内容
プロジェクト憲章
リーダーはプロジェクトを始める前に、「なぜ、自分たちはこのプロジェクトを行わなければいけないのか」という理由を自分自身で納得し、一緒に走る仲間に説明する必要があります。
プロジェクトを取り巻く環境や背景、前提条件、達成したい最終目標および目的、求められる成果物、実現できた場合の想定効果、予算や許容されているスケジュールなどの制約条件、プロジェクトリーダーは誰が行うのか、チームの体制図などを文書化していきます。
これらは、PMBOKでは「プロジェクト憲章（Project Charter）」としてまとめられます。
ゴール
プロジェクトを成功させるためには、リーダーは「SMART GOAL」を心がけましょう。
プロジェクトリーダーはマイルストンの設定およびレビューする際には、以下の4点について注意してください。
・ゴール（最終目標）を達成するために通らなくてはならない条件もしくは状態が具体的に定義されていること（正しい例：〇月〇日要件確定、△月△日設計完了など）
・状況の変化に左右されないこと（外的環境で変化されない）（悪い例：為替が1ドル ＝ 120円になった場合）
・「どのように」達成するかではなく「何」を達成するかが述べてあること（正しい例：教育対象者一覧完成、テスト検収書受領など）
・時間軸に沿って平均的に分散していること
逆算思考
・アマゾン社では、新サービスに着手するときに「逆算思考」を用いている。その代表的な取組みとして製品ありきのプロダクトアウトの発想ではなく、「顧客の視点」をスタート地点にするため、開発前に“プレスリリース”を作成している。
・そのプレスリリース内容は、サービスの特徴とユーザーにとってどのような便益が得られるのかに焦点が当たっている。プロジェクトキックオフ時に全員でそれを読み、サービスの意義、価値、利用シーン、Q&A、ユーザーマニュアルまで想定する。
・プレス記事を通じて、リーダーのみならずプロジェクトメンバー全員で実現したいビジョンとゴールを共有し、チームのパフォーマンスを引き出している。
成果の三要素
リーダーはプロジェクトで取り組む対象範囲において、達成すべき「成果」を定義する必要があります。
自分たちのプロジェクトは何をもって成功したと評価されるのか、以下の3つの要素で定義することで、クライアントとの認識のズレを防ぎ、チームが目指すべきベクトルを合わせます。
・成果の形状
・受け入れ基準
・受け入れプロセス
リスク
・リスク…潜在的な阻害要因
・問題……顕在的な阻害要因
・課題……取り組むべき問題の原因
それぞれの違いを理解することで、プロジェクトリーダーは管理すべき対象の優先順位を明確にできます。
「リスク」と「問題」の関係は、しばしば氷山で説明されます。
海面より上の部分、すなわち顕在化している阻害要因を「問題」と呼び、海面より下の部分、すなわち潜在的な阻害要因を「リスク」と呼びます。
当然、「リスク」はまだ起きていないわけですから、外から観察するだけでは水面下をうかがい知ることはできません。
目の前で起きていることをじっくり見つめることを「観察」と言います。
それに対して、まだ見えていないものを見ようとすることを「洞察」と言います。
体制構築
「自分たちは何のために集まっているのか」を理解し、「一人ひとりの持つ強みは何か」にフォーカスすることです。
プロジェクトにおいては人数（マンパワー）よりも、ゴール達成に必要な能力（スキル）を持っているメンバーを集めることが求められます。
CFT（クロスファンクショナルチーム）と呼ばれる全社課題解決のために部門横断型のチームを常設する組織も増えていますが、運営するためには経験が必要になるでしょう。
・12頭の犬にはすべて異なる役割があり、楽な役目はない
・全頭が 1つのマグネットのように意思統一できていないと、そりは一歩も前に進めない
・列の先頭にいる 2頭がリーダー犬であり、もっとも足が速く、賢く、冷静である。マッシャーの考えをもっとも理解している
・リーダー犬の役割は、列の「方向性」と「スピード」を決めること。リーダー犬のスピード以上に列が速く進むことはない
・2列目の犬は、「調整役」を担う。先頭を走るリーダー犬の「方向性」と「スピード」にしたがいながらも、後続の犬たちの進捗や疲れ具合を見て、全体のスピードを微修正する
・とくに 2列目の犬が重要なのは、列がカーブを曲がるとき。彼らは列全体の能力を考慮しながら、転倒しないギリギリのスピードを選択する
・そりに一番近い最終列に位置する 2頭は、チームの中でもっとも身体が大きく、脚力が強い犬が担当する。停止している重いそりを最初に動かすためには、まず、この 2頭が全力を尽くさなければならない
・犬たちは本能的に闘うことで組織におけるヒエラルキーを決めるため、一緒に飼育すると傷つけ合ってしまう。そのため、普段は離れた部屋に分けて飼育されている。そりをひくときだけ、列に合流するが、お互いの役割を理解し合い、協力し合っている
プロセス
「プロセス」を設計する際の5つのポイントについて理解を深めていきましょう。
・IPO
・5W1H
・スキルレベル
・依存関係とマイルストン
・1W&1P
「1W&1P」です。何やら呪文のように見えますが、「1つのタスクは最長1週間以内に分割する」「1つのタスクには原則、1人の担当者を割り当てる」
最長経路
プロジェクトを遅延なく運営するためには、クリティカルパスを重点的に管理し、リソースを優先的に配置します。
納期短縮が要請された場合は、クリティカルパス上の作業にリソースを追加投入することで圧縮できるかを検討する必要があります。
私は、プロジェクトを成功に導くためには、「②スコープ（範囲）」「⑤品質（期待値）」「⑦コミュニケーション（チームビルディング）」「⑧リスク（阻害要因）」「⑩ステークホルダー（利害関係者）」の5つを集中的に管理していくべきだと考えます。
なぜなら、この5つは放置しておくと、「悪化または増加していく」性質を持ち、「資源」を「加速度的に食いつぶしていく」影響要因だからです。
プロジェクトのスコープは拡大しやすく、お客様から求められる品質はどんどん上がっていきます。
チームのコミュニケーションはコンフリクト（対立）を起こしやすく、リスクは手を打たなければ問題として顕在化していきます。
利害関係者の中でも反対派（ブレーキ）はスケジュールが先に進むほどに依怙地になっていきます。
ルール
一般的に、プロジェクト立ち上げ時に私たちは以下のようなルールを設定します。
・出社時間、退社時間、遅刻または早退時の連絡ルール
・座席表、連絡先（電話、メールアドレスなど）
・成果物のネーミングルールおよび格納場所
・会議体のルール（時間、場所、議事録など）
・進捗確認シート
・成果物のテンプレート（要件定義書、設計図など）
・問題発生時の管理ルール（データベースなど）
・プロジェクト辞書（用語説明など）
議事録
議事録の目的は、「決定事項を合意する」「課題を確認する」「今後の行うべき作業を整理する」という3点に集約されます。
変更要求
多くのプロジェクトでは、「変更管理DB（データベース）」「変更管理一覧表」などを整備し、一元管理する運用をしています。
起票内容としては、「変更要望内容」「変更理由」「影響範囲」「業務面からの緊急性」「変更した場合のメリット」「変更しない場合のインパクト」など、判断に必要な情報を記入してもらいます。
その際の注意点は、「要件変更を要望しているユーザー自らが起票する」ということ。
プロジェクトによっては、外部コンサルタントがクライアントから依頼されて代理入力しているケースも見られますが、私は断固反対です。
理由は、「要件の認識のズレを防止」し、「責任の所在を明確化」するためです。
組織運営
「ホウレンソウ」はあくまでも、チームの目標達成のための手段としてのコミュニケーションです。
これを、アメリカの心理学者レオン・フェスティンガーは「道具的コミュニケーション（Instrumental Communication）」と名づけました。
チームが成り立つためにはもう1つ、別の方向性のコミュニケーションも必要になってきます。
それは、「自己充足的コミュニケーション（Consummatory Communication）」と呼ばれます。
これは、何か具体的な目的があって行うコミュニケーションではなく、単に自分の気持ちや感情を表すためだけの会話やあいさつ、笑い話などのコミュニケーションに当たります。
SL理論
SL理論では、メンバーの成熟度（レディネス；Readinessという表現を使っています）を、「能力（Ability）」と「意欲（Willingness）」の2つの指標で整理しています。
リーダーの5つの情報経路
リーダー自ら「①情報収集者（コレクター）」として、それらを取りにいく姿勢が求められます。
同時に、リーダーは自分の持っている情報をメンバーに伝達する「②配給者（ディストリビューター）」としての役割も持ちます。
各メンバーの役割や成果物の作成に有益な情報を取捨選択しながら、適切なタイミングで共有していきます。
情報はリーダーからメンバーへ伝達するだけでありません。
メンバーからリーダーに対して、情報を吸い上げる「③管理者（モニター）」としての役割も必要です。
計画に対する進捗はどうなっているか、重要な課題を抱えていないかなどを、随時キャッチする仕組みも必要です。
リーダーはチームの代表です。
自分たちのチームの進捗や課題が他のチームの作業にどう影響するのか、常に確認する必要があります。
チーム内で解決できないハイレベルな課題についてはステアリングコミッティー（プロジェクト運営委員会）の判断を仰ぐよう、早めのエスカレーション（上位への指示相談）を行います。
また、リーダーはチームメンバーの頑張りや貢献を、メンバーの上司や人事評価者へ伝えなければいけません。
よって、リーダーは積極的に外部チームへの「④報道官（スポークスマン）」としての役割も意識して、チーム外とのコミュニケーションも図っていく必要があります。
最後に見落としがちなのが、「⑤橋渡し役」です。
フランス語で「リエゾン」と呼びます。
リーダーは「リーダーとメンバー」間のコミュニケーションのみならず、「メンバーとメンバー」間のコミュニケーションにも気を配る必要があります。
メンバー間で理解や認識のギャップがないか、感情的な対立（コンフリクト）が発生していないかなど、必要があればリーダーは適度な手助けをしていきます。
これらのコミュニケーション課題は作業日報や問題管理シートには上がってこないケースが多いので、リーダー自ら現場を歩き回って、手を打っていくことが求められます。
意思決定プロセス
プロジェクト成功の秘訣は、「意思決定」の手法にありました。
プロジェクトでは、毎週火曜日に「設計会議」が開催されており、関係者は誰でも参加することができました。
そこでのルールは「具体的な要件の設定」「課題解決に向けた意思決定」を行う、ということでした。
プロジェクトでは、議論が空中戦になることを避けるために、「運用シナリオ」「技術的実現性」「実現コスト」「トレードオフ案の妥当性」などの「評価軸」を明確に定めていました。
そして、議論の流れと決定事項をすべて、文章で開発関係企業に公開していました。
面白かったポイント
タイトル通り、プロジェクトマネジメントの基礎がまとめられている。
リーダーの5つの情報経路はよくまとめられているし、意識して実践していかないといけないと思う。
満足感を五段階評価
☆☆☆☆