こんにちは、ドキュメントグループ所属、マニュアル制作エンジニアの仲田です。
サイボウズでは写経という徳の高すぎるブームが勃発せんとしていますが、私はというと、写経とカテゴライズされる行動を取っただけで、お札を貼られたキョンシーのごとく封印されそうなので、ブログの執筆に勤しんでいます。
先日、会社の映画部で「STAND BY ME ドラえもん」を観てきたのですが、良かったです。ネタバレになるので詳しくは書けませんが、ドラえもんの街が3Dで再現された映像には、それだけでもワクワクさせられます。しずかちゃんは2Dよりも可愛いです。
ただ、大山のぶ代のドラえもんを観て育った私としては、やはり声を受け入れられない感がありました。やはり、大山のぶ代は偉大。
さて、話が変わりますが（ここからが本題）、みなさんはマニュアル制作という仕事をご存知でしょうか？
世の中には星の数ほどマニュアルがあります。その裏には、当然マニュアルを作っている人がいるのですが、マニュアル制作という仕事に関する情報は少ないように感じます。
そこで、今回は、サイボウズ ドキュメントグループの仕事をご紹介します。
ドキュメントグループの主な仕事
ドキュメントグループの活動目的は、ユーザーにサイボウズ製品の使い方を伝えることです。
おもに次の役割を担っています。
- 製品画面の言葉を決める
- 製品のマニュアルを作る
製品画面の言葉を決める
Good design helps to understand a product.（良いデザインは理解をもたらす）とは工業デザイナー ディーター・ラムスの言葉。
Webサービスでは、主に次のデザイン要素があります。
- ビジュアルデザイン
- デザインデザイン
- インタラクションデザイン
- 情報アーキテクチャ
ドキュメントグループは、情報アーキテクチャのうちのラベリング（画面に表示する言葉の決定）を担います。適切なラベルを提示することで、ユーザーは、何をすれば何が起こるのかの予測が可能になります。
もちろん、良いデザインとは、ラベリングだけでなくビジュアルやインタラクションなどの他の予想との組み合わせでできるもの。UIデザイナーなどの他のチームと連携して決定します。
製品のマニュアルを作る
マニュアル制作というと、皆さんはどういったイメージを持ちますか？
愛着を持つ製品があって、それを世に広めたい！と思ったら、書く、という行為は、有効な手段の1つ。マニュアル制作エンジニアにとって、製品への愛着が、活動欲求となっています。
たとえば、私が今メインで担当しているkintone。売上情報、顧客情報や、文書などの、さまざまな業務データを保管するデータベースアプリを、簡単に作れるサービスです。アプリには、データに紐づくワークフロー（業務の流れ）の管理、チーム内の連絡や、データの集計など、さまざまな機能を追加可能。会社ごとに異なる業務の流れに合わせた業務アプリを作成できます。
業務の流れは会社によって千差万別。パッケージ製品では、自分の会社の業務とは合わない。かといって、1から開発するにはお金がかかるし、時間もかかる。kintoneは、そんな背景から開発された製品です。
半分宣伝のようでしたが、使い方次第で多様な業務に応用できるツール。より活用してもらうべく、マニュアル制作エンジニアとして日々あがいています。
マニュアル作りという仕事
さて、ソフトウェアのマニュアルとは、どのような過程で作られるのでしょうか。
マニュアルの制作過程を、順を追ってご紹介します。
- 開発仕様書を熟読
- 自ら製品を使う
- 社内からのフィードバックを基に改善
- ユーザーからのフィードバックを基に改善
開発仕様書を熟読
開発仕様書には、主に
- 製品の開発目的
- 各機能が実現するユーザーシナリオ（その機能があると、ユーザーは何ができるようになるのか）
- 各機能の仕様
- 制限事項（できないこと）
が書かれています。
まずそれらを熟読し、「（開発者視点で）ユーザーに知って欲しいと思うこと」を把握します。
体験なくして表現はない。自ら製品を使う。
次に、開発段階の製品を触っていきます。 ここでは、開発仕様書から得たユーザーシナリオを基に、ユーザーの立場で触ることが肝要。「ユーザーが知りたいと思うこと」を掴みます。自分が疑問に思うことは、きっとユーザーも疑問に思います。
そのほか、製品のユーザビリティテストを実施して、被験者が疑問に感じたことや、躓いた操作を参考にすることもあります。
概して、「（開発者視点で）ユーザーに知って欲しいと思うこと」と「ユーザーが知りたいと思うこと」は一致しません。どちらの把握が欠けても、伝えるべき情報が不足します。
伝える情報を整理
ここまで来たら、ユーザーに伝える情報を整理して、執筆開始。
小説や雑誌と違って、マニュアルを1ページ目から最後まで順に読む人はいません。知っておくべき情報は何か、欲しい情報はどこに書かれているか、を読者が一目で把握できる構成にする必要があります。
また、これも雑誌などと違う点ですが、わくわくしながらマニュアルを読む人は、あまりいませんよね。必要に迫られて読むものです。ですので、説明は、簡潔に、ロジカルに書きます。
このあたりのスキルは、テクニカルライティングと呼ばれるもので、マニュアル制作エンジニアの職能の1つ。
詳細は別の機会に譲りますが、テクニカルライティングとは、テクニカルコミュニケーションの一分野。巷で流行るWikiPedia教条主義に沿うと、「筆記・口述などの方法で特定の聞き手に技術的・実務的（テクニカル）な情報を伝えるプロセス」の筆記版のこと。（参照）
メールでの仕事のやり取りで相手に誤解されてしまった。
ものごとがいまいち正確に伝わらない。
そんなことを感じたことがあれば、テクニカルライティングを学んでみると、いいことがあるかもしれません。ないかもしれません。
社内からのフィードバック
さて、少し話が逸れましたが、マニュアルの執筆が中盤に差し掛かる頃には、開発中の製品が、サイボウズ社内に公開されます。
いわゆるドッグフーディングというもの。開発中の製品を使って社内の業務を実際に回してみて、改善点を探ります。
このドッグフーディングは、マニュアル制作にとっても情報収集の絶好の機会。社内SNS（kintoneの機能の1つ）上のつぶやきなどから、社員が何を疑問に思ったか、どの操作で躓いたか、などを把握します。収集した情報は、マニュアルにフィードバック。
ユーザーからのフィードバック
晴れて公開、一段落！というところですが、そこで終わりというわけにはいきません。ここからは、PDCAのサイクルを通して、マニュアルの質を高めていきます。
製品のサポートチームからは、ユーザーからのお問い合わせや、起こったトラブルを分析したフィードバックがあります。
また、マニュアルサイト内で採るアンケートも、重要なフィードバックの1つ。
アンケートの結果は、kintoneに記録されます。
アンケート結果を集計し、評価の低い記事を抽出。記事の内容に関連するユーザーからのお問い合わせを分析し、記事を改善します。
そのほか、検索キーワードも、「ユーザーが知りたいと思うこと」を把握するのに役立ちます。
検索キーワードと検索後のページ移動の記録から、マニュアルに不足している情報を推測します。たとえば、検索結果からどのページも開かずにマニュアルサイトを閉じる、という行動をユーザーがとったとしたら、その検索キーワードに関連する情報が不足している可能性が高いです。
このように、チェックと改善を繰り返し、マニュアルの質を高め、製品全体のUX改善に繋げます。
アンケートや検索キーワードの分析については、詳しくは別の機会に改めて。
最後に
さて、今回はマニュアル制作エンジニアの仕事をご紹介しましたが、いかがでしたでしょうか？
今回ご紹介した、製品マニュアルの制作以外にも、APIの利用マニュアルや、エンタープライズ向けのシステム構築マニュアルなど、ドキュメントグループでは幅広い仕事を手がけています。
現在、ドキュメントグループではスタッフを募集しています。
興味を持っていただけましたら、是非ご応募ください。
マニュアル制作エンジニア
マニュアルや製品画面を英語圏にローカライズするエンジニアも募集しています。
ソフトウェアローカライズエンジニア
あ、この記事のタイトルは、お察しのとおり、「STAND BY ME ドラえもん」からとって付けたものです。
いつもユーザーの側にそっと寄り添い、「助けてマニュアル制作エンジニア！」の声に反応。マニュアルという名の4次元ポケットから、あらゆる便利情報を取り出す。そんな存在でありたいと想い、付けました。
