小規模サービス開発におけるソフトウェア開発者のタイプとインパクトについて。

クラウドソーシングの登場もあり、小さな会社が開発リソースが不足している中でも
小規模のサービスを開発しやすくなってきました。
ついつい「安さ」で開発者を選んでしまうとひどいことになるのは、
開発者側からみると自明なことなのですが、経営視点からみると「安さ」は重要な指標です。
しかも開発者以外には開発者の実力は判断しにくいものです。

ここで開発者の実力を見ぬくことができる技術顧問の存在が重要となるわけです。

開発者のタイプを3つに分けて説明した上で、実際に開発を行った場合にどのような結果を生むのか、
についてまとめます。

前提

小規模 = 開発者1-3名程度の開発

開発者のタイプ

タイプ1

一つの機能を作ることができるが、一つのシステムを作りあげることができないタイプ。
プロジェクトの主力開発者としてこのタイプの開発者を選んでしまうと目標を達成できない可能性が大きいです。
しかし、昨今のクラウドソーシングなどに登録してある情報をみると、本当はこのタイプの仕事しかできないが、
あたかもなんでもできるかのようにプロフィールをまとめている開発者がいるので発注側が誤って選んでしまいやすいです。

システムのアーキテクチャが固まり、一部のテンプレート的に増やせる機能を作り上げる目的でスポット参戦させることで
活躍してもらう場面もあるかもしれないですが、
コミュニケーションコストや低スキルゆえに発生する問題の数々をバックアップしたり、
協業のコスト増を超えるメリットを生み出せるかどうか微妙な線です。

進捗を伸ばすために安い低スキル開発者を複数投入、というのは他の主力開発者の時間を奪い
むしろ進捗を妨げることすらありえます。

タイプ2

技術的には一つのシステムを作りあげることができるが、
要件をまとめあげることや長期的な保守性を加味した開発をすることができないタイプ。
また、頼まれた仕事以外のことを提案する頻度が低い傾向にあります。

そもそもシステムを必要とする会社、部門はシステム開発に習熟していないことがよくあります。
習熟していないからこそ開発者に依頼するわけで当たり前です。

そのため、小規模開発では開発者がお客様の要件を聞き取り、仕様としてまとめあげていったり
よりよい方法を提案するスキルが必須となります。
お客様からいただいた情報に過不足があった場合に、自ら情報をとりにいけるかどうか？
曖昧なまま進めて、曖昧なまま実装して、仕様バグを生み出すか？
この違いはかなり大きいです。

中-大規模プロジェクトではこの部分を特定の担当者がやってくれて、
実装だけをすればいい開発者が活躍できるケースもあります。
しかし小規模の場合は各担当者があるべき要件、あるべき仕様を導き出すことができないと厳しいものがあります。

タイプ3

技術的には一つのシステムを作りあげることができ、
長期的な保守性も加味して開発でき、
ビジネスとシステムをつなげて考えることができるタイプ。

システムが誰のどんな問題を解決するためのものかを考えることができる人ですね。

このタイプは要件に曖昧なところがあれば、自らお客様にヒアリングし、正解を引き出すことができます。
また、大抵の場合細かな指示を必要としません。

システムの目的や制約などを共有しておけば、その場その場で判断・報告をしてくれるため
発注側のコストも抑えられます。

• サービスや開発に関して改善すべき点があれば自発的に提案する
• スケジュールなど制約を加味したうえで現実的な選択をしてくれる

など非常にありがたい行動をとってくれますし、こうした開発者でチームが構成されていることは
開発の拡大フェーズで大きなアピールポイントになります。

現実にあてはめて比較してみる

タイプ3よる開発の例

例えば、タイプ3の開発者2名に初期開発 1,000万 で発注し、
保守コストが月 10万程度だったとします。（金額は適当です）
1年間のコストは1,120万です。

スケジュール通りに完成し、追加機能の実装も素早く行うことができます。
システム自体は非常に使いやすいものとなっています。
お客様からの評判もよく、サービス本来の価値を提供することで売上をあげることができます。

タイプ1、2タイプによる開発の例

タイプ1を1名、タイプ2を1名に初期開発 800万 で発注し、
保守コストが月 8万程度だったとします。
1年間の開発コストは896万です。

システムの完成まで元々のスケジュールの1.5倍かかった上に、
追加機能の開発が前者の10倍のコスト、時間がかかります。

開発のやりとりのために発注側が使うコストも前者と比べて何倍もかかります。

システム自体も前者のものと比べて使いにくいものに仕上がっています。
システムの目的を把握したうえでの改善提案、設計を行っていないためです。

品質が低くバグが収束しないため、サービスの信頼度が低く
バグの対応のためにビジネスに必要な新規機能の開発が滞ります。

お客様からの評判が悪く、サービス本来の価値を提供することができず
売上をあげることができません。

まとめ

タイプ1-3の開発者によるサービス開発を紹介しました。

これらの開発者を採用したり、外注する際に意外にもそのコスト差が1.5倍程度しかないことがあります。
実際にその仕事の成果をみると生み出した価値は1.5倍どころか10倍も20倍もあることはざらです。

しかし、この1.5倍をケチったがためにタイプ1,2の開発者を選んでしまうと
長期的に見て10倍、もしくはそれ以上のコストがかかってしまうことになります。
単価が高ければ信頼できるか？というとそうでもありません。
強気の価格設定をする低スキル開発者もいます。

そこで技術顧問が重要となるわけです。
実力のある技術顧問がいれば、開発者の選定を誤る可能性は低くなります。
世間のWebニュースなどで目にする技術顧問は著名な開発者が多いですが、
そのようなレベルではなく、タイプ1・2とタイプ3の違いを見ぬくことができるレベルがあるだけでも
今回説明したようなケースでは大きな効果があるでしょう。

そもそもどうやってそのような技術顧問と出会うのか？という問題はあるかもしれませんけどね。