現在マイベストで行っているmybest BlogKaigi 2024の連載のタイミングで、ちょうどマイベストにエンジニアとして新卒入社して3年のタイミングを迎えました、あまね(@isaka1022)です。
すでに4年目になったので、もう新卒です！とも言えなくなる年代になったこともあり、3年をふりかえる記事を書こうと思いつつ、「3年前と比べて何が一番大きく変わっただろうか？」ということを考えてみたのですが、一番の変化というものが思いつかず...。
ですが、最近の私の中の変化として、「エンジニアの価値」について悩み抜いた結果、「ものをつくる」だけではなくて「複雑なものをシンプルに提供すること」なのではないかという考え方になりました。
そこで今回はなぜその結論に至ったか、なぜ悩んでいたか、についてについて書きたいと思います。
マイベストという環境を選んだ理由
詳細は以下のnoteに書いたので割愛しますが、私は新しいサービスづくりや事業づくりに関わりたいと思い、また「ものを作る」という立場で貢献できればと思ったので、エンジニアとしてWEB業界に就職することを決めました。
就活当時の1on1イベントなどではお恥ずかしながらも「想像と創造」という僕の就活コンセプトを伝え、「機能の企画から実装まで、頭で考えるところから手を動かして作るところまで全部やりたい！」という軸で会社を探し、それができるのはベンチャーの規模感の会社で、マッチしたのがマイベストでした。
入社後に改めてどうしてマイベストを選んだか？実際どうかを振り返った記事
エンジニアとして働くということの解像度を上げる1,2年目
就職当時も「働いた経験ががない中で会社を選ぶのは難しい」と思っていましたし「仕事を通しての自分のやりたいことは、実際に働いていく中で見つけていくものだ」という考えだったので、まずは領域にこだわらず、いろいろなことをなんでもやるぞ！という気概で最初は働きました。
もちろん、最初はメンターの先輩についてもらいながら実装をし、「先輩が実装したほうが100倍早いのに手をかけさせてしまって申し訳ない」と思いながらも、フィードバックをもらいながら、ふりかえりを継続してキャッチアップやスキルアップをしていきました。
新卒1年目のふりかえり記事
結果としてマイベストでは1年目からプロジェクトを担当させてもらい、就活時代に考えていたように、企画を考えるところから実装、リリース、そして運用まで含めて開発とはどのようなものかを知っていきました。
新卒1-2年目で取り組んだ「人気ランキング自動掲出プロジェクト」について
このころになり、就活時代に自分が考えていた「機能の企画から実装まで、頭で考えるところから手を動かして作るところまで自分で全部やる」という考え方の限界を感じていきます。
マイベストではPdMとエンジニア、そしてデザイナーでそれぞれには専門性を活かして協力しながら開発を進めています。
大規模な開発では、システム設計や実装だけで多くの時間がかかるため、それ以外の仕様を決めたり、ステークホルダーとの調整など、開発以外のことに使える時間がありません。
仕様を決めるのに必要な情報の収集や、ユーザー理解についてはその分野に多く時間をかけている人が責任を持って行ったほうが最適解にたどり着く確率は上がります。
エンジニアはエンジニアとしてシステムの理解や技術のキャッチアップを行い、エンジニアリングという観点を持ちながら議論して、多職種と協力したうえでチームとして良い機能をリリースしたほうがよいのではないかと思うようになりました。
事業づくりに対しての解像度を高めた3年目
その後、社会人3年目になるタイミングで、新規事業「favlist」の開発ミッションに配属され、エンジニアの立場から事業やプロダクトを0から立ち上げるという体験をさせてもらいました。
それまでは大きくマイベストの「機能を作る」ということが仕事だったのですが、このミッションになってからは「favlistというプロダクトそのものの価値を作る」ということがそれまでとは大きな違いでした。結果としていろいろな試行錯誤を行い、多くの学びを得た1年でした。
初めての新規事業の開発で得られた知見をまとめた記事
しかし、その過程で一つの悩みも抱えるようになっていきます。職種ごとに分担をしてものごとを進めるうえで、エンジニアが関われる領域の狭さです。
いかに最適な設計をしたり、メンテナンス性が高いコードを書いても、そもそも「何を作るか」「なぜやるのか」という部分がユーザーのニーズとずれていると、自分が開発したものが使われない、ということが起こります。
では、「何を作るのか」から考えたくても、、それぞれの職種の責任や情報量の差、権限、そして経験などの観点からは、エンジニアしては貢献できる範囲が「開発」という領域で閉じてしまい、価値が出しづらい、というような悩みに直面します。
このあたりから「そもそもエンジニアとしての価値とは何か」ということを考える日々が続きました。
自分の価値って何なんだろう？と悩む時期
「価値」という言葉を考えたときに、思い浮かんだのはRubyKaigi2022のMatzの基調講演です。
マイベストでは毎年スポンサーとしてRubyKaigiに参加させてもらっており、このときも現地で講演を聞いていました。（レポートは2023年のものですが）
それまでは普段使っているプログラミング言語としてしかRubyを見ていなかったのですが、この講演を聞いて、Rubyを使って作られたソフトウェア、プロダクトが人々に提供している価値も、Rubyによって支えられているという事実、そしてRubyをオープンソースとして無料で使わせてもらっているという「Rubyの価値」に気づき、自分の中でパラダイムシフトが起きていたので印象的な講演でした。
つまり、Rubyという言語が生み出している価値というのは直接的には見えづらいかもしれないが、多くのプロダクト、そしてそのプロダクトを通した事業や企業に経済的な価値がついているのであれば、それはRubyがあることの価値ともとれる、ということだと受け取りました。
「作る」以外のエンジニアの価値
私は「ものを作る」という仕事をしたくてエンジニア職を選んだわけですが、この「作る」という言葉の意味が、就職当初の認識はかなり狭いものだったなと今では思っています。
例えば新規事業の開発においては「開発する」といっても、それがそのまま「実装する」「ユーザーにデリバリーする」には直結せず、「学びを貯める」や「作らないでできる（最短の）方法を考える」などの目的に応じたいろいろなバリエーションがあります。
たとえユーザーに価値が直接届かなかったとしても、機能を開発したり、なにかを「つくる」過程で得られた知見や学びには当然価値があるのです。
新規事業におけるエンジニアの役割や意識したことについてBuriKaigi2024にて登壇した資料です。
そういった場合にエンジニアとして僕が生み出している価値は何なのだろうか？ということを考えたときに、直接的にユーザーに何かを届けることには限らなくてもよいのではないか、と思ったのです。
「作った機能を提供する」以外でのエンジニアとして自分が提供できる価値はなにか？ということを考えた結果、思い浮かんだのが「複雑性」という言葉です。
ソフトウェア開発も複雑性との戦い
「複雑性」という言葉はよくソフトウェア開発で使われることばかと思います。僕が初めて意識したのは、新卒1〜2年目で、『A Philosophy of Software Design』という本の輪読をした際でした。
新卒1年目の頃はただ要件を満たすようなコードを書くことで手一杯だったのですが、だんだんとシステムの設計まで行うようになると、そのモジュール、あるいはクラス、そしてメソッドの役割が何で、それを使うときに使い手が知らなくてはいけないことはなにか？という視点でものを考えていきます。
そもそもの機能の切り口や仕様を変えたらもっとシンプルになりませんか？というような仕様の見直しの提案もできるようになりました。
こちらの記事を見て、その考え方がしっくりきたので貼っておきます。
エンジニアの仕事の本質は「複雑なものをシンプルに提供すること」
こうした概念をあてはめていくと、エンジニアとして提供している価値は「複雑なものをシンプルに提供すること」であるというような整理が自分の中でできていきました。
新規事業においては考えなくてはいけないことがたくさんあります。ユーザーが誰で、課題が何で、どうすればそれを解決できて、どのように普及していくのか。さらには、どのようにプロダクトに落とし込むのか。
こうした入り組んだ（複雑な）命題において、自分のエンジニアとしての役割はいかにその中での開発をシンプルにできるかということなのではないかということ考え始めます。
取り組まなくてはいけないたくさんの課題に対して、なるべくシンプルな回答や解決方法、あるいは問題の違った捉え方を提供すること。
「百聞は一見にしかず」という言葉もありますが、デモの効果はとても大きいです。
ああでもない、こうでもないというチーム内の議論が、プロトタイプを見るだけで、すぐにイメージが共有化されたり、できたものを見たときにそれを「ほしい」「いいね」と思うかどうか？というような判断軸もわかりやすくなります。
こうした見える形でものを提示できるのは、実際に手を動かしてものを作れるエンジニアだと思います。
ちょうど同じ時期に取り組んでいたマイベストのバックエンドガイドラインの策定においても、「チームが増える中でテストのカバレッジを上げたい」という課題を解決するために、いろいろな要素を考える必要がありました。
こちらも実際にコーディングをしたりシステムをつくる仕事ではないですが、毎回バックエンドエンジニアが実装時に考えていた「どこまでテストを書けばいいんだろう？」「大丈夫なのか？」「レビューで指摘してよいのだろうか？」などの問題にして、咀嚼したり汲み取ったりしながら、「ガイドライン」というシンプルな形でチームに対して提供しました。
結果として複雑だった開発のフローを少しはシンプルにできたのですが、これも「作る」以外で価値を提供できたものかなと思います。
このような、「ものを作る」という以外にも、こういった複雑性をなるべくシンプルな形で他の人に提供すること。
それが、ソフトウェアエンジニアとして生み出せる価値なのではないかという大きな気付き・学びを得た瞬間でした。
これから
そうはいったものの、ではどうすれば「シンプルになった」と言えるのか。それはまだまだわからないことも多いです。
何が一番最適かはケースバイケースでしょうし、だからこそ僕たちエンジニアがちゃんと取り組む意義があるのではないかと思っています。
そのためには、技術やドメイン知識のさらなる習得に加えて、「同じシステムを長期間メンテナンスし続ける中でふりかえること」も大きいのかなと思います。マイベストに関わって3年、同じシステムを長期間メンテする中で見えてくるものがあるのかはこれから意識していきます。
「複雑性」という観点でマイベストをみると「選択」という領域もとても複雑性が高い分野だと思います。
こうした課題に対してシンプルな解決策が提供できるか。これはマイベストのエンジニアとして、今3年を終えた今だからこそ、取り組みたい課題だと思っています。
こうして、私の社会人3年間が終わります。新卒時代が終わるタイミングとなりますが、これから4年目もまた楽しく頑張っていきます！
株式会社マイベストのテックブログです！ 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion
すごくいい記事！