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

平鍋健児 / 野中郁次郎

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

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

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

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

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

アジャイルの、特にスクラムのやり方、考え方がよくわかる。知識が全く無い状態から読み出すアジャイルの本としてもいいと思う。
後半はアメリカから逆輸入される前の、野中氏が書いた元祖スクラムの自画自賛であるが、確かにためになることはいろいろ書いてある。が、そこはほとんど読み飛ばしてしまった。

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

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

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

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

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

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

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

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

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

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

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

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