12章　多すぎる尺度

原題: Too many yardsticks

しかし多くのチームは、全体的な目標ではなく、その目標の特定の部分に集中してしまう傾向があります。その特定の部分が、組織全体の目標よりも優先されてしまいます。その部分がより具体的になればなるほど、それを測定する方法も具体的になっていきます。やがて、チームのパフォーマンスを測る方法がチームごとにバラバラになり、さらにはそれらの手段が全体の目標を損なうような行動にインセンティブを与えるようになるかもしれません。これが多すぎる尺度というアンチパターンです。

わかる！メンバーにとってわかりやすい目標に砕いて言った結果、部門間の目標がずれていく。トップレベルでは同じものを目指してたはずなのになんか対抗意識もやしてる？みたいになることも(98lerr)

👍 (98lerr)

ブレイクダウンしたときに漏れる

自分のプログラムが使用している OpenSSL ライブラリをアップグレードするという ToDo アイテムがあっても、それが実行されないのは、あなたがそれに優先順位をつけていないからです。

うちのチームの一部で、ToDo アイテムがたまりすぎて、優先順位をつけることに手がまわらなくなりつつあります (hayase)

ちゃんとリファインメントするようにプロセスを改善する

全体的に、いわゆる外資系の、トップダウンな意思決定に従うマネジメントの話になっている気がしていますが、 JTC的な(?) 現場重視 (?) の管理だと、話の構造がだいぶ違ってきたりするのでしょうか?(hayase)

みんな右向け右系と、右向けといわれて右の向かい方を現場で考えるのと、現場のマストをこなした上での右向け系

階層で戦略~戦術に組織、部門、チームでなっていくところとかも含めてこの後読んでいくとよさそう

12.1　目標の階層

自分の目標が組織の大きな目標にどのように関わっているかを知ることは、多くの人にとって仕事の満足度につながります。自分の仕事が孤立無援で、自分の仕事やその仕事をしている理由を誰も評価してくれないと、組織のほかの部分とのつながりが切れてしまいます。

目標の階層をつけないと、これはこれで自分の仕事の位置づけが分からなくて、個人がばらばらになる。目標を作ったら作ったで、序文のように(全体の目標を忘れて)自分に近いところの目標にフォーカスしてしまう。ここをどっちかに寄せない調整が悩ましいです。今のところ、目標は決めて、全体と結びつける話を意識させるために言い続けるしか浮かんでいない。(98lerr)

某前職がこれの権化のような状態でした(hayase)

DevとOpsの間に壁を作らないだけじゃなくて、他の壁も取り扱っているのかな、と思いました。

12.1.1　組織の目標

重要なのは、組織の目標を認識すると、自分がこれから取り掛かる予定の仕事が違って見えるようになるということです。

自分のタスクをみるのと、その背景を見るのと。ここは言われれば当然なんですが「忙しい！」となってるときほど近視眼になって、ここに立ち戻れなくなるのが危険。(98lerr)

みえてれば防げる部分も。見続けられるように。

12.1.2　部門の目標

12.1.3　チームの目標

部門の目標が組織の目標に対応付けられているように、チームの目標も部門の目標に対応付けられている必要があります。これは組織の目標に直接対応付けるよりも簡単なはずです。なぜなら部門の目標は技術的な観点で作成されているはずだからです。

チームで、個人、チームの目標が部門、組織にどう紐づいてるかを話せるのを常態化したいけれど、そうもいかないことも多そう。(98lerr)

この例ではとても綺麗に対応していますが、実際 1:n にならない場合があったり、部門目標には含まれないけど維持・改善しなければならないともあり、目標設定はすごく難しいなと感じています(hayase)

組織とか上のレイヤーの話を意識する効果の一つに、「部門目標に含まれてない」が消えるのも防げそう

暗黙のルールなども、目標管理から外れがちな気がする

12.1.4　目標の確認

目標を聞くというのは単純すぎるように見えますが、うまくいく理由は簡単です。目標設定は、マネジメントチームの中核的な仕事の1つです。マネージャーに自分や自分のチームの目標を明確にしてもらうことは、合理的な要求です。

チームや組織の目標を聞いてみるというのを考えたことない人も。目標というのを、「ノルマ」でなく「みんなで向かう先」という共通認識をとれるとよい？(98lerr)

皆さんの中には、自分のマネージャーが非常にひどい人で、目標について絶対に答えてくれないと考えている人もいるかもしれません。

冗談だとおもいますが、隠したいケースあるんですかね。(98lerr)

「答えられない」のを隠してるケースも

階層が深過ぎて、元の目標とか意図とかを現場に近い人がわからなくなってるケースは、前職でわりとあったな……と思いました (hayase)

12.2　どの仕事に取り掛かるかに意識的になる

自分の仕事に意識的になるということは、コミットメントという考え方に根ざしています。あなたは同僚やマネージャーとコミットメントを交わしています。そしてあなたの部門は組織とコミットメントを交わしていく、という形で連鎖していきます。個人にとって、コミットメントは信頼を測る通貨のようなものです。

「信頼貯金」という言葉好きです。コミットメントを通して信頼を溜めるところも、放っておくとなぜか目減りしていくところも。(98lerr)

12.2.1　優先度、緊急度、重要度

Priority, urgency, and importance

↑単語の確認で書いてます (98lerr)

これらの質問は、あなたがこの新しいコミットメントを引き受けることができるかどうかを評価するのに役立ちます。

自己管理している時のコミットメント順序、自分で見て優先度が低いと思って下げすぎると、相手に不誠実になるなという体験もありました。ほどほどのところがある。(98lerr)

多くの人が重要度と優先度を混同しています。優先事項は、ほかの行動よりも優先されます。しかし、もし優先事項がほかの行動よりも優先されるのであれば、複数の優先事項が存在することはあり得ないでしょう。

日本語の優先は「何が先」を表してる文字になってるのに、優先度高いのを複数並べるとか起きがち。文字の意味捉えるのも大事ですね。(98lerr)

私の主張は、1 人の人間が持つことのできる優先事項は一度に 1 つだけだというものです。

これは本当に大事で、作業をお願いするときはいつも意識していたい (hayase)

「優先度」というと、レベル分け間で同立を作る感じ

優先順位とか、優先事項とかっていう方が良さそう。

緊急度と重要度のどちらも、文脈によって変わりうるということを認識することが重要です。タスクの依頼者にとっては、そのタスクは彼らが実行しなければならないほかのタスクと関連しているので重要だとみなすでしょう。一方で、そのタスクを実行する側は、同じ文脈を持っていないため、依頼に対する見方が異なる場合があります。

文脈、背景のために目標が大事って話に返ってきた。「タスク決まってるんだから目標とかなしに進める」という人(そんなにいない気はするけれど)に説明するのにわかりやすい。(98lerr)

すてきな章の構成

しかし、こういった会話をする前に、優先事項にどれだけの時間がかかるのかを把握しておきましょう。優先事項がどのくらい遅れるかわからないのに、優先事項を遅らせるという決定はできません。どうしてもどのくらい遅れるかがわからない場合は、マネージャーにその旨を伝えるようにしましょう。

新しい優先事項のために、元の優先への影響を把握して伝えて合意は大事。一方、「あのチームが炎上してる。優先度高いから支援入って」系は、なかなかすぐにかかる時間を判断しにくいのが悩ましい。最初の段階にそのスコープとかかる時間を整理するところから入る、というのがだからこそ大事なのだと思いますが。(98lerr)

優先事項を遅らせるかどうかの前に、捨てられない「緊急」が複数貯まっている時点で、詰んでいる気もする(hayase)

12.2.2　アイゼンハワーの意思決定マトリックス

あなたが取り組むタスクに対して完全な決定権を持っていない場合があることを考慮して

はたして，上の人ならば判断できるのか (hayase)

上の人の上の人の判断がないといけないケースも。。こうなると詰み(積み)がち

12.2.3　コミットメントにノーと言う方法

新しいコミットメントにノーと言うのは難しいですが必要なことです。コミットメントは信頼を測る通貨です。安易にコミットメントを受け入れることは、組織の信頼を危険にさらします。達成できない新しいコミットメントにノーと言うことは、信頼を維持するための1つの方法です。

断ってばかりも、受け入れてばかりも、どちらも信頼を危険に晒す。意識していたい。(98lerr)

次のようなシンプルで落ち着いた言葉を返しましょう。「お手伝いしたいのですが、以前からのコミットメントがありますので。もし優先事項について話したり、この件がより重要であると主張したいのであれば、私のマネージャーであるサンドラに話してください。彼女が私の優先事項やそのほかのタスクを決めます」。このシンプルな断り方には議論の余地がありません。

断り方の例つき、優しい。(98lerr)

うちは階層の浅い組織で「上」の人がいないような状態なのですが，この例を見ると階層構造があることのありがたさを感じました(hayase)

「念のため確認ですが、これは私の優先事項を変えるということですか？」と質問し、常に明確にしましょう。

マネージャーは自分が無理なお願いをしていることに気付いていないことが意外と多いものです。優先順位を争うタスクの中から選択をしてもらうことで、新たなコミットメントを再評価してもらうことができます。

「相手がわかってない可能性もある」と考えるのは、失礼ではなくて思いやり。「あの人がわからないはずがない」は危ない。(98lerr)

相手がわかってないかもしれないと思うのもスキル

相手を尊重しつつ

12.3　チームの仕事を整理する

12.3.1　作業を細分化する

唯一必要なのは、すべての未処理の作業をどこかに記録し、チームが見えるようにすることです。仕事は、人々の頭の中だけにあってすぐに消えてしまうようなものであってはならないのです。

よく脳内で済ませようとする人に「脳内メモリはもっと有効なデータに使おうよ」という話をします。(98lerr)

深追いすると、何したかったんだっけ？ってなることとかも

以前マネージャーの仕事をどうラクにさせるかという話をした時に、マネージャーに書き出してもらうという結果になった時がありました。(98lerr)

書き出してくれれば、周りも助けられる

50 項目もある ToDo リストを見ると、一瞬にして分析麻痺状態に陥り、何も進められなくなってしまいます。

Icebox の大切さがわかる (hayase)

と思ったら、プロダクトバックログをコンパクトにする話は出てこなかった．スプリントバックログを無駄に大きくしないのは前提として，プロダクトバックログが膨れ上がる問題はどうすればいいのでしょう．

インフラ管理は，どこまでもバックログが積み上がるような気がしています．

Iceboxに入れて、バックログに入れる必要あるもの入れるし、ないやつはずっと沈める or 沈み続けてるなら消えるくらいでちょうど良さそう

インフラ、その場で優先度下げられてるけれど、コントロールできない一定条件にたどり着くとまずい問題があったりするのが危うい(と書いたけれど、インフラじゃなくても同じ話はあるかも)

アプリでも放っておいたらまずい問題はあって直していくのだけど、インフラだと後回しになりやすい気がします。

12.3.2　イテレーションの作成

目標はイテレーションでコミットしたすべてのタスクを成果物の期日までに完了させることです。予期せぬ事態でそれができないこともありますが、それはそれで良いのです。常に予定外の作業に直面し、時にはその仕事が優先されることもあるでしょう。

「終わらないこともある」と「終わらなくてもいい」の違い、うまく伝わらない時もあって難しい。目的があって、そのための「予定外」だったりが出てくるならば「終わらせればいいにならない」っていうのをうまく伝えたい。(98lerr)

終わらせるための最善の努力をしてるか

+ 終わらせられる計画になっているか

あなたやあなたのチームが取り組んでいることの透明性を確保できます。

アプリケーション開発との違いとして、インフラの作業は複数人で分担しづらかったり、複数の作業をまたがった全体性を持たせるのが難しかったりするのではないか……と思っています。属人化しやすかったり、計画に他の人が関与しづらかったり。 (hayase)

アドホックな対応( w/アプリとか)が多くて、自分たちの流れというより流そうとしてるところの支援になりがちだったり

だからこそ、インフラとアプリの切り方じゃなくて、プラットフォームでチームを分けたりするか

散らかりまくったインフラの掃除で，どこもかしこも片付けないといけないのだけど，それぞれの片付けが直接連携していない……という

12.4　予定外の作業

時折、同僚が予告なしに訪ねてきて、何かを手伝ってほしいと頼まれることがあります。良き同僚でありたいと思い、あなたは彼らを手伝うことにしました。30秒ほどのなんてことはない作業に見えたものが、あっという間に考え違いと混乱の連鎖に陥り、最終的には想像以上に時間を消費してしまうことがあります。

あるある(98lerr)

+1 (hayase)

だからこそ、都度頭の中にあるものを吐き出すことは習慣づけたい。(98lerr)

12.4.1　予定外の作業のコントロール

次のようなステップによって予定外の作業をコントロールできます。

1. 入ってくる仕事を評価する。

2. その仕事がどこから来たか記録する。

3. その仕事が本当に緊急のものかどうかを判断する。緊急であれば実行する。そうでなければ後回しにする。

4. 集中している作業が終わったら、後回しにした仕事をさらに詳しく評価し、いつ作業するかを決める。

予定外のタスク、これは書き出しておきたい。いきなり手をつけて、 2, 3 の検討ができないまま実施されてたり。(98lerr)

評価するだけでも、元のタスクの集中が切れる

チャットを非同期コミュニケーションに使うことで適切なタイミングの割り込みにしたいけれど、同期的な使い方をしてしまいがち

チャットは、非同期コミュニケーションをシームレスに同期に切り替えられるところも旨みだけれど、同期が前提なようにも取れてしまう

5秒で返事できるとおもったら5分かかって，フロー状態に戻るために15分かかる……みたいな

リモートのモブプロ

短時間での切り替え、一人のドライバー、一人のナビゲーター、その他のモブがワークする (joe の研修)

声の大きい人中心になってしまいがち

モブの人の声、つい聞いて主導を委ねがち

12.4.1.1　同僚からの予定外の作業

どういうわけか、多くの人が常に連絡が取れるようにしておかなければならないと暗黙のうちに思い込んでいます。しかし、このような考え方では 1 日のうちで生産性の低い時間が増えてしまうだけです。

うちだ……．これでは品質と効率が下がると主張しているのですが、「ビジネスサイドの人」と意見が一致しません (hayase)

メールを閉じ、チャットを閉じて、ヘッドフォンをして、ひたすらタスクに没頭してください。

以前MS牛尾さんの講演で「人によっては、日の半分は他人のために時間を解放し、半分は連絡手段を経って自分のために使っている」という話を伺い、そうしたオンオフをコントロールするのが大事なのだなと思ってはいます。(98lerr)

ただ、一方で「緊急の相談」と、ブロックをこじ開けて入ってくる予定はとても多い。(98lerr)

ただし、この対応で重要なのはコミットメントを守ることです！　後でフォローアップをすると言ったのなら、必ずフォローアップをしましょう。

いきなりブロックじゃなくて、まずは信頼の積み上げ。こういうところに触れてくれてるのがこの本は素敵。(98lerr)

12.4.1.2　システムからの予定外の作業

いずれにしてもシステムからの予定外の作業は無視できません。

この辺も、組織の誰かがトラブルに巻き込まれてないかと、チャットをオフにしきれないところ。(98lerr)

システム通知と、人の連絡経路を分けておかないと、この辺につられて人との常時同期コミュニケーションも避けられなくなる

12.4.1.3　今やるか、後回しにするか

12.4.2　予定外の作業への対応

メンテナンス・パッチ適用・セキュリティ・再設計などといった、自分の作業の延期を検討したくなることもあるでしょう。しかし、自分の仕事を低く評価したいという衝動を抑えましょう。

メンテナンスとかパッチ適用とか、「重要で期日が決まっている」作業が多いので、割り込みで時間を削られると期日に間に合わなくなったり、作業品質が落ちたりしてしまいがち。(hayase)

定期メンテ、パッチで埋まる人組みになってるところがもう苦しいけれど、それ以上に広げる説明も難しいし、増えて楽になるとも限らないのが悩ましい

もしあなたがそういった作業の延期を申し出るなら、次のイテレーションでそれらが優先されるようにしてください。

ここまでセット、のような蔑ろにされがちな話に触れてるところが優しい。(98lerr)

私はこのプロセスを特にアジャイルやカンバンとは呼んでいませんが、それはこの2つの言葉が組織によっては大きな負担になっている可能性があるからです。

用語を使うか使わないかというのは折々で悩ましい。言葉を使うと、説明した上でそれぞれが調べてくれるが、相手によっては誤解した理解をしたり、知らないことを馬鹿にされたと受け取る人もいる。使わないと、丁寧な説明ができる状況を作らないといけなくなるし、名前がないことで記憶に残りにくくなることもある。常にどちらがいいとは言えないのだけれど、それぞれの効果を意識して相手に響く方を選びたい。(98lerr)

誤解されるのが辛いな、と実感しています。特にアジャイル関係の概念で。(hayase)

12.5　本章のまとめ

みんなからのコメント

実践する/伝えるためのハードルはなにか？

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

どれくらい効果がありそうか？