こんにちは、estieでSWEをしている上久保です。
私は入社以来、新規事業の立ち上げチームでプロダクト開発に携わっています。PMF前のプロダクトでは、価値検証のための機能開発を最優先に進める必要があるため、スピードが強く求められます。一方で、パフォーマンスや可用性といった非機能要件への対応は後回しになりがちで、そうした高度なエンジニアリングスキルを磨く機会が限られていると感じることもありました。さらには昨今の生成AIの台頭により、コーディングや設計といった業務がAIに代替される場面を何度も目にし、「このままでエンジニアとして成長できるのだろうか？」という不安を抱えるようになりました。
そんな悩みをメンターのsugitakさんに相談したところ、次のような言葉をもらいました。
「上久保さんは開発以外にもシステム運用やチーム内のコミュニケーションとかもやっていますよね。それも立派なエンジニアリングですよ」
その一言に、私はハッとさせられました。
「私はソフトウェアエンジニアだけど、肩書通りに”ソフトウェア”だけを開発する必要はない」
この気づきは、私にとって大きなものでした。視座が一段階上がり、今の仕事と将来のキャリアが地続きでつながっていることを実感できたのです。
この記事では、私が経験してきた「ソフトウェア開発以外のエンジニアリング」について、それぞれの意義や難しさ、そこから見えてきたキャリアの広がりについてお話ししたいと思います。
プロダクトのエンジニアリング
最新トレンドの言語やフレームワークなどについて、SNSやブログ等で盛んに情報発信されている場面をよく目にします。しかし、これらの技術選定は実際の業務の中で行われており、技術の優劣自体よりも業務で発生した課題を解決できたかどうかがエンジニアリングの評価として重要です。一般的に、業務やドメイン知識に関する情報はリスクを考慮し、社外に公開されることはあまりありません。顧客要望の実現や障害対応、開発ロードマップの策定といった業務の中で発生した個別の判断や作業は、技術と直接の関連はありませんが、重要なエンジニアリングの一要素であり、プロダクトの成否に大きく関わっています。
今期、私は「プロダクトを運用すること」に注力しました。その中には、例えば手動のDB修正作業といった一見地味な作業もあります。しかし、適切にプロダクトを運用するためには、顧客業務や業界についての知識を深く理解する必要があり、技術自体の複雑さとは別領域の高度なエンジニアリングが求められると気づきました。
最初から運用作業は自動化したい、手作業を受け入れたくないという気持ちはエンジニアとして共感できます。しかし、デリバリー速度が求められる開発において、一定手動の運用作業が発生することは受け入れるべきだと私は思います。
繰り返しになりますが、大切なのは業務の課題をエンジニアリングで解決することであり、そのためにまずはエンジニアが業務を知るところから始めるべきです。運用を自分でやることで業務に対する解像度が上がり、初めて見えてくる課題もあります。また、運用の一部分だけを自動化して気軽に試すことも可能になります。運用によって開発者が業務に対する理解を深めながら、プロダクトの改善サイクルを回していく、その過程は誇るべき立派なエンジニアリングではないでしょうか。
チームのエンジニアリング
私は今期、チームのエンジニアリングにも挑戦する機会がありました。
私はマネージャーではありませんが、メンバーに対してリーダーシップを発揮し、チームをより良くしていくことは出来ます。以前の私は、チームの目標が設定されているのに自身の成長を優先して行動しがちでした。しかしそれでは、仮に自身の目標は達成されたとしても、チームが成果を上げられませんでした。そもそも、そのような状態は「チーム」と呼べないのです。
反省した私は、目先の自分の仕事を終わらせることに固執せず、チームが最大の成果を出せるように自分にできることはないかと考え、メンバーの動きにも気を配るようになりました。
具体的には、開発の実装担当者が迷わないようにタスクの前提知識やスコープについて認識合わせをしたり、レビューをきっかけにドメイン知識を共有することに力を入れています。また、チーム全員で毎週開発振り返りを実施し、学びと次週に向けた改善策について議論しています。さらには最低週1回チーム全員で出社して隣で仕事をすることで、困りごとをすぐに質問して解決できるような環境づくりを目指しています。
これらの活動はすべて、チーム内に良いコミュニケーションと信頼関係を生み、開発の土台を作る重要なエンジニアリングだと思います。人の集まりであるチームの状況をプロダクトのように正確にモニタリングすることは不可能ですが、チーム内のコミュニケーション量を増やすことで、何かしら問題がある場合にいち早く気づき、乗り越えることでチームが成長します。フィードバックを通じた継続的な改善が必要な点はプロダクトのエンジニアリングとの共通点です。
ビジネスのエンジニアリング
会社経営にとっていうまでもなく重要なビジネスの成功のためにもエンジニアリングは欠かせません。私自身、ビジネスについてはわからない部分が多いですが、データ分析基盤の整備やKPIダッシュボードの作成といった意思決定の支援について取り組んできました。プロダクトのよって生まれたビジネス価値の現状を可視化することでチーム全体の理解が深まり、開発のモチベーションアップにもつながっていると感じています。
商品となる開発プロダクトの他にも、営業活動や顧客管理、請求処理や労務といった全社員の全ての業務に対して、エンジニアリングによる業務改善の余地は存在します。「ビジネスはエンジニアの自分には関係ない」などと切り離すのではなく、「エンジニアとして貢献できることはないか？」と常に考えて行動し続けることこそが、ビジネス貢献の鍵になるのではないかと思います。
エンジニアリングから広がるキャリア
業務を通じてプロダクトやチームを運用していくことでエンジニアとして成長し、エンジニアリング対象の「範囲」や「時間軸」は少しずつ広がっていきます。しかし、その広がり方は一様ではなく、人によっても異なるものです。
この「広がり方」は自身のキャリアを形作るものだと私は感じています。例えば、プロダクト開発を行う中で培った「技術」を全社に広めたいのならテックリード、開発「チーム」のエンジニアリングに熱量を感じたのならEM、プロダクトを起点とした「ビジネス」づくりに興味が湧いたのならPMといったように、日々の業務で行うエンジニアリングが将来のキャリアパスの出発点であると気づきました。
この分類はあくまで一例であり、どれかにならなければいけないというものではありません。キャリアは人生のどの時点においても自分で決められて、自由に変えられるものだと私は思っています。大切なのは「今やっているエンジニアリング」と「将来のキャリア」のつながりをしっかりと意識して日々の仕事に取り組み、振り返りと修正を繰り返していくことではないかと思いました。
最後に
エンジニアが運用と聞くとシステムの運用だけをイメージしがちですが、運用という言葉自体は「そのもののもつ機能を生かして用いること」という意味を持っています。
運用の対象はシステムに限らずあらゆるものであり、そして運用すること自体が深いエンジニアリングのテーマであるなと私は感じました。
estieでチーム開発をしていく中で、ソフトウェアに閉じない広い意味でのエンジニアリングが重要であると実感しました。多くの学びを通じて、自分が何を運用し、エンジニアリングすることに魂を燃やせるかを見つけて、そこからエンジニアとしての次キャリアを拓くことができたら良いなと思います。
最後まで読んでいただきありがとうございました。この内容に少しでも興味をもっていただけた方は是非カジュアル面談でお話ししませんか？ご応募お待ちしております。
