※この記事は、2022 Speee Advent Calendar25日目の記事です。
どうもこんにちは。まさかのアドベントカレンダー2022最終日担当、デジタルトランスフォーメーション事業本部 (以下、DX事業本部)ソフトウェアエンジニアの石井です。
私はこれまでDX事業本部の中でも特にHousii (ハウシー)という事業にメインで携わり、約2年間、「エンジニアとして事業に貢献する」というテーマと向き合い続けてきました。過去にも以下のようなテーマで登壇させていただきました。
そこで今回はHousiiを通じて得た自身の学びや実際の取り組みをご紹介しつつ、
- エンジニアとして事業に貢献するとは「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である
- そのためには、Why-What-Howの接点に関わりながら、技術意思決定力を磨き続けることが重要である
というお話ができればと思います。
私のように「エンジニアとして事業に貢献したい」、「手触り感を持ってプロダクト開発に携わり、顧客に価値を届けていきたい」と考えているエンジニアの方にとって、何かしらの参考になれば幸いです。
- 事業とチーム体制のご紹介
- エンジニアの私が、事業というものをどのように捉えているか
- エンジニアとして事業に貢献するとは、「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である
- Housiiプロダクトチームでこれまでチャレンジしてきたこと
- まとめ
事業とチーム体制のご紹介
この記事では事業の詳細については触れませんが、前提として関連する事業やチームについて簡単にご紹介いたします。
Housiiについて
Housiiは、希望条件を登録して待つだけで不動産会社から希望にあった提案を受け取ることができる、完全会員制家探しサービスです。
Housiiチーム体制について
「営業、マーケティング、開発のセクションごとにチームを組成して日々事業活動を行っており、それを統括する事業責任者がいる」というスタートアップのような体制で事業開発を行っています。職種横断で定期的に事業についてディスカッションする場があるなど、職種間の距離が近いことが特徴です。
ちなみに、プロダクトマネージャー (PdM)やプロダクトマーケティングマネージャー (PMM)のような職種は各社役割が異なると思うので、SpeeeのDX事業本部ではどのような役割なのかと気になった方は以下の記事も合わせて読んでいただけると幸いです！
エンジニアの私が、事業というものをどのように捉えているか
はじめに、エンジニアである私がHousiiという事業に2年間携わる中で、事業というものを今どのように捉えているかを言語化していきます。
まず、事業を立ち上げる際には「なぜやるのか（Why）」からスタートすると思います。例えば、私の所属するDX事業本部では「リアル産業のDX」という大目標に向かって、それに紐づく事業を連続的に立ち上げています。私の所属するHousiiという事業もその中の一つです。
よって、以下のようにWhy、What、Howがすべて整合している状態を保ちながら、事業やプロダクトを成長させていく必要があると考えています。
- Why
- DX事業本部全体のVision / Mission / Value
- Housii事業のVision / Mission / Value
- Housiiプロダクトのコンセプト
- What
- プロダクトロードマップ
- 解くべきインパクトのある課題の設定
- 施策 (課題に対するソリューション)の立案
- How
- 開発 (施策のデリバリー)
- 施策を検証可能な状態にする
- 施策の検証と振り返り
- 開発 (施策のデリバリー)
これらの整合性を担保しつつ、施策 (What)によって得た学びをより大きなWhatに還元し、事業の不確実性を減らしていく (事業の解像度を上げていく)ことが重要です。
ここで着目したいのが、事業の解像度が上がる、事業のフェーズが変わるにつれて、解くべき課題 (What)やその解き方 (How)が変わっていくということです。そして、チームで「どのようにWhy-What-Howを一貫させていくか」という共通認識を持つための道標が「事業戦略」だという理解をしています。
エンジニアとして事業に貢献するとは、「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である
前述の内容を踏まえて、「エンジニアとして事業に貢献するとは何か」を考えていきます。
基本的にエンジニアは事業の中でも特にプロダクト開発にメインで関わっていくと思います (本記事で述べるプロダクトはソフトウェアを前提としております）。そして、プロダクト開発は事業のWhyを達成するために行うものなので、事業の成長や変化、事業戦略から多大な影響を受けます。
よって、エンジニアとしてプロダクト開発に従事する上で、以下のような制約条件を考慮する必要があるでしょう。
- 事業解像度が上がるほど、Why-What-Howを一貫させるための事業戦略や、プロダクトとして解くべき課題 (注力すべき施策)が変わっていく
- 事業戦略や解くべき課題 (注力すべき施策)が変わると、最適なソフトウェアのアーキテクチャが変わっていく
- コンウェイの法則に則り、同時に最適な組織アーキテクチャも変わっていく
- 施策の試行回数が積み重なるほど、ソフトウェアが複雑になり、施策を試行するための開発コストが上がっていく
- いわゆる技術的負債、そしてチーム内のコミュニケーション複雑性も増していく
そして、エンジニアはそのような制約条件下で以下のようなテーマと向き合うべきだと私は考えています。
- 常に目的思考を持って、「その施策を通じてどのような価値を提供したいのか」、「その施策を通じて、事業としてどのような学びを得たいのか」を理解した上で、最適なHowをチームで意思決定し続けること
- 事業戦略に追従しながら、大小様々な施策を試行可能なソフトウェアや組織のアーキテクチャをデザインし続けること
これらのテーマに向き合い続けることが、冒頭でも述べた「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」だと考えています。エンジニアリングの面白いポイントとも言えますね。
ただこれは言うは易し行うは難しで、非常にチャレンジングなテーマです。私自身、様々な試行錯誤の末にこのような解釈をするようになっていきました。今もまだまだ道半ばだと思っていますが…
次節では、実際にHousiiプロダクトチームで取り組んできたことをいくつかご紹介していきます。
- どのようにチームでWhy-What-Howを一貫させていくか
- どのようにチームで技術意思決定力を磨いていくか
を考えるきっかけになると幸いです。
Housiiプロダクトチームでこれまでチャレンジしてきたこと
Why-What-Howの接点を定点観測する
これまで繰り返し述べてきた通り、日々変化する事業において、チームでWhy-What-Howの一貫性を保つことが重要です。そのためには前提となる事業の情報を定期的にチームで同期し続ける必要があります。
Housiiプロダクトチームでは、立ち上げ期から開発メンバー全員が集う週次の定例MTG (スクラムのリファインメントです)の場で、PdMやPMMから以下のような情報や考察を共有してもらう取り組みを続けています。
- 施策リリース後にユーザから得られたフィードバックやKPIの変化
- それに対するPdM、PMM視点での考察
- (ある場合は) ロードマップのアップデート
- それらを踏まえて、目下取り組む施策の目的、背景、内容
前提が揃った状態で皆が議論を繰り返すことで、エンジニアメンバーも施策の目的を見失わず、目的思考で最適なHowについて考えることができます。特にHowはエンジニアの得意領域なので、「より開発コストを抑えつつ、インパクトが生み出せるソリューションの提案」はエンジニア起点で生まれることも多いです。
また副次的な効果として、エンジニアが手触り感を持ってプロダクト開発ができている状態が作り出せているとも考えています。私は「目的が不明瞭なものを依頼されること」が苦手で、共感いただけるエンジニアの方も多いのではないでしょうか。Why-Whatがぶった切られた状態でHowだけを要求されるような環境だと、事業やプロダクトに貢献しているという手触り感が得られにくいと思うんですよね。ただタスクを捌くだけになってしまいがちです。
そういった課題に対しても、施策の目的や事業・プロダクトの方向性をチームで同期し続けることが効果的だと考えています。
チームで技術意思決定力を磨いていく、徹底的言語化文化
Housiiのプロダクトチームでは「あ、今の意思決定、ドキュメントにまとめておきますね」といった会話が日常的に飛び交っています。徹底的に言語化することを大切にしています。
オーナーシップを持った優秀なメンバーが集まってくれたというのもありますが、そのような言語化文化を作りたいという私の想いもあります。理由は以下の2点です。
- 未来の開発生産性への先行投資のため
- 個々人の技術意思決定力の向上のため
未来の開発生産性への先行投資のため
「初期メンバーのみで半永久的にプロダクトを成長させていく」という戦略は、あまり現実的ではありません。やはりチームや組織も事業とともに成長、拡大、変化していくと思います。
そこで開発生産性を落とさずにチームをスケールさせていきたいわけですが、チーム内が暗黙的なルールやコードから読み解けない情報 (意思決定の背景など)に溢れかえっていると、それは難しいでしょう。新しいメンバーが早期に成功体験を積むことも困難になります。
そういった将来起こり得る組織課題をなるべく減らすために、Housiiチームでは「今なぜこの仕様にしたのか」、「今なぜこの設計にしたのか」といった仕様や設計、意思決定を徹底的に言語化し、ドキュメントに残すようにしています。
特にArchitectural Decision Records（ADR）と呼ばれる意思決定ドキュメントを残すことは大切にしていて、そういった「ソースコードには残らないが、重要な意思決定プロセス」もチームの資産として蓄積していきたいという想いから取り組んでいます。
このドキュメントを実装前に用意することで、「その時点の事業状況を踏まえて、本当に最適と言える意思決定か」を相互レビューすることができ、それがWhy-What-Howの一貫性維持にも繋がります。また、新しく入ってくれるメンバーも「当時、どのような背景でどのような課題に向き合っていたから、このような実装になっているのか」と、意思決定プロセスをトレースすることができます。そして、これは後述する「メンバーの技術意思決定力向上」にも大きく寄与していると考えています。
ちなみにADRに関しては、DX事業本部の各チームで積極的に導入が進んでいます！こちらの記事でも言及されているので、合わせて読んでみてください！
個々人の技術意思決定力向上のため
私は新卒・中途エンジニア採用にも関わっているのですが、そこで候補者の方からよくもらう悩みが「もっと設計力を伸ばしたい」です。
私はここでいう設計力とは、これまで繰り返し述べてきた「技術意思決定力」のようなものだと捉えています。「事業上の課題を将来起こり得る技術的なリスクも考慮した上で、今どう解決するかを決める力」のような理解をしています。私は10年ほどエンジニアをやっていますが、設計は未だにとても難しいですし、私自身も特に2、3年目の頃に設計力の伸び悩みを感じていました。
そういった背景もあり、私はHousiiのエンジニアメンバーや採用面談でこの悩みを相談された際に「設計や技術意思決定を言語化する習慣をつけること」を提案しています。
言語化することで思考が整理されますし、その時点で最適な技術意思決定をドキュメントに残していくことで後から振り返りが可能になります。
過去の自分の意思決定と今の意思決定を比較することで、「昔はこのような観点を持てていなかったな」といったように、エンジニア個人としても成長を実感することができると思います。そして皆に伝わるドキュメントを書くことを習慣化することで、物事を構造的に理解する力も向上していくと思います。
設計力に伸び悩みを感じている方、ぜひ小さな技術意思決定や設計の言語化から始めてみてはいかがでしょうか。
技術意思決定力を磨いて、責任を持てる時間軸を伸ばしていく
私からリード役割を引き継いでくれたメンバーも直近、プロダクトの未来を見通すということについて記事を書いてくれました。彼自身もこれまで数々の技術意思決定を積み重ね、このような大きな責任を担ってくれるようになりました。
ぜひ、こちらも合わせて読んでみてください！
まとめ
私はエンジニアの責任は「技術を使って、事業上インパクトのある課題を解決すること」だと考えています。そのためには事業を多面的に捉え、Why-What-Howが整合しているかを常にチェックしながらプロダクト開発に向き合う必要があります。
弊社には事業責任者や営業、マーケティングに精通したメンバーと近い距離で密にコミュニケーションを取りながら、本質的なプロダクト開発に取り組める環境があります。スモールチームをベースにしているので、エンジニア一人ひとりが日々、大きな技術意思決定を積み重ねてくれています。
「もっと事業に貢献したい」、「もっと設計力や技術意思決定力を磨きたい」という方、ぜひ気軽にお話しましょう！
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
※この記事は、2022 Speee Advent Calendar25日目の記事です。昨日の記事はこちら。
