Scrum-Upプロジェクトのryo_gridです。
この記事では有志による趣味ソフトウェア開発を行った上で得られた知見や、プロジェクトのこれまでの流れについて書いていきます。
Scrum-Upプロジェクトとは
有志で趣味のソフトウェア開発しちゃおうぜプロジェクトです。
Maker Faire に参加している団体などハードウェア界隈ではチームでのプロダクト開発というのは比較的珍しくありませんが、ソフトウェア界隈でのチーム開発というのはゲーム界隈などの一部の分野を除くと、それほど一般的でないように思います。近いものとしては、OSSがあり、その界隈では多数の人たちでの開発が行われていますが、最初は創始者が形にして、それに徐々に人が賛同して集まっていくというフローなのでやはり違うのかなと捉えています。
そこで、まったくゼロの、企画の段階からチームで開発を行ってみようと立ち上がったのがScrum-Upプロジェクトです。
現在4名のメンバ（私含む）が参加しています。
それ以外にもプロジェクトについて説明したいことはあるのですが、長くなるので詳しくは下のリンク先をご覧ください。
プロジェクトの成果物: UZOMUZO(alpha)
先日、Mastodon風マイクロブログホスティングサービス UZOMUZO(alpha)をリリースしました。
http://uzomuzo.herokuapp.com/
今年度のはじめあたりからMastodonが一定の流行を見せておりますが、残念ながらIT系技術者ではないと自分でインスタンスを立てるのは難しいというのが現状だと思います。そこで誰でもMastodonのインスタンスっぽいものを立てられるようにしよう!というのが本サービスの着目点です。
UZOMUZOチームのメンバは3名(プログラマx2、デザイナx1)。
開発期間は各々可能な時間にまたーりと作業して一ヶ月弱というところでした。
トップページ
ユーザの投稿が流れるページ
プロジェクトのこれまでの流れ
企画出しおよびメンバ集めイベント@オンライン
FBのイベントを立てて私の知人(FBで繋がっている人)を中心に招待して実施しました。
開催場所はオンラインで、Slack上で行いました。
オンラインで行った理由は世界中どこにいる人でも参加できるようにしたかった(実際現在NYから参加しているメンバもいます)のと、会議室などの会場を押さえるのが面倒だったからです。
イベントで使用した説明資料のスライドはこちらです。
https://docs.google.com/presentation/d/1atCJZ-NAZVnaaIc22FS8OzhPIXgdA88X0xzyDtWVSKQ/edit?usp=sharing
イベントは企画出しだけ参加して、プロジェクトに参加しないとか、ただ議論の様子をROMするのもOKということにしました。
イベント準備においては、実施日以前からSlackに入ってイベント運営方法について議論やアドバイスしてくれるメンバもおり大変助かりました。
イベント当日の参加者は、トータルで6名でした。
そして、そのうち実際にプロジェクトに参加することにしてくれたのは3名でした。
250人ぐらいの人にイベントへの招待を出しましたがこんな感じの結果だったので、なかなか難しいなというのを実感しました（私の人徳の無さかもしれませんが）。
議論の進め方としては、ただ思いつきでプロダクトのアイデアを挙げていても議論が発散してしまうので、社会課題・問題意識・取り組みたいテーマなどをまず設定して、そこからブレークダウンしていくことを繰り返すやり方をとりました。
イベント自体はみんな好きな時間に一時離席などしていたので、過疎ってしまう時間帯などもありましたが、おおむね議論はうまくいきました（と思っています）。
イベント実施前は一定数のメンバがコミットしてもいいという企画がなかなか決まらないのではないかと懸念しましたが、（想定外に、）イベント自体の参加人数が少なかったこともあり、うまいこと合意形成をすることができました。これはラッキーだったと思います。
プロジェクトの進め方としては、イベントでの議論の結果、軽めのプロダクト(企画1)でチーム開発の体制を整えて、重めのプロダクト（企画2: これがUZOMUZO）の開発を行おうという話になりました。
コラボレーション基盤の整備
まずはコラボレーション基盤の整備、具体的には利用するサービス類の整備に取り組みました。
コミュニケーションツールにはSlackを引き続き利用することにしました。
あとは、皆がアクセスできるgitリポジトリが必要だよね、ということでgithubの利用を検討しましたが、プライベートリポジトリが無料枠では5人までしか使えず将来的にメンバが増えた場合に対応できないということで、github類似サービスのDeveoを利用することにしました。
Deveoも無料枠では、リポジトリのデータ量に制約があるようですが、当面は問題ないかと思っています。プルリク(DeveoではCodeReviewと呼ぶ)もできるし、issue管理やwikiの提供もあり、なかなか便利です。
プロジェクトサイトを立てる
次はモチベーションを高めるためには、形からということで、プロジェクトのサイトを立ち上げることにしました。
実現方法としては、いまどきの流行にのって、github.ioを利用しました。
静的なサイト（バックエンドサーバなどを持たない）ならホスティングできてしまうので、大変便利です。といっても、今はHTMLファイル一つの簡素なサイトですが、、、そのうちもっとイケてるサイトにしていきたいと思っています。
開発: 企画1(軽めのやつ)
企画出しイベントでは、軽めのプロダクト(企画1)でチーム開発の体制を整えるという計画を立てたのですが、いかんせんプロトタイプの開発の段階で想定以上に技術的難易度が高い、かつ、完成したところで、需要も無ければ、一発ネタとしても微妙なんじゃないかということが分かってきたので、開発を中止して企画2に進むことにしました。
ただ、企画2にはあまり興味が無く企画1をやっていきたいというメンバもいたので、そのメンバには引き続き企画1の開発を進めてもらっています。どんなものが出てくるか、こうご期待です。
開発: 企画2(重めのやつ=UZOMUZO)
各々が自宅などで好きな時間に開発を進めました（ています）。メンバによっては、家庭や仕事の都合で手が動かせなくなる時期なども発生しましたが、そういう状況は想定していたので、残ったメンバで粛々と作業を続けていきました。タスクの分担決めは3人とメンバも少ないのでSlack上でコミュニケーションをとりながら決めていきました。DeveoにはIssue管理の機能もあるので、それを利用すれば良いのではないかという話もあるのですが、今のところまだ定着していません。サービスリリースをした以上、バグ管理などはこれまで以上にしっかりと行っていかなくてはならないので、Issueベースでのタスク管理の定着にはもっとちゃんと取り組む必要がありそうです。
リリース
リーン・スタートアップという方法論？がありますが、我々もその考え方を採用し、まだプロダクトとしては未熟な段階ながらUZOMUZOをアルファリリースするという方針をとりました。これには、リーン・スタートアップで言われるような読めない市場に対して、早めにリリースを行って、それに対する市場の反応からプロジェクトを成功に向けて方向づけようというような、高尚な目的もまあ無くは無かったのですが、どちらかというと、成果物のリリースという形で一区切りつけないと、いつになってもだらだらと開発を進めることになり、メンバのモチベーション低下が起きると考えてのことでした。また、リリースというマイルストーンをぼんやりとでも示すことで（いついつリリースというデッドラインを決めたりはしませんでしたが）、メンバの作業もノッてくるかなと思ったからです。
そんなわけで、先日、UZOMUZO(alpha)がリリースされました。
運用・保守
サービス自体はheroku(の無料枠)で運用しています。無料枠でもRDB(PostgreSQL)などが使えてありがたやです。
知人に触ってみてもらったりすると、メンバのテストでは見つからなかったようなバグも出てくるもので、報告があれば適宜修正を行っています。
サポート的なところで言うと、現状ユーザが全然いないので、問い合わせなどもなく、特になにもしていない状況です。
開発にあたって注意したこと
お金を使わずにプロジェクトを回す
今のところ、プロジェクトを進めるにあたって一円もお金を使っていません。
なるべく、ネットサービスの無料枠などの恩恵を受けてお金を使わずに回しています。
これは、メンバにお金が無いから、とかそういうわけではなく、有料のサービス・インフラなどを利用するとして、メンバでお金を出すといった話になると、お金のやり取りも面倒だし、誰がどれだけ負担して、誰が管理するんだという話が出てきてしまい面倒かつ揉め事の種になると考えるからです。また、今後、新たなメンバが参加してくれるかもしれませんが、その時に、既存メンバがある金額をそれまでに出していたとすると、新規メンバとの関係が対等ではなくなるといったことも考えられます。
この制約は結構きつい制約ですが今後も可能な限り守っていきたいと思っています。
個人情報を持たないようにする
個人情報を持つと漏洩が怖いので、基本的には持たない作りにしました。
不必要にユーザの情報は入力させず、ユーザ認証はGoogle認証のみとしています。
このような方針がプロジェクトとしてあるので、今後新たな企画を考える場合もSNSのような個人情報盛りだくさん、みたいなものは難しいと考えています。
適度な開発期間の企画をあらかじめ選ぶ
開発期間が短すぎるとせっかく複数人で開発するには物足りないし、長すぎるといつまでもリリースができないので、開発メンバーのモチベーションが維持できないと考えました。従って、企画出しイベントの時点で、想定される開発期間は意識した上で企画の選定を行うようにしました。
採用した技術
WebフレームワークにRuby on Rails 5を利用しました。
開発に参加している3名はそれぞれある程度Railsの開発経験はあったものの、version1とか2ごろの話だったので、いろいろ仕様が変わっていてそこの差異を理解するのに苦労しました。
今後は技術的に面白そうなところとしては、Websocket(RailsだとAction Cableと言うのを使うらしい)を利用して、投稿のリアルタイム反映をまずはやっていきたいと考えています（今はページをリロードしないと他ユーザの新規投稿がタイムラインに現れない）。あとは、Cloudinaryを利用して、ユーザアイコンの設定に対応したいと考えています（今は全員ユーザアイコンが固定...）。
得られた知見（ノウハウ）
ようやく本題です!
趣味ソフト開発におけるPM(Product Manager)の難しさ
一応、私がPMという扱いになっているのですが、基本的には私を含めて全メンバは対等な関係としているので、どうみんなが作業をして、その成果として企画をゴールに向かわせていくかというところは案外難しい話になってきます。例えば、これが企業だったら、メンバは雇用関係という縛りを受けているので、私が上位の権限をもって作業指示を出していけばいいわけですが、趣味の開発では皆ボランティアで参加していますし、無理やり指示などしようものなら、嫌になって離れていってしまう可能性もあります。なので、各人が自主的に作業したいところをやりつつも、うまいこと必要な作業が網羅されるよう誘導して、プロダクトが完成するように仕向けなければなりません。
このコツというのはうまく説明できないですが、強いて言えば、相手を尊重し対等な関係として作業をお願いする。また、自身が推進役として率先して作業する、といったところかなと思っています。
あくまで趣味であることを認識する
上記の話と関連しますが、あくまで趣味でやっているプロジェクトであり、参加しているメンバの目的はソフトウェアの開発や、プロダクトの運用を楽しむことにあります。したがって、無理に作業スケジュールなどを立てて開発を進めることは避けるべきだと考えています。
活動時間がバラバラでもうまく回る仕組みにする
各メンバとも自身の生活がありますので、活動時間はバラバラにならざるを得ません。また、家庭や仕事の事情によっては、しばらく作業から離れてしまう場合もあります。したがって、
- 皆で相談して決めなければならないことは必要最低限にし、なるべく各人の裁量で作業が進められるような形にする（各人のバランス感覚が大事になってきますが）
- 全員の意見調整をしていたら先に進まない場面も出てくるので、しばらく不在にしているメンバを抜きでエイヤっとものごとを決めていく大胆さも時には必要(ex: UZOMUZOというサービス名は2名で決めた)
コード管理はちゃんとする
別に趣味ソフト開発に限らないのですが、コード管理をちゃんとしないとカオスになります。もちろんgitなどのバージョン管理システムを使えばそれで万事OKという話でもありません。各メンバがmasterにやたらめったらコード入れてたら、他のメンバはコミットログを見るしか修正内容を把握する方法がありません。そこで、修正を入れる場合は、自分用に修正に対応するブランチを切って、修正が終わったら修正内容をできるだけ詳細に記述したプルリク(CodeReview)を作成し、私が確認した上でmasterにマージするというルールを決めました。これにより全体の修正を少なくとも私は把握している状況を作れますし、他のメンバもプルリクを見ることでどんな修正が入ったか把握することができます。ただ、このやり方だと私がボトルネックになる（不在だとマージされない）ので、しばらく不在になる場合は他のメンバに権限委譲しておくといったことが必要なのだろうなと思っています（今のところそういうことはないですが）。
あとは、どのメンバも突発的な事情で開発から離れることが起こりうるので、修正はキリのいいところでこまめにプルリク化してもらって、開発成果が手元に持ちっぱなしになることを避けることが必要だと思います。
物理的な距離の制約は問題にならない
UZOMUZO開発チームは関東にいるメンバが2人、九州にいるメンバが1人という構成ですが、何の問題もなく共同作業を進められています。
UZOMUZOのチームではないですが、NYにいるメンバも一人います。このように、海外のメンバが出てきた場合は時差の問題などありそうな気もしますが、そもそもみんな活動時間がバラバラなのでそんなに問題にならないような気もします。
早い段階でリリースする
既に上で述べたことですが、早い段階で小さくプロダクトをまとめ、リリースできる状態を作り、リリースしてしまった方が、開発メンバのモチベーションは維持しやすいのではないかと感じています。そして、その後はインクリメンタルに改善や機能追加などを行っていくやり方をとるのがよいのではないかと感じています。
情報を一人に占有させない
人間何があるかわかりませんから、突発的にメンバが抜けてしまうことも考えられます。特に趣味ソフト開発の場合、企業での開発と比較してより確率は高くなります。したがって、プロジェクト（企画）の運営に必要な情報を一人が握ってしまうのは避けなければなりません。例えば、企画で利用しているサービスのアカウント情報などがこれにあたります。そういったものは作成する時点で一定数のメンバと共有しておくように徹底しなければなりません。（とか書いておきながら、herokuへのデプロイに必要な情報を私がまだ占有しているので、これは早期に共有しないとな、と思っています...）
ルールはみんなで決める
プロジェクトの運営にあたっていくつかルールがありますが、それらは私が勝手に決めたわけではありません。提案はしますが、それを採用するかどうか決定するにあたってはメンバの合意を必ず得るようにしてきました。手間はかかりますが、こういうところの意思決定を皆ですることで、プロジェクトへの参加している感や、メンバの一体感が出てくるのかなと考えています。
まずは知人を中心にやった方が無難
Scrum-Upプロジェクトのメンバは今のところ、私とは直接面識のあるメンバだけから構成されています（メンバ間は必ずしも面識あるわけではないです）。これは、最初の企画出し&メンバ集めイベントを私の知人に限定して開催したためです（厳密には招待された人が招待した人というのもイベントには参加されていましたが）。これには私なりの意図があって、ネットで広く人を募ってイベントに参加してもらうというやり方も考えられましたが、まったく面識もない人が集まっても恐らくコントロールしきれないだろうなと思ったのでやめました。最悪、（言葉は悪いですが、）他人と協調できず、独断専行してしまうような人がメンバに加わった場合、プロジェクトが崩壊しかねません。それに対して、知人だけに限定しておけば、人となりは分かっているわけなので、ある程度は安心です。
とはいえ、ずっと知人だけでやっていくつもりなわけでもありません。まずは知人であるメンバ達でプロジェクト・チームの体制を整えてから、外部の人を受け入れていくという進め方がリスクヘッジになるかなと考えているだけです。悲しいことですが、あまりに協調性を欠く方がいたらプロジェクトを去ってもらうという決断も必要になってくると思います。ですが、これはプロジェクトのメンバがある程度結束した状況でなければ行えないことだと思っています。
余談1: マーケティング？的な話
いざリリースしてみたあとに検索してみたところ、既に無料でMastodonのホスティングをやっているサービスが2つほどあって、このままだとユーザ来てくれなそうだなあと感じています（リリース後に気づくのが情けない）。なので、当初とは別のユーザセグメントをターゲットにして、何か刺さる機能性とかを持たせないといけないかと考えているのですが、良いアイデアがありません。何か面白いアイデアがあれば、コメント欄までお願いします○刀乙
(個人的にウェブ広告でも打ってみてもいいかもと考えていますが、その前に方針を固めないと)
まあ、ポール・グレアム大先生が下の記事で述べているように、まずは足でユーザを獲得しろという話もあるので、方針転換するのは時期尚早かもしれませんが。
余談2: メンバー募集
もし、Scrum-Upプロジェクトへの参加に興味がある方がいれば、下のアドレスまでメールいただければと思います！
uzomuzo.contact[at]gmail.com
関連記事
以上。この記事を機にチームでの趣味ソフト開発にチャレンジする人が増えれば幸いです。