ドキュメントなお話

2013年3月15日

例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れてくるUIの外部仕様を知ることではなく、機能全体を理解すること、そして機能訴求ポイントや訴求方針を押さえることです。そういった面を全部想像してライティングするよりも、当該設計／実装に至った経緯を記した検討資料や各種仕様書（いわゆる「ドキュメント」）を入手して、エンドユーザー向けにコンテクスト変換した上でブラッシュアップ、必要に合わせて不足情報の追加というフローで作業した方が、正確で重要なポイントを押さえた成果物につながるわけです。それも効率良く。

なのですが、どうもこのドキュメントを要求する行為を甘えと取る人がそれなりにいるようで、なんだかなあという感じです。資料開示すればすぐに問題が解決するにも関わらず、どうして開示を嫌がって原稿作成工程に無用の負荷を掛けたがるのか、理由がまったく謎です。新規テキストをスクラッチでイチから起こすことと、エンドユーザーの利益（ひいては製品やサービスの提供側の利益）と、重要なのはどちらでしょうか。いろいろ見聞きしている範囲ではありますが、何を優先するべきか？の判断基準がズレてきてるなあ...と感じることが増えた今日この頃です。

この種の問題のありがちな原因として、開示できるレベルのドキュメントを残していない（から開示できない）というのであれば、それはそれで大問題ですよね。開発＆コアグループだけで検討や情報共有が完結するならば、整理されたドキュメントなしでも（当座は）良いのでしょうが、デザインにせよテキストにせよ、あとから外部発注作業を入れることが前提であるならば、絶対に何らかのドキュメントを残す必要があります。それに運用フェーズや人事異動でメンバー変動が発生することを考慮に入れれば、「開発＆コアグループだけだからドキュメントは不要」という弁解が通るはずがないのは自明だと思うのですがね。

ところで、エンドユーザー向け外部説明（各種ガイドやヘルプ、FAQ）の構成検討は、製品・サービス仕様検討と並行して進めるべきというのは、一体いつになったら一般化するんでしょう。仕様検討の段階で「これは仕様で対応、これはUI上のテキストラベル他で対応、これはヘルプなど外部説明で対応」のようにしっかり考えておかないと、最後になって「マニュアル（ヘルプ）に書いておけばいいや」のお約束が発動することになります。エンドユーザー向けのFAQを検討するなかで、仕様検討から漏れている観点も拾うことができるという効用も、いまいち理解されていないようです。ただコストダウン圧力の余波で最近はお疲れ気味とはいえ、メーカー系はなんだかんだでまだしっかりしてる印象です。Web屋さんはHCDとか言うのであればもっと頑（ｒｙ

ということで、「ドキュメント出して」「ドキュメント作って」「ドキュメント観点も大事」というまとまりがないようなあるような怪しい三本立て（何）でお送りしました。