永瀬美穂のレビュー一覧

アジャイル開発の一つ、Scrumの方法や心持ちを漫画とともに説明してある本。

なんちゃってアジャイルしか経験がなかったので、非常に参考になった。
すぐに理想的に実践できるのは不可能だが、知っているのと知らないのでは大きく違うと思います。
あるプログラミング言語を知らなくても別の言語の経験から大体理...続きを読む解することはできますが、チーム開発手法はある程度知らないと前に進めないと思うので、知らない人は目を通すだけでもしておくといいと思います。

マンガの登場人物たちの社内営業システム開発ストーリーに沿ってスクラムのノウハウについて解説されている。
初めてシステム開発をすることになった人の1冊目に最適な本。

「大きな問題なくスクラムが導入できた事例」となっていて、スクラムの基本的な考え方を学ぶのに良い。
現実はもうちょっと強い抵抗勢力や失敗があるのでこれだけ読んでうまく導入するのは難しいかもしれない。初めの一冊としておすすめ。

2013年初版発行なのでちょっと古い本だが、中身は今でも問題なく読める。

スクラムのはじめから終わりまで、どういうことをやってどういう問題が起きるのかを漫画と解説で順に説明してくれる形式になっているので、これからスクラムを導入しようとしている人、スクラムをやっているけどうまくいかない人は、何かと参...続きを読む考になるはず。

現場でscrumではないがほぼほぼscrumでのチーム開発になり、上司におすすめされて読んでみました。バックログを頻繁に直してタスクの見える化を行っていた理由やPOがなぜ重要かがいまいち腑に落ちていませんでしたが、この本を読んで納得できました。scrumは体験して学んでいくための仕組みということを肝...続きを読むに命じてこれからに備えていきたいと思います。

悩んだら見返す本。
最近SCRUM回してないけど、回しているときは結構重宝してた。
軽く書かれているので、入門本としてはおすすめできる。
（SCRUM Guideが真なのはわかっているが、全体像つかみにくい）

だいぶやられた。自分の近頃を省みて、ふわふわそわそわした心持ちにさせられた。いい本。

原著がそもそも良いのだと思うのだけど、邦訳品質がとても高く、自然に素直に読みくだせた。訳者の顔ぶれを見ればさもありなん、ではあるけれど。

Kent Beck が来日講演したときに、繰り返し「誠実であること」につ...続きを読むいて語っていたけど、それを思い出した。
喜び(Joy)、を社是とすることは、自分(たち) に対してかなりストリクトにエクストリームに誠実じゃないと続けられないだろうなー、と。

アジャイルソフトウェア開発手法の1つであるscrumについて、実践的な部分に重きを置いて説明されている。 scrumで知っておかないといけないことと、scrumで進めていくときによくありそうなアンチパターンが織り交ぜられていて、とても参考になる。 「だいたい終わってまーす！！」→「確実に終わらせて進...続きを読むむんだ！！」とか。 マンガ形式になっている部分はイメージしやすくて、サクッと読める内容となっている。 前提知識を揃えるためにも、是非ともチームメンバ全員に読んでもらいたい一冊。 参考文献も必読です。 「scrumの本質は、学びの仕組み」はいい言葉。素早く反省して学んでいくフレームワークがscrumだと感じている。

何度も読んでいます。
ビジネスアジリティを現場レベルでイメージすると、応用できることがたくさんあるんじゃないか？という仮説を立てています。

少しずつになってしまうと思いますが、時間をかけて整理していきます。

以下は、完全に自分用メモです(;'∀')

1. 支援する…前向きでいられるように
a....続きを読む 育てる
i. 与える
ii. 守る
iii. 勇気づける
b. 動機付ける
i. 挑戦
ii. 実験
2. ファシリテートする…アジャイルになりやすくなるために
a. 会議
b. 対話
c. 環境
3. 教育する
a. やってみせる
b. 実例を示す
c. 教える
i. 学習
ii. 道場
iii. ゲーム
iv. 物語
4. 気付く…背景にある事情についてよく考える
a. 観察する
i. 観る
ii. 聴く
1) 傾聴する
a) 空白の時間を作る（空白を埋めようとしてはいけない）
b) 心を開く（リラックスしたオープンな表情にする）
c) 興味を示す（自然な形で、何度もアイコンタクトする）
d) 理解を示す（うなずく、相づち、マイクロコミュニケーション）
2) アドバイスを伝える前に、相手の話を聞く
3) 話を明確にする質問をする
b. 熟考する
c. 質問する
5. フィードバックする…チーム自身が問題に気付けるように
a. 口頭で
見たことや聞いたことを具体的に伝える
i. チームに
ii. 1対1で
b. 見える化する
i. 図表
ii. フロー
iii. メトリクス
iv. リマインダー

仕事で実際に使う知識なので読みました。
ふわっと全体像を知れたので、あとは実務と照らし合わせながら定着させよう。未経験には一発で理解するのは難しかった。

ざっくりやることを理解。
バックログはTask chuteの考え方にも近い。
直近のプロジェクト2つで試せるから実践してみる

XP、リーン、スクラムなどひっくるめてアジャイルと呼ぶと、もうアジャイルで開発しない理由が見当たらなくなる。

13章の最初の引用「二つの自由のあり方がある。間違っているのは、人は自由に好きなことをしてよい。正しいのは、人はすべきことを自由にやってよい。」というところが印象に残っている。みんな好きなように楽しくやる、というのではなく、"曖昧さ"はなく、秩序があって、それでいて自由に、そして楽しく働いている。こ...続きを読むの違いはすごく大きい。ビジョンを共有し、ルールや手順が明確になっているから、それに沿って頑張れる。真面目に頑張っている人、正直な人が損をしないシステム。
業種が違うと活かせる部分とそうじゃない部分はあると思うけど、メンローという組織のあり方はすごく理想的だなと感じた。

スクラムについて勉強したかったので、読みました。
スクラムでPJを進めていく場合、締切とか全体的なスケジュールとかをどうするのかってあると思うけど、そこら辺の心配事もきちんと書いているので、良かったです。

ここに書かれているのはおそらく基本的なスクラムなはず。スクラムをやっている、やっていたならそれとの差異を感じながら読めて、基本に戻った方がいい部分とか、こういう理由でルール変更してるな、とかを考えながら読むと良いのではないでしょうか

アジャイルコーチとはどういうことか？というよりは、プロのコーチが組織の改革を頑張るエバンジェリストに向けて大切なことを伝授する感じ。
でも、私自身がプロでやってても印をつけたポイントはいくつもあったし、最終章には著者レイチェルの愛の深さを感じる。私もこういうコーチでありたいと改めて思った。
アジャイ...続きを読むルを導入の関門を抜け、もっと効果的な実践を目指したいスクラムマスターには読んでもらいたい。アジャイルのやり方やマインドを書いた書物は多いが、チームをリードしたりファシリテートしたりする視点に集中して書かれた本はあまりないように思う。この本にはスクラムマスターが常に気にしておいて欲しいことが沢山書いてある。

アジャイルで、とくにXPの作法で成立してる、技術と喜びに溢れた職場。
かなり多くの場面やストーリーを交えて、この会社がどのように過ごしているのかを紹介している。自分にも機会があれば、ぜひともこんな会社を作りたいと改めて思う。事業として成功している事例があることにその勇気を得られる。

アジャイルな思...続きを読む考に慣れていない人には、もしかしたらショッキングで素直には受け入れがたい内容かもしれない。しかし、それぞれ「なぜそうするのか」を著者の経営理念にもとづいて解説してあり、急には変わらなくても考え直す機会にはなるかもしれない。

こうできたら！と思う反面、世間一般的にはに縛られてむず痒さを感じたり等。なんというか、本当にこうできるようにするには、いろんなところに働きかけていかないといけない気もしたり。ますます組織やプロダクトのあり方等考えさせられる1冊。

カタカナ語と抽象的な概念が多くやや掴みにくさはある。コンウェイの法則は、ソフトウェアと開発チームの関係性を指し示す概念で真を食っていると感じる。

セントラル方のアナリティクス組織に置き換えた時に3つのコラボレーション全てが当てはまるので、組織を最適化させる際には切り分けて考える必要がありそう。

...続きを読む① コラボレーション
② X as a Services
③ ファシリテーション
↓
①例：ビジネスパートナー活動・レポート作成
②例：tableauダッシュボード提供（作成ではなく
③例：セルフBI活動

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、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする