Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第1回 【壱】書いてある要件はやらねばならない。書いてない要件はやってはいけない。

  2007/10/25 12:00

 システム開発において大切なことは、何を作るかについて開発依頼者と、開発受託者の認識しているものが一致していることです。そのために要件定義書は大変重要な書類となります。

要件誤りか? 要件理解誤りか?

 要件定義書は、一般的には日本語、つまり自然言語で記述されますので、同じ言葉を使っても違ったものを頭にうかべることがおこりえます。例えば、「1年満期の契約の満期日には…」といった処理記述があった場合、この満期日は1年後の同じ日でしょうか、それとも、その1日前? うるう年の時は? 正解をはっきりさせなくてはいけないですね。

 また「入力は、当該部門の担当者にのみ許される」と言った場合、当該部門の範囲や、臨時雇用のスタッフなどの扱いはどうなるのでしょうか? こういったことが曖昧では、セキュリティ上の入力権限チェックの仕組みがうまくできる保証はありません。

 どの業界にも、常識となっている事柄があります。そういったことについて開発受託者は必ずしも熟知しているわけではないので、要件定義書は可能な限り、記述について具体的であることが求められます。

 トラブルが起こると、よく要件誤りか、要件理解誤りかが問題になります。

 「これを、そういう風に読むの? かんべんしてよ…」とか、「こんなの常識じゃない…」とか、言い合う光景が目に浮かびます(常識なんて人によって違いますよね)。

 そして、極めつけが、「こんなの書いてなくても当たり前じゃない(規程には無いけれど)、うちのシステムでは必ずやることになっているのですよ…」などといった話になるケースです。

 この場合、逆もあります。「いつもこの処理が入ることになっているので、要件定義書には書いていないけれど、入れておきました」「ここだけ、このロジックがないのです。書き洩れと思って入れておいたのですが…」といった具合です。

 怒りたいのだけれど、どう怒ったらいいのだ・・という気持ちになります。やった方も、良かれと思って気を利かして、結果が始末書では…浮かばれないですね。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管理の向上を実現。2005年から株式会社アイネス。経済産業省・プロセス改善研究部会主査、同・開発プロセス共有化部会副主査。東京海上日動システムズ技術顧問。情報処理学会IS研究会委員。JUAS主席研究員。JISA要求工学調査委員会委員。 著書:SEC BOOKS「経営者が参画する要求品質の確保―超上流から攻めるIT化の勘どころ」(オーム社・共著)、「実務で役立つプロジェクトレビュー」(翔泳社)

バックナンバー

連載:開発担当者必携!トラブル削減のための原則拾七ヶ条

もっと読む

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5