感情タグBEST3
Posted by ブクログ
ソフトウェア開発において組織のパフォーマンスを上げるために何が重要かという研究のまとめ本。
会社で偉い人を説得するのに使えるとても良い材料になりそう。
この本の内容について語ったり考察してるブログやポッドキャストがたくさんあって、そういったものを通じて理解を深めることができるのかまた良かった。
Posted by ブクログ
ソフトウェアや組織をどのように計測するのか、それぞれの値がどのように関係しているのか、が書かれた本
2014年から今まで毎年レポートを行っており、その一部が収録されている
現代においてこの本を読まなければ、ソフトウェア開発について会話ができないと思っても良い、というレベルの一冊
Posted by ブクログ
唯一言える注意点は、16章が重い！w
ここがメインコンテンツで、それ以外は言葉や前提を共有するための前菜なんだと思います。
その分、重い内容でも理解しやすく、コードだけでないレガシーなシステムに立ち向かう身としては、すごく実践的で、ここを起点に開発組織を改善していこうと思いました。
【A書評】
- CDに向けて基盤となる仕組みを早急に用意する
- 組織としてパフォーマンス計測ができるよう準備する
Posted by ブクログ
Four Keysの元となった書籍。アンケート調査からパフォーマンスの良い組織の特徴を丁寧に説明している。話の盛り上がりとかは特に無いが、各指標値が開発組織の状態を表していることはよく理解できた。
Posted by ブクログ
リーンとDevOpsのケイパビリティが組織とソフトウェアデリバリのパフォーマンスを押し上げるということをアンケートと統計的手法による調査と分析に基づいて説明している。
組織及びチームが高いパフォーマンスを創出するために、その文化を如何に作るかがカギ。学びの組織文化とリーダーシップが大いに関係する。
経営管理（リーダーシップ、組織文化、マトリクス組織、リエゾン担当者、権限移譲、動機付け、目標管理、評価制度等々）に関心のある人にも読める本。
深い技術的知識は不要だけど、DevOpsの知識を補いたい人は他の文献をあたる必要があるかも。
Posted by ブクログ
開発組織の改善にはどんな手法や研究がされているのか気になり手に取りました。
散発的にプロジェクトへ参加して開発作業を行うこととは違う継続したサービス提供のためのアクションについて理解を深めることができました。
組織の課題を知るために過去の実績や障害を知ること。
組織の現在を知るための計測を行うこと。
組織の未来を得るために人が障壁になっているプロセスを置き換え委譲を行うこと。
不確実性は何かを把握し、分割を試みる。
自分から考え行動し、貢献を行うことが求められて少数では足並みを揃えることができないことを意識して少しずつ活動をしていきたいと思いました。
Posted by ブクログ
■パフォーマンスの良好な組織とそうでない組織の比較
・コードのデプロイ頻度は46倍
・コミットからデプロイまでのリードタイムは1/440
・変更復旧時間（稼働停止から復旧に要する時間）は1/170
・変更失敗率は1/5
■有益で質の良い情報
1．受け手が解消したいと思っている疑問に対し、答えをもたらしてくれる
2．適切なタイミングで伝達される
3．受け手が有効に使えるようなやり方で提示される
■継続的デリバリとは？
・「品質」の概念を生産工程の最初から組み込んでいく
・作業はバッチ処理で進める
・反復作業はコンピュータに任せて人間は問題解決に当たる
・徹底した改善努力を継続的に行う
・全員が責任を担う
■継続的デリバリを実践するために必要な基盤整備
・包括的な構成管理
・継続的インテグレーション
・継続的テスト
■継続的デリバリの効果
・アプリケーションコード、システムコンフィギュレーション、アプリケーションコンフィギュレーション、ビルドスクリプト、コンフィギュレーションスクリプトに対するバージョン管理
・信頼性が高く、修正が容易で、定期的に実行される、包括的なテストの自動化
・デプロイメントの自動化
・継続的インテグレーション
・情報セキュリティのシフトレフト（時間軸上左へ移す、つまり、従来よりも早い段階から実施する）
・「寿命」の長い機能ブランチではなくトランクをベースにした開発
・テストデータの効果的な管理
■継続的デリバリの促進要因
・バージョン管理
・デプロイメントの自動化
・継続的インテグレーション
・トランクベースの開発
・テストの自動化
・テストデータの管理
・情報セキュリティのシフトレフト
・疎結合アーキテクチャ
・権限をもつチーム
・モニタリング
・プロアクティブ（予防的）な通知
■ハイパフォーマーである可能性が高い要素
・テストの大半を、統合環境を必要とせずに実施できる
・アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる（そして実際にもデプロイまたはリリースしている）
・チーム外の人物の許可を得なくても、対象システムに大幅な変更を加えられる
・対象システムの変更作業で他チームに頼ったり、他チームに相当量の作業を課したりすることなく、対象システムに大幅な変更を加えられる
・チーム外の人々とやり取りしたり協働したりすることなく作業を完遂できる
・ソフトウェア製品やサービスを、それが依存する他のサービスに関係なく、オンデマンドでデプロイ、リリースできる
・統合テスト環境を必要とせずに、オンデマンドでテストの大半を実施できる
・デプロイメントを、無視できるほどわずかな稼働停止時間のみで、通常の勤務時間内に完了できる
■コンウェイの法則と逆コンウェイの法則
チーム間のコミュニケーションの状態とシステムアーキテクチャとのこのような関係を最初に論じたのは米国のコンピュータ草創期のプログラマーMelvin Conwayであり、具体的にはこう述べた―「システムを設計する組織は〈中略〉その組織のコミュニケーション構造を反映した設計しか生み出せないという制約に縛られる」。これに対して我々の調査研究では「逆コンウェイ戦略」とも呼ばれる考え方―組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャを実現すべきだ、という考え方―を裏付ける結果が出ている。目指すべきは、「〈チーム間のコミュニケーションをさほど要さずに、設計からデプロイまでの作業を完遂できる能力〉を促進するアーキテクチャを生み出すこと」なのである。
この戦略を可能にするアーキテクチャ面でのアプローチとしては「コンテキスト境界とAPIにより、大規模なドメインを、より小規模、より疎結合なユニットに分割する」「テストダブル（ソフトウェアのテストでテスト対象が依存するコンポーネントを書き換えた代用品）と仮想化により、サービスやコンポーネントを独立した形でテストする」などが挙げられる。この点で、サービス指向のアーキテクチャなら（またマイクロサービスアーキテクチャも、堅固なものであれば）しかるべき成果をあげられるはずである。ただしそうしたアーキテクチャを実現しようとする際には、成果の達成度の厳密なモニタリングが不可欠である。あいにく現実には、サービス指向を謳っているにもかかわらず、独立した形でサービスをテスト・デプロイできず、チームがパフォーマンスを高められない、というアーキテクチャが多い。
もちろんDevOpsのキモはチーム間のより良い協働であり、ここで「チームは協力し合うべきではない」などと説いているわけではない。疎結合のアーキテクチャの目的は「組織内でのコミュニケーションの処理能力を、実装レベルの細かな意思決定に関するやり取りで使い切ったりせず、より高次な共通の目標やその達成方法に関する議論に使えるようにすること」なのである。
■重要なのは、チームが他のチームやシステムに依存せずに製品やサービスに変更を加えられることである。
■リーンマネジメントのプラクティス
１．進行中の作業（WIP:Work in Progress）を制限することでプロセスの改善とスループットの増大を図る
２．品質と生産性に関する重要な数値指標と、（不具合も含めた）作業の現況とを一覧できるビジュアライズディスプレイを作成・継続管理する。エンジニアも管理者もビジュアルディスプレイを利用できるようにし、提示されている数値指標を経営目標に追従させるよう努力を重ねる
３．アプリケーションのパフォーマンスとインフラのモニタリングツールから得たデータに基づいて、日常レベルのビジネス上の意思決定を行う
■リーン製品開発のプラクティス
１．１週間未満で製品と機能を完成して頻繁にリリースできるよう、関連作業を細分化して進める能力
２．開発の最初期から顧客関連業務に至る作業フロー全体に対するチームの理解度と、（製品や機能の状況も含めて）このフローの可視化の度合い
３．組織が顧客フィードバックを積極的・定期的に収集し、それを製品デザインに盛り込む能力
４．承認不要な開発プロセスの一部として、開発チームが有する、製品仕様の作成・変更権限
■変革型リーダーシップ
・ビジョン形成力
・心に響くコミュニケーション能力
・知的刺激
・支援的リーダーシップ
・個人に対する評価
A.1 継続的デリバリの促進効果が高いケイバビリティ
1.本番環境のすべての成果物をバージョン管理システムで管理
GitHubやSubversionなどのバージョン管理を利用して､アプリケーションのコードやコンフィギュレーション、システムのコンフィギュレーション、本番環境のビルドやコンフィギュレーションを自動化するためのスクリプトなど、本番環境のすべての成果物を管理するケイバビリティである。第4章を参照。
2.デプロイメントプロセスの自動化
デプロイの完全自動化(手作業による介入が不要な状態) の実現の度合いである。第4章を参照。
3.継続的インテグレーションの実装
継続的インテグレーション(Continuous Integration: C1)は継続的デリバリの実現に向けての第一歩である。CIとは「コードに定期的にチェックインし、チェックインのたびに重大な不具合を発見するための迅速なテストがトリガーされ、不具合が見つかれば開発者が直ちに修正する」という開発のプラクティスである。このプロセスによって正規化されたビルドとバッケージを作成にデプロイ、リリースする。第4章を参照。
4.トランクベースの開発手法の実践
トランクベースの開発は､ ソフトウェアのデプロイとデリバリにおけるパフォーマンスの予測要因となりうることが立証されている｡特徴は「コードリポジトリでアクティブなブランチの3つ未満」「統合前のブランチとフォークの『寿命』は非常に短い(たとえば1日未満)」「アプリケーション担当チームが統合の際のコンフリクトやコードフリーズ、スタビライゼーションのためにコードへのチェックインやプルリクエストをストップする『コードロック』の期間がほとんどあるいはまったくない」などである。第4章を参照。
5.テストの自動化
ソフトウェアのテストが開発プロセス全般にわたって継続的に(手作業ではなく)自動的に行われる、というプラクティスである。効果的なテストスイートは信頼性が高い。本当の不具合を探知し、リリース可能なコードだけをパスさせる｡ 留意すべき点は「自動化テストスイートの作成と管理の主な責任を負うのは開発者」ということである。第4章を参照。
6.テストデータの管理
テストデータは慎重に管理しなければならず、テストの自動化においてはテストデータの管理の重要性が増しつつある｡ 効果的なプラクティスとしては「使用しているテストスイートに適したデータを入手する」「必要なデータをオンデマンドで入手できる」「自組織のパイプラインでテストデータを調整できる」「実施できるテストの量がデータによって制限されてしまわない」などが挙げられる。ただし、自動化テストを行うのに 必要なテストデータの量は常に極力少なくするべきである。第4章を参照。
7.情報セキュリティのシフトレフト
情報セキュリティ関連の作業を設計段階とテスト段階に組み込むことも、パフォーマンス向上の重要なカギである。具体的には「アプリケーションの情報セキュリティ関連のレビューを実施する」「情報セキュリティ担当チームをアプリケーションの設計段階からデモ段階までの全工程に参画させる」「事前に承認された情報セキュリティ関連のライブラリとパッケージを使う」「セキュリティ関連機能のテストも自動化テストスイートの一部にする」といったプラクティスが挙げられる。第6章を参照。
8.継続的デリバリ (CD) の実践
継続的デリバリとは「ソフトウェアを、ライフサイクル全体にわたってデプロイ可能な状態で維持する」という開発プラクティスのことで、チームはこのデプロイ可能な状態の維持を、新機能の追加よりも優先する。このプラクティスを実践すれば、チームのメンバー全員がシステムの質とデプロイ可能性に関するフィードバックを素早く入手できるので､デプロイ不能との報告を受ければ直ちに修正できる。また、本番環境へのデプロイヤエンドユーザーへのデプロイもオンデマンドで行える。第4章を参照。
A.2 アーキテクチャ関連のケイパビリティ
9.疎結合のアーキテクチャ
チームがアプリケーションのテストやデプロイを、他部署との調整を要さずにオンデマンドで、どの程 度実施できるかは、アーキテクチャの結合の度合いによって決まる。アーキテクチャが結合であれば、チームは他チームの支援や協力に頼らず独立した形で作業を進められ、それによりチームの迅速な作業と組織への価値提供とが可能になる。第5章を参照。
10.チームへのツール選択権限の付与
本研究では 「ツールを選ぶ権限を与えられているチームのほうが継続的デリバリの能力が高く、それがソフトウェアの開発とデリパリのパフォーマンスを高める」との結果が出ている。チームの効率を上げるのに必要なものは何かを一番よく知っているのは現場担当者である。第5章を参照(製品管理の領域におけるチームの権限については第8章を参照)。
A.3 製品・プロセス関連のケイパビリティ
11.顧客フィードバックの収集と活用
本研究で「顧客に関するフィードバックの定期的な収集と、製品設計におけるその活用に対して、組織が積極的であるか否かが、ソフトウェアデリバリのパフォーマンスを大きく左右する」との結果が出ている。第8章を参照。
12. 全業務プロセスの作業フローの可視化
チームにとっては､ 製品の開発段階から顧客対応段階に至る全業務プロセスの作業フロー(ならびに製品や機能の現況)の可視化とその十分な理解が必須である。本研究で、このケイバビリティがパフォーマンスを大きく左右することが立証されている。第8章を参照。
13. 作業の細分化
作業は1週間未満で完成できるよう、細分化する必要がある。コツは「ブランチを使って複雑な機能を開発し低頻度でリリースするのではなく、迅速な開発が可能な機能に細分化する」というものである。この手法は機能レベルでも製品レベルでも応用できる(たとえばMVP [実用最小限の製品］を利用するのも1つの方法。MVPとは製品自体とそのビジネスモデルの「検証による学び」が可能な規模の機能だけから成るプロトタイプのことである)。作業をこうして細分化して進めれば、リードタイムもフィードバックループも短縮できる。第8章を参照。
14. チームによる実験の奨励・実現
チームによる実験とは、 開発者が開発プロセスにおいて、チーム外の人々の承認を得なくても新たなアイデアを試したり、仕様を更新したりできる能力を指す。このケイパビリティを強化すれば、チームは革新を迅速に実現し、価値を創出できる。特に「作業を細分化して進める｣「顧客フィードバックを製品設計に盛り込む」「作業フローを可視化する」といった他のケイバビリティと並行して強化すると効果が高まる。第8章を参照(このケイバビリティの技術面に関しては第4章を参照)。
A.4 リーン思考に即した管理・監視に関わるケイパビリティ
15. 負担の軽い変更承認プロセス
本調査研究で「チーム外の変更諸問委員会(CAB：change advisory board) のレビューを義務付けるより、(ペアプログラミングやチーム内でのコードレビューなど)ペアレビューをベースにしたライトウェイトな変更承認プロセスを確立したほうが、パフォーマンスが高まる」との結果が出ている。第7章を参照。
16. 事業上の意思決定における､ アプリケーションとインフラの監視結果の活用
事業レベルの作業に関する意思決定で、アプリケーションとインフラのモニタリングツールから得たデータを活かす能力。プラクティスとしては「問題が発生したら担当者を呼び出す」というやり方よりも優れている。第7章を参照。
17. システムの健全性のプロアクティブ(予防的)なチェック
しきい値警告と変化率警告に基づいてシステムの健全性を重視し、問題の予防的な探知と軽減を図る能力。第13章を参照。
18. WIP制限によるプロセス改善と作業管理
進行中の作業(WIP: Work in Progress)を制限して作業フローを管理するというのは、リーン思考の実践コミュニティではおなじみの手法である。効果的に実践すれば、プロセスの改善、スループットの増大、システムにおける制約の可視化がれる。第7章を参照。
19. 作業の可視化による、品質の監視とチーム内コミュニケーションの促進
ダッシュボードや内部Webサイトなどのビジュアルディスプレイを品質やWIPの監視に活用すると、ソフトウェアデリバリのパフォーマンスが向上することが立証されている。第7章を参照。
A.5 組織文化に関わるケイパビリティ
20. (Westrum推奨) 創造的な組織文化の育成
これは本研究で採用した組織文化の測定基準であり、航空や保健医療などきわめて複雑で高リスクな領域のシステムを専門に研究を重ねた社会学者Ron Westrumが提唱したモデルを下敷きにしている。そして 本調査研究では｢この確定基準で､ チームと組織全体のパフォーマンスを予測できるほか、燃え尽き症候群の軽減効果も予測できる ｢こと」が判明している｡ 具体的にこの基準で測定できるのは、情報の流れ、協働・信頼関係、チーム間の仲介などのレベルである。第3章を参照｡
21.学びの奨励と支援
自組織は、継続的な進歩を遂げる上で、「学び」を必須の要素と捉えているか｡ 学習を「犠牲」と受け止めているか、それとも「投資」と考えているのか。これが組織の「学び」の文化を測る基準である。第11章を参照。
22.チーム間の協働の支援と促進
従来、チーム同士は「縦割り」の関係にあったが、それをどの程度脱却し、開発・運用・情報セキュリティの領域を果たせているのかについて、そのレベルを反映するケイバビリティである。第3章および第5章を参照。
23.有意義な仕事を可能にするツール等の資源の提供
職務満足度の予測要因となりうるケイパビリティである。強化のキモは「各構成員が困難でも有意義でやりがいのある仕事ができ、自身のスキルを活かし判断力を働かせる権限を与えられること｣「各構成員 が、職務を全うするのに必要なツール等の資源を与えられること」である。第10章を参照。
24.改善を推進するリーダーシップの実現や支援
改善を推進するリーダーシップとは、DevOpsの実践に不可欠な技術的作業とプロセス関連作業を支援・増強するもので、次の5つの要素から成る - 「ビジョン」「知的刺激」「心に響くコミュニケーション」 「支援を重視するリーダーシップ」「個人に対する評価」。第11章を参照。
