プロダクトオーナーが押さえるべき「要求開発」の本質

中佐藤 麻記子2015/11/28( 土 )

プロダクトオーナー祭り 2015 ：セッション C-2

自己紹介• 株式会社 豆蔵　所属（ 2012 年 12 月～）• 主に講師やってます– オブジェクト指向・ UML– 新人研修（ Java ・ C++ ）– アジャイル– 要件定義（システム部門・ユーザー部門）

• Agile Japan 2015-2016 実行委員2

Web 告知上のアジェンダ2005 年から提唱されている「要求開発方法論」について、紹介します。超上流工程の手法のため、BRUF （ Big Requirements Up Front ）の典型とも思われがちですが、その本質はビジネスとシステムをつなぐ役割です。特に最近、システム部門の方以外に、ユーザー部門の方にも教育 をする機会があり、その経験も踏まえて、エッセンスをお話しします。

3

私の思い• 「プロダクトオーナーシップ」 って、業務システム／ B to B にはないんだろうか？• ある！（と思う・・・）• でも、製品開発のプロダクトオーナーやプロダクトマネージャーとはちょっと違うかも

4

業務システムの特徴• 使い手と作り手が（今のところは）やや離れている• 特に使い手の利害関係者が多い• 頻繁な本番リリースが必ずしも望まれていない

5

要求開発とは• 「業務システム」 向きの手法です• 経営分析とシステム開発の間に位置します

経営分析 システム開発要求開発

6

コタツモデルビジネスオーナー

業務担当者システム開発者

7

“ 経営” とか ”ビジネス” と言われると、おしりがムズムズするという方へ

8

Requirement Triangle

Needs

Features

Requirements

設計 コード

ストーリーストーリーストーリー

9

要求開発のやろうとしていること正しい要求の獲得

システム開発に必要な情報を過不足なく定義

関係者の合意形成10

何が 「正しい」 のか？• ユーザーの要求は 「正しい」 のか

とにかく今、事務作業が多くて大変なんだ。早くなんとかし

てよ。

最優先すべきはスピードだよ。モタモタしていると、競合他社に置いていかれ

るよ。

当然、一番大事なのはお客さまですよね。お客さまのために、この機能は、早期に実現し

ないと。

折角時間とお金をかけるなら、この機能も追加してよ。

ついでにこの機能も。

このシステムは、随分長いこと刷新されないままなんですよね。そろそろ何とか

してくださいよ。

11

なぜ、要求「開発」？• ユーザーからヒアリングした要求が「正

しい」とは限らない

• 「要求分析」 などは、要求が既に存在しているという前提に立っている

• 要求は、業務を分析することで、ロジカルかつ能動的に開発しなければいけない

12

「必要な情報を過不足なく定義する」には？

「共通フレーム 2013 （情報処理推進機構ソフトウェア・エンジニアリング・センター編）」より

システム化計画

要件定義

システム要件定義

ソフトウェア要件定義

システム化の方向性

ソフトウェア適格性確認テス

ト

システム適格性確認テス

ト

運用テスト

評価

プログラミング

投資効果はあるか

要求は正しかったか

仕様通りか

事業

（ビ

ジネ

ス）

業務シ

ステ

ム

13

要求開発の 4 つのフェーズ準備フェーズ 立案フェーズ デザインフェー

ズシフトフェーズ

「何ができたら成功？」 を決める

現状 (AsIs) の可視化

あるべき姿(ToBe) の設計

システム開発への移行

プロジェクト　 ゴールの明確化

ステークホルダー　 の整理

業務課題の　 抽出

要求の構造化

現状業務分析- 業務プロセス- サービス構造- 情報構造

施策検討

あるべき業務　 プロセスの設計- 業務プロセス- サービス構造- 情報構造

システム化範囲　 の導出

システム化計画　 策定

システム要求の　 文書化- RFP/RFI 作成トレーサビリティ（追跡可能性）

14

準備フェーズのモデル

重視すべき立場からのインプット（課題、要求、解決案）

元々のプロジェクト目的との整合

適切なレベルの目標を設定

スコープからステークホルダーを特定

既出のインプット情報（課題、要求、解決案）

プロジェクト定義書

ステークホルダーリスト

ゴール記述書

要求分析ツリー

15

立案フェーズのモデル

ビジネスユースケース

業務フロー

サービスを実現する手順を表す

サービスに関わる概念を整理

業務に現れる概念を整理

ステークホルダーリスト

ゴール記述書

アクターと提供すべきサービスの抽出

要求に関連したサービスの抽出

ゴールに関連したサービスを抽出する

要求分析ツリー

概念モデル

16

デザインフェーズのモデル

サービス・モデル（ビジネス・ユースケー

ス）

サービスを実現する手順を表す

サービスに関わる概念を整理

業務に現れる概念を整理

ゴール記述書

プロセス・モデル（業務フロー）

準備フェーズ　←　　→　デザインフェーズ

As-Isから

To-Be

重点課題と対応方針 システム化範囲

（システム・ユースケース）

システム機能を抽出

立案フェーズ　←情報モデル（概念モデル）

17

シフトフェーズのモデル（一例）

業務に現れる概念を整理

プロセス・モデル

（業務フロー）ユースケース・モ

デル（システム・ユースケー

ス）

デザインフェーズ　←　　→　シフトフェーズ

システム・ユースケース図

情報モデル（分析クラス図）

ユースケース一覧

ユースケース記述システム機能を抽出

非機能要件リスト

用語集の概念に属性・操作を追加

システム特有のクラスを追加

IT システムのスコープを抽出

入出力仕様

出力レイアウト画面モックアップ

情報モデル（概念モデル）

18

要求開発手法の話は以上です。あれ？

もうひとつありませんでしたっけ？19

要求開発のやろうとしていること正しい要求の獲得

システム開発に必要な情報を過不足なく定義

関係者の合意形成20

関係者の合意形成• 合意は 「作った結果」 ではなく、「作る過程」で生まれる– “ アジャイルな計画づくりで重視するのは、計画よりも、計画をつくる過程そのものなのだ。”「アジャイルな見積りと計画づくり」より– “ 本当の価値は作成されたモデルではなく、モデリングという作業そのものにある”「ディシプリンド・アジャイル・デリバリー」より

21

アジャイル開発の危うさ• アジャイル開発は 「変化を抱擁する」 からこそ、「変えてはいけないもの」 を合意すべき Nee

ds

Features

Requirementsストーリーストーリーストーリー

22

要求開発手法のアジャイルな使用方法• 各種成果物を、合意形成のためのディスカッションの枠組みとして使ってください– 作った成果物を送付して、それにハンコ押してもらうことは 「合意」 ではない

• 変えてはいけない「価値」が何か探求しよう–詳細をすべて合意はできないし、すべきではない23

お願い• 恐れずユーザーと話してください– 思った以上にシステムに対して真剣です– 自分の業務に直結するものとして捉えています– システムのことを知りたいと思っています–ヒアリングは絶対に 「手ぶら」 で行かないこと

• 誰にも 「悪気」 はない– プロジェクトを失敗させようと思っている人はいない–みんなの 「思い」 の方向性を揃えていくことこそプロダクトオーナーシップ

24

ありがとうございました