お仕事のマインドについて、

• マネージャーはメンバーに自分の負担を分散し
• メンバーはマネージャーの仕事を奪いにいく
  

ことを目指すのが良さそうだと思ったというお話です。

いつものように、アンチパターンで検証してみます。

メンバーに負荷を分散しないマネージャー

こう書くと良い人にも思えますし、実際にこういう動きをする方は「良い人」であることが多いのですが、これをやってるとマネージャーとしてやるべきことに手が回らなくなります。
マネージャーといっても多くの場合はプレイヤー仕事を完全に切り離すことはできないわけですが、これをメンバーに渡せるか、少し意地の悪い言い方をすると、過去の経験を活かして手っ取り早く付加価値を出せる仕事を手放せるかは、特に新任のマネージャーにとっての最初の関門になりやすいものです。
さらに一歩進めると、渡されたメンバーが気持ちよく仕事ができる渡し方というものもあって、ここら辺も心得ている上司の下で働いていると、メンバーとしても仕事が楽しくなって互恵関係が生まれたりすることもあります。まぁ、実際にはそんなにうまくはいかないんですけどね。

メンバーの仕事を奪うマネージャー

本来メンバーがやるべき業務を、自分がやった方が品質が高い・早いなどの理由でやってしまうパターンです。
メンバーの人数が少ない時は確かに自分でやった方が早いこともあるのですが、メンバーが3人を超えてくるあたりで必ずマネージャーがボトルネックになります。この状態になっても、主観的には自分がやったほうが早く終わるように感じ続けてしまうのが難しいところですね。
こうなってしまうと、任せないからできるようにならない。できないから任せられない。という悪循環の始まりです。「うちのメンバーは能動的に動かなくてさ」と言ってますが、その原因はマネージャーの方にあるのかもしれません。もしそうなら「それこっちでやっとくよ」とか言ってる場合じゃないですよ。

マネージャーの仕事に関与しないメンバー

給与も役割も現状維持のままで良いのであれば、皮肉でもなんでもなく、マネージャーの仕事になんてものに関与する必要は全くないのですが、ここら辺を実現したいのであれば、マネージャーの仕事に積極的に関与しに行く必要が出てきます。
また、これはマネージャーがやる仕事だろ？と感じることを頼まれるということは、あなたが少なくとも潜在的にはマネージャー候補だという事でもあります。なので、望んでいないのであれば、この段階でその旨をはっきり伝えた方がいいと思います。
基本的にマネージャーの給与が非マネージャーより高めなのは、マネージャーの仕事がクソめんどくさいものだからです。知識やスキルで他を圧倒できない人は、このクソめんどくささを引き受けなければなかなか給与を上げるのは難しいってことですね。

マネージャーに負荷を分散するメンバー

大前提として、マネージャーはいざという時のバッファみたいな機能も担うので、いざという時はいいんです。それは、当たり前にすべきことだから。問題は、平時にこれをやっちゃうことなんですよね。
典型的には、

• 原案や仮説を持たずに相談する
• 依頼された仕事を完成させない（8割くらいの出来で終わりにしちゃう）
• 確認されるまで必要な報告をしない

とか。
マネージャーがいなくてもやっていることは、マネージャーがいる時にもやりましょう。

すぐに探せない

目当ての情報を探しだせないナレッジ管理は、当然使いものになりません。
こう聞くと当たり前のことなのですが、
・PDFにOCRをかけていない
・メタ情報が不十分/不正確
・検索精度が弱いシステム内に保存されている
・動作が遅いシステム内に保存されている
・フォルダの深いところに保存されている
みたいな形でそこそこ見かけることもあるのがこのパターンです。
変なシステムにきれいに保存するくらいなら、ファイル名の命名規則をきっちり決めてGoogleDriveに保存したほうがよっぽどマシだったりします。

優先度・重要度ががごっちゃまぜになっている

締結済み契約書のように重要度に差があまりない情報群であればほとんど気にしなくても良いのですが、玉石混交の情報を何も考えずに貯めても、そこに生まれるのはナレッジではなくゴミの山だったりしますからね。
依頼者と法務とのやり取りなんかが典型です。生のやり取りに価値があるケースはごく僅かなので、共有すべき情報を取り出して、そちらを蓄積するようにしましょう。

抽象化されていない

抽象化されていない情報は、再利用しにくい情報でもあります。
仕掛中の契約書案みたいなものが典型ですね。類似案件だからといって参考にしてみたら、交渉を経て譲歩した条項が入っていたり、個別案件特有のケアがされていたりして却って気を使う、みたいな経験は誰でも一度はしたことがあるはず。
雛形化（抽象化）して、具体的な事案から切り離すことで再利用しやすくしましょう。

余計な情報が書いてある

上記の3つは手を加えなさすぎて使えないパターンですが、逆に変に手が加わっているせいで使いづらいパターンもあります。
例えば、手順書以外の情報がたくさん書かれている手順書なんかが典型例ですね。知識をひけらかしたいタイプの人が暇だからといって作った資料に起こりがちなやつです。
目的のために必要な情報にしぼりましょう。

古い情報が残っている

情報は必ず古くなるので、古い情報が紛れ込むことは避けられません。問題は、古い情報が残り続けることです。
その原因の一つは、「古いな、これ」と気づいた人が、更新せずに閉じてしまうこと。
気づいた人が軽やかに更新できる仕組みを作って展開しましょう。更新のルールと判断者を決めるだけでOKです。判断者は別に部門長でなくてもOKだし、情報によっては担当=判断者にするのもありですよ。
そしてもう一つは、更新しづらい媒体で書いてある情報。
ナレッジ共有用途でパワポを使うのは、どうしてもその必要があるときだけにしておきましょう。情報以外に配置を気にしなければならず、ページ制限もあるので更新しづらく、情報が陳腐化しやすくなります。

今日が現職の最終出社日でした。
次の会社は来月からです。というか、来週からです。

今回は4年9ヶ月と自分にとっては異例の長期間在籍でしたが、要所要所で発生した組織再編とM&Aの影響で、職務経歴上の在籍企業としては新たに3社分獲得することができ、在籍企業獲得効率としてはなかなかだったのではないかと思います。
伝わらないとちょっと怖いので念のために申し添えておきますが、これは自虐です。こんなのが良いことなわけが無い。

なお、今度こそこれが最後の転職になるんじゃないかって気がしています。
もう誰にも信じてもらえないかもしれませんが、ここまで強い確信を抱いたのは、実に4年9ヶ月ぶりです。
今度は本当に、最後だと思いますよ。たぶん。

せっかくだから、うちのチームのどこが素晴らしいのかを書き残しておこうと思う。

やると決めたことを、きっちりやる

のっけから校長講話みたいなつまらないタイトルになってしまったけど、これを徹底できるチームは珍しいし、強いな、ということを改めて実感した。
タスク管理をAsanaでやろう。細かいタスクもAsanaに登録しようと声をかけたら、翌週からAsanaでタスク確認ができる状態になっている。ドキュメント作成を伴う案件管理は全部Hubbleにすると決めたら、もれなくHubbleに載ってくる。業務手順は口伝ではなくマニュアルで引き継ぐというルールを設けたら、マニュアルがどんどん作られて、更新されていく。
組織が方針を転換するときは、普通は船のようにゆっくり方向を変えていくものだけど、うちのチームは自動車のように「キュッ」とハンドル操作に即時反応して方針転換できる印象がある。

タスクがどんどん拾われていく

これは少人数のチームだから実現できていることだという自覚はあるけど、少人数のチームであれば常にこういう状態になっているわけではないということもまた事実なので、やはりうちのチームの良さの一つだと思う。
うちのチームの未アサインタスクは、基本的に立候補でアサイン先が決まっていく。なんとなく「これはこの人の案件だよね」というふんわりとした分担はあるけど、別に業務範囲を限定を掛けているわけではないので、今回は私がやっていいですか？というやり取りもよく発生している。
更に良いと思うのが、たくさん業務を処理する人に対する感謝がメンバーから出てくるということ。昨日ワークフローたくさん確認してくれてありがとうとか、今週タスクたくさん引き取ってくれてありがとう、とか。
こういう一言をちゃんと言える人と一緒に働けることは、とても素晴らしいことだと思う。

素直さと貪欲さ

法務未経験のメンバーが2人いるんだけど、この2人は1年でちょっとびっくりするくらいに色々なことができるようになった。
法務のバックグラウンドを持たないので知識面ではまだ足りていないけれど、逆に言えば、知識面以外については経験豊富な法務メンバーと比較しても全く見劣りしないんじゃないかと思っている。この異常な成長を可能にした要素は色々あるのだろうけど、一番大きかったのは素直さと貪欲さなんじゃないかと思う。
ダメ出しをすると、理由を確認して次に活かそうする。未経験の業務を「これやってみない？」と振ったら、負荷の状態で引き受けられない場合以外は「やってみます」と即答が返ってくる。
こういう優等生的なことだけでなく、「調子はどう？」と聞かれて、イマイチなときには「イマイチですね」と応えてくれるのも、マネージャーとしては本当に助かっていた。

どんどん進めていくが、勝手には進めない

当社の会議体事務局のタスク処理は並列処理が可能になっていて、15くらいのタスクを手分けして30〜60分で処理している。meetでつなぎながら各自別の作業をしている様は異様ではあるけど、同時に圧巻でもある。
作業中に判断が必要なポイントが出てきたら「これ、どうしましょう」という声かけがあり、その場で議論&判断がなされて処理されていく。
こんな感じで、会議体事務局のタスクだけでなく、日々の依頼対応も処理されていく。担当者が、ルールに当てはめて判断できるところはどんどん自分で判断して進めるが、ルールに当てはめて判断できないことが出てきたら、きっちり止めて、意思決定を求めてくる。だから、任せる方も安心して任せていられる。
もちろん判断を間違えることもあるけど、そんなことは担当者が誰であっても起こりうることなので、大した問題ではない。というより、この自律的な業務処理に水を差すくらいなら、多少の判断ミスなんて喜んでスルーしたくなるような気持ちよさを、うちのチームの業務遂行には感じている。

ほんとうに、素晴らしいチームだな、と思うよ。

現在の勤務先では、行動指針よりも細かくて具体的な「しぐさ」のガイドラインみたいな位置づけで、「日々の業務ルール」というものを明文化しているんだけど、「設けて良かったな」と思えるものと、「あまり意味なかったな」というものに分かれたので、振り返ってみようと思う。

良かったもの

催促やリマインドは、必要があれば、相手の状況を踏まえずに、いつでも、何度でもする

昨日リマインドしたから、連日はさすがに・・・みたいな遠慮は無駄の極みではあるけど、同時に自然な心情でもあるので、「やって良いんだよ」ということを明確に宣言する意味があったと思う。
催促やリマインドって、もらう方は基本ありがたいものだから、する方は遠慮する必要なんて全然ないんだよね。

急ぎの連絡、話した方が早い案件はすぐに電話やhuddleをする。事前調整不要。取れないときは受けた側がコントロールする。取らなかった/取れなかった場合はコールバックする。

法務全員が顔を合わせるのは歓迎会・送別会などのイベント時か、惑星直列みたいにたまたまタイミングが揃った時、みたいな現職では、どうしても非同期コミュニケーションを主にせざるをえないけど、話せば30秒で終わることも、slackだといつ終わるか読めないし、こういうのは大きなストレス源になってしまう（ちなみに、「slackはすぐ見てもらえる・返事をもらえることは期待しない」という業務ルールもある）。
リモートだと今電話して良いタイミングかはわからないので、これを明文化しないと、緊急時でもなければ電話やhuddleをするのはためらう人が多かったのではないかと思う。同時に、受ける方がスルーする選択肢を持っていることも重要だと思う。

謝らなくて良いことについて、謝罪しない。

このルールが必要なほど、着任当初は「すみません」がめちゃくちゃ多かった。謝らなくても良いことについて謝罪する場面のほとんどは、感謝に代えることが可能なので、セットで「謝る代わりに感謝していこう」って声掛けをしていた。謝られても全然嬉しくはならないけど、感謝されると嬉しいものだからね。

法務内では、共有してはならない情報以外、息をするように共有する/共有した≠認識された

情報の流量がかなり増えた。あと、情報の偏在も少なくなった。情報管理の手間も少なくなった。取りこぼしが拾われるケース（あれの話じゃないですか？みたいな）がちょくちょく発生した。
あと、情報の流量が増えた際に「前に共有しましたよね？」みたいな詰めが発生すると重荷になるので、後段も結構重要だったんじゃないかと思う（これは想像）

ワークしなかったもの

業務で参照する書籍は以下の条件（定価&法務書籍サブスクに収録されていない&買ったらslackで報告）を満たせば事前確認不要で購入OK

考えうる最も緩いルールにしたつもりだったんだけど、全然書籍購入は進まなかった。
むずい。

セミナーは、無料のものは業務と全く無関係でなければ事前確認不要で受講OK。有料のものも、業務上の必要性があれば基本承認するので迷わず申請する。

これもかなり緩いルールにしたつもりだったんだけど、全然セミナー受講は進まなかった。
むずい。

これまで、個人のタスク管理もチームのタスク管理も、イマイチしっくりくるやり方にたどり着けていなかったんだけど、最近になって個人としてもチームとしてもタスク管理がいい感じに仕上げってきたので、こうするともっと良くなるよ、というアドバイスを期待して共有。

個人のタスク管理

3行まとめ

1．ToDoリストで管理
2．ToDoには必ず期限を設定
3．ToDoリストは期日でソートし、今日やらなければならないことだけカレンダー登録

具体的な方法

1440分の使い方では、ToDoリストでタスク管理をしてもタスクは積み上がるだけなので、タスクを消化していきたければスケジュール帳でタスク管理せよと言われており、それは確かにその通りなんだけど、タスクの粒度が細かく、その数や追加頻度が多い人（つまりは、大抵の法務担当者）がGoogleカレンダーでタスク管理をしようとすると、あっという間に破綻してしまう。
そこで、ズンズンタスクを登録できるToDoリストと、消化の後押し力が強いカレンダー登録を組み合わせます。

Step1
タスクを認識したら即座に&深く考えずにToDoリストに登録

Step2
ToDoリストに登録する際に「必ず」期限も設定する
→後述のとおりリスケが発生しやすい管理方法なので、極力デッドラインよりも前の日にしておく

Step3
退勤前に、今日やりきれなかった業務を翌日にリスケする
→明らかに先で良い（登録時に期限設定をミスったもの）以外は、機械的に翌日にしてOK

Step4
リスケが終わったら、翌日期限のタスク処理のための予定を、翌日の空き時間にセット
→具体的なタスクごとに予定を分ける
→ざっくり「作業時間」みたいな登録をするのはNG
セットしきれなかったタスクは、翌日やれないはずなので、翌々日以降にリスケ。
→デッドラインが近いものは、翌々日以降に予定登録もしておくことを強く推奨

解説

ToDoリストとカレンダー登録のいいとこ取りをするのが狙いです。
カレンダー登録をおしゃかにする「ちょっといいですか？」が天敵なので、リモート向きです。
カレンダー登録に際して処理時間の見積りもすることになるので、作業見積りの精度が求められますが、すぐに慣れます。

この方法でタスク管理するのに適したツール

TickTick
・ショートカットキーでどこからでもタスク登録可能（Step1）
・「今日」「明日」「6/1」と打つだけで期限設定される（Step2）
・明日へリスケするボタンがある（Step3）
・期日でタスクをグループ化できる

チームのタスク管理

3行まとめ

1．カンバンでタスク管理できるツールを使う
2．カンバンは「アサイン待ち」「ToDo」「対応中」「待ち」「ルーチン」
3．本当に今やっているタスクのみ対応中に入れて、週次で厳密に進捗管理

具体的な方法

チームでのタスク管理は、「タスクがもれなく登録されない」「登録されたタスクについても進捗がシステムに登録されない」といった問題からなし崩し的に破綻してしまいがちです。
その原因はITリテラシの低さやチームワーク意識の低さといった個人の素養に起因するところがあることも否定しきれませんが、何より「タスク管理の効果をメンバーが感じられていない」ことが主な原因であることも少なくないように思います。
そこで、効果を実感しやすいタスク管理の仕組みとして、以下のような方法を現在試しています。
なお、契約案件などの細かいタスクをこれで管理するのは無理なので、それはCLMサービスなどで管理する前提です。

Step1：登録
タスク認識をしたら、とりあえず「アサイン待ち」にタスク登録
期限が先でも、タスク認識をしたらとりあえず登録
アサイン待ちやToDoが多くなりすぎた場合は、「いつかやる」というセクションを新設して、優先度が低い案件をそちらに移すのもあり（当社は作っている）

Step2：アサイン
即対応する必要があるタスクについてはアサイン担当者（マネージャーなど）がアサイン
登録者が自ら担当するタスクは、自分で自分を担当者にアサイン
週次のタスク確認ミーティングで、アサイン待ちの案件が残っている場合はアサインを検討
→着手する必要がないならアサインしなくてもOKだが、毎週確認はする
アサインされた担当者は、タスクを「ToDo」に移動

Step3：期限設定
デッドラインではなく、完了目安の日付を期限に設定
→デッドラインは説明欄に記載
重めのタスクはサブタスクにも期限を登録してマイルストーン管理をする

Step4：進捗管理1
担当者は、タスクに着手したタイミングでタスクを「やっている」に移動
他部署確認や決裁待ち、リリース待ちなどで法務の手を離れたタスクは「待ち」に移動
他の優先業務の発生などで対応できなくなったタスクは「ToDo」に戻す
週次のタスク確認ミーティングで、↑をやる
→リアルタイムでやってもOKだが、そうする必要はない

Step5：進捗管理2
「やっている」に入っているタスクについて、来週の進捗確認ミーティングまでにどこまで進めるかを担当者が宣言し、説明欄に記載
→担当者はGoogleカレンダーで宣言した処理を行うための時間を確保
同時に、前週の進捗確認ミーティングで宣言した「どこまで進めるか」の振り返り
→予定通り進まなかった場合は原因分析と、必要に応じてリスケ
→全く進まなかった場合は、「ToDo」への移動を検討

Step6：ルーチン処理
支払い処理や契約更新などの定期タスクの処理漏れがないかを確認
チームでルーチン業務を管理する必要がない場合は省略可

解説

週次のタスク確認ミーティングで、詳しく進捗確認するのを「今動いているべき案件」に絞ることで、ダレがちな進捗確認に緊張感がもたらされます。
かといって、進捗していないのはサボっているからではない（はず）なので、進捗がないことを責めるのは厳禁。むしろ、予定通り進捗した場合はそれを讃えて、無事完了に至った場合はみんなで祝福することで、タスク確認ミーティングの憂鬱さを和らげましょう。
また、進捗確認だけでなく、動いていないタスクやアサインされていないタスクを全メンバーの目の前に展開できることもポイントです。自分がアサインされない限り他人事になりがちな未進捗案件の山を見える化し、それを手分けして崩していくことを通じて、法務にかけがちなチーム感の醸成にも寄与してくれます。

この方法でタスク管理するのに適したツール

asana
多分、Trelloでも同じようにできるはず
・slackのslack commandでタスク登録&チャンネル共有ができる
　→すぐに登録できる
　→登録後の「これ登録したよ」の共有も簡単
・無料でチームでのカンバンの利用が可能
・期限と担当者をカンバンビュー上のチケットで確認できる（詳細を開く必要がない）

---

皆さんの会社は、どんな感じでタスク管理してますか？

新メンバーのオンボーディングの過程でダブルチェックについて認識合わせする機会があり、その時考えながら話していたこともあってちゃんと整理しようと思ったので、半年ぶりにブログを書いてみることにした。

---

ダブルチェックは●●ではない

ダブルチェックは、育成の手段ではない

ダブルチェックを育成の手段として位置づけてはならない。
もちろん、ダブルチェックを通じて学びを得られることに疑いはないし、ダブルチェックは業務の過程で自然に発生するものなので、人は誰しもダブルチェックを通じて成長することは疑いの余地はない。しかし、だからといってダブルチェックを育成の手段と位置づけられるわけではない。
炭鉱で石炭を掘れば筋肉はつくだろうが、炭鉱労働を筋トレと位置づける人がいないのと同じことだ。
ダブルチェックは、育成の手段としてはフィードバックを得られるまでのタイムラグが長すぎるし、そもそもフィードバックの網羅性も低すぎる。コメントもない修正結果から意図を汲み取れというのは時間の無駄だし、勘違いも生みやすいという意味でも育成手段としてはかなり劣悪な部類に含まれるのは疑いの余地はない。

ダブルチェックは、上司の安心材料ではない

上司が安心するためにダブルチェックを使ってはならない。
上司としては、自分が見ることで安心感を得られるのだろうが、部下の人数と上司の人数のバランスからして、上司によるダブルチェックがボトルネックになることは避けられない。
上司が安心したいのであれば、100%属人的な「自分が見る」という手段ではなく、「適切な能力を有する複数人がチェックする」というダブルチェックの仕組みにその根拠を求めるべきだ。もし、上司が常に最適なチェッカーなのだとしたら、それは育成または採用の失敗に他ならない。

ダブルチェックは、責任分散の仕組みではない

チェック依頼者は、ダブルチェックを受けたことを理由に成果物の不備の責任が軽減されると考えてはならない。
チェッカーは、自分がチェッカーであることを理由に成果物の不備の責任が軽減されると考えてはならない。
ダブルチェックに取り組む二人が同じレベルの責任感をもって取り組まなければ、ダブルチェックを行う意味は損なわれてしまう。

ダブルチェックは、能力を証明する手段ではない

チェック依頼者は、自信のない部分や迷った事項を積極的に開示し、チェッカーによる重点的なチェックを求めなければならない。
チェック依頼者は、修正された箇所がないことを喜んではならない。また、修正されたことを嘆く必要もない。修正された内容を確認し、納得したときは「なるほど」と思えばそれで良いし、納得できないときはチェッカーに質問すれば良い。

ダブルチェックは、自己主張の場ではない

チェッカーは、どちらでもよいこと、効果に影響がないことに口を出してはならない。
チェッカーは、根拠を明確に示せない修正をしてはならない。
チェッカーは、指摘事項がチェック依頼者の自尊心や自信にダメージを及ぼす可能性があることを忘れてはならない。

ダブルチェックは●●である

では、ダブルチェックとは何なのかといえば、成果物の品質を向上させるために行うものだ。
当たり前のことではあるけど、余計な枝葉がついていることが多すぎる。
シンプルにやっていこう。

法務の納期コミットは、昔上司から「何日でもいいけど示して死守しろ。営業がそれを前提にスケジュール組めることに意味がある。自分の都合ではなく、事業の都合を考えろ。」って言われたよ。

— KATAOKA Genichi (@katax) December 28, 2022

このtweetは、法務による売上への貢献を考える際のエッセンスを含んでいると思っているので、ちょっと膨らませてみる。

法務に限らずいわゆる間接部門は、原則として直接売上を建てないから間接部門とカテゴライズされるわけで、売上への貢献を求められてもピンとこないのは無理もない。だからなのか、目標設定に際しても、事業にどう影響するのかにまで言及されないことがとても多い（コンプライアンス研修を「実施する」とか、個人情報の管理体制を「構築する」とか。）。
ただ、事業にポジティブな影響が全くないような施策はやるだけ無駄だし、人を巻き込む場合は迷惑ですらあるので、事業にどのような影響があるのかを考えずに施策を実施することは避けなければならない。
そして、「事業への影響を考える」際にもっともわかりやすいのが、売上への貢献なんじゃないかと思っている。逆に言えば、売上への貢献がない施策をそれでもやるべきというのって、難しくない？ということでもある。

そもそも、売上は概念上のものであり、最前線の営業であっても独力で売上を直接生み出しているわけではないことは、「この売上は私だけの力で作ったものです。」と誰かが言った場合の周囲の反応を想像すれば容易に理解できる。つまり、濃淡の差こそあれ、多くのメンバーが売上の創出に関与していることは自明なわけだ。そして、その「多くのメンバー」の中に法務も入っているはずで、そうだとすると、法務の売上貢献も、問われているのは有無ではなく、「どのように関与したか」だけでしかない。
せっかく関与しているのだから、「どのように関与したか」を自覚して、進歩させていこうというのが、法務が考える売上への貢献なんだと思う。

この考え方は、依頼部門と法務部門との対立構造を解消するのにもある程度有益だと思っているんだけど、それはまた別の機会に。