John Erskine once observed that "in the simplest terms, a leader is one who knows where he or she wants to go, then gets up and goes". Joel Barker defines a leader as "a person you would follow to a place you wouldn't go by yourself". A good definition for a development team leader might be:
かつてJohn Erskineは、この様に述べている。「端的に言うと、リーダとは自分が行きたい場所を知っていて、そこに行く人物である。」Joel Barkerは、リーダをこう定義している。「あなたが自分では行かない様な所へ導いてくれる人物である。」 開発チームのリーダの定義は、次の様なものだろう。
The person who understands the ultimate project objectives, each step of the way, and who guides the rest of the team down this path through clear vision setting and effective communication.
全ての局面でプロジェクトの究極の目的を理解し、明確な構想を描き、効果的なコミュニケーションを通して、チーム全体を目標に向かって導く人物。
An interesting observation regarding development projects is that occasionally, the person who fits this bill is not always the person who is formally leading the project. Even when this situation occurs, this individual can still wield great influence and ultimately make significant contributions to the teams success. Obviously, the better situation is when the formal Team Leader is also a possessor of effective leadership skills, vision, and experience.
開発プロジェクトについて興味深い事は、往々にして、上記の描写にぴったりの人物が必ずしも公式のリーダではない点である。この場合においてさえ、この人物は、大きな影響力を持ち、チームの成功に大きな貢献を果たす事が出来る。公式のチームリーダが、有能なリーダーとしての資質、構想、経験を兼ね備えている事が望まれる事は言うまでもない。
Some of the major challenges facing the systems building Team Leader are:
システム構築チームリーダが直面する問題とは：
Creating the System Vision
システム構想の作成
One of the Team Leader's more vital responsibilities, and one which never fails to present an incredible challenge, is the creation of an overall "vision", within the minds of the project team members and the business clients, of both the proposed system, as well as the necessary steps to insure its completion. These images should convey the functional depth and breadth of the system, the direction and proposed steps of the project, the overall expectations and responsibilities of each team member, and the creative "boundaries" and limitations of the development effort. This system "vision" represents clear, common, shared objectives upon which all activities will be grounded throughout each successive project development stage.
チームリーダの責任事項の中でも取り分け重要で、決して楽に片付けられないのが、提案されるシステムと完成までの必要な作業項目双方について全体的な“構想”を描き、プロジェクトチームメンバと顧客に植え付ける事である。このイメージは、システム機能の適用範囲（対象や処理の範囲）、プロジェクトの方向や作業項目、チームメンバへの全体的な期待と責任、開発作業の"分担"と限界などを伝えるものでなければならない。このシステム“構想”は、連続したプロジェクトの各開発段階で全ての活動の拠り所となる、明快、共通、共有の目的を提示している。
Determining Task Assignments
作業項目の決定
Another difficult responsibility is the dividing up of the work. This is the part which seems to give every project manager premature gray hairs - if it hasn't already happened on a prior development effort! It is important to assign tasks, responsibilities, and deliverables early for each upcoming phase. Make certain each team member has both a primary and a secondary list of assignments. This insures that when decisions or issue resolutions are pending, secondary tasks can be focused on instead of the individual having to shift into an idle period.
作業を項目毎に分割する事も、難しい仕事だ。これは、全プロジェクトマネジャが若白髪になりそうな（もし、前のプロジェクトでそうなっていなければだが！）工程である。どのフェーズも着手前に、その作業項目、責任、成果物を決定して（割り当てて）おく事は、重要である。メンバー全員に、主担当・副担当2つのリストを作成し渡しておく。これで、決定や懸案事項が未決の場合でも、副担当の作業を遂行出来、手待ち状態を作らなくて済む。
AConsideration must also be given to the experience level, the technical ability, the management skill, and the availability of each team member. These all have an important bearing on the nature of the assigned tasks. Care must be taken to avoid putting anyone into a situation where he or she feels "in over their head" - yet, at the same time, each team member must feel a sense of challenge, and believe that his or her work is relevant and important.
メンバー個々の経験、技術力、管理能力や利用可能性も考慮しなければならない。これら全て、割り当てられた作業の結果に大きく影響する。誰もが、”頭越しに物事が決められる”と感じる様な状況は避けなければならない、また、同時に、全員がチャレンジャー精神を持ち、自分の仕事が必要かつ重要なものだと信じていなければならない。
An even higher consideration is the willingness, as well as the ability, of each individual to accept and carry out the assigned responsibility. For the team leader, this represents an act of trust, for the team member, it represents challenge and opportunity. These interests can sometimes seem to compete with one and other, but the overall objective is to optimize each person's individual talents and to avoid useless busy work or idle time. Making appropriate assignments which are important, challenging, and consuming, along with the additional responsibility for reviewing and reassigning tasks when necessary, all make the team leader's job one which which requires a keen human insight as well as the willingness to let people grow.
更に高次の考慮点は、個人の能力と同時に、割り当てられた責任を受け入れ、遂行しようとする意志についてである。チームリーダには（メンバーに対する）信頼が求められ、メンバーにとっては挑戦の機会である。双方の関心は、相反している様でもあるが、最終的な目的は、個人の能力を最大限に引き出し、無駄な作業や時間の浪費を無くす事である。適切な仕事の配分を作るのは、重要かつ困難、また時間の掛かる作業である。加えて、必要に応じて、作業項目を再検討・再配分しなければならない。この全てをこなす為、チームリーダには、人々を育てる姿勢と共に、鋭い人間的な洞察が求められる。
Making Decisions
意志決定
A team leader is a decision maker. This fact for some may seem to be a blessing, but for others it may feel like a curse. With decision making ability comes both control (which most leaders like) and accountability (which most leaders fear). In some cases, a decision is strikingly apparent to everyone, and the team leader serves only to confirm the choice and to set the dependent actions into motion. In other cases, the decision is between two or more choices with equal merit. Most decisions are somewhere in between. As a team leader, being a perfect decision maker is simply not possible - but being an effective decision maker is! The following rules of thumb can help to increase decision making effectiveness:
チームリーダは意思決定者である。ある者にとっては恩典となるが、他方、別の者には災いに思えるだろう。意志決定権には、（殆どのリーダが好む）統制権と(殆どのリーダが恐れる)説明責任が付いてくる。場合によっては、結論は全員に明らかで、リーダはそれを承認し、必要な作業を実施に移すだけである。一方、同じ様な効果を持つ二つ以上の選択肢の中から決めなければならない事もある。殆どのケースは、これら両極端の間に位置している。チームリーダが完璧な意志決定をする事は不可能である−しかし、有能な決定者にはなれる！以下の指針は、より的確な判断を下すのに役立つだろう。
Thomas Jefferson once advised back in 1792, when making critical decisions that "delay is preferable to error". Many times an iterative, focusing decision approach can result in the highest quality outcome and the broadest consensus and support.
Thomas Jeffersonは、1792年に「重要な決定の場合、”間違った決定をするよりは、遅らせた方がまし。”」と忠告している。多くの場合、焦点を絞った判断を積み重ねて行く事が、最高の結果を生み、幅広い合意と支持を得る事になる。
Monitoring Progress
進捗管理
The way in which team leaders monitor progress tends to be a matter a management style. Some may have quick team meetings, others may require written reports, and others may put into place formal time collection procedures. In all cases, a few fundamental elements should be present. First, clearly identifiable units of work must be assigned to each team member. These may range anywhere from a broad mandate to a detailed programming task. Second, a milestone date for each defined deliverable should be agreed upon. These both should present reasonable yet challenging objectives. Third, a formal accounting of these objectives and goals must periodically be required. This aids in keeping a sense of urgency in place, in providing a basis for later performance evaluations, and in keeping a sense of accomplishment alive and well through each successive phase.
リーダの進捗管理の方法はそれぞれの管理手法に依るところが大きい。短時間のチーム会議を開いたり、報告書の提出を求めたり、あるいは時間集計の手続きを決めたりする事もある。何れにせよ、2-3の基本的な要素は押さえておかなければならない。まず、はっきりと区別された作業単位が各人に割り当てられていなければならない。これらは、包括的な指示から詳細なプログラミング作業まで多岐に渡る。第２に、決められた成果物全てのマイルストーンの日付について合意しておく事。これらが、容易ではないものの納得した目標となる。第３に、これら目的、目標に対する成果の正式な報告が、定期的に必要である。これは、緊張感を保ったり、後の業績評価の基礎となったり、連続したフェーズを通して達成感を持ち続させるのに役立つ。
Opening Communication Channels
連絡経路の確立
This sounds so easy, yet many team leaders tend to gravitate toward one of two extremes. One is the "keep your fingers crossed" approach. This is where a team leader hopes that the clients, analysts, and programmers are all busily communicating away with each other about every aspect of the system without him or her having to do anything. The other is the "my way or the highway" approach. In this situation, the team leader controls all of the communication opportunities and only lets others into the loop on a "need to know" basis. Both extremes eventually lead to frustration or resentment.
これは簡単そうに聞こえる。そして、多くのチームリーダは、２つの極端な例のどちらかに陥ってしまう傾向がある。一つは、「神頼み」型。チームリーダは、自分が何もしなくても、「顧客、アナリスト、プログラマ達は、システムに関する全ての事柄についてお互いに連絡しあっている」と希望しているのである。もう一方は、「自己流また高速道路」型。この場合、リーダが連絡機会・手段の全てを統制し、他の者には「情報が欲しい」場合にだけ、連絡の輪に入る事を許す。どちらの場合も、最終的には、不満や反発を招く。
The team leader must achieve proper and balanced communication between everyone involved. This means that he or she must organize, orchestrate, prod, and maneuver both business clients and system builders into meetings, sessions, and informal encounters:
チームリーダは、全員に対して、適切かつバランスの取れた連絡手段を提供しなければならない。これは、リーダが、顧客やシステム構築者達を、組織し、調整し、活性化し、会議や説明会または非公式な会合に動員する事を意味している。(目的は)：
This applies across the board - the team leader is ultimately responsible for ensuring steady progress and for making things happen. At the same time the he or she should not stifle informal communication. Most system builders thrive on learning, sharing, and comparing. A certain amount of this is to be expected and is productive as long as milestones are being met.
これを、プロジェクト全体を対象に行なうのだ。チームリーダは、着実な進捗と計画の実現について最終責任を負っている。同時に、彼(彼女)は、普段の（非公式の）情報交換を阻害してはならない。ほとんどのシステム構築者は、学習し、知識を共有し、互いに比較しあって成長する。これは、ある程度期待されている事で、マイルストーンがきちんと守られている限りは、有益である。
The last challenge facing the team leader is his or her own communication style. As a manager, the team leader must discipline himself or herself to react to both good news and bad news with moderation and maturity. A balanced reaction to both increases the odds of actually hearing both, and this awareness keeps project surprises to a minimum.
チームリーダが直面する最後の問題は、自身のコミュニケーションのスタイルだ。管理者として、リーダは、節度と円熟さ持って、良い知らせにも悪い知らせにも対応出来る様、節度を持っておかなければならない。（どんな話にも）バランスの取れた反応をすれば、どんな話であってもちゃんと耳に入る確率が高くなる。それに、これが判っていれば、不測の事態を最小限に押さえる事が出来る。
Deflecting Unnecessary Distractions
余計なプロジェクト以外の事項の回避
These sometimes seem to come from every direction! Clients may ask for a little help in an unrelated area, management might put the team through a "fire drill" to rejustify the project, or a new software tool may arrive which seems to fascinate everyone. The team leader must strive to keep these distractions to a minimum. Keeping the team focused on the primary objectives while at the same time running interference with the client or the team can keep a team leader hopping! Sometimes interruptions can be handled through subtle deadline reminders, other times it may take creative thinking to find alternate means of handling the unplanned requests. In the worst case, no choice is given, and the team must react. When this happens, the team leader must make sure that the distraction is taken care of as quickly and effectively as possible - then get back to the primary mission: building the system.
これは、どの方向からでも起こり得る！エンドユーザは、プロジェクトと関係ない事でも助けを求めてくる。経営陣は、プロジェクトの正当性を確認する為、”模擬的に緊急事態を起こす”かもしれない。または、皆を熱中させる様な新しいソフトウェアツールが導入されるかもしれない。チームリーダはこれらの事象を最小限に押さえる努力をしなければならない。チームを常に本来の目的に向かわせ、同時に、エンドユーザとプロジェクトチームの間の連絡を機能させる為、チームリーダは飛び回り続ける事になる！ それとなく納期を確認する事で邪魔物を処理出来る事もある。また、計画外の要求に対する代替案を見つけるのに、新たな発想を必要とする場合もあるかもしれない。また、チームが、否応なく対応しなければならない最悪の場合もある。この時、チームリーダは、それを出来るだけ早く且つ効果的に処理し、本来の任務であるシステム構築に戻る様、策を講じなければならない。
Enforcing Quality Standards
品質基準の実施
This is easy! Just dictate hard and fast, nitpicking rules, then bop anyone on the head with a sharp stick who doesn't follow them to the letter. If that doesn't work, just follow it up with a cruel public tongue lashing!
これは簡単だ。ただ強力かつ厳密に指示し、規則の詳細に拘り、正確に守らなければ頭を硬い棒で殴るのだ。それでも、上手く行かなければ、皆の前で、きつく叱ると良い。
Sometimes team leaders seem to get so engrossed into the minute details of standards enforcement, they begin to bare more resemblance to the programming police rather than mere human system builders. This is unfortunate, quality should be inspired rather than dictated. Quality standards should be a reflection of the desire for excellence on the part of the team. This is tough assignment for the team leader since it requires discipline and temperament.
しばしば、リーダが規則遵守の非常に細かい処にまで熱を上げ、人間味のあるシステム構築者と言うよりは、プログラムで動く警察官に思えてくる。これは、残念な事である。品質管理は、命令されるものではなく自発的なものでなければならない。品質基準は、チームにとって、より大きな成果を上げようとする熱意の表われであるべきだ。チームリーダには、自制と忍耐を求められ大変な作業である。
The spirit of the review process should be one of both confirmation of quality as well as identification of improvement opportunities. Make no mistake about it, work product reviews are an essential ingredient in making high quality a reality; they provide needed recognition for sincere efforts toward the creation of high quality products. In addition, team leaders should dedicate themselves to the "review it once" rule. This means that all observations, input, and changes are brought out in the first review. A second review should be called for in only very rare cases. This puts the burden on the team leader to be equally complete and penetrating when reviewing each team member's work.
レビューに対する姿勢としては、それを品質の確認か、品質改善の機会と捕らえる。間違ってはいけない。作業成果のレビューは、高品質を実現する重要な要素である。それは、高品質の製品を作るのに要した努力が認められる場でもある。また、チームリーダは、”レビューは一度だけ”ルールを守るべきだ。これは、最初のレビューに、全ての意見、資料、変更(の記録)が揃っていなければならないと言う事である。２度目のレビューは、めったに開かれない。チームリーダは、どのメンバーの成果をレビューする時も、（等しく）全体を把握しかつ内容に精通している必要がある。
Watching Scope Boundaries
対象範囲の堅持
This is the part which is kind of like being a sheep herder. No matter how hard a team leader tries to keep the delivered functionality in scope, someone always seems to come up with a clever new feature, or an undiscovered requirement, or a "twist" on the original vision which will require more time. Sometimes these may seem to be just a little time here or a little time there, but it all eventually adds up to a significant amount of time, and a missed deadline.
これは、羊飼いに似た役割である。チームリーダが、どんなに頑張って提供する機能を計画の範囲内に納めようしても、常に、別の便利な機能、見逃していた要件、元の構想を“一捻りしたもの“を誰かが思い付つき、それらは追加の時間を必要とするのである。一つ一つは、大した時間ではない様に見えるが、合計すると非常に大きな量になり、往々にして、納期を逸してしまう事になる。
So how can this be prevented? The answer is it can't.
では、これをどうやって防ぐか？ 答えは、「防げない」である。
Changes to scope are an inevitable part of system building; the key is to keep the changes in control. Each proposed change must be evaluated as to both its importance and its necessity. If the change doesn't pass the "gotta have it" test, direct the effort back within the established project boundaries. Otherwise reasonable change control procedures should be utilized to recognize and plan for the effect of the work increase.
対象範囲の変更は、システム構築の避けがたい部分である。ポイントは、それらを掌握しておく事にある。変更提案は、その重要度と必要性の観点から評価されなければならない。「どうしても必要だ。」と言う事にならない限り、既存の作業を継続すべきだ。そうでない場合、変更管理手続に従い、作業の増加を認め、計画を策定するようにしなければならない。
。
An alert project manager should be able to spot true improvement opportunities, and then either build the case for a scope increase (if the benefits merit the effort), or identify sensible design trade-offs for the more beneficial features.
注意深いプロジェクトマネジャは、改善の機会を見つける事が出来るはずだ。そこで、（効用が負荷を上回れば、）システムの対象範囲を広げたり、より有効な機能との設計上のトレードオフを見つけたりするだろう。
Supporting a Career Development Atmosphere
キャリア形成の雰囲気作り
Sherman Hamilton, while writing on teamwork, pointed out that "a leader inspires his or her staff to believe in themselves and their ability to succeed long before they could recognize their own potential". This is a frequently overlooked responsibility of the development team leader. Meetings, issues, and deadlines can sometimes lower the priority for ensuring that a learning environment exists for the less experienced project team members. This is unfortunate, since the investment in making sure that every team member is ascending his or her personal learning curve can pay off in many subtle, unexpected ways with surprising impact.
Sherman Hamiltonは、チームワークについて書いている中で、「リーダは、部下達が自分達の潜在能力に気付くずっと前に、彼らに自分自身と能力に自信を持たせる事が出来る。」と指摘した。これは、開発チームのリーダの職責としてよく見られる事である。会合、懸案事項、納期などのせいで、しばしば、プロジェクトチーム内の経験の浅いメンバーが、知識を吸収する環境の存在を軽視しがちになる。これは、残念な事である。何故なら、メンバー全員が自己の知識や経験を増す事への投資は、多くは目に見えない形で、あるいは予期しない形で、驚く程の効用をもたらすものだからである。
The inexperienced programmers gain by learning efficient and sensible approaches to creating high quality software from the more senior team members. This not only contributes to their personal confidence, it also reduces the potential for easily avoided program re-work and testing problems. The more experienced analysts and programmers gain by being given greater levels of responsibility and challenge. This provides an opportunity for them to stretch and grow to the point where they are ready to be entrusted with increasingly significant leadership roles.
経験の浅いプログラマは、先輩のメンバから高品質のソフトウェアを作る為の効率的かつ賢明な手法を学び取る。この事は、彼らの自信につながるだけでなく、簡単に防げるプログラムのやり直しやテスト時のトラブルの芽を未然に摘み取ってくれる。経験の深いアナリストやプログラマは、より大きな責任と課題を与えられる事で、キャリアを積む。こうして、彼らは、リーダとして更に大きな役割を任されても十分な域まで、幅広く成長する機会を得る。
As long as individual team members are not put into situations where they are "in over their heads", a sensibly managed learning environment can not only produce systems, people, and results of exceptional quality, but it can also invigorate overall team morale by reassuring everyone that they are being given the opportunity to advance through performance.
「頭越し」の状況にない限り、上手く管理されている学習環境は、システムを構築し、人を育て、非常に高い品質の成果をもたらすだけでなく、実績に依って昇進の機会が得られると確信させる事でチーム全体の志気を高める事が出来る。
Managing Issues and Problems
懸案事項や問題の処理
Some people make a career out of doing nothing but this, and they even enjoy it! What these team leaders have realized is that being an effective problem solver requires both discipline and organization. But this isn't enough, the most important rule for managing issues is: when you hear it, write it down. This ensures that the issues and the related details are really captured, and can be subsequently reviewed, prioritized, and organized.
何もしないで、こればかりやって来ている人もいる。そして、楽しんでさえいる！この様なチームリーダは、「優秀な問題解決者になるには、訓練と組織が必要」と理解している。しかし、それでは不十分だ。問題処理の秘訣は、「聞いたものは書き留める」事である。これで、問題と関連詳細事項が確実に把握され、後に検討され、優先度が決まり、段取りが決まる。
Warning: If human memory is all that is used to keep track of the issues for a complex project, eventually selective system builder thinking will begin to creep in, and before you know it - zap! Those nagging, unwanted, negative thoughts will be forgotten within a matter of seconds, and they will silently wait to be remembered at the least opportune and inconvenient moment (like during prototyping or acceptance testing).
警告：大規模なプロジェクトで懸案事項を全て人間の記憶に頼って管理すると、知らない間に、システム構築者は、最後には自分の好みに基づいて考える様になる。煩わしい、嫌な、否定的な考えは、瞬時に忘れられてしまう。そして、最悪の場面、１番拙いタイミング（プロトタイピングや検収時）で思い出される迄、静かに待つ事になる。
Another important point is made by Robert Townsend when he states that "an important task of a manager is to reduce his or her people's excuses for failure". These excuses sooner or later appear to the team leader as issues or problems. As long as they remain unresolved, safe, valid excuses for delay, unaccountability, and failure will exist within the minds of the affected team members. Not only should the team leader swiftly and effectively act to resolve each new issue or problem, he or she must also be on constant guard to make sure none slip by unnoticed.
Robert Townsendは、「マネジャの重要な仕事は、失敗に対する部下の言い訳を減らす事にある。」ともう一つの大事な点を指摘している。この種の言い訳は、遅かれ早かれ、懸案事項か問題点としてチームリーダに伝わる。それが解決されない限り、遅れ、無責任、失敗に対する言い訳が、安全で有効なものして、そのまま影響を受けたチームのメンバーの心に留まる。チームリーダは、発生した懸案事項や問題点を、迅速かつ効果的に処理するだけでは不十分で、気付かれないまま放置される事が一つもない様に監視しておかなければならない。
In many cases, the issues are just too numerous for one person to possibly be able to work through without help. When this situation occurs, the team leader must assign the responsibility for each specific issue resolution to either a business client or to another person on the project. By doing this, the team leader effectively delegates all of the tasks required to arrive at acceptable answer to others. What he or she is not giving up, is the responsibility for making sure that all outstanding issues ultimately do get resolved.
大抵、懸案事項の数が多すぎて、一人の人間だけで処理する事は出来ない。そこで、リーダは、それぞれ具体的な事項の解決をエンドユーザやプロジェクト内の他のメンバに依頼しなければならない。こうして、リーダは、妥当な結果が求められている作業の全てを、それらの人々に効果的に委任する。リーダが手放せないのは、全ての懸案事項を最終的に解決させる責任である。
Counteracting Project "Threats"
プロジェクトの「脅威」対策
This last category can be one of the most difficult. It deals directly with the impact of "Murphy's Law" (if it can go wrong it will!) on the project. Arnold Glasow once observed that "one of the tests of leadership is the ability to recognize a problem before it becomes an emergency". Some examples of typical project threats are:
最後の分類は、最も困難な部類に入る。プロジェクトにおける"Murphy's Law"（失敗の可能性があれば、失敗する）の帰結を扱っている。Arnold Glasowは、かつて、「リーダとしての要件の一つは、問題をそれが大きくなる前に見つけられるかどうかという事だ。」と述べた。典型的なプロジェクトの脅威を例示する。
The astute leader remains on the alert for these potential treats, and as soon as they are recognized, he or she then deals with them in their early stages .
巧妙なリーダは、上記の脅威に注意している。そして、見つけると直ぐ初期の段階で対策を打つ。
Copyright © 1999, Russ Finney, All Rights Reserved
The itmWEB Site・ Copyright © 2006, itmWEB Media Corporation,
All Rights Reserved - webadmin@itmweb.com