先日若手の方に「手順書の粒度」について質問されましたので、今日はその質問に対する私なりの答えを紹介したいと思います。
手順書の粒度とは？
操作手順書（所謂ユーザーマニュアル）、運用手順書、移行手順書など、システム屋は様々な局面で手順書なるものを作成します。問題になるのはこの手順書の粒度（どこまで細かく記述するか？）です。細かく丁寧に書こうとすればいくらでも細かくできますし、省略しようとうすればかなりサッパリした物にすることもでます。もちろん細かく丁寧に書けば読み手にとっては理解しやすいものになる可能性が高いですが、細かく丁寧に書くには多くの工数がかかります。逆に簡素なものであれば作成工数も最小限で済みます。
また、細かく丁寧な手順書は作成時に工数がかかるだけでなく、運用保守にも工数がかかってしまいます。例えば、「操作端末の画面ショットをふんだんに盛り込んだ手順書は、記載内容に直接関係ない場合でも、画面レイアウトのちょっとした変更に伴い修正(画面ショットの差し替え)を行う必要がある」といった具合です。
とはいえ、作成時や保守時の工数を考え簡素なものとしたら、簡素すぎて読み手が「理解できない」「手順を間違える」となると本末転倒です。
このようなことを考えると手順書の適切な粒度は「読み手が理解できかつ手順を間違えないレベルで、なるべく簡素に書く」ということになります。
適切な粒度を検討する時の考慮点
・考慮点１：読み手のリテラシを想定する
「読み手が理解でき、手順を間違えない」を前提とするには、読み手のリテラシをある程度明確に定義する必要があります。読み手のリテラシーが低い場合はそれなりの細かさで記載する必要がありますし、ある程度のリテラシを読み手に期待できる場合は細かい説明を省くことができます。
・考慮点２：システム固有の情報は必ず記載する
対象となるシステムに固有の情報（システムの目的や利用シーン、固有の操作方法/ルールなど）は必ず記載するようにしましょう。この部分まで省いてしまうと手順書に対する理解度が著しく低下してしまいます（アタリマエですよね）
・考慮点３：一般的な説明・他にも記載がある情報は省く
逆に、対象システム固有でない情報は記載を省く対象として考えてください。たとえば、操作端末のOSがWindowsの場合「WindowsOSへのログイン手順は省く」など、Web検索などで取得できる一般的な情報や当該手順書以外に記載がある項目については省くことを検討すべきです。
「保守対象となるか？」もポイント
上記考慮点に加えて「その手順書が保守対象がどうか？」も、もう1つの考慮点になります。たとえば移行手順書など通常1回しか使う予定のない手順書であれば、保守対象とはなりませんので保守工数を気にせずに作成時に許される工数の範囲で細かく/丁寧に書いてもOKです。
手順書も含めた各種ドキュメントの粒度については、システム開発の本質とはちょっと外れるにも関わらず、工数に大きなインパクトを与える可能性のある要因なので、なるべく早い段階でお客様を含めた関係者全員のコンセンサスを取る必要があります。ご留意ください。
コメント