要求開発から見たテストの捉え方 株式会社 豆蔵 萩本 順三 自己紹介 – 株式会社豆蔵 取締役 – 内閣官房 情報通信技術担当室 電子政府推進管理局 （GPMO）補佐官 萩本 順三 • 前社では、オブジェクト指向開発を行うチームＯＴＧ（オブジェクトテクノ ロジグループ）を設立 オブジェクト指向開発方法論 Drop • • さまざまなアプリケーションツールをオブジェクト指向にて開発 分散オブジェクト環境HORB ver2.x開発リーダー • 要求開発アライアンス幹事 • • • • • ＜著書、翻訳書、参考URL＞ 「初歩のUMLモデリング」（技術評論社） 「やさしいJavaプログラミング」、「最新オブジェクト指向技術応用実践」（エーアイ出版）。 「Java と UML で学ぶオブジェクト指向の考え方」（監訳 ／翔泳社）、「HORBではじめるJava • • • 分散オブジェクトプログラミング」（秀和システム）。 「 Web連載【改訂版】初歩のUML(http://www.atmarkit.co.jp/fjava/devs/renew_uml01/renew_uml01.html)」 「 Web連載 ＩＴエンジニアとしての道を究めるには (http://jibun.atmarkit.co.jp/lskill01/rensai/hagimoto01/hagimoto01.html)」 その他、Java、方法論、分散オブジェクト技術に関する雑誌記事や講演多数。 • 目次 • • • • 要求開発の意義 真の品質向上とは、真の生産性向上とは 要求開発方法論Openthologyの概要 フェーズ概説 要求開発の意義 要求は「開発」するもの • 「要求分析」、「要求定義」などは、要求がすで に存在しているという前提に立っている • ユーザからヒアリングした要求の実現が業務効 率化に結びつくとは限らない。 • 要求は、利害関係者により業務の最適な姿を 分析する過程で開発される。 なぜよいシステム開発ができないのか？ – 最悪のシナリオ 業務理念を統制し、業務効 率化を図るための業務とは ○○あるべきだよ。 ビジネスオーナの論理 あの業務は、○○パッケージや ○○フレームワークを使って開発 すれば簡単だよ。 業務は、それにあわせればいい。 システム開発者の論理 壁 我々のやり方がベストなん だ。これにあわせてシステム を作ってくれよ。 業務担当者の論理 それは、正しいシステム要求がだせ ないから • うまくいきそうで駄目なシナリオ（その１） – トップ・業務管理者の考えどおりのシステムを作ったが、業務担当から大クレーム。 – 結局使われないシステムになった。 業務理念を統制し、業務効 率化を図るための業務とは ○○あるべきだよ。 ビジネスオーナの論理 わかりました。おっしゃるとおり、 業務効率化案に基づいた要求を 考えていきましょう。 壁 あの取締役、業務の事をな にも分かっていないんだよ ね。 でも、あの人のいう こと本当にただしい のかなあ？ まあ、いっか。 システム開発者の論理 業務担当者の論理 それは、正しいシステム要求がだせな いから • うまくいきそうで駄目なシナリオ（その２） – 業務担当者からそれぞれ要求を聞きだした。 » 業務の標準化ができない。 » 効率化を考慮していない業務にあわせ てシステムを作ってしまう。 業務理念を統制し、業務効率化を図るた めの業務とは○○あるべきだけど、業務 担当は、みんな既存システムのやり方に 慣れてしまって本当に改善しようとおもっ ていないんだ。 ビジネスオーナの論理 分かりました。業務担当の方々 に合わせて、システムを開発しま す。 だけど、それぞれの 担当者から出てくる 要望を開発するのは 大変だよな。 ま、いっか。 システム開発者の論理 壁 我々のやり方がベストなん だ。これにあわせてシステム を作ってくれよ。 業務担当者の論理 要求開発とは – 正しい要求の獲得と合意のための活動 業務理念を統制し、業務効率化を図るため の業務とは○○あるべきだ、しかし現実は △△だから、それをどう改善できるか現場と 話し合ってみよう。 ビジネスオーナの論理 あの業務は、○○パッケージや○○フレー ムワークを使って開発すればよさそうだ、し かし、本当に求められている業務の姿を明 確にして３者で合意しなければ、真の要求 など獲得できるはずがないね。 システム開発者の論理 問題の視覚化(モデル)と 改善プロセスによる活動 開発された要求 （システム要件） 我々のやり方がベストだと思っていたけど、 見方を変えれば欠点が多いね。問題分析ツ リーでもう少し業務のあるべき姿を考えてみ よう。 業務担当者の論理 コタツ モデル 要求開発活動組織 • チーム構成とミッション（例） 要求開発推進チームのミッション 要求開発組織 ファシリテート （支援）する 要求開発全体を計画し、現状 要求開発全体を計画し、現状 分析からシステム開発の完了 分析からシステム開発の完了 まで、プロジェクト全体が成功 まで、プロジェクト全体が成功 裏に終わらせる責任を持ちま 裏に終わらせる責任を持ちま す。 す。 ファシリテート （支援）する 要求開発 推進チーム ITチーム 業務チーム 協働する 業務チームのミッション 新しいシステムに対する要求を、迅速かつ適切に引き 新しいシステムに対する要求を、迅速かつ適切に引き 出し、開発チームに提供ことに責任を持ちます。そのた 出し、開発チームに提供ことに責任を持ちます。そのた めに必要な現状分析や将来のビジョンを捉え、ヌケモ めに必要な現状分析や将来のビジョンを捉え、ヌケモ レ・ダブリなく要望を取り上げます。 レ・ダブリなく要望を取り上げます。 ITチームのミッション 業務が捕らえた要望を適切にシステム要求として受け取り、シ 業務が捕らえた要望を適切にシステム要求として受け取り、シ ステムとして提供することに責任を持ちます。 ステムとして提供することに責任を持ちます。 開発時には複数回のイテレーションを繰り返し、要求の曖昧さ、 開発時には複数回のイテレーションを繰り返し、要求の曖昧さ、 見えない真の要求解明に、BMTと共に責任を持ちます。 見えない真の要求解明に、BMTと共に責任を持ちます。 ビジネスシステムにおける要求開発 （例） 責任者 推進役 要求開発チーム 統括責任者 推進チーム ・ナビゲータ ・アドバイザ ・標準化担当 オブザーバ レビューア 相談役 業務チーム ＩＴチーム ビジネスオーナー IT可視化 実施者 業務可視化 実施者 毎週：要求開発チーム運営会議 毎月：要求開発成果報告 製品開発における要求開発（例） 責任者 要求開発チーム レビューア 相談役 統括責任者 推進チーム オブザーバ ・ナビゲータ ・アドバイザ ・標準化担当 企画・営業チーム ＩＴチーム ビジネスオーナー IT可視化 実施者 推進役 業務可視化 実施者 毎週：要求開発チーム運営会議 毎月：要求開発成果報告 要求開発にて必要とされるスキル • 要求開発組織は、繰り返し行うビジネス改善・視覚化を含む要 求開発活動の中で、徐々にチームとしての能力を育んでいくと いう目標を持ちます。 防 御 折衝力 プロジェクトが危機に陥った時に、問題要因を取り払うため に問題を勃発させた関係者らの問題を解決するよう動く 前進 場の形成 要求開発組織 プロジェクトの進むべき方向性を与え、それに向かって チームが突き進むための先導的役割を担う ファシリテーション力 プロジェクトメンバーが、進むべき道を自ら見つけ られるような背後支援と自主的活動場の形成 プロセス推進力 浮 力 メンターリング能力 裏打ちされた技術力によって参加メンバーの基礎技術 （体力）を支える ビジネス・ITの表と裏（実は表は表でもある） エンジニアはこの事を強く意識すべし！ オペレーション 課題 ビジネス 表（価値） ビジネス課題 裏（実現） ビジネス オペレーション 表（価値） システム 裏（実現） システム要求 表（価値） システム設計 裏（実現） 見えない壁それは分割・分業の副作用 （見えない壁を突き破る仕組みが必要） 要求開発ステージ ビジネス 課題 ビジネスオーナ 価値のある 戦略 ビジネス オペレーション システム開発ステージ システム 要求 ビジネス実施者 要求分析者 最適なビジ ネスオペ レーション 合意された 非機能要求 機能要求 ビジネスオペレー ションの根拠は？ システム要求 の根拠は？ 設計 アーキテクチャ アーキテクチャ の根拠は？ 実装 設計者 実装者 設計による 解法 実装 の根拠は？ 要求はどうにでも定義できる！ ビジネス戦略 最適解はどれだ！ ＩＴによる付加価値注入 問題解決 現場の問題解決 戦略を選ばずして、要求は決まらず 戦略のトリアージ オペレーション 課題 ビジネス ビジネス戦略 システム システム要求 ビジネス戦術 トリアージさ えれた戦略 改善・改革が必 要な業務処理 トリアージ（triage）：要求を戦略的に取捨選択する事。 もともとは医学用語で、有限のリソース（医師や医薬 品など）を最大限に活用し、各患者の病状や状況に 合わせて、より多くの傷病者の治療をするために優 先順位を決定することを指す。 トリアージされ た要求 参考：発刊予定書籍 「成功する要求仕様、失敗する要求仕様」日経ＢＰ アランＭデービス著、安井・萩本監訳、高嶋訳 要求開発の現場 • プランの見える化 – まず、仮説的な活動プランでもいいので、見える化す る（要求開発方法論を利用）。 – 日々の活動のゴールを定め、ゴールに向かうシナリオ を見える化する。 • 活動の場（コタツモデル）の雰囲気を見抜き、活動 の場が活性化するために、あらゆる策をうつ。 要求開発の現場 • 活動の場のリズムを掴む – – – – – – – – 押しても駄目なら引いてみな！ たまには議論に負けることも大切 失敗を成功に繋げる 発散と収束を使い分ける リズミカルな場の盛り上げ方 話し方に強弱をつける 全員参加型にする（狭い部屋） 客観性（問題解決）、主観性（モチベーションアップ）を 使い分ける • 参加者の脳を刺激する（気づき）よう努力する – （なるほど～、へえ～） 要求開発（見える化の） 大変な事、実は大変じゃない事 • 大変な事 – 落とし前をつける – 覚悟をする – 要求獲得を遅らせる際のマネジメント • 大変ではない事 – 見える化することで、みんなが分かっていな かった事を納得してくれる（いいねえ～～） – その間に業務を学べる 真の品質向上とは 真の生産性向上とは ソフトウェアの品質の向上 • 失敗するソフトウェア品質の向上 –要求を正しく作る。 • 正しくない要求を正しく作る可能性。 ソフトウェアの品質の向上 • 成功するソフトウェア品質の向上 – ビジネスにとって価値のある要求につい て、正しく作りあげること。 開発生産性の向上 • 失敗する開発生産性の向上 – 決められた時間内に決められた予算枠で 要求を無理やり定義し、その要求を実現 する開発の生産性を高める。 • 価値が無いものを早く作り、不良ＩＴ資産を増 やす可能性 開発生産性の向上 • 成功する開発生産性の向上 – ビジネスにとって価値のあるシステムだけ を開発することで、下記を実現する • 企業における開発組織全体のスループットを 向上させる事 • 不良ＩＴ資産を増やさず、スピーディなビジネ ス変革に対応できるようにする事 要求開発方法論 Openthologyの概要 要求開発アライアンス http://www.openthology.org/ ■参考書籍 「要求開発」 日経ＢＰ 「戦略的要求開発のススメ」 翔泳社 要求開発アライアンス著 安井昌男 Openthology構造とモデル Openthology • 戦略とサービス構造中心でモデル化 – ビジネス戦略からプロジェクト戦略へ – 業務のサービスの明確化 • 企業の意思決定層とビジネスオペレーション層の構造を確立（見 える化） – 企業の意思決定層の戦略を、ビジネスオペレーション層のサービスまで 具体的に落とし込むメソッドを持つ。 ビジネス戦略 ビジョン：ゴール構造 ビジネス オペレーション ビ ジ ネ ス I T シ ス テ ム プロセス構造 ビジネス・プロセス アプリケーション・プロセス サービス構造 ビジネス要求 システム要求 アプリケーション フレームワーク 実装アーキテクチャ 情報構造 オブジェクト モデル データ モデル Openthology構造とモデル Openthology ユースケース記述 業務フロー（アクティビティ図） ユースケースモデル ビジネスユースケースモデル ビジネス戦略 BSC戦略マップ ビジネス概念モデル 分析・設計モデル クラス図 ビジョン：ゴール構造 DB モデル ビジネス ビ ジ ネ ス I T シ ス テ ム プロセス構造 サービス構造 ビジネス・プロセス ビジネス要求 アプリケーション・プロセス システム要求 アプリケーション フレームワーク 実装アーキテクチャ 情報構造 オブジェクト モデル データ モデル 開発プロセスオーバービュー 広義の要求開発（要求定義） 狭義の要求定義 ＢＤＡ 経営分析 要求開発 広義のシステム開発 ビジョン、ミッションの 確立 問題点分析 準備 立案 デザイン 移行 狭義のシステム開発 システム開発 ビジネスゴール設定 ビジネスユースケース 財務的解決やマーケ ティング的解決で終わ る課題もある 業務フロー（As-Is、To-Be) 業務レベルの概念モデル ビジネス戦略の見 える化、プロジェク トスコープとリソー スを確定しゴール を明確化。 システム化範囲の導出 ロードマップ作成 システムユースケースの 抽出と個別プロジェクト へのブレークダウン 方向付け 推敲 構築 移行 第１ プロジェクト 方向付け 推敲 業務要求の獲得 とプロセスの見え る化、ITの基本要 求の獲得。 構築 移行 第２ プロジェクト 方向付け 推敲 構築 移行 狭義のプロジェクト 第３ プロジェクト 広義のプロジェクト 要求開発プロセス（プロセスキャビ ネット）のイメージ 段階的に詳細化・具体化していく Phase： Disciplines 準備 立案 Plan デザイン シフト 作業項目名 作業項目名 Do P P P D D D D C C C C A A A A P Check Act 要求開発のフェーズ 準備 ■スコープとリソースの決定 ・ビジネス戦略の把握とプロジェクト課題の見極め ・必要人材のアサイン 立案 ■概観の把握と可視化 ・プロジェクト課題にスコープしたビジネス領域の可視化 ・ビジネス要求の抽出 デザイン シフト ■ToBe業務の設計 ・ToBe業務の設計 ・IT基本要求の開発 ■システム計画 ・IT基本要求の抽出 ・システム移行計画書の作成 実際のプロセスキャビネット 要求開発プロセスキャビネット 段階 初期知識の可視化と合意に基づく計画 Phase 準備 arrangements Decipliens 計画 Action デザイン design シフト shift ・概観ビジネスモデリング ・ビジネスToBeモデリング ・システムToBeモデリング ・ビジネス要求の開発 ・IT基本要求の開発 ・IT基本要求の開発 ・プロトタイプ開発 ・プロトタイプ開発 ・システム移行計画書作成 ・承認権限者による検証 ・メンバー責務・スキルの確認 ・モデリングの評価（Option） ・ビジネス課題の評価 ・教育実施評価 ・承認権限者による検証 ・プロジェクトミッションの評価 ・モデリング戦略評価 ・概観ビジネスモデリング評価 ・承認権限者による検証 ・ビジネスToBeモデルの評価 ・IT基本要求の評価 ・プロトタイプの評価 ・システム基本構想の評価 ・承認権限者による検証 ・システムToBeモデルの評価 ・IT基本要求の評価 ・システム移行計画書内容の評価 ・計画の見直し・改善 ・メンバー構成の見直し ・教育計画の再計画 ・必要であればビジネス課題の理解のやり 直し ・メンバー構成の見直し ・必要であれば、再教育を期間を検討する ゼ ・計画の見直し・改善 ・構想の見直し・改善 ・すぐやるカイゼン ・計画の見直し・改善 ・構想の見直し・改善 ・すぐやるカイゼン ・計画の見直し・改善 ・すぐやるカイゼン ・要求開発プロセスのカスタマイズ ・実施計画書作成 ・コアメンバー教育 (Option) ・動機付けセミナー(Option) ・教材の作成(Option) システム化 Check 立案 draft ・フェーズ基本計画 ・システムToBeモデルの評価方法の策定 ・IT基本要求の評価方法の策定 ・システム移行計画書達成評価基準の明 確化 要求モデル 教育 システム開発への移行 ・フェーズ基本計画 ・ToBeモデルの評価方法の策定 ・IT基本要求の評価方法の策定 ・ビジネス可視化プロトタイプ計画 の見直し ・システム基本構想策定計画 ・ビジネス課題の理解 ビジネスモデル ・プレビジネスモデリング(Option) Do 新ビジネスのデザイン ・フェーズ基本計画 ・モデリング戦略策定 ・ビジネス要求評価方法の策定 ・教育計画の作成 ・ビジネス可視化プロトタイプ計画 ・システム基本構想策定計画 ・フェーズ基本計画 ・要求開発プロジェクトのゴールの設定 ・要求開発チーム編成計画 ・準備教育計画作成 Plan ビジネス課題に関する概観の可視化 ・要求開発メンバー教育 プロセスセル • プロセスキャビネットからPDCAの単位に活動をまとめ成 果物と一緒にまとめパターン化したもの 例）準備フェーズのプロセスセル START 名前 目的 END Plan 準備ベース アクティビティ（活動） 情報の入出力 チーム編成 要員「準備教育」 準備教育計画作成 コアメンバー教育 (Option) 動機付けセミナー(Option) 教材の作成(Option) Check 教育実施評価 Do Act 成果物 アクテビティ名 要員「準備教育」プロセスセル コアメンバーの教育・トップへの動機付けセミナー メンバー構成の見直し 必要であれば、再教育を期間を検討する 教材(Option) 教育アンケート 入力 経営計画・システム開発計画 出力 プロジェクトメンバースキル表 要員「準備教育」プロセスセルの内容 要求開発標準プロセスセルリンク フェーズにおけるＰＤＣＡマイルストーン 準備フェーズ 立案フェーズ デザインフェーズ シフトフェーズ END 準備ベース 立案 ベース システムシフ トベース デザイン ベース 要求開発メンバー教育 ビジネスToBe IT基本要求開発 モデリング 概観ビジネス ビジネス要求 システム 基本構想案 モデリング 開発 システム基 本構想 フロントローディング開発（立案） チーム編成 要員「準備教育」 活動単位のPDCA (プロセスセル) フロントローディング開発 システムToBe モデリング IT基本要求定義 システム 移行計画作成 フェーズ概説 可視化・可視化と言うけれど （準備フェーズで行うべきこと） 金・時間（リソース） ビジネス戦略マップ(BSC) 範囲（スコープ） 人材（リソース） N O 何をすることで 何が いつまでに どうなるのか 評価尺 度 目 標 値 重要度 がS, A の要望 で未判 断の要 望数 0 件 1 窓口(営業・ＣＳ)が要望の重要度を判断することで 重要な要望が 2006年5月 プロジェクト統括で判断され、 結果として重要な要望が早期 に実現される 2 プロジェクト統括（ノア）で要望を判断することで 積み残した要求の数が 2006年7月 整理され、結果として計画的 に要求が対応されるようにな る 要求 (L2)の 数 2 0 0 件 3 実現イメージを作成し、起案部署に確認することで 要望の実現方法が 2006年5月 合意され、結果として機能の 作り直しの件数が減り開発ス ピードが向上する 未確認 の要件 （L3）数 0 件 4 企画の判定会議を実施することで 企画が 2006年5月 判断され、結果として現場と トップの合意が得られる 未判断 の開発 着手数 0 件 5 新しい要望ＤＢを構築することで 要望の情報共有が 2006年５月 滞りなく運用されている 利用し ている 開発 チーム 数 全 ソ フ ト 開 発 チ ー ム プロジェクトゴール 記述書 準備フェーズ 経営方針 社是など ミッション ビジョン ブレークダウン (手段) 企業全体としての 具体的な目標 中期経営計画など 年度経営計画など (手段) 個々の目標 (手段) 個別の タスク ブレークダウン 年度経営計画など ブレークダウン 部門年度計画など 事業計画など (手段) システム システム ・計画がブレークダウンされて 「手段の連鎖」を構成しているか 確認する ・目標値の設定を確認する 準備フェーズ BSC戦略マップ 収益源の増大 売上げの増（3年後に110%) 売上げの増（3年後に110%) 生産性の向上 財務の視点 財務の視点 海外の売上げ増（2倍) 海外の売上げ増（2倍) 顧客の視点 顧客の視点 国内外で同一レベ 製造ラインを半分にする 製造ラインを半分にする 国内外で同一レベ ルのサービス ルのサービス イノベーション 新製品を開発する 新製品を開発する 内部プロセス 内部プロセス の視点 の視点 顧客関係の強化 メインテナンス・レス メインテナンス・レス ポンスの向上(50%） ポンスの向上(50%） 拠点代理店の設置 拠点代理店の設置 コストの圧縮(10％ コストの圧縮(10％) ) 納期を圧縮(10%) 納期を圧縮(10%) 卓越した業務 製作工期の短縮(10%) 製作工期の短縮(10%) 据付工期の短縮 据付工期の短縮 調達日数の短縮(20%) 調達日数の短縮(20%) 調達費の削減(4%) 調達費の削減(4%) 準備フェーズ ユーザ事例 （戦略地図を描くことでゴールが見え、合意できる） イノベーション 顧客 業務改善 表面的な意識 トップダウン分析 ＢＳＣ戦略マップ （気付き） 表面的には、イノベー ション顧客に関心があ る。でも現状は業務問 題のみ。 内面的な意識 ボトムアップ分析 問題分析ツリー なぜか業務改善のみでてくる？ 準備フェーズ 業務詳細モデルを書く前に攻略点を特定セヨ （立案フェーズで行うべきこと） N O 何をすることで 何が いつまでに どうなるのか 評価尺 度 目 標 値 重要度 がS, A の要望 で未判 断の要 望数 0 件 要求 (L2)の 数 2 0 0 件 1 窓口(営業・ＣＳ)が要望の重要度を判断することで 重要な要望が 2006年5月 プロジェクト統括で判断され、 結果として重要な要望が早期 に実現される 2 プロジェクト統括（ノア）で要望を判断することで 積み残した要求の数が 2006年7月 整理され、結果として計画的 に要求が対応されるようにな る 3 実現イメージを作成し、起案部署に確認することで 要望の実現方法が 2006年5月 合意され、結果として機能の 作り直しの件数が減り開発ス ピードが向上する 未確認 の要件 （L3）数 0 件 4 企画の判定会議を実施することで 企画が 2006年5月 判断され、結果として現場と トップの合意が得られる 未判断 の開発 着手数 0 件 5 新しい要望ＤＢを構築することで 要望の情報共有が 2006年５月 滞りなく運用されている 利用し ている 開発 チーム 数 全 ソ フ ト 開 発 チ ー ム ゴールによるスコープ の絞込み 概観ビジネスモデリング ビジネ スアク ター ゴールに関係する箇所 についてAsIsを分析し、 ToBe要求と、ToBeモデル を描く。 ビジ ネス ユー ス ケー ス ○○社 商品を販売する 顧 客 プロジェクトゴール記述書 商品を仕入れる 関 連 メ ー エ カ ン ー ティ ティ サービス提 供体の範囲 を表す c d E コマ ー ス事 業 注文ル ー ル型 注文ルール型 * 商 品分類 仕 入先・ 商 品タ イ トル 関係 注 文ルー ル <<powertype>> 1 * 1 - - * 名称: 販売期間: 販売単価: * * 1 商 品タ イ トル * - 注文ルール型 送料計 算ルー ル * 名称: 仕入先 値引 きルー ル - 名称: 1 * 1 購 入商品タ イトル 顧客 - 1 - * 氏名: 住所: 電話番号: 1 注文 * - 注文年月日: + 1 非会員 顧客 注文時販売単価: 注文量: 消費税: 販売金額: 送料: 1 * 会員 - カー ド会社 決 済方法 1 + + 認証する() ID: パスワード: 有効期間: 認証する() 1 1 * 認証する() 0..1 決済方 法－ 個別 1 ポ イ ン ト加算 1 - ポ イン ト ポイント加算年月日: 加算ポイント: - 金額: + 認証する() * - 現ポイント数: 1 + 金額換算() 1 * 決済方 法－ポ イ ント利 用 * + 決済 方法＝現金 決済方 法＝カー ド ポイント利用年月日: 利用ポイント数: 金額換算() 立案フェーズ 要求とは？ 要求の生息地 • 開拓地に住む原住民 – 初めから企業ミッションの中に生息している、そもそも達成す べき最優先要求。 – いままでの業務の延長から見つかる要求。 – いままでのシステムの中に生息して、今後も必要となる要求。 • 未開の土地 – 業務改善により始めて姿を見せる要求。恥ずかしがりやで、 まだ形がはっきりとせず、個人の意識の中に眠っているので、 みんなで目に見えるように可視化しないと出てきてくれない。 • 暗黙知域 – 業務メンバーと開発メンバーの意識の中に暗黙知として眠っ ており、これが基で様々なトラブルを引き起こす。 要求開発における 要求の開発および獲得 • 要望 – 業務視点でだされた、ビジネスおよびシステムに対す る「XXXのためにXXXしたい。」といった要望。 • 要求 – 要求開発チームで、意味不明な要望、要望の重複排 除、似ている要望を整理することで要求に格上げされ る。 • 要件 – 期間コストを踏まえて、どのシステム開発で取り入れ るのか決定されたシステム要件。 * Featureとは、「要求の特性」あるいは「要求獲得時の初期の抽象表現」の意 要望-要求-要件への変化 トップ・品質管理 例： 「検査業務を早く、安く、正確に！」 管理者・品質管理（業界標準等） 例：管理者「 効率化を図るために、再測を止める」 品質管理「セキュリティのために、個人特定機能が必要」 ビジョン 方針 対策 目的 現場 例：担当者「業務ミスを犯さないために、二重チェックを行う」 個別方針 要望 （会議体で検討） ・重複を省く ･グループ分け ・重要度の管理 ・業務かシステムかの判断 ・要求の優先度付け ・目的に対する対策を分析 し、参加者の納得できる方 法を仕上げる。 要求 要件 業務要件 業務要求 （会議体で分析） ・システム化対象の選択 ・システム化実現方法の 選択検討と合意 ･リリース予定日の設定 0…＊ （会議体で分析） ・コンセプトの再確認 ・運用方法の確立 ・例外事象の洗出 ・システム利用方法 ・上記の標準化 システム要求 システム要件 要求 機能要求 ユースケース コンポーネント 非機能要求 アーキテクチャ IT Pro blog • 「ITPro Wacher」…これで検索してください。 – 要求開発（ビジネスモデリング道場） – 闘う要求開発ファシリテータ (1)---コタツモデル”を実践する (2)---“改心者”は最大の味方 (3)---成功させるための要求開発戦略 (4)---人の創造力こそが要求開発の原動力 (5)---要求開発方法論 まとめ • 要求を開発するということは ①戦略をコタツモデルでトリアージ ②次期ビジネスオペレーションを定め ③それを実現するＩＴ化要求の最適解を作り出す事 • 見える化の効果とは – 重要な部分を理解・合意できること – さらに次期の業務に対して覚悟をとりつける事 • 真の品質向上とは – ビジネスにとって価値のある要求について、正しく作りあ げる事 • 真の生産性向上とは – ビジネスにとって価値のあるシステムだけを開発する中で、 開発生産性を高める事
© Copyright 2026 Paperzz
