BETA

週末プロジェクトを失敗させないためのガイドライン

投稿日:2019-02-20
最終更新:2019-02-20

このガイドラインはこれからチームで週末プロジェクトをはじめる人に向けて書かれています。

チームガイドライン

まずは週末プロジェクトの基本であるチームビルディングから。

能動的に稼働しそうな人だけをアサインする

稼働しない人をアサインしたらチームの士気が下がり、疑心暗鬼とヘイトが蔓延します。言わないと動かない人も管理コストが高いのでアサインを避けましょう。アサイン後コミットしなくなった人は早めにキックしましょう。メリットと目的をもって能動的にコミットできる人で固めることが大前提です。

メリットを明確にする

  • 実績になる
  • バズったら有名になる
  • 技術の幅が広がる

など、参加するメリットを明確にしましょう。ムードが乱れたら「なんのメリットがあってここに参加したのか?」を再確認しましょう。

明確で実現可能なゴールにする

2か月以内に完成するレベルの現実的かつ具体的なゴールを設定しましょう。「なんとなくすごいものを作ろう」だと終わりが見えないのでだらける率が高いです。たとえば以下のようなゴールが良いでしょう。

・このフレームワークを使って来月中にトランプゲームを作る
・ログイン機能があるミニチャットツールを4月までに作る

技術的に実現困難なものは避け、機能が膨れて長期プロジェクト化しすぎないように注意しましょう。まともなプロダクトにしたいなら後述のワークフローを参照してください。

タスクの重みを認識させる

「暇な時にできる人がやろう」だとまず誰もやりません。まずは明確に「誰が」「いつまでに」「何を」するかを決め、各々にそれを守る認識をもたせます。期限内に完了できない場合は事前に報告を促すなど、最低限の緊張感を持たせましょう。

週間MTG(グループ通話)で進捗確認をする

マストです。これがないと翌週には誰もコミットしてません。MTGに毎回出ない人や毎回タスクをやってこない人はキックしましょう。

参加前のチェックリスト

参加者には次のチェック項目を確認してもらいましょう。友達や同僚でもチェックを満たせないのであれば招待を見送りましょう。さもないと今後の関係値が悪化することになります。

参加することで得られるメリットを理解している
リリースまで当事者意識をもってコミットする覚悟がある
自分の意思で参加している
自分のタスクは責任をもって完了させる
コミットできなければ離脱する

招待テンプレート

週末プロジェクトにメンバーを招待する際に使ってください。

よければ週末プロジェクトに参加しませんか?  

ゴール: ?月までに?ツールを作る  
技術スタック: ??  
メリット:  
・?言語(フレームワーク)の実績ができる  
・技術の幅が広がる  
・バズったらテンション上がる  
ルール:  
・毎週土曜14:00~16:00で定例MTG  
・MTG不参加やタスク放置が続いたらキック

ワークフロー

技術研鑽だけが目的ならワークフローは無視して構いませんが、何かしら使われるプロダクトを作る場合は参考にしてください。

課題の設定

プロダクトとして成立させたい場合、解決したい自分の課題を具体的に定義する。課題設定が甘いとログポースを持たずにワンピースを目指す状態になり、進路がぶれぶれになる。

たとえば「コレステロールが高い」という課題があるとして、そのままだと抽象的すぎるので解像度をあげていく必要がある。この時点では解決策は考えない。ひたすら課題の解像度をあげていく。

  1. コレステロールを下げる方法がわからない
  2. コレステロールを下げる食材があるらしい
  3. 毎食低コレステロールメニューを考えるのがめんどくさい

このように、「コレステロールを下げたい」という抽象的な課題が解像度を高めることで、「低コレステロールメニューを考えるのがめんどくさい」という具体的な課題にいきついた。

解決策を定義

次に、選定した課題をどうやって解決するか考える。「低コレステロールメニューを考えるのがめんどくさい」という課題の場合、

「低コレステロールメニューの組み合わせを毎日昼にアラートする」

と、解決しそうだ。もっというと「最寄りのコンビニで手に入るメニュー」であり、「最寄りのコンビニ」の場所もセットでアラートされるとよりアクションに繋がりやすい。また、同じメニューだと飽きるので毎日違うメニューであるとより良い。解決策としては「低コレステロールメニューをレコメンドしてくれるアプリ」を作ればいいのだ。

MVPを作る

MVPとは必要最低要件を満たしたプロダクトのこと。いきなりコーディングやデザインをはじめるのではなく、まずは「仮にそれがあった場合、本当に課題解決になるか?」を検証する。エンジニアやデザイナーは得意領域で早々に着手しがちだが、MVP検証をしっかりやっておかないと、頑張って作ったけどゴミだったという結末になる。今回の例の場合、

  1. コンビニの低コレステロールメニューをスプレッドシートに羅列する
  2. GAS(スプレッドシートのマクロ)で毎日昼頃にメニューをランダムに組み合わせてメールする

これだけでできそうだ。エンジニア以外でも1日程度で完成する。数週間かけてたいそうなアプリをスクラッチする必要はない。まずはこれで課題&解決策の検証ができる。

その結果「しばらくしたらメールを無視してゴミ箱に入れる習慣がついた」場合、当初定義した課題は間違っていたことになる。正しい課題としては「低コレステロールメニューがわかっても、購入に至るモチベーションが湧かない」だと言える。

そうすると解決策も、

「低コレステロールメニューの購入済みレシートの写メをとってアプリに認識させないと、毎日100円が自動的に友達(恋人)に送金される」

といった具合に変化する。MVPとしては友人や恋人に協力してもらい、LINEで写メを送らなかったら100円LINE PAYを送金するという口約束をしてみればいい。おそらくだがこのMVPは最初のMVPよりまともにワークするだろう。

このことから分かるようにMVP検証は非常に重要で、これをサボるとみんなで頑張ってゴミを作ることになる。開発前にこれから作ろうとするものがゴミでないと確信が持てるまで、MVP検証を繰り返そう。

プロダクト開発で最も重要なのはここまでのフェーズで、課題確定後は作業的に開発を進めていけばいい。モダンな技術スタックで楽しく進めよう。

オススメツール

  • Trello - カンバンでライトにタスク管理できる
  • Notion - 込み入ったプロジェクト管理がしたいなら
  • Slack - 推奨。GitHubやTrelloのアクティビティをチャンネルに流そう
  • GitHub - オープンソースのほうが緊張感あってオススメ
  • ハングアウト - MTGにオススメ
  • リアルタイムボード - オンラインホワイトボードでブレスト

最後に

よほどリテラシーが高いメンバーでない限り、「気楽に楽しく、ぼちぼちやってこー」という雑なモチベートでは空中分解します。うまくいかないどころかお互いにヘイトが溜まり、その後の関係に響くこともあります。また、最低限の課題検証を行わないと「使われないものを作ってしまう」リスクもあります。

「ちょっと仕事的だなー」と感じるかもしれませんが、週末プロジェクトは「サイドワーク」ぐらいの緊張感をもって臨むとちょうど良いと思います。せっかくやるなら最後までやりきって、誰かしらに使われるものを作りたいですよね。

それでは、良い週末プロジェクトライフを!

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

About Web Service

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう