Bill One 開発 Unit ブログリレー2024の第13弾になります！
技術本部 Bill One Engineering Unitの佐橋です。
Bill Oneでは昨年の10月に要件定義・設計プロセスを統一しました。
同じ課題感を持つメンバーが集まり、約6カ月をかけて検討とPoCを行った後に本導入しました。
今回はプロセスを統一した理由と、どのようなプロセスを統一したのかについてご紹介します。
要件定義・設計プロセスの統一が必要になった理由
Bill Oneではサービスの立ち上げ以来、要件定義や設計手法・設計レビューに関して共通のプロセスが定義されていませんでした。立ち上げ当初は、Bill Oneを軌道に載せることが最優先であり、一定人数が増えた後でも立ち上げメンバーが各チームをリードし、口伝でノウハウを伝えることで対応していました。
しかし、Bill Oneは立ち上げ当時から比較してかなり人数が増えています（4年間でエンジニアが約10倍に増加）。そのため、新規メンバーのみで構成されるチームも多くなり、Bill One全体として共通の設計手法や要件定義のプロセスがないことで、次のような課題が発生していました。
- ジュニアのエンジニアが要件定義・設計で何をすればいいのか分からない。
- チームの実力によっては、要件定義時・設計時に考慮すべき事項が抜け落ちる。
特に2.に関しては、サービスのクオリティーを担保するために、本来ならばプロジェクトの前半で考慮すべき点が後半に見つかることもありました。
またこれら先の2つの課題に加え、開発文化が異なるバックグラウンドを持つメンバーが増えているという背景もありました。と言うのも、Bill One では、セブ島を拠点とするSansan Global Development Center, Inc.（SGDC） の多くのメンバーがBill Oneに参画しています。しかし、日本とフィリピンの開発文化は異なるため、要件定義や設計のプロセスが共通していないと、品質の低下を招く可能性があります。
以上の3つの理由から、要件定義・設計プロセスの統一化が必要だと考え、検討を開始しました。
ただし、統一化を必要以上に行い過ぎてしまうと、チーム内で工夫できる部分が減ってしまう可能性があります。また統一時に多くのドキュメントを作成することを求めると、開発の着手が遅くなり、最終的には開発全体のスピードも遅くなります。
そのため、出来るだけ必要最低限で統一することを心掛けました。
要件定義・設計プロセスの統一化にあたって何をしたか？
要件定義・設計プロセスを統一するために、次のような事項を定義しました。
- 要件定義時のドキュメントテンプレートの統一化
- 設計時の最低限作成するドキュメントと作成手法の定義
- 要件定義、設計のレビュー体制の整理
これらについて詳しく説明します。
1. 要件定義時のドキュメントテンプレートの統一化
当時、要件定義は行われていはいましたが、その際に何を決定するかがチームによってバラバラだったため、抜け漏れが後から見つかるような状態でした。
これを解消するために、要件定義時のテンプレートを作成しました。
ただ、プロジェクトの仕様をドキュメントとして残そうという取り組み自体は少し前から始まっており、要件定義時に使用できそうなドキュメントテンプレートがあったため、それを一部改善する形で進めました。
その中で特に工夫した点として、Bill One全体でチェックしたい非機能要件のリストを作成し、要件定義の終了時までにチェックリストを埋めることを必須化しました。Bill One全体として機能要件はしっかり考慮されている一方で、非機能要件は抜けがちだったので、その課題を改善するためです。
非機能要件としてチェックすべき項目は、非機能要件の定義 | Think IT（シンクイット） を参考に、Bill Oneで全プロジェクト共通のチェックすべき項目として定義しました。
現在では、このチェックリストを使って要件定義することで、プロジェクトの初期時に考慮すべき非機能要件の漏れが減り、品質向上につながっていると感じています。
2. 設計分析手法の定義
次に、設計時に最低限押さえておくべきドキュメントと、その作成手法を定義しました。
これを定義することで、プロジェクト初期段階の設計では、何が完了すれば終了なのかが明確になり、設計の漏れが減ることを期待しました。
ただし今回、設計のドキュメントでも所謂「どのような機能を作るのか」を明確にする上流寄りの設計ドキュメントのみを定義しています。と言うのも、下流の設計ドキュメントになればなるほど、決定すべき項目が増え、プロジェクトによっても異なってくると考えており、一旦上流の設計ドキュメントのみを定義しました。
今後随時、下流の設計ドキュメントも定義していく予定です。
ドキュメントはあくまでドキュメントであり、プロジェクトを進めるにあたって、ドキュメントを作成するよりもプロダクトマネジャー（PdM）やデザイナとのコミュニケーションを取ることのほうが時には重要だと考えています。
そのため、できるだけコミュニケーションを重視してほしいという考えから、ドキュメント作成は必要最低限に留められるように、次の2つのドキュメントを作成することを推奨しています。
a. データもしくはイベントのフロー図
b. 概念データモデル図
ここで「推奨」としているのは、規模の小さいプロジェクトの場合、そもそもドキュメントを作成する必要がないケースもあるため、プロジェクトの規模によって作成するかどうかを判断してもらうようにしたためです。
a. イベント・データのフロー図
イベント・データのフロー図です。最も簡易的なものだとデータの流れを表現した Data Flow Diagram（DFD）のようなものになります。
これを作成することで、プログラムの流れや扱うべきエンティティが明確になり、開発者間での共通理解が深まります。
DFDでこのフロー図を作成する場合、データに注目をする性質上、テーブル中心のモデリングになりがちです。
そのため、Bill Oneではフロー図を作成する手法として、イベントストーミングと採用しています。
イベントストーミングとは、ビジネスプロセスをイベントの流れとしてモデリングする手法です。
特に、イベントを時系列に書き出していくBig Pictureは、PdMやデザイナも参加しやすいものとなっています。
Bill Oneでも、イベントストーミングを実施する際はPdMもしくは仕様に詳しいエンジニアをドメインエキスパートに据え、エンジニア、デザイナも含めてワークショップを行っています。
これをすることにより、プロジェクトの初期の段階から、ステークホルダー間での共通理解が深まり、その後のデータベース設計やクラス設計にも役立ってきます。
また、Bill Oneでは、DDDの手法を取り入れています。これは、イベントストーミングのイベントを中心にモデリングする手法は相性がよく、「物」よりも「コト」に注目して分析でき、業務プロセスを反映したモデリングがしやすいと考えています。
b. 概念データモデル図
次に、概念データモデル図です。これは、システムで扱うデータの概念の関係を示す図です。
Eric Evansの『Domain-Driven Design』第1章「知識をかみ砕く」でも、ドメインエキスパートとのコミュニケーションを通じて概念モデル図を作成する例が紹介されています。
深いモデルを作成することで、ドメインへの理解をより深められるとされています。
イベントストーミングでは、エンティティの発見はできるものの、エンティティ同士の関係性や属性まではモデリングを通して洗い出す必要があります。
そのため、イベントストーミングで作成したフロー図を補助線に、機能要件と照らし合わせながらエンティティの関係性や属性を見直すことで、概念データモデル図を作成できます。
概念同士の関係図をプロジェクトの初期段階で作成することで、機能で扱うものの本質が見えてきます。これを疎かにした場合、UI主導の設計となりがちです。
UI主導の設計になった場合、UIの変更に脆く、拡張性が低くなります。
とはいえ、イベントストーミングのように「概念モデル図を作るための具体的な手順」が確立しているわけではないため、エンジニアの経験や知識が問われる部分でもあります。
次の書籍などがモデリングの参考になるのではないかなと思っています。
- UMLモデリングレッスン … 概念データモデルには一定のパターンがあるとして、概念モデリングに関する21のパターンが紹介されています。
- データモデリングでドメインを駆動する─分散／疎結合な基幹系システムに向けて … 基幹システムのデータモデリングを中心に、Webアプリケーションでも参考にできる内容が多いです。特にデータモデリングの重要性を説いています。
3. レビュー体制の整理
最後に、要件定義や設計のレビュー体制を整理しました。
要件関連のレビューはPdMに依頼し、非機能要件や設計関連のレビューはチームで判断してシニアエンジニアに依頼したり、他チームのエンジニアに依頼したりして行っています。
ここを厳密に定義しなかった理由として、Bill Oneは各チームが独自の開発文化を持っているため、チーム内での判断に任せることで、各チームに合ったレビュー体制が整うと考えたためです。
ただし、セキュリティー要件のレビューに関しては、見落としや知識不足がある可能性も否めません。そのため、セキュリティー要件については専門のセキュリティーエンジニアに依頼しています。
Sansanには、PSIRT（Product Security Incident Response Team）というセキュリティーチームが存在します。セキュリティーリスクを最小限に抑えるため、要件定義時に作成したドキュメントをPSIRTレビューに通すことを必須化しています。
まとめ
今回、一定のプロセスを統一したことで、ドキュメントが統一され「何を作ればいいか」が明確になりました。
まだ運用を始めたばかりなため、開発スピードなどの影響は今後見えてくるかなと思っています。
現状運用している中で、イベントストーミングに関しては、PdMやデザイナからも実施することで共通認識が得られて良いという声も上がっており効果を感じています。
しかし、改善する必要がある点も見えてきています。
- 概念モデル図の作成には、エンジニアの経験や知識が求められるため、エンジニア間で共通理解を深める取り組みが必要な点。
- 既存システムを改修する場合、既存機能の図がないため、ある程度起こし直す必要がある点。
これらに関しては、一定予想できていましたが、今後改善をしていきたいと思います。
次回、Bill One 開発 Unit ブログリレー2024 vol.14は ToCプロダクトに長年携わってきたPdMがToBプロダクトに関わり思うこと です。
ブログリレーの最新の投稿についてはXアカウント @SansanTech でお知らせしますので、フォローよろしくお願い致します。
