川村渇真の「知性の泉」

使用目的などから導き出すと良い解が得られる


難しいテーマの質問には、解の導き出し方を教える

 システム開発の業界に長くいて、こんなサイトを公開していると、必ず尋ねられることがある。「仕様書は、どのように書けばよいのでしょうか?」という質問だ。テーマがあまりにも大きすぎて、簡単には回答できない。
 こんなときは、仕様書の書き方を説明する代わりに、仕様書の設計の仕方を説明するようにしている。そのほうが、尋ねた人が自分で応用でき、対象システムに適した仕様書を作れると思うからだ。
 仕様書の設計の仕方とは、仕様書に求められる条件を先に調べ、それを満たすように仕様書の書式や書き方を設計する方法である。もっと一般的な表現に変えると、「何かを作る場合、それに求められる条件を先に洗い出し、その条件を一番多く満たす形で、目的物である何かを設計する」となる。
 この方法自体は、対象となる何かに関し、そのの具体的な内容を求める汎用的な検討手順でもある。対象となるのは、仕様書だけでなく、報告書といった書類、組織の規則、製品の仕様など、ほとんどのものが可能だ。というわけで、どのように考えて解を求めるのか、大まかにだが紹介しよう。

検討対象が報告書なら、読み手が求める内容に

 仕様書を例にすると難しすぎるので、上司に提出する報告書を題材にしよう。設問は「報告書は、どのように書けばよいか?」である。この場合でも、具体的にどんな報告書になるかは、何を報告のかで大きく異なる。ここでは、報告書の設計の仕方が目的なので、すべての報告書を対象として話を進めよう。まず最初は、報告書に関していろいろと考察してみる。
 報告書というのは、誰がに報告する目的で作成し、その相手に提出する。つまり、読み手が存在するわけだ。その読み手が本当に知りたいことこそ、報告すべき内容になる。トラブルの解決報告なら、解決したかどうかの結果だけでなく、何が原因で、どのように対処し、どの程度の被害があったのかも含まれる。
 報告書で考慮すべき点は、説明の詳しさである。詳しく説明するほど、書く側が大変なだけでなく、読む側も時間を費やす。両者が使う時間は、直接的な仕事ではないので、できるだけ少なく押さえたい。そのため報告書には、内容が把握できる範囲内で、最小限の項目だけを入れるのが理想だ。
 定期的に提出する報告書では、何も問題がない場合もある。そんなときまで詳しい説明を書く必要はない。ただし、「何も問題なし」の1行だけを書いたのでは、本当に問題ないのか読み手は確信を持てない。問題ないと判断した際の材料を、一緒に示す必要がある。具体的なデータが望ましく、作成の手間を軽減するために箇条書きを採用し、項目名とデータを並べるだけで十分だ。
 判断に用いた基礎データを示すと、報告者が気付かない何かの兆候を、読み手が気付く場合もある。早目に気付くほど対処が容易なので、その効果は意外に大きい。もちろん、問題が発生した場合でも、基礎データを示すのは当然だ。その際には、様々なデータを示し、原因の特定、被害規模の推測、対処の効果などを判断材料に用いる。
 読み手にとっては、結論を明確に示すことも重要である。トラブルの解決であれば、解決したのか、もうすぐ解決するのか、解決のメドが立ったのか、それとも立たないのか、原因すら分からないのか、現在の正確な状況が知りたいはずだ。こうした結論を最初に示し、その理由や状況を詳しく説明するのが、上手な報告の方法といえる。

報告書に求められる内容を、階層構造で整理する

 以上のような検討がある程度までできたら、検討した内容を整理する段階に入る。それまでに挙げた項目を分類し、階層構造で並べてみる。それで大まかな整理ができるので、あとは不足する項目がないか、全体を通して考えよう。思い付いた項目を追加しながら何度か考えると、必要な条件がまとまる。
 報告書に必要な条件の大枠は、読み手が求める内容を含めることと、読み手と書き手の無駄を少しでも減らすことの2点だ。これに沿って、考えられる項目を挙げると、以下のようになる。

報告書に求められる条件
・読み手の求める情報を含める
  ・結論をハッキリと書く
  ・結論を導いた過程を説明する
  ・読み手を説得できるように、判断材料を明示する
  ・気付いた点なども、早目に報告する
・書き手と読み手に無駄な時間を使わせない
  ・本当に必要な項目だけに限定する
  ・内容の重要度の応じて書式や説明量を変える
  ・内容が理解しやすい構成にする

 以上のように整理できたら、個々の条件を満たすための具体的な工夫を考えてみる。この段階になると、具体的に何の報告書か決めなければ前に進みにくい。トラブル解決の報告書なら、「内容が理解しやすい構成にする」の工夫としては、最初に結論を書き、次に詳しい説明を続ける書式がある。詳しい説明の部分でも、原因の調査から始まって、誰もが原因を究明するときの手順と合わせれば、読み手も段階的に中身を検査できるため、内容が理解しやすくなる。このように、1つの条件に複数の工夫を洗い出してみる。
 報告書の書式の検討では、より広い範囲で考える必要もある。その1つが報告の方法で、紙に印刷した書類だけに限定せず、口頭による報告、電子メールでの簡単な報告、電子ファイルでの報告なども一緒に検討する。報告対象の内容によっては、報告しなくてもよい状況があるかもしれない。
 工夫がひととおりで終わったら、あとは整理してまとめる段階だ。まず、矛盾する工夫を取り除く。たとえば、内容を正確に書ける工夫があったとして、書くのが面倒になるものなら、「書き手と読み手に無駄な時間を使わせない」の条件を満たせない。
 こうした矛盾を排除した後で、残った工夫を組み合わせて、最終的な報告書の候補をいくつか用意する。その中で一番良いものを選べば、かなり良質な報告書の書式が得られる。もし残った工夫を全部入れられるなら、複数の候補を用意する必要はない。
 この種の思考方法に慣れてくると、上記のような条件の整理を、早い段階からできるようになる。ただし、最初のうちは自由な思考が重要なので、少しの間だけは制限を付けずに考えたほうがよい。その際に思い付いた項目をメモしておけば、後で整理するときに役立つ。
 なお、現実の世界では、読み手である上司側のレベルが低い状況も存在し、こんな検討が通じにくい。これは報告書の内容検討とは別な問題なので、ここでは取り上げない。

汎用的な検討手順として整理すると

 報告書の内容検討で用いた手法を、より一般的な検討手法として整理してみよう。報告書の例で欠けているのは、利用する状況が複数ある場合である。たとえば、システム開発の仕様書なら、開発中に設計内容を調べるだけでなく、設計内容のレビュー、開発終了後のシステム変更などにも用いる。こういった複数の利用状況があるなら、そのすべてに対応しなければならない。
 複数の利用状況も考慮し、具体的な作業手順として整理した結果が、以下の検討手順だ。見て分かるように、工夫や対処が矛盾する場合や、複数の候補から選択するなどの工程も含めてある。

汎用的な検討手順として整理した結果
1. 検討対象物を利用する状況を明らかにする
2. 利用状況ごとに、必要な条件を洗い出す
3. 条件ごとに、それを満たす具体的な工夫や対処を見付ける
 (1つの工夫や対処が複数の条件を満たすこともある)
4. 工夫ごとに、重要度や効果を判断する
5. 工夫や対処を組み合わせで、矛盾するものを洗い出す
6. 矛盾を避けるように、工夫や対処の組み合わせを複数選ぶ
7. 選んだ組み合わせを評価して、一番良い組み合わせを決める
8. 決めた組み合わせに従って、検討対象物を設計する
9. 設計した内容を評価して、悪い部分を修正する(必要な回数だけ)

 以上の内容だが、現実には1回目の手順である。設計したものを実際に使ってみると、気付かなかった問題点が生じる場合もある。その際には、同じ手順で設計し直せばよい。2回目以降の適用では、工程2の「必要な条件を洗い出す」部分で、気付いた問題点に関係する条件が加わるはずだ。
 この作業手順で注意しなければならないのは、最終的に求めた検討対象物の中身が、1つの形式ではないかも知れない点である。報告書の例で示したように、問題がないときと発生したときで書式を分ける方法もある。もちろん、複数の書式を含んだ1つの書式定義を採用しても構わない。ただし、複数の書式を含む形式だと、内容が複雑になりがちで利用しづらく、あまりお勧めできない。
 状況ごとで書式を切り替えると言っても、その数が多いと別な問題が生じる。どれを使えばよいのか迷ったり、書き方を間違えたりしやすくなる。どんな書式を採用するにしても、全体として可能な限り単純化することだけは、強く心掛けたい。
 ここでは書式の例を中心に取り上げているが、このような検討手順は、道具や仕事のやり方などを決める際にも役立つ。この手順に従えば、物事の存在理由から考えられ、それに必要な項目を洗い出すことで、たいていの内容は得られるはずだ。

仕様書に限定せず、開発の書類体系から検討する

 最初に取り上げた、システム開発における仕様書の書き方に話題を戻そう。この質問をした人の意図は、仕様書の具体的な形式を教えてほしいという部分もあるが、開発全体でどんな仕様書を書くべきかを知りたい意図も含んでいる。
 話としては仕様書という言葉を用いたが、実際の開発で作成するのは仕様書だけでない。記述の重複や無駄を避ける意味でも、書類全体を一緒に検討し、最良の解を求める必要がある。その意味で、開発の書類体系を最初に設計すべきだ。
 システム開発は期間が長く、その過程で何種類もの書類を作成する。それぞれ必要な段階で作成するとともに、採用したシステム開発方法論、設計手法、開発ツールに依存する部分も多い。書類の内容をそれらに合わせないと、実際の製作物と書類の内容が対応しづらいからだ。
 マトモなシステム開発方法論では、開発工程を数個に分割し(フェーズと呼ぶことが多い)、その中を数個の大きな作業(同じくアクティビティ)に分け、さらに数個の作業単位(同じくタスク)に分解する。こうした作業を眺めてみて、どんな書類が必要なのか洗い出す。実際の開発方法論では、作成すべき書類も指定されているので、新たに洗い出す必要性はほとんどないだろう。
 作成すべき書類が決まったら、前述の検討方法を個々の書類に適用してみる。求められる基本条件としては、設計内容の正確な記述、重要な項目の記述漏れの防止、短い時間で書けること、レビューのしやすさ、システム変更時の書類自体の修正のしやすさなどが挙げられる。この基本条件を照らし合わせ、より細かい条件を求めてみる。
 システム開発のように作成する書類の種類が多いと、書類間の関連も検討しなければならない。記述の重複を防止するだけでなく、前工程の設計内容との整合性を検査しやすくする工夫(具体的には、設計した機能ごとにIDを付けて関係を検査するとか)が必要だからだ。こういった点は、個々の書類の検討では難しく、書類体系のレベルで検討しなければならない。
 こうした上位レベルの検討でも、前述の検討方法が適用できる。個々の書類の場合と同じように、基本条件を決めてから、より細かな条件を洗い出す。最終的には、書類の書式だけでなく、作業方法までが得られるはずだ。それに沿って、個々の書類の書式を検討すればよい。

 どんな作成物でもそうだが、それを作るのには何らかの目的がある。その目的に合わせる形で仕様を決めれば、たいていの作成物で適切な形式が得られる。ここでは、その視点と手順を紹介してみた。
 作成の目的は、時間とともに変化する。以前は適切であった形式でも、現在の状況に照らし合わせると不適切な場合もある。もはや作ること自体に意味がないものまでだ。適切な形式を定期的に見直すことで、作成物の内容を改善できるし、必要ないものまで作る無駄を防げる。
 どんな風に作ったらよいのか迷ったときは、ここで紹介した検討方法を適用してみよう。何も考えずに作るよりは、かなり良い形式が求められるはずだ。そして、その作成物の重要度が高いほど、得られる効果は大きい。

(2000年6月25日)


下の飾り