見出し画像

LeSS(大規模スクラム)を導入してみた話

lambda_funtaro

エンジニアとしてHERPに入社して2~3ヶ月ぐらい経ったころジョブチェンジをしてスクラムマスターとしてLeSSを導入してみて半年たったお話。

感じたこと、思ったこと、良かった点、悪かった点などを振り返りつつそんなにまとめずに書き連ねたものである。

サマる

実質この記事はエッセーみたいなものなのでサマれてないが、

・目的志向で人を巻き込む
・LeSSの思想を目的として利用すると言語化されてて楽でいいぞ
・LeSS導入だけでは良いプロダクトは作れない

背景

私の働いてる会社は日本の採用2.0を実現するというミッションを掲げていて、採用領域においてイノベーションを起こすことを狙っている、俗に言うスタートアップと呼ばれる企業である。

LeSS導入前の開発体制については入社してすぐにLeSSを導入したこともあり深く理解はしていないが、大雑把に表現すると プロジェクト制 × ウォーターフォール気味 であり、プロジェクトの流れは下記のような雰囲気だったと一開発者としては思っている。

・謎の組織がプロジェクトを発足(ここについては知らないだけ)
・上流が機能の要件定義をする
・それを元にアサインされた開発者が開発する

お気持ち

この開発フローがあらゆる状況で悪いと言うつもりはないが、自分がしたい開発、会社のポジショニングや価値観からはズレていると思った。

個人としてどう開発していきたいか
・自分がなんの役に立っているかを理解したい
・仕事は人生の大部分を占めてしまうんだから毎日楽しくお仕事したい

会社としてどう開発すべきだと思っているか
・スタートアップ企業柄、顧客が言っている要求や僕らが考える機能がフィットするかは不確かなので確かめながら開発したほうが良い
・Haskell推し企業として、他の技術とは違い実証検証が少ない技術を利用することが多く、その部分に関しても確かめながら開発をした方が良い

代表が言ってたコト
・「開発部とそれ以外の部の溝が大きくてそれを埋めたいんだよね〜」
・　-> わかる〜のお気持ち

LeSSのからのアンサーソング

LeSSはそもそもスクラム開発のでかい版であり、スクラム開発はアジャイル開発の手法の一つで、それらの価値や効果的な適用範囲について考えることで目指すべき方向へどのようにLeSSが効果的だと思っているかを書いてみる。

個人としてどう開発していきたいかのアンサー

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
(中略)
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

出典: アジャイル宣言の背後にある原則

信頼関係や自分たちのやり方を自分たちで最適に調整するなどの前提が掲げられていて、楽しくお仕事をしやすい。

確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
(中略)
確約（コミットメント）：スプリントゴール
スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促すものでもある。

出典: スクラムガイド

開発は常に目的が語られており、何の役に立っているかが明確。

会社としてどう開発すべきかのアンサー

スクラムの理論
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。

出典: スクラムガイド

ビジネス的、技術的に予測が不確かな領域では、スクラムの理論の基である経験主義によって予測可能性を最適化してリスクを制御するできるとスクラムでは言っている。

開発部とそれ以外の部の溝が大きくてそれを埋めたいんだよね〜のアンサー

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

出典: アジャイル宣言の背後にある原則

こんな感じでLeSSと向かうべき方向がなんとな〜く寄り添っていることがわかってくれたら嬉しい。

あと標準なくして改善なしって言葉があり、フレームワークを導入して標準を作って、それに対して改善や振り返りをしたいって話もあったりしたので、LeSSってフレームワークはぴったりだった。

それに、スクラム採用を推し進めている会社だしスクラム開発やっとくか？みたいな雑なノリもあった。

実際のやり方

標準なくして改善なしの精神にあたって、まずはLeSSを忠実に守ってみているので、実際にどう回しているかという点については書籍やインターネットの情報を参考にしてもらいたい。

目的が大事

導入において1度失敗をした。

失敗時は、プロセスのルールの浸透を重要視した。
LeSSの知識をプロセスルール的な部分と思想的な部分に分割して考え、まず普段の開発フローをLeSSのプロセスルールに則ってやってみた。

これが失敗だった原因のようにおもう。
プロセスやルールの浸透を重視していたため、LeSSのルールに不要なまでに縛られて思うような開発ができなかった。当時はみんなで絶対的な答えを求めてLeSSやスクラムの書籍を漁ったりしていたと思う。
しかしLeSSやスクラムのルールに絶対的な答えはなかった。

The LeSS rules define the LeSS Framework. But the rules are minimalistic and do not give answers as to how best to apply LeSS in your specific context. The LeSS principles provide the basis for making those decisions.

出典: Large Scale Scrum(LeSS) - https://less.works/jp/less/principles/index
DeepLによる翻訳

LeSSルールは、LeSSフレームワークを定義するものです。しかし、ルールは最小限のものであり、あなたの特定の状況でLeSSをどのように適用するのがベストなのかという答えを与えるものではありません。LeSSの原則は、それらの決定を行うための基礎を提供します。

(DeepLの翻訳すごいな...)

そもそもフレームワークというものは絶対的な答えを提供なんぞしてくれないのかもしれないが、LeSSに関してはそんなものは無いちゃんと書いてあった。

失敗後、アジャイルの思想的な部分からスクラムの思想、LeSSの思想までをおさらいして、LeSSフレームワークの目的を開発チームに繰り返し共有し、その目的に基づいたフィードバックなどをしていった結果、LeSS導入の狙いが達成されつつあるように思う。

ちなみにLeSSを導入失敗後に認定スクラムマスター(CSM®)の研修を受け、資格を取得した。
研修の内容は考え方や思想的な部分が多く、そこから多くの示唆をもらう事で導入に成功した部分が大きいと思う。

研修のコストに関しては金(20万円ぐらい)と1週間の研修期間を会社からいただいた。
スタートアップ企業で金も時間もなくて大変なのにありがたい。

良かった点

実際の声

・小さく作るをやっていくのがよかった
・ユーザーストーリーをもとにするのがよかった
・型があると改善がまわしやすい
・上流と下流が分かれなくなったのが良い
・開発者が自律してユーザーヒアリングをしたり、顧客への提供価値について考えるようになった
・1週間サイクルが良い

実際の声を聞きつつ自分の思った事も混ぜて理由を書いていくと...

機能開発のリードタイムが短くなった
LeSSでは経験を重視しており、予測しにくいものに関してはまず動くものを作り提供し、市場の反応などを見て検証することに一貫して重きを置いていて、フレームワーク的にもその思想が反映されている。
具体的にはスプリント区切りでの開発や推奨スプリント期間が1週間であったりするため、機能開発のリードタイムが短くなって不確実な領域での開発チームとしては良い恩恵を受けれた。

開発チームとそれ以外の部の溝が小さくなった
スプリントレビュー全社向けに行っていて、毎週何を開発したかを全社員に向けて公開して、フィードバックを集めている。
それによって開発チームとその他のチームのコミュニケーションが以前より活発になり、相互的に良い影響を与え合っているように思う。

開発進捗や開発ロードマップがよりカスタマーサクセスや営業に伝わって営業やサポートがしやすくなったり、逆に営業やカスタマーサクセスのフィードバックが開発に生かせるようになった。

なんのための開発かわかりやすくなった
スクラムではステークホルダーの要求を開発するにあたってプロダクトバックログアイテム(以下PBI)というものを作成するのだが、Howを書かずにWhatを書くルールがあり、ソリューションについては開発者と相談して決定することになる。これによってWhatを達成するための必要最小限のコストで開発を実現できるともに、なんのための開発かがより分かりやすくなって、個人としてどう開発していきたいかの所が達成された。

開発チームが重要視すべき価値や思想が言語化されている
LeSSによって開発チームが重要視する価値や思想が言語化されていて、すぐに参照できる状態であるためチームで共有しやすく、プロセスや働き方の改善がしやすい。
営業などは良しとするものとして分かりやすく売り上げなどの数値があるが、開発チームがわかりやすく良しと置けるものって中々ないと思っている。
その中で一定信頼できるアジャイルの思想を利用して一旦これを良しとして動けるのは便利な道具だなと思った。

良かった点は探そうと思ったら一生出てくるので、この辺にして...

悪い点

実際の声

・小さく作ることそのものが正義となってしまっており、不要なステップや検証が挟まっていることがありそう
・まぁでもなんともいえないし、思考プロセスが簡略化して思考停止で作業できること自体は余計な議論を避けられて良いのかもしれない
・チームが良い意味なのか悪い意味なのか機能してない
・SREタスクがやりにくい

実際の声を聞きつつ自分の思った事も混ぜて理由を書いていくと...

思考停止で小さく作ることはデメリットもある
技術的にも市場的にも不確実性の高い領域のため、小さく作って市場に素早く出すことを重要な価値としておいているが、確実性が高いが工数の大きい開発がしにくくなってしまう。
そのような場合には技術、市場どちらの確実性が高いのかを見極め、それらに応じて適切なプロセスを選ぶ方がよさそう。

価値が示しにくいものの取り扱いが難しい
スクラムでは待ち行列理論を利用して、価値とコストで優先順位を一意につけることでプロセスの無駄を省く。しかし、プロダクト全体の統一感を持たせるために工数をかけてでもやるべきデザインや、プロダクトの信頼性を上げるためのインフラ整備系タスクなど、中長期に効いてくるような価値を持つ開発を取り扱う際に、ビジネス的価値を持つものとの比較で優先順位を一意につけることが難しい。どうやら一般には完了の定義で担保するようですが。

チームの扱いが難しい
LeSSではクロスファンクショナルなチームがプロダクト全体を把握した上で、どのチームもどんな開発ができるような状態になっていることが望ましいとされている。
しかし、弊社でもそうだがチームによって技術的にはなんでも開発できるのだがドメイン知識の偏りによって開発ができないなどの状況が生まれてきている。

他社のLeSS導入事例を見ても、追うKPIによってチーム分割がなされていたりなど、チームが知るべき知識のスコープがある程度狭められていることが多いので、今後はそのようなアレンジも参考にしようと思っている。

LeSSだけでは良いプロダクトは作れない

上記の悪い点を改善するのはそれはそうとして、今後のやっていきについても書く。

良いプロダクトを開発していくにあたっては、豊かな仮説を素早く正しく検証することが大切だと思っている。

LeSSを導入し半年以上が経過して、仮説を素早く市場に出すプロセスや意識が根付いてきた。しかし素早く検証することが出来てきたが故に豊かな仮説構築やそれに基づいた確からしい検証が課題として浮き彫りになってきた。

それもそのはずで、LeSSでは素早く仮説検証をする土台を作ってくれるがどんな仮説を立てたらいいかや検証方法については教えてくれないのだから...

現在はここを課題としてPOと協力し組織能力の改善を進めているので坂田先生の次回作に乞うご期待ください！

あとそういえば全方位で採用もしてるんでリンク置いときます。
もっとカジュアルに様子を聞きたかったらTwitterのDMとかでもヨシ！


この記事が気に入ったらサポートをしてみませんか？