全6005文字

 アジャイル開発の経験が少なく、中央集権型の日本企業において、組織や文化を変革せずこれまで通りに開発ベンダーを活用しながら、SoR(System of Record)領域の業務システムのアジャイル開発を成功させるにはどうすればいいのか。そのポイントを解説する特集の3回目である。

 前回(第2回)は、アジャイル開発プロジェクトを立ち上げる準備段階における計画立案や体制構築の工夫について解説した。今回は、チームを形成して実際に開発する開発工程における4つのポイントについて事例を交えながら解説する。具体的には「要件定義に使うドキュメント」「チームの裁量の確保の仕方」「進捗報告の方法」「初回リリースの範囲」である。

ポイント1:ユーザーストーリーだけに頼らない

 1つ目のポイントが「要件定義に使うドキュメント」である。ステークホルダー(本稿では特にシステム開発の予算を持つ人、システムの仕様を決める人、システムを使う人などを指す)との合意形成における工夫だ。

 アジャイル開発における要件定義では、「役割(誰が)」「要望(何をしたい)」「理由(なぜ)」の要素で構成される「ユーザーストーリー」を使ってプロダクトオーナー(PO)や開発者がステークホルダーと合意形成する手法がメジャーである。一般に優れたユーザーストーリーの特性は頭文字をとって「INVEST」とされる。

表 優れたユーザーストーリーが備える6つの特性
「INVEST」で記述するよう心がける(出所:シグマクシス)
項目説明
Independent:独立している先行するストーリーが完了してないと始められないなど、他の影響を受けない
Negotiable:交渉可能であるストーリーが具体的過ぎないタスクで記述されており、プロダクトオーナーと実現方法について交渉できる
Valuable:価値があるストーリー単独で顧客にとっての価値がある
Estimable:見積もり可能であるストーリーを実現するのに必要な時間が(他ストーリーとの比較において)見積もれるだけの十分な情報がある
Sized Right(Small):適切な大きさである(小さい)開発するに当たり、ストーリーを実現するのに必要な時間が長過ぎない程度に、適切なサイズに分割されている
Testable:テスト可能であるそのストーリーが完了したかどうかをテストでき、受け入れ条件が明確になっている

 ユーザーストーリーはユーザーの「価値」に注目し、優先順位を付けてステークホルダーと合意するためには適している半面、既に稼働中のSoR領域の社内システムを刷新するプロジェクトでは要件が抜け落ちるケースがあることに注意が必要だ。

 要件が抜け落ちる要因は大きく2つある。

 第1の要因はユーザーストーリーそのものの質が悪い場合だ。既存社内システムの刷新プロジェクトでは、INVESTのうち特に「Negotiable:交渉可能である」に着目したい。

 と言うのも、既存社内システムを刷新する場合、ユーザーは欲しい機能が具体的に決まっていたり、既存の機能に目が行ってしまったりして、ユーザーストーリーに機能の詳細を書いてしまいがちだからだ。例えば「複数の項目を選択したい」という要求を「チェックボックスで選択したい」と具体的な機能で記載してしまう。結果、Negotiableでなく(交渉の余地がなく)、ユーザーのリクエストをそのままの形で反映するといったことが起こる。

 ある消費財メーカーの実例を紹介しよう。この会社では商品企画に関する業務を全て紙文書で進めていたが、担当者ごとにフォーマットや情報の管理方法が異なり、採番ルールなども十分にマニュアル化されていなかったため、業務の煩雑さが課題となっていた。

 そこで、業務を簡略にし、社員の負荷を減らし、事業継続性を高めるという目的の下、新システムを導入するに至った。実際に要件定義に入ると、ユーザーは過去の企画や各種ルールを一元管理できるシステムを早期に実現しようという思いが強く、ユーザーストーリーに本来書くべき「要望」「理由」ではなく、ユーザーが考える「具体的な実装方法」ばかりを盛り込んでしまった。

 ユーザーレビューでの指摘も機能の実装方法に注目が集まり、そのストーリーで実現したい業務の目的や内容については深く議論されることはなかった。このまま開発工程に突入したところ、開発者が目的を理解しないままユーザーストーリーに記載された機能をそのまま実装したため、ユーザーにとって使い勝手が悪い複雑な操作画面となってしまい、最終的に完成したシステムはユーザーが満足する品質には届かなかった。

 第2の要因は、一連の業務を遂行するためのユーザーストーリーが不足している場合だ。ユーザーストーリーは1つの部門の業務を明確にする用途には適しているが、複数部門をまたがるような横串の業務を漏れなく書こうとする場合は注意したい。特に、先述の機能目線で記載されたユーザーストーリーは、個々の機能の仕様は明確になるものの、システムの全体像やストーリー間の結びつきが曖昧になり、そこに要件の抜けが潜みやすい。

 例えばある顧客が倒産した場合を考えてみよう。最初に営業部門が「倒産情報」を登録し、与信部門がその真偽を確認・確定し、最後に出荷部門が該当顧客への出荷を保留する。この一連の流れで与信部門のユーザーストーリーから「倒産情報を確認・確定する」という作業が漏れてしまうと、「倒産先への出荷を保留する」という複数部門が関わる一連の業務が成り立たなくなってしまう。

 先ほど紹介した消費財メーカーのプロジェクトでも、開発者が個々の要件や機能にのみ着目してユーザーストーリーを作成したため、ユーザーストーリー間の要件の抜け、テーブルの漏れ、画面仕様イメージのずれが発生した。このプロジェクトでは上記2つの要因が重なり、イテレーションごとに実施するレビューでの指摘が多くなり、プロジェクト中盤からは新規のバックログ(優先順位付けされたユーザーの要求一覧)に着手できなくなってしまった。

 これらの問題は全て、ステークホルダーであるユーザーの目的や要件が、開発者に十分に伝わっていないことが原因だ。ユーザーの要望が漏れなくユーザーストーリーへ反映されない限り、アジャイル開発は成功しないわけだ。

 では、「十分な情報」を得るにはどうすればいいのか。一般には、ユーザーストーリーそのものの品質を向上させたり、ユーザーストーリーを業務プロセスやカスタマージャーニーで並べる「ユーザー・ストーリー・マッピング」を使って抜け漏れを確認したりする方法がある。