この記事はCAMPFIRE Advent Calender 2023の22日目の記事です🎉
こんにちはmatinanaです。
今日のテーマはエンジニアが事業とユーザー価値に向き合う挑戦をしている話です。
事業理解をどう深めていくのか、開発と事業部の繋がりをどう担保するのか、スクラムでのユーザー価値の追求など、今年トライしてきたことをお話できればと考えています。
ですが折角のアドベントカレンダーなので、まずは寄り道をして、突然ですがmatinanaという名前の由来を話しますね。笑
matinanaって？
matinanaという名称は、荻窪にあるタウンセブンというスーパーから取ってきています。
タウンセブン→町七→matinanaです。
十年以上前の学生時代、僕はタウンセブンで毎日ダンスの練習をしていました。（見回りの警備員さん、いつも怪我するなよと声をかけてくれてありがとうございました。）
指導者も先輩もいない中、まだ数が少なかったインターネット上のブレイクダンスの動画を参考にして、自問自答と体中にアザを作りながら試行錯誤の毎日でした。
ネットを通して過去の偉人達からの学びを得て、自分で「こうやるとよいのかな？」という仮説を立てて、とりあえずトライをして、失敗しながらも撮っておいた動画をもとに検証を行い、また次の仮説をもとにトライをして改善をしていく。
今思えば毎日やっているプロダクト開発と同じプロセスを踏んでいた、そんな自分のクリエイティブの原点がタウンセブンなので、この場所の名前を使いたいなと思ってつけたのがmatinanaというアカウント名になります。
ユーザー価値とは
さて、エンジニアが事業とユーザー価値に向き合う。
事業は、プロダクトを通して提供しているサービスですよね。
ではユーザー価値とは？
日々プロダクト開発をしているエンジニアからすると、「ユーザー価値に向き合う」というのは当たり前のことと捉える方が多いかと思います。
では、今作っている機能のユーザー価値が何かをすぐに答えられますか？
それを紐解くためにユーザー価値に関しての面白かった体験を書きますね。
インセプションデッキで気づかされるユーザー価値
僕たちのチームでは、Epicと呼ばれる大きめの開発に着手するときに施策における共通認識を作るためにインセプションデッキを行うようにしています。
いつもはPdM/デザイナー/エンジニアだけのプロダクトチームでインセプションデッキを行っていたのですが、CAMPFIRE for Entertainment のサービス開発に向けたインセプションデッキではエンターテイメントのクラウドファンディングを行うプロジェクトオーナーさんと日々やり取りを行っているエンタメチームの方にも参加頂くことにしました。
エンタメチームの方はインセプションデッキが初めてで、基本的にはプロダクトチームがファシリテーションを進めながら進行をしていました。
一番最初の項目「我々はなぜここにいるのか？」は、施策に取り込む背景や目的の認識をあわせるための項目です。
プロダクト側としても、事業に寄り添った考えを持ち、下記のような項目をプロダクト主体で洗い出していました。
- P/Lへのポジティブインパクト
- テールプロジェクトの増加による興味層の拡大
- 強豪に対抗していくための戦略
こういった事業的なインパクトを出しきって次の項目に行こうとなった時に、あまりエンタメチームの声を聞けてないなと思ったので「CAMPFIREのミッションの文脈ではなぜこの施策をやるべきでしょうか？」とエンタメチームに投げかけてみました。
その返答は、「クラウドファンディングプロジェクトのオーナーさんに渡る資金が増えることで、資金集めに使う時間を減らせ、よりオーナーさんがクリエイティブに使う時間を増やすことが出来るからです」というユーザー価値ど真ん中の話が出てきました。
プロダクトチームが出していたことは、ユーザー価値ではなくて、事業インパクトだったんですよね。
もちろん施策の背景や目的を出すのがこの項目なので間違ってはいないのですが、この言葉を聞いて、プロダクトチームも「よし、やろうぜ！」とよりチームがまとまった気がします。
ユーザーに日々向き合っている人の本質的な想いの声は、作り手のサービスへの向き合い方を変えてくれるのだなと改めて思った瞬間でした。
ということで、エモい話しは一旦このあたりにして、この記事ではエンジニアとして、チームとして、事業とユーザー価値に向き合うためにやってきた挑戦をいくつか紹介させて頂きます。
この記事が、明日からのサービス開発でもっと事業とユーザー価値に向き合う一助になれば嬉しいです。
個人としての向き合い
まずはチームではなく、個人として向き合ってきたことを振り返ってみます。
事業への理解を深めていく
もちろん以前から事業やユーザー価値に対して考えることはありました。
しかし、それを強く意識し始めたのは今年の後半になってプロジェクトオーナー（PO）さんの領域のEMになり、PO領域の毎週の事業推進定例に出るようになってからでした。
事業推進定例では、この半年で追うべき値としてPOさんの初回申請率と申請承認率の２つを目標値に持っていました。
ユーザー価値を計る方法としては、インタビューやアンケートなどの定性指標と、数値に落とし込んで考える定量指標の２つの切り口があります。
定性的な指標も大切ですが、それらの結果が定量指標に反映されていきますし、より継続的にウォッチしやすいものも定量指標の方なので一旦は前述の定量指標を目標に置いていました。
毎週上下する指標をもとにプロダクト側と、POさんと日々やりとりをしているCS側の両面で課題や解決案を話していく中で、想定以上にCS側の要因が指標に影響が大きいことが分かってきました。
（ちょうどタイムリーな似たような話として先日アプリマーケティング研究所がつぶやいていたツイートがありますね）
プロダクト開発だけでサービスが回っているわけではないので、よく考えれば当然あることなのですが、やれAIで作成を簡単に、やれステップを小さくすることで負担を減らす、と単眼的にプロダクトでの解決を軸に考えていた自分としては改めて面白い発見になりました。
この体験をもとに、プロダクトチームに閉じていないで、もっと広い視野で事業を見れるようにしようという意識が高まりました。
事業理解への近道は事業に関わる人との距離を縮めることだと決めた
人を理解せずに、開発と事業指標をどう紐付ければよいのかな？と考えていたのですが、数値では文化や流れが作れないと気づいて、まずはプロダクトチーム以外の人との連携をしっかりしようと考えました。
巻き込んでくれる人がいた
どこから始めよう？と悩む間もなく、CPOがひたすら事業!
課題やそこに向き合う人へ巻き込んでくれました。
事業部の方で情報を整えてもらって、それに対してプロダクト側の意見を落とすのではなく、事業部と一緒にやろうの精神じゃないと駄目なんだと気付かされました。
少しずつ巻き込まれるようになった
MTGで事業部の方と話す時に課題の共有や協力の申し出をするようにしてきたら、自然と色々な人から巻き込まれるようになってきた。
- 日々の業務フローを共有して貰えたり
- CS課題について話すMTGに呼んで貰えたり
エンジニアが事業に歩み寄るだけでなく、エンジニアにも歩み寄ってもらえるようにしようと思った
エンジニアへの身近さを感じて貰うために従業員代表に
縁もあって、従業員代表というものになった。
なったから何かを出来るわけではないと思っていましたが、エンジニアが何らかの形で組織の見える場所に立つことはエンジニアにとっても、組織のフェイズ的にも一抹でも意味があることになりそうだと思いました。
実現したいことは何度でも言い続けるをキーワードに、信任のアンケートを問う場で開発での機能改善だけでなく、他部署との連携を強めてbiz x devの両軸での改善を呼びかけるように宣伝していました。笑
全社での勉強会で開発チームのフローや課題の理解を共有する機会を作った
そもそもエンジニアチームが日々どういうフローで仕事をしているかが全社に知られておらずブラックボックスになっていたので、それではbiz x devの協業や歩み寄りも難しいよな〜と、ここの解像度があげられるような発表を全社向けにすることに。
実現したいことは何度で(ry
ということで、全社でプロダクトを作っていこうを添えて。
なにかにこじつけて開発チームと全社との距離を近く出来ればと投げまくっていたw
全部署のマネージャーを集めた研修の際も、マネージャーチャンネルで、感想なんて誰も書いてない中でここぞとばかりにチャンスを見つけて開発チームと全社の繋がりが少しでも推進するようにアピールするように意識していましたｗ
少しずつ輪が広がってきた
そうした活動の甲斐もあって（！？w）まだまだ全然多くはないですが、EMになる前はプロダクトチームに閉じていた関わりが、少しずつ広がってきています。
（このグラフは感謝を伝えられるアプリであるUniposでのお礼を言い合えた人数なので関わってる人はもっと増えているはず）
こんなふうに、関わりの範囲を広げることで事業への解像度を少しずつ高く出来るようにしてきました。
チームとしての挑戦
EMとして自身の事業への理解を深めていくのは当然の義務であります。
それは、EMの役目は
であり、組織の目標達成・成果の最大化には事業への理解は欠かせないためです。
その上で、EMが一人で事業理解を深めても開発チームとの大きな齟齬がある状態では意味がありません。
この解決の糸口は、ちょうど自分がEMになったタイミングで偶然始まったスクラムがもたらしてくれました。
個人の向き合いを触れてきたので、チームがユーザー価値・事業理解を深めていくプロセスでも自分のやってきたことを話せれば良いのですが、実際はほぼないですｗ
素晴らしいスクラムチームの仲間たちのおかげで、チームとして事業に向き合う挑戦が出来ているので、そちらも併せて紹介させてください。
バックログにユーザー価値を書く
PO領域のスクラムチームではプロダクトバックログアイテム（PBI）の種別として下記の4種を持っています。
- ユーザーストーリー
- ジョブストーリー
- バグフィックス
- スパイク
それぞれの種別の紹介は今回は避けますが、その中でユーザー価値に直接つながるユーザーストーリーの種別ではPBIにユーザー価値を記載する箇所を作っています。
記事のはじめでユーザー価値について触れましたが、機能開発一つとってもそれによって可能になることは多く存在します。
しかしそれは逆に、ユーザーが意図していない機能になり使われないものとして作られてしまう懸念も多く含んでいるということです。
これを防ぐためにも、PdM/デザイナー/エンジニアを含んだスクラムチーム全体でユーザー価値が何なのかをリファインメントの過程ですりあわせるようにしています。
ユーザー価値を上段にして話すことで、より具体の実現方法はデザイナーやエンジニアが探求することができて、PdMが仕様を考えるより複合的な解に近づくことが出来るという副産物もあります。
PBI自体はPdMだけでなく、エンジニアも作るようにしているので、すべてのユーザーストリートでユーザー価値を設定することで、日々エンジニアがユーザー価値や事業として提供するサービスに向き合う機会を作っています。
エンジニアのディスカバリー参加
上記のPBIにユーザー価値を記載して、その価値や価値を実現するための要件に対してエンジニアもリファインメントで日々意見を交わすというのもディスカバリーという課題・機会の発見や広義でのデザインにエンジニアが参加していることになりますが、
エンジニアのディスカバリー参加としては、他のトライも出来ているのでこちらでは3つほど既存の開発プロセスでは出来ていなかったことを紹介させて頂きます。
①効果測定にエンジニアも深く入る
設定
従来からCAMPFIREではユーザー価値を実現出来ているかを計るためにABテストやGAを利用しての効果測定を行ってきていました。
しかし、エンジニアはマーケやPdMが決めた内容に沿ってそれらを実装するのが主で、エンジニア自身がどういった効果測定をやるべきかには踏み込めておらず、またどういった結果を想定しているかについての解像度も高くはありませんでした。
なにかの期待CVRを20%とするのと、80%とするのでは、UIやUXが全く異なります。
また、なぜそれが20%なのか80%なのかを突き詰めることも同じく届けるユーザ価値が適切に届けられるかの重要な観点になります。
そのため、ユーザーが触るものを実際に作るエンジニアとしてもここの設定に一端の責務を持つ方が良いのではないか？そう考えて、解像度を高く持てるようにスクラムチーム全体で取り組もうとなりました。（何より良いサービスを届けるために何が出来るかを考えるのは楽しい！）
結果の振り返り
また設定に向き合うだけでなく、リリース後にはオールアジェンダと呼ばれる週2回のスクラムチーム全体のイベントでみんなで結果も振り返るようにしています。
- 例: AI機能のリリース後の振り返り
課題
もちろん課題もあって、ここの運用はまだまだ定まり切っていない部分もあります。
ただ、直近のオールアジェンダでも指標について話されているように、チームとしてそれに向き合っていく姿勢は日々高められていると感じています。
②オールアジェンダで職種を越えた意見のやり取りを行う
先程の項目でもオールアジェンダというワードが出てきましたが、オールアジェンダとは文字通りあらゆることをアジェンダにして、PdM/デザイナー/エンジニアで話し合う場です。
効果測定の話や、UIをどうしていくかの話、スクラムチーム全体のドキュメントをどう管理していくか？などの多岐にわたるトピックを扱っています。
基本的に他のMTGは設定時にアジェンダが決まっているものですが、オールアジェンダではまずは場を固定で用意して、その時々でリスト上で整理されている各自が話したいアジェンダの中からピックアップして話を進める形にしています。
これが出来ることで、今チームに足りていないことに集中する時間を定期で取ることができます。
直近では来期からのロードマップを実現するに向けて、改めて自分たちの携わっている領域であるプロジェクトオーナーさんにとってのユーザー価値ってなんだろう？を振り返るトピックについて取り上げていました。
この職種を越えた意見のやり取りが、それぞれの職種で持っている事業やサービス価値への解像度をチーム内で循環させる仕組みとしてとても機能しています。
多種多様なトピックを扱うからこそ、その職種、その人の観点が落ちやすいんですよね。
めちゃいいイベントなので、ぜひみなさんもやってみてください。
③スプリントレビューでのデモに事業部の方を呼んで幅広くFBを貰う
毎週スプリントの最終日に行われるスプリントレビューでは、デモと呼ばれる一週間のスプリントで完成したものを事業部の方も呼んで見てもらう機会を作っています。
既存の開発プロセスでもQAを通して事業部の方に触ってもらうことはありましたが、より短いスパンかつ、より同期的にFBを貰うことが出来るようになりました。
記事の前半で触れているように、プロダクト側のアウトカムだけでなく、CSや事業部のアウトカムもユーザへの価値提供に大きく影響がある今のフェイズでは、密な情報連携やお互いの領域への意見はとても重要な機会になります。
この場で機能の改善案が出ることや、今後の開発案の共有を出来ることで、既存の非同期での意見交換では難しかったお互いの意見を踏まえた準備や先手をより早く打つことが可能になります。
結果として、サービス開発のプロセスがスピーディーに回せるきっかけの一つになっていると感じます。
事業と向き合うのも大事、あとは開発で大切にしたいことをどう並立させるか。
さて、今まで事業やユーザー価値と向き合う話をしてきました。
改めて記載する中でここにエンジニアが向き合うことの価値をひしひしと感じている一方、直近では事業と技術課題への挑戦を並立させることの難しさの壁にぶち当たってもいますｗ
Four Keysの目的の最上段にあたるものは？
今期から開発チームではFour Keysを計測できるようにしています。
なぜ Four Keys を改善するのか？/productivity-con-link-and-motivationという導入期に参考にさせて頂いた記事でも、Four Keysの目標値には、その値を目指す目的と手段をセットで置くことの大切さを書いてくれています。
CAMPFIREでもこれを見習って目標数値だけでなく、目的や実現することなども設定していますが、開発指標のFour Keysだとしても目的にあたるものは基本事業に関するものを置いています。
また、その「事業価値の向上」のような抽象的な目的の上段に、より具体として事業で目指すべき数値もセットでおけるとそれを実現するための開発生産性としてのFour Keysを適切に設定・評価できるようになるよね…とFour Keysでの生産性向上チームでは話しています。
このように、開発指標と事業指標は一緒に考えて設定するほうがよいだろうというのが今のチームの肌感になっています。
どう並立させていくか
一方、全社の仕組みであるOKRとロードマップに落とし込んだ時に、開発指標を並立させることの困難さにもぶち当たっています。
OKRとロードマップ
開発指標であるFour Keysの上段に事業目標が据えられるとしたら、開発チームとしてのOKRに事業目標が据えられるのが当然の流れになります。
ですが、OKRを実現するロードマップを考えたときに、事業目標が最上段にある場合、ロードマップも事業目標の達成をベースにしたロードマップになります。
この流れ自体は問題がないかのように思えますが、こうした際にリファクタリングやエラー対応、技術的な挑戦などの事業との関連が見えにくい開発業務がロードマップから浮きがちになってしまいます。
ただ一方、ロードマップにこれらを置く場合、やるべきこととOKRを一致させるためにはOKRにも開発文脈のOKRが入る必要があります。
それを全社で追っていくOKRから落とし込んだものにするには、事業目標と技術的な課題への挑戦をOKR上で表現する必要があります。
これ…めちゃむずいんですよね。
純粋に開発だけが追うOKRとしてセットしちゃえば良いんですが、今期はそれを行った結果、全社のOKRから乖離があるものになってしまいました。
結果、他の部署が全社から落とし込んだOKRに沿った部のOKRとして日々の業務で邁進する中で、開発チームのOKRだけが他の部署と違う方向を向いてしまい、日々の業務でOKRの達成に向けて時間を作るのが難しいという状況に陥ってしまう場面がありました。
ここはまさにいま詰めているところですが、開発としての挑戦もしっかり全社の仕組みの中で捉えられるようにして、その上で全社が一丸となってより良いサービスを作る枠組みをみんなで考えている最中です。
この結果は、また来年のアドベントカレンダーでハッピーな話として話せると良いなと想っています。
最後に
事業とユーザー価値に向き合うために個人やチームでやってきたトライについて書いてきました。
今回少しだけ紹介させて頂いた記事だけでなく、ネット上にあふれる本当に多くの記事や事例に背中を押されて一歩ずつ事業とユーザー価値に向き合うエンジニアに、チームに、なってきていると感じています。
また、スクラムチームメンバーだけでなく、全プロダクトメンバーや、CSをはじめとした事業部の方など、多くの人達の協力と工夫と努力と思いやりの中でやりたいことが出来ていると感じています。改めて、今年も一年間、みなさんありがとうございました！！！
「エンジニアチームとして事業・ユーザー価値とどう向き合うか」は、まだプロダクト開発界隈でも答えが出きっていない領域だと思うので、ぜひこの記事を読んだあなたの挑戦もこの答えを一緒に作っていく仲間として共有して頂ければと想っています。
一緒に素敵なプロダクトを沢山世に出していきましょうー！
来年もHappy Hacking🎉