ビジネスにおけるエンジニアの強みはアプリ作成だけではない

エンジニアの強み

• 抽象化による現状の分析モデルの作成
• 現状分析からパターン化
• 現状分析からの最適化

また、パターン化からの自動化(アプリ作成)へとつながる。これらの強みは抽象化スキルからでてくる。

[思考実験]うまく行っていない会社にエンジニア君とコンサル君の2人が原因分析をすると...

うまく行っていない会社の前提として、物作ったりサービス提供したりする業務系のビジネスとする。基本的に3つの登場人物に分かれる。

• 経営者
• マネジメント層のリーダー
• 現場のメンバー

そして、それぞれの視点からは見えているものが違う。基本的にトップに近づけば近づくほど、より広い視点になるが、現場を理解していないこともあり、なぜ収益がよくならないのか深く分析できない。

登場人物	視座の高さ
経営者	会社を上から見る。経営指標が一番良く見える。逆に現場が見えない経営者もいる。
リーダー	チームを上から見る。チームが一番良く見える。経営サイドも現場サイドもほどよく見える距離感
メンバー	自分の目の前まで。自分の作業が一番良く見える。経営サイドはほとんど見えない。

このような場合は、それぞれの登場人物から見えているものを分析して、なぜうまくいっていないのか探る必要がある。そこでうまくいっていない原因をヒアリングしてみんなから集めて、それをもとに分析することにした。

コンサル君はMECE(ミーシー)を使い、エンジニア君は概念モデリングを使う

コンサル君はMECE(漏れなくダブりなく)を念頭に、ヒアリング結果をKJ法で分類していってみた。
エンジニア君は概念モデリングを使って、ドメインエキスパート(経営者・リーダー・メンバー）にヒアリングを続けながら概念同士をつなげていった。サブタイプ矢印などをうまく使って、抽象度のレベルを揃えていった。

コンサル君はシステムシンキングを使い、エンジニア君は概念モデリングを使う

コンサル君はシステムシンキングを使って、各概念の因果関係をつなげていった。
エンジニア君は概念モデリングの依存矢印を使って、各概念の最低限の因果関係をつなげていった。

概念モデリングの強さ

コンサル君の使っているツールはパターン化されたものが多い。対して、エンジニアのもつ概念モデリングはかなり応用性の範囲が広い。MECEを初めて知ったときに、概念モデリングのほうが先を行っているなと思った。概念が2つの分類軸を持つときに(例えば働くクルマであれば、働く軸とクルマ軸の２つ)、概念モデリングはうまくこの表現をサブタイプで表すことができる。またサブタイプがネストを深くしすぎると分類がおかしくなることも感覚として知っている。

単にシステムシンキングだけ使ってもうまくいかない。なぜならシステムシンキングはデータフロー図のように概念の網羅性に弱く、1つ1つのユースケースにしか対応しない(だから、コンサル君はKJ法で概念の抽出を図った)。そこで最近の設計ではデータフロー図よりも概念モデリングやクラス図によるリレーションで概念を表現している。こうすると概念の網羅性が上がり、概念を辞書のように参照できるようになる。この概念モデリングをもとにデータフロー図(今回でいうシステムシンキング)を作るとより、網羅性の高いものになる。しかし、概念モデリングにはすでに依存矢印があるため、それを因果関係の矢印として使えば、システムシンキングを使う必要はなくなる。

エンジニアのもつ抽象化とモデリングのスキルがビジネスの原因分析にかなり役立つことを最近実感してる。