平鍋健児のレビュー一覧

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

平鍋健児 / 野中郁次郎

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

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


■アジャイル開発とは

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

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

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

■スクラムとは

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

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

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

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

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

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

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

■ケーススタディー

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

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

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

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

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

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

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

目次

はじめに

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

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


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

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

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

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

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

平鍋健児 / 野中郁次郎 / 及部敬雄

たしかにスクラムの概要や導入のための具体的な手法を求めて読むには物足りない内容かも知れないが、スクラムのスケーリングのための手法 LeSS, SAFe, Nexus, Scrum@Scale の各手法の解説は、スクラムの全社的な展開の選択肢を広げる際の参考になる。関連して、終盤の自己相似的な組織の拡大の話も新鮮で刺激になった。

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

平鍋健児 / 野中郁次郎 / 及部敬雄

スクラムをフレームワークとしてだけではなくて、人々の活動と捉えているところに著者たちの熱い気持ちを感じました。

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎 / 及部敬雄

　文句なしの★5つの本です。　というのも野中先生の『知識創造企業』は本当に僕の中でのビジネス人生において一番大事にしている本だというところもあります。　

知識創造企業への想いについては、当時の読書レビュに詳細は委ねますが、その中の「ラグビーアプローチ」にものすごく感動しました。　そして、この本は、20年以上前にはじめて社会人としてビジネスパーソンになる際に、内定者への課題図書として会社から提供された本でした。　当時まだ学生だった私としては、会社っていうところはすごい本を読ませるところなんだな、と、青二才ながら大変感動していたことをよく覚えています。

　そういう、僕のビジネス人生の基礎を築いてくださった野中先生の本は、失敗の本質、しかり、戦略の本質、直観の経営ほか、そして、ワイズカンパニーも当然読んできたのですが、この第2版が出版されると知って、この本を読むために、個人的に　『アジャイル三部作』（This is Lean, みんなでアジャイル，そしてこちら）と課題設定して、ゴールデンウィークを活用して三本読んできたかいがあると思いました。　本当に三部作を順番で読んできて、ものすごく理解が深まりました。　僕はソフトウェア技術者ではなく、営業職責の人間なんだけれども、「ラグビーアプローチ」による知識創造は非常にインパクトを受けた理論であって、それが「スクラム」という名前に変わってソフトウェア開発における一大アプローチになったと聞いたことから、これは読まねば！と思っておりました。
　　
　ラグビーをやってきたものからすると、スクラムというとどっちかというとセットプレイであって、止まった状態、という印象があり、「スクラム」が動的に動き続ける、というところに若干の違和感はあったのですが、今回の書籍においては、1986年の論文から正しく引用してくださっていたり、知識創造企業から「ラグビーのようにチームで一丸となってボールを運んでいる」や、「ラグビーにおいて、チーム内でボールがパスされながらフィールド上を一群となって移動するかのように」の部分を正しく表現してくださっていて、ちょっとううれしい。（さらに書籍の中にはポッドシステムについても少し触れられているのが、また、うれしい）

　まぁ、あくまでメタファーなので、若干の変化はあるとは思いますが、最後のメッセージ文を読んで、僕も何らかの形でまたこちらの「スクラム」にも関わり続けていきたいなぁ、と思いました。

P289 「スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似形の知識創造活動であり、それを実践する人々である」



以下、改めまして抜粋引用となります。(ふせんはりはりしすぎで多めです)
＝＝＝＝＝＝＝
P66　
　スクラムが役割を3つに分けているのはそれぞれの仕事に線を引くためではない。「計画」と「実行」を分離してしまってはスクラムの意味がない。そんなやり方は本末転倒である。
　スクラムでは役割を超えて協力していくことが欠かせない。「あなたvs私」ではなく「問題vs私たち」の構図を引き出すことが重要である。「私たち」はもちろんスクラムチームだが、私たちが向き合う問題とは何なのかをチームが共通認識として揃えておく必要がある。

P72
　アジャイル開発では対話を重視している。ユーザーストーリーは、従来の仕様書による情報伝達の欠点を補う手法として生まれた。従来の問題とはすなわち、完璧な仕様書で伝達しようとするあまり、どこまでも詳しく書くことになり、大きなドキュメントを抱えて「分析麻痺」に陥る問題だ。しかも、書き終えた頃には、要求が変化してしまっている。

P94
　これらを見ると、アジャイル開発の現場がいかにアナログのコミュニケーションを重視しながら、チームの暗黙知を共有し、テストとコードという動くものによって品質を作っていくかがわかる。顧客から見て価値がないムダなドキュメントを排除し、密度の濃い「場」を使ったコミュニケーションこそが、アジャイル開発の圧倒的なスピードを支えている。それは、チームの力を最大限に活かすプラクティスによって成り立っている。

P143　
　メンバーはスクラムの方法論だけでなく、その本質にある「課題を見つけ、5cmの階段を上るように小さく改善する（検査と適応）」「困り事などは書き出し、空中戦にせず課題を解決する（透明性）」「誰かがやってくれる、を待たない（オーナーシップ）」といったマインドを学び取っていた。

P153
―最後になりますが、薄井さんは、すべてのプロジェクトがアジャイルになる、もしくは、なるべきだ、と考えますか？
　個人的にはなるべきだ、と考えます。　人間が成長し続ける生き物である以上、その活動を支えるITシステム開発や、それ以外の営みも、同等以上のスピードで成長する必要があると思います。それを実現するためにも、アジャイルは不可欠と思います。

P209
　それは技術的な議論だけではなく、人と人との協調、共感といった感情面も含めた、チーム作りや組織作りにまで及んでいた。そして、彼らは正解を学んでいるのではなく、新しいコンセプトを使って、自分たちのやり方を形作ろうとしているように見えた。まさに、私たちが「スクラム」という言葉で呼んだ共感と共振がそこにはあったのだ。

P211
　新製品開発という速さと柔軟さが求められる場面では、成果物を紙に書き、それを壁越しの別のチームに渡すようなリレーをしていてはだめである。様々な専門性をもった人が1つのチームを組み、ラグビーのように開発の最初から最後まで一緒に働くことが求められる。人とチームを重視し、彼らに自律的に動ける環境を与えることでブレークスルーが起こりやすくなると同時に製品化までの時間が短くなるというのがこの論文の趣旨だ。

P236
　現在、65%の人が自分の仕事を幸せだと考えていないという調査結果がある。彼らは、自分たちの仕事がうまくマネジメントされていない、自分の仕事をコントロールできない、創造性を排除されている、と考えている。そしてそのことが生産性を落とし品質も悪くしてしまう根本の原因だと思うんだ。もしみんなが自分の人生に責任を持ち、自分の進む方向を自分で決められたとしたら、自分の人生にもっとエネルギーと創造性を感じて、チームですごいソフトウェアを作り出す仕事を、わくわくしながらやれるんじゃないかと思っている。その結果、製品のコストが10分の1になれば、この地球上にはもっと必要なものが手に入るようになるだろう。スクラムによって、こういった職場の変化、そして製品やサービスの変化が、もっと現実的な未来に近づくと思っているんだ。

P261　
野中　P、つまり「プラン:plan」というものは言葉で書かれた形式知であって、PDCAは最初に計画ありきなんですね。　これでは本当にほしいもの、顧客に届くもの、そして感動すなわちイノベーションは作れないんです。最初に論理思考、分析思考に陥ってしまってはだめ。作るものには「意味」があって、意味は計画や論理からは出てこない。意味の正体は、最初はもっと主観的かつ曖昧で、言葉にできないことが多いのです。
平鍋　いきなり「何を作る」のではなく、「なぜ作る」のかという情熱を、主観のままに伝えることが大事だと。
野中　我々が何かを作ろうとするときには、まずプランがあるのではなく、その前に直接経験や直観、主体的・身体的な経験というものから得た動機があるはずです。それこそが「意味」であり、コミットメントの源泉になる。知も感情も含めた全人的な身体知＝思いが、まず一番初めにあるのです。

P273
野中　論文「The New New Product Development Game」の図1、TypeCを見てください。ここはフェーズが重なった絵がありますが、よく見ると、最初のフェーズを示す円は最後に向かって伸びています。これを言い換えると、「最初に企画をした人は、最後までチームに残って、身体で意図を伝えよ」ということなんです。
平鍋　これがプロダクトオーナーの仕事なんですね。ユーザーと開発チームを身体でつなぐ。そして、それができるのは、実践知リーダーだと。
＝＝＝＝＝＝＝

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

平鍋健児 / 野中郁次郎 / 及部敬雄

アジャイル開発やスクラムをソフトウェアの開発手法だけにとどまらず、組織構造や文化といった観点で記載している

一部はアジャイルとはスクラムとはと言った基本的な話から始まり、二部では実際の事例と、三部は組織論。

SECIモデルの理解とアジャイルとの親和性について深く理解できる。

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

平鍋健児 / 野中郁次郎

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)」

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎

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

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

《投稿用更新》

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

平鍋健児 / 野中郁次郎 / 及部敬雄

･開いてびっくり縦書き、ということもあってか、技術書というよりビジネス書寄りの内容
･第1部は、未経験の私でもわかりやすく、スクラム(アジャイル)について概観することができた(特に現場の様子がイメージできるのが良かった)
･ジェフ・サザーランドのインタビューが良かった(『スクラム』を読んでみたくなった)

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

平鍋健児 / 野中郁次郎 / 及部敬雄

3部構成で、1部はスクラム開発とは？アジャイルとは？についての解説から始まるため、まずはここから読み進めていくのが良いだろう。実際の取り組み事例を読みたい場合は2部へ。現場での実践では、思わぬことが起きがちで、それらの課題にどのように対処したのかを知ることができ、非常に興味深かった。

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎 / 及部敬雄

スクラムというタイトルが付いているけど、この本を読んだからスクラムが出来るという訳ではない。
スクラムが対象としている根っこの課題は何なのかを語ろうとしている本。
なので、1部にスクラムの表面的な話が載っているが、知らない人向けだろうし、知っている人からすると退屈。
後半の対談とかは面白いが、これも示唆くらいな話なので、そこから自分で考える事が必要だろう。

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

平鍋健児 / 野中郁次郎 / 及部敬雄

ウォーターフォール型の開発は敵対関係を生み出しやすく、面白くない→個人的に刺さった

【感想】
　スクラムを中心に、アジャイル開発の技法、企業への導入エピソードが紹介されている。アジャイル開発は大きく技術的手法、組織的手法に分けられる。本書は、組織的手法である「スクラム」の記述に焦点をあてていて、技術的手法の詳細には立ち入っていない。リファクタリングやTDD、CI等については紹介程度の記述がある。実際の開発で生かすには、別の本を読む必要があるだろう。
　とかく、情報が分散していて、章ごとのつながりを捉えるのが難しく、咀嚼が難しいと感じた。おそらく、この本の目的は「アジャイル開発手法とスクラムについて色々な観点で紹介する」ことなのだろう。フレームワーク・プラクティスがかなり多く登場するし、ケーススタディの登場企業も多い（覚えて使いこなすことが難しい）。
　企業４社ごとのアジャイル導入経験も記述されているのが、各企業群をまとめて抽象化していないので、頭に叩き込むのが難しい。研究書ではないので、当然ではあるのだが。そして、読んでも、弊社で実施している４，5カ月程度のシステム導入プロジェクトを、アジャイル方式にするイメージが余り湧かなかった。なんといっても、顧客にとって、アジャイル型を選択するメリットがイマイチ分からなった。基本設計までして、顧客から承認を得る必要があるとする。そのとき、請負型ではなく、準委任型で、なぜユーザー企業が発注してくれるのだろうか。準委任型で、開発発注するにしても、「何を開発するか」は決まっていないといけないわけだから、基本設計は顧客と行っておく必要があるように思えるのだが。基本設計まで終わっている機能を、準委任型で開発依頼してくれるためには、スケジュールと予算が潤沢にあるような企業じゃないと、無理なのかな、と思った。もしくは、要件がふわっとしていて、基本設計自体が無理で、開発して、その成果物をみないと要件が固まらないような内容なのだろうか。そうなると、それはもはやPOCのようでもあるのだろうか。
　「スクラムの源流は野中＆竹内のナレッジマネジメント論文である」という章の取り扱いも難しい。興味深くはあるが、スクラムの関連情報、アカデミックな組織分析である。スクラムの素養が日本企業にはあるよ、という意味では分かるのだが...。既に情報過多なので、ここで新しいアカデミックな話を入れてくるのであれば、事前のケーススタディに対する汎化、抽象化の章にしてほしかった。「野中さんと、点と点がつながる面白い話ができた！スクラムの関連情報だし、伝えたい」という意志を感じる。
　個人的に一番刺さったのは、ウォーターフォール型の仕事自体が楽しくない、と書いていること。今私が仕事で感じている辛みが簡潔な文章で表されていて、なるほどな、と思わされた。この文章と出会えただけで、★４つ。自分の生業、仕事内容を見直し、システム開発に携わるなら、アジャイル的な職場に移るように準備、努力をし始めようと思った。

>>p47「工程を追って順に仕事を進めるやり方は、仕事を渡す側と受ける側の間に敵対関係を生み出す傾向にある。「仕事に書かれていないことをやってほしいと言うのです」「簡単に気を変えないでほしい」「自分にコントロールできないことに対して、私は責任が持てません」などなど。ウォーターフォールの開発を観察すると別の発見がある。そう、仕事が楽しくないのだ。ウォータフォールの開発モデルは、製品作りに携わる人々のモチベーションをそぐ原因になる。そして、その結果できた製品は、作った現場開発者の創造性、スキル、そして情熱を表現するものにはならなにのだ。人はロボットではない。だから、人にロボットのように働くことを求めるプロセスは、介在する人々を不幸にする結果になる。」

【本書を読みながら気になったコト】
■アジャイル開発では、期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減する。ユーザーからフィードバックを取り入れながら開発する

■ウォーターフォール手法の問題点
・創造性を奪う。変更を拒み、部分最適な機能が出来上がる
・文書による完璧なコミュニケーションなど不可能
・完璧な計画を立てることはできず、必ず不確実なことが起きる
・工程を追って順に仕事を進めるので、ステークホルダー間で敵対関係ができて、仕事が面白くない

■インクリメント…スプリントにおける成果物、製品の機能。

■リファイアメント…プロダクトバックログの内容を更新する。優先順位の変更、機能詳細の追加、工数見積もりの変更を行う

■アジャイル開発という開発手法が存在するわけではい。アジャイル開発宣言の価値観を反映した開発の手法の1つがスクラムである


■こまめに完成物を見せて、フィードバックをもらう、という考え方自体はウォータフォール型の開発でも活かせる。その前提で工数、費用を見積もりする

■各種企業での実践例が記述されているが、何故多くのユーザー企業は、請負型ではなく、準委任型（アジャイル開発）でのプロジェクト推進を許したのか？
　→完成物責任が無い状態で、発注する（最終的な予算がいくらになるか見えてこない）以上、ユーザー企業としては、アジャイル開発を好みそうにないと思えたのだが
　・BtoBでリリースはどうやっている？細かくフィードバックをもらえないと、リリースはできない
　→なぜそんなにも、ユーザー企業は開発やスプリントレビューに付き合ってくれる？どうしてそんなにユーザー企業がアジャイル開発に理解があり、つきあってくれるのか？
　
■2020年3月にIPAからアジャイル開発版「システム・モデル取引・契約書」が公開された
　→準委任契約を前提とする
　→プロダクトオーナーはユーザー企業から選出する

■人生もウォーターフォールより、アジャイルに。変化を前提に。一定の期間、目標を決めて、実践しながら、時折振り返りを実践する
　

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

平鍋健児 / 野中郁次郎 / 及部敬雄

Scrum;
適応型ソリューション(adaptive solutions)をチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載された。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum」として紹介した。
スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており、スクラムの改良に伴ってこのガイドも更新されている。(Wikipedia)

Agile;
アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development)は「アジャイルソフトウェア開発」という概念を提唱した文書である。
2001年に、軽量ソフトウェア開発手法（と当時呼ばれてた）分野で名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法が共有する価値観を議論した。彼らはその結果を 「アジャイルソフトウェア開発宣言」という文書にまとめた。アジャイルソフトウェア開発宣言はアジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている。
この宣言は以下の4つの価値観を示し、これらの価値観を有するソフトウェア開発を「アジャイルソフトウェア開発」と名付けた。
・プロセスやツールよりも個人と対話を
　　Individuals and interactions over processes and tools
・包括的なドキュメントよりも動くソフトウェアを
　　Working software over comprehensive documentation
・契約交渉よりも顧客との協調を
　　Customer collaboration over contract negotiation
・計画に従うことよりも変化への対応を
　Responding to change over following a plan
(Wikipedia)

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

平鍋健児 / 野中郁次郎 / 及部敬雄

アジャイル開発とスクラム

企業内でもアジャイル開発が広まって来たと思う一方で、まだまだウォータフォール開発がなくならない現実。
アジャイル開発を知識創造型と呼びますが、人との繋がりによって臨機応変に動くことで、より良い、より市場に特化した製品やサービスを生み出す。
私達と顧客と見ることで、一体感を生み出す。

ソフト開発に限らず、ビジネスやマーケティングなどでもスクラムは取り入れられてきた。アメリカの海兵隊の陸海空が連動して動くシステムもまた、然りとのこと。

よりコミュニケーションを必要とすると考えれば、必ずしも万人に、良いものとは思えない。コミュニケーション高荷になりかねないのでは。
それでも、情が先にくるかっての日本企業が当時、この方法を取り入れることができたら、日本の歴史も少しは変わっていたかもしれませんね。