Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

人月の神話 - 人(能力)で月(時間)は買えない。

カテゴリ:システム考
更新日:2011-12-14
私はフリーランスとして、基本的に月額費用で請求するようにしているんだけど、それを決めたときには、確かに「これって人月計算だよな。ほんとうにいいのか?」ということを考えていたな。

> 人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
ここまで整理すれば、人月は良いか悪いかというのは相性の問題でしかないということが導けるでしょう。人月がダメなら、フリーエンジニアはほとんどダメということになります。彼らは生活がかかってるから、成果物に対する対価と言うよりも時間の拘束自体に請求をしなくてはハイリスクになる。もっと言えば、食っていけなくなる。なので、単価設定をするしかない。それって人月じゃないですか。
まぁ、実際。この要素は大きかった。契約~開発~納品~検収~入金なんてサイクルでやってたら生活できません。たとえ、開発中が無収入でもやれるくらい貯金があったとしても、ちょっと綱渡りすぎるよね。

だけど、本当の理由は他にある。

> 人月は悪どころか、ものすごい善かもしれない - 山本大@クロノスの日記
エンジニア目線で見ると、人月は悪に見える。

できるやつとできないやつの生産性は10倍も100倍も違うのに、 単価はせいぜい±30%ってところだから、そういう比較をすると納得がいかないのはよくわかる。

> 人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
バカでも優秀でも同じ金額になるので優秀な人は生きるのが辛くなります。単価が同じだと仮定して、ダメな人は1ヶ月かかり優秀な人が1週間で完遂できる仕事があるとします。そうなると、優秀な人が損をします。1ヶ月で出来る仕事を1週間で出来る人間には1週間分だけのお金を払えばいいじゃない、ということになってしまうからです。その人だけ2倍~3倍の単価設定ができるわけでもない。

優秀なエンジニアなら早くできる。だから、人月計算だと優秀な人が損をする、ってか?だけど、その考え方こそが、「人月の神話」なんだよね。能力(人)で時間(月)が買えると思ってるわけだ。

「人月計算が悪」と思っているのなら、まず、この考え方から脱しないといけない。

優秀だと思っている人には悪いけど、どんなに優秀でも時間生産性ってのは、そんなに増えないよ。そりゃ、素人や新人と比較すれば、圧倒的な差はあるだろうし、最初のリリースまでの期間を比較するなら、経験がある方が早くできるかもしれない。

だけどさ。リリースしたら終わり、なんてことあるの?

そりゃ、契約上の話として、それ以降は手が出せなくなる、ってことはあるかもしれない。だけど、バクのないソフトウェアなんて信じないし、機能追加や修正が必要ないなんてことも、本当はほとんど無いんだと思う。改良が必要なくなったソフトウェアってのは、使われなくなったか、改良するための費用が出ないか、じゃないかな。

システムってのは、使っていくうちに変化するものなんだよね。これは、使う人が変化する、ってこと。だけど、ソフトウェアという名とは裏腹にソフトウェアほど強固なものはない(改良できるうちは柔らかいんだけど)。ハードウェアなら壊れるからリプレースできるのに、ソフトウェアって一般的な概念では壊れないから、どうにも融通が効かなくなる。そうすると、人間が使うのに工夫するか、それが限界にくれば使うのを止める。

元の話は、スマフォアプリだけど、これだってバグフィックスやバージョンアップはするだろう。「一本84円からの世界」って言うけど、製品としてのライフサイクル全体での視点は必要なんじゃないかな。

それに、リリースした後の検収にだって時間は必要なんだよね。仕様書に完全に準拠したソフトウェアを作り上げたとしても、その仕様書がユーザーの希望を完全に表しているとは限らない。実際のところは、ユーザーは仕様書ではなく、できあがって動いているシステムで評価するんじゃないかな。そして、評価するには時間がいる。

中小企業向けに業務システムを開発してた経験からすると、納品(カットオーバー)後の方が大変なんだよね。規模の大小にかかわらず(といっても、あんまり大規模は経験ないけど)、落ち着くまでに大体三ヶ月かかる。カットオーバーから一ヶ月くらいは、さすがにドタバタして、導入支援をするこっちも忙しい。二ヶ月目は、だいぶ落ち着くけど、ユーザーの責任者がまだ不安がる。けど、三ヶ月目になると質問やトラブルが減るのが分かる。すぅ、っと楽になる時がある(ない場合は、たぶん根本的にトラブってるので、仕切りなおしたほうがいいんだと思う)。おそらく、新しいシステムに会社全体が慣れるまでに、それだけ必要ってことだろう。

納期は、リリースは、終わりじゃない。ただの通過点にすぎない。なら、通過点の早さを競う優劣さに、何の意味がある?

リリース前に、悩んで悩んで実装した機能が、実は間違っていたとか。実際には使われなかったとか。そんな経験もある。リリース前に悩むくらいなら、とっとと使ってもらって評価してもらったほうがいいんじゃないか?そのために、粗々でもいいから、できるだけ早くプロトタイプを作って、早く評価してもらって、それから細部を詰めていけばいいんじゃないか?

結局のところ、アジャイルってことになるのだろうか。そうすると、仕様書という形で目標を固定できないから、期間で区切るしかない。で、月額費用で請求することにしたんだよね。

どのくらい期間でできるのかは、ユーザーの評価能力にも依存するので、一概には言えなくなる。まぁ、そうすると発注する方もリスクがあるから、最初のプロトタイプは一ヶ月くらいで提供するようにするとか、全体の期間も区切るとか、契約してもらうための努力はしてる。

でも、ほんとうは、つくったシステムが、ずーっと使われることを望んでいるんだよね。ソフトウェアが使われ続けるには、改修し続けるしかないけど、納期で仕事を区切るようなやり方では、そんなことができないんだよね。

人月の神話新組新装版

人月の神話新組新装版
著者:フレデリック・フィリップス・ブルックス
価格:3,360円(税込、送料込)
楽天ブックスで詳細を見る

スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

ガーデニングが趣味のフリーのシステムエンジニア兼プログラマ(フルスタックエンジニア)です。

仕事募集中です。個人なので、融通がききます。 大規模な開発はできないかもしれませんが、研究や製品開発レベルでの小規模開発、特に相談しながら新しいものを作っていくのが得意です。詳しくはWebサイトをご覧ください。
詳しくは「fintopoとは」をご覧ください。

> fintopoとは

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。