2016年10月31日

性能はどの工程で確保するべきか


初めての方はこちらを「はじめに

今回は性能目標をどのタイミングで達成するのかという話です。
開発モデルによって細かい事情は変わると思いますがここではウォーフォールをベースに話をします。また性能というのは動作速度に限定して話を進めます。ただ、いずれにせよそういった差異には関係の無いより本質的な部分が述べたいところです。

動く様になったら測定する


良くあるのはテストの段階で性能を確保しようとするパターンです。つまりある程度動く様になったので性能を測ってみるというものです。測定→コードを修正、というループを繰り返して目標の性能を達成します。場合によっては機能に関するテストは完全に終了して機能に関する品質は確保された後に性能に関するテストを行ったりもします。

こういった「手順」自体は問題はありません。テストというものは基本的には品質を確認する工程ですから、性能の品質を確認する作業と考えれば自然な事です。問題はここで「確保」しようとするパターンです。つまりテストに入るまでは性能のセの字も出て来なくて、テストの工程に入ってから初めて性能に関する取り組みを行って目標を達成しようとするものです。この様なパターンではコードの修正は必須です。コードを修正するので機能に関するテストをやり直す事になります。「計画通りに進める」という観点からすれば作業は増大するし影響は読み切れないしで危険極まりない状態です。

しかしその様に苦労しても目標を達成できる場合は未だ良いのです。本当の問題はこの工程に来てからではもう目標とする性能を達成できない場合があるのです。「コードを修正」という意味は製造工程を部分的にやり直すという意味です。だからこそテストをやり直す必要が出てくる訳です。つまり製造上の工夫ではどうにもならない設計上の限界値に達してしまえば設計をやり直さなければならないのです。そうなるともはやテスト期間中に事を収めようとするのは不可能に近い事です。何が何でもリリースする為に無理やりやろうとすれば、付け焼き刃的に設計を性能視点のみで強引に変更してしまい、リリース後に重大な問題を引き起こすのが関の山です。勿論潔く諦めて制限付きでリリースさせてもらえる様に交渉するというパターンもあり得ます。いずれにせよ不幸な結論しか待っていません。この様な事態に陥らない為には設計工程で性能を確保する必要があります。

設計工程で確保する


製造工程で出来る事は言うなればチューニングの域を出ません。ループの回数が無駄に多かったので減らしたとか、あるライブラリーの呼び出しが異常に遅かったので一度しか呼ばない様にしたとか、そういった地道な改良の積み重ねです。勿論「塵も積もれば山となる」の例え通り大きな効果を上げる事もあります。これに対して設計工程で性能を確保するという事は性能の出る「方式」を採用する事と言えます。例えばデータ処理の部分にはキャッシュの層を設けるとか、通信のプロトコルとしてHTMLではなくより下位のTCP/IPの層を用いる、といった事です。これらの事は少々のコードの修正で実現できるものでは無く全体の構造を変更する必要があるのでテスト期間などで出来る様な事では無い訳です。

方式を選ぶ


方式を選ぶ事が性能にとってどの様な意味を持つのかを具体例を基に説明します。
Excelを使える方は以下の様な計算式を入れてみてください。
=a1+pi()+10.0
一応説明しますと「a1」はセルの座標、「pi()」は円周率を表す関数です。
訂正状態にして入力した文字列を確認してみてください。結果は以下の様になったはずです。
=A1+PI()+10
不思議じゃないでしょうか?
座標と関数のアルファベットは大文字になり、数値は小数が無くなりました。これはつまり計算式の場合にExcelは入力された瞬間に入力内容を何かしら加工しているという事です。何故そんな事をする必要があるのでしょう?勿論内部事情は分からないので推測しかできません。例えば数式の場合には正規の文法が定められていますから表記も統一的なものにしようとしたといった事も考えられるかもしれません。別の考えで計算速度を考慮したという事も考えられかもしれません。つまりユーザーが自由に入力したままの形で保持していると計算する時に毎回計算処理の前に文字列の解析処理をしなければなりません。その辺の処理は入力時に行ってしまって標準的な形式で保持してしまえば再計算の時にはその分速くなるという事です。

合っているかどうかはともかくこの推測を例に方式を選ぶ事が意味する事を説明します。この場合方式というのは大きく分けて二つ考えられます。
方式A:Excelの様に入力時に標準形に修正して保持するもの
方式B:逆にそのまま保持して計算時に文字列の解析を行うもの
二つの方式の違いは文字列の解析を入力時に行うか計算時に行うかの違いになります。この場合原理的に方式Aはどんなに頑張っても入力速度は方式Bより速くなりません。また逆に計算速度は方式Bはどんなに頑張っても方式Aより速くなりません。つまりどういう方式を選択するかによってそれぞれの性能の限界値が決定してしまう事になります。逆に言えばこの段階で適切な方式を採用できれば概ね性能は確保できる事になります。

どの様にして決定するか


どの様にして方式を決定するべきかと言えば一言で言えば性能の理論値を導き出す事です。性能の実測値は勿論ソフトウェアが完成した後でしか測れません。従って作る前に性能目標を達成する為には事前に机上で理論値を計算する必要があります。方式の選択は各方式で全体の理論値がどうなるかによって判断するという事になります。理論値を導き出す為には良く分からない部分については簡単なプログラムを組んで実測をする様な事も必要です。

あくまでソフトウェア全体の性能の理論値を導き出す事によってその一部として自動的に方式が決定されるという事になります。この理論値を出す作業が性能を確保する主な作業と言えます。

いつ決定するか


それではこの様に性能を大きく左右する方式の決定はいつ行うべきなのでしょうか。
結論から言えばそれは計画の立案時です。
何故なら方式を決定するという事は設計の重要な枠組みを決める事でもありますからそれが決まっていないのに正確な見積もりが出るはずがありません。従って見積もりを行う、つまり計画を立てる時には必要だという事です。もしどうしても計画立案時には出来ないという場合には、計画の初期の工程に理論値を出して方式を決定する工程を入れる事です。理論値を導き出した後に今一度計画を修正する旨を伝えて、今回の計画はあくまで暫定的なものだと宣言する事です。「運が良ければ変わらない」程度のものだという事です。

ベストな場所


ここまで設計工程で性能を確保するべきだという話をしてきました。しかし実は設計工程で性能を確保する事が必ずしもベストではありません。一般に問題はより上流で解決した方が効率が良いのです。
つまり企画です。
企画で性能を確保するというのはどういう事かと言うと、例えば業務としてあるアプリケーションの出力結果の印刷物を担当者がExcelに転記入力してメールで関係者に配布しているとします。流れとしては以下の様な感じです。
アプリケーション→印刷→転記→Excel→メール
これに対し新たな商品としてExcelの形式で出力して、かつそれをそのままメールで送信する機能も付けたアプリケーションを提供したとしたらどうでしょう。
アプリケーション→メール(Excel)
この場合この機能の性能がソフトウェア的に見た場合に少々遅かったとしても問題にならない可能性があります。何故なら幾ら遅いと言っても、印刷して人間が目視で転記する時間に比べれば圧倒的に速いですし、それに何と言っても放っておけばいいからです。担当者にとってはアプリケーションを実行した時点で作業は終了する事になります。

企画段階でシビアな性能目標を拭い去る事が出来れば開発はかなり楽になります。
全ての企画でこの様な事が考えられる訳ではないかもしれませんが、企画立案時に常にその様な意識を持つ事は新しいアイデアに繋がる場合もあり有意義な事だと言えます。

一覧


メニュー

関連


UIについて-性能・後編
UIについて-性能・前編


記事を広める



posted by 善 at 18:43 | Comment(0) | TrackBack(0) | 設計 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック