はじめに
開発に携わる人には聞きなれた言葉、「業務」、「機能」、「処理」
でも、全員が同じ意味でとらえているでしょうか？
普通に使っている言葉なのに微妙にニュアンスが違っていませんか？
結局は決め事なので、ステークホルダ間で定義すればよいことですが・・
今回は、ちょっと違った視点で三つの言葉の役割を考えてみました。
業務
ユーザ（利用者）の世界に一番近い概念
現実社会のルールが適用される領域
処理
コンピュータの世界に一番近い概念
プログラムロジックのルールが適用される領域
機能
業務と処理はそれぞれ独自の世界を持っていますが・・
では、機能って何でしょう？
一番わかりやすい表現では、業務と処理をつなぐもの
現実社会とコンピュータの世界をつなぐもの
ということで、今回はこの機能について少し掘り下げてゆきたいと思います。
業務分析
実際の開発で行う業務分析は、現実社会を「データ」や「処理」といった物差しで切り取ってコンピュータの世界に投影することなので、機能という概念はここでは必要無いように思えます。
業務の特徴
現実の世界は様々な要因が絡み合って非常にカオスな世界で、常に変化し続ける特徴を持っています。
そんな複雑で、不安定な世界をそのままコンピュータの中に持ってくるのは大変です。
その点、コンピュータの世界は論理的な秩序ある世界でなければなりません。
AIの進歩でかなりカオスも取り込めるようになっていますが、それでも人間が期待する答えを毎回ぶれることなく出し続けるには正しくルールをロジックとして、プログラミングしなければなりません。
機能の役割
そんなわけで、機能の出番が来るわけです。
カオスな世界から不要な条件を間引き、実現したい業務だけを世界の一部分として切り取り、処理との間のバッファーの役割を果たす。
処理の役割の再定義
せっかく機能がカオスな世界から秩序ある世界へのバッファーとなって頑張ってくれるので、処理としてはシンプルなことだけ引き受けることを心掛け、複雑さをできるだけ排除します。
処理が単純になればそれだけ使いまわしができるようになります。
出来上がったビーフシチューを肉じゃがにするにはちょっと無理がありますが、単純に下処理した牛肉、玉ねぎだったらどっちにも使いまわしができるようになります。
単体試験もすごく単純になり、開発時間や費用の削減につながりますね。
ということで抽象化の話
機能の役割の中で
”カオスな世界から不要な条件を間引き、実現したい業務だけを世界の一部分として切り取り”
という表現がありましたが、じつはこれをIT業界の専門用語では「抽象化」と表現しています。
ここからは、いろいろな視点から抽象化の話をします。
構造化設計の抽象化
まずは基本的な構造化設計から
構造化技法での抽象化はモデル化の中で実現されていて、次のような流れで行われます。
（１）現行物理モデル
（２）現行論理モデル
（３）新論理モデル
（４）新物理モデル
ここで、（２）と（３）の論理モデルが抽象化の工程となります。
つまり、同じ人間という実体がAさん、Bさんというように個々に表現された物理モデルから
AさんもBさんも人間だ！ というようにひとくくりにして「人間」として表現するのが論理モデルです。
このことにより、分かりづらい物理モデルから余計な要素を省き理解しやすい形へ表現することで、現行の改善点、問題点が明確になります。
オブジェクト指向の抽象化
オブジェクト指向で、物理モデルに相当するのが、オブジェクト図です。
AさんオブジェクトもBさんオブジェクトもしっかり表現されます。
論理モデルに相当するのが、クラス図です。
AさんオブジェクトもBさんオブジェクトも一つの人間クラスとして表現されます。
機能は・・・
ということで、機能も抽象化という役割を担っているという話がしたかったのが今回の肝でした。
業務という物理モデルを機能で抽象化し、理解しやすい形で表現する。
という機能の役割を意識して開発してゆきましょう！
最後に
皆さんへ問いかけ
業務を「目的」、処理を「手段」と見ることもできますが、そうすると機能ってなんでしょう？
こうしてみると、システム工学って哲学だと思いませんか・・