前置き
以下のイベントに参加してきたので、そこでの得た知見と、
その知見を通して得た学びを記録として残しておく。
不確実さと複雑性の増大
VUCAの中では、ゆっくり数年かけてAsIs→ToBe分析はやっても意味なし。
理由
変化のパラメタがどんどん増えている。(変数が多い)
データの量と種類がどんどん膨らんでいる。(データの境界位置が探りにくい)
データの量と種類が増えるだけなら、通信の問題で済む話だが、
データの量と種類が増える ≡ それを使うソフトウェアの数と種類が増える
事実、対応しないといけない領域の範囲や
アプリケーション同士の接続、企業の壁を越えたシステム同士の接続など
相互運用性などがより一層求められる。
実際問題、筆者はあるエンタープライズの大規模システムの再設計案件で、
これを痛いほど体験しました。
複雑さへの対応の過去と問題
ソフトウェア開発が複雑というのは、もうかれこれ何十年も言われてきた。
それへの対抗策として、モデリングやアジャイルなどの開発手法、設計パターンなどがたくさん出てきた。
しかし、これらだけでは太刀打ちできなくなってるのが現状問題。
そこから言えること
上記ゆえに変化の因果関係や範囲があいまいになっている。
どこで何が変化するのか？
変化したことで、どこにその影響が波紋するのか、あいまいな中でソフトウェア開発しないといけない。
同時に、その中から本当に大事な変数(俗にいう真因や制約部分)を見出すのも難しい。
年単位でAsIs業務分析をして、ToBeへ向かうなんてことは、このVUCA環境の中ではありえないことである。
ToBeへ到達したころには、外部環境は大幅に変わってしまっている。
なぜソフトウェア開発が予測しにくくなったか
今と昔のITの立ち位置の変化
昔は事業活動の中の一部をシステムって考えてた。
たとえば、図書館の司書さんが使ってた蔵書貸出返却管理システムとかがその一例と感じる。
しかしながら、
いまはあらゆる事業活動とシステムが一体化。
現実的に、事業活動の一部だけをシステム～なんてことは成立していない。
これは何もすべての事業活動をデジタル化しろって話ではない
つまり、事業活動とItが密接に関連づいていることによって、
システム開発と運用は、事業の競争優位性強化の直接的手段であり、同時に競争優位を失う直接原因でもある。
事実、ITが事業のボトルネックになってる事例は多々ある。
事業観点におけるデジタル化進展によるエンジニアの立ち位置
ITエンジニアが今は事業活動の当事者である。
これはBPRコンサルがソフトウェア知見がないといけないということでもあるし、その逆でもあると感じる。
エンジニアの日々の行動と判断が事業の業績を持続できるかが決まってくる。
これは事業の持続可能性という変数に関わってくる。
従来アプローチの問題点
モデリング手法
ここは自分がモデリングを生業としているので、一瞬ヒヤッとしました。
下図のようにモデリングだけでもこんなにある。
確かにこれらの関係性を把握したり、それぞれのモデル図の用途を学ぶことは私も価値があると感じている。
ただし、いろんなモデリング技法を高度に使いこなしても、致命的欠陥がある。
上図は、いろんなモデルのメタモデルになっている。
固定属性というのは、変化しない属性。
変動属性は変わりやすい属性。
これを用途に合ったモデル図で表現していくのが一般的なモデリングである。
ただし、そのどのモデルもWhy事業視点が抜けている。
どういうものをつくるのか？というWhatまでにとどまっていた。
この6W2Hをモデリング技法で表現しても、Whyは表現できない。
以上が従来のモデリングアプローチの特徴であるとのこと。
この部分への主張
でも匠やRDRAとの組み合わせでそれは避けられるのでは？とも感じた。
実際問題、わたしは案件の中で価値 ← 要求 ← 要件という依存関係を厳守するトレーサビリティマップを作成することと、工夫したファシリテーションの２点で、モデル図の目的を見失わないようにコントロールできた経験がある。
VUCAの中でどう設計していくか
事業成果
これはビジネスアーキテクトとしての非常に関心の強い内容であった。
事業の成果＝持続的な高い業績＝競争優位性の獲得と維持
ソフトウェア開発運用を事業、なんだったら経営視座でとらえる
システムは持続的に高業績を生み出すための直接的手段であるからだ。
持続的にお金がもうからない事業は事業として成立しない。
お金さえ儲かればいいとは言っていない。
SDGsなどお金を儲けつつも環境問題にメスを入れてる企業は昨今多い。
そのためには、
①競争優位の獲得と維持
②どう設計したら競争劣化を緩和できるのか？
を考える必要がある。
主張
①の方は3Cや5フォース分析、SWOT分析によって、
競争優位性としての自社の強みや外部脅威などを把握したうえで、
どの活動が価値として成立し、それが強みであるかをバリューチェーンモデルで可視化し、
ドメインモデリングを行う必要があると強く感じている。
このあたりは別記事で改めて個人の見解としてまとめる。
俗にいう、システム内のコアドメインといわれる奴は、
その組織のコアコンピタンスの業務活動を直接的に支援するものである。
ゆえにそこのメンテコストがかかりすぎれば価値あるコア業務の足を引っ張り、
かかるコストが低ければ価値あるコア業務を強く支援する。
設計の3つの評価基準
VUCAの中で事業視座で俯瞰して設計していくためには以下の３つの評価基準があるという。
この整合させるという話は、**システムアーキテクチャ構築の原理**に記載されている以下の図のことを指していると思われる。
事業課題が要求に、設計判断がアーキテクチャに対応している。
合目的性
ISOなどの規格の中では、機能適合性と言われている。
どのくらい要求に設計がフィットしているのか？という指標。
これは、そもそもの要求とその前提のステークホルダー価値を正確にイシューとしてとらえていないと成立しない。
経済性
利益を生み出すために、コストをかけるべき箇所とそうではない箇所という感じで明確な境界で分離された構造によって実現される。
これによって、どこにどの程度リファクタリングコストをかけるのか？なども決まってくる。
大事なのは、直近の時間軸での利益のためなのか？
それとも長期的に見ての利益のための先行投資なのか？
という観点でも考えること。
ここは、BIダッシュボードなどを使って、
横軸が時間、縦軸利益率の実績グラフを描くなどして以下の変曲点に着目すれば、
自ずと「もうここにリファクタリングコストをかけるべきではないな」とある程度読める。
発展性
これは内部環境でいえば、ソフトウェアの進化に伴う自分たち自身の発展。
それだけでなく、競合組織、スタートアップなどの発展という外部環境。
自然発生的な市場の流れの変化も外部環境変化に含まれる。
それらの動的な変化に従い、競争優位確保＆維持のための事業に適応できなくてはならない。
それを満たす代表的な品質特性が、
変更容易性やアプリケーション間連携が全体としてうまくいくかという相互運用性。
自分たちの定義しているルールの変更容易性や、
古き良き文化という意味でのルールの再利用などにもかかわる。
ルールの相互運用性という意味でいえば、
異なる組織を連携または組み合わせた際、各組織のルール同士が衝突しないか
などという意味も含まれている。
事業活動の当事者として何をすべきか
行動モデルを変える
下図に示すように状況の観察が最初。
そこで得た情報をもとに仮説を作って行動をする。
行動することで、状況も変わるし、経験値も得られる。
これはどちらかというと、PDCAというよりも仮説行動×OODAループであると感じる。
事業戦略や、全体のアーキテクチャという事業戦術レベルは、PDCAの方がいいが、
事業戦術を構成する、事業活動レベルの詳細なものは、OODAの方がVUCA環境では適しているからである。
常に変化する状況の中で、自分たちの過去の知見をうまく使い、
そして時には捨てて学習を繰り返しながら順応していく。
これってまさにDX系の案件の特性であると感じている。
自社の差別化戦略の分析に基づいて設計判断する
whyに着眼したビジネスモデリング
増田さんが出されたこのモデル図、若干の違いはあれども
匠メソッドで出てくる要求分析ツリーそのものであると感じました。
これは事業のマーケティング戦略とモデリングとのつながりを意識させられるものだ。
活動方針
匠にないものとして、活動方針というものがある。
戦略を実現するためには、時間や物的資源、人、お金などの制約の中で行動しないといけないので、排他的に何をやらないか、何を選ぶか選択。
ここが自社独自の排他的選択になるという。
この排他的選択の領域に結び付くような脆弱さの部分は、
あえて受け入れるという選択をしたことになるので、その部分の脅威分析はしないということにつながる。
そしてこの方針にさえのっとってさえいれば、あらゆる活動は方針を満たしている。
SOLIDでいえば、リスコフの置換原則を満たすといえる状態である。
逆にこの方針が定義されていない状態では、
あらゆる活動がバラバラな方向を向き、活動同士の衝突を生み、
それがステークホルダー同士の要求の対立関係などを生む原因にもなる。
活動規則
業務ルールは、こういう状況で、こんなイベントが起きたら、
これ以上事業がズレないようにと、活動に対して制約をあたえる。
これはアクティビティ図などにおいて、ビジネスロジックが働く条件分岐として現れる。
この辺のルールの創造は、**チェンジザルール**という本で思想が描かれている。
こういった業務ルールが、戦略を満たす形でソフトウェアに組み込まれることで、
初めてシステムは事業戦略を満たす実現リソースとなる。
この辺のルールの扱いを気にせずに、機能面だけをシステムで実現しようとすると、DXなんてものは全く意味をなさない。
差別化分析の技法
最近よく触れるようにしているバリューチェーンモデルが出てきた。
これは自社内の価値の構造を生む部分とそれを支援する領域に分けて考えるもの。
バリューストリームマップは、これに対して動的なモデル図である。
いってしまえば、クラス図とシーケンス図の関係性。
差別化戦略のための5箇条
これはモデルと、マーケティングで考えたSWOT分析モデルとの整合させたトレーサビリティマップが必要に感じる。
そういう意味でもマーケティング部門もドメインモデリングに一緒に取り組んでほしいと強く感じる。
丁度以下の図で、差別化戦略というワードを使っていたので添付しておく。
差別化戦略とソフトウェア設計方針
図の中核部分だけに投資を集中させ(パレート法則)、
他の一般や補完領域は、既存のライブラリやサービスなどに頼ってしまう。
