shiloの素人日記

素人考えを書きます

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ならではの学びもたくさんありましたが、現在の環境ではまた異なった学びもたくさんあり、とても楽しいです。

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

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

プロダクトヒストリーカンファレンス 2024の参加レポート

はじめに

こんにちは、shiloです。とにかく久しぶりの投稿になってしまいました。 今後は忙しさを理由にせずに定期的にブログ書きたいなと思っています。（とりあえず宣言しとけば、続けられるかなという思い・・・笑）

今回の記事では2024/11/30（土）にTODAホールで開催されたYOUTRUST社主催のプロダクトヒストリーカンファレンス2024に参加してきたので、参加レポートをまとめようと思います。

ぱっと結論を言うと、普段なかなか業務で得られないようなプロダクト観点での学びがたくさんあり、参加してとても良かったです。

プロダクトヒストリーカンファレンス2024の概要

公式メッセージより引用：

「プロダクトヒストリーカンファレンス2024」は、 プロダクトやサービス開発の軌跡から学びを深める、 テックカンファレンスです。 社会課題を解決へと導いた技術。技術の発展がもたらす未来。 未来をより良くするための、終わりなき探究と創造。 そうして生まれたサービスやプロダクトが、 新たな当たり前を生み出し、 私たちの生活に欠かせないモノやコトになる。 その背景には、開発段階からの小さな成功の積み重ねや、 数多くの困難・失敗、試行錯誤の繰り返しがあります。 開発現場のリアルな話からヒントやきっかけを得て、 未来の可能性を広げながら、 一緒に日本のモメンタムを上げていきましょう。

公式メッセージにも記載がある通り、プロダクトヒストリーカンファレンスは各社のプロダクトやサービス開発の歴史における成功談や失敗談、学びを共有することを目的としているテックカンファレンスでした。

ある個別の技術にフォーカスというよりはプロダクト開発にフォーカスしているカンファレンスだったので、参加者はエンジニアだけではなく、PdMの方も結構な人数が参加していたのではないかと思います。

私自身もエンジニア以外の方ともコミュニケーションを取ることができたので、そういった意味でも参加して良かったなと思っています。

印象に残ったセッション

どのセッションも各社のCTOやVPoE、PdM職の方の発表がほとんどでした。 なので実体験として経験された話を中心に、中には結構生々しい体験談もありました。いずれもとても参考になる濃密な内容だったという印象です。 ここではその中でも特に印象に残った3つのセッションについて簡単に紹介させていただきます。

事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談

こちらは、株式会社LayerXのVPoEである高橋さんと株式会社ニーリーのCTOである三宅さんによる「事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談」セッションです。 このセッションではLayerX社の資産運用サービスであるALTERNAとニーリー社のプロダクトの一つであるMobility SaaSにおいて、①立ち上げ期×成功談、②立ち上げ期×失敗談、③急成長期×成功談、④急成長期×失敗談という各象限でどのようなことがあったのかお話いただきました。

特に印象的だったのは高橋さん、三宅さんの両者が「エンジニアが事業サイドに染み出すカルチャー・プロセスを作ったことが成功の元となった」とお話しされていたことでした。LayerX社においてはエンジニアも企画に参加することで全社的に企画のリソースが増え、多くの改善施策に取り込めるようになったことで、成果が出たとのことでした。また、ニーリー社においてもエンジニアがユーザーや業務解像度を上げて、必要なものをエンジニア自身が考えて開発することで、いち早くデリバリーに繋げることができた結果、成果につながったとのことでした。 その上で、エンジニアが事業サイドに染み出すことができるようになったらPdMはどのような立場を取ればいいかということに対しては「より深くドメインを理解しなければならない」、「ドメインエキスパート的な立ち位置になる」とお話しさせていました。

このセッションを聞いて感じたのは、プロダクトを立ち上げ、成長させていくためには組織内の役割を職種ごとに完全に分けるのではなく、グラデーションを作っていくことが素早くデリバリーをしていく上では非常に重要なのかなと感じました。その中でも特に「エンジニアが事業サイドに染み出す」というグラデーションによる効果が大きいのだと理解しました。この「エンジニアが事業サイドに染み出す」はこのセッションだけではなく、今回のカンファレンス全体の一つキーワードだったような気がしています。

登壇資料はこちらです。

領域を絞ったマルチプロダクト開発における技術戦略＆開発戦略

こちらはエムスリー株式会社のVPoEである河合さんと株式会社メディカルフォースのCTOである畠中さんによる「領域を絞ったマルチプロダクト開発における技術戦略＆組織戦略」セッションです。 このセッションではおける領域を絞ったバーティカル領域における開発の面白さや難しさ、開発組織について対談するものでした。

内容としては以下のようなお話がありました。

  • バーティカルな領域での開発の面白さ・難しさ

    • 面白さとしてはエンジニア視点では技術選定などのチャレンジする機会がとても多い。経営・戦略視点では似通った領域が重なり、新たな価値を生み出すことができたり、データが思いもよらない別の領域で効果を発揮したりすることがある。
    • 難しさとしては普段目にしないようなドメイン知識を身につけないといけない。特にプロダクトの成長とともに組織の人数は増えていくが、その時に全員に対してドメイン知識や課題を同じ理解度で共有することは難しい。

  • マルチプロダクト開発における開発組織の工夫

    • 課題はみんなで共有するけど、解決策は属人的に解決している
      • プロダクトが多いので、全員で共有するとコストがかかる
    • エンジニアリングのいいところはスケールできること
      • 一人で解決できないこともチームで解決できる
        • コードレベルで分担できる
    • その上で、全員が同じ知識を持っていることが良くて、属人的であることが本当に悪いことなのか
      • 属人性を排除するにもコストがかかる
      • 属人性によるリスクを考えるのがマネジメントの仕事

  • 野球を実際にする

    • 野球のドメイン知識を表層的で学んだ人はベースを一周すればいいと考え、軽量のウェアや素早いスパイクを開発する。
    • でも本当の課題はそこではない。
      • 打つためにはどうするのか、抑えるためにはどうすればいいか
        • なので結局は自分が実際に現場で体験して課題を実体験してみることが大事

特に印象的だったのは属人性の話と野球の例え話でした。この話を聞くまで属人的であることは悪であるという認識がありましたが、振り返ってみると業務とかでも属人性をなるべく排除するために不必要以上のことをやってしまい、デリバリーが遅くなってしまっていることもあるかもしれないなと思いました。また野球の話ではやはりバーティカル領域においてプロダクトを大きくしていくにはドメイン知識を理解した上で、正しく課題を認識することが重要であることを再認識しました。

ドメイン特有の制約と向き合うプロダクト開発と事業成長！PMF前後それぞれの楽しさとは？

こちらは株式会社UPSIDERのEngineer Manager兼Tech Leadである関野さん、キャディ株式会社のVPoEである藤倉さん、株式会社リクルートのエンジニアである高橋さんによる「ドメイン特有の制約と向き合うプロダクト開発と事業成長！PMF前後それぞれの楽しさとは？」セッションです。金融や製造業というドメインと向き合う開発の現実と醍醐味やPMF達成前後の変化等についてパネルディスカッション形式でお話しいただきました。

セッションの中で関野さんが「PMF前後から攻め（新規機能の実装）と守り（セキュリティ対策）の比重が変わっており、最近はプロダクトが成長するにつれてセキュリティが目に見えて増えてきたので、守りの比重が増えてきた。人材的にもPMF前後から求めるスキルの幅が広がってきた。」とお話しされていたのが印象的でした。 私自身そのようにプロダクトの立ち上げから関わった経験はないのですが、そのように各フェーズにおいて比重が変わっていくのはその通りで、それを乗り越えていくからこそ成長していけるんだろうなと聞いていて、とても納得しました。

スポンサーブース

朝イチのまだ人がまばらな時間。この後は常に大盛況でした。

スポンサーブースでは10社以上がブースを出店しており、常に大盛況でした。 ブース企画としては自社のプロダクト・サービスの説明やアンケート参加などがメインでした。 プロダクトヒストリーのカンファレンスということもありアンケートに関してはプロダクト文脈のアンケートがいくつかありました。

あと、時間が合わず行けなかったのですが、スポンサーブースの一角には登壇者の方と登壇後に話ができるMeetUpコーナーがありました。 何人かの登壇者の方に直接聞いてみたいこともあったので、次回参加時には計画的にMeetUpコーナーも活用したいと思います。 また、コーヒーコーナーがあり、受付時にもらえるタンブラーにコーヒーを入れていただくことができました。（熱々のコーヒー飲みながら、講演を聴くことができたのは、すごくよい体験でした）

懇親会

残念ながら所用により参加できなかったのですが、プロダクトヒストリーカンファレンス2024では懇親会も開催されました。 お寿司食べたかったです。

懇親会もたくさん参加されていたみたいですね！

その他

今回開催されたTODAホールですが、とにかくめちゃめちゃモダンでおしゃれでした。 （調べてみたところ2024年11月3日オープンということでとても新しいらしいです。）

実は私、建築学科出身で以前は建築家を目指していた身なので、おしゃれな建物に行くと結構テンションが上がってしまいます。 開催される会場の雰囲気もカンファレンスの満足度というのに結構影響を与える重要な要素だなあと感じました。 オブジェもおしゃれですね。

階段？？

終わりに

今日の発表を聞いてエンジニアでもドメイン知識を積極的にキャッチアップし、事業サイドに染み出していくカルチャーやプロセスを作りながら素早くデリバリーしていくことがプロダクトを成長させる一つのポイントであると実感しました。そのためにも営業、PdM、エンジニアといった職種で完全にやること分けるのではなく、あえて組織内でグラデーションを作っていくことが今後必要なんだろうなと思います（難易度は高いですが、、）。

最後に、これまでテックカンファレンスは何度か参加してきましたが、今回のようなプロダクトにフォーカスしたテックカンファレンスは初めてで、上記の通りとても学びが多かったです。また来年もぜひ参加したいと思います。

（YOUTRUSTさんはじめ、ご登壇いただいた各企業の方、素晴らしい機会をありがとうございました！）

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

【雑記】今年の目標（プライベート編）

はじめに

こんにちは。ryoです。

以前、以下の記事で自分なりのミッションステートメントを設定しました。

hogarakaryo.hatenablog.com

今回はそのミッションステートメントに沿った今年の目標（プライベート編）を考えてみたので、この記事で自律も兼ねてまとめたいと思います。

仕事編は近いうちにまた記事にします。

続きを読む

【Django】便利！Django Debug Toolbarのインストール方法

はじめに

こんにちは。ryoです。
今回はDjangoをフレームワークとしたWebアプリを開発する際に、開発環境にインストールしておくと何かと便利なDjango Debug Toolbarのインストール方法について解説します。
使用方法は今後別記事でまとめたいと思います。

Django Debug Toolbarとは？

Django Debug ToolbarとはDjango Webアプリケーションをデバッグするのに非常に有用なサードパーティ製のツールです。
ツールをインストールすると開発環境のブラウザにツールバーが表示され、以下の情報を常に確認することができます。
※表示する情報はカスタマイズすることもできます。（後述の補足1を参照）

続きを読む

【雑記】ミッションステートメント

はじめに

こんにちは。ryoです。

この間ついに「7つの習慣」を読みました。 大学院卒業直後に購入しましたが、読んでいると眠くなってくるため3年くらい放置していましたが、2023年11月くらいに再チャレンジしてやっと読了です。 社会人経験が少しずつ増えてきた事と結婚したことが影響しているのか以前読んだ時よりも色々納得できる部分が増えた気がして、思いの外すんなり読むことが出来ました。

続きを読む

【Python】プロキシ認証環境下でpipコマンドを使用する方法

はじめに

こんにちは。ryoです。
この間、プロキシ認証環境下でpipコマンドでパッケージをインストールしようとしたところプロキシによってpipが上手くいかなかったので、その場合の対処法を備忘のためにまとめます。
環境はWindows10です。

結論

続きを読む

【Django】10分でWindowsにDjangoの環境構築

はじめに

こんにちは、ryoです。
普段使用しているPCはMacですが、今回たまたまWindowsにDjangoの環境を構築する機会があったので、情報共有も兼ねてまとめたいと思います。
最低限ですが、この記事でまとめている手順を踏んでもらえばローカルサーバーの起動（トップページの表示）までできるようになります。
検証環境はWindows10です。

①Pythonのインストール

続きを読む