特集
» 2005年06月13日 00時51分 公開

現場から見るSEの「地力」:すこしのことにも先達はあらまほしきことなり (1/3)

失敗に学ぶシステム開発。(特集:顧客満足度ナンバーワンSEの条件)

[杉山正二(アールエスコンポーネンツ),ITmedia]

  杉山正二(アールエスコンポーネンツ 取締役)

 「基本的にはなるべくカスタムの開発はしない」という前提に立ち、いかに既存のソリューションを有効活用、応用していくかが、リスクを最小限にし、短期間で品質の高いアプリケーションシステムを構築するカギである。今回は私の失敗から得られた教訓を紹介したい。結果的にカスタム開発になってしまった例だが、皆さんの参考には十分なるだろう。

 今回は、私の失敗例を基に、そこからどのような教訓が得られるかについて、単にパッケージかカスタムかを超えた視点で説明してみたい。

 失敗した対象のシステムは、図に示すように、製品情報システムである。このシステムの主な目的は、1.製品の基本情報(特に国内で調達した製品)の維持管理、2.コールセンターが利用するための製品の付加情報(たとえば、代替品情報や販売終了予定情報)の維持管理、3.カタログエラーの処理支援、である。

 私の目論見では、1や2の目的に必要な基本データや基本機能は、まさに製品マスターやPIMと呼ばれる範疇のものなので、当然、そういったパッケージをベースに検討すべきだと考えていた。

 必要なシステムも、1〜3のカテゴリーに分けて整理して検討していけば、それほど難しくなく設計できると思っていた。したがって、ユーザーにはもとより、ベンダーに対してもその旨をよく説明し、既存のパッケージや他社で開発した同様のシステムをベースに要件を整理し、機能を設計してもらうよう、お願いをしていた。

 しかも、特殊なアプリケーションではないし、目的も明確になっている。また、それをきっちりユーザーとベンダーに伝え、それも理解してもらえたと考えていた。あとは、システム部門のマネジャーとベンダーが中心となって、うまくユーザーを巻き込みながら、問題なく開発が進むものと確信していた。しかし、残念ながら、結果は大きく違ってしまった。

教訓1:アプリケーション(システム化)の目的を共有せよ

 この点は、私自身、目的をきちんと関係者(この場合は、ユーザー、システム部門のマネジャー、ベンダー)に伝え、共有したつもりであった。しかし、実際は十分共有されていなかった訳で、文書化するなど、もっと確実に共有できていることを確認すべきであった。結局、目的が曖昧になり、ユーザーの担当者の意見に押されて、上記3.中心のシステム機能の検討になってしまった。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -