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

デスマーチが起きる理由 - 3つの指標

差分表示


3つの指標

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。
まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。
それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。
それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。
あの馬鹿どもめ。一体何を考えているんだ?

スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。

「遅れてすまない」

そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。
何より、ホワイトボードは真っ白だった。ミーティングは、まだ始まっていなかったのだ。
十数人の同僚たちが私を見つめる中、見慣れない男――背は低く、おせじにもカッコいい奴には見えない――がこちらを見ていることに気づいた。

「あなたがコンサルタントの方ですか?」

私の質問に彼は頷いた。

「その通り。私はジョナサン。君はトム君だったね。すぐ来ると聞いて、君を待っていた。さあ、ミーティングを始めよう。大切なミーティングだ」

彼は矢継ぎ早にそう言うと、中央に戻っていった。何が大切なミーティングだ――席に座って私は思う。こんなものは時間を無駄にしているに過ぎない。

「ミーティングを始めるにあたって、まず現状を確認したい。もらった資料は少し古くなっているからね。誰か、現状を説明してもらえないだろうか」

そう言われて立ち上がったのはアレクサンドだった。少し融通の利かないところはあるが、かなり頭の切れる奴だ。私も一目置いている。

「この販売管理システム開発プロジェクトは、2月の頭から開始しました。当初のプロジェクト完了予定日は、7月末。
つまり、開発期間は6ヶ月と見積もられていました。しかし、今がいつであるかお分かりでしょう。既に10月の半ば……つまり2ヶ月半の遅れが出ています。
早急な……一刻も早い対策が望まれます」

彼の言っていることは、このミーティングに来ている連中ならみんな理解している。理解していないのはあのコンサルタントだけだ。

「一つ質問させてもらいたい。今、『早急な』『一刻も早く』と言ったが、何故なんだね?正確な理由を教えてくれないか」

もう着席するつもりでいたアレクサンドは、突然の質問に少し面食らったようだったが、即座に答えた。

「それは……来年一月からの運用が予定されているからです。運用時にバグが出るといけませんから、最低でも1ヶ月のテスト期間が必要です。
ですから、11月末までには開発フェイズを完了させなければいけません」

それも、みんな分かっていることだ。とにかく時間が足りない。毎日残業しても、まだ足りない。せめて運用が4月あたりに先延ばしになってくれれば、何とかなるのだが。

「状況を整理してみよう。当初は6ヶ月の開発期間を予定していたプロジェクトだが、2ヶ月半もの遅れが出ている。
結論から言えば、これまでに行ってきたであろうマネジメントは、有効に機能していなかったということだ。
誤解を与えないように言っておくが、君たちを責めているわけじゃない。責任だとか、上下関係だとか、そんなことはどうでもいい。
問題は開発の遅れで、我々は解決策を探さなくてはいけない……このミーティングはそのためのものだからね」

私は、資料を眺めるふりをした。馬鹿げたミーティングだ。このプロジェクトを救えるはずが無い。我々は解決策を探さなくてはいけない。
そんなことを言うだけなら誰にだってできる。猿にだって言える。私の上司にだって言えるだろう。……いや、言えないかもしれない。

そんなことを考えていたため、少しの間、彼の言葉は耳に入らなかった。顔を上げると、彼がプロジェクターで何かのスライドを表示するところだった。

-『デスマーチ』の現状問題構造ツリー http://www.mikihoshi.com/wiki/index.cgi?page=%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1

「努力、友情、勝利」と書かれたスライドが現れて、彼の御高説が始まるのかと思っていたが、そうではなかった。
表示されたのは、何の変哲も無い付箋紙を矢印で結んだだけの、ツリーだった。上にはデスマーチと書いてある。まさにこのプロジェクトのことだ。

「これは何ですか?」

私の変わりにステーシーが質問した。彼女は知らないことを人に尋ねるのが得意だ。様々な分野の知識を持っている彼女にも、どうやら知らないことがあるらしい。彼はゆっくりと答えた。

「デスマーチの現状問題構造ツリーだ」

「人は、自分が問題を認識していると思っている。全ての前提は頭の中に入っていて、自分は正しい判断をしているのだと信じている。
誰もが自分が一番プロジェクトの役に立っているのだと考えている。
自分が一番難しいモジュールを開発していて、だから一番残業していて、もちろんこのプロジェクトは最大限効率的なのだと信じている。
しかし、私はこう思う。『本当にそうだろうか?』と」

彼が何を言っているのか、最初、よく分からなかった。だが、暗に自分たちの努力を否定されているのだと気づくのに、そう時間はかからなかった。
みんなも同じだったようだ。すぐに、「そんなはずはない」「何を考えているんだ」「俺たちを非難しにきたのか」と野次が飛んだ。

「では、」彼は、小柄な彼は、まるで聞き分けのない学生たちをなだめる教授のような口調で言った。

「確かめてみようじゃないかね?」


「『''必要な時に必要なだけのスキルを持った開発者を投入しないと、プロジェクトは遅れる''』」彼は言った。そんなこと常識だ。
「これが常識だということは理解してもらえると思う。だが、私がこれまでに見てきたほとんどのプロジェクトでは、
実際にこの常識を尊重してプロジェクト運営が行われているとは言い難い状況だった」

何だって?この常識が守られていない? 言われてみれば……確かにそうだ。

――今、うちの会社で一番問題になっているのは、営業部門だ。とはいっても、今期の営業成績が特に悪かったというわけではない。
大手顧客のほとんどから同じ苦情を言われている、と言えばお分かりだろうか。要するにレスポンスタイムの改善を要求されているのだ。

噂では、速やかに改善しなければ、オーダーを減らすとまで言われたらしい。
まるで脅されているようなものだが、営業部門の業務にかなり時間がかかっていることは否定できない。
そこで、改善計画が持ち上がり、システム部門に話が回ってきたというわけだ。

大量に使われていた紙の書類を減らし、必要な情報全てをデータベースに登録し、情報にどこからでもアクセスできるようにして迅速な営業を顧客に約束する。
そのためにこのプロジェクトは始まった。これっぽっちの人数で、なかなかどうして、社運を賭けたプロジェクトじゃないか。

しかしだからこそ、システムの運用が遅れれば顧客の信用を失い、売上の減少に直結すると言える。

この販売管理システムの開発が始まったとき、私は管理職の連中に、
ユーザ代表と話し合って仕様を決めるSEの数が足りないと不満を言ったことがある。そのとき、彼らは何をしてくれただろう。何もしてくれなかった。

必要な時に必要なだけのスキルを持った開発者を投入してくれなかった。この常識が守られていなかったから、このプロジェクトは遅れたというのか?

もし1月の運用に間に合わなければ、プロジェクトマネージャーの首が飛ぶことは間違い無い。おそらくプロジェクト関係者の昇進の話も無くなるだろう。
そして私も……私は知らずにペンを握り締めていたことに気づいた。

「『''管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする''』」

一瞬、彼が超能力者でないかと疑った。彼の口から漏れた言葉は、まさに私の考えていたことだったからだ。
その妄想を振り払ってスライドを見ると、彼の持つ棒(どこから引っ張り出したのだろう?)の先には、そう書かれた付箋紙があった。彼の問いかける声が耳に入った。

「『''必要な時に必要なだけのスキルを持った開発者を投入しないと、プロジェクトは遅れる''』のに、
『''管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする''』。
これは明らかに矛盾している。こう考えてみよう。『この矛盾は、何故、生まれるのだろうか?』
……ステートメント(付箋紙)の続きを見てみてくれないか。
『''管理者は新たな人員の追加に極めて慎重である''』というやつだ。これには同意してもらえると思う。そして、その下にもステートメントがある」

言われて、ステートメントを辿る。すぐに3つのステートメントが目に入った。

-『''プロジェクト単位でコスト(主に人件費)が集計され黒字or赤字が判断される''』
-『''プロジェクトが赤字であると判断されると追加投資(人員増加)が認められない場合がある''』
-『''プロジェクトが赤字であると判断されると管理者の立場が危うくなる''』

最後のステートメントの控えめな表現に、みんなが笑った。吹き出してしまった奴までいる。私も、ここまで控えめな表現は見たことが無い。

みんながステートメントに十分目を通せるだけの時間を置いてから、ジョナサンは口を開いた。

「君たちの会社では、ごく一般的なプロジェクト管理を行っていると思う。
だから『''プロジェクト単位でコスト(主に人件費)が集計され黒字or赤字が判断される''』にあてはまっているはずだ。
また、『''プロジェクトが赤字であると判断されると追加投資(人員増加)が認められない場合がある''』にも覚えがあるだろう。
特にルールが無くても、管理者自身がそう決めている場合もある。
そして最後に、『''プロジェクトが赤字であると判断されると管理者の立場が危うくなる''』だ。特に反論は無いと思う」

その言葉に、みんなが頷いた。もちろんそうだ。みんな常識じゃないか。

「さて、それぞれのステートメントは常識的なことに過ぎないが、下から上に、矢印を辿って読んでみよう。問題が見えてくるはずだ」

本当だろうか?一つ一つのステートメントに違和感は無かったように思うが……私は言われた通りに下から上へと視線を移動させる。
それにあわせるように、ジョナサンはステートメントを読み上げた。

「もし、『''プロジェクト単位でコスト(主に人件費)が集計され黒字or赤字が判断される''』
かつ『''プロジェクトが赤字であると判断されると追加投資(人員増加)が認められない場合がある''』
かつ『''プロジェクトが赤字であると判断されると管理者の立場が危うくなる''』であるとき、
『''管理者は新たな人員の追加に極めて慎重である''』……ということにはならないかな?」

彼はまた、みんなの理解を待った。

「同様に、もし、管理者から見て『''プロジェクト遂行に十分なだけの人員が存在しているように見える''』
かつ『''管理者は新たな人員の追加に極めて慎重である''』とき、
『''管理者は遅れているプロジェクトに必要なスキルを持った開発者を追加することを先延ばしにする''』」

この因果関係にも異論は無い。

少しの間、沈黙があった。みんな、現状を理解しようと考え込んでいるのが分かる。
一つ一つはたわいもない常識だ。
だが、このステートメントの流れはなんというか、嫌な感じがする。

「ところで、『''プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する''』という事について考えてみよう。
コミュニケーションや資料作成が無駄だと言っているわけではない、ただ、善悪とは無関係にそういう傾向が存在していることは認めてもらえると思う」

その意見に、みんなが頷いた。
私は、またスライドを見た。こんなに真剣にスライドを見たミーティングは、何年ぶりだろうか。右側のステートメントに目を通す。

「何故だろうか?トム、ツリーを読み上げてくれないか」

いきなりのご指名にいささか狼狽しながらも、私は立った。みんなの顔を見渡して僅かに時間を稼ぎ、その間に考えをまとめる。よし。私は意を決して口を開いた。

「いいでしょう、ジョナサン。『''何故だろうか?''』との質問ですが、理由はこのツリーを見れば明らかです。
まず、『''顧客は納期遅れが不満であり、管理者に絶対の納期厳守を要求する''』という当然のイベントが発生します。
私たちのプロジェクトの場合、顧客の部分は営業部門であり、より大局的な視点では経営者であるということになります。
次に、『''管理者は慌てて([[スキル]]を問わずに)開発者をかき集め、遅れているプロジェクトに投入する''』ということになります。
これに加えて、『''[[スキル]]が低すぎる開発者は[[スキル]]が高い開発者の時間を奪い、明らかに足を引っ張ることさえある''』
かつ『''一度動員した開発者をプロジェクトのメンバーから除外することは困難''』
かつ『''プロジェクト内での上下関係は職場の上下関係を反映しており、プロジェクト遂行のために最適化されているとは言い難い''』とすれば、
『''プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する''』ことは明白です」

言い終わって、みんなの視線を一心に集めていることに気づいた。どうして私なんかに注目するのだ?なんとなく気まずさを感じながら、私はそのまま着席した。
やれやれ、こういうのは学生時代だけで十分だ。

----

「話をまとめてみよう。トムの読み上げてくれたツリーから分かることは、スキルを問わずに『''多数の人員を投入すればするほど、プロジェクトは非効率的になっていく''』ということだ。それでは納期は守れない」

マネージャー補佐のヨハンが、ジョナサンの言葉に納得出来ない様子で立ち上がった。

「いいや、私は、その前提のほうが間違いだと思うよ。まったくナンセンスだ」

吐き捨てるような言葉に、私は愕然とした。私が読み上げたツリーの内容を、ヨハンはまだ理解していないのだろうか……それとも、理解したくないのだろうか。

ヨハンは言った。

「確かに『''管理者は新たな人員の追加に極めて慎重である''』が、遅れているならそれをカバーするのは、当然のことじゃないか。人が足りていないからなんだろう?なら、外部から人を連れてくれば良い。これで、『''プロジェクト遂行に十分なだけの人員が存在している''』」

「実際は、プロジェクト遂行に十分なだけの人員はいません」

アレクサンドが、はっきりとした口調で言った。

「今のままでは何もかも不十分です。特に、Bモジュールの進捗の遅れをカバー出来るスキルを持った開発者が足りていないんです!」

最後のほうは、プロジェクトのメンバー全員が上げた悲鳴のようだった。

「よろしい。つまり、開発者の視点では『''プロジェクト遂行に必要となる必須スキルを持った開発者が十分に存在していない''』ということだ。
一方、トムの読み上げてくれたツリーから分かることは、スキルを問わずに『''多数の人員を投入すればするほど、プロジェクトは非効率的になっていく''』というわけだから、
従って、『''開発側が求めているのは、少数の高スキル開発者の投入''』だということになる。アレクサンド、そうだね?」

先ほどは声を荒げたアレクサンドだったが、今のジョナサンの言葉には満足したようだ。

「ええ、その通りです」

予期せぬ理解者の登場に、彼の声はもう和らいでいた。

「さて、『''少数の高スキル開発者の投入''』このマネジメントが行えない理由はあるかな?」

ジョナサンはそう言うと、私たちの顔を見渡した。答えたのはヨハンだった。

「理由はもちろんあります。いいですか、人員の投入には、コストがかかります。
高スキルの開発者をプロジェクトに投入するには、非常に多くのコストがかかるんです。
今でさえ赤字ぎりぎりのプロジェクトなんですよ。もしそんなことをすれば、プロジェクトは一気に赤字になるでしょう。
マネジメントの本質は、納期と予算の両方を守ることです。そのバランスが大切なんです。高スキル開発者の追加は一切認められません」

ヨハンは、アレクサンドをちらりと見やった。信じられないほど冷酷な目だった。

開発期間とコストの両方を守るだと?ならばこのプロジェクトの遅れは何だと言うのだ。メンバーの努力が足りないとでも言うつもりなのか。

彼の言葉に、みんながざわめき出した。それを遮るように、ジョナサンが言った。

「よろしい。つまり、管理者の視点では『''コスト(人件費)の極端な増加を避けるため、遅れているプロジェクトへの人員追加を行う際には単価の安い低スキル開発者が優先される''』。
……このプロジェクトには確かに矛盾が存在している。開発者にも、管理者にも、どちらにも言い分がある。大きな対立だ」

彼はホワイトボードに図を書き始めた。

「予算と納期、これが矛盾の原因だと、私は思う」

-コスト対スループット ? 対立解消図(Cloud) http://www.mikihoshi.com/wiki/index.cgi?page=%A5%B3%A5%B9%A5%C8%C2%D0%A5%B9%A5%EB%A1%BC%A5%D7%A5%C3%A5%C8

「ツリーのほうを見れば、それは明らかだ。プロジェクトに遅れがでないようにしたい、これは顧客と開発者の望むマネジメントだ。
反対に、予算をオーバーしないようにしたい、これが管理者の望むマネジメントだ」

ジョナサンは、対立解消図に『対立』と文字を書き足し、より鮮明に対立関係を伝えようとする。

「だが、管理者の行動方針に関しては疑問が残る。
彼らは始めのうちは予算を重視している。しかしプロジェクトが大幅に遅れていることを顧客に責められると、
予算を無視してでも納期に間に合わせようとして、大量の人員投入を行う。ここで、『''予算を守る''』という方針を、あっさり捨てているのは何故かね?」

「……私たちがこれまで上手くマネジメントできていなかったのは、この矛盾と関係があるということですか?
もしこの矛盾が解消できれば、マネジメントは上手くいくと?」

ヨハンが、彼をまっすぐ見つめて質問した。

ジョナサンは、冷静さを崩さない。

「予算を守ろうとする考え方は、納期を守ろうとする考え方と、相容れないように思える。二つの方針は矛盾している。真っ向から対立している。
私はそれが、問題の本質だと思う。
しかし、」

ジョナサンは言った。

「考え方が対立しているように見えるからと言って、本当に対立しているとは限らない。大抵は、どちらか考え方の前提が間違っているだけであることがほとんどだ」

そう言って、またステートメントを書き足す。

『''プロジェクト単位にコスト(人件費)を集計することは正しい''』

しばらく、そのステートメントにみんなの視線が集中した。今の今まで、疑ったことなど一度も無かった。みんな当然の前提と思っていたことだ。
あたりまえの常識だったはずのことだ。これが、間違っているかもしれないとでも言うのだろうか。馬鹿げている。だが、もし、そうだったなら?どういうことになるのだ?

みんな黙ってしまった。


長い沈黙の後、普段はあまり喋らないボブが、躊躇いがちに口を開いた。

「一つ、いいですか」

----

「私は、会計を専門に学んできました。ですから、コストについてはここにいるみんなよりも多少分かっているつもりです」

会計? ボブが会計を勉強していたなんて初耳だ。

「続けたまえ」

ジョナサンが言った。

「知っている人も多いでしょうが、コストには、変動費と、固定費があります。これは原価計算の基本的な考え方です。
まず変動費はその名の通り、変動するコストです。変動は生産量に比例する、と定義されています。次に固定費ですが、これは固定しているコストです。
生産量がどれだけ変化しようと、固定費は変わりません。生産量が0でも、固定費は発生します」

「それが?私たちとどう関係があるの?」

ステーシーが言った。

「まあ最後まで聞いてみようじゃないか」

アレクサンドがフォローする。

「変動費は、製品のコストとして製品原価の中に集計されます。製品を作るために使ったコストを製品に集計するのですから、この集計には確かな根拠があります。
一方、固定費ですが、これは製品を作った量に比例して変動したりすることはありません。
マネジメントをどれだけ頑張ったとしても、常に一定額支払われることが決まっているコストです。

ですから、『''固定費を製品のコストとして製品原価の中に集計することには、正当な根拠が無い''』ということです」

「当然のことだな。固定費を製品コストに割り振ろうとすると、少なからず誤差が出る。

設備投資などをして固定費が大きくなればなるほど、その誤差は増える。
そうやって誤差が大きくなれば一部の製品の原価は高くなりすぎて、製品価格も高くなりすぎ、製品は売れなくなる」

ヨハンが自分の知識をひけらかすように言った。

「常識だ」

私はボブの言う原価計算の話を聞きながら考えていた。ボブの言ってくれたことが、どうプロジェクトのコスト計算に繋がるだろうか。まだ分からない。

「どの業界でも、コストの中でとりわけ多いのが、人件費です。考えてみてください。
アルバイトやパートタイマーなら時間給で雇うことができます。ジョナサンのような一時雇いのコンサルタントも……変動費として扱うことができると思います。
しかし、社員はどうでしょうか。社員の給料は、企業全体で見れば、常に一定額支払われることが決まっているコストです。
ボーナス等で多少上下はしますが、それほど大きく変動するわけではありません。
つまり、社員や長期契約の契約社員・派遣社員に支払うコストは、『''人件費は固定費''』なんです。
ですから、先ほどの製造業の常識をこの業界にあてはめると、『''人件費をプロジェクトのコストとしてプロジェクト単位に集計することには、正当な根拠が無い''』
ということになりませんか?」

会議室は、水を打ったように静まり返った。みんな、ボブが言ったことに矛盾が無いかと考えているのだろう。
いや、矛盾を探そうとするよりも、直感を働かせればいい。毎月会社が払う人件費は、プロジェクトに投入した人員の数に比例しない。
当然じゃないか。ボブの言ったことにはどこにも矛盾が無い。ボブの意見は、正しい。

最初に口を開いたのは、なんとヨハンだった。「間違っている」彼は怒りに震えて言った。

「『''プロジェクト単位にコスト(人件費)を集計することは間違っている''』。ボブの言っていることが正しい。私の使っているコスト計算方法は間違っている!」

自分たちが間違った常識を信じていたのだと、もうみんな理解していた。ヨハンはジョナサンのほうに振り向いて言った。

「どうすればいい?どうすればもっと上手くマネジメントできるんだ!?」

今にも掴みかからんばかりの勢いだった。それでも、ジョナサンはポーカーフェイスだった。小さく、しかしはっきりとした声が、会議室に響いた。

「簡単なことだ。とても簡単なことだ。間違った前提に従っていたなら、前提を変えてみればいい」

ああそうか。私は唐突に彼の冷静さの理由を理解した。ジョナサンにとっては、常識が間違っていることなど、あたりまえのことなのだろう。

----

「先に進む前に、『''プロジェクト単位にコスト(人件費)を集計することは間違っている''』という仮定について、もう少し考えてみたい。いいかね?」

みんなが頷くのを見て、ジョナサンは言葉を続ける。

「ボブの説明では、変動費と固定費という用語が使われたが、より原価計算の定義に正確に言うのであれば、直接費と間接費という言い方も出来る。
直接費と間接費は相対的な概念で、ある視点で見た場合にコストの発生と相関を持つか否かによってどちらに分類されるか変わってくる」

「''今までのプロジェクトマネジメント手法の大きな間違い''は、本来であれば企業全体の間接費として考えなければならない固定的な人件費を、
あたかも直接費であるかのようにプロジェクト単位に集計してきた点にある。『''人件費はその大部分が固定費・間接費である''』という事実を無視し、
『''プロジェクト単位にコスト(人件費)を集計する''』とき、『''コストの配賦誤差が大きくなりすぎて、正しいマネジメントの障害になる''』ということだ」

「一つ、面白い質問をしよう。''今まで別の仕事をやっていた雇用済みの人員をプロジェクトに参加させた。企業の支払うコストは、増えるだろうか?''」

そう問われて、ヨハンは答えた。

「増えません」

言ってしまってから、自分で言った言葉が信じられないような、苦い顔をしている。

「そうだ。コストは増えない。''プロジェクト単位のコスト集計''が生み出す『''コスト増の妄想''』は、こんな基本的なことさえ忘れさせてしまう。
二つ目の質問だ。''プロジェクトに参加していたメンバーをプロジェクトから外した。企業の支払うコストは、減るだろうか?''」

今度は、私のほうに質問が飛んできた。このくらいの質問になら、答えられる。

「減りません。ただし、そのメンバーがプロジェクトの期間だけ雇われている臨時雇用の人員でなければ、ですが」

「そのとおり。見せ掛けのコスト削減を理由にプロジェクトのメンバーを減らしたところで、『''コスト節約は妄想''』でしかない。
最後の質問だ。ステーシー、答えてくれないか。
''プロジェクトAに参加しているメンバー2人とプロジェクトBに参加しているメンバー1人を交換した。企業の支払うコストは、変わるだろうか?''」

ステーシーは流暢に答えた。

「もちろん変わりません」

続けて言う。

「しかし、非現実的です。ジョナサン、私にはあなたの言っていることが机上の空論であるようにしか思えません。
まるで、別のプロジェクトから開発者を引っ張って来ることが出来ると思われているように聞こえますが、そんなことは不可能です。
現実として、高スキルプログラマはどのプロジェクトでも足りていません。頭を下げたって断られるのがオチです。
それなのに……あなたは魔法でも使おうと言うんですか?」

ふと、私はアイスコーヒーを見た。もうすっかり氷は溶けてしまっている。魔法か。そんなものは存在しない。
物理法則は誰にも変えられない。好き勝手に時間を遡ることも出来ない。魔法などというものは存在しない。当たり前のことだ。
当たり前だって? 私は自嘲する。今日は信じていた常識が崩れた日じゃないか。もしかしたら、魔法だってあるのかもしれない。
しかしどうして、私たちは常識が間違っていることに気付けなかったのだろうか。

私たちに無くて、ジョナサンにあるものは、何だったのだろう。何が違ったのだろう。彼は部外者だった。だから常識の間違いに気付くことが出来たというのか?
いや、違う。この業界には毎年、別の業界からたくさんの人間が流れ込んできているのだ。それは理由ではない。

だとしたら、違いは何だ。あの常識を書いた付箋紙を寄せ集めたツリー。ジョナサンは確か、現状問題構造ツリーと呼んでいた。
あれが、違いなのだろうか。問題の真因を突き止めるのに、あれを使ったのではなかったか。
そしてホワイトボードに書かれた図、対立解消図。前提を考え、正しい判断をするために、あれを使ったのではなかったか。
もし、物理法則を変えずに、現実を今より良くするための手法があるとしたら。ジョナサンが、それを知っているのだとしたら。

「この世界に魔法など存在しないよ。しかし、銀の弾丸(魔法の解決策)が無いわけでもない」

ジョナサンの言葉に、ステーシーは眉をひそめた。

----

「少し脱線するが、いいかね。ちょっとした御伽噺の話をしよう。狼男を殺す銀の弾丸の話だ」

「まさか……」アレクサンドが呟いた。

私も信じられない。『人月の神話』は読んで知っている。だが、まさか、本当にあるというのか?そんなものが。

「この業界で働くもので知らない人はいないと思うが、『狼人間を撃つ銀の弾はない』とブルックスは書いた。
これは、ソフトウェア・プロジェクトの困難性はソフトウェアの複雑性や人間であるが故の不確定性によるものであり、
技術的なアプローチによる魔法の解決策は無い、という意味だ。この言葉が言われてから、20年以上が過ぎた。
オブジェクト指向の発展により彼の予言の一部は外れたが、その他のほとんどの洞察に満ちた言葉は、
今日のソフトウェア・プロジェクトにもそのまま当てはまっている。もちろん、人月計算も」

「では『銀の弾丸』は、技術的なアプローチではないと?」ステーシーが言った。
「少なくとも……」ジョナサンは小さく笑う。

「ブルックスはそう書いている。銀の弾丸などこの世界のどこにも存在しないのだと宣言しているわけでは、決して無い。
彼はこの業界の絶望を望んでいない。現状の改善を諦めることを推奨するためにあの論文を書いたのではない。
『銀の弾丸』が、技術的アプローチ以外の分野に確かに存在するのだと信じて、あの論文は書かれたのだと思う。
あの言葉は、パンドラの箱の最後にあったものだ。それは一見災厄そのもののように見えるが、その実、希望なのだよ」

そう言って、ジョナサンは少し目を閉じた。

「続けてください」アレクサンドが言った。「技術的なものでなくてもかまいません。もし知っているのなら、教えてください。『銀の弾丸』とは何なのですか」

私は何も言えなかった。『人月の神話』を読んで、あのとき私は自分を笑った。こんな業界にいるなんて、俺はなんて馬鹿なんだろうと。
そして本棚の奥にあの本を突っ込んで、……私は何をしたのだろうか。私は毎日、ただ悪態を吐いていた。考えることもせずに。

ジョナサンが目を開く。

「狼男を殺すという『銀の弾丸』とは何だろうか? 言葉と実体を結びつけるとき、重要なのは''定義''だ。
少し英語を知っていれば分かることだが、『銀の弾丸』は『魔法の解決策』の代名詞だ。しかし、そこで立ち止まってしまっては意味が無い。
さらに問うてみよう。
『解決策』とは何だろうか? それは、問題を解決するための策、アイデア、ひらめき、そういうものだ。
容易には理解できない、複雑にもつれあった事象を整理したり、誰も解けなかった問題を一段上の視点から判断し、結論を出したりすることだ。
通常、『解決策』を行使することによって、良くない現状を改善することが出来る。ただし、条件がある。
『魔法のように劇的に』問題を解決する『解決策』でなければならない。それが、『魔法』の『解決策』、『銀の弾丸』の定義だ」

ホワイトボードに、ツリーが描かれる。

前提条件ツリー

-目標 『銀の弾丸=魔法の解決策』
--前提 『魔法の』
---前提の前提 『容易には信じられない方法、常識の対極にある方法』
---前提の前提 『劇的な効果』
--前提 『解決策』
---前提の前提 『現状が改善される策、アイデア、ひらめき』
---補足 『容易には理解できない、複雑にもつれあった事象を整理する』
---補足 『誰も解けなかった問題を一段上の視点から判断し、結論を出す』

「やっぱり魔法じゃないですか」ステーシーが茶化す。

「いや、魔法ではない。
『''部外者が問題を解決する過程を無視して結果だけを取り出すから、魔法に見えてしまう''』だけだ。例を挙げよう」

「14世紀、あるところに嘘吐き男がいた。彼は若かった。いつも夢を見ていて、口ばっかりで、非現実的な話ばかりを約束して、貴族たちの援助を受けようと必死に駆けずり回っていた。
彼がどんなに壮大な嘘をついていたのか教えよう。『''地球を逆向きにぐるりと一巡りして、スパイスの宝庫、アジアに辿り着いてみせましょう!''』」

みんなが笑った。コロンブスの話だ。

「彼は、本人が自覚していたかどうかはさておき、アメリカ大陸を発見した――すくなくとも、そこが怪物の待ち受ける海の果てではないことを証明した。
『聞いたかい!あの嘘吐き男が、今まで誰も知らなかった世界があることを発見したんだってよ!』
『へえ、海の果てに出航して帰ってきたのかい!だが、また、どうせいつものホラ話だろう』
『いいや、それがな、女王の前で、持ち帰った宝を見せたらしい』『なんとまあ!』ああ、それはまるで、魔法のような話だ。結果だけを見れば」

私は訊いた。「コロンブスは、自分が正しいと信じていたのですか?」

「もちろん。彼はある天文学者に出会い、地球は丸いと確信していた。
そして丸いのであれば、直径の計算に多少の誤差があったとしても、反対側を回ればいずれ目的地に辿り着く。
彼が考え、実行したことには、どこにも矛盾など無かった。どうしようもないほどの正論だった」

「ならどうして、貴族たちはコロンブスを支持しなかったのかしら?」ステーシーの疑問は、みんなの疑問を代弁していた。

ジョナサンは棒でツリーを指す。

「簡単なことだよ。それが『''容易には信じられない方法、常識の対極にある方法''』だったからだ」

誰もが納得していた。コスト計算にしたってそうだ。常識が間違っていると言われて、''はいそうですか''で済むはずが無い。
だとすると……、やはりあのツリーや図は只者ではないということになる。コスト計算に関する私たちの常識を改めさせたのだから。

ジョナサンは棒をスライドさせ、話を続ける。

「コロンブスは、結果が『''劇的な効果''』をもたらすと分かっていた。当時、新航路の発見は国を挙げての一大事業だったためだ。
そして、新航路の発見はまさに『''解決策''』だった。『''現状が改善される策、アイデア、ひらめき''』、それは、『''地球を逆向きにぐるりと一巡り''』することだった。
さて、ここで一つ質問しよう。''これは魔法かな?''」

誰も答えない。分かりきった質問に、間違うのが怖いのだろうか。私は答えた。

「いいえ。コロンブスがやったことは魔法ではありません。『銀の弾丸』も魔法ではありません。
しかし、魔法で無いとしたら、一体何と言ったらいいのか……」

「『劇的な結果』だけを取り出したなら、それは『魔法』だ。しかし、やっている本人にとっては、それは魔法ではない。
常識の積み重ねの上に成り立つ、合理的な判断に過ぎないというわけだ。
いわゆる『銀の弾丸』は『劇的な結果』である『魔法の解決策』の代名詞だが、私たちの求めているのは『コロンブスが使った魔法の解決策』ではなく、
『''私たちだけの常識外れな解決策を作り出す方法''』だ。それこそが『''銀の弾丸''』と呼ぶに足るものだ。そうは思わないかね?」

みんなが頷いた。もう誰も、銀の弾丸が無いとは思っていないようだ。見つけてやろう。そんな気持ちになっている。

「さて、御伽噺はこれでおしまいだ。楽しんでくれたようで何より。では、現実のプロジェクトに戻ろう。
コスト計算に関する質問は後で受け付けよう。今の問題は『''高スキルプログラマが不足している''』ことだ。
ステーシー、『''高スキルプログラマが不足している''』理由を、ぜひ聞かせてくれないかな?」

「ええ、もちろん」

----

「理由は、『''別のプロジェクトも遅れている''』ということです。ですから、別のプロジェクトから開発者を引っ張ってくるなんて無理なんです」

その言葉に、私はため息をついた。そうだ。別のプロジェクトも遅れている。そうして結局、振り出しに戻るのだ……本当に?

違う。上手く言葉にならないが……違和感を感じる。まるでバグが残ったソースを見たときのような気分だ。この感覚を無視してはならないと、プログラマとしての勘が告げている。

ふと、ジョナサンの言葉が頭を過ぎった。『本当にそうだろうか?』

「ステーシー、それは違うんじゃないかな」知らずに、私の口が動いていた。「『一番遅れているプロジェクト』は、常に一つだと思う。
だとしたら、比較的遅れていないプロジェクトから開発者を引っ張ってくることが出来ない理由は、ほかにあるんじゃないか?」

「そんなはずは無いわ。いつだってそう言って、別のプロジェクトのマネージャーは開発者の再配置を許可しないのよ」

ステーシーは譲らない。ステーシーはいい加減なことを言ったりしない。別のプロジェクトのマネージャーは本当にいつもそう言っているのだろう。
それでも、何か別の理由があるはずだ。ステーシーが何か言おうとするのを制して、ヨハンがその理由を答えた。

「マネージャーの言い分のことなら私に聞いてくれ。今だから言えるが、『''高スキルプログラマの柔軟な活用が出来ない''』のは、
『''高スキルプログラマ多少余裕が出来ても、マネージャーはそれを隠そうとする''』からだと思う。
どうしてそんなことをするのかなんて聞かないでくれよ。今まで話してきたことだ。『''プロジェクト単位のコスト集計の悪影響''』だよ。
もしプロジェクトに余裕があるなんて知られようものなら、あらゆる方面から圧力がかかる。まったくコスト削減の圧力といったら、凄まじいものだよ。
『''メンバーを減らしてコストを減らし利益を上げろ!''』この方針に反論などしようものなら、あっという間にクビを切られる」

「でも、『''プロジェクトに参加していたメンバーをプロジェクトから外してもコストは減らない''』のだから、それは全く理不尽な圧力です。馬鹿げています。
こんな理不尽な状況では、『''高スキルプログラマ多少余裕が出来ても、マネージャーはそれを隠そうとする''』のも、もっともな話です」

ああ、明日は雪が降るかもしれない。まさかアレクサンドがヨハンを弁護するシーンが見られるとは。
ボブも、何か言いたいようだ。

「他にも理由があります。これはマネジメントとしては些細な問題に見えるかもしれませんが、本人にとっては重大な話です。
通常プロジェクトは、全てが同じ場所で行われているわけではありません。そうすると、プロジェクトを移る場合、当然引っ越しを行う必要が出てきます。
この引っ越しの費用は、どこから出るとお思いですか?今のシステムでは、全部開発者の自腹です。
それだけではありません。引っ越し先に家具が足りていなかったら?インターネット回線が引かれていなかったら?恋人や家族と離れ離れになったら?
『これは社の命令だ。抵抗は無意味だ』とでも言うのですか?
現状では、会社を恨みながらも、渋々引っ越しに同意する開発者がほとんどです。
高スキル開発者の中には、こういった待遇が苦痛で、辞めてしまう者もいます。これも『''高スキルプログラマの柔軟な活用が出来ない''』理由です」

「残業も同じだ。残業で家庭を壊して、自分の身体を壊して、会社のために真面目に働く人間なんているはずがない。
無茶をすれば、高スキルプログラマから辞めていくことになる。それは一年後かもしれないし、明日かもしれない」

私も補足する。まるで言いたい放題だ。
ヨハンも唖然としている。今まで、開発者の負担がどんなに重大な意味を持つか、考えたことも無かったのだろう。ジョナサンが、まるで会話でもするように話した。

「どこだってそうさ。どこだって『''マネージャーと開発者の間で、マネジメントとして捉える範囲が異なっている''』ものだ。
ここで、『それは経理の問題だ』とか『それは就業規則の問題だ』と責任転嫁するのは簡単だ。
『そんなことをプロジェクトマネジメントの対象と考えるのは非常識だ』と一蹴するのも簡単だ。難しいのは、『変えよう』と考えることだ」

「そうですね」ヨハンは、噛み締めるように繰り返す。「本当にそうです」

「現状のシステムを変えなければ、高スキルプログラマを活用することなんて出来ない。変えなければいけません」

深刻な空気になりそうだった会議室の雰囲気を変えたのは、ステーシーだった。

「思ったのですが、『''高スキルプログラマが不足している''』理由はそれだけではないかもしれません。
当然ですが、高スキルプログラマの全てが最初から高スキルプログラマだったというわけではありません。
普通のプログラマが、経験を重ねて、高スキルプログラマになるんです。少なくとも、本来はそうあるべきなんです。
ですから、『''開発者の教育が思うように進まない''』という問題もあるのでは?」

確かにそうだ。もちろん、『教育が大切だ』などという陳腐な台詞は、この業界でも十年以上前から言われている。
だが、実際に短期間で開発者のスキルを上げる方法は確立されていない。上司に命令されて嫌々受ける社員研修制度に至っては、
悪口しか聞いたことが無いほどだ。

ジョナサンが、一つ質問をする。

「開発者の努力不足という個人的な問題は、確かに存在するのかもしれない。
しかし、ここにいる人間は別に努力が嫌いというわけではないはずだ。一体、開発者は何故努力しないんだね?」

誰も答えない。たまりかねて、私が答える。

「『''開発者の努力(作業の効率化)が正しく評価されない''』からです。もし努力すると、どういうことになるか説明しましょう。

開発者が努力して、作業を効率化したとします。すると、その開発者は普通より早く仕事が終わりますから、少し手が空いた状態になるんです。
ところで、『''分業が進んでいる職場では、プログラマがプログラミング以外の仕事をすることは許されない''』ため、
他の人の仕事を待つ必要が出てきてしまいます。憶測でコードを書くことも出来ますが……『''仕様が決まっていないのにコードを書いても、どうせ作り直し''』になります。やるだけ無駄です。
さて、暇そうにしている開発者の元に、次の仕事が回ってきます。開発者はその仕事も片付けます。
ここで、『''より多くの仕事が回ってくるようになっても、それに比例するほどには評価は上がらない''』点が問題です」

ホワイトボードにペンを走らせながら、ジョナサンが言う。

「仮に、''作業あたりの評価 = 評価 / 作業量'' と定義すると、むしろ作業あたりの評価は下がる、というわけかね」

「そうです。そこにマネージャーがやってきて、手持ち無沙汰になった開発者を注意するんです。
『皆が忙しそうにしているのに、君は何をしているんだね。仕事をしないのならクビだ!!!』
でも実際は、その開発者が一番仕事をしていたりするんです。それは進捗表を見れば誰だって分かることです」

ヨハンが言った。

「『暇そうにしている』『よく手が止まっている』といった『''感情的な視点で開発者を評価してはいけない''』ということか……」

ジョナサンが、ペンを置いた。見ると、ホワイトボードにはツリーが書きあがっている。これを見れば、問題は一目瞭然だ。

-『高スキルプログラマが不足している』の現状問題構造ツリー http://www.mikihoshi.com/wiki/wema.cgi?page=2004071812140030499

全員が、ツリーを凝視した。どこにも矛盾が無いとしたら、この中に一番の問題があるに違いない。

ヨハンが唸るように呟いた。「評価基準だ……全ての原因はそれだ。『''人は、自分がどう評価されるかに従って行動する''』んだ。
問題は人をそうさせてしまうシステムだったんだ。
ジョナサン、一体何を評価基準として使えばいいんだ。
開発者の経験年数か?開発者のスキルか?だが、そんなことは私には判断できない」

常識に縛られて、本当に簡単なことに気付けないことがある。

「何が分からないのかね」ジョナサンが問う。

分かってしまえば何ということもない、当然の結論に辿り付くことがある。

「ヨハン、『''マネジメントの本質は、納期と予算の両方を守ること''』だと君は言った。コスト計算の方法は間違っていたわけだが、しかし、残されたものがある。
プロジェクトの成功の本質は、目的は何だね?」

人は、回り道をしながらも、確かにそこに辿り付く。それが人間が持つ力、論理的思考の持つ力だ。

「納期……進捗……開発者を評価するための基準は、進捗への貢献度だ。『''経験年数やスキルではなく、プロジェクトの進捗への貢献度こそが評価基準であるべき''』なんだ」

驚いたことに、誰からも反論は出なかった。ヨハン自身も訳が分からないようだ。

ジョナサンが口を開いた。

「多くの者が忘れてしまっているようだが、『''評価基準は目的を達成するための手段''』なのだよ。『''間違った評価基準は、目的達成の障害でしかない''』。
間違った方針を変えてみることだ。全てのメンバーの努力のベクトルが、真っ直ぐ目標を向くように。それが、真に努力するということなのだよ」

----

私は思った。目標に沿った評価基準があって、初めて真の努力が生まれる。きっと、そうなのだろう。いや、そうに違いない。
しかし、そんなことが実際に可能なのだろうか?

評価基準として成果主義を導入しようという話は、これまでにも無かったわけではない。
だが、そういう話は役員レベルで何度も潰されてきたと聞いている。

優秀な社員を評価することで大きな格差と妬みが生まれたり、逆に平均的な社員の評価が導入前より下がってしまいやる気が落ちたり、
やり方が変わることで生産性が低下してしまったり、そういう様々な懸念があるためだと説明されているが、彼らの本心など誰にだって分かっている。
要するに年功序列という権益を守りたいだけなのだ。

結局、彼らは『''社員を稼働率で評価する''』ことに慣れきってしまっている。
彼らが変化を認めるのは、会社が潰れそうになったときくらいだろう。いいや、それでも認めないかもしれない。

「どうやら『''成果主義''』という言葉を思い浮かべているようだが、それとは少し違う」

見透かしたようなジョナサンの言葉に、私は驚いた。
「何が違うというのですか?」ヨハンは質問する。自分の手の届かないところに答えがあったという苦悩が、ヨハンの声を苛立たせているようだ。

ジョナサンは、無言でホワイトボードを裏返した。ペンが走る。そこに書かれた言葉自体は簡単だった。しかし、その意図を理解するのは容易ではなかった。

『''プロジェクトを正しく評価するためのコスト計算''』

「答えを性急に追い求めると、『''問題は外部にあった''』、あるいは、『''問題は上司にあった''』、という話になってしまうことがある。
これは非常に危険な落とし穴だ。この落とし穴に一度嵌ってしまうと、抜け出すのは容易ではない。マネージャーのみならず、プログラマにも覚えがあることだろう」

もちろん覚えがある。バグをライブラリやOSのせいにしたことは数え切れない。しかし、筋道立てて確認してみると、実は自分のミスだったということのほうが多い。
正しい答えにたどり着くには、焦りは禁物だ。

「とりあえず、中途半端になってしまったコスト計算の話に戻ってみよう。全員に、重要な定義を知ってもらう必要がある。
さて、ヨハン。君に質問だ。『''プロジェクトを評価する方法は、プロジェクトの損益(利益または損失)である''』というのは、正しいかな?」

「もちろんです」ヨハンは答えた。沈黙するジョナサンに少し不安になったのか、言葉を足す。「それ以外にプロジェクトを評価する方法などありません」

「では、」私は、ジョナサンが何と言うのか、なんとなく想像がついていた。
彼は楽しそうに笑うと、まるで理解の足りない学生たちに言い聞かせる教授のような口調で言う。

「確かめてみようじゃないかね?」そしてまた、常識が一つ変わっていくのだ。

「『''プロジェクトを損益(利益または損失)で評価する''』。これが、ヨハンの言うプロジェクトの評価方法だ。多くの企業ではこの評価方法を使っている。
しかし、多数決というのは正誤を決める方法ではない。重要なのは、根拠となる前提と、期待した結果が、実際にあるかどうかという点だ」

-プロジェクトを正しく評価するためのコスト計算 ? 対立解消図(Cloud) http://www.mikihoshi.com/wiki/wema.cgi?page=2004072316135912619

私は考える。また、この図だ。常識を打ち破るのは、容易ではない。だが、この対立解消図の前には、間違った常識は生き残れない。

「『''プロジェクトを損益(利益または損失)で評価する''』という方針を採用した場合、当然だが『''損益を算出するためにプロジェクト単位にコスト(変動費と固定費)を集計する''』ことになる。
そうだね?」

「ええ、そうです……分かりましたよジョナサン。認めます。『''プロジェクトを損益(利益または損失)で評価する''』限り、人件費などの固定費をプロジェクトに集計することは
避けられない。しかし、『''固定費のコスト集計には正当な根拠が無い''』ですし、『''コストの配賦誤差が大きくなりすぎて正しい判断ができなくなる''』わけですから、
ここに矛盾が生まれていることになります。『''プロジェクトを損益(利益または損失)で評価する''』という方針を強く強制すればするほど、
固定費の配賦誤差が生み出す悪影響が顕在化し、『''正しくプロジェクトを評価する''』という目的が達成できるかは怪しくなっていく……ということですね」

「そうだ。それが従来のプロジェクト・マネジメントが抱える方針制約だ。間違った方針のもとで努力すればするほど、状況はどんどん悪化していくことになる」

ステーシーが身を乗り出して質問した。「別の方法があるのですか?」ジョナサンは答えない。そのかわり、指で頭を何度か叩く。

自分で考えろ、ということなのだろう。みんなも考えている。何が正解なのか。固定費の配賦誤差は避けられない。方針が間違っている。つまり……。

アレクサンドが呟いた。「本当に、誤差だらけの損益を計算する必要があるのかな?」途端に、みんなが自分の意見を言い合った。もちろん、私も参加する。
にわかに、会議室が騒然となった。

「何で誤差を含む損益を使うのかしら。そんなの間違ってるわ」「固定費があるから誤差が生まれるんだ」
「たぶん、計算式が間違っているじゃないかな」「計算式って、''損益 = 売上 - 費用(変動費 + 固定費)''ってやつだろ?これが間違いなのか?」
「どこがマズいんだろ?」「今までの話を聞いてなかったのか? 固定費に決まってるだろ」「だいたい、固定費ってマネジメント不能なんだろ」
「マネジメント不能だっていうなら、固定費についてはマネージャーじゃなくて経営者が考えればいいんだ」
「固定費を計算式に入れる根拠って無いんじゃないか?」「どうせマネジメント不能なんだから、固定費を無視して評価してみればどうかしら?」
「そうだ。プロジェクトに関連する変動費だけを考慮すればいい」

こんなに意見を出し合ったのは、ひさしぶりだ。みんなの意見が次第に収束していく。最後に残ったのは、あまりにもシンプルになった、新しい計算式だった。

-''売上 - 変動費''

「完璧だ」ヨハンが言った。「完璧とはどういうことですか?」ボブが質問する。「分からないのか?これなら固定費の配賦誤差が入る余地なんて一切無い。だから、判断を間違える可能性が無くなる。
『''正しい判断が出来る''』評価方法だ。これは、完璧に目的に沿った評価方法なんだよ」

ヨハンが興奮して説明している。正しい方針というものは、こんなにも単純なことなのだろうか。

パチパチパチ

満面の笑みを浮かべて、ジョナサンが拍手をしている。

「よくやった。君たちは自分たちで答えを見つけ出した。矛盾を解決する方法を探し出して、今までは考えもつかなかった方針を見つけ出したのだ。本当に素晴らしい」

褒められて悪い気はしない。確かに、自分たちは答えを出したのだから。

「ジョナサン、この計算式の結果に名前はあるのですか? 固定費や間接費を考慮していない以上、これは損益ではありません。これは何と呼べばいいのですか?」

ステーシーは自分が知らない定義に出会って、少し困惑しているようだった。ジョナサンに、みんなの視線が集まる。

「''売上''から''変動費''を引いた結果を、''スループット''と言う」

-''スループット = 売上 - 変動費''

「これこそが、本来マネージャーがマネジメントすべきものだ。『''マネジメントの目的は期間あたりのスループットの最大化である''』と言い換えてもいい」

ヨハンの眼は輝いていた。無理も無い。ようやく、自分のやるべきことを見つけたのだ。
開発者に恨まれながら、自分がやっていることが本当に正しいのかと悩む必要は、もう無い。
マネジメントの正当性は、それが目的に沿っているかどうかで判断すればいい。
今、目的と手段が確かに繋がったのだ。

「どうしても『''売上''』でなければならないのですか?」ステーシーの質問に、ジョナサンが答える。

「いい質問だ。定義が『''売上''』となっているのは、必ず『''納品''』までを考慮しなければならないためだよ。
仕掛品や完成品の在庫をどれだけ作っても、『''納品できなければマネジメントが成功したとは言えない''』からね」

確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫とは?この業界に在庫なんてありませんが?」

私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。

「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだろう。''ものづくり''をしている業界で、''納期遅れ''が起きている職場で、''現場に在庫が無い''などと考えるのは大きな誤りだ」

----

「『''在庫''』とは、将来納品するために存在する、作りかけの未完成品や納品前の完成品のことだ。
そのままでは納品できないもの、全てが在庫だ。

例えばIT業界での『''在庫''』とは、『''書きかけのコード''』『''未テストのコード''』『''別のコードの完成を待っているテスト済みのコード''』
『''完成していても顧客に納品されていないコード''』を指す。もちろん、『''完成していても顧客に納品されていないドキュメント''』も在庫だ」

ジョナサンの言葉を聞くうちに、私のマシンの隣に何かが山のように積みあがっているのが見えてきた。
何だろう。そうだ、あれは、私が書いてきたコードだ。毎日残業して、その中に価値があると信じて作り出してきたコードだ。
あれが全て、在庫だというのか? 現時点では顧客に納品することができない、スループットに繋がっていない、在庫だというのか。
頭を振って、妄想を追いやろうとして、気付く。いや、違う。在庫の存在は妄想ではない。

簡単なことだ。''コードは目に見えない。だから、私たちはそれが在庫だと正しく認識できていなかったのだ。''なんということだろう。

顧客の視点で考えてみれば、それがよく分かる。書きかけのコードや、未テストの機能は、顧客の視点ではほとんど価値が無い。
機能が完成したと私が叫んでも、未テストの機能にお金を払ってくれるような都合の良い顧客はいないのだ。
機能がテストを通って、確実に動作すると保証されて、初めて在庫は価値に変わるのだ。
その点では、IT業界は製造業と何の違いも無い。まさに、未テストのコードは在庫なのだ。

「在庫、ですか。在庫というのは倉庫に入っているものだと思っていましたが、
パソコンの中にも在庫はあるというわけですね」
ボブの言葉に、ジョナサンは頷く。

「『''在庫''』はスループットを生み出す前の状態であり、将来的にスループットに変わる可能性はあるが、
しかし、現時点ではスループットにはなっていない。これがどういうことか、わかるかね?」

「つまり……開発者の稼働率を上げるために今すぐ必要でない作業を行わせても、在庫を増やすことにしかならない。
見た目の効率を重視したマネジメントでは、スループットを増やすという目標は達成できないということですか?」ヨハンが尋ねる。

「そのとおり。プロジェクト・メンバー全体の生産能力は一定だと仮定しよう。すると、『''在庫を増やすために生産能力を使い過ぎると、相対的にスループットを減らす結果になる''』。
これはマネジメントの目標に反した行動だ」ジョナサンの言い分はシンプルだ。だが、ステーシーが疑問を口に出した。

「『''必要になるまで、作業の開始を遅らせる''』ということは理解できます。
しかし、それでは開発者の手が空いてしまいます。その開発者の時間が無駄になるのでは?」ステーシーが疑問を口に出す。

「それは違う。開発者の余剰生産能力はいわば自然発生したセーフティー・バッファー(安全のための緩衝)なのだ。
開発者にさしあたって必要の無い在庫を作らせることでセーフティーを削り、生産能力をバランスさせてしまうと、前工程に発生した遅れをカバーするための時間的余裕が無くなってしまう。
作業のフローは非常に脆く壊れやすい状態になり、実際にフローは滞る。その結果、スループットに破壊的な影響を及してしまうのだ」

「そうじゃないかと思ったわ」ステーシーはため息を吐く。「思い当たることだらけだもの」

「ところで、この『''在庫''』をスループットに変えるためのコストを『''経費''』という。
『''顧客に納品する目的でないもの''』は、全て経費だ。
よく在庫と誤解されるのだが、『''顧客に納品する目的でないコード''』『''顧客に納品する目的でないドキュメント''』なども『''経費''』に含まれる。
目に見える経費、というわけだね」

「てっきり経費というのは、紙に印刷されたものだと思っていましたよ」ボブが冗談を飛ばし、アレクサンドがそれを受けた。「これからはメジャーで測らないとな」

みんなが笑う。ジョナサンも楽しそうに笑った。

「さて、『''在庫''』『''経費''』『''スループット''』の3つの指標がある。
マネジメントの手段は明らかだ。『''在庫を減らし、経費を減らし、スループットを増やす''』。これが、マネジメントの全てだ」

「たった、それだけなのですか?」
ヨハンは、簡単には認められないようだ。
彼は勉強家だ。ずいぶんと努力をして、マネージャーになったのだと聞いている。答えが簡単に手に入ることに、慣れていないのかもしれない。

「そう、たったそれだけだ。この3つの指標の他には、何も必要ない。
注意して欲しいのは、これらの指標の一つだけを改善しようとすると逆効果になってしまうということだ」

「『''コスト削減''』は逆効果なのですか?そんなはずは無いと思います」 ヨハンの反論に、ジョナサンは答える。

「その内容はともかく、『''コスト削減''』を行おうとするマネージャーは多い。
だが、『''在庫を減らすこと''』と『''スループットを増やすこと''』を蔑ろにしていては、効果的なマネジメントを行っているとは言えない。
それどころか、『''コスト削減を重視しすぎて、在庫を増やし、スループットを減少させてしまう''』ケースもある。
例を挙げよう。

社員に休憩時間を与えず、残業をさせて稼働率を上げる。マネージャーは時間当たりの人件費を節約したように錯覚する。
しかし実際には、''企業が支払う金額はこれっぽっちも減ってはいないし、むしろ残業代などで増えている。コスト削減は妄想だ。''

開発者にひたすらコードだけを書かせて稼働率を増やし、マネージャーは開発の効率を上げたように思い込む。
これも実際には、''在庫が増えただけだ。生産能力を在庫の作成と管理に振り向けたわけだから、スループットは激減している。''

これほど非効率的なマネジメントは無いよ」

「しかし、この業界ではみんなそうしているのでは?」「なら、みんな間違っているんだろうね」笑いの消えたみんなと対照的に、ジョナサンは心底楽しそうだ。

ジョナサンは話を続ける。「定義上当然のことだが、『''スループットが減ると利益も減る''』。
これを改善しようとまたマネージャーが『''スループット無視のコスト削減''』、あるいは自滅的な『''稼働率向上戦略''』に向かえば、
在庫増加、スループット減少、利益減少の破壊的な悪循環が発生することになる」

「最後には、わけもわからず倒産ってわけか」アレクサンドがぽつりと呟いた。

この業界の倒産件数は、年々増加傾向にあるという。多くのベンチャー企業が生まれては消え、大企業の採算悪化も珍しくない。
それは、正しいマネジメントが行われていなかったからなのだろうか。コスト削減だけを重視して、スループットを見失っているからなのだろうか。

「スループットを増大させるには、『''書きかけ・未テストのコードを減らし(在庫削減)、分納などで納品を早める(スループット増加)''』ことが最良だということになる。
しかしそのためには、『''スループットが大きく増えるのであれば、経費が多少増えても良い''』という、考え方の転換も必要になる」

コスト増!今までの私たちにとっては禁句だった言葉だ。遅れているプロジェクトに払う金など無いと、何度遠まわしに宣言されたことか。
だが信じられないことに、ヨハンは何も言わずに考えているようだった。しばらくして、ヨハンが口を開いた。

「コスト至上主義からスループット至上主義への転換が必要、ということですね。両者はまるで違う。天動説と地動説くらいに違う……。
ですが、『''これ以上の経費削減は無意味だ''』という気持ちは、私にもありました。
僅かの経費に執着して、利益を生み出す別の要因を見落としているのではないかと、いつも考えてきました。
確かに、見落としていました。『''スループット''』、『''在庫''』……経費削減と同様に、いや、それ以上に、重要な視点です。
考え方を変えるには時間がかかるかもしれませんが、見落としていたものを見つけたからには、最大限努力しましょう」

私は、自分がヨハンを誇らしい気持ちで見ていることに気付いた。彼なら、正しいマネジメントを実践するに違いない。

未テストのコードという在庫を減らすのに、テスト駆動開発が有効だと私が提案したら、聞き入れてくれるだろうか。
開発の効率を上げるために、テスト・サーバーがどうしてももう一台必要なのだと説得したら、決断してくれるだろうか。
たぶん、ヨハンならやってくれるだろう。

「さて、時間だ」ジョナサンが、時計を見て言う。

「今日はもう行かなければいけない。ヨハン、また何かあったら連絡をくれたまえ。『''経費''』は増えるかもしれないが、『''スループット''』を増やすことは保証しよう」

最後のはジョークのつもりだったのだろうか。ジョナサンは笑いながら、会議室を後にしたのだった。

(ここで、一区切り)

*このページの更新履歴

-2004/06/29 新規作成(ミーティング開始)
-2004/06/30 文章追加(現状問題構造ツリー)
-2004/07/01 文章追加(対立解消図)
-2004/07/03 文章追加(崩れ去る前提)
-2004/07/07 文章追加(変わる常識)
-2004/07/11 文章追加(銀の弾丸は魔法ではない)
-2004/07/18 文章追加(間違っていた方針)
-2004/07/23 文章追加(コスト計算再び)
-2004/07/25 文章追加(3つの指標)
-2004/07/28 文章修正

*デスマーチとは

予定の開発期間を過ぎても、まだまだ終わらないプロジェクトのこと。
エドワード・ヨードンは、著書の中でデスマーチの定義として4つの項目を挙げています。
-1.与えられた期間が、常識的な期間の半分以下である。
-2.エンジニアが通常必要な半分以下である。
-3.予算やその他のリソースが必要分に対して半分である。
-4.機能や性能などの要求が倍以上である。

*リンク

**wema

-デスマーチが起きる理由@wema(各図へのインデックス) http://www.mikihoshi.com/wiki/index.cgi?page=%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3
**デスマーチ

-デスマーチ - ソフトウェア開発においての死の行進...DeathMarch http://www.nilab.info/wiki/%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1.html
-真・コンピュータ用語辞典 - デスマーチ http://www.geocities.co.jp/SiliconValley/5634/t82C4_0008.html
-デス・マーチとCMM http://village.infoweb.ne.jp/~fwgf2942/process/Proc.Dethmarch/Proc..Dethmarch0.html
-ソフトウェア開発の落し穴 - デスマーチ http://iwatam-server.dyndns.org/software/devintro/deathmarch/deathmarch/

-人月の神話?狼人間を撃つ銀の弾はない http://www.amazon.co.jp/exec/obidos/ASIN/4894716658/
-デスマーチよ!さようなら! http://www.amazon.co.jp/exec/obidos/ASIN/4774120030/
-デスマーチ?なぜソフトウエア・プロジェクトは混乱するのか http://www.amazon.co.jp/exec/obidos/ASIN/4901280376/

**制約理論(Theory Of Constraints, TOC)

-制約理論の広場 http://www002.upp.so-net.ne.jp/toc-jp/index.htm
-TOC http://takumi.web.infoseek.co.jp/TOC/TOC.htm

-ザ・ゴール ? 企業の究極の目的とは何か http://www.amazon.co.jp/exec/obidos/ASIN/4478420408/
-ザ・ゴール 2 ? 思考プロセス http://www.amazon.co.jp/exec/obidos/ASIN/4478420416/
-クリティカルチェーン?なぜ、プロジェクトは予定どおりに進まないのか? http://www.amazon.co.jp/exec/obidos/ASIN/4478420459/
-シンクロナス・マネジメント?制約理論(TOC)は21世紀を切り拓く http://www.amazon.co.jp/exec/obidos/ASIN/4947627433/

** このページから派生したページ
-[[デスマーチが起きる理由-1人称の場合-]]
-[[デスマーチが起きる理由-3人称の場合-]]
-[[デスマーチが起きる理由-推敲版-]]
-[[デスマーチが起きる理由/anonymousさんへの回答]]
-[[Aさんのアンチデスマーチ]]

----

* コメント

[[#rcomment]]
- 2007-06-15 (Fri) 10:35:18 ''[[Delilah]]'' : Great website! Bookmarked! I am impressed at your work!
- 2007-06-12 (Tue) 13:57:15 ''[[ku]]'' : サービス残業が当たり前という「常識」を「非常識」として認知されたいですねぇ・・・
- 2007-06-03 (Sun) 15:33:20 ''[[Reynold]]'' : None
- 2007-05-28 (Mon) 12:51:25 ''[[KKK]]'' : これはどこの国の話だ?サービス残業があたりまえの日本では社員は使えるだけ使ったほうが得なのでは?
- 2007-05-01 (Tue) 06:42:15 ''[[Herbert]]'' : None
- 2007-04-28 (Sat) 15:26:40 ''[[TAKER]]'' : 「人件費をプロジェクトのコストとしてプロジェクト単位に集計することには、正当な根拠が無い」のところは是非上司に読ませたいです。が、文章全体が長すぎる。。
- 2007-03-26 (Mon) 01:06:30 ''[[adult sex porn]]'' : Thank you.

- 2007-01-22 (Mon) 15:45:36 ''[[k-taro]]'' : 「在庫」を減らし「スループット」を上げるには、タイムボックスw
- 2006-04-18 (Tue) 13:15:19 ''[[Nuka]]'' : リンク先の図が見たいです。
- 2006-02-28 (Tue) 11:13:29 ''[[Kenji]]'' : 会社を変えたくなる内容。こんな運用をしている会社は実在するのか。あったら是非そこで頑張らせてほしいものだが。
- 2005-12-05 (Mon) 17:04:14 ''[[PM志望]]'' : 楽しく読ませていただきました。受注判断時にスループットを判断材料にすることは常識なのでうまくやれば有効な手段だと思いますが、逆に進捗貢献至上主義になりすぎるとスループットが伸びなくなる可能性があるかもしれません(掛け持ちによるスループット増を嫌う)
- 2005-11-06 (Sun) 20:17:07 ''[[lon]]'' : デスマーチという言葉の意味さえ知らずにこのページのたどり着きました。私自身は働く身ですらありませんが、おもしろくて一気に読んでしまいました。この文章の作者に感謝します。
- 2005-10-14 (Fri) 13:28:38 ''[[あおいそら]]'' : パラダイムシフト、結果、成果をどう捕らえるか、簡単で難しい
- 2005-08-22 (Mon) 11:00:53 ''[[Beverli Eagan]]'' : Cameron Moore
- 2005-08-02 (Tue) 06:57:02 ''[[Jerry Gadette]]'' : David McGiffert
- 2005-07-06 (Wed) 07:25:36 ''[[William James Teegarden]]'' : Tom McCown
- 2005-07-05 (Tue) 00:42:29 ''[[Granville Young]]'' : Nancy Hvasta
- 2005-07-03 (Sun) 23:58:28 ''[[John Zemansky]]'' : Wesley Mann
- 2005-07-03 (Sun) 21:35:03 ''[[Larry Boyd]]'' : Noel Tomlinson
- 2005-07-02 (Sat) 22:23:02 ''[[Dorothy Byrne]]'' : Paul M. Sonski
- 2005-07-01 (Fri) 16:08:51 ''[[Noel Tomlinson]]'' : Lloyd L. Tolbert
- 2005-06-30 (Thu) 20:54:39 ''[[Cara Giallanza]]'' : Tom Phillips
- 2005-06-29 (Wed) 01:57:43 ''[[Harry Waters Jr.]]'' : Michael Mills
- 2005-06-28 (Tue) 00:25:10 ''[[Ken Chase]]'' : Stephen Homsy
- 2005-06-27 (Mon) 05:07:00 ''[[Lisa Freeman]]'' : David Robbie
- 2005-05-28 (Sat) 12:05:21 ''[[Cara Giallanza]]'' : Wesley Mann
- 2005-05-25 (Wed) 02:45:44 ''[[Steven Wolff]]'' : Kenny Myers
- 2005-05-24 (Tue) 23:18:36 ''[[Larry Boyd]]'' : Walton D. Hadfield
- 2005-05-24 (Tue) 11:19:36 ザ・コールは未読ですが、この文書にはXPやデマルコの本に通じるものが多くあり、とても示唆に富んでいると思います。がんばってください。
- 2005-05-10 (Tue) 07:34:39 ''[[Martha Johnston]]'' : Susan Rosen
- 2005-05-04 (Wed) 20:12:23 ''[[Jerry Sargent]]'' : Nancy Hvasta
- 2005-05-01 (Sun) 17:15:37 ''[[Lawrence A. Hubbs]]'' : Daniel R. Bentley
- 2005-04-30 (Sat) 21:01:20 ''[[Jerry Gadette]]'' : Joe Flaherty
- 2005-04-30 (Sat) 15:52:37 ''[[Bruce Moriarty]]'' : Lisa Freeman
- 2005-04-28 (Thu) 21:17:25 ''[[Kenny Myers]]'' : Martin A. Kline
- 2005-04-28 (Thu) 02:34:06 ''[[David McGiffert]]'' : David McGiffert
- 2005-04-28 (Thu) 00:49:44 ''[[James F. Walker]]'' : Hazel Catmull
- 2005-04-27 (Wed) 06:27:20 ''[[Cara Giallanza]]'' : Justin Mosley Spink
- 2005-04-21 (Thu) 02:34:08 ''[[Tom McCown]]'' : Walton D. Hadfield
- 2005-04-20 (Wed) 19:37:09 ''[[Jerry Sargent]]'' : Walton D. Hadfield
- 2005-04-19 (Tue) 16:44:10 ''[[Tony Piller]]'' : Angela Greenblatt
- 2005-04-18 (Mon) 10:01:25 ''[[Bruce Moriarty]]'' : David Harold Brown
- 2005-04-16 (Sat) 00:03:42 ''[[Cara Giallanza]]'' : Richard Leon
- 2005-04-14 (Thu) 16:54:34 ''[[Ken Chase]]'' : Cameron Moore
- 2005-04-12 (Tue) 23:40:13 ''[[David Robbie]]'' : Dan Ondrejko
- 2005-04-11 (Mon) 15:55:17 ''[[Martha Johnston]]'' : Justin Mosley Spink
- 2005-04-11 (Mon) 15:10:24 ''[[Dorothy Byrne]]'' : Nancy Mickelberry
- 2005-04-11 (Mon) 07:56:17 ''[[Jim Dultz]]'' : Nancy Hvasta
- 2005-04-10 (Sun) 15:19:56 ''[[Martha Johnston]]'' : Roland Blancaflor
- 2005-04-10 (Sun) 10:08:47 ''[[Max Kleven]]'' : Kenny Myers
- 2005-03-02 (Wed) 17:37:21 可否および現実的に実現出来るかはともかくとして、個人的にこのような運用をしているプロジェクトを死ぬまでに1回は体験してみたいです。はぁ〜、デスマーチはもういや。。。
- 2005-02-06 (Sun) 21:42:24 ”世界の全ての人(経営陣と言い換えてもいい)が変わるなら”という前提もやはり、非生産的なのでは。
- 2005-02-06 (Sun) 14:42:24 ''[[Coffee]]'' : 例えるなら、それは「(渋滞距離を短くするために)車間距離をゼロにしよう」という目標に似ている。現実には、車間距離をむやみに縮めれば事態はますます悪化し、渋滞距離はますます伸びていく――ここに悪循環が存在する。
- 2005-02-06 (Sun) 14:30:43 ''[[Coffee]]'' : 全ての生産能力を100%使いきることは、コスト最優先の現場での至上命題とされている。しかし、それは部分的なコストの最適化でしかなく、マーフィー(事前予測の不可能なトラブル)が作業のフローを停滞させ、全体の生産性を著しく低下させてしまう。「全ての生産能力を100%使いきる」という目標は、直感に反して極めて非生産的なものだ。
- 2005-02-02 (Wed) 12:28:19 「セーフティー・バッファーをなくせ」←?頭悪いすね。集めて正しい所に再配分だ
- 2005-01-29 (Sat) 11:22:05 sapporo < もう一回読ませましょう
- 2005-01-20 (Thu) 22:04:42 ''[[sapporo]]'' : すいません。この本を読んだ役員が、嬉々として”銀の玉あるじゃないか!セーフティー・バッファーをなくせ!”と言ってきました。どうしたらいいんでしょう?
- 2005-01-18 (Tue) 11:27:01 君ら技術者なら、もっとWikiをWikiらしく使おうよ。。。
- 2004-12-16 (Thu) 00:08:20 ''[[A]]'' : 大きな開発だと丸投が普通で、顧客と交渉できないし、プロジェクトが開始した時点では顧客のプロジェクトチームは解散済みとはある。最適とかの前に顧客の要望がまったく不明で確認も不能って事がある。
- 2004-12-16 (Thu) 00:06:38 ''[[A]]'' : いろいろと前提が違う議論がありすぎる。システム開発にしても前提が結構違う。
- 2004-12-08 (Wed) 22:41:03 プロジェクトの不確実性の前には、リソース配列の最適化は幻想
- 2004-12-08 (Wed) 22:04:54 "全体"って何の事を指しているのか分かってますか? >最適化 
- 2004-12-08 (Wed) 14:16:48 ''[[仕掛品]]'' : このページにある件=デスマーマーチに関する、最適化の話で、業務提携などの話とは異なると思いますがいかがでしょうか?。
- 2004-12-07 (Tue) 14:22:52 世間では「自社だけで黒字化はキツイ」 http://itpro.nikkeibp.co.jp/free/NC/NEWS/20041206/153472/ って認識だが? >損を押しつけ
- 2004-12-07 (Tue) 10:24:11 「A社 対 B社 の問題」ではなく、「A社&B社 対 問題」だっつーの >全体最適化でも、損を押しつけるけど、全体だとかわらない
- 2004-12-06 (Mon) 13:48:13 ''[[仕掛品]]'' : 仕事の目的は、お金を儲けることですし、人は仕事するために生きてるわけではありません。長時間の残業は避けるべきですね・・・。あと、全体最適化でも、損を押しつけるけど、全体だとかわらないね。というだけで、押しつけることは同じだと思いますけど・・・。
- 2004-12-05 (Sun) 02:33:23 残業代も変動費だろ?
- 2004-12-05 (Sun) 02:03:34 ''[[falcon]]'' : 亀レスですみませんが、変動費が外注費等だとすると、結局は「単位期間あたりのスループットの向上=単位期間あたりの売上向上」になり、結局は残業させて早く納品ということになりませんか?本来なら、XPとかCMMとかJITとかの手法を使うことによって、ソフトウェア開発プロセスを改善して納品までの期間を短くするべきなのでしょうが、そうった手段を持ち得ない大半の組織やマネージャは、結局のところ、作業者の残業に頼ることになりませんか?
- 2004-12-05 (Sun) 00:30:17 人の目的はお金を儲けることではない
- 2004-12-05 (Sun) 00:24:13 社会科学の場合「対立」に対して妥協の道を探そうとします。バランスを取るわけですね。「インフレ率と失業率」「サービス向上と人員削減」「財政再建と景気回復」「経審評点維持と人員削減」トレードオフと思われる物は沢山あります。これらに対してどのようにバランスを取るか?これがマネジメントだと。しかし自然科学の場合は「現実に対立は存在しないので妥協はしない」を信念としているのです。
- 2004-12-05 (Sun) 00:17:55 トヨタ流では、ボトルネックを強引にあぶり出すのです。ラインが順調に流れ始めると、速度を上げるなどして無理を与えて問題を発生させます。そして、問題を発生させた上で、それを徹底的に改善していくわけです
- 2004-12-04 (Sat) 02:07:22 ''[[酔狂人]]'' : 他所に損を押し付けて自分の担当するところの評価を上げようとするのを「部分最適化」と呼ぶのですが……。
- 2004-12-01 (Wed) 10:52:01 ''[[仕掛品]]'' : >TOC初心者さん。変えなきゃいけないのはわかってるけど、業界の体質的になかなか難しいといったところでしょうか?おそらくこのページで述べられている全体最適化というのは、経営から見た最適化で、私が述べているのは労働条件から見た最適化で、両方が同時に最適化されることはなく、非常に難しいかと思います。経営者から見れば給料は0円で仕事は山ほど、労働者から見れば給料は山ほどで仕事はちょっと、というのが望ましいわけですから・・・。
- 2004-11-30 (Tue) 21:17:08 ''[[TOC初心者]]'' : 同意いただき、ありがとうございます。仕掛品さんのお話をうかがう限りでは、IT業界では「ルールを変えることはできない」というのが既に決定事項であるようなので、それについて特にコメントはありません。ただ、仕掛品さんが「最悪な理論」だと感じている全体最適と、このページで述べられている全体最適とは、違うものを指しているように思います。
- 2004-11-28 (Sun) 17:33:27 ''[[仕掛品]]'' : >TOC初心者さん。はい、その通りですね。しかし、最近のIT系の改革では、全体最適化のみが注視され、労働環境や評価についてはグレーというのが現状です。IT業界の問題は、評価尺度が難しいという事だと。定量的に評価が難しい。たとえば、規模にすると、多く書けば良いかというと、良いコードというのはまとまっていて、短い。悪いコードはスパゲティで長い。というのがあるので、規模の多さ、少なさは尺度にならない。じゃぁ、利益?というとそうでもない。実はプログラムにはGUIのように簡単で利益が出やすい部分と、コアな部分で数値演算とか難易度が高くて利益が出にくい部分とある。しかし、会社としては、簡単なプログラムだけだと、他社との差別化がしずらいので、難易度の高い物にも利益が出なくても投資しなければならない。したがって、利益ベースというのも難しい。したがって、妥当なところで、人月というところになってきています。全体最適化の話題をするとセットとして成果主義という上司の気分次第というあいまいな評価尺度になり、優秀なひとがこき使われ、ゴマスリが跋扈するという状況が現状です。個人的な意見としては、全体最適化よりも、優秀なひとによりリソースが行き渡りやすい、部分最適化をつよめ、優秀な人同士の横のつながりを作ることで、並列的に全体最適化をするシステムの方がうまくいくのではないかと思います。現状の、優秀と無能を十把一絡げにして、適当に集めたグループを部分最適するのではなく、優秀な人をあつめた、部分を作り、まず、部分を最適化し、給料の配分をグループ内で消め、かつ、グループ間の連携をうまくとれる人間を間に入れるというのが最適かとおもってます。
- 2004-11-27 (Sat) 22:02:48 ''[[TOC初心者]]'' : だから、ルールを変えようという話なのでは?優秀な人に実は余裕がある、という状態が、表面化しないのはなぜか(それは、表面化させても当人およびマネージャにメリットがないから、な訳ですが) を考えて、その方針制約を取り除く必要がある、というのが、この話の本質だと思います。この場合の制約は評価尺度である、ということになります。全くルールを変えずに単に優秀な人をこき使おう、ということならば仕掛品さんの言うとおりですが、そういう話ではないと思います。
- 2004-11-27 (Sat) 14:59:36 ''[[仕掛品]]'' :  酔狂人さん>相対的な負荷は関係ないのでは?、サークルではなく、会社なので、能力に関係なく、同じ給料の人には、同じ仕事量を割り振らなくてはいけない。したがって、絶対量として同じ量をくばらないのであれば、労働者としては、がんばって、能力を上げると、同じ給料でも沢山しごとしないといけない。さぼって、能力をさげると、同じ給料でも楽ができるとなります。そして、現在のIT業界のほとんどは、成果主義とは名ばかりの、年齢給です。この現状があるかぎり、能力に関係なく、絶対量で仕事を割り振らないのはおかしい。そして、そういう現状なので、能力のある人は本来楽が出来るはずなのに、能力のあるひとばかりに仕事がかたまり、結果入院という自体が発生するのがIT業界です。休みを与えるなんて、名目上だけですよ?。現実は搾り取れるだけ搾り取るってのが普通ですね。
- 2004-11-24 (Wed) 21:53:15 ''[[fool]]'' : 社員数が固定なら全社トータルのスループット重視としても、社員の増減てあるわけでしょ。社員が10倍になったのにスループット2倍では駄目でしょ。だから社員一人当りの平均スループット重視でないか。それと株主に対するスループットもあるので指標としては   トータルスループット/(社員数+α・株数)  てな感じでしょうか? 係数αは1株が社員何人に当たるかを示す どう求めるか見当付かんけど
- 2004-11-24 (Wed) 21:22:28 ''[[fool]]'' : 個々のプロジェクトで予算管理とかを具体的に如何やるかってのが今一つ見えません
- 2004-11-24 (Wed) 12:38:26 ''[[dog]]'' : >酔狂人さん 「物理的制約は明確出でない場合がほとんど」全くその通りだと思います。ですから、この分野では「思考プロセス」の活用が必須になるわけですよね。
- 2004-11-23 (Tue) 10:10:02 ''[[dog]]'' : >
- 2004-11-23 (Tue) 07:21:12 ''[[酔狂人]]'' : 能力で区別しない絶対的な負荷は高くても、能力当たりの相対的な負荷は軽くなるようにするということです>仕掛品さん
- 2004-11-23 (Tue) 00:09:33 例えば自社以外に外注する >変動費
- 2004-11-23 (Tue) 00:08:25 余力が前提だよ >他の人の荷物も運んでいる=重労働
- 2004-11-22 (Mon) 20:21:39 ''[[falcon]]'' : 単品生産のソフトウェアの場合、変動費って具体的には何でしょうか?
- 2004-11-22 (Mon) 17:38:20 ''[[仕掛品]]'' : >酔狂人さん。それは、足の速い人は、自分の分も運んだ上に、他の人の荷物も運んでいる=重労働。足の遅い人は荷物をもってもらえる=軽労働。つまり、能力が高いと重労働ということに代わりがないと思います。つまり、全体最適は、一部の人間に負荷がかかりすぎるという理論ではないでしょうか?
- 2004-11-21 (Sun) 22:46:02 ''[[酔狂人]]'' : ソフトウェア開発においては、物理的制約は存在しないか、明確でない場合がほとんどだから、こだわりすぎると逆効果になりかねません>dogさん
- 2004-11-21 (Sun) 22:28:35 ''[[酔狂人]]'' : 「制約」とは、「速度」の上限を決めるところであって、時間がもっともかかるか否かは「制約」とは無関係です。「時間がかかる」ことを重視するのは、「コストワールド」の考え方です。
- 2004-11-21 (Sun) 22:12:12 ''[[酔狂人]]'' : 全体最適化について誤解しています>仕掛品さん 特定の個人やグループに過度に負荷が集中すると、ミスを起こしやすくなったり、病気になったりして、能力が低下しやすくなります。それは全体最適化に反します。
『ザ・ゴール』でも足の遅い少年の荷物を持ってやり、全体としてのスピードをあげようとする場面がでてきます。
- 2004-11-16 (Tue) 00:45:42 早い話、儲け >何がメリット
- 2004-11-16 (Tue) 00:43:57 ''[[ボトルネックとは]]'' : 簡単に言うと時間がかかっているもの。開発期間の割合からみてテストがボトルネックなのであろう。
- 2004-11-15 (Mon) 16:00:39 ''[[マルチタスク]]'' : 私は皆さんの議論を聞いていてよくわからない所があります。皆さんが捉えられているボトルネックとはどのような意味なんですか?ボトルネックを認識したところで何になるんですか?ソフトウェア業界にいる私にとって、会社にとっても、何がメリットになるのか分かりません。すいませんが、皆さん教えてください!!
- 2004-11-15 (Mon) 14:17:17 「ソフトウェア開発の場合、3割から9割もテストしているということはテストがボトルネックなのです。」http://www.atmarkit.co.jp/farc/rensai/bto01/bto01.html
- 2004-11-15 (Mon) 13:32:07 ''[[dog]]'' : >酔狂人さん リンク先の文章拝見しました。この文章の作者はTOCを誤解しているようです(この文章は2年前のものですから、現在は違うかもしれませんが・・・)。また、「制約を意識する必要はない」というより、「制約を意識しなければ、(ほとんど)改善できない」のです。
- 2004-11-15 (Mon) 00:39:08 ''[[めけめけ]]'' : 単純な人間なので、単純に感動しました。特にスループット云々・・・そう、これ、これが言いたかったのよと・・・
- 2004-11-14 (Sun) 22:20:32 ''[[酔狂人]]'' : ソフトウェア開発では、TOCで言うところの制約はほとんど意識する必要はないと思います>dogさん http://www.objectclub.jp/ml-arch/extremeprogramming-jp/3800/3840.html
- 2004-11-10 (Wed) 21:52:11 この前提がおかしい >社内のみから人材を調達する場合
- 2004-11-10 (Wed) 13:34:28 ''[[仕掛品]]'' : という部分が違うだけで、労働者の労働量は増えてると思います。また、現状は、優秀な人は常に仕事が山積みで、暇そうにしている人は、それなりの人なのでヘルプに送っても大してお役に立てないから、暇してるのだと思います。なので、暇な人を連れてくればというのも無いと思います。
- 2004-11-10 (Wed) 13:32:20 ''[[仕掛品]]'' : また、他の仕事のヘルプに入れるような、優秀な人は数がすくないです。したがって、ヘルプ役の人は限られてきます。そうして、他のチームを助けるために呼ばれることが多くなった結果、まともに休みが取れなくなります。そして、従来の仕事がおろそかになり、それを何とかするために、チームに残った人が休みを返上して、作業することにより休めなくなります。基本的にデスマーチは発生した時点で、社内のみから人材を調達する場合、総量として休みが従来より減るのは確定事項です。したがって、このページの理論で、全体最適をかけると、だれが休みを返上するか?toiu
- 2004-11-10 (Wed) 13:27:20 ''[[仕掛品]]'' : 最初に休みを考慮して仕事を分配したとします。しかし、問題が起き、あるチームだけが休みが取れなくなったとします。この状態で、他のチームの優秀な人材がヘルプにはいると言うことは当初予定されていた休みを少なくするという事を意味します。この人に従来通りの休みを与えるためには、別な人が休めなくなります。
- 2004-11-05 (Fri) 12:25:21 プログラマの休みを考慮すればいいだけの話では? >プロジェクトにとって、最適なプログラマの移動は、プログラマにとっては休む事なき重労働
- 2004-11-04 (Thu) 11:35:24 ''[[仕掛品]]'' : 久々に、遊びに来てみました:全体最適というのはおもしろい観点ですね。全体最適は嫌いです。プログラム業界では全体の為という悪しき理由で、一部の個人にとんでもない負荷がかかり、病気・自殺などが問題になっています。プロジェクトにとって、最適なプログラマの移動は、プログラマにとっては休む事なき重労働という意味です。したがって、会社としては、良い理論だと思いますが、労働者としては、最悪な理論だと感じています。
- 2004-10-22 (Fri) 21:45:46 ''[[dog]]'' : ただし、この文章全体を批判しているわけではありません。半分あっているだけでは全く機能しないのが「スループット計算」なのです。プロジェクト環境における企業の「制約」とは何か?もう少し頑張ってみて下さい。
- 2004-10-22 (Fri) 21:40:19 ''[[dog]]'' : 「スループットを管理する」という本当の意味を考えた場合、単に「売上−変動費」という視点だけでは不十分です。「スループット」最も重要なのは「制約を認識しているかどうか」という視点です。この部分を踏まえることなくスループットの話をしても、「コスト計算の世界」にいるのと同じです。
- 2004-09-22 (Wed) 17:40:04 ''[[coco]]'' : ↓anonymous「さん」が抜けてました。失礼しました。
- 2004-09-22 (Wed) 09:14:06 ''[[coco]]'' : (> anonymous 氏)ご返答ありがとうございます。『ザ・ゴール』をお読みになったanonymousのコメントを楽しみにしています(←※皮肉じゃないです。いろいろ点に意識が向いてすごいなぁと思ってますので)
- 2004-09-20 (Mon) 13:45:21 ''[[議論がかみ合わない理由]]'' : コストとスループットの話しか出てきませんが、TOCの重要な概念に「部分最適」は悪であり「全体最適」が重要、があります。例として鎖の強度問題がよくあげられます。『鎖を構成する輪一つ一つそれぞれを強化する事だけでは全体の強度が上がる事には結びつかない。一番弱い輪を探して強化、またそれを繰り返す事で全体の強度を上げる。』といったものです。つまり複数のプロジェクト一つ一つについて個別にではなく、全体で考えよ、という事です。
- 2004-09-19 (Sun) 14:03:57 ''[[anonymous]]'' : (> coco 氏)私には別に何らかの信念があるわけではないのです。ただ、ここで提示されている新しいルールが、現実に機能するかどうかについて疑問があったので、反証と思われるものをいくつか例として挙げただけです。また、プログラマやマネージャの能力の客観評価は不可能だと思っています。ですから、能力に見合った報酬という概念はフィクションだと思っています。ただ、社会とはいくつものフィクションを共有することで成り立っているものなので、それを批判するつもりはありません。
- 2004-09-19 (Sun) 13:53:28 ''[[anonymous]]'' : 丁寧なご回答、ありがとうございます。ご返事が大変遅れて申し訳ありません。今回のご回答で、私の疑問点は半分ぐらい解決されたと思います。しかし残りの半分ぐらい、残念ながら釈然としない部分が残りました。その理由ですが、どうも議論がかみ合わないような、前提の異なる議論をしているような気がします。そしてその違いのひとつは、私が『ザ・ゴール』三部作を読んでいないことではないかと思われます。ということで、その本を読みましたら、またこちらに伺うかもしれません。今までいろいろありがとうございました。
- 2004-09-12 (Sun) 17:08:31 ''[[Coffee]]'' : 質問ありがとうございます。回答第四弾を追加してみました。
- 2004-09-12 (Sun) 17:07:54 その言い換えは出来ないと思います。なぜなら、「仕事をすればするだけ(=稼働率を上げる)」ことと「効率を上げる」ことは、別のことだからです。
- 2004-09-11 (Sat) 08:31:39 [[デスマーチが起きる理由/anonymousさんへの回答]]に、「効率」とありますが、「効果」の間違いでは?「仕事をすればするだけスループットが増える」は、「仕事の効率を上げればスループットが増える」と言い換えられます。
- 2004-09-09 (Thu) 10:11:56 ''[[coco]]'' : anonymousさんが、人件費をプロジェクト単位で集計すべきだと強く訴えるからには、そこにメリットもしくは根拠があってのことだと思われます。よろしければ、その点について、anonymousさんの考えを教えていただけないでしょうか?また、プログラマーやマネージャーの能力評価について、どのような指針をお持ちですか?
- 2004-09-08 (Wed) 01:21:21 ''[[anonymous]]'' : すみません、前回の質問をまとめる時間が取れませんので、前回のものをそのまま質問とさせて頂きます。あと、追加ですが(3)結局、スループットは客観的な測定は可能なのでしょうか?(4)マネージャに限らず、社員が個人の利益の最大化を目指すのは当然のことで、それできちんと会社が運営できるような制度を作るべきなのではないでしょうか?以上です。よろしくお願いいたします。
- 2004-09-06 (Mon) 22:01:17 ''[[anonymous]]'' : またも丁寧なご回答、ありがとうございます。時間が取れませんので、後ほど改めてご返事させていただきます。今の疑問をかいつまんで申しますと、(1)ウォーターフォールのフェーズが変わるごとに、新たな人員が必要になりますが、その獲得しすぎを抑制する方法がないのでは?(2)ドキュメント・教育などの引継ぎのためのコストは、もし人員が不足しなかった場合無駄になるのでは?また、XPの隆盛と逆行するやりかたなのでは?ということです。今回はこれで失礼します。
- 2004-09-05 (Sun) 20:20:49 ''[[Coffee]]'' : 回答に追加してみました。
- 2004-09-05 (Sun) 16:50:59 ''[[anonymous]]'' : 以上です。よろしくお願いいたします。
- 2004-09-05 (Sun) 16:49:47 ''[[anonymous]]'' : 3.他の疑問です。(1)『ザ・ゴール』は未読ですが、すべてのプロジェクトに共通のボトルネックを共同で解決すべし、よって人材をボトルネックにまず集中すべし、というテーマだと聞いております。つまり、ソフトウェア業界のように、しばしばマネージャ同士がゼロサムの競争をしている場合は成り立たない議論ではないでしょうか?(2)ブルックス『人月の神話』には、追加の人員は無駄である、それは技術が足りないからではなく、仕様の理解に多くの時間が必要だからだ、と書かれています。私の実経験でも、それは正しいと思います。この小説では、なぜ人材の追加で問題が解決できるのでしょうか?
- 2004-09-05 (Sun) 16:47:51 ''[[anonymous]]'' : 2.そもそもこの理論は、スループットを完全に定量的に(おそらくは金額ベースで)、そして客観的に査定することが可能だとする前提に基づいています。私はそれは不可能だと思います。例えば、システムの根幹にかかわるデバイスドライバのスループットはいくらですか?これ単体では納品はできませんから、金額ではゼロです。よって正当な評価のためには、金額のみでなく、プログラマ同士の評価といった計量しがたい基準を取り入れる必要がありますが、これは定量どころか、順序すら付けがたい極めてデリケートなものだと思います。これで果たしてプロジェクトのスループットの変化をパーセンテージで示せるでしょうか?大幅に恣意が入り込む余地が存在していると思うのですが。
- 2004-09-05 (Sun) 16:46:16 ''[[anonymous]]'' : 1.人材の追加の前後におけるスループットの変化によって、そのプロジェクトに実際に人材追加が必要だったかどうかを査定する、とのことですが、では追加ではなく、プロジェクトの当初から参加するべき人数を見積もる場合はどうでしょうか?当初から人数が多すぎた場合、それを外部から見破る方法はないと思います。人数が多すぎる疑いをかけられ、人員を引き抜かれた場合、マネージャはスループットを下げて「ほら見ろ、うちは人数はちょうどピッタリだったんだ。人を戻せ」と主張することになるでしょう。
- 2004-09-05 (Sun) 16:45:18 ''[[anonymous]]'' : Coffee 様、丁寧なご説明、ありがとうございます。スループットの定量的な変化を評価することによって、人材の獲得競争は抑止できる、とのご意見だと理解しました。つきましては、さらに質問がございます。よろしければお教えください。
- 2004-09-05 (Sun) 15:34:11 ''[[Coffee]]'' : [[デスマーチが起きる理由/anonymousさんへの回答]]
- 2004-09-05 (Sun) 11:58:15 ''[[anonymous]]'' : 以上です。どなたかよろしくお願いいたします。
- 2004-09-05 (Sun) 11:57:45 ''[[anonymous]]'' : 4.さらに補足的な内容です。プログラマの能力の客観的な評価すら非常に難しいのに、マネージャの能力やプロジェクトの優先順位を客観的に評価する方法があるとは、私には思えません。スループットなどという客観評価の指標は現実には成立しないでしょう。結局、プログラマやマネージャの政治力の大小で評価は決まってしまうのではないでしょうか?
- 2004-09-05 (Sun) 11:57:24 ''[[anonymous]]'' : 3.以上の問題を解決するには、結局元の通り、人件費をプロジェクトのコスト計算に含めるようにするしかないのではないでしょうか?
- 2004-09-05 (Sun) 11:57:00 ''[[anonymous]]'' : 2.それを抑止するために、マネージャのさらに上の経営者層による、プロジェクトの優先順位の判断が行われるとのことですが、その判断基準は結局「スループット」です。スループットを正しく測定することはしばしば不可能だ、と私は思うのです。例えば(1)技術的に高度でマネージャに理解できない場合、(2)この小説のように社内向けのシステムで、直接の売上を持たない場合、などです。どうでしょうか?
- 2004-09-05 (Sun) 11:56:32 ''[[anonymous]]'' : 1.人件費を固定費とみなし、プロジェクトのマネージメントから外すとすると、社内の人員の総数は一定ですから、マネージャによる人員の獲得はゼロサム競争になってしまい、人員の抱えすぎを抑止する方法が無くなってしまうのではないでしょうか?
- 2004-09-05 (Sun) 11:56:06 ''[[anonymous]]'' : 私の質問が不明確だったようですので、質問をやり直させていただきます。私はこのページの趣旨と違い、人件費をプロジェクト単位で集計すべきだと考えているのです。
- 2004-09-05 (Sun) 00:29:08 ''[[通りすがり]]'' : プロジェクト単位に集計するのが間違い>1. プロジェクトの優先順と優秀な人のスケジュール決め>2. スループットで評価>3. 2.>4. 以上
- 2004-09-04 (Sat) 22:34:00 ''[[anonymous]]'' : 追加質問です。4.下に書いたような、人員の抱えすぎを抑止するために、何か方法が存在するでしょうか?例えば、人員を多く抱えすぎて、予定より早く終わりそうなプロジェクトがあったとしても、そのマネージャは人員の抱えすぎが露見することを恐れて、わざと進捗を遅らせるでしょうから、プロジェクトの終了時期を見ても人材の抱えすぎは発見できないと思います。以上です。どうかどなたかお教えください。
- 2004-09-04 (Sat) 22:03:56 ''[[anonymous]]'' : 以上です。よろしくお願いいたします。
- 2004-09-04 (Sat) 22:02:04 ''[[anonymous]]'' : 3.プロジェクトの進捗への貢献度によって人を評価する、とのことですが、技術的な知識のないマネージャが、その貢献度を正しく評価できるのでしょうか?評価基準はコードの生産量?ステップ数?例えばシステム全体にかかわるデバイスドライバのバグを直そうとしているプログラマがいるとして、その人の作業の意味をマネージャが理解できなかったら?
- 2004-09-04 (Sat) 22:01:23 ''[[anonymous]]'' : 2.前の質問と関連しますが、優秀なプログラマを他プロジェクトから引っ張り込んでもマネージャが責任を問われないなら、どのプロジェクトのマネージャも「うちこそ人が足りない!」と主張して、他から引き抜きはやろうとするけれど、自分のプロジェクトの人材を他に提供するようなことを許そうとはしないのではないでしょうか?
- 2004-09-04 (Sat) 22:00:12 ''[[anonymous]]'' : 1.作業者の賃金を、固定費として考慮に入れない、としていますが、本当にこれでいいのでしょうか?例えば、会社中から優秀なプログラマを集めて行われたプロジェクトと、新人が一人だけでやったプロジェクト、この二つを同じコストとみなせるのでしょうか?
- 2004-09-04 (Sat) 21:59:24 ''[[anonymous]]'' : 全部読ませていただきましたが、私には意味がよくわかりませんでした。よろしければいくつか質問させてください。
- 2004-08-28 (Sat) 14:05:02 遅れているプロジェクトに他のプロジェクトから人を回す時は、高いスループットを短い期間で得られるプロジェクトを優先。これ常識。
- 2004-08-12 (Thu) 15:41:59 ''[[結論として追記しませんか]]'' : 組織全体がコスト至上主義からスループット至上主義へ転換をはかり、『経験年数やスキルではなく、プロジェクトの進捗への貢献度』とした評価基準で『高スキルプログラマを柔軟に活用』する。
- 2004-08-12 (Thu) 15:17:36 ''[[why]]'' : >全体の生産能力は一定だと仮定すると、『在庫を増やすために生産能力を使い過ぎると、相対的にスループットを減らす結果になる』
- 2004-08-12 (Thu) 15:13:23 ''[[テストを省略する原因]]'' : [A]ソフト開発期間を短縮するには、「人員を増やす」「作業効率を上げる」「作業を減らす」→単純に人員を増やすことは逆効果、作業効率を上げる難しい [B]「このままでは納期に間に合わない」場合、「納期を延ばす」「機能を削減する」「(主に)テスト作業を省略する」→言わなければバレないテストの省略
- 2004-08-08 (Sun) 12:57:52 ''[[Coffee]]'' : ありがとうございます。推敲版に置き換えさせていただきました。
- 2004-08-07 (Sat) 14:41:21 ''[[推敲版書いた人]]'' : 光栄です。どうぞご自由に使って下され。
- 2004-08-07 (Sat) 11:24:23 ''[[Coffee]]'' : 推敲版見てみました。すごくいいですね。このページの文章を推敲版に置き換えたいのですが、推敲版に署名が見当たりません(人のこと言えない>自分)。署名していただければ「書いた人」の段落に追加、匿名希望でしたら「書いた人」の段落を消して、置き換えたいと思います。お返事お待ちしております。
- 2004-08-07 (Sat) 10:46:36 ''[[Coffee]]'' : 小説「ザ・ゴール」の初版がアメリカで出版されたのが1987年。日本で訳書が出版されたのが2001年(著者は改善好きの日本人を脅威に感じていたため、しばらく翻訳を許可しなかったらしい)。先人は偉大です。でも悲しいかな、日本人は大人になるほど本を読まなくなる傾向があるようです。「ビジネス本なんて仕事の役に立たないよ」「本なんかより経験が大事だ」「それって子供向けの童話でしょ?」「まだまだガキだねー」。今まで散々言われてきましたが、本を読まないで成功した人なんていません。読書こそ最も有意義な時間の使い方だと、本気でそう信じています。
- 2004-08-05 (Thu) 14:58:17 ''[[TOCは周知の事実なのか]]'' : 製造工程のボトルネックを見つけ,これらを管理する(平成16年度春期試験 http://www.kimura-kouichi.com/test/20041/041pmex7.html)
- 2004-08-05 (Thu) 14:56:31 1.スループット(製品の売上高-原材料費・外注費)の増大、2.在庫(原材料費・外注費、仕掛品・製品)の低減、3.業務費用(原材料費・外注費以外の経費、総人件費を含む)の低減をすべし
- 2004-08-05 (Thu) 00:55:32 ''[[Coffee]]'' : あー。言われてみれば確かに紛らわしいですね。そこは考えてみます。
- 2004-08-04 (Wed) 11:36:43 ''[[仕掛品]]'' : すみません。やっと理解しました。 読み直したのでついでに>>各プロジェクトのスループットの合計から固定費を引くことで損益を求めることができる>>損益とスループットが逆じゃないですか?損益から固定費を引くとスループットがでるのでは?>>文意的にはスループットに固定費を足すと損益が出るが正しいのかな?。
- 2004-08-03 (Tue) 19:04:23 推敲してみた
- 2004-08-03 (Tue) 18:06:09 ''[[仕掛品]]'' : 書きかけのコードは書かれているように、人月ベースで費用(在庫?)扱いが一般的かと思います。
- 2004-08-03 (Tue) 17:21:19 書きかけのコードってそもそも、企業会計では、流動資産としてカウントしてるのでしょうか?その場合の金額はどういうルールで計算なんだろう・・・・。
- 2004-08-03 (Tue) 17:00:25 会計上の「在庫」=棚卸資産(商品、製品、半製品、仕掛品、原材料その他の資産)=貸借対照表の資産の部における流動資産(決算日からみて、1年以内に現金および現金等価物を受け取ることができると予想されるもの) >> 本当にその金額のキャッシュに変換できるか否か、にかかわらずカウントされる >> 「現実離れした価値を持つもの」by Coffee氏 >> TOCでは、こういうものを一括りで現時点無価値物(=スループットになる前の状態=「在庫」)として考え、これを如何にスループットに変えていくかということをマネジメント対象としている、という理解。同じ「在庫」という言葉なので混乱してませんか?もともと違うと考えるべき。 私の理解が間違ってるかもしれないけどね・・・・。^^;
- 2004-08-03 (Tue) 16:15:07 ''[[仕掛品]]'' : もう少し言うと、文章の趣旨に対して、作成中のプログラムをコストと扱うことは賛成ですが、在庫(ストック)と呼ぶことには語弊があるなと感じたというのが発端です。
- 2004-08-03 (Tue) 16:10:38 ''[[仕掛品]]'' : TOCが定義する「在庫」と、商法が定義する「在庫」の位置付けが異なるということが単純に、誤解を招き紛らわしいという風に思っただけです。ごめんなさい。
- 2004-08-03 (Tue) 14:27:42 ''[[coco]]'' : 失礼。下の2004-08-03 (Tue) 12:54:10の書き込みは、そのふたつ下の2004-08-03 (Tue) 11:18:22への質問です。
- 2004-08-03 (Tue) 12:54:10 TOCが定義する「在庫」と、商法が定義する「在庫」の位置付けが異なるということが、具体的にどのような問題を引き起こし得るとお考えなんでしょうか?
- 2004-08-03 (Tue) 12:47:54 トムは思った、とかでは? >3人称
- 2004-08-03 (Tue) 11:18:22 なんどもすみません。。ですから、仕掛品はまったく売れないもの、純粋な負の資産としなければ、なりませんが、在庫は売れようが売れまいが、売れるものとして、税金などの対象になるという事だと思うんですが…。いや、本質とは関係ないところにこだわってすみません。完成品か・未完成品かで商法上の扱いが違うことを問題にしています。
- 2004-08-03 (Tue) 10:15:23 3人称のやつ、全然3人称になってなくないですか?
- 2004-08-03 (Tue) 01:37:21 ''[[Coffee]]'' : 標準原価計算での在庫と仕掛品は、どちらも現実離れした価値を持つものとして扱われています。50%の工程を経て、50%の直接人件費が配賦された仕掛品は、果たして製品の50%の価格で売れるのでしょうか? もちろん、売れるはずがありませんね。もし『''標準原価計算がその成立当時と違って、現代の製造の現実と大きく乖離している''』のだとしたら……それに従って導き出した判断は、果たして本当に正しい判断なのでしょうか。
- 2004-08-02 (Mon) 17:44:11 売れればね。
- 2004-08-02 (Mon) 13:55:22 逆です、決算のときに、在庫はあくまでも、叩き売れば現金に戻せるもの・仕掛品は製造中で費用となるものではないでしょうか?TOCで見てるか決算ベースでみてるかの差でしょうか?
- 2004-07-31 (Sat) 15:49:02 [補足]原材料も仕入れて倉庫等に保管しているなら、それも在庫。
- 2004-07-31 (Sat) 11:15:19 ''[[Coffee]]'' : TOCでは仕掛品と完成品在庫を区別せず、共に「現時点で納品不能なもの=在庫」として扱います。これを一般化して、「現時点で十分なお金に変えられないもの=投資」と呼ぶこともあります。作った人が考えるほど、仕掛品には付加価値がありません。開発者が機能が50%完成していると言い張っても、開発者以外の人間にとって、現時点で動かない機能は無価値なのです。ですから正しい判断をするためには、「付加価値を考慮しないほうがベター」ということになります。
- 2004-07-30 (Fri) 19:51:11 ''[[coco]]'' : 私は文章の形式には特に違和感を感じませんでした。この小説を読んだときは、まだTOCの本を読んでなかったので、ツリーの見方が分からなくて少し戸惑いました。
- 2004-07-30 (Fri) 15:58:55 あんまり変わらんな。>1人称の場合
- 2004-07-30 (Fri) 12:47:08 「仕掛品」の「在庫」では?
- 2004-07-30 (Fri) 11:36:14 作成中の品は在庫ではなく仕掛品。
- 2004-07-30 (Fri) 07:53:55 ありがとう!
- 2004-07-30 (Fri) 05:56:15 とりあえず3人称の視点で書いてみた。つもり。>別のページ
- 2004-07-29 (Thu) 23:27:01 私は文章を(あるいは、文字の羅列を)書くことが出来ます。しかし、小説の作法に関しては極めて無知です。自分の文章が小説として正しくないことは自覚していますが、どこをどう直したら良くなるのかが分かりません。私はあなたのコメントを役立てることが出来るレベルに達していないのです。ですから、どうか別のページを作成して頂き、引用などを使って改善すべき点をご教授下さいませんでしょうか。
- 2004-07-29 (Thu) 12:25:52 小説としてNG。トムが思っているいることなのか場面の描写なのかといった1人称の視点と3人称の視点による書き分けができていない。
- 2004-07-29 (Thu) 07:51:20 ちなみに、『〜場合がある』系のステートメントは、「成立する状況下では本命の因果関係が強くなる」というふうに思ってください。
- 2004-07-29 (Thu) 07:41:07 wemaで『管理者は新たな人員の追加に極めて慎重である』のステートメントまわりを修正してみました。今度はどうでしょうか>論理がおかしくね?
- 2004-07-28 (Wed) 23:47:46 じゃぁ、まぁ根性で乗り切ってくれたまえ
- 2004-07-28 (Wed) 23:40:11 「6ヶ月の開発期間を予定していたプロジェクトだが、2ヶ月半もの遅れが出ている」んだろ?「問題は開発の遅れで、我々は解決策を探さなくてはいけない……そのため」の「高い金を払ってコンサルタントを雇った極めて重要な」ミーティングだろ? 『在庫を減らし、経費を減らし、スループットを増やす』だあ? 「考え方を変えるには時間がかかるかもしれませんが、最大限努力しましょう」 だあ? 「また何かあったら連絡をくれたまえ」だあ? まったく、おめでたい人たちでつね(w
- 2004-07-28 (Wed) 12:39:05 論理がおかしくね?『管理者は新たな人員の追加に極めて慎重である』原因は『プロジェクトが赤字であると判断されると追加投資(人員増加)が認められない場合がある』 その理由は『プロジェクトが赤字であると判断されると管理者の立場が危うくなる』 からであって、その判断基準が『プロジェクト単位でコスト(主に人件費)が集計され黒字or赤字が判断される』 ぢゃね? 横並びぢゃなくね?
- 2004-07-27 (Tue) 10:54:51 クリティカル・チェーンの「最遅スタートルール」も「在庫」の削減に寄与しますね。TOCってちゃんと繋がるんだ。
- 2004-07-27 (Tue) 10:08:22 ''[[kilin28]]'' : 別のところで議論され尽くされているかもしれませんがスループット経営(管理)とキャッシュフロー会計が同じであるのであれば歴史上どちらが先だったのでしょうか?
- 2004-07-27 (Tue) 06:55:55 日系ソリューションビジネス 特集名 CIOの直言、「
大きな勘違いをしていないか!」http://itpro.nikkeibp.co.jp/free/WAT/ITARTICLE/20040611/1/>雑誌。下の文はあくまで要約なので、そのままの文が載っているわけではないですけど。
- 2004-07-27 (Tue) 00:43:43 誰がどのセリフをしゃべっているのか分かりやすくしてほすい
- 2004-07-26 (Mon) 22:49:42 ''[[MAS]]'' : マネージメント層は、会社内ではゼロサムゲームなので、協力関係は結べない。のが一般的みたいです。
- 2004-07-26 (Mon) 14:31:49 ''[[TN]]'' : >「今日見た雑誌に書いてあった」ということですが、どの雑誌か、おしえてください。 
- 2004-07-26 (Mon) 14:00:11 章(各文章追加)の間の横線は残しておいたほうが、読みやすくなると思う。
- 2004-07-26 (Mon) 02:06:52 この手の例題では無能かもしれないが善良な人しか出てきません。Aさんの言いたいことは、この世には無能で邪悪で横槍がうまい人がいて、しかもその人が管理職だったりして・・ということでは?
- 2004-07-25 (Sun) 11:45:01 ''[[大ちゃん]]'' : 足場を作ってみました。[[Aさんのアンチデスマーチ]] 。ページ名が気に入らなければ変更してください。
- 2004-07-24 (Sat) 06:31:17 ''[[otsune]]'' : AさんはYukiWikiで新しいページを作ってここのコメントで主張していることをまとめてみるというアイデアはどうでしょうか?
- 2004-07-21 (Wed) 09:39:48 ''[[A]]'' : 危機っていうかだめなんだが、認識できるかどうかが問題。危機感なんて感じているならとっくにデスマーチなんて解決している。内側しか見れない人のなんと多い事よ。
- 2004-07-20 (Tue) 23:07:57 今日見た雑誌に書いてあった。「IT業界は自分たちの問題を解決することさえ出来ていないのに、顧客にITに傾倒した偽のソリューション(解決策)を売りつけようとしている。顧客は、利益増もコスト削減もまともに提案できないSIに、不信感を強めている」 これが危機でないとしたら、一体何なんだろう。
- 2004-07-20 (Tue) 22:02:36 こういうのはプロジェクトマネージャーとかより営業や顧客にみせてあげたほうがいいと思う
- 2004-07-20 (Tue) 09:20:27 今の日本だと、ソフト屋さんよりもハード屋さんの方がコレに当てはまる。
- 2004-07-20 (Tue) 09:08:48 ''[[A]]'' : ぶっちゃければ"危機感の欠如"である事は事実です。学習するって事は危機感があるからです。ではどうやって危機感を感じるのでしょう?その点が問題なのです。デスマーチに危機感を感じる企業などないのです。デスマーチになって危機感を感じるのは現場の開発者だけです。
- 2004-07-20 (Tue) 09:04:20 ''[[A]]'' : TOCという知識を周知な人はどこからTOCという単語を知ったのでしょう。"外部"から知識を吸収したはずです。この世界に"外部"のある事の認識がない人が"外部"から知識を吸収する事はありません。
- 2004-07-20 (Tue) 09:02:40 ''[[A]]'' : 根本がずれているようです。"優秀な"コンサルをやとえる、という事は"優秀さ"を評価できる、という事です。"優秀さ"を評価できる人は"優秀"です。そういう人がいるならそもそもデスマーチは発生しないか、ましな状態になります。
- 2004-07-19 (Mon) 23:47:12 もしどうしても人に聞くことが嫌なら、本に聞くという手もあります。ここだけの話、実は私も本に聞いたのです。何度も何度も。悩むたび、考えるたびに。
- 2004-07-19 (Mon) 23:41:50 ソクラテスの説いた「無知の知」の姿勢が、急成長の中にあるIT業界には欠けているようです。「驕れるものは久しからず。ただ春の夜の夢の如し」と、昔の人は言いました。「聞くは一時の恥、聞かぬは一生の恥」とも言います。完璧ではない自分を自覚して、学んでいく姿勢が大切だと思うのです。
- 2004-07-19 (Mon) 14:56:14 ''[[A]]'' : まあコンサルだけでなく内部改革を行なおうとしていたのですが、だめだった模様です。
- 2004-07-19 (Mon) 14:55:25 ''[[A]]'' : 以前、コンサルを雇うための詳細な試算をだそうとした人達がいましたが、噂が上部にたっしただけでとばされました。部署まるごとです。
- 2004-07-19 (Mon) 14:49:04 ''[[A]]'' : "優秀な"コンサルがやとえれば解決する事項もあります。ただし、コンサルの優劣など不明ですし、そもそもコンサルをやとって解決されるとこまるのです。外部の人間に解決されたら内部の人間の無能さがばれますので。絶対にコンサルを雇おうという提案は却下されます。
- 2004-07-19 (Mon) 12:27:44 コンサル雇って問題が解決するなら苦労はしないね。みんなとっくに雇ってデスマーチなんて無くなってるよ
- 2004-07-18 (Sun) 23:15:00 ''[[takano32]]'' : 確か「デッドライン?ソフト開発を成功に導く101の法則」ですね.>こういう文体のプログラミング関係の本
- 2004-07-17 (Sat) 12:13:43 ただいまデスマーチ参加中。
- 2004-07-15 (Thu) 13:03:28 ''[[Q]]'' : 面白い小説ですね。続きを楽しみにしています。ところで署名がないようですが、この記事はどなたが書かれているのですか? Wikiだから不特定多数の方の共同執筆なのでしょうか?
- 2004-07-15 (Thu) 09:08:42 ''[[A]]'' : おもしろいのは確かですね。でもTOCなんてすでに周知の事実です。それ以前の問題なんです。デスマーチが発生する原因は。
- 2004-07-15 (Thu) 03:28:05 分野が違うので自信がありませんが、TOCは「束縛条件付き理論」なんて感じをうけますが。
- 2004-07-15 (Thu) 01:16:40 結構わかりやすいと思うんですが。こういう文体のプログラミング関係の本、ありましたね。
- 2004-07-14 (Wed) 23:11:47 小説と考えれば言いたい事見える必要もないのでは?  楽しませてもらってます。
- 2004-07-14 (Wed) 12:38:42 「ザ・ゴール2」よりもまず「ザ・ゴール」を読むべきでは?#この文章、すごく読みにくいです。筆者の言いたいことが見えません。
- 2004-07-14 (Wed) 09:03:10 ''[[A]]'' : 市場の変化が理解できるというのはこの世に外の世界がある事を認識できている人がいるという事で、相当に理想的です。そもそもコンサルを呼ぶ事を決定できる人がいるなんてこれ以上ないほど幸運な状態です。
- 2004-07-14 (Wed) 08:57:27 ''[[A]]'' : 「現状維持=何もしない」などとは書いていません。現状を維持するための努力は大変な物です。まあ努力せずにいろいろできるわけですが。。市場の変化が理解できる人がいる、というのはかなり理想的な状態です。
- 2004-07-13 (Tue) 23:42:16 なるほど。今が良ければそれでいい、後は野となれ山となれ、というわけですか。しかしそれも「前提が違う」のです。ある組織が現状維持を望んでも、市場はそれとは無関係に変化してしまいます。すなわち「現状維持=何もしない」という暗黙の前提が、間違っているのです。
- 2004-07-13 (Tue) 17:21:12 ''[[A]]'' : このような文章においては常にある違和感は「前提が違う」という事です。あらゆる組織が現状を打開したいと考えているとする前提がまちがっているのです。混乱が収束されると困る人達がいるのです。その点は注意しないといけません。
- 2004-07-13 (Tue) 17:13:32 ''[[A]]'' : 子育ては確かに将来への投資です。しかし親が魚をとるのに忙しく、魚取りを本当に教える事が可能でしょうか?また魚取りの技術がない親にそだてられた子供が立派な魚取りになれる事はかなり奇跡的な事です。
- 2004-07-13 (Tue) 15:42:06 殺す時に注意すべきはルールをおおやけにする事です。決して隠蔽してはいけません。
- 2004-07-13 (Tue) 15:37:05 将来への絶望であればすでにしています。一人二人死んんだ所でかわりません。重荷がへって幸福になるだけです。
- 2004-07-13 (Tue) 09:57:45 子供を育てるという策は、教育という将来への投資を選択することです。それは、短期的には何も生産しない、割りに合わない投資に見えるかもしれません。でも、子供を育てることを放棄したなら、その家族は遠からず存続できなくなるだろうと私は思うのですが、いかがでしょうか。
- 2004-07-13 (Tue) 09:51:38 もし老人を殺せば、大人と子供は将来に絶望し、働く意欲を失うかもしれません。3匹しか魚が手に入らなければ、次は自分が殺されるのだろうと思われたなら、きっと本当に、4匹すら取れなくなるでしょう。レイオフは悪循環を生むだけの、その場しのぎの策です。
- 2004-07-13 (Tue) 09:41:06 現実には、逆に、老人を守ろうとして新規雇用を凍結しているところもあるようですね。進む少子高齢化が技術不足を生み、IT産業を空洞化させてしまうのではないかと心配です。
- 2004-07-13 (Tue) 08:58:54 食料調達プロジェクトの例にしてもWhiteRabbitさんの例はまだ理想的です。もっと酷いです。問題は、それで家族が生活できるかどうかを問う場合なら、まず老人を殺ろせるかを考慮に入れないといけません。
- 2004-07-13 (Tue) 08:56:43 こういうのを読むと、書いている人は本当に「現場」体験した事あるのか疑問に思う事があります。「現場」の現実はもっと残酷です。何もしない方が増しという場合もあります。
- 2004-07-12 (Mon) 19:42:55 ''[[kekke]]'' : デスマーチって絶版されてます7よね?どーにかして、再販されないかしら。。。
- 2004-07-12 (Mon) 19:34:07 こんなカッコつけてるだけのコンサルタント高い金払って雇う時点で、もうこの会社だめだろ。そりゃデスマーチ起こるよ。
- 2004-07-12 (Mon) 13:13:04 ''[[n_ryota]]'' : 高スキルのプログラマが少人数というと、Googleっぽいですが、たしかにありだと思います。一般的な人を高スキル(価値を生み出す能力が高い状態)にするのがゆとりとかXPとかそういう方法論なのかな・・・? 分からないなりにいろいろ(http://cafe.eyln.com)で考えたりもするんですが、いまのところマネジメントの分野においてでも「ソフトウェア開発の抱える問題を『一発で』解決できる」ような銀の弾丸はないんじゃないかと思っています。
- 2004-07-11 (Sun) 23:35:47 鬱だ……ブルックスだった。御指摘感謝。
- 2004-07-11 (Sun) 22:51:08 ''[[誰?]]'' : 「銀の弾はない」ってデマルコだっけ?
- 2004-07-11 (Sun) 22:34:37 「プロジェクト単位のコスト集計が生み出す『コスト増の妄想』」 私はこれこそプロジェクト単体でしか見ていない馬鹿の詭弁だと思いますがね。
- 2004-07-11 (Sun) 22:25:49 人員の再配置に「時間」がかかるのは事実です。しかし、どれだけ「コスト(お金、追加投資)」が必要になるというのでしょうか。私は、人事コストは「ほとんどかからない」と思いますし、人員の再配置を前提にドキュメント等を整備するようにすれば、教育などで「無駄にする時間」もずいぶん減らせると思いますよ。「無駄にする時間<短縮される開発期間」であれば、再配置を躊躇う理由はないはずです。
- 2004-07-11 (Sun) 22:15:15 「総合的なコストの変動さえないのなら、人事コストの変動はないと言えるのか?」
- 2004-07-11 (Sun) 22:01:45 その懸念はあるかもしれませんね。しかし、だからといって何もしなければ、食料調達プロジェクトは黒字なのに、家族は飢えたまま(赤字)になるでしょう。問題は、それで家族が生活できるかどうかです。
- 2004-07-11 (Sun) 21:28:49 ''[[WhiteRabbit]]'' : そうですか?魚獲りの例えだと、子供の参加が大人の成果に影響しないという暗黙の前提がありますよね。でもソフト開発では「低スキルのプログラマがバグを入れる」とか、「プロジェクトに詳しくない人間に教えなくてはならない」とか、そういったマイナス要因があるはずです。毒キノコはそういった比喩です。
- 2004-07-11 (Sun) 21:00:52 毒キノコがあるという前提を付け足したなら、それは完全に別の話ですよ。比較は無意味です。
- 2004-07-11 (Sun) 20:51:02 ''[[WhiteRabbit]]'' : 食料調達プロジェクトの例えなら、こっちのほうが則していると思います。ある島に6人家族がいました。その島はキノコの宝庫でしたが、毒キノコも生えていて、しかも抜いてしまうと普通のキノコと区別がつかなくなる点がやっかいでした。食料の余裕があるうちはキノコに詳しい大人だけで足りていましたが、なぜか食料が厳しくなり、子供にもキノコを探させることになりました。しかし、子供は運悪く毒キノコを持ち帰り、それと知らず食べた大人が寝込んでしまって、さらにひもじくなりました。
- 2004-07-11 (Sun) 18:44:31 次の食料調達プロジェクトでは、6匹の魚を手に入れました。大人は2匹ずつ、子供は1匹ずつ、魚を獲りました。計6匹です。効率は150%に落ちましたが、それがどうしたというのでしょう。その家族はもう飢えることはありませんでした。めでたしめでたし。
- 2004-07-11 (Sun) 18:43:56 「人間よ。お前の家は6人家族ではなかったのか。収益4匹から6人分のコストを引けば、2人が飢える計算になる。『プロジェクト毎にコストを集計してはならない』のだ」「ではどうすれば?」「食料調達プロジェクトに、子供を連れていきなさい」「しかし子供たちは狩りが上手くありません。効率が落ちます」「それがどうしたというのかね?」
- 2004-07-11 (Sun) 18:22:56 「家には、おじいさんとおばあさん(老人2人)、息子と娘(子供2人)、そして、私と妻(大人2人)がいます。食料調達プロジェクトは、私と妻の2人で始めました。そして、大成功を収めました。なんと、4匹もの魚を手に入れたのです!4匹から支払ったコスト2人を引くと、このプロジェクトは2匹もの黒字です!効率は200%です!大成功です!さあ、褒めてください神様!」
- 2004-07-11 (Sun) 15:33:58 ''[[kan]]'' : 「今、家の建築に5人、畑を耕すのに5人が担当してますが、家を早く建てたいので、これから建築に10人、食料調達0人とします。一日に消費する食料は同じですから、なんら問題はありません。食べ物がなくなる?畑で出来る食料の計算なんて難しいし、してはいけない決まりなのです。大原則なのです。」
- 2004-07-11 (Sun) 14:03:27 ''[[ボブ]]'' : コストに収益を加算して、あたかもコストが減ったかのように扱ってはならない ―― 会計の大原則。 kanさんは、会計の定義通りのコスト計算をしていないようですね。しかし、まあ、それが賢明です。会計も原価計算も結局のところ、判断の役には立ちません。
- 2004-07-11 (Sun) 06:35:03 ''[[無名]]'' : 本当に「利益を含めてコスト計算する」ところならこの問題に陥らないからでしょう。「生産するであろう利益」を計算できるなら、最初に人員を決める時点でデスマーチにならないようにできるし、その計算が間違っているなら言及する意味は無い。
- 2004-07-11 (Sun) 04:12:59 ''[[kan]]'' : 人材が非生産プロジェクトに参加する場合、その人物が生産するであろう利益を含めてコスト計算する。このことが全く抜け落ちているのはどういうことですかね。まるで三流小説ですね。
- 2004-07-10 (Sat) 17:45:49 ''[[あ〜る]]'' : 面白いですね、何気なく開いて見入ってました。
- 2004-07-10 (Sat) 12:52:33 ''[[あ!]]'' : 現在進行中・・・ ふう。。。
- 2004-07-10 (Sat) 12:31:06 ''[[m]]'' : 「運用開始時のシステムの要求定義を最小限のものに絞り込む」もありかな?
- 2004-07-10 (Sat) 12:28:51 ''[[m]]'' : 続きは「開発者が複数案件を並行して手掛け,生産性アップ」とか,「ユーザ(ここでは営業)をプロジェクトに巻き込んで,仕様決定への参加を促す」とかかな?
- 2004-07-09 (Fri) 17:27:58 ''[[ながせあきひろ]]'' : いえ、どこがどう段落になっていたのかまで覚えているわけではない以上、人の文章に改行位置とはいえ推測で手を加えるのに抵抗を感じまして……。とりあえず、現時点で段落は直っているようですね。
- 2004-07-09 (Fri) 12:59:49 ''[[小人さん]]'' : そう思ったら、コメント付ける前に直そうね、ながせさん。
- 2004-07-09 (Fri) 11:12:48 ''[[ながせあきひろ]]'' : なんか改行が消えてしまっている様に見えます。昨晩見たときにはちゃんと段落に別れてたんですが……
- 2004-07-09 (Fri) 10:42:48 ''[[minap]]'' : せめて、行頭字下げと改行ぐらいは入れた方が読みやすいかと。(w;
- 2004-07-08 (Thu) 23:27:16 ''[[yoosee]]'' : 続きは「(会社)全体効率化」のために「(ボトルネックの)部分効率化」を図る(ボトルネックに優秀な開発者を動的にアサインする)と言う形になるのかなぁ。TOC が出てるんだから制約条件下での全体効率化と言う方向にいきそうな気がしますね。
- 2004-07-05 (Mon) 09:22:51 ''[[kohn]]'' : 『プロジェクト単位にコスト(人件費)を集計することは間違っている』という説、非常に興味深いです。今後の展開を楽しみにしています。