レヴィが提案するシステムデザインのためのフレームワーク「システミング」について要点をまとめたガイドブックが完成しました。このページではガイドブックの前半の内容を掲載しています。全ての内容をご覧になりたい方は、ガイドブックをダウンロードしてご利用下さい。

はじめに

最近、社会の状況を表現する際にVUCA(Volatility:変動性、Uncertainty:不確実性、Complexity:複雑性、Ambiguity:曖昧性)という言葉がよく使われます。経済のグローバル化、インターネットの急速な普及、新しいテクノロジーの進歩、価値観の多様化などの要因が絡み合って、世界は予測不可能で混沌とした状況になってるということを表している言葉です。

VUCAな社会では、大企業の競争優位性が短期間のうちに揺らいで新興のスタートアップ企業にとってかわられたり、有望だと思われたマーケットがあっという間に成熟してレッドオーシャンになったり、誰も予期しなかった出来事がものすごいスピードで社会に波及して人々の生活が大きく変わったりしています。これは、必ずしも嘆かわしいことではありません。このような時代は、チャンスに溢れた時代であると言うことができます。小さい企業や個人でも、大きな価値を生み出して社会に素早く浸透させることができます。成長しきったと思われていた企業も、やり方と工夫次第でさらにビジネスを成長させることができます。

ただし「わかりやすかった時代」と同じやり方をしていては、そのチャンスを掴むことはできません。チャンスを掴むためには、変化や複雑さに強い考え方、戦略、組織などが必要なはずです。それはどのようなものでしょうか?それを考えるにあたっては、他の分野に先駆けて変化や複雑さに挑戦してきた先人達のやり方が参考になります。そのような分野の代表格として、宇宙開発やソフトウェア開発が挙げられます。私達は、それらの分野で培われてきた「変化や複雑さに対する挑み方」を、新しい時代に適応するための拡張を加えつつ、誰もが実践な可能な形に翻訳し、システミングというフレームワークを構築しました。システミングを用いることで、変化や複雑さに強い問題解決や価値創造の活動を実現することができると私達は考えています。

1. システミング

1-1. システミングとは?

システミングとは、私達(レヴィ)が提案する「システムデザインを上手く実践するためのフレームワーク」のことです。"System"に接尾辞"ing"をくっつけた造語であり「システムとして考える」「システムについて考える」「システムを実現する」など、システムをキーワードにしていろいろなことを上手くやるという意味を込めて名付けました。

フレームワークというのは、メソッド(やり方)・マインド(考え方)・プロセス(手順)などをまとめて、誰でも実行できるように整理したもののことです。システミングを使うことで誰でも同じように上手くシステムデザインを実行することができ、変化や複雑さに強い製品開発やビジネスを実現することができます。

システミングは、宇宙開発やソフトウェア開発などの分野で発展してきたシステムズエンジニアリング(システム工学)のアプローチや方法論をベースにしています。宇宙開発やソフトウェア開発の分野は、他の分野に先駆けて複雑さに挑んできました。そのような分野の中で培われてきた「複雑なものを上手くつくるための方法」がシステムズエンジニアリングです。システムズエンジニアリングは有用な視点や手段を多く提供してくれますが、多岐に渡る内容を体系的に理解して製品開発や問題解決の場で活用するには多くのトレーニングや長い実務経験が必要です。システミングは、そのような"難しいシステムズエンジニアリング"のハードルを下げ、誰でも現場で使えるというところを目指して構築しました。

1-2. システミングとシステムデザイン

前節で、システミングとは「システムデザインを上手く実践するためのフレームワーク」のことだと述べました。それでは"システムデザイン"とは何のことでしょうか?詳しくは「2. システムデザイン」にて説明しますが、ここではまず一般的なことについて先に考えてみます。

日本語で"デザイン"という言葉は物品や画面の形状、色、レイアウトなどを指す場合がありますが、広義には"設計"という言葉に相当します。設計とは一般的に、モノゴトを具現化するための様々な検討や準備、計画のことを指します。もう一つ、"システム"という言葉の方も気になってしまいますが、それは後ほど考えるので、とりあえずここではプロダクト(製品)やサービスのことを指してシステムと表現していると思って下さい。

そのように考えるとシステムデザインとは「プロダクトやサービスを具現化するために様々な検討や準備を行い、計画を立てること」と言えます。これは決して特別な活動というわけではありません。多くの企業で日々行われていることですし、設計開発などの部署で働く人だけでなく経営・営業・オペレータなど様々な立場の人が何らかの形で携わっている活動です。

このように誰もが取り組んでいるシステムデザインですが、それがいつも上手くいくとは限りません。特に対象とするプロダクトやサービスが複雑で、状況の変化が大きいとき、システムデザインはとても難しくなります。そのようなときにお役に立てるのが、システミングです。

1-3. 価値探索と複雑さ

はじめにで述べたことと重なりますが、現代の社会やビジネスをとりまく状況はVUCAと表現され、変化が激しく予測が困難です。VUCAな世界でチャンスを掴むためには、次の2つの方向性について考え、それに伴う難しさに対処しなければなりません。

方向性①:価値探索

様々な技術や機能が短期間でコモディティ化されていく中、ビジネスで成功するためには常に新しい価値の提案と提供が必要となります。また、多くの産業がサービス化され、顧客が求めるものが個別の機能や性能から、総合的な体験へと変わってきています。そのため、試行錯誤を繰り返してどのような体験が価値を持つのかを探索しながらモノづくり・コトづくりを進めなければなりません。

方向性②:複雑さ

現代社会では、あらゆるモノゴトに多数かつ多様なステークホルダが関わるようになっています。そのためたくさんの、そして様々な要望や制約に対応しなければなりません。異なる立場からの要望や制約がコンフリクトすることも多くあります。プロダクトやサービスが独立して多種多様な要求に応えるのは難しく、他のプロダクトやサービスとの連携が求められます。考慮すべき事柄がどんどん増え、プロダクトやサービスそのものも複雑化していきます。

これからのビジネスや問題解決は、この2つの方向性を両立させる必要があります。これは大きな課題でもありますが、同時に大きなチャンスでもあります。世の中の変化に対応して価値を探索し、複雑さに上手く対処することができれば、例え小さな企業や個人でも大きな価値を生み出すことができます。

VUCAな世界でチャンスを掴むための2つの方向性

システミングは、このようなチャンスを掴むために役立つことを目的として生み出されました。対象や状況が複雑で変化が大きいとき、システムデザインはとても難しくなります。「3. 問題とアプローチ」で挙げるような様々な問題が生じるからです。それらの問題に対処し、上図の右上領域におけるシステムデザインを上手く実践するためのフレームワークがシステミングなのです。

2. システムデザイン

1-2. システミングとシステムデザイン」では、システムデザインを「プロダクトやサービスを具現化するために様々な検討や準備を行い、計画を立てること」と表現しました。これは、プロダクトやサービスを着目するシステムとした場合の表現です。しかし、システムという言葉は必ずしもプロダクトやサービスのことだけを指すものではありません。後ほど示すように、事業、組織、社会、人間など様々なモノゴトをシステムとして考えることができます。対象とするモノゴトをシステムとして捉えることで、はじめてシステムデザインを考えることができます。また、「具現化するために様々な検討や準備を行い、計画を立てること」という部分も、デザインという言葉を表現するには不足があります。デザイン(設計)において重要なのは、何かを具現化することそのものではなく、具現化したものによって何らかしらの目的を達成することです。目的につながらないものを具現化したり、目的と関係ない計画を立てたりすることはデザインとは言えません。これらのことを踏まえてシステムデザインをあらためて定義すると、次のようになります。

システムデザインの定義

モノゴトをシステムとして捉えて、「目的それを実現するシステムをどうつなげるか?」を考えること。

システムデザインの概念図

システムデザインにおいてデザインの対象となるシステムのことを専門用語でSoI(System of Interest:着目するシステム)と呼びます。何をSoIとして設定するかを明示することが、システムデザインの第一歩です。

例えば、自社のビジネスで扱うプロダクトやサービスをデザインしたい場合、SoIとしてプロダクトやサービスを設定します。その場合は、上の図の「目的を実現するシステム」のところにプロダクト名やサービス名が入ります。もし、事業や組織をシステムとして捉えてデザインしたい場合は、この部分が事業システムや組織システムになります。

システミングはシステムデザインを上手く実践するためのフレームワークなので、「目的とシステムをどうつなげるか?」について分かりやすい表現方法を定めています。それが、下に示すようなビューモデルです。ビューモデルは、様々な視点から切り取ったシステムの見え方(ビュー)ビュー間の関係性について示した図です。大きく「システムを外から見るビュー」と「システムの中を見るビュー」に分けて考えることで、どのようなビューが必要かを考えやすくしています。ビューモデルについては「5. ビューモデル」で詳しく説明します。

ビューモデル

システミングでは、ビューモデルに示されたそれぞれのビューについて、関連するビューとの整合性を保ちながらモデル(ビューの中身を表現したもの)を構築していきます。全てのビューについてモデルが完成したとき、目的とシステムがつながってシステムデザインが成功したと考えます。

目的とそれを実現するシステムをいきなりつなぐことはできないので、いくつもの細かいビューに分けてシステムを捉え、ビュー同士をつなげていくことで最終的に目的からシステムまでをつなげるという考え方を表現した図がビューモデルです。ここでそれぞれのビューは、目的からシステムにたどり着くための飛び石のような役割を担っています。

3. 問題とアプローチ

システムデザインとは「目的とそれを実現するシステムをどうつなげるか?」を考えることです。このように書いてしまうと、それはとても簡単なようにも思えます。目的から出発して、その目的を実現するために必要な機能などを書き出していって、その機能を実現する方法を発案するという流れで進めば良さそうな気がします。しかし、実際にシステムデザインに取り組んでみると、コトはそれほど簡単には進まず、様々な困難に出会います。この章ではシステムデザインを難しくしている問題について整理した上で、その問題に対するシステミングのアプローチを紹介します。

3-1. システムデザインの難しさ

システムデザインを難しくしているのは、様々な「わからない」と、わからないを生み出す「複雑さ」です。まずは、様々な「わからない」について考えてみましょう。以下にシステムデザインをやってみるとよく遭遇する「わからない」を挙げてみます。

わからない①:他人の頭の中はわからない(認識ギャップ)

当然のことですが、他人が何を考えているかを正確に知ることはできません。同じシステムを対象にして議論していても、人によってシステムのイメージや詳細が異なっていて問題が起きることがよくあります。また、顧客やユーザーが本当に求めていることを正確に知ることもできません。

  • チームメンバーの間で、システムに対する認識が異なっている。
  • 顧客が本当に思っているものと、設計者が考えているものが異なっている。
  • ユーザーが使いづらいと思っているところに気づいていない。
わからない②:何がおきるかわからない(リスク)

モノゴトを事前に完全に予測することは不可能です。どんなに準備して考え抜いも「もしかしたら起こるかもしれない」といったことや「結果がどうなるかわからない」ということが必ず残ってしまいます。そのような"わからない"はリスクと呼ばれます。

  • 部品が故障してしまうかもしれない。
  • ユーザーが誤った操作をしてしまうかもしれない。
  • 競合が参入してきて、競争が激しくなるかもしれない。
わからない③:何がわかっていないかがわからない(無知)

システムに関する全ての要素や可能性を漏れなく認識して列挙することはとても難しいことです。特に、はじめてつくるシステムであったり、その領域について詳しくない人がデザインに取り組む場合は、様々なものを見落としてしまいます。この"わからない"がやっかいなのは、わかっていないことに気づくことが難しいということです。

  • 重要だけど見落としていたステークホルダが存在した。
  • DCモータの動作によって磁気センサが影響を受けることを知らなかった。
  • 思ってもみなかった使われ方をするシーンがあった。
わからない④:やってみないとわからない(曖昧さ)

システムデザインを進めていく上では「具体化してみないとわからない」や「つくってみないとわからない」という場面が数多くあります。最初は曖昧なものでも、一度それで仮決定として詳細化や具体化を進めてみると、はじめて問題点やあるべき姿に気づき、仮決定だった曖昧な箇所まで戻って修正することができます。ここまでに挙げてきた①〜③の"わからない"にも、最初はわからないけど、一度具体化することでわかるようになったり気づいたりすることが多くあります。

  • 画面のプロトタイプをつくってみたら、表示件数を絞り込む機能が必要であることがわかり、機能リストに追加した。
  • どのくらいの性能や精度が出るのかわからなかったけど、試作をつくって検証することでおおよその値が明らかになったので、その値に基づいて基本設計を修正した。
  • 使用する部品を決めることで初めて故障に関するリスクを見積もることができた。
わからない⑤:変化に対してどう対処したらよいかわからない(適応)

システムデザインに変化はつきものです。①〜④で挙げたような"わからない"が原因となって後からシステムのあるべき姿が変わったり、外部の環境が変化することで大きな影響を受けたりします。そのようなとき、どのように変化に対応すればよいのかは、決してわかりやすいものではありません。ある部分の変化が、他の部分にどのような変化をもたらすかが分からないことも多くあります。システムデザインを上手く実践するためには、変化に上手く対処する必要もあるのです。

  • 使用する予定だった部品が廃盤になってしまって異なる部品を選定したけど、その変更がシステムにどのような影響を及ぼすのかわからない。
  • 強力な競合が参入してきてシェアを奪われそうだけど、どのように事業を改善したらよいのか分からない。
  • 検証テストの結果、性能が不十分であることがわかったが、どのように設計を変更すればよいのか分からない。

システミングでは上記の①〜⑤のような「わからない」がシステムデザインを難しくすると考え、それを乗り越えるための方法を提案しています。①〜⑤はMECE(漏れがない・重複がない)になっているのではなく、複数の項目にあてはまる「わからない」があったり、いずれにも当てはまらないような"わからない"があるかもしれません。しかし、①〜⑤のような視点で考えれば、システムデザインにおける難しさの大部分をカバーすることができるはずです。

3-2. 複雑だから難しい

このような「わからない」の原因となるのが、「複雑さ」です。複雑さの程度が大きいと、わからないの程度も大きくなります。ここでは「複雑さ」について少し考えてみましょう。

モノゴトの関係性が入り組んで理解や予測が困難な状態のとき、人はそれを「複雑だ」と考えます。一般的に、モノゴトに関わる要素の数や種類が多く、それらの間に様々な相互作用があるときに複雑さは大きくなります。たとえ個々の要素のそれぞれの振る舞いについては簡単に理解できる場合でも、要素がたくさん集まって互いに影響を及ぼしあうと、その全体の振る舞いを予測することがとても難しくなります。

例えば、ロケットや人工衛星などの宇宙システムは複雑なものの代表的な例と言えます。百万点にもおよぶ多数の部品と、数十万〜数百万行の大規模なソースコードからなるソフトウェアがお互いに影響を及ぼしながら様々な機能を実現しています。そのため、宇宙システムの全体はとても複雑になり、その設計に取り組む際には「3-1. システムデザインの難しさ」で取り上げた様々な「わからない」が大きな問題となります。

現代社会では、宇宙システムのような特別なシステムだけでなく、身の回りの様々なシステムが複雑になっています。プロダクトやサービスについて考えたとき、次のような場合に複雑さが大きくなります。

プロダクトやサービスとしてのシステムが複雑になる場合

  • 関係者が多い。いろいろな人がいろいろな要望をいう。
  • 要素が多い。例)部品数、コード行数、機能数が多い。
  • 解決すべき問題や課題が多く、それらの間に関連性がある。
  • 様々な規制や制約を受ける。
  • 多くの人が使う。いろいろな使い方がある。
  • 既存の仕組みや製品・サービスを組み合わせる。
  • もともと複雑なものに手を加える。
  • いろんな立場の人、考え方の人、能力の人が使うとき

3-3. 基本的なアプローチ

システムデザインを難しくする様々な「わからない」と、それを生み出す「複雑さ」に対処するためには何が必要でしょうか?システミングでは、それらの問題に対する基本的なアプローチとして「システム思考」と「システミング三原則」を挙げています。

3-3-1. システム思考

システム思考とは、モノゴトをシステムとして捉えることで複雑な状況や問題を理解するという考え方です。システムとは、次の3つの性質を備えているものと定義することができます。

システムが備えている性質

このように定義すると、スマートフォン・飛行機・Webサービス・家電製品などの一般的な機能システムだけでなく、社会・街・企業・生物など様々なモノゴトをシステムとして考えることができます

そしてモノゴトをシステムとして捉えると、要素・相互作用・入出力・階層性などの概念を使ってシステムを理解したり、システムモデルという図を使ってシステムを分かりやすく表現したりすることができます。このような理解や表現の方法は、他の領域に先駆けて複雑さに挑んできた航空・宇宙・ソフトウェアなどの分野の中で発展してきたものです。

システム思考については別冊の「システムとして考える〜システム思考&システムモデル入門〜」においてさらに詳しく説明しています。そちらもあわせてお読み下さい。

3-3-2. システミング三原則

システミング三原則は、システムデザインに取り組む際に常に意識するべき重要なことを3つにまとめたものです。システム思考でモノゴトを考え、システミング三原則を意識しながら設計を進めることが、システムデザインを上手く実践するための前提となります。

原則1:分けて考える

人は複雑なシステムの全体をそのまま理解したり表現したりすることができません。そのため、システムのあり方について考えたり、他人と共有したりする場合には、システムを様々な側面に分けて表現することが必要です。例えば「システムが持つべき機能について考える」「システムの物理的な構成について考える」「誰がどのようにシステムを使うのかを考える」などのような側面に分けて考えることで、はじめてシステムを表現して理解したり共有したりすることができます。システムを様々な側面に分けて考える方法については、「4. ビューとモデル」で扱います。

原則2:整合性を保つ

原則1で述べたように複雑なシステムは様々な側面に分けて考えなければ理解や表現ができません。しかし、分けただけでは問題が出てきてしまいます。分けて考えた様々な側面の間に整合性がないと、システムが全体として目的を達成することができなくなってしまいます。ここで「整合性がある」とは、きちんと対応関係があって矛盾していないという意味です。例えば、「システムの機能」と「システムの物理構成」という2つの側面の間には「その物理構成が機能を実現できるものになっているか?」などの点において整合性がとれていないとなりません。温度を計測するという機能が求められているのに、温度センサに相当する物理デバイスを持っていなければ機能と物理構成の間の整合性がとれなくなってしまいます。整合性については「5. ビューモデル」で扱います。

原則3:わからないを意識する

問題に対処するためには、まずはその問題を認識しなければなりません。「3-1. システムデザインの難しさ」にまとめたシステムデザインの難しさとしての「わからない」は一見当たり前のものばかりですが、設計に臨む際にはつい忘れてしまうことが多いです。システミングでは①〜⑤のようにタイプ分けすることで意識したり議論したりしやすくしています。①〜⑤のような様々な「わからない」があるということを念頭において、常に気にしながら設計を進めることが複雑なシステムデザインを上手く実践するための必須条件となります。

3-3-3. 問題とアプローチの対応

ここでは、システム思考とシステミング三原則がどのようにして「5つのわからない」に対応するのかを簡単に整理しておきます。システミングの具体的な実践方法は次章以降で紹介するので、ここではだいたいの対応関係を理解できれば十分です。

わからない①
他人の頭の中はわからない(認識ギャップ)
  • システム思考:システムの言葉、システムモデルなどで表現することで共有できる
  • 原則1:分けて表現することで理解できる、共有できる
わからない②
何がおきるかわからない(リスク)
  • システム思考:システムとして表現することで要素間の相互作用によって生じるリスクが考えやすくなる
  • 原則1:分けて考えることでリスクの洗い出しと発生確率の見積もりができるようになる
わからない③
何がわかっていないかがわからない(無知)
  • システム思考:システムモデルで過去の知見を活かす
  • 原則3:わからないことがあるかもしれないということを意識することで発見しやすくなる
わからない④
やってみないとわからない(曖昧さ)
  • 原則3:最初から完璧を目指すのではなく、曖昧なまま一度進んでもよいと考えることができる
  • 原則2:後から整合性を保つように修正すればよいと考えることができる
わからない⑤
変化に対してどう対処したらよいかわからない(適応)
  • 原則2:整合性を保ちながらやれば変化しても大丈夫
  • 原則3:変化を前提にしておくとしておかないのでは大違い

4. ビューとモデル

システミングにおいて中心的な役割を担うフレームである「ビューモデル」を構築したり、システミング三原則の一つである分けて考えるを実践する上で重要な概念として「ビュー」と「モデル」があります。ここではビューを考える上で必要なビューポイントとあわせて、ビューとモデルの基本的な考え方について紹介します。ビューとモデルはシステム思考においても重要な概念であり、別冊の「システムとして考える〜システム思考&システムモデル入門〜」でも例を含めて紹介していますので、合わせてご覧下さい。

4-1. ビューポイント

複雑なシステムの全体をそのまま考えたり理解したりすることは困難なので、システムデザインを進めるときには、システムの一部や特定の側面を切り取って表現する必要があります(システミング三原則の原則1:分けて考える)。そのような表現をする際の関心の持ち方や立ち位置のことを「ビューポイント」と呼びます。例えば、システムの機能に関心を持つビューポイント(Functional Viewpoint)、システムがどう使われるかに関心を持つビューポイント(Operational Viewpoint)、システムの物理的な姿について関心を持つビューポイント(Physical Viewpoint)などが例として挙げられます。

ビューポイントのイメージ図

4-2. ビュー

ビューポイントはシステムを切り取って見るときに「どの方向からシステムを見るか?」を表す立ち位置のことでしたが、ビューは「システムをどのように切り取って見るか?」を示す言葉です。ビューポイントを決めるだけではビューは決まりません。ビューポイントに加えて、抽象度とスコープ(範囲)を決める必要があります。

4-2-1. ビューの抽象度

ビューを考えるときの抽象度とは、簡単に言うと「どのくらい細かく見るか?」のことです。例えば、システムの物理的な側面について関心を持つビューポイント(Physical Viewpoint)からラップトップPCの構造を理解するという場合を考えてみましょう。抽象度が高いビューではディスプレイ・キーボード・ストレージ・バッテリーなどの大きな物理構成が見えます。一方で抽象度が低い(具体度が高い)ビューでは通信バス・コネクタ・ケーブル・変圧デバイスなどのより細かいデバイスやコンポーネントが見えてきます。

4-2-2. ビューのスコープ

ビューポイント(どの側面を見るか?)と抽象度(どのくらい細かく見るか?)を決めれば、あとは「どの範囲を見るか?」さえ決めればビューが定まります。あるビューポイントから見たときのシステム全体を見るビューを考えてもよいですし、特定の目的と役割を持ったサブシステムについて考えるビューを想定することもできます。

抽象度を低くする(細かく見る)場合はある程度範囲を狭めないとビューに含まれる情報が多くなってしまって表現しずらくなってしまいます。逆に高い抽象度でシステムを捉える(粗く見る)場合はシステムの全体や大部分を自然な形でビューにおさめることができるでしょう。抽象度とスコープはそれぞれ設定することができますが、上記の理由から、抽象度が高いほどスコープが広くなる場合が多いです。

4-2-3. ビューを定める

ビューポイント、抽象度、スコープを決めれば一つのビューが定まります。逆に、あるビューについて考える場合、どんなビューポイントから見ているのか?どのくらいの抽象度で見ているのか?どの範囲を見ているのか?を考えることができます。

ビューを決めるポイント

ビューはシステムを切り取って見るときの、切り取り方や枠(フレーム)であると言うことができます。システムを切り取って見たときに見えるものそのものではなく、切り取り方を指します。見えるものは次の節で説明するように「モデル」と呼びます。

ビューの決め方や、ビューとモデルの違いは、カメラで写真を撮る場面を思い浮かべると分かりやすいかもしれません。システムを表現するためにビューで切り取ることは、被写体をカメラで撮影することに似ています。人物を被写体とする比喩で考えてみましょう。

その人物を正面から撮るのか、それとも後ろから撮るのかを決めることがビューポイントを決めることに相当します。その人物の全体が写真におさまるようにするのか、それとも顔や手足など一部だけを撮影するのかを決めることがスコープを定めることに相当します。また、抽象度はズームアップの度合いに相当します。手を撮影する場合に、皮膚の毛穴までわかるように撮るのか、腕や手のひらの形状がわかるように引いてとるのかでは、出来上がる写真がだいぶ違います。ここまでのこと(どこから撮るのか?どの部分を撮るのか?どのくらいズームするのか?)を決めると定まるカメラのファインダー(どのような写真が撮れるのかを確認するためののぞき窓)がビューです。そして、撮影された写真がモデルです。

ビューとモデルの関係

4-3. モデル

4-3-1. モデルの表現方法

ビューはシステムを切り取って見るときの枠のことであり、その枠から見えたシステムを表現したものがモデルです。前の節ではそのことをカメラの比喩で説明し、ビューはファインダーでありモデルは写真であるとしました。カメラの場合はファインダーを定めてシャッターを押せばモデルに相当する写真が写されますが、システムデザインの世界ではビューを定めただけではモデルを描くことができません。そのモデルをどのような手段で描くのかを決めることではじめてモデルを描くことができます。

例えば、モデルは文章(ドキュメント)や箇条書き(リスト)で描くこともできます。仕様書や機能リストなどがこのようなモデルに相当します。他にも図や表などを使って描くこともできますし、それらを組み合わせて表現することもできます。図の一種になりますが「システムモデル」として表現したモデルが使われる場合も多くあります。システムモデルは、システムを構成する要素をノードで、要素同士の関係性をリンク(エッジ)で描いたネットワーク状の図のことです。詳しくは別冊の「システムとして考える〜システム思考&システムモデル入門〜」で説明しています。

システムモデルの例

ビューを定め、そのビューを表現する方法を決めると、モデルを描くことができます。表現方法としては文書、図、表、システムモデルなど様々な方法を選ぶことができますが、どの方法が適しているかは対象となるシステムやビュー、そしてモデルを描く目的によって異なります。

ビューと表現方法が決まるとモデルを描くことができる
4-3-2. モデルの意義

システムをつくるときは、チームメンバーの間や顧客などのステークホルダと開発者の間でシステムに対する認識を合わせることが重要です。どんなシステムをつくっているのか(つくるべきなのか)について認識が揃っていないまま設計や実装を進めてしまうと、意図通りに動作しないシステムや、顧客から見て役に立たないシステムができあがってしまいます。

しかし、人は複雑なシステムの全体をそのまま理解することはできないので、システムに対する認識を合わせるためには工夫が必要です。そこで登場するのが、ビューやモデルです。ビューで切り取ってモデルとして表現することで、人はシステムの部分的な姿を理解することができるようになります。すると、チームメンバーや顧客との間で、少なくともそのビューで切り取った側面や部分については認識を合わせることができます。これが、システミング三原則の分けて考えるが重要な理由です。

ここまでを読んだ皆さんの中には、ビューとモデルの違いがいまいち分からなかったり、わざわざ別の概念として登場させる必要性がわからないという方がいるかもしれません。その場合は、さしあたってはビューとモデルを同じものとして混同してしまっても構いません。ビューとモデルの概念をはっきりと分けて考えることができれば、より広い範囲に対して効果的なシステミングができるようになります。しかし、ビューとモデルを同じようなものだと考えても、システミングの基本的な部分を実践することはできます。慣れるまでは無理に理解しようとせず、同じようなものだと思って読み進めてみて下さい。

システミングガイドブックに続く

ここまでに、システミングとは何か、システムデザインの定義、システムデザインにおける問題、その問題へのアプローチ、そしてシステミングにおいて重要な考え方となるビューとモデルについて説明してきました。

いよいよここからがシステミングの中核的なフレームであるビューモデルマイルストーンの解説となります。続きはシステミングガイドブックに記載しているので、ぜひダウンロードしてご覧になって下さい。