この記事はLITALICO Engineers Advent Calendar 2024 シリーズ2の11日目の記事です。
カレンダーは4枚あるので、ぜひこちらもご覧ください 
- シリーズ1: 「PHPで実現する無理やり並列処理：工夫と禁じ手」 by @euonymus さん
- シリーズ3: 「ライフワークバランスを確認するツールを作った話 - 1」 by @nonikeno さん
はじめに
LITALICOでエンジニアをしている @tomoki-oke です。障害福祉領域の転職サイト LITALICOキャリア の開発を行っています。
皆さん計画は得意ですか？自分は苦手です。いつも何かに追われています。
小さい施策は安定して進行できるのですが、施策が3ヶ月程度の規模感になると全体像が見えずコントロールできなくなってしまう感覚があり、大きい施策を担当することに苦手意識を持っていました。
幸い今年は先輩とチームを組んで施策を担当する経験が積めた1年でした。先輩の型を取り込んで開発スタイルを変えた結果、そんな自分が6ヶ月程度の施策を計画し、手応えを持って進められるようになりました。また自らプロダクト開発を推し進めている感覚も持てるようになり、開発が楽しいと思える瞬間が増えました。
本記事では最近担当した施策の実体験を題材に、自分が実践しきれてないことも多々ありますが、コントロールしてる感を持って開発リードするためのTipsを紹介しようと思います。
「コントロールしてる感を持つ」とは
そもそもコントロールしてる感を持てている、とはどういう状態でしょうか？
逆に自分の過去の経験からコントロール感を持ててない状態を思い浮かべると
- プロジェクトの終盤なのに、リリースまでに必要な開発タスクの全体像がまだ見えていない
- メンバーにコードレビューをしてもらった結果、根本的な部分の指摘を受けて大きく手戻りが発生してしまう
- PdMと議論する際に意見が衝突してしまい、うまく自分の意見を取り込むことができない
色々苦い経験が思い浮かびましたが、みなさんも似た経験があるんじゃないでしょうか？
（ない、あるいはすでに克服していればこの記事から得られるものはあまりなさそうです）
個人的な経験から、コントロール感を持つとは 「全体像が把握できており、主体的に意思決定ができている」 状態だと考えます。
補足：全体像とは？
何を指すかはケースバイケースで難しいのですが、正しい判断を下すために必要な情報のすべてというイメージです。
イメージしやすい開発を例に取りますが、例えば「記事系ページの本文の末尾にリンクの文言を追加する」という施策があり、その施策のPRで以下のようなコードがあるとします。
class ArticleController
def show
- @body = @article.body
+ @body = append_link(@article.body)
end
+ # リンクを追加する
+ def append_link
- このロジックがControllerのレイヤーにあることは適切なのか？
- 修正対象のページはこのPRで全てカバーできているのか？
などの疑問が湧いてきます。
「コーディングや設計のベストプラクティスと照らしてどうか」などこのコードだけで判断できる部分もありますが、
- 施策内容であれば「リリース予定のPR全体」で要件を満たしているか
- 設計方針であれば「コード設計の全体」で責務が適切に切られているか
などは適切な判断を下すために周辺情報が必要になります。全体最適な判断をするために必要な1歩引いた視点というイメージを指しています。
前提知識
自己紹介
- 新卒6年目。入社時から同じサービスを担当
- チームの中では2番目に古参で、サービス・コードの理解はある方
- 1人での開発の進め方は慣れてきたし、自信が付いている
- 普段、リード的な役割は担ってない
- 普段の開発は1人1タスクが多めで、サブチームで開発するという経験は少ない
- 個人的にスタンスを取って主張する、ということが苦手
- 過去2-3人の開発のリードを担当した経験はあるが、タスク管理・設計の多方面で手に負えなくなり、増員＆サポートのおかげでなんとかリリースしたという苦い経験も
担当プロダクト
- 障害福祉領域の求人サイトです
- 利用者は求人を掲載する法人と、求人に応募する求職者の2種類です
- 求職者の方が「自分らしいキャリアを歩めるように、自分にあった職場を見つけて応募し、入社できる」ように日々開発しています
普段の開発体制
チーム体制
- エンジニア: EM + エンジニアx6の合計7人
- 普段の開発
- 1人1施策で収まる規模感の開発が多く、サブチームを組んで開発することは少なめ
- 誰かがぐいっと引っ張る、ではなくチーム内で議論して開発を進めていくスタイル
- 普段の開発
- プロダクトマネージャー、デザイナー
今回の担当施策の性質
施策について
- 内容
- 求人に応募した求職者の方が、サイト上で法人の方とやり取りをするための「メッセージ機能」を開発する
- メッセージをやり取りする体験はLINEのようなイメージで、
- エンジニア系の求人サイトでも見かけるように、求人サイトとしては一般的な機能
- 求人に応募した求職者の方が、サイト上で法人の方とやり取りをするための「メッセージ機能」を開発する
- エンジニアの関わり方
- メッセージ機能を開発する、という企画検討部分はすでに完了しており、
- 1stリリースに含めるスコープの切り方・どういう仕様・要件にするか、などをPdM・デザイナー・エンジニアで議論して決めていくところから、実装・リリースまで関わる
チーム体制
- エンジニア: 自分 + 先輩エンジニアx2の計3人
- 「適切に共有してくれるならサブチーム内で意思決定していい」というレベルで権限委譲してくれており、開発の進め方の自由度は大きい状態
- このサブチームのリード的役割が、EMから自分への期待値
- リードといえども先輩とのチームなので、適宜相談しながら進められる体制
- プロダクトマネージャー、デザイナー
- 普段の開発と同じ
概要 / タイムライン
ここからは担当施策のぼかした実体験をベースにしつつ、時系列をなぞる形で学びを見ていきます。
※ 
: 前編（本記事）／
: 後編
-
0ヶ月目：プロジェクトにジョイン
-
学び：「施策をやる理由」の目線をPdMと合わせ、自分の言葉で話せるようにする
-
-
1ヶ月目：まずは計画を立てる
-
学び：リスクからプロジェクト全体の進め方を「設計」する
-
- 2-3ヶ月目：要件定義・設計
-
学び：As-Is/To-Beを言語化して、そのギャップを埋めるように開発項目を考える
-
- 4ヶ月目：実装前半
-
学び：適切なメンバーに、適切な内容を、適切な粒度で、定期的にレポーティングする
-
- 5ヶ月目：実装後半
-
学び：早く出せることは価値である
-
- 6ヶ月目：テスト・リリース
0ヶ月目：プロジェクトにジョイン
メッセージ機能開発の開発メンバーとしてアサインされました。LINEのような体験の機能としてなんとなくイメージは持てています。これまでの担当施策より規模が大きい開発で、開発の全体像はまだ見えていない状態です。
分かるけど、分からない
メッセージ機能は以前より社内・顧客から要望の声があったのは知っているので、この機能があると良さそうなことは分かります。競合サービスでもよく見る体験ですし、あると良いイメージは十分持てています。
ただ、この機能を作ることで最も解決したい課題は何か？がはっきり見えていません。「なぜ作るのか？」の理由に対して即答できない状態です。PdMが見えている「事業的にこの機能を作りたい理由」が見えていない気がします。
咀嚼して、自分の言葉でPdMと認識をすり合わせる
「課題」と「解決手段（メッセージ機能）」の繋がりをPdMのビジネス検討資料を読み込んだり、自分で業務フローのAs-Is/To-Beを書き起こして解釈していきます。
| As-Is | To-Be |
|---|---|
 |
 |
- 現在、どんな課題があるのか？
- この機能が課題をどう解決するのか？
を自分なりに言語化することで、解決したい課題が腑に落ちてきました。
PdMと認識をすり合わせていく中で
- この機能が解決できる課題は複数あること
- その中で最も解決したい課題が何であるか
- その上でまず初期リリースにおいて目指したいこと
のあたりが見えてきました。
学び：「施策をやる理由」の目線をPdMと合わせ、自分の言葉で話せるようにする
これは「主体的に意思決定する」ために重要でした。
施策をやる理由は「背景課題（Why）」→「課題解決のアプローチ（What）」→「仕様（How）」の論理的な繋がりの最上段にあたります。スコープ調整・仕様の議論・実装の方向性などプロジェクト中で判断に迷う様々なシーンで、この根本的な理由が役に立ちます。「XXXを優先したいから、YYYで、....だからZZZにするほうがいい」というような論理構造のアンカーになってくれます。
またPdMと目線を合わせると書きましたが、本質的には「エンジニア自身で、課題解決のために必要なことはなにか？を考えられる」が目指すところです。個人的には「課題解決のために必要なはずだ」という自負があると、議論の中で自信を持って主張できるようになるとも感じています。
エンジニアとしてテクニカル観点を抑えることは当然大事ですが、事業側の目線も持って考えることで、議論がリードしやすくなる気がします。
1ヶ月目：まずは計画を立てる
課題と施策の関係性が腑に落ちたので、開発に入っていけそうです。この後、皆さんならまず何から着手するでしょうか？自分なら早速要件定義や設計に入ろうと考えてしまいますが、受けたアドバイスは「網羅的にプロジェクトの概要から入ろう」でした。
プロジェクトに関わる情報を集約する
まずはプロジェクトの概要をドキュメントでまとめることにしました。しかし自分には網羅的に概要から入るイメージが湧かず、アウトラインとなる目次を先輩に引いてもらいました。「背景課題は何か（Why）」「プロジェクト上の関係者（Who）」「タイムライン（When）」のように大体5W1Hに沿った目次で整理していきます。
また資料の管理方針もここで考えておきます。過去、プロジェクト後半でドキュメントが散乱して、置き場所が分かなくなって困ることが何度もありました。同じ思いはしたくないので、これまで出てきた資料や今後まとめる資料の置き場所も決めておきました。
プロジェクト中のリスクを減らすように進め方を考える
自分が情報をまとめている裏側で、先輩が「プロジェクトを進める上でのリスク」のリストアップをしてくれました。
- 情報が分散するリスク
- 仕様が決まらず開発に着手できないリスク
- 要件に対して実装が漏れているリスク
- 脆弱性があるリスク
など。
先輩曰く、「プロジェクト中のリスクを把握し、『いつ、そのリスクに対処するのか？』の計画を作っておくのが重要」とのことです。例えば先程の「資料の置き場所を決める」は「情報が分散するリスク」の対処にあたります。
同様に対処したいリスクが何かと、どういう進め方で先手を打つかを議論して決めていきました。例えば「仕様が決まらないリスク」に対しては「仕様を決めきってから開発ではなく動くものを見せて仕様を固めていく」など。
大きな開発ほど失敗するリスクは大きくなりますが、同時に進め方を工夫する余地も大きくなるようです。普段の開発でも同様に工夫する余地はあるはずですが、初めて気付いた視点でした。
学び：リスクからプロジェクト全体の進め方を「設計」する
これはプロジェクトを成功させるために1番重要な部分でした。
当たり前ですが、プロジェクトは失敗しなければ成功します。失敗するかもしれないリスクのケアが成功の鍵です。大きな問題なくリリースを迎えられたのは、失敗するリスクの芽を摘んだ計画段階にあったと思います。
またリスクに入念な準備をしたことで、それでも気付けなかった想定外の経験は、悔しさからか脳内に刻み込まれました。
リスクを考えることは、プロジェクトの成功にも、この経験を次のプロジェクトに活かすためにも重要だと感じました。
一方で「〇〇の理由で失敗するかもしれない」というリスクの引き出しの多さや精度は、経験に依存するとも思いました。実際、今回のプロジェクト計画のアウトラインやリスクのリストアップは先輩2人にかなり頼っています。分からない部分は頼ったり、頼られたりすることが重要かもと思います。
これは「プロジェクト進行前に全てのリスクに対応すべき」ではなく、「『いつ、そのリスクに対処するのか？』の計画を作っておくのが重要」という話です。
入念な準備は重要ですし、全てのリスクに対処してからプロジェクトに入れるのが理想ですが、時間は有限でリスク対応にも工数がかかります。リスク対応に時間をかけすぎて開発に着手できず、早くリリースできないこともリスクの1つです。
それにより大きな問題が起こるリスクは早めに対処すべきですが、「最悪、問題が起きても対応できる」とか「リリースまでに対処してればいい」などのリスクは後回しで構いません。プロジェクトを通して、大きな問題が起こらないようにコントロールできていればOKです。
一旦おわります
長くなったので一旦この記事はここで切り上げ、要件定義以降の話は後編の記事で触れていきます。
LITALICO Engineers Advent Calendar 2024は明日も4本の記事が公開予定です。
- シリーズ1 @R-Tsukada さん
- シリーズ2 @takmon さん
- シリーズ3 @nonikeno さん
- シリーズ4 @R-Tsukada さん
賑やかですね 
お楽しみに！