Loading article…
.jpg/500px-World1074-(12-5L-37-5R).jpg)
フォローザサン（FTS）は、グローバル分散ソフトウェアエンジニアリング（GDSE）のサブフィールドであり、市場投入までの時間を短縮するために設計されたグローバルナレッジワークフローの一種です。このワークフローでは、ナレッジプロダクトは1つのタイムゾーンの生産拠点によって所有および進められ、その日の終わりに、数タイムゾーン西にある次の生産拠点に引き渡されて作業が続行されます。[1] [2]理想的には、これらのタイムゾーンでの作業日は重なり、1つの拠点の1日が終了すると、次の拠点が始まります。
FTS は、1 日あたりの総開発時間を大幅に増加させる可能性があります (単一のタイム ゾーンの観点から見ると)。2 つのサイトの場合は開発時間が最大 16 時間まで増加し、3 つのサイトの場合は最大 24 時間まで増加し、開発期間が最大 67% 短縮されます。
これは業界では一般的に実践されておらず、成功裏に適用された文書化された事例はほとんどありません。[3]これは、その要件が一般的ではないため、FTSを実際にうまく適用する方法に関する知識が不足しているためと考えられます。
歴史
フォローザサンの起源は、1990年代半ばにまで遡ります。IBMは、 FTS を活用するために特別に組織された最初のグローバル ソフトウェア チームを擁していました。[4]このチームは、世界中の 5 つのサイトに分散していました。残念ながら、このケースでは、ソフトウェア成果物を毎日引き渡すことは一般的ではなかったため、FTS は成功しませんでした。
IBM における FTS の他の 2 つの事例は、Treinen と Miller-Frost によって文書化されています。[3]最初のチームは、米国のサイトとオーストラリアのサイトに分散していました。このチームでは FTS は成功しました。2 番目のチームは、米国のサイトとインドのサイトに分散していました。このケースでは、コミュニケーション不足、タイム ゾーンの問題、文化の違いにより、FTS は失敗しました。
原則
FTS は次の 4 つの原則に基づいています。
- 主な目的は、開発期間/市場投入までの時間を短縮することです。
- 生産拠点は多くのタイムゾーンが離れています。
- プロジェクトを所有し、プロジェクトに取り組むサイトは常に 1 つだけです。
- 引き継ぎは毎日、各シフトの終了時に行われます。次の生産拠点は西に数タイムゾーン離れています。
よくある誤解
FTSを定義する上で重要なステップは、FTSを他のグローバル分散構成と区別し、FTSではないものを明確にすることです。次のような類似のグローバル分散構成はFTSではありません。[2]
- グローバルナレッジワークとは、地理的に分散した知識労働者が複数の場所から共同で作業することと定義されます。[5]これは引き継ぎがないためFTSではありません。
- 24 時間 365 日のサービス。この構成では、作業はその時点で対応可能な作業者に分配されます。これは可用性に重点が置かれ、作業者間の依存関係はほとんどありませんが、FTS は期間の短縮に重点が置かれ、毎日の引き継ぎを実行するために異なるサイト間の依存関係が必要になります。
- 24 時間製造。この構成は、シフトあたりの従業員数を増やすだけでは生産量を増やすことができない高価なリソースをシフトで完全に最適化することに重点を置いています。ただし、リソース コストを削減するというこの推進力は、FTS の推進力ではありません。
- 複数のシフトを併置。FTS とは対照的に、この構成では労働力が安価な 1 つの場所を選択し、複数の 8 時間シフトを同時に実行します。
困難
FTS の最大の強みは、開発を複数のタイム ゾーンに分散していることですが、同時に最大の弱点でもあります。分散ワークフローは、文化的および技術的な違い、および時間の違いにより、調整とコミュニケーションが困難になるため、実装がより複雑になります。
FTS の実装が難しい主な理由は、ハンドオフが重要な要素であり、それを正しく行うことが難しいためです。この困難さを引き起こす最大の要因は、コミュニケーション不足です。[3]
FTS をうまく適用した企業の事例はほとんど記録されていません。[3]いくつかの企業は FTS の実装に成功したと主張していますが、これらの企業は毎日の引き継ぎを実践していませんでした。[3] [6]しかし、分散同時モデル[2]を使用して成果物の毎日の引き継ぎを組み込んだ、FTS の成功したアプリケーションの限られた数がCameron によって発見されました。[7]
最近のFTSに関する研究は、FTSの数学的モデリングに移行している。[8] [9] [10] [11] [12]研究は速度の問題とハンドオフに関する問題に焦点を当てている。
方法
FTSはGDSEのサブフィールドであるため、[4] GDSEでうまく機能することがわかっている同じアジャイルソフトウェア開発方法論はFTSでもうまく機能します。 [2]特に、Carmelら(2009)は、アジャイルソフトウェア開発方法論がFTSの原則を支援すると主張しています。その理由は次のとおりです。[1]
- 毎日の引き継ぎをサポート: ソース コードの継続的統合と自動統合により、各サイトは業務時間中に独自のコード ベースで作業できると同時に、統合によって更新されたテスト可能なコードが維持され、次のサイトが使用できるようになります。
- コミュニケーションに対処する: アジャイル手法ではコミュニケーションを重視します。特に、1 つのサイト内で実行できる対面コミュニケーションを重視します。FTS はサイト間のコミュニケーションを減らすことを目的としているため、対面の側面はアジャイル開発手法の全体的な適用に大きな障害にはなりません。
- 協力と連携を引き出す: FTS ではより多くの連携と連携が必要となるため、この点に重点を置くことは特に有用です。
課題
Krollら（2013）は、1990年から2012年までに発表された論文を調査し、FTSに関する36のベストプラクティスと17の課題を発見しました。[13]課題は、調整、コミュニケーション、文化の3つのカテゴリに分類されました。FTSを成功裏に実装するには、これらの課題を克服する必要があります。
調整
- タイムゾーンの違いにより、リアルタイムのコラボレーションの機会が減少します。チーム メンバーは、遠隔地の同僚との連携を実現するために柔軟に対応する必要があります。連携が限られていることと応答の遅延は、調整に悪影響を及ぼします。
- 毎日の引き継ぎサイクルまたは進行中の作業の引き継ぎは FTS の要件です。これがなければ、市場投入までの時間を短縮することはできないからです。
- 地理的分散
- コスト見積もり
- チームワークの喪失
- サイト数
- 調整の崩壊
- 経営上の困難
- 技術プラットフォーム
コミュニケーション
- コミュニケーションの豊かさの喪失 / 対面コミュニケーション
- 社会文化的多様性の難しさ
- 同期通信
- 言語の違い
- 技術的な問題
- 宗教上の祝日や国民の祝日を管理します。
文化
- 文化の違い
- 異なる技術的背景
ベストプラクティス
日々の引き継ぎのための方法論を選択し適応させることは非常に重要です[1] [13]、例えばアジャイルソフトウェア開発やウォーターフォールモデルの使用などが挙げられます。
特定されたベストプラクティスは、アジャイル手法の使用と、FTS活動を開発するためのテクノロジーの使用です。アジャイルは、FTSにおける重要な課題である毎日の引き継ぎをサポートします。[1]管理ツールを使用して、スケジュールの見積もりと計画、スプリントの管理、進捗状況の追跡を行うことができます。さらに、会議ビデオ、電子メール、電話などのテクノロジーは実装が簡単で、企業がチーム間で同期および非同期の通信を実行できるようにし、アジャイル環境でうまく機能します。
月を追う
関連する概念としてフォロー・ザ・ムーンがあり、これは、夜間の安価な電力[14]や予備の処理能力を利用してデータセンターのコストを節約するなどの理由から、特に現地の夜間時間帯に作業を実行するようにスケジュールするものです。
その他の用語
- 24時間開発
- 24時間開発
参照
注釈と参考文献
- ^ abcd Carmel, E.、Dubinsky, Y.、Espinosa, A. (2009 年 1 月)。太陽に従うソフトウェア開発: 新しい視点、概念的基盤、および探索的フィールド スタディ。System Sciences、2009 年。HICSS'09。第 42 回ハワイ国際会議 (pp. 1-9)。IEEE。
- ^ abcd Carmel, E.、Espinosa, JA、Dubinsky, Y. (2010)。「Follow the Sun」グローバルソフトウェア開発ワークフロー。Journal of Management Information Systems、27(1)、17-38。
- ^ abcde Treinen, JJ、Miller-Frost, SL (2006)。太陽を追いかけて：グローバルソフトウェア開発のケーススタディ。IBM Systems Journal、45(4)、773-783。
- ^ ab Carmel, E. (1999). グローバルソフトウェアチーム: 国境やタイムゾーンを越えたコラボレーション。Prentice Hall PTR。
- ^ Espinosa, JA, Cummings, JN, Wilson, JM, & Pearce, BM (2003). 複数のグローバル企業におけるチーム境界の問題。Journal of Management Information Systems, 19(4), 157-190.
- ^ Yap, M. (2005 年 7 月)。Follow the sun: 分散エクストリーム プログラミング開発。Agile Conference、2005。議事録 (pp. 218-224)。IEEE。
- ^ Alexander Cameron (2003 年 8 月)。「Rational Users Conference 2003。Follow-the-Sun テクニックを使用した市場投入までの時間の短縮」。
- ^ Espinosa, JA, & Carmel, E. (2003 年 5 月)。グローバル ソフトウェア チームにおける時間的分離による調整コストのモデル化。グローバル ソフトウェア開発ワークショップ、国際ソフトウェア エンジニアリング会議 (ICSE) (pp. 64-68)。
- ^ Jalote, P., & Jain, G. (2006). 24時間ソフトウェア開発モデルにおけるタスクの割り当て。システムとソフトウェアジャーナル、79(7)、904-911。
- ^ Setamanit, SO, Wakeland, W., & Raffo, D. (2007). シミュレーションを使用したグローバルソフトウェア開発タスク割り当て戦略の評価。ソフトウェアプロセス:改善と実践、12(5), 491-503。
- ^ Sooraj, P., & Mohapatra, PK (2008). 24時間ソフトウェア開発プロセスのモデリング。Strategic Outsourcing: An International Journal、1(2)、122-141。
- ^ Taweel, A., & Brereton, P. (2006). タイムゾーンをまたいだソフトウェア開発のモデル化。情報およびソフトウェア技術、48(1), 1-11。
- ^ ab Kroll, J., Hashmi, SI, Richardson, I., & Audy, JL (2013 年 8 月)。フォローザサン ソフトウェア開発におけるベスト プラクティスと課題に関する体系的な文献レビュー。Global Software Engineering Workshops (ICGSEW)、2013 IEEE 第 8 回国際会議 (pp. 18-23)。IEEE。
- ^ ジェフ・カルーソ (2009年8月19日). 「月を追って、何百万人も救おう」
- ゴディネス、ビクター (2007 年 1 月 2 日)。「Sunshine 24/7: EDS の作業は 1 つのタイム ゾーンで停止しても、別のタイム ゾーンで再開」。ダラス モーニング ニュース。2008 年10 月 31 日閲覧。
- 「太陽を追う：グローバル ソフトウェア開発のケース スタディ」。IBM Systems Journal。2006 年 10 月 1 日。2008年10 月 31 日に閲覧。
- 「グローバル コール センター ネットワークがバークレイズのコストを大幅に削減」。Computer Weekly。2001 年 10 月 11 日。2008年10 月 31 日閲覧。
外部リンク
- 業界での使用例 - IT サポート