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

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

はじめに

• ビジネスにスピード感が求められる環境、ビジネスが不確実で先読みすることが難しい環境では、ビジネスを作る側と技術を担当する側で協力してソリューションを考える必要あり。
• そして、すばやくリリースしてユーザーを獲得すること、ユーザーの反応を見ながらソフトウェアを追加・改変していくことが求められる。

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

第1章 アジャイル開発とは何か？

• ビジネスのスピードに追随するという目的だけではなく、自律的なチームや組織を作るという手法としてもスクラムが注目。自分たちで決めながら動く自律したチームを作ることが、生産性を上げる鍵となっている。
• 期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減するとともに、ユーザーや顧客のフィードバックを取り入れながら開発する。
• 協調とコミュニケーションスタイル、顧客と開発チームのゴールの共有関係、柔軟な計画変更の考え方、現場の開発者のモチベーションなどの価値観を重要視。

第2章 なぜ、アジャイル開発なのか？

• ITのゴールは仕様を満たすことではなく、ビジネスとしての効果を上げること。
• すばやくユーザーや顧客のフィードバックを得ることで、ムダな機能を作ることを防ぎ、市場投入スピードを上げ、ビジネスの投資対効果を高める。

第3章 スクラムとは何か？

• 予見的なプロセスではなく経験的なプロセスであり、実際にやってみた結果を見ながらチームを適応させていく。
• 効果的に実践するためには、スクラムチームを含む組織全体が「コマンド-コントロール」型から「リーダーシップ-コラボレーション」型の自立した組織に変わる必要がある。

第4章 アジャイル開発の活動

• プランニングポーカー
  • 複数人の意見で見積もることで、見積もりの精度が向上する。
  • 開発者が自身の意見を話すことで、いろんな考え方を知ることができるという学習効果もある。
• 朝会
  • チームは自分の仕事に透明性を持って参加することが重要。
  • 独りぼっちでそれぞれに与えられた仕事をこなしているのではなく、共通のゴールに向かって何かを一緒に生み出していくプロジェクトの一体感を毎日作る。
  • 現在のプロジェクトの状況（バーンダウンチャートなど）を壁などを使って見える化し、チームで共有すると、朝会の効果が上がる。
• 振り返り
  • チームが抱えている問題点を共有し、自分たちでできる解決策を見つけ出し、それを行動に移す機会にすること。これにより多くの場合効率もよく、モチベーションも引き出せる。
  • すべてチームが自律的に運営することがとても重要で、外部から押し付けられた解決策はうまく行かない。
  • 振り返りがうまく回りだすと、チームはどんどん自分たち流のやり方を獲得することができ、チームが自律的になっていく。
• タスクかんばん
  • 可視化によるちーうの協調支援と透明性の確保が主目的。
  • タスクかんばんを見れば、全員が以下の観点でスプリントの状況を確認でき、スプリントのゴールに向かって全員が自律的に行動できる。
    • ずっと動いていないタスクはないだろうか？
    • 何か障害があるのではないか？
    • 今回のスプリントは予定通りにいくだろうか？
    • 誰か手の空いた人が助けるべき人はいないだろうか？
• バーンダウンチャート
  • バーンダウンチャートを全員で更新し、確認する運用にすると、現状をメンバー全員が共感を持て、そこから行動につなげられる。

第2部 アジャイル開発とスクラムを実践する

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

第6章 小さく始めて浸透させる ～楽天による組織改革

• トヨタ生産方式に「あるべき姿を求めて改善し続ける人間集団をつくる」という考えがあるように、仲間を信じること、仲間に任せること、仲間を応援すること、といった人間中心の環境を作ることが重要。
• チームみんなで、より高みを目指し、お互いを奮い立たせ、励まし合い、「努力していこう」と継続的に勇気づけること。これこそが、アジャイル開発のすべて。

第7章 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦

• 「短い時間で提供しなければならない」という制約が、本当に必要なものだけを提供→フィードバック→必要なものだけ提供、というループを回した。「小さく速いループ」が「思い込みを排除し、短期間で最大の効果を得る」のに役立つことを学んだ。

第3部 アジャイル開発とスクラムを考える

第8章 竹内・野中のスクラム論文再考

• 新製品開発という速さと柔軟さが求められる場面では、様々な専門性を持った人が一つのチームを組み、ラグビーのように開発の最初から最後まで一緒に働くことが求められ、人とチームを重視し、彼らに自律的に動ける環境を与えることでブレイクスルーが起こりやすくなると同時に、製品化までの時間が短くなる。
• 自分の人生にもっとエネルギーと創造性を感じて、チームですごいソフトウェアを作り出す仕事を、わくわくしながらやれる環境作りが生産性や品質向上につながる。

1.不安定な状態を保つ

• 最初に綿密な計画書や指示があるわけではなく、チームは自由な裁量と同時に、困難なゴールを目指す。
• プロジェクトの開始時にすべての要求を固定することができないため、要求を固定するよりも、人を中心にしたコミュニケーションと協働でプロジェクトを前に進める。
• 要求のリストは、順位付けられた「バックログ」として管理されるが、このリストは時間とともに変化していき、常に不安定な状態といえる。

2.プロジェクトチームは自ら組織化する

• チームは不安定な環境から自己組織化し、対話の中で自律状態を作り出す。
• 自己組織化されたチームの状態は、「チームが自律しており」、「常に自分たちの限界を超えようとし」「異種知識の交流が起こる」という特性がある。

3.開発フェーズを重複させる

• 開発フェーズを重複させることで、メンバーは専門分野を越えてプロジェクト全体に責任感を持つようになる。
• 分析、設計、実装、テストという開発フェーズが重なり、メンバーは分析者、設計者、実装者、テスターという専門の垣根を取り払って一つのチームとなる。
• 仕様書ではなく、対面のコミュニケーションを基本に情報を伝達し合いながら問題解決する。文書ではなく、「人」が情報を運んでいる。

4.マルチ学習

• メンバーはグループ全体として学習し、さらに専門を越えて学習する。
• 「多層学習（個人、グループ、組織、企業といった複数のレベルで学習が起こること）」と「多能力学習（別々のスキルを持った人が集まることで、専門外の知識についての学習が起こること）」をマルチ学習と呼ぶ。
• 多層学習では、プロジェクト内の学びは、個人とグループという二層で起こる。特に全員が同じ体験を通して学んでいることが重要で、個々の学びの総和ではなく、その体験の中で交わされた会話や議論を含めて、グループ全体があたかも一つの生命体のように獲得した学習が成果だといえる。

5.柔らかなマネジメント

• 無管理でも強い管理でもなく、自主性を尊重した「柔らかなマネジメント」が重要である。
• 「自己マネジメント」、「相互マネジメント」、「愛情によるマネジメント」の三つを総称して、「柔らかなマネジメント」と呼ぶ。
• 「オープンな仕事環境作り」、「開発が進行していく中で、リズムの違いをマネジメントする」、「失敗を自然なこととして受け入れる」などがポイント。

6.学びを組織で共有する

• 過去の成功を組織に伝える。もしくは意識的に捨て去る。

第9章 スクラムと知識創造

• スクラムはスプリントによって獲得・創造した知識（要求に関する知識、ユーザに関する知識、作り方に関する知識）を「動くソフトウェア製品の成長」と「スクラムチームの成長」という、2つの形で蓄積していく活動。
• 目に見える事象と、その背後にある関係性までを読み、その場で適切な判断を下し実行することを実践知と呼び、実践知を持ったリーダーを実践知リーダと呼ぶ。
• 形式知（ビジョンや原則）だけでも暗黙知（現場の実行力）だけでもなく、両者を行き来できるリーダーがアジャイル開発で必要なリーダーシップ。
• 実践知リーダーリップに必要な6つの能力
  • 「善い」目的を作る能力
  • 「場」をタイムリーに作る能力
  • ありのままの現実を直観する能力
  • 直観の本質を概念に変換する能力
  • 概念を実現する能力
  • 実践知を組織化する能力

まとめ

• 僕個人の意見だと、スクラムをやる一番の価値は、自律的なチームや組織を作るだと思う。これさえできれば、本来の目的であるビジネスとしての効果を上げることの一番の近道だと思う。
• これの根拠として、組織の成功循環モデルで言われているグッドサイクルは、関係の質を高めるところから始め、関係の質を高めるとは、相互理解を深め、お互いを尊重し、一緒に考えることである。と言われているためである。
• 組織の成功循環モデルの詳細は、ネットで調べてください。
• ということで、やっぱりスクラムをやるなら、チームビルディングがすげー大事になってくるので、次はチームビルディングに関する本を読もう

以上。