平鍋健児の作品一覧

「平鍋健児」の「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」「アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」ほか、ユーザーレビューをお届けします！

作者をフォローする

フォローすると、この作者の新刊が配信された際に、お知らせします。

• 

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

  IT・コンピュータ / 全般

  3.9

  (30)

  • カート
  • 試し読み

  Posted by ブクログ

  アジャイル開発とスクラム　顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
  著：平鍋　健児
  著：野中　郁次郎
  
  けっこう分かりやすかった
  構成は３部、第１部アジャイルとは何か、第２部ケーススタディ　第３部アジャイル開発と知のモデル　である
  
  
  ■アジャイル開発とは
  
  ウォータフォール開発に対して、アジャイル開発
  アジャイル開発とは、短い期間を区切ってその中ですべての手順を踏んで動作する完成品の一部を開発する、それを繰り返すこと
  アジャイル開発では、分析、設計、実装、テストを短い期間で並列で行うこれを繰り返す。動くソフトウエアを一定間隔を作り、それを成長しさせていく
  
  アジャイル開発と...続きを読むは総称
  　・スクラム
  　・エクストリーム・プログラミング（ＸＰ）
  　・ユーザ機能駆動開発（ＦＤＤ）
  　・ＤＳＤＭ
  　・適応型ソフトウエア開発（ＡＳＤ）
  　・Ｃｒｙｓｔａｌ　Ｃｌｅａｒ（クリスタルクリア）
  　・Ｅｖｏ（イボ）
  
  ■なぜアジャイル開発
  　・ウォータフォールだと時間がかかるので、ビジネスのリリースに遅れたり、完成したとき時代遅れになっている
  　・ウォータフォールだと、まったく使われない機能を実装してしまうケースが４５％、アジャイル開発であれば、常に必要な機能を実装し続けている
  
  ■スクラムとは
  
  　＜プロセス＞　１～４週間の期間を区切って開発を行う、その期間のことをスプリントという（アジャイルでは反復イテレーションという）
  　・プロダクトバックログ　開発すべき機能全体のリストをいう
  　・スプリントバックログ　今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
  
  　＜役割＞
  　・プロダクトオーナー
  　・開発チーム
  　・スクラムマスター　管理者ではなく、開発チームの支援者
  
  　＜成果物＞
  　・インクリメント：スプリントで完成した製品の機能のこと
  　・プロダクトバックログ　開発すべき機能の全体のリストをいう
  　・スプリントバックログ　今回のスプリントで開発すべき機能の一覧、プロダクトバックログの１部
  
  　＜イベント＞
  　・スプリント　開発するための反復イテレーションの期間をいう
  　・スプリント計画　　スプリントの開始に先立って行われるミーティング
  　・ディーリースクラム（朝会）　
  　・スプリントレビュー　スプリント終了時に製品のデモを行うこと
  　・レトロスペクティブ　スプリントレビュー後に行われるふりかえり
  
  そもそも、ウォーターフォールであれ、アジャイルであれ、必要な共通スキルがある
  　・ソフトウエアプログラミング、設計、テストに関する知識と経験
  　・ユーザ体験（ＵＸ）の知識と経験
  　・ＤＢやモデリングに関する知識と経験
  　・開発環境やツールに関する経験と知識
  
  加えて、スクラム開発をするためには、アジャイル開発特有の活動（プラクティス）が必要
  　・ユーザストーリー　ユーザの言葉で書かれた説明書
  　・プラニングポーカー　プロダクトバックログから、スプリントバックログをつくるための手法、見積もりも合わせて行う
  　・朝会（ディーリースクラム）　昨日やったこと、今日やること、障害になっていること　を確認する
  　・ふりかえり（レトロスペクティブ） ＫＰＴ（継続、問題、試用）次回改善したみたいことなどを洗い出す
  　・タスクかんばん　未実施、作業中、完了がわかるようにタスクをカードに書き出したものを壁にはって見える化をする
  　・バーンダウンチャート　進捗曲線、着地予測と残量確認ができるグラフ
  　・ペアプログラミング　難易度の高いプログラミングを２人でやる開発手法
  　・テスト駆動開発（ＴＤＤ）テストコードと製品コードを対に開発していく手法
  　・リファクタリング　既存のプログラムを外部仕様を変えずに内部を改善する開発手法
  　・継続的インテグレーション（ＣＩ）常に全体を動くようにビルドを最新に保つ管理方法
  
  スクラムを支えるツール
  　・ＩＤＥ統合開発環境
  　・ソースコード管理ツール
  　・バグ管理システム
  　・クラウド（ＡＷＳ）等
  
  ■ケーススタディー
  
  ＜リクルート：リクナビ＞
  　・開発期間の短縮化
  　・開発のスピードアップ
  　・パッケージをつかうか、テンプレートをつかうのか、アジャイルをつかうのか　⇒　アジャイル
  　・ライバルメーカーがリリースする前にサービスをリリースするのが第一
  　・全体進捗わからない　⇒　バーンダウンチャート
  　・タイムボックス（１週間）に入る機能のみを開発に回す
  　・８０％できればＯＫ，２０％はできなくてもだれも怒らない
  　・アジャイルを使うのはＱＣＤのＤが重要
  
  ＜楽天：楽天市場＞
  　・運用と開発を並行で対応
  　・リリースしたら終わりではなく、運用の始まり
  　・継続的インテグレーション：ＣＩ。自動ビルドで常に動く状態で運用できる
  　・半分に開発をわけたら、前半の３．５倍後半に生産性がでた
  　・シンプル設計、リファクタリング、継続改善の文化
  　・見える化　⇒　タスクボード、パーキングロットチャートを採用
  　・あるべき姿を求めて改善を続ける　⇒　昨日より今日をよりよくすること
  
  ■アジャイルと知のモデル
  
  　・アジャイル開発は全員で開発に取り組む⇒全員で対応
  　・マルチ学習、多層学習、複数レベルで学習を行う
  　・柔らかなマネジメント　自己マネジメント＋相互マネジメント＋愛情によるマネジメント
  　・リーンスタートアップ　ユーザについての知識を学びながら開発を進める
  
  ＜ＳＥＣＩモデル＞
  　共同化　暗黙知⇒暗黙知　個人の知を組織で共有
  　表出化　暗黙知⇒形式知　暗黙知を文書化して形式知化して伝達可能にする
  　連結化　形式知⇒形式知　知識を体系化し、新しい知識を生み出す活動
  　内面化　形式知⇒暗黙知　新たに生み出された形式知を個々人で実践して、暗黙知に変換する
  
  ＜アリストテレスの３つの知＞
  　エピステーメ　形式知　科学、哲学、再現可能
  　テクネー　暗黙知　技術、スキル、工芸、ノウハウ知
  　プロテシス　実践知　実践からの知恵、賢慮、価値観、倫理観
  
  ＜ＰＤＣＡとの関係＞
  　ＰＤＣＡはＰ：計画で始まる　計画は形式知で、計画ありき　⇒何を作るのではなく、なぜ作るを
  　イノベーションはまず、共同化から始まる　⇒　共感、共振、共鳴
  
  目次
  
  はじめに
  
  第１部 アジャイル開発とは何か、スクラムとは何か
  
  第一章 アジャイル開発とは何か？
  第二章 なぜ、アジャイル開発なのか
  第三章 スクラムとは何か？
  第四章 アジャイル開発の活動（プラクティス）
  　
  第２部 アジャイル開発とスクラムを実践する
  
  
  第五章 スピード時代に独自のアジャイル手法
  第六章 小さく始めて浸透させる〜楽天のアジャイルによる組織改革
  第七章 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦
  　新たな分野への取り組みと「どうぶつ医療クラウド」システム開発
  
  第３部 アジャイル開発とスクラムを考える
  
  第八章 竹内・野中のスクラム論文再考
  第九章 スクラムと知識創造
  第十章 スクラムと実践知リーダー
  　
  特別対談 野中郁次郎×平鍋健児
  　
  　おわりに
  　謝辞
  　参考文献案内
  　注
  　索引
  
  ISBN：9784798129709
  。出版社：翔泳社
  。判型：4-6
  。ページ数：288ページ
  。定価：2000円（本体）
  。発行年月日：2013年01月
  。発売日：2013年01月17日

  0

  2024年01月10日
• 

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

  IT・コンピュータ / 言語・プログラミング

  4.2

  (12)

  • カート
  • 試し読み

  Posted by ブクログ

  たしかにスクラムの概要や導入のための具体的な手法を求めて読むには物足りない内容かも知れないが、スクラムのスケーリングのための手法 LeSS, SAFe, Nexus, Scrum@Scale の各手法の解説は、スクラムの全社的な展開の選択肢を広げる際の参考になる。関連して、終盤の自己相似的な組織の拡大の話も新鮮で刺激になった。

  0

  2022年10月03日
• 

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

  IT・コンピュータ / 言語・プログラミング

  4.2

  (12)

  • カート
  • 試し読み

  Posted by ブクログ

  スクラムをフレームワークとしてだけではなくて、人々の活動と捉えているところに著者たちの熱い気持ちを感じました。

  0

  2022年08月05日
• 

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

  IT・コンピュータ / 全般

  3.9

  (30)

  • カート
  • 試し読み

  Posted by ブクログ

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

  0

  2021年09月14日
• 

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

  IT・コンピュータ / 言語・プログラミング

  4.2

  (12)

  • カート
  • 試し読み

  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を見てください。ここはフェーズが重なった絵がありますが、よく見ると、最初のフェーズを示す円は最後に向かって伸びています。これを言い換えると、「最初に企画をした人は、最後までチームに残って、身体で意図を伝えよ」ということなんです。
  平鍋　これがプロダクトオーナーの仕事なんですね。ユーザーと開発チームを身体でつなぐ。そして、それができるのは、実践知リーダーだと。
  ＝＝＝＝＝＝＝

  0

  2021年05月23日