モブワークの1回目のレポートです。
ここでやったワーク、決まったこと、得た知見をまとめます。所要時間は約2時間、まずは何から始めるかを相談するところから始まります。
MURAL1という付箋のような共同編集ツールと、Zoomでの音声通話、そしてホストでの画面録画を併用して編集、議論を進めていきます。
まずは、みんながMURALになれるところからはじめました。MURALはその特徴として、複数人での編集でもストレスなくコンフリクトも起きずに操作、画面作成が可能であり、アイディア出しのような作業において付箋をぺたぺた貼っていくような場合の操作性が非常によいです。ホワイトボードアプリはたくさんあるものの、付箋というわかりやすいインタフェースは今回のプロジェクトとの親和性が非常に高いと思われます。また、複数の案から投票で決めるとか、作業時間を決めるためのタイマーがあるなど、細かいけれどかゆいところに手が届く機能もあります。
ひとしきりみんなでMURALで遊んだ後本題に入ります。
いよいよ本体の機能のアウトラインを組み上げていくモブワークが始まりました。ここでは、どんなサービスになるのか、 欲しい機能は何かをざっくばらんに出しつつ、要不要や優先度をつけていくというのが基本のワーク内容になります。
最初はコンセプトの説明です。1章、2章と重複する内容ですが、改めて参加者に口頭で説明しました。ここで改めて口に出して説明し、みんなからの質問、コメントをもらうことで内容が整理され、より的確になることが期待されます。
まずは、技術同人誌ポータルis何という枠を作り、ここにコンセプトを列挙しました。
- 世の中の技術同人誌が集まるところ
- サークルポータル、LP（Landing Page）を兼ねる
- 購入サイトへのリンク（とらあな、BOOTH等）
- 更新チェッカー（サークルが更新したらPushしてくれる）
ひとしきり説明する中で、共通認識として残った「技術同人誌ポータルとは」という認識が統一されました。また期待した通り、本質的な部分が抽出できました。
オンラインでの会議や相談における難しいポイントのひとつは、喋りだすタイミングだと思います。誰かが喋っているときに言いたいこと伝えたいことができたとき、いま喋っている人が終わるまで待つこと、待っている間に自分が思ったことを忘れないようにすること、喋りだすときに別の人とかぶらないようにすることなど、オフラインの打ち合わせと違って難しいポイントがたくさんあります。
MURALではこれらの問題のいくつかがスマートな形で解決できます。例えば喋りたいことができたときには付箋にして貼ってしまうことができます。これなら忘れないですし、話が終わったときにそれを見ながらしゃべることもできます。話の途中で解決した場合は付箋なので剥がすこともできます。
次に喋りだすときのタイミングは難しいですが、これもファシリテーターがMURALを使って解決できます。誰かの話の途中で新たに貼られた付箋があるときは、貼った人に振ることで議論することができます。付箋がない場合はそのまま会話の流れに任せることもできますし、喋りたい人が多いときは付箋によってまとめて意見を集めることができます。
ファシリテートとしてはまだまだ改善できる部分がありますが、技術同人誌ポータルis何を整理・共有する議論も、MURALによって非常に快適に進めることができました。MURAL最高ですね。
次は、「欲しい機能」を列挙していきます。
まずは雑に欲しい機能を列挙していきます。最初は特に何も考えずに追加していきますが、途中で読者、サークル主、ファンというカテゴリが生まれます。付箋の色変えも簡単にできますし、とりあえず追加した付箋をカテゴライズしていくこともできます。サークル主が欲しい機能、読者が欲しい機能、両方が含まれる”ファン”が欲しい機能、と分類することができます。
この章で3回くらい言ってますが、共同編集ツールとしてMURALは最適解でした。複数人でバラバラ追加していくには非常に便利です。（なお、後日フリートライアルによるものだったことが判明するのですが、それはまた別の話)
ところで、最初から全ての機能を盛り込むことは当然できません。最低限の機能で公開してユーザーの反応を見ながら機能を追加する、あるいはそのまま実装しないといった選択が必要になるでしょう。ベンチャーなどでよく使われるリーン開発には、実証実験を行うための、実用最小限の製品を意味するMVP（Minimum Viable Product）2という概念があります。
このサービスにおいて何が最小限の必要な機能なのか、という観点で機能を整理します。これがないと成り立たない、この機能はあったらいいけどあとで実装すればいいかな、そういった観点です。この時、先ほどの欲しい機能からもう少し細かい機能に分解しつつ抽出を進めました。
そして、その中で優先度を設定していきます。MVPの中でもさらに必須なものを左側に、少し優先度が下がるものを右側にグルーピングします。並べ替えやグルーピングを同時にみんなでやることで、参加者の大多数が納得できる形にスピーディーに落とし込むことができます。
その結果として、以下の6つがギポタルのMPVであろうということに落ち着きました。
- ログイン機能
- サークル登録
- 本の情報
- トップページ
- 固定のURLが存在する
- サークルのポータルページ
またこれらの機能の実装を試すことで、我々開発チームが開発をできるという仮説実証を行うことができる、という重要な視点も生まれました。
当初からこのプロジェクトは有志の集まりです。金銭的な見返りがあるわけでもなく、明確な締め切りがあるわけでも、強い使命感があるわけでもありません。モチベーション、ドライビングフォースの観点で外的な強制力はありませんから、このチーム、プロジェクトがリリースまで、あるいはそれ以降継続するかは未知数です。したがって、MVPを定め、それを達成することでこの仮説実証ができるのです。
さて、ここで少しブレイクです。ギポタルがリリースできたとして、サークル主にサークル、本を登録してもらわないことには意味がありません。どうすればサークル主を呼び込めるか、そのためのプロモーション戦略を雑談ベースで話しました。
この開発に参加している人は技術同人誌の界隈の人、何ならほとんどみんながサークル主です。したがって自分たちで登録すれば一定数の初動は見込めますし、Podcastや登壇などで折に触れ告知を打つこともできるでしょう。それ以外にも、初心者向けのコンテンツで新規サークル、初めて本書きました！のような人たちを誘導するといったアイディアも出てきます。
また、公開モブプロやプルリク公開募集、あるいはforkして別ジャンルのポータルサイトを作れるようにするなど、OSS的な観点でみんなで作り上げる感ができると楽しいよねー、といった意見もあります。
さらに実装過程を本にするという話もここで出てきます。言い出しっぺの妖怪本書いてけ3がこのチームにはいますから当然の帰結でしょう。すでに書き始めています。
Windowsのファイル名は、大文字小文字を区別しないようです。最初、Promotion.pngでファイルを作り、パスをpromotion.pngで指定したため、本文を直すのではなく、ローカルのファイル名を直してPushしました。その結果、画像ファイルが見つからないと思われるエラーが。
今回、この本の執筆に使っているEasyBooksは、まだエラー回りの扱いが未実装な部分もあり、どういうエラーが出ているのかがわからない場合が少なくありません。
みなさんもファイル名には注意しましょう。そして今後の改善に期待！
ここまで技術同人誌ポータルという名前で（先取りでギポタルといっているところもありますが）きていましたが、そろそろ名前を決めることにしましょう。技術同人誌ポータル、そのままも悪くないですが、かわいい感じもよいですね。ということで、いろいろ出していく中で、ぎぽたる/ギポタルというあたりで固まってきます。てくぽなども出ましたが、割と早い段階でギポタルに収束したのが面白いところです。
ゆるキャラ作る？などのコメントが残っているのもご愛敬。またドメインの予定も固まり、さっそくみんなでドメインが取得されていないか、類似のドメインがないかを確認しました。幸い特に問題なさそうでした。
ここまでで1時間15分くらいです。1時間ちょっとでこれだけのワークができたというのは相当素晴らしいと思っていますが、どうでしょう？
そろそろ後半戦、ネクストアクションを組んでいきます。アーキテクチャを決める、デザインを考える、インフラ回りの制約の共有などを行いつつ、毎週木曜日にモブワークとして進めていくというあたりが何となく決まりました。またデータベース回りでHasura.ioについて調べるとか、ドメインを取っておくなども出てきました。
最後はふりかえりです。
このギポタルプロジェクトでのふりかえりのフレームワークはFun Done Learn4を用いています。かんたんに説明すると、楽しかったこと、やったこと、学んだことなどを列挙していくものです。前向きによかったことをたくさん出すことができます。
欠点は、NextActionや改善が出づらいところらしいですが、すでにNextActionも出ていますし、Learnとかでも出てくるでしょうからそこに気を付ければよい、あるいはFun Done Learnの最初に、改善希望とかも出しましょう、という形でファシリテーションをやるというのも手かもしれません。
全体に楽しかった、アイディアがたくさん出た、といったコメントがたくさんあったとおり、とても楽しい2時間でした。またMURALが非常に便利で、こういったワークには非常に向いているツールでした。付箋を貼るというUIもよいですし、複数人同時アクセス・編集がストレスなくできることで議論が空中戦にならず、次回以降は前回のワークスペースを見ながらふりかえったり、結論を再確認したりすることもできるという期待があります。
何をやるか、というところから始まった第一回モブワークでしたが、2時間の中で非常に密度の濃いワークができました。KANEさんのファシリテーション力やMURALの使い勝手などによるところも大きいですが、参加者全員が楽しみながらワークをやるという貴重な経験ができたと思います。
また次のやること、次の予定が決まったのも非常に良かった点ですね。これから動いていくギポタルへの期待が高まります。
Footnotes
-
ベンチャーが新しいことにチャレンジするときに、仮説を立ててその検証をするためにMVPを作ります。ベンチャーという限られた資金では全てのことを試せないので、最も効果的でコアとなるものを見抜く必要があります。そのとき机上の空論になってもいけないため、仮説を検証できる最小限の製品を組み立てて実証実験をして、また新たな仮説を立てて次のMVPを作っていくというサイクルを繰り返します。 ↩
-
おやかたのことです。成し遂げたいam #33https://anchor.fm/nashio/episodes/ep-33-am--oyakata2438-ef2di3でも話していますが、最近いろいろな人に「技術同人誌書きませんか？」と沼に誘っていたらいつの間にか「妖怪本書いてけ」と言われるようになりました… ↩
-
参考 https://qiita.com/yattom/items/90ac533d993d3a2d2d0f ファン・ダン・ラーン(FDL)ふりかえりボード ↩