14卒入社の "コードを奏でる笛吹" です。
入社したその日から、さっそく社内システムの開発をしています。
Speeeのチーム開発
Webサービスやシステムの開発の仕方には、いろんな方法があります。
バージョン管理はどうするのか、プロジェクト管理はどうするのか、どうやって情報共有していくのか…
チームで開発するときには、決めておかなければいけないこともたくさんあります。
そこで今回は、Speeeでの開発フローの例をご紹介します！
Speeeの開発工程
ソフトウェアの開発工程を標準化して、1つのモデルとしたものをソフトウェア開発モデルといいます。
ソフトウェアの作業工程は「要件定義」→「設計」→「実装」→「テスト」といった作業単位に分けることができます。
ソフトウェア開発モデルはシステムをどう作っていくかというスタイルなので、システムの規模や開発期間などに
よっても変わります。
その中でも、代表的なソフトウェア開発モデルとしては、ウォーターフォールモデルがあげられます。
ウォーターフォールモデルはその名の通り、要件定義、設計、実装、テストの順に上流から下流に流れるように開発を進める手法で、前の工程には戻らないことが前提となります。
Speeeの開発はこれとはほぼ逆で、「アジャイル開発」を行っています。
タスクは小さい単位に分けて、それぞれに対して要件定義、設計、開発、テストを連続的に取り組んでいきます。
必要に応じて前の工程に戻ったりもするので、「完璧に要件定義をしてからじゃないと設計できない」ということはありません。アジャイル開発は、状況に応じて流転するニーズ駆動型開発ともいわれているように、必要に応じて柔軟に対応できることが利点となります。
その分、開発の際には拡張性などにも十分気を付ける必要はありますが、作りこむことでどんどんいいものができてきます。
アジャイル開発では、1週間ごとなどの短い期間で成果をあげることが重要となるので、要件定義からテストまでを小さいタスクごとに並行していくつも行っていくのです。そのため、開発スピードはすごく速いです！
チームの人数はプロジェクトによっても異なりますが、3人～12人程度の比較的少数で行います。
プロジェクトマネージャーやディレクター、エンジニア、デザイナーなどがいますが、チームによってはエンジニアとプロジェクトマネージャーしかいないようなこともあります。
そういうときは、エンジニアも要件定義を書いたりと、臨機応変なチーム構成となっています。
Backlogによるチケット管理
Speeeでは、クラウド型プロジェクト管理ツールであるBacklogを使って開発していきます。
タスクをすべてチケット化することで、実装担当の振り分けや実装漏れの防止を簡単に実現することができます。それぞれのチケットごとに「未処理」「処理中」「処理済み」「完了」と状態を変更することができ、チケットの状態を見ることでプロジェクトの進捗度も把握しやすいのもチケット化の利点となります。
チケットがある程度終わるごとに、そのチケットの実装内容についてのテストが行われます。そして、バグがあればその都度チケットはエンジニアのもとに戻ってくるので、適宜修正していくのです。
また、チケットを消化している間にも、新たなチケットは増えていきます。
このように、実装とテスト、要件定義を平行して行うことで、開発にスピード感が生まれます。
チケットを作るときは、チケット名を工夫するとその後の管理がしやすくなります！
Backlogではチケットの検索ができます。例えば「【ページ名】【機能名】どのように修正するか」といったように、ページごとや機能ごとにキーワードを入れておくと、ページごとや機能ごとに検索することで、それぞれどのように開発してきたのかという情報を見ることができます。
アジャイル開発では、要件はどんどん追加され、変化していきます。チケットをうまく使えば、その軌跡を追うこともできるのです。
gitによるバージョン管理
開発を行うときに重要なバージョン管理には、分散型バージョン管理システムのGitを使用しています。
以前は集中型バージョン管理システムのSVNを使用していましたが、Gitのほうが複数人で並行して開発する時には最適なので移行しました。
Gitでは、サーバにリモートリポジトリを置き、エンジニアがそれぞれローカルにリポジトリを作成することもできます。
まず、リモートリポジトリから最新の情報をpullしてきます。pullすると、その情報がローカルリポジトリに反映されます。そこで、新しくブランチを切り、チケットごとに実装を進めます。実装したソースは、ローカルリポジトリに対してcommitやmergeをします。そして、ある程度実装したらリモートリポジトリにpushすることで、自分の実装をリモートにあげて、みんなで共有できるようになります。
ブランチの切り方にはチームごとにやり方がいろいろあると思いますが、私のチームでは下記のような切り方をしています。
まず、masterブランチを用意します。これは本番環境で動かす用のブランチです。
次に、releaseブランチを用意します。これはステージング環境で、本番環境に反映するためのテストを行うためのブランチです。
そして、開発用にdevelopブランチを用意します。実装時には、このdevelopブランチを基に、チケットごとにどんどんブランチを切っていきます。
developから切り出したブランチは、実装が完了したらdevelopにmergeします。そして、developをpushすることで、リモートリポジトリに反映させていきます。
複数人で開発していると同じクラスをいじっていてconflictが起こることもありますが、conflictができるだけ起こらないように、あらかじめ一緒に開発しているエンジニアと連携して、お互いの開発部分が重ならないように進めていくことが重要となります。
できるだけconflictしないようにするためにも、チケットは詳細化する必要があるのです。
ステージング環境に反映させたいときには、developをreleaseにmergeします。ステージング環境に実装を反映させたら、そこでテストを行います。
ステージング環境では、本番環境と同じデータを使い、本番環境と同じ状態でテストを行います。こうすることで、バグを発見したり、使いづらいなどの要望が出てきたとしても、本番環境に影響を与えることなく修正することができます。
バグはdevelopから再度ブランチを切り出して修正し、releaseに再度mergeして再テストを行っています。
テストをしてバグがでた場合、一般的にはreleaseからブランチを切って、修正を行うと思います。
今回ご紹介している開発例は、私が新卒として初めて関わったプロジェクトです。
新卒2名で全社向けのサービスを作っていますので、masterに反映されるreleaseの品質担保のために、修正をdevelopでまとめて行っております。
こうすることで、全体に反映させたいような修正点が複数あった場合でも、developであらかじめ切り出して開発していたブランチへの修正反映も管理しやすくなるという利点もあります。チームの状況に応じて自由にブランチを切っているのです。
テストもバッチリ！という状態になったら、releaseをmasterにmergeします。
そして、masterをpushすることで、リモートリポジトリの本番環境に実装を反映させることができます。この作業がいわゆるアップデートになります。
このように、基本となるブランチを複数用意することで、リリースされてるアプリなどに影響を与えることなく、並行して実装を進めていくことができます。ちなみに、もし致命的なバグが発見されても、バージョン管理されているので、ひとつ前のバージョンまで戻したりなど、臨機応変な対応もできるのがGitのいいところですね。
情報共有の仕方
開発を進めていく上で重要なのは、チケット管理やバージョン管理だけではありません！
Speeeでは複数人で開発をし、タスクも小さく分けて、同時進行でどんどん進めていきます。
すごいスピードで開発が進んでいくので、日常的にしっかりと情報共有することが重要となってきます。
要件定義や設計などの情報は、このBacklogのWikiなどに記録しておきます。
Wikiで情報共有することで、ディレクターとエンジニアの連携も非常に楽になります。
Wikiは要件定義以外にも、共有しておきたい情報も適宜書いていきます。アジャイル開発では、人の入れ替わりも少なくありません。担当者が抜けた場合、次の担当者に引き継ぐ場合の資料としてもとても役立ちます。
情報共有の手段としては、Chatworkというクラウド型のコミュニケーションツールも大いに利用しています。近くにいない人に聞きたいときや、文章で聞く必要があることに関しては、メッセージを送って気軽にやり取りをします。
もちろん、WikiやChatworkだけではなく、直接聞きにも行きます。
実はこれ、けっこう大事なんです。直接会話をすることはコミュニケーションの観点からもとても重要なので、遠慮せずに話しかける習慣がみんなついています。
チーム開発ではそこまで人数も多くないし、直接聞いた方が早かったりもします。こうやって日常的な会話の中でも情報共有が行われているので、リスクの可能性の察知やプロジェクトの状況把握などがしやすい環境となっています。
コミュニケーションを密にとることで、潜在的な要件を前もって引き出すこともできるため、常に意識してコミュニケーションをとることが重要です。
おわりに
アジャイル開発でスピード感をもってプロジェクトをまわしていくときに、一番重要になってくるのは「連携」です。
BacklogやGit, Chatworkなどは、すべて連携のための手段でしかありません。どう使うかはチームの自由ですが、「このチームでうまく連携するためにはどう使えばいいのか」ということを考える必要もあります。
今回はSpeeeの開発フローを簡単に説明しましたが、チームごとにうまく連携するための施策は他にもたくさんあります。
それぞれが一番いいやり方を追求し、開発を行っています。私も、チームにとって一番良いやり方を早く見つけられるように、いろいろ試していきたいと思います！
