チームプログラミング

ソフトウェア工学において、チームプログラミングとは、コンピュータソフトウェア開発プロジェクトにおけるタスク配分を調整するためのプロジェクト管理戦略であり、2人以上のコンピュータプログラマーを、大規模なプログラミングプロジェクト内の個々のサブタスクに共同で取り組むよう割り当てることを意味します。一般的に、この用語が現在使用されている方法は、複数の個人が同じ作業に同時に取り組む、ソフトウェア開発業界で現在流行している手法を指します。これらのシステムでは、プログラマーは多くの場合、同じコンピュータワークステーションで2人1組でグループを構成し、一方が他方のソフトウェア作業を観察し、一定間隔で役割を交代します。

従来のチーム管理方法

従来のソフトウェア開発では、範囲と規模の大きいプロジェクトでは、ほとんどの場合、複数のプログラマがコンピュータ システムの別々の部分で作業する、つまり分業方式でした。 1 人のプログラマが、実行可能な時間内に完全に独力で複雑なシステムに必要なすべての作業を適切に完了できると考えるのは明らかに不合理です。 また、開発プロジェクトが複雑になるにつれて、システム分析、品質保証、個々のコンポーネントがもたらす技術的課題などの側面で専門知識が最も重要になります。 当初は非公式なプロセスになる傾向がありましたが、商用ソフトウェア開発が実行可能な産業として台頭するにつれて、より産業的かつ体系的なアプローチが必要になりました。

構造化システム分析設計法（SSADM）など、もともと政府プロジェクトのために設計された紙ベースのシステム方法論では、個々の担当者に個々のタスクを割り当て、ウォーターフォール型ソフトウェア開発モデルにおける設計者の役割をプログラマーの役割とは明確に区別していました。また、この方法論では、システム開発プロジェクトが進行する個々の「ライフサイクル」段階も明確に区別されていました。その結果、システム開発プロジェクトの「紙の証跡」の作成に非常に長い時間がかかり、分析ドキュメントの一部、あるいは場合によっては全体が実際の開発時には古くなっていることが多く、役に立たないどころか、むしろ役に立たないものになっていました。

現代のトレンド：1つのサブタスクに複数のプログラマー

これらの旧来の手法では、システムの拡大に伴いコストが制御不能に陥ったり、市場投入期間の目標達成に間に合わなかったりといった問題が顕在化しました。こうした問題から、ペアプログラミング、モブプログラミング（別名アンサンブルプログラミング）、そしてベームスパイラルといった新しいシステムライフサイクル構造といった手法が生まれました。これらの新しいアプローチの仕様策定は1980年代半ばに始まり、現在も続いています。これらの戦略の多くは、複数のプログラマーが個々のタスクに個別に責任を負うのではなく、同じソースコードに共同で取り組むことを前提としています。例えば、「ペアプログラミング」では、結果として得られる製品に対する責任は、割り当てられたサブタスクに共同で取り組む2人のプログラマーの間で均等に分担されます。このアプローチの利点としては、一方のプログラマーの知識不足を、もう一方のプログラマーの特定分野の能力で補えること、そして責任の共有によってプロジェクトの期限や品質目標の達成に対するインセンティブが高まることが挙げられます。

この手法は、 Rational Unified ProcessやExtreme Programming（略称XP）といったオブジェクト指向プログラミング技術を中心とした新しいプログラミング手法で頻繁に用いられ、統一モデリング言語（UML）などの設計ドキュメント作成手法と組み合わせて使用​​されることが多い。オブジェクト指向プログラミング言語では、ソフトウェア機能はモジュール化された個別の単位（機能要素はクラス、特定の機能を実行する相互にリンクされたクラスの集合はパッケージと呼ばれる）を形成する。最もよく知られているのはC++とJavaである。これはプログラミングプロジェクトをサブチームに分割するのに有効であるが、各サブタスクの完了後に結果として得られる製品を統合する際には、依然として問題が発生することが多い。

モブプログラミング

フランスのモブプログラミングセッション

モブプログラミング（非公式にはモビング、アンサンブルプログラミング、ポッセプログラミングとも呼ばれる^[1]）は、チーム全員が同じ作業に、同じ場所で、同じコンピュータを使って同時に取り組むソフトウェア開発手法です。これは、 2人が同じコンピュータの前に座り、同時に同じコードで共同作業を行うペアプログラミングに似ています。モブプログラミングでは、コードの記述とコードベースへの入力には1台のコンピュータを使用しますが、共同作業はチーム全員に拡張されます。^[2]

モブプログラミングの基本コンセプトはシンプルです。チーム全員が一つのタスクに同時に取り組むというものです。つまり、一つのチーム、一つの（アクティブな）キーボード、そして一つのスクリーン（もちろんプロジェクター）です。 ^[3]

— マーカス・ハマーバーグ、モブプログラミング – フルチーム、フルスロットル

これは、リーン生産方式、エクストリームプログラミング、そしてリーンソフトウェア開発の原則に基づいています。「モブプログラミング」という用語が最初に使われたのは、『エクストリームプログラミングの視点』です。^[4]

モブプログラミングチームは、ソフトウェアコーディングに加えて、他の一般的なソフトウェア開発タスクにも共同で取り組むことができます。例としては、ユーザーストーリーや要件の定義、設計、テスト、ソフトウェアの導入、専門家との連携などが挙げられます。ほぼすべての作業はワーキングミーティングやワークショップで行われ、顧客やビジネス専門家を含むソフトウェア開発に関わる全員がチームメンバーとみなされます。^[5]モブプログラミングは、画面共有技術を用いて、同じ仮想空間内に分散したチームでも機能します。^[6]

参照

• ペアプログラミング
• エクストリームプログラミング

参考文献

1. Edward Sykes (Heretsch); Rajpal Singh (2012). 「ACCU 2012 ライトニングトーク：Posseプログラミング」（PDF） . Accu2012 ライトニングトーク.
2. Zuill, Woody (2014). 「モブプログラミング：チーム全体で取り組むアプローチ」Agile2014カンファレンス体験レポート：11.
3. Hammarberg, Marcus. 「モブプログラミング – フルチーム、フルスロットル」. CodeBetter . CodeBetter. 2014年11月15日時点のオリジナルよりアーカイブ。 2014年9月9日閲覧。
4. Moses Hohman、Andrew Slocum (2002). 「第28章 モブプログラミングとXPへの移行」. Extreme Programming Perspectives . Addison-Wesley.
5. ニグリ、ジュリアン。 「ル・モブ・プログラミング：プレゼンテーション」。ソート（フランス語）。ソート。2014 年9 月 9 日に取得。
6. ハラー、サイモン;キリスト、ヨッヘン。フーバー、マーティン。 「リモートモブプログラミング」。2019 年4 月 29 日に取得。

外部リンク

• モブプログラミング