エンジニアは日々現場で学ぶ
開発現場で学べること
第5回　開発のトラブルは必然と考えよう

クロノス 山野寛
2004/3/3

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■トラブルの発生は必然である

　クライアントや開発メンバーに恵まれ、毎日残業なしの8時間労働が続く。大きなトラブルや仕様変更もなく、完成度の高いシステムにエンドユーザーも大満足。開発コストも大幅に抑えることに成功し、最終的には大幅な黒字でカットオーバーを迎えた。

　あなたは、このようなシステム開発の現場を経験したことがあるだろうか。残念ながら筆者はいまだかつてこのような素晴らしい現場に参画したこともなければ、周囲からそのような話を聞いたこともない。私が過去に参画した多くの現場では、必ずといっていいほど大きなトラブルや仕様変更に見舞われ、エンジニアたちは寝る間も惜しんで対応に明け暮れていた。これはまさに、

システム開発におけるトラブルの発生は必然である

という言葉が、現在のシステム開発の現状を示しているのではないだろうか。

■要求の変化やトラブルにいかに備えるか

　そのような現実からも、近年のシステム開発の現場では物事がすべてうまく進むように準備を整えておく努力をすることよりも、将来立ちはだかるであろう要求の変化やトラブルに、どう対処すべきかの対策を練っておくことを重視する傾向があるのではないだろうか。少なくとも筆者はそう考える。アジャイルな開発プロセスの代表格であるXPの「変化を抱擁せよ（Embrace Change）」という言葉の裏側には、

ユーザーの要求は変化するものであり……

という意味が込められているのではないだろうか。つまり開発の現場においては、トラブルは必ず発生するというのは、もはや定説であり常識なのである。

　例に漏れず、今回の開発においても筆者の頭を悩ませたトラブルがあった。それは「単体テストの工数オーバー」である。われわれは開発に入る前の準備段階から多くの議論を行ったうえでテスト方針を決定したにもかかわらず、第1反復終了時点では当初予定していたテスト工数の2〜3倍もかかってしまっていたのである。

　では、なぜそのような事態になってしまったのかを順を追って説明しよう。

■テスト方針の決定

　まずわれわれは、第1反復計画時に製造フェイズで行うテストの方針を決定することにした。読者もご承知のとおり、システム開発ではフェイズごとにいくつものテストが実施される。一般的には以下の表1に挙げる種類のテストが実施されているだろう。

概要 対応する工程 対応する工程 単体テスト 個々のモジュール（部品）のみを対象としたテスト プログラム設計 結合テスト 複数のモジュールを組み合わせて行うテスト 詳細設計 システムテスト システム全体を対象に行うテスト 基本設計 （要求定義） 運用テスト （ユーザーテスト） クライアントが設計・実施を行うテスト 要求定義

表1　テストの種類

　この表1の概要の項目には、ごく一般的なテストの目的を記述しているが、実際には現場によってテストの対象範囲や粒度はまちまちのようだ。

　例えば単体テスト1つとってみても「クラス（モジュール）単位で検査する」と定義する現場もあれば、「1つの機能単位で検査する」という定義の下で実施する現場もある。

　また、オブジェクト指向開発が注目を浴び始めたころから、要求定義段階で抽出されたユースケースを中心として開発を進めていく、いわゆるユースケース駆動（UseCase Driven）で開発を行う現場も増えてきた。そういった現場では必然的に各テストをユースケース単位で計画・実施することも多いようだ。

　ユースケース単位でテストを行うことは一見シンプルに見えるが、実は意外にも計画立案が困難であると筆者は感じている。というのも、上記のように1つのユースケースを1単体テストと定義した場合、当然要求定義フェイズで抽出されたユースケースの粒度によって、そのテスト範囲は大きく異なってくるのである。

　例えば、ユースケースの粒度が大きい場合は、本来単体テストの目的であるとされる「プログラムの分岐条件を網羅する」といったようなテストケースの作成に高いスキルが要求され、ケース漏れも多くなる。逆にユースケースの粒度が細かいと、単体テストの実施量が増え、ドキュメント作成といったような間接的工数が無駄に増えてしまう。

　つまり単体テストをユースケース単位で行うことは、より多くの議論と計画を必要とし、もしもその決定が誤りであった場合は、開発全体の工数を圧迫してしまう恐れがあるということに十分注意したい。

　上記のことも踏まえ、われわれは第1反復での単体テスト方針を以下のように決定した。

（1）1ユースケースを1単体テストとする。
（2）設計者が単体テストのテストケースを作成し、テストデータと予想される結果を日本語で記述する。
（3）製造者はテストケースに即したテストデータとJUnitコードを作成し、すべてのケースが正常に動作するまで繰り返し実施する。
（4）実施結果を設計者が確認して単体テスト完了とする。

■計画と実績

　上記のテスト方針を基に、われわれは第1反復を実施したのだが、反復の中盤あたりで次のような問題が発覚した。

• 設計者の説明不足などによってプログラマの仕様理解度が低く、テストデータの精度が低い
• ユースケースの粒度が大きく、1つの単体テストで対象となるモジュールが多いためにJUnitのテストコードが複雑化し、テストコード自体のデバッグに多くの工数をとられてしまう

　結局スケジュールの遅れなどからその問題に対処することもできず、多くの残業を行うことでなんとか第1反復を完了させることができたのだが、当然のことながら予想をはるかに上回る工数オーバーとなってしまったのである。

■プロセスの改善

　われわれは第1反復の失敗を繰り返さないためにも、第2反復に入る前にメンバー全員で問題となったタスクの洗い出しとその対応策を考えることにした。やはり一番の問題は単体テストの実施であったため、われわれは次のような内容でテスト方針の転換を行うことにしたのである。

（1）テストデータと予想データを設計者がExcelに作成する。
（2）テストデータのDBへの投入、実行結果と予想結果の比較（assert）、テストデータの削除といったような全ケース共通的な部分のJUnitコードを（1）のデータを基にマクロで自動生成する。

　テストデータを設計者が作成することによる工数増も懸念されたのだが、それ以上にテスト精度の向上とJUnitコードのデバッグ工数削減の効果があるだろうとの予想から、第2反復以降は上記の方針で実施することに決定した。

　その結果、見事にわれわれの単体テストに関する改善策が功を奏し、単体テストの工数が半分程度に減少、全体の工数も予定内に収まるまでに改善されたのである（図1）。

図1　予定工数を100とした場合、第1反復の工数は120、第2反復の工数は92程度であった

■反復型プロセスとPDSの関係

　実は今回筆者が読者の皆さんに伝えたいのは「単体テストの実施に関する提案」でも「テスト自動化の推進」でもない。注目していただきたいのは、その単体テスト改善に至るまでのプロセスである。近年RUPをはじめとする反復型の開発プロセスが注目を浴びている要因の1つは、「プロセス自体がPDS（Plan−Do−See）サイクルである」という部分ではないか、と筆者は考える。

　かつてほとんどのシステム開発プロジェクトで採用されていたウオーターフォール型プロセスでは、開発の見直しを行うというタスクを設定する場合、意識的かつ計画的にマイルストーンを設定しなければならず、開発作業が多忙になると、見直しという間接的なタスクはスケジュールから除外されてしまうことが多かった。

　一方、反復型プロセスでは、要件定義、設計、実装、テストが交互に繰り返されることによって、各反復の開始時には反復計画、製造終了時には反復の見直しを行うタスクをスケジュールに設けることが容易であり、このことからも一度策定した方針の再構築もウオーターフォール型プロセスに比べて楽である（図2）。

図2　反復型プロセスとPDS（Plan−Do−See）サイクル

　この計画・実施・見直しというタスクは、ビジネスにおけるPDSのサイクルと同じであり、ビジネスを遂行するという観点からも非常に合理的で強力であることが分かるだろう。

　今回、第1反復で発生した問題に対して短期間で対処できたことは、この反復型プロセスの特徴をうまく活用した結果であるといえるだろう。

■人間は反省して成長する生き物である

　「人間は反省する生き物であり、反省によって成長する。逆に反省しない人間は決して成長しない」と筆者は考える。開発のプロセスもまた同じである。失敗があるからこそ成功するための案が生まれる。そうして成長していくことによって品質の高いシステムも完成するのであろう。そのように考えると冒頭で書いた

システム開発におけるトラブルの発生は必然である

は、実は、

システム開発におけるトラブルの発生は必然であり“必要”である

となるのかもしれない。

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。