烏合の衆をまとめ上げるリーダーシップ (2) 連載第7回

前回、フリーランスが一斉に集まってプロジェクトが始まった場合のリーダーシップについて取り上げました。これは1つの成功パターンとして理想のケースに該当するのですが、世の中あまたあるプロジェクトすべてがこうなるとは限りません。
例えば、炎上中のプロジェクトに外部からPM PLが招聘されてプロジェクトを立て直すといった事例もよく聞く話であります。こうしたケースにおいて、リーダーはどうやってプロジェクトの健全性を取り戻すのか、考察してみたいと思います。

炎上プロジェクトに火消し要員を招聘する、ということ

普段から付き合いのあるフリーランス同士が集まったプロジェクトで炎上した場合、関係者一同の総意として外部からリーダーを招聘するであろう、という前提として一旦本稿では考察の対象外とし、初見のメンバーだけで始まったプロジェクトにおいて、プロジェクトオーナーが現状を見かねて外部からリーダーを招聘したケースを想定することにします。

プロジェクトの途中で人をアサインする、ということは

人月の神話でフレデリック・ブルックスはこう書いています。

遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。

いわゆるブルックスの法則として有名ですね。ということは、メンバーであれリーダーであれ、誰かしらを追加要員としてアサインすると、必ずそのプロジェクトの進捗が遅延するのでしょうか。いいえ違います。単に既存のメンバーと同じスキルセットを持ったメンバーを追加でアサインしても、プロジェクトの状況説明や仕様のインプットなど、コミュニケーションの追加コストを支払う割に進捗しにくいことは事実ですが、こうした炎上プロジェクトにおいて単なる作業者を追加するのではなく、俯瞰して状況を観察し軌道修正を図れるリーダーを招聘することで、プロジェクトの立て直しを図るのです。

プロジェクトの途中でリーダーを招聘する際にプロジェクトオーナーがすべきこと

仮に、現在炎上しているプロジェクトにおいて
•既存のメンバーは自己のアウトプット、自己の責任を全うすることにしか興味がない
•メンバー間のコミュニケーションが皆無または少なく、それぞれがバラバラに品質や納期の調整をしたがる

こうした兆候が見受けられる場合、既存メンバーと同じタスクをこなすメンバーを追加アサインしたり、メンバーを総入れ替えしたりするよりも、まず全体を統括するリーダー招聘を検討しましょう。

プロジェクトオーナーは本来、プロジェクト全体を統括する立場ですが、ビジネス上の判断を技術者へ伝えたとしても、技術者が同じ温度感、同じ優先度でそれを理解できるとは限りません。ですので、ビジネス上の課題を正しく理解し、技術者が同じく理解できるようタスクの優先順位づけをしてプロジェクトのリカバリができるリーダーを招聘するべきです。

しかし、一方でビジネス上の課題と技術上の課題がイコールであるとは限らず、必ずしもビジネス上の課題がすべてに優先するとも限りません。ですので、プロジェクトオーナーはリーダーにイエスマン的な振る舞いは絶対に求めないでください。

炎上プロジェクトにリーダーを迎え入れたら最初にすること

炎上プロジェクトにリーダーを迎え入れることになったら、プロジェクトオーナーは最初に、次の4つを実行してください。
•リーダー招聘の理由説明とともに、オーナーがこれまで持っていた権限をリーダーに移譲した、という宣言をメンバー全員に(できれば同時に対面で)する
•招聘されたリーダーはメンバー全員に対して平等に接することを宣言する
•すべての作業はリーダーが承認してから行なうようルールづけする
•すべてのチケットは全員が平等に見えるようにする
以上の4つですが、目的は「今までのやり方ではうまくいかなかったという危機感を共有する」このたった1つです。

炎上プロジェクトにアサインされたリーダーのミッションとは

リーダーはまずメンバーの面倒ごとを巻き取ることから始める

炎上プロジェクトにアサインされたリーダーは、まず「コードを書く(実装する)以外のすべての面倒ごとをメンバーから巻き取る」つもりでメンバーと接することを強くおすすめします。

プロジェクトオーナーから招聘されたリーダーは、着任するまではオーナーの主観、ビジネス上の課題と現実の戦力にギャップがあるといったネガティブな情報しかもたらされていません。また、一方でメンバーからのインプットはゼロかそれに近い状態で着任するわけですから、客観的な事実を確認するためにも、まずメンバー全員から「面倒ごとを巻き取りたいので」という持ちかけかたでヒアリングを始めましょう。

もし、メンバーから集まった面倒ごとが、本当にビジネス上の課題として置き去りにされていたのであれば、まずそこから着手すべきという判断になるでしょうし、逆に、不要な面倒ごとに対して高い優先度が割り当てられていたのであれば、プロジェクトオーナーに「チームの総意として」これを諫言し、本来やるべきタスクの優先度を上げることができるよう調整するべきなのです。

リーダーはメンバーとの接し方に細心の注意を

さて、リーダーはプロジェクトの要請で参画したのですが、正しくは「プロジェクトオーナーの要請」であって、メンバーを含めた総意で迎え入れられたとは限りません。ですので、
•最初からメンバー全員の協力が得られるとは限らない
•メンバーからは、自分たちの利益ではなくオーナーの利益のために招聘されたと思われている可能性がある

この2点を充分念頭に置いて振る舞いましょう。また、もう1つ大事な着眼点があり、それは「既存メンバーは着任したばかりのリーダーが知らない情報を山のように持っている」ということです。こうした観点を踏まえ、リーダーはメンバーとの接し方に細心の注意をはらうべきなのです。

炎上したプロジェクトにおいては、往々にしてビジネス上の要求と技術的課題の狭間で、あるいは、メンバー間などで様々な対立がおこりがちです。こうした対立はとかく主観と主観のぶつかり合いに終始する傾向にあるので、常に客観的事実で判断し、最適な着地点を探し当てることが求められます。

プロジェクト再生における取捨選択

本稿でこれまで述べた、プロジェクトオーナーや新規着任したリーダーがやるべきことは、あくまで「取捨選択」の範囲で行う優先順位付けの整理です。炎上プロジェクトを救う銀の弾丸などない、と言うのは簡単ですが、限られた納期や予算の中でプロジェクト再生を行うには、ALL or NOTHINGの発想ではなく、まず取捨選択という発想をしましょう。

もちろん、時には今まで書いたコードのほとんどを捨てる選択をしなければならないこともあるでしょう。しかし、決してコードを書いた人を責めてはいけません。何故なら、最初から書きたくて捨てられてしまうクォリティのコードを書いたわけではないからです。

人間は感情の動物です。そして、社会性をもった動物でもあります。言い換えれば、正しい動機づけさえ行われて正当な社会的評価、承認欲求が満たされればプラスの結果へ向かいます。ですので、取捨選択の理由を人の資質に求めず、先ほども述べたように「今までのやり方ではうまくいかなかったという危機感を共有する」ことを繰り返し理解してもらうしかありません。

一方で、プロジェクトオーナーは「これだけ予算と期間をかけたのに」という執着を少なからず持っています。また、プロジェクトオーナーが上司や株主や顧客に対して説明責任を持っていることも多く、こうした焦燥感や不安感から、現実解とはかけ離れた要求を(リーダーを通じて)メンバーへ行うこともあるでしょう。

つまり、先ほど述べた「人間は感情の動物」「社会性をもった動物」というのは、プロジェクトオーナーにも当てはまるのです。しかし、こうした要求が果たして正当なのかどうかを判断し、プロジェクトオーナーを諌める必要すらあるのです。また、こうした局面において、感情に感情で処理しようとすると往々にして収集がつかなくなります。まったく感情を無視してドライに処理するわけにもいきませんが、必要以上に感情論に振り回されず、プロジェクトオーナーあるいはメンバー側のどちらにも偏らず、公平で客観的な判断が常に求められることを常に意識しましょう。

本記事におけるまとめ

•炎上プロジェクトの途中でメンバーを追加するのは基本的に費用対効果が薄い、が、正しく優先順位付けをした上で軌道修正ができるリーダーを招聘するのは有効である
•炎上プロジェクトにPM PLをアサインしたプロジェクトオーナーは、メンバー全員に対して「今までのやり方ではうまくいかなかったという危機感」を共有する
•招聘されたリーダーは、メンバー全員に対して平等に接し、メンバー全員からコーディング以外の面倒ごとを巻き取るつもりでヒアリングを行なうこと
•リーダーは、メンバーとの接し方に細心の注意を払うこと
•リーダーは、プロジェクトオーナー側やメンバー側のどちらにも偏らず、感情論に振り回されず公平で客観的な判断を行なう必要がある

間違いないチームマネジメント

競争的な市場の中でビジネスを加速させていくためには、強力なチームの存在が欠かせません。効果的なチームビルディング術や、チームでの共同作業に役立つツールやポイントを押さえることで、最高のチームを作り出しましょう。

詳細を確認する

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事