ひがやすを blog このページをアンテナに追加 RSSフィード

Information

2008-07-21

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

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

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

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

システムエンジニア不要説 - masayangの日記（ピスト通勤他

○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。

動かないものをいろいろレビューしても、本当のことはわからないから、レビューの結果に信憑性がないのだ。上っ面をレビューしているに過ぎない。

だからといって、○○設計書が、無駄だというのは言いすぎだ。メンテナンスをする上において、○○設計書は、重要な資料になる。


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


これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。

プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。

プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーションでまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。

おいらは、XPに関しては、2000年に会社ではじめて以来、主破離のプロセスを通って、今ではほとんど意識してないけど、スピリッツは、ずっとXPのまま。考えの根本にはXPがあると思う。

軸がぶれないって危険なことかもねのエントリでもこの辺が良く現れてるね。


アジャイルって言い方をしてないのは、SIerとかで取り入れるのが難しいからなんだよね。アジャイルに、無条件に拒否反応を示すSIerっているから。プログラミングファースト開発なら、SIerでも受け入れることができる。

最初に要件定義をして概算の見積りを出す。これは準委任契約(成果物ではなく、人月で請求する)。

次に顧客と仕様を実装に落とす部分(プログラミングファースト)も準委任契約で行なう。これも工数がどれくらいになるかは確定しにくいから、準委任契約が良い。

プログラミングファーストで仕様が固まったら、後は、一括請負(成果物ベースで請求する)でドキュメントやテストなどを行なう。

この形態なら、SIerでも契約しやすい。


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


プログラミングファースト開発を今のSIerで行なうのは、厳しいのかもしれない。プログラミングファースト開発は、基本的に全部内製するって考えだから、下請けに投げていくゼネコン体質には向いていない。

どうすればよいのかは、いつも考えている。

プログラミングファースト開発をおこなう会社を今の会社からスピンアウトして作るってのが、一番現実的かなと思っているけど、この辺はまだ考え中。フレームワークや開発手法などをプログラミングファースト開発にむけて整備するのが、第一段階だね。

Permalink | コメント(5) | トラックバック(2) | 11:30 プログラミングファースト開発の必要性を含むブックマーク プログラミングファースト開発の必要性のブックマークコメント

コメントを書く

masayangmasayang 2008/07/21 11:39 トラックバックいただきました。

コードから起こしたドキュメントを設計書というのかどうかは微妙ですが、ソースをよむ手がかりを残すのは良いことではないでしょうか。自分もJava使ってた頃は、コードからUML起こすツール使ってました。ソースとの乖離がないことが保証されていれば最高。

あと、ソース読む手がかりという意味では、BasecampとかTRACとかに残った記録でも充分ではないでしょうか。要は資料整備のために開発者が二度手間かからないように工夫することだと思ってます。


自分もAgileをSI屋で扱えるよう、いろいろ考えてはいます。なかなか難しいですね。
そのうちブログに書きます。

通りすがり通りすがり 2008/07/21 12:00 ソースとの乖離がないUML。
まさに仕事で、そんなもの書いてます(PG前に)。けど、それこそソース嫁って感じ。保守に役立つドキュメントはどんなものなのか？をもう少し考えたいです。

通りすがり２通りすがり２ 2008/07/21 16:22 ホントインターネットって疫病神だわ。
まあ過労死しない程度に人月安売りしてね。

shiroshiro 2008/07/21 16:48 私見ですが、ソースコードはhow(とwhat)の直接表現である一方で、whyを直接表現することができませんよね。一方、メンテにおいて最初に知りたいのはwhy (何故全体がこういう構成になっているのか、何故このコンポーネントでこのアルゴリズムが選択されているのか、etc.) です。なので、おおまかに言えばwhyが記されているドキュメントこそが保守に役に立つのではないかと＞通りすがりさん

nakanaka 2011/01/15 13:29 「メンテナンスする人が必要になるドキュメントを書く」っていうのがいいですね。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
 ゲスト

画像認証

トラックバック - http://d.hatena.ne.jp/higayasuo/20080721/1216607451
リンク元