手作業のPDF化から配布の自動化へ

人が読み、管理し続けられる形で原稿を残す

当社では、多くの文書をMarkdown形式で作成しています。
Markdownは、見出しや箇条書きを簡単な記号で書き表すテキスト形式です。
テキストなので、Git（変更履歴を管理するツール）で、いつ誰がどこを変えたかを記録できます。
レビューする側も、前回からどこが変わったのかを差分で確認できます。

最近では、AIに文書を書かせたり、管理まで任せたりすることも珍しくありません。
AIにHTMLで資料を作らせると見やすい、という声も聞くようになりました。

それでも、任せきりにしてはいけない部分があります。
書かれた内容を人が読み、どこが変わったのかを確かめることです。
HTMLは見た目を整えやすい一方で、原稿にすると、変更の前後を見比べにくくなります。
見比べにくいと、人は次第に見なくなり、管理や確認がおろそかになってしまいます。

当社がMarkdownで原稿を書き続けているのは、人が変更を追い続けられるようにするためです。

同じPDFを、最初に作った人しか作れなかった

ただし、人が管理しやすい形と、読み手へ届けやすい形は別のものです。
顧客へ提出する文書は、内容が正しいだけでなく、読みやすく整える必要があります。
Markdownのファイルや、それを表示しただけの画面を、そのまま提出物として扱うことはできません。

当社でも以前はこの二つの間を人の手でつないでいました。
営業やディレクターがエンジニアからMarkdownを受け取り、内容に誤りがないかを確認した後、提出用の形式へ作り直します。
PowerPointへ内容を移す人もいれば、CSS（文書の見た目を定義するファイル）を自分で用意し、PDFを作る人もいました。

提出した後に仕様が変わり、エンジニアがMarkdownを更新すると、この作り直しがもう一度発生します。
余計な作業が入り、最新の内容をすぐには届けられません。

変換の手順とCSSは、作った人がそれぞれ持っているだけです。
別の人が同じ文書をPDFにすると、内容の変更がわずかでも、見た目が大きく変わってしまいます。
そのため、手順書を数行修正しただけでも、最初にそのPDFを作った人へ作り直しを頼んでいました。
PDFの作り直しを頼める相手が、文書ごとに1人に決まっていたことになります。

Markdownで原稿を管理すること自体に問題はありませんでした。
問題は、更新のたびに作り直しが必要で、しかもその作り直しを、最初に作った本人にしか頼めなかったことです。

同じPDFを作れることに絞って、小さく始めた

最初の段階では、この問題だけに取り組みました。
MarkdownをPDFへ変換できること。
誰が実行しても同じ見た目のPDFになること。
求めたのは、この二つです。

まず、個人がそれぞれ持っていた変換の手順とCSSを一つにまとめ、それをコマンドラインツール（文字のコマンドを入力して動かすプログラム）にしました。
ツールはGitLab（ソースコードや文書を管理する社内のシステム）で管理し、各自の端末へダウンロードすれば、誰でも同じことができるようにしました。

最初からすべてをそろえず、小さく作って使い始める。
いわゆるスモールスタートです。

これで、PDFの作り直しを頼む相手は、最初に作った人でなくてもよくなりました。
コマンドラインを使える人なら、誰に頼んでも同じPDFが返ってくるからです。
1人に集中していた依頼を、複数の人へ分けられるようになりました。

確認した人が、そのままPDFを作る

コマンドラインツールは、自分では操作しない営業やディレクターからも好評でした。
自分たちも使えるように広げてほしい、という要望も出ました。
営業やディレクターは、Markdownの内容を確認した後、PDFにするために誰かへ頼む必要があったからです。

数か月後、次はコマンドを使わなくてもブラウザからPDFを作れるWebアプリを作りました。
Markdownを貼り付けると変換後の見た目をその場で確認でき、表紙や目次などの設定も同じ画面で済みます。
エンジニアから受け取ったMarkdownを確認し、貼り付けて数回操作すれば、PDFが完成します。
Markdownが更新されても、その場ですぐに作り直せます。

公開した後には、GitLab上と同じ表現で図や絵文字を出したいといった要望を受け、扱える記法を増やしてきました。

対象にしているのは、技術調査の報告書、顧客向けの手順書、概要説明のように、文章が中心となる文書です。
提案時のプレゼンテーションなど、PowerPointが適している場面では別の方法を使っています。

PDFにするための依頼は、ここでなくなりました。
内容に誤りがないかを確認する仕事は、営業やディレクターの手元に残しています。

PDFを作る部品を、そのまま社内文書の配布にも使えた

顧客向けの文書のために作ったWebアプリは、社内文書にも役立ちました。

当社では、エンジニアと非エンジニアの双方が読む社内文書を、Google Drive上のPDFで配布しています。
元になるMarkdownは、GitLab上の社内共有リポジトリ（ファイルと変更履歴の保管場所）で管理しています。
Markdownを更新するたびに、担当者がWebアプリでPDFを作り、Google Driveの所定の場所へ置くようになりました。

ここにも、人の手作業が残っていました。
PDFへの変換も、Google Driveへ置く操作も、手順が決まっており、その都度人が判断することはありません。
それでも人の操作である以上、元のMarkdownだけを直して配布用PDFの更新を忘れれば、読み手は古い情報を参照してしまいます。

そこで、この操作を自動化することにしました。
必要なものは、すでにそろっていました。
当社は開発会社として、機能を独立した部品に分けて作ることを基本にしています。
PDFを生成する処理も、操作画面から切り離し、ほかのシステムから呼び出せる形（API）にしてありました。

GitLabには、変更をきっかけに決まった処理を自動で実行する、CIという機能があります。
足したのは、このCIからAPIを呼び、できたPDFをGoogle Driveへ置く連携だけです。
組み込んだその日のうちに運用を始めました。

担当者がMarkdownを更新すると、CIがPDFを作り直し、Google Drive上のPDFを新しいものに置き換えます。

この連携により、Markdownの更新から配布用PDFの更新までが一つの処理になりました。

更新漏れをなくし、内容の確認は人に残した

現在は、更新を社内へ確実に届けたい周知文書のいくつかを、自動配布の対象にしています。
すべての社内文書を自動化した事例ではありません。

対象の文書では、自動化してから更新漏れがなくなりました。
文書を更新する担当者も、更新が億劫でなくなったと話しています。

振り返ると、PDFにする作業を担う人は段階ごとに変わりました。
最初に作った1人から、コマンドラインを使える人へ。
次に、内容を確認した本人へ。
社内文書では、人の操作そのものが不要になりました。
一方で、内容の確認は、どの段階でも人の仕事として残しています。

おわりに

文書業務を改善するとき、変換ツールの選定だけでは解決できないことがあります。
誰が内容を作り、誰が確認し、どの形式で原稿を管理するのか。
読み手へはどの形式で届け、原稿を更新した後に何を行うのか。
工程を順に確認すると、人が判断すべき箇所と、決まった手順を繰り返している箇所を分けられます。

原稿は人が変更を追える形にしておき、どこに人の作業を残すかを先に決めておく。
AIに任せられる作業が増えるほど、この順序が大切になります。

今回の事例では、一度にすべてを解決しようとはしませんでした。
課題を一つずつ切り出し、その段階で必要な範囲だけを作りました。
Markdown、GitLab、Google Driveという既存の仕組みは、そのまま残しています。

特定の人にしか頼めない作業や、同じ情報を別の形式へ移す作業が、文書の作成から配布までのどこかに残っていないか。
その一つから小さく始めれば、既存の運用を生かしながら一段ずつ改善を進められます。