ビジネスアーキテクトが身に着けるべきスキル

# 前提知見
価値駆動のモデリング手法である匠メソッドや、ステークホルダーの懸念点である脅威駆動でモデリングする脅威モデリングというワードが出てくるが、それらはググればすぐ出てくるので、ここでの説明は割愛します。

※　随時、思い出した際に「あ、この部分不足してた」という内容をつけ足していきます。

# エンタープライズアーキテクチャ目線
組織全体のアーキテクチャをエンタープライズアーキテクチャ(EAと略)という。
EAは、下図のようにビジネスアーキテクチャ～テクニカルアーキテクチャまでの4階層からなる。

<img width=600 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/6ac46909-3e84-7af9-7b11-c086ad4204e4.jpeg">

そしてその依存関係は、TA→AA→DA→BAという向きが望ましい。
ITアーキテクトの扱う、DA～TAの3階層は、上位のBAを成り立たせるための手段だからだ。
が、、、DXが進んでいない組織でよく見かけるのは、BAが下位の手段である
特定のITや人に依存しているような構造である。

BA上で「こんなビジネスモデルがいい」となっても、
下位の手段の層でそれが実現不可能なものであるならば、その結果を上位のBAに反映させなければならない。
そのため、ビジネスアーキテクトは実質他のアプリ層やデータ層とを行き来できるために、
他の層の知識も持っていなくてはならない。
特にAA層の知見はほぼマストと言ってもいいだろう。(他の層の知識がなくていいという意味ではない)

# ビジネスアーキテクトの責務範囲
責務の範囲はかなりの広範囲にわたる。
ざっくりいうと、PMやPMOとしての責務＋アーキテクト的責務が求められる。
しかもそれはプロセスの側面だけではなく、情報アーキテクチャの側面まで含まれる。
プロセスという機能的側面だけを見るだけでは、ビジネスを立体的に捉えているとは言えない。

ざっくりとその視野として含まれていないといけない範囲が何なのか？
わかりやすい思考のフレームワークが存在する。
UAFという大規模なシステムアーキテクチャ構築の際に、私が案件の中で使っていたものである。

<img width=600 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/2b4d4bbc-7940-36d9-fd08-fccc9162f134.png">

このUAFを使った思考プロセスに関しては以下の別記事を参照ください。

https://qiita.com/Kudo_panda/items/d02110649fd139c1d877

これをひとりで実現するのは、かなりしんどいし認知負荷も高い。
そのため、一部の責務をPMさんやスクラムマスター、エンジニアリングマネージャーに
なっていただかないと、質高く機能しない。

## 情報アーキテクチャ
ビジネス側のステークホルダーと議論する際に、データモデルを見せても有意義な議論にはなりにくい。
ステークホルダーが関心あるのは、データというそれ単体では意味をなさないものではなく、【情報(Information)】や複数の情報から得た法則性という【ナレッジ(知見)】である。
ナレッジと情報、データは以下のような階層構造になっている。

<img width=600 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/fbc98f72-e2c1-dc91-8eaf-2837f7f6aadc.png">

詳しくはここでは省くが、
ステークホルダーはどんな情報とプロセスがあれば、それを価値と感じるのか？
その両側面を匠メソッドの価値分析モデルの価値記述として記述できていることが望ましい。

情報に対しても、上記のUAFのような複数の抽象度と、複数の構造や流れ、状態の観点などで考察をしておく。
さらにカスタマージャーニーマップにおいて、各ステップごとにステークホルダーはどんな情報を欲するのか？を置かれている状況(物理環境条件など含め)も込みで考察しておく。

この情報アーキテクチャ自体が、データアーキテクチャのWhyとなるのだ。
いきなりデータアーキテクチャを考えても、ステークホルダーの価値との結びつきが見えず、論理が飛躍してステークホルダーには聞こえてしまうのだ。

ちなみに情報アーキテクチャに関しては、以下の本を一度手に取ってみてほしい。

![91o2mmnD4xL._SY425_.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/4d6861d3-3801-201b-3beb-2678a003663f.jpeg)


さらにデータ品質を考えるために通れない、情報品質の本も是非参考にしてほしい。
情報アーキテクチャを考えるために必要なものだからだ。
![41NCtqVKEWL._SY466_.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/8afebdd0-3607-49f9-3ae7-f912ca577cd7.jpeg)



# ファシリテーションスキル
モデリングをしながら問いかけをしたりするなど、ファシリテーターとしても任務したりする場面がある。
ファシリテーションだけできてもモデルとして可視化するスキルがないとダメだし、
アーキテクチャ考えられても、正確に非機能面踏まえたヒアリングができていないと
アーキテクチャ上に重要な保証されるべき品質特性が反映されているのか？
を検討できなくなります。

# ステークホルダーモデリング
わたしがここでいうステークホルダーモデリングには、以下の図のようなステークホルダーマネジメントや後述の匠メソッドで使う価値駆動モデル、ステークホルダーの不安要素を扱うための脅威分析など幅広く求められる。

<img width=400 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/f9918257-769e-0182-f625-2be65b424cd3.png">

なぜなら、それらはアーキテクチャ(ここでいうアーキテクチャとは、システムだけのスコープではなく、組織全体のアーキテクチャ)を決定づける重要なアーキテクチャアドライバとなるから、ビジネスアーキテクトが正確に把握できていないといけない。

## 推論技術
推論に使う、帰納法・演繹法、アブダクションの３つは、
精度の高い要求定義の際に必須のものである。

インスタンスレベルの具体的な、総務の田中さんという方の要求ではなく、
総務という組織の中のヒトとして、どんな要求を満たす必要があるのか？
を明らかにする必要があるからだ。

この内容については、以下の記事などとセットで参照ください。

https://qiita.com/Kudo_panda/items/a57522bdb04d871f184e

詳しい内容はここでは省きます。

# 脅威モデリングスキル
OWASPなどのイベントで最近よく使われている脅威モデリングは、
セキュリティエンジニアがよく攻撃者目線で使っている印象が強いかもしれないが、
実はそんなことなくて、あらゆるステークホルダー目線での脅威(懸念事項)を可視化し、
その中でリスクになるものを見つけ出し、保証されるべき品質特性を明らかにする。

アプリ層における振る舞いの観点での品質特性(非機能)と、
データ層における品質特性のWhyとなるものを脅威モデリングを使って可視化するのだ。

それがないと、どんなログを集めるべきなのか？　とか
どういったメトリクスを監視すべきなのかさえ分からなくなる。

脅威モデリングのやり方に関しては、以下に記載する。

https://qiita.com/Kudo_panda/items/e9d3786add67abbc66df

https://qiita.com/Kudo_panda/items/5f71c9dc69c1f5de7dbd

ビジネスアーキテクトが率先して、アプリの非機能の土台となるプロセス面のリスク、
データになる前の情報の品質特性などの土台となる情報面のリスクを様々なチームを巻き込んで、マネジメントする姿勢が求められる。

ちなみに脅威の側面だけでなく、価値の側面からの考察も必要であり、
そのための必要スキルは次に記載する。

# 価値駆動モデリングスキル
これは匠メソッドという、萩本さん考案の価値を起点として要求などを洗い出しましょうという考え方。
詳細は省くが、各ステークホルダーにとっての価値を可視化し、
因果関係のツリー構造にまとめ上げることで、どの要求に選択集中して実現したら
良さそうか？　やステークホルダー間の価値の関係性などを可視化する支援になってくれるフレームワークである。

この匠メソッド単体では、スクラムのように枠組みだけを提供しているので、
自分たちの置かれた環境に応じて、他のモデル(ステークホルダーマップやTOCの思考プロセスツリーなど)などと組み合わせて使用することによって、より威力を発揮し、精度の高い要求分析を可能にする。

ただし、価値の側面だけでなく、上記の脅威分析を行った上での懸念リスクの側面
と両方からプリズムのように評価した上で、施策を実行に移すのかどうかの判断をしないといけない。
そしてその判断をビジネスアーキテクトは、他のアプリやデータアーキテクトと密な連携をしながらしなくてはならない。

## データの利活用とGQMの考え方
最近話題として増えてきたと感じるデータ利活用は、手段ばかり取り上げられがちだが、
匠を使った企画工程が非常に重要であると感じている。

データになる以前の「ステークホルダーにとって価値ある情報資源は何か？」を
価値分析モデルを使って明らかにし、
その後「その情報はどのようなデータがあれば構成可能か？」と材料となるデータを
GQMストラクチャーを使って明らかにし(GQMの考え方は以下の記事参照)、
どのようなプロセスでデータが加工されて価値ある情報が完成するのか？
というレシピを考えるのである。

https://qiita.com/Kudo_panda/items/7d8158faac806887dc4c

これはデータエンジニアと密なコラボをすることで、仮説ベースで明らかにすることになる。
最初考えたデータセットでは、もしかしたら必要な情報は完成しないかもしれない。
それに価値以上に無駄に収集コストがかかるかもしれない。
しかしながら、それらの失敗から学びを得て、ステークホルダーにとって価値ある情報を
企画・要件定義しつづけるスタンスやファシリテートするスキルが、
ビジネスアーキテクトには求められる。

:::note warn
ちなみにデータ利活用の際には、その際の脅威分析の両側面からの考察をした上で、相対的に価値の方が上回ると判断した場合に、初めて実行に移すというプロセスを踏むことを推奨する。
:::

# QA的活動スキル
品質要求分析をシステムのレイヤーからではなく、ビジネスアーキテクチャ層から考える。

上記の脅威モデリングや匠Methodの価値駆動モデリングによって、
ハッピーシナリオ、バッドシナリオののカスタマージャーニーマップをそれぞれ描き、
ステークホルダーにとっての強い品質要求を分析する。

そのWhyがあるからこそ、システムに求められる非機能、データの品質特性が明らかになってくる。

そのような企画段階からの品質の分析活動のスタイルが求められるし、
案として出てきたアーキテクチャからボトムアップに「このアーキテクチャのデメリットはパフォーマンスが遅いことであり、それはこのステークホルダーの要求として抜けもれてることではないか？」と、すぐさま要求の方にフィードバックをかける活動も求められる。


# 業務のモデリング
## BPM 業務プロセスモデリング
業務のモデリングをプロセスの静的な構造と、プロセス同士の動的なやり取りの観点(フローチャートなど)とで両方から行う。

この辺りは、BPRコンサルの担当領域とも言えるが、ビジネスアーキテクトの責任範囲として重要な部分である。
プロセスの方が、システムに詳しくないステークホルダーに対しては、データよりも共通認識がはかりやすい。

その際には

:::note info
イベントストーミング手法を使うことをお勧めする。
:::

理由は、イベント系の流れに着目することで、イベントの抜け漏れを防ぎやすくなり、
かつイベントストーミングでは、最初からポリシー系(〇〇規約とか)を関心分離しているため、ドメインモデルの時点からの負債の根源を小さくしやすいからです。

プロセスの静的な側面・動的な側面のどちらからモデリングを行ってもいいが、
まずは私的には業務の流れに着目した方が、ヒアリングなどから現状分析を行う際などの場面ではコミュニケーションがとりやすい。

その際には、アクティビティ図を用いると現状は誰が何のプロセスを責務として持っているのかが把握しやすいと感じる。

### 事前条件・事後条件・不変条件の定義
よくあるように感じる現象なのだが、業務分析をモデリングを用いて行う際に、
フローチャートなりアクティビティ図を用いて可視化していたとしても、
事前条件と事後条件を定義していないモデル図をよく目にする。

この定義は後工程のシステム化の段階で曖昧さを生むだけでなく、
実際にシステムを使うアクターにとって目的が達成できたのか？をうやむやにしてしまう。

<img width=400 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/b601cb33-abe7-d16a-c940-ebe4ee657aa4.png">

上図がまさにそうだが、一番最初の●黒丸。
ここにその業務フローの開始条件の状態を必ず定義する。
そして、最後の黒丸には終了条件を必ず定義する。
でないと、そのフローが何を持って開始されるのか？何をもって終了するのか？
それが定義されていないために、ユースケースの事前・事後条件が未定義なままになってしまう。

またそれ以外にも、この業務フローが実行中に普遍的に変わらない事実、
たとえば「執筆者の勤務ステータス状況が正規雇用中のままである」などといった
フローの走っている最中に不変な条件も忘れずに定義する。

これら３つを忘れてシステム化を進めようとしても、手戻りが発生してしまうので、
不明だから他の業務フロー分析を先に行うとかっていうように、
後でまた検討しようってスタンスならいいが、未定義な状態は絶対にダメ！

## 業務データのモデリング
業務を理解するにはプロセスの側面だけでなく、その業務中でやり取りされる情報も大事である。
データの側面からの分析も必須である。
いきなりデータとして考えるのではなく、どんな情報がその業務を成り立たせているのか？
データになる以前にどのような情報が業務の中でやりとりされるのか？
それをDFDやER図を用いて明らかにする。
このあたりの流れは、UAFの思考プロセスと同様。

## 条件分岐
フローチャートやDFD中で条件分岐があるのなら、それも忘れずに記載しておく。
なんでかというと、イベントストーミングだけではポリシー系の要素を考慮漏れが起きる可能性がある。

そこで、このフローチャートなどの中で発生する条件分岐を見つけることで、
必ずその分岐が走る裏には何かしらのポリシーに沿って【～ならば次のステップへ】
などの判断がされているとなり、ポリシー系の概念の考慮漏れを抑制できる。

## 状態図
そのデータがどんな状態を持ち、どのプロセスによってどの状態に変化するのか？
またその状態として認識されるのは、データがどの変域に収まっている時なのか？
を明らかにする。

# 企画段階におけるECRS原則の適用
事業戦略を満たす業務フローを可視化し、その中でどの部分をシステム化したらいいのか？
などの検討をする。
上記で各コンテキストごとに切り分けたチームの中という狭いスコープだけで考えるのではなく、あくまでも全体を俯瞰した上で、どこの部分に対して業務プロセス改善を行うのが良いのか？を検討した上で、そこをズームインした、より詳細なプロセスに対してECRSを適用するのだ。

その際に、いきなシステム化のスコープを検討せずに、まずはECRS原則に従って、
削れるところや、分割または統合できるプロセスを明らかにした上で、
フローの流れを変えたりしてから、システム化のスコープを定義する。

## なぜシステム化するのかをADR的に残す
さらにそのなぜシステム化したいのか？
だれにとってそれは価値があるのか？　などの情報をADR的に残す必要がある。
さらに失敗を小さくできるように、小さくシステム化していく。


# KPIマネジメントスキル

# 設計原則集
書籍：プリンシプルオブプログラミングやクリーンアーキテクチャなどに記載された
設計原則集は、何もアプリケーションアーキテクチャ層にだけ適用できるものではない。
ビジネスアーキテクチャ層においても、単一責務となるような設計思想や、
ある部門の業務プロセスが変更されても、他への影響をないようにするといった
開閉原則の思想は必要である。

さらにチームの認知負荷の限度を把握した上で、あえてチームに多重責務状態にするのか？
それとも素早いデリバリーのために単一責務となるようにするのか？
(例：マイクロサービス１つを１つのチームに運用担当させるなど)
といった考察をしなくてはならない。

## 関心の分離
事実、EAモデルの4階層をもう一度よく見てほしい。

<img width=600 alt="ファイル名" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781175/6ac46909-3e84-7af9-7b11-c086ad4204e4.jpeg">

もうこの時点で、マクロなレベルでそれぞれの階層で関心が分かれているのにお気づきだろうか？

## クリーンアーキテクチャ
書籍クリーンアーキテクチャに書かれた原則集は、
ビジネスアーキテクチャを運用しやすくするためにも絶対に抑えておいた方がいい。

# タレントアーキテクチャ
AI中心のビジネス～～とかって言われるようになってきてはいるものの、
やっぱりまだ組織は人と情報システムの集合から構成されている。
組織の内部にいる従業員、すなわちタレントたちが、どのチームに配属されたら、
強みを発揮しやすく、逆にどのチームに配属されると弱みが強調されやすいのか？

そのタレントの特性に応じて、人の配置関係を考えなくてはいけない。
これは人材育成や、どんな特性でどの程度のスキル感のヒトを採用したらいいか？
どんなキャリアの方向性を描いている人がいいのか？
といったことなど含めて描けていると、ヒトの要件定義そのものになり、
採用の時のミスマッチなどが起こりにくいことにも繋がる。


# チームトポロジー
## チームの境界範囲の設計
そのチームに割り当てるプロセス群と、データをマイクロサービスの設計思想を用いて明らかにする。
この時にそのチームが他のチームに対してどのような責務を持つのか？
というチームトポロジーの思想がマストになってくる。

# コミュニケーションパスの設計
コンウェイの法則を理解した上で、ビジネスアーキテクトは逆コンウェイ戦略を用いて、組織構造とシステムアーキテクチャの両方を改善していかなくてはならない。

https://zenn.dev/offersmgr/articles/11446a55243d6a

上記のようなコミュニケーションパスの現状を可視化してくれるツールを用いて、
常に組織構造を可視化できるようにしておく。
そうすることで、システムアーキテクチャとの相似形が成り立っていない所はどこなのかも分かりやすくなる。