こんにちは！８月に入社したFumiyaです。

SWEとしてドクターズプライム（以下DP）に入社し、はや1ヶ月が経ちました。

この記事では私がDPに入社し１ヶ月で感じた、以下３点を中心にお伝えしたいと思います！

①　エンジニアチームにはどんな人がいるのか
②　プロダクト開発のスタイル
③　自分が今やっていること

自己紹介

私はエンジニアとしては２年目でまだまだ歩み始めたばかりです。DPに入社する前はSES企業で金融系の現場にアサインされていました。

かなり大規模なプロジェクトではあったものの、アサインして２日ほどでコードを書いていた記憶があります。ちなみに完全未経験でスタートだったので当時はかなり驚きました。

幸い設計書がかなり細かく記載してあること、ウォーターフォールであったため工数に余裕があったこともあり、コードの海に溺れながらもなんとかやっていた気がします。

そんなこんなで１年が経った時、自分のキャリアなど考えるタイミングとなり、エンジニアになった時に2年目はジャンプアップすると決めていたため、思い切って転職を決意しました。

そして巡り会ったのが DPでした！

入社を決めた理由は、この後に書いているので自己紹介はこれくらいにして、エンジニアチーム紹介に移ります！

エンジニアチーム紹介

エンジニアっぽくないエンジニアが多い印象です。

流行りのドラマのモノマネをやっていたり、バズっているネタが飛び交っている感じです。

DPは全員出社というスタイルをとっているためメンバーとの物理的な距離が縮まり、他チームとの連携が容易に行える環境にあります。

その流れで普段のコミュニケーションが活発になり、チームという垣根を超えてランチに行ったりバスケ、サウナに行っていたりとアクティブなメンバーもいます。

入社したメンバーが実施するオンボーディングプログラム運営の担当しているエンジニアがいたりするのも開発だけじゃないって感じがします。

とはいえ、根はエンジニアなのでPCの組み立ての際に目を輝かせていていたり、社内勉強会を開催したり、外部の勉強会に参加しメンバーに共有するといったエンジニアっぽい文化もしっかりあります。

技術的な事に限らず、MBTIに詳しくなってメンバー同士の相互理解を深めたり、外国籍メンバーの母国語でコミュニケーションがとりたくて語学の勉強したりとインプットを絶やさずに知識をアップデートし、既存の枠にとらわれず柔軟に考え方を取り入れる文化があります。

DPの開発スタイル

"荒削りミニマムリリース" ＋ "長期のユーザー価値を追求"

シンプルに表すならこれ一択です！！

"荒削りミニマムリリース"

ミニマムリリースを実践する上でプルリクの粒度はかなり意識しています！

プルリクを最小限サイズで出すことの恩恵は

・レビュアーの負担を軽減
・リードタイムが短くなる
・手戻りを最小限にとどめる

などがあり、開発生産性が高い状態を保てるようになります。

ミニマムリリースの考え方はDPのPrinciple（行動規範）にも含まれていてエンジニアメンバーだけでなくDPメンバー全体に浸透しており、D-CAPを爆速で回しています！

D-CAPとはPDCAのサイクルのまずDoから始めることで未知の領域に対して強みを発揮する考え方です！

スタートアップらしいですね。

"長期のユーザー価値を追求"

長期のユーザー価値を追求するためにDPではアウトカムを重視しています！

アウトカムとは、アウトプットがユーザーにどのような影響を与えるかを考慮したものです。タスクの優先度を明確にするために活用しています。

そしてリリースがあった際には、エンジニアの開発定例会議でMetabaseを用いてユーザーの動向を可視化し、機能の影響度の振り返りを行っています。

アウトカムを導入することで、これまで感覚的に行なっていたタスク選択が明確な指標を持って選択できるようになり、開発時のモチベーション向上にもつながると思います。

また、定期的に影響度を確認することで想定した影響力と誤差があった場合にも、リリースを重ねるごとに影響力の予想の精度がユーザーとの感覚の差を少なくすることができ、ユーザーに寄り添った提案ができると考えています。

今やっていること

入社して一定期間は社内のサービスや必要なスキルのキャッチアップのためオンボーディング期間が設けられています。

私はまさに絶賛オンボ中です！！

まず初めにやったことがミッション、ビジョン、CorePrincipleの理解です。

現在、DPは選考過程でお試し入社の期間が1〜1.5日程度あるのですが、その段階で事業やミッション、ビジョン、CorePrincipleの説明を受けます。

なので、ある程度 DPへの解像度をもった状態で入社となります。

ですが、最重要項目であるOKRを作成するためにさらに事業や会社理解の解像度を上げていきます。

OKR（Objectives and Key Results）は目標達成管理フレームワークの1つで DPメンバー全員が作成しています。

OKRを活用することで日々何をすべきかが明確になり、今やっていることに全力を注ぐことが出るようになるので、なんとなく過ごしている時間がなくなり生産性が向上します。

私の場合は「いち早くオンボを終わらせDPのエンジニアとして開発する」というObjectivesをおいて日々キャッチアップを進めています。

キャッチアップはどんな感じで行なっているかいうと、サービスの技術スタックと自分のスキルの差分を出し、足りていない分野を掛け合わせて機能を提案し、コーディング、レビューしてもらう形をとっています。

前職は畑違いのだったこともありWeb業界でのキャッチアップの量は膨大になっていますが、この形式を取ることで目に見える形で差分が埋まっていき自己効力感が高まるのですごくワクワクしながら毎日過ごせています。

また、実際の開発をする時のプルリクの粒度を同時に学べることやフィードバックをもらうことで既知の分野でも視点が違う指摘がもらえたりするのでアンラーンの機会があるといった一石二鳥のポイントがあったりします。

レビューをしてくださってるメンバーもブログを執筆しているので、ぜひ読んでみてください！

これまでに感じたこと

これ以降は"エンジニアとして"だけでなく、 "DPについて感じたこと"をお伝えできればと思います。

入社してみたら聞いていた話とイメージが違った...と言う話はよくあることだと思います。私の場合は DPの選考過程と入社してからのギャップはありませんでした。

選考時にDPメンバーに事業について聞いた際に一人一人の解像度、熱量の高さが話をしているだけで伝わってきました。その熱量がミッション実現という同じ方向を向いているのがすごいなと感じ、毎日Day1のような熱量があるDPで開発したいと思い入社を決めました。

サービスをより良くするためにD-CAPを回し、考え方を柔軟に取り入れ経験学習サイクルを回すことでサービスとともに自身の成長を実現しているというのが目に見える形であり、仕組み化されていると感じます。

このご時世出社に抵抗がある方は多いと思いますが、 DPは出社のメリットをうまく活用していると思います。

スムーズなコミュニケーションを実現したり、熱量の伝播が起こったり、同じ方向を向いているという感覚が身近に感じられることで一体感が生まれていると感じました。

DPらしいエンジニア

最後に DPらしいエンジニアとはどんなイメージかというまとめて終わりにしようと思います。

・「経験学習サイクルを回している」
・「既存の知識を捨て去り、知識のアップデートができる」
・「必要なことを明確に把握し、スピード感を持って開発できる」

これらが私が入社してから感じたDPらしいエンジニア像です。

エンジニアとしては若手ですが、DPエンジニアとして盛り上げていきたいと思います！

よろしくお願いします！