こんにちは。いちおか＠問題解決サポーターKAIOS代表です。

問題解決あるあるコラム第6回のテーマは、「変更管理」です。変更管理と言えば4Mですね。最近では5M、6Mとどんどん数が増えて行き、「いったいどんだけ管理すりゃいいのさ！」といいたくなります。でも、ふり返って問題の原因を辿っていくと、大抵これらMの管理不行き届きに原因があるので仕方ないですね。最近は世の中の変化が激しいので、第五のM「Mother nature（環境）」の影響度が大変大きくなって来ています。みなさんお馴染みの7step FMEAでも5M影響分析が欠かせません。堪りませんね。

変更管理を機能不全に陥れる魔法の言葉

でも、逆に言えばこの５Mをしっかり見張っていれば大抵の問題は防げる事になります。ところが、ここにも例によって我々人間の悪いクセが出てきてしまいます。変更管理を機能不全に陥れるパワーワード「キャリーオーバー」です。全ての面倒くさいプロセスをスキップ出来る（と思っている）魔法の言葉です。この「キャリーオーバー」という言葉ひとつで全ての潜在リスクを過小評価することが出来、多くの確認作業を省くことを正当化出来る、多くの技術者にとって救いの神の様な言葉です。…でも、結局は救ってくれないんですけどね。

キャリーオーバーは何も変わっていない？

確かにキャリーオーバーですので、モノ自体は何も変わっていません。既に市場実績があれば、何も変わっていないのですから、何も心配することはありません。従ってことさら心配してわざわざ仕事を増やす必要もないでしょう。…でもそれってホントでしょうか？ひとつ忘れていますよね、そう、五つ目のM＝環境は変わっています。世の中は常にダイナミックに変化しています。キャリーオーバーしたものを開発していた時と今とでは様々な環境の変化が生じています。この変化は、当時では想定も想像も出来なかった事が沢山あります。なのに、その変化に目を向けずキャリーオーバーでプロセスを進め、いざ問題が発生するとお決まりのあのフレーズが出てきます。「気が付かなかった」「今ままでのままで大丈夫だと思っていた」じゃあ、この後どうするの？「次から気をつけます」「次回の確認リストに追加します」そうして次にそのリストをレビューしても、その時にはまた環境変化が生まれています。

どうしても早く前に進みたい

こうして永遠のイタチごっこリストが作り上げられて行きます。是正しなければならないのは、「その時の環境変化の影響を考える」というステップが抜けてしまっている「仕事の仕方＝プロセス」です。入り口でしっかり準備をすれば、後がうんと楽なのに、我々人間はどうしても「早く先に進みたい」という衝動に勝てず、目の前のゲートをどんな形でもいいので通過しようとしてしまいます。「怪しいものを発見して止める」のが目的のゲートを、「ゴールにたどり着く為のただの通過点」にしてしまっているのです。第3回のテーマでも出てきた「やったからいいでしょ」というKGIで行動してしまっているのです。ゲートでのチェック項目が、「レビューをした事」になってしまい、本来の目的である「レビューでリスクをみつける」という事が忘れられてしまっているのです。例えば、レビューで見つけたリスクの数をKPIにして、開発の進捗毎に発見したリスクの数を見ていくとレビューの有効性が確認できるかもしれませんね。

リスクの過小評価という最大のリスク

いかがでしょうか？みなさんがあまり好きではない変更管理システムは、実はこの様にリスクの過小評価を防ぎ、限られたリソースを本来注ぎ込みたい製品開発に集中させ、効果的かつ効率的に進めるために考えられた仕組みなのです。ところが我々は「管理」されることを嫌い、自ら「リスクの過小評価」という「最大のリスク」を生み出しながらイシューの中に飛び込んで行ってしまっているのです。交通の激しい幹線道路に右も左も見ずに飛び出す様なものですね。

キャリーオーバーはリスクもキャリーオーバー

変更管理は本気でやろうと思うとキリがないですが、かといってスキップする訳には行きません。しっかり影響を評価し、どこまでならリスクを許容出来るのか考えた上で、対応する範囲を決めて実施する必要があります。「キャリーオーバー」と言って変更を最小化しようとする行為は、リスクもキャリーオーバーしていることを良く理解する必要があります。

まとめ

変更管理は奥が深いです。でも、未来の問題を防ぎたければ、変更管理としっかり向き合う事が実はタイパもコスパも最適化出来る最高の手段となります。
いかがでしたか？少しは変更管理が好きになれそうですか？「最初に面倒くさい」のと、「後ですんごい面倒くさい」のとどちらを選ぶかは、我々次第なのです。

今回も最後までお読み頂きありがとうございました。
それでは、また次回もお楽しみに！