「業務システムのためのユーザーマニュアル作成ガイド」なる書籍が発行されたとのことで、その辺について思うところを入手前（笑）に書いておこうと思います。
業務システムのマニュアルにおける一番重要なポイントは、画面単位ではなく、業務単位で説明することです（例：「顧客情報登録／修正」という画面があるとして、「顧客情報登録／修正」という画面単位ではなく、「顧客情報を登録する」「顧客情報を修正する」という業務単位で見出しを用意する）。業務システムでは単一画面で特定業務が完結するように設計されることが多いと思いますが、当該画面への遷移方法は利用組織・業務依存で異なることが常ですので（コンテクスト依存）、業務単位で説明した方がユーザーにとってわかりやすいのです。業務システムのマニュアルは、システム開発を担当したSIerが画面単位の外部仕様書を流用して作成することが多いと思いますが、この点に注意が必要です。
また、担当者が入れ替わりながら保守管理をしていくことを考慮すれば、特殊な制作ソフトウェアやデータ形式、極端に凝ったレイアウトを採用しない、ということもお約束に含まれます。（長期間にわたる保守管理を前提としない、ある意味使い捨ての）わかりにくい特定業務だけの簡易解説シートのようなものであれば凝りに凝ったPowerPointスライドでも良いでしょうが、ある程度ボリュームがあるマニュアルであるならば、素直にWordで作成した方が保守管理の面で得策といえます。
忘れられがちな観点として、業務マニュアルとの兼ね合いをどうするのか？という極めて重要なポイントもあります。業務システムのマニュアル（操作マニュアル）と業務マニュアルとの間の線を何処に引くのか、両者のバランスをどう取るのかの判断は非常に悩ましく、「これが正解」というものはありません。例えば先の顧客情報登録の際に、備考として自由記入フィールドが用意されているとしましょう。このフィールドに入力すべき情報の内容や入力に当たっての留意点は、業務システムのマニュアルと業務マニュアルのどちらに記載すべきでしょうか？まあ、この例の場合は第三の選択肢である「UI側でカバーしちゃえ」（フィールド初期値として文字列を表示するなど）というのが正解っぽいですけど（笑）
ちなみにユーザーが単一マニュアルを見るだけで情報入手を完結できることを最優先とするならば、業務システムのマニュアルと業務マニュアルを分割することはナンセンスです。ただこの場合、業務改善や業務システムの改修の影響がマニュアルに与える影響（保守管理コスト）が極めて大きくなります。先のTCシンポジウムでも指摘された通り、業務マニュアルは長く使われる性質を持ちますので、変更があることを前提に変更の影響を局限化できるような設計をはじめから意識する必要があります。その意味で、ユーザーの利益のために単一マニュアルの本文中にすべてを記載するという判断は、運用する側にかなりの負荷を要求することになります。極端な例を挙げてみましょう。
このように、業務システムのマニュアルと業務マニュアルを単純に統合しようとすると、情報量の増大によりマニュアルとしての機能が低下するだけでなく、業務の中核フローが変更されなくとも末端の運用基準が変更になっただけで大元の業務マニュアルの修正が必要になるなど、管理負荷が過大になるということに注意が必要です。業務マニュアルの設計に当たってメンテナンス性が重視されるというのはこういうことで、制作ソフトウェアやデータの作りかただけの問題ではないのです。全社対象の業務マニュアルや各種の規定書、部門単位の業務マニュアルとの間の兼ね合いといった頭痛のタネも、この種の問題に積み重なってきます。
で、メンテナンス性とユーザーニーズをどうバランスさせるかが問題なのですが...。この問題は本来、業務システムの設計段階で、十分検討される必要があるはずです（先の例のようにUI側でカバーできないか検討するなど）。ですが、どうしてもマニュアル系については「ヘルプ付ければいいや」「業務マニュアルに書くから」で片付けられがちで、なかなか上流側で意識すべき問題として取り上げられないのが実情でしょう。別に業務マニュアル制作をマニュアル制作会社に完全外注せずとも、業務改善検討や業務システム設計の段階で、ドキュメンテーションに長けた人材を参加させるようにすれば解決していく問題だとは思うのですが、問題周知も含めて先は長そうです...。
情報大工のひとりごと