記事の概要
経験に基づき、今でもありがちな要件に関する考え方をシェアする。
対象者
下記に該当する現場に参画している。
- ウォーターフォール開発
- 参画先のエンドが老舗の企業（あくまで傾向なので、これは気にしなくても良いかも）
且つ、下記のいずれかに該当する。
- 詳細設計以降を担当していたが、上流工程を任され始めた。
- 詳細設計以降を担当しているが、上流工程を任されたい！
注意点
- あくまでざっくりと、経験から言える内容であること。
- 技術的な詳細は省略するので、自身で日々学習すること。
筆者スキルなど
作成した基本設計書の数（大体）
| 種別 | 実績本数 |
|---|---|
| 画面／UI | 170 |
| バッチプログラム | 90 |
| テーブル | 230 |
今回のテーマが役に立った案件
- 小売業向け棚卸代行サービス業の業務システム：13年半
- 食品製造業向け販売管理システム：3年半
題材とする案件（現仕様と要件の説明）
今回は、例として架空の『菓子を販売する会社』の売上を管理するシステムとする。
※かなりレガシーな内容だが、実際にまだこういうシチュエーションは存在する。
現状の仕様
- 販売データが、各店舗から随時トランザクションテーブルに追加される。
- ユーザは現状、トランザクションのデータはCSVでエクスポートし表計算ソフトで利用している。
トランザクション（販売実績）のイメージ
下記のように、販売データが都度追加される。
| 明細番号 | 売上日 | 時刻 | 店舗コード | 品目コード | 販売数量 |
|---|---|---|---|---|---|
| 1 | 2024/4/1 | 12:45 | 11 | 10001 | 4 |
| 2 | 2024/4/1 | 13:30 | 21 | 10002 | 11 |
| 3 | 2024/4/2 | 10:32 | 11 | 10001 | 8 |
業務要件
ユーザの要件は下記の通りである。
- CSV→表計算ソフトをやめて、トランザクションのデータを手軽に見られるようにしたい。
機能要件
ユーザの要件を満たすために必要なこと。
- 店舗名や品目名を表示（マスタから拾う）
- 売上の金額を算出（複数の項目で演算）
- 店舗、品目、売上日の単位で集計（サマリー）
これを実現するには、店舗情報と品目情報が登録されたマスタテーブルが必要となる。
マスタ（店舗マスタ）のイメージ
店舗コードから判明する情報が登録されている。
| 店舗コード | 品目名称 |
|---|---|
| 11 | 東京 |
| 21 | 大阪 |
マスタ（品目マスタ）のイメージ
品目コードから判明する情報が登録されている。
| 品目コード | 品目名称 | 単価 |
|---|---|---|
| 10001 | チーズケーキ | 1000 |
| 10002 | ガトーショコラ | 2000 |
データ作成用のSQL（ざっくりレベル）
SQLを普段から触るのであれば、要件を把握した時点で大体イメージ出来るだろう。
SELECT
th.売上日 ,th.店舗コード ,mt.店舗名, th.品目コード ,mh.品目名
, SUM(ROUND(COALESCE(mh.単価,0) * th.販売数量,0)) AS 売上金額 -- 売上金額は導出項目
, SUM(th.販売数量) AS 販売数量 -- 販売数量も集計
FROM 販売実績 th -- ベースはトランザクション（販売実績）
LEFT OUTER JOIN 店舗マスタ tm ON th.店舗コード = tm.店舗コード
LEFT OUTER JOIN 品目マスタ hm ON th.品目コード = hm.品目コード
GROUP BY th.売上日 ,th.店舗コード ,mt.店舗名, th.品目コード ,mh.品目名 -- 集計単位
ORDER BY th.売上日 ,th.店舗コード ,th.品目コード -- 表示順は要件次第
;
アウトプット（機能要件通り）のイメージ
上記のSQLを実装すれば、名称や売上金額を追加した販売データが参照できるようにする。
| 売上日 | 店舗コード | 店舗名 | 品目コード | 品目名 | 売上金額 | 販売数量 |
|---|---|---|---|---|---|---|
| 2024/4/1 | 11 | 東京 | 10001 | チーズケーキ | 4000 | 4 |
| 2024/4/1 | 21 | 大阪 | 10002 | ガトーショコラ | 22000 | 11 |
| 2024/4/2 | 11 | 東京 | 10001 | チーズケーキ | 8000 | 8 |
非機能要件
業務に支障がでないようにすること。
- 表示のレスポンスが３秒以上かからないようにして欲しい。
実装手段
検討の結果、BIによるレポーティングとなった。理由は下記の通り。
- コスト削減（要件的にスクラッチでゼロから組むまでも無い）
- 拡張性／将来性（分析のため、軸を変えた出力の要望を見越して）
実装方法を考えてみよう
さて、ここまで読んでみて実装のイメージは思いつくだろうか？
思い付くとしたら、候補はいくつだろうか？
要点は下記の通りである。
- トランザクションとマスタを結合する（名称取得と金額計算に必要）
- 上記の結合した結果をBIレポートへ表示させる。
パターン１：BIで頑張る
これは発想としては最も分かり易い。
BI側でGUIの結合ツール、または手書きでSQLを使って実現する方法である。
正直、これで良いならこれで済ませたいところだが、問題が無い訳では無い。
〇メリット
- リアルタイム性に優れる（最新の販売実績を常に参照可）
- テーブルや他の機能に影響しない
×デメリット
- オンラインのテーブルから直接拾うと、データ量次第ではパフォーマンスが悪くなる。
- 機能的に何がどこまで可能かはBI製品の仕様に依存する。
パターン２：DBにビューを作る
トランザクションとマスタを結合したビューを作り、BI側はそれを参照するだけとする方法。
結合のSQLを１つ作って置いておくだけで、BI側は単純にビューを拾うだけで済む。
ただ、パターン１と共通する問題点は残る。
〇メリット
- リアルタイム性に優れる（最新の販売実績を常に参照可）
- 他の機能に影響しない
×デメリット
- テーブルから直接拾うのとほぼ一緒なので、データ量次第ではパフォーマンスが悪くなる。
- もしテーブル定義の変更が必要な時、ビューのせいで変更できなかったり、ビューを消す必要がある。
パターン３：DBにマテビューかDMを作る
トランザクションとマスタを結合したビューを実体として保存し、BI側はそれを参照するだけとする方法。
パターン２との違いは、ビューは実体が無く簡単に言えば都度SQLが実行されてしまうが、マテビューやDMは更新の時だけSQLが実行されるので、パフォーマンスに優れる。
尚、マテビューはマテリアライズドビュー、DMはデータマートの略である。
詳細は自身で調べて頂きたいが、要するに一時的（または恒久的）にテーブルを作り、データを格納しておく場所である。
〇メリット
- ユーザが参照する際のパフォーマンスに優れる（非機能要件を満たすのが容易）
- 大元のテーブルや機能に不具合があった際の影響を抑えられる（少なくとも次の更新タイミングまでは）
×デメリット
- リアルタイムではないので、更新頻度を関係者間で決めておき合意を取らなければならない。
- 更新用のバッチプログラムやストアドプロシージャ等を追加する必要がある。
- 更新タイミングは、他の機能の更新タイミングと調整する必要がある（いわゆるジョブネット）
パターン４：大元のテーブル定義を変更する
最後に、基本的にやってはいけないがどうしようもない時の奥の手を紹介する。
いっそのこと、トランザクションテーブル（販売実績）を要件通りのレイアウト（アウトプットイメージ）に変更し、販売実績を追加する機能を変更する方法である。
その場合、店舗名や品目名、売上金額（単価×数量）も店舗で売上が立ったタイミングで追加される。
分かり易さで言うとパターン１と同じくらいだが、こちらは致命的なデメリットが発生する。
〇メリット
- 最もリアルタイム性に優れる（要件通りのテーブルに随時追加されるのだから）
- 追加モジュールが不要（BI側は見るだけだし、ビューやマテビュー、DMも不要）
×デメリット
- テーブル定義の変更は他の機能への影響が考えられ、場合によっては多くの機能が改修対象となる。
- 逆正規化となり、更新時異状が発生しトラブルの温床となる（致命的デメリット）
逆正規化や更新時異状について知らない人は、データベース設計に関する書籍で勉強して欲しい。
※個人的に良いと思う２冊
どれが良い選択か？
候補が出たところで、どれを選択するべきか？
いくつかの観点で判断が必要である。
運用面
- 扱うデータ量は？（件数や容量）
- 同時に利用するユーザ数は？
- ユーザが利用可能な時間帯は？（バッチ処理の場合に考慮が必要）
- あと何年くらい使うシステムなのか？
大人の事情
- コスト
- 納期、開発期間
- 社内政治（ユーザ側もベンダ側もあり得る）
などなど・・・
結局は
最終的に決めるのは『お客様』 であるユーザ企業である。
だが、導入した結果『お客様』が困らないように、最善策を推すのは我々ベンダの役目だ。
「お客様がこう言ったので～」 というような無責任な仕事にならないように気を付けたい。
という訳で、判断基準は 『お客様が、何を最優先に考えているか？』 ということになる。
今回挙げた４つのパターンを簡単な図に当てはめてみよう。
汎用的な判断基準
純粋に実装方法だけで考えるとこのような結果になると考えられる。
| 提案 | コスト面 | 安全性 | レスポンス速度 | リアルタイム性 | オススメ度（暫定） |
|---|---|---|---|---|---|
| パターン１（BIで頑張る） | 〇 | 〇 | △ | 〇 | 〇 |
| パターン２（ビュー） | 〇 | 〇 | △ | 〇 | △ |
| パターン３（マテビューかDM） | △ | 〇 | 〇 | △（×に近い） | 〇 |
| パターン４（大元の変更） | △ | × | 〇 | 〇 | × |
要望や事情を考慮した判断基準
上記に更に事情を考慮した基準を加える。
下記は一例に過ぎない。実際の現場はもっと複雑なはずである。
ここでの判断には一般的な正解は無いと考えている。
無難という観点ではパターン１（BIで頑張る）かパターン３（マテビューかDM）になるだろう。
| 考慮する点 | 少ない（短い） | 中間 | 多い（長い） |
|---|---|---|---|
| ライフサイクル | パターン４（大元の変更） | パターン１（BIで頑張る） | パターン３（マテビューかDM） |
| データ量 | パターン２（ビュー） | パターン１（BIで頑張る） | パターン３（マテビューかDM） |
| 同時アクセス数 | パターン２（ビュー） | パターン３（マテビューかDM） | パターン３（マテビューかDM） |
要件定義が完了
様々な基準を参考の上でやることは下記の通り。
- 『お客様』と検討の上で決定し、最終的な合意を取る（何らかの手続きがあると思われる）
- 現場で指定されているフォーマットの要件定義書に纏める（これへのサインや捺印が手続きかも）
これでようやく要件定義がひと段落し、基本設計へとコマを進めることが出来る。
ひとまず、お疲れ様ｗ
最後に
いかがだっただろうか？
これを読んで 「全然教科書通りじゃない」 とか 「セオリーに反している」 と思った人も居るかもしれない。
しかし、実際の現場というのは教科書通りに綺麗である確率は低い！（と思う）
スキルを身に着けるために資格の勉強や個人開発も良いと思うし、どんどん挑戦するべき！
だが、実際に現場で有効なのは・・・
- 実務経験（辛い思いをした現場なら尚良し）
- 判断力
- 提案力
- 柔軟性
などではないかな～と、上流工程を18年やってきた私は思っている。
最初の方に『注意点』でも述べた通り、あくまで経験に基づく考え方なので参考程度に留めておいてもらいたい。
ただ、頭の片隅に覚えておいて決して損はしないはずだ。
今回はここまで。
長文にお付き合い頂いた方には、とにかく敬意と感謝である。
上流工程の初心者を対象としたが、現場では自信を持ってグイグイと相手に切り込んでいく勢いで、失敗を恐れずに色々な経験を積み重ねて『つよつよエンジニア』になって頂きたい。
以上
Discussion