なかなかの良い本であった。
世の中でLeanとかDevOpsとか言われているが、実際のところどうなのか？
みたいなところが、計測をもとに網羅的に紹介されている。
網羅的なのでチェックリストというか指針として使えるなと思う。
CI環境を整えるとか、継続にdeployし続けるとか、ある意味では当たり前のことが言われているわけだが、セキュリティチェックを開発プロセスに組み込んで、毎回やるほうが効率がいいことがわかったとかは、なかなかおもしろかった。
最後の方の結果に関しては、全体的にここにメモを載せておく
組織モデル。これはユニコーン企業の秘密にもあった構造だ。たぶんもう業界標準。
チーム、マネジメント、リーダーシップのそれぞれについて、高いパフォーマンスを生む行動とプラクティスの一覧
1. 本番環境のすべての成果物をバージョン管理システムで管理 GitHubやSubversionなどのバージョン管理を利用して、 アプリ ケーションのコードやコンフィギュレーション、システムのコン フィギュレーション、本番環境のビルドやコンフィギュレーショ ンを自動化するためのスクリプトなど、本番環境のすべての成果 物を管理するケイパビリティである。 第4章を参照。
2. デプロイメントプロセスの自動化 デプロイの完全自動化 (手 作業による介入が不要な状態) の実現の度合いである。 第4章を参 照。
3. 継続的インテグレーションの実装 継続的インテグレーショ ン (Continuous Integration: CI)は継続的デリバリの実現に向 けての第一歩である。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章
0 件のコメント:
コメントを投稿