松元健のレビュー一覧

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

優れたスクラムマスターになるための方法をわかりすく書いてあるとても良い本でした。途中にあるエクササイズがとても勉強になりました。

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

実践ベースで書かれているのが何より良かった。具体的なプラクティスがいくつもありすぐに取り入れられるものも多かったです。事あるごとに見返したいと思う本でした！

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

さらっと読めるけど大事なエッセンスの詰まった良本。「スクラムとはマインドセット、文化、哲学であり、決まった手法のセットではありません」「新たなスクラムの理解・定義は「生き方」そのものです。」素敵な表現、まさにそのとおりだと思っている。スクラムマスター道（ScrumMasterWay）として、自チームがある程度軌道に乗ったとしても偉大なスクラムマスターへはまだ遠いことを教えてくれる。もっと色々やりたくなる！

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

本書のユニークな点として、gitの各種コマンドやgitを使ったブランチ戦略についてかなり丁寧に記述されていることが挙げられる。
アジャイル開発に取り組むチームの練度が上がりデプロイ頻度が上昇するとき、このブランチ戦略やテスト周りで問題が起こりやすい。その壁を乗り越えるためのヒントがあるというだけで、現場にとってどれだけありがたいことか。

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

最新のプラクティスの紹介がされている
初心者でもわかるように丁寧に説明されており、かつ高度な内容も取り扱っている

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

スクラムマスターっていまいちどんな責務なのかわからない、自分もかなり誤解してたけど、どういった視点をもってどう活動していけばよいかがわかった気がする。
自己組織化のゴールは、自分たちだけがうまくやっている状態ではなくて、それを越えてシステム全体として、全員がそれぞれの正しい部分を活かし会える状態なのかな。
あるときプロダクトオーナー、あるときは開発者として、一緒に障害を乗り越えつつも、別の視点での課題を提示する、POや開発者との兼務も可能だけど、兼務になると冷静な観察ができなくなったり、つい同情、甘えが出て現状に満足してしまうというのもわかる。
知識創造企業で野中郁次郎先生が指摘していた、ミドルマネジャー、ミドル・アップ・ダウンの概念がスクラムマスターなのかな。
薄くて挿絵も多いからサラッと読めるけど、実践するのはなかなか難しそう。
スクラムマスターになることはなくても、心のなかに自分を成長させるスクラムマスターを持ちたい。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

スクラムマスターとしてどう振る舞うべきか？責務は何か？どのようなチームを目指すのか？などが書かれていて良かった

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

具体的な開発現場の様子がマンガのストーリーになっていて、実際の現場を想像しやすい。まだ読み始めたばかりだが、良本と確信できる。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

SCRUM MASTER THE BOOK 優れたスクラムマスターになるための極意

「スクラムチームの母」と呼ばれ、著名なスクラムトレーナーであるZuzana Sochova氏の著書です。

スクラムマスターについて書かれた本は少なく、よいガイドになる貴重な本です。
スクラムマスターになりたい人だけでなく、リーダーをやっている人が身につけるとよいスキルがわかる内容になっていると思います。
日本語版付録として、スクラムの概要が説明されているのが親切です。

【本書で学べること・考えること】
- スクラムマスターの役割と責務
- 心理状態モデル（どのようなケースで何をやるか）
- #ScrumMasterWay（スクラムマスターの哲学）
- メタスキルとコンピタンス（収得すべきスキルや心構え）
- チームの構築方法（チームビルディングについて）
- 変化を起こすための方法
- 実際のスキルの使い方
- 実際にスクラムマスターとしての実践するには

読んでみての感想です。

「スクラムマスターとは？」という疑問に対し、役割や目的、必要なスキル、一般的な進め方のステップなどが体系的に説明されています。

スクラムマスターは、「開発チームが自己組織化することを推進し、責任を持って目標に向かって行動することを支援する」ことが役割であり、責務であると明確に定義されています。これはわかりやすいです。

スクラムマスターは、開発チームから一歩引いた視点で物事を観察し、以下のスキルを駆使して責務を全うすることがわかります。
- ティーチング
- 傾聴
- コーチング
- ファシリテーション
- 自己コントロール
- スクラムへの理解
- 専門知識 など

抽象的で具体的でないという意見もあると思いますが、具体的な内容はケースバイケースなので仕方がないと考えます。
上記したスキルは、それぞれで本一冊になるテーマなので、それらを習得するにもコストがかかりますし、人の適性もあるかと思います。

それでも、何を学び、実践していけば良いかというガイドになりますし、収得するには実際にトレーニングを積む必要もあるということが理解できるので、全体像を体系的に理解するには有用だと思います。

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

アジャイルプラクティスを解説してるけど、それぞれのプラクティスがスタンダードな内容になっていて、普通の開発でも使える内容になってる

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

同僚たちと読書会をやって、おおよそ一年かけて読み終わった。

すごく抽象的な話が多く、読書会で脱線しながらわいわい話すにはちょうどよかった。
たまにパラパラと読み直すと良さそうな本。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

久しぶりにスクラムの本読んだ。クネビンとかアジャイルの車輪とか、最近の道具を知らなかったので、認識をちょっとアップデート。コンパクトにまとまってるけど、行間で考えさせられる。付録の「10分でスクラム」は無償公開されてると良いかなと思った。1人でやっつけ仕事が多いので、チームでも、スクラムマスターでもないけど、「透明性とコラボレーションを推進する」人ではあるので、頑張ってパクりたい。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

「スクラムマスター」に焦点を当てた、ありそうでなかった書籍。

スクラムマスターはリーダーだ、という言葉が何度か出てくるが、なるほどファシリテーションやコーチングなど、求められる行動はリーダーのそれと類似している。
状況に合わせマインドモデルを変え対応していくというのはSL理論に通じるものがある。

アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知

常松祐一 / 川口恭伸 / 松元健

　先に紹介した「アジャイルの『ライトウィング』と『レフトウィング』」では、ライトウィングを「高速に石橋を叩いて渡る」と表現しています(※1-2)。「動いているシステムを壊さずに、高速に、着実に、製品をインクリメント (※1-3) していく」 ことが、アジャイル開発で達成したい状態です。大きな変更を一度に実現しようとしても、うまくいかないことは読者のみなさんも経験からわかるのではないでしょうか。この制約を踏まえて達成したい状態を実現するには、プロダクトが変化することを受け入れ、その変化の過程で開発の生産性やプロダクトの品質が落ちないようにする必要があります。そのために重要なのが「早く気がつく」 「小さい単位で完成させる」「継続的に見直す」の3つであり、それぞれを具現化するために一つ一つのプラクティスを実践していきます。



関係者を集め、ゴールやスコープを揃える
関係者を揃える/ゴールを揃える/スコープを揃える
　多くの人が絡む作業をはじめる際は、最初の認識合わせが重要です。実装が完了し、テストを行い、デモを見せる段階になって初めて、作っていたものが期待と違うものになっていたとわかるのは誰もが避けたいことです。こうした事態を避けるには、関係者を早い段階から巻き込み、プロダクトに対して継続的にフィードバックを得られるようにすることが必要です。
　一方で、多くの関係者を集めればよいというわけでもありません。さまざまな立場からパラパラに要望や要求が突きつけられることで、開発は簡単に迷走し、せっかくの時間や人を浪費することになります。筆者はそのような現場をいくつも見てきました。
　多くの人が関わるプロジェクトで、円滑な進行をするために、認識合わせは以下の順に進めていくとよいでしょう(図5-1)。

1. 適切な関係者を揃える
　開発者と異なる立場や役割の人は、これから開発するプロダクトのゴールや要件について、異なる情報や期待を持っているかもしれません。関係者が全員揃う前の段階で、いろいろな決定を下してしまうと、手戻りが発生するリスクが大きくなります。関係者の範囲は広く多様です。開発中に直接やりとりする役割もあれば、開発が終わってから動き出す役割もあります。開発の成果物をユーザーとして利用する人や、開発に直接関与しなくとも、リソースや情報を提供してくれる人も関係者です。関係書をきちんと洗い出せていなかった結果、後から物言いがついて開発が遅延または失敗するというのは残念ながらよく聞く話です。将来的に関わる人々を含めて、プロダクト開発でやりとりする関係者はしっかり探しておきましょう。図5-2は適切な関係者を挙げた一例です。
　その人が関係者にあたるのかを見極めるためには、「今度こんな機能を開発するんですけど、関係や影響するところはありそうですか?」と尋ねてみましょう。話を急に振られたとしても、関係者であれば少し考えた後に、気づいた点を答えてくれるでしょう。短い質問であれば相手の時間をさほど取らないので、声をかけられて迷惑に感じる人は少ないはずです。後から関係者だったことが判明して手戻りが発生してしまうリスクを考えれば、早くに声をかけたほうがよい判断といえるでしょう。
　関係者に該当していても、当人が持っている興味には幅があります。単にプロダクトに興味がある人もいれば、自分の仕事に直接関係や影響がある人もいます。また開開に対してどの程度の権限や影響力を持っているのかも異なります。それぞれが持つ開発との関係性を整理するのは大変ですが、「興味の高低」と「権限/影響力の高低」 の2軸で関係者を分類するだけでも、気にかけるべきことや適したコミュニケーション手段が整理できます(図5-3)。
　筆者が調べた限りで最も古い出典は 「Strategies for Assessing and Managing Organizational Stakeholders」 5-1 です。その他にも、「ステークホルダー分類」 で調べると細部が異なるバリエーションがいくつか見つかります。

2. ゴールの認識を揃える
　関係者への声かけが終わったら、次はゴールの認識を揃えていきます。ここでいうゴールとは、関係者全員がプロダクトを通して実現したいことを指します。集まった関係者は「置かれている状況」「持っている前提知識」「解決したい課題」がそれぞれ異なっている状態です(図5-4)。まずはお互いの理解や考え方を話し、共有することから始めましょう。
　気をつけるべきなのは、プロダクトを通して最終的に何を実現したいのかをきちんと確認できているかどうかです。関係者の話を聞くことで、開発でやるべきことは明確になっていきます。しかし、やるべきことをすべて達成しても狙っていたゴールに辿り着かない場合があります。例えばECサイトで「ユーザーにまとめ買いを促したい」と考えた際、その理由は複数考えられます。他にも「一人当たりの売上を上げたい」「送料の負担を抑えたい」「定期購入を促したい」といった目標は異なる立場の人たちから出てくるであろうゴールです。まとめ買いを促すことが達成できても、プロダクトを通して実現したかったことが達成できていなければ意味がありません。ゴール認識を揃えておかなければ、開発する内容が適切かどうかを判断できません。関係書の話がゴール (What) ではなく、解決手段 (How) に向いているとこういった問題が起きやすくなります。また、成功の指標や基準は決まっていても解決手段がゴールに結びついていない、という場合もあります。先に揃えるべきはゴールであって、 解決の手段やスケジュール/スコープではありません。関係者から話を一通り聞き終わった後、その先に何を成し遂げたいのかを聞くようにしましょう。
　プロダクトとしての理想のゴールを話そうとすると、抽象的でフワッとしたものになりがちです。例えば「すべてのユーザーが満足してくれるストレスのない購入体験」はまさに理想のECですが、その実現手段はいろいろと考えられます。理想のゴールの手前にある「一人当たりの売上を10%上げたい」「送料の負担を10%抑えたい」「6ヶ月間の定期購入比率を5%上げたい」といった、具体的なゴールを1つ選んだほうが、やるべきことを明確にでき、続くスコープの議論が進めやすくなります。
　事業戦略や長期的な方向性についても、わかっている限りで話しておきましょう。事業の方向性はシステムの設計に大きな影響を与えます。将来の計画について話し合う中で、設計に影響する要素や懸念事項がちっとも議論されない場合、適切な設計が行えていない可能性が高いです。ただし、可能性の段階ですべての詳細を詰めることは困難であり、予想が外れることもあります。それでも、事業戦略や方向性についてあらかじめ話し合っておけば、実際にプロジェクトが進行してから問題が起きたとしても、議論の概略を元に対処できます。将来のプロジェクトの成功につながる大切なステップとして取り組みましょう。

3. スコープの認識を揃える
　関係者が集まり向かうべきゴールの認識が揃ったら、どの時期に何を達成したいのか、プロダクトに必要な機能やそのためのユーザーストーリーを洗い出し、開発するスコープの認識を揃えます(図5-5)。
　まずはやるべきことの洗い出しからです。考えていること、頭に思い浮かんだことはすべて共有しましょう。「これは担当外のことだから言わなくて大丈夫」と考えるのはよくありません。後になって実は必要だったと判明することがないよう、些細な事項でも検討する必要はないか確認しましょう。
　やるべき項目を洗い出したら、緊急度や重要度を考慮して優先順位をつけます。同じ順位の項目ができないように、順序を定めます。優先順位がないと「すべて緊急である」「すべて重要である」と判断されてしまったときに、最初のリリースに含めたいユーザーストーリーが大きく膨れてしまい、スコープを小さくする議論ができなくなります。こうなるとスコープが大きいためにリリースまでの期間が長くなり、短くリリースして学びを得ていくというアジャイル開発の目標から遠ざかってしまいます。一方で最初のリリースは単に早ければよいというわけでもなく、プロダクトに求められる当たり前の品質や必須の機能も考慮する必要があります。そのためスコープはよく話し合い、「必ずやる」項目以外に「できればやりたい」「余裕があればやりたい」といった濃淡をつけることが大切です。機能やユーザーストーリーが決まれば、 実現するためにどの程度の手間が必要になりそうか、作業の規模を見積もれるようになります。チームがイテレーションごとにどれくらいの量をこなせそうか、過去の実横から推定します。過去の実績を持っていない新しいチームの場合、一定の時間、実際に作業をしてみて、進捗を計ってみましょう。作業の規模は当初の想定や希望と離れているかもしれません。初回のリリース時期を優先するのであれば、スコープに含まれるユーザーストーリーを見直して減らす必要があります。スコープを見直すときに何を重視するのか意識できるようにしましょう。
　またスコープには、すべての機能やユーザーストーリーを含めるべきだと言われがちです。しかし、それはシステムが当たり前に使えるようになった未来を想像しているからこその認識でしょう。例えば最初はデータも少なく、検索や絞り込み機能は必要ないかもしれません。もしくはそもそも機能自体が必要ないこともあります。まず機能が必要となる前提条件を考え、開発側から関係者へ都度確認を取りましょう。スコープは少しでも小さく、明確なものに絞ることが重要です。スコープは適切な大きさに抑えられていても、ゴールの達成に寄与しないものが含まれているかもしれません。適切なスコープ設定は難しく、丁寧に議論を積み重ねる必要があります。どんなステップを経て達成していくか、順序の入れ替えが可能な箇所はどこになりそうか、 いつどんな協力が必要になりそうかなど、お互いが協力できるように納得がいくまで話し合いましょう。認識や考え方の差はすぐに埋まらないため、継続して議論していくことが必要です。



大きめの開発はDesign Docで目線を合わせる
Design Doc
「Design Doc」 とは開発を始める前に、開発の背景/目的/設計/代替案を整理するドキュメント手法です。ドキュメントを元に関係者と共有/議論することで、取り組みを明確化し、手戻りを減らすことを目的としています。Googleで取り組みが始まり、現在では多くの技術企業に取り入れられています。Design Docは設計書や仕様書というよりも議事録に近い位置づけで、何度も議論して修正しながら作り上げていくことを重視しています。この手法は、ソースコードを書き始める前のコードレビューのような役割も担っています。
　Design Doc は、開発するものを十分に検討/詳細化できますが、一方で忙しくても読み通せるぐらいの短さにまとめる必要があります。重要な事項を書くことに絞り、詳細なことは書きすぎないことが重要です。すべての開発で事前に用意する必要はありません。筆者は数ヶ月以上かかる開発、いくつか実現案が考えられる開発、技術的/ドメイン的に新規で不慣れな開発に取り組む際、1~2週間程度の時間をかけて用意しています。
　Design Doc の項目には規定はありませんが、そもそも「比較的形式ばらないドキュメント」という立ち位置です。項目が多ければよい、分量が書いてあればよいとするのではなく、自分たちの開発で何を明確に残しておかなければならないかを議論し、取捨選択してください。仕様書や設計書などのドキュメントでは記載される機会が少ない一方で、Design Doc では意味があるとされる項目に「目標でないこと」と 「代替案」があります。開発が長期化するとやることがぶれてきてしまいますが、はじめに目標としないことを明示しておくと、スコープが広がることを抑制できます。 また検討した際に考慮した代替案が記載してあると、開発時にどこまで考慮して意思決定したのかを推し量ることができ、意思決定の参考にも設計スキルの教育にも役立 ちます。
[Design Doc に含める項目]
・概要
・背景
・対象範囲
・目標
・目標でないこと
・解決策/技術アーキテクチャ
・システムコンテキスト図
・API
・データストレージ
・代替案
・マイルストーン
・懸念事項
・ログ
・セキュリティ
・オブザーバビリティ
・参考文献


"Four Keys Metrics”でチームのパフォーマンスを測る
Four Keys Metrics
　デリバリーのパフォーマンスを測るメトリクスとして「Four Keys Metrics」があります。これはGoogle Cloud の DevOps Research and Assessment チームが研究から導いたもので、「Accelerate State of DevOps Report」という毎年公開される調査レポート 6-5 や 『Lean と DevOps の科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』 66 で紹介されています。Four Keys Metrics の項目は次の4つです。
1. リードタイム: コードコミットから本番環境稼働までに要する時間
2. デプロイの頻度: 本番環境へのリリースの頻度
3.平均修復時間:本番環境で障害が復旧するのに要する時間の平均
4. 変更失敗率:リリースが原因で本番環境に障害が発生する割合

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

スクラムマスターの必要性やマインドセットなどスクラムマスターに関連する情報は見れたものの、具体的な実践方法というよりは抽象的なコンセプトの話でした。なので概要をざっくり理解したい人にはいいと思いますが、実践方法を知りたいという人には向いていない気がしました。
自分は追加で書籍を読むかセミナーに参加しようと思います。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

どれくらい具体的に書いてあるのかが理解できない。
この本を読んですぐにスクラムマスターできるの？
詳しくは自分たちのワークショップに参加してねと読める。
システム開発の具体的な手法というよりは概念的な解説な気がする...
コーチングやファシリテーションだってそれぞれ本を何冊も読まないといけないし講習も受けないとだめなのでは
だけど本物のスクラムマスターがいてくれたらプロジェクト運用スムーズな気がする、いっぱいいると良いのに...

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

ZuzanaSochova / 大友聡之 / 川口恭伸 / 細澤あゆみ / 松元健 / 山田悦朗 / 梶原成親 / 秋元利春 / 稲野和秀 / 中村知成

この本の独自性は、#ScrumMasterWayをまとめたことだろうか。
スクラムのプラクティスを把握してチームでスクラムを回しはじめたスクラムマスターに、自身のこの先を見つめるのに良い本。