技術の提案を却下する前に、上司が伝えるべきこと

はじめに

「この仕組み、そろそろ変えた方がいいと思います」

設計レビューや1on1で、メンバーからそんな提案が出る。

話を聞くと、技術的には筋が通っている。ただ、移行にかかる時間や、リリース後の運用を考えると、そのまま進めるのは難しい。

「今は優先度が低い」
「もう少し全体を見て考えてほしい」

そう返したくなる場面だ。

でも、そこで一度立ち止まりたい。こちらが判断に使っている情報を、相手も持っているだろうか。

部下の視野を広げたいと思うなら、まずは上司が見ている景色を伝える必要がある。技術の提案を受け止める場面には、エンジニアの判断力を育てる機会もあると思う。

「全体を見て」の全体は、共有されているか

提案する側は、日々の開発で感じている不便を見ている。

修正のたびに別チームへの確認が必要になる。似た処理があちこちにあり、変更箇所を探すだけで時間がかかる。古い構成が、新しい機能を追加する足かせになっている。

一方、上司には別の事情が見えている。

今期中に届けると約束した機能がある。運用を担える人が限られている。移行に人を割くと、他の仕事が止まる。

どちらも、判断に必要な情報だ。

ただ、上司がその事情を伝えずに「全体を見て」と言ってしまうと、相手には何が足りないのか分からない。

たとえば、こう説明できる。

「変更に時間がかかっているのは、私も改善したい。ただ、今期はこの機能のリリースがある。移行に二人必要なら、そちらへの影響も一緒に考えたい」

これなら、メンバーは次の案を考えられる。移行範囲を絞るのか、時期をずらすのか、別の方法で困りごとを減らせるのか。

広い視野を求めるなら、広く見るための情報を渡す。

「視野が狭い」と指摘する前に、上司ができることはある。

技術の説明から、解決したい問題の話へ

新しい技術を使ってみたいという気持ち自体は、悪いものではない。興味があるから調べるし、使い方も覚える。

ただ、その技術を仕事で採用するなら、何がよくなるのかを説明する必要がある。

そこで聞きたいのは、

「今のやり方で、どんなことに一番時間がかかっている？」

という具体的な困りごとだ。

「保守性が上がります」だけでは、どれほどの改善なのか判断しにくい。

「小さな修正でも三つのチームとの調整が必要で、着手まで一週間かかっています」

ここまで分かれば、技術を変える以外の方法も含めて検討できる。責任範囲の整理で改善できるかもしれないし、本当に構成の変更が必要なのかもしれない。

提案した技術への賛否を急ぐと、議論は採用するかしないかの二択になりやすい。先に困りごとを共有すれば、選べる手段が増える。

上司も、「今の仕組みでやってきたから」という理由だけで判断していないか、確かめたい。使い続ける負担も、変更する負担と同じように検討する必要がある。

意見が割れたら、何を確かめれば決められるかを考える

それでも、見立てが分かれることはある。

本人は「変更すれば開発が楽になる」と考え、上司は「運用が難しくなる」と考えている。説明だけで結論が出ないなら、確かめられる部分を探したい。

たとえば、こんな場面を考えてみる。

あるメンバーが、新しい構成への移行を提案した。変更のしやすさには期待できそうだが、チームで扱えるかは分からない。

そこで、全体の移行を決める前に、切り離せる一機能を検証環境で試すことにした。

今回確認するのは、修正の手間と、提案者以外のメンバーが変更や障害調査をできるか。検証に使える時間も先に決める。

試してみると、修正は確かに楽になった。ただ、別のメンバーが障害の原因を調べようとすると、構成を理解するまでに時間がかかった。

そこで、全面移行は保留する。検証を一機能に絞ったまま、調査手順や必要な知識を整理し、その内容を見て次の判断をする。

こうした結果なら、提案した側も上司も、自分の見立てを更新できる。

本人は「自分が扱える」と「チームが扱える」の違いを知る。上司は、変更によって得られる改善を具体的に把握する。

検証を始める前には、結果をどう判断するかも合意しておきたい。「動いたら成功」と考える本人と、「運用まで確認したい」上司では、同じ結果を見ても評価が変わる。

また、事前に決めた条件を満たしたのに、上司が後から別の理由で止めれば、不信感が残る。新しい事情が出たなら、それを説明する責任がある。

検証は、提案を諦めさせるための儀式にしない。

結果によっては、自分が当初考えていた方針を変える。そのつもりで向き合いたい。

試す余裕がないときは、理由と再検討の条件を伝える

すべての提案に、検証の時間を用意できるわけではない。

期限が迫っていることもある。仕組みの一部だけを切り離すのが難しい場合もある。今は見送るという判断も、必要だ。

そのとき、「余裕がないから」で会話を終えると、提案は宙に浮く。

何を優先するために見送るのか。どんな条件が変われば、再び検討できるのか。そこまで伝えたい。

「今月はリリース対応に人を集中させるので、検証は始められない。リリース後の計画見直しで、他の改善案と一緒に優先度を決めよう」

こう伝えれば、採用の約束をせずに、次に判断する場を示せる。

一方、再検討の見込みが立たないなら、それも率直に伝える方がいい。「落ち着いたらやろう」を繰り返すほど、提案する側の期待だけが残ってしまう。

延期するなら、検討事項として残し、誰がいつ見直すかを決める。上司がその約束を忘れないことも、次の提案を受け取るために必要だと思う。

任せるなら、判断できる範囲も渡す

検証や改善を任せるときも、「自由にやっていい」だけでは十分ではない。

どこまで本人が決めてよいのか。どの段階でレビューが必要なのか。期限に間に合わないと分かったら、誰に相談するのか。

その境界を先に伝えておく。

ここが曖昧なままだと、本人が進めた後で上司が止めることになる。上司には必要な介入でも、本人には「結局、任せてもらえていなかった」と映るかもしれない。

任せる側は、途中で確認する場も用意したい。完成後のレビューだけでは、修正に大きな手間がかかることがある。方針を決めた段階で一度話せれば、本人の判断を聞きながら、足りない情報を渡せる。

メンバーには、根拠を示し、問題を早めに共有する責任がある。上司には、判断に必要な情報と支援を用意する責任がある。

両方があって、任せた仕事が成長の機会になる。

上司も、見立てを変えるところを見せる

試した結果、本人の想定が外れることもある。

そこで「だから言っただろう」と返せば、本人は次から慎重になるだろう。ただ、それが判断の慎重さなのか、上司に逆らわないための慎重さなのかは分からない。

振り返りで確かめたいのは、どの前提が違っていたか。そして、次に似た提案をするとき、何を先に調べればよいかだ。

逆に、本人の案が有効だったなら、上司も素直に認めたい。

「運用が難しいと思っていたけれど、この結果なら進められそうだね」

新しい情報を受け取って判断を更新する姿は、メンバーにとっても参考になる。

エンジニアには、自分の考えを持ち、必要な場面で提案してほしい。同時に、その考えを確かめ、必要なら変えられるようになってほしい。

そのためには、上司も判断の理由を言葉にする必要がある。

意見が割れたとき、メンバーから、

「では、何を確認すれば決められるでしょうか」

と聞かれたら、私はうれしい。

こちらの答えを待つだけではなく、判断するための材料を探そうとしている。その問いに一緒に向き合えることが、育成の手応えになると思う。