チームビルディングで使える魔法の言葉

人的リソースのリスク
プロジェクトのリスクには人的リソースがかなりのウエイトを占め、エクスボージャに換算すればプロジェクトを赤字に追い込む可能性だってある。プロジェクトマネージャのプロジェクトファシリテーションのコンピテンシが不足すれば顧客との対外的な対話に支障を及ぼすし、プロジェクトチームの運営にも大きな問題を生じる。同じようにアーキテクトやSEリーダなど設計やプログラミングなどをリードするエンジニアのファシリテーションコンピテンシやエンジニア一人ひとりのコミュニケーションコンピテンシになんらか問題があれば、小さな穴となって後々のリスクの種として埋まってしまうかもしれない。エンジニア一人ひとりがプロジェクトで発揮するコンピテンシのほか、それぞれのプライベート、たとえば健康についても人的リソースのリスクとしては考慮する必要があるし、プロジェクトチームのメンバは重要だがセンシティブな情報としてプロジェクトのaccountabilityの責を負うマネージャにはオブラートに包んででも知らせておくべきだろう。

プロジェクトマネージャの人的リソースへの期待
プロジェクトマネージャは、そのプロジェクトの作業を見積もり、展開する際に、チームメンバのファシリテーション、技術、並びにセンシティブな健康など勤怠に及ぶ持ち合わせた情報の中でプロジェクトに最適化して人的リソースを配付するから、必要な情報が後だしされるとリプランしなければならなくなる。リプラン自体は、プロジェクトが終わるまでいつでも発生することだから、プロジェクトマネージャならそれをすることは厭わないが、リプランする際の影響度は小さいことに越したことはない。だから、なんらか事情があるのならオブラートに包んででも「何かあるかも」と事前に告知してほしいと思うのは当然のことだ。

プロジェクトのチームビルディング
プロジェクトのチームビルディングには、フォーマルなプロジェクトキックオフミーティングから始まる。チームが編成されれば、過去に何らかのプロジェクトで顔見知りなメンバを何人かいることも少なくないだろう。チームビルディングは、入学式後のクラスでの自己紹介のようなものだ。最初の関係作りに失敗してしまうとリカバリはしんどい。仕事だからと言って、決められたことを言われてやるだけのエンジニアは必要とされない。プロジェクトに必要なコンピテンシをチームの一員として自己を自ら位置づけ、プロジェクトを成功に導くことが期待されるし、応えたいと思うものだ。

些細なことでチームまとまる
チームを編成すると、なぜか、賑やかなエンジニアもいれば、無口なエンジニアも混ざる。どちらがいいか悪いかではないが、賑やかでも無口でも、プロジェクトをファシリテートするコンピテンシは一律に求められるものだ。だから、チームメンバが一方的なコミュニケーションの関係になっているなら赤信号だ。誰かがやるべきことを果たしていないからだ。コミュニケーションの不均衡は、人的リソースのリスクに発展する可能性があるから、それを暗示的に明示的に関わることで変える必要がある。
とても些細なことだが、マネージャもプロジェクトマネージャも少しチームから離れて状況を見る視点を持っているものだ。だから、それに気付くことが出来るだろう。もし、コミュニケーションの不均衡の予兆を見つけたら、まず、不均衡の状態のメンバそれぞれのデスクをまわることだ。そして、マネージャからコミュニケーションを促せばよい。いきなり、プロジェクトのフォーマルな場で動くより、まず、インフォーマルなコミュニケーションを取ってみよう。例えば次のようなことを。

• 雑談をする
• 食事を一緒に食べる
• お菓子を分ける
• 飲みにいく

結局、人は感情が大部分を占めるから、本能の一部である食べることが絡むとつい本音が出るものだ。こちらとしては、本音を気兼ねなく伝え交わすことが出来る環境の取っ掛かりを作ることでチームがまとまる方向に向かわせられることできる。

「ご飯食べに行こう！」
「コーヒーのみに行く？」
「これ食べたことある？」
「明日、飲みに行く人？」

とても簡単で、とても効果がある魔法のことば。ありふれていることが一番良いこともある。

• 道具室(アプリとか)

• 図書室

ストーリーポイントと理想日の違いが、中々腹に落ちず。頭でわかっているつもりでも、胸がすっきりしない感じ。自分の言葉でうまく言い替えられなければ本質的に理解しているといえないとわかっているから、ちょっと歯がゆい日を何日か過ごした後、ふと「あぁ、それでいいじゃん」と思うときが間々あるもので。大げさに言えばブレークスルーした、みたいな。実際適用するなら経験のないチームには理想日のほうがWBSの展開で経験をしているから取っ付きやすいだろう。理想日でボトムアップで積み上げるか、仮定か一般的な画面などチームで作業のプロセスとボリュームの共通認識を作ってそれを基軸にほかの作業を計るか。積み上げは抜け漏れの恐れや仔細な仕様の有無に無駄な時間をとられるから、短時間に“大体の”見積もりをするというプライオリティなら必然とストーリーポイントになるだろう。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

• 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します）

• 視聴覚室

• 調達室