セントラルファイナンスのサイトです。
まとめる 参考 アプラス そして 返し 分類 人物 整理 咎め 挑戦 区分 保証 ジャックス 窓口 見送り 目標 仕方 ジェイ 集約 グリーン クレディア 移行 有料 異動 著作 足り 給料 免許 単独 カーン

前提とは？/ セントラルファイナンス

[ 519] デスマーチが起きる理由 - ３つの指標
[引用サイト]　 http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。
まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。
それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。
それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。
スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。
そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。
十数人の同僚たちが私を見つめる中、見慣れない男――背は低く、おせじにもカッコいい奴には見えない――がこちらを見ていることに気づいた。
「その通り。私はジョナサン。君はトム君だったね。すぐ来ると聞いて、君を待っていた。さあ、ミーティングを始めよう。大切なミーティングだ」
彼は矢継ぎ早にそう言うと、中央に戻っていった。何が大切なミーティングだ――席に座って私は思う。こんなものは時間を無駄にしているに過ぎない。
「ミーティングを始めるにあたって、まず現状を確認したい。もらった資料は少し古くなっているからね。誰か、現状を説明してもらえないだろうか」
そう言われて立ち上がったのはアレクサンドだった。少し融通の利かないところはあるが、かなり頭の切れる奴だ。私も一目置いている。
「この販売管理システム開発プロジェクトは、2月の頭から開始しました。当初のプロジェクト完了予定日は、7月末。
つまり、開発期間は6ヶ月と見積もられていました。しかし、今がいつであるかお分かりでしょう。既に10月の半ば……つまり2ヶ月半の遅れが出ています。
彼の言っていることは、このミーティングに来ている連中ならみんな理解している。理解していないのはあのコンサルタントだけだ。
「一つ質問させてもらいたい。今、『早急な』『一刻も早く』と言ったが、何故なんだね？正確な理由を教えてくれないか」
「それは……来年一月からの運用が予定されているからです。運用時にバグが出るといけませんから、最低でも1ヶ月のテスト期間が必要です。
それも、みんな分かっていることだ。とにかく時間が足りない。毎日残業しても、まだ足りない。せめて運用が4月あたりに先延ばしになってくれれば、何とかなるのだが。
「状況を整理してみよう。当初は6ヶ月の開発期間を予定していたプロジェクトだが、2ヶ月半もの遅れが出ている。
誤解を与えないように言っておくが、君たちを責めているわけじゃない。責任だとか、上下関係だとか、そんなことはどうでもいい。
問題は開発の遅れで、我々は解決策を探さなくてはいけない……このミーティングはそのためのものだからね」
私は、資料を眺めるふりをした。馬鹿げたミーティングだ。このプロジェクトを救えるはずが無い。我々は解決策を探さなくてはいけない。
そんなことを言うだけなら誰にだってできる。猿にだって言える。私の上司にだって言えるだろう。……いや、言えないかもしれない。
そんなことを考えていたため、少しの間、彼の言葉は耳に入らなかった。顔を上げると、彼がプロジェクターで何かのスライドを表示するところだった。
「努力、友情、勝利」と書かれたスライドが現れて、彼の御高説が始まるのかと思っていたが、そうではなかった。
表示されたのは、何の変哲も無い付箋紙を矢印で結んだだけの、ツリーだった。上にはデスマーチと書いてある。まさにこのプロジェクトのことだ。
私の変わりにステーシーが質問した。彼女は知らないことを人に尋ねるのが得意だ。様々な分野の知識を持っている彼女にも、どうやら知らないことがあるらしい。彼はゆっくりと答えた。
「人は、自分が問題を認識していると思っている。全ての前提は頭の中に入っていて、自分は正しい判断をしているのだと信じている。
自分が一番難しいモジュールを開発していて、だから一番残業していて、もちろんこのプロジェクトは最大限効率的なのだと信じている。
彼が何を言っているのか、最初、よく分からなかった。だが、暗に自分たちの努力を否定されているのだと気づくのに、そう時間はかからなかった。
みんなも同じだったようだ。すぐに、「そんなはずはない」「何を考えているんだ」「俺たちを非難しにきたのか」と野次が飛んだ。
「『必要な時に必要なだけのスキルを持った開発者を投入しないと、プロジェクトは遅れる』」彼は言った。そんなこと常識だ。
「これが常識だということは理解してもらえると思う。だが、私がこれまでに見てきたほとんどのプロジェクトでは、
――今、うちの会社で一番問題になっているのは、営業部門だ。とはいっても、今期の営業成績が特に悪かったというわけではない。
大手顧客のほとんどから同じ苦情を言われている、と言えばお分かりだろうか。要するにレスポンスタイムの改善を要求されているのだ。
大量に使われていた紙の書類を減らし、必要な情報全てをデータベースに登録し、情報にどこからでもアクセスできるようにして迅速な営業を顧客に約束する。
そのためにこのプロジェクトは始まった。これっぽっちの人数で、なかなかどうして、社運を賭けたプロジェクトじゃないか。
ユーザ代表と話し合って仕様を決めるSEの数が足りないと不満を言ったことがある。そのとき、彼らは何をしてくれただろう。何もしてくれなかった。
必要な時に必要なだけのスキルを持った開発者を投入してくれなかった。この常識が守られていなかったから、このプロジェクトは遅れたというのか？
もし１月の運用に間に合わなければ、プロジェクトマネージャーの首が飛ぶことは間違い無い。おそらくプロジェクト関係者の昇進の話も無くなるだろう。
その妄想を振り払ってスライドを見ると、彼の持つ棒（どこから引っ張り出したのだろう？）の先には、そう書かれた付箋紙があった。彼の問いかける声が耳に入った。
『管理者は新たな人員の追加に極めて慎重である』というやつだ。これには同意してもらえると思う。そして、その下にもステートメントがある」
最後のステートメントの控えめな表現に、みんなが笑った。吹き出してしまった奴までいる。私も、ここまで控えめな表現は見たことが無い。
だから『プロジェクト単位でコスト（主に人件費）が集計され黒字or赤字が判断される』にあてはまっているはずだ。
また、『プロジェクトが赤字であると判断されると追加投資（人員増加）が認められない場合がある』にも覚えがあるだろう。
そして最後に、『プロジェクトが赤字であると判断されると管理者の立場が危うくなる』だ。特に反論は無いと思う」
「さて、それぞれのステートメントは常識的なことに過ぎないが、下から上に、矢印を辿って読んでみよう。問題が見えてくるはずだ」
本当だろうか？一つ一つのステートメントに違和感は無かったように思うが……私は言われた通りに下から上へと視線を移動させる。
「ところで、『プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する』という事について考えてみよう。
コミュニケーションや資料作成が無駄だと言っているわけではない、ただ、善悪とは無関係にそういう傾向が存在していることは認めてもらえると思う」
私は、またスライドを見た。こんなに真剣にスライドを見たミーティングは、何年ぶりだろうか。右側のステートメントに目を通す。
いきなりのご指名にいささか狼狽しながらも、私は立った。みんなの顔を見渡して僅かに時間を稼ぎ、その間に考えをまとめる。よし。私は意を決して口を開いた。
まず、『顧客は納期遅れが不満であり、管理者に絶対の納期厳守を要求する』という当然のイベントが発生します。
私たちのプロジェクトの場合、顧客の部分は営業部門であり、より大局的な視点では経営者であるということになります。
次に、『管理者は慌てて（スキル?を問わずに）開発者をかき集め、遅れているプロジェクトに投入する』ということになります。
これに加えて、『スキル?が低すぎる開発者はスキル?が高い開発者の時間を奪い、明らかに足を引っ張ることさえある』
かつ『プロジェクト内での上下関係は職場の上下関係を反映しており、プロジェクト遂行のために最適化されているとは言い難い』とすれば、
『プロジェクトの人員が増えれば増えるほどコミュニケーション、資料作成ための時間が増え、実質的な開発効率は低下する』ことは明白です」
言い終わって、みんなの視線を一心に集めていることに気づいた。どうして私なんかに注目するのだ？なんとなく気まずさを感じながら、私はそのまま着席した。
「話をまとめてみよう。トムの読み上げてくれたツリーから分かることは、スキルを問わずに『多数の人員を投入すればするほど、プロジェクトは非効率的になっていく』ということだ。それでは納期は守れない」
吐き捨てるような言葉に、私は愕然とした。私が読み上げたツリーの内容を、ヨハンはまだ理解していないのだろうか……それとも、理解したくないのだろうか。
「確かに『管理者は新たな人員の追加に極めて慎重である』が、遅れているならそれをカバーするのは、当然のことじゃないか。人が足りていないからなんだろう？なら、外部から人を連れてくれば良い。これで、『プロジェクト遂行に十分なだけの人員が存在している』」
「今のままでは何もかも不十分です。特に、Bモジュールの進捗の遅れをカバー出来るスキルを持った開発者が足りていないんです！」
「よろしい。つまり、開発者の視点では『プロジェクト遂行に必要となる必須スキルを持った開発者が十分に存在していない』ということだ。
一方、トムの読み上げてくれたツリーから分かることは、スキルを問わずに『多数の人員を投入すればするほど、プロジェクトは非効率的になっていく』というわけだから、
従って、『開発側が求めているのは、少数の高スキル開発者の投入』だということになる。アレクサンド、そうだね？」
今でさえ赤字ぎりぎりのプロジェクトなんですよ。もしそんなことをすれば、プロジェクトは一気に赤字になるでしょう。
マネジメントの本質は、納期と予算の両方を守ることです。そのバランスが大切なんです。高スキル開発者の追加は一切認められません」
開発期間とコストの両方を守るだと？ならばこのプロジェクトの遅れは何だと言うのだ。メンバーの努力が足りないとでも言うつもりなのか。
「よろしい。つまり、管理者の視点では『コスト（人件費）の極端な増加を避けるため、遅れているプロジェクトへの人員追加を行う際には単価の安い低スキル開発者が優先される』。
……このプロジェクトには確かに矛盾が存在している。開発者にも、管理者にも、どちらにも言い分がある。大きな対立だ」
「ツリーのほうを見れば、それは明らかだ。プロジェクトに遅れがでないようにしたい、これは顧客と開発者の望むマネジメントだ。
彼らは始めのうちは予算を重視している。しかしプロジェクトが大幅に遅れていることを顧客に責められると、
予算を無視してでも納期に間に合わせようとして、大量の人員投入を行う。ここで、『予算を守る』という方針を、あっさり捨てているのは何故かね？」
「……私たちがこれまで上手くマネジメントできていなかったのは、この矛盾と関係があるということですか？
「予算を守ろうとする考え方は、納期を守ろうとする考え方と、相容れないように思える。二つの方針は矛盾している。真っ向から対立している。
「考え方が対立しているように見えるからと言って、本当に対立しているとは限らない。大抵は、どちらか考え方の前提が間違っているだけであることがほとんどだ」
しばらく、そのステートメントにみんなの視線が集中した。今の今まで、疑ったことなど一度も無かった。みんな当然の前提と思っていたことだ。
あたりまえの常識だったはずのことだ。これが、間違っているかもしれないとでも言うのだろうか。馬鹿げている。だが、もし、そうだったなら？どういうことになるのだ？
「私は、会計を専門に学んできました。ですから、コストについてはここにいるみんなよりも多少分かっているつもりです」
「知っている人も多いでしょうが、コストには、変動費と、固定費があります。これは原価計算の基本的な考え方です。
まず変動費はその名の通り、変動するコストです。変動は生産量に比例する、と定義されています。次に固定費ですが、これは固定しているコストです。
「変動費は、製品のコストとして製品原価の中に集計されます。製品を作るために使ったコストを製品に集計するのですから、この集計には確かな根拠があります。
ですから、『固定費を製品のコストとして製品原価の中に集計することには、正当な根拠が無い』ということです」
そうやって誤差が大きくなれば一部の製品の原価は高くなりすぎて、製品価格も高くなりすぎ、製品は売れなくなる」
私はボブの言う原価計算の話を聞きながら考えていた。ボブの言ってくれたことが、どうプロジェクトのコスト計算に繋がるだろうか。まだ分からない。
アルバイトやパートタイマーなら時間給で雇うことができます。ジョナサンのような一時雇いのコンサルタントも……変動費として扱うことができると思います。
しかし、社員はどうでしょうか。社員の給料は、企業全体で見れば、常に一定額支払われることが決まっているコストです。
ですから、先ほどの製造業の常識をこの業界にあてはめると、『人件費をプロジェクトのコストとしてプロジェクト単位に集計することには、正当な根拠が無い』
会議室は、水を打ったように静まり返った。みんな、ボブが言ったことに矛盾が無いかと考えているのだろう。
いや、矛盾を探そうとするよりも、直感を働かせればいい。毎月会社が払う人件費は、プロジェクトに投入した人員の数に比例しない。
「『プロジェクト単位にコスト（人件費）を集計することは間違っている』。ボブの言っていることが正しい。私の使っているコスト計算方法は間違っている！」
自分たちが間違った常識を信じていたのだと、もうみんな理解していた。ヨハンはジョナサンのほうに振り向いて言った。
今にも掴みかからんばかりの勢いだった。それでも、ジョナサンはポーカーフェイスだった。小さく、しかしはっきりとした声が、会議室に響いた。
ああそうか。私は唐突に彼の冷静さの理由を理解した。ジョナサンにとっては、常識が間違っていることなど、あたりまえのことなのだろう。
「先に進む前に、『プロジェクト単位にコスト（人件費）を集計することは間違っている』という仮定について、もう少し考えてみたい。いいかね？」
「ボブの説明では、変動費と固定費という用語が使われたが、より原価計算の定義に正確に言うのであれば、直接費と間接費という言い方も出来る。
直接費と間接費は相対的な概念で、ある視点で見た場合にコストの発生と相関を持つか否かによってどちらに分類されるか変わってくる」
「今までのプロジェクトマネジメント手法の大きな間違いは、本来であれば企業全体の間接費として考えなければならない固定的な人件費を、
あたかも直接費であるかのようにプロジェクト単位に集計してきた点にある。『人件費はその大部分が固定費・間接費である』という事実を無視し、
『プロジェクト単位にコスト（人件費）を集計する』とき、『コストの配賦誤差が大きくなりすぎて、正しいマネジメントの障害になる』ということだ」
「一つ、面白い質問をしよう。今まで別の仕事をやっていた雇用済みの人員をプロジェクトに参加させた。企業の支払うコストは、増えるだろうか？」
「そうだ。コストは増えない。プロジェクト単位のコスト集計が生み出す『コスト増の妄想』は、こんな基本的なことさえ忘れさせてしまう。
二つ目の質問だ。プロジェクトに参加していたメンバーをプロジェクトから外した。企業の支払うコストは、減るだろうか？」
「減りません。ただし、そのメンバーがプロジェクトの期間だけ雇われている臨時雇用の人員でなければ、ですが」
「そのとおり。見せ掛けのコスト削減を理由にプロジェクトのメンバーを減らしたところで、『コスト節約は妄想』でしかない。
プロジェクトAに参加しているメンバー2人とプロジェクトBに参加しているメンバー1人を交換した。企業の支払うコストは、変わるだろうか？」
「しかし、非現実的です。ジョナサン、私にはあなたの言っていることが机上の空論であるようにしか思えません。
まるで、別のプロジェクトから開発者を引っ張って来ることが出来ると思われているように聞こえますが、そんなことは不可能です。
現実として、高スキルプログラマはどのプロジェクトでも足りていません。頭を下げたって断られるのがオチです。
ふと、私はアイスコーヒーを見た。もうすっかり氷は溶けてしまっている。魔法か。そんなものは存在しない。
物理法則は誰にも変えられない。好き勝手に時間を遡ることも出来ない。魔法などというものは存在しない。当たり前のことだ。
当たり前だって？ 私は自嘲する。今日は信じていた常識が崩れた日じゃないか。もしかしたら、魔法だってあるのかもしれない。
私たちに無くて、ジョナサンにあるものは、何だったのだろう。何が違ったのだろう。彼は部外者だった。だから常識の間違いに気付くことが出来たというのか？
いや、違う。この業界には毎年、別の業界からたくさんの人間が流れ込んできているのだ。それは理由ではない。
だとしたら、違いは何だ。あの常識を書いた付箋紙を寄せ集めたツリー。ジョナサンは確か、現状問題構造ツリーと呼んでいた。
そしてホワイトボードに書かれた図、対立解消図。前提を考え、正しい判断をするために、あれを使ったのではなかったか。
もし、物理法則を変えずに、現実を今より良くするための手法があるとしたら。ジョナサンが、それを知っているのだとしたら。
私も信じられない。『人月の神話』は読んで知っている。だが、まさか、本当にあるというのか？そんなものが。
「この業界で働くもので知らない人はいないと思うが、『狼人間を撃つ銀の弾はない』とブルックスは書いた。
これは、ソフトウェア・プロジェクトの困難性はソフトウェアの複雑性や人間であるが故の不確定性によるものであり、
技術的なアプローチによる魔法の解決策は無い、という意味だ。この言葉が言われてから、20年以上が過ぎた。
「ブルックスはそう書いている。銀の弾丸などこの世界のどこにも存在しないのだと宣言しているわけでは、決して無い。
彼はこの業界の絶望を望んでいない。現状の改善を諦めることを推奨するためにあの論文を書いたのではない。
『銀の弾丸』が、技術的アプローチ以外の分野に確かに存在するのだと信じて、あの論文は書かれたのだと思う。
あの言葉は、パンドラの箱の最後にあったものだ。それは一見災厄そのもののように見えるが、その実、希望なのだよ」
「続けてください」アレクサンドが言った。「技術的なものでなくてもかまいません。もし知っているのなら、教えてください。『銀の弾丸』とは何なのですか」
私は何も言えなかった。『人月の神話』を読んで、あのとき私は自分を笑った。こんな業界にいるなんて、俺はなんて馬鹿なんだろうと。
そして本棚の奥にあの本を突っ込んで、……私は何をしたのだろうか。私は毎日、ただ悪態を吐いていた。考えることもせずに。
少し英語を知っていれば分かることだが、『銀の弾丸』は『魔法の解決策』の代名詞だ。しかし、そこで立ち止まってしまっては意味が無い。
容易には理解できない、複雑にもつれあった事象を整理したり、誰も解けなかった問題を一段上の視点から判断し、結論を出したりすることだ。
『部外者が問題を解決する過程を無視して結果だけを取り出すから、魔法に見えてしまう』だけだ。例を挙げよう」
「14世紀、あるところに嘘吐き男がいた。彼は若かった。いつも夢を見ていて、口ばっかりで、非現実的な話ばかりを約束して、貴族たちの援助を受けようと必死に駆けずり回っていた。
彼がどんなに壮大な嘘をついていたのか教えよう。『地球を逆向きにぐるりと一巡りして、スパイスの宝庫、アジアに辿り着いてみせましょう！』」
「彼は、本人が自覚していたかどうかはさておき、アメリカ大陸を発見した――すくなくとも、そこが怪物の待ち受ける海の果てではないことを証明した。
『いいや、それがな、女王の前で、持ち帰った宝を見せたらしい』『なんとまあ！』ああ、それはまるで、魔法のような話だ。結果だけを見れば」
そして丸いのであれば、直径の計算に多少の誤差があったとしても、反対側を回ればいずれ目的地に辿り着く。
「ならどうして、貴族たちはコロンブスを支持しなかったのかしら？」ステーシーの疑問は、みんなの疑問を代弁していた。
誰もが納得していた。コスト計算にしたってそうだ。常識が間違っていると言われて、はいそうですかで済むはずが無い。
だとすると……、やはりあのツリーや図は只者ではないということになる。コスト計算に関する私たちの常識を改めさせたのだから。
「コロンブスは、結果が『劇的な効果』をもたらすと分かっていた。当時、新航路の発見は国を挙げての一大事業だったためだ。
そして、新航路の発見はまさに『解決策』だった。『現状が改善される策、アイデア、ひらめき』、それは、『地球を逆向きにぐるりと一巡り』することだった。
「『劇的な結果』だけを取り出したなら、それは『魔法』だ。しかし、やっている本人にとっては、それは魔法ではない。
いわゆる『銀の弾丸』は『劇的な結果』である『魔法の解決策』の代名詞だが、私たちの求めているのは『コロンブスが使った魔法の解決策』ではなく、
『私たちだけの常識外れな解決策を作り出す方法』だ。それこそが『銀の弾丸』と呼ぶに足るものだ。そうは思わないかね？」
みんなが頷いた。もう誰も、銀の弾丸が無いとは思っていないようだ。見つけてやろう。そんな気持ちになっている。
「理由は、『別のプロジェクトも遅れている』ということです。ですから、別のプロジェクトから開発者を引っ張ってくるなんて無理なんです」
その言葉に、私はため息をついた。そうだ。別のプロジェクトも遅れている。そうして結局、振り出しに戻るのだ……本当に？
違う。上手く言葉にならないが……違和感を感じる。まるでバグが残ったソースを見たときのような気分だ。この感覚を無視してはならないと、プログラマとしての勘が告げている。
「ステーシー、それは違うんじゃないかな」知らずに、私の口が動いていた。「『一番遅れているプロジェクト』は、常に一つだと思う。
だとしたら、比較的遅れていないプロジェクトから開発者を引っ張ってくることが出来ない理由は、ほかにあるんじゃないか？」
「そんなはずは無いわ。いつだってそう言って、別のプロジェクトのマネージャーは開発者の再配置を許可しないのよ」
ステーシーは譲らない。ステーシーはいい加減なことを言ったりしない。別のプロジェクトのマネージャーは本当にいつもそう言っているのだろう。
それでも、何か別の理由があるはずだ。ステーシーが何か言おうとするのを制して、ヨハンがその理由を答えた。
「マネージャーの言い分のことなら私に聞いてくれ。今だから言えるが、『高スキルプログラマの柔軟な活用が出来ない』のは、
どうしてそんなことをするのかなんて聞かないでくれよ。今まで話してきたことだ。『プロジェクト単位のコスト集計の悪影響』だよ。
もしプロジェクトに余裕があるなんて知られようものなら、あらゆる方面から圧力がかかる。まったくコスト削減の圧力といったら、凄まじいものだよ。
『メンバーを減らしてコストを減らし利益を上げろ！』この方針に反論などしようものなら、あっという間にクビを切られる」
「でも、『プロジェクトに参加していたメンバーをプロジェクトから外してもコストは減らない』のだから、それは全く理不尽な圧力です。馬鹿げています。
こんな理不尽な状況では、『高スキルプログラマ多少余裕が出来ても、マネージャーはそれを隠そうとする』のも、もっともな話です」
「他にも理由があります。これはマネジメントとしては些細な問題に見えるかもしれませんが、本人にとっては重大な話です。
通常プロジェクトは、全てが同じ場所で行われているわけではありません。そうすると、プロジェクトを移る場合、当然引っ越しを行う必要が出てきます。
それだけではありません。引っ越し先に家具が足りていなかったら？インターネット回線が引かれていなかったら？恋人や家族と離れ離れになったら？
高スキル開発者の中には、こういった待遇が苦痛で、辞めてしまう者もいます。これも『高スキルプログラマの柔軟な活用が出来ない』理由です」
「残業も同じだ。残業で家庭を壊して、自分の身体を壊して、会社のために真面目に働く人間なんているはずがない。
無茶をすれば、高スキルプログラマから辞めていくことになる。それは一年後かもしれないし、明日かもしれない」
ヨハンも唖然としている。今まで、開発者の負担がどんなに重大な意味を持つか、考えたことも無かったのだろう。ジョナサンが、まるで会話でもするように話した。
「どこだってそうさ。どこだって『マネージャーと開発者の間で、マネジメントとして捉える範囲が異なっている』ものだ。
『そんなことをプロジェクトマネジメントの対象と考えるのは非常識だ』と一蹴するのも簡単だ。難しいのは、『変えよう』と考えることだ」
「現状のシステムを変えなければ、高スキルプログラマを活用することなんて出来ない。変えなければいけません」
普通のプログラマが、経験を重ねて、高スキルプログラマになるんです。少なくとも、本来はそうあるべきなんです。
確かにそうだ。もちろん、『教育が大切だ』などという陳腐な台詞は、この業界でも十年以上前から言われている。
だが、実際に短期間で開発者のスキルを上げる方法は確立されていない。上司に命令されて嫌々受ける社員研修制度に至っては、
しかし、ここにいる人間は別に努力が嫌いというわけではないはずだ。一体、開発者は何故努力しないんだね？」
「『開発者の努力（作業の効率化）が正しく評価されない』からです。もし努力すると、どういうことになるか説明しましょう。
開発者が努力して、作業を効率化したとします。すると、その開発者は普通より早く仕事が終わりますから、少し手が空いた状態になるんです。
ところで、『分業が進んでいる職場では、プログラマがプログラミング以外の仕事をすることは許されない』ため、
他の人の仕事を待つ必要が出てきてしまいます。憶測でコードを書くことも出来ますが……『仕様が決まっていないのにコードを書いても、どうせ作り直し』になります。やるだけ無駄です。
ここで、『より多くの仕事が回ってくるようになっても、それに比例するほどには評価は上がらない』点が問題です」
でも実際は、その開発者が一番仕事をしていたりするんです。それは進捗表を見れば誰だって分かることです」
「『暇そうにしている』『よく手が止まっている』といった『感情的な視点で開発者を評価してはいけない』ということか……」
ジョナサンが、ペンを置いた。見ると、ホワイトボードにはツリーが書きあがっている。これを見れば、問題は一目瞭然だ。
ヨハンが唸るように呟いた。「評価基準だ……全ての原因はそれだ。『人は、自分がどう評価されるかに従って行動する』んだ。
「ヨハン、『マネジメントの本質は、納期と予算の両方を守ること』だと君は言った。コスト計算の方法は間違っていたわけだが、しかし、残されたものがある。
「納期……進捗……開発者を評価するための基準は、進捗への貢献度だ。『経験年数やスキルではなく、プロジェクトの進捗への貢献度こそが評価基準であるべき』なんだ」
「多くの者が忘れてしまっているようだが、『評価基準は目的を達成するための手段』なのだよ。『間違った評価基準は、目的達成の障害でしかない』。
間違った方針を変えてみることだ。全てのメンバーの努力のベクトルが、真っ直ぐ目標を向くように。それが、真に努力するということなのだよ」
私は思った。目標に沿った評価基準があって、初めて真の努力が生まれる。きっと、そうなのだろう。いや、そうに違いない。
優秀な社員を評価することで大きな格差と妬みが生まれたり、逆に平均的な社員の評価が導入前より下がってしまいやる気が落ちたり、
やり方が変わることで生産性が低下してしまったり、そういう様々な懸念があるためだと説明されているが、彼らの本心など誰にだって分かっている。
彼らが変化を認めるのは、会社が潰れそうになったときくらいだろう。いいや、それでも認めないかもしれない。
「何が違うというのですか？」ヨハンは質問する。自分の手の届かないところに答えがあったという苦悩が、ヨハンの声を苛立たせているようだ。
ジョナサンは、無言でホワイトボードを裏返した。ペンが走る。そこに書かれた言葉自体は簡単だった。しかし、その意図を理解するのは容易ではなかった。
「答えを性急に追い求めると、『問題は外部にあった』、あるいは、『問題は上司にあった』、という話になってしまうことがある。
これは非常に危険な落とし穴だ。この落とし穴に一度嵌ってしまうと、抜け出すのは容易ではない。マネージャーのみならず、プログラマにも覚えがあることだろう」
もちろん覚えがある。バグをライブラリやOSのせいにしたことは数え切れない。しかし、筋道立てて確認してみると、実は自分のミスだったということのほうが多い。
「とりあえず、中途半端になってしまったコスト計算の話に戻ってみよう。全員に、重要な定義を知ってもらう必要がある。
さて、ヨハン。君に質問だ。『プロジェクトを評価する方法は、プロジェクトの損益（利益または損失）である』というのは、正しいかな？」
「もちろんです」ヨハンは答えた。沈黙するジョナサンに少し不安になったのか、言葉を足す。「それ以外にプロジェクトを評価する方法などありません」
「『プロジェクトを損益（利益または損失）で評価する』。これが、ヨハンの言うプロジェクトの評価方法だ。多くの企業ではこの評価方法を使っている。
しかし、多数決というのは正誤を決める方法ではない。重要なのは、根拠となる前提と、期待した結果が、実際にあるかどうかという点だ」
私は考える。また、この図だ。常識を打ち破るのは、容易ではない。だが、この対立解消図の前には、間違った常識は生き残れない。
「『プロジェクトを損益（利益または損失）で評価する』という方針を採用した場合、当然だが『損益を算出するためにプロジェクト単位にコスト（変動費と固定費）を集計する』ことになる。
「ええ、そうです……分かりましたよジョナサン。認めます。『プロジェクトを損益（利益または損失）で評価する』限り、人件費などの固定費をプロジェクトに集計することは
避けられない。しかし、『固定費のコスト集計には正当な根拠が無い』ですし、『コストの配賦誤差が大きくなりすぎて正しい判断ができなくなる』わけですから、
ここに矛盾が生まれていることになります。『プロジェクトを損益（利益または損失）で評価する』という方針を強く強制すればするほど、
固定費の配賦誤差が生み出す悪影響が顕在化し、『正しくプロジェクトを評価する』という目的が達成できるかは怪しくなっていく……ということですね」
「そうだ。それが従来のプロジェクト・マネジメントが抱える方針制約だ。間違った方針のもとで努力すればするほど、状況はどんどん悪化していくことになる」
ステーシーが身を乗り出して質問した。「別の方法があるのですか？」ジョナサンは答えない。そのかわり、指で頭を何度か叩く。
自分で考えろ、ということなのだろう。みんなも考えている。何が正解なのか。固定費の配賦誤差は避けられない。方針が間違っている。つまり……。
アレクサンドが呟いた。「本当に、誤差だらけの損益を計算する必要があるのかな？」途端に、みんなが自分の意見を言い合った。もちろん、私も参加する。
「どこがマズいんだろ？」「今までの話を聞いてなかったのか？ 固定費に決まってるだろ」「だいたい、固定費ってマネジメント不能なんだろ」
「固定費を計算式に入れる根拠って無いんじゃないか？」「どうせマネジメント不能なんだから、固定費を無視して評価してみればどうかしら？」
こんなに意見を出し合ったのは、ひさしぶりだ。みんなの意見が次第に収束していく。最後に残ったのは、あまりにもシンプルになった、新しい計算式だった。
「完璧だ」ヨハンが言った。「完璧とはどういうことですか？」ボブが質問する。「分からないのか？これなら固定費の配賦誤差が入る余地なんて一切無い。だから、判断を間違える可能性が無くなる。
「よくやった。君たちは自分たちで答えを見つけ出した。矛盾を解決する方法を探し出して、今までは考えもつかなかった方針を見つけ出したのだ。本当に素晴らしい」
「ジョナサン、この計算式の結果に名前はあるのですか？ 固定費や間接費を考慮していない以上、これは損益ではありません。これは何と呼べばいいのですか？」
ステーシーは自分が知らない定義に出会って、少し困惑しているようだった。ジョナサンに、みんなの視線が集まる。
「これこそが、本来マネージャーがマネジメントすべきものだ。『マネジメントの目的は期間あたりのスループットの最大化である』と言い換えてもいい」
仕掛品や完成品の在庫をどれだけ作っても、『納品できなければマネジメントが成功したとは言えない』からね」
確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫とは？この業界に在庫なんてありませんが？」
「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在庫が無いなどと考えるのは大きな誤りだ」
例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別のコードの完成を待っているテスト済みのコード』
『完成していても顧客に納品されていないコード』を指す。もちろん、『完成していても顧客に納品されていないドキュメント』も在庫だ」
何だろう。そうだ、あれは、私が書いてきたコードだ。毎日残業して、その中に価値があると信じて作り出してきたコードだ。
あれが全て、在庫だというのか？ 現時点では顧客に納品することができない、スループットに繋がっていない、在庫だというのか。
簡単なことだ。コードは目に見えない。だから、私たちはそれが在庫だと正しく認識できていなかったのだ。なんということだろう。
顧客の視点で考えてみれば、それがよく分かる。書きかけのコードや、未テストの機能は、顧客の視点ではほとんど価値が無い。
「つまり……開発者の稼働率を上げるために今すぐ必要でない作業を行わせても、在庫を増やすことにしかならない。
見た目の効率を重視したマネジメントでは、スループットを増やすという目標は達成できないということですか？」ヨハンが尋ねる。
「そのとおり。プロジェクト・メンバー全体の生産能力は一定だと仮定しよう。すると、『在庫を増やすために生産能力を使い過ぎると、相対的にスループットを減らす結果になる』。
これはマネジメントの目標に反した行動だ」ジョナサンの言い分はシンプルだ。だが、ステーシーが疑問を口に出した。
しかし、それでは開発者の手が空いてしまいます。その開発者の時間が無駄になるのでは？」ステーシーが疑問を口に出す。
「それは違う。開発者の余剰生産能力はいわば自然発生したセーフティー・バッファー（安全のための緩衝）なのだ。
開発者にさしあたって必要の無い在庫を作らせることでセーフティーを削り、生産能力をバランスさせてしまうと、前工程に発生した遅れをカバーするための時間的余裕が無くなってしまう。
作業のフローは非常に脆く壊れやすい状態になり、実際にフローは滞る。その結果、スループットに破壊的な影響を及してしまうのだ」
よく在庫と誤解されるのだが、『顧客に納品する目的でないコード』『顧客に納品する目的でないドキュメント』なども『経費』に含まれる。
「てっきり経費というのは、紙に印刷されたものだと思っていましたよ」ボブが冗談を飛ばし、アレクサンドがそれを受けた。「これからはメジャーで測らないとな」
マネジメントの手段は明らかだ。『在庫を減らし、経費を減らし、スループットを増やす』。これが、マネジメントの全てだ」
彼は勉強家だ。ずいぶんと努力をして、マネージャーになったのだと聞いている。答えが簡単に手に入ることに、慣れていないのかもしれない。
「『コスト削減』は逆効果なのですか？そんなはずは無いと思います」 ヨハンの反論に、ジョナサンは答える。
だが、『在庫を減らすこと』と『スループットを増やすこと』を蔑ろにしていては、効果的なマネジメントを行っているとは言えない。
それどころか、『コスト削減を重視しすぎて、在庫を増やし、スループットを減少させてしまう』ケースもある。
社員に休憩時間を与えず、残業をさせて稼働率を上げる。マネージャーは時間当たりの人件費を節約したように錯覚する。
しかし実際には、企業が支払う金額はこれっぽっちも減ってはいないし、むしろ残業代などで増えている。コスト削減は妄想だ。
開発者にひたすらコードだけを書かせて稼働率を増やし、マネージャーは開発の効率を上げたように思い込む。
これも実際には、在庫が増えただけだ。生産能力を在庫の作成と管理に振り向けたわけだから、スループットは激減している。
「しかし、この業界ではみんなそうしているのでは？」「なら、みんな間違っているんだろうね」笑いの消えたみんなと対照的に、ジョナサンは心底楽しそうだ。
これを改善しようとまたマネージャーが『スループット無視のコスト削減』、あるいは自滅的な『稼働率向上戦略』に向かえば、
この業界の倒産件数は、年々増加傾向にあるという。多くのベンチャー企業が生まれては消え、大企業の採算悪化も珍しくない。
それは、正しいマネジメントが行われていなかったからなのだろうか。コスト削減だけを重視して、スループットを見失っているからなのだろうか。
「スループットを増大させるには、『書きかけ・未テストのコードを減らし（在庫削減）、分納などで納品を早める（スループット増加）』ことが最良だということになる。
しかしそのためには、『スループットが大きく増えるのであれば、経費が多少増えても良い』という、考え方の転換も必要になる」
コスト増！今までの私たちにとっては禁句だった言葉だ。遅れているプロジェクトに払う金など無いと、何度遠まわしに宣言されたことか。
だが信じられないことに、ヨハンは何も言わずに考えているようだった。しばらくして、ヨハンが口を開いた。
「コスト至上主義からスループット至上主義への転換が必要、ということですね。両者はまるで違う。天動説と地動説くらいに違う……。
考え方を変えるには時間がかかるかもしれませんが、見落としていたものを見つけたからには、最大限努力しましょう」
私は、自分がヨハンを誇らしい気持ちで見ていることに気付いた。彼なら、正しいマネジメントを実践するに違いない。
未テストのコードという在庫を減らすのに、テスト駆動開発が有効だと私が提案したら、聞き入れてくれるだろうか。
開発の効率を上げるために、テスト・サーバーがどうしてももう一台必要なのだと説得したら、決断してくれるだろうか。
「今日はもう行かなければいけない。ヨハン、また何かあったら連絡をくれたまえ。『経費』は増えるかもしれないが、『スループット』を増やすことは保証しよう」
2004-11-28 (Sun) 17:33:27 仕掛品? : ＞TOC初心者さん。はい、その通りですね。しかし、最近のIT系の改革では、全体最適化のみが注視され、労働環境や評価についてはグレーというのが現状です。IT業界の問題は、評価尺度が難しいという事だと。定量的に評価が難しい。たとえば、規模にすると、多く書けば良いかというと、良いコードというのはまとまっていて、短い。悪いコードはスパゲティで長い。というのがあるので、規模の多さ、少なさは尺度にならない。じゃぁ、利益？というとそうでもない。実はプログラムにはGUIのように簡単で利益が出やすい部分と、コアな部分で数値演算とか難易度が高くて利益が出にくい部分とある。しかし、会社としては、簡単なプログラムだけだと、他社との差別化がしずらいので、難易度の高い物にも利益が出なくても投資しなければならない。したがって、利益ベースというのも難しい。したがって、妥当なところで、人月というところになってきています。全体最適化の話題をするとセットとして成果主義という上司の気分次第というあいまいな評価尺度になり、優秀なひとがこき使われ、ゴマスリが跋扈するという状況が現状です。個人的な意見としては、全体最適化よりも、優秀なひとによりリソースが行き渡りやすい、部分最適化をつよめ、優秀な人同士の横のつながりを作ることで、並列的に全体最適化をするシステムの方がうまくいくのではないかと思います。現状の、優秀と無能を十把一絡げにして、適当に集めたグループを部分最適するのではなく、優秀な人をあつめた、部分を作り、まず、部分を最適化し、給料の配分をグループ内で消め、かつ、グループ間の連携をうまくとれる人間を間に入れるというのが最適かとおもってます。
2004-11-27 (Sat) 14:59:36 仕掛品? : 酔狂人さん＞相対的な負荷は関係ないのでは？、サークルではなく、会社なので、能力に関係なく、同じ給料の人には、同じ仕事量を割り振らなくてはいけない。したがって、絶対量として同じ量をくばらないのであれば、労働者としては、がんばって、能力を上げると、同じ給料でも沢山しごとしないといけない。さぼって、能力をさげると、同じ給料でも楽ができるとなります。そして、現在のIT業界のほとんどは、成果主義とは名ばかりの、年齢給です。この現状があるかぎり、能力に関係なく、絶対量で仕事を割り振らないのはおかしい。そして、そういう現状なので、能力のある人は本来楽が出来るはずなのに、能力のあるひとばかりに仕事がかたまり、結果入院という自体が発生するのがIT業界です。休みを与えるなんて、名目上だけですよ？。現実は搾り取れるだけ搾り取るってのが普通ですね。
『ザ・ゴール』でも足の遅い少年の荷物を持ってやり、全体としてのスピードをあげようとする場面がでてきます。
2004-11-10 (Wed) 13:32:20 仕掛品? : また、他の仕事のヘルプに入れるような、優秀な人は数がすくないです。したがって、ヘルプ役の人は限られてきます。そうして、他のチームを助けるために呼ばれることが多くなった結果、まともに休みが取れなくなります。そして、従来の仕事がおろそかになり、それを何とかするために、チームに残った人が休みを返上して、作業することにより休めなくなります。基本的にデスマーチは発生した時点で、社内のみから人材を調達する場合、総量として休みが従来より減るのは確定事項です。したがって、このページの理論で、全体最適をかけると、だれが休みを返上するか？toiu
2004-09-05 (Sun) 16:47:51 anonymous? : ２．そもそもこの理論は、スループットを完全に定量的に（おそらくは金額ベースで）、そして客観的に査定することが可能だとする前提に基づいています。私はそれは不可能だと思います。例えば、システムの根幹にかかわるデバイスドライバのスループットはいくらですか？これ単体では納品はできませんから、金額ではゼロです。よって正当な評価のためには、金額のみでなく、プログラマ同士の評価といった計量しがたい基準を取り入れる必要がありますが、これは定量どころか、順序すら付けがたい極めてデリケートなものだと思います。これで果たしてプロジェクトのスループットの変化をパーセンテージで示せるでしょうか？大幅に恣意が入り込む余地が存在していると思うのですが。
2004-07-29 (Thu) 23:27:01 私は文章を（あるいは、文字の羅列を）書くことが出来ます。しかし、小説の作法に関しては極めて無知です。自分の文章が小説として正しくないことは自覚していますが、どこをどう直したら良くなるのかが分かりません。私はあなたのコメントを役立てることが出来るレベルに達していないのです。ですから、どうか別のページを作成して頂き、引用などを使って改善すべき点をご教授下さいませんでしょうか。

 

[ 520] 要求工学 第29回：前提条件ツリーと移行ツリー(エンタープライズICT総合誌 月刊ビジネスコミュニケーション)
[引用サイト]　 http://www.bcm.co.jp/site/youkyu/youkyu29.html

今回は、何を何にどのように変えるのかという「どのように」の部分について解説する。ここでは、まず前提条件ツリーを用いて最終目標を達成するためにどんな障害があるのかを発見し、それを克服するための中間目標を調べる。次いで移行ツリーを用いて作業を具体的に実行していく計画を明らかにする。これでようやく論理思考プロセスの紹介が完結することになる。
まず対立解消図を用いてゴール、ゴール達成の要件、要件の前提の相互関係を分析することにより、前提間の対立を解消するインジェクションを発見する。次に、未来実現ツリーを用いてインジェクションと因果関係に基づいて、想定される好ましい結果とネガティブ・ブランチの可能性を明らかにする。さらに、ネガティブ・ブランチを用いて最悪の事態を予測し、それに対するインジェクションを考案する。ネガティブ・ブランチを未来実現ツリーに追加する。
前提条件ツリーを用いて最終目標を達成するための障害やそれに対処するための中間目標の関係を明らかにする。また移行ツリーを用いてどのように変革を完成するかを示す行動の時間的な順序関係を具体化する。
前提条件ツリーの構成要素には、実現すべき目標と中間目標、そして目標を実現する上での障害がある。前提条件ツリーで扱う関係は必要関係と克服関係である。
必要関係では、上位の目標を実現するためには下位の目標が必要であることを表す。これに対して克服関係では上位の目標の障害を下位の中間目標によって解決できることを表す。
新たなシステムが成功するための前提条件を予め明らかにするために作成するのが前提条件ツリーなのである。
まず手順１から手順３までで、対立する前提条件から望ましい要求と対立しない共通の目的を探索する。次いで手順４から手順６で、対立を解消するためのインジェクションを発見するのである。このように対立を生じさせている要求の目的を探すことで、変更可能な仮定や暗黙の条件を明らかにするための手がかりを見つけることができる。
因果関係では、目的、要求、前提の論理的な関係を定義する。また同じ前提から対立していた前提の要求が、インジェクションにより論理的に導かれることも因果関係で表す。
次に、第２の問を考えることで最終目標を達成するための課題としての障害を抽出する。また障害に対する対策を考えて中間目標として記述する。さらにこの中間目標の障害は何かを考えて、その対策を具体化していく。
中間目標を障害に対応付けるとともに、時間順序に従って下から上に配置する。つまり最終目標を頂点として、その前に必要な克服すべき課題と対策とを時間をさかのぼるように上から下に順に配置していくのである。
時間的に先行する中間目標と障害を後行する中間目標と障害の下に配置し、下の中間目標から上の中間目標に線を引く。すべての中間目標と最終目標とを線で結ぶ。このとき下位の中間目標によって回避される障害から、下位の中間目標からその上位の中間目標へ向けた線に対して線を引く。
すべての中間目標と最終目標とを線で結ぶ。このとき下位の中間目標によって回避される障害から，下位の中間目標からその上位の中間目標へ向けた線に対して線を引く。
今回もこれまでと同じ徳島県上勝町（かみかつちょう）の町おこしの事例[3]について、前提条件ツリーを作成してみよう。上勝町はミカン以外の産業のない山間の過疎と高齢化に悩む町だったが、葉っぱをビジネスにすることで、活性化に成功したことで有名になった。
ここでは最終目標を「葉っぱを売ることができる」としてみよう。この最終目標に対する障害としては、次の３点が考えられる。
たとえば、売れる葉っぱを持っているためには、働く人がいないといけないという課題があり、さらにそのために高齢者が葉っぱを集めることになる。
ところが、高齢者が葉っぱを集めるためには、高齢者が葉っぱが売れることを信用しないという課題が出てくる。そこでこの課題を解決するために、高齢者に葉っぱが売れることを認知してもらう活動が必要になるというわけだ。
このような検討を続けることで、最終目標の実現に向けて考えられるすべての課題を明らかにしていくことができる。最終的に検討結果を整理すると、図1のような前提条件ツリーになるだろう。

 

[ 521] 後藤弘茂のWeekly海外ニュース
[引用サイト]　 http://pc.watch.impress.co.jp/docs/2006/0320/kaigai254.htm

まだ、奥歯に物が挟まったような表現をしているのは、全ての地域の全てのPS3に標準搭載するかどうか、決めあぐねているのかもしれない。
「HDDは、シリアルATAの2.5インチの標準品で、自分で繋ぐこともできる。全部のPS3に入れてしまえとなるかもしれない。マーケット次第だが、プラットフォームとしてはあることを前提として考えている」と久夛良木氏は言う。
こうした図式を見ると、PS3はもはやゲームコンソールとは言えない、エンターテイメントコンピュータに仕立てられつつあることがわかる。本当に、PS3の上でアプリケーションが花開くかどうかは、まだわからないが、SCE自身はその方向で考えていることがよくわかる。そして、そのためのコストは、なんとかできると考え始めたのかもしれない。
SCEは、PS3だけでなく、同社の新プラットフォーム全体でこうした、プログラミングの拡張を指向している。例えば、PSPの開発ツールの価格も、現在の75万円から50万円に引き下げる。ゲーム業界以外のアプリケーション開発者へ向けたアプローチだ。
PS3とHDDの文脈の中で、もう1つ重要な要素はネットワークだが、これも、先週のカンファレンスで明らかにされた。もっとも、今回発表されたPS3関連のサービスや環境の中で、もっともクリティカルに見えたのがネットワークだった。
SCEはPS3のローンチと同時にネットワークサービスも開始するという。ベーシックサービスは無料で提供する。しかし、その内容とスケジュールは、どう見ても、SCE側の膨大な努力を必要としそうだ。
内容が盛りだくさんであるだけではない。SCEのネットワークサービスは、猛ダッシュのスケジュールがすごい。最初のSDKを3月末、SDKのセカンドリリースを4月末、サーバー側のフル機能の実装の完了は6月末、そして7月からライセンシー向けにフル機能のテストをスタート、9月には本番環境への移行をスタートさせるという。現段階で、通常のライセンシーのデベロッパには何も提供されていないことを考えると、異例のハイペースだ。SCEは、これまでネットワークは弱かったことを考えると、当然、実現性には疑問符がつく。
とはいえ、SCEのネットワーク戦略発表はポジティブな面も多い。同社が危機感を持ってネットワークに本気で望むという姿勢が明らかになったからだ。ネットワークサービスがドライブされると、PS3ではオンライン配信という新しい展望が開けてくる。
もちろん、この道は、さらにその先では、インターネット経由の分散処理のCellコンピューティングへも繋がっている。つまり、道のりは、まだまだ長いということだ。

 

戻る

セントラルファイナンスのサイトです。

セントラルファイナンスのサイトです。