ログラスでアプリケーション基盤領域のエンジニアをしている龍島(@hryushm)です。以前弊社いとひろ(@itohiro73)より、偶有的複雑性と向き合うEnabling & Platform戦略についての投稿をしました。
自分自身Enabling & Platformを担う部署に所属しており、この戦略に最前線で向き合い、実行しています。今回はこの戦略に基づいて、主に偶有的複雑性の一部である非機能要件への対応に実際どのようなアクションを取っているのかを書いてみたいと思います。
プロダクトの成長と非機能要件対応の必要性
まず前提として、対象としている非機能要件が持つ性質について整理します。
プロダクト開発における、市場への受け入れられ度合いと機能要件の不確実性、非機能要件対応の必要性について一般的な関係をプロットしてみると、下図のようになります。
機能要件の不確実性
緑の線となってる機能要件の不確実性は、プロダクトが市場に受け入れられるにつれて減少していきます。プロダクトの初期段階では機能要件の不確実性が高く、満たすべき仕様は定まりきっていません。しかし、ユーザインタビューや機能実装、機能をミニマムでリリースすることで得られるユーザーフィードバックや、市場分析を通じてこの不確実性は減少していきます。
非機能要件対応の必要性
図の赤い線で示した非機能要件への対応の必要性は、プロダクトが市場に受け入れられるにつれて増加していきます。それには具体的に以下の要因が関わってきます：
- ユーザー数の増加に伴うシステムの負荷増大
- データ量の増加によるパフォーマンスへの影響
- セキュリティリスクの増大
- 機能の複雑化に伴う保守性・拡張性の課題
- ユーザー体験の向上に対する要求の高まり
これらの要因により、スケーラビリティ、パフォーマンス、セキュリティ、保守性といった非機能要件への対応が徐々に重要性を増します。プロダクトが成長するにつれ、これらの要件を満たすことが持続可能な成長と競争力維持に必要となってきます。
機能レベルでの成長と非機能要件対応の必要性の関係
この図の関係性はプロダクト全体に限らず、個々の機能でも短いサイクルで同じような推移をたどり、いわゆるフラクタル構造となっています。機能のディスカバリーの段階では機能要件の不確実性が高く、機能をリリースして改善を重ね、多くのユーザに利用されるようになると非機能要件対応の必要性が高くなるのです。
今ログラスが取り組んでいる課題とアプローチ
以上を踏まえてログラスが現在向き合っている課題と、それに対してどのようなアプローチを取っているのかを見ていきます。
ログラスにおいてこの1年ほど、拡大期にあったある機能について、大きな非機能要件（主にパフォーマンス）の問題が顕在化する事態が発生していました。それに対応するPJを立ち上げ、メンバーのリソースを当て、現在においてもなんとか抑え込んでいるという状態です。言わば火を吹いたところに急いで消火に向かう状況で、顧客影響や機能開発の遅延にも繋がってしまっていました。
この経験から、現在は非機能要件に対して専門に対応するアプリケーション基盤チームを組成し、各機能についてより早い段階での対応を進めています。
個々の機能について拡大期に差し掛かったところで、アプリケーション基盤チームによるフィーチャーチームに対するヒアリングを行っています。内容としては下記のようなポイントです。
- データ量増加で非機能要件（特にパフォーマンス）に影響する可能性があるか
- 今後機能をスケールするにあたって変更容易性の低い箇所が無いか
これらを事前に見積もっておくことで課題を認知し、対応のロードマップを立てています。認知した課題全てにすぐ取り組むことはできないですが、課題に対する解像度を上げ、マネジメントすることで問題が大きくなることを事前に防げると考えています。
ヒアリングがこのタイミングである理由は、機能要件の不確実性が十分に下がっている段階であるからです。機能要件の不確実性が高い段階でヒアリングや課題認知をしても、実際に拡大、成熟期に入る段階では前提が大きく変わっている可能性が高いため、現状の限られたリソースで取り組むベストなタイミングだと考えています。
しかし、現状を理想と考えているわけではありません。機能がある程度作られた状態で重大な課題が見つかった場合、それに対応することはなおハイコストであり、拡大、成熟期へと進む大きなハードルとなりえてしまうからです。
理想と考えている形
非機能要件に対しては機能実装初期から機能要件と共に検討し、成長と共に対応し続けていくことが理想です。機能のディスカバリー段階からパフォーマンスを主とする非機能要件も考慮に入れ、マネジメントできる状態でPMF、拡大、成熟期へとなだらかに推移していくイメージです。
ログラスではそれが十分に実現できていないという現状があります。各フィーチャーチームのエンジニアは本質的な顧客課題解決に軸足をおいており、もちろん非機能要件について考慮してはいきますが、より高いレベルでの対応が求められています。その差分を埋めるために、ログラスでは下記のような組織が理想ではないかと考えています。
イネーブリング&プラットフォーム組織を置き、プラットフォーム領域として偶有的複雑性に対処する基盤の整備を行います。さらにイネーブリング領域として各フィーチャーチームに必要に応じて入り込み、一体となって偶有的複雑性を解消、チームが最大出力を出せるよう働きかけます。
具体的に非機能要件（パフォーマンス）への対応を例とすると、まずプラットフォーム領域としてSLI、SLOといった指標の整備、それをモニタリングする基盤の構築などを担います。さらにイネーブリングとして各フィーチャーチームに入り込み、その基盤を利用して実際に指標を満たしていけるようフィーチャーチームと一体化して動き、スキル獲得の支援をします。
これによってフィーチャーチームが機能開発初期から機能要件と非機能要件に両輪で向き合うことができ、非機能要件への対応の必要性を低く保ったまま機能をスケールさせられると考えています。
まとめ
現在のログラスでは非機能要件への対応が後手に回ってしまっており、スケールの障害となってしまっています。まずは機能の拡大期に入る前に課題の解像度を上げ、課題をマネジメントできるようにしていくアプローチを取っています。しかし理想とする形はイネーブリング&プラットフォーム組織がプラットフォームを整備した上で各フィーチャーチームに有機的に入り込み、機能開発初期から非機能要件対応を含む偶有的複雑性を小さく抑える形です。
これまでログラスは様々な課題を乗り越えプロダクトを成長させてきましたが、現在の一番の課題は間違いなくこのイネーブリング&プラットフォーム領域です。個人的にはその大きな課題に向き合える楽しさを感じつつ、実際はメンバーが足りずやりたいことのほんの少ししかできていない現状にもどかしさを感じています。この記事を読んで面白そうと興味を持ってくださった方、ぜひお話ししましょう。
