昨日、法務部スベースという名前で世古さんとやっているpodcastで気づいて大興奮したのですが(大興奮している様はこちらからどうぞ)、アレオレには2種類あるみたいなんですよ。みなさん、ご存知でした?

1つ目は、あれ俺詐欺のそれで、もはや説明不要だと思いますが、要は手柄の横取りってやつですね。で、今回存在に気づいたのはもう一つのアレオレで、それは「あれやったの俺たちなんだよね」の略です。

左利きのエレン(ジャンプ+で読める&Netflixにドラマ化された作品があります)の登場人物に「流川俊」がいます。彼はコピーライターを志望していましたが願いは叶わず広告代理店で営業を担当しています。
天才アートディレクターの神谷は、制作したCMがカンヌで受賞したことを、担当営業だった流川に電話で知らせて、それを聞いた流川は「おめでとうございます!」と喜ぶのですが、これを受けた神谷の一言が痺れるのです。
おめでとうじゃねえよ。やったな、って言え
〜Netflix版第4話より

神谷さんは、「このプロジェクトは、俺たちの仕事だ」と言っているんですよね。
これを受けて流川は、自分の仕事に強い誇りを持てるようになります(その直後にどん底に突き落とされるわけですが、まぁそれはそれとして)

こんな具合に、あれは俺たちがやった仕事だと、自分事として語れる人が多いプロジェクトは良いプロジェクトだと思うし、そういう人を作れるかは、マネージャーの腕にかかっているんですよね。
神谷さんのような一言を、伝えるべきタイミングで伝えるべき人に伝えられる、そして、アレオレな人をたくさん生み出す、そんな人に自分もなりたいな、と強く思ったのでした。
このエントリーをはてなブックマークに追加

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

今回は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。有料のものも、業務上の必要性があれば基本承認するので迷わず申請する。


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

このエントリーをはてなブックマークに追加

先日、プライバシー・バイ・デザインとPIAの実施方法というウェビナーを拝聴し、内容もさることながら進行のスタイルが素晴らしいと思ったのでメモ。

どんなスタイルなのか


TMIプライバシー&セキュリティさんのウェビナーは今回以外もこのスタイルとのことで、ご存じの方も少なくないのかもしれないけれど、
  • スライドでトークテーマ(質問形式)を投影
  • ファシリテーターが質問を読み上げ、パネリストに「コメントある方はいらっしゃいますか?」と振り、手を上げた人を「●●さん、おねがいします」と指名してマイクを渡す。
  • マイクを渡された人が話し終わったらファシリテーターが「他にコメントある方はいらっしゃいますか?」と振る。
  • コメントが出尽くしたら次のトークテーマに移る
という感じ。

何がいいのか


あなたじゃない、がない


通常のパネルディスカッションは、ファシリテーター「●●さん、いかがですか?」と、話す人を指名することが通常だが、あまり喋っていない人に振る、みたいな配慮や、ファシリテーターによるパネリストに対する理解の不足により、いつもテーマドンピシャの人に振られるわけでは無い。
その点、TMIP&S方式だと、そのテーマで話すネタがある人が手を上げて話すので、このズレが生じない。

複数の人の話が聞ける


通常のパネルディスカッションでは、ディスカッションとは名ばかりで、パネリスト同士のやり取りがほとんど発生しないということも少なくない。
他方、TMIP&S方式だと、コメントが出尽くさないと次のテーマに行かないので、同じテーマで複数の視点から話を聞くことができる。

濃い話が聞ける


通常のパネルディスカッションではトークテーマが固定されないため、話が拡散してしまって深い話になりにくい。
これに対し、TMIP&S方式は、トークテーマを投影しているので、オフトピに流れたり、見当違いのやり取りで時間が浪費されることがない。しかも同じテーマについてコメントが出尽くすまで話すので、必然的に話題が掘り下げられることになる。

テンポが良い


通常のパネルディスカッションでは、自分が話したあとの展開が明確ではない(誰が話を継いでくれるのか、とか、次のテーマに移るのか、とか)ので、話が間延びしてしまったり、微妙な間が発生してしまったりしがち。
TMIP&S方式は、自分が話すと決めたことを話したら必ずファシリテーターが引き取ることになる結果、テンポが良くなる。話し手にとって、後の展開を考えなくて良いのはかなり気持ちが違うのではないかと思う。

ということを思いました。
このエントリーをはてなブックマークに追加

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

個人のタスク管理


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%属人的な「自分が見る」という手段ではなく、「適切な能力を有する複数人がチェックする」というダブルチェックの仕組みにその根拠を求めるべきだ。もし、上司が常に最適なチェッカーなのだとしたら、それは育成または採用の失敗に他ならない。

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


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

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


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

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


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


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


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


多数の事業会社を抱えるホールディングスとして協働する仕組みを作るのはむずかしいが、個々のメンバーは戦闘力が高いので普通に回すだけなら問題ない、というチームを半年くらい受け持っていたときの振り返り。うまくやれたとは到底言えないけど、多くの学びがあったとは思う。
今見ているチームとは性質が真逆なので、その意味でも気づけたことが多かった。


振り返りの読み返しでこれを見つけたときは、「え、Audibleって再開したの今年だったんだっけ?」と本気で驚いた。そのくらいAudibleは日常に入りこんでいる感覚。
聴き放題サービスとはいえ、話題の本は結構な確率で収録されているので、ランニングする習慣のある方にはAudibleを強くお勧めします。


これ、今はかなり明確になっていて、それは「小規模法務チームのオペレーションのベストプラクティス(守破離の守)を作る」というものです。昔から興味・感心を持っていたことだけれど、言語化したときにあぁ、自分がやりたかったのはこれだったのか、と納得できたのが不思議な感覚だった。
まぁ、数年したらまた別の何かを見つけているのかもしれないけれど。


今はこのときとちょっと考え方が変わっていて、少人数チームでタスク確認ミーティングが機能しない場合、チームとしての機能が破綻している可能性があると思っている。他の人が何をやっているか、どういう状況かに興味がないというのは、結構やばいよね、という意味で。


法務未経験のメンバーの立ち上げを強く意識した1年だったので、こういう系の投稿も多かった。
読み返したときにはすでに記憶から抜け落ちているので、(自分が書いたことだから当たり前だけど)そうだよね、なんて感じで同意しちゃってなんだかおもしろかった。


おぅ、結構良いこと言ってるじゃない、と自画自賛した。惜しむらくは、これも記憶からきれいに抜け落ちていたということ。なんとかならんのか、この揮発性の高さ。


今年始めたことの一つにSpacesはあるなー。
一人喋りもやってみたけど満足感はほとんど得られず、自分は語りたいのではなく、誰かと対話をしたかったのだということを自覚した。
2023年も対話を楽しんでいこうと思います!


2022年夏に大きな山を超えたこともあり、業務外活動を再開できたのも今年の大きなトピック。仕事100%になると充実感は得られるけど、どんどんすり減っていくんだよね。
この「数週間前に聞いた」というのも互助会の突発イベントで、忙しがっていたら触れることができなかったものなので、ゆとりは重要だよねということを実感しています。


その閉塞感はキャリアの行き詰まりからくるものではなく、自分の能力の伸びの停滞からくるものでは、という指摘は、残酷だけど向き合う必要があるものだよね。
たった4ヶ月前のことなのにこれも忘れてたw


名言オブジイヤー2022はこちらでした。

といったところで、2022年は大変お世話になりました。
2023年も引き続きよろしくお願いいたします!


このエントリーをはてなブックマークに追加

良かれと思ってした行動でメンバーを病ませてしまうマネージャーについて、大掃除をしながら考えてみたので、思いつくままに書いてみようと思います。

良かった点に着目しない


なにかのアクションが100点満点であることはほとんどありません。そのため、あるアクションについては、良かった点と良くなかった点の両方が含まれています。このとき、良かった点に着目しないと、メンバーにとってはフィードバックとダメ出しが同義になるため、フィードバック自体に強いストレスを感じるようになります。
これをやってしまう人は、本人の成長のために良かれと思ってそうしている場合があるのが怖いところです。優しい言い方をすればいいってもんじゃないというのもポイントですね。

答えが一つではない事柄についてクイズを出す


ここでいう「クイズ」は、マネージャー側がすでに答えをもっている状態でメンバーに質問をする振る舞いを指しています。
例えば、打ち合わせでうまく情報を引き出せなかったメンバーに、「あのとき、どうすればよかったと思う?」といった問いかけをするようのケースがそれです。マネージャーは、自分の頭で考えるプロセスが成長につながる、という思いがあってそうしていることが多いのですが、残念ながら、このときメンバーが考えているのは「どういう答えがマネージャーの考える正解か」です(心理的安全性が確保されている関係の場合は別として)
マネージャーの考え方にシンクロできているメンバーは早々に答えにたどり着けますが、そうでない人は「違う」「そうじゃない」を何度か繰り返した後、マネージャーから(ときにはため息交じりに)正解を教えてもらうという儀式を通じて上下関係を刻印されるとともに、自己肯定感がごりごり削られることになります。

どっちでもいいことについて口を出す


どっちでもいいなら黙っていましょう。裁量のなさは、人から活力を奪います。
なお、これは、細かいことに口を出すなという話ではありません。細かくてもこだわるべきことについては、その理由を示しつつこだわればよいのです。

できない人として優しく対応する


期待されていないという実感は人を傷つけます。
期待できる範囲・限度の仕事を任せて、しっかり期待してみてはいかがでしょう?
なお、「できない」と思っている人のアウトプットは、先入観もあって粗がとても目立って見えるということもお忘れなく。


ダメ出しがストレート


自己肯定感が極めて高く、ダメ出しに強いマネージャーが、本人の成長のためを思ってやってしまいがちなのですが、普通の人はダメ出しを受けると傷つくという前提で、言い方を工夫する必要があります。
なお、内容を「工夫」をすると、何についてダメ出しをされているのかわからなくなるので、よくないというのが難しいところではあります。


いろいろ書きましたが、環境や関係や相手の属性によってはそうすべき場合もあるという意味で、これはべからず集ではないという点は最後に付記しておきます。
このエントリーをはてなブックマークに追加

T/O
だとエントリーにならない&意外に徹底しているチームは少ないようなので効能を書いておくと、
  • 作業漏れがほぼなくなる
  • 業務が見える化される結果、業務改善がされやすくなる(このステップ、無駄じゃね?という会話が生まれる)
  • 誰でも同じ品質で対応できるようになり、リソースの稼働効率が良くなる
  • 久しぶりの対応でも「思い出す」工程が不要ですぐ作業にとりかかれる
  • 割り込みに強い(中断させられたときの影響が限定的)
  • 役割分担ができる(このステップやるから、次すすめておいて、みたいなかんじ)

コツは、
  • 文章を理解できれば作業ができるくらいに具体的に書くことを目指す
  • 最初から完璧なものを作ろうとしない(運用でブラッシュアップしていく)
  • 作業の都度毎回参照する(慣れていないと意外にこれが難しい)
  • マニュアルへのアクセスを確保する(slackチャンネルのリンクとか、ショートカットとかで)
  • 修正のハードルをできる限り下げる。
って感じです。
このエントリーをはてなブックマークに追加

↑このページのトップヘ