受託開発業務に関する５つのルール5 rules on solution buisiness

エウレカコンピューターでは、システムの受託開発業務を７年間行ってきました。
その殆どがウェブ上でのシステムだったのですが、この間で私たちが受託開発業務について経験し、私たちのルールとなっていることを、みなさんにお伝えします。









（ルール１）システムは限りなく安くなる


システムの殆どは、クラウドを利用するか、無料のアプリケーションをうまく組み合わせて運用することによって、限りなく安くなります。

重要なことは、システム利用者にとって至れり尽くせりのシステムを、高額の予算をかけて作成することではなく、８０％の要求でも構わないので「まずは動くものを作る」ということです。

そして、そういったスピード感でシステムを発注するお客様は、システムの開発運用だけでなく、ビジネス全般もうまくいっているものなのです。

（ルール２）ベンダーとの信頼関係が最も大切

こういうお話が結構あります。

「ベンダーを切り替えようと考えているんだけど、エウレカさんで出来ないかなあ」

大変ありがたいお話しです。しかし、どうしベンダーを切り替えるんですか？と尋ねると必ず出てくるのが、お金の話だったりします。もちろん後述しますが、大変な暴利を貪っているベンダーさんも中にはいますが、「うーん、これはかかってしまう費用なんじゃないですか？」という場合も多々あります。

そういったケースでは、ユーザーの要求のためにシステム運用にコストがのってしまっている場合は多く見受けられます。

そういった場合、ベンダーを切り替えるよりも、コストをどのように下げれるかを既存のベンダをよく話しあうことをおすすめします。

（ルール３）予算の半分を初期開発費用に、残り半分を追加開発費用にあてる

システムは初期段階での要求で、実際のシステム利用者の要求をすべてすくいとり、完璧なものを開発することは不可能に近いものです。

にも関わらず、ほとんどの発注者様は、「初期開発」＋「メンテナンス（初期開発の１０％前後）」という予算感覚の方が多いように見受けられます。
確かにメンテナンスは必要なのですが、メンテナンスの予算で「追加開発」を行うのは困難です。
なので、ベンダー側も予め初期開発コストに追加開発分を入れておく、なんてこともままあります。

（ルール４）プログラマによって生産性が変わるという神話は真実だ

仕方のないことなのですが、人月、人工での予算管理、費用管理、プロジェクト管理、品質管理は、大規模な案件では仕方なく採用するわけですが、だいたい１０００万円以下の案件においては、見積書をつくる上で必要であって、数値としての正しさはほとんどありません。

プログラマの優秀さによって、生産性は１０倍ほど違う場合もあります。

何が言いたいかというと、小規模な案件においては、優秀なプログラマがプロジェクトに参加しているかどうか、ということが成果物の品質に大きく反映してしまうということです。

信頼のおけるベンダの信頼のおけるプログラマに仕事を頼むが、一番、ということになります。

（ルール５）ソリューションビジネスは儲からない

土木工事現場で働く作業員。彼らの多くを正社員として雇用している会社がどこにあるでしょうか？
日雇い労働という言葉が指すように、人工単位（人日、人月）でのソリューションビジネスにおいては、労働者を雇用することはビジネスモデル上、非常に困難です。

人工単位なので、仕事がある時は一人分の売上しかありませんし、仕事が無いときももちろんあります。

つまり、仕事がない時もあるということは、仕事がある時に仕事がない分ももらっておかないとビジネスとして成立しないということです。
また、もらえなかったら、ひとりのプログラマに多くの仕事をこなしてもらわないといけません。

ひとりのプログラマが５人月分の仕事を抱える、なんてことはよくあることです。
そんなことなので、プログラマはメンタルヘルスの問題を多く抱えてしまいます。