AdidasのIT部門がベンダー管理部門からエンジニアリング部門に変化した話
Adidasは元々IT部門が小さく、開発はベンダーがやっていて自分たちはベンダー管理をしていた。そこからどうやってエンジニアリング部門になったのか。
お話をされている方がプラットフォームエンジニアリングのVPとディレクターの方なのでだいぶハイレベルの話ですが、とてもいい話でした。
この動画はコンウェイの法則と逆コンウェイの法則の情報収集をして見つけた本、Team Topologiesを読んでいてちらっと紹介されていました。こちらは後でまたまとめます。
元々AdidasのITはどんなチームだったか
- コストセンター
- 一つのベンダーがほとんどのソフトウェアを作っていて、頻繁なハンドオーバーが発生してプロセス的に効率的じゃなかった
- IT部門は数人で開発ではなく管理をしていた
(Team Topologiesの記述より)
こんなKPIをトラッキングしていた。動画 (8:50くらい) から引用。
- コミットしたストーリーポイントのうちどの程度デリバリできたか
- 不具合 (Defect) の割合
- コード品質
- ベンダーごとFTR (真ん中下の黒いグラフ、おそらくFailure to Return、差し戻し率かな)
スクラムであろうとこれはベンダー側はリスク積みますね。
変化させたこと
- 社内の開発リソースを増やした。
- 逆コンウェイの法則を意識して組織を設計し直した。
- メトリックの取り方を、ソフトウェアのデリバリパフォーマンスから組織のパフォーマンスに変えた
- ベンダーを「パートナー」とした。
KPI。動画 (30:28) から引用。
- ビルドにかかる所要時間
- ビルドステータス
- コミット頻度 (が2つある)
タイトルの DevOps over Coffee は今のやり方を変えることをCxOに了承してもらうためにコーヒーを飲みながらエンジニア8人と一緒にミーティングを実施したことに由来するようです。
データ！データ！データ！
データへのこだわりがとてもよくわかる。
アスリートは自分のパフォーマンスを必ずストップウォッチなどのデータで計測している。自分たちもデータで計測するべきだ。
とか
以下の動画で過去にはアスリートと対話をすることで良い製品を作ってきたが、現在はアスリートが遠く、対話をしにくいので、ポケット (モバイルデバイスなど) にいることで消費者との距離の近さを担保しているんだとか。
改善活動にデータが必要というのは同意。変わったのか変わってないのか、そもそもどこに課題があるのか、どういう傾向の課題なのかを把握するときにデータが非常に役に立つので、とても納得感があります。