SIerからWeb系事業会社に転職して半年近く経過したので、ここまでの学びをいくつか振り返る

はじめに

こんにちは。shiloです。 SIerからWeb系事業会社にエンジニアとして転職して半年くらいが経ちました。 年末も近くなってきたので、ここら辺で一回転職してからどのような学びがあったのか振り返ってみます。

簡単に前職のご紹介

• 大手SIerで4年間、官公庁向け業務システムの開発に従事していました。
  • ロールとしては初め開発メンバーで最後の1年は単年度プロジェクト（20〜30名規模）のPjMを担当しました。
• オンプレ環境だったので年間の半分くらいは現地への出張でした。
• この時の技術スタックとしてはC#、Linux、SQL Serverあたりです。
• 個人でDjangoを使ったWebアプリを公開したりして遊んでいました。
  • 前職も非常に楽しかったですが、Web系の事業会社に興味が出てきてしまい、2024/4に現在の会社にエンジニアとして転職をしました。

近況

• toC向けのプロダクトの開発を主に担当しています。
  • 私自身幅広い分野に興味があったので、バックエンド中心ではありますが、フロントエンド、インフラも一部担当しています。
  • 設計や実装、テストだけではなく、最近は要件定義のフェーズにも関わったりしています。
• 技術スタックとしてはRuby on Rails、Vue.js、AWS、MySQL、Dockerあたりが普段よく触っている技術です。前職に比べると幅広くモダンな技術に触れている印象です。

入社して半年の学び

SIerからWeb系事業会社に転職してみてどんな学びがあったのか業務に対する姿勢やマインド面中心の観点で振り返ってみようと思います。 とりあえず先に申し上げておくと、上記の通り環境が大きく変わったこともあり、学びがとても多いです。 ただそれが嫌というわけではなく、むしろ毎日が充実していてとても楽しいです。

そんな中で私は普段、日報を書いているのですが、その中でこれはマインド面の学びだったなあと思うことを一覧化して時々眺めて見返しています。 現状150行くらいになっているのですが、とてもそれらの全てを書くことはできないので、特に個人的に業務に対する姿勢やマインド面から学びだったなあと思うことを挙げていきます。

許可より謝罪

これは一番のマインドシフトかもしれないです。どこで初めて聞いたかわからないですが、初めて聞いた時からとてもしっくりきています。

前職では本当にとにかく絶対大丈夫というもの以外は社内やお客さんに対してとりあえず許可をとっていた気がしています。会社の上司や先輩もみんなそんな感じで仕事を進めていたので、それが当たり前だと思っていました。

それに対し、今は絶対にミスしちゃいけない時は確認するけど、それ以外の時はとりあえず自分の判断でやってみるという感じに自然となっている気がしてます（ダメならごめんなさい精神です）。

なんでこのような変化があったのかなと考えてみると、確認すること自体は間違いではないとは思うのですが、やはり自分や相手を含め時間をとってしまう上にそれだけスピードが遅くなるということにある時気づいたからです。 それよりもとりあえず多少の間違いは大丈夫だからどんどんやってみてバリューを出していこうという雰囲気が今の環境にはあるような気がしており、それが求められている気がします。 なりより個人的にも確認しているよりすぐに手を動かした方が単純に楽しいと思います。

この学びは普段の行動にも大きな影響を及ぼしていると思うので、今回挙げさせていただきました。

ちなみに調べてみると、けんすうさんが10年くらい前に記事になさっているのを発見したので、Web系の業界では割とスタンダードな考えなのかもしれません。

blog.livedoor.jp

振り返りをして共有すること

上記でも少し書きましたが、私は毎日日報を書くようにしています。 入社当初先輩に指示されて実施していましたが、やっていくうちに振り返りの効果を実感することができましたので、最近は自主的に続けています。 やり方としては大体20分くらいでその日をYWTで振り返り、それを自分の分報チャンネルに投稿するというのをやっています。

このような日報がどのような効果があったかというと、一言で言えば、「日々の気づきを学びに昇華できる効果」と「その学びと非常に親和性が高いフィードバックがもらえる可能性が高い効果」があったと思っています。

まず、「日々の気づきを学びに昇華できる効果」についてですが、一般的に人は仕事をしていく中で細かいものを含めれば莫大な数の気づきがあると思います。ただ、それって都度振り返らないと忘れちゃって、気づきがゼロとは言わないまでもゼロに近いところまで戻ってしまうということにある時気づきました。 せっかくの気づきをゼロに戻してしまうのはとてももったいないので、一日の最後にYWTで振り返ることを始めたところ、全ての気づきは無理でも重要な何個かの気づきを学びに昇華できることに気づきました。学びに昇華できれば、それは気づきに比べて忘れづらくなるというのも実感しています。

次に「その学びと非常に親和性が高いフィードバックがもらえる可能性が高い効果」についてですが、これはこのままの意味です。 得た学びを分報チャンネルに投稿することで読んでくれた他の人に対してその学びを贈ることができます。 また逆にその学びに対してより深い知見やフィードバックが返ってくることも多々あり、さらなる学びに繋げられることも大いにありました。 このような学びのサイクルのようなものは前職にもありましたが、前職よりも頻繁にサイクルが発生している気がしており、自分としてはとてもありがたいなと思っています。

はじめは若干学びを共有するのは緊張しますが、次第に慣れてきます。 日報おすすめです！

エンドユーザーの体験(使いやすさ)を1番に考えること

これも前職からのギャップに驚いた部分であり、とても学びになった部分です。

前職では主に業務システムを担当していたので、エンドユーザーは業務やシステムに精通しているオペレーターの方が中心でした。なのでエンドユーザーの体験ももちろん重要視はしていましたが、それより一つの画面でたくさんのことができる機能重視のシステムが求められていたと考えています。

対して現在担当しているプロダクトは toC向けのサービスのプロダクトであるため、機能よりもエンドユーザーの体験が1番優先順位が高いです。具体的には初めてこのサービスを使ったユーザーでも難なくサービスを利用した目的を達成できるかが開発においても1番重要視されています。

なので常にユーザーがこのサービスを使った際にどのように思うかというユーザー共感が開発の前提にあり、ここに関しては前職以上に間違いなく共感力というものが求められています。

私自身も機能の実装に目が入ってしまい、ユーザーの気持ちになりきれていなかったなと改めて感じることもまだまだ多々あります。今後もその辺りの優先順位を間違えないように開発をしていきたいなと思っています。

事業に関わる数字を知ること

私が現在担当しているプロダクトは一般ユーザーによる決済が含まれているので事業KPIの一つに流通量や流通額というものがあります。

私自身は前職の時もこのような事業KPIは時に意識をせずに仕事をしてきたので、転職直後は特に意識もしていませんでした。 ただ、ある時先輩がそれらの事業KPIについて説明をしてくれて、ここはこの案件が反映されたから流通量や流通額が伸びているんだど説明してくれた時がありました。 その時に、自分の業務の出来によって何万といったユーザーや何億といった規模の流通に影響を及ぼすことを初めて実感し、背筋が伸びるとともにとてもワクワクしという出来事がありました。 （前職では、あくまでも官公庁の業務システムが担当だったので、ユーザーは多くとも数百人程度だったのでユーザーの数では比べ物にならないです。）

それ以降は週に1回程度、KPIの数値をBIツールで確認するようになりました。 最近は、「この時取り組んだ〇〇はここで数字として現れていそう」など数字と事業全体に関する勘が少し鋭くなった気がします。 また、自分が関わった案件により流通量や流通額が増えた時は単純に嬉しいですし、下がってしまった時もその要因を分析するのも楽しかったりします。 モチベーションにもつながっているので、個人的にはこのように事業に関わる数字を意識しておくことも重要だなと学びました。

終わりに

若干雑になってしまいましたが、ここまで半年間の特に印象的な学びを振り返ってみました。　

SIerではSIerならではの学びもたくさんありましたが、現在の環境ではまた異なった学びもたくさんあり、とても楽しいです。

またどこかの断面で同じように学びを振り返ってみたいなと思います。 今回の記事が少しでもどなたかの役に立てば幸いです。

ここまで読んでいただきありがとうございました。