プロジェクトリーダーのお仕事（２）
昨日、書いた後考えていたけど、そもそもの前提を書いてないから、壮大な精神論になってる気がする。
まず、前提として、受託にしろ自分から何か作り始めるにしろ、目的地を捉えている必要がある。目的地が見えていなければどれだけ『道』を創っても、それは目的地に到達出来ない。
なので最初にするのは、まず目的地の明確化。
これは簡単なはずなんだけど、実際には色々な人が関係するので、難しい。
本来は最初に思いついた「欲求」が最終的な目的地のはずなんだけど…
- 伝言ゲームで全然別の目的地を伝えられたり
- 目の前に見えてるのに遠回りをするように伝えられたり
- そもそも言い始めた人が わからない もしくは もういない
よく聞こえるのは、
「いやー僕らも急に言われて困っちゃって」
「もっと金額を増やせ」
「この技術（言語、フレームワーク）を使ってください」
本質的には、目的地に辿り着ければ実際の手段は何でもいいはず。
だから、自社でプロダクトを開発するような形態は自身が発案者なので「やりやすく」、SIerのような形態は他者が発案者なので「やりにくい」というイメージがつく。
目的地の明確化は、単純に「発案者に聞く」か「発案者が書いたものを受け取る」というのがてっとり早い。それが難しいのであれば、色々な情報をもとに、自分なりに目的地を考える。自分なりの目的地が見つかっていない状態でプロジェクトリーダーを担うのはかなりやばい。そういう仕事は断った方がいい。
目的地が見つからない原因は
- 請負う自分自身の知識不足（技術と業務）
- 発案者本人がよくわかっていない
知識不足は興味不足と言ってもいいかも。興味があれば最初に知識がなくても自分から情報を取りに行くので補えることが多い。
問題は発案者本人がよくわかっていない方で、経験した中で多かったのは、「現場からこういう意見が出ているんだよ」というやつ。誰が言っているのか？何人が言っているのか？強い希望なのか？わからない。誰かの代弁をしているっぽいのだが、雲をつかむような話で、何もわからなかったりする。
なので、最初に目的地を明確にするのが大切。
ちなみに、結果として、目的地が最初に思っていたのと違ったり、ズレたりすることは良くある。でもこれは問題ない。問題は変わった時、ズレた時に、「変わった」「ズレた」というのに気づけること。気づくためには基準を持つこと。そして変化を予測…というか起こると認識すること。
うーん。実データをちゃんと示さないと、どれだけ書いても精神論っぽくなっちゃうな…
まだ続く(｡･ω･)ﾉﾞ