仕様変更に打ち勝つ
上流で固める仕様を絞り、変更前提の開発手法を取り込む
書誌
| text | 唯野 |
| author | 森山徹 |
| publisher | 日経 BP 社 |
| year | 『日経オープンシステム 2002.4』p.94-115 |
履歴
| 2002.4.16 | 読了 |
| 2002.4.16 | 公開 |
| 2002.11.28 | 修正 |
感想
ソフトウェア開発における「仕様変更」はよくあることであり、既に仕様変更のないことを前提とした開発手法はありえない。個人的に日経オープンシステムは「おっ」と感じる特集でも実際に読んでみると総論的でいまいちという印象を抱くことが多い。実際のユーザ事例は非常にありがたいだけに、もう少し踏み込んだ内容だともっとよいのにと思う。
抄録
94-96
昨今の仕様変更の原因の多様化。特に新しい試みを行う際に仕様の詳細を後から詰めていく(詰めざるを得ない)という傾向が出てきている。当然、ウォーターフォール型では対応できないため、要求仕様よりも設計に時間をかけ、スパイラル型アプローチを取るといったスタイルが取られることになる。
- 開発期間の短期化
- 開発時に仕様を決める案件の増加
- 外的要因による仕様変更の増加
96-99
上記の問題解決のポイントとして以下が挙げられる。かつ、それを短期間で成果として結実させる必要がある。もちろん、基本はユーザと SE のコミュニケーションであり、そこから仕様を肥大化させずに漏れをなくしていくということ。また、優先度によって範囲を絞り込むことも重要となる。一方、決定項目に関しては、変更の影響の大きくなるものを先に決めてしまい、GUI などは大体のところで開発に入るといった切り分けを行う。
- 過不足のない仕様作りとユーザの合意を得る手法
- 設計時の決定項目とそうでない項目の切り分け
- 仕様変更を前提とした開発手法の整備
100-103
システム化の範囲を重要度で絞るのは仕様を肥大化させない上で有効な手段となる。(コア機能と周辺機能とに切り分けて、コア機能から着手するなど。)逆に入り込みやすい仕様として、既存システムの機能やレア・ケースをそのまま含めている場合などがある。これらはワークフローとして処理の流れを整理しユーザからの合意を得るというのが一般的な手段となる。レア・ケースの場合は費用対効果とシステム以外の代替手段の提示がポイントとなる。同時に判断しにくいものは後回しにするという切り分けも求められる。
ユーザの潜在的な要求に対しては、ヒアリングで得たことを突き詰めて捉える、誰のための要求かを考えてみる――のがよい。その上で、そのような質問をユーザに発することでユーザ自身に気付かせるというスタイルがある。また、関連部署を含めて関係者全員の揃う場で確認を取り、成果を共有するようにする。なかなか仕様の固まらない場合には、集中ミーティング(普段とは別の場所、基本的に解決するまでエンドレス、関係者は全員参加)で問題解決の意識を広めるのが効果的である。また、ユーザ側に完璧を期するのではなく、余裕を持たせることも必要。
104-107
決定項目の切り分けは以下のようにまとめられる。
| 設計項目 | 重要度 | 説明 |
| データ項目 | 高 | 桁数も含め変更のないようにする |
| 画面(入出力) | 高 | データ項目に関連するため |
| 画面(GUI) | 低 | プロトタイプを元にユーザによるチェックを行う |
| 帳票レイアウト | 低 | データ項目が固定されていればユーザからフィードバックが得られる |
| セキュリティ | 高 | 使い勝手とのトレードオフを勘案する |
| パフォーマンス | 低 | テスト時のチュー二ングで向上できる |
その上でシステム的な仕様の説明に関しては、ユーザの理解の得られる資料・ツールの利用が効果的となる。具体的には UML の利用などが挙げられる。UML は要求分析ではユースケース図、クラス図、オブジェクト図、ステートチャート図、アクティビティ図などが有効で、設計時にはクラス図、オブジェクト図、シーケンス図、コラボレーション図などに重点をシフトさせる。
108-111
仕様変更を以下のように切り分けることで、後に回せるものを判断していく。ほかに費用対効果で見てすぐに対応できるものは対応する、スパイラル型で変更差分を後から取り込むなどが挙げられる。いずれにしても影響範囲の把握がまず重要になる。また、パフォーマンスを得るための仕様変更、短期開発に伴うカットオーバー後の仕様変更などもある。
- 業務上必須
- 運用で回避可能
- スケジュール内で対応可能
- 運用で回避(スケジュール内で対応不可能)
全文を読まれる場合はログインしてください
Up