※この記事は、2024 Speee Advent Calendar4日目の記事です。 昨日の記事はこちら
こんにちは。22卒エンジニアの長谷川と申します。現在は、デジタルトランスフォーメーション事業本部にてイエウールというサービスのアプリケーション開発業務とインフラ業務を担当しております。
この記事では、現在従事している既存事業の開発にて自分がよく陥いる「依頼されたものを開発するだけ」の状態からの脱却について試行錯誤していることを書いていきます。「エンジニアが事業貢献するって具体的にどういうことだろう」と疑問に感じている方に、1つのサンプルを提供できれば幸いです。
既存事業の開発について
まず、現在従事している開発について、簡単に紹介します。
イエウールは、売却を検討している不動産オーナーと、不動産仲介会社をマッチングさせる不動産売却一括査定のWebサービスです。 イエウールの開発では、新規プロダクトを開発する新規プロダクトチームと、既存のプロダクトをグロースさせていく既存プロダクトチームがあり、私は既存の開発を担当しております。
既存チームで担当していることは
- ユーザーに新しい価値提供をするために仮説検証を行いながら既存プロダクトに新規機能追加を行う開発
- 内部オペレーションの生産性を向上するための開発
- システムの基本品質を上げて開発パフォーマンスを向上させるための開発
- ...
等の開発に加えて、「〇〇率の改善PJT」「一部オペレーションの大規模改修PJT」などの一時的に立ち上げるPJTを含み、多岐にわたったものになっています。
既存事業の開発で起こりがちな状態
このような、いろいろな領域から全く別の開発依頼を受け、また依頼主も固定化されない、という状況に対して、依頼を受けてただ開発するだけの受注開発のようになってしまうことが多いです。（正直、既存新規関わらずな話だと思いますが）
そうなってしまうと、
- 依頼された内容を開発したが、これがユーザー価値にどう繋がっているかわからない、、
- 目的はなんとなくわかるけど、あまりにも開発するべき内容が多いな、、本当にこれ全部やる必要あるのかな、、
- 全部開発終わったけど、全然事業成果出ていない、、なんでやったんだろう。
のようになり、開発体験としても悪いですし、何より依頼主やPJTの企画者しか事業貢献のレバーを持っておらず、開発としてできたことで本来事業成果につながったはずのものが小さくなってしまっています。
このような状況に陥らないように、どのように事業貢献していくのか。それを Speee の開発で大切にしている Why-What-How に沿ってまとめていきます。
＊Speee における Why-What-How はこちらの記事に詳しいです。
「依頼されたものを開発するだけ」からの脱却
目的を明確にする
とにかくまずはPJTの目的を明確にします。 なぜそれをやるのか、それをやることによってどのようなアウトカムが生まれるのか、を企画者にひたすら聞きながら、自分でも解釈を深めていきます。話すことが目的ではありませんが、理解できるまでひたすら聞き自分でもアウトプットします。
ここで重視していることは、
- あくまで長い時間軸の目的とセットで、PJTの目的を明確にする
- 可能な限りドメインの理解度を深める
- 目先の速度も重視する
の三点です。
あくまで長い時間軸の目的とセットで、PJTの目的を明確にする
PJTが1~2ヶ月程度で終わるものだとしても、半年・一年後にどのような状態にしたいのか、そのためにどのような開発をしていくのかを把握しにいきます。
- イエウールというサービスがどのような状態になるためなのか
- どのような事業上の数値を追いかけており、それはいつまでにどれくらいの数値になっているべきなのか
- ユーザーがどのような状態になっているためのものか
などの観点です。
うまく咀嚼できない場合は、素直にあまり目的を理解できていないことや、整理したいということを企画した方に伝えさせてもらいながら、明確化を進めていきます。
可能な限りドメインの理解度を深める
一時的なPJTだと、2~3年開発をしているメンバーでも知らない機能の改修や、ほとんど知らないビジネス領域・バリューチェーンでの問題がテーマとして挙がります。 もちろん、既にコードとして実装している箇所でもあるので、実装を始めてしまえばなんやかんやとPJTは進みます。ただ、そのフェーズまで来てしまうと「一緒に要件を考える」といったことをできない状態になってしまうため、可能な限り早いタイミングでドメインの理解度を深めます。
理解を深めるため、過去のIssueや実装をひたすら読んだり資料が残っていればそれを読むのですが、それに加えて、企画者に対してビジネスプロセスを構造化をリクエストしたり、簡単な資料をリクエストさせてもらうなど、開発だけで閉じない行動もしながら理解を進めています。もちろん自分たちでも作成します。
例えば、構造化した結果、こういったフロー図や、シーケンス図などがアウトプットとして出ます。 理解できるだけでなく、こういった図があればPJTとしても構造化しながら会話ができるので、抽象的な単語だけで会話しているが実は認識がずれている、みたいなことも防げます。
目先の速度も重視する
特に重要な点ですが、 目的の明確化やドメインの理解はとても重要な一方で、ここに時間をかけすぎて開発が1ヶ月遅れました、、のようになってしまうと本末転倒なので、あくまで目先のスピードは落とさないようにします。 ときには割り切って進めた方が、結局事業成果につながるな、と判断できればそちらで進めます。
どうやって達成するかの戦略・勝ち筋を理解する
目的だけではなく、それをどうやって達成させるのかについても、聞いたり意見を伝えながら明確にしていきます。 特に、「いつまでにどうなっている必要があるか」のマイルストーンについては、丁寧に認識をすり合わせます。
マイルストーンの要素としては以下のようなものです。
- タイミング（いついつまでに）
- 事業成果（〇〇％、〇〇件）
- ユーザー体験（ユーザーがこういうことができる）
- PJTとしてはこういう状態（e.g. 〇〇が完成している、リリースできる状態になっている）
PJTによっては、明確にプロダクトロードマップのようなものをひける場合もあれば、開発のウェイトが少なく別部署のウェイトが高かったり、いろいろな不確実性からマイルストーンを綺麗にひけない、などなど色々なシチュエーションがあります。
ただ、どのようなPJTでも「どうやって達成しようとしているか」「いつまでにどうなっていたいか」を把握し、それに対して開発観点で何ができそうかを積極的に伝えていきます。
戦略に沿った適切な開発サイクル・体制を決め、リリースまで持っていく
戦略に対して、すぐに実装を始めるのではなく、どうやったら小さい工数で大きな成果を早く出せるか、を詰めていきます。
例えば、イエウールの既存開発ではC向けの開発がありますが、C向けの開発では「データを取りながら毎日・毎週仮説検証を回す」ことが勝ち筋になることが多いです。
この戦略ならば、
- いついつまでにどこまで持っていくために
- どのような仮説を検証する必要があって
- そのために何回施策を打って
- 仮説を検証するために必要な母数はどれくらいで
- その母数ならば最短⚪︎日で施策のサイクルを回せて
- 開発は1施策あたりどれくらいの工数で実装可能で
- じゃあいつまでに開発要件が決まっていている必要があって
- どんなデータがあれば要件を固められるのか
などを決めて、実際にどのように開発を進めていくのかを決めていきます。
このように、要件が上がってきたらリリースするのではなくて、どのタイミングでどのように要件があるべきかをこちらからも考え、意見を伝えながらPJT全体のQCDを高める方法を一緒に考えていきます。
終わりに
既存事業で「依頼されたものを開発するだけ」にならずに事業貢献をしていくために試行錯誤していることについて、自分なりの考え方と一例を書いてみました。
この記事を書いてみて、改めてですが、開発だけでこれらのことをできるわけではなく、PJTを企画しているメンバーなどの開発以外のチームとの協力体制をどうやって築いていくかの重要性を感じます。 そして、その協力体制は「開発のため」という目的ではなく、「事業全体のため」「ユーザーや不動産業界のため」という目的を共有しているからこそ作っていけるのだと思いました。
また、Speeeでは一緒にサービス開発を推進してくれる仲間を募集しています。 エンジニアとして事業を作っていくことに興味がある方、一緒に働きましょう。
新卒の方の本選考申込はこちら。
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます。
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください。もちろんオープンポジション的に上記に限らず積極採用中です！
