システム開発フローの紹介

株式会社ヴァージニアのエンジニアリング本部本部長兼CTOの村上です。
SMARTCRMを始めとするシステム開発をどのような手順で行っているのか、という質問を面接で頂くことが多いので、今回はその紹介を致します。
基本的にはアジャイルで開発を進めているのですが、業務用システムの開発というのもあり、上流工程は比較的しっかり行っているかと思います。
フローとしてはおおまかに以下のフェーズに分かれます。

1. 要求、デザイン作成
2. 要件定義
3. 画面設計書作成
4. 詳細設計
5. 単体・結合テストケース作成
6. 実装
7. 単体・結合テストケース実施
8. バグ改修
9. シナリオテストケース実施
10. リリース

その中でエンジニアが特に気になると思われるフェーズについて紹介したいと思います。

1. 要求、デザイン作成

どのような機能をどのようなUXで実現すれば、ユーザーの方に役立つのかが重要です。ですので、要求とデザイン作成はSaaS事業部とデザイナーが協力して実施します。そのアウトプットがAdobe XDのフレームとなって出てきます。

2. 要件定義

要件定義では、デザインを見て機能の目的やUI・UXを理解し、要求の担当者にその理解と疑問点をぶつけます。
その結果として、以下のような要件定義書の形でまとめていきます。

このフェーズは、今の所私が担当することが多いです。
実は私は、大規模データ処理、WEBアプリケーション開発、アーキテクチャ構築などを手掛けてきた一方で、上流工程はほぼ経験してきていませんでした。ですので前職で他の方がどうやっていたかを思い出したり、様々な本を読んだりしたのですが、今はこのやや独自と思われる形に落ち着いています。
このやり方が最適だとは思っていないのですが、

1. この機能で何を実現したいか
2. 何故この項目が必要か
3. この項目があっても良さそうだが何故要求として入れていないのか

などといった、要求に関する疑問を解消していくと要件定義として必要な内容が満たされると思っています。
ただ、詳細設計を担当する開発パートナーさんの技術力が高いのでこれでも質問を頂きながら進められているという面も大きいです。
ですので要件定義のエキスパートの方がいたら是非弊社に入って腕をふるって頂ければと思います。

3. 画面設計書作成

これまでのフェーズでデザインと要件が作成されたので、このフェーズではそれを画面設計書に落とし込みます。制約やUIのイベント、エラー条件とその文言などを記します。
この段階で完成されるのが理想なのですが、どうしても細かい部分に見逃しは発生するので、詳細設計時や、実装者やテスト作成者からの指摘で修正することも多いです。

4. 詳細設計

API定義、ER設計、ビジネスロジック設計をこのフェーズでは実施します。弊社ではOpenAPIのフォーマットでAPI定義をしています。
バリデーションと、ある程度の分量のビジネスロジックはOpenAPIのYAMLにマークダウン記法で書き込んでいます。図が必要だったり分量が多いビジネスロジックについては、別途マークダウンで記載して、YAMLにはそのファイルを見るよう記載しています。

5. 単体・結合テストケース作成

ここでいうテストは、UIを実際に操作して行うテストです。RailsについてはRspecでテストを記載しているので、APIの動作は基本的にはそちらで担保出来ています。FEについてはFE側で行うビジネスロジック実装がほぼ無いのもあり、ユニットテストは書いていません。ですので、UIを操作して行うテストのケースを書いて実装後にテスト実施をしています。このテストケースはFE実装者も見るようにしてもらっています。そうすることで、画面設計書だけでは開発者の思い込みで仕様漏れが発生することがあるのですが、それを減らす効果がありました。
なるべく自動化してテストを回せる回数を増やしたいので、E2Eテストをどう導入するかが今の課題となっています。

6. 実装

BEエンジニアはAPI定義、ER、ビジネスロジック設計書をもとに、基本的にはAPI単位で実装を進めます。ビジネスロジックが複雑な場合は、そのサービスクラスだけ分担を分けることもあります。FEエンジニアは、画面設計書とAPI定義をもとに実装を進めます。ただ、勉強会でERとビジネスロジック設計書を輪読しているのですが、そうするとやはり内部の理解が深まってFE実装も進めやすいようです。

7. テスト実施

フェーズ5で作成したテストケースを使って実施します。バグ、特にFEのバグはここで見つかることが大半です。JIRAのバグチケットにテンプレートを登録しているので、バグの発生状況と元々期待される結果などをそのフォーマットに合わして記します。そして適宜開発者に割り当ててバグ改修を進めて行きます。優先度については、チケットにpriorityとして選択するのと、時折バグ整理会で残っているバグチケットの優先度と実施時期の見直しをしています。

9. シナリオテストケース実施

こちらでデグレが起きていないか最終確認して、問題なければリリースとなります。
テスト担当者が細かく実施しているのでもしデグレがあってもリリース前に気がつけるようになっています。
ただ、網羅性とスピードはトレードオフなので、やはりE2Eテストをいかに導入するかが今後の課題となっています。

現状の課題とまとめ

上流工程の課題としては、既存の仕様との兼ね合いで要件を満たすことが困難、可能であってもロジックやUI・UXが複雑になってしまうことがあるというのがあります。これは、システムが大規模であるゆえに、各エンティティの役割やエンティティ間の関係が複雑かつ膨大になり、そこを把握しきれないで設計して実装を進めてしまうことが根本原因の一つであると考えられます。ここでいうエンティティは、ER図としてのエンティティというよりは、DDDにおけるドメインエンティティに近い位置づけです。エンティティの役割と関係性が整理されていれば、このエンティティに実は影響出るのでこの仕様では難しい、代わりにこういう仕様ならシンプルになる、などがわかるはずです。その対策として、弊社の開発パートナーさんとドメインとその関係を把握・整理する会を１日掛けて開催しました。今後はこれを土台にエンティティとその関係を定義していく予定です。

いかがでしたでしょうか。少しでも弊社の開発フローの参考になれば幸いです。どのフェーズでも人を募集していますので、1つ以上やってみたいフェーズがありましたら是非弊社を応募してみて下さい。勿論、もっとよいやり方を導入したいという方も大歓迎です。