マイクロアドでアプリケーションエンジニアをしているタカギです。
今回の記事では、マイクロアドでどのような流れで開発が行われているのか、について記事を書いていきたいと思います。
システム開発本部の組織構成
まず、システム開発本部がどのようにチーム分けされているのか、見ていきましょう。 システム開発本部は大きく4つのグループ（プロダクト開発グループ／基盤開発グループ／IT戦略グループ／Tech Lab）に分かれており、プロダクト開発グループはさらに6つのユニット（ディレクションユニット／第1-4開発ユニット／データサイエンスユニット）に分かれています。
それぞれのチームの主な役割を簡潔に書いてみました。
- プロダクト開発グループ
- ディレクションユニット：ビジネスサイドとのやり取り、開発のとりまとめ
- 第1開発ユニット：広告配信処理(DSP)の開発
- 第2開発ユニット：広告配信処理(SSP)の開発
- 第3開発ユニット：画面の開発
- 第4開発ユニット：バッチ処理の開発
- データサイエンスユニット：機械学習などを用いたデータ利用のための研究・開発
- 基盤開発グループ：インフラ基盤の開発および運用保守
- IT戦略グループ：社内IT関連のサポート、監査
- Tech Lab：関連技術の調査・研究、各ユニットの技術サポート
タカギは第4開発ユニットに所属していますので、アプリ開発者目線で開発の流れを書いていこうと思います。
各チームと連携して開発を進めていきますが、開発の過程で最も関わることが多いのはディレクションユニットです。
ディレクションユニットに所属しているメンバーはディレクターと呼ばれていますが、この記事でもその名称を使用していきます。
プロジェクト管理
マイクロアドでは、プロジェクト管理ツールとしてJIRAを使用しており、そのなかでも特に、「カンバンボード」1をメインで使用しています。（一部のチームでは「スクラムボード」2も使用しています）
カンバンボードとは
カンバン ボードは、作業を視覚化し、進行中の作業を制限し、効率 (またはフロー) を最大化するために設計されたアジャイル プロジェクト管理ツールです。
作業の各プロセスをステータスとして表し、その状態遷移をワークフロー3として設定することができます。
JIRAでは、各タスクをissue（課題）という単位で管理します。
上記の図のように、どのissueがどのステータスなのか、視覚的に把握・管理しやすくなっています。
開発用issueの管理方法
通常、単一の開発タスクでは要件を満たせないことが多いので、まず始めに複数の開発用issueをまとめるためのissueがプロジェクト単位で発行されます。
アジャイルプロジェクト管理では、このようなissueのことを「エピック」、開発用issueのことを「ストーリー」と呼んでおり、マイクロアドでもこの名称を使用しています。
ストーリー、エピック、イニシアチブ、テーマとは?
・ストーリーは「ユーザーストーリー」とも呼ばれ、要件またはリクエストをエンドユーザーの観点から簡潔にまとめたものです。
・エピックは、より小さなストーリーに分割できる、まとまった作業です。
・イニシアチブは、共通の目標達成のためのエピックの集合体です。
・テーマは、組織全体にわたる大規模な重点分野です。
https://www.atlassian.com/ja/agile/project-management/epics-stories-themes
このようにプロジェクトを管理することで、プロジェクトの目的や要件が複数のissueに分散することがなくなり、
- エンジニア・ディレクターが同じものを参照することで認識齟齬を無くす
- 情報を分散させないことで管理コストを軽減する
という効果があります。
下記のようなイメージです。
- プロジェクトAのエピックissue
- ストーリーissue A-1（第1開発ユニット担当）
- プロジェクトBのエピックissue
- ストーリーissue B-1（第1開発ユニット担当）
- ストーリーissue B-2（第3開発ユニット担当）
- ストーリーissue B-3（第4開発ユニット担当）
- プロジェクトCのエピックissue
- ストーリーissue C-1（第2開発ユニット担当）
- ストーリーissue C-2（第4開発ユニット担当）
開発の流れ
エンジニアが開発を開始する場合は、エピックissueに紐付けつつ、ストーリーissueを発行して作業を進めていきます。
※他にも、リファクタリング、調査、運用作業、タスク、などの課題タイプのissueがありますが、詳細については省略します。
ストーリーissueは下記のステータスで管理され、基本的には上から下に向かって順に進んでいきます。
| ステータス | 概要 |
|---|---|
| 内容検討待ち | 未着手の状態 |
| 内容検討中 | テストケース作成中 |
| バックログ | テストケース作成完了 |
| 開発（対応）中 | 実装／テスト中 |
| 受け入れテスト中 | テスト結果レビュー中 |
| 受け入れ完了 | テスト結果レビュー完了 |
| 完了 | 本番環境での確認が完了 |
| 中止 | 開発が不要になった場合 |
各ステータスについて見ていきましょう。
内容検討待ち
issue作成時のステータスです。まだ他の案件を対応しているなど、未着手の状態です。
着手できる状態になったら、エンジニアが「内容検討中」にステータスを変更します。
内容検討中
テストケースを作成してディレクターに確認してもらうステップです。
要件・仕様から、
- テスト項目
- それを確認するためのテストデータパターン
などを作成し、テストケースとしてまとめます。（Confluence4を使用して作成することが多いです。）
作成したテストケースはチーム内でレビューした後、ディレクターに確認してもらいますが、この過程が実装の前にあることで、（少なくともテストケースに記載がある範囲では、）エンジニアとディレクターの認識の齟齬がない実装になります。
ディレクター確認がOKとなれば、ステータスを「バックログ」に移動してもらいます。※ディレクターしか移動できないように制御されています。
バックログ
テストケースが固まって、開発の準備ができた状態です。
開発担当者はテストケース作成の段階から、
- 優先度
- 他の案件へのアサイン状況
- 既存機能の改修の場合は、その機能に詳しいかどうか
- 実装予定のプログラミング言語に詳しい人かどうか
といった基準でアサインされることが多く、そのまま開発に入ることが多いです。
※未経験の言語にチャレンジするなど、上記の基準に当てはまらないこともあります。
状況によっては、ストーリーissueを
- テストケース作成
- 実装
- テスト実施
のように複数のサブタスクissueに分割して、それぞれ別のエンジニアがアサインされることもあります。
開発（実装）にアサインされたエンジニアが「開発（対応）中」にステータスを変更して開発を進めます。
開発（対応）中
実装とテストを進めるステップです。
マイクロアドではGitHub Enterprise5を使用しており、コードレビューは基本的に1~2人体制で行っています。
ちなみに、申請すればIntellij IDEA6のUltimate版を使用することも可能で、タカギもKotlinを使用するプロジェクトではよく使っています。
テストが完了したら、エンジニアが「受け入れテスト中」にステータスを変更します。
受け入れテスト中
テスト結果をディレクターに確認してもらうステップです。
画面開発の場合は、実際に画面を触って見た目や挙動の確認なども行います。
ディレクター確認がOKとなれば、ステータスを「受け入れ完了」に移動してもらいます。※ディレクターしか移動できないように制御されています。
受け入れ完了
ディレクターによるテスト結果確認がOKとなった状態です。
その後本番リリースを行い、ディレクターによる本番確認がOKとなれば、ステータスを「完了」に移動してもらいます。※ディレクターしか移動できないように制御されています。
完了
本番リリース後のディレクター確認が完了した状態です。
他チームとの連携
ディレクターとは毎回連携が必要になりますが、場合によってはその他のチームと連携することもあります。
例）
- 新たにサーバ構築が必要になった場合など、基盤開発グループに依頼
- 外部のAPIに接続するためのID、secret、トークンなどの取得を基盤開発グループに依頼
- 実装について、他の開発ユニットの詳しい人にヒアリング
- メーリングリストの作成をIT戦略チームに依頼
まとめ
まずテストケースを作り、必ずディレクターが確認するというマイクロアドの開発の進め方は、認識の相違による修正を防ぐという意味で非常に効率的であると感じています。
前職では、実装→テストケース作成→仕様考慮漏れによる問題が発覚して実装修正、ということがそこそこの頻度で発生していましたが、この方式だとそういうことがあまり起きません。
ディレクションユニットの方々には負担が大きいかもしれませんが、開発エンジニアとしてはこの上なくやりやすい仕組みで、とても助かっています。
こういった仕組みを整えてくれた先輩方に感謝しつつ、マイクロアドのシステムをよりよいものにするべく、日々開発業務に励んで行きたいと思います。
