mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。
過去の記事はこちら
- 第1章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）
- 第2章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）
- 第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）
- 第4章：技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）
第5章 アーキテクチャのキーポイント
- ローパフォーマンスになる傾向が強いもの
- 構築中のソフトウェア（ あるいは利用する必要のある一群のサービス）は、他社（外注先など）が開発したカスタムソフトウェアである
- メインフレームのシステムで作業を進めている
- ハイパフォーマーはテスト容易性が担保できていてデプロイ頻度が高い
- 必要なツールをチーム自らが選択できる
- 情報セキュリティの概念をデリバリのプロセスに組み込んでいるチームも継続的デリバリのパフォーマンスが高い
第６章 デリバリライフサイクルに情報セキュリティを組み込む
- 情報セキュリティの対策をソフトウェア開発ライフサイクルの早い段階で対処する場合、デリバリのパフォーマンスに加えてセキュリティの質も上がる
- デリバリパフォーマンスの高い組織では、セキュリティの問題の修正の所要時間が短い
第7章 ソフトウェア管理のプラクティス
- リーンマネジメントのプラクティスには3つの手法がある
- 負担の軽い変更管理プロセス
- 本番環境に対する変更には必ずチーム外の人や組織管理者の承認を得る必要があるチームには、デプロイ頻度、リードタイムサービス復旧時間がいずれも負の相関がある
議論に出たこと
- 「ビジネス側と開発側のチーム間で高次な共通の目標やその達成方法に関する議論をする」というのがもっと必要
- システムは疎結合である必要がある
- アプリケーションの開発環境以外の外部要因でデプロイを阻害する要因は出来るだけ排除したい
- 開発者の人数が増えると生産性が上がるのか
- 必要なツールをチーム自らで選択するにはある程度熟練のエンジニアチームでないと難しいかも
- 既存のものを使い続けるのは安定はしているが技術的に枯れていく
- 新しいツールを選択・実証してダメだった場合に見切りをつけて別のツールに切り替えるという判断をするためには過去様々なツールを使ってきた経験が必要
- マイクロサービスはフェーズ依存や初期設計の難しさはある
- モジュラモノリスから始めるのが良さそう
- デリバリパフォーマンスが高い組織は事前にセキュリティ部分も意識しているという想定
- セキュリティのシフトレフトが出来ている組織はパフォーマンスが高そう
- レビュー待ち時間を長くせず、すぐ完了に持っていく努力をするべきと感じる
- レビュープロセスの高速化は開発とレビューを同時に行えるペアプロやモブプロがオススメ
