オフショア開発ラボ型が失敗する理由３つ
はい、こんにちは、オフラボの花井です。
今回はオフショア開発ラボ型が失敗する理由３つについて説明をしていきます。
オフショア開発アカデミーのご案内
オフショア開発について体系的に学べる情報サイト【オフショア開発アカデミー】では、こちらの内容やその他の情報について学ぶ事ができます。ご興味がある方はこちら
オフショア開発ラボ型とは
オフショア開発ラボ型は期間を決めて、開発チームを作って、その開発期間内であれば、自由に開発を行うことができるオフショア開発の開発方法の一つです。
オフショア開発ラボ型は柔軟に開発する事ができるメリットがあります。そのため、システム変化に柔軟い対応する事が可能です。
そのため近年では多くの企業がオフショア開発ラボ型を利用しています。
しかし、オフショア開発ラボ型は柔軟性が高い分、開発の生産性に大きく幅があります。
今回はオフショア開発ラボ型で失敗した事例について、プロジェクトの特徴や理由について説明をしていきます。
オフショア開発ラボ型が失敗する理由３選
ブリッジエンジニアのスキルと経験不足
オフショア開発ラボ型は依頼者側の担当者とブリッジエンジニアが情報を共有し、その他の開発チームへと情報を共有します。
ブリッジエンジニアとは
ブリッジエンジニアとは日本側の企業とベトナム側の開発チームを繋ぐ間のポジションのことを言います。
日本人のお客様の希望の要件を聞いて、システムが開発できるように開発者に伝えることやシステム開発に関する情報をお客様に伝えると言うと想像しやすいかもしれません。
そのため、様々な情報が集中するため、オフショア開発では重要なポジションになります。
ブリッジエンジニアの業務
ブリッジエンジニアは様々な業務があります。ブリッジエンジニアと一言と言っても色々なタイプがありますので、なかなか「ブリッジエンジニアの業務はこれです」と言いづらいです。
日本のお客様の希望やサービスやシステムの内容をやりとりします。
そのため多くの情報を受け取り、整理し、開発ができる状態にすることが主な業務になります。
具体的には開発要件・開発ドキュメントの作成、スケジュール作成、開発者のアサインなどを行います。
開発要件資料の作成
開発要件とは、どんな機能を作りたいのか、どんなシステムを作りたいかを確認し、正確に開発できるように、機能の詳細やデザインの詳細を作成していきます。
当然、依頼するお客様はシステムを開発するプロではありません。そのため開発したいシステムの内容が機能が不十分だったり情報が抜けている場合があります。
そのため、開発要件を作るためには、お客様から内容を聞くだけでなく、修正しながら開発要件を作っていきます。
この場面でブリッジエンジニアのスキルが足りず、システムの機能が不十分になると、システムが動かなくなることもありますので、かなり重要な仕事です。
そして、システム開発とは家を建てていくようなものです。
お客様の要望を聞いて、サービスを理解し、将来どのようなユーザーがシステムを使うか、どのような機能が追加される可能性があるか、反対にサービスの性質上システムにしないほうが良い機能はないか（人的な対応が得意な部分）、機能がオーバースペックにならないか
現在のお客様の希望を聞いて、サービスの本質を理解し、何年も先のシステムの状況やユーザーを想像しながら開発要件を作っていきます。
システム開発の難しく、面白い部分でもありますが、お客様のサービスを理解しないと良いシステム開発は提供できません。
前述したようにシステム開発は家を建てていくようなものです。
後から「こんな機能は想定していなかった」、「こんな使い方は想定していなかった」などで、追加開発ができない、または大幅な費用が必要になることを避けなければなりません。
開発ドキュメントの作成
開発要件から開発ドキュメントと言われる開発の詳細要件を作ります。
例えば動作の定義やページ構成、データベースやテスト、サーバーの構成や性能を記載し詳細を作っていきます。
この開発ドキュメントを使って、開発者が開発ドキュメントの情報通りに開発していきます。
そのため、かなり正確な開発ドキュメントを作る必要があります。
開発ドキュメントが正確であれば、要件を満たしたシステムを開発する事が出来る可能性は高くなります。
しかし、もし開発ドキュメントが不十分だったりすると、開発をやり直すことも発生する可能性があります。
重要な業務の一つです。
開発スケジュールの作成
完成した開発ドキュメントに合わせてスケジュールを作っていきます。
開発期間や開発する順番など、実際に開発する手順通りにスケジュールを作成します。
開発者チームの構成
開発スケジュールが完成後、スキルや経験に合わせて開発者を任命していきます。
いわゆる上流過程と言われる部分をこの部分をブリッジエンジニアが担います。そのためブリッジエンジニアの質によって大きくシステムの品質が変わります。
このようにブリッジエンジニアの業務は多岐にわたります。
そのため、ブリッジエンジニアのスキルや経験が不足している場合、様々な問題が発生します。
依頼者側の担当者の協力
依頼者側の担当者の方がどのようなシステムを開発したいか明確に整理して情報共有する必要があります。
もちろん、依頼者側の担当者はシステム開発のプロではありません。そのため、オフショア開発会社のブリッジエンジニアと共同で情報を整理して、開発したいシステムの情報を作ります。
しかし、担当者の協力なくシステム開発を行うことはできません。
依頼側の担当者もシステム開発の情報共有に多くの時間が必要になります。
オフショア開発会社は開発のプロですが、開発するシルテムが提供するサービスのプロではありません。
担当者の協力は良い開発に必要不可欠です。
開発サイクルの仕組み
三つ目は開発サイクルの仕組みについてです。
オフショア開発ラボ型の期間では、短く開発期間を区切って、開発を進めていきます。
この短い開発期間をスプリントと言います。
オフショア開発ラボ型の期間内では、このスプリントを複数回を行います。
開発期間のサイクルを効率よく回すには、準備・開発・テストを管理する仕組みが必要です。
この仕組みがうまく機能しない場合、オフショア開発ラボ型の効率は悪くなってしまいます。
スプリントを管理するツールなどを使用してオフショア開発ラボ型を円滑に進める必要があります。
タスクを管理して、スプリントの準備や開発タスクなどを管理します。
また、テストなどを管理することも効果的です。
このようにツールなどを使用して、オフショア開発ラボ型を効率的に進めることで開発の生産性を高める事ができます。
まとめ
今回はフショア開発ラボ型が失敗する三つの理由について説明をしていきました。
オフショア開発ラボ型のサポートはオフラボ・アカデミーサポートで行なっております。
興味がある方は、お問い合わせください。