このエントリーをはてなブックマークに追加LINEで送る

13.1. プロジェクトにおける変更管理への認識

ハッピィ・エンジニアリング表紙

 変更管理というのは、プロジェクト管理の中でももっとも難しいプロセスのひとつである。なぜなら、変更管理というのは独立した問題ではなく、プロジェクトのあらゆる側面が正しく構成されていなければ行うことができないものだからだ。

 

 変更管理を行うためには構成管理が行われていなければならず、構成管理を行うためには要求ベースラインがしっかりしていなければならず、要求ベースラインを正しく作成するためにはプロジェクトの変更承認プロセスが明確化されていなければならない、といったように、変更管理というものは、本書で述べてきたすべての領域で問題が解消されて初めて達成できるのである。

 

 そもそも、開発プロジェクトで成果物として「高い品質」が要求されるのは当然である。「品質」という言葉には、当然ながら一貫性や整合性も含まれる。成果物、例えばソースコードとドキュメントの間の整合性が取れていなければ、それは「品質が低い」のである。開発プロジェクトは、さまざまな状況の変化によって変化し続けるものであり、変更がない開発プロジェクトというものはあり得ない。本来であれば、こうした変化をコントロールすることが求められるが、現実には変更状況の把握すらできていないプロジェクトが多数ある。

 

 つまり、現状では、変更管理の難しさと重要さが正しく理解されているとは言い難い。その原因の多くは、変更管理に対する軽視・誤解・手抜きなどによる。

 

変更管理に対する軽視

 結局のところ、ここでもユーザ企業とSIベンダ、そして連鎖する下請けに至るまでの「甘えと癒着」の構造がある。その結果として、前述した例のような

 

  • 変更に対する権限を適切に設定していない
  • 指揮命令系統が複数発生する

 

という、混乱を生むだけの、無責任な仕事の進め方をしてしまうのである。

 

 権限のない人間同士が、勝手に変更の指示と受け入れを行っている。そのまま作業を進めてしまうと、変更通知が徹底されない。ユーザ企業・SIベンダを問わず、必ず「俺は聞いていなかった」と言い出す人間が出てくる。さらには、冒頭の例でユーザ企業のシステム部門とプログラマがPHS番号をはじくような機能を作ってしまったように、要求されてもいない機能(金メッキ)を勝手に作り出すといった事態に陥る。

 

 「3.1 利害の対立」で記述したように、本来、発注側は、経営戦略に基づいてさまざまな部門戦略を持つが、それを実現する手段のひとつとしてシステム戦略がある。システム戦略を実現するためにプロジェクトが存在するのである。したがって、ユーザ企業は、システム戦略よりも上位の戦略から発生する業務要件を規定し、それをSIベンダ側に示すべきである。

 

 しかし、ユーザ企業側ですら、上記のようなプロセスに従って業務要件を決めているとはいえない状況である。ましてや、変更要求が経営戦略からくる経営側の要求なのか、あるいはエンドユーザやシステム担当者の「趣味的な」問題なのかの判断すらなされていない。さらにSIベンダ側は成果物の一貫性や整合性を維持し、度重なる変更を追跡できる状態では管理していない。つまり、そもそもの問題は、変更承認プロセスと変更管理プロセスが不明確なことにある。

 

 上述のストーリーと同様に、ユーザ企業側で要件の調整と、合理的判断による意思決定が行われていない。その上で、結果責任のみをSIベンダに押しつけている。SIベンダ側でも、さまざまなメンバが変更要求を受け入れ、そして関係するチームとの共通認識を持たないままに変更への対応を進めてしまっている。

 

 変更承認プロセスと変更管理プロセスは、プロジェクトの利害関係者の役割と責任を明確にするものである。これが不明確なままにプロジェクトを進めることは、誰もが無責任に仕事をしているのと同じことである。変更承認プロセスと変更管理プロセスは、明確に定義し、利害関係者全員が厳守する必要がある。

 

変更管理に対する誤解

 典型的な誤解が、変更履歴ツールを導入すれば変更管理ができる、というものだ。昨今の変更履歴ツールは、ソースコードだけでなく、ワープロ文書やプレゼンテーション資料といったバイナリファイルの差分を管理できるものも多い。また、チーム連係機能も充実しているので、成果物管理に使えばそれなりに便利なものであることは確かだ。しかし、変更履歴が取れるだけでは意味がない。さらに、変更管理ツールに登録する際に入力するコメントのみで変更を管理しているつもりになっている技術者も多い。変更管理ツールに入力するコメントは、そのツールを利用していないメンバは参照できず、変更履歴と呼ぶには不十分である。変更履歴として必要なのは、

 

  • どのような必要性があり、変更が発生したのか
  • 既存のどの要件に対する変更なのか
  • その変更により、どのような設計変更が発生したのか
  • どのプログラムを修正すれば、変更要求を満たせるのか

 

というようなことである。これらが、一貫性を持って記録されていなければならない。

 

 変更管理は、構成管理と混同されることも多い。構成管理もプロジェクトの重要なプロセスのひとつであるが、構成管理を実施しているからといって変更管理を行っていることにはならない。むしろ、構成管理は変更管理の一部分としてとらえることが重要だ。

 

 構成管理とは、簡単にいうと「プロジェクトの静的な状態を把握する」プロセスのことで、プロジェクトの動的な状態を把握する「スケジューリング」や「モニタリング」と対をなすものである。プロジェクトの静的な状態とは、

 

  • 要求と成果物の対応関係
  • 成果物間の依存関係
  • 成果物間の整合性
  • 成果物の完了率
  • 成果物を生み出すのに要したコスト

 

といった事柄である。こういった情報を適切に管理・更新していかなければならないが、その場合に重要になるのが変更管理だ。状態の変更を管理していなければ、「プロジェクトの現在の状態」がわからなくなってしまう。構成管理を適切に行うには、必然的に変更管理を適切に行わなければならないのだが、その目的は変更管理とは異なることに注意してもらいたい。

 

変更管理に対する手抜き

 きちんとした変更管理は労力が多い。さらに、正しいプロセスを順守しようとすると、余計な待ち時間が必要となる。そこで、変更管理に対する手抜きや形骸化が発生する。

 

 さらに、変更管理自体が生産性のある業務ではないために、「プロジェクトの雑用」と位置づけてしまっている。変更管理そのものをSIベンダに丸投げしてしまう。そのような場合には、SIベンダのプロジェクトリーダが片手間に変更管理者を兼任していたり、経験の少ないメンバの当面の仕事として割り当てられたりする。

 

 SIベンダに変更管理を任せてしまうことによる弊害は多い。変更管理や構成管理は、政治力をも含めた高度な判断力が要求されるマネジメント業務である。変更の受け入れ可否を判断するということは、成果物のリリース可否を判断することと同義であり、ユーザ企業とSIベンダで役割を分担するならまだしも、そもそもSIベンダに丸投げしてはならない業務である。ましてや、そのような判断を新人メンバに任せたり、プロジェクトリーダの片手間で行ったりしてはならない。

 

 特に、プロジェクトの最初期段階では、未確定項目が多いため、ユーザ企業内で周知されていない変更要求が、SIベンダに気軽に提示され、SIベンダ側も気軽に受けてしまう。これでは、ユーザ企業ですら、正確なシステム要件が何なのかという共通認識を持つことができない状態になってしまう。だからこそ、変更管理は、ユーザ企業とSIベンダの両者が関わるべき作業なのである。特に「変更の承認」には、ユーザ企業が、経営戦略や部門戦略の観点で、その変更が本当に必要なのかを判断し、SIベンダが変更を実施する上で
技術面・計画面での実現性を判断する必要がある。最終的な「変更の承認」は両者の協力なしには成立しない。

 

 さらに、変更管理をSIベンダに丸投げすることで、SIベンダが変更をコントロールすることになってしまう。前述したように、なんら合理性のない変更要求をSIベンダ側が安易に無批判で受け入れてしまったり、あるいは作業工数やスケジュールを盾に変更を拒否したりするようなことが起こる。

 

 現在の日本では、ITガバナンスに対する意識が希薄であるため、各システムがブラックボックス化してしまい、コストもスケジュールもユーザ企業からは見えにくい。そのため、変更に関わる諸問題に対して、SIベンダはかなり政治的な動きを見せる。つまり、大幅に水増しをしたり、やりたくない仕事ならコストや納期を過大に述べたりする。発注側の担当者も、あうんの呼吸でそれを把握し、ずぶずぶの関係を維持させるために「自社内」に向けて「この変更の実施は取りやめたほうがよい」とアナウンスする格好になる。

 

 経営戦略〜システム戦略〜システム要件という流れで発生している変更要求を却下しているということは、そもそものシステム投資やシステムそのものの価値を否定しているに等しい。SIベンダが、「顧客の利益追求のお手伝い」をしているのではないことは明白である。

 

 さらに、技術者の行動特性として、「必要な作業」よりも「目の前の作業」や「デバッグ」を優先させる傾向がある。また、すでに完成したソースに手を入れることを嫌う傾向もある。SIベンダに変更管理を丸投げし、SIベンダが片手間に変更管理を行うことで、変更管理は形骸化してしまう。特に、納期間際の切迫した状況だと、ソースコードを書き上げることやバグを追い出すことに追われて、変更管理プロセスを無視しがちだ。「とりあえず文書化は後回しで、まずバグつぶし」という結果になる。成果物間の整合性は失われ、履歴管理も追跡も、もはや不可能であろう。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

13.1. プロジェクトにおける変更管理への認識 ハッピィ・エンジニアリング関連ページ

13.2. 変更管理のメリット
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.3. 変更管理プロセスの位置付け
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.4. 変更管理における役割
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.5. 変更管理プロセス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.6. 変更管理方法論
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング