前回は、「できない」と呼ばれる状態の多くは、その課題の暗黙知を知らないだけかもしれない、という話を書きました。今回はその続きとして、では手順書を整えればいいのか、というところを考えます。
最初は、手順書を充実させればいいと思っていた
確認観点をそろえたいと思ったとき、最初に浮かぶ道具は手順書です。私も例外ではありませんでした。よく整理された手順書があれば、担当者が変わっても同じ操作ができる。まずはそこから、と考えるのが自然だと思います。
実際、手順書はとても役に立ちます。どのサービスの、どのメニューを開き、どのボタンを押すか。操作の順番を言葉にして残せば、初めての人でも迷わず画面を進められます。私自身、初めて触るサービスで、手順書に助けられたことは何度もあります。
ただ、OpsMate Proを作るにあたって、いくつかの手順書を改めて読み直しているうちに、引っかかりが出てきました。そろえられているのは主に「操作」であって、その手前にある「なぜ確認するのか」は意外と書かれていない、と気づいたのです。手順書を書いていたころは、それで十分だと思っていました。読む側に回って初めて、抜けている部分が見えてきた感じでした。
「なぜ確認するか」が抜けやすい
たとえば「この画面でステータスを確認する」と書いてあっても、なぜそのステータスを見るのか、そこで何が分かるのかまでは省略されがちです。書いた本人にとっては当たり前だからです。当たり前のことは、わざわざ言葉にしません。
すると、手順どおりに画面は開けても、そこに表示された値が何を意味するのかが分からない、ということが起きます。操作は再現できているのに、判断ができない。画面は正しく進んでいるのに、頭の中では止まっている。これは案外つらい状態です。
手順を追うことと、状況を理解することは別物でした。目的を共有しないまま操作だけをなぞると、少し画面が違ったり、想定外の値が出たりした瞬間に、次の一歩が踏み出せなくなります。「書いてあるとおりにやったのに、この先が書いていない」という、あの手詰まりの感覚です。
正常値と異常値が書かれていない
もう一つ気になったのが、正常な状態と異常な状態の基準です。手順書には「確認する」とは書いてあっても、「どうなっていれば正常で、どうなっていたら異常なのか」までは書かれていないことが多いのです。
経験のある人は、表示された値を見た瞬間に、これは問題ない、これはおかしい、と判断できます。頭の中に基準があるからです。でもその基準は、たいてい言葉になっていません。感覚として持っているので、手順書には残りません。
未経験の人は、書かれていない部分を自分で補えません。値は読めても、それが良いのか悪いのか分からない。ここでも、暗黙知を持っているかどうかの差がそのまま出てしまいます。しかも本人は「確認した」と思っているので、抜けに気づきにくい。確認したのに判断していない、という状態が、静かに残ってしまいます。
前提が変わると、手順書は急に弱くなる
さらに、手順書は前提が固定されているときに強い道具です。画面のレイアウトが同じ、対象の構成が同じ、想定した状況どおり。その範囲では、手順書はきれいに機能します。
ところが実際の課題は、少しずつ前提が違います。想定していた設定と違う、画面の見た目が変わっている、途中で別の異常が混ざる。AWSのようにサービスの画面や機能が更新されていく環境では、なおさらです。そうなると、操作の順番だけを書いた手順書は、急に頼りなくなります。
経験者はこういうとき、手順から一度離れて、目的と判断基準に立ち返って動けます。暗黙知で補えるからです。「この手順が想定しているのはこういう状態で、目的はこれだから、今の状況ならこう読み替えればいい」と、頭の中で翻訳できます。逆に言えば、その暗黙知が共有されていないと、手順書は「順調なときだけ使える地図」になってしまいます。少しでも道が想定と違うと、地図の外に出てしまうわけです。
そろえるべきは、操作より確認観点と判断基準
ここまで来て、標準化すべき対象を取り違えていたのかもしれない、と思い直しました。そろえたかったのは操作の再現性そのものではなく、その手前にある確認観点と判断基準のほうです。
- 何のためにこの確認をするのか（目的）
- どこを見て、何の値を読むのか（確認する場所と値）
- どうなっていれば正常で、どうなっていたら異常か（判断基準）
- 何を証跡として残すのか
このあたりを課題の側に持たせておけば、操作の細部が多少変わっても、担当者は目的と基準に立ち返れます。操作をなぞるだけの手順書より、少しだけ揺らぎに強い形になるはずだと考えました。想定外に出会ったときに、地図の外へ放り出されるのではなく、「そもそも何を確かめたいのか」に戻れる。そこが違いだと思います。
もちろん、これは手順書を否定する話ではありません。操作の記述も必要ですし、うまく書かれた手順書は今でも強力です。
ただ、すべての手順書に対して、1動作ごとに正常値と異常値を細かく書き続けるのも現実的ではありません。対象となる設定や画面は多く、サービスの更新によって表示や仕様が変わることもあります。すべてを人の手で詳細に記載し、さらに最新の状態へ保ち続けようとすれば、手順書を作ること自体に膨大な時間がかかってしまいます。
細かく書けば暗黙知を減らせる一方で、作成やレビュー、更新の負担は増えていきます。逆に簡略化すれば、経験者の判断に依存する部分が残ります。
つまり、手順書だけを充実させても、前回書いた「観点をそろえる」にはたどり着けない、というのが今回の結論です。操作の外側にある確認観点と判断基準を、どこかにきちんと持たせないといけない。その「どこか」を、私は課題データの側に置こうと考えました。
言い換えると、手順書が答えているのは「どう操作するか」で、私が足したかったのは「なぜ確認し、どう判断するか」でした。この二つは、どちらが上ということではなく、役割が違うのだと思います。操作の手順は手順書に任せ、その手前の目的・判断基準・証跡は課題データに持たせる。そうやって役割を分けたほうが、両方とも書きやすくなる、という感覚もありました。一つの文書に全部を詰め込もうとすると、どちらも中途半端になりがちだからです。
次回へ
では、足りない確認観点を補うのに、AIに聞けばいいのではないか。手順書に書かれていない「なぜ」や「正常・異常」を、その都度AIに質問すれば埋まるのではないか。次回はそこを実際に考えてみて、AIチャットだけでは課題全体の現在地が見えにくい、と感じたところを書きます。