読者です 読者をやめる 読者になる 読者になる

アーキテクチャをスマートに。

株式会社ネオジニア代表。ITアーキテクトとしてのお仕事や考えていることなどをたまに綴っています。(記事の内容は個人の見解に基づくものであり、所属組織を代表するものではありません)

「工数をもらう」ってよく聞くけど(1)

考え方

受託開発の現場では、よく「工数をもらう」という表現を聞ききます。

これは、

作業工数がオーバーするので、顧客からお金をもらいましょう

というような意味合いです。

この言葉、僕は最近になってすごい違和感を覚えるようになりました。

これには、人月見積もりという悪しき商習慣(?)が背景にあるのではないかと考えています。

人月見積もりって?

人月とは作業量の単位です。
一人の作業者が1ヶ月でやれる作業量を1人月と言います。
これをベースに製造コストを計算する手法が人月見積もりです。
同様に、人日、人時などもあります。

ところで、情報システム開発の現場では、人月見積もりはダメだとかいう話をよく耳にするのですが、何がどうダメなんでしょうか?

ダメと言われているのに、一向に改善される気配がないです。
なぜ改善されないんでしょうか?

管理職や経営陣の方はどうかわかりませんが、現場のエンジニアで、このことについてある程度の理解レベルに達している人は全くいませんでした。
みんなダメといっているから、ダメなんじゃないの? そんなレベルです。
なぜある程度の理解レベルに達しているエンジニアはいなかったんでしょうか?

僕はこのように自問自答しながら、自分なりの答えを探し続けてきました。

なぜ人月見積もりはダメなのか?

先輩エンジニアに質問しても、的をえた答えは返ってきませんでした。
そればかりか、「そんなことを気にする前に、とにかく仕事をやれ!」などと怒られることもありました。

そこでいつものグーグル先生に質問するわけですが、これが結構色々と情報が出てきます。

まず簡単でわかりやすいのは、人月思考のプロジェクトマネージャは、進捗が遅れたときにすぐに人を増やそうとする、ということでした。
これをやるパターンは本当に多いのですが、でも実際には、新しく来た人たちの教育やコミュニケーション時間によるロス等で、あまり進捗回復できないことがほとんどでした。

他にもいろいろな問題が指摘されているようです。

しかしながら、一概に何が悪いとは理解しにくくて、ナルホド感があまり得られませんでした。

また、Web上で得られる情報はどれも非常に高度な内容で、ちょっと気合を入れて読み込まないといけない論文チックな感じもあり、特に現場のエンジニアにとっては知らない世界の話も多いので「ふ〜ん」みたいな理解レベルにしかならない。

そんな印象を受けました。

そういう経緯もあって、とりあえず総論的な説明はグーグル先生で出てくるWebサイトにお任せするとして、もうちょっとわかりやすく、現場のエンジニアから見た切り口で考えてみました。

というわけで因果関係図(的なもの)を書いてみた。

かなり単純で短絡的なところもありますが、因果関係がよくわかると思います。

まず大きな要点として、「工数と売り上げが比例する」ということが挙げられる。

人月見積もりをしたからといって売り上げが下がるわけではない。
むしろマネージャレベルの人たちになると、ある程度の工数を確保し、利益につなげようとする考え方が基本となっている。

特に受託開発においては、もう一つの要因として、ユーザ企業と交渉して見積もり作業を行う人は、現場のエンジニアとは立場(会社)が違う、ということがある。
極端に言うと、エンジニアがどれだけ頑張って工数を減らそうが、見積もりをした人にとっては何の得にもならないので、あまり関心がないということだ。

これは組織的な問題。というか産業構造全体の問題かな。といあえず今は置いておく。

一番の本質は次のこと。

そもそもの根本的な間違いは、情報システムの価格を「ユーザにとっての価値」ではなく、「製造コスト」に焦点をあてていることにある。

ズバリそのとおり。
僕はこの答えを得た瞬間、目からウロコが落ちました。


次のポストへ続く。