読者です 読者をやめる 読者になる 読者になる

なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

ガントチャートを書く文化がないところは、ほんとに書かないんだな。

わりと大きめのSIerに居たり、小さい会社のコンサルに在籍しながら大きめの企業相手のプロジェクトに関与したり、事業会社の企画部門で社内プロジェクト回したりして、その後、今のベンチャー企業に移って来たわけですが、仕事の管理の仕方って、ピンキリなんだな、ってのを改めて感じています。


CMMIなんて小難しいことに踏み込む以前のレベル分けとして、こんな感じになるかなーと。

 

5.WBSガントチャート(線表)を書いて、誰がいつ何をするか、が明確に共有されている。
4.タスクリストに必要なことが列挙されており、組織として何をすべきかが共有されている。
3.マイルストーンだけは共有されているが、具体的に何をするかまでは各メンバーに委ねられている。
2.必要なときに必要なメンバーが集まって勢いで決めて、その勢いで行動する。
1.担当者が権限者と個別に会話して個別に進める。 

 

 

5.WBSガントチャート(線表)を書いて、誰がいつ何をするか、が明確に共有されている。

WBSガントチャートだと思っているひとー。

WBSはスケジュールじゃなくてタスクの構造化管理のことだからねっ。

ガントチャートから線表を外した左側だけでも成立するからねっ。

WBSに時間軸表現を組み合わせてチャートで表したものがガントチャートだからね。

 

腐ってもPMP試験合格経験者なので、ガントチャートのことをWBSって言うなーって思ったりしますが、その方向に勘違いしていてWBS書いて出せと言ってガントチャートが出てくる分には歓迎です。

 

WBSって言って通じるところは、プロジェクトマネジメントを一定レベル以上で理解しているところ。リトマス試験紙的な感じ。

 

WBSって言って通じなくても、ガントチャートって言って通じなくても、線表を書く文化があるところは、意識的ではないもののタスクマネジメントがそこそこできているところだと思います。書かないところはほんとに書かないし、そして案の定、、、な文化です。

 

4.タスクリストに必要なことが列挙されており、組織として何をすべきかが共有されている。

WBSガントチャートレベルまで構造化や時間軸・優先度管理等がなされていなくても、タスクリストがあって管理されていれば、管理レベルはだいぶ変わります。

 

いちいち線表まで書いてると、変更があったときの「管理のための管理資料の管理負荷」が高くなるので、機動性・柔軟性とスピードのバランスを鑑みて、あえてこのレベルにとどめておくことも多いです。


タスクリストとはいえ、せめて期限と担当者の項目くらいは用意しておきたいものです。

 

3.マイルストーンだけは共有されているが、具体的に何をするかまでは各メンバーに委ねられている。

マイルストーンは、期間ではなく、期限=デッドラインですので、マイルストーンだけでの管理は結構厳しいです。

 

マイルストーン=いついつになになにがあるよ!、からのー、そこまでに何をどんな順番で用意していかなくてはいけないか、がプロジェクト・マネジメントですので。

 

複数人のチームが組めず、担当者が実質一人で回しているような案件であれば、仕事の進め方は担当者個人に任されている、という状態でもあったりするので、マイルストーンの管理だけでもやっていけたりします。


また、そのプロジェクトに深くは関わらない程度の人に情報を共有するには、マイルストーンだけを伝えると、情報過多にならないので良いと思います。
情報過多な報告・共有資料は読み手がちゃんと目を通さなくなるので、結局、共有できてない(相手の認識に含まれない)事態を引き起こしかねないです。

 

毎日メールで報告してたのに、いざトラブルが起こった時に「俺は聞いてない」と言われる事件がつい先日ありました。(半泣)

 

2.必要なときに必要なメンバーが集まって勢いで決めて、その勢いで行動する。

まだまだ体制が未整備で、古参の一部が経営方針を握っている中小企業にありがちな体制です。

 

プロジェクトマネジメントいう概念自体が知られていない、存在していない可能性が高いです。


そうしたメンバーで会して議しても、そこで導き出された結論について記録を残さなかったり、参加していなかった人への共有プロセスが整ってないってことも多いです。

 

そして、結論と経緯を整理・記録してないので、3日と立たずに簡単に真逆の意見が吹き出したりします。

 

それを「中小企業らしい決断スピードと柔軟性」という耳障りのいい言葉で覆い隠して見て見ぬフリをしているところも多いです。

 

 

1.担当者が権限者と個別に会話して個別に進める。

立ち上がって間もない会社や、拡大期に入りつつも、仕事のやり方を変えられない古参幹部に見受けられます。

 

最初は人数も少ないし、メンバーの知恵を持ち寄ったところで分からないものはわからないから、まず動いてみて、それで見えてきた問題に個別に対応していく、その突破力重視のやり方は大事です。

 

 

ある程度の結果が出てくると、人もより優秀な人が採用できるようになります。


そして、さらなる拡大に向けて、色々なことを知っている人間を集めておきながら、結局そうした知恵を生かさずにいつまでも突破第一で進めて、目の前の落とし穴を全力で踏抜きに行くかのようにトラブルを起こし、あとからやってきたハイスキル人材に呆れられ、見放すように辞めていってしまい、なかなか会社が拡大しないという事態に陥り、原因作ってる本人が「XXX人の壁」とか言っちゃう。

 

 そんなレベルで運営されている事が多いです。

 

どれが絶対的正解って話じゃない

超重量級のプロジェクトマネジメントは、その管理ために工数もスキルも必要になりますから、置かれている状況、企業や組織の成長ステージ、個別の案件の状況によって、管理レベルを使い分けていいと思います。

 

MS Projectでも、チケット管理でも、ToDoリストでも、ポストイットでも、ポモドーロでも、タスクシュートでも、なんでもいいんです。

 

 

 

以上、仕事の管理の仕方・レベルって、いろいろだなー、って話でした。