コードのオーナーシップ
@t_wada: "技術的負債というのは継続的に返済されていくべきものです。プロジェクト化しなければならないほどに負債を溜め込んでしまうことがそもそも誤っている" "SaaSのような継続的進化を前提とするビジネスモデルをとる企業にとっては、これはエンジニアリングだけではなく誰しもが共通認識として持つべき" @t_wada: "経験上、優れたサービスを作るチームには、そのサービスに対する強いオーナーシップが明確に存在します。そのサービスを良くしていくのは自分たちなんだという認識と自覚、責任感なしには、優れたサービスを作ることが難しい" @t_wada: "品質の低いコードを書いたことで自らがページングされる、あるいはそのようなコードに起因して困っているお客様と真摯に向き合うことで、はじめて製品の品質に対してオーナーシップを持てるようになります" @t_wada: "品質の低いコードを書いたことで自らがページングされる、あるいはそのようなコードに起因して困っているお客様と真摯に向き合うことで、はじめて製品の品質に対してオーナーシップを持てるようになります" これらの安易なチーム化によって、結果として開発者に「XXX は自分たちではない誰かがやってくれる」と考えさせてしまうような組織設計をとることも、現在のカミナシにおいて必要なオーナーシップが損なわれかねない誤った選択"
@t_wada: "優れたサービスを提供するためには、これらの重要なファンクションがすべて開発チームに内包され、外部チームに依存することなく、サービス提供のために自律的に動ける状態こそが理想" @t_wada: "継続的な改善を前提としたプロダクトを外注で作る難易度が高いと言われがちなのには、発注者と受託者の間でオーナーシップの所在が不明瞭になりやすいところにもその理由がある" https://scrapbox.io/files/6406c5d3ba8961001bab2a9a.png
koushisa.icon
コードのオーナーシップが欠如する要因はまあ色々あるがほとんどのケースは「チームの体制や構造上の問題を抱えていて、なるべくしてなる」
無作為なアサイン計画
外部の委託業者による引き継ぎ不足やコピペの横行
とにかくベロシティをあげることが目標になってる
誰かが負債を生み出したとして、それを返済するのが別の人という構図が出来上がる
納期や外部品質ばかりを評価指標にするとクリーンなコードを書いて予防することはあまり評価されない
チームの規模を小さくして、DEV Teamが外部仕様を固めるプロセスにどれだけ介入できるか、が大事だなと思う 具体的にはどうすればいいんだろうね？
プロダクトをどうやって作り、どうリリースしてどう改善していきたいかに依る
プロダクトオーナーやエンジニアリングマネージャーなどがなんらかの方向性を示すべき
メンバーがボトムアップにできることは限られる
一つの機能でも良いので、自分で開発したものを自分で運用するという経験や場を作る