開発合宿でのチームの回し方

こんにちは、アプリケーションエンジニアの id:shimobayashi です。

先日はてなでは開発合宿が行われ、私はエンジニアでありつつもその傍らでディレクター業にチャレンジという形で3人のチームに参加しました。
そんな開発合宿の振り返りを通じて、何かチーム開発のヒントになればと思いこの記事を書くことにしました。

なお、この記事ははてなエンジニアアドベントカレンダーの11日目です。

いきなり崩壊

まずはチームビルディングですが、結果からいうと崩壊しかけました。


やることを決めずに3人でチームを結成*1してしまったので事前の準備として、

  • 目標を設定
  • 目標を踏まえて、取り組むテーマを設定
  • テーマを踏まえて、サービス案を決定

というアプローチでサービス案を決めようとしました。
妥当なサービス案を考え出すことを狙ったアプローチです。
しかし、いよいよサービス案を決定する段階になって「テーマが不適切だ」というちゃぶ台返しが発生し、議論が紛糾してしまいました。


開発合宿の性質上、全員がやりたいと思えるサービス案であることが重要なのでこのままでは進めません。


そうしてよくよく話を聞いてみると、このチームにとって本当に重要な目標は「自分たちがおもしろいと思えるサービスをつくり出す」ことだと分かりました。
したがって先ほどのアプローチを取り止め、

  • テーマなど決めずに全員が簡単なサービス案を付箋に書き出して、全員がおもしろいと思ったサービス案を採用する

という直球のアプローチにしたところ、30案ほど出た中でなんとか1案だけが採用されました。


本来のウェブサービス開発であればこのようなアプローチを取ることはまずありませんが、今回は開発合宿ということでそれに合わせた形になりました。

サクサク開発

開発自体は非常に順調でした。

最初に3人で画面遷移図を描いて完成のイメージを共有した上でタスクを書き出し、タスクの優先度を「発表会で優勝する」という目標のもとに納得感を持って決め、カンバン方式でタスクを処理していきました。
また、効率性を重視し手慣れたSinatra+CoffeeScript+MongoDBを使ってHerokuで動かすことにしました。
そうすることで、実働時間内で優先度の高いタスクをこなしていくことで無理なくサービスをつくることができました。

f:id:shimobayashi:20141208163804j:plain

時にはペアプロで開発を進め、認識のブレを解消しました。
気分転換に3人で琵琶湖の周りを散歩をして、良いアイディアが浮かんだので戻って実装するということもありました。

f:id:shimobayashi:20141208161938j:plain

特別なことは何一つしていませんが、うまくチームを運用できたように思います。
そうした結果、最速*2で合宿内リリースをすることができました。
存在感のアピールができ、コンテンツを事前にストックすることで発表会の準備にもなりました。

まとめ

こうしてサービスをつくりあげ、発表会では10候補中2位をいただきました。独特なおもしろさのあるサービスに仕上がったと思います。
このサービスをはてラボで皆さんに使っていただけるようにブラッシュアップを進めておりますので、今後のリリースにご期待いただけると幸いです。


このように、失敗しても良い場所で自分を試せるというのは開発合宿の良さの一つです。
今回上手くいった考え方を振り返ると、やはり「ゴールを常に意識する」ことの大事さを改めて認識しました。


はてなでは、一緒にサービスを開発する仲間を募集しています。

*1:エンジニア+エンジニア+デザイナーの3人構成。ちなみに、前回の合宿プロダクトである大承認と同じメンバーです。

*2:開発合宿2日目のお昼ごろ。ちなみに、前回も最速リリースでした。