1. はじめに
プロダクトを継続開発する上で、チームが「主体的に成長し続けること」は大切です。
しかし現実には、「もっとメンバーに主体的に動いてほしい」「誰も新しい試みを提案をしてくれない」と悩むことはないでしょうか。
私はそうでした。
「もっと提案してほしい」・・・そう思いながら気づけば自分一人で進めてしまう日々。
そんな私のチームが数年かけて、メンバー全員が主体的に成長して、提案しまくるチームへと変わることができました。
その大きな要因は、成功体験だけでなく「失敗体験」も積み重ねたことです。
その数年間で、私のチームは100件以上の新しい技術・ツール・プラクティスを試しました。
そのうち半分は、うまくいかず、やめることになりました。
チームで失敗をたくさん経験し、「失敗しても大丈夫」という安心感ができたことで、新しい試みが提案されやすくなりました。
本稿では、明日から現場で活用できるものを持ち帰っていただくために以下を紹介します。
(長いので要点を知りたい人は太字のみお読みください)
- チームで成功体験と失敗体験を繰り返して提案しまくるようになる方法
- 実際に効果があった、明日から実践できる多数のプラクティス
本稿は、スクラムフェス三河2025での私の発表に興味を持ってくれた方々に、より深く理解してもらうために作成した記事です。また、発表資料も公開していますので、記事より発表スライドの方が理解しやすいという人はそちらを参照ください。
スクラムフェス三河での発表スライドはこちら
2. 課題だらけのチームとその数年後
2.1 かつて(2019年)の状況
冒頭の悩みをかかえていた頃(2019年)の私の開発チームを紹介します。
下図のメンバー構成でした。
チームには、以下の特徴がありました。
- 業務で教えてもらったことしか知らない
- 技術記事の投稿、社外勉強会への参加、いずれも経験なし
- 開発のやり方が古いまま(新しいことを試さない)
- 自分のタスクの事しか考えない
2.2 数年後(2025年)の状況
後述するプラクティスを実践し続けたことで、2025年は以下のような状態になっていました。
- 毎年新人が入ってくるが、その新人も含めて全員が主体性を発揮して成長
- 全員が技術記事を毎月投稿、全員が社外イベントで発表
- 毎月、新しい技術・ツール・プラクティスを皆が提案
- 各自が自分のタスクの事だけでなく、チームのための意見を積極的に発言
開発の生産性も向上。詳細は以下の記事参照。
1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
2.3 チームを変革させた要因
メンバーが思いついた活動や記事で読んだプラクティスなど、とにかく色々やってみることで、成功体験と一緒に「失敗体験」も繰り返したことが変革の要因でした。
以降で詳細を説明します。
3. 提案しない主原因の分析
3.1 当時(2019年)の私の悩み
当時の私(プレイングマネージャー)は、自分のチームに対して、以下の課題を感じていました。
- 「もっと提案してほしい」と思いながらも、気づけば自分一人で進めてしまう
- メンバーは言われたことはやるが、自分から新しいことを提案しない
- チームの改善は、自分が考えて実行するパターンが続いている
- もっとチームの生産性を上げないと、プロダクトのロードマップは実現できない
3.2 間違っていた主体性を求めるアプローチ
当時までは、チームのメンバーに主体性を発揮してもらおうと思って、以下のような活動を行っていました。
- 「もっと主体的に動いて欲しい」と言葉で伝える
- 1on1などで「何か提案がない？」と聞く
- 「失敗を恐れずチャレンジしよう」と励ます
- 「みんなで改善していこう」と呼びかける
しかし、これだけでは変わりませんでした。
3.3 なぜメンバーは提案しないのか？
これに関しては、正直な話、当時はその原因がわかっていませんでした。
本当の原因が分かったのは、チームの改善がうまくいった後でした。
そこで分かった「5つの主原因」を以下に記載します。
- 今のやり方を変える必要性を感じない(現状維持が安全という心理)
- 忙しくて提案を考える時間がない(提案を考えるより開発が優先という価値観)
- 何かを提案するほどの知識がない
- 提案することで得られるメリットが見えない
- 自分の提案でチームが失敗したらと考えると怖い
3.4 問題の本質：環境と仕組みの不備
つまり、それまでの「主体性を求めるアプローチ」は的外れな活動だったということです。
問題はメンバーの主体性が足りないことではなく、「やり方を変える提案をする必要性の共有」「継続的に提案できる仕組み」「提案による成功体験」がない環境と仕組みでした。
当時はここまで正確な原因はわかっていませんでしたが、この後に紹介する私のチームで実践した手法は、さきほど記載した「5つの主原因」をすべて解消する活動になっていました。
(すべての主原因を解消する活動になっていたのは偶然ですが) 問題を解消するメカニズムを伴っている手法なので、自信を持っておすすめできます。
次の章では「5つの主原因」に対して、それぞれどのように解消したのか、その詳細なやり方を説明します。
4. 提案してもらうためのやり方
4.1 新しいものを試す必要性を共有してスローガンを掲げる
当時のチームが変わるために重要な事は、「今のやり方を変える必要性を感じない」というチームの姿勢を変えることでした。
そこで、チーム全員でこれからどうなりたいかを議論しました。
議論の中でチームのメンバーから出てきた言葉の中には、
「世の中の良いプラクティスやツールを全然知らない」
「このままだと世の中から置いてかれそう」
「ずっと同じやり方はつまらない」
というものがありました。
それらの課題を解決する施策として「かたっぱしから新しい技術・ツール・プラクティスを試してみるのはどうだろう」という提案をすると、メンバーの皆が「それは面白そう」「自分たちも成長できるし楽しそう」と乗り気になってくれました。
具体的には、上図のように、世の中の新しい技術・ツール・プラクティスを積極的に試して、得た知見を社内や社外にアウトプット(技術記事を投稿)し、いいねをもらってモチベーションアップするという活動です。
「試す→アウトプット→いいね」の無限ループで成長できて楽しそうということで、この活動を「ハピネスチームビルディング」と名付けました。
活動に名前を付けるというのは大切です。
特に、その後に何年間も継続するつもりの活動であれば、自分たちが気に入る名前をつけた方が、前向きに取り組みやすくなります。
(実際、この時に名付けた「ハピネスチームビルディング」は、この時点では誰も知らないスローガンでしたが、何年間も社内外に発信を続けることで、多くの人から共感されるものに変わっていき、チームのメンバーがそれを誇りに思うようになりました)
実際にチームで初年度(2019年)に試したプラクティスの一例は以下です。
- モブプログラミング
- 分報
- 毎朝15分の勉強会
- インセプションデッキの作成
- ドメインビジョン声明文の作成
- DX Criteriaでの評価
- Lean Coffeeによる振り返り
<主原因の解消>
「5つの主原因」の1つである「今のやり方を変える必要性を感じない」に対して、古いやり方のままでは世の中に置いていかれるという危機感を共有して、皆で取り組むぞという雰囲気になりました。
4.2 インセプションデッキで提案が優先という価値観を共有
アジャイル開発のチームにおいては「インセプションデッキ」というものを関係者全員で作って、共通認識をつくり出すことは多いと思います(インセプションデッキの詳細はこちらを参照)。
そのインセプションデッキを作る上で、「トレードオフスライダー」というものがあります。
これは、時間・予算・品質・スコープのどれを優先するのかを決めておくことで、プロジェクトが遅れた際に、何を犠牲にして何を達成するのかを判断するために利用します。
そして、トレードオフスライダーには、「時間・予算・品質・スコープ以外に重要なこと」を定義して、その優先順を決めるということもできます。
ここで、「新しいものを提案して試す」という活動を定義し、その優先度を皆で話し合ってMAXにしました。
イメージが湧くように、以下に具体例を示します。
このように、トレードオフスライダーによって、長期を見据えてチームを継続成長させるための「新しいものを提案して試す」が優先して活動すべき価値観であることをチームのメンバーで共有しました。
<主原因の解消>
「5つの主原因」の1つである「忙しくて提案を考える時間がない(提案を考えるより開発が優先という価値観)」に対して、皆で提案することがチームにとって重要という価値観に変えました。
もちろん、マネージャーは提案活動によって生まれる勉強会などを行うことを前提にした開発計画を立てることが必要です。プロジェクトの進捗遅れにより提案活動が省略されてしまうと、結局は開発が優先という価値観に戻ってしまうため、プロジェクトが遅れないようにマネジメントします。また、多少の遅れがあっても提案活動を継続して価値観をぶれさせないことも必要です。
4.3 知識がなくても提案できる提案タイムの開催
「新しいものを提案して試す」という活動を皆でやろうと思っても、各メンバーが開発業務と並行して新しい技術・ツール・プラクティスを探して提案し続けるのは困難です。特に開発経験の少ないメンバーにとっては、提案するほどの知識がないので、高いハードルになります。
そこで月に1回、「提案タイム」というものを開催しました。
具体的には、全員で同じ時間に、新しい技術・ツール・プラクティスを探す時間を45分間設けます。
つまり、知識がないなら、今、調べて知った情報で提案すればOKという考え方です。
そのように時間が与えられたとしても、開発経験の少ないメンバーは、その探し方がわからないという問題があります。そこで、どういう探し方をすればよいか、具体例として以下の情報も合わせて提示しました。
- 有名なカンファレンス(デブサミやスクラムフェス)での発表資料を見て、そこで紹介されているプラクティスを提案する
- 使っているエディタ(Visual Studio)の有名な拡張機能を調べて、その中から活用できそうなものを提案する
- 使っている開発言語で、人気のライブラリを調べて、その中から活用できそうなものを提案する
- ふりかえりのやり方(KPT、YWT、Lean Coffee など)は色々あるので、やってみたいものを提案する
- アジャイル開発で有名なプラクティスは色々あるので、やってみたいものを提案する
例を提示して探す時間を確保することで、皆が提案できるようになりました。
場合によっては、調べたけど提案できるようなものが見つからないこともありましたが、その時は「そういうこともありますね」と、あまり気にしないスタンスとしました。
45分間で探した後に、提案内容がある人は、チームで試したいものを5～10分で提案します。
そこで面白そうとなったものは、次の日から試しました。
<主原因の解消>
「5つの主原因」の1つである「何かを提案するほどの知識がない」に対して、今、調べて知った情報で提案すればOKという考えで提案してもらえるようになりました。
4.4 感謝・称賛の機会を作り成功体験に
「提案して良かった」と本人が実感できることが、次の提案につながります。
ここで気をつけることは、メンバーに提案してもらったツールやプラクティスで実際に成果が出たとしても、提案した本人に「成果が出て良かった」と感じてもらわなければ成功体験にならないということです。
たとえば、新しいものを試みる提案活動を始めたばかりの頃、こんなことがありました。
朝会がマネージャーへの報告会になってしまっている問題に対して、チームに配属されたばかりの新卒入社の新人が「朝会で1人1回は質問する」というルールを提案したのです(詳細はこちら)。
それを試してみた結果、質問をきっかけに「タスクの進め方や優先度の見直し」がたびたび起きるようになり、チームの成長と生産性アップに繋がりました。
ただ、質問をきっかけに「タスクの進め方や優先度の見直し」が起きても、その新人はそれが自分の成果だと気付いていませんでした。
私が「○○さんの提案したルールのおかげで、タスクの進め方や優先度の見直しが起きて、生産性アップに繋がりました。ありがとうございます。」と伝えると、その新人はとても驚いて表情がぱっと明るくなったのを今でも覚えています。
この体験により、その新人は「自分でもチームを良くできるんだ」と自信になり、さらに他のメンバーも「自分も提案してみよう」と思える雰囲気が生まれました。
心理学の研究でも、人は「自分の行動が他者に感謝される」ことで自己効力感が高まり、次の行動意欲が強化されると言われています。
つまり、感謝や称賛は単なるお礼ではなく、チームに提案文化を根付かせる強力な仕掛けになるのです。
そこでチームとして取り組んだのは「小さな改善でも感謝を言語化して伝える」ことです。
新しく試したもので「便利になった」「効率が上がった」と思ったら、それを必ず提案した人に伝えるようにしました。
チームのふりかえりでは、改善の効果を(できるだけ)客観的に言語化し、提案者を名指しで称賛しました。
そうすることで、本人が「成果が出た」と実感でき、提案するメリットがはっきりと感じられるようになります。
この「小さな称賛の積み重ね」により、「主体的な行動で成果が出ると嬉しい」と感じるようになり、提案タイム以外のチームの会議でも、意見や提案がたくさん出るようになりました。
主体的に行動することで楽しく仕事をしているメンバーが増えてくると、他メンバーや新しく入ってくるメンバーもその刺激を受けて、最終的にはチーム全員が主体性を発揮してくれるようになりました。
<主原因の解消>
「5つの主原因」の1つである「提案することで得られるメリットが見えない」に対して、小さな改善でも感謝・称賛を伝えることでメリットを感じてもらうことができました。
4.5 失敗を称賛しながら繰り返す
チームの皆で大事にしていたのは、失敗してもいいからとにかく試してみる事が重要という価値観です。
だから、思い付きでも効果見込みが低そうなものであっても、とにかく皆で新しいものを試しました。
特に最初の1年くらいは、そうやって新しいものを試す実績を積み重ねて、チームに「新しい技術・ツール・プラクティスを試す風土」を作る事を優先しました。
そして試した結果、効果が高いものは継続しますが、効果が低いものはやめました。
とにかく試してみることが重要という価値観なので、やめることになっても「ナイスチャレンジでした」と称賛して、失敗を気にせず、どんどん試しました。
例えば、私のチームはリモートワークを始めたばかりの頃、様々なコミュニケーションのやり方を試してみました。Discord、NeWork、SpatialChatなどのツールを試してみたり、Zoomの同じルームで常時接続してみたりなど、色々と試してみましたが、その多くは失敗でやめることになりました。
いろいろ試して、失敗したやり方やツールについて、理由を話し合うことによって、なぜうまくいかなかったのか、どういう要素が必要だったのかを言語化できて、自分たちに合うやり方を理解することに繋がりました。
そして、最終的には、チームのメンバーが一番しっくりくるやり方になりました。
つまり、失敗することで学びを得て、後の成功に繋がったのです。
チームの価値観として重要なのは「失敗してもいいから新しいものを試すこと」なので、失敗した件数も含めてどれだけたくさん試すことができたのかを、下図のようにグラフで見える化しました。
グラフで件数が積み上がっていく様が見える事で、「今月もいろいろ試行できましたね」という感じにチームの皆で喜び合って、成功/失敗にかかわらず、試したこと自体に達成感を感じることができました。
数年間で私のチームは100件以上の新しい技術・ツール・プラクティスを試しました。
そのうち半分は、うまくいかず、やめることになりました。
失敗しても提案は称賛されることなので気にしませんでした。
たくさん失敗すると失敗に慣れて、チームが失敗を全般的に恐れなくなりました。
<主原因の解消>
「5つの主原因」の1つである「自分の提案でチームが失敗したらと考えると怖い」に対して、失敗しても提案自体を称賛する価値観を共有することで解消しました。
4.6 主原因の解消のまとめ
「5つの主原因」に対して、それぞれ以下のように解消しました。
- 今のやり方を変える必要性を感じない(現状維持が安全という心理)
→ 古いやり方のままでは世の中に置いていかれるという危機感を共有 - 忙しくて提案を考える時間がない(提案を考えるより開発が優先という価値観)
→ 皆で提案することがチームにとって重要という価値観に変える - 何かを提案するほどの知識がない
→ 今、調べて知った情報で提案すればOK - 提案することで得られるメリットが見えない
→ 小さな改善でも感謝・称賛を伝えることでメリットを感じてもらう - 自分の提案でチームが失敗したらと考えると怖い
→ 失敗しても提案自体を称賛する価値観を共有する
5. 変化し続けることの大切さ
なぜそこまでして、チームのやり方を変えることが大切なのか、もう一押し、説明させてください。
5.1 マンネリ化したことありませんか？
チームのマネジメントとして、様々な仕事のやり方を、変え続けることは必要だと思っています。
たとえば、よく聞く話として、朝会の時間に5～10分の雑談をするチームはあると思います。
その雑談のプラクティスを始めたばかりの頃は、すごく盛り上がって、各自の価値観が共有できて、とても良いプラクティスと感じたのに、長く続けていると、始めた頃と比べて効果が減衰してきたと感じることはないでしょうか？私はあります。
もう1つの例として、チームで定期的に行う「ふりかえり」のやり方として、新しい方法を試してみた結果、それまでにない観点での革新的な意見が出て良かったので、長く続けていたら、変えたばかりの頃ほどの良い効果が出にくくなってきたということはないでしょうか？私はあります。
それがマンネリ化です。
5.2 マンネリ化を検知して変える
もともと最適なやり方だったとしても、チーム状況の変化やマンネリ化の度合いによって、そのやり方が最適でなくなることはよくあります。
期待通りの効果が出ていないなら、やり方を変えた方が良いですが、過去の私は、それに気付かず続けていました。
たとえば、ふりかえりで期待している効果が以下だと仮定します。
- 何がうまくいったか・何がうまくいかなかったかを明確にして、その学びを次に活かす
- 全員が主体的に考えを表明したり、互いの努力を認めたり、問題を共有し合う
- 課題を見つけて、それを解消する対策を立てる
- 前回とは違った観点での意見や課題を出そうと試みる
その期待通りの効果が出ていれば、変えなくても問題ありません。
ただ、期待を下回っているのであれば、やり方を変えた方が良いでしょう。
大切なのは、マンネリ化を検知して、やり方を変えてみることです。
変えた結果、失敗することもあります(私はたくさんあります)。
でも、失敗しても気にせず、その失敗から学んで次のやり方を試してみれば良いのです。
なお、ふりかえりのやり方を変える方法については、以下の記事で公開していますので、よろしければ参照ください。
6. 生産性アップするプラクティス
ここまでで、チームが提案しまくるようになるやる方と変化し続ける大切さを説明しました。
この最後の章では、本稿を読んで何かを変えてみようとなった時のために、私のチームで今までやったプラクティスの中で、生産性アップにつながりやすいイチオシのプラクティスを紹介します。
端的に言うと、それは「メンバーの活動をめちゃくちゃ透明化する」というプラクティスです。
具体的なやり方を以降で説明します。
(チームのコミュニケーションツールがSlackの前提で書いていますがTeamsでも問題ありません)
6.1 朝会での目標宣言
朝会で各自が「何のタスクをどこまでやるか」、今日の目標を宣言して Slack に投稿します。
これはデイリースクラムで「今日やること」を報告することに近いですが、ポイントは「どこまで進めるつもりなのか」という目標をしっかり宣言することです。
そして、各自が帰宅する前に、朝に宣言した目標に対して「どこまで進んだか」をSlackに書き込みます。
上図は、目標宣言用スレッドに各自が朝会の開始前までに目標を投稿した時の例です。
これを行うことで、以下の効果があります。
- 目標を宣言して達成を目指すことによるパフォーマンス向上(目標設定理論)
- 目標達成すると、達成感が得られる
- 他メンバーから助言(認識相違がないか)を教えてもらいやすい
- 全員がチーム全体の進捗をより強く共有できる
目標が達成できた時は、下図のようにチームの皆から称賛スタンプが付いて、達成感も増加します。
これは進捗の透明化だけでなく、自分自身のふりかえりにもなります。
6.2 タスク着手時に進め方を検討して明文化
新しいタスクに取りかかるとき、そのタスクのレビュアーを事前に決めておいた上で、その人と一緒に「どう進めるか」をあらかじめ決め、それをそのタスクのチケット(Jiraなど)に書き残します。
開発経験の少ないメンバーによくある話として、タスクの進め方を熟練者と事前に相談しないことで、非効率な進め方になってしまうことがあるため、それを回避できます。
また、成果をすべて作り切ってからレビューすることで、大きな手戻りが起きることもよくある話ですが、タスクの着手時に、進め方として途中段階でレビューや相談するポイントを決めておくことで、大きな手戻りを回避できます。
そして、どういう進め方をするのか透明化されることで、他のメンバ－からもフィードバックを受けやすくなります(先にこっちをやった方が良いとか、ここはペアプロした方が良いとか)。
6.3 日中は分報で開発状況を実況
作業中は、自分の分報チャンネルに「いま何の作業を進めているか」「どう進めているか」を実況しながら進めます。
各自の作業状況が透明化されることで、他メンバーの助言により、早く課題が解消されたりします。
分報のやり方の詳細は以下の記事を参照ください。
下図のように、各自の状況を実況することで助言し合うなどのメンバー間のコラボレーションが促進されます。
6.4 なぜ透明化が生産性アップになるのか
スクラムガイドに経験主義の三本柱として「透明性・検査・適応」があります。
つまりスクラムにおいては、透明性を高める → 検査（フィードバック）ができる → 適応（改善）が進む という改善サイクルを回すことが、基本になります。
さらに心理学の観点でも、以下の効果があります。
- 目標を公開することで行動が促進される
- 進捗を記録・報告することで達成率が上がる
メンバーの活動をめちゃくちゃ透明化することは「スクラムガイド」と「心理学的な行動科学」の両面から効果的とされているわけです。
そして、私のチームでは、この透明化のプラクティスを何年間も実施していました。
その状態になると、本当に改善サイクルが効率的です。
たとえば、あるメンバーが担当していたタスクが、思ったより時間がかかったとしましょう。
メンバーの透明性がなければ、そのタスクを、どういう進め方をしていたのか担当者しか分かりませんし、担当者がそのタスクでやる作業が5つあったとして、それぞれにどれだけ時間がかかったのかも分かりません。
しかし、このプラクティスで透明性を確保していれば、それがすべて分かります。
どういう進め方をしたのかは、レビュアーと集中検討してチケットに記載していますし、何の作業にどれくらいかかったのかは分報を見れば分かります。
その結果、時間のかかった要因がたとえば「最後にまとめてコンフリクト解消したこと」だったとすれば、コンフリクトが発生するブランチを特定して毎朝 Slack に通知してくれる CI を作成することで、小さなコンフリクトのうちに解消するという改善策を打てます。
その他にも、朝会での各自の目標宣言を聞いて、まわりのメンバーが違和感(思ったより遅過ぎもしくは早過ぎ)があれば、「これってXXXをやる想定でしたが認識合ってますかね？」などを質問します。
そうすると、余分な事までやろうとしていたり、一部の作業を飛ばそうとしていたりを事前に解消するなど、生産性アップに繋がるフィードバックが得られました。
このように、透明化することでフィードバックし合う機会が増加して改善に繋がります。
6.5 注意点
「透明化」は「監視」とは違います。
監視だと感じられてしまうと、生産性アップどころか、ストレスや不満を増やすリスクがあります。
透明化の目的は「みんなで助け合ったり、チームを改善するため」であり、監視や評価のために使うものではありません。
この前提をチームでしっかり合意しておくことが重要です。
7. 最後に
最近、転職しました。
そのため、紹介した2025年のチームというのは、厳密には前職のチームです。
そして今、転職して3ヶ月ですが、転職先のチームでも、新しいやり方を試してみようという雰囲気になりつつあります。
それは実際に、やり方を変えることで、成果が出たからです。
ある時、このままではリリースに間に合わず、2週間以上も遅れてしまうということが分かりました。
しかし、そういうピンチのときこそ、チームが変わるチャンスです。
その状況を打開するために「みんなで生産性を上げるために改善案をいろいろ出して試してましょう」と提案し、実際にいくつかの改善案を試してみました。
最後の章で説明した透明化のプラクティスのいくつかも採用しました。
その結果、生産性が1.5倍くらいになり、遅れを挽回しました。
このことから、透明化のプラクティスは、少なくとも私の前職と現職の2つの会社では有効だったと言えます。
ぜひ本稿の内容を、明日からのチーム改善の参考にしていただければ幸いです。
X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev