伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義
•
1 like•1,079 views
Developers Summit Kansai 2020での発表内容となります。 DXの企画を受けて要件定義を実施する状況でRDRA（らどら：Relationship Driven Requirement Analysis）を実施した事例を具体的な流れで紹介します。
Recommended
Recommended
More Related Content
Similar to 伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義
Similar to 伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義 (20)
More from Noriyuki Mizuno
More from Noriyuki Mizuno (20)
Recently uploaded
Recently uploaded (10)
伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義
- 1. Developers Summit Kansai 2020 伝統的食品工場エンジニアリング会社が挑む DXへのビジネスアイデアを RDRAによる要件定義でプロダクト開発へつなぐ ～Side：要件定義 水野 昇幸 ＠NoriyukiMizuno
- 4. // 自己紹介：最近の発表ネタ 発表や公開している内容はこちら。※過去6年程度 RDRA関連 ・RDRA+プロトタイピング および仕様化時に役立つ技術、事例紹介 ソフトウェアテスト/テスト自動化関連 ・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・（共著）InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・DevSumi関西2018：2018年、テスト自動化の「これまで」と「これから」 ・ET⁻WEST2018：なぜ組込みシステムにおけるテストは難しいのか ～ 2つのテストアーキテクチャによってテストを組立てる ～ ・（共著）InSTA2017＠東京：Test Conglomeration - Proposal for Test Design Notation like Class Diagram ・JaSST’17関西：納得できるテストをつくるアプローチ ・STAC2015：自動家は見た～自動化の現場の真実～ ・ET-WEST2014：組込み開発でのSWテスト自動化のライフサイクル ・関西風と欧米風、２つのTest Automation Patterns ・テストカタマリーの紹介/活用したテスト設計プロセス案 TOC（制約理論：Theory of Constraints）関連 ・SaPIDTOC～未来予想型チーム運営ワークショップ ・SQiP2014：CCPMの考え方を活用したテストフェーズにおける課題解決 ～課題発見、解決までのケーススタディ～ ・プロジェクトマネジメントの概要とCCPMによる工期短縮の仕組み ・CCPMのおはなし、CCPM折り紙ワークショップ ・提案を検証する技術（TOC マフィアオファー（URO）活用技術）
- 6. // 背景：前段の紹介を踏まえた状況 RFP 提案書 要件定義 仕様 プロダクト 企画 提案 要件定義～仕様化 実装 ※実装に関わるあれこれは 本発表では紹介しませんRDRAの活用範囲 小林さん Codeer Codeer開発
- 7. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ （継続的に段階的な 開発を実施）
- 8. 今回の要件定義活動についてタイムラインで状況を紹介します。 // 参考：段階的な開発のプロセス 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ （継続的に段階的な 開発を実施） 要件定義 （＋仕様化） 開発 フィード バック 業務①：見積 業務フロー 要件確認 画面案 仕様調整 見積業務：開発 フィードバック対応 業務②：計画 業務フロー 要件確認 画面案 仕様調整 見積：フィードバック ・・・ 計画業務：開発 参考）よくやるプロセス：業務単位でパイプライン的に要件明確化＋仕様化→開発とつなぐ （デザイン、全体方針設計）
- 9. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ （継続的に段階的な 開発を実施） Phase1： RDRAたたき台 モデルの構築 Phase2： RDRAモデルの検証 と仕様化への活用 オマケの現状： 現在のモデル活用 状況と仕組み
- 11. ここでRDRAの紹介
- 13. RDRA：らどら、Relationship Driven Requirement Analysis モデル定義の要件定義手法、現状は「RDRA2.0」となってます。 バリューソース、神崎善司氏に提唱された手法 Webにかなりの情報をまとめて頂いてます→リンク：http://k-method.jp/ 興味がでたら書籍を読もう！ // RDRA紹介：参考文献 モデルベース要件定義テクニック https://www.amazon.co.jp/dp/B07D25W3HF/ RDRA2.0 ハンドブック: 軽く柔軟で精度の高い 要件定義のモデリング手法 https://www.amazon.co.jp/RDRA2-0- %E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF- %E8%BB%BD%E3%81%8F%E6%9F%94%E8%BB%9F%E3%81%A7%E7%B2%BE %E5%BA%A6%E3%81%AE%E9%AB%98%E3%81%84%E8%A6%81%E4%BB%B6% E5%AE%9A%E7%BE%A9%E3%81%AE%E3%83%A2%E3%83%87%E3%83%AA%E 3%83%B3%E3%82%B0%E6%89%8B%E6%B3%95- %E7%A5%9E%E5%B4%8E%E5%96%84%E5%8F%B8-ebook/dp/B07STQZFBX/
- 14. 始祖である神崎さんが最近イベントで多数紹介してくれております。 （そして、書籍段階からさらに改善が行われているようです…） 直近の神崎さんイベント開催記録（2020/08/27段階）： // RDRA紹介：文献以外の情報 2020/07/30 要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法 2020/07/22 テレワーク下の要件定義 2020/06/19第2回 実践者に学ぶ 設計手法・方法論セミナー/ 2020/02/12要件定義を素早く行う手法RDRA2.0のワークショップ 2020/01/28要件定義を素早く行う手法RDRA2.0のご紹介（第２回） 上記以外でも、最近はオンラインでRDRAテーマのイベントが 開催されることもあります！ →例：RDRA MeetUp など
- 15. 実際にRDRAを試してみる場合、ツールとセットが推奨となります。 ツールとしては、以下の2つが推奨となります。 理由：トレサビが機械的に確認できないとRDRAのうまみが半減しますので… 1．EA（Enterprise Architect）＆RDRA2.0プラグイン 2．（神崎さん作）Power Point向けツール // RDRA紹介：ツール 本発表では、EA（Enterprise Architect）を活用した例を紹介します。 神崎さん作Power Point向けツールは こちらの書籍にリンクが載ってます （ステマ？）
- 16. 聞いたことがありそうな要件定義の問題 // 参考：RDRAが解決する要件定義の問題 RFPなど ユーザ/POなど 要件定義担当？ 画面一覧 帳票一覧 機能一覧 UC一覧 開発担当 とにかく「一覧」としてまとめようとしてまう 一覧から分担を割り当てようとも考えてしまう お、おう ？？一覧
- 17. とにかく「一覧」としてまとめようとしてまう 一覧から分担を割り当てようとも考えてしまう 聞いたことがありそうな要件定義の問題 // 参考：RDRAが解決する要件定義の問題 RFPなど ユーザ/POなど 要件定義担当 画面一覧 帳票一覧 機能一覧 UC一覧 開発担当 UCシナリオまで まとめようとしたら もうみてらんない！ お、おう 問題点： ・成果物間の整合性があるか分からない（大抵整合性はない） ・画面、機能が何のために必要なのか分からない ・業務ユーザ/POが一覧を見ても運用ができるか判断できない →ユーザ側のやりたいことがどう反映されたか不明確 ・レビューで見て何が分かるのか？指摘側の趣味の指摘？ 網羅性って何よ？ってなる
- 19. // RDRAレイヤによる（絶妙かつ）段階的な整理 システム価値 業務 業務 業務 システム外部環境 （抽象的な） 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 外部システム 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 イベント 情報 情報 情報 情報 状態 状態 状態 状態 バリエーション 条件 BUC UC Act ビジネスユースケース：１業務フロー相当 ※RDRA要素 アクティビティ：UMLと同じ ユースケース ：UMLと同じ 凡例 RDRAレイヤによる（絶妙かつ）段階的な整理 コミュニ ケーショ ンの 土台とな る 影響度を 手早く 確認 Whyを 辿ること で 妥当性を 議論可能 アイコン 要素の 接続で 整合性確 保 RDRAの特徴（抜粋） 開発における 価値 ユーザ/開発の 価値 ビジネス、業務向け情報 システム、開発向け情報 こちらの図は書籍のRDRA2.0記法から少しだけ ずれた記述表現があります（以下の部分） ・一部依存線を活用（Whyを明示するため） ・BUCに順序関係を表現 RDRAはこの絵に 慣れるのがだいじ！
- 20. // RDRAレイヤによる（絶妙かつ）段階的な整理 システム価値 業務 業務 業務 システム外部環境 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 外部システム 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 イベント 情報 情報 情報 情報 状態 状態 状態 状態 バリエーション 条件 ・モデル（図）で表現を行います ※独自要素を含みます ・「要素」のつながりを重視し、モデルを育てていきます ・ダイアグラムは推奨の分け方（区切り）が紹介されてます つながり重視ですが、ダイアグラムも使いやすいです RDRAレイヤによる（絶妙かつ）段階的な整理 コミュニ ケーショ ンの 土台とな る 影響度を 手早く 確認 Whyを 辿ること で 妥当性を 議論可能 アイコン 要素の 接続で 整合性確 保 RDRAの特徴（抜粋） 開発における 価値 ユーザ/開発の 価値 （抽象的な） 要求
- 21. // RDRAレイヤによる（絶妙かつ）段階的な整理 ・モデル（図）で表現を行います ※独自要素を含みます ・「要素」のつながりを重視し、モデルを育てていきます ・ダイアグラムは推奨の分け方（区切り）が紹介されてます つながり重視ですが、ダイアグラムも使いやすいです システム価値 業務 業務 業務 システム外部環境 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 外部システム 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 イベント 情報 情報 情報 情報 状態 状態 状態 状態 バリエーション 条件 情報モデル 状態モデル UC複合図 業務フロー/ 業務フロー ＆UCモデル ビジネス ユースケース図 （業務内構成） ビジネス コンテキスト図 RDRAレイヤによる（絶妙かつ）段階的な整理 コミュニ ケーショ ンの 土台とな る 影響度を 手早く 確認 Whyを 辿ること で 妥当性を 議論可能 アイコン 要素の 接続で 整合性確 保 RDRAの特徴（抜粋） 開発における 価値 ユーザ/開発の 価値 （抽象的な） 要求
- 23. // アイコン要素の接続で整合性確保 RDRAレイヤによる（絶妙かつ）段階的な整理 コミュニ ケーショ ンの 土台とな る 影響度を 手早く 確認 Whyを 辿ること で 妥当性を 議論可能 アイコン 要素の 接続で 整合性確 保 RDRAの特徴（抜粋） 開発における 価値 ユーザ/開発の 価値 システム価値 業務 業務 業務 システム外部環境 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 外部システム 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 イベント 情報 情報 情報 情報 状態 状態 状態 状態 バリエーション 条件 ・アイコン要素のつながりで整合性を取ることができます ・EAなら特にトレーサビリティが分かりやすいです （Power Point向けツールも便利です） →影響度を手早く確認することも可能となります （抽象的な） 要求
- 25. システム価値 業務 業務 業務 システム外部環境 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 外部システム 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 イベント 情報 情報 情報 情報 状態 状態 状態 状態 バリエーション 条件 （抽象的な） 要求 // コミュニケーションの土台となる ユーザ/POなど 開発担当 業務中心に議論 開発の背景を伝える システム開発要素の背景を伝えることで、 開発時に発生した疑問などを自主的に フォローしてもらえる （開発担当、優秀ですので！） 業務中心で確認しながら システム化することでの妥当性を 開発前段階でも机上で確認しながら 要件を決めることができる
- 26. 聞いたことがありそうな要件定義の問題→RDRAで解決につながる // 元の課題の解決へ RFPなど ユーザ/POなど 要件定義担当 画面一覧 帳票一覧 機能一覧 UC一覧 開発担当 お、おう 問題点： ・成果物間の整合性があるか分からない（大抵整合性はない） ・画面、機能が何のために必要なのか分からない ・業務ユーザ/POが一覧を見ても運用ができるか判断できない →ユーザ側のやりたいことがどう反映されたか不明確 ・レビューで見て何が分かるのか？指摘側の趣味の指摘？ 網羅性って何よ？ってなる アイコン要素の接続で整合性確保 Whyを辿ることで妥当性を議論可能 RDRAレイヤによる段階的な整理 RDRAレイヤによる段階的な整理
- 28. もどります
- 29. Phase1
- 30. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ Phase1：RDRAたたき台モデルの構築 RFP 提案書 要件定義 仕様 プロダクト 小林さん Codeer Phase2 （継続的に段階的な 開発を実施） Codeer開発 この辺のはなし
- 31. // Phase1：RDRAたたき台モデルの構築 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン 仕様 仕様 RDRAレイヤの主にこの辺 1．業務～BUC～業務フローまで簡易整理 2．モデルとして階層・つながりを考慮してまとめる 3．UCや画面を割り当てておく システム状況を考慮して見直し ・よく実施する手順 簡易整理は マインドマップが （慣れていれば） 速いです ※階層で検討可能 ・・・業務フロー アクティビティ1-1-3 アクティビティ1-1-2 アクティビティ1-1-1 業務フロー BUC1-2 BUC1-1 ・・・ ・・・ 業務2 業務1 XXの業務
- 32. // Phase1：RDRAたたき台モデルの構築 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン 仕様 仕様 RFP RDRAモデル ■RFPコンテンツ ・企画にて目指すサービス、抽象的要望 ・サービス毎のステークホルダ、 サービスの関連システム ・サービスの業務構造（一部）、 具体的手順案 ・サービス提供時手順（一部） ・実現時の画面案 ・（その他プロジェクト情報） この辺情報あり この辺一部情報あり 業務 BUC 画面 Act UC RFPの情報をベースに RDRAの各情報を段階的に作成 RDRAレイヤの主にこの辺
- 33. // Phase1：RDRAたたき台モデルの構築 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン 仕様 仕様 RFP RDRAモデル ■RFPコンテンツ ・企画にて目指すサービス、抽象的要望 ・サービス毎のステークホルダ、 サービスの関連システム ・サービスの業務構造（一部）、 具体的手順案 ・サービス提供時手順（一部） ・実現時の画面案 ・（その他プロジェクト情報） この辺情報あり この辺一部情報あり 業務 BUC 画面 Act UC マインドマップベースで 「あたり」をつける ※ここだけastah*使ってます RDRAレイヤの主にこの辺 ・・・業務フロー アクティビティ1-1-3 アクティビティ1-1-2 アクティビティ1-1-1 業務フロー BUC1-2 BUC1-1 ・・・ ・・・ 業務2 業務1 XXの業務
- 34. // Phase1：RDRAたたき台モデルの構築 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン 仕様 仕様 RFP RDRAモデル ■RFPコンテンツ ・企画にて目指すサービス、抽象的要望 ・サービス毎のステークホルダ、 サービスの関連システム ・サービスの業務構造（一部）、 具体的手順案 ・サービス提供時手順（一部） ・実現時の画面案 ・（その他プロジェクト情報） この辺情報あり この辺一部情報あり 業務 BUC 画面 Act UC 1つの業務、1つのBUC（業務フロー）単位で集中して整理する RDRAレイヤの主にこの辺 業務A BUC BUC BUC 画面 Act UC Act UC
- 35. // Phase1：RDRAたたき台モデルの構築 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン 仕様 仕様 RFP RDRAモデル ■RFPコンテンツ ・企画にて目指すサービス、抽象的要望 ・サービス毎のステークホルダ、 サービスの関連システム ・サービスの業務構造（一部）、 具体的手順案 ・サービス提供時手順（一部） ・実現時の画面案 ・（その他プロジェクト情報） この辺情報あり この辺一部情報あり 業務フロー/ 業務フロー ＆UCモデル ビジネス ユースケース図 （業務内構成） 業務ALL：ビジネス コンテキスト図 その他インプット 工場に 関わる書籍 業務 BUC 画面 Act UC RDRAレイヤの主にこの辺
- 37. 提案書段階でRDRAたたき台モデルを用いる利点をまとめておきます ・スコープを手早く把握できる ・（ツールを使うことで）見積に必要な一覧情報はまとめて出力できる ・次（開発）フェーズにつながるベース情報を用意できる →開発フェーズにてたたき台モデルを継続して育てていく // 提案書段階でのRDRAの利点 RDRAモデル 業務フロー/ 業務フロー ＆UCモデル ビジネス ユースケース図 （業務内構成） 業務ALL：ビジネス コンテキスト図 業務 BUC 画面 Act UC 画面一覧 帳票一覧 UC一覧 整合性が取れたものを出力 （こちらの情報自体は、その局面の 見積情報以外価値が低い）
- 38. Phase1->Phase2
- 39. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ （継続的に段階的な 開発を実施） Phase2：RDRAモデルの検証と仕様化への活用 RDRA たたき台 モデル RDRA 議論済 モデル 実装へ 情報 （データ構造） 具体的画面 デザイン案 仕様 モデル の検証 不明点 の確認 モデル を元に 具体的 仕様設計 ※実際は実装から もフィードバック ありますが省略
- 40. // Phase2：RDRAモデルの検証と仕様化への活用 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン案 仕様 仕様 RDRAレイヤ の主にこの辺 ＜主に業務単位で作業を実施＞ ・よく実施する手順 - 手書きでの簡単なイメージを用意する - 実現イメージと対応させて業務フローを紙芝居的に確認する - （初期からメモしてた）疑問点、曖昧な部分などを確認する - 画面や仕様（ビジネスルールなど）にまとめる - （実装側からの疑問などが来た場合）業務と対応させつつ確認する ※仕様の例（ルールのモデル化をした場合）
- 41. // Phase2：RDRAモデルの検証と仕様化への活用 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン案 仕様 仕様 RDRAレイヤ の主にこの辺 手書きでの簡易画面 イメージを用意する （初期からメモしてた） 疑問点、曖昧な部分など を確認する 簡易画面イメージと 業務フローを対応させて 紙芝居的に確認する RDRA たたき台 モデル ※各業務で実際に使用している 帳票やメモ、メール記述なども参考
- 42. // Phase2：RDRAモデルの検証と仕様化への活用 システム価値 業務 業務 業務 システム外部環境 要求 要求 アクター UCBUC BUC BUC アクターBアクターA Act Act Act UC UC UC 画面 システム境界 システム 画面 業務->BUC（業務フロー）の階層構造 情報 情報 状態 状態 RDRA対象外 具体的画面 デザイン案 仕様 仕様 RDRAレイヤ の主にこの辺 情報 （データ構造） 具体的画面 デザイン案 仕様 状態 仕様はデシジョン テーブルなどに表現 できるレベルが便利 開発可能な 具体的な情報へ 洗練させる RDRA たたき台 モデル
- 44. Phase2->現在まで
- 45. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート プレスリリース イマココ 注：本発表ではキレイすぎる部分だけ紹介してますのでご了承ください 中間の課題と工夫についてはSlideShareにもまとめてますので参考としてください 関連資料：RDRA+プロトタイピングおよび 仕様化時に役立つ技術、事例紹介 https://www.slideshare.net/NoriyukiMizuno/rdra-236183496 ※主にPhase2向けの課題と工夫をまとめております
- 46. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート イマココ （継続的に段階的な 開発を実施） （いろいろあれど）4/1に無事プレスリリースしております プレスリリース 6/17には日経朝刊 に載ってました
- 47. 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 おまけ：現状 中間 省略 RFP提示 開発スタート イマココ （継続的に段階的な 開発を実施） （いろいろあれど）4/1に無事プレスリリースしております プレスリリース 6/17には日経朝刊 に載ってました 皆様が保有している工場の管理用として ぜひとも導入検討ください！
- 48. 現在
- 49. おまけ：現状（継続的に段階的な 開発を実施） 現在のモデル活用状況と仕組み： RDRAモデルから画面、仕様、テストへの各ツール連携を可能に！ 今回の要件定義活動についてタイムラインで状況を紹介します。 // タイムラインと紹介するフェーズ 2019 4月 8月 5月5月 6月 9月7月 6月 8月7月 2020 4月 Phase1 Phase2 中間 省略 RFP提示 開発スタート プレスリリース イマココ RDRAモデル 業務 BUC 画面 Act UC テスト 具体的画面 仕様 連携 連携 連携