スクラム開発体制の組織だからこそ、スクラム開発をしないチームが存在すべき理由
この記事はGLOBIS Advent Calendar 2020の21日目の記事です。
先日のプロダクトマネージャー Advent Calendar 2020に引き続き、今年のAdvent Calendarは2本目…もし良かったら読んでみてください^^
はじめに
現在、「グロービス学び放題」というMBAの知識をベースにした動画学習のサブスクリプションサービスのプロダクトマネジメントを行っています。サービス自体は立ち上げからもうすぐ満4年が経ちますが、法人ユーザーを主として個人ユーザー含めて現在10万人以上の方に利用されております。開発体制は、組織を通してスクラム開発を推奨していますが、状況に合わせて臨機応変な組織づくりを行っており、私の率いているチームが特殊な動きを取っており、それについてご紹介できればと思います。
グロービスの開発体制
現在、社内には10前後の開発チームがあります。多くは内製でサービス開発を行っているチームですが、中には外注してたシステムを内製化するために社内の少数のメンバーが外部の開発パートナーをディレクションしながら開発するチームや、社内向けの共通システムの保守運用を行っているSIerチックなチームもいます。
グロービス学び放題に関しては、法人の人事担当者などの管理者向けプロダクト、法人/個人のサービスを受講するプロダクトはwebとappとに分かれており、さらに、決済周りを包括して開発しているチームがあり、4つのチームがスクラム開発をしております 。
今回の話はグロービス学び放題の開発に絞ったものとなっておりますので、その他にも事業毎に開発チームがありますが、割愛させていただきます。
「スクラム」というフレームワークにおけるイメージ
今では多くの企業でスクラム開発が行っていると同時に、その多くが開発を伴うワークフローに課題を残している気がします。スクラムガイドでも定義している通り、スクラム開発は非常に実践的なフレームワークであって、ガイドの示す方向性に沿っていれば、高い確率で成功するはずなんですが、最近以下のようなことを考えております。
スクラム開発を行う中で、非開発組織-開発組織の意思疎通の難しさ、古参者-新参者の組織における情報共有の難しさ、シニア-ジュニア間の能力差や個人間での見えているスコープの違いから来るコミュニケーションの難しさがあると思っています。さらに、スクラムのフレームワークを作り上げたJeff Sutherlandは、銀行のATMビジネスでの経験後、11社のVPoE、CTO、CEOを歴任しており、その経験を経て、「スクラム」のフレームワークを完成させました。
個人的な意見ですが、「スクラム」は非常にバランスの取れたフレームワークであり、汎用性も高いと思っています。個別具体のケースには、組織全体に適用するために、社内のコンセンサスであったり、マネジメント層のスクラムへの理解度が必要なのだと思います。それらの要素が整っておらず、開発の現場でスクラム開発を導入ことで問題が起こっているのではないだろうか？それらを組織内での現場-マネジメント間の対立構造にしないために、アジャイルコーチやスクラムコーチが必要になってきているという理解に至っています。
スクラム開発偏重になると起こってくる問題
組織全体を俯瞰した視点が薄れて、スクラムチームの視点のみで物事を考えるようになってくると、3段階に問題が生じてきます。
1.サイロ化
まずは発生してくるのはサイロ化です。スクラムチームの構成メンバーの流動性が少なかったり、スクラムのワークフローを回すために他チームやステークホルダーとのコミュニケーションが少なくなったりすると、さらにサイロ化を加速させます。極端なサイロ化でなくとも、チーム間のコミュニケーションの壁が高まることは、個別最適が進みやすくなり、結果として各個人が全体感を把握しにくくなってしまうことが問題になります。
2.“点”でのコミュニケーションに陥りやすくなる
以前のスクラムガイドでは、開発チームは自己組織化しており、「誰が」「どのように」作業するかを選択できるとなっていました。2020 年版ではスクラムチームの自己管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようになりました。このようにスクラムガイドの改定で、スクラムチームの各メンバーが自律的な動きを求められるようになったが、依然としてチームとして「何をつくるのか」はPOの意思決定に委ねられており、ユーザーやステークホルダーにおける価値をしっかりと価値検証できるかはPOに大きく依存してしまいます。さらに、チーム外に関する多くの情報がPOを経てチームにインプットされる場合、その伝達過程での情報のフィルタリングやスクリーニングが意識的、無意識的に関わらず発生してしまうと、そのスクラムチーム全体が偏った情報を元に意思決定してしまうので、先述のサイロ化を加速する羽目になってしまう。こういった“点”でのコミュニケーションは、状況を多角的に捉えられなくなるので、気をつける必要があります。
3.構造的に情報の非対称性が組織内に発生する
組織構造が複雑になるあるいは多くのチームで成り立つようになってくる中で、“点”でのコミュニケーションが促進されると、他のコミュニケーションパスがなくなり、情報を判断する術がなくなってしまいます。チームリーダー間のコミュニケーションに加えて、チームメンバー間のコミュニケーションがある“線”でのコミュニケーションがあると、例えばチームでのmtgの際に、他方の情報を支持・強化する、あるいは、相反する情報の共有が起こり、議論は深まる方向性に動きます。更に異なる情報が加われば、それは“面”でのコミュニケーションとなり、情報の検証精度が更に上がり、自ずと効率的かつ正確な新しいコミュニケーションフローができたり、チーム全体の情報感度が高まるなど、他チームとコラボレーションできる機会が劇的に上昇します。しかしながら、逆に“点”でのコミュニケーションが主流になってしまうと、組織内における現場層とマネジメント層での認識だけでなく、同じ現場層でもチーム間での認識に乖離が出てしまい、共通認識を持つことが難しくなってしまいます。それが原因となり、共通認識を持つためのコストがあがり、そのような環境下では働きにくさが出るので、チームの生産性も下げてしまいます。
以上のようなプロセスを経て、あるチームと別のチームの間に存在する課題やすべきことに対する対応が漏れてしまうことが大きな課題になります。チーム間に落ちているタスクは、優先度の決定から、割り当てるリソースの決定、着手したとしても他に差し込みがあった際の対応速度に至るまで様々な点で軽視されてしまいがちです。その結果、重要度と緊急度の2軸のマトリクスにおいて、下図のように、第一に重要度、次に緊急度で意思決定されるべきことが、緊急度で意思決定されるようになってしまう。つまり、組織として、真に重要なことよりも、目先に差し迫っているものに対応するという意思決定が多くなり、中長期の戦略スコープが持ちにくくなってしまいます。
スクラム開発をしないチームが存在すべき理由
先述したとおり、スクラムは優れたフレームワークなので、組織の文化や状況に合わせて、うまく適用させることで生産性を上げることが出来ます。その時々の状況に合わせて、組織体制を変えていくなど、組織としての意思決定が必要になります。その一方で、ボトムラインからも上記の課題を対処できるのではないかと考えて、実践しているのが「あえて、スクラム開発をしないチームを作る」ということです。
「あえて、スクラム開発をしないチームを作る」
スクラム開発をしないチームが、今の私のチームで、総勢10名くらい、私以外の全員が他のチームとの兼務（…実際の稼働比率は20％くらい）であったり、週2-3稼働の業務委託であったりで構成されています。主に最近は、RubyやRailsのアップデートであったり、メール配信システムのリプレイス、サービスを通した分析基盤の整備を行っています。他の開発チームや非開発チームとの関わり方は、スクラム開発からはかけ離れていて、プロジェクトベースで進めております。私のチームから2人以上を選出（…1人だけだと悩みを抱えてしまってスピード感が出づらいので、いつでも相談して決めれるように）し、他チームとの打ち合わせを通して、やるべき事をリファインメントしていきます。一方で、他のチームがスクラム開発を行っているので、スクラムで大事な概念である「透明性・検査・適応」は意識し、プロダクトバックログなどのスクラム開発で出てくる成果物はきちんと管理するしています。これは、インターフェース部分は開発チーム間の連携を損なわないために必要なことだと思っています。
そういった、ポジション取りをし、チームを編成する中で大事だったポイントは、「プロフェッショナルであること」、「チーム間のメディエーターが必要」、「常にYesから始める」の3点です。
プロフェッショナルであること
ビジョナリー・カンパニー2でも「誰をバスに乗せるのか？」と言われているように、個人個人の能力の高さは非常に大事です。サイバーエージェントで開発責任者をやっていた方や、現職で開発組織の部長クラスの方、楽天の方など、「週5稼働を求める」のではなく、「優秀な人材に協力してもらう」というスタンスでチームを作っています。グロービス自体の知名度が高くないので、仕方ない部分もありますが、やっていることに面白いと思ってもらえて、「協力してもらってる」状態になります。また、いい意味でみんながドライで、苦労して作ったものでも、ユーザーにとって価値がなければ「自分らがやったことに固執せず、すぐに置き換えるべし！」というようなマインドを持っています。これはチーム内ではUser firstを最優先の判断軸としていて、作業内容のROIなどは計算しつつも、同じ判断軸のもと動けている良い証拠だと思っています。ちなみに、開発組織全体でも「User Centric」を大事にしており、チーム内では更に意識を高めるために、「User First」と言い換えています。
チーム間のメディエーターが必要
他チームとの連携の観点では、チーム全体として、約5チームと連携している状態になります。チーム間連携を進めていく中で特に意識しているのは、「信頼関係をつくっていくこと」です。全員が業務委託など他のチームとの関わりが薄いと、困難な局面に直面した際にうまく突破できないので、社歴が長く社内のシステムに精通しているメンバーにも一緒に入ってもらうことで、プロジェクトを通して、お互いの理解を深めています。プロジェクトが終わる時には、新しい信頼関係が生まれ、それが次のプロジェクトで次の信頼関係を生む種になっている…そんな好循環のサイクルが生まれるように全体の設計を考えることも大事なことです。
常にYesから始める
よく「日本人はNoと言えない」みたいなことで、批判される時もありますが、チームとチームに落ちてしまっているものを拾っていくポジションからすると、常にYesから始めることは必須だと思っています。私自身、「出来るか出来ないかで言うと、人間の頭で考えられることで、システム化できないことはない」（…ただし、どれだけ工数がかかるかは一旦置いておく。笑）と思っているので、まずは相手の話を聞き、その重要度の位置付けをはっきりさせることにひたすら注力します。そのヒアリングの中で大事なのは、小さなことでも良いから要望や希望をすべて言ってもらうことで、そのためにはポジティブな空気感を作ってあげることが大事だと考えています。
最後に
ここまで読んでいただきありがとうございました。
今年も残す所、あと10日となりましたが、昨日、今日と突然寒くなってきましたので、お体ご自愛ください。
また、もしAdvent Calendarなどを通して、グロービスに興味を持って頂いた方がいましたら、気軽にお話しましょー🎶
色々なポジションで採用しており、以下のリンクで確認できます。
