「漏れ」なく洗い出す知恵
まずは仕様バグの一つ目「漏れ」をなくす知恵を見ていこう。 漏れが起きる理由の一つは，エンドユーザーが要求を言い忘れることにある。例えば，サブシステムを追加したり，新システムにリプレースしたりするような案件の場合「エンドユーザーは新たに追加したい機能についての要求は出す。しかし，現行システムについては言及しない。『今のままで』で済まされてしまう。現行システムの仕様まで含めて要求を洗い出さなければならないので，これでは漏れが起きる」（CSKシステムズ IT生産技術部 副統括担当 白寄徹男氏）。 そのほか，エンドユーザーは“言わずもがな”だと思っていることは言わないし，そもそも要求定義で何を言えばよいかが分からないこともある。 漏れをなくすには，多くの要求をどうやって洗い出すか，業種/業務ごとに常識的な観点はきちんと考慮されているか，違う視点から見たら何か出てこないか――といったことがポイントに
図解を駆使して仕様バグをつぶす
図1●不適切なデータフロー図の例 要求定義と実装は分けて考えなければならないのに，それが交じっている。この段階で，データストアがファイルなのかテーブルなのかなどを定義すべきではない 便利な図解だが，使い方を間違えると役に立たない。まずは専門家に，「やってはいけない」ことを3点指摘してもらおう。 最初は「要求と実装を一緒に考えてはいけない」（オージス総研 取締役 ソリューション開発本部 副本部長 兼 アドバンストモデリングソリューション部 部長 山崎朝照氏）ということである。（図1）は要求定義でよく使われるデータフロー図（DFD）だが，書く内容が間違っている。「こうした不適切な図を前提に設計するとデータ構造がメチャメチャになる。メンテナンスに苦労する可能性が高い」（メタジトリー 取締役 松本聰氏）。 DFDでは，上下の二重線に囲まれた枠を「データストア」と呼び，処理されたデータの格納場所を表
エンドユーザーの要求は間違っている？
ムラウチドットコムの橋本昌巳氏（取締役システム担当）は，自社のECサイトの構築で，かつて次のような経験をした。 ある業務担当者に新機能が欲しいと言われて開発した。しかし，その機能を使うのはその人だけで，他の人は使わない。業務改善に寄与したかどうかも結局，分からなかった。担当者が異動すると，また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し，保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。 現場を取材していると，こうした要求定義（注1）にまつわる話は事欠かない（図1）。IPA（情報処理推進機構）のアンケート調査（注2）によると，9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏（ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア）は「業務要件の詰めの甘さ
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
