角征典のレビュー一覧

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

あの有名なアーキテクチャの図ばかりが取り上げられるがデータベースやWebといった「詳細」に依存しないようにビジネスロジックを再利用可能にし、ソフトウェアをソフトに保つアーキテクチャ設計が書かれた本。DDDと実装として使われることがあるけど、この本の中ではDDDという言葉は一度も使われてなくて意外だった。

Clean Agile 基本に立ち戻れ

RobertC.Martin / 角征典 / 角谷信太郎

アジャイルの生みの親の一人である著者による一冊。
間違って利用されることも多いアジャイルと言う言葉ですが、本書を読むことで基本に立ち戻り、改めて理解することができます。

アジャイルコーチング

RachelDavies / LizSedley / 永瀬美穂 / 角征典

身についている、実践できていることがほとんどだったが、客観的なアドバイスがまとまっており、自分でたまに読み返すのも、慣れてきたスクラムマスターに読んでもらうのも良さそう

Clean Agile 基本に立ち戻れ

RobertC.Martin / 角征典 / 角谷信太郎

読み終わるまでに結構が時間がかかりました、
サブタイトル「基本に立ち戻れ」にあるとおりAglileの基本と最近の状況を的確に指摘しており、とても示唆に富む内容でした。

P112 ハムエッグの話は評判がよくなく、最近は参照されない

Clean Coder プロフェッショナルプログラマへの道

RobertC.Martin / 角征典

ボブおじさんの長年のエンジニアとしての経験から、「プロのプログラマーであれば、こう振る舞うべし」と教えてくれる本。
子供が生まれて自分の働き方が大きく変わって早数年。いい意味で自分の働き方を見つめ直す良い機会になりました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

「アーキテクチャ」って何？という質問に説明できる人はどれだけいるでしょうか？

他に、「単一責任の原則」という、「一つのモジュール（ソース）は一つの責任者にすべき」という原則が書かれているのですが、この原則について、誰か教えてくれた人はいるでしょうか？
（実際、私は、この原則をわかっていたつもりですが、重要さを意識できておらず、業務上痛い経験があったため、この本の価値がわかりました）

要は、アーキテクチャを理解して、教えてくれる人は、なかなか周りにはいないと思います。
そのような貴重な情報を教えてくれるのがこの本だと思いました。（と言いつつ、私は、2回ぐらい読みましたが、まだまだ理解できていない部分も多く、また何年後かにチャレンジしたくなります）

翻訳ということもあり、文章は読みやすいとは言えないです。また、設計、プログラミング経験、実務経験をある程度持ってないと、イメージがしづらく、読んでいて腑に落ちないところはあるかと思います。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

第4部までと第5部以降で大きく感想が変わる本。

第4部まで（全体の半分弱）は以降の議論のための土台を用意するためにプログラミングパラダイムや SOLID 原則などが解説される。ここは概論がよくまとまっていて、読んでいて楽しい。
ただし、親切丁寧な解説というわけではないので紹介されるそれぞれの概念を初めて知る人向けというよりは、多少なりとも知っている人がよりクリアに理解するための文章という気がする。

第5部以降がこの本の主な主張かと思われるが、ここからは結構癖が強い。
有用な記述もあるものの、全体的な印象としては「理屈はわかるが、それは現実的か……？」と感じるものが多かった。
（あと、読んでいると何故かめちゃくちゃ眠くなる）

後半については原理主義的な強い主張が多く、実践に直結するかと問われると、個人的には No だと言わざるを得ない。
しかし、少しばかり極端な考え方に触れておくことは自分の思考の振り幅を広げる上で有用だと思うので、そういう意味では良い本だと思う。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

優れたアーキテクトは境界を定義し、依存関係の方向性を自由に操り、決定を遅らせることができる。

アーキテクトは未来を常に予測し、境界を設けたときと設けなかったときのコストを意識しYAGNIと格闘し続ける道のりなんだろうなと感じた。

境界をひく正解がない以上、なぜその境界を引いたのか説明できるだけの根拠と経験をもってアーキテクチャを描こうと思った。

Clean Coder プロフェッショナルプログラマへの道

RobertC.Martin / 角征典

最初は読みにくいなぁと思っていた。
ただ、「２章の「ノー」と言う」につい食いつきました。

プロフェッショナルというのはどういうことか？という話なのですが、自分も含め、どれだけプロではないことをしていたのかと反省しました。
責任を持って、出来ないことを言うことが大事であること、コミュニケーションをとって、相手が何を望んでいるかを把握すること。その望みをかなえる為に、別の提案で出来ないかを考えること。

その他、プロが見積もりを立てる時、予定完了時間と分散を使った確立的な見積もりを提出することが多い。不確実性があるから、当たり前のことですね。

今まで、やってみますと言って、残業して必死に対応したものの、あまり役に立たなかった、使われなかったことが多々あるなぁ。もう、そんなのは止めよう。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

設計の指針になることが書いてあります。この本を読んでから、インターフェイスを常に意識するようになりました。

エッセンシャル スクラム

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

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

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

クリーンアーキテクチャについての本だが、ほとんどはその具体的な方法論ではなく良いアーキテクチャの定義に終始している。

そのため良いアーキテクトについて順を追って理解できる本であり、クリーンアーキテクチャ自体よりそこに到るまでの理論の方が重要だと感じた。

アーキテクトのトレンドはあれど、理論の部分に関しては何十年たっても変わることはないものなので、何周も読んで理解を深めていきたいと思う。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

コード片と文章で説明されているので、ある程度プログラマとしての経験がないと理解は難しいだろうなという印象。
デザインパターンが前提知識になっているんですが、あんな23個も覚える必要なかったな、、と遠い目で思います。
JJUGで聞いたクリーンアーキテクチャの実践は、やっぱり面倒だと思うし、規模にもよるけど、保守性を担保するのにここまでやる必要あるのかなと、やや懐疑的。
とりあえずコードは書けるようになったけど、きれいに書くにはどうしたら良いか迷ってる人にはオススメかも。

以下、気になったところの引用。

p34 ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

p119 多くのアプリケーションにおいて、再利用性よりも保守性のほうが重要だ。

p244 ソフトウェアを構築する3つの活動
1.まずは動作させる。動作しなければ、仕事にならない。
2.それから、正しくする。あなたやほかの人たちが理解できるようにコードをリファクタリングして、ニーズの変化や理解の向上のためにコードを進化させていく。
3.それからら高速化する。「必要とされる」パフォーマンスのために、コードをリファクタリングする。

p259 アーキテクチャの観点では、データベースはエンティティではない。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

印象に残ったことメモ

- ソフトウェアアーキテクチャの目的は、「求められるシステムを構築、保守するために必要な人材を最小限に抑えること」である。

- 設計の品質は労力で計測できる。必要な労力が少なく、ライフタイム全体で低く保たれているならば、その設計は優れている。逆に、リリースごとに労力が増えるなら、その設計は優れていない。

- 崩壊したコードを書く方がクリーンなコードを書くより常に遅い。よくある、「あとでクリーンにすればいいよ。先に市場に出さなければ」これは、リリースごとの負担が増えていき、開発スピードが鈍化していき、先にクリーンにしているコードよりも後に市場に出る結果となることが経験的に多いそう。

- オブジェクト指向とは、「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」そのために依存関係逆転の原則を使う。

- 言語パラダイムが進むにつれて進化しているのは、何をすべきではないか、である。

- 安定度/抽象度等価の原則「参照される数が多いモジュールほど抽象的に。参照される可能性がなければ無駄に抽象的にしない。」

- 選択肢を多く残す
上位方針（ビジネスルール、ビジネスロジック）から決める
詳細の決定はできるだけ遅延させる。選択肢を残す（データベース、フレームワーク、ウェブサーバー、GUI、IOなどは変化しやすい）

- ビジネスルール
これがエンティティオブジェクトとなる。エンティティは特定のフレームワークには依存せず、何にも依存しない Plain Old Data で作るべき

- ハードに依存しないコードを書く
レイヤ
　- ソフトウェア　　：ハードウェアに依存しないコード
　- ファームウェア　：ハードウェアに依存するコード
　- ハードウェア

- 組み込み開発では、できるだけファームウェアを書かない。ソフトウェアを書いて、できる限り寿命を延ばす。ハードウェアは進化していく。変化しやすいものに依存していると、そのコードも修正が必要。ハードウェアの変化に合わせてファームウェアは変化していくが、ソフトウェアは変化しない。

エクストリームプログラミング

KentBeck / CynthiaAndres / 角征典

いいこと書いてあるんだけど、なんか読みづらいのは何故なんだろうか。今となっては当たり前に定着したことを、（今の感覚では）必要以上に丁寧に説明しているからだろうか。
でも、当たり前のことこそ明文化するのは大事で、だからこそこうした古典を読むのは大事だと思う。

図解リーン・スタートアップ成長戦略

アッシュ・マウリャ / 角征典

新規事業をどのように立ち上げるか、「リーンスタートアップ」は知っていたが、ちゃんと本で読むのは初めて。書きやすく考えやすく、比較しやすいフレームで、考えるべきポイントがまとめてある。新規事業を検討する社内プロジェクトで使用。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

RobertC.Martin / 角征典 / 高木正弘

クリーンアーキテクチャに限らず、アーキテクチャについての幅広い知見が詰まった一冊です。
もっと若いときに読んでおきたかった本です。
一方で、ある程度現実のソフトウェア開発を経験してからでないと理解しづらいかもしれません。

ところどころ読みづらい部分、やや冗長な部分があるので星マイナス1です。

エッセンシャル スクラム

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）

アジャイルコーチング

RachelDavies / LizSedley / 永瀬美穂 / 角征典

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

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

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

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. リマインダー

アジャイルコーチング

RachelDavies / LizSedley / 永瀬美穂 / 角征典

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