一般にシステム開発の仕事では多くの「ドキュメント」を使います。「要件定義書」，「システム設計書」，「テスト計画書」など，開発や保守のフェーズで様々なドキュメントを作成する必要があります。

　なぜ，システム開発では多くのドキュメントを使うのでしょうか？　それは「システムが目に見えない」ということと，「大人数の役割が異なる人たちで協業して構築していく」という特別な事情が関係しています。

　「目に見えない」ものをコンピュータシステムとして構築していくのは，非常に難しい作業です。そのためシステム開発の世界では，昔から多くの人たちがモデル化を提唱し，実践してきました。「業務モデル」「データモデル」「機能モデル」などの図を使ったモデリングが行われてきたのです。DFD（Data Flow Diagram），機能階層図，UML，ER図など人が目に見える形を作り（今の言葉で言う「見える化」），ドキュメント化を助けてきました。

　またシステム開発は，多くの開発工程を役割の異なる人が担当します。上流を担当するコンサルタント，外部設計を担当するSE，内部設計を担当するSEからプログラマなどそれぞれの人たちは，前工程から要件定義書や外部設計書などのドキュメントを引き継いではじめて，自分の工程を作業できるわけです。このため，ドキュメントは大変重要なものなのです。

　他にも様々な理由はありますが，システム開発でドキュメントが多く使われるのは，このような理由があるためです。

ITエンジニアが最も苦手なのは「他人を説得するためのドキュメント」

　さて，これからが本題です。それでは，ITエンジニアが最も苦手とするドキュメントとはどんなものでしょうか？

　私自身の経験とIT人材指導の経験から言うと，それは「新しい企画などを他人に説明し，説得する」ためのドキュメントだといえます。多くのITエンジニアは「説得力を持つドキュメント」の作成が苦手です。特に，自分の会社で課長以上の役職者〜経営層クラス，顧客の上位職クラスに説明するドキュメントを苦手としている人が多いのです。かつて，私がシステム設計を担当するSEだった頃も，上位職を説得するドキュメントを作成するのは非常に苦手でした。一生懸命ドキュメントを作成し，説明するのですが，いつも以下のような厳しい評価コメントが浴びせられていました。

●文章が長い！
●最後まで読まないと結論が分からない！
●くどくど説明している！
●何が大事で，何がどうでもよいのか分からない！
●どうして，そういう主張になるのか分からない！（理由が不明確）

　現在の私は「説得力を持たせるコツ」が分かったので，上記のような評価コメントをもらうことはなくなりました。しかし，若い部下のドキュメントを読むと，やはり同じような指摘をしてしまいます。ITエンジニアにとって「説得力を持つドキュメント」を作成するのは難しく，上手く書けるようになるには，訓練が必要というのが私の結論です。そこで，今回は「説得力をもつドキュメント」を上手く作る方法について説明しましょう。

説得力を持つドキュメント作成のポイント

　まず，最初に考えなくてはならないことは，「なぜ多くのITエンジニアが上位職を説得できるドキュメントを書けないか」の理由を探ることです。私がこれまでの経験から導き出した結論は，「上位職が求めるドキュメント表現とITエンジニアが訓練されてきたドキュメント表現力はまったく違う」ということです。例えばITエンジニアがあるシステム企画を上司職に説明し，説得するためのドキュメントを作成したとしましょう。

上位職とITエンジニアの視点の違い

　一般に上位職は忙しいこともあり，完結でシンプルなドキュメント表現を好みます。「なぜ，この企画が必要なのか，この企画が成功する論拠は何か」という「理由」を論点にしたがり，これをドキュメント表現することを望みます。一方，ITエンジニアは「企画をどのように進めていくのか，誰がいつまでに何をするのか」というTODOをできるだけ詳細に表現しがちです。

　なぜ，このような違いが発生するのでしょうか？　これは上位職とITエンジニアの役割，それまでの教育の違いが影響しているからです。上位職が行うのは「判断業務」であり，自分で判断したことは常に成功させなければならないという責任を持ちます。だから，成功するかどうかの判断に関係する理由を詳細に知りたがるのです。一方，ITエンジニアは，若いときからシステム構築に必要な情報を全て漏れなくドキュメントに表現するよう，教育されます。例えば，年間10回くらいしかない，会社の業務上あまり影響をもたない例外処理を，上位職は気にすることはありません。しかし，ITエンジニアは年間10回であっても，誤処理を起こすことは許されない環境に育つ場合が多いのです。この結果，ITエンジニアは若いうちから，細かいことでも漏らさないように訓練されていくのです。上位職もかつては細かかったのでしょうが，マネジメントの仕事を行ううちに次第に判断に必要なこと以外は気にしなくなっていくのでしょう。

　このような理由から，上位職とITエンジニアの視点はまったく異なるものだといえるのです。従って上位職を説得するなら，ITエンジニアの視点では駄目です。上位職を説得するためには，上位職の視点でドキュメントをチェックし，修正していくことが欠かせないのです。

事例で確認しよう！

　かつて私が企画の仕事を始めた頃，新しいアイデアの説明を詳細に記した企画書を作成し，上司や役員をはじめて説得しなければならない機会がありました。私は職場の先輩である山田さん（仮名）にチェックしてもらうことにしました。山田さんは私の8年先輩で企画の仕事を長く担当していました。

芦屋：山田さん，新しいアイデア考えました。常務に説明したいので見てくださいますか？

山田：いいよ。どれどれ，うーんよく分からないな。

芦屋：・・・何かおかしいでしょうか？

山田： 1行目の「戦略的顧客応対システム」って，何が言いたいのかな？

芦屋：あの，新しい「店頭接客用のシステム」です。これを作る企画なんですが・・・

山田：なら，そう書けよ。で，誰がいつどこで何のために使うものなのかな？　分からないよ。

芦屋：当社の店頭販売員が，店頭販売で使うんですが。

山田：そういうことだね。なら，そう書いたらいい。・・・で，今のシステムでは何が駄目なの？　それも分からないな。

芦屋：今のシステムは，応答時間が長いので，顧客を待たせて会話が途切れるので，気まずくなるそうです。だから，この際，徹底的に顧客応対に特化したシステムを作ろうかと・・・

山田：なら，そう書けばいい。君の書き方は最終的な機能ばかり書いてあるから，なぜ必要で，どんな特徴があるのか分からないんだよ。

芦屋：お言葉ですが，そんな表面的なのでなく，企画自体を見てほしいんです。

山田：反論は受け付けないよ。俺は，この文章の意見を述べているんだ。君を批判しているんじゃない。君を批判しても無意味だからね。

芦屋：どういうことでしょうか？

山田：君は文書を使った説得の方法をまだ知らないだろう？　文章を作るのは君。でも，文書を評価するのは他人なんだ。だったら，他人がおかしいと思う意見をたくさん取り入れてブラッシュアップすることが，説得力を高めるための最も合理的な方法じゃないのか？

芦屋：・・・・・

山田：常務に同じ感想もたれたら終わりじゃないのか？

芦屋：常務は，そう思わないかも知れないじゃないですか？

山田：俺が思う以上，常務も同じように思う可能性があるんじゃないのか？そういう可能性は極力排除するのが企画の仕事と教わってないのか？

芦屋：それは・・・

山田：説得力がなかったら，終わりだぞ。

芦屋：でも，私的には，十分説得力があると・・・

山田：芦屋，それは客観的な事実でなく君の感情，自分で作った文章に対する情緒的なものだよ。いいかい，評価を高めるステップから感情は分離したほうがいい。感情に支配されるとよいことはない。

芦屋：・・・・・

山田：どうする？　もう止めようか？

芦屋：いえ，・・・もっと指摘してくださいますか？　助かります。

山田：了解。ここも分からないところだけど・・・

　山田さんの話は非常に参考になりました。上位職を説得するときには，上位職の視点をもつ他人の評価を素直に受け，十分な事前準備を行うことが重要です。「ITエンジニアとして十分経験がある人間が，独りよがりな文章を書いても駄目」ということを山田さんから教えてもらったのです。

「視点の違いを理解する」ことと「相手に分かりやすい説明」を行うこと

　上位職を説得するために重要なことは，ITエンジニアとしての「自分の視点と上位職の視点は異なる」ということを理解し，その上で，自分の考えていることを相手に正しく伝えることです。相手に理解してもらう以上，説明する側はとにかく分かりやすく説明することが求められます。

　人は，自分が分かっていることを相手も分かっているだろうと思い込む悪い癖があります。このため，相手の気持ちを無視した独りよがりの資料を作り，それを使って説明してしまうのです。これでは，相手に正しい話は伝わりません。では，どうしたら相手に伝わる資料を作成でき，それを使った説明ができるのでしょうか。

上位職の視点をもつ他人の評価を取り入れよう

　説得という行為が他人を納得させることである以上，自分一人で資料作ることには限界があります。これは，ITエンジニアとしての自分と，判断を主に行う上位職の視点が異なるからです。自分の視点の範囲で考えたこととは別の視点を要求していることを理解しておかなくてはなりません。そこで，上位職の視点をもつ他人の力を借りることが必要になります。こういった視点をもつ他人に資料を見せ，模擬的に説得をし，評価してもらうことが重要になるのです。

習得のためのアドバイス

　「説得力をもつドキュメントの作り方」のうち，最も難しいと思われる「上位職説得のためのドキュメント作成」という説得術を説明しました。ドキュメントの作成は，とかく，図の作り方とか色の使い方だとかの表面的な表現を重視するITエンジニアの方が多いのですが，私はもっと本質的なものを重視して指導しています。例えば，「A部長を説得するために最も必要なドキュメント表現とは何か？」と問われたら，あなたはどう答えるでしょうか？　「A部長がどういう人か分からなければ答えようがない」と言うのでしょうか？　私は「A部長をいつも説得している部下にドキュメントを見せてもらって，徹底的にレクチャーしてもらえ。書いた文書は納得できるまでチェックしてもらえ！」とアドバイスしています。それが，最も合理的な方法と考えるからです。

　ドキュメントは目的をもって作成されます。目的を達成するために，「何をすればよいか」「何ができるか」を常に考えて工夫していく人間だけが，スキルアップできるのです。

　今回で，この連載は最終回となりました。説得術という，抽象的な行為をより具体的に表現する工夫をしてきたつもりです。読者の皆様にどこまで有用であったかを確かめることはできませんが，多くのITエンジニアに少しでも役にたった部分があればこれ以上の喜びはありません。なお，この連載は完了しますが，私のブログ「芦屋広太のヒューマンな日記」では，引き続きヒューマンスキルアップ連載を続けています。また，ITProのサイトでも，「芦屋広太のひとつ上のヒューマン・マネジメント」を連載していきます。そちらもぜひ，よろしくお願いいたします。

芦屋広太　システムアナリスト/IT教育コンサルタント。 SE，PM，システムアナリストとしてシステム開発・システム統合などを経験。この過程で調査・分析した内容を「ヒューマンスキル教育」としてモデル化。現場での教育，雑誌・書籍の発表，セミナー・研修に利用する。著書に日経コンピュータでの連載をまとめた「SEのためのヒューマンスキル入門」「Dr芦屋のSE診断クリニック（翔泳社）」などがある。ブログ（http://d.hatena.ne.jp/officearon/）でのスキルアップ連載も好評。（連絡先：clinic@a-ron.net）