概論

実践編. 状態設計を実務で使う

では、実際のプロジェクトでは状態設計をどう使うのか。

状態設計というと、業務フローをきれいに書いたり、As-Is / To-Beを整理したりするための設計手法にも見える。

ただ、実務で一番効くのはそこではない。

「このプロジェクトを次にどう進めればいいかわからない」ときに、何を確認すれば前に進むのかが見えること。

特にAIプロジェクトでは、この使い方が重要になる。

仕事を捉える

業務名を疑う

「ああ、あの仕事ね」と理解したところから間違いやすい

• プロジェクトの入口では、「営業」「審査」「問い合わせ対応」「図面作成」のような業務名が与えられることが多い。
• ただし、同じ「営業」でも実際に行っていることは会社によってかなり違う。
  • 商品を説明する
  • 顧客の課題を整理する
  • 提案書を作る
  • 契約条件を調整する
  • 契約処理まで行う
• 人間は、かなり違う仕事を同じ名前でラッピングして扱える。
• 一方で機械に処理させるなら、それらは別の仕事として扱わなければならない。

だから、

「営業をAI化する」と言われて「ああ、営業ね」と思う人ほど危ない。

まずは一度、

この会社が営業と呼んでいるものは、実際には何なのか

を見る必要がある。

仕事や作業、処理の終了条件を決める

「何をする仕事か」ではなく「何が揃えば仕事が終わるか」を見る

• 現場に仕事内容を聞くと、「説明する」「確認する」「入力する」「提案する」といった行動が出てきやすい。
• しかし、行動は仕事を成立させるための手段でしかない。
• 状態設計では、「その仕事が終わったときに何がどうなっていればいいのか」を見る。

例えば営業であれば、

• 顧客情報が確認できている
• 顧客の申込意思が確認できている
• 購入するプランが決まっている
• 契約に必要な情報が揃っている
• 後続の契約処理を開始できる

という状態かもしれない。

重要なのは「商品説明をした」ことではなく、必要な情報と意思が揃い、次の仕事へ進める状態になったことである。

仕事のつながりを整理する

仕事は「次へ進める状態」の連鎖として見る

一つの業務の中にも、複数の状態が存在する。

例えば、

• 顧客が特定できている
• ニーズが確認できている
• 提案内容を決められる
• 条件合意できている
• 契約処理を開始できる

というように、ある状態が成立すると次の処理が可能になる。

段ボールに商品を詰めなければ配送できないのと同じで、仕事には「ここまで揃っていないと次へ進めない」という条件がある。

この連鎖を整理すると、仕事の構造が見えてくる。

• 誰が何をクリックしているか
• どのExcelを開いているか
• どのシステムへ入力しているか

だけを整理すると、人やツールが変わったときに構造も変わってしまう。

一方で、何が揃えば次へ進めるのかという状態は比較的残る。

未知を見つける

状態から確認事項を出す

状態を置くと「何がまだわかっていないのか」が見える

状態設計は、最初から正しい答えを書く作業ではない。

例えば、**「契約処理を開始できる状態」**と仮に置いてみる。

すると、

• 顧客情報はどこまで必要なのか
• 本人確認は完了している必要があるのか
• 見積承認は必要なのか
• 支払条件は確定している必要があるのか
• 例外契約の場合はどうするのか

という問いが出てくる。

この問いが出ること自体に価値がある。

状態を置くことで、その仕事について、自分たちが何を知らないのかが見えるからである。

状態設計は、既知の業務を整理するだけではなく、探索すべき未知を発見するための道具でもある。

現場から判断条件を掘る

「ルールを教えてください」だけでは、仕事はなかなか出てこない

現場の人は、自分がどう判断しているかを必ずしも言語化していない。

• たくさん見てきたからわかる
• なんとなくこれは危ない
• このケースなら確認する
• この場合だけは通さない

という状態になっていることが多い。

そのため、

「判断基準を教えてください」

と聞いても、十分な答えが返ってこないことがある。

それよりも、

• このケースならどうしますか
• これは確認しなくてもいいですか
• この項目、本当に必要ですか
• これを無視すると何が起こりますか
• これは通しても大丈夫ですか

と具体的に聞く。

すると、

• 「それは絶対ダメです」
• 「昔これで事故がありました」
• 「このケースだけは上長確認です」

といった情報が出てくる。

そこで初めて、

その仕事が今の品質を保つために守っていた条件

が見えてくる。

判断を機械が扱えるところまで分ける

「何を見れば、何が判断できるか」まで落とす

例えば小説の審査を、

「作品を読んで合否を決める」

と理解しているだけでは、機械化するには粗すぎる。

実際の審査員を見ると、冒頭だけを読んで20秒程度で落としている作品があるかもしれない。

そこで「なぜ今ので落とせたんですか」と聞くと、

• 日本語の構造として大きな違和感がある
• 読者がシーンを想像できない
• 想像させた内容に沿って文章が展開していない

といった条件が出てくる。

つまり、

• Fact：何が確認できたか
• Can：そのFactから何が判断できるか

まで分ける。

例えば、

• Fact：冒頭300文字に大きな文法的破綻がない
• Fact：人物・場所・行動が読み取れる
• Can：読者が場面を想像できる
• Can：最低限の文章成立性がある
• State：詳細審査へ進める

という構造になる。

人間はこのあたりを圧縮して「読めばわかる」で処理している。

AI化するときには、それを機械が扱える粒度まで展開していく。

次の一手を決める

進行リスクを特定する

「進め方がわからない」は「何が危ないかわからない」であることが多い

プロジェクトの途中で、

「次に何をすればいいんだろう」

となることがある。

このとき、標準的なプロジェクト工程を探しても、あまり答えにならない。

むしろ考えるべきなのは、このまま先へ進んだ場合に、何を間違える可能性があるのかである。

例えば、

• そもそも仕事を誤解しているかもしれない
• 必要なデータが存在しないかもしれない
• 人間の判断基準を取り違えているかもしれない
• 現場と管理者で求める品質が違うかもしれない
• 致命的な例外条件を見落としているかもしれない
• AIができないことを前提に計画しているかもしれない
• 評価方法自体が間違っているかもしれない

といったリスクがある。

それが見えれば、次にやることも見える。

• 仕事を誤解していそう → 現場を見る
• データが怪しい → 実データを確認する
• 判断基準が怪しい → ケースを並べて判断してもらう
• AI能力が怪しい → 小さく作って試す
• 評価方法が怪しい → 人間の判断と比較する

進め方を考えているようで、実際にはリスクへの対応方法を決めている。

実装リスクを状態にひもづける

それっぽい処理が動いても「その状態になれない理由」を見ると、リスクが具体化する

例えば、

「後続担当者が追加確認なしで契約処理を開始できる状態」

を目指しているとする。

その状態になれない理由として、

• 必須情報が欠けている
• 入力された情報が間違っている
• 顧客の意思が曖昧
• プランと契約条件が矛盾している
• 例外条件が未確認

などが考えられる。

これらが、その仕事における具体的なリスクになる。

つまり、

• 目指す状態を置く
• その状態の成立条件を出す
• 成立を阻害するものを探す
• 阻害要因を潰す方法を決める

という順番で考える。

漠然と「リスクを洗い出しましょう」とやるより、かなり具体的になる。

評価を設計する

絶対に守る条件を決める

平均点が高くても、一発アウトなら使えない

仕事には、これを破ったら仕事として成立しないという条件がある。

例えば問い合わせ対応なら、

• 他人の個人情報を回答しない
• 誤った契約内容を案内しない
• 法令違反になる回答をしない

などが考えられる。

こうした条件は、単純な平均精度とは分けて扱う必要がある。

AIが全体として95点でも、致命的な5点が存在するなら使えない仕事もある。

逆に、多少文章がぎこちなくても、絶対条件を守りながら大幅に速度を上げられるなら、導入価値がある仕事もある。

良いほど価値が出る条件を決める

「NG」と「より良い」を同じ評価軸にしない

絶対条件とは別に、

• 回答が速い
• わかりやすい
• 丁寧
• 一度で解決する
• 顧客満足度が高い

など、高いほど価値が出る条件も存在する。

そのため評価では、

• 絶対に守る条件
• 高いほど望ましい条件
• 実用上必要な合格ライン

を分けて考える。

これはAIを採点するためだけではない。

この仕事における「良い仕事とは何か」を定義することそのものでもある。

今の仕事と比較する

AIだけを絶対評価せず、状態推移ごと・仕事全体で人と生産性を比べる

AIプロジェクトで判断したいのは、「AIが完璧か」ではない。

現在の仕事から、AIを含む新しい仕事へ切り替えた方が良いか

である。

比較対象は、

• 現在の人間運用
• 現在の外注
• 既存システム
• 現在のコスト
• 現在の処理時間
• 現在発生している失敗

になる。

人間も普通に間違える。

そのため、「AIが1件間違えたので使えない」とは限らない。

一方で、平均値では人間を上回っていても、現在の仕事では絶対に起こさない重大事故をAIだけが起こすなら使えない。

だから、現在の仕事がどの状態を、どの品質で成立させているのかを理解することが評価の前提になる。

作りながら解像度を上げる

AIが解く問題を細かくする

状態が見えると、必要な能力を切り分けられる

例えば最初は、

「問い合わせに正しく回答する」

という一つの能力に見えている。

実際に作って評価すると、

• 問い合わせ意図を特定する
• 顧客状態を確認する
• 必要なナレッジを取得する
• 適用条件を判断する
• 回答を生成する

という複数の能力に分かれるかもしれない。

さらに評価すると、「ナレッジ取得はできているが、適用条件を間違えている」ことがわかる。

すると次に解くべき問題は、「問い合わせ回答能力を上げる」

ではなく、**「この条件判定の能力を上げる」**になる。

評価から失敗原因を探る

作る→評価する→原因を探す、を繰り返す

AIプロジェクトでは、

• 作る
• 評価する
• どこで状態が成立しなかったかを見る
• 原因を分解する
• 問題設定を細かくする
• また作る

という行き来が発生する。

つまり状態設計も、一度書いたら終わりではない。

作ってみることで、

「実はこの状態が一つではなかった」

「この判断には別の情報が必要だった」

「ここに例外条件があった」

とわかる。

そのたびに、仕事の理解も状態設計も更新される。

プロジェクトが進むほど、状態の解像度が上がっていく。

終わりに

状態設計は、最初に正しい業務図を完成させるためのものではない。

仕事を状態として捉えることで、何がわかっていて、何がまだわかっていないのかを明らかにするためのものである。

未知が見えればリスクが見え、リスクが見えれば次にやることが決まる。

そして、作って評価するたびに状態の解像度を上げていく。

AIプロジェクトでは、この繰り返しそのものが、仕事を機械化できるところまで理解していくプロセスになる。