私の職場でも手順書を作成する機会は多い。プログラマが開発環境を構築する手順、リリース時にサーバー等にセットアップを行う手順など。また、ソフトウェアのテスト項目を書いた「テスト仕様書」も手順書の一種といってもいいだろう。
手順書には、ただ作業の手順（WHAT/HOW）を書けばよいというものではない。何のためにその作業をするのかという目的（WHY）も書くべきだと思う。例えば、テスト仕様書であれば、テストの「方法」だけでなく、何を確認しようとしているかという「観点」も書くべきだ。
★
「目的」を書くことのメリットの一つは、作業中のトラブルに対応しやすくなることである。なぜその作業をするのか、ということが分かっていれば、作業中に予期しなかった事態が発生しても、作業者自身が対処方法を考えることができる。
例えば、
(1) C:\data を C:\databack にコピーする。
(2) foo.exe を実行
と書かれた手順書があったとしよう。(1) の作業中にディスクが一杯になって、コピーできなかったらどうするか？ 不要なファイルを削除して空き容量を増やせばいいが、それが困難な場合もあるだろう。(1) の処理の目的が何か分からない以上、これ以上作業を続けるのは危険だ。(2) の foo.exe が C:\databack というディレクトリにアクセスするのであれば、続行することは出来ない。
もし、これが、
(1) データディレクトリのバックアップ
万一に備え、C:\data を C:\databack にコピーしておく。
(2) foo.exe を実行
となっていれば、C:\data をコピーする目的は明確だ。念のためにバックアップしているだけなら、「C:」ドライブの空き容量が不足していれば、「D:」でも「E:」でもいいだろうという判断ができる（※１）。
★
「目的」を明確化することのもう一つのメリットは、手順の記述ミスを検出しやすくなることである。目的を満たせないような手順が書かれていれば、読む人が気づくからだ。そして、一般的には、「目的」自体を書き間違えることは、「手順」を書き間違えることよりも少ないだろう（※２）
★
「プログラム」が何らかの手順を示すものだとすれば、こうした作業用の手順書は、人間を制御するためのプログラムであると言えるかもしれない。手順書がプログラムなら、バグが混入することもある（※３）。手順書を書く時にも、プログラミングを行うときと同じくらいの力や情熱を注ぐべきだろう。
応援のクリックお願いします → 
※１
もっとも、この場合はコピー先を「C:\databack」と明示する必要は無いので、あまり良い例ではないのだが・・・。
※２
「もっとコメント論 」では言及していなかったことだが、同様の効果はソースコードのコメントにも期待できるだろう。つまり、ソースコードに処理の「目的」をコメントとして書いておけば、処理の実装がそれと一致していない場合に、バグとして検出することができるというわけである。
※３
昨年11月の東証の障害もそうだったのではなかったか。
■関連記事
・足跡の作り方（前編）
・プログラムに操られた男
・もっとコメント論 ～その１～ コメントとは何か
・誰のためのコード？
・どこまで書くか設計書
SEを極める 仕事に役立つ文章作成術
―百戦錬磨のプロマネが伝授するドキュメント作成の極意
―百戦錬磨のプロマネが伝授するドキュメント作成の極意
posted with amazlet
on 06.07.09
福田 修 日本情報システムユーザー協会
日経BP社 (2005/11)
日経BP社 (2005/11)
現場の仕事がバリバリ進む ソフトウェアテスト手法
posted with amazlet
on 06.07.09
高橋 寿一 湯本 剛
技術評論社 (2006/05/10)
技術評論社 (2006/05/10)