総ページ数1,000ページ超のマニュアルWeb化事例ーStoryblok移行で得た“CMS選定前にやるべきこと”

1. プロジェクト概要

まず、今回ご紹介するプロジェクトの全体像をお伝えします。

弊社が担当したのは、あるIT企業のマニュアルのWeb化プロジェクトです。10〜15社が参加した競合選定を経て受注し、設計からStoryblokへの移行、執筆支援までを一気通貫で担当しました。

このプロジェクトには、Web化を検討している多くの企業に共通する課題が凝縮されています。最初に、その課題の全体像を整理します。

1-1. クライアントが抱えていた課題

移行対象となるドキュメントは、操作マニュアルとAPIリファレンスあわせて約40ファイル、数1,000ページに及びました。管理担当者は大勢いましたが、「どのファイルが最新版か」を把握しているのは担当者一人だけで、全体像を誰も把握できていない状態でした。

エンドユーザーはWordをPDFに変換したファイルをダウンロードして使っていましたが、複数ファイルをまたいだ検索はできません。必要な情報がどのファイルに載っているかわからないため、当たりを付けてダウンロードしてみる必要がありました。

1-2. 課題の本質：「わかりにくい」ではなく「自己解決できない」状態

このプロジェクトの出発点にあった課題は「マニュアルがわかりにくい」ではなく、「そもそもマニュアルを使って問題を自己解決できる状態になっていない」でした。つまりエンドユーザーがマニュアルを探しても答えが見つからない、そのためマニュアルが整備されているにも関わらず、問いあわせが絶えないという状態でした。

※この課題の背景にある『なぜWordマニュアルをWeb化すべきか』については、別記事で詳しく解説しています。

>Webマニュアル作成の方法とは？Wordマニュアルから移行する手順とおすすめツールを解説

本記事では、実プロジェクトの具体的なプロセスと判断に絞って紹介します。

2. そもそも「Storyblok」とは？

本題に入る前に、本記事で何度も登場する「Storyblok」について簡単にご紹介します。すでにご存じの方は、次の章「3. 着手してすぐ見えた、Web移行を阻むもの」へお進みください。

2-1. ヘッドレスCMSの基本

CMS（Content Management System）とは、Webサイトのコンテンツを専門的な技術知識がなくても作成・編集・公開・管理できるシステムの総称で、いくつかのタイプに分類されます。「ヘッドレスCMS」は、コンテンツの管理画面と表示デザインが分離された構造を持つCMSです。

表示側（フロントエンド）の実装は別途行いますが、コンテンツ自体はCMS側で一元管理できます。

2-2. Storyblokとは

StoryblokはヘッドレスCMSの一種で、「ブロック」という単位でコンテンツを管理できます。マニュアルのような階層構造を持つドキュメントとの相性が良いシステムです。

※Storyblokについて詳細を知りたい方は、以下のブログをご覧ください。

>高機能ヘッドレスCMS「Storyblok」の特徴 | Jamstackブログ | 株式会社ヒューマンサイエンス

3. 着手してすぐ見えた、Web移行を阻むもの

プロジェクトの最初に弊社が行ったのは、既存のWordファイルの内容を把握することです。この段階で、全体的に「注意」や「補足」などの要素の使い方がバラバラであることが見えてきました。ここでは、主な3つの問題と、それらを抱えたままWeb化してはいけない理由をお伝えします。

3-1. 「注意」と「補足」の使い方がバラバラ

注意書きと補足情報の区別がついていない状態でした。あるファイルでは「※注意」と本文中に埋め込まれている一方、別のファイルでは太字で「【補足】」と記載されています。形式が統一されていないだけでなく、内容の重要度も担当者によってまちまちでした。ユーザーから見て、それが操作上の重要な注意なのか、参考として補足された情報なのかを一目で判断できない状態になっていました。

3-2. 手入力による見出し番号の崩壊

Wordに備わっているアウトラインやスタイル機能が活用されておらず、「1.1.1」などの項番が手入力で付けられ、見た目だけを整えているファイルがほとんどでした。また、番号が飛んでいたり、番号自体が振られていなかったりするケースもありました。

3-3. 文体・表記の揺れ

複数の担当者がそれぞれ独自にファイルを管理してきたために、「各用語・表現をどのように記載するか」というルールが文書化されておらず、統一されないままマニュアルが作成されていました。マニュアルの文体や表記の揺れ（「クリックする」と「クリックします」が混在するなど）も、その延長として生じていました。

3-4. なぜこの状態のままWeb化してはいけないのか

このような問題がある状態で、CMSの構成要素の設計を進めることはできません。強引にCMS移行を進めても、マニュアルの見た目は整いますが、ユーザーが感じる「わかりにくさ」の根本は、上記の問題を解決しないことには変わらないからです。

4. ヒューマンサイエンスのアプローチ：CMS構築よりも「要素の分類と定義」

弊社では、CMSへの移行プロジェクトを進める際、CMSの構築前に「このマニュアルはどんな要素から成り立っているか」を整理する工程を設けています。一見遠回りですが、結果的にこの工程があるからこそ、CMSのブロック設計が無駄なく進み、執筆フェーズでの迷いを最小化できます。

ここでは、要素定義からStoryblokのブロック設計につなげた具体例をご紹介します。

4-1. マニュアル要素の洗い出し

既存のWordファイルを解読し、マニュアルを構成するすべての要素を列挙します。本文テキスト・手順ステップ・画像・表・注意（操作上の警告）・補足（参考情報）・注釈・コード表示——これらを個別に定義し、それぞれをどう扱うかのルールを決めます。

たとえば、このプロジェクトでは「注意」と「補足」を以下のように定義しました。

注意
定義：操作を誤ると、データの損失やエラーが発生する可能性がある場合に使用する
スタイル：オレンジ系のNote

補足
定義：必須ではないが、理解を助ける参考情報として使用する
スタイル：グレー系のNote

このルールをドキュメント化し、執筆担当者が「これは注意か補足か」を迷わずに判断できる基準を作りました。

4-2. Storyblokブロック要素とのマッピング

洗い出したマニュアルの要素を、Storyblokのブロックに対応させます。今回のプロジェクトでは、以下のような対応関係でブロックを設計しました。

補足と注意書きを一つの「ノートブロック」にまとめ、種類を属性で切り替えるという設計は、マニュアルの要素を先に定義していたからこそ考えられたことです。要素の定義がない状態でブロックを設計すると、後から「この要素に対応するブロックがない」という問題が顕在化し、ブロックの作り直しや構造の変更という手戻りが発生します。

5. プロジェクトで直面した2つの想定外と解決策

入念に要素整理を行っても、実際のプロジェクトでは必ず想定外が発生します。重要なのは、想定外をゼロにすることではなく、早期に発見して軌道修正できる体制を整えておくことです。

今回のプロジェクトでも、着手後にいくつかの想定外に直面しました。ここでは、特に影響の大きかった2つの想定外と、私たちがどう解決したかをお伝えします。

5-1. 表が予想を超えた工数要因に

マニュアルの要素を整理する段階で、私たちは表の扱いをやや軽く見ていました。

「表は表として移行すればよい」と考えていたのですが、実際にすべてのファイルを精査してみると、表の量と複雑さは想定を大きく超えていました。特に問題になったのは、次のような複雑な表です。

・セルを結合した表
・特定のセルだけ左寄せにしてある表
・ヘッダーが入れ子になっている表

このような表は、Storyblokの標準テーブル機能では表現できません。これはStoryblokに限った話ではなく、多くのCMSに共通する制約です。CMSの標準機能は「シンプルな表」を想定して作られているため、Wordで作り込まれた複雑な表をそのまま再現できないケースが多いのです。

そこで方針を変更し、複雑な表はHTMLで記述してブロックに読み込む形式を採用することにしました。これにより、標準機能では再現できないレイアウトも自由に表現できるようになります。

ただし、ここでもう一つ想定外がありました。ExcelのデータをそのままHTMLに変換すると、Excelが独自に付加するスタイル情報が大量に混入してしまうことです。これをそのままWeb化すると、コードが煩雑になり、表示崩れやメンテナンス性の悪化につながります。Webに読み込めるクリーンな状態にするには、相当な手直しが必要でした。

試行錯誤の結果たどり着いたのが、Excel→Word→HTMLという変換手順です。一度Wordを経由することで、余分なコードが取り除かれ、比較的クリーンなHTMLを出力できることがわかりました。完全ではありませんが、作業効率は大幅に改善しました。とはいえ、この手順にも一定の手間がかかるため、「Excelから直接クリーンなHTMLを出力できるツール」を整備すれば、さらに効率化できる余地は残っています。

WordマニュアルをWeb化する際、表は軽視されがちですが、実際には工数を大きく左右する要素のひとつです。表の多いプロジェクトほど、早い段階でHTML化の方針とUX要件を決めておくことが重要です。

5-2. 見出しの自動採番がない

もう一つ、着手前に想定できていなかったことがあります。見出しの自動採番です。

マニュアルには「第1章」「1.1」「1.1.1」のような番号が必要です。Wordでは「アウトライン番号」として標準機能に含まれており、普段使い慣れていると意識しないほど当たり前の機能です。しかし、Storyblokにはこの自動採番機能が標準で備わっていませんでした。

仮にこのまま進めていたら、執筆者が一つひとつ手入力で番号を振ることになります。それでは、Word時代に起きていた番号の抜けや飛びといった問題が再発するのは目に見えていました。せっかくWeb化するのに、運用負荷が下がらないどころか、むしろ悪化してしまいます。

そこで、開発チームに、ブロックの並び順を読み取って自動的に番号を付与するプログラムの開発を依頼しました。これにより、執筆者が番号を手入力する必要がなく、ブロックを並べれば自動的に番号が振られるようになりました。途中で章を追加しても、後続の番号が自動で繰り下がります。

このギャップに気づけたのは、マニュアルの要素の定義段階で「章・節・項の3階層に自動で番号を振る必要がある」と整理していたからでした。逆に言えば、この整理をしていなければ、ブロックをある程度組み上げた後になって「番号が付かない」という問題が発覚し、大きな手戻りが発生していたはずです。

Wordでは「あって当たり前」の機能が、CMSには存在しないケースがあります。移行前に「現在のWordでどんな機能を使っているか」を棚卸ししておくことで、こうした追加開発の必要性を早期に把握できます。

6. 設計が固まれば、執筆は「当てはめる」だけ

マニュアルの要素の定義とブロックの構築が完了した後の執筆作業は、想定以上にスムーズでした。

執筆者が行うのは「チャプターブロックを並べ、セクションブロックを配置し、その中に本文・画像・表・注釈を適切なブロックで入れていく」という作業です。デザインや構造を都度考える必要がなく、コンテンツの記述に集中できます。「これは注意か補足か」という判断も、マニュアルの要素を定義する段階でルールが決まっているので、迷うことがありません。

今回のプロジェクトでは、執筆段階で構造やマニュアルの要素の扱いに迷うことがほとんどありませんでした。構造が固まっていれば、あとはそのパターンに当てはめていくだけになります。複数人が関わる大規模なマニュアル制作ほど、「迷う余地がない状態」を事前に作ることが品質の均一化につながります。

7. なぜ10社以上の比較から弊社が選ばれたか

ここまで、プロジェクトの進め方や具体的な工夫をお伝えしてきましたが、少し視点を変えて「なぜこのプロジェクトを弊社に任せていただけたのか」をお話しします。これからマニュアル制作会社の選定を控えている方にとって、「どのような観点でパートナーを見極めるべきか」の参考になれば幸いです。

7-1. クライアントの選定プロセス

今回のクライアントは、10〜15社への資料請求から始め、5社に提案を依頼するという段階的な選定プロセスを採用していました。初めての外部委託ということもあり、依頼先の選定には慎重を期していました。

最も重視されたのは、「Webデザインの品質」ではなく「マニュアルの内容の質（わかりやすさ・構成）」だそうです。デザインの見栄えよりも、ドキュメントとして機能するかどうかが問われていました。つまり、Webデザインが得意な制作会社ではなく、マニュアルの中身を改善できる会社を探していたということです。

7-2. 評価された3つのポイント

弊社の提案に対しては、以下のフィードバックをいただきました。

・課題の指摘が的確だった
・ここまでモダンなWeb化を提案してきた会社はなかった
・Storyblokの管理画面の使用感が良さそうだった

また、APIリファレンスを含む大規模マニュアルの制作経験を持っていたことも理由の一つとのことでした。

弊社としては、「既存マニュアルの課題をどう診断し、何を変えるか」という提案内容を高く評価いただいたものと考えています。

7-3. 「CMSに詳しい」だけでは足りない理由

このプロジェクトを通じて強く感じたのは、「CMSの仕様に詳しいだけでは、クライアントの要望に応えきれない」ということでした。既存のWordマニュアルを読み、どこでユーザーが迷うのか、どの表現にバラつきがあるのかを見抜けないと、Web化しても使いやすいマニュアルにはなりません。

8. マニュアルのWeb化を検討している方へ：着手前のセルフチェックリスト

ここまでの内容を踏まえ、WordマニュアルのWeb化を検討している方に向けて、CMSの選定より先に確認すべき点を整理します。

8-1. 補助情報の定義

・「注意」「補足」「注釈」などの補助情報の種類と使い方が、担当者間で統一されているか

8-2. 見出しの構造・番号管理

・見出しの階層（章・節・項）は一貫しているか※ファイルごとにバラバラな場合、移行前の整理が必要になります。
・見出し番号は手入力か、Wordのアウトライン機能で管理しているか※手入力の場合、番号の抜けや矛盾が潜んでいることが多いです。

8-3. 表の複雑さ

・セルの結合がある表はどのくらいあるか
・セルごとに文字寄せや書式が異なる表があるか

表が多いと、Web化の工数は想定より大きくなりやすいです。早い段階でHTML化の方針を決めておくことが重要です。

8-4. WordとCMSの機能差

・Wordで使っている機能（自動連番、スタイル、図表番号など）のうち、CMSに標準搭載されていないものは何か

移行前に現状のWordファイルで使っている機能を棚卸しすることで、追加開発が必要な要件を早期に把握できます。

これらを事前に把握しておくだけで、移行にかかる工数の見積もり精度と着手後の手戻りを大幅に減らすことができます。逆に言えば、CMSを選定してから「どんなマニュアルの要素が必要か」を考え始めると、後になってCMSの標準機能に合わせてマニュアルの表現を妥協するか、追加開発で対応するかの二択を迫られることになります。「CMS選定よりもマニュアルの要素の整理が先」というのは、このプロジェクト全体を通じて最も実感した教訓です。

マニュアルのWeb化を検討している場合、まず代表的なWordマニュアルを3〜5冊選び、見出し・本文・手順・注意・補足・表・注釈・コード・画像といった要素を色分けしてみてください。色分けに迷う箇所が多いほど、Web化の前に整理すべき課題が多いということです。外部のマニュアル制作会社に相談する際は、その棚卸しがある程度できた段階で話を持っていくと、外注先での費用見積もりや課題の診断がスムーズになります。

9. マニュアルのWeb化に関するよくある質問

最後に、WordマニュアルのWeb化を検討されているお客様から、私たちが実際によくいただく質問をまとめました。これまでお伝えした内容と重なる部分もありますが、「自社の場合はどうだろう？」と検討を進める際のチェックリストとしてご活用いただけるはずです。

もっと詳しく知りたいと感じた点があれば、お気軽にお問い合わせください。

10. マニュアル作成・改善のご相談はヒューマンサイエンスへ

ヒューマンサイエンスは、日本語版のマニュアル作成から英語翻訳まで、ワンストップでご支援いたします。1985年からの長きにわたり数々のマニュアルを手がけてきた実績があります。以下のようなニーズがございましたら、ぜひお気軽にご相談ください。

・既存の日本語マニュアルや英語マニュアルを分かりやすく改善したい
・英語マニュアルの作成を検討していて、日本語マニュアルから段階的に進めたい
・社内で作成された日本語マニュアルを英訳して活用したい

特長①：大企業・グローバル企業を中心とした豊富なマニュアル制作実績

ヒューマンサイエンスは、製造業やIT業界を中心に、多岐にわたる分野でマニュアル制作実績を積み重ねてきました。これまでに「ドコモ・テクノロジ株式会社」「ヤフー株式会社」「ヤマハ株式会社」など、名だたる企業をクライアントとしてきました。

マニュアル制作事例紹介| ヒューマンサイエンス

特長②：経験豊富なコンサルタントによる調査・分析からアウトプットまで

業務マニュアル作成に携わるのは、ヒューマンサイエンスが誇る経験豊富なコンサルタントになります。熟練のコンサルタントが、豊富な経験と提供された資料から、より分かりやすく効果的なマニュアルを提案します。また、情報が整理されていない段階からのマニュアル作成も可能です。担当のコンサルタントがヒアリングを行い、最適なマニュアルを作成いたします。

マニュアル評価・分析・改善提案サービス| ヒューマンサイエンス

特長③：マニュアル化だけでなく、定着支援も重視

ヒューマンサイエンスは、マニュアル作成にとどまらず、”定着化”という重要な段階にも注力しております。マニュアル作成後も、定期的な更新やマニュアル作成セミナーを通じて、マニュアルの定着を支援してまいります。多岐にわたる施策により、現場でのマニュアルの有効活用をサポートいたします。

マニュアル作成セミナー| ヒューマンサイエンス

最後までお読みいただき、ありがとうございました。このブログがわかりやすいマニュアル作成のヒントになれば、うれしく思います。