だんだん業務マニュアルっぽい内容になってきました。 旧版のマニュアル、承認者と担当者の取材、下流工程関係者への取材と業務仕様書への材料は全てそろいました。 「よーし、後はこれをまとめるだけ」と思いましたね？ 残念ながらそうはいきません。業務マニュアル特有の一番面倒な「突き合わせ」が残っています。 今回は長いです。
「突き合わせ」工程
「突き合わせ」は上記旧版のマニュアル、承認者と担当者の取材、下流工程関係者への取材といった集めた仕様にそれぞれ食い違いや矛盾が多数出て、かつそれらが互いに間違いではなく社内で回ってしまっているようなズレ状態をどうするか、という話です。
業務に精通した人なら、この時点で「ぐげげ～」となるはずです。
製品マニュアルにはあってはいけない工程
この工程は取扱屋本業の「製品マニュアル」には存在しない工程でした。
製品マニュアルでは､製品の操作に「操作は場合によって異なります」があると欠陥仕様だからです。
ソフトウェアの操作で、実際の製品に合わせて「この操作はAの画面とBの画面では異なります」と書いたところ「こりゃまずいな」とソフトウェアの方を修正したという事例もありました。 この突き合わせ工程は製品マニュアル制作では経験していません。 製品1つにつき仕様は1つですから、同じ製品でいくつも操作方法が異なっている仕様はありませんでした。例外的に法務関連では可能性はありますが、取説屋は「法務関連は社内でやって」というスタンスでしたから、問題になったことはありません。
今回の記事は取扱屋が「いくら取材しても仕様がいつまでも決まらず、納期が…という業務仕様書」を請け負ったときの経験から書いています。
なぜズレが起きる？
このズレ問題は業務側の標準が定まっていないために起きています。
業務仕様書・マニュアルの書き手に責任はありません。 A部署とB部署で手順が食い違っていたら、 「A部署ではこう、B部署ではこうです。どちらを標準にするか決めてください」 までが書き手の仕事です。
「A部署ではこの手順、B部署ではこの手順。標準手順は未決定」 が正しい業務仕様書です。
書き手の役割
業務仕様書から作られた業務マニュアルの誤りは、一箇所の間違いだけでなく、業務マニュアルそのものの信用問題、言い換えれば「その業務マニュアルはあてにならないから読んでも無駄」とされてしまう。
B部署の人がA部署の手順が書かれたマニュアルを見て「これは間違っている、使えない」として二度とそのマニュアルを見なくなることです。
だから、両方ある、未決定と書く。
そこでA部署とB部署が、 「いや、うちが正しい」 「いや、そっちが間違っている」
そして、A部署とB部署で揉めても、さすがにそれは書き手には責任を取れません。
同じ業務に2種類の手順があり、標準化されていない一番困った例もあるはずです。これは書き手には決められないので､双方に内容を示して落とし所を決めてもらわないとならない。 役割を整理します。
- 取材を受けた人：事実を出す
- 書き手：事実を整理する
- 業務側：仕様を決定する
- 書き手：決定された仕様を文書化する
手順が2種類存在し、どちらを標準とするか未決定 の場合でも、この役割分担を崩すのは危険です。
この役割分担を崩すと、業務仕様書の書き手、マニュアル作成者がいつの間にか業務設計者になってしまうという大問題に発展します。 業務上の標準を決定する責任は業務側にあります。 同時に書き手には以下の責任があります。 これが今回の内容のキモです。
- 食い違いを発見する
これは、取材と資料の読み合わせで行います。 - 食い違いの内容を正確に記録する
- 関係者に確認する
- 未決定事項を明示する
書き手側も無責任ではいられません。
業務で異なる実例
シンプルな実例を示します。 「この作業は月末までです」とあったとします。 「月末処理」と聞いても部署によって以下のように取り方が異なります。 まず、暦月の最終日にやる、月末までに終わっていればよいの2つがあります。 ここでは「月末までに終わっていればよい」とします。
- 最終営業日までにやる
- 暦月の最終日までにやる（←月末が土日祝なら？）
- 翌月第1営業日までにやる（←遅れいても、提出が1日なら…という態度）
- 25日締めなら25日までにやる
他に以下のような場合もあります。
- 月末までに終わっていればよい（月末はなんとなく）
- 月末処理：実施日不明。要確認
営業の納品日の月末と、銀行の営業日が関連する経理の月末と、人事の月末、システム部の月末は異なります。 以下のような感じです。
- 経理 → 銀行営業日、支払日、締め日などが関係する
- 人事 → 勤怠締め、給与計算、社内の締め処理など、別の基準になる
- 販売 → 会社の営業日や売上締め
- システム → バッチ処理の実行日やデータ確定日
業務仕様書が完成したときにただ「月末」と書いてある場合に、どれに当たるかを再チェックできるようにするため「経理月末」「人事月末」「販売月末」「システム月末」と名前をつけておきます。 こういった条件のリストは別にまとめておくと良いでしょう。
「条件次第」「人による」は2種類ある
業務使用初を作っていると数多く出てくるのがこの「条件次第」「人による」です。
- 条件次第：条件によって処理が変わる。
- 人による：担当者や決裁者によって処理が変わる。
これら2つも業務仕様が確定できない内容ですが、条件や人の判断がルールによって変わっているのか、それとも組織内の習慣等で行われて把握できない場合があります。
ルールによるものであれば、「金額による」「業務担当者の判断」のように詳細に場合分けして書きます。
それ以外、組織内の習慣等で行われて把握できない場合は、「条件による：条件不明」「人による：条件不明 担当者名または担当部署を記載」のように書きます。
書いていても嫌ですが、やむをえません。
「不明・未決定・条件次第」は誤りではない
「不明・未決定・条件次第」はエラーに見えますが、勝手に「月末25日」と入れるよりはるかに安全なエラー状態です。
たぶん、プログラマならわかるでしょう。正しいエラー値ではなく、変数に設定した見慣れない値が表示され、「この値はなんだ？」とわからなくなる、あの状態を避けるためです。
何度も取材しても業務仕様書の下原稿ができても、どうしても不明・矛盾かあるなら、また後で再取材して書き直せるように「不明、複数の場合あり」と明記する。適当な「何か」が書いてあると見つけにくく、それを訂正するのは心理的にも負担です 「金額などの条件によって変わるが、金額等の条件が不明」と書いてあれば、後からの修正は容易です。
- 不明：現時点で情報が得られていない
- 矛盾あり：複数の情報が一致しない
- 要確認：資料と実運用などの確認が必要
業務仕様書の段階では、こういったものをしっかり出してください。
嫌だな、と思うのは当然です。 「こんな中途半端なもの出すな」と言われそうに思います。 でも、「経理の月末とシステムの月末は異なり、ずれています」と明記されていれば、それは確認者は文句を言えません。 どれを採用するかを決定するのは業務仕様書、業務マニュアルを書く担当者ではなく、実際の作業担当者、決定する上長です。
以前、下流工程の人に「『これが遅れるとどうなります？』と取材しておくように」と書いたのは、このためです。
これが根拠として入っているととても強くなります。
実際のところ、経理関係では、支払日や入金日などに直結する処理もあり、1日の遅れが大きな影響を及ぼすことが多い。その上、なぜか担当者がとても厳しい…ようなこともあったりした…ような気がします（汗）。
取材してもどうにもならなかったら？
いくら取材しても「不明・矛盾」がどうにもならないこともあります。
その場合はどうするかという問題が残ります。 あなたに決裁権がない場合は、この「不明・矛盾」が含まれた業務仕様書の原稿を「決裁権のある上長」に投げてください。
確認者に改変・破棄されたりしないよう、念のため手許にバックアップは取っておいてくださいね。
確認担当者（主に上長）に投げるのは無責任ではありません。
書いている人間には決裁権がありませんから、管轄外の事を行うのが間違いです。
ただ、書き方は工夫する必要があります。
「業務仕様 不明・矛盾点 確認書」として「書き手」と「確認担当者」、「確認提出日」「確認者の受領日」「回答日・承認日」を入れます。これは責任の所在を明確にするためで、後々とても重要になります。決して省略しないでください。 正式な業務では、提出・確認・承認の記録を残すことが重要です。
上記の「月末」の例では以下のようにチェックボックスをつけて選んでもらいます。
□経理 、□人事、□販売、□システム、□責任者指定、□条件により変わる（条件記載欄入れる）
これは取材してもわからなかった点ですから、決定の権限がある人に決めてもらう必要があります。
ここだけは避けられません。 気が重く、面倒ですよね。上長の「お前にやれと言っただろうが」というセリフが目に浮かびます。しかし、ここを曲げると後の自分にダメージが何倍にもなって返ってきますから、耐えてください。
業務仕様書の完成
チェックが戻ってきたら、内容を原稿に落とし込みます。 この作業は難しくありません。
どのパターンを適用するかを指定する、条件による場合は条件別に書く、確認できずならそのまま書く、不明ならばこれまたそのまま書く。 これだけです（←おいっ）。
わからないことをそのまま書くのは心理的に抵抗があるのはわかります。 でも、これはそこまで書けば完成です。気にせずやっちゃってください！
わからないことを、わからないと書けること。それも専門家の能力です。