スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている|s_semiya
#アジャイル #スクラム
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている|s_semiya
プロバスケチームのように密なチームワークで最高のパフォーマンスを出すチームでいきなり一人抜けると、パフォーマンスがガタガタになる。
プロチームなのにキャッチボールも出来ない人が入ってきたら困る
勝敗関係なく、試合の後に美味しいビールを飲むこと
界隈の今ホットな話題はチームトポロジーで扱うような「頻繁なアーキテクチャの変更」に対してメンバーを機動的に配置できないならどうすんだよ、という話です。
頻繁なアーキテクチャの変更に対してメンバーを機動的に配置できないならどうすんだよ
業務委託エンジニアと直接雇用エンジニアの最大の違い
人事権です。進退権と言い換えてもいいかもしれません。
直接雇用エンジニアはメンバーをチームに残すか、あるいは退場させるかはその会社が決めます。
業務委託エンジニアは会社が決められません。
するとどうなる?
高いパフォーマンスを出しているスクラム開発チームがあったとします。
うちメンバーの1人は業務委託契約です。
(エンジニア個人と契約しているのか、SESで派遣されているのかはここでは考慮しません)
そうこうしているうちに契約更新の時期が来ました。
「単価20%アップを要求します。」
まあそうなりますよね。
(実際には単価10万円アップ3回とか10万円アップ+15万円アップとかのコンボだったりします)
機能するスクラム開発チームはメンバーを育てる
前述のプロバスケチームと同じです。
最高のパフォーマンスを生み出すために、チームはメンバーを育てます。
「安易に交換可能な部品」が何人いても高いパフォーマンスを生み出せるチームにならないからです。
またチームが向き合うプロダクトは1つ1つが共通化できない複雑な問題を抱えているため製造業的な「共通規格」「普遍的なスキル」というアプローチも不可能です。
「安易に交換可能な部品」が何人いても高いパフォーマンスを生み出せるチームにならない
内製化するというのは「エンジニアに直接指揮命令したい」需要
俺たちが投下した教育コストはなんだったんだ
---
スクラム導入には組織の取り組みが必要なことを電車にたとえてわかりやすく説明してみる
スクラムは「開発部門が効率的にシステム開発を行うための手法」というよりも「組織がビジネスとシステム開発の関係性を管理するための手法」
3つの責任
分業すると失われるものがある
コア事業をアウトソースするな