2023年の dinii Feature team
はじめに
dinii のエンジニアチームには、Feature team と呼ばれるチームがあります。
Feature team の役割は、プロダクト開発そのものとなります。
それをより生産性高く実施するためには、開発としてまとめるには広い期待値があるように感じています。
世間一般的な Feature team に関する説明はこれらが詳しいかと思います。
なぜ Feature team を立ち上げたか
Feature team 自体の dinii における成り立ち自体は、こちらをご覧ください
dinii では、早期から多くのプロダクトを作る必要があったため、このタイミングでの Feature team / Platform team を立ち上げるました。
最初からプロダクトを複数つくるために、多くの技術基盤投資が必要となり、結果として Platform team を明確化する必要性でたため、逆算的に Feature team が出来ました。
そのため、フルサイクルでエンジニアリングしたい、ではなく、Platform team を立ち上げたい、が先行し、結果として Feature team が立ち上がりました。
そのため、dinii における Feature team は、旧ワンチーム時代の価値観を引き継いでいるチームと言えます。
旧ワンチーム時代
dinii のプロダクトは、飲食ドメインのプロダクトであり、このような特徴があります。
レガシー領域のため、オペレーション理解が重要
ただ便利なツールを入れました、では価値提供に繋がらない。点の機能提供ではなく、オペレーションの流れを汲んだ価値提供が必要。
日常に近いドメインのため、理解はしやすい一方、自明ではない
飲食ドメインは、知ればイメージはしやすいですが、飲食店のオペレーションや構造、温度感は自明なものではなく、多くのインプットや調査が必要です。
インフラシステム
POS システムという、飲食店のインフラとなるサービスを担っているため、サービストラブルだけでなく、意図しない仕様不備によっても顧客に甚大な影響を及ぼしうる。
マルチプロダクトかつ、全てのプロダクトが連動
飲食店内のオペレーションを全て支えているため、プロダクトの数が多く、一連のオペレーションの中で複数のプロダクトが連続的に使用される。
そのため、複数のプロダクトの理解を前提とした開発が基本。
そのため、開発観点ではフルスタックであることが望ましく、かつ顧客課題やオペレーションの理解度も高く求められます。
このあたりの技術選定関連は、こちらもご覧ください。
当時の Feature team を立ち上げる以前の dinii の開発メンバーは、肌でこれらを感じ取り、日々適応し、行動していたように思います。
特に立ち上げ期においては、実際に飲食店に足を運ぶのはもちろんですが、飲食店の現場で開発・リリース・フィードバック・改善リリース、なども、エンジニア自身がよくやっていました。
当時はまだサービス規模が小さく、リリースリスクが相対的に小さいため、思い切ったリリースがしやすかったことは前提としてあります。一方で当時のエンジニアたちの立ち回り、価値観のようなものが、今も引き継がれていることは事実あると思います。
そのため、Feature team 立ち上げ以前を知っているメンバーからすると、暗黙的にこの感覚を共有しており、開発業務を越境することのハードルがかなり低いように思います。
一方、Feature team が立ち上がった後にジョインしたメンバーからすると、この背景が異なっているため、どこまで踏み込んで良いのか迷うケースが増えてきたと思います。
また、当時とは規模も状況も異なるため、過去と同じ行動が最適とも限らず、古参メンバーのアンラーニングも求められていくでしょう。
dinii の Feature team
そのため、改めて dinii の Feature team のメンバーとして期待したい指針を言語化していこうと思いました。
ソフトウェアエンジニアは、プロダクトそのものに手を入れることができる唯一の立場です。
エンジニア以外は、デザイナーであってもプロダクトマネージャーであっても営業部長であっても、ひいては代表取締役であっても、プロダクトそのものに手を入れることはできません。
一方、エンジニアは全員、それが出来ます。
そのため、プロダクトを直接変更することができるエンジニア自身が、市場や顧客ニーズを理解し、プロダクトとして何が求められているのかを理解していれば、最短最速で最良のプロダクトを生み出すことができるはずです。
これは、言い換えると「自分が欲しい物を作っている」状態だと考えます。
エンジニアであれば誰しも経験はあると思いますが、特に自分が欲しいものを自分で作っているときは、「完成品 <> 実装 <> 設計」が個人の中でノータイムで繋がっていて、圧倒的な生産性でアウトカムを生み出せていると思います。そして何より楽しいです(これが一番重要)。
仕事としてのプロダクトづくりにおいては、自分が顧客当事者でないことも多いと思いますが、顧客解像度や顧客とのシンクロ率を高めることで「自分が欲しい物を作っている」状態に近づく事はできると思います。
事業ドメインによっては顧客解像度が得づらいこともあると思いますが、dinii が取り組んでいる飲食ドメインでは、飲食店に行くだけで自分自身もいちユーザーとなれますし、また店舗内オペレーションに関してもすぐに見に行ける、飲食店の従業員の方に話を聞ける距離感です。だからこそ、解像度にこだわれると考えています。
「自分が欲しい物を作っている状態」の背景には、広い意味でのエンジニアリング志向があります。
エンジニアリングとは、技術の社会適用であり、単に実装する、ではなく、社会に対して価値提供するものだと考えています。
そのため、顧客を起点として、課題発見、要件定義、実装、デリバリー、改善、その他の一連の、顧客への価値提供プロセスを指していると考えています。
一方、技術設計を含む実装工程は、ソフトウェアエンジニアという職能の人にしかできない知的生産活動でもあります。
そのため、実装工程以外の部分に時間を投下しすぎて、結果実装時間が全然ない状態は、本末転倒と考えています。
翻って、幅広い開発プロセスの理解、顧客・課題解像度の維持、知的生産に充てる時間、をそれぞれ捻出できるタイムマネジメント、セルフマネジメント力が求められると言えます。
さらに、顧客課題を的確に解決しつつ、継続的に価値提供するための、適切な技術判断ができる必要もあります(負債を減らす、保守性を保つ、顧客オペレーションを守る)。
まとめると、Feature team に対する現時点での行動期待値はこのようになっていると思います。
広い意味での「エンジニアリング」ができるチーム
エンジニアリング = 技術の社会適用。実装する、でなく、価値提供する。
よりよいエンジニアリングをするためには、「自分が欲しい物を作っている状態」が理想的。
顧客解像度を上げながら日々開発をするためのセルフマネジメント
技術設計を含む実装工程は、ソフトウェアエンジニアという職能の人にしかできない知的生産活動であり、「実装時間が全然ない」は、本末転倒なので、よしとしない。
翻って、幅広い開発プロセスの理解、顧客・課題解像度の維持、知的生産に充てる時間、をそれぞれ捻出できるタイムマネジメント、セルフマネジメント力が求められる。
顧客課題を解決する打ち手を的確に実装に落とし込める技術力
顧客課題を一次情報で理解している方が、早く良いものが生み出せる(自分が欲しいものを作っている状態が理想的)。
それを実現するための実装において、どういう手段があるかは幅広く選択出来る方が良い。
求めすぎではないか問題
Feature team エンジニアに対する期待値の話をすると、求めすぎではないか問題に直面します。
要するにプロダクトマネジメントしつつ、ソフトウェアエンジニアをしてくれ、とも取られかねないと思います。
また、必ずしも全員が顧客とのシンクロ率を等しく上げられるとも限りません。
実現難易度は高いと思いますが、その可能性をできるだけ引き上げるための技術選定、チーム構成でもって dinii はこれをバックアップしたいと考えています。
まず、Platform team が強力に技術基盤や開発生産性をバックアップしてくれています。Feature team の開発生産性、開発者体験を底上げするための多くの打ち手を講じてくれています。
次に、ビジネスチームからの支援が厚いです。日々顧客と接しているビジネスチームメンバーからは、日々大量の顧客の声(良い声も悪い声も)を熱量高く伝えてくれます。
そして、顧客との距離を縮めやすいドメインであることです。
実際に、我々のクライアント企業の役員・代表クラスの方と、直接エンジニアが会話できる機会が毎週レベルであります。
エンジニアメンバーが、顧客企業の役員レベルの方々と日常的に壁打ちできるサービスはそうそうないと思います。
このチーム体制とドメインの特性をフル活用することで、Feature team 期待値は十分実現できると思っています。
逆に、この実現が困難であれば、可能な限り実現できる組織体制、技術投資、など、Feature team を取り巻く周辺の環境の方を最適化していきたいと考えています。
それぐらいに、Feature team のエンジニアが、「自分が欲しい物を作る」状態に持っていけていることを重視したいと思っています。
顧客解像度を高めるための Tips
解像度を上げる一般論的な部分では、このあたりの資料があります。
一方で、顧客解像度を高めるための活動、そのためのユーザーヒアリングやドメイン知識の座学的な学習は、それだけでかなり大変で、また人によって向き不向きは正直あると思います。
息を吸うようにユーザーヒアリングやインサイト抽出が出来る人もいますが、全員がそうとは限りません。
また、一次情報をとってはみたものの、これがどう実務に活かせるのか、と思うことも多いと思います。
その場合は、一次情報の理解度を高めることに気をつけてみると良いと思います。
一次情報の理解度を高めるためには、得意な人に頼るのが良いです。
もう一歩踏み込んで、解像度を高めるスペシャリストにガイドを頼ることがオススメです。つまり、一次情報を取ることに加えて、スペシャリストの解釈を知る、ことです。
例
・カスタマーサポートチームの問い合わせ履歴を見る
→ さらに、その担当をしたカスタマーサポートのメンバーに、「その問い合わせを受けてどうだったか、何が根本課題だったのか」を聞く
・商談に同席する
→ さらに、その商談の準備として何をしたのか、どういう仮説をもっていたのか、商談を実際にしてみて予想通りだったことは何か、予想外だったことがなにかを聞く
商談議事録に目を通す
→ さらに、その議事録を書いた人に ….
カスタマーサクセスチームの成功事例に目を通す
→ さらに、その担当者から….
リリースされた機能のメトリクスを自分で見てみる、クエリを書いてみる。
→ さらに、実際にその機能をヘビーユースしていると思われる顧客の、社内担当に、なぜそのような状況なのかを聞いてみる。
まとめ
飲食ドメインという身近な環境をフル活用して、今後もよりよいプロダクトづくりを実現していきたいと思います。