こんにちは！
クラウドテック開発チームで駆け出しのスクラムマスターをやっている西村です。
2018年の10月に入社をして現在4年目になりますが、このブログに投稿するのは初めてになりますので、お手柔らかにお願いします。
クラウドテックは、2015年4月から始まったハイクラスなフリーランスのIT・WEBエンジニアやデザイナーに特化したマッチングサポートサービスです。https://crowdtech.jp/
このクラウドテックの開発を行っているチームで、今年の7月から 「スクラム」 を取り入れました。
スクラムでの開発が未経験のチームで、どのように取り入れていったのか、取り入れたことによる変化などをお伝えしようと思います。
目次
- はじめに
- 前提：どんなチーム構成だったの？
- きっかけ：そもそもなんで「スクラム」を始めたの？
- 準備：まずは何やったの？
- 実施：チームとしての変化
- 結果：すべて解決ではないが前進は出来ている
- 振り返り：スクラムは課題解決の答えではない
- まとめ
はじめに
この記事では、スクラムでの開発が未経験のチームで、どのように取り入れていったのか
取り入れたことによる変化などをお伝えしようと思っておりますので、
- スクラムに興味あるけど実践の経験がないし、どうすればいいかわからない
- なんとなくスクラムっぽい運用をしているけど、ちゃんと運用してみたい
- チームに課題があるのは認識しているけど、解決のアプローチが出来ていない
等のお悩みを持ってる方は、参考になるかもしれません。
なにより、私が所属するチームが 「同じ悩み」 を持っていました。
それを解決するために何をしたのか、どんな変化があったのかお伝えしていこうと思います。
前提：どんなチーム構成だったの？
クラウドテック開発チームはマネージャーを先頭に
- マネージャー（Mgr）：1名
- プロダクトマネージャー（PdM）：1名
- プロダクトオーナー（PO）：1名
- エンジニア：4名
- デザイナー：1名
の8名と
- マーケとか営業支援ツール管理、他チームのヘルプなど（私）
の全9名で1つのチームとなっていました。
私だけ切り出したのは、私の主業務がプロダクト開発ではなく、周辺サービスやビジネスサイドとの連携で動くことが多かったからです。
つまり、「プロダクト自体は開発していない」という形だったので、意図的に分けています。
きっかけ：そもそもなんで「スクラム」を始めたの？
もともと、チーム内では「スクラムっぽいやり方」で開発 をしていました。
ですが、これを実施しているのは「エンジニア」のみで、チームとして行っているものではありませんでした。
ただチームでは、「プランニング」と「振り返り」を毎週行っていたので、やんわりスプリントっぽく回していたので
というような状況でした。
そんな中、半期の振り返りを行っている中で
- 多くのタスクが属人化されている
- ちゃんとスクラムが出来ていない
- そもそもちゃんと理解しているわけじゃない
- 現状POへの負荷が高いと感じている
- チームのパフォーマンスを測定出来てない
などの課題が出てきたので、
チーム内で 「しっかりとスクラムを取り入れよう」 という合意を取り、4月から10月までの半年間、 「とりあえずトライしてみよう」 という形になりました。
準備：まずは何やったの？
スクラムガイドを読み、現状との差を認識する
一番最初は 「そもそもスクラムってなんだろう？」 という部分を、チームで認識を揃えるところからスタートしました。
私を含め、スクラムのことを「ちゃんと勉強した」というチームメンバーが少なく、共通認識が作れていない状態でした。
最初はこれを脱却するために
- スクラムガイドを読んだ上で、感想や自分なりの考え方の共有
- わからない部分などを共有し、チームでの認識を合わせる
- チームとして、スクラムチーム・スクラムマスターの在り方の認識を揃える
- 今のチームに足りていない物（スクラムイベントや成果物）は何かを洗い出す
ということを行いました。
結果、チームとして
などの課題が出てきました。
スクラムマスターを決めて、チームを「スクラム」の流れに乗せる
次に行ったのは 「スクラムマスターを選出する」 ということでした。
スクラムを始めるにあたって
- 「スクラムマスターは開発者やPOを兼務すべきではない」 という事
- 最初はチームの在り方が変わって、少なからずパフォーマンスの低下が起きると想定
という懸念があり、「開発者からの選出は難しい」という判断をして、私が「すべての要件を満たせるポジションにいた」という事で選出されました。
これにより、チームの構成が
- スクラムチーム外
- マネージャー（Mgr）：1名
- プロダクトマネージャー（PdM）：1名
- スクラムチーム
- プロダクトオーナー（PO）：1名
- スクラムマスター：1名
- 開発者（エンジニア・デザイナー）：5名
という構成になりました。
Mgrはチーム全体のマネジメント、PdMは「ステークホルダー」という立ち位置チームに関わってもらう事になりました。
そして、このタイミングで 「ポジションごとの担う役割」 というのも明文化しました。
今までは 「とりあえず全部POに聞く」というの止めることが出来る ようになって
「これはPOに聞く」「これはスクラムマスターの仕事」などの役割分担が出来る ようになりました。
ドキュメントを準備して、すぐに読み返せる状態にする
スクラムガイドを読んで、チーム内で揃えた認識をベースに
をすべてドキュメント化して、全員が常に確認出来る状態を作りました。
特に新設するものに関しては、チームの意見を取り入れて、その都度変更を加えるという事を実施しました。
下記画像は一部ですが、スクラムに関連して追加したMTGや、今までやっていたMTG・スプリントの進め方をそれぞれドキュメント化しました。
スクラムガイドをチームで読み始めてから、およそ1ヶ月ほどで 「スクラムを始める為の準備」 を終わらせて、実施をしました。
ビジネスサイドにもデンタツする
そして特に重要視したのが 「ビジネスサイドのメンバーにもデンタツをする」 ということです。
クラウドテックは、ハイクラスなフリーランスのIT・WEBエンジニアやデザイナーに特化したマッチングサポートサービスです。
開発チーム以外にも営業・キャリアサポーター・パートナーサクセスなど、多くのメンバーと一緒に作っているプロダクトになります。
開発チームで起きる変化を伝えることで、チーム内外での認識を合わせたり、協力してもらえる環境を作るという点で、とても重要な部分でした。
ビジネスサイドのメンバーに伝える際には
なぜの部分をしっかり伝える 事と、導入することで 何が変わるのか の部分を重点的に伝えるのが良いかと思います。
※画像はビジネスサイドに伝える時に使った資料の一部
実施：チームとしての変化
まずは3ヶ月間運用をしてみて、良かった点や課題点などをその都度出して、チームで議論しながら進めていくという形を取りました。
とりあえずやってみよう精神という感じですね。
個人的な解釈も含みますが、大きく3つの変化が見えたかなと思っています。
1. チーム運営自体の課題が発見しやすく、自分事にしやすい
最初は共通の認識がなかったので、大きな課題は捉えられても、細かい課題までは目を向けられていませんでした。
正確には 「個人では認識していたが、チームでは認識をしていなかった」 という状態です。
これが解消できたので、課題が上がった時に他のメンバーからも意見を聞きやすく
チーム全体の課題とその改善案の認識が取りやすく、チーム運営の改善自体も素早く回すことが出来るようになりました。
2. 改善までの時間短縮と新たな課題解決が出来るようになった
新たにスプリントレビューを設けたことで、ビジネスサイドとの連携が今までよりも強化されました。
今までは成果物はリリース後に報告をしていたので、フィードバックをもらってから改善するまで
（他のタスクなどの兼ね合いで）どうしても時間がかかってしまう場面がありました。
スプリントレビューを設けて、成果物のリリース前にフィードバックを貰うことで、
直ぐに改善に取りかかれて、双方が納得した状態でリリースが出来るようになりました。
また、スプリントレビュー中に出た課題も、その場で開発者も含めて解決策を検討することが出来るようになり
より相手の要望に沿った内容を盛り込んだ上でリリースも行えるようになりました。
3. 「新しいトライ」が作れるようになった
スクラム前までは、「A（フロントエンド）さんはページのリニューアル、B（バックエンド）さんはこの機能の追加を」といったように
誰が担当するかを事前に決めた上で、タスクアサインを行っていました。
この状態だと、「Aさんが居なくなったらフロント側の実装が進まない」等の属人化も発生してしまいます。
そこで、タスクを決める際（プランニング時）は 「誰がどのタスクとっても良い」 という形に変えました。
実際まだまだ属人化している部分もありますが、「Bさんがフロントにトライしたいからフロント系のタスクを取っていく」という流れも実際に生まれたので
メンバーが主体的に「新しいトライ」を行う環境を作ることが出来た と解釈しています。
結果：すべて解決ではないが前進は出来ている
半期の振り返りの際に出てきた課題である
- 多くのタスクが属人化されている
- ちゃんとスクラムが出来ていない
- そもそもちゃんと理解しているわけじゃない
- 現状POへの負荷が高いと感じている
- チームのパフォーマンスを測定出来てない
の項目が実際どのぐらい解決できているかを見ていくと
- 多くのタスクが属人化されている： 改善の余地あり
- ある程度の属人化は解消できたが、まだ解消できる余地がある
- ちゃんとスクラムが出来ていない： それなりに出来た
- チーム内で「どのように運用していくか」の認識を揃えられて、実施できている
- そもそもちゃんと理解しているわけじゃない： それなりに出来た
- スクラムガイドを読み、チーム内の認識を揃えることが出来た
- 認識を揃えた上でチームに関する様々な課題が判断できるようになった
- 現状POへの負荷が高いと感じている： 改善の余地あり
- チームのパフォーマンスを測定出来てない： 失敗の後改善中
- 一度チームで出した方法で実施は出来たが、測定できるものではなかった
- すでにこの部分は改善策をチームで考えて実施中
と言った感じになっています。
「スクラムへの理解」という点でいえば、全員が共通の認識を揃えられたので「それなり出来た」と判断しています。
「それなり」の意図としては、「スクラムガイドはこうだけど、実際にはどうしていくのがいいのかな？」といった部分もあり
まだまだ習熟度は上げていけるのかなーと思っているので、ここは引き続きスクラムマスター筆頭に考えていく部分です。
また、「チームのパフォーマンスを測定出来てない」という部分は3ヶ月実施してみて
「これだとあまり意味をなしていないよね」という事もあり、根本から見直しをして絶賛改善中です。
（この話はまたどこかの機会に・・・）
簡単にまとめてみると 「全部解決出来たわけではないけど前進は出来ているし、これからどんどん改善していく」 といった所です。
振り返り：スクラムは 課題解決の答えではない
結果部分にも書きましたが、スクラムを導入したからと言って「全てが解決出来たわけじゃない」です。
「そりゃそうだよね」という感じではありますが、スクラムは 「何かを解決するための特効薬ではない」 ということです。
私自身「スクラムってすごそうだから、導入したら解決するのでは？」なんて最初は思っていましたが、そんな事はありません。
ですが、スクラムを導入することで 「チームで課題に気がついて、チームで解決するための土台」 が出来るようになったと解釈しています。
これが出来ることで、課題解決をしていって、チーム全体のパフォーマンスが上がったり、よりチームが働きやすい環境を作れるようになるなと感じています。
「チームも1つのプロダクト」 なので、これからもチーム全体が納得して進められるように、スクラムマスターを頑張っていこうと思ってます。
まとめ
およそ4ヶ月ほどのチーム状況をまとめてみましたが、いかがだったでしょうか？
実際にスクラムを試して思ったことは 「やるととても難しいが、良い変化も感じられるし継続できそう」 というような印象です。
私自身しっかりとスクラムを行った経験もなかったですし、もちろんスクラムマスターも初めての経験でした。
ですが、チームメンバーの協力も得ながら、少しずつ前進出来ているなーと感じる場面が多かったです。
スクラムもトライ&エラーを沢山繰り返しながら、アップデートしていく物だと思いますので
チームによって在り方は様々だと思いますが、参考になれば嬉しいです。
We're hiring!
株式会社クラウドワークスではクラウドテックのエンジニアも募集しています。
労働市場のバイアスを取り除き、選択肢の最大化を図る のビジョンに共感いただける方は是非ご応募ください。
https://www.wantedly.com/projects/676499
