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

  • 翔泳社
3.94
  • (57)
  • (65)
  • (47)
  • (10)
  • (0)
本棚登録 : 532
レビュー : 70
  • Amazon.co.jp ・本 (288ページ)
  • / ISBN・EAN: 9784798129709

作品紹介・あらすじ

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

感想・レビュー・書評

並び替え
表示形式
表示件数
  • アジャイルラジオにて西さんがベタ褒めしていたので購入。
    「従来の開発手法では最初に計画をたてるため、途中で計画外のよりよいやり方が見つかっても採用できない。(p.55)」→実際すでにどうしようもない状況になってるときって多い。。。
    「話し合ってKeepから先に出すのは、この回を前向きに運営する鍵になる。まず、よかったことを出してProblemとTryに向かう勇気を出す。(p.72)」→単純に表面的な効率だけ考えるとKeepを飛ばしてしまいがちだけど、Keepは絶対あった方が良いと思う。人をほめる機会って意外とすごく少ない。
    「ペアプログラミングは、コストは二倍ではなく1.15倍、そのかわり、テスト通過率が15%増、コード行数は15%減した(p.86)」→やっぱり客観的なデータがあると説得力がある。行数で賃金が決まってる所は嬉しくないだろうけどw
    「アジャイルを進めていくというのは、どこまでも人を育てる話だと思ってるんです。(p.167)」→激しく同意。メンバーがもともと持っている熱意をいかにして表面化しやすい環境にみんなでしていくか。
    「いきなり「何を作る」のではなく、「なぜ作る」のかという情熱を、主観のままに伝えることが大事だと。(p.246)」→新入社員ならまずは言われたとおりにやるべきだけど、考えられるだけの経験を持っていても目的を理解しないまま作業に入ってしまうことが多い。指示する場合は目的も添えて、指示を受ける場合は目的を確認するように気をつけよう。
    「スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似形の知識創造活動であり、それを実践する人々である(p.271)」

  • 日本の事例が豊富に取り入れられており、共感・理解しやすい。
    また、スコープが大きく技術職だけではなく関わる顧客〜管理職〜技術職すべてにメリットが感じられるのではないか。
    実践・具体例は少ないので、本書→「アジャイルな見積りと計画づくり」の順で交互に読んでいくと取り入れ易いと思う。

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

    ワンチームマインド

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

    おわりに

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

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

    「合宿をしなさい」

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

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

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

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

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

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

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

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

  • 「合宿をしなさい」

  • 事例紹介がいい感じ。

  • <目次>
    はじめに プロローグ〜歴史的出会い
    第1部 アジャイル開発とは何か、スクラムとは何か
     第一章 アジャイル開発とは何か
     第二章 なぜ、アジャイル開発なのか
     第三章 スクラムとは何か
     第四章 アジャイル開発の活動(プラクティス)
    第2部 アジャイル開発とスクラムを実践する
     第五章 スピード時代に独自のアジャイル手法〜ワンチームマインドで挑むリクルート
     第六章 小さく始めて新党させる〜楽天のアジャイルによる組織改革
     第七章 「IT新市場」におけるアジャイル開発に取り組む富士通の朝鮮
    第3部 アジャイル開発とスクラムを考える
     第八章 竹内・野中のスクラム論文再考
     第九章 スクラムと知識創造
     第十章 スクラムと実践知リーダー
     特別対談 野中郁次郎x平鍋健児

    <メモ>
    オリジナルのスクラムの特徴(201)
    1.不安定な状態を保つ
    2.プロジェクトチームは自ら組織化する(自己組織化)
    3.開発フェーズを重複させる
    4.マルチ学習
    5.柔らかなマネジメント
    6.学びを組織で共有する(学習する組織)

    3M「成功よりも失敗からの方が学べることが覆い。ただし失敗するときには、創造的に失敗すること」(214)

    組織は、自然と成功したやり方を標準化して制度化する方向へと向かう。ただし、これが行き過ぎると逆に危険だ。外部環境が安定している場合には、過去の成功を「先人の知恵」として言葉で伝えたり、成功事例を元に標準を確立したりすることはうまくいく。しかし、外部の環境変化が速いと、このような教訓は逆に足かせになることがある。多くの場合、過去の成功体験を捨て去ることは難しく、外部環境の変化によって強制的に捨てることになる。(217)

    「学びを組織で共有する」というオリジナルのスクラムにある考え方は、アジャイル開発に抜けた部分として、日本のオリジナリティが活きる領域だとも筆者は考えている。(218)

    コンウェイの法則によれば「ソフトウェアの構造はそれを作り出した組織構造に従う」(221)



    日本が忘れてしまった実践知
    平鍋 実践知を駆使するには、やはり身体で動くことが不可欠なのですね。
    野中 そうです。新体制をともなわなくてはいけないわけです。考えるだけではいけない。そういう意味でわれわれは昔から「知行合一」とかいろいろなことを言ってきましたが、90年代、2000年代の日本は「分析過多」「計画過多」「コンプライアンス過多」というのがはびこるようになってしまった。
    日本のハードウェアや新製品開発が一番元気だったころに機能していた実践知リーダーシップを、われわれはいつの間にか喪失してしまったのです。それをなんと、ソフトウェアという新たなものづくりで復活させようという、平鍋さんたちの取り組みには感動しました。

    2011年、ジェフ・サザーランドとガブリエル・ベネフィールドが、スクラムのトレーニングを日本で開催した際の参加者からの質問
    「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門にステークホルダーがいるのです。そして、どの機能を優先すべきかについて意見が分かれているのです。意見をひとつにまとめるには、どうしたらよいのでしょうか」
    野中「形式的な会議で決めることはできない。いろんな背景をもった人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこからはじめて、一つの共通理解が生み出される。この過程をみんなで踏みなさい。」






    2014.04.07 池上さんから借りる
    2014.04.13 読書開始
    2014.04.20 読了
    2017.09.12 社内読書部

  • 著者の一人である野中郁次郎氏は、論文「The New New Product Development」の中で、「専門集団によって設計され、文書化されたナレッジが、次の工程の専門集団にに引き継がれ、これを繰り返して物を作っていく」プロセスに対して、当時、キャノン、ホンダなどが行っていた「色々な専門家が一体となり、自律的組織として物を作っていく」プロセスを、ラグビーに例えて、「スクラム」と呼んだ。このスクラムは、海を越え、アメリカでトップ・プログラマたちをインスパイアーした。そして、スクラムは、その名前のまま、ソフト開発プロセスの新ムーブメントとなり、故郷である日本に帰ってきた。
     ソフト開発は、現在のものづくりのみならず、会社経営にも非常に重要な要素であることは明らかであるが、日本のビジネスパーソンは、あまりにもソフトウエア・リテラシーが低い。私は、それが日本産業の生産性の低さの原因ではないかと思っている(残念ながら、これはわが社にも言える。特にソフト開発部門マネージメントのソフト開発リテラシーの低さは、悲惨を超えて喜劇的だ)。本書は、そういった状況を打破し、ソフト開発の改善、改革とそれを基盤にした経営改革にすばらしいアイデアを披露してくれるすばらしい本である。

  • 平鍋 健児

  • おわりに、にむけた壮大な前振り。事例が一番伝達効率悪そうだなあと思った。

全70件中 1 - 10件を表示

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

平鍋健児の作品

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメントを本棚に登録しているひと

ツイートする