現実世界の仕事の一部を肩代わりするのがソフトウェア

## 現実世界とソフトウェアの間にはギャップがある
「オブジェクト指向でなぜつくるのか-第2版-」の第7章で、コンピュータは現実世界の一部の仕事を肩代わりするだけであって、現実世界をすべて置き換えるものではないという説明がされていました。

つまり、現実世界とソフトウェアの間には大きなギャップがあることを示しています。よって、ソフトウェアを開発するときには現実世界とのギャップを埋めなければなりません。

今回はそのギャップを埋めるための作業が紹介されている、「オブジェクト指向でなぜつくるのか-第2版-」の第9章をまとめました。


## 記事のゴール
- 現実世界の仕事にソフトウェアを導入するときに行う、業務分析と要求定義の仕方を知る。


## コンピュータが得意なこと
コンピュータを現実世界の仕事に導入する前に、コンピュータはどんなことが得意なのか、性質を知っておく必要があります。得意でないことを任せようとして、ソフトウェア開発が困難になり、いつまでたっても完成しないことになっては本末転倒です。

コンピュータが得意な仕事は **決まり切った仕事** と **覚える仕事** です。人間はこういった仕事が苦手なので、コンピュータを利用しています。

### 決まり切った仕事
コンピュータはプログラムの命令を忠実に猛スピードで実行できます。人間のように疲労によって間違えることもありません。具体例として、従業員の給与計算や銀行預金の利息計算などが挙げられます。

### 覚える仕事
コンピュータはGB（ギガバイト）やTB（テラバイト）単位の膨大な情報量を正確に記録して、瞬時に取り出すことができます。記憶装置が故障しない限りは、人間のように忘れてしまうこともありません。


## ギャップを埋める作業
現実世界の仕事だと、同じ作業でも人によってやり方が異なっていたり、状況に応じて臨機応変な対応をしたりします。

現実世界のこういったあいまいな仕事から **決まり切った仕事** と **覚える仕事** を得意とするコンピュータに任せられる部分を抜き出さなければなりません。さらに使い勝手や実行効率、保守性、拡張のしやすさなども考慮してソフトウェアを開発しなければならないという側面もあります。

上記を踏まえると、ソフトウェア開発でプログラミングを始める前に必要な作業は次の3つです。

1. 業務分析: 現実世界の業務を整理する
2. 要求定義: コンピュータに仕事を任せる範囲を決める
3. 設計: ソフトウェアの構造を定義する

### 業務分析
現実世界の仕事が、どういった役割でどのように進めているかを整理します。またコンピュータに任せる仕事を決める際の情報源を得るために、この段階で業務上の課題を抽出します。

### 要求定義
現実世界の仕事からコンピュータに任せる仕事を定義します。このとき重要なことは、コンピュータが得意な **決まり切った仕事** と **覚える仕事** を現実世界の仕事から抜き出すことです。

### 設計
使い勝手や実行効率、保守性、拡張のしやすさなどを高い品質でつくるために、あらかじめソフトウェアの構造を定義します。


## 業務分析・要求定義・設計を円滑にするUMLのモデリング
上記3つの作業は、オブジェクト指向が登場するよりも前から行われていました。しかし、オブジェクト指向の **モデリング** の登場により、上記３つの作業を円滑に進められるようになりました。

ここでいう **モデリング** とは、UMLを使ってソフトウェアの機能や内部構造を2次元の図で表現することを指します。

**モデリング** は **業務分析** ・ **要件定義** ・ **設計** でそれぞれ成果物が違います。なぜなら、各作業で **モデリング** を行う目的が違うからです。

**各作業でモデリングを使う目的**

- 業務分析: 現実世界の様子をそのまま捉えること
- 要件定義: コンピュータの性質を考慮して、肩代わりさせる仕事の範囲を決めること
- 設計: 開発環境を考慮して、ソフトウェアの構造を決めること


## モデリングの実践例
今回はビジネスアプリケーションを例に、実際にモデリングの過程を紹介します。

### ビジネスアプリケーションとは
ビジネスアプリケーションとは、企業などのビジネス活動を支援するソフトウェアのことを指します。典型的な例として、受発注や在庫管理、会計、人事などが挙げられます。

この章では、身近な例として図書館が取り上げられています。またすべての作業を手作業で行なっているということを前提にしています。

### 業務分析
まずは現実世界で人間が行なっている仕事の様子を整理します。今回は図書館の仕事でも、一般的な貸出業務を例に取り上げます。仕事の流れをアクティビティ図を使って表現すると、以下の図のようになります。

![oop-アクティビティ.png](https://qiita-image-store.s3.amazonaws.com/0/186009/37639ab0-8151-d52f-90e0-7424b4f82f38.png)

単純な絵ではありますが、図書の貸出がどのように進むのかが一目瞭然になるため、業務の課題や改善点について議論しやすくなります。

また一般的に業務分析は仕事の担当者にヒアリングをしながら進めますが、その際アクティビティ図のような絵を書きながら進めることで、検討漏れを無くしたり、認識のずれを少なくすることができます。

さらに図を活用して議論することで、アイデアが出やすくなるとも言われています。モデリングには人間同士のコミュニケーションを送信する効果があるようです。


### 要求定義
要求定義では、業務分析で作成したアクティビティ図を見ながら、コンピュータが得意な **覚える仕事** 、 **決まり切った仕事** を見つけて、コンピュータに任せる仕事を定義します。

コンピュータに任せる範囲を決める際は、ユースケース図を使うことで簡潔に表現できます。今回は図書館の全ての仕事のうち、コンピュータに任せるべき仕事だけを表現しています。

![oop-ユースケース図.png](https://qiita-image-store.s3.amazonaws.com/0/186009/185f70a5-e7a6-5079-d8a6-7479c161c5f6.png)


第8章でも紹介されていましたが、中央の大きな長方形内に書かれている仕事が、コンピュータに任せる仕事です。

ユースケース図でコンピュータに任せる仕事が決まったら、業務分析で作成したアクティビティ図に図書システム（コンピュータ）の列（UMLではパーティションと呼ぶ）を追加し、ユースケース図の結果を反映させます。

![oop-アクティビティ2.png](https://qiita-image-store.s3.amazonaws.com/0/186009/d1f3c4a3-f52c-ea27-0090-14b59a79ecda.png)

完成したアクティビティ図を見てもわかるように、全ての仕事がコンピュータに取って代わったわけではありません。コンピュータが得意でない仕事は人間が行います。つまり、ソフトウェアは現実世界の仕事を全て置き換えられるわけではないことがわかります。

もうひとつ要求定義の段階で作成すべき重要な図がクラス図です。クラス図を使って、 **管理する情報の構造** を表現します。このようにシステムで管理する情報を構造的に表現した図を **概念モデル** と呼びます。

下図が図書システムの概念モデルです。

![クラス図.png](https://qiita-image-store.s3.amazonaws.com/0/186009/a5e7086a-1903-421b-9bbc-f2c8359253ea.png)

この図は以下を表現しています。

- 利用者の情報として氏名、生年月日、性別、住所、電話番号を管理する
- 同じタイトルの本を複数所蔵することがあるため、本の種類を図書タイトル、1冊の本を図書と読んで区別する。
- 図書には1冊ずつ図書番号を付与する。
- 図書タイトルは、小説、専門書、実用書、参考書、児童書、写真集などのジャンルを分けて管理する。
- 図書タイトルは書名、ISBNに加えて、出版社と著者の情報を管理する。
- 利用者　は複数の図書タイトルを予約することができる。
- 利用者は1回に複数の図書をまとめて借りることができる。
- まとめて借りた図書であっても、1冊ずつ返却することができる。

このように見ると文章での説明の方がわかりやすいと感じるかもしれません。

しかし、この図は図書館システムとして管理すべき情報を論理的に表現しているため、リレーショナルデータペースのスキーマを容易に設定できるはずです。

また紛らわしく見落としがちなルール、ここでいうと「図書タイトル」と「図書（物理的な1冊の本）」の違いなども図を書く過程で発見することができますし、さらに2次元の図で表現することで、イメージと内容を合わせて記憶しやすくなります。

## まとめ
- 現実世界とコンピュータの間には大きなギャップがある。
- ソフトウェアを現実世界の仕事に導入するときは、まずそのギャップを埋めなければならない。
- ギャップを埋める方法として、 **業務分析** ・ **要求定義** ・ **設計** という作業がある。
    - 業務分析では、アクティビティ図を作成するなどして、現実世界の業務を整理します。このとき、現実世界での仕事の担当者にヒアリングをしながらまとめることで検討漏れや認識のずれをなくします。
    - 要求定義では、ユースケース図を作成するなどして、コンピュータに任せる仕事の範囲を決めます。コンピュータに任せる仕事の範囲を決める際は、コンピュータが得意な「決まり切った仕事」や「覚える仕事」を考慮して決める。
    - また要求定義の時に概念モデルを作成して、管理する情報の構造を2次元の図でまとめれば、データ構造をイメージと合わせて記憶しやすくなります。

## 所感

私も仕事で業務改善を行った時があったのですが、コンピュータの性質を無視して現実世界の仕事を全て自動化しようとしてしまいました。結果的に業務改善を担当することを断念してしまったのですが、この本を読んでいればちょっとは違ったのかなと思いました。

現実世界のあいまいな仕事からコンピュータが得意とする「決まり切った仕事」と「覚える仕事」を抜き出すという軸さえしっかりと理解していれば、プログラムを書くことと同じくらいかそれ以上、上流工程の仕事が楽しそうだと思えました。