システムとは何か？ ― 抽象度とMECEで理解する“システム思考”の基礎

前回は”システムズエンジニアリングの適用範囲と導入条件の解説、SEは答えではなく方法論”と題してNASA SE ハンドブックの前書きとイントロダクション（導入部）の解説をしました。

前書きとイントロダクションの重要ポイントを復習すると以下の３点になります。

システムズエンジニアリングを活用するための大切な前提が書かれているので、もし興味が出たら記事を覗いてみて下さい。

今回は、NASA SE ハンドブックの本章の解説の前に”システムとはなにか？”について詳しく解説して行きます。

システムという言葉は、私たちの普段の生活でも頻繁に使われる言葉ですが、意外と統一的な理解がされていない言葉だと思います。特に日本のマスコミだと、IT関連の文脈で使われことがほとんどな気がします。

そんな曖昧な言葉であるシステムを、今回の内容でキッチリと解説して行きます。

このシステムという言葉の意味、概念を掴むと、これから学んでいくSEの根幹になることは勿論のこと普段の生活でも非常に役に立つ概念なので楽しみにして下さい。

一応は、本連載の第０回にあたる”システムズエンジニアリングのすゝめ”で軽く、表面的なシステムの概念を解説をしました。ここでは一部の内容は重複しますが、丁寧に確実に理解できるように進めて行きます。

では、SEの根幹となる”システム”について解説を始めて行きましょう。

システムとは?

まずは辞書的な定義から始めて行きましょう。

SEにおける学会的な組織のINCOSEから言葉を借りてきます。
※INCOSEは国際システムズエンジニアリング協議会、International Council on Systems Engineeringの略）

抽象的すぎてわかるような、わからないようなモヤっとした気持ちにさせられます。

次に、この連載のベースになっているNASA システムズエンジニアリング　ハンドブックから言葉を借りてきます。

これもINCOSE同様にわかるような、わからないような空中戦の話のように聞こえますね。

この２つの定義からシステムにという言葉に対して以下の３点が理解できます。

どうやらこの３つのポイントを抑えたモノをシステムと定義していると考えて良さそうです。

ポイントを踏まえてJCOSEでのシステムの定義を見て行きましょう。
※JCOSEは、INCOSEの日本支部のこと

JCOSEでの定義では、かなり具体的な内容に変わってきました。

ここまでのことを筆者流に要約すると次のようになります。

理解促進のために定義に基いたシステムを図示化してみます。

どうでしょうか？システムについて少しは理解の助けになったでしょうか？

ここまでの内容で理解できるように本来のシステムという言葉は日本のマスコミがよく使うIT関連に特化した言葉ではなく汎用性のある言葉だということがわかると思います（マインドセットして非常に重要）。

少なくとも複数の要素を持つモノ事は全てシステムと考えられそうです。

定義の話だけを進めても、話の空中戦だけが進んでしまうので、次に具体例をシステムとして考えて頭に概念を植え込んで行きましょう。

実体のある具体例をシステムとして考える

具体例として身近かつ私の専門分野の自動車で考えて行きましょう。

自動車の原則的な目的は、以下のようになると思います。

他にも安全（衝突性能やITデバイスによる予防）、快適（エアコンや照明など）、便利（カーナビなどの運転支援）など色々な目的もあるとは思いますが、ここではシステムの理解のために原則論で考えて行きます。

理解促進のために図解で進めて行きます。

実際に自動車の構成要素を考えて行きましょう。いきなりエンジンとかサスペンションなどの具体的な部品を考えるとわからなくなるので大雑把に考えて行きましょう。

※図では単純化しているので極シンプルにしています。

各３つのシステムは単独では自動車になりえません。各要素が相互作用して自動車になります。実体としての自動車も各要素は単独で存在しておらず、各要素が相互作用として様々な方法で物理的に接続されています。

これでシステムの概念の図解と同じになりました。

次にシステムの定義と照らしわせて見ましょう。

つまりで自動車はシステムであると考えることができます。

どうでしょうか？自動車をシステムとして考える実感や感覚が湧いてきたでしょうか？

さらに私の専門分野であるパワートレインを展開していきましょう。

※実物はもっと複雑、相互作用は入り組んでおり、他にも要素として電装系と存在します。

システムとして捉えたことによって自動車という全体のシステムに対して、エンジンなどの”各要素がどのような役割を果たしているのか”が理解しやすくなったと思います。

自動車システムの要素、パワートレインをさらに細かく分けたことにより、自動車への理解が少しは容易になったと感じませんか？

これが物事をシステムとして見る大きなメリットの一つで、複雑な物事を理解できる要素に分けて理解する、理解した要素を統合することによって複雑な物事を正確に理解することが容易になります。

次に自動車システムの見方を少し変えてパワートレインをだけを抜き出します。

図からわかるようにパワートレイン自体も自動車システムと同じように目的を持ちながら、相互作用をする複数の要素で構成されています。

つまり自動車システムの要素であるパワートレインもシステムとして考えることができます。このような時にパワートレインは自動車システムのサブシステムと呼んだりします。

ここでは図解をしませんがエンジンも要素で分解すると、エンジン自体もシステムと考えられるので、この時にエンジンは自動車システムのサブサブシステムと呼ばれます。
※エンジンを細かくするとバルブ関連の動弁系システム、ピストン-クランクの往復運動系、冷却系とかいろいろある

つまり要素を細かく展開するほどシステムが出てきて、サブサブ・・・システムと呼ばれることになります。

ここで自動車システムをサブシステムという概念を使って書き直します。

図からわかるようにシステムは小さなシステムの集合体と考えることができるのでシステム・オブ・システムズ（System of systems)と呼ばれたりします。日本語で表すと要素の入れ子状態と考えるとわかりやすいでしょうか。

この考え方からSEでは複数形でシステムズエンジニアリングと呼ばれる所以でもあります。

システムとはなにか？システムとして物事を捉える概念は理解できたでしょうか？

実際の業務ではシステム展開を分割不能な単位、構成部品レベル（ボルトとかバネ）まで落とし込みますが、ここでは理解のための図解なのでここまでにしておきます。

次は理解を深めるために実体物ではなく、実体物がない組織やサービスを例に見て行きましょう。

実体がない具体例でシステムを考える

ここでは、大きく出て日本政府という組織をシステムとして考えて行きます。

日本政府の目的は、いろいろあるかと思いますが憲法から持ってきましょう。

他にも思うことがある方もいらっしゃると思いますが憲法上は上記のように規定されています。

まずは政治経済の教科書的な内容に従って立法、司法、行政に分解します。

細かい言い回しは異論があるかと思いますが、基本概念は皆さんと合意が取れると思います。

既にこの時点でシステムとして定義を満たしていますね。

折角なので行政システムを展開して行きます。

実体や解釈の違いはあれど、基本的に合意できる内容になっているはずです。一部を書き出しただけでも相当に複雑なシステムになっていますね（実際の省庁は１府１２省庁もある、図は１府３省庁だけ）。

日本政府の行政をシステムとして見ると、内閣と財務省が強大な力を持っていることがよくわかります。内閣システムと財務システムだけが他の行政システムへ指示、予算の分配という一方通行に近い相互作用を持っていることがわかります。

なので、特に内閣システムの責任者の総理大臣、財務システムの大臣が日本政府の目的から大きく逸れたことを行うと日本政府システムは目的を果たすことが全くできないでので、皆さんもしっかり選挙に行きましょう。
※たまたま、執筆時点の日付、2025年２月初頭は衆議院解散総選挙の真っ只中。

話が逸れました。

ここまでの具体例で実体物のある自動車、大きな組織である日本政府もシステムとして捉えることが可能なことがわかると思います。

最後に無形のサービスを考えて行きましょう。

私はピザが好きなので、ピザの宅配デリバリーサービスをシステムとして考えて行きます。

この目的も異論はあるかと思いますが、原則的には合意できるはずです。

システムとして展開していきます。

次に相互作用を考えます。今回は相互作用の内容も考えてみます。

イメージは湧きますか？既に立派なシステムですね。相互作用の中身を明確にするとより分かりやすくなりますね。

配送システムを展開していきます。

相互作用の内容を考えることによって各システムの関係性がより分かりやすくなったと思います。本来は、受注システムも生産システムも配送システムと同様に展開し、相互作用を記載すると基本的に水平方向のシステムで相互作用し理解がさらに容易ですが図の簡略化をしています（見易さとスペースのバランス）。

特に相互作用も情報と実体物のピザで色を変えることによって、情報、物の流れが掴みやすくなったと思います。

このように相互作用で流れる情報や物体自体（受注情報やピザとか）のことをフローと呼び、情報や物体などの形式をインターフェースと呼びます。
※flowの日本語訳は流れ、interfaceの日本語訳は合わせ目、界面、接合面とか

このフローの内容とインターフェースが合致してないとシステム間で正しく相互作用することができなくなるので、非常に重要な概念なので覚えて下さい。

さらにここでのポイントはシステムの中身が、ここまでで紹介した自動車システム、日本政府システムと違って物体や組織に限定されないことがポイントです。

INCOSE、NASA、JCOSEから導き出した筆者流のシステムの定義を再び確認します。

まさに宅配ピザのデリバリーサービスの各要素は、物や組織だけでなく目的達成に必要な全てを含んでいました。

ここまで自動車、日本政府、宅配ピザのデリバリーサービスのモノ・組織、サービスを具体例としてシステムとして考えてきました。

つまりシステムとは、マスコミが言うようなIT関連に特化したモノではなく、相当に汎用性が高い言葉だということが理解できると思います。

基本的に複数の要素から構成されていれば、なんでもシステムと捉えるとことができます。

さらに具体例で解説した通りシステムとして捉えると複雑なモノ・コトでも非常に理解しやすく整理できることがわかると思いますのでオススメの考え方です。

システムとして捉える考え方のコツ

ここまではシステムとはなにか？システムとして考えることの有用性を解説してきました。

折角なので、システムとして考えるコツのようなものを紹介して行きます。

システムの上下階層は抽象度が重要

見出しを見てもなんのことか理解しにくいと思うので順を追って解説して行きましょう。
※抽象度の定義はわかりにくいので省く

まず具体例で解説した日本政府の図を思い出しましょう。システムの展開の理解に特化するために各システムの目的、相互作用は取り除きます。
※もっとも多くの日本人が共通に理解しているのは日本政府のはずなので筆者専門の自動車は封印

ここでは上下方向だけに注目したいので立法システム、司法システムは取り除きます。

そうすると上下方向に特化して見えてきますね。ちなみに上下方向のことを階層と言います。

このときに階層別での言葉の意味を考えて抽象、具体性を考えて行きます。
※内閣システムはわかりにくいのので一次、退場して頂きます。

階層のトップの日本政府だと含まれることが多すぎて人によって解釈やイメージが統一できませんが、図の最下層レベルだと”どのジャンルの実務を行うか”については理解可能で、多くの人で解釈は別れないレベルになると思います。
※どんな実務かはまだわからない。

これで階層によって言葉の抽象・具体感の変化がわかると思います。

この言葉の意味の抽象・具体感のレベルを抽象度と呼びます。学者さんに怒られそうな定義ですが、ここではシステムを考えるのに使うことに特化するので良しとします（別記事で解説するかもしれません）。

折角、なので具体方向にもう少し掘り下げて行きましょう。私はミリタリー好きなので防衛システム、つまり防衛省の一部を掘り下げます。
※どの国も防衛組織は階層が非常にわかりやすいので採用。

だんだんと具体化されて図の最下層レベルでは皆さんの多くが知っているだろう各自衛隊が出てきました。各自衛隊も多くの人が日本の陸・海・空を防衛する組織であることに異論がある人はほとんどいないはずです。
※幕僚監部は日本独特の言い回しでわかりにくいのですが、運営・維持・管理・戦略・大きな作戦などを担当しています。誤解があるかも知れませんが軍政部＋司令部＋参謀部のような感じです。

さらに掘っていきましょう。

さらに下の階層に行くにつれて具体的になっていることがよくわかると思います。聞きなれない言葉もあるかと思いますが防衛エリア・担当業務内容や範囲でどんどん具体的になっています。
※師団までは補給や広報・人事などの後方業務を含めた広い業務が実行できる、師団未満は防衛業務のみに特化。

どうでしょうか？抽象度、階層構造が理解できたでしょうか？

物事をシステムとして考える時に階層構造を無視して下記のような展開をすると意味がわからなくなります。

上下方向の階層構造を大幅に間違えれば防衛省の直下が陸上自衛隊隊員の意味になり意味がわからなくなります。左右方向の階層構造も無視してしまうと、隊員、護衛艦、航空方面隊が横並びになり意味がわからなくなりますね。
※大枠の意味では自衛隊員が、防衛省の所属の特別公務員なので防衛省の構成メンバーであることは間違いではないが、防衛省直下ではない。

つまり物事をシステムとして考える時は上下方向の階層、つまり抽象度のコントロールと左右方向の抽象度を揃えることが重要になります。

今回は防衛省・自衛隊組織を使ったのでかなり細かく何層にも分かれた階層になっていますが、実際に階層を考える時は必要に応じた階層で良いと思います。

抽象度のコントロールのコツ

基本的に抽象度のコントロールは、練習や実施回数による部分が大きいと思いますが、私なりのコツがあるので紹介しましょう。

まずは抽象度変化させる軸を決めるのが重要です。具体例で出した防衛省、自衛隊は業務範囲、防衛エリアを軸に具体化されています。

ただし防衛省、自衛隊では軸を業務範囲・防衛エリアの2つにしましたが、一個に絞ることを推奨します。なぜなら自衛隊のような防衛組織は、論理的に作られているので2つの軸でも、綺麗に階層化できるからで、一般的な物事で複数軸で階層化するのは難しい場合が多いです。

折角なので、具体例で出した自動車、宅配ピザのデリバリーサービスも見て行きましょう。この場合は役割・機能軸で具体化されています。

2つ目のコツは、具体例のように実際に書き出して上下左右で比較することです。私には脳の理屈は、よくわかりませんが人間の脳は比較思考が得意なので、それを利用します。

例えば、自衛隊の例でわざと左右で抽象度をずらします。

なんとなく違和感を感じませんか？この違和感を利用して修正します。もし可能であれば他の人にチェックしてもらうのも有効な手です。

このよう図示化を利用して抽象度の精度を高めます（MBSEの利点でもある）。

3つ目のコツは既存の組織図・部品表・サービスのパンフレットを利用することです。

そもそも組織図・部品表は論理的に書かれているので、階層構造になっていることが多いのでヒントとして利用できます。

特に自衛隊のような防衛組織の場合は、そのまま上手く階層構造になっていることが多いです。

さらに抽象度に合わせて階層構造にする場合に困るポイントの一つが、階層構造は思い浮かぶけど、各階層の名称が思いつかないことが多々あります。

この時に組織図・部品表・サービスのパンフレットを利用すると、多くの単語が階層に分かれて書かれているのでかなり役に立ちます。

まとめると以下が抽象度のコツになります。

もし良かったら参考にして下さい。

システムの水平展開はMECEが重要

ここではシステムとして考える場合の水平展開のポイントを解説していきます。

見出しの通り、MECEにすることが大きなポイントになります。MECEといきなり言われてもわからない方が多いと思うので順に解説していきます。

まずMECEの定義です。
※MECE:Mutually Exclusive and Collectively Exhaustive

この定義もわかるようなわからないようなモヤっとする言い回しですね。筆者流に言い換えましょう。

少しはマシになったでしょうか？

システムの解説同様に、これ以上に定義を弄繰り回しても空中戦になるだけなので具体例で身体にしみ込ませていきましょう。

具体例は日本政府を使います。日本政府をMECEに分割すると上で解説したように以下のようになると思います。
※憲法に書いてあるから間違いない

立法は、名の通り法を作る、行政は法に基づいて実務、司法は法の適用をチェックするのでダブりなく、漏れがない状態になります。

どうでしょうか？感覚は掴めたでしょうか？このMECEも訓練や実行回数によるところが大きいので数をこなして慣れるのが一番だと思います。

実際に慣れるために具体例で使った自衛隊も見て行きましょう。

流石の自衛隊で領域において完璧なMECEです。ただし実運用上は陸・海・空の境界で困ることがあるので陸自、海自も航空部隊を持ってますし、空自は高射部隊、基地防衛隊の陸上戦力を持ってます（論理と現実）。

また最近だと人間の活動領域が増えて来たので陸・海・空・宇宙・サイバーに広がってますが、これも同様にMECEですね。

システムとして考える時に左右展開をMECEを無視して、ダブりやモレが発生するとあまり意味がないので注意が必要です。

実際に上記に記したようにダブり、抜け、モレによって意味のないシステムになってしまいますので左右展開はMECEになっていることに注意しましょう。

MECEのコツ

折角なので抽象度と同じようにMECEにする私的なコツをいくつか紹介しましょう。

まず第一のコツは、MECEの前提条件を決めましょう。

実はMECEは、論理学的にも前提条件の上で成り立っています。上記で紹介した具体例も前提条件に基いてMECEになっています。

上記の2つの例も前提条件があるからこそMECEに分けられるわけですね。

よってMECEの作業に入る前に前提条件を決めることがとても大切です。

さらに前提条件がMECEにとって非常に厄介で同じ対象でも、前提条件によって答えが変わります。

たとえば人の性別、男女でMECEを考えて見ましょう。
※センスティブな話題だがわかりやすいからしょうがない、特に深い意図はありません

このように前提条件しだいで答えがかなり変わってきますので前提条件の設定は必ずしておきましょう。個人的なおすすめとしてはMECEの図を作るときに必ず前提条件を書いておきましょう。

逆に仕事で上司や顧客などからMECEにしろって言われた時には必ず前提条件を聞いておきましょう。そうしないとトラブルのもとになります。

2つ目のコツは、抽象度と同じで具体例のように実際に書き出して確認することです。書き出すことによって何故か、見えてくることがあるので積極的に書き出しましょう。

また書き出すことによって他人による確認が可能になるのでオススメです。

3つ目のコツも抽象度と同じで既存の組織図・部品表・サービスのパンフレットを積極的に利用しましょう。基本的に並列に書かれていることはMECEになっていることが多いはずなので参考になります。

もし組織図・部品表などがMECEになってなくても、自分でMECEを行うときに大いに参考になるので活用しましょう。

４つめのコツは完璧にこだわり過ぎないことです。もはや精神論になってしまいますが論理学上は全てが完全にMECEになったとしても現実ではMECEにならないことがほとんどです。

なので現実的に完璧なMECEに分けられる対象は限られてくるので、そこそこMECEだと思ったら十分だと思います。
※現実的に完璧にMECEになるのは年齢や行政区分（国、県、市）など、人が厳密にルール化したモノだけ

大切なのは完璧なMECEであることではなく、MECEを実際に使うと便利であることが重要なので、自分が納得する、見せる人が納得するレベルで十分だと思います。

まとめると次のようになります。

もし良かったら参考にして下さい。

システムの展開は水平はMECE、上下階層は抽象度

ここまで抽象度とMECEの解説をしてきました。

改めてシステムとして物事を考える時の抽象度、MECEの使い方を解説すると以下のようになります。

基本的に上記の2つの乗っ取ればほとんどの物事がシステムとして捉える事が可能になります。

また抽象度のコントロール、MECEも、抽象度の検討時に上下関係だけに捉われて思考がスタック、MECEの検討時に左右関係だけに捉われた思考のスタックを防ぐ効果もあります。

例えば抽象度にせよ、MECEの場合でもサブサブシステム1-２が思い浮かばない場合は、サブサブシステム1-2以外のシステムがわかっていれば穴埋め問題のように思いつくことがあるので非常に有効です（周囲情報から導き出す）。

もし良かったら参考にして下さい。

まとめ

今回はSEのキモになるシステムの解説でボリュームが多いですがまとめて行きます。

まずシステムとは以下のように定義されました。

詳細は本分に譲って、大切なことはシステムはIT関連に特化した言葉ではなくて複数の要素から構成されていればなんでもシステムとして考えることができるのがポイントです。

このシステムとして考えるメリットは以下のようになりますね。

このことから、ますます複雑化する現代社会では必須になるスキルだと私は思っています。

次にシステムとして物事を捉えるコツは上下階層は抽象度、左右の展開はMECEで考える。

まとめは以上になります。

この物事をシステムとして考えることはSEの根幹になるので、是非とも身に付けることをおススメします。普段からニュースなどで気になったことを脳内でシステムとして考えるクセを付けると良い訓練になります（書き出すとより効果的）。

またSEに興味がない方でも、システムとして考えるスキルを身に付けると驚くくらい世の中の見え方が変わってくるので非常におススメです。

以上、システムについての解説でした。

次回は、NASA　システムズエンジニアリング　ハンドブックに戻ってシステムズエンジニアリングの基礎、検証(Verification)と妥当性確認(Validation)を解説します。

• NASA システムズエンジニアリング　ハンドブック　Rev2
  本解説のベースとなる本です。Public Domainなので無料で入手できます。

• システムズエンジアリングハンドブック　慶応義塾大学出版　監修:西村秀和
  本サイトでも頑張ってNASAのハンドブックを監修していきますが、時間が掛かるので直ぐにでも全体を学びたい方はこの本がおススメです。私も持っています。