すこしのことにも先達はあらまほしきことなり：現場から見るSEの「地力」（1/3 ページ）

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

[杉山正二（アールエスコンポーネンツ），ITmedia]

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

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

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

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

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

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

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

教訓1：アプリケーション（システム化）の目的を共有せよ

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