はじめに

※この記事は、2025 Speee Advent Calendar9日目の記事です。昨日の記事はこちら

　こんにちは！Speeeでイエウールという自社サービスのWebサービスの開発をしている、木俣と申します。周囲からはきまっちゃんと呼ばれています！

　私は2023年にSpeeeに入社しました。当時、エンジニアとして「課題を特定し解決まで導く力」が自分に足りないと感じ、それを身につけられる環境を求めて入社しました。そこから3年目になり、生成AIの普及によってコーディング速度は格段に上がりました。しかし、それ以上にユーザーのニーズや事業環境の変化も激しくなっています。

　現在のイエウールの現場は、AIで開発を効率化しても追いつかないほど求められる機能が多く、すべてを開発していたら変化に取り残されてしまうのが「事実」です。だからこそ、私たちは「言われたものをただ作る」のではなく、「目的を理解し、最も筋が良い手段は何か」を考え抜くことに挑戦し続けています。この記事では、そんな変化の激しい環境の中で、私たちがどのように曖昧なビジネス課題に向き合い、AIでは代替できない「解決する力」を磨いているのか、直近の実体験をもとにお話しします。

プロジェクトの特性に合わせて「エンジニアの関わり方」を変える

　イエウール事業部は、事業責任者を筆頭に、マーケター、営業、Ops（社内オペレーションチーム）など、多様な専門性を持つメンバーで構成されています。

そのため、私たちエンジニアのもとには、それぞれの立場から日々多種多様な依頼が飛び込んできます。

マーケター：「ユーザーの声を拾うために、アンケート機能を実装したい」
社内オペレーションチーム：「オペレーションが煩雑なので、業務生産性を改善したい」
事業責任者：「事業戦略を立てるための、分析ツールが必要だ」

と依頼の内容も分野もバラバラです。これらを曖昧なまま進めないためには、「解決したい課題（スコープ）に対して、具体的に何を開発するのか」という要件定義のプロセスにおいて、どこにどれだけコスト（時間と頭脳）を割くか、私たちエンジニアが見極める必要があります。

　例えば、「ユーザー向け機能」であれば、日々ユーザー行動を分析しているマーケターが一番詳しいはずなので、ある程度要件を固めてもらったほうがスムーズです。逆に、「新規事業や戦略ツール」のような誰も正解を知らない領域なら、全員で手探りで要件を決めていく必要があります。そして、今回取り上げる「業務効率化」に関しては、「毎日コードや仕様を読んでいるエンジニア」こそが、複雑な現状を最も正しく把握しているケースが多々あります。

　このように、「誰が一番その領域に詳しいか」という背景を理解し、プロジェクトの特性に応じて「成果が最大になる立ち回り」を変えること。これがイエウールの開発におけるこだわりです。また、これだけ多くのステークホルダーがいる環境で、なぜスピード感を持ってプロジェクトを進行できるのか。その原理については、こちらの記事で詳しく取り上げられているので、併せてご覧ください。 tech.speee.jp

※1 事業をもっと速く大きく推進するための巻き込みとカルチャー浸透より引用

「課題への解像度」が、届けられる価値を2倍にする

　ここからは、エンジニアが目的の言語化から深くコミットし、大きな手応えを感じた「業務効率化」の実例についてお話しします。

　ある日、ビジネスチームから相談が来ました。「特定のデータを更新するフローを自動化したい。来月の繁忙期に間に合わせたい。つまり納期は1ヶ月後。ここを逃すと、事業計画に穴が空く」要求を整理すると、以下の通りでした。

今手動で入力しているデータをすべて自動入力にしたい。
一部のデータは重要なので、紙面での保存（印刷）も必要である。

これを真正面から受け止めて実装しようとすると、最低でも2ヶ月はかかりそうです。それでは納期に間に合わず、繁忙期の機会損失が発生してしまいます。つまり、「機能は完成したが、事業価値（タイミング）は失った」という本末転倒な状態です。

「何のために？」を突き詰める

　こういった場合、私たちは必ず「ビジネス要件＝この機能で本当に解決したい課題は何か？」を徹底的に明らかにします。単に「フローを自動化したい」という言葉だけを受け取ると、「全部の工程を自動化する」以外の選択肢は見えません。しかし、「何のために？」が明確になれば、やるべきことを一気に減らせる可能性があります。

　とはいえ、イエウールは10年以上続いているサービスです。それぞれの業務プロセスにも「10年分の背景」が積み重なっています。エンジニアは「コードの構造」は把握していても、「現場でそれがどう運用されているか」までは分かりません。逆に、そこが分からないままでは、ビジネスチームからの要望が本当に正しいのかも判断がつきません。

　そこで私たちのチームでは、関係者を巻き込んで「今のオペレーション」を可視化し、どこにどれくらいの時間がかかっているか、繁忙期にはどのくらい時間が足りなくなるのかをすり合わせました。具体的には、以下の図のようにフローを書き出し、関係者との認識の齟齬をなくし、ボトルネックを議論していきます。

結果：スコープ半減、価値は2倍

　この図をもとに、「結局どこがボトルネックで、何をどこまで短くすればゴールなのか」を議論した結果、以下の事実が見えてきました。

来月の繁忙期を乗り切るには、特定の業務フローを「月8時間分」削減できればよい。
その中で最も時間がかかっているのは「工程A」であり、ここは必ず自動化が必要。
一方で、「紙の印刷」は繁忙期以外のタイミングでまとめて行っても問題ない（今やる必要はない）。

ここまで分解できたことで、論点は絞られ、開発すべきスコープは半分になりました。工数が半分になれば、1ヶ月という短い納期でも余裕を持ってリリースできます。要望の核となる価値は100%提供しつつ、空いたリソースでさらに他の人の要望も叶えることができるようになりました。結果として、「同じ時間で提供できる価値を2倍にした」と言える手応えを得ることができました。

「理解」の領域の広さが、事業を動かす

　一つの要望に対して目的からこだわることで、大きな成果が出せました。しかし、ここまでこだわっても、まだイエウールの開発チームには課題が残っています。それは、関わる領域の広さです。

　イエウールの開発には多種多様な依頼が飛び込んできます。依頼を出す側からすれば、自分の施策こそが最も重要で、一刻も早くリリースしてほしいと願うのは当然です。しかし、すべての要望を言われた通りの期限で開発することは物理的に不可能です。常にリソースが逼迫しているからこそ、私たちは改めて施策の「目的」に立ち返ります。

この施策は、具体的にどの「課題」を解決するのか？
この開発によって、いくらの「事業価値」が生まれるのか？
このプロジェクトは、「いつ」のタイミングで検証できればよいのか？

　これら（Why）が明確になれば、単なる先着順ではなく、「事業にとって一番インパクトがある順」に開発を並べ替えることができます。例えば、優先度の高い施策を最速で出しつつ、他の要望については「検証機能だけを先行して出す」「フェーズを分けて段階的にリリースする」といった柔軟なパズルを組むことで、全体としての成果を最大化できるようになるのです。

　イエウールでは、このようにエンジニアが主導して「開発すべきもの」を議論します。自身の工夫や判断が事業成果に直結する感覚は、「言われたものを作るだけ」の開発では決して得られない経験です。実際に私たちのチームでは、以下の図のように「どのタイミングで、どの価値をユーザーに届けるか」を綿密に管理し、それが事業部にとって最適解になっているか日夜議論しています。ただコードを書くのではなく、事業を動かすための「最適な一手」を打ち続ける。それがイエウールのエンジニアリングです。

まとめ

　生成AIの登場によって、コーディング速度は飛躍的に上がりました。しかし、どれだけAIが進化しても、「目の前に広がる大量の課題」を、事業が目指している方向と矛盾なく解決できる人材の需要は尽きることはありません。むしろ、作るスピードが上がった今だからこそ、「何を作るべきか」を意思決定する機会は増しています。

　正解の見えない曖昧な課題に対し、徹底的に理解を深め、自分の頭で考え抜く。そうやって正面から事業成果に向き合うことで、エンジニアとしてできることも、仕事の面白さも何倍にも膨らませることができるはずです。