角征典のレビュー一覧

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

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

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

プロジェクトの振り返りの参考にしようと購入した。
全体的に「欧米か！」って感じの雰囲気が漂っていて、実際に自分が属するチームに受け入れて貰えるか不安。
実現できそうなプラクティスから少しづつ取り入れていきたい。

前書き以下記載がありますが、その通りだと思います。

(第一版冒頭、読者の声より引用)
本書を利用するためにアジャイルチームに属している必要はない。ただ、改善したいと思うだけでよい。彼らのアドバイスに従うことで、あなたのチームはさらに成功へと導かれるだろう。

「ふりかえり」のための実例がたくさん載っています。

スクラムマスターのＢさんに会社に来てもらったとき、この本を紹介されました。

うちの会社では、会議ツールと一緒にこの本を入れて、ときどき活用しています。

関心の分離をしたいのだろうということはなんとなく分かった。「クリーンアーキテクチャ」のことを知りたくてこの本を読んだのだけれど、そこについて書かれているのは数ページ（1章分）だけなので、物足りなさを感じる。周りの概念の部分はそんなにいらないから、核の部分をもっと書いてほしかった（原点って得てしてそう...続きを読むいうものかもしれないけれど）。大風呂敷を広げた感はやっぱり感じてしまい、考え方としては分かるけれど、現実問題として、ピッタリ当てはめることができるものかはよく分からない。ネットでは鵜呑みにするなって言っている人も見かけるし。本書が、エンジニアとしてものすごく響いたかと言えば、否と言わざるを得ない。

翻訳が読みにくい。
語り口が読みにくい。
全体の伝えたいストーリーが見えにくい。
自分がやってるリサーチの抜け漏れのチェックには使えそう

スクラム開発を詳しく知るのには恰好なのだろうけれども、スクラム開発を支持するひとびとのスクラム開発それ自体へのものすごい熱量やこだわりはたまたま巻きこまれてしまった程度の人間にとっては次第に馬鹿馬鹿しく感じられてくる。

第Ⅰ部　イントロダクション
第1章　設計とアーキテクチャ
　ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

…事実は、短期的にも長期的にも崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。

■まとめ
　いずれの場合...続きを読むも、開発組織が自らの自信過剰を認識して回避し、ソフトウェアアーキテクチャの品質と真剣に向き合うことが、最善の選択肢となる。
　ソフトウェアアーキテクチャと真剣に向き合うには、優れたソフトウェアアーキテクチャとは何かを知る必要がある。労力の最小化と生産性の最大化を実現する設計とアーキテクチャを構築するには、そこに到達するためのシステムアーキテクチャの属性を把握する必要がある。
　それが本書の内容だ。優れたクリーンなアーキテクチャと設計がどのようなものかを説明する。本書を読んだソフトウェア開発者は、長期的に利益をもたらすシステムを構築できるだろう。


第2章　2つの価値のお話
　…ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる。


第Ⅱ部　構成要素から始めよ：プログラミングパラダイム
第3章　パラダイムの概要
構造化プログラミングは、直接的な制御の移行に規律を課すものである。
オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである。
関数型プログラミングは、代入に規律を課すものである。

■まとめ
　パラダイムの歴史的な教訓は、アーキテクチャとどのように関係しているのだろうか?「すべて」において関係している。我々は、アーキテクチャの境界を越えるための仕組みとして、ポリモーフィズムを使う。我々は、データの配置やアクセスに規律を課すために、関数型プログラミングを使う。我々は、モジュールのアルゴリズムの基盤として、構造化プログラミングを使う。
　これらの3つが、アーキテクチャの3つの大きな関心事に対応していることに注目してほしい。その3つとは「コンポーネントの分離」「データ管理」「機能」である。


第4章　構造化プログラミング
■まとめ
　構造化プログラミングの価値を高めるのは、反証可能なプログラミングの単位を作成する能力である。したがって、現代の言語では無制限のgoto文がサポートされていない。このことでは、アーキテクチャレベルにおいて、機能分割がベストプラクティスだと考えられている理由でもある。
　最小の機能から最大のコンポーネントまで、あらゆるレベルにおいて、ソフトウェアは科学のように、反証可能性によって動かされている。ソフトウェアアーキテクトは、簡単に反証できる(テスト可能な)モジュール、コンポーネント、サービスを定義しようとする。そのために、さらに上位のレベルにおいて、構造化プログラミングのような制限を課している。
　こうした制限については、今後の章で詳しく調べていきたい。


第5章　オブジェクト指向プログラミング
■まとめ
「OOとは何か?」この質問には、多くの意見と多くの答えがある。だが、ソフトウェアアーキテクトにとって、その答えは明らかだ。00とは「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」である。これにより、アーキテクトは「プラグインアーキテクチャ」を作成できる。これは、上位レベルの方針を含んだモジュールを下位レベルの詳細を含んだモジュールから独立させることである。下位レベルの詳細はプラグインモジュールとなり、上位レベルの方針を含んだモジュールとは独立して、デプロイおよび開発することが可能となる。

第6章　関数型プログラミング
■まとめ
これまでの流れをまとめよう。
●構造化プログラミングは、直接的な制御の移行に規律を課すものである。
●オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである。
●関数型プログラミングは、代入に規律を課すものである。
　これら3つのパラダイムは、我々から何かを奪っている。それぞれがコードの書き方に何らかの制限をかけている。いずれのバラダイムも我々にパワーや能力を与えてくれるものではない。過去半世紀にかけて我々が学んだのは、何をすべきではないかである。
　そのために我々は、歓迎できない事実に直面する必要がある。それは、ソフトウェアは急速に進歩する技術ではないということだ。現在のソフトウェアのルールは、Alan Turingが電子計算機で実行するための最初のコードを書いた1946年のものと同じである。ツールは変わり、ハードウェアも変わったが、ソフトウェアの本質は変わっていない。
　ソフトウェア(コンピュータプログラムの本質)は、「順次」「選択」「反復」と「間接参照」で構成されている。それ以上でもそれ以下でもない。



第Ⅲ部　設計の原則
　SOLID原則の目的は、以下のような性質を持つ中間レベルのソフトウェア構造を作ることだ。
・変更に強いこと
・理解しやすいこと
・コンポーネントの基盤として、多くのソフトウェアシステムで利用できること

■SOLID原則
●単一責任の原則(SRP Single Responsibility Principle)
　コンウェイの法則から導かれる当然の帰結。個々のモジュールを変更する理由がたったひとつだけになるように、ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響を受けるようにする。
●オープン・クローズドの原則(OCP Open-Closed Principle)
　Bertrand Meyerが80年代に広めた原則。ソフトウェアを変更しやすくするために、既存のコードの変更よりも新しいコードの追加によって、システムの振る舞いを変更できるように設計すべきである。
●リスコフの置換原則(LSP Liskov Substitution Principle)
　Barbara Liskovが提唱した有名な派生型の定義。1988年に誕生。要するに、交換可能なパーツを使ってソフトウェアシステムを構築するなら、個々のパーツが交換可能となるような契約に従わなければいけないということ。
●インターフェイス分離の原則(ISP Interface Segregation Principle)
　ソフトウェアを設計する際には、使っていないものへの依存を回避すべきだという原則。
●依存関係逆転の原則(DIP Dependency Inversion Principle)
　上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳細側が方針に依存すべきであるという原則。

第7章　SRP
■まとめ
　単一責任の原則(SRP)は関数やクラスに関する原則だが、同じような原則が別のレベルでも登場する。コンポーネントレベルでは、この原則は「閉鎖性共通の原則(CCP)」と呼ばれるようになる。また、アーキテクチャレベルでは、「アーキテクチャの境界」を作るための「変更の軸」と呼ばれている。これらについては、すべてこの後の章で取り上げる。

第8章　OCP
■まとめ
　オープンクローズドの原則(OCP)は、システムのアーキテクチャの隠れた原動力である。その目的は、変更の影響を受けずにシステムを拡張しやすくすることだ。目的を達成するために、システムをコンポーネントに分割して、コンポーネントの依存関係を階層構造にする。そして、上位レベルのコンポーネントが下位レベルのコンポーネントの変更の影響を受けないようにする。

第9章　LSP
■まとめ
　リスコフの置換原則(LSP)はアーキテクチャのレベルにも適用できる。むしろ適用すべきである。置換可能性に少しでも違反してしまうと、システムのアーキテクチャが特別な仕組みだらけになってしまう。

第10章　ISP
■まとめ
　本章での教訓は、必要としないお荷物を抱えたものに依存していると、予期せぬトラブルの元につながるということだ。
　この件については、第13章「コンポーネントの凝集性」で全再利用の原則(CRP)を扱う際に改めて掘り下げたいと思う。

第11章　DIP
■まとめ
　本書では、ここからさらに上位レベルのアーキテクチャの原則を扱うことになるが、依存関係逆転の原則(DIP)も何度となく登場する。これは、アーキテクチャの図のなかで最も目立つ原則だろう。図11-1の曲線は、後の章では「アーキテクチャの境界」を表すことになる。曲線を横切る依存性が抽象に向かっているが、これは後の章では「依存性のルール」という新しいルールとして登場する。


第Ⅳ部　コンポーネントの原則
　SOLID原則がレンガを組み合わせて壁や部屋を作る方法を伝える原則だとするならば、コンポーネントの原則は部屋を組み合わせて建物を作る方法を伝える原則である。大規模建築と同様に、大きなソフトウェアシステムは小さなコンポーネントを組み合わせて作られている。

第12章　コンポーネント
■まとめ
　動的にリンクされたファイルを実行時にプラグインできる。これが我々のアーキテクチャにおけるソフトウェアコンポーネントだ。ここにたどり着くまでに大変な労力を要する50年だったが、我々は気軽に使えるコンポーネントプラグインアーキテクチャをようやく手に入れることができた。

第13章　コンポーネントの凝集性
■再利用・リリース等価の原則(REP)
　再利用の単位とリリースの単位は等価になる
■閉鎖性共通の原則(CCP)
　同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。
■全再利用の原則(CRP)
　コンポーネントのユーザーに対して、実際には使わないものへの依存を強要してはいけない

■まとめ
　かつての我々は、凝集性に関してそれほど深く考えることはなく、再利用・リリース等価の原則(REP)、閉鎖性共通の原則(CCP)、全再利用の原則(CRP)よりもずっとシンプルに考えていた。凝集性は「ひとつのモジュールはひとつだけの機能を持っている」という属性のことだと考えていた。しかし、コンポーネントの凝集性に関するこれら3つの原則は、それがもっと複雑なものであることを示している。どのクラスをコンポーネントにまとめるかを決めるときには、開発時の利便性と再利用性のトレードオフを考慮する必要がある。アプリケーションのニーズに従ってこれらのバランスをとるのは、簡単なことではない。また、最適な落としどころは常に変わり続ける。つまり、今の時点で適切だった判断が、翌年には不適切になっているかもしれない。プロジェクトが進み、再利用性を重視するようになると、コンポーネントの構成も変わっていくのである。


第14章　コンポーネントの結合
■非循環依存関係の原則(ADP)
　コンポーネントの依存グラフに循環依存があってはいけない。
■安定依存の原則
　安定度の高い方向に依存すること。
■安定度・抽象度等価の原則(SAP)
　コンポーネントの抽象度は、その安定度と同程度でなければいけない。

■まとめ
　本章で取り上げた依存性管理の指標は、設計における依存性と抽象度の関係が、私が「よいもの」と考えているパターンに当てはまるかどうかを計測するものである。経験上、世の中にはよい依存もあれば、悪い依存もある。これらの指標は、私のこれまでの経験を踏まえたものになっている。とはいえ、これらの指標がすべてではない。これは何らかの基準に従って計測しただけにすぎない。だが、万能ではないかもしれないが、それなりに役立つのではないだろうか。


第Ⅴ部　アーキテクチャ
第15章　アーキテクチャとは？
■まとめ
　本章で紹介した2つの物語は、アーキテクトが大規模に採用している原則の小規模な活用例である。優れたアーキテクトは、方針と詳細を慎重に区別して、方針が詳細を把握することなく、決して依存することがないように、両者を切り離す。優れたアーキテクトは、詳細の決定をできるだけ延期・留保できるように、方針をデザインする。


第16章　独立性
■まとめ
　そう、これは一筋縄ではいかないのだ。切り離し方式の変更は設定オプションにすべきだと言いたいわけではない(そのほうが適切なこともあるが)。私が言っているのは、システムの切り離し方式は時間とともに変化する可能性があるということだ。そして、優秀なアーキテクトであれば、そうした変化を予見して、適切に進めていくのである。


第17章　バウンダリー：境界線を引く
■まとめ
　ソフトウェアアーキテクチャに境界線を引くためには、まずはシステムをコンポーネントに分割する。そのなかのいくつかのコンポーネントがコアのビジネスルールになる。必要な機能が含まれているそのほかのコンポーネントは、コアのビジネスには直接関係しないので、プラグインにしておく。次に、コンポーネントにコードを配置して、そこから一方向にコアのビジネスに向かって矢印を描く。
　これは、依存関係逆転の原則(DIP)と安定度・抽象度等価の原則(SAP)を適用したものであると認識すべきだ。依存性の矢印が詳細レベルから抽象レベルを指すようになっている。


第18章　境界の解剖学
■まとめ
　モノリス以外のほとんどのシステムでは、複数の境界戦略を使用する。サービスの境界を利用するシステムが、ローカルプロセスの境界を同時に利用することもある。実際サービスは相互作用する複数のローカルプロセスのファサードにすぎない。また、サービスやローカルプロセスはほぼ確実に、ソースコードのコンポーネントで構成されたモノリスか、動的にリンクされたデプロイコンポーネントのいずれかである。
　つまり、システムの境界は、ローカルでにぎやかな境界とレイテンシーに影響される境界が混在しているのである。


第19章　方針とレベル
■まとめ
　方針の議論には、単一責任の原則(SRP)、オープン・クローズドの原則(OCP)、閉鎖性共通の原則(CCP)、依存関係逆転の原則(DIP)、安定依存の原則(SDP)、安定度・抽象度等価の原則(SAP)が混在している。本章を読み返し、それぞれの原則がどこで使われているのか、どうして使われているのかを確認してもらいたい。


第20章　ビジネスルール
　アプリケーションをビジネスルールとプラグインに分割する場合、実際のビジネスルールがどのようなものかを把握しておいたほうがいいだろう。ビジネスルールにはいくつかの種類があることがわかる。
　ビジネスルールとは、ビジネスマネーを生み出したり節約したりするルールや手続きのことだ。厳密に言えば、コンピュータで実装されているかどうかにかかわらず、ビジネスマネーを生み出したり節約したりするルールのことだ。手動で実行されたとしても、お金を生み出したり節約したりすることはできる。
　たとえば、銀行がローンにN%の利子を付けているとすると、それは銀行のお金を生むためのビジネスルールになる。利子をコンピュータで計算しようと、そろばんで計算しようと、まったく関係はない。
　こうしたルールのことを最重要ビジネスルールと呼ぶ。ビジネスにとって欠かせないものであり、システムが自動化されていなくても存在するからだ。
　最重要ビジネスルールには、いくつかのデータが必要になる。たとえば、ローンであれば、貸付金残高、金利、支払いスケジュールなどが必要になる。
　こうしたデータのことを最重要ビジネスデータと呼ぶ。システムが自動化されていなくても存在するデータだからだ。
　最重要ビジネスルールと最重要ビジネスデータは密接に結び付いているため、オブジェクトの有力な候補になる。こうしたオブジェクトのことをエンティティと呼びたい。

■まとめ
　ビジネスルールは、ソフトウェアシステムが存在する理由である。中心的な機能である。お金を生み出したり節約したりするコードを保持したものである。いわば、家宝である。
　ビジネスルールはそのままでいなければいけない。使用するユーザーインターフェイスやデータベースなど、下位の懸念事項に関わるべきではない。ビジネスルールを表すコードがシステムの心臓部となり、そこにプラグインされるものについては、何も配慮しないことが理想である。ビジネスルールはシステムのなかで、最も独立していて、最も再利用可能なコードでなければいけないのだ


第21章　叫ぶアーキテクチャ
■まとめ
　アーキテクチャは、システムで使用しているフレームワークではなく、システムそのものについての情報を伝える必要がある。たとえば、ヘルスケアシステムを構築しているならば、新しく参加したプログラマがソースリポジトリを見たときに、「ああ、これはヘルスケアシステムだ」と思えるようにしておくべきである。システムの提供方法はまだわからなくても、システムのユースケースをすべて把握できるようにしておくべきだ。そして、あなたのところへやって来て、こう言うだろう。
「モデルのようなものは見えますが、ビューとコントローラーはどこにありますか?」
あなたはこう答えるだろう。
「それは詳細だから、まだ気にする必要はないよ。あとから決めよう」


第22章　クリーンアーキテクチャ
■まとめ
　こうした単純なルールに従うのは、それほど難しいことではない。ルールを守っていれば、いずれ多くの苦痛から解放してくれるだろう。ソフトウェアをレイヤーに分割して、依存性のルールを守れば、本質的にテスト可能なシステムを作り、それがもたらすメリットを受け取ることができる。システムの外部のパーツ(データベースやウェブフレームワーク)が廃れたとしても、そうした要素を最小限の労力で置き換えることができる。


第23章　プレゼンターとHumble Object
■まとめ
　アーキテクチャの境界の近くには、Humble Objectパターンが潜んでいる。境界を越える通信には、シンプルなデータ構造が含まれている。また、境界はテストしにくい部分とテストしやすい部分に分割する。アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。


第24章　部分的な境界
■まとめ
　アーキテクチャの境界を部分的に実装する３つのシンプルな方法を見てきた。もちろんほかにも方法はあるだろう。この３つの戦略はあくまでも例として提供したものだ。
　これらのアプローチには、それぞれ独自のコストとメリットがある。最終的に完全な境界に至るまでの代理として、特定の状況においては適切なものである。境界がうまく設定できなければ、劣化していく可能性もある。
　アーキテクチャの境界をいつどこに作るのか、それは完全な境界なのか部分的な境界なのかを決めるのは、アーキテクトの役割である。


第25章　レイヤーと境界
■まとめ
　ここまでにやってきたことは何を意味するのだろうか?200行のKornshellで実装できるシンプルなプログラムに、どうしてわざわざアーキテクチャの境界を作ったのだろうか?
　この例は、アーキテクチャの境界があらゆるところに存在することを示している。我々アーキテクトは、それがいつ必要になるかに気を配らなければいけない。また、境界を完全に構築しようとすると、コストが高くつくことを認識する必要がある。それと同時に、境界を無視すると、たとえ完全なテストスイートやリファクタリングの規律があったとしても、レイヤーを追加するコストが非常に高くなることも認識する必要がある。
　では、我々アーキテクトは何をすべきだろうか?その答えは満足できるものではない。非常に頭のいい人たちが、抽象化が必要になることを予測してはいけないと提唱してきた。これがYAGNIの哲学である。このメッセージには、オーバーエンジニアリングのほうがアンダーエンジニアリングよりも悪質であるという知見が含まれている。だが、アーキテクチャの境界が必要なところになかったとしたら、境界を追加するコストやリスクは非常に高いものとなるだろう。
　おわかりいただけただろうか。ソフトウェアアーキテクトは未来に目を向けなければいけない。頭を使って推測するべきだ。コストを評価し、アーキテクチャの境界がどこにあるのか、完全に実装する必要があるのか、部分的に実装すべきなのか、無視したほうがいいのかを判断する必要がある。
　しかもこれは、1回限りの決定ではないプロジェクトの開始時に、実装する境界と無視する境界を決めればいいわけではない。常に見張る必要がある。システムの進化に注意を払うべきだ。境界が必要になりそうなところに注目して、境界がないために発生している摩擦の兆候を感じ取ってほしい。
　そこから、境界を実装するコストと無視するコストを比較検討し、その決定を何度も評価する。無視するコストよりも実装するコストが低くなる変曲点で、境界を実装することがゴールである。
　そのためには、注意深く見守らなければいけない。


第26章　メインコンポーネント
■まとめ
　Mainをアプリケーションのプラグインと考えよう。初期状態や構成を設定して、外部リソースを集め、アプリケーションの上位レベルの方針に制御を渡すプラグインである。プラグインなので、アプリケーションの設定ごとに複数のMainコンポーネントを持つこともできる。
　たとえば、開発用、テスト用、本番用のMainを用意することもできる。あるいは、デプロイする国別、権限別、顧客別に用意することもできるだろう。
　Mainをアーキテクチャの境界の背後にあるプラグインとして考えると、設定の問題はもっと解決しやすくなるはずだ。


第27章　サービス：あらゆる存在
■まとめ
　サービスは、システムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。システムのアーキテクチャは、システム内の境界と、境界を越える依存性によって定義される。アーキテクチャは、要素の通信や実行の物理的な仕組みで定義されるわけではない。
　サービスは、アーキテクチャの境界に囲まれたひとつのコンポーネントの場合もある。あるいは、アーキテクチャの境界で分割された、複数のコンポーネントで構成されている可能性もある。めったにないが、アーキテクチャに重要性を持たせないために、クライアントとサービスを結合させることもあるだろう。


第28章　テスト境界
■まとめ
　テストはシステムの外側ではない。安定度やリグレッションのメリットを提供するのであれば、テストもうまく設計すべきシステムの一部である。システムの一部として設計されていないテストは、脆弱で保守が難しくなる傾向がある。保守が難しいので、メンテナンスルームに廃棄されることもよくある。


第29章　クリーン組込みアーキテクチャ
■まとめ
　組込みソフトウェアを開発している人は、組込みソフトウェア以外の経験から多くを学ぶことができる。本書を手にしたあなたが組込み開発者であれば、ソフトウェア開発に関する豊富な知見を発見できるだろう。
　すべてのコードをファームウェアにすると、プロダクトの長期的な健康のためにならない。ターゲットハードウェアでしかテストできないと、プロダクトの長期的な健康のためにならない。クリーン組込みアーキテクチャは、プロダクトの長期的な健康のためである。


第Ⅵ部　詳細
第30章　データベースは詳細
■まとめ
　データの構造であるデータモデルは、アーキテクチャ的には重要である。だが、回転する磁気面上でデータを移動させる技術やシステムは、アーキテクチャ的には重要ではない。リレーショナルデータベースシステムは、データを表形式で管理して、SQLからアクセスするための仕組みであり、これは前者(データモデル)よりも後者(技術やシステム)に近い。データこそが重要なのであり、データベースは詳細なのである。


第31章　ウェブは詳細
■まとめ
　このような抽象化は簡単ではないし、適切な抽象化のためには試行錯誤が必要になるだろう。だが、不可能ではない。この世界には怪しげなマーケティングの奴らが満ちあふれている。抽象化が必要になる場面はいくらでも見つかるだろう。


第32章　フレームワークは詳細
■まとめ
　フレームワークに出会ったら、すぐに結婚しようとしてはいけない。その前に何らかの方法で時間稼ぎができないかを考えよう。フレームワークは、アーキテクチャの境界から可能な限り遠ざけるようにしよう。牛一頭を購入する以外にもミルクを得る手段はあるはずだ。


第33章　事例：動画販売サイト
■まとめ
　図33-2のアーキテクチャ図には、2つの観点での分割が含まれている。単一責任の原則(SRP)にもとづくアクターによる分割と、依存性のルールによる分割である。どちらの分割も、変更の理由や頻度が異なるものを分離することが目的だ。変更の理由に対応するのはアクターによる分割で、変更の頻度に対応するのは方針のレベルの違いである。
　コードの構成をこのようにしておけば、システムをデプロイするときにも思いどおりに進められるようになる。デプロイ可能な単位でコンポーネントをまとめることができるし、仮に状況が変わったとしても、コンポーネントのまとめ方を変更しやすい。


第34章　書き残したこと
■まとめ : 言い残したこと
　いくらうまい設計をしても、その実装方法の複雑さを考慮しなければ、あっという間に設計が崩れてしまう。これが本章のポイントだ。あなたが望む設計をコードの構造にマッピングする方法、そのコードをとりまとめる方法、実行時とコンパイル時に依存性を分割する方法について考えてみよう。使える選択肢は可能な限り残しておきたいが、理想に走りすぎてもい。チームの規模やメンバーのスキルやソリューションの複雑さ、そして時間と予算の制約などを考慮しよう。選んだアーキテクチャスタイルを守らせるためにコンパイラが使えるかどうかを検討して、データモデルなどのほかの領域と結合してしまわないように注意しよう。悪魔は実装の詳細に宿るものだ。

【プロ意識】
■責任を取る
■第一に危害を加えてはいけない
・機能に危害を加えてはいけない
　QAは何も見つけてはいけない
　動作することを「把握しなければ」いけない
　自動QA
・構造に危害を加えてはいけない
　本物のプロは、構造を犠牲にして機能を届けるのはバカのやることだと思っている。コードの柔...続きを読む軟性はその構造にかかっている。構造が不安定ならば未来も不安定になる。
　あらゆるソフトウェアプロジェクトの基本的な前提として、ソフトウェアは変更しやすいというものがある。構造に柔軟性がなくなり、この前提が崩れてしまえば、業界全体の経済モデルが根底から覆されてしまう。
　つまり、ソフトウェアは適切なコストで変更できなければいけない。
…
　すべてはテストに通じる。コードのほぼ100％を網羅する自動テストスイートがあり、思いついたらすぐに実行できるのであれば、コードを変更するのは怖くない。どうすればコードの変更が怖くないと証明できるのだろうか？それは、常に変更すればいいのである。
■労働倫理
・自分の専門分野を知る
※すべてのソフトウェアのプロが備えるべき最低限のこと
▶デザインパターン：GOFの24のパターンについて説明できる。POSAのパターンを実際に使える知識がある。
▶設計原則：SOLID原則を知っている。コンポーネントの原則を熟知している。
▶方法論：XP・スクラム・リーン・カンパン・ウォーターフォール・構造化分析・構造化設計を理解している。
▶規律：TDD・オブジェクト指向設計・構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している。
▶成果物：UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・ディシジョンテーブルの使い方を知っている。
・継続的学習
・練習
・協力
・指導
■ドメインを知る
■雇用主や顧客に対して親身になる
■謙虚


■TDDの3原則
1. 失敗するユニットテストを書くまでプロダクションコードを書いてはいけない。
2．テストを失敗させる目的以外でユニットテストを書いてはいけない。なお、コンパイルできないのも失敗に含まれる。
3．失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはいけない。

■TDDの利点
・確実性
・欠陥混入率
・勇気
・ドキュメント
・設計
　TDDの3原則に従ってテストを書こうとするとジレンマに陥る。下がり甘きたコードのことはすでに頭にある。だが、まだコードがないので、先にユニットテストを失敗させろと3原則に書いてある!これはつまり、これから書くコードを先にテストしろということだ。
　コードをテストする上で問題となるのは、コードを分離しなければいけない点だ。例えば、他の関数を呼び出している関数をテストするのは難しい。テストを書くには、その関数を他から切り離す方法を探さなければいけない。言い換えれば、テストファーストをするには、優れた設計について考えなければいけないということだ。
　テストを先に書かなければ、複数の関数をテストのできない大きな塊に詰め込んでしまうことになる。あとからテストを書くとなると、大きな塊全体の入出力のテストならできるだろうが、個別の関数をテストするのは難しい。
　つまり、3原則に従ってテストを先に書けば、うまく疎結合した設計ができるようになる。優れた設計に導いてくれるツールを採用しないプロがいるだろうか?
「テストなんかあとで書けるよ」と言うかもしれない。だが、それは違う。あとで書くことはできないのだ。本当に。あとで書けるテストも少しはあるだろう。注意深く計測していけば、あとでカバレッジ率を高めることもできるだろう。だが、あとで書いたテストは防御なのだ。先に書くテストは攻撃である。あとで書くテストは、コードを書いた人や問題の解決方法を知っている人が書くものだ。こうしたテストは、先に書くテストほど鋭いものではない。


■早すぎる詳細化
　ビジネスもプログラマも「早すぎる詳細化」の罠に陥りがちだ。ビジネスは、プロジェクトを承認する前に、これから手に入れるものを正確に知りたいと思う。開発者は、プロジェクト見積もる前に、これから開発するものを正確に知りたいと思う。どちらもできるはずのないことを詳細化しようとして、コストを無駄にしているのだ。
・不確定性原理
　問題は、紙に書かれたものと実際に動くシステムが違うことだ。仕様どおりに実装されたシステムを見ると、ビジネスは自分の欲しかったものじゃないと言う。要求が実際に動いているのを見ると、もっとよいアイデアが浮かんでくる。そして、それは目の前にあるものじゃない。これには、観察者効果(あるいは不確定性原理)が影響している。動いている機能をビジネスに見せると、新しい情報を与えたことになる。そして、その新しい情報は、システムの見方に影響を与える。つまり、要求を詳細化していくと、開発中のシステムとかけ離れていくのだ。
・見積もりの不安
見積もりの不安
　開発者も詳細化の罠に陥ることがある。システムをもっと正確に見積もらなければいけないと思っているのだ。だが、正確に見積もることなどできない。
　まず、完全な情報を持っていても、見積もりにはバラツキがでる。次に、不確定性原理によっさて、早すぎる詳細化は無効にされている。要求は変化するので、詳細化は現実的ではないのだ。
　プロの開発者は、精度の低い要求からでも見積もりは可能であり、見積もるべきであることを理解している。また、見積もりは見積もりであることもわかっている。見積もりには必ずエラーバー(誤差範囲)を設けて、ビジネスにその不確実性を理解してもらっている。

中盤までのテストダブルの話や具体的なTDDの事例は記述が明確で分かりやすいが、博物館的が雰囲気もあり、ブランチは使わないのが好ましい、ミーティングの招待は辞退しよう、など固執すると危険そうな価値観も多く記述されている。

リサーチクエスチョンの設定こそが大本質。業務上実務的なリサーチの勘所が知りたかったので、今読みたい本では無かった。

一緒に作業をしつつコーチングをして社内政治にも負けず、環境ができたら立ち去る。これを社内の一メンバーが逆境の中で達成できるとは思えない。
上記が難しく感じるのは、本書が立派なコーチになるための手段の説明を主に書いているからであり、個々のプロセスの目的や必要性の記述が薄いからだろう。
社内政治に勝つの...続きを読むではなく、一つ一つのプロセスの目的を説明した上でお互いにとって利益があることを確認しながら体制を変えていく必要があり、それに伴ってコーチも正当に評価される環境を目指す必要がある。

第一章から三章までが凄く大事な事が書いてあると思った。
プロのエンジニアとして、どのように責任を持つのか、仲間とどうコミユニケーションを取っていくべきなのか、について著者の経験談を元に詳しく書かれていた。

エンジニアのインターン1年目の自分としては、働く中で核となる考え方を得ることができ良かった！...続きを読む

(四章目以降は、知っている事が多いようにも思えた)

アジャイルに対してどういう思いで議論され、生み出されたのかを感じるできる本です
スクラムなどの実践的な手法の説明ではないので、そういう事を求めてる人には合わないと思います
一方で全体としてアジャイルとは何かを考えたい人には合う本ではないですしょうか

コードレベルのパラダイム、モジュールレベルとコンポーネントレベルの設計原則、アーキテクチャレベルの検討ポイントというように整理されて書かれているため、初学者でも混乱せずに学んでいくことができる。

チームで「ふりかえり」を実施するために使えるアクティビティやファシリテーターの心得が書かれてる。手引き書なので実戦で使ってみないと分からない部分はありますが、「ふりかえり」の本はあまり見かけない中で貴重な1冊でした。

レトロスペクティブとは、「反省」、「ふりかえり」といった意味。本書は、アジャイル系プロセス（ソフトの開発方法の一つ）でのレトロスペクティブのやり方を解説する。一つのイテレーションの終わりにレトロスペクティブを実施することで得られる効果は・現イテレーションの問題点を、次で改善・現イテレーションでうまく...続きを読む言った点の強化、「文化」化・チームのコミュニケーションが盛んになる・プログラマーの社会性が高まるなど多岐にわたる。要は、plan-do-check-act(PDAC)のcheckにこのレトロスペクティブを使うとうまくいくということである。納得できる点も多々あるが、問題点もある。それは、なにかというと、レトロスペクティブのファシリテーションがすごく難しいということである。本書の大部分は、このファシリテーションについての解説であるが、ファシリテーション・リテラシーが低い人（おそらくほとんどのプログラマーはそうだろう）には、その解説が頭に入ってこないと思う。私の場合もそうで、中盤を過ぎたあたりからなんとか理解できるようになった。しかし、理解と実践は大きな隔たりがある。理解すら容易ではないのに、その実践たるや、想像を絶する難しさである。とはいえ、アジャイルな取り組み方でとりあえずはじめてみようか、とも思う。

期待したほど面白くなかった。


「フード三原則」
１．善人は、フードをおいしそうに食べる
２．正体不明者は、フードを食べない
３．悪人は、フードを粗末に扱う

　言葉のチカラというのはすごいもので、「圧倒的当事者意識を持て！」と伝えるだけで、「何だかよくわかんないけどやらなきゃ！」という意識に変わ...続きを読むりました。

　発想は、単純、素直、自由、簡単でなければならない。そんな、素直で自由な発想を邪魔するものの一番は何か。それはなまじっかな知識―知っていると思う心―である。