はじめに
BABY JOB株式会社 開発部 手ぶら登園開発課 の OKWRK です。
BABY JOBへは今年の10月に参画したばかりの新参者です。
さて、私が所属する手ぶら登園の開発チームでは、開発手法としてスクラムを採用しています[1]。
実のところ私は前職でもスクラムの経験があったのですが、その体験は全くと言ってよいほど異なっていました。
前職のチームではスクラムは数々の苦悩をチームに振りまいた挙句、最終的には「滅んだ」のですが現職の手ぶら登園の開発チームではスクラムが機能し「活きている」と感じられるのです。
2つのチームは一体何が違っていたのでしょうか。
今回はこの２つのチームを比較することで、前職でなぜスクラムが滅んでしまったのか、そしてスクラムが「活きる」組織の条件について考えたいと思います。
２つの組織の共通点
実のところ、これから比較する２つのチームには共通点も多数あります。
特にチームをとりまく環境にはかなりの共通点があります。
- フルリモートのメンバーが多い
- 自社プロダクトの開発を、完全に内製化して行っている
- 会社の看板的プロダクトを開発しており、リソースも社内で一番割り当てられている
- 自分たちの他にももう１チーム 開発チームが同じプロダクトの開発に携わっており、合計で10数名の開発メンバーが参画している
- 1~2年で急激に大きくなった組織に属しており、ほとんどのメンバーの在籍期間が2年未満
- １つのプロダクトに集中して対応でき、１つのチームで複数プロダクトを見る必要はない
- ABI認定スクラムマスターが組織に在籍している
このようにチームを取り巻く環境の面はではかなり共通部分が多いことがわかります。
また、スクラムが滅んだ組織にもABI認定スクラムマスターが在籍していたということは、スクラムについて正しい知識を持った人物がいても結果は良くならなかった事を意味するかと思います。
スクラムの運命を分けた２つのチームの相違点
チームを取り巻く環境という面では多くの部分で共通点が見える両チームですが、一体なにが決定的な違いを生んだのでしょうか。
私は、その文化や価値観に相違点があったと考えています。
メンバーの信頼関係を重要視するか
２つのチームとも所属する組織が１～２年で急激にメンバーの数を増やしており、開発組織全体で時間的にはまだ付き合いの浅いメンバーがほとんど、という状況については共通していました。
ただし、この状況を問題視して対応していたかという点については大きく異なります。
スクラムが滅んでしまった前職の開発チームでは、多くの企業と同じように新メンバーの加入があっても、開発組織の全体朝会で簡単にお互いに名前と所属を伝える程度の自己紹介をする程度でした。
また雑談なども少ない文化だったので、メンバー間の自己開示や相互理解はなかなか進まず、スクラムを進めるうえで重要な信頼関係の構築に時間がかかっていました。
さらに、業務委託の契約形態をとるメンバーがほとんどだったこともあり早期に離脱してしまうメンバーも多かったため、チーム内の信頼関係はいつまで経っても構築されませんでした。
一方で、スクラムが活きている手ぶら登園開発チームは、所属する開発部の新メンバーオンボーディング時に自己紹介スライドを作ってもらい、そのスライドを使って自己紹介をしています。スライドはメンバー全員が見れる共有フォルダに保存されているので、いつでも見れる状態になっています。さらに、新メンバーに既存メンバー全員の自己紹介を聞いてもらう時間をとっており、オンボーディングの一環でかなり丁寧にメンバー同士の自己開示、相互理解を促進させるための時間をとっている印象です。
結果として手ぶら登園開発チーム含めBABY JOBでは入社後早い段階で相互理解がすすみ[2]、メンバー同士の信頼関係が早期に構築されていると考えています。
コミュニケーションの取り方の文化の違い
フルリモートのメンバーが多く、非同期コミュニケーションの比率が高いという点については共通していますが、そのコミュニケーションの取り方や意識にはやはり明確な違いがありました。
スクラムの滅んだ前職チームはプライベートチャネルへの投稿やDMを多用する傾向[3]にありました。これは個人情報を扱うことの多かった事業の性質や、個人主義的な社内の文化が背景にあったのかと思うのですが、クローズドなコミュニケーションが主流になってしまっており、スクラムマスターが情報の公開性を説いても、なかなか改善されないものでした。
一方で、スクラムが活きている手ぶら登園開発チームは、チームメンバーはSlackのDMなどは積極的には使わず、基本的にオープンなチャネルや環境でのコミュニケーションをとる傾向にあります。
これはチームが所属する開発部のWorkingAgreementにも「コミュニケーションは原則、オープンかつ、必要に応じて情報がストックされる場所で行うことを好む。」と記されており、メンバーの中でコミュニケーションは可能な限りオープンに行うべきであるという認識が共有されています。
会議の議事録なども会議終了後すぐに関係個所に共有されるので、BABY JOBでは情報の透明性がしっかり確保されている印象です。
お互いを尊重しあえているか
エンジニアにとって、コードレビューはかなりデリケートなコミュニケーションの１つです。そのチームの文化が出るタイミングでもあります。
残念ながらスクラムの滅んだ前職チームでは、コードレビューは良い状態とは言えませんでした。
レビューの催促を受けてもなかなか応じなかったり、自分の主義主張と合わないことに過剰にコメントをつけたりということが度々行われ、ひどいときにはほぼ罵り合いの喧嘩になっていたことすらありました。
スキルの高いメンバーは多かった半面、自分の主義を優先して押し通すようなことや、他者に歩み寄らずに突き放すようなことが多く、コードレビュー以外のコミュニケーションでも衝突が多く見受けられたのです。
最終的にコードレビューの遅延ややミスコミュニケーションによって計画への影響が出ることも多かったため、スプリントゴールも未達になり、ふりかえりの雰囲気は最悪になっていました。
一方、スクラムが活きている手ぶら登園開発チームでは、結果的にコードレビューで大幅に修正が入る場合でも、実装者の観点やチャレンジを称えるなど、良い点を見つけて評価することが意識的に行われています。また、コードレビューに限らず「褒める」ということが日常的に行われている印象で、日々ぬくもりを感じています。
これは、お互いを尊重しあう気持ちが前提としてあるからこそだと考えています。
なぜスクラムが「活きている」と感じられたのか
２つのチームのスクラムの死活を分けたと思われた文化面の相違点を3つあげましたが、これら３つの相違点には「スクラムの重要な考え方」に基づく重要な要素が内包されていたのです。
その「スクラムの重要な考え方」とはズバリ「スクラムの５つの価値基準」です。
スクラムの５つの価値基準
スクラムの５つの価値基準は「確約」「集中」「公開」「尊敬」「勇気」です。
「確約」は、「スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する」
「集中」は、「スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する」
「公開」は、「スクラムチームとステークホルダーは、作業や課題を公開する」
「尊敬」は、「スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される」
「勇気」は、「スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ」
というそれぞれの意味を価値観を示しています。
先ほどの相違点をそれぞれにあてはめてみると、
「メンバーの信頼関係を重要視するか」は「確約」と「勇気」
「オープンなコミュニケーションを好むか」は「公開」と「集中」
「お互いを尊重しあえているか」は「尊敬」と「集中」
の価値基準と強い結びつきがあるように思えます。
そして、結果として５つの価値基準が満たされていたため、スクラムが「活きている」と感じられたのです。
おわりに
私が直近経験した2つのチームの対比から、スクラムが「活きる」組織の条件として「メンバー間の信頼構築」「オープンなコミュニケーション」「お互いの尊重」がいかに重要だったかを再認識しました。
同時に、これらすべては「スクラムの5つの価値基準」に基づいており、逆説的に「スクラムの５つの価値基準」を守ることこそが、スクラムを活かすための条件なのだと考えています。
これからスクラムを導入しようと考えている方、またはすでに実践しているが課題を感じている方にとって、この記事が一つの参考となれば幸いです。読者の皆さんの組織が、スクラムを「活かす」ことができることを願っています。
私たち BABY JOB は、子育てを取り巻く社会のあり方を変え、「すべての人が子育てを楽しいと思える社会」の実現を目指すスタートアップ企業です。圧倒的なぬくもりと当事者意識をもって、子どもと向き合う時間、そして心のゆとりが生まれるサービスを創出します。baby-job.co.jp/
Discussion