開発生産性Conference 参加レポ
アイミツ開発チームでエンジニアリングをしている deliku といいます。
本日下記イベントに参加してきました。カンファレンス会場が日本橋で自宅からアクセスしやすく有り難かったです。
開発生産性Conferenceとは？
開発生産性に纏わる知見を集めて、より良い組織を作りながら顧客への価値提供の速度を上げ、よりグロースするサービス・プロダクト作りに向き合うためのカンファレンス
なぜ参加したのか
下記ブログで開発生産性を向上し続けたい想いを書いており、今もそれは変わらず、ユーザに価値を素早く提供し続けるために重要だと考えています。
カンファレンスに参加することで他社事例から弊社で活かせるものがないか情報収集をしたく参加しました。
なぜ我々は開発生産性を高めていきたいのか
プロダクトとはそれ自体に価値はなく、ユーザに価値を提供して初めて価値が付加されるものと思っています。また、最初からユーザが求めているものを正しく開発できれば悩むことはないのですが、確実な答えは誰ももっていません。「分からないことが多い状態から、分からないことを分かるように進めていき、たくさんのユーザに価値を提供し続けたいと思っています」
仮説検証という打席に多く立ち続ける必要があり、その打席に多く立ち続けるために開発生産性の向上をしたいのです。
【株式会社ログラス】生産性向上に自ら取り組むチームカルチャーが生み出す顧客価値
「良いケーキの切り方」という表現は素敵だなと感じました。確かに切り分けたケーキが大きすぎるともうちょっと小さくならないかな？となりますよね。
また「チームカルチャーが重要な要素である」という点は非常に共感しました。「一人称から三人称」「1人で立ち向かうのは難しい」「先導・推進した人を褒める」など、みんなで一丸となって取り組んでいこう という価値観・文化を形成しているんだなと。
【株式会社リンクアンドモチベーション】なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜
SREとアプリ開発者とでチームが分かれていると改善が進みづらいのはああるあるな話で、こういったケースの場合チームの一員となって境界をなくすがセオリーだろうなと思って聞いていました。（後半でその話が紹介されます）
リリース作業自体が大変のなかでデプロイ頻度をあげるために、リリース作業の回数を増やしてしまっていたのは、「木こりのジレンマ」状態に陥ってしまっていたのかなと。
木を切り倒す作業において、木こりが斧を研ぐために作業を中断すると、木が倒れる前に斧が鈍ってしまい、再び作業を中断する必要があるというジレンマです。このジレンマは、仕事の効率化や生産性の向上において、目の前の作業に集中しすぎて、全体を見通せないことで、逆に効率が悪くなることを表しています。
また、自分も気をつけているのですが、FindyTeams+ を導入し数値が見えることで目先の数値をあげることにフォーカスするのではなく、なぜその数値になっているかのファクトを分析することが重要かなと思います。
【株式会社タイミー】組織をスケールさせるための Four Keys とチームトポロジー
「PBIは顧客への価値提案以外のタスクが存在する」
これは弊社でも同様です。リファクタリングやセキュリティ対応、ミドルウェアのバージョンアップなど顧客への価値提案に比べると対応優先度は下がりがちになるのは理解できる一方、後回しにするとその分だけ蓄積されていくので、判断が難しいもののいつやるかの決めの問題かなと思っています。
感想
エピック / タスク / チケットを小さくし、プルリクを小さくする、ペアプロ/モブプロの導入、スコープを小さくするのは、開発者体験の向上の手法の王道だなと各社の講演を通して感じました。また、ZOZOのようにAIサポートを導入する会社が増えていきそうな予感がします。
弊社の取り組み
昨年 FindyTeam+ を導入し数値計測を行なう環境を整えており、去年はエンジニア組織の生産性が高い企業として受賞しています。
その背景にはエンジニア以外も含めた１チームでフローの最適化を行ったり、小さな改善活動を地道にしていたりします。下記のブログにて紹介していますので、興味のある方はぜひ読んでみてください！
▶ 【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
ちょっと興味あるかも？と思った方はまずはカジュアルにお話ししましょう！
エンジニア採用資料はこちら
この記事が気に入ったらサポートをしてみませんか？