オフショア開発を検討する方にはウォーターフォール開発とアジャイル開発という概念を聞いたことがありますね。更に、ウォーター フォール開発より新しいアジャイル開発を使用したらほうがいいと言われることは少なくありません。もしアジャイル開発はより優れていたら、ウォーターフォールが歴史から消えるでしょう。実際にはそんなことはありません。
では、アジャイル開発とウォーターフォール開発はどういうところで違いか、どの企業やオフショアプロジェクトに適するかを、我々が解説します。
1.ソフトウェア開発プロセスに関する方法論
1.1.ウォーターフォール方法論
1.1.1.ウォーターフォール型とは？
ウォーターフォール型開発は、ソフトウェア開発プロセスに関する、最も簡単な最初の方法の一つです。フェーズの順序に直接関係するので、「ウォーターフォール」と呼ばれています。ウォーターフォール型開発の各ステップは、滝のカスケード層のように次のステップに流れます。前のフェーズが完了するまでフェーズは開始されます。フェーズを戻す唯一の方法は、フェーズ 1 からやり直すことです。言い換えれば、ウォーターフォール型は、いくつかの個別のフェーズからなる連続的なマネジメントプロセスです。
ウォーターフォール型開発の目標は、完成品を一度に提供することです。 この方法は、主に大企業や政府のシステムに適しています。しかし、ウォーターフォール型開発は処理されるべき範囲が大きいため、処理が遅く、管理が難しく、変更への対応もあまり良くないと思われます。
1.1.2.ウォーターフォール型開発のフェーズ
ウォーターフォール型開発は、通常、厳密な順序に従って5〜 7 つのフェーズで構成されます。 フェーズの具体的な名前はさまざまですが、最初は発明者であるウィンストン W. ロイスによって次のように定義されました。
- 要件: すべての顧客要件はプロジェクトの開始時に収集され、それ以上の連絡なしに他のすべてのフェーズを計画できます。 プロジェクトの要件は、すべてのチームメンバーにとって明確である必要があります。
- 設計: 設計フェーズは通常、論理設計と物理設計の 2 つのサブフェーズに分割されます。 論理設計とは可能な解決策をレイアウトすることであり、物理設計とはそれらの理論的なアイデアやスキーマを具体的な仕様に変えることです。 このフェーズではコーディングは必要ありませんが、チームはプログラミング言語やハードウェア要件などの仕様を確立します。
- 実装: 実装フェーズでは、コーディングが行われます。 プログラマーは、前のフェーズから要件と仕様に関する情報を収集し、実際のコードを作成します。 彼らは通常、このフェーズの終わりまたは次のフェーズの開始時に統合される小さなコード断片を実装します。
- 検証: このフェーズでは、顧客がプロダクトをレビューして、要件を満たすかどうかを確認します。 テスト担当者は、テストプロセスで発生する問題を系統的に見つけて報告します。 重大な問題が発生した場合、プロジェクトは再評価のためにフェーズ 1 に戻る必要がある場合があります。 プロダクトがこのフェーズを通過すると、完成品が顧客にリリースされます。
- メンテナンス: 顧客は、メンテナンスのフェーズ中に定期的に完成品を使用します。使用中に発生するバグ、不適切な機能、およびその他のエラーを発見します。 問題が発生した場合、開発のチームはパッチを作成する必要があり、更新プログラムはそれらに対処する必要があります。 大きな問題では、プロセス全体をフェーズ 1 からやり直す必要がある場合があります。
1.1.3.ウォーターフォールのメリット・デメリット
メリット：
- 計画または予算を容易に作成することは可能です。
- 各プロセスの責任者は高い専門性を必要とするため、プロセス以外の技術を必要とせず、プロジェクトの安定性と完全性を確保できます。
デメリット：
- プロジェクト終了後の早い段階で問題が発見された場合、再開発に多くの時間とコストがかかります。
1.2.アジャイル方法論
アジャイル型開発は、何度も繰り返される短い操作サイクルなど、反復開発のコンセプトを中心としたソフトウェア開発の方法論です。
アジャイル型開発は、2001年に開発者のコミュニティによって提唱されます。理由は彼らが伝統なプロセスである「ウォーターフォール」にうんざりして、新たなマニフェスト（アジャイルマニフェスト）を設定することがを決意したからです。
アジャイルと言えば、スクラムやかんばんモデルなどを耳にすることがあります。アジャイルが考え方（または方法論とも言える）であるため、ソフトウェア開発におけるステップが具体的にどうすればアジャイルと見なされるかに関して定義はありませんが、実際にアジャイルの目的などを表す4つの価値と12の原則（つまりアジャイルマニフェスト）しかありません。
1.2.1.アジャイルの 4つの価値
1．プロセスとツールより個人とインタラクション：顧客のニーズに対応し、開発プロセスを推進するのは人であるため、プロセスやツールよりも人を高く評価することは容易に理解できます。
2．包括的なドキュメントよりソフトウェアの処理：昔から、製品の開発と最終的な納品に向けた文書化には、膨大な時間が費やされていました。アジャイルはドキュメンテーションをなくすものではありませんが、ソフトウェア開発に必要なドキュメントを一元にして、簡素化します。
3．契約交渉よりも顧客のコラボレーション：アジャイルマニフェストは、開発プロセス全体を通じて関与し、協力する顧客について説明しています。 これにより、顧客のニーズを満たすことがはるかに容易になります。
4．プランに従うことより変更への対応：アジャイルの見解は、変更は常にプロジェクトを改善したり、付加価値を提供したりするというものです。
1.2.3.アジャイルの12つの原則
1．早く継続的なソフトウェア提供を通じて顧客満足度を向上
2．開発プロセスを通じて変更される要求へ対応
3．機能するソフトウェアを頻繁に提供
4．ビジネス側の人と開発者がプロジェクトを通してコレボレーション
5．関係者に対するサポートと信頼、モチベーションの向上
6．フェイス・トゥ・フェイスでの交流を実現
7．機能するソフトウェアが進歩の最も重要な尺度
8．一貫した開発ペースをアジャイルプロセスで支援
9．仕様や設計へのこだわりでアジリティを向上
10.シンプルさ
11.自己組織化されたチームが優れたアーキテクチャ、要件、設計を促進
12.定期的な振り返りで効率を向上
1.2.4.アジャイルのメリット・デメリット
メリット：
- アジャイル開発モデルは、新製品や新機能をより迅速にユーザーに提供できます。
- ソフトウェア・システムを開発しながら顧客のフィードバックを受け取ることは両方に利益をもたらします。
デメリット：
- 柔軟性ゆえに、定期的に見直さないと最初の目的から逸脱しやすいです。
1.2.5.アジャイルにおける代表的なモデル
1.2.5.1.スクラムモデル
スクラムは、アジャイル方法論を支える多くのフレームワークの中で最も使用されていることは間違いません。 スクラムの特徴は、スプリントと呼ばれる開発のサイクルまたは段階と、製品目標に向けたソフトウェア製品の開発時間を最大化することです。 この製品の目標は、スプリントがスクラムチームの製品を一歩近づける、より大きな価値の目標です。
通常、ソフトウェアの開発管理に使用されますが、ビジネス関連のコンテキストでうまく使用できます。毎日は 15 分間の小さなミーティングから始まります。毎日のスクラムは、活動を同期させ、1 日の作業を計画するための最良の方法を見つける役割を果たし、スプリントの「健全性」と製品の進捗状況を確認できます。
メリット
- すべてのスプリントの締め切りに間に合わせるようにしているため、チームのモチベーションは良好です。
- 透明性により、チーム内のすべてのメンバー、さらには組織全体がプロジェクトを追跡できます。
- スクラムモデルでは常に品質に重点が置かれるため、ミスが少なくなります。
- このモデルのダイナミクスにより、開発者は優先順位を再編成でき、完了していないスプリントがより注目されるようになります。
- スクラムチーム全体が割り当てられたタスクの「なぜ、何を、どのように」を理解できるように、適切なスプリント計画が優先されます。
デメリット
- プロジェクトの細分化と開発のアジリティの追求により、チームはプロジェクト全体を見失い、特定の部分に集中してしまうことがあります。
- すべての開発者の役割が明確に定義されていない可能性があるため、チームメンバーの間で混乱が生じることがあります。
1.2.5.2.かんばんモデル
かんばんという言葉は日本語に由来し、その意味は「ジャスト イン タイム」の概念に関連しています。 実際には、かんばんモデルはボードまたはテーブル (かんばんボード) に編成され、列に分割され、ソフトウェア開発プロジェクト内のすべての流れを示します。 開発が進むにつれて、テーブルに含まれる情報が変化し、新しいタスクが開始されるたびに、新しい「カード」が作成されます。
このモデルは、人事、マーケティングなどの個々のビジネス部門にも役立ち、チームのすべてのタスクに必要な可視性をもたらします。
かんばんモデルでは、チームのメンバー全員が開発がどの段階にあるかを正確に把握し、プロジェクトの状況をいつでも確認できるように、コミュニケーションと透明性が必要です。 何よりもチームの能力に焦点を当てており、小さな変更を受けるプロセスに最適です。
メリット
- 「カード」という単純な概念を使用して、単一のプロジェクトの下にあるすべてのタスクを表示する機能 (たとえば、完了済み、進行中、またはテスト中など)。
- 実行中のタスクの数を制限できます。
- サイクルの期間に焦点を当てます – タスクがバックログから最終段階に移行するのにかかる時間。
- 継続的な提供を可能にします。
- おそらく、「IT の世界」の外で実装する最も単純なモデルの 1つです。
デメリット
- カンバン ボードに表示されている情報が古い場合は特に、チーム メンバーがその情報を誤解する可能性があります。
- かんばんには時間枠がないため、あらゆる段階で遅延などの時間に関する問題に直面する可能性があります。
2．オフショア開発におけるチャレンジトップ
2.1.言語の壁
他の国の企業と協力することは、言語が違うことを意味しています。オフショア開発を探している日本企業は、日本語能力が高い人材を有した企業を選択しないと、コミュニケーションが失敗するために、両方が相手の目的・行動を理解できなくてプロジェクトも失敗します。また、日本語がペラペラ話せる人材が技術に関しての知識を持たなければ、プロジェクトは成功を収めません。ITオフショア国の中で、日本企業と長く付き合ているのは中国、ベトナム、インドです。しかし、日本企業は、オフショア開発企業が日本語がうまくできる人材（例えばブリッジSE）を持っているために、相談する時、言葉遣いがちょっと荒くしてはいけません。外国人がどれほど日本語を理解しても、母語の思考と母国の文化に影響されるために、コミュニケーションをちゃんと行えなければ、誤解を発生することもあります。
2.2.プロジェクトマネジメントが難しい
オンサイトの場合を除き、他のオフショア開発モデルでは、プロジェクトは自社と長く離れた地域で実行されるために、プロジェクトマネジメントが難しくなる課題に直面しています。最初からオフショア開発の企業と相談する時、報告方法の時間・頻度をきちんと確認しなければ、期待通りに高品質なプロダクトを受け取りにくいです。
2.3..要件と違った最終的なプロダクト
検収する時に、最終的なプロダクトが要件と違ったことを見づけることはあまり少なくありません。理由は様々あるが、最大の理由として良いオフショア開発の企業を選択できないこと、次にマネジメントが下手なことです。しかし、時々、顧客が提供した最初の要件が曖昧すぎるために、顧客の要求を十分に理解できない場合もあります。
3．オフショア開発に向けるウォーターフォールを選択する注意
多くの専門家の評価によりますと、ウォーターフォールは次の場合に適します：
- 要件の変更頻度はあまり多くない。
- 開発されたソフトウェアやシステム、アプリケーションは複雑ではない。
- プロジェクトの期間は短い。
- 要件は明確である。
- 使用されたテクノロジーやツールは安定している。
プロダクトの要件やプロジェクトの規模を考慮した後、ウォーターフォール型のオフショア開発が適切だと思ったら、次の点に注意してください：
- 日本企業で長く付き合っている海外の企業を選ぶ：日本企業または文化は特殊があるために、日本企業と協力する経験がなかったら、コミュニケーションが取れないし、顧客のニーズを理解できないし、様々な問題が発生する可能性が高いです。そこで、オフショア開発を検討する企業は、日本で長く活躍している海外の企業を優先すればいいです。
- できる限りに、詳しい要件を提供してください：日本語で多く知られている特徴は曖昧さですよね。しかし、海外人と相談すると、日本風の話し方を行ったら、相手が誤解することもあります。特に、ITオフショア開発に関して、「それは良くないです」というより「どのところが良くない」を指摘したらいいです。つまり、外国人との会話で曖昧さを徹底的に回避してください。
- 報告を効率的かつ明確にする：依頼先のプロセスが報告を提供する頻度はどのくらいか、報告内容は明細にするかなどを最初から明らかにしてください。また、実装中に、報告書に不明点がある場合、早く問い合わせください。
4．オフショア開発に向けるアジャイルを選択する注意
4.1.作業範囲 (SoW) を決定する
作業範囲は、プロジェクトで実行される作業に関する情報を含むドキュメントです。 これは、書いてある締め切り日にタスクが完了されるべき最初の合意です。 手順は詳細を示すことを意図したものではありません。むしろ、ソ
SoWの内容:
- プロジェクトのマイルストーンと日付
- 各マイルストーンの成果物のリスト
- 報告スキーム。
各マイルストーンは、イテレーションと呼ばれる短い部分に分割されます。 これにより、反復ごとに特定のタスクを含む大まかな計画を準備することができ、それらのタスクに優先順位を付け、必要に応じて再配置することが容易になります。
4.2.プロダクトロードマップを作成する
プロダクトロードマップは、長期的および短期的な目標とそれらを達成する方法で構成されるプロジェクトの段階的なガイドとして機能する戦略的なドキュメントです。 これは、要件、技術スタック、または期限が変更された場合に、時間の経過とともに変換できるプロジェクトの全体的な視覚的表現です。
ロードマップを作成することで、プロジェクトのプロセスを明確に表すことができます。 この段階で、アジャイル開発チームは各イテレーションを複数のスプリントに分割できます (標準の長さは 1 週間です)。
4.3.コミュニケーションの効率化
アジャイル方法論では、チームが定期的な短い会議を実行します。 オフショア開発チームを管理する場合、これらの会議は非常に重要なので、チームが互いに作業を調整できるようにします。
以下に、スクラムモデルに従うオフショア開発で、最も一般的な 3 種類の会議を示します。
- 毎日のスタンドアップミーティング： 通常は午前中に開催され、15〜 20 分間続きます。 会議中、各チームメンバーは次の3 つの質問に答える必要があります。昨日は何をしたか、今日は何をするか、タスクを実行するための現在の障害は何ですか。
- 次のスプリントを準備するためのスプリント計画ミーティング： スプリントの目標とスプリントのバックログは、この会議の成果です。
- リリース計画が作成されるリリース計画会議：リリース計画は、反復計画の開発にさらに使用されます。
そればかりではなく、コミュニケーションの効率化を遂げるために、データの透明性（チームの間、そして開発チームと顧客）を確保するべきです。データを一元管理したり、相談中に一つの意味だけを含む、簡単な言葉を使ったり、コミュニケーションやプロジェクトマネジメントを支えるツールを活用したり、様々な方法を活用できます。
4.4.一般的なアジャイルの基準（12つの原則など）に固執する
アジャイルソフトウェア開発で使用されるよく知られた手法があります。例えば、共通のコーディング標準や、ソース管理サーバー、継続的統合、バグ追跡、設計パターンなど。オフショア開発チームでは、対面でのコミュニケーションが減少するため、これらの手法がより重要になります。
オンサイトチームとオフショア チームの両方がスムーズに作業できるようにするソース コード サービスを使用していることを確認してください。 リモート作業をうまく処理できないソース コード管理システムを活用する場合は、別のソース コード管理システムを探す時間がかかります。
アジャイル型のオフショア開発チームを管理する場合、アクティブなコラボレーション ツール (wiki、問題追跡ツール、プロトタイピング ツールなど) の必要性も高まります。
4.5.ドキュメント化と共有を徹底
コミュニケーションの中で、口頭だけではなく、形に残るように会話の内容をテキスト化したらほうがいいと思います。紛争や誤解などが発生したら、テキストをたどり着いて、正しい意図を把握することは可能です。また、相談する時、日本企業はできるだけで優しい日本語で話してください。少ない人に知られている言葉または丁寧すぎる表現を使うより、簡単な表現はコミュニケーションの効果を上げます。
4.6.定期的にデモを開催
デモは、チームが作業の結果を発表する会議です。 通常、これらの会議は各スプリントの後、つまり、特定の機能が使用可能になったときに開催されます。
これらのミーティング中に、チームはプロダクトオーナーから建設的なフィードバックを受け取り、それに応じて取り組みを調整できます。 また、プロダクト オーナーは、チームの作業ペースを考慮して、ワークロードをより効果的に調整できます。メリットが満載するために、できる限り、デモを定期的に開催してください。
5．VTIグループ
株式会社VTIは金融、建設、小売、運輸、インタネットサービスなど多岐多様な業種で、全規模企業向けにソフトウェア開発、自動化実装、デジタルトランスフォーメーション、ハイテクサービスをご提供します。
従来、VTIグループはAWSパートナー、マイクロソフトゴールデンパートナー、Magento、Odoo、ServiceNow、Salesforce公式パートナーに認定され、ISO 27001 セキュリティ標準、プライバシーマーク（Pマーク）、国際認証CMMIレベル3を取得したことに加えて、日本・韓国・ベトナム・シンガポールの100会社以上にパートナーとしてIT技術のサビースを提供しております。更に、この4国にわたる8子会社で働いている1200従業員以上は、企業様のDX革命の成功を目指して、社員一同全力を持って取り組んで参ります。
