仕様変更の常識(2)-ウォーターフォールの仕様変更の性質

2018年8月22日水曜日

システム開発

t f B! P L
 仕様変更の性質について解説する。
 どうかこれを把握して「正しい仕様変更」を行って欲しい。

 ウォーターフォールは「要求分析」「要件定義」「設計」「開発」「テスト」「納品」「検収」「導入」を順番に進めていく開発手法だ。

 通常の「設計」は「基本設計」と「詳細設計」に分かれる。
「基本設計」というのは細かい部分は設計しないで具体的な機能とデータ構造のみ設計する工程である。データ構造以外は非情技の業務担当者にも理解できるものが多い。(絶対では無いが)

 また、一般認識は無いが「開発」は「共通部開発」と「個別開発」に分かれる。
 どんなシステムでも複数の画面があるように、システムには個別の機能が複数ある。それぞれをバラバラに作っていたら生産性が著しく悪くなってしまう。だから複数の機能に跨いで使用する機能は「共通部」として先に開発しておく。「個別機能」は完成した「共通部」を利用して開発する。言わば「共通部」とは「ソフト部品」である。「先に部品を作らなければ製品を組み立てることはできない」と言えば分かるだろうか。

 さらに「テスト」には「単体テスト」「結合テスト」「ユーザーテスト」がある。この三つはどんな単純なシステムでも必ずある。大きなシステムならもっと増える。
 「単体テスト」は個別部をバラバラにテストするもの。
 「結合テスト」は個別部を全て組み立ててテストするもの。
 「ユーザーテスト」はシステムを実際に使用するユーザーにテストしてもらうもの。「検収」と似ているようだが違う。「ユーザーテスト」の段階ではまだ十分な品質には到達していない。不具合も有る。「検収」は納品後に行うものだから不具合があってはならない。

 以上を図で表すと以下のようになる。

要求分析→要件定義→基本設計→詳細設計→共通部開発→個別開発→単体テスト→結合テスト→ユーザーテスト→納品→検収→導入


 仕様変更は前工程で発生するほど修正範囲と手戻り工数が多くなりコストと時間が掛かる。多重請負などの問題は複雑になるので割愛する。

 発注元(業務担当者)による仕様変更は「要求分析→要件定義→基本設計」の三つの工程の何れかで発生する。
 詳細設計以降は発注元(業務担当者)には理解できない。この工程での仕様変更はITベンダーの裁量下にあり問題ない。

 「要求分析」は業務の分析なので本来は発注元(業務担当者)の仕事である。ITベンダーは助言をするだけだ。「要件定義」も「どんなシステムを作りたいか」を定義したものなので発注元(業務担当者)の仕事だ。「どんなシステムを作るか」を受注者のITベンダーが決めるなんてナンセンスだろう。レストランで食事をする時、店が「あなたはサーロインステーキを食べます」と決めて勝手に持ってきたらどう思うか ?
 普通は注文する側が決めるものだ。
 「要求分析」と「要件定義」に訂正が発生し仕様変更が必要になったら完全に発注元(業務担当者)の責任なのだ。その事は自覚して欲しい。
 「基本設計」はITベンダーが行うのでITベンダーの責任だが、通常は詳細設計に入る前に基本設計の内容に問題が無いか発注元に確認しているはずだ。そこで発注元が承認しているから詳細設計に入っているので、これも発注元にも責任がある。

仕様変更し難いタイミング


 繰り返すが、仕様変更は前工程で発生するほど修正範囲と手戻り工数が多くなりコストと時間が掛かる。

 仕様変更を行う場合にどれだけ追加コスト(と時間)が発生するかは「現時点での進捗」によって違う。進捗が進んでいればいるほど追加コスト(と時間)が嵩む。

 なぜかといえば「ソフトウェアは全ての工程が試行錯誤である」ということを以前説明した。仕様変更は「既に完成している試行錯誤の成果物」について「試行錯誤をやり直して成果物を修正する」ことになるからだ。「日本人は目に見えないモノの価値を無視する」から「手も動かしていない試行錯誤に何で金払わなければならないのだ!」と文句を言う奴は山ほど居るが、現実に試行錯誤にはコストと時間が掛かる。仮にソースコードの修正量が少数であっても「その修正が正しいかどうか」にはバカにならない検証と試行錯誤が必要になる。

 進捗が「詳細設計」であれば「詳細設計」だけ修正すればよい。
 進捗が「共通部開発」であれば「詳細設計」と「共通部開発」を修正する。
 「個別開発」であれば「詳細設計」と「共通部開発」と「個別開発」を修正する。
 「ユーザーテスト」であれば「詳細設計」から「ユーザーテスト」まで全て修正対象だ。「テストで何を修正するのか?」と疑問に思うかも知れないがテストには「何をテストするか」を決めた「テスト仕様書」が必要になる。また。最近はテストの一部を自動化しているので「テストコード」というテスト用プログラムのコードを修正しなければならない。

 以上の理由により進捗が後工程に及ぶほど仕様変更のコストは高く付く。コストを最小限にしたければ「できる限り早く仕様変更を済ませる」べきだろう。
 つまり多くの場合仕様変更はユーザーのミスや検討不足が原因で起きるので「早い段階でミスに気付け!」ということだ。設計に入る前に気付いた方が良いのは言うまでも無い。

仕様変更し易い場所、し難い場所


 システムの何処を仕様変更するかによってもコストは大きく変わる。あまりコストの掛からない場所と「ほとんど全てに修正が及ぶ」場所がある。
 修正コストが安いのは「個別部」である。画面の一部だけとか出力ファイルの一部を修正するなど「他の部分に影響しない」仕様変更であれば安く早くできる。
 逆に「共通部」はほぼ全ての「個別部」に影響するので修正コストが高く付く。
 特にシステムの骨組みに当たる「データ構造」を変更すると内容しだいでは膨大な修正コストが発生する。「基本設計」の段階から再検証しなければならなくなる。場合によっては「設計思想」を変更しなければならなくなる。

 この変は非情技に理解できるように説明するのは困難なので詳細は割愛する。回を改めて説明したい。

 システムには構造的な意味での逆ピラミッド型構造があると思って欲しい。下の頂点が共通部やデータ構造。上の広がっている方が個別部である。上は下に従属している。従って下を変更すれば上に影響する。上の方が広がっているので下の変更ほど影響が大きい。



 最悪の仕様変更は「進捗が最終テスト段階で、共通部データ構造を変更する」ものである。ここまで酷いのになると仕様変更に応じられないことも多い。だいたい非道いトラブルになる。

 最初の「要件定義」の段階で情技師からデータ構造に関する説明とレビューはやっているはずだ。この段階で慎重に間違いが無いか確認しておくべきだ。ここで手抜きをすると後に多くの無駄なコストを払うことになる。
 前工程ほど石橋を叩くように慎重に良く考えて取り組むべきだ。特に発注元の業務担当者がだ。

次回はアジャイル開発の仕様変更について語りたい。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ