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

第13章 変更管理

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

 プロジェクトはおおむね順調で、製品リリース期に入りシステムもだいぶ安定してきた。テストの消化率・バグ解消率も順調に上昇していたある日、SIベンダのプロジェクトマネージャはエンドユーザからこんな要求を受けた。

 

「電話番号だが、携帯電話番号を入力されると困るので、チェックを入れてはじいてほしい」

 

 携帯電話番号のルールはわかっており、チェックロジックを入れる場所もだいたい見当がつく。そこで、マネージャは担当チームリーダを呼び、エンドユーザの要求を伝えた。チームリーダはプログラマに直接口頭で指示を出し、プログラマは変更管理シートに記入した上でソースを修正し、動作を確認してからバージョン管理システムにチェックインした。

 

 マネージャが2週間の新婚旅行から戻ってみると、プロジェクトは大混乱しており、リリースすら危うくなる状況に陥っている。現場には険悪な空気がただよい、誰もが他チームの悪口を言っていた。

 

 マネージャが休暇を取っている間に、何が起きたのだろうか?

 

 まず、テストチームから開発チームにクレームが入った。リグレッションテストが通らないというのだ。あいにく、修正を担当したプログラマが休んでいたので、苦労してチーム内の資料を調べてみると、プログラマの開発マシンに変更管理シートが保存されているらしいことがわかった。変更管理の内容をチームリーダに問い合わせてやっと変更点が把握され、テストチームに変更を伝えるとともに、設計担当者にも仕様書を変更するよう依頼した。

 

 今度は、定例ミーティングでユーザ企業のシステム部門から文句を言われた。携帯電話番号が入力できないのでは、使いものにならないというのだ。エンドユーザからの要求だと伝えると、システム部門の担当者は不承不承納得したが、プログラマと雑談をしているときにその話を出すと、そんなものは簡単にできると言われたので、ではせめてPHS番号だけをはじくようにしてほしい、と依頼した。プログラマは変更管理シートを起こすこともせず、ソースコードをチェックインするときにコメントに記述しただけで作業を終わらせてしまった。依頼元の担当者に電話をかけた。

 

「直しておきましたよ」

 

 その後は再度のトラブルである。テストチームからはまたもやリグレッションテストが通らない、定期レビューでは設計者から仕様が違うと言われ、開発チームは依頼されたとおりに作っただけで、成果物の修正依頼は各チームに適切に出してあると言い張る。チーム間には不信が広がり、あれほど順調だったプロジェクトが突然崩壊の危機に瀕してしまったのだ。

第13章 変更管理 ハッピィ・エンジニアリング記事一覧

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

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

≫続きを読む

13.2. 変更管理のメリット ハッピィ・エンジニアリング

 ユーザ企業にとっても、SIベンダにとっても、変更管理は面倒な作業である。ユーザ企業は変更要求を受け付け、合理的判断に基づいて変更を承認し、SIベンダに作業を依頼する。SIベンダは、ユーザ企業が出す要件と、設計書の整合性を確認し、設計書とソースの整合性を維持し、テストケースへの反映を行う。 このよう...

≫続きを読む

13.3. 変更管理プロセスの位置付け ハッピィ・エンジニアリング

 変更管理は、プロジェクト管理の最上位、あるいはプロジェクト管理よりも上位に位置すると言っても過言ではない。 変更を承認する権限を持たない人間が勝手に承認することは認められず、指揮命令系統を無視して作業を進めていいものでもない。変更の承認権限はユーザ企業の意思決定権者に一元化すべきで、プロジェクトマ...

≫続きを読む

13.4. 変更管理における役割 ハッピィ・エンジニアリング

 きちんと変更管理できない理由のひとつは、変更管理をする上での役割やプロセスが決まっていないことである。 変更管理には多くの労力が必要だ。役割やプロセスを決定し、それらを多くの利害関係者に周知徹底することや、要件からテストに至るまでの一貫性を維持・管理していくには、コストがかかる。そのため、なんとな...

≫続きを読む

13.5. 変更管理プロセス ハッピィ・エンジニアリング

 変更管理プロセスは、プロジェクト計画の承認後ただちに開始し、プロジェクトが終結に至るまで継続して行うべきものである。プロジェクトに対する変更は、そのライフサイクルすべての段階において変更の可能性がある。前述したように、プロジェクト計画そのものも変更管理の対象となるので、プロジェクト計画の初版がリリ...

≫続きを読む

13.6. 変更管理方法論 ハッピィ・エンジニアリング

 最初にやらなければならないのは、変更管理プロセスを確立することだ。変更管理を行う目的は、「品質の維持」である。プロジェクトの品質とは、「要求が正しく成果物に反映されていること」であり、成果物の品質とは「不具合が少なく、整合性が取れていること」である。 開発プロジェクトの大目標であるこれらの点を満た...

≫続きを読む

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

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