こんにちは。株式会社アップガレージグループ ITソリューション事業部のエンジニア加藤です。 最近、弊社の20%ルール内で取り組んでいる「要件定義の体系的な学習」について記事で共有します。
20%ルールとは？
弊社では、業務時間の20%を将来的なチャンスにつながるプロジェクトの探索やスキル習得の時間として使用可能です。 1日の業務稼働時間を8時間とすると、1週間で最大8時間がこれに割り当てられます。
経緯
これまで「要件定義」といった形式で体系立って学習したことが無く、自分の知識の最適化や棚卸しをしたかったため。
学習に使用した本は以下となります。
特に学びになったこと
備忘録程度に、それぞれの章ごとに特に学びになったことを記載していきます。
1章 要件定義の基礎知識
段取り8割
- 開発規模、希望納期を把握する
- 衝突・トラブルが発生しそうな箇所は予めルールを決めておく
潜在要求の明示化
- 表明あり、認識あり（顕在要求）：網羅的に整理し、より正確に理解する
- 表明なし、認識あり（暗黙の要求）：念を入れて確認を怠らない
- 表明なし、認識なし（潜在要求）：相手からの発信を触発させるよう、複数の角度から質問する
- ※個人の解釈ですが「あ～そういえば◯◯◯ってよく使うかも！」のような回答が引き出せると良いイメージ
ウォークスルー
- 意思決定者に全体を流れで理解してもらい、スムーズに承認が得られるよう準備・リハーサルを行う。
ベンダーとしてユーザーをリードする
- あくまで指針を導き、それを正確に伝えることに徹する
- ユーザーを置き去りにしたり、強制的に操作すべきでない
2章 要件定義の下調べ・段取りフェーズ
開発開始後の想定外を減らすこと
- このフェーズでは想定外を減らすことに注力したい
- 時間は有限なので可能な限り時間を節約する（資料作成など）
- 把握した内容はユーザー（依頼側）にも共有し、お互いの認識齟齬を減らす
ユーザー側のステークホルダを可視化する
- ユーザー側にとっての利害関係者・それとのやりとりを理解する
クリティカルパスは押さえる
ステークホルダの識別
- 本当の顧客、ユーザーを意識する
- 直接対面するユーザー側担当者の意見のみを鵜呑みにしない
- 外部のステークホルダの存在に気づかず考慮漏れになりがち
3章 業務要求の分析・定義フェーズ
現行業務の調査
- 現状の業務を調査し、理想とのギャップを明示化する
- ここでもユーザー側の潜在要求を掘り出す
- 各業務を一覧化し、自動化できる作業が無いか洗い出す
当事者（ユーザー）に「組織に不足する仕組みやスキル」を特定してもらうよう、ベンダとしてアプローチする
- ここで不足している事項が業務要求となる
ビジネス・ルール分析の位置づけ
- 暗黙的な業務やルールが存在すると開発の漏れとなり、結果的に使えないシステムになる
- 開発に際して、ベンダ側一元的にでルールを作成→浸透できるようアプローチする
ステークホルダが主体のレビュー会を開催する
- ベンダー側（要件定義担当）がファシリテーションを行う
- 目的：要件を文書化した後、実際の事業における目標実現に対し有効か確認する
4章 機能要求の分析・定義フェーズ
必要不可欠なもの、必須でないものを判断する
- 肥大化を防ぐため、不要なものは可能な限り整理・廃止する方向で進める
既存システムにおける不具合は、業務の仕組みから正しい形にする
- システムの側面から追求すると期待値がズレることがある
- 分析中に取り決めたこと、設計に引き続くことは文書化する
帳票
- ビジネスやオンライン上の業務フローだけでなく、帳票等の集計結果も分析対象
- 帳票出力では、「目的」「場所」「時間」「ユーザー」をきちんと把握する
- 例：電子表示だけで良い場合、pdf化が必要な場合、紙として印刷機能が欲しい場合など
- 一度に出力される量も踏まえ、期待される出力スピードを意識する
通常期と繁忙期のトランザクション量の違いも念頭に置く
外部接続
- 連携箇所は漏れなく洗い出す
- 何のために使用しているか、導入時に一覧を作る
- システム本体に無いロジックを有しているため、開発・保守で考慮漏れになりやすい
5章 非機能要求の分析・定義フェーズ
性能
- 応答の速さは「5秒以内」など定量的に定義すべきだが、通常のユーザーにはIT知識が無く定義は難しい
可用性
保守性
- 運用・保守は自動化することがよく目標になるが、人の入り込む余地は残しておいた方が良い？
- 自動化しすぎてログを閲覧できない・ログが多すぎて管理できないケースも有り得る
移行性
- 新システム導入時、確実に成功させる必要があるイベント
- 以降前後の規模を見積もり、対策に過不足を作らない
セキュリティ
- 前提として、セキュリティ対策と性能はトレードオフ
- 事故による社会的信頼・経済的な損失を見積もった上で、システムに求められる強度を見誤らない
システム環境・エコロジー
6章 要件定義の合意と承認・維持フェーズ
要件に関する討論と合意
意思決定の記録、経緯と理由の記録
- 承認が得られなかった箇所は、強引な説明は避けて積み残しとして切り離す
- 一部の問題点のために全体が覆されたり、作業が一時停止することは避けなければならない
討論→合意のサイクルはルーティン化する
- 一定周期で合意形成する仕組みで、各メンバーの当事者意識を強める
- 小分けに議論する
ライフサイクル管理
- 正常稼働だけでなく「要求」が意図通り実現できているか？という観点で考える
- 逆に要求されていない機能、例えば「開始当初実装されていたが、環境変化により不要になった機能」は、正常稼働の必要性は低い
自分自身に活かせたこと
学習終了後まもないため実際に要件定義書を書いておりませんが、実務において役立ったことは多数あります。
開発時に意識すべきことの順序を明示化できる
- 要件漏れの防止や業務上の非効率の排除に寄与しました。
自社の価値にまた一つ気づいた
- 直接役に立ったことではございませんが、開発者と実際の現場（店舗）が近く情報伝達が早い弊社は、ビジネスを進めていく上の障壁が一つ少なくメリットが大きいと感じました。
これからについて
要件定義に限らず開発に必要なスキルを継続的に学習し、品質向上や自分のスキルアップに繋げていきます。
株式会社アップガレージグループ ITソリューション事業部では、共に勉強し合い、成長し合うメンバーを大募集しています！ www.upgarage-g.co.jp
