美しいドキュメントを作る
ソフトウェア開発を行うエンジニアって、実は思った以上にたくさんの種類のドキュメントを作成します。その仕事上、プロジェクト計画書や提案書、見積書のようなものから、システムの鳥瞰図や概要図、業務フロー、モデル図、ＤＦＤ、業務分担図などさまざまな資料を作成します。私が比較的好んで用いている10～11種ほどあるＵＭＬなんかもありますね。そのほかにも、打合わせ資料、進捗報告書やトラブル報告書、顛末書、品質報告書などの類もあります。
そしてそれを同僚、上司、お客さまに提示します。
目的はそれぞれですが、どのドキュメントにも共通しているものもあります。それは
「誰かと認識や理解を共有する」
ことです。
そう、いわゆるコミュニケーションの基本にして究極。本質となる部分です。コミュニケーションとして成立しなければ、ドキュメントなんて作っても価値は半減以下です。
ドキュメントは強力なコミュニケーションツール
まず、「コミュニケーションがスムーズに成立する」それだけでお客さまに
「こいつはやるな！」
と思っていただけます。それだけで信頼を得やすくなります。新規顧客だとその瞬間に自分を売り込めるため効果は絶大でしょう。
次に、「顧客に自分が言いたいこと」「訴えたいこと」をより的確に伝えることができます。すると顧客との間での勘違いや早とちりなどの誤解が大幅に減ることになります。
システムの開発範囲や要件の範囲などの打合わせでは、その効果は少なくありません。即ちドキュメンテーション能力はエンジニアにとって強力なコミュニケーション力でもあると言えるわけです。
人の五感と情報吸収率は
味覚：２％
嗅覚：３％
触覚：１５％
聴覚：２０％
視覚：６０％
なんて言われているのですから、視覚化できるドキュメンテーションスキルが高いか否かというのは、いわば生命線と言っても過言ではありません。
特にシステムという目に見えないモノを相手にしているＩＴの世界では、図や絵を上手く使うと口頭説明以上のコミュニケーション効果があるものです。
また、往々に優秀なエンジニアの中には口下手な人が多いものですが、そんな人もドキュメンテーション力があればその弱点をカバーすることもできます。
そうに考えると、エンジニアにとってドキュメンテーション能力があるかどうかは、しっかりした仕事ができるかどうかの１つの分水嶺と言っても過言ではないのです。
エンジニアリング活動における最重要課題の一つ
しかし、エンジニアの中にはプログラミングさえ強ければ良いと考えているのか、ドキュメントに絞ってみると「ちょっと...」と思える人が少なくありません。
たとえば提案書などでは、ドキュメンテーションが下手なエンジニアが作った資料を、営業や他のエンジニアが体裁を整えたり再編集するケースも少なくないでしょう。
また、トラブル報告書などでも
技術用語満載で丁寧には書いてはあるが、
読む方から見ると「何を言いたいの？」「結論は？」などと
理解に苦しむことも珍しくない。
なんてことも起こります。その他にもいろいろな資料を見ますが、もっと起承転結を踏まえたメリハリのある文章が書けないのかと、お客さまは大抵思っています。
もちろん学生時代からしっかり書ける人と言うのは非常に少なく、若い時には大抵お客さまに理解できないと言われて恥をかくことや、言いたいことが上手く伝わらないこともあるでしょう。
そしてどうすれば上手く表現できるか、どうすれば図や絵で上手く表現できるか、どうすれば簡潔で迫力のある文章が書けるか、などと悩み勉強を積み重ね、いろいろなシーンのお客さまで様々な経験をしてエンジニアのドキュメンテーションの重要性を知るようになります。
美しい資料を作ればビジネスが伸びる
具体的に次のような点に力を入れるといいでしょう（資料の作り方など一般論を書いても意味がないので第一線の技術者としての視点で書く）。
1. 読みたくなるような資料を作れ
その理由は次の通りです。
「システム開発や導入などの時はお客様の方はSEが提示した資料は下手に書いてあっても必ず読んで下さる。そして分らなければ質問もされる。それはお客さまはその資料を理解しないとプロジェクトの管理などが出来ないからだ。だが、提案活動や不良発生時の対応資料などでは状況が違う。特に他ベンダーのユーザーへの売り込みはそうではない。お客様は何を言っているのか分からない資料は、そもそも読まれない。それは内容を理解しなくても何ら支障がない。単にベンダー選定の比較表に×をつければ済むだけなのだから。
それでは我々のビジネスは伸びない。従って、エンジニアを名乗る者は"お客さまが読んで下さる資料"ではなく、"お客さまが読みたくなるような資料"作りを心掛けなければならない。そのためには日頃努力しなければならない。努力なしに、いざという時にそんな資料を作れるものではない」
2. 外部資料はできるだけ全件レビューする
お客さまへの提案書は何を訴えたいのか？
わかりやすいか？
読みたくなりそうか？
同業他社より差別化できているか？
などといった視点で厳しくレビューしましょう。それは、訴求力と言う点においてドキュメントの優劣がビジネスの成否を大きく左右し、さらに内容が優れていれば競合他社を一歩も二歩もリードできるからです。
3. 図や絵を書く時は必ずキーとなる「何を言いたいのか」という文章を書く
その会議などを欠席された方が、後でその資料を見られても何を言いたいのかわかって頂くためです。
中には「文字が多すぎると読みたくない」といって、Powerpointで描いた図や絵だけでお客さまにプレゼンする人もいますが、そんなエンジニアは急用で急遽欠席された顧客の方にどうやって言いたいことを伝えられるか考えた方が良いでしょう。
こんな些細なことが往々にビジネスを左右するものなのです。
4. 日頃ことあるごとに美しいドキュメントを作れ
常日頃から周囲と共に「ドキュメンテーションが上手いと、自分を顧客に売り込めるし、顧客との間での勘違いなどのコミュニケーション・ミスも減る。信頼も得やすい。ビジネスも上手く行く。だから勉強せよ」と言いあうようにしましょう。
そうやって常に刺激しないと、エンジニアという人種は往々にしてプログラミングにばかり目が向きやすいからです。
その他にも、
・文章は起承転結を踏まえて書け
・できるだけ箇条書きで書け
・マクロからミクロに書け
・一文は60文字程度にしろ
・よりインパクトがあるように、共感や感動を呼ぶ言葉を使え
・図や絵を上手く使え
・一枚の資料でも表紙をつけろ
などさまざまな点で気を付けるポイントと言うものがあります。
そうしているうちに現場でモノづくりだけしか興味を持とうとしないエンジニアたちも変わっていきます。当初はお客さまとの打合わせに表紙もつけない資料を持っていくエンジニアであっても、段々と表紙をつけることが当たり前のようになるでしょう。
また、エンジニアが図や絵などの資料を書いた時は上司やお客さまに提出する前に、まわりの仲間に「これは分かる？」と聞くようになるケースも出てきます。
こうした定常的な取り組みが常識化すれば、その他にもさまざまな変化が現れ、美しいドキュメント作りは組織の一つの文化になっていくことでしょう。
一流は例外なくドキュメンテーションが上手い
巷で有名な一流のマネージャーや営業は、総じてドキュメンテーションが上手です。ドキュメンテーションが下手なまま、一流のマネージャーや営業になった人はあまりお目にかかることがありません（ゼロとは言いませんが…）。
それは一枚の図や絵や進捗管理表で、プロジェクトの関係者である顧客やメンバーやパートナーなど、多くの方々に自分が考えていることを適確に知らしめることができるからでしょう。
そのためにエンジニアは、"たかがドキュメント"と軽視せずに日頃一枚の文章や図や絵を書くときでもいかに上手く描くかを心がけることです。
それを5年10年と心掛けた人と、そうでない人のとの差は大きいはずです。
ドキュメンテーションは、重要なコミュニケーション技法である
そのことを改めて認識しましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。