リーダー不在のプロジェクトをコントロールするために

「リーダー不在のプロジェクトが動き出してしまった…」
今回は、筆者が実際に経験した事例(とは言えNDAがあるのでフィクション仕立てにしています)から、リーダー不在のプロジェクトでどう舵取りをすればよいのかについて述べてみたいと思います。
最初に結論を書いてしまいますと、「結局のところ誰かがリーダーシップを発揮しないといけない」という現実解に行き着くのですが、プロジェクトの予算や座組のしかたによっては、リーダー不在のままプロジェクトがスタートしてしまう、といったケースも残念ながら存在します。
必ずしも下記図1のような座組がいけない、というわけではありませんが、このような座組でトラブルが長期化する(した)ケースというのは、おそらく経験がある方もいらっしゃるのではないでしょうか。

（図1 プロジェクトオーナーが技術者ではなく、プロジェクトオーナーとエンジニアの間にリーダーが不在なケース）

リーダー不在でおきたトラブル – 責任分界点上の障害発生 –

前章/図1のように、プロジェクトオーナーとエンジニアとの間にリーダーがいないプロジェクトの場合、下請各社の責任分界点に近い箇所で障害がおきたりすると、誰が初動の調査を行ない、障害被疑部位の切り分けを行ない対応するのか・・・が曖昧なために初動が遅れたり、「まずはネットワーク・サーバーエンジニアが初動対応をするのだろう」と暗黙のうちに決めてかかられたりしてA社の業務負荷のみが増えるといったことが起きたりします。

A社もB社も契約はプロジェクトオーナーと結んでいるため、本来ですとプロジェクトオーナー側に受入試験を行なうスキルのあるエンジニアがいて、PLおよびPM業務を行なうべきなのですが、プロジェクトオーナー側にこうしたエンジニアがいないと、障害発生時の対応負荷に偏りが発生し、「弊社で調査しましたが、弊社担当箇所に問題はなく、他社構築担当箇所が障害被疑部位と思われます」といったたらい回しが発生するリスクが高まります。

こうした体制ですと、A社とB社との間で協力して問題解決を行なうよりも「うちのせいじゃない」という責任回避に終始することにもなりかねず、技術的な、本質的な解決からは遠のくばかりで、これではプロジェクトオーナーも含め全員が不幸なままです。仮に、こうした体制において個人のエンジニアがどう頑張っても、自己犠牲の上に成り立つ解決しかできないので、いわゆる「スーパーエンジニアによる解決」が行われたとしても、彼がプロジェクトを離脱してしまうと同じ品質での解決は困難です。こうした属人的な解決が仮にできたとしても、それは組織としては不健全なままなので、プロジェクトオーナー側に技術のわかるPMやPLを立てるしかありません。

また、PMやPLを立てたから即ち解決、というわけにはいかず、運用設計や責任分界点も含めた契約の見直しすら必要になることもあります。

リーダー不在のプロジェクトをどう着地させるのか？ – 短期プロジェクトでメンバーができること –

1つのサービスやシステムを複数社で長年運用するようなケースですと、根本的にプロジェクトの体制や契約から見直すしかない、という結論でしたが、短期間のプロジェクトの場合はそうもいきません。少々乱暴な言い方になってしまいますが、「四の五の言わずさっさと手を動かしてプロジェクトを終わらせる」しか解決方法はなく、誰かが率先して社間のハンドリングも含めて実行するしかありません。

次に私が経験したケースですが、こちらも発注元企業の下に下請が複数社あり、下請各社はそれぞれ発注元企業との直接契約でしたので、下請各社間において商流の上下はありません。こうした体制であることをプロジェクト発足後に自社の営業から聞かされて作業に着手したのですが、どうやって案件の進行をハンドリングしてプロジェクトを完遂させたのかを振り返ってみたいと思います。

まずはキックオフミーティングを実施する

新たにプロダクトを作るなど、前向きに始まったプロジェクトではキックオフミーティングで士気を上げるといった話はよく聞きます。しかし、下請各社のうち、プロジェクトに積極的に関与する会社と運用フェーズであまり手を動かしたくない会社があるだろう、つまり社間でプロジェクト関与度や関心に温度差があるだろうという予想をしていたので、社間のコミュニケーションで如何にロスを減らすか、という目的をもってキックオフミーティング開催を各社にはたらきかけました。

もちろんこうした目的もあるのですが、リーダー不在のプロジェクトなど成功するわけがないという予想をしていたので、キックオフミーティングの場でイニシアティブを握り、プロジェクト推進をやりやすくしたいという狙いが本音でした。

仮にプロジェクトが進みだし(暗雲が立ち込めて)からこうした動きをしようにも、各社の足並みが揃う可能性は低く、プロジェクトのイニシアティブを握るチャンスはキックオフミーティングが最初で最後、かつ最大であると考えます。

各社にキックオフミーティングを持ちかける際に、1つだけ気をつけていただきたいのですが、こちらがあまり張り切った雰囲気で「キックオフミーティングしましょう！」という誘い方をしてしまうと、あまり熱意のない会社から敬遠されてしまいます。ファーストコンタクトの時点では相手の温度感はなかなかわからないと思いますので、硬軟使い分けて「まずは顔合わせしたいと思います」といったニュアンスでキックオフミーティングに参加してもらうのがよいでしょう。

キックオフミーティングは観察の場にしよう

キックオフミーティングでは、だいたい各社ともキーパーソンが集まるのが通例ですが、いわゆる「職位が上なのでキーパーソンとされている人」と「手を動かしたり上司のサポートをしたりしているために技術または業務に精通している“事実上の”キーパーソン」のうち、どちらのタイプが出席しているのかを見極めます。

また、こうしたプロジェクトでは、エンドユーザーの担当者が複数の下請企業の担当者に何度も同じ話をするのを嫌う傾向があります。なので、キックオフミーティングの場では、誰がエンドユーザーの担当者と一番長いつきあいをしているか、または一番信頼されている下請企業の担当者なのか、という見極めをし、その人を通じて顧客との調整をしてもらうという役割分担をお願いするのも1つの作戦です。

キックオフミーティングでこうした見極めができれば、

• 無駄のないレポートラインの確立
• 社間の利害調整の優先順位づけ

の道筋が見えてきます。

そして、キックオフミーティングの場では必ずプロジェクト進行中のコミュニケーション方法について調整しておきましょう。

プロジェクト進行中のコミュニケーションについて

複数社で進行するプロジェクトにおけるコミュニケーションでもっとも忌避すべきなのは、社間の情報連携漏れです。過去にはメーリングリストや手オペによる同報メールが主流でしたが、今はだいたい以下のコミュニケーションツールを使い分けています。

•Slack や ChatWork などのチャットツール
•Backlog や Redmine などのプロジェクト管理ソフト
•Google Drive や OneDrive for Business などでファイル共有

これらツールの基本的な使い方については割愛しますが、以下の運用ルールでコミュニケーションを図っていました。

•コミュニケーションツールは基本的にクラウドですぐに利用可能なものを選定し、構築コストをかけない。
•ツールの管理権限は選定した企業がもち、他社のアクセス権は基本的に平等な扱いとし、個別チャットは原則禁止する。ただし、一部センシティブなファイルのやり取りのみ例外とすることもある。
•ファイル共有にメールは使用せず、チャットツールにファイルのリンクを貼り付ける。

これらのルールは同報性と情報の公平性を保つ目的で考えて導入しました。これは、別の言い方をすると「コミュニケーションロスやコミュニケーションミスとそれをリカバリする工数を削減する」という目的でもあります。電子メールによるコミュニケーションを極力なくすことで、

•都度宛先やCC、BCCを設定したメール送信がなくなるため、誤送信リスクを無くすことができる
•電子メールの往復で何重にもついた引用文よりもチャットツールやBTSのほうが対応履歴などのテキスト検索がしやすい上に可読性も高い
•情報アクセスの権限はコミュニケーションツールへの招待時に決定し設定するので、都度のやりとりにおけるセキュリティリスクを減らすことができる

という効果がもたらされ、プロジェクトの進行が大きく前進しました。

こうしたツールの特性を理解し、キックオフミーティングで「こういうコミュニケーション方法でプロジェクトを進行しましょう」と提案することで、プロジェクト推進のイニシアティブを握ることすら可能になります。ただし、ツールの使用を強制することが目的になると、本末転倒です。

リーダー不在のプロジェクトでイニシアティブを握るメリットと学び

「他のメンバーより多く給料を貰っていないのに」「他社の面倒なんて見たくない」というネガティブな理由で、複数社間に跨るプロジェクトのリーダーシップを取りたくない、という方がいらっしゃるのは100も承知です。しかし、リーダー不在のプロジェクトで消耗するくらいなら、「早く終わらせる」というモチベーションでも構いませんので、リーダー不在のプロジェクトにアサインされたら、リーダーシップを買って出てみましょう。すると、以下のようなメリットがあります。

•洞察力が鍛えられる
•リーダーシップが鍛えられる
•人脈が外に広がる

プロジェクトそのものの成否にかかわらず、プロジェクトでのリーダーシップを買って出ることで、単なる「作業者」ではなく、ビジネスの要求をどうやって実装へ落とし込むか、プロジェクトの進行のために次に必要なタスクは何なのか、社間でどう協力していけばよいのか、という普段なかなか得ることのできない学びが得られるほか、自らの考えとハンドリング技術でプロジェクトが成功裏に終わると、これは自分の成果として誇ってよいと考えます。