Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20151128 po matsuri_c-2プロダクトオーナーが押さえるべき要求開発の本質_公開用

2,406 views

Published on

2015年11月28日(土) プロダクトオーナー祭り C-2セッション

Published in: Software
  • Be the first to comment

20151128 po matsuri_c-2プロダクトオーナーが押さえるべき要求開発の本質_公開用

  1. 1. プロダクトオーナーが押さえるべき 「要求開発」の本質 中佐藤 麻記子 2015/11/28(土) プロダクトオーナー祭り2015:セッションC-2
  2. 2. 自己紹介 • 株式会社 豆蔵 所属(2012年12月~) • 主に講師やってます – オブジェクト指向・UML – 新人研修(Java・C++) – アジャイル – 要件定義(システム部門・ユーザー部門) • Agile Japan 2015-2016 実行委員 2
  3. 3. Web告知上のアジェンダ 2005年から提唱されている「要求開発方法論」 について、紹介します。 超上流工程の手法のため、 BRUF(Big Requirements Up Front)の典型とも 思われがちですが、その本質はビジネスと システムをつなぐ役割です。 特に最近、システム部門の方以外に、ユーザー 部門の方にも教育 をする機会があり、その 経験も踏まえて、エッセンスをお話しします。 3
  4. 4. 私の思い • 「プロダクトオーナーシップ」 って、 業務システム/B to Bにはないんだろうか? • ある!(と思う・・・) • でも、製品開発のプロダクトオーナーや プロダクトマネージャーとはちょっと違うかも 4
  5. 5. 業務システムの特徴 • 使い手と作り手が(今のところは)やや離れて いる • 特に使い手の利害関係者が多い • 頻繁な本番リリースが必ずしも望まれて いない 5
  6. 6. 要求開発とは • 「業務システム」 向きの手法です • 経営分析とシステム開発の間に位置します 経営分析 システム開発要求開発 6
  7. 7. コタツモデル ビジネス オーナー 業務 担当者 システム 開発者 7
  8. 8. “経営” とか ”ビジネス” と 言われると、おしりがムズムズする という方へ 8
  9. 9. Requirement Triangle ストーリー ストーリー ストーリー 9
  10. 10. 要求開発のやろうとしていること 正しい要求の 獲得 システム開発に 必要な情報を 過不足なく定義 関係者の 合意形成 10
  11. 11. 何が 「正しい」 のか? • ユーザーの要求は 「正しい」 のか とにかく今、事務作業が 多くて大変なんだ。早く なんとかしてよ。 最優先すべきはスピー ドだよ。モタモタしている と、競合他社に置いて いかれるよ。 当然、一番大事なのは お客さまですよね。お客さ まのために、この機能は、 早期に実現しないと。 折角時間とお金をかけるなら、 この機能も追加してよ。ついで にこの機能も。 このシステムは、随分長いこと 刷新されないままなんですよ ね。そろそろ何とかしてくださ いよ。 11
  12. 12. なぜ、要求「開発」? • ユーザーからヒアリングした要求が「正しい」 とは限らない • 「要求分析」 などは、要求が既に存在して いるという前提に立っている • 要求は、業務を分析することで、ロジカル かつ能動的に開発しなければいけない 12
  13. 13. 「必要な情報を過不足なく定義する」 には? 「共通フレーム2013(情報処理推進機構ソフトウェア・エンジニアリング・センター編)」より システム化 計画 要件定義 システム 要件定義 ソフトウェア 要件定義 システム化の 方向性 ソフトウェア 適格性確認テスト システム 適格性確認テスト 運用テスト 評価 プログラミング 投資効果はあるか 要求は正しかったか 仕様通りか 事 業 ( ビ ジ ネ ス ) 業 務シ ス テ ム 13
  14. 14. 要求開発の4つのフェーズ 準備フェーズ 立案フェーズ デザインフェーズ シフトフェーズ 「何ができたら 成功?」 を決める 現状(AsIs)の 可視化 あるべき姿 (ToBe)の設計 システム開発への 移行  プロジェクト ゴールの明確化  ステークホルダー の整理  業務課題の 抽出  要求の構造化  現状業務分析 - 業務プロセス - サービス構造 - 情報構造  施策検討  あるべき業務 プロセスの設計 - 業務プロセス - サービス構造 - 情報構造  システム化範囲 の導出  システム化計画 策定  システム要求の 文書化 - RFP/RFI作成 トレーサビリティ(追跡可能性) 14
  15. 15. 準備フェーズのモデル 重視すべき立場から のインプット(課題、 要求、解決案) 元々のプロジェクト目的との整合 適切なレベルの 目標を設定 スコープからステーク ホルダーを特定 既出のインプット情報 (課題、要求、解決案) プロジェクト定義書 ステークホルダーリスト ゴール記述書 要求分析ツリー 15
  16. 16. 立案フェーズのモデル ビジネスユースケース 業務フロー サービスを実現 する手順を表す サービスに関わる 概念を整理 業務に現れる 概念を整理 ステークホルダーリスト ゴール記述書 アクターと 提供すべき サービスの抽出 要求に関連した サービスの抽出 ゴールに関連した サービスを抽出する 要求分析ツリー 概念モデル 16
  17. 17. デザインフェーズのモデル サービス・モデル (ビジネス・ユースケース) サービスを 実現する 手順を表す サービスに 関わる 概念を整理 業務に現れる 概念を整理 ゴール記述書 プロセス・モデル (業務フロー) 準備フェーズ ← → デザインフェーズ As-Is から To-Be 重点課題と 対応方針 システム化範囲 (システム・ユースケース) システム 機能を抽出 立案フェーズ ← 情報モデル (概念モデル) 17
  18. 18. シフトフェーズのモデル(一例) 業務に現れる 概念を整理 プロセス・モデル (業務フロー) ユースケース・モデル (システム・ユースケース) デザインフェーズ ← → シフトフェーズ システム・ユースケース図 情報モデル (分析クラス図) ユースケース一覧 ユースケース記述システム 機能を抽出 非機能要件リスト 用語集の概念に 属性・操作を追加 システム特有のクラスを追加 ITシステム のスコープ を抽出 入出力仕様 出力レイアウト 画面モックアップ 情報モデル (概念モデル) 18
  19. 19. 要求開発手法の話は以上です。 あれ? もうひとつありませんでしたっけ? 19
  20. 20. 要求開発のやろうとしていること 正しい要求の 獲得 システム開発に 必要な情報を 過不足なく定義 関係者の 合意形成 20
  21. 21. 関係者の合意形成 • 合意は 「作った結果」 ではなく、「作る過程」 で生まれる – “アジャイルな計画づくりで重視するのは、計画よりも、 計画をつくる過程そのものなのだ。” 「アジャイルな見積りと計画づくり」より – “本当の価値は作成されたモデルではなく、モデリングと いう作業そのものにある” 「ディシプリンド・アジャイル・デリバリー」より 21
  22. 22. アジャイル開発の危うさ • アジャイル開発は 「変化を抱擁する」 から こそ、「変えてはいけないもの」 を合意すべき ストーリーストーリーストーリー 22
  23. 23. 要求開発手法のアジャイルな使用方法 • 各種成果物を、合意形成のための ディスカッションの枠組みとして使ってください – 作った成果物を送付して、それにハンコ押して もらうことは 「合意」 ではない • 変えてはいけない「価値」が何か探求しよう – 詳細をすべて合意はできないし、すべきではない 23
  24. 24. お願い • 恐れずユーザーと話してください – 思った以上にシステムに対して真剣です – 自分の業務に直結するものとして捉えています – システムのことを知りたいと思っています – ヒアリングは絶対に 「手ぶら」 で行かないこと • 誰にも 「悪気」 はない – プロジェクトを失敗させようと思っている人はいない – みんなの 「思い」 の方向性を揃えていくことこそ プロダクトオーナーシップ 24
  25. 25. ありがとうございました

×