#1 判断ドリブンアーキテクチャ - 業務を分解すると、最後に残るのは「判断」だった -
はじめに
私はエンジニアです。
いまもコードを書いています。
一方で、中小企業の現場に入り、
業務の整理や構造化を支援する立場にもあります。
技術と業務、両方を見てきました。
自社の業務にAIを入れて、何か効率化できないか。
そこから今回の取り組みは始まりました。
しかし、いきなりAIを入れるのではなく、
まず業務の構造を整理することにしました。
業務プロセス設計を進める中で、
「業務を分解すると最後に残るのは判断ではないか？」
という考えにたどり着きました。
そのとき思いついたのが「判断ドリブン」という考え方です。
この考えは note に書いてきました。
noteでは、このアーキテクチャの思想を、
実際に手を動かしながら整理してきました。
一方で、実装についてはここ（Zenn）に書いていこうと思います。
Zennでは、
何をやろうとしているのかの概要を「導入編」として示し、
その後、実装を進めながら構造を具体化していきます。
正直に言うと、
最終的にどうなるかはまだ完全には見えていません。
うまくいくかどうかは、
神とAIのみぞ知る、という感じです。
ただひとつ言えるのは、
これは机上の理論ではなく、
自分の業務を使った実験である、ということです。
始まりは「AIを入れたい」だった
最初の動機はとても単純です。
自社の業務にAIを入れて、
何か効率化できないかと思った。
でも、いきなりAIツールを入れるのは違う気がしました。
いきなりAIを入れるのではなく、まず業務の構造を整理しよう。
そう考えました。
まずやったこと：ビジネスモデルキャンバス
私はビジネスモデルキャンバスというフレームが好きなので、
まずそこから始めました。
- 誰に価値を提供しているのか
- どこで売上が立つのか
- 日常的にどんな業務が発生しているのか
ここでやったのは改善でも戦略でもありません。
今回扱う世界（ドメイン）を固定すること。
さらにヒアリングや業務フローを見ながら、
実際の業務を確認しました。
業務ジャーニーという単位
整理していく中で気づいたのは、
業務は「細かい作業」ではなく、
意味のまとまり
として存在している、ということでした。
そこでこの単位を
業務ジャーニー（Business Journey）
と呼ぶことにしました。
カスタマージャーニーマップの考え方を応用し、顧客ではなく業務側の流れとして再定義したものです。
業務ジャーニーとは、
1つの成立状態を持つが、
他の成立状態に従属しない単位
もう少しわかりやすく言うと、
それ単体で「何かが確定した」と言える終点を持つ業務のまとまりである。
単なる作業の一部ではなく、それ自体が意味を持つ単位である。
です。
たとえば、
- 新規顧客獲得ジャーニー
- 提案・合意形成ジャーニー
- 制作進行ジャーニー
- 入金確認・消込ジャーニー
などです。
ここではまだ「判断」という言葉は出てきません。
入金消込ジャーニーを選んだ理由
複数の業務ジャーニーを並べてみたとき、
特に目についたのが「入金消込」でした。
字の通り、銀行からの入金と売上管理台帳を比べて消し込む作業です。
一見すると単純な照合作業です。
キャッシュは回っている。
入金もされている。
しかし、
売上が確定しない。
金額が微妙に違う。
名義が一致しない。
どの案件か特定できない。
督促をどこまで強めるか迷う。
止まっているのは作業ではありません。
そこにあるのは、判断でした。
作業ではなく、判断だった
入金消込業務を観察すると、
作業自体は単純です。
- 銀行口座を確認する
- 金額を照合する
- 台帳に記入する
しかし業務が止まるのは、
業務を次に進めてよいかを確定させる瞬間
でした。
そこで私はこう定義しました。
判断とは
状態を確定させる行為。
確定とは
責任主体が状態を固定すること。
業務はフローで進んでいるのではなく、
判断の連鎖で進んでいる
のではないか。
そう考え始めました。
フェーズ構造が見えてきた
ここまで整理すると、
業務分解には段階があることが見えてきました。
- フェーズ0：ドメインを固定する（BMC＋ヒアリング）
- フェーズ1：業務ジャーニーを抽出する
- フェーズ2：扱う判断を選ぶ
- フェーズ3：判断の責任構造を明確にする
私は現在、フェーズ3まで進めています。
まだAIは導入していません。
でも、構造は見えました。
何が見えたかというと、
「誰がどこで止まり、誰の責任で確定しているか」です。
そして、ここまで来て気づきました。
業務が止まるのは、作業が難しいからじゃない。
判断が揺れるからだと。
そして揺れる判断は、たいてい属人的です。
揺れる判断は、だいたい同じ場所で、同じように起きます。
なので次に考え始めたのが、ログでした。
なぜログを考え始めたのか
判断を取り出してみて、次に思ったのはこれでした。
これ、毎回同じようなことで迷っていないか？
入金の名義が少し違う。
金額が数百円ずれている。
督促を強めるかどうかで悩む。
そのたびに、誰かが判断しています。
しかし、
- なぜその判断をしたのか
- それは正しかったのか
- 次も同じ判断でよいのか
は、どこにも残っていません。
その場で決めて、終わりです。
これでは、
- 人も成長しにくい
- 引き継ぎも難しい
- AIに学習させる材料もない
と感じました。
いきなりAIに判断させるのは無理です。
でも、人の判断を記録することならできる。
そこで考えたのが 判断ログ です。
- どんな状況だったか
- 誰がどう確定させたか
- 後から見て妥当だったか
これを残す。
すると次に似たケースが出たときに、
「前はどうしていたか」が見えるようになります。
それだけでも、判断は少し安定します。
さらにデータが溜まれば、
- AIが材料を整理できる
- 過去の類似事例を提示できる
- 将来的には推奨もできる
かもしれない。
だからまずは、
AIを入れる前に、判断を残す。
ここから始めようと思いました。
ここからが本番
ここまでが導入です。
次回は、
業務ジャーニーの中から
実際に「判断」を取り出します。
作業ではなく、
状態を確定させる判断
として言語化していきます。
そこから、この設計思想は一段深くなっていくと思います。
Discussion