コンセプトが決まったら、次は参加者を募集する段になります。
たまたま二つのイベントがあったのでそこで一気に整理と、骨子の整理、そしてデザインのフレームが作られます。
本章ではそのあたりの流れについて述べます。
5月30日、技術書界隈を盛り上げる会1というオンラインイベントが開催されました。これは著者と主催の人がいろいろ話をしながら技術書に関わる話をいろいろわいわいする会なのですが、 この会は2部制になっており、第一部はゲストがもっている経験や本を作ることになった経緯などを話す、どちらかというと勉強会という側面があります。 これに対し、第二部は、ゲストを含め界隈に関わる人が任意で残る「オンライン飲み会」です。前半の勉強会と、後半のゆったりした懇親会というニュアンスで大変居心地が良いのですが、 この懇親会の中で、ふと技術同人誌ポータルサイトの話になりました。
ここから、モウフカブールさんと話をする中で、どんどん話が進んでいくことになります。この本を手に取られた皆さんも、壁打ちや1on1というフレームワークで 今持っている課題の洗い出しや整理をすることもあるでしょうが、まさにそういった形でおぼろげだったアイデアがでてきて、荒い形ではありますが、形になっていきました。
具体的には、サークルと技術同人誌のポータルサイトを作りたい、検索性の悪さやイベントで閉じているところが課題だと思っている、Webサービスとして立ち上げたい、といった課題や解決策が出てきたのです。
なお、この話を始めたのは、ゲストも主催も落ちて、まったりし始めた土曜日の25時頃(日曜日の深夜1時)です。会話の中で、サークル主としてもニーズが強いこと、初心者や一般参加者にとっても良いサービスになりそうなことなど、話していくうちにどんどん話が整理されていきました。
ついに、1時半ごろ、おやかた合同誌のSlackに、雑に「技術同人誌のサークルポータル作りたい」と発言するに至ります。すぐに反応がもらえたので、もっと@mottox2さんをZoomに呼び出しました。 彼は、技書博2の公式ページの実装のかなりの部分をされていますし、UIデザイナーでもあるということで、是非とも協力していただかねばと思っていた矢先でした。
簡単に口頭で概要を説明したところ、その場でもっとさんがワイヤフレームを組んでくれることになりました。 なお、ここで使ったツールは、Figma3というもので、ブラウザ上で簡単にデザインできるツールです。複数人で共同編集することができるので、 シェイプや文字を追加しながらデザインを作っていくことができ、CSSとして表示もできるものです。今回、初めて知りましたが便利ですね。
トップページには、イベントやタグの一覧、また今後開催されるピックアップイベントなどが表示される予定です。現時点ではかなりシンプルですが、トップページに必要な項目 というのは案外少ないかもしれません。
メインはやはり本のページです。とはいえ、本のページには、書影、本の紹介、BOOTH等の頒布サイトへのリンク、あるいはタグ一覧などが入ることでしょう。
実はこの時には、本のページのイメージは作りませんでした。
そして、サークルのページのワイヤフレームが次に作られました。
サークル名、公式ページやBOOTHなどへのリンク、サークル紹介が入ります。
また出展予定/過去の出展イベントの一覧があり、頒布物の一覧が入ります。
頒布物の一覧は、本のページの抄録的ではありますが、書名、タグ、中身の説明のみならず、頒布サイトへの直リンクや初出時期など、必要な情報が一覧で見れるようになっています。 当然それぞれはクリックできるようになっており、サークルページから直接頒布サイトへ飛べるようになっています。
ここで初出時期を明記するようにしたのは、
- 前のイベントで購入した可能性があるかがわかるように
- その技術同人誌に記載された情報の鮮度を見られるように
という目的があるためです。この情報を加えたことにより、イベント単位でのチェックや新刊チェックに有効に働く事を期待しています。 特に技術のアップデートが早い技術においては、大型アップデートなどにより、過去の情報の鮮度、有効性が落ちることも考えられます。これらを一目で見れるような頒布物登録としています。
つづいては、ジャンルごとのページです。ここはタグごとに本をまとめています。本の紹介自体はサークルページに載っているものと同じです （ただしサークル名がわかるように、本の下にサークル名が明記してあります）。
このページはタグごとに作られます。それにより似たテーマの本を素早く探し出すことができます。
また、上方には“おすすめタグ”という項目があります。ここには、類似するタグ、あるいはより上位の概念や下位の概念に関連するタグが配置されます。 これにより、より広い概念のタグを使って広く検索したり、スコープを狭くして自分にヒットする本を探しやすくすることができるでしょう。
なおこのおすすめタグは、手動で設定することを考えています。自動でやったほうが楽は楽ですが、そのアルゴリズムを作るのも大変です。 ヒット率が下がってしまうことも本意ではありません。それくらいならば、それほど多くないタグですから、手打ちしてしまった方が確実でしょう。
以上のようなモックアップがもっとさんと話しだしてから、小一時間で出来上がったのでした。
さて、モックアップができた翌日、また偶然なことに、プロダクトマネージャと実装者を見つけることができました。プロダクトマネージャという表現が適切なのかは議論はありますし、 本人は雑用とか何でも屋とか言っていましたが、KANEさん@higuyumeです。もともと彼はバックエンドならできるよー、ということでしたが、 その後のモブワークのファシリテーションも精力的にこなしていただいており、もはや足を向けて寝れません。
また成り行きで、なべくらさん@nabe_kurageが実装もやってみる、ということも決まりました。これでこのプロジェクトを進めるのに必要な全てがそろったことになります。
ではどういうなりゆきでそうなったかというと、その日、成し遂げたいam4の収録があったのです。その収録の中で、成し遂げたいこととしてこのプロジェクトについて話し、いろいろ考えていることを相談しました。
昨日の相談でモックアップはありましたし、より具体的な機能やコンセプトについて話すことができました。
https://anchor.fm/nashio/episodes/ep-33-am--oyakata2438-ef2di3
一部は是非ここで聴いてみてください。ポータルサイトの話は29分ごろから始まります。
収録が終わってから、引き続き3人で話を進めます。バックエンドをどうするのか、フロント実装を誰がどうやって進めていくのか、といった話です。
実はこのあたりは録音がないのがもったいないところです……残念。
エンジニア雑談のあるあるですね。
もともと、親方Projectの合同誌の相談用のSlackがあります。普段は合同誌作成の相談や雑談をしているのですが、5月31日の段階で新しくチャンネルを作り、相談を始めることになりました。
最初期の相談の一部はSlackチャンネルのログを見ながら、議論の概要を振り返ることにしましょう。
まずは、担当の決定です。すでにSlackにいた関係者を中心に巻き込みます。(いや、基本的には自主的に参加してくれました。ホントですよ？)
- 言い出しっぺ・旗振り：親方
- ディレクション+データ設計：KANE
- フロントとか：なべくら
- デザイン：もっと
- セキュリティ回り：にるふぃ
- その他：えるきち（フロント回りアドバイザ？)、FORTE、（他参加者随時
という形で決まりました。
このあたりでコアメンバーが決まり、プロジェクトの理念やマネタイズなどの話が出ます。発起人である親方より、アイディアの概要を提示しつつ、ぼんやりと周知を図ります。 細かいところでいろいろ議論は出ましたが、大きな修正はなく進んでいったと考えています。
「議論のポイントはGitHubのIssueにまとめていく」という基本方針がここらへんで決まります。フローな情報や相談・議論はSlackで、議題の提起や結論やポイントは GitHubにという形でということになりましたが、やはり二重で管理、あるいは転載転記するのは大変ですね…
実際にIssueが登録されるのは、モブワークが始まってからになります。
次は進め方の話になります。
前述のようにバックエンドはKANEさん、フロント回りはなべくらさんという形ではありますが、なべくらさん自身どこまでできるかわからないとのことでした。そこで、進め方についての議論、優先順位を決めました。
最優先はサイト・サービスの立ち上げですが、せっかくなのでなべくらさんの実装練習を二つ目(あるいは1.5番目)の優先度とすることにしました。これはおやかたの独断です。
そして、えるきちさんより、モブプログラミング（以下、モブプロと記載）で実行する提案がなされます。
モブプロの説明は他のサイト5、書籍を見ていただくとして、基本的には複数人（※注：原則3人以上を指します。）で一つの成果物を生み出すチーム作業のテクニックです。
結果として、週1回、二時間程度でモブプロをやってみよう、という話になりました。
モブにすることで、複数人が実装や決定に関与します。その結果、原則的には全てが合議制で決まることになります。また当該技術に対しての知識に差があっても平均値に引き上げることができます。
確かにできる人が一気に進めたほうが瞬間速度では勝るでしょう。しかし認識の相違や手戻りといったリスクをはらんでいますし、属人化も避けられません。モブだから絶対にこれらの問題は発生しませんとは言えませんが、これらのリスクは相当下げられるでしょう。
一旦、次回をモブワークの日と定め、モブでやってみることが決まりました。
一応、立ち上げスケジュールの話もしておかなければいけません。
この時点では、コロナ影響のため各種イベントが軒並み中止になる中、開催予定のイベントは2020年11月の技書博がほぼ唯一でした。（のちに2020年の9月に技術書典がオンライン開催される旨告知されます）。
したがって、11月の技書博で利用できるよう立ち上がればよいというスケジュールを立てました。
また、モブの進め方にもかかわりますが、モブが上手くいかなかったときのバッファも持つことができることを確認しています。
最悪プロジェクトの進捗が出なかったとして、要件を削減・縮減するとか、別のできる人を探してくる、お金を払って外注に出す等のアプローチもできますし、最悪プロジェクトが崩壊・空中分解したとしても、このサービスがないという状態は変わりませんから今以上に不幸になる人はいません。
そういったセーフティネットを確保したうえで、11月立ち上げという目標を設定しました。
こうして、偶然がいくつも重なり合って、二日ほどで一気に進むことになります。
本稿執筆時点ではまだどういうスケジュールでどういうものが出来上がるのかはまだわかりません。しかしそれぞれ得意分野を持つ参加者が参加してくれ、さまざまな進め方や開発手法を間近で見ることができるチャンスに恵まれました。
ある意味チームが生えてきた、ともいえるような素晴らしいチームだと思いますし、この後の開発過程でもその素晴らしさを何度も目の当たりにします。
強権をふるうわけでもなく、誰かに無理が寄るわけでもなくベストな形で進むチームが爆誕したのです。
次の章では、はじめてのモブワークについてお話ししましょう。お楽しみに。
ちょうど私がギポタルプロジェクトにちょっと足を突っ込んだのがこの頃(Slackのログみたら6/4)でした。
//blankline
今私がメインでやってる仕事は結構旧態依然とした社内システムの内製・機能追加になるので、いわゆるモダンWeb開発とか今風フロントエンドという環境とは カスリもしないし、使う機会は今の所なさそうなので、優先的にそれを学びたいという意識や意欲はそもそもあまり無いんですよね。
//blankline
どちらかというと、おやかたさん主催のおやかた合同誌Slack内にておやかたさんが「こんなのやります！」って言い出して、 またおやかたさんが変な事ぶちあげたなぁ… 面白そうだから乗っかっておくか。が当初参加モチベの１００％でした。 (そこの温度感はあまり今も変わってないですが、関われてしまうこのプロジェクトの温度感はすごく良いと思います。)
//blankline
そもそも私はWebフロントエンドとかよくわかんないしそっち方面では役に立たないだろうと思ってましたので、 せいぜいバックエンドのDB周りとか得意なところで関われればいいか… というぐらいの気持ちでいてます。 （モブワークもタイミング合う時と合わない時があって、参加できたりできなかったりですし。）
//blankline
ただ、この手のプロジェクトで一番うれしい点は、私みたいなWebメインじゃない人からすると「普通の業務だとカスリもしない設計・開発の知見が得られる」点で、そういうところは非常に満足しています。
//blankline
ちなみに、このギポタル本に関しては誤字脱字拾ったりとかもしてるので、別にこのプロジェクトへの関わり方はモブワークに参加するだけでもなく、例えばこういう関わり方でいいんじゃないかなぁと思っています(笑)
Footnotes
-
技術書界隈を盛り上げる会 https://anchor.fm/nashio 技術書典や技書博など、技術書を書く・発行することを応援するオンラインイベントです。（YoutubeLive）。パーソナリティはびば@viva_tweet_xさんとKANE@higuyumeさんです。 ↩
-
https://gishohaku.dev/ 技術書同人誌博覧会（技書博）は、エンジニアがもつ知を「技術書」という形でアウトプットするためのイベントです。 ↩
-
成し遂げたいam https://anchor.fm/nashio 自分が成し遂げたいと思っていることを探求するラジオ（Podcast）。パーソナリティはなべくらnabe__kurageさんとKANE@higuyumeさんです。 ↩