モジュール分割の勧め（SIer不要論）

ここに書いたソフトウェア開発の方法論は、あくまで「全ての条件が整えば成立する」という理想論に近いものである。
世間には「現実はそんなに甘くないぞ、できるわけないだろう」と、あらゆる理想論をバカにする人も多いが、理想論は向かうべき方向性を示すものであり、いくら現実への実装が難しくても正しい方向性を見失うと、いくら努力しても状況が悪化する地獄の状況になってしまう。
正しい方向性というものを定めるためには、目的地を定めることが重要であり理想論はその目的地である。

よって、あまり感情的にならず「一つの方向性の話」と割り切って読むことをお勧めする。

一応は「論」の展開なので文体は、いつもの敬体ではなく常体で記載する。

汎用ソフトと専用ソフトの視点
SIerの開発するソフトウェア
モジュール分割視点
ソフトウェア開発レイヤー
SIerの開発はレイヤー分割が不十分
モジュール分割は他にもある
現在の業務ソフトウェアはモジュール分割が不十分
なぜモジュール分割できないのか
経産省の言っていることは正しい
現在のITベンダーは汎用モジュールを作るべき

汎用ソフトと専用ソフトの視点

ユーザー企業の業務用ソフトウェアは、ユーザー専用ソフトウェアとして、固有の業務知識を反映して開発されたソフトウェアである。

原則としてユーザー固有の業務ソフトウェアは、他のユーザーにとっては、役に立たないソフトウェアとする。

このようなソフトウェアを専用ソフトウェアと呼称する。

これに対し、Excel,WindowsやLinux, PostgreSQLとなど、汎用的に多くのユーザーの役に立つように作られたソフトウェアを汎用ソフトウェアと呼称する。

SIerの開発するソフトウェア

日本でSIerなどが開発するソフトウェアは、ほとんどが専用ソフトウェアである。

特定ユーザー企業専用にソフトウェアを開発し、そのソフトウェアは他の会社では全く役に立たない。

SIerの開発する業務ソフトウェアは通常は非常に大規模なソフトウェアになる。

特定ユーザーの業務を単独のソフトウェアでカバーし、会計処理や在庫管理や人員管理など、他の会社と基本は大きく変わらない情報処理まで、そのユーザー専用に開発する。

この件は、よく「SIerは車輪の再発明を繰り返しソフトウェア技術者を無駄に浪費している」と批判の対象になっている。

ソフトウェア技術者は不足しているので、極力「車輪の再発明」になるような「同一機能の重複開発」は避けることが望ましい。

SIerの開発は、大規模な専用ソフトウェアを多数のユーザー企業向けに、多数開発することで、本来開発する必要の無いソフトウェアを大量に開発し、日本のソフトウェア技術者を無駄に浪費している。

しかも、その浪費したソフトウェア技術者を、無理な超過労働や精神虐待などで、精神疾患など廃人に追い込み破壊し続けていることも明記しておきたい。

モジュール分割視点

マネジメント視点

ソフトウェアの開発単位は9人以下の少人数チームであるべきである。

したがって、ソフトウェアの規模は、9人以下で開発できる規模でなければならない。

それを上回る規模のソフトウェアが必要であるなら、ソフトウェアを複数のモジュールに分割するべきである。

一つのモジュールの規模は、9人以下のチームで開発できる規模とすべき。

「9人以下のチーム」という開発単位は、スクラムというソフトウェア開発プロセスモデルにおける開発人数の上限である。

ただ、ここではソフトウェア開発プロセスモデルの選択に関する議論は行わない。
たとえ、ウォーターフォールモデル開発であっても、一つのソフトウェア・モジュールの開発人数は、10人未満が望ましいことに変わりは無い。
ソフトウェア開発に限らず、9人というのは一人のマネージャーが監督できる人数の上限となる。

これを超えるとマネージャーは全てのメンバーの仕事を把握できなくなる。

10人以上の人員を管理する必要がある場合、マネージャーの下にサブマネージャーを二人配置して、マネージャーはサブマネージャー二人を管理する。
サブマネージャーの配下に、十数人の人員を9人以下の二つのチームに分割して配置する。

例えば、サブマネージャーAの配下に6人、サブマネージャーBの配下に4人という具体的に配置して、マネージャーはサブマネージャー二人を管理する。

この理屈は、ソフトウェア開発に限らず、組織管理の基本的な考え方である。

アーキテクト視点

モジュール分割を9人以下のチームで開発できるようにする、もう一つの理由は、一人のアーキテクトがそのソフトウェアの全貌を把握できる限界を超えないためでもある。

アーキテクトとは、ソフトウェア開発の技術面のリーダーの役割で、開発中のソフトウェアの技術的仕様的な整合性に責任を持つ設計構造の管理者である。

スクラム開発では設計リーダーをプロダクトオーナーと呼び、最近の開発では製品企画と設計のリーダーをプロダクトマネージャーと呼ぶこともある。
それぞれの背景思想と役割は、少し異なるが大雑把には同じようなものである。

一人の管理者の認識範囲を超えてはいけない

マネジメントの視点でも、アーキテクトの視点でも、単位ソフトウェアの開発規模は、そのソフトウェアを開発しているリーダーの認識力の限界を超えないように、モジュールを分割すべきなのである。

その認識力の上限の目安が「9人以下で開発できるソフトウェア・モジュール」となる。

大規模なソフトウェア開発は、モジュール分割の視点からみて、その企画と設計が間違っていると言える。ソフトウェアの規模が大きくなるなら、モジュール分割が不十分だからだ。
一つ一つのモジュールが適度に小さくなるまで、モジュールを分割すべきなのだ。

後で解説するがモジュール分割が適切に行えない責任の一部は業務側ユーザーにもある。

ソフトウェア開発レイヤー

昔からソフトウェアのモジュール分割において、利用されてきたモジュール分割の概念に「レイヤー」という考え方がある。
この考え方は、TCP/IPとなどネットワークプロトコルの役割分割に使用されて以降、ソフトウェア全体のモジュール分割概念に今でも利用されている。

レイヤー概念を、高度に抽象化して説明すると、以下のように説明できる。

レイヤーとは「階層」という意味の言葉で、その構成は高いビルに似ている。

ビルには1階から2階,3階,4階… といくつもの階層がある。

この一つの階層が、一つのソフトウェア・モジュールになっていると考える。

上の階層は、一段下の階層に従属する。従属とは「仕様に従う」という意味になる。

2階のソフトウェアは、1階のソフトウェアの定めた仕様に従わなければならない。

3階は2階に、4階は3階に従属する関係にある。

通常、低層階は機械に近い機能を提供し、高層階は人間に近い機能を提供する。

ソフトウェアで最も低層レイヤー(1階)にあるのは、OSである。WindowsやLinux,MacOSがそれにあたる。

2階にあるのが、PostgreSQLやOracleと言ったミドルウェアになる。

2階ではExcelのようなユーザーが直接使用するアプリケーションも稼働できる。

3階でPostgreSQLやOracleを利用して稼働するのが、多くの業務用ソフトウェアである。

このようにソフトウェアは、レイヤーに分けてモジュール分割する事で、一つ一つのソフトウェアを可能な限り単純に作れるようになる。

また、通常は低層レイヤーのソフトウェアは、汎用ソフトウェアとして開発され、高層レイヤーほど専用ソフトウェアとして開発される。

SIerの開発するソフトウェアは、最も高層レイヤーのソフトウェアとして開発されている。

補足として、純粋に高度な技術で開発されているソフトウェアは低層レイヤーのソフトウェアである。

高層レイヤーのソフトウェアは、低層で開発された高度なソフトウェアを呼び出してユーザーに使いやすく提供するのが、その役割と言える。

この方が、高層の専用ソフトウェアの開発コストを節約できるので、望ましい。

高度な技術製品を、ユーザー毎にいちいち開発していたら、膨大な開発コストに膨れ上がるだろう。

SIerの開発はレイヤー分割が不十分

記事の前で「SIerの開発は、大規模な専用ソフトウェアを多数のユーザー企業向けに、多数開発することで、本来開発する必要の無いソフトウェアを大量に開発し、日本のソフトウェア技術者を無駄に浪費している」と説明したが、ソフトウェアのレイヤー分割の視点で見ると、どこの会社でも同じような処理をする会計処理や在庫管理や人員管理などのソフトウェアを、少し内容が違うだけで、個々のユーザー企業毎に開発している。

個々の企業の業務システムで、在庫管理や予算管理や資産管理・受注発注管理など基本的な処理はほとんど変わらない情報処理を、DB設計のレベルから作っている。銀行業務や証券取引など会社毎に別々の基幹ソフトウェアを作る必要があるのだろうか。

どこの会社でも基本は変わらない管理業務なら、その管理業務を汎用ソフトウェア・モジュールにして、業務システム開発時に組み込めば良い。細かい業務手順の違いは、汎用ソフトウェア・モジュールの仕様に合わせないと、無駄な車輪の再発明は無くならない。

もし、車輪の再発明の無駄をなくすことを望むのなら、SIerが開発しているソフトウェアは、もっとレイヤー・モジュールを細かく分割すべきである。

そして、低層レイヤーと高層レイヤーに分割して、低層レイヤーのソフトウェアは汎用ソフトウェアにして、最も高層レイヤーのソフトウェアだけを、ユーザー専用ソフトウェアとして開発すべきである。

こうすることで、「車輪の再発明」はほとんどなくすることができ、膨大なソフトウェア・エンジニアの浪費と破壊を抑制できる。

モジュール分割は他にもある

レイヤーによる階層的なモジュール分割以外にも、様々なモジュール分割の方法がある。

昔から使用されているのは、ソフトウェアの部品として汎用的なソフトウェアをまとめた「ライブラリ」というソフトウェア部品群である。

このライブラリにGUIなど画面要素が加わったものが「コンポーネント」という。画面表示部分があるだけでライブラリの一種である。

ソフトウェア開発全体の枠組みをライブラリと一緒に提供するものが「フレームワーク」である。

他にDBMSに多いが、常駐するソフトウェアでアプリケーションと通信しながら、情報処理の一部分を担うソフトウェアを「ミドルウェア」と呼ぶ、DBMS以外にはWebサーバーやCMSなどがある。

Web-APIとしてミドルウェアを別のサーバーPCやクラウド上に配置する「マイクロサービス」というモジュールもある。

このように現代のソフトウェア開発は、多数の汎用ソフトウェア部品を集めてきて、要素技術を組み立てて開発されるものが多数派となっている。

モジュール分割それ自体は、既に導入されて長い年月が経っている。

ユーザーが知らないだけである。

現在の業務ソフトウェアはモジュール分割が不十分

以上の説明のようにモジュール分割それ自体は、一般的な技術である。

しかし、SIerで開発されるようなユーザー専用ソフトウェアは、充分にモジュール分割されていない。

本来、開発する必要の無いソフトウェアを「車輪の再発明」で大量に開発しているのが現状だ。

もし、適切に業務で使用するソフトウェアをソフトウェア・モジュールとして分割して、汎用ソフトウェアとして市場提供されていれば、ユーザー企業は自社専用ソフトウェアを開発するとき、販売されている汎用ソフトウェア・モジュールを買ってきて、組み立てるだけで、自社専用ソフトウェアを開発することができるようになる。

そのソフトウェアの複雑さにもよるが、いちいちSIerに開発を発注する必要も無くなるかも知れない。

なぜモジュール分割できないのか

モジュール分割ができない理由として、ユーザー業務の標準化ができていない、ユーザーごとの固有の要求が多く専用ソフトウェアを開発せざる得ないという理由がある。

また、ユーザー業界全体で業務手順の標準化の努力が不十分なので、少し違う業務手順に合わせる必要がある。

ユーザー側が「システムに業務を合わせる」事を拒絶するため、「業務にシステムを合わせる」しかなくなる。

「業務にシステムを合わせる」からソフトウェアを、汎用ソフトウェアにすることができなくなる。モジュール分割を適切な規模になるまで行えないのも、これが原因である。

結果として、本来必要の無いソフトウェアを大量に開発しなければならなくなり、ソフトウェア開発コストが膨らみ、開発に必要な人員も膨らみ、SIerのような大規模開発業者に発注するしかなくなってしまう。

はっきり言ってユーザー企業の自業自得になっているのが、現実である。

経産省の言っていることは正しい

DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～の以下のPDF資料では、「DXシナリオ」としてITベンダー側に次のような改革を促している。

「（ITベンダーは）受託型から、AI、アジャイル、マイクロサービス等の最先端技術を駆使したクラウドベースのアプリケーション提供型ビジネス・モデルに転換」

DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～ (38ページ参照)

「マイクロサービス等」の示す意味は、これまで説明してきた「汎用ソフトウェア・モジュール」の提供を意味すると考えられる。
業務のコア部分はユーザー企業が内製し、その内製に使用する「マイクロサービス等」の「汎用ソフトウェア・モジュール」をITベンダーが提供することで、ユーザー企業の内製を容易にすることを想定していると思われる。

経産省がDXレポートで、以前からユーザー企業に対して、ソフトウェアの内製化を勧めているのは、背景にこれまで説明したような全社会的な非効率があるからである。

「車輪の再発明」による無駄の原因を作っているのは、SIerの顧客であるユーザー企業自身である。

ユーザー企業が自分で、汎用ソフトウェア開発の道を閉ざし、専用ソフトウェアを開発させて、無駄に開発コストを膨らませて、ソフトウェア技術者を浪費して、技術者の人手不足を悪化させている。業務ソフトウェアの価格高騰を、ユーザー企業が自ら作り出しているに等しい。