こんにちは、キノトロープアカデミーです。
「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。
＜上級編 第5回＞
運用後に困らないための非機能要件定義
についてお伝えします。
担当は高橋です。
Webサイトのリニューアルや新規制作において、ついつい見た目や機能ばかりに目を奪われがちですが、実は運用が始まってから最も大きな差が出るのが「非機能要件」の定義です。
サーバの耐久性やページの表示速度、動作を保証するスマホ端末の範囲など、目に見えにくい部分だからこそ、事前のすり合わせが欠かせません。運用後に
「急なアクセス増加でサイトが落ちてしまった」「新しいスマホで正しく表示されない」といったトラブルに頭を悩ませないためには、発注者側が自社のアクセス状況や想定する閲覧環境を明確に制作会社へ伝え、あらかじめ運用のルールを定めておくことが何より重要となります。
”運用後に困らないための非機能要件定義”をテーマに、
今日お伝えしたいことは3つあります。
非機能要件は、機能要件にもまして何をしたらよいかわからない、難しそうと思われることが多いかと思います。
確かに、内容自体が難しいということと、直接Webページや見た目に反映されないものが多いため、実感がわかないということもあるかと思います。
また、通常時・正常時は非機能要件を満たしていなくても、気にならないということも影響しているかと思います。
例えば、可用性についていえば、インフラ環境やシステムに何も問題ない状態の場合、
サーバが１台でも２台でも状況に変わりはありません。サーバやシステムで障害が発生した場合に初めて問題の発生に違いが出てきます。
このように直接は見えないが、ある状況下で問題が発生してくる場合があります。それが予想していない、想定できていないことであれば、Webサイトの運用後にとても困ることになります。
非機能要件の内容は、運用後は簡単には変更や拡張が難しい場合もあるため、要件定義時に、運用後を見越して困らないための定義と把握が必要となってきます。
また、非機能要件の内容による費用への影響もあります。例えば、稼働率目標が99%の場合と99.9%の場合で運用費・サーバ費用が倍以上違ってくるなどといった場合もありますので、費用と合わせて必要な定義していく必要もあります。
また、非機能要件の内容による費用への影響もあります。
例えば、稼働率目標が99%の場合と99.9%の場合で運用費・サーバ費用が倍以上違ってくるなどといった場合もありますので、費用と合わせて必要な定義していく必要もあります。
そのため、重要視しない非機能要件部分がある場合などは制作会社に明示してあげることで、運用費などが抑えられる可能性もあります。
非機能要件はその名の通り、機能要件以外のすべての範囲をさしますが、キノトロープではIPA（独立行政法人情報処理推進機構）で定義されている『非機能要求グレードの６大項目』をベースとして定義しています。
まずは簡単に『非機能要求』として決めるべき大枠をご紹介します。内容としては、
・可用性
・性能・拡張性
・運用・保守性
・移行性
・セキュリティ
・システム環境
というものがあります。
非機能要件自体はシステム開発において共通の事項ではありますが、特にWebサイト制作において重要なポイントについて抜き出してお話したいと思います。
性能要件とは、主にはどのくらいのアクセス数までサイトが正常に動作できるようにするかを定めるものです。
月10万PVのサイトなのか、月1000万PVのサイトなのかによって当然対応も変わってきます。
また、性能目標を定義する際に重要となってくる部分としては、
・通常発生するピーク時のアクセス数
・まれに発生する最大ピーク時のアクセス数
の情報を用意し、制作会社に伝えてあげることです。
なぜならば、
・Ａ．月30万PVで1日1万PVのサイト
・Ｂ．月30万PVで月初め1日のみ20万PVのサイト
では用意するべき性能や環境が大きくことなるからです。この例では当然Ｂのほうが高い性能が必要となります。
ピーク時のアクセス数も制作会社に確認してもらうのがよいかと思いますが、具体的な確認方法の例をご説明します。
Google Analyticsの場合であれば、レポートのユーザ＞概要などから『時間別』の表示で確認します。
時間単位などのなるべく短い間隔でのピークとなるアクセス数が本来達成するべき性能となります。この数値をもとに制作会社とリニューアル後に目標時とするアクセス量を定めるのがよいでしょう。
なお、グラフ１のように毎日安定したアクセス数のサイトの場合はわかりやすいですが、例えばこのようなアクセスの場合はどのポイントを目標にするかは検討が必要です。
もちろん最大に合わせる方法もありますが、この場合も費用との兼ね合いとなります。事前に予測できるアクセスであれば、アクセスが増えるタイミングのみ増強する方法もあります。
事前に予測できないアクセス増加については、無駄なコストとなってしまう場合もあるため、予算や会社としての対応するべきレベルにあわせて定義を行う必要があります。
なお、アクセス増に対応する方法としては大きく
・サーバの性能を上げる
・サーバの台数を増やす
・キャッシュする時間を延ばす（キャッシュサーバ利用の場合）
があります。
ログイン機能やユーザによる表示の切り替えを行わないサイトであれば、CDNと呼ばれるキャッシュサーバを利用することで性能を大幅に上げることができます。例えば、1時間キャッシュするや24時間キャッシュするといったことで、かなり多くのアクセス数を処理することも可能となります。
ログイン機能などを伴うサイトではキャッシュが出来る範囲は限定されるため、サーバ性能や台数を上げる必要があります。性能についてはAWS等のクラウド環境であれば比較的容易に上げることができます。
台数を増やす対応については、アプリケーションの仕様やライセンスなどの問題もあり、容易には変更が難しい場合が多いです。
性能要件については今後増やすべき目標のアクセス数を指標として定義することが多いです。例えば、サイトによりますが現状の2倍などと定義しその目標に対応できるように環境を用意してもらうことがよいでしょう。
そして、性能要件が満たせているかの確認も難しいところではありますが、「負荷試験」といって実際想定されるアクセスを擬似的に行い、性能をチェックする方法です。負荷試験を行っているか、負荷試験の結果がどうだったかについては、制作会社に確認するのがよいでしょう。
そしてもう一つＷｅｂサイトにおける重要な性能指標として、表示性能があります。３秒でページが表示されるなどの性能についてです。
こちらも目標時間を設定し計測する必要がありますが、システム的な応答時間と、実際にユーザが利用可能な時間には差が出てくるため注意が必要です。実際に即してなるべくユーザが利用した際に利用可能となる時間を定義するのがよいでしょう。
この場合、回線の速度や、利用しているスマートフォンのスペックにもよるため、計測する環境についても定義を行い、想定をすりあわせておく必要があるでしょう。
Webサイトを閲覧する環境の定義は当然重要となり、OSやブラウザ、そのバージョンの定義が必要となります。またスマートフォンやタブレットについては具体的に検証を行う端末までを指定してもらうのがよいでしょう。
発注者側としては、どの端末でも担保してもらえるのであれば、ブラウザのバージョンまでの定義でもよいのですが、制作会社側で実際にテストを行う端末は限られることが多いため、端末まで定義して担保する範囲を明確にするのがよいでしょう。
そのうえで、スマートフォン端末の違いで起きる不具合はどのような契約範囲で対応を行うかなどをすり合わせる必要があります。また、当然新しいブラウザや、スマートフォン端末が出てきます。
制作会社としてはまだない未来の環境については当然担保することは出来ないのですが、発注者側としては新しい端末への対応をどうするかは重要なポイントとなります。
ため、要件定義のタイミングで、運用時に定期的に新しい端末での動作確認をおこなうといったルールを定めるなど、時間経過・環境変化によるサイトの劣化が極力発生しないような対応も定義することで、安心して運用を続けられることになるでしょう。
最後までご覧いただきありがとうございました。
の３点についての内容でした。
