この写真良いなぁ。
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは?という私のアイデアをシェアしたいと思う。 注:このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、…
情報源: ソフトウェアの納期見積もりは、星占いレベルのものであると思う – メソッド屋のブログ
結局「ソフトウェア開発は積算可能なのか?」と言う問題につきるわけですが、実際には不可能でしょう。それを行うにはソフトウェア開発が産業としてもうち一段階か二段階上のの工業化が実現されないと無理だと思います。あるいは、システムが今よりも単純でソフトウェア開発にリアルに「製造工程」があった頃は一応のカッコ付きで可能だったのかもしれません。まぁ二段階上の工業化を進めたら「アプリケーション」をつくるプログラマはほとんど必要ないかもしれませんけど。
つまり、プログラマとそのチームの生産性の集合知が事実上無く、一般化した積算根拠なんて作れませんって話ですね。型枠職人の間でも生産性の違いはもちろんありますが、それが個人間で5倍とか10倍とかになることはありませんが、ソフトウェア開発ではそれがあり得るので、汎化した積算資料作るのはそもそも無理。
そう考えるとチームを固定して、実績から積算根拠となる数値を作らないと見積も工期設定も出来ないって事になるでしょ。そう考えると安定してシステム(アプリケーション)を開発維持しようと思うとチームを固定できるような契約形態や受発注の仕組みが必要で、それ一番簡単な方法が内製化って話です。またそうした根拠を作るためにもメータリングは必要だし、アジャイルはアンチ工学じゃないって話でもあります。
まぁ、いろんな願望込みで書いてますけど。
※あくまでも個人の意見で、所属会社とは関係ありません。
[amazonjs asin=”B01EVM3XVK” locale=”JP” tmpl=”Small” title=”積算資料 2016年 07 月号 雑誌”]
コメント