こんにちは!好奇心おばけのかわそん (@KKohey4)です!

本記事を読むメリット
- 初心者が4日間、共同で開発を進めていく、リアルな過程がわかります。
- チーム開発で実際に起きたトラブルを紹介します。[対処法も]
- 共同開発で知っておくべき、最低限の知識がわかります。
この記事を書いている僕は、Life is Tech!というプログラミング教育会社で、大学生メンターとして働いています。
今回は、GWの4日間、静岡県の伊豆でチームを持って、実際の自治体が抱えてる問題にITからアプローチしてきました。
そこで 企画→実装→プレゼン という流れを経験した、僕自身の学びや反省を共有します。
皆さんがチームで開発する時、少しでもお役に立てれば幸いです。(^_^)a
※必要なGit知識だけ知りたい場合はこちらをどうぞ。
[共同開発]Gitを使って自治体の課題解決に取り組んだ[Life is Tech!]
4日間の大枠は
- Day1: 自治体が抱えている課題の把握
- Day2: 課題へのアプローチ・企画の決定
- Day3: 共同開発の開始、トラブルの発生
- Day4: プレゼンをして解決策をアピール
っていう感じです。
その日のツイートを深掘りしつつ、説明しますね。
Day1: 自治体が抱えている課題の把握
共同開発Day1
・課題から解決の過程は無限に話し合えるのでスピード感や踏ん切りは必須
・web→アプリへの誘導とかは自然さ、メリットの提示が大切
・自治体の抱えてる問題はかなり深刻
とかとか学びが多かった.大人数の便利さやコミュニケーションコストのもどかしさとかを感じられるからいい経験😌
— かわそん/Web大好きマン (@KKohey4) 2019年5月1日
実際の自治体が抱えている課題をプレゼンしていただき、インタビューを通して理解を深めました。
ここで気づいたのは、
っていうことですね。
絶対的な答えがないので、いくらでも時間はかけられるのですが、提出期限は迫ってきます。。。
企画を膨らませつつも、妥協点を打つことが想像以上に大切でした。
Day2: 課題へのアプローチ・企画の決定
共同開発Day2
・期限あるプロダクトの場合、想像力
は最大、創造は最小で
・コア以外の機能をそぎ落としつつ
目的から逸れたりズレないように
・まあコンフリクトは起きるので、
完全に防ぐ事を目指すより対応力を.令和初日から学び多いスタート、今日もみなさんがんばりましょ!
— かわそん/Web大好きマン (@KKohey4) 2019年5月1日
令和初日、課題を踏まえて、具体的な企画を考えました。
この日に気づいたのは、
っていうことかなと。
「期限内に自分たちがどこまで実装できるか」を見誤ると、中途半端になっちゃうんですよね。
課題解決のためのコア機能を見定めつつ、周辺機能を削ぎ落としていく。
お互いの能力を確認しつつ、実装計画をすり合わせるフェーズ、大事です。
Day3: 共同開発の開始、トラブルの発生
共同開発Day3
・膨らませた企画案を目的から逸れな
いように注意しながら絞ってく
・期間が迫ってくるとコミュニケーシ
ョンが感情的になりがち
・灯台下は暗い、気づくはずの箇所に
普通に穴が空いてる最終日はリスクを取らずブラッシュアップにフォーカスすべき😌#プログラミング
— かわそん/Web大好きマン (@KKohey4) 2019年5月3日
課題→企画ときて、いよいよ実装に入ります。
当然ですが、この段階でめちゃいろんなトラブルが起こりますね。
具体的には
- コードのコンフリクト
- コミュニケーションが感情的になる
- 視野が狭くなる
などなど。ちょっと解説します。
①コードのコンフリクト
コードの同じ箇所を違う人がいじると起こります。
事前にすり合わせていても、起きます。技術的な対処法は後ほど。
②コミュニケーションが感情的になる


っていうことが起きます。
TODO | DOING | DONE |
かわそん、ヘッダーデザイン | かわそん2,ボディデザイン | かわそん3,ボディーコード |
こんな表をつくって、お互いの進捗を把握するのが大事でした。
③視野が狭くなる
普段なら気づくはずの事に気づきにくくなります。
広いことを考えるので、基本的なことを見落としがちになるんですよね。
例えば、今回Umer,Umer Eats,Umaw というフェイクアプリとニュースサイトを作りました。
でもニュースサイトをUma Picksという名前にした方が統一感がでるということに気づかなかったんですよね。。。
話し合ってるときは、足元が暗くなりがちっていう視点は持っておくべきかなと。
Day4: プレゼンをして解決策をアピール
共同開発Day4
・伝わる言葉≠伝える言葉、魅力を伝え
きる努力の手を抜くべからず
・強みを活かして弱みは助けてもらえ
る共同開発、コミュコストは抑えるべ
き(Git技術)
・自分の危機感≠チームのメンバーの危
機感、納期がある時はバッファ
を大きめに
また記事として共有します😌— かわそん/Web大好きマン (@KKohey4) 2019年5月3日
開発で力つきた、、、っていう気持ちはわかりますが、作るだけじゃ意味ないです。
かなと。
というのは、自分たちにとっては当たり前でも、他人にとっては馴染みないことだったってことは、割とよく起きるんですよね。
そのギャップを埋めつつ、魅力を伝えきって初めて、正しく評価されるステージに立てます。
Gitを使って完成したプロダクト
Day1~Day4で結果作れたプロダクトは合計5つです。
福島県南相馬市を、馬を通してPRしました。
※すみません、著作権の関係でサービスの写真は貼れません。。。概要と技術を紹介しますね。
①UmarとUmar Eats、Uberのフェイクアプリ
「動いている馬」を感覚的に知ってもらうために作りました。馬が地図上を走り回っていまして、タップすると詳細情報が見れるようになっています。
canvasを使って、親しみのわくようなアニメーションを実装しています。
②Umaw, Snowのフェイクアプリ
「馬との身近さ」を感じてもらうために作りました。カメラロールに保存された顔写真や、その場で撮った顔写真と馬を合成します。
今回はSwiftを使って、ios用に作りました。
③馬ニュースを町民が投稿、編集できるサービス
「町民も楽しみながら周知を」ということを狙って作りました。実際にあったことでもいいですし、おもしろフェイクニュースでもOKです。
基本的にPHPで実装して、AWSでインスタンスを立てました。
共同開発初心者が、実質開発時間1日でここまで作り上げられたって、かなりすごいのではないかなと。
共同開発で最低限知っておくべき知識[Git]
今回僕がチームを持って、masterブランチを管理したのですが、役に立った知識は3種類です。
- Pull Requestの送り方←reviewers と assigneeも
- ブランチの概念←共同開発初心者がいる場合は説明必須
- マージの仕方(少人数ならレビューは口頭でOK)
開発のコミュニケーションコストがガクンと下がるので、Git周りの周辺知識は超大事だと感じました。
僕が事前にやり込んでおいた本はこれです。
※この本やり込めば困ることは無いです。Jenkinsなどの便利なサービスも紹介されていますし。
もし中途半端な状態でチーム持ってたら、、、と考えるとゾッとしますね。。
共同開発やるなら必須かなと。
まとめ: 共同開発はどっちにも転びます
記事のポイントをまとめておきます。
- 正確な課題の把握は大事、時間をかけるべき。
- 企画立案はいくらでも話せるので、どっかで踏み切りを。
- 「伝える」努力をサボらないように
- 気をつけてもトラブル起きるので、心と技術に余裕を。
こんなところですね。
共同開発では 必ずしも1+1=2にならないです。
コミュニケーションコストが高ければ1+1<2にもなるし、強みを組み合わせられれば1+1>2にもなるんですよね。
個人の能力を最大限発揮できるような、そんな体制を整える大切さを身をもって勉強できました。
この体験が、これから共同開発をしようかなと思っている方にとって少しでも参考になれば幸いです。