前段

以前は、仕様がある程度決まった段階でプロジェクトに参画し、
仕様に基づきプログラムコードを書く事が多かったのですが、
先日のプロジェクトで初めて、仕様決めの段階からシステム案件に参画させていただきました。

入社して以来、まともにシステム案件の要件定義を詰めるにあたり、

何の要件を詰めていく必要があるのか
どういったドキュメントがあるのか

といった事を学習した事がなかったのもあり、頭がなかなか追いつかず、プロジェクトは進んでいきました。

失敗談

突然ですが、失敗談を記載します。
先日リリースしたシステムですが、管理画面の開発に想定以上の時間がかかってしまいました。
時間がかかった理由としては、技術力不足はもちろんの事ながら、技術力以外の要因を考えた時に、大きな括りで以下と考えています。

各画面の機能実現のための、最低限のデザイン構成で制作を進めなかった

この経験を経て、管理画面は使い勝手を第一に追求しつつ、できるだけ短い期間で最低限必要な機能を実装し、納品する事が最も良いと感じた次第です。

こういった失敗もありつつ、開発に着手する前の要件定義全般について
自分の中で再度整理し次回に繋げれるようにしておきたいという思いから、記事に書くに至りました。

また、参考として以下書籍を用いています。
システム開発の基本が知れる良い本だと感じました。

参考：図解まるわかり要件定義のきほん

かなり詳しいレベルまで載っているので、この度は、自分の環境でとりあえず必要だと感じている項目を抜粋して記載しました。
ドキュメントの書き方は書籍に載っているので、割愛します。

目次

1. 機能要件
 2. 非機能要件

1. 機能要件

ソフトウェアやシステム開発において、クライアントから求められる「機能」のことです。
次の案件で機能要件を詰める際に、特に意識したい項目については、文章多めに記載している形となります。

1-1. システム化業務フロー・システム化機能一覧

システム化する場合の業務フローを確認します。
そこから、機能を抜き出して一覧化し、機能に抜け漏れが無いか確認します。
業務フロー図が有り・機能一覧がちゃんと書き出してあるケースって意外と少ないのでは？と思います。
自分は何をするにしても洗い出し系が得意ではないです。
だからこそ、これらを意識して抜け漏れを減らしたいと考えています。

1-2. エンティティ一覧

言わずもがな、データ定義を行う際に必要となる作業です。

1-3. 画面一覧

意識すべき事は、以下と考えます。

各画面は、システム化機能一覧のどの機能に属するかを記載し、機能との関係がわかるようにする

何をするための画面なのか明確でないと、結局使用されない画面となってしまうため、注意します。

1-4. 画面遷移図

これ作成するのめちゃくちゃ骨が折れる気がします。。。

機能が多く画面遷移も多い管理画面を作成する場合においては、画面遷移図を作成し、営業・デザイナーと認識合わせをした方が良いのでしょうが、画面遷移図の作成があまりにも辛い作業なのであれば、ワイヤーフレームをもとに議論するなり、デザイナーさんが作成したXDをもとに議論するなりした方が良いかもしれません。
しかし、一度やってみて、判断しても良いかもとも思います。

画面遷移図を作成する際に注意すべき点を記述します。

画面名/画面IDなど画面を識別できるものを入れる
ボタン/リンクを押したときの遷移先を明確にする
画面遷移では戻りの遷移の抜けが発生しやすいため注意する
検索など、自画面内で遷移するボタンも明記する
可読性を高めるために1業務1枚で作成する

参考：図解まるわかり要件定義のきほん

1-5. 画面レイアウト（ワイヤーフレーム、XDなど）

意識すべき事は、以下と考えます。

UI標準化を進めて統一的で使いやすいシステムにする

検索一覧系画面や、データの作成・更新・参照・削除を行う詳細画面などの標準化を行います。
フォントの指定、ボタン機能による色を統一する事で、誤操作を防ぐなど、使い勝手の向上を目指して標準化します。
機能・用途ベースでUI標準化がなされているかしっかり確認してから、画面を作り始めた方が良いと感じています。

1-6. API一覧

フロントエンド開発担当のエンジニアとバックエンド開発担当のエンジニアで明確に分かれている場合に作成すれば良い、という印象です。
しかし自分の周囲では、フロントエンド開発をやってきたメンバーもバックエンドのAPI定義箇所のソースを読めるようにした方が良い、という風潮があるので、これからAPI一覧を作成する事はあまり無いかもしれません。

1-7. バッチ処理一覧

何時何分にどのバッチ処理が実行されるか一覧化します。

2. 非機能要件

非機能要件については全然意識した事がなかったので、知っておく必要があると感じました。
「機能以外」の性能、拡張性、セキュリティなどの品質的に関連するもの全般を指すとの事です。
一般的な例を踏まえて記載しつつ、細かいところは会社の体制と合わせながら、かつインフラを触りながら、理解していく所存です。

2-1. 可用性

継続性
運用時間 24時間（緊急メンテナンスやリリースが発生した場合を除く）

稼働率
基本24時間365日稼働稼働率99.9%（計画停止を除く）

耐障害性

サーバー、ネットワーク：基本的にはクラウドの冗長化で対応する
ストレージ、データ：基本的にはクラウドの冗長化で対応する。DBについてはDBのバックアップを併用する

災害対策
システム：基本的に東京リージョンでのみ運用
Availability Zoneの追加（大阪リージョンなど）については別途費用を頂戴し対応。など

2-2. 性能・拡張性

業務処理量
特に、業務量増大度、同時接続数を意識する事が重要。
同時接続数500リクエスト/秒など

2-3. 信頼性

障害検知
CloudWatchによるモニタリング実施（サーバ障害・アプリケーション障害）

ログ
webサーバ：アクセスログ、エラーログを出力
アプリケーションサーバ：エラーログ、バッチ処理実行ログを出力

バックアップ
ログ：webサーバログを7日間保存、アプリケーションログを7日間保存
データベース：イメージバックアップを取得し、7日間保存
※保存期間はクライアントと調整する

2-4. 性能目標値

クライアント的に性能目標値まできっちり決める事は少ないかもしれないが、知見としてこういった項目がある事を理解しておく。

オンラインレスポンス（web画面）
通常時3秒など

バッチレスポンス
夜間バッチ、DBバックアップを5時間以内で終了など

2-5. リソース拡張性

CPU、メモリ、ディスク、ネットワーク
CPU、メモリ、ディスクは拡張可能なこと

2-6. 性能品質保証

性能テスト、スパイク負荷対応
業務処理量、性能目標値に定めた値の性能テスト、スパイク負荷テストを実施する

2-7. 運用・保守性

通常運用
運用監視：リリース時、アクセス数増大が見込まれるタイミング

障害時運用
システム異常検知時の対応：基本的に10:00〜19:00は受付（障害の内容次第ではこの限りではない）

運用環境

試験環境を1セット準備する
運用マニュアル：必要
リモートオペレーション：google meetなど

サポート体制

ハード/ソフトの保守契約：必要
サポート要員、導入サポート、オペレーション訓練：必要

2-8.セキュリティ

セキュリティ診断
脆弱性診断：外部による脆弱性診断については別途費用を頂戴して対応など

アクセス、利用制限

IP制限（セキュリティグループ・basic認証）
管理画面ユーザー認証機能（ID,パスワード）
応募画面はLINEログイン認証など

通信
SSL通信による暗号化

データの秘匿
パスワードデータは暗号化する

不正追跡・監視

不正監視：必要（ログの取得）
※不正通信を検知次第、不正通信を遮断する、など
マルウェア対策：80及び443及び22以外のポートは基本的に全て閉じ不正なアクセスを防止、など

Web対策
WAFの導入、など

セキュリティインシデント対応/復旧
セキュリティインシデント発生時は、弊社エスカレーションルールに則り対応、など

まとめ

案件次第ではありますが、次回案件ではこれらの要件を意識しつつ、
顧客との調整・社内調整の際には、うまく進めていけるよう準備をしておこうと思います。