モチうめぇ。ピザうめぇ。
Introduction
プロジェクト・マネジメントという概念やその実行技術というものは、 業界や立場、そしてチームで仕事をするか/個人で仕事をするかという違いを超えて必要な知識だと思う。
(学校で教えてもいいくらいだと思う。道徳や総合学習よりよっぽど健全な社会の形成に役立つだろう)
どうやって仕事を適度な作業単位に分解しどうやってスケジュールに落とし込むのか、
そしてどう進捗を管理していくか、というのは(やや大仰な言い方だけど)人生のコア・スキルであると思うのだが、 意外と誰も教えてくれないのである。
ただ、PMBOKやP2Mなどの規格となるような知識体系はややとっつきにくく、 実際の使用シーンに応用しづらいきらいがある。
その点、日揮にお勤めの佐藤氏は、ブログ(タイム・コンサルタントの日誌から)や個人サイト(マネジメントのテクノロジーを考える)において、実際にプロジェクトをマネジメントしていくうえでの、ノウハウや考え方、ツールの作り方・使い方に関して、業務経験で培った肌感覚に沿ったわかりやすい語り口で解説してくれている。正直めっちゃありがたい。
世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
その佐藤氏の著書である本書では、海外プロジェクトに抜擢された若手エンジニアが、
PMの達人である大学の先輩に、教えを乞うというストーリー形式でわかりやすくproject mangementの要点が解説されている。
(類似本にありがちな)「Xつのポイント」的な感じで列挙してくのではなく、実際の作業手順まで示してくれている点が白眉だと思う。
Amazonのレビューでも指摘されているが、本のタイトルが若干軽い感じ(意識高い系な感じ)なので誤解をうけてしまいそうなるのが心配になるほど、実用的な本だ。
備忘用メモ
備忘用に重要だと思う箇所だけ抜き書きしてく。
プロジェクト = アクティビティの連関という世界観(p.52)
じつは、現代プロジェクトマネジメントの理論や技法は、1950年代に米国において、プロジェクトという大きな仕事の塊を「システム」と捉えたことからはじまったのです。
プロジェクトを「アクティビティ」と呼ぶ作業要素が違いに連関したシステムだと考えました。
そこから、重要な技法が次々に生まれたのです。
逆にいえば、ひとつひとつの要素のアクティビティがしっかり定義されているからこそ、しっかりとしたシステム=プロジェクトが成立する。
アクティビティの形式(pp.70-71)
- アクティビティとは、プロジェクトを構成する「部品」である
- アクティビティの具体的構造とは、インプット・アウトプット(成果物/完了状態)・リソースと指示・報告である
- なんども似た形のもの繰り返されるようなのPJTについては特にアクティビティ・リスト(=WBS辞書)を作る必要がある。これは仕事のBOM(部品表)のようなものである。
だれでも正しいWBSを作れる方法(pp.75-)
本全体のキモとなる部分かもしれない。
WBSの作り方は、成果物の分解構造からアプローチする方法(P-WBS)と、作業フローに沿った仕事の機能的な分解から作る方法(F-WBS)が存在する。
どちらも有力な方法*1だが、この本では両者の考え方を組みあわせることでアクティビティを洗い出す方法を推奨している。
紹介されているWBSの作成手順は以下の通り。
- プロジェクトの「成果物の構造図」をつくる(→P-WBS的発想)
- プロジェクトが最終成果物にいたるまでの仕事の「プロセスの構造図」をつくる(→F-WBS的発想)
- 両者のマトリクスを作成する
- マトリクスのマス目(=最小単位のアクティビティ)をグループ化して、適正なワークパッケージを形成する
- マネジメントの分担を意識して、ワークパッケージに整理番号をふり、WBSに構造化する。
- 各ワークパッケージのインプット・アウトプット・必要リソースを、アクティビティリストに記述する(=WBS辞書の完成)
実際の作業イメージも本のなかでは示されていて、とてもわかりやすかった。
会社によってはF-WBSのコード体系が共通で整備されていて、そのコードが社内言語化されているし実績もコード別に管理されている、というエピソード(おそらく佐藤氏の勤務先の日揮のことだろう..)も興味深い。
「一回限りの仕事=Project」をマネジメントするための知識体系ではあるけれど、
それでも共通化できる部分のマスタを整備して、練度を高めて高速化するのがこういった技法のもうひとつの使い方ではないか。
スケジューリングの方法(pp.115-121)
クリティカル・パス法の説明などの部分である。
- アクティビティリスト上で、各アクティビティに対して「先行アクティビティ」が何であるか明確にしておく。
- アクティビティリスト上で、各アクティビティの所要工数が定義されている
- プレシーデンスダイアグラム(Precedence Diagram)を書いて、順序関係を図示する
- 一番はじめのアクティビティから後続のアクティビティに向かって、最早着手日と最早完了日を順番に書き込んでいく(ここでクリティカル・パス*2がわかる)
- 最後のアクティビティから前のアクティビティにさかのぼっていくように、最遅完了日と最遅着手日を画定していく
ちなみに4は「フォワードスケジューリング」、5は「バックワードスケジューリング」と言う。
いきなりガントチャートとか引く前に、順序関係を図示したほうがいいよね、っていう話。
クリティカル・パスの短縮化の定石(pp.122-125)
どうしても納期を短縮したいときには、
- ゆとりの集中化(個人がもっているバッファを集中管理した上で削減する)
- 並列作業化
の2つの方法を使う。前者はチーム・プレーのときのみ使えるワザで、後者がより個人単位の仕事にも用いやすい。
クリティカル・パス上のあるアクティビティの完了が次のアクティビティの開始条件になっているとき、
実は先行アクティビティを100%完了させることが、次のアクティビティに必要でない(例えば70%段階まで仕上げられれば次に移れる)場合がある。
こういった場合に、先行アクティビティを構成するいくつかの作業のうち、後続アクティビティに必要な部分のみ完了した時点に最早着手日をずらす、という方法をとる、というのが「並列作業化」が意味するところである。
(実際にこういった変更を施す場合は、後続アクティビティに必要部分とそうでない部分に分割して、別々のアクティビティとして定義し直すほうがスマートだろう。たぶん。)
このような操作を行った場合に、クリティカル・パスが別の経路にうつることがあるのでそれも考慮すべしである、とのこと。
この「並行作業化」は大人数が関わる共同作業としてのプロジェクトだけでなく、個人で行なっている様々な仕事を高速化するための方法論としても有効だと感じた。
当然視されているタスクA→タスクBというフローを、タスクAをa1, a2, a3と分割することによってa1→a2→B(並行してa3)といった感じに短縮することができないか常に検討する姿勢が重要だろう。
工程表への追記によるスケジュール管理
・なんかかっこいいところ
工程表は、航海士にとっての海図に似ています。
工程表もつくらずにプロジェクトを始めるのは、海図を持たずに航海に出るようなものです。もちろん、多くの会社は最初に工程表をつくってはいるでしょう。
ただ、それを最後までアップデートせずに使い続けるところも少なくないようです。
ちょうど、航海に出たけれど、海図に自船の現在位置や進路や速度をいっさい記入しない航海士のようなものですね。
(p.163)
・ガントチャート上で進捗を示すときは、「イナズマ線表記」か「二重線表記」のいずれかを使う。
(→後者しかなじみがなかったので、イナズマ線表記のほうが直感的でいいなと思った)
・よりわかりやすくかつ可視的・参加的な方法として、F-WBS × P-WBSのマトリックス上にそのままポストイットを貼っていって進捗を管理する方法もある(→これ結構いいな)
Conclusion
身も蓋もないけど、ちゃんと締め切りを守れるようにするためには、まずしっかりWBSを作ろう。
んで、いきなり天守閣をつくるのではなく石垣たるアクティビティをしっかり定義しようっていうのが著者の主張で、それは正鵠を射ている。
WBSを作るような思考習慣っていうのは、(ロジックツリーとかの広まりとともに)それなりにもう日本にも根付いてきたといえるが、
そもそもWBSのマスタとしてのアクティビティ・リストを整備するのが管理のためにも作業全体の高速化のためにも大事だぜっていうのが、佐藤氏の主張の特徴的かつ示唆的なところだといえる。
brevis.exblog.jp
brevis.exblog.jp
佐藤氏の最近のブログの記事(↑)でも指摘されているように、いきなり工程表を引いたり、
WBSを書き下すのではなく、まず「基本部品」たるアクティビティの定義がなされて、その組み合わせとしてプロジェクトを表現する、というのが本筋である。
Enjoy!