スクラム開発の経験から紐解く、価値提供を加速させるチーム文化の形成

はじめに

優れたチームビルディングが必ずしも事業の成功を保証するわけではありません。しかし、チームの成長なくして事業の成長は望めないことも確かです。

この記事は、所属するプロダクト開発チームにおいてのチームビルディングでの経験や、それを通じて得た学びなどをまとめたものです。

成功事例というわけでは一切なく、チームビルディングで培った個人的な考えのアウトプットや記録です。

チームビルディングの最適解は組織文化や人員構成、事業やビジネスの特性によって大きく異なるものだと思います。同じチームなのにその時期によっては変えていく必要もあるものです。

この記事では具体的な方法よりも、少し抽象的な考え方を中心に書いています。体系的にナレッジをまとめきれていないことや、少々書き殴り気味な文章なので読みにくいかもですが、ご了承ください。

対象読者

• プロダクト開発などに携わるエンジニアや企画職の方
• アジャイル開発やスクラム開発に挑戦しようとしている、または壁にぶつかっている方
• チームビルディングに取り組んでいる方

以前のチームの特徴と課題

まずはじめに、以前のチームについて簡単にまとめます。以降のセクションはここでのチームがスタート地点として記述しています。

チーム構成・体制

そもそも会社としての組織構造は、いわゆる機能別組織でエンジニアと企画職は別の部門に所属しています。

本記事でフォーカスを当てるチームは、上記の機能別組織から、1つの事業（サービス/プロダクト）専任の横断的なチームを構成した体制になります。

アサインされる人数は、時期によって変わっていくことになりますが、おおよそ以下の通りです。

• エンジニア：2〜4名
• 企画職：1〜3名

※営業、デザイナーなど他職種のメンバーもいますが、本記事では便宜上プロダクト開発で中心の登場人物となるエンジニアと企画職のみに言及します

開発・運用プロセス

元々は職能別組織のみで、事業専任の横断的なチームも存在しなかったため、開発プロセスとしてはいわゆるウォーターフォール型の直列的な運用でした。

横断チームになり、エンジニアと企画職が定期的に会話する機会は増えましたが、それでもウォーターフォール型の開発プロセスが続いている状況でした。

この運用では、企画職がプロダクト開発に対してのほぼすべての施策の立案・仕様策定を行い、エンジニアは仕様に基づく開発とリリースを行うというものでした。

チームの課題

ここはとくに個人的な解釈となりますが、この頃のチームには以下のような課題がありました。

1. 開発プロセスの非効率性

• ウォーターフォール型の運用から抜け出せず、学習サイクルが非効率的
• 開発プロセスに対してトライができておらず、成り行きの独自運用を行っている状態

2. 職種間のコラボレーションによる相乗効果が生まれていない

• エンジニアと企画職で、工程・業務が完全に分離されている
• 自社開発のプロダクトではあるが、一緒に議論するなど協業するケースが少ない

3. 「スピード」の意識が薄い

• 企業に良いものをしっかり考えて作る文化があるが、一方でスピードに対しての意識が薄い
• 自社開発のプロダクトという性質上、外部圧力も弱く期限設定が緩い

現代のプロダクト開発のプラクティスとの間には確かにギャップがありましたが、同時にそれを埋めることで、より良いプロダクト開発を通してユーザーにより多くの価値を提供できる可能性を期待していました。

スクラム開発への挑戦とそこから得た学び

導入の経緯

上記のチーム状況を改善するために、いくつかの開発手法やプラクティスを調査・検討しました。

その中でとくにスクラム開発の考え方に共感したのと、ある程度の運用プラクティスが体系的にまとまっていることもあり、スクラム開発にチャレンジすることにしました。

チームで実際に行っていたスクラム開発の内容についての詳細は本記事では割愛しますが、一緒のチームメンバーが記事を書いているので、気になる方はそちらを見てみてください。

https://zenn.dev/lclco/articles/f2f9d7709c178f

スクラム開発によるプラスの効果

はじめはスクラム開発の運用に慣れるまでに時間がかかりましたが、チームがある程度慣れて、運用がスムーズに行えるようになった頃、以下のような効果や手応えがありました。

• エンジニアと企画職のコミュニケーション機会の増加
• コミュニケーションの集約と一元化による効率化
• スプリントによる締め切り効果で開発スピードの向上
• エンジニア同士の開発における協力体制の強化

本記事ではメリットは簡単にしか触れませんが、改めて振り返ってみても、スクラム開発を導入したことで以前と比較してチームは確実に良くなったと感じています。

スクラム開発で感じた難しさ

一定の手応えを感じながらも、同時にスクラム開発に対しての理解が進めば進むほど、その度に挫折感を味いました。

個人的に感じた難しさはいくつもありますが、たとえば以下のようなものです。

1. チームに理論やマインドを浸透させる難しさ

• 形式などルールを変えることはある程度できるが、マインド自体を変化させるとは格段に難易度が高い
• スクラム開発は理論の浸透が鍵で、自己管理型のチーム文化を形成することが難しい

2. チームの意識が「価値の提供」ではなく「形式的な運用」に偏重

• 前述ができない結果、スクラムセレモニーの運用や手順にばかりに気を取られる
• 本来の目的である「ユーザーへの価値提供」より、運用を上手く回すこと自体が目的化する

3. 超えられない分業の壁

• 企画職が施策・仕様を考えて、エンジニアが開発する運用は根本的には大きく変わらず
• プロダクトバックログリファインメントが仕様の質疑応答の場になっていた

スクラム開発を通じて得た学び

スクラム開発の実践を通じて多くの難しさを感じながらも、試行錯誤しながらチームビルディングを進める中で、段々と自分の中に重要な考え方が形成されていきました。

この部分が自分にとっての大きな学びとなるため、少し多いですが覚えている範囲でまとめます。

1. 「価値提供」を起点としたプロセスの構築

チームとしてさまざまな活動を行いますが、最終的にはユーザーに「価値を届ける」ことが目的です。そのために何をすべきか、どうすれば上手くいくかを問い続けることが、チームビルディングにおいても非常に重要な発想の起点となります。

2. 言語化・可視化

当たり前ですが、チームは人の集合体で、それぞれの人が異なる考えを持っています。
時には直接言葉で直接伝えることも重要ですが、いつ誰が見てもある程度同様の解釈ができるように、方針やメッセージを言語化・可視化することは、チームの共通意識や共通理解を生むために非常に重要で効果的です。

3. 課題・テーマの優先順位の明確化

プロダクト開発は、非常に多くの要素が絡み合い、課題の候補も数多くあります。
ただ、それらの中で本当に重要なものを選び出し、今注力するべきことを明確に宣言することは重要です。

これにより、効率的で意味ある仮説検証に繋がったり、チームの意識や課題感が統一され、課題解決に向けて建設的なコラボレーションをする鍵になります。

4. 開発だけでなく、意思決定もスピードにこだわる

開発プロセスだけでなく、意思決定もスピードにこだわることは時には重要です。

とくに現代にはチームの共感を重要視する価値観や重要性が説かれるシーンが多いですが、完全な共感など完璧さにこだわりすぎず、適切なスピード感を持って意思決定を行うことが重要。
素早く実行しフィードバックを得て改善するのは、プロダクト開発においても、チームビルディングにおいても同様です。

5. スクラム開発のセレモニーからの気づき

こちらは少し毛色の異なるものですが、スクラム開発の各セレモニーや運用からも、学びとなる部分がありました。

• スプリントなどから学ぶ締め切り効果
  ベロシティの計測と活用は決してエンジニアに開発スピードの圧力をかけるためのものであるべきではないですが、スピードに対する意識が低いチームに対して、明確なタイムボックスを上手く設定することは、チームのスピードと集中力が高めることに効果的。

• プロダクトバックログリファインメントから学ぶ職種間コラボレーションのコツ
  コミュニケーションを不定期かつ多発的に発生させず、集約化することでのコスト削減の考え方は重要。また、リファインメントを単なる質疑応答ではなく、職種間のコラボレーションを促進するための場として活用することで、職種間の相乗効果を高めるためのチャンスを作ることができる。

• レトロスペクティブから学ぶチームに対するPDCA
  リリース施策に対してのPDCAは良く回そうとするが、同時にチームに対してもPDCAを回す文化を作る。チームや運用が改善すれば、結果的にプロダクト開発や価値提供にレバレッジがかかる。

スクラム開発からの学びからトライした新たなチームビルディング

今となっては、スクラム開発は当時に比べ、何倍も難しさや奥深さを感じるとともに、何倍も可能性を感じる開発プラクティスだと感じています。

ただ、今回の一連のチームビルディングにおいては「完全にスクラム開発をワークさせることはできなかった」というのが個人的な解釈です。

ただ前述の通り、その経験から多くのことを学び、ここ1年以内でスクラム開発にはこだわらない新たなチームビルディングにチャレンジしてきたので、以下に主な取り組みをまとめます。

チームの「意識」を揃えるための取り組み

1. 「ミッション・ビジョン」「ロードマップ」の言語化・可視化

まずは改めてチームの方向性を明確にするための「ミッション・ビジョン」や「ロードマップ」を作成し、チームとして何を目指すのか明確にしました。

これは、意思決定の重要な軸として機能したり、ひとつひとつの施策や業務が何のためのものなのかを認識しやすくなることで、メンバーのモチベーションやコミットメントミットメントを向上させることに繋がります。

2. 注力テーマの明確化

中長期的な視点での方向性の言語化・可視化が「ミッション・ビジョン」だとすると、「注力テーマの明確化」は短期的なチームの注力のポイントの明確化です。

直近で取り組む内容や、解決したい課題を明確にし、狙いを定めた上でチーム出力の最大化を狙います。また、アイデアを考えたり、議論する際こ、思考のスコープを限定的にする効果もあり、メンバー全員が発想しやすくなります。

チームアクションの「質」を高めるための取り組み

3. 施策タイプの定義・分類と運用フローのパターン化

施策・タスクにおけるタイプを定義・分類し、それぞれのタイプ別に運用ルールをパターン化して定義しました。
重要な注力テーマに対するコア施策などはチームで比較的コストをかけて検討きるようにしつつ、コア施策以外では効率・スピードを重視した分業的なアプローチをバランス良く両立するためのルールメイクです。

これにより、チームアイデアの質を高めつつ、人的コスト、スピードのバランスを取ることを狙うことができます。

4. 「価値提供」「課題解決」を中心としたコラボレーション

コア施策については、「価値提供」と「課題解決」を軸としたコミュニケーション設計を整備しました。ウォーターフォール的な分業ではなく、各職種がそれぞれの観点やアイデアを、共通のテーマに対して建設的な意見交換ができる場として設定しています。

提供価値や課題に対しての手段の選定、開発仕様の検討など、以前は企画職がある程度決めきっていた部分を、エンジニアとのメンバーが協業的に意見を出し合い、より良いアイデアや手段を見出せる可能性が高まった印象があります。

5. 「サービス価値・事業課題」と「プロダクトの質」のアプローチを分離

各職種の強みや役割を最大限に活かしながら、より効率的で質の高い施策立案やプロダクト改善案の立案・実行プロセスを確立することを狙い、「サービス価値・事業課題」と「プロダクトの質」でアプローチを分離しました。

企画職は「サービス価値・事業課題」に対しての施策を中心に起案し、エンジニアは「プロダクト自体の質」を上げるための施策を中心に立案するような運用を試し始めていて、今のところの所感としては、プロダクトの質を着実に上げていくために効果的な考え方やプラクティスになり得ると感じています。

6. リリース後のフィードバック共有サイクル

リリースした施策やアクションの効果を、チーム全員で把握し、ネクストアクションへの反映するプロセスを標準化しました。

こちらはチームとして当然必要ではあるものの、チームとしてサイクルを回すことで、チームメンバー全体のプロダクトや事業の理解の促進に繋がる効果を感じます。こちらを起点に「こうゆうことに活かせないか」というアイデアが出たり、議論が深まるケースもあります。

チームアクションの「スピード（量）」を高めるための取り組み

7. 「小さく早く」届けて学習するチームに

「小さく早く」ユーザーに届け、フィードバックを素早く得る、いわゆるアジャイルな発想を重要視して運用し、文化形成にチャレンジしています。

現代のプロダクト開発において、不確実性に向き合うための効果的なプラクティス、開発のリスクヘッジ、開発生産性文脈でのビジネス貢献など、さまざまな効能が認められてきている印象ですが、意外と実践しようとすると難しいものです。

とくに元の組織・チーム文化として、ウォーターフォール型の運用プロセスが根付いている場合、意思決定のプロセスはじめある種の発想の転換が必要になります。こちらは根気強くチームで考え方を変えていきつつ「小さく早く」を実践していきながら、チームの文化として形成されてきている印象があります。

個人的には「ユーザーに提供する価値」を明確にして、必要十分な機能を見極めることから始めることがポイントというかコツかなと実践してきた感覚では思っています。

実際に起きた変化や結果としては、当初想定していたフル仕様を意味ある単位で小さく徐々にリリースしてフィードバックを得ることで、フル仕様の実現に対しての必要性を問い直したり、別の課題を優先度を上げて対応するなど、まさにアジャイルな意思決定に繋げられています。

8. 行動指標の定義

売上やMAUなどのKGI/KPIは重要な指標ですが、直接的にコントロールが難しい成果目標です。そこでより具体的な行動目標として「スプリントあたりのリリース数」を設定しました。

これは単なる数値目標ではなく、「小さく早く」を実現するためのコントロール可能な指標として位置付けています。リリースを通じてしか現実を変えられないという前提のもと、多くのリリースを実現することでユーザーへの価値提供を加速させることを意識しています。

この指標を活用することで、「目標のリリース数を達成するために何が必要か」「どうすればリリース数を増やせるか」といった議論を通じて、チームビルディングやリリースプロセスの改善に活かしています。

さいごに

この記事では、スクラム開発の経験から得た学びと、それを活かした新しいチームビルディングの取り組みについて紹介してきました。

振り返ってみると、チームビルディングを通じて多くの気づきと成長の機会を得ることができました。

プロダクト開発を通じてビジネスを成功に導くためには、チームビルディングは非常に重要な要素となります。簡単な道のりではありませんが、継続的な改善と挑戦を重ねていきたいと思います。

最後まで読んでいただき、ありがとうございました。