こちらのイベントのアーカイブを視聴したので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- ゲスト講演〜技術的負債が開発者体験を悪化させる〜
- タイミー講演〜「技術的負債との付き合い方 〜プロダクトミライ会議〜
- タイミー講演〜現場のエンジニアが向き合う技術的負債の現実（リアル）〜
- パネルディスカッション
- 場合によっては負債と認識して採用することもあると思うが、どのように意思決定プロセスを踏むのか？
- 負債の4象限の中でまずはどこから取り組むのか？
- 技術的負債がある中で成果を出してしまいその後に現場を離れるようなことを防止する方法はないのか？
- 開発者自信がユーザー体験を技術的負債の解消よりも優先したい意志がある場合、どのように開発者に向き合わせるか？
- プロダクトミライ会議では改善速度のほうが早いのか？課題が生まれる方が早いのか？
- 開発からビジネスサイドへの説明とはどのようなことをしているのか？
- 技術的負債活動の実施をどのようにステークホルダーに説明すればいいのか？
- 負債を可視化することでエンジニアの満足度は向上したか？
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。
第5回目は技術的負債が開発組織に及ぼす影響と具体的にどの様に技術的負債を返済していくのかを共有する勉強会です。
今回は「技術的負債は開発者体験を悪化させる（332はてブ）」や「エンジニアリングスキルで捉えるチームマネジメント（532はてブ）」のブログを執筆し、質の高いアウトプットを継続されているmtx2s氏をお招きして技術的負債が開発組織や開発者体験に与える影響を語っていただきます。 技術的負債に関してタイミーではプロダクトツラミカイギ、プロダクトミライカイギという技術的負債の返却に関わる会議帯の運営をしており、継続的な取り組みをしておりますので具体的な技術的負債返却に関する取り組みをお話します。
会の様子
ゲスト講演〜技術的負債が開発者体験を悪化させる〜
まずは松本さんが、技術的負債が開発者体験を悪化しているといえる理由と技術的負債が生まれるメカニズムを説明してくれました。
技術的負債に関して言及されている書籍や有名なブログ記事などを丁寧に整理してくれた発表だった上に内容も非常にわかりやすかったので、今後技術的の話をするときは前提としてこの発表を聞いてもらえばよいのではないか？と思える内容でした。
タイミー講演〜「技術的負債との付き合い方 〜プロダクトミライ会議〜
Timeeで技術的負債や開発時に発生する課題に対応している具体事例としてプロダクトミライ会議の紹介をしてくれました。
プロダクトミライ会議は、各々の開発チームが抱えている課題を持ち寄って対応策を話し合う会議ということで、2週間に一度30分行われているそうです。
プロダクトミライ会議では、技術的負債を解消をしつつも課題を認知することを優先しているということで、継続して行ったことで課題に対するナレッジ蓄積や問題認知/問題解決までのスピードの向上...様々なプラスの効果があったということでした。
また、各チームが改善活動で生まれた内容の共有→課題の起票→課題の評価というアジェンダで進めていることも、会の目的を考えると非常に共感できました。
タイミー講演〜現場のエンジニアが向き合う技術的負債の現実（リアル）〜
現場で実際にどのようにして技術的に対して向き合い、改善を繰り返してきたか？という話を聞いていきました。具体的には、2022年度に以下のことをやっていったそうです。(改善の内容は20%ルールで実施)
テスト周りの修正をこれだけ丁寧に実際に手を動かしながらやってくれる方がいらっしゃるチームは強いなあと思いましたし、実際にコードをリファクタリングしていく前にこういった設備を整える重要性も実感できる発表でした。
パネルディスカッション
最後に、登壇者でパネルディスカッションを行っていきました。
以下、パネルディスカッションの内容を一問一答形式で記載していきます。
場合によっては負債と認識して採用することもあると思うが、どのように意思決定プロセスを踏むのか？
- ユーザーのフィードバックを元に機能自体の必要性を考える場合は負債を意図的に飲んでいる
- 現状こういった意思決定をしたことはない
- 負債のトレードオフが何かを明確に説明できるか？をまず判断する。これが言語化できれば、将来的にその負債をいつどのように解消するのか？を言語化する
負債の4象限の中でまずはどこから取り組むのか？
- 情報の可視化から取り組む
技術的負債がある中で成果を出してしまいその後に現場を離れるようなことを防止する方法はないのか？
- スタートアップなどは特に、PMF勝負みたいなところはあるので、人に向き合うというよりも技術的負債があればそこに淡々と向き合うことが重要だと思う
- そもそもこういった事例を見たことがない。もしあるなら評価の観点がバグっている可能性が高い
開発者自信がユーザー体験を技術的負債の解消よりも優先したい意志がある場合、どのように開発者に向き合わせるか？
- 機能開発をしている人が技術的負債に向き合う経験が重要だと思う。そうすれば、負債を溜めた際のインパクトが実感できて、いい塩梅を保とうとしたり考えが変わるかも知れない
- 時間を区切ってどちらもやってもらうようにする
- まずチームで認識を合わせることが大事
プロダクトミライ会議では改善速度のほうが早いのか？課題が生まれる方が早いのか？
- 溜まり続けるよりも課題が改善する速度のほうが早い。ただ、負債が溜まり続けてはいる。
開発からビジネスサイドへの説明とはどのようなことをしているのか？
- 正直ベース、環境に恵まれていて困ったことはない。ただ、これは普段からコミュニケーションが取れているからこそな気もするので、コミュニケーションを丁寧に取り続けることが大事だと思う
技術的負債活動の実施をどのようにステークホルダーに説明すればいいのか？
- ステークホルダーが理解できる部分で話をする。プログラムの構造などではなく、セキュリティなどの単語をキーワードにして話をすることが重要だと思う。
- 静的解析を他のプロダクトと比較する。
負債を可視化することでエンジニアの満足度は向上したか？
- 周りのエンジニアが一緒に向き合ってくれるという意味では安心感が高まった。ただ、見えない負債はまだまだあると思うので、そこに対する不安は今も感じている。
会全体を通した感想
技術的負債に関して最初に考えるときに出てきそうな課題や欲しくなる知識が一つのイベントでほぼ網羅されていて、素晴らしいイベントでした。
技術的負債の概念に向き合い始めた人やチームには、今後まずこのイベントのアーカイブを勧めようと思います笑
