要件定義招待LT

1. システムオブシステムズで
ちょいちょいSoSだった話
モデリング事業部
工藤 由
美

2. DDDの思想は、
アプリサイドで考えるのでなく、
そもそもビジネスアーキテクチャから取
り入れるべきもの。
ビジネスアーキテクチャの形から
クリーンにする。
-工藤 理論

3. 自己紹介
【仕事】
モデリングやアーキテクチャを売りにしてる中小企業で
システムオブシステムズのビジネスアーキテクト兼コンサルとして企画～要件定義の支
援担当。
ビジネス層からDDDやクリーンアーキテクチャの思想を盛り込む活動を布教中。
【趣味】 独自方法論の確立や既存の思想のカスタマイズ、
ラウドロックやハードコア(重たいサウンドのもの)を聴いたり創ったり(Ba&Dr編曲)。
最近、ずっと音楽活動できてない💦

4. システムオブシステムズとは
System of Systems（SoS）とは、
独立した複数のシステムが相互に連携して
一つの大規模なシステムを構成することを指します。
SoSは、個々のシステムが持つ機能を拡張することによって、
より高度で複雑な機能を実現することができます。
ちょっと何言ってるかワカンナイて方向けに次で図解します。
（結構いろんなとこでこれ使われてます）

5. システムオブシステムズの図解①
2024/2/21

6. システムオブシステムズの図解②
人も１つのリソース、システムと考え
る。
右図は
エンドユーザーはITシステム使わない、
ユーザーだけがITシステム使うって
ケース。
緑枠がSoSのシステム境界。
2024/2/21

7. システムオブシステムズの図解③
2024/2/21

8. システムオブシステムズの図解③’
2024/2/21

9. UAFについて
Unified Architecture Framework
の頭文字の略。
SoSを前提に創られているが、
個人的にはあらゆるとこで使える。
Enterprise Architecture framework
に非常に似た統一FW。
抽象から具体のレイヤー構造。
１つのシステムはリソースて考える。

10. 最初の個人的課題
・UAFについての知見が個人の経験として足りていなかった。
・ユースケース駆動(ICONIXプロセス)くらいのモデリング力しか充分に
はなかった。
・UAF文献も充分ではなく、自分たちで方法論を確立していくしかな
かった。
・その中で別の課題を抱えた他のSoS案件も同時稼働。
・抽象度を揃えるにしても、他人と自分とでは粒度が異なる。
・ヒアリングやファシリ時も、みなの視点を合わせることにも当初非常
に苦労した。

11. 案件に存在した課題点
調整すべきステークホルダーの人数が少なく、
協力的なステークホルダーが参画してきてくれたおかげで
様々な方法論の確立、アーキテクチャ方針の全体像の解像度を上げるには至ったが、
対象ドメインが普段触れないような複雑系SoSビジネスであり理解に多大な時間がか
かったこと。
対象ビジネスがそもそもどんなビジョンを満たしたいのか？
アーキテクチャガイドが浸透しておらず全体のモデルに一貫性が存在していなかった。

12. UAFの欠点と利点
【欠点】
・学習コストが高い。粒度揃えたり～～etc
・モデルの整合性を保つのがやや時間がかかる。
・FWなのでこれ単体ではどうにもならない。ファシリテーションや【具体と抽象】などと組
み合わせて使うもの。
【利点】
・強制的に設計力が上がりやすい。(RDRAや匠などの他のフレームワークと相性抜群)
・ステークホルダーの関心事の整理にもなり、トレードオフ考察しやすい。
・Unfiedだから自分たちで状況に応じてカスタマイズ拡張などもできる。
などなど０ベースでモノを作るのが好きな人は向いているように感じます。
2024/2/21

13. 偶然に偶然が重なった幸運
・クライアント先が非常に協力的で思想がアジャイルであったこと。
・直前にクリーンアーキテクチャ本、具体と抽象、問題発見力の書籍をじっくり読みこ
んでいたこと。
・〇〇シンキングのようなMECEをベースとした思考の講座をUdemyなどでやっていた
こと。
・直感的に必要そうと思ってやったRDRA、匠メソッドがヒントになったこと。
・そもそも論、実務開発経験ほぼない自分をアーキテクトとしてアサインさせてもらえ
たこと。
・大変だったけども、複数の案件が相乗効果でアーキテクトの実力を底上げしてくれる
内容であったこと。

14. 閃いて取り入れた工夫①
クリーンアーキテクチャの思想、MECEなどを取り入れながら確立していった。
解析性含めたメンテナンス性を向上させるための仕掛けとして、以下を適用。
・最上位抽象からのトップダウン、具体システムからのボトムアップの折衷方式
・目的に複数のコンテキスト概念が混ざっていたら粒度揃うよう分離する、interface分離思想
・各層の概念の重複を徹底排除(MECEのダブりなく)
・モレは後から追加しやすい仕組みとして、新しい概念は上位の目的を満たすように実現(リス
コフ置換原則)
・必ず下位→目的となるように粒度を揃えて(SLAP原則)依存関係も厳守(安定依存)

15. 閃いて取り入れた工夫②
・コンテキスト図の導入
・各要素の動機である価値のモデル作成
・全体の一貫性を見れるトレーサビリティマップ作成
・設計方針となる思想のドキュメント作成
(ガイドラインが存在していなかったため)
・抽象概念から出てきた手段概念要素を追加導入(部分的に)

16. コンテキスト図
システムオブシステムズでは、
ポンチ絵レベルでいいから
コンテキスト境界の描かれた図
がマジで大切！！
共有してる部分が認識できるから。

17. 図のズームレベルを意識
先程の図には右図にこんな風に
描いては粒度の秩序が無くなる。
重複部分にあるちっこいシステムは
このコンテキスト図の粒度では
細かすぎるから描かない！
(図においてもSLAP原則を適用)
※緑と黒合わせてさらに巨大なSoSとして
扱うこともある。

18. 目的粒度が異なるものは分ける

19. 次にトライしたいこと
・もっともテコ入れすべき問題の計画およびマネジメント
・セキュリティ含めたリスク要素分析を
各ステークホルダに行い、そこから品質副特性を明らかにしていく。(トレードオフ込みで)
さらにそれだけでなく、
・ユーザーが「そう！これが欲しかった体験なの！」っていう今まだない品質などの概念。
【問題発見】でその概念変数を見つけ、匠メソッドをカスタマイズしたものを確立
・トレードオフ分析の図形的方法論確立(ほぼ完成)
・仮説検証用のデータを管理するデータマネジメント案件
・書籍の執筆(ネタを構想中)

20. 今後の登壇予定
5/25(木曜)
エンジニアリングマネジメントについてLT！ TechDLT Vol.11
6/15(木曜)
上流工程なんでもLT！ TechnicalDirectorMeetup Vol.4
2024/2/21

21. Qiita:@Kudo_panda
コミュニティ:YKMCやるわよ駆
動
他所属コミュニティ:SE4BSな
ど