現役コンサルタントが語る
今回のポイント
発注する側として意識しなければならないのは「発注するタイミング」である。システム化への企画が煮詰まっていない段階で発注するとコストもかかるしSIerも困惑する。仕様が二転三転するようではいつまでたっても開発に着手できない。これも社内体制の確立と合わせて特に意識するべき点である。
今回紹介するのは、生鮮食品を扱う中堅企業でここではA社としておこう。同社で、販売先である顧客からの注文を受理し、仕入先へ発注する仕組みをオンラインで管理する仕組みをシステム化するというプロジェクトが発足した。このプロジェクトを担当することになったのが、そのときに新設された情報システム部である。
A社では受発注オンラインシステムの開発にあたり、事前に社内で企画会議を実施、活発に意見が交換された。こうしてできあがった土台をもとに、いよいよシステムインテグレータ（SIer)へ発注する運びとなった。このSIerは受発注系のシステム開発の経験もあり、また担当営業、SEともに信頼のおける人物という印象であったとA社の担当者は語る。
当時私は、A社の社内システム開発という別のプロジェクトに参加しており、さまざまなシステムを開発するA社に勢いを感じていたものである。私が担当したこの社内システムは、通常の業務を忠実にシステム化することが求められていた。一方の受発注システムは、ただオンラインで処理するだけでなく、仕入れ先の在庫を確認し、都合に合わせて仕入れ先を自動選択したり、異なる販売先からの同一商品の注文を安く仕入れられる組み合わせで発注するなど、人手での作業では煩雑になる処理を担うものであった。
この受発注システムは、業務の効率化と戦略的な営業支援という両面を併せ持っており、実現すればA社にとって強力なシステムになる。また一からのシステム開発で、なおかつ予算にも余裕があることから、SIerとしても腕の見せ所十分な案件だった。
A社からの要求が徐々にまとまりつつあるころ、A社とSIerとの間でシステム発注に対する合意が整い、契約を結ぶ運びとなった。開発費に対する正式な見積りはまだ先だが、ある程度の実作業が必要になり、それに伴う技術者の投入が行なわれるためであった。
ここでの「ある程度の実作業」とは、本格的な開発に先駆けて必要となる機能の検証などを行なうことだ。たとえば、サーバが謳い文句どおりの働きをしなければ、基本設計を行なっても意味がない。さらにパフォーマンスについての実績が報告されていないようなケースでは、なおさら事前の確認が必要となる。
また、登場して間もないデータベースなどでも、要求される処理能力があり、必要となる機能が問題なく動作するかどうかなどについて、先行調査として先駆け検証が必要となる。後から重要なツールについて「こんなはずではなかった……」と後悔しても、後の祭りになってしまうからである。
私の担当しているプロジェクトが終了し、A社の情報システム部の担当者やSIerの担当SEとも親しくなったことで、この受発注システムに私も参加することになった。
そこで初めて聞かされて驚いたのは、先行調査を始めてから半年以上経つのに、まだ設計段階に進んでいないという異常な事態に陥っていることだ。A社とSIerの双方から話を聞いたところによれば、打ち合わせのたびに追加の要求や仕様変更が発生するため、仕様が確定できないということであった。つまり、要件定義に手間取っているのだ。
SIerとしては、毎回のように出てくる要求を無視するわけにはいかない。また、A社の情報システム部の担当者も社内の意見を無視できない。関連部署から出る新たな要求や、あったら便利だと思える機能について、ただの思い付きと切り捨てるわけにはいかず、調整に苦労しているという状況だったのだ。
ただしA社としてはすでに先行調査に関する契約を行ない、技術者も受け入れているため毎月の支払いが発生している。SIer側としても、仕様が固まり発注されたときのために、SEやプログラマといった技術者を、いつでも投入できるように万全の体制を敷いている。A社の「せっかく作るなら、良いものを作りたい」というシステムに対する思いは理解できるが、どこかである程度割り切らないと、いつまで経ってもシステムは完成せず、コストばかりが積み上がってしまうということになりかねない。
 |  |
|---|
現役コンサルタントが語るシステム開発の落とし穴
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】
