暗黙知をどうやってAIに理解させる？
ナレッジマネジメントの苦労話（前編）
- AIソリューション
- ソフトウェアテスト・品質保証
Introduction
「あの人が見ると、なぜか不具合が見つかる」
システムの開発やリニューアルの現場には、こんな人がいないでしょうか。仕様書を一目見ただけで「ここは確認しておいた方がいい」と言い当てるベテラン。リリース前のレビューで「この画面、月末の処理と重なると危ない」と気づく担当者。そして実際に、その指摘どおりの不具合が見つかる——。
品質がそうした人に支えられていること自体は、悪いことではありません。問題は、その判断の根拠が仕様書のどこにも書かれていないことです。担当者が異動する、チームを増員する、テストを外部に委託する。そのたびに品質が揺れてしまうなら、その組織の品質はまだ個人の経験に依存していて、組織の資産にはなっていません。
本コラムは、株式会社 SHIFT が AI テストの現場で向き合ってきた「暗黙知」との付き合い方を、前編・後編の2回に分けてお届けする苦労話です。前編では、多くの組織に共通する「暗黙知を資産にしようとして、うまくいかないあるある」を取り上げます。ご自身の組織に重ねながら読んでいただければ幸いです。
目次
暗黙知とは—仕様書に書かれていない「現場の判断」
暗黙知とは、仕様書には書かれていないのに、現場では当然のように使われている判断のことです。
イメージしやすいように、新しく参画した優秀なテスト担当者に仕様書を渡す場面を考えてみます。仕様書を読めば、画面の項目や処理の流れは理解できます。ところが実際のレビューでは、「この項目は過去に問い合わせが多かった」「この条件は業務上ほとんど使われないが、使われたときの影響が大きい」「ここはお客様の受入で必ず見られる」といった話が出てきます。どれも仕様書には書かれていない、しかしテストの成否を左右する判断です。
もう少し具体的な例を挙げます。基幹システムの刷新で「承認フローのテスト」をする場面です。仕様書には「上長承認のあと経理承認へ進む」と書かれていても、実際には特定の部門だけ例外ルートがある、月末だけ承認者が変わる、監査では差戻しの履歴が重視される、といった事情があります。こうした事情を知らないままテストを組み立てると、見た目は網羅的でも、現場で本当に起きる問題を素通りしてしまいます。
*図: 仕様書に書かれている情報だけでは、現場で判断されている例外・監査・受入の観点まで拾いきれないことがあります。*
これは開発側・テスト側だけの話ではありません。お客様の現場にも、業務を回してきた担当者だからこそ知っている判断があります。画面上は同じ「承認」でも、部署によって確認すべきリスクが違う。帳票の項目名は同じでも、監査で見られる意味が違う。品質を支えているのは、実はこうした「書かれていない判断」の層なのです。
暗黙知の資産化、失敗あるある
「では、書き残せばいいのでは」と思われるかもしれません。私たちも、そう考えて何度も挑戦してきました。ところが、暗黙知を資産にする取り組みには、典型的な失敗パターンがあります。
失敗あるある1:
とにかく書き残す—誰も読まないドキュメントの山
「気づいたことは何でもナレッジ集に書こう」と始めると、最初の数か月は順調に溜まります。しかし整理の軸がないまま増えたメモは、次の案件で「どれを読めばいいのか」がわからず 、結局誰も参照しなくなります。書くコストだけが残り、取り組み自体が立ち消えになる——最もよくあるパターンです。
失敗あるある2:
きれいに一般化する — 当たり前のことしか残らない
逆に、誰でも使えるようにと抽象的にまとめると、「境界値は注意して確認する」「例外系も忘れずに」といった、教科書に書いてあるレベルの一般論だけが残ります。ベテランの判断の価値は「この業務の、この画面で、これが危ない」という具体性にあります。一般化した瞬間に、その価値が抜け落ちてしまうのです。
失敗あるある3:
具体的に書きすぎる — その案件でしか使えない
では具体的に書けばよいかというと、今度は案件固有の情報に寄りすぎて、次の案件では使えないメモになります。加えて、お客様固有の情報をどこまで書いてよいのかという、情報の取り扱いの問題も出てきます。細かければよいわけでも、抽象的ならよいわけでもない。この「ちょうどいい粒度」の探索が、想像以上に難しいのです。
失敗あるある4:
種類の違う知識を混ぜる—どこで使う知識か分からなくなる
もうひとつ見落とされがちなのが、知識の「種類」です。その知見は、製品や画面に固有の話なのか。お客様の業務や受入基準に固有の話なのか。業界の法規制や商習慣の話なのか。それとも、案件をまたいで使えるテスト技術の話なのか。種類の違う知識をひとつの入れ物に混ぜると、あとから「これはどの案件で使ってよい知識なのか」が判別できなくなり、ナレッジ全体の信頼が落ちていきます。
私たちの経験では、暗黙知を資産にする第一歩は、知見を増やすことではなく、混ぜてはいけない知見を分けることでした。
SHIFTも、同じ壁に向き合ってきた
SHIFT はテストの専門会社として、数多くの現場でこの壁に向き合ってきました。ベテランのテスト設計者が持つ判断を、個人の頭の中から取り出し、業務の進め方やレビューの型として誰でも再現できる形にする。長年かけて積み上げてきたこの取り組みが、いま SHIFT が提供する AI テストの土台になっています。
ただし、ここまで読んで「AI に暗黙知を学ばせれば解決」と感じた方には、先にお伝えしておきます。私たちが実際にやってみて学んだのは、AI は魔法ではなく、暗黙知との向き合い方の順序を間違えると、AI を使っても同じ失敗を繰り返すということでした。
後編では、SHIFT がテストの暗黙知をどのような土台の上で扱い、AI を活用したサービスとしてお客様に届けるまでに何につまずき、何を学んだのかをお話しします。
おわりに — まず、自組織の「書かれていない判断」を眺めてみる
前編のまとめです。
1.品質を支えているのは、仕様書に書かれていない「現場の判断」= 暗黙知である。
2.暗黙知の資産化には典型的な失敗パターンがある。書きすぎても、一般化しすぎても使えない。
3.第一歩は知見を増やすことではなく、種類の違う知識を分けることから始まる。
もし、テストの属人化や品質のばらつきに課題を感じているなら、まずは自組織で「仕様書に書かれていないのに、いつも誰かが口頭で補っている判断」を思い浮かべてみてください。それが、みなさま の組織の暗黙知の入り口です。
SHIFT では、こうした暗黙知への取り組みを土台にした AI テストのソリューション AIテストセンター ネムラナイ を提供しています。
詳しくは AIテストセンター ネムラナイの紹介ページをご覧ください。
後編「テストの暗黙知を、サービスとして届けるまで」に続きます。
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
