はじめに
初めまして。Contrea株式会社でPdM兼EMをしている＠hirykawaです。
弊社はインフォームドコンセントを皮切りに医療現場の業務改善を行う「MediOS」というWebサービスを開発しております。
1年前にスクラムを導入した経緯から稼働させるまでの工夫・問題点、その結果までをお話しさせていただければと思います。
スクラム導入を検討している担当者の方に読んでいただけますと幸いです。
なぜスクラムを導入した？
私が入社した時期、副業・本業を含めエンジニアとデザイナーで計7名ほどのメンバーがいました。
まだプロダクトは最初の検証期間であり、その日その日のユーザーの意見や商談の状況等でプロダクトに求めることが変わる環境でした。
メンバーのタスクの進め方としては、アサインされたタスクが終わったタイミングで適宜チームメンバーと相談しながらタスクボードから取れそうなタスクをとり進めていました。
最初の立ち上がりとしては最低限のルールの中で皆で協力しながら業務を進めることはできていました。
しかし、人数も増えてきたことや費用対効果をより明確にするための「常に変わる優先度の定期的な反映」と「短期的な開発計画のステークホルダーへの共有と合意」が求められはじめ、開発スタイルを整える必要があると考えておりました。
その中で「短期間（スプリント)の計画を立て、全員でスプリントゴールを目指し、価値を届けるサイクルを繰り返す」スクラムの導入は現状の状況にピッタリだと考えていました。
どうやって導入した？
社内メンバーの協力の同意をとる
「プランニングで定めたタスクを基本的にやり切る」「開発者はスプリントゴールに集中する」「ステークホルダーにはスプリントレビューに出席いただく」など、スクラムを円滑に進めるには社内の開発メンバー以外の方にも協力していただく必要があります。
フルコミットのエンジニアメンバーには事前に説明して合意をとった後、社内メンバーに向けてスクラムの必要性とメリットを説明し、一緒に開発体制を作っていきたいとコミュニケーションをとりました。
この投稿後エンジニア以外のメンバーもスクラムを知りたい！と声を掛けてくださりました
スクラムの勉強会の実施
開発メンバー含めスクラム実施経験者は自分しかいなかったため、まずスクラムの勉強会を実施しようとなりました。
スクラムに関する参考書や教材はたくさんありますが、私はあえて「スクラムガイド」を皆で読む形で実施しました。
スクラムガイドは聖書とも言われており約１８ページのPDFでとてもシンプルな教材です。
基本的にはどの参考書や教材もこのスクラムガイドを解釈の元としているものが多いと思います。
ただしスクラムガイドは何より読みづらいです。
シンプルであるがゆえ、初めて読むと知らない単語・抽象的な単語のオンパレードです。
読み進めるのが難しいスクラムガイドですが、私は最初の教材として好んでいます。
というのもスクラムには具体的な正解は無いと思っており、「スクラムとは何か？」という問にスクラムガイドの概念を何度も読み合わせながらみんなで意見を出し合って理解しようとし、現状に当てはめていく作業が、スクラムの成功と継続には大事だと考えているからです。
本よりは読むページ数も少ないので、まずやってみようと始めやすいことも良い点ですね。
非エンジニアメンバーはさらに読むのに苦労されてました
スクラムガイドを読み終わった後は、Yahoo! TechBlogのスクラム概要図を見ながら内容を振り返り、復習を行いました。
まずは始めてみる
たくさんインプットすると疲れてしまったりモチベーションの低下の可能性もあるので、最低限のルールブックを読んだら、「とりあえず始めてみよう」としました。
最初に決めることはスプリントの期間の策定です。
スクラムガイドには1ヶ月以内と定められていますが私たちはスプリントを2週間に定めました。
前職では人数も多かったことより1週間ごとに実施していましたが、我々の人数(全体で開発者10人未満)では2週間程度が適切と判断しました。
その次に定めるのはイベントの実施日です。
スプリントの開始日と終了日はプランニングやスプリントレビュー等で多くの時間を使うので、メンバーが集まりやすい曜日に設定することをお勧めします。
また全社の動きに合わせれるとステークホルダーも参加しやすく、営業メンバーの定例の後にスプリントレビューとプランニングを設定できると、開発の優先度に現場の状況も合わせやすくなると思います。
デイリースクラムはスクラムイベントの中でプランニングに次ぐ重要イベントです。
おすすめは業務開始の時間で毎日同じ時間にすることです。同じサイクルにすることで、身体が慣れるようになります。
また道具で必要になるのはスクラムボードですが、JIRAやLinerなどのツールを用意するのではなく、まずはFigjamの付箋でタスク管理を始めました。
既存のスクラム管理ツールは使いこなせるととても便利ですが、スクラム経験者が少ない中では学習コストもかかることから、まずはスクラムの本質を体験するために付箋で管理するスタイルで始めました。
Figjam上でステータスを管理
Figjamの上部にはチームルールを記載に常に目に入る様に
デイリーで時間ができたらスプリントバックログを綺麗にする習慣をみんなでつける
ちゃんとする部分とゆるく始める部分
まず最初に稼働するときに重視したのは、「プランニングでしっかりと計画を立てること」「デイリースクラムでタスクの状況を皆で確認し障壁を解消すること」です。
ステークホルダーにスクラムのメリットを感じてもらうことも大事ですが、スクラムのモチベーションを継続するために、まずは開発者がスクラム導入によって「業務がしやすくなる」「ゴールを達成しやすくなる」と感じてもらうことが大事だと思います。
プランニング時間が長くなったとしても、「タスクを全員で細かくサブタスクまで切り」、「実施が完了すれば期待されるスプリントゴールの達成になるか」までは必ず確認してから完了するようにしました。
デイリースクラムも毎日サブタスクを一つ一つチェックする様にし、障壁がないか、見通しが立っているかを共有するようにしました。
ストーリーの粒度や振り返りの精度などは最初はあまり過度には触れずに進めていきました。
結果として、早い段階で「計画と実行のプロセスの分割におけるタスク遂行のしやすさ」や「お互いの業務理解度を高めることでレビュー時の時間短縮」などさまざまな効果を早い段階で共有することができる様になりました。
スクラムの効果を早くも感じるメンバーも。始めて良かった。
軌道に載せていくために
ステークホルダーとのコミュニケーション
スクラムの導入におけるメリットを開発者以外にも示していくことは重要です。
サイクルをリスペクトしていただくことやアジャイル開発とは何かを理解していただないと、スプリントの途中で開発タスクの再設計を要求されたり、最初からカチッとした仕様とスケジュールを求められるようになります。
その際に大事なのはスプリントレビューの充実です。
特にステークホルダーには「いま求めている成果物が上がってくること」と「以前のスプリントレビューのコメント反映されること」を感じてもらえるように意識しました。
求めている成果物に関しては、「現状の会社の優先度に合わせ開発物を適切に選んで実装」し、「内容がわかりやすく共有されていること」を満たす様に進めました。
「以前のコメントが反映された実装」も短いスパンで意思決定していることから価値を証明できます。
しっかりとスプリントレビューで示した方針は守って開発サイクルを回せる様にし、信頼をチーム全体で獲得できるようにしていきました。
ステークホルダーからの信頼はスクラムチームが十分な権限を得るためにも重要です。
ストーリーポイントの導入
スクラムにおいても、中期的なスケジュールの見積もりはチームに求められます。
そこで我々は見積もりの手法としてストーリーポイントの概念を導入しました。
詳しい内容は以下のAsanaの資料が見やすいと思いますが、単純な人月ではなく、他のタスクと比べた相対的なタスクの難易度・複雑性等でチームメンバー全員でポイント付けを実施します。
このポイントの消費ポイントを毎スプリントで測定しておき、チームが平均で消費できるポイントを予測します。
事前にストーリーをポイント付けしておき、中期的なスケジュールを常にステークホルダーに共有できるようにしておくことでコミュニケーションが取りやすくなります。
スプリントバックログリファインメントの導入
スクラムが成熟していき消化できるタスクの量と人数が増えていくと、プランニングの時間が肥大化していきます。
人間は集中できる時間が限られていることもあり、4時間近くプランニングをすると段々効率が下がっていきます。
そこで、プランニングのない週に時間を区切って、新規で追加されたストーリーを整理する時間を設け、プランニングの負荷を軽減させていきます。
スクラムイベント以外のMTGは入れない
スクラムイベントは十分すぎるほど作業の時間を割いています。
MTGが必要になった場合まずはスクラムイベントのどれかで解消できないか？を考えます。
その中でどうしても解消できない場合にのみ、新たにMTGをセットします。
スクラムマスターの教科書的なYoutube 面白すぎて何度も見てます
弊社で起きたスクラムの問題点
スプリントを何回か繰り返していくと様々な事象が発生していきました。
開発以外の業務を兼任するメンバーの扱い
スクラムガイドには5つの価値基準が書かれておりその中の一つに「集中（Focus）」があります。
「スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。」
しかしスタートアップでは開発以外の業務(営業など他業種)を兼任しているメンバーも多いです。
兼任メンバーの扱いについては、我々もまだ最適解を持っていないですが、一つの方針を取りました。
大事なことは、「ゴールに向けて可能な限り進捗できること」「プランニング時に予測ができること」だと考えております。
まず行ったことは、「兼任のタスクも可視化できるようにする」ということです。
プランニング時に、兼任タスクとして切り出し共有し、開発者として作業できる時間量(キャパシティ)を算出。
キャパシティに応じたタスク量をスプリントバックログに積む。
デイリースクラム時には両方のタスクの進捗を確認して、スプリントゴールが達成できるようにチームでカバーしていきます。
この方法の問題点としては、兼任業務のプランニング時に想定できないタスクが発生することです。
開発業務であれば、プランニングで計画したタスク以外は差し込みNGとすることができますが、兼任業務では開発チーム内での判断はできません。
スプリントゴールが達成できなかった理由が兼任業務の差し込みタスクの場合、レトロスペクティブで改善できないことも多いです。
一般的に兼任は作業効率が大きく下がる[1]ことが知られています。
| 並行作業数 | 各作業の作業時間割合 | スイッチングコストの割合 |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
メンバーがスクラムに集中できる環境とすることが理想ですが、スタートアップにおいては業務の幅の広さを会社としてもキャリアとしても求められることがあるため難しい塩梅であると考えております。
副業メンバーの扱い
副業メンバーは一般的に業務時間が不規則であることと、稼働時間が少ないため、スクラムイベントにおける恩恵を受けづらいです。
また、業務効率のことを考えると副業メンバーがフルコミットメンバーのタスクを完璧に把握している必要もありません。
上記のことから、副業メンバーに関しては週に一度30分ほど時間をとり、タスクの進捗と割り振りを確認する体制としました。
現状、上記の運用で開発業務を進めております。
1年経ってどうだったか
1年が経ちスプリントは２３回目に突入しました。
スクラムに慣れてきた途中からNotionを利用したチケットの管理を行っています。
スクラムは必ず生産性が上がる様な劇薬ではないですが、以前掲げた「常に変わる優先度の定期的な反映」と「短期的な開発計画のステークホルダーへの共有と合意」に適した開発スタイルは提供できるようになったかなと思います。
会社全体としてもサイクルが身についており、「あの要件は次のスプリントに乗るの？」「前回のスプリントレビューの〇〇についてなんですけど」など、プロダクトへの要求整理やスケジュールに関しても会話しやすくなったと感じています。
またスクラムを介して自己管理のスキルが備わったメンバーも多く、計画と実行と振り返りの短いサイクルを繰り返すことのメリットを感じています。
スクラムは特にスタートアップに向いていると思います。
中期長期のカッチリとしたスケジュールよりも、現状の状況を踏まえた柔軟な意思決定とスピードが求められるためです。
また、外部のメンバーを巻き込みやすいことと、開発チームに十分な権限が与えられる可能性が高いことからスクラムを軌道にも乗せやすいと思います。
みなさまも Let's Scrum!
最後に
Contreaでは一緒にMediOSの開発を進めてくださる仲間を募集しています。
エンジニアであってもユーザーの現場に行き課題を見つけプロダクト作りをしていく環境を、「面白い」と思っていただけるのならばベストマッチだと思います。
転職希望がない状態で話を聞きたい等のみでも問題ありません。ぜひお話しさせてください！
他記事の宣伝
-
新規事業の立ち上げを振り返る
https://note.com/hirykawa_/n/n28038511d9fe -
素人経営者の「3年半のしくじった経営、うまくいった経営」
https://note.com/kazubou21/n/n9e60ae4d0d16 -
エンジニアだからできる組織の文化作り
https://note.com/amu__prog/n/n71a3e029d6e9?from=notice -
エンジニアインターンのインタビュー記事
https://www.wantedly.com/companies/company_6229577/post_articles/866518 -
現場を「経験しに行く」ということ
https://note.com/_hidehiro/n/ne033679e5868
-
ワインバーグのシステム思考法より参照。 ↩︎
インフォームドコンセント支援システム「MediOS」を開発するContreaのProductチームのブログです。 様々なバックグラウンドをもつメンバーが所属し、医療の未来を作る仕事をしております。
Discussion