変更とは
ここで言う変更とは、日常の営みや計画に対する全般的な変更を差します。
変更というからには、変更前が存在します。変更前の状態すなわち現状から何かを変更するという行為について、問題が発生しがちです。
変更を黙ってしてしまい、他の人が気づいておらず問題となる場合もありますし、変更を掛けた対象すなわち現状がそもそも間違っていたので、変更後の状態が間違いになってしまうという問題もあります。
変更マネジメントとは
変更マネジメントは、何らかの変更を加えることに対して、適切なマネジメントを行うことです。
変更前の状態から、変更後の状態になるためには、そのための計画が必要となり、その前のプロセスや計画から文字通り変更となります。
変更することが正しいことなのか、変更の計画が正しいか、変更の実行途中で問題は出ないか、変更後は想定どおりの変更になっているか、といった一連の行為を取り決め、正式に行うということになります。
正式に、というのは、自分ひとりで勝手に決めないで、関係者を含めて実行しましょうということになります。
変更マネジメントの方法
変更マネジメントは以下のステップにて行います。
- ①現状を整備し正式化する
- ②現状からの変更後の状態を定義する
- ③変更するための計画を立てる
- ④変更を実行する
- ⑤変更の実施途中で問題が発生していないかを確認する
- ⑥変更後の状態が問題ないかを確認する
- ⑦変更後を新たな現状として整備し正式化する
現状を整備し正式化する
変更にて最も大事なことは変更を確実に実施することではありません。変更前が正しいことです。
変更前が正しくないなどということが、起きうるでしょうか？
残念ながら変更前の現状が正しくないのは日常的に起きます。
ITにおいては、実態として動いている環境と、検証環境とがありますが、検証環境にあるべき最新版が実は古いということが起きてしまいます。
実態として古いものに対して変更し、実行したら想定していないものになってしまっています。結果トラブルが発生してしまうこととなります。
現状が正しいというのは当然のことのようではありますが、現状は実態として存在するものの、正しく管理されているかは別な話ですので、変更マネジメントの第1歩は現状の整備となります。
さらに正式化ということで、誰もが最新版を認識するという状態にしなければ、やはり誤りが起きます。
現状からの変更後の状態を定義する
変更を実施するにあたり、変更後を決めるということは比較的すぐにできます。
しかし、現状が正しく認識されていないがゆえに、変更が正しくないということが起きてしまいます。
したがって、現状を正しく認識したうえで、変更後の状態を正しく定義します。
現状が正しく見えていなかったり、頭の中だけにあったりしている状況であれば、形式化し正しく認識しましょう。
変更するための計画を立てる
現状を認識したら、変更後の将来像を描きます。そして次に行うことは、変更後の状態までの段取りを決めることです。
現状をもし粗くとらえていたら、段取りも粗くなってしまい、変更後の将来像に辿り着きません。
あるいは、現状の問題点を部分的にのみに捉えて、改善を行う変更を定義したとしたら、変更したことで別な問題を起こすような影響を出してしまうかもしれません。
また、変更を加える時に、特にITにおいては、いつでもできるというものではないことがあります。
日中は使われているので変更を加えられないとか、月1回の日曜夜の保守タイミングしか変更できないということはあります。タイミングが限られているということは、そのタイミングを逃さないために、分刻みの段取りが必要な時もあります。
すなわち将来像に向かうための全体計画と実行計画、変更の瞬間における計画といった段階的な計画をするということになります。
変更を実行する
変更の瞬間までの計画ができているのであれば、実行は計画どおりに実施すればいいだけのことです。
ただ、何時でも計画は完璧とは限りません。むしろ不完全さが潜んでいると思っていたほうがいいです。
変更が取り返しのつかないものであればあるほど、事前の計画の完璧さは言うまでもなく、重要です。なので、実行にリスクがあるのであれば、事前にシミュレーションやリハーサルと実施するということも行ったほうがいいでしょう。
変更の実施途中で問題が発生していないかを確認する
変更を行うにあたって、実行し始めたら取り返しがつかないことが多いですが、まだ取り返しがつかないところまでいっていないのであれば、引き返すことは可能です。
計画が完全ではないと考えるのと同時に、実行が正しく実行できているかどうかも、完璧ではないかもしれないという前提で、途中経過を確認していきましょう。
計画段階で、引き返し可能ポイントというものを決めておくことは有効です。同時に、どのように実行を計測するかも決めておくことが望ましいです。
そして、実際その時になった場合は、情報を拾って問題の有無を確認します。
問題があったら、その度合いを確認し、続行か引き返しかを見極めることも必要となります。
変更後の状態が問題ないかを確認する
変更が終わったら、終わった後を確認することは必須です。
実はこれが行われず、計画どおり実行できたのでOKとして解散してしまうということが起きます。
実行だけでなく、結果が正しくなっているかは、最終確認として計画の内にしておくべきでしょう。
問題のなさは、できれば実行計画やタイムスケジュールに対して正しくなっているかという視点ではなく、そもそも描いた変更後の将来像と合致しているかという観点で見ます。
実行後といういまさらのタイミングで、そもそも違うみたいなことがあっては困りますが、致命的なことが起きていないかは見るべきです。
さらには、実行後に新たな運用が開始された状態においても、確認は続けます。もし計画どおりであってもやっぱり目的を果たしていなかったなどということがあるかもしれません。
その際は再度チャレンジするのかなどを議論することになるでしょう。
変更後を新たな現状として整備し正式化する
最後にまた重要なことが待っています。それは変更後には新たな現状となるわけですから、現状を整備し正式化するということです。
それは始めにやったことですね、ということなのですが、本来のタイミングは変更を実行した直後です。ただし、これができていないことが起こりがちなので、始めにも実施すべきことなのです。
なぜ、このタイミングで整備ができていないのでしょうか。それは、変更を実行するというのは、急なタイミングであったり、大仕事であったりしますので、実行直後は終わったことの安心感により、仕事を終わらせてしまうからです。
さらに次の変更まで、例え次が何年後であろうと、先を見据えて行動することで、長期にわたる本当の安心感を得られるはずです。
ITシステム開発プロジェクトでの変更マネジメント
変更といっても意味が広くやや抽象的でしたので、2つの場面での変更を見てみましょう。
ITシステム開発プロジェクトにおいては、プロジェクトの工程別計画が立てられているはずです。
工程はプロジェクトにもよりますが、多くは要件定義を行い、設計、開発、テストと大括りには進みます。
各フェーズにて変更は発生しますが、要件もしくは設計への変更が主なものです。
テスト段階で要件変更が発覚したとしましょう。
工程の後ろのほうで、前の段階での不備が発覚したということで影響は大きいです。
まずやるべきことは、今定義されているはずの要件定義に基づいた設計および実装された仕様を確認します。
そして、変更すべきことを、影響を踏まえて明確にします。
そして、変更としてどのように実行していくかの計画を検討します。
いまは既にテストですので、今のテストにどのように合流するのか、それは可能なのかも含めて検討し計画することになります。
変更においては、その部分のテストを実施した上で、全体のテストに合流し、全体として正しいかを確認します。
そして、やはり重要なのは、変更を設計書などの正本に反映させるということです。
さらに変更が発生したら、誤った変更になってしまいます。
既存ITシステムでの改修におけるマネジメント
既存ITシステム改修は、まさに変更を行うことと同義です。
変更のステップに沿って実施していくことになりますが、最初のステップである現状の整備は非常に重要です。
ITのプログラム資産は正しく管理されていればいいですが、作業中に変更を入れなればならないことも多々あり、管理ミスの発生はよく起きます。
前のバージョンに戻ってしまうことで、改修したはずの仕様が消えていることもあります。
このようなミスを防ぐためのツールもありますので、効率的に管理できていることもあるでしょうが、やはり、そもそも最初に登録したものが誤っていれば、何をしても誤った結果にしかならないということになります。
改修においては、影響範囲を見極めることが定義を行ううえで重要です。
そのためには、現状を見極めたうえで、改修後の要件を定義し、特に要件として挙がっていなかった現行への影響部分についても、見極めた上で、将来像を策定します。
変更のための計画は、新たにITを導入するよりも難しい場合があります。というのは、既存ITがあるからです。
既存ITは既に利用されていますので、制約の中で変更を加える前提で計画を策定します。
変更の実行にあたっては、別な変更要求がないかを含めて、結果既存ITに影響する事象をすべて押さえたうえで対応します。
変更内容を本番へ実際切り替えるにあたっては、細心の注意を払います。
ITの変更はある意味簡単にできてしまいます。最後にテストしたのに、いつの間にかまた変わっているなんてことも起きます。
ですので、テストやリハーサル時に最終バージョンを確認し、確実に切り替えに反映します。
変更後は、想定どおりとなっているかを本番にて確認します。本番で確認することが困難な場合もありますので、結果確認をどうするかはそのあたりも計画しておきます。
そして、振り出しに戻り、変更後を新たな現状として正式化します。
変更マネジメントでのありがちな問題
変更のステップの中で説明してきたとおり、変更は各タイミングでリスクが潜んでいます。綿密に計画したとしてもやはり問題は出てきてしまいます。ありがちな問題を見てみましょう。
変更前の状態がそもそも正しくない
変更前の現状が正しくないために、変更をしても正しい変更後にならないというのは、これまでも説明してきたとおりです。
変更前後の切り替えが簡単に考えられている
変更にあたっては、変更後の状態に注目して進められがちです。
ITの画面上の操作にしても、ユーザ利便性を考えて、先に入力候補リストが出たほうがいいという変更後の要求があったとします。
言うのは簡単なのですが、ITの現状の作りが要求に応じやすいかどうかは別です。
要求としてはいち早くやりたいので、とっとと切り替えてと言われるかもしれません。しかし候補リストを作成するには、もう一つの画面にも影響してしまうかもしれません。
その場合、ただ単にその画面を切り替えれば済むのではなく、全体機能の切り替えになってしまう時もあります。
そうなってくると改修を進めるだけでなく、切り替えの難易度も上がります。
しかし、機能への要求は考えていても、切り替えの難易度を検討していないようなことは、実際はよく起きてしまいます。
実は一日ではできない作業量だったというようなことも起きたりします。
変更がいつのまにか勝手にされている
現状が正しく最新になっていないという問題はよくあると説明しましたが、この原因の一つとして勝手に変更されているということがあります。
勝手に変更されるというのは、変更マネジメントが浸透していないことも原因としてありますが、意図せず起こしてしまうこともあります。
一人で実施している作業であれば、自分がわかっているから問題ないとして作業を進めているかもしれませんが、自分自身が実は途中で間違っていることもあります。よって一人であっても、変更前から変更後へのステップは無視できないということになります。
そもそも違っていたということが発覚する
現状が正しいと認識されているものに対して変更を進めていましたが、正しいと思われている現状が実は違っていたということがあります。
違っていたというのは、ある時点で正しいと判断したのでしょうが、実はそもそもの目的から考えると違っているということです。
変更を加える際には、現状を分析しなおしたりしますが、その際に改めて気づくということが多いです。
これは問題と言えば問題ですが、潜んでいた問題を顕在化し、改善に向けることができることなので、前進したとも言えます。
引き返せない状況となっている
変更は現状を変える行為です。よって現状をある意味壊してしまうことになります。
壊しても変更が正しく反映すれば問題はありません。しかし、変更が万が一うまくいかなければ、現状と変更後の両方を失うこととなります。
うまくいかないことはあり得ることとして、考えるべきです。そうしないと現状が壊れたままになってしまいます。
なので、変更を少しずつ進めて、引き返せる状態を認識しつつ、もしうまくいかないことがあったら引き返せるように計画が必要です。
引き返すには、引き返す時間も必要なので、確保したうえで、変更を実行します。
全部を一斉に変更はできなかった
変更するものは一つでないことはあります。変更と一言で言葉では言えても、実物は100個くらいのこともありえます。
PCが100台あってすべてを変更するようなことです。
このような時は、もちろん100台の変更をする計画にしないといけません。しかし、何らかの理由で、80台しかできないなどということも起きなくはありません。
80台の状態でタイムリミットとなってしまったらどうなるでしょう。
20台は後から変更すれば問題ないのであればいいのですが、80と20という中途半端な状態は許されないということもあります。
そうであれば、すべてがやりきれる、としてうまくいかないものがでてきたら、引き返すことも予め考えおかないといけないということです。
想像もしていなかったことが影響して変更できない
ソフトウェアのバージョンアップ作業をメーカーから言われて行うことはあるでしょう。
バージョンアップはもちろんよくするために行うのですから、よいことは起きても基本的に問題は起きないはずです。
しかし、よいことをしたはずが、予期せぬ問題が起きてしまうことがあります。
ある機能は改善されたとしても、別な機能がやらなくてもいい改善をしているかもしれません。それにより現状動いていたものが動かなくなることもあります。
ソフトウェアはブラックボックスですので、何が起きるかわかりません。メーカーも説明しきれるとは限りません。
リスクはあるという計画にしておいたほうが無難です。
変更マネジメントで本当にすべきこと
起こりがちな問題としても説明してきましたが、変更というのは多大なリスクがあると思っていたほうがいいということになります。
変更はある意味改善なので、前向きに行うべきことです。しかし、後ろ向きになってはしまいますが、リスクを過小評価していないかと注意しましょう。
確実に引き返せる計画を
引き返せないのは、最も問題です。変更がうまくいかなくても最悪現状に戻りたいです。
変更前の状態をキープするという意味で、バックアップいながら進める計画としましょう。
変更の切り替えに想像力を働かせて
変更前の状態に変更を加えて、ある時にスパッと入れ替えるということを計画しがちです。というのは、変更前に一部変更を加えるほうが楽だからです。
しかしそのようにすんなり切り替えられるケースばかりではありません。
変更を加えた後は、多くの関係者に影響する可能性もあります。つまり、変更後を待ちわびていた人もいれば、まだ変更しないで欲しいという人もいるという併存状態になっていることもあるということです。
このあたりは想像力を働かせて、変更後状態を考えないといけません。
変更前に変更を加えるというやり方だけでなく、変更前は残しておいて変更後を一定期間併存するというやり方も検討に加えましょう。
危険度に応じた計画の保険を
変更は場合によっては非常に短期間に実行されます。そのような時であっても、計画を考えないのは危険です。
ここまで説明してきたとおり、変更にはリスクがあり、時には想定外なことも起きます。
もちろん危険度合にもよりますが、引き返せることを計画に含めて綿密に計画するのと同時に、何か起きてしまった時のための、計画の保険も準備しておきましょう。
コメント