はじめに
今回の本はこちら。
テックスキルばかりに目が向きがちだけど、ソフトスキルも大事。
この本は何度でも読み返したい１冊かもしれない。
いつか「XP を体現してる人だよね」って言われたい😊
そのために XP とは何かを理解し、実践できるようにもう一度読んでみようと思った。
読書メモ
第1章XPとは何か
✧ XP とは、効果のない技術的 / 社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。
✧ XP とは、自分が今日やるべきことを十分に理解することである。
✧ XP とは、明日をよりよくしようとすることである。
✧ XP とは、チームのゴールに貢献した自分を評価することである。
✧ XP とは、ソフトウェア開発で人間としての欲求を満たすことである。
💬 そうか、チームのゴールに貢献した自分を評価してあげていいんだ。自己肯定感低すぎて、結果的によかったことでも私なんか・・・ってつい言ってしまう。もう少し自分のこと認めてあげてもいいのかな。
第Ⅰ部 XPの探求
第2章 運転を学ぶ
ソフトウェアはあらゆるものが変化する。
問題は変化ではない。
問題はむしろ、我々が変化に対応できないことにある。
💬 変化に対応するための柔軟さ、柔軟な考え方は大事だが、人の意見に流されるのとは違う気がする。でも本当にどっちでもいいなと思うときは多数派の意見でいいかなと思う。
それぞれのプラクティスは、チームの能力、コミュニケーション、自信、生産性を向上させる実験だ。
💬 それぞれのプラクティスは実験という考え方よき。実験には失敗がつきものだから。成功しない方法を見つけただけと思えば失敗ではなくなるのかもしれない。絶対に失敗しない人なんていないんだから、失敗からの学びを大切にしたい。
第3章 価値、原則、プラクティス
プラクティスは日常的な取り組みである。
価値とは、ある状況における好き嫌いの根源にあるものだ。
価値がプラクティスに目的をもたらすように、プラクティスは価値の説明責任を果たしているのである。
価値とプラクティスのギャップを埋めるのが原則だ。
原則とは、その分野に特化した活動指針である。
本書を読んでも、エクストリームプログラマーにはなれない。
たとえ XP の一部であっても、学習したり試したりすることは有益である。
💬 一度に全てをやるのは難しい。意識してやることを１つだけ決めて、まずは１週間試してみよう。
第4章 価値
本当に重要なのは、個人としてではなく、チームや組織の一員としてどのように振る舞うかである。
XP では、開発を導く５つの価値を採用している。
コミュニケーション、シンプリシティ、フィードバック、勇気、リスペクトだ。
コミュニケーションは、チーム感覚や効果的な協力関係を生み出すために重要なものである。
「最もシンプルで、うまくいきそうなものは何ですか？」
💬 これはパワーワードだと思った。うまくいかないと意味がない。シンプルさの追求はその後でも遅くないかな。
ソフトウェア開発において人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。
💬 チームに対する個人の貢献をリスペクトする 人のダメなところにばかり目がいくのは誰だって同じだろう。どんな形であれ誰しもチームに貢献していると思う。それを見つけ、認め、称賛し、感謝する。褒め活はやっぱり大事だと思う。
第5章 原則
人間性
労働時間を制限すれば、こうした人間の欲求を満たす時間を確保したり、チームと一緒にいるときの個人の貢献度を高めたりすることができる。
💬 チームで働く時間を 9:00~17:00 としているのは、理にかなっているのかと改めて気づいた。チーム活動の時間を長くすればチームへの貢献度が高まるわけではない。
優れたチームが素晴らしいのは、メンバーたちが信頼関係を築いてから一緒に働くことによって、みんなが自分らしくいられることである。
💬 同じチームで働くのに、メンバーを信頼していなかったら一緒に働くのは難しいと思う。誰しも完璧な人間なんていない。だからこそ、チーム内でうまくサポートしあいながらチーム活動ができたらいいなと思う。
経済性
最優先のビジネスニーズを最初に解決すれば、プロジェクトのバリューを最大化できる。
💬 ビジネスニーズを最初に解決するのか。そしたら、ニーズは何なのかを把握することから始まるのかな。
相互利益
コンピュータービジネスとは、人間のビジネスであり、仕事上の人間関係を維持することが大切である。
💬 win-win な関係になるのって難しそう。この本ではプラクティスとして、自動テストを書く、リファクタリングをする、一貫性のある名前の付け方をする、の３つが挙げられている。どれもやれてる気はするけど、まだ今のプロダクトに途中参加している Devs がいないので、今後 join してくるメンバーにいつか話しを聞いてみたいなと思った。
自己相似性
💬 似ているものを他のところで応用する
ある文脈でうまくいった構造をコピーしたからといって、他の文脈でうまくいくとは限らない。とはいえ、まずはそこから始めるのがいいだろう。
💬 他のチームでうまくいってるコードをコピーして使ってもうまくいかないことが多い。だけど、ノーアイディアなら試しにやってみて、エラー文から考えるのはありなんだろうな。
改善
XP のポイントは、改善によってソフトウェア開発の高みを目指すことだ。改善のサイクルでは、明日をよりよくするために必要な気づきや理解を追い求めながら、今日できる最高のことをやる。完璧になるのを待ってから始めるわけではない。
💬 昨日は昨日できる最高のことをやっただろうか？今日をよりよくするために必要な気付きや理解は何があっただろうか？日々改善するためには必要な問いかけなんだろうな〜と思った。
多様性
みんなをリスペクトして、自分の言い分を主張すれば、ストレスのかかる状況であってもコミュニケーションは円滑になるはずだ。
💬 自分の意見が大事にされたいと思ったら、相手の意見も同様に大事でリスペクトしないといけない。意見は正しいとか間違ってるとかないと思う、だから色々出た意見からより良い方法は何かを見つけ出そうとする努力が必要なのだと思う。
ふりかえり
ふりかえりは「公式」の機会に限定すべきではない。
💬 食事しながら、お茶しながら、「非公式」な場で一緒にふりかえるという方法もあるらしい。飲み会で自然と仕事の話なったり、意識してふりかえりをしているつもりはなくても、気づきを得られたり、雑談って大事だよねって話はこんなところにもつながったりするのかな・・・。
流れ
流れの原則では、改善のために小さなバリューを何度もデプロイすることを提唱している。
💬 価値は小さくてOK。早くデプロイして、早くフィードバックをもらうことで、問題の大きさを最小限に留めることができる。２週間毎くらいでしか本番環境へのデプロイをしていないけど、私はもっとこまめに本番環境へもデプロイしたいと思っている。ユーザーには見せないようにデプロイする方法あるのかな？
機会
XP の実践を始めると、必ず問題に直面する。エクストリームになるというのは、それぞれの問題を個人の成長、人間関係の深化、ソフトウェアの改善などの機会に意識的に変換することである。
💬 ポジティブシンキング。そして人間関係構築は重要だな〜と改めて感じた。仕事ではこの人はいいけどこの人は嫌いとか個人的な感情は一旦脇に置いて、開発しているプロダクトの成長にどう貢献するかだと思う。誰にだって合う合わないはあるけど、まずは相手の話を批判せず、一旦受け止め、自分の意見を伝える。簡単そうで難しいが実践していきたい。
冗長性
冗長性はムダにつながる可能性がある反面、目的の達成に必要な冗長性は排除しないように気を付けておかなければいけない。
💬 冗長性ってムダばかりじゃないんだ・・・。
失敗
何をすべきかわからないときには、失敗のリスクを受け入れることが成功につながる最短で確実な道である。
💬 気軽に失敗しよう。できない方法を見つけただけだ。なぜできなかったのかを知れば、解決にグッと近づく。
品質
きれいだが時間のかかる方法を知っていれば、今の時間でできる限りのことをすればいい。そして、あとからきれいな方法で完成させるのだ。
💬 リファクタリングにたくさんのまとまった時間を使わなくても、日々のコーディングの中できれいに書ける方に少しずつ寄せていく。ボーイスカウトっぽい感じがする。
ベイビーステップ
「あなたができる最も小さなことで、正しい方向がすぐにわかるものは何ですか？」
💬 実装を変更するときは、一気にやろうとしない。少しずつ進めば手戻りも少ない。
責任の引き受け
ストーリーを実装する担当者が、ストーリーの設計、実装、テストの責任を最終的に担うというものもある。
責任には権限が伴わなければいけない。
💬 実装に責任は持つけど、時間が経って学びが増えて、前に書いたコードがよいとは言いがたいものだったとしても、それ誰が実装したの？とかではなくて、こうすると良くなるから変更しようか！ってなるといいな。
結論
原則がプラクティスの意図を教えてくれる。
原則を理解すれば、既存のプラクティスと全体のゴールに調和したプラクティスが作れるようになるはずだ。
💬 たくさんの原則をみてきたが、ポジティブに考えられるか、メンバーを尊重できるかなどの人に関わる話と、小さなステップで進めて早くフィードバックをもらうなどの開発手法に関わる話、この２つについて話しているように感じた。どれも理解はできる。体現できるようにベイビーステップで始めよう。
第6章 プラクティス
XP のプラクティスは組み合わせたほうがうまくいく。
💬 毛色の違いそうなものは負荷も少なく組み合わせやすいかも。
第7章 主要プラクティス
全員同席(Sit Together)
クライアントが主張する問題が何であろうと、それは常に人の問題であることだ。技術的な処置だけでは不十分である。
全員同席して、あらゆる感覚を使ってコミュニケーションすることの大切さだ。
💬 オンラインでつながるより、オンサイトで会話した方が話しやすい気がする。だけど 9:00 ~ 17:00 の間、気が休まるタイミングがあまりないので、毎日オンサイトでペアプログラミングをやってたら結構しんどいかも〜とコミュ障の私は思ってしまう。。。
チーム全体(Whole Team)
💬 1日に無理なくやりとりできる人数 → 12人、全員の顔を覚えていられなくなる人数 → 150人
個人的な闘値はもっと低いが一般的な値はそうらしい。
💬 複数のチームに属すると生産性は下がり、チーム感が失われる。タスクの切り替え時間がムダ。チームには100%参加するのが効率的。
情報満載のワークスペース
💬 15秒で状況を把握できるワークスペースが必要。Tracker でタスク管理はしているけど、進捗確認はしてないかも。朝のミーティングで軽く確認する場を設けてもいいのかなって思う。
いきいきとした仕事
生産的になれる時間だけ働くこと。無理なく続けられる時間だけ働くこと。
💬 毎日9:00~17:00がチーム活動専念時間となっている。その時間で個人ワークする時間はないので、私は毎日グッタリしちゃう。
ペアプログラミング
パートナーがハマったら主導権を握り、相手の失望感を軽減させる。
💬 多分メンバーの中で一番私がハマりやすい｡｡｡＿|￣|○ だからペア相手がすかさず助け舟を出してくれるとかなりありがたい。だけどペア相手がハマってて私が助けられることのが少ないのが残念すぎる😥
ペアとパーソナルスペース
咳をするときは口を押さえること。病気のときは仕事を休むこと。パートナーが気になるような強めの香水は避けること。
💬 ここでは香水の話をしてるけど、タバコの臭いもやめてほしい。タバコを吸わない人の健康を害する行為は絶対にやってはいけないと思う。
ストーリー
XP スタイルの計画づくりの特徴は、ストーリーを書いたらすぐに見積もることだ。こうすることで、最小の投資で最大のリターンを得る方法を考えられる。
💬 チーム開発では、PdM/PdD がストーリーを書いて、Devs がポインティングしている。時間の使い方って難しいんだよなぁ〜・・・。
週次サイクル
1週間分の仕事の計画をまとめて立てること。
週次サイクルは、チームや個人が実験をするための、手軽で頻繁で予測可能なプラットフォームでもある。
💬 月曜日に「金曜日までにどこまでストーリーを消化できそうか？」を予測して、水曜日あたりに進捗の確認をして、金曜日に予測に対して結果がどうだったか振り返る。あんまり真面目にやってなかったな〜。ちょっとやってみたいな。これをやるとストーリーの見積もり力が上がりそう。
四半期サイクル
四半期分の計画をまとめて立てること。四半期に一度は、チーム、プロジェクト、進捗、大きなゴールの調整について、ふりかえること。
💬 きっとマイルストーンはもっと遠くまでいくつか置いてある気はするけど、ただ置くだけじゃなくて、やってみてどうだったか？をふりかえることって大事だと思う。ふりかえるから、軌道修正ができるのかも。日々の学習にも言えそう・・・。
ゆとり
たとえば、8週間のうち1週間を「ギーク週間」にしたり、1週間の予算の20%をプログラマーが選んだタスクにあてたりすればいい。
💬 ギーク週間って何のことだろう？って思って調べたら、「開発者が通常の業務から離れて自分の興味や新しい技術に集中する時間」のことだった。Pivots がエンゲージメントを終えて次のエンゲージメントまでに2週間くらい間があって、その間にプロダクトを作ってたりするけど、多分それがギーク週間なのかも。私たちのチームは月に１日ランドリーデーと言ってチーム開発はなしで、休んでもいいし、自己研鑽に時間をつかってもいい日を設けてきたが、これがゆとりの施策にあてはまるのかも。
10分ビルド
自動的にシステム全体をビルドして、すべてのテストを10分以内に実行させること。
💬 CI/CD はやってるけど、10分以内に終わってるかな〜？パイプライン見たらだいたいどれも10分以内には終わってそうだけど、9分弱はかかってるなぁ〜。まだそんなに大きなプロダクトじゃないと思うんだけど・・・。
継続的インテグレーション
💬 1日1回以上、コードを main に push して CI/CD 回してるから出来てるって言えると思う〜。
テストファーストプログラミング
💬 TDD 開発してる☆
インクリメンタルな設計
インクリメンタルな設計を取り入れるときは、経験を踏まえたあとに設計するのが最も効果的である。
💬 とりあえずテストをパスするコードを書こう！それから重複しているところはないか？どうすればもっと分かりやすく書けそうか？を考えよう！って話かな？
第8章 始めてみよう
変化は常に自分のいるところから始まる。あなたが変えられるのは、あなただけだ。組織が機能していても、機能していなくても、あなたは自分に XP を適用することを始められる。チームの誰もが、自分の振る舞いを変えることを始められる。
💬 「自分の行動を変えられるのは自分だけ。行動を変えれば未来が変わる。」部屋の見えるところに貼ってはあるんだけどね。アクションプラン大事。
第9章 導出プラクティス
本物の顧客参加
💬 これは難しい・・・。特に顧客が他の職場だと・・・。同じ職場のメンバーが顧客だったとしても忙しいって言われてチームにアサインできなさそう。ん？チームメンバーの誰かが顧客だったらいいのか！なんて・・・。それはそれで尖ったプロジェクトになりそうで面白そう(笑)
インクリメンタルなデプロイ
💬 レガシーシステムをリプレースするときの話は、今はちょっと頭に入ってこなかった。
チームの継続
チームを継続しながら適度なローテーションを行えば、組織は「安定したチーム」と「知識や経験の継続的な広がり」の両方の利点が得られるだろう。
💬 XP ができるメンバーであればって前提がありそう。
チームの縮小
💬 改善するゆとりを持って開発する。日々の開発で少しずつ改善して１人工抜いてしまおう！トヨタ生産方式出てきたwよく工場とかでやってるやつだ。
根本原因分析
💬 なぜなぜを５回繰り返すやつ出てきたwなぜの矛先が人に向かうと人間関係が悪くなるから、あくまでもモノ･コトに目を向けよう。
コードの共有
💬 まずは、その日のコードは main ブランチか、別ブランチに push することだと思う。それからボーイスカウトの原則。
コードとテスト
コードとテストだけを永続的な作成物として保守すること。その他のドキュメントについては、コードとテストから生成すること。
💬 ドキュメントは作るなってことかな？？テストがプロダクトの仕様書になるように書けてればいいんだけど、テストタイトルを書き直すのを忘れてるときがあるから気を付けないとな〜。
単一のコードベース
💬 複数のブランチに分けて開発するなって感じのことが書いてあった。ブランチを分けたとしても数時間以上も維持するなと。たまぁ〜にやってたかも・・・。
デイリーデプロイ
💬 出来てると思ってる☆
交渉によるスコープ契約
今日正しいと思えることをみんなが勇気を持って取り組めるようにするものである。
💬 開発をしていくと日々学びが増えてよりよい方向へ軌道修正できる。そのために短期的な契約をいくつも結び、リスクを減らす作戦。
利用都度課金
💬 ユーザーからお金を取れるほどのアプリを開発してないからよく分からないけど、ユーザーがアプリをどのくらい使ってくれているか、どの機能がよく使われているかなど、行動分析をしてよりよいプロダクトになるよう常に改善が必要なんだな〜。
第10章 XPチーム全体
チーム全体が見失っていたのは、全員がロープに結ばれているという感覚だ。あるグループが先頭になって他のグループを追従させるよりも、全員で足並みをそろえて歩いたほうが、ずっと先まで進めるのである。
💬 なんかどこかで聞いたことがある言葉だな〜・・・。これか？「早く行きたければ一人で行け。遠くまで行きたければ、みんなで行け。」アフリカのことわざらしいです。岸田首相が所信表明演説で言ってたみたいですね。足並みを揃えると時間はかかりそうですが、なんだか楽しそうだし、遠くまで行けたら新たな気づきもありそう☆
テスター
💬 例外処理って忘れがちだな〜。
インタラクションデザイナー
💬 デザイナーの存在は本当に大事。デザインとプログラミングの両方を並行しながら勉強できるほどキャパないし、なんなら CSS が苦手すぎて勉強の手が出ない🥶
アーキテクト
💬 アーキテクチャはちゃんと勉強したいなーと思ってる。
プロジェクトマネージャー
💬 プロジェクトマネージャーとプロダクトマネージャーがそれぞれ書かれているけど、プロダクトマネージャーがやってくれてる気がする。Devs が開発に注力できるのはこうした存在が大きいとつくづく思う。
プロダクトマネージャー
ストーリーの順番は、技術ではなくビジネスの理由で決めるべきだ。
💬 課題を解決するツボを分解すると・・・？
経営幹部
XP チームの評価を決める人たちは、優秀なチームがどのようなものかを理解すべきである。
経営幹部が XP チームを理解し、自身の経験や視点をうまく適用するには、新しい経験則を学ぶ必要があるだろう。
💬 今までの人生の中で経験した成功体験に囚われてるソフトウェア開発未経験者が上司だと XP って理解されるんだろうか🤔
テクニカルライター
💬 ドキュメントって今まであんまり残してこなかったけど、開発に初めて join する Devs 向けに開発環境の構築はどうする？とかアプリの構成はこうなってるとかが書かれたドキュメントは必要だな〜と思う。
ユーザー
💬 XP チームにユーザーは入ってないけど、一番ユーザーのことを知りにいくのがプロダクトデザイナーかな。ユーザーの本心がどこにあるのか？を見極めるスキルって難しそう。
プログラマー
プログラマーは社交性や人間関係のスキルを身に付ける必要がある。
💬 ペアプログラミングをやると絶対にしゃべらないといけないしね・・・。自分自身がめちゃくちゃ人見知りするからフランクに誰とでも会話できる人が羨ましい。
人事
以下は、XP における重要性の高い従業員だ。
✧ リスペクトを持って行動できる。
✧ 他人とうまくやれる。
✧ イニシアチブをとれる。
✧ 約束したものをデリバリーできる。
💬 イニシアチブだけはとれる自信がない・・・。一度だけ学級委員をやったことがあるが、絶対に私には向かない、もう二度とやりたくないと思ったことがある・・・。私はイニシアチブを取ってくれる人をサポートする方が性に合ってると思うし、その方がモチベーションの維持がしやすいし楽しい。
役割
チームが成熟しても、権限と責任のバランスを保つことを忘れないようにしたい。
チームの誰もが変化を提案できるが、その懸念を行動で裏付けられるように準備しておくべきである。
💬 懸念を行動で裏付けるか〜。想像はあくまでも想像で、もしかするとただの思い込みだけかもしれないしね。行動！考動！？
第11章 制約理論
経営幹部の支援やチーム外の人たちとの強い人間関係は、XP の適用に不可欠である。
XP によってソフトウェア開発を整備すると、ソフトウェア開発以外の組織の仕事の構造も変化させてしまうからだ。
💬 プロダクトを通して仕事のやり方や組織のありかたを変えていけたらいいなと思う。今までのやり方をいきなり180度変えるのは難しいかもしれない。だけど、地道に少しずつ周りの理解を得ながら進めたら、今より働きやすい未来になりそうな気がする。だからこそ人間関係って大事なのだと思う。
第12章 計画：スコープの管理
💬 ストーリーのコストにポイントをつけて計画を見積もる手法はこの本の第１版で紹介されていたようだ。しかし、第２版ではどうやら下記にもあるように実時間で見積もるのを勧めている。
だが、今では実時間で見積もるほうが私の好みだ。
そのほうができるだけ明確で、直接的で、透明性のあるコミュニケーションがとれるからである。
第13章 テスト：早めに、こまめに、自動化
💬 ソフトウェアの欠陥は信頼をぶち壊す。人として、ディベロッパーとして信頼してもらえるスキルを身につけたい。
第14章 設計：時間の重要性
XP チームはできるだけシンプルな解決策を好む。設計のシンプリシティを評価する 4 つの基準を紹介しよう。
- 対象者に適している。 設計がいかに見事で洗練されているかは重要ではない。その設計を使うべき人たちが理解できなければ、それはシンプルではない。
- 情報が伝わりやすい (以下省略)
- うまく分割されている。 (以下省略)
- 最小限である。 (以下省略)
💬 理解しようとする努力は必要だけど、何回聞いても理解できないな〜って思うなら、それはシンプルじゃないのかも。
第15章 XPのスケーリング
プロジェクトが停止する前に、XP チームで「ロゼッタストーン」を書くことが多い。これは、将来の保守のための簡単なガイドであり、ビルドとテストのプロセスを実行する方法や、システムについて学習しやすい出発点を記述したものである。ビルドにはテストが含まれているため、保守担当者がシステムを学習するときに落とし穴にハマることがない。
💬 アプリの保守チームに渡す前に、これはやっておいてほしいやつですね。アプリの保守チームにアサインされて、先日までアサインされてたチームのプロダクトで、README 書こうよ〜って声かけてたけど、結局おざなりにしたままチームを後にすることになったので少しばかり心残りだったりする。
第16章 インタビュー
Q: どのように XP を導入されましたか？
A: 13 のプロダクトグループに Object Mentor 社の 1 週間のトレーニングを受けてもらいました。13 グループありますから、全部で 13 週間かかりました。XP を使い始めてからは、チームにコーチをつけました。
今やるとしたら、まずはひとつのチームで始めて、XP が本当に「自分のもの」になったことを確認してから、そのチームに次のチームを指導させると思います。
💬 まずはひとつのチームで始めてっていうのは XP 的な考え方でいいなと思う。自職場では、XP が本当に「自分のもの」になったことを確認する前に、次のチームを指導してないだろうか？ XP が自分のものになったことをどう確認するのか？ということも疑問になるが、XP を自分のものにできるように精進したい。
おわりに
XP の肝になりそうな部分は第Ⅰ部に詰め込まれていた気がするので、第Ⅱ部 XP の哲学 もあるけど、読書メモはここまでにしようと思います☆
ここまで読んでみて思ったのは、XP を行うのは「人」で、チームを構成するのも「人」で、必要な機能を考えるのも、ユーザのことを考えたデザインを作るのも、コーディングするのも、全部「人」。その一人ひとりが、XP の価値と原則を理解して、プラクティスを実践するからこそ、チームとして成り立つことができるのではないだろうか、と。人はそれぞれ個性があるから面白い。それゆえ新しい気付きがあり、思いもよらぬアイディアにつながったりする。だけどとあるメンバーのふるまい次第でチームはあっさり崩壊したりする。アサインされたチームでお互いにカバーしあいながら日々のチーム活動ができたらいいなと思います。XP 最高かよ🎉🎉🎉