【開発ディレクター向け】オフショア開発で要件定義を成功させるコツ

2022-05-24 2023-06-14

システム開発

オフショア開発チーム

要件定義とは、これから開発するシステムを理想に近づけるために最も重要な工程の一つです。

国内の開発会社に依頼する場合も、何度もコミュニケーションをとりながら進めるこの要件定義。
クライアントとオフショア開発会社をつなぐディレクターには、不安を感じられている方も多いのではないでしょうか。

よく聞くオフショア開発での要件定義に対する不安は、以下のようなものがあります。

品質が悪く発注内容や設計とは違うものができてしまう
結果として費用がかさんでしまった
コミュニケーションの問題

上記のような疑問や不安にお応えしていきます。

今回の記事を読めばこれがわかる！

☑️　要件定義の失敗例
☑️　要件定義が失敗する理由
☑️　要件定義で失敗しないためのポイントと対策

この記事は、Enlytでディレクターをしている石田が執筆しています。
要件定義は開発の要と言っても過言ではないと思っています。
こちらの記事が開発に携わる方のお役にたてば幸いです。

要件定義でよくある失敗事例

【失敗事例1】要件定義の目的と実現機能の乖離

要件定義ではまず「何を実現したいか」を決め、そのために必要な機能を考えていくというフローを踏みます。
ここでありがちな失敗としては、「何を実現したいか」という目的と機能が乖離してしまうことです。

例えば「ユーザー同士のコミュニケーション創出をしたい」という目的があったとします。
そのために記事へのコメント機能を作ることが決まり、それを構成する細かな機能を要件定義では固めていきました。
コメントの執筆者が判別できるようにするためユーザーネームとプロフィール画像を入れさせたり、リプライがくると通知が来るようにしたりと、単に「コメント機能」といっても必要な要素は複数あります。

しかしいざリリースをしてみるとコメント機能はほとんど使われませんでした。なぜならユーザーはカジュアルな記事の閲覧を好み、アプリ内で自分を表現することに興味を持たなかったためです。
何かコメントをしたいときは、自分のSNS内で記事をシェアし、コメントを添えるようでした。

このように、実現したいことと実現方法が乖離していると、せっかく要件定義・開発を行っても無駄になってしまうことがあります。

【失敗事例2】コストの過小見積もり

要件定義では、ある大きな機能を実現するために、細かな機能をリストアップしていきます。
前述のコメント機能で言うと、大きな機能が「コメント機能」、それを成立させる細かな機能として「ユーザープロフィール登録」「プッシュ通知」などが存在します。
ここで必要な機能が漏れてしまうと、開発工程での大きな手戻りの原因となります。

単純に「プッシュ通知機能が必要だったのに書いていなかった」と言うこともありますが、さらに気をつけなければならないのは「その機能を開発する見通しは立っているのか」である場合もあります。
なんの技術を使うのか、iOS/Androidの開発で差異は発生するのか…など技術的な見通しが立っていないと、要件定義後に大きく工数が膨らんだり、新たな技術導入に伴う予期しないコストが発生したりとトラブルが起こることがあります。

【失敗事例3】要求仕様の追加・変更でスケジュール遅延

要件定義が要因となってスケジュールが遅延することもよくあります。
過小見積もりが要因の仕様を追加・変更も、遅延を引き起こす原因となります。

要件定義が曖昧な状態で開発を始めると、ある機能を実現させるために必要な実装が想定よりも多く必要だと途中で気づくことになります。
すぐに実装できるものであれば巻き返せますが、物によってはリサーチも含め何週間もその機能にかかりきりにならなければいけないという事態も発生しかねません。

開発を進める途中で技術を変更したり、追加で実装が必要になることは、知見がない分野の開発ではなかなか全て回避することは困難です。
しかしある程度要件定義段階で見通しをつけておくことで、減らすことはできるのではないでしょうか。

要件定義が失敗する理由

クライアントとの認識齟齬

要件定義を制作し始める前に最も押さえておきたいポイントの一つが、要件定義を書く人間⇆クライアントの間での認識すり合わせです。

クライアントからはこの機能開発の意図やゴールを必ず聞き、伝えられた機能を何も考えず実装する…と言うことないようにしましょう。
クライアントはユーザーの動向やビジネス上の知見は高いが、開発やシステム運用に関しては知識が浅い場合があります。
その目的を達成するために、どんな機能が必要なのか？　今想定している機能は本当に目的に沿った物なのか？　などを考え、ディスカッションをできると良いでしょう。

また、もし要件定義を書く方がエンジニアでない場合は、技術の知見がある方の意見を取り入れることも必須です。
クライアントとのディスカッションに同行してもらったり、事前に相談してクライアントへ出す提案を一緒にまとめたりしましょう。
せっかくクライアントとすり合わせてもそれが的外れだった場合、大きな手戻りの元になってしまいます。

リリーススケジュールのすり合わせができていない

開発では、スケジュールのすり合わせは単に「何月何日にリリースしましょう」など日付を確認するだけでは終わりません。
単にクライアント・開発チームからOKが出たとしても、ロジックが通っていないと後から崩壊してしまいます。

どの作業にどのくらい工数がかかるのかをまず見積もり、理由を持ってスケジュールを作成します。
この時点で、リリース予定日がクライアントが要求するスケジュールよりも後になってしまう場合もあります。
開発に2年かかるサービスを3ヶ月でリリースすることは不可能です。
各スケジュールの理由を説明し、合意が取れなかった場合は、合意が取れる形を模索する必要があります。
例えば優先度の低い機能の実装をリリース後に回したり、リソースを増員したりといった方法が一般的には考えられます。

また、開発チームとのすり合わせも重要です。
クライアントと合意をする前に、エンジニアとそのスケジュールが実現可能なのか裏取りをします。
ここでのコミュニケーション不足が、オフショア開発における失敗の要因になる場合は多く見られます。

プロジェクトメンバーのスキルの問題

システム開発の業界では、常に知見のない分野の開発・実装にチャレンジをし続けなくてはなりません。
ビジネスの潮流や新しい技術の台頭などが業界を目まぐるしく変化させており、常に進化し続ける必要があるのです。

裏を返すと、どんなに経験豊富なエンジニアを抱えていたとしても、スキルや知見が案件に追いついていない可能性が常にあると言うことです。
知見が低い場合、要件定義時の見積もりで意見をもらったとしてもそれがずれている可能性があります。
要件定義後、開発に入った際に想定よりも時間がかかってしまう…と言う事態が発生することも視野に入れる必要があるでしょう。

要件定義で失敗しないためのポイントと対策

方向性や打合せ期間をクライアントとあらかじめ定めておく

前述のように、クライアントとの認識齟齬が要件定義の手戻りに繋がることが多々あります。
ではそんな認識齟齬はどのように防げばよいのでしょうか。
自分の認識全てをいちいちクライアントに確認するとキリがなくなってしまいます。
重要なのは手戻りの原因となりそうなポイントを押さえて、議事録を残していつでもお互いに見直せる環境を用意しながら合意をとることです。

特に押さえたいポイントとしては、機能の方向性やリリーススケジュールが一般的には挙げられるでしょう。
クライアントが想定する目的・ゴールに想定している機能が合致しているかと言う大前提も、リリース後の失敗を防ぐために重要です。
またスケジュールに関しても、単に日付を伝えるのではなく、どのくらい工数がかかるのかなどロジックを伝えて合意を取らないと、曖昧な認識でクライアントはOKを出すことになってしまいます。

また、リリースまで全く確認をしない進め方はまずあり得ないと思います。
いつ、何を確認してもらうかというスケジュールも合意を取りましょう。
この日付は開発のマイルストーンにもなります。
定期的に確認をしていくことで、手戻り防止やスケジュール遅延の早めの申告が可能になるでしょう。

余裕を持たせ、適切な作業見積もりを出す

開発の作業見積もりには必ずバッファ（=余裕）を持たせてスケジュールに反映すべきです。
見積もりを一緒につくるエンジニアは、今回開発する機能にかかる工数を必ずしも正確に出せる訳ではありません。
新しい技術についての知見がまだ足りていなかったり、作業者にトラブルが起きたり、スケジュールが遅延する理由は様々なところに転がっています。
そのため、あまりにも実装が簡単な機能を除いて、常に見積もりには少し余裕を持たせましょう。

現地開発チームとのコミュニケーションを増やして相互理解を深める

特にオフショア開発では、現地の開発チームとのコミュニケーション不足が様々なトラブルの要因になり得ます。
クライアントの意図の共有が不十分であるなど、日本側担当者が要因となることももちろんあります。
開発チームとの確認作業が、言語の壁などでしっかりと行えないこともあるでしょう。

確認の回数を増やしたり、チャットを使って常にコミュニケーションを取れる環境を作ったり、なるべく開発チームと接する機会を増やすことが重要です。
言語・文化の壁があると、時間をとって準備をしてからコミュニケーションに臨みたいと思い、接する機会を減らしてしまう傾向があるかと思います。
しかしコミュニケーションが少なくなるとトラブルに気付きにくくなります。
可能であればクライアントも含め、定期的に相互理解を深められるようプロダクトや開発進捗を確認できる場を頻繁に設けましょう。