プログラミングファーストはSI開発には向かない
いまかなり理想論的なことを言っているが、この件はみなさんおおいに議論して欲しいと思う。
http://kamawada.com/~masanori/blog/2008/07/post_523.html
このブログでも再三言ってきているように、欧米からパッケージやソフトウエアを買ってきて、
人月作業は中国・インドにもっていくなんていうモデルはくやしいと思いませんか。
mark-wadaさんに釣られて色々意見が出てくるかとおもいきや、
なんだか意外と意見が出てきていないようなので、自分の意見をマジレスで書いてみる。いつもそうだけど。
自分の意見では、プログラミングファーストは現在のSI開発では（そのままでは）導入できないと思う。
自分の前提は10人以上の開発者が入る（ピークはその数倍以上）感じの中・大規模案件程度ね。
プログラミングファーストはまず幾つかの前提があるように思う。
- お客さんがある程度時間がある。動くものを見てもらってというループを繰り返すならそうならざるを得ない。
- 勿論開発者はプログラミングが相当できる人前提。
- どちらかといえば新規案件前提？既存だとお客さんとしても現行どおりって言われる感じだし、動くものをみないでも進むと思ってそう。
まずお客さんのかかる時間として、プログラミングファーストの方が長くなるんじゃないかと思う。
実際大量の画面がある場合、それをお客さんに触ってもらってってのは良いことだとおもうけど、
全部触る時間もないだろうし、人の意見なので前回の意見と変わっちゃう場合だってあると思う。
とはいえ、プログラミングファーストだと、お客さんに幾つかの機能だけを見てもらって、残りは仕様書レベルで
合意するよとかって出来ない。
またお客さんとの間では合意のプロセスがとっても大事でしょう。
仕様書ある場合とプログラミングファーストの場合で比較してみる。
仕様書ありきだと、
SIerが仕様書提出
→お客さんがOKかどうか判定
→SIerが実装
→お客さんが前回提出した仕様と実装が同じか判断。
→リリース
って流れだけど、
プログラミングファーストだと以下の流れみたいになってしまって、
★の部分が大変じゃないかなあ？
SIerが実装提出
→お客さんがOKかどうか判定
→SIerがに多分1度でOKはもらえないので返ってくる。再度実装
→お客さんが再度動きを確認 ★ここが大変！★
→SIerがOKそうなら仕様書を書く？
→リリース
何故かっていうと、前回の動きをお客さんが覚えているとは限らないから。
それとそんなに重要じゃない部分でも意思決定するときに仕様書のような拠り所がないと
お客さんは不安に思うんじゃないかな。本当はそんなに重要じゃない部分だけど、決定に時間がかかっちゃったりもするし。
ただ、ここの時点で徐々に仕様書を作っていき、段階的に仕様をつめていくなら全然アリだとおもうけど。
あとはコードだけだとHOWは書いてあるけど、WHYは書かれないからそれは仕様書として早めに書いておくべきだとおもうな。
だってお客さんとしてもWHYがあってないシステムには意味が無いしはなるべく早く確認したいのが人情じゃないかと。
また、開発メンバーの話で言えば、自分のいた/いる開発の現場は、異なる役割の人のコラボレーションで仕事が成立してます。
プログラミングが出来る人もいれば出来ない人もいる、そんな現場。
それはそれで受け入れてみんな上手くやってるし、それは悪いことじゃない。人には得手不得手あるので。
実際にコード書いたりの技術な人、業務を知ってて業務的な整合性取ったりとか改善をする人、人の管理やお客さんとフェースする人、
あとはお客さんの4種の役割があってそれらのコラボレーションで成り立ってるというのが自分の見方。
そうなると、役割ごとに見たいもの・スキル的なアンマッチもあるので、共通したコミュニケーションの
手段が必要です。それが仕様書なんだと思う。この辺はよういちろうさんの意見と結構近い。
プロトタイピングとか、プログラミングファーストとか、近年ではプログラムの動作をまず確認してもらって、
妥当であればそれで良し、的な風潮が見え隠れするけど、プロジェクトが完了して成果物が顧客に渡る際には、・ ○○という人々に□□という目的で△△というドキュメントを書きました。
・ このシステムは○○という操作をすると△△という動きをすることを良しとしました。という2点が揃っていることが、開発側の最低限の責務だと思う。
http://www.eisbahn.jp/yoichiro/2008/07/post_211.html
この1点目の誰にというのがポイント。これは顧客だけじゃなくて、大規模になればなるほど
関係者も増えるので、そのためのコミュニケーション手段としての仕様書が必要になるのが現実だと思う。
例えばAってシステムとBってシステムの外部接続インタフェースとかプログラミングファーストで出来ないだろうし。
コミュニケーション手段として仕様書書くはずです。特にオフショアとか遠隔地ならなおさら。
このように、ひがさんが言う保守するための仕様書はとっても大事なのも間違いないんだけど、
コミュニケーションの手段としても同じくらい重要。特にコンテキストが異なる人・役割が異なる人の間だと、
ちょっと多めに残してあげなくちゃいけない。これが今のSI開発でなんで仕様書がこんなにいっぱいあるのという現実じゃないかな。
勿論不要な仕様書は断固反対。メンテのコストもバカにならないし、保守時に要・不要の判断したりしなくちゃいけなかったり、
それがバグの原因にもなる。
ただし保守に行くまでの間の開発時でも仕様書は必要だと思う。
仕様書の記述するボリュームに関しては考えるべきところはいっぱいあるし、今のバンバン書いているのが
適切だとはとても思えない。だから、もっと仕様書をスリム化させて最小限の記述量でいく方向が正しいし、
このエントリの趣旨にはあわないけどそもそもお客さんの要求から本当に必要なものだけを抽出して、
なるべく実装しないでニーズをかなえていくのが一番適切だと思う。
なので、ひがさんのプログラミングファーストは出来るプログラマの少人数体制の限定されたコンテキストが
前提なんじゃないかと思えるわけです。例えば、アジャイル開発のようにお客さんもまじっての口頭ベースなどで
仕様が徐々に決まるような開発。それなら凄くわかる。最適だとおもう。
しかし、どうにも規模の問題がからんでくるようなSI開発の現実からいきなり一足飛びにそこにはジャンプ出来ないのが課題ですね。
それより能力の異なる人同士できちんとコラボレーションできるような仕組みがあるといいと思うんだけど、
いまのところその現実解が仕様書じゃないでしょうか。それを超えるものがどうにもないので自分としては最小限の手数で仕様書を書いて、
最大限仕様書を有効活用しようとする方法論がベストだと思ってます。
なので自分がもしやるとしたら、プログラミングファーストの良いところだけをポイントで抜き取って仕様書を書いて開発する。
たとえばこんな感じ。多分うまくやってる人は今でもこういうのやってそうだけど。
- お客さんに作りたいもののイメージと安心感を与えるためになるべく早くプロトタイプを動かして大枠で挙動をみてもらう
- 初期はプロトタイプをコミュニケーション手段として、お客さんと話をした結果を仕様書にまとめ、仕様を仕上げていく
- 中期は初期で段階的に出てきた仕様をお客さんとの間で合意にいたるように仕様書を記載
- 末期としては仕様書を元に実装をした上でお客さんに仕様との乖離がないかをチェックしてもらう
- リリース
最後に別問題ですが付け加えるなら、大規模なSI開発なら、一番取り組まなくちゃいけないのは
規模の問題でしょう。ボリュームとしての業務の量が多すぎる、関わる人数多すぎるなどなど。
特に業務のボリュームとして大規模でも、関わる人の人数を減らしていかないといけないのは間違いない。
関わる人数の多さが仕様書の多さ・コミュニケーションコストの多さにつながっているので。
これにはSIerと日本の雇用形態が抱える悩みがあるので一概に解決できないし、自分には今のところ思いつかない。
ただし、規模の問題が解決した結果として、例えば5人とかで大規模でもプログラミングファーストしちゃうのは明るい未来だなあと思います。
（追記）
いまさっき知ったけどid:manameさんがこんなこと書いてたのね・・・・
基本設計書、詳細設計書、プログラム設計書などあるけれど、それぞれ連結試験、単体試験、コーディングが
正しいかどうかの試験項目をあげるために作っている。それによって仕様とソースが等しいことを確認しているのだ。だから私はプログラミングファーストという単語を聞くと必ず思うことがある。「その後付けの設計書がプログラムと等しいことを
http://d.hatena.ne.jp/maname/20080721
どうやって保証しているのか」「作ったプログラムの試験項目はどのように作成しているのか」ということ。
この観点は自分の観点と非常に近いです。まなめさんの「その後付けの設計書がプログラムと等しいことをどうやって保証しているのか」は
開発者サイドの視点ですよね。これもそのとおりじゃないかなあ。自分が書いたのは、これをお客さんからみたときの話ですね。
