Loading article…
分散型アジャイルソフトウェア開発とは、地理的に分散したプロジェクトにおける課題を克服することを目的として、アジャイルソフトウェア開発の原則をグローバルに分散した開発環境に適用した場合の効果を考察する研究分野である。
アジャイルソフトウェア開発の原則は、より良いコミュニケーションを促進するための構造を提供しており、これは分散環境での作業を成功させる上で重要な要素です。しかし、対面でのやり取りがないことは、アジャイル開発の中核となる原則の一つを失わせることになります。そのため、分散型アジャイルソフトウェア開発は、一般的なアジャイルソフトウェア開発よりも困難なものとなります。
インターネットの技術的有効性によってもたらされる新たな機能の助けを借りたグローバル化の進展により、ソフトウェア開発企業は開発業務をより経済的に魅力的な地域にオフショアするようになった。この現象は90年代に始まり、その戦略的重要性は2000年代に認識された。[ 1 ]関連する初期の研究のほとんどもこの頃に行われたものである。[ 2 ]
この時期に、アジャイルマニフェストが発表されました[ 3 ] 。これは、ソフトウェア開発における主流の重厚なアプローチからの進化を表しています。これにより、「分散ソフトウェア開発はアジャイルになり得るか？」という疑問が自然に生じました。この疑問に答えようとする最初の包括的なレビューの1つは2006年に行われました[ 4 ]。3つの組織を調査した結果、「分散ソフトウェア開発環境にアジリティを慎重に組み込むことは、分散チーム間のコミュニケーション、制御、信頼に関するいくつかの課題に対処するために不可欠である」ことがわかりました。その後、2014年に、分散方式でアジャイルを機能させる際の主な問題を特定するために体系的な文献レビュー（SLR）が行われました[ 5 ] 。 2019年にも同様のSLRが行われました[ 6 ] 。
分散環境では、全員の作業負荷と成果物への貢献度を把握することが困難になる場合があります。アジャイルの原則と実践を採用することで、プロジェクトの初期段階で問題や重要事項を視覚化できるイテレーションが複数回行われるため、可視性が向上します。アジャイルソフトウェア開発の重要な要素の一つであるプログラミングコードの継続的インテグレーションは、管理上の問題の発生を減らすことにも役立ちます。アジャイルの原則を採用することで、グループ間のコミュニケーションに良い影響があるようです。サイクルを進めることで、メンバーが短期的な目標を容易に把握できるようになります。スプリントレビューは、外部コミュニケーションを改善する強力な方法であり、パートナーやステークホルダー間で機能や前提条件に関する情報を共有するのに役立ちます。アジャイルの実践は、一貫したコミュニケーションとプログラミング成果物の伝達を促進することで、プロセスに関わるさまざまなチーム間の信頼構築にも役立ちます。 Passivara、Durasiewicz、Lasseniusによる調査によると、プロジェクトで採用されたスクラムアプローチの結果、ソフトウェアの品質とコミュニケーションが改善され、コミュニケーションと協調作業が比較的に規則的になったことが示されています。さらに、同僚のモチベーションも高まったと報告されています。[ 7 ]このように、分散環境でアジャイルプラクティスを採用することは、プロジェクトの品質と実行にとって有益であることが証明されています。したがって、これらは分散開発にアジャイルを組み合わせることによって得られる利点の一部と見なすことができますが、[ 8 ]リストは網羅的ではありません。主な利点は次のとおりです。
分散型環境は、ローカルな考え方よりもグローバルな考え方を育み、チームメンバーは互いのアイデア、認識、文化、美意識などを交換し、受け入れることができます。多様な文化背景を持つメンバーは、異なる視点から仲間から知識を得たり共有したりする機会を得ます。このようにして、既成概念にとらわれない発想で、新たな計画を業務に持ち込むことができるのです。
チームメンバーは、業務遂行において豊富な自由と機会を享受でき、唯一の目標はタスクを完了し、成果物を期日までに提出することです。これは組織に対する責任感の拡大にもつながります。このようにして、従業員は仕事と私生活のバランスを取ることができ、結果としてワークライフバランスも実現できます。
チームは複数のタイムゾーンにまたがって活動できるため、24時間以内であればいつでもアクセス可能です。世界中から人材を雇用できるため、生産性が向上します。常に誰かが問題に対応できるため、作業が中断されることはありません。これにより、太陽の周りを24時間365日稼働し、ダウンタイムがほとんど発生しないことが保証されます。分散環境は生産性とパフォーマンスを重視するため、作業の引き継ぎはタスクの達成に役立ちます。
前述のとおり、分散型アジャイル環境では、出勤状況よりも生産性とパフォーマンスが重視されます。これは、障がいのある方々にとって、自分にとって快適な環境で自由に働き、成果物に貢献できるというメリットがあります。また、従業員がオフィスに出勤して勤務時間を記録できない場合でも、自宅で業務を完了できるため、成果物に影響を与えることなく作業を進めることができます。
分散型アジャイル環境での作業は、個人と企業双方の繁栄と幸福度を高めます。これは、作業が世界中の複数の人に分散されるため、一人の人間が作業を完了させるという大きなストレスが軽減されるからです。これにより、身体的および精神的な健康が確保されます。また、複数の人がそれぞれの役割を果たし、何度も反復作業を行うことで、最終的な成果物の品質が向上し、企業にとって有益となります。したがって、企業と従業員双方にとってメリットのある状況と言えるでしょう。
分散環境での作業では、目標、締め切り、作業内容などについて議論や会議を行う必要が生じることがよくあります。しかし、分散環境でアジャイルの原則と実践を取り入れることで、ビデオ会議などの利用可能な手段によるコミュニケーションが可能になり、出張費を削減できます。これにより、物理的な出席の必要性が減り、対面でのやり取りが強化されるため、会議は世界中のどこからでも開催でき、チームの他のメンバーも参加できるようになります。
作業は反復的に進められるため、成果物の進捗状況や、関係者全員が同じ理解度を共有しているかを定期的に確認することができます。また、この方法により、エラーやバグの特定が容易になり、プロセスが複数回の反復を経ていく中で、早い段階で修正することが可能になります。各段階におけるインプットの増加は、成果物の品質向上につながります。
同じ業務が世界各地で実施されることで、世界中のより広範な人材プールを活用できるようになり、グループの能力範囲が拡大します。そのため、組織内の様々な部門や分野における連携や意思決定を強化し、ステークホルダーとのコミュニケーションを図り、成果物の優先順位付けを行うために、すべての人事担当者が一体となって行動する必要が生じます。
分散型アジャイル環境はリモートワークの概念を強化するため、より多くの従業員を収容するためにオフィススペースを拡張する必要はなくなります。また、従業員は希望する環境で自由に働くことができるため、電気、コンピューター、駐車場などの仕事関連のさまざまな事柄は大きな懸念事項ではありません。これは、そうでなければこれらの間接費に費やされるであろう多額の費用を節約するのに役立つため、ある意味で有益です。クライアントへの継続的なデリバリーによる反復的な改善は、アジャイルソフトウェア改善の中心的なプラクティスであり、オフショア展開の重大な困難の1つであるプロジェクト状況の可視性の低下を正しく特定します。定期的な対面会議により、チームリーダー、プロジェクトマネージャー、クライアント、顧客は、取得した作業プログラムによってプロジェクトの進捗状況を追跡できます。
分散型ソフトウェア開発には、分散チーム間の空間的、時間的、社会文化的差異に起因する固有の課題があります。これをアジャイル原則およびプラクティスと組み合わせると、両方の手法が互いに正反対であるため、関連するリスクの深刻度が増します。アジャイルソフトウェア開発は、非公式なコミュニケーションと緊密なコラボレーションに基づいているため、もともと同じ場所にいるチームで使用するために設計されました。しかし、分散開発には、公式なコミュニケーション、明確な標準、設定されたガイドライン、および厳格な構造が必要です。[ 9 ]このセクションでは、前述の互換性の問題の結果として、分散型アジャイルソフトウェア開発に伴うリスクと課題について説明します。
分散環境でアジャイルの原則と実践を組み合わせる際に直面する非互換性の結果として、以下のような課題が生じる可能性があります。[ 10 ]
オフショア組織は、詳細な要件をオフショアに送って構築する計画主導型設計を好む。[ 11 ]これは、ドキュメント作成の優先順位を低くするアジャイルチームの一般的な慣行と矛盾する。この状況の結果、誤解が生じる可能性がはるかに高くなる。
ペアプログラミングは、2人のプログラマーが並んで特定の問題に取り組むもので、一般的なアジャイルプラクティスです。この方法は、プログラマーの満足度を維持しながら、より短い時間でより良い製品を生み出すことが示されています。[ 12 ]チーム間の距離のため、これを実現するのは非常に困難です。
各分散チームのタイムゾーンが異なるため、両チームが都合の良い時間に会議を設定することがより困難になります。片方のチームメンバーは会議に参加できるが、もう片方は参加できないという状況が容易に発生する可能性があります。これは、差し迫ったタスクのプログラムコンポーネントが密接に連携している場合に特に問題となります。このような場合、一方のチームは他方のチームからのフィードバックなしには作業を進めることができません。
分散型環境では、密接なコミュニケーションが取れないことによるデメリットは、特に研修期間を必要とする経験の浅い開発者にとって顕著です。同じ場所にいない従業員を研修するのは困難です。背景や文化の違いを考えると、経験の浅いチームメンバーを迅速に業務に慣れさせるのは容易ではありません。そのため、代替的な研修方法を検討する必要があります。
作業の分配に関しては、場所に基づいて作業を分配することで、チームの地理的な分散をアーキテクチャに反映させることを避けたいと考えています。コンポーネントではなくストーリーの観点から考え、単一のユーザーストーリーに関連するタスクをチーム全体に分配する方が良いでしょう。地理的な場所やコンポーネントによる過度の専門化は、分散チームに課せられるコミュニケーションの課題にチームがうまく対処できていない兆候です。この過度の専門化は、顧客の要求ではなく開発に合わせて製品を変更するという意図しない結果をもたらします。[ 13 ]
2013年に行われた研究では、分散型アジャイル開発におけるリスク管理に関する文献を統合しようと試みました。[ 9 ]より包括的な研究では、分散型アジャイルプロジェクトのリスク要因を分類しようと試みました。[ 14 ]これは、研究文献と13のIT組織の実体験の両方を利用して行われました。簡潔にするため、対応する管理手法を含む45のリスク要因の全リストは省略されています。代わりに、主要なカテゴリと全体的な管理手法の簡単な要約が示されています。
このカテゴリには、顧客による要件仕様の策定や計画、モデリング、構築、ソフトウェア アプリケーションの展開など、ソフトウェア開発のさまざまな活動に関連するリスク要因が含まれます。[ 15 ]このカテゴリのリスク要因の多くは、知識の共有が不十分であることに起因します。不明確な目的、要件、標準プロセスの慣行の違い、設計間の不整合などが挙げられます。これらのリスクの多くは、知識が効果的に共有されるようにすることで管理できます。より具体的には、プロジェクトの目的と要件がチーム間で明確に理解されていることを確認してください。開発サイクルの可能な限り多くの部分を自動化および標準化し、各チームが同じテクノロジー スタックとインフラストラクチャで作業できるようにします。つまり、全員が同じ認識を持っていることを確認してください。
プロジェクト管理とは、プロジェクト計画、プロジェクト組織化、プロジェクト人員配置、プロジェクト指揮・管理といった業務を指します。この分野には、開発活動と管理活動の相互作用に起因するリスクが伴います。分散型アジャイル開発の導入は、プロジェクトの管理方法を根本的に変革します。これを慎重に行わないと、初期開発速度の低下、スプリントごとのチーム再編成、複数拠点チームの能力の不均一性といったリスクが生じる可能性があります。
このカテゴリーには、グループ意識の欠如に関連するリスク要因がまとめられています。グループ意識を高めるには、グループメンバー間の集中的なコミュニケーション、調整、協力、そして信頼関係が不可欠です。同じ場所にいるチームは、物理的に同じ場所にいることで自然に意識が高まるため、この意識をより容易に獲得できます。グループ意識の欠如に伴うリスクを管理するために、地理的に分散したチームは、最新のテクノロジーツールを活用した、より規律あるコミュニケーション手法を用いる必要があります。プロジェクトの方向性を定めるために、初期段階で同じ場所に集まるといった手法は、リスク管理において効果的であることが証明されています。
これらの要因は、顧客、ベンダー、およびサードパーティ開発者との連携に関係しています。リスク管理の要点は、これらの外部関係者との調整とコミュニケーションを効率的かつ明確に行うことにあります。
不適切なツール使用によって生じるリスク要因は、このカテゴリーに分類されます。例えば、コミュニケーション体制の不備は、チームにビデオ会議ツールを提供することで解決できます。さらに、プロジェクトで使用する適切なツールを選択することも重要です。これはプロジェクト、チーム、ユースケースによって異なるため、事前に使用するツールについて分析することをお勧めします。
分散型アジャイルソフトウェア開発で直面する課題を克服する上で最も重要な要素の1つは、コミュニケーションを改善することです。[ 10 ]これは、コミュニケーションセッションのセットアップと終了にかかる時間を最小限に抑え、可能であれば音声会議よりもビデオ会議を優先することを意味します。
信頼関係を築くために、チーム全員との対面でのコミュニケーションの機会を奨励すべきである。プロジェクト開始時にこれを行うことは、チームがプロジェクト全体を通して従うことができる計画を立てる上で有益である。さらに、最終成果物のリリース前の最後の数回のイテレーションでも有益である。[ 13 ]
タイムゾーンの違いによる会議への参加の難しさに対処する一つの方法として、両チームと良好な関係を築いている代表者をチームに任命し、両チームの仲介役を担わせるという方法があります。また、多段階の報告と複数のデイリースクラムミーティングを伴うネスト型スクラムを使用する方法もあります。[ 16 ]
時差のあるチームでスクラムミーティングを行うための解決策は、ローカルチームミーティングとグローバルスクラムミーティングを区別することです。[ 17 ]各チームは、1日の始めにローカルミーティングを行い、1日の別の時間にグローバルミーティングを行います。これは、勤務時間が重なる場合にのみ可能です。
分散型チームであるため、確立されたアジャイルプラクティスから逸脱してしまう可能性があります。そのため、チームが正しい方向へ進むよう導くコーチ役の人物が必要です。また、分散型ワーク環境におけるアジャイルプラクティスの代替案を自ら検討することも重要です。
採用したアジャイルアプローチについてチームメンバー全員に周知徹底するためには、プロジェクトのドキュメントを維持することが重要です。これにより、分散ソフトウェア開発環境でアジャイルの原則とプラクティスを使用する際のグループコラボレーションが向上します[ 16 ] [ 18 ] [ 19 ] 。[ 20 ]このためには、ドキュメントの維持をチームにサポートするさまざまなツールを使用できます。[ 18 ] 。
分散環境におけるコミュニケーションを改善するために、さまざまなツールやプラットフォームを活用できます。分散チーム間の仮想的な距離を最小限に抑えるためには、これらは非分散環境よりもさらに不可欠です。
分散型ソフトウェア開発におけるコミュニケーションを支援するツールは数多く存在します。電子メールのような非同期ツール、音声・ビデオ会議ソフトウェアのような同期ツール、インスタントメッセージングのようなハイブリッドツールは、チームメンバーが必要な会議やコミュニケーションを行うための手段を提供します。また、ソーシャルネットワーキングを支援するツールは、場所を問わずチームメンバー間の共有体験を生み出すのに役立ちます。
プロジェクトを円滑に進め、すべてのチームとチームメンバーが、実施すべき作業内容を明確に理解できるようにするためには、課題管理ツールなどのプロジェクト管理プラットフォームを活用する必要があります。
すべてのチームメンバーに共通の体験を提供するために、すべてのチームメンバーは開発に同じツールを利用できる必要があります。[ 21 ]同じソフトウェア構成管理ツールをプロジェクト管理ツールにリンクさせることで、開発者は同じペースで作業し、同様の方法で開発についてコミュニケーションをとることができます。
すべてのチームメンバーが製品と開発に関する同じ知識にアクセスできるようにするには、Wikiソフトウェアやナレッジベースなどのツールを利用できます。
アジャイルマニフェストの価値観と原則は、12のケーススタディにおいて、分散型ワーク環境における適用可能性の観点から検討されてきた。[ 22 ]これらの研究では、分散型アジャイルソフトウェア開発をプロジェクトに適用したソフトウェア企業を追跡調査した。12のケースのうち、10社は米国に拠点を置くオンショア企業であり、7社はインドに拠点を置くオフショア企業であった。調査結果は以下の表にまとめられている。
このことから、すべてのケーススタディが、プロセスやツールよりも個人と相互作用を重視すべきであるというアジャイルマニフェストの最初の価値を強調していることがわかります。アジャイルマニフェストは、必ずしもドキュメントを完全に否定するわけではありませんが、包括的なドキュメントよりも動作するソフトウェアを優先します。この価値は、ほとんどのケースにも反映されています。顧客とのコラボレーションの重要性を契約交渉よりも強調しているケースは4つしか特定されていません。表から明らかなように、4番目の価値は、ソフトウェア企業によってすべての価値の中で最も採用されていません。「一般的に定義されているアジャイル開発プラクティスに厳密に従うのではなく、企業はプロジェクトの進化するニーズに合わせてそれらを継続的に微調整しています」。[ 23 ]アジャイル原則に関しては、開発チームとの対面での会話がすべての研究で評価されていることは驚くべきことではありません。これは、オンショアチームとオフショアチームの間で電子的にシミュレートされました。開発の後半でも変更要求を受け入れるかどうかについては、研究対象のソフトウェア企業のいずれも詳細を提供していません。このことから、それは他の原則ほど重要視されていなかったと推測できる。