【書評】アジャイル開発とスクラム

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

きっかけ

アジャイルサムライを呼んだが、後続の本で知識を深めたいと思っていたので、読了。
本当は、実際にやってみてフィードバックを得ながら開発するのがいいのだろうけど、プロジェクトの主流はウォーターフォールが一般的で難しい。
あと、私生活に適用しようと思っても、いきなり適用が難しいのがある。
本質をより良く理解したかった。

近くに、メンターになれる人がいれば良かったけど、内向的性格が災いして、なかなかできない。
なんか、アジャイルをテーマにしたカンファレンスがあれば、行きたいと思う。

内容・感想

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

アジャイル開発とは何か、スクラムとは何か

ウォーターフォール

開発工程に従って順次開発する方式。
工程間をドキュメント使って意思疎通する。
下記問題点がある。

• 動くものが最後まで見えない
• 文章での意思疎通による誤解発生のしやすさ
• 完成時に古くなる可能性

アジャイル

開発工程を短い期間で繰り返す。
ユーザの意見を取り入れて開発を行う。

アジャイル開発

手順・プロセスによる開発ではない。
価値観や考え方を元にした開発。
そのため、やり方には複数ある。
決まったやり方を指すのではなく、考え方を指す。

(おそらく多くの人は、決まったやり方を求めている気がする。)
(そのために、誤解が生まれている気がしてならない。)

なぜ、アジャイル開発なのか

従来のシステム開発

1. 市場調査
2. ビジネスモデル確立
3. システム発注
4. ソフトウェア開発
5. 納品
6. リリース

ビジネスのゴールと、ソフトウェア開発のゴールが分断されている。
ビジネスのゴール：システムで利益を得る(リリース以降)
ソフトウェアのゴール：仕様通りに作る(納品まで。リリースも含む場合がある。)

ゴールが違うから別々の利益を求める。
↓
最初の内に多くの機能を求める。
↓
リリースする頃には、いらない機能になってお金がかさむ。

章まとめ

アジャイルが出現した背景
ビジネス変化の高速化

アジャイルの目的
ゴールを共有して、無駄を省く事。
柔軟な対応と費用対効果の向上に主眼を置く。

スクラムとは何か

アジャイルの一種。
経験を元にしたスプリント*1を実行する。
スプリントで得た経験を、次のスプリントに活かす。

スクラムの３つの役割

• プロダクトオーナー
  何を作るか決める人
• 開発チーム
  開発する人々
• スクラムマスター
  マネジメントする人。働きやすい環境構築を行う人。

スクラムの成果物

• インクリメント
  スプリントの成果物。リリースする媒体。
• プロダクトバックログ
  機能リスト
• スプリントバックログ
  今回のスプリントで実装する機能リスト

スクラム５つのイベント

• スプリント
• スプリント計画
• デイリースクラム
• スプリントレビュー
• レトロスペクティブ

スプリント

繰り返す反復の作業。

スプリント計画

スプリント開始時のミーティング(キックオフ)
プロダクトバックログからスプリントバックログを抜き出す。
対応内容を決めて、タスクに落としこむ。

(アジャイルは計画が内容に思われがちだが、実際は、やることを決めて計画は立てる。
アジャイルサムライでも知っていたので、それほど驚きはしないが、知らない人は驚愕するらしい。
※個人の推測

ここでWBSに落とすのだろうか？)

デイリースクラム

朝会・夕会の実施。
活動状況を共有する。
開発チームで対応できないこと→スクラムマスターに依頼する。
共有して見えた状況→プロダクトオーナーに報告

(ウォーターフォールでもやると思う。
ただ、役割を決めてないと宙ぶらりんになるが。
やることは、スクラムの肝な気がする)

スプリントレビュー

スプリントが終わった後のデモ

レトロスペクティブ

スプリントレビューでの振り返り

アジャイル開発の活動

アジャイルの実践には、プラクティスと呼ばれるいくつかの活動が必要になる。

ユーザストーリー

ユーザの言葉で書かれた機能説明　→　これが要求仕様書になる。
アナログ重視して、カードに書かれたことをきっかけとして話す。
会話ベース。
仕様書に落としこむと、ドキュメント肥大化と分析麻痺が起こるから。

(方式が異様に多いのは、何度か経験がある。
ドキュメントが多いと圧倒されるし、仕事をした気になるから注意が必要だと思う。
ドキュメントが多い＝優れたシステムではないハズ！)

プランニング・ポーカー

チーム全体で開発規模を見積もる。
各々の見積もりを比較して決める。
※人は、見積もるより比較が楽なため。

ポーカーのように日数合わせをして進めるので、この名称だと思われる。

朝会（デイリースクラム）

やることを見える化して、チームで共有する。
長くなる議論は、一旦区切る必要がある。

振り返り

チーム活動を通して、今後の改善を話し合う。
PDCAのCAに相当。
気づきを共有して次に活かすのが目的。

(よく考えるとPDCAのCAって、一緒にやることが多い気がする。)

タスクかんばん

現在していることを全てカード化して可視化する。
誰でも見ればプロジェクト状況が分かるようになる。
そうすることでボトルネックを見つけやすくして、スループットをあげる手法。
あと、分散開発がしやすくなる。

(たぶん、これはトヨタの流れだよね。。。)

バーンダウンチャート

スプリントの残作業を認識して、現在の進捗を知るのが目的。
進捗に対してどのような行動をとる／取らせるかが重要。
一番の目的は、行動喚起すること。

ペアプログラミング

ペアでプログラミングさせる。
そうすることで、リアルタイムレビューと知識の共有が行われる。
会話しながら開発するので、集中力が必要になる。

テスト駆動開発

テストの定義→失敗→再設計を繰り返して設計を成長させる。

リファクタリング

外部からのうときを変えずに、内部構造を変える再設計活動。

継続的インテグレーション

動くソフトウェアを常時展開させる

アジャイルを支えるもの

アナログと会話

動くものによって品質を作って密度の濃い場を作る。
開発速度と効率が上がる。

(今までは品質を高めながら作るのが主流だったけど、これからは作りながら品質を高めていくことが主流になる。
そうしないと、速度でないことは、明白なハズ！)

オブジェクト指向

変更・テストの容易性をあげる技術として必須。

(今は、関数型が目立つが、オブジェクト指向と反目はしないと思っている。適用する場所が違うだけ。
アジャイルを突き詰めていくと、マイクロサービスになる気がする。)

スピード時代に独自のアジャイル手法。ワンチームマインドで挑むリクルート

新しい開発標準「SWAT」

メディアの変化

紙　→　Web
旧来の勝ちパターンが遅すぎる。
やってみないとわからないが多数を占めるので、実際にやってみることを優先しなければいけない。
競合他社がいるなかで遅いことは、負けに繋がる。
(ブルーオーシャン戦略の基本ですな)

SWAT

Speedy Willing Alliance Teamの略。
一致団結して、意志をもって開発スピードを追求する。
(言われたことを早くやるではないのが、ポイント)

スクラムと実践知リーダー

スクラムオーナーとプロダクトオーナーに求められるものは、実践知のリーダーシップ。

アリストテレスのフロネシスと実践知

知　→　３つの形態がある。(ドラゴンボールのセルかな？？)

• エピスメーテー
  科学・哲学が該当。
  普遍的で、文脈に依存せず、再現可能で言語表現できるもの
• テクネー
  技術・スキル。文脈依存で実践のノウハウ
• フロネシス
  実践からの知恵。目に見える事象と背後にある関係から適切な判断をして実行する。

(フロネシスを理解してない奴が多いこと。
だから、「Why ~」って言うのに騙される。
やり方を学んでも、それができる場面と背景を理解してないとダメってことだな。
魚の目利きのやり方を覚えても、いい魚が絶対手に入るわけではない。
売っている人との利害関係や関係の構築を考えることも必要なのだ。
それを体系的に伝えることが困難なので、修行という考え方があるのだと、儂は思う。)

実践知に必要なリーダーシップ

• 良い目的を作る　→　良い判断のため
• 場をタイムリーにする　→　知の流通を良くする
• 現実の直視　→　現実を見て、本質を見抜く
• 直感の本質を概念化　→　本質を見つけたら、それを伝える能力
• 概念の実行　→　見つけた法則を実行に移す行動力。政治力も伴う。
• 知の組織化　→　知の伝授・継承・分散

(リーダーシップを発揮するとは、未知の事象を解析して分析、実践して検証を含めること？
何もしない奴は、確かにリーダーシップがあるとは言えんな。
あと、考えを持たない奴も、リーダーとしてどうだろうかと思う。)

感想

アジャイルサムライを読んでいたからか、違和感なく読めた。
リーダーシップの考え方は、概ね同意。
行動を起こして、率先するのがリーダーシップだと思うね。

やっぱり一番難しいのが、問題の共有と解決だろうか。
人の考えは、統一することができないから、アジャイルが失敗しやすい由縁だと感じる。
それをどうやって解消するかが、アジャイル開発の課題な気がする。

アジャイルの基礎はアジャイルサムライで固められた。
汎用概念や、他の取り組み方、実践方法について迷ったら、読むといいかもしれない。
たぶん、アジャイルサムライを読み直すと、見えなかった本質の説明が分かりそうな気がする。
多読がいいとされるのは、理解のきっかけが、いろんなところにあるからかもしれないと思いました（小並感）

アジャイルサムライ−達人開発者への道−

*1:反復プロセス