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.

Proposal to Openthlogy 2.0

5,712 views

Published on

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

  • Be the first to comment

  • Be the first to like this

Proposal to Openthlogy 2.0

  1. 1. Openthology Ver.2.0 への提言 細川 努 牛尾 剛
  2. 2. はじめに 本講演は現在のOpenthology1.0の課題を分析し、  Openthology2.0の要望事項と解決案をまとめたも のである。 あくまで細川&牛尾の意見であり、Openthology2.0  へ向けては理事含めて、皆さんのご意見を広く承りた いと思います。
  3. 3. 本日のアジェンダ Openthlogy1.0の復習  Openthlogy1.0の課題  課題の分析  解決策(案) 
  4. 4. 要求開発アライアンスの Openthologyとは 要求開発アライアンスは、“ビジネス的価値を生み出す情報システムのシステム  要求”はどのように開発されるべきかを実際のシステム構築経験や工学的見地 から総括し、実践的手法に昇華させることを目指しています。 要求開発アライアンスが整備を目指す要求開発方法論、「Openthology(Open  Enterprise Methodology:オープンソロジー)」は、ビジネス的要求をシステム要 求に変換するためのシステマティックなアプローチとともに以下の方法を提供しま す。 ◦ 戦略的IT化を推進するための組織形成やプロジェクトの構成方法 ◦ 経営課題やビジネス要求を構造的に分析する方法 ◦ ビジネスの構造やメカニズムを視覚化する方法 ◦ ステークホルダーの合意を形成しつつプロジェクトを推進する方法 ◦ 企画したシステムによるビジネス的価値・効果の検証方法 ◦ ビジネス要求とシステム要求のトレーサビリティの管理方法 要求開発アライアンスホームページより ビジネス要求をシステム要求に変換するための システマティックなアプローチをもつ要求開発方法論
  5. 5. 要求開発ってなんだっけ? 家を建てることに例えるなら モデル 間取り 収納 将来は? 予算は? 発 注 要件を 老後… 防犯 採光性? 通気性? 確定 建築状況の確認 引き渡し前に 設計士に どんな家を 自分の家への 設計・検証 確認 要求を決める しっかりと 欲しいのか 要望を 要求を示す 家族で相談 しまった! しっかり確認 △◎×?! しておかないと
  6. 6. 要求開発Openthologyモデリング全体像 ビジネス構造をしっかりとモデルで示します 要求開発 立案フェーズ デザインフェーズ cd 論 理モデ ル 0..* 1..* 0..* 0..1 1 0..* ビジネス戦略 高 概念クラス図 理想のモデル (ToBe) ad ア クティビ ティ 業務 開始 終了 ビジネスの 情報 抽象度 現状のモデル システム基本要求書 概念ビジネスフロー図 (AsIs) ud ユ ー スケー スモデ ル ud ユ ースケースモデル 実現可能なモデル (Realize) ビジネスユースケース ビジネスユースケース ad ア クテ ィビ ティ ad ア ク テ ィビ テ ィ ad ア クテ ィビ ティ 業務 業務 ad ア クテ ィビ ティ ad ア ク テ ィビ テ ィ 低 業務 ad ア クテ ィビ ティ 業務 業務 開始 終了 開始 業務 終了 開始 終了 開始 システム 終了 開始 終了 システム 開始 終了 システム システム システム システム システム システム システム システム システム システム 現状ビジネスフロー図 IT戦略ビジネスフロー図 6
  7. 7. システム開発Openthologyモデリング全体像 要求開発 システム開発 デザインフェーズ 方向付け/推敲/構築/移行/評価 cd 論 理モデル シフトフェーズ cd 分析クラス図 0..* 1..* 0..* 0..1 0..* id コ ンポーネントモデル 1 0..* 1..* 0..* パッケージ 0..1 パッケージ 高 パッケージ 概念クラス図 分析クラス図 パッケージ図 cd 設計クラス図 ud ユ ースケースモデル a d ア クティ ビティ 業務 開始 終了 ビジネス 情報 ITの抽象度 システム 概念アクティビティ図 システムユースケース 基本要求書 設計クラス図 図 ud ユ ースケースモデル ? 実現可能なモデル sd 相 互作用 (Realize) 論理 モデ ル:: 論理 モデ ル:: 論理 モデ ル:: 論理 モデ ル:: 論理 モデ ル:: 低 シーケンス図 ad ア ク テ ィビ テ ィ 業務 ad ア ク テ ィビ テ ィ ビジネスユースケース 開始 業務 終了 システム 開始 終了 dd コ ンポーネントモデル システム システム Node1 Node2 システム Component 2 Component3 IT戦略アクティビティ図 Component4 配置図 7
  8. 8. Openthology構造とモデル 戦略とサービス構造中心でモデル化  ◦ ビジネス戦略からプロジェクト戦略へ ◦ 業務のサービスの明確化 企業の意思決定層とビジネスオペレーション層の構造を確立(見える化)  ◦ 企業の意思決定層の戦略を、ビジネスオペレーション層のサービスまで具体 的に落とし込むメソッドを持つ。 ビネ戦 ジス略 ビネ ジス ビ ジ プセ構 ロス造 サビ構 ース造 情構 報造 ネ ス オジク ブェト ビネ・ロス ジスプセ ビネ要 ジス求 モル デ シテ要 スム求 デタ ー アリーョ・ロス プケシンプセ I モル デ T シ ス アリーョ プケシン テ ム フーワク レムー 実アキクャ 装ーテチ
  9. 9. Openthology目標の成績表 目標 成績 対応するツール 備考 ビジネス要求をシステム要求 おしい ブロセスセル/プロセスキャビ システマティックなアプローチ に変換するシステマティック ネット が明記されているが、前提条 なアプローチ 件がある(初心者が厳しい) 組織形成やプロジェクト構成 未達成 明確なものはなし 経営課題やビジネス要求を 良くでき 要求分析ツリー、BSC戦略マッ 構造的に分析する ました プ、IT貢献度マップ、問題分析 ツリー、ビジョン分析ツリー ビジネス構造やメカニズムを 良くでき TFP分割図、アクティビティ図、 視角化する ました LFD、概念モデル、ビジネスユ ースケース図 ステークホルダーの合意を形 未達成 明確なものはなし コタツモデルなどのコンセプト (各種ダイヤグラムやゴール記述) 成しつつプロジェクトを推進 はあり する ビジネス的価値、効果の検証 おしい ゴール記述書、BSC戦略マップ 目的-手段の連鎖による価値 、IT貢献度マップ の検証はできるが、効果の検 証はあまりできていない 要求のトレーサビリティ おしい BSC戦略マップ、IT貢献度マッ ビジネスと要求のつながりのツ プ、要求分析ツリー、問題分析 ールは多いが、ビジネス要求 ツリー、ビジョン分析ツリー、要 からシステム要求へつなぐ方 求リスト、アクティビティ図… 法は明示されていない
  10. 10. 解決案 Openthology 2.0
  11. 11. 解決案 こ が わ? こ変る Opent hology Openthology 2.0 Openthologyの体系をシンプルにして 初心者にもわかりやすくしよう 思い切って 本当に大事なところに絞って 他はオプションにしてはどうかな?
  12. 12. 解決案 こ が わ? こ変る Opent hology Openthology 2.0 UMLがわからない人でも 要求開発ができるようにするには… 使う場面を想定してカスタマイズし た手順(レシピ)を作りたい…
  13. 13. 解決案 こ が わ? こ変る Opent hology Openthology 2.0 フロントローディングの具体化 業務要求だけでなく 非機能要求も大事だよ アジャイルな 要求開発
  14. 14. 解決案 こ が わ? こ変る Opent hology Openthology 2.0 みなさまの支持あっての 要求開発でございます。 ヤル気があれば なんとかなる! あとは 勢いでガンバる!
  15. 15. Openthology2.0 要求リスト 番号 要求 優先順位 顧客満足度 顧客不満足度 ReDA01 初めての人でも流れがわかること 3 5 4 ReDA02 初めての人でも要求開発の成果物や要件 1 5 5 定義/基本設計へのつながりがわかること ReDA03 初めてのひとでもある手法の代替え手段が 4 5 3 わかること ReDA04 カスタマイズが容易であること 5 3 5 これを決め ReDA05 作業の重要度がわかること 6 3 5 7 ましょう ReDA06 下流の要求開発にも対応すること 3 5 ReDA07 具体例がわかること 2 5 5 ReDA08 アーキテクチャや非機能要件を考慮するこ 11 3 3 と ReDA09 フロントローディングを具現化すること 12 3 3 ReDA10 検証の方法を考えること 8 3 4 ReDA11 ステークホルダ毎に整理すること 9 4 3 ReDA12 マーケティングを強化すること 10 3 4
  16. 16. Openthology2.0 ゴール記述 何を どうすることで 何が いつまでに どうなる 評価尺度 手法を 再整理する 初心者が 2007/06 Openthologyを 2.0βを説明され 理解できるよう た人へのアセス になる メントの平均点 が20%向上する 非機能要件 整理する フロントローディ 体系化する ング これを決め ましょう
  17. 17. Openthology2.0 ロードマップ案 時間がかかってもいいから、 完成度を高くしたいね 2.0本執筆作業? Webコンテンツ整備 対外アピール テーマ別作業 全体構想具体化 2007/12 2008/2 2008/8 2009/2 2009/3 現在 合宿 合宿 完成宣言 合宿 - 全体構想の合意 - 全体レビュー - 最終レビュー - 作業分担の決定 - β版完成
  18. 18. 要求開発の流れの整理例 参考 主要成果物 EA 要求工学 準備 前 ビ 提 ジ ネ ビジネス戦略を確認する ゴール 要求分 課題 ス 記述書 析ツリー リスト ・ ア IT達成目標を確認する ー キ 立案 ビジネス テ 方 ニ ビジネス ユース ク 向 ー サービス構造を確認する(As-Is) チ 概略図 ケース づ ズ ャ け 分 図 析 業務 概念 ビジネス 分 フロー モデル ルール 析 情報構造を確認する(As-Is) プロセス構造を確認する(As-Is) 非プロセス要素を確認する(As-Is) 非機能要件を確認する (As-Is) (As-Is) リスト 改善・変革ポイントを分析する 啓 発 ビジネス デザイン 方 サービス構造を策定する(To-Be) ビジネス ユース 向 概略図 ケース づ け 図 業務 概念 ビジネス 分 情報構造を策定する(To-Be) プロセス構造を策定する(To-Be) 非プロセス要素を策定する(To-Be) フロー モデル ルール 析 (To-Be) (To-Be) リスト 課題 狙いと改善・変革ポイントの実現性を確認する 解決 啓 リスト 発 移行 ーア 要 キプ 求 テリ RFPを作成する 要件定義を行う 仕 RFIを作成する 要件 クケ RFI RFP 様 チー 定義書 化 ャシ or or ョ 課題・申送り事項を整理する ン ・ ア
  19. 19. 参考 要求開発の基本的な流れ 目的・課題・要望の分析 プロジェクトでやることと目的の探索 プロジェクトの目的と範囲とゴールの設定 目的と範囲の設定 業務プロセスの分析と新業務のモデル化 業務プロセスの分析 プロジェクト対象業務の概念の整理 静的構造の分析 要求の整理とシステム化 要求リストアップと整理と取捨選択 範囲の策定 19
  20. 20. 参考 要求を抽出する5つのルート ToBe業務フロー 目的分析 一番主体 課題分析 揺さぶり 要望分析 要求 20
  21. 21. 参考 プロセスフレームワークの全体像 プロセスフレームワーク 内容 目的の構造を分析する 目的分析 目的・課題・要望の分析 課題を分析する 課題分析 要望を分析する 要望分析 プロジェクト目的を決定する プロジェクト目的の策定 目的と範囲の設定 プロジェクトのゴールを設定する ゴール分析 プロジェクトの範囲を決定する プロジェクト範囲の決定 プロジェクトのステークホルダを決定する ステークホルダ分析 機能やサービス構造を分析する サービス構造の分析 プロジェクトの効果を分析する 効果分析 業務フローを分析する 業務プロセスの分析 概念構造やデータ構造を分析する 静的構造の分析 分析結果から要求を抽出します 要求のリストアップ 要求の整理とシステム化範囲の 策定 モデルにより要求に抜け漏れや無理がな 要求の揺さぶり いか検討する IT化後のイメージを可視化し検証する ITイメージとリスクの軽減 必要な要求を取捨選択する Mamezou Co., Copyright © 2007 要求のトリアージ 21 Ltd. All right reserved.
  22. 22. 参考 目的分析 説明  ◦ 目的の構造を分析する ◦ プロジェクト目的と企業戦略のつながり、目的と要求の関連、目的を達成 するために必要な手段の分析を行う 用途  ◦ プロジェクトのゴール設定に用いる ◦ 目的を達成するために必要な要求を分析する ◦ 要求と企業戦略のつながりを見る 手法  ◦ BSC戦略マップ ◦ IT貢献度マップ ◦ ビジョン分析ツリー ◦ 要求分析ツリー 22
  23. 23. 参考 目的分析に使われる手法 他手法の人が要 求開発を理解/活 名称 説明 使い分け 備考 用しやすくなるから 目的からブレークダウンして、解決策を 他手法と比べると最もシンプル 目的ー手段の連鎖を ビジョン分析ツリー 探索する手法 な手法 見たい場合は簡易な 経営戦略までさかのぼる必要が 要求ツリーを作ること ないケース 難易度が最も低い BSC(バランスドスコアカード)のフォー 経営戦略と整合性をもったITシ IT貢献度マップとセット BSC戦略マップ マットに既存の戦略をマップして確認す ステム企画を行いたいケース で使われる 要求開発以外 る手法 の手法も提示 する BSC戦略マップで見える化した戦略に 経営戦略と整合性をもったITシ BSC戦略マップとセッ IT貢献度マップ 対してITをどのように活用するか見える ステム企画を行いたいケース トで使われる 化する手法 上位の要求(利益の拡大など)から細 BSCとビジョン分析ツリーの中 目的分析に加え課題 要求分析ツリー かい要求までを目的ー手段の連鎖によ 間レベル 分析、要望分析も同時 って系統だてて整理したもの 戦略と整合性をとりつつプロジェ に分析することができ クトの方向付けをしたい場合に る 使用される 23
  24. 24. 参考 ライトウェイト型のプロセスレシピの例 ゴール記述書作成 業務目的の確認 アクティビティ図(As-Is)作成 ビジネスコンテキスト図 ビジネスユースケース図の作成 アクティビティ図(To-Be) コスト分析作成 問題分析ツリー作成 TFP分割図(To-Be)作成 要望分析シート作成 RFP作成 要件リスト作成 ビジョン分析ツリー 要求分析ツリー(小)作成 システム開発 ITイメージの確認 ● 24
  25. 25. 参考 その他のトピック 管理プロセスとモデリングプロセスの分離  ◦ ファシリテーションや心構えなども含む バリエーション毎の整理  ◦ 上流要求開発/下流要求開発(山岸さん) ◦ ステークホルダー毎の整理(石沢さん) 非機能要求/アーキテクチャ  フロントローディングの具現化  評価/検証  Openthology Ver.2.0

×