システム企画におけるポイント

今回から開始するWeb連載では、「基幹系システムもアジャイルで〜ユーザー主導による適用のためのポイント〜」に引き続き、基幹系システムにおけるアジャイル開発のポイントについて、詳細に解説していく。連載第一回の本稿では、システム企画フェーズの重要性と、必要なアクティビティについて述べる。

アジャイル開発における開発の進め方の特徴には以下の点がある。

• 動作するシステムの提供を短期の開発期間（イテレーション）で繰り返し、ユーザーからのフィードバックを受け入れて、システムを成長させる
• システム全体を分割し、要件が固まったところから段階的に構築して全体を組み上げる
• 短期間なイテレーションの間に、「要求定義→設計→実装→テスト」といったソフトウェアの開発サイクルを回す

それぞれの進め方は適切に実施すれば効果があげられるが、基幹系のような規模の大きいシステムでいきなり開発に入ってしまうと、以下のような問題が発生しかねない。（図1）

• イテレーションごとにユーザーからフィードバックをもらうが、ユーザーの使い勝手の向上のための細かな改善要望が相次ぎ、改善がいつまでも終了しない
• 仕様が決まったところから構築していくため、システム全体としてどのような価値を提供するのかが明確でない
• イテレーション期間中に仕様に関してステークホルダーの調整に手間取り、イテレーション内で仕様が確定せず構築に入れない

上記のような問題を引き起こさないように、アジャイル開発手法を用いる際には、特にシステム企画工程で以下を実施することが重要になる。

• システム化の目的を明確にする
• ビジネス要求をシステム要求に紐付けする
• ステークホルダー間で合意を形成する

システム化の目的を明確にする

アジャイル開発手法では、繰り返し実施するイテレーションにおいて動作するシステムをユーザーに提供し、ユーザーが実際に使用することによって要求をブラッシュアップできる。文書上に記述した仕様ではわからなかった使用感の違いや、現実の業務を考えたときに必要となる情報の漏れなどを発見できる。ユーザーは受け入れテストで発見した不具合だけでなく、要求の誤りによる欠陥も含めて改善要望を出すことになる。

イテレーション計画の作成時には、改善要望に従った改修タスクと、まだ実装していない機能の開発タスクを天秤にかけ、各イテレーションでどのタスクを実施するかをユーザー側が決定する。その際に、各タスクの優先順位の判断基準を明確にしていないと、声が大きい部署からの要望が優先されたり、イテレーションの度に異なる基準でタスクを選択することになってしまう。改善要望に振り回され、開発が終了しないという結果を招くことにもなりかねない。

こうした状況に陥るのを防ぐためには、システム化の目的を明確にすることが必要である。システムがどのような価値を提供するかを、イテレーションを開始する前に検討する。現在の業務を分析して課題を発見し、何を改革するべきか、あるべき業務の姿はどのようなものか、などを検討する。そこから抽出したビジネス要求をシステム化の目的とする。

システムに関する要求は本来、ビジネス要求やユーザー要求から段階的に生み出されていくものである（図2）。目的としてのビジネス要求が掲げられていれば、それを判断基準にできる。ユーザーからの改善要望を実施するかどうかに関しては、ビジネス要求とどれだけ結び付けられるかといった事項を最優先にして、ユーザー側と交渉することも必要だ。

システム化対象の機能を抽出する

ウォーターフォール型のプロセスでは、開発対象の領域に対するすべての要件定義が終了するまで、次の工程を始めない。対照的にアジャイル開発では、システム全体を分割したうえで、要件が確定したところから設計・実装・テストを開始していくという特徴がある。各イテレーションの終了後には、そのイテレーションで開発対象となった機能について、ユーザーへのリリースや本番運用までを実施することがある。

段階的に機能を構築してリリースしていくと、システム全体としての効果が測定できないのではないか、という批判もある。確かにイテレーションごとに細切れになった要求仕様だけを頼りに開発を進めてしまうと、全体像を見失うことにもなりかねない。

こうした問題は、システム企画の段階で検討しておくことで回避できる。イテレーションでの開発に入る前に、システムの目的として検討したビジネス要求からブレークダウンする形でユーザー要求、システム要求を抽出する。特にビジネス要求を満たすために必要な業務の設計と、システムに関する要求の検討を並行させ、互いにフィードバックを加えるように進める。ビジネス要求をどのようにシステムによって満たすのかが明確になり、またシステム要求からビジネス要求へのトレーサビリティも確保できる（図3）。

ここで定義したシステム要求を軸にして機能を抽出し、イテレーションでの開発に入っていけば、対象となる機能の詳細な要件は個別に検討していても、全体としてどのようなビジネス要求につながっていくのかを把握できる。

ステークホルダーでシステム化の目的・効果を共有する

特に基幹系システムにおいては、業務が複数の部署にまたがることが多い。そのため、個々の部署・部門の利益だけを追い求めると部分最適に陥り、全体としては効率が悪い。

一方、全体最適を追い求めれば、個々の部署では負担が増える場合もある。例えば、システム上で今よりも細かく情報を管理しようと思えば、システムに情報を登録するという業務が新たに発生する。仕様決定の代表者は、自部署の都合だけを考えればこうした仕様を許可しない可能性がある。ステークホルダー間の調整の手間などが入ると、短いイテレーションの中で仕様を確定することが困難になり、最悪の場合、仕様決定待ちで実装できないという状態に陥ってしまうからだ。

こうした事態を避けるには、一部のユーザーやシステム部門のみがシステム化の目的や効果を把握するのではなく、プロジェクトのステークホルダー全体で共有することが望ましい。目的や効果を検討する際には、一部の部署だけではなく、ステークホルダーの代表者も参加して議論する。全社的な視点で、あるべき業務やそれを支えるシステムに必要な機能を検討するのだ。参加者には各部門の代表という意識だけでなく、業務改革検討メンバーであるという視点からの議論を促す。

目先のシステム仕様の問題を取り扱う前に、このような俯瞰的な見方から合意を形成しておけば、その後のシステム仕様の検討においても同一の前提から検討可能になる。当初は意識の統一に時間がかかるかもしれないが、システム開発前に統一しておくことの効果は非常に高い。

以上の内容で、システム企画フェーズの重要性が理解頂けたと思う。もちろん、ウォーターフォール型のような計画主導の開発手法を採用した場合においても、ビジネス要求とシステム要求の結び付けなど、本稿で述べたプロセスが重要となることに変わりはない。しかし、変化に適応して柔軟に開発を進められるアジャイル開発手法のような開発手法こそ、しっかりとした目的やチームの合意形成が重要な意味を持つと言える。