今回も前回に引き続き、構造化のテクニックを使ってわかりにくい資料を整理していく。例文の修正を通じて、ドキュメントの構造は仕事の進め方や課題の構造を反映し、それを整理することは仕事や課題の整理につながることを説明する。
前回までの例文の修正結果を図1に示す。今回は、前回手をつけなかった（1）～（3）の項目について検討する。これらは同等に並べてよいものだろうか。これらで十分だろうか。
まず、同等に並べることについては、適切ではない。最初の段落に「必要な機能を漏れなく指示する」「必要な箇所を漏れなく判断できる」という2つの要件が示されている。しかし（1）～（3）のそれぞれが、この2つの要件とどう関連しているかが明確ではない。
内容を検討すると、前者に対応するのは（1）、残りは（2）と（3）になっている。明確には書かれていないが、修正箇所を網羅的に洗い出すために、ユーザーと開発者による作業の分担を前提としていることが文章から読み取れる。ユーザーは自分が関わっている業務の変更で生じる、画面上の目に見える修正は明確に指示できる。これが（1）の記述だ。
しかし、システムがどう作られているのかわからないこと、他のユーザーの業務を含めた全体が見えているわけでもないことから、指摘した以外の修正箇所がないとは言い切れない。そこで、（2）修正が必要な理由や（3）後続の業務を材料として示し、システムの観点で業務全体を見ることができる開発者に補完してもらおうという考え方だ（図2）。
つまり図3で示すように、ユーザーが把握している画面上の修正箇所を起点に、その修正の理由である業務の変更内容を示す。さらに、変更した業務以降の業務を示すことで、業務の変更によって生じる他の画面への影響を判断できるようにしている。
これで十分とまでは言い切れないが、ユーザーが持っている材料を使って、個別の修正項目から影響の検討を依頼する範囲を順次拡大しているのがわかる。以上を踏まえて整理した文章が図4になる。
ここまで、文意や表現を変えず、構造視点で例文を整理してきた。修正依頼書の記述意図と内容を明確にできたと思うがいかがだろうか。しかし、この内容で納得できるかというと、残念ながら筆者には違和感がある。進め方に無駄が多いからだ。
ユーザーが知っている範囲を示した上で、より広い範囲を開発者に見てもらおうというアイデアは理解できる。しかしこの指示通りに、同じ業務に関連する別の画面の修正を指示するとどうなるだろうか。（1）の画面の修正箇所は違うが、（2）のa）、b）は同じになるはずだ。つまり同じ記述を何度もすることになる。
この問題を解決するには、順番を逆にすればよい。業務の流れ全体と変更する業務を最初に示し、次にその業務に関連する画面を挙げる。その中で修正が必要な画面を示し、その画面の修正箇所を示すようにすれば、無駄なく効率的だ。ただし、文章は組み立て直しになる。
ドキュメントが活動や課題に直結
ここで、話がドキュメントの構造から、仕事の進め方の検討になっていることに注意してほしい。ドキュメントの構造は、それによって表現しようとしている活動や課題の内容を反映するからだ。ドキュメントの構造を検討することは、活動や課題の整理に直結するのだ。
スタッフの仕事の段取りや組み立てのスキルが低く、OJTなど現場の指導でなかなか効果が出ないという悩みを持っている部署は多いと思う。この課題を解決するために、構造中心のドキュメント作成のトレーニングをお勧めする。
スキル不足のスタッフを集め、そのうちの1人が書いた出来の良くないドキュメントについて、各自文意を変えずに修正してもらう。このとき、日本語にはこだわらず、構造の整理に専念してもらうことが大切だ。
このトレーニングを繰り返すことで、ドキュメント品質が短期間で向上する。そして、ドキュメント構造の検討を通じて、活動や課題を整理するスキルも向上する。構造観点でのドキュメント整理には、本連載で紹介してきたSo what？やMECEといったロジカルシンキングの構造化テクニックを活用してほしい。
ピースミール・テクノロジー株式会社 代表取締役社長
富士ゼロックス、外資系データベースベンダーを経てウルシステムズに入社。上流コンサルティング事業の立ち上げのためITエンジニアのスキルアップ教育を実施。産業技術総合研究所でのシステム開発で培った技術の展開をミッションとする関連会社（現職）を設立、代表に就任。
