大学二年生の江口と申します。

僕はdesigning plus nine（以下dp9）というサークルに所属しており、そのサークル内部用の作品投稿SNSの制作を担当しました（概観は上図）。

タイトルの通り、プロジェクトの期間は動き出してから約8ヶ月間です（サイドプロジェクトとして進めていたため長い期間がかかりました）。その中で僕はメンバー（エンジニア）として1回目のリリース、PM(Product/Project Manager)として2回目のリリース（デザインを全てのページについて改善し、多くの新機能を加えた大型アップデート）を経験しました。

１回目と2回目ではどちらも10人弱のメンバーで、ほとんどの学生メンバーが入れ替わりました。

そこで、学生でサイドプロジェクトとしてチーム開発をするということについていくつかの知見を得ることができたので以下で記そうと思います。

興味があれば読んでみてください（参考になればいいねをお願いします）。

注意

あくまで学生がチームでサービスをリリースするときの教訓なのでフルタイムで働ける社会人の方たちなどにとっては参考にならないかもしれません、ご了承ください。

教訓

人数と生産性 -初期段階では出来るだけ人は入れるな。

初期段階では出来るだけ人は入れないようにしましょう。
理由は三つです。

タスク振り分けと共有のコストが進捗にかかるコストに近いレベルでかかるから。

後ほど記述しますが、各メンバーの能力の把握、定例会議のセッティング、各メンバーの忙しさの確認（授業日程、他の活動）、それに応じた期日の振り分け、そして度々の進捗の確認などメンバーが多いほど発生する仕事が山ほど出てきてしまいます。

しかも学生だと隣に座って毎日同じ時間に出社してくるわけではなく、皆授業があって上のような作業の多くをリモートで行わなければなりません（メッセージの返信が1日後、あるいはメッセージが返ってこないなんてザラです）。

さらにこういった作業はPM（学生）がきちんと行わなければ途端にプロジェクトの進行が止まります（PMがテスト期間だったりすれば止まらざるを得ません）。開発する人数が一人か二人ならこういった作業、あるいは期間の長さによる弊害を大幅に減らすことができるでしょう（もちろんその開発者が一人で走り切らなければならないリスクはありますが後述する存在意義を十二分に感じてくれるはずです）。

あまりできないメンバーの戦力は0ではなくマイナスになるから。

できるメンバーができないメンバーに教育している間も時間は失われていきます。
そしてその教育が短い期間で成果に繋がる可能性は低いでしょう。またエンジニアの場合、できないメンバーが仕込んだバグなどを書き換えなければなりません。
プロジェクトに教育の目的がない限り、できるメンバーに絞った方が良いと思われます。
（教育の目的を持たせたい場合も初期リリースではなく運用段階に入ってからの方が良いと思われます）

人数が多いと各メンバーのプロジェクトに対するアイデンティティが失われるから。

人は存在意義で動きます（マズロー/自己実現欲求）。
人が多いと他の人が果たせる役割をなぜ自分がやるのか、また自分がやらなかったとしてもプロジェクトが崩壊しない安心感からコミットが下がりやすくなります。
僕もメンバーとして1回目のリリースを行うときは僕が担当していたサーバサイド（Rails）を書ける人材がいなかったため、「自分がやらないとダメなんだ」というモチベーションが大いに湧いたものです。
この理由も考えれば、一つ上で触れたできないメンバーのコミットが上がる可能性も低いことが予想できます（実際低かったように思われます）。

よく人数と生産性が比例しないと言われますが、これは特に人数が一桁台かつメンバーが学生だと顕著であり、
またここはProduct Manager(以下PM）の実力も影響すると思っていて、

初期段階における生産性 = (人数 ** PMの実力) * 各々の能力の平均

のような関係式が成り立つように感じました（*は積、**は累乗を意味します）。
しかも学生のPMの実力はよくて0（人数が増えても変わらない）、普通に負（人数が増えるほど生産性が落ちる）になると思います（サービスの種類にもよりますが）。

PM力が高い学生などそうそういないので少数精鋭で臨んだ方が良いです（PMとして実力を伸ばすのも、まず人数が少ない状態で仕事を回せるようになってからが良いのではないかと思っています）。
そして必要な役職はエンジニア/デザイナー/PMの順番だと思います（エンジニアがPMを兼務する形が良いです）。

とにかくリリースしてユーザーをつけろ。

僕たちは恥をかきたくありません。質の低いサービスをリリースして、しょぼwwww なんて思われたら鬱になること間違いなしです。

それでもリリースしましょう。
なぜか。

少なくともユーザー数が1以上になるからです。
メンバーの間で、それまで何のために頑張っていたのかわからなかったのが「 今いるユーザーのため 」という明確な目的が生まれます。
ここが学生がサービスを早くリリースするべき一番の理由のように感じます。

学生で、報酬が発生しない案件である以上、頑張れるモチベーションはそう多くありません。
「自分の成長」「やってみたいという好奇心」などの極めて曖昧な目的だと、自分が予想していたよりも遥かに長くつらいサービス開発の過程にまいってしまいます。またそういった目的は思考の煽りを受け安く、すぐに気が変わってしまうことが往々にしてあります。

それらに比べてユーザーがいることはこの上ないインセンティブになります。
またバグなどを見つけた時も対応の早さが異なります。
ユーザーがいなければ、 まあユーザーは気づかないだろうなーという気持ちになりますが、
ユーザーが既にいると、 何としてもユーザーが被害に遭わないようにしよう という気持ちになります。

全てが、付いてくれるであろうユーザーのためではなく、もう付いているユーザーのためになる。

学生であれば、特にこういったメンバーのインセンティブに気を配る必要があると思います。
そのために早くリリースして早くユーザーをつけましょう。

Done is Better than Perfect. - Mark Zuckerberg

仕事ができないと思ったのならその人の生活に思いを馳せよう。

上記でも散々述べていますが、学生同士だと納期が守られない、さらにはメッセージが返ってこないなんてザラにあります。

そういう時こそ、相手の生活に想像を巡らせてみましょう。。。

そうです。他の活動で忙しかったり、その人のモチベーションが低下している姿が容易に想像できると思います。
だからその学生が期待値を超えなかったからといって一概に「あいつは仕事ができない」と決めつけるのは自分にとっても大きな機会損失になります。

I don’t like that man. I must get to know him better. - Abraham Lincoln

定例会議をしない。

定例会議をすることもリスク

有意義な定例会議をするならあらかじめ準備（アジェンダや場所の用意など）が必要ですし、移動のコスト、時間のコストなど人間が思っているよりも多くのコストが発生します。

したがって 定例会議をすること自体リスクだという姿勢を取るべきです。
するにしても極力コストがかからないようにしましょう。
会議についてはこちらの記事なども参考になります。
- 良い会議を行なうには、どうすればよいのか。

実際、僕らも1回目のリリースから2回目のリリースの期間の後半は定例会議はほとんど行いませんでした。しかし定例会議を行なっていた1回目などに比べて 進捗にほとんど影響はありませんでした。

そしてこれは人数が増えると共有のためにせざるを得なくなっていくのでやはりここでも人数の少なさがプラスに働きます。

人の目に触れることの重要性 -ユーザーの流れをシビアに考えよう。

これは上記で述べてきた組織的な話ではなく、アップデートを行う中で何がよかったかを述べたものです。

どこからユーザーが来るのか。

当たり前ですが、サービスはユーザーがいなければ価値がありません。
逆にユーザーがいればサービスとしての価値がぐんと上がります。
そしてユーザー数を伸ばすには単に新規登録してもらうだけでなく、継続的に使ってもらうことが不可欠となります。

作り手の作りたいものを作るのではなく、新規ユーザー数や継続率を伸ばす機能を優先的に実装するべきです（そのためにユーザーがいつどこから来るのかを考えましょう）。
それらを伸ばせればさらにデータがたまり、ユーザーの行動をより正確に把握することができます。
それが1回目のリリースではわかっていませんでした。

2回目のリリースではユーザーの流入を考えて、サークルの活動のメインとなっているSlackにURLと共に通知を飛ばすようにしました。スマホで見ていることも予想できたので、レスポンシブ対応にしました。
今後もメールでの通知やSlackとの連携でメンション機能などを実装する予定です。

こういった流入を考えた機能を増やすことで、まだ2回目のリリースをしてから10日ほどしか経っていませんが、すでにアクティブユーザー数が6倍以上に増えています。

ログは嘘をつかない。

1回目のリリースではスマホではなくPCで見るはずだという仮説のもとPC版のみの実装にしました。
しかし2回目のリリースでレスポンシブにしたことによって、現実は、下の図を見てわかる通りスマホで見る人の方が多かったということがわかりました。
こういったユーザーに関する仮説検証を回すにもいち早くユーザーについてもらうことが必要でした
（ユーザーへのヒアリングなどである程度わかるかもしれませんが、ユーザーも存在していないサービスについて想像を巡らせてヒアリングに答えるのには限界があります）。

これら獲得したユーザーが残してくれたログを見ることで、どういったユーザーがいつ何のページに訪れているかもわかります。それらは今後改善をする上で非常に有用な情報となるでしょう。

最後に

サービス開発の醍醐味はやはりユーザーの声を聞けるということです。
ユーザーの『良いね！』『良いサービスじゃん！』という声は本当にモチベーションになります。
ぜひみなさんも少数精鋭で（あるいは一人で）爆速でリリースして、ユーザーをつけて、サービス開発の楽しさや辛さを知ってみてください！

もしこの記事を読んで何か参考になるところがあればぜひいいねをお願いします。
また何かあればコメントしてください。
ありがとうございました。

関連記事としてよければこちらもご覧ください。
- サークル内部サイト”mates”制作を通じて自分の欲について考えてみた