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

  • 翔泳社
3.95
  • (64)
  • (69)
  • (52)
  • (11)
  • (0)
本棚登録 : 652
感想 : 78
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (287ページ)
  • / ISBN・EAN: 9784798129709

作品紹介・あらすじ

企業の経営層に向けてソフトウェア開発手法の「アジャイル」とその手法の一つである「スクラム」を体系的に解説。スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを提示する。さらに、この手法を取り入れ、ビジネスと一体になってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像についても考える。日本におけるアジャイル開発の第一人者と世界的な経営学者・スクラム産みの親による提言。業界をリードするリクルート・富士通・楽天の最新開発事例を収録。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
    著:平鍋 健児
    著:野中 郁次郎

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


    ■アジャイル開発とは

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

    アジャイル開発とは総称
     ・スクラム
     ・エクストリーム・プログラミング(XP)
     ・ユーザ機能駆動開発(FDD)
     ・DSDM
     ・適応型ソフトウエア開発(ASD)
     ・Crystal Clear(クリスタルクリア)
     ・Evo(イボ)

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

    ■スクラムとは

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

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

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

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

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

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

    スクラムを支えるツール
     ・IDE統合開発環境
     ・ソースコード管理ツール
     ・バグ管理システム
     ・クラウド(AWS)等

    ■ケーススタディー

    <リクルート:リクナビ>
     ・開発期間の短縮化
     ・開発のスピードアップ
     ・パッケージをつかうか、テンプレートをつかうのか、アジャイルをつかうのか ⇒ アジャイル
     ・ライバルメーカーがリリースする前にサービスをリリースするのが第一
     ・全体進捗わからない ⇒ バーンダウンチャート
     ・タイムボックス(1週間)に入る機能のみを開発に回す
     ・80%できればOK,20%はできなくてもだれも怒らない
     ・アジャイルを使うのはQCDのDが重要

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

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

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

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

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

    <PDCAとの関係>
     PDCAはP:計画で始まる 計画は形式知で、計画ありき ⇒何を作るのではなく、なぜ作るを
     イノベーションはまず、共同化から始まる ⇒ 共感、共振、共鳴

    目次

    はじめに

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

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


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

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

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

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

  • アジャイルラジオにて西さんがベタ褒めしていたので購入。
    「従来の開発手法では最初に計画をたてるため、途中で計画外のよりよいやり方が見つかっても採用できない。(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業界での「スクラム」の説明が展開され、最後に本来の「スクラム」(野中郁次郎)との融合が図られる構成も読んでいて楽しめるものでした。
    第二版だと、初版では勘違いされやすいテーマの修正や組織論にまで展開されています。ただ、やっぱり「アジャイル」を組織に適用するのは無理なんだな~、という印象。なので、個別のプロジェクトとしては「アジャイル」ができたとしても、最終的には組織とぶつかるところが出てくるのは避けられなさそう。

  • 開発者、PMがアジャイル開発やる前に読む本。の用語が丸っと学べる

  • スクラムのバイブル

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

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

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

  • アジャイル/スクラムの説得力を伴うLoveな本。デメリットや問題点に関するところは弱い。人にアジャイル/スクラムを勧めるときに根拠となる理屈がひととおり網羅されている。

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

    ワンチームマインド

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

    おわりに

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

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

    「合宿をしなさい」

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

全78件中 1 - 10件を表示

著者プロフィール

平鍋 健児:(株)永和システムマネジメント 代表取締役社長

「2023年 『世界標準MIT教科書 ストラング:教養の線形代数』 で使われていた紹介文から引用しています。」

平鍋健児の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×