🐼

Mob Designingをやってみている話

2023/10/27に公開

背景

私が所属している会社で提供しているとあるサービスは、そのバックエンドが人手によるGoogle Spreadsheetの運用で回っている状況です。
業務フローが定まってきたため、社内向けサービスとして管理システムを立ち上げ、効率を少しでも改善するべくプロジェクトが始まっています。

そして、数年ほど新規開発から離れていた私が、新しいシステムの立ち上げメンバーとして、スクラムマスターの役割を与えられました。

チームには、各領域でのプロフェッショナルが揃っています。

しかし、それぞれが数年来それぞれの領域を深く突き詰めていたため、相互の知識をあまり理解できていません。

「メンバー間のスタック知識の分離が著しい」
「ある役割が特定のメンバーに偏っていてボトルネックになっている」
- 一目瞭然ですが、設計のロールがいませんね。
- プロダクトマネージャが設計を兼任していますが、当然到底回りません。

という声が聞かれていました。

ところで、数年来として巨大化したシステムの保守運用や、社内の細々した後始末係に関わってきた身として、
本当に久しぶりにゼロからのシステム立ち上げをすることになりましたが、
私自身に開発関係者としてスタートを上手に切れた経験はありません。

諸事情により上を下への大騒ぎの中で突然引き継がれた役職で、何をして良いのかも分からないままメンバーの9割を失ったり、
すでに巨大化してしまったシステムのリファクタリングで不必要な複雑性を持ち込んでシステムを阿鼻叫喚の地獄にたたき込んだり…。

上手くいくビジョンなど何もないまま、チームメンバーを大混乱に陥れてきた過去ばかりです。

振り返って考えるに、私自身の開発者としてのスキルは世間の低い方2割、頭も悪い方、リーダーとしての牽引力も魅力もない、といった身にも関わらず、
役職としての責務に徒に突き動かされて、ワンマンで「自分がこのシステムを考え、作り上げる」という思考に囚われすぎていたように思います。

そこで、今回のプロジェクトを大失敗に終わらせないためにはどうすればいいか、と考えていた折、
とあるエンジニアの楽園において「モブプログラミング」の単語を目にすることとなりました。

そういえば、興味があるもののきちんと学んだことはないなと思い、改めて本を読んだり、
知り合いの会社でモブプログラミングの現場に参加させてもらったりしました。

今回、私がチームに提案して実践してもらっているのが「モブデザイン」ともいうべきものです。
すなわち、「モブプログラミングのように、設計する」ことにしています。

一見するとごく普通、当然の営みではありますが、孤立した各スタックのエンジニアしかいない、
きちんとした設計工程を経験したメンバーもいない状況で、 設計もエンジニアがきちんとやるんだ、という舵を切ったのはなかなか勇気のいることでした。

また、そもそも設計には 一貫性が極めて重要 である中で、モブプログラミングのように 責任の所在が曖昧になりやすい 手法が果たして上手くいくのか、かなり危険な博打にも思えます。

各メンバーの役割を次のように定めています。

特に、ドライバーはできるだけ「タスクをこなす上で何かしらの障壁を感じているメンバー」に担ってもらうことにしています。
（たとえば、Figmaを不得意とするメンバーには、Figmaを使った画面設計のドライバーを担ってもらう、など）

そしてこれらのメンバーを集めて、かなり贅沢な時間の使い方をしています。

「悪くありません」。
コスト管理をしながら他の業務も回しているプロダクトマネージャーの胃に穴が空いている可能性は否定しませんが、一応概ね好評です。

点がとても良く機能しています。

これからも設計工程、開発工程を一通りこの方法で進めてみようと考えています。
いつかプロダクトマネージャーの胃がすべて溶けて、オフィスが血に染まる日が来ることがないように、
よりスピードアップして無駄のない形態へ推移しなくてはなりませんが…。