キックオフミーティングにおける「パーソナルナレーティブ」

開発チームのキックオフミーティングで、「プロジェクトチーム計画書」を使ってメンバーに期待感を伝えるのがぼくのやり方だ。
どうしたらシンプルに、ストレートにリーダーとしても期待感を伝えるか、いろいろ考えているが、とあるプロジェクトで新しいやり方を試してみた。
パーソナルナレーティブは、ぼくの造語で、コーバーンのユースケース実践ガイドにおける、利用ナレーティブから着想を得ている。例えば次のような感じだ。

期待する役割:業務エキスパート

  • 林田さんは業務エキスパートで、お客さんと話しながら要求を詰めていくのが得意であり、状況によっては客先に常駐することも厭わず、お客さまとまったく同じレベルで業務を理解し、システムに関する要求を理解している。
  • 品質・テストに関しての意識が高く、システムテスト結合テストの項目作成はそれらを十分配慮して行っており、要求の変更から発生するテストに対する影響に関しても十分注意深くトレースしている。
  • 山田さん、川田さん、森田さんからは適宜仕様に関する質問が舞い込んでくるが、これらに関して適切に回答を行い、必要に応じてお客さまに確認している。
  • そうはいっても、開発側の都合もよく理解しているので、無理な仕様の盛り込みは避けてくれることが多い。

1行目には期待する役割をシンプルに書く。ちなみにぼくのプロジェクトでは、「業務エキスパート」「サブリーダー・テストコーディネータ」「技術リーダー・アーキテクト」「開発環境担当・副アーキテクト」の4人のメンバーから構成されている。
2行目以降は、きわめて具体的に、プロジェクト中に各メンバーに期待する行動や、他のメンバーとのかかわりあいを書いていく。特に重要なのは他のメンバーとのかかわりあいで、上の例だと、「山田さん、川田さん、森田さんからは適宜仕様に関する質問が舞い込んでくるが・・」が相当する。もう一つ具体例を示しておこう。

期待する役割:サブリーダー・テストコーディネーター

  • 川田さんは、業務アプリケーションの開発に精通していて、特に業務の観点からのテスト項目の作成と、効率の良いテスト実施には定評がある。
  • 品質の高いテストを行うには、業務を把握することが一番だという認識があり、業務仕様の細かい部分のモレも見逃さない。
  • 業務リーダーの林田さんが作成した結合テスト項目に対して、レビュー時には、開発者の視点から足りない項目を指摘することも多く、後輩である森田さんにテスト時に必要な観点をレクチャすることがある。
  • また、テストの無駄を省くことには積極的で、Excelなどを活用したテストツールを作成したり、既存の製品を調査・採用することもある。
  • 開発リーダーである岡島がいないときに、その代理としてチームのまとめ役となる。

その他のコツは、

  • その人のキャラクターを無視したことは書かない
  • 期待感が重要。今出来ていることを書くのではない
  • 必ずメンバー全員の前で声にして発表する

といったところ。
メンバーのフィードバックを得たところ、なかなか好評だった(と思っている)。リーダー本にも書いたが、ぼくの理想とするチームは「特攻野郎Aチーム」のように、いろんなキャラクタ・役割・能力による混成チーム。このように具体的にメンバーの「To Be像」を表現することによってそれに近づけるような気がしている。