（3）開発の効率化

（3）開発の効率化

チームが、より高い生産性で開発するためには、常に「より効率的に」という意識を持つことが大切です。

「技法とツールの使い方を、身に付ける」というのは、1つの方法です。以下では、効率良く仕事をこなすための技法である「テスト駆動開発（TDD）」と、筆者たちが行った「改善」について解説します。

TDDは、プログラマにとっては、開発のリズムを作る効果が高い開発手法です。第1回でも説明したように、TDDでは、実装を行う前に、自動化されたテスト、もしくは手順を明確化したテストを作成し、実装はそのテストをパスすることを目標に行います。 TDDがプログラマにとって効率的であることの背景には、「要件」を「コード」に落としこむ時に、いろいろなことを考える必要がある、という状況があります。

例えば、今回の業務システムでは、役割の異なる多くのアクターが存在しました。報告書を提出する対象のプロジェクトの状況などのいくつかの条件によって、操作内容や操作結果が異なりました。

そこで、「こういう前提があり、こういう処理を実行した時に、こういう動作をする」といったテストを書き、それを少しずつ継ぎ足しては、そのテストをパスするという過程の繰り返しを実践します。その時々、作成したテストをパスすることのみに集中して開発することは、範囲を限定して、常に小さな目標の達成だけを考えるので、実装が非常に容易になるのです。

業務フローのテスト・コードを記述する

筆者たちは、TDDを実践するためのツールとして当初、「RSpec」と呼ぶRuby用のテスト・フレームワークだけを使っていました。

しかし、RSpecでは、オブジェクトのふるまいに対するテストは記述できるものの、業務フローの粒度でテストを記述するのは、非常に大変です。

具体例を示すと、「業務担当者としてログインする、すると業務担当者用の一覧画面が表示され、そこで検索ボタンを押下して、」といった業務フローがありました。こうした複雑な業務フローの内容こそ、テストとして明確にゴールを記して開発していきたい内容でもありました。

そこで、筆者たちのチームは、RSpecのほかに「Cucumber」を導入することにしました。このツールを使うことで、上記のような一連の業務フローを、より容易かつ明確に、さらに自然言語を用いてテスト・ケースとして実装できるようになりました（図2）。

スロー・テスト問題への取り組み

次に問題となったのは、スロー・テストです。これは「テスト・コードが多すぎて、すべて実行するのに時間がかかる」という問題です。

私たちは、この問題に対し、「テストの整理」という対策で臨みました。モデルやバッチ処理において不安となるものだけをRSpecで詳細にテストし、ある程度はCucumberでカバーするようにし、また、一部のテストはコミット時に限って実行するといった設定にしました。

こうして、筆者たちは、TDDの実践方法を、プロジェクト内で改善していきました。

今回は、TDDだけに焦点を当てて解説しましたが、開発時においては、いろいろな形で効率化の向上に対する対策を実施しました。例えば、デプロイメント（配備）作業の自動化、複数のブランチを持っていても強力なマージ（合併）を実現するための分散バージョン管理システムの利用、など様々です。

こういった技術やツールは、ただ導入するだけではありません。何かの問題が起こった際には、今回説明したように、チーム内でその都度対応を考えて取り組みました。

（4）プロダクトの成長

変化が起こったのは、開発チーム内に限ったことではありません。プロダクトそのものも、当初の想定と比べて、大きく変わりました。

筆者は、2008年4月にプロジェクトに参画しました。もともとは、同年3月に要件定義が終了していた、という前提で参画しました。その当時の予定では、想定画面数も3画面ほどのシステムでした。

しかし、最終的には、24画面を持つ巨大なシステムになりました。

なぜ、このようなことになったのかを、以下で説明します。

業務確認テストを実施しての気付き

開発するにあたり、PM、開発チーム、ビジネス・オーナーの3者間で、定期的に仕様を確認する打ち合わせ（定例会）を開きました。この定例会では、デモを実施し当初想定していた要件に沿っているか動作を確認しながら実施していました。

ある程度、定例会を繰り返しつつ、業務を実行するうえで最低限必要な機能を実装した段階で、業務を実際に行う作業担当者を中心とした疑似的な業務確認テストを実施しました。

すると、当初想定以外に要望が大きく膨れ上がりました。実際に業務を行う作業担当者から、現状で使う上での問題の修正要望や追加機能の要望がたくさん発生したのです。

以降、仕様検討会は、以下のようなかたちになりました。

• 実際に業務を担当する人にも参加してもらう
• 要望の順位付けと、優先度の高い要望の確認をする

前者は、上記の失敗を踏まえた措置です。

後者は、膨れ上がった要望のうち、本当にプロジェクト期間内に必要なものだけを選択するための措置です。期間を超えたとしても、さらなるコストをかけて開発を続ける場合に限って、プロジェクトを延長するかどうかを判断してもらうという形にしたのです。

さて、ここまで読んだ方は、「アジャイルで開発するとプロジェクトは失敗する」と思うかも知れません。あくまでも私見ですが、語弊を恐れずに言えば、アジャイルでやると、確かに失敗します。

より正確に言えば、今回のように、「プロダクトに問題があった場合に、早く問題に気付く」というのが、アジャイルの本質だと思います。

仮に、「当初の想定通りの画面で、ビジネス・オーナーと要件を確認せずに開発を行って、リリースして、プロジェクトを終了した」とします。この場合、上記よりも短い期間で完成しますので、プロジェクトは成功とみなされていたかもしれません。

しかし、それは、エンドユーザーが喜んで使うシステムになったでしょうか。いいえ、ならなかったでしょう。使われないままのシステム、もしくは、使いにくいまま無理やり使うシステムになったのではないかと思います。

エンドユーザーを交えて、デモや、実際に動かすつもりでのテストを実施し、そこで得たフィードバックをもとにプロダクトを作り、改善していくこと。これは、非常に重要だと思います。