貴方もイタコエンジニア
プロジェクトを上手く回すための要素
すべてのプロジェクトは、それぞれで有限の人・物・金で構成され、唯一無二のアウトプットを送り出す。プロジェクトは上手くいくケースもあるし、失敗するプロジェクトもある。どちらかと言えば、何らかの要素において、失敗していると印されるプロジェクトが圧倒的に多い。プロジェクトがプロジェクトになるためには、契約までのプロセスから、プロジェクトのライフサイクルに突入し立ち上げ(initiation)、実施(execution)を経て完了することでプロジェクトが終了(closing)となる。この契約からプロジェクトの終了まのでライフサイクルすべてに出てくるのは、たった一つ、“人”だ。人は、契約からプロジェクトの終了までプロジェクトに関わる関係者と一貫して何らかを共有しアウトプットを続ける。俯瞰しなおすと、契約からプロジェクトまでを構成する要素の中で一番占めるものはやはり人であって、プロジェクトはプロジェクトライフサイクルの観点からも、人に始まって人に終わるということに尽きる。尽きる要素の人を上手く回せることができれば、プロジェクトを上手く回せるのではないか、とどれだけの人が気付いているだろうか。
それでも人はコミュニケーションできない
契約後、プロジェクトを開始するためにメンバを集めてプロジェクトの憲章(スクラムならプロダクトバックログ)を共有するためのコミュニケーションを皮切りに何回もコミュニケーションを重ねると、話す人はいつも同じ人であることはないだろうか。プロジェクトマネージャ、グループリーダやメンバ含めて、積極的に話す人は話すし、話さない人は話さない。ファシリテーションが上手な人が、促し、機会を与えるとやっとボソボソとこぼす人も居るし、一方的に捲くし立てるようなコミュニケーションをとるメンバもいるだろう。話さないということは、コミュニケーションを発しないということを言っているが、コミュニケーションの本来の意味で言えば“相互”の意思疎通が成り立つことが必要だ。その点から言えば、一方的に話す人や人の発言をさえぎるひともコミュニケーションが出来ない人になる。コミュニケーションは、“話す”、“聴く”、“共有する”、“意思表示する”をすることだが、本当にプロジェクトのメンバ一人ひとりが理解して、実践できていると思っていたらそれは間違いだ。
イタコエンジニアの登場
顧客とプロジェクトメンバ(厳密には、顧客もプロジェクトチームの一員だ)、プロジェクトメンバ間、プロジェクトメンバとマネージャなどコミュニケーションをとる場面は多彩だ。このいくつもあるコミュニケーションパスは、何をするにしても、何とかして意思疎通して“共有”を図らないとプロジェクトは望まないほうに突き進む。そうならないように、イタコエンジニア*1を担う“だれか”が、場面場面のコミュニケーションを促していく。プロジェクトであるから、当然、プロジェクトマネージャは本来コミュニケーションを持っていることが必然だし、リーダのエンジニアにも必要なコンピテンシだ。スクラムならそれこそ、全員に必要とされるコンピテンシだ。そういったロールを担う人がコミュニケーションを促すことを期待するが、残念なことに本来のコミュニケーションから言えば当然の“話す”、“聴く”、“共有する”、“意思表示する”が意識的にされない。
だからこそ、メンバのコミュニケーションスキルは、そのときのプロジェクトの必然性から集められたメンバそれぞれに依存してしまうから、リスクマネージメントの観点からも過度な期待は禁物だ。多くのリスクは、仮にリスクを識別できていてもコミュニケーションが失敗することで発現の確率が上がってしまうものだ。だからこそ、コミュニケーションを維持促進するためにファシリテーションができる媒介者のイタコエンジニアが必要になる。
貴方もイタコエンジニア
兎に角、プロジェクトを成功させるためには、コミュニケーションをとることが最大の成功要因だから、プロジェクトの中で一人ひとりが対等に意思疎通できる環境作りが肝要になる。それを押し付けるのではなく、“全員イタコエンジニア”をローガンにしてコミュニケートできるように促す道具として活用する方法もあるだろう。何より、半分は遊びのように思えるようなおかしさがネーミングとしてあるのが良いと思っている。
#devLOVEで局地的に流行らせてみました。
- 道具室(アプリとか)
- 図書室
- 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します）
画像は、amazonでのお買いもの。テキストリンクは、itunesでのお買いもの。
- 視聴覚室
- 調達室
