要件定義～実際の現場作業を振り返って～

概要

少し大きな開発プロジェクトで久しぶりに要件定義に関わったので、実際に経験した大切なことの備忘録として投稿。
実際の経験を書いているので書籍とは違った生の声として誰かの役に立てばと思う。

要件定義の流れ

1. 目的／ステークホルダー／体制の共有
2. 現状業務の整理（As is分析）
3. システム化範囲の決定
4. 非機能要件の検討
5. 外部設計
6. コスト／スケジュール調整

1. 目的の共有

いわゆるプロジェクトキックオフ。
プロジェクトにもよるけどコンサル的な立場でない限り目的はお客さんから言われる場合が多いと思う。システム化することで売上増を目指すや今の業務上の課題を解決したい、業務効率化したいなどもうちょっと具体的に何を一番解決したいかがあるはずなのでそれを関係者と共有する。
この目的の共有はプロジェクトに関わる人すべてにしておかないと実際作ってみたけど使えないシステムになってしまった。とかよくある話しのため、後からプロジェクト参加するメンバーにも正確に伝えらえるよう関係者全員に周知する必要がある。

次にステークホルダーや内部の体制の共有。
このメンバーでやっていきます。って宣言だったり、各ステークホルダーの役割分担の明確化のために実施する。少なくとも<お客さん>と私たち<開発者>、あと連携先の<他システム担当者>とかは必ずいる印象。
前のプロジェクトで一緒に仕事をした経験があるか、それとも初めての相手かで今後の要件定義の難易度が結構変わってくる。あのチームとはすんなり調整ができそうだとか、あのチームはいまいちそうだからリスクだね。とかなんとなくわかったりする。システム作りって結局人と人とがやるから相手次第と感じられるとき。

意思決定権を持つお客さん（役割上ではなく実際に決めてくれる人）とかもここで把握しておくと、後々進めやすくなる。

2. 現状業務の整理（As is分析）

ここからが実際のプロジェクト作業の開始。
まずやることは現状業務の整理いわゆるAs is分析。現状業務なのでお客さんがよく知っていると思いきやドキュメント化されていることはまずなく、開発者が主体でヒアリングしてモデル化する。

この時、ヒアリング先を誰にするかが重要。打ち合わせには出てくるのはお客さん先のIT部門の人がメイン。IT部門の人が現状業務を知っていればいいが、まず細かいところは知らない。ヒアリング先を明確にして実際に業務をしている現場の人にヒアリングできるかがキモ。でも現場の人って実際は業務してるわけで基本的には忙しい。そこをうまく仲介してくれるかがお客さんのIT部門の力に掛かっている。IT部門に力がないとなんとなくこの頃から失敗しそうな空気を感じる。。。

多少愚痴になりそうなため、ここまでにして具体的なヒアリング内容を以下に記載。
基本的にはよくある5W1Hだけど少し補足。

〇ヒアリング内容

• いつ？
  • 何時ですか、どのくらい時間がかかりますかという部分と、その時って忙しい中やってるのかゆとりがある時間にやっているのかが結構重要。当たり前だけど忙しいときの要求は高くなりがち。
• 誰が？
  • 主にITスキルは？的なもの。ブラインドタッチできますよ。とか、Word／Excel余裕ですよ。とか想像してるとダメ。実際の現場ってパソコン触ったことないとかの人が普通にいる。
• どこで？
  • ちゃんとしたオフィスの机の上か、それとも駐車場の空きスペースかとか。実際システムに使用するにあたって場所による制限はないかの確認。
• 何を？
  • 業務で使用しているのは画面やデータといったデジタル化された物か、実際の物体、アナログ的な物か？後者の場合、大きさ重さは？それによる制限は付かないかなどを確認する。
• どうやって？
  • 手書きなのか紙で作っている台帳か、デジタル化されているExcelとか表計算ソフトとかかの確認。
• 目的は？
  • 一番上に持ってきてもいいくらい重要。そもそもその業務って何のためにやっているのか？は常に理解しておく必要がある。
• 例外的な業務は？
  • たくさんヒアリングして完璧だと思いきや、実は基本的な業務はそうだけどこんな時だけこうしているんですよ。ってプロジェクトの途中で突然出てきたりする。。。早めに対策できるように早めに抑えておく。
• 何が一番助かるか？
  • プロジェクトの目的と現場の解決してほしい課題って意外にずれていることがある。

〇アウトプット

• 業務フロー
  • ヒアリングしたことはドキュメント化する。モデル化手法はいろいろあるけど、とりあえず業務フローが一般的な気がする。↓なもの。

最近はフリー素材もありますね。

業務フロー図テンプレート - 無料ダウンロード
https://www.edrawsoft.com/jp/process-flow-templates.html

〇補足

お客さんにもよるがこのフェーズが最も重要で最も大変と思える。
誰がいつまでに何をして何を回答／整理してくるのか、アウトプットに対しいつまでに確認して合意するのか名確認する必要がある。

〇参考URL

• 業務分析とは
  • http://www.consulting-skill.com/analysis/

3. システム化範囲の決定

ここからがシステムの話し。
実際にシステム化範囲を決める。ちょっと乱暴だけど「1. 目的」がTo beで「2. 現状業務」がAs isなのでそのギャップをどの部分までシステム化して、どうやって実現するかを設計する。

システムとして以下などが一般的な解決策になり、システムの構成部品になる。
それぞれシステムの実現性（技術的に実現可能か）を検討した上で決定する。

• 画面
• 機能
• インターフェイス連携
• バッチ
• データ

〇アウトプット

• 業務フロー
  • この業務フローはシステム構成部品が登場する新業務フロー。新しい業務フローでシステムを取り入れて業務がまわるか検証する。
  • 人とシステムの連携内容／入出力／論理データを整理する。
• 画面一覧
• 機能一覧
  • 機能の複雑性をここで明確にする。インプット量／種類は？処理内容／ビジネスロジックの複雑性は？アウトプット量／種類は？
  • 量／種類が膨大になりそうな場合はここで全量の認識合わせをしておく
• インターフェイス一覧
• バッチ一覧
• 帳票一覧
• データモデル図

〇補足

経験的にここで異常時の設計を行い業務フローに取り入れておくと、後々楽ができる。
もしシステム異常が発生したら？処理遅延が発生したら？どうリカバリして業務をまわすのか、業務フローで整理しておきたい。
特に最近はネットワークが関係しないことはまずないため、オフライン時にどこまで求められるのかも整理しておくといいと思う。

システム化の範囲を決めるタイミングのため技術的課題が挙がることが多いフェーズ。課題を細分化し１つ１つ潰していく。それでも課題事項が解決できない場合は阻害要因の本来の目的から確認し阻害要因に対し別のアプローチができないか確認することも重要。

4. 非機能要件の検討

システム化範囲が決まったら忘れがちな非機能要件を検討する。
非機能要件は実はたくさんあるが重要度が高いものは以下の２つ思う。

• 性能要件

  • １つの処理に期待する性能は？
    • 95%1秒以内、5%3秒以内、1%10秒以内等を決める
  • 1度に処理する処理量は？
    • 1件なのか、100件を超えるのか、それ以上か、によって画面なのかバッチなのか等のシステムとして実現方法が決まる
  • 蓄積データ量は？
  • 1年間でどのくらいのデータ量見込みか？何年分保持するのか？
    • 100万件：まぁ大丈夫かな。1,000万件：ちょっと処理内容気にして設計しようか。1億件：え？しっかり考えて設計しないと総合評価で命取りじゃない。。。みたいな感覚が大事。総合評価でダメってなった時の自分の青い顔が浮かぶ(^^;)

• セキュリティ要件

  • 個人情報／機密情報を保持することになるか？
  • 保持データやログ／通信路の暗号化は必要か？

これらに対しシステムとしてどう対策を実施するかを決める。

〇アウトプット

• 非機能要件一覧
  • 具体的な数値をちゃんと記載しておく。

5. 外部設計

ここからは開発者として得意な範囲。主に外部（お客さんや他システム）に影響する内容を項目ベースで決定する。
一番上に書いている画面関係がまずは最重要。ITリテラシーの違うお客さんは画面イメージが出てきてこの段階で初めてシステムのイメージができたりする。え、今まで文字で書いてきた内容って実はこういう意味だったの？みたいなお客さんとの認識違い是正されるのがこのタイミングなので画面はしっかり書けば書くほど後のリスクが減ると思う。
その点、画面がないバッチとかは処理シーケンスやデータモデルなどあの手この手でお客さんとイメージを合わせていく。
書いてはいないけど、最後に画面／機能／データの関連図が書けると尚良い。
〇〇画面で△△情報が表示されて、ボタン押下で□□機能に情報が連携・処理されてDBに保存されるよね。みたいなイメージ図。

〇アウトプット

• 画面一覧
  • 画面遷移図
  • 画面設計書
• 機能一覧
  • 機能設計書
• インターフェイス一覧
  • インターフェイス項目設計書
• バッチ一覧
  • バッチ設計書
• 帳票一覧
  • 帳票レイアウト設計書
• データモデル図
  • 論理データベース設計書
  • E-R図

〇参考URL

要件定義～システム設計ができる人材になれる記事

大変参考になりました！

6. コスト／スケジュール調整

今までのステップでお客さんとどんなシステムにするかイメージのすり合わせができた状態になる。
じゃあ、ここからは実際に作っていきましょう。とスタートできるかというと実際は違うケースが多い。
大体、お客さんのやりたいこと／理想は肥大化していて、当初のプロジェクトのコストとスケジュールに収まりきらないケースが多い。

そこで今まで作ったアウトプット（主に機能一覧や画面一覧）にお客さんの優先度とシステム側のコスト（開発規模）を付けて何をスケジュール内で開発していくか（プロジェクトスコープ）を決める。

この時、コスト／スケジュールでお客さんの本来のやりたいことが実現できなくなると元も子もないので、スコープ外なった機能がなくてもお客さんの本来のやりたいこと（システム化の一番の目的）が達成できるのか、再度業務フローで検証などがシステム担当としては必要になる。

まとめ

忘れないうちにプロジェクトを振り返って経験から得たことをまとめてみた。
後半は少しざっくりになりがちだったのでまた何か思い出したら更新しようと思う。
いずれも個人的な経験をもとにしているため万人に通じるものではないが誰かの役に立てばと思う。

参考書籍

【Kindle版】はじめよう! プロセス設計 ~要件定義のその前に

【Kindle版】はじめよう！システム設計 ～要件定義のその後に