f-viktor@github.io%

「ベストプラクティス」を超えて

The Best cats are YOUR CATS

セキュリティ分野で働く人なら、「ベストプラクティス」のリストやそれに付随するチェックリストを目にしたことがあるのではないでしょうか。これらのベストプラクティスは、最低限きちんとしたセキュリティ水準を満たすために、そして、「うちの会社はちゃんとやっていますよ」と他社に示すために作られたものです。

中には、私よりもずっと賢い人たちや、今このブログを読んでくれているみなさんと同じくらい賢い人たちによって書かれたものもあります。
では、ベストプラクティスを「改善する」ことは本当に可能なのでしょうか。

具体性と普遍性

これらのガイドラインは、専門家委員会がさまざまな企業での経験をもとに、誰でも使える普遍的なルール体系を作るために策定したものです。彼らは、現実世界に存在するさまざまな企業に広く適用でき、それらを管理可能な形へと整理する仕組みを目指しました。標準化とは、現実世界にある自然な複雑さを、扱いやすく単純化した抽象モデルに無理やり当てはめ、スケールさせようという試みです。

しかし、専門家委員会が特定の企業の内情を細部まで把握することは現実的に不可能です。「あらゆる会社で使えるガイドライン」を作ることが目的だった以上、特定の会社にとって「ベスト」なプラクティスを作るのはそもそも無理があります。

二つとして同じ企業など存在しない以上、それぞれにとってのベストプラクティスも異なって当然です。
つまり、いわゆる「ベストプラクティス」とは、あくまで「一般的な会社」という理論上の抽象モデルにとっての「ベスト」であるに過ぎないのです。

「自分で作るな」という教訓

私がよく口にする教訓のひとつに「暗号を自作するな（Don’t roll your own crypto）」というものがあります。ここに込められているメッセージは「謙虚さ」です。「賢人たちが膨大な時間をかけて良いものを作ってきた。自分がその人たちより賢いなどと思うな」ということです。

新しいことを学ぶとき、私たちはたいていルールを教わります。音楽の先生は「この和音は常に明るい」と言い、国語の先生は「文章は起承転結で書け」と言い、料理のプロは「ピザにパイナップルをのせるな」と言います。

しかし、初心者にとって絶対的な法則に見えるものも、専門家にとっては単なる目安に過ぎないことがよくあります。
最高の音楽家は常識など気にせず演奏し、最高の詩人は文の構造に縛られずに書く。だから私は、自分のピザには好きな具を好きなだけのせます。

これらのルールは物事を単純化したものであり、だいたいは正しいけれど、いつでも通用する絶対的な真理ではありません。専門家になること、それは、そもそもなぜそのルールが存在するのかを理解することです。そのルールが作られた仕組みを完全に理解すれば、ルールを守るべき場面と、根本的な仕組みを踏まえて判断すべき場面を見極められるようになります。そして後者の場合こそが「ベスト」を超えられる場面なのです。

結局、インシデントが発生したら、PCI Standards CouncilやISOのチェックリストを満たしていたからといって責任を免れることはできません。結果に対する責任を負うのは私たち自身です。だからこそ、専門家を名乗るに恥じない存在にならなくてはいけません。自分たちの状況にとって本当にベストなものを生み出せるのは自分たちしかいないのです。もちろん、基準を無視してよいという意味ではありません。基準をどう守るのか、そしてより高い水準へどう引き上げていくのかを考える必要がある、ということです。

今、この場所で

あなたの会社は、他社と何が違うのでしょうか。各企業はそれぞれ、特定の時代や場所、業界、そして変化する市場環境という条件の中で事業を行っています。また、どの程度のリスクを取るかも企業によって違います。こうした要素は重要ですが、あまり語られることのないものもあります。
それは、会社を構成している「人」そのものです。

企業は社内で働く従業員を、取り替えのきく「人的資源」として捉えがちです。というのも、数千人規模の組織を統括する立場にいると、セキュリティ部門に何人いるのかを把握するだけでも大変だからです。ましてや、一人ひとりの強みや弱みまで把握することは不可能でしょう。一方で、より現場に近いマネジメント層やチームの中では、人は名前で呼ばれ、誰がどんな強みを持っているかについてもある程度の共通認識があります。

たとえば、モバイルセキュリティに関して抜きん出たスキルを持つメンバーがチームにいるとしたら？

プレゼンテーションが得意な人がいるとしたら？

多種多様なプロダクトを抱えている場合は？

一人ひとりの特性を理解することで、リソースをより適切に配分できるようになります。さらに重要なのは、「コンプライアンス対応」が「実際に価値を生む仕事へと変わる」ということです。個々の開発者が「このポリシーは自分のプロダクトにとって本当に意味がある」と理解できたときにこそ、強力な成果は生まれます。そのためには、それぞれの状況をきちんと理解したうえで、現場でそれを使う人たちを前提としたポリシーを設計する必要があります。理由が「ベストプラクティスだから」といった表面的なものにとどまっていると、開発者のモチベーションは一気に下がります。

人は多くの場合、習慣で物事を行ったり、標準だからという理由で従ったり、他社がそうしているからという理由で同じことをします。しかしみなさんには「なぜそれをやるのか」を考えてほしいのです。本当に達成したいことは何なのか。その「ベストプラクティス」は、本当にその目的に導いてくれるものですか？

主な学び