弊社の開発手法とその変遷について
株式会社var CTOのsleekです。
こちらの記事では、弊社の開発手法の変遷について書きます。
スタートアップにおけるリアルな開発手法として参考になれば幸いです。
概要
- チーム開発未経験が多いスタートアップでのリアルな開発手法について
- どのようにして開発手法を変えていったかについて
まとめ
- いきなり大きなプロジェクトのやり方を真似しない
- 手探りで少しずつ新しい手法などを追加していく
背景
弊社では、オンラインハンズオン学習プラットフォームであるEnvader(エンベーダー)やRareTECH(レアテック)受講生向けのポータルサイトどの開発を行なっている。
この二つのシステムの開発は両方合わせて5, 6人程度で行っているが、チーム開発の経験が豊富な人はほぼいないに等しい。この環境の中いきなり世の中に溢れている様々な開発方法をふんだんに取り入れたところでうまく仕組み化できず機能しないことが目に見えていた。特に様々なブランチ戦略やCI/CD環境の構築などは整えられれば強力ではあるものの、弊社で開発がスタートした時に無理に取り入れると、むしろコストがかさむだけになってしまう。このことを考慮して逆に0からスタートして少しずつ色々な手法を追加していく方針にした。
前提
弊社プロダクトの仕様
| Envader（エンベーダー） | RareTECH Portal（レアテックポータル） | |
|---|---|---|
| インフラ | GCP GAE + CloudSQL + GCF | AWS Elastic Beanstalk + RDS |
| 言語 | Vue/Go | React/Django |
弊社での開発手法の変遷
現在でも、まだまだ課題は残っているが、チーム開発未経験の人やこれからチーム開発のやり方に悩んでいる企業などの参考になればと思い、行ったことを記録していく。
Envader(エンベーダー)の個人開発
開発当初は1人で開発を行っていた。開発するにあたってGit管理はしていたものの、全ての作業をmainブランチ内で行っていたため、Gitは ただのバックアップツール と化していた。ブランチについても特に作成する意義が見つからなかった。
タスク管理については初めTrelloを活用していたが、ほとんどメモ状態であり、そこまで機能はしていなかった。
後から振り返ってもこれをやっておけばもっと効率的にできたという点はそこまでないため、個人開発ということであればそこまでやるべきことは多くないのではないかと考えている。もちろん慣れている方であればGit管理やCI/CDなど様々な技術を取り入れることが大変ではないため、自分のレベルなどに合わせて考えるのが大事である。
Envader(エンベーダー)の2人での開発
2人での開発について書く。2人で開発をする上でソースコード管理は必須であったため、AWS EC2上に構築したGitlabを導入した。Githubを使わなかった理由については記憶が曖昧だが、Privateリポジトリに関する制約などであったと記憶している。
タスク管理についてはTrelloからGitlabに移行してはみたものの、Issueの扱いやブランチ戦略などを定めていなかったため、ほとんど機能せず、結果的にはかなり適当な管理になってしまった。考えられる原因として考えられることは、 そもそも開発経験が少ない少人数で開発をする場合、Slack等のコミュニケーションツールでタスクを共有し、お互いが勝手に実装していっても十分機能するため、下手に取り入れたところで管理コストに対してメリットを得られないということであった。また、直接プログラムに関係しないようなタスクがあった場合にそのタスク管理も扱いが難しくなるため、適当になってしまった。結果的に個人や超少人数で開発をする場合は適当なメモなどで管理するだけで十分であるという結論に至った。
ブランチ戦略については特に何も設けておらず実験的な機能以外は基本的にはmainブランチをお互いに編集しコミットしていた。
コードのデプロイについてはシェルスクリプトなどを作成して手動で行っていた。これについては特に問題点はなかったと感じている。
CI/CDを取り入れることの検討
ある程度開発も順調に進んでいた上、利用していたGCPのサービスにも慣れてきたため、近年流行っているCI/CDを導入してみるかの検討を行った。
以下に大まかな検討事項を記載する。
- そもそもこの時点ではCI/CDツールを利用したことがなかったため、インフラ環境として利用していたGCPへどうやってデプロイするかがわからず、かなりのコストがかかることが予想された。
- そもそもGitの運用すらちゃんとできていないため、CI/CDを取り入れるベースとなる状況を整えられていなかった。
- 自作のシェルスクリプトを利用してデプロイすること自体のコストはそこまで高くなかった上に公開しているサービスでもなかったため、失敗した時の影響も少なく、この段階でCI/CDを取り入れるメリットもそこまでなかった。
以上を鑑みてCI/CDを導入するメリットは経験になるということ以外はなかったため、導入を見送ることにした。
Githubへの移行とCI/CD導入
Envaderのベータ版を一部に向けてリリースしており、開発は順調に進んでいたが、弊社のスクール事業であるRareTECH用のポータルサイトをAWS上に構築してリリースすることが決定し、全体的なコードやタスク管理方法を見直すことにした。
ソースコード管理
ソースコード管理はGithubに移行した。これはGCP・AWSのコード管理ツールを利用し、どちらかに依存するより中間をとったほうがメリットがある上、圧倒的な情報量の観点で優位であることを考えて決定した。
RareTECH用ポータルサイトはファーストリリースをするまでの間特にブランチ戦略などは設けず、個人が作業用ブランチを作成し、適当なタイミングでmainブランチにマージをするという流れて開発をしていた。本来はルールを最初に設けたほうがよかったかもしれないが、開発経験がそこまで多くない人からするとブランチ戦略を導入して解決される問題自体の経験をするという意味で悪くなかったと感じでいる。
ファーストリリース以降のブランチ戦略については後述する。
開発・本番環境とCI/CD
ポータルサイトはコストの問題で開発環境をAll in OneのEC2で、本番環境はElastic Beanstalk + RDSで運用しているが、デプロイ作業がかなり煩雑になってしまったため、ここではじめてCI/CDを本格的に導入することを考え始めた。導入にあたっていくつかのツールを調べたが、結果的にはGithub Actionsに必要な機能は全て用意されていたため、これを利用することに決定した。
一般的にCI/CDは最初に取り入れることが良いとされているが、未導入での開発を経験したことがない人達の中でCI/CDを取り入れるメリットはあまりない気がした。そして今回取り入れた結果はじめてメリットや仕組みを理解できたため、無理して初めから取り入れるよりも、問題が生じたタイミングで取り入れることを検討するのが良いという結論に至った。
新たなブランチ戦略
CI/CDを取り入れたタイミングでブランチ戦略について検討した。開発人数が増えたところで5, 6人であったためブランチ戦略自体はかなりシンプルなものにした。
概要は以下の通りである。
- mainブランチ
- 本番環境と連動
- developブランチ
- 開発環境と連動
- features/#Nブランチ
- 各issueと連携させたブランチ
Issueとプルリクの扱い
デプロイの自動化とブランチ戦略を立てたことでようやくissueやプルリクを適切に利用する環境が整った。それまではNotionとissueでタスクがバラバラになっていたが、issueベースでタスクを管理するという体制が整ったことでNotionはドキュメント、issueはタスクといった役割分担を適切に行うことができた。また、少しずつGithub Actionsにも慣れてきたため、プルリク発生時にリンターのチェックを入れ、コード規約違反などを適切に判定するといったような開発効率を上げるような機能を導入できるようになった。
まとめ
以上が弊社での開発手法の変遷である。弊社ではチーム開発経験豊富な人がいなかったからこそ逆に各企業が取り入れている開発手法のなどを単に真似することはしなかった。これによりメリットデメリットを検討した上で一つ一つの手法を取り入れることができ各フェーズに応じた適切な開発手法を取り入れられたと感じている。一見無駄が多いようにも思われるが、一つ一つのツールが存在している背景やチームにもたらす恩恵などを適切に検討できたことで非常に有益な経験を積むことができたと思っている。また、これは最初から用意されているチームに合流することではできなかった経験であるため、個人開発や未経験の多いチーム開発などでは是非検討してほしい要素である。
弊社は現在も新規に導入する要素がないかを検討中であるため、また更新があれば今回のように発信していく予定である。
Discussion