CADDi Be Agile! 〜開発もビジネスもスクラムで回してみた【イベントレポート】

キャディでエンジニア採用を担当しています片渕です。

今回は2022年3月25日に開催したイベント、『CADDi Be Agile! 〜開発もビジネスもスクラムで回してみた』の内容をレポート形式で紹介しています。

メインのアジェンダとしては大きく以下3点です。

Tech組織のみならずBiz組織でのスクラム導入の背景や現状、課題と感じている点などについて、Techからは高藤・Bizからは佐野がプレゼンしています。

[toc]

Tech組織のスクラム『LeSS』に関して

高藤:

LeSSという仕組みを一部のチームで導入しているので、その話を今回はしていきます。

なぜスクラムという開発手法を用いているのか

LeSSをやる時にも考えたことになるのですが、私は「Tech組織は価値を届ける開発組織でありたいな」と思っています。

これはどういうことかというと、エンジニアは技術的に難易度が高いことにも挑戦したいのですが、結局は作ったシステムを使うステークホルダーの方々が、価値を感じてもらわないといけないのです。

技術的にとても難しいものを作ったとしてもユーザ側に価値が無い、となるとエンジニアとしては何をしていたんだ?ということになってしまいます。

よって、しっかり価値を届ける組織を目指した時に、ビジネスが急成長してきた会社なので解決したい課題も少しずつ変化してきます。

そうした不確実な部分が多くあるものの、常に軌道修正をしながら開発できる組織で、しっかり価値提供できる開発チームでありたいと考えています。

また、上からの指示があったからやりましたというのではなく、ユーザとコミュニケーションして課題を設定し、課題を解いていく組織でありたいですね。

その実現のために必要なことが、スクラムとマッチしているので、現在もスクラムを継続しています。

スクラム導入の歴史や背景について

私がキャディに入社して3年ちょっと経過するのですが、入社時はエンジニアは数名ほどで、現在は50名ほどの組織になっています。

最初の頃は、なんちゃってスクラムのような状態で、生産管理プロダクトという我々の受発注の仕組みの中での基幹システムの部分は、数名規模の開発から始まりました。

この頃はアジャイル開発で、スクラムという言葉は知っているものの、しっかり学んだ人は私自身も含めていませんでした。

もちろんスクラムマスターという役割の人もいなかったですし、スクラムイベントがあるようだということを、なんとなくで進めていたのが正直なところです。

当時は、JIRAという仕組みを使ってチケットを切ることをやっていたのですが、何だか合わないなという意見もあり一旦辞めて、スプレッドシートにやることを書いていったことがあり、結果的に荒れたスプレットシートができあがってしまいました。

本格的にスクラムを知ったきっかけ

その後、スクラム開発に詳しいエンジニアリングマネージャーが入社して、また様々なプロダクトも作られるようになってきました。

エンジニアリングマネージャーからは、「Howをどうするか?」を教えられたというよりは、スクラム基本原則の理解が重要という話もあり、スクラムガイドを輪読して読書会なども開催していました。

結果、「スクラムでは何を大事にしているか?」という原理・原則を理解して、その上で自分たちは何をしなければいけないかを考えるようになりました。

この頃から、JIRAを改めて使うことになり、やや抵抗を感じながらもスプレッドシートからJIRAに移行もしました。

現在ではキャディの中では基本的にはJIRAを使っていますし、Biz側でも使われるようになっています。

そのような歴史があり、チーム全体通してスクラムでやる理由を理解した状態になれたのではないかと思っています。

LeSSの導入の背景

そして最近の話になってきますが、この1年でエンジニアが2倍の数にもなってきて組織が大きくなったので、LeSS(Large Scale Scrum)を導入することになりました。

LeSSを導入した背景としては、スクラムで推奨される人数は10名以下とガイドには書かれているのですが、我々のチームもそのようなサイズ感になってきた時に、コミュニケーションにやりづらさを感じていました。

例えば、デイリースクラムや振り返りの場などで時間を定めてコミュニケーションをするのですが、人数が多いと全員がすっきりするまで発言できず、限られたトピックのみしかコメントができなくなったのです。

自分の意見を言い切れなくて消化不良となるケースも多くなってきたり、プロダクトの面でも自分が担当しているプロダクトに近いもの、生産管理でいうと受発注がメインでデータを扱っているシステムと我々が発注するデータをパートナー様に提供するポータルのプロダクトチームとの連携の時に、お互いにどんなことを今後やっていくのかを、クオーターやスプリント単位での可視性・透明性が薄れてきているなと感じました。

そうした点を考慮すると、もう少し大きな人数でスクラムを回す方法がないかなと考えた時に、LeSSという仕組みを導入しました。

1つのプロダクトを開発する人数も増えてきて、プロダクトの価値を考えると一緒に動ける方が良いかなと思っていました。

そのため、2021年の11月からLeSSを導入し、1ヶ月間を準備期間としてそれぞれの開発チームが合流するためのことを考えていました。

LeSS以外にも手法はあるのですが、我々がやっていることをそのままできそうなのがLeSSだと思ったので、こちらを選んだということですね。

ラニング・リファイメント・レトロスペクティブもLeSSにあり、理解しやすかったです。

LeSS導入当初にやったこと

準備期間にやったことは、ミロというオンラインのホワイトボードでやったのですが、スプリントプラニングではチームごとにやる前に全体でプラニングして、その後に各チームごとにプラニングをやりましょうという話です。

スクラムの代表者、LeSSに参加してくれる各チームのリーダーに集まってもらって、どういうことをやらないといけないのかを書き出していきます。このイベントはどのくらいの時間をかけるのか、などを最初に議論するわけです。

開発者だけではなく、プロダクトオーナーとなるPdMにも理解して欲しかったので、オーナーがやるべきことを議論してすり合わせをして準備を進めて行きました。

実際に去年の11月からスタートして2ヵ月経過して問題も見えてきたので、「クオーターごとにLeSSを導入してどうだったか?」を振り返り、次のクオーターで新しい取り組みをやるということを継続しています。

今後に向けて

LeSSを選択して苦労もありましたし、私自身はもちろんですが参加したエンジニアも同じだったと思います。

スクラムやLeSSは、自分たちが経験したことを改善するのにはとてもいい方法で、各組織が経験したことを積み重ねていくことができます。

今後は、LeSSならではの悩みもありまして、チーム同士のコミュニケーションはどこまで担保すべきなのか、などは引き続き考えて行きたいと思っています。

Biz組織のスクラムに関して

佐野:

私の方からは、2022年3月24日にアトラシアンのイベントにてプレゼンさせていただきました資料をもとに、Biz組織でのスクラム導入の話をしていきます。

一般的にはソフトウェア系の会社にスクラムを導入すると思うのですが、どのような経緯でBiz側に導入していったのか、説明してきます。

Biz部門へのスクラム導入経緯

2021年の10月からスクラムを導入しはじめたのですが、ちょうど事業や組織が一気に拡大するフェーズで、プロジェクトマネジメントが急務という状態になりました。

QCD担保はもちろん、どんどん事業や組織が大きくなるものの、まだアーリーステージの会社なので、スケーラビリティを担保するには一定の型も必要になると考えていました。

そのため、何かしらの手法を入れようと検討したところ、スクラムの話があがり導入することにしました。Tech組織で既に導入していたので、Biz組織でも試験的に3プロジェクトからやってみましょうということでスタートしました。

導入直後のカオスからの改善

導入してみたところ、導入直後はカオスな状態が発生し、メンバーからスクラムやJIRAなどへの不満が続出しました。

バーンダウンチャートも見事にバーンアップしてしまうことにもなり、全然スクラムとして機能していませんでした。

そこでスピードを意識してPDCA回し、スクラムマスターを配置して、JIRA警察と称してDoDやストーリーポイントが入っていないことなど、細かくチェックをしていきました。

また、KPIの設定やモニタリングを行い、スプリント達成率などを計算して集計し、100%を目指していくといった取り組みを進めていきました。

このように毎週改善に取り組んでいった結果、少しずつコツが見えてきました。

このプロジェクトだったらバーンアップチャートが良いよね、JIRAオートメーション機能を使うといいよねというコメントが出て、やり切る意識が高まってきました。

導入してから2ヶ月後くらいで、きれいなバーンダウンチャートを示せるようになったのは、劇的なbefore/afterになったなと感じています。

このように結果がついてくると、スクラムやJIRAを嫌がっていたメンバーから、「とてもいいツールですね」「JIRAとスクラムの親和性がいいね」という話が出てきました。

導入した成果やメリット

キャディではムーンショットと呼ばれる非連続の成長を実現したり、事業課題の見える化も進み、スムーズなリプラニングも可能になってきました。

また、各チームのフレームワークが共通言語化したことから、議論の土台がそろってきたことは成果の1つと思います。

以上が、2021年の10月から12月までに起きたことです。

Bizやコーポレートも含めた全部門へのスクラム導入

この3ヵ月の成果を踏まえて一気に改善も進んだので、Biz/CPの全部門に入れて組織のOSにしたく、トップダウンスクラムをインストールすることにしました。

そのために年始の全社ミーティングで2時間くらい勉強会をやりました。

キャディでは前職がコンサル・ベンチャー・商社・メーカーなど様々で、アジャイルなプロジェクトマネジメントへの慣れ・不慣れの程度さは大きいのですが、改善を高速で回していくのは良いことだよね、と議論を進めながらやってきました。

スクラム導入の目的を言語化

キャディの組織のあり方によって、理想的なスクラムの形は異なると思いますが、少なくともBiz組織ではShift Leftな組織づくりを目指したいと考えています。

つまり、計画性や透明性を担保したり、事業スピードを早めたり、メンバーのコミットメントの担保することが大切になります。

さらにスクラム浸透に向けた取り組みとしては、認定スクラムマスターを取得したり、スクラムマスター育成プログラムを作ったり、新人研修でスクラムやJIRAの研修をやったり、型化を推進したり、業務特性に応じてはカンバンと併用することもやってきました。

スクラムマスターへの期待値も言語化し、チームの達成やスプリントのPDCA、チームの心理的安全性を高めることなどを定めました。

スクラム運用において学んだ3つのこと

やってみて学んだことは、3つほどあります。

まず1つ目は今やるべきことにフォーカスすることです。Mustでやることにフォーカスして、やるべきタイミングの優先順位をつけることが必要です。

2つ目は、Bizの特徴として社外のステークホルダーが多く、顧客やサプライパートナーなどに依存する不確実性が多いので、これを先につぶしていくことです。DoDや担当者は明確になっているか、ステークホルダーとの認識合わせができているか、このあたりを最初に確認しておくことが必要です。

3つ目は、必ず達成することを目標にすることです。コンサバティブになりがちなスプリント計画ばかりでは、ムーンショットを達成できないので、プロジェクトオーナーやスクラムマスターが連携して対応しています。

見えてきた課題と改善に向けた取り組み

このように取り組んできて現時点では半年くらいが経過してきているのですが、スピード感を高めていく点についてはKPI設計を見直したり、スクラムマスターの育成については、スクラムマスター横串での連携強化やベストプラクティスの共有などを行いました。

TechでLeSSを導入し始めた話がありましたが、Bizでも10人くらいだったチームが3ヶ月で30人とか40人の規模になってくることもあり、これからLeSS的な取り組みをしようとしているのが、Biz側の状況となります。

パネルディスカッション

ここでは以下4つのテーマに関して、パネルディスカッションに参加したTech/Bizのメンバーからのコメントをまとめています。

[1]Biz/Techともにスクラム導入の背景や、当初解決したかった課題感は何か?

正林:

Bizの方で案件のデリバリーをやっていましたが、お客様も大きくなってきて案件が大型化してきています。 そんな中で、業務の全体像を管理したり、進捗を追っていくこと、タイムボックスを切っていく成果管理のところに課題があり、組織ごとのリーダーの力量によって質が異なりました。 プロジェクトマネジメントの手法がいるよねという話も出ておりましたが、JIRAとセットで使える手法がなかった点が課題でした。

高藤:

Techでは不確実に対してどう立ち向かうのかが大きいと思っていましたし、規模や求められるスピード感が変わってきているので。見える化も難しくなり、そこをスッキリできるといいなと思っていました。

[2]スクラムを導入してみた時の難しさや、想定していなかった困難とそれらへの対処方法は?

木岡:

そもそもJIRAに慣れておらず、Biz組織もすごいスピードで組織拡大していく中で、自分自身をマネジメントできる人ばかりではない中でスクラムを運営することが難しかったです。 例えばDoDを適切に設定できないことが挙げられます。 これを設定できるようリーダー層にオーナーを任せ、品質を担保できるようスクラムマスターとしてサポートしていました。

濱口:

LeSS自体の困難さと言っても、2〜3チームくらいの規模でしたし、LeSSの特有のチーム横断的なイベントは最小限で行なっていたので、あまり問題は発生しませんでした。 ただし、スクラム自体の浸透度やストーリーポイントの理解度について(他のチームと比較したときに消化ポイントが低いことを気にしてしまうメンバーがいる等)は、課題として出てきました。

[3]スクラム導入の成果を言語化すると何か?

朱:

TechとBizで共通言語で議論ができることがよかったです。私が所属しているチームでは、原価計算のロジックアップデートをやっているのですが、Biz側で要求を分析していてTech側にシステムに反映するため2つのチームを統合しようとした時に、スクラムがあったのでやりやすかったです。 共通基盤で価値提供がしやすく、スプリントのイベントも一緒にできるので成果の1つかなと感じています。

山下:

BizとTechの同じところとして、不確実性が高いので見積るのが難しいことがあります。よって、完了定義を明確化することをみんなが意識し、開発を着手する前に考えておくことができるのは成果だと思います。 違うところとしては、TechとBizではBizの方がチーム一体になっているように見えるのですが、実はプロダクトは1つなのでTechの方がフロントエンドとバックエンドなどお互いがサポートしあっています。 よって、今回のスクラムの目標から、具体的にブレイクダウンしないとBiz側ではスクラムを進めるのは難しいと思っています。

正林:

全部が見えるようになったことですね。 第三者からみても、見える化は進んだと思います。 JIRAとスクラムをセットで運用していたので、プロジェクト管理がそろいました。 キャディは仮説検証を高速で繰り返しているフェーズの会社なので、同じOperating Systemの上で動かせるようになったのは成果です。

[4]今後スクラムをさらに活用して取り組んでみたいことは何か?

木岡:

Bizでは大きな人数・組織に同時多発的にスクラムを導入したので、各スクラムで独自の運用となっているケースもあります。 そのため、スクラム同士を横串で連携強化したり、標準化を進めることが必要です。 こうすることで、新しく入った人や異動で入ってくる人ともスムーズに入ることができますし、やりづらさが減ると考えています。

佐野:

キャディでは、様々なバックグラウンドの人が集まっており、国内・グローバルで今後さらに展開するためには、とても良いメンバーに恵まれていると思っています。なので、Bizスクラムのベストプラクティスといえばキャディだよね、と言われるようになりたいですね。

濱口:

この4月からキャディでは次の期が始まりますが、3チームがシステム的に連携するようになりますので、LeSSの真果がこれから問われるだろうなと思っています。

高藤:

LeSSの枠組みで活動しているチームと、LeSSの外のチームとの取り組みや改善が今後のテーマになるので、ここをやっていきたいと考えています。

最後に

いかがでしたでしょうか?

Tech組織はもちろんBiz組織も積極的に採用を進めておりますので、まずはカジュアルにもっと話を聞いてみたい!という方は、こちらより申し込んでいただけますと幸いです。

また、イベントに関する情報は、キャディのconnpassがありますので、こちらも登録いただけると嬉しいです。

最後までお読みいただきまして、ありがとうございます。