目的と要件の整理でアーキテクチャは見える：現場から見るSEの「地力」（1/3 ページ）

教訓をどのように2次開発に生かしたか。（特集：顧客満足度ナンバーワンSEの条件）

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

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

　システム開発は、要件を満たせば、スピード、低工数、低リスク、適正コストを目指すのが当たり前の時代である。では、どのようにすれば良いのか？　皆さんが答えを求めている問いだろう。正解を示すことはできないが、こうすれば大失敗は防げる、という意味で、数多くの教訓を得ている。

　今回は、前回紹介した教訓を、どのように2次開発に生かしたかを説明するが、これはそのままアプリケーション開発のポイントにつながる。このようなポイントを押さえておけば、アプリケーション開発はほぼうまくいくはずである。

　まずは、前回の最大の失敗点を反省し、このシステムの目的（1. 製品の基本情報（特に国内で調達した製品）の維持管理、2. コールセンターが利用するための製品の付加情報（たとえば、代替品情報や販売終了予定情報）の維持管理と提供、3. カタログエラーの処理支援）を再確認した。

　幸いなことに、ベンダーの新しい責任者は、データベースの再設計を申し出てくれたぐらいだったので、私の考え方をよく理解してくれ、話はスムーズに進んだ。二人ともユーザーの話を鵜呑みにするのではなく、不要な機能は開発しない、ときっぱりと対応した上で、新機能や機能修正を設計することで合意し、二次開発を開始した。

教訓1（アプリケーションの目的を共有せよ）への対応

　この点は、今回ベンダーの責任者、システム部門のマネジャーがともに前回と交代し、私の考え方を十分理解してもらえたので、それほど苦労しなかった。あとは、ユーザーの担当者にどのように納得してもらうかが問題であった。しかしながら、責任者が交代して、信頼できると判断したら、後は拍子抜けするくらい良く協力してくれた。システム開発とは言っても、つくづく“人”と“コミュニケーション”の問題に行き着くことを実感させられた事例であった。

教訓2（簡単だと思っても、アーキテクチャはきちんと設計せよ）への対応

　この点に関しても、ベンダーの責任者がアプリケーションアーキテクチャの考え方をきちんと理解している人だったので、比較的容易にアーキテクチャの設計を進めることができた。具体的には、上記3つの目的を実現するために、次のようにそれぞれ別の設計思想で設計することにした。

・1.	製品の基本情報管理：この部分は、とにかくデータ設計とデータベース設計に注力する。データの入力や修正の機能は、基本的な機能に絞る。
・2.	コールセンターが利用する情報の管理と提供：この部分は、1.の基本テーブル群に手を入れるのではなく、検索や表示に最適化した付加テーブル群を用意し、あくまでも検索の容易性やスピードを重視する。
・3.	カタログエラーの処理支援：ここは、すべての機能をシステム上に実現しようとすると、とてつもなく複雑なものとなり、工数もコストも膨大になる。したがって、ユーザーと良く議論し、ある程度のマニュアル作業を残す方向で、シンプルな管理機能のみを実現することにした。