平鍋健児のレビュー一覧

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎

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

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

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

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

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

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

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

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎

四年ぶりに再読。アジャイルやスクラムはある程度理解している前提で、何度読んでも会話の重要性は再認識する。ビジネスとエンジニアの垣根を超えるコミュニケーションはやっぱどうあがいても大事。政治的事情でよしとされない場合でも、ダマで勝手にやっちまおう。
しかし読むたびにtypeAからCの考え方混乱するわ。Aが普通のスクラムだとおもってたが、やっぱちがうな。

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

平鍋健児 / 野中郁次郎

アジャイルとは何か、そして自分自身の業務にどのように取り込んでいけば良いか、ということを考えさせられる一冊。スクラムの本質に迫る野中氏との対談も読み応えありました。

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

平鍋健児 / 野中郁次郎

ひさしぶりにこういう専門書を読んだ。
面白かった。ソフトウェアもウォーターフォールではなく、こうしたアジャイル型の開発が進むのだろうか？

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

平鍋健児 / 野中郁次郎

SECIモデルで知られる野中郁次郎氏の論文が、アジャイルのアイディアのもとになっていると聞いて拝読。

その点では本書後半において明らかになっており、アジャイルを単なる高速ソフトウェア開発のプラクティスではなく、情報共有、知識共有という、IT企業にとって必要不可欠な要素と結びつけて考えることができるようになった。前半は一般的なアジャイルの説明に終始するため、後半こそ、野中氏が関わっている本書の本質であると思う。

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

平鍋健児 / 野中郁次郎

アジャイル開発、スクラムという概念を理解するつもりで読んだので、その目的は達成できた。（だから★４つ）
プラットフォーム上でのサービス開発には使えるなと思う反面、大規模プラットフォーム開発の主戦場ではつかえないかも。日本が負けているのは、サービス開発ではなく、プラットフォーム開発（戦略）だと思っているので、いまここに乗ることが本当にやることなのかという疑問はのこった。

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

平鍋健児 / 野中郁次郎

スクラムの勉強で購入。
スクラムの基本的な考え方とか、わかりやすくて良かった。
あと楽天とリクルートでの実例もあって、これからスクラムを入れるにあたって、すごく参考になる内容。

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

平鍋健児 / 野中郁次郎

今となっては随分古い内容になった気がする。
XPのプラクティスなんて殆どが当たり前になってきた。
初めて読んだ当時は、こんなの現実的でないなんて思ってたのに…
技術的な内容というより、ポエムというか概念というか、理念か…？
まぁサクサク読めたけど、この先どんどん陳腐化していきそうな…

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

平鍋健児 / 野中郁次郎 / 及部敬雄

■従来手法の何が問題なのか？
・人の創造性を奪ってしまう
・文書によるコミュニケーションには限界がある
・悪いタイミング
・未来を読む水晶玉はない
・仕事が楽しくない
・部分最適化

■アジャイルを大規模化するフレームワーク
【共通する点】
１．既にうまくいったチームが２つ以上あること
２．大規模化する必要があること

・Nexus：最も純粋なスクラムの複数チーム拡張。あくまでソフトウェアのプロダクト開発に焦点がある。チーム間の依存関係を調整しながら、同期的に全体スプリントを回し、動くソフトウェアをデリバリーする。
・Scrum@Scale：単にソフトウェア開発手法としてのスクラムを拡張したものではなく、スクラムによる組織運営を主眼としたフレームワーク。会社全体がすばやい意思決定と顧客指向の組織に変わること、そして、優れたプロダクトやサービスを市場に出していくことの両方を指向している。また、マーケティングチームや人事チームなど、これまでアジャイルが対象としてこなかったチームにも、スクラムを適用する。よって、導入には会社の方針が必要となる。EATを採用するには、エグゼクティブレベルの意思決定が必要になる。
・SAFe：プロダクト開発の方法論に留まらず組織運営や文化形成までを対象にしたフレームワーク。プロダクトを作る部分はもちろん、そこに至るまでの判断やワークフロー、チームを支える組織を対象とすることで、部分最適ではなく全体最適を目指している。
　また、SAFeは大規模アジャイルフレームワークの中でもトップのシェアを誇っていて、世界中の多くの企業による導入事例がある。ScaledAgile,Inc.によって事業として運営されていることもあり、トレーニングや認定制度導入支援をしている企業や団体も多い。
　SAFeの全体像を見ると複雑で難しく感じるかもしれないが、導入レベルに合わせた4つの構成、ロードマップ導入事例導入支援を受けられるという点が高いシェアにつながっている。
・LeSS：シンプルにスクラムを大規模開発に適応させたフレームワーク。チームを中心に、大規模に適応させるために必要なものだけを追加している。そのため、ある程度スクラムに慣れたチームや組織にとっては、すんなりと受け入れることができるであろう。
　一方で、用意されたプロセスやルールを使って一気に導入したい場合には向かないかもしれない。プロダクトやプロダクトグループの成長に合わせて学習を繰り返し、フレームワークも成長させていく姿勢が求められる。
　Nexusと共通点は多いが、詳細では違うところもある。スクラムの共同開発者の1人であるケン・シュエーバーが開発したNexusとは違うルートで、開発現場の大規模開発へのニーズに適応していったスクラムの形だといえる。
・Disciplined Agile：エンタープライズ対応に重きを置き、これまでアジャイルに含まれていなかった、「ガバナンス」「文書標準」「レビュー」「エスカレーション」「教育」「運用」「予算」「人事評価」などという言葉が出てくる。リアルな大企業でよく聞く言葉群だ。例えば、契約方法やリソースの戦略が「方向付け」フェーズの「予算確保」というゴールに登場する。
　また、これまでチームベースのアジャイルがわざと避けてきた大域構造を示す言葉群、「アーキテクチャ」「フェーズ」を積極的に入れている。スコット・アンブラーの過去の仕事から、ラショナル・ユニファイド・プロセス(RUP)、アジャイル・モデリング(AM)、アジャイル・データ(AD)などの視点もしっかり入っており、集大成的なアジャイル百科事典ともいえるだろう。
　PMIがこの手法を取得したことで、今後PMBOKと相乗した普及活動が活発になるだろう。

■事例：NTTコムウェア
【社内プロセスの変革】
　そこで、これらの既存プロセスが抱える課題感例えばNTTコムウェアとしてウォーターフォール開発で積み上げてきた、統計データに基づく品質評価が、
・案件ごとに完成の定義が異なり、試験工程をまとめて取らないスクラムに適さない
・意思決定の会議体に必要となる、資料作成や事務処理、事前説明等が煩雑である
といった課題に対し、冒頭で出てきたアジャイル推進組織とともに、カイゼンに取り組んだ。
　このプロセス改革においては、アジャイル開発の実践と同様、守破離のマインドで取り組んだ。実際にスクラムを行う中で、社内プロセスに対し理想論を押し付けず、既存のプロセスで取り組み、結果として見えた既存制度の課題点を、他組織を巻き込むことで社内プロセスの変革につなげたのである。
　例えば品質評価のプロセスにおいては先述の通り、統計データに基づいたテスト消化曲線やパ発生曲線の収束を目指す従来型の評価方法が主流であった。しかし、開発の中で試験を同時に実施する私たちのチームでは時系列曲線を描くことができない上、「バグ」の定義も困難であった。
　こういった課題に対し、定性的な評価として「プロダクトオーナーによる評価レポート」や、「品質コントロールのために行った施策の透明化」を用い、定量的な評価として「循環的複雑度」や「長期的に見たモジュールごとのコミット数」(コミット数が多い=リファクタリング頻度が高いモジュールは要注意)を用いる等、新たな品質評価の可能性を品質管理部門と連携して模索した。これら新たな指標値の出力に自動化を組み合わせることで意思決定プロセスの短縮化に挑戦した。


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

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

平鍋健児 / 野中郁次郎 / 及部敬雄

アジャイル・サムライを読んだ後だったので、「ふーん」という感じだった。

開発現場に深く入ってない人が「アジャイルってどんなもんじゃい？」というときに読むと非常にいいかも。

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

平鍋健児 / 野中郁次郎

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

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

平鍋健児 / 野中郁次郎

本書は、共著者に野中郁次郎が入っていることからもわかるように、システム開発に従事している人でなくても、経営視点でアジャイルとスクラムについて解説している。やや抽象的なところが多いが、この分野で初めて読むにはお薦め。しかし、米国で始まったスクラムが実は竹内・野中が日本の製造業でのイノベーションの手法として名付けた「スクラム」から来ているとは驚きであった。また、実際にスクラムを採用した、リクルート、楽天、富士通の方のインタビューも興味深かった。

・アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。
・アジャイル開発では、すばやくユーザーや顧客のフィードバックを得ることで、ムダな機能を作ることを防ぎ、市場投入のスピードを上げ、ビジネスの投資対効果を高める。
・ウォーターフォールの問題点
　?人の創造性を奪ってしまう
　?文書によるコミュニケーションには限界がある
　?悪いタイミング
　?未来を読む水晶玉はない
　?仕事が楽しくない
　?部分最適化
・アジャイル開発の現場がいかにアナログのコミュニケーションを重視しながら、チーム内の暗黙知を共有し、テストとコードという動くものによって品質を作っていくかがわかる。
・従来の発注・受注関係のままだと、開発チーム側は事業担当者から「何としてでもやってもらわないと困る」と言われても断ることができない。その結果、開発側は次回から検討や文書作成に慎重に時間をかけ、さらに安全のためのバッファを追加した見積もをすることになる。これが繰り返されると、そのバッファ分だけ納期は伸び、かつ開発効率も落ちていく。
・技術的負債とは、メンテナンスが難しいコードの増加が開発の足かせになることを借金（負債）になぞらえて表現したものだ。

・楽天開発部の方の言
「僕自身、そうしたボトルネックになるのは何としてもいやなので、そうならないためにもプログラムだって書ける、アジャイルなマネージャーを目指しているつもりです。まず自分が成長しないことには、チームが成長することはできないと思う。」
「テストが終わりじゃなくて、そこから次のステップに進んでいけるんです。だからこそ、リリースのときには、作った開発者自身に現場に入ってもらいました。」

・実践知リーダーシップに必要な六つの能力
　?「善い」目的を作る能力
　?「場」をタイムリーに作る能力
　?ありのままの現実を直観する能力
　?直観の本質を概念に変換する能力
　?概念を実現する能力
　?実践知を組織化する能力

・一つには、リーダーシップの形が変わる必要があるでしょう。対話と場作りを重視したプロジェクト運営、その場その場で共感を作り、高い視点の価値観で判断する実践知リーダーシップです。

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

平鍋健児 / 野中郁次郎

アジャイル開発のサイクルがわかる１冊。おかげで過去に読んだ「SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法」（2017年. ジェイク・ナップ (著)）に書いてあった意味がようやくわかるようになった。

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

平鍋健児 / 野中郁次郎

どういった要求に対してアジャイルの考え方が生まれたか、具体的な手法の例が読みやすく書いてある。
知ることと実際に適用するのは別だが、アジャイルの考え方を手っ取り早く把握するのにはまずまず。

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

平鍋健児 / 野中郁次郎

なんかこう、しっくりこない。
ソリューション開発には確かに向いてなくはない。
受託開発のなかで適用するのはなかなか難しそう。
筆者もそれは認めていて、そのようなスキームの中での適用の工夫を述べている個所もある。

できたら、「受託開発における」スクラム開発について、本を出してもらえないかな。

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

平鍋健児 / 野中郁次郎

顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
見積もりポーカーやKPTなどアジャイル開発の方法論について記載されていてアジャイルを知らない人がざっと分かる本。（1章しか読んでいない）

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

平鍋健児 / 野中郁次郎

「持ち帰り禁止ルール」は自分の組織にも適用してみたがうまくいった。全員で定義がはっきりしたルールを定める重要性を体感。野中先生節はやっぱ好き。

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

平鍋健児 / 野中郁次郎

前半でアジャイルの概要を説明し、後半でこれを実施した企業の事例を紹介し、最後に著者二人の対談を載せた本。

前半の解説部分は可もなく不可もなく。後半の事例紹介では当事者のインタビューが掲載されており、どのような困難に直面しそれをどのように乗り越えたか、に関する生の声を目にでき、それなりに有意義。最後の対談部分は、学者らしい抽象論に終始しており、実践知である「アジャイル的」なるものとは正反対の趣で萎えた。

入門書として悪くはないと思うが、いかんせん「アジャイルサムライ―達人開発者への道」というぶっちぎりの良書が存在してしまっているので、相対的にあまり高い評価は与えられない。

入門を終えた後に読むちょっとした事例集として、読んでも良いかな、という程度。☆３つ。