「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」
いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法
最初にまとめ
「いちばんやさしい」と書いてあるが、超入門というわけでもなく、自分が過去に読んだアジャイル開発の本の中で、一番網羅的に説明されているような印象を持った。 新しい本だけあって、過去に出版されたアジャイル開発の良い本のノウハウが反映されているし、日本人が日本企業を意識して書いた本なので、表現や考え方にも違和感なく自然に頭に入ってくる。
例によって気になったところの覚書
Chapter1 アジャイル開発の世界
05 ユーザーとソフトウェアの関わり
顧客インサイトを知る
- 重要なのは実際に顧客がとった行動とそれに基づく分析を行うこと。
- Systems of Insightを構築
Chapter2 なぜアジャイル開発なのか
09 従来型の開発手法「ウォーターフォール」
- 非機能要件も明確にしておく
コレ忘れがちだけど大事。開発手法に関わらず。
10 顧客が本当に欲しかったもの
- 某調査機関によると、開発したソフトウェアの3分の2の機能は使われていない
経験上、企画はいつもどんなときも、ブルーハーツの名曲「夢」を歌うものです。
あれも欲しい コレも欲しい もっと欲しい もっともっと欲しい
その結果がこれなんですな。 上で取り上げたSoIを構築することと、UX検証を行って落としていくことが重要なんですね。まあそれができる状態というのは、つまり開発済みなのですが。少なくてもバックログの順位というものを明確につけ、それを開発チームと合意することは重要と思いました。
関連記事： risingsun-system.biz
- プロダクトを触ることで自分が表明した「欲しいもの」と「本当に必要なもの」のギャップに気づく
その通りなんだけど、ある程度は事前に気づいて欲しいところでもあるな、なんて思いました。試すのも無料ではないので。
11 ソフトウェア開発は不確かなもの
- 現代のソフトウェア開発は急速なテクノロジーの進化や複雑化する社会情勢などからVUCAになった
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（曖昧性）
なので変化に耐えうる手法が求められる。 そうだとするとウォーターフォールのような手戻りできない方法よりも、もっといつも軌道修正しやすい方法のほうが、より良いプロダクトにたどり着く可能性が高まるはず。 つまり、（細かい手法はどうあれ）アジャイルであるべき、ということになります。
Chapter3 アジャイル開発がもたらす変化
17 個人と対話
- 相手の価値観を尊重し、ともに考えていく
19 顧客との強調
- 顧客と開発側が課題を共有できていると、より本質的なアプローチが可能
- 顧客からのネガティブなフィードバックがあるからこそ課題に気づくことができる
３つ合わせて、開発チーム以外の人たちと、この「チーム感覚」を持てたらほぼ成功な気がする。
22 自己組織化チームとリーダーシップ
- サーバント・リーダーシップ：メンバーたちがビジョンへ向かうことを支援し、成長を促す。メンバーの声に耳を傾け、課題解決をサポートするリーダー
プレーイングリーダーがこれをやりはじめると、潰れてしまうので、リーダー的立場の人だけでなく、メンバー全員が持っているべき考え方なんじゃないかと思う。
23 アジャイルチームの成長戦略
- チームに求められるスキルをそれぞれのメンバーが身につけていくことでチーム全体として成長していきます。
そうなんだけど、習得する時間がネックなんですよね。
24 筋肉質なソフトウェア
- YAGNI（YouAin'tGonnaNeedIt）とは、「機能は実際に必要となるまでは追加しないのがよい」
すごく当たり前なんだけど、これは結構厳格に守ったほうが良いことで、ちょっと先回りのつもりで実装したりして、結局不要なものになったみたいな苦い経験を思い出されます。
Chapter4 アジャイル開発の中核にあるコンセプト
34 反復的な作成物レビュー
- アジャイル開発の成果物は「プロダクト」と「チーム」なのです。インクリメンタルかつイテレーティブな開発を通じて、成長するのはチームでもある。
「チームの成長が成果物である」という考え方はすごくポジティブな気持ちになれる良い考え方だと思ったのでハイライト
- 改善施策の候補は、重要度ｘ緊急度マトリックスを用いて整理する
確かに。最近リモートでレトロスペクティブをやると、こういうマトリックス的な視点を忘れてしまって、緊急な問題しか書かないみたいになりがちだなとおもった。 緊急度の低い重要な問題にも目をつけないとですね。
Chapter5 小さく始めるアジャイル開発
36 タスクの見える化
- 気づいたタスクについて見える化する
ついついslackに残すだけにしてしまう場合がありますね。
40 ペアで作る
- ペアプログラミングの対象はプログラミング以外にも当てはまり、「ペアワーク」と呼びます。
- 緊急トラブルやツールの設定など1人で対峙することがつらい作業は、一緒に取り組むことで心理的障壁も下げられるでしょう。また、新しくチームに参加したメンバーの育成やベテランが持つ暗黙知の伝授など、教育に役立てることもできます。
これまでもなんとなくやっている事だけど、ちゃんと意識的に使うのはありかも。
41 やったことの見える化
- Keep、Problemを共有し取り組むTryを決定したあと、最後にチームメンバーへの感謝を示すアクティビティです。感謝を伝えるというのは、「あなたの行動がチームにとってプラスになっている。その行動を継続してほしい」というフィードバックを行うことにほかなりません。
これは良さそうだなと思いました。チームへの貢献を目に見える形にするというのは良いことで、心理学的に言っても感謝を相手に伝えるのは、相手だけでなく自分の自己肯定感を高め、ポジティブな雰囲気にすることができる。
Chapter6 上手に乗りこなすためのカイゼン手法
46 チームの活動が形骸化し始めたら？
- 「問題ありません」という発言が頻発したら要注意です。この発言の裏には、問題の解決を諦めていたり、そもそも問題に気づいていなかったりするケースが隠れていると考える。
すごくわかります。
- 5本の指（ファイブフィンガー）を使って進捗状況を発言できる環境作りも対策の1つになります。
こうやって進捗状況や健康状態とかも含めて、数値化していくのは良いですね。5段階にするとみんな3にするので、「順調 or 要注意 or やばい」の3段階くらいで良さそうに思いました。
- 問題が小さいうちに課題解決や意思決定し、進捗を妨げるものを除去していけばチームのパフォーマンスは上がっていきます。
朝会とかで早期に見つけていくのが良いですと。
- その他マンネリ化したときの対策案
- YWT
- Y->W->Tの流れで、気づいた学びを次に活かすという視点
- Fun! Done! Lean!
- 楽しかったか、学びがあったかという視点
- YWT
48 成果の停滞感に直面したら
おもしろそう。プログラマー＋デザイナー＋プロダクトオーナーでフロントエンドの実装を最適化するのとか。「モブワーク」かな
Chapter7
アジャイル開発を懐疑的に思っている人が聞いてくる質問と答え集
Chapter8 アジャイル開発はあなたから始まる
61 素直な声に耳を傾けよう
- 巨人の肩に乗りながら、時には飛び降りる
- アジャイル開発は「目的から考える」ことが重要。その一方で、感覚的な違和感についても逃さないようにする
この柔軟さがアジャイル開発の強いところかなと。ある程度幅をもたせることで、反対してくる人の対策もしやすい。
62 アジャイル開発の学びを深める、広げる
- ハンガーフライト＝チームや部署を横断する学び合いの場
- アジャイル開発は失敗の歴史によって向上するものであり、自チームだけでは得られない知見をほかのチームから学び得る機会を作ることが大切
