基幹系システムもアジャイルで〜ユーザー主導による適用のためのポイント〜

２００１年2月の「アジャイルソフトウェア開発宣言」から9年の歳月が流れた。 日本でもようやく、アジャイル開発の事例が増え、盛り上がりを見せてきている。 しかし、いまだに、いわゆる基幹系システムでアジャイル開発を適用した事例は少ないと言わざるを得ない。 本稿では、アジャイル開発に関する特徴・効果を整理すると共に、筆者の経験を基にアジャイル開発を基幹系システム構築に適用していくためのポイントを紹介する。

アジャイル（agile）とは「俊敏な」「機敏な」という意味である。そしてアジャイル開発手法とは、従来の計画重視の開発とは異なる軽量かつシンプルな様々な開発手法の総称だ。具体的には、短期の開発を繰り返し、自律的なチームを運営していく手法で、コミュニケーションに重きを置いている（図1）。なお、繰り返す開発の1サイクルを「イテレーション」と呼ぶ。

図1　アジャイル開発の特徴と効果（画像をクリックで拡大）

アジャイル開発は、システム全体を対象に要件定義や設計、開発を進めていくウォーターフォール型の開発と対極にあると言える。その違いはプロジェクトの随所に現れる。

例えばウォーターフォール型では、ユーザーは要望した機能が実現されるかを要件定義の検収段階で確認する必要がある。このときシステム全体に関する膨大な要件定義書をレビューしなければならず、確認の負荷が非常に大きくなる。これに対してアジャイル開発では、一度に要求の確認を行う対象範囲はそれほど広くない。また、ある時点で誤りがあっても修正できる余地があるので、仕様確定の時間を短縮することにつながる。

以下では、アジャイル開発とウォーターフォール型の開発の違いを詳しく見ていく。そのうえでアジャイル開発の効果と現状を確認し、アジャイル開発を基幹系システムの構築に適用するためのポイントをまとめる。

後戻り、進ちょく、改善
3つの視点で見た特徴

アジャイル開発には多くの特徴があるが、ここではウォーターフォール型との違いを象徴する「後戻り」「進ちょく」「改善」という3つの視点で、アジャイル開発の特徴を見ていこう。

(1)後戻りを受け入れる

ウォーターフォール型は要件定義や設計、実装などの工程で漏れがないことを前提にしており、前工程の成果物に基づき精緻な計画を立案し、計画を順守するように管理していく。後戻りは計画の崩壊を意味するため、基本的に工程の後戻りは許さない（図2）。

図2　ウォーターフォール開発手法とアジャイル開発手法の比較（画像をクリックで拡大）

だが、アジャイル開発では「要求は変化するもの」として、変化を受け入れられるプロセスやアーキテクチャを用意する。実際に誤りに気付いたり、より良いやり方を発見した場合、フェーズを後戻りしても追加修正を実施する。

(2)システムが見えない期間が短い

ウォーターフォール型はシステム全体を対象にしているため、設計や開発などでユーザーにシステムが見えていない時間が長く、途中でビジネス環境の変化を仕様に取り込むのが困難。そのうえ進ちょくは開発ベンダーの報告に頼らざるを得ず、開発終盤にスケジュールの遅れが発覚するというのはよくある話だ。

ところがアジャイル開発は1回のイテレーションごとに開発したシステムが見える。環境の変化があっても、そのたびに耐え得る仕様かどうかを検証できる。加えて、動作するシステムを用いて機能の実現度合いを把握するので、正確な進ちょく管理が可能だ。

(3)継続的に改善できる

ウォーターフォール型は各工程を1度しか実施しないため、仕様の欠陥や進め方の誤りを改善しづらい。受入テストで仕様の欠陥が発覚しても、ユーザーがあきらめる、開発ベンダーに頑張らせる、期間延長とコスト超過を受け入れるなどの対処を採るしかない。

アジャイル開発は各イテレーション後に、ユーザーから仕様の誤りや追加に関するフィードバックを得られる。それらを次のイテレーションで取り込んでシステム改善できる。また、開発者がイテレーションにおけるプロセス改善案を検討することで、段階的に生産性を高められる。

ユーザー満足度の向上や無駄な機能の開発を一掃

アジャイル開発が脚光を浴びる背景には、ウォーターフォール型では享受しにくい効果を手に入れられるといった期待がある。何より大きいのは、ユーザー満足度が高いシステムを構築しやすい点だ。

前述の通り、アジャイル開発では実際に動くシステムを用いて機能の実現度合いを確認できる。ユーザーはシステムの専門家ではないため、仕様書から機能を把握するのは難しいが、システムを使えば必要な機能が整っているかどうかを明確に認識できる。不足があった場合にも改善点を具体的に伝えられる。結果としてユーザーの要求精度は高まり、満足度の高いシステムを構築することが可能になる。

無駄な作業を削れる。逆に言えば、本当に必要な機能の開発に集中できるといった効果もある。無駄排除の好例がドキュメントだ。ウォーターフォール型ではシステムを稼働させるまでに膨大な量の文書を作成するが、アジャイル開発ではユーザーの要望をシステムに実装するために最低限必要なドキュメント以外は文書化しない。

またアジャイル開発では、ユーザーからのフィードバックに応じて重要度の高い機能から手掛けるのが普通だ。ユーザーからの要求があっても重要度が低い機能は、最終的に構築対象外になることが多い。これは「使われない機能を作る」という無駄を省くことにつながる。筆者が携わった事例では、予算に対して3％程度少ない費用で済んだ。

さらに、保守段階での改善費用を抑えやすいという効果も期待できる。ユーザーの要望を反映しながら何度も改善を繰り返したプログラムは、往々にして変化に強い構造になっているからだ。ビジネス環境の変化に迅速に手を打てることは言うまでもない。

このほか、要求が固まった部分から開発・リリースできるのでシステム導入効果を早期に享受できる、設計やテストのプロセスを何度も繰り返すので開発チームの能力を高めやすい、といった効果も見込める。

短期間でのサービス開始や仕様変更が頻繁な分野で先行

ここ数年、アジャイル開発を用いたシステム開発事例は確実に増え続けている。その動向を俯瞰してみると、アジャイル開発を採用した事例には大きく2つの傾向があるようだ。

1つは、市場の存在を確かめなければならない事業に踏み出す際のシステム開発である。インターネット上のサービスのように、他社に先駆けて市場に参入することが成功の秘訣になるような分野では、要件定義に多くの時間をかけられない。そこで、軽量な開発言語を使い数週間でベータ版のサービスを開始。要望の反映や不具合の改善をしながら短期間でブラッシュアップしていく。

2つめは、搭載すべき仕様が市場環境によって刻々と変化するようなシステムの開発だ。頻繁に発生する仕様変更の管理や、コミュニケーションを容易にするようなツールを利用し、異なる拠点の開発チームが協調して仕様を拡充することで、開発期間の短縮や不具合の減少という面で効果が出ている。

このようにウォーターフォール型では実現が困難な分野で、アジャイル開発に挑戦する事例は多い。だが、基幹系システムでの事例となると、途端に少なくなる。最大の理由は、アジャイル開発に対する不安やためらいが根強く残っていることだ。現に、筆者はこれまでに、次のような声を聞いたことがある。

• 仕様変更を繰り返すとユーザーの好き勝手な仕様ばかり増え、システム化の目的があいまいにならないか。
• ドキュメントを書かずに開発して良いシステムを構築できるはずがない。
• 高いスキルを持つメンバーが大勢いれば可能かもしれないが、それではコストがかかる。
• 次々と変更要求が出てくることで作り直しが増え、開発が進まなくなる。

4つのポイントを押さえて基幹系にアジャイル開発を適用

これらの意見には誤解もあれば、適切な対策を講じることで回避できるものものある。以下では、基幹系にアジャイル開発を適用する上で欠かせない4つのポイントを整理する（図3）。

図3　アジャイル開発を成功させるにはポイントを押さえる必要がある

ポイント(1)：開発前にシステム化の目的を合意する

イテレーションを繰り返す前、システム企画段階で業務分析や課題把握、システム化施策の検討を実施し、ステークホルダー間で目的を合意しておく。特に、要求を取りまとめる立場にある利用者側のリーダーと目的を共有することは重要だ。使い勝手などユーザーから上がってくる細かな仕様変更が、システム化の目的から考えて適切かどうかを判断する際に役立つ。複数の部門に関係するような機能の仕様を確定する際の判断基準にもなる。

ポイント(2)：ドキュメントを作成して要求を可視化する

アジャイル開発ではドキュメントを一切記述しないというのは大きな誤解である。“無駄”なドキュメントを作らないだけで、開発に必要なドキュメントは必ず残す。ドキュメントで業務フローなどを可視化し、システム化の対象範囲をユーザーと合意するのは当然のことだ。

ドキュメントの作成にはモデルを利用する。短期間で繰り返すイテレーションの中で、ユーザーの要望を確認するのに費やせる時間に限りがあるだけでなく、自然言語ではあいまいさが残るからである。モデルを用いれば、後にデータモデルを作成する際の効率化も図れる。

ポイント(3)：PDCAを核にチームを適切に管理する

各イテレーションでPDCAのサイクルをキッチリと回す。PDCAは、ユーザー視点と開発チーム視点の両面で考える。前者についてはユーザーと一緒にPDCAを繰り返しながら、既存機能を改善するか、新機能を実装するかなどイテレーションごとのスコープを柔軟にコントロールしていく。後者に関しては、開発メンバーがイテレーション開始時にスケジュールなどの目標を設定し、終了するたびに反省点を見つけて次のイテレーションで改善する。こうすることで個々の開発メンバーのスキルが向上し、高いコストをかけなくてもパフォーマンスの良いチームを形成できる。

ポイント(4)：変化に強いアーキテクチャを整備する

短期間での開発や変更を可能にするため、共通アーキテクチャを整備する。実際には、高いスキルを持つメンバーにアーキテクチャの整備を担当させて、プロジェクトの土台を固める。こうすることで複雑な機能の品質を担保しやすくなる。

仕様の変更が想定される機能と、トランザクション制御のような基盤機能の実装担当者を分けるなど、体制面も工夫しておくとよい。個々のメンバーの担当範囲を狭めることで、品質を維持しやすくなるだけでなく、イテレーションごとの開発ボリュームを押さえられる。

アジャイル開発の特徴や活用時の基礎的なポイントを理解いただけただろうか。アジャイル開発で成果を上げるには、ユーザーの積極的な関与はもちろん、プロジェクト管理手法など多くの面で変更を余儀なくされる。しかし、「要件定義から先は開発者あるいはベンダー任せ」という従来のやり方では追随できないほどビジネス環境の変化が激しくなった今、アジャイル開発によって得られる効果を無視できないことも事実だ。

そこで今後は、アジャイル開発で難しいとされる契約問題も含め、実践に役立つ情報をIT LeadersのWebサイトで連載していく予定だ。アジャイル開発の経験者にも、そうでない方にも期待していただきたい。