/

[覆面座談会]現場ではケンカが頻発

「アジャイル」成功・失敗の分岐点(1)

 いま、企業のシステム開発プロジェクトでは、「アジャイル」[注1]方式の採用が本格化しています。Webアプリケーションなどスピード重視の開発案件が増えたからです。アジャイルは、開発途中での仕様変更などに柔軟かつ迅速に対応することを重視したやり方の総称です。一方、事前に仕様を詳細なレベルまで詰めておく、プロセス重視・手続き重視の従来方式を「ウォーターフォール」[注2]と呼びます。アジャイル開発は、ウォーターフォール開発よりも簡単そうに見えますが、安易に取り組めば失敗します。本連載の第1回では、アジャイル開発の経験が豊富な3人に、現場の様子を語ってもらいました。(聞き手は、池上俊也=日経SYSTEMS)

日経SYSTEMS(以下、日経):最近、業務システムの開発にアジャイルを適用する事例が増えてきました。アジャイル開発の経験が豊富な皆さんは、こうした状況をどのようにご覧になりますか。

Aさん:以前は若い開発者が中心となって、Webシステムの開発でアジャイルを採用するケースが多かったと思います。しかし最近は、ちょっと違う。開発会社のトップや、ユーザー企業の担当者がアジャイル開発の採用を求め、トップダウン的に取り組むケースが多いようです。それもこれまでウォーターフォール型を適用していた業務システムのプロジェクトに適用する事例が目立ちます。

Bさん:より速く、より安くシステムを開発する手法として、アジャイルが広く認知された結果でしょう。私がびっくりしたのは、最近見たRFP(提案依頼書)[注3]の中に「開発はアジャイルで」と書かれていたことです。これはアジャイルが確実に広がっている表れだと思います。プロジェクトマネジャー(PM)にも、アジャイル開発の経験が求められるようになってきました。

日経:ユーザーや上司から「アジャイルで開発せよ」と要求する傾向が強くなってくると、開発現場としては取り組まざるを得ないですね。

Cさん:そうだと思いますよ。ユーザー企業の中では、自分たちのビジネスを、スピード感を持って変えたいというニーズが強い。そこで「俊敏」や「機敏」と呼ばれるアジャイルに目を付けた。うちの会社でもアジャイルを適用した開発事例が増えています。アジャイルはもはや一部のエンジニアだけのものではないように思います。

「俊敏」「機敏」の道は険しく

日経:アジャイルの適用が進む一方で、その難しさから失敗するプロジェクトも多いと聞きます。実際、現場ではどんな失敗があるのでしょうか。

[注1]システム(ソフトウエア)開発手法の一つ。アジャイルは「俊敏な」という意味。開発途中での仕様変更や機能追加などに臨機応変に対処すべく、システム開発とユーザーレビューを短い期間で繰り返しながらシステム全体を構築する。代表的なアジャイル開発手法は「エクストリーム・プログラミング」と「スクラム」
[注2]システム(ソフトウエア)開発手法の一つ。分析工程→設計工程→プログラミング工程→テスト工程、という順序で作業を進め、各工程での作業を完結させてから次の工程に進む。上流工程から下流工程へ滝が流れるように進むので「ウォーターフォール(滝)」の名が付いた
[注3]request for proposalの略語。ユーザー企業が、ハードウエアやソフトウエア、あるいはサービスを購入しようとする際に、各種の購入要件をまとめてベンダーに知らせるための文書を指す

Aさん:よくあるのは、モノがなかなか出来上がらない、あるいは何度も何度も必要以上にイテレーション(反復)[注4]を繰り返すプロジェクトです。ある現場では、いきなりイテレーションを始めて失敗する例がありました。本に書いてあるように、要求仕様を書いた付せん紙をホワイトボードにペタペタ張っていったのですが、その後要求がなかなか煮詰まらない。そうして時間だけが過ぎていったようです。

日経:なぜイテレーション内で機能が完成しないのですか。

Aさん:2週間や1カ月という短い期間で設計・開発・テストをする難しさはあります。しかし根本的には、要求に対する意識が甘かったようです。もちろんウォーターフォール型のように詳細に要求を定義する必要はありません。ただ業務システム開発の場合、アジャイルでもビジネス分析や要求定義が必要です。要求の洗い出しや優先順位付け、要求同士の関係の確認などを怠った結果、失敗したのでしょう。

日経:イテレーションに伴う失敗は、結構あるのですね。

Bさん:そうです。イテレーションの終了時に、ユーザーと開発側の間でトラブルになったケースがありました。開発現場では初めてのアジャイルで慣れるまで時間が掛かり、最初のイテレーションで予定通りの機能が間に合わなかったようです。それを見たユーザーが「約束と違う」と激怒。出来上がらなかった機能は次のイテレーションに回せばよいのですが、まずかったのは次のイテレーションでもほとんど出来上がらなかったこと。設計作業に戸惑ったようです。

日経:そしてまたユーザーが激怒。

Bさん:はい。アジャイルにはテスト駆動や常時結合[注5]などさまざまな技法があり、これを習得するのに時間が掛かります。初めてアジャイルに取り組むメンバーが多いときには、習熟の時間を考慮しないと、全く機能が出来上がらない状況が普通に起こります。

Cさん:俊敏や機敏といったメリットを得る道のりは険しいものです。

[注4]代表的なアジャイル開発手法の一つである「エクストリーム・プログラミング」で使う用語。開発プロジェクトをスタートさせるときに、イテレーション(反復)の期間を例えば「2週間」と決めて、2週間ごとに成果物(任意の機能を持つプログラム)を得られるようにプロジェクト全体を計画し、推進していく
[注5]任意のソフトウエアを開発する際、それを構成するソースコードを書き上げる度に、ビルド(ソースコードをコンピューターが実行可能なファイルに変換)とその動作検証を行い、ビルド管理ツールなどに登録して結合するやり方を指す

ドキュメントは作る? 作らない?

日経:アジャイルの特徴の一つに、ドキュメントよりも動くソフトウエアを優先するという原則があります。しかし業務システムではドキュメントを重視する傾向があり、問題が起きているようです。いかがでしょうか。

Cさん:ドキュメントをとにかく作れという品質保証部門と、アジャイルだからドキュメントは必要ないと主張する開発側の対立はよくある光景です。

Aさん:そもそもアジャイルでドキュメントがいらないと誤解する開発者が多いのではないでしょうか。確かに欧米では、ドキュメントを全く作らない事例がある。ただしこれは、長年自社のシステムを担当してきた熟練エンジニアがそろっていて、ソースコードを読めばドキュメントの代わりになるからです。日本の場合はそうはいかない。基本的にアジャイルでも、ドキュメントの作成は必要です。

Bさん:それでもウォーターフォール型のようにあれこれ作るのはストレスのもとですよね。アジャイルの場合、ユーザー側はドキュメントと動くソフトウエアの両方をレビューしなければならないので負担が大きくなります。あるプロジェクトで、ユーザーが「ドキュメントがあるからそれに従って作ればいい」と、あまりの多さにソフトウエアのレビューを断るケースがありました。これでは結局、ウォーターフォール型に逆戻りです。

Cさん:だからこそ、どのドキュメントを作成し、どのドキュメントを削るか、またどのドキュメントを運用後に作成するかなどをきちんと見極めないとプロジェクトが混乱します。「とにかく作れ」という品質保証部門のプレッシャーにも勝たなければいけない。

設計者とプログラマの意見が対立

日経:アジャイルでは緊密なコミュニケーションが求められますが、この不備による失敗はありますか。

Aさん:アジャイルの現場ではしょっちゅうケンカが起きてますよ(笑)。

日経:具体的にはどんな?

Aさん:2人で1台のマシンを共有して作業を進めるペアプログラミングはその代表でしょう。お互いが批判を繰り返してケンカになるケースがよくあります。スキルの差があまりない場合は特に注意が必要ですね。

日経:こうした衝突は以前からよくあったのですか。

Aさん:いえ、アジャイルが登場した当初は、気心が知れた仲間同士で行うので特に問題になりませんでした。それが最近目立つのは、全く知らない人同士がペアになるケース。それも専門分化が進む業務システム開発では、設計者とプログラマがペアを組むこともあります。プログラミングの知識が乏しい設計者と、設計の知識が乏しいプログラマが意見を交わすので、どうしても衝突が起きやすくなります。

Cさん:その上、業務システム開発の場合、ステークホルダー(利害関係者)がやたらと増えるのでコミュニケーションがさらに難しくなる。とりわけ難しいのは、ユーザーをどう巻き込むかです。この点はアジャイル開発の成否のカギを握っているといえます。

Aさん:そう、プロジェクトが大きくなると、チーム間のコミュニケーションも必要となるので、PMの力量が問われますよね。

PMが開発現場で右往左往

日経:プロジェクトマネジメントの難しさは高まるわけですか。

Bさん:はい。PMが上司の私に泣きついてきた例がありました。現場は何だか楽しそうに仕事をしているものの、一向にプログラムを確認できない。現場のメンバーが何を作業しているのか今ひとつつかめないというのです。メンバーに聞いても問題ないのひと言。ガントチャート[注6]やWBS[注7]といった管理ツールがないので、うまく進んでいるのか判断できなかったようです。

日経:実際はどうだったんですか。

Bさん:ちゃんと作業は進んでいました。ただそれを把握する手立てがなかった。結果的に進捗遅れは起こりませんでしたが、現場で右往左往しているPMは、その役割を果たしているとはいえないでしょう。

日経:マネジメントの点では、ツールの活用もカギになるのですね。

Aさん:ツールありきではダメですが、ツールを使うとアジャイルの生産性は一気に高まります。具体的には、タスク管理ツールやビルド管理ツール[注8]、自動テストツールなどが有効です。

根深い「契約」の問題

日経:ところで、根深い問題だと思いますが、契約についてトラブルになることはありませんか。

Aさん:もめることはありますね。アジャイル開発を一番難しくするのが契約だと思います。アジャイルの基本は実績精算です。つまり、掛かった時間と人員に対してコストが発生する、というものです。ところが国内のシステム開発は、ほとんどが一式いくらという請負契約です。これでは要求仕様が大幅に膨らむ可能性があるアジャイルでは大きな障壁となります。

[注6]プロジェクトのスケジュールを管理・表現するための図。「線表」「バー・チャート」とも呼ぶ。横軸が時間、縦には作業項目が並べられる。各作業の開始、終了日付の間を塗りつぶし、横棒の形状にする
[注7]work breakdown structureの略語。プロジェクトマネジメントにおいて、計画を立てる際に用いられる手法の1つ。プロジェクト全体を、それを構成する細かい作業に分割し、図で表す
[注8]人が書いたソースコードをコンピューターが実行可能な機械語に変換して実行ファイルを作ったり(この作業を「コンパイル」と呼ぶ)、複数の実行ファイルを結びつけて任意のアプリケーションを生成したりするなどの作業をまとめて「ビルド」と呼ぶ

Bさん:この障壁が発生しない、ユーザー企業における内製プロジェクトや、ベンダーのパッケージソフト開発では、アジャイルがマッチしやすい。

Aさん:アジャイルの発祥の地である米国の企業では、システム開発の内製が多いので問題がないのです。

Cさん:アジャイル開発では見積もり時のトラブルもつきものですね。さまざまなリスクをイテレーションによって解消する手法なのに、見積もりにリスクを積んでしまうケースです。こうなると、ウォーターフォール型よりもコストが高くなり、ユーザーにとってのメリットが失われてしまいます。

Bさん:そう、慣れていないからリスクを積むという悪循環ですよ。

Aさん:結局、ユーザーが実績精算でいいと納得すればトラブルは起きないのですが、それも難しい。請負契約でアジャイル開発を実践する場合は、いろいろな対策が必要になるでしょう。

動くチョウを捕まえる

日経:そこまでしてもアジャイルに取り組むメリットは大きいのですか。

Aさん:もちろんすべてに適用する必要はありません。例えば官公庁の入札管理システムなど要件がきっちり固まるプロジェクトなら、無理にアジャイルを適用する必要はない。ただし、いずれウォーターフォール型で適用可能なプロジェクトはオフショア開発にシフトしていきます。開発現場の競争力として、アジャイル開発は欠かせない要素になるといえるでしょう。

Cさん:現在の開発プロジェクトは"動くチョウ"を捕まえるようなものです。これまではチョウは止まっていたので、右に5歩、前に10歩進んで手を伸ばす、という手順を定義できました。動くチョウの場合、ちょっと進んでチョウの位置を確認し、どこに進むのかを見直す。捕まえ方にもコツが必要。これがまさにアジャイルです。さまざまな技法をマスターする必要があるので、当然ウォーターフォール型よりも難しい。

Aさん:とはいえ、天才プログラマである必要はありません。私の経験から言うと、基本をちゃんとマスターすれば、ほとんどの開発現場でアジャイルを成功させることができます。

Bさん:ただし、本に書いてある通りにやってもうまくいかないことがあるので注意が必要ですよ。現場で実践して改善していく。それがアジャイルの本質ですから。

◇  ◇  ◇

従来のウォーターフォール型開発にはない、アジャイル開発の難しさは、「イテレーション」「ドキュメント」「コミュニケーション」「マネジメント」への対策である。次回(本連載の第2回)から4回に分けて、開発プロジェクトを成功に導く実践的なテクニックを紹介していこう。

(日経SYSTEMS 池上俊也)

[日経SYSTEMS2010年9月号の記事を基に再構成]

すべての記事が読み放題
有料会員が初回1カ月無料

セレクション

新着

注目

ビジネス

ライフスタイル

新着

注目

ビジネス

ライフスタイル

新着

注目

ビジネス

ライフスタイル

フォローする
有料会員の方のみご利用になれます。気になる連載・コラム・キーワードをフォローすると、「Myニュース」でまとめよみができます。
新規会員登録ログイン
記事を保存する
有料会員の方のみご利用になれます。保存した記事はスマホやタブレットでもご覧いただけます。
新規会員登録ログイン
Think! の投稿を読む
記事と併せて、エキスパート(専門家)のひとこと解説や分析を読むことができます。会員の方のみご利用になれます。
新規会員登録 (無料)ログイン
図表を保存する
有料会員の方のみご利用になれます。保存した図表はスマホやタブレットでもご覧いただけます。
新規会員登録ログイン