こんにちは、杉本です。
突然ですが皆様、
「オブジェクト指向プログラミング」
(OOP: Object Oriented Programming)
ってご存じでしょうか?
そうです、あのロボットとか犬とかでよく例えられる、よく分からんアイツです。
OOPを知らない方は、是非とも以下記事をご覧いただきたく。
https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e
今回は、OOPを取り入れて業務システム開発を行うために必要な、「論理項目」についてのアレコレをご説明申し上げます。
そもそも「論理項目」とは
ここでの「論理項目」とは、「何かの事象において、原因、関与、発生し、それが記録され得る、何某かの実体か事実」とします。
といっても、これだけではワカルワケナイダロ!とても理解が難しいので、例を挙げます。
(ある日のオフィス)
Aさん: Bさんや、これやっといてくれんかの。 (依頼書Aを渡す。)
Bさん: はい、了解
Aさん: よろしくね~~~
こういう状態で先のルールを当てはめると、ざっくりこんな感じに分割できる。
(実体)
人物 > 依頼者、受領者
業務 > 業務内容 (依頼書Aに書かれている。)
書類 > 依頼書 > 依頼書A
(事実)
・ちゃんと依頼が受領されたか?
・依頼内容の業務は完了しているか? (この時点ではないけど、なんとなく想像できる。)
論理項目の思考
ここが綺麗に整理できていれば、そのオブジェクトのプログラム上の名称も、自然ときれいな物になります。
当然ですが、きちんとメモを取ることが肝要です。
論理項目の抽出は、物事を深く掘り下げて要素を抽出する思考力と集中力、忍耐力が試される作業ですので、いつでも浅いとこに戻れるように備えましょう
ここでは、先の例に使った業務依頼の流れを説明します。
Step1. まずそこで達成したいことを決める。
ここでは、「業務を依頼しそれが終了すること」が最終目的になると仮定した。
その一連の流れにおいて、その流れの主人公が得たい結果を決めるとよい。
コツは、主語は常に1つに
Step.2 処理の流れ順を決めよう
Step.3 6W3H(少なくとも5W1Hはある程度明確にすること。)を明確にしよう
Step.End 終わり
ここまで出来れば、あとはExcelなりMarkdownなりで仕様書を作成するのみだ。
もちろん物は試しで実際に、ソースコードを実装してもよい。
仕様書を展開して思想の共有を図ろう。
そもそも業務システム開発において、理想的なOOPを取り入れることは難しい
OOPは物事を出来る限り小さい単位に分割し、その集合をプログラムで扱う必要があります。
しかしながら、この作業拘れば拘るだけ徹底して分割できますが、やりすぎると却ってコードが肥大化(というより)仕様書の時点で誰も全容を把握できなくなります。
極端な例ですが、普通の業務システムにおいて、論理項目を分子だとかそのレベルまで分割するのはどう考えてもやりすぎです。
かといって余りにもアバウトすぎるのも、OOPを取り入れる意味がない。
受注情報や、発注情報を単に「取引情報」とするのは結局のところ項目内部で種類が定義されるので保守の面でいえば、OOPの意味はまるで存在しない。
※取引情報は受注情報や発注情報の上位要素(より意味の広い)項目であるといえるので、受発注を伴うシステムの場合は、それらを明確に区別するべき。
しかしながら、ある程度の開発規模になると設計者が複数名(しかも場合によっては会社ごと違う)になります。
物事のとらえ方は十人十色、分割の粒度を揃えるためには、納期や費用面、クライアントの要求のみでなく、関係者間での見解を一致させる必要があります。
恐らく複数人の開発においてOOPを取り入れる際に、一番破綻しやすい部分であると思います。
さいごに
OOPに限らず、オブジェト指向型や手続き型等の様々な手法があります。
単一の業務を自動化する場合には詳細ケースに拠りますが、大抵の場合は手続き型で事足ります。
足りなくなったら後から考えればよいのです。
但し、「足りなくなる可能性のある箇所」は把握して、ある程度想定しておきましょう。
後の自己精神が救われます。
それらは教科書なりなんなりで学べるので、ぜひ適当な本を読まれてみてください。
おわり
