お疲れ様です。僕です。
僕は、休み過ぎてニート疲れがひどいです。
話は変わりますが、これどう思います？
結局、かなり大きなオーダーで納期に遅れていることがわかった。
しかし、だからいったいどうしたというのだ。
この工場で納期に遅れることなど当たり前のことではないか。
この工場では重要度順に客からのオーダーを4つに分けることができる。
「Hot(重要)」「Very Hot(最重要)」「Red Hot(超最重要)」「Do It Now(いますぐやれ）」の四つだ。
つまるところ、全てが遅れているのだ。「ザ・ゴール 企業の究極の目的とは何か」著：エリヤフ・ゴールドラッド
これは製造業の話ですが、ソフトウェア開発にも通じるところがあります。
何か感じることがある方は、炎上中か炎上経験者ですね。
はは、仲間仲間。
今回は少し「ザ・ゴール」の理論に従って
「プロジェクトは何故遅れるのか」を追ってみたいと思います。
ソフトウェア開発プロジェクトのサンプル
以下のようなシンプルなプロジェクトを検討していきます。
あくまで小規模(10人月～50人月程度)のものです。
人数で言ったら最大10人いかないくらい？
図の補足説明
一般的な請負開発で、お客様の要求から始まるプロジェクトです。
ユーザー側の受入れ検査でプロジェクトを終了となります。
スイムレーンを横に切っていますので、左から右へ時間が流れていくとお考え下さい。
PMはプロジェクトマネージャ、PGはプログラマー、ユーザー部門は顧客とします。
また、「要件定義書」という言葉は目的が不明確になる為、PMの最初の成果物は機能一覧としています。
過去の記事でも何度かお伝えしましたが、機能一覧が出た時点で金額の見積もりを行います。
本来、作業工数を出した後に金額を見積もるべきですが、現実にそぐわない正論はゴミですので、今回は忘れることにします。
プロジェクトの目標(ゴール)とその測定
企業の目標が「お金を儲けること」であるのは、疑う余地もないかと思います。
「ザ・ゴール」でもそのように謡っています。
従って、プロジェクトの目標は「ソフトウェア開発を手段としてお金を儲けること」です。
実は、美しいプログラムを書くことでも、超高品質のソフトウェアを作ることでもありません。 ひょっとしたら、ソフトウェアを完成させることでもないのかもしれません。
先ほど紹介した「ザ・ゴール」の中では、
この「儲ける」を3つの指標で測定するよう指摘しています。
スループット
定義：販売を通じてお金を作り出す割合のこと
ソフトウェア開発プロジェクトで考えると、”(在庫 + 業務費用) / 総売上金額”という感じでしょうか。
在庫
定義：販売しようとするものを購入するために投資したすべてのお金のこと
ソフトウェア開発プロジェクトで考えると、外注利用の場合などに発生する費用、ハードウェア購入費用、ライブラリ購入費用など。
業務費用
定義：在庫をスループットに変えるために費やすお金のこと
ソフトウェア開発プロジェクトで考えると、ソフトウェア開発にかかった全ての人件費（アイドルタイムなども含む）。
3つの指標とプロジェクトの目的
スループットを上げ、在庫を減らし、業務費用を減らすことがプロジェクトの目的となります。 バランスが大事で、スループットを上げたとしても業務費用や在庫が増えてはいけません。
しかし、ソフトウェア開発において在庫となるものはあまりなく、ほとんどが、業務費用に集約されるかと思います。 つまり、スループットが低下し、業務費用が膨れ上がる現象がプロジェクトの遅れとなります。
これらの前提を基に「プロジェクトは何故遅れるのか」について検討を進めていきたいと思います。
「プロジェクトは何故遅れるのか」の検討
「プロジェクトが何故遅れるのか」について検討するためにはボトルネックを探す必要があります。 ボトルネックは先ほど紹介した「ザ・ゴール」ではこう定義されています。
定義
ボトルネック：与えられえている仕事量よりも処理能力が同じか、それ以下のリソースのこと
非ボトルネック：与えられている仕事量よりも処理能力が大きいリソースのこと
ソフトウェア開発における三つのリソース
定義に従いボトルネックを探す為に、リソースを定義する必要があります。
図で示したプロジェクトでのリソースは、「PG」「PM」「ユーザー部門」となります。
ボトルネックを探せ
ボトルネックとなりうる内容として以下の３パターンが考えられます。
①PGがボトルネック
これは、設計書、プログラム、テスト結果のいずれかがふんづまります。
②PMがボトルネック
これは、機能一覧がふんづまっている状態です。
③ユーザー部門がボトルネック
これは、要求仕様がふんづまっている状態です。
この３パターンについて、事例を踏まえて検証していきます。
①PGがボトルネックの可能性
PGに与えられた工数を、作業時間が超えてしまったという状況です。
このパターンは大いにあると思います。
大きく分けて、以下の2種類かと思います。
①アイドル時間が多く、作業時間が尽きた
②無駄なものを作る時間が多く、作業時間が尽きた
①アイドル時間が多く、作業時間が尽きた
・スケジュールが見えておらず、着手・完了をぎりぎりまで遅らせた
・インプットとなる成果物が、揃っておらず着手が遅れた
・インプットとなる成果物が揃っていることに気づかず、着手が遅れた
・作業のキリが良く定時までだらだらした
・昨晩遅くまでゲームやり過ぎて居眠り
②無駄なものを作る時間が多く、作業時間が尽きた
・前工程の問題を後続工程に引き継いでしまった
・認識に問題があり要求されていないものを作っていた
・作る物が決まっていない状態で作り始めた
・技術力不足により問題解決に時間がかかった
・こだわりが出た
アイドル時間に関する問題はマネジメントの問題かと思います。
マネージャーはちゃんと責務を全うしてください。
人間はクソみたいな理由で、貴重な時間をドブに捨てます。
無駄なものをつくる問題については深刻です。
実は一発で作れた場合に比べ、簡単に倍以上の時間がかかります。
想定のN倍の時間がかかることなんて、ザラにあります。
PMがボトルネックの可能性
仮にPMがボトルネックであれば、機能一覧の洗い出しも未完了なので、受注するかも分からない状態です。
何を作るかもわからない状態で一括請負というのはさすがに無いのではないでしょうか。そもそも見積もれません。
また、PMがPGの仕事に手を出始めると、「全てPM待ち」という状態になります。
これもPGの作業でふんづまっているので、PGのボトルネックと考えて良いでしょう。
そもそもPMは効率よくプロジェクトを進める仕事であって、
PMがいなくても非効率にプロジェクトが進むだけです。
必ずしもやらないといけない作業ではないので、ボトルネックも何もありません。
結局、後続のPGでふんづまります。
ユーザー部門がボトルネックの可能性
想定できるのは、こんな感じでしょうか。。
①納期は決まっているが要求が定まらない
②受注後に要求がコロコロかわる
③機能一覧や設計までやろうとする
①納期は決まっているが要求が定まらない
これは、放っとくしかないですね。
見積提示する時に、元々期待されていた納期を無視し、実現可能な納品日を書くと良いと思います。
無理なものは、無理です。
②受注後に要求がコロコロかわる
結構厄介です。
ただ、機能一覧があればそれを根拠に
「変更ですか？とりあえずリストアップしときますね。やるかどうかは金額次第ですけど。」
と言って、変更要求を塩漬けにします。
しかし、機能一覧の出来が悪いと大変です。
変更かどうかがわからない。
あっという間に焦げ臭くなります。
③機能一覧や設計までやろうとする
お客様しかわからない事とかもあるので、そういうところは必要です。
しかし、全部やろうとするお客様は一体何なのでしょう。
要件定義や設計で工数とってるんでね。
もっと楽して良いんですよ？
ま、やってくれるって言ってるし
と、待ってると痛い目見ることがあります。
・待てど暮らせど資料が来ない
・来ても矛盾だらけの不完全なもの
・指摘や質問したら落ち込んでレスポンスが悪くなる
・最後は手が回らなくなり、メモ書きや口頭で済まされる
・最新の情報が何かわからなくなる
しかし結局、ふんづまるのはPGです。
ボトルネックまとめ
3パターンについて検討しましたが、
やはりPGがボトルネックなのではないでしょうか。
ボトルネックは悪いものと言うわけではなく、存在するものです。
現実として受け入れるものです。
PGの作業の中でも、特にプログラミングがボトルネックになるのではないでしょうか。
いわゆる炎上プロジェクトは
いつまでもプログラミングが終わらない状態
ではないでしょうか。
まとめ
このブログ始まって以来の長文ですが、
「プログラミングが遅れるとプロジェクトが遅れる」
という当たり前すぎる結論に辿り着きました。
プロジェクトに関係する人は全て、プログラミングを速やかに終わらせる為に動くべし
とか言っておけば、何とか格好つきますかね。
ここまでお付き合いくださった方。
どうも、ごめんなさい。
この程度の文章を朝8時に書き始めて今は19時です。
バカなのかな。
おわり
コメントを残す