PROFILE
池田 智裕
開発管理課 課長
Webシステム開発のSIerを10数年経て2015年4月に株式会社ラクスに入社。MailDealerの開発に2年携わった後、2017年よりラクスベトナム代表を3年間務め2020年に帰任。現在は横断的に開発本部をサポートする開発管理課に所属。
高品質と開発効率の両立を目指す開発プロセス
ラクスでは現在、12のBtoB SaaSを開発しています。各プロダクト開発チームは、高品質なプロダクト提供と開発効率を両立するために、開発プロセス、アーキテクチャ、技術要素について各プロダクトに最適化した一定の裁量をもって開発しています。（図は2023年5月現在）
一方で品質や効率性を高めるため、以下のようなプロダクト横断の取り組みもあります。
・プログラミング言語やDBなど、ベースとなる技術要素はいくつかのプロダクトで同じものを選定
・テックリードによる技術勉強会や開発事例共有会の定期開催
・「開発管理課」という組織横断のチームが、標準的な開発プロセスを整備
今回はその中でも、開発管理課がとりまとめている標準的な開発プロセスを紹介します。ラクスの一般的な開発プロセスのイメージを持っていただければ幸いです。最初に書いた通り、この標準プロセスを参照しつつも各プロダクト開発チームでさまざまな特徴がありますので、それらは今後紹介していきます！
開発本部の体制
ラクスの組織は「事業部門（営業、企画、プロダクトマーケティング、CS、開発・デザインなど）」と「管理部門（経営管理、経理・財務、人事、情シスなど）」に分かれています。
エンジニアやデザイナーが所属している「開発本部」は独立した専門組織で、営業、企画、プロダクトマーケティング、CSが所属する「事業本部」と協力しながらプロダクト開発を行っています。開発本部を専門組織にした目的は、① エンジニアやデザイナーが気持ちよく働ける文化を作るため、② プロダクトのニーズに合わせて選択と集中を機動的に行えるようにするためです。（図は2023年5月現在、管理部門、事業本部は一部省略）
開発部門内は、下の図のようにプロダクト別開発チーム（東京開発統括部、第二開発部、第三開発部）に分かれています。インフラ開発部は全てのプロダクトのインフラ構築・開発・運用を専門に行っています。デザイン、フロントエンド、R&D、技術広報、開発管理など、専門性を活かして横断的に動くメリットのある領域は第一開発部に集約されています。
開発プロセスの標準ケース
以下では開発プロジェクトの進め方を紹介します。手戻り発生を防ぎ、本当に顧客に必要な機能を届けるために、開発単位を適切に区切り、ビジネスサイド（企画・営業・サポート）と密接にレビューを行いながら進めているのが特徴です。機能リリースサイクルは1か月～3か月が多いです（図はリリースサイクルのイメージ）以下ではリリースサイクル内の各工程を紹介します。
企画
１．企画会議（参加者：開発、企画、営業、サポート、事業部長）
お客様からの要望や企画案について、開発チームが概算工数を算出。事業部長も含めたビジネスサイドと認識を合わせた上で、次期開発での開発項目を選定。
２．要求仕様（参加者：開発、デザイナー、企画、営業、サポート）
営業・サポートチームや経理部にヒアリングし、ユーザの抱えている問題、実現したいことを理解する。課題解決のためにどのような機能を実装するか要求仕様を作成し、ビジネスサイドに提示する。UX部分での要求がある場合にはデザイナーも参加。
設計
３．要件定義（参加者：開発、デザイナー）
要求仕様ををもとに、開発チームが機能要件を策定。実施する事・実装しないことを明確にする。UX設計はデザイナーが担当。より良い仕様が提案出来る際は開発・デザイナーからも積極的に提案を行い、より良いプロダクトにしていく。
４．概要設計（参加者：開発、デザイナー）
Excel・HTMLモック・Figmaなど画面遷移がわかるドキュメントを使って、仕様ミーティングをおこなう。文言設計はデザイナーが担当。内容によっては営業・サポートチームも参加して意見をもらう。
５．設計承認レビュー（参加者：開発・デザイナー・企画・営業・サポート・事業部長）
各設計のポイントをビジネスサイドに共有し、仕様や機能が顧客に価値を提供できるものになっているかを一緒に確認する。重要な案件の場合は事業部長・経理も参加。要求仕様・要件定義・概要設計のいずれの各工程で実施されるかはサービスによって異なる。
実装
６．プログラミング設計 （参加者：開発）
難易度の高い機能、パフォーマンスに注意を払う必要のある機能について、プログラムレベルの設計をおこなう。案件によってはこのフェーズをスキップする。
７．実装・単体テスト（参加者：開発）
実装後に単体テストを実施する。
８．受入（参加者：開発）
修正された全てのソースコードに対して第三者が保守性の高いコード実装になっているかどうかをレビューする。仕様通りに不具合なく動作するかの受入れを実施する。
結合テスト
９．結合/システムテスト（参加者：開発・QA）
リリースする機能がすべて揃った後に結合テストを実施する。
下記はテストの例
・結合/システムテスト
・セキュリティテスト（脆弱性診断で対応できないもの）
・負荷/性能試験
・回帰テスト
・自動テスト
10．UIレビュー（参加者：デザイナー）
UIの専門家が、実装の完了した機能について画面・ＵＩ・文言の品質についてレビューを実施する。
この工程は設計段階で実施されることもある。
11．デプロイ準備（参加者：インフラ）
・デリバリー関連
・リリース対象機能が漏れなくデプロイされるか確認したか
・リリース手順やJob等のリハーサルは完了したか
・各種運用変更テスト
・監視
・サーバ構築等の手順やJOB構成の変更など
12．セキュリティチェック（参加者：開発・開発管理課）
横断部門がセキュリティ担保のための提出物をチェックする。
・MWライセンスチェック
OSSライセンス関連の訴訟トラブル回避のため、ライセンスをチェック。
・脆弱性ツール検査
実装時のセキュリティ品質を担保するため、脆弱性診断ツールによる検査を実施。
・脆弱性チェックリスト
設計・実装のセキュリティ品質を担保するため、開発チームで定めているセキュリティ基準に準拠しているかチェック。
13．社内フィードバック（参加者：開発・デザイナー・企画・営業・サポート）
社内機や検証機にリリースし、社内利用してもらう。
社内の各部署に利用を促し、指摘事項や改善ポイントのFBをもらい、できる限りの修正対応を行う。
リリース
14．リリース準備（参加者：開発・インフラ・企画・サポート）
ビジネスサイドへの変更点の説明会、顧客周知や、サポートサイトの変更・プロモーション・リリース演習などリリースに向けての準備を行う。
15．リリース判定（参加者：開発管理課）
本番リリースできる水準で品質/性能/顧客周知などのリリース準備が整っているか、開発チームとは別の第三者部門が監査を実施。リリース判定でOKがでなければリリースすることはできない。
16．リリース（参加者：開発、インフラ）
慌てず騒がず慎重に安全に落ち着いてバージョンアップを実施。
リリース後
17．振り返り会（参加者：開発、デザイナー）
企画会議からリリースにいたるまでの、設計・実装・テスト・バージョンアップでの課題についてミーティングを開き次回以降の開発に対策を講じPDCAを回す。
おわりに
以上がラクスの開発プロセスの標準ケースの紹介でした。各プロダクト開発チームは、顧客への高品質なプロダクト提供と開発効率の両立を目指しています。顧客に必要な機能を効率的に提供するために、開発単位を区切り、ビジネスサイドと密接にレビューしながら進めるのが特徴です。機能開発だけでなくリファクタリングにも主体的に取り組みながら、振り返りと積み重ねのPDCAを回しています。
各プロダクト開発チームの裁量で開発プロセスを最適化する取り組みもありますので、それも追って紹介していければと思います！
