CYBIRD Advent Calendar 2025の25日目担当、@cy_ryosuke_zushi です。
24日目は@cy-yamaken さんの「Proxyで理解する、JSデータバインディングの仕組み」でした。
昨今あらゆる機能がパッケージ化され、中身について理解しなくともある程度動作するものが作れる世の中になってきてますよね…
中身を理解せず、落とし穴にハマらないように気をつけたいと思いました。
さて、私からは新卒3年目エンジニアの自戒と気づきを赤裸々につづっていこうと思います。
はじめに：コードを書くことが目的だった自分へ
かつての自分へ。そして今、画面に向かって必死にリクエストを消化しているあなたへ。
新卒で入社してからの数年間、私は「優秀なエンジニア」＝「依頼された機能を、速く、バグなく実装できる人」だと信じて疑いませんでした。
「ここにボタンが欲しい」「CSV出力機能を追加して」「この入力欄を増やして」
そんな依頼が来るたびに、「はい、できます」「すぐやります」と即答することが、自分に課せられた使命だと思っていたからです。
しかし、ある失敗経験がその考えを少し変えることになりました。
使われなくなった「自動化ツール」
当時、私は「手動で行なっていたテストケース作成の作業を自動化する」というタスクを抱えていました。
「これを自動化すれば楽になるはずだ」と信じ、与えられたテストケースを見て自動化案を考え、実装しました。リリース時には「おー、これは便利だね」と好感触なフィードバックをもらえて、私は大満足でした。
けれど、数ヶ月経ったある日、ふとログを見て気づいてしまったのです。
「あれ、必死で作ったあの機能、最近あんまり使われてなくない……？」
理由は単純でした。
「そもそも元のテストケース自体の質が悪く、より良いテストケース運用に切り替えたことで、手動作成の手間自体が激減したから」 です。
ニーズへの理解
では、自分の作ったものは誰のためにもなっていなかったのか？
そんなことはありません。
一時的にですが助かった人はいましたし、業務が効率化されたのは事実です。
問題は私のニーズへの理解度でした。
テストケース作成者は「今の形のテストケースを自動で作成できるようにして欲しかった」わけではなく、
本当は「（今の形じゃなくてもいいから）要件を満たしているテストケースを簡単に作成できたらいいな」だったわけです。
つまり、当時の自分がすべきことは「この形のテストケースじゃないとダメですか？」などのヒアリングや「違う形であればこんな風にテストケースが作れて楽ですよ」等の提案を行い、要件を深掘りすることだったのです。
価値あるものを作り続けるために
依頼者は「手段（ボタンが欲しい）」を提示してくれますが、
私たちがやるべきことは「目的（大変な作業を楽にしたい）」を達成することです。
だから最近は、あえて少しだけ「面倒くさいエンジニア」になろうと意識しています。
「これ作って」と言われたら、脊髄反射で「はい」と言う前に、一度手を止めてこう聞くようにしています。
「わかります。でもその前に少し教えてください。なぜ、それが必要なんでしたっけ？」
「それを作ると、具体的にどんな業務が楽になりますか？」
正直、3年目の自分にとって、こう聞き返すのはまだ勇気が要ります。「つべこべ言わずに作れ」と思われないかな、と不安になることもあります。
でも、これは否定ではありません。
依頼してくれた人の時間も、実装する自分の時間も、無駄なものを作ることに使いたくないからです。
最後に：技術を武器に、本当の価値を届けるために
日々の業務に忙殺されていると、つい「ハイハイ」と要件を飲み込んで、手を動かしたくなります。思考を停止してコードを書く方が、精神的には楽だからです。
でも、3年目になった今、自分に言い聞かせています。
私たちは、言われた通りの図面を引くだけの製図マシンではないはずだ、と。
技術という武器を使って、誰かの問題を解決するのが私たちの仕事です。
私は手段にとらわれず目的の達成に向けた提案できた時、「あ、今エンジニアとしていい仕事ができたかも」と少しだけ自信が持てるようになりました。
もしあなたが、依頼された内容・作るモノの「価値」について少しでも疑問を持っているなら、以下のことを意識してみるといいかもしれません。
・技術的な実装方法に飛びつく前に、その背景にある課題や痛みに興味を持つこと
・依頼者を「発注者」ではなく「共創のパートナー」と捉えること
・「なぜ？」と言う勇気は、最高のモノを届けるための優しさだと知ること
まずはあなたを信頼して頼んでくれた人のために、勇気を持って「なぜ？」という問いかけから始めてみませんか。