新規事業やってみての振り返り(1)

noteはじめました。株式会社Joolenでエンジニアをやっています。縁あって、この会社で新規事業を担当させて頂いています。

まだまだ詰めなければいけないところ、苦しいところはいっぱいあるけれども、ようやく新規事業が形になってきました。ここらへんでプロジェクトの発足から、今日に至るまでの振り返りをしたいと思います。

2020/5 新規事業プロジェクト発足

緊急事態宣言の真っ只中、新規事業プロジェクトの発足が発表されました。開発手法はスクラム。体制としては…

開発チーム：社内でも選りすぐりの技術バリバリな人々4名
プロダクトオーナー：社長
スクラムマスター：私(ちなみにスクラム初経験…)

という構成。会社としての本気度がうかがえる、「オラ、ワクワクすっぞ」なチーム構成でした。

Azure DevOpsで始めたスクラム開発

今までほとんど触ったこともありませんでしたが、スクラム開発を進める上でのツールにはAzure DevOpsを採用しました。これは、今振り返ってみてもとても良い選択だったと思います。
Product Backlog Item(PBI)の管理、タスクの管理、バーンバウンチャートの生成、ソース管理(Git)、CI/CDまで全部入りだったので、全ての情報をAzure DevOpsに集約できたのは大きかったなぁ、と感じています。
Azure DevOps(Boards)の活用事はQiitaの記事としてまとめてあるので、またスクラムやる時には参考になればと思います。

採用した技術

Webアプリケーションが前提だったので、下記の技術を採用しました。

フロント： React (Material UI)
サーバサイド：Laravel
DB ：MySQL
インフラ：Google Cloud Run (あとはアプリを動かすために必要な、memory store とか Cloud SQLとかVPCとか…)
CI/CD : Azure DevOps Pipelines

弊社のスキルセットはPHPがメインなので、サーバサイドは自ずとPHPフレームワークのデファクト(だと思っている) Laravelを採用。フロントはVueという選択肢もありましたが、開発メンバーのスキルセットを考慮してReactに。
また、社内にインフラに強いエンジニアがいない、という事情もあり、サーバレスな仕組みを取り入れてみました。

ちなみに、サーバレスでシステムを構築すれば、コストが抑えられるかな？と目論見もあったのですが、セッションを維持するためのRedisの費用やサーバレスVPCの費用が意外と嵩むこともあり、思ったほど安くあがらなかったというのが現在の感想です。

Cloud Run × Laravel × React でシステムを構築するためのノウハウもQiitaにまとまっています。
Laravelをデプロイする 
ReactをCDN(Cloud Storage)にデプロイする
CloudRunにデプロイする料金に関する記事

スクラムで直面した失敗ごと

これは本当にたくさんありました。スクラムマスターとして反省しています(多分)。振り返ってみると…

開発メンバースキルレベルがバラバラ

Joolenの基本スキルセットはPHPと書きましたが、中には受託案件で C#をメインにされている方も多くおり、開発メンバーとしてアサインされていました。この方々、技術力は素晴らしいのでキャッチアップはできるのですが、当然ながらLaravelが予め提供している機能などは知らないので、次のスプリントの計画を立てる時に認識の齟齬が出ます。

例えば、要件に「権限の制御をいれる」とあった時に、Laravel知っている人であれば、「あぁ、Gateの機能を使えば良いよね」になるのですが、知らないとイチから実装しよう、という発想になるわけです。
こうなると、ストーリーポイントにも毎回、大きな乖離が出て、毎度それを説明して意識をすり合わせる、という流れになります。
結果、長い時間がプランニングに費やされるようになり(多い時は半日も！) 、疲弊した中で黙々と次のスプリントの計画を立てていくこと…弊社ではこれを「お葬式状態」と読んでいましたw

結果、プランニング通りにスプリントは終わらず…かなりしんどい時期だったと、振り返ってみると感じます。

この状態への対処方法は今でも悩ましいですが、メンバー間のコミュニケーションを取りながら、いち早くキャッチアップしてもらうということかな、と思ってます。(現状、それ以外の解決方法が思いつかない) 

Product Owner(PO)忙しすぎ問題

決して、POをディスっているわけではないですw念のため。上記でも書いた通り、POは社長なので当然、経営者としての仕事や他案件などもあるわけで…

インセプションデッキが中々できないやら、開発チームとして上手くPOの意図を汲み取れないやら色んなことで苦しんだような気がします。
そもそも、この新規事業はビジネスモデルとしてどうなのか？という意見が出たりもして開発チームのモチベーションの維持が難しくなってしまった時期もありました。
当時は慣れないリモートワーク中心の中で、スクラム内でのコミュニケーション不足も要因として大きかったのかもしれません。(今、振り返ってみれば)

当時のレトロスペクティブ のKPTボードを見返すと本当に色々と書いてある…色々とあったなぁ。

続く…

スクラムでの失敗ごとはまだまだいっぱい書けそう。
あとは、次回はやってよかったスクラムの施策なども書こうかと思います。