ビジネスクリーンアーキテクチャ

1. 初めての要件定義
変革に強いビジネスクリーンアーキ
テクチャ
発表者名
工藤 由美

2. アジェンダ
トピック 1 UAFについて
トピック 2 苦労と工夫
トピック 3 やった方がいいと
思うこと
トピック 4 まとめ
2

3. 概要
ドメイン知識が全くないDX推進ビジネスにおける、
システム化以前の超上流工程～
リソース要件定義(システム要件定義含む)
までを実体験した中での気づきや創意工夫。
主な提供したいステークホルダー一覧
・関心の異なるステークホルダーの要求などの整理に困ってる
・これから要件定義に触れたい
・システム以前の企画段階の工程を知りたい
3

4. 自己紹介
業部所属
2021年秋からIT業界へ、今2年目。
IT業界入る前は、
予備校講師や飲食店接客、音楽など。
モットーは
【昨日の常識は今日の非常識】
【制約は振り回されるものでなく使いこな
すもの】
【目的はミュータブル】 【国内は部屋】
現在 System Of Systems関連ビジネス
で
OOを用いた戦略的ビジネスアーキテクチャ
構築
(ビジネス要求、要件定義) 4

5. System Of Systemsについて
コンテキストポンチ絵 5
複数のシステムで
１つの大きなシステム
って捉える。
他のSoSへまたいでる。

6. 課題
エンタープライズモデル 6
ビジネスモデルが
下位のシステムに依存してる場合、
どんなにシステムを保守性高めても
すべて水の泡。
(寿命の短いビジネスでいいとか、
後からリアーキテクティングするとかは別)

7. トピック1
UAFについて

8. UAFってなに？
EAをベースにした、
マスターすれば
無駄なリソース削減や、
組織改革
DXにも繋がる枠組みを提
供。
20XX/9/3 プレゼンテーションのタイトル 8

9. 早い話がピラミッドストラクチャー
20XX/9/3 プレゼンテーションのタイトル 9

10. UAFに必要な前提知識
方法論がない中で、実体験を通して思った必要な前提知識。
• 具体と抽象(部分と全体)
• クリーンアーキテクチャ(依存の向き、関心の分離)
• MECEのダブりなく思想(※モレは拡張しやすく設計すること
で対処)
• KPIフレームワーク
• 設計原則
• トレードオフのための水平思考(今回カット)
• デザイン思考などなど
20XX/9/3 プレゼンテーションのタイトル 10

11. トピック2
苦労と工夫

12. 議論の空中戦
全く触れたことがないドメイン知識のビジネスで、
様々なステークホルダーが、
各々の関心事を話してしまっているため、
常に瞬間的に具体な視点と
抽象な視点とが行きかい、頭が混乱する。
本当にあっちこっち話が飛んでました汗
ある人は、めっちゃ具体に
ある人は、めっちゃに抽象に汗
プレゼンテーションのタイトル 12

13. ファシリテートの徹底工夫
全員の話を事細かに聞いていてはラチがあかないと感じ、
ドメイン知識もないから、
全員の視点が合わせやすい、リソースレベルに着目した。
まずはどのような既存情報システムや運用者含めた、
リソースがどのように振舞うのかを
リソースレベルでのアクティビティ図を描きながらヒアリング。
その中で出てきた重要なデータや状態もメモっておく。
20XX/9/3 プレゼンテーションのタイトル 13

14. 早い話がピラミッドストラクチャー
20XX/9/3 プレゼンテーションのタイトル 14

15. ボトムアップに抽象をくくりだす
リソースレベルのものを作成し、
一旦持ち帰って、
リソースに依存しないロジックや状態、データを抽出するために、
リソースレベルのアクティビティ図から抽象化して、
オペレーショナルレベルの業務フロー(業務戦術フロー)を描いた。
20XX/9/3 プレゼンテーションのタイトル 15

16. トピック2
やった方がいい
と思うこと

17. 貸出サービス(左が具体フロー、右が抽象フ
ロー)
20XX/9/3 プレゼンテーションのタイトル 17

18. 返却サービス(左が具体フロー、右が抽象フ
ロー)
20XX/9/3 プレゼンテーションのタイトル 18

19. SOLID原則思想の適用
リソースの登場概念(図書館スタッフや借出者)が、
対応するオペレーショナルレベルの活動をすべて実現しているかの
チェックをした後、実現関係のトレースをした。-リスコフ置換に基
づいた-
※まだこの段階で実現できてるかのチェックは不十分
さらにオペレーショナルの
登場概念を目的別に
分解した。
-interface分離-
20XX/9/3 プレゼンテーションのタイトル 19

20. 戦略ビューの要素を抽出
具体な戦術から、戦術に依存しない
活動を抽出する。
それが戦略interfaceの持つ
能力と結びついてるから。
持っているといえるための根拠の
指標をまず先に定義する。
20XX/9/3 プレゼンテーションのタイトル 20

21. 早い話がピラミッドストラクチャー
20XX/9/3 プレゼンテーションのタイトル 21

22. 要求に対する指標パラメタの定義
20XX/9/3 プレゼンテーションのタイトル 22

23. Operationalとリソースのトレーサビリ
ティ
20XX/9/3 プレゼンテーションのタイトル 23

24. ビジネスで必要なデータを抽出
本来は、この各ビューに対して
強い関心を持つステークホルダーに
対して、他にも重要なパラメタないか
ヒアリングする。
折衷方式で割り出す！！
ここからそのビジネスで必要なデータが割り出せる。
それをUAFではInformationという列に定義。
ビジネスアーキテクチャでは、データ要求まで最低限定義しなくて
はならない。
20XX/9/3 プレゼンテーションのタイトル 24

25. 2022/10/8 プレゼンテーションのタイトル 25

26. トップダウンからもアプローチ
Strategicビューよりさらに
１つ上位の目的からもトップダウンに要素を出していき、
先程までのボトムアップと混ぜ合わせた。
その中でStrategicビューに関心のあるステークホルダも
巻き込みながらヒアリング。
両軸からのアプローチが大事！！
(目的ありきでの手段、手段ありきでの目的
てだけでなく、時間が許すなら敢えて目的無視した手段とかを出す
のも手)
20XX/9/3 プレゼンテーションのタイトル 26

27. 観点ごとに、階層ごとのツリーをつくる
①要求ツリー
・動的な側面の要求
・静的な側面の要求
(データやPerformerなど)
リスク分析はどっちにもかかる要求。
②要求指標ツリー(要件ツリー)
③実績ツリー
(テストツリーと呼んでます)
20XX/9/3 プレゼンテーションのタイトル 27

28. (補足)Serviceビュー
Serviceビューでは、1つの貸出 or 返却て粒度でサービスを抽出。
そのService Functionを1つのリソースで実現するのか？
それとも複数のリソースで実現するのか？
この後者がSystem Of Systemsのスタイルです。
20XX/9/3 プレゼンテーションのタイトル 28

29. トピック3
まとめ

30. こだわったポイント
20XX/9/3 プレゼンテーションのタイトル 32
・依存の向きを厳守
・抽象度を揃える
・折衷方式
・トレーサビリティが取りやすいツリー作成
・設計原則の適用
・図形によるトレードオフ分析
(時間制約によりカット)

31. すべてのITを導入してる企業の社員に忘れないでほしい
こと
20XX/9/3 プレゼンテーションのタイトル 33
ビジネス、データ、アプリ、テクノ
各アーキテクチャ層を拡大すると、
戦略～リソースまでの層がある。
お願いだから、
自分の層で責務を全うせずとも
下の手段層でカバーすれば
イイっしょ
みたいに放棄しないで下さい。

32. UAFを使った
アーキテクチャや
DXコンサルの
オファーお待ちして
ます。
34

33. ありがとう
ございまし
た！
35
発表者名 工藤 ゆみ
Web サイト
https://qiita.com/Kudo_panda
Qiitaアカウント名 せやかて 駆動