webサイト制作の要件定義は「機能要件」と「非機能要件」に分けよう。
webサイトの要件定義は概念が曖昧。
今回の結論は、webサイトリニューアルの要件定義でも「機能要件」と「非機能要件」がある。という話です。
まず、みなさんにお伺いしたいのですが、webサイトの要件定義とは何か説明できますか？
「やることとやらないことを明確にする。」という感じでしょうか。
はい。
では「やることやらないことはどう選別しますか？」という質問に対してはどうでしょう。
「こうしています。」という明確な答えを持っているwebディレクターってそんなにいないんじゃないかって思います。
webサイト制作の要件定義でも「機能要件」と「非機能要件」が必要。
いわゆるシステム開発・ソフトウェア開発案件において、要件定義には、機能要件と非機能要件に分けて考えられます。
私もプロデューサーとして長いですが、ことwebサイト制作となると、あまりそういう分類を意識して要件定義をされている印象がありません。
「いやー、ざっくりしてるなー」っと感じることが多いものです。
たまに、『クライアントのシステム部門からそれに類する細かい要求が出てくることもある。』くらいの感じです。
そもそもwebサイト制作では、システム開発・ソフトウェア開発と同等の要件定義をすべきなのでしょうか？
答えはYESです。
なぜなら・・・
数ページの会社案内が掲載されたコーポレートサイトならまだしも、CMSやお問い合わせフォーム、場合によっては、複雑な商品検索のシステムがwebサイトに乗っかってきますし、サイトのパフォーマンス的なことも関わってくるのが普通だからです。
そんなwebサイトに関わるwebディレクターはその要件をきちんと理解・整理しておく必要があります。
webサイトのリニューアルの要件定義には、機能要件と非機能要件があり、そこを取りまとめる責任がwebディレクターにはありますよ、ということです。
では、機能要件、非機能要件それぞれについて、webサイトのリニューアルだと、どういう要件に落とし込まれることが多そうかというのを紹介していきます。
「機能要件」は文字通り実装すべき機能。
まず機能要件についてですが、これは文字通り実装する機能です。
例えば・・・
- サイト内検索機能
- プレスリリースの発信を管理する機能
- 刊行物をeBookで閲覧できる機能
- お問い合わせフォームに入力された内容を企業担当者にメール送信する機能
といったものです。 機能ということでいうともっと細分化できます。
ただ、お見積を作る上で、「まぁこの辺まで決めておけばブレないよね。」というレベルまでは定義しておいた方が安全です。
「非機能要件」の範囲は広い。６つに分類して考える。
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）が発足させた非機能要求グレード改訂ワーキング・グループ」で「非機能要求グレード」なるものを定義しているのでそちらを参考にしますね。
IPAというと、安全なwebサイトの作り方、といったガイドラインも出していて、多くのシステム会社も参考にしているところだと思います。
1. 可用性
webサイトのサービスが問題なく途切れることなく継続できるかという話です。
例えば
- アクセス過多でサイトの閲覧に支障がでたらどうするか。
- 悪意ある攻撃から守るためにどうするか。（WAFやUTM等）
- サーバのデータセンターが直下型の地震で仮に崩壊したらどうするか。
といったものです。
webサイトのサービスが停止しないように、講じる策を決めておく必要があります。
webサイトのサービスが停止するようなことは起こらないに越したことはありませんが、「そうなってしまったらどうするの？」「そうならない対策って取れますか？」って話です。
私の経験では、業務性質上、絶対にサービスが停止してはいけないというクライアントの例で、webサーバを東京と札幌の２拠点におき、DNSラウンドロビンというやり方で、いずれかが障害で使えなくなっても、もう片方で同様のサービスを継続できる、というような対応を行いました。
システムサービスを継続的に利用可能とするための要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・運用スケジュール（稼働時間・停止予定など）
・障害、災害時における稼働目標
実現方法例
・機器の冗長化やバックアップセンターの設置
・復旧・回復方法および体制の確立
2. 性能・拡張性
webサイトのパフォーマンス、機能やスペックの拡張についての話です。
- どのくらいの同時アクセス数に耐えられるか。
- どのくらいデータ量をwebサーバにアップロード可能か。
- サイトの表示スピードはどの程度を担保するか。
- 機能は同じだが、選択できる属性だけ異なるというCMSの機能拡張が容易か。
といったものです。
サーバによっては、ディスク拡張がすぐできなかったり、CMSの実装を根本から考え直す必要が出てきたり、「拡張」という点において考慮が甘いケースが多いように感じます。
システムの性能、および将来のシステム拡張に関する要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・業務量及び今後の増加見積り
・システム化対象業務の処理傾向 (ピーク時、通常時、縮退時など)
実現方法例
・性能目標値を意識したサイジング
・将来へ向けた機器・ネットワークなど のサイズと配置＝キャパシティ・プランニング
3. 運用・保守性
webサイトをどう運用し、どうメンテナンスするのかといった話です。
例えば、
- CMSのセキュリティアップデート対応をどうするか。
- 緊急事態発生時の対応、連絡体制をどうするか。
- インフラ稼働監視をどうするか。（有人監視、アラートをメール等）
- CMSや各種契約情報のアカウント管理をどうするか。
など。
webサイト公開後のことは、webサイトリニューアル初期の要件定義フェーズで考えておいたほうがいいです。制作側にとってはそれが制作スコープにも関わってきます。
システムの運用と保守のサービスに関する要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・運用中に求められるシステム稼動レベル
・問題発生時の対応レベル
実現方法例
・監視手段及びバックアップ方式の確立
・問題発生時の役割分担、体制、訓練、マニュアルの整備
4. 移行性
webサイトリニューアルする際に、旧サイトからどうデータを移行するのか、といった話です。
webサイトのリニューアルというと、既存サイトの扱いに目を背けるわけにはいきません。
何を移行して、何を移行しないのか。
移行するとした場合にどう移行するのか。そういうことを決めておく必要があります。
例えば、
- 基幹システムとの連携引き継ぎをどうするか。
- お知らせページの移行範囲、移行方法をどうするか。
といったものです。
お知らせページの移行範囲を例にあげましたがここをちょっと深掘りしておきます。
お知らせページやプレスリリースページは、ページ数が膨大なことが多いので、認識の齟齬があると、膨大な追加コストがかかる可能性があります。
なので、webディレクターは特に気にしておいた方がいいです。
「直近3年間のお知らせのみ移行する。」
「お知らせページ内リンク切れは考慮しない。」
といった決め事を作っておくことをお勧めします。
最近だと、RPA（Robotics Process Automation）とかいう技術を使い「移行対象コンテンツの修正を自動化する。」
というケースもあったりしますが、元のHTMLコーディングソースの状態次第ということもあり、残念ながら一概に出来るとは言えません。
現行システム資産の移行に関する要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・新システムへの移行期間及び移行方法
・移行対象資産の種類及び移行量
実現方法例
・移行スケジュール立案、移行ツール開発
・移行体制の確立、移行リハーサルの実施
5. セキュリティ
文字通りwebサイトのセキュリティをどう担保するのかという話です。
ここは、専門のシステム会社、サーバ保守会社などに相談することが多いですが、webサイトのセキュリティ担保のためにどういうことをしないといけないかは理解しておいた方がいいです。
例えば、
- DDoS攻撃対応
- ウィルス対策
- クロスサイトスクリプティング対応
- SQLインジェクション対応
- 秘匿性高い部分のアクセス制限
など。
バックエンドのプログラム開発を行うプロジェクトについては、情報処理推進機構（IPA）が提供しているセキュリティ実装チェックリストでバックエンドエンジニアやシステム開発会社に対応の確認してますね。
情報システムの安全性の確保に関する要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・利用制限
・不正アクセスの防止
実現方法例
・アクセス制限、データの秘匿
・不正の追跡、監視、検知
・運用員等への情報セキュリティ教育
6. 環境・エコロジー
これは、制作環境、サーバ環境など、webサイトの開発、運用を行う環境における決め事のようなものですね。
秘密保持契約や業務委託基本契約内で定義されているので、プロジェクト単位での要件定義に含まれることはあまりないのかなと。
システムの設置環境 やエコロジーに関する要求
情報処理推進機構（IPA）とソフトウェア高信頼化センター（SEC）による非機能要求グレード改訂ワーキング・グループ」で定義された「非機能要求グレード2018」
要求例
・耐震/免震、重量/空間、温度/湿度、 騒音など、システム環境に関する事項
・CO2排出量や消費エネルギーに関する事項
実現方法例
・規格や電気設備に合った機器の選別
・環境負荷を低減させる構成あ
要件定義で「そこまで求められる？」って意見について補足します。
webディレクターはやることが多い職種です。
そこまで見切れないということがあるのもわかります。
ただ、具体的なところは、システムエンジニアやバックエンドエンジニアのサポートを受けるとしても、何を決めておかないといけないか、ということはwebディレクターがリードする必要があります。
それも全部を押さえる必要はなく、先に挙げたようなよくあるもの、緊急性が高そうなものについて抑えておく、ということで問題ないと思います。
あとは、クライアントのシステム担当からの要望も出てくるでしょうし、細部は専門家の意見を踏まえて決定していけばいい。
問題は、運用時に想定外のまずい事態が起きてしまうことです。
webディレクターは、リスクに「どう対応するのか、しないのか」をクライアントに説明できる状態にしておく必要があります。
要件定義の非機能要件はプロだからこそフォローすべき領域なのかなと。
機能要件、非機能要件は、システム会社が把握しておけば良い話ではなく、webサイトも１つのシステムと捉え、webディレクターはそこに関与し、理解しておかなければいけないというお話をしました。
大事なポイントをまとめておきます。
機能要件は、クライアントもwebサイトのリニューアルの初期段階で「ああいうことをしたい」「こういうことをしたい」って出てきやすいです。
機能設計や画面設計を行うにあたって、進行上目に触れることになるので忘れられることはありません。
しかし、非機能要件については、クライアントの担当者も詳しくないし、公開後のことってついつい後回しになってしまいがちなんです。
そういう領域だからこそ、プロである、制作側からクライアントに提案し、誘導する必要があります。
要件定義は見積と対になります。最初の段階で機能要件と非機能要件をwebディレクターが先導して決めていくことが大事ということです。
結果そうすることで、余計な齟齬がなくなり、最終的なクライアントの満足度も高まるのは間違いないです。
特に非機能要件。そこを説明出来る知識と提案力、高めていければです〜。
