Hamic事業部でとある子供向け製品の開発をしている瀬尾と申します。
本記事ではとある製品開発の主にサーバーサイドの開発のプロセスとツールについて紹介します。これを見ればこれからプロジェクトに入ってくる人もなんとなく開発の流れや雰囲気が掴めるといいなと思っています。
なお、プロセスやツールは執筆時点のもののため、今後変わってしまう可能性があることをご理解いただければと思います。
これはHameeアドベントカレンダー7日目の記事です。
コンテキストを合わせる
- Hamicとは・・・
- 「テクノロジーで愛のあふれる世界をつくる」をミッションにこども向けのIoT製品を開発しているプロジェクトです。
エンジニア視点でいうと、IoT製品ということでハードの設計・製造からファームウェアの開発、連携するモバイルアプリ・バックエンドのサーバーサイド、インフラと製品開発に必要な技術の幅が広いのがひとつ特徴と言えるかと思います。
次に開発チームがどんなメンバーやスキルセットを持った人かというと
- 開発者（社員、パートナー）デザイナー（社員）
- スポット的にアジャイルコーチ（パートナー）
で、この内モバイル開発者:サーバー・インフラ開発者:デザイナーが3:2:1くらいの割合です（全体の人数はぼかして書いていますが1桁で収まる人数）。
社員メンバーは私を含めてアジャイル開発の経験はあまりなく、プロジェクト開始当初はアジャイル開発の経験豊富なパートナーさんに入ってもらいコーチングを受けてプロセスを改善しながら開発を回して今に至ります。
また、コロナ禍の状況下でHameeでは比較的早めに会社としてリモートワークを推奨（時期によっては原則）していることもあり、現在は基本全員フルリモートで働いており拠点もバラバラで、リアルでは数年会っていないメンバーもいますが今のところ破綻せずに開発できています。もちろん各スクラムイベントはすべてオンラインで実施しています。
開発プロセス
前置きが長くなりましたが、まずはざっくり開発プロセスからです。Hamic事業部ではスクラムをベースに独自のアレンジを加えたもので、イテレーションは1週間で回しています。
スクラムイベントとしては
- アイスボックスの棚卸し
- プランニング
- 開発
- スプリントレビュー（デモ）
- レトロスペクティブ（ふりかえり）
という感じでわりと基本から外れていないのかなと思います。
ただ、参加メンバーは開発者+デザイナーのみで（さまざまな事情により）プロダクトオーナー的な役割の人間は不参加です。この辺りは別途どこかで書けたらいいなあ。
一つずつ見ていきましょう。
アイスボックスの棚卸し
当プロジェクトでは開発者+デザイナーは誰でもバックログを追加することができるようにしています。まだ検討が済んでいないバックログをアイスボックスと呼び、毎週追加されたものをメンバーで棚卸しするという工程を踏んでいます。
なお、ツールとしてはPivotal Trackerを利用しています。今どきPivotalかよと思う向きもあるでしょうが、アジャイル開発に慣れていない我々にとっては、自由度が高いツールよりもある程度使い方を強制されるツールの方が型を覚えるという意味では良かったのかなと思います。まあ癖が強いツールですよね（検索精度をもう少しなんとかしてほしいとは思う）
話を戻すと、アイスボックスの棚卸しでは人によっては備忘録的にわりと雑に放り込まれたタスクを詳細化（リファインメントと呼んでいます）し、いわゆる開発レディな状態に整えるという作業をしています。この時点でポイント（相対ポイントを採用しています）振りもしてしまいCurrent Backlogに移動もします。
理想的にはバックログの登録時に開発レディにできれば良いのですが、登録コストが高くなると面倒くなって登録しないなんてことになりかねないので、なるべく登録はライトにし、後から詳細化するという運用にしています。
プランニング
PivotalのCurrent Backlogに積んであるタスクをイテレーションごとに割り振っていきます。
プランニングの進め方も紆余曲折あったのですが、現在はバックエンド側とフロントエンド側とそれぞれ別々にプランニングをし、結果を最後に共有するという形に落ち着いています。
ここはフロントとバックの開発が比較的独立して動けるからこうなっているだけで、状況が変われば一緒にプランニングする形に変わるかもしれません。
開発
プランニングで決めたタスクを実施していきます。そこで使っているツールとそれぞれの使い方についても触れながら説明します。
タスク管理
上でPivotalを使っていると書きましたが、実はNulab Backlog（スクラム用語のバックログとややこしいのでツールの方をBacklog、スクラムの方をバックログと表現します）を併用しています。
使い分けとしては、Pivotalはそのイテレーションで何をやるかのフロー情報（流れて消えていく）のタスク管理に、Backlogはタスクの中で蓄積して後から見返したいストック情報の管理に使っています。（PivotalはマストでBacklogは必要に応じて作る）
なんでこんなめんどくさい事をしているかというと、それぞれのツールのいいとこどりをしたかったからです。
Pivotalはスクラム開発のタスク（ストーリー）管理に特化していて、イテレーションごとのタスクを管理するのにちょうど良いが、完了したタスクを後から見返したり、表示領域も（おそらく意図的に）狭いので多くの情報を書くのに向いていない。
Backlogはフロー情報の管理をするには重くなりがち（カンバン機能は未検証）で優先順位（優先度ではない）づけもしにくい。ただし、意思決定の記録や調査記録など後から情報を見返すのには比較的使いやすい。
両方をいい感じに扱えるツールとか使い方があったらぜひ教えてください！
ソース管理・CI・デプロイ
ソースコードの管理にはBitbucketを利用しており、PRでのレビューを必ず通してマージするという運用です。また、CIにはCircleCIを採用し、リポジトリにプッシュされるとリントや自動テスト、対象のブランチの場合はドキュメント生成やデプロイトリガーの実行をしています。原則テストなくしてリリースなしの運用です。
デプロイに関しては基本的にAWS CodePipelineを利用しています。
スプリントレビュー（デモ）
PRのレビューとは別にデモを実施しています。例えばサーバサイドではこれで良いと思った内容がフロントからみるとおかしいといった認識の齟齬を防いだり、それぞれが何をしているかを理解するチームビルディングの側面があったりします。
各自が知らないうちにタスクを終了させていたとならないように、デモでOKとなって初めてPivotal上でタスクを完了状態（Accepted）にする運用としています。
実際この場で指摘が入って修正がするなんてこともあったので、今のところうまく機能しているように思います。
レトロスペクティブ（ふりかえり）
毎週KPTフレームワークちょっとアレンジしてふりかえりを実施しています。ここではツールとしてMiroを利用。
アレンジの部分で個人的には面白いな思っているのが、KPTに加えてサンクスともっと褒めてくれを追加しています。
最初はサンクス（そのイテレーションで他のメンバーに感謝を伝えたいことがあればそれを書く）だけだったのですが、それだと盛り上がらない時期が続いたので、「もっと褒めてくれ」が追加されました。
出典: 漫画「スラムダンク」16巻より引用
これは自薦他薦問わず褒めてほしいことがあったら取り上げる場所を用意する試みです。ちなみに最初は自薦のみだったけど、みんなシャイだから書かないので他薦もOKになりました。
個人的にはスクラムで最も重要だと思っているのは「ふりかえり」のプラクティスで、これがないと改善のサイクルが回らずにダメならダメなまま突き進んでしまうことが多いんですよね。人によってはふりかえりの時間が惜しいから開発させてくれという意見もあるとは思うのですが、私の経験上はふりかえりでかけた時間を取り返してお釣りがくることがほとんどです。もしなんかプロジェクトがうまく進まないなーなんてお困りの方はふりかえりだけでも取り入れてみるのはいかがでしょうか。
ふりかえりガイド
ひさびさにふりかえりガイドを見たら2021/5に更新されていて、エモさが爆発していた。
まとめ
Hamic事業部では以上のようなプロセスで開発を回しています。まだまだ改善の道の途中ですので今後もプロセスは見直していく予定です。もし興味があるよという人はこちらからご連絡いただけると嬉しいです。