変更要求案件対応の工程とマネジメント手法
変更要求リストは変更要求全体のマネジメントを行うためのものですが、1件1件の案件が予定どおりに終わるためには、そのためマネジメントが必要です。
一つひとつがプロジェクトでもあるのですが、いわゆるITシステム開発プロジェクトの教科書を見ても変更要求案件対応のそれとは異なります。
超大手のITベンダーであっても、プロジェクトが変更要求対応案件であることを軽視して失敗しているケースが散見されます。
では、変更要求対応案件はどのように進めていけばよいのでしょうか。
それだけで膨大なコンテンツとなりますので、ここでは概要の紹介となります。
工程全体の組み方
変更要求案件は、既存ITに対する要求への対応です。
よって既存が存在する中で進めるものです。
ここが大きなポイントであり、既存が既に本番で稼働していることが制約となっており、プロジェクトとしての難易度を上げているところです。
工程の組み方としては、要件定義、設計、開発、テスト、移行という通常の段階を経て行うのが基本とはなりますが、少し工夫が必要となります。
まず要件定義の段階においては、要求を確認するところから始めます。
要求確認の後は、それをITとして実現するべく要件定義を行っていきますが、既存ITが存在しますので、現行ITの調査が工程として必要となります。
調査は現行が既にあるため、実装レベルまで調査が必要です。
要件定義と言いながら、設計や実装レベルまで一旦たどり着いてからようやく要件が確定することになります。この工程をあなどると実現できないIT企画となってしまいます。
非機能要件についても現行が既にあるので、現実的な調査の上で、要件が確定することになります。
要件定義が実装レベルまで確定してれば、その後はあまり問題ありません。しかし既存ITが複雑である場合調査が不十分なケースもよくあることです。
その後、設計、構築と進め、総合テスト、受入テスト、運用テスト、移行、本番切替、移行後フォローとなります。
既存ITがあるということは、本番運用が行われている中での移行・切替となります。
移行・切替をしくじると本番業務運用に影響が出て、ビジネス上の影響が出てしまいます。
従って、入念に進める必要があります。
上流工程の進め方
要求としてITでやりたいことは比較的わかっていることが多いです。
それは既に稼働しているITがあるため、それに対する変更は目に見えやすいということからです。
しかし、要求に対して実現にあたっては簡単とは限らないことが多いです。
上流工程は、全体の半分の期間を費やすぐらいのことも多いくらい重要なフェーズです。
まず要求の確認を行います。
確認したら確定ではありません。
既存ITの調査により、実現性について確認していく必要があるからです。
実現性を確定するまでが、慎重かつ時間の掛かるタスクになることが多いです。
調査をしていく上で、実装レベルまで調査します。そのうえで実現方法とその影響まで調査します。
データに1項目追加したいというだけの要求であっても、簡単にはいかないこともあります。
調査に時間を費やしたわりには、結果実現できなかったということもあります。
その際にはまた別な切り口での調査ということになります。
上流工程において実現方法の選択肢がいくつか出てくるのは普通です。場合によっては、やっぱりできないので業務運用での対応となるケースもあります。
それも含めて複数の選択肢の中で、調査も工数が掛かりますから最適解を見定めてタスクを組みます。
しかし、最適解と思っていても、調査したらやはり実現できないということもあり得なくはないため、別な実現方法も検討する期間を計画しておく必要があります。
このように、既に実装されているITがあるため、実装レベルという下流工程までを行ったり来たりしながら、要件定義が完成していくことになります。
機能面、非機能面ともに検討を繰り返した中で、定義付けます。
非機能面の特にテスト、データ移行、本番切替については、特に既存ITと既存ビジネスの継続を考慮した計画と実行が必要となり、重要な観点となりますので、別途説明します。
設計・構築工程でのマネジメント手法
変更要求案件にもよりますが、構築規模は比較的小さいものは多いでしょう。
既存のITが存在するため、それに対する要求は目に見えています。もう少し機能が改善されれば効果は大きい、といった要求は数多く発生します。
構築規模が小さくても、要件定義工程は現行ITを調査しなければならないため、期間を要します。しかしそこまで精緻に進められていれば、設計は調査段階でほぼ目途は立っているし、構築においても影響箇所が見出せています。
よって、相対的に全体の中でのマネジメント対象としては、小さいものになることが多いです。
とはいえ、要件定義における調査が不十分であることもあり、進捗が思ったより進まないこともあります。
よって、マネジメントは行っていく必要があります。
マネジメント対象は設計の本数なりプログラムの本数なり、定量的に把握できるものが多いため、定量評価により状況を把握するようにしましょう。
調査が不十分であった際は、課題として発生し、問題が多ければ課題が積み上がります。
課題の発生数と解決のスピードも見て、状況を評価し、必要に応じて対応するようにしましょう。
プログラムモジュール単位であれば並行してタスクを進められるため、仮に遅れた場合はメンバ増加が可能であればリカバリ可能です。
ベンダーに委託している場合は、定期報告を定量的にもらい、評価の上コントロールするようにします。
テスト工程の組み方とマネジメントの方法
テストは、通常は総合テスト、受入テスト、運用テストとなります。
総合テスト、受入テスト、運用テストはいずれかのテストを統合して行われることもあります。それは発注者とベンダーの関係性にもよります。
いずれにしても、変更要求であれば、必要なテストは、業務シナリオテストと新旧対比テストになります。
そして、重要なのは、変更要求のとおりできているかというテストと変更要求がない部分が今まで通りというかというテストを行うということです。
リグレッションテストと呼ばれますが、変更要求案件においては、変更以外箇所が意図しない方向に変更されてしまっていることが多く発生してしまいます。
従って、構築箇所が少なくても、影響箇所が大きければ、極端な例としては、初期構築規模のテストが必要ということになります。
テスト範囲については、要件定義時にも既存ITを調査の上、計画を盛り込む必要があります。
受入テストや運用テストにおいては、特にユーザサイドの観点から網羅的にテスト計画を組んで実行します。
レアと思われるケースにおいても、そういうケースこそ問題が発生しますので、ケースを洗い出します。
ユーザサイドで十分なテストケースが導き出せることはあまり多くはないです。
ただ発注したベンダーに丸投げしてお願いすると、それはそれでユーザ視点は抜けてしまいます。
よって、ユーザサイドでできるよう体制を厚くしておきたいところです。
データ移行のマネジメント方法
変更要求に対しては、データに変更が発生する案件は難易度が上がります。
データに影響があると、過去蓄積されたデータや切替前後のデータにどのような変更要求があり、どのように切り替えるのかを緻密に計画しないといけません。
データ移行はベンダーとも揉める要因になります。
というのは、ベンダーは、既存ITにあるデータはユーザのものであり、移行データはユーザが用意し、移行を実施するものと考えるからです。
ところが、発注者であるユーザのほうは、データも含めて変更対応してくれるものと思っていることが多いです。
認識のギャップにより、最悪プロジェクト頓挫にまで追い込まれることもあるくらいです。
緻密でかつ役割分担を明確にする計画を要件定義段階で決めておく必要があります。
実務上においても、問題は多く発生します。
それは変更前データでは明確になっていなかったデータ項目を、変更後は必要とするような要求がよくあるからです。
明確でないということは、項目があったりなかったりします。あるいは、同じ意味なのに、不完全な状態なこともあります。
それらのデータを取り揃えるのは、意味を理解している人でないとできません。
意味というのは、現行ITと変更後ITの両方の要求と仕様を理解していることを前提とした意味の理解になります。
よってITと業務を両面知っていないとできないことになります。
ベンダーはそれができないことが多いため、できれば自分のタスクではないようにしたいと考えます。
ところが、プロジェクトしては、誰がやろうと意味を理解して実行できるように準備できる体制が必要です。
要件定義時点で、誰がこのデータ準備ができるか、どのような段取りで実行するかを粗方決めておきたいところです。
本番切替のマネジメント方法
本番切替とはほんの一時のことです。しかし重要なポイントであるため、綿密に計画し、実行する必要があります。
本番に切り替えると、変更後が本番になりますので、変更が間違っていると本番が間違っていることになり、取り返しがつきません。
もちろん、機能的にはテストで検証していきますが、切替作業そのものの中に問題が潜んでいる可能性があります。
本番切替方法についても要件定義で決めておく必要があります。
リスクを低減する方法としては並行稼働という方法があります。しかし新規のITに切り替えるのであればなせる業ですが、変更の場合は、ほとんどは一発切替となります。
一発切替のリスクが大きいと考えるのであれば、別な機能として稼働させ、稼働確認できてから既存IT機能を停止するということも考えます。
しかし、それができるのも変更要求の限られた条件下になります。
切替に関しては、ある日突然変更となるため、変更前から変更後になるITだけでなく、関係する事項すべてに対して計画していくことになります。
本番切替の日は、タイムスケジュールを立て実行します。
切り戻しが必要になることを想定して、切り戻しタイミングも含めて計画します。
本番稼働後フォローのマネジメント方法
本番切替を行って稼働した後はITとしての仕事は済んでいるのでしょうか。
大抵は本番稼働後に何らかの問題が発生することを想定して、フォローを計画します。
テストで検証し、移行・切替を計画して行ってきましたが、やはりその後通常運用を維持するために、バックアップ策としてのフォロータスクが発生します。
フォローはその時に焦って計画しても実現できません。
予め決めておくべきことは、フォローメンバやベンダーを含めた体制です。
夜間処理などは朝までに対応しないといけないため、ある程度ケースを想定したリカバリ方法を用意します。
その他、通常運用として、業務代替策を用意し、何かあってITが利用できない事態に陥った時は、発動できるように予め関係者とも話しておきます。
フォローで計測すべきことも決めておき、日々計測します。
発生障害件数はフォローすべきもので、リスト化して対応状況をマネジメントしておきます。
稼働・保守・障害対応にて通常運用のマネジメント手法を説明しましたが、フォロー時は通常に加えて厚めの体制を組んで対応します。
もちろん、今晩切替する変更要求のリスクによりますので、影響の大きくないものは、稼働直後のみのフォローということもあります。
変更要求案件マネジメントでありがちな問題
難易度の見誤り
変更要求案件は、一見簡単そうに見えてしまうことがあります。
既存ITの中味が見えないため、表面的な変更だけで対応できそうに思えてしまうからです。
要件定義時点で調査を行い、見積範囲を見極めるということを説明してきましたが、言葉で言うほど優しいものではありません。
業務プロセスレベル、オペレーションレベルなどの様々なレベルで影響を見極める必要があり、特に実装レベルの調査は、難易度が高く見逃しは起きます。
改修箇所を数カ所見込んでいたのですが、実際はデータ構造が複雑であったため、処理をさらに追加しない等の事象が発生します。
難易度を見誤った結果、テストについても範囲を狭く見積もっており、思わぬところに影響がでることで、結果納期もコストも予定で収まらないということが、現場においては日常的に起きています。
影響範囲の見誤り
難易度にも近い概念ですが、影響範囲の見誤りも、よく起きています。
ITで発生するデータは別な業務で利用されていることはよくあります。
変更要求があったのは、一点の項目修正であったかもしれませんし、簡易なものと思われるかもしれません。
しかし、その修正該当データは他の業務で使っており、しかもその影響を知らなかったということは、十分起きうる事象です。
納期・コストが予定で収まらないのは当然のことながら、最悪稼働後に発覚することもあります。
案件がありすぎる
比較的大きなITプロジェクトを実施後は変更要求が多数発生します。
これは、プロジェクトとして一旦終わらせるために、プロジェクト過程で発生した変更要求が後回しになっているからです。
案件がありすぎるということは、ある意味ITシステムが不完全であったということと言えます。
しかしよく見ると先延ばししても大丈夫であったということは、何とかなっているとも言えるのかもしれません。
案件が多すぎた状態は、ITと業務のギャップが多いという意味ではよい状態ではないと言えますが、課題が見えており、潰していけばよい状態に近づく、ということが見えているとも言えます。
1件1件案件リストに対してマネジメントしていくことで、よりよい状態となると期待して取り進めしていくことになるでしょう。
案件がない
逆に案件がない、という状態もあるでしょう。
案件がないということは、ある意味ITが完璧な状態にあるということになります。
ある意味非常によい状態と言ってもいいでしょう。
しかし変更要求ないというのは、反響がないということでもあり、完璧な状態であればいいのですが、あまり使われていなくて反応がないという可能性もなくはありません。
利用面での調査を改めて行ってもいいかもしれません。せっかく作った仕組みが活用されていなければ、活用促進活動に移ったほうがよいです。
また、見方を変えると別なリスクも示唆しています。
変更要求案件がないと、あまり面倒見なくてよいということとなり、人を当てがいません。
そんな折に、深刻な障害が発生した場合は、対応ができず問題が長期化するというリスクを孕んでいます。
障害対応案件の割り込みが入る
変更要求案件は優先順位を決めて取り組んでいますので、現在進行中の案件への期待は高いです。
しかし、障害対応案件はそれ以上の緊急度となり、優先順が上がってしまうことがあります。
対応するメンバを並行して走られることが仮にできたとしても、同一プログラムモジュールへの影響があったら、どちらかに待ちが発生することになります。
障害対応のほうが、緊急度が高いことが多いですから、割り込みが入ってしまったことになります。
その結果としては、変更要求案件は一次作業停止せざるを得ません。
既存ITが存在するためいつでのそのリスクは存在することになります。
突然大きな案件が発生する
ITへの要求は突然出てくることがあります。
取引先とデータ連携して受発注しているケースも多くあります。
その際に、取引先との関係上、急であっても対応せざるをないという事態はよくあります。
しかも、取引先との連携関係となると大きな案件となることもしばしばです。
変更要求案件はリスト上で優先順位をつけて次々に対応していますが、大きな案件が急に発生し、リストの意味がなくなってしまうことすらあり得ます。
変更要求案件マネジメントとして本当にやるべきこと
変更要求案件はITの日常保守運用している間では、通常は発生したものを合理的にこなしていくことになります。
リスト化して優先順を明確にし、対応していきます。
1件1件の費用対効果も算出した上で、実際にやるべきものを対応していく、ということになります。
また1件についても、実行するにあたっては、既存ITの調査という行為を経て対応していきますが、その感での見落としなど、リスクは多く孕んでいます。
さらに、案件そのものが急に発生し、計画が崩れ去るリスクがいつでもあるということになります。
理想的な状態にマネジメントしてもっていきたいと思っても、なかなか難しい一面があるのが変更要求案件への対応です。
何か発生するのを見込んで、余裕を持ちすぎてもコストが定常的に掛かってしまいますし、かといって何もないことを想定して余裕が全くないと、何か起きたら即時破綻になりかねません。
このあたりは、外注を含めたメンバのリソースの問題となりますが、マネジメントしていくには、学習と実践を積み、見極める力をつける必要があるのかもしれません。
リソース面、外注面のマネジメントについては別途説明の機会を設けます。
コメント