無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
日本生まれ、米国育ち 注目のソフトウェア開発手法「スクラム」
本書は、企業の経営層に向けて、ソフトウェアの開発手法アジャイルとその手法の1つである「スクラム」を体系的に解説するものである。また、スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを示し、この手法を取り入れ、ビジネスと一体となってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像について考える。日本におけるアジャイル開発の第一人者、平鍋健児氏と、世界的な経営学者でありスクラムの提唱者、野中郁次郎氏の両者が、日本企業のリーダーシップと競争力を高めるために必要な、知識創造プロセスの重要性を提言する。
※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
アジャイルの勉強として本を読みました。
2013年の本なので、紹介されている具体例は付箋を使ったり、壁にチャートを張り出したりとアナログな方法が中心でしたが、アジャイルやスクラムの基本的な考え方は現在も大きく変わっていないと思いますので、勉強になりました。
私はたまたまこの本が会社にあったので読みましたが、2021年に第2版が出ているので、今から読む人はそちらを読んだ方が良いと思います。
【第1部】
アジャイルとスクラムの概要だけ知りたい方は、第1部だけ読めば十分そうです。
アジャイル関係の用語と、それぞれがどういう意味なのかを知ることができて良かったです。
・スプリント
一定期間（通常1週間〜1か月）を区切って、決めた成果を完成させる開発サイクル。
このサイクルを繰り返すことで、「このチームなら1スプリントでどこまでできるか」という知見を蓄積できる。
・スクラムマスター
チームが円滑に開発できるよう支援する役割。
例えば、「他部署の承認待ちで作業できない」といった問題の解決や、「コードレビューに時間がかかる」といった問題の改善策を考える。
こうした役割を専門に担当する人を置く、という発想があることが印象に残りました。
【第2部】
アジャイルを採用した企業の実例集のような内容でした。
アジャイルについて概要を知りたいだけであれば、ここまで読まなくてもよさそうです。
一方で、企業改革のドキュメンタリーなどが好きな人には面白い内容だと思います。
個人的に印象に残ったところは以下です。
・アジャイルは、大規模開発や品質を特に重視する場面では難しい。
システムの根幹部分はウォーターフォールで開発し、フロントエンドはアジャイルで開発する、といった使い分けもある。
・ビジネス側と開発チームの信頼関係を構築するための工夫。
ビジネス側は仕様を伝えるだけでなく、背景や目的などのコンテキスト（文脈）も共有する。
開発チームは、内部の進捗状況をできるだけオープンにする。
・被災地で医療のためのシステムを急いで作る場合、アジャイルの短いサイクルでリリースし、ユーザーからのフィードバックを反映していく方法は、特に相性が良さそうだと思いました。
【第3部】
アジャイルの元になった考え方や、会社全体をアジャイルによってどう良くしていくか、といった、より大きな視点の内容でした。
アジャイルについてより深く知りたい人向けだと思います。
Posted by ブクログ
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
著：平鍋 健児
著：野中 郁次郎
けっこう分かりやすかった
構成は３部、第１部アジャイルとは何か、第２部ケーススタディ 第３部アジャイル開発と知のモデル である
■アジャイル開発とは
ウォータフォール開発に対して、アジャイル開発
アジャイル開発とは、短い期間を区切ってその中ですべての手順を踏んで動作する完成品の一部を開発する、それを繰り返すこと
アジャイル開発では、分析、設計、実装、テストを短い期間で並列で行うこれを繰り返す。動くソフトウエアを一定間隔を作り、それを成長しさせていく
アジャイル開発とは総称
・スクラム
・エクストリーム・プログラミング（ＸＰ）
・ユーザ機能駆動開発（ＦＤＤ）
・ＤＳＤＭ
・適応型ソフトウエア開発（ＡＳＤ）
・Ｃｒｙｓｔａｌ Ｃｌｅａｒ（クリスタルクリア）
・Ｅｖｏ（イボ）
■なぜアジャイル開発
・ウォータフォールだと時間がかかるので、ビジネスのリリースに遅れたり、完成したとき時代遅れになっている
・ウォータフォールだと、まったく使われない機能を実装してしまうケースが４５％、アジャイル開発であれば、常に必要な機能を実装し続けている
■スクラムとは
＜プロセス＞ １～４週間の期間を区切って開発を行う、その期間のことをスプリントという（アジャイルでは反復イテレーションという）
・プロダクトバックログ 開発すべき機能全体のリストをいう
・スプリントバックログ 今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
＜役割＞
・プロダクトオーナー
・開発チーム
・スクラムマスター 管理者ではなく、開発チームの支援者
＜成果物＞
・インクリメント：スプリントで完成した製品の機能のこと
・プロダクトバックログ 開発すべき機能の全体のリストをいう
・スプリントバックログ 今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
＜イベント＞
・スプリント 開発するための反復イテレーションの期間をいう
・スプリント計画 スプリントの開始に先立って行われるミーティング
・ディーリースクラム（朝会）
・スプリントレビュー スプリント終了時に製品のデモを行うこと
・レトロスペクティブ スプリントレビュー後に行われるふりかえり
そもそも、ウォーターフォールであれ、アジャイルであれ、必要な共通スキルがある
・ソフトウエアプログラミング、設計、テストに関する知識と経験
・ユーザ体験（ＵＸ）の知識と経験
・ＤＢやモデリングに関する知識と経験
・開発環境やツールに関する経験と知識
加えて、スクラム開発をするためには、アジャイル開発特有の活動（プラクティス）が必要
・ユーザストーリー ユーザの言葉で書かれた説明書
・プラニングポーカー プロダクトバックログから、スプリントバックログをつくるための手法、見積もりも合わせて行う
・朝会（ディーリースクラム） 昨日やったこと、今日やること、障害になっていること を確認する
・ふりかえり（レトロスペクティブ） ＫＰＴ（継続、問題、試用）次回改善したみたいことなどを洗い出す
・タスクかんばん 未実施、作業中、完了がわかるようにタスクをカードに書き出したものを壁にはって見える化をする
・バーンダウンチャート 進捗曲線、着地予測と残量確認ができるグラフ
・ペアプログラミング 難易度の高いプログラミングを２人でやる開発手法
・テスト駆動開発（ＴＤＤ）テストコードと製品コードを対に開発していく手法
・リファクタリング 既存のプログラムを外部仕様を変えずに内部を改善する開発手法
・継続的インテグレーション（ＣＩ）常に全体を動くようにビルドを最新に保つ管理方法
スクラムを支えるツール
・ＩＤＥ統合開発環境
・ソースコード管理ツール
・バグ管理システム
・クラウド（ＡＷＳ）等
■ケーススタディー
＜リクルート：リクナビ＞
・開発期間の短縮化
・開発のスピードアップ
・パッケージをつかうか、テンプレートをつかうのか、アジャイルをつかうのか ⇒ アジャイル
・ライバルメーカーがリリースする前にサービスをリリースするのが第一
・全体進捗わからない ⇒ バーンダウンチャート
・タイムボックス（１週間）に入る機能のみを開発に回す
・８０％できればＯＫ，２０％はできなくてもだれも怒らない
・アジャイルを使うのはＱＣＤのＤが重要
＜楽天：楽天市場＞
・運用と開発を並行で対応
・リリースしたら終わりではなく、運用の始まり
・継続的インテグレーション：ＣＩ。自動ビルドで常に動く状態で運用できる
・半分に開発をわけたら、前半の３．５倍後半に生産性がでた
・シンプル設計、リファクタリング、継続改善の文化
・見える化 ⇒ タスクボード、パーキングロットチャートを採用
・あるべき姿を求めて改善を続ける ⇒ 昨日より今日をよりよくすること
■アジャイルと知のモデル
・アジャイル開発は全員で開発に取り組む⇒全員で対応
・マルチ学習、多層学習、複数レベルで学習を行う
・柔らかなマネジメント 自己マネジメント＋相互マネジメント＋愛情によるマネジメント
・リーンスタートアップ ユーザについての知識を学びながら開発を進める
＜ＳＥＣＩモデル＞
共同化 暗黙知⇒暗黙知 個人の知を組織で共有
表出化 暗黙知⇒形式知 暗黙知を文書化して形式知化して伝達可能にする
連結化 形式知⇒形式知 知識を体系化し、新しい知識を生み出す活動
内面化 形式知⇒暗黙知 新たに生み出された形式知を個々人で実践して、暗黙知に変換する
＜アリストテレスの３つの知＞
エピステーメ 形式知 科学、哲学、再現可能
テクネー 暗黙知 技術、スキル、工芸、ノウハウ知
プロテシス 実践知 実践からの知恵、賢慮、価値観、倫理観
＜ＰＤＣＡとの関係＞
ＰＤＣＡはＰ：計画で始まる 計画は形式知で、計画ありき ⇒何を作るのではなく、なぜ作るを
イノベーションはまず、共同化から始まる ⇒ 共感、共振、共鳴
目次
はじめに
第１部 アジャイル開発とは何か、スクラムとは何か
第一章 アジャイル開発とは何か？
第二章 なぜ、アジャイル開発なのか
第三章 スクラムとは何か？
第四章 アジャイル開発の活動（プラクティス）
第２部 アジャイル開発とスクラムを実践する
第五章 スピード時代に独自のアジャイル手法
第六章 小さく始めて浸透させる〜楽天のアジャイルによる組織改革
第七章 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦
新たな分野への取り組みと「どうぶつ医療クラウド」システム開発
第３部 アジャイル開発とスクラムを考える
第八章 竹内・野中のスクラム論文再考
第九章 スクラムと知識創造
第十章 スクラムと実践知リーダー
特別対談 野中郁次郎×平鍋健児
おわりに
謝辞
参考文献案内
注
索引
ISBN：9784798129709
。出版社：翔泳社
。判型：4-6
。ページ数：288ページ
。定価：2000円（本体）
。発行年月日：2013年01月
。発売日：2013年01月17日
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 ブクログ
これは良書。一度は読んでおくべき本でした。
IT用語である「スクラム」という言葉を、実は逆輸入版だったと知って驚きました。今よりもずっと前に、日本で、しかも製造業の研究においてすでに「スクラム」という言葉と概念が作られており、ずっと後にアメリカのIT業界で正にこれだと復権したというのは面白いですね。
この導入から始まり、IT業界での「スクラム」の説明が展開され、最後に本来の「スクラム」（野中郁次郎）との融合が図られる構成も読んでいて楽しめるものでした。
第二版だと、初版では勘違いされやすいテーマの修正や組織論にまで展開されています。ただ、やっぱり「アジャイル」を組織に適用するのは無理なんだな～、という印象。なので、個別のプロジェクトとしては「アジャイル」ができたとしても、最終的には組織とぶつかるところが出てくるのは避けられなさそう。
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
ビジネス・実用
ビジネス・実用
ビジネス・実用
