※この記事は、2025 Speee Advent Calendar 21日目の記事です。昨日の記事はこちら
はじめに
こんにちは、DX 事業本部でエンジニアをしている大金です。
エンジニアとして4年目になり、純粋な技術的意思決定の枠を超えた判断を求められる場面が増えてきました。
- 技術的負債の解消にどのくらい開発リソースを割くのが正解なのか？
- どんな人を採用するべきか？採用要件は？
- 自分を含めてメンバーのアサインをどうするべきか？
「やった方がいいこと」は無限にある。しかし、リソースと時間は有限です。
この記事では、試行錯誤を経て馴染んできた「達成プランを軸に判断する」という考え方について書きます。上記のような問いに対して、何を考え、どう向き合えばいいのか。
純粋にコードを書く以外の仕事にもどんどん役割を広げていきたい、事業を前に進めていきたいと思っているエンジニアの方にとって、少しでも助けになれば幸いです。
- はじめに
- 判断軸がないまま迷子になっていた
- すべての判断は「目標の達成プランがあるか」で決まる
- 達成プランを軸にした判断の実例
- プランは破綻する。修正し続ける
- 一人で抱え込まない、達成プランは全員で作っていくもの
- さいごに
判断軸がないまま迷子になっていた
「どれもやった方がいいけど、何をやるべき？」
この問いに明確なスタンスを持っていないと、意思を持たずに目の前のタスクを片付けてしまいます。 振り返ってみると、「このリファクタリングは確かにできたら嬉しいけど、今このタイミングで工数をかけてまでやるべきなのか」「なんとなく進捗が悪い状態は、いつまでに解消しなければならないのか」と思うことばかりでした。
要所要所で、事業の観点から本当に「良い」意思決定だったのかわからない。そんな状態に陥っていました。
問題の本質は、何をもって「良い」意思決定と言えるのか、判断の軸がなかったことでした。
そんな基準があるなら教えてくれ、と思う方もいるかもしれません。
私がたどり着いた答えは「自分で目標達成に向けた道を描けているのか？」ということでした。
すべての判断は「目標の達成プランがあるか」で決まる
さまざまな意思決定と向き合う中で気づいたことがあります。それは、達成プランがあるかどうかがすべての判断の前提になるということです。
達成プランとは、目標から逆算して「今これをやれば届く」という見通しのこと。達成プランと照らし合わせることで、今の行動が良いのか悪いのかが判断できるようになります。
達成プランを軸にした判断の実例
技術的負債、採用、メンバーアサイン——これらは一見バラバラな論点に見えますが、すべて事業目標を達成するためのパーツです。だからこそ、達成プランを軸に考えることで、点ではなく線として判断できるようになります。
簡単な例として、1年以内にリリースしたい機能群がバックログにあり、その完遂を目指すとします。この目標から逆算して、各領域では次のように考えます。
技術的負債の返済方針をどうするのか？
まず、今の手なりの開発速度で期日目標に間に合うかを確認します。
次に、枷になっている・なる可能性が高い負債がないかを洗い出します。 実際にその機能周辺に詳しいメンバーにヒアリングしたり、周辺のコードを散策したりして確認します。
そして、その負債を返済すれば想定している1年スパンでリリース予想期日が早まるかどうかで判断します。
早まるなら投資する。早まらないなら今はやらない。達成プランに照らして必要かどうかで考えます。
採用要件をどうするのか？
開発投資によって開発チームの生産総量を増やして1年間の実装を完了させることを考えているとします。
まず、今後の開発物を眺めた上で、どんな開発物が増えてきそうか？どんな機能群があるのか？それらは切り分けて別チームなどで進めることができるのか？を考えながら、何人、何チーム、といったどんなチーム体制にするべきか考えます。
そこから、どんなポジションでどうバリューを出してもらうかを考えます。
例えば、実際の自分の現場では、進捗管理などがボトルネックになる懸念はありませんでした。 それよりも、難易度の高い実装や粒度の大きい設計から実装までを品質高く行ってくれるメンバーがたくさんいた方が良さそうだと判断しました。
メンバーのアサインをどうするのか？
目標に含まれる機能の中に、不確実性の高い技術が含まれているとします。 データ調査や検証など曖昧な部分が多く、1年のうち最初の3ヶ月以内には突破しておきたい。
まず、自分とシニアメンバーの二人で1ヶ月のプロジェクトとして検証開発を切り出します。そこで不確実性を潰し、別チームが実装できる状態まで調査・技術検証を行います。
その間、自分が行っていた進捗管理の役割は一時的に他メンバーに持ってもらうよう調整します。
やることが山積みの中で、今週何をやれば達成プランを最速で進められるかを常に問い続けます。
プランは破綻する。修正し続ける
ここが一番苦しいですが、一番大切なところです。
先週「これでいける」と合意したプランが、次の週には破綻している——そんなことはよくあります。 数週間にわたり設計プロセスが遅延した、既存コードで想定外の大きいバグが発覚した、依存していたAPIが突然の廃止告知をしてきたなど...
要因は様々ですが、達成プランそのものが破綻する状況はかなり頻繁に発生します。
そうなった時、「このまま進んで問題ないか？」「達成に向けた動きになっているか？」という問いを持ち続け、泥臭くプランを修正し続ける。これが最も大切で、最も苦しいところです。
逆に、常に達成可能な状態が続いているなら、目標水準を引き上げることを検討してもいいかもしれません。
破綻したときの修正プラン
達成プランがなくなったときの打ち手は、多種多様です。 実際に自分が実務で頻繁に行った打ち手を3つほどピックアップし、具体の検討内容例も合わせて記載しました。
見ての通り、「銀の弾丸」なんてものは存在しません。 下記を検討しても達成プランが見えない場合は、素直に無理と判断し、目標自体を見直す方が良いケースも多いです。
1. 価値の総量を変えずに、開発工数を圧縮するプランを検討する
- 実装をそのまま行わず、GASなどで簡易実装しつつ一部はマニュアルオペレーションを許容することで仮説検証する
- パフォーマンスの負荷が懸念になった場合、サーバーのグレードを一時的に上げる、内製化せずに既存のSaaSを契約するなど、短期コストをかけてリリースを早める
2. 開発生産性/生産量を上げる
- 1スプリントあたりの現状の実績(5pt)と定義した理想状態(7pt)のGAPを埋める仮説を立て、妥当性を検証する
- チームの分割を行い、定期MTGを含めたコミュニケーションコストを下げることによって実装時間を物理的に上げる
- LLMを使って、一部LP修正や文言修正などを開発ではないメンバーに担ってもらう
- 単純にエンジニアを採用して人数を増やす（ただし、コミュニケーションパスが増えることや、実装の複雑性なども考慮が必要）
3. 開発計画自体を変えて、やる・やらないの判断を再び行う（ビジネスサイドに要求する）
- ビジネスプランに立ち返り、リリース済み機能の結果や再分析を踏まえて「そもそも想定するよりも成果が出ていない、筋が悪いか〇〇という機能自体不要だ」「丸々全部作る必要はない、一部だけでいいかも」「対応エリアを限定してもいいかも」といったアイデアが出てくる
- ビジネスサイドに要求を出す（干渉していく）こと自体も、目標達成において非常に大切なポイントです
破綻→修正を繰り返す泥臭い作業
「達成プランを持ち続ける」とは、非常に泥臭い作業の連続です。
- そもそも根本の事業目標とその意図、なんでこの開発を行いたいかをヒアリングし理解する
- 想定される開発の総量を見積もる（精度より、なぜその見積もりにしたかを説明できることが大切）
- ベロシティを測り、上振れ・下振れの見立てを立てる
- 関係者に妥当性を説明し、状況が変わったらまたやり直す
でも、これをやらないと何に投資すべきかわからず、優先順位がつけられず、「やった方がいい」が無限に増えていきます。
達成プランを持ち続けることが、すべての投資判断の土台になります。
一人で抱え込まない、達成プランは全員で作っていくもの
基本的には高い目標を追っているケースが多いため、「達成プランを考えろ」と言われても一人で簡単に100%描けるほど甘いものではありません。エンジニアの視点だけではなく、ビジネスサイドの分析や仮説など、さまざまな要素を総合した上での達成プランです。
達成プランを構築する上で、多くの論点と向き合う必要がありますが、一人ですべてできることではありません。チームメンバーや上司、他の職種のメンバーと一緒に考え、議論しながら構築していくものです。
フラットに可否を判断し、無理なプランは無理だと説明する。 無理だということを説明している場の議論中に、FBやジャストアイデアから「これならいけそう」というプランが生まれることもかなり多いです。 「実際に行けるプラン」へ議論しながら修正し続ける。周りにいるのはあなたを否定する人ではなく、事業を一緒に前に進める一蓮托生の仲間です。
さいごに
事業を動かすエンジニアとは、事業目標の達成プランを持ち、泥臭くプランを修正し続ける人だと私は考えています。
判断基準を持つこと自体は簡単ではありません。でも、達成プランという軸を持つことで、少なくとも「何に向き合うべきか」は見えてきます。
この記事が、同じように迷いを感じているエンジニアの方の参考になれば幸いです。
Speee では一緒にこの変革期を楽しんでくれる仲間を募集しています！
Speee では様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれた方は、こちらをチェックしてみてください。
この記事をきっかけに興味を持っていただけたら嬉しいです！
