シェア
はてブ
記事AI要約 アジャイルはエンジニアリングマネージャー（EM）の強力な武器になる——本対談では、共にマネージャーとアジャイル実践者の顔を持つ天野氏と粕谷氏が、その相乗効果を掘り下げます。両氏はスクラムマスター経験がマネジメントに活きる実例として、コーチングスキルやチーム観察力、検査と適応のサイクル運営などを挙げ、これらが1on1や戦略立案、組織運営に直結すると論じています。さらに機能別組織やマトリクス組織など様々な環境下でのアジャイル実践方法を示し、「現代のソフトウェア開発においてアジャイルの知識なしにマネジメントすることはもはや不可能」と断言。最後に、コミュニティ参加や小さな実験から始める具体的アプローチを提示し、マネージャー自身がアジャイルを実践することが組織変革の推進力になると結論づけています。
今回のスクラムマスター往復書簡では、「アジャイルはエンジニアリングマネージャー（EM）にとっても大きな武器になる」というテーマで、株式会社はてなのエンジニアリングマネージャーで書籍『スクラムの拡張による組織づくり』の著者である粕谷大輔さん（通称：だいくしーさん）との対談をお届けします。
天野 祐介（あまの ゆうすけ）
（元）サイボウズのスクラムマスター・アジャイルコーチ。サバティカル休暇中。東京→仙台移住しました。スクラムフェス仙台実行委員会。すくすくスクラム仙台運営。一歩立ち止まって、今後の生き方を模索中です。
note：スクラムマスターの頭の中
粕谷 大輔（かすや だいすけ、だいくしー）
2001年に大学卒業後、SI、ソーシャルゲーム開発を経て、2014年にはてなに入社。アプリケーションエンジニアとして、サーバー監視サービス Mackerelの開発に携わり、2017年1月より同チームのディレクターに就任。Mackerelの200週連続新機能リリースを牽引した。また、社内のスクラムマスターを集めた「すくすく開発会」という枠組みを立ち上げ、会社全体の開発プロセスの改善に取り組んだ。2021年5月よりChatwork株式会社（現:株式会社kubell）。その後2024年5月から再び株式会社はてなに。著書として『スクラムの拡張による組織づくり』（技術評論社）
私とだいくしーさんはどちらもマネージャーとアジャイル実践者という2つの顔を持っています。この共通点を活かし、「アジャイルはEMにとっても大きな武器になる」というテーマを掘り下げていきます。前回の連載記事では、アジャイルコミュニティに参加することで得られる学びが組織運営において極めて実践的であることを述べました。今回はその視点をさらに発展させ、マネジメントとアジャイルの融合がもたらす具体的な価値と実践方法に焦点を当てたいと思います。
From: 粕谷
こんにちは。今回はお声がけどうもありがとうございます。
簡単に自己紹介をさせていただきますが、株式会社はてなでエンジニアリングマネージャーをしているだいくしーです。
はてなには、技術グループという専門職グループがあり、ここには100名ほどになる、はてなのエンジニア全員が所属しています。はてなのエンジニアは、この技術グループと、はてなブログや、マンガアプリなどのプロダクト開発を担当するチームと両方に所属することになっています。いわゆるマトリクス型の組織です。
私は、この技術グループ全体を管掌するマネージャーとなります。
スクラムマスターの経験は、マネージャーとしての土台になる
From: 天野
だいくしーさん、ありがとうございます。まずは私自身のマネージャー経験から少しお話ししたいと思います。
私がマネージャーになったのは2022年、サイボウズでスクラムマスターが職能として確立されたタイミングでした。それまで約6年間、スクラムマスターとして複数のチーム・組織を支援してきましたが、自分がマネジメントの道に進むとは思ってもいませんでした。
というのも、私は長らく「自分はマネジメントには向いていない」と思い込んでいたんです（笑）。プレイヤーとして技術や実践を深めることは好きでしたが、「人をマネジメントする」ということに対しては苦手意識がありました。だから、キャリアの選択肢としてマネジメントの道は意識的に避けていたんですよね。
ところが実際にマネージャーとして働き始めてみると、これまでスクラムマスターやアジャイルコーチとして培ってきたスキルが、思いのほか活躍することに気づきました。特に印象的だったのは日常的に行う1on1での対話です。
スクラムマスターとして学んできたコーチングのスキル——傾聴、認知、拡大質問、リクエスト——これらが1on1の場でそのまま活かせることに、ある種の驚きを感じました。逆に考えると、こういったスキルトレーニングを積み重ねてこなかった人がいきなりマネージャーになって1on1を始めるのは、かなり難しいんじゃないかと思います。「あなたの目標は？」「今抱えている課題は？」と質問しても、その先の対話をうまく展開できなければ、形式的な面談で終わってしまうでしょう。1on1では「話題がないのでスキップします」といったやり取りがよく見られます。これは、効果的な1on1ができていないことの表れだと思います。
だいくしーさんは、エンジニアからマネジャーへのキャリアチェンジを経験されていますが、アジャイルの経験がマネジメントにどのように役立ったと感じていますか？
From: 粕谷
はてなに入社する前の2012年に、当時働いていたモバイルゲームを開発するチームではじめて実際にアジャイル開発を経験しました。そのチームはXPを実践しているチームでした。それ以来、アジャイルについて熱心に勉強し、コミュニティとも接点を持つようになりました。
その後、はてなに入社しましたが、最初はアプリケーションエンジニアとして働きました。はてなで私が所属したチームでは、私の入社前からスクラムを使っていて、今のCTOである大坪（id:motemen）がスクラムマスターをやっていました。
そのチームでエンジニアとしてコードを書きながら、もともとのアジャイル開発への興味もあって、チームのプロセス改善などに目配せをしていました。
その後、異動などでチームの体制が変わる際に、普段のふるまいから自然とスクラムマスターを引き受けるようになりました。エンジニアとの兼務ではありましたが。
そして、チームに入って3年ほどが経ったころに、そういったアジャイルに立脚する活動を評価されて、チームのマネージャーに抜擢されました。つまり、アジャイルの経験がマネジメントに役立つという以前に、そもそもアジャイルの経験が自分がマネージャーになる理由のひとつになっていたといえます（笑）。
いざ、マネージャーになった自分は、当然マネジメントの勉強をしてきたわけではありません。ですが、ソフトウェア開発チームの成果を最大化する、というマネージャーへの期待を実現する手段と、アジャイル実践者として身につけたスキルや知識はそんなに離れていないと考えました。そもそも当時の自分に使える手札は、アジャイル開発の経験と知識のみでしたし。
たとえば、ピープルマネジメントについては、天野さんも書かれているとおりコーチングのスキルが役立ちます。
マネージャーとしてチームの状態を探るのも、スクラムマスターがやる「観察」とよく似ています。この「観察」とチームへの直接的な「干渉」のバランスもスクラムマスターとしての経験に基づいて、少しマネージャーとしての立場であることを自覚しながらアレンジしました。スクラムマスターは、チームの自己管理化を促すために干渉はほどほどにするものですが、マネージャーとしてはもう少し「チームにこうしてほしい」という我を出してよいのではないか、といったアレンジです。
チームの方向性を指し示す際にも、インセプションデッキのようなツールを使って情報を整理してチームに伝える、というやり方が使えます。
マネージャーなんてやったことがない、という不安が無いわけではなかったですが、意外と必要なスキルはすでに自分に備わっていたと実感しました。
ただし、金勘定だけはあらためて勉強しなおす必要がありましたが（笑）。
こうして本格的にマネージャーとしての仕事に取り組むようになり、その後アジャイル以外のマネジメントの勉強もたくさんしましたが、このアジャイルの経験がマネジメントの仕事の引き出しのひとつとして使える、という感覚は今でも変わっていません。
検査と適応――アジャイルの実践知を活かす
From: 天野
アジャイルの実践がマネジメントへの道を開いた、というのは非常に興味深いポイントですね。特に印象的だったのは、「アジャイル実践者として身につけたスキルや知識は、マネージャーへの期待を実現する手段とそれほど離れていない」というご指摘です。この点をもう少し掘り下げてみたいと思います。
私がマネージャーとしての役割で、アジャイル実践者としての経験が特に強みになったと感じるのは、「検査と適応を繰り返しながら変化に対応し、戦略目標を実現する組織的なプロセスの実行をリードできた」ことです。今年のRSGT2025での登壇でも共有しましたが、組織の目標設定と定期的なフィードバック、ふりかえりのサイクルを回すプロセスの設計と実行は、スクラムマスターの経験が直接活きる領域だと感じました。特に、定期的なふりかえりと改善のサイクルを組織レベルに拡大することで、チームの成果とエンゲージメントの両方を高められることを実感しています。
この背景には、リーダーシップのあり方が大きく変化していることが挙げられます。かつての「指示命令型」から、メンバーの力を引き出す「サーバントリーダーシップ」へと、組織におけるリーダーシップの求められる形が変わってきています。Googleがマネージャーの研究で明らかにしたように、優れたマネージャーの第一の要件は「良いコーチである」こととされています。これはまさに、スクラムマスターに求められる資質と重なりますよね。
一方で、だいくしーさんが「金勘定だけはあらためて勉強しなおす必要がありました」と言及されたように、マネージャーならではの役割や責任も確かにあります。予算管理、人事評価、リソース配分、長期的な戦略立案など、スクラムマスターの経験だけでは補いきれない部分もあるでしょう。
そこで質問なのですが、だいくしーさんはアジャイルの経験を武器にしながら、マネジメントならではの役割や責任をどのように捉え、実践されているのでしょうか？
From: 粕谷
たとえば戦略立案やその実行などは、天野さんも書かれていますが、結局は検査と適応を繰り返しながら微調整をしていくことになりますし、組織の方向性を示すという観点だと、スクラムのプロダクトオーナーに必要なスキルセットを身に着けておくと、なんとなくできそうな気はしてきますね。
直接的にアジャイルのスキルを活用できそうにないマネージャーの仕事としては、人事評価、採用、予算管理などがあると思っています。
ですが、マインドセットというか、こういった未知の仕事への向き合い方に関しては、やはりアジャイルな考え方が充分役に立つと思います。不確実なものにどう対処するか、という考え方です。
ふりかえりをこまめにやり、検査と適応のサイクルを回し続ける、というのがその答えになります。まずは仮説をおいてやってみる。そして分析してふりかえる。自分はこれまで、採用活動で成果を出せたケースが多いのですが、まさにこのとおりにやった結果だと思っています。
たとえば、過去の採用実績から、1件内定承諾を得るまでの期間に、何人の候補者と面接をしたのかを調べる。その前段に何人とカジュアル面談をしたのか、カジュアル面談獲得までに送ったスカウト数は……などの数字を分析することで、成果を出すための自分の行動量についての予測ができます。予測ができれば、実際にやってみて、カジュアル面談から選考に進んでいただく件数を増やすためになにか工夫ができないかなどを都度ふりかえって考えます。この検査と適応をひたすら繰り返すことで、成果につながっていくわけです。
一方で、人事評価に関してはこの手は使えません。今回の人事評価は少し失敗でした、次は改善します、ということを言ってよい分野ではないからです。もちろん人事評価そのものが失敗に終わらない範囲であれば、ふりかえりによる改善はできますが、あまり大胆な仮説・検証はしづらい分野ですね。この場合は、頼る術を身につけるために徹底的にいろんな本を読み、先輩たちに話を聞いてインプットをたくさんしました。そしてそのインプットの内容を真似ながら、小さな検査・適応によって少しずつ自分なりのスタイルを見つけていく、という形だったかなと今にして思います。
天野さんがこのようなマネージャーならではの仕事をどう身につけたのかも気になるので教えてほしいです。
“マネージャーならではの仕事”との向き合い方
From: 天野
確かに、アジャイルの考え方はマネージャーの仕事を進める上でも大きく役に立ちました。特に検査と適応のプロセスを繰り返し不確実な問題に向き合う考え方は、自分にとって未知な「マネージャー」という仕事も何とかなりそうな感覚を持たせてくれました。
課題を見つけては仮説を立て、小さな一歩を踏み出し、結果を観察して学び、次の一手を考える。このサイクルを繰り返せば、どんな困難な状況でも少しずつ理想の状態に近づいていけるという確信があったからこそ、マネジメントという未知の領域への恐怖心が和らいだように思います。
一方で、「これはマネージャーならではの仕事だ」と改めて身につける必要があったものも確かにありました。特に次の2点が印象的です：
1. 評価フィードバック面談
だいくしーさんも言及されている通り、人事評価は「失敗しました、次は改善します」と軽々しく言えない領域です。1on1でのメンタリング・コーチングはこれまで多く経験しましたが、給与や昇進に関わる「評価」の要素が入ると途端に難しく感じました。幸いなことに、『エンジニアリングマネージャーのしごと』が発売された時期と重なり、同書の評価面談に関する章は何度も読み込んで参考にしました。
2. 組織のリソースを使った意思決定
スクラムマスターはチームを支援することが主な責任であり、直接物事を決めたり手を下す機会は多くありませんでした。一方マネージャーとしては、組織の限られたリソースをどう配分するか意思決定する責任があります。新規採用枠の確保や予算配分、チーム構成の決定など、組織全体の最適化を考慮しながら時に苦渋の決断を下す責任は、これまでにない重みを感じるものでした。
また、マネージャーに特有の「孤独感」の存在にも気づきました。メンバーには見せられない仕事が多く、「マネージャーは何をしているのか分からない」と言われることも珍しくありません。さらに、他のマネージャーも多忙を極めており、気軽に相談できる場も限られています。この問題意識から、私は四半期に1回程度、本部内のマネージャー数十名が集まって議論や相談をする1日を過ごす活動を企画・運営していました。このような場を運営する上で、コミュニティやカンファレンスの運営経験が非常に役に立ちました。この場を運営しながら、私自身も他のマネージャーから実践的な知見を多く学ばせてもらいました。
組織のリーダーシップを担うマネージャーにとって、アジャイルの実践知を活用できるシーンは多岐にわたります。私たちのように、アジャイルの実践経験からマネジメントへと移行するケースがある一方で、アジャイルのバックグラウンドを持たずにマネージャーになる方も多くいらっしゃいます。そのようなマネージャーは、アジャイルのどの部分から実践し始めるのが効果的だと思われますか？
From: 粕谷
マネージャーの「孤独感」はとても良くわかります。また、「マネージャーは何をしているのか分からない」問題は、自分自身がメンバー時代に上司に対して感じていたことなので、自分がマネージャーの仕事をはじめるにあたっての強い課題のひとつでもありました。
ここでもヒントになったのはアジャイルの知識でした。スクラムの３本柱に「透明性」「検査」「適応」というものがあります。スクラムマスターとして、チームに口酸っぱく透明性によりステークホルダーを含めたメンバー全員が共通理解を持つことが必要だ、と語ってきた経験から、マネージャーにもそれはあてはまるだろうと考えました。
なるべく自分の考えていることをグループウェアに書いたり、週報をみんなの見えるところに書いたりしました。ただ、マネージャーとしての業務が深くなるにつれ、あまりつまびらかにしすぎるのも良くないかもと考えるようになりました。たとえば、生煮えのアイデアをそのままみんなに公開しても、マネージャーとしての自分の影響力が大きいので、かえってメンバーを不安にさせてしまうこともあります。いまだにこの公開と非公開の塩梅がよくわからないです。個人的にはあらゆる物事をオープンにして仕事をするのが好みなのですが。
さて、アジャイルのバックグラウンドを持たないマネージャーがアジャイルをどう実践していくのが良いか。
まず、そういうマネージャーがアジャイルを改めて学ぶ必要があるかどうか、から考えてみたいと思います。私は必要である、と思います。
私と天野さんが今回のテーマとしている「マネージャー」は「エンジニアリングマネージャー」のことです。ソフトウェアプロダクトを開発する組織を管掌するわけですから、プロダクト開発についての知識は可能な限りたくさん備えておくべきで、アジャイル開発についての知識は、現代のソフトウェア開発においては必須知識です。プロジェクトマネジメントの知識体系のひとつであるPMBOKでも第7版以降でアジャイルのエッセンスがそれまで以上にたくさん取り入れられました。
エンジニアリングマネージャーのマネジメント領域は、先日開催されたEMConfでの広木大地さんの基調講演によると、以下の4領域となります。
- ピープルマネジメント
- プラットフォームマネジメント
- プロジェクトマネジメント
- プロダクトマネジメント
※プラットフォームマネジメントは従来、テクノロジーマネジメントと呼ばれていましたが、すべての頭文字をPで揃えるためにEMConfの基調講演の発表で呼び方が変わりました
アジャイルの知識は、これらのうちプロジェクトとプロダクトのマネジメントに必要なスキルです。天野さんと私のやりとりでは、さらに1on1などへの活用から、ピープルマネジメントにも有利なスキルであることがわかってきました。
技術的な要素を扱うプラットフォームマネジメントにおいても、現代の開発の現場ではアジャイルと関連の深いDevOpsの知識は必須です。
これらを見ていくと、アジャイルの知識を一切持たずにソフトウェア開発組織をマネジメントすることは、もはや不可能であると言い切ってしまってよいと思います。
では、どのようにしてマネージャーがアジャイルに関する知識を得ていけばよいか。
これは自分の経験ですが、まずは身近なコミュニティに顔を出すのが良いのではないでしょうか。たとえば、私は大阪に住んでいますが、アジャイルに興味を持ち始めたころから、スクラム道関西や、京都アジャイル勉強会といった地元のコミュニティに顔を出していました。
近くにコミュニティが見当たらない場合でも、コロナの渦中ほどではないですがDiscordサーバーなどのオンラインで活動しているコミュニティもありますし、まずはそういったところに顔を出してみて、そこに参加している人々が今どういう話題に興味を持っているのか。どんな書籍が流行っているのかなどをキャッチして、そこから学んでみるのが良いと思います。
認定スクラムマスター研修などの、研修を受講するのも良いと思います。そこに集まっている人や、講師の方と関係性を築くことができれば、そこからコミュニティの入口を探すこともできるでしょう。
天野さんの、アジャイルの学びへの入口はどのようなものでしたか？
アジャイルを学び、実践するための第一歩
From: 天野
「アジャイルの知識を一切持たずにソフトウェア開発組織をマネジメントすることは、もはや不可能である」というのは我々だから取れるポジショントークのようにも感じられますが、私も強く同意します。アジャイルとは不確実な状況に対処するための思考様式と言えますから、そのような知識やマインドセットはマネージャーがまず第一に備えるべきものです。必ずしもスクラムマスターやアジャイルコーチを何年以上経験すべきとは言えませんが、自組織が外部環境に対して十分な競争力を発揮できる敏捷性（アジリティ）を備えられる程度にはアジャイルの知識は必要でしょう。
私自身のアジャイルの学びへの入口は「書籍」でした。当時は組織の中に他にアジャイルを実践しているチームは存在せず、社外の人との繋がりもなく、自分に合うコミュニティをうまく見つけることができませんでした。必然的に自分の意思でアクセスできる情報源は書籍に集中し、本の虫と言えるほどアジャイルの関連書籍を読み漁っていました。100冊ほどは読んだでしょうか。その後はRSGTなどのカンファレンスに参加し、徐々にコミュニティに参加する機会も増えていきました。
アジャイルを学び始めて驚いたのは、その概念の関連する分野の広さと深さです。例えばスクラムの源流を辿れば野中・竹内先生の『The New New Product Development Game』を知り、『知識創造企業』や『ワイズカンパニー』に広がります。他にもリーンを辿ればトヨタ生産方式があり、チームへの理解を深めようと思えば心理的安全性の作り方やファシリテーションのようなソフトスキルから始まり、スケーリングアジャイルや組織論へと広がります。
アジャイルに関連づけられる分野の幅が広いので、何でも参考にできてしまうんですよね。だからアジャイルコミュニティに参加する人たちは、何事も面白がることのできる人が多いと感じます。学びに対するある種の無節操さがあるというか、とにかく学ぶことに対して貪欲だと思います。これは、マネージャーにとっても非常に大きな強みになります。
上記のような学びに対する姿勢を備え、実践的なアジャイルの知識を持つマネージャーになるためには、やはり実際にアジャイルチームで活動することが重要だと思います。現在すでにマネージャーであれば、マネジメント対象のチームのアジャイルへの挑戦をリードし、成功できるようサポートすることが何よりも学びになるのではないでしょうか。
とはいえ、機能別組織で特定の職能のピープルマネジメントを主に担当している場合などは、マネジメント対象の単位でアジャイルを実践するのもなかなか難しいでしょう。だいくしーさんは機能別の組織も含まれるマトリクス型の組織で働いておられますが、このような状況のマネージャーはどこから実践を始めるのが良いと思われますか？
From: 粕谷
アジャイルに関連付けられる分野の幅が広く、何でも参考にでき、何事も面白がる人が多いというのは同意ですね。コミュニティで教育心理学に関する本が流行っているかと思えば、野球監督の落合博満氏についての本が話題になるなど、幅が広いなと感じます。そして気になるので実際に読んでみると、たしかにめちゃくちゃ自分の仕事の参考書籍として刺さります（笑）。
マネジメント対象が具体的なチームではなく、アジャイルの実践が難しいケースは、実際私自身ももどかしく思うことがあります。
はてなには技術グループサブ会というものがあります。エンジニア全員が所属するマトリクス型の技術グループという職種別組織があり、その組織のサブ的な位置づけの会です。これは、たとえばフロントエンド技術や、セキュリティなど、特定の技術分野に関心のある人たちが集まり、週1回程度の定例会や、専用のグループチャットなどでの活動を通して、その専門性をプロダクト開発組織をまたいで共有したり、深めたりするための会です。このサブ会の1つに「すくすく開発会」というのがあるのですが、これは開発プロセスをより良くするために、アジャイル開発についての知識を中心に学び合うための会です。この「すくすく開発会」に参加して、いろいろなチームでの取り組みが共有されている様子を見ていると、スクラムマスターの血が騒ぐというか、ああ楽しそうだな、自分だったらこうやるのにな、とつい羨ましく感じてしまいます（笑）。
すこし話が逸れてしまいましたが、つまり私も具体的なチーム活動の中で自らが実践する機会というのはほとんど無くなってしまいました。
ただし、職種別組織の運用の中でも少ないながらも機会はあるので、そこで実践していくのが良いのではないでしょうか。たとえば、前職ではエンジニアリングマネージャー同士がチームを組んでスクラムのような活動をしていました。取り組みたい課題をプロダクトバックログアイテム的に扱い、毎週スプリントプランニングを実施するのです。たとえば、評価時期が近いからこのスプリントでは評価が実施できる状態をゴールとしよう。メンバーの評価シートを準備する。評価メンバーのスケジュールをカレンダー登録する。これらをこのスプリントの作業計画としよう。スプリントの最後にはレトロスペクティブを実施して、来週は評価がはじまっても大丈夫な状態になっているかを点検する。というような具合です。
すでに書いたとおり、採用活動での実践は、結果に対する不確実性がほどよく存在する分野なので、プランニング、レトロスペクティブ、改善の流れが作りやすいですね。
アジャイルに関する書籍を学んで得られた知識を、そういう身近な自分の業務でどう適用できるのかを考えるのが良いと思います。
ただしこういう実践は、そもそもの本丸であるプロダクト開発の現場での実践とはやはり違うので、マネージャーとして現場に対するナッジングやコーチングをするためには、現場での実践経験や成功体験が不可欠であるとは思いますから、難しいところですね。
最近は生成AIなどを使って、短い時間で個人開発もやりやすくなっていますから、実際に小さいソフトウェアを漸進的に作ってみる、というのもひょっとしたらおもしろいかもしれません。
From: 天野
ありがとうございます。だいくしーさんとの対話を通じて、マネージャーとしてアジャイルを実践する上で最も重要なのは「実際の経験を積むこと」だと改めて実感しました。マネージャーも #ScrumMasterWay でいうところの「レベル1：私のチーム」の段階をしっかりと経験することが、組織全体のアジャイル実践の質を左右し、優れたマネジメントの基盤になるのではないでしょうか。
私たちの対話から見えてきたのは、マネージャーとしてアジャイルの経験を積む方法はいくつもあるということです：
- マネジメント対象がチームの場合：そのチームのアジャイル実践を直接リードする。自らがプロダクトオーナーやスクラムマスターを兼任するか、メンバーの一人がその責任を担うようサポートし、チームと共に学び成長する。
- マネジメント対象が機能別組織の場合：だいくしーさんの例のように、採用活動や評価プロセスなど自分の業務にアジャイルの要素を取り入れる。あるいは、マネージャー同士でスクラムチームを組み、組織的な課題に取り組む。
- 小さな実験からスタートする：全体を変えようとするのではなく、自分の担当範囲で小さな実験を始める。週次ミーティングにふりかえりの要素を取り入れる、自分のタスク管理にカンバンを使ってみるなど、身近なところから変化を起こす。
- コミュニティとの接点を広げる：社外のアジャイルコミュニティやカンファレンスに参加し、他社の事例や知見を学ぶ。認定スクラムマスター研修などの公式トレーニングも効果的なスタート地点になる。
- 社内コミュニティを育てる：はてなの「すくすく開発会」のような社内コミュニティを作り、アジャイルに関心のあるメンバーと共に学び合う場を構築する。
本連載の第3回でぼのたけさんが次のように述べているように、「異なるリーダーシップを分担する」という考え方も、マネージャーにとって大きな学びになると思います。
つまりスクラムでは、主にタスク志向の行動を取るリーダーとしてプロダクトオーナーを、組織志向の行動を取るリーダーとしてスクラムマスターを別々に定義した、とも考えられます。
スクラムでは、プロダクトオーナー、スクラムマスター、開発者という3つの責任を通じて、ビジョン提示・意思決定、プロセス改善・チーム支援、自己組織化・専門性発揮といった異なるリーダーシップの側面が表現されています。これらを一人で担おうとするのではなく、チームや組織全体でどう分担し、補い合うかを考えることで、自分のリーダーシップスタイルを見直すきっかけにもなるでしょう。
マネージャーは、組織における直接的な権限と影響力を持つ存在です。マネージャー自身がアジャイルを深く理解し、率先して実践することで、組織全体を素晴らしい方向へと変革していく大きな推進力となります。本記事が、マネージャーの皆さんのアジャイル実践への第一歩を後押しし、日々の組織づくりのヒントになれば嬉しいです。皆さんの挑戦を心から応援しています。
