nikkie-ftnextの日記

イベントレポートや読書メモを発信

イベントレポート | mtx2sさんの講演「技術的負債が開発者体験を悪化させる」、素晴らしかったです👏👏👏 #Techmee

イベントレポート 設計

はじめに

はちみー、はちみー、はっちっみー♪ nikkieです。

12/21(水)に「技術的負債の返済から改善する開発者体験 - Techmee vol.5」がオンライン開催されました。
mtx2sさんのゲスト講演が気になりそこだけ参加したのですが、これがものすっごくよかったのです👏
まとめるにあたってアーカイブを見返し、胸中に色々な思いが去来したのですが、まず今回はどんなトークだったかをまとめます。

なお「開発者体験」がTwitterトレンド入りするほど反響しているようです。

目次

勉強会の概要

技術的負債の返済から改善する開発者体験 - Techmee vol.5 - connpass

「一人ひとりの時間を豊かに」を掲げるタイミーが発信するTech勉強会

第5回目は技術的負債が開発組織に及ぼす影響と具体的にどの様に技術的負債を返済していくのかを共有する勉強会です。

今回は「技術的負債は開発者体験を悪化させる（332はてブ）」や「エンジニアリングスキルで捉えるチームマネジメント（532はてブ）」のブログを執筆し、質の高いアウトプットを継続されているmtx2s氏をお招きして技術的負債が開発組織や開発者体験に与える影響を語っていただきます。

アーカイブ（みんなぜひ見て！！）

mtx2sさんの講演は5:09くらいから始まります。

タイミーのエンジニアの方の発表やQ&Aは積ん読（積ん録？）です（早めに見たいな）。

「技術的負債が開発者体験を悪化させる」

発表資料

1年前のブログでも「技術的負債が開発者体験を悪化させる」を取り上げられています。
こちらをベースとした発表という印象でした。

アーカイブを見る前にブログに目を通しておくと、「これ、ブログ版で見たところだーー！！！」ってなります（N=1）。

アジェンダは以下

  • 2つの体験の似た特徴
  • 振る舞いの価値、構造の価値
  • 無謀な開発による悪循環
  • 無謀な負債、慎重な負債
  • ユーザ体験と開発者体験の決定的に違う点

注目したきっかけ

こちらのツイートがきっかけです。

mtx2sさんは存じ上げなかったのですが、「万難を排して参加したい」と見て、これはリアルタイムで聞いたほうがいいやつだなと心が決まりました。

自分の言葉でまとめてみると

この講演は、体験が悪いと離反するという点で、開発者体験とユーザ体験は似ているという話から始まります。
書籍やブログ記事などにあたって「技術的負債」を整理していき、最後はこれら2つの体験の決定的な違いに言及します。
決定的な違いとは、「開発者体験をよくできるのは開発者自身」という点です。

開発者は技術的負債に「真正面から向き合う」「懸命に闘う1」必要がある。
そのための武器（向き合う対象である技術的負債の整理）をこの講演で授かった感覚です。
その武器がこちら、2つの軸「意図的／無自覚」「無謀／慎重」で技術的負債を4象限に分け、それらへのアプローチを提言しています。

「技術的負債が開発者体験を悪化させる」で参照された資料を追いかける

私は一次情報を取りに行きたくなっちゃうたちなので、ブログ版も参照して参照先を見に行きました。

『レガシーコード改善ガイド』

言及されたのは2つ

  • はじめに：技術的負債が蓄積したコードに感じるネガティブな感情の例2
  • 第1章　ソフトウェアの変更
    • ソフトウェアの変更理由4つが提示される（1.1）
    • 1.1.4の表（4つの変更の比較）を参照
    • 「振る舞い」と「構造」（『レガシーコード改善ガイド』では設計）の導入

『Clean Architecture』

https://asciidwango.jp/post/176293765750/clean-architecture

第2章と第15章が言及されます。
どちらの章も「振る舞いより構造の方が価値が大きい」というUncle Bobの主張が引用されます3。

「The (missing) value of software architecture」（Philippe Kruchten）

価値については、「ボジティブ／ネガティブ」「見える／見えない」の2軸（4象限）で整理されます。

価値の「見える／見えない」軸について

  • 「見える」は「振る舞い」
    • ユーザ体験に影響
  • 「見えない」は「構造」
    • 開発者体験に影響

と対応します

ユーザー体験も開発者体験もボロボロに（無謀な開発による悪循環）

（ここは話の流れの紹介です。一次情報の紹介はありません）

TechnicalDebtQuadrant（マーティン・ファウラー）

マーティン・ファウラーの技術的負債の4象限が参照されました。
自分の言葉でまとめたところでも言及した、「意図的／無自覚」「無謀／慎重」の2軸による4象限です。

  1. 無自覚・無謀＝知識不足・スキル不足
  2. 意図的・無謀＝クイック&ダーティー
  3. 意図的・慎重＝実験や試行錯誤
  4. 無自覚・慎重＝知識の大きな乖離
    • 3と4は学びによる負債

クイック&ダーティー（2. 意図的・無謀 の象限）

品質と引き換えにスピードを得ようとする姿勢です。
これはt-wadaさんの「質とスピード」でも引き換えではないと指摘されている話ですね。

design payoff line（クイック&ダーティーをちゃんと設計するが上回る）のは1ヶ月以内という話もありました。

実験や試行錯誤（3. 意図的・慎重 の象限）

Henrik Kniberg氏のブログを引いて、悪い負債と良い負債という概念が導入されます。

old debt is bad and new debt is good.

これを受けて、この講演のタイトルは「悪い技術的負債が開発者体験を悪化させる」と改訂されます。

知識の大きな乖離（4. 無自覚・慎重 の象限）

これは「今になって設計がどうあるべきか悟った」という後から気付くパターン。
「負債という概念の生みの親のウォード・カニンガムの定義に近い」領域とも話されていました（28:35）。

思い出したのがこちらのエントリ

「もしも自分たちが書いているプログラム（WyCash）を、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、自分たちは絶えずその不一致につまずき続けることになり、開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです」と説明したのです。

自分たちの理解とソフトウェアが一致していない状態（「不一致につまずき続ける」）が負債、たしかに4の象限と近いですね。

4の解決策はリアーキテクティング、不一致の解決は開発者だけでは難しいというのも納得感があります。

資料の追いかけは以上です。

終わりに

mtx2sさんの講演について、参照された資料を集める形でレポートしました。
アーカイブやスライドを見返し、参照された書籍やブログもざっと確認しましたが、いろいろな知識を束ねられて技術的負債に向き合う知見として発信されていることに畏敬の念を感じます。
発表、ありがとうございました。

Twitterで話題になっていますが、30分のタイムボックスを確保してアーカイブを見るのが非常にオススメです。
情報量が豊富ですし、資料にない話もあります。
数年に渡ってデブサミとかで繰り返し話されうる発表だと思いました。
たしかに研修にしたいですね。

タイミーさん、勉強会の開催ありがとうございます。
また参加者の皆さまもありがとうございました。

近日中に予定している「考えたこと編」でお会いしましょう。

  1. ↩
  2. ↩
  3. ↩