「正解がわからない」から始まった判断基準づくり

第一章　正解がわからない

「正解がわからないんです」

難航したプロジェクトを振り返っていた時、サブリーダーがそう言った。

私は思わず聞き返した。

「わからない？
正解が？」

技術的に難易度が高い案件ではあった。
有識者もいた。
レビューも進捗報告もあった。

それでも、プロジェクトは次第にコントロールを失っていった。

何が起こっていたのか。
何が足りなかったのか。

私たちは何度も話を聞いた。

一つひとつ事実を確認し、「なぜ」を繰り返しながら原因を探っていく。
お互いが、なぜなぜ分析にも慣れてきた頃だった。
ようやく彼は、胸の内に抱えていた思いを口にした。

「レビューで何を見ればいいのか。
どこまでやれば完了なのか。
その判断に自信が持てなかったんです」

「え……？」

その言葉を聞いた瞬間、私はほっとした。
やっと、本当の問題が出てきた。

私は考えた。
問題は人ではない。
足りなかったのは、判断基準だった。

対策の方向性は見えた。
だから最初にやるべきことは、人を責めることでも、新しい仕組みを導入することでもない。
「何がわからないのか」を言葉にし、それを共有できる組織を作る方向へ舵を切った。

この出来事を境に、私の役割は変わった。
品質を守るだけでなく、「正解」を次の世代へ伝えることも私の仕事になった。

彼の言葉を聞いて、私はこのサブリーダーを育てたいと思った。
同じように悩む人を、これ以上増やしたくない。

その時、強く意識した言葉がある。

「属人化」だ。

レビューの勘所も、難航の兆候も、「なんとなく」で判断される。
だが、その「なんとなく」は言葉になっていなければ共有できない。
結果として、若手は判断基準を持てないまま走り続ける。

かつては、経験豊富な人の勘や判断に頼っても仕事は回っていた。
しかし、その「正解」が共有されないままでは、人が変わるたびに同じ失敗を繰り返してしまう。
今は、その勘を言葉にし、誰もがたどり着ける「正解」として残さなければ、次の世代へ引き継ぐことはできない。

では、その「正解」をどう残せばいいのか。
マニュアルだけでは限界がある。
経験を文章にするだけでも十分ではない。
誰もが必要なときに取り出し、判断に生かせる形で残す方法が必要だった。

私は、属人化された知識や判断基準を、組織の知識として残せないかと考えるようになった。

その方法を探す中で、AIという選択肢が見えてきた。

第二章　経験は継承できるか

しかし、AIを使う前に考えなければならないことがあった。
そもそも、経験とは何なのか。

今は、経験を積む機会そのものが多くはない。
だからこそ、成功や失敗を通してしか身につかない感覚を受け継ぐことが難しくなっている。

数多くの失敗と成功を通して、少しずつ危険の兆候や成功する型が見えてくる。しかし、そうした感覚は言葉にしなければ継承できない。
有識者が現場を離れれば、その感覚も一緒に消えてしまう。

若い頃は、有識者が「ここは危ない」と言う理由がよく分からなかった。
それでも、「きっと何かが見えているのだろう」と思いながら、その背中を追いかけていた。

「経験だから」

そう言われても、その経験の正体までは教わらなかった。

若い頃の私は、間違える方が悪い、とさえ思っていた。判断基準を知らないまま、ただ結果だけを見ていたのだ。
今思えば、かなり危うい考え方だった。

自分が間違える側になるとは思っていなかったし、失敗には理由があるとも考えていなかった。

しかし、自分も間違えた。
人の間違いにも巻き込まれた。
難航したプロジェクトを振り返るうちに、一つ気づいたことがある。
失敗は偶然ではなかった。
失敗には、驚くほど似たパターンがある。

あの日、サブリーダーの「正解がわからないんです」という一言を聞いた時、私は昔の自分を思い出した。

有識者の言葉を必死に追いかけながら、「なぜそう判断するのか」が分からずに仕事をしていた頃の自分だ。
あの日の出来事は、私自身の経験の意味を改めて考えるきっかけになった。

定年が近づくにつれ、そのことを以前より強く意識するようになった。
これまで現場で学んできた判断基準を、次の世代へ残したい。

その思いが、AI導入に取り組む原点だった。
AIに期待したのは、人の代わりになることではない。仕事を奪うことでもなかった。

有識者が持つ観点や判断基準を、人が変わっても受け継げる形で残したかった。

第三章　AIはどう育ったか

では、実際に私はAIをどう使い始めたのか。
AIを本格的に使い始めたきっかけは、そんなに立派なものではない。

プロジェクト管理者向けの研修資料を作っていた時のことだ。
演習で使うレビューコメントを用意するため、AIにレビューコメントを50件作らせてみた。
思った以上に、それらしいレビューコメントが出来上がった。

「これは使える」

そう思った。
次は、そのレビューコメントを「技術」「設計」「運用」「認識のずれ」といった観点で分類したかった。
しかし、50件を一つひとつ読みながら整理するのは、正直なところ面倒だった。

「これもAIにやらせてみよう」

そう思って試してみると、分類はあっという間に終わった。

「いい感じだ」

AIは叩き台としては十分だった。
しかし、プロジェクト管理者向けの研修として使うには、そのままでは足りない。
品質の観点で分類し、判断基準を加える必要があった。

そこで私は、AIへの指示を書き直した。

「あなたは品質部長です」

「あなたの最大のミッションは、炎上プロジェクトを防ぐためにリスクを検知することです」

「品質の観点で分類してください」

期待する役割や判断基準を、一つひとつ言葉にして伝えていく。
最初から思い通りの結果が出るわけではない。

例えば、レビューコメントを工程ごとに分類させたところ、本来は設計段階の課題として扱うべきコメントが、「運用」に分類されるケースがあった。

原因を確認すると、コメントの表現が曖昧で、AIが判断に迷っていたのだ。
そこで、分類結果だけでなく自信度も出力するよう指示を変更した。
判断に迷ったケースを、人が優先的に確認できるようにするためだ。

自信度が低いものだけを人が確認すればよい。
AIが一次判定を行い、人は判断が難しいものに集中する。
その結果、確認の負担を大きく減らすことができた。

こうして、AIの答えは少しずつ、私が求めるものへ近づいていった。

私はAIを育てているつもりだった。

しかし、振り返ると違っていた。
本当に磨かれていたのは、私自身の判断基準だったのである。

レビューでは、誤字脱字だけを見ているわけではない。

「100件同時に発注操作が行われても、システムは止まらないか」

「障害が起きたあと、安全に復旧できるか」

「そもそも、業務側と開発側で、前提となる認識は一致しているか」

レビューとは、未来に起こり得る失敗を想像し続ける仕事である。
その観点を「技術」「設計」「運用」「認識のずれ」といった形で整理し、どの工程で検出すべきだったのかを言葉にしていく。

難航の兆候を、再利用できる知識へ変えていく。
一人の経験を、組織の経験へ変えていく。
地味で、時間のかかる仕事だった。

その過程で、私は一つの結論にたどり着いた。

人の経験をAIが理解できる形へ翻訳する。
その考え方は、その後のAI活用全体にも広がっていった。

私は、その翻訳こそが、AI活用の本質だと思っている。

第四章　「AIは嘘をつく」と言う前に、言葉を磨く

その考え方を、品質活動全体へ広げていった。
最初に取り組んだのは、「AIに何をしてほしいのか」を整理することだった。

期待が曖昧なままでは、AIはもちろん、人同士でも議論はかみ合わない。
特にAIのように期待が先行しやすいテーマでは、「何をやるのか」、「何をもって成功とするのか」が共有されないまま、議論が広がっていく。

そこで私は、目的、期待する成果、役割分担を言葉にし、チームで共有した。
その過程で、こんな言葉を何度も耳にした。

「AIは嘘をつく」

だが、本当に「嘘」なのだろうか。
私は少し違う見方をしている。

私たちが期待を十分に言葉にできていなかっただけではないのか。
そう考えるようになってから、私はAIへの向き合い方を変えた。AIの答えを疑うのではなく、自分たちの指示を見直すようになった。

期待する成果や判断基準を書き直すたびに、チームの認識も少しずつそろっていった。
散らばっていた議論は構造を持ち始め、チームとしての「正解」が見えるようになってきた。

AI導入とは、ツール導入ではない。
組織が抱える課題や暗黙知を可視化する活動なのだ。

第五章　「誰のミスか」から「なぜ止められなかったか」へ

では、その考え方は、本当に現場で通用するのだろうか。
言葉にした判断基準は、品質活動に生かせるのか。
それを確かめるため、私は小さな検証を始めた。

システム全体を確認する総合試験の不具合表をもとに、品質分析にAIを取り入れることだった。

AIに「品質部長」として不具合の分析をさせる。
どの工程で検出すべきだったのか。
どの機能に不具合が多いのか。
そうした観点で整理・集計させる。

そして、その結果をもとに人が品質を分析する。
AIが品質を判断するのではない。
AIは情報を整理し、人が判断するための材料を用意する。
判断するのは、最後まで人である。

私が目指したのは、AIと人のそんな役割分担だった。

小さく試し、動かし、また考える。
壮大な構想より、小さく試すこと。
それが私のやり方だった。
試作を重ねるうちに、議論も変わっていった。

「AIで何ができるか」ではなく、
「自分たちは何を正解としたいのか」

という話が増えていったのである。

原因分析も、
「誰のミスだったのか」
から、
「なぜ止められなかったのか」
へ変わっていった。

レビューで何を見るのか。
どこまでできたら先へ進むのか。
どんな時に立ち止まるのか。

チームは少しずつ、自分たちの正解を作り始めていた。
私は、その変化が何より重要だと思った。

今、あのサブリーダーは、AIが整理した分析結果を見ながら、「ここはリスクが残っています。一度止めましょう」と自ら判断できるようになった。

あの日、「正解がわからない」と打ち明けてくれた彼は、今では自分の判断基準を言葉にできるようになったのである。

答えを出したのはAIではない。
AIをきっかけに、人間同士の会話が変わった。
それこそが、私にとってAI導入で得られた一番大きな成果だった。

第六章　正解は育てるもの

AI導入を通して、改めて考えるようになったことがある。
品質責任者として、一番怖いものは何か。

気づかないうちに、みんなで間違った方向へ進んでしまうことだ。
ともすると、その間違いが正解だと思い込む。
そして、その状態こそが、一番修正しにくい。

プログラムを直すなら、力仕事で何とかなる。
バグを修正し、テストをやり直せばいい。
だが、人の認識はそう簡単には変えられない。

「これでいい」
「前もこうだった」
「誰も止めないのだから問題ない」

難航するプロジェクトでは、不思議なくらいこの言葉が出てくる。

だが、「前もこうだった」は、安全だったことの証明ではない。
前回は、たまたま問題にならなかっただけかもしれない。
そんな思い込みが積み重なると、間違いは組織の「当たり前」になってしまう。

だからこそ、「止める勇気」が必要になる。

難航したプロジェクトを振り返ると、止めるべきタイミングは、一度ではなかった。
しかし、そのたびに「もう少し様子を見よう」という判断が積み重なっていった。

もちろん、振り返りだからこそ見えることもある。

振り返る目的は、誰かを責めることではない。次に、より良い判断ができるようにするためだ。

だからこそ、「なぜ止められなかったのか」を考えることには意味がある。

レビューがどの状態なら合格なのか。
どのリスクなら立ち止まるべきなのか。
どのタイミングで上司へ相談すべきなのか。

その判断基準が共有されていないと、人は流される。
だが、曖昧なまま進めた問題は、時間とともに何倍にも膨れ上がる。
だからといって、立ち止まるという判断も簡単ではない。
進むことにも、止まることにも責任が伴う。

だから私は、正解は一つではないと思っている。

選択肢はいくつもある。
どれを選ぶかは難しい。
それでも大切なのは、限られた情報の中で、そのとき最善だと思える判断をすることだ。

そして、本当に大切なのは選んだ後だ。

その選択が正しかったと思えるように考え、学び、行動を続けること。
その積み重ねが、選んだ道を「正解」にしていくのだと思う。

技術は変わる。
市場は変わる。
組織も、人も変わる。

だから、正解もまた、常に変わり続ける。

私が何度も書き直したチェックリストも同じだった。
新しい技術や失敗から学ぶたびに、判断基準を書き足してきた。
チェックリストは完成品ではない。
組織知を育て続けるためのものなのである。

AIも同じである。

一度作って終わりではない。
試し、学び、改善し続けることで、組織の判断基準は磨かれていく。

ベテランの役割は、すべての答えを知っていることではない。
次の世代が、より良い正解をつくれるように種をまくことだ。

経験を言葉にし、判断基準を残し、組織知として育てていく。
その種は、次の世代の現場で育ち、新しい正解になっていく。

AIは答えを出すための存在ではない。

情報を整理し、見落としを減らし、人が判断するための材料を示してくれる存在だ。

最後に判断するのは、人だ。

正解は、経験を重ねながら、つくっていくものだ。

経験を言葉にし、
知識を共有し、
組織で学び続ける。
その積み重ねが、昨日より少しだけ良い判断を育てていく。

私は、そのプロセスそのものを「正解」と呼びたい。

あの日、  
「正解がわからないんです」  
と打ち明けてくれたサブリーダーがいた。

あの一言が、私の品質活動を変えた。
私が次の世代に残すべきものは、答えなどでなく判断基準なのだと教えてくれた。

正解は待つものではない。  
人と組織が育てていくものなのだ。

これはシステム開発の品質保証の記録である。
しかし、本当に残したかったのは品質の仕組みではない。

経験を言葉にし、判断基準として次の世代へ手渡していく。

有識者が現場を去れば、知識は継承されない。
だから私は、この本を書いた。

#創作大賞2026
#ビジネス部門 　
#経験を言葉にする
#判断基準
#組織知  
#次世代育成
#品質保証