これはいい！Programming First Development

これはいいなあ。
Developers [Test] Summit 2008（デブサミTest）で、ひがやすを氏が紹介したというソフトウェア開発方法論「Programming First Development」。

「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論:ITpro

この方法論では，要件定義のあとにドキュメントを書くのではなく，いきなりプログラミングしてしまう。プロトタイプではなく，本番で使うプログラムの8割くらいを作ってしまうのである。紙で書いた仕様書をユーザーにレビューしてもらう代わりに，プログラムを動かしてユーザーが実際に触ることで動作を確認してもらう。保守に必要な基本設計書や外部設計書は後で書く

プログラミングの際には，実装優先でとりあえずテストは考えない。シナリオ・ベースでテストしていき，バグを発見したら，その周辺でユニット・テストを書く。「バグは偏在していることが多い」（ひが氏）からだ。

「大規模開発ではどのように作業を分割するのか」。これに対しひが氏は「上流の開発者と下流の開発者を分けてしまうと，コミュニケーション・ロスが生じる。一つの機能やユースケースを小さなチームに割り振り，最初から最後まで担当するようにすればいい」と答えた。

プログラムは想像で書いたドキュメントより価値が大きい

これは今まで言語化していなかったけれども、私がいつもとても効率的だろうとイメージしている開発手法にかなり近い。感覚的にはそういう作り方していてもプログラミングをしながら、かなりのホワイトボックスなテストをしているのであって、要するにユニット・テストに関わるドキュメントにかかるコストが耐え難いのである。それに要件定義からプログラミングまで全部に関わりたいなんて言う私にはまさにうってつけである。

「今はSEとプログラマが分かれているのが問題。プログラミングを知らない人が仕様を書くから，実装できない仕様が生まれる。あるいはプログラマが言われたことをそのまま作るだけになってしまう。この状況を打破するには，仕様を考える人とプログラミングする人を同じにしなければならない。1人でできるようになれば全体の工数は減るので，月300万円程度まで単価を上げられる。人月が悪いわけではなく，人月でも単価が高ければいい」

これも大いに同意したい。

ついでにコメントしておくと、私としては「プログラマが言われたことをそのまま作るだけ」になる事の方が罪というか問題が大きい気がする。

SEがプログラミングを知らないなんて事があるのか？という気もしますが、まあプログラミングを知らなくても論理的な思考力・分析力があれば、まともな仕様は書けるのではないかとも思う。
もちろん実際にどれ程そうできる人がいるのかは別だし、プログラミングを知っている人とはちょっと違うコミュニケーションが必要になるかもしれないが、必ずしも悪い話ばかりとは限らないと思う。

それに対してプログラマが言われたままに作るだけというのは、その仕様の業務的な意味を理解しようとしていないという、ある意味で思考停止な状態なわけだ。少なくともエンタープライズなシステム開発においては最低な話である。

その際立った例がいわゆる「IT土方」的にプロジェクトに投入されるソフトウェア開発の初心者なんだろう。
まあ、そんな初心者では「言われたことをそのまま作ることすらままならない」場合もとても多いのだけれど。建前としては彼らがユニットテストを終えた事にしておいて、後のフェーズでほぼ完全に書き直す事もあったりする。

そんな現状を打破し、要件定義からプログラミングまで(少数)精鋭だけで遂行できるプロジェクトがあったら、どんなに楽しく有意義だろうと思ってしまう。

内容はちょっとズレるのかもしれないが、机上の「想像」だけで仕様を固める「ウォーターフォール」な開発手法(及びプロジェクト遂行管理)をいつまで続けていく気なのか、と時々思う。

できる事なら私もこの「Programming First Development」を実践できるようになりたいと思う。