脱力感の中、年内のサービス開始は不可能だと悟りつつ、また重い選択肢を突きつけられます。
１つは開発中止。既に費やした費用は戻って来ないが、追加費用も発生しない。
もう１つは開発継続。開発済みのシステムを活かせることが可能であるが、追加費用が発生する。
この時点で私は、WEBシステムの外注に当たり１つの結論に至りました。
【プログラマーは指示されたことしかしない】
後から、別のシステム開発会社にお勤めの方に伺ったところ、最近の若いプログラマーに特にそういう傾向があるとのこ
とです。
また、私はこのころ、システム開発の基本、プロセス、仕様書策定、開発言語についての書籍を読みあさり、今回のシス
テム開発案件の問題点を探っていました。
『開発言語』
まず、開発言語として選択したJAVA言語ですが、外部からの改ざんに強いなど堅牢性とセキュリティに優れている反面、
後から修正を加えるということが苦手です。
ある程度システムが組み上がり、機能不足や不都合な部分を発見しても、簡単に修正することが出来ません。
機能を後から追加するには、初めから機能を追加することを想定して開発しなければならない、という部分がJAVA言語は
特に厳密に要求されるようです。
また、JAVA言語は、他の言語に比べて開発費用が高く設定されています。別のPHPやPerlであれば、おそらく3/4程度の費
用に抑えられたはずです。これは、別の開発案件でJAVA言語で組んだ場合とPHP言語で組んだ場合の費用比較をしたとき
に分かりました。
さらに、JAVA言語は、サーバに要求する能力も高くなります。
一般的なレンタルサーバレベルでは動きません。
ハイスペックな専用サーバが必要になります。当然、ハイスペックなサーバは維持コストも高くなりますから、トータル
コストが一気に跳ね上がります。
『プロトタイプの問題点』
プロトタイプを用意することで、仕様書では分からないヴィジュアル（見た目）のチェックを事前に行えるというメリッ
トがあります。
しかし、「あくまでプロトタイプ」なのか「これが完成イメージ」なのか、時に判断に迷います。
「これで本番システムの開発に移行して良いですか？」と聞かれたとき、明らかに機能不足やイメージとかけ離れていれ
ば指摘しますが、細かい部分は「プロトタイプだから仕方ないのかな？」と思ってしまうのです。
それはまるで、まるで完成品のような下書きを見せられたときの気持ちに似ています。
しかし結局、プロトタイプのユーザーインターフェイスがそのまま完成品として納品されたとき、「やはり指摘すべきだ
った」と後悔することになります。
このことから分かったのは、プロトタイプは「機能が動かない」だけで、デザイン面やインターフェース周りはそのまま
完成版に引き継がれるということです。
『要件定義』
これは全くの盲点だったのですが、開発の前段階で準備作業のための費用とも言うべき「要件定義費用」が発生します。
もちろんソフトハウスによっては、最初の開発費用に合算して見積もりを出すところもありますが、情報販売WEBシステ
ムの開発を依頼したソフトハウスは別途費用を要求してきました。
大きなシステムですから、準備段階に人的コストが必要なのは分かりますし、支払うことについては何の問題もありませ
んが、最初の見積もりに要件定義費用が入っていないということに疑問があります。
実は、この要件定義費用だけで１５０万円以上を支払っています。
しかし、納品されたシステムを見る限り、果たしてこの費用は必要だったのかどうか疑問です。
しかも、そのソフトハウスはこの要件定義の作業が必ず発生するため、コストカット出来ません。
『プログラマーの退社』
晴天の霹靂とでも言うべきでしょうか。
メインプログラマが外注先のソフトハウスを退社してしまいました。
IT業界の動きの激しさを痛感する出来事です。
それと同時に、この段階で仕様書策定の必要性を強く感じました。
要件定義作業で大まかな「仕様書らしきモノ」があるとはいえ、やはりそれだけでは不足です。実際にソフトハウス内で
引き継ぎはなされていますが、その程度は推して知るべし。
『勉強不足』
システム開発依頼者である私の勉強不足。実は、これが一番の問題点でした。
システム開発の現状、プログラマーの質、開発言語の特徴、サーバなど関連する諸システムの知識、システムの規模に対
する費用と日程の算定。
まさかと思うほどのスキルを身につけなければ、WEBシステムの外注は出来ません。
そして、これでもかと思うほど事前に仕様を準備して臨まなければ自分の思い描くシステムは完成しません。
システム開発が暗礁に乗り上げた反面、自分でも驚くほどの経験値を得ることが出来たのは不幸中の幸いでしょうか。
私は、この段階でモバイルアクセス機能を諦めました。
ただ、システムを丸ごとお蔵入りにするのは避けたいと考えました。そこで、費用がかさむデザインやインターフェース
の修正はせず、モバイルアクセス機能をカットした分、見劣りする部分の修正を施し、最後のシステム修正を依頼しまし
た。
この時点で気が付けば暦は師走。
東京に初雪が観測…されたかどうかなどドーデモイイ年の暮れでした。
１つは開発中止。既に費やした費用は戻って来ないが、追加費用も発生しない。
もう１つは開発継続。開発済みのシステムを活かせることが可能であるが、追加費用が発生する。
この時点で私は、WEBシステムの外注に当たり１つの結論に至りました。
【プログラマーは指示されたことしかしない】
後から、別のシステム開発会社にお勤めの方に伺ったところ、最近の若いプログラマーに特にそういう傾向があるとのこ
とです。
また、私はこのころ、システム開発の基本、プロセス、仕様書策定、開発言語についての書籍を読みあさり、今回のシス
テム開発案件の問題点を探っていました。
『開発言語』
まず、開発言語として選択したJAVA言語ですが、外部からの改ざんに強いなど堅牢性とセキュリティに優れている反面、
後から修正を加えるということが苦手です。
ある程度システムが組み上がり、機能不足や不都合な部分を発見しても、簡単に修正することが出来ません。
機能を後から追加するには、初めから機能を追加することを想定して開発しなければならない、という部分がJAVA言語は
特に厳密に要求されるようです。
また、JAVA言語は、他の言語に比べて開発費用が高く設定されています。別のPHPやPerlであれば、おそらく3/4程度の費
用に抑えられたはずです。これは、別の開発案件でJAVA言語で組んだ場合とPHP言語で組んだ場合の費用比較をしたとき
に分かりました。
さらに、JAVA言語は、サーバに要求する能力も高くなります。
一般的なレンタルサーバレベルでは動きません。
ハイスペックな専用サーバが必要になります。当然、ハイスペックなサーバは維持コストも高くなりますから、トータル
コストが一気に跳ね上がります。
『プロトタイプの問題点』
プロトタイプを用意することで、仕様書では分からないヴィジュアル（見た目）のチェックを事前に行えるというメリッ
トがあります。
しかし、「あくまでプロトタイプ」なのか「これが完成イメージ」なのか、時に判断に迷います。
「これで本番システムの開発に移行して良いですか？」と聞かれたとき、明らかに機能不足やイメージとかけ離れていれ
ば指摘しますが、細かい部分は「プロトタイプだから仕方ないのかな？」と思ってしまうのです。
それはまるで、まるで完成品のような下書きを見せられたときの気持ちに似ています。
しかし結局、プロトタイプのユーザーインターフェイスがそのまま完成品として納品されたとき、「やはり指摘すべきだ
った」と後悔することになります。
このことから分かったのは、プロトタイプは「機能が動かない」だけで、デザイン面やインターフェース周りはそのまま
完成版に引き継がれるということです。
『要件定義』
これは全くの盲点だったのですが、開発の前段階で準備作業のための費用とも言うべき「要件定義費用」が発生します。
もちろんソフトハウスによっては、最初の開発費用に合算して見積もりを出すところもありますが、情報販売WEBシステ
ムの開発を依頼したソフトハウスは別途費用を要求してきました。
大きなシステムですから、準備段階に人的コストが必要なのは分かりますし、支払うことについては何の問題もありませ
んが、最初の見積もりに要件定義費用が入っていないということに疑問があります。
実は、この要件定義費用だけで１５０万円以上を支払っています。
しかし、納品されたシステムを見る限り、果たしてこの費用は必要だったのかどうか疑問です。
しかも、そのソフトハウスはこの要件定義の作業が必ず発生するため、コストカット出来ません。
『プログラマーの退社』
晴天の霹靂とでも言うべきでしょうか。
メインプログラマが外注先のソフトハウスを退社してしまいました。
IT業界の動きの激しさを痛感する出来事です。
それと同時に、この段階で仕様書策定の必要性を強く感じました。
要件定義作業で大まかな「仕様書らしきモノ」があるとはいえ、やはりそれだけでは不足です。実際にソフトハウス内で
引き継ぎはなされていますが、その程度は推して知るべし。
『勉強不足』
システム開発依頼者である私の勉強不足。実は、これが一番の問題点でした。
システム開発の現状、プログラマーの質、開発言語の特徴、サーバなど関連する諸システムの知識、システムの規模に対
する費用と日程の算定。
まさかと思うほどのスキルを身につけなければ、WEBシステムの外注は出来ません。
そして、これでもかと思うほど事前に仕様を準備して臨まなければ自分の思い描くシステムは完成しません。
システム開発が暗礁に乗り上げた反面、自分でも驚くほどの経験値を得ることが出来たのは不幸中の幸いでしょうか。
私は、この段階でモバイルアクセス機能を諦めました。
ただ、システムを丸ごとお蔵入りにするのは避けたいと考えました。そこで、費用がかさむデザインやインターフェース
の修正はせず、モバイルアクセス機能をカットした分、見劣りする部分の修正を施し、最後のシステム修正を依頼しまし
た。
この時点で気が付けば暦は師走。
東京に初雪が観測…されたかどうかなどドーデモイイ年の暮れでした。