言語化から図表化へ
昨今のビジネスパーソンはとにかくドキュメンテーションの質が著しく低下していると感じます。
特に年代などは関係ありません。
40代半ばでも圧倒的に「自分だけ」「一部の人にだけ」わかればいいという思想が見え隠れするドキュメントを非常によく見かけます。正直「読むほうの身になれよ？」と言いたくなるほどヒドいものも多いと感じてしまいます。
特にフリーフォーマットのものや、本人にフォーマットを考えさせると目を覆いたくなります。「WORDなんかよりEXCELのほうが使いやすい」などと言っていても、そのEXCELすらまともに使いこなせていない…なんてことは日常茶飯事です。
私たちＩＴエンジニアは、開発プロジェクトに参加するととてもたくさんの種類、たくさんの量のドキュメントを作成することがあります。実際、私自身もプロジェクトに参加するとエンジニアでもないのに数百ページ～千ページほどのドキュメントを書いてます（10/3からユーザー企業側のＰＭＯとしてプロジェクトに参加していますが、すでに100ページ近く書いてます）。
ですが、それらドキュメントの大半は目的に合わせて体裁や最適化を常にするように作成しています。なぜなら
自分以外の人に見せる
＝コミュニケーション（認識や情報の共有）
を最大の目的としているからです。可読性、習得性などが低いドキュメントはそれだけで品質が相当低いと言わざるを得ません。しかし、現在ではそういったドキュメントしか作成できないビジネスパーソンとそれを許容する企業とが非常に増えてきているように思えるのです。
当然、コミュニケーションツールであるドキュメント自体の質が低下し、情報や認識を共有することもおぼつかなくなっているわけですから、他人との情報共有や認識の共有に支障が出ます。すると集団活動では足並みをそろえた連携は取れなくなっていくでしょう。もうそうなってしまったら組織ですらありません。ただの烏合の衆です。
そうならないようにしたいなら、とにかく文章表現／文書化にもう少し気を遣うようにしましょう。
ソフトウェア開発においてもとにかく文章にすることです。
一般的なプロジェクトでは、業務フローやユースケース図、シーケンス図などを要件定義の成果物とすることも多いかもしれません。これらの資料は見た目が良く、また可読性も高いのでユーザー要件が整理できている感覚に陥りやすい傾向があります。
個人的には文章でだらだら書くよりも、こうした図表を多用するほうが齟齬を起こしにくくて良いと思うのですがもちろんデメリットもあります。
たとえば図形オブジェクトの位置調整やコネクターの置き換えなど、見た目を整えるために時間も労力も多く消費する可能性があります。日本のエンジニアの多くは文章で記述するほうが楽だという理由だけのために、こうした図やオブジェクトの切り貼りに「慣れていない」ため、生産性がとても悪いのです。
また、そうして生産効率が落ちやすい割には説明のスペースが少なく、実際には作成者しか意図が分からない場合も珍しくありません。もちろんドメインやクラスなどうまく部品化すれば一つひとつをわかりやすく整理することは可能ですが、「慣れていない」ことの弊害はこんなところにも出てきます。
特にこうした図表（≒ダイアグラム）を中心とした表記は、コミュニケーションの不得意なエンジニアあがりの人は相手の読解力を無視しやすいために注意が必要で、そういったリーダーやプロジェクトマネージャーの意見を取り入れてしまうと、大半のプロジェクトで何らかの失敗を誘発してしまうことでしょう。
もちろんこのような図表（≒ダイアグラム）はきちんと書き方、読み方のルールや手順を整え、関係者間で徹底してしまえば最終的にはとても有用になります。だらだらと文章でまとめただけの煩雑なドキュメントを読むよりもはるかにわかりやすくなっていることでしょう。
しかし、こうした成果物にいきなり取り掛かるのではなく、まずは業務仕様を文章にしてみてください。
言っていることが逆転しているように感じるかもしれませんが、なにもおかしくはありません。
×：何でもかんでも文章でまとめようとしてしまう
×：いきなり図表で書こうとしない
○：まず文章で整理して、その内容を図表に反映する
にしようと言っているわけです。
実際に、この方法は同様の指導を若手向けに実施している企業は少なくないといいます。仕様や機能をとにかく文章で書き出すだけです。行間にこっそり仕様を滑り込ませるようなことはせずに全て包み隠さず文章化する。ただし、記述の仕方は個人依存にさせず一定のルールを設けます。
文章で記述する時点で考えてほしいのは5W2Hの意識です。
それぞれが「いつ、どこから、誰が、何の情報を、どういう理由で、どれぐらいで、どうするのかが明確かどうか」を織り込んでいるかを意識するのです。また、その文章もできるだけ箇条書きのように記載し、一文一文をできるだけシンプルにします。
特に「誰が（Who）」「どういう理由で（Why）」「どれぐらいで（How Much/How Many）」には注意したほうがいいでしょう。
「誰が（Who）」
自分の業務・作業に慣れきっている人ほど省略しがちです。
その結果、開発側が行動の主体を特定できずに困るケースはよくあります。
「どういう理由で（Why）」
要求の妥当性を判断するためのものです。
読み手の思考を停止させず、理解や納得を得るためにも必要です。
「どれぐらいで（How Much/How Many）」
利用頻度や量は合意形成の対象情報から漏れ落ちることが多い傾向があります。
たとえば私はQMSの品質マニュアルを作成したときも、プライバシーマークを取得するための個人情報保護マニュアルを１から作成したときも、ソフトウェア開発プロジェクトで操作マニュアルや運用マニュアルを作るときもそうですが、できるだけ
"「Who」は、（「When」時に）「What」を「How」する。"
という書き方に表記を統一して書いていました。
「Who」は主語
「What」は目的語
「How」は述語
になります。
さらに目的を明確にするときには
"「Why」のために「Who」は、（「When」時に）「What」を「How」する。"
と統一して書いていました。
このように、文章を記述する際に担当者一人ひとりの表現力やその場の思い付きで文章を書かせるのではなく、常に定型的なフレームワークを定義してそのフレームワークに沿って全員が共通の表記とするようにします。こうすれば足りていないものがすぐに分かります。書かれていない要求は「ないもの」とみなせるからです。
また、こうすると文章で整理しても読む際に誤読がぐっと減ります。
日頃から書いて確認、書いて確認をくり返し、齟齬なく関係者と認識齟齬がないことを確認しながら詰めていってみてください。レビュー／評価する側も5W2Hを意識してレビューしてみてください。
こうした文書化においては、当たり前で分かりきったことも必ず記述するよう指摘します。また、「する」ことだけ記述するのではなく「しない／できない」ことも記述します。
とにかく「書いていない事項はシステム化されない」と思った方がよいでしょう。
そうして文章がある程度整理されてきたら、その内容から業務フロー図やユースケース図、シーケンス図などの各種成果物へと展開していくのです。
図表化までの手順を端折ってフリーダムにしてしまうと、だいたいコミュニケーションとしてはどこか抜け漏れや齟齬が生じて失敗する部分が出てきます。そうならないようにちょっと手間かもしれませんが「言語化」→「図表化」の手順を踏むようにしてみてください。それだけで圧倒的に抜け漏れや齟齬の発生する確率はグッと減るはずです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。