技術的負債が開発者体験を悪化させる(講演)
開発者体験をよくできるのは開発者自身
ユーザ体験とは違う
技術的負債に「真正面から向き合う」「懸命に闘う」
そのための武器(技術的負債にまつわる整理)を授けられた印象
「意図的/無自覚」「無謀/慎重」の2軸・4象限による整理(slide=85)
向き合う(slide=90)
無謀な開発の悪循環から抜け出す(象限(1)(2))
常に最善を尽くす(象限(3))
ステークホルダーの理解を得る(象限(4))
引用された書籍
冒頭(自己紹介)
理解をするためにコードの整理、コメントを書く経験もされたとのこと
技術的負債は開発者にネガティブな感情を抱かせる
技術的負債ばかりの環境はEmotional costが高い
締切に追われる残業もEmotional costが高い
2つの体験の似た特徴
ユーザー体験、開発者体験
どちらも、優れた体験が得られないと離反する
開発者は退職
どこに転職しても大抵、技術的負債を抱えている
逃げられない
👉 真正面から向き合う
無謀な開発による悪循環
開発者体験が悪化する2つの悪循環(slide=40)
悪循環1つ目
(時間に対するプレッシャー)
技術的負債の増加
開発速度の低下
プレッシャーが高まって、再度の無謀な開発
別の悪循環
無謀な開発が蓄積された中での振る舞いの変更
欠陥の修正に追われる。気づかなかったものは障害となる
手元の開発を止めて、欠陥・障害対応へ。開発速度の低下
プレッシャーが高まって、再度の無謀な開発
バックログアイテムの4象限のうちネガティブな2象限の対応に追われる(slide=41)
技術的負債の増加(見えない・ネガティブ)
欠陥・障害の増加(見える・ネガティブ)
ユーザ体験も悪化している
ユーザ体験と開発者体験の決定的に違う点
体験をすぐれたものにするのは
ユーザ体験はプロダクトの提供者
開発者体験は開発者
開発者自身で解決
技術的負債に向き合う
開発者自身でコントロールできるもの
考えたこと
データサイエンスも同じ構造ではないか
見える価値(例:レポート)に特化している。でも本当にそれでいいのだろうか?
(2)クイック&ダーティーが個人的な感覚としてちょっと耐えられない
(1)スキル不足・知識不足のためにクイック&ダーティーになっていることもある?