コラム
» 2008年09月01日 17時04分 UPDATE

闘うマネジャー:「オープンソースを多用」だからこそ作るサンプルアプリ (1/2)

駄目なものは駄目、と言いたいけれどなかなかうまくいかないのがシステム構築。オープンソースを多用したシステムの場合はなおさら不安が先立つことが多いのではないか。少しでもプロジェクト失敗のリスクを減らすため、発注に際してサンプルアプリを付けることは効果が大きい。

[島村秀世,ITmedia]

憶病だからこそ備える手立て

 「まったく使いものにならない」と声に出して言いたいのだが、それを証明するのが極めて難しいがゆえにズルズルと手直しや妥協を繰り返し、結果的に、発注者側も開発者側も満足行かないシステム開発をしてしまうことは意外と多い。建築物のように強度や防水などの状況を調べ、「駄目なものは駄目」と言えたらいいのにと思うが、システムとなるとどうもうまくいかないのが現実だろう。

 駄目なものは駄目と言えるようにするためにはRFPがいいという人もいるし、できあがっているものを見て、使えるか判断できるようにASPやSaaSがいいという人もいる。筆者のようにオープンソースを多用したシステムについて、詳細な設計書を発注者側で用意するという人もいるだろう。どれが正解なんてことはもちろんないのだが、中途半端なのは困る。

 ところで、コンサルタントやシンクタンクの方々は上記のような問題について、「それぞれ最適な場面があるので、ケース・バイ・ケースですね」と答えると思うのだが、これは中途半端の典型例なのか、それとも逆で最善の解なのだろうか。筆者はこの辺に、「失敗しないシステム開発となる」か「失敗しやすいシステム開発となるか」の分かれ道があるように思う。

 長崎県庁ではいずれの地場企業も入札に参加できるように、格付けを行っていない。さらに詳細な設計書も用意しているので、「同様のシステムを構築した経験」等の実績を求めることもしていない。いいことではあるのだが、運用していくとマイナス面も見えてくる。設計書が丁寧かつ分かりやすく書かれていれば「これならできる」と安易に考えるベンダーがいて、このようなベンダーに限って「難しい」と投げ出すのではなく、「仕様書のここが悪い。あそこが分からない」と難癖をつけ、挙げ句の果てに発注者が悪いとして「もめる」ことが数年に一度くらいは発生する。実力が水準に達していないにもかかわらず入札に参加し、できないのをごまかすために難癖をつけるというわけだ。

 担当したベンダーが誠実あれば、設計書の不備に関しては「ミスはミス」として認め、追加作業分の費用を払うことで対処できるのだが、上記のような難癖型となると、追加費用など払うべきではない。ところで、誤解のないように断言しておくが、大多数のベンダーは極めて善良である。

 筆者は憶病である。

  • 憶病だから、分割発注し、もしもの時の被害額が最小になるようにした。
  • 憶病だから、各担当者に詳細な設計書を作ってもらい、システムの中身が分かるようにした。
  • 憶病だから、DBのテーブル・フォーマットは自身が管理し、好き勝手な項目が発生しないようにした。

 しかし、この程度では難癖型とは戦えない。もっと憶病でなくてはならないようだ。そこで、筆者は設計書作成の過程でチェックを入れ、難しそうな部分がどこかをピックアップし、その部分のサンプルアプリを作成することにした。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -