【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

デスマーチが起きる理由/anonymousさんへの回答 - 回答。

目次

回答。

第一弾

1.作業者の賃金を、固定費として考慮に入れない、としていますが、本当にこれでいいのでしょうか?例えば、会社中から優秀なプログラマを集めて行われたプロジェクトと、新人が一人だけでやったプロジェクト、この二つを同じコストとみなせるのでしょうか?

「人件費が固定費である」という点だけに注目しないでください。 重要なのは、人件費の割り当てが正しいかではなく、 スループットが最大化されているかということなのです。

2.前の質問と関連しますが、優秀なプログラマを他プロジェクトから引っ張り込んでもマネージャが責任を問われないなら、どのプロジェクトのマネージャも「うちこそ人が足りない!」と主張して、他から引き抜きはやろうとするけれど、自分のプロジェクトの人材を他に提供するようなことを許そうとはしないのではないでしょうか?

リソースマネジメントに対する理不尽な政治的妨害を避けるには、 現在の進捗度(クリティカルパスの何%が完了しているか)を基に、人員投入後のスループットを試算させて、 人員の投入によってどれだけプロジェクトの進捗を改善できるのか、数字を出させることです。

例えば、プロジェクトAでは人員の投入によって期間あたりのスループットが1.25倍になりました。 売上は変わりませんでしたが、開発期間が80%に短縮されたためです。

一方、プロジェクトBでは人員を投入しても期間あたりのスループットは全く変わりませんでした。 そのプロジェクトには、同じスキルを持つプログラマが、既に十分なだけ存在していたからです。

明らかに、前者は良いマネジメントであり、後者は悪いマネジメントです。 「どれだけのスループット向上があるか?」という観点から事前に確認することで、 前者の人員投入を積極的に行い、後者を拒否することができます。 たとえ、前者のほうが規模が小さく、後者のほうが規模が大きくても、スループットは嘘をつきません。

ちなみに、過去に行ったプロジェクトの『期間あたりのスループット』を算出することで、 各プロジェクトの生産性を客観的に比較することが出来ます。 これにより、成功したと思われていたプロジェクトが実は失敗しており、 たいして成功していなかったと思っていたプロジェクトが大成功と呼ぶべきものであったことが分かったりします。

3.プロジェクトの進捗への貢献度によって人を評価する、とのことですが、技術的な知識のないマネージャが、その貢献度を正しく評価できるのでしょうか?評価基準はコードの生産量?ステップ数?例えばシステム全体にかかわるデバイスドライバのバグを直そうとしているプログラマがいるとして、その人の作業の意味をマネージャが理解できなかったら?

技術的な知識のないマネージャが、技術的な知識を持っている人の意見を聞く限り、貢献度を正しく評価できるでしょう。

貢献度は、プロジェクトの関係者なら簡単に知ることができます。 それには「彼・彼女がいなくなったら、このプロジェクトはどれだけダメージを受けるだろうか?」と自問することです。

コードの生産量やステップ数には何の意味もありません。それは、走行距離で車の良さを評価するようなものです。 その考えでは、長距離トラックが最高の車であり、街乗り用の軽自動車は最低の車、ということになってしまいます。 長距離トラックだけを揃えれば、全てが上手くいくのでしょうか?言うまでも無く、そんな評価基準は間違いです!

ポイントは、個人の作業量や稼働率ではなく、仕事の流れや依存関係に注目することです。 流れが止まれば、生産性はゼロか、マイナスになってしまうのですから。(『ザ・ゴール』参照)

デバイスドライバのバグは、システム全体にかかわるものでしたね? だとすれば、デバイスドライバのバグを修正する作業は、『システム全体の進捗』に貢献しているはずです。 故に、そのプログラマが書いたコードが何行であるかに関わらず、そのプログラマを評価するべきだと言えます。

4.下に書いたような、人員の抱えすぎを抑止するために、何か方法が存在するでしょうか?例えば、人員を多く抱えすぎて、予定より早く終わりそうなプロジェクトがあったとしても、そのマネージャは人員の抱えすぎが露見することを恐れて、わざと進捗を遅らせるでしょうから、プロジェクトの終了時期を見ても人材の抱えすぎは発見できないと思います。

スループットの前では、そういう小細工は不可能です。

第二弾

私の質問が不明確だったようですので、質問をやり直させていただきます。私はこのページの趣旨と違い、人件費をプロジェクト単位で集計すべきだと考えているのです。

1.人件費を固定費とみなし、プロジェクトのマネージメントから外すとすると、社内の人員の総数は一定ですから、マネージャによる人員の獲得はゼロサム競争になってしまい、人員の抱えすぎを抑止する方法が無くなってしまうのではないでしょうか?

2.それを抑止するために、マネージャのさらに上の経営者層による、プロジェクトの優先順位の判断が行われるとのことですが、その判断基準は結局「スループット」です。スループットを正しく測定することはしばしば不可能だ、と私は思うのです。例えば(1)技術的に高度でマネージャに理解できない場合、(2)この小説のように社内向けのシステムで、直接の売上を持たない場合、などです。どうでしょうか?

3.以上の問題を解決するには、結局元の通り、人件費をプロジェクトのコスト計算に含めるようにするしかないのではないでしょうか?

いいえ。これらの問題は全く問題にはならないか、あるいは、解決可能な問題です。

4.さらに補足的な内容です。プログラマの能力の客観的な評価すら非常に難しいのに、マネージャの能力やプロジェクトの優先順位を客観的に評価する方法があるとは、私には思えません。スループットなどという客観評価の指標は現実には成立しないでしょう。結局、プログラマやマネージャの政治力の大小で評価は決まってしまうのではないでしょうか?

「プログラマの能力の客観的な評価」は不可能です。世界で最も優れたプログラマは誰?という質問にさえ、 答えが何通りも考えられることからも、それは明らかです。

しかし、「プログラマの能力の相対的な評価」は簡単ですし、大抵はそれで客観的な評価に代えることができます。 彼ら一人ひとりに、こう聞いてみればいいのです。

「このプロジェクトの中で、自分より優れていると思うプログラマは? 反対に、自分と同じくらいか、それ以下だと思うプログラマは?  (この質問への回答は匿名で行われ、他のメンバーに知られることはありません)」

プログラマの名前を書いたカードをそのとおりに並べ替えていけば、評価ははっきりするでしょう。

第三弾

1.人材の追加の前後におけるスループットの変化によって、そのプロジェクトに実際に人材追加が必要だったかどうかを査定する、とのことですが、では追加ではなく、プロジェクトの当初から参加するべき人数を見積もる場合はどうでしょうか?当初から人数が多すぎた場合、それを外部から見破る方法はないと思います。人数が多すぎる疑いをかけられ、人員を引き抜かれた場合、マネージャはスループットを下げて「ほら見ろ、うちは人数はちょうどピッタリだったんだ。人を戻せ」と主張することになるでしょう。

質問の前提として、プロジェクトの開始時から終了時まで人員数が一定であるプロジェクトを仮定しているようですが、 そういったプロジェクトはリソースマネジメントの観点から見て、大きな無駄を抱えているプロジェクトだと思います。

普通、プロジェクトはいくつかの段階を経るものです。まず、要求定義や基本仕様策定の段階では、少数のプロフェッショナルだけが関わります。 次に、徐々に実装の詳細が見えてくるにつれ、プロジェクト遂行に必要なスキルを持ったプログラマをプロジェクトに割り当てていくことになります。

この段階で、『スループットを考慮しつつ、人員を追加していく』ことが出来るようになるはずです。

最後に、(デスマーチにならずに)作業のピークを過ぎたプロジェクトでは、人員を減らす余裕が出来てくるはずです。

人月計算の概念そのままに、最初から必要になるであろう人員を全て用意してしまおうというやりかたは、 『当初から人数が多すぎた場合、それを外部から見破る方法はない』ですし、『人員を引き抜けないため、新規のプロジェクトが開始できない』といった状況を招くことになり、 決して得策では無いと考えます。必要になったとき、必要なだけ追加していくと良いのではないでしょうか。

2.そもそもこの理論は、スループットを完全に定量的に(おそらくは金額ベースで)、そして客観的に査定することが可能だとする前提に基づいています。私はそれは不可能だと思います。例えば、システムの根幹にかかわるデバイスドライバのスループットはいくらですか?これ単体では納品はできませんから、金額ではゼロです。よって正当な評価のためには、金額のみでなく、プログラマ同士の評価といった計量しがたい基準を取り入れる必要がありますが、これは定量どころか、順序すら付けがたい極めてデリケートなものだと思います。これで果たしてプロジェクトのスループットの変化をパーセンテージで示せるでしょうか?大幅に恣意が入り込む余地が存在していると思うのですが。

それはどちらかというと、スループットではなく、制約条件(ボトルネック)の話です。

例えば、デバイスドライバのバグによってプロジェクトの進捗が制限されてしまう状況を考えます。 (TOCでは、これを『デバイスドライバの工程が制約条件となっている』と言います)

プロジェクト全体のスループットがデバイスドライバに依存してしまっているわけですから、この状況でデバイスドライバのプログラマに休まれたりすると、 デバイスドライバのバグのせいでメンバー全員が仕事にならなくなってしまうかもしれません(スループットはゼロ)。

あるいはもっと性質の悪いことに、『一見仕事は続けられるように見えるけれど、在庫を作っているだけでスループットには貢献できていない』 状態になってしまうかもしれません。このとき、スループットはマイナスになります。

仕事をすればするだけスループットが増えるように錯覚しがちですが、実際には、在庫(現時点では必要でないドキュメントやソースコード)を増やしたぶんだけ 管理の手間が増え、修正にかかる時間が増加し、将来のスループットを減らしてしまうことになります。 これはトヨタなどでは作りすぎのムダと呼ばれています。直接顧客のためにならないことに工数を消費している状態です。

さて、こういう状況(制約条件の発生)が、デバイスドライバの工程にどれくらい起きるのか?という点が重要です。 (なお、これは定量的に評価できる回数です) もし毎日、または、数日に一回の割合で起きるのであれば、明らかにデバイスドライバの工程が制約条件になってしまっています。 ここを改善しないと、プロジェクトの進捗は改善できません。マネージャーは、いくつかの方法を検討できます。

プログラマの評価に直接繋がるのは2だけですが、全てに共通するのはプログラマの負荷が減ると言うことです。 ボトルネックの負荷を減らせば、仕事がスムーズに流れ始め、スループットは増加します。

なお、プロジェクトのスループットの変化については、『クリティカルチェーン』の一読をお勧めします。

3.他の疑問です。(1)『ザ・ゴール』は未読ですが、すべてのプロジェクトに共通のボトルネックを共同で解決すべし、よって人材をボトルネックにまず集中すべし、というテーマだと聞いております。つまり、ソフトウェア業界のように、しばしばマネージャ同士がゼロサムの競争をしている場合は成り立たない議論ではないでしょうか?(2)ブルックス『人月の神話』には、追加の人員は無駄である、それは技術が足りないからではなく、仕様の理解に多くの時間が必要だからだ、と書かれています。私の実経験でも、それは正しいと思います。この小説では、なぜ人材の追加で問題が解決できるのでしょうか?

仕様を全て理解するために、多くの時間がかかるという点は事実です。 しかし、『何故、多くの時間がかかるのでしょうか?』 経験によれば、デスマーチに陥ったプロジェクトには以下の特徴があります。

もちろんこれらは、あらゆる人員投入を失敗させる要因に成り得ます。

重要な点は、メンバーがスループットやボトルネックの考え方を知っており、何が生産的であり、何が生産的でないかを理解していることです。

デバイスドライバの工程がボトルネックであり、プロジェクト全体のスループット向上のためにはデバイスドライバ工程への 人員追加の成功が必須なのだとマネージャーとメンバーが良く理解しているとします。

投入した人員により、1ヵ月後にプロジェクト全体のスループットに6割の増加(1+0.6、ということ)が見込めるなら、 マネージャーや他のメンバーはデバイスドライバ工程を積極的にサポートするべきですし、 デバイスドライバのプログラマは仮に自分の時間の何割かを割いてでも、教育を行うべきだと結論されるでしょう。

第四弾

(1)ウォーターフォールのフェーズが変わるごとに、新たな人員が必要になりますが、その獲得しすぎを抑制する方法がないのでは?

JIT流人員投入。

適正な人員投入を行うための最も簡単な解決策は、JITが推奨しているようにプロジェクトを常に人員が不足する状況にしておき、 誰かが悲鳴を上げるまで放置しておくことです。 そして、悲鳴を聞いたら、どんなスキルを持った人員を投入して欲しいのか正確に聞き出し、必要とされている人員を確実に投入するのです。

残念ながらこの方法は導入時にメンバーの反感を買いやすく、また、人員を確実に投入できるだけの人事体制も必要になります。 JITは在庫管理の手法としては優秀なのですが、人員の管理のためのアプローチとして活用することは難しいと言えます。 (マネージャーとの強い信頼関係が無いと、悲鳴を上げる前に辞めていく人さえ出てくるでしょう。)

TOC流人員投入。

より良い方法として考えられるのは、プロジェクトのフェーズごとに工程間、作業間の 依存関係を表現できるスケジュール表(PERT図などがこれに該当します)を作成し、 事前にどこがクリティカルパス(最も長い経路)になるのかを確認しておくことです。

 【クリティカルパスの例】
  
 ----->----->----->----->----->----->----->----->----->-----> 時間
  [___10日___]─┐
         [___10日___]→[____15日____]──[完成](←最長経路は15日+10日+15日なので、クリティカルパスは40日となる)
 [____15日____]─┘      ↑
        [__5日_]────┘(←この工程はクリティカルパスではない)
  
  
  [___10日___]─┐
         [___10日___]→[____15日____]──[完成](←クリティカルパスが遅れると確実にプロジェクトの完了が遅れる)
 [____15日____]─┘      ↑
        [___9日___]-──┘(←仮にこの工程が遅れても、クリティカルパスに食い込まない程度ならば問題ではない)

クリティカルパスの進捗が遅れず、非クリティカルパスがクリティカルパスに食い込まなければ、プロジェクト完了日は守られます。 そこで、クリティカルパスには多めに人員を配置し、非クリティカルパスに配置する人員は少なめに(不足するように)配置しておくのです。

その後、スケジュール表を更新していき、もし非クリティカルパスがクリティカルパスに 食い込む可能性が出てきた場合には、対処不能な状況になる前に人員を追加投入します。

(2−1)ドキュメント・教育などの引継ぎのためのコストは、もし人員が不足しなかった場合無駄になるのでは?

(1)の方法を採用した場合、人員は将来不足するように計画的に投入され、必要になるたびに追加投入されていくわけですから、 「もし人員が不足しなかった場合」というのは杞憂です。(1)の方法では、人員の追加投入が前提となります。

(2−2)また、XPの隆盛と逆行するやりかたなのでは?

XPが否定しているのは、ソースコードと同じことを説明しているドキュメントの存在です。 (基本的に、手作業で行うソースコードとドキュメントの同期作業には 時間と集中力が必要となり、スループットを低下させます。在庫はスループットを減少させるのです)

XPは、ソースコードからは理解することが出来ない情報 (システムの概要、モジュールの構成、用語の定義、インフラの設定方法、等) をドキュメント化すること自体は否定していません。 (とはいえ、XPが「仕様書」という体裁に拘っていないことは確かです。)

XPの基本方針の一つは、「本当に必要になるか分からないものは、作らない」というものです。 (これは Just In Time 方式 の考え方に通じるものがあります。)

つまり、本当に必要な(スループットに貢献する)ドキュメントならば、書く。 実は書く必要の無い(スループットに貢献しない)ドキュメントなら、書かない。 という実益ベースの姿勢こそが、XPの根底に流れる精神なのです。

(3)結局、スループットは客観的な測定は可能なのでしょうか?

クリティカルパスの概念(※)を正確に理解し、PERT図等を利用することで、 スループットの客観的な測定は可能です。

PERT図を使い始めると、おそらくスループットが思うように伸びない事態に直面するでしょう。 多くの職場には以下の問題があるため、スループットの向上が阻害されることがあるのです。

これらはTOCでは方針制約と呼ばれ、利益やスループットに基づく根拠を持たないまま、 多くの企業で慣習として行われているものです。方針制約はスループットを減少させる 方向に働くため、スループットを向上させ、利益を上げるためには、方針制約の発生源(中核的な問題 Core problem)を取り除く必要があります。

最近では「クリティカル・チェーン」を図で解説した書籍がいくつか出ていますので、 そういったものを利用して、クリティカルパスやスループットへの理解を深めることをお勧めします。

また、中核的な問題(Core problem)を発見するためには、TOCの「思考プロセス」が利用できます。

※重要な考え方は、非クリティカルパスの工程が多少遅れたからといって、 それを非難すべきではないという点です。 なぜなら、その遅れはスケジュール上の余裕に吸収され、 全体のスループットに全く影響しないからです

(4)マネージャに限らず、社員が個人の利益の最大化を目指すのは当然のことで、それできちんと会社が運営できるような制度を作るべきなのではないでしょうか?

もちろん資本主義社会において、社員が個人の利益の最大化を目指すことは当然です。 しかし、企業が成功するためには、社員が自社の利益の最大化を考えて行動してくれることが必要です。 一見、二つの考えは対立しているように見えますが、そうではありません。

必要とされているのは、「自社の利益の最大化を目指す」ことが、「社員が個人の利益の最大化を目指す」ことと一致する、そんな制度です。 この時、コストをベースにした評価制度ではしばしば矛盾が引き起こされてしまいますが、 スループットをベースにした評価制度は、目的の一致を促す可能性を秘めていると言えます。

例を見てください。

コストを評価基準としている企業「ローコスト・コーポレーション」。 スループットを評価基準としている企業「ハイスループット・コーポレーション」。 この二つの企業はライバル同士です。

両社の技術部で改善案が提案されました。 この案は確実に自社の利益になり、また、別の3つの部門の利益にもなる、いいことずくめの案です。 しかし、問題が一つあります。コストを負担するのは技術部なのです。

さて、両社の技術部のマネージャーは、この改善案を部門間会議で提案したのでしょうか?

ローコスト・コーポレーション技術部のマネージャー、コストカット氏は、この改善案を報告しませんでした。 なぜなら、ローコスト・コーポレーションでは、部門ごとのコストに応じた評価を行っているからです。

コストカット氏「報告しなくて当たり前だろう!技術部のコストが増える案など提案すれば、私の評価は下がってしまうじゃないか!」

一方、ハイスループット・コーポレーション技術部のマネージャー、プロフィット氏は、この改善案を報告しました。 ハイスループット・コーポレーションでは、部門ごとのスループットに応じた評価を行っているためです。

プロフィット氏「報告して当然です!3つの部署のスループット、ひいては自社のスループットを増やすこの案を提案すれば、私の評価は上がるのですから!」

両社では、こんなことが毎日続くのです。どちらが多くの利益を得られる、成功した企業になると思いますか?