Próximos SlideShares
地図を片手にアジャイル開発
- 1. 地図を片手にアジャイル開発 規模が大きく納期や予算が厳しいエンタープライズ開発でアジャイル開発を行うために、必要な要件定義とは 2017/2/22
- 2. わたしは… ㈱バリューソース 代表取締役 社長 神崎 善司 zkanzaki@vsa.co.jp 要件定義の散歩道：https://www.facebook.com/youkennotsubo twitter：@zenzengood 要件定義手法の開発 RDRA Relationship driven requirement analysis 普段は システム企画・要件定義などの支援 セミナー開催（要件定義、モデリング） 要件定義用ツールの開発 要件定義との関係は オブジェクト指向を中心にシステム開発全般に関わる 要件定義などの上流工程を中心としたセミナー・コンサルティングを行う その間一貫してモデル中心で行う その経験を活かしてモデルを使った要件定義の手法を「RDRA」としてまとめる
- 3. 今日持って帰っていただきたいこと いつから開発のイテレーションをはじめますか？ アジャイルで開発する単位が見えていますか？ システムの複雑度をコントロールできていますか？ あなたは要求を実現したいと思ってますか？
- 4. なんでこうなるのか？ 要件が分からない１ 再構築編 XXX XXXX XXXXX XXXXX XXXX XXXXX XXXXX XXXXX AAAAA AAAAA AAAAA AAAAA AAAAA 日付 担当者A 担当者B 担当者B 担当者A タスク 担当者 この方向に圧縮 する思考になる 変更の影 響が大きい 早い段階から個人 ワークが始まる 辻褄が合っていない 大量のドキュメント 誰も説明 できない 要件を変えたくて もどこに影響が出 るか分からない 要件定義の途中 から要件が変え られなくなる
- 5. 要件が分からない２ アジャイル開発編 とりあえず開発できるものを作ってみました この後どうします？ 扱いのわからないドキュメントとプログラム しかないですよ • アジャイルで進めています • 動くもので確認する • 重厚なドキュメントを作っていては変化に素早く対応できない • 要件は決め切らない • ウォーターフォールでは誤りを早期に発見できない • ～～～ • 単純に要件定義の方法が分からないの で開発を始めてしまったのでは？？
- 6. 今何が起こっているのか（SoRとSoE：越境アジャイル） 開発 調達 生産 マーケ ティング 流通 販売 サービス SoR SoE とにかく早く SoR SoE クラウドサービス/アウトソース SoE（System of Engagement）（System of Record） Business Process Outsourcing 開発 調達 生産 マーケ ティング 流通 販売 サービ ス 売り上げにつながらない 社内リソース・活動を排除 アジャイル アジャイル 今回の範囲
- 7. では はじめましょう まずはWhyとWhatから
- 8. 前提とするプロセス 開発 要件定義 計画 非機能要求 プロト プロト アーキテクチャ構築 Or 先行開発 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト フィード バック プランニング のベース いつから開発のイ テレーションをはじ めますか？ アジャイルで開発 する単位が見えて いますか？ システムの複雑度を コントロールできてい ますか？ あなたは要求を実 現したいと思って ますか？ 継続的インテグレーション
- 9. いつから開発のイテレーションをはじめますか？ ⇒いきなり開発するわけにもいかない 開発 要件定義 非機能要求 アーキテクチャ構築 Or 先行開発 構築 受入テスト ～ 計画 プランニング のベース 計画 計画 計画 計画 計画 計画 計画 開発イテレー ションスタート 地図が必要
- 10. アジャイルで開発する単位が見えていますか？ ⇒単純に「ユースケース単位で開発する」とはいかない ⇒ストーリー毎に開発する ⇒ ストーリーの単位は？ 開発 要件定義 プロト非機 能要 求 プロト プロト アーキテクチャ構築 Or 先行開発 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト非機能要求
- 11. システムの複雑度をコントロールできますか？ ⇒システムの複雑度 ＝ ビジネスルール＋システムの仕組み ⇒ビジネスルールをいかに抽出するか？ バリエーションの組 み合わせから細かな 条件が整理される 概念 取引先 商品 取引 組合せによる特性を分析 仕入 先 自社倉庫 顧客 入荷出荷 支払請求・入金 倉庫 運 送 業 者 営業 購買 物 流 発注受注 金 融 機 関 販売管 理 購買管 理 入荷出荷 債権管 理 債務管 理 金 融 機 関 在庫管理 直送 経理 運送 シス テム 決済 シス テム 決済シ ステム 出荷シ ステム 入荷 システ ム 入庫 検 品 再構築の場合 ビジネスコンテキスト 開発 要件定義 プロト非機 能要 求 プロト プロト 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト非機能要求 スムーズにイテ レーションを回す ためには
- 12. あなたは要求を実現したいと思ってますか？ ⇒トップレベルの要求は大体いつも同じ（再構築の場合） ビジネスの変化に追従できるシステム 保守・開発のコストを下げる ⇒いつの間にか忘れられる 納期優先になる 要求を使って要件の内 容に方向性を持たせる コスト構造 収益構造 パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソ ース 主要活動 チャネル 顧客との 関係 ビジネスモデルキャンバス例えば基幹システムの場合 利益モデ ル ネット ワーク 組織構造 プロセス 製品性能 製品 システム サービス チャネル ブランド 顧客 エンゲー ジメント ビジネス １０タイプ 開発 要件定義 構築 受入テスト非機能要求 フィードバック 要件で開発を 方向付ける コアコンピタンス SoR SoE
- 13. システム地図でプロジェクトをコントロール 開発 要件定義 計画 プロト プロト アーキテクチャ構築 Or 先行開発 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト フィード バック プランニング のベース 継続的インテグレーション システム地図 システム地図 業務バリ エーション 要件でコントロール
- 14. 全体を俯瞰するためには 何が 何処に
- 15. 何が どこにある 地図は何を表している
- 16. 郵便局 XXホテル 病院 何が 役割の名前で対象 を理解する 駅 どこにあり 北 南 西 東 道路を中心に住所を表す マーク
- 17. 一方通行 指定方向外 進行禁止 目的地に進むためには 道路のルールに従う ローカルなルールも 出典livedoor.blogimg.jp
- 18. システム地図 購買管理 債権管理 債務管理 在庫管理 仕入 先 自社倉庫 顧客 入荷出荷 支払請求・入金 倉庫 運送 業者 営業 購買 物 流 発注受注 金融 機関 販売管理 購買管理 入荷出荷 債権管理 債務管理 金融 機関 在庫管理 直送 経理 運送シ ステム 決済 シス テム 決済シ ステム 出荷シ ステム 入荷シ ステム 入庫 検 品 ビジネスコンテキスト 何が どこに 販売管理 システムの構成要素 （マーク・関係性） システム地図
- 19. モデルイメージ 軽め 開発 要件定義 受入テスト アクターからシステムの入出力 システムの入出力から機能・データ システム全体を１枚もしくは入 出力で分けた数枚で整理
- 20. モデルイメージ 重め 開発 要件定義 受入テスト 業務のコンテキスト、モデル 別に整理 販売管理 購買管理 画面・帳票モデル プロトコルモデル 機能複合モデル （CRUD） データモデル イベントモデル 業務のコンテキスト
- 21. エンタープライズ系要件定義 あるある 要件定義で起こる様々な問題の解決に向けて 仕様化のためのマインドセットを変える
- 22. 一覧症候群 機能 機能 機能 機能 機能 機能 機能 機能 機能を集めたら システムが出来 上がる？ 一覧を作ってバラ バラにプログラム を作れば効率的 一覧づくりが目的化する （一覧は大事です）
- 23. 人工衛星 なかなか落ちていかない 昨日も話したけどそこもワークフロー で処理すると考えているんだけど… 私が決めるわけにいかないし… 一昨日話したけど そこはルールを明確に して自動化すると思っているんだけど… 私が勝手に決められないし… システム いつまでたってもシステム に切り込まない
- 24. 意味不明な区分 長年使われるシ ステムがおかし なビジネス習慣 を生む ToBe おかしな商習慣を ベースに要件定義す るとおかしな区分が再 生産される システムがこうだ からこうしている
- 25. RDRAとは RDRA：Relationship driven requirement analysis 要件定義の仕組み システム地図を作るために活用
- 26. 要件定義には何を定義すればいいのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 RDRAでは「要件定義の対象をシステムとシス テムを取り巻く環境」と考える システムを 取り巻く環境 システ ム 要件 定義書
- 27. 要件定義では何が定義されないといけないのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 •その機能が使用するデータは？ •システムに必要な機能は？ •その時の入出力情報は？ •システムとの接点は？ •どのようにシステムは使われるのか？ •どのような人、外部システムと関わるのか？ •このシステムの目的（価値）は？
- 28. もの サービス システム価値 もの サービス 利害関係者 ユーザ 要件定義の構造を定義する システム外部環境 外部システム システム 機能 データ 機能 機能 利害関係者 ユーザ 外部システム システム システム境界 機能 データ 機能 •システム価値 •システム外部環境 •システム境界 •システム 要件定義の構造
- 29. システム価値 もの サービス 利害関係者 ユーザ 要求 価値 外部システム 要件分析の枠組み 構成要素 １．【システムの価値】を捉える •対象業務に関わる人を洗い出す •関係する外部システムを洗い出す •要求を捉える ２．【システム外部環境】を捉える •対象業務の流れを捉える •対象業務に関わる概念を明らかにする •システムの利用シーンを明らかにする ３．【システム境界】を捉える •ユーザインターフェースを明らかにする •外部システムとのインターフェースを明 らかにする ４．【システム】を定義する •機能を明らかにする •データを明らかにする •ドメインの構造を把握する システム外部環境 システム 機能 データ 機能 システム境界 利用 シーン
- 30. コンテキストモデルからシステム境界まで １．対象業務に関わる人と外部 システムを把握する class システムコンテキスト 業務名 <<システム>> Xxxxシステム システム主体者１ システム主体者２ システム主体者３ システム主体者４ 業務主体者５ 外部システム コンテキストモデル 要求モデル 外部システム 人（アクター） シス テム 要求 要求 要求 ２．下記関係者の要求を 把握する ４．業務の中でシステムが 関わる部分を把握する ３．業務を組み立てる uc ユースケース ＸｘｘｘをＹｙｙｙする ＸｘｘｘをＷｗｗｗする ＵｕｕｕをＬｌｌｌする システム主体者１ システム主体者２ システム主体者３ システム主体者４ KkkkkをXする OをOnnnnする 業務モデル 対象業務に関わる人と外部シス テムを要件定義の起点とする イベントモデル プロトコルモデル ５．外部システムとのイベントを 捉える ６．外部システムとの プロトコルを整理 同じように利用シーンから ユースケースを導き出す
- 31. ユースケースから機能、データまで システム ７．ユースケースに関わる ユーザーインターフェーズ を洗い出す uc ユースケース ＸｘｘｘをＹｙｙｙする ＸｘｘｘをＷｗｗｗする ＵｕｕｕをＬｌｌｌする システム主体者１ システム主体者２ システム主体者３ システム主体者４ KkkkkをXする OをOnnnnする イベントモデル プロトコルモデル ８．ユースケースを実現 する機能を洗い出す custom 画面モデル <<画面>> 商品登録画面 - 商品名 - 取引先 - 荷姿 - 発注単位 - 商品カテゴリ <<画面>> 販売状況照会 - 月 - 商品カテゴリ <<画面>> 発注登録 - 商品 - 発注日 - 発注数量 - 入荷予定日 <<画面>> 商品説明 - 商品カテゴリ <<画面>> カート処理 - 受注番号 <<画面>> 受注照会 - 顧客名 - 受注日 商品売上詳細 - 商品 - 売上数量 - 売上金額 詳細説明 - 商品説明 カート内商品 - 商品 - 数量 <<画面>> 決済処理 - 顧客名 - 住所 - 決済方法 受注商品 - 商品 - 受注数量 画面帳表モデル act 機能モデル <<function>> Uuuu機能 <<function>> Zzzz機能 <<function>> Ｘｘｘｘ機能 <<function>> Ｙｙｙｙｙ機能 機能モデル act 機能モデル <<function>> Uuuu機能 <<function>> Zzzz機能 <<function>> Ｘｘｘｘ機能 <<function>> Ｙｙｙｙｙ機能 class データモデル２ <<datamodel>> AAAＸｘｘｘ - xxx11: int - xxx12: int - xxx13: int Ｘｘｘｘ <<datamodel>> AAAＸｘｘｘ１ - x1xx11 - x1xx12 - x1xx13 <<datamodel>> AAAＹｙｙｙ - yyy1 - yyy2 - yyy3 Ｕｕｕｕ - uuu1 - uuu2 - uuu3 <<datamodel>> AAAＪｊｊｊ - jjj1 - jjj2 - jjj3 <<datamodel>> AAAＯｏｏｏ - eeee1: int - eeee2: int - eeee3: int Ｘｘｘｘ <<datamodel>> AAAＸｘｘｘ２ - x2xx1 - x2xx2 - x2xx3 Ｘｘｘｘ Ｘｘｘｘ３ - x3xx1 - x3xx2 - x3xx3 データモデル ９．アクションを機能に 対応付ける 画面・ ユースケースモデル ユースケースモデル 機能モデル システム境界 １０．データを洗い出す １１．機能とデータ を付き合わせる 機能複合モデル
- 32. システム価値 システム外部環境 システム境界 システム ＵＣ：ユーケース 全ての情報をつなげる コンテキスト 利用シーン 業務 イベント ユースケース概念 画面・帳表 機能 ドメイン データ 要求 機能複合 モデル 利用シーン ＆ＵＣ 業務＆ＵＣ 状態 ＵＣ＆画面 ＵＣ＆機能 プロトコル 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 関係が整合性、網羅性を確保する システム地図の構成要素
- 33. 実際のモデル pkg マイルストーン３ コンテキスト + 営業承認者 + 営業担当者 + 物流担当者 + 経理 + B2B_基幹システム 販売管理 + 業務フロー + ユースケース + 画面・帳票 + イベント + プロトコル + 機能モデル 債権管理 + ユースケース + イベント + 画面・帳票 + 機能 購買管理 + 画面・帳票 + 業務フロー + ユースケース + 機能モデル 債務管理 会計システム 在庫管理 仕入登録 発注依頼 入金計上 出荷指示 売上計上 売上登録 支払計上 入荷通知 仕入計上 入荷通知 act 業務＆UC 営業 物流 経理 見積書作成 受注登録 出庫作業 開始 終了 見積承認 見積フォロー 営業承認者 営業担当者 受注承認 請求書発行 入金確認 督促状の発行 開始 見積もりを登録する 起票を承認する 入金を確認する <<在庫管理>> 商品を出庫する 請求書を作成する 出荷指示 出荷指示する 受注残を照会する 督促状を発行する 検収登録検収を登録する フォローを記録 する 物販の場合は出荷指示 サービスの場合は顧客サービス設定を行う 顧客サービスを設 定する 納品を確認する 受注を登録する 終了 顧客サービスの設定 受注残高を確認 <<include>> <<include>> uc 販売管理 受注を登録する (from ユースケース) <<在庫管理>> 在庫引当をする (from ユースケース) <<在庫管理>> 在庫引当を取り消す 出荷指示する (from ユースケース) <<在庫管理>> 商品を出庫する (from ユースケース) 売上を計上する (from ユースケース) 請求書を作成する (from ユースケース) 入金を確認する 債権の消込を行う 受注残を照会す る 受注を消し込む 見積もりを登録する (from ユースケース) <<在庫管理>> 在庫を確認する 見積もりを消し込む (from ユースケース) 入金を計上する 起票を承認する (from ユースケース) 督促状を発行する フォローを記録する 顧客サービスを設 定する 納品を確認する 概要 ・顧客からの見積もり依頼を受ける ・顧客の過去の受注情報を照会する ・顧客の見積もり情報を登録する <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> act 業務フロー 営業 物流 経理 見積書作成 受注登録 出庫作業 開始 終了 見積承認 見積フォロー 営業承認者 営業担当者 受注承認 請求書発行 入金確認 督促状の発行 開始 出荷指示 検収登録物販の場合は出荷指示 サービスの場合は顧客 サービス設定を行う 終了 顧客サービスの設定 受注残高を確認 キャンセル 終了 [サービスの場合] [物販の場合] class CRUDモデル <<機能>> 会計計上 <<機能>> 出荷情報取 得 <<機能>> 売上データ作成 <<機能>> 見積登録 <<機能>> 見積消込 <<機能>> 受注登録 <<機能>> 受注消込 <<機能>> 承認登録 出荷指示 - 受注番号 - 出荷指示日 - 出荷指示番号 受注 - 受注番号 - 受注日 - 得意先 - 合計金額 - 消費税額 - 値引額 受注明細 - 商品 - 数量 - 単価 - 金額 - 備考 決済情報 - 決済方法 - 決済方法別詳細情報 納品先情報 - 住所 - 連絡先 見積もり - 見積番号 - 見積日 - 得意先 - 消費税額 - 値引額 見積明細 - 商品 - 数量 - 単価 - 金額 - 備考 <<機能>> 出荷指示 <<機能>> 顧客サービル設定 <<機能>> 納品登録 出荷指示明細 - 受注番号 - 商品 - 出荷日 - 数量 - 納品日 顧客サービス - 受注番号 - 得意先 - サービス開始日 - サービス終了日 - サービス種類 <<機能>> 出庫確認 <<CRUD>> <<U>> <<R>> <<R>> <<R>> <<CRUD>> <<RU>> <<CRUD>> <<CRUD>> <<CRUD>> <<U>> <<U>> <<CRUD>> <<R>> <<R>> <<CRUD>> <<R>> <<CRUD>> <<CRUD>> <<U>> <<R>> <<CRUD>> uc 販売管理_UC＆機能 受注を登録する <<在庫管理>> 在庫引当をする <<在庫管理>> 在庫引当を取り消す 出荷指示する <<在庫管理>> 商品を出庫する 売上を計上する請求書を作成する 入金を確認する 債権の消込を行う 受注残を照会す る 受注を消し込む 見積もりを登録する <<在庫管理>> 在庫を確認する 見積もりを消し込む 入金を計上する 起票を承認する 督促状を発行する <<機能>> 受注登録 <<機能>> 見積消込 <<機能>> 見積登録 <<機能>> 受注消込 <<機能>> 承認登録 <<機能>> 会計計上 <<機能>> 売上データ作成 <<機能>> 出荷情報取得 <<機能>> 督促情報作成 <<機能>> 出荷指示 顧客サービスを設 定する フォローを記録する 納品を確認する <<機能>> 顧客サービス設定 <<機能>> フォロー登録 <<受信>> 出庫通知 <<受信>> 納品通知 <<機能>> 出庫確認 <<機能>> 入金登録 <<機能>> 納品登録 <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> class 画面・帳票 未出荷分を受 注残とする 見積登録 - 見積番号 - 見積日 - 得意先 - 合計金額 - 消費税額 - 値引額 受注登録 - 受注番号 - 受注日 - 得意先 - 合計金額 - 消費税 - 値引き 出荷指示 - 出荷指示ID - 受注番号 - 出荷指示日 受注残照会 - 受注番号 - 得意先 伝票承認 - 伝票番号 - 承認状態 - 承認者 見積明細 - 商品 - 数量 - 単価 - 金額 - 備考 受注明細 - 商品 - 数量 - 単価 - 備考 出荷指示明細 - 商品 - 出庫済数量 在庫管理システムからのイ ベントの分析により出荷処 理の詳細が分かってきた 見積フォロー登録 - フォロー日 - フォロー担当者 - 見積番号 顧客サービス設定 - 受注番号 - サービス - 開始 - 停止 納品登録 - 出荷指示ID - 納品日 検収登録 - サービスID - 検収日 - 検収担当 uc 販売管理_UC&画面 在庫管理 受注を登録する <<在庫管理>> 在庫引当をする <<在庫管理>> 在庫引当を取り消す 出荷指示する <<在庫管理>> 商品を出庫する <<在庫管理>> 商品を入庫する <<購買管理>> 商品を発注する 売上を計上する 請求書を作成する 入金を確認する 債権の消込を行う 受注残を照会する 受注を消し込む 見積もりを登録する <<在庫管理>> 在庫を確認する 見積もりを消し込む 入金を計上する 起票を承認する 在庫照会 在庫引当 在庫引当取消 督促状を発行する 検収を登録する 売上計上基準が出荷基準の 場合は出庫タイミングで計 上、検収基準の場合は、検 収確認のタイミングで計上 見積登録 - 見積番号 - 見積日 - 得意先 - 合計金額 - 消費税額 - 値引額 受注登録 - 受注番号 - 受注日 - 得意先 - 合計金額 - 消費税 - 値引き 出荷指示 - 出荷指示ID - 受注番号 - 出荷指示日 受注残照会 - 受注番号 - 得意先 請求書 督促状 入金登録 伝票承認 - 伝票番号 - 承認状態 - 承認者 フォローを記録する 見積フォロー登録 - フォロー日 - フォロー担当者 - 見積番号 顧客サービスを設 定する 顧客サービス設定 - 受注番号 - サービス - 開始 - 停止 納品を確認する 納品登録 - 出荷指示ID - 納品日 検収登録 - サービスID - 検収日 - 検収担当 受注照会 - 受注番号 - 受注日 - 得意先 - 合計金額 - 消費税 - 値引き <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> stm プロトコル 受注 [受注] [入金] 物販 開始 見積済 見積フォロー済 未入金 入金あり 一部入金済 全部入金済 受注済 サービス提供 サービス提供 中 サービス提 供終了 終了 出庫待ち 出庫中 出庫済み 検収済 納品済 [納品確認が不要] 出庫指示 [在庫有り] 入金通知 [請求残 ＝入金額] 受注登録 受注 登録 入金通知 [請求額＝入金額] 入庫 [在庫あり] 顧客サービス設定 [開始指示] 出荷指示 [在庫なし] 出庫通知 [未 出荷分なし] サービス利用 [ワンタイム契約] 出庫通知 [未出 荷分あり] 見積フォロー登録 [検収が必要ない] 顧客サービス設定 [停止指示] 検収登録 [検収が 必要な場合] 納品登録 [納品 確認が必要] 入金通知 [請求額＞ 入金額]売上情報登録 act イベント <<受信>> 出庫通知 <<送信>> 出庫指示 <<受信>> 納品通知 在庫管理 在庫引当情報 - 受注番号 - 商品 - 数量 <<送信>> 在庫引当 <<受信>> 在庫引当取 消 出庫指示を 受け付ける 出庫したこと を通知する 受領書を受け取り 納品を確認したこ とを通知する 在庫を引き 当てる 引き当てた在庫を取 り消す 出荷指示情報 - 受注番号 - 出荷指示日 - 出荷指示番号 出荷指示明細情 報 - 受注番号 - 商品 - 出荷希望日 - 数量 - 納品日 出庫商品情報 - 受注番号 - 商品 - 出荷日 - 数量 uc コンテキスト B2B_基幹システム 営業担当者 物流担当者 経理 営業承認者 在庫管理 (from 基幹システム) 会計システム (from 基幹システム) class データモデル 債権管理 販売管理 受注 - 受注番号 - 受注日 - 得意先 - 合計金額 - 消費税額 - 値引額 見積もり - 見積番号 - 見積日 - 得意先 - 消費税額 - 値引額 納品先情報 - 住所 - 連絡先 決済情報 - 決済方法 - 決済方法別詳細情報 出荷指示 - 受注番号 - 出荷指示日 - 出荷指示番号 受注明細 - 商品 - 数量 - 単価 - 金額 - 備考 入金 - 入金日 - 入金元 - 入金額 見積明細 - 商品 - 数量 - 単価 - 金額 - 備考 商品 - 商品CD - 商品名 - 単価 - 商品カテゴリ 取引先 - 取引先CD - 取引先名 請求 - 請求日 - 請求先 - 請求金額 取引先決済情報 - 決済方法 - 決済方法別詳細情報 取引先納品先情報 - 住所 - 連絡先 取引先別単価 - 商品CD - 取引先CD - 取引先別単価 出荷指示明細 - 受注番号 - 商品 - 出荷日 - 数量 - 納品日 顧客サービス - 受注番号 - 得意先 - サービス開始日 - サービス終了日 - サービス種類
- 34. システムの対象を理解する 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 関係が整合性、網羅性を確保する システム地図の構成要素
- 35. ビジネスコンテキスト 仕入先 会社 得意先 入荷出荷 支払請求・入金 倉庫 運送 業者 営業部 購買部 商品管理部 物流部 発注 受注 金融 機関 販売管理 購買管理 入荷出荷 債権管理 債務管理 金融 機関 在庫管理 直送 顧客 販売手段 店頭 コールセンター 会計 経理部 受取 店頭在庫 発注 販売 受注 受取 受取 受取 発注 入荷 出荷 支払入金 納品 見積 在庫移動 棚卸 在庫補充 商品属性 納品加工 納品 商品 所有移動 委託 在庫 商品 自社倉庫 部署 B2C B2B <在庫> ・実在庫 ・理論在庫 ・所有 ・取置 ビジネスルールのも とになるビジネス上 の関心毎を記述 システム化対象のビジネス上の登場人 物を管理 「ものとこと」を表現
- 36. システム化対象を分類する ビジネスコンテキスト 仕入先 会社 得意先 入荷出荷 倉庫 営業部 購買部 物流部 発注 受注 販売管理 購買 管理 入荷出荷 在庫管理 直送 顧客 販売手段 店頭 EC コールセンター 店頭在庫 発注 販売 受注 受取 受取 受取 発注 入荷 出荷 納品納品 自社倉庫 B2C B2B 販売管理 対象領域 販売管理 在庫管理 購買管理 フ ロ ー フ ロ ー フ ロ ー 営業 経理物流 業務 分類 業 務 分 類 業 務 分 類 業務 分類 業務分類 組織 仕事 価値フロー 仕事 仕事 B2C B2B EC 店頭 組織の責務と価値フロー からビジネスをシステム 化対象を分類する
- 37. ビジネスルールを洗い出す ビジネス ルール ビジネスコンテキスト 会社 得意先 営業部 物流部 在庫管理 受注 受取 出荷 商品 所有移動 自 社 倉 庫 所有 取置移動 入荷 仕入先 <在庫> ・実在庫 ・理論在庫 ・所有 ・取置 概念 出荷 入荷 取引先 商品 業務 組合せによる特性を分析 在庫 <在庫> ・実在庫 ・理論在庫 ・所有 ・取置 「理論在庫」「所有」 「取置」という概念がビ ジネスルールを生む
- 38. ビジネスルールの表現 業務 プロトコル 概念 ドメインデータ 手順のルール 情報構造のルール 計算式 規約 基準 表形式の一覧 在庫あり 在庫なし 在庫引当登録 [在庫＜１] 受注引落し [在庫＜１] ランクA ランクB 0～200 10,000円 5,000円 201～300 20,000円 15,000円 受注引 落し 在庫引 当登録 フライト 空港 2 イベント 画面 会員 Y Y Y N 購入合計＞10000 Y Y N Y 過去購入回数＞２ Y N N Y 割引率５％ X - - - 割引率3％ X X - - 割引なし - - X X デシジョンテーブル ビジネスルールを３つの形式で整理する
- 39. ビジネスルール整理のものさし 直目する視点 手順のルール 情報構造のルール 計算式 基準 規約 分析 視点 作業の順番など、順序や進行に条件 がある場合にこの方式で分析する 情報に構造があり、情報間のつな がりに多重度があるときにこの方 式で分析する 独立した計算式や条件の場合は 一覧形式で整理する 登場 人物 会社、人、組織、外部のシス テムなどで識別しているもの を洗い出す 人、組織間でやりとりに着目 する 登場人物間にやりとりが発生するとき ワークフローが発生する 例： 部門間のワークフロー 承認ワークフロー 登場人物には個々に特性があり 構造化できる 例：顧客：一般・会員 ～ 登場人物の関係性で決まるもの 外部のシステムが規約として決め ているもの 商品 サー ビス 商品の種類や特性に着目す る サービスの前準備でワークフローが必 要なものがある 例： インターネットの接続工事 サービスのローテーションルール ものやサービスで扱う情報を構造 化する 例： 伝票の構造 サービスと附帯物の関係 もの、サービスに関わる計算 もの、サービスのバリエーションか らくる計算の差異 利益率など もの、サービスのバリエーションか らくる処理の差異 お金 支払 入金 決済方法などお金に関わる 特性に着目する 例： 残管理：消し込み 商品（サービス）の販売から入金まで の流れ １回払いと継続払いの手続きの違い もの、サービスとお金の対応つけ 複雑な決済方法の構造化 金額計算 値引き率 自動継続 時間 時間、時期、期間、日付に よって特殊性がでるものを分 析する 期間にまつわるルール 例：期限が１週間... 時期による振る舞いの違い 例：季節キャンペーン 定周期のイベント 例：日時 週次 月次 期間や時期にまつわる関係の変 化を構造化する 時間にまつわる計算式 例： 実稼働時間の計算方法 時間あたりの単価 場所 場所によって条件が変わるも のや特殊性が発生するもの を分析する 国内取引と海外取引の手続きの違い 地域特性による手順の相違 例： 海外取引における乙仲の存在 海外品の返品の省略 場所による構造の違い 例： 通過、時間の違い 国内と海外取引の伝票の違い 場所による計算式の違い 例： 場所による仕様の違い 場所による税率の違い 温暖地と寒冷地仕様の条件 環境 制約 法律や業界の自主規制など の制約に着目し分析する 会計基準 例： 顧客の検収を持って売上げ計上する 情報間の多重度が制約になる 制約のルールが複雑な場合に構 造化して分析する 単独で存在するルール 税率 ビジネスの普遍的な軸を物差し にして特徴を洗い出す
- 40. 管理の壁に対応する
- 41. どっちが分かりやすい 分析が先、一覧は後
- 42. 開発単位 直行する概念を組み合わせる データ ドメイン 設計・実装 開発 要件定義 プロト非機 能要 求 プロト プロト アーキテクチャ構築 Or 先行開発 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト非機能要求 SoR SoE データ・ドメイン ・業務分類 ・業務フロー ・アクティビティ ・ユースケース データ・ドメイン コンテキスト コンテキスト ・ストーリー ・シナリオ ・ストーリー ・シナリオ どの単位？ ・業務分類 ・価値フロー ・アクティビティ ・ユースケース データ・ドメインを 一旦決めた方が 落ちつく コンテキスト イテレーションの長さに合わせ て開発単位を決める
- 43. WBSっぽく管理する マネージャー：いつ何ができる？ それで間に合うの？ リーダー：要件をどこまでつめればいい？ 手法を学ぶ リリースに 向けた調整 広く浅く徐々に深くする フィードバックで精度を上げる 開発 要件定義 プロト非機 能要 求 プロト プロト Fix 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト ～ フィードバック プランニングの ベース WBSを定期期間で管理
- 44. まとめ
- 45. まとめ まずはメンバーの頭のなかを可視化 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 RDRAの構成要素
- 46. RDRA ワークショップ ２時間でシステム地図を作成する 場所を用意していただければワークショップの勉強会を開催いたします やっぱり手を動かさないとわからない
Entre para ver os comentários