プログラミングファースト開発
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。
テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。
熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。
プログラミングファースト開発の開発手順は次のようになります。
- 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す
- 保守のために必要なドキュメントを書く
ユーザにレビューしてもらって、ここは修正して欲しいといわれたら、できる限りその場で修正します。なんどかレビュー・修正を繰り返すより、その場でOKをもらったほうが効率的です。
即座に修正して、即座に動かさなければいけないので、スクリプト言語かSeasar2のようにHOT deployをサポートしたフレームワークが望ましいでしょう。
作業は、ペアで行なうことを推奨します。一人がプログラミングしているときに、もう一人がシナリオテストを書きます。ここでのプログラミングは、ユーザにレビューしてもらう前に準備をしている段階のものです。
実装が終わったら、シナリオテストを実行して、仕様とあっているのかを確認します。実装が複雑なものは、ユニットテストを書きながら実装を進めてもいいと思います。
シナリオテストを実行して、バグが見つかれば、バグの周辺のユニットテストを書きます。これが、極力ユニットテストを書かずに品質を確保する方法で説明した「バグは偏在する」という性質を利用して、少ないテストで一定の品質を確保する方法です。
テストを書かずにプログラミングをどんどん進めると、プログラムが場当たりな感じになってしまいがちですが、ペアでソースコードとシナリオテストをレビューしあうことで、品質を高めていきます。
テストサミットで話したときは、ペアでの作業やシナリオテストを最初に書くことは、盛り込まれていなかったのですが、その後のフィードバックを受けて、手順を修正しました。
開発工程は次のようになります。
- 要件定義
- これまでと一緒
- プログラミングファースト開発
- 総合テスト
- これまでと一緒
開発の単位はユースケース。ペアで関連のあるいくつかのユースケースを担当します。ユースケースをまたがるようなロジックもペアで関連のあるユースケースを担当するようにすれば、うまく扱えるんじゃないかと思います。
ペアにどんな人を選ぶかですが、最初のうちは、業務SEとプログラマの組み合わせが良いんじゃないかと思います。業務SEはプログラミングを学び、プログラマは業務を学んで、最終的には、一人の人がSEとPGのスキルを持つことが望ましいと思っています。
みんなが業務もプログラミングもできるようになったら、ベテランと若手のペアにします。若手のスキルアップには、経験豊富な人と組ませるのが一番です。
プログラミングファースト開発によって、ユーザは、自分の欲しいものが早く手に入ります。これは、ユーザにとって価値のあることなので、開発者の単価を上げることができます。単価を上げても、全体の工数が減れば、ユーザにとっては安くなります。
オフショアなんて必要なくなります。だって、プログラミングフェーズに大量に人を投入する必要はないし、最初にプログラミングは出来上がっているんだから。
全部自分たちで開発する。これって気持ちいいし、利益も出る。
