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

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

教訓3（データ設計は十分確認せよ）への対応

　ベンダーの責任者が変わったことである程度データ設計も任せられると思ったが、同じ失敗は繰り返したくないので、ER図をきちんと記述し、それを最初に提出してもらうようお願いした。そのER図をシステム側のマネジャーと私で十分レビューし、若干の修正を加えた上で、データベース設計に進んだ。この場合のレビューでも、上記の設計思想を意識して、1.に相当する製品基本データの部分は、特に時間をかけた。おかげで、その後の機能設計もうまく進み、パフォーマンスの問題から若干設計変更が必要になったものの、データベース設計も大きな問題なく順調に終了した。

教訓4（ユーザーの現行業務を疑え）への対応

　このシステムの場合、特に問題となったのは、上記3.の領域である。ここに関しては、ベンダーの責任者に対しては、「安易に実現できます」とは言わないようにお願いした。その上で、システム部門のマネジャーに対しては、あるべき業務の姿を考え、その上で、システム化すべき、システム支援すべき業務と、マニュアルで行うべき業務とを整理し、さらにユーザーと十分時間をかけてレビューするよう、指示した。おかげで、ユーザーも納得した上で、マニュアル作業を残すことを了承してくれた。

教訓5（ユーザー部門の責任者を巻き込め）への対応

　この点に関しては、直接的にこのアプリケーションを利用するチームの責任者レベルでは不十分なので、その上長まで含めて、プロジェクトに巻き込み、二次開発を推進した。さらに、この二次開発の費用対効果分析をきちんと行った上で、二次開発稼動後の実現効果を測定し、報告させるような仕組みを取り入れた。これによって、関係者も真剣に参画せざるを得ず、うまくユーザー部門の責任者を巻き込むことができた。ちなみに、二次開発によって、期待していた効果は、担当者の作業工数削減という形で、十分実現できたことを付け加えておく。

教訓6（データ／データベース設計に大きな問題を発見したら、直ちに開発を中止して、設計をやり直せ）への対応

　この点に関しては、上述したとおり、ER図のレビューから始まって、データ設計、データベース設計のレビューには十分時間をかけ、注意を払った結果、大きな問題は発生しなかった。何度も言うが、データ設計の重要性をまたしても思い知らされたシステム開発でもあった。

　ここまで読まれた読者の方であれば、二次開発から新たな教訓を読み取られたはずである。