PR

 一見簡単に思えるアジャイル開発は、ウォーターフォール型にない難しさがある。イテレーション、ドキュメント、コミュニケーション、マネジメントへの対策が必要だ。カギは現場のカスタマイズ。四つの失敗パターンに分けて、成功テクニックを探る。

 なぜうまくいかないのか──。NECソフトの安藤寿之氏(第二官庁ソリューション事業部 第三システムグループ 主任)は、プロジェクトマネジャー(PM)として初めて参加したアジャイル開発で、その難しさを痛感した。基本については情報収集してマスターしたつもりだった。だがイテレーション内に機能が完成しない、メンバーによって作業内容のブレも大きい、タスクをホワイトボードに張り出しても数が多すぎて管理しきれないなど、失敗の連続だった。安藤氏はハプニング続きに「なじみのあるウォーターフォール型に戻すことさえ考えた」。

 それでもアジャイルには、刻々と変わる要求に対応できる俊敏さや、現場のやる気向上といったメリットがある。これらのメリットを享受するには「後戻りはできない」と自分に言い聞かせた。安藤氏はその後も、メンバーと共に改善を続けながら、アジャイルの成功に向けて日々取り組んでいる。

失敗パターンは大きく四つ

 安藤氏の例は氷山の一角である。アジャイルを採用したものの、うまくいかない、工数がむしろ膨らんだというケースは珍しくない。手掛けるアジャイル開発が軌道に乗り始めたユー・エス・イーの大草健太郎氏(技術営業本部 SIアーキテクチャ推進グループ RIAソリューションユニット テクニカルマネージャ)は「最初はいろいろな苦労がある。教科書通りにやってもダメ。現場でカスタマイズすることが大切だと分かった」と打ち明ける。

図1●アジャイルで陥りがちな四つの失敗パターン
図1●アジャイルで陥りがちな四つの失敗パターン
納期やコストに制約のある業務システムの開発では、こうした失敗がさらに発生しやすくなる
[画像のクリックで拡大表示]

 実際、アジャイルではどんな問題に直面するのか。PART1の座談会や多くの取材から、陥りがちな失敗パターンは四つあることが分かった(図1)。

 一つ目は、イテレーション(反復)に関する失敗だ。短い周期で設計・実装・テストを繰り返すアジャイルでは、期間内になかなか機能が出来上がらない事態に直面しやすい。

 二つ目は、ドキュメントに関する失敗だ。ドキュメントよりも動くソフトウエアを優先するアジャイル開発。その特徴から、本来必要なドキュメントを作っていない問題が起こりやすい。

 メンバーやユーザーがうまく連携できない。これが三つ目のコミュニケーションに関する失敗。ユーザーの負担をどう解消するかが悩みどころだ。

 最後はマネジメントに関する失敗である。アジャイルでは各メンバーが水平型のチームを構成し、ボトムアップ的に行動する。納期やコストのマネジメントが利きにくい面がある。PMが作業の負荷や進捗をきちんと把握できない例は少なくない。

 そこで、これら四つの失敗パターンについて、現場における成功テクニックを紹介しよう。今回は、インターション編とドキュメント編をお届けする。

イテレーション編:要求定義は必須、機能配分に注意

 アジャイル開発では、短い周期で設計・実装・テストというイテレーションを繰り返す。イテレーションの最後には、動くソフトウエアとして何らかの機能をリリースする必要がある。

 ところが、イテレーションの最初に予定した機能が終了時になっても完成しないことが少なくない。その結果、次のイテレーションで取りこぼし分の機能が積み上がり、プロジェクトがどんどん苦しくなる。そして“終わりなきイテレーション”に突入する。

 原因は何か。現場の事例を見ると、大きく三つある。「何を作るかという要求がほとんど決まらないままイテレーションを始める」「作業の負荷を考えずに各イテレーションの機能配分を行う」「イテレーションの反省を次のイテレーションに生かせない」である。以下でその対策を紹介する。

アジャイルでも要求定義は必要

図2●要求を収束させるイテレーションの構成
図2●要求を収束させるイテレーションの構成
アジャイルでは、要求の見直しが収束せずに、なかなか機能が出来上がらないことがある。日立システムアンドサービスの英 繁雄氏は、まず事前に粗い要求を定義する。さらに、同一機能の要求を変更できるイテレーション回数を限定することで迅速な開発につなげている
[画像のクリックで拡大表示]

 「たとえアジャイルでも、複雑な業務システムの開発なら要求定義は欠かせない」。こう強調するのは、国内では珍しいアジャイルの社内標準プロセスを策定した日立システムアンドサービスの英 繁雄氏(プロジェクトマネジメント本部 生産技術部 シニアテクニカルアーキテクト)である。英氏らが策定した開発プロセスは図2のように、イテレーションに入る前に「要求定義」がある。英氏は「いきなりイテレーションに入っても何を作るかがなかなか決まらないうちに時間だけが過ぎる。最初にビジネス分析を行い、おおまかな要求の洗い出しや詳細化、優先順位付けを行う」と語る。

 ただし、ウォーターフォール型のような詳細な要求定義を行うわけではない。やみくもに時間を掛けないために英氏は「ここまで詳細化すれば完了という形ではなく、1カ月など時間を決めて後はイテレーションの中で詳細化する」という工夫をしている。

 このプロセスで特徴的なのは、3回のイテレーションをひとくくりにして「ステージ」という単位を設けていることだ。これは納期やコストに制約のある業務システム開発において、要求変更を一定期間内に収めるための対策といえる。ユーザーと合意の上、ユーザーレビューの結果を反映するのは原則としてステージ内のみ。要求変更に柔軟に対応するアジャイルの本質から離れるかもしれないが、「永遠に要求変更を受け付ける開発プロセスは、業務システムにはそぐわない」(英氏)。

 ステージ内では、1回目と2回目のイテレーションで発生した要求変更を、2回目と3回目で吸収する。3回目のイテレーションでは開発する機能を割り当てず、要求変更の対応に集中。ステージを越えた要求変更は原則として認めないルールだ。これで終わりなきイテレーションを阻止できるという。