小さく不正確な依頼がチームの時間を大きく浪費する
(staysaasy.com)- 管理者やリーダーの曖昧な依頼は、小さな質問に見えても、チームの時間、優先順位、実行の方向性を大きく揺るがすことがある
- 「確認してほしい」「モダンにしなければならない」といった表現は、レポート、スライド、週末作業、大規模アップグレードのような過剰な対応へ広がりやすい
- 依頼する側は、期待する時間投資、優先順位への影響、既存資料の確認なのか新規作業なのか、成果物をどこで使うのかまで併せて伝えるべき
- 依頼を受けた人も努力の水準を聞き返し、不明点を確認する必要があり、リーダーは忙しくて答えられないだろうと決めつけてはいけない
- 最初の段階で少し気まずいほど具体的に話せば、後で起こる混乱、誤った作業、コストの無駄を大きく減らせる
小さな依頼が大きな作業に膨らむ仕組み
- 組織の中では、短く軽く見える依頼が、予想よりはるかに大きな作業へ膨らむことが繰り返し起こる
- 管理者が「Xをやってもらえるか」と尋ねたところ、直属の部下が想定より10倍多い時間を使い、管理者が「そこまで時間を使ってほしかったわけではない」と反応する事例がある
- 役員が会議で「これをちょっと確認してくれる？」と短く言ったことが、24人が4バージョンのスライドデッキを作り、週末まで働く状況につながることがある
- 肝心の会議では、役員が最初のスライドの最初の一文の要約だけを見て「全体の発表は必要ない」と言うこともある
- 「言い訳なしにモダンであるべきだ」という言葉も、意味を確認しなければ大規模な技術アップグレードと解釈されることがある
- 実際の意図は、数年かけて新バージョンでAPI構文を更新する程度かもしれない
- その間に重要なプロジェクトのリリースが遅れる可能性がある
依頼する側が先に決めるべきこと
- リーダーは依頼するとき、期待する時間上限を直接伝えるべき
- 例：「20分以上かけず、20分後に手元にあるものだけ持ってきてほしい」
- 優先順位にどのような影響を与えるべきかも併せて整理する必要がある
- 例：「約2週間かかると見込んでおり、他の主要な作業の優先順位を大きく下げないようにしてほしい」
- 実際のスケジュールが違う、または他の仕事と衝突する場合は、すぐ連絡するよう伝えるべき
- 既存資料を確認するだけでよいのか、新たに分析したり作成したりする必要があるのかも区別すべき
- 例：「このテーマについて、すでに持っているものがあるかだけ教えてほしい。まだ考えたことがないなら、それが分かるだけでよい」
- 成果物の使い道を伝えれば、相手は努力の水準を合わせやすい
- 例：営業見込み客に送る回答、次回のAll HandsのQ&A準備、次回の取締役会の主要テーマなど
依頼を受けた人が確認すべきこと
- 依頼を受けた人は明確化の質問をする必要がある
- 「何時間も必要な非常に徹底した結果を期待しているのか、それとも短い整理でよいのか？」のように、努力の水準を確認すべき
- 質問して愚かに見えるのではなく、尋ねずにまったく間違ったことをする方がより危険
- リーダーのメールやメッセンジャーを古代遺物のように解釈して時間を使うより、依頼したリーダーに直接確認する方がよい
- リーダーに依頼する時間があるなら、その依頼を明確にしてくれる時間もある
1件のコメント
Hacker News のコメント
非技術系のリーダーが1、2段階を飛ばして、明確化の質問やスケジュール・成果物の定義を行う経験のあるシニア技術者ではなく、ジュニア技術者に直接話すケースがいちばん嫌い
複数のキャンペーン組織や政治系テック組織でよく見たパターン
ジュニア技術者も指揮系統を理解しているので、上の人が意図したかどうかにかかわらず、それを壊すと混乱と大騒ぎが起きる
実際の物理的な作業をしているのはジュニアエンジニアであることが多く、上位レベルから見ている人よりも特定の質問にはうまく答えられる
わざわざ伝言ゲームをする必要はないのでは、と思う
経験の浅いベンダーのプロジェクトコーディネーター、コーディネーターが仕事を処理してくれることに慣れたベンダー側の技術者、この分野が初めての顧客がそろうと、かなり大きな混乱が起こり得る
「質問せずに完全に見当違いのことをしたら、明らかに愚かに見える」「作業中の明確化の質問に答えるには相手が忙しすぎる、などと決して決めつけるな」という話について、リモートで働いていてオンラインチャットも使えない状況ではどうすればよいのか気になる
対面なら、小さく素早く、ざっくり整理した質問をたくさん投げやすいが、メールはより形式的で邪魔になる感じがあり、何が分からないのかを説明し、想定される回答まで先回りして潰すのに時間がかかる
ビデオ通話は設定するのに時間がかかり、付随コストも大きい
顧客プロジェクトでは、Google Docに小さな質問が生じるたびに追記し、ときどき顧客に文書を確認してほしいと知らせたり、顧客に編集通知を購読してもらったりする
顧客は回答を文書に直接書き込み、作業が進むにつれてこのプロセスを繰り返す
利点は、顧客が一度にすべて答えなくてもよく、通知が減り、双方ともあまり形式ばらずに書いてもよく、協働している感じが出て、関連箇所の横にフォローアップ質問を付けやすく、文書コメントで短いやり取りや小さな作業の割り当て・追跡もでき、他の人が読んで貢献するのも簡単なこと
ここでは、よく知らない非技術系の顧客との契約作業のように、小さな質問が多く発生する状況を想定している
他の人たちはメールにそのような制約を課していない
CEOに送るのでなければ、思いついたまま質問を書いてすぐ送ってよい
「あ、この質問も忘れていました。ありがとうございます！ $QUESTION」のように、すぐ2通目のメールを送ることも恐れる必要はない
https://twitter.com/TechEmailsで上級幹部たちのメールを見ると、ほとんどがかなりくだけている
Bill GatesとMicrosoft幹部たちがやり取りした古いメールの一部は、高校生のテキストメッセージより大して整っているわけでもない
上司の上司の上司の上司に絵文字を入れろという意味ではないが、素早い非形式的なメールがキャリアの終わりになることはない
多くの人にとってより大きく感じられるのは分かるが、双方にとって実際により面倒かどうかは分からない
質問を明確にするために往復の会話が必要なら、そうすればよい
共有文書方式もよいアイデアで、追加の利点が2つある
文章にする行為が質問をより明確にする追加ステップになり、質問と回答が後のために文書化される
後で改めて書き起こす必要がある短いやり取りより、どちらも大きな利点
認知負荷を相手に渡せばよい
1日に何度も邪魔するより、1回邪魔するほうがましだから
新しいイシューを受け取ったら、まずざっと見て、何をするか計画し、潜在的な問題や衝突を頭の中で掘り下げ、ときには巨大な質問リストを作り、それから誰がどの質問に答えられそうかを分けてから、オンラインでの会話を始める
社内では通常、Slackのような社内メッセンジャーで短い5分のビデオ通話を依頼すればよい
近くで一緒に働く同僚なら、予告なしにそのまま電話することもある
外部顧客にも事前に合意していれば、実際の電話番号やビデオ通話で同じようにできる
たとえばキックオフ会議で、顧客が望む連絡頻度と、どの質問は即時にやり取りすべきで、どの質問は遅い非同期コミュニケーションで十分かを決めておけばよい
時間は労力・実質・スコープを表す指標としては非常に悪い。
たとえば「20分だけ見て、20分後に手元にあるものを持ってきて」という依頼を見ると、人によって20分で達成できる量は少しずつ違う。
仮にその差を無視したとしても、依頼したマネージャーがその20分の労力から必要なものを得られる保証はない。
アジャイル環境で発見・調査作業を「スパイク」と呼び、「タイムボックス」を設定するのをよく見るが、「その時間内に望むものを見つけられなかったらどうなるのか？」と聞くと、たいてい良い答えは返ってこない。
実際には、必要なことが分かるまでタイムボックスが延びていく。
だから時間は、労力や実質やスコープの悪い代理指標である。
記事の後半にある例、「何時間もかけた非常に徹底的なものを期待していますか、それとも素早い整理で十分ですか？」のほうが良いと思う。
これは、かかる時間ではなく作業範囲について話しているからだ。
時間で測ると、その時間内に望むものが得られる保証はなく、結局さらに時間を足すことになる。
「その時間内に望むものを見つけられなかったら？」への答えは、想定していた時間内には答えを見つけられなかったという事実が分かり、この調査作業に必要な労力への期待値を調整する、ということだ。
マネージャーとしては、まさにその情報こそ知りたい核心情報の一つである。
だからプロジェクトが脱線してゴミ箱行きになるのを防ぐには、何であれタイムボックスが必要だ。
個人作業や一人でやる作業にも当てはまる。
何でも永遠に抱え続けることはできるので、止める地点を強制的に作り、フィードバックを受けるかリリースしたうえで、続ける価値があるかを決めるほうがはるかに良い。
ここで働いているメカニズムは、人々に優先順位付けを強制することだ。
優先順位の判断が非常にうまいならタイムボックスの必要性は下がるかもしれないが、その場合でも、タイムボックスがなければ必要な水準を超える品質まで作業を続けたい誘惑に耐えるのは難しいかもしれない。
こうした作業パターンは、知っていることより知らないことのほうがはるかに多い場合に有用だ。
目標は当てずっぽうではなく、情報に基づいた推測ができる程度まで、「分かっていること」の比重を少しずつ増やすことだ。
たとえばレガシーコードベースにバグがあり、代替システムはほぼ完成していて2か月後にリリース予定だとしたら、そのバグをどう扱うだろうか。
無視することもできるし、誰かに「何が何でも直せ」と言うこともできるが、どちらも良くない。
そこで「このバグを調査してほしい。ただし1時間を超えないで、どこまで分かったか知らせてほしい」と言う。
終わると、問題の形がよりよく分かる。
「問題領域は見つけたが、ビジネスロジックに詳しい人と一緒に解かないと修正できない」と戻ってきたら、適切なリソースを付けて修正につなげればよい。
「コードのこの部分で、かなり整理はされているが、まだ完全には追跡できていない」と言われたら、巨大な作業ではなさそうだという信頼に基づいて、さらに時間を与えられる。
逆に「この奇怪なスパゲッティのどこかにあり、覗き込んだら深淵がこちらを覗き返してきて背筋が凍り、壁の絵が血の涙を流したので、もう二度と送り込まないでほしい」と言われたら、これ以上追跡する価値がないことが明らかになり、手放せる。
望むものを時間内に得られず、さらに時間を足す経験をしたというのは信じるが、普遍的ではない。
問題は、「望むもの」自体を最終目標として扱っている点にある。
だから記事でも「それがなぜ必要なのかを言え」としている。
「最大顧客が契約更新前に知る必要がある」は、「ただ気になった」よりも、多くのお金と多くの社員の時間を使う価値がある。
リーダーシップのレベルでは、あらゆる利益を追うことはできないと理解し、費用対効果が最も良いものに戦略的に集中しなければならない。
単に仕事に人を付けるだけでなく、適切なスキルを持つ人に適切な仕事を割り当てることまで含まれる。
スタートアップのCEOが何かを依頼してきたが、その依頼は1〜2文程度の短いものだったと思う。
その結果、14ページのレポートを作成し、数時間を費やし、その大半は個人の時間で行った。
CEOにレポートを送ったが、その後は何の返信もなく、何も起こらなかった。
その後、自分の中で新しいルールを作った。
依頼のコストは、その依頼を伝えるコストに比例すべきだ。
今ではコストの大きい依頼を受けると、待ち、遅らせ、エスカレーションを求める。
依頼した人はデューデリジェンスを行い、さらに上層部の承認を得て、そのコストを払う価値があることを示さなければならない。
くだらない依頼なら二度と聞こえてこないし、価値のある依頼なら処理する。そして、その労力が適切な可視性なしにこっそり行われないという副次的な利点もある。
第一に、最初の依頼では絶対に何もしない。
重要ならもう一度依頼してくるので、そのとき考える。
第二に、自分が残業しなければならないなら、相手も残業しなければならない。
相手が残業したくないなら、その程度には重要ではなかったということだ。
エンジニアリングでジュニアからCレベルまで、さまざまな段階に身を置いてきて、いくつか学んだことがある
第一に、全員が善意で行動しなければならない
リーダーが5秒も考えずに、その場の思いつきで直属の部下に何かを頼むのも見たし、逆に直属の部下が「人間コマンドライン」のように、正確な構文を与えられないと動かないのも見た
どちらもやってはいけない
第二に、マネージャーやリーダーにとって「一回限りの依頼」は存在しない
どんな依頼でも、他のあらゆる仕事より暗黙の優先順位を持つことになる
システム全体と環境の中で動かなければならず、そうしなければチームにその選択を押しつけていることになる
第三に、依頼を受ける側なら、依頼者が何を必要としているのか理解できるよう助けなければならない
暗黙の前提をなくす必要があり、まさにそこにドラゴンが潜んでいる
コミュニケーションし、知らせ、教え、依頼者が望むものを確定し、双方が合意しているか確認しなければならない
こうしたことは、必要がなければ時間を無駄にしたくないという効率性から生じるが、依頼者と受け手が互いに助け合おうとすれば、たいてい生活はずっと耐えやすくなる
どこまでやってよいか限界を押し広げようとするリーダーと、チームと善意の関係を築こうとするリーダーは、はっきり違う
考えのない要求を続けるマネージャーは、最高の社員を着実に失っていく
経験上、十分な時間がたつと、こうしたリーダーの下にはジュニアだけが残る。経験ある人たちはそのチームを避けるからだ
「人間コマンドライン」なチームメンバーも、悪意ある振る舞いのよい例だ
ごく小さな依頼でさえ、自分が作ったフォームや文書を埋めないと着手できないと要求し、何日も議論したり批判したり回覧したりした後で、ようやく小さな仕事について考える人たちと働いたことがある
質問を正確に投げる手間を誰もかけたがらないようにすることで、小さな依頼から自分を守ったつもりになっているが、時間がたつと一緒に働きにくい人だという評判が積み上がる
もう一つの変種は、あらゆる依頼の曖昧さを悪用する人だ
何を求められているかはおおむね分かっているのに、「教訓を与える」ために、依頼の字面どおりではあるものの、誰も必要としておらず望んでもいないと分かっている成果物を出す
偶然ではないが、こうしたゲームをしていた人たちの大半は、この1年の間に解雇された
人はある程度仕事をする悪い同僚をしばらくは我慢できるが、人員削減の時には真っ先に削除対象リストに載る
1か月前、リーダーとして自分が犯していた失敗に気づいた
表向きはチームにオーナーシップを持たせる意図で、やるべき多くの仕事を投げ込んでいたが、実際には「今この瞬間に何をすべきか」というストレスをチームに押しつけていた
「チームにものすごく権限委譲している！」と思いやすい巧妙な罠だが、実際にはチームにストレスを与え、集中力を落としている
OEDによると、名詞化はオーストラリア英語の口語から始まったという
https://www.oed.com/search/dictionary/?q=ask
言語が絶えず変化する生物社会的な認知の産物で、本当の規則などないことは皆分かっているが、すでに良い同義語がちゃんとあるのに、こういう用法は砂を噛むような不快感がある
その情報が意思決定を左右してほしくなかったからだ
自分にとって楽なものではなく、ビジネスとエンドユーザーにとって最善のものをすべきだと思っていた
ところが相手はより長く難しい方を選び、後で分かったのは、実はもう一方を望んでいたが、それは私にとってより難しいだろうと思っていたということだった
現実の生活でも同じことが起きる
新しいキッチン収納を作るとき、扉の上部レールについて2つの選択肢を妻に示した。片方の方が難しかったが、好きな方を選んでほしくて言わなかった
当然、妻は難しい方を選び、後で分かったのは、そちらの方が簡単だと思っていて、実はもう一方の方を気に入っていたということだった
だから常に相手にすべての情報を渡すべきだ
経営陣が投げた質問が筋違いだと、なぜ言えないのか
答えはもちろん、階層に逆らわないためだ
しかし、こうした階層への順応は実際にはビジネスの役に立たない
もっと簡単に捨てられるべき価値観のように見える
「かなり徹底したものを期待していますか、それとも手早いまとめでいいですか？」という質問は笑える
エンジニアが非エンジニアに、ある作業にどれくらい時間がかかるかを正直に言うと、非エンジニアは衝撃を受けて、それは無理だと言うだろう
「20分以上かけず、20分後にその時点であるものを持ってきて」という依頼は正気とは思えない
20分で終わる仕事などない
むしろ「これは見ずにコーヒーを飲んできて、ざっくり見積もってくれ」と言う方がましだ
私たちは複雑な作業をしており、考える時間が必要だ
考える時間を使ってほしくないなら、そもそも尋ねなければいい
問題の一部は、上司に「消えてくれ」と言いたくもないし、上司が20分の仕事だと思っているものに6時間使ったとも言いたくないところにある
だから代わりに、他のすべての仕事が後ろ倒しになる
優れたエンジニアリング管理が、意図せず技術者を釣り上げてしまう人たちから、エンジニアをできるだけ遠ざける理由だ
弱いマネジメントの典型的な兆候は、本人が全体的な含意を理解していないレポートを要求したり、作業を割り当てたりすること
弱いエンジニアリングの典型的な兆候は、その要求に「はい」と答えること
弱いマネージャーが、些細に処理できる範囲を超えたことを要求してきたら、作業者は技術的・社会的文脈に応じて次の3つのどれかをすべき
A) 「それはどうやればいいのですか？」と尋ねる
マネージャーが技術者で、自分の技術的な無能さを補うために曖昧に仕事を投げている場合に有効
そのたわごとをそのまま投げ返すと、自分が要求していることの範囲と、メカニズム上の現実に向き合わざるを得なくなる
B) 「その作業には X のリソースがかかります。期待値は何ですか？」と伝える
ここで X は膨大な人時、金、旧式の RuneScape GP など何でもあり得る
非技術系マネージャーに適しており、A と同様に、これはその場で承認するようなことではなく、通常の手続きを経るべき大きな要求であることに向き合わせる
C) 「いいえ」と言う
すべての組織やすべての社会的文脈で可能なわけではないが、高成果の組織はこれを可能にする
高成果のエンジニアリング環境では、エンジニアリング組織が筋の通らない無駄仕事に対して強い拒否権を持ち、Cレベルの上層部だけがそれを覆せる
この拒否権をいつどう行使するかを知ることも、エンジニアリングが育てるべき重要なスキルである
だからそれについて何を言っても、自分を出口の方へ押しやる結果になり得た
“ask” を名詞として使っているのを見るたびに言語感覚がむずむずするので調べたら、こんな投稿があった
https://english.stackexchange.com/questions/4246/can-or-shou...
同じように気になる人の役に立つかもしれない
要求に文脈が欠けているときが、最大級の時間の無駄の一つである
必要な人にだけ知らせることで時間を節約しようとしているように見えるが、「なぜ」と文脈は良い解決策を出すうえで本当に重要
それがないと、相手がすでに何を考えてみたのか分からない
たとえば「X 国からのリクエストをブロックしなければならない」と言われれば、たいていのファイアウォールサービスでは難しくない
しかし、なぜそうする必要があるのか
特定の国からトラフィックが発生しないという契約上の保証をしようとしているのなら、誰でも VPN で2分もあれば国コード検出を回避できるので、そのやり方は通用しない
ユーザーは X をしたいが方法が分からず、Y ならうまくいくと思って Y について助けを求め、他の人たちは Y が妙に見えて混乱する
https://xyproblem.info/
すでに多くの人がその丘で討ち死にし、それでも実装された
また別の犠牲者にならないほうがいい
結局のところ、会社の文化と、人々がシニアリーダーにどれだけ気軽に反論できるかに大きく左右される
その負担は、下の人たちが反論しやすいようにすべきシニアリーダーにある
経験上、最高のリーダーは謙虚で、聞こうとする姿勢を見せる
ただし、ときには無駄仕事をすることも仕事の一部である
あまりに多いなら当然ほかの仕事を探せばいいが、常に経営陣を疑って問い返す人にはならないほうがいい