エンタープライズアーキテクチャ目線
組織全体のアーキテクチャをエンタープライズアーキテクチャ(EAと略)という。
EAは、下図のようにビジネスアーキテクチャ～テクニカルアーキテクチャまでの4階層からなる。
そしてその依存関係は、TA→AA→DA→BAという向きが望ましい。
ITアーキテクトの扱う、DA～TAの3階層は、上位のBAを成り立たせるための手段だからだ。
BA上で「こんなビジネスモデルがいい」となっても、
下位の手段の層でそれが実現不可能なものであるならば、その結果を上位のBAに反映させなければならない。
そのため、ビジネスアーキテクトは実質他のアプリ層やデータ層とを行き来できるために、
他の層の知識も持っていなくてはならない。
特にAA層の知見はほぼマストと言ってもいいだろう。
ビジネスアーキテクトの責務範囲
責務の範囲はかなりの広範囲にわたる。
ざっくりいうと、PMやPMOとしての責務＋アーキテクト的責務が求められる。
しかもそれはプロセスの側面だけではなく、情報アーキテクチャの側面まで含まれる。
ざっくりとその視野として含まれていないといけない範囲が何なのか？
わかりやすい思考のフレームワークが存在する。
UAFという大規模なシステムアーキテクチャ構築の際に、私が案件の中で使っていたものである。
このUAFを使った思考プロセスに関しては以下の別記事を参照ください。
これをひとりで実現するのは、かなりしんどいし認知負荷も高い。
そのため、一部の責務をPMさんやスクラムマスター、エンジニアリングマネージャーに
になっていただかないと、質高く機能しない。
ファシリテーションスキル
モデリングをしながら問いかけをしたりするなど、ファシリテーターとしても任務したりする場面がある。
ファシリテーションだけできてもモデルとして可視化するスキルがないとダメだし、
アーキテクチャ考えられても、正確に非機能面踏まえたヒアリングができていないと
アーキテクチャ上に重要な保証されるべき品質特性が反映されているのか？
を検討できなくなります。
ステークホルダーモデリング
わたしがここでいうステークホルダーモデリングには、以下の図のようなステークホルダーマネジメントや後述の匠メソッドで使う価値駆動モデル、ステークホルダーの不安要素を扱うための脅威分析など幅広く求められる。
なぜなら、それらはアーキテクチャ(ここでいうアーキテクチャとは、システムだけのスコープではなく、組織全体のアーキテクチャ)を決定づける重要なアーキテクチャアドライバとなるから、ビジネスアーキテクトが正確に把握できていないといけない。
推論技術
推論に使う、帰納法・演繹法、アブダクションの３つは、
精度の高い要求定義の際に必須のものである。
インスタンスレベルの具体的な、総務の田中さんという方の要求ではなく、
総務という組織の中のヒトとして、どんな要求を満たす必要があるのか？
を明らかにする必要があるからだ。
この内容については、以下の記事などとセットで参照ください。
詳しい内容はここでは省きます。
脅威モデリングスキル
OWASPなどのイベントで最近よく使われている脅威モデリングは、
セキュリティエンジニアがよく攻撃者目線で使っている印象が強いかもしれないが、
実はそんなことなくて、あらゆるステークホルダー目線での脅威(懸念事項)を可視化し、
その中でリスクになるものを見つけ出し、保証されるべき品質特性を明らかにする。
アプリ層における振る舞いの観点での品質特性(非機能)と、
データ層における品質特性のWhyとなるものを脅威モデリングを使って可視化するのだ。
それがないと、どんなログを集めるべきなのか？ とか
どういったメトリクスを監視すべきなのかさえ分からなくなる。
脅威モデリングのやり方に関しては、以下に記載する。
ビジネスアーキテクトが率先して、アプリの非機能の土台となるプロセス面のリスク、
データになる前の情報の品質特性などの土台となる情報面のリスクを様々なチームを巻き込んで、マネジメントする姿勢が求められる。
ちなみに脅威の側面だけでなく、価値の側面からの考察も必要であり、
そのための必要スキルは次に記載する。
価値駆動モデリングスキル
これは匠メソッドという、萩本さん考案の価値を起点として要求などを洗い出しましょうという考え方。
詳細は省くが、各ステークホルダーにとっての価値を可視化し、
因果関係のツリー構造にまとめ上げることで、どの要求に選択集中して実現したら
良さそうか？ やステークホルダー間の価値の関係性などを可視化する支援になってくれるフレームワークである。
この匠メソッド単体では、スクラムのように枠組みだけを提供しているので、
自分たちの置かれた環境に応じて、他のモデル(ステークホルダーマップやTOCの思考プロセスツリーなど)などと組み合わせて使用することによって、より威力を発揮し、精度の高い要求分析を可能にする。
ただし、価値の側面だけでなく、上記の脅威分析を行った上での懸念リスクの側面
と両方からプリズムのように評価した上で、施策を実行に移すのかどうかの判断をしないといけない。
そしてその判断をビジネスアーキテクトは、他のアプリやデータアーキテクトと密な連携をしながらしなくてはならない。
データの利活用とGQMの考え方
最近話題として増えてきたと感じるデータ利活用は、手段ばかり取り上げられがちだが、
匠を使った企画工程が非常に重要であると感じている。
データになる以前の「ステークホルダーにとって価値ある情報資源は何か？」を
価値分析モデルを使って明らかにし、
その後「その情報はどのようなデータがあれば構成可能か？」と材料となるデータを
GQMストラクチャーを使って明らかにし(GQMの考え方は以下の記事参照)、
どのようなプロセスでデータが加工されて価値ある情報が完成するのか？
というレシピを考えるのである。
これはデータエンジニアと密なコラボをすることで、仮説ベースで明らかにすることになる。
最初考えたデータセットでは、もしかしたら必要な情報は完成しないかもしれない。
それに価値以上に無駄に収集コストがかかるかもしれない。
しかしながら、それらの失敗から学びを得て、ステークホルダーにとって価値ある情報を
企画・要件定義しつづけるスタンスやファシリテートするスキルが、
ビジネスアーキテクトには求められる。
ちなみにデータ利活用の際には、その際の脅威分析の両側面からの考察をした上で、相対的に価値の方が上回ると判断した場合に、初めて実行に移すというプロセスを踏むことを推奨する。
業務のモデリング
BPM 業務プロセスモデリング
業務のモデリングをプロセスの静的な構造と、プロセス同士の動的なやり取りの観点(フローチャートなど)とで両方から行う。
この辺りは、BPRコンサルの担当領域とも言えるが、ビジネスアーキテクトの責任範囲として重要な部分である。
プロセスの方が、システムに詳しくないステークホルダーに対しては、データよりも共通認識がはかりやすい。
その際には
イベントストーミング手法を使うことをお勧めする。
理由は、イベント系の流れに着目することで、イベントの抜け漏れを防ぎやすくなり、
かつイベントストーミングでは、最初からポリシー系(〇〇規約とか)を関心分離しているため、ドメインモデルの時点からの負債の根源を小さくしやすいからです。
プロセスの静的な側面・動的な側面のどちらからモデリングを行ってもいいが、
まずは私的には業務の流れに着目した方が、ヒアリングなどから現状分析を行う際などの場面ではコミュニケーションがとりやすい。
その際には、アクティビティ図を用いると現状は誰が何のプロセスを責務として持っているのかが把握しやすいと感じる。
事前条件・事後条件・不変条件の定義
よくあるように感じる現象なのだが、業務分析をモデリングを用いて行う際に、
フローチャートなりアクティビティ図を用いて可視化していたとしても、
事前条件と事後条件を定義していないモデル図をよく目にする。
この定義は後工程のシステム化の段階で曖昧さを生むだけでなく、
実際にシステムを使うアクターにとって目的が達成できたのか？をうやむやにしてしまう。
上図がまさにそうだが、一番最初の●黒丸。
ここにその業務フローの開始条件の状態を必ず定義する。
そして、最後の黒丸には終了条件を必ず定義する。
でないと、そのフローが何を持って開始されるのか？何をもって終了するのか？
それが定義されていないために、ユースケースの事前・事後条件が未定義なままになってしまう。
またそれ以外にも、この業務フローが実行中に普遍的に変わらない事実、
たとえば「執筆者の勤務ステータス状況が正規雇用中のままである」などといった
フローの走っている最中に不変な条件も忘れずに定義する。
これら３つを忘れてシステム化を進めようとしても、手戻りが発生してしまうので、
不明だから他の業務フロー分析を先に行うとかっていうように、
後でまた検討しようってスタンスならいいが、未定義な状態は絶対にダメ！
業務データのモデリング
業務を理解するにはプロセスの側面だけでなく、その業務中でやり取りされる情報も大事である。
データの側面からの分析も必須である。
いきなりデータとして考えるのではなく、どんな情報がその業務を成り立たせているのか？
データになる以前にどのような情報が業務の中でやりとりされるのか？
それをDFDやER図を用いて明らかにする。
このあたりの流れは、UAFの思考プロセスと同様。
条件分岐
フローチャートやDFD中で条件分岐があるのなら、それも忘れずに記載しておく。
なんでかというと、イベントストーミングだけではポリシー系の要素を考慮漏れが起きる可能性がある。
そこで、このフローチャートなどの中で発生する条件分岐を見つけることで、
必ずその分岐が走る裏には何かしらのポリシーに沿って【～ならば次のステップへ】
などの判断がされているとなり、ポリシー系の概念の考慮漏れを抑制できる。
状態図
そのデータがどんな状態を持ち、どのプロセスによってどの状態に変化するのか？
またその状態として認識されるのは、データがどの変域に収まっている時なのか？
を明らかにする。
企画段階におけるECRS原則の適用
事業戦略を満たす業務フローを可視化し、その中でどの部分をシステム化したらいいのか？
などの検討をする。
上記で各コンテキストごとに切り分けたチームの中という狭いスコープだけで考えるのではなく、あくまでも全体を俯瞰した上で、どこの部分に対して業務プロセス改善を行うのが良いのか？を検討した上で、そこをズームインした、より詳細なプロセスに対してECRSを適用するのだ。
その際に、いきなシステム化のスコープを検討せずに、まずはECRS原則に従って、
削れるところや、分割または統合できるプロセスを明らかにした上で、
フローの流れを変えたりしてから、システム化のスコープを定義する。
なぜシステム化するのかをADR的に残す
さらにそのなぜシステム化したいのか？
だれにとってそれは価値があるのか？ などの情報をADR的に残す必要がある。
さらに失敗を小さくできるように、小さくシステム化していく。
KPIマネジメントスキル
設計原則集
書籍：プリンシプルオブプログラミングやクリーンアーキテクチャなどに記載された
設計原則集は、何もアプリケーションアーキテクチャ層にだけ適用できるものではない。
ビジネスアーキテクチャ層においても、単一責務となるような設計思想や、
ある部門の業務プロセスが変更されても、他への影響をないようにするといった
開閉原則の思想は必要である。
さらにチームの認知負荷の限度を把握した上で、あえてチームに多重責務状態にするのか？
それとも素早いデリバリーのために単一責務となるようにするのか？
(例：マイクロサービス１つを１つのチームに運用担当させるなど)
といった考察をしなくてはならない。
タレントアーキテクチャ
チームトポロジー
チームの境界範囲の設計
そのチームに割り当てるプロセス群と、データをマイクロサービスの設計思想を用いて明らかにする。
この時にそのチームが他のチームに対してどのような責務を持つのか？
というチームトポロジーの思想がマストになってくる。
コミュニケーションパスの設計
コンウェイの法則を理解した上で、ビジネスアーキテクトは逆コンウェイ戦略を用いて、組織構造とシステムアーキテクチャの両方を改善していかなくてはならない。
上記のようなコミュニケーションパスの現状を可視化してくれるツールを用いて、
常に組織構造を可視化できるようにしておく。
そうすることで、システムアーキテクチャとの相似形が成り立っていない所はどこなのかも分かりやすくなる。