Shoeisha Technology Media

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

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

テーマ別に探す

第2回 【弐】「~と同じ」という要件はない。「~と同じにする」ための要件定義をする。

  2007/10/25 12:00

 よく「いつもと同じ」というニュアンスで要望が出されることがありますが、は「いつも同じ」はいつも同じではありません。なにが「同じ」なのかをはっきりとさせるところがトラブル削減のポイントです。

「いつもと同じ」はいつも同じではない

 「今と同じ」「前と同じ」、「他と同じ」、「いつもと同じ」、私たちが生活の中でよく使う便利な言葉です。私もよく床屋さんで使います。それでも春夏秋冬、「いつもと同じ出来上がり」は微妙に異なります。この言葉、厳密さを要求されるシステム開発の場でも頻繁に使われるのですが、使われた時、よほど気を付けないと、とんでもないトラブルの種となります。

 例えば、システムを作り直し、業務の効率を上げようなどというプロジェクトが行われた場合を考えて見ましょう。業務設計をしている時、「この部分は今と同じでよい」などという決め方をよくします。業務要件としてはある意味大変わかりやすいものなのですが、それを実現するためのシステム開発となると、「今と同じ」…でよいケースは希、ほとんどないと言ってよいでしょう。

 頼む方は、今と同じに使えればよい、とすることは、極めて明快な要件定義と思っているケースが多く、加えてどこか直さなくてはいけないのかもしれないが、同じでよいのだから簡単だろうと思うのが一般的です。今のを作った時の要件定義があるだろうし、今動いているものがあるのだからそれ以上に明快な明確でわかりやすい表現はないと確信しているわけです。そもそも、なにも直さなくていいのでは? と、思っている場合もあります。つまり一般的には簡単だと思っていることが多いように思われます。しかし、作り直して、全く同じ機能のものを作るのは神技です。不可能と言ってよいでしょう。

 受ける方も、「同じでよい」と言われた時、あまり考えずに「同じでよい」を、要件として飲み込んでしまった人には、同じに動くように作るための要件定義が必要、などということは意識の外だと思います、結果、作りはじめてから、次々と、ここはどうしましょうということになります。

 さらに、同じにするために要件定義が山ほど発生することがある…などとは思いもよらない開発依頼者は、「同じでいいと言ったじゃない。そのくらい調べてよ」という態度になりがちです。同じにするために次々に沸いてくる、課題、難問に真剣に受け答えてくれないことさえおこるのです。これではシステム開発がうまく行きません。開発依頼側にはイライラと不信、開発受託側には赤字と徹夜が待ち構えています。

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


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


著者プロフィール

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

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

バックナンバー

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

もっと読む

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