開発生産性Conference2024 参加レポート
はじめに
カンリーでバックエンドエンジニアをしている菅野（@imsugeno）です。
今回はFindyさん主催の開発生産性Conferenceに参加してきたので、その参加レポートをお届けします。
開催概要
イベント名：開発生産性Conference2024
開催日：2024.06.28(金) - 2024.06.29(土)
開催場所：虎ノ門ヒルズ（一部オンラインセッションあり）
※参加日は06.28(金)のみです
参加経緯
カンリーのエンジニア部には「ケン活」という業務時間内での自己研鑽を推奨する制度があり、1営業日1時間を目安に業務時間を自己研鑽に使用することができます。
普段からFindyさんの勉強会に参加することもあり、開発生産性には興味があったので、こちらの制度を利用して参加することにしました。
参加セッション
ビットキーの開発組織戦略と各チームの開発生産性向上に対する取り組み事例
株式会社ビットキー 白木 孝典さん
（ネット上に資料なし）
開発組織体制・QAシフトレフト・BDDの導入・チームコミュニケーション、など様々な側面からビットキー社で行なっている開発生産性に関する取り組みを紹介されていました。
印象的だったのはコードジェネレータを自作した点で、こちらに関しては過去にnoteで取り上げられていたのでリンクを貼らせていただきます。
保守のための開発がいらない状態、パーフェクトなプロダクトを目指したとのことだけあり、シンプルなCRUD APIであればほぼ自動で作成され、バリデーション実装なども自動で行われるということだったので、コードジェネレータ自体の実装や運用がめちゃめちゃ気になりました。
またこれだけでなくE2Eテストもmablによって自動化されており、QAエンジニアによる手動リグレッションテストはほぼ行わないという徹底ぶりで、このような状態を目指せれば良いだろうなと思います。
パーフェクトなコードジェネレータまでは難しいかもしれませんが、SwaggerやDB定義からのコード生成、一部のE2E自動化までは自チームでも行なっている部分なので、さらなるE2E自動化やQAシフトレフト、自動コード生成の余地を探っていきたいですね。
作りすぎない技術 - API時代の開発努力の在り方について考える
Postman株式会社 川崎 庸市さん
「無駄を省く」という文脈で、YAGNI・車輪の再発明・チームトポロジーなど様々な観点から、無駄な努力をせずにスピーディーに開発を行う方法を紹介されていました。
元々知っていたものもあればそうでないものもあり、知らなかったキーワードとして気になったのは以下のキーワードです。
Fail Fast
OODAループ
ビルディングブロック
MACHアーキテクチャ
コンポーザブルアーキテクチャ
結局はまとめの言葉に尽きるなという感想でした。
我々のリソースは有限です。その中で効率的かつ効果的に開発を行い、生産性を向上させるためには、過剰な設計開発や技術の導入を避けることが重要です。また、限られたリソースの中でどこに重点を置くのかを明確にすることも不可欠です。
何か要件が来たときにどう実現するか（どう実装するか）を考えがちですが、これって車輪の再開発じゃないか？実装せずに他サービスを利用することで工数を削減できないか？とイシューから疑うことを心がけたいです。
顧客価値向上による開発生産性向上
Tably株式会社 及川 卓也さん
（ネット上に資料なし）
このセッションでは「確かに…」が多すぎてずっと首を縦に振っていました。
「開発生産性をどう上げるか」というセッションが多い中で、「開発生産性を上げることは顧客価値向上の手段」という前提で、目的を見失わないようにしようと向き直らせてくれる内容でした。
ざっくり内容と刺さった言葉としては以下が挙げられます。
開発生産性の向上＝投資の最小化orリターンの最大化
FourKeysなどのメソッドは、投資の最小化とリターンの最大化のどちらに寄与するのか、を考えることで開発生産性向上の最大化を目指す
アウトカムが高いプロダクトを作らないと意味がない
使われないプロダクトのFourKeysがいくら高くても意味がない
コードの向こうにユーザーを見る
事業サイド対開発サイドではなく、全員が「プロダクト志向」を高める。そのために越境する。
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの
株式会社カケハシ 笹尾 納勇仁さん
このセッションでは、カケハシ社でのプロダクト拡大フェーズでチームの混乱期を乗り越えてマトリックス型のチームを構築するまでの経緯を紹介されていました。
制約理論自体を理解できていないので6割程度の理解になってしまっているのですが、前の及川さんのセッションと同様になぜ開発生産性を上げるのかにスポットを当てており、開発生産性も突き詰めていくと価値提供に行き着くのだなと勝手に納得しました。
またサイクルタイムやベロシティ等を計測しつつも細かな数値の変動に一喜一憂せず、チームの状態をターゲットに置いて中長期的なトレンドで改善していた点もとても参考になりました。
小さく分割されたユーザーストーリー、分割を経て行う優先度づけや高速な仮説検証などロジカルに施策を実行されていた一方、登壇者の方がかなり高い熱量で発表されていたことが印象的で、言うは易し行うは難しであったことが伺えました。
制約理論の参考文献として紹介されていた「ザ・ゴール ― 企業の究極の目的とは何か」は一度読んでみたいですね。
開発生産性につながるDevSecOpsとその落とし穴、1億件超のデータ漏洩とその教訓
EGセキュアソリューションズ株式会社 徳丸 浩さん
（ネット上に資料なし）
いかに早く開発サイクルを回すことができても、セキュリティ上の重大な欠陥がある製品を提供してしまったら意味がなく、その上でDevOpsにセキュリティ観点を組み込んだDevSecOpsは重要です。
本セッションではCapitalOne社でのセキュリティインシデントを事例として、DevSecOpsの落とし穴を解説されていました。
具体的な事例はこちらの論文にまとまっているとのことで、興味がある方は読んでいただけると発表の概要が分かるかと思います。
なぜCapitalOne社はDevSecOpsをいち早く取り入れた企業だったのにも関わらず、SSRF攻撃を受けてしまったのかという内容となっており、まとめると以下の原因であったようです。
クラウドのセキュリティ機能の過信
システムが複雑であるから（作っている側でさえも複雑で扱いきれないほどであるから）「攻撃を受けるはずがない」と言う過信
セキュリティエンジニアの離職率の高さによるセキュリティ運用の低下と、それを産んだ企業風土の根本的な問題
AWSなどのクラウドセキュリティは利用者側が責任共有モデルを理解し、ユーザー責任範囲は適切に運用する必要があります。
目新しい技術トレンドに囚われず、このような基本的なセキュリティ対策を地に足つけて行うことが重要ですね。
まとめ
すべての日程、すべてのセッションを見れたわけではなかったものの、一般論としての新たな知見もありつつ、実践ベースのいい意味で泥臭いナレッジもありつつ、現地で見たセッションだけでも濃密な学びがありました。
有志の方がネット上に公開されている資料をまとめられていたので、興味があれば他の資料も見ていただけると良いかと思います。
ここで登壇できるくらい魅力的な開発チームを作っていきたいですね！
おまけ
企業ブースもしっかり回らせていただきました！
以前Findyの勉強会でお話しした方にお会いできたり、後日カジュアル面談で私も参加してましたーと話題になったり、コミュニティとしてもとても良い場でした！
スタンプラリー特典のガチャでは、爆運でアマギフをたんまりいただいてしまいました。
ありがとうFindy…ありがとう開発生産性…
弊チームでは開発生産性の向上も含め、共に働くエンジニアを募集しております。
もしご興味があればカジュアル面談でお互いの情報共有からさせていただけると幸いです！
下記リンクから応募いただくか、もしくはこっそりXのDMでご相談いただいても大丈夫です → @imsugeno
この記事が気に入ったらサポートをしてみませんか？