a box of chocolates

You never know what you're gonna get.

プロジェクトマネジメント力を自己採点してみる

プロジェクトマネジメントについてすごく良いエントリがあったので、自己採点しつつ、実践できているところ/できてないところをメモ。
点数は感覚値です。
僕と一緒に働いている方、お前そこ違うだろというツッコミあれば直接言ってください。


元ネタ : http://ponponpainnow.blog.fc2.com/blog-entry-252.html


ポリシー

  1. 全てのメンバーが目的・段取りのわからない仕事をしない/させない。
  2. プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。
  3. プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。
  4. プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。
  5. リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。
  6. みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。
  7. 人は一人一人別人であり仕事に対するスタンスは様々だが、ほとんどの人にとって仕事はあくまで生活の手段であり、生活のイベントより大切な仕事のタスクなんてないと考える。
  8. 業務システムの開発でどんだけ失敗しても人は死なない。気楽にやろう。最も大切なのは人の心。なるべく楽しくやるべ。

60点。
目的・段取りが分からない仕事をさせないように、プロジェクトの目的やタスクレベルでの目的を伝えているつもりなのですが、徹底はできてないのが現状です。あと、段取りについてはその粒度(どこまで細かく伝えるか)を担当者によって変えているつもりなのですが、うまくいかないときもあって試行錯誤を繰り返しています。
リーダーとメンバーがフラットでオープンな関係を築けているかなぁ。僕はそのつもりだけど、この辺は相手があってのことですからね。
生活のイベントより大切な仕事のタスクはないというのも、仕事に熱中し過ぎているとつい忘れてしまいがちなので、気をつけないといけませんね。

フラット&オープン

  1. リーダー、サブリーダー、メンバーはたんなる役割であり、対等に仕事を譲り合い奪い合う関係である。
  2. 役割に関係なくお互いになんでも言い合える関係を作ることが最も大切。
  3. リーダー自身が自由で本音な発言をすることでしかフラットな関係は作れない。
  4. 全ての情報を全てのメンバーにオープンに。基本的にはメール・メッセージは常に全てのメンバー宛に。
  5. チーム内に何してるかわからない人がいたり、一部の人しか知らない事情があると、とても雰囲気が悪くなる。
  6. 見積り・計画・スケジューリング・アサインは全員参加で。

70点。
なんでも言い合える関係をつくることは大事ですが、そこでのコミュニケーションで意図しない対立やすれ違いが発生するのは防ぎたいところです。
僕は正直に本音で話をしているつもりだけど、上手く伝わっているか不安になるときも多いです。
一部の人しかしらない情報というのは極力なくしている(事情がないかぎり)つもりなので、その辺は実践できてるかな。仕事に関するやりとりは、IRCとかSkypeとかでログを残してあとから参照できるようにしています。
見積もり、計画、スケジューリング、アサインは、全員参加ではやっていないですね。メンバーの意見を聞くことも多いですが、まずはディレクターがざっくり決めるみたいなやり方をしています(けどこのやり方は属人性が高いので、やっぱり仕組みとして何か用意されている方が良いですね)。

スピード&フレキシビリティ

  1. やってみないとわからないことの方が圧倒的に多い。トライ&エラー&リスケを繰り返す。スモールスタート&リスケジュール。
  2. 考えてもしかたないことやわからないことを考えない。下手に予測するより聞いたり試したりする方が早い。
  3. 早く失敗することは遅く失敗することよりも何倍もよいことである。
  4. スピードとクォリティは反比例する。どんな要求にもまずは素早く対応する。
  5. リーダーは自分の作業に集中していてもメンバーからのアクションにはすぐ応える。「今いいですか?」の答えは常に「YES」。メンバーを待たせてはいけない。

80点。
スピードは個人的には意識しているところです。
どんな要求にも素早くというのは、前職の先輩がそういうことを教えて叩き込んでくれたのが役に立っている気がします。
「面倒だからちょっと後でやろう」と思ったら、そのタスクはすぐに着手するようにしています。「面倒だから」という理由でいちど先延ばしにしてしまうと、次なかなか着手するマインドになりにくいから、という経験からの判断です。
リーダー(管理者/ディレクター)として、メンバーからのアクションにすぐ応えるというのは実践しているつもり。基本メンバーの生産性優先でいきたいです(だからリーダーが重要なタスクを握っていてはいけない)。

スケジューリング

  1. 日々リスケする。プロジェクトの初日に完璧なスケジュールが引けるはずがない。実態と乖離した変化しないスケジュールは失敗の素。
  2. スケジュールとWBSは似て異なるもの。スケジュールは見易さ扱い易さが命。メンバーが手元にスケジュールを持っていないプロジェクトは失敗する。
  3. スケジュールには、全てのタスクと空き工数を掲載して常に現状に合わせた状態にしておき、現状の把握と未来の計画が最もやりやすい状態にしておく。
  4. どの時点でもどれだけ未確定なことがあっても、実際に全体のスケジュールを引いて実名でアサインしてリソースの過不足を確認することは重要。
  5. スケジュールの進捗状態は常にオンスケになるため、当初の計画との差異や稼働状態の管理は別途行う。
  6. リソースの状況に関わらず必ずやるべきことと、リソースから逆算してやれる範囲でやることを区別すること。
  7. スケジュールを変更する時は必ず担当者と話して一緒に考えること。
  8. 森を見ずに木に手をつけてはいけない。木を見ずに森を見積もってはいけない。

75点。
何をするにもまずはざっくりスケジューリングする、というのは前職で身につけたスキルだと思っています。
たとえ精度がいまいちでも、まずは修正するたたき台がないとプロジェクトは暗闇の中、どの方向にどのくらいのスピードで進んでいいか分からないですから。
スケジューリングについては最近ではRedmineとかTracとか、進捗を管理できるツールがオープンソースでいいものがたくさん公開されているので、そういったものを導入すると捗りますね。
今のチームではホワイトボードを2つ使って、2ヶ月くらいのカレンダーを書いて、マイルストンやお休みの予定などをだれでも常に見られるようにしています。

アサイ

  1. 一人一人の特徴や好みに合ったアサインをすることはとても重要。
  2. 全てのメンバーが自分の役割と他人の役割に納得できるようになるまで見直す。
  3. プロジェクト期間中に成長したり変化するメンバーもいる。最後まで柔軟に変更する。
  4. 経験年数や業務知識よりも、頭の良さや心の強さや柔軟さを重視する。前者は変わるけど、後者はほとんど変わらない。
  5. ダメな人をイイ人の上につけない。年齢や役職を無視する。新人が入社初日から旧人より仕事ができることもある。
  6. 「どんな仕事でも長時間かけても平気」「面白い仕事なら長時間かけても平気」「どんな仕事でも長時間は嫌」という仕事に対するタイプを意識する。
  7. アサインに関してチームとメンバーの利益が一致しないことはよくある。ありのままをメンバーに話すこと。
  8. 本人がその役割を好きかどうかはとても大切。
  9. チームと個人に明確に責任を持たせる。
  10. 各カテゴリのチーム内の権威が自然にチームリーダーをするのが望ましい。
  11. 適材を適所に。それが全て。適材がいなければ始めてはいけない。
  12. 要件定義〜設計フェーズはできるかぎり少数精鋭を保つ。手空きのメンバーに仕事をまわさなければならない状況になると重要な初期の成果物の品質が格段に落ちる。

70点。
アサインは、プロジェクトのリーダーとしては最も気を使うべきところかなと思っています。
とはいえ、メンバーに最適化された仕事ばかりでもないので、個々のマインドや成長指向などを考えて割り振ったりしていますが、個人的には反省すること(このタスクはこうしておけばよかった)も多いです。
あんまり属人的にタスクをアサインし過ぎていると、タスクに対する属人性が高まりまくって誰も引き継げなくなってしまいますし、かと言ってフラットにアサインしすぎると効率も落ちるし、アサインされたメンバーもなかなかモチベーション高まらないと思います。要はバランスだと思いますが、難しいですね。

プライド

  1. 全ての人には美意識や価値観やプライドやこだわりがある。それをできるかぎり尊重し傷つけないようにする。
  2. 人が一生懸命話をしてる時にはなるべくさえぎらない。ため息をついたりしない。
  3. 「ダメじゃーん」と言った方ががんばる人もいるし「よくできました」と言った方ががんばれる人もいる。
  4. ほめる時はみんなの前で、注意する時は一対一で。
  5. 短期的な効率よりもやる人の気持ちを優先する場面も多い。

75点。
ここに書かれていることもまったくその通りなのですが、いざ実践しようとするとなかなか難しいです。
自分ではそうしているつもりはないのに、相手から見るとプライドを傷つけられているように感じてしまうというのはよくあることで。常に、今自分が相手からどういう風に受け取られているかは意識しておきたいです。
特に注意するというのは難しいです。
自分としては注意ではないのに注意と受け取られたり、注意しているつもりがそう受け取られなかったり。

コミュニケーション

  1. チーム全体で話す。数人で話す。一対一で話す。それを上手に使い分けること。
  2. 状況によって話がぶれないようにすること。相手によって話を変えてはいけない。
  3. 常にメンバー全員の気持ちを知っておくことは大切。定期的に一対一で話すなど。
  4. 常に明るく楽しく。仕事に負の感情を持ち込まない雰囲気を作ることが大事。
  5. 必要な話を必要なレベルで必要な人にする。相手が望んでない話を理解できないレベルでしてもムダ。
  6. 神経質な人にはおおらかに、おおらかな人には神経質に、楽観的な人には悲観的に、悲観的な人には楽観的に。
  7. 仕事でミスした人に「ミスしただろ!」と怒っても百害あって一利なし。原因や対応や予防策などを一緒に考えることが重要。
  8. 人や仕事をなめてると感じられるメンバーを見つけた時だけは厳しく。なめられてもなめてもダメ。
  9. 仕事も遊びも類友ではあるが、できるかぎり負の影響が出ないようにする。
  10. 沈黙を同意と思ってはいけない。多くの場合、沈黙とともに問題が潜在化する。
  11. 議論の対立は失敗ではない。対立を敵視すると自由な議論ができない。
  12. 会議はアジェンダを配布し、アジェンダ以外の内容については議論しない。それによって出席者を減らすことができる。

85点。
大項目の中で、僕が一番自信が持てるのはこの項目かなと思います。が、それでも実践できてない部分はありますね。
人や仕事をなめてると感じたときだけは厳しく、というのは実践したいですが、何がどうまずいのかをちゃんと説明するのが難しいなと思っています。
沈黙を同意とは思っていないけど、沈黙からうまく話を引き出すというのがなかなかできないです。
コミュニケーションについては別のエントリにしたいと思います。

クォリティ

  1. 目的、内容、責任の所在、〆切、質重視かスピード重視かなどは常に明確に。曖昧さを徹底的に排除する。
  2. 必要のない冗長性を排除する。なにも考えずに簡単にまわる仕組みを作ること。記入しやすく見やすい進捗管理表とか。
  3. 成果物・タスクの粒度に注意する。一つ一つが大きいと数が減って管理しやすい。小さいと数は増えるが柔軟にアサインできたりする。
  4. 最新の問題が最優先ではない。最古の問題が最優先でもない。発生順と優先順位に関係はない。
  5. 頑張りや心がけではなく工夫と仕組みで救う。

70点。
QCDのどこを優先すべきかは、常に伝えるようにしているつもりだけど、できてないときも多そう。
簡単にまわる仕組みを作るのは賛成だけど、自分が持っているタスクを簡単に回す方法を作るのが苦手な気がします。

コスト

  1. なにかを作るコストとそれを利用するコストのバランスには細心の注意を払う。
  2. 〆切ぎりぎりに慌ててやるのが一番コストが低い。意識的に上手に利用すること。
  3. メンバーの作業を遮る度に生産性はどんどん落ちていく。
  4. 短期的に生産性を上げる方法はない。プレッシャーをかけても思考は速くならない。過度の残業(短期を除く)は生産性を落とす。

70点。
締め切りぎりぎりに慌ててやるのが一番コストが低い、というのは言われてみるとそうですね。常にそうだと困るけど、意識的に使いこなせるようになると良さそう。
作るコスト、利用するコストのバランスは、ディレクターとしては常に意識しています。

リスク

  1. フラット&オープンの実現が最大のリスク管理(メンバーからのアラート頼み)である。
  2. 問題が起きた時は何度も「なぜ」を繰り返して根本的な原因に到達するまで対処しない。
  3. 知らないことが問題になることより、知っているつもりで誤解していることが問題になることの方が圧倒的に多い。

60点。
リスク管理はなかなかできていないです。
問題が発生したときに根本的な原因に到達するまで対処しない、ということはできてないかなぁ。根本的な原因に辿り着く前に対処するべきこともあるし、根本原因までたどりつくためにはそれなりに振り返りの技術も必要だと思っています。

リーダーシップ

  1. 「いいからやれ!」というのは通用しないし、それを言う人もそれで動く人も信用してはいけない。
  2. 正直に誠実に。自分のミスは素直に認める。公平にはできないけどできるかぎり公正でありたい。
  3. リーダーだけは結果責任。正しくても結果がダメなら意味がない。
  4. 常に問題や誤りが起きるのが当たり前。要件も見積りも常に変化するのが当たり前。問題や誤りや変化に対応することがリーダーの最も大切な仕事。
  5. 過度の残業の発生はマネジメントの失敗をメンバーに救ってもらっているということ。残業は悪ということを徹底する。
  6. 平和だったらリーダーはヒマなのが正しい。メンバーが忙しくなる頃にはリーダーの仕事のほとんどは終わってるはず。
  7. リーダーの笑顔は義務。加えて絶対にくじけない胆力。いつでもヒマで上機嫌が理想。
  8. どれだけオープン&フラットを実現しても、管理者は同僚ではないし純粋なチームの一員にはなれない。これはしかたない。
  9. 個人の評価は難しく苦しいことが多いが、厳しく明白に成果の差をしっかり反映するように努力すること。
  10. 問題が起きた時には必ず先頭に立って矢面に立つ。絶対に逃げてはいけない。結果が伴わなくともその姿勢がチームの雰囲気をよくする。
  11. 外部からの雑音を遮断することは難しい。一つ一つ理論的に検証してメンバーと共有する。
  12. 旧来の悪習は自分以降の代には持ち越さないという強い意志を持つ。

65点。
リーダーの笑顔は義務、了解です。いつでもヒマで上機嫌な上司になりたい。
そして管理者は同僚ではないし純粋なチームの一員にはなれないんですよね。そうですよね。しかたないですよね。
旧来の悪習は自分以降の代には持ち越さないという強い意志は、僕にはないので、今後精進していきます。

ソノホカ

  1. 数値はたんなる道具であり、現場の判断の材料であったり後を追うもの。数値を計測・記録する事務作業はマネジメントの本質ではない。
  2. ウソはあらゆる面でものすごくコストの高い最悪の手段。
  3. 夕会は人気がない。朝会か午後会で。
  4. 人は変化を憎悪することが多いし、変化への基本的な反応は論理的なものではなく情緒的なものであることが多い。
  5. ハラスメント系の問題は何もしなければ絶対に見つからない。発見するための仕組みを用意すること。

60点。
数値は道具、判断の材料、その通りですね。
夕会は人気ないんですね。朝会か午後会か。今の職場では朝会で定着していますが、前の会社を辞める直前は夕会を定着させていたなぁ。それぞれメリット・デメリットありますが、夕会はそこで仕事を振り返って帰りやすくする(あるいはどのくらい残業するか認識を合わせやすい)という効果がありました。

クロージング

  1. 評価や反省は厳しくごまかしなく。それが最も本人のためになる。
  2. 反省会は必須。記憶が定かなうちに他者も交えて反省・改善をしないとせっかくの経験がムダになる。
  3. 反省会で、全員がオープンにフラットに悪い部分も含めて相互を評価し合えたら、そのチームはうまくいったということ。
  4. 全ての項目が○な人はいないし×な人もいない。固有のミスや特定のカテゴリで人を評価しない。全期間を通したトータルで評価する。
  5. 打ち上げは必ずやる。絶対にやる。やる。

50点。
反省会、なかなかできてないなー。以前にやったときは、いい振り返りが得られて、チームの運用方法なども多少改善できたので、もっと定着させていかないといけないなと思っています。
チームがうまくいったかどうかが、全員がオープンにフラットに悪い部分も含めて相互評価できたら、という視点はいいですね。
前の会社のときのことを思い返すと、ちゃんと仕事を振り返ることができるチームは、雰囲気も良いし、チームとして優秀だったと思います。
打ち上げはやりましょう。打ち上げましょう。打ち上がりましょう。

おまけ(メンバーの休暇について)

  1. メンバーが休みたいと言ったら全てノータイムでOKする。
  2. ちゃんと考えられる人は、ちゃんと時期などを考えてるから問題ない。
  3. 休みたい人を無理矢理引き止めてもいいことがない。

80点。
一応実践しているつもり。休みたい人を引き止めてもいいことがないのは、自分に置き換えて考えてもまあそうですよね。
普段からスケジュールについて話すときに、この時期に忙しくなりそうみたいなことをメンバーと話しておくと、メンバー側も休みを取るときに気にする要素が減るかなと思っています。


以上、自己採点してみましたが、まあぼちぼち、普通のマネージャーという認識であります。
そんな僕と一緒に働いてくれるエンジニアとデザイナを募集しております。
興味がある方は以下のページを参照の上、ぜひエントリーしてください!

株式会社はてな

追記 2020/11/21

最新版がkindleにて公開されています。
(作者の方からコメントいただきました!ありがとうございます!)