はじめに
11月21日に
技術的負債に向き合う Online Conference
11月28日に
開発生産性の未来：世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜
と2週連続でFindyさん主催のカンファレンスに参加させていただきました。
特にFindyさんのカンファレンスを選んで参加したわけではなく、
興味関心のあるカンファレンスに参加を決めたらこうなったのでシンパシーを感じます。
28日は汐留でオフラインで参加し懇親会にも参加させていただきましたし、
21日も時間を取ってかなりしっかり参加させていただきました。
部屋で一人で首がもげるほど頷いたり、負債に立ち向かう姿に涙を流したり、
オフラインではオンラインで素敵な発表を拝見した方に直接お会いしてお話を聞けたりと
良い体験ができました◎
本記事は上記２つのカンファレンス参加の感想文です。
印象に残ったセッションや言葉、全体を通して感じたことを記載していきます。
技術的負債に向き合う Online Conference
11月21日にオンラインで開催されたカンファレンス
エンジニア不足の中でどう技術的負債と向き合ったのか
株式会社 RevComm 服部 圭悟さんの発表
当時の課題（一部）というスライドに記載の状況に対して
負債の種類を分析し、課題を解消するための戦略を組織・チーム・個人という観点で立て、
それぞれに対して理想像を描き、原理原則を守って着実に改善を進める。
本当に真摯にエンジニアリングに向き合い続けたことが感じられる素晴らしい発表でした。
当時の課題に対応した今はどうなったか？というスライドは涙なしには見られませんでした。
組織の観点での戦略
- チームのミッションとバリューを明確化
- 未来の組織図を作成
- JDの作成
- 採用プロセスの見直し
数年後の自分たちはどういう組織体制で働いているべきか「チームトポロジー」を基に設計した。
-> 自分たちの目指す状態がクリアになった。現在と未来のギャップが明確になった
今、うまくいかない。
ではどういった組織になっていればうまくいくのかを示すことの重要性を感じました。
チームの観点
- 振り返りを導入する
- 情報を得るために必要なコストを減らす
- 暗黙知を形式知に
- 優先度を決める - やるべきことをやる
「振り返り」が最も重要
「振り返り」を繰り返すことで、チームは自己組織化する。チームの自己組織化はトップダウンの文化からは生まれない。
変化を焦らない。改善を焦らない。焦ると失敗する。変化には忍耐が必要。
ついつい振り返りの場でもたくさん喋ってしまいがちなので、何度も口に出して読みたい言葉。
個人の観点
やる。それだけ
とのことでしたが、確実に必要なことを見極めて取り組まれていると感じました。
現場主導で取り組む継続的な技術的負債の解消
ファインディ株式会社 浜田 直人（@ham0215）さんの発表
なぜ開発生産性の話？
- 技術的負債の解消に取り組む場合、開発生産性の向上を目的とすることが多いため
- 技術的負債解消前後の開発生産性を比較することで定量的に効果測定できる
- 開発生産性を定量的に示すことで、開発チーム以外にも説明しやすい
- 効果が少ない場合、負債を解消しない理由を明確にできる
- 生産性が向上した証跡を残すことで次回以降の負債解消がさらに進めやすくなる
技術的負債の解消に取り組む際の効果測定指標としての開発生産性が重要であるというのは当然の話ではあるのだけれど、忘れてしまいがちな話。目的を見失わずに取り組むことが重要。
Four Keysに加えてプルリクエストの作成数とマージまでの時間を取る理由
- Four Keysだけでは個人のパフォーマンスが見えづらい
- Four Keysではチームのパフォーマンスは測れるが、メンバー単位で深堀りしづらい
- プルリクエストの作成数とマージまでの時間の場合、メンバーごとのアウトプット量とスピードがわかる- 作成数を増やしてマージまでの時間を短くするには、１つ１つのパッチサイズを下げる必要があり、Four Keysの向上にも繋がる
- 簡単にデータを取得できる
- プルリクエストベースで開発すると自然にデータが取れる
Four Keysに加えてプルリクエストの作成数とマージまでの時間を計測するというのが良く聞く話ではあったのですが、メンバー単位で深掘りしやすいという理由に納得しました。
数値と合わせてどういう状況でこの数値になったのか、という振り返りを合わせて行うことで改善に向けてどうすれば良いのかを考えることができると思いました。
技術的負債解消のサイクル
- 闇雲に改善すれば良いというものではない
- 工数と効果のバランスを意識しよう
- 頑張ってもあまり効果がないと改善のモチベーション低下
- リソースは無限ではない
- 一方で細かいものはえいやーでやる勢いも大事（私やみんなの気分が良くなる！だけで良い！）
一番印象に残ったのがこの話で、開発期間中に溜めておいた不満点を「のびしろ」として蓄積し、それに着手する前にディスカッションを実施してから改善にあたるというサイクルが定義されている点です。
ともすると自己満足で改善に臨んでしまいがちなので、着手する前にディスカッションしてから取り組むということは有効そうだなと感じました。
とはいえ小さなものはえいやっでやってしまう勢いも大事というバランス感覚にも共感。
また振り返りの場の中で数値を見ることでチームの自己組織化も促進できると感じました。
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い
@mtx2s さんの発表
負債の4分類の中の無謀で無自覚な負債、無謀で意図的な負債が生まれる原因となる組織設計について、様々なアンチパターンを紹介してくださった発表でした。
私が過去に所属していた組織で実際に直面した問題もいくつかあり、チームや製品の連続性・成長・自己管理といったものがいかに重要であるかが身に染みました。
またそれぞれに対してどのように対策を打つのかも示唆されていました。
組織設計がソフトウェア設計に与える影響は大きい
ソフトウェア設計が生産性に与える影響も大きい
それは「市場投入までの時間」と「遅延コスト」という形でビジネスに影響を及ぼす
ソフトウェアが設計がそうであるように、組織設計も何が正解であるかは不確実で流動的
したがって、完璧な答えにたどり着くことは決してない
だから、ソフトウェア設計と同様に、組織設計もリファクタリング・リアーキテクティング繰り返す必要がある
その探索を続ける中で組織は、生産性を維持・向上させることが可能になる。
より良い組織設計に近づけるための探索を続けることの重要性を感じました。
個人的にエンジニア組織を構築する上で重要なポイントは以下だと感じました。
- 連続したチームであること
- チームがオーナーシップをもって取り組める状態であること
- チームがリリースしたものに対するフィードバックを受け、改善を続けられること
- 上記３点ができた上で定期的な変動があること
開発生産性の未来：世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜
11月28日に開催されたオンライン、オフラインのハイブリッドカンファレンス
開発生産性向上を通じた組織文化づくりへのアプローチ
andfactoryさん、スタークスさんがそれぞれ
- 開発生産性の定義
- 開発生産性を上げるための取り組み
- 今後の取り組み
といったテーマで対談形式でお話されていました。
開発生産性の定義
ビジネスアウトカムを見据えながら、エンジニアが計測・コントロールしやすいKPIとして
PR数やマージまでのリードタイム、リリース品質といった指標をうまく利用する。
開発生産性を上げるための取り組み
PRのリードタイムを計測しボトルネックになっている部分を抽出・改善。
チェックしている項目
- オープンからマージまでの平均時間
- コミットからオープンまでの平均時間
- オープンからレビューまでの平均時間
- レビューからアプルーブまでの平均時間
- アプルーブからマージまでの平均時間
- プルリク作成数
- マージ済みプルリク数
- 平均コメント数
- レビューされずにマージされた割合
- 平均変更行数
- 平均変更ファイル数
- レビュー依頼からレビューまでの平均時間
- レビュー数
- 自分がレビューしたプルリク数
- プルリクに対する自分のコメント数
ここで説明されていた中で特に印象に残ったのが「エンジニアの基礎行動を徹底させるツール」という言葉。
良い数字をひたすら追い求めるというものではなく、健康診断の数値のように異常値がないかを計測し異常値があった場合に原因を探って改善する。
特にジュニアエンジニアの教育において仕事の進め方を観測しやすくなる、という部分が良いなと思いました。
また進捗が悪い時に報告しなくても観測できる状態にするという優しさも素敵だなと思いました。
今後の取り組み
- オープンからマージまでを24時間以内にする
- PR健康診断を通じてPRの品質を定量化しメンバーが状態を把握できることで、今後の自主的な改善につなげる
- 期待付加価値の精緻化
- 実現付加価値の観測性の強化
懇親会
懇親会はエンジニアリングという共通言語を持って知らない方とお話しできる機会で個人的に大好きです。
今回もスタークスの片居木さんと発表内容についてお話しできたり、一緒に来られていた新卒の方ともお話ができたり、技術的負債に向き合うOnline Conferenceで発表されていたFindyの浜田さんとお話できたりと、とても有意義な時間でした。
またこういった場で自分が関わっているシステムではありえないような別のシステムの苦労話を聞くことでハッとすることも多いのですが、今回はハードウェアに関するソフトの開発をされている方の話で「変更のリードタイムっていうけどおじいちゃんおばあちゃんはソフトの更新なんて当ててくれないんですよ」とおっしゃっていた話が印象に残りました。
２つのカンファレンスを通して感じたこと
技術的負債を解消する・開発生産性を向上させるためには個々のエンジニアの行動変容が必要でそのためには文化の醸成が必要であるということを改めて強く感じました。
また計測の部分では最終的にはビジネスアウトカムが重要であるものの、その手前の指標を計測し原因分析をして自主的な改善に取り組み続けるということが重要であると感じました。
さらにそれらを促す組織を作るためには継続性・オーナーシップ・自己組織化といった観点が重要であると感じました。
非常に学びの多い二日間でした。
これからチームでの取り組みに活かしていきたいです。