昨今はシステム仕様の複雑化が進み、その多くが大量のプログラムソースで構成されている印象を受けます。

そのようなシステムで、より効率的な「開発」「テスト」「保守・運用」を行うためには、システムをモジュールと呼ばれる小さな単位に区切ることが効果的です。こうした開発手法は「モジュール開発」と呼ばれます。

今回はモジュール開発のメリット・デメリット、分割手法などを解説します。

弊社GIGではモジュール開発をはじめとした、高品質なシステム開発支援を行っています。モジュール開発を含めたシステム開発に関してご支援が必要な場合は、お気軽にご相談ください。  
■実績紹介
■お問い合わせはこちら

モジュール開発とは

IT業界でいうモジュールとは、ソフトウェアを構成する部品のことを指します。プログラミングでは、一般的にこのモジュール（部品）を最小単位として開発・テストを進めることになります。

なかにはモジュール（部品）単独で動作可能なものもありますが、基本的には他のモジュールなどと組み合わせて使用します。

ただ、このモジュールという言葉は、システム開発の現場やパッケージ製品ごとに指し示す範囲が異なることもあり、ややあいまいな表現という側面も。今回は「モジュール = 最小単位の部品」と定義して、解説を進めます。

モジュール開発のメリット

モジュール開発にはどのようなメリットがあるのでしょうか？ ここからはエンジニアの目線でメリットを解説します。

メリット1. QCDを改善できる

モジュール開発を取り入れることで、QCDの改善が期待できます。QCDとは、Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字を並べたもので、システム開発においてはすべて欠かせない要素です。

【Quality（品質）の改善効果】

メインとなるプログラムを開発する前に、まずは部品となるモジュールを開発するのが一般的です。メインとなるプログラムとは、たとえば基幹システムでは「売上管理」や「仕入管理」、「在庫管理」などが該当します。それぞれが独自の仕様で動いている一方で、同じような処理や計算を行っている箇所もあります。

この同じような動きをしている箇所を別々の画面で担当者がプログラミングした場合、品質にバラつきが発生する可能性があります。

そのため、多くの画面で使用する処理や計算を極力モジュール化することで、品質にバラつきが発生することを防げるでしょう。

【Cost（コスト）の改善効果】

システム開発会社の多くは、今までの案件で使ったモジュールを他の案件にも使っています。

「他で使ったものを使いまわしているの？」と思われるかもしれませんが、他の案件でも使った経験があるからこそ、品質が担保されているともいえます。

このようにモジュールは一度開発してしまえば他のシステムにも流用可能なので、開発コストを抑える効果があるでしょう。

【Delivery（納期）の改善効果】

どの現場のシステム開発も、納期は非常にタイトです。DX推進を掲げる企業が増えてきており、加速する市場の変化にスピード感をもって柔軟に対応することが求められます。のんびり開発していては、市場に取り残されてしまうでしょう。

タイトな納期を守るためには、モジュール化できる処理はモジュール化しておき、必要な時にすぐにそのモジュールを呼び出せる状態にして時短するような工夫が不可欠です。

メリット2. 保守性が向上する

同じような動きをしている箇所を別々の画面で担当者がプログラミングする状況は、品質面だけでなく保守・運用面でも問題があります。

プログラムにバグはつきものであり、それはモジュール化しても変わりません。ただ、モジュール化しておくことで、修正箇所がモジュール内に限定されるのはひとつのメリットです。

仮にモジュール化しておらず、多くの画面で同じような処理を行っている箇所でバグが発見された場合、それらの画面すべてを確認しなければなりません。余計な工数やコストがかかることは一目瞭然でしょう。

モジュール化しておくことで、プログラムの保守性が向上することは間違いありません。

メリット3. 可読性を高められる

「可読性が高い = プログラムが読みやすい」とも言い換えられ、可読性が高ければバグが発生した際に調査がしやすくなる傾向にあります。

基幹システムでいう「売上管理」や「在庫管理」など業務の核となる部分のプログラムだと、何千、何万という行でコーディングされているケースがほとんどです。

これぐらいの量になると、モジュール化されていない場合は可読性が非常に低くなります。業界用語として、モジュール化もされておらず、処理がぐちゃぐちゃな可読性の低いソースコードのことを「スパゲッティコード」と呼ぶことも。まさに皿に盛られたスパゲッティのごとく、実行される箇所が絡み合っていることからこう名付けられました。

システム開発の現場では、多くの開発会社のエンジニアが次々に修正や追加を行います。可読性が低ければ、修正や追加にも時間がかかり、新たなバグの発生要因にもなります。可読性を高めるためにも、うまくモジュールを活用して開発を進めたいところです。

モジュール開発のデメリット

モジュール開発では、開発・導入にあたっての検討事項が多くなる傾向にあり、開発する前に工数がかかるのはデメリットです。

また、できるだけモジュール化したくなるところですが、全てをモジュール化してしまうと、逆に管理が大変です。必要だと思って作ったモジュールでも、使い道がなく埋もれてしまっては意味がありません。

さらに、モジュールをきちんと管理できていなければ、同じようなものが複数できあがる可能性もあります。これではモジュール開発のメリットがなくなってしまうだけでなく、品質の低下や工数増にもつながりかねないため、注意が必要です。

モジュールの分割手法【データの流れ編】

ここからはよりエンジニア目線が強くなりますが、モジュールの分割手法に関しても解説を進めます。

モジュール分割手法は、「データの流れ」を意識したものと、「データの構造」を意識したものに分けることができます。まずは「データの流れ」を意識したモジュール分割手法を確認します。

1. STS分割

▲出典：山梨英和大学

データの流れを「Source（源泉）」「Transform（変換）」「Sink（吸収）」に分割して、モジュールの階層構造を設計する手法のことをSTS分割と呼びます。それぞれをシンプルな表現に変えると、「入力モジュール」「処理モジュール」「出力モジュール」となります。

プログラムのなかでは、以下のようなデータの流れを意識してモジュール分割を行います。

1. 入力モジュール：画面から入力されたデータを処理する
2. 最大抽象入力点：これ以降は入力データが発生しない区切りのポイント
3. 処理モジュール：入力データを出力データに変換する
4. 最大抽象出力点：これ以前に出力データが発生しない区切りのポイント
5. 出力モジュール：画面に出力するデータを処理する

2. トランザクション分割

▲出典：山梨英和大学

対象となるデータの種類と、そのデータに関連するプログラムを一連の処理（トランザクション）単位に分割する手法のことをトランザクション分割と呼びます。

たとえば、上の図のように給与ファイルの更新処理が発生するケースでは、処理を「手当の更新」「基本給の更新」「控除の更新」といった3つのトランザクションに分けられるため、これを分割することができます。

3. 共通機能分割

▲出典：山梨英和大学

STS分割やトランザクション分割を行った後、それらに共通して含まれる機能があれば、共通機能としてひとつのモジュールにすることを共通機能分割と呼びます。

STS分割やトランザクション分割では、大きな上位モジュールを複数の小さな下位モジュールに分解するので、だんだんと下方向に枝分かれする構造（木構造）になります。

一方、共通機能分割では、基本となる共通機能は単一機能のモジュールであり、それらが集まって大きなモジュールになるので、STS分割やトランザクション分割とは逆の構造になります。

たとえば商品受注量や発注量の増減のように、「商品受注」「発注」という個別の項目では別物でも、「増減」という抽象的な部分が共通していれば、共通機能になることも多いです。

モジュールの分割手法【データの構造編】

次に「データの構造」を意識したモジュール分割手法を確認していきましょう。

1. ジャクソン法

▲出典：山梨英和大学

入力データの構造と出力データの構造の対応関係からモジュールに分割する手法は、ジャクソン法と呼ばれています。

データやそれを扱うモジュールを、「基本」「連続」「選択」「くり返し」の4つの要素を組み合わせて表現していきます。

入出力データの構造に基づいてモジュール分割を行う手法であり、先にみたデータの流れに着目する構造化設計とは異なります。

入出力データを構造化して上下関係を作った後に、入力データと出力データの構造の間に対応関係を作成。そして、その対応関係を写像と考えてモジュール化します。データ構造の上下関係がそのままモジュールの上下関係となります。

2. ワーニエ法

▲出典：山梨英和大学

入力データを中心に、データが「いつ」「どこで」「何回」使われるかを3種類の制御構造（順次／選択／くり返し）でモジュール化する手法のことをワーニエ法と呼びます。

ジャクソン法と異なり、ワーニエ法では入力データの構造のみからプログラム構造を決めます。

モジュールの独立性を評価する基準

モジュール分割を行うケースでは、モジュールの独立性にも注意しなければなりません。

モジュールの独立性が低く、他のモジュールに依存する割合が高いと、再利用性や保守性などが低下。モジュール化によるメリットを十分に得られないケースも考えられます。

モジュールの独立性を評価する基準には、モジュールの「強度」と「結合度」があります。

基準1. モジュールの強度

▲出典：山梨英和大学

モジュールの強度は、ひとつのモジュールに実装される機能同士の関連性の強さを表します。モジュールの強度が強いほど、モジュールの独立性が高くなります。

「機能的強度」を持つモジュールでは、ひとつの機能のみでモジュールが利用されているため、仮に仕様変更が生じても、他のモジュールに影響を与えません。

一方、「暗号的強度」のモジュールでは、関連性のない複数の機能をコーディングしているため、ひとつの機能を修正すると、他のモジュールにも修正を加えなければならないケースが発生する可能性があります。つまり、プログラムの保守性は低いと解釈できます。

基準2. モジュールの結合度

▲出典：山梨英和大学

モジュールの結合度は、データを受け渡す際に他のモジュールに依存している度合いを表します。こちらはモジュールの結合度が弱いほど、モジュールの独立性は高くなります。

「データ結合」のモジュールでは、必要最小限のデータのみを受け渡しているため、他のモジュールを修正しても影響がほとんどありません。

一方、「内容結合」のモジュールでは、他のモジュール内を直接参照してデータを受け渡しているため、他のモジュールを修正すると受け渡しが困難になります。つまり、保守性が低いと解釈できます。

モジュール開発を含むシステム開発を検討される際にはGIGにご相談ください

GIGでは、これまでモジュール開発を含めたシステム開発で培ってきたノウハウと知見を活かした支援のもと、高品質なシステム開発を実現してきております。

また、豊富なWebサイト制作実績が示すように、お客様と丁寧で密なコミュニケーションを重ねてきたと自負しております。

無料相談から承っていますので、モジュール開発を含めたシステム開発に関してご支援が必要な場合は、ぜひ一度お問い合わせください。

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。