新規事業サービス化の検証で個人商店化したチームの失敗談
1. はじめに
こんにちは。Web系企業で開発業務を担当していますが、今年に入ってから新規事業をサービス化するための検証をスクラムに則って行っています。
紆余曲折あった末に４月頃からとあるサービスを展開するための検証を4人チームで行っていたのですが、書籍「チームジャーニー」でいうところの「チーム」ではなく「グループ」になってしまっていたなと反省することがありました。
今回の記事では自身の戒めも兼ねて、反省するまでに至った経緯を振り返り、どうすれば良かったのか考えをまとめたいと思います。
2. プロジェクトの背景
今年の４月からとあるサービスを事業化するための検証を4人チームで行うことになりました。ここでは、スクラムに則り以下のような体制としました。
- プロダクトオーナー：１名（自分）
- 開発担当：３名（内、１名はスクラムマスター兼務）
なぜこの体制にしたかというと、実は4人チームになる前に７名のチームで別のサービスの仮説を検証していた時期がありました。
その時は全員で１つの仮説を検証するということを行っており、尚且つ誰かがリーダーシップをとって意思決定するのではなく合議制でものごとを決めていたため、とにかく何かを決めるのに時間がかかるという課題がありました。
そのため、責務をきちんとわけ、その責務の範囲内で担当者がきちんと意思決定を行うことを目的としてプロダクトオーナー、開発担当という役割を明確に決めました。
3. 発生した問題と失敗の詳細
3-1. チームの「個人商店化」
上記の通り役割をきめ、プロダクトオーナーはサービスの方向性やプロジェクトの推進、開発担当はサービスを実現するための技術に対して責任を持つこととしました。
しかし、結果としてお互いの役割への関心が薄くなってしまっていました。
「新事業の可能性を探る」というチームとしての目標を達成するため、この段階では役割こそありはするものの、目標達成のための行動をとるべきです。
しかし、変に役割に囚われてしまったことで目標を達成するために動くという基本的なことが疎かになってしまい、書籍「チーム・ジャーニー」でいうところの「チーム」ではなく「グループ」になってしまっていました。
※主語が「私たち」ではなく「私（個人）」
また、チームとしての目的をきちんと相談せずに進めてしまっていたため、自分の役割の目的が完了したら他のことには関心を持たないということになってしまっていました。
3-2. コミュニケーション不足の具体的な問題
上記の通り個人商店の集まりと化してしまっていたため、コミュニケーションも不足していたと思います。
プロセスの段落でも触れますが、毎日デイリースクラムは行っていたものの目的を見失っており、ただの情報共有で済ましてしまっていることがほとんどでした。
このようなプロセス以外にも、前述の通りお互いの役割に関心がなくなってしまっていたため、新事業のターゲットをどうするかなど根本の目的を達成するための会話が圧倒的に不足していたと思います。
3-3. プロセスの軽視がもたらした悪循環
新規事業の検証を始めた当初、ステークホルダーからの要望に迅速に対応するため、という名目でスクラムの各プロセスをかなり簡略化し、毎日のデイリースクラムと簡易なプランニングしかしていませんでした。
時間短縮を意識するあまり振り返りを行っていなかったのですが、これが本当に良くなかったです。
最初はデイリーの中で反省も行うことを決めていたのですが、やはりファシリテーターがそのことを忘れていると振り返り・改善の機会も失われてしまいます。
結果、振り返りのタイミングや改善点を洗い出す機会を失い続けたまま最後の方まで動き続けることになってしまいました。
4. 学んだ教訓
4-1. チーム内の品質管理の重要性
今回プロトタイプの開発をClaude等のAIツールを使って行っていました。
１つのサービスでしたが、開発の都合上分野に分けて２つのプロトタイプを作成することになりました。AIツールで開発速度が爆上がりしたこともあり、一つのプロトタイプを一人が担当することになりました。
本来であればチーム内でソフトウェアの方向性が合っているかといった観点でレビューすべきでしたが、これも省いてしまいました。結果として、個人が開発したものをプロトタイプを検証してくれる営業担当者へ横流しするだけになってしまいました。
結果的に営業担当者にとって分かりづらい表記があったり、操作のしづらさが残ってしまいました。
プロトタイプとは言え、必要な工程を省かずにきちんと行い、その上で速度を出す工夫をすべきです。
4-2. チームビルディングの必要性
プロジェクトが始まる初期段階で、インセプションデッキの作成を行うべきです。
当然初期段階では書けない項目もありますが、少なくとも「我々はなぜここにいるのか」を実施することによって、個人商店のところで記載したような「チームの目的がはっきり決まっていない」ということを防げたように感じます。
4-3. 外部ツールとの適切な付き合い方
報告資料作成時にLLM（主にGemini）との壁打ちに頼りすぎてしまい、自分の言葉で説明できない状況に陥りかけました（上司からの指摘で気づきました・・・）。
具体的にいうと、GeminiのDeepResearchを駆使して最終報告時に多角的な意見を出せるように頑張っていたのですが、やはり自分で調べたり検証した案ではないので全くの腹落ちしておらず誰がみても「AIに作らせたんだな・・・」ということがわかる資料になっていました。
ただLLMが悪いわけではなく完全に使う側の問題なので、次の点を注意したいと決意しました。
- LLMはあくまで補助。自分がどういった報告・説明をするかは自分で決める。
- DeepResearch等で本当に色々な情報を調べることができるが、究極的にはただインターネットから拾ってきただけの情報。自分がやったこと、自分が出した結論から報告内容をまとめる。
4-4. プロセスの意味を理解する
冒頭で記載した通り、今回はスクラムのプロセスをかなり簡略化して進めていました。
しかし、書籍「アジャイルサムライ」などでも述べられているように、守破離の「守」に到達していない状態でプロセスを変更すること自体NGでした。
スクラムのプロセスは偉人たちの叡智で決められているため、まずはその通りに実践してプロセスの基本を理解した上で自分たちなりの工夫を行うべきだと気づきました。
5. おわりに
いかがでしたでしょうか。
見事にスクラムガイドにも記載されている「理解は容易、習得は困難」という状況に陥っていました。
なかなか反省点の多いプロジェクトになってしまいましたが、逆に多くのことを学ぶこともできました。
今後もし同じようなプロジェクトを担当する機会があれば、特に以下の点を肝に銘じて進めたいと思います。
- チームとしての目的を明確にし、チーム員全員が腹落ちするまで議論する（インセプションデッキの「我々はなぜここにいるのか」）
- 基本を理解して進める
なお、今回のプロジェクトはほぼリモートで進めていましたが、新事業の検討のような創造的な作業は、できるだけ対面で行った方が効果的だと感じました。開発作業とは異なり、アイデア出しや議論はface-to-faceのコミュニケーションの価値が高いと実感しています。
Discussion