<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Agile · 仁才徳</title>
    <link>https://jared.lynskey.co.nz/ja/tags/agile/</link>
    <description>ソフトウェアエンジニアリングと開発組織のリーダーシップについて。評価、採用とチームの拡大、CI/CD、DevOps モニタリング、エージェンティック AI。ソウルより。</description>
    <generator>Hugo</generator>
    <language>ja</language>
    <copyright>© 2026 仁才徳</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/ja/tags/agile/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>スクラムマスターとは？役割と、結果より「プロセス」を見るべき理由</title>
      <link>https://jared.lynskey.co.nz/ja/posts/2023/2023-10-16-outcome-indepedent/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/ja/posts/2023/2023-10-16-outcome-indepedent/</guid>
      <pubDate>Mon, 16 Oct 2023 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>Scrum</category>
      <category>Scrum Master</category>
      <category>Agile</category>
      <category>Retrospectives</category>
      <category>Team Management</category>
      <description>スクラムマスターの役割と責任をスクラムガイドに沿って整理し、プロジェクトマネージャーとの違いを比較。スプリントの結果ではなくプロセスに目を向けるべき理由を考えます。</description>
      <content:encoded><![CDATA[<p>先に結論から書きます。2020年版のスクラムガイドでは、スクラムマスターは「スクラムガイドで定義されたとおりにスクラムを確立すること」と「スクラムチームの有効性」に責任を持つとされています。具体的には、開発者、プロダクトオーナー、そして組織全体を支援する役割です。チームが自己管理できるようにコーチし、進捗を妨げる障害物の除去に働きかけ、スクラムイベントがきちんと開催され、生産的に、タイムボックス内で行われるようにする。逆に、作業を割り振ることや、チームに結果を催促することは、ガイドのどこにも書かれていません。この記事で書きたいのは、その違いの話です。</p>
<p>これまで参加した中で一番ひどかったレトロスペクティブは、どれも同じ形をしていました。スプリントゴールを外した結果、1時間まるごと「なぜ達成できなかったのか」の査問会になるパターンです。逆に一番良かった回は、ゴールの話がほとんど出ませんでした。どう働いたか、何が邪魔だったか、次に何を試すか。その違いこそが「結果に依存しないマインドセット」と呼ばれるものです。自分でもしばらくスプリントを回してきて、これはスクラムマスターにとって一番大事な姿勢だと思うようになりました。</p>
<p>念のため言っておくと、結果はもちろん大事です。立派なプロセスだけあって何もリリースしないチームに給料は出ません。ただ、スプリントを完了させるのはチームの仕事です。スクラムマスターの仕事は、スプリントを生み出す「機械」そのものを改善すること。この2つは別の仕事で、混同したところから、私が見てきたスクラムの機能不全の大半が始まっています。</p>

<h3 class="relative group">スクラムマスターとプロジェクトマネージャーの違い
    <div id="スクラムマスターとプロジェクトマネージャーの違い" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e3%82%b9%e3%82%af%e3%83%a9%e3%83%a0%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc%e3%81%a8%e3%83%97%e3%83%ad%e3%82%b8%e3%82%a7%e3%82%af%e3%83%88%e3%83%9e%e3%83%8d%e3%83%bc%e3%82%b8%e3%83%a3%e3%83%bc%e3%81%ae%e9%81%95%e3%81%84" aria-label="アンカー">#</a>
    </span>
    
</h3>
<p>この2つの役割はよく混同されます。一人に両方を任せる会社が多いのも一因です。主な違いはこうです。</p>
<table>
	<thead>
			<tr>
					<th></th>
					<th>スクラムマスター</th>
					<th>プロジェクトマネージャー</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>見るもの</td>
					<td>チームの仕事の進め方と、それがうまく機能しているか</td>
					<td>スコープ、スケジュール、予算</td>
			</tr>
			<tr>
					<td>作業を割り振るか</td>
					<td>割り振らない。開発者が自分たちで計画する</td>
					<td>割り振ることが多い</td>
			</tr>
			<tr>
					<td>成功の姿</td>
					<td>スプリントを重ねるごとに良くなっていくチーム</td>
					<td>期限内・予算内で完了したプロジェクト</td>
			</tr>
	</tbody>
</table>
<p>スクラムには、そもそもプロジェクトマネージャーという役割がありません。プロジェクトマネージャーが普段担う仕事の多くは、何をどの順番で作るかを決めるプロダクトオーナーと、それをどう作るかを計画する開発者に分かれています。</p>

<h3 class="relative group">結果への執着を手放すと何が変わるか
    <div id="結果への執着を手放すと何が変わるか" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e7%b5%90%e6%9e%9c%e3%81%b8%e3%81%ae%e5%9f%b7%e7%9d%80%e3%82%92%e6%89%8b%e6%94%be%e3%81%99%e3%81%a8%e4%bd%95%e3%81%8c%e5%a4%89%e3%82%8f%e3%82%8b%e3%81%8b" aria-label="アンカー">#</a>
    </span>
    
</h3>
<p>まず、チームが本当の意味でオーナーシップを持てるようになります。スクラムは自己組織化チームが前提のはずですが、結果に一喜一憂するスクラムマスターは、気づけば意思決定に手を突っ込んでいます。するとチームは「決めるのは自分たちじゃない」とすぐに学習します。プロセスに軸足を置けば、メンバーに実験させ、たまには間違った判断もさせて、そこから学んでもらえます。オーナーシップはそうやってしか育ちません。</p>
<p><a href="https://jared.lynskey.co.nz/ja/posts/2023/2023-09-01-retrospecs/" >レトロスペクティブ</a>も正直になります。部屋の問いが「なぜ数字を外したのか」だと、本当の答えは隠れてしまいます。「何が足を引っ張ったか、次は何を試すか」なら、みんな話してくれます。スプリント中の障害への対応も同じです。結果に執着するスクラムマスターは締め切りの心配でパニックになりますが、プロセスに集中している人は、淡々とブロッカーを取り除きにかかります。まだ誰もよくわかっていないことが障害になっているなら、タイムボックスを切った<a href="https://jared.lynskey.co.nz/ja/posts/2023/2023-10-18-spike/" >スパイク</a>を提案します。</p>
<p>ステークホルダーとの関係も落ち着きます。語れるストーリーがバーンダウンチャートだけだと、ちょっとしたブレがすべて失敗に見えます。チームが何を学び、どう適応してきたかも語れるなら、期待値はもっと現実的になりますし、スプリントの途中でチームに降ってくるはずだったプレッシャーの多くを、外で受け止められるようになります。</p>

<h3 class="relative group">すでに何かの結果に固執してしまっているなら
    <div id="すでに何かの結果に固執してしまっているなら" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e3%81%99%e3%81%a7%e3%81%ab%e4%bd%95%e3%81%8b%e3%81%ae%e7%b5%90%e6%9e%9c%e3%81%ab%e5%9b%ba%e5%9f%b7%e3%81%97%e3%81%a6%e3%81%97%e3%81%be%e3%81%a3%e3%81%a6%e3%81%84%e3%82%8b%e3%81%aa%e3%82%89" aria-label="アンカー">#</a>
    </span>
    
</h3>
<p>言うは易し、というのはわかります。特定の結果に深く入れ込んでいるときに「プロセスに集中しよう」と言われても、標語にしか聞こえません。</p>
<p>実際に効いたことをいくつか。まず、結果を気にする自分を責めないこと。何かを望むのは普通のことで、そうでないふりをしても続きません。次に、結果目標を自分でコントロールできるプロセス目標に翻訳すること。「大会で勝つ」ではなく「毎日30分練習する」。リリースがウケるかどうかは制御できませんが、レビューとテストを済ませて早めにデモしたかどうかは制御できます。それから、執着に燃料を与えているものに気づくこと。ダッシュボードや株価を1日に10回リロードしているなら、チェックする時間を決めて、それ以外は見ない。途中の小さな勝利もちゃんと祝ってください。放っておくと、遠くのゴールが注意力を全部食べてしまいます。もし固執のせいで眠れないとか日常生活に支障が出ているなら、専門家に相談する価値があります。恥ずかしいことでは全くありません。</p>
<p>結果は今でも大事です。ただ、結果を安定して出しているチームには、「何を」だけでなく「どうやって」の面倒を見ている人が必ずいました。</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2023/2023-10-16-outcome-indepedent/featured.jpeg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
