エンタープライズ

現役コンサルタントが語る

システム開発の落とし穴

2006年4月12日　　文●システムクリエイト代表取締役
田中徹

第5回
開発会社への発注のタイミング（2/2）

企画会議にSEを同席させる罠

　こうした現状を打破するために、まずSIerの担当SEとじっくり話を聞いてみると、「A社の意気込みや、システムにかける思いを十分感じるので、『要求はここら辺にして、そろそろ設計段階に……』とはなかなか言い出せない」という、想像したとおりの悩みを抱えていた。確かに、見切り発車で設計に進めば後々揉めることになるのは明らかであり、SEとしては要求を打ち切るのはなかなか難しい。

　しかし、なぜこれほどの期間に渡ってA社で仕様が決まらなかったのか。その理由は、SIerとの話し合いの場が社内における企画会議と同じレベルになってしまっていたからである。

　さまざまな意見を交換し、システムを検討する企画会議を実施するのは大切なことだ。これを何度か繰り返し、システムの方向性や一定の機能の絞り込みを行なっていくわけだが、A社ではこの企画会議をSEを含めてやっている状態になってしまった。こうなれば、当然のことながらSEに対してリクエストばかりが増え、あれもこれもという話になってしまう。こうした状況になれば、なかなか仕様が決まらないのも当然の帰結である。

　システム開発の専門家がいる席で企画会議をやれば、いい知恵が借りられるかもしれない……という気持ちは理解できる。しかし本来であれば、社内でどういった機能を実現するのかをあらかじめ決めておき、その後にSIerにシステム化へ向けての調査や設計を行なってもらうのが順序である。

　企画・立案にSEや技術者を入れることに良い面もある。技術者が実務を理解している場合、業務をシステム化するに当たっての手法、機能について、最善の方法をアドバイスしてくれる。しかし、今回のこのケースに限って言えば、開発要員としてのSEはやはり無駄であったというほかない。

　続けて、A社の情報システム部の担当者や関連部署、そしてプロジェクト責任者である役員にいたるまで話を聞いた。全体としては「システムを作る以上は良いものにしたい」「充実した機能を揃えたい」「すべての部署で満足できるものにしたい」という話で、前向きな姿勢が十分に伝わった。しかし同時に、これだけの意識があれば次から次へと要求が出てくるのも無理はないとも感じた。

　A社の担当者とSIerのSEだけではラチがあかないということで、私もこのプロジェクトに本格的に参加することになった。言い方は悪いが、こういうぐずぐずした状態のプロジェクトには、新しい人を参画させることで、体質が変わることもある。A社の役員もそれを見越しての依頼だろう。

　まず私は、A社に対して「要求仕様が変わりすぎる。これではSIerも設計・開発作業に進めない」と諫言した。さらに関連部署を集めた席において、「この日までに提出された要求に従って設計を行ないます」と伝え、スケジュールを引き直した。情報システム部の担当者には、「今後SIerと相談して決めることではあるが、場合によっては一次開発、二次開発と分けるかもしれないので、機能の優先順位をつけてください」と念を押した。

　一方担当SEにも、事情は分かるが開発経験を活かしてもう少しリーダーシップを発揮してもよかったのではないかと忠告した。

開発会社への発注は
企画書をまとめてから

　今回のケースは、企画・立案の段階から、開発のための技術者を集めてしまったことが原因だ。A社も気づくべきであったし、SIerもそれを指摘するべきであった。では、開発会社にはどのタイミングで発注するべきなのだろうか。

　システムの性格、規模、内容によって一律で語ることはできないが、1つのタイミングとなるのは、社内でシステム化への企画書をまとめてから、だろう。企画書ができ上がるということは、機能の洗い出しがある程度終わっており、全体像が明確になっているということである。これは、既存の業務をシステム化へ移行する場合などに当てはまる。

　一方、新規事業でシステム化と同時に業務が始まるといったケースでは、企画の段階から技術者が参加してほしい場合もある。システムコンサルタント的な役割を期待して、SEに入ってもらうというわけだ。このように、開発会社に依頼する時期も、内容によって異なってくる。不安であれば経験値の高いコンサルタントに依頼し、助言を求めるのがベストだろう。

　最後に、ユーザー企業が開発会社に提出する企画書について少し触れておこう。「良い企画書」というものについて、これが絶対だ、というものがあるわけではない。しかし開発するSEにとって見やすい、分かりやすい企画書というものはある。

　まずはシステム化する業務範囲の全体像が明確になっていること。これが明確でないと、SEはシステムの範囲を想定しにくい。さらに、機能について、なぜその機能が必要か、どういう役割を果たすのかという詳細な説明があると、代替案やさらに優れた提案がしやすくなる。そして稼動環境や開発環境について、制限があるのか、あるいは開発側で最適なものを選択する余地があるのかという点についても記述したいところだ。