プロジェクトの体制図に人の名前が書かれていても、必ずしも全員が求められるスキルを持っているとは限りません。ボートの見えない側では、シャベルや塵取りで我武者羅に漕ぎまくっているかもしれません。
「案件が取れるかわからないから提案書の体制図には適当に人をいれといて、もし取れたらその時に考えよ」これは提案時に、なされる会話です。
これは避けようのないことでもありますが、いざ受注できた時にどれだけ真剣に体制を考えるか、それが重要です。盤石の体制で始まることは極めて稀ですが、急ごしらえの体制でスタートすると必ず出遅れて、進むにつれて遅れは広がっていき、気が付いた時には炎上の一歩手前という状況になっています。

見切り発車は仕方ない

システム開発プロジェクトが立ち上がると、推進する体制を構築します。作業計画を立てて、必要なスキルのあるエンジニアを確保して、技術力もコミュニケーションスキルも高いチームリーダーを据えて盤石の体制を築きます。というのは理想で、多くのプロジェクトでは、理想的な体制ができていない状況で見切り発車することがほとんどです。
大きい案件の場合、提案してからラッキーにも受注して契約締結するまでには1ヶ月以上かかることも普通で、提案時にエンジニアを確保しても案件が確定するまでの期間、厳密に言えば契約を締結するまでの期間にエンジニアを遊ばせておくことはビジネスとしてあり得ないので、見切り発車となってしまうことは避けようがありません。
契約が締結出来たら満足してしまう営業サイドやマネジメントは、始まった後のことをそれほど真剣に考えているとは思えず困ったものです。
プロジェクトの推進責任を持つ製造サイドとしては、何しろプロジェクトをスタートしなければならず、スキルは二の次として、とりあえずエンジニアの数を確保することを最優先に考えます。まったくの新人が投入されたり、やったこともない領域を任せたり、運よくスキルフルな人がいたとしても別プロジェクトとの兼務であったり、盤石の体制でスタートを切れることは、ほぼありません。
理想の体制を築くために優秀なエンジニアを探し続ける気持ちを持っていたとしても、プロジェクトの推進が忙しくなると理想とする体制への追求は後回しになってしまいます。

危うい体制となりがちなプロジェクト

見切り発車は仕方ないとしても、エースや頼れるエンジニアが一人もいない状況で突き進むことは危険です。最初から出遅れると、遅れを取り戻すことに躍起になってしまうため、頭数は揃っているように見えても水面下では猛烈に漕ぎまくっている状況で、漕いでも漕いでも進まない自転車操業の始まりです。
こうならないために危うい体制になりがちなケースでは、計画にゆとりを持たせるなど事前に打てる手立てを取っておくことがPMには求められます。

①急に立ちあがる
コンペもなしにベンダー決め打ちで急に立ち上がるプロジェクト。これまでに付き合いの多い大手SIerやグループ内のシステム関連会社は、既に機密保持契約があり、契約形態もいくつも持っているためクライアントとしては手続きが楽です。ベンダーとしても安定的に案件がくる関係性は魅力なので無下に断ることもできず、クライアントの「こんなことやりたいんだけど、なんとかならない？」という軽いリクエストに「検討しましょう！」という危機感のない回答をしてプロジェクトが始まってしまうのです。
いざ始まると、何やら本気で期限も決まっていて逃げられない状況のため、とりあえず誰でも良いから空いてる人をアサインしてしまいます。

②ゴールが途中で変わる
例えば、業務システムの開発途中でボットを入れたい、ECサイト構築の途中でサブスクモデルに変えたいなど。途中で目的が変わって当初よりもキャッチーなキーワードが一人歩きすると、もともとの構築プランは置き去りにされてしまいます。体制を変えずにエンジニアの役割や作業内容を変えて対応しようとすると、スキルセットが全然違うため壁にぶつかります。

③エンジニアを探す選択肢が少ない
社員でもお抱えベンダーのエンジニアでも稼働が空いているからと言って、スキルも評価せずにプロジェクトへ参画させることは明らかに間違っています。ゴリゴリの開発者なのに要件定義に充てたり、全く知らないシステムの障害調査に充てたり。
当然、期待通りの成果を出せるはずもなく、クレームが出ては優秀な人が尻拭いすることになります。その結果、優秀な人の本来タスクが遅れてしまい、あちこちにひずみが発生して被害が拡大していくという光景はよく見ます。
エンジニアを探す選択肢が少ない、またそこに手間を掛けないベンダーにありがちです。

スーパーエンジニアは諸刃の剣

エンジニアの中にはすごく優秀な人がいて、どんな領域でも設計も開発もテストも早いし品質も高い。このようなエンジニアがいるとプロジェクトは救われます。
ただし、このエンジニアに任せすぎるのは危険です。何かにつれて、それは彼に聞いてくださいと名があがり、あらゆる会議に顔を出している。チームリーダーが説明するのではなく、毎度スーパーエンジニアが説明している状況は、技術力の問題ではなく、体制の観点で問題があります。
スーパーエンジニアのおかげで円滑に進められる面もありますが、もしも、その人が離脱したらプロジェクトが止まってしまうようでは困ります。出来る人が何もかもやっていたらチームとは言えないため、極論を言ってしまえばチームリーダーの技術があろうがなかろうが、チームリーダーとしての役割を全うしてもらわなければいけません。
PMとしては、スーパーエンジニアに頼るのではなく、スーパーエンジニアを増やすことを考えるべきです。

体制図は役割と責任を表現する手段

文鎮型の体制が良しと言われた時期もありましたが、全員がリーダーというのは聞こえは良いですが悪く言えば責任も役割も不明確で、下手をするとクロスオーバーしまくりで非効率です。システム開発プロジェクトには、ピラミッド型の体制が適していると思いますが、チーム名が適当に付いていたり、各自の役割が曖昧だったりしたら文鎮型と同じです。
体制図は、役割と責任を表現する手段であるため、チームの守備範囲がわかるようなチーム名にすることや出来るだけ個人個人にも役割がわかるようなポジションネームを与えることが大切です。

体制の評価

プロジェクトが開始された後も定期的に体制を見直すことは必要です。
野球やサッカーなどプロのチームスポーツでは、調子が悪い選手は途中交代となり、チーム戦術にフィットしない選手の出番は減っていきます。成果が出なければ二軍へ降格することありますし、体力がない選手はいくら技術が高くてもスーパーサブのままです。システム開発プロジェクトで控えの選手を抱えておく余裕はないので皆がスタメンとなりますが、今のメンバーを時々再評価することは必要です。
スキルの低いエンジニアはリスクになりますが、長く在籍するエンジニアに経験値が集中することも危険です。スキルと経験値を天秤にかけるのではなく、長期的な視点で育成も含めたリソース計画と最良の体制であることのバランスを考えつつ、定期的に新陳代謝を図ることもプロジェクトマネージャーの仕事です。

イラスト：危うい体制となりがちなプロジェクト

①急に立ちあがる

②ゴールが途中で変わる

③エンジニアを探す選択肢が少ない

炎上診断チェックリスト（⑤体制）

⑤－1．チーミング
・全メンバーが記載された体制図がある
・守備範囲がわかるような意味のあるチーム名になっている
・主要なメンバーには責任が明確なポジション名が付いている
⑤－2．採用方法
・ポジションに必要なスキルを考慮して採用した（稼働が空いている人を入れた、馴染のベンダーの言いなり）
・優秀な人の紹介は優秀の論理でエンジニアを採用している
・定期的に新陳代謝を図ること考えている（体制見直しの機会を計画にいれている）
⑤－3．チームリーダー
・立場や役職、年齢によらずスキルから任命している
・チーム内の全ての報告・説明はリーダーが行っている（詳しいメンバーに説明してもらうことはない）
・チームリーダー任命時に後任育成やプロジェクト終了時までの責任を伝えている
・チームリーダーは５W1Hを明確にしてメンバーへ指示している
・構造的理解と説明ができる（全体でｘｘ、いくつに分類され、それぞれ何本など）
・レビューで正解を提供できるスキルと知識を持ち得ている
⑤－4．役割
・クライアント担当者の役割（誰が何を決定するか）を確認できている
・開発体制のマネジメント、PM、サブPM、PMOの役割とカウンターは明確に決まっている
⑤－5．開発メンバー
・開発メンバーの得手不得手を把握している
・主要な開発メンバーのプロジェクトでの達成目標を確認している
・長期的な視点で育成も含めたリソース計画をたてている

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！