新しいチームにジョインして、それまでとは全然違う仕事を任されたものの、仕事の進め方がわからなくて困ったことはありませんか？

そんな時に、前任者が作成したマニュアルがあると大変心強いものです。マニュアルは自分だけで読み進めることができるので、誰かに質問するのと違って他人の時間を奪いません。また、（業務内容が変化しない限りは）何度でも使いまわせます。マニュアルはチームにとって重要な「資産」です。

もっとも、現実にはこのように理想的な引き継ぎができることばかりではないでしょう。むしろ、マニュアルなどまったく存在せず、自力で業務内容をひも解いていかなければならない場合や、マニュアルは一応あるものの、情報が古すぎて全然役に立たないという場合のほうが、実際には多いのではないでしょうか。

「チームの未来のためにマニュアルをつくろう！」と言うのは簡単ですが、実際にマニュアルを上手に運用するのは簡単なことではありません。今日は、チームにとってよいマニュアルとは何かについて少し考えてみたいと思います。

マニュアルをつくる前にまずは業務を見直す

マニュアル運用の失敗例とはなんでしょう。マニュアルがなくても別にいいような簡単な業務には、充実したマニュアルがあるのに、マニュアルがないと何をしてよいのかわからないような複雑な業務には、マニュアルがないといったことがありえます。

これでは本末転倒なのですが、なぜこんなことが起こるのでしょうか。

理由は非常に単純です。複雑な業務の従事者はいそがしい場合が多く、マニュアルをつくるだけの時間的余裕がないからです。また、複雑な業務のマニュアルをつくるのは、複雑ゆえに多くの時間がかかります。そのこともまた、マニュアルの準備を停滞させている原因です。

これはやっかいな問題です。業務が複雑なままでは、今後もマニュアルがつくられることは期待できません。思うに、問題の根本は複雑な業務が存在していること自体にあります。業務が複雑すぎてマニュアルがつくれないのであれば、マニュアルをつくる以前に業務内容自体を見直すべきでしょう。

たまに勘違いしている人がいますが、「複雑な業務＝高度な仕事」というわけではありません。仕事が複雑すぎるのは、ある意味では仕事の整理を怠った結果だともいえるのです。もちろん、どうやっても複雑になってしまう仕事は存在するでしょうが、多くの仕事は丹念に要素分解していけば、見通しよく整理できます。

業務が複雑すぎてマニュアルをつくるのが大変だと思った時は、マニュアル以前に業務そのものをもっと整理できないか見直しましょう。話はそこからです。

マニュアルづくりに時間をかけすぎてはいけない

マニュアルをつくる際には、あまり時間をかけすぎてはいけません。

マニュアルはあくまでチーム内で使うものですから、顧客に出すもののようにきれいにデザインなどを入れる必要はありません。文章を書くのに時間がかかるなら、箇条書きのようなものでもよいのです。

また、リンクで済むものは極力リンクで済ませるべきです。他所にも書いてあるものを、二重で書くのは時間のムダです（参照先が消えるおそれがある、などであれば別）。たとえば、これはエンジニア限定の話ですが、コードを読めばそれで読み取れるという情報をわざわざ文章にして再記述する必要はありません。マニュアルを書く手間は、少なければ少ないほどよいのです。

まずは自分の作業メモからはじめよう

思うに、「引き継ぎで困らないように、マニュアルを準備しよう」という気持ちで自ら進んで「マニュアルづくり」の時間を確保できる人はまれです。仕事が暇で時間が余っていれば、このようなこともできるかもしれませんが、少しでもいそがしくなるとマニュアルづくりは「あとで時間ができたらやろう」と後回しにされます。もちろん、実際に「あとで」やることはありません。

そうならないためにも、マニュアルは別途時間を確保してつくるのではなく、実際に業務をしながらつくってしまうのがおすすめです。具体的には、「作業メモ」を取りながら仕事を進め、そのメモをそのままマニュアルにしてしまうわけです。このやり方なら、いそがしさに関係なくマニュアルが蓄積されていきます。

これは後任者のためだけでなく、自分のためにもなります。メモという形で自分の業務を整理することで、新しい気づきが得られるかもしれません。

マニュアルの経年劣化にどう対応するか

どんな情報も、時の経過によって古くなっていきます。マニュアルも例外ではありません。業務内容は時々刻々と変化していきますから、マニュアルの情報が古くなって使えなくなる日は必ずやってきます。このようなマニュアルの経年劣化には、どう対応するのがよいのでしょうか。

一番よいのは、業務内容が変わるたびにマニュアルを最新のものにアップデートすることですが、現実には時間がとれずに古いまま放置されることも多いものです。最低限、マニュアルの情報が古くなった部分には「この情報は古い情報です」と注記だけはするようにします。とりあえず「古い」ことさえわかれば、その情報をそのまま使ってしまう事故が防げるからです。

また、放っておくとチーム内のドキュメントは乱雑になっていく傾向があるので、定期的に要らないものは削除するなどして整理ができるとよいでしょう。これは議論が分かれるところですが、古い情報を延々と残しておくのは事故の元なので僕はおすすめしません。

読まれないマニュアルに価値はない

最後に、マニュアルをつくる際には忘れてはならない視点があります。それは「読んでもらえるように書く」ということです。

あたりまえですが、マニュアルには必ず「読者」がいます。自分の作業メモをそのままマニュアルにする場合であっても、読者として未来の自分がいます。デザインや形式にこだわる必要はないものの、最低限読者に通じるような書き方をする気持ちは持たなければなりません。

また、チームのルールやコーディング規約などを「啓蒙」するためにドキュメントをつくる場合は、ただ書くだけでなく「読んでもらうための工夫」を入れると効果的です。たとえば、これは僕が以前働いていたチームでの話ですが、そのチームのコーディング規約が書かれたドキュメントには「くだらない冗談」が大量に含まれていました。これはつまり、飽きずに最後まで読んでもらうための工夫です。

誰にも読まれないマニュアルを書くことは、完全に時間のムダです。あとで読む人がいるから、書く意味があるのです。そのことを忘れてはいけません。

イラスト：マツナガエイコ

SNSシェア

• シェア
• Tweet