マネジメントを経験してから、技術との向き合い方が変わった。
それは「技術を捨てた」とか「技術に興味がなくなった」という話ではない。
むしろ逆で、
技術がなぜ必要なのか、どこで使うべきなのかを、初めて本気で考えるようになった。
プレイヤー時代の私は、
技術力を高めることが、そのまま価値になると信じていた。
書けること、分かること、早いこと。
それらが揃っていれば、自然と評価され、チームにも貢献できると思っていた。
けれど、マネジメントを任された瞬間から、
その前提は少しずつ崩れていった。
技術的に正しい判断をしているはずなのに、
プロジェクトは思うように進まない。
自分が一番分かっているはずなのに、
チームはなぜか静かに停滞していく。
この記事では、
マネジメントを経験したことで見えた「技術がうまく機能しなかった理由」と、
そこから変わっていった私自身の技術との向き合い方を、実体験ベースで振り返る。
もし今、
「技術は頑張っているのに、手応えがない」
「昔と同じやり方が、なぜか通用しなくなった」
そんな違和感を感じているなら、
この話はきっと他人事ではないはずだ。
プレイヤー時代の私は「技術＝評価」だと思っていた
プレイヤーとして仕事をしていた頃、
私の中では「技術力」と「評価」はほぼイコールだった。
新しい技術をキャッチアップできているか。
難しい実装を一人で解決できるか。
トラブルが起きたとき、誰よりも早く原因にたどり着けるか。
そうした“分かりやすい強み”を積み上げていけば、
自然と評価され、任せてもらえる仕事も増えていく。
当時は、疑いなくそう思っていた。
実際、プレイヤーとしてはそれなりにうまく回っていたと思う。
実装面で困ることは少なかったし、
周囲から「技術に詳しい人」「頼れる人」と見られていた感覚もあった。
だからこそ、
「もっと技術を磨けば、もっと価値が高まる」
「技術で結果を出し続ければ、立場も評価も後からついてくる」
そう信じて、学習にも仕事にも向き合っていた。
振り返れば、その考え自体が間違っていたわけではない。
プレイヤーという役割においては、
技術力が評価の中心になる場面は、確かに多い。
ただ、当時の私はそこから一歩も外を見ていなかった。
自分が「何を書いたか」「どれだけ分かっているか」ばかりに意識が向き、
その技術が誰にどう使われ、何を前に進めているのかまでは、
正直あまり考えていなかった。
それでも現場は回っていたし、
少なくとも自分の中では「順調」だった。
この時点ではまだ、
この価値観が後になって自分を苦しめることになるとは、
想像もしていなかった。
マネジメントを任されて、違和感を覚え始めた
マネジメントを任されたとき、
正直なところ、そこまで大きな不安はなかった。
プレイヤーとしては問題なくやれていたし、
技術的なことは一通り分かっている。
「役割が少し増えるだけだろう」
そんな感覚に近かったと思う。
むしろ、
自分が分かっているからこそ、
チームをうまく回せるはずだという自信も、どこかにあった。
最初のうちは、実際それなりに回っていた。
スケジュールを見て、タスクを振り、
詰まりそうなところがあれば自分が手を動かす。
「自分が動けば早い」
「分からないところは、説明するより書いたほうが確実」
そんな判断を、無意識に繰り返していた。
けれど、少しずつ違和感が積み重なっていった。
自分が関わらないと進まない仕事が増えていく。
確認や判断が、すべて自分に集まってくる。
気づけば、チーム全体の速度が、
自分の処理速度に引っ張られるようになっていた。
技術的には、間違ったことはしていない。
むしろ、正しい判断をしているつもりだった。
それなのに、
なぜか余裕がなくなっていく。
チームも、以前より静かになっていく。
「こんなはずじゃなかった」
そう思い始めたのは、この頃だった。
プレイヤー時代と同じ感覚で動いているのに、
結果だけが噛み合わない。
技術を武器にしてきたはずなのに、
その武器が、思ったように効かなくなっている。
この違和感の正体が何なのか、
当時の私はまだ、うまく言葉にできていなかった。
ただ一つだけ確かだったのは、
プレイヤーの延長線上にある動き方では、
マネジメントは成立しないらしい
という感覚だった。
技術力があっても、チームはうまく回らなかった
マネジメントを任されてからしばらくして、
はっきりと分かるようになったことがある。
技術力があることと、チームがうまく回ることは、
必ずしも一致しない。
自分が関わっている限り、
技術的な判断が致命的に間違うことはない。
少なくとも、そう思っていた。
実際、設計や実装の内容そのものは、
大きく破綻していたわけではなかった。
レビューでも、致命的な指摘が出ることは少ない。
それでも、チーム全体を見ると、
なぜかスムーズではなかった。
誰かが詰まっている。
判断待ちのタスクが滞っている。
ちょっとした認識の違いが、
想像以上に時間を奪っていく。
そのたびに、私は技術で解決しようとした。
設計を細かく書き直す。
実装例を提示する。
場合によっては、自分で手を動かして片付ける。
「これで早くなるはず」
「このやり方が一番安全だ」
そう思っての行動だった。
けれど、結果はあまり変わらなかった。
むしろ、
自分が動くほど、
チームは自分の判断を待つようになっていった。
「分からないから聞く」ではなく、
「決めてほしいから待つ」
そんな空気が、少しずつ生まれていた。
今振り返ると、
技術そのものが問題だったわけではない。
問題だったのは、
**技術を“どう使っていたか”**だった。
技術は、本来チームの動きを助けるためのものだ。
誰かが判断できるようにするための材料であり、
次の一手を選びやすくするための道具でもある。
それを私は、
「正しい答えを出すための武器」として使っていた。
その結果、
判断は私に集まり、
チームは考える余地を失っていった。
技術力があれば何とかなる。
プレイヤー時代にうまくいっていたその感覚が、
ここでは逆に作用していた。
このあたりから、
「技術を持っていること」よりも、
「技術がどう使われているか」を
意識せざるを得なくなっていった。
マネジメントを通して見えた「技術の本当の役割」
マネジメントを経験して、
技術そのものの価値が下がったわけではない。
むしろ逆で、
技術が本来、何のために存在しているのかを
初めて真剣に考えるようになった。
プレイヤー時代の私は、
技術を「正しい答えを出すための力」だと思っていた。
複雑な要件を理解し、最適な設計を導き、
それをコードとして落とし込む力。
もちろん、それ自体は今でも重要だ。
ただ、マネジメントという立場に立って見える景色は、
少し違っていた。
プロジェクトが前に進まない原因は、
技術的な難しさよりも、
判断が止まることにある場合がほとんどだった。
誰が決めるのか分からない。
決めるための材料が足りない。
判断の基準が共有されていない。
そうした状態では、
どれだけ技術力があっても、
チームは動けない。
そこで初めて気づいた。
技術の役割は、
「正解を出すこと」だけではない。
人が判断できる状態を作ること。
チームが前に進める材料を揃えること。
それも、立派な技術の役割だった。
設計書は、
自分が理解するためのものではなく、
誰かが判断しやすくなるためのもの。
コードは、
自分が書けることを示すためではなく、
他の人が安心して触れるためのもの。
技術は、
個人の能力を誇示するための武器ではなく、
チームの意思決定を助ける道具だった。
マネジメントを通して、
私はようやくその当たり前に気づいた。
この視点に立つと、
技術の見え方は大きく変わる。
「どれだけ詳しいか」よりも、
「誰が使えるか」
「どう共有されているか」
を考えるようになった。
そして、
技術を“持つ”こと以上に、
技術が機能する状態を作ることが
自分の役割なのだと、
少しずつ腹落ちしていった。
技術との向き合い方が、こう変わった
マネジメントを経験してから、
技術そのものをどう見るかだけでなく、
どう向き合うかがはっきりと変わった。
技術を磨くこと自体をやめたわけではない。
ただ、何を基準に学び、どう使うかの優先順位が変わった。
「最新」よりも「共有できる」技術を選ぶようになった
以前は、
新しい技術や流行っているフレームワークに
自然と目が向いていた。
「知っていること」
「触ったことがあること」
その数を増やすことが、
自分の価値を高めると思っていたからだ。
今は少し違う。
その技術を、
チームの誰が理解できるのか。
困ったときに、誰がフォローできるのか。
そうした視点を、
無意識のうちに考えるようになった。
一人だけが分かっている技術よりも、
数人で支え合える技術のほうが、
結果的に強い。
「書ける」より「説明できる」を大事にするようになった
プレイヤー時代は、
「コードを書けば伝わる」と思っていた。
実装を見れば意図は分かる。
分からなければ読めばいい。
そんな前提で動いていた。
マネジメントを経験してから、
それが通用しない場面を何度も見た。
説明が足りないまま進んだ設計。
背景が共有されていない判断。
結果として、手戻りや停滞が起きる。
今は、
「なぜそうするのか」を言葉にすることを、
コードを書くことと同じくらい重視している。
説明できない設計は、
再現も改善もできないからだ。
深く掘る技術と、割り切る技術を分けるようになった
すべての技術を、
同じ熱量で追いかける必要はない。
マネジメントを経験してから、
そう割り切れるようになった。
自分が責任を持って深く理解すべき領域。
概要が分かっていれば十分な領域。
他の誰かに任せたほうがよい領域。
これを意識的に分けることで、
技術に振り回される感覚が減った。
結果として、
「何でも分かっていなければならない」
というプレッシャーからも、
少し距離を置けるようになった。
技術を「成果につなげる視点」で見るようになった
以前は、
技術そのものが成果だと思っていた。
今は、
その技術が何を前に進めるのか。
誰の判断を楽にするのか。
どのリスクを下げているのか。
そうした“効き方”を意識するようになった。
同じ実装でも、
使われ方次第で価値は大きく変わる。
技術は、
ただ正しくあるだけでは足りない。
機能して初めて意味がある。
マネジメントを経験したことで、
私はようやくその視点を持てるようになった。
それでも、技術を捨てたわけではない
マネジメントを経験して、
技術との向き合い方は確かに変わった。
だからといって、
技術を捨てたわけではないし、
技術に興味がなくなったわけでもない。
むしろ、
以前よりも技術を慎重に、
そして大切に扱うようになった感覚に近い。
プレイヤー時代は、
技術は「積み上げるもの」だった。
できることを増やす。
知っていることを広げる。
それ自体が前進だと感じられた。
今は少し違う。
技術は、
「使われてこそ意味があるもの」
だと考えるようになった。
どれだけ高度な技術でも、
それが理解されず、
チームの中で孤立してしまえば、
かえってリスクになる。
だからこそ、
むやみに広げるより、
確実に活かせるところに集中する。
これは技術を軽く見ているのではなく、
技術の価値を下げないための選択だと思っている。
また、マネジメントを経験したことで、
技術を見る目そのものも変わった。
「これは本当に必要か」
「この複雑さは、誰のためのものか」
そう問い続けるようになった。
以前なら、
「できるから」「面白いから」で選んでいた技術も、
今は一度立ち止まって考える。
それでも、
深く掘るべき技術がなくなったわけではない。
むしろ、
ここは譲れないという技術領域は、
以前よりはっきりしてきた。
自分が責任を持つべき部分。
品質に直結する部分。
後から変えると高くつく部分。
そうしたところには、
今でも時間と労力を惜しまない。
技術を捨てたのではなく、
技術との距離感が変わった。
マネジメントを通して、
技術を“消耗品”にしないための向き合い方を、
ようやく覚え始めたのだと思っている。
プレイヤーに戻った今、技術は以前より重くなった
マネジメントを一通り経験し、
再びプレイヤーとして技術に向き合うようになった今、
不思議と、技術は以前よりも「重く」感じられている。
それは、
学ぶことが辛くなったとか、
実装が難しくなったという意味ではない。
むしろ逆で、
一つひとつの技術が、より現実的な重さを持つようになった
という感覚に近い。
プレイヤー時代の私は、
「この技術が使えるかどうか」を基準に考えていた。
今は、
「この技術が入ることで、何が変わるのか」
「誰の判断が楽になるのか」
「どこに影響が波及するのか」
といったことを、自然と考えるようになった。
設計を書くときも、
「自分が理解できるか」ではなく、
「次に触る人が迷わないか」を意識する。
実装でも、
動くかどうか以上に、
「なぜこの形なのか」が説明できるかを気にする。
その分、
コード一本、設計一枚にかかる責任は、
確実に重くなった。
以前のように、
「とりあえず動けばいい」
「あとで直せばいい」
とは思えなくなった。
マネジメントを通して、
技術の先にあるものを見てしまったからだ。
この変更が誰に影響するのか。
この判断がどれくらいの手戻りを生むのか。
この設計が、チームの速度を上げるのか、下げるのか。
そうしたことを一度考えてしまうと、
技術はもう、
単なる自己表現の手段ではいられない。
一方で、
この「重さ」は、決して悪いものではない。
むしろ、
技術を雑に扱わなくなったことで、
一つひとつの選択に納得感が生まれた。
何となく選ぶ技術が減り、
選んだ技術には理由がある。
マネジメントを経験してからプレイヤーに戻ると、
技術は軽くなるどころか、
意味のある重さを持って戻ってくる。
今はそう感じている。
これからマネジメントを経験するエンジニアへ
もしこれから、
マネジメントを任される立場になるなら、
一つだけ伝えておきたいことがある。
それは、
「技術が分からなくなるのでは」という不安は、
思っているほど心配しなくていい
ということだ。
多くのエンジニアが、
マネジメントに足を踏み入れるとき、
同じ不安を抱く。
手を動かす時間が減る。
最新技術から離れる。
気づいたら、現場についていけなくなるのではないか。
その感覚は、とても自然だ。
私自身も、
どこかで同じことを考えていた。
けれど、実際に経験してみると、
失われるものより、
見えるようになるもののほうが多かった。
技術のどこが重要で、
どこがそうでないのか。
どんな技術が、
本当にチームを助けるのか。
そうした視点は、
マネジメントを通らなければ、
なかなか身につかない。
そしてもし、
将来またプレイヤーに戻ることになっても、
その経験は確実に残る。
判断の背景が見える。
設計の重さが分かる。
技術の「効きどころ」を考えられる。
これは、
単に技術を続けているだけでは、
得られにくい感覚だと思う。
マネジメントは、
技術から遠ざかる道ではない。
技術を、より深く理解するための回り道
だと、今は感じている。
不安を感じるのは、
それだけ真剣に技術と向き合ってきた証拠だ。
だから、
もし声がかかったなら、
一度は引き受けてみてもいい。
技術との関係は、
その先でまた、違う形で戻ってくる。
まとめ｜マネジメントは、技術を“薄めた”のではなく“濃くした”
マネジメントを経験したことで、
技術から離れた時間があったのは事実だ。
手を動かす時間は減り、
キャッチアップのスピードも、
以前と同じではなくなった。
だから一時期は、
「技術が薄まってしまったのではないか」
そんな不安を感じたこともある。
けれど、今振り返ると、
それは違っていた。
マネジメントを通して、
技術の“量”は減ったかもしれない。
だが、技術の“意味”は確実に濃くなった。
なぜこの技術を使うのか。
誰の判断を助けるのか。
この選択が、どこに影響するのか。
そうした問いを経て触れる技術は、
以前よりも重く、
そして責任を伴うものになった。
技術を、
自己表現の手段として扱っていた頃とは違い、
今は「成果につなげるための道具」として、
より丁寧に向き合っている。
マネジメントは、
技術を奪うものではない。
一度距離を取らせ、
別の角度から見せてくれるだけだ。
そして戻ってきたとき、
技術は以前よりも、
何のために使うのかがはっきりした存在になっている。
もし今、
マネジメントと技術の間で迷っているなら、
その経験は決して無駄にはならない。
むしろ、
技術と長く付き合っていくための、
大切な通過点になるはずだ。
私にとって、
あの時間があったからこそ、
今の技術との向き合い方がある。
そう胸を張って言えるようになった。
コメント