マネージメントログ

経緯

ここ一年ほど、社内のプロジェクトを横断的にマネージメントしていた。「トラブル続きなので、おれになんとかしてほしい」ということだ。ほぼ一年ほど経過したので、やってきたことや現状をまとめておく。

おれ自身、マネージメントの経験はあまりないが、そこらへんの有象無象のマネージャーより数段ましなマネージメントができる自信はあった。実際できていたと思うが、やはりうまく行かなかったこともいくつか出てきた。だがそこらへんは、おれは自分と向き合える人間なので、反省も改善もできない無能マネージャーと違ってきっちりと改善した。

うまくいかなかった大きな原因は、「自分が息をするようにやっていたことほど、他人に伝えるのが難しい」ということだ。「息をするようにやっていたこと」ほど、「他人に伝えないといけない」という発想にはならないし、そもそもどこまでをどう伝えていいかわからない。それをやれと言われても、「お前は息の仕方を他人に教えられるのか？」とか、ジョジョみたいなことを言い出さないといけなくなるだけだ。

フレームワーク化する

だからといって、それを伝えずに進めると、「確実にあるべきもの」がない状態が生まれてしまう (e.g. レビューが必要なポイントでそれが行われていない)。そこで、「誰が仕事を進めても確実に一定水準の成果物が上がってくる」ように、全体的にフレームワーク化した。おれが「やっていたこと」「求めていること」をすべてリストアップして、それをフレームワークとした。

これが劇的に効果があって、トラブル続きだったプロジェクトが目に見えて改善した。仕事を進めるのがもともと不慣れな人、単に経験不足な人も、フレームワークがあれば余計なことを考えずに、各工程の成果物に注力できる。彼らはフレームワークを構築する能力がないだけで、そこさえ補助してやれば高いパフォーマンスを発揮することもわかった。

テンプレ化する

具体的に「どうフレームワーク化したのか？」というと、単にテンプレを作っただけだ。以下のようなフォーマットで必要な分を並べるだけ。斜体のところを埋めていってもらうイメージだ。レビュー記録は、別途テンプレを用意してある。

なんとかドキュメント
- URL: https://…
- ドキュメント概要:
  - なんとかをどうにかするための手順をまとめた
- レビュー記録
  - URL: https://…
かんとか作業
- 作業概要: あれをこうする
- 作業手順書 URL: https://…
  - レビュー記録 URL: https://…
- 作業日時: 2019-04-10
- 作業者: Joekyo
- …

テンプレはチェックリスト

加えて「このテンプレ自体がチェックリストとして機能する」ので、このテンプレが埋まっていないということは、未チェックの項目がある、つまり「何かが足りていない状態」であるということになる。これが非常に強力で、何度も「考慮漏れや準備漏れによるトラブル」から救ってくれた。

テンプレはレール

まだ加入したばかりの経験の浅いメンバーにも、「テンプレを埋めるだけで OK です」と伝えると、なんの問題もなく仕事が進むようになった。テンプレがレールになっているので、その上を走っていけばいいだけだからだ。逆に言うと、テンプレの上を走るだけで、問題なく進んでいけるようにテンプレを改善していかなくてはならない。何かができていなかったり、足りていなかったりした場合は、即座にテンプレという名のレールを修正する。テンプレを埋めるだけで「あるべき姿」になるように、テンプレを使って誘導するのだ。これで誰がやっても、ほぼ同じレベルの結果が出てくるようになった。

「ほっといてもそうなる」ような仕組みを作る

多くの人が目にしてきたであろう「あれができていない、これが足りてない」みたいなことを、年がら年中メンバーに喚き散らしている無能マネージャーは、単にフレームワーク化やテンプレ作成の能力がないだけだ。喚き散らしている内容は、自身の無能さの自己紹介に他ならない。よくある「部下は上司の考えを先読みしてうんぬん」みたいな考えは、徹頭徹尾間違っている。部下が上司の考えを先読みして行動できるなら、その上司は存在自体が不要である。

おれ自身、そういった無能マネージャーを嫌というほど目にしてきたので、自分自身がそうなるのだけは絶対に避けたかった。少なくともおれにとってマネージメントとは、「ほっといてもそうなる」ような仕組みを作ることだからだ。

求めているものは各個人で違う。マネージメント上、必須のタスクがあるのならフレームワーク化・テンプレ化するべきなのだ。

ちなみに、上記のテンプレやそれを元にしたドキュメントは、すべて Scrapbox 上で作成されている。Scrapbox はマネージメントの基本である。

レビューページ

レビューすらまともにできていなかったので、ここも改善した。前述のテンプレを用意して、そのテンプレベースで進める。あらかじめ定義してあるチェックリストのリンクがテンプレ内に記載されていて、そのチェックリストを網羅しないとレビューが完了しないようなテンプレになっている。

レビューで指摘が入った場合は、

テンプレ内にその指摘内容を「1 指摘 1 項目」になるように箇条書きにする。
その際、指摘事項に ToDo とプレフィックスを付けることでタスク化し、
再レビュー時にそれらの修正内容の確認と併せて、
Done になっていることも確認する。

例えばこんな感じだ。

なんとか作業手順レビュー
- レビュー対象: https://…
- 概要: なんとかをどうにかするための手順をまとめた
- レビュアー: Joekyo
- 指摘事項
  - ToDo あれをこうする
  - ToDO さらにああする
  - Done どうにかこうにかする
- 承認:
  - 2019-04-01 まだ修正が必要です Joekyo
  - 2019-04-01 ToDo が残っています Joekyo

再レビュー時に ToDo が残っているということは、修正漏れがあるということになる。この仕組を導入してから、修正漏れがまったくなくなった。

ルールで縛るな、仕組みで縛れ

無印良品は、仕組みが９割　仕事はシンプルにやりなさい (角川書店単行本)

「マネージメントで一番ダサいのはルールで縛ることだ」みたいなことを言っていた人がいたが、まったく同感である。ルールは「運用コスト」と「メンテナンスコスト」が高すぎる。加えて「ルールを好む無能な連中」を引き寄せてしまう。

「あれをやってはだめ」「こうしないとだめ」ではなく、「あれができないようにする」「勝手にこうなるようにする」ための仕組みを作る。

ルールを最低限にとどめ、仕組みを拡大する。

業務フローに組み込む

ナレッジまとめページや、チェックリストを作っても、いざそれが必要になったときには存在自体を忘れていることが多々ある。要は「業務フロー上にないものは、存在しないのと同じ」なのだ。マネージメント手法とか、なんとか Hack 的なものも同様、それらを業務フローに組み込めないなら機能しないし、存在しないのと同じだ。

特にナレッジなどは、共有したところで「なるほど症候群」で終わる可能性がほぼ 100% といってもいい。共有することはもちろん大事だが、積極的に業務フローに組み込む努力をしなければならない。

言い方を変えると、「業務フローにないことはできない」である。「それは言い過ぎだ」と感じるのは、「個人の能力に期待しすぎている」だけだ。その期待が行き過ぎると、前述の「年がら年中メンバーに喚き散らしている無能マネージャー」になる。

逆に「相手の業務フロー上にないことを依頼してもうまくいかない」とも言える。このことを無視して、「なんでこんなこともできないんだ？」と文句を言っている人を見かけるが、単に「相手の業務フロー上にないことを依頼した」ためである。「業務フロー上にないことを依頼する」ということは、「依頼相手の個人の能力に依存した業務を依頼した」ということになる。できない人にはできないのだ (できない人が無能と言っているのではない。得手不得手があると言っているだけ)。

十字架を立てる

「トラブルが起きないことを祈っているが、いつもトラブルが起きる」みたいな話が出たことがあった。当然だ、十字架も立てずにただ祈っているだけだからだ。

彼らのやってきたことと言えば、要は「仕事を右から左に流していただけ」だ。もちろんそれが悪いこととは言わない。それがないと仕事は終わらないし、実際に会社を回してきたのは彼らのそういった努力だ。

ただ、それは結局「仕事を右から左に流していただけ」でしかないのも事実だ。それだけでは不十分で、「下から上に積み上げる」こともまた重要だ。具体的に言うと、自動化や非機能要件といった類のものである。これらをまったくと言っていいほど積み上げてこなかったことが、トラブルの間接的な要因となっていた。

要約するとこうだ。

仕事を右から左に流すだけではだめ
非機能要件的な施策を下から上に積み上げる
横と縦で仕事を進める

横(右から左)と縦(下から上)、これで十字架が完成する。必要なら前述のような無能マネージャーを磔にでもしたらいい。あとは祈るだけだ。

ちなみにおれは仏教徒なので、十字架には祈らない。

Scrapbox を活用する

Scrapbox - Realtime Knowledge Base - Capture ideas in context
Capture and link ideas instantly to simplify your projects and team collaboration. Notes, design, and code stay in context from one page to 10,000+.

コミュニケーションするな、コラボレーションしろ

「仕事はコミュニケーションが重要」とか言って、延々とコミュニケーションしてる人がいる。だが、本当に仕事に必要なのは「コミュニケーション」ではなく「コラボレーション」である。

かく言うおれも、これを徹底できていなくて、大きなトラブルを招いてしまったことがあった。それ以来、コミュニケーションではなく Scrapbox を使ってコラボレーションすることを徹底している。具体的には、全員で同じページ開いてみんなで更新することだ。「コミュニケーション」は行き違いや伝達漏れが発生しやすいけど、「Scrapbox でコラボレーション」ならそういったリスクを最小限に抑えられる。

コミュニケーションは機能不全の印なんだ。緊密で有機的につながる仕事ができないから、関係者のコミュニケーションが必要になる。部署間のコミュニケーションを増やす方法ではなく、減らす方法を探すべきだ。
── 『ジェフ・ベゾス果てなき野望』

ジェフ・ベゾスの言うことはいちいち正しい。

プロジェクトまとめページを作る

「プロジェクトまとめページ」は、プロジェクト運営に非常に有効だ。それを見るだけで全体像が把握できるし、入ったばかりの人にもやさしい。

このまとめページに求めるものは、

一覧性
網羅性

である。ここを目指して作成する。

とにかく Scrapbox に書く

まとめページに限らず、とにかく「Scrapbox に書く」ことを啓蒙し続けてきた。とりあえず「Scrapbox を検索したら見つかる」状態に持っていくことだ。いまだに「情報を Slack で通知して情報共有したつもりになって、あとから情報を探して慌てる」パターンが見受けられるけど、それでもだいぶ「Scrapbox に書く」人は増えてきた。Slack は通知であり、情報共有ではないのだ。

先日、「議事録すらまともに取らなかったプロジェクトが、ミーティングが開始されると同時に即座に Scrapbox を開いてコラボレーションを開始した」光景には、大きな感動を覚えた。

マンパワーの排除は圧倒的正義

これはいまだに不完全だけど、いま進めているやつがうまくいけばだいぶ改善できそうでほっとしているところだ。

とはいえ、「話をしているといつのまにかマンパワーで解決する方向に進んでいる」ことが多々あるので、そういうときは常にストップをかけるようにしている。

手を動かす人だけが正義

正義を否定しない

もちろん「無駄にマンパワーを使え」という意味ではない。これが大前提で、これを踏まえて。

作業しないことには仕事は進まないので、どうしても「手を動かす人」は必要だ。また自主的に問題を解決しようと手を動かす人もいる。

物を作る人
自動化する人
情報整理する人

もろもろの「手を動かす人」のことである。

ここで重要なのは、「手を動かす人だけが圧倒的な正義」ということだ。それをしないと仕事は進まないし、問題も解決しないのだから当然だ。

加えて「手を動かす人」の逆が、多くの人が目にしたであろう「ただ文句を言うだけの人」である。

「手を動かすことが正義」であり、「手を動かす人」に対して「ただ文句を言う」ということは、「正義」を否定することに他ならず、すなわち「悪」である。

手を動かす人を否定すると自主的に動かない状態に最適化される

「手を動かす人」が、多少ずれたことをしていても大目に見るべきだ。どうしても気になるなら、フレームワークを改善して誘導したらいい。

手を動かして文句を言われるなら、結果的にその組織では「なにもやらない」が正解になる。最終的には「だれも自主的に動かない」状態に最適化される。このことを理解せずに、無邪気に文句を言う人を見かけるが、見つけ次第止めさせるべきだ。

おれはそれを自分がやらないように常に意識していた。なぜならそれは、「自分が悪人になるに等しい行為」だからだ。

だいたいこんな感じで進めてきた。やってきた内容はほぼ上記のとおりだけど、ひとつ付け加えておきたいことがある。「自分と向き合えていないときほど失敗する」ということだ。無能マネージャーが失敗している原因はそこにあるし、それはおれも変わらない。

逆に「常に自分と向き合って進めていけばいいだけの話」でもある。本当に単純で簡単な話だ……。