TOP
＞
システム開発
＞ ITモデルのデメリット
ながさきITモデルへの参画 〜 地場SIerの官公庁システム開発奮戦記
第３回：上流工程に携わることによる、本当の意味での下請けからの脱却
著者：
ドゥアイネット 穴井 春奈
2006/5/10
1
2
3
次のページ
ITモデルのデメリット
入札方式でシステム受注ができる「ながさきITモデル」は、受注企業にとってメリットばかりではない。結局、一般競争入札は札入れした金額が他社よりも高ければ落札できないのだ。受注企業にとってのデメリットには次のようなものが考えられる。
受注計画が立てにくい
県は情報システムにおける年間の発注計画をオープンにしていない。いつ頃、どの規模の入札案件が発生するのかわからず、企業側としても、売上や人員計画の見通しが立てられない。ましてや落札できなかった場合のリスクを考えると、一般競争入札に対して、消極的にならざるを得ない面があることは否めない。
システムの全体像が見えにくい
ながさきITモデルでは1つのシステムをある機能ごとに小分けにし、複数の案件として発注を行う。
第2回
で説明した休暇システムでの小分けの単位を例にとってみると、職員が休暇届を申請する機能で1つ、管理者が申請データを修正・承認する機能で1つといった具合だ。この2つをそれぞれ違う企業が受注した場合、ある企業は申請機能だけ、ある企業は管理機能だけとバラバラに担当することになり、システム全体としての流れがつかみにくい。
図1：システムの全体像が見えにくいというデメリット
金額設定の難しさ
システム開発の採算は度外視してでも、県のシステム開発実績が欲しい会社もある。最も低い金額を見積もった会社が落札するという一般競争入札の仕組みに乗じて、まったく採算を度外視した金額で落札する会社が現れた。
このように入札でのシステム受注では価格競争におちいりやすいため、同じ地場企業であっても企業体力のある会社にはかなわない。大手の場合は開発人員も資金もある。ただこの件に関しては各地場企業も不満だったらしく、様々な意見を県に提言したようだ。
最終的には入札における最低制限価格が調整され、「安ければ落札できる」ということはなくなった。しかしながら、この最低制限価格はどう見積もればよいのか判断しかねるものであり、企業努力で開発工数を減らして見積り金額を抑えて入札に参加しても、結局は最低制限価格を下回ってしまって失格となってしまうこともある。
本当の意味での下請けからの脱却
このように、ながさきITモデルにはメリットだけではなく、デメリットも存在する。受注企業にとって、入札への参加の判断については利益に繋がるかどうかが一番の焦点ではないだろうか。入札では発注単位とリスクが小さく分割されているので、リスクが少ない分利益も少ない。入札では企業の大小に関係なく自治体案件を受注できるチャンスが平等に与えられているだけであり、実際の開発自体はオフショア開発と同じなのである。
当社にとっては、入札に参加するだけでは今までの下請けと同じである。入札案件に対して利益を求めること自体がおかしいのではないだろうかとさえ思えた。オフショア開発に利益を求め、30年先まで企業が生き残っていけるかは疑問である。そうではなく、何かに特化して下請けから抜け出していかなければ、当社もいずれは淘汰されるような厳しい時代なのではないだろうか。
そう考えると、今後生き残っていくためには設計など上流工程での付加価値の高い仕事ができるようになる必要がある。
入札をきっかけに県のシステム開発に携わり、県職員との関わりの中で信頼を築いていく中で、より上流工程の設計業務を受注していくことが人材・企業の育成に繋がり、本当の意味で下請けから脱却することに繋がっていくのではないだろうか。
下流工程から上流工程へ
当社は休暇システム開発の一般競争入札を落札してから、改修も受注して実績を積み上げており、徐々に上流工程である設計支援・仕様書作成業務を依頼されるようになった。これは「ながさきITモデル」の「詳細な仕様書を作成する」というフェーズであり、県の担当者が中心になって行われるのだが、システム設計の専門的な部分になるとどうしても専門家の支援が必要になってくる。そこを当社でサポートすることになったのだ。
この時システム設計を担当したのは当社SEである井川だった。今まで大手ベンダーのSEから設計を依頼されてきた井川だったが、長崎県から依頼された仕様書の書き方には戸惑いを隠せなかった。これまで井川が経験してきた仕様書作成では、企業によって仕様書の定型フォーマットがあり、画面遷移図／テーブル関連図／処理概念図などのフォーマットに合わせてプログラムの機能や処理を書けばよかったのだ。だが、長崎県が求める仕様書にはフォーマットがない。
井川は島村参事監が作成した仕様書を参考にして書きはじめたが、その仕様書は島村参事監から酷評を受けた。今まで井川が経験してきた仕様書作成は、あくまでプログラムの付録のようなものだったのだ。だが県が要求する仕様書には、業務の流れや注意事項など、プログラムを作る側に何のための処理か理解してもらえるように書かなければならない。
島村参事監はこういった。
「フォーマットも大事だけれど、一番大事なのは仕様書を読んだ相手がすぐ理解して納得できることであって、フォーマットを守ることではありません。相手に理解してもらうには『絵』や『図』が一番効果的でしょう。仕様書は作り手に理解させようと書くものではないのです。相手に理解してもらおうという気持ちがなければ、いい仕様書は書けません」
つまり分割発注だからこそ、図や絵を用いて誰にでも理解でき、開発者によって解釈の違いを発生させない仕様書を書くことが重要なのだ。また開発者が業務内容を理解することによって、開発段階での仕様の誤りを発見することもできるようになる。
そのためには仕様書の書き方を工夫していかなければならない。最初は当社の仕様書作成の表現力は低く、島村参事監に何度も仕様書を突き返されて書き直しを命じられたが、それに比例するように井川の仕様書作成技術はレベルアップしていった。
1
2
3
次のページ
「長崎県スケジューラー紹介」
ドゥアイネットでは、リッチクライアント言語を使ったスケジューラーを開発致しました。直感的な操作性とストレスを感じさせない処理スピードで、事務の効率化とコストダウンを実現しています。デモサイトが公開されていますので、ぜひ一度お試しください。
機能詳細はコチラ（実際に体験できるデモサイトをご用意しています！）
http://www.doinet.co.jp/activity/scheduler/
著者プロフィール
株式会社ドゥアイネット 穴井 春奈
システム技術部2課 チーフ。
前職は一般事務。もっと自分にしかできない仕事をしたいという思いから転職を決め、ドゥアイネットに入社して4年。現在は長崎県電子自治体プロジェクトに携わり、設計から開発までをこなす。
INDEX
第3回：上流工程に携わることによる、本当の意味での下請けからの脱却
ITモデルのデメリット
手当システム 〜 分割発注のプロジェクト
できあがった完成品の使い回しのメリット
