こんにちは。ニーリーのCTOの三宅（@katzhide）です。
先日、YOUTRUST社主催の大規模カンファレンス「プロダクトヒストリーカンファレンス2024」が開催され、ニーリーはスポンサーとして、LayerXさん(のVPoE 髙橋さん)と「事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談」というタイトルで登壇をさせていただきました！当日ご来場いただいた方、オンライン視聴をしていただいた方、ありがとうございました。
トーク主体のセッションだったので、モデレーターをやってくれた菊地さん（@_tinoji）がセッションの書き起こしレポートを書いてくれています。長いのですが、盛況のセッションだったようなので、ぜひ読んでください！！
セッション当日はその場で質問を受け付けて回答するパートを用意しました。質問が集まらなかったらどうしようとビビってたのですが、まさかの20個を超える質問をいただきまして感謝しかないです。当日は3つしか回答できなかったので、この記事で全部の質問に対して回答させていただきます！！ 当日のセッションで回答させてもらったものもあるのですが、じっくりと考える時間もできたので、改めて回答させていただきます！こちらも長文になってしまったので、興味がある質問だけでも読んでいってください！
※似たような質問は集約して回答させていただいています。
質問の一覧
開発組織に関連する質問
- Q1_事業サイドに染み出すカルチャー醸成はどうやっているのか
- Q2_人材採用について、どう取り組んでいる？
- Q3_エンジニアが事業に染み出す組織におけるPdMの役割って何？
- Q4_開発組織のデザイナーの位置付けはどうなっている？
開発プロセスに関連する質問
- Q5_エンジニアはどうやって開発内容や優先順位を判断していた？
- Q6_初期開発における開発優先順位はどう決めていた？
- Q7_プロダクトバックログの粒度ってどんな感じ？
- Q8_ユーザーリサーチはやっている？
- Q9_施策の効果測定は誰がやっているの？
- Q10_トイル対応は誰が担当しているの？
オフショア開発に関連する質問
その他の質問
質問への回答
Q1_事業サイドに染み出すカルチャー醸成はどうやっているのか
エンジニアがドメイン知識をつけて提案していく、はまさに理想系だなと思うのですが、そのようなマインドへ持って行ったマネジメント術を教えていただきたいです。
事業サイドに染み出すカルチャー/プロセスを定着させるために実施されてきたことはありますか？
改めてじっくり考えると大きく４つあるのかなと考えています。
- カルチャーをみんなで言語化する
- 言い続ける
- 採用で絶対に譲らないポイントにする
- 背中で語る・行動で示す
1. カルチャーをみんなで言語化する
ニーリーではプロダクト組織のカルチャーをCTOがトップダウンで決めるのではなく、主要メンバーと一緒に考えて言語化しました。また、言語化の最初のブレストはあえてCTO抜きでやっています。
詳細はこちらのnoteに書いてありますので是非読んでみてください。
カルチャーを作っていく上で中心となるメンバーと一緒に考えることで、納得感や愛着を持てるようになり、カルチャー浸透にも効果があったと思っています。
2.言い続ける
とにかくことある毎に言い続けました！ プロヒス当日は「染み出す」をいい過ぎたんじゃないかなと若干反省してるくらい習慣化しています。カルチャーを体現した人を賞賛するとか色々と方法はあると思いますが、とにかく繰り返し言い続ける地道な活動は大事だと思います。
3.採用で絶対に譲らないポイントにする
カルチャーに良い悪いや正解はありません。そして、カルチャーはいい方向に変えるのは大変ですが、悪い方向に変わっていくのはすごく早いので、採用時のカルチャーマッチは本当に大事にしています。どんなに優秀な人でもカルチャーが合わない場合は採用しないようにしています。
今は、「事業に染み出す開発組織」というカルチャーを大事にしてるので、技術をいい意味で手段として捉えて、事業創造や事業グロースをエンジニアが能動的にやっていきたいと思える人を大事にしています。今後も組織は拡大していき、多様性も高まっていくとは思いますが、この「事業に染み出す開発組織」カルチャーはぶれないようにしたいと思っています。
4.背中で語る・行動で示す
口でいうだけでは浸透は難しいです。言っている人間が誰よりも率先して体現していくことで、言葉に説得力が増すし、みんながついて来てくれると信じています。
Q2_人材採用について、どう取り組んでいる？
事業が爆速に成長していく中で、人材確保は必要かと思います。どんな人材を採用しているのでしょうか。また、新卒採用などは考えているのでしょうか？
事業に染み出したエンジニアがいるとベストなのは理解ですが、一方でそういう人材の採用が難しいと思っていて、その辺りどの様に取り組んでいたのでしょうか。
一定レベルの技術力やパーソナルスキルを見た上で、大事にしてるのは２つです。
- 「事業に染み出す開発組織」をはじめとしたニーリーのカルチャーにフィットしているか
- ドメイン知識を深掘りしていける思考力と好奇心があるかどうか
1. 「事業に染み出す開発組織」をはじめとしたニーリーのカルチャーにフィットしているか
事業で染み出す開発組織であることをアピールするために、開発者向けカンパニーデックやnoteなどで情報発信していますが、カジュ面を含む選考過程でも必ず強調して伝えるようにしています。
2. ドメイン知識を深掘りしていける思考力と好奇心があるかどうか
私は、ドメイン知識は「業界知識」、「業務知識」、「サービス知識」、「プロダクト知識」と４層あると考えています。この全ての層でエンジニアが解像度を上げられるかで開発スピードが大きく変わってくる（特にVertical SaaSだと）と思っているので、大事にしています。 不動産やモビリティ領域への経験や関心は重視していないですが、ドメインを深く掘り下げた経験やそれを実現するための思考力や好奇心の高さについては選考で重視しています。
採用が難しいのはそうなのですが、ハードルは下げず、諦めずに頑張り続けています。とにかくそういう志向性の人を集めることが大事だと思うので、もっと発信を頑張っていきたいと思っています。
インターン生から入社してくれてるケースはあるのですが、新卒採用はまさにこれからチャレンジしようと思っています！
Q3_エンジニアが事業に染み出す組織におけるPdMの役割って何？
エンジニアが事業やユーザーの解像度を高く持ち、ビジネスサイドとの連携も取れている状態で、PdMには何を求めますか？あるいは、PdMはいつ必要になりますか？
両社ともにエンジニアが要件定義や作るものを決めるという役割を担っているとのお話しでしたが、そうなった場合、PdMの実際の役割やバリューの出し方はどのようになっていたのでしょうか？
ちょうど1人目PdMの阿部さんがドンピシャのブログを書いてくれているのでこちらもみてください！
確かに、エンジニアが事業に染み出すとPdMと被る部分が出てきます。なので、PdMにはもっと事業に染み出そうという話をしています。PdMの方には、採用過程でニーリーが考えるPdM像や期待役割、業務などは必ず伝えるようにしているのですが、そこでは、以下のようなことを伝えています。
伝えていることの抜粋
- 理想とするPdM像はmini-CEO
- ミッションは「顧客・マーケットに向き合い、プロダクトを通じて、価値提供を創造し続けること」
- つまり、特定領域における「事業PL／主要KPI」へのコミットを期待する
- エンジニアがプロダクト企画やデリバリーマネジメントをするので、PdMはそれもやるけど、もっと事業に染み出すよ。具体的にはサービス企画やオペレーション企画もやるよ。
PdMがジョインしてくれたのは今年なので、ローンチしてから4年後ですね。 それまで、というか今もCEOとCTOがプロダクトを結構見てるので、PdMジョインは比較的後でも大丈夫でしたが、正直このタイミングは遅かったですね。もっと早く採用すべきでした（笑
タイミングはいつがいいかというのは、事業やプロダクトの特性、組織のケーパビリティによります。事業を伸ばすための課題を解決する上で、必要な人材がPdMだとなった時がタイミングだと思います。
Vertical SaaSは初期から必要な機能が盛りだくさん、かつ明確な課題が多い傾向があると思っています。なので、比較的PdMが後ろでもいいのかなと。ただ、エンジニアがクライアントやユーザーに直接話を聞くなど一次情報にあたれるかどうかにも依存しますね。
Q4_開発組織のデザイナーの位置付けはどうなっている？
デザインの話があまり出ませんでしたが、デザイナーはどこで入るのでしょう
デザイナーもPdMもエンジニアもみんなプロダクト組織のメンバーで、主にグロースチーム（所謂ストリームアラインドなチーム）に所属しています。 PdMが起点となって開発の案件が始まることが多いですが、デザインが必要かどうか関係なく、開発内容は一緒に議論をしており、デイリースクラムにも参加していたりもします。
ただ、今はフルコミットのデザイナーは1名しかおらず、コーポレートやマーケといったプロダクトデザイン以外のこともやっています。なので全ての開発案件に入りきれていないのが実情です。もっと仲間を増やして、PdMと一緒にインタビューやディスカバリーなど、抽象度が高い状況からプロダクトデザインに取り組んでいきたいです。
Q5_エンジニアはどうやって開発内容や優先順位を判断していた？
プロダクト作成に対して、エンジニアの判断がうまくはまったことによってうまくいったと言うことですが、判断基準は個々人の主観から判断を入れて行ったのでしょうか？またはドメイン知識を習得させたPdMチックなメンバーを数名立てて判断をしていったのでしょうか？
プロダクト責任者としてCEO・CTOのどちらかがエンジニアと議論しつつ、やるやらのジャッジをしていました。どちらも営業やCSなどの組織責任者を兼任していてユーザーへの解像度が高かったので、その座組が最適でした。
アウトカムを定量化して効果を見据えるというようなことはやっていませんでしたが、常にそれをやることで何が解決できるのか、得られるものは何なのか、事業KPIにインパクトはあるのか？を問い続けて判断はしていました。
今後はPdMがその役割のメインを担っていくことが多くなると思います。ただPdMが決めるというルールを設けるつもりはなく、いいモノを作る上で最適なフォーメーションでやることを大事にしたいので、今後もエンジニアが決めるケースも全然あると思います。
Q6_初期開発における開発優先順位はどう決めていた？
初期のアイデアの優先順位づけはどうやりましたか？(何を以ってやる、と決めた？)
立ち上げ当初はいかに導入社数（在庫）を増やすかが重要だったのですが、営業に苦労していました。なので、まずは導入いただくために必要な機能を優先して開発していましたね。その機能を開発すれば何社導入できる見立てになるのか、みたいな。
例えば、契約の解約機能や更新機能が必要になるのは、そもそも契約が発生して一定期間後なので、それまでに開発すればいい。とにかく今導入してくれるかどうかの決め手となる機能を優先して開発していました。意外とすぐに契約の解約が発生して、めちゃくちゃ焦って解約機能を作ることになったのはいい思い出ですね。
また、初期ローンチ時は決済手段としてクレジットカードと銀行振込の2つを提供しようとして、ほぼ開発も終わっていたのですが、銀行振込はあえて機能を塞いだりしましたね。 とにかく、初期は導入社数を増やすことが大事だったので、あえて機能を絞って必要な開発に注力するようにしていました。
Q7_プロダクトバックログの粒度ってどんな感じ？
プロダクトバックログを溜めまくってさばく、をしていたときに、プロダクトバックログの粒度はどの程度細かく記載をしていましたか？荒れている状態の場合、割と具体的に書かないと齟齬が広がる印象だったため気になりました。
これは、テーマ②「立ち上げ期x失敗談」の、約1年間かけてお金関連のドメインを作り直したエピソードへの質問ですね。 この作り直しの目的はリアーキテクチャすることで開発しやすくすることも当然あるのですが、1番の目的は、請求・送金・決済・会計処理などお金に関する機能開発が困難だった状況の解消でした。 データモデルが辛く、開発スピードが遅いというより、そもそも開発がしづらく、何をやるにしても工数が大きくなってしまう状況でした。
お金関連の開発は難易度が高く、品質保証もしっかりとやらないといけないので大変です。そこで、どうせ大きな開発を沢山するなら、そもそもコアな部分から作り直し、機能開発をしやすくした上で、まとめて多数の新機能を開発することを選択しました。
コアな部分から作り直しをする予定だったこと、お金関連の機能は影響範囲が広くなりがちなこともあり、各種要望はまとめて整理してプロダクトに落とし込みをするつもりでした。なので、プロダクトバックログは、流れてしまわないことだけ注意して、粒度は気にせず、ラベルをつけておいてひたすら起票して溜めていました。 通常は開発案件ごとにバックログを起票して、PRDを書いて開発を回しているので、全然やり方は違っていますね。ウォーターフォールプロジェクトのイメージに近いですね。
ちなみに通常の開発においてのプロダクトバックログの粒度については、納得いく解を出せてないです（汗
Q8_ユーザーリサーチはやっている？
企画を組む際に事前にユーザーリサーチ等は行っていますか？
必ずやるというわけではなく、ケースバイケースでやっていますね。 大きな案件だったり解像度がまだ上がりきっていない場合はしっかりとリサーチしますが、エンジニアが一次情報にあたれていて、やるべきことが明確にイメージできている場合は、改めてリサーチをするよりクイックに開発して、早くフィードバックを受けるようにしていますね。
Q9_施策の効果測定は誰がやっているの？
リリース後の効果測定もエンジニアが行っていますか？また、ABテストなどの施策もエンジニアで決めていますか？
PdMが不在の時代はエンジニアが、今はPdMやエンジニア含めてストリームアラインドなグロースチームみんなでやってますね。 また、データ収集や分析にはAnalyticsチームも支援してくれます。
Q10_トイル対応は誰が担当しているの？
パッチを当てて時間を稼いでるうちに営業をして、という運用で回避するような策を打つ時、運用回避するエンジニアは機能を開発する人と同じ人がなるのでしょうか？もしくは運用エンジニアとして分ける？
同じ人がやるようにしていますね。 運用専属の人がいる方が効率はいいと思います。ただ、運用やるのって大変だし、何より楽しくないことが多いので。
また、運用をやることで、どういう機能を作ればいいのか解像度を上げるきっかけにもなるので、メリットもあるかなと。 とはいえ、失敗談でお話しした通り、事業が伸びるとトイルの作業時間も伸びて、トイルに追われる日々になってしまった時代があるので、トイルを撲滅するために期間を限定して分担するとかメリハリをつけるとかはありかもしれません。
Q11_オフショア開発先の選定方法は？
オフショア開発の依頼先の選定は何を基準に行いましたか？また、依頼先とのリードタイムは問題になりませんでしたか？
参考にならなくて申し訳ないのですが、受託開発をやっていた時に何度か一緒に仕事をしたことがあった会社にお願いをしました。すでに実績があったので他社比較とかはしてないですね。 付き合いがあった会社なので、リードタイムや対応スピードは色々と協力いただいたのでその辺も問題にはなりませんでした。
安物買いの銭失いって言葉があるようにコストも大事ですが、時間やいいモノを作れるかはもっと大事なので、信頼できる会社を選ぶのが大事かなと思います。
Q12_オフショア開発は本当に辛くなかった？
オフショアの作成したものを内製化に切り替えた時、中身を見た時に、初めから自分たちで作っておけばよかった、、、といった作りにはなっていませんでしたか？
オフショア開発したシステムが負債になったりはしませんでしたか？
失敗談の通り、辛みはありましたし、任せ過ぎたのは反省だったなと思ってます。 ただ、オフショアにお願いしたことで、限られた資金、リソース、時間の中で戦えて事業をしっかりとグロースできたので、大変なことはあった（今もあります）けど、1ミリも後悔はないですね。
なので、「負債」と思ったこともあまりないですし、自分達で作っておけば良かったともあまり思ったことはないですね。
仮にエンジニアが豊富で初期から内製選んでいたからといって、辛みを全部回避できたかというとそうでもないのかなと。やってみないとわからないことは多かったですし、時間的制約（早くリリースする）で開発のアプローチも理想ではない選択をすることもあったと思います。将来を過剰に予測するより、とにかく早く世の中に出してフィードバックを受ける、それを高速で変化させていけることが大事かなと思います。どこまでやるかは判断難しいですが、迷ったら作らないを選んだ方がいいのではないかなと思ってます。とにかく事業が成長していないと、困る状況にもなれないので（汗）。
Q13_管理画面のSaaSは何を使っている？
フロントエンドのSaaSはなにを使用したのでしょうか？
管理画面のフロントは何のSaaSを使ってますか？
BaseMachina（ベースマキナ）さんですね。
Park Direct本体の管理画面は独自開発しているのですが、周辺領域のサブシステム的な部分で色々と活用しています。
ニーリーには、サクセスエンジニアリングチームという、Park Directのアプリケーション以外の全ての領域をスクラッチだけではなくローコード・ノーコードツールを駆使して開発するチームがあるのですが、そこがメインで使っています。 例えば、オートコールシステムや一括メール送信サービス、トイル作業などで活用しています。
Q14_エンジニアの時間の可視化はどうしている？
エンジニアリングの工数を可視化すべきとありましたが、どのような仕組みで可視化していますか？
エンジニアの時間の可視化に関して、どのような手法で可視化をされましたか？
開発以外で一定の時間を占めていそうな作業を見るという方針でやっています。 今、継続して可視化しているのは、以下の2つです。
- トイル（本番作業）
- ビジネスサイドからの問い合わせ対応
タイミングによっては、会議やエラー対応なども見ていました。
チームによっては作業種別ごとに時間を集計して振り返りをするなど、さらに工夫してるところもありました。
データを見るのが好きなのでついつい細かく計測したくなってしまうのですが、厳格に測ると大変なので、課題を解決するために必要最低限な可視化になるように気をつけています。具体的には、トイルや問い合わせ対応はチケットで管理し、作業種別ごとの概算時間 x チケット数でざっくり計算しており、1つ1つの実際の作業時間までは計測・収集していないですね。
Q15_辛い時はどうやって乗り越えた？
失敗した時メンタルがやられることはありませんでしたか？もしあればどう乗り越えたか教えていただきたいです。
成功するまでやり続ければ失敗じゃない、と思って頑張り続けてます！
おわりに
一緒に登壇してくださったLayerXの高橋さん、素晴らしいイベントを開催してくださったYOUTRUSTさん、本当にありがとうございます！大規模カンファレンスに登壇するのは初めてだったのでめちゃめちゃ緊張しましたが、それ以上にすごい楽しかったです！
後日、今回のスポンサーを提案した人事のメンバーからニーリー公式noteの方に、感想などなどを投稿する予定ですので、そちらもお楽しみに！
