【変更管理⑤】進行状況モニタリング

手続き型業務には必ず「いま、何の作業しているところ？」と言う、状況…ステータスが管理されていないと、抜け漏れが発生してとんでもない事態に発展してしまうかもしれません。

ＩＴ企業にいらっしゃるエンジニアであれば、いわゆる業務系・管理系のシステムを作成する場合、否応なく「状態」「状況」「ステータス」の遷移を管理するようなシステムを構築しているはずです。

むしろ、その「状態」「状況」「ステータス」を軸にして、すべての機能が設計されているのではないでしょうか。

そして、それは支援業務としての変更管理でも同じことが言えます。

変更管理と言うくらいなので、何かしらの「状態」「状況」「ステータス」を管理しています。そして何かしらとは、変更依頼の状況であったり、現時点での変更依頼状況の進捗状態などを管理しているわけですね。

こういった状態の遷移を管理するような場合、まずはどんな「状態」があるのかを洗い出し、そしてそれらの点を線にし、抜け漏れが無いことや関係性に齟齬が無いことを確認します。最後に、「状態」が遷移する条件を整理すれば、業務の、あるいはシステムの軸となる仕様の完成です。

それを実現するダイアグラムが、ステートマシン図（ステートチャート、状態遷移図）です。

たとえば、今回の変更管理であればざっくり書いてみると…

こんな感じでしょうか。

①〔変更依頼〕を作成し、変更管理委員会が受理し、
　識別を付与した時点で【依頼】と言う状態になる。
②変更管理委員会にて、影響調査や変更内容の妥当性検証を始めると、
　【調査】と言う状態に遷移する。
③調査が完了し、変更が許可されると【依頼承認】。
　ここで却下されると【終結】と言う状態に遷移する。
④依頼承認されれば、〔変更依頼〕内容に従って、
　対象成果物に変更を加える。この間、【対策】に遷移する。
　　　・
　　　・
　　　・

まだ、①までしか説明していないので、この辺で割愛しますが、このように状態が遷移していくわけですね。

何事もそうですが、新しく計画を立てて有期的な活動を開始する場合…つまりは期限にスタートとエンドが決められている活動を行う場合は、限られた時間内で求められた成果を出さなければなりませんので、確実な管理が求められます。

そういった場合は、このように「状態」の定義と、その「状態」が遷移する条件を定義し、

　どうなったら（何をしたら）、状態が遷移するのか？
　どんな状態を定義しておくと、管理しやすくなるのか？

と言った点を考慮しておくと、マネジメント業務が非常に楽になるでしょう。逆に、こうした基準を決めずに「なんとなく」、「経験則で」管理しようとすると、必ず苦労することになります。なぜなら、状況や状態を把握する人間によって、何に重きを置いているのかが異なるために、報告などでも一貫性が無く、報告者とそれを聞く者との間でコミュニケーション・ギャップが発生してしまうからです。

　「だいたい終わりました」
　「もうすぐ終わります」
　「いい感じです」

と言ったアバウトな表現が許された現場では、顕著にあらわれるのではないでしょうか。

　「変更依頼が２件発生しました。
　　うち１件は明日中が回答期限となっています。」
　「変更依頼が却下され、終結１件となりました。」

と言ったように、あらかじめ手続きのルールや基準を決めておくと、正確な情報伝達が可能になるんですね。と言うか、むしろこれくらいしっかり決めた業務になっていないと、システム化（ＩＴ化）するのは無理です。コンピューターにアバウトで属人的な管理なんて不可能ですからね。