❄️

厄介な問題に「システム思考」で挑む

2024/04/08に公開

伝えたいこと

論理的思考だけでは立ち行かない厄介な問題への武器として、システム思考という選択肢も持っておくと分析の幅が広がるかも

要約

  • レガシーシステム、どうする?というありふれた厄介な問題
  • どうすべきかの仮説はあるけど分析が甘そう
  • システム思考で解像度UP、新たな仮説を立てられた

社内のレガシーなシステムを今後どうしていくか?

システムの詳細は省きますが、10年くらい前からシステムを持っている多くの企業が、この問題を抱えていると思います。
この問題をどうにかするためにマイクロサービスが流行し、成功したり失敗したり、、今も闘っている企業は多いでしょう。
弊社はマイクロサービス化に失敗した側で、今も闘い続けているのです。

どうアプローチすれば良いかわからない

レガシーシステムは総じて歴史が深く、事業を支えてきた重要なシステムです。
故に規模は大きくなり、関係者も多くなり、変更容易性は下がっていきます。
なんとかしたいけど、何をすれば良くなるのかわからない。
出来ることは色々ありそうですが、何をするのも簡単ではありません。

さあどうする?

仮説はあった

何が今のレガシーシステムの状況を作り出しているのでしょうか。
その原因を断つことが出来れば、現状を打破出来るのでは。

一応、仮説はありました。
変更容易性低下の原因は、3つの複雑さが起因しているのではないかと。

その3つの複雑さを以下のように定義しています。

  • 本質的な複雑さ
    • 対象とするドメイン知識の難しさ
  • 偶有的な複雑さ
    • 技術的要因による複雑さ(コードが読みづらいなど)
    • 仕様とコードの乖離
  • 規模による複雑さ
    • 対象とするドメインの広さ、連携するシステムの数など

これらは弊社メンバー@sotaro8181発表資料モノタロウさんのテックブログから着想を得ています。どちらも素晴らしい内容です。

システム思考で考える

この仮説の確からしさを検証する為にシステム思考を使いました。
システム思考を知ったのは、「エンジニアリング組織論への招待」と「ダイアローグ」を読んだことがきっかけでした。

ググると解説記事は色々出るので詳細はそちらに任せるとして、システム思考とはざっくり「ある物事を構成する要素間の関係性に注目する考え方」です。
システムのわかりやすい例が「生態系」で、害虫だからといって駆除して減らすと生態系全体に影響を与えてしまいます。このようなものを分析するための手法としてシステム思考が誕生したわけです。

実践

システム思考は、まず問題の全体像を把握する必要があります。
その手法として、書籍ダイアローグでは氷山モデルを使った例がありそれを参考にしました。
よく「この問題は氷山の一角に過ぎない」と表現したりしますが氷山モデルはまさにそれで、
目に見えるものとそうでないものを分けて、隠れた問題を炙り出します。

なんだか難しそうな感じですが、雑めにやってみます。
今回の仮説は「変更容易性低下の原因は3つの複雑さが起因しているのではないか」なので、
変更容易性低下によって起きている目に見える事象をいくつか挙げます。

  • 機能追加やリリースに時間がかかる
  • 何か開発をしようとした時にボトルネックになる
  • 他チームからリソースを借りようにも参入障壁が高い

次に、変更容易性に影響を及ぼす変数の時間による推移[1]を考えます。

  • レガシーシステムのコード量、カラム量
    • 増加
  • コミュニケーションを取る人の量
    • 増加
  • 担当チームの人数
    • 減少(今のままだと)
  • 担当チームの技術力
    • 横ばい

これらを元に、Aが増えるor減るとBが増えるor減るの関係[2]を思いつくままに図に起こしていきました。

結果

こんな感じになりました。

見辛くてすみません。
青い矢印が増加の関係、赤い矢印が減少の関係になっています。
この図の注目ポイントは次の箇所です。

負のループが「偶有的な複雑さ」を中心に形成されています。
つまり、「偶有的な複雑さ」を取り除いてループを破壊すると突破口が開けるかも。

課題の解像度が上がった

システム思考によって、偶有的な複雑さに初手で対処するのが良いとさらなる仮説を立てることが出来ました。
しかし、このシステム思考は自分一人で作ったものなので観点が足りていない可能性が高いです。
周囲の人にも見てもらいながら補完していく必要があります。

まとめ

レガシーシステムをどうするか考える時は、現場に深く入り込んで何が起きているか観察したり、関係者から話を聞いたりすることも肝要だと思います。

また、分析や仮説は机上の空論でしかありません。
ある程度考えたら、小さく試してフィードバックを得て、計画に反映するのが良いのではないかと考えます。

なお、本来のシステム思考はより多くの思考プロセスを踏みます。
今回は初挑戦ということで簡略化して挑みましたが、今後は経験を重ねて本来のシステム思考を使いこなせるようになりたいです。

脚注
  1. 「時系列変化パターン」と呼ばれます ↩︎

  2. 「ループ図」と呼ばれます ↩︎

レバテック開発部

Discussion