変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
- 作者: Gary Gruver,Tommy Mouser,吉羽龍太郎,原田騎郎
- 出版社/メーカー: 技術評論社
- 発売日: 2017/01/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
だいぶ前に読んでいた本ですが、まとめてみました。
この本はどんな本か？
HPのプリンタでのファームウェア開発における事例をもとに、巨大な組織でハードウェアが絡む製品開発をアジャイルに進めるやり方を紹介した本です。
他のアジャイル本と比較して上位の経営幹部向けだと感じました。DeoOpsなど実践に関する説明は少ないです。
大組織におけるソフトウェア開発の変革
既存の大組織の多くがソフトウェア開発・デリバリーに苦しんでいる。 その結果、市場で競争したり、ソフトウェアでイノベーションを起こすことが困難になってきている。
大企業でソフトウェア開発を変革するには、チーム同士が協力し価値を生み出す仕組みづくりをまず考える。 それぞれのチームの働き方はその次である。
経営幹部が主導する
単にアジャイルに取り組むことを目的にしない。
エンタープライズレベルの継続的改善プロセスは経営幹部が作る必要がる。 なぜならば組織内のリソースを割り当てられる唯一の存在であり、バリューチェーンの端から橋までを見ることができるからである。
経営幹部はエンタープライズレベルで計画を推進し、進捗を把握できる戦略的な目標を設定する。
- 通常4〜7個の上位目標
- 測定可能な小項目
経営幹部は組織全体と共同して目標を設定し、この目標が重要であり達成可能だと全員が感じられるようにする。
アジャイルに取り組むための「正しい方法」を決めてしまうと、次にその正しい方法を全員に教えなければと思い始めてしまう。 リーダーとして、可能な限り目標ととともにフレームワークを提供し、仕事の進め方に関しては最大限の裁量をチームに与えることが重要である。 これによってチームは仕事により興味を覚え、結果に対するオーナーシップを高めることになる。
ビジネス目標を設定し、継続的改善プロセスを実施し続けることで、経営幹部やマネージャーを巻き込み、彼らに変革をリードさせる。 組織全体にわたる計画プロセスやデリバリープロセスの改善に注力する。
頻繁に結合する文化を作る
ブランチを切らず、全員がメインブランチで開発を進める。これにより頻繁な統合を促すことができる。 メインブランチで開発するにはテクニックが必要である。
- 既存のコードを壊す変更を実装しない。
- 既存の機能を壊すことなく、コードの大規模なリファクタリングを可能にする。
- フィーチャーフラグなどを導入し、新しいコードをコミットしつつ、システムの他の部分からは使わせない。
- 既存の機能を壊さずにデータベースのスキーマを変更する。
自動テストなどを拡充し、メインブランチは常に安定する状態を保たなければならない。
- コードをコミットする際、自動化された受入テストに合格するまでその場を離れてはいけない
- 壊れたビルドに続けてコードをコミットしてはならない。
