平鍋健児のレビュー一覧
-
Posted by ブクログ
Scrum;
適応型ソリューション(adaptive solutions)をチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載された。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum」として紹介した。
スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており、スクラムの改良に伴ってこのガイドも更新されている。(Wikipedia)
Agile;
アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development)は「アジャイルソフトウェア開発」という概念を提唱した文書である。
2001年に、軽量ソフトウェア開発手法（と当時呼ばれてた）分野で名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法が共有する価値観を議論した。彼らはその結果を 「アジャイルソフトウェア開発宣言」という文書にまとめた。アジャイルソフトウェア開発宣言はアジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている。
この宣言は以下の4つの価値観を示し、これらの価値観を有するソフトウェア開発を「アジャイルソフトウェア開発」と名付けた。
・プロセスやツールよりも個人と対話を
Individuals and interactions over processes and tools
・包括的なドキュメントよりも動くソフトウェアを
Working software over comprehensive documentation
・契約交渉よりも顧客との協調を
Customer collaboration over contract negotiation
・計画に従うことよりも変化への対応を
Responding to change over following a plan
(Wikipedia) -
Posted by ブクログ
アジャイル開発とスクラム
企業内でもアジャイル開発が広まって来たと思う一方で、まだまだウォータフォール開発がなくならない現実。
アジャイル開発を知識創造型と呼びますが、人との繋がりによって臨機応変に動くことで、より良い、より市場に特化した製品やサービスを生み出す。
私達と顧客と見ることで、一体感を生み出す。
ソフト開発に限らず、ビジネスやマーケティングなどでもスクラムは取り入れられてきた。アメリカの海兵隊の陸海空が連動して動くシステムもまた、然りとのこと。
よりコミュニケーションを必要とすると考えれば、必ずしも万人に、良いものとは思えない。コミュニケーション高荷になりかねないのでは。
それでも、情が先にくるかっての日本企業が当時、この方法を取り入れることができたら、日本の歴史も少しは変わっていたかもしれませんね。 -
-
Posted by ブクログ
従来の開発手法ではビジネスの変化に対応できなくなったため、アジャイルが広まった。ソフトウェア開発のみならず、組織経営やチーム運営にも多くの示唆が含まれている。
第1部ではアジャイルとスクラムの基本的な説明、第2部ではリクルート・楽天・富士通でのアジャイル事例紹介、第3部ではそれらを踏まえた考察、という3部構成になっている。
スクラムで決められている役割はこの3つ。プロダクトオーナー、開発チーム、スクラムマスター。スクラムマスターはプロジェクトファシリテーションに注力するサーバントリーダー。管理者たるマネジメントリーダーではない。コマンドコントロール型の組織から、自律化・自己組織化したチームへと変わる。
ーアジャイル宣言ー
プロセスやツールよりも個人との対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。
ー以下、メモー
自社の開発プロセスにアジャイルを取り入れることをイメージしながら読んでいた。べき論を言えば、自社の開発プロセスの課題に答える形での改善活動が望ましく、フレームワークを取り入れるだけでは現場が困窮するだけだろう。つらつら思いついたことを残しておく。
・アジャイル思想導入における障害とは？
・やっつけでアジャイル導入した場合と、課題展開を行った上での対策としてアジャイル導入する場合の違いとは？
・AI開発プロジェクトにおけるアジャイルとシステム開発プロジェクトの違いとは？
・メーカーでの導入事例とは？
・システム開発以外の領域でのアジャイルとは？
通常業務、プロジェクトに取り入れること。顧客体験を最大化するために顧客の言葉で書く。可視化共有化のために、紙ベースのアナログを活用する。
この一冊をとっかかりにアジャイルやリーンスタートアップを読み漁ろう。チームの開発、成長のスピードアップへの強い示唆がある。 -
Posted by ブクログ
著者の一人である野中郁次郎氏は、論文「The New New Product Development」の中で、「専門集団によって設計され、文書化されたナレッジが、次の工程の専門集団にに引き継がれ、これを繰り返して物を作っていく」プロセスに対して、当時、キャノン、ホンダなどが行っていた「色々な専門家が一体となり、自律的組織として物を作っていく」プロセスを、ラグビーに例えて、「スクラム」と呼んだ。このスクラムは、海を越え、アメリカでトップ・プログラマたちをインスパイアーした。そして、スクラムは、その名前のまま、ソフト開発プロセスの新ムーブメントとなり、故郷である日本に帰ってきた。
ソフト開発は、現在のものづくりのみならず、会社経営にも非常に重要な要素であることは明らかであるが、日本のビジネスパーソンは、あまりにもソフトウエア・リテラシーが低い。私は、それが日本産業の生産性の低さの原因ではないかと思っている（残念ながら、これはわが社にも言える。特にソフト開発部門マネージメントのソフト開発リテラシーの低さは、悲惨を超えて喜劇的だ）。本書は、そういった状況を打破し、ソフト開発の改善、改革とそれを基盤にした経営改革にすばらしいアイデアを披露してくれるすばらしい本である。 -
-
-
-
-
-
-
-
Posted by ブクログ
■従来手法の何が問題なのか？
・人の創造性を奪ってしまう
・文書によるコミュニケーションには限界がある
・悪いタイミング
・未来を読む水晶玉はない
・仕事が楽しくない
・部分最適化
■アジャイルを大規模化するフレームワーク
【共通する点】
１．既にうまくいったチームが２つ以上あること
２．大規模化する必要があること
・Nexus：最も純粋なスクラムの複数チーム拡張。あくまでソフトウェアのプロダクト開発に焦点がある。チーム間の依存関係を調整しながら、同期的に全体スプリントを回し、動くソフトウェアをデリバリーする。
・Scrum@Scale：単にソフトウェア開発手法としてのスクラムを拡張したものではなく、スクラムによる組織運営を主眼としたフレームワーク。会社全体がすばやい意思決定と顧客指向の組織に変わること、そして、優れたプロダクトやサービスを市場に出していくことの両方を指向している。また、マーケティングチームや人事チームなど、これまでアジャイルが対象としてこなかったチームにも、スクラムを適用する。よって、導入には会社の方針が必要となる。EATを採用するには、エグゼクティブレベルの意思決定が必要になる。
・SAFe：プロダクト開発の方法論に留まらず組織運営や文化形成までを対象にしたフレームワーク。プロダクトを作る部分はもちろん、そこに至るまでの判断やワークフロー、チームを支える組織を対象とすることで、部分最適ではなく全体最適を目指している。
また、SAFeは大規模アジャイルフレームワークの中でもトップのシェアを誇っていて、世界中の多くの企業による導入事例がある。ScaledAgile,Inc.によって事業として運営されていることもあり、トレーニングや認定制度導入支援をしている企業や団体も多い。
SAFeの全体像を見ると複雑で難しく感じるかもしれないが、導入レベルに合わせた4つの構成、ロードマップ導入事例導入支援を受けられるという点が高いシェアにつながっている。
・LeSS：シンプルにスクラムを大規模開発に適応させたフレームワーク。チームを中心に、大規模に適応させるために必要なものだけを追加している。そのため、ある程度スクラムに慣れたチームや組織にとっては、すんなりと受け入れることができるであろう。
一方で、用意されたプロセスやルールを使って一気に導入したい場合には向かないかもしれない。プロダクトやプロダクトグループの成長に合わせて学習を繰り返し、フレームワークも成長させていく姿勢が求められる。
Nexusと共通点は多いが、詳細では違うところもある。スクラムの共同開発者の1人であるケン・シュエーバーが開発したNexusとは違うルートで、開発現場の大規模開発へのニーズに適応していったスクラムの形だといえる。
・Disciplined Agile：エンタープライズ対応に重きを置き、これまでアジャイルに含まれていなかった、「ガバナンス」「文書標準」「レビュー」「エスカレーション」「教育」「運用」「予算」「人事評価」などという言葉が出てくる。リアルな大企業でよく聞く言葉群だ。例えば、契約方法やリソースの戦略が「方向付け」フェーズの「予算確保」というゴールに登場する。
また、これまでチームベースのアジャイルがわざと避けてきた大域構造を示す言葉群、「アーキテクチャ」「フェーズ」を積極的に入れている。スコット・アンブラーの過去の仕事から、ラショナル・ユニファイド・プロセス(RUP)、アジャイル・モデリング(AM)、アジャイル・データ(AD)などの視点もしっかり入っており、集大成的なアジャイル百科事典ともいえるだろう。
PMIがこの手法を取得したことで、今後PMBOKと相乗した普及活動が活発になるだろう。
■事例：NTTコムウェア
【社内プロセスの変革】
そこで、これらの既存プロセスが抱える課題感例えばNTTコムウェアとしてウォーターフォール開発で積み上げてきた、統計データに基づく品質評価が、
・案件ごとに完成の定義が異なり、試験工程をまとめて取らないスクラムに適さない
・意思決定の会議体に必要となる、資料作成や事務処理、事前説明等が煩雑である
といった課題に対し、冒頭で出てきたアジャイル推進組織とともに、カイゼンに取り組んだ。
このプロセス改革においては、アジャイル開発の実践と同様、守破離のマインドで取り組んだ。実際にスクラムを行う中で、社内プロセスに対し理想論を押し付けず、既存のプロセスで取り組み、結果として見えた既存制度の課題点を、他組織を巻き込むことで社内プロセスの変革につなげたのである。
例えば品質評価のプロセスにおいては先述の通り、統計データに基づいたテスト消化曲線やパ発生曲線の収束を目指す従来型の評価方法が主流であった。しかし、開発の中で試験を同時に実施する私たちのチームでは時系列曲線を描くことができない上、「バグ」の定義も困難であった。
こういった課題に対し、定性的な評価として「プロダクトオーナーによる評価レポート」や、「品質コントロールのために行った施策の透明化」を用い、定量的な評価として「循環的複雑度」や「長期的に見たモジュールごとのコミット数」(コミット数が多い=リファクタリング頻度が高いモジュールは要注意)を用いる等、新たな品質評価の可能性を品質管理部門と連携して模索した。これら新たな指標値の出力に自動化を組み合わせることで意思決定プロセスの短縮化に挑戦した。
■「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい」 -
-
-
Posted by ブクログ
本書は、共著者に野中郁次郎が入っていることからもわかるように、システム開発に従事している人でなくても、経営視点でアジャイルとスクラムについて解説している。やや抽象的なところが多いが、この分野で初めて読むにはお薦め。しかし、米国で始まったスクラムが実は竹内・野中が日本の製造業でのイノベーションの手法として名付けた「スクラム」から来ているとは驚きであった。また、実際にスクラムを採用した、リクルート、楽天、富士通の方のインタビューも興味深かった。
・アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。
・アジャイル開発では、すばやくユーザーや顧客のフィードバックを得ることで、ムダな機能を作ることを防ぎ、市場投入のスピードを上げ、ビジネスの投資対効果を高める。
・ウォーターフォールの問題点
?人の創造性を奪ってしまう
?文書によるコミュニケーションには限界がある
?悪いタイミング
?未来を読む水晶玉はない
?仕事が楽しくない
?部分最適化
・アジャイル開発の現場がいかにアナログのコミュニケーションを重視しながら、チーム内の暗黙知を共有し、テストとコードという動くものによって品質を作っていくかがわかる。
・従来の発注・受注関係のままだと、開発チーム側は事業担当者から「何としてでもやってもらわないと困る」と言われても断ることができない。その結果、開発側は次回から検討や文書作成に慎重に時間をかけ、さらに安全のためのバッファを追加した見積もをすることになる。これが繰り返されると、そのバッファ分だけ納期は伸び、かつ開発効率も落ちていく。
・技術的負債とは、メンテナンスが難しいコードの増加が開発の足かせになることを借金（負債）になぞらえて表現したものだ。
・楽天開発部の方の言
「僕自身、そうしたボトルネックになるのは何としてもいやなので、そうならないためにもプログラムだって書ける、アジャイルなマネージャーを目指しているつもりです。まず自分が成長しないことには、チームが成長することはできないと思う。」
「テストが終わりじゃなくて、そこから次のステップに進んでいけるんです。だからこそ、リリースのときには、作った開発者自身に現場に入ってもらいました。」
・実践知リーダーシップに必要な六つの能力
?「善い」目的を作る能力
?「場」をタイムリーに作る能力
?ありのままの現実を直観する能力
?直観の本質を概念に変換する能力
?概念を実現する能力
?実践知を組織化する能力
・一つには、リーダーシップの形が変わる必要があるでしょう。対話と場作りを重視したプロジェクト運営、その場その場で共感を作り、高い視点の価値観で判断する実践知リーダーシップです。 -
-
-
-