全3022文字
PR

アジャイル開発の要件定義では「ユーザーストーリー」を使って合意形成を進める。「誰が」「なぜ」「何をしたいのか」を書いた資料で、優れたそれには6つの特性がある。素早く的確に合意するにはウオーターフォール開発でつくる4つのドキュメントも使いたい。

 アジャイル開発の経験が少ない日本企業が組織や文化を大きく変革せずにSoR(System of Record)領域の業務システムのアジャイル開発を成功させるにはどうすればいいのか。そのポイントを解説する連載の5回目である。

 第3回と第4回では、アジャイル開発プロジェクトを立ち上げる準備段階における計画立案や体制構築の工夫について解説した。今回と次回では、チームを形成して実際に開発する開発工程における4つのポイントについて事例を交えながら解説する。

 具体的には「要件定義に使うドキュメント」「チームの裁量の確保の仕方」「進捗報告の方法」「初回リリースの範囲」である。このうち今回は1つ目を説明する。

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

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

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

表 優れたユーザーストーリーが備える6つの特性
「INVEST」で記述するよう心掛ける(出所:シグマクシス)
表 優れたユーザーストーリーが備える6つの特性
[画像のクリックで拡大表示]

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

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

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

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

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

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