長年プログラマをやっているが、見積もり作業と言うものが難しい。
…というか、プロとしてこんな事を言うのはどうかと思うが、はっきり言ってやり方がわからない。
プログラマではない方には関係のない話と思うが、暇ならお付き合いを。
プログラマで独立したいと思っている人は、他山の石として読んでいってください。
独立プログラマの仕事と言うのは、まず相手から「こんなプログラムが欲しい」と依頼されるわけだ。
この時点で、要求は漠然としている。場合によっては、自分が何を求められているのかすらわからないことがある。
でも、相手は言うのだ。「どれくらいで作れますか？」と。
ここで「どれくらい」には２つの意味がある。日程と金額だ。
この２つは無関係ではないが、独立している。でも、相手はそのことすら知らない。だから「どれくらい」という曖昧な言い方になるのだ。
自分が似たようなものを作ったことがあるなら、ある程度勘が働く。
でも、そればかりではない。そういう時は、細かな作業工程を想像し、積み重ねて概算を出さなくてはならない。
ところが、ここで矛盾が生じる。相手が依頼している内容が漠然としているので、細かな作業工程など出せないのだ。
かくして、まずは作業内容確認のカウンセリングから入ることになる。
本当に欲しい機能はなんなのか。どういう状況で使おうと思っているのか。必須機能はどれで、あれば便利だと思っている機能はどれなのか。
大抵はお客様は何らかの業務で思い悩み、コンピューターの力を借りれば解決できるのではないかと考え、どうすれば良いのかの方策を考えてから「プログラムは作れるか」と相談に来る。
しかし、プログラムの専門家ではない人が考えた「理想のプログラム」は、実現不可能な要求を盛り込んでいることが多い。
そこで、依頼以前の、業務の何で思い悩んでいるのか、と言うところにまで立ち戻って話をして、本当に必要としているプログラムはなにか、と言うところから一緒に考えなくてはならないのだ。
ともかく、いよいよ作られるプログラムの「要求仕様」が固まったとしよう。
この時点で、要求仕様は実現可能であることが前提だ。
「いい人材を見分けるプログラム」なんてものは実現不可能だが、アンケートや簡単なゲームを通じてなら、適正を見極めることができるかもしれない。
そういう、具体的方法論にまで踏み込んだものが「要求仕様」だ。
さて、これが「どれくらいで」作れるかを答えなくてはならない。
でも、これが実のところ、不可能なのだ。
個人で仕事を始めてから、初期の頃には荒見積もりを出すことの難しさに悩んでいた。
結局決めかねて「いい加減な嘘をついて」それらしい見積書を作るのだが、良心の呵責があった。
でも、プロジェクト進行について書かれた専門書なんかでも、この「荒見積もり」は不可能だ、と言うことが明記されているのね。
だから、大企業でもそれらしい嘘をつく。
作業に入る前に工程表を作ることなんてできない。
これは、プログラムに限らない。単純プロジェクトならともかく、ちょっと複雑なプロジェクトでは、全てそうなのだ。
特に、誰も経験したことがないはじめての作業を行う時には、工程表なんて絶対にまとめられない。
でも、それでは困る。見通しがたたなければお客様は発注はできないし、結局は自分にも仕事が来ず、お金が入らないのだ。
だから、嘘でいいから工程表を書く。それらしく書く。
まず、思いつく限りの細かい工程に全体を分解する。次に、それぞれの工程が「順調に行けば」どれくらいの時間で終わるかを見積もる。
ここでの見積もりは、間違えたって構わない。
初めての仕事だから難しそうだ、と思っていたものが案外簡単だったり、過去に似たものを作っているからすぐできるだろう、と思っていたものが、前提条件の違いで想像以上に苦しんだりする。
作業工程はできるだけ細かく分解しているが、実際に作業してみると想像外の作業が発生したりもする。
でも、細かな作業工程の個々の見積もりが間違っていたとしても、全体を通せば平均化される、と期待して見積もる。
ともかく、一度全体を「順調に行けば」どれくらいの時間で作れるか、を算出することが重要だ。
順調に行った場合の時間見積もりが出たら、これを１０倍する。
…いきなりそんな、１０倍なんて乱暴な。
そう思う人も多いだろう。当然だ。
僕も独立した頃は、何倍かに見積もらなくてはならないことはわかっていたが、何倍にするのが妥当なのかわからなかった。
３倍？ ５倍？ でも、経験則から言えば、５倍くらいの見積もりでは苦しいばかりで割に合わない。
答えは、ちゃんと古い本に書いてあった。「人月の神話」に、少なくとも９倍せよ、とある。
理由は簡単。
まず、技術者は、作業見積もりを出す時に技術面の難題を中心に考える。
実際には、難題以外にも、細かな作業が多数ある。それらは、難しくはないが時間がかかる作業だ。
そして、実はこうした作業の方が全体の中での比率は多く、難題部分に多くの時間が取られたとしても、その２倍は「簡単な部分」の作業に必要なのだ。
だから、簡単な部分も作るためには、時間を３倍して考えなくてはならない。
次に、技術者は技術面以外の事を考えない。
技術的に動くプログラムができたとしても、実際にはそれを「使いやすく」まとめる作業も必要だし、マニュアルなどを整備して、誰が見ても使える状態にする作業がある。
これらの、プログラムの本質ではない作業は、実のところプログラム本体の作業よりも長い時間…２倍はかかる。
だから、「動くプログラム」を「製品として使えるプログラム」にするのには、時間を３倍して考えなくてはならない。
結果、最初の見積もりの少なくとも９倍が、実際に作業に必要な時間だ。
僕は、計算のしやすさもあって１０倍を目安に考えている。それが、先に書いた１０倍の意味だ。
「人月の神話」では古すぎる、今はもっといい算出方法があるはずだ、と言う人もいるかもしれない。
でも、比較的新しい「デスマーチ」にも、今でもこの方法が有効だと書かれていることも追記しておく。
（デスマーチも、すでに古典ということにされてしまっているらしいが…）
本質的な問題として、作業工程を見積もる方法なんてない、確度の低い見積もりに安全係数（ここでは１０倍）を掛ける方法以外ないのだ、と知っておかなくてはならない。
初めて見積もりを書く、駆け出しの独立プログラマーは、ここで安全係数を掛けない見積もりを出して、全然割に合わない仕事をしたりする。（自分の過去の失敗談だ (^^; ）
作業時間が算出できれば、金額も算出できる。
１日は８時間労働、なんらかの専門家の日当は通常５万円なので、単純に計算すればよい。
１週間は５日間なので、それで計算すれば納期も算出できる…
ことになるが、それは少し伸ばした方が良い。
1.2倍にするか、1.5倍か、思い切って２倍か…は、人による。僕の場合、複数の仕事を同時に抱えることもあるので、先方に納得してもらった上で２倍の日数をもらっている。
しかし、実際にはこの日数は「保険」でもある。
先に書いたように、作業に入る前に作業工程を見積もることが、そもそも不可能なのだ。
最初に見積もった作業工程を１０倍することで、「想像外の作業」の発生は大体吸収できる。
でも、それらの想像外の作業が困難の連続になったとしたら？ ここで、納期を長めに取ることに意味が出る。
もし困難が多ければ、長めにもらっていた納期日数の中で収拾がつけばよい。
長めにもらった分については、金額を発生させていない。だから、ただ働きだ。
しかし、それは自分が見積もりを失敗した結果なのだから、甘受しなくてはならない。
逆に、想像以上に仕事が早く終わる場合がある。それは自分が優秀なのだから、お金は有難く頂戴すればよい。
いずれにせよ、見積もりと言うのは「お客様にとっての」保険に過ぎない。
見積もりで出した日数内に終わり、金額も見積もりどおりなら何の問題もないのだ。
余りにも困難で当初の納期に間に合わないとか、十分実現可能と思っていた要求仕様が、実は矛盾があって作成不可能だった、と言う場合もある。
そういう時は、問題の発生がわかった時点で、すぐにお客様に連絡。丁寧に事情を説明すれば、普通は納得していただける。
追加作業が必要だから金額を上げて、については了承されない場合が多いが、矛盾があるから仕様を変更したいとか、納期に間に合いそうもないから一部機能をカットしたい、など、交渉の方法はいくらでもある。
工程表を最初に作り、あとは何の状況も説明せず、では、最後になって「言っていたことと違う」という論争になりかねない。
できることなら、定期的に現在どの作業を行っていて、どこまで出来ているかを報告するのがよいだろう。
全体に遅れているのなら、素直に早い段階で「遅れています」と言われていたほうが、納期が来てから「出来てません」といわれるよりも良い。
完成していなくても、途中経過を時々見てもらうのも効果がある。
思ったものと違っていた、など早く気がつけば修正も楽だし、それがお客様側からの要望で当初予定とは違う修正になる場合は、追加料金をもらえる場合だってある。
途中からの修正の場合、実は遅れている工程がある場合には、その遅れ分も「修正に必要な時間」に内緒で入れ込んでしまって納得してもらう、というようなテクニックもある。
…と、急にプログラマーの仕事の一端を書いてみたが、これはプログラマに限った話ではない。
最初に書いたとおり、ちょっと複雑で、誰もやったことがないようなプロジェクトであれば適用可能な話なのだ。
東京電力が、福島第１原子力発電所の事故を収拾するための工程表を発表した。
早速、遅すぎるとか、本当にこの通りに実行できるのか、等といった批難が相次いでる。
先に書いたとおり、やったことがない作業の工程表など作れない。実行期間の正確性など、保証出来るわけがない。
しかも、今回の作業工程表は、実際のところ作業内容すら見えていないのだ。
「漏水を止める」と言っても、どこから、どのように漏水しているかもわからない。
つまり、プログラムで言えば要求仕様もまとまっていない段階で作られているのだ。
それでも、作ったことに意義はある。それは、作成依頼に対する「荒見積もり」と同じで、ある程度の概要を示すことが出来るからだ。
今後、作業が遅れそうなら、素直に遅れると、理由を説明して発表すれば良い。
もちろん、未知の作業に対して十分な余裕は見積もって工程表を作っているだろうから、前倒しになる作業もあるだろう。
実際に作業をされる方々には、幾多の困難が予想される。
見守るしかない我々としては、作業が前倒しになったり、遅延したりするのに一喜一憂していてはいけない。
作業工程表とは、もともと「その通りには行かない」性質のものなんだと理解しておくことが重要だ。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |