[基幹システム刷新PJT-05] PJT立ち上げ前_「こうするとOKになる」を示す_②シンプルに構造化する
※前回内容：適切に言語化する。
「こうなるとNGだよ」しか伝えないと良い感じにならない。雰囲気が悪くなる。「アレはダメ」「コレもダメ」ばかりでは上手く行かない。
「こうするとOKになる」という明るい未来を伝えることも必要だ。
運用設計の考え方をベースに、システム化する際に必要となる要素を３つに分けて経営とPJTメンバーに共有した。
「運用設計」に出会ったキッカケは忘れたが、出会った時に「これ、デジタル化する時の考え方に転用できる！」と思って、パクらせて頂いた。「こうならないために、こうしていこう！」と伝える際の【言語化】に、大いに役立った。またPJTを進める上での自分への戒めになった。
※「運用設計」自体については、深く理解できていない。お恥ずかしい限りだ。
経営とPJTメンバーに共有した「システム化する際に必要となる３つの要素」は下記。
①適切に言語化する（人が理解できるようにする）
②シンプルに構造化する（システムが業務を扱いやすいようにする）
③ドキュメント化（論理的に正しいことを検証できるようにする）
この記事は ②シンプルに構造化する（システムが業務を扱いやすいようにする） について。
②シンプルに構造化する（システムが業務を扱いやすいようにする）
シンプルに構造化しないと何が起こるのか？
例えば、業務をシンプルに構造化しないでシステム化しようとすると何が起こるのか？
適切に【言語化】しようと思っても、複雑すぎて言語化できない。他人は内容を捉えられず、要件のムリやモレに繋がる。
複雑化したままシステム化をしようとすると、費用がかさむ（カスタマイズが代表格）。
システム化しないで運用でカバーするにしても、シンプルではないので運用そのものがムリがある状態になる。その人が感覚的にやっている業務となってしまい、他のヒトが代替するにしてもムリがある状態になってしまう（属人化）。
だから、シンプルに構造化する。
システム化できるのは「平易な業務」のみなのだ。
「平易な業務」に落とし込めていない業務は、システムに落とし込めない。可能な限り「平易な業務」に再構築して、ヒトが楽になっていくように目指すべし。システムの考え方に合理性があれば、業務側を見直す。
システムにはそのシステムの考えがある（基幹システムは特に）。長年の経験から最もベストなフローが体現されたのがパッケージシステムだ。その考え方を理解して、みんなが納得いく内容であれば、自分たちの業務をシステムのやり方に落とし込んでいくべし。業務がずっとシンプルになる。ヒトがやった方が良い内容は、ヒトに任せる。
「平易な業務」に落とし込めず、システムのやり方にも代替できない業務があるならば、ヒトがやるしか方法はないことを理解すべし。また、その際に「そこまでして拘って今後もずっとやり続ける価値のある内容かどうか」を現場部門長や経営が判断すべし。「拘る内容ではない」「価値がない」業務なら、思い切ってシステムの考えに乗ってもらうべし。シンプルに構造化できない時の最終奥義は「金で解決」。
パッケージシステムに自社独自の考えを無理やり注入する。ただ、カスタマイズは追加費用が発生する。その費用分の価値があるのかどうかを ”判断してもらう” べし（後日詳細）。
シンプルに構造化できれば、システム化がずっと簡単になる。
システムの考えに乗る部分が多くなればなるほど、良いこともある。
うまく言語化できないまま要件定義が進み、定義モレがあったとしても安心なのだ。パッケージシステムなら、細かい部分も含めて構造化されているので、定義モレがあってもシステムがカバーしてくれる。
逆に、複雑なままでシステムの考えに則っていないと大変だ。カスタマイズやスクラッチが一番分かりやすい。
定義モレが発覚した際、システムはそのモレをカバーしてくれないのだ。追加開発が必要になってデスマーチが始まってしまう。
システムは「ヒトが面倒くさいと思っている業務」を全部肩代わりしてくれるわけではない。「ヒトがシンプルに構造化した業務」しか肩代わりしてくれない。
ヒトが業務を「平易な業務」に構造化することもせず、「複雑な業務」をヒトがしないなら、ヒトはきっと不要だ（極論）。
【参考】
運用設計ラボ 波田野 裕一 さんの資料。
運用設計についての資料なんだけど、「属人化」とか「マネジメント」とかにも関連するような内容も多い。スライドは256ページあるんだけど、内容がしっくり来る（グサグサ来る）。「システム化する際に必要となる３つの要素」は下記内容を参考にさせて頂いた。
