今回は、文書類に関わることの各論です。
（総論については、記事『文書化した情報（総論）』をご覧ください）
文書と記録の違いや、計画書・仕様書・手順書など個々の文書の注意点について述べます。
（書籍に書いてあることと重複する内容もありますがご容赦ください）
—
■ 記録
記録とは、実施した結果（証拠）や計測結果のことです。文書の一種ですが、それ以外の文書と性質が大きく異なるので、その違いを中心に説明します。
昔のISO9001は「文書」と「記録」を別々に記述しており、行うべき管理の違いが分かりやすかったのですが、現在（2015年版）は記録も “文書化された情報” の一部という扱いになっています。「文書」の定義が『情報及びそれが含まれる媒体』ですから、”情報が含まれる媒体” という意味で同じ扱いなのでしょう。「文書化した情報」は、後に続くワードによってどう扱わなければならないのかが分かりますが、『保持』とあるものが “記録” のことです。
記録とそれ以外の文書によって、その性質や管理内容がどう違うのかを下の表に示します。
このように、記録とそれ以外の文書とでは、情報を文書化する目的や管理の視点が大きく異なります。
しかし、『必要な時に、必要な情報が、必要な状態で利用できること』という管理の視点はどちらも共通しています。
また、記録以外の文書として作成したものでも、時間の経過とともに記録に変化するものもあります。例えばプロジェクト計画書は、作成した時点ではそのプロジェクトに必要なものですが、プロジェクトが完了した後は “過去の計画の証拠” として記録としての管理の対象となります。
—
■ 計画書
計画書とは、計画を文書化したものです。ここでは、「計画の策定」と「計画書の運用」において気をつけるべきことを述べます。
１．”計画” とはスケジュールのことだけではない。
『いつやるか（スケジュール）』 だけが計画ではありません。次のことも重要です。
『誰がやるか（役割分担、責任と権限）』
『どのようにやるか（手順、環境、設備）』
『どの程度やるか（出来栄え基準、完了基準）』
これらも、しっかり検討して計画書に明記しましょう。
２．計画は、必要に応じて適宜見直すこと。
状況は常に変化します。その変化を素早くとらえて、それに応じて軌道修正することが必要です。それが、計画の変更であり計画書の修正です。
ただし、安易な変更は禁物です。「状況がどう変化したのか」を見極めて「状況の変化に対応するにはどうしたらよいか」をよく考えて見直しましょう。
—
■ 仕様書
仕様書とは、”仕様” を文書化したものです。仕様とは、製品の形状や動作・サービスの内容など、対象の有り様のことです。
また、一連の個々の作業のINPUTやOUTPUTにあたる文書が「仕様書」です
ここでは、仕様書を作成する際に気をつけることを２つ述べます。
１．仕様書には「外見え」と「内向け」の２つがある。
【外見え】ユーザー目線で記述した仕様書です。製品案内や取扱い説明書などによくある「機能仕様」「スペック」などがそれです。
【内向け】開発者向けの情報を記した文書です。外見えの仕様を実現するための情報を記したものです。「構造仕様」「設計図」などがそれです。
各作業の関係と、その間でそれそれの仕様書がどうつながっているのかをよく考えながら作業しましょう。
２．仕様書の役割は３つ。
(1) 作業のインプット … 作業の入力情報。これが間違っていると後の作業は総崩れです。
(2) 作業のアウトプット … 試行錯誤の結果を形にしたもの。次の作業や他者の作業のインプットになるものです。
(3) 組織の資産 … 保守資料、引継ぎ資料など。未来の自分や後任のための情報です。
間違った情報や曖昧な情報をもとに作業すると不良を作ることになります。仕様書は、詳しい情報を正しく伝えるための仕組みです。きちんと作成しましょう。
—
■ 手順書
手順書とは、手順を文書化したものです。ここでは、手順書の作成や利用の際に気をつけることを２つ述べます。
１．手順書を作成する理由は、「手順を目に見える」ようにすること。
手順書はただ「書けばいい」というものではありません。作業前に勉強したり、作業中に確認したり、周知徹底に利用したり、新たな要員の指導に用いたりするものですから、正確さはもちろん、見やすく・分かりやすく・曖昧さがないことが必要です。
したがって、手順書には図が必須です。文書における図の役割について、多くの人は「文章が主、図が補足」というイメージを持っていると思いますが、私は手順書に関しては「図が主、文章が補足」であるべきだと考えています。作業の手順を長々と文章で書くよりも、フォローチャートで示した方が一目瞭然です。
手順を文章で記述すると、読み手にとって分かりにくいだけでなく、似たような流れや条件が複数ある際に作成ミスを犯しやすく（間違いに気が付きにくく）なります。そこで、手順書を作成する際には「構造化プログラミング※」をお勧めします。これにより、複雑な条件や複雑な流れを整理でき、視覚的に表現することができます。手順書の先頭に構造化チャートを１枚載せておくだけで、手順書の分かりやすさが格段に良くなります。 ※ 記事「複雑なことを整理する｜構造化プログラミング」参照
２．手順書を守ることが目的ではない。
守るべきは定められた「手順」です。
手順が守られていれば手順書など無くてもよいのです。品質（特にISO9001）に関わっている人の中には「何でもかんでも手順書が必要」と言う人がいますが、それは思い違いです。
手順書は、手順がきちんと守られるようにするための道具であり、手順の問題点を確認して改善するための道具でもあります。道具は正しく使いましょう。
コメント