脱・人月に向けて

私がこの業界に入った 18 年前、真っ先に違和感を感じた「人月」という制度。開発の仕事を続けていく中で、ここにメスを入れないとお客様と開発者の信頼関係は構築できないという気持ちが年を追う毎に強くなっていきました。

お客様と開発者は対立するものではなく、共通の問題を解決する仲間である。この思想はとても大切です。
しかし、これがなかなか定着しない原因は、人月という曖昧なコスト算出構造を土台にしているためと考えます。

お客様からみた人月に対する根本的な不信感とは「1人月」の定義が不明確なことです。

ある開発会社では、成果品とは無関係に、常駐している間は(何もしなくても)1人月を請求するでしょう。
別の開発会社からは、このシステムは 10 人月規模ですと教えてもらいましたが、なぜかという理由はわかりません。そして実際に、10人が作業したのかどうかも不明です。
さらに別の開発会社は、「一式いくら」という見積になりました。こうなると根拠は一切不明なので、無理矢理問いただすと「100人月相当」という返事になりました。やはり根拠はわかりません。

それでも人月が大多数に支持されている理由は何かといえば、「他に変わる手段がないから」だと思われます。そもそも、人月以前の時代はプログラムのステップ数で金額を請求していました。さすがに現代ではステップ数と成果は無関係と解釈されていますが、人月単価と成果も実はあまり関係ないと多くの関係者は知っています。

つまり、お客様に自分たちを信頼してもらおうと思っても、明確な価格表を出せない中ではお互いが腹の探り合いになるということです。人月の曖昧さは、良くも悪くもそのような土壌を生みます。

一方で、人月は開発の仕事をマンパワーで語れるようにしました。技術力は人月の単価に反映されるはずですが、優秀な人間が少人数で行うよりも、平均的な単価で力仕事を行った方が売上になるという認識が広まります。これによって心ある技術者はこの業界への魅力を少なからず失っていくことになります。

この状況を変えるために、これまでも人月に代わる多くの提案が行われてきましたが、いまだ本命というアプローチがありません。それは何故かを私なりに検討した結果、労働集約型アプローチを土台としている以上、人月を適用するのはやむをえないという結論に至りました。

これは逆にいえば、人月とは異なる体系をつくるためには現在の延長ではなく、発想を変える必要があるということです。

そこで本日、当社が発表した「Model Driven Contracting」という発想は、自動生成技術を前提にした価格体系になっています。開発から属人性を排除することで、業務項目単価を明確にしました。自動生成の適用外についても、可能な限り人月という考えをやめ、単価を明示するように心がけました。
http://www.jasminesoft.co.jp/service_develop.html

このアプローチには別の効果があります。私達は同業間での開発案件ではなく、直接、お客様に接していくという意思を明確にしました。SI 業界の下請け階層構造にのらないという気持ちが込められています。

退路をたった分、本当に目指すべき方向がはっきりしました。腹の探り合いをやめ、直接、お客様と信頼関係をもってシステム開発を行いたいということです。そのためには「わかりやすい価格を明らかにする」ということが必要不可欠だと考えています。

Webアプリケーションの1業務項目の開発単価(データ型に依存せず、CRUDを実現する)を 8,400 円(税込み)と表明しました。DB の変更から Java プログラムの修正、SQL 対応、画面修正とテストまでをすべて手作業で行うことと比較すると、かなり競争力のある価格になっていると思います。

この提案がお客様にどう評価されるのかは、私達の今後の開発実績によります。この成功は、Wagby の信頼をも同時に高めることになるでしょう。いよいよ正念場です。