はじめまして。CX開発グループでエンジニアをしている高橋です。
今年の8月にホワイトプラスへ中途入社し、気づけば4ヵ月が経とうとしています。
ようやく開発フローにも慣れてきたタイミングなので、今回は「入社4ヵ月目のエンジニアが実際にどんな働き方をしているのか」をご紹介しようと思います。
これからホワイトプラスへの入社を検討している方の参考になれば幸いです。
また、将来の自分が読み返したときに「そういえば最初はこんな感じだったな」と振り返れるような記録にもしておきます。
働き方
フルリモート
エンジニアは基本フルリモートです。
もともと出社への抵抗はあまりありませんでしたが、それでも毎朝の通勤がなくなったのは解放感があります。
電車遅延時の変な焦燥感なども無くなって、精神衛生上とても良いです。
勤務時間
勤務形態はフレックスで、出社時間は特に決まっていません。
私は前職の習慣もあり、9時ごろにログインすることが多いです。
チームとしても、デイリースクラムがあるため基本10時には全員ログインしています。
退勤については特に何もなければ私は18時〜19時ごろには上がっています。
開発用PC
開発用に会社からMacBook Proが貸与されます。
ずっとWindows PCだったので、入社したての頃は細々した違和感がありました。
今はだいぶ慣れまして、逆にプライベートでWindowsを使う時に、Macの癖で謎のキーを押してしまうくらいに仕上がっています。
唯一残念なのはWindows時代に使ってた色々なフリーウェアが使えなくなったことですが、これもそのうち代替が見つかるでしょう。
「Mac 初めてだけど大丈夫かな…」という方も、4ヵ月毎日使っていれば自然と慣れるので安心してください！
一週間の過ごし方
CX開発グループでは1週間＝スプリントとしてスクラム開発をおこなっています。
私が参加している定例イベントは以下の通りです（先輩方はもっと色々なミーティングに参加している様子）。
- 月曜日：スプリントプランニング、勉強会
- 火曜日：特になし
- 水曜日：バックログリファインメント、EMとの1on1
- 木曜日：特になし
- 金曜日：スプリント振り返り、エンジニア定例ミーティング
スプリントレビューがない理由
スクラム経験者の方は「スプリントレビューはやらないの？」と思われるかもしれません。
私も気になって聞いたところ、以下の理由で実施していないとのことでした。
- 大きな機能開発の際は事前にビジネスサイドと認識合わせをしておりズレが起きにくい
- エンジニアが高いドメイン知識を持っているため認識の齟齬が少ない
- 不明点はチャットなどですぐに相談できる
チームにとっての最適解を探した結果こうなっているのだと思いますので、そういうものと理解しています。
日々の作業
前日からのタスクがあればその続きから取りかかります。
大きな新規機能開発の時は進め方も少し変わるようですが、現在の私の1日は概ねこんな流れです。
デイリースクラム
スクラムメンバー全員で、Google Meetでおこないます。
全体の共有事項や、前日追加のタスクが来ていないかの確認を行います。
その後、曜日ごとの確認事項を共有して、スプリントタスクの確認という流れです。
スクラムメンバーごとに、「先日やったこと／今日やること／困っていること」を順番に報告します。
教科書通りのデイリースクラムというよりも、毎日の進捗報告会というイメージの方が合っているかもしれません。
今はスプリントが常に順調だからかもしれませんが、スプリントゴールの達成に向けての作戦会議みたいな雰囲気ではないです。
タスクの確認
カンバン方式で進めており、レビュー依頼まで完了したら次の優先タスクへ着手します。
計画時に一度は確認しているはずですが、着手時に不明な点があれば、スクラムメンバーやビジネスサイドに確認を入れます。
バックログリファインメントで粒度が細かくなっているため、1日1タスクはレビュー依頼まで行くイメージです。
コーディング
前職ではAIはサジェストのお供くらいの位置付けだったのですが、ホワイトプラスに入社してからAIエージェント無しではコーディングできない体になりました（笑）
社内にはCursor、Devin、Claude Codeなど複数のツールが整備されています。
私は基本Cursorを使いつつ、簡単なタスクはDevinに並列で進めてもらうという使い方をしています。
入社直後はコードの所在がわからないことも多いですが、AI に「この処理どこ？」と聞くと教えてくれることもあり、立ち上がりがとても楽になります。
少し前の記事になりますが、チームで使用しているAIツールはこちらにまとまっています。 blog.wh-plus.co.jp
コードレビュー
コード管理は GitHub を使用しています。
そのためレビューもGitHubのプルリクエストでおこないます。
CX開発グループでは軽微な修正を除き、スクラムメンバー全員でコードレビューを行います。
目的は、単に品質の担保だけでなく、
「自分が担当していない領域のコードも理解できるようにする」
という学習の側面が大きいです。
全員レビューだと負荷が高そうに思われるかもしれませんが、その分スプリントのタスク量を調整しています。
ある程度学習が進んだらレビュアーを減らすこともできると思うので、そこからスプリントで消化できるタスク量が伸びたり、開発のリードタイムが縮んだりしていくのかなと思っています。
受け入れテスト
レビュー完了後、リリース前にビジネスサイドに受け入れテストをしてもらいます。
必ずしもタスク単位とは限らず、より業務フローに近い粒度での確認になります。
また、ビジネスサイドとの日程調整も必要なので、実装当日にすぐテストフェーズへ入ることはあまりありません。
当日はテスト環境へのデプロイと、テストするために必要な環境の整備などをしていきます。
リリース作業
受け入れテストに問題なければリリース用ブランチへマージします。
ホワイトプラスでは毎日本番リリースがあり、担当者は日替わりの抽選制です。
リリース用のコマンドを実行するだけですが、まだ慣れず毎回少し緊張しています。
（番外）アラート対応
本番環境のエラーは Slack に通知され、CX開発グループでは曜日ごとに担当者を決めて対応しています。
私の担当は月曜日と水曜日です。
月曜朝は土日の軽微なアラートが溜まっていて大変なこともありますが、普段触らない領域のコードを読むよい機会になっています。
過去に発生したことがあるものはドキュメントやSlackのログを検索すれば対応方法が出てきます。
スクラム内でレビューを担当するまでは、自分がタスクで担当してない部分の作りを知れるのはここだけだったので、大事な作業だと思います。
まとめ
入社4ヵ月目の働き方をご紹介しました。
ポジションによって違いはあると思いますが、ホワイトプラスの一般的なエンジニア像として参考になればうれしいです。
文章にしてみると、社内ではさまざまな自動化やツール活用が進んでおり、余分な作業が削減されていると改めて感じました。
おかげで開発に集中できる環境が整っていると思います。
一方で、受け入れテストで一旦詰まりが発生するプロセスになってるなと改めて感じました。
アクターが増えるので仕方ない部分があると思いつつ、未来の自分がうまく改善していることを期待して本記事を締めたいと思います。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！ ネットクリーニングの「リネット」など、「生活領域×テクノロジー」で事業を展開しています。 弊社に興味がある方は、オウンドメディア「ホワプラSTYLE」をご覧ください。オンラインでのカジュアル面談も可能ですので、ぜひお気軽にお問い合わせください。
