Your SlideShare is downloading. ×
要求開発の発展と展開、そして課題
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

要求開発の発展と展開、そして課題

3,211
views

Published on

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2012年4月定例会発表資料です。 …

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2012年4月定例会発表資料です。
Open Community "Requirement Development Alliance" 2012/4 regular meeting of the presentation materials.

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,211
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
73
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 要求開発の発展と展開、そして課題 株式会社 匠 BusinessPlace 代表取締役社長 萩本順三 http://www.takumi-businessplace.co.jp/ www.takumi-businessplace.co.jp
  • 2. 要求開発における10の普遍的価値 2 www.takumi-businessplace.co.jp
  • 3. その1:要求開発4象限ユーザ企業・IT企業共通・ビジネスとITを繋げる考えがベースにある・ビジネス戦略、ビジネス改革の手法に発展できる可能性IT企業(IT企業の変革、エンジニアの意識改革に使える可能性)・開発会社の従来の視野をユーザ業の視点まで広げる・ビジネスの視点からエンジニアリングを再構築 戦略・要求 オペレーション ユーザ企業 ビ ビジネス ビジネス の視点 ジ 戦略 オペレーション ネ ス 表(価値) What How 裏(実現) What 表(価値) 裏(実現) How 開発会社の シ ス 表(価値) What How 裏(実現) 従来の視野 テ ム システム要求 システム設計 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 3 www.takumi-businessplace.co.jp
  • 4. その2:コタツモデル~要求をコタツで形成~ 要求は、あるものではなく、開発するものである 業務理念を統制し、業務効率化を図るための 業務とは○○あるべきだ。 しかし現実は△△だから、それをどう改善でき るか現場と話し合ってみよう。 オーナの論理本当に求められている業務の姿 我々のやり方がベストだと思っていを経営や現場と、きちんと確認 たけど、見方を変えれば欠点が多しないと、あるべき業務やシステ いね。ムの要求は導き出せない。 問題の視覚化(モデル)と もう少し業務のあるべき姿を考えて 改善プロセスによる活動 みよう。 コタツ 開発された要求 開発担当者の論理 業務担当者の論理 モデル Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 動機編より抜粋 4 www.takumi-businessplace.co.jp
  • 5. その3:要求のロジカルな落とし込みオーナーや業務担当者から聞いたものをいきなり要件に落とし込まない。 要望 要求 要件オーナーやユーザーからの オーナーやユーザーからの 合意された要求に対してリクエスト 要望をとりまとめ 予算、スケジュール、可能但し、それを実現して本 その目的、効果、妥当性 性を検討して、当にメリットが得られるの を検証して、関係者が合 実現すべき、業務、システか、実現可能なのか等の 意したあるべき姿 ムを定義したもの裏打ちはない 要求の爆発を防止 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 5 www.takumi-businessplace.co.jp
  • 6. その3:要求の構造的な階層化要求を上位・中位・下位で関係付けて見える化できる枠組みがある。 戦略・要求 オペレーション ビ ビジネス ビジネス ジ 戦略 オペレーション ネ ス 表(価値) What How 裏(実現) What 表(価値) 裏(実現) How シ ス 表(価値) What How 裏(実現) テ システム要求 システム設計 ム 要求開発4象限 戦略要求 業務要求 IT要求 利用代理店IDが システム開発費 利用代理店IDが 業務負担の 増大することを 維持費の削減 増大することを 軽減 見込したID管理 見込したID管理学生サービスの重点拡充 商品管理の○○を ××に改善する 標準業務モデル ○○による の確立 業務システム構築 ○○視点での安心品質の確保 使いやすさ重視 新サービスビジネスモデル 業務支援 の早期確立 システム構築 要求分析ツリー Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 6 www.takumi-businessplace.co.jp
  • 7. その4:コタツモデルの本質的価値コタツ形成は、チームの役割だけを示すものではない。参加者全員が3つの視点を持つ事。 戦略的 将来の価値を 視点 取りに行く傾向 業務部門に戦略的視野 を身につけさせる。 IT活用の ビジネスにとって 業務問題 現在の価値を 価値のある 取りに行く傾向 視点 要求・要件 解決の視点 戦略部門に現場の問題 課題を理解させる。これによって、要求(戦略・業務・IT)を広い視野で考え、取捨選択するための基礎が形成される。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 7 www.takumi-businessplace.co.jp
  • 8. その5:コタツは、結果イメージの予測を加速• ビジネス戦略と業務を見える化しながらIT要求を出し、開発 を進めていく手法の可能性 匠メソッド ビジネスアジャイルメソッド• 企画を高速に回す可能性 匠メソッド 匠Method for Service 戦略・要求 オペレーション 戦略的 ビ 視点 ジ オーナ ネ IT活用の 業務問題 ス 業務担当 視点 解決の視点 戦略的 視点 シ ス テ ム システム担当 IT活用の ビジネスにとって 業務問題 価値のある 視点 解決の視点 要求・要件 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 8 www.takumi-businessplace.co.jp
  • 9. その6:要求開発は仕事力向上のヒント 戦略・要求 オペレーション ビジネス戦略 企画戦略/プロモーション ビ ジ ネ ス Howの手探り Howからの突き上げ シ ス Howのチューニング テ ム システム要求 システム開発○企画戦略段階における戦略 ビジネスリスクマネジメントの向上 1.イノベーションの向上 2.実現性の早期発見匠Think 用語より …要求開発の中で創り出された重要な言葉を通して教育を行う体系 ●「戦略と実現の線上にしか価値は存在しない」 ●「制御可能で制御価値の高いものから手をつける」 Howの手探り :企画段階から製品の価値や実現可能性を探る Howからの突き上げ:企画段階から技術面からの製品価値の向上を即す Howのチューニング :技術的試行錯誤を早い段階で繰り返し価値向上を図る Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 9 www.takumi-businessplace.co.jp
  • 10. その7:要求開発は切れていたものを繋げる仕組み切れていたものを、繋いで、並行でスピーディに回す。 戦略・要求 オペレーション ビジネス戦略 企画戦略/プロモーション オーナ ビ ジ ネ ス Howの手探り 人と人 業務担当 システム担当 シ Howからの突き上げ ス テ Howのチューニング オーナ企業 ム システム要求 システム開発 業務運用 子会社 IT子会社 企画・戦略部門 会社と会社 営業部門 組織と組織 開発部門 業務部門 戦略 思考と思考 目的 実現 手段 実現 手段 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. www.takumi-businessplace.co.jp
  • 11. その8:コタツの究極の本質は2つの視点の導入 戦略的 視点 匠メソッド キャリア開発 匠メソッド 業務改革 for Service 匠メソッド 要求開発 for ProductIT活用の 業務問題 匠メソッド 匠Think ビジネスにとって 価値のある 視点 要求・要件 解決の視点 システム開発時 業務改革 要求開発時 スキル開発時 現場力向上 将来価値 戦略を考える 業務のあるべ 将来の自分 の視点 き姿を考える 戦略を考える 現在価値 現状の問題 現状業務の 現在身につけ の視点 解決を考え 問題解決を るべきスキル る 考える を考える Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 11 www.takumi-businessplace.co.jp
  • 12. その9:目的と手段の構造を持つモデル体系がある ビジネス戦略ビ 戦略ビュージ ビジネス戦略ネス プロジェクト戦略 サービス ビュー プロセス ビュー 情報 ビュー ビジネス要求 ビジネス・プロセス オブジェクト モデルIT アプリケーション システム要求 データシ ・プロセス モデルステム アプリケーション フレームワーク 実装アーキテクチャ Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 12 www.takumi-businessplace.co.jp
  • 13. その10:システムに繋ぐ明確なプロセスがある 準備 立案 デザイン 移行 立上げ 現状分析 改善検討 業務改善 ゴールの合意 見える化 見える化 システム化 ・ 仮説設定 (現状モデル) (新モデル) 要件定義 プロジェクト 課題分析 評価 RFP 計画作成 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 13 www.takumi-businessplace.co.jp
  • 14. 要求開発を適用したビジネスの課題• なかなか要求開発からシステム開発に繋 ぐ案件が少ない。• 大きなウォータフォール開発となりがち 。• どこでも、なんでも使えます的。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 14 www.takumi-businessplace.co.jp
  • 15. 匠Method 要求開発を発展させビジネス価値の見える化に挑戦 15 www.takumi-businessplace.co.jp
  • 16. Why 匠Method.• 要求開発方法論を更に洗練化 • 契約主導:要求開発方法論と開発方法論のセット化 • 価値主導:ビジネスアジャイル要求開発• 要求開発を幅広く活用可能とする • 業務改革要求開発 • 要求開発による製品開発メソッド(匠Method for Product) • 要求開発によるビジネス企画メソッド(匠Method for Service)• ビジネス視点でITを開発するための • キャリアデベロップメント• 価値を見える化するためのガイドライン • 匠ビジネスエクスペリエンス• 要求開発的思考法 • 匠Think リスクマネジメントとイノベーションのための発想法、思考法のトレーニング Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 16 www.takumi-businessplace.co.jp
  • 17. 匠Thinkプラクティス テンプレート 匠メソッド ガイド 匠プロセス 要求開発プロセス キャリア開発ガイド システム開発プロセス 教育体系ガイド ビジネスアジャイル開発プロセス サービス開発ガイド 業務改善プロセス 匠Method for Service 最新・独立 匠Method for Product 最新・独立 匠テクニカル モデリング ビジネスエクスペリエンス Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 17 www.takumi-businessplace.co.jp
  • 18. 匠メソッドの構成要素匠Think 匠メソッドやガイドに共通する基本的な思考パターンを示したもの匠メソッド 匠プロセス 要求開発プロセス ビジネス価値を産むための要求開発実施プロセス (手順) 要求開発の後のシステム開発についてのプロセス システム開発プロセス ビジネスアジャイル開発プロセ 要求開発とシステム開発をアジャイル(俊敏)に実施するプロセス ス 業務改善プロセス 要求開発によって業務改善をおこなうプロセス 匠Method for Service 要求開発によるビジネス企画のためのプロセス 匠Method for Product 要求開発による製品開発プロセス 匠テクニッ モデリング ビジネスやシステムを抽象化によって見える化する ク ユーザーの視点でビジネスやシステムをデザインする ユーザーエクスペリエンス (技法)匠ガイド キャリア開発ガイド 要求開発の実施に必要な人材像を示す 教育体系ガイド 要求開発の実施に必要な教育体系を示す サービス開発ガイド 要求開発によるサービス開発の進め方を示すプラクティス 要求開発を成功させるためのポイントを成功事例を踏まえて説明テンプレート 匠メソッドで用いる様式集 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 18 www.takumi-businessplace.co.jp
  • 19. やるべき事とは 匠Think 戦略と実現の線上にしか価値は存在しない 価値できるだけ前段階で! 企業による分断 戦略 業務 組織による分断 IT活用 職種による分断 IT実現 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 19 www.takumi-businessplace.co.jp
  • 20. 要求開発活用の気付き(製品開発の場合)コタツの応用壁を壊して、合意形成の場を形成する トップ&製品企画部門 戦略的 視点 技術活用の ビジネスにとって 価値のある 業務問題 視点 要求・要件 解決の視点 開発部門 企画営業部門 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 20 www.takumi-businessplace.co.jp
  • 21. 経営・業務改革の考え方として(将来の価値と現在の価値) 戦略的 視点 将来の価値 業務問題 現在の価値 解決の視点 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 21 www.takumi-businessplace.co.jp
  • 22. そもそもの原点:製品の要求とは! ユーザ HowからWhatの創出 何を必要としているのか 何を必要としているのか (Whatの流れ) (Whatの流れ) Howの手探り Howのチューニング 方 向 ニーズとシーズの 性 バランス(調整)Howからの突き上げ 製品 Howからの突き上げ ビジョン 製品コンセプト 製品アーキテクチャ シーズからニーズを描く:情報洪水時代(情報過多)に最も必要な事! Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 22 www.takumi-businessplace.co.jp
  • 23. 経営・業務改革の考え方として(価値を描いて作る)描く力 価値 戦略 業務 機能 構造 作る力 オブジェクト指向 要求開発 匠メソッド 方法論Drop 1997 方法論2005 方法論2009 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 23 www.takumi-businessplace.co.jp
  • 24. 匠Method for Service(企画のための要求開発) • モデル・ビューとは、サービス企画段階において、様々なビュー (視点)で、サービスの価値や機能および構造を見える化する ためのフレームワーク。 • まずは見える化するためのフレームワークを確立する事が何よ り重要モデル・ビュー(基本)の全体像 組織ビュー ドメインビュー プロジェクトビュー 価値モデル 業務モデル 機能モデル Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 24 www.takumi-businessplace.co.jp
  • 25. 匠Method for Product(製品企画開発メソッド) • モデル・ビューとは、製品企画段階において、 様々なビュー(視点)で、製品の価値や機能お よび構造を見える化するための枠組みの事。モデル・ビュー(基本)の全体像 ユーザビュー プロダクトビュー プロジェクトビュー 価値モデル 業務モデル 機能モデル 構造モデル Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 25 www.takumi-businessplace.co.jp
  • 26. ビジネス企画への活用匠Method for Serviceのご紹介 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 26 www.takumi-businessplace.co.jp
  • 27. 匠Method for Serviceの目的/活用範囲• 匠Method for Serviceは、要求開発方法論のコンセプトを活用し、サービス(業 務・システム等)の企画段階において価値のある企画をスピーディに行うためのビ ジネス企画のための標準的手法です。• 匠Method for Serviceが有効な状況 – 新規ビジネス企画における有効性 • 新たなビジネスを立ち上げる際に、全体的な視野を持ち、ステークホルダの価値を形にしなが ら、関係者感で共感していくためのプロセスが明確になる。 – 継続的ビジネス企画における有効性 • 企画を行ったが、「魅力的な内容」、「企画対象の特徴や強み」といった観点で考えた時に、 企画の進め方に何か問題があるように思えている。 • 企画自体に属人性があるために、人によって企画としての表現や質が大きく異なっている。 • プロジェクトがいつの間にか立ち上がり、価値の評価が行われずに企画が進む。 – システム企画における有効性 • 企画が手間取り、開発が遅れがちになる。 • 企画の狙いがぶれている状態で開発が進み、結果的に要求定義に後戻りすることがある。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 27 www.takumi-businessplace.co.jp
  • 28. ライセンス体系 • 匠Method for Service – イントロダクション(無償部分) • モデルの全体像と、それぞれのモデルの概要説明。 – ドキュメント解説編(ライセンス有償) • 個々のモデルの詳細な説明とモデル同士の関係性。 – サンプル編(ライセンス有償) • モデルのサンプルドキュメント。 – テーラリングガイド(ライセンス有償) • 企画の特性に対して、カスタマイズするためのガイド。 – コンサルティングガイド編(ライセンス有償) • 社内で匠Method for Serviceを実施するためのコタツ形成の方法 、問題意識の持ち方、それぞれのセッションでの意識の持ち方、質 問に対する答え方等、ファシリテータ― or コンサルタントのノウハ ウを纏める。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 28 www.takumi-businessplace.co.jp
  • 29. 使用法• 匠Method for Service – トライアル24H • 24時間(振り返り含めて約6日間) • 案件にて実践するサービスを提供 • ケース1 : 比較的小さな案件では、開発まで繋げる • ケース2 : 大きな案件では、要求開発の準備フェーズとして活用 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 29 www.takumi-businessplace.co.jp
  • 30. ドキュメント全体体系 ◆ビジネスユースケース図 ◆システムユースケース図 ◆SWOT分析シート ◆BSC戦略マップ ○ ○ シ ステ ム ○○社 商 品 一 覧 参 照する組織 在 庫 の 確 認を 粉 う 在庫担当ビュー 顧 客 商 品 を 購 入する 売 上 集 計 を 粉う 会計担当 ◆ステークホルダリスト ◆ステークホルダ価値関連図 ◆ビジネスコンテキスト図 ◆業務モデル(AsIs,ToBe) ◆概念モデルドメインビュー ◆要求分析ツリー ◆プロジェクトゴール記述書 ◆プロジェクト初期プラン ◆プロジェクトシートプロジェクトビュー Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. www.takumi-businessplace.co.jp 30
  • 31. ドキュメント全体体系(モデル・ビュー) ●…匠オリジナルモデル 説明 ●…要求開発等により一般的なモデルを拡張 ●…一般的なモデル ドメイン(問題領域) 組織ビュー プロジェクトビュー ビュー ●SWOT分析シート ●ステークホルダ分析 ●プロジェクトシート ●匠BSC戦略マップ ●ビジネスコンテキスト図 ープロジェクトビジョン ープロジェクトミッション価値のモデル ●要求分析ツリー ●ステークホルダ価値関連モデル ●プロジェクトゴール記述 ●プロジェクト初期プラン ●業務モデル(As-Is)業務 ●業務モデル(To-Be)モデル ●概念モデル ●ビジネスユースケース図機能 ●システムユースケース図モデル Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 31 www.takumi-businessplace.co.jp
  • 32. ドキュメント概要説明(1) ドキュメント名 説 明 書き方ポイント ◆SWOT分析シート ・ビジョン、SWOT分析、戦略テーマ ○ビジョンは組織として目指したい方向性 をまとめたもの。 を3~5記述します。 プロジェクトごとに記述は多少異な るが、一度書いていれば再利用可能。組織ビュー ◆ 匠BSC戦略マップ ・戦略を財務、顧客、内部プロセスまで ○顧客戦略以降は記号を付けて、要求分析 落とし込むためのシート。 ツリーと対応を取るようにします。 BSC戦略マップを改造して活用します。 ○詳細戦略は要求分析ツリーにて深堀しま プロジェクトごとに記述は多少異な す。 るが、一度書いていれば再利用可能。 ※匠Method for Service イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 32 www.takumi-businessplace.co.jp
  • 33. ドキュメント概要説明(2) ドキュメント名 説 明 書き方ポイント ◆ステークホルダリスト ・プロジェクト関係者からビジネス関係者まで、 ○プロジェクトが関係するビジネスのキー 主要な利害関係者を洗い出し、整理します。 となる関係者、および、プロジェクトに ・業務フローのレーン、価値相関図のステーク 直接的に関わる関係者を洗い出します。 ホルダに(一部)使用します。 ○あくまでビジネスの全体像を掴むことが目的 ・ビジネス上重要な企業および関係者について の図ですので必要以上に細かく記述しないで ◆ビジネスコンテキスト図 ステークホルダから抜粋して、ビジネスの根 ください。その中で本質的に問題と思われる 幹となす主要なモノやコトの流れを捉えます。 個所や改善点なども説明吹き出しで説明する とよいでしょう。 ○細かな業務フローを書く前に、書くことがポドメイン イントです。業務フローでは、ビジネスの大ビュー 枠を掴みきれないことがあります。 ・プロジェクトテーマを成功に導くため ○これはシステムを開発したが、関係者が ◆価値関連図 使ってくれないといったリスクを初期段 に重要となるステークホルダの人達が ビジネスに参画する際のメリットを洗 階から見抜くためにシミュレーションし い出し、ビジネス価値という観点でリ ます。これにより、行き詰まる場合は企 スクがないか事前検証します。 画的な問題があります。 ◆業務モデル ○AsIsの大きな問題個所については、要求分 (AsIs、ToBe) ・現状(AsIs)は現状業務の問題個所をフローで 析ツリーの問題エリアの記述と対応するで 表します。 しょう。 ・新(ToBe)は新業務をどのように行うか大ま ○ToBeの新業務およびシステムについては、 か 要求分析ツリーのプロジェクト課題エリア に設計したものを記述します。 に対応することになるでしょう。 ※匠Method for Service イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 33 www.takumi-businessplace.co.jp
  • 34. ドキュメント概要説明(3) ドキュメント名 説 明 書き方ポイント ◆概念モデル ・ビジネスで使われる用語の意味概念はビジネ ○用語同士の関係性、および全体-部分の関係 スを行う関係者によって解釈が異なることが 汎用化-特殊化の関係を見える化するもの あります。概念モデルにより、用語概念同士 であり、データ構造のモデルを作成すると の関係を明らかにすることで、ビジネス概念 いうものではありません。ドメイン の意味を関係者で統一化を目指します。ビュー ◆ビジネスユースケース図 ・ビジネス機能とそのビジネス機能を使う ○ビジネス機能はビジネスユースケースとし ○○ 人(役割名)を見える化することで、 て、ステークホルダはビジネスアクターと 社 主要ビジネス機能とステークホルダの関 して表現します。 係を明らかにします。 ◆システムユースケース図 ・ビジネスユースケースの機能について、 ○システムユースケースはITシステムに対 システム的にサポートされるものを、 する基本要求を記述します。あくまで、 システムを使う立場から見た単位で記述 ○ ○ シ ステ ム 商 品 一 覧 参 照する システムユースケースとして抜粋し、 記述します。 します。 在 庫 在 庫 の 確 認を 粉 う 担 当 顧 客 商 品 を 購 入する 売 上 集 計 を 粉う 会 計 担 当 ※匠Method for Service イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 34 www.takumi-businessplace.co.jp
  • 35. ドキュメント概要説明(4) ドキュメント名 説 明 書き方ポイント ◆要求分析ツリー ・問題エリアには、プロジェクトで取り扱 ○要求エリアは戦略、業務、ITとできるだ うべき本質的問題を記述します。 け繋げるようにします。 ・プロジェクト課題エリアは、プロジェクトで ○要求は10~25が適切。あまり数が 取り扱うタスクとなるテーマを記述します。 多くなると本質が理解できなくなります。 ◆プロジェクトゴール記述 ・プロジェクトとしてのゴールを約束事として ○ゴールは、3段階程度に期間を分類するとプロジェ 記述します。 よいでしょう。 1.プロジェクトオーバービュー策定段階クト 2.プロジェクト企画完了段階ビュー 3.システム開発完了段階 ◆プロジェクト初期プラン ・プロジェクトの初期段階としてのスケジュ ○できるだけ視覚的に分かりやすく記述し ールを記述します。 ます。 ◆プロジェクトシート ・プロジェクトミッション、問題・課題、 ○本プロジェクト当初から少しづつ完成させ テーマ、ゴールなど、ここまで書いたドキュ て行きます。最終的には、プロジェクト企 メントを抜粋して作成します。 画書のベースとなるものです。 この段階では、あくまで概略に留めます。 ※匠Method for Service イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 35 www.takumi-businessplace.co.jp
  • 36. 要求開発準備フェーズとしての役割(例:24Hでビジネス外観をHowの手探り) ビジネス戦略 戦略ビュー プロジェクト戦略 ◆ステークホルダリスト ◆価値関連図 ◆プロジェクト初期プラントライアル ◆要求分析ツリー24Hの範囲 ◆ビジネスコンテキスト図 ◆プロジェクトゴール記述 ◆プロジェクトシート サービス ビュープロセスビュー 情報ビュー 業務・プロセス ビジネス要求 ◆業務モデル(AsIs、ToBe) ◆ビジネスユースケース図 ◆概念モデル◆業務システムフロー ○○ 社 アプリケーション・プロセス システム要求 データモデル◆基本要求 ◆画面イメージ ◆システムユースケース図(TFS要求管理) (スケッチフロー) ○ ○ シ ステ ム 商 品 一 覧 参 照する 在 庫 在 庫 の 確 認を 粉 担 う 当 顧 客 商 品 を 購 入す る 売 上 集 計 を 粉う 会 計 担 当 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 36 www.takumi-businessplace.co.jp
  • 37. 製品企画・開発への活用匠Method for Productのご紹介 ※匠Method for Productは、NDSと共同開発・共同所有しています。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 37 www.takumi-businessplace.co.jp
  • 38. 匠Method for Productの目的/活用範囲• 匠Method for Productは、要求開発をベースとした、製品開発における、プロダ クトの企画・マネジメント手法として生まれました。製品や、プロダクト(製品群)の 価値を企画段階から描き、プロダクトの発展をマネジメントします。 匠Method for Productは製品開発に3ステップのイテレーションで繋げます。 (匠Method for Serviceはシンプルな企画 1st イテレーションを売りとしている)• 匠Method for Productの特徴 – プロダクトマネジメントに幅広い視野を与える ユーザの感じる価値? – 製品企画の価値をデザインする ユーザの視点 ユーザのビジネス? – 製品開発の方向性を見える化する プロダクトの全体像? プロダクトの視点 プロダクトの価値? プロダクトの成長? プロジェクトの視点 ミッション・ゴール ビジョン Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 38 www.takumi-businessplace.co.jp
  • 39. ライセンス体系• 匠Method for Product – イントロダクション(無償部分) • モデルの全体像と、それぞれのモデルの概要説明。 – ドキュメント解説編(ライセンス有償) • 個々のモデルの詳細な説明とモデル同士の関係性。 – サンプル編(ライセンス有償) • モデルのサンプルドキュメント。 – イテレーションガイド(ライセンス有償) • 開発に繋げる3回のイテレーションの流れを説明。 – コンサルティングガイド編(ライセンス有償) • 社内で匠Method for Productを実施するためのコタツ形成の方法 、問題意識の持ち方、それぞれのセッションでの意識の持ち方、質 問に対する答え方等、ファシリテータ― or コンサルタントのノウハ ウを纏める。 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 39 www.takumi-businessplace.co.jp
  • 40. 匠Method for Product 全体体系(モデル・ビュー) ●…匠オリジナルモデル 説明 ●…一般的なモデルを拡張 ●…一般的なモデル ユーザビュー プロダクトビュー プロジェクトビュー ●ビジネスコンテキスト図 ●プロダクトビジョン ●プロジェクトシート ●ユーザコンセンサスモデル ●プロダクトコンセプト -プロジェクトビジョン ●プロダクト戦略 -プロジェクトミッション ●プロダクトロードマップ -プロジェクトプラン ●プロジェクトゴール記述価値の ●要求分析ツリーモデル ●想い図 ●ポートフォーリオマルチビュー ●プロダクトバリューシミュレーション -パンフレットイメージ -プロトタイプシナリオ -ユーザライフスタイルデザイン ●ステークホルダ分析 ●プロダクトステークホルダ分析 ●ユーザビジネスモデル ●業務モデル業務 ⇒業務フロー ●組織モデルモデル ●製品体系図 (利用目的別マップ)機能 ●機能体系図モデル ●問題・課題分析構造 ・アーキテクチャモデルモデル Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 40 www.takumi-businessplace.co.jp
  • 41. 匠Method for Product(価値・機能)主要モデル・トレーサビリティマップ ユーザビュー プロダクトビュー プロジェクトビュー ユーザコンセンサスモデル プロダクト プロジェクト ビジョン・コンセプト ビジョン・ミッション 主要 ビジョン プロジェクト ステークホルダ コンテキスト プロダクトビジョン と戦略 への想い投入 の抽出 強化点の コンセプトと戦略 コンセプト化 のトレーサブル 主要 ステークホルダ プロジェクト の抽出 への絞り込み 想い図 プロジェクト ビジネスコンテキスト図 プロダクト戦略 への想い投入 (ビジネス関係者) (匠BSC戦略マップ) あたり前機能 ・企業向け 差別化機能 戦略的機能 ・ビジネスモデル 廃止・強化機能 コンシューマ 要求分析ツリー 向け 要求・解決策要求 ステークホルダ分析 機能体系図 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 41 www.takumi-businessplace.co.jp
  • 42. 匠Method for Product (業務・機能)主要モデル・トレーサビリティマップ ユーザビュー プロダクトビュー プロジェクトビュー 市場から見た プロダクト価値 の評価 業務・組織 ポートフォーリオ プロダクトロードマップ マルチビュー プロダクト 全体プラン評価 業務モデル プロジェクトシート 添付 業務・組織 開発 の評価/改革 プランユーザビジネス 製品体系図 モデル 組織モデル ユーザビジネス から見た製品 プロジェクトプラン 系列・機能の 評価 プロジェクト の目標設定 製品ごとの機能体系 の評価 機能体系図 プロジェクトゴール記述 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 42 www.takumi-businessplace.co.jp
  • 43. ドキュメント概要説明(1) ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆ユーザコンセンサスモデル ・ステークホルダの中で、製品を使用する ○現意識には、現在達成しているものや、 ユーザの具合的なイメージとして連想し 目指している価値を表現します。 その人が、製品に対してどのような価値 ○新意識では、ユーザの新たな利用サイクルを を感じているのか、実際の言葉で記述し 連想し、そこで形成されるであろう価値を記 ます。その際に、現在の意識と、本来あ 述します。 るべき意識を記述します。ユーザ ・製品を展開する上で重要な企業および関係者 ○あくまでビジネスの全体像を掴むことが目的 ◆ビジネスコンテキスト図ビュー の図ですので必要以上に細かく記述しないで についてステークホルダから抜粋して、ビジ ください。その中で本質的に問題と思われる ネスの根幹となす主要なモノやコトの流れを 個所や改善点なども説明吹き出しで説明する 捉えます。 とよいでしょう。 ○本図は、通常は、業務処理の流れを順序的に 説明するものではありませんが、シンプルな レベルで流れを記述するとよいでしょう。 ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 43 www.takumi-businessplace.co.jp
  • 44. ドキュメント概要説明(2) ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆ユーザビジネスプロセス ○コンシューマー向け製品にはビジネスプロ ・製品を使用するユーザのビジネスプロセス セスが存在しないことが多いでしょう。 について業務フローを使って表現します。 ただし、コンシューマー向けであっても、 製品を使う際にフロー的なものがあれば、 それを記述します。 ○ビジネス向け製品においては、お客様の製 品に関わる業務フローを見える化します。ユーザ ◆ユーザビジネス情報モデル ・ビジネス向け製品において、ビジネスを ○あくまで企画・営業・開発メンバーの業務ビュー 理解するという意味あいにおいて、情報 の基礎知識としての情報モデルですので、 モデルを作成し、内部関係者で共有知と 用語の関係構造を捉えるというレベルで完 します。 結させてください。 詳細すぎるモデルを時間をかけて記述して も、理解できなければ意味がありません。 ◆ステークホルダ分析 ・顧客のほか、製品開発販売に関わるビジネ ○コンシューマー向け製品とビジネス向け スの主要な利害関係者を洗い出し、その特 製品では、ステークホルダが異なります。 性を分析します。 ○コンシューマー向け製品では、消費者を カテゴリで区分できる場合は、区分してく ださい。 ○両ビジネス共に、製品販売に関わる関係 者を登場させます。 ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 44 www.takumi-businessplace.co.jp
  • 45. ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ドキュメント概要説明(3) ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆プロダクトバリュー ・プロダクトの価値を描き、あらゆる観点で シュミレーション 評価・検証を行ういくつかの図で構成され ます。 ・製品の評価軸をマルチに構成できる匠BP で発案された新たな価値評価モデルです。 座標軸をいくつも持てるので、複雑多彩な ◆ポートフォーリオ プロダクト構成にも活用できます。 マルチビュー ・製品パンフレットのデザイン評価的な意識 より、その中で構成される「キャッチフレ ・製品パンフレットのイメージを作成し評価 ーズ」や主要機能の見せ方について、しっ します。 かり記述し、それを持って次期リリースのユーザ 価値を評価します。 ◆パンフレットイメージビュー ・主に何のためにプロトタイプ開発を行うの ・製品評価を行うためのプロトタイプを行う か、どこまで行うのか、何で評価し、プロプロダク 際に使用します。 トタイプの成果として何を期待し、今後にトビュー 活用するのかを明確にします。 ◆プロトタイプ(共通) (スケッチフロー) ・コンシューマー向け製品では、一般消費者 ・製品の新たな価値を描くために、ユーザ の製品を使う新たなライフスタイルを見える の新しいライフスタイルの中で製品が如 化します。 何に使われるのかイメージできるシナリオ ・ビジネス向け製品については、企業の中で を描きます。 製品を使う新たな業務スタイルを見える化 ◆ユーザライフスタイル します。 デザイン ・これらはユーザコンセンサスモデルの新意識 を参考に考えましょう ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 45 www.takumi-businessplace.co.jp
  • 46. ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ドキュメント概要説明(4) ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆プロダクト戦略 ・プロダクトの製品戦略を、財務の視点や ○まず製品系列の範囲を決め、その範囲内にて 重要戦略の視点、顧客の視点で整理し、 戦略を定める必要があります。 内部プロセスと内部プロセス強化(育成) に繋げていきます。 一般的なBSC戦略マップを拡張した、 匠戦略マップを使います。 ◆プロダクトロードマップ ○プロダクトロードマップは、外向け(顧客向 ・プロダクトにおける開発プランを3年スパン けパートナ―向け)と、内向けで見せ方を変 程度で見える化します。ここでは、製品機能 え、内向けはより詳細が記述できる形式を使 の開発をカテゴリ分類するだけではなく、ビ うと良いでしょう。 ジネス機会、ブランディング、営業活動など (サンプルを参照してください)プロダク のゴールも見える化し、全体として何がいつトビュー までにできているかを理解できるようにしま す。 ◆プロダクトビジョン・コンセプト ・プロダクト戦略の根幹となる、プロダクトのビ ○プロダクトのビジョンやコンセプトの要素は、 ジョンやコンセプトを明記します。プロダクト プロダクト戦略から導き出されます。あるいは のビジョンは、その製品の根幹となる魅力を継 逆に、ビジョンやコンセプトからプロダクト戦 続的に提供するための表現言葉となります。 略が導き出される事もあります。 また、コンセプトは、ビジョンを実現するため ○ユーザコンセンサスモデルは、プロダクトのビ の主要技術・キャッチ的用語で表現されます。 ジョンコンセプト策定時に参考となるでしょう。 ◆プロダクト ステークホルダ分析 ・製品開発や企画・販売に関わる主要な利害 ○ステークホルダ分析と共通させて使用する 関係者を洗い出し、その特性を分析します。 ようにしても構いません。 ・先に説明した、ステークホルダ分析の中で 製品の開発・企画・販売に関わる主要関係 者の抜粋版となります。 ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 46 www.takumi-businessplace.co.jp
  • 47. ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ドキュメント概要説明(5) ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆業務モデル ・製品における企画・開発・販売の各プロセス ○企画・開発・販売など各部門の連携がうまく を見える化します。現状プロセスの場合は、 いっていないことが多くあります。業務プロ その問題点を明らかにします。 セスの現状と新規を描くことにより、組織の また、新規プロセスの場合は、改善効果を 抜本的改革を行うために活用します。 明らかにします。 ・製品企画・開発・販売における組織の全体 ○業務プロセスと同様に、現状と新規を描くよ ◆組織モデル 像を見える化します。 いでしょう。プロダクトビュー ◆製品体系図 ・複数製品系列や、複数製品を持つ場合は、 ○製品体系図は、様々な表現方法がありますが、 どこまでを本プロジェクトのターゲットと 利用の視点からカテゴライズされた体系図を するかを決定し、その範囲内にある製品に 記述することをお勧めします。 ついて、全体体系を見える化します。 ○機能体系図における機能名の欄には、細かな ◆機能体系図 ・個々の機能ではなく、機能をカテゴライズ化 詳細機能を入れないようにしましょう。 し、全体マップに入れていきます。その際に そもそも何をしたいのかという本質レベル 強化機能、新機能、廃止機能等の分類も行い で機能をまとめて、機能概念(大くくりの機 ます。 能)を考えてみてください。あるいはあるカ テゴリの代表的機能を、キー機能として登場 させてもよいでしょう。 ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 47 www.takumi-businessplace.co.jp
  • 48. ◆…匠オリジナルモデル 説明 ◆…一般的なモデルを拡張 ドキュメント概要説明(6) ◆…一般的なモデル ドキュメント名 説 明 書き方ポイント ◆プロジェクトビジョン ・プロジェクトメンバーの想いをビジョンとして ○プロジェクトのビジョンは、想い図から参考に /ミッション ・ 表します。これには、プロジェクトを実施する します。 想いが中心となりますが、プロダクトに関する ○プロジェクトミッションは、ゴール記述や、 想いが入っても構いません。 要求分析ツリーを参考にします。 一方、ミッションは、ゴール記述の中で代表的 なものをミッションとします。 ◆想い図 ・プロジェクトに参画するメンバーのプロ ○ここで使われる想いの領域のカテゴリー ジェクトおよび製品に対する想いを見え は重要です。これに併せて問題・課題を る化します。 このカテゴリーで分類することも行いま す。 ○想いのモデルは、ビジョン形成に役立てます。プロジェクトビュー ◆要求分析ツリー ・問題エリアには、プロジェクトで取り扱 ○要求エリアは戦略、業務、ITとできるだ うべき本質的問題を記述します。 け繋げるようにします。 ・プロジェクト課題エリアは、プロジェクトで ○要求は10~25が適切。あまり数が 取り扱うタスクとなるテーマを記述します。 多くなると本質が理解できなくなります。 ◆ゴール記述書 ・プロジェクトとしてのゴールを約束事として ○ゴールは、3段階程度に期間を分類すると 記述します。 よいでしょう。 1.プロジェクトオーバービュー策定段階 2.プロジェクト企画完了段階 3.システム開発完了段階 ※匠Method for Product イントロダクション編より抜粋 Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 48 www.takumi-businessplace.co.jp
  • 49. www.takumi-businessplace.co.jp 匠には誰もがなれるわけではない 匠を目指そうとするものだけに、その権利は与えられるお問い合わせ: hagimoto@takumi-businessplace.co.jp Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 49 www.takumi-businessplace.co.jp