ビジュアル化（見える化）した資料を元に進める
言ってみれば当たり前のことですが、資料を作るのはめんどくさいものです。私も好きな作業ではありません。けれども私はほぼすべての活動において、必ず資料化します。
求められなくても
大変な状況であっても
それが利益につながらなくても
必ずです。
Excelなのか、Wordなのか、PowerPointなのか、あるいはテキストなのか、メール本文なのか、形は都度異なりますが、資料化をしない仕事はないと言ってもいいかも知れません（実際には忙しくなって、中途半端に残るものも出てきますが、それでも後で思い出しては徐々に追加しています）。
資料はプロジェクト関係者の合意形成の土台になる、とても重要な資産です。ここで手を抜くと、後で必ず大失敗してしまいます。
私が見てきたプロジェクトでも、炎上や失敗してしまうプロジェクトのほとんどにおいて、とにかくこの『資料』が適切に作られていませんでした。
まったく作られていなかったり
最初に作って以降、一切改版されず、実体と食い違っていたり
プログラムから逆算すると、必要な定義や設計資料が不足したり
していて、「これでどうやって今のプログラムになったんだ…？」と言うものであったり、とにかく"例外なく"炎上しているプロジェクトでは、資料の適切性が保証されていません。
仮にそれっぽい資料があっても、合意形成の土台になっていなければ意味がありません。
では、「なぜビジュアル化した資料を作ることが大事なのか？」と言うと、下記の２つの現実が大きく関わっています。
・A. 人間は物事を忘れるし気が変わる
・B. 全体よりも細部に意識が行ってしまう
A. 人間は物事を忘れるし気が変わる
「えっ、何だそんなこと？」と思う人がいるかもしれませんが、これはとても重要なポイントです。"言った／言わない"で言い争う、醜い水掛け論はこれが原因で起きるからです。
私は、20代の後半に差し掛かった頃（27歳？28歳？）、初めて億越えのプロジェクトを任された時に、顧客の担当窓口の方とこの点で揉めることがありました。
以来、二度とこのような面倒くさい問題に巻き込まれることが無いよう、全てを記録化すると誓うようになりました。それから今まで何らかの形で記録（資料）を残すことは、私の中で常に最優先事項となったのです。
不確実な現実と戦うプロジェクトでは、この"人間の特性"を把握して対応することが大事です。特にプロジェクト最初期の要件定義フェーズでは
「まだ何もない状況で、後々の工程や実際のアプリやシステムに
大きな影響を与える判断をしないといけない」
という難しい問題があります。
また、アプリやシステム開発のプロジェクトでは短期間に数千万円や数億円、もしくはそれ以上の予算が動くことが通常で、責任の重さも通常の業務と比べて大きくなりがちです。
これをミーティングなどで「誰々が何々を決定した」という責任者の言質を取る形で進めてしまうと責任回避の心理が働いて「いつまで経っても物事が決まらない」とか、「肝心のポイントがあやふやなまま進む」などという、よくある要件定義の失敗に繋がってしまいます。
要件定義工程は、基本的にウォーターフォールでもプロトタイピングでも、スパイラルでも、ましてやアジャイル開発手法であっても、基本的に似たような進め方になります。要件がスコープを決め、スコープがスケジュールや予算を決めることになるからです。
スケジュールや予算が決まらなければ注文もできませんし、プロジェクトメンバーを集めることもできません。ですから、
①決められるものは全て決める
②決められなければ「いつまでに」「誰が」「何を」決めるのかを決める
は必ず行います。
①+②=100%となっていなくては、要件定義工程が正しく完了したとは言いません。もちろんそれでも、後々仕様の変更等が発生することはあるのでしょうが、実際に変更要求が無い範囲内において、100%検討が網羅されていなければなりません。
そして、これをせずにそのまま放置しておくとプロジェクトが進んで状況が変わったときに判断が変わり、要件変更や仕様変更に繋がってプロジェクトが大混乱するという悲惨な事態にもなりかねません。
また、「役職的にはシステムの要件を判断する立場にあるけど、実は IT には全然詳しくない」という人（残念ながら、日本企業ではむしろこれが普通です…）の判断を要件としてしまうと、要件定義に失敗してプロジェクト自体が失敗することにもなってしまいます。
これらの問題を回避するという意味でも、要件定義の際にプロジェクトリーダーは
個人ではなくチーム全体の合意形成の土台として資料をまとめていく
ことがとても大事なポイントになります。この際にビジュアル化した資料でわかりやすくまとめてあると、プロジェクトが進んだ後でも「なぜこの判断に至ったのか」の経緯を簡単に振り返ることができるため、混乱の予防策としてとても有効です。
資料をビジュアル化するときに重要なポイントになるのは、「関係者に理解しやすい形でまとめる」というところです。
たとえば、業務フローやユースケース図などをまとめる際に、UML などの「正しい書き方」があることが多いと思います。ですが、こうした正しい書き方で作成された資料はリテラシーを必要とするため、非専門家が理解しにくいという状態を生み出してしまうことにも繋がります。
よくあるパターンとしては、
「優秀な若者が正しい書き方で資料をまとめていて、
判断ポイントにも触れられているけど
偉い人がそれを読み取れずに流されてしまい、
後で要件がひっくり返ってしまった」
という事例を見かけます。資料はあくまでも関係者の合意形成を行うための土台となるものなので、あまり「正しい書き方」にはこだわっても意味がありません。
そうではなく、それらを理解した上で関係者のリテラシーや専門性のバックグラウンドを理解した上で「分かりやすい形」に落としていくよう意識することが良い結果につながります。
B. 全体よりも細部に意識が行ってしまう
要件定義や各設計工程の本質的な目的が理解できていないエンジニアや、頭の中でプログラムがすぐに組めてしまっている優秀なプログラマーの場合、要件の定義もそこそこに、さっさと具体的なアーキテクチャーや製造のあり方を言及する人がいます。
「日本語で書くより、プログラムで書いた方が早い」
と言って、設計を嫌うエンジニアもこの類です。
また、プロジェクトや新規事業の経験が少ない人が意思決定者にいる場合、要件定義の際に「今はまだそこに時間を割くべきではない」という部分に議論や意見が集中してしまうことがしばしば起こります。
よくあるパターンは、誰でも理解しやすいアプリケーションの機能やデザインに議論が集中した結果、システムアーキテクチャやユースケースの検討が進まず、実装の際に遅延や混乱を発生させて失敗してしまうケースです。
以前起きたセブンペイの「セキュリティ問題」はまさにそうした結果起きたものと言えます。
プロジェクト活動の中で最も重要で、最も貴重な資源は「時間」ですので、重要度の低い細部に議論が集中してしまうと、時間切れになって重要な要件が詰められないままプロジェクトが進んでしまい、スケジュール遅延から来る失敗の原因になってしまいます。
テキストで長々と文章化されていたり、行が連なっているスプレッドシートよりも、ビジュアル化した資料が優れている点は、「全体と部分の関係性」が分かりやすいところです。
あらかじめ検討しなければならない要件の全体像を示した上で、
「今はここを議論していて、プロジェクトチームとして
この部分の判断を意思決定しないと次に進めません」
と資料で示しておいて、さらにミーティングなどでアジェンダ（議題）として設定しておくことでこうした事態を防ぐことができるわけです。
個人的には、これができない人とはあまり一緒に仕事をしたくないですね。
管理・統制ができなくなるからですが、管理・統制ができなくなると、まず間違いなくマネジメントできなくなります。そうなれば、待っているのは炎上プロジェクトか、一方的に苦労を強いられるプロジェクトの２択しかありません。
変に細かいところにこだわっていて、話の大筋が締めくくれない会話をしていると、ストレスが溜まってしまってしょうがありません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。