#プロジェクト管理
進捗管理だけで納品が出来ると思うな。
複数のプレーヤーが長期間にわたって仕事を進めるプロジェクトにおいて、進捗管理は非常に重要だが、それだけで納品が上手く行くわけではない。そもそも、満足してもらえる納品物が出来上がるためのアプローチの設計が必要だ。
進捗管理をしていれば遅延やトラブルには気が付く。ただ、問題が起こってから対処できる打ち手の幅は狭い。問題は起こるべくして起こっているのであり、そもそものアプローチが失敗に向かうアプローチ
要望は先手を打って断る。出てから断るのは悪手。
プロジェクト管理で大事なことの一つに、作業範囲（システム開発ではよくスコープと呼ばれる）の管理がある。
プロジェクトを進めていくと、当初想定していなかった作業が必要になり、追加でやってくれないか、と頼まれることがある。必要なことなのだが、スケジュールの遅延、追加コストの発生、収益の圧迫に繋がる。
ただ、「契約の範囲外なので出来ません」と素直に断るのは難しい。まず相手は不満に思うし、そもそも契約
追いかけるゴールの数を絞る。
人間の集中力には限りがある。細かい仕事をたくさん追いかけていると、集中力が疲弊してしまって、大した成果を挙げられない。
プロジェクト管理も同様で、大小様々な事象に対して全力で取り組んでいると、すぐに疲弊してしまう。全方位的・網羅的に目を配ることは必要だが、把握した事象には濃淡を付けて管理することが重要である。
以前、時間管理のセミナーを受けたときに、「1日のうちに出来る仕事は、3つの大事と2つ
終わらない伝言ゲームから逃げ出す。
お客さんや上司からの依頼を外注先に伝えるとき、終わらない伝言ゲームに陥ったことはないだろうか。
お客さんから電話が来る
↓
外注先に電話で伝える
↓
外注先から不明点を質問される
↓
お客さんに再度確認する
↓
再び外注先に伝える
↓
・・・
専門性の違う人達が役割分担をして動いているので、ある程度の伝言が発生するのは仕方ないのだが、やり取りが終わらずにいつまでも続く場合、素直に伝書鳩を続ける
とにかく次のアクションを考える。
#プロジェクト管理 を一通り学んで、まずは全体の計画を立てなくてはと思いながら、なかなか計画を立てるタスクに取り組めない自分がいる。計画を立てるタスクは、脳のリソース消費が大きすぎて気が重いのだ。
そんなとき、GTD（Getting Things Done）という考え方に出会った。GTDは仕事を円滑にこなしていくためのノウハウで、頭の中のモヤモヤを解消するための様々な方法論が提唱されている。
指示・依頼の粒度を大きくしていく。
これは #プロジェクト管理 に限らず、仕事の指示・依頼全般に関わる話になるけど、指示・依頼の粒度は大きくしていくことが望ましい。
新人に任される仕事の範囲は小さいが、成長していくに連れて任される範囲は大きくなり、事業責任者にもなってくると、月次・四半期・年次の成果さえ出していれば良しとされる。
信頼性が高まるに連れて、責任の範囲も大きくなっていく、ということだが、別の見方をすると、指示・依頼の
前工程と後工程を検証する。
プロジェクトの作業に入り込んでしまうと、つい自分の作業ばかりを見るようになってしまうが、#プロジェクト管理 という視点では、前工程と後工程の繋がりを考えることは非常に大事。
例えば、パンフレットの制作をするとき、いろいろな人から原稿を集めて、デザイナーさんにパンフレットを制作をしてもらうときに、取りまとめの仕事が若手社員に振られることはよくある。
仕事を引き受けた時点では、もらった情報をまとめ
チェックの機会を事前に計画する。
前回に引き続き、#プロジェクト管理 について書く。
プロジェクトを進めていて、何よりも避けたいのが手戻り。ミスによるやり直しはある程度は避けられないけど、ちゃぶ台をひっくり返されるタイプの手戻りは非常に勿体ない。
例えば、3ヶ月後にイベントがあるとする。プログラムを考えて、日程を決めて、会場を押さえて、出演者との調整を始めて、企画書をコツコツ作り込み始めていったとしよう。
ある程度企画書が出
ゴールから逆算する。
今日からしばらく、連続シリーズで書いてみようと思う。テーマは #プロジェクト管理 について。
プロジェクトとは、ある目的を達成するために期間を定めて行う仕事のことを指す。その反義語はルーチンで、仕事の主体がなくならない限りは永続的に行い続ける仕事。
これまで社会人になって関わってきた仕事は、ITコンサルティングも、製造業のマーケティング支援も、観光のアクティビティ商品開発も、どれもプロジェクト