はじめに
Photoruction Advent Calendar 2022の5日目の記事です！
アドカレ運営委員長こと、CREチームの田中です！
現在、CRE(Customer Reliability Engineering)のリーダーをやっていますが、
少し前まで、スクラムチームでスクラムマスターをやっていました。
せっかく、認定スクラムマスターを取得して、スクラム開発を取り組んでいたので、いい機会なので、その時の棚卸をしようと思います。(認定スクラムマスターも取得したしね。。)
スクラム開発ってなに？
その中でも、スクラム開発は導入のしやすさから、おそらく一番ポピュラーな手法です。
スクラムは、ラグビー用語で、肩を組んで押し込んでいくプレーのことです。
イメージはこんな感じ。
「スクラム開発」という文脈では、チームワーク、コミュニケーションを重視し、
シンプルなロールやルールに基づいて、アジャイル開発の理念の実現を達成しようとするフレームワークを意味します。
アジャイル開発の理念については、アジャイルソフトウェア宣言が有名なので、気になる方は、一読してみるといいかもしれません。
https://agilemanifesto.org/iso/ja/manifesto.html
なんでアジャイル(スクラム)開発ってできたの？
アジャイル開発という考え方が生まれたのは、約20年前(2001年がアジャイル元年らしい)。
それまでは、
と、一定の開発期間を設けて、一度にまとめてドン！とリリースまで突き進むウォーターフォール開発が主流でした(もちろん今でも全然採用されている)。
ウォーターフォール開発は、開発に入る前段階で、完璧に要件定義や仕様が固まった状態であることが前提となる開発なのですが、
これだと、どこかの工程で問題発生した際に、軌道修正がしづらく、リリース計画の大幅な見直しが発生しやすいです。
VUCA(Volatility: 変動性, Uncertainty: 不確実性, Complexity: 複雑性, Ambiguity: 曖昧性 の頭文字をとった言葉)という言葉が巷に広がって久しい昨今、ビジネス環境は予測不可能な状況になり、不確実性を極めています。
アジャイル開発は、こうした不確実性というリスクを、「小さく」開発フローを回すことで、そのリスクに対応していこうという考えから生ました。
つまり、アジャイル開発とは、
大きな「分からない」から、小さな「分かる」を短期間の積み上げていくことで、
小さな「分からない」に限定していくことを目指す開発です。
上記はあくまで、私の解釈を言葉にしたものですが、こう捉えていくと、
エンジニアリング以外のビジネスシーンにも、有用で、何かしらのエッセンスになりうるテーマかもしれません。
認定スクラムマスター研修で学んだこと
認定スクラムマスターの講習で、個人的に面白いと思ったことがいくつかあります。
スクラムの具体的な仕組みに関して知りたい方は、スクラムガイドブック(日本語版)を見てもらうのがいいかと思いますので、そちらをチェックしてみてください。ここでは長くなるので割愛させていただきますmm
スクラムは楽しんだもん勝ち
大前提として、スクラムはゲームだ。
スクラムは開発チームとステークホルダーの幸福度を追求するゲームでシンプルなフレームワークだよ。
というのが、講習の際、講師の方が仰っていました。
(研修の資料の一部から抜粋)
チームとしてワークさせ、チームメンバーが楽しんで開発に臨める組織状態にするよう、サポートするのが、スクラムマスターの役割ということです。
その際、「心理的安全性」を高めることが重要であると、述べられていました。
ハーバードビジネスレビューでは、なんでも言い合えるチーム作りをするために、心理的安全性の重要性が説かれています。
高い心理的安全性であれば、イノベーションを生み出すような高いパフォーマンスを引き出しますが、
低い心理的安全性の状態では、自己防衛を目的とする恐怖反応を引き出してしまいます。
具体的には、チームメンバーが質問をしたり、間違いを認めたり、アイデアを模索したり、現状に挑戦するようなことをやめてしまいます。それは、アジャイルではないです。
スクラムはイベントがたくさんあり、必然的にコミュニケーション量が多くなります。
その際、心理的安全性を担保するように、特に初期では、気をつける必要があります。
スクラムの前提のお話
次に、日本でスクラム開発を行う際、日本と欧米のエンジニアのスキルの前提の違いについて念頭におかないといけないな〜と
講習中に感じた事柄です。
スクラム開発の目標に、「自己組織化」というワードがあります。
自己組織化とは、誰かからの指示に従う形ではなく、チームメンバーがチームとして最適な方法を判断し行動していく状態です。
何か問題にぶち当たった時に、チームで解決できるスキルがある(あるいは、スキルを獲得できる方法を知っている)。
欧米のエンジニアはフルスタックが前提(フロントサイドもサーバーサイドもアプリ側も対応できる)で、
職能が分化されている日本のエンジニアとは前提が異なります。
実際、研修中、質問で、どうそのギャップを超えていけるかと質問があり、その回答としては、
Mob(モブプロプログラミング)がおすすめだとの話でした。
ここで、あえてこの話題に触れたのは、前提が異なるから、スクラムが実現できないという話ではなく、
スクラムの体現するために、前提の違いを念頭に置くべきという考えからです。
実際、そのギャップを乗り越え、「自己組織化」できている組織を作るのはめちゃくちゃハードなことだと思われます(どうやるんですかね。。)
衝撃の事実
海外事例のお話を聞いていると、海外の先進的なアジャイル企業では最早スクラムが使われていないらしい。。
具体的には、今話題のイーロンマスクがCEOを務める、テスラやスペースXなどです。
スクラム開発を極めた結果、スクラムチームは、自己組織化ができており、スクラムマスターが必要なくなります(1人1人がスクラムマスターになっている)。AIに代替されているようです。
Twitterで、リモートワークを撤廃することだったり、小規模チームを作っていくみたいなことを宣言しているのは、
テスラやスペースXのスクラム開発の経験からなんだろうな〜と邪推してます。
スクラム開発で試したこと
半年と少しほど、スクラムマスターとして、スクラムに取り組みました。
施策は色々行いましたが、チームとして大きく意思決定したのは3点かなと。
試したこと
- モブプロをやってみた
- ベロシティの算出
- リファインメントカフェの実施
モブプロに関して
チームの自己組織化を目指すに当たって、Mobしかない！ということを講習で聞いたので、すぐに取り入れてみました。
ただ、チームは、Webエンジニアだけでなく、iOSエンジニア、Androidエンジニア含めて、やってみよう！みたいな導入の仕方をしてしまい、そこは現実的ではなかったよねってことで、そこは諦めました。
適宜問題に当たったら、Google Meetやslackのハドルを繋げて、コミュニケーションを取るような形で進めていきました。
コミュニケーションの促進や心理的安全性の向上という意味では、上手くいった。
自己組織化を目指すという意味では、成果不十分みたいな総括かなと思います。
ベロシティの算出
複雑性に対して対応するために、チームとしての生産性を見える化する必要があります。
ベロシティとは、チームが作業を進めるための生産性を意味します。
ベロシティは、開発完了見込みの予測や、チームの成長を把握するために役立ちます。
プロジェクトに対し、ストーリーポイント(作業完了に必要な見積もりの尺度)を振り、ベロシティの算出してみようと試みました。
結論から言うと、これは上手く回りそうになく、やらないという意思決定をしました。
というのも、スクラムチームが9名で、Webエンジニア、iOSエンジニア、Androidエンジニアが入り混じっており、１つのプロジェクトの開発というより、それぞれのエンジニアが異なる案件を抱えるという状況でした。
となると、ベロシティ(チームとしての生産性)を算出したとして、その値にそれほどの価値が生まれないだろうということ。
プロジェクトごとにチームとして、ストーリーポイントを振るわけですが、技術領域が異なると、多く見積もってしまうという問題がありました。
まぁ、WebならWebのエンジニアだけで割り振ればいいのはいいのですが、ベロシティという値に集約されることを考えると、歪な数値になるということで、諦めました。今振り返ってみても、前提条件的に難しい気がします。
リファインメントカフェ
リファインメント(洗練という意味)はスクラム内のイベントではなく、アクティビティ(必要であれば実施する)であると、講習で聞いたので、こちらもすぐに取り入れました。
これはすごく良かったです。
デイリースクラムを朝やっていて、その直後に、仕様のすり合わせや確認が必要であれば、開催みたいな感じで頻繁に行っていました。
効果としては、仕様の変更や出戻りのコストは減ったと思います。
また、リファインメントカフェのおかげかは微妙ですが、リファインメントカフェを始めてから、ちょっとした確認を取る機会が増えた気がします。
まとめ
透明性→検査→適応のサイクルを最大化するという観点から見たら、ベロシティ計測を捨てているので、正しいスクラムの運用ではなかったかもしれないです。
ただ、総括としては、雰囲気良く開発ができたので、悪くはなかったと思います。
むしろ、チームビルディングの観点では、うまく機能していました。
チーム再編の際には、メンバーみんな別れを惜しんだくらいですし(別に社内にいるんですけどねw)。
スクラムマスターとして、どこまで貢献できたかと問われると自信はないですが、一定の成功体験は積めたので、
これを糧に今のチームでもスクラムのエッセンスを取り入れていきます！(次はそんな記事を書きます！！)
株式会社フォトラクションでは一緒に働く仲間を募集しています
