読者です 読者をやめる 読者になる 読者になる

froglog

プログラミングや統計の話など

性能要件重視のシステム開発の定石について考える

このエントリについて

最近参加したとある勉強会や業務をしている上で思うところありまして。

性能要件に価値を置くようなシステムの開発において、性能面でのリスクを軽減するような進め方って?というところを考えてみました。

機能要件と性能要件

私はいわゆるシステム開発にはそれほど詳しくはないんだけど、システム開発のプロジェクトには2種類あるのではと考えています。一つは 機能要件 にウェイトをおくプロジェクトで、企業の会計システムなどおそらくシステム開発というと多くはこちらに属するのではと思います。*1

一方、非機能要件、特に 性能要件 がそのシステムの価値の大きな部分を占める場合もあります。 いわゆるビッグデータ的な話のプロジェクトはこちらに属することが多いのではないでしょうか。 機能要件に比べ性能要件は「やってみないと分からない」感が強く、性能要件を達成できるかが読みにくく不透明であることが挙げられます。(もちろん機能要件を満たすのも簡単ではありませんが)

つまりプロジェクトスタート時点では「性能要件を満たせないかもしれない」というリスクが常にあるわけです。 であれば性能要件重視のプロジェクトはそのリスクを考慮した進め方をしないといけないはず。 その進め方の定石ってだいたい次のような感じになるんじゃないでしょうか??

性能要件重視のシステム開発

最適化や予測、パターン認識のようなソリューションのシステムについて考えます。

プロジェクト全体の進行

  1. 要件定義
    • KPI の合意
  2. データ収集
  3. データ分析
    • 目的を達成するための手法にあたりをつける
    • 足りないデータがないか、あれば収集する
    • オフライン評価、オンライン評価の設計
  4. オフライン評価
    • P: テスト対象の手法やアルゴリズム、特徴量等を決める
    • D: テストデータについて上記手法の実施や統計モデルの学習など
    • C: オフライン評価用の KPI で評価
    • A: 結果によって次のイタレーションの方向性を決める
  5. システム開発
    • 設計: どこまでのチューニングを許容するか?
    • 実装: ゴリゴリ
    • テスト: ここでは機能についてのテスト
  6. リリース
  7. オンライン評価
    • P: パラメータの変更、手法の入れ替え等
    • D: 実環境での運用
    • C: オンライン評価用の KPI で評価
    • A: 結果によって次のイタレーションの方向性を決める

以下、この内のデータ分析・オフライン評価・オンライン評価について述べます。

データ分析

ここのデータ分析は「実現の手法ありき」の分析ではなく、データを見ることによりどの手法が妥当(っぽい)かを決めるための分析です。 ここが「実現の手法ありき」になってしまっていると「分析ツールにデータをつっこんでみました。こんな結果出ました」というだけの分析になりかねません。これではリスクへの備えになりません。

また、この時点で後で出てくるオンライン評価とオフライン評価の設計をしておきます。 それぞれについて KPI は何か、納得感のある評価をするにはどういうデータ・手順が必要か、等を決めます。

オフライン評価

ここがないとぶっつけ本番で商用運用を始めることになり、性能要件が未達だった場合は非常につらいことになります。 そのリスクを避けるためにも、本開発が始める前に実装しようとしている手法の妥当性をここで見ておきます。

また、PDCA サイクルを何回か回して試行錯誤しておくことで手法を叩き上げると同時に、実装のバリエーションの幅が見えてくるのではないでしょうか。

オフライン評価が難しい場合ももちろんありますが、ある程度のシミュレーションはできる場合が多いと思います。(というのもオフライン評価ができてない、頭にないことが多いように思われるためです) 場合によっては評価データを別途収集するような判断もありえますが、そこはコストとリスクのバランスで決めます。

オンライン評価

ここでも同じように PDCA サイクルを回しますが、最後の詰めのチューニングになります。システムの実装を変えるような変更は好ましくなく、できるだけパラメータチューニング程度で済ませられればよいでしょう。*2

また、運用しながら評価を回すことになるのでできるだけ迅速に一つのパラメータセットを評価できる必要があります。Web システムの何かの最適化みたいな話であれば A/B テストは必須でしょう。

何かのメトリクスを改善するというタスクにおいて、できるだけ短い期間で実験結果を得、トライ&エラーをできるだけたくさん回す ことが改善効率に大きく寄与するというのはシステム開発に限った話ではなく、言うまでもない真理です。インターネッツのエライ人たちも言っています。*3 *4

まとめ

偉そうに書いてますが、性能要件未達のリスクを考慮していくと普通はこれに近いプロジェクト運営に自然となっていくのでは…と思っています。 というのも最初に書いた勉強会で見た発表や、かつて携わった音声認識のプロジェクト*5でも似た感じだったからです。

ただし、上に書いたのが理想的な進め方なのかは分かりません。もっとイケてる方法があれば教えて欲しいです。 また、すべてのシステムで前述のような進め方ができるわけでもありません。例えば組込みシステムだとオンライン評価はできないわけで。

できるだけ性能面のリスクを軽減して、ベンダーもクライアントもみんなが幸せになれるようにやっていけるといいんだけど。

*1:もちろんそういったシステムでもレスポンスタイムやスループットなど性能要件も含まれることは理解しています

*2:とはいえ性能未達なら実装を変更しないといけなくなるかもしれません…

*3:iPad登場後の出版社のデジタル戦略とは?

*4:ビッグデータというか、根拠を元に主張をするという行動原理の話

*5:認識性能がそのまま UX に影響を与える、性能重視案件