言われた通りにやるな、なぜを掴め — マネージャーと働く技術

• はじめに：「ボタンを青くしてくれますか」
• 1. すべての依頼の背後には意図がある
• 2. 丁寧に「なぜ」を尋ねる方法
  • 2.1 意図を先に明かす
  • 2.2 閉じた質問ではなく開いた質問で
  • 2.3 「聞いた後に言い直して確認」する
• 3. より良い代替案を提示する
• 4. アップワード・マネジメント — マネージャーを管理するとは
  • 4.1 マネージャーの「取扱説明書」を掴む
  • 4.2 驚かせない(No Surprises)
• 5. 1on1ミーティングをきちんと使う方法
• 6. フィードバックを授受する技術
  • 6.1 フィードバックを受けるとき
  • 6.2 フィードバックを与えるとき(上向きを含む)
• 7. バランスを取る — これは万能ではない
• 8. 事例：同じ依頼、違う結果
• 9. アラインメントの会話 — 最初から最後まで
• 10. よくあるアンチパターン五つ
  • 9.1 尋ねずに推測で作る
  • 9.2 すべてに口を挟む
  • 9.3 同意しておいて陰で別のことを言う
  • 9.4 悪い知らせを隠す
  • 9.5 結果ではなく労力だけを報告する
• 11. アラインメントは一度きりではなく習慣だ
• 12. 実践チェックリスト
• おわりに
• 参考資料

はじめに：「ボタンを青くしてくれますか」

ある金曜の午後、マネージャーがSlackでメッセージを送ってきます。「決済ボタンを青くしてもらえますか。来週月曜のデモの前までに」

ここで二種類のエンジニアに分かれます。

一人目のエンジニアはすぐにCSSを開き、色コードを青に変え、プルリクエストを出します。30分で完了。効率的に見えます。

二人目のエンジニアはもう一つ尋ねます。「はい、可能です。青くしたい理由は何かありますか。デモで強調したい部分があれば、もっと合う方法を提案できるかもしれません」

マネージャーが答えます。「ああ、実は前回のデモで顧客が決済ボタンを見つけられないと言ったんです。もっと目立たせたくて」

この瞬間、問題は完全に変わります。「ボタンを青く」は解決策でしたが、本当の問題は「決済ボタンが目立たない」でした。青はむしろ自社のブランド背景色に近く、かえって見えにくくなるかもしれません。二人目のエンジニアは、コントラストの強い色、位置の調整、わずかな影など、より良い選択肢を提案できます。

この記事は「言われた通りに働くな」という話ではありません。正確に言えば、依頼の表面ではなく、その背後の目的を掴み、その目的を最もよく達成する方向で働けという話です。そしてそれは反抗ではなく、マネージャーと共により良い結果を作る協働の技術です。

1. すべての依頼の背後には意図がある

依頼は氷山の一角です。水面上に見える「何を(what)してほしい」という言葉の下には、「なぜ(why)それが必要か」というはるかに大きな塊が沈んでいます。

        「ボタンを青く」          <- 表面(提案された解決策)
   ─────────────────────────────  水面
        「決済ボタンが見えない」    <- 問題
        「デモで転換率を見せたい」   <- ビジネス目標
        「今四半期の売上プレッシャー」 <- より大きな文脈

マネージャーが解決策を先に言うのには理由があります。彼らも忙しく、頭の中ですでに「こうすればいい」と一度答えを出しているからです。しかしその答えは、マネージャーが持つ情報と時間の中で出た暫定的な解にすぎません。その領域を毎日見つめているのはあなたです。

ここで肝心なのは態度です。「なぜですか」と尋ねるのは詰問ではなく、もっとうまく手伝うために文脈をくださいという合図であるべきです。同じ質問もトーンによって全く違って聞こえます。

• 悪い例：「これ、本当にやる必要ありますか」(抵抗に聞こえる)
• 良い例：「これで達成したいことを教えていただければ、その目標に最も合うように作れます」(協力に聞こえる)

2. 丁寧に「なぜ」を尋ねる方法

「なぜ」を尋ねるのが危険に感じられるのは、尋ね方を誤ると無能あるいは非協力的に見えるのを恐れるからです。だから質問には技術が要ります。

2.1 意図を先に明かす

質問の前に「なぜ尋ねるのか」を添えると、防御的な反応が消えます。

[目的の宣言] + [質問]

「より良い方法を提案したいので — この機能で解決したいユーザーの問題は何でしょう」
「優先順位を正確に合わせたいので — これが今週中に終わる必要がある理由はありますか」
「見当違いのものを作らないために — このレポートを誰が、どんな決定に使いますか」

2.2 閉じた質問ではなく開いた質問で

「これ、必ず青でないとだめですか」はイエス/ノーで終わり、それとなく反対のように聞こえます。代わりに文脈を引き出す開いた質問を使います。

• 「この変更でどんな結果を期待していますか」
• 「成功したとどうやって分かりますか」
• 「これを見るのは誰ですか」

2.3 「聞いた後に言い直して確認」する

聞いたことを自分の言葉で整理し直して確認すると、誤解を早期に捉え、マネージャーに「ちゃんと聞いている」という信頼を与えられます。

「理解が合っているか確認します。顧客がデモで決済ボタンを見つけられず、
月曜のデモではそれが明確に見えてほしい — 合っていますか。
であれば、色だけ変えるより、位置とコントラストも一緒に直すことを提案したいです」

3. より良い代替案を提示する

「なぜ」を掴んだら、いよいよ単なる実行者から問題解決者へ上がる番です。ただしここには定番の落とし穴があります。自分のアイデアに惚れ込み、マネージャーの本来の依頼を無視することです。

良い代替案の提示は、常にマネージャーの目標を認めることから始まります。

[目標の承認] → [元案の限界] → [代替案] → [トレードオフ] → [決定権を返す]

「決済ボタンが目立つべきだという点には完全に同意します(目標の承認)。
ただ青は自社の背景に近く、かえって埋もれかねません(限界)。
コントラストの強いオレンジで位置を上げれば、より確実に見えるはずです(代替案)。
ただオレンジは一次ブランドカラーではないので、デモ用だけに使い、
後でデザインチームと正式な色を決める手もあります(トレードオフ)。
どちらの方向がよいでしょう(決定権はマネージャーに)」

最後の一行が重要です。代替案を押し付けず決定権をマネージャーに戻せば、あなたは「自分が正しい」と言い張る人ではなく、「選択肢を広げる」人になります。マネージャーが最終的に元案を貫いても構いません。あなたが見えていない文脈(法務要件、経営陣への約束など)があるかもしれず、何より責任はマネージャーが負います。意見を十分に述べたなら、決定にはきれいに従います。これをよく**「同意しなくとも、決まれば全力で従う(disagree and commit)」**と呼びます。

4. アップワード・マネジメント — マネージャーを管理するとは

「マネージャーを管理する」という言葉に違和感を覚えるかもしれません。権限もないのにどうやって上を管理するのかと。しかしここでの管理は統制ではなく、関係を能動的に運営することを意味します。マネージャーが自分をうまく助けられるよう、自分から先に情報を出し方向を合わせる仕事です。

4.1 マネージャーの「取扱説明書」を掴む

人それぞれ働き方が違います。マネージャーも同じです。次を観察するか、直接尋ねましょう。

4.2 驚かせない(No Surprises)

マネージャーが最も嫌うのは悪い知らせそのものではなく、悪い知らせを後から、別の人を通して聞くことです。スケジュールが遅れそうなら、締切当日ではなく数日前に知らせます。

悪い例(締切当日):
「すみません、今日は終わりそうにありません」

良い例(3日前):
「進捗を共有します。API連携で想定外の認証問題が出て、
既存スケジュールより二日ほど多くかかりそうです。二つの方法があります:
(1) 認証部分を次スプリントに回し、残りを先にデプロイするか、
(2) スケジュールを二日延ばすか。どちらがよいですか」

後者は単なる報告ではなく、選択肢を整理してマネージャーの意思決定を楽にします。これが信頼を築く方法です。

5. 1on1ミーティングをきちんと使う方法

1on1はマネージャーの時間ではなく、あなたの時間です。よくある誤解は1on1を単なる進捗報告で埋めることですが、進捗はSlackや文書でも伝えられます。顔を合わせる30分は、より深い対話に使うべきです。

事前に議題を書いて持っていくだけで、1on1の質が変わります。

[1on1 議題テンプレート]

1. 詰まっている所 / 助けが必要なこと
   - X の決定にマネージャーの意見が必要です。

2. アラインメント確認
   - 来四半期の優先順位を私はこう理解していますが、合っていますか。

3. フィードバック依頼
   - 前回の発表はどうでしたか。改善点はありますか。

4. 成長 / キャリア
   - シニアへ進むにはどんな力をもっと伸ばすべきですか。

5. 上へ伝える情報
   - チームで Y の問題が繰り返されていて、知っておくとよさそうです。

特に4番(成長)と3番(フィードバック依頼)は後回しにしがちですが、最も価値が大きいです。フィードバックは待っても来ません。先に、具体的に依頼してこそ役立つ答えが返ります。「私どうですか」ではなく「前回の設計レビューで私の説明は明確でしたか。もっと説得力を持たせるには」のように。

6. フィードバックを授受する技術

6.1 フィードバックを受けるとき

防御は本能です。誰かが自分の仕事について否定的なことを言うと、心拍が上がり言い訳が先に飛び出します。しかしその瞬間に防御すると、相手は次から率直なフィードバックをくれなくなります。

• まず聞く。反論する前に最後まで聞きます。
• 具体化する。「いまいちだった」という漠然とした言葉には「どの部分か例を挙げてもらえますか」と返します。
• 感謝する。同意しなくても、時間を割いて言ってくれたことには感謝します。
• 後で判断する。その場で全部受け入れたり拒否したりする必要はありません。「考えてみます」も良い答えです。

6.2 フィードバックを与えるとき(上向きを含む)

マネージャーにもフィードバックを与えられます。ただし方法が重要です。SBIモデル(状況-行動-影響)が有用です。

[状況 Situation] 前回のスプリント会議で
[行動 Behavior]  途中で優先順位が三回変わり
[影響 Impact]    チームが何に集中すべきか混乱しました。

→ 人ではなく行動とその結果に焦点。
  「あなたは気まぐれだ」(人格攻撃) X
  「優先順位が頻繁に変わると混乱する」(行動・影響) O

上向きのフィードバックは私的な場で、非難ではなく改善提案の形で伝えます。良いマネージャーなら歓迎し、そうでなくとも試み自体があなたの主体性を示します。

7. バランスを取る — これは万能ではない

ここまで読んで「では全ての依頼にいちいちなぜと尋ねるのか」と思ったなら、それは行き過ぎです。バランスが必要です。

• 些細で明確なことはそのままやる。 誤字修正に「なぜ直すのですか」と尋ねるのは時間の無駄です。
• 緊急時はまずやって後で尋ねる。 障害時に「まず根本原因を議論しましょう」は不適切です。先に火を消し、振り返りでなぜを論じます。
• 信頼残高を見る。 入社直後なら、まず忠実に実行して信頼を築くほうがよいです。信頼が積もれば「なぜ」を尋ね代替案を出す余地も広がります。
• 繰り返すパターンに集中する。 一度の依頼より、繰り返される非効率や方向のずれに「なぜ」を当てるほうが効果が大きいです。

肝心なのは「なぜを掴め」が「指示を疑え」ではない点です。目的を理解してこそより良く実行できるという、きわめて実用的な態度です。

8. 事例：同じ依頼、違う結果

あるデータエンジニアがマネージャーから「毎週月曜の朝に売上レポートをExcelで送ってほしい」という依頼を受けました。

彼は言われた通り、毎週手でクエリを回しExcelを作りました。6週間が過ぎると、その仕事が負担になりました。そこでようやく彼は尋ねました。「このレポートはマネージャーご自身で見ますか、それとも誰かに転送しますか」

答えは意外でした。「チームチャンネルに貼って皆が見られるようにするためです」。であればExcelである必要も、人が毎週作る必要もありませんでした。彼はダッシュボードを作り、チームチャンネルで自動更新されるようにしました。マネージャーの本当の目標(「チームが売上を常に見られるように」)はより良く達成され、彼の月曜の朝は自由になりました。

もし最初の週に「なぜ」を尋ねていれば、6週間の手作業はなかったでしょう。目的を尋ねる30秒が数十時間を節約します。

9. アラインメントの会話 — 最初から最後まで

理論を一つの会話にまとめてみましょう。新人に近いエンジニアのジミンとマネージャーの架空の1on1です。ジミンはこの記事の技法を一つずつ自然に使います。

マネージャー: 次のスプリントで検索機能を少し早めに作ってもらえますか?

ジミン:   はい、可能です。より良く作りたいので一つだけ伺います —
          検索を今、優先順位に上げたきっかけはありますか?(意図から尋ねる)

マネージャー: 営業チームから、顧客が欲しい資料を見つけられないという声が続いています。

ジミン:   ああ、では核心は「欲しい資料を早く見つけられるようにすること」ですね。
          私の理解で合っていますか?(言い直して確認)

マネージャー: その通りです。

ジミン:   であれば、フルテキスト検索を最初から全部作るより、
          まず最もよく探される資料にタグとフィルタを先に付けるほうが
          より早く効果を出せるかもしれません。検索はその次の段階で。
          (目標の承認 → 代替案の提示)

マネージャー: お、そのほうが速そうですね。でも検索窓があったほうが見栄えが良くないですか?

ジミン:   ごもっともです。では軽い検索窓とフィルタを一緒に一次で出し、
          反応を見てから本格検索を育てる方向はどうでしょう。
          ただし一次は精度が完璧ではないでしょう。(トレードオフ)
          どちらがよいですか?(決定権を返す)

マネージャー: いいですね、そうしましょう。一次はいつ頃可能ですか?

ジミン:   金曜までに一次を出し、来週月曜の1on1で反応を一緒に見ます。
          もし遅れそうなら水曜に前もってお知らせします。(期待値の管理)

この会話でジミンは一度も「それはできません」と言いませんでした。しかし最初の依頼(「検索機能を早く」)と最終結果(「フィルタ優先、軽い検索窓、段階的拡張」)はかなり違います。表面ではなく意図(「資料を早く見つけられるように」)を掴んだからです。

これがこの記事の言うすべてです。反抗せず、しかし単なる実行者にとどまらず、マネージャーと共により良い答えへ向かう道。その道のあらゆる角には同じ問いが立っています。「これで本当に成し遂げたいことは何でしょう」

10. よくあるアンチパターン五つ

ここまでの話を裏返すと、マネージャーとの関係を壊す典型的な失敗の一覧になります。自分に当てはまるものがないか、正直に点検してみてください。

9.1 尋ねずに推測で作る

最もよくある、最も高くつく失敗です。「たぶんこういう意味だろう」と何日もかけて作ったのに、望まれていたものと全く違う場合。推測のコストは常に質問のコストより大きいです。30秒の質問が三日の無駄骨を防ぎます。

9.2 すべてに口を挟む

逆の罠です。些細な依頼にまで「なぜですか」を付ければ、協力者ではなく障害物になります。7章で述べたバランスがここで重要です。「なぜ」はインパクトが大きいか、方向が疑わしい仕事に絞って使います。

9.3 同意しておいて陰で別のことを言う

会議では頷き、席に戻ると「あれは筋が通らない」と同僚にこぼす。これは信頼を最も速く崩します。異論があるならその場で、丁寧に言うべきです。言うタイミングを逃したなら、別途訪ねて言います。陰口は答えではありません。

9.4 悪い知らせを隠す

物事がうまくいかなくなったとき、手遅れになる前に知らせる代わりに「なんとか一人で解決しよう」と隠すこと。たいていより大きな事故に広がります。マネージャーは早く知るほど多く助けられます。遅れて爆発した爆弾は、助けることすらできません。

9.5 結果ではなく労力だけを報告する

「本当に頑張りました」は報告ではありません。マネージャーが知るべきは「それで何がどうなったか」です。労力は入力であり、マネージャーが責任を負うのは出力です。常に結果とその意味で語る習慣をつけます。

11. アラインメントは一度きりではなく習慣だ

実のところ、ここまでのすべての技法は一つの大きな習慣に収束します。アラインメント(alignment)を定期的に更新することです。

誤解はアラインメントを一回限りのイベントと見ることです。プロジェクト開始時に一度合わせれば終わりだと。しかし状況は変わり続けます。市場が変わり、優先順位が変わり、マネージャーが上から受ける圧力も変わります。一か月前のアラインメントが今日も有効だという保証はありません。

[アラインメントの周期]

毎日:   今日自分がやることは合意された方向と合っているか?(一人で5秒点検)
毎週:   1on1で優先順位がそのままか確認
四半期: より大きな目標と自分の仕事が整合しているか再点検

この習慣が体に染み付けば、「なぜを掴め」はもはや意識的な努力ではなく、働き方そのものになります。毎回新たに尋ねなくても、マネージャーの目標と文脈が頭の中で常に生きています。すると同じ依頼を受けても「これがその目標にどうつながるか」が自動的に浮かびます。

そして時が経つと興味深いことが起きます。マネージャーがますます大きな仕事を、ますます少ない説明と共に任せ始めます。なぜならあなたが表面ではなく意図を見て働くと知っているからです。それこそが信頼が自律に変わる瞬間であり、シニアへ向かう道の核心です。

12. 実践チェックリスト

新しい依頼を受けたとき、自分に投げる質問です。

• この依頼でマネージャーが本当に達成したいことは何か。
• 依頼された解決策以外に、より良い方法はあるか。
• 成功の基準は何で、誰が結果を見るのか。
• 締切と優先順位が他の仕事と衝突しないか。
• (代替案があるなら)目標を認め、トレードオフを整理し、決定権を返したか。
• スケジュールリスクがあるなら、前もって(当日ではなく)共有したか。
• 些細または緊急な仕事なら、詮索せずすぐ実行するのが正しくないか。

おわりに

「言われた通りにやるな」という言葉は、ともすれば傲慢に聞こえます。しかし本当の意味は正反対です。マネージャーをより良く助けるために、彼が言葉で表しきれなかった意図まで汲み取ろうとする努力です。

良い協働は命令と服従ではなく、目的を共有した二人がより良い答えを共に探していく過程です。その過程の第一歩は、いつも同じ問いです。「これで私たちが本当に成し遂げたいことは何でしょう」

その問いを丁寧に、しかし欠かさず投げられるなら、あなたは単に仕事をこなす人ではなく、共に方向を定める人になります。そしてその差が、最終的に信頼を、そしてキャリアを作ります。

参考資料

• Julie Zhuo, The Making of a Manager (マネジメントと1on1の基本)
• Will Larson, lethain.com — 「managing up」関連の記事群
• StaffEng, staffeng.com — シニア/スタッフエンジニアの働き方
• Harvard Business Review (hbr.org) — 「Managing Your Boss」(John Gabarro & John Kotter)
• Kim Scott, Radical Candor (フィードバックの授受)
• Amy Edmondson, The Fearless Organization (心理的安全性と率直な対話)