コードのオーナーシップ
>@t_wada: "すべてはオーナーシップ" "システム運用の責務は開発チームに帰属すべきもの" "開発者が「コードを書いたら終わり、運用は誰かがやってくれる」というマインドセットでは、品質の高いコードやサービスは生まれません" / “カミナシ社の執行役員 CTO に就任しました｜Tori H…” https://t.co/DdsWdsR9wJ
>@t_wada: "経験上、優れたサービスを作るチームには、そのサービスに対する強いオーナーシップが明確に存在します。そのサービスを良くしていくのは自分たちなんだという認識と自覚、責任感なしには、優れたサービスを作ることが難しい"
>@t_wada: "品質の低いコードを書いたことで自らがページングされる、あるいはそのようなコードに起因して困っているお客様と真摯に向き合うことで、はじめて製品の品質に対してオーナーシップを持てるようになります"
>@t_wada: "品質の低いコードを書いたことで自らがページングされる、あるいはそのようなコードに起因して困っているお客様と真摯に向き合うことで、はじめて製品の品質に対してオーナーシップを持てるようになります"
>これらの安易なチーム化によって、結果として開発者に「XXX は自分たちではない誰かがやってくれる」と考えさせてしまうような組織設計をとることも、現在のカミナシにおいて必要なオーナーシップが損なわれかねない誤った選択"
>@t_wada: "優れたサービスを提供するためには、これらの重要なファンクションがすべて開発チームに内包され、外部チームに依存することなく、サービス提供のために自律的に動ける状態こそが理想"
>@t_wada: "継続的な改善を前提としたプロダクトを外注で作る難易度が高いと言われがちなのには、発注者と受託者の間でオーナーシップの所在が不明瞭になりやすいところにもその理由がある"
コードのオーナーシップが欠如する要因はまあ色々あるがほとんどのケースは「チームの体制や構造上の問題を抱えていて、なるべくしてなる」
トレードオフスライダーが崩壊した締め切り駆動開発
無作為なアサイン計画
責任境界が曖昧な開発組織
外部の委託業者による引き継ぎ不足やコピペの横行
とにかくベロシティをあげることが目標になってる
クリエイティブチーム, イネイブリングチームとの社内受託状態
誰かが負債を生み出したとして、それを返済するのが別の人という構図が出来上がる
負の悪循環で至るところに水漏れ, 割れ窓ができあがる
納期や外部品質ばかりを評価指標にするとクリーンなコードを書いて予防することはあまり評価されない
チームの規模を小さくして、DEV Teamが外部仕様を固めるプロセスにどれだけ介入できるか、が大事だなと思う
具体的にはどうすればいいんだろうね？
プロダクトをどうやって作り、どうリリースしてどう改善していきたいかに依る
プロダクトオーナーやエンジニアリングマネージャーなどがなんらかの方向性を示すべき
メンバーがボトムアップにできることは限られる
自分達の領域にオーナーシップを持てるような外発的な動機を作る
フィーチャーチームでチームを小さくする
一つの機能でも良いので、自分で開発したものを自分で運用するという経験や場を作る
フィードバックループをまわせるようにユーザーが見えるような仕組みを作る
トレードオフスライダーを作る
締め切り駆動開発をやめる