[基幹システム刷新PJT-06] PJT立ち上げ前_「こうするとOKになる」を示す_③ドキュメント化（論理的に正しいことを検証できるようにする）
※前回内容：シンプルに構造化する。
「こうなるとNGだよ」しか伝えないと良い感じにならない。雰囲気が悪くなる。「アレはダメ」「コレもダメ」ばかりでは上手く行かない。
「こうするとOKになる」という明るい未来を伝えることも必要だ。
運用設計の考え方をベースに、システム化する際に必要となる要素を３つに分けて経営とPJTメンバーに共有した。
「運用設計」に出会ったキッカケは忘れたが、出会った時に「これ、デジタル化する時の考え方に転用できる！」と思って、パクらせて頂いた。「こうならないために、こうしていこう！」と伝える際の【言語化】に、大いに役立った。またPJTを進める上での自分への戒めになった。
※「運用設計」自体については、深く理解できていない。お恥ずかしい限りだ。
経営とPJTメンバーに共有した「システム化する際に必要となる３つの要素」は下記。
①適切に言語化する（人が理解できるようにする）
②シンプルに構造化する（システムが業務を扱いやすいようにする）
③ドキュメント化（論理的に正しいことを検証できるようにする）
この記事は ③ドキュメント化（論理的に正しいことを検証できるようにする） について。
③ドキュメント化（論理的に正しいことを検証できるようにする）
ドキュメント化しないと何が起こるのか？
戦争が起こります。遺恨が残ります。
「声がデカイ」「態度がデカイ」「役職が上」などの人の意見や分析が無条件で正しいとされるようになる。
「声が小さい」「謙虚」「役職が下」などの人の意見や分析が例え正しくても、その内容は会議では表に出てこれない。「アレってどうなったんだっけ？」が発生する。
しかも、回答がみんなバラける。
で、みんな自分に有利になるような解釈をし始める。
で、言い争いが勃発する。PLとかPMOも記憶頼みになる。
で、自分に有利になるような解釈をし始める。
で、現場から恨まれ始める。
（協力ベンダーも同様。）「いつまでに、だれが、何をする」も曖昧に。
タスク発生時点では皆同意したのに、時間とともに何故かみんな自分に有利になるような解釈をし始める。
で、「私はこう思ってた」が始まる。
これらのスレ違いはPJTが進むにつれてキツくなってくる。
自分を含めたみんなが「自分は正しい」と思ってることが厄介。
だから、ドキュメント化する。
ドキュメント化する目的は大きく２つ。
みんなで検証できるようにするため。
口頭ではなくドキュメントを元に議論や分析を進めることで、「感覚的」になったり「主観的」になったりすることを防ぐ。
「声がデカイ」「態度がデカイ」「役職が上」などの人の意見だったとしても、ドキュメントを元に分析を進めると「これ違くない？」「それ論理的ではなくない？」とか気づきやすいし、言いやすい。
因みにこれで私自身が私自身の間違いに気付くこともできた。ドキュメント内容は他部署も閲覧するわけだから、「完全に主観的な意見」を主張することは控えるようになる。
記録しておくため。全員の認識を一致させるため。
議事録は残す。
PJTに限らず当たり前のことなんだけど、中々難しい。
特にPM/PL/PMOを1人が兼任とかしていると、なかなか時間が取れない。けど、議事録が残っていないと後々戦争になったり遺恨が残ったりするので、嫌でも残した方が良い。ドキュメントに対する全員の合意を残す。
打合せで使った資料も議事録も、全て参加者に確認してもらい、間違いがないことを同意してもらうこと。「自分のノートにはこう書いてあります」では無意味。
あとで「記載内容が間違っている」となる内容もあるだろうが、それはそれで良い。重要なのは「その時は間違いが無いことに同意した」ということが残っていること。
残っていないと「そんな内容知らない」とか「内容が間違っている！あなたが何とかリカバリして！！」となりやすい。
しかし残っていると「十分に確認してなかったんだけど..」「こういう意味ではなかったんだけど..」と、感情的な口論を避けられる可能性が高まる（※可能性がゼロにならないのが残念だ…）。
【参考】
運用設計ラボ 波田野 裕一 さんの資料。
運用設計についての資料なんだけど、「属人化」とか「マネジメント」とかにも関連するような内容も多い。スライドは256ページあるんだけど、内容がしっくり来る（グサグサ来る）。「システム化する際に必要となる３つの要素」は下記内容を参考にさせて頂いた。
