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

1

2

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

Copyright Masayoshi Ohshima. All rights reserved.

3

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

Copyright Masayoshi Ohshima. All rights reserved.

4

ソフトウェア業界は、これら4つの問題の解決は困難だと思い込んでいるのではないだろう

か？しかし、これらの問題を克服しなければ、今後ますます拡大するソフトウェア開発の需要を賄うことは困難だろう。

Copyright Masayoshi Ohshima. All rights reserved.

5

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

ソフトウェア業界も「構造を可視化」することに、もっと取り組まなければならない。

Copyright Masayoshi Ohshima. All rights reserved.

このポンチ絵は、業務アプリケーションを想定した、「ソフトウェア・システムの全体構造」の図である。この図は、筆者が７－８年前に、金融系の大規模ＳＩプロジェクトの成果物体系（上流から下流までの全ての成果物体系：体系という意味は、成果物間の関連という意味である）を考えているときに、思いつたものがベースとなっている。（その図をご覧になりたい方は、メールにて連絡ください）

この図が示す重要なポイントは、

★あらゆる成果物において、２つの成果物間どれをとっても、「多対多の関係」がある

ということである。これに引き続いて導き出される結論は、

★ソフトウェア・システムの全体構造は、ツリー構造ではなく多次元構造である

ということである。

★機能構造を、あたかもツリー構造のように表現するが、それは、間違いである

ということにつながる。その認識に立つと、過去のあらゆるソフトウェア開発プロジェクトが、

「適切にソフトウェアの構造を管理していない」

ということに気がつくに違いない。

6

7

ソフトウェアがビジネスの中で重要な役割を持つようになっている時代である。ビジネスとソフトウェアの関係についても考えてみることにする。

ここに書いたのは、ビジネス活動の主要要素である。BMM（Business Maturity Model）も参考としたが、筆者の経験から主要と思われる要素を示した。

ビジネス活動の基本は、理念・目標から出発し、どういった顧客に何を販売したいのか、ということが基礎にある。その上に、ビジネス・プロセスや、組織、業務機能、ビジネスールール、あるいは、配置（営業・製造・物流拠点など）を考えているのが、ビジネスモデルといえよう。

それらの、要素間には、どのような関係があるのか？ それがテーマである。

Copyright Masayoshi Ohshima. All rights reserved.

ここで示しているのは、ビジネス活動の特定の二つの要素間の関係である。○をつけたところが関係のあるところだと見てほしい。

見てわかるように、ビジネス活動の要素間にも、どの二つの要素をとってみても、多対多の関係があることに気がつく。（当たり前である）

すべての要素を考慮すると、ビジネス活動も、多次元（恐らく１０次元を超える）構造の中で行われていることに気がつくのである。

事業を遂行するときに、何か問題が発生すると、経営者あるいは事業部門の上層マネジメントは、こういった多次元の構造を瞬間的にひも解いて、どこに影響が及ぶのかを判断する。それができるマネジメントは優秀であるが、すべての人がそういった能力を持っているわけではない。

このように、ビジネス活動も多次元性の中での活動だという認識を持つと、さて、ビジネスの変化のソフトウェア・システムが迅速に対応するためには、何が必要となるのであろうか？

8

それに応えるまえに、ここで、ビジネス活動の複雑さを可視化した図を示したい。

すべても要素に多対多の関係が、ここにも存在する。

こういった構造は、業種やそれぞれの企業（企業に限らず、大学や行政機関などすべてに当てはまる）

9

10

つまり、複雑さとは、

★システムの全体が多次元構造である

ということではないだろうか。

人は3次元のモノしか認識できない（イメージを持てない）。２０次元や30次元の構造物をイメージすることができないのが、人である。

そこに、大きな困難さがあるのではないだろうか。

そうであるから、業務分析やソフトウェアの設計・製造という作業が大変困難な作業になる。特に人が行う場合には。

Copyright Masayoshi Ohshima. All rights reserved.

ところで、ソフトウェア・システムの構造の中心にあるのは、どういった要素であろうか？

この図は、一般に考えられ作業を行うときに考えている構造である。

「機能」が中心にあり、その周りに画面・エンティティ（ＤＢ）などの要素がある という考え方である。

しかし、それは正しくない。

11

これが、正しい構造である。

中心は「データ項目」である。機能（業務機能もソフトウェア機能も）は、データの変換として記述される。（業務機能でさえそうである。少なくとも、ソフトウェアで実現できる業務機能の場合は）

ビジネス構造とソフトウェア構造の接点は、データ構造にある といったらわかりやすいかもしれない。ＥＡ体系を思いだせば理解できるだろう。ＢＡの一つ下位にあるのは、ＡＡではなくＤＡである。このことの意味は、「ＢＡとＡＡを繋げているのはＤＡである」ということだが、この図は、それと同じことを示している。

ソフトウェアを自動的に生成する（あるいはエンジンで動作する）ツールがあることを、ご存じの方も多いと思われる。そういったツールは、ソフトウェアの要素をリポジトリというデータベースに保持しているが、実は、ここで示したように「データ項目」を最初に登録しないと、「機能」を定義できない。機能を定義するためには、その前にデータ項目が定義されている必要がある。これも、わかってしまえば、当たり前かもしれないが、人がソフトウェアを開発する時に、そのことを十分認識してプロジェクトを行っている例は、必ずしも多くない。（勿論、この考え方を認識している例もあることを筆者は知っている）

12

ここでは、深くは触れないが、リポジトリを持つ開発ツールがある。現時点では、そういったツ－ルが、ビジネスとソフトウェアの世界の全ての要素を管理できているわけではないが、ソフトウェアの世界に限っていえば、コードを自動生成するできるツールや、設計情報を見ながら機能をエンジンが実行させるツールは、ソフトウェアの要素間の関連を保持している。

かつて（今でも主流であろう）クラス図やインタラクション図を描けるツールが存在したが、そういったツールは、残念ながら、リポジトリを持っていない、単なるお絵かきソフトである。

今求められているのは、ソフトウェア・システムの全体を統合的に管理できる、リポジトリを持った開発ツールである。（特に、長期的に維持管理していくことが求められる基幹業務システムにおいて。情報系、グループウェア、ＢＩ系などは、さらに早いスピードが重要であり必要はない。その観点ではＩｏＴのリアルタイム性に追従できる基幹業務システムが必要になる。がここでは、それはテーマではないので割愛する。）

現行の基幹業務システムのマイグレーションが今後必要になる企業は、多いと思われる。そのとき、どういうシステムを構築するのか？相変わらず、労働集約的な開発を行うのか。筆者は、「大規模システムは人が設計とコードの開発をするのは、管理限界を超えているのだから、やめておきなさい」と主張するのである。

それに、今後、人口が減る一方で、あらゆる業界でソフトウェア開発の需要が爆発的に増大することが想定されている時代である。ソフトウェア開発の生産性を劇的に向上させることは、全産業にとって極めて重要度の高いテーマになっている。

そろそろ、労働集約的な開発を続けるバカサ加減に気がついてもよい時期だろう。 13

Copyright Masayoshi Ohshima. All rights reserved. 14