こんにちは、中嶋です！
先日の2024年6月28日〜29日に開催されたファインディ株式会社が主催する開発者生産性カンファレンス 2024に参加してきたので、本記事では参加したセッションの中で印象に残ったところや全体を通しての感想などをお伝えできればと思います！
会場の様子
今年のイベント会場は、虎ノ門ヒルズでした。 昨年よりも参加者が増えているとのことでした。
たくさんの方が来場されていて4階と5階のブースを行ったり来たりするのが思ってたより大変でしたが、移動距離はそこまで遠くなかったのでスムーズに回れました。
スポンサー企業のブースを周ってスタンプラリーも無事に完全制覇することができました！笑
では、気になったセッションについて順不同でご紹介させて頂ければと思います！
参加したセッションの感想
価値創造と開発生産性
最初に印象に残ったのは本イベントのメインテーマである「開発生産性」の定義を再考するきっかけとなった価値創造と開発生産性というセッションです。今回開催されたイベントでは「開発生産性」に関するテーマについて、具体的な実装レベルから抽象度の高い事業や組織のレベルなど異なる文脈で議論が展開されるセッションが数多くありました。本セッションではそのような多様な文脈で議論される「開発生産性」という言葉の定義を改めて考え直す上で非常に多くの学びがありました。このセッションを聞いた後は、他のセッションを聞く際にどの文脈で語られる「開発生産性」の話なのかを意識しながら聞くことができたと思います。
開発生産性には、狭義な意味での効率を示す「物的生産性」と、広義な意味での効果を示す「付加価値生産性」があります。そして、ビジネスの現場だけでなく学術的な論文の世界でも、これらの意味合いを明確に使い分ける言葉が統一できておらず、開発者とマネージャーの間でも認識齟齬が起きているというお話をされてました。「開発生産性」に限らず統一的な定義がまだ定まってない段階で、言葉だけが一人歩きしてしまい現場が混乱すること（アジャイル, ビッグデータ, DXなど）は、ソフトウェアの世界ではよくあることかと思います。そのため言葉の曖昧さを無くすために客観性の高い定量的な数値を用いて管理することが好まれます。しかし、言葉であれ数字であれ意図（意味）を完全に伝達することは困難なので、結局はコンテキストが最も重要なのだと改めて認識しました。ここでは「開発生産性」の目的に立ち返り、最終的にはどんなビジネスであっても存続していく上で「顧客に付加価値を提供すること」が本質的な論点であると説明されてました。やはり、まずはメンバー全員がプロダクトのビジョンやゴールについて共通認識を得ることを優先的に取り組むべきなのだと改めて実感しました。効果が先で、効率はその後という優先度を意識するよう今後も注意したいなと思います。
開発組織の生産性を加速させる: 継続的価値提供を実現する文化と仕組み
本セッションでは、開発生産性を「価値ある開発（効果）」と「開発の効率性」に因数分解して、「価値ある開発（効果）」に重点を置いてどのように実現していくのかを紹介されてました。まず前提として開発する機能がどのくらいの付加価値を生み出すかを実際に開発・リリースする前の段階で把握することが困難であることを受け入れる必要があると思います。そして、仮説検証型のアジャイルを実践することで、「進む先を軌道修正できること」や「修正できる頻度を増やすこと」などに焦点を当てて実際の具体的な改善活動の取り組みについてご紹介して頂きました。特に印象的だったのは、開発チームのメンバーがユーザーインタビューをマネージャーと2名体制で一緒に行っていたり、レトロスペクティブではチームの熱量を維持するために振り返りだけでなく「"むきなおり"」も実践されていることなどがありました。先が見えないプロジェクトや目的が不透明な開発案件だとメンバーの熱量も下がってしまいがちです。仮説検証を開発チームだけで完遂できるような体制を目指して当事者意識を醸成させるような取り組みが重要なのだと実感しました。
途中で質疑応答の時間を設けて対話しながらセッションを進める形式だったので、話も聞きやすかったです。スクラムを実践されていて、チームの規模や体制も似ていたので、非常に参考になりました。また、本セッションの中では市谷聡啓さんが書かれた「正しいものを正しく作る」や「組織を芯からアジャイルにする」という書籍からの引用がいくつか紹介されていました。チームの杉山もおすすめしていたので、自分も読んでみて、気になるものをチームに取り入れていきたいなと思いました。
アーキテクチャレベルで考える開発生産性
本セッションでは、開発生産性について利益（収益）と費用という文脈から紹介されてました。開発生産性はコスト削減のための手段ではなく、利益（収益）の最大化を目的としなければ意味がないと思いました。コモディティ化された機能やオプション機能と、競争優位性を生み出すコア機能を区別せずに開発リソースを投じてしまうと、企業の競争力も大きく低下してしまいます。有限な開発リソースを最適に配分していく（選択と集中の意思決定を実行する）上で、まず前提として収益の最大化を目的とした開発生産性を議論すべきだという重要性について学びました。
そして、競争優位性を生み出すコア機能に対して最大限の開発リソースを割いていく上でドメイン駆動設計のノウハウが役に立つことを紹介されていました。ソフトウェアの品質特性として機能性と変更容易性の観点を取り上げて、それぞれがドメイン駆動設計の戦略的設計においてどのように関連しているかについて学びました。ドメイン駆動でソフトウェアを設計する上で最も重要な作業の1つとしてコアドメインとサブドメインの境界を明確に線引きすることが挙げれられます。その際にプロダクトのビジョンやゴールを理解できてなかったり、サービス固有のドメイン知識がなければ、どのような機能が収益の最大化にとって重要なのか（優先すべきなのか）を判断することができません。機能性が高い競争優位なコアのドメイン領域に特化して変更容易性の設計コストを集中させることで、開発生産性をアーキテクチャレベルで高めていく必要があることを実感しました。
開発生産性の観点から考える自動テスト
最後に取り上げたいのは、開発生産性の観点から考える自動テストのセッションです。自動テストの目的を「信頼性の高い実行結果に短い時間で到達する状態を保つことで開発者に根拠ある自信を与えソフトウェアの成長を持続可能にする」と結論づけた上で、信頼性, 実行結果, 短い時間で到達する, 状態を保つという4つの観点を紹介されていました。
特に印象に残っているのは、ユニットテストという概念について開発者の間で認識齟齬があるため、従来のユニットテスト, 結合テスト, E2Eテストではなく、テストサイズ（スモール, ミディアム, ラージ）によって分類することでテストピラミッドを再整理するというお話がありました。また、モック,スタブ,スパイ,フェイクなどのテストで利用される擬似的なデータを「テストダブル」と呼び、それを利用するとテストの信頼性に関わる偽陽性（コードが正しいがテストが失敗する）や偽陰性（コードが間違いだがテストが成功する）のリスクを増大させるため、テストサイズを下げることを目的としないと大きな効果は期待できないことなどがあります。
他にもFlakyなテストはラベルを付けてCI上で実行する際はスキップさせておき後で時間を設けて集中的にリファクタしたり、テスト実行結果からコードの実行時エラーなのかテストのアサーションエラーなのかを判別できる情報が提供されないようなテストは書かない、などのノウハウも数多く紹介されていてすぐに導入できそうなものは取り入れようと思いました。
まとめ
本イベントを通して「開発生産性」に関して多くの学びを得ることができました。これまではどちらかというと実装的かつ効率性に偏った認識をしていましたが、利益（収益）や付加価値などのビジネス的かつ効果性の観点が本質的には重要であることを意識しようと思いました。また、初日のJ.B. Straubel氏によるKeynoteでは開発組織の文化の重要性について強調されていたことが印象に残っています。今後は開発組織が大きくなっていく中で、チームの価値観や文化を築き上げていくが重要だと切実に感じました。
おまけ
本イベントのランチは、1日目がベーグルで、2日目がとんかつ弁当でした。どちらも程よいボリュームでおいしかったです！
巨大ガチャ
奇跡的に2等（技術書）と3等（Amazonギフト券5000円分）を連続で当てることができました。
懇親会
開発生産性Conference 2024 投稿総まとめです。
— 開発生産性Conference 2024 6/28-6/29開催（オンライン配信あり） (@dpe_findy) June 30, 2024
スポンサー企業の皆様、ご登壇者の皆様、ご参加頂いた皆様、ありがとうございました。
また、次回来年の開発生産性Conference 2025でお会いしましょう！#開発生産性con_findyhttps://t.co/9HBhp5SJNx #Togetter @togetter_jpより
懇親会にも参加してきました！開発体制やエンジニア採用などについてお話ができて良かったです。
本記事は以上となります。
最後まで読んで頂きありがとうございました！
当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募ください！
アプリケーションエンジニアはこちらから！ www.wantedly.com
SRE はこちらから！ www.wantedly.com
