※この記事は、2024 Speee Advent Calendar 10日目の記事です。
昨日の記事はこちら
はじめに
リフォームDX事業部でヌリカエ・リフォスムなど複数のプロダクト開発に携わっている黒須と申します。
入社から2年間は、不動産DX事業のイエウールでSEO・LPO・オペレーション開発などを担当していました。
現在は PjM・スクラムマスターとして４レーンの開発を統括しつつ、自らも開発 Issue を持ちながら業務に取り組んでいます。
この記事では、エンジニアとして主体的に事業へ貢献するために私が心がけていることをご紹介します。
学生やエンジニア未経験の方には少し難しい内容かもしれませんが、Speeeのエンジニアがどのように事業と向き合い、貢献を目指しているかが伝われば幸いです。
実際の例も書いているので、すごい・詳しく知りたい、などと思ってもらえると嬉しく思います。
「主体的な事業貢献」って？
主体的に事業に貢献している状態を、私は以下のように捉えています。
- PJTや施策の目的を理解し、事業へのインパクトを明確化できている状態
- 事業戦略から逆算した計画を立て、実現可能性を高める工夫と実行ができている状態
一方で、主体的ではない例はこんなところでしょうか。
- PJTを完遂しても施策の妥当性を検討せず、ただ開発を進めている状態
- 見積もりと実績が乖離しても、「見積もりが甘かった」で終わり、改善策を考えない状態
前者は順調にリリースできたとしても成果に繋がらないリスクがあり、後者は開発スケジュールの継続的な遅延に繋がります。
逆算的に目標を立てる
満たせている状態が分かっても、実際なにをすればいいの？という状態だと思います。
ここで陥りがちなパターンは、現状の延長線上で努力し続けるということです。
たとえば「ベロシティを1.5倍にする」という目標を掲げているケースで、品質を犠牲にしたり休日返上でコードを書いたりして目標を達成しても、事業成果に繋がらないことは容易に想像できます。
よって、今までやってきたことに対して積み上げ的にできることを増やしていくのではなく、目標から逆算的にやるべきことを決めていく必要があります。
そのためにはまず、自分の目標が事業とどう結びついているかを整理しましょう。
先程の例であれば「1.5倍の施策量をリリースすること」なのか、「1.5倍の売上を出すこと」なのか、それとも「同じ施策量を少人数で実現すること」なのかを明確にすることで、進むべき道が見えてきます。
自分が引くべきレバーを明確にする
Biz メンバーと会話して「1.5倍の施策量」をリリースすることが戦略上必要であることが分かったとします。
このとき、制約条件がないと、リファクタリング・開発フロー見直し・体制変更・採用・etc. とやれそうなことがたくさん出てきて、やるべきことがシャープになりません。
現状の課題と論理的に実現できそうな水準を整理して、自分が引けるレバーが複数あってもあえて引かずに制約条件とすることで、工夫できるポイントがたくさん出てきます。
今回の例で「開発体制や人数を変えない」という制約条件を引くと、リファクタリングと開発フローの見直しに注力するという方向性を定めることができ、その中での工夫ポイントを見出すことに集中できるようになります。
Speee での実例
実際、過去に私がどんな制約条件を設定して、何を行ったかを紹介します。
① フロントエンドで架電先を選定する React ベースのアプリケーションを、バックエンドで架電先を選定+架電するためにリファクタリングしたケース
架電システムを改善していくPJTでは、架電先を選定するロジックを React 側からバックエンド側に寄せることが勝ち筋でした。
当時の私はReactの経験が乏しく、既存のリッチなアプリケーションを移行する方針が見えない状況でした。
しかも React のバージョンが16系で、メンテするには最新のベストプラクティスとの差分が大きすぎました。
そこで私は「既存コードを別ディレクトリにコピペし、基本的に削除しか行わない」「React の勉強はしない」という制約条件を設けました。
(プロダクトやPJTの状況、今後のプロダクトの方針を踏まえた上での意思決定なので、一般的な正解ではありません)
結果的にリファクタリングは迅速に進み、リリースしたい頻度通りに施策をリリースすることができて、PJTとして大きな成果を収めました。
② 外注で3人月かかっていたフロントエンドのABテスト開発を、新卒メンバーが0.5人月で実現可能な仕組みにしたケース
それまで外注で行っていた開発を2年目の私と1年目の新卒メンバーの2人で開発するPJTで、外注している開発を内製化できたらその分だけ成果になるPJTでした。
最初の数回は後輩と一緒に施策を実装していましたが、「自分は施策の開発をしない」という制約条件を課し、開発の障壁になっていることを一つ一つ取り除いていきました。
詳細は省きますが、毎週のようにインパクトが大きい問題を定義して、解決するサイクルを繰り返しました。
- ABテストをパス・ファイル単位ではなく if 文で行えるようにする
- 多重コールバックネストによって実行されているコードを手続き型で呼び出せるようにする
- Stg にデプロイする前に挙動を確認するための仕組みを導入する
- デプロイ時間を4分の1にする
- プランナーの要件定義力を向上させるためのサポートを行う
- 動作確認手順を爆速にするためのブックマークレットを作成する
↑ は一例ですが、新卒メンバーの努力も相まって、結果的に1人あたりの生産性を6倍にすることができました。
この考え方は一般的らしい
制約条件を設定することで、問題を別の視点で捉え直す「リフレーミング」が可能になり、創造性が高まることは一般的に知られているようです。
最初のステップ
とはいえ、何を制約条件として、何に注力するのかを決めるのは難しいテーマだと思います。
そういった方は、まずはこれらの手順を踏んでみると良いと思います。
- 自分が実装している施策が事業にどんなインパクトをもたらしているのかを聞いてみる
- そのインパクトを実現するために掛けられるコスト (人月、期間、金額) を聞いてみる
- そこから逆算して、自分が実装している施策をそのコストで実装する場合、どうするべきかを考える
おそらく多くのエンジニアは「期間」を制約条件とするのが考えやすいと思います。
期間を制約条件とした場合、どんな工夫ができるのかを考えてみましょう。
- ~~ という方法ではなく、 ~~ という方法であれば半分の期間で同じ目的を実現できる
- ~~ という工夫をすれば、次に実装する施策は実装コストが掛からなくなる
- この施策はどう頑張ってもROIが合わないので、施策自体を見直したほうがいい
このような創造的なアイデアがたくさん生まれてくるはずです。
まとめ
人それぞれ事業への貢献モデルがあると思います。
「どんなレバーを引いて、どんな成果を生み出していきたいか」
これを能動的に考えて実行できる人が主体的に事業貢献をできている人だと思います。
Speee には、事業の成長に本気で向き合うエンジニアがたくさん在籍しているので、興味を持たれた方はぜひご応募ください！
一緒にサービス開発を推進してくれる仲間を募集しています。
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！
もちろんオープンポジション的に上記に限らず積極採用中です！
