要件定義～設計～テストというシステム開発プロジェクトを推進するうえで重要なこと
目次
はじめに
システム開発プロジェクトにおいては、当然ながらそのプロジェクトを推進していく必要があります。
システム開発の受託開発側として当然プロジェクトを推進していくのは当たり前ですが、発注側もプロジェクトのオーナーですので、プロジェクトを推進していく必要があるのは当たり前です。
この記事では発注側及び受託開発側が、システム開発プロジェクトを推進するうえで重要なことをお伝えしたいと思います。
なお、ここでのシステム開発プロジェクトの範囲（工程）は、要件定義、基本設計、詳細設計、ソフトウエアの実装、単体テスト、結合テスト、システム（総合）テストになります。
システム開発プロジェクト推進での肝
最初に、推進での肝を３つお伝えします。
１）開発計画を立てて、
２）計画通り実行し、
３）開発中に逐次起こる問題を解決していく
になります。
具体的にそれぞれの肝について詳しく解説したいと思います。
開発計画を立てる上でのポイント
一般的には要件定義を行う時点で開発計画を立てることが必要になります。開発計画を立てるうえでの３つのポイントを記します。
１）開発で行うことをすべて洗い出す→WBS（Work Breakdown Structure）
２）開発で必要な人材（リソース）をすべて洗い出す→開発体制構築
３）WBSと開発体制に基づいて、開発計画表を作成する
この１）～３）の流れだと、開発計画表作成したことによって、ENDが決まる＝開発プロジェクトの完了時期が決まることになりますが、実際のシーンではENDが決まっていることも多いわけです。
発注者側がいつまでに商品、サービスを発売したいという意思を持っている場合は、ENDの時期が明確に示されることが多いです。
ENDが決められている場合は、それを実現する＝決められた期間で開発が完了することを目指して開発体制を構築することが極めて重要になります。
開発計画の立て方イメージを以下の図に記します。
計画通り実行していくためにはどうしたらよいか？
次に開発計画表を作成した上で、本格的に開発をスタートした後は、計画表通り実行していくのが基本となります。そのためにはどうしたらよいでしょうか？
以下の２つの物差しが非常に重要であると考えます。
１）開発計画表に基づいた日程管理
２）課題管理
開発計画表は作ったら終わりではなく、開発しているときに活用していくのが重要です。
また課題管理は日程管理と別に行っていくことをお勧めします。
具体的に２つの管理の仕方を解説します。
日程管理のポイント
日程管理とは、開発計画表に基づいて、本日時点でそれぞれのタスクが予定通りか遅れているかを常にチェックすることです。
日程管理のイメージ図を記します。良く行う方法としては、本日のところに縦線を引いての管理方法があります。
それぞれのタスクが本日時点で予定通り出来ている場合は本日のところに線が引けますが、例えば４日くらい遅れている場合は、4日前のところに線を引くことになります。
すなわち本日より左側に線を引くことになります。
全体をとらえると本日時点で開発が予定通り進んでいるかを俯瞰的に見ることができます。
そしてどのタスクが遅れているかというのも明確になります。
課題管理のポイント
課題管理表には、それぞれの課題はいつまでに誰がどのように解決するのかということを逐次記していきます。
個々の課題が予定通り解決していくかを常にチェックしていきます。
なお日程管理、課題管理は基本的に毎日行うのが基本だと思いますが、プロジェクトメンバー全員と共有するためには１週間に１回くらいで良いと思います。
例えば週１回プロジェクト会議を行い、その会議の中で必ず日程管理と課題管理をメンバー間で共有するのが合理的だと考えます。
日程管理、課題管理以外で重要な３つの管理
今まで解説した日程管理、課題管理がプロジェクト開発管理では非常に重要なことであることは間違いありませんが、それ以外にも重要な管理として、以下の３つを紹介したいと思います。
１）変化点管理
２）不具合修正後の管理
３）リスクマネジメント
３つそれぞれの管理内容について以下で解説します。
変化点管理
変化点管理という言葉は一般にはそれほど言われていないかもしれませんが、システム開発プロジェクトにおいては、非常に重要なポイントになります。変化点管理は大きく2つがあります。
１）過去のシステム、商品の改良をするといった開発プロジェクトにおいて、過去のシステム、商品から変更した機能の管理
→全く新しいシステム、商品開発でなく、過去のものの改良するという開発も多いと思います。
その場合は、変更した機能の管理が極めて重要です。例えば組み込み機器開発を例にすれば電子回路や機構部品といったハードウエアで変更したものをすべて洗い出し、変更によってどういう影響があるかなどを洗い出すことが必要です。
機能を実現するためにソフトウエアが変更される場合も当然ありますので、その場合は個々のソフトウエア変更内容で、どういう影響があるかを洗い出します。
２）開発プロジェクトの途中で、仕様変更によって変更した機能、箇所の管理
本来は開発当初の要求仕様分析→要件定義というフェーズにおいてシステム、商品の仕様はFIX＝決めたうえで、開発を行っているわけです。
しかし実際には、往々にして開発プロジェクトの途中で、お客様からの要求や会社のトップマネジメントからの指示などにより、システム、商品の仕様変更が行われることが多いのは否定できません。
仕様変更が発生する度に、その内容を管理し、どのような影響があるかをきちんとチェックしていく必要があります。
開発途中での仕様変更による不具合は極めて多いのが常です。変化点管理を行うことで、不具合を出来るだけ防ぐようにしましょう。
不具合修正後の管理
開発プロジェクトにおいて、不具合があったら逐次修正していくことは当たり前ですが、問題は不具合修正したことによる弊害が生じる恐れがあるということです。
ソフトウエア開発においはデグレードという言葉で称されています。こういった不具合、デグレードを出来る限り防ぐために、不具合修正後に以下のような管理をすることが重要です。
１）修正によって不具合は実際に改善されたか？
２）修正によって他に改善された不具合は無いか？
３）修正によって新たな不具合が発生していないか？
４）今回の不具合と似たような不具合は無いか？
リスクマネジメント
リスクマネジメントというのは言葉の通り”リスク”をマネジメントすることです。このリスクマネジメントはすでに解説してきた課題管理とは別に行うことが重要です。
ここでの”リスク”の定義は、「起きる確率は低いと考えられるが、もし起きてしまったら大きな障害になるような現象のこと」です。
こういったリスクマネジメントが甘かったために大きなシステム障害が起きたという報道が毎年のようになされています。
私たちのシステム開発においても、必ずリスクマネジメントというアクションを取り入れることによって、障害を起こさないシステム開発を行っていきましょう。
まとめ
今回は、開発プロジェクト推進で重要なこととして、
開発計画を立てる
開発計画に基づいて着実に実行する
開発中に逐次起こる問題を解決していく
という３つを掲げさせていただき、それを実行するための日程管理、課題管理、変化点管理、不具合修正後の管理、リスクマネジメントについて解説しました。
著者が経験してことに基づいて解説してきました。今後の開発に役立つ点があれば幸いです。
関連記事はこちらです
↓
関連記事を以下に記します。