高品質なWebアプリケーションの開発手法

ここ最近、高品質なWebアプリケーションを効率よく開発するにはどうしたらいいかということを真剣に考えています。というのも、今まで構築してきたシステムにプログラムのバグが立て続けに発生するようになってきたためです。今までのプログラマ個人主義の開発体制の限界がきたのかもしれません。この問題を解決するために、まずはシステムになぜバグが発生したのか、その原因を把握することから始めたいと思います。

ケース１： 単純にテストが足りない

ユーザは時として、プログラマが予測しないようなデータを入力してきますし、XSS、SQLインジェクションなどをねらった悪意あるデータを入力される可能性もあります。それらの想定される様々な入力に対して十分なテストが行われていないと、一見正常に動いているように見えても、後々バグが見つかるということになってしまいます。また、システムのあまり重要でない機能に多いのですが、単純にプログラムのアルゴリズムが間違っていたなんていうはずかしいバグもありました。

ケース２： 長期の継続的な追加開発によるシステムの破綻

何の開発手法も確立していない状態で、数年にわたりシステムを継続的に開発していくと、コードはスパゲティのように複雑に絡み合い、あるバグの修正が別のバグを引き起こすというようなひどい状況になりえます。また、数年前のプロジェクトということもあり、ソースコードの管理がきちんと行われていなかったりして、修正したつもりがデグレードというような恐ろしいことも起こりえます。このケースではクライアントさんとの付き合いも長くなっているので、問題は深刻です。

ケース３： 開発担当者はもういない

古いプロジェクトになるとそのシステムを開発した人間がすでにいなくなっているケースです。バグが発生したときには仕方なく今いる人間が、ソースコードを読み直し、システムの内容を把握、そして修正を行わないとなりません。コーディング規約などが整備されていないため、なれない人間だとソースコードの解読にかなりの時間を要します。そしてこのような非建設的な事柄に貴重な時間を浪費してしまいます。

問題可決には何をすべきか

こうやって、失敗したケースを並べてみると何をしたらいいのか何となく見えてきます。おおざっぱにまとめると以下のような感じでしょうか。

• テスト方法の整備
• コーディング規約の整備
• ドキュメントの整備

ではこれらをどう実践していくかということですが、XP（エクストリーム・プログラミング）という開発手法を応用することで、うまくいきそうな気がします。XPというとペアプログラミング、テストファーストという言葉がすぐ浮かんでくるんじゃないかと思いますが、物事をできるだけシンプルに考えようという姿勢が僕は好きです。また、開発速度が上がることも期待できそうです。開発速度について、はてなのnaoyaさんのWeblogには以下のように書かれています。

はてな はまぞう - ASIN リンク支援ツールの開発裏話 : NDO::Weblog

フレームワークを使って、もう一人のエンジニアとのペアプログラミング。毎朝にスタンディング・ミーティング（立って会議)をして仕様を策定し、二日ちょっとで作り上げました。やろう、と決めてから三日以内にリリースというスピードは、Perl フレームワークと、XP のいいとこ取りをした開発スタイルに依るところが非常に大きいです。

XPとフレームワークを利用して、３日で機能を開発したそうです。他にもXPを導入している会社の話をちらほらと聞きますし、どうやらWebアプリケーション開発にXPが有用なのは確かなようです。

それではXPを使うと先ほどのケースはどのように解決できるでしょうか？

ケース１： 単純にテストが足りない。

これを解決するためにはテスト方法を整備しなければなりません。XPではテストを機能テスト、単体テストの２つに分けて行います。機能テストはユーザ（クライアント）がこのように動いてほしいと思った通りの挙動を示すかのテストで、単体テストはプログラム内の各オブジェクトのメソッドが期待通りに動くかのテストです。前者はテストの性質上、ユーザ側に行ってもらうのが理想です。といってもクライアントによってはWebの知識があまりない場合も多いので現実的にはディレクタがユーザと話し合ってテストケースを決めるという形になるでしょうか。また、後者の単体テストはプログラマの仕事になります。ここで重要なのがテストもプログラミングするという点です。テストスクリプトを作成し、残しておくことで繰り返しテストを行うことができますし、様々な良い副作用も期待できます。これらの２つのテストをきちんと行うことで、バグはグンと減ると考えられます。また、ペアプログラミングを行い、もう一人の人間がテストケースを考えるというようにすれば、さらにバグの比率は減るでしょう。

ケース２： 長期の継続的な追加開発によるシステムの破綻

XPを使うことで、このケースも失敗のリスクを減らすことができます。機能を追加するごとに単体テストを行うことを義務づけます。テストはテストスクリプトとして残っているため、それを毎回実行することで、ある機能を実装したおかげで別のところにバグが生じた場合も事前にそれを見つけることができるようになります。また、CVSなどのリソース管理システムを導入し、リソースを管理することでデグレードの危険を回避します。

ケース３： 開発担当者はもういない

これを解決するにはドキュメントの整備が必要ですが、得てしてプログラマはドキュメントを書くのが嫌いです（偏見？）。XPでは単体テスト用に書いたテストスクリプトがそのままドキュメントになり得ます。メソッドがどのような振る舞いを期待されているかがテストをみればわかります。プログラマにとっては文章でまとめられたドキュメントよりもこちらの方がシステムを理解するのに役立つのではないでしょうか。また、もういない誰かが書いたテストケースをすぐに実行できます。自分の修正が正しいのかもそれで確認ができます。自分のせいでシステムが壊れていないかも確認できます。テストスクリプトを書くということにはこのような副作用もあるんです。

XPをいきなりどかんとすべて導入というのはちょっと無理があるので、まずはコーディング規約の整備、単体テストの義務づけあたりからやっていこうかと思います。