オフショア開発の失敗を限りなく減らす！外注にあたってのチームの考え方！

弊社は今までオフショア開発を失敗しない方法という観点でいくつかの記事を書かせていただきました。

【完全保存版】オフショア開発を失敗させないための３つのコツ

オフショア開発における５つのデメリットと４つの対策

【実体験】オフショア開発を活用される際の注意点

これらの記事では書ききれておりませんでしたが、開発チームの構築も失敗を防ぐという観点では非常に重要です。

適切なチームを編成し、立ち上げていくには何か月もかかる場合があります。

しかし、悲しいことに長い時間をかけて立ち上げたチームがうまくワークせずにチームを理由にプロジェクトが失敗に終わってしてしまうことも散見されています。

その失敗の原因の一つとして、契約形態やチーム構成が開発対象のシステムとマッチしていないことがあげられます。

本記事では、契約形態とチームの考え方について整理しました。

失敗を防ぐための注意点の一つとして、ご参考いただけますと幸いです。

■オフショア開発での2つの契約形態

オフショア開発では、請負型開発とラボ型開発の2つの契約形態があります。

①請負型開発

請負型開発は発注した仕様、要件に基づいて開発された成果物を納期までに納品する契約形態です。

請負型開発では、受託者は事前にしっかりと定められた仕様、要件に基づいて納期、品質の担保責任を負って開発を行います。

そのため、発注者は開発プロセスに関わることはあまりありませんが、事前に定めた仕様、要件に基づいて開発が進むため、仕様や要件を決める段階で抜け漏れがないことを発注者側で確認しないと後々トラブルが起きる可能性が高いです。

実際、オフショア開発の失敗として扱われるよくあるケースとして、開発中に検討漏れしていた要件が発覚し、その仕様の開発が仕様変更にあたるのか仕様明確化にあたるのかでもめることが散見されます。

事前に要件、仕様を定めて、それに基づいて開発するという特性上、請負型開発では、前工程に戻らずに開発を進めるウォーターフォール型開発で進めていくことが多いです。

そのため、請負型開発は、既存システムのマイグレーションのような要件が明確に定まって各工程で必要な作業が明確なシステムの開発や計画の進捗管理が厳格になされる必要がある大規模なプロジェクトで活用されています。

②ラボ型開発

ラボ型開発とはオフショア開発企業内に発注者専属のITチームを編成し、3ヶ月から1年間の契約を結ぶサービスです。

ラボ型開発はあくまで人材を一定期間借りる契約のため、契約時に仕様、要件を確定する必要はなく、仕様変更に柔軟に対応できます。

そのため、開発途中でユーザーとフィードバックを行い確認をしながら進めることができるため、ユーザーの要望に最大限応えることが可能です。

また、契約期間中は他の企業のプロジェクトに参加しないように契約することもできるため、優秀な人材を長期間確保して発注者の企業に係るノウハウを蓄積して長期的な開発拠点としていくことも可能です。

請負型開発と違って、仕様、要件に基づいて計画をたてることを前提としないため、発注者が開発プロセスのなかで定期的にコミュニケーションをしながら進めていくことが一般的です。

ラボ型開発は、計画、設計、実装、テストというプロセスで機能や仕様毎に実装し、それを繰り返アジャイル型開発で実施することが多いです。

また、計画の単位が工程ではなく、機能や仕様毎に開発を行うため、修正にかかる工数が少なくすみます。

一方、仕様、要件ごとに開発スケジュールを設定するため、全体のスケジュールや進捗具合が把握しにくくコントロールが難しいというデメリットがあります。

時間契約であること、明確な仕様や要件を事前に定める必要がないこと、修正が発生しても工数が少なくて済むことから、ユーザーからのコメントをもとに機能を継続して修正、追加していくWebサービスやユーザーヒアリングを前提とした新規事業に向けたMVP開発等の開発が適しています。

ラボ型開発の分類

ラボ型開発は先日のブログ「TEMって何？アウトソーシング先進国のアメリカ発の新しい考え方！」で紹介したDDTとTEMの考え方と非常に相性がいいです。

①DDT：Dedicated Development Team

DDTとは、社内で不足するリソースを外部から調達することを目的として開発を委託するエンジニアチームです。

特定のプロジェクトに紐づけて短期的に委託するのではなく、社内で発生する別のプロジェクトにアサインする可能性も視野に入れて長期的な目線でチームを組成します。

社内の一部門として扱うことを前提としているため、社内の各事業部門に事業部長が行われるようにプロジェクトマネージャーを配置して、プロジェクトマネージャー経由でコミュニケーションを行うことが一般的です。

DDTは稼働後の機能追加や修正を念頭に置いたWebサービスの新規立ち上げや人員追加、改善や機能拡張が継続して起こる社内システムの開発に活用される場面が多いです。

②TEM：Team Extension Model

TEMとは特定のプロジェクトに不足する人員を調達する目的としたエンジニアチームです。

割り当てられたプロジェクトのみに全工数を注ぎます。

プロジェクトのチームに従事するため、一般的には各プロジェクトチームのリーダーのもとで他のチームメンバーと同様に直接のやり取りを行うことが一般的です。

TEMは急遽増員が必要になった場合の人員として活用されることが多いです。

向き不向きの整理

ここまで請負型開発とラボ型開発の違いについて説明したうえで、ラボ型開発の活用方法としてDDTとTEMを整理しながらお伝えしました。

下の図にてここまでのお話を整理いたします。

■まとめ

ここまででお伝えした通り開発するシステム、ビジネス上の要求に基づいて委託する際のチームの考え方が変わります。

適切な手法を選択することで、コスト削減をしつつ、要件にあったシステムを期間内で開発するといった守りの面だけでなく、長期的な事業の拡大に耐えるITチームを構築するという攻めの面も実現できます。

弊社も多くのオフショア開発企業と同様、ラボ型開発と請負型開発を提供しています。

600以上の開発案件で蓄積したノウハウから、お客様に最適なチーム編成をご提案することもできますので、もし開発手法に関するお悩みがあれば、お気軽に弊社までお問合せください。

・「お問合せ」ページ