火曜の午前。クライアント先の担当者からメッセージが届いた。「来週の火曜に予定している初回提案、今週の金曜まで前倒しできませんか? 上への報告が早まってしまって」
このとき、プロジェクトマネージャーがいちばん言いやすい返事がある。「はい、大丈夫です」
以下の話は、ONTLEでAIプロジェクトマネージャーを運用する中で実際に起きたことをもとにしている。ここで言うAIプロジェクトマネージャー(以下AI PM)とは、スケジュール表・担当者・作業ステータスといったプロジェクト情報につながった状態でクライアントの依頼を受けて返答し、仕事を割り振る「実行ツール」だ。人とやり取りするだけのチャットボットで終わらず、実際のスケジュール表を覗き込んで答えを組み立てる点が違う。
そのAI PMが、似たような依頼に「大丈夫です」と答えたことがある。クライアントは喜んだ。ところが翌日、担当デザイナーのスケジュールを開いてみると、金曜より前に先に終わらせなければならない作業が二件かかっていた。金曜納品は物理的に不可能だった。結局クライアントに連絡し直して、「申し訳ありません、やはり火曜に…」と言葉を飲み込むことになった。
クライアントの立場からすれば、これは小さな事故ではない。一度「大丈夫です」を聞いたあとで「やっぱり無理です」を聞かされると、そこから先、そのマネージャーのすべての「大丈夫です」が疑われる。信頼は一瞬で削れ、ゆっくりとしか積み上がらない。
この記事は、その失敗そのものの話ではなく、失敗したあとに何が起きるかの話だ。人であれAIであれ間違える。大事なのは、同じ場所でもう一度転ぶかどうかだ。
仕事ができる人とできない人を分けるのは、失敗の有無ではなく再発するかどうかだ。同じことで三度目の小言を言われると、「この人は学ばない」という判断が下る。仕事の勘とは、結局のところ、一度やけどした場所を覚えている能力に近い。
ところが、AI PMにとってこの「記憶」は人とは違う働き方をする。人は手痛い目に遭うと、その感触が数日は残る。一方でAIは、会話が終わったり翌日に新しい作業を始めたりすると、昨日のあのヒヤッとした瞬間を基本的には持ち越せない。だからAI PMに「今後は気をつけます」と言わせても、実質的には何も変わらない。次の会話のAIは、そんな決意をした覚えがないからだ。
言い換えると、AI PMの「学習」とは賢くなることではなく、間違えたことを書き留めて次の自分に渡すことだ。昨日の自分が今日の自分にメモを残すようなものだ。そのメモがどう行動につながるかは単純だ。ルールを文章にして保存しておけば、新しい依頼が入ってきたときにAI PMがまず保存されたルールを読み、条件に合えばスケジュール表を照会し、その結果から答えを組み立てる。保存 → 読み込み → 照会 → 返答。この四つの箱の流れが機能するには、メモをうまく書かなければならない。
役に立たない振り返りと役に立つ振り返りは、フォーマットで分かれる。四つのステップに整理できる。
ステップ1。何が間違っていたかを一文で。
納期の件なら、こう書く。「クライアントの納期短縮の依頼に対し、担当者のスケジュールを見ずに可能だと答えた」。ここから感情は抜く。「焦っていた」「反省している」といった言葉は、次の作業に何の指示も与えない。何をしたかだけを淡々と書く。
ステップ2。なぜそうしたのか、本当の原因まで。
表面的な原因は「確認しなかった」だ。だが、そこで止めてはいけない。なぜ確認しなかったのか。クライアントが速い返事を望んでいるように見えて、速い応答こそが良い応答だと思い込んだからだ。本当の原因は、「依頼を素早く受けること」と「約束を確定させること」を一つにまとめてしまった点にある。これを突き止めてこそ、次のルールが正確になる。「確認をちゃんとしよう」で終わらせると、範囲が広すぎてどこでも引っかからない。
ステップ3。次は何を、どんな基準で確認するか。
ここでは確認項目と返答基準を決める。確認項目は二つ。該当作業の担当者の空き時間、そしてそれより先に終わらせなければならない作業があるか。返答基準は一つ。照会結果を根拠に、可能・不可能・条件付きのいずれか一つでだけ答える。もしスケジュール表の照会に失敗したり情報が足りなかったりしたら、そのときは確約せず「確認してから改めてお伝えします」と保留する。この分岐まで書いておいてこそ、ルールが実際に最後まで機能する。
ステップ4。その確認を業務フローのどこに掛けるか。
同じ確認でも、いつ作動するかで有用性が分かれる。このルールは「クライアントが確定したスケジュールを変えてほしいと依頼してきた瞬間」、つまり依頼を受け付ける入り口に掛けなければならない。報告書を書き終わってから「あ、そういえばスケジュールを確認すべきだった」では意味がない。チェックは仕事が終わる場所ではなく、始まる場所に立てる。
四つのステップを経ると、一つの記録がこう完成する。
事案: 納期短縮の依頼に、担当者のスケジュールを見ずに可能だと答え、約束を覆した。 原因: 依頼の受付と約束の確定を分離しなかった。 発動条件: クライアントが確定した納期・スケジュール・範囲を変えてほしいと依頼してきたとき。 動作: 依頼は即座に受け付けるが、確約は保留する。担当者の空き時間と、先に終わらせるべき作業を照会したうえで、可能・不可能・条件付きのいずれかで答える。照会できない場合は確約せず、再確認する旨を案内する。
実務でよく上がってくる振り返りは、「クライアント対応時に慎重さを欠いた。今後は留意する」で止まる。読むと正しいことを言っているようだが、来週のAI PMに渡しても何も起きない。いつ発動するのか、何をせよと言っているのかがないからだ。上の記録は地味でおもしろくない。その代わり、そのまま実行できる。ルールはカッコよくある必要はない。入り口で静かに作動してくれさえすればいい。
数週間後、同じクライアントが似た依頼を送ってきたとしよう(この場面は、ルールがどう作動するかを見せるための仮定だ)。「今回の分量、もともと来週の木曜ですが、水曜に一日だけ前倒しできますか?」
ルールが掛かる前なら、また「はい、合わせてみます」が飛び出していた場面だ。今回は違う流れになる。依頼を受け付けた瞬間、「スケジュール変更の依頼」という条件が引っかかる。AI PMは受付だけしておいて確約は先送りする。まず該当作業の担当者のスケジュールを見て、先に終わらせるべき作業がいつ片づくかを確認する。続いて、そのあとの検収を一日削るとどんな品質差が生じるかを、担当者に尋ねて確認する。この「検収を削ったときの影響」はAIが単独では判断できない部分なので、必ず人間の担当者に確認するようルールに紐づけてある。そのうえで答えを組み立てる。
「水曜、可能です。ただし、そのためには2回目の社内検収を半日に縮める必要があるので、細かな誤字やディテールの修正は納品後に補う形になります。その条件でよければ水曜、今のように検収をすべて通すなら木曜です。どちらにしましょうか?」
この答えには三つが入っている。可能かどうか、その代償、選択肢。クライアントは空疎な約束ではなく、実際に決定できる情報を受け取る。品質を少し譲って一日前倒しするか、一日多く使って完成度を守るかは、クライアントが決めることだ。
肝心なのは、この変わった反応が、その日のAIがより賢くなったから出たわけではない、という点だ。一度やけどした場所に立てておいたルールが作動した結果だ。同じモデルでも、入り口にチェックがあるかないかで答えの質が分かれる。
ここまで読むと、「じゃあ失敗するたびにルールを作ればいい」と考えがちだ。ところがルールには逆側の落とし穴があり、むしろこちらのほうが多い。
ルールが積み上がるだけで整理されないと、AI PMは鈍くなる。「誤字を一つ直してください」のような軽い依頼にまでスケジュール照会や先行作業の確認が付くと、それは慎重なのではなく空気が読めていないだけだ。すべての依頼を同じように重く扱うのは、結局、何も重要に扱っていないのと同じだ。
だから、どの教訓をルールに昇格させるかには基準が要る。繰り返しの頻度だけで見ない。三つを一緒に見る。一、二度以上実際に起きたか。二、一度だけでもその被害が大きかったか。三、毎回確認するコストより、一度見逃したときの損失が大きいか。このうち一つでも明確なら昇格させる。一度しか起きず、被害も小さく、確認コストだけがかかることなら、記録は残すが入り口には掛けない。
下ろすべきルールも同じ目で見る。しばらく一度も引っかからなかったルールだからといって、無条件に廃棄するわけではない。二つを区別しなければならない。リスクそのものが消えたなら(例:その問題を生んでいた手順がなくなったなら)ルールも下ろす。逆にリスクはそのままなのに、そういう依頼が入ってくる機会がなかっただけなら、ルールは残しておく。
ルールは作ることより捨てることのほうが難しい。作るときは何かを改善した気分になるが、捨てるときは「また起きたら」という不安が足を引っ張る。その不安を基準で御するのが、より熟練した運用だ。
AI PMは、疲れを知らずに振り返りを書ける。人は忙しいと振り返りを飛ばし、事故が起きたときだけパッと書く。AIは毎日「今日間違えたことはあったか、あったなら発動条件と動作は何か」を淡々と書き上げられる。この律儀さそのものが、かなり大きな資産だ。
だが、その振り返りのうち何をルールに昇格させるかは、人が決めるのが正しい。この判断には事業の文脈が要るからだ。同じスケジュール変更でも、契約書に納期遅延の条項が絡む件かどうかで重みが違う。確認責任がこちら側にあるのか、クライアント側の変数なのかで、ルールに掛けるべきか否かが分かれる。先の納期の件が「すべてのクライアントに条件付きでのみ答えよ」になるのか、「納期変更が契約条項に絡む件に限って」になるのかは、その契約とスケジュール変更の影響を知る人が決めるべきだ。
だからONTLEでAI PMを運用するやり方はこうだ。AI PMが先の四つの箱の書式(事案・原因・発動条件・動作)で振り返りの下書きを毎日上げる。人間のPMはその下書きごとに、三つの箱の判定を付ける。「ルールに掛けよう」/「今回だけ」/「ルール不要(こちらの責任ではない)」。昇格したものだけが入り口に掛かり、残りは記録としてだけ残る。AIは記録し執行する側、人は何が記憶に値するかを判断する側だ。この承認手続きは、製品の核心というより、AI PMが暴走しないように押さえておく運用装置に近い。
こうして積み上がったルールの束は、時間が経つと一人の経験を超える。人の組織でいつも惜しいのがここだ。仕事ができる人が去ると、その人がやけどした記憶も一緒に去る。教訓が文章として刻まれていれば、担当者が代わっても、過去の失敗から生まれたチェックはその場に残る。
失敗しないマネージャーはいない。AIであれ人であれ。だから「失敗しないこと」を目標に据えるのは、最初から負ける戦いだ。目標は別のところに置くべきだ。一度やけどした場所に次の自分のためのチェックを立てておくこと、そのチェックを決意ではなく作動するルールにすること、そしてルールが膨れ上がらないよう間引くこと。AIプロジェクトマネージャーの仕事の勘は、この三つに表れる。
通常は内部用です。振り返りには、どの段階でどう滑ったかといった生々しい運用記録が含まれるため、そのまま外部に公開するより、人間のPMが取捨選択して伝えるのが適切です。ただし、クライアントに直接影響を与えた事案であれば、何が間違っていてどう正したかは透明に共有するほうが、信頼回復には良いです。記録全体を開けることと、その記録から出た結論を共有することは、別の問題です。
積み上がれば必ず起きます。「素早く答えよ」と「確約前に必ず照会せよ」が一つの依頼でぶつかる、という具合です。こういうときは、ルールごとに優先順位を付けておくのが現実的です。たいていはクライアントの信頼やデータ損失を防ぐルールが、速度や利便性を高めるルールより上に来ます。衝突が繰り返される二つのルールは、人間のPMが見直し、発動条件をさらに狭めて、両者が同じ入り口で出くわさないように整えるのが根本的な解決策です。
すべての失敗を記録しつつ、ルールに昇格させるものだけを別に選り分けます。記録とルールは別の層です。記録はとりあえず残しておく原材料で、ルールはそのうち「二度以上繰り返された、一度でも被害が大きかった、確認コストより見逃したときの損失が大きい」ものだけを選んで入り口に掛ける完成品です。記録が多いのは構いません。問題は、入り口に掛かったチェックが多いことです。この二つを混ぜないのが、ルールの山に埋もれないコツです。