この記事は、Bill One開発Unitブログリレー2025の第19弾です。
- 1. はじめに
- 2. プロジェクトの背景
- 3. プロジェクトの目的
- 4. 仮説検証で不確実性を減らしながら前進する
- 5. プロジェクトを通して得た学び
- 6. おわりに
- Sansan技術本部ではカジュアル面談を実施しています
1. はじめに
技術本部 Bill One Engineering Unitの川原です。Webアプリケーション開発エンジニアとして、Bill Oneの開発に携わっています。
本記事では、権限管理の仕組みを見直すプロジェクトに携わった中で感じた知見を紹介できればと思います。
プロジェクトの背景や進め方にフォーカスし、権限管理の技術的な詳細には踏み込みません。同じような不確実性の高いプロジェクトに取り組む方へ少しでも参考となる情報を共有できればと思います。
2. プロジェクトの背景
Bill Oneには大きく分けて、請求書受領・債権管理・経費精算の3つの業務領域があります。
管理ユーザーがあらかじめ用意されたロールをユーザーに割り当てることで、機能の利用可否を制御していました。
しかし、どの領域においても「特定のユーザーだけに機能を制限したい」という要望があり、特に従業員規模の大きな企業ほど、そのニーズは顕著でした。こうした要望に対しては、その時点の各領域で現実的な対応を重ねてきました。
結果として、権限制御はプロダクト全体で一箇所に集約されるのではなく、複数のコンポーネントや業務領域にまたがって実装される状態になっていました。そのため、新たな権限制御を追加・変更する際に、影響範囲を把握するための検討や関係者間の調整が必要となっていました。
当初は大きな問題として認識されていなかったものの、機能やユースケースが増えるにつれて、仕様の整合性を保つための検討が必要になりました。また、同じような仕組みが異なるチームで個別実装されてしまうといったケースも見られるようになりました。
この状態はユーザーの求める権限要件を今後素早く実現していく上でリスクとなる可能性がありました。
3. プロジェクトの目的
こうした背景がある中で、請求書受領の業務領域で細かな権限制御のニーズが高まったタイミングで、権限管理の仕組みを見直すプロジェクトが始動しました。
私たちのチームは、チームトポロジー*1で言うストリームアラインドチームにあたり、元々のバックログでやりたいことだけを達成するならば、既存の仕組みを踏襲して最低限の実装で対応することも可能でした。
しかし、分散した権限制御の課題が今後さらに顕在化することを踏まえると、領域を横断して利用できる権限管理を構築することが中長期的に価値が高いとチームとして判断しました。そのため、既存の延長ではなく、汎用的な権限管理基盤を構築するプロジェクトとして進めることとなりました。既存の仕組みを拡張する案も検討しましたが、部分的な対応を重ねると中長期的な複雑性がさらに増すリスクの高さを懸念し、この案は採用しませんでした。
権限管理として汎化する上で、次のような要件を満たす必要があります。
- 新たな権限を少ない工数で追加しやすい構成であること
- 将来的なカスタムロール・グループに対する権限付与といった機能拡張にも対応しやすい構成であること
- 将来的なリクエスト数の増加に耐えうる設計または、耐えうるようにリプレイスが可能な設計であること
これらの要件を満たすためには、設計上考慮すべきことが多く、不確実性が高い状態でのプロジェクトスタートとなりました。以降では、チームとしてこの不確実性とどのように向き合いながらプロジェクトを進めたかを紹介します。
4. 仮説検証で不確実性を減らしながら前進する
スプリントレビューで目線を合わせる
ここで言う不確実性とは、プロダクト要件・技術設計のいずれもが固まりきっていない状態を指しています。
まず、プロダクト面の不確実性を減らすために、2週間ごとに実際に動くプロトタイプを作成し、CS・PdM・デザイナーに触ってもらうプロセスを取り入れました。
UIモックではなく検証環境でバックエンドを含めて動くものを用意することで、体験の認識を合わせるだけでなく、実装面での課題も早期に把握できました。プロダクトの要件が抽象的な段階でも、動くものを通して議論できたため、認識のズレを最小限に抑えながら進めることができました。
技術面では、認可基盤の設計など影響範囲の大きい意思決定が多くありました。そこで、早い段階で全体構成の大枠を固めつつ、性能面でボトルネックになり得る部分は後から置き換え可能な形に切り出す判断をしました。設計段階からパフォーマンスがクリティカルになり得るモジュールに対して負荷試験を実施し、実現可能性を確認しながら進めたことで、必要なところに集中して改善できました。
このように、プロトタイプと技術検証を組み合わせることで、不確実性を段階的に減らしながらプロジェクトを前に進めていきました。
あえてやらなかったこと
今回のプロジェクトでは、初期段階ですべてのタスクを洗い出し、詳細な計画を立てることは行いませんでした。
不確実性の高い状況では、初期の想定自体が変わる可能性は高く、タスクを細かく洗い出しても前提はすぐに崩れてしまいます。そのため、最初はおおまかなロードマップを描くに留め、2週間ごとのスプリント単位で状況を見ながら計画を具体化していく進め方をチームとして選びました。
また、立ち上げたばかりのチームであったため、過去のベロシティが存在せず、スプリントごとにタスクの質や量が異なるため、ベロシティを生産性の指標に置くのは難しいと判断しました。
そこで、ベロシティではなく、スプリントごとに「この期間で何を達成するか」というゴールを明確化し、その達成に必要な課題へ集中する形で進めました。
この進め方により、不確実性の高い中でも優先度を柔軟に見直しながら、着実に前進できました。
5. プロジェクトを通して得た学び
動くものベースで議論する
影響範囲が広く、技術的な設計に時間がかかることを想定していたため、今回のプロジェクトではプロトタイプを「捨てる前提」で約1カ月かけて作成しました。
今回のプロジェクトにおける全体設計の意思決定は、チーム内だけで完結するものではなく、関係者との検討や認識合わせに一定の時間を要する可能性がありました。 そこで、設計が決まりきっていない段階でも、実際に動くものを用いて議論できる状態を早期に作るべきだとチームとして判断しました。
捨てる前提でコードを書くことには、チーム内でも少なからず抵抗がありましたが、プロジェクトの影響範囲と手戻りのコストを天秤にかけて、動くものを早期に用意することを優先しました。
体験のデモを通してPdM・CS・デザイナー・エンジニアの目線を揃えて議論できたことで、技術的な設計が固まりきっていない中でも、最終的なゴールの認識を合わせながら開発を進めることができました。
もし設計を固めきってから関係者との議論を始めていたら、合意形成により多くの時間がかかり、後戻りのコストも大きくなっていたと感じています。
今決めることと後で決めることを分ける
不確実性が高い状態では、全てを最初に決めきった上で進めるのは非常に時間がかかってしまいます。今回のプロジェクトでは、全体のアーキテクチャの大枠を先に決め、設計が議論になりそうなモジュールは後で変えられる状態にしておくことでリスクを抑えながら前に進めることができました。
実際に、初期段階では判断を保留した設計要素もありましたが、その分、必要になったタイミングで改めて検討する余地を残すことができました。
ゴールから逆算して本当に必要なことを優先する
タスク単位ではなく、リリースまでのゴールから逆算した計画を立てることで、やらないこと・決めないことの判断がしやすくなり、 スプリント内で本当に必要なことだけにチームとして集中できました。
今回のプロジェクトでは、このスプリントで達成すべきことは何かを毎回確認し、あえて着手しない判断も行ってきました。その結果、スコープを広げすぎることなく、限られた時間の中でも着実にリリースに向けて前進できたと感じています。
6. おわりに
今回のプロジェクトは、入社以降に携わった中でも、リリースまで約5カ月と比較的長期で、不確実性も高いものでした。その中で、チームとして仮説検証を繰り返しながら進めたことで、不確実性を下げながら着実に前進できたと感じています。
プロジェクトは 11月中旬にリリースし、1月現在でも大きな問題なく安定稼働しています。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
*1:『チームトポロジー 価値あるソフトウェアを素早く届ける適応型組織設計』（著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎）
