20代中盤のエンジニア達と週3勤務のプロダクトオーナーでスクラム開発を始めた話

この記事は、株式会社Ancar Advent Calendar 2019の24日目の記事です。

こんにちは。
プロダクトチームでスクラムマスターをしている藤原です。

弊社の2019年アドベントカレンダーへの2回目の投稿になります。
1回目は「半年間の療養生活から社員15人のスタートアップにスクラムマスターとして入社した話」というタイトルで、入社前の療養生活中に取り組んだ内省や自己分析、入社に至るまでの心身の変化についてお話ししました。

2回目の今回は、入社してから2019年末の今日この日まで、スクラムマスターとして、スクラムプロセスの改善、開発チームやプロダクトオナーへの支援と奉仕、仕事を進める上での妨害の排除などを題材に記事を書きます。

スクラム開発の始まり

6月に入社して1ヶ月のオンボーディングの後、7月からスクラム開発を始めていきました。
弊社は12月が期末なので、ちょうど 3Q からスクラム開発を始めたことになります。
当時、3人のエンジニアがいましたが、そのうち2人がベトナムに出国し、GAOGAO で研修などをしておりましたので、7月の帰国を待っての開始となりました。
スクラム開発を始めるまでは、金子にリーダーシップをとってもらい、とても助けになりました。
弊社のスクラムは、スプリントのイテレーションを1週間に設定しています。

プロダクトオーナー

入社前の療養生活中に相談していた須藤がプロダクトオーナーを務めています。
ご自身も体調が優れない状態にあり、週3日で勤務をしています。
須藤は以前の職場での上司であり、優秀なエンジニアでもあります。

開発チーム

開発チームのメンバーは20代中盤のメンバーで構成されています。

・弊社で初めての新卒採用となる社会人1年目の遊佐。
・電気通信事業者の営業職からエンジニアに転職した海上。
・開発経験はあるけど大学にも在学中で週3稼働の中田。
・転職前は電気機器メーカーで公共インフラを担当していた志摩。
・企業経験があるけどエンジニアとして再スタートした小貫。

スクラム開発の開始当初となった7月は遊佐、海上、中田の3人でした。
8月から志摩、9月から小貫が参加してくれました。

スクラムマスター

半年間の療養生活から社会復帰した私がスクラムマスターを努めています。
前職はスクラムマスターを努めたほか、エンジニアとして Android、iOS アプリの開発、インフラ、バックエンド側の調整も担当しておりました。
どの様な人間かは、自己紹介をマインドマップとして描いているので、よろしければこちらの記事をご覧ください。

開発チームに開発を任せるまで

開発チームのメンバーは20代中盤のメンバーで構成されています。
さらに、社会人1年目や、転職によるジョブチェンジのメンバーが多く、経験、スキル不足であることは明白です。
最初の仕事は、「中古車も個人のクルマも一括検索」できる新サービスの Ancar Search になりました。
機能横断的なチームを目指しますが、まずはプロダクトオーナーの須藤と、スクラムマスターの私で、開発チームを技術的にも支援し、経験、スキル不足を補います。

体質

開発チームは経験、スキル不足ではあるけれど、問題があればそれを素直に我が事に捉え、愚直に改善に取り組み、実力に変えていく、素敵なチームです。
経営層、プロダクトオーナー、過去の技術的負債、作業環境、人材育成の機会など、不満要素は沢山あるのですが、文句を言うことなど、ほとんどありません。
プロダクトオーナー 、スクラムマスターへの報告会になりがちなデイリースクラムも、「開発チームに向けて情報共有して。」と初日にアドバイスするだけで、開発チームでの情報共有、業務改善検討会になりました。
しかし、この体質が後々、開発チームの大きな障害となりました。

改善

スクラムはシンプルに始めて、徐々に改善していく様にしました。
最低限の役割、成果物、会議体で進め、課題となっている箇所をその都度、肉付けして対応しました。
下記はスクラム開発を開始した当初に改善を進めたものです。

・スプリントバックログを、Web ツールからホワイトボードでのタスクボードに変えて、タスクの見積もりや進捗を透明にする。
・完了の定義を説明し、コードレビューやドキュメントなど、開発チームの出来ることで品質の向上を意識してもらう。
・WIP の制限をして、滞りがちなコードレビューを完了しないと、他の作業が出来ない様にすることで、タスクを完了させる事を意識してもらう。
・調査タスクは、大きな規模感で見積もるよりも、時間制限を設けて、その時間の中で何がわかったかをまとめ、皆に共有してもらう。

自立

スクラム開発を開始した当初の開発チームは、DB のデータを検索して、検索結果をブラウザに一覧表示することも出来ない、頼りないチームでした。
git-flow でのブランチ戦略を採用していましたが、開発を進めていくとコンフリクトが多発し始め、GitHubでブランチ保護ルールを作成し、作業ブランチを強制的に最新にする様に対応したりしました。
Web サイトを公開するまでの作業手順を、勉強会として開催し、AWS を利用して実際に作業してもらうなどの取り組みも行ってきました。

Ancar Search は AWS の ECS を利用して運用しているのですが、コンテナ / Caas については、プロダクトオーナーの須藤や、スクラムマスターの私よりも、開発チームの方が詳しく、使いこなせてる様に感じていました。
そこで、ECS へのデプロイを機に、須藤と私が、開発チームの技術的サポートから距離を置き、開発チームに「技術を使った課題解決に対して、リーダーシップを発揮」する事を期待する様にしました。
「あとは任せた！」と少し投げやりな感じもしましたが、3Q の終わりに、開発チームのメンバー達にヒアリングをすると、「良いタイミングで任せてくれた。あの後から、開発チームが自己組織化されていった。」と、開発チームの何人かのメンバーから、振り返った当時の話をしてくれました。
そう言ってもらえると嬉しいですね。

プロダクトオーナーと開発チームが交渉するまで

開発チームの努力が実り、9月下旬に無事、Ancar Searchをリリースしました。
3Q のチームでの取り組みを締め括る、印象深い出来事になりました。
SMART をタスクテンプレートにしてみたり、相対見積もりを一覧化して比較できるようにしてみたりと、リリースまで改善に取り組みました。

3Q を振り返ってみると、開発チームは経験、スキルが不足しているとは言え、スプリント計画までにPBI の並び替えができてなかったり、スプリントでの開発対象となる PBI の規模感が大きかったり、分割できてなかったりと、プロダクトオーナーの支援が必要であることも感じていました。
また、ユーザーに使われることを想定して開発、リリースしたのに、それがユーザーにとって価値があり、利用されているかなどの検証などが出来ていない様に感じていました。
開発チームが自己組織化され、デイリースクラムを開発チーム自身で運営できる様になったと感じていたので、4Q はプロダクトオーナーの役割に目を向け、支援をすることにしました。

傭兵

経営層が開発チームを信じていないと、指示されたことを忠実にこなす様に押さえ付け、傭兵の集団にしがちです。
しかしながら、経営層からはある程度の裁量を持たせ、プロダクトを向上させるための会話をして欲しいとまで言ってくれてます。
弊社の開発チームは経験、スキルが不足している為、価値を考えるのは上の人間の仕事になり、PBI で示された通りにしか開発を進めることが出来ません。
そうすると、開発チームはお客様の為ではなく、プロダクトオーナー個人や、社内組織からの圧力の為に開発、提供をし始めてしまいます。
プロダクトオーナーとの対話、交渉を促しても、ほんの一瞬のことで、すぐに上手く作る事ばかりを考えていました。
さらに、開発チームは、問題があればそれを素直に我が事に捉え、愚直に改善に取り組み、実力に変えていく、素敵なチームですが、それ故に、経験、スキルが不足している為、開発が上手くいかないのは全て開発チーム自身の責任である様に感じていました。
経営層、プロダクトオーナー、過去の技術的負債、作業環境、人材育成の機会など、不満要素は沢山あるのですが、文句を言うことなど、ほとんどありません。

妨害

PBI の並び替えができてなかったり、スプリントでの開発対象となる PBI の規模感が大きかったり、分割できてなかったりと、プロダクトオーナーがスプリント計画までに果たすべき作業が出来ていないのに、スプリントレトロスペクティブで、開発チームから一切、問題として取り上げられることがありません。
そこで、妨害リストを公開し、スクラムマスターの私から見た、開発チーム以外に起因する課題を共有しました。
開発チームがいくら成長したとしても、前提を変えない限り、大きな改善にならない事が出てきたのは間違いありません。
妨害リストを運用して、前提から妨害を排除していきます。
下記は妨害リストを運用し、プロダクトオーナーに起因する課題の改善を進めたものです。
週3日という貴重な勤務時間の中で、スクラムプロセスのほか、リーンでの仮説、検証にも取り組んでみました。

・プロダクトバックログリファインメントを開催し、 PBI の並び替え、細分化、詳細化の場を設けるようにした。
・スプリント計画、プロダクトバックログリファインメントの中心人物はプロダクトオーナーであり、取り仕切りをお願いした。
・PBI の受け入れ基準を、開発チームが1スプリントで達成できる単位や、マイルストーンになるよう、 PBI の細分化を行うようにした。
・リーンスタートアップ、リーンキャンバス、リーンスプリントを例に、課題の理解、ソリューションの決定と、プロトタイプ、開発成果物の定性、定量的検証を説明した。

交渉

今後の事業展開を見据え、AWS の Cognito を利用してのユーザー管理を、4Q の始めから取り組んできました。
「クルマの個人売買マーケットプレイス」である Ancar では、メールアドレスの他にも、Facebook アカウントでのログインが可能です。
Cognito を利用してのユーザー管理でも、メールアドレスの他、Facebook アカウントも管理したいのですが、メールアドレスでの管理が完成したのに、Facebook アカウントでの管理が難航します。
PBI の細分化、詳細化を進めても、完成まであと一歩が続きました。
開発チームからは、「あと少しで出来る」との進捗報告がありますが、その「あと少し」が全然、解決できません。
スプリントレビューでプロダクトオーナーから、「あと少しで出来るというから待っているんだけど、全然、出来上がってこない。マイルストーンでプロダクト開発の進め方を決めたいんだけど、この結果報告を聞いて、どうしたら良いか、判断が難しい。」という言葉がでます。
出来ないことは、はっきり出来ないと伝えることの方が、事業を進める上で大事な要因になることを知ったのです。

この後から、開発チームは経験、スキルが不足していることに起因する現時点で出来ないこと、プロダクトオーナーからの要求で困難なことを、現時点では出来ない、難しいと、はっきり意思表示し始める様になります。
スプリント計画では、開発チームの実力で出来ることを交渉し始め、作業の優先順も、開発チームから見た優先順を伝え、プロダクトオーナーと調整が出来る様になったのです。

最後に

半年間、試行錯誤する中で、大変だったと思うことがたくさんあり、ここに書いてない改善もたくさんあります。
この一年を振り返ってみると、辛かったと思うこともあった気がしますが、やってきた改善の効果を感じたり、やりがいを感じたりしたことの方が多い様に思います。
スクラムマスターとして、まだまだ期待に応えられないところもあり、不甲斐ないと思うことも多くありますが、スクラムチームの素敵なメンバーと共に、スクラムプロセスを改善したり、各メンバーへの支援や奉仕、仕事を進める上での妨害を排除してこれたと思っています。
スクラムチームのメンバーと一緒に働いてこれたことに感謝します。

3Q は開発チーム、4Q はプロダクトオーナーに重きを置いて支援と奉仕をしてきました。
次は、私自身が、スクラムマスターとしてどうなのかというところに重きを置いて改善して行きたいと思っています。
現状では、スクラムマスターとして支援することで、最もユーザーや事業に貢献するものをプロダクトオーナーに検討してもらい、ユーザーや事業に貢献する様に開発チームに作ってもらうことで、会員数や売上、利益を向上させることではないかなと思っています。
また、開発チームにスキルマップを作ってもらい、インフラなど、弱い部分を妨害リストにリストアップしたので、こちらも積極的に支援していきたいと思っています。

以上、20代中盤のエンジニア達と週3勤務のプロダクトオーナーでスクラム開発を始めたことについてお話ししてみました。
何かの参考に少しでもなれば幸いですが、まだまだ手探りでスクラムを肉付けしているので、同じ様な環境でスクラム開発をご経験のスクラムマスターがいらっしゃったら、是非、お話を聞かせて頂きたいです。

おまけ

スクラムプロセスの改善についての取り組みを、いくつか写真付きでご紹介します。
また、プロダクトオーナーを支援するために読んだ本もご紹介します。

タスクボード

スプリントバックログを、Web ツールからホワイトボードでのタスクボードに変えて、タスクの見積もりや進捗を透明にしました。
画面を覗き込むより、大きく貼り出した方が、開発チームもやりやすいと喜んでくれました。
デイリースクラムは、このタスクボードで進捗や課題の共有をしています。

因果関係図

スプリントレトロスペクティブで、取り上げられる課題の頻度により、因果関係図を利用して、課題の根本を見つけ出し、解決するといった取り組みをしています。
同じ様な課題が3回ぐらい挙げられたら、因果関係図を利用する様にしています。
因果関係のどこで対応するかを、スクラムチームのメンバーと考えて判断し、次のスプリントで対応しています。

Keep ストッカー

開発チームがスプリントで良い取り組みを行い、改善の効果を実感しているのですが、後続のスプリントでその改善に取り組まなくなってしまうなど、残念な状態になっていました。
そこで、スプリントレトロスペクディブで挙げられた Keep の中から、今後も継続して取り組んで行きたいことを、優先度をつけてストックする様にし、開発チームに継続して取り組んでもらっています。
10個までストックし、形骸化したもの、貼り出さなくても取り組めるもの、優先度の低いものから入れ替え様と思っています。

ユーザーストーリーマップ

「スプリントで開発していると、全体像を意識して開発を進めることがイメージしづらい。」と、プロダクトオーナーから相談があり、ユーザーストーリーマップを作りました。
後続3スプリント分のユーザーストーリーを、ユーザーのアクティビティに合わせてマッピングしたり、発生している課題や技術的負債も併せてマッピングしてます。
わかりやすくなったと、プロダクトオーナに喜んで頂きましたが、現状だと、ユーザー価値よりも技術的負債などの方が多いのが課題です。

読書

プロダクトオーナーを支援するために有効ではないかと思われる、下記の書籍を読み、参考にしました。

・Running Lean 実践リーンスタートアップ
　アッシュ・マウリャ (著), 渡辺 千賀 (解説), エリック・リース (編集), 角 征典 (訳)
　(オライリー・ジャパン)
・図解リーン・スタートアップ成長戦略
　アッシュ・マウリャ (著), 角 征典 (訳)
　(日経BP)
・ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
　及川 卓也 (著)
　(日経BP)
・INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
　マーティ・ケーガン (著), 佐藤 真治 (監訳), 関 満徳 (監訳), 神月 謙一 (訳)
　(日本能率協会マネジメントセンター)
・ユーザーストーリーマッピング
　ジェフ・パットン (著), 川口 恭伸 (監訳), 長尾 高弘 (訳)
　(オライリー・ジャパン)