なぜ、システム開発は必ずモメるのか?

システム開発の前提知識

システム開発工程とプロジェクトマネジメント

36712489/iStock/Thinkstock

本書で語られている課題の多くは、システムの企画やシステムベンダの経験があれば、誰しも思い浮かぶものではなかろうか。それらが対話形式で語られており、気軽に読み進めることができる書となっている。ここではその要点を紹介していきたい。

前提知識として重要となるのが、システム開発手法の基本である「ウォーターフォールモデル」である。古くからある伝統的な手法であるものの、特に大規模システム開発においては、なお主流の考え方だ。

1.要件定義

現行の業務とそれを支援するシステムを分析。改善点と新業務要件を定義して、システム化の範囲・目的・方針を決定。それらを元にシステム化要件を定義。

2.外部設計

要件実現の方式や使用するハードウェア、ソフトウェア、ネットワークなどを定義してシステム構成を明らかにする。

3.内部設計

プログラムの構造およびその間のインターフェースなどをプログラミング可能な状態まで定義。

4.プログラミング

内部設計に従ったプログラムの作成。

5.テスト

プログラム単体のテスト、関連機能を繋ぐ結合テスト、システム全体の機能を検証するシステムテスト、ユーザ側で最終的な検証を行う受入テスト

を行う。

ハイライトでは上記の内、読者の多くであろうユーザ側の視点が重要となる、要件定義、テストに加え、全体のプロジェクトを円滑に運営するためのプロジェクト管理について、起こりがちな問題や裁判事例を中心に紹介する。

【必読ポイント!】要件定義 ～「言った・言わない」と「やる・やらない」～

そもそも要件定義は何を決めるのか

KatarzynaBialasiewicz/iStock/Thinkstock

「もう設計も終わるはずの時期なのに、また要件からやり直し!そのうえ納期は全然延ばしてくれないなんて、お客さんヒドくないですか?」

冒頭の言葉はシステムベンダの経験があれば、多くの方が言ったことのあるセリフだろう。本書ではあまりにも多くのプロジェクトの混乱の原因となる要件確定の遅れから紹介されている。しかし、東京地裁の平成16年3月10日の判決によれば、ユーザの出す要件変更が及ぼすプロジェクトへの影響は、専門家であるベンダでなければ把握できない。要望を受けたときには、メリット・デメリットの検討、追加費用等をユーザに提示することが必要と判断されている。

つまり、ユーザのワガママでは済まされないのである。それを仕組みとするため、定期的に要件変更に関する会議を開くことが提唱されている。ベンダとしては、プロジェクト末期にユーザに泣きついても無駄であり、要件確定当初から毅然とした態度で合理的に接点を見いだす姿勢が求められるのだろう。

要件定義をベンダ任せにするユーザ

「今度のお客さんは『とにかく動くものつくってくれれば』って要件定義も一切お任せで、こっちの思い通りにできるから本当楽チン。」

本当にそうだろうか。著者はそれこそが危険な兆候であるという。