Winning Project Teams

By Russ Finney

成功するプロジェクトチーム

System Building Competence
システム構築能力

This is absolutely critical. The ability to succeed is established within the minds of the clients as well as the project team members in the early stages of the effort. An essential component of this perception is both the management ability, the technical skills, and the sense of direction possessed by the project leadership. Both the business clients and the team can detect fairly quickly if the project leaders have "what it takes" to take them to a final product. Without question this feeling has a tremendous impact on morale.
これは、絶対に必要だ。成功出来る能力は、プロジェクトの早い段階で、顧客やプロジェクトチーム・メンバーの気持ちの中に作られる。 この考え方の重要な要素は、管理能力、技術力、プロジェクト・リーダーの指向性である。 ”プロジェクトを完成させるのに何をすべきか、リーダーが判っているかどうか”、エンドユーザーもチームも、非常に早く気付くだろう。 間違いなく、この感触はプロジェクトの志気に非常に大きな影響を与える。

Humphrey Watts in his book Managing the Software Process, describes a model for measuring the maturity of a software development organization. These ideas were further refined by the Software Engineering Institute (SEI) at Carnegie Mellon University. A brief summary of the maturity levels of the model (in terminology which will relate to some of the central themes of this white paper) are presented below:
Humphrey Watts は、著書Managing the Software Processの中で、ソフトウェア開発組織の成熟度を測るモデルを 説明している。この考えは、カーネギーメロン大学のソフトウェア工学研究所[the Software Engineering Institute (SEI)]によって 更に精練された。(この白書の中心課題に関連した用語による)モデルの成熟度の要約は、以下の通り。

Initial Level
導入レベル

A team or organization at this level tends to take a chaotic, ad-hoc, "invent as we go" approach toward every new systems building effort.
このレベルのチームや組織は、新しいシステム構築作業の度に、渾然とした、臨時の、行き当たりばったりの手法を採る。

Repeatable Level
反復レベル

A team or organization at this level uses planning techniques, gathers requirements in a systematic fashion, utilizes software quality assurance techniques, and follows a patterned approach on each subsequent effort.
このレベルのチームや組織は、計画技法を使い、組織的にシステム要件を集め、ソフトウェアの品質保証技法を利用し、 続く構築作業では定式化された手法に従う。

Defined Level
定型化レベル

A team or organization at this level follows defined methodological steps, uses process improvement techniques to enhance the methodological approach, conducts regular training programs, views the entire systems development process from an integration perspective, and utilizes more disciplined information engineering and structured development techniques.
このレベルのチームや組織は、定型化された方法論的手順に従う。作業改善技法で方法論的手法を強化し、 定期的に学習会を開き、システム開発作業全体を統合化の視点で見つめ、 より厳格な情報工学や構造化開発技法を適用する。

Managed Level
総合管理レベル

A team or organization at this level actually captures and utilizes software development metrics for future estimation and process analysis purposes. In addition, some of concepts of Total Quality Management (TQM) are employed to reinforce the effectiveness of the entire development process.
このレベルのチームや組織は、ソフトウェア開発の指標（工数など）を計測し、将来の見積りや業務分析に利用する。 加えて、総合品質管理Total Quality Management (TQM)が、開発作業全体の効率改善に導入される。

Optimized Level
最適化レベル

A team or organization at this level utilizes continuous organizational change management techniques to optimize its own operations (as well as the company's), emphasizes defect prevention rather than defect detection, and constantly seeks technological innovation opportunities.
このレベルのチームや組織は、(会社の業務に加えて)自分達の作業を最適にする為、継続的組織変更管理技法を導入する。 問題発見より問題防止に力点が置かれ、普段から技術革新の機会を探る様になってくる。

Project Team Experience
プロジェクトチームの経験

Even within organizations with high success rates, one factor which never changes on each new effort is the amount of experience possessed by the chosen project team members. Will the project team include a business expert? If not, will the assigned members be able to effectively comprehend and discuss the business requirements and issues in the client terminology? Having someone on the team (even if only in the initial phases) who understands the business is a great confidence builder! It allows the analysts and designers to ask the dumb or simplistic questions to someone other than the client. This actually makes more effective use of everyone's time and it adds an subsequent level of security. In addition, it puts someone in the position of making sure that "creative thinking" stays within reasonable boundaries.
高い成功率を誇る組織においてさえ、新しいプロジェクトに関しては、変わる事のない一つの事柄がある。 それは、プロジェクト・チームメンバーの経験の量である。そのチームに業務の専門家はいるのか？ いなければ、業務要件や懸案事項を充分理解し、顧客の言葉で討議する事が出来るメンバを指名出来るか？ (初期段階だけでも) プロジェクトチームに誰か業務に精通した人間がいれば、信頼獲得に大きく貢献する。 また、システムアナリストや設計者は、顧客を煩わせる事なく、幼稚で些細な質問をする事が出来る。 結果、全員が時間をより効率的に使い、後続作業に時間的余裕を持たせる事も可能になる。 更に、”独創的な発想”が妥当な範囲に収まる様、監視する役を置ける様になる。 ［突拍子も無い考えが、勝手に広がるのを防げる］

What about technical expertise? Is the project entering uncharted waters without a guide? Having someone on the team who is familiar with the specialized knowledge surrounding a selected technological environment provides the same confidence creating benefits as those listed above. A technical expert can assist others, make suggestions, develop standards, and prevent time consuming mistakes. In addition, he or she can provide leadership by example. By spearheading the work and creating examples for others, a technical expert can transfer knowledge and experience in a timely and effective manner. The prevents the "invent as we go" situation teams often find themselves in when embarking on a new technology.
技術力はどうか？プロジェクトは、何の知識も持たずに未知の分野に入ろうとしているのか？ 採用した技術環境に関する専門知識を持ったメンバーの存在は、上記と同じ信頼感を生み利益をもたらす。 技術専門家は、他のメンバーを支援し、助言を与え、規準を作成したりして間違い訂正にかかる時間を未然に防ぐ事が出来る。 そして、彼(彼女)は、リーダシップを身を以って示す事が出来る。 仕事を率先したり手本を示したりして、技術専門家は、知識や経験をタイミング良く効果的に引き継ぐ事が出来る。 また、チームが新技術を採用した時にしばしば直面する”行き当たりばったり”の事態を未然に防ぐ。

Project Control and Coordination
プロジェクトの統制と調整

Large, complex undertakings which require the participation of many people throughout the development process, demand both high-level and detailed guidelines to assist in the channeling of the individual results into an integrated final product. As each person focuses on his or her's part of the system, a clearly defined set of standards and specifications must exist insure that the final result will "mesh" with the results being produced by others. In many ways, a systems building project can be thought of a series of specifications, each level spiraling from broad requirements into highly detailed procedural instructions. The collection of these efforts into a unified whole presents the ultimate challenge for the group. What are some of the ways to successfully make this happen?
開発の期間を通して多数の参加が必要な大規模で複雑な仕事は、 個々の成果を統合化された最終成果に結び付けるのに高度で詳細な指針が必要である。 各人は、システムの自分の担当部分しか見ていないので、明確に記された規準や仕様が存在しなければならない。 これにより、個人の成果が、他のメンバーの物と組み合わされる時の整合性を確保する。 多くの点で、システム構築プロジェクトは一連の仕様作成作業と見なす事も出来る。 それぞれの段階で、概要仕様から非常に詳細な作業指示へと（渦巻き状に）展開されるのである。 これらの結果を統合して一つの成果に仕上げる事が、グループにとって最大の課題となる。 これを成功に導く方法は何だろうか？

Ultimately, three major factors contribute to the level of success that systems building team will enjoy at each of the required integration points. One of these factors is the creation of "consistency" standards. During each phase, guidelines should be developed for both the content as well as the format of the final work products. A second important factor is cross-team communication. Common requirements, similar issues, shared data, and reusable functionality all should be openly discussed and coordinated. Sub-teams should participate in the development of overall high level shared goals and objectives which encourage cross-team interaction and decision making. A third factor is the insistence on the part of the top team leadership that individual and sub-team successes be innertwined. Consistent deliverable, quality assurance, methodological, and review standards must apply to all team members equally.
システム構築チームが、その成果を上手く纏めて行くには、結局、3つの主要な要素が鍵を握る。 その1つは、一貫性に関する規定だ。各フェーズ毎に、成果物の内容と様式に関する指針が作成されなければならない。 2つ目は、チーム全体のコミュニケーションである。共通の要件、類似の懸案、共有データ、再利用可能な機能、 これら全てがオープンに議論され、調整されなければならない。 サブチームも全体の高いレベルの共有目標や目的の作成過程に参加すべきである。 それは、チーム全体の対話や意思決定を容易にする。第3の要素は、「個々のメンバーやサブチームの成否は、 相互に深く関係しあっている」と言う事を、チームの指導者が常に強調しておく事である。 一貫した成果物、品質保証、方法論、検証規定などは、メンバー全員に等しく適用されなければならない。

Team Goals and Individual Objectives
チームの目標と個人の目的

A project team seems to develop a unique "personality" over time. It becomes a reflection of everyone involved, radiating confidence and certainty if spirits are high, seething with doubts and confusion when direction is lacking. How can project dynamics be so different from one team to the next? Leadership certainly plays a vital role, but individual team member attitudes make the difference.
プロジェクトチームは時間と共に、特徴の有る個性を持つ様になる。 それは、関係者全員を反映し、志気が高ければ自信と確信をみなぎらせ、方向性を欠くと疑念や困惑が取り巻くのである。 どうすれば、プロジェクトの行方がチーム毎にそんなに違ってくるのだろうか？ リーダーシップが重要な役割を持つのは間違いないが、チームメンバー個々の姿勢も影響する。

Two fundamental questions illuminate the spirit of the group effort. First, is everyone on the team driving toward a well defined and articulative objective? Second, whose objective is it? An amazing thing can happen on development projects; everyone is busily working away on whatever it is that they individually perceive as his or her's most important tasks. Hopefully, each person's work will mesh with the rest of the group's results. This will probably happen if everyone clearly and precisely understands the ultimate phase objectives. But what if they don't?
2つの基本的な疑問が、グループ精神に光を当てる。 まず、チームの全員がきちんと記述され明確な目的に向かっているだろうか？ 次に、その目的とは誰のものか？開発プロジェクトでは驚く様な事が起こる。： 全員が、自分の考えに従って最も大事な仕事を忙しく進めている。 上手く行けば、その結果は他のグループの成果と組み合わさる事になる。 もし、全員が、そのフェーズの最終目的をはっきりと正確に理解していれば、その通りになる。 しかし、そうでなければ？

This is where human nature begins to step in and things can begin to get interesting. If the attitudes of the team members tend to be goal driven (which is good) but the team leadership is fuzzy about what the objectives really are (which is bad), individual and sometimes scattered goals begin to pop up. Unique and potentially conflicting agendas take shape. Before you know it everyone is busily working away and the atmosphere appears to be productive. But an time of reconciliation lies ahead. At some point the individual results must be combined, and depending on the fit, the attitude of the team will ultimately be affected. The group's mission or purpose at this point becomes very real, because it is at this moment that the team realizes that there may not have really been a common direction in the first place, and that fact is painfully obvious.
ここに人間の性格が絡んで、事態は興味深いものになる。 もし、チームのメンバーは目標指向(好材料)だが、チームのリーダシップが真の目的について曖昧(悪材料)である場合、 個人の、時としてばらばらの目標に向かう事になる。一つ一つ異なり、矛盾をはらむ問題が、姿を表してくる。 あなたが気付く迄は、全員が忙しく働き、その場は一見生産的に見える。だが、考えを改める時が待っている。 ある時点で、個々の成果は、一つに組み合わされなければならない。 その整合性の如何は、チームの姿勢に重要な影響を与える。グループの役目または目的は、ここで、真に現実の物になる。 何故なら、「そもそも共通の方向性など無かった」と、この時初めてチームが認識し、 それは誰の目にも明らかであるからである。

Why even take this risk? Insuring that goals and objectives are clearly spelled out, and the activities and tasks which will be followed to ultimately reach them are uniformly understood, will only give the team a shared sense of purpose. Everyone needs to have a stake in, and a share of, the responsibility for the outcome of each phase. Doing this can have an incredible impact on people's attitudes. Clearly comprehending the relevance of the work and how it will contribute to the final product, is a powerful motivator for creating an air of cooperation and open channels of communication between team members. Individual goals can be visualized as a part of the larger team objectives. The goal driven attitude of the team will truly be reflected in the quality of the results.
では、何故この危険を犯すか？目標と目的が明確に文書化され、 それらの達成に必要な活動や作業が等しく理解させる事が、チームに共有の目的意識を持たせる唯一の手段である。 全員が各フェーズの結果に共同して責任を持つ必要がある。これが、メンバーの姿勢に非常に大きな影響を与える。 作業の必要性と、最終結果にどう貢献出来るかを、しっかりと理解する事は、 協力の気運やメンバー間のオープンなコミュニケーションの手段を生む強力な力になる。 個人目標は、チーム全体の目的の一部として視覚化も可能だろう。 チームの目標指向の姿勢は、実際、結果の品質に反映するのである。

Systems Building Vision
システム構築の構想

A "vision" doesn't do anyone any good if it is only in one person's head. Only when it has been absorbed and adopted by the team does its usefulness begin to emerge. A business or system "visionary" plays an important yet sometimes unenviable role in making this happen. His or her willingness to share insight and understanding of a situation, and the necessary steps he or she envisions to arrive at a desired outcome, tend to be dependant on two factors: the level of confidence he or she has in the ideas, and his or her tolerance for scrutiny and criticism. Regardless of these personal risks, a professional system builder must strive to be a system "visionary". With each passing phase of the project, he or she must constantly develop and communicate his or her vision of both the system functionality and the project approach.
”構想”は、人の頭の中にあるだけでは、誰の役にも立たない。 チーム内に広まり、受け入れられて初めて、その有用性が生まれてくる。 その実現に当たっては、業務やシステムの具現化が、重要だが、しばしば困難な役割を果たす。 状況に対する洞察や理解、望ましい結果に到達する手順について、彼(彼女)が、 どの位積極的に他と意見を共有しようとするかは、次の2つの要素に関係する。 ：自分の意見についての自信と、詮索や批判に対する寛容さである。 その様な個人的なリスクがどうであれ、プロのシステム構築者は、システムの構想を示さなければならない。 プロジェクトのフェーズが進む毎に、彼(彼女)は、システムの機能やプロジェクトの手法について常に自分の構想を描き、 他のメンバーに伝える必要がある。

Putting forward this vision assists in accomplishing two important results. First, it creates a baseline foundation for continuing discussion. In many cases, the original system/approach vision may not survive for long as better ideas are presented and improvement discussions occur. Second, the vision promotes constructive, critical thinking.
この構想を打ち出す事で、2つの重要な結果が得られる。 第一に、継続的な意見交換の基礎となる。多くの場合、より良い案が提出され、修正が話し合われた結果、 当初のシステムや手法の構想が、ずっと原形を保つ事はないだろう。第二に、建設的且つ代替的な発想を促進する。

People tend to provide more input in a "review and improve" mode rather than a "create from scratch" mode. The presentation of a baseline vision stimulates this process. In addition, if the "visionary" can relinquish ownership of the original idea, and subsequently encourage it to become the property of the group, the effectiveness of the process can be even more enhanced. The system builder serves to plant the "starting point" ideas, and the team members and business clients assist with, and take responsibility for, the ultimate direction and composition of the shared vision.
人は、”評価・改善”モードの方が、”一から創り出す”場合より多くの意見を出しやすい。 原点となる考えを示して、この活動を活性化させるのである。 また、その構想が元の発案者のものでなくなれば、結果的にグループの共有物に成り易く、 その事が、更にこの過程を強化していく。システム構築者は、その”出発点”となる構想をプロジェクトに持ち込み、 チームメンバーやエンドユーザーは、最終的な方向性や共有の構想の生成を支援し、同時に責任を持つのである。

Project Team Confidence
プロジェクトチームの信頼感

Another important team attitude is confidence. The development of a complex system presents tremendous challenges to a project team. Sometimes it can even feel like an act of faith. An enormous amount of detail is collected, analyzed, organized, and assimilated into a functional "whole". On very large efforts, only a few key individuals may possess the total "big picture", and this may be at varying levels of completeness. This ambiguity can from time to time test the confidence of the project team members. Given these uncertainties, how does a team feel assured and confident of success throughout the process, and have this reflected in the individual team member attitudes?
チームの姿勢でもうひとつ重要な点が、信頼感である。 複雑なシステムの開発は、とてつもなく多くの難問をプロジェクトチームに投げかける。 時として、そう信じられている節がある。 非常に多くの詳細事項が収集・分析・整理され、一つの機能体として纏められる。 多くの努力にも関わらず、全体のプロジェクト像を把握しているのは、ほんの一握りの主要メンバーだけだし、 その内容も様々である。この曖昧さが、しばしば、チームメンバーの信頼感を揺るがす事になる。 この様な不透明な状況下で、プロジェクトの期間中、チームは、どの様にして、迷う事なく成功への自信を保つのか？ また、それを、どうやってメンバー個々の姿勢に反映させるのか？

Clearly, the realization on the part of the team, that a system design is formed as a gradually evolving solution, from a process which tends to be iterative in nature, helps everyone to be patient with the slowly disappearing level of ambiguity. The more team members who participate on the project who have been through the complete system building life cycle, the more likely the overall team awareness will be that everything will come together at each major milestone. This is an important confidence builder for the less experienced members of the team. The higher the level of confidence possessed by the team, the more secure the business clients feel, and the more likely the team will actually "see" themselves succeeding, even in the face of the unknown.
明らかに、チームとして、システム設計が、「徐々に進化していく解法」として、 現実の反復過程の中から生まれる事を理解すると、全員が、不透明さが徐々に無くなって行くのを辛抱強く待つ様になる。 チーム・メンバーのより多くが、システム構築ライフサイクルの最初から最後までを経験している程、より容易に、 チーム全体が「主要なマイルストーン毎に、全てが組み合わさって一つにまとまる」と言う意識になり易い。 これは、経験の浅いメンバーが自信を持つ大きな助けとなる。 チームの自信が大きい程、エンドユーザーの安心感も増し、不測の状況に遭遇したとしても、実際にチームが成功する確率が高くなる。

Copyright © 1999, Russ Finney, All Rights Reserved