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

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

教訓2：アーキテクチャ（アプリケーションの枠組）はきちんと設計せよ

　ベンダーを含めて、アプリケーションアーキテクチャを設計できる人を見つけ出し、一緒に十分検討した上で、アーキテクチャを先に固めてしまう必要があった。PIMに類似したシステムなので、アーキテクチャを十分検討しなくても大きな問題はないだろうと安心していたのが間違いであった。

教訓3：データ設計は十分確認せよ

　機能の設計はある程度ベンダーに任せても大丈夫だが、データ設計およびデータベース設計は、十分にレビューする必要がある。このシステムの場合も、ER図を最初にきちんと記述しなかったために、一部の属性が誤ったエンティティにマッピングされてしまい、後々尾を引くことになってしまった。

　たとえば、製品の販売価格1つをとってみても、これは製品に直接紐付くものではない。弊社の例で言えば、カタログ期間中は販売価格を変更しないが、新しくカタログを発行するときには、価格を変更する場合がある。そうすると、製品エンティティとカタログエンティティを紐付ける販売というリレーションエンティティを追加し、販売価格はこのエンティティの属性とするのが適切である。この販売価格の例は簡単かもしれないが、データ設計を疎かにすると、似たような間違いを犯しがちである。

教訓4：ユーザーの現行業務を疑え

　ユーザーはどうしても現在行っている業務をそのままシステム化してほしいと考えがちであり、それを素直にシステム開発者やベンダーが受けてしまうと、大変なシステムになってしまう。あくまでもあるべき業務の姿を考え、その上で、システム化すべき、システム支援すべき業務と、マニュアルで行うべき業務とを整理する必要がある。良いSEは、ユーザーの言葉を鵜呑みにせず、常にWhyを問いかけながら、本当の要件を整理しなければならない。

教訓5：ユーザー部門の責任者（オーナー）を巻き込め

　上記の教訓4ともつながるが、システム化に伴って、現行業務を変更しなければならない、あるいは変更すべきと分かったとしても、その業務の担当者に納得してもらうことは容易ではない。そういった場合には、やはりユーザー部門の責任者を巻き込むことが必要不可欠である。

　ただし、注意すべき点は、この責任者がどういった人物かを理解しておくことである。意思決定ができる人か？　ITを理解している人か？　などなど。できれば、データ設計までできる人がいれば最高だが、多くを望んではいけないだろう。