こんにちは、こくぼ id:yusuke-k @yusuke_kokubo です。 株式会社ファントムタイプ @phantomtype という会社をやってます。 Misoca社には2年半ほど前からお世話になってます。
開発のプロセスや生産性をあげる組織のあり方を考えるのが好きです。 最近はUIデザインをしたり、Misocaが目指すプラットフォームのUXデザイン(見習い)をしたりしています。
ここ3年ほどでMisocaはスタートアップして資金調達からexitまで行きました。 その過程で開発プロセスもいろいろ変わってきたのでここらでいちど整理したいと思います。
注意事項
ここでは開発チームに限った話を書きますが、他にもマーケティングやユーザーサポートなどのチームがあります。
チームプロフィール
- メンバー
- 約8人 (女性比率0%)
- リモートワーク
- 1~3人
こちらのメンバー紹介記事もあわせてご覧ください。
全体の流れ
Misocaではプロダクトの開発が以下の流れで行われます。
やること会議
Misocaではやること会議と呼ばれる場所でProduct Backlogのリファインメントが行われます。 この会議はMisoca経営陣と各チームから一部のメンバーが参加して今後のプロダクトについて話をします。
- 会社やプロダクトのロードマップを更新する
- 直近6ヶ月〜1年までの予定を更新
- 開発に限らずマーケティングやユーザーサポートのロードマップもある
- 会社の目標と方針を確認する
- 会社として何を優先して取り組むのか共通認識をつくる
- Product Backlogの優先順位付け
- ロードマップや目標の方針に沿ってProduct Backlogを決めて、順位付けをする
Backlogの元になるアイデア(バックログアイテム)はMisocaチームの誰でも提案できます。 ユーザーからの要望や意見から上がってくることも多々あります。
スプリント
Misocaではスクラムをフレームワークにして開発のイベントをつくっています。 後述しますが、スクラムガイドに書いてあることを徹底してはいません。
weekly
スプリントプランニング
- 1週間でやることを洗い出して目標を立てます
- 状況によってプロジェクトごとに細分化してプランニングします
全体への成果報告
- スプリントの終わりに開発チーム以外のメンバー全員に成果を報告します
- 動かせられるものはデモを交えます
開発プロセスふりかえり
- やったことや成果についてふりかえりをします
- ここでは開発プロセスの改善に限った話をします
開発チームミーティング
- プロダクト開発を支える技術的な話をします
- プロセスとは関係ないコードベースの改善について話をすることが多いです
- RubyやRailsやその他ライブラリの新バージョンについてなどトピックの情報交換もします
不具合ふりかえり
- https://app.misoca.jp/ で発生した障害や不具合についてのふりかえりをします
- 発生原因や防止策について話をします
- 設計の問題なのか実装や仕様の問題なのか
- 「不具合を埋め込みやすいこのコードよくないよね」みたいな話もあります
コードを埋め込んだ個人の責任が追求されることは一度もありません tech.misoca.jp
daily
朝会
朝会については過去に記事を書いてるのでこちらをご覧ください。 tech.misoca.jp
コードレビュー
Misocaではgithub.comでPull Requestによる開発をしています。 コードレビューもPRの単位で行います。 レビュー担当などは特に設けず、各自が時間をとってレビューをします。
過去、レビュータイムという時間をとってみんなでレビューしましょう、という取り組みもやっていましたが今はレビューが習慣化されたのでやっていません。
デプロイ
マージされたPRは適当なタイミングでデプロイされます。 もちろん影響の大きいデプロイは別途調整されたうえで行われます。
スクラムとの違い
スクラムをフレームワークとしていますが、完全に沿っているわけではありません。 なのでMisocaは「スクラムをやっている」わけではありません。 *1
プロダクトオーナーが明確にいない
- 会社やプロダクトのビジョンは経営陣が示す
- プロダクトの方向性や順位付けはやること会議で決める
- プロダクトのデザインは開発チームと外部の協力者で決める
プランニングは簡易的にしかやってない
- いわゆるプランニングポーカー的なものはない
- プロジェクトごとに独自の裁量で決めている
スプリントレビューがない
- レビューではなくデモを交えた報告をしている
- 品質保証は開発チーム内で任されている
ベロシティなどの開発チームの生産性を測るメトリクスはない
- プロダクトとしての指標は計測して全体で共有している
- 開発チームの成果はそれで代用できている、と考えている
プロセスを考えるうえでの個人的な意見など
プロセスの話と技術的なトピックを分けて話をする
プロダクトのコードベースの話と人やツールのプロセスの話は微妙にコンテキストが異なります。*2 なのでそれぞれは別枠として扱っています。
開発チーム内での自浄作用
技術の選定、PRのマージまでの流れ、デプロイのルール、タスクの進め方、計画のつくりかたはチーム内で完結できるのが望ましいです。 それらの一つ一つの意思決定をチーム外に仰いでいてはパフォーマンスが出せません。 誰がどの仕事をどのように進めるのかチーム内で決めます。
ミーティングは最小限 (残業は悪)
Misocaでは残業をする文化がないので定時時間内でいかに効率的に仕事をするかを求められます。*3 そのためミーティングが多くなってくると「最近多くね」という会話が出てきます。 そうなるとミーティングを短くしたり参加人数を絞ったり、ということが行われます。 朝会なんかは特に大きく変わって今の形に落ち着いています。
生産性をあげることは大事だけどプロダクトの成功のがもっと大事
開発チームという言葉が最近あまり好きではありません。開発することだけが仕事のように見えてしまうからです。 Misocaは自社プロダクトの開発をする組織です。 なので開発をするだけでなく、プロダクトのオーナーシップをすべからく全てのメンバーが持つべきです。 チームとしての生産性を上げることももちろん大事なことですがそれ以上にプロダクトが世の中の流れに適応して柔軟に変化していける方が大事です。 *4
こまめにふりかえり、軽い気持ちでトライ
Misocaチームのよい文化の一つに「なんでもやってみる」というのがあります。 大きな方針転換も小さな改善も「とりあえず試してみよう」という気持ちにみんながなります。(ならないこともたまにあります) そのためにみんなで考えてみんなで実行しています。 ここには書ききれない細かい施策によって全体の大きな流れが形成されています。
他チームとの協同
意見をくれたユーザーへの個別連絡
ユーザーの意見や要望がリリースされた場合は、意見をいただいたユーザーへ個別連絡をしています。 これは開発チームとユーザーサポートのチームが協力して行われます。
今後解決したい課題
- プロダクトのロードマップが全員に浸透できていない
- メンバーが増えたときにスケールしていける自信がない
- ダイバーシティが欠如している
- 一部のメンバーが主導しないと前に進めないことがある
- メンバー間のスキルトランスファーをうまくやれる方法を見いだせていない
- 中長期的なスケジューリングが下手くそ
今後の予定
- プロダクトがあるべき姿、について話す場を設ける
- 開発チームに限らず「Misocaをもっとよくすること」をみんなで議論する
- 計画づくりをうまくできるようにする
- プランニングの精度を上げる
- ベロシティを計測して数値で話ができるようにする
- メンバー間のスキルトランスファーを進める
まとめ
現時点のMisocaの開発プロセスについてまとめました。 まとめてみると、まだまだチームとして改善できるポイントがあるなあ、と思いました。 今後も頑張ります。
詳しい話を聞きたい人は個別にご連絡ください。
