スクラム開発をヒントにコミュニケーションロスを改善した話
# はじめに
こちらの記事はSTORES.jp Advent Calendar 2019の14日目です。
はじめまして、サーバーサイドエンジニアの@fuqdaと申します。
先日リリースしたプロジェクトで自分はサーバーサイドの開発メンバーでありつつ、プロジェクトリーダー的なことをさせてもらいました。
そこではコミュニケーション上の課題があったのですが、進め方を工夫したところプロジェクトがうまく回るようになったので、今回はその時のお話をしたいと思います！
# 結論
はじめに結論を言ってしまいます！
スクラムのエッセンスを小さく取り入れたらコミュニケーションが改善されてプロジェクトマネジメントがはかどったよ！
これだけだと言葉足らずですが、つまりスクラムに必要な活動の全てではなく出来るだけを小さく取り入れてみたら、課題が解決出来たぞという話です。詳細は後述するので、しばしお付き合いください。
# スクラムについて
そもそもスクラムって何だよ！という方もいらっしゃるかもなので、軽く説明させて頂きます。
スクラムはアジャイル開発手法の1つです。常に進む方向を調整しながら目的を達成できるプロダクトをつくるために、全員が一丸となって行うべき作業、会議、成果物を定めたものです。
出典：西村直人 永瀬美穂 吉羽龍太郎 | SCRUM BOOT CAMP THE BOOK | 翔泳社 p22
スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
出典：Ken Schwaber Jeff Sutherland | The Scrum Guide | p3
これだけだと具体的なイメージが湧かないと思うので、スクラムで登場する専門用語とその活動についても触れておきます！
# スクラムに登場するキーワード
・プロダクトオーナー
→ プロダクトバックログの管理人で最終決定権を持つ存在
→ プロダクトが要求通りであるかのジャッジを行う
・開発チーム
→ リリース可能なプロダクトを作るチーム
→ 上下関係はない
→ 3〜9人で構成する
→ 全員が揃うことでプロダクトを作ることが可能なメンバーの集まり
・プロダクトバックログ
→ 実現したい要求をリストにして並び替えたもの
・スプリント
→ スクラムは最長1ヶ月間の固定期間を区切り、そのサイクルを回す。その1サイクルをスプリントと呼ぶ
→ 開発チームはこの期間で計画・設計・開発・テストなどプロダクトのリリースに必要な全ての行為を繰り返し行う
・スプリンバックログ
→ プロダクトバックログを具体的な個別のタスクに分けたもので、1つのスプリント内で実施されるタスクの一覧のこと
・ベロシティ
→ 1つのスプリントでチームが何ポイント分のタスクを消化出来たか？を数値化したもの
# スクラムで行う主な活動
毎日やること
・デイリースクラム
→ 毎日の朝会(昼会)のようなもの
→ 前日のデイリースクラムでやったことと当日やることの共有・ 相談
スプリントの開始時にやること
・スプリント計画ミーティング
→ スプリントの実行計画作成 ＆ タスクの見積もり
スプリントの終了時にやること
・スプリントレビュー
→ スプリントで作った成果物をプロダクトオーナーが確認する
→ プロダクトオーナーが実際に動作する環境を触ってスプリント内で要求通りの開発がされているのかを確認し、作業の完了をジャッジする
→ プロダクトバックログに追加すべき項目があれば追加する
→ 現在の作業の進捗を踏まえてリリース日を予測する
・ スプリントレトロスペクティブ
→ スプリント内のプロダクト開発に問題がなかったかの振り返りミーティングのことで、改善のための施策を話し合って次回以降のスプリントでのアクションプランを決める
# ぼくらのプロジェクト事情...
長い前置きは終わりついに本題へ。
スクラムのエッセンスを開発に取り入れようと思った背景と当時のプロジェクトの状況を軽く振り返ります。
【プロジェクトメンバー】
✍️プロダクトマネージャー(1名)
👨💻エンジニア(4名)
・サーバーサイド(2名) ← 自分ココ🙋♂️
・フロントエンド(2名)
🎨デザイナー(2名)
【当時のプロジェクトを取り巻く状況】
・スケジュールが比較的タイト🔥
→ 絶対にこの日までにリリースしたい日が決まっていた
・別プロジェクトを掛け持ちしてるメンバーがほとんど🏃
→ 専任メンバーは自分だけ
→ 別プロジェクトもガシガシ動いてるのでメンバーが多忙
・全体スケジュールのフォローアップ(進行管理)は誰もしていない😇
→ PMとプロジェクトリーダーの自分との間でプロジェクト進行の
ファシリテーションをどちらが行うのかが曖昧だった
・メンバー間のコミュニケーションが少ない 😓
→ メンバー間に認識のズレや仕様理解の差分が生まれやすい状況
→ なんとなく相談しにくいかも？
作業としてはフロントエンドとサーバーサイドとデザイナーでプロジェクトのはじめに作成した仕様の草案を元に分業しており、なんとなく進んでる気はするもののプロジェクトの管理が出来ていないため何がどこまで終わってるのかを把握出来ておらず、ズルズル時間だけが過ぎる状況でした...
その状況を見かねて声をかけてくださったのが会社の先輩エンジニアの@Katsumata Ryo(以下かつまたさん)でした。
かつまたさんは以前のプロジェクトでスクラムをやっていたときの話をしてくださり、現状のコミュニケーションロスをクリアして、プロジェクト進行にプラスになりそうだったので小さく導入することにしました。
# 解決したかった課題
・誰が何をどのくらいやってるのか分からない😢
→ どんな問題が起こってるのかも把握出来ない
・仕様的な理解度が人によって違いそう🙈
→ あとで認識ズレてた...が発生しそうかも
・もしかして相談しにくいのでは？😇
→ コミュニケーションが上手くいってたら、もっと仕様・開発の相談とかありそうだけどあまり来ないかも...
・タスクの粒度が粗く作業分担がうまくできてない😵(サーバーサイド側)
→ 大きな粒度で作業してしまっていて、もっとタスクを細かくして分担した方が進捗が出そう...
→ バタバタしたまま作業に入ってしまったのでタスクを整理したり、残課題を洗い出す時間をちゃんと取った方がはかどりそう...
誰が何をやっているのかが分からないと進捗管理が出来ないので困る...
コミュニケーションを十分に取れてないので、個人個人でどこまで仕様を理解してるのか分からない(認識齟齬の温床の予感)...
当初slackで何でも相談してね！とPMからプロジェクトメンバー全員にアナウンスがあったのですが、関係性も出来ていない急造メンバーでバンバン相談し合うの厳しそう...
相談しやすい空気を作ったり、そういった音頭を取ってくれる人が必要なはず！
そして、自分のサーバーサイド側については、残課題がモヤモヤしたままで、なし崩し的に開発してしまっててヤバそう...
一度立ち止まって課題を整理したい！
# 具体的に取り入れたスクラム要素
そんなわけで2つの施策を試してみました！
・毎日の昼会
・1週間のスプリントで見積もり・振り返り・KPT(サーバーサイドのみ)
# 毎日の昼会
手始めにスクラムの活動の一つであるデイリースクラムを昼会という形で取り入れることに！
突然ではあるもののメンバーにコミュニケーションの重要性を伝え、快諾してもらうことが出来たため、昼会を基本的に毎日12:00~12:15の時間で行うことにしました。
(STORES.jpはフレックスタイム制でコアタイム12:00 〜 16:00の会社です)
ルールとしては、エンジニア全員は必須参加でPMとデザイナーは任意参加で必要な時に招集する形で進めることにしました。
内容としては、その日やるタスクと各自の困ったこと共有・スケジュールの確認などが主で15分で収まらない相談ごとは昼会が終わってから、関係するメンバーだけ残って話をするようにしました。
ちなみにSTORES.jpは週1リモートが可能なのでリモートのメンバーもおり、リモート勢はslackコールで昼会に参加してもらいました！
(リモートでも問題なくミーティングが出来ました🙆)
# 1週間のスプリントで見積もり・振り返り・KPT
これは完全にサーバーサイド側のみで、フロントエンド・デザイナー・PMは参加不要の取り組みとしてはじめてみました！
エンジニア全体で行わなかった理由については、フロントのタスク見積もりにサーバーサイドが立ち会わなくても毎日の昼会で早めに相談出来るので、
スプリントは各セクションに全て任せても良いと判断しました。
あとスケジュールがタイトだったのもあり、無駄に集まって関係ないメンバーを拘束して時間をロスしないように気を付けました。
【1週間のスプリントでやったこと🙆】
・週の頭にミーティングしてタスクを洗い出しポイントを振る
→ ex) ざっくり1時間で終わりそう = 1ポイント
→ そこでタスクも分担
・金曜日にスプリントの振り返り(スプリントレトロスペクティブ)＆ KPT
→ 課題を共有して翌週のアクションプランを決定
【1週間のスプリントでやらなかったこと🙅】
・ベロシティーを測る
→ 1週間で何ポイント分のタスクを消化出来たか？の計測
ちなみにスプリントでのタスクの管理はasanaで行いました！
(ミーティングはasanaを見ながら実施)
※ asanaの使い方についての詳細は以下の記事を参照 👀
https://note.com/acairojuni/n/n2eff81f38851
タスクをカンバン・タイムライン・カレンダーで管理出来て、スケジュール管理しやすく使いやすかったのでオススメです😆✨
# 解決出来た課題
・誰が何をどのくらいやってるのか分からない😢
→ 昼会の時間にヒアリング出来るので正確に把握出来るようになり管理コストが減った
・仕様的な理解度が人によって違いそう🙈
→ 昼会で仕様の確認など開発途中の確認を定期的に挟むようにしたので認識齟齬が減った
・もしかして相談しにくいのでは？😇
→昼会で毎日顔を合わすようになってslackでのカジュアルな相談や口頭での相談も増えた
・タスクの粒度が粗く作業分担がうまくできてない😵(サーバーサイド側)
→ スプリント毎のミーティングでタスクを細かくして分担出来るようになった
誰が何やってるのか分からない問題をクリア出来たのはデカく、
PMやプロジェクト外の方への報告がしやすくなったので、関係者の精神衛生上も健全な状態へ。
(〇〇プロジェクトって今どうなってるの？って心配されなくなりました😌)
相談コストが下がったおかげで仕様もっとこうした方がいいよね？という話も活発になり、プロダクト品質としてもプラスの方向に！
タスクをスプリント毎に細かくして分担したおかげで進捗も出るようになったので、全体的にうまく回るようになったと思います。
# プロジェクトの結末
全体的にモヤモヤあいまいな状況で進んでいたプロジェクトでしたが、
結果としてリリース時期を早めて大きなトラブルなくリリースを終えることが出来ました😭🎉✨
後日談なのですが、別プロジェクトの方からも「〇〇プロジェクトすごくスムーズに進んでて良かったよね！」とコメント頂き、当初のバタバタ度合いと打って変わって良い形で終えられたのがホントに有り難かったです🙏
# まとめ
スクラムのエッセンスを小さく取り入れたらコミュニケーションが改善されてプロジェクトマネジメントがはかどったよ！
本来のスクラムを厳密にやる場合は、プロダクトオーナーが優先順位を決め、スクラムマスターがスクラムを補助し、開発チームは優先順位に従ってプロダクトバックログのタスクに掛かるなど決められた型があると思います。
今回は自分が開発チームとプロダクトオーナーを行き来したり、流動的に実施し、スクラムの要素を小さく取り入れたことで導入コストも少なく、ある程度メリットも得ることが出来たので、チームの状況に合わせて取り入れるのがオススメです！
逆に全てを厳密にやろうとするとコミュニケーションに掛かるコストもいくらか増える認識なので、しっかりやる場合は、そのときのメンバーの負荷も加味して合意が取れればやっていくのが良さそうだと思いました。
というわけで今回は自身のプロジェクト体験記という形で投稿させて頂きました。
最後まで読んで下さりありがとうございました👋
# 参考文献
・SCRUM BOOT CAMP THE BOOK
・The Scrum Guide
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
この記事が気に入ったらサポートをしてみませんか？