要件定義の本質は、「概念に名前をつけること」

要件定義の本質

要件定義とは、
「画面項目を並べること」
ではない。

「機能一覧を作ること」
でもない。

個人的には、

“存在している概念に名前をつけて整理すること”

だと思っている。

例えば、
ある案件で、
fieldControl.js という名前のJSがあった。

名前だけ見ると、

「フィールドの表示制御をするJS」

に見える。

でも、
実際に中を整理していくと、
そこに入っていたのは、

・業務ごとの入力ブロック切替
・顧客区分ごとのUI変更
・条件変更時の値クリア
・自動計算項目と手入力項目の切替

だった。

つまり、
単なるフィールド制御ではない。

“業務UI制御”

だった。

ここで初めて、

「これは表示制御ではなく、
業務ごとのUIルールなんだ」

という概念が見えてくる。

さらに、
inputCheck.js という名前のJSもあった。

最初は、
必須チェックをするだけのJSに見える。

でも、
整理していくと、

・承認者の妥当性
・自己承認禁止
・金額制約
・添付チェック
・プラン整合性
・帳票明細生成
・備考文言生成
・出力条件分岐

まで入っていた。

つまり、
これは単なる入力チェックではない。

“業務ルール”

であり、

“帳票生成ルール”

でもあり、

“申請制御”

でもあった。

つまり、
このJSは、

プロセス管理を補助するための
一部機能として使われていた。

例えば、
プロセス管理側では、

「どの承認ルートへ進めるか」

という大枠を管理している。

一方で、
JavaScript側では、

• 入力内容は正しいか

• 添付は揃っているか

• 承認者は妥当か

• 自己承認になっていないか

• 帳票として成立するか

といった、

“基本機能だけでは表現しきれない業務条件”

を補完していた。

つまり、

プロセス管理とJavaScriptが
別々に存在しているのではなく、

業務ルールを成立させるために、
役割分担していた。

要件定義で大切なのは、
こうした

「混ざっているものを分離すること」

なんだと思う。

例えば、

• 承認ルート

• 業務UI制御

• 入力バリデーション

• 帳票生成

• データ補助

• 業務フロー

• プロセス管理補助

これらは、
本来別々の概念だ。

でも、
整理されていないシステムでは、
全部が混ざる。

そして、
混ざったままコード化される。

結果として、

「なんとなく動いている巨大JS」

が生まれる。

逆に、
概念が整理されると、
システムは急に理解できるようになる。

例えば、

「これは業務UI制御」

「これは承認制御」

「これは帳票生成」

「これはプロセス管理補助」

と名前が付くだけで、
責務が分離される。

つまり、
要件定義とは、

“まだ言語化されていない業務を、
人間が理解できる単位へ切り分ける作業”

なんだと思う。

そして、
その整理がされていない状態では、

コードを書いていても、
実際には、
業務そのものを読解する作業になる。

だから、
システム開発では時々、

「コードを整理していたはずなのに、
気づいたら業務整理をしていた」

ということが起きる。

次はこの記事を読みませんか？

kintoneのプロセス管理は、業務をそのまま描かない