こんにちは。株式会社ペライチの執行役員開発部長の佐藤です。
ペライチではスクラムで開発しています。
ペライチのスクラム開発は、かれこれ 3、4 年前に 1 つのスクラムチームから始めました。
幸いなことに、チームも機能ごと 4 つに拡大しそれなりに長い期間、スクラム開発を続けられています。
今回はスクラムを始めた導入機から拡大期までの変遷と振り返りを記事にしてみようと思います。
※この記事はペライチの通ってきたスクラムの歴史を振り返る n=1 のストーリーを記載します。スクラムはこうすべき！というわけでなく、各社ごとのスクラムのスタイルがあって良いと考えている上での記事ということをご承知おきいただけると幸いです。
スクラム導入以前
導入以前は issue ベースで開発案件をエンジニアに都度アサインする形式の開発をしており、CTO から各エンジニアが直接作業指示を受けているような形式を取っていました。
フルタイムの社員も 2,3 名しかおらず、週 2~4 日稼働の業務委託のメンバーが数名といった体制でした。
チームの状況の特徴としては以下です。
- チームメンバー全員がそろう時間帯が少ない
- チームメンバーの多くに稼働のばらつきがある
このような状況だと、スクラムガイドで定義されているような、スプリントプランニングや、レトロスペクティブをやるには時間的な負担や調整の難易度が高くなります。
たとえば以下の状況が発生します。
- 稼働日数が少ないメンバーの直接的な作業時間の多くがスクラムのイベントに吸収される。
(1 週間スプリントで稼働日 2 日で半日スクラムのイベントやっていると 25%作業時間が奪われる。) - 業務委託メンバーの稼働曜日が変わるなど、メンバー全員のスケジュール組み直しが頻発する。
そのためスクラムを導入する以前に issue ベースの開発していたのは一定合理性はあると思う一方、どうしても以下のような課題も発生します。
- issue ベースでエンジニアにタスクを渡すので、複数 issue にまたがるような規模の大きい開発や不確実性の高い開発がしづらい。
- チーム組成していないので、開発内容を学習し次の開発に活かすような PDCA が働きにくい。
(メンバー同士が仲よい悪いといった話ではなく組織てきな機能がないという話です。あしからず。。)
このときのペライチはホームページ作成機能の保守改善系の開発がメインでしたが、長期的にはホームページ作成の枠を超えた新機能の提供を進めたい時期でした。
スクラム導入期
新機能開発を行いたいということで、スクラムチームを組んだ開発にチャレンジしました。
当時開発部の規模としては社員、業務委託合わせて 8,9 名前後で、その内 5 名程度をスクラムチームに切り出してスクラムチームを組みました。
社内にスクラムの経験者がいるわけでもなく、自分たちなりにスクラムガイドを解釈、模索しながらのスタートでした。
スクラム導入して発生した問題
正直に申し上げてスタート当初は以下のようなさまざまな問題も発生しました。
問題1. 今までの開発スタイルに比較して会議時間が増えることの現場からのネガティブな意見
初回のスクラム開発ではこのような声も上がったのですが、その後の開発で開発部全体にスクラム開発を適用範囲を広げ、チーム全体でスクラム開発プロセスの学習や振り返りを通じて、開発プロセスに対する理解や各自の役割期待のすり合わせを一定進めることはできました。
問題2. 会社としてチーム開発の経験も乏しく、各自の役割期待のすり合わせが不十分でメンバーどうしの対立の発生
チームとしてスクラムの三本柱の特に「透明性」「検査」が行えていなかったと思います。(※)
各自の役割期待が個々人で異なり作業範囲の認識ズレなどによる対立が発生しました。
今思えば、開発開始前にドラッガー風エクササイズなどで、各自の役割のすり合わせや、相互理解を促進したうえで取り組むなどをすることで、開発チーム内の「透明性」を担保するべきでした。
(この話は 3,4 年前の話でして、現在は現場メンバーも心理的安全性が高い組織と感じてくれています。)
※スクラムガイドではスクラムの各イベントが機能するためには、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現することが必要と記載されています。
問題3. スクラムと言いつつもその実態はウォーターフォールに近いなんちゃってスクラム
なんちゃってスクラムの特徴としては、以下のような要素があると思っています。
- 最初のリリースに向けて、開発すべき機能をモリモリにしてしまう。
- まずユーザーに使ってもらう、リリースすることを優先せずに、使われるかわからない僕の考えた最強の機能を想像で作ってしまう。
- 作っているものがユーザーに真に価値あるものなのかという観点での「検査」の不在
- 開発期日が先にあり、それに向けて開発する。(そして実現できずに期限延長)
導入期に実現できたことと、残された課題
ペライチのスクラム導入期を振り返ると当初の課題にあった規模の大きい開発に取り組む体制には改善はできました。
しかし、不確実性の高い開発に向けた本来的なスクラム開発を実践するためには
- 「透明性」「検査」「適応」の実現
- 実態はウォータフォールに近い開発スタイルの打破
といった課題が残ったような状況でした。
さらに、幸いなことにメンバー数、機能数も増えていきました。
一方で 1 スクラムチームで各機能の開発をすることが苦しくなり、スクラムチームの中にプロジェクトチームが複数存在するような、いびつなチーム運営も発生していました。
(デイリースクラムの後に各プロジェクトの朝会をやったりなどでデイリーの形骸化などが発生していました。)
スクラム拡大期
このような、なんちゃってスクラムが開発プロセスとして定着してきた時期に、あらためて開発スピードの改善や効率的な開発を目的に、体制を大きく変更しました。
主な変更点としては以下を実施しました。
- 1 チームでペライチ全体の機能を管掌するスタイルから、機能ごとにスクラムチームを組むスタイルへと変更。
- プロダクトマネージャーの参画によるユーザー起点の開発制度、スピードの強化
- 全社でのスプリントレビュー開催による、フィードバックループの強化
1チームでペライチ全体の機能を管掌するスタイルから、機能ごとにスクラムチームを組むスタイルへと変更。
- チームトポロジーでいわれるところのストリームアラインドチームのような形でドメイン領域でチームを分割するスタイルにしています。
- 導入期のようにペライチ全体の機能を 1 チームで管掌した場合、個々人が案件ごと触る機能が変わることもあり仕様や実装方式の把握に頻繁にオーバーヘッドを要することの解消を狙いました。
- チームごとに守備範囲を定めて、純粋な開発業務に集中できるようになり、最近はサーバサイドもフロントも両方担当する形で活躍するエンジニアも増えてきました。
- 同じチームメンバーで開発を継続していけるので、人となりを理解したうえで互いにリスペクトを持った開発を実施しやすくなりました。
- デイリースクラム等で同期的に日々メンバーが何を困っているかの「検査」がなされるので、じゃあそこは一緒に考えようとか、対面レビューしましょうといったチームワークを発揮した働き方がリモートワーク下でも日常的に発生しています。
プロダクトマネージャーの参画によるユーザー起点の開発制度、スピードの強化
- これまでのペライチにはプロダクトマネージャーはおらず、マーケティング担当者やサポート部門と開発部がそれぞれで必要な機能をそのときどき相談して開発する内容を決めていました。
- プロダクトマネージャーの参画により、ユーザーインタビューやデータ分析の強化により全社的に開発するべき機能の優先度が整理され、使われるかわからない僕の考えた最強の機能を想像で作る問題が解消されました。
- (エンジニアも積極的にユーザーインタビューに参加するなどしてユーザー目線を養うようにしています。)
全社でのスプリントレビュー開催による、フィードバックループの強化
- さらにスプリントレビューを開発部全員やプロダクトマネージャーはもちろん、全社から参加者を募る形で開催するようにしました。
- 一定規模の開発で、開発途中のものでも部分的に動かせる箇所からスプリントレビューで積極的にデモをする形にしています。
- ペライチのメンバーはエンジニアであるないにかかわらず、ユーザーインタビューや問い合わせ対応等のサポートに関わっており、そこで出会ったユーザーの目線を含む目線でのフィードバックを社内で得ることができています。このプロセスでリリースする前からフィードバックループを高頻度で回すことができています。
- もちろん実際のユーザーさんにインタビューを通じフィードバックをいただくプロセスも重視しています。
- 全社巻き込んだ形で会なので「透明性」を持ってプロダクトに対するフィードバック「検査」を実施して、フィードバックを元にした「適応」を実施し不確実性のある中での開発を進める形になっています。
まとめ
このように長い期間をかけてペライチのスクラム開発は進化をしてきました。
まだまだ書ききれないトピックはたくさんあるのですが、現在はスクラム開発を活用して機能ごとにユーザー価値と生産性を高める取り組みを継続できていると思います。
特に今までの過程で特に大事だなと思っているポイントは以下です。
- チームは一定のサイズで分割するべき。ピザ 2 枚ルールのサイズ感は納得感が非常にあります。
- チーム内のチームワークをうまく発揮するために、スクラムマスターを中心とした、気軽に困っていること等を相談しやすい雰囲気づくりと会議体の設置。
- 開発だけでスクラム開発をうまくできることではない。全社を巻き込んだプロダクトへのフィードバックループをいかに作るか。
またこれからの課題としては
- 機能ごとのチーム編成にしたことによる、守備範囲外の機能が発生しているので、そこのカバーを組織的に行うこと。
- チームが今後も増えていく予定で、チームごとにプロセスが最適化されすぎないように、各チームの学びをいかに横展開して開発部全体で成長できるしくみづくり。
といったことがあると考えており、より一層ペライチの開発部には成長の伸びしろがあると考えています。
そんなスクラム開発について語るイベントを開催予定です！ちょっとでもご興味がある方は是非お申し込みいただけると幸いです！
採用情報
このような透明性が高く全社一丸となった開発を一緒にやっていけるエンジニアを全方位的に募集中です！
ぜひカジュアルにもう少し細かいスクラム開発の話などもできれば幸いです。
▼ 選考をご希望の方はこちら（募集職種一覧）
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
Discussion