【システム開発】要件定義後「開発フェーズ」で発注者がやるべきこと5選

システム開発において要件定義フェーズが終了すると、そこからは設計・プログラミングなど開発フェーズに入ります。

「開発フェーズに入れば、のんびりとシステムの完成を待とう。」
いやいや、そうはいきません！開発フェーズに入れば、少しは安心してもいいですが、まだ発注者がやることはあります。

今回は、開発フェーズに入ったら発注者がやるべき5つのことについて解説します。それぞれの具体的なアクションも紹介しているのでぜひ最後までご覧ください。

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。


要件定義が終わり開発フェーズに入った後、多くの発注者の方は「あとはシステムの完成を待てばいい」と思われているかもしれません。ここで一息つくのはいいですが、のんびり待っていると後から焦ることになります。さながら、夏休みに計画的に宿題をやる子どもと、夏休みの終わりに宿題を間に合わせるために必死になる子どものようにです。

開発フェーズにおいても、発注者も積極的に関与し、システム開発を成功に導くためのステップを踏むことが重要です。では、具体的にやるべきことはなにか？それをこれから解説します。

それでは順に見ていきましょう。

1．進捗管理と遅延なき回答

まず進捗管理についてですが、開発フェーズに入ると、開発ベンダーから定期的な進捗報告が上がってきます。1ヵ月に満たないなど余程短い開発期間でない限り、進捗報告がないことはないでしょう。これらの報告は、ただ形式的に受け取り何となく聞き流してはいけません。

システム開発プロジェクトは、当初のスケジュール通りに進まないことが多いです。スケジュールに遅れが生じている場合、その原因と対策にもしっかりと耳を傾けてください。

次に遅延なき回答について、システム開発で作るべきものは、基本的には要件定義書に全て記載されているはずです。ただし、何かしらの漏れは必ずと言っていいほどありますし、要件定義書に記載しきれなかった、あるいは気が付かなかった詳細な要件、そして設計以降に決定を持ち越した仕様もあります。

これらの決定事項・質問には設計フェーズで引き続き検討や判断が求められますので、スケジュールで決められた設計期間内に、速やかな回答が求められます。たった一つの回答だったとしても、その内容次第で回答の遅延は設計の遅れ、ひいてはスケジュール全体の遅延に繋がりますので、注意しなければなりません。

進捗管理と遅延なき回答における具体的なアクションは下記のものが挙げられます。

2．受入テストの準備と実施

開発フェーズを終えると、発注者は受入テストを行います。このテストは、システムが要件を満たしているか、実際の業務で問題なく動作するかを確認するための重要なステップです。具体的には、要件定義書で定義した要件どおり各機能が動作するのか、予期しないエラーや問題が発生しないかを確認します。

ここで過去の経験談をご紹介しますが、当社が開発を受託したシステムが間もなく開発終了に近づいた時に、発注者であるお客様に対して「開発も終わりに差し掛かっているので、受入テストの準備をお願いします。」と依頼したところ、「受入テストって、何をするのですか？」と質問されたことがあります。

開発者側としてはテストは日常的に使われるような言葉ですから、受入テストは受け入れるためのテストで、相手が知らないとは想像もしていなかったので、その質問には少し驚きました。しかし冷静に考えてみれば、兼ねてより何度か私も口にしていますが、ITベンダーの常識であっても発注者はシステム開発をする機会は少ないわけで、受入テストがピンとこないというのも頷けることでした。

その時はどのように対応したかと言うと、当社で実施したシナリオテストのテストケース・データをご覧頂き、「これを参考にして、テストを実施してください。」とお伝えしました。ですが、実はこのやり方がいいという訳ではありません。

なぜなら、開発側の視点に基づいたテストケースであるからです。要件定義に基づいて開発を行い、テストも行っているのですから、発注者・開発者のどちらがテストシナリオを作っても同じ結果になるはずです。

しかし、開発者視点でのテストは発注者、つまり実際に使う人の立場からすると、抜け漏れがあることがあるのです。受入テストは開発するシステムの規模に比例してテストケースが多くなり、期間も長くなりますので、入念な計画を行いましょう。

受入テストの準備と実施における具体的なアクションは下記のものが挙げられます。

3．コンテンジェンシープランの策定

Wikipediaによるとコンテンジェンシープランは、下記の内容とあります。

では、システム開発における緊急時対応とは何を言うのでしょうか？
今やシステムは企業の事業にとって欠かせないものとなっています。システムありきのビジネスモデルも多いでしょう。それだけに、システムに不測の事態が起こると事業への影響は計り知れません。

もし、システムが止まったらどうしますか？　売上の減少やお客様へご迷惑をかけ、企業に対する信頼性が損なわれるかもしれません。

今年の7月、マクドナルドでシステム障害が発生し、一部店舗が閉店するということがありました。店舗の閉店は売上減少になるばかりか、せっかくご来店頂いたお客様にもご迷惑をおかけしてしまいますので、企業の信頼低下にも繋がります。

このような事態を防ぐためにも、システム導入後、システムに不測の事態が起こった場合、どのように対応するのかを事前に検討しておく必要があります。これは保険的な要素が強いものですから、もしもを想定して計画を立てることはなかなか難しいと言うのも事実ですが、システムの重要性、事業に与える影響を鑑みて対策を施してください。

コンテンジェンシープランの策定における具体的なアクションは下記のものが挙げられます。

4．成果物の評価と改善

開発フェーズが進むにつれ様々な成果物、例えば設計書・テスト結果・ユーザーマニュアルなどが作成されます。(※成果物（納品物）は、契約に依存します。詳しくはこちら→システム開発の契約書はここに注意！)発注者としては、これらの成果物をレビューし、品質を確認することが求められます。品質の高い成果物を確保することで、システムの安定稼働を実現することができます。

しかし、実際にはシステム部の方でない限りレビューできる成果物は限られ、限界もあるでしょう。特に設計書は発注者がレビューすることが困難な代物です。ただし、最低限抑えて頂きたいことがあります。それは、成果物の納品時点で最新の状態になっているのかという点です。

開発フェーズにおいては、設計を行い、プログラミング・テストへと進行しますが、設計後に仕様が変わることが少なくありません。また、設計の見直しをすることもあります。そういった場合、プログラムを優先し設計の修正が後回しになることがあります。後回しになって、納品前に修正してあればいいのですが、納品時点で忘れている、あるいは間に合わないので故意的に修正しないということがあります。それがリアルです。

ですから、成果物は最新状態になっていることを文書で報告してもらうことで、悪く言えば手抜き作業に対する抑止効果は期待できます。

もちろん要件定義書と照らし合わせて、相違がある箇所などを見つけたら、その内容をフィードバックし改善を求めましょう。

成果物の評価と改善における具体的なアクションは下記のものが挙げられます。

5．システム導入計画

システムの開発が完了したら、そのシステムの導入が待ってます。導入計画をしっかりと策定し、スムーズな移行を目指します。導入計画には、移行スケジュール・トレーニング計画・サポート体制の構築などが含まれます。

小規模なシステムであれば、システムの導入を大げさに考えることはないと思うかもしれませんが、規模が小さくてもお金に関わるようなシステムの場合は、テストを十分に行ったとしても慎重にしなければいけません。

また大規模なシステム、複数店舗・複数支店で使われるようなシステムの場合、いきなり全店から開始する前に、いくつかの支店から開始し問題が生じないかを確認したうえで、他の店舗へ拡張していくという方法も考慮すべきです。

システム導入計画における具体的なアクションは下記のものが挙げられます。

まとめ

今回解説したように、システム開発において要件定義が終わっても、発注者の役割は終わりではありません。

以上の5つについてなど、発注者が積極的に関与し続けることで、プロジェクトの成功確率を大きく高めることができます。

システムの完成を待つだけでなく、開発の進行状況を常に把握し迅速に対応することで、問題が発生しても早期に解決できます。発注者としての責任を全うし、プロジェクトを成功に導いてください。