吉羽龍太郎のレビュー一覧

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

基本的な導入方法からchef-soloとserverの違いや特徴、コマンドリファレンスも用意されているのでプロビジョニングにchefを初めて使う際この本があると大抵の事は載っていると思います。地味ながらchefの設定対象(td-agentやniginx)の設定方法なども副次的に覚えられるのも嬉しいです。

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

Chefについて、基本的な使い方、ある程度実践的な実践的な環境の構築(PHP, Nginx, Ruby, Uniconrn, MySQLリプリケーション、Fluentd）、環境構築のテストといったことが丁寧に描かれているのでかなり良い本。
しかし、実践的な環境構築でcommuty cookbooksを使わないで自前でゴリゴリやりすぎていて、-1としました。　

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

このシリーズはオライリーと違ってそこそこ初心者でも分かるように書いてくれてる。あと実例があるからイメージつきやすい。欲を言うなら、冒頭で要点まとめるとか、分かりやすい工夫があるといい。

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

Chefを実践してみるのに必要な事項が整理されている。
前半のローカル開発環境の構築が、Macを例に記載されている点がちょっと残念。

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

chefはとっつきにくい部分があると思うけど、導入しやすくなる一冊だと思う。個人的には欲しい情報が整理されていた。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

マシュー・スケルトン / マニュエル・パイス / 原田騎郎 / 永瀬美穂 / 吉羽龍太郎

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

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

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

西村直人 / 永瀬美穂 / 吉羽龍太郎

スクラム開発の全体像を実践を意識して把握できるのでありがたいが、漫画のほうに（あえて描かなくてもいいはずの）残業描写が多いのが気になる

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

西村直人 / 永瀬美穂 / 吉羽龍太郎

　特に、プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ。プロダクトオーナーは作るものをより良くすることに注力しないといけないので、開発チームに、もっとたくさん作ってほしいとかもっと作りこんでほしいというプレッシャーを無意識のうちにかけてしまうかもしれない。一方で、スクラムマスターは円滑に仕事を進めていきたいので、開発チームが無理している状態を見過ごすわけにはいかない。無理をしている状態が続けば、長期的にうまくいかなくなってしまうからだ。

■完成の定義の一例
・デモ手順の通りに動作する
・publicメソッドのテストコードがある
・調査した内容はWikiにまとめてある
・最新の仕様がWikiにまとめてある
・リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる

　スクラムチームを常に良い状態にしておくのがスクラムマスターの役目だ。スクラムチームを観察して、どこがうまくいっていないかを見つけよう。扱いにくいコードの場合でも、どこかに予兆はあったはずだ。
　たとえば、その予兆は書いたコードからもわかる。どうみても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしていることかもそうだ。こうしたことを見逃さないように工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。良くない状態の開発チームは、こういうことに割く時間さえ作れないかもしれないからだ。
　
■リリーススプリント
　…スクラムを始めたばかりのスクラムチームが採用することが多い。これは通常のスプリントが終わったあとに、リリースに必要な作業を片づけるための時間を最後にまとめて取るやり方だ。通常のスプリントとは違って、その期間のことをリリーススプリントと呼んでいるだけで、やり方はとくに決まっていない。スクラムイベントも必要なければやらなくていい。

　スクラムで大人数による開発はできるのだろうか？作るものの規模が大きければ開発する人の数も多くしたくなるだろうが、スクラムでは開発チームの人数は３～９人の少人数が適切とされている。


■ボクくんがスクラムのプロジェクトを通じて気づいたこと
・ロールは単なる目印
・開発を進めるうえで大切だと思うことは何でも話し合っておく
・スクラムチーム全員がプロダクトバックログについて知っておく
・見積りは推測
・自分たちの作業は自分たちで見積もる
・ベロシティがわかれば、先の見通しが見えてくる
・スプリントプランニングでは確実に終わらせられる計画を作る
・スプリントゴールを守るために毎日検査する
・問題になる前に見つけて対応する
・完成の定義は、スクラムチームで合意する
・タイムボックスに入るようにしていくのが重要
・プロダクトバックログの順序は常に見直しておく
・自分たちの責務について理解しないとうまくいかない
・ベロシティはあくまで目安
・ロールで担当する部分を分けているので、どこに問題があるかわかる
・頻繁に話し合って伝えていくのが一番大事
・スクラムマスターがスクラムチームを良い状態に保つ
・障害に順序をつけてどれを優先的に解決するかを明らかにしておく
・スクラムチームの進む先をいつも明確にするために整理し続ける
・スプリントの準備は開発をうまく進めるうえで不可欠
・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
・全員でさまざまな状況を克服できるようにしておく
・責任を持って取り組んでいくのが大事
・なんでもリリーススプリントに回すのは良くないこと
・スクラムは体験して学んでいくための仕組み

SCRUM BOOT CAMP THE BOOK

西村直人 / 永瀬美穂 / 吉羽龍太郎

なぜか購入したまま放置していたのか、どこかから出てきた。
実践的という意味では非常によくまとまっている。もう少し早く読めば良かったか。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

マシュー・スケルトン / マニュエル・パイス / 原田騎郎 / 永瀬美穂 / 吉羽龍太郎

やや難解。日本語は不自然でないがすんなり入ってきにくい。また日を改めて読み直してみる。
“いまどき”の組織編成のあり方として明確な指針を示していると感じる。将来に通用するかは分からないが、いまはこれがベストだろう。
事前の知識を必要としていて解説が平易でないところも多いうえ、組織を編成する責任者とか所属チームを拡張する一端を担うような人でないと使いどころが無さそう。組織のビジョンをこの書籍で共有することは難しい。

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

西村直人 / 永瀬美穂 / 吉羽龍太郎

アジャイル開発の考え方や運用のコツ、言葉などを一通り学習。未来はすべて決められないことを前提に、しなやかにゴールに到達するチーム運営として、とても参考になる考え方。目的ゴールにワクワクすることが大事、というのは不変。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

マシュー・スケルトン / マニュエル・パイス / 原田騎郎 / 永瀬美穂 / 吉羽龍太郎

コンウェイの法則を意識するのは分かった。
4つの最適なチームや3つのインタラクションモードがあることは分かった。
自分のチームがどんな状況で、どうしたら良いか、考えるために良い本だと思う。

SCRUM BOOT CAMP THE BOOK

西村直人 / 永瀬美穂 / 吉羽龍太郎

漫画でアジャイル活動の説明がされており、初めてアジャイルに取り組む人が一般的な流れを理解するにはとても良い。

サーバ／インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載！]

吉羽龍太郎 / 新原雅司 / 前田章 / 馬場俊彰

今の勤務先では全く経験のないDevOps。転職後の職場で役立つかなと読んでみた。

冒頭でDevOpsとはなんなのか、どのように推進していくのかといったことが説明されていて、何となくイメージできた。今までに触れたことのない文化・概念なので、とても新鮮だ。

その後は関連するツール類を実際に動かしながら説明するような内容。Ansible、CircleCI、Docker、Kubernetesといったツールの基本が学べそう。暇な時にVMを立てて軽く触ってみてもいいかもしれない。今は無料でも気軽にこういう環境を作れて面白い。

Chef実践入門――コードによるインフラ構成の自動化

吉羽龍太郎 / 安藤祐介 / 伊藤直也 / 菅井祐太朗 / 並河祐貴

chefの入門書。実際に試して確認しながら進められるようになっててよいです。
7章のテスト駆動インフラ構築と、10章の大規模システムの構築と運用は参考になりました。

ジョイ・インク 役職も部署もない全員主役のマネジメント

リチャード・シェリダン / 原田騎郎 / 安井力 / 吉羽龍太郎 / 永瀬美穂 / 川口恭伸

みんなで学び合う文化を作る。
この本に早めに出会えればよかったなー、そうすると前職でもっと違う施策をとってだと思う。こういう文化を一から作り、改善が実感できていくのは楽しいだろうなー。

エースを作らず、皆で必要な無駄を取り入れて成長する
ペアプロ、デイリースタンドアップミーティングなどなど
二重投資が実は最短で低コスト、というマインドと自負を持つべきですね。

あと、ルールと計画に厳格なマネージャーではなく、恐怖によらない説明責任のもと、皆で改善して将来の計画を作っていこう、という雰囲気を作るチーム作りが大事と痛感。
これを肝に命じて、自分の仕事を見直していこう。だから、今の会社はマネージャーとは言わない。

ジョイ・インク 役職も部署もない全員主役のマネジメント

リチャード・シェリダン / 原田騎郎 / 安井力 / 吉羽龍太郎 / 永瀬美穂 / 川口恭伸

　読み終わって、うちの会社と比べてみる。
　う～ん、このやり方は絶対楽しいけれども、うちの会社には合わないだろうなぁ。

　ソフトウェア開発会社なのに、二人一組で一つのパソコンを使い、
　オープンスペースのオフィスは、机をつなげればチームの増減に対応できる。
　タスクはすべて無駄なく管理されて、ちょっとこれもやってよ、なんて仕事も発生しない。

　理想の働き方とは。

ジョイ・インク 役職も部署もない全員主役のマネジメント

リチャード・シェリダン / 原田騎郎 / 安井力 / 吉羽龍太郎 / 永瀬美穂 / 川口恭伸

喜び（joy）のある組織の作り方をメンロー・イノベーションズ社が行なっている取り組みを通じて紹介した本。
アジャイル、スクラム開発に沿った経営をしている。
常にペアでの作業を行い、一人のheroによる解決を許さない仕組みは長期的にみて非常に有効。取引先にもその分の費用を出してもらっているというのが素晴らしい。
取引先はだいぶ選ぶことになるので、日本で行うのは難しい印象を持った。
社内で動かせる部分から試していきたい

p180 ボスではなくリーダーを育てる
リーダーシップとは、核となる価値観を都合のよいときだけふりかざすことではない。価値観が崩されそうなとき、立て直しに参加することも意味する。
メンローで一番自然にリードできる人は、受容的で他人を尊重できる人。リーダーは落ち着き、我慢強さ、密かなる自信を示す。

p194 カオスを終わらせる、曖昧さをなくす
要件追加が来た時の対応方法。仕事を片付ける方法を探しても、廊下でプロジェクトマネジメントをやっても生活はよくならない。
そうした時にやる仕事は四半期の初めに設定したゴールとは関係ないことが多い。
朝出社すると、メンバーがアサインしたタスク以外のもので忙しくしている。仕事の責任者はマネージャーなのに、各自の優先事項が管理できない。

p203　ショッキングピンク判断
上司に仕事の割合を知ってもらうために、ボードにタスクカードの一覧を使い、新規開発以外のタスクにどれだけの時間をかけているかを知ってもらうため、ピンク色の目立つカードにして見分けがつくようにした

CakePHPで学ぶ継続的インテグレーション

渡辺一宏 / 吉羽龍太郎 / 岸田健一郎 / 穴澤康裕

CIに関するトピックをひとまとめに紹介している本。僕がCakePHPを使って、開発をしているため、参考になるところも多かった。ただ、PHP-UNITの具体的な使い方などは公式のドキュメントを参照する必要がある。