いいマニュアルの作り方
序：日々転変する現実と「マニュアル」
マニュアル、作りますよね。ドキュメンテーションは有史以来人間の集団にとって必要不可欠なもので、複数人が集まって何かやろうと思ったらマニュアルは常に作成される運命にあると思っていいと思います。
もっとも、変化の速い現代社会にあっては、書かれたマニュアルは簡単に陳腐化します。業務マニュアルに限って言っても、かつての重厚長大型産業における（長い目で見ればそんなに頻繁に作業内容が変わらない）製造業と、日々新たなデバイスやソフトが導入されてくる現代のサービス業とでは業務内容が更新される頻度が全く異なるであろうことは容易に想像がつきます。
なんでこんな話をしているかというと、私が所属するリーガルテックスタートアップであるMNTSQでも業務内容をマニュアル化（ドキュメント化）するというのは当然に行われているのですが、具体の記載はプロダクト自体のアップデートや状況の変化で一瞬で使えなくなることが多いです。
そうすると、そんなマニュアル作らなくていいんじゃないかみたいな気持ちになってくるのですが、参照されるドキュメントがなければ組織がスケールしませんし（非同期のインプットが不可能になる）（OJT全部口頭でやるのか？）、開発のために必要な知識が脳内にしかないという状況は不健全です（組織にナレッジが蓄積されない）（担当者辞めたら終わりか？）。他方、陳腐化したマニュアルを後生大事に墨守し「これでよし」と考えるのも愚かな所業であると言わざるを得ません。
ここには、変化の速いビジネスにあっては、マニュアルに書かれなければならない情報自体を工夫しなければならない、という問題意識があります。
本稿では、３つの視点から、日々転変する現実に対処するにふさわしい「マニュアル」はどのような性質を備えているべきかを考えてみます。
１．規律密度
第一に、マニュアルに記載する事項を「どこまで細かく書くか」という問題があります。一般論として、ある程度わかっている人向けに書くなら、あまり細かいことを書く必要はなく、逆もまた然りです。基本的なことですが、誰がどのような理解度で何の作業をするためのマニュアルなのかを明確に意識しておく必要があります。それによって記載する専門用語や前提知識の粒度も変わってくるはずです。
また、マニュアルはできるだけ簡潔なほうが望ましいです。人生は有限なので、不要な情報を記載すべきではありません。本当に必要な情報が希釈されてしまうし、outdatedな情報が増えることによりメンテナンス工数も爆増してしまいます。
些末な規律が多いことには上記以外の弊害もあります。
一つは、陳腐化することがわかっているマニュアルの書き手は、現在の作業ルールは常に暫定的なものであることを認識していますが、新たな読み手はその文脈を共有していません。マニュアルの読み手は往々にして当該マニュアル以外の情報は何も持たされていないので、「守らなくていいルールがいつまでも更新されずに遵守される」事態が簡単に発生します（次章で詳述）。一定の前提条件に支えられて初めて意味を持つルールは、そうした前提条件と合わせて併記することによって、読み手が自分の頭で当該ルールの射程を理解し、必要に応じて修正することができるようになります。
もう一つは、流派に関する問題で、特にエンジニア間で顕著だと思いますが、同じ目的を達成するために複数の手段が存在し、どれも無差別である場合は、特定の一つの手段を指定すること自体が不要であるように思われます。マニュアルの書き手は、できるだけ丁寧に書こうとして「おれのかんがえたさいきょうのやり方」を書いてしまいがちですが、読み手へのリスペクトを欠いたマニュアルは読み手からリスペクトされないので、変に規律密度を上げすぎず、読み手の自走的な思考を補助するような書き方を工夫する必要があるように思います（具体的には、プロセスの目的のみを明示しその手段は読み手に委ねるなどが考えられます）。プレイヤーの裁量を確保する、という視点が必要です。
２．principleとrule
上記の規律密度に関する問題は、つまるところ「簡にして要を得るマニュアルには何を記載するべきか／何を削るべきか」という問題だと思います。ここでは、私独自の視点から、二つの軸で整理したいと思います。
まず、マニュアルはprincipleとruleという異なる内容に整理できると思います。principle（原則）とは、組織の目的や問題意識から導かれる原理原則であり、rule（準則）とは、原理原則を達成するために具体化された個別の行動準則です。
たとえば、会社の情報セキュリティマネジメントを行うこと、情報漏洩を防ぐことがprincipleであり、このprincipleを達成するために、個別のセキュリティルール（USBの使用規程、文書管理規程、クラウドの利用ポリシー等々）などがrule化されます。もっとも、principleは相反するポリシーが複数あるのが通常で、セキュリティの例で言えば、リモートワークの推進、予算の最小化、業務効率化なども同時に追求すべきprincipleとなるでしょうから、これらを合理的に比較衡量した結果をrule化することになります。
状況の変化によっては、principleは変わらなくてもruleは変更されることがあるし、principle自体も変わることがあります。
問題を抱えている多くのマニュアルは、ruleだけを記載し、principleについては何も触れていないことが多いです。そのため、なぜそのruleを守らなければならないのか、なぜそのような操作をしなければならないのかがさっぱりわからないので、読み手は記載してあるruleすら本当の意味で理解することができません。後進が理解できなければ、ruleが陳腐化してもその問題に誰も気付くことができないし、長期的には成長しない組織が爆誕します。
弊社の例で言うと、弊社ではBizチームもLegalチームも全員GitHubを操作できる必要があるのですが、このハードルを達成するためには、単にGitHubの操作方法を説明するだけでは全然足りないです。
GitHubでドキュメントを管理する目的、MNTSQ社が理想とするドキュメント文化の在り方、Gitの思想を全員が理解できている必要があり、「マニュアル」にもそれらを文章化して記載する必要があります。
より卑近な例で言えば、ある作業方法（rule）が採用されるに至った歴史的経緯（principle）がマニュアルに一文でも残っていると、その作業方法が内在する問題点やよりよくこなす手段を、後からそれを読んだ人が思いつくことができるというのがあります。
principleがちゃんと併記されていれば、現行のruleの妥当性を高次の目線で検証できるようになります。マニュアルの陳腐化を防ぐためには、その作業フローの本質部分をドキュメント化することによって、マニュアルを不要とするほどに読み手を成長させることこそが本質的であるように思います。
３．methodologyとmethod
マニュアルを理解するためのもう一つの軸として、methodology（方法論）とmethod（方法）の区別を導入したいと思います。これは、組織の規律の問題というよりは、組織のノウハウの問題にフォーカスしています。
methodとは、日々の作業における手順であり、methodologyとは、目的に合わせてどのmethodを利用すべきかを体系化したものです。
たとえば、コミュニケーション方法としてslackと電話があったとすると、slackと電話はmethodですが、コミュニケーションツールとして電話とslackどちらが適切かを判断するのはmethodologyです（同期的にQ&Aが多数発生しそうで、かつ双方が同時に時間を取れるなら電話の方が効率的なことが多い、みたいな方法論がありそうです）。すなわち、適切なmethodの選択は、methodologyから演繹されるものです。
マニュアルを漏れのないように丁寧に書こうとすると、methodをすべて書きがちです。上記の例で言えば、当事者が具体の状況で採用できるコミュニケーションツールはslackと電話に限られないわけですが（GitHub issueとかPull RequestとかZoomとかメールとか口頭での会話とか無限にある）、方法についてすべて書く必要はほとんどの場合ありません。具体の状況において、その場その場で適切な手段が選択さえできればいいわけです。
読み手が応用できない抽象度の低いルールや、些末な具体的手法は、多くの場合methodologyさえインストールされていれば自然と思いつくものが多く、特定の状況に依存したmethodを書き連ねることは読み手の思考を狭めることになります。とりわけ頭脳労働に関するマニュアル（本当はすべての仕事に言えることだと思っていますが）は、未知のmethodに対して開かれていることが重要であるように思います。
跋
マニュアルは組織の思考を整序するツールとして非常に有用ですが、思考の幅を狭める要素もあるなと思うようになってきました。何より重要なのは日々生起する新しい問題に対し、ゼロベースで自分の頭で思考することだと思っていますが、「methodが書かれていないからやりませんでした」とか、「（既に陳腐化しているのに）ruleに書かれていたからやりました」みたいなことは大抵行き過ぎたマニュアル主義による思考放棄が原因で発生します。そういうのをマニュアル自体の工夫によってなんとかできないか、というのが本稿の主題でした。
上記の思考過程では憲法・行政法の考え方が参考になりました。法律を勉強するといいことがあるぞ。
本稿はMNTSQ株式会社の勤務時間中に書かれました。自分の頭で考えて仕事をしたい人はぜひご連絡ください。
この記事が気に入ったらサポートをしてみませんか？