LeanとDevOpsの科学（Accelerate）読書メモ
waddy_u総括をここに書く
読む前の認識
ポッドキャストで聞いていたので、ある程度内容というかメッセージは知っていた。ただ、具体的にどういうアクションが起こせそうか、がわからず。とりあえずデプロイ頻度を上げまくれば良いのか？本番環境だけにしてしまえばいいのか？ということをぼんやりと考えていた。
課題意識
いまの開発プロセスでより良くできるところがあれば根拠としてこの本をつかいつつ改善したい。逆に、組織、マネジメント、リーダーのプラクティスは重要視するポイントではない。
今後やっていきたい活動
計測する：
- リードタイム-1時間未満、1日未満、1日から1週間
- 本番環境へのデプロイ頻度：オンデマンド、1時間に1回から1日1回
- 平均修復時間
- 変更失敗率
計画する:
- 情報セキュリティのシフトレフト
- よりオンデマンドでデプロイできる状況をつくる努力
- 顧客に対するフィードバックの収集と製品への反映努力
- 作業の細分化
waddy_u第一章 業務を加速させるということ
各組織はマーケットにおける競争力と優位性を維持するために、次 のような面でさらなる加速化が求められる。
- 顧客に満足感を与える製品やサービスの提供
- マーケットとのエンゲージメント(絆、つながり)の強化、顧客要求に対する感度向上、顧客理解の促進
- 自社(自組織)に影響を与える可能性のある法的、倫理的規制強化に対する予測と対処
- セキュリティ上の脅威や経済情勢の変化など、潜在的リスクへの対応
こうした業務の加速化において中核的な役割を果たすのがソフトウェアであり、この点はどのような業界でも共通である
ソフトウェアおよびテクノロジーが、顧客や利害関係者に価値を提供する際の重要な差別化要因となる。
主戦場がITではない企業にとっても、「いかにソフトウェアをうまく活用するか」が事業成功のカギになっている点で共通らしい。感覚としてはわかるけど断言するのは強いですね。
1.2 エビデンスに基づいた変革のキーはケイパビリティ
次の3点はパフォー マンスを予測するための指標として取り上げられることが多いにもか かわらず、そうした指標にはなりえないものである。
- アプリケーションの使用年数やアプリケーションに必要なテクノロジー。たとえばメインフレームベースのSoR(System of Record。記録を主眼としたシステム。基幹系システムあるいは勘定系システム)か、より新しいSoE(System of Engagementを生み出すためのシステム。情報系システム)か
- デプロイメント(デプロイ)の実施は運用チームか、開発チームか
- 変更諮問委員会(CAB: Change Approval Board)があるかないか
これに対して、ソフトウェアのデリバリや組織自体のパフォーマン スの向上に効果が大きいのは、パフォーマンスがきわめて良好な組織や ごく革新的な企業が実際に日々の改善努力で焦点を当てている事柄で ある。
ざっくり、利用している技術がレガシーか最新かは関係ないと理解した。なんとなく新しく出たもののほうが競争力に直結しそうな印象だけど、そうでもないらしい。
1.3 DevOps 採用の価値
まとめると、「より高頻度でデプロイしている組織ほど、組織パフォーマンスが高い」そうだ。ローパフォーマンスの組織は開発プロセスへの投資が足りず、デプロイの大規模な失敗を招き、サービスの復旧に時間がかかる。
高頻度にデプロイできる状況を整える努力をしている組織は競争力があるとも読み替えられる。じゃあ具体的にどのくらいの頻度だといいの？というのは後述だけど、だいたい毎週本番環境にリリースできるとよく、もっというとコミットしたそばから本番に適用できるほどいいらしい。
waddy_u第2章 開発組織のパフォーマンスを計測
高頻度にデプロイできる組織ほどパフォーマンスが高いということがわかった。じゃあソフトウェアデリバリのパフォーマンスを的確に計測できる尺度はなに？という話で、
我々は次の4つを 選び出した。デリバリのリードタイム、デプロイの頻度、サービス復旧 の所要時間、変更失敗率である
ということらしい。理由も書いているけど省略。わりとリーン開発の手法から取り入れている模様。リードタイムは「コードのコミットから本番稼働までの所要時間」と定義している。
これらの尺度をベースに調査を行った結果、ハイパフォーマーは
- デプロイ頻度：オンデマンド（一日複数回）
- 変更のリードタイム：一時間未満
- サービス復旧の所要時間：1時間未満
- 変更失敗率：0-15%
ということがわかった。より高頻度というか、やりたいときにデプロイし、コミットしたら一時間以内に本番に反映されるという状況なのね。この状況をつくるためにはかなりプロセスに投資しないといけないはずで、それが結果的にパフォーマンス向上に寄与しているのだろう。
2.3 組織のパフォーマンスとデリバリのパフォーマンス
ここ数年の分析で、ハイパフォーマーのこうした基準での パフォーマンスの測定結果がローパフォーマーのそれを上回る傾向に あり、両社の対比は一貫して2倍を超えている。この傾向が示唆するの は「組織のソフトウェアデリバリのケイパビリティ(能力、機能)は、組織に競争上の優位性をもたらす」という点である。
雑に書くとデプロイ頻度が高い組織ほど競争力が高いと。コードの行数や抱えている社員の数ではなく、デプロイ頻度がキーだったのは面白い結果。
ソフトウェア関連の部門においては、作業を細分化して進めてデリ バリを行う能力がとりわけ重要である。というのも、この能力が組織に 十分備わっていれば、A/Bテストなどの手法でユーザーのフィードバッ クを素早く得られるからである。ここで注目すべきは「 製品開発に実験的な姿勢で臨める能力が、継続的デリバリに寄与する技術的プラクティ スと高い相関をもつ」という点である。
つまり誰かに言われたからとか、カタログ的な機能不足の圧力に屈してとかではなく、（最終的に）開発メンバーが必要だとおもったから試しにやってみるという姿勢がデリバリパフォーマンスに寄与すると。これはなんだか心情的に納得できる話ですね。官僚的なプロセスになった瞬間萎える。
waddy_u第3章 組織文化のモデル化と測定
今回の課題ポイントとはずれる部分なので流し読み。とはいえまとめのこの部分は響いた。
「 私がこの経験から学んだ中でも特に印象に残っているのが、 組織文化を変えていく上でまず最初にやるべきなのは、関係者の思考方 法を変えることではなく、関係者の言動、つまり皆が何をどう行うかを 変えることだ、という点である」[Shook 2010]※4。我々はその趣旨に沿 う形で「リーンとアジャイルのプラクティスを実践すれば組織文化に 好影響を与えられる」という仮説を掲げ、技術的プラクティスと管理面 でのプラクティスを視野に、それらが組織文化にもたらす影響を測定し てきた。リーンマネジメントの手法は、「継続的デリバリ」と総称される 各種技術的プラクティスと併用すると組織文化に好影響を与えられる。
個人の解釈：啓蒙活動や浸透させたいことがあるときに、ミーティングを開いて「これやりたい、やっていこうぜ、あとお願いします」では組織は変わらない。継続的デリバリに組み込み、それに関わるメンバーの行動を変えることで組織が変わっていく。ただ、もうひとつ影響を与えるとされる「リーンマネジメント」はよくわかっていない。
waddy_u第4章 技術的プラクティス
この章が熱い！
アジャイル開発手法を実践しているチームの間では、管理面のプラク ティスやチームのプラクティスに比べて技術的プラクティスは「二の次 」という扱いをする傾向が強い( アジャイルのフレームワークの中に は管理面やチームのプラクティスを重視するものもある )。しかし我々 の調査研究では、技術的プラクティスが高頻度、高品質、低リスクなソ フトウェアリリースを実現する上で決定的な役割を果たすことが立証 されている。
調査研究によって「継続的デリバリのプラクティスは、結果に測 定可能なレベルの影響を確かに与えている」ことが明らかになった。
激アツ。「ビジネスに直結してないんじゃない？」とみなされがちな技術プラクティスが、組織パフォーマンスに影響を与えることが科学的にわかったというのが。なんとなくよさそうだからとか、開発体験がいいからとかではなく、測定可能なものとして影響を与えると。はっきり言っている。嬉しいですね。
「じゃあどうすれば！？どうすればいい？なにすればいい？」という感じでモチベーションバク上がり。
4.1 継続的デリバリとは？
「継続的デリバリ」とは、機能の追加、構成の変更、バグの修正、各種 試行など、さまざまな変更を、安全かつ迅速かつ持続可能な形で本番環 境に組み込んだりユーザーに提供したりする作業を促進する一群のケ イパビリティから成る手法である。次の5つの基本原則を柱とする。
「品質」の概念を生産工程の最初から組み込んでいく
作業はバッチ処理で進める
反復作業はコンピュータに任せて人間は問題解決に当たる
徹底した改善努力を継続的に行う
全員が責任を担う
これらの実践のためには以下の作業基盤を整備する必要がある。
包括的な構成管理(CM:Configuration Management)
継続的インテグレーション(CI:Continuous Integration)
継続的テスト
継続的デリバリとは、質の高いソフトウェアをより高頻度でより確 実にユーザーに提供できるよう、複数のフィードバックループを作るこ とである※2。正しく実践できれば、新バージョンのリリースが、日常的 な作業として、いつでもオンデマンドで実行できる。継続的デリバリの 実現には、開発者とテスターのほか、UXや製品、運用の担当者も参加し てもらい、デリバリプロセス全体を通しての各担当者の協働が欠かせ ない。
もうここにこの本のすべてが詰まっているといっても過言ではない。
自分の業務で取り入れたいところ
ありがたいことにいまの職場は継続的デリバリがかなり高いレベルで実現されており、「ああ、みんなが頑張って効率化したデプロイ作業はすごくいいことだったんだな」と確認できた。で、さらによくできるところがあるとすれば…
- 「品質」の概念を組み込む
品質に対して、わかりやすい作業のLintやユニットテストはCIに組み込めている。また、動作確認レベルのE2Eテストも組み込めている。ただ、セキュリティリスクに対する組み込み、画面レイアウト崩れ、バックアップ作業の確実性 このあたりが組み込めていない、と感じる。やはり一度でも踏んだことのあるミスに対しては積極的に組み込むが、遭遇したことがないものに対してはなかなか初っ端から組み込む発想が出にくい。ただ、どれも顧客から指摘されてしまうとアカンタイプのやつなので、開発初期にセットで話を出す余地がないかもう一度考えたい。
- 作業はバッチ処理で進める
フィードバックをもらえる最小単位に切り出すことができていない。というのも、中途半端な完成度でのリリースは、かえってサービス全体のUXを損ねる恐れがあるから、というのが大きい。結果、内部で隠密に進め、検証環境でガッツリ確認し、大きめのリリースとして展開することが増える。
マーケティング的なサプライズを度外視して、例えば一部のユーザーにだけベータ機能としてUXを損なう可能性があることを周知し、それでもいいと同意してくれた人にだけ部分的に使ってフィードバックをもらう、という仕組みを検討するのがよさそうか。GitHubとかはこのへん充実しているよね。
Feature Previewがまさにそれ
4.2 継続的デリバリの効果
すでに第3章で述べたように、我々は「継続的デリバリを実践すると、 組織文化に好影響を与えることができる 」との仮説を立てた。そして分 析の結果、それが真であることを立証できた。組織文化を改善したけれ ば、継続的デリバリのプラクティスを実践すると効果が得られるのである。
改めて。デリバリの実践が組織文化に好影響を与えるって矢印が、やっぱり印象に残る。調査結果から、どうやったら継続的デリバリを促進できるか、という話がまとめられている。
さらにさらに、継続的デリバリによってソフトウェアデリバリへのパフォーマンスに寄与するだけでなく、組織文化の改善さえ促すことを示唆する調査研究があった模様。継続的デリバリにの実践度が高いチームは、次のような成果をあげていた：
- 組織への帰属意識が強い(第10章を参照)
- ( リードタイム、デプロイ頻度、サービス復旧までの所要時間の各 尺度で測定した)ソフトウェアデリバリのパフォーマンスレベル が高い
- 変更失敗率が低い
- パフォーマンス志向で創造的な文化が浸透している(第3章を参照)
さらに良いことに「 継続的デリバリの実践度が増すと、職務満足度や やりがいが高まる」という点も明らかになった。これはつまり「テクノ ロジーへの投資は人への投資でもある」ということであり、こうした投 資により良好な開発プロセスの持続可能性が高まる。
この関係、どういう要素なんでしょうね。自分のやったことが、即座に顧客に届く、というのがやっぱり満足度を上げる要因になっているのかな。
4.3 品質に対する継続的デリバリの効果
調査結果から言えることとして、ハイパフォーマーの場合は新しい作業に費やす時間の割合が大きく、予定外の作業や修正作業に費やす時間の割合が小さい傾向があったそう。
4.4 継続的デリバリのプラクティス -- 有効性の高いものは
4.4.1 バージョン管理
異論ないでしょう。アプリコンフィグレーションをバージョン管理するほうがデリバリパフォーマンスに寄与するみたい。Rails の application.rb とか Next.js の next.config.js とかそういうのですかね。
4.4.2 テストの自動化
これも感覚と一致する。ただし、ITパフォーマンスの予測尺度になりえる活動は限られるらしい。なんとなく想像する「カバレッジの計測」や「バグ率の計測」は関係ないようだ（よかった）。
- 信頼性の高い自動化テストの実施 ― つまり、そのテストに合格したソフトウェアであればリリース可能、不合格であれば重大な不具合がある、とチームが革新できるようなテストを実勢していること。
- 開発者が主体となった承認テストの作成・管理、および承認テス トの容易な複製・修正 ― 我々の分析結果の中でも興味深いのは 「主としてQAチームか外注先が作成・管理している自動化テスト は、ITパフォーマンスと相関関係にない」という点である。
ふたつめがとくに印象に残りますね。開発者が品質に責任をもつことが、パフォーマンス向上につながると。もちろん付け加えて、テスターが不要だということではない、ということも言っています。
4.4.3 テストデータの管理
よくわからなかった。シードの話？
4.4.4 トランクベースの開発
要するに、開発者が手元で抱えるブランチの生存期間を短くして、できるだけはやく（1日未満）本流にマージするような開発の流れを言っているようだ。僕も最初イメージしづらかったが、こちらの解説がわかりやすい。
言わんとしていることはなんとなくわかるけれども、うーん、これは、アプリケーションの特性にもよりそうな話な気がしますね。機能によっては慎重に開発を進めたいものもあるでしょうし。ただ、
我々が何 人かに聞き取りをした結果と我々自身の経験とに基づいて「こうした 結果が出たのは、より『寿命』の長いブランチを複数使うと、リファクタリングとチーム間のコミュニケーションを阻害するからだろう」と コントリビューターいう仮説を立てた
でかいプルリクはたしかに気力も削がれる。
4.4.5 情報セキュリティ
ハイパフォーマンスなチームは、情報セキュリティの概念をデリバ リのプロセスに組み込んでいる傾向が強かった。こうしたチームでは設 計の段階からデモの段階まで、さらにテスト自動化の支援段階に至るま で、ソフトウェアデリバリのライフサイクルを通して情報セキュリティ の担当者がフィードバックを提供していた
このあたりすごい身構えるけど、デリバリプロセスに組み込みこんで、懸案があればチームの日常業務に組み込む形がいいということだ。GitHub の dependabot が自然にその役割をやってくれているので、あればイメージ近いかもですね。OWASPの観点から組み込めると良さそう。
4.5 継続的デリバリの導入
結構投資しなきゃいけないし、ソフトウェアの構成を見直さないといけないとおもう。それを次の章で紹介するね、と書いてました。
waddy_u第5章 アーキテクチャのキーポイント
5.1 システムのタイプとデリバリのパフォーマンス
システムアーキテクチャがソフトウェアデリバリのパフォーマンスに加える制約の影響を調査したらしい。
ローパフォーマーとなる傾向が強いもの:
- 構築中のソフトウェア( あるいは利用する 必要のある一群のサービス)は、他社(外注先など)が開発したカスタム ソフトウェアである
- メインフレームのシステムで作業を進めている
興味深いのは、「メインフレーム系システムへの統合の対象 である」という環境と、それを担当しているチームのパフォーマンスと の間に、有意な相関関係が見られなかった点。
他のケースではシステムのタイプとデリバリのパフォーマンスに有 意な相関関係は見受けられず、これは意外な結果であった。
ソフトウェアを外注するとデリバリパフォーマンスが下がる、メインフレームで作業するとパフォーマンスが下がる。いずれも納得できる話だ。
あとは、コンテナによるマイクロサービスだからといってパフォーマンスが向上するわけではない、というのもなんとなく聞いていた噂と一致する。ここは気をつけないといけない。
5.2 注力すべきはデプロイとテストの容易性
我々の調査では、次の2 つの事項に「 同意できる 」と回答した組織であればハイパフォーマーである可能性が高い、という結果が出たのである。
- テストの大半を、統合環境を必要とせずに実施できる
- アプリケーションを、それが依存する他のアプリケーションや サービスからは独立した形で、デプロイまたはリリースできる(そして実際にもデプロイまたはリリースしている)
アーキテクチャに関わるこの2つの特性を、我々は「テスト容易性」と 「デプロイ容易性」と呼んでいるが、この2つがパフォーマンスを向上さ せる上で重要だと思われる。この2つの特性をもたせるには、システム が疎結合である必要がある― つまり相互に独立した形で変更・検証 できなければならない。そこで我々は2017年の調査研究で分析範囲を 拡大し、カプセル化された疎結合アーキテクチャがパフォーマンスをどの程度向上させるかを調べた。その結果、そうしたアーキテクチャには確かにITパフォーマンスを向上させる効果があることが判明した。 2017年度の分析では、次のケイパビリティをチームが備えているか否 かが「テストとデプロイの自動化」をも凌いで、継続的デリバリの最強の促進要因となっていたのである。
- チーム外の人物の許可を得なくても、対象システムに大幅な変更 を加えられる
- 対象システムの変更作業で他チームに頼ったり、他チームに相当 量の作業を課したりすることなく、対象システムに大幅な変更を 加えられる
- チーム外の人々とやり取りしたり協働したりすることなく作業を完遂できる
- ソフトウェア製品やサービスを、それが依存する他のサービスに 関係なく、オンデマンドでデプロイ、リリースできる
- 統合テスト環境を必要とせずに、オンデマンドでテストの大半を実施できる
- デプロイメントを、無視できるほどわずかな稼働停止時間のみで、通常の勤務時間内に完了できる
引用ながくてすいません。でも大事そう。ここでいいたいのは、
目指すべきは「<チーム間のコミュニケーションをさほど要さずに、設計からデプロイまでの作業を完遂できる能力>を促進する アーキテクチャを生み出すこと」なのである。
ということなのだ。
もちろんDevOpsのキモはチーム間のより良い協働であり、ここで「チームは協力し合うべきではない」などと説いているわけではない。 疎結合のアーキテクチャの目的は「組織内でのコミュニケーションの処理能力を、実装レベルの細かな意思決定に関するやり取りで使い切っ たりせず、より高次な共通の目標やその達成方法に関する議論に使える ようにすること」なのである。
これは最初読んだとき震えて寝た。僕が一所懸命考えていた「良いアーキテクチャ」とはパフォーマンスを挙げる要因の一部にしか貢献していなかったのだ。
- あとで変更しやすいようにする
- イベントドリブンベースにして、スケールしやすいようにする
- フロントエンドとバックエンドを分けてリソース効率が良い協業を促進する
せいぜいこのくらいだった。3番目はいいセンいってるがそれでも解像度が低い。チーム間のコミュニケーションをさほど要さずに設計からデプロイまでの作業を完遂できるようなアーキテクチャを目指す、というのはとてもわかりやすい目標だ。
5.3 疎結合アーキテクチャにはスケーリング促進効果も
疎結合になっているかどうかは、開発者の人数が増えるにつれて、デプロイ頻度が有意に上がっていることが確認できればよい。デプロイのためにチーム間連携、ステップ数が増えるような状態だと、デプロイ頻度は下がってしまいそう。
5.4 必要なツールをチーム自らが選択できる
まあこれはさすがに…でも新しいツールを使うまでにステップ数や承認が多ければ多いほどやる気が削がれるのは確かですね。
5.5 アーキテクチャ設計担当者が焦点を当てる エンジニアと成果
アーキテクチャをめぐる議論では「マイクロサービスかサーバーレスか」「KubernetesかMesosか」「どのCIサーバー・言語・フレームワー クを標準にすべきか」といった具合に、とかくツールやテクノロジーに 焦点を当てがちだが、本調査研究では、こうした焦点の当て方が誤りで あることが立証されている。
ワロタ。いや、笑えない…
waddy_u第6章 デリバリライフサイクルに情報セキュリティを組み込む
本調査研究では「チームが情報セキュリティを時間軸上の左へ移動 （シフトレフト）すると、継続的デリバリを実現する能力が向上し、ひい てはデリバリのパフォーマンスも向上する」との結果が出ている。情報 セキュリティ関連の作業を独立したフェーズとして開発プロセスのダ ウンストリームで実施するのではなく、最初からソフトウェアのデリバ リのプロセスに組み込むのである。
いわゆる開発工程の最後のほうで「セキュリティチェック」のような工程が入ると、そこで不具合が見つかった場合にシンプルに手戻りが大きい。それはそう。
テストの話と同じく、セキュリティのリスクも検出できる1番早い段階で見つかるといいよね、という話。具体的にはモノによるとは思うが、力学としてシフトレフトさせよう、ということ。あとは開発者もこの辺を積極的に勉強してテストに組み込めるといいですね。
waddy_u第7章 ソフトウェア管理のプラクティス
リーンマネジメントの話だった。技術プラクティスからは少し離れるのでスッと流す。
- リーンマネジメント
- 進行中の作業（WIP）の制限
- 可視化（見える化）
- ワークフローの可視化
- 負担の軽い変更承認プロセス
作業に集中し、本番にデリバリーするまでのハードルを下げ、その効果をよりみやすくしよう、そうすれば開発効率を上げられ、組織のパフォーマンス向上も見込める。
waddy_u第8章 製品開発のプラクティス
この章もリーン製品開発のプラクティスだったので流すが。
- 1週間未満で製品と機能を完成して頻繁にリリースできるよう、 関連作 業を細分化して進める能力(実用最小限の製品 ( MVP: minimum viable product) の実践の度合いなど
- 開発の最初期から顧客関連業務に至る作業フロー全体に対する チームの理解度と、(製品や機能の状況も含めて）このフローの可 視化の度合い
- 組織が顧客フィードバックを積極的・定期的に収集し、それを製品 デザインに盛り込む能力
- 承認不要な開発プロセスの一部として、開発チームが有する、製品 仕様の作成・変更権限
1の一週間未満で機能を完成して頻繁にリリースできるよう...ってのは、努力目標としてはいいと思うけど、実際無理なときもあるし、下手なデザインで出すくらいならまとまってから出したほうがいいという話もあると思うので全面的には同意できない。作業の細分化ならまあわかる。
waddy_u第9章 作業を持続可能にする
バーンアウトに陥りやすいパターンと対処法が述べられている。ピックアップするなら以下。
• DevOps導入に向けての組織レベルでの投資 ― チームのスキル とケイパビリティの開発に投資を怠らない組織は、より良い成果を上げている。チームメンバーのトレーニングに投資して、新たなスキルの習得に必要な支援および（時間も含めた）資源を提供することこそが、DevOpsの導入を成功させる上で不可欠である。
特にスタートアップなど、期間と資源が限界まで切り詰められた状況ではなかなかDevOpsに投資するというのは難しいかもしれない。うまくこの辺を教育含めて持続可能にする訓練ができるといいですね。自社開発できる能力がある会社はDevOpsに投資しよう。
waddy_u第10章 従業員の満足度、アイデンティティ、コミットメント
このへんはあまり興味をそそられないけど、一応流す。従業員に満足度調査を行い、組織への帰属意識をチェックしよう、という話だった。20代の頃は帰属意識や職務満足度などというものに興味がかなかったが、「従業員を満足させずしてどうして顧客を満足できようか」みたいな考えの会社が増えてきた印象がある。ので、自分がそういう視点になってきたのかなと。
それで、興味深いのは継続的デリバリおよびリーンマネジメントのプラクティスがこの職務満足度の向上にもつながるというのだ。ほんとだとしたらすごい。
以上をまとめよう。職務満足度と高い相関を示す測定対象項目を比較検討すると、ある状況が見えてくる。プロアクティブ（予防的）なモニタリングや、テストやデプロイの自動化といったプラクティスにより、 単調作業が自動化され、人間に求められるのはフィードバックループに 基づく意思決定、という状況である。人間はタスクの管理から開放され、 自身のスキル・経験・判断力を生かして意思決定を下すようになるわけである。
あ。ここは結構大事だった。デリバリの自動化と継続は、メンバーの尊厳を守っているということなのね。
多様性の話はスキップ。僕の想像を超えている。ひとつ言えるのは、プログラマは性別や人種とか気にしなくていい部類の職業だと思うので、早く理想値に近づいて欲しいなと思う。自分の娘の将来も気になるし。
waddy_u第11章 変革型リーダーシップとマネジメントの役割
苦手な話が続く。ここ10年くらい？でリーダー象が大きく変わりましたね。この本で紹介されているのは：
• 高い信頼性と生産性を実現するための文化規範を確立しサポート する
• 開発者の生産性を高めるテクノロジーを創造し、デプロイまでの リードタイムを縮小し、より信頼性の高いインフラをサポートする
• チームの実験や技術革新をサポートし、良質な製品を迅速に創造し実装する
• 組織の部署を越えた取り組みにより、戦略的な協力関係を築き上 げる
すごいやり手ですね。変革型リーダシップはメンバーのやる気を鼓舞し、大規模な組織改変を促進する者のことだそうだ。大丈夫かなこれ。根性論みたいになってない？特性として次の5つがあるらしい。
- ビジョン形成力 ― 組織が何を目指し、5年後どうあるべきかを明確に把握している
- 心に響くコミュニケーション能力 ― 不確実で変動する環境下でも、従業員を鼓舞し、ヤル気にさせるような対話を行う
- 知的刺激 ― 部下の意欲をかきたて、新たな方法で問題に取り組むよう促す
- 支援的リーダーシップ ― 部下の個人的要求や感情に配慮と気遣いを示す
- 個人に対する評価 ― 目標の達成、作業品質の向上を認識・賞賛 し、顕著な業績を上げた場合には個人的に報奨する
うち、知的刺激に関して次のようなプラクティスはいいね、と思った。
- 従業員が失敗を恐れないようにする
- 情報共有のための機会や場を作る
- デモデイやフォーラムを開催して、情報共有や技術革新を促す
- モニタリングを優先事項にする
それっぽい仕事をするときになったら、また見返そう。
waddy_u第12章 統計学的背景
スキップ。
waddy_u第13章 軽量心理学入門
スキップ。
waddy_u第14章 アンケート調査を採用する理由
スキップ。あとで。一つ言えるのはアンケートを甘くみてはいけない（戒め）。
waddy_u第15章 データの収集方法
スキップ。あとで。
waddy_u第16章 ハイパフォーマンスを実現するリーダーシップとマネジメント
ユニコーン企業のヒミツでもみた気がする。組織の組み方的な話だった。
waddy_u付録
ここにまとまっているので思い出したくなったら付録を見ればOK。