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