プログラミングファースト開発の必要性

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに﹁設計書﹂と名のつくものは全部クソだ。だって動かないんだもん。

動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。

結局はコードを仕上げてから動かして初めて﹁だめだこりゃ﹂ということになる。


○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。
動かないものをいろいろレビューしても、本当のことはわからないから、レビューの結果に信憑性がないのだ。上っ面をレビューしているに過ぎない。
だからといって、○○設計書が、無駄だというのは言いすぎだ。メンテナンスをする上において、○○設計書は、重要な資料になる。


つまり、○○設計書は、物を作るうえにおいては意味があまりないけど、メンテナンスをする上では重要なのだ。


これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。
プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーションでまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。
おいらは、XPに関しては、2000年に会社ではじめて以来、主破離のプロセスを通って、今ではほとんど意識してないけど、スピリッツは、ずっとXPのまま。考えの根本にはXPがあると思う。
軸がぶれないって危険なことかもねのエントリでもこの辺が良く現れてるね。


アジャイルって言い方をしてないのは、SIerとかで取り入れるのが難しいからなんだよね。アジャイルに、無条件に拒否反応を示すSIerっているから。プログラミングファースト開発なら、SIerでも受け入れることができる。
最初に要件定義をして概算の見積りを出す。これは準委任契約(成果物ではなく、人月で請求する)。
次に顧客と仕様を実装に落とす部分(プログラミングファースト)も準委任契約で行なう。これも工数がどれくらいになるかは確定しにくいから、準委任契約が良い。
プログラミングファーストで仕様が固まったら、後は、一括請負(成果物ベースで請求する)でドキュメントやテストなどを行なう。
この形態なら、SIerでも契約しやすい。


仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。


プログラミングファースト開発を今のSIerで行なうのは、厳しいのかもしれない。プログラミングファースト開発は、基本的に全部内製するって考えだから、下請けに投げていくゼネコン体質には向いていない。
どうすればよいのかは、いつも考えている。
プログラミングファースト開発をおこなう会社を今の会社からスピンアウトして作るってのが、一番現実的かなと思っているけど、この辺はまだ考え中。フレームワークや開発手法などをプログラミングファースト開発にむけて整備するのが、第一段階だね。