サイトのリニューアルが終わり、納品物一式を受け取った。その中に80ページの「運用マニュアル」がある。半年後、お知らせを1本追加しようとした担当者は、そのPDFを開いて数分スクロールし、閉じて、制作会社にメールを送る。「お知らせの追加をお願いしたいのですが」
ドキュメントが無いわけではありません。むしろ立派なものが納品されています。それでも使われない。この状態は、書き手の手抜きでも読み手の怠慢でもなく、設計の問題です。
1冊の中に、目的の違う4種類が混ざっている
技術文書の設計には、Diátaxis（ダイアタクシス）という考え方があります。ドキュメントをチュートリアル・ハウツーガイド・リファレンス・説明の4種類に分け、混ぜないことを原則にするものです。
それぞれの役割はこう分かれます。
| 種類 | 誰が、いつ読むか | 中身 |
|---|---|---|
| チュートリアル | 初めて触る人が、覚えるために | 手順どおりにやれば一度は成功する体験 |
| ハウツーガイド | 業務中の人が、目的を果たすために | 「お知らせを追加する」など、目的別の手順 |
| リファレンス | 確認したい人が、正確さのために | 設定値・項目名・仕様の一覧 |
| 説明 | 判断したい人が、理解のために | なぜそうなっているのかの背景 |
冒頭の80ページのマニュアルは、この4つが順不同で混ざっています。CMSの管理画面の全項目を並べたリファレンスの間に、初回セットアップのチュートリアルが挟まり、その後ろに設計思想の解説が続く。
お知らせを1本足したいだけの担当者が必要としているのは、この中のハウツーガイド1ページだけです。 それが80ページのどこにあるか分からないから、探すより電話したほうが早い。使われない理由はこれ以上でも以下でもありません。
逆に、4つを分けて納品すると変わります。「よくやる操作」だけを集めた薄い冊子が別にあれば、担当者はそこを開きます。全項目の一覧が必要になるのは、通常業務ではなく調査のときだけです。
発注時に指定するのは「ページ数」ではない
見積もりの段階で「マニュアル一式」と書かれていると、たいていは分量の話になります。何ページ相当か、画面キャプチャは何点か。ここを詰めても、使われるかどうかは変わりません。
指定すべきなのは、日常業務でやることを名指しして、その手順書を独立した形で求めることです。たとえばコーポレートサイトなら、次のようなものがそれにあたります。
- お知らせ・ブログ記事を1本追加する
- 既存ページの文章と画像を差し替える
- 問い合わせフォームの送信先アドレスを変える
- 社員紹介ページに1名追加する
このリストは発注側にしか作れません。制作会社は、その会社が何を頻繁に更新するのかを知らないからです。 逆に言えば、このリストを渡せば、それに対応するハウツーガイドを作ってもらえます。
そして検収では、その手順書を見ながら社内の担当者が実際に1回やってみるところまでを条件にします。読んで分かった気になるのと、手を動かして完了するのは別です。詰まった箇所があれば、それが手順書の欠落です。この検収を入れると、納品されるドキュメントの質は目に見えて変わります。
リファレンスと説明は、別の場面で効く
日常業務にはハウツーガイドがあれば足ります。では残り2つは要らないかというと、要る場面が明確にあります。
リファレンスが効くのは、担当者が代わったときと、別の会社に頼むときです。 設定値の一覧、使っているサービスとその用途、ドメインやアカウントの管理情報。これらは普段誰も見ませんが、無いと引き継ぎが止まります。制作会社を変える判断をしたときに、この一覧が無いために移行そのものを諦める——という形で表面化します。この構造は開発会社と連絡が取れなくなったときに何が起きるかで扱いました。
説明が効くのは、何かを変えようとしたときです。 「この機能はなぜこういう作りになっているのか」が書かれていないと、後から手を入れる人は既存の判断を全部やり直すことになります。数年後にリニューアルを検討する際、前回の設計意図が分かるかどうかで、調査にかかる時間が変わります。
つまり4つは、読まれる時期がそれぞれ違います。 ハウツーは納品直後から毎月、リファレンスは担当交代のとき、説明は数年後。1冊にまとめると、この時間差が無視されます。
「ドキュメントがある」と「更新されている」は別
もう1つ、発注時に決めておくと後で効くことがあります。ドキュメントを誰が更新するかです。
サイトは公開後も変わります。ページが増え、機能が追加され、外部サービスが差し替わる。そのたびに手順書は古くなります。半年後に「書いてあるとおりの画面が出てこない」となれば、そのドキュメントはその時点で捨てられます。
保守契約を結ぶ場合は、改修時に関連するドキュメントも更新することを作業範囲に入れておいてください。ここが曖昧だと、更新は誰の仕事でもなくなります。契約に入っていないなら、それは発注側が自分で更新する前提だということです。どちらでも構いませんが、決めていない状態がいちばん悪い結果になります。
放置されたサイトが何を招くかはサイトを放置するリスクに、保守費用の内訳の見方は業務システムの保守費用にまとめています。
次の発注のとき、1枚だけ用意する
これから制作や開発を発注する予定があるなら、見積もりを依頼する前にA4で1枚のリストを作ってください。
内容は「公開後、自社の担当者が自分でやりたい操作」の箇条書きです。10行もあれば足ります。多くの会社で、実際に頻繁にやる操作はその程度に収まります。
このリストを見積もり依頼に添えると、2つのことが起きます。ひとつは、その操作に対応した手順書が納品物に入ります。もうひとつは、そもそも担当者が自分でできる作りになっているかが、設計の段階で検討されます。「お知らせを自分で追加したい」が最初に伝わっていれば、それができる管理画面になります。伝えていなければ、そうならないこともあります。
ドキュメントの話に見えて、実際には公開後に自走できるかどうかの話です。だから発注前に決めるだけの価値があります。
サイトのリニューアルや新規制作にあたって、公開後に社内で回せる形まで含めて設計したい、既存サイトの引き継ぎ資料が実用に耐えるか見てほしい——そうしたご相談は、グリームハブのHP制作・リニューアル相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
