佐藤 知一 / 世界を動かすプロジェクトマネジメントの教科書
佐藤さんのブログをよく読んでおります。というわけで、期待して購入。かなり読みやすいです。
テーマとしては、海外の別企業と共同でプロジェクトを行う際は日本の仕事の常識を見直してみましょう、という内容ですが、日本国内で完結しているとしても参考にすべきシーンも多いかと思います。シンプルにプロジェクトマネジメントのヒント集としておすすめ。
#2021-01-24 古書整理のためにざっと再読したため、一部追記・編集しました
発言権も実権もない若手がプロジェクトに向き合う
主人公である「広田さん」が、いわば作者の佐藤さんのデフォルメキャラとして登場。そして偶然会った、大学時代の後輩「小川くん」。彼が関わる「海外メーカーとの共同開発プロジェクト」の指南をすることになり…、
最初から最後まで、登場人物の会話形式で話が進みます。
佐藤さんの会話形式問答は、リアリティがあってかなり分かりやすいです。
（都合のいいキャラが定形問答とギャグを言って、詳細は「コラム」に長々と書いてある、みたいな内容じゃないですｗ）
なにより良いのは、小川くんがあまり権限を持っていない若手であること。
きっと日本は「発言権も実権も無く、また、あったとしても容易にそれを扱えない」というジレンマが強い人が多いと思うので、実際に「プロジェクトをなんとか良くしたい」と思って本書を取っている作者にちゃんと寄り添っている内容だと思います。
小川くんのプロジェクトは、「誰が何の権限を持ってるのかはっきり決まっていない」とか、「相手側との契約周りが曖昧」など、ヤバい臭いがプンプンしてきます。
別に伝統的日本企業の以心伝心・暗黙知文化が悪というわけではありませんが、規模が一定レベルを越えてくれば、国内であってもやはり明文化や契約書等は大切になってきますよね。
それでも、曖昧になってしまっている組織やプロジェクトはかなり多いと思うのですよね。
「プロジェクトマネジメント」
まずはプロジェクトの定義から。・達成すべきゴールが決まっている（完了条件）
・複数の人間が協力して行う（協力条件）
・失敗のリスクを伴う（リスク条件）
プロジェクトの定義って色んな人がいろんなこと言ってますが、だいたい内容は同じです。
ただ「失敗するリスクを伴う」というのは初見。なるほどなあと思います。
失敗するリスクがない ＝ 定型業務 ですから、たしかにそれはプロジェクトじゃないですね。
そして、よくある「マネジメントとリーダーの違い」についてはこんな説明です。
マネジメントとは、「人に動いてもらって、目的を達成すること」
リーダーシップとは、「対等な仲間を引っ張って、動かす力」
ちなみにプロジェクトマネジメントの目的は「プロジェクトの期待価値を最大化する」こと。
プロジェクトの種類
受注型 ←→ 自発型（スコープを自分で決める）大型 ←→ 小型
の表が出てきて、大型かつ受注型は「オーケストラ」、小型かつ自発型は「ジャズバンド」という例え。
オーケストラ：指揮者（指示するだけで演奏しない人）がいて、きっちりした楽譜もある
ジャズバンド：バンドリーダーはいるが指揮者はなく、ソロはそれぞれ、アレンジもその時々、即興などもある
なるほどねぇ。
SIerの大型案件と、Webベンチャーの新規サービス開発する小型プロジェクトって、違うのは一目瞭然だけど、何がどう違うのかはしっかり整理できてなかったです。
ちなみにPMPは大型受注プロジェクト寄り、P2Mは大型自発プロジェクト寄りだそう。
PMPの方は想像がついたんで、小型自発プロジェクトを担当した時は「PMP勉強してもあんまり意味ないだろうな」って思ったのですが、P2Mは自発プロジェクト向けなのですね。
これはちょっと調べてみよう。
ゴールと目的と目標
出ました、耳タコ格言の代表格！「なにがプロジェクトの成功なのか」を最初に定義しておく。
でもこれ何度、どの本で読んでも、一回やってみないと身につかないんですよねぇ。。。
ミッション：プロジェクトの使命
ゴール：完了条件のこと。WhatあるいはWhere。「○○できたら終了する。」
目的：なぜそれをするのか。背景。Why。ゴールより広い。
目標：成功したかどうかを判定するモノサシ。どう達成すれば成功とするのか。How。これは複数ある（のが普通）。
ex「○○社との共同で、XXの性能を持つ新製品を8ヶ月以内に市場に出荷する」
ex「X国で3年以内にxx億円以上の売上を達成する」
ひとりごと：
もしかしてこの目標に入るものって、この３種類しかないのではないか…？
・新しいものを作り出す(売り出す)
・効率化の施策等でコスト/時間を削減する
・売上高を純増させる
ここで「プロジェクトチャーター」を書くことをおすすめされます。
短くてよい。A4が3枚くらい。そしてできれば印刷してプロジェクトルームにはっておく。
「インセプションデッキ」と似ています（欲しい結果はほぼお同じだと思う）が、個人的には「プロジェクトチャーター」の方が分かりやすい・馴染みやすい日本語です。
- プロジェクトの名称
- 達成すべきゴール（完了条件）
- プロジェクトの目的（背景と意図）
- プロジェクトの目標（成功を測る基準）
- スローガン（あれば）
- プロマネの名前
- プロジェクトの組織
- プロジェクトの遂行方法
- 概略予算
- 最終期限とおもなマイルストン
- おもなチャレンジ項目と想定されるリスク
チャレンジのOS
プロジェクトの遂行能力は、ピラミッド構造で下から OS（体制や習慣）＞ アプリ/道具（過去のデータや手順やツール）＞ プロマネの個人スキル となっていて、プロジェクトは「組織のOS」が基盤となるので、外から「デキるPM」を連れてきたってうまくいかないよというわけですね。
組織自身の力というか文化というか。ブランディングの話にも通じるかと思います。
チャレンジのOSは、S＋3K
S：システムズアプローチ（システム的な見方をする）
K：言葉を大切にする（言語化）
K：契約と責任を重んじる（契約責任性）
K：かならず計画をたてる（計画重視）
プロジェクトの計画
次はWBSの作り方。いきなり「ガントチャートツールでざっとタスクを切って、それぞれに日付と担当を入れていきまーす」とすると、これは抜け漏ればかりのものに。
小規模で慣れてる（よくある）ものなら、これで十分なのだと思いますが。が、「失敗するリスクがある」と思った瞬間に、これはやめるべきだと思います。
まずはゴールに必要な作業（アクティビティ）リストを網羅し、それを誰がやるかを考え、タイムテーブルと収支を作る。
必要なワークパッケージ（プロジェクトをコントロールする最小単位）を洗い出すこと。
簡単そうに見えて、これが結構難しいんですよね。ここがPMの肝だ、ということも書いてあります。
ちなみにプロジェクトには以下のような種類があり、特徴が違うので頭に入れておくとよい。
・ものづくり系
・サービスづくり系
・イベント系
・研究系
テクニックとして、
「成果物のスコープ」と、「プロセスのスコープ」をそれぞれ洗い出し、それをマトリクスにする、 というのはなるほどなと思います。
「リソース」と「プロセスのスコープ」のマトリクス もいいですね。
それを見ながら、階層や左右のバランスが悪くないWBSを作り
↓
それを、インプットとアウトプットをそれぞれ添えたアクティビティリストに落とす…
担当者、完了日、工数、予算も入れる。
で、それを見ながら、「逆算で」スケジューリングをしていく。
ワークパッケージがMECEになっていれば、スケジューリングは、パズルっぽい感覚で取り組めるはず。バッファや予算の考え方のコツなんかも書いてあります。
ここで、何を工夫しても、工期やリソースが不足していることがわかれば、この時点で対策を講じることができるわけですね。
組織と予算を作る
スケジュールは、まずは「逆算」で考えます。いわゆるPM系の試験で必ず出てくるのが「プレシーデントダイアグラム」。
アクティビティを箱にして、順序ごとに並べて矢印でつなぐ。並行して作業すべきもの・できるものが普通はあるので一本道にはならない。
それぞれのアクティビティに必要な工数(日数)を箱に書き込み、かつその箱の４頂点にそれぞれ「最早着手日」「最早完了日」「最遅着手日」「最遅完了日」というのを前後のアクティビティボックスをみながら計算して入れていきます。
ここで最早着手日と、最遅着手日が同じであるボックスの並びが「クリティカルパス」で、これは日程定期に余裕もないし順序も動かせないという死守すべきスケジュールとなる。
もしこのクリティカルパスが納期に間に合わなそうなら、以下のようなやり方等で短縮を試みる。
- アクティビティを見直して（細分化して）実はそのアクティビティ全てを完了しなくても次のアクティビティが動き出せる（後半の作業が並列になる）ものがないかを検討する
- 各アクティビティに見積もり担当者らのバッファが混じってないかを確認し、プロジェクト全体で申告してもらい、バッファをプロジェクトで共有する（※ただしこれは想定と違う結果になったとき、各申告者を責めないようなルールの徹底が必要なので大技）
-
ただし何より大事なのは、「実行可能なスケジュールをみんなで一緒に作る」という気持ち。
- 製造過程よりコストが低い事が多い「頭を使うアクティビティ」の価値が過小評価されがち
- リスクが計算に入ってない
- 総合値で見るためクリティカルパスの遅れ等が反映されない
- コスト計上のタイミングによってだいぶ見え方が変わってしまう
誰か偉い人が１人で机上でやって従わせるより、現場を知っていて実際に動くメンバーから進言があればより現実的な計画になるし、メンバーが「自分たちで作った」と思えれば当事者意識や責任感も増す。
組織については、機能ごとに部署となっている「機能別組織」は、決まった定常業務をきちんと回すにはとてもよい。
ただ、この組織形態ままプロジェクトチームを動かす（本ではおそらくこれを「マトリクス型組織」）というのは難しい。意思決定が遅くなるし、プロマネの権限も微妙となる。指示形態や評価が困難になる。
だからといってプロジェクト型チーム＝部署としてしまうと、技術力の蓄積が図りにくいし、会社全体での業務プロセス改善というのも難しい。状況によって体制はよく考えるべき。
しかし、これは誰が偉いか上か下かという話ではなく、プロマネはあくまで「役割」であることを忘れないこと。首相であっても道路交通法には従うのと一緒。
それとプロジェクトオーナー(スポンサー)の存在。
プロマネの悩みの多くは「予算不足」か「役員不足」だから、スポンサーはトップを説得してそれらを支援できるような人がよく、その人が任命するのが望ましい。
ただ、大きな組織ではこれを１人で担うというのも難しい。
だから「ステアリングコミッティ」執行委員を作り、そこに各部署の要人とかに参加してもらい、プロジェクトで決めきれないことをここに上げて合議制で決めてもらう、という手もある。
そして「事務局」という名前の（実質PMO部隊のようなものを）技術部に置く。「事務局」って便利な言葉だよね。
いろいろ情報が入ってくるし、マネジメントに関するWBSや予算表とかを管理していてもなにも言われない。管理されているという妙な上下意識も生まれない。
進捗とコミュニケーション
進捗管理と違い、費用の管理は数字を出して行うべき。これは「プロジェクトが終わった時に全部でいくらかかるか？」「最初の予想した予算内に収まるか？」といった問いに答えるため。
ここでもPM系試験でよくでてくる「アーンドバリューマネジメント」の図が。
予定の線(Planned Value)と、実績の線(Actual Cost)以外に、出来高の線(Earned Value) を描くと、例えば予定より実績が低くなっていたのは、進捗が予定より遅れているからだ、といったようなことが予測できる可能性がある。
ただし、これは実務で使う際は結構留意すべきごとがあるから、使う際には注意。
リスクへの向き合い方と交渉
リスクの大きさ ＝ （可能性 × 影響度）÷ 対応能力よって、リスクの大きさを小さくしたいなら、影響度を小さくするか、対応能力を大きくするかしかない。
リスクへ向き合う態度として、２パタンがある。
・安全第一主義（前例主義、失敗しないのが当たり前）
・現実主義（小さな失敗を上手にする方法を学ぶ、リスクに見合う最適なコストに収める）
安全第一主義は、お役所や公的事業的な組織に未だに多いが、現実主義のライバルが力をつけてきているのでは？
リスクは、キーパーソンが集まってわいわい洗い出しをし、影響度、発生確率、優先度等を議論し、それにたいしてどうアプローチできるか、もしくはしないか、という「リスク対応策」と担当者をまとめる。
これで、洗い出しするまえはリスクのすべてが「未知のリスク」だったものから、「予期されたリスク」→「予期され計量化されたリスク」へと転化できる。そうすれば影響度を下げるか、対応能力を上げるかの対処が検討でき、リスクとしては軽くすることができるはず。
「未知のリスク」はどうしようもないから、なんとか予備費を捻出しておく等で対応する。
交渉については、明確で強い意志をもつこと、事前に(相手や市場や競合を)よく調べて戦略を考えること、オープンクエスチョンをしてからクローズドクエスチョンで誘導する・Yes…andといった否定をしない言い方をするなどの戦術を使う、そしてなにより「相手の信用を得る」ことが最上だと肝に銘じること。
立ち回りの難しさ
さて、全体を通して非常にリアリティかつ役立つテーマとして出てくるのが、「立ち回りの難しさ」です。これが、PMPとかを勉強してもおそらく分からない現場の勘所なのでは。
つまり、タイトルにもある「違う文化の人（組織）と一緒にプロジェクトを回す」ことの難しさ。
そして、社内の上司や組織をどうコントロールするか、という難しさ。
よく、「ドイツではすぐに議論になる。みんな議論が好き。」という話を聞きますね。
本書の例えで「相手が汗をかき出したら成功」とかいうネタが出てきます。
日本は「分からない」と聞くのはあまりよくない印象ですが、欧米流だと「分かるように言わないやつがわるい」（だから分からなければ分かるまで聞く）という感じでしょうか。
でも日本も、自分が第三者とか、相手がいない場所だとめちゃくちゃ言うんですよね。笑
「あんな説明で分かるわけねーよ」って。
政治家の演説ならともかく、仕事の相手であれば「ちゃんと聞かなきゃ仕事できないでしょ」って怒られるレベルですが、聞き方が難しいんですよね。
とくに相手が年季の入った年上の上司とかだと。笑
でもここを、上司や組織を上手く手のひらで転がすくらいに思ってやるのが大事。
・・・と、話が逸れました。
本書ではここまで具体的なやり取りは出てきませんが、「ぼくみたいな立場でそんなことしたら、『余計なことするな』って怒られる」みたいなくだりは全編通して出てきます。
海外チームとの関わりもあってややこしい。
これが実際、一番難しいところだと思うんですよね。
工程表の作り方とかバーンチャートだとかいう小手先のテクニックは、使えるけど、それを勉強したからってプロジェクト回せるようにはならない。
（でもテクニックなので、あればあるほどよい）
本書は会話形式なこともあり、著者が現場で活躍する人なこともあり、その辺のバランスが非常に逸品だなと思います。
というわけで、プロジェクトが始まるときには、ぜひざっと再読したい本。
現場で働いたことのある殆どの人に有用だと思います。おすすめ。