明日から使えるプロマネ基本スキルが身に着く1冊/『孫社長の締め切りをすべて守った 最速！ 「プロマネ」仕事術』
こんにちは、Fujiです。
僕は普段ゲームプランナーをやっていますが、施策を考えたり仕様書を作ったりしつつ、プロジェクト全体の進行管理も行っています。
今でこそプロジェクト全体のスケジュールを見ながら、タスクの進捗確認や仕事の割り振りなどを行えていますが、社会人になって数年はプロジェクトの進行管理に限らず自分のタスク管理すら怪しい時期がありました･･･。
スケジュール作成とか、タスク管理とか、できるようになりたい！と思っていた時に、『孫社長の締め切りをすべて守った 最速！ 「プロマネ」仕事術』と出会い、プロジェクトの進行管理スキルを身につけることができました。
「いつも仕事が〆切に間に合わない」
「うまくスケジュールを立てたいけど、何から始めれば良いかわからない」
こんな経験をしたことはないでしょうか？
今回紹介する本は、こんな経験のある社会人の方にぜひ読んでいただきたい本です。
この1冊だけでもプロマネの基本スキルはしっかり身につくと思います。
この本の著者は、元ソフトバンクの社長室長である三木さんという方で、
タイトルにもあるように孫社長の新しいプロジェクトのプロジェクト・マネージャー（プロマネ）を任されてきた方です。
ナスダック・ジャパンの創設、日本債券信用銀行（現・あおぞら銀行）の買収、ADSL事業「Yahoo!BB」の立ち上げなどのプロジェクトでプロマネを務められてきたそうです。
【おすすめする理由】
僕がこの本をおすすめする理由はズバリ、「明日からすぐ使える」からです。
著者の方はソフトバンクでプロマネを務められて、ちゃんとPMBOK(プロジェクトマネジメントに関する知識体系)も学んだ方です。
様々な経験をし、学術的な知識もある上で、「とはいえ実際の現場で使えるようにノウハウを落とし込むとこうだよね」というスタンスでこの本を執筆されています。
なので、プロジェクトをそれほど経験していない社会人歴の浅い人にとってもとても分かりやすい内容になっています。
僕も社会人2～3年目くらいの時にこの本に出会いました。
当時は、
「クリティカルパスとか、ステークホルダーとか、そういう言葉はなんとなく知ってるけど、でもそれって実際にプロジェクト上のどこでどう使うの？てかそれ以前にそもそも何から始めればちゃんとしたスケジュールを組めるようになるの！？」
みたいな状況でした。
そんな中、この本に出会って読んでみると、「まずはこれを決めてね、次にこれをするんだよ」と難しい言葉を使われることもなく、手取り足取り教えてくれているような感覚で学ぶことができ、学んだことをしっかり現場で活かせました。
前置きはこのくらいにして、ここから本の内容に入っていこうと思います。
このnoteでは、特に大事だなと思うポイントをピックアップして紹介いたします。
【結論】
さっそく結論からお話します。
プロマネの基礎スキルとは、
「ゴールを決めて、プランニングをして、タスク実行すること」です。
プロジェクトを進めるにあたって、プロマネがやるべきことは、
「ゴールを決める」、「プランニングする」、「タスクを実行する」という3つのフェーズに分かれています。
それらの3つのフェーズで行うことを、さらに細かく書くと、こうです。
▼概要：プロマネの基本スキル
・ゴールを決める
└プロマネを決める
└オーナーを決める
└品質・納期・コストを明確にする
・ゴールまでのプランニングをする
└ゴールを達成するためのタスクを洗い出す(WBSを作る)
└タスクをアウトプットで定義し、担当者を明確にする
└タスク間の依存関係を整理する
└スケジュールを組み、タスク管理シートを作る
└定例会を設定する
・タスクを実行する
└毎週定例会を行う
└タスク管理シートとアウトプットの差分を確認する
└遅れが発生している場合は是正措置を講じる
└翌週のタスクのアウトプットを確認する
これらの細かいところについては後述していきます。
そして、これからプロジェクト・マネージャーの話をするにあたって、「プロジェクト」という仕事についての前提もそろえておきましょう。
本書では、「プロジェクト的な仕事」とは、以下の特徴を持つ仕事だと定義されています。
▼プロジェクト的な仕事
・明確な〆切があり、ある一定期間内に成し遂げる仕事
・他部署、他部門や他社の人間と共同で進める必要がある仕事
・過去にやったことがなく、具体的な手段や手順があらかじめ明確になっていない仕事
例を挙げるとよりわかりやすいと思います。
例えば、「新しい商品を企画して売る」という仕事はプロジェクト的な仕事と言えますね。
▼新しい商品を企画して売る
・発売日が決まっている
・商品企画部、マーケティング部、製造部、品質管理部、営業部、小売（他社）･･･etc.と協力して進める
・過去に無い全く新しい商品を作る
僕の業界である「ゲームを作る」というのもプロジェクト的な仕事です。
▼ゲームを作る
・リリース日が決まっている
・プランナー、デザイナー、プログラマ、SE、デバッガー、マーケターと、多くの他部門と協力しながら開発を進める必要がある
・過去に無い新しいコンテンツを作る
他にも、以前書いたnoteで紹介した「ポケモンのゲーム」や「ポケモンのアニメ」なんかは、相当多くの会社が絡んだ巨大プロジェクトと言えるでしょう。
もし、今自分が進めている仕事が、上記のような「プロジェクト的な仕事」に当てはまるようでしたら、
ぜひ読み進めていただければと思います。
では、「プロジェクト」の定義がはっきりしたところで、
「ゴールを決める」、「プランニングする」、「タスクを実行する」のうちの「ゴールを決める」から見ていきましょう。
【ゴールを決める】
▼プロマネを決める
まず、誰がプロマネであるかをはっきりさせましょう。
誰がプロマネかが明確じゃないと、プロジェクトの進捗状況が誰も分からなくなるからです。
もしプロマネが不在のままプロジェクトが進行すると、
各々が自分のタスクに関係のある人としか連絡を取らなくなります。
そうすると、個々での情報量や新しさがだんだんとバラバラになっていきます。
そして最終的には、このようなことが起きます。
「今、誰がどんなタスクをやっているかが分からない」
「Aさんが言っていることとBさんが言っていることが違う。最新の情報どっち？」
「このタスクはそっちの部門の人がやってくれると思っていた。今さらお願いされてももう〆切には間に合わない」
「CさんとDさんしか知らない情報が今になって判明した」
こうして、プロジェクトの終盤になって〆切になんとか間に合わせるためにほぼ全員が残業をするハメになるのです。
（いわゆるデスマーチと呼びます）
いやー、おそろしいですよね･･･。
こうならないために、まず「プロマネは誰か」を明確にしましょう。
そうすることで、進捗情報がプロマネに集まり、常に最新の正確な状況が分かるようになります。
その結果、〆切に対して遅れが発生しそうだとしても、そのことを素早く察知し、対応することができるようになります。
▼オーナーを決める
次に大事なのが、オーナーをはっきりさせることです。
オーナーというのは、そのプロジェクトの依頼人であり、意思決定者です
プロジェクトは、「品質・納期・コスト」によって構成されています。
この内容とバランスに対して意志決定を行うのがオーナーの主な仕事です。
「品質を下げてでも納期に間に合わせろ」
「納期とコストはどれだけかかってもいいから最高の品質でリリースする」
など、これはオーナーが決めることです。
（プロマネはこの部分に責任を負っていないので、オーナーが決める必要があります。）
この決定に従って、プロマネはプロジェクトの着地のさせ方を考え、現場のメンバーを動かしていくことになります。
オーナーが明確になっていないとどうなるかというと、この場合もデスマーチを引き起こしかねません。
明らかにオーナーにいる立場の人なのに、
「俺はこう思うけど、あの人の意見も聞いてみて」
ということを言われると、プロマネを含む現場のメンバーは
「結局どっちの話をもとに動けば良いんだ？」
と困惑します。
で、とりあえず動いてみたはいいものの、後になって
「それは自分の想定とは違った。この部分はこう変えてほしい。でも〆切は動かせない。」
みたいな話が降ってくることになります。
最悪の場合、オーナーが逃げて意思決定者がいなくなるということもあります。
こうならないために、プロジェクトのオーナーは誰で、誰が「品質・納期・コスト」に責任を持つのかを明確にしましょう。
とはいえ、
「いやいや、オーナーが1人の時はそれでも良いかもしれないけど、複数人いる時はどうすればいいの？」
というパターンも往々にしてあると思います。
そんな時は、「合議制にして定例会を作り、その定例会を意思決定機関にする」が正解だと著者は言っています。
▼品質・コスト・納期を明確にする
プロマネとオーナーが決まったところで、オーナーにプロジェクトの「品質・コスト・納期」を聞きましょう。
その「品質・コスト・納期」のバランスが、今回のプロジェクトのゴールとなります。
ここで、著者は「チャーターを作成しなさい」と言っています。
「チャーター」とは、PMBOKで使われている用語で、「権限委譲証明書」のようなものです。
つまり、「オーナーである私が、プロマネであるあなたにこういう内容のプロジェクトの進行をする権限を与えますよ」という文書です。
チャーターには、プロジェクト立ち上げの時点で以下の内容を盛り込んで、オーナーから了承をもらっておくのが良いと著者は言っています。
▼チャーターに盛り込む内容
・プロジェクトの目的・ミッション、ゴールイメージ、求められる成果物
・プロジェクト・オーナー名、プロジェクト・マネージャー名
・ステークスホルダー一覧
・定量目標と関連する成功基準
・前提条件
・スケジュールとマイルストーン
・予算
この文書があることによって、ようやくプロジェクトの全体像とゴールがはっきりします。
これで「ゴールを決める」ことができましたね。
次は「ゴールまでのプランニング」の話に移ります。
【ゴールまでのプランニング】
▼ゴールを達成するためのタスクを洗い出す(WBSを作る)
ゴールが決まったら、次はそのゴールに到達するまでのプランニングをしましょう。
プランニングでまず行うことは、WBSを作ることです。
WBSとは、「Work Breakdown Structure」という言葉の略です。
これは、「ゴールを達成するためのタスク」という意味です。
料理を例にするとわかりやすいかと思います。
カレーを作る場合のWBSをざっくり書くと、このようになると思います。
▼カレー作りのWBS
・必要な材料を調べる
・材料を買う
└肉、にんじん、玉ねぎ、じゃがいも、カレールー･･･etc.
・肉と野菜を切る
・肉と野菜を炒める
・水を加えて煮込む
・カレールーを加えて煮込む
・皿に盛り付ける
※WBSに取り掛かる前に、プロジェクトオーナーに目的と要件を確認しておきましょう。
「ダイエット中だから野菜カレーがいい」とか、
「香りを良くするためにルーはスパイスから作ってほしい」とか、
目的と要件によっては、WBS（買うべき材料や調理方法）がまったく異なってきます。
WBSを作る上で大事なことは、「抜け漏れを出さないこと」です。
ここで抜け漏れが出てしまうと、後々どこかのタイミングでその漏れたタスクを押し込まなければなりません。
とはいえ、他部門が関わるタスクについては自分の知識範囲では分からないこともあるでしょう。
その場合は、潔く「質問する」しかありません。
著者の方は、関係者を集めてタスクを付箋に書き出してもらうことで、効率的にWBSを作成していたそうです。
▼タスクをアウトプットで定義し、担当者を明確にする
WBSを作り終えたら、次にやることは「アウトプットの定義」です。
どういうことかというと、「○○をやる」という動詞で終わらせるのではなく、「○○書」「○○リスト」といった名詞でタスクを定義しなさい、ということです。
これは、動詞のままだと「やりっぱなしで次の仕事につながらない」ということが起こりうるからです。
例えば、「市場調査をする」というタスクがあった場合、
このまま「市場調査をする」という動詞表現でのタスクだと、「調べるだけでこのタスクは完了するんだな」とも受け取れるのです。
そうではなく、「市場調査報告書」とちゃんと名詞で定義しておけば、書類を作成して提出するところまでがタスクになり、後工程のタスクを行う人がその報告書を元にタスクを進めることができます。
そして、それぞれのタスクに対して担当者を明確にしておきましょう。
担当者が明確でないと、責任の所在がはっきりしないからです。
また、僕の個人的な経験から補足させていただくと、担当者をはっきりしておかないと、連絡窓口が曖昧になってしまうデメリットもあります。
担当者が決まっていないと、他部門の人がタスクに対して質問したい場合に、往々にして「とりあえずタスクが関係している部門のリーダーに聞く」という連絡ルートが生まれてしまいます。
そうすると、そのリーダーは質問されたからにはそのタスクに詳しい人に聞いて、その答えを質問してくれた人に返答します。
これでは、ただの伝言ゲームになってしまって、非常に非効率です。
担当者が決まっていて、その人と直接やり取りすればすぐに終わる話が、必要のない人まで巻き込んでしまいます。
だから、担当者ははっきりと決めておくべきです。
▼タスク間の依存関係を整理する
タスクごとの定義や担当者が決まったら、今度はそれぞれのタスクの依存関係を整理します。
具体的には、「クリティカルパス」の関係になっているタスクを見つけます。
クリティカルパスとは、「プロジェクト全体のスケジュールを決めているタスクの連なり」という意味です。
もうすこし砕けて言うと、
「これとこれとこれのタスクが全て予定通りに終わらないと、全体のスケジュールが遅れてしまう！」
というタスクたちのことです。
カレーの例で言うなら、
・「材料を買う」→「肉と野菜を切る」
（肉と野菜を買わないと、それらを切ることができない）
・「肉と野菜を切る」→「肉と野菜を炒める」
（野菜を切らないと炒めることができない）
・「カレールーを加えて煮込む」→「皿に盛り付ける」
（煮込み終わらないと皿に盛り付けることができない）
がクリティカルパスです。
なので、それぞれのタスクの所要時間とクリティカルパスが分かることで、全体のスケジュールが自ずと決まります。
そして、ここで重要なのが、タスクの依存関係を断ち切ることです。
依存関係に見えて、そうではないタスクの連なりが意外とあります。
カレーの例で言うなら、
「肉と野菜を切る」→「肉と野菜を炒める」
これは断ち切れる関係です。
肉と野菜を全て切り終えないと、炒めることができない訳ではないですよね。
なので、
野菜を切る→炒める→炒めている間に肉を切る→肉を炒める
という流れで、タスクの依存関係を一部断ち切って進めることが可能です。
日常の仕事でもこういうことはよくあります。
例えば、ITサービスで言うなら、
「仕様書を作る」→「実装する」
です。
全ての仕様書を書き終わるまで、実装に着手できないという訳ではありません。
例えば画面数、必要ボタン、画面遷移図だけでも先に準備できていれば、実装を開始することはできます。
そうすることで、実装してもらっている間に、画面のどこにどの要素を置くか、という細かい仕様を詰めることができるのです。
このようにして、クリティカルパスを圧縮することができます。
▼スケジュールを組み、タスク管理シートを作る
タスクの見積もりが終わり、依存関係の整理も終わって、ようやくスケジュールを組むことができます。
スケジュールを組む時によく使われるのはガントチャートですが、
本書ではスケジュール管理も込みなら「プロジェクトマネジメントシート」を使うことをオススメしていました。
というのも、プロジェクトが進行すると予定通りに進まなくなることが多く、その都度ガントチャートを更新しようとすると相当な時間がかかってしまうから、という理由です。
そこで、もっと管理や変更がしやすい形として著者がたどり着いたのが「プロジェクトマネジメントシート」でした。
百聞は一見にしかずということで、プロジェクトマネジメントシートとはこんなものです。
「誰が、いつまでに、何をするのか」の最新状況がひと目で分かる表になっています。
「タスク管理シート」とも呼べますね。
これなら、急なタスクが増えたり、減ったりしても表を1行2行書き換えれば良いのでラクです。
▼定例会を設定する
プロジェクトマネジメントシートが完成したはいいものの、それをプロマネが最新の状態に管理して、メンバーにも共有する場が必要です。
そこで、著者は定例会を毎週設定しましょう、と言っています。
定例会のやり方については後述します。
【タスクの実行】
プロジェクトを立ち上げ、ゴールを決めて、ゴールに到達するまでのプランニングをして、やっっと実行フェーズまで来ました。
プロジェクトをしっかり進行させるために、実行フェーズでもプロマネのやることは重要なことだらけですので、引き続き詳しく見ていきましょう。
▼関係者全員が集まって定例会を行う
定例会では、タスクの進捗確認を行います。
その際、なるべく関係者全員が集まった方が良いとのこと。
なぜなら、プロジェクトの情報をその場で一斉にアップデートできるからです。
関係者全員が集まれないと、連絡コストがかかりますし、人によって情報が古いままタスクを進めてしまっている人もいて、最悪の場合大幅な手戻りや修正が発生してしまいます。
こうならないためにも、なるべく関係者全員で情報をアップデートして、
次のタスクを認識の齟齬なく進行していきたいものです。
▼タスク管理シートとアウトプットの差分を確認する
そして定例会で行うことは進捗管理ですが、具体的に何をするかというと、
「タスク管理シートとアウトプットの差分を確認する」ということです。
プランニングの章でお伝えしたように、「アウトプットをモノで定義」していますから、「この〆切日までに、このモノが出来上がっているか、それはオーナーの求めているクオリティか」を確認すれば良いわけです。
確認する内容はこれ以上でもこれ以下でもありません。
▼遅れが発生した場合は是正措置を講じる
進捗確認した上で、〆切に対してモノが完成していなかったり、モノとしては完成しているけどオーナーが目指すクオリティに満たずに手戻りが発生したり、という場合が出てくるでしょう。
（プロジェクトでは今までに作ったことのない物を作る訳ですから、見積もった工数よりも時間がかかってしまったり、クオリティを上げるために試行錯誤したりして遅れることはままあります。）
その時にプロマネができることは、以下です。
・クリティカルパスに関係するタスクの場合は、依存関係を切る
・工数が余っているメンバーに割り振る
もし遅れているタスクがクリティカルパスに関係する場合は、
前述したようにその依存関係が一部でも断ち切れないかを考えてみましょう。
後工程のタスクを少しでも早めに着手できるようにすれば、〆切に間に合わせられるかもしれません。
※（これは僕の経験から言えることですが）依存関係を断ち切ろうとする時は、絶対に自分だけで「こう切れるかも」と判断せず、
依存関係のタスクに関係する人に「この部分だけ先に進めることってできますか？」と聞きましょう。
依存関係の切り方によっては実際の作業者が困ってしまうケースもありえますので、プロマネと作業者の間で具体的に話し合って折り合いをつけましょう。
また、依存関係を断ち切ったことで確認工数が増えてしまい、逆に時間がかかってしまうケースもあります。
これも気をつけた方が良いです。
そして、依存関係を断ち切ってもまだ〆切に間に合いそうにない場合は、
その他の余裕があるメンバーに仕事を割り振りましょう。
このようにして、タスクを〆切までに間に合わせる工夫を行います。
▼プロマネの権限で解決できない問題はオーナーに決めてもらう
でも、単なるタスクの遅れよりも、さらに大きな問題になる場合もあります。
タスクの遅れが、「依存関係を切っても、他のメンバーに割り振っても、どうしても遅れてしまいそう(または品質を満たせない)」という場合には、もはやプロマネで解決できる段階ではありません。
「品質・納期・コスト」のバランスを調整する段階に入っているのです。
そういう時には正直にオーナーにそれを伝えて、
「品質は保ちたいから〆切を遅らせる」
「〆切にはどうしても間に合わせないといけないから増員する」
などの判断をしてもらいます。
※オーナーに状況を伝えるのは「なる早」がベストです。
遅れることが分かっているのにそれを伝えないままだと、遅れれば遅れるほど修正分のコストがかかりますし、最後まで遅れて品質が微妙なままプロジェクトが終わると売上にも繋がらないですし、ましてやクライアントワークの場合は最悪契約違反になりかねません。
あとがき
さて、ここまでプロジェクト・マネージャーの仕事について大切なポイントをピックアップして説明してきました。
プロマネの基本スキルである「ゴールを決めて、プランニングをして、タスク実行すること」について理解いただけたら嬉しいです。
この本では、他にも「プロジェクトの振り返り」や、「想定外＆トラブルを切り抜けるノウハウ」、「孫社長流の新規事業立ち上げ術」など、ためになる情報がたくさんあります。
特に想定外についての話は、現場で使えるノウハウがたくさん詰まっています。
「プロマネの基礎的な話は分かったけど、でも実際そんな教科書みたいなプロジェクトばっかりじゃないよね、こういう場合もあるけど、その時はどうすればいいの？」
という悩みに答えてくれています。
今回は「プロマネの基礎スキル」の部分だけピックアップして話す予定でしたので、想定外の話はぜひ実際の本を読んでもらえればと思います。
ではまた。
この記事が気に入ったらサポートをしてみませんか？