10
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事はHTアドベントカレンダー7日目の記事です。

はじめに

はじめまして。博報堂テクノロジーズのCREATIVE BLOOM開発部でソフトウェアエンジニアをしている土井です。業務では、CREATIVE BLOOM TEXT Ads, DISPLAY Adsに関わっています。

新卒2年目の2025年、いくつかのプロジェクトに携わる中で、「エンジニアの仕事ってコードを書くことだけじゃないんだな」と実感する場面が何度もありました。

この記事では、その過程で得た学びを、具体的なエピソードとともに共有します。学生の方や、同じように新卒1年目、2年目で奮闘している方の参考になれば嬉しいです。

具体的な価値を実現していく過程すべてがエンジニアリングである

ソフトウェアにおいても同じことがいえます。それは誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。

エンジニアリング組織論への招待.

この言葉の意味を、3つのプロジェクトを通じて実感しました。

1. 関係者との連携:社内プロダクトの認証基盤移行

当時担当していた社内プロダクトの認証基盤を移行するプロジェクトに携わりました。コードの変更自体はシンプルなものになるだろうと考えていました。でも、それだけでは全然足りませんでした。

まず、グループ企業内の認証を担当しているチームに連絡を取り、必要な手順や設定について確認しながらPOC環境で検証を進めました。

また、認証方式が変わるということは、サポート部門の業務フローも変更が必要でした。これまで手動で行っていた承認作業がなくなる一方で、「新しいフローはどうなるの?」「問い合わせが来たらどう対応すればいい?」という疑問が当然出てきます。企画チームへの説明や、運用移行の支援も必要でした。

さらに、開発チームのローカル開発環境の変更も必要でした。チームメンバーの開発者体験(DX)を損なわないように、ローカルの認証は簡略化するなどの準備をしました。

振り返ると、実運用で使う処理のコードを書いている時間より、関係者への説明や運用移行の支援に費やした時間の方が長かったかもしれません。しかし、それらが価値を生み出す上で重要なプロセスだったなと感じています。

2. ユーザー業務の理解:実務検証プロジェクト

プロダクト配属から半年ほど経った頃、機能開発を進める中で「自分はユーザーの業務を本当に理解しているのか?」という疑問が湧いてきました。

幸運なことに、ユーザーヒアリングに同行させてもらう機会がありました。そこで聞いた話は、自分が想像していたものと違う部分もあれば、既存機能のどこがどれくらい必要とされているか理解できた部分もあり、発見の連続でした。

この経験からもっと深く業務を理解したいと思い、実際の業務プロセスに入り込んで検証するプロジェクトを企画しました。直接ソフトウェア開発に従事しない取り組みだったので、部長やチームメンバーに相談し、承認を得て進めることができました。

ヒアリングだけでなく、実際にユーザーが対応している業務の一部を体験することで、本当に困っているポイントを肌で実感できました。正直、期待したほどの成果が出なかったケースや、担当者との認識のズレが発覚することもありました。ただ、業務改善に向けた実務的な課題について重要な示唆を得られたことに加えて、同時期に開発していた別機能への早期フィードバックも得られたのは大きな収穫でした。

3. スコープの調整:広告文最適化機能

広告運用では、効果的な広告文の選定がPDCAサイクルの要です。ただ、膨大な選択肢の中から最適な組み合わせを探す作業は、運用担当者にとって大きな負担になっていました。この負担を軽減する機能を開発することになりました。

これは覚えておいてほしいのですが、すべての仕事は必ずやり直しになります。最初の狙いどおりに行くほうがまれなのです。スマホのアプリもWindows95も、あなたの明日のプレゼン資料もそうです。どうせやり直しになるのだから細かいことはおいておき、まず全体像を描いてしまったほうがいいのです。これがつまりプロトタイプを作るということになります。

なぜ、あなたの仕事は終わらないのか.

この考えに基づいて、最初からコア機能に絞って開発を進めました。さらに、実務検証で現場に入った経験から「早期にユーザーFBを得て改善していく方が良い」と感じていたので、β版として2週間早くリリースする判断をしました。正直なところ、劇的な効果があったとは言えませんが、今後の改善につながるフィードバックを得ることができました。

この学びについて

これらの経験から、設計やコーディングだけでなく、関係者との連携、ユーザー業務の理解、スコープの調整—これらも含めて「エンジニアリング」なんだと感じるようになりました。

おわりに

振り返ると、私にとって2025年は「コーディング以外の大切さ」を学んだ1年でした。

こうした挑戦ができたのは、CREATIVE BLOOM開発部の挑戦を後押しする文化と、頼りになるチームメンバーのおかげです。特に実務検証のプロジェクトは、直接ソフトウェア開発に従事しない取り組みだったので、部長やチームの理解がなければ実現しませんでした。

2026年は、この学びを活かして、より大きなインパクトを生み出せるよう頑張ります。

最後まで読んでいただき、ありがとうございました!

10
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?