吉羽龍太郎のレビュー一覧
-
-
-
-
-
-
-
-
-
Posted by ブクログ
PARTⅠ デリバリーの手段としてのチーム
KEY TAKEWAYS 要点
Chapter 1
・コンウェイの法則では、ソフトウェアアーキテクチャーとチームインタラクションを同時に設計する利点を説いている。両者に働く力は同じものだからだ
・チームトポロジーはチームの目的と責任を明確にし、チーム間の相互関係の効果を向上させる
・チームトポロジーでは、戦略適応性の実現のために組織を調整しつつソフトウェアシステムの構築においては人間的なアプローチを利用する
過去数十年にわたって、ビジネスを構成するための新しいアプローチがたくさん登場した。それらは依然として組織を静的なものとして見ていさて、組織を再編したあとに起こる現実のふるまいや構造は考慮に入れていなかった。たとえば、1990年代に登場しそこから数十年でかなり普及した「マトリクスマネジメント」は、個人にビジネスマネジャーとファンクショナルマネジャーの双方に報告させることで、複雑で、不確実性が高くさて、高度なスキルが必要な仕事に対応しようとした。純粋な職能型組織のチーム構造と比べると、ビジネス価値に焦点を当てているとはいえ、これもまた静的な世界観であり、ビジネスや技術の領域が急激に進化するにつれ、時代遅れになっていく。
Chapter 2
・組織はそのコミュニケーションパスを反映した設計を作り出す
・組織設計はソリューション探索の制約になり、取りうるソフトウェア設計を限定する
・全員が他のすべての人とコミュニケーションするよう求めるのは、混乱のもとである
・チーム内のフローがよくなるようなソフトウェアアーキテクチャーを選択せよ
・明瞭なチームインタラクションだけにコミュニケーションバスを限定することで、モジュール化した疎結合なシステムが生まれる
コンウェイの法則の背後にある同形性を示す証拠が増えていることを考えると、技術リーダーの意見を聞かずにチームの形成、責任、境界について決定を下すというのは、ソフトウェアシステムを構築する組織にとって非常に非効率で、そしておそらく無責任なのだ。
実際に、組織設計とソフトウェア設計は同じコインの裏表であり、どちらも同じだけの知識を持った人たちによってなされる必要がある。アラン・ケリーのソフトウェアアーキテクトの役割についての見解は、この考えをさらに発展させたものだ。
これまで以上に確信するようになったことがある。アーキテクトを名乗る人には技術的スキルと社会的スキルの両方が必要であり、人間を理解し社会の枠組みのなかで仕事をする必要があるということだ。同時に、彼らには純粋な技術にとどまらない広範な権限が必要だ。組織構造や人事問題についても発言権を持つ、つまりマネジャーになる必要があるのだ。
基本的に、組織設計にはエンジニアを巻き込む必要がある。というのも彼らは、APIインターフェイス、抽象化、カプセル化といった重要なソフトウェア設計の概念を理解しているからだ。ナオミ・スタンフォードはこのように付け加える。
「部署や課、システム、ビジネスプロセスといったものは、設計の一部としてより広い組織とのインターフェイスや境界を決める場合に限り、独立して設計できる」
Chapter 3
・チームはソフトウェアデリバリーにおける最も効果的な手段である。個人ではない
・ダンバー数を踏まえて、組織のグループのなかのチーム数を制限する
・チームの認知負荷の許容量に合わせて、責任を限定する
・チームごとに明確な責任の境界を作る
・チームの成功の助けとなるよう作業環境を変える
PART Ⅱ フローを機能させるチームトポロジー
KEY TAKEWAYS 要点
Chapter 4
・その場しのぎや頻繁なチーム設計の変更はソフトウェアのデリバリーを遅くする
・唯一絶対のトポロジーはないが、どの組織にとっても不適切なトボロジーはある
・どのトポロジーにするかを検討する際は、技術面や文化面での成熟度、組織の規模、技術面での規律といった観点が欠かせない
・特に、フィーチャーチームやプロダクトチームのパターンは強力だが、それを支える環境がある場合のみ機能する
・チームの責任を分割することでサイロを壊し、他のチームの能力を高める
Chapter 5
・4つの基本的なチームタイプによって、現代のソフトウェアチーム間のインタラクションは単純化できる
・業界におけるよくあるチームを基本的なチームタイプにマッピングすることで、オーナーシップの不明瞭さや過負荷または低負荷なチームを取り除き、組織を成功に導ける
・中心となるチームタイプは、ストリームアラインドチームだ。その他のチームタイプはすべてストリームアラインドチームを支援する
・その他のチームタイプとして、イネイプリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームがある
・トポロジーは大規模になると、しばしばフラクタル(自己相似)な形となる。すなわちチームから構成されるチームだ
ストリームアラインドチームが備える能力
一般的に、ストリームアラインドチームは初期の要求探索の段階から本番運用まで作業を進めるのに必要な能力一式を備えている必要がある。そこのような能力には以下のようなものが含まれる(これに限らない)。
・アプリケーションセキュリティ
・事業成長性分析と運用継続性分析
・設計とアーキテクチャー
・開発とコーディング
・インフラストラクチャーと運用性
・メトリクスとモニタリング
・プロダクトマネジメントとオーナーシップ
・テストとQA
・ユーザーエクスペリエンス (UX)
Chapter 6
・チームファーストのアプローチを活用して、ソフトウェア境界を選択する
・ソフトウェアのデリバリーチェーンにおいて、隠れモノリスや結合に気をつける
・ビジネスドメインで境界づけられたコンテキストを踏まえたソフトウェア境界を利用する
・必要に応じて別のソフトウェア境界を検討する
PART Ⅲ イノベーションと高速なデリバリーのためにチームインタラクションを進化させる
KEY TAKEWAYS 要点
Chapter 7
・ソフトウェアデリバリーを強化するには、いずれかのチームインタラクションモードを選択する
・チームインタラクションモードにはコラボレーション、X-as-a- Service、ファシリテーションの3種類があり、他のチームにサービスを提供したり、そのサービスを進化させたりする
・コラボレーションはイノベーションを強力に推進するが、フローを低下させる可能性がある
・X-as-a-Serviceは他のチームがすばやくデリバリーするのを助けるが、それは境界が適切な場合に限られる
・ファシリテーションは複数チームをまたぐ問題の発生を回避したり、問題を見つけたりするのに役立つ
Chapter 8
・戦略的優位性の追求のために、異なるトポロジーを同時に活用する
・新しいアプローチの導入を加速するために、チームタイプやチームインタラクションを変える
・チームトポロジーを活用して、探索、開発、終了フェーズを区別する
・さまざまなニーズに対応するために、複数のチームタイプが同時に存在することを想定しておく
・組織変更のトリガーを認識しておく
・運用は、自律操舵のための高精度な入力センサーとして扱う
Chapter 9
・チームファーストのアプローチとコンウェイの法則、4つの基本的なチームタイプ、チームインタラクション、トポロジーの進化、組 織的センシングを組み合わせる
・さあ始めよう。 まずはチームから始めて、ストリームを特定し、 最 低限のプラットフォームを明らかにし、 能力ギャップを見極め、チームインタラクションを実践しよう
■4つのチームタイプと3つのインタラクションモード
4つの基本的なチームタイプは以下のとおりだ。
・ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ
・プラットフォームチーム：下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす
・イネイブリングチーム：転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける
・コンプリケイテッド・サブシステムチーム：普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される
速いフローで効果的なソフトウェアのデリバリーを行うのに必要なのは、これらのチームの組み合わせだけだ。だが、効果的なソフトウェアデリバリーとは何なのかを理解し、それを実現していくには、4つの基本的なチームタイプ間のインタラクションモードも極めて重要である。
・コラボレーションモード： 特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある
・X-as-a-Serviceモード：あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする -
-
Posted by ブクログ
特に、プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ。プロダクトオーナーは作るものをより良くすることに注力しないといけないので、開発チームに、もっとたくさん作ってほしいとかもっと作りこんでほしいというプレッシャーを無意識のうちにかけてしまうかもしれない。一方で、スクラムマスターは円滑に仕事を進めていきたいので、開発チームが無理している状態を見過ごすわけにはいかない。無理をしている状態が続けば、長期的にうまくいかなくなってしまうからだ。
■完成の定義の一例
・デモ手順の通りに動作する
・publicメソッドのテストコードがある
・調査した内容はWikiにまとめてある
・最新の仕様がWikiにまとめてある
・リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる
スクラムチームを常に良い状態にしておくのがスクラムマスターの役目だ。スクラムチームを観察して、どこがうまくいっていないかを見つけよう。扱いにくいコードの場合でも、どこかに予兆はあったはずだ。
たとえば、その予兆は書いたコードからもわかる。どうみても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしていることかもそうだ。こうしたことを見逃さないように工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。良くない状態の開発チームは、こういうことに割く時間さえ作れないかもしれないからだ。
■リリーススプリント
…スクラムを始めたばかりのスクラムチームが採用することが多い。これは通常のスプリントが終わったあとに、リリースに必要な作業を片づけるための時間を最後にまとめて取るやり方だ。通常のスプリントとは違って、その期間のことをリリーススプリントと呼んでいるだけで、やり方はとくに決まっていない。スクラムイベントも必要なければやらなくていい。
スクラムで大人数による開発はできるのだろうか？作るものの規模が大きければ開発する人の数も多くしたくなるだろうが、スクラムでは開発チームの人数は３～９人の少人数が適切とされている。
■ボクくんがスクラムのプロジェクトを通じて気づいたこと
・ロールは単なる目印
・開発を進めるうえで大切だと思うことは何でも話し合っておく
・スクラムチーム全員がプロダクトバックログについて知っておく
・見積りは推測
・自分たちの作業は自分たちで見積もる
・ベロシティがわかれば、先の見通しが見えてくる
・スプリントプランニングでは確実に終わらせられる計画を作る
・スプリントゴールを守るために毎日検査する
・問題になる前に見つけて対応する
・完成の定義は、スクラムチームで合意する
・タイムボックスに入るようにしていくのが重要
・プロダクトバックログの順序は常に見直しておく
・自分たちの責務について理解しないとうまくいかない
・ベロシティはあくまで目安
・ロールで担当する部分を分けているので、どこに問題があるかわかる
・頻繁に話し合って伝えていくのが一番大事
・スクラムマスターがスクラムチームを良い状態に保つ
・障害に順序をつけてどれを優先的に解決するかを明らかにしておく
・スクラムチームの進む先をいつも明確にするために整理し続ける
・スプリントの準備は開発をうまく進めるうえで不可欠
・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
・全員でさまざまな状況を克服できるようにしておく
・責任を持って取り組んでいくのが大事
・なんでもリリーススプリントに回すのは良くないこと
・スクラムは体験して学んでいくための仕組み -
-
-
-
-
-
![サーバ／インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載！]](https://res.booklive.jp/395506/001/thumbnail/S.jpg)
-
-
Posted by ブクログ
みんなで学び合う文化を作る。
この本に早めに出会えればよかったなー、そうすると前職でもっと違う施策をとってだと思う。こういう文化を一から作り、改善が実感できていくのは楽しいだろうなー。
エースを作らず、皆で必要な無駄を取り入れて成長する
ペアプロ、デイリースタンドアップミーティングなどなど
二重投資が実は最短で低コスト、というマインドと自負を持つべきですね。
あと、ルールと計画に厳格なマネージャーではなく、恐怖によらない説明責任のもと、皆で改善して将来の計画を作っていこう、という雰囲気を作るチーム作りが大事と痛感。
これを肝に命じて、自分の仕事を見直していこう。だから、今の会社はマネージャーとは言わない。 -