社内の業務のやり方を、AIで作り替えていく。旧システムのやり直しも含めて、 その改善が単発で終わらず次々に起きている状態を作りたい、というのが 9月2日の戦戦会議で出た話です。
改善が続いている会社では、起票 → 実行 → お披露目 → 期待が輪になって回っています。 1件直るたびに「出せば形になる」という実感が社内に増え、その実感が次の起票を呼ぶ。だから波になる。
起票が出るには2つ要ります。課題が見えることと、出せば形になると思えていること。 それぞれについて、今の状態・打ち手・目指す状態を並べました。
| 現場に要るもの | As-is（今の状態） | ソリューションの方向性 | To-be（目指す状態） |
|---|---|---|---|
| NEED 1課題が見える、という力 | 目の前の手間を「そういうものだ」として受け入れている。困りごとはあるが、課題の形にならないので、口に出す対象にならない。 | RS大学校などの学習で、現状とあるべき姿を見比べる型を入れる。自分の仕事を外から見る言葉を持つ。 | 目の前の作業を、現状とあるべき姿の差として書ける。何がどう変わればよいかまで言える。 |
| NEED 2すぐ形になる、という期待 | 言っても順番待ちか、そのままになる、という前提でいる。だから気づいても出さない。仮説・要確認 | 社内向けの広報で、直った事例を出す。何が上がって、何日で、どう変わったかを具体で流す。 | OOKABE GLASS では出せばすぐ形になる、と思えている。だから思いついた時点で出す。 |
起票が上がった瞬間に、5体のエージェントが順に動きます。 受け付ける・現状を調べる・あるべき姿を描く・作る・見せる。 人が輪の中に入るのは、起票するときと、受け取るときだけです。
起票が依頼として人に渡る。受けた側の優先順位の列に並び、後ろのほうは順番が来ないまま残る。 さらに、どの部隊がやるのかがその都度の判断になるため、担当のお見合いが起きる。仮説・要確認
起票が発火装置になる。Backlog に上がった瞬間に、受付エージェントが要対応の案件として立ち上げる。 人が「やるかどうか」を決める工程を、起票と実行の間に置かない。
ここが止まると：起票は残るが動かない。現場から見ると「出しても何も起きない」＝ SECTION 02 の期待が 0 になる。
起票に書かれた本人の言い分が、そのまま現状の説明として使われる。 実際の手順・使っている画面・扱っている件数までは取りに行かないので、 直したあとで「そこは元々そうしていない」が出る。
調査エージェントが現物から現状を組み直す。画面、帳票、データ、実際の操作を読んで、 今どう回っているかを事実として起こす。ここがずれていると、あとの工程は全部ずれたまま進む。
ここが止まると：直ったのに使われないものが出来る。現場は「分かっていない」と受け取り、次を出さなくなる。
あるべき姿を、起票者が言えた範囲でしか作らない。 現場は今のやり方の延長でしか書けないので、 作業を速くするところで止まり、やり方そのものは変わらない。
設計エージェントが起票者のリクエスト ＋ AI の自律的な定義の2本立てで描く。 起票者が書いたあるべき姿を出発点にしつつ、 現状を読んだうえで「そもそもこの手順は要らない」まで含めて別案を足す。
ここが止まると：改善が時短どまりになる。旧システムの前提を引き継いだまま、速いだけの同じ仕事が残る。
作って、出して、終わり。うまく動かなければ、また人が指摘して直す。 直すたびに人の手が要るので、案件数が増えるとそこで詰まる。
開発エージェントが実行 → 検証 → 改善を輪にして回す。 肝は、検証を作った本人ではない別の主体に任せること。 ここは 8月19日の資料「ループを設計し、人はどこに立つか」で扱った内容がそのまま入る。
ここが止まると：品質が人の手数に縛られる。件数を増やせないので、波の大きさに上限ができる。
出来たことが、関わった人の中で終わる。 起票した本人にも、いつ何がどう変わったのかが届かない。
お披露目エージェントが、起票した本人に出来ましたと見せる。 ここで出た「出したら本当に形になった」が、社内向け広報の原料になり、 SECTION 02 の期待を作る。
ここが止まると：輪がつながらない。1件ずつの改善は残るが、波にはならない。