要件定義工程のアジャイル開発の進め方
では、業務システムの要件定義工程にアジャイルをどう適用するか考えてみましょう。ところで業務システムの要件定義のアウトプットは何でしょうか。Webアプリケーションの開発では、まず画面遷移図（サイトマップ／サイトストラクチャー）を作成することが優先されますが、業務システムの場合は業務フローです。業務システムは、企業の複数の部門にまたがって業務処理がされてゆく動脈であり神経なので、全体の流れ、部門の役割分担、承認や内部牽制などがどうあるべきかを業務フローで表すことが重要なのです。
図3は、パッケージベースの業務システム開発における要件定義の作業工程です。キックオフミーティングで作業のスケジュールや内容、体制、成果物などを確認し合った後、いきなりパッケージをインストールします。そして、既存システムのデータや伝票を参考にしながらマスタデータ（取引先や商品など）を入れ込むところがアジャイル的手法です。
こうして準備した後で、いろいろな現場の方に業務のヒアリングやディスカッションを行います。その際、既存の伝票などを参考にトランザクションデータ（受注や発注など）を入れ、画面のイメージを持ってもらいながら意見や要望を引き出します。複雑な処理や全体にかかわる考え方については必要に応じて機能概要説明書にまとめてユーザーとの共有を確認します。
そして新しい業務フローを作成しつつ、双方の検討課題を課題リストにまとめ、出てきた要望をカスタマイズ一覧にリストアップします。そして優先順位の高いものをカスタマイズ範囲と決定し新業務フローと一緒に承認を得ます。
基本設計工程以降のアジャイル開発の進め方（1）
ところでウォーターフォール開発における基本設計と詳細設計の違いを知っていますか。会社によって多少異なりますが、一般に基本設計書は「お客様に仕様を理解してもらうもの」、詳細設計書は「プログラマーがそれを見て作れるもの」であり、対象となる「読者」が異なります。その用途に沿って、基本設計書は画面や帳票のイメージやそこに表示される項目の説明が主体ですが、詳細設計書はそれに加えてイベント発生時の処理内容やエラー処理など細かな処理まで記述されることになります。
パッケージベースの業務システムではこの2つを区別せず、すぐに設計＞開発＞単体テストという一連のイテレーション開発に持ち込むことができます。要件定義でカスタマイズ範囲を確認したら、後はイテレーション（スプリント）の計画を立てて、カスタマイズ対象の優先度の高いものから順次開発作業に入ります。その際、簡単なものであれば「設計書」などを作成せず、既存画面のハードコピーに赤書きしたもので開発指示をすることも可能です。業務システムの場合は、設計書をきちんと残す必要がありますが、その作成は後回しにします。ただし、この簡単な指示書もきちんとファイリングして取っておきます。後から設計書を作成する際にこの指示の束を確認することで記載漏れを防止できるからです。
完成後にドキュメントを作成するという方式は、ウォーターフォールに慣れている人からは邪道と思われますが、設計書の変更が少ない、画面イメージをそのまま利用できる、不要な記述で分厚くならないなどのメリットもあり、ドキュメント作成コストの低減につながります。
基本設計工程以降のアジャイル開発の進め方（2）
パッケージベースの開発と言っても、既存機能の手直しではなくサブシステムまるごとが新規開発だという場合もあります。その部分だけウォーターフォールでやるというのもハイブリッドの1つの方法ですが、当社ではイテレーションを前後半に分ける工夫でアジャイルを適用しています。
通常のイテレーションでは、期間内に完成できる機能範囲を決めて開発を行います。ここで言う完成とは、機能の設計＞開発＞単体テストまでの一連の作業であり、レビューによる変更は次のイテレーションに持ち越されます。こうして優先順位の高いものから順次作成して最後に全機能が完成します。各イテレーションの最後にお客様とのレビューが行われるのですが、そこで確認した内容（これはOK、これはこう変更したい）が仕様のFIXとなり、いつまでも変更が続くことの歯止めとなります。
業務システムは規模が大きい上にシステム全体にかかわる機能要件が多いため、新規開発でこの方式を取るとイテレーションで完成したつもりの機能に対する変更が後からどんどん出てきます。ウォーターフォール方式で設計工程を基本設計と詳細設計に分けているのは、こうした変更を避けるためのものなのです。
そこで当社は図4のように作成作業を前半（イテ1）と後半（イテ2）に分けています。最初に画面デザインや画面遷移までの部分をイテ1として全機能分を作成して全体のイメージや整合性を確認します。そこでOKとなった後で、完成までの残りの作業をイテ2として実施するという2段構え方式です。イテ1がウォーターフォールによる基本設計に相当し、イテ2で詳細設計から単体テスト完まで行うという感じです。イテ1に相当するイメージ確認作業を画面モックで行う方式もよく使われていますが、モック作成の手間が余分にかかります。この方式は、そのままイテ2につなげられるようにしているところが一歩踏み込んだアジャイル方式と言えます。
下流工程はウォーターフォール
なお、単体テスト以降、すなわち結合テストや運用テスト、総合テストなどの工程はアジャイル開発手法の適用外になるでしょう。結合テストでしっかり品質確認したうえで運用テストや総合テストに移行するというウォーターフォールの考え方が適していると思います。
おわりに
今回は、業務システムの開発においてアジャイルをどのようにハイブリッド適用するかについて説明しました。特に、これまであまり語られてこなかったパッケージ適用をベースにした上流工程の作業内容をモデルにしているので、そのまま皆さんの仕事に役立てることができると思います。まだまだ業務システムの請負契約でアジャイルを適用している例は少ないですが、今回紹介した一歩踏み込んだアジャイル開発のハイブリッド適用をぜひ実践してみてください。
今月の復習問題
以下の問題文を読んで正しいものに○、間違っているものに×を付けてください。
- 問題1：ウォーターフォール手法のV字モデルを描いた場合、アジャイル開発に置き換えやすいのはV字の上側である。
- 問題2：パッケージをカスタマイズする開発プロジェクトは、パッケージという枠が決められてしまうのでアジャイルに向かない。
- 問題3：アジャイル開発と言えども、プログラミングをしてから設計書を作るという逆の流れの作業はやってはならない。
復習問題の答え
- 問題1：×
- 問題2：×
- 問題3：×
プログラミング工程を中心とし、前工程の設計、後工程のテストを合わせてアジャイル開発するのがやりやすい。
既にユーザーに見せられる画面や帳票があるので、アジャイル開発がやりやすい。
成果物として設計書を作る必要があるなら後追いで設計書を作る場合もある。
アイスコーヒーにラムを入れてかき混ぜる（ステア）するだけの簡単なカクテルです。家にラムだけあって割るモノ（ミキサー）がない時、ラムだけ飲むのも海賊みたいだしなぁってときの切り札となる一品です。
先日、久しぶりにロング・アイランド・アイスティを飲みました。レシピも相当複雑なんですが、紅茶は入っていないのにアイスティの味がするという不思議な一品です。一方、ブラック・ローズはまったく対照的に超シンプルな一品です。アイスコーヒーを使っているのにアイスコーヒーの味が･･･。やっぱりします･･･。
