人を入れればプロジェクトは救われる？？
プロジェクトの人員増加の前に考えなければいけないこと
往々にして、プロジェクトの進捗が芳しくなかったり、スケジュールが厳しくなると、打たれる対策は「人員の追加」です。
しかし、人員の追加はプロジェクトを救う方法の1手段でかつ最後の手段にすぎません。人員の追加はコストが上がり、教育や管理で一時的に生産性が下がるという状況を生みます。
そんなリスクがあっても、人員を追加をする以上はその効果がリスクに見合う必要があります。
「そもそも問題の解決になっているか？」を検討せずに、そのリスクを背負い込むワケにはいきません。
にもかかわらず、「まずは人員増強」を最初に行うプロジェクトが多いのには違和感を覚えざるをえません。
まず、人員の増強を検討する前に決定権者は以下のことを「確認」せねばなりません。
しかも、この「確認」は自分の目・耳で集めねばなりません。他の人からは既に人員の追加要望が上がっているのであれば「追加が必要な理由」しか聞くことが出来ないからです。
「本当に必要か？」というチェックは自分で行うしかありません。「増員」を要望するベンダにそのチェックを行わさせるのも間違いです。以前の投稿でも書きましたが「増員はベンダには都合がいい」という事実も忘れてはいけません。
無論、「パートナー」である「ベンダ」を疑えと言っているわけではありません。ただ「利益と立場が違う」のは事実です。
ですから、こういった増員という重要な決断をする前に「自分自身でチェック」を行ってください。
ではそのチェック項目は何でしょうか？
１．プロジェクトは回っているか？
２．現在の人員にタスクは十分に振れているか？
３．何がボトルネックかはっきりしているか？
人員を増強するにしても「どんなロールの人にどんなタスクを持ってもらう必要があるのか？」がはっきりしないといけません。
往々にしてJavaのプロジェクトだから「javaの優秀な技術者を」というような依頼が非常に多いのが事実です。
しかし、プロジェクトの中で実装者が不足するケースは以外に少なく、他の原因の場合のほうが多いのです。
まず第一点の「プロジェクトは回っているか？」ですが、要件→設計→実装→フィードバック→要件・・・というプロジェクトサイクルが回っているかという点です。そのためにはプロジェクトにおけるロールがはっきりし、その役割が果たされていて、さらには各ロールの間が有機的に結合していることが重要です。
意外ににベンダはプロジェクト慣れしているため、自然とロールを配分してチーム化します。特にロール配分やチーム形成が難しいのは「ユーザー側」であることを覚えていてください。
基幹のような大規模プロジェクトはそうそう社内でもあるものではありません。そうなると、特にユーザーサイドは不慣れなチーム作りをせねばなりません。 その上で、要件を出して設計をチェックし、実装のフィードバックを次の要件に盛り込むというタスクを果たすロールを配分したチームを作らねばならないのです。
ですから、「（特にユーザーサイド）チーム・ロール構成は確立しているか？」というのはプロジェクトが回っているかという上で、重大なチェックポイントです
次の「タスクが振れているか？」というのは全体的な人々の「忙しさ」をチェックすれば分かります。単純な労働時間もしかりですが、各担当者からのヒアリングでいいでしょう。
ここで注意せねばならないのは、一部のコアメンバーだけが非常に忙しいケースをチーム全体が忙しいと勘違いすることです。
これは、その「コアメンバー」が果たしているタスクが「ボトルネック」になっている場合を意味します。ですから「マネージャーとその周辺は異常に忙しい」というケースと「チームのリソースを使い切っている」という場合を取り違えてはいけません。
ためしに、PMOから離れた、末端のタスクを持っている実装者のもとに行き「細かい作業をお願いできるような状況か？」と聞いてみると良いでしょう。
中心的なマネージャーから「忙しいか？」と聞かれれば、自分の貢献を疑われないために、どうしても「忙しい」という回答になります。
しかし、「もう少しタスクを増やしてもいいですか？」と聞かれれば、当然「リーダーを通してくれ」といいつつも、「可能か否かは匂わせるのは吝かではないはずです。
次に「何がボトルネックか」ですが、これは結局増員するにしても「どんなロールでどんなスキルが足りないのか？」をはっきりさせるために重要です。
その際に、プロセスは重要な役割を果たします。例えばこの表を見てみましょう。
プロセスタスク
このように、開発作業の中で作成する「成果物」がはっきりしている場合、「今何を作ってて何が出来てこないのか？」をはっきりさせることができます。
詳細設計が足りないのか？実装コードが足りないのか、テスト設計者が足りないのか？有るいはもっと上流に戻り、画面設計書が足りないのか？さらにそもそも要件定義における機能概要一覧が上手く作成できていないのか？業務が定まらず「業務フロー」がかけていないのか？
あるいは実装面でアーキテクトが足らずフレームワークが出来上がらないのか？
ちなみに私見から言えば、一番今まで多いケースは「要件定義」における「業務フロー」や「機能概要一覧」が定まらないケースが一番多いと思われます。
なので、こういうプロジェクトが「Javaの技術者を・・・」と要望を出すことに違和感を覚えざるをえません。
「業務フロー」や「機能一覧」を作成するにはJ2EEの実装技術は「有るに越したことはない」という程度のスキルになります。
さて、今回は「プロジェクトを救う」際に「人を増やす」前にしなければならない大事なポイントを述べてみました。
少ない人員で出来ていないことは多くの人員ではもっと困難を極めます。
10人に対して、プロジェクトを回し、タスクを振り分け、適宜にボトルネックを解消することが出来ていなのであれば、人員を増強すれば、よりプロジェクト運営は困難になります。
是非、皆様の周りのプロジェクトで「人員追加」が持ち上がっているのであればこの機会に、チェックをしてみてください。
