※このストーリーは、noteで発信した記事を転載しています。

こんにちは！EMの相澤（@tigers_loveng）です！

6月28日（金）29日（土）の両日ともに、プロダクトチーム全社員で業務として開発生産性Conference2024に参加してきました！

先日も記事を執筆しましたが、参加者体験がメインだったので、今回はセッション内容に触れた参加レポートをお届けします！

色々な学びが得られた素晴らしいセッションの数々だったので、全て紹介したいと思いつつ、厳選してお送りします。

各メンバーがベスト2を選び、ざっくりサマリー / 良かったところ / ourlyの組織に活かせそうなところの3つの観点でまとめてもらいました。

長文にはなりますが、最後までお付き合いいただけると幸いです！！

社内FB会の様子

EM相澤がピックアップしたセッション2選と感想

プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの

• ざっくりサマリー
• • リソース効率重視からフロー効率重視の体制への変革過程を、ザゴールの制約理論を元に解説
• 良かったところ
• • なんとなくではなく、明確な考え／信念を元に実行していたので自分の中でもなぜフロー効率が良いのかを言語化できました。
  • 発表の中でメンバーや他職種の方への感謝で感極まっていたところに、笹尾さんの人柄や思いが溢れていて素敵な組織だと感じました。
• ourlyに活かせそうだと思ったところ
• • ユーザーストーリーを元に価値分割し、提供価値ベースでチケットを作成することで本質的な生産性向上を目指す上での不確実性を減らせそうだと感じました。

開発トップのマネジメント： 採用からオンボーディングで始まる一貫した生産性向上戦略

• ざっくりサマリー
• • 生産性向上の一環としてピープルマネジメント強化を目的に、入り口となる採用からオンボーディング、の改善に関してのhokan社の事例共有
• 良かったところ
• • 立ち上がりまでの期間を元にオンボーディングプランを設計し、オンボーディングコストを最小にするという考えがなかったので新しい視点がインストールできました。
• ourlyに活かせそうだと思ったところ
• • 新規参画者は多くはないのでオンボーディングにコストをかけすぎてもよくないが、プレボーディングでの情報共有や教育などできる範囲のこともあるので取り入れられそうです。

カンファレンス参加してみての感想

全体的に「組織を強くするカルチャーをどう作るか」「どのようなコミュニケーション体制を作ると良いか」という話が多かったように感じ、ourlyプロダクトチームの強みでもあるソフトスキルが存分に活かせそうだなと思いました。

一方でそれ以前にプロダクトの価値は何か、我々が存在している理由は？という根本を問うような話もあり、改めてチームで向き合うべき課題も見えてきたのでとても良いカンファレンスでした！

テックリード玉田がピックアップしたセッション2選と感想

技術的負債の解消のための設計アプローチ hacomono編

技術的負債の解消のための設計アプローチ hacomono編 hacomonoはウェルネス産業向けのVertical SaaSです。現在 6,000 店舗に導入、前年比 2 倍以上で増dev-productivity-con.findy-code.io

• ざっくりサマリー
• • Chain of Responsibilityパターンなどを使用して決済フローのリファクタリングを行った話
  • ディレクトリを分けない形でAtomic Designを解釈し、ルールや仕組みで成功裏に運用している話
• 良かったところ
• • 複雑な決済フローのリファクタリングに挑むにあたり、そのアプローチと使用したデザインパターンがとても理になかっているように見え、参考になりました
  • Atomic Designのつらみは多いですが、hacomonoさんでは原典に立ち返ってディレクトリを分けることにこだわらずに設計したこと、ルールを機械的に担保する仕組みを導入したことなど工夫も多く感心しきりでした。
• ourlyに活かせそうだと思ったところ
• • 複雑に絡み合ったロジックのリファクタリングには時間がかかるため躊躇しがちですが、往々にして時が経つごとに要件が追加されて状況は悪化します。生産性向上のためにもある時点で腰を据えて立ち向かわねばなりませんが、そのときにさまざまなデザインパターンなどの手法を武器として扱えるようになっていれば、リファクタリングに際しても戦いを有利に運べるのだなと感じました。

Google Cloud が提供する生成 AI ソリューションと開発生産性の変革

Google Cloud が提供する生成 AI ソリューションと開発生産性の変革 「生成 AI」は、ビジネスの成長やイノベーションを促進する非常に大きな可能性を秘めています。Google Cloud は「dev-productivity-con.findy-code.io

• ざっくりサマリー
• • GoogleのProject IDXというクラウド開発環境を用いたFlutter開発のハンズオン
• 良かったところ
• • モバイルアプリ開発における開発環境構築はネックになりがちですが、その心配が要らずサクッと開発できてしまう点が大変魅力的でした。
• ourlyに活かせそうだと思ったところ
• • 開発者個々人のIDEのカスタマイズはどうするのかといった心配はありますが、オンボーディングや一時的に開発に参加するメンバーなど向けにでも開発環境を整える手間を省けるのは大きなメリットであると感じました。

カンファレンス参加してみての感想

規模の大きな開発チームであっても果敢に変革を試み、成果を出しているという企業様が多くあったことに大変感銘を受け、規模の小さな弊社ではより一層変化を恐れずにチャレンジすべきであると思いを新たにしました。

また今回のカンファレンスのような、開発生産性にフォーカスした他社事例を多く知ることができる機会があるというのも恵まれていると感じます。参加費が無料であることを始めとしてガチャや昼食の配布など、ホスピタリティを意識された取り組みも多くFindyさんには足を向けて寝られません。

BE山岸がピックアップしたセッション2選と感想

作りすぎない技術 - API時代の開発努力の在り方について考える

• ざっくりサマリー
• • リソースは有限
  • 必要になるまで作らない
  • 実際に必要となるまでは実装しない（YAGNI原則）
  • 理由: コストの発生を避けるため
  • 組織的開発における重複を排除
  • 機能の重複開発
  • ドキュメントの重複
  • ツールやプロセスの重複
  • 理由: リソースの無駄、効率低下、一貫性の欠如を防ぐため
  • ほどよい80点の品質を目指す
  • 100点の品質を追求するのは難しく、割に合わないことが多い
  • 80点の品質を“継続的に改善する“アプローチが効率的
• 良かったところ
• • リソースの有限性を再認識できてよかったです。
  • 実際に必要になるまで作らないという考え方(=YAGNI原則)が無駄な作業やコストの削減に直結することが分かり、とても有益でした。
• ourlyに活かせそうだと思ったところ
• • これまで“将来的に必要になりそう“という観点で実装していた部分があったため、その改善とレビューの観点としても活かせると思いました。
  • リソースの効率的な利用や、実装以外の重複排除の考え方は、プロジェクトの規模が大きくなるにつれて重要性が増すため、実践していきたい。

「開発生産性を上げる改善」って儲かるの？に答えられるようにする

• ざっくりサマリー
• • 開発生産性を上げるための改善投資の効果について、エンジニアが説明責任を果たす必要がある。
  • 開発生産性はプロダクトチーム以外からの“信頼“を築くことに価値がある。
  • 開発生産性に関するデータは“信頼“を構築するために使用する。
  • 本来、“信頼“が積み上がれば、開発生産性は問題にならなくなる。
  • 事業責任者の視点では、ビジネス戦略的に適切なタイミングで成果を出す開発組織であれば、生産性は気にならない。
  • 本当に知りたいのは、シンプルに“狙ったタイミングで成果を出す開発組織なのか、それとも違うのか“。
  • 各レイヤーによって期待値が異なるため、開発生産性を上げて何を達成したいのか、期待値の擦り合わせが必要である。
• 良かったところ
• • レイヤーごとに開発生産性を上げることに対する期待値が異なるという観点を新たに知ることができて良かったです。
  • 開発生産性向上の取り組みが、開発組織以外からの“信頼“を築くことに価値があるという視点は新鮮で、とても有益でした。
• ourlyに活かせそうだと思ったところ
• • 各レイヤーが重視している観点を知ることができたので、開発生産性を上げることによって達成したい期待値を擦り合わせることができると思いました。

カンファレンス参加してみての感想

「開発生産性」の定義から、それを向上させることで最終的に何を達成したいのかを考えさせられる内容が多くて非常に有益でした！

エンジニアであってもビジネスを進める上では経営者視点がかなり重要であることも改めて学べたので、今回のConferenceに参加できて良かったです！

FE山岸がピックアップしたセッション2選と感想

爆速開発文化を支えるProduct Engineerの開発生産性向上の取り組み

• ざっくりサマリー
• • 顧客への価値提供をベースに開発生産性を評価する。生産性を向上させるには顧客理解が必須で、使われるものを作ることが重要。また、チームとして生産性向上に取り組むためにボトムアップで意見を出し合っている。
• 良かったところ
• • 開発メンバーがプロダクトエンジニアとして活躍すべく仕組みが構造化されていると感じた。顧客へ価値提供（アウトカム）を共通の目的として、要望の棚卸会やレビュー会、ET 会等、プロダクトエンジニアにならざるを得ない仕組み作りをしているように感じた。
• ourlyに活かせそうだと思ったところ
• • まずは ourly の開発チームとしてどこに価値を置くのかを話し合いたいと思った。それを計測する手法としてアウトカムのスコアリングのような指標は良さそうだと感じた。
  • ビジネスサイドとエンジニアサイドで距離があるのはよくある話だと思うが、ourly も例に漏れずビジネスサイドから見てエンジニアが何をやっているのかわからない状況だと思う。なので全員がその週に作られたデモを見て、参加者は積極的にフィードバックし、作ったメンバーがわかるレビュー会等を設けると、会社として共通の目標ができて良いのではないかと思った。

開発生産性の観点から考える自動テスト

• ざっくりサマリー
• • 開発生産性の観点でテストを書く意義とは、信頼性の高い実行結果に短い時間で到達する状態を保つことで、開発者に根拠ある自信を与え、ソフトウェアの成長を維持するためである。ただ、テストはあくまで品質をあげるきっかけにすぎず、品質をあげるのはプログラミングだけなのは理解しておくべき。
• 良かったところ
• • どうやってアイスクリームコーンをピラミッドにしていくのか、という文脈でテストダブルについて学べたこと。テストダブルの利点としては下記が挙げられる。
  • ①ネットワークエラーのテスト等テストがやりづらかったもののテストを可能にする。
  • ②テストの速度と決定性を向上させる。
  • ③テストサイズを下げる。
• ourlyに活かせそうだと思ったところ
• • 上記のようなテストパターンについては FE で勉強会をしていたところだった。アイスクリームコーンをピラミッドにしていくために共通の認識として学んでいきたいと思った。
  • E2E テストはコストがかかる割に不安定なテストなので、今 E2E に投資するよりもユニットテスト（ourly だと特に hook 周り）を充実させた方が良いのかな、と思った。

カンファレンス参加してみての感想

自分が最近考えていた「理想のエンジニア像・組織」が明確にプロダクトエンジニアという言葉で言い表されていることがわかった。

結局のところ使われない機能を提供してしまうことが生産性が低いと言えると思っていて、顧客が本当に使いたいものを作る、ひいては私たち ourly が使いたい ourly を作ることが、ourly の場合は価値提供になるしサービス提供側として誠実だと思った。

また開発生産性を考える上で開発者体験（DevEx）も忘れてはならず、ourly の開発メンバーはソフトスキルが高いので、良くも悪くもやろうと思えばなんでもできてしまう（正直面倒臭い取り組みもソフトスキルで賄えてしまう節あると思う）ので、「エンジニアが開発していて楽しいか」「ourly で働いていて楽しいか」も今後重要な指標になってくるのではないかと思った。

最後に今回豪華なお昼ご飯や景品ガチャを用意・主催してくださった Findy さんにはとても感謝しています。次回から有料にしてくださいませ…🙏

BE神本がピックアップしたセッション2選と感想

フィーチャー開発からホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~

• ざっくりサマリー
• • ログラスが組織/事業成長に伴いワンチーム開発からフィーチャーチーム開発そしてホールプロダクトチーム開発に変化した過程を本質的複雑性と偶有的複雑性の2軸で整理し報告
• 良かったところ
• • 本質的複雑性と偶有的複雑性という2軸から普段の業務を切り取る視点を得ることができたこと
  • 日本企業でまだ導入している企業が少ないFASTというフレームワークを用いて、自社のVALUE体現に向けて本誌的に顧客への価値提供を目指す姿勢に勇気をもらえたこと
• ourlyに活かせそうだと思ったところ
• • 普段の業務で発生する対応を「本質的複雑性」と「偶有的複雑性」の2軸で整理すること
  • 「Org Topologies」は自分のチームがどこにいるか、次にどこを目指すか? を考える参考になること

スクラム開発導入による他組織を巻き込んだ開発生産性向上の取り組み

• ざっくりサマリー
• • 事業フェイズが進み目的不確実性が低い機能から高い機能の開発が増えてきたためウォーターフォールからスクラムへ変えた時にリードタイム短縮でやった事例の紹介
• 良かったところ
• • なんとなく最初からスクラムではなく目的不確実性が高くなってきたからスクラムを選定したという事実を知れたこと
  • PdMから解決したい課題が上がってきた時に、要求と要件を整理してスコープと優先度を整理するやり方が具体的でわかりやすかった
• ourlyに活かせそうだと思ったところ
• • 要件定義の時点で、課題に対して要求と要件を整理してMVPをプロダクトチームからPOへ提案できるような進め方を今後やっていけると思ったこと
  • 細かい要件は実装しながら都度要件を詰めていくという進め方が紹介されており、実装前から要件詰めすぎずにourlyでもこの進め方を取り入れるのが良さそうと思ったこと

カンファレンス参加してみての感想

アウトプットからアウトカムに着目点が変わったことで企業毎の取り組みや目的の部分が差別化された報告が多くて良かったです。また、毎セッションの間の時間があることで、登壇者やスポンサーブースの方と会話する機会が取れてより深く会話ができたことがとてもよかったです。

「開発生産性」というテーマは他のテックカンファレンスと比較して情報の非対称性が熟練度によって発生しづらいのでジュニアエンジニアでも楽しめるところが更に良いポイントだと思いました!

FE藤野がピックアップしたセッション2選と感想

顧客価値向上による開発生産性向上

顧客価値向上による開発生産性向上 本セッションでは、開発生産性を顧客の利益を最大にしながら労力を最小限に抑えることとして捉え、その実現のために顧客理解、課題dev-productivity-con.findy-code.io

• ざっくりサマリー
• • 開発生産性とは投資に対するリターンであり、何に対して寄与するものなのかを意識することでより効果的になる。投資を最小限に抑えてリターンを最大化することを目指す。リターンを最大化するために必要な投資は惜しまない。
  • 価値は顧客価値・事業価値の2つ。顧客価値はクライアントが感じる価値のことで問題が解決された状態。事業価値は売り上げや利益のこと。この2つを両立させることが会社の価値になる。
  • 顧客価値は共感を持つところからスタートする。共感 → 検討を回していくことで技術選定の解像度が上がってくる。プロダクト思考を持ち、開発物がどこに貢献するか？ユーザーを主語にして機能の議論ができているか？を最大化するために Four Keys や SPACE がある。
• 良かったところ
• • 開発するものの価値を知るためにはどのような基準があるか（狩野モデル）を知ることができた。
  • 何を作ったかではなくどのような価値を生み出したかという考え方は意識しないとすぐに抜けてしまうが、解像度高く落とし込めた。
• ourlyに活かせそうだと思ったところ
• • これからプロダクトチームとして成熟していくために顧客価値の共感は必要になると思うので、例えば新規開発の話になった時に「ユーザーを主語にして機能の議論ができているか」という問いは常に置いた方が良いなと思った。
  • 今後も理想の数字を追うだけにならないように、改めてプロダクトチームでourlyの価値の定義をすると良いと思った。

価値創造と開発生産性

【資料公開】価値創造と開発生産性2024年6月28-29日に開催の開発生産性Conferenceでの登壇資料ですwww.ryuzee.com

• ざっくりサマリー
• • 「開発生産性」という言葉の確固たる定義はないが、意味の認識の違いが問題を生み出す。なんとなく聞こえのいいことをふわっと進めると意図しない結果になる。数字を使うと一見論理的に見えるが、数字の意味や認識が合っていないと逆効果。
  • まず計測するのは価値を創造できているかどうか。価値の定義を自分たちで行い、全員に何度でも伝える。それから価値が提供できていることを示す指標を考える。
• 良かったところ
• • 現状数字をなんとなく追ってしまっていることが再認識できたこと。数字を意味のあるものにするために必要なのは、自分たちのプロダクトのビジョンや価値提供できていることの根拠。
• ourlyに活かせそうだと思ったところ
• • 自分たちのプロダクトのビジョンは認識しているしコンテキストもおそらく揃っているが、今後ourlyが成長・拡大していくためにはこの考え方をより強く浸透させることが大事だと思った。
  • 現状全くできていないのでやっていこう！というよりは現状できているのでより強化するためのエビデンスとして有用だという感じ。

カンファレンス参加してみての感想

今回は特に組織の文化の重要性について触れられていたことが印象的でした。ourlyのプロダクトや組織でも文化の醸成、カルチャーマネジメントには注力しており、プロダクトチームとして価値の定義をするうえでの大きなヒントを得ることができました。

また、テックカンファレンス特有の心地よいお祭り感もあり「開発生産性」を通じたひとつのコミュニティが広がっていくのを感じました。このような場を提供してくださった Findy さんに改めてお礼申し上げます。ありがとうございました！

BE土橋がピックアップしたセッション2選と感想

経営視点から捉えた開発生産性

• ざっくりサマリー
• • 開発生産性を最大化するためには、「テクノロジー投資戦略」と「Developer eXperience」の2つの要素が重要となる
  • 「どの山に登るのか」を間違えるとアウトカムは最大化されないので、自社、マーケットトレンド、テクノロジートレンドをそれぞれ鑑みて作るプロダクトを決める必要がある
• 良かったところ
• • 経営的な観点で開発生産性を捉え直しているところ。また短期、中期、長期でエンジニアチームが投資していることを言語化して整理している点
• ourlyに活かせそうだと思ったところ
• • ourlyチームも”プロダクトチーム”として活動するようになったので、今考えている施策や問題は経営観点でいくと、短期、中期、長期のどこに効いてくるのかを視点として持った上で考えられるようにしたい

仮説検証生産性とプロダクトグロースサイクル

https://gamma.app/docs/-necbojc9wcdk8yw?mode=doc

• ざっくりサマリー
• • プロダクト開発は市場を探索するフェーズと、収益を伸ばす活用のフェーズに分けられるので今のプロダクトの状況に応じてどちらの比重を増やすのかを考える必要がある
  • プロダクトマネジメントの目標を考える際には、ロジックツリーによる線形の関係だけでなく、システム思考による非線形の相関関係があることに注意する
• 良かったところ
• • 期待付加価値を高めていく上で、新しく探索をする点と、顧客の問題解決にフォーカスする活用の点で分けて考える思考法を知ることができる点
• ourlyに活かせそうだと思ったところ
• • エンジニア側からも事業やプロダクトに価値を発揮していく上で、そもそもどういう指標を追い求めていけばいいかの手掛かりとなりそうな点

カンファレンス参加してみての感想

そもそも開発生産性とは何か？というところから考え直すきっかけとなり、とても刺激になりました。

また開発生産性を高めたその先に何があるのか、それをプロダクトの価値や経営の観点からも論じている発表があり、新しい観点を身につけることもできました。この2日間で学んだことをもとに行動に移します！

以上、各メンバーがピックアップしたセッション2選と感想を紹介しました！
最後までお付き合いいただきありがとうございました。

ourlyは全方位で積極採用中です！この記事を読んで相澤とカジュアル面談してみたいと思っていただけたら、ぜひ気軽にご連絡ください！