Visualize the complexity of software system, the structure of software system and business system, Not Tree structure but multi-dimensional structure ビジネスとソフトウェア・システムの全体構造を可視化する

1. この資料の目的は、一つには、ソフトウェア・システムの複雑性とは、一体、どうい
うことなのか？ということを説明することにある。また、ソフトウェア・システム（業務
アプリケーション・システム）が、業務の中で使われることから、業務とソフトウェア・
システムの関係がどうなっているのかを説明することが二つ目の狙いである。最
後に、筆者が昨年来啓蒙活動をしている、「リポジトリーを持つ開発ツール（超高
速開発ツールの典型的なタイプ）」が、なぜ重要なのか、簡単に触れている。その
詳細は、http://www.slideshare.net/MasayoshiOhshima/20141119-
0?qid=2c5dccdf-b079-4070-8b3d-7659298cb0f5&v=default&b=&from_search=2を
参照いただきたい
1

2. 2
ソフトウェア開発が困難であることは、かなり古くから語られている。これは、Ｆ．ブルックス
の「人月の神話」に記載されていることであり、今でも、それは変わらないといってよいだろう。
長年、ソフトウェア開発技術者は、この問題を当たり前だと考えているが、それ以上深い検
討をしてきたとは言えない。今でも、「ソフトウェアは見えないので、設計や開発が困難だ」と
いう発言を良く耳にする。しかし、筆者は、そこでとどまっていては、何も解決できないと考え
るのである。
Copyright Masayoshi Ohshima. All rights reserved.

3. 3
Ｆ．ブルックスは、このようなことも言っている。このことは、ソフトウェア・システムの構造を可
視化することが困難だ、ということと同じであり、複雑さと可視性が難しいと語っている。この
資料では、後ほど、ソフトウェア・システムの全体構造を可視化している。それをすることは
可能だということを示したい。
Copyright Masayoshi Ohshima. All rights reserved.

4. 4
ソフトウェア業界は、これら4つの問題の解決は困難だと思い込んでいるのではないだろう
か？しかし、これらの問題を克服しなければ、今後ますます拡大するソフトウェア開発の需
要を賄うことは困難だろう。
Copyright Masayoshi Ohshima. All rights reserved.

5. 5
他の業界を見ると、ソフトウェア業界との違いが明確になる。化学の世界、宇宙物理学の世
界、生物学の世界においては、「不可視だから困難だ」などと諦めていたら、分子、原子、光
子、素粒子、遺伝子、ＤＮＡ，紫外線、重力波などを発見することはできなかったであろう。彼
らは、見えないものを見えるようにすることに努力してきたのである。それができたから、進
歩があったといえよう。
ソフトウェア業界も「構造を可視化」することに、もっと取り組まなければならない。
Copyright Masayoshi Ohshima. All rights reserved.

6. このポンチ絵は、業務アプリケーションを想定した、「ソフトウェア・システムの全体
構造」の図である。この図は、筆者が７－８年前に、金融系の大規模ＳＩプロジェク
トの成果物体系（上流から下流までの全ての成果物体系：体系という意味は、成
果物間の関連という意味である）を考えているときに、思いつたものがベースとな
っている。（その図をご覧になりたい方は、メールにて連絡ください）
この図が示す重要なポイントは、
★あらゆる成果物において、２つの成果物間どれをとっても、「多対多の関係」が
ある
ということである。これに引き続いて導き出される結論は、
★ソフトウェア・システムの全体構造は、ツリー構造ではなく多次元構造である
ということである。
★機能構造を、あたかもツリー構造のように表現するが、それは、間違いである
ということにつながる。その認識に立つと、過去のあらゆるソフトウェア開発プロジ
ェクトが、
「適切にソフトウェアの構造を管理していない」
ということに気がつくに違いない。
6

7. 7
ソフトウェアがビジネスの中で重要な役割を持つようになっている時代である。ビジネスとソ
フトウェアの関係についても考えてみることにする。
ここに書いたのは、ビジネス活動の主要要素である。BMM（Business Maturity Model）も参
考としたが、筆者の経験から主要と思われる要素を示した。
ビジネス活動の基本は、理念・目標から出発し、どういった顧客に何を販売したいのか、と
いうことが基礎にある。その上に、ビジネス・プロセスや、組織、業務機能、ビジネスールー
ル、あるいは、配置（営業・製造・物流拠点など）を考えているのが、ビジネスモデルといえよ
う。
それらの、要素間には、どのような関係があるのか？ それがテーマである。
Copyright Masayoshi Ohshima. All rights reserved.

8. ここで示しているのは、ビジネス活動の特定の二つの要素間の関係である。○を
つけたところが関係のあるところだと見てほしい。
見てわかるように、ビジネス活動の要素間にも、どの二つの要素をとってみても、
多対多の関係があることに気がつく。（当たり前である）
すべての要素を考慮すると、ビジネス活動も、多次元（恐らく１０次元を超える）構
造の中で行われていることに気がつくのである。
事業を遂行するときに、何か問題が発生すると、経営者あるいは事業部門の上層
マネジメントは、こういった多次元の構造を瞬間的にひも解いて、どこに影響が及
ぶのかを判断する。それができるマネジメントは優秀であるが、すべての人がそう
いった能力を持っているわけではない。
このように、ビジネス活動も多次元性の中での活動だという認識を持つと、さて、ビ
ジネスの変化のソフトウェア・システムが迅速に対応するためには、何が必要とな
るのであろうか？
8

9. それに応えるまえに、ここで、ビジネス活動の複雑さを可視化した図を示したい。
すべても要素に多対多の関係が、ここにも存在する。
こういった構造は、業種やそれぞれの企業（企業に限らず、大学や行政機関など
すべてに当てはまる）
9

10. 10
つまり、複雑さとは、
★システムの全体が多次元構造である
ということではないだろうか。
人は3次元のモノしか認識できない（イメージを持てない）。２０次元や30次元の構造物をイ
メージすることができないのが、人である。
そこに、大きな困難さがあるのではないだろうか。
そうであるから、業務分析やソフトウェアの設計・製造という作業が大変困難な作業になる。
特に人が行う場合には。
Copyright Masayoshi Ohshima. All rights reserved.

11. ところで、ソフトウェア・システムの構造の中心にあるのは、どういった要素であろう
か？
この図は、一般に考えられ作業を行うときに考えている構造である。
「機能」が中心にあり、その周りに画面・エンティティ（ＤＢ）などの要素がある とい
う考え方である。
しかし、それは正しくない。
11

12. これが、正しい構造である。
中心は「データ項目」である。機能（業務機能もソフトウェア機能も）は、データの変
換として記述される。（業務機能でさえそうである。少なくとも、ソフトウェアで実現
できる業務機能の場合は）
ビジネス構造とソフトウェア構造の接点は、データ構造にある といったらわかりや
すいかもしれない。ＥＡ体系を思いだせば理解できるだろう。ＢＡの一つ下位にある
のは、ＡＡではなくＤＡである。このことの意味は、「ＢＡとＡＡを繋げているのはＤＡ
である」ということだが、この図は、それと同じことを示している。
ソフトウェアを自動的に生成する（あるいはエンジンで動作する）ツールがあること
を、ご存じの方も多いと思われる。そういったツールは、ソフトウェアの要素をリポ
ジトリというデータベースに保持しているが、実は、ここで示したように「データ項目
」を最初に登録しないと、「機能」を定義できない。機能を定義するためには、その
前にデータ項目が定義されている必要がある。これも、わかってしまえば、当たり
前かもしれないが、人がソフトウェアを開発する時に、そのことを十分認識してプロ
ジェクトを行っている例は、必ずしも多くない。（勿論、この考え方を認識している例
もあることを筆者は知っている）
12

13. ここでは、深くは触れないが、リポジトリを持つ開発ツールがある。現時点では、そ
ういったツ－ルが、ビジネスとソフトウェアの世界の全ての要素を管理できている
わけではないが、ソフトウェアの世界に限っていえば、コードを自動生成するできる
ツールや、設計情報を見ながら機能をエンジンが実行させるツールは、ソフトウェ
アの要素間の関連を保持している。
かつて（今でも主流であろう）クラス図やインタラクション図を描けるツールが存在
したが、そういったツールは、残念ながら、リポジトリを持っていない、単なるお絵
かきソフトである。
今求められているのは、ソフトウェア・システムの全体を統合的に管理できる、リポ
ジトリを持った開発ツールである。（特に、長期的に維持管理していくことが求めら
れる基幹業務システムにおいて。情報系、グループウェア、ＢＩ系などは、さらに早
いスピードが重要であり必要はない。その観点ではＩｏＴのリアルタイム性に追従で
きる基幹業務システムが必要になる。がここでは、それはテーマではないので割
愛する。）
現行の基幹業務システムのマイグレーションが今後必要になる企業は、多いと思
われる。そのとき、どういうシステムを構築するのか？相変わらず、労働集約的な
開発を行うのか。筆者は、「大規模システムは人が設計とコードの開発をするのは
、管理限界を超えているのだから、やめておきなさい」と主張するのである。
それに、今後、人口が減る一方で、あらゆる業界でソフトウェア開発の需要が爆発
的に増大することが想定されている時代である。ソフトウェア開発の生産性を劇的
に向上させることは、全産業にとって極めて重要度の高いテーマになっている。
そろそろ、労働集約的な開発を続けるバカサ加減に気がついてもよい時期だろう。
13

14. Copyright Masayoshi Ohshima. All rights reserved. 14