読者の中に、自分が書いた文書のレビューを受けることに、苦手意識を持っている方はいないでしょうか。

レビューを受けると、自分の作ったものに必要以上にダメ出しをされているような気がしたり、沢山赤入れをされたものを返却されて気が滅入ったりすることがあります。そのため、「品質を高める」という目的はわかっていても、できれば形式的で無難なレビューで済ませたい、などと考える方が少なくないようです。

レビューを受けるのにはストレスがかかりますが、レビューは、品質の高い文書を効率的に作成するうえで必要な作業であり、なおかつ、自分自身のスキルアップも図れる貴重な機会でもあります。特に、システム開発の中でも提案書や報告書など顧客と折衝するため文書を作るようになると、レビューをうまく受けることが非常に重要なポイントになってきます。これらの文書の品質を高めるには、技術者としての視点だけでなく、顧客からの視点で文書を見ていくことが必要で、そのためにはレビューを有効に活用するのが最も効率的だからです。

提案書や報告書を作成するには顧客視点での見直しが必要。そこでレビューが重要になってくる

今回および次回は、顧客と折衝するための文書を作る際にレビューを活用して顧客視点を得るコツを紹介します。まずは顧客視点が大切になる理由を説明し、それを踏まえたうえで、レビューの受け方に関する良くある誤りについて説明します。

レビューが大切になる理由

私は数年前にシステム開発会社から現職に移り、ITコンサルティングを行っています。システム開発会社にいた頃から設計書など技術文書を書いてきましたが、現職では、そのころに受けたレビューとは全く質の違うレビューを受けています。

レビューの質が違うのは、コンサルティングの成果物である文書に求められる品質が違うからです。

コンサルティングの成果物は、顧客に対して提案したり報告したりするための文書です。こうした文書では、内容が技術的に正しいというだけでなく、顧客から見て理解しやすく納得感があるということが大切です。つまり、顧客の視点で文書の品質を評価することが必要になってきます。

このことはコンサルティングの成果物に限るものではなく、システム開発でも、顧客との折衝に使う文書には同じことが言えます。案件を受注するための提案書や、顧客がカットオーバーを判断するための品質報告書のような文書は、内容に関して読み手である顧客に理解かつ納得してもらうことが目的であり、顧客視点で評価することが必須です。

「顧客になったつもりで評価する」というのは、言葉にするのは簡単ですが、これまで技術者としての訓練を中心に受けてきた人が突然それを求められてすぐに実践できるものではありません。顧客との折衝の経験を積めば、顧客視点を持つことができるようになりますが、それには時間がかかります。そのため、顧客視点を、レビューを通して補うことが必要となり、レビューが重要になってくるのです。

こうした顧客折衝に関わる文書の作成経験が少ない人には、陥りがちな典型的誤りがあります。以下では、それらを紹介します。

誤り1: 記述不足は説明で補えばよい

文書に記述の不足があっても、プレゼンの場面で説明を補えれば十分だと考える人がときどきいます。最近の提案書や報告書がPowerPointなどのプレゼンツールを使って作られることが多いことの影響かもしれませんが、これは誤解です。

「プレゼンノウハウ」系の本などを参考にすると、記述を省略して単純化しアニメーションを駆使した資料を作りたくなりますが、このようなプレゼン資料と、プレゼンツールを使って作られる正式な文書は別物なのです。

提案書や報告書は、たとえプレゼンツールを使って作られていても、プレゼン資料ではありません。成果物となる提案書や報告書を提出するにあたって、プレゼン形式で文書の内容を顧客に説明することも良くありますが、その場合でもプレゼン資料と考えてはいけません。顧客に提出され、正式な文書として扱われる提案書や報告書は、プレゼンの場で一回だけ参照されて役目が終わり、とはならないためです。

提案書であれば、顧客側の担当者は、案件の発注に向けて社内で関係者を説得するためにその提案書を利用します。提案がコンペになっているのであれば、その提案書の記述内容が競合の提案書と比較されます。そのようなとき、プレゼンで補った記述不足が間違いなく補足される保証はありません。

顧客の基幹システムのカットオーバーを判定するために提出された品質報告書は、顧客のビジネスに直接影響のある意志決定に使われる重要な文書です。その内容が口頭で補足しなければ理解できないような曖昧なものであることは許されません。報告書は解説がなくても顧客に理解して納得してもらえるだけのものである必要があるのです。

誤り2: 完成させた状態にしてからレビューを受ける

書き手が自分自身で納得できる文書を完成させてから、初めてレビューを受ける、というやり方をする人もいます。技術者視点で内容が正しい文書を作成するだけで良ければ、このやり方が効率的である場合もあるでしょう。設計書などの場合、詳細部分まで緻密に整合がとれた状態で内容を確認してもらわないと意味がないことがあるからです。

しかし、顧客視点で見て品質の高い文書を作成する場合、このやり方は適切ではありません。提案書や報告書では、その文書で何を伝えたいかというメッセージと、メッセージを支える論理構成が重要になります。このメッセージと論理構成がどうなるかによって、文書の全体の目次や、どの部分に重点を置いて記述するかといったメリハリが変わってきます。

こうした文書を書き慣れていない人が顧客視点での文書のレビューを受けると、多くの場合メッセージや論理構成に大きな変更が伴う指摘を受けることになります。時間をかけて全体を詳細に書き上げてからレビューをするスタイルでは、最後にこのような指摘を受けて大幅な修正が必要になり、作成期日に間に合わないといった事態になってしまうことがあるのです。

このような事態を避けるには、提案書や報告書では、メッセージや論理構成の骨組みを作り上げる段階から、レビューを受けてそれらを確かなものとしていくことが必須です。見方を変えると、顧客視点で品質の高い文書は、レビューのくり返しの中で書き手とレビュアーによって作り上げていくものだということになります。

次回は、レビューを通して顧客視点で文書の品質を向上させていく進め方を紹介します。

(イラスト ナバタメ・カズタカ)

執筆者紹介

田原 幸弘(TAHARA YUKIHIRO)
- ウルシステムズ シニアコンサルタント


ユーザー系SI企業にて、映像配信、セキュリティ、通信制御などの開発案件でプログラミングから要件定義まで携わり、2007年より現職。大規模プロジェクトでの要件定義手法定着支援、開発ベンダーの設計書品質向上などのコンサルティングを中心に行うほか、システムリプレースの要件定義や顧客への提案活動に従事している。利用者、情シス部員、開発者全てに利益があるシステム開発プロジェクトの実現を目指して、日々の業務に邁進している。