メンバ－全員が主体的に提案しまくってくれるように成功体験と一緒に「失敗体験」も繰り返そう

メンバ－全員が主体的に 提案しまくってくれるように 成功体験と一緒に「失敗体験」も繰り返そう 2025/9/6 弥生株式会社 エンジニアリングマネージャー 小島優介

はじめに (1/2) プロダクトを継続開発する上で チームが「主体的に成長し続けること」は大切です しかし現実には「もっとメンバーに主体的に動いてほしい」 「誰も新しい試みを提案をしてくれない」と悩むことはないでしょうか 私はそうでした。 「もっと提案してほしい」… そう思いながら気づけば自分一人で進めてしまう日々 そんな私のチームが数年かけて メンバー全員が主体的に成長して、提案しまくるチーム へと変わることができました

はじめに (2/2) その大きな要因は、成功体験だけでなく「失敗体験」も積み重ねたことです その数年間で、私のチームは100件以上の 新しい技術・ツール・プラクティスを試しました そのうち半分は、うまくいかず、やめることになりました チームで失敗をたくさん経験し、「失敗しても大丈夫」という安心感が できたことで、新しい試みが提案されやすくなりました 本セッションでは、明日から現場で活用できるものを持ち帰っていただくために ・成功体験と失敗体験を繰り返して提案しまくるようになる方法 ・実際に効果があった、明日から実践できる多数のプラクティス を紹介します

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

当時(2019年)の私 名前：小島 優介 所属：デンソークリエイト(前職) 業務： BtoBの自社製品開発の プレイングマネージャー 社外活動： 社外での発表経験なし 社外での勉強会の参加経験なし 技術記事の投稿経験なし

当時(2019年)の私の開発チーム 1. 業務で教えてもらったことしか知らない 2. 技術記事の投稿も社外イベント参加も無し 3. 開発のやり方が古いまま(新しいものを試さない) 4. 自分のタスクの事しか考えない 中堅(私) 3年目 2年目 配属予定の新人 (プログラミング未経験で入社)

2025年：主体的に成長し続けるチーム 1. 毎年新人が入ってくるが、その新人も含めて全員が主体性を発揮して成長 毎月投稿、全員が社外イベントで発表 3. 毎月新しい技術・ツール・プラクティスを皆が提案 2. 全員が技術記事を 4. 各自が自分のタスクの事だけでなく チームのための意見を積極的に発言 開発の生産性も向上。詳細は以下の記事参照。 「1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開」 https://qiita.com/kojimadev/items/4b28f801863cf4e8f0da

• https://qiita.com/kojimadev/items/4b28f801863cf4e8f0da

私の2019年と2025年の比較 2019年 1. 社外での発表経験なし 2. 社外での勉強会の参加経験なし 3. 技術記事の投稿経験なし 2025年 1. Developers Summit 2020 KANSAI ベストスピーカー賞1位 Microsoft Build 2022 セッションのスピーカー 2. 複数のコミュニティや勉強会に参加し、自分でコミュニティを運営 3. Qiitaで20,000Contributions(200万PV以上) 月刊誌「Software Design」3年以上連載 円満退職の上で 転職も成功

• https://note.com/kojimadev/n/n76a551f67786

個人とチームを変革させた要因 変革の要因は、メンバーが思いついた活動や記事で読んだプラクティスなど とにかく色々やってみることで 成功体験と一緒に「失敗体験」も繰り返したこと

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

当時の私の悩み 当時の私(プレイングマネージャー)は自分のチームに対して 以下の課題を感じていた • • • • 「もっと提案してほしい」と思いながらも、気づけば自分一人で進めてしまう メンバーは言われたことはやるが、自分から新しいことを提案しない チームの改善は、自分が考えて実行するパターンが続いている もっとチームの生産性を上げないとプロダクトのロードマップは実現できない

間違っていた主体性を求めるアプローチ 当時までは、チームのメンバーに主体性を発揮してもらおうと 以下のような活動を行っていた • • • • 「もっと主体的に動いて欲しい」と言葉で伝える 1on1などで「何か提案がない？」と聞く 「失敗を恐れずチャレンジしよう」と励ます 「みんなで改善していこう」と呼びかける しかし、これだけでは変わらなかった

なぜメンバーは提案しないのか？ 正直な話、当時はその原因がわかっていなかった 本当の原因が分かったのはチームの改善がうまくいった後で、以下だと分かった 「5つの主原因」 1. 今のやり方を変える必要性を感じない(現状維持が安全という心理) 2. 忙しくて提案を考える時間がない(提案より開発が優先という価値観) 3. 何かを提案するほどの知識がない 4. 提案することで得られるメリットが見えない 5. 自分の提案でチームが失敗したらと考えると怖い

問題の本質：環境と仕組みの不備 それまでの「主体性を求めるアプローチ」は的外れな活動 • やり方を変える提案をする必要性の共有 • 継続的に提案できる仕組み • 提案による成功体験 問題は上記がない環境と仕組み 次の章で「5つの主原因」すべてに対して、どう解消したのか説明 （当時は正確な原因はわかっていなかったので ぶっちゃけ、すべての主原因を解消する活動になっていたのは偶然ですが）

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

皆でどうなりたいか議論 当時のチームが変わるために重要な事は 「今のやり方を変える必要性を感じない」 というチームの姿勢を変えること チーム全員でこれからどうなりたいかを議論 チームのメンバーから出てきた言葉 「世の中の良いプラクティスやツールを全然知らない」 「このままだと世の中から置いてかれそう」 「ずっと同じやり方はつまらない」 「かたっぱしから新しい技術・ツール・プラクティスを試してみるのは？」 「それは面白そう」「自分たちも成長できるし楽しそう」と乗り気に

新しいものを試す活動のスローガンを掲げる 世の中の技術 ツール プラクティス 積極的に試す 得た知見をアウトプット(発信) 社内/社外 いいね！でモチベーションアップ 「試す→アウトプット→いいね」の無限ループで成長できて楽しい この活動を「ハピネスチームビルディング」と名付ける 活動に名前を付けることは大切！ (この時点では誰も知らないスローガンだったが、何年も社内外に発信を続けることで 多くの人から共感されるものに変わり、チームのメンバーがそれを誇りに思うようになった)

実際にチームで試したプラクティスの例 新しいものを試す活動を開始した初年度(2019年度)に試したものの一例 • モブプログラミング • 分報 • 毎朝15分の勉強会 • インセプションデッキの作成 • ドメインビジョン声明文の作成 • DX Criteriaでの評価 • Lean Coffeeによる振り返り 「5つの主原因」の「今のやり方を変える必要性を感じない」を解消 →古いやり方のままでは世の中に置いていかれるという危機感を共有して 皆で取り組むぞという雰囲気に

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

インセプションデッキを作る アジャイル開発において「インセプションデッキ」というものを 関係者全員で作って共通認識をつくり出す(詳細はこちら) インセプションデッキの中に「トレードオフスライダー」というものがあり スコープ・予算・時間・品質のどれを優先するのかを決めておくことで プロジェクトが遅れた際に、何を犠牲にして何を達成するのかの判断に利用 スコープを 最優先する例

• https://www.agile-studio.jp/post/apm-inception-deck

新しいものを提案が優先という価値観を共有 トレードオフスライダーは「時間・予算・品質・スコープ以外に重要なこと」を 定義して、その優先順を決めることも可能 長期を見据えて、チームを継続成長させるため「新しいものを提案して試す」が 優先して活動すべき価値観であることをチームのメンバーで共有 「新しいものを提案して試す」 の優先度を皆で話し合って最大に

提案活動をする前提での開発計画 マネージャーは提案活動を行うことを前提にした開発計画を立てることが必要 プロジェクトの進捗遅れにより提案活動が省略されてしまうと 結局は開発が優先という価値観に戻ってしまう 以下が重要 • プロジェクトが遅れないようなマネジメント • 多少の遅れがあっても提案活動を継続して価値観をぶれさせない 「5つの主原因」の「忙しくて提案を考える時間がない」を解消 →皆で提案することがチームにとって重要という価値観に変えた

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

提案タイムの開催 各自が開発業務と平行して新しい試みを提案し続けるのは困難 特に開発経験の少ないメンバーは、提案するほどの知識がないのでハードル高い 「提案タイム」を毎月開催 全員で同じ時間に、新しい技術・ツール・プラクティスを探す(45分間) 知識がないなら、今、調べて知った情報で提案すればOK

探し方の具体例を提示 開発経験の少ないメンバーは、そもそも探し方がわからない どういう探し方をすればよいか、具体例も合わせて提示 • デブサミやスクラムフェスの発表資料で紹介されているプラクティスを提案 • 人気のライブラリを調べて、活用できそうなものを提案 • エディタ(Visual Studio)の有名な拡張機能を調べて提案 • アジャイルのプラクティスやふりかえりの中から、やってみたいものを提案 具体例を提示して45分間を与えることで、皆が提案ができるように （調べたけど提案できるネタが見つからないこともある その時は「そういうこともありますね」とあまり気にしない）

各自の提案を聞いて、次の日から試す 45分間で探した後に、提案内容がある人は チームで試してみたいものを5～10分で提案 面白そうとなったものは、次の日から試す 「5つの主原因」の「何かを提案するほどの知識がない」を解消 →今、調べて知った情報で提案すればOKという考えで提案

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

提案して良かったとなるために 「提案して良かった」と本人が実感できることが、次の提案につながる メンバーに提案してもらったツールやプラクティスで実際に成果が出ても 提案した本人に「成果が出て良かった」と 感じてもらわなければ成功体験にならない 感じてもらえるよう伝えることが重要

提案活動を始めたばかりの頃の話 朝会がマネージャーへの報告会になってしまっている問題に対して 新卒入社の新人が「朝会で1人1回は質問する」というルールを提案 (詳細こちら) 質問をきっかけに「タスクの進め方や優先度の見直し」が起きるようになり チームの成長と生産性アップに繋がった しかし、新人はそれが自分の成果だと気付いていなかった 「○○さんの提案したルールのおかげで、タスクの進め方や優先度の見直しが 起きて、生産性アップに繋がりました。ありがとうございます」 と伝えると、その新人はとても驚いて 表情がぱっと明るくなった

• https://note.com/kojimadev/n/n437dee901e86

感謝や称賛は提案文化を根付かせる 心理学でも、人は「自分の行動が他者に感謝される」ことで 自己効力感が高まり、次の行動意欲が強化されると言われる 感謝や称賛は単なるお礼ではなく チームに提案文化を根付かせる強力な仕掛け 実際に、前ページのエピソードにより その新人は「自分でもチームを良くできるんだ」と自信になり 他のメンバーも「自分も提案してみよう」と思える雰囲気が生まれた

チームで感謝を言語化して伝えることに取り組む 「小さな改善でも感謝を言語化して伝える」ことにチームとして取り組む • 新しく試したもので「便利になった」「効率が上がった」と思ったら それを必ず提案した人に伝える • チームのふりかえりでは、改善の効果を(できるだけ)客観的に言語化し、 提案者を名指しで称賛 本人が「成果が出た」と実感でき 提案するメリットがはっきりと感じられる

成功体験の積み重ねの波及効果 成功体験の積み重ねにより「主体的な行動で成果が出ると嬉しい」と感じる 提案タイム以外のチームの会議でも、意見や提案を積極的に発言する 主体的に行動することで楽しく仕事をしているメンバーが増える 他メンバーや新しく入ってくるメンバーもその刺激を受ける 最終的にチーム全員が主体性を発揮するようになる 「5つの主原因」の「提案することで得られるメリットが見えない」を解消 →小さな改善でも感謝・称賛を伝えることでメリットを感じてもらう

提案してもらうためのやり方 以下のプラクティスで「5つの主原因」を解消する 1. 新しいものを試す必要性を共有してスローガンを掲げる 2. インセプションデッキで提案が優先という価値観を共有 3. 知識がなくても提案できる提案タイムの開催 4. 感謝・称賛の機会を作り成功体験に 5. 失敗を称賛しながら繰り返す

とにかく試して実績作り チームの皆で大事にしたのは 思い付きでも効果見込みが低くても失敗してもいいので とにかく試してみるという価値観 最初の1年は、試した実績を積み重ねて 「新しいものを試す風土」を作る事を優先 効果が高いものは継続し効果が低いものはやめる とにかく試してみることが重要という価値観なので やめることになっても「ナイスチャレンジ」と称賛して 失敗を気にせず、どんどん試す

失敗から学びを得る リモートワークを始めたばかりの頃 Discord、NeWork、SpatialChatなどのツールを試してみたり Zoomの同じルームで常時接続してみたりなど、色々と試したが その多くは失敗でやめることになった 失敗したやり方やツールについて、理由を話し合うことによって なぜうまくいかなかったのか、何が必要だったのかを言語化できて 自分たちに合うやり方を理解できた 最終的にチームのメンバーが一番しっくりくるやり方に(詳しくはこちら) 失敗することで学びを得て、後の成功に繋がった

• https://qiita.com/kojimadev/items/c211207ede652c2abeb0

新しいものを試した件数の見える化 チームの価値観として重要なのは 失敗してもいいから新しいものを試すこと 失敗した件数も含めてどれだけたくさん 試すことができたのかを見える化 (件数) 1年間の試行件数の推移 35 30 25 件数が積み上がっていく様が見える事で 「今月もいろいろ試せましたね」 とチームの皆で喜び合って 成功/失敗にかかわらず 試したこと自体に達成感を得る 20 15 10 5 0 1月 2月 3月 4月 5月 6月 7月

半分くらい失敗しても気にしない 100件以上の新しい技術・ツール・プラクティスを試す 半分は失敗で、うまくいかず、やめることに 失敗しても提案は称賛されることなので気にしない たくさん失敗すると失敗に慣れて、チームが失敗を全般的に恐れなくなる 「5つの主原因」の「自分の提案でチームが失敗したらと考えると怖い」を解消 →失敗しても提案自体を称賛する価値観を共有する

提案してもらうためのやり方 － まとめ 「5つの主原因」に対して、以下の方針で解消した 1. 2. 3. 4. 5. 今のやり方を変える必要性を感じない → 古いやり方のままでは世の中に置いていかれるという危機感を共有 忙しくて提案を考える時間がない → 皆で提案することがチームにとって重要という価値観に変える 何かを提案するほどの知識がない → 今、調べて知った情報で提案すればOK 提案することで得られるメリットが見えない → 小さな改善でも感謝・称賛を伝えることでメリットを感じてもらう 自分の提案でチームが失敗したらと考えると怖い → 失敗体験を繰り返すことで失敗に慣れる

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

変化し続けることの大切さ ここまでに新しい試みを提案してもらうやり方を説明しましたが なぜそこまでして、チームのやり方を変え続けることが大切なのか もう一押し、この章で説明させてください

マンネリ化したことありませんか？ 例① 朝会の時間に5～10分の雑談をするチームはよくある 雑談のプラクティスを始めたばかりの頃は すごく盛り上がって、各自の価値観が共有できて、とても良かった 長く続けていると、始めた頃と比べて効果が減衰してこないか？（私はある） 例② チームで定期的に行う「ふりかえり」で新しいやり方を試した時、 それまでにない観点での革新的な意見が出て良かった 長く続けていると、変えたばかりの頃ほどの効果にならなくないか？（私はある）

状況の変化により、最適なやり方が変わる もともと最適なやり方だったとしても チーム状況の変化やマンネリ化の度合いによって 最適でなくなる 期待通りの効果が出てないなら、やり方を変えた方が良い が、私はそれに気付かず続けていた

マンネリ化を検知して変える たとえば、ふりかえりで期待している効果が以下だと仮定 • • • • 何がうまくいったか・何がうまくいかなかったかを明確にして、 その学びを次に活かす 全員が主体的に考えを表明したり、互いの努力を認めたり、問題を共有し合う 課題を見つけて、それを解消する対策を立てる 前回とは違った観点での意見や課題を出そうと試みる 期待を下回っているのであれば、やり方を変えた方が良い 大切なのはマンネリ化を検知して、やり方を変えてみること 変えた結果、失敗することもある (私はたくさんある) 失敗しても気にせず、その失敗から学んで次のやり方を試しせばOK

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

生産性アップするプラクティス この最後の章では、本セッションを聞いて何かを変えてみよう！ となった時のために、私のチームで今までやったプラクティスの中で 生産性アップにつながりやすいイチオシのプラクティスを紹介 それは「メンバーの活動をめちゃくちゃ透明化する」 以下の3ステップで説明 1. 朝会での目標宣言 2. タスク着手時に進め方を検討して明文化 3. 日中は分報で開発状況を実況

1. 朝会での目標宣言 － やり方 • 朝会で各自が今日の目標を宣言して Slack に投稿 • デイリースクラムで「今日やること」を報告することに近いが ポイントは「どこまで進めるつもりなのか」をしっかり宣言すること • 帰る前に目標に対する実績を Slack で報告する 目標宣言用スレッドに 各自が朝会の開始までに 目標を投稿した時の例 メンバーA(memberA)

1. 朝会での目標宣言 － メリット • • • • 目標を宣言して達成を目指すことによるパフォーマンス向上(目標設定理論) 目標達成すると、達成感が得られる 他メンバーから助言(認識相違がないか)を教えてもらいやすい 全員がチーム全体の進捗をより強く共有できる 帰る前に目標に対する実績を Slack で報告する時の例 達成すると皆が祝ってくれて 達成感も増加 メンバー A(memberA) メンバーA(member)

2. タスク着手時に進め方を検討して明文化 タスク着手時に、そのタスクのレビュアーと一緒に 「どう進めるか」を決めて、タスクのチケット(Jiraなど)に書き残す メリットは以下 • タスクの進め方を熟練者と事前に相談しないことで 非効率な進め方になってしまうことを回避 • 途中段階でのレビューや相談するポイントを事前に決めておくことで 成果をすべて作り切ってからレビューすることによる大きな手戻りを回避 • タスクの進め方が透明化されることで、他のメンバ－からのフィードバック も受けやすくなる(先にこっちをやるとか、ここはペアプロした方が良いとか)

3. 日中は分報で開発状況を実況 作業中は、自分の分報チャンネルで 「いま何の作業を進めているか」「どう進めているか」を実況しながら進める 各自の作業状況が透明化されることで、他メンバーの助言により 早く課題が解消される(分報のやり方の詳細はこちら) 各自の状況を実況することで 助言し合うなどの コラボレーションが促進

• https://note.com/kojimadev/n/n1a9f5364c630

なぜ透明化が生産性アップになるのか スクラムガイドに経験主義の三本柱として「透明性・検査・適応」がある 透明性を高める → 検査（フィードバック）ができる → 適応（改善）が進む の改善サイクルを回すことが基本 心理学の観点でも、以下の効果 • 目標を公開することで行動が促進される • 進捗を記録・報告することで達成率が上がる

実際に数年間やってみたが、改善が効率的になる たとえば、あるメンバーの担当タスクに想定以上の時間がかかった場合の分析 メンバーの透明性がなければ、どういう進め方をしたのか曖昧になりやすい そのタスクの中のどこに時間がかかったのかも分からない 本章での透明化のプラクティスをやっていれば すべて分かるため分析が容易 • 進め方はレビュアーと相談してチケットに記載済み • 何の作業にどれだけかかったのかは、分報を見れば分かる

透明化することでコラボレーションの機会が増加 朝会での各自の目標宣言を聞いた時 他メンバーが違和感(思ったより遅過ぎもしくは早過ぎ)があれば 「これってXXXをやる想定でしたが認識合ってますかね？」などを質問 余分な事までやろうとしていたり、一部の作業を飛ばそうとしていたりを 事前に解消するなど 生産性アップに繋がるフィードバックが得られる

Agenda  かつての私と今の私  提案しない主原因の分析  提案してもらうためのやり方  変化し続けることの大切さ  生産性アップするプラクティス  最後に

転職先のチームでも 転職先のチーム(まだ入社3ヶ月)も 新しいやり方を試してみようという雰囲気になりつつある ある時、このままではリリースに間に合わず、2週間以上も遅れてしまう そういうピンチのときこそチームが変わるチャンス 「みんなで生産性を上げるために改善案をいろいろ出して試してましょう」 と提案し、透明化のプラクティスのいくつかも試してみた その結果、生産性が1.5倍くらいアップして遅れを挽回 つまり透明化のプラクティスは、少なくとも私の前職と現職では有効だった

最後に 本セッションの内容をより深く理解してもらうために Qiita で記事を以下のタイトルで公開中です メンバ－全員が主体的に提案しまくってくれるように成功体験と一緒に「失敗体験」も繰り返そう https://qiita.com/kojimadev/items/ce9ec36704b58961be5b 本セッションの内容を 明日からのチーム改善の参考にしていただければ幸いです

• https://qiita.com/kojimadev/items/ce9ec36704b58961be5b