マニュアルづくりの振り返り

昨日、ずっとタスクとして抱えていた、あるWebメディアの運用マニュアルを、ようやくひととおり書き終わりました。前の会社でも、今やってる仕事でも、業務として「マニュアルづくり」をけっこうやります。

マニュアル作成って、取材記事の執筆でもコラムや批評の執筆でもない、クリエイティブであることがあまり必要ないイメージのある業務ですが、けっこう大事なことだと思っています。

そこで今回、マニュアルづくりの振り返りを書いてみようと思います。

マニュアルづくりの意味

マニュアルづくりをしておくメリットを改めて言語化したいのですが、要は人にやり方をレクチャーする時間をある程度、減らすことができます。フロー化できる業務はフロー化してしまって、自分の時間は企画とかモチベーション管理とか、そういうことに使いたい。そのためにマニュアルづくりがあると考えています。

あとは「属人化を避けたい」ということがあります。「結局、中野に任せときゃいいや」となると、自分に無限に業務が降ってきてしまいます。自分がすでにできることは、それが繰り返しになってくると、だんだんきつくなってきてしまいます。それよりは、他の人にできるようになってもらうほうが、達成感を他者とシェアできるので、それもメリットではあると思うのです。

取材記事のライティングとの違い

取材記事やコラム／エッセイの執筆と、マニュアルの作成は、「ライティング」という意味では似ているように思えます。

ただ、マニュアルのほうはどちらかというとプログラミングに近いので、難易度が高い部分があると思います。

プログラミングはたとえば「この分岐が来たらこう処理する」みたいな想定が必要になるわけで、最短時間で処理できるルートは何なのか、マシンにもっとも負荷がかからないやり方は何か、といったシミュレーションが必要になります（ちなみに「人」「マシン」と言ったときに僕のなかでこの２つに価値の序列をつけているわけではありません）。

そのマニュアルを見た人にこういうふうに作業してもらう、という想定ができていなければならず、その情報をどこから取ってくるかというと、机上で考えているだけでは当然ダメで、実際の業務経験のボリュームが必要です。

で、その業務経験の時間数じたいは何千時間とあるので、マニュアルづくりの際には、その情報を自分の脳内で抽象化して処理して、最短ルートを計算する、みたいなことをしていると思います。

なので、同じ２万字でも、インタビュー記事の構成を２万字分やるのと、マニュアルを２万字分執筆するというのでは、脳への負荷のかかり方が全然違うのではないかと思います。

オーラル・ヒストリーと「厚い記述」

ちなみにインタビュー記事のようなテクストの場合は、アカデミック・ライティングの分野では「厚い記述」（アメリカの文化人類学者ギアーツが提唱した概念）とも言ったりしますが、必ずしもコンパクトな記述がよいというわけではありません。ここのところはビジネス畑の人や、あと新聞社で記者のトレーニングを受けた人だったりが、頭にない観点ではないかと思います。

インタビュー記事は、これも学術的な概念で言い換えればいわゆる「オーラル・ヒストリー」なわけです。で、オーラル・ヒストリーを語る場合、ボリュームが大きいことそのものが意味を持つことが、かなりあります。

つまり、「コンパクトであれ」と言ってしまうときに経路づけられる恣意的な取捨選択や抽象化が、マイナスの方向に働く場合があるわけです。このあたりは、いま注目が高まっている「当事者研究」とも関連のある話だと思います。当事者研究は、恣意的な抽象化への批判から生まれていて、「rawであること」「個別性」が重要だとされます。

プログラミング思考と箇条書き

一方、マニュアルの場合は「厚い記述」をある程度まで脳内で前提化した上で、それを徹底的に抽象化し、コンパクトな記述に落とし込まなければなりません。しばしばエンジニア出身の人は「箇条書き」を好むわけですが、これは何もサボっているわけではなく、箇条書きというのはプログラミング的な思考の表出だと思います。

僕もマニュアルを作成する際は、箇条書きをけっこう使います。地の文よりも、箇条書きになっていたほうがチェックリストとして脳内処理しやすいからです。つまり、マニュアルは地の文で書きすぎず、必要なところでは箇条書きをうまく活用することが必要だと思います。

マニュアル執筆のノウハウ開発に関するあれこれ

なんでこんなことを書いているかというと、やはりインタビュー記事の執筆や、自分で書くエッセイ／コラム的なテクストの執筆よりも、マニュアル執筆のほうがはるかに時間がかかってしまうからです。でも、マニュアル的なテクストがきちんと世の中に流通していると、人間はよりクリエイティブな活動に時間を使うことができる。だから言語化したい、やり方をある程度はパターン化したい。

ちなみに、「マニュアルは直感的で、ビジュアルなものを」とかも、実はちょっと違うと思うのです。デザインの力も当然必要ですが、デザイン過剰だと「それっぽさ」だけが出てしまい、実効的な力を持たないケースが往々にしてある、ということをしばしば目撃しました。

いわゆるグラレコ（グラフィック・レコーディング＝イラストや図表を使って議論をまとめる手法）も、必要な場面では必要だとは思いつつ、「絵が描きたいだけでは？」「うまいって言われたいだけですよね？」と思ってしまうことがけっこう多いです。本質的でない部分も大いにあるなと。

それこそグラレコって、「厚い記述」と真反対にある考え方で、当事者研究的な視角からいえば「不誠実の極み」とすら言えますからね。「まとめる側」の権力性に超絶的に無自覚なわけですから。フーコーが一般常識になっていないことの弊害がすごいあるなと思います。

マニュアルは「作って終わり」ではない

これも過去の経験から思うことですが、マニュアルを含むレギュレーションって、いわゆる「ウォーターフォール」モデルではなくて「アジャイル」でなければならないと思うのです。というか現時点で、ウォーターフォール的な感覚が染み付いたまま仕事をすることほどヤバいことはないと思っていて。

会社員を辞めてフリーランスになって感じたメリットのひとつが、常にアジャイルでいられるということです。ウォーターフォールモデルは工数管理などのサラリーマン的、というかワークライフバランス的な要請から生まれたものではあると思うんですよね。もちろんその必要性はよくわかります。

ただ、僕の感覚では、ウォーターフォールにはアウトプット面でのいいところは特になく、良い仕事をするには徹底的なアジャイル化が必要だと思います。で、「あ、この人ウォーターフォールだな」と思う人に出会ったら、その瞬間に局面転換を働きかけなければいけない、と思うのです。

で、マニュアルを作る仕事をたくさんやって思ったのは、

• マニュアルは不断の改訂が必要
• マニュアルの周知徹底のための繰り返しの広報が必要

ということです。まあ、こんなのは言われれば当たり前のことではあるのですが、意外とそこをきっちりやらない人が95%だ、ということがわかりました。なので、ここをやるだけで価値が出るなと思います。

マニュアルは属人化を避けるためのものなのですが、随時のアップデートと広報は、ここだけは誰か一人の人間＝具体的にはマニュアル作成者が属人的に、強烈にグリップしなければいけないと思います。

というわけで、今回も仕事の振り返りを書いてみました。意識が高まっているので言語化しようと思い、一気に書きました。