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

13.6. 変更管理方法論

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

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

 

 開発プロジェクトの大目標であるこれらの点を満たすためには、プロジェクト管理プロセスと同様、変更管理プロセスを確立しておかなければならない。成果物には、正しく動くことだけでなく、整合性が取れていることも要求される。整合性を維持するために必要なプロセスが、変更管理である。

 

 変更管理プロセスには、

 

  • 要求変更申請プロセス
  • 要求受け付けプロセス
  • 受け入れ可否判断プロセス
  • 変更内容記録プロセス
  • 変更内容追跡プロセス

 

が含まれる。

 

変更要求が出される要因は、大きく分けて次の3つである。

 

  • 要件変更要求
  • バグを含む修正要求
  • 改善要求

 

 ただし、現実には、いったん出された変更要求が修正後に取り消されたり、監査方法の変更に伴って規約が変更されたりすることもある。

 

 変更要求はプロジェクトのあらゆるプロセスで発生し得るものだ。要件の変更要求はプロジェクトの初期段階に多く、改善要求はリリース後に出されることが多い。しかし、開発の最終段階になって要件変更が要求されることや、開発の初期段階から厳しい性能要件が要求されることもある。

 

 こうした変更要求を適切に管理していくためには、各プロセスで生じる影響や問題点を整理しておかなければならない。

 

計画立案段階の方法論

 プロジェクト管理において、プロジェクト計画の重要性はいくら強調しても強調しすぎることはないだろう。あいまいな計画からはあいまいなプロジェクトしか生まれ得ず、あいまいなプロジェクトからはあいまいな成果しか得られない。プロジェクト計画があいまいになる要因については、これまでの章でさまざまな視点から論じてきたが、ここで、その一因として「変更に対する認識の甘さ」をつけ加えておきたい。

 

 「計画」という言葉には、ある種「不可侵」なもの、という印象がある。一度立ててしまった計画を変更するとはなにごとか、といった考えである。計画の変更というと、見通しの甘さ、調査・調整不足、ご都合主義、といった負の印象がつきまとう。しかし、最初から完全な計画というのはあり得ないものだ。

 

 プロジェクト計画自体にも、方向づけ・推敲・作成・移行というライフサイクルがあるのである。プロジェクト計画の変更は悪いことでもなんでもなく、計画に変更がないほうがむしろおかしいのだ。「計画を変更するなど、とんでもない」と考えて、計画に対する変更プロセスを一切考慮しないことのほうが問題である。

 

 計画の変更は、要件の変化、技術調査の結果、市場環境の変化、ビジネス上の要求の変化など、さまざまな要因で生じ得る。より現実的なことを言えば、スケジュールの遅延も大きな計画変更要因である。

 

 こうした点を随時計画に反映し、改訂していかなければ、計画自体が次第に現実と乖離したものとなっていく。そうなると、現実的に不可能なスケジュールの強行(そして破綻)、基本要件の漏れなど、根本的な問題に発展する。繰り返すが、質の低い計画からは質の低い成果物しか生まれない。

 

 このプロセスで管理すべき変更は、要件に関するものがほとんどである。プロジェクトはまだ方向づけおよび推敲段階で、頻繁に新たな要件が出されたり、逆に取り下げられたりする。そのため、早期に構成管理データベースを導入し、成果物に加えられた変更を追跡可能にしておかなければならない。

 

 この段階での変更管理は比較的容易なので、そうした時期に変更管理手順をしっかり浸透させ、手順を確立しておくべきである。例えばファイルサーバのありかやディレクトリ構造など、個別的・具体的な作業手順についてもこの段階で確定しておく。そうしておかないと、同じ文書の異なるバージョンが存在してしまったり、加えた変更が紛失してしまったりする。こうした作業や手順立案はライブラリアンの担当ともいえるが、変更管理者も積極的に関わるべき事項である。

 

 プロジェクトの初期段階に行われる要件の変更は、粒度が大きく、プロジェクトの規模すら左右しかねないものが多い。そのため、プロジェクトが間違った方向に進まないように、変更承認者が合理的判断を行えるだけの情報が必要である。変更管理者には、実現可能性・工数・スケジュール・リスクを十分に分析し、変更承認者が理解可能なように説明する能力が求められる。

 

 このプロセスで変更管理の対象となる主な成果物は、

 

  • プロジェクト計画書
  • 要件定義書、要件仕様書
  • WBS

 

である。

 

開発段階の方法論

 開発プロセスでも、計画プロセスから継続して要件変更要求や、スケジュール変更が断続的に発生する。開発プロセスでの変更を受け入れるには、変更に強い設計や反復的な開発プロセスを採用するといったことは当然だが、このプロセスで重要なのは変更の追跡可能性(traceability)である。

 

  • いつ(When)
  • 誰が(Who)
  • なぜ(Why)

 

変更を要求し、それに対して、

 

  • どこに対し(Where)
  • 何を(What)
  • どのように(How)

 

修正したか、を記録しておかなければならない。

 

 この記録を怠ると、設計と実装が食い違う、要件が抜ける、といった弊害が起きる。こうした問題は、保守や二次開発にも悪影響が及ぶ。設計(ドキュメント)と実装が異なっていた場合、どちらが正しいのか容易に判断がつかなくなる。本来であれば、顧客が利害関係者との調整を図り、変更の工数やスケジュールを加味した上で変更を受け入れるか否かを検討・判断し、要件を再定義した上で仕様の変更と設計変更を行うべきである。

 

 不具合報告などのように単純な変更要求であれば、こうした追跡は比較的容易だが、本章冒頭の例のような、ささいな要件の変更についても十分な注意が必要だ。コードの修正量は確かに小さいが、実際には要件定義・基本設計・詳細設計・実装・テストケースのすべてについて変更が必要となる。こうした変更をすべて追跡できるようにしておくには、単にバージョン管理システムでソースコードの変更履歴を残しておけばよいものではなく、ましてやプログラマがその場で手を動かして直してよいわけがないことがわかるだろう。

 

 このプロセスでは、しばしば指揮系統が混乱する。各利害関係者が各自の立場と価値判断から、開発チームに対して変更要求を出してくるからである。プログラマとしては、「こんな修正、簡単でしょ」と言われると、自分の技術力のなさをさらけだすようで、「できません」とはなかなか言いにくい。もちろん、安易に「できる」と言ってしまうプログラマにも問題があるが、そもそもプログラマに変更受け入れの可否判断をさせてはいけないのだ。

 

 変更承認者は、ユーザ部門や企画部門からの変更要求が合理的なものかどうか、変更によってリスクがどれだけ増えるのか、スケジュールへの影響がどの程度あるのか、などを判断した上で、変更の可否を決定しなければならない。また、SIベンダは、QCDの向上に力を注ぐべきであり、顧客へのご機嫌取りのために「金メッキ」を作り込んだりするような要求を独断で受け付けてはならない。

 

 大事なのは、変更承認者により変更が認められ、変更管理者により変更が指示されたもの以外を変更してはならないということである。

 

 このプロセスにおける構成管理や変更管理は、比較的整備されていることが多い。開発環境と運用環境の設定および維持、ソースコード管理など、目に見える作業が多くなるため、方法論も豊富にあり、プロジェクトメンバの意識も比較的高い。しかし、このプロセスほど変更管理が形骸化しやすいプロセスもない。メンバに時間的な余裕があるときは手続きに従って作業が進行するが、デスマーチが始まると、それどころではないとばかり、軽んじられ、無視されるようになる。その結果として、本節の冒頭のような、ありがちなストーリー展開となる。

 

 デスマーチを発生させるようでは、そもそもプロジェクト管理自体が間違っているともいえるが、そうした状況に陥ったとしても、手順が明確になっていて、監査がしっかり行われれば、形骸化はある程度防ぐことができる。

 

 繰り返し述べているように、ソースコードの履歴管理をすることが変更管理ではないし、変更管理シートを一枚書けばよいというものでもない。ソースコードの修正がどのような意味を持つのか、メンバ全員がしっかりと意識することが大切だ。

 

 このプロセスでは、ちょっとした変更が、思ったより大きな影響を与えることが多い。そのため、変更の追跡可能性の確保が重要である。そうしておかないと後で変更内容や理由がはっきりしなくなり、対象システムのあるべき姿がわからなくなる。技術者の変更に対する誤認や誤解が生まれた場合には、大幅な手戻りとなりかねない。

 

 権限外の作業をしてはならない、という点を徹底させることも重要だ。変更を行う権限だけでなく、要求を出す権限の割り当てと範囲を明確にしておくべきである。そうしておけば、プログラマが「よかれと思って」機能を追加してしまうことも防げる。

 

 こうした「金メッキ」を防ぐには、変更レビューが有効である。その変更が妥当なものか、要求に合致しているかを確認する作業が変更レビューであるが、プロジェクトの定例ミーティングとは別に機会をもうけて行うべきだろう。変更通知を受けた変更管理者が判断できるものであればよいが、判断できないものであれば臨時ミーティングを招集するなり、作業者から直接報告を受けるなりする必要がある。

 

 このプロセスで変更管理の対象となる主な成果物は、

 

  • 仕様書
  • ソースコード
  • バイナリファイル
  • テスト計画、テストケース
  • ユーザマニュアル

 

である。

 

運用段階の方法論

 運用プロセスで出される変更要求は、主に障害修正要求か、小さな要件変更要求である。いずれの場合でも、障害・変更管理表を起こし、変更を記録するのはまだいいほうで、その場でソースコードをコメントつきで修正するだけ、せいぜいチェックイン時のコメントに残るのみというケースが多い。その上、運用時の障害修正は、開発時よりもターンアラウンドタイムの要求が厳しいことがほとんどである。どうしても障害対処が優先になりがちで、文書化や他チームへの伝達は後回しにされるか、まったく行われないかのどちらかだ。

 

 運用プロセスでの変更管理がもっとも難しい。「運用に乗ったらプロジェクト管理はおしまい」という風潮があり、このプロセスで変更管理が意識されることはほとんどないからだ。運用チームに引き継ぎをして開発チームが解散してしまうことも多い。しかし、運用プロセスでの変更管理こそがもっとも重要なのである。

 

 なぜなら、変更記録を残し、各成果物を適切に改訂していかないと、運用手順書やユーザマニュアルと実際の動作とが乖離していく、仕様と実際の動作が乖離していく、といった問題が生じるからである。この結果、運用コストが増大する、障害復旧手順が誤っているために復旧に時間がかかるなどの弊害が起きる。

 

 障害復旧手順書などに影響が出る場合には迅速に修正版を配布すべきだが、ユーザマニュアルなどの改訂は、頻繁に行う必要はない。修正したシステムをリリースしてから、ユーザマニュアルを改訂・リリースすればよい。書籍や製品マニュアルであっても、次の版を印刷するまでは誤りが放置されるのだから、それほど神経質になる必要はないが、定期的に改訂版をリリースすることが望ましい。

 

 プロジェクトが運用プロセスに入ると、開発リソースが激減するのが常である。通常、開発チームは解散し、残っているのはドキュメントとソースコードのみ、という状態になる。運用チームは、残されたドキュメントとソースコードから業務を行っていかなければならない。

 

 このことだけでも運用チームにとっては相当なプレッシャーになるが、加えて、利用者からのフィードバックを受け取るのが常である。受け取ったフィードバックを反映させ、かつ整合性を保つためには、このプロセスの変更管理こそがもっとも重要なのである。

 

 なぜなら、変更の手順が明確になっており、変更が正しく追跡できている、という自信を運用チームが持っていないと、どうしても変更要求に対しておよび腰になる。その結果、利用者は「不具合がなかなか修正されない」とか「いつまでたっても使いにくいままだ」という不満を抱くようになる。つまり、サービス品質が低下する。

 

 変更要求を受け入れるためには、「変更を行っても整合性は失われない」という自信が必要なのだ。変更管理をしっかり行っておけば、むやみに変更を恐れたり嫌がったりすることもない。運用プロセスでの変更管理は、サービス品質の維持に欠かせないプロセスなのである。

 

 このプロセスで変更管理の対象となる主な成果物は、

 

  • 仕様書
  • 設計書
  • ソースコード
  • バイナリファイル
  • ユーザマニュアル

 

である。

 

二次開発に向けた方法論

 このプロセスでは、主として改善要求が多くなる。当初の要求を満たしていないなど、瑕疵に該当する修正であれば、瑕疵担保期間はSIベンダが無償で修正を行わなければならない。しかし、瑕疵に該当しない修正の場合、当然保守費用が必要となるし、さらに大きな変更や追加が生じるようであれば、二次開発ということになる。

 

 保守作業や二次開発にかかるコストや労力は、このプロセスに到達するまでに変更管理をどれだけ行ってきたかにかかってくる。まず、要件定義書・要件仕様書の変更管理をしっかり行っていなければ、何が改善要求で何が要件変更なのかもわからなくなる。
 ドキュメントとソースコードの整合性を保っていなければ、ソースコードから仕様の再構成が必要になるし、そもそもソースコード、つまり現状の動作が本当に要件を満たしているものかどうかもわからない。運用後に発生する変更要求は、えてして現場担当者の場当たりな操作性の向上といった視点から行われるものが多く、本当に業務上の要件を満たすかどうかはわからないのだ。

 

 そうなると、二次開発は要件の再定義から始めなければならなくなる。当然二次開発に特有な要件があるので、要件定義は必要だが、二次開発の要件定義は、あくまでも当初の要求ベースラインに対する差分として行われるべきである。

 

 このあたりをあいまいにしたまま二次開発に突入すると、技術者は自分たちがやっている作業が障害対応なのか、要件変更なのか、追加開発なのかがあいまいなまま突っ走ることになる。

 

 この段階では、既存システムに対する変更要求はほとんど発生しなくなる。代わりに、次期開発への要求、大幅な機能追加や変更といった要求が多くなる。

 

 この時点でできることは、さして多くない。このプロセスを適切に処理するには、これまでどのような変更管理を行ってきたかにかかっている。二次開発で必要なことは、一次開発の要件と、二次開発の要件の差分を明確にすることである。一次開発の要件定義が明確になっていないと、結局要件の再定義や、ひどいときにはソースコードからリバースエンジニアリングしてドキュメントを起こすといった手間のかかる作業が必要となる。

 

 このプロセスで変更管理の対象となる成果物は、

 

  • 二次開発における要件定義書、要件仕様書
  • 仕様書

 

である。

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

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

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

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