※この記事は、2024 Speee Advent Calendar21日目の記事です。 昨日の記事はこちら tech.speee.jp
自己紹介
初めまして、23新卒エンジニアの真保です。
学生の頃はCGの研究や組み込みハードウェア開発を行なっており、
web開発は未経験で入社しました。
サマーインターンにおいて「ユーザのどんな課題を解決したいか？」を徹底的に深掘り、
本当に価値あるプロダクトを作ることに強くこだわるカルチャー共感し入社を決めました。
現在では、事業責任者と開発戦略について話したり、
数年後の事業の行先を見据えながらアーキテクチャの意思決定をしたりしています。
この記事について
入社1年目からHousiiという新規事業のプロダクト開発に携わる中で
ユーザの本当の困りごとを見つけ、プロダクトを通して解決策を提供する。
ということに向き合い続けてきました。
「真のユーザ課題を見極める」という事業的な不確実性しかない面白いフェーズに関わる中で、
事業を預かるエンジニアとして大事にしている価値観を言語化してみようという内容です。
読者自身が携わっているプロダクトを想像しながら読めるよう、Housii特有の内容は省きました。
他の新規事業に関わるエンジニアの方にも共感いただける部分があるのではないかなと思います。
新規事業に関わるPMなどにも「エンジニアってこういうことを気にしていたんだ」という、
相互理解のきっかけの一つになると嬉しいです。
Housiiの事業ステージ
Housiiは家を購入したい人と不動産会社のマッチングプラットフォームです。
「家の購入」という人生でそう何度もない体験において、購入に至るまでに幾つもの壁があります。
自分の条件にあう物件を探し、出会い、購入に至るまでのプロセスにおいて、
- そもそもどんな壁が立ちはだかるのか
- 何が原因でそれらの困りごとが発生するのか
- そのユーザ課題を本質的に解く上で、どんな難しい点があるのか(なぜ未解決課題なのか)
- どうやってその難所を突破するのか
こんなことを考えながらプロダクト開発を通してユーザ課題に向き合い続けています。
Speeeのミッションに紐づく開発思想
Speeeでは「解き尽くす。未来を引きよせる。」というミッションを掲げています。
我々が解こうとしているのは未解決の社会課題であり、それ故に対峙する社会課題は
「こうすれば解ける」という正解がまだ確立されていません。
プロダクトを通じたユーザの行動データからユーザの課題を推測することが多く、
「答えは市場に取りに行く」という考え方を大切にしています。
以前、私の先輩が分かりやすい例えをしていたので引用すると
患者さんに「たぶん風邪だと思います」と言われたとしても、
医者はそれだけで風邪と断定はしない。
症状についてヒアリングしつつ自身で診断し、使うべき薬や治療法を決定するはず。
我々が顧客に「こういう機能作って下さい」と言われる状況もそれと同じで、
あくまで問題やペインを聞いてプロダクトをどうするべきかは
こちらが課題定義し、判断するべきだと思います。
ヒアリングから治療法の決定(仮説立て → 機能開発 → データ収集 → 分析)のサイクルを高速で回し、
ユーザ課題の解像度を上げ続けることが未解決の課題に対峙する上で大切な考え方だと思っています。
機能をリリースして分析してみると、昨日まで最重要と思っていたことが実は見立てが異なっていて、
今日は重要ではなくなっていることも少なくはありません。
今週は極めて重要だったことが、翌週にはどうでも良くなることだってある。立てた計画に疑問を抱くことなく、ただ従ってちゃダメだ。大きな変化が起きたときに、その衝撃に耐えられなくなる。(引用元 : アジャイルサムライ)
勝ち筋が決まっていない新規事業開発におけるエンジニアの腕の見せ所はどこにあるのだろうか？
と、前置きはここまでで、以下が本編です。
1. ビジネスサイドの人と同じ目線で事業目標を追う
以下の2,3,4の土台となるのがこの部分である。
事業の向かう方向性を見通すことで、より長い時間軸を考慮した意思決定ができるようになる。
- そもそも自分達はプロダクトを通してどんなユーザ課題を解決したいのか
- 半年後(イメージしにくい場合は3ヶ月後)に、ユーザはどんな体験を届けられているべきか
2. どこを丁寧に作り、どこを捨てやすく作るかを見極める
基本的な方針として「コア機能」(プロダクトの拡張の軸となるメイン機能など)は丁寧に作り、
「仮説を確かめる」ための機能はなるべく捨てやすく作ることを意識している。
コア機能
多くの開発者が頻繁に触るので、見通しの良さは開発速度や変更失敗*1などに大きな影響を与える。
その機能は長く残るので、技術的な意思決定は長い時間影響を与え続ける。
プロダクトの主機能であり、触れるユーザ数も多いため非機能要件の水準も高くなりやすい。
- Housiiでは加盟不動産会社とユーザのチャット機能をコア機能とおいている
- 例えば通常のテキストメッセージ送付とPDFファイル送付を同じ処理とみなして設計するか？
- 今後メッセージ種別を増やしやすい設計になっているか？など
「仮説を確かめる」ための機能
既存機能に入り込むように作るのが手っ取り早く、
それによりリリースを早めることが可能なケースは少なくない。
リリースしてみたら仮説が正しくなかったことが分かり、いざその機能は捨てようとなったときに、
コア機能などに深く根を張っていると、捨てるための工数の大きさ故に捨てることを断念し、
価値を提供できない機能が負債として蓄積されることにつながってしまう。
捨てやすく作るためには、モジュール性を意識して設計したり、
既存機能を継承して既存機能とは独立して作ったり。
技術的な意思決定においては、
ある機能の作り方を考えるにあたり、事業フェーズを考慮すると何が重要なのか。
選択肢からの決定によって生じるデメリットをどのように受け止めるか。
を考えるのが重要だと思っている。そして、「何が重要か」を判断するには、
1で述べた「事業が向かいたい方向」を捉えることが不可欠である。
意思決定については、実践でもすぐに参考となるこちらの記事を是非ご一読いただきたい。
3. リリースした機能が価値を生んでいるかを点検し続ける
どれだけエレガントな設計で開発を行えたとしても、既存のコードに追加する形で開発すると、
アプリケーションコード全体の複雑度はどうしても高くなる。
複雑度が上がるということは、修正時の影響範囲が広がることなので、
開発スピードが遅くなる(=ユーザへの価値提供が遅くなる)ことを意味する。
そのため、アプリケーションコード全体の複雑度を下げ続けるために
価値を届けられていない機能はプロダクトから取り除く不断の努力が求められる。
この取り組みを行うには「リリースした機能が価値を届けられているか」の判断が求められる。
ユーザが直面している問題の根本原因をデータなどから推察して仮説立てし、
その仮説が正しかったかどうかを、機能リリースによって解決できたかを確認すること。
私は機能リリースの目的を上記のように認識している。
仮説が正しいかどうかを確かめるには「この機能によって、この数値がこのくらい伸びるはず」と
機能に期待する効果を前もって定義しておくことが欠かせない。
ソフトウェアを扱うプロとしてプロダクトコードの保守性に責任を持つために、
リリースした機能が価値を届けられているかをエンジニアも見続けることが重要である。
4. 点検結果を評価し、対応期日を切る
例えば、以下のようなケース。
リリースした新機能がユーザ価値を大きくもたらし、主要なKPIがグッと伸びたとする。
この機能は捨てやすいように、かつリリースを早めるためにある程度雑に作られたが、
ユーザに大きな価値を提供できるので、機能として残したかったり、あるいは今後拡張したい。
しかし、雑に作ってしまっているので保守容易性に乏しかったりする。
「保守容易性を上げるためにリファクタリングを」とも考えられるが、ここで一度立ち止まりたい。
(特に新規事業の)プロダクト開発において「やった方がいいこと」は数えきれないほどある。
それら全てに対処すると、新しい価値を創出するための時間を取れず、事業を推進できない。
こんなときには「今やることによって事業にどう影響を与えるか？」と考えるようにしている。
- 複雑な実装だから、リファクタを後回しにすると仕様理解から始めることになり、同じ対応でも工数が大きくなる。仕様を理解している今のうちにやることで、工数が大きく変わる。では今やるべきだ。
- 今回作ったテーブル/モデルはどちらもコア機能に対して独立しているから、ここの内部の複雑度が他の開発に対して与える負の影響はなさそうだ。今後1,2ヶ月ほどこの機能を触ることもないので、今リファクタリングに時間をかけるよりも、この先リリースしたい機能開発に集中した方が事業上の不確実性は減らせそうだ。では今やるべきものではないな。
その結果「今ではない」と判断したら、「いつ対応すべきか」を切ることを意識している。
※ この「いつ」とは○月×日のような具体的な日付ではなく、状況であることが重要である。
(「このモデルを触るとき」「CV数が○○件を超えたら」など)
見方を変えると「ここで対応しないとまずい」というラインを引き、
そのときまでは意図的に負債を抱えるという意思決定を明示的に行うことである。
上記はあくまで一例だが、重要なのは「事業の前進を最大化できる意思決定とは何か」と、
常に事業目標から逆算することだと思っている。
最後に
- 「仮説立て→機能開発→市場に答えを取りに行き→分析→次の仮説立て」の連続
- このサイクルを高速で回し続け、ユーザ課題をスピード感を持って更新し続けることが最重要
- 事業の未来を見据えてプロダクトに責任を持つと、自然とエンジニアも数字を見に行く
今回は技術を扱うプロとして新規事業開発を加速させるために意識していることをまとめました。
簡単に解決可能な社会課題は既に解かれており、未解決課題が未解決なのは難所があるからです。
裏を返せば、未解決ゆえにそれを解くことには大きな意義があるはずです。
そういった困難な課題に立ち向かうにあたり、本記事が突破の一助となれば大変嬉しく思います。
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています。
新卒の方はこちらより本選考に申し込みが可能です。
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます。
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれた方は、こちらをチェックしてみてください。もちろんオープンポジション的に上記に限らず積極採用中です。一緒に未解決課題に立ち向かっていきましょう。
*1:デプロイによって本番環境で障害が発生する割合
