手順書（ガイドライン）の作り方
List
現場のリーダーが作れ
「手順書」には、要求仕様作成手順書、要件管理手順書、プロジェクト計画書作成手順書、プロセスのテーラリング手順書、ピアレビュー手順書、不具合処理手順書、構成管理手順書、進捗管理手順書、リスク管理手順書、SQA審査手順書、ベストプラクティス判定手順書など、いろいろなものがあります。
分かりやすく言えば、プロジェクトにおいて新しく何かに取り組もうとすれば、書式や各項目における書き方や判断や例外的なことへの対応方法などの「基準」を決めておく必要があります。最初にプロジェクトとしてある程度の基準を決めをしておくことで、チームの中で足並みを揃えて進むことができるのです。そのためにも、これらの手順書は、プロジェクトのリーダーを中心にして現場の人たちが作成すべきというのが私の考えです。
また、こうした基準を事前に文書にしておくことで、途中で判断がぶれなくて済むのです。一般に、こうした基準を最初に取り決めて文書にされることはありません。そのため、時間の経過の中で書き方や判断が変化していくことも少なくないのです。一度判断が振れると、なかなか元に戻りません。こうして要求仕様の書き方がずれていくのです。中には、何らかの手順書のようなものが用意されていることがありますが、それでも例外的なことに付いてはほとんど明文化されていませんでの、そのような手順書が作られても実際には積極的には活用されないのです。「例外」が扱われていない手順書は、手順書としての価値は低いのです。
しかしながら多くのプロセス改善の現場を見ていると、“外部”で作られた標準の「手順書」がそのまま導入されています。時として、その標準の手順書には現場の誰も関わっていないこともあります。現場の人たちは、「エンジニアリング」の作業に忙しく、そうした「手順書」つくりに参加しているヒマがないというのが、もっとも多い理由です。そのため、プロセス改善の推進組織の人が、文献から適当なものをそのまま切り取ってきたり、CMMなどのプロセス改善のコンサルティングに入った業者が提供したものを、これもそのまま流用したりしています。
でも、こうした方法では、実際の運用の中で発生する細かな対応方法などを手順書にフィードバックされることはありません。そうした具体的で細かな判断や選択肢こそが手順書に必要なのです。例外的な事態への対応も現場の人たちが参加していないと事前に気付くことは難しいし、実際にそのような手順書で運用している中で例外的な事態に遭遇しても、自分達で作っていない手順書では、そうした項目が収まる場所が見つからないのです。あるいは、構成の意味を理解しきれていませんので、手順書の構成を変更しにくいのです。けっきょく、そこにある手順書は、有り難みの少ない、当たり障りのない手順書でしかないのです。
手順書は、ある意味では個々のプロジェクトにおける「ルール集」です。組織の全員がそうしたルールに精通している状態であれば良いのですが、その状態に達するまでは、現場でそのルールを必要とする自分達でルールを作るべきなのです。そうすることで、組織の全員（またはそれに近い人たち）が、このような「ルール」に精通することができます。
たとえば、今回、要求仕様書の書き方を「USDM」の書式（拙著「要求を仕様化する技術・表現する技術」参照）で書いてみようという時、文献を参考にして書式を決めたり、要求の表現の見本や実際のカテゴリの分け方、「認定仕様」の基準、幾つかのケースで＜グループ＞の観点などを決める必要がありますが、それをすかさず「要求仕様書作成ガイドライン」としてまとめておくのです（私は、“手順書”よりも“ガイドライン”という表現の方を多く使用しますので、ここから“ガイドライン”に切り替えます）。最近では「Power Point」でまとめることを勧めています。こうすることで、項目の追加が容易なことと、他のチームに説明したり、組織内でプレゼンテーションをするときもそのまま使えますので便利なのです。
要するに、プロジェクトで何か新しいことに取り組むときは、同時に「○○作成ガイドライン」を作ることです。要求仕様書だけでなく、レビューの仕方を変えるとか、プロジェクト計画書を書くといった、新しい取り組みでをする時に、最初に「ガイドライン」の形を作っておき、実際に進め方や基準を考えた時に、すかさずその「ガイドライン」に追加していくのです。最初に「形」にしておかないと、現実の作業の中で作ることは難しくなります。
ガイドラインの中に書くそれぞれの方法や考え方などの基本は、適当な文献やセミナーの資料などから引用しても良いでしょうし、場合によってはサンプルやテンプレートをそのまま活用することになるかもしれませんが、いま用意しているガイドラインは、このあとのプロジェクトで実際に取り組むテーマですので、それらを使ってプロジェクトの中で活用する場面を想定し、成果物の構成や用語の説明、書き方の基準、判断の仕方などを決めれ良いのです。ここで作るのは決して「組織の標準」を作るのではありません。あくまでも今回の「プロジェクトの標準」です。
もちろん、別のチームですでにこうしたガイドラインが作られているときは、それを参考にして、同じ考え方でいけるものはそのまま流用し、勝手が違う部分は手直ししたり追加すれば良いでしょう。その意味では、プロセス改善の推進役の人が持ち込んだ「標準」や、外部のコンサルタントが持ち込んだ「標準」も、それはあくまでも参考であって、自分達で手直しすれば良いのですが、そのような機会が設けられていないかもしれません。でも、最終的には「自分が経験したことと、自分の頭で考えたこと以外は役に立たない」ことを肝に命じておくべきです。
組織の中でこうしたガイドラインの「流用」をくり返すことで、組織の誰もが必要なガイドラインを作るスキルを手にし、しかもそこには多くのプロジェクトで洗練されたガイドラインが残るのです。「組織の標準」は、こうして使い込まれて、ある程度のパターンに収束した「プロジェクトの標準」を元にすればよいのです。
もちろん、同じタイトルのガイドラインが「１つ」に収束するとは限りません。規模やドメインの違い、顧客の種類などによって異なるガイドラインになることもあります。大事なことは、現場の人たちの手でこうしたガイドラインが“自在に作れる”ことと、プロジェクトの要求に合うように“変化させることの判断”ができることです。「宛てがわれたガイドライン」のままではこうした対応ができず、結局、時間の経過とともに要求に合わないガイドラインに縛られてしまい、硬直化の中で失敗する可能性が高くなるのです。
例外も規定すれば例外ではなくなる
プロジェクトの最初に取り決めるガイドラインや「標準」の中で、この後の取り組みの中で遭遇する“すべてのケース”を扱うことはできません。事前のガイドライン作成の段階で気付くことや、イメージできる範囲でしか「ルール」を作ることはできません。そのため、実際の運用の中で、事前には想定されていなかった事態に遭遇することになりますが、そのような時は、そこで判断した基準やルールとして決めたことを、ガイドラインやプロジェクト「標準」に書き加えておけば良いのです。
しかしながら、プロジェクトの最初にある程度のかたちでガイドラインとして作っておかなければ、プロジェクトの中で遭遇した「想定外」の事態に対する対応や決定事項を書き残すことはできません。そのため、せっかくの経験も“次”に活かされることがなかったり、実際に経験した人の中に“ノウハウ”として残るだけになってしまい、組織のスキルには昇華しないのです。
この種のガイドラインなどで漏れることの一つに「例外事項」があります。要求の至要化の中で、「理由」が書けないケースはどうするか、ベースライン設定のレビューまでに仕様について合意が取れないケースはどうするか、適当なライブラリ関数が見つからない時はどうするか、不具合対応プロセスの中で、緊急に入ったバグに対して、就業時間外になてしまい検討委員会が開けない場合はどうするかなど、通常のパターンから外れるケースに対する扱いが重要になります。
しかしながら日本は、基本的には「例外」を認めない社会です。少なくとも1999年9月の東海村JCOの臨界事故が発生するまでは、「例外」を明文化することは認められない社会でした（まだ全面的に解消したわけではありませんが）。そのため、JCOにおける常識では考えられないような被爆人身事故が起きたのであり、そのような事故を想定した防災訓練もやってこなかったために、周辺に住む多くの一般住民も被爆したのです。さらにこの事故では、救助に駆け付けた救急隊も被爆するというお粗末な事態も引き起こしています。どうやらそこにあったマニュアルにはこの種の「例外事項」への対応が書かれていなかったものと思われます。
皮肉な話ですが、あの忌わしい事故によって、「例外事項」を明文化することの必要性が認知され、めったに起きないような例外的な事態を想定した演習が可能になったのです。
話は少し飛びますが、同じようにこの種の社会文化の影響から、うまく機能しない取り組みがソフトウェア開発の中に見ることができます。たとえば、プロジェクトは成功することが前提となっていて、計画書の中で「失敗する可能性」を明文化することを認めない風土があります。そのため、プロジェクトの最初にリスク管理の一環として「失敗する可能性」をリストアップすることが“不謹慎”と受け取られるのです。
また、そのような組織風土の中では、「バグ」の発生件数の見積もりとその対応のための工数を事前に確保できないことがあります。たとえば、プロジェクト計画書の「目標」のところで「バグ件数＝０」と書かれることによって、バグの対応工数を見積もることはできなくなります。そのため、他のプロセスにこの工数を忍び込ませることになり、その分だけ見積もりが曖昧になりますので見積もりスキルの修得に支障を来します。そうした“水増し”ができなければ、このプロジェクトは最初から失敗するか、「バグ」データが「QAテストでのバグ」しか計上されないのを利用して、その前の設計者によるテストの工数を大幅に確保することで表面に出るバグを隠すことを考える可能性もありますが、問題は何も解決しないことに気付くべきです。
こうした対応になるのも、「例外事項」の発生を認めない文化のしわ寄せと言えるのです。
話をガイドラインに戻しますが、こうした「例外事項」が書かれていないガイドラインは、役に立たないことに気付いてほしいのです。プロセスに慣れてくれば、通常のルールには慣れてきますので、いちいちガイドラインを見ることはなくなります。というよりも見る必要がなくなるのです。そうなると、現場の人たちにとって役に立つガイドラインというのは、めったに起きないこと、つまり「例外事項」に遭遇した時に、どう対応すべきかが書かれているガイドラインということになります。
「例外事項」というのは、事前に想定されていないことですが、ここでは解釈を拡大して、何度か遭遇したかもしれないがめったに遭遇しないことや、他の誰かが遭遇したことがあることも含めます。ある人が対応に戸惑うことが起きた時、このガイドラインを見れば、その判断の仕方や対応方法が書かれていることが望ましいのです。もちろん、想定外の全く新しい事態に遭遇した時は、関係者が集まって判断や対応方法を決めますので、すかさずその内容をガイドラインに追加すれば良いのです。このように「例外事項」がきちんと書かれているガイドラインは、いつまでも活用されるガイドラインなのです。
そして、こうして定義された「例外事項」は、定義された時点で、実は本当の意味での「例外」ではなくなるのです。つまり、その人にとっては「例外事項」かも知れませんが、組織の文化としては「例外」ではないというのが望ましい姿なのです。
それでは、ガイドラインには「例外事項」しか必要無いのか？という短絡した質問をされたことがありますので、念のために、その他の項目（ここでは「一般事項」と呼ぶことにします）がきちんと定義されることの必要性を簡単にまとめておきます。
１）一般事項は、新たにチームや組織に参加する人や、他のチームにやり方を説明するときに有効
２）新しい状況に対応するために一般事項を変更するときに有効
１）の方は別に説明する必要はないでしょう。
２）の方は、もともと「定義することの本質的意義は変更できること」にあります。このことはあまり認識されていません。例えば、外部からボードとセットでモジュールを購入する時、「ソースコードは付いていますか？」と尋ねることがありますが、これは、自分達で変更する可能性があるからです。いつまでも変更しないのであれば、ソースコードを要求する必要はありません。ガイドラインや「標準」の定義も、これと同じで、市場や顧客の要求の変化に対応しなければならず、いつまでも同じ定義で通用するわけではありません。それに、定義されていなかったことで担当者の“ノウハウ”となってしまったことによる混乱は、すでに多くの組織で経験済みのはずです。一般事項も、定義されていることではじめてその時点での要求に合うように変更（テーラリング）できるし、新たに変更した部分はプロジェクトのメンバーも慣れていないので、実際の場面ではガイドラインを参照したり確認したりしながら進むことになるのです。