レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない

ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。
お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。

そんなことやってちゃだめだと。


1キロステップの生産性指数をだして、今回の開発は10キロだから1000万円とか。

汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が1キロ(1000行)だったら1人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。


フレームワークのコアのコードも、
ビジネスロジックの肝のコードも、
ネットワークの通信コードも、
自動生成したコードも同じ1ステップとカウントする。

見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して
次の開発の値決め(ダンピングともいう)につかうんだから、ソフトを開発する側としてはやりきれない。
生産性を上げようという発想も生まれないし、出来るだけコードを短くして保守性を上げようという発想もうまれない。


でも、大きなSIerさんでは結構まかり通ってる話で、1社じゃないどころか結構な数のSIerさんがいまだにそんな事やってる。


そりゃあ、廃れるってSI企業。

そこには絶対的に危機感持った方が良いです。若い人は特に問題意識を持った方が良い。


僕は色々やってきたけど、ソフトウェア開発では見積もりほど成否に直結する工程は無い
そして見積もりほど、SIerで適当に行われている工程もまたないと思う。(しょせん未来の事なんてわからないよみたいなスタンス)


ウォーターフォールでやってる会社さんなら余計源流かつ源泉でしょ?。一番手戻ったらキツイ部分でしょ。

もっと科学的にやろうよ。


現実的じゃないって解っていながら流されているケースが多い、もしくは他の方法を知らないっていうケースもある。
会社の標準ルールだからしたがうって思考停止のケースもある。


生産性はやたらしぼる方向で緻密になっていくのに、見積もり精度は相変わらずどんぶり勘定のステップ見積もり。

何の根拠にもならない数字をいじり倒してそれなりにもらえる数字にしようと見積もりする作業は、すぐにやめた方が良い。

意味ない上に、害悪がある。


良い見積もりというのは、考えぬかれた計画だ。

そして見積工程で必要なのは、開発のリスクを見通した上での条件交渉

算出される結果としての数字(または価格)は、計画を全うするのに必要な予算だ。


見積もりで描いた青写真を実現していくのに、合わない部分や予想外のことが起こるのは当たり前だが、

はじめから見当違いの青写真を下書きにして、違う絵を描こうとするならうまい絵が描けるわけない。


エイヤっと見積もって、開発の生産性アップでなんとかして!ってのは、無責任すぎる。
未来は不確実だからって諦めて、当たるも八卦で占うってことでもない。そんなの覚悟がなさすぎる。


成功までの青写真を描いて、その通り進めるんだという覚悟が必要で、
だからこそ生まれる責任感があって、、


不測の事態を見越してリカバリできるように、後だしじゃんけんにならないように、条件交渉を盛り込んだ、計画こそがソフト開発の見積もりだと思う。


SIはソフトを売ってるんじゃない、作り上げる過程と作り上げるサービスを売ってるんだから、その道程を計画して見積もりするべきだろう。


僕らの会社は幸い、そういうことをしっかり考えたので受託案件で赤字になった事はないし、だいたい定時に帰ってきちんと納品する。

見積もりのときに、最後まで見通した計画をするからだと思ってる。


僕らの見積もり手法は、ファンクションポイントにストーリーポイントのエッセンスを加えつつ現代風にアレンジして、

プログラムの内部構造の複雑度をポイント化したものをベースにする。


予測が比較的容易な実装工程の実績工数を基準にした係数を使って

ファンクションポイントを機能の重みと捉えて係数で掛け算する。


でも出来るだけ掛け算は控えめにする。

掛け算は、丸めの部分が大きくなってしまうからだ。

それよりも細かく見積もって足し算で計算する。


僕は、見積もりには自分ならこういう作業はこれぐらいでやるっていう作業感覚を大事にしたい。

それぞ宣言的な工数として算出し、できるだけ足し算で計算する。


見積というものは、正確に実績工数を予測するというものではない、

見積は、予測ではなく計画であり宣言だと思っている。



開発の付帯作業も、納入までのWBSを出来るだけ細かく見通して、工数に加味する。


SLAの難易度や、システム要件の難易度をポイント化して加味する。
この辺ファンクションポイント法からの流用だ。


そうやって出来た見積もり金額は、高いともいわれるときもあるが、根拠がしっかりしているので妥当な金額だと胸がはれる。

実際、今までの開発でだいたい予測を大きく違わない着地をしている。

安く出したら、うちのエンジニアを不幸にするだけだし、エンジニアを祖末に扱う事につながる。

根拠無くディスカウントを大きく求められたなら、どっちみちエンジニアに苦労をしいるか、そもそも成功しない案件になるだけだから、心置きなくお断りする。


利益を上げる体質になっていないソフト会社は、一番最初の見積もりを考え直した方が良い。

ステップ数で見積もりやってる会社さんに居るなら、疑問をもって改善した方が良い。

ステップ数見積を見積工程の成果物にすると、計画を立てずに物事を進めるということにつながりやすいので、いけませんよということです。


生産性とかアジャイルとかフレームワークとか言語とかも大事だけど、

見積をちゃんとやるのはすごく成功に寄与するよ。