初めてのプロジェクトリーダー（2）
なにはともあれ、まずはチームビルディング

永和システムマネジメント
岡島幸男
2005/4/6

　前回は開発者からリーダーへの視点の切り替えについて解説をしました。今回からいよいよ、実践的な内容に入っていきます。

　まずは、計画を立てます。通常プロジェクトマネージャが作成するプロジェクト全体計画は、プロジェクト目的、概要、課題、スケジュール、コストなどについて漏れなく記述する必要がありますが、ここでの計画とは、必ずしもプロジェクト全体の計画を意味してはいません。これは、あなたのチームの計画書だと考えてください。主な目的は、チームの運営方針を表明し、メンバーに足掛かりを与えることです。プロジェクトの規模や、体制によってまちまちですが、プロジェクト全体の計画書とはまったく別に作成してもよいでしょう。計画の作成、発表とそれを通じたメンバーとのコミュニケーションを通じて、チームを作り上げていきます。

◆ チーム計画に記述する内容

　計画に記述する内容は、以下を参考にしてください。どのようなフォーマットでも構いませんが、PowerPointなどのプレゼンテーション形式をお勧めします。

◎ プロジェクト目的と、チームの位置付け

　プロジェクト全体の目的と、その中でのチームの位置付けをはっきりさせます。関連のあるほかのチームがあれば、そのチームとの関係、役割分担も説明します。プロジェクト全体の目的などは、ほかにプロジェクト全体の計画があればそれを参照するようにしてもよいでしょう。

◎ スケジュールと体制

　 簡単なスケジュールとチームの内部体制を説明します。例えば、「3月から増員」など、スケジュールに応じて体制を変えていくことが決まっているのであれば、それも説明します。この時点で、スケジュールの詳細を出す必要はありません。重要なマイルストーンのみ抽出してください。

◎ システム概要

　今回ターゲットとなるシステムの概要を説明します。必要があれば（決まっているのであれば）、ユースケースやアーキテクチャについて説明してもよいでしょう。ただし、詳細過ぎないようにしてください。あくまで目的は足掛かりであって、すべてを正しく説明することではありません。

◎ 課題

　チームの作業遂行に当たっての課題を書き出します。課題の最適な粒度を決定するのは難しいのですが、チームの視点から見て最適なサイズにしてください。プロジェクト全体の課題をブレークダウンした結果が望ましいでしょう。チームの力ではまったく解決できない課題を書いても意味がありません。

◎ 役割分担

　各メンバーに期待する役割を表明します。経験、スキルなどを考慮し、サブリーダーやアーキテクトなどの役割を必要に応じて与えて体制図を作ります。ちなみに、体制図に加えて私がよく使うのは、「性格に応じたフォーメーション」です。

　下図は、実際私が担当したあるチームのフォーメーションです。各メンバーのスキルが総じて高く、自律して動けるメンバーが多かったため、サブ機能ごとに責任担当を割り振りました。すでに2回目のフェイズで、各メンバーの性格はつかんでいたこともあり、各メンバーの性格に応じて、担当する機能を決めました。初めて採用する技術を使ってバリバリ進めていく必要がある機能は「アタックタイプ」の性格を持つ人を、逆に既存の技術を使って、じっくり慎重に進めていく必要がある部分は「ディフェンスタイプ」の人を割り振りました。「バランスタイプ」の人には、仕様全体をつかむことが必要な機能を割り振りました。

あるチームのフォーメーション

　目的は、作業の進め方に関する判断基準を与え、リーダーからの期待感を伝えることです。例えば、アタックタイプの人には、広く、浅く、素早く動き、新しい技術に関しても積極的に取り上げて提案してほしいと伝えます。逆にディフェンスタイプの人には、焦らず、既存の技術を使って確実に成し遂げてほしいと伝えます。ちゃんと期待を伝えることが重要です。

　すべてのプロジェクト、チーム、フェイズに最適な方法とはいえませんが、メンバーそれぞれの得意とするスタイルでの作業が多くなるため、チーム全体のモチベーションを高く保つ効果があります。

◎ チーム目標

　ここでの目標とは、プロジェクト収支などプロジェクト全体での話ではなく、チーム内部で何を達成するかということです。チームの方向性を合わせるのが目的ですので、数値化されていなくても、多少あいまいでも構いません。目標設定のポイントは、メンバーにとっての「チャレンジ的な要素」と「ハッピーな要素」を組み込むこと、そして「リーダーとしての信念を盛り込むこと」です。例えば私は、「新しい技術の導入（ただし、きっちり検証しながら）」の一文を必ず入れます。新しい技術にチャレンジすることは、私にとっての楽しみであり、そしてほとんどのメンバーにとっても楽しみだと考えているからです。

◆ いつ作成し、発表するのか

　プロジェクトの開始時に加え、繰り返し型の開発プロセスを採用しているのであれば、フェイズごとに（計画を）作成します。前フェイズの課題を踏まえて、今回のフェイズでそれらに対してどのように対処していくのかも説明します。

　なお、作成した計画は原則的にメンテナンスしません。何度も違うバージョンを配って、メンバーを混乱させないためです。どのように発表すると効果的かを十分考えましょう。発表は1度きりで、しかもメンバー全員の参加は必須です（もちろん、メンバーが追加された場合はその都度説明を行います）。

　発表はプロジェクターを使って、プレゼンテーション形式で行います。この発表は、メンバーに対するイニシエーション（通過儀礼）の効果も狙っているので、自己紹介などを行って、場を和ませてください。その後、必要に応じてプロジェクト全体の計画を発表した後に、チームの計画を発表します。

　役割分担とチーム目標は最後に説明します。目的、体制、課題などは、ほぼ議論の余地がないはずですので、質疑応答をきっちりと行いながら進め、役割分担と、目標部分ではメンバーとの議論を大事にしましょう。「チーム一丸となって取り組む必要があること」「メンバーそれぞれに期待していること」などを正しく伝える必要があります。熱く語ってください

◆ 開発プロセスをどうするか

　ここまで、開発プロセスにはあえて触れずに書いてきましたが、ソフトウェア開発プロジェクトの計画において、開発プロセスは重要なポイントとなります。計画発表時に開発プロセスについて説明を求められることも多いでしょう。

　プロセスがプロジェクト全体ですでに決められている場合など、従わざるを得ない局面も多いでしょうが、もし許されるのであれば、「中庸」の価値を意識しながら、チームに最適なプロセスの導入にチャレンジしてみてください。「チームは一期一会の原則」にあるように、プロジェクトやチームメンバーに応じたプロセスの導入が理想です。

　現在主流となっている開発プロセスには、大ざっぱにいってXPに代表される「アジャイル型」とウォーターフォールに代表される「従来型」があります。開発プロセスについてあまり深入りすると、この連載の目的を逸脱（いつだつ）してしまいそうなので、ここではごくあっさりと「アジャイルと規律」［*］に従った、アジャイルと従来型（計画駆動型）の「ホームグラウンド」（最も成功する確率の高い条件）を紹介するにとどめます。

［*］ 「アジャイルと規律」は、アジャイルな開発プロセスと、計画駆動型（従来型）の開発プロセスについて、公正な立場で比較、検討したうえで、プロジェクトの特徴に応じたハイブリッド（いいとこ取りな）プロセスを生み出すための実用的なアプローチを教えてくれます。

特徴	アジャイルの場合	計画駆動の場合
アプリケーション	小規模、変化する、不確実	大規模、安定、高い確実性
マネジメント	内在化された計画、質的制御、暗黙知	文書化された計画、量的制御、形式知
技術	シンプルな設計、短いインクリメント、実行可能なテストケース	大規模な設計、長いインクリメント、文書化されたテスト計画
人	専任のオンサイト顧客、熟練した開発者、高い自由度の文化	必ずしも専任でない顧客、一般レベルの開発者、秩序を尊ぶ文化

◆

　会議、ミーティングは、プロジェクト活動の中で重要な位置を占めます。もちろん意思決定機構としても重要ですし、貴重なコミュニケーションの場です。会議、ミーティングにも、朝会、設計レビュー、お客さまとの進ちょく会議など大小いろいろあります。次回は運営のコツを実体験を交えて説明します。

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）