はじめに
開発部で施工管理チームのフロントエンド 開発をしている藤井です。
施工管理チームは主に、新築施工・リフォーム施工において、着工から完工までの「実際の工事が完了するまで」を効率的に管理するための機能を担当しています。
具体的な機能には、工程表・報告・検査などがあります。
施工管理チームの開発フローは、これまでウォーターフォールに近いものでした。
ウォーターフォール的な開発が、決して悪い訳ではありませんが、直近の開発においてチーム内でズレが生じてしまったことをきっかけに、スクラムの本格的な導入を検討することになりました。
弊社の新規事業チームでは、すでにスクラムが導入されており、それに倣ってみようと考えたのです。
（新規事業チームとは、ANDPADでまだサービス化できていない建築業界の新たなニーズに対応する部隊です）
チームが抱えていた課題
私たちのチームには２つの課題がありました。
１つ目は、開発工数がうまく見積もれなかったことです。
その結果、ある機能のリリースを延ばす事態になってしまいました。お客様に直接影響が出ることはなかったのですが、ビジネスサイドやカスタマーサクセスメンバーに迷惑がかかってしまいました。
２つ目は、開発メンバー自身も負担がかかかり「上から降ってきたタスクを消化しているだけに感じてしまう」という声が上がったことです。これまでも部分的に朝会などを取り入れてコミュニケーションを図っていましたが、正直、形だけになっていた感が否めません。
これを機会に、本当に良いチーム・開発とはなんなのか、チームみんなでスクラムを通して考えることにしました。
スクラムを導入してみて、施工管理チームがやったこと・良かった点などを紹介します。
まずチームでしたこと
開始当初、「スクラム」のことをなんとなく分かっていても、具体的にどうしたらよいか真に理解しているメンバーはいませんでした。
そこで、まずチーム内で認識を合わせたことが２つあります。
1つは、「誰か１人がスクラムに責任を持つのではなく、メンバー全員が理解して取り組む」ということです。
そしてもう1つは「最初から完璧に理解して行うのではなく、やりながら全員で勉強していこう」ということです。
スクラムマスター１人が頑張って啓蒙しても、メンバーが協力しなければ、その人が疲弊して終わるだけです。何も改善には繋がりません。
この「共通認識の構築」が非常に良い効果をもたらしました。
あるメンバーはスクラムの図解イラストを引っ張ってきて共有したり、またあるメンバーは本を読んできて内容を共有したりといった、学び合う雰囲気が自然とできていったのです。
参考にしたもの
今回我々が参考に使ったものは、とても少なく、イラスト１枚と本１冊です。
いろんな参考資料や書籍がありますが、全てを読み込んでからやるのではなく、やりながら理解していくために、あれこれと手を出しませんでした。
イラスト
スクラムの全体像を再確認するために、上記に掲載のイラストを何度も見て、参考にさせて頂きました。プランニング、レビュー、レトロスペクティブをどのタイミングでやるのか、メンバー全員で都度チェックしました。
書籍
スクラムに関する書籍はいくつかありますが、そんな中で今回こちらの本が参考書となりました。
この本が自然と選ばれた理由は、読みやすさにあります。
スクラムの基本的な解説とあわせて、実際の開発を想定したストーリーが漫画で描かれており、とても読みやすく参考になりました。大事なところは丁寧な説明も入っており、何度も振り返りながら使っていく上で、使いやすさも感じました。
分厚い本だと全員が読むまでに時間もかかってしまいますが、スクラムに対して強いモチベーションがないメンバーでも簡単に読むことができたと思います。
新たに使う物品
付箋
今までJira上で管理していたissueチケットですが、付箋も使うことにしました。
付箋のメリットとしては、今何をやっているか、何が残っているかひと目で見えるということにあります。
付箋には、Jira番号、タイトル、担当者、そしてストーリーポイントを書きました。Jiraとの併用は面倒ではないかとも懸念がありましたが、メンバーそれぞれが分担して管理すればそうでもないことに気づきました。
また、タスクを完了した際に、物理的に付箋を移動することで、「終わらせた」という感覚が強く持てることもメリットです。大したことではないかもしれませんが、意外とこれがゲーム感覚になって達成感をより感じれます。
ホワイトボード
これまでもホワイトボードはメモ書き等で使っていましたが、今では物理カンバンとして利用しています。
またプランニングの際は、裏側を使用して、機能追加や修正の際には、タスクを小分けにするため書き出したりもします。
（タスク書き出し中の写真）
プランニングポーカー
ストーリーポイントをつけるために、さっそくこちらを経費で購入してもらいました。
https://www.amazon.co.jp/dp/B0746T9LXW/ref=cm_sw_r_tw_dp_U_x_Ct0DDb6D2MC1T
カードにはフィボナッチ数列が振ってあり、タスクに対して自分が思う工数を出し合って、見積もっていきます。
もちろん、全員が同じ数字にはなりません。しかし、これは良いコミュニケーションをもたらしました。
Aさんはある理由で「5」だと考えるが、Bさんは別の理由で「13」だと考える。その違いを話し合うことで、PM・デザイナーも含め、メンバーの認識を合わせていきます。
この作業が白熱し、一見カードでわいわい遊んでいるように見えますが、真剣にそのタスクについての議論ができ、懸念点や難易度などの理解を深めることができました。
（スプリントプランニング中の写真）
効果はどんな感じ？
まだ初めて1週間ちょっとですが、メリットをすでに感じています。
それは「コミュニケーションが増えて、相互理解が深まった」ことです。
（ここでいう相互理解とは、PMと開発メンバー、そしてデザイナー間でという意味です）
これまでお互いに「彼はこんなタスクがあるんだろうなぁ」となんとなく把握している曖昧な状況でした。
しかし、一緒にスプリントプランニングを行い、他のタスクも洗い出すことでそれぞれが持っているタスクが明確になったのです。また物理ボードを使うことで今誰が何をやっているのかが一目でわかるという状況になりました。不思議とお互いの信頼度も上がったように感じます。
朝会の進め方も変わってきました。それまでは、1人の疑問点から議論が発展して、関係者だけが話し続ける、といったことがあったのですが、「それに関係あるのはAさんとBさんだけだから、朝会後に話そう」と場を切り分けるようになりました。
さいごに
スクラムが走り出してわずかですが、今後もチームメンバーで話し合いながら改善を進めていきます。
また別の記事で、デイリースクラムにおいて工夫していることなどをまとめたいと思います。
