性能要件について<性能・拡張性> | システム導入検討のエッセンス(6)

性能要件について<性能・拡張性> | システム導入検討のエッセンス(6)

イントロダクション

前回、前々回と非機能要件から可用性についての話をしてきました。
今回からは性能・拡張性についての話をしていきたいと思います。

システムの性能は、主にシステムからのレスポンスが対象になります。
ボタンをクリックしてから画面に結果が描画されるまでの時間、というとわかりやすいですが、そんなに簡単なものではありません。

性能要件を完全にユーザー側で定義するのは非常に難しいです。
しかし考え方だけは理解しておかないと、機能要件ばかり追いかけて理想の機能を達成できたとしても、業務に支障が出るレベルでレスポンスが悪くなる、ということが起こります。

スポンサーリンク

性能要件について

どのような条件下での性能なのか

性能についての要件、というだけなら「操作時のレスポンスが〇秒以内であること」というだけになります。

当然ながら性能要件としてこれでは不十分です。
何台のパソコンから接続されるのか、何人のユーザーがログインするのか、業務毎の使用頻度はどれくらいかという「条件」が抜けているからです。

例えばシステムに1人しかログインしていない状態でレスポンスが要件を達成していたとしても、10人、100人ログインした時には要件を達成しないことがありえます。
だからといって「どんな条件下でも」などという条件は非現実的です。
日本中、世界中から日々アクセスされるようなGoogleやYahoo!のポータルのようなWebページの性能と社内ユーザーだけが接続するシステムの性能を同じにする意味は全くありません。

性能を達成させるためには、効率的なプログラムの記述方法やデータのインデックス作成も必要ですが、そもそもハードの性能を超える性能は出せません。
利用者、利用頻度にあったハードを選定しないと、性能が足りなくてもレスポンスが悪化しますし、逆にオーバースペックでも過剰な投資になってしまいます。

条件の導き出し方

条件として提示が必要となる数値は以下のようなものがあります。

・システムを利用する予定のクライアント(パソコン、スマデバ)台数
・システムを利用する予定のユーザー数
・想定トランザクション数(≒処理数)とピーク
・想定データ件数

クライアント数やユーザー数はすでに管理している情報を元に提示できますが、トランザクション数やデータ件数はどのように導き出せばよいでしょうか。
現行システムがあれば、そのシステムのトランザクション、データ件数を採取するのが正確ですし確実でしょう。
システム化されていない業務であれば「想定」でしかないかもしれませんが、現行業務の処理数を確認しておくことが最も近い値になります。

例えば勤怠管理について、休暇の申請件数が全社で年間何件あるか、1件の申請の決裁者は平均何人いるか、種別毎に集中的に申請される時期があるか、申請や決裁が集中するような時間帯があるか等が挙げられます。

これらを今回導入をしようとしている業務毎にある程度の数値として把握し、要件として提示する必要があります。

条件自体が実態とブレがあると、こちらが提示した条件には適合した性能になっていても、そもそも条件通りの使い方をしていないので性能が出ない、ということもありえるので、できる限り正確な数値が必要です。

システムが性能を保証する範囲

「操作時のレスポンスが〇秒以内であること」という要件に不足しているもう1つの条件があります。
それは「どこからどこまでが〇秒以内なのか」です。

エンドユーザーのイメージとしては、Webシステムであれば自分のパソコンのブラウザからボタンをクリックして結果が返却されるまでの時間、となると思いますが、実際にはそこまで補償してくれるシステムはほぼありません。
システムが設置されているサーバからエンドユーザーのWebブラウザの描画に至るまでの伝送経路やパソコンの性能によりレスポンスが左右されてしまうからです。

システムとしてはデータの検索効率もプログラムの効率もハードの性能も良いのに、設置場所から外部に接続して経由してくるネットワークの伝送速度が遅く、結果的にエンドユーザーから見たときに「システムが遅い」と言われても、システムベンダーは対策のしようがありません。
クラウドサービスの場合さらに如実で、どれだけバックグラウンドのネットワークを高速にしても、エンドユーザーが速度の遅い回線を利用していればどうにもなりません。

操作しているパソコン自体がメモリが不足していたり、CPUが貧弱だったり、そうでなくても他のソフトの影響でパフォーマンスが低下していることもあり得ます。
ソフトやシステムの「推奨スペック」は、ただ単に動くか動かないかだけではなく、所定の性能を保証できるスペックを提示しています。
これを達成していないのに「システムが遅い」と言うのは言いがかりでしかありません。

基本的にシステムが保証するレスポンスは、「システムがリクエストを受け付けて、レスポンスを返却するまでの時間」であると考えなければいけません。

スポンサーリンク

中締め

現行業務の把握なくして業務改善なし

性能要件については、利用者側が「このシステムは誰が、どれくらい使うものなのか」をきちんと把握する意味合いもあります。
システムを導入することによる効果を正しく把握するためにも、「誰が、どれくらい使うシステムなのか」という想定と、結果の測定方法を準備する必要があります。

システム主管を部門間で押し付け合い、結局誰が何をやっているかの全体像がわからない、というのが最もよくない状態です。
これらの把握なくして、システム導入による効果を訴求することはできません。

実際の調達時に要件としてどこまで詰めるかというだけではなく、日頃からこの意識をもってシステム運用にあたることも重要と考えます。


RFI・RFP/プロジェクト管理関連の記事を纏めています。

PJ管理カテゴリの最新記事