角征典のレビュー一覧

アジャイルコーチング

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

アジャイルコーチング

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

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

エッセンシャル スクラム

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

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

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

Clean Agile 基本に立ち戻れ

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

アジャイルのポエム。
本じゃなくても、Qiitaとかで読めれば良さそうな内容。
XPのプラクティスが重要。
デイリースクラムは、必須じゃないとか。
ペアプログラミングも常時やらなくても良いとか。
クラフトマンシップ、職人宣言とか。
Scrumで最初はガチガチの型に嵌めてやれとは少し趣が違った見解。

プロダクトリサーチ・ルールズ 製品開発を成功させるリサーチと9つのルール

アラス・ビルゲン / C.トッド・ロンバード / マイケル・コナーズ / 角征典

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

エッセンシャル スクラム

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

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

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

RobertC.Martin / 角征典

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


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

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


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

Clean Craftsmanship 規律、基準、倫理

RobertC.Martin / 角征典

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

プロダクトリサーチ・ルールズ 製品開発を成功させるリサーチと9つのルール

アラス・ビルゲン / C.トッド・ロンバード / マイケル・コナーズ / 角征典

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

アジャイルコーチング

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

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

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

RobertC.Martin / 角征典

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

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

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

Clean Agile 基本に立ち戻れ

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

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

エンジニアのためのデザイン思考入門

角征典 / 東京工業大学エンジニアリングデザインプロジェクト / 齊藤滋規 / 坂本啓 / 竹田陽子 / 大内孝子

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


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

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

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

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

KentBeck / CynthiaAndres / 角征典

古典の第2版。初版と印象が違う。「はじめに」に意図が書いてある。初版への批判（傲慢・強制的）に応えて（堪えて？）書き直したとある。

価値と原則とプラクティスのフレームワークって日本人にはあまりない考え方。でも西洋人は好き。