このシリーズでは、個人で作っている「AWS OpsMate Pro」という運用支援ツールの開発記録を残していきます。第1回は、まだコードの話をしません。なぜこのツールを作ろうと思ったのか、その入口にあった違和感を書いておきたいからです。ここがぶれると、あとの回が全部ぶれてしまう気がするので、少し丁寧に書きます。
「標準化」という言葉に、少し身構えてしまう
運用や保守の現場では、「標準化」や「再現性」という言葉をよく耳にします。手順をそろえれば、誰がやっても同じ結果になる。品質が安定する。属人化がなくなる。言葉としては正しいと思いますし、目指す方向にも異論はありません。
ただ、この言葉を聞くたびに、私はどこか身構えてしまうところがありました。標準化という言葉が、いつのまにか「人を同じ型にそろえること」として語られている場面を、何度か見てきたからです。手順をそろえる話だったはずが、いつのまにか人をそろえる話にすり替わっている、という感覚です。
同じ手順書を渡したのに、片方はすらすら進み、もう片方は途中で止まってしまう。そうすると「あの人はできる」「この人はできない」という評価になりがちです。でも、本当にそれは能力の差なのだろうか、と引っかかっていました。同じ手順書なのに差が出るなら、手順書だけでは足りない何かがある、ということでもあるはずです。
出身分野が違えば、最初に見る場所が違う
少し考えると、当たり前のことに気づきます。運用に関わる人は、それぞれ違う道を通ってきています。ネットワークが得意な人、サーバー構築が長い人、クラウドから入った人、開発寄りの人、セキュリティを見てきた人。同じチームでも、頭の中の地図はかなり違います。
たとえば「サイトが見られない」という一つの事象でも、ネットワーク出身の人はまずDNSや経路を疑い、サーバー出身の人はプロセスやログを見に行き、クラウドから入った人は配信サービスの設定を開きます。どれも間違いではありません。どれもその人の経験に裏打ちされた、まっとうな一手です。ただ、最初に手が伸びる場所が違うのです。
この違いは、慣れた課題では大きな問題になりません。自分の得意分野の課題なら、最初の一手がたいてい正解に近いからです。問題は、自分の得意分野の外にある課題を担当したときに起きます。そこでは、経験のある人でも、最初にどこを見ればいいのか分からなくなります。
そして、この「最初にどこを見るか」「何を危険だと感じるか」「正常か異常かをどう判断するか」「どこまで証跡として残すか」といった感覚は、手順書にはあまり書かれていません。書いた人にとっては、あまりに当たり前で、わざわざ言葉にする対象ではないからです。当たり前すぎて、書き落とされる。これが、後の回でも繰り返し出てくるテーマになります。
暗黙知を知らないことと、能力が低いことは違う
つまり、多くの現場で「できる／できない」と呼ばれているものの正体は、その課題に固有の暗黙知や常識を、たまたま知っているかどうかの差だったのではないか。私はそう考えるようになりました。
ある領域では常識でも、別の領域から来た人には共有されていない。それを知らないまま作業に入ると、確認の順番を間違えたり、見るべき値を見落としたりします。結果として遅くなり、判断も鈍り、「この人はできない」と受け取られてしまう。
でも、それはその人の理解力の問題というより、課題側が必要な確認観点を渡せていない問題ではないかと思ったのです。知っていれば同じようにたどり着けるものを、たまたま知らなかっただけなら、それは埋められる差です。少なくとも、生まれ持った能力の差として片付けるより、そのほうが前向きだと感じました。
もちろん、これは「努力や経験が無意味だ」という話ではありません。深い経験は、やはり強いです。ただ、経験の入口の部分――「この課題ではまずここを見る」という最初の道筋――までは、暗黙知として個人の頭に閉じ込めておかなくてもいいのではないか。そこは共有できるのではないか、と考えました。
人をそろえるのではなく、観点をそろえたい
そこで発想を逆にしてみました。人を同じレベルにそろえようとするのではなく、「その課題に必要な確認観点へ、誰が担当しても自然にたどり着ける状態」を作れないだろうか、と。
標準化の対象を、人ではなく課題に置く。課題の側に、目的・背景・確認する場所・正常と異常の判断基準・残すべき証跡を持たせておく。そうすれば、担当者がどの分野の出身であっても、少なくとも「見るべきところを見ないまま進んでしまう」ことは減らせるはずです。
これは、全員を同じ考え方に矯正することとは違います。得意分野の違いはそのままでいい。ネットワークの人はネットワークの強みを、開発の人は開発の強みを持ったままでいい。ただ、その課題で最低限たどるべき道筋だけは、誰の頭の中にも同じように現れてほしい。そういう標準化のかたちを作りたいと思いました。人の多様さを削るのではなく、課題の見せ方をそろえる、という方向です。
AWS OpsMate Proを作ろうと思った
この考えを、自分の手が届く範囲で試したくなりました。それが、個人で作り始めた「AWS OpsMate Pro」です。AWSの運用でよくある課題を題材に、確認観点そのものをデータとして持たせ、担当者を最初から最後まで導けないかを検証するツールです。
ここで一つだけ、正直に線を引いておきます。このツールは、AWSの実環境へ接続して何かを変更するものではありません。あくまで確認と判断と記録を支援するもので、実際の操作は使う人が正式な手順で行う前提です。派手な自動化ではなく、地味な「観点の共有」を扱うツールだと考えています。むしろ、この地味さこそが今回のテーマだと思っています。
このシリーズで書いていくこと
次回からは、なぜ手順書だけでは足りないと感じたのか、なぜチャット型のAIだけでは物足りなかったのか、というところから順に掘り下げていきます。そのうえで、実際にどんなデータモデルや画面を作ったのかを、コードも交えて記録していく予定です。3つの課題を具体的に作った話や、AIの役割をどこまでに絞ったか、といった話も出てきます。
自分でも、まだ正解を持っているわけではありません。作りながら考えを変えた部分もありますし、できていないことも多く残っています。それでも、「できない人」と呼ばれてしまう場面を少しでも減らせる設計はないか、という最初の問いだけは、シリーズ全体を通してぶらさずに書いていきたいと思います。
次回は、その第一歩として「手順書をそろえるだけでは、本当の標準化にならないと思った」理由を書きます。