筆者の担当

4.6.2 要件の整理

イテレーションの一番初めには顧客を交えた顧客ミーティングを実施する．この顧客ミー ティングでは主に，このイテレーションで取り組む予定となっているユーザストーリについ ての再確認を行う．ユーザストーリを見直し，優先度や要件に変更が無いかなどについて顧 客と議論し，このイテレーションで取り組むユーザストーリを決定し，合意を形成する．

顧客ミーティングではユーザストーリを印刷したものを机に並べ，議論を行った．できる 限り顧客が発言しやすいミーティングを目指し，プレゼン形式ではなく，ワークショップ形 式にした．この顧客ミーティングにより，初期段階で抽出しきれなかった顧客要求やその変 化を捉え，より顧客にとって価値のあるシステムを開発する事を目指している．

開発フェーズにおける全5回のイテレーションの顧客ミーティングにより，ユーザストー リの増減や変化が生じた．各イテレーションの顧客ミーティングで決定されたユーザストー リの変更を表 4-8に示す．

イテレーション0は初期計画の直後であったため，特に変更が発生する事はなかった．イ テレーション1，2，4では当初のシステム要件から漏れていたユーザストーリの抽出や，開 発が進むにつれて不要と考えるようになったユーザストーリをスコープから除外する事に成 功している．イテレーション3では特に変更が発生しなかった．

表 4-8 顧客ミーティングにおけるユーザストーリの変更 イテレーション ユーザストーリ コ ア /

サブ

変更 種別

備考

イテレーション0 コーチは代行依頼のメール内 のリンクをクリックすること で代行への立候補ができる

サブ 変更 機能種別をサブか らコアに変更

管理者はHTTPベーシック認 証でコーチ評価ページにアク

セス出来る

サブ 変更 機能種別をサブか らコアに変更

イテレーション1 コーチは月カレンダから立候 補ができる

サブ 削除 －3USP

管理者は基本スケジュールの 変更開始日が設定できる

サブ 追加 ＋5USP

イテレーション2 管理者は基本スケジュールの 変更開始日が設定できる

サブ 変更 機能種別をサブか らコアに変更 管理者は解決されていない代

行依頼申請のリマインダを受 信できる

サブ 削除 －5USP

イテレーション3 ― ― ― ―

イテレーション4 コーチは代行依頼の一覧を閲 覧できる

サブ 変更 見積もり値が2USP から5USPに変更

＋3USP 管理者は任意のコーチの代わ

りにそのコーチとして操作が できる

サブ 削除 －5USP

管理者は月毎の各コーチ勤務 実績の割合を円グラフで見る ことが出来る

サブ 削除 －3USP

管理者はシステム上でログが 見ることができる

サブ 削除 －1USP

4.6.3 タスクの詳細化

顧客とイテレーションで取り組むユーザストーリの要件について整理をした後，開発メン バによるタスクの詳細化を行う．タスクの詳細化では各ユーザストーリの実現に向けて必要 なタスクの洗い出しの他，マネジメント，障害対応などについてのタスクも確認する．洗い だしたタスクには担当者の割り当てと期日，所要工数のボトムアップ見積りを行う．役割分 担は基本的に1つのユーザストーリには2人以上のメンバが関わるようにし，細かいレビュ ーが行き届くようにする．これらのタスクをもとにスケジュールを計画し，開発を行う．

4.6.4 開発

本プロジェクトではコロケーション^[5]を導入し，平日にコアタイムを設け，全メンバが同 じ居室に集まり，開発を行う．コロケーションとはチームとしての実行能力を高めるために，

チームメンバの大部分または全員を物理的に同じ場所に集めることである．一日の初めには 全員参加のデイリーミーティングを開催する．デイリーミーティングでは，各メンバが現在 取り組んでいるタスクについての進捗状況や困っている点について簡単に報告し，チーム全 体で共有する．また，その日に取り組むタスクを宣言することで，その日の共同作業を円滑 に行えるようにする．

4.6.5 成果物レビュー

成果物レビューでは，イテレーションの期間内で開発したユーザストーリを顧客にレビュ ーをして頂く．レビューは実際にシステムを稼働させる事で行う．また，単なるデモだけで なく，実際のユーザである経営者や事務員，コーチに実際にシステムを試用して頂き，細か いデザインや使い勝手，文字の表現などについての意見を頂く．実際のレビュー風景を図 4-5 に示す．

図 4-5 顧客ミーティングの風景（成果物レビュー）

4.6.6 振り返り

イテレーションの最終日に，開発メンバによるイテレーションの振り返りを行う．振り返

りにはKPT ^[19]を用い，開発フェーズにおけるイテレーションの活動をより良く改善を目指す．

KPT：Keep, Problem, Tryは行ってきた仕事や活動を振り返る際に，「継続」「問題点」「挑

戦」の3つの視点で整理するフレームワークのことである．振り返りのミーティングでは各 メンバが「K：今後も続けること」，「P：問題であること」，「T：今後，やるべきこと」の観 点で意見を出し合い，整理する．

振り返りを実施することにより，開発メンバが気づいた開発における改善点，問題点，リ スクなどを共有でき，開発フェーズの取り組みをより良く改善していく事ができる．実際に 作成し，居室に張り出していたKPTシートを次の図 4-6に示す．

図 4-6 振り返りで作成したKTPシート