[基幹システム刷新PJT-04] PJT立ち上げ前_「こうするとOKになる」を示す_①適切に言語化する
※前回内容
「こうなるとNGだよ」しか伝えないと良い感じにならない。雰囲気が悪くなる。「アレはダメ」「コレもダメ」ばかりでは上手く行かない。
「こうするとOKになる」という明るい未来を伝えることも必要だ。
運用設計の考え方をベースに、システム化する際に必要となる要素を３つに分けて経営とPJTメンバーに共有した。
「運用設計」に出会ったキッカケは忘れたが、出会った時に「これ、デジタル化する時の考え方に転用できる！」と思って、パクらせて頂いた。「こうならないために、こうしていこう！」と伝える際の【言語化】に、大いに役立った。またPJTを進める上での自分への戒めになった。
※「運用設計」自体については、深く理解できていない。お恥ずかしい限りだ。
経営とPJTメンバーに共有した「システム化する際に必要となる３つの要素」は下記。
①適切に言語化する（人が理解できるようにする）
②シンプルに構造化する（システムが業務を扱いやすいようにする）
③ドキュメント化（論理的に正しいことを検証できるようにする）
この記事は ①適切に言語化する（人が理解できるようにする） について。
①適切に言語化する（人が理解できるようにする）
言語化しないと何が起こるのか？
例えば「現行業務」とか「システムへの要望」とかを適切に言語化しないと、何が起こるのか？
「今やっている業務」の捉え方が人によってバラける。
システム導入では自社だけではなく、システム会社も参加することがある。自社内ですら「今やっている業務」の認識を合わせられないなら、システム会社はもっと認識が合わない。
この状態で進んでいくと、、、システム導入時に「要望通りになってない！」と怒りが現れる。
現場からすると「期待していたのに！」という状態。で、最悪そのシステムは使われずにゴミとなる。現場はEXCELとか紙を活用し始める（日常業務を問題なく回すために）。
「言わなくても分かるでしょ？」「これは当たり前でしょ？」みたいな感じで進んでいくと、上記のような結果になると思っている。
また話しづらい内容があった時に言語化から逃げると、上記のような結果になると思っている。「面倒なことになりそうだし、この内容は深く入り込まないほうが良いかな…」「何度も質問してクドいかな？」とこっちから言語化から逃げるようなことをしてしまうと、結果は地獄だ（因果応報ってやつか）。
だから適切に言語化をする。
※この内容については、皆結構納得してくれた。なぜなら「新システムでは出来ると聞いていた」「あの人が出来ると言っていたのに、結局出来なかった」という経験が既にあったからだ。
システム担当者やベンダーが事細かく質問することを事前に理解してもらった。「嫌がらないでね。後で こうじゃない！ とか こう思ってたのに！ みたいになりたくないから協力して欲しい。」と伝えた。
逆に「やり過ぎなくらいにシステム担当者やベンダーに事細かく要求して欲しい。当然すぎる内容でも アレ？ と思ったら、事細かく確認してもらった構わない。遠慮が原因でシステム化が失敗することもあるから、遠慮は不要です。というか、遠慮は罪です。」とも伝えた（ベンダーは嫌がるだろうけど。。。）。
お互いにこの認識があるので「ちょっと確認したいんだけど」と誰かが言っても嫌な雰囲気にならなかった。我儘な人は滅多に居ないので、俺様態度で質問したり要望を言う人も滅多に居なかった（完全に居ないとは言えないのが残念。
言語化から逃げたくなることもあるけど、言語化から逃げると「相手への甘え」「自分への妥協」となって、結局は良い結果にならない、、気がする。基幹業務の現状とか要望を「察する」なんて無理だ。
言語化から逃げちゃダメだ。
【参考】
運用設計ラボ 波田野 裕一 さんの資料。
運用設計についての資料なんだけど、「属人化」とか「マネジメント」とかにも関連するような内容も多い。スライドは256ページあるんだけど、内容がしっくり来る（グサグサ来る）。「システム化する際に必要となる３つの要素」は下記内容を参考にさせて頂いた。
※リンク ： OpsLab.jp 発表資料 2019-05-20 運用業務の設計思想
この記事が気に入ったらサポートをしてみませんか？