変更管理プロセスが弱いとトラブルが多い

以前、ITILの研修を受けた時、講師から「変更管理プロセスが弱いとトラブルが多い 」という話を聞いて、非常に心に残った。

【1】ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
例えば、OSやソフトのバージョンアップ、システム移行、マイグレーションなど。

つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
このギャップがトラブルだ、と。

だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
そこに矛盾がある、と。

【2】ITシステムは変化があって当然だし、その変化を受け入れて、その変化をコントロールする技術を持つことが重要だ。
その技術が、変更管理プロセスであり、構成管理プロセスであったりすると考える。

つまり、プログラミングやモデリングそのものに問題があるわけではない。
それら技術の進化が激しく、5年も経てば老朽化が当たり前で、5年おきにリプレースしてシステム移行だけでなく業務移行も伴う。
そういう変化をコントロールする術をあなたは持っていますか？と問われている気がする。

ITILはそういう変更管理プロセスに着目した考え方だと思う。

僕は、そういう変化をコントロールできる開発基盤として、Redmine＋Gitが必要ではないか、と考えている。
そのアイデアも膨らましてみる。

変更管理の基盤は構成管理が支えている: プログラマの思索

XDDPと言う派生開発: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない: プログラマの思索