2017-12-03

初めてチームで開発した感想(2年くらい前の下書き)

色々あって生まれて初めてチーム(4人)で開発したのでその感想をば．あんまりきっちりまとまっているわけではないけれども，~~風化しない内に．~~公開忘れてて2年経ってた

概要

何をした？

既存DBのデータと，センサデータを扱ってデータを表示するWebサービス開発(演習) サービス内容を元に基本設計〜開発まで全て行うことになった．

メンバーの内訳は？

メンバの内2名(僕含む)が学生の頃に趣味で開発経験あり．その他2名はC言語のプログラミングを授業で触った程度．

開発期間は？

2週間

開発環境は？

インターネットのない空間

取り敢えず，環境的には以下のことを速攻で行った．

共有サーバ，Gitリポジトリ，Wikiの設置(GitBucket)
gem local mirrorの構築
開発用仮想マシンイメージの作成(Fedora，Rails開発環境構築済み)

各自のPCが有ったので，そこに仮想環境を構築し，それぞれ統一した環境下で開発を行った．

結果は？

~~実はまだ開発中...まあ何とか間に合いそう．~~

なんとか間に合ったらしい．

難しかったこと

メンバのスキル差

一番つらかった．特にプログラミングをやっていたかどうかでいちいち専門用語を解説しなければならないのが大変だった．

例えば，「JSONを返すAPIを作ろう」なんて言っても通じない．だから一つ一つ説明をしていく必要があった．

一方で，専門用語を解説している内に，自分でも理解や考えが浅かった部分も見えてきて勉強にはなった．「(経験的に)当然こういう設計になるよね」ということを思いもよらぬ角度から指摘されて，よくよく考えてみると無駄が多かったりした．

最後らへんには根気強く解説やフォローを行ったことで他の二名についても自分だけで簡単な実装であればできるようになった．

面倒とか思わずに，相手が納得するまで教えた方が最終的にはお互いのためになると感じた．

情報の共有

今回の開発では，自分たちで考えたアイデアを元にシステムを構築した．当然，ほぼ素人がシステムを構築するので，その過程では仕様変更が多々生じた．それはある程度仕方がないとして，問題なのはそれが全員に共有できていなかったことだった．

特に僕があまり情報発信をしなかったがために，自分でも気づかない内に仕様を変えてしまっていたり，実装が間違っていたりすることがあった．こういうことになると，相手も稼働が増えるし，面倒だしイライラする．

問題解決の策は2つ行った．

一つ，朝の情報共有を必ず行うようにした．システム構成図をホワイトボードに書いて，「今日中に○○の画面が表示されるようにします」「△△と××のシステム間の通信で悩んでいます」といった風に行うこと，困っていること等を共有した．実装内容までは触れなくても，「ああ，Aさんはココの実装をするんだな」「ココが困っているんだな」ということさえ抑えられれば，後は関係者間で話ができるし，後で決定した情報を共有するときにも，全員が前提が分かっているということになってスムーズに事が進んだ．

二つ，決まったことはなるべく情報として誰でも見られるところに明文化しておいた．形式はGit，Wiki，PPT等．Wikiにはサーバ・クライアント間の通信データ形式(JSON)を主に， PPTにはシステム構成図や考えたこと，アイデアなどを書いた． (今思うと，PPTにはその設計に至った経緯についても書いておくべきだった)

こうすることで，一度決まったことをもう一度話し合わなくても良くなり，仕様を見やすい形式で参照しながらコードを書けるようになった． Git，Wikiについては最終的に全員が利用し，仕様変更などもGitにコミット・プッシュ，さらにWikiを変更して伝えるというサイクルができた．「Wikiのどこどこを見て」といった風に共通の言語で話すことができるようにもなった．

(納期，スキルを超えた)システムの肥大化

自分たちで考えたアイデアはなるべくそのまま形にしたい．そういった思いから当初から多くの機能をシステムに持たせた設計を行った．結果，納期ギリギリまで開発を行うことになり，十分なテスト時間を確保することができなくなってしまった．

今回のケースでは，認証用・Webサービス用・データ用等で複数のアプリケーションサーバを構築し，更にサービスに必要そうなデータも滅茶苦茶たくさん想定して設計をした．けれども，結局使われないものが多かった上に，実際のサービスでは逆に不足しているという帯に短しなんとやらな状態になってしまった．あと，サービスが実際に動くのも，最後の最後になってから，という状態になってしまった．

やはり，初めの設計はなるべく機能をそぎ落として，最小限，何があればサービスとして成立するかを考えるべきだったと思う．

サービス構築時は初めから大規模なDBやシステムをたくさん作るのではなく，なるべく少ないデータ種別，なるべく少ないシステムを作ってしまう．そこに後々APIを外部化するなどで徐々に汎用性や再利用性を高める．こうした方法であれば動くものを見て，それに機能追加をしていけるので，マイルストーンも立てやすいし，サービスとしてのブラッシュアップもしやすかったと感じる．ミニマムスタート大事．