【感想・ネタバレ】アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメントのレビュー

平鍋健児 / 野中郁次郎

日本生まれ、米国育ち 注目のソフトウェア開発手法「スクラム」
本書は、企業の経営層に向けて、ソフトウェアの開発手法アジャイルとその手法の1つである「スクラム」を体系的に解説するものである。また、スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを示し、この手法を取り入れ、ビジネスと一体となってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像について考える。日本におけるアジャイル開発の第一人者、平鍋健児氏と、世界的な経営学者でありスクラムの提唱者、野中郁次郎氏の両者が、日本企業のリーダーシップと競争力を高めるために必要な、知識創造プロセスの重要性を提言する。
※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

[ブクログ · ★★★★★]

アジャイル開発とスクラム　顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
著：平鍋　健児
著：野中　郁次郎

けっこう分かりやすかった
構成は３部、第１部アジャイルとは何か、第２部ケーススタディ　第３部アジャイル開発と知のモデル　である


■アジャイル開発とは

ウォータフォール開発に対して、アジャイル開発
アジャイル開発とは、短い期間を区切ってその中ですべての手順を踏んで動作する完成品の一部を開発する、それを繰り返すこと
アジャイル開発では、分析、設計、実装、テストを短い期間で並列で行うこれを繰り返す。動くソフトウエアを一定間隔を作り、それを成長しさせていく

アジャイル開発とは総称
　・スクラム
　・エクストリーム・プログラミング（ＸＰ）
　・ユーザ機能駆動開発（ＦＤＤ）
　・ＤＳＤＭ
　・適応型ソフトウエア開発（ＡＳＤ）
　・Ｃｒｙｓｔａｌ　Ｃｌｅａｒ（クリスタルクリア）
　・Ｅｖｏ（イボ）

■なぜアジャイル開発
　・ウォータフォールだと時間がかかるので、ビジネスのリリースに遅れたり、完成したとき時代遅れになっている
　・ウォータフォールだと、まったく使われない機能を実装してしまうケースが４５％、アジャイル開発であれば、常に必要な機能を実装し続けている

■スクラムとは

　＜プロセス＞　１～４週間の期間を区切って開発を行う、その期間のことをスプリントという（アジャイルでは反復イテレーションという）
　・プロダクトバックログ　開発すべき機能全体のリストをいう
　・スプリントバックログ　今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部

　＜役割＞
　・プロダクトオーナー
　・開発チーム
　・スクラムマスター　管理者ではなく、開発チームの支援者

　＜成果物＞
　・インクリメント：スプリントで完成した製品の機能のこと
　・プロダクトバックログ　開発すべき機能の全体のリストをいう
　・スプリントバックログ　今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部

　＜イベント＞
　・スプリント　開発するための反復イテレーションの期間をいう
　・スプリント計画　　スプリントの開始に先立って行われるミーティング
　・ディーリースクラム（朝会）　
　・スプリントレビュー　スプリント終了時に製品のデモを行うこと
　・レトロスペクティブ　スプリントレビュー後に行われるふりかえり

そもそも、ウォーターフォールであれ、アジャイルであれ、必要な共通スキルがある
　・ソフトウエアプログラミング、設計、テストに関する知識と経験
　・ユーザ体験（ＵＸ）の知識と経験
　・ＤＢやモデリングに関する知識と経験
　・開発環境やツールに関する経験と知識

加えて、スクラム開発をするためには、アジャイル開発特有の活動（プラクティス）が必要
　・ユーザストーリー　ユーザの言葉で書かれた説明書
　・プラニングポーカー　プロダクトバックログから、スプリントバックログをつくるための手法、見積もりも合わせて行う
　・朝会（ディーリースクラム）　昨日やったこと、今日やること、障害になっていること　を確認する
　・ふりかえり（レトロスペクティブ） ＫＰＴ（継続、問題、試用）次回改善したみたいことなどを洗い出す
　・タスクかんばん　未実施、作業中、完了がわかるようにタスクをカードに書き出したものを壁にはって見える化をする
　・バーンダウンチャート　進捗曲線、着地予測と残量確認ができるグラフ
　・ペアプログラミング　難易度の高いプログラミングを２人でやる開発手法
　・テスト駆動開発（ＴＤＤ）テストコードと製品コードを対に開発していく手法
　・リファクタリング　既存のプログラムを外部仕様を変えずに内部を改善する開発手法
　・継続的インテグレーション（ＣＩ）常に全体を動くようにビルドを最新に保つ管理方法

スクラムを支えるツール
　・ＩＤＥ統合開発環境
　・ソースコード管理ツール
　・バグ管理システム
　・クラウド（ＡＷＳ）等

■ケーススタディー

＜リクルート：リクナビ＞
　・開発期間の短縮化
　・開発のスピードアップ
　・パッケージをつかうか、テンプレートをつかうのか、アジャイルをつかうのか　⇒　アジャイル
　・ライバルメーカーがリリースする前にサービスをリリースするのが第一
　・全体進捗わからない　⇒　バーンダウンチャート
　・タイムボックス（１週間）に入る機能のみを開発に回す
　・８０％できればＯＫ，２０％はできなくてもだれも怒らない
　・アジャイルを使うのはＱＣＤのＤが重要

＜楽天：楽天市場＞
　・運用と開発を並行で対応
　・リリースしたら終わりではなく、運用の始まり
　・継続的インテグレーション：ＣＩ。自動ビルドで常に動く状態で運用できる
　・半分に開発をわけたら、前半の３．５倍後半に生産性がでた
　・シンプル設計、リファクタリング、継続改善の文化
　・見える化　⇒　タスクボード、パーキングロットチャートを採用
　・あるべき姿を求めて改善を続ける　⇒　昨日より今日をよりよくすること

■アジャイルと知のモデル

　・アジャイル開発は全員で開発に取り組む⇒全員で対応
　・マルチ学習、多層学習、複数レベルで学習を行う
　・柔らかなマネジメント　自己マネジメント＋相互マネジメント＋愛情によるマネジメント
　・リーンスタートアップ　ユーザについての知識を学びながら開発を進める

＜ＳＥＣＩモデル＞
　共同化　暗黙知⇒暗黙知　個人の知を組織で共有
　表出化　暗黙知⇒形式知　暗黙知を文書化して形式知化して伝達可能にする
　連結化　形式知⇒形式知　知識を体系化し、新しい知識を生み出す活動
　内面化　形式知⇒暗黙知　新たに生み出された形式知を個々人で実践して、暗黙知に変換する

＜アリストテレスの３つの知＞
　エピステーメ　形式知　科学、哲学、再現可能
　テクネー　暗黙知　技術、スキル、工芸、ノウハウ知
　プロテシス　実践知　実践からの知恵、賢慮、価値観、倫理観

＜ＰＤＣＡとの関係＞
　ＰＤＣＡはＰ：計画で始まる　計画は形式知で、計画ありき　⇒何を作るのではなく、なぜ作るを
　イノベーションはまず、共同化から始まる　⇒　共感、共振、共鳴

目次

はじめに

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

第一章 アジャイル開発とは何か？
第二章 なぜ、アジャイル開発なのか
第三章 スクラムとは何か？
第四章 アジャイル開発の活動（プラクティス）
　
第２部 アジャイル開発とスクラムを実践する


第五章 スピード時代に独自のアジャイル手法
第六章 小さく始めて浸透させる〜楽天のアジャイルによる組織改革
第七章 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦
　新たな分野への取り組みと「どうぶつ医療クラウド」システム開発

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

第八章 竹内・野中のスクラム論文再考
第九章 スクラムと知識創造
第十章 スクラムと実践知リーダー
　
特別対談 野中郁次郎×平鍋健児
　
　おわりに
　謝辞
　参考文献案内
　注
　索引

ISBN：9784798129709
。出版社：翔泳社
。判型：4-6
。ページ数：288ページ
。定価：2000円（本体）
。発行年月日：2013年01月
。発売日：2013年01月17日

[ブクログ · ★★★★★]

スクラムが元々経営学・企業研究から出発していることはあちこちで話題になるが、完全に一方通行で今はシステム開発領域に閉じたものと思い込んでいた。
この考えを、また元の分野に返す、往復と相乗効果についてまとめられていることで、双方の理解とやはりスクラムというフレームが日本発を誇れるものであることを再認識できた。

[ブクログ · ★★★★★]

P.111 筆者（平鍋）は2000年にXPとケント・ベックに出会い「ソフトウェアは人が人のために作っている。『技術』と『人と人との関係性』、その両方がソフトウェア開発の本質だ」とはじめて気づき、ソフトウェア開発現場を改革していくことを、それ以降の仕事の中心とした。

ワンチームマインド

「何としてでもやってもらわないと困る」という100%のコミットメントを求められると答える側の開発者も慎重にならざるを得ない。このため「この件に関しましては持ち帰って検討いたします」となって検討と後日回答の繰り返しが常態化しプロジェクトが進まない。そこで思い切って「可能性80%ならOKと答えてよい。そのかわり持ち帰りは厳禁」という方針を打ち出し、これにより進捗のスピードとプロジェクトの風通しが著しく改善した。

おわりに

「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門にステークホルダーがいるのです。そしてどの機能を優先すべきかについて意見が分かれているのです。意見を一つにまとめるにはどうしたらよいのでしょうか」

「野中先生はどう思われますか？」

「合宿をしなさい」

「形式的な会議で決めることはできない。いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこでなぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこからはじめて、一つの共通理解が生み出される。この過程をみんなで踏みなさい」

[ブクログ · ★★★★★]

日本におけるアジャイル開発の第一人者の平鍋さんと、スクラムの父と呼ばれる野中郁次郎先生によるアジャイル開発の解説本。 アジャイル・スクラムとは何ぞや、から始まり、貴重な比較的大規模開発の事例の紹介とキーパーソンへのインタビュー、そして対談形式でアジャイル・スクラムの成り立ちや背景となっている思想が語られている。 アジャイルに限らず、方法論が語られることが多いが、本書では考え方や思想が強調されているところが非常に興味深い。 特にスクラムに大きな影響を与えているSECIモデルによる暗黙知→形式知のループの考え方は自分の思考方法について考えされられた、と同時に実践しないといけないと感じた。 今回、著書の平鍋さんにサインをいただくことができたが、サインに添えられた一言「仕事を楽しく変えて行きましょう！」にアジャイルの全てが詰まっていると思う。 楽しくなければやっていけないよね！ アジャイルの考え方を学ぶにはとても良い本だと思う。エンジニアはもちろん経営者にもぜひ読んでいただきたい。

[ブクログ · ★★★★★]

これを読んだらアジャイル開発、スクラムができるか？というともちろんそんなことはないが、チームや企業文化に合ったプラクティスを導入し、改善し続ける必要性が理解できた。テストやペアプログラミング以外にも様々な課題解決方法を知りたい方には一冊目としてはおすすめできると思う。

[ブクログ · ★★★★★]

顧客満足や市場創出などビジネスの価値を創造することを目的としたアジャイル開発、開発環境である、継続的イテレーション、テスト駆動開発、リファクタリング、ペアプログラミング、チーム環境である朝会、タスクかんばん、プランニングポーカー、ふりかえり（KPT)などの方法論も技術論ではなく経営的な視点で書かれているので、とても全体像が掴み易い。

スクラムは元々野中郁次郎氏と竹内弘高氏がHarvard Business Review 誌に "The New New Product Development Game" として80年代の日本企業であるホンダやキャノンの新製品開発のなどを例として発表した論文をベースにしていて、本書でも再考と称して「アジャイルソフトウェア開発スクラム」との比較が行われている。

アジャイルでなぜ生産性があがるかとの議論では、最初に考えた機能を全部作成しないからというのが定説のようだが、どうやらそれだけではないようだ。不安定な状態から自ら組織化して、専門分野を越えた多層学習、多能力学習によって学びを組織で共有し、メンバーそして組織が成長して生産性が高まるのだ。逆に言えば成長の無いアジャイルは不完全であり、そもそもアジャイルはソフトウェア開発の方法論ではなく経営論と言ったほうが適切なのではないだろうか。

一年ほど積読にしていたのが悔やまれる名著です。

[ブクログ · ★★★★★]

アジャイルラジオにて西さんがベタ褒めしていたので購入。
「従来の開発手法では最初に計画をたてるため、途中で計画外のよりよいやり方が見つかっても採用できない。(p.55)」→実際すでにどうしようもない状況になってるときって多い。。。
「話し合ってKeepから先に出すのは、この回を前向きに運営する鍵になる。まず、よかったことを出してProblemとTryに向かう勇気を出す。(p.72)」→単純に表面的な効率だけ考えるとKeepを飛ばしてしまいがちだけど、Keepは絶対あった方が良いと思う。人をほめる機会って意外とすごく少ない。
「ペアプログラミングは、コストは二倍ではなく1.15倍、そのかわり、テスト通過率が15%増、コード行数は15%減した(p.86)」→やっぱり客観的なデータがあると説得力がある。行数で賃金が決まってる所は嬉しくないだろうけどw
「アジャイルを進めていくというのは、どこまでも人を育てる話だと思ってるんです。(p.167)」→激しく同意。メンバーがもともと持っている熱意をいかにして表面化しやすい環境にみんなでしていくか。
「いきなり「何を作る」のではなく、「なぜ作る」のかという情熱を、主観のままに伝えることが大事だと。(p.246)」→新入社員ならまずは言われたとおりにやるべきだけど、考えられるだけの経験を持っていても目的を理解しないまま作業に入ってしまうことが多い。指示する場合は目的も添えて、指示を受ける場合は目的を確認するように気をつけよう。
「スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似形の知識創造活動であり、それを実践する人々である(p.271)」

[ブクログ · ★★★★★]

良本。オススメ。
分かりやすく平易なだけでなく、文章の端々に鋭い言説が垣間見れる。
初心者もそれ以外の人も楽しめる一冊。

[ブクログ · ★★★★★]

「アジャイル」については一年以上前からその存在は知っていた。しかししっかりした意味を学ぶことはなかった。
今回、この本を読んだ事でその意味は判ったと想う。
その上で「アジャイルとプロジェクトマネジメントは水と油だ」と言う表現に疑問が生じた。アジャイルは「マネジメントしないプロジェクトマネジメント」なだけで水と油では無く、プロジェクトを完遂する手法の一つ、言わば水とジュースの様な間柄では無いか。ものによってはプロジェクトマネジメント手法がマッチするし、ものによってはアジャイルがマッチする。そんなイメージが在る。企業風土や職種、そのプロジェクトの目指すものによって使い分ける柔軟性が必要な気がする。
本書は「アジャイルとは何か」から始まり、定義、構成するもの、魂について触れる。まさに「アジャイルの扉」で開けようかどうしようか迷って居る人に、何も言わずそっと差し出すのに最適な本で在る。また「アジャイル」の存在を知らずとも、組織の活動に疑問、不満を持つ人々、コミュニケーションの在り方や会議の在り方に悩む人々の＂モヤモヤ感＂を振り払う可能性を秘めて居る。
そんな意味ではＩＴに限らない職種（例えば飲食業、建築業、小売店）などにも是非オススメしたい。大切なのは技術だけで無く思想（魂）なのだから。
もし適用して＂すんげえ良かったよ！＂と感じられたら、是非ともシェアして頂きたい。

そんな未来を感じさせる素晴らしい本である。

《投稿用更新》

[ブクログ · ★★★★☆]

これは良書。一度は読んでおくべき本でした。
IT用語である「スクラム」という言葉を、実は逆輸入版だったと知って驚きました。今よりもずっと前に、日本で、しかも製造業の研究においてすでに「スクラム」という言葉と概念が作られており、ずっと後にアメリカのIT業界で正にこれだと復権したというのは面白いですね。
この導入から始まり、IT業界での「スクラム」の説明が展開され、最後に本来の「スクラム」（野中郁次郎）との融合が図られる構成も読んでいて楽しめるものでした。
第二版だと、初版では勘違いされやすいテーマの修正や組織論にまで展開されています。ただ、やっぱり「アジャイル」を組織に適用するのは無理なんだな～、という印象。なので、個別のプロジェクトとしては「アジャイル」ができたとしても、最終的には組織とぶつかるところが出てくるのは避けられなさそう。

[ブクログ · ★★★★☆]

日本のボスが課題図書として同僚に挙げていた一冊が回覧されてきたので、読んでみた。
ソフト開発に携わっているわけではないので、直接取り入れるわけではないけれど、小さく回していけということですね。
野中先生はやっぱりお得意の暗黙知と形式知、そして実践知の話に持って行くのね。

[ブクログ · ★★★★☆]

従来の開発手法ではビジネスの変化に対応できなくなったため、アジャイルが広まった。ソフトウェア開発のみならず、組織経営やチーム運営にも多くの示唆が含まれている。

第1部ではアジャイルとスクラムの基本的な説明、第2部ではリクルート・楽天・富士通でのアジャイル事例紹介、第3部ではそれらを踏まえた考察、という3部構成になっている。

スクラムで決められている役割はこの3つ。プロダクトオーナー、開発チーム、スクラムマスター。スクラムマスターはプロジェクトファシリテーションに注力するサーバントリーダー。管理者たるマネジメントリーダーではない。コマンドコントロール型の組織から、自律化・自己組織化したチームへと変わる。

ーアジャイル宣言ー
プロセスやツールよりも個人との対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。

ー以下、メモー
自社の開発プロセスにアジャイルを取り入れることをイメージしながら読んでいた。べき論を言えば、自社の開発プロセスの課題に答える形での改善活動が望ましく、フレームワークを取り入れるだけでは現場が困窮するだけだろう。つらつら思いついたことを残しておく。

・アジャイル思想導入における障害とは？
・やっつけでアジャイル導入した場合と、課題展開を行った上での対策としてアジャイル導入する場合の違いとは？
・AI開発プロジェクトにおけるアジャイルとシステム開発プロジェクトの違いとは？
・メーカーでの導入事例とは？
・システム開発以外の領域でのアジャイルとは？

通常業務、プロジェクトに取り入れること。顧客体験を最大化するために顧客の言葉で書く。可視化共有化のために、紙ベースのアナログを活用する。
この一冊をとっかかりにアジャイルやリーンスタートアップを読み漁ろう。チームの開発、成長のスピードアップへの強い示唆がある。

[ブクログ · ★★★★☆]

著者の一人である野中郁次郎氏は、論文「The New New Product Development」の中で、「専門集団によって設計され、文書化されたナレッジが、次の工程の専門集団にに引き継がれ、これを繰り返して物を作っていく」プロセスに対して、当時、キャノン、ホンダなどが行っていた「色々な専門家が一体となり、自律的組織として物を作っていく」プロセスを、ラグビーに例えて、「スクラム」と呼んだ。このスクラムは、海を越え、アメリカでトップ・プログラマたちをインスパイアーした。そして、スクラムは、その名前のまま、ソフト開発プロセスの新ムーブメントとなり、故郷である日本に帰ってきた。
　ソフト開発は、現在のものづくりのみならず、会社経営にも非常に重要な要素であることは明らかであるが、日本のビジネスパーソンは、あまりにもソフトウエア・リテラシーが低い。私は、それが日本産業の生産性の低さの原因ではないかと思っている（残念ながら、これはわが社にも言える。特にソフト開発部門マネージメントのソフト開発リテラシーの低さは、悲惨を超えて喜劇的だ）。本書は、そういった状況を打破し、ソフト開発の改善、改革とそれを基盤にした経営改革にすばらしいアイデアを披露してくれるすばらしい本である。

[ブクログ · ★★★★☆]

四年ぶりに再読。アジャイルやスクラムはある程度理解している前提で、何度読んでも会話の重要性は再認識する。ビジネスとエンジニアの垣根を超えるコミュニケーションはやっぱどうあがいても大事。政治的事情でよしとされない場合でも、ダマで勝手にやっちまおう。
しかし読むたびにtypeAからCの考え方混乱するわ。Aが普通のスクラムだとおもってたが、やっぱちがうな。

[ブクログ · ★★★★☆]

アジャイルとは何か、そして自分自身の業務にどのように取り込んでいけば良いか、ということを考えさせられる一冊。スクラムの本質に迫る野中氏との対談も読み応えありました。

[ブクログ · ★★★★☆]

ひさしぶりにこういう専門書を読んだ。
面白かった。ソフトウェアもウォーターフォールではなく、こうしたアジャイル型の開発が進むのだろうか？

[ブクログ · ★★★★☆]

SECIモデルで知られる野中郁次郎氏の論文が、アジャイルのアイディアのもとになっていると聞いて拝読。

その点では本書後半において明らかになっており、アジャイルを単なる高速ソフトウェア開発のプラクティスではなく、情報共有、知識共有という、IT企業にとって必要不可欠な要素と結びつけて考えることができるようになった。前半は一般的なアジャイルの説明に終始するため、後半こそ、野中氏が関わっている本書の本質であると思う。

[ブクログ · ★★★★☆]

アジャイル開発、スクラムという概念を理解するつもりで読んだので、その目的は達成できた。（だから★４つ）
プラットフォーム上でのサービス開発には使えるなと思う反面、大規模プラットフォーム開発の主戦場ではつかえないかも。日本が負けているのは、サービス開発ではなく、プラットフォーム開発（戦略）だと思っているので、いまここに乗ることが本当にやることなのかという疑問はのこった。

[ブクログ · ★★★★☆]

スクラムの勉強で購入。
スクラムの基本的な考え方とか、わかりやすくて良かった。
あと楽天とリクルートでの実例もあって、これからスクラムを入れるにあたって、すごく参考になる内容。

[ブクログ · ★★★☆☆]

今となっては随分古い内容になった気がする。
XPのプラクティスなんて殆どが当たり前になってきた。
初めて読んだ当時は、こんなの現実的でないなんて思ってたのに…
技術的な内容というより、ポエムというか概念というか、理念か…？
まぁサクサク読めたけど、この先どんどん陳腐化していきそうな…

[ブクログ · ★★★☆☆]

アジャイルの概念、その背景にある企業哲学について良く考察されていた。
SECIモデルとアジャイルの関連性は興味深かった。

[ブクログ · ★★★☆☆]

本書は、共著者に野中郁次郎が入っていることからもわかるように、システム開発に従事している人でなくても、経営視点でアジャイルとスクラムについて解説している。やや抽象的なところが多いが、この分野で初めて読むにはお薦め。しかし、米国で始まったスクラムが実は竹内・野中が日本の製造業でのイノベーションの手法として名付けた「スクラム」から来ているとは驚きであった。また、実際にスクラムを採用した、リクルート、楽天、富士通の方のインタビューも興味深かった。

・アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。
・アジャイル開発では、すばやくユーザーや顧客のフィードバックを得ることで、ムダな機能を作ることを防ぎ、市場投入のスピードを上げ、ビジネスの投資対効果を高める。
・ウォーターフォールの問題点
　?人の創造性を奪ってしまう
　?文書によるコミュニケーションには限界がある
　?悪いタイミング
　?未来を読む水晶玉はない
　?仕事が楽しくない
　?部分最適化
・アジャイル開発の現場がいかにアナログのコミュニケーションを重視しながら、チーム内の暗黙知を共有し、テストとコードという動くものによって品質を作っていくかがわかる。
・従来の発注・受注関係のままだと、開発チーム側は事業担当者から「何としてでもやってもらわないと困る」と言われても断ることができない。その結果、開発側は次回から検討や文書作成に慎重に時間をかけ、さらに安全のためのバッファを追加した見積もをすることになる。これが繰り返されると、そのバッファ分だけ納期は伸び、かつ開発効率も落ちていく。
・技術的負債とは、メンテナンスが難しいコードの増加が開発の足かせになることを借金（負債）になぞらえて表現したものだ。

・楽天開発部の方の言
「僕自身、そうしたボトルネックになるのは何としてもいやなので、そうならないためにもプログラムだって書ける、アジャイルなマネージャーを目指しているつもりです。まず自分が成長しないことには、チームが成長することはできないと思う。」
「テストが終わりじゃなくて、そこから次のステップに進んでいけるんです。だからこそ、リリースのときには、作った開発者自身に現場に入ってもらいました。」

・実践知リーダーシップに必要な六つの能力
　?「善い」目的を作る能力
　?「場」をタイムリーに作る能力
　?ありのままの現実を直観する能力
　?直観の本質を概念に変換する能力
　?概念を実現する能力
　?実践知を組織化する能力

・一つには、リーダーシップの形が変わる必要があるでしょう。対話と場作りを重視したプロジェクト運営、その場その場で共感を作り、高い視点の価値観で判断する実践知リーダーシップです。

[ブクログ · ★★★☆☆]

アジャイル開発のサイクルがわかる１冊。おかげで過去に読んだ「SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法」（2017年. ジェイク・ナップ (著)）に書いてあった意味がようやくわかるようになった。

[ブクログ · ★★★☆☆]

どういった要求に対してアジャイルの考え方が生まれたか、具体的な手法の例が読みやすく書いてある。
知ることと実際に適用するのは別だが、アジャイルの考え方を手っ取り早く把握するのにはまずまず。

[ブクログ · ★★★☆☆]

なんかこう、しっくりこない。
ソリューション開発には確かに向いてなくはない。
受託開発のなかで適用するのはなかなか難しそう。
筆者もそれは認めていて、そのようなスキームの中での適用の工夫を述べている個所もある。

できたら、「受託開発における」スクラム開発について、本を出してもらえないかな。

[ブクログ · ★★★☆☆]

顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
見積もりポーカーやKPTなどアジャイル開発の方法論について記載されていてアジャイルを知らない人がざっと分かる本。（1章しか読んでいない）

[ブクログ · ★★★☆☆]

「持ち帰り禁止ルール」は自分の組織にも適用してみたがうまくいった。全員で定義がはっきりしたルールを定める重要性を体感。野中先生節はやっぱ好き。

[ブクログ · ★★★☆☆]

前半でアジャイルの概要を説明し、後半でこれを実施した企業の事例を紹介し、最後に著者二人の対談を載せた本。

前半の解説部分は可もなく不可もなく。後半の事例紹介では当事者のインタビューが掲載されており、どのような困難に直面しそれをどのように乗り越えたか、に関する生の声を目にでき、それなりに有意義。最後の対談部分は、学者らしい抽象論に終始しており、実践知である「アジャイル的」なるものとは正反対の趣で萎えた。

入門書として悪くはないと思うが、いかんせん「アジャイルサムライ―達人開発者への道」というぶっちぎりの良書が存在してしまっているので、相対的にあまり高い評価は与えられない。

入門を終えた後に読むちょっとした事例集として、読んでも良いかな、という程度。☆３つ。

[ブクログ · ★★★☆☆]

平鍋さんが知り合いなので読んだ。非常に基本的なアジャイル開発とスクラムに関するまとめとケーススタディ。あとは野中郁次郎さんとの対談。日本でいつの間にか失われたスクラムがソフトで蘇って逆輸入。サムソンの合宿がなぜ今日本でやれないんだろうね？まあ出張がその代替となっている気はするけど。

[ブクログ · ★★★☆☆]

改めて「アジャイルを知ろう」と思って読んでみました。全体のエッセンスをうまくまとめていて分かりやすい本だと思います。またその発展方法、方向なども示させていて、今の業務と照らし合わせると考えさせられるところの多い本です。とは言っても軽くまとめられていてサッと読めるので忙しいマネージャー向けという感じかな。