平鍋健児のレビュー一覧
-
Posted by ブクログ
アジャイルの勉強として本を読みました。
2013年の本なので、紹介されている具体例は付箋を使ったり、壁にチャートを張り出したりとアナログな方法が中心でしたが、アジャイルやスクラムの基本的な考え方は現在も大きく変わっていないと思いますので、勉強になりました。
私はたまたまこの本が会社にあったので読みましたが、2021年に第2版が出ているので、今から読む人はそちらを読んだ方が良いと思います。
【第1部】
アジャイルとスクラムの概要だけ知りたい方は、第1部だけ読めば十分そうです。
アジャイル関係の用語と、それぞれがどういう意味なのかを知ることができて良かったです。
・スプリント
一定期間（通常1週間〜1か月）を区切って、決めた成果を完成させる開発サイクル。
このサイクルを繰り返すことで、「このチームなら1スプリントでどこまでできるか」という知見を蓄積できる。
・スクラムマスター
チームが円滑に開発できるよう支援する役割。
例えば、「他部署の承認待ちで作業できない」といった問題の解決や、「コードレビューに時間がかかる」といった問題の改善策を考える。
こうした役割を専門に担当する人を置く、という発想があることが印象に残りました。
【第2部】
アジャイルを採用した企業の実例集のような内容でした。
アジャイルについて概要を知りたいだけであれば、ここまで読まなくてもよさそうです。
一方で、企業改革のドキュメンタリーなどが好きな人には面白い内容だと思います。
個人的に印象に残ったところは以下です。
・アジャイルは、大規模開発や品質を特に重視する場面では難しい。
システムの根幹部分はウォーターフォールで開発し、フロントエンドはアジャイルで開発する、といった使い分けもある。
・ビジネス側と開発チームの信頼関係を構築するための工夫。
ビジネス側は仕様を伝えるだけでなく、背景や目的などのコンテキスト（文脈）も共有する。
開発チームは、内部の進捗状況をできるだけオープンにする。
・被災地で医療のためのシステムを急いで作る場合、アジャイルの短いサイクルでリリースし、ユーザーからのフィードバックを反映していく方法は、特に相性が良さそうだと思いました。
【第3部】
アジャイルの元になった考え方や、会社全体をアジャイルによってどう良くしていくか、といった、より大きな視点の内容でした。
アジャイルについてより深く知りたい人向けだと思います。 -
Posted by ブクログ
アジャイルの本質を、源流まで遡って理解できる本。
野中郁次郎先生の、SECIスパイラルとの関係も知り、改めてソフトウェア開発に留まらない、イノベーションを起こすマネジメントとリーダーシップの方法であるということが分かる。
暗黙知と形式知を回して知識創造を進めることにつながる、アジャイルの各種ミーティングや取り組み
サイロを自律分散型、フラクタルなチームや組織のあり方
実践知に基づくリーダーシップ→哲学やことば、目線、ロジックと情熱の双方をもった身体性を持って対話と言葉を語るリーダーシップの発揮が必要ということ
自律分散組織は、複雑適応系理論の応用ということで、複雑系の科学にもつながること
色んな示唆があり、自身の考えていること、関心のあることの全てにAgileが接地する事が分かった。複雑系は、システム思考的に森林保全を進めることや、アクターネットワーク理論にも繋がりそうだし、知識創造としてのAgileは現場主義と対話、身体性の重要性という、自身ができていないことへの向きなおりというか、総括して向かうものということが分かった。
さて、これから、socializationを、どこまでできるか。
なんとかしたいものだ
-
Posted by ブクログ
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
著：平鍋 健児
著：野中 郁次郎
けっこう分かりやすかった
構成は３部、第１部アジャイルとは何か、第２部ケーススタディ 第３部アジャイル開発と知のモデル である
■アジャイル開発とは
ウォータフォール開発に対して、アジャイル開発
アジャイル開発とは、短い期間を区切ってその中ですべての手順を踏んで動作する完成品の一部を開発する、それを繰り返すこと
アジャイル開発では、分析、設計、実装、テストを短い期間で並列で行うこれを繰り返す。動くソフトウエアを一定間隔を作り、それを成長しさせていく
アジャイル開発とは総称
・スクラム
・エクストリーム・プログラミング（ＸＰ）
・ユーザ機能駆動開発（ＦＤＤ）
・ＤＳＤＭ
・適応型ソフトウエア開発（ＡＳＤ）
・Ｃｒｙｓｔａｌ Ｃｌｅａｒ（クリスタルクリア）
・Ｅｖｏ（イボ）
■なぜアジャイル開発
・ウォータフォールだと時間がかかるので、ビジネスのリリースに遅れたり、完成したとき時代遅れになっている
・ウォータフォールだと、まったく使われない機能を実装してしまうケースが４５％、アジャイル開発であれば、常に必要な機能を実装し続けている
■スクラムとは
＜プロセス＞ １～４週間の期間を区切って開発を行う、その期間のことをスプリントという（アジャイルでは反復イテレーションという）
・プロダクトバックログ 開発すべき機能全体のリストをいう
・スプリントバックログ 今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
＜役割＞
・プロダクトオーナー
・開発チーム
・スクラムマスター 管理者ではなく、開発チームの支援者
＜成果物＞
・インクリメント：スプリントで完成した製品の機能のこと
・プロダクトバックログ 開発すべき機能の全体のリストをいう
・スプリントバックログ 今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
＜イベント＞
・スプリント 開発するための反復イテレーションの期間をいう
・スプリント計画 スプリントの開始に先立って行われるミーティング
・ディーリースクラム（朝会）
・スプリントレビュー スプリント終了時に製品のデモを行うこと
・レトロスペクティブ スプリントレビュー後に行われるふりかえり
そもそも、ウォーターフォールであれ、アジャイルであれ、必要な共通スキルがある
・ソフトウエアプログラミング、設計、テストに関する知識と経験
・ユーザ体験（ＵＸ）の知識と経験
・ＤＢやモデリングに関する知識と経験
・開発環境やツールに関する経験と知識
加えて、スクラム開発をするためには、アジャイル開発特有の活動（プラクティス）が必要
・ユーザストーリー ユーザの言葉で書かれた説明書
・プラニングポーカー プロダクトバックログから、スプリントバックログをつくるための手法、見積もりも合わせて行う
・朝会（ディーリースクラム） 昨日やったこと、今日やること、障害になっていること を確認する
・ふりかえり（レトロスペクティブ） ＫＰＴ（継続、問題、試用）次回改善したみたいことなどを洗い出す
・タスクかんばん 未実施、作業中、完了がわかるようにタスクをカードに書き出したものを壁にはって見える化をする
・バーンダウンチャート 進捗曲線、着地予測と残量確認ができるグラフ
・ペアプログラミング 難易度の高いプログラミングを２人でやる開発手法
・テスト駆動開発（ＴＤＤ）テストコードと製品コードを対に開発していく手法
・リファクタリング 既存のプログラムを外部仕様を変えずに内部を改善する開発手法
・継続的インテグレーション（ＣＩ）常に全体を動くようにビルドを最新に保つ管理方法
スクラムを支えるツール
・ＩＤＥ統合開発環境
・ソースコード管理ツール
・バグ管理システム
・クラウド（ＡＷＳ）等
■ケーススタディー
＜リクルート：リクナビ＞
・開発期間の短縮化
・開発のスピードアップ
・パッケージをつかうか、テンプレートをつかうのか、アジャイルをつかうのか ⇒ アジャイル
・ライバルメーカーがリリースする前にサービスをリリースするのが第一
・全体進捗わからない ⇒ バーンダウンチャート
・タイムボックス（１週間）に入る機能のみを開発に回す
・８０％できればＯＫ，２０％はできなくてもだれも怒らない
・アジャイルを使うのはＱＣＤのＤが重要
＜楽天：楽天市場＞
・運用と開発を並行で対応
・リリースしたら終わりではなく、運用の始まり
・継続的インテグレーション：ＣＩ。自動ビルドで常に動く状態で運用できる
・半分に開発をわけたら、前半の３．５倍後半に生産性がでた
・シンプル設計、リファクタリング、継続改善の文化
・見える化 ⇒ タスクボード、パーキングロットチャートを採用
・あるべき姿を求めて改善を続ける ⇒ 昨日より今日をよりよくすること
■アジャイルと知のモデル
・アジャイル開発は全員で開発に取り組む⇒全員で対応
・マルチ学習、多層学習、複数レベルで学習を行う
・柔らかなマネジメント 自己マネジメント＋相互マネジメント＋愛情によるマネジメント
・リーンスタートアップ ユーザについての知識を学びながら開発を進める
＜ＳＥＣＩモデル＞
共同化 暗黙知⇒暗黙知 個人の知を組織で共有
表出化 暗黙知⇒形式知 暗黙知を文書化して形式知化して伝達可能にする
連結化 形式知⇒形式知 知識を体系化し、新しい知識を生み出す活動
内面化 形式知⇒暗黙知 新たに生み出された形式知を個々人で実践して、暗黙知に変換する
＜アリストテレスの３つの知＞
エピステーメ 形式知 科学、哲学、再現可能
テクネー 暗黙知 技術、スキル、工芸、ノウハウ知
プロテシス 実践知 実践からの知恵、賢慮、価値観、倫理観
＜ＰＤＣＡとの関係＞
ＰＤＣＡはＰ：計画で始まる 計画は形式知で、計画ありき ⇒何を作るのではなく、なぜ作るを
イノベーションはまず、共同化から始まる ⇒ 共感、共振、共鳴
目次
はじめに
第１部 アジャイル開発とは何か、スクラムとは何か
第一章 アジャイル開発とは何か？
第二章 なぜ、アジャイル開発なのか
第三章 スクラムとは何か？
第四章 アジャイル開発の活動（プラクティス）
第２部 アジャイル開発とスクラムを実践する
第五章 スピード時代に独自のアジャイル手法
第六章 小さく始めて浸透させる〜楽天のアジャイルによる組織改革
第七章 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦
新たな分野への取り組みと「どうぶつ医療クラウド」システム開発
第３部 アジャイル開発とスクラムを考える
第八章 竹内・野中のスクラム論文再考
第九章 スクラムと知識創造
第十章 スクラムと実践知リーダー
特別対談 野中郁次郎×平鍋健児
おわりに
謝辞
参考文献案内
注
索引
ISBN：9784798129709
。出版社：翔泳社
。判型：4-6
。ページ数：288ページ
。定価：2000円（本体）
。発行年月日：2013年01月
。発売日：2013年01月17日 -
-
-
-
Posted by ブクログ
文句なしの★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を見てください。ここはフェーズが重なった絵がありますが、よく見ると、最初のフェーズを示す円は最後に向かって伸びています。これを言い換えると、「最初に企画をした人は、最後までチームに残って、身体で意図を伝えよ」ということなんです。
平鍋 これがプロダクトオーナーの仕事なんですね。ユーザーと開発チームを身体でつなぐ。そして、それができるのは、実践知リーダーだと。
＝＝＝＝＝＝＝ -
-
Posted by ブクログ
P.111 筆者（平鍋）は2000年にXPとケント・ベックに出会い「ソフトウェアは人が人のために作っている。『技術』と『人と人との関係性』、その両方がソフトウェア開発の本質だ」とはじめて気づき、ソフトウェア開発現場を改革していくことを、それ以降の仕事の中心とした。
ワンチームマインド
「何としてでもやってもらわないと困る」という100%のコミットメントを求められると答える側の開発者も慎重にならざるを得ない。このため「この件に関しましては持ち帰って検討いたします」となって検討と後日回答の繰り返しが常態化しプロジェクトが進まない。そこで思い切って「可能性80%ならOKと答えてよい。そのかわり持ち帰りは厳禁」という方針を打ち出し、これにより進捗のスピードとプロジェクトの風通しが著しく改善した。
おわりに
「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門にステークホルダーがいるのです。そしてどの機能を優先すべきかについて意見が分かれているのです。意見を一つにまとめるにはどうしたらよいのでしょうか」
「野中先生はどう思われますか？」
「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこでなぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこからはじめて、一つの共通理解が生み出される。この過程をみんなで踏みなさい」 -
Posted by ブクログ
日本におけるアジャイル開発の第一人者の平鍋さんと、スクラムの父と呼ばれる野中郁次郎先生によるアジャイル開発の解説本。 アジャイル・スクラムとは何ぞや、から始まり、貴重な比較的大規模開発の事例の紹介とキーパーソンへのインタビュー、そして対談形式でアジャイル・スクラムの成り立ちや背景となっている思想が語られている。 アジャイルに限らず、方法論が語られることが多いが、本書では考え方や思想が強調されているところが非常に興味深い。 特にスクラムに大きな影響を与えているSECIモデルによる暗黙知→形式知のループの考え方は自分の思考方法について考えされられた、と同時に実践しないといけないと感じた。 今回、著書の平鍋さんにサインをいただくことができたが、サインに添えられた一言「仕事を楽しく変えて行きましょう！」にアジャイルの全てが詰まっていると思う。 楽しくなければやっていけないよね！ アジャイルの考え方を学ぶにはとても良い本だと思う。エンジニアはもちろん経営者にもぜひ読んでいただきたい。
-
-
Posted by ブクログ
顧客満足や市場創出などビジネスの価値を創造することを目的としたアジャイル開発、開発環境である、継続的イテレーション、テスト駆動開発、リファクタリング、ペアプログラミング、チーム環境である朝会、タスクかんばん、プランニングポーカー、ふりかえり（KPT)などの方法論も技術論ではなく経営的な視点で書かれているので、とても全体像が掴み易い。
スクラムは元々野中郁次郎氏と竹内弘高氏がHarvard Business Review 誌に "The New New Product Development Game" として80年代の日本企業であるホンダやキャノンの新製品開発のなどを例として発表した論文をベースにしていて、本書でも再考と称して「アジャイルソフトウェア開発スクラム」との比較が行われている。
アジャイルでなぜ生産性があがるかとの議論では、最初に考えた機能を全部作成しないからというのが定説のようだが、どうやらそれだけではないようだ。不安定な状態から自ら組織化して、専門分野を越えた多層学習、多能力学習によって学びを組織で共有し、メンバーそして組織が成長して生産性が高まるのだ。逆に言えば成長の無いアジャイルは不完全であり、そもそもアジャイルはソフトウェア開発の方法論ではなく経営論と言ったほうが適切なのではないだろうか。
一年ほど積読にしていたのが悔やまれる名著です。 -
Posted by ブクログ
アジャイルラジオにて西さんがベタ褒めしていたので購入。
「従来の開発手法では最初に計画をたてるため、途中で計画外のよりよいやり方が見つかっても採用できない。(p.55)」→実際すでにどうしようもない状況になってるときって多い。。。
「話し合ってKeepから先に出すのは、この回を前向きに運営する鍵になる。まず、よかったことを出してProblemとTryに向かう勇気を出す。(p.72)」→単純に表面的な効率だけ考えるとKeepを飛ばしてしまいがちだけど、Keepは絶対あった方が良いと思う。人をほめる機会って意外とすごく少ない。
「ペアプログラミングは、コストは二倍ではなく1.15倍、そのかわり、テスト通過率が15%増、コード行数は15%減した(p.86)」→やっぱり客観的なデータがあると説得力がある。行数で賃金が決まってる所は嬉しくないだろうけどw
「アジャイルを進めていくというのは、どこまでも人を育てる話だと思ってるんです。(p.167)」→激しく同意。メンバーがもともと持っている熱意をいかにして表面化しやすい環境にみんなでしていくか。
「いきなり「何を作る」のではなく、「なぜ作る」のかという情熱を、主観のままに伝えることが大事だと。(p.246)」→新入社員ならまずは言われたとおりにやるべきだけど、考えられるだけの経験を持っていても目的を理解しないまま作業に入ってしまうことが多い。指示する場合は目的も添えて、指示を受ける場合は目的を確認するように気をつけよう。
「スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似形の知識創造活動であり、それを実践する人々である(p.271)」 -
-
Posted by ブクログ
ネタバレ「アジャイル」については一年以上前からその存在は知っていた。しかししっかりした意味を学ぶことはなかった。
今回、この本を読んだ事でその意味は判ったと想う。
その上で「アジャイルとプロジェクトマネジメントは水と油だ」と言う表現に疑問が生じた。アジャイルは「マネジメントしないプロジェクトマネジメント」なだけで水と油では無く、プロジェクトを完遂する手法の一つ、言わば水とジュースの様な間柄では無いか。ものによってはプロジェクトマネジメント手法がマッチするし、ものによってはアジャイルがマッチする。そんなイメージが在る。企業風土や職種、そのプロジェクトの目指すものによって使い分ける柔軟性が必要な気がする。
本書は「アジャイルとは何か」から始まり、定義、構成するもの、魂について触れる。まさに「アジャイルの扉」で開けようかどうしようか迷って居る人に、何も言わずそっと差し出すのに最適な本で在る。また「アジャイル」の存在を知らずとも、組織の活動に疑問、不満を持つ人々、コミュニケーションの在り方や会議の在り方に悩む人々の＂モヤモヤ感＂を振り払う可能性を秘めて居る。
そんな意味ではＩＴに限らない職種（例えば飲食業、建築業、小売店）などにも是非オススメしたい。大切なのは技術だけで無く思想（魂）なのだから。
もし適用して＂すんげえ良かったよ！＂と感じられたら、是非ともシェアして頂きたい。
そんな未来を感じさせる素晴らしい本である。
《投稿用更新》 -
-
-
Posted by ブクログ
これは良書。一度は読んでおくべき本でした。
IT用語である「スクラム」という言葉を、実は逆輸入版だったと知って驚きました。今よりもずっと前に、日本で、しかも製造業の研究においてすでに「スクラム」という言葉と概念が作られており、ずっと後にアメリカのIT業界で正にこれだと復権したというのは面白いですね。
この導入から始まり、IT業界での「スクラム」の説明が展開され、最後に本来の「スクラム」（野中郁次郎）との融合が図られる構成も読んでいて楽しめるものでした。
第二版だと、初版では勘違いされやすいテーマの修正や組織論にまで展開されています。ただ、やっぱり「アジャイル」を組織に適用するのは無理なんだな～、という印象。なので、個別のプロジェクトとしては「アジャイル」ができたとしても、最終的には組織とぶつかるところが出てくるのは避けられなさそう。 -
-
Posted by ブクログ
ウォーターフォール型の開発は敵対関係を生み出しやすく、面白くない→個人的に刺さった
【感想】
スクラムを中心に、アジャイル開発の技法、企業への導入エピソードが紹介されている。アジャイル開発は大きく技術的手法、組織的手法に分けられる。本書は、組織的手法である「スクラム」の記述に焦点をあてていて、技術的手法の詳細には立ち入っていない。リファクタリングやTDD、CI等については紹介程度の記述がある。実際の開発で生かすには、別の本を読む必要があるだろう。
とかく、情報が分散していて、章ごとのつながりを捉えるのが難しく、咀嚼が難しいと感じた。おそらく、この本の目的は「アジャイル開発手法とスクラムについて色々な観点で紹介する」ことなのだろう。フレームワーク・プラクティスがかなり多く登場するし、ケーススタディの登場企業も多い（覚えて使いこなすことが難しい）。
企業４社ごとのアジャイル導入経験も記述されているのが、各企業群をまとめて抽象化していないので、頭に叩き込むのが難しい。研究書ではないので、当然ではあるのだが。そして、読んでも、弊社で実施している４，5カ月程度のシステム導入プロジェクトを、アジャイル方式にするイメージが余り湧かなかった。なんといっても、顧客にとって、アジャイル型を選択するメリットがイマイチ分からなった。基本設計までして、顧客から承認を得る必要があるとする。そのとき、請負型ではなく、準委任型で、なぜユーザー企業が発注してくれるのだろうか。準委任型で、開発発注するにしても、「何を開発するか」は決まっていないといけないわけだから、基本設計は顧客と行っておく必要があるように思えるのだが。基本設計まで終わっている機能を、準委任型で開発依頼してくれるためには、スケジュールと予算が潤沢にあるような企業じゃないと、無理なのかな、と思った。もしくは、要件がふわっとしていて、基本設計自体が無理で、開発して、その成果物をみないと要件が固まらないような内容なのだろうか。そうなると、それはもはやPOCのようでもあるのだろうか。
「スクラムの源流は野中＆竹内のナレッジマネジメント論文である」という章の取り扱いも難しい。興味深くはあるが、スクラムの関連情報、アカデミックな組織分析である。スクラムの素養が日本企業にはあるよ、という意味では分かるのだが...。既に情報過多なので、ここで新しいアカデミックな話を入れてくるのであれば、事前のケーススタディに対する汎化、抽象化の章にしてほしかった。「野中さんと、点と点がつながる面白い話ができた！スクラムの関連情報だし、伝えたい」という意志を感じる。
個人的に一番刺さったのは、ウォーターフォール型の仕事自体が楽しくない、と書いていること。今私が仕事で感じている辛みが簡潔な文章で表されていて、なるほどな、と思わされた。この文章と出会えただけで、★４つ。自分の生業、仕事内容を見直し、システム開発に携わるなら、アジャイル的な職場に移るように準備、努力をし始めようと思った。
>>p47「工程を追って順に仕事を進めるやり方は、仕事を渡す側と受ける側の間に敵対関係を生み出す傾向にある。「仕事に書かれていないことをやってほしいと言うのです」「簡単に気を変えないでほしい」「自分にコントロールできないことに対して、私は責任が持てません」などなど。ウォーターフォールの開発を観察すると別の発見がある。そう、仕事が楽しくないのだ。ウォータフォールの開発モデルは、製品作りに携わる人々のモチベーションをそぐ原因になる。そして、その結果できた製品は、作った現場開発者の創造性、スキル、そして情熱を表現するものにはならなにのだ。人はロボットではない。だから、人にロボットのように働くことを求めるプロセスは、介在する人々を不幸にする結果になる。」
【本書を読みながら気になったコト】
■アジャイル開発では、期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減する。ユーザーからフィードバックを取り入れながら開発する
■ウォーターフォール手法の問題点
・創造性を奪う。変更を拒み、部分最適な機能が出来上がる
・文書による完璧なコミュニケーションなど不可能
・完璧な計画を立てることはできず、必ず不確実なことが起きる
・工程を追って順に仕事を進めるので、ステークホルダー間で敵対関係ができて、仕事が面白くない
■インクリメント…スプリントにおける成果物、製品の機能。
■リファイアメント…プロダクトバックログの内容を更新する。優先順位の変更、機能詳細の追加、工数見積もりの変更を行う
■アジャイル開発という開発手法が存在するわけではい。アジャイル開発宣言の価値観を反映した開発の手法の1つがスクラムである
■こまめに完成物を見せて、フィードバックをもらう、という考え方自体はウォータフォール型の開発でも活かせる。その前提で工数、費用を見積もりする
■各種企業での実践例が記述されているが、何故多くのユーザー企業は、請負型ではなく、準委任型（アジャイル開発）でのプロジェクト推進を許したのか？
→完成物責任が無い状態で、発注する（最終的な予算がいくらになるか見えてこない）以上、ユーザー企業としては、アジャイル開発を好みそうにないと思えたのだが
・BtoBでリリースはどうやっている？細かくフィードバックをもらえないと、リリースはできない
→なぜそんなにも、ユーザー企業は開発やスプリントレビューに付き合ってくれる？どうしてそんなにユーザー企業がアジャイル開発に理解があり、つきあってくれるのか？
■2020年3月にIPAからアジャイル開発版「システム・モデル取引・契約書」が公開された
→準委任契約を前提とする
→プロダクトオーナーはユーザー企業から選出する
■人生もウォーターフォールより、アジャイルに。変化を前提に。一定の期間、目標を決めて、実践しながら、時折振り返りを実践する