1年程前から位置情報を使ったWebサービスを友人と開発してましたが、訳あって離脱することになりました。
この経験を今後に活かすため、この1年でよかったこと・よくなかったことを振り返って、教訓としてまとめてみようと思います。
なお次のとおり趣味で開発した時のお話ですので、お金が絡む開発だとちょっと違うかもしれません。
- メンバー全員自分から参加を希望した。
- 全員プライベートの時間を使って開発を実施。
- 勤務場所は全員ばらばら。土日であれば1時間で全員集合可能。
- 全員ソフトウェア開発に携わる仕事で、Web系が1名、SIerが2名。
この開発に際して便利だったものを下記にまとめてますので、気になる方はどうぞ。
http://qiita.com/canpok1/items/1c86d561e955a8799946
得た教訓
まずは今回得た教訓を。
- CI環境を早めに整えて、機能作成に集中できるようにしよう。
- できるだけお互いにレビューを行って、個人の知見を皆で活かそう。
- 最初はコア機能の完成を目指して、早めに成果を実感できるようにしよう。
- 定期的に振り返りの機会を作って、問題点を早めに対策できるようにしよう。
- 皆の立場や状況を考え発言・行動し、雰囲気良く開発できるようにしよう。
この教訓に至った経緯を以下に記載していきます。
この1年間で行ったこと
開発期間は約1年。何がよくて何がよくなかったのかを思い出すために、この1年間を思い出してみます。
2015年7月
友人Aが位置情報を使ったWebサービス作りたいということで、全部で3名でプロジェクト開始。
週に1回カフェに集まって、仕様の検討や開発言語などの選定を実施。
友人Aがプロトタイプ的なものを作成し、それ以外のメンバーは技術調査やお勉強。
2015年8月
一機能だけがプロトタイプで動くように。 今思うと、最低限の機能の30%くらい。
Herokuを使おうということになっていざデプロイしてみるもwebソケットが上手く動作せず。
この頃は集まらないでLINEで連絡を取り合い、Herokuでうまく動かせるように各自で奮闘してました。
2015年9月
SpringBoot使ったらHeroku上で上手く動きそうだったため既存コードを手直しし、それを元に分担して機能実装開始。
Herokuですぐに動作確認できるよう、CIサービスを使った自動デプロイの仕組みも整えました。
この頃から、
- 毎週末はカフェに集まって作業。
- 作業終わったら必ずプルリクエストを出す。皆から承認されたらマージ。
という進め方が確立。
このやり方で各自のペースで作業し、最低限の機能の50%くらいがここら辺で実装完了。
2015年10〜2016年1月
毎週末は予定が合えば集まって、予定合わないなら自宅で、という感じで進めてました。
最低限の機能の5%くらいが毎月作成完了していく、全体としてはそんなペース。
2016年2月
これまでは「これがあると面白いよね」というものもタスクとして挙げたりして、取り組みやすそうなものをこなしてました。
でも進みが遅いという状況から、遊ぶのに必要な最低限の機能をまず作ろうよという話になり、取り組むタスクを取捨選択。
そこで、3月頃に開発合宿しない？という話になり、このころから合宿終了までに最低限の機能を完成させるのが目標となりました。
2016年3月
2泊3日で開発合宿を実施。
おそらく過去最高に作業が進みましたが、最低限の機能が全て完成とまではいかずに約90%完成で合宿終了。
合宿後は、残件の完了目標日を4月中旬に設定してまたこれまで通り各自のペースで開発続行。
2016年4月
最低限の機能完成が、目標通り4月中旬に完了。
引き続き7月上旬までを目標に、独自仕様の部分を世の中の共通仕様に沿うように変更したり、テストコードを作成するなどの内部のリファクタリング作業を実施。
2016年5月～7月
各自のペースで作業を進めるも7月上旬までには終わりそうにないため、完了目標を10月までに再設定。
合わせて月ごとの中間目標を設定し、それに向かって各自のペースで作業。
2016年8月
7月までの中間目標として設定した作業がほぼ終わらず。
期限は設定せずに各自のペースで緩く進めたいという友人Aと、目標期限日を設定してそれを目安にきっちり進めたいという私とで、今後の進め方に対する考えが割れました。
私が期限期限と言いすぎて雰囲気を悪くしていたこともあり、今後も進め方の考えの違いで迷惑をかけてしまいそうという理由から私から離脱することにしました。
よかったこと・よくなかったこと
これまでの開発を振り返ってみます。
よくなかったことについては、どうすればよくなるかを考えてみます。
よかったこと
- CI環境を早めに整えたこと。テストやデプロイ作業の属人化をなくして機能作成に集中できました。
- プルリクエストによりレビュー実施が徹底できたこと。こうしたら？という改善案を出し合えたり、実装方法の参考になったりしました。
- 定期的に集まって作業したこと。一人で作業するよりも顔合わせて作業したほうが楽しいですし、作業はかどりました。
よくなかったこと
- 最初に取り組んだのが、既存Webサービスで代用可能な機能の作成だったこと。これがないと！という機能作成に取り掛かるのが遅くなりなかなかサービスが使えず、モチベーション低下の原因になってたと思います。
- 最初にどの機能を作るかが曖昧だったこと。各自がやりたいことをどんどん取り入れていった結果、最低限の機能ができるのに時間かかりました。
- メンバー間で進め方に対する共通認識が取れてなかったこと。早く作りたいというメンバー（私）が、ゆっくり作りたいというメンバーの作業ペースに対して不満を募らせてしまう事になりました。
- プルリクエストのマージには全員の承認が必要という約束を、変えることなく進めたこと。職場の繁忙期などでプルリクエストの確認が遅くなると、全体の進みを止めることになっていました。
- 現状の問題点について皆で考える機会を作らなかったこと。自分は問題と思っていても、他のメンバーは問題と思ってないということがありました。
- 雰囲気が悪くする言動があったこと。理解を得られないまま進めようとしたり、何でも否定したり、一切連絡しなくなったりと、雰囲気が悪くなることがありました。
どうすればよかった？
- 最初にコアとなる機能の完成を目指せばよかった。早く成果を実感できればモチベーションの維持につながったはず。
- 最初にどの機能を作るかを明確にすればよかった。作る機能を明確にしておけば成果を出すための最短経路を選択できたはず。今回だと既存サービスで代用可能な機能の作成やリファクタリングは後回しにできたと思います。
- これまでのことを振り返る機会を定期的に作ればよかった。プルリクエストの承認遅れの問題や、進め方に関する不満の解消など、皆で対策を考えれば解決出来たはず。
- もっと相手の立場や状況を考えて発言・行動できればよかった。働いてる環境、知識レベル、やりたいことは皆違いますが、それらを踏まえた言動ができてれば雰囲気が悪くなることは防げたと思います。具体的な改善例を出しづらいですが、多人数での作業では必要なことかなと。
まとめ
友人とのWebサービス開発プロジェクトでのことを振り返って、得た教訓をまとめてみました。
途中で離脱することになり完成を見届けれず残念ですが、会社の業務では試せないような技術を試したりプロジェクト管理に関する多くの知見を得られたりして参加してよかったと思ってます。
何より皆で開発するの楽しかったし 
今後も仕事や趣味で何かしら作っていくはずなので、今回得られた教訓を活かしていこうと思います。
こういう時はこうしたら？みたいな意見があれば、教えていただけると幸いです。