Solution

役割分担型プロジェクト運営

　ソフトウェアプロジェクトは、さまざまなカルチャーを持つメンバから構成されている、小さな生態系（エコシステム）を設定する。その生態系には以下のような要素がある。
アリスター・コバーン『アジャイルソフトウェア開発』 144p
TOP > Solution > 役割分担型プロジェクト運営

概要

　受託開発型の中規模から大規模プロジェクトで適用されている役割分担型のプロジェクト運営を考察する。基本的には初期設計段階においてプロジェクトは成功するという確信（あるいは期待）を以って、プロジェクトは進行していく。途中段階あるいは最終段階において、なぜ最初の予想が外れてしまうのかの原因を探り、既に予想が外れた時点（いわゆる火を吹いた状態）においてのフォローアップを考える。

目的

　初期計画のずれ、見込み違い、それによる製作＆試験期間圧縮による品質の低下によりプロジェクトは悪化の一途をたどるが、これをよいイテレーションに変換するための方策を練る。
対症療法でしかないが、既にデスマーチ化したプロジェクトに対して、「初期設計の甘さ」を問い詰めても仕方がない。この場合には、劣悪な環境になってしまったプロジェクトに対する治療を行うことが最優先になる。できる限り、荒療治をしない形（人間関係を保つ形）でよい方向付け／修復を行う。

前提条件

　対処の適用範囲を明確にするために前提条件を列記してみる。
以上の４点を本対策の適用範囲とする。これらのいくつかの条件に反している場合には、本対策は適用できないし、適用したとしてもほとんど効果をなさないと考えられる。そういう場合には、別の対策（ときに荒療治）が必要になるだろう。

少し前提条件に詳しい説明をつけてみよう。

立て直すべきと会社が考えている

　現プロジェクトに対して、会社側がなんら対策を行わないと結論付けているのであれば、現プロジェクトは会社にとって捨て駒に過ぎない。この場合には、デスマーチ状態を回避することなく、プロジェクトメンバの健康面を気遣った対策を立てるのが第一であろう。会社側の思惑と顧客の思惑とが大きく乖離している場合は、現プロジェクトを「立て直す」という行動は無駄であることが多い。

メンバが現在の状況が劣悪と感じている

　プロジェクトメンバが、長時間の勤務や深夜や休日の出勤を苦にしていないならば、別の対策を立てるべきである。たとえば、プロジェクトのマネージャや責任者の意向にそぐわないチームメンバが、あえてデスマーチ状態を好み、そのままプロジェクトを続行しているのであれば、メンバ内からの自発的な改善を望むことはできない。この場合には、プロジェクトメンバの意識を本来の目的となる顧客や会社側の思惑に沿わせることが必要になる。

責任者が現在の状況を劣悪と感じている

　プロジェクトメンバだけでなく、プロジェクト責任者も現状が劣悪であると思っていなければいけない。たとえば、プロジェクトメンバに長時間勤務を強い、深夜や休日出勤を続けることによって、プロジェクトが進行できると信じているプロジェクト責任者には、このプロジェクトを改善する意志はない。この場合は、プロジェクト責任者の意識改善が必要であり、そうすることによって、プロジェクトメンバを含めたプロジェクト全体がよいイテレーションに変化していくだろう。

プロジェクトメンバの絶対数が足りている

　デスマーチプロジェクトの多くは、人海戦術的にプロジェクトメンバを多くしたときに発生する意思伝達の速度低下（あるいは恣意的な伝達遅延）が、問題となる。このために、プロジェクトメンバの絶対数は足りている、と考えられる。たとえば、正規に設計された仕様を実現するために、１０人と見積もりを出したプロジェクトに対して、５人しか投入しない場合には、別の対策を採る必要がある。予算は足りているが技術スタッフが不足しているために人員を確保できないのか、予算が足りないために少人数でプロジェクトを運営しなければならないのか、という問題に移る。

　よって、誰も（顧客や発注元は除く）がプロジェクトの状態が劣悪と考えているものの、諸条件によりデスマーチ状態を抜け出ることができない場合を考える。最終顧客の無理解や、発注元による無理なスケジューリングあるいは無計画性に対して、プロジェクトが対抗できる方策、できれば最終顧客や発注元を巻き込んだ形で改善できる方法を考えていく。

スターはいらない

　成功するプロジェクトを形作るために、管理者は時としてスター（高度なスキルを持ち、強力なリーダーシップと交渉能力を持った技術者）を求めるが、実際には、そのようなスター技術者はほとんどいない。たいていは、平均的なスタッフの組み合わせによって、競争力の高いアプリケーションをくみ上げなければならない。
　平均的なスキルを持つスタッフによって、プロジェクトが完結できない見込みがある高度な技術要素を持つプロジェクトならば、話は別であるが、大規模あるいは中規模プロジェクトに高度なスタッフが300人導入されることは実現不可能な話である。
　となれば、より平均的なスタッフ（幸運であれば、平均よりもわずかにスキルの高いスタッフ）を集めることによって、プロジェクトを成功させることが現実的である、ということになる。

救世主はいらない

　同じことはデスマーチプロジェクトにもいえる。数々のデスマーチを救う物語には、何らかのスキルを持ったスターが出てくる。危機に瀕している現実にある日、突然、スターが現れて危機を救ってくれる。実際に、そのような神話が形作られることもあり得るのだが、現実的ではない。救世主を期待していても、宝くじの当たるよりも低い確率でしか、現れないのでは、３つのうち１つしかスケジュール通りにいかないソフトウェア業界では、あてにできない。

中央集権的な存在はいらない

　アーキテクチャというソフトウェアのコア構造が明らかになったとき、アーキテクトというソフトウェアの中央集権的な存在が浮かび上がった。ひとりのアーキテクトが作成されるアプリケーション全体を把握して、全体がバランスよく動くように努める、という方式である。しかし、ここに誤算がある。総勢300人のプログラマの中央に位置するアーキテクトがひとりでよいのか。ひとりの頭脳でまかなうことができるのか。そして逆説的に言えば、300人のプログラマが集まっても、出来上がるソフトウェアは、ひとりの頭脳の中でしか整理しえない問題しか解決できないものなのか。
　おそらく、LunixのコアプログラマやRubyの作者がひとつのソフトウェアを統一させるという枠組みと、現実に何百万行もあるソースコードから成り立つ基幹ソフトウェア開発の枠組みは異なると思われる。
　ひとつの会社が、ひとりの社長の号令の下に動くのではない、と同様に、数百人で構成されるソフトウェア開発はひとりのアーキテクトや、ひとりの責任者によって成り立つものではないだろう。ひとりの責任者が見られる範囲はせいぜい１２人程度（ＸＰの最大人数、ソフトウェア職人に就く最大の弟子の数）と考えられる。

協調

　サッカーをたとえにすれば、ひとりのスター選手とそれを支える１０人の選手のチームと、スター選手はいないが１１人の平均を上回る選手のチームと、どちらが長期戦に強いか、という話に近い。チームリーダは必要かもしれないが、他の選手の手足を動かすわけにはいかない。ゴールキーパーは攻めにいきたいかもしれないが、ゴールを守る役目に徹しないとチームは負けてしまう。
　それぞれの役目を明確にした上で、それぞれの役目をこなす、そして、全体の協調を整えたところで、調和のとれたチーム、最終的には結果＝ソフトウェアができると想像できる。

役割分担

　ここで、役割分担型のプロジェクトにおける、それぞれの「役割」について再確認を行う。




　図のように、設計・製作・試験・構成管理の４つのチームは、強い協調関係にある。このグループを全体的に統括していくのがマネージャの役割となる。通常、うまくいっているプロジェクトではグループ内で自己組織化が正常に行われる。このために、マネージャが強力に介入することは少なくてよい。
　しかし、顧客からの仕様変更が多かったり、全体スケジュールが厳しくなったり、なんらかの理由によってグループ内の不和が発生した場合には、マネージャは強い介入によって、プロジェクトの正常化を求めなければいけない。

　通常、顧客とマネージャとプロジェクトメンバとの間は、協調関係にあり、顧客からの適度な仕様変更・追加、マネージャによるスケジュール管理の適度なプレッシャ、プロジェクト内の設計チームによるソフトウェアに対する適度な改善提案、製作チームによる改善案やツールの作成、試験チームと製作チーム間の適度な問題処理票のやり取り、が行われる。
　いくらかのプレッシャはプロジェクトの生産性や品質に貢献するが、多すぎるプレッシャは更に効率を悪くするだけである（「アジャイルソフトウェア開発」より）。幻想的なスターを求めないのであれば、責任と権限はほどよく分担するほうが優れたチームを形作ることができる。

次に、バランスの悪いために起きるデスマーチプロジェクトを具体的に考えてみる。

マネージャの権限が強大

　よく陥りやすいパターンとして、マネージャの権力が絶大であるプロジェクトがある。マネージャは顧客の協調関係（打ち合わせや仕様決定会議）を強く保ち、顧客と設計チームとのつながりが相対的に弱くなる。仕様を把握しづらい立場となる設計チームは、製作チームとの協調関係が薄くなり、存在意義が薄れてくる。結局、マネージャによる、設計の統制が行われ、よって、製作チームにもマネージャによる仕様の伝達が行われる。最終的に出来上がるソフトウェアの全体を把握している者は、マネージャを置いて他がなく、後継者を作ることはできない。



陥りやすいマネージャの性格としては、
があげられる。

　性格は容易に変えられるものではないし、時には統率されることを望むスタッフもいるので、いちがいにこのマネージャが悪いとはいえない。また、技術指向の高いマネージャの支配下に、技術指向の高いスタッフを置くと、推進力はきわめて高い。
　もっとも、長期的にプロジェクトを見たときには、教育効果が低いために後継者作りには向かない。

このマネージャによるデスマーチの悪循環は次のシナリオとなる。
  1. 顧客とマネージャの緊密度が高いために、マネージャがプロジェクト側よりも顧客に感情移入しやすくなる。
  2. スケジュールや仕様変更に対して、現実のプロジェクトよりも顧客に有利な形で計画を立てやすくなる。
  3. マネージャがプロジェクトメンバに対して、過度な期待（裏を返せば、身勝手なマネージャの思惑）をしすぎて、プロジェクトの進捗が悪くみえてくる。
  4. 平均的なプロジェクト運営から、楽観的な顧客の要望（24時間体制、人海戦術による増員による挽回、過度なスケジュール）を受け入れる確率が高くなり、メンバが疲弊する。
  5. マネージャは思ったとおりにプロジェクトが動かないために、リーダーやスタッフを叱り飛ばしたり、発奮（とマネージャは思っている）させることによって、進捗を回復しようとして、1へ戻る
　この場合、マネージャの権力を抑え、本来のプロジェクトの治癒能力を引き出せばよいので、対策としては、マネージャが複数のプロジェクトを担当して、特定プロジェクトに介入する絶対的な時間を減らす、とよい。そうすることによって、マネージャが介入する時間が減り、顧客との調節はプロジェクトの設計チームに戻り、元の協調関係へと戻っていく。
　ただし、既にデスマーチ状態となっているプロジェクトでは、巨大なマネージャ権力＝マネージャしか仕様を知らない、という状態になっているので、マネージャがいなくなるということは設計チームの主力がいなくなることに等しい。
　対策は、次のようにマネージャが持っている仕様（暗黙知）を、権限としてではなく単なる「字引」として、押さえ込むとよい。

　こうすることによって、マネージャは本来の仕事である顧客とのスケジュール調節、顧客から雨あられと振ってくれる仕様変更の調節、次プロジェクトの開拓、近視眼的ではない長期スケジュール（少なくとも3ヶ月先の予定）を立てることが可能になる。
　デスマーチ状態のプロジェクトに対して、マネージャができることは数少ない。高野フルーツパーラーのケーキを持ってきたり、なるべく目立たないようにプロジェクトを観察していることぐらいしかない。

設計者（リーダー）の権限が強大

　もうひとつ陥るパターンとして、設計チーム（あるいはリーダー）の権限が大きすぎる場合がある。マネージャが他のプロジェクトにかかりきりになってしまったり、過度にマネージャがリーダーに権限を持たせたりしたときに陥るパターンである。
　５人以下で構成される小規模のプロジェクトである場合、プロジェクトマネージャ兼リーダーとなる場合もあるので、このパターンにならないように注意する必要がある。
　マネージャの権限が強大であるパターンと同じように、もともと権限を持ちやすい立場にいる役割の人が、権限をそのまま行使するとリーダーがプロジェクトの進捗管理をしないといけないにもかかわらず、仕様の把握＆文書化をしないといけない、という情報が伝達されない状態になる。




陥りやすい設計者（リーダー）の性格や立場は、
となる。

　マネージメントとリーダー業務の混在（よく言われる、役職以上の責務を期待される風習）により、外向きの交渉（マネージメント）と内向きの交渉（リーダーシップ）とのバランスが取れなくなってしまっている例である。
　スタッフの中に新たなリーダーが出現しない限り、プロジェクトは形式的なリーダー（リーダー業務を放棄したリーダー）を中心に据えてしまうために、機動性が悪くなる。リーダーの指示待ちになるプロジェクトが出来上がる。

この設計者（リーダー）による、デスマーチシナリオは次のようになる。
  1. プロジェクトマネージャ兼リーダー、あるいは、リーダーがひとりの状態からプロジェクトが始まる。
  2. リーダーは、顧客との打ち合わせや仕様を煮詰めていく。
  3. ある程度、仕様が固まった段階で、仕様書の作成、プロトタイプのコーディングのためにスタッフを入れる。しかし、スタッフに伝承するのではなく、分担のみで別々の作業を行う。スタッフは、無難な部分を書きリーダーがチェックする方式をとる。
  4. コーディングが始まり、さらにスタッフを入れるが、仕様書を作成したスタッフも「よくわかっていない」ので、リーダーが手取り足取りしないとコードが進まない。やむなく、仕様書は全面的にリーダーが書くのだが、打ち合わせもあって満足な質にはならず、メーリングリストや議事録を使いながら断片的にスタッフに仕様を伝える。
  5. コーディングが終わる頃になって、仕様書の不足分（詳細性ではなく、網羅性が足りない）が見つかる。リーダーはスタッフを叱咤するが、「よくわからない」ままコーディングしているスタッフにとって、仕様はリーダーが握ったままなので、どうしようもない。
  6. 同様に、試験工程が始まっても、仕様の網羅性は保てない。既に、仕様書を書く暇はなくなっているので、再び4のように断片的に伝えるが、スタッフは理解しない。試験も任せることもできず、かといってコーディングも任せることができない状態となる。リーダーが仕様を握っている、という状態に陥る。

　ここでの最大の問題は、3でリーダーがスタッフに仕様の伝承を怠ったことにある。リーダーは過去１ヶ月の顧客との打ち合わせにより、基礎技術を勉強する時間もあり、顧客との意思疎通もはかれているのだが、途中からは入ったスタッフには何の前準備もない。おそらく、導入時におおまかなプロジェクト概要と周辺技術を１時間程度説明することが多いと思うが、そのような短期間では概要しか伝えることができない。導入段階では、あくまで概要を伝えるのみにとどめ、プロジェクト内で働くために必要な知識は、継続的に伝えておく必要がある。
　最初が間違っているので、4から6へ工程が進んだままでも間違えたままになる。
　このような方式でクリアできるプロジェクトの大きさは５人以下の小規模プロジェクトで、リーダーがひとりひとりのスタッフの動作を目で確認できる程度の大きさまでだろう。１０人以上になれば、作業分担をせざるを得ず、リーダーひとりでは全体を掌握することはできない。

　このような場合、対策は、早急に設計者をもうひとり育てることである。デスマーチ状態の場合、仕様書を書き直したり、詳細な設計を残したりする時間的な余裕がない状態になっているので、形式を求めることは不可能である。
　誰かひとりをピックアップ（一番最初にプロジェクトに入ったスタッフがよい）を対象にして、半日をかけてリーダーが知っている仕様をひとつひとつ確認していく。半日は、本来のリーダー業務に戻るとよい。

　プロジェクトリーダーの本来の仕事は、プロジェクトメンバが仕事をする際にフォローアップを行うコーチングである。プロジェクトリーダーが設計を行い、スタッフがコーディングを行う、新人が試験を行うというヒエラルキーが、このデスマーチを引き起こす。
　プロジェクトリーダーがリーダーシップを以って、プロジェクトメンバを牽引し、経験上技術スキルが足りないところがあればフォローアップし、配員が不足していると思えばマネージャと相談する、という中間管理をすることによって、避けられるリスクである。

製作者（リーダー）の権限が強大

　プロジェクトリーダーが技術指向であったり、マネージャとリーダーを兼務している場合に陥りやすいのが、製作チームの権限が強大になったてしまうパターンである。設計者（リーダー）のときと同様に、比較的小規模のプロジェクトで起こりやすい。また、中規模以上のプロジェクトではリーダーがスキルを過信していると、あっという間に取り返しのつかないデスマーチへと突入してしまう。



　設計者（リーダー）が強大になるパターンと違い、製作者（リーダー）が強大になる場合には問題が顕在化しにくい。これは、ある意味で成功するプロジェクトのパターンと考えられるからだと思われる。
　技術スキルのある人がプロジェクトリーダーを受け持った場合、顧客との仕様調節の場に出て仕様を把握し、ある程度の仕様書を残してスタッフと一緒に仕様書を作成（あるいは分担して作成）し、プロトタイプ製作を行うために製作者としてプロジェクト全体を牽引していく、というパターンは、一種のプロジェクト成功パターンである。
　しかし、よく図を眺めてほしい。このリーダは、顧客との打ち合わせで交渉能力を発揮し、設計で顧客の要件をひとつひとつ仕様書に書き起こし、さらに品質の高いプログラミングを行う能力のある「スター」ではないだろうか。スターは、平均的なプロジェクトでは現れることがない。ひょっとしてこのようなスター的なリーダーが現れたら疑いの目で見てほしい。偽装されたスターかもしれないからだ。

　自称スター型のリーダーが陥りやすい点を列挙してみよう。

陥りやすい製作者（リーダー）の性格＆性質は、
　マネージャを兼任してはいないが、プロジェクトを任されている信頼あるリーダーが陥りやすいパターンである。能力は悪くない、しかし、プロジェクトを運営させるとなぜかうまくいかない、という技術者が陥る落とし穴である。
  1. 技術スキルのあるリーダーが、技術調査も含めてプロジェクトを開始する。
  2. 技術調査を行い、ある程度の基礎設計（顧客の要件）をまとめる。
    設計書には非が見つからない。やや記述不足が見られるが時間の制約もあり特に問題は見つからない。
  3. 設計の中途段階、あるいは、設計の終わった段階でスタッフが入る。
    この場合、同程度のスキルを持つ勘のよいスタッフであれば問題はでない。しかし、平均的なスキルのスタッフを投入した場合、リーダーの描く設計イメージがスタッフに伝わらないまま、設計を進めていくことになる。難しい設計はリーダーが行い、無難な部分をスタッフが行う。
  4. 設計が終わり製作段階になると、リーダーは難しい設計を実装していく難しいコーディングに注力し始める。リーダーはスキルが高いので、実装も難なくクリアしてしまう。スタッフは無難なところをコーディングして一見、うまくいっているように思える。
  5. ところが、なんらかの要因で作業量が倍増した（設計漏れ、顧客の要望、工期の短縮など）ときには、スタッフは増員される。リーダーは難解なコーディングを仕上げる（あるいはデバッグ）するまで忙しい状態が続き、新しいスタッフへの説明もままならなくなる。
  6. せっかく増員したスタッフであるが、しばらく遊んでいる（仕事が割り当てられない）状態が続いてしまう。単純に工数を浪費してしまい、仕事はすすまず、リーダーが関わっている難しい設計と難しいコードは、他のスタッフには手が負えず素晴らしい設計は屑同然になる。
　一見、リーダーに非がないように見えるが、このリーダーはプロジェクト全体の技術レベルを合わせることを忘れ、自分の満足を達成させるために設計とコーディングを行っている。おそらく、リーダー自身には悪意はない。これによって自体はますます深刻になる。
　このような技術リーダーの場合には、プロジェクト全体のバランスをとる方法を伝えたほうがよい（トム・デマルコ「ゆとりの時間」より）。エンジン全開は研究プロジェクトの場所にとっておいて、かの人の技術を他のスタッフへ伝承するような役割を認識させるとよいだろう。
　自称スター型のリーダーは、好きなことができない手かせ足かせを感じるだろう。しかし、技術を相手に伝えることができないのであれば、その技術はリーダーひとりでしか活用できない、死んだ技術でしかない。常に新しい息吹を吹き込んで、イテレーションにより再生可能な技術にするためには、自らが育て上げた技術を伝承していくことが必要になる。

スタッフとリーダーとマネージャ

　よく聞かれる人材育成の方法として「現在の立場よりもひとつ上の役目を要求する」というものがある。たとえば、リーダーではないスタッフに対して、リーダーが行う仕事（品質管理やスケジュール調節）を要求したり、マネージャではないリーダーに対して、マネージャが行う仕事（顧客交渉、金額ベースのスケジューリング）を課したりする。
　これは弊害が多い。特に無難な小規模のプロジェクトではよいのだが、中規模以上のプロジェクトでは、スタッフはスタッフの仕事（コーディングや試験や設計）、リーダーはリーダーの仕事（プロジェクトの進捗管理や顧客の要件分析、スタッフのフォローアップ）、マネージャはマネージャの仕事（顧客との金額交渉、スケジュール交渉）があるので、リーダーがマネージャの仕事をすれば、リーダーが忙しくなり、スタッフがリーダーの仕事をすればスタッフが忙しくなりすぎて、それぞれに課せられた任務をまっとう出来なくなる。最終的に、マネージャは余った時間を何に使っているのかと見れば、コーディングをしていたりする。これでは本末転倒である。
　人材教育はＯＪＴ目標などを使って計画的・明示的にプロジェクト内に組み込まれたほうよいし、そうすることによってそれぞれの仕事分担が明確になるし、誰がどの役割を担っているのか、誰が越権行為を行っている（プロジェクト全体の調和を乱そうとしている）のかが、わかるようなる。

　おそらく、キャリアパスがスタッフ→リーダー→マネージャという一本しか用意されていないのが、デスマーチを作っている最大の要因かもしれない。会社が全面的に悪いとは言わないが、営業スキルを求められるマネージャタイプのパスだけではなく、ソフトウェア職人気質のような技術指向のプログラマのパスや、広くスタッフに教育を行うための指導スキルを持ったパスなど、各人においての長所が利用できるようなキャリアパスがあれば、現在のようなスタッフが最下位で、マネージャが最上位というヒエラルキー的な弊害を避けることができると思われる。
　スタッフからマネージャまでを含めて、相互に協調できる形でプロジェクトを運営し、デスマーチ状態から脱出できるのが、役割分担型のプロジェクト運営である。
copyleft by masuda.t