#freeze
#contents
* プロジェクトマネジメントとは [#rfd7f244]
-次々と起こる予期せぬ難問に取り組みながら、優先順位を付け、対処していくという挑戦
-理想は、チームが航海に出る前に荒れた海を穏やかな海に変えること
* 4章 優れたビジョンを記述する [#ke1f68b7]
全てのドキュメントは、大局的な観点に立ったビジョンのドキュメントから派生する。よってPMは他のどのような計画関係の成果物よりもビジョンのドキュメントを重視すべき。
** ビジョンのドキュメントに必要な5つの品質 [#j498af98]
-シンプル
-意図重視
-統合
-閃き
-覚えやすい
優れたプロジェクトの目標は、クリアでシンプルなものであり、作業が完了したときにどうなるかが解説されている。
ビジョンのドキュメントやプロジェクトの目標の中でなされた主張は、ドキュメント中のどこかで裏付け、または明確化しておくべき。
ビジョンはビジュアルになっているべきである。
チームメンバーがビジョンを日頃から目にするようにしておくために、核となる目標をポスターにして、廊下の目に付くところに貼っておく。
プロジェクトにおける日々の意思決定では、ビジョンの有効性を問いかけ、そのビジョンを活きたものにし続けるよう努力する。
* 7章 優れた仕様書の記述 [#y0d7c368]
仕様書は、チームに要求されるほとんどの成果物と同様、現行のプロジェクト、仕様書の作成者、仕様書の使用者が持つニーズに適合しているべき。
仕様書はプロジェクトにおいて以下の３つの目標を達成するべき。
-正しいものの構築を保障する
-プロジェクトの計画フェーズを締めくくるマイルストーンを提供する
-プロジェクトの過程で踏み込んだレビューや各個人からのフィードバックを可能にする
** 仕様書の使用によってできること [#ja812757]
-構築するものの機能を効果的に描写することができる
-設計者に対して具体的な記述を要求することで、彼らの意思決定を明確化することができる
-実装作業を開始する前に、詳細計画についてのレビュー、疑問の洗い出し、議論を行うことができる
-１人が持っていた情報を複数のメンバーに伝えることができる
-チーム内で共有できる、具体的な計画の参照標準とすることができる
-チームの目標となるスケジュールのマイルストーンを提供することができる
-書き手が何らかの理由によりプロジェクトから離れた場合の保険とすることができる
-健全な議論を加速させ、その品質を向上させるとともに、そう言った議論の頻度を増やすことができる
-リーダーによるフィードバックと、品質基準の設定機会が与えられる
-チーム（と仕様書作成者）に対し、心の平穏と自信をもたらすことができる
** 仕様書の使用によってできないこと、やろうとしてはいけないこと [#xb714484]
-メンバー間の議論を全てなくそうとすること
-機能の重要性を証明しようとすること
-メンバーに哲学的視点を持たせようとすること
-仕様書作成者の持っているVisioやUMLのスキルを見せびらかそうとすること
** 仕様書に記述すること [#cbd820fe]
◆要求仕様~
-作業によって達成されるべき全ての要求と責任の概要
-最終結果がどうなるかということを、実現方法について言及することなく記述しただけのもの
-プロジェクトを成功させる上での必要条件を挙げたもの
◆機能仕様~
-顧客の視点から見た特定のシナリオやシナリオ群における振る舞いや機能を記述したもの
-ソフトウェアの機能をUI（あれば）を通じて解説し、なるべく技術的な詳細に踏み込まないようにしつつ、ものごとの動作方法を解説
◆技術仕様~
-機能仕様を満足するために必要となるエンジニアリングアプローチを解説したもの
-詳細度は、機能仕様に必要な作業項目に対して技術的な裏付けを提供できるだけのレベルで十分
◆作業項目一覧~
-機能仕様を満足する上で必要となるタスクのリスト
-重要度の違いに基づいて詳細レベルにまで細分化した項目を、日単位の見積もりと共に記述
◆テスト基準 ... 各テストケースの優先順位 ~
◆マイルストーン達成基準 ... 各マイルストーンにおける品質目標 ~
**仕様書記述の注意点 [#c45eecd5]
-設計作業や計画作業と、仕様書の記述作業は切り離す
-仕様書の記述を行う時は、探究心と創造心を一旦脇に置いておき、表現と説明に集中するようにする
-他の仕様書から優れた説明を借用する
-専門用語や曖昧な言葉を避ける
-仕様書を記述する際に、読み手のことを考える
-Visioやフローチャートとは恋に落ちない
-記述しているのが仕様書なのかリファレンスなのか意識しながら書く
-詳細に入る前に、擬似コードを用いたり、日本語を使用して、複雑な処理を大局的な観点から説明する
-古い仕様書を保管しておく ... 参考資料になるから
-仕様書の著者は１人に限定すべき。メンバー全員はコメントを付けたり、内容を追加するといった形で貢献するべきだが、必ず１人の責任者が内容をチェックし、形式を整え、矛盾のないようにまとめ上げなければならない
**レビュー [#yae179cf]
◆レビューの目的~
以下の２つの疑問に答えること。
-この仕様書には、開発期間を通じて私たちの指針になるくらいの詳細が記述されているか？
-成果物はプロジェクトの要求と目標を満足させることができるか？
◆レビューの方法~
-レビューの参加者には、レビュー前に仕様書を読むことを要求する
-レビューの運営進行はPMが行うべき
-運営進行は疑問に答えて行くという簡単なもの
-レビューで出て来た疑問は、疑問を持ったメンバーが満足するまで議論して答えを出すか、仕様書中の懸案事項の一覧に新規項目として追加するかのいずれか
-疑問が尽きたら懸案事項の一覧をレビューし、再度レビューで議論する必要性を判断する。再度議論するものがなければ、仕様書はレビュー済みと見なしてもよい
-レビューが完了したら、PMはレビューで洗い出された新たな疑問や懸案事項に対処する期限を設定する
-レビューが終わった後速やかに、懸案事項の簡潔なサマリー、（必要であれば）次のレビュー日程、懸案事項の解決期限をメールで参加者全員に伝達
**レビューの質問一覧 [#k9e505bc]
-プログラマの作業項目一覧と仕様書はマッチしているか？
-仕様書中の主要なコンポーネントはそれぞれ、各作業項目とどのように関連しているか？
-見過ごしている作業項目があるとすれば、設計中どの辺りにありそうか？
-この設計が破綻するのはどういった場合か？
-最も弱いコンポーネントやインタフェースは何か？
-なぜ、それらを改善することができないのか？
-この設計における強固な側面とは何か？逆に最も弱い側面とはなにか？
-我々が最も自信を持っているものと、自信のないものはそれぞれ何か？
-我々の力と自信は、最も重要なコンポーネントに注力されているか？
-適切な品質レベルが想定されているか？
-それはプロジェクトのビジョンで要求されている信頼性、パフォーマンス、使用可能性を満足できるか？
-テストの見積もりは現実的か？
-なぜ、これよりシンプルな設計が採用できないのか？
-本当にこういった複雑さや機能が必要とされるのか？
-こういった簡潔化を行わないということに関して、具体的な理由や、しっかりした論拠があるのか？
-最も変更される可能性が高いのは、設計中のどの要素か？また、その理由は？
-このプロジェクトにおけるテスティング、文書化、マーケティング、その他の役割を持った担当者には、ベストの作業を行うために必要な情報が全て与えられているか？
-PM、プログラマ、テスターが抱く、この仕様書に対する主要な懸念は何か？また、機能に対する主要な懸念は何か？
-このプロジェクトで構築している他の機能と、コードの共有やコードの融通を図る機会はあるか？
-この設計におけるセキュリティ上のリスクとは何か？そのリスクを除去しないのはなぜか？
-そのリスクは潜在的改善策と共に仕様書中に記載されているか？
-特定ユーザが、このUI設計を用いることで必要な作業を行えるということを示す確かな根拠があるか？
-UIに関して、アクセス可能性とローカライゼーション要求を満足できているか？
* 8章 優れた意思決定の行い方 [#yda7b284]
**意思決定の重要度を評価する [#c2606701]
-この意思決定の中心にはどういった問題があるのか？
-この意思決定がプロジェクトに影響を及ぼす期間はどのくらい続くことになるのか？また影響の大きさはどの程度になるのか？
-この意思決定が間違っていた場合、どれだけの影響が出るのか？またどれだけのコストがかかるのか？その結果によって他のどういった意思決定に影響が波及するのか？
-この意思決定にどれだけの時間をかけることができるのか？
-この種の意思決定を以前に行ったことがあるか？
-これは本当に自分が行うべき意思決定なのか？
-誰の承認が必要なのか？意思決定を行う前に誰のフィードバックが必要なのか？
**選択肢の比較評価の注意点 [#k22dd5e0]
選択肢の比較評価を行うには、まず選択肢の長所と短所の一覧表を作成してから評価する。以下、その注意点を列挙する。
-「何もしない」という選択肢を必ず含めておく
-厳しい質問を投げかける
-反対意見に耳を傾ける
-選択肢の組み合わせを考慮する
-関連する観点を全て含める
-紙やホワイトボードに書き始める
-安定するまで洗練する
**意思決定のレビュー [#zb988303]
過去の意思決定をレビューし、教訓を求めたり、よりよい戦術を見出す機会を探求することによって、意思決定のスキルを向上することができる。以下にレビューの質問集を列挙する。
-その意思決定は核となる問題を解決したか？
-その意思決定をより迅速化できるような、より優れたロジックや情報はあったか？
-ビジョンのドキュメント、仕様書、要求定義書はその意思決定に役立ったか？
-この意思決定はプロジェクトの進捗に役立ったか？
-鍵となる人々をプロセスに参画させ、意思決定の支援をさせることができたか？
-この意思決定が他の問題を引き起こす／防止するということはあったのか？
-振り返ってみた場合、この意思決定の最中に気にしていたことは正しいことだったのか？
-正しい決定を行うだけの十分な権限があったか？
-この意思決定によって学んだことをプロジェクトの他の部分にどのように適用できるのか？
* 11章 問題発生時に行うこと [#h82b5ab3]
**問題への対応手順 [#i33fd121]
1. 気を落ち着かせる
2. 問題を評価する
-人々に対して多くの疑問を投げかけることによって、反射的な行動を戒め、まず考えるように仕向ける
-前提となっていることを１つずつ消し込む
-自分自身が問題とその本当の影響をしっかりと理解出来ているかどうか確認する
-問題の優先順位付け（緊急（今すぐ！）／大問題（今日中）／気がかり（今週や来週）／問題なし（対応不要））を行う
3. 再度、気を落ち着かせる
-誰が心配し、動転しているかに注意を払い、その人の気を落ち着かせるために手を差し伸べる
-あなたがリーダーであれば、あなた自身が気を落ち着かせ、ゆったりとすることで、全員にその落ち着きが伝搬します
-あなたがリーダーであれば、状況に対する責任を取ることで、誰のミスだったかに関係なく、チームはその問題からいち早く復旧できるようになります
4. 適切な人材を集めて会議する
-問題について、最も責任があり、知識があり、適切に対処できる人材を洗い出し、その人たちを会議室に招集する
-打ち合わせの人数はできるだけ少なく抑える。多くなる場合は最初に少人数で議論を開始し、弾みをつけた後で他の参加者を招き入れるのが良い
5. 選択肢を探求する
-選択肢を考える
-調査が必要であれば、適切な人に振ってしまう
-いつまでに答えが必要かをできるだけ明確にしておく
6. 最もシンプルな計画を作成する~
(1) 選択肢を評価し、最も優れたものを選び出し、シンプルな計画を立案~
(2) 計画の承認をお願いすることになる人たちと、計画の実行前に情報を通知しておく必要のある人たちを洗い出す~
(3) 計画の承認をお願いすることになる人たちのところに行き、計画を提示し、彼らからのフィードバックを取込み、サポートを得る~
(4) (3)で修正した計画を、計画の実行前に情報を通知しておく必要のある人たちに伝える
7. 実行する~
(1) 計画の実行~
(2) 定期的なチェックポイント（時間毎、日次、週次）を設け、計画通りに結果が生み出されていることを確認すると共に、この問題に対して他にできることがあるかどうかを改めて考える~
(3) 新たな問題が見つかった場合は 1. に戻る~
8. 結果を振り返る
**よくある問題の対処法 [#b86e6659]
◆見過ごしがある、または何らかの気付きがある~
-要求を変更
-実装スケジュールの見直し
-必要に応じて他の設計選択肢を探求
◆何か馬鹿げたことを強要される~
-あなたの意見を優先順位付けし、具体的な提案を考え出し、政治力と交渉力を使って妥協点を探す
◆スケジュールが遅延している、またはリソースが不足している~
次のマイルストーンに間に合う可能性が75%を割り込んでしまっている場合は、以下の対応を行う。
-機能を削除する
-スケジュールを延長する
-スケジュール上のリスクのリストアップ
-クリティカルパスの移動
-作業を将来に予定している他のものと交換できるか検討
◆品質が低い
-優れた品質とは何かということについて、チーム全員の理解を育み、それに対して日々の目標を設定する
-何か（機能、時間）を犠牲にして、品質を向上させる
-進捗スピードを一旦低下させ、品質が一定基準を満たし、チーム全員が品質基準を満たす方法を理解するのを待った上で、進捗のスピードを再び上げる
◆方針が転換される
-変更を特定のコンポーネントに隔離できるかどうか検討
-どの仕様、あるいは仕様のどの部分が有効なのかを洗い出し、それらを切り出して開発パイプライン内に維持するようにしてから、変更しなければならないものの優先順位を明確にする
◆チームまたは個人の問題が発生する
-何が起こっているのかを尋ねる
-事態の改善に向けて何が出来るのかを尋ねる
-問題を洗い出し、言いたいことを全て言ってもらう
-症状について尋ねるだけでなく、原因を探るようにする
◆意見が一致せず、いさかいが起こる
-共通点を見出す。前向きな勢いを付けることができる点から手を付ける
-性格上の対立を見出した後、それらを無視する
-相互の関心事を見つけ出す。相互の関心事を書き出し、共通点と関連付け、それを明確に示す
-どの主張に譲れる点があり、どの主張が絶対に譲れないのかを把握する
-交渉を始める前には必ず、交渉が物別れに終わった場合にあなたが失うものと相手が失うものを理解しておく
-説得と議論を使い分ける
-人を説得する際には、進捗に最も重要となる主張に重点的に取り組むようにする
◆プロジェクトの方向性に対する信念がぐらついている
-信念を揺るがしている考えが正しいかどうか検討し、正しくなければ方向性を再び信じることができるように政治力を行使する
-チームのために小さな目標を設定し、それを達成させることで勢いをつける
-信じるよう頼む
◆反乱の恐れがある
-問題の存在を認め、全ての不平を整理し、少なくとも一部の不平については目に見える形で取り組む
** ダメージコントロール [#nbde0e56]
-プロジェクトを制御可能な状態に戻すことを最優先にする
-全員ミーティングの実施。状況を簡単に説明し、問題に取り組んでいることを伝える
-ミーティングで同意できない場合、同意できていたところまで議論を戻し、そこから一歩ずつ着実に議論を進める
-問題には１つずつ取り組み、その問題が解決してから、または誰かに推進役を割り当ててから、次の問題に取り組む
-ダメージが技術的なものである場合は、いつの時点まで正しかったのかを確認し、その時点まで戻す
-どのようにすれば問題を隔離することができ、プロジェクトの最も重要な部分に影響を与えないようにすることができるのかを考える
-ダメージを避けるためにリソースの適用を検討する
* 13章 ものごとを成し遂げる方法 [#f8b6e6e3]
**順序付き一覧表を作れ！ [#a717658b]
-PMは順位付けの一覧表の作成とメンテナンスに注力する。作成にあたっては、要求、機能、バグといったもの全てに関してやるべきことを洗い出し、プロジェクトにとって重要度の高い順に並べていく。
-ものごとを成し遂げるということは、重要なことを明確にするとともに、その判断結果をチームにおける全てのやり取りに反映させることにかかっている。
-メンバー全員に優先順位付けした一覧表を周知し、その一覧表に従って作業してもらう
-一覧表を持っておくことで、何が起こったとしても必ず、最も重要な作業を選択し、多大な労力をかけたり、士気を低下させたりすることなく迅速に調整を行うことができる
-ほとんどのプロジェクトでは、目標の一覧表、機能の一覧表、作業項目の一覧表という最も重要かつ最も形式的な順序付き一覧表を作ることになる
-これらの一覧表が必ず互いに対応付けられていることを確認する。全ての作業項目は機能に対応付けられ、全ての機能は目標に対応付けられている必要がある。
**第1級優先順位とその他を分類せよ！ [#i4b3bc78]
-どの項目を第1級優先順位として分類するか、真剣に検討する
-この項目群を少なく、密度の濃いものとするよう努力する
-この項目群によってプロジェクト目標を達成するための最も工数の少ない方法を定義することができる
-この分類は多くの議論や討論が行われることになるので、プロジェクトの早期に行うこと。また、いつまでもだらだらと続けてはならない
-順位付けを避けていてはプロジェクトの進捗などあり得ない
**優先順位は力だ！ [#n6531c10]
-確固たる優先順位を持っていれば、いつでも、どこでも、最も重要な主題に議論を収束させるための質問を投げかけることができる
**優先順位付けマシーンになれ！ [#tece9c10]
-PMが優先順位を保守することで、チームは重要なものごとに集中し続け、作業を進捗させることができるようになる
-優先順位付けは不変のものではなく、変化して当たり前のものであり、私たちの方向性や目標に変化があった場合には、それらを直接的かつ迅速に反映させる必要がある
**PMが「NO!」と言うことでプロジェクトは進む [#e968939b]
-PMは、目標にそぐわないものごとに対して「NO!」と言うことで、チーム全体のレベルを一定に保ち続け、チームを率いていかなければならない
-チームのメンバーには以下の宣言を行い、優先順位の重要性と、どれほど積極的に優先順位を守ろうとしているのかを伝える
誰かが優先順位を無視した指示をしてきたと思った時には「NO!」と言って下さい。あるいはその指示をした人に対して、
私が「NO!」と言っていたと伝えれば、その人は私のところに来るはずです。もし彼らが文句を言ったとしても、
議論して時間を無駄にしないようにして下さい。とにかく私のところに来るように言って下さい
**「NO!」の言い方 [#gdf205b7]
-「NO! それは我々の優先順位に合致していません」
-「NO! 時間ができた場合にのみ行います」
-「NO! あなたがxxxを行って下さい」
-「NO! 次のリリースで考えます」
-「NO! 絶対ダメです」
**クリティカルパスを知れ [#s6a0a48a]
PMは以下のクリティカルパスを把握しておく。
-プロジェクトにおけるエンジニアリング作業
-プロジェクトにおける大局的な見地に立った意思決定プロセス
-コードのビルドやバグのトリアージにおけるチームのプロセス
-ウェブやイントラネットにコンテンツを登録する際のプロセス
-プロジェクト目標に影響を与える打ち合わせ、出来事、プロセス
**冷酷であれ [#q73a95fa]
-多くの人々が尋ねることを躊躇したり、忘れたりしているものの、前提と真実をふるいにかける最もシンプルな方法は、「あなたが知っていることは、どのようにして知ったのですか？」と質問することである
-前に進もうとし、選択肢を探求し、どのような問題や罠であっても抜け出る道は必ずあるという信念がチーム内にないと、プロジェクトは成功しない
**抜け目なくあれ [#b799d2b5]
抜け目ないPMとして環境を評価するための大まかな指針を以下に列挙する
-どういったコミュニケーションスタイルをとるか？
-グループはユーモアのセンスをどれだけ持っているか？
-データに基づいて主張すれば、議論で勝つことができるか？
-xxxを効率的に行えるのは誰で、私はその人物のどういった点を真似でき、何を学ぶことができるだろうか？
-このメンバーやグループに対する振る舞いにおいて、最も再重要視される価値は何か？
PMは上記質問に対する答えに応じて、自らの作業方法を調整すべきである。
**ゲリラ戦術 [#z7745421]
目標達成のためのゲリラ戦術を以下に列挙。使い方には注意が必要。
-権限の保持者を知る。自分が話すことができる人の中で最も影響力がある人のところに行って話をする。
-情報源に当たる。又聞きでなく、実際の情報源である人物を見つけ、直接話を聞く。
-コミュニケーション方法を変える。意思疎通がうまくいっていないと感じたら方法を変える。最も良いのはホワイトボードを前にした対面コミュニケーション。
-二人きりになる。率直かつ正直な意見が聞きたい場合や、深い内容で集中した対話を行いたい場合に有効。
-誰かを捕まえる。一刻も早く答えが欲しいときに、答えを知っている人を待ち伏せする。
-姿をくらませる。割り込まれずに作業したいときに有効。
-アドバイスを求める。あなたが最も高く評価している関係者や、必要なものを得る方法について有益なアドバイスができる人をリストアップしておき、必要なときにアドバイスを求めるようにする。
-お願い、懇願、袖の下
-人々を互いに競わせる
-事前工作をしておく
-コーヒーや食べ物をおごる
* 16章 社内の力関係と政治 [#t89135e3]
- 適切なタイミングで適切な人を説得し、自らの知識を用いて皆が満足するような解決策を導き出し、状況を打開する人は、立場以上の大きな力を持ってると言える
- 職場の物理的な位置関係が持つ価値を軽んじてはならない
- 政治とは、人や組織を管理するスキル
- あらゆるリーダーは政治上や力の制約を抱えている
- 力の大きさは責任、ストレス、難度の大きさに比例する
- 政治とは、ある種の問題解決である
- どのような物事であったとしても、人が選択可能な現実的な選択肢は限られており、それらは全て政治的な関係を持っている
**力の種類 [#xf093669]
- 報償
- 威圧
- 知識
- 人脈
- 影響力
**力の誤用の防止策 [#z20a1cd8]
プロジェクトのいかなる時点においても、誰でも公の場で以下の質問ができる状況を作っておく。
-今週/今月/このプロジェクトに対する私たちの目標は何ですか？
-全体、あるいはサブチームにおける上記の目標で、何か矛盾していることはないでしょうか？私たちはどうやってそれらをマネジメント、解決することができるのでしょうか？
-この特定の意思決定は誰がどのようにして行うのでしょうか？
-この意思決定がプロジェクトにとって最善であることを保障するための基準は何でしょうか？
-あなたや私の力は、私たちの目標に貢献する、あるいはチームを支援する方法で用いられているでしょうか？
-リソースをどのように使用すれば、成功する確率を最も高めることができるのでしょうか？私たちはそれをどうやって実現すれば良いのでしょうか？
**政治的な問題を解決する方法 [#q864e9cd]
政治的な問題を成功裏に解決する唯一の方法は、ニーズを明確化してから、それを入手するための計画を立てること。
主なニーズは以下の通り。
-リソース（予算、時間、要因）
-意思決定を行う権限
-あなた以外の人が意思決定権限を持っている場合、その意思決定に対して与えることのできる影響力
-あなたの目標を支持する、またはあなたの目標と整合性を持つようにするための、他社の目標の調整
-他社の目標と整合性を持つようにするための、あなた自信の目標の修正
-アドバイス、専門的知識、サポート
**マネージングアップ [#m73cdef4]
-あなたの責任を決定する時こそが、あなたの仕事をやり遂げる上で必要となる権限についてじっくり考えるチャンス
-あなたが現時点で持っていないものの、今後必要となるサポート全てを洗い出せば、マネージャはそのサポートを行う方法について、何らかの手助けを行うことができる。これをマネージングアップと言う。
最も簡単なマネージングアップの方法は、あなたのマネージャと議論を開始し、以下のような具体的なポイントを提案すること。
-マネージャに対して行って欲しいこと（指導、知っておくべきことの教授、意思決定の支持、成長すべき分野の指摘 など）
-目標達成に必要なリソース、そのリソースを用意できる人
-関与レベルと関与頻度
**ニーズを満たすことができる確率の評価 [#b9d58f2d]
以下のポイントをチェックすべし。
-あなたの必要としている力を誰が持っているか？
-過去において、どの程度この手の支援を取り付けることに成功したか？
-この手の支援を取り付けることに、過去に誰が成功しているか？
-あなたの主張にはどのくらい説得力があるか？
-どのようなアプローチとスタイルが最も有効か？
-あなたの必要とするリソースを誰かが狙っているか？
-これは闘うべき戦いなのか？
-見えない障害物に気をつける
**影響力を行使する際の戦術 [#w3659326]
-直接要求
-対話
-側面攻撃（同様の主張や意見を持った他人の影響力を利用）
-段階攻撃（自分から必要としている人までの間の関係を把握し、最も身近なところから段階的に攻める）
-間接攻撃（他の人に代理で要求を出してもらう）
**グループでの打ち合わせ [#c8bd07a1]
-決定しなければならない、あるいは議論しなければならない重要なことがある場合には必ず、打ち合わせの前に予め参加者を吟味する
-打ち合わせが始まるまでに、あなたの力と影響力を使用するための準備を十分に行う（打ち合わせに対して影響を与えるだけでなく、打ち合わせの場で起こりそうなことにも対処する）
-打ち合わせが始まるまでに、出て来そうな質問と、各参加者が聞きたがっている答えを考えておく
**マネージャがやるべきこと [#k8618817]
-自らのチームを守る道を見つける
-チームの作業効率を高めつつ、本当の経験と学習機会を与えることができるよう、バランスを考えながらチームを守る
-チームに明確な目標がない場合は、明確な目標を設定する
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
