和智右桂のレビュー一覧

継続的デリバリー 信頼できるソフトウエアリリースのためのビルド・テスト・デプロイメントの自動化

JezHumble / DavidFarley / 和智右桂 / 高木正弘

継続的デリバリーの化身みたいな人が書いた本
ソフトウェア開発をするのであれば、確実に読んでおきたい一冊

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

"今までのリーダーシップとは違う" という内容ではなく、現代のリーダーに必要な考え方や行動を "あらためて" まとめました、的な本ととらえる方が良いと思いました。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

極めて実践的な本。
他の本にあるような崇高なリーダー像、マネジメント手法を描くのでは無く、チームリーダーレベルで少しずつ現場に取り入れる事が出来るように意図されている。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

「ドメイン駆動設計」なるものは何なのか。
例えばテスト駆動開発であれば、テストを実装しそこからレッド→グリーン→リファクタリングと進んでいく。
ではドメイン駆動設計はドメインが起点かというと、むしろリファクタリングしながらドメインを浮き彫りしていく彫刻のようなアプローチが望ましいようだ。
(第八章ブレイクスルーのあたりにくわしい)

一度通読しただけで完全に理解できるような代物ではないが、いかにしてコード、そして設計にドメインを注入していくのかというコア部分は必読。

第4部、戦略的設計は内容的にも入り組んでおりやや難解に感じた。再読が必要だ。

重厚で、かつ内容を噛み砕きながら読む必要があるため相応の覚悟は必要。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

初見だと新しい概念が大量に出てきて、理解できないままどんどん話が進んでいきます。

それもあり放置していた本ではあったのですが、DDDで設計されたプロジェクトに入った機に再読。
実際に触りながら読むと、前より理解しながら読み進めることができました。


時代背景も今と違うため、素直に全てを受け止めるのではなくどんな理由があってなにを解決するために生まれたものかを理解するのが大事かと思われます。

特にアーキテクチャとしての戦術的DDDをDDDの全てとして受け止めてる人も多く、その辺りが曖昧になると本質を見失ってしまいそうです。

１回読んだだけで理解できる本ではないため、実践を繰り返しながらより深い理解を進めていきたいと思います。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

重厚な本で、読みきるのに結構時間がかかる。
筆者が開発を行っている際に現れた課題を題材に、どのように解決に向かっていくのかを、参考にした他の著書やパターンなどを引用しつつ、DDDの概念に当てはめて説明していく形になっている。
何よりこの本を読んだことで、複雑なシステムに対するモチベーションが高まった。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

1,2,7章が個人的にはまった。
早く行くためには1人で、遠くに行くためにはチームで、を実践するための考え方、具体的な行動について丁寧に説明しています。

リーダーが決めてくれない、メンバーが考えてくれない、とお互いが思っている状態がやばい、というのはささった。とにかく言語化する、ちゃんと考える時間を取ることが大切。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

リーダーリップについて書かれた本は多くありますが、どちらかというと経営に近い職層の方を対象にしたものや比較的大きな・大人数の組織を束ねる人を対象にしたものが主流な印象があるなかで、この本はいわばリーダーの底辺にいる人たちを対象にしたものになっています。いってみれば”リーダー”の中でも最大多数の人たちに向けて書かれた貴重な本であるといえます。内容も日常的な業務で発生しうる課題にフォーカスしたものになっており、リーダー必読の書だと思います。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

誰しもチームで仕事をしたことがあると思うが、リーダーに限らず、チームで成果を出すために、明日から簡単に実践できるテクニックがつまっている。
著者が実際に経験したことベースで書かれているからこそ、読みやすい。よくある、理論だけのリーダーシップ本とは一線を画している。
仕事で困った時の「お助け辞書」としても活用が可能だと思う。そのくらい現場ですぐに使えるものが詰まっている。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムのあるゆることが網羅されている。かなりのボリュームだけど手引き書としてとても良いと思う。
これまでの経験や知人から聞いたような事柄をいろいろ思い出して、自分の経験知識のおさらいになった。よくまぁこれだけ的確な文章で書ききったなと。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

京都で読書会をやってました。
序盤のDDDの基礎的な部分も面白いが、後半の実践するための様々な手引き部分が業務とリンクしてとても読み応えがある。
ただ、モデリングを始めようとして手に取ると、モデリング手法については一切触れていないので不完全燃焼になるかも。
この本はあくまでもモデリングができる前提で、モデルを利用した開発の仕方を説明している本なので注意が必要。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

ある程度以上の規模を持つシステムを構築する際には、一通り目を通しておくべき書籍です。
ESBによるシステム統合のベストプラクティス(コンテキスト境界)と同じ話が出てきてびっくりしました。合併によるシステム統合の際などにも、参考になるアイデアがいろいろ詰まってます。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

ドメイン駆動設計の原典。
原典だけあって一度は目を通しておきたいし、じっくり読み込む機会を設けたいと思う一方、本書と同じ言葉で語るには訓練が必要である（たとえば「モデル」という言葉）。

理解はしたいが、おすすめはしづらい。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムの基本的なポイントがおさえられ、かつ現実的に制約になりえるところ(複数プロダクトを見るチーム、SMと開発者の兼任など)にも目配りされた網羅的な一冊。
「グルーミング」など最新のスクラムガイドでは用いられていない用語があったり、この一冊だけでスクラムと向き合うにはいささか時が流れすぎてはいるが、ある程度習熟しているなら自己点検の意味でも読む価値のある一冊。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムを導入した会社のBiz側として必要な章だけかいつまんで、通読。
一気にスクラムの理解が深まった。

あとは業務上で必要な時に辞書として使うのが良さそう。

エリック・エヴァンスのドメイン駆動設計

EricEvans / 牧野祐子 / 和智右桂 / 今関剛

DDDの文脈で「エンティティ」「バリューオブジェクト」「サービス」「集約」といったものが何を指すのか理解できました。実践ドメイン駆動開発は現在精読中ですが、こちらの本を先に読む方が良いと思います。
「境界づけられたコンテキスト」がマイクロサービスと相性が良いと言いますが、マイクロサービスに関する和書は数少ないためその意味でもこの本は重要だと思いました。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

和智右桂

「言葉」を大事にする、という姿勢はよく分かるし好感が持てる主張で、自分も近似値でもいいから言語化して伝えようとする努力の中から得られるものがあると常々思っている。

「思考を晒す勇気」「間違いを受け入れる謙虚さ」「自分の心の揺れに気づく」などあらためて内省の材料になる部分もあった。

それと、和智さんは、訳本より自らの言葉で語る文章の方が向いている人だな、と思った。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

翻訳が読みやすくてサクサク頭に入るのがすばらしい。ところどころにLeffingwellさんの名前が出てくるからSAFe系の図解が多く、エンプラ系に響きそう

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムを始めたときから、何回も開いている。
ここに答えはないが、考えるための要素がある。

これまで一気通貫で読んだことがなかったので、通しで読んでみた。
結果、あらためてスクラムは難しいと思った。

予想として良しとするのか、コミットメントしてやり切るのか。
どっちが正解なのかわからない。

本気なのか適当なのか。
本気でやってても、他人からみたら適当レベルに見えるかもしれない。

ただ開発はチームで行っていて、人と一緒にチームを形成している。
一人ひとりが異なるのだから、どのチームでも正解なんてないのと同じように、
そういうことを受け取られる可能性の一つがスクラムなのだと思う。

スクラムを用いることで、チームに最低限のルールを示し、
一人ひとりが異なることを前提に、チームで前進していくしかないのだろう。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
○私自身は、開発チームはすべからく、各スプリントで何を届けられるかを予想（見積もり）しなければならないということに賛同する。しかし、予想を基にコミットメントを導きだすことで、利益を得られる開発チームも多い。コミットメントによって、プロダクトオーナーと開発チームの間にも、開発チームの内部にも、相互の信頼関係が築かれる。（P.18）
○プロダクト開発の初日には、自分たちが何をしているかについての情報は最も少ない。開発が続くにつれて、少しずつ学習していく。それではなぜ、最も重要で、おそらくやり直しの利かない判断を初日、もしくは初期に行おうとするのだろうか？（P.38）
○ただ実際のところは、ほとんどの技術的ストーリーはプロダクトバックログに入れるべきではない。代わりに、これらのストーリーはビジネスストーリーの関連タスクとするべきだ。（P.88）
●プロダクトバックログアイテムの例：PBIの形式は、フィーチャー、変更、不具合対応、技術的な改善、知識の獲得
○みんなでグルーミングすることでさまざまな意見がを引き出せることを知っている。みんなの意見や、それぞれの立場から視点を活かせば、重要な情報をもれなく引き出せる。また、いろいろな立場のチームのメンバーをグルーミングに参加させると、プロダクトバックログについての明確な理解を共有できる。（P.102）
○見積もりはコミットメントではない（P.120）
○技術的負債があまりにも増えすぎてしまうと、そのプロダクトに関して何らかの予測をするのはほぼ不可能になる。（P.139）
○負債を返済する手段として一括払いを選ぶことが多い。それよりは、何回にも分けて、適切なタイミングでインクリメンタルに既知の技術的負債を返済していくほうがよい。（P.154）
○チームを小さく保つ理由を以下のように述べている。
・誰かがやってくれるから自分はやらあくてもよいという「社会的手抜き」が少ない。
・小さなチームは建設的なやり取りが頻繁に発生する。
・調整に必要な時間が少ない。
・誰も陰に埋もれることがない。
・小さなチームのほうがメンバーを満足させることができる。
・有害な過度の専門家が発生しにくい。（P.197）
●Appelo による7段階の権限レベル、通知、説得、相談、合意、助言、確認、委譲（P.218）
●伝統的なプロジェクトマネージャーの責務は一貫性の管理、スコープ、時間、コスト、品質、チーム、コミュニケーション、リスク、調達。PO、SM、開発チームはこれらの責務を分割、あるいは共有する。（P.226）
○事前にきちんと計画を作れると思うな（P.235）
●プランニングのレベル（P.244）
・ポートフォリオ：おそらく年単位
・プロダクト：数か月単位、あるいはもっと長期
・リリース：3か月から9か月
・スプリント：1週間から1か月
・デイリー：毎日
○MRFは最低限の「必須」フィーチャーを表すものだ。つまり、顧客が期待する価値や品質をもたらすために、今回のリリースに必ず含める必要があるフィーチャーである。リリースプランニングの中でも重要なのが、今回のリリースにおける真のMRFが何なのかを再評価して見直すことだ。（P.300）

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムについて一通りに情報が記載された一冊。

スクラムになれた人がきになる部分をつまみながら読むとスクラムを更に加速させることができる1冊。