Can a Team be too Big?

By Russ Finney

チームは大きくなり過ぎないか？

System development projects come in all shapes and sizes. At many smaller companies, a project "team" may only consist one to three people working on a specific business application. Conversely, at a huge corporation, a multi-year project may involve literally hundreds of people. So does an optimal size really exist for the number of people who should be on a development team for maximum effectiveness? Fred Brooks, in his book The Mythical Man-Month, puts the recommended number at ten.
システム開発プロジェクトは、形態も大きさも様々である。小さな企業では「チーム」は、特定の業務を対象に1人から3人で構成される。他方、大企業では数年に渡るプロジェクトに文字通り何百人が参加する事もある。それでは、開発チームに最も効率良い最適の規模というものが、実際存在するのだろうか？Fred Brooksは、著書The Mythical Man-Monthで、10人という数字を推奨している。

In this context, he describes the various roles these ten people should assume. The team leader, in addition to the usual administrative duties, is responsible the for the overall business and technical "architecture" of the system, and the methods, approach, and techniques which will be ultimately employed throughout the development effort. He or she should have several sub-team leaders who take the responsibility for either a functional business area or a technical specialty (such as on-line lead, batch lead, or data base administrator). The rest of team members fulfill support roles as needed for programming, data modeling, process modeling, testing etc. The key to this approach is the team leader is a primarily system architect first, and his or her administrative duties take second place to this overriding responsibility.
その中で、彼はこれらの10人の人が受け持つ様々な役割を説明している。チームリーダは、通常の管理義務に加えて、開発作業の間に採用されるシステムの業務・技術両面の全体構造、解決方法、（プロジェクト）手法、技術などについて責任を負う。彼（彼女）は、機能別の業務分野や、個別の専門技術(オンライン処理、バッチ処理、データベース管理など)について責任を持つ数人のサブチームのリーダーを、任命する。残りのメンバーは, プログラミング、データモデル作成、(業務)処理モデル作成、テストなどでリーダを支援する役を果たす。この考え方のポイントは、”チームリーダは、一義的にはシステム設計者であり、管理業務は2次的なもの”としている事である。

Mr. Brooks also gives an excellent analogy of the similarity between a project team leader and a medical surgeon. In an operating room, the surgeon decides which techniques will be used, the surgical methods which will be followed, and the course of action if a crisis should occur. The surgeon is thus accountable for the outcome of the operation, and the remaining surgical team members are present to assist and to make recommendations. This is very similar to the situation with which the project team leader is faced. But how can this optimal organization be utilized on very large projects where over twenty, or over fifty, or even over one hundred people may be involved?
また、Brooks氏は、プロジェクトチームのリーダーと外科医の類似性を見事に示している。手術室では、外科医が、使用する技術、手術の方法、緊急時の対応処等を決定する。従って、外科医は、その結果に責任を負い、残りのチームメンバーは、彼(彼女)を助け、助言をする為にその場にいるのである。これは、プロジェクトチームのリーダーが、直面する状況と非常によく似ている。しかし、20人、50人あるいは100人を越す人々が関係する極めて大規模なプロジェクトで、この様な最適の組織を実現するにはどうしたら良いだろうか？

The answer is: don't change the approach. The development effort must be sub-divided in such a way that each piece can be assigned an optimal mix of team members along with an accountable team leader, who takes responsibility for the role of system architect for that sub-system. The trick is to build an effective oversight organization to coordinate the activities of these sub-project teams. This means that a master system architect must be appointed to oversee the activities of all the team leaders. In many cases, this individual may needs a separate staff to help support the overall administrative, coordination, and decision responsibilities he or she will be facing. This is where the project bureaucracy begins to take shape, and the key is to make sure that its primary focus is on communication and integration, rather than administrivia and red-tape.
答えは、「基本は同じ」と言う事である。開発作業は細かく分割され、各々が信頼出来るリーダに率いられ、最適に編成されたサブシステムに割り当てられる。各リーダは、担当のサブシステムについて、設計者として責任を負わなければならない。肝心なのは、これらのサブプロジェクトチームの活動を効果的に調整する組織を作っておく事である。これは、全チームリーダーの活動を監督するシステム設計総括責任者を任命しておかなければならないということを意味する。大抵、この人物は、総括的な管理、調整、意志決定に当たって、各々の分野に支援スタッフを必要とする。これが、プロジェクトに官僚制を持ち込む原点にもなるが、目的はあくまでコミュニケーションの促進とチームの結束を図る事であり、管理体制やお役所仕事では決して無い。

Listed below are several success factors to consider when assembling a very large project team:
以下は、非常に大きいプロジェクトチームの編成時に考慮されるべき成功要件である：

• The overall project should be lead be a master system architect who is vested with the final decision authority on functional, technical, methodological, scope, and approach issues. He or she must empower the team leaders to work independently, as well as insuring that the sub-team's efforts are centrally coordinated and integrated.
• Each sub-project (made up of a maximum of ten people), should be lead by an experienced, proven system builder who recognizes the importance of cross-team communication. This person must be vested with the same level of accountability as if the sub-project was a "stand-alone" effort.
• Clear standards should be set by the master architect, after receiving the advise and council of the team leaders. These standards should foster both the seamless integration of the sub-systems as well the creation of a consistent product from the diverse project teams.
• All workplans, budgets, and schedules should be compared and coordinated on a regular basis. Timing problems and schedule inconsistencies must be quickly identified, and the team must remain open to rapid contingency planning.


• 全体のプロジェクトは、システム設計総括責任者によって率いられなければならない。彼(彼女)は、機能、技術、方法論、構想、手法などの問題について最終決定の権限を有する。また、サブチームの作業が一元的に調整され統合されるのを確認すると共に、チームリーダに自らの裁量で行動する権限を与えなければならない。
• どのサブプロジェクト(最大10人から成る)も、チーム間コミュニケーションの重要性を理解している経験豊富なシステム構築者によって率いられなければならない。この人物は、サブプロジェクトを「独立した」ものとみなし、同様の説明責任を負わなければならない。
• システム設計総括責任者は、チームリーダー会義の助言をうけて、明確な規定・規準を策定する。これらの規定によって、多様なプロジェクトチームが整合性のとれた成果を生み出せると同時に、サブシステムの一様な統合が可能になる。
• 全作業計画、予算、スケジュールは、定期的にチェックされ調整されるなければならない。タイミングの問題やスケジュールの矛盾は、すぐに見つけなければならない。また、チームは、不測の事態に迅速に対処出来なければならない。

Copyright © 1999, Russ Finney, All Rights Reserved