はじめに
開発リーダーの役割りは、プロジェクトの規模と大きく関ります。本稿では、メンバーの人数が5〜10人程度のチームにおけるプロジェクトを想定しています。このレベルの人数をまとめる場合、20〜100人規模の場合とでは大きな違いがあります。それは、「チームメンバー1人1人と向き合える」「向き合う必要がある」ということです。20〜100人をまとめる場合、どうしても統計的／システム的な対応や考え方が求められます。こういった大プロジェクトを成功させている人が5〜10人のチームを成功に導けるかというと、必ずしもそうではありません。数字だけしか追えず、技術への理解が浅かったり、その人の人間的な魅力が薄ければ、誰もついてこないのです。大プロジェクトを成功させていても、PMP（Project Management Professional）を持っていたとしても、それだけでは成功に結びつかない難しさが、この規模のプロジェクトにはあるのです。
もちろん、プロジェクトマネジメントが不要と言うつもりはありません。しかし、プロジェクトマネジメントについて学びつつも、メンバー1人1人のポテンシャルをどれだけ引き出せるかが進むべき道となります。そこはプロジェクトマネジメントのようなスマートな世界とは違う、泥臭い部分もある世界です。しかし、それだけに面白い／やりがいがある部分も多いのです。
鉄則1：プロジェクト／案件内容の把握を確実に
プロジェクトの初期段階では、案件そのものを理解／把握することが開発リーダーにとっていちばん重要です。この認識がずれてしまうと、どんな計画を立てても的外れになってしまいますし、任された案件がうまくいくことはまずありません。
案件内容というと要件だけを思い浮かべる方もいますが、それだけではありません。特に重要な確認点を次に挙げます。
- 要件（特に案件の動機）
- リリース日
- 予算総工数
案件に取りかかったら、まず行うのはヒアリングです。案件が手許に来たということは、案件を作ったり見積りをした人が必ずいるはずです。その人たちから、できるだけ多く情報を引き出すことが肝心です。訊き出す対象は上司や先輩、顧客になります。外部に訊く必要がある場合は、案件説明会などの開催を事前に計画しておく必要があります。
こういったことは最初に訊くほうが楽ですし、当然手戻りは少なくなります。何も知らない新人が教育担当にアレコレと質問するように、案件リーダーの新人であるあなたは、疑問点やわからないことを上司や先輩にどんどん訊いていってください。いったん案件を引き受けてしまえば、今度は自分が案件の内容をすべて知っていることになります。案件を完全に引き受ける前に、「それをやるにはここを教えて」とやるべきです。それぞれの確認点について見てみましょう。
要件確認（案件の動機）
案件の動機／目的の把握は、非常に重要です。動機を把握してないと、たとえば次のような事態が発生します。
- コスト削減が目的であるのに、マニュアル操作の多いシステムを構築してしまった
- 処理の高速化を目的としているのに、テスト計画にパフォーマンステストが盛り込まれていない
- 法改正に伴う改訂なのに、法律の施行に間に合わないリリース計画を立てている
また、この動機が強いものなのか、弱いものなのかも知っておきたいところです。動機が非常に強い場合は、先方は協力的でしょうが、要望なども多い可能性があります。逆に動機が弱い場合は、こちらから質問をしてもなかなか返ってこなかったり、最悪のケースでは案件そのものが無くなったりしますが、こちらの要望が通りやすい傾向があります。
ほかにもチェックポイントはいくつかありますが、要件定義の話になりますので、詳細については省きます。
- 新規案件か改訂案件か（影響調査の範囲）
- 非機能要件の有無（パフォーマンスなど）
- 使用する技術について（技術的な新規性の有無）
- インフラ環境（セキュリティ対策や機器発注の必要性）
リリース日
リリース日が決まっているか、も重要なチェックポイントです。決まっていない場合でも、顧客側の希望日があったり、チーム内やPMや顧客担当者間の暗黙の了解があることがあります。
次に、そのリリース日が動かせるかどうかを確認します。プレスリリースを出していてリリース日がその中に明記されてしまっている場合、動かすことは困難でしょう。また、担当している案件が前提条件となって他の案件が動いている場合、当然、その案件よりも先行してリリースする必要があります。
予算総工数
担当している案件について、どれぐらい手持ちの工数があるかを把握しましょう。見積りがこれからの場合は、見積り後に下記をチェックしましょう。もし教えてくれないのであれば、工数管理は誰か別の人がやることになります。
- メンバーの人数を概数で出す 総工数：6人月（120人日）
開発期間：2か月
※開発期間は案件開始予定日と案件終了日から求めます
→ 必要なメンバー：3人（＝6（人・月）÷2（月））
この時点では、2か月間（自分を入れて）3人が関わるんだ、という程度の認識で問題ありません。
- 見積り内容の把握
通常は見積りの際の前提や詳細があるはずです。人によっては、改訂箇所をソースレベルですべて書き出してあったりします。そういった情報は貴重ですので、必ず引き継ぐようにしてください。
なお、この時点で、自分が考えている（だいたいの）総工数と見積り総工数が、明らかに乖離している場合があります。これはデスマーチへの危険信号か、案件に対する自分の勘違いか、見積り担当者が勘違いしていることになります。いずれにせよ、早急に案件の見直しを図る必要があります。
鉄則2：チームビルディングを楽しもう
案件状況を把握したら、次はチームビルドです。チームビルドは、案件リーダーとして最も工夫のしがいがある部分だと思っています。これから案件を一緒に進めていくチームですので、よく考えて作りたいものです。
メンバーの決定
まず、案件内容を勘案しながらメンバーを決めます。決め方はケースバイケースですが、いちばん重要なファクターは、メンバー各自のスキル／経験でしょう。特殊な技術が必要だったり、コーディング量が多い場合は、その技術に特化したメンバーを必ず入れるようにしましょう。改訂案件であれば、以前の案件の経験者も入れておきたいところです。
逆に、「経験させてやってくれ」とか「人が余ってるから」、「ほかに誰もいないから」という理由で新人や未経験者をたくさん参加させられた場合は、大変です。基本的に戦力にならないどころか、説明などにほかのメンバーの時間をとられてしまいますので、できるだけ断りましょう。一般的には、5人のうち1人が未経験者、というくらいが限度と考えるべきでしょう。
次に考えるのは、案件に参加できる期間です。普通は優秀な人ほど一案件に拘束可能な時間が少ないはずです。本当に優秀な人はレビュアーとしてのみ参加してもらうこととして、開発期間を通じて参加できるメンバーをできるだけ増やしてください。入れ替わりが激しいほどリーダーの負担が大きくなりますし、メンバーの責任感も低下してしまいます。最も人が必要な期間（たとえば製造期間など）のみ人を増やすこととして、あとは一定のメンバーで進めていくのがよいと思います。
なお、メンバーがあらかじめ決められていることもありますが、交渉次第で変更可能な場合もあるので、できるだけ案件に合わせたかたちでチームビルディングをしましょう。
メンバー間のコミュニケーションパスを確保
メンバーが決まったら、まずキックオフミーティングをします。案件の説明もそうですが、お互いが直接顔を合わせることが重要です。たとえば、Aさんが知ってることをBさんが訊いてきたので、「Aさんに訊いて」と言ったら、
- ケース1：Bさんから「Aさんを知らない」と言われた（暗に話したくない）
- ケース2：そのままになった（Bさんが自分で調べているらしい）
- ケース3：BさんがAさんに訊きに行ったら、Aさんに邪険に扱われた
→ 結局、自分がAさんに訊いて、Bさんに伝えた
こういう経験はありませんか？ コミュニケーションパスがリーダーとメンバーの間だけにしかないと、リーダーは情報の伝達役のみで1日が終わってしまいます。メンバー間で面識があれば、上記のような事態はかなり軽減されます。人間は知ってる人と知らない人で驚くほど対応が違うものです。できるだけメンバー間のコミュニケーションパスを確保するようにしてください注1。
著者の経験では、最初に飲み会を開くとかなり効果がありました。単純にメンバーがどのような人かを知る場にもなります。お酒がダメなら夕食を一緒に食べるということでもでよいので、試してみてください。
