NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ

昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。
今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。
プログラミングファースト開発の詳細はこちら。
http://d.hatena.ne.jp/higayasuo/20080501/1209636051
http://d.hatena.ne.jp/higayasuo/20080721/1216607451

最初のテーマは「品質」。データとしては、

テストコードのカバレッジやバグ密度などで品質を確保しようとしている。
でも、品質に問題があるプロジェクトも残念ながら存在する。
品質に問題があるのは、上流での要件定義や外部設計に問題があることが多いので、上流をより完璧に近づけるように努力していきたいとのこと。

テストコードのカバレッジを見るのは悪くないと思うんだけど、カバレッジの数字だけにとらわれて、本当に必要なテストが漏れてしまうことも多いので、注意が必要。また、数字をあげることにとらわれて、意味のないようなテストが増えてしまうことも問題。
カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。

問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。

Kさんはこういってました。
ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
品質の高いものを作るためには、最初から動かしてみるしかない。だから、プログラミングファーストで開発しているんだと。

私の考えだと、「品質は実際に使うことで高めていくもの」です。実際に使ってみないと、目的にあっているかどうかなんてわからない。上流の設計の精度を高めるのは、限度がある。ユーザですら自分が本当に欲しいものは何なのかわかっていないのに、精度の高い設計なんてできるわけがない。
だから、プログラミングファーストで最初に作って、実際に使ってみるのです。

次のテーマは、開発プロセス。
Kさんのビジネスにおいては、スピードが最も重要。アイディアをできるだけ早くビジネスとして実現する必要がある。だから、開発プロセスは、軽量化したい。
軽量化するうえで目をつけたのが、設計書。昔は、たくさんコードを書かなければいけなかったので、自然言語で考えた(設計した)上で、コードを書く必要があった。でも今は、フレームワーク(SAStrutsなど)が発達しているので、コードは必要最小限のものですむ。コードを見れば何をやっているのか一目瞭然なので設計書は書く必要がない。
設計書のかわりに、外部仕様のテストシナリオを書く。テストシナリオが設計書のかわりになる。
設計書を書かないことで、かなり開発のスピードが上がる。

そのとおり。これだけ理解力のあるユーザがいるなんてびっくり。
さらに付け加えると、品質を上げるためには、早期のレビューが重要。プログラミングファーストでは、ペアで開発するんだけど、ペアプロではなく、一人がプログラミングをしているときに、もう一人はテストシナリオを書く。そして、お互いにレビューしあう。これでより、品質を高められると思います。

データは、コードレビューは、ほとんどしていないといってました。社員がコードを理解できないという問題もあるでしょう。コードを理解できない人が、設計書を作っているってのもおかしな話なんだけどね。
ただ、データにはアーキテクチャや設計のレビューをしている部隊がいて、その人たちが、コードの早期レビューを行なったときは、とても効果があったということでした。
早期のコードレビューは、品質を高めるのにとても効果的なので、データ全体で行なうことをお勧めします。

最後のテーマは、SI業界の多重下請け構造をどう思うか。
ずばりいえば、データは多重下請け構造の頂点にいて、まったく困っていないので、多重下請け構造をどうこうしようとは思っていないというのが、本音でしょう。
SIの新しいビジネスモデルが現れて、自分たちのビジネスが脅かされない限りは変える必要がない。
日本のSI業界の多重下請け構造をなくすためには、新しいビジネスモデルが必要なのです。

この新しいビジネスモデルこそ、「プログラミングファースト開発をするSIer」だと思っています。全部内製で、自分たちで最初から最後まで開発するSIer。
ユーザから見るとこれまでより早く、コストが安く、自分たちの思ったものが手に入る。

「プログラミングファースト開発をするSIer」は、私自身で作ろうかと思っています。今はその準備中。プログラミングファースト開発が本当に通用するのか、もっと経験をつむ必要があるから。

追記:主催者の方の議事録が公開されているので、合わせてご覧ください。
http://d.hatena.ne.jp/ikedatka/20080831/1220184983