本当は戦争の歌らしいです
こんにちは。
グーグルで「業務システム入門」で検索すると、前回の記事がTOPに表示されていました。
他にも参考になるサイトはいっぱいあるのですが。（＾＿＾；）
謙虚に頑張ります。
業務システムに必要な知識
今日は業務システムに必要なことについて考えていきましょう。
開発にはザックリ分けて２つの知識が必要になります。
- 業務内容に関する知識
- プログラミングやデータベースに関する知識
システム開発を外注する際、この２つの知識を共有することが非常に大切になります。
依頼者側は業務に関する知識はある程度持っていると考えられます（システム化できているかは置いておいて…）。しかし、プログラミングに関する知識は持ち合わせていないことが多いです。
逆に、開発受注側はプログラムの知識は持っていても、業務の内容が把握できていないことが多いでしょう。似たようなシステムを作っていた事があっても、会社ごとにやり方は違っているものです。
実はこの知識の差は業務システム開発の落とし穴になりえます。
完成したシステムを、いざ使ってみたら…。
「なんかここ使いづらいな～。」
「これなら今までの方が早いよ！」
「ここはこうして欲しいと言ったのに。。。」
せっかく、お金を払ったのにこれでは悲しいですよね。
上流工程
そのため、いきなりプログラムをする前に準備が必要となります。
この「準備」がいわゆる「上流工程」になります。
分かりやすく言うと、家を建てる時の設計士が「上流工程」、実際に建てる大工さんが「下流工程」だと思ってもらって良いです。
依頼者側と相談しながら、業務の事を把握し設計書を作る段階まで落とし込んでいく。
これが上流工程の作業の一つです。
「図」という共通言語
では具体的に、依頼者と開発者でどうやって知識の共有を行うのでしょう？
答えは、両者が分かるように「図」を使います。
モデリングとも言います。
業務の漠然とした作業内容を、ルールに従って分割し、流れを作って、フローチャートのような図を作っていきます。
さらに、それをデータベースに着目した図にしたり、システムの機能に関する流れを図にしたりしていきます。
大事なのは、
「プログラムやデータベースの知識が（あんまり）なくてもわかる。」
「業務の事を（そんなに）知らなくてもわかる。」
そういう「図」を共通言語にして知識を共有し、同じような完成形のイメージを目指していきます。
具体的にどんな図を使うのかは次回以降、紹介していこうと思います。
おわりに
涼しくなってきました。仕事に関する本を貪るように読んでいます。
図書館って凄いんですよ！
読書の秋も良いですね＾＾。集中できます。
それでは。
聖。