- Authors

- Name
- Youngju Kim
- @fjvbn20031
- はじめに: 二週間を無駄にした日
- 核心の洞察: 方向は仕事を与えた人が知っている
- 定期的なアラインメントの価値: ドリフトを防ぐ錨
- 共有の利得: 失うもののない取引
- 質問の技術: 賢く聞く
- 期待値の管理: 何が合意されたか確認せよ
- 事例: 会話の例
- 落とし穴: 過剰報告を戒めよ
- 1対1ミーティングを積極的に活用せよ
- リモート・非同期環境でのSync
- よくある質問 (FAQ)
- 何を聞くか分からないとき: アラインメント感覚を育てる
- 共有の頻度は仕事の段階による
- 信頼はアラインメントから育つ
- 実践法: Syncルーティンを作る
- 聞くのを先延ばしにするコスト
- おわりに: 一人で速くより、一緒に正しく
- 参考資料
はじめに: 二週間を無駄にした日
新人の頃、私は「言わなくてもちゃんとやる人」になりたいと思っていました。仕事を受けたら聞かずに一人で最後まで掘り下げ、完成した成果物で驚かせたかったのです。だから一度、二週間の作業を受け、その間ほとんど報告しませんでした。途中で聞いたら「これくらい一人でできないのか」と思われるのではと怖かったのです。
二週間後、私は誇らしげに成果物を持って行きました。そして上司の最初の一言。「あれ? これ、その方向じゃなかったんだけど。」
私が作ったものは、よくできた、しかし間違ったものでした。要件を自分流に解釈し、その解釈が最初からずれていたのです。もし三日目に一度でも「こう進めていますが合っていますか」と聞いていたら、二週間ではなく三日だけの損で済んだはずです。
その日に気づいたことがあります。自分のしていることが正しいかは、仕事を与えた人が最もよく知っている。 私は「どう」の専門家ですが、「何を、なぜ」の専門家はその仕事を定義した人です。一人で長く走るのはかっこよく見えますが、間違った方向にかっこよく走れば、ただ速く遠ざかるだけです。
この文章は「こまめに聞け」という単純な助言を超えて、なぜ定期的なSyncが能力の表現なのか、そしてどう賢く聞くかについてです。
核心の洞察: 方向は仕事を与えた人が知っている
ここで指摘すべき認知バイアスが二つあります。どちらも私たちを一人で走らせる罠です。
バイアス1: 上司の記憶力の過大評価
私たちはよく、上司が自分の受けた仕事をはっきり覚えていると仮定します。「この前言ったから分かっているだろう。」しかし現実は違います。上司は私以外にも十の別の仕事を同時に処理していて、私に仕事を与えたその瞬間の文脈は、彼の頭の中で素早く薄れていきます。
私の人生の100%であるその作業が、上司にはその日処理した二十のうちの一つにすぎません。だから「当然覚えているだろう」という仮定は危険です。むしろ逆に仮定するほうが安全です。上司の記憶力は過小評価せよ。 つまり、上司は忘れただろうと前提し、文脈を思い出させながら共有せよ、ということです。「先週いただいたあの作業、こう進めています」と思い出させるのは、小言ではなく配慮です。
バイアス2: 上司の勘の過大評価
もう一つの仮定は、上司が仕事の進み具合を「勘」で分かるだろうという信念です。「私が詰まれば気づくだろう」「問題が起きれば先に聞いてくれるだろう。」しかしテレパシーはありません。上司は私が報告していないことを知ることができません。
特に無沙汰を吉報と解釈する罠がよくあります。私が静かだと、上司は「うまくいっているのだろう」と思い、「もしかして詰まっているのか」とは思いません。だから沈黙はしばしば「問題なし」という誤ったシグナルを送ります。
上司の記憶力は過小評価し、上司の勘は過大評価するな。その隙間を埋めるのが、まさにあなたの共有だ。
この二つのバイアスを総合すると結論は一つです。上司が自分で覚え、自分で察してくれると期待するな。アラインメントは私が能動的に作らなければならない。そしてそのアラインメントの核心は「自分の進む方向が正しいか」を確認することであり、その答えは仕事を定義した人にあります。
定期的なアラインメントの価値: ドリフトを防ぐ錨
方向がずれることを「ドリフト(drift)」と呼びましょう。船が潮に流されて少しずつ針路を外れるように、作業も時間とともに本来の意図から少しずつ遠ざかります。
ドリフトの恐ろしい点は、それが複利で累積することです。初日の1度の差はわずかです。しかしその1度を放置すると、遠くへ行くほど到着地点は意図と大きく開きます。
ドリフトとアラインメント
意図した方向
─────────────────────────────────→ 目標
\
\ ドリフト(こまめにsyncしない)
\
\
\___________________ 見当違いの場所に到着
意図した方向
──┬───┬───┬───┬───┬──────────────→ 目標
↑ ↑ ↑ ↑ ↑
定期的なsyncで毎回針路を補正
定期的なSyncはこのドリフトを捉える錨です。よく確認するほど、一度のずれが小さいうちに発見して直せます。アラインメントのコストは小さく頻繁に払うほど安くなり、先延ばしにしてまとめて払うほど高くなります。まさにはじめにで述べたあの二週間の損のように。
ここにはアジャイル開発が短い反復周期(スプリント)とデイリースタンドアップを置く理由と同じ哲学があります。長いウォーターフォール方式が危険な理由は、最後になって方向が間違っていたと発見するからです。短い周期でよく確認すれば、間違っても小さく間違い、速く正します。個人の働き方にも同じ原理が当てはまります。
共有の利得: 失うもののない取引
こまめに共有して聞くことが損だと感じるかもしれません。「余計に煩わせているのでは」「能力がないように見えるのでは。」しかしコストと利得を計れば、共有はほとんど失うもののない取引です。
| 項目 | 共有しないとき | こまめに共有するとき |
|---|---|---|
| 方向の誤り | 最後になって発見、全体やり直し | 早く発見、小さく修正 |
| 上司の安心 | 無沙汰に不安、マイクロマネジメント誘発 | 進捗が透明、信頼形成 |
| 詰まった問題 | 一人で苦しむ、時間の無駄 | 素早く助けを得る |
| 貢献の可視性 | 黙々とやったが見えない | 過程が見え認められる |
| 優先順位の変化 | 知らずに旧方向を固守 | 素早く再調整 |
よくある誤解を指摘すると、こまめに聞くことが無能のシグナルだという考えです。実は正反対です。賢い質問は能力のシグナルです。「方向が正しいか確認したい」というのは、時間を無駄にしないプロの態度です。逆に、二週間無駄にした成果物を持ってくることこそ本当の無能に見えます。
もう一つの利得は「貢献の可視性」です。黙々と一人で働くと、その努力と思考過程が誰にも見えません。結果だけが評価されます。しかし過程を共有すれば、あなたがどんな困難をどう乗り越えたかが見えます。これは自己PRではなく正当な可視化です。見えない仕事はなかったことになりやすいのです。
質問の技術: 賢く聞く
「こまめに聞け」が「何でもかんでも聞け」ではありません。質問にも技術があります。賢い質問は相手の時間を節約しながら、自分の必要な答えを正確に得ます。
1. 閉じた質問と開いた質問を使い分ける
方向の確認は閉じた質問がよいです。「どうすればいいですか」より「Aで行こうと思いますが、Bという選択肢もあります。Aが合っていますか」のように具体的な選択肢を与えれば、相手ははい・いいえに近く素早く答えられます。
2. 手ぶらで聞かない
最も悪い質問は「これどうやるんですか」です。最も良い質問は「これを試してみて、こう詰まりました。私の考えではAですが、どう見ますか」です。自分の仮説を持って聞けば、相手は最初から説明する必要なく、私の仮説を検証してくれるだけで済みます。
3. 5分ルールと30分ルール
いつ聞くか迷うとき役立つ経験則です。些細な詰まりはまず自分で短く(例: 15-30分)試してみます。その時間を超えても進展がなければ、これ以上一人で抱えるのは時間の無駄です。一人で苦しむ時間と聞くコストを天秤にかける習慣をつけてください。
4. 聞く前に自分で点検
良い質問の前に自問すること。
- この答えはすでにドキュメントやコードにないか
- 自分が試したことを整理したか
- 自分の持つ仮説を明確にしたか
- 相手が答えやすい形に整えたか
5. 非同期で聞けるなら非同期で
緊急でない質問はメッセージで残します。相手が都合のよいときに答えられ、答えが記録に残ります。即時の対話がどうしても必要なときだけ直接呼びます。
期待値の管理: 何が合意されたか確認せよ
こまめにSyncすることの本質は「期待値の管理(expectation management)」です。葛藤と失望の大半は能力不足ではなく期待値の不一致から来ます。私はAを作っているのに相手はBを期待していた、というように。
期待値を合わせる核心の瞬間は仕事の開始時と進行中です。
仕事を受けるとき: 言い直してみる
仕事を受けたら、自分の言葉で整理して確認します。「私が理解したところでは、XをYの方式でZまで作ればよいのですよね。締め切りはいつまでですか。」この一度の確認が最初の誤解を捉えます。人は聞いたものを自分流に解釈しがちで、その解釈を声に出して検証しなければずれを発見できません。
特に次を明確にします。
- 何が「完了」か(完了の定義)
- いつまでか(締め切りと優先順位)
- どの程度の品質・範囲か(ざっと速く vs 完璧に)
- 誰のためのものか(最終の読者・利用者)
進行中: 仮定を表に出す
作業中に自分が下した決定と仮定を表に出します。「要件に明記されていない部分はこう仮定して進めます」と共有すれば、その仮定が間違っていたとき相手が正してくれます。沈黙の中の仮定が最も危険です。
期待値の管理には「アンダープロミス、オーバーデリバー(under-promise, over-deliver)」という古い知恵があります。できることを正直に約束し、可能ならそれ以上をやり遂げること。守れない約束をして失望させるより、守れる約束をして信頼を築くほうがよいのです。
事例: 会話の例
抽象的な原則を具体的な会話で見ましょう。
仕事を受ける瞬間
良くない例 上司: 「今回、検索機能をちょっと改善してください。」 私: 「はい、分かりました。」(内心: 検索をどう改善しろと? とりあえずやってみよう。)
良い例 上司: 「今回、検索機能をちょっと改善してください。」 私: 「はい。確認のため伺うと、今いちばんの不便は速度ですか、精度ですか。そして今スプリント内に終えるべきですか、それとも次のリリース目標ですか。」 上司: 「速度が問題です。今スプリント内に一次改善ならうれしいです。」 私: 「分かりました。では速度優先で、今スプリントはインデックス改善まで行い、精度は次に回します。三日ほど後に中間の方向を一度お見せします。」
進行中の点検
「検索作業の中間共有です。現在インデックス方式をAに変えて応答速度が半分になりました。ただ進めるうちに、精度が少し下がるトレードオフが見えます。速度優先とのことなので、このまま行ってよいですか、それとも精度も一定水準の維持が必要ですか。」
この短い共有一つが、数日後の「なぜ精度が下がったのか」という追及をあらかじめ防ぎます。トレードオフを一人で決めずに表に出すこと — これが成熟したSyncです。
落とし穴: 過剰報告を戒めよ
ここまでこまめに共有せよと強調してきましたが、すべてにバランスがあります。過少共有がドリフトを生むなら、過剰共有は別の問題を生みます。
落とし穴1: あまりに頻繁な妨げ
5分ごとに些細なことを聞けば、相手の集中を絶えず断ちます。特に深い作業(deep work)中の人に頻繁な割り込みは大きなコストです。まとめて一度に聞くか、非同期で残せるものは非同期で残す分別が必要です。
落とし穴2: 責任の押し付け型の質問
自分で考えもせず「これどうやるんですか」だけを繰り返せば、それはアラインメントではなく意思決定の押し付けです。質問は「自分が考えた」という前提の上で価値があります。自分の仮説のない質問の繰り返しは信頼を削ります。
落とし穴3: 共有のための共有
報告のための報告、形式を埋めるアップデートはノイズです。「今日も頑張りました」のような中身のない報告は、かえって肝心の重要なシグナルを埋もれさせます。共有は相手の意思決定に影響を与えるか、方向を確認するときに価値があります。
落とし穴4: 自律性の喪失
すべてを確認してもらおうとすると、自分で判断し責任を負う能力が育ちません。シニアになるほど、何を一人で決め何を確認してもらうかを見分ける判断力が重要になります。小さな決定は自分で、戻しにくい大きな決定は確認してもらう、という分別が必要です。
バランスを見つける問いはこうです。「この決定が間違ったとき、戻すコストが大きいか。」コストが大きく方向に関わるものほど確認してもらい、小さく戻しやすいものほど自分で決めます。アマゾンのジェフ・ベゾスが言った「戻せる決定(two-way door)」と「戻せない決定(one-way door)」の区別がここで役立ちます。
1対1ミーティングを積極的に活用せよ
多くの会社に上司との定期的な1対1ミーティング(one-on-one)があります。ところが多くの人がこの時間を受動的に流してしまいます。上司が聞くことに答えるだけで終わる、という具合に。これは大きな無駄です。1対1は上司の時間ではなくあなたの時間です。
インテルの伝説的CEOアンディ・グローブは『ハイ・アウトプット・マネジメント(High Output Management, 1983)』で、1対1ミーティングは部下が主導すべきだと強調しました。彼は1対1を「部下のミーティング(subordinate's meeting)」と呼びました。議題を部下が準備し、部下が導くのが理想だというのです。
1対1をうまく使う方法はこうです。
- あらかじめ議題を準備する。「今回はこの三つを相談したいです。」
- 方向確認をここでする。普段些細なことで妨げない代わりに、まとめて1対1でアラインメントする。
- 期待値を合わせる。「私はうまくやれているか」「優先順位は合っているか」を明示的に聞く。
- フィードバックを請う。「私がもっとうまくやれる部分はありますか。」
1対1ははじめにで述べたあの「二週間の無駄足」を防ぐ定期的な安全網です。週に一度でも方向を合わせる場があれば、ドリフトは一週間分を超えません。
リモート・非同期環境でのSync
分散したチーム、在宅勤務、異なるタイムゾーン。現代の職場では、隣の席にそっと聞くことがますます減ります。物理的に離れているほど、Syncはより意図的でなければなりません。
リモート環境の最大の落とし穴は「孤立したまま静かにドリフトすること」です。オフィスなら通りすがりに「あれどうなってる?」と聞けますが、リモートではそうした偶然のアラインメントが消えます。だから能動的な共有がオフィスよりはるかに重要になります。
リモート・非同期環境のSync実践はこうです。
- 進捗を文字で残す。聞かれる前にまず見えるようにする。公開チャンネルの短いアップデートが、見えない仕事を見えるようにする。
- 「無沙汰が吉報」という仮定を破る。リモートで沈黙はより危険だ。うまくいっていてもうまくいっていると言う。
- 非同期を基本に、同期を例外に。緊急でないものはメッセージで、速い合意が必要なものだけ通話で。
- 時差を尊重して明確に書く。相手が起きていなくても一人で理解できるよう、文脈を十分に含めて聞く。
リモートで信頼される人の共通点は「見えるように働くこと(working visibly)」です。華やかな成果発表ではなく、地道で透明な小さな共有の積み重ねです。
よくある質問 (FAQ)
あまりに頻繁に聞くと無能に見えませんか。
質問の質次第です。自分の考えなしに「これどうやるんですか」だけを繰り返せば無能に見えます。しかし「Aで行こうと思いますがBの可能性も見えます。どう見ますか」のように仮説を持った質問は、かえって有能に見えます。核心は頻度ではなく質です。賢い質問は多くしても信頼を築き、怠けた質問は一度でも信頼を削ります。
上司が忙しすぎて聞く隙がありません。
非同期を活用してください。忙しい上司ほど即時の対話よりよく整理されたメッセージを好みます。「確認必要: Aで進めようと思いますが大丈夫ですか。返信なければ明日午前までにAで進めます」のように、デフォルトの行動を決めて聞く方式もよいです。すると上司は反対するときだけ答えればよくなります。そして1対1ミーティングがあれば、その時間にまとめてアラインメントしてください。
一人で解決するほうが成長に良くないですか。
バランスの問題です。すべてを即座に聞けば自分で考える筋肉が育ちません。逆にすべてを一人で抱えれば時間を無駄にし、悪い習慣を固めます。お勧めの方式は「まず閾値の分だけ一人で試し、その中で仮説を作った後、詰まれば仮説と一緒に聞く」です。これで一人で考える訓練にもなり、時間の無駄も防ぎます。答えをもらう前に自分の答えを持っていること自体が学習です。
聞いたのに「自分で考えてやれ」という答えが来たら。
良いシグナルです。上司があなたにその決定を委ねたのです。このときは自信を持って決めつつ、決めた内容を短く共有しておいてください。「おっしゃるとおりAで進めました」と。すると上司は方向がずれたときだけ介入すればよくなります。委ねられた自律性をうまく使うことが、より大きな委任を受ける道です。
同僚同士もSyncが必要ですか。上司とだけすればよいのでは。
むしろ同僚間のSyncのほうが重要なときが多いです。同じコードベースを触る同僚、自分の成果物を受け取って使う同僚、依存関係にあるチーム — 彼らとのアラインメントがずれると、統合段階で大きな衝突が起きます。「私はこのインターフェースで作るけど大丈夫?」の一言が、数日後の統合地獄を防ぎます。方向を定義する人が上司なら、自分の作業とかみ合う人は同僚です。どちらもアラインメントの対象です。
毎回確認すると主体性がないように見えませんか。
確認の種類を区別すればよいです。「これどうしましょう?」は主体性がないように見えます。しかし「私はAでやろうと思います。理由はこうです。私が知らない文脈はありますか?」は主体性を持ちつつアラインメントすることです。核心は決定を押し付けることではなく、自分の判断を見せて検証してもらうことです。自分の意見なしに聞くことと、意見を持って確認することは、全く違う印象を与えます。
何を聞くか分からないとき: アラインメント感覚を育てる
「こまめに聞け」という助言で詰まる地点があります。「何を聞くべきかさえ分からない。」特に新人ほど、自分が何を知らないのかさえ分からない状態(unknown unknowns)によく陥ります。こんなとき漠然と「うまくいっていますか」と聞けば、中身のない会話になります。
アラインメント感覚、つまり「今何を確認すべきか」を知る能力は育てられます。いくつかの手がかりがあります。
- 仮定を点検せよ。作業しながら「これは当然こうだろう」と流した地点があります。その仮定こそ確認すべき候補です。当然だと思ったものが最もよく間違います。
- 分岐点を探せ。作業中「Aで行くかBで行くか」分かれた瞬間。その選択が方向を左右するなら確認候補です。
- 戻すコストを計れ。今の決定が間違ったとき戻しにくいものほど、前もって確認する価値が大きいです。
- 沈黙している領域を見よ。要件に明記されておらず、自分が任意で埋めた部分。その空欄が危険地帯です。
はじめにの二週間の事例で、私が見落としたのはまさに「要件を自分流に解釈したその仮定」でした。その仮定を一度だけ声に出して確認していたら、すべてが違ったはずです。アラインメント感覚の核心は結局「自分が無意識にした仮定を意識的に引き出すこと」です。
この感覚は経験とともに育ちます。最初は何を聞くか分からず迷いますが、ドリフトを何度か経験すれば「ああ、こういう地点で確認すべきだったんだ」が体に染みつきます。だから初期のぎこちない質問を恐れないでください。それがアラインメント感覚を育てる授業料です。
実戦のコツとして、作業を始める前に「今自分がしている仮定三つ」を書いてみてください。例えば「この機能はログインしたユーザーだけが使う」「データはリアルタイムでなくてよい」「既存のAPIを再利用する」のようなもの。この仮定リストを上司や同僚に一度見せるだけで、隠れていたずれの半分が表に出ます。仮定を文字に書いた瞬間、頭の中で当然だったものがようやく検証可能な命題になります。
アラインメントの技術は、答えをよく知ることではなく、何を知らないかをよく知ることだ。
共有の頻度は仕事の段階による
「こまめにSyncせよ」が「常に同じ頻度で報告せよ」という意味ではありません。良い共有は仕事の段階と危険度に応じて頻度を調整します。すべての瞬間に同じ強度で報告すれば過剰になり、すべての瞬間に沈黙すればドリフトになります。
おおよそのガイドはこうです。
- 開始段階: アラインメントを密に。方向が最もずれやすいときなので、初期に頻繁に確認します。最初の成果物の小さな断片を早く見せてフィードバックを受けます。
- 安定段階: アラインメントを緩く。方向が確定し順調なら、わざわざ頻繁に妨げる必要はありません。軽い進捗共有で十分です。
- 分岐・危険段階: 再び密に。重要な決定地点や危険信号が見えれば、頻度をすぐに上げます。
核心の原則は「不確実性が高いときはより頻繁に、低いときはより少なく」です。不確実性が アラインメントの頻度を決めるべきであって、習慣や形式が決めてはなりません。こう調整すれば、過剰報告の落とし穴も避け、ドリフトの危険も減らします。
もう一つ、共有には「プッシュ」と「プル」があります。プッシュは私が先に知らせること、プルは相手が必要なときに見られるようにしておくことです。重要で急ぐものはプッシュで直接知らせ、参考用の進捗はプルで(共有ドキュメントやボードに)残しておけば、相手が望むとき自分で確認できます。この二つを適切に混ぜれば、共有の効率が大きく上がります。
信頼はアラインメントから育つ
こまめにSyncすることの最大の報酬は、実は「信頼」です。そして信頼は自律性として返ってきます。これは直観と反対のように見えます。よく確認する人がどうしてより大きな自律性を得るのでしょうか。
そのメカニズムはこうです。私が進捗を透明に、予測可能に共有すれば、上司は私を「安心して任せられる人」と認識します。悪い知らせも早く知らせ、方向がずれそうなら先に確認する人。こういう人にマイクロマネジメントをする理由はありません。むしろ「この人は自分でうまくアラインメントするから、もっと大きなものを任せてもよい」という信頼が積み重なります。
逆に、共有せず一人で走る人は逆説的により多くの干渉を呼びます。上司は進捗が見えないので不安になり、不安だと何度ものぞき込みます。沈黙がマイクロマネジメントを呼ぶのです。自律性を望むなら、まず透明性を与えなければなりません。
ここに重要な転換があります。Syncは「許可を求めること」ではなく「信頼を築くこと」です。毎回決定を押し付けるために聞くのではなく、「私はこう進んでいて、こういう判断をしました」と見せることです。こうした共有が積み重なれば、上司はますます少なく確認し、ますます多く委任します。
信頼の好循環はこう働きます。
| 段階 | 行動 | 結果 |
|---|---|---|
| 1 | 透明にこまめに共有 | 予測可能性が形成される |
| 2 | 悪い知らせも早く伝える | 正直さへの信頼 |
| 3 | 小さな判断をうまくこなす | 力量への信頼 |
| 4 | 上司が干渉を減らす | 自律性が拡大する |
| 5 | より大きな仕事を任される | 成長が加速する |
結局「こまめに聞くこと」が「あまり干渉されないこと」につながる逆説。これがアラインメントが与える最大の贈り物です。
実践法: Syncルーティンを作る
こまめにSyncすることを意志ではなく習慣にするためのルーティンです。
1. 開始アラインメント (Kickoff Sync)
新しい作業を受けたら、始める前に5分のアラインメントをします。理解したことを自分の言葉でなぞり、完了の定義・締め切り・優先順位を確認します。
2. 定期チェックイン (Regular Check-in)
作業の長さに比例して中間チェックインを設けます。二週間の作業なら少なくとも三日に一度は方向を確認します。「静かに全部作って驚かせる」誘惑を捨てます。
3. 詰まりの閾値を決める
一人で抱える時間の上限をあらかじめ決めます。その時間を超えたら、仮説を整理して聞きます。
4. 軽い非同期アップデート
大げさな報告ではなく、一、二行の進捗共有を習慣化します。「X終了、今Y中、Zで決定が必要」のように。
Sync実践チェックリスト
- 仕事を受けるとき自分の言葉でなぞって確認したか
- 完了の定義と締め切りを明確にしたか
- 方向がずれうる作業で早く確認したか
- 詰まったとき決めておいた閾値内で聞いたか
- 質問するとき自分の仮説も一緒に示したか
- トレードオフを一人で決めず表に出したか
- 過剰報告で相手を妨げていないか
聞くのを先延ばしにするコスト
最後に、聞くのを先延ばしにすることの本当のコストを指摘したいです。私たちはよく「もう少しやってみてから聞こう」と先延ばしにします。その先延ばしの理由はたいていプライドです。知らないと認めたくなく、一人で解決した姿を見せたく、妨げになるのではと躊躇します。
しかし先延ばしのコストは時間が経つほど大きくなります。第一に、間違った方向にさらに深く入り、戻すのが難しくなります。第二に、遅く聞くほど「なぜ早く聞かなかったのか」という反応を受けやすく、かえってより無能に見えます。第三に、その間に積もったストレスと詰まりがほかの仕事まで台無しにします。
はじめにの二週間が、まさにこの先延ばしの結果でした。三日目に聞いていれば三日の損、それをプライドのために先延ばしして二週間を失いました。先延ばしにしたプライドのコストが、早く聞いたときの気まずさよりはるかに大きかったのです。
覚えておいてください。早く聞くことは弱点を出すことではなく、時間を節約する強さです。気まずさは五分ですが、先延ばしのコストは数日です。二つを天秤にかければ、答えはいつも明らかです。
おわりに: 一人で速くより、一緒に正しく
もう一度、あの無駄にした二週間に戻ります。あのときの私は「言わなくてもちゃんとやる人」になりたかったのに、実際にやったのは「一人で間違った方向に速く走ること」でした。本当に「ちゃんとやる人」は聞かない人ではなく、いつ何を聞くべきか分かる人でした。
こまめにSyncすることは依存ではありません。アラインメントです。私が「どう」の専門家なら、方向を定義した人は「何を、なぜ」の専門家です。その二つの専門性をこまめにかみ合わせることが協業の本質です。
上司の記憶力は過小評価し(忘れただろうと前提して思い出させ)、上司の勘は過大評価するな(テレパシーはないので能動的に共有せよ)。その間の隙間を埋める小さな共有たちが、二週間の無駄足を防ぎ、信頼を築き、結局より良い結果を作ります。
すべてを一文に縮めるとこうです。アラインメントは弱点ではなく強みだ。聞くことは足りないからではなく、時間を節約し信頼を築く最も賢い方法だ。そしてその賢さは練習で育つ — 何をいつ聞くべきか、何を一人で決め何を確認すべきか、その感覚はぎこちない初期の質問を経て育つ。
一人で速く行くより、一緒に正しく行くこと。そのほうが遠くまで行けます。
参考資料
- Larson, W. An Elegant Puzzle: Systems of Engineering Management (2019) および lethain.com (https://lethain.com).
- Grove, A. (1983). High Output Management. Random House. (1対1ミーティングとアラインメント)
- Beck, K. et al. (2001). Manifesto for Agile Software Development (https://agilemanifesto.org).
- Bezos, J. Amazon Shareholder Letter (2015) — two-way door の決定 (https://www.aboutamazon.com).
- Harvard Business Review, "What Great Managers Do" (https://hbr.org).
- Clear, J. on feedback loops (https://jamesclear.com).