社会や社会や産業自体が理解の難しい複雑なシステムとなっているために、社会や産業の問題は想定している創発的機能が何らかの原因で動かなくなっている現象や、想定外の望ましくない創発が発生している現象であると考えています。このため、システムとしての社会や産業における創発を適切にマネジメントすることにより問題定義から課題解決までを行うアプローチを考えます。このように、課題解決を行うにあたり、対象をシステムとして考えるシステム思考および関連手法を用いてアプローチのことをシステムズアプローチと呼んでいます。
システムズアプローチは、特定の手法やツールを指す名称ではなく、複雑なシステムを明示的にシステムとして考えて課題にアプローチする考え方を指します。
本研究室では、利害関係に基づいたシステムへの要求の記述、サブシステム間の関係性に注目した機能、振る舞いを記述する方法を組み合わせて問題定義から解決に取り組むアプローチをシステムズアプローチとして教育プログラムに組み込んでいます。【参考資料】
ここではNASA Systems Engineering Handbook (SP-2016-6105)のFIGURE 4.0-1を前提に説明します。システムの設計プロセスを、Stakeholder Expectations, Requirement Definition, Logical Decomposition, Design Solution Definitionの4つの反復と想定します。
Stakeholder Expectationsでは、Stakeholder Value Networkなどの形式で記述する、Structured Interviewの結果をまとめる、など、ある程度属人的な要素を含んだ方法により利害関係者の関係性を定義していくことなります。また、利害関係者やユーザーがどのようなことを期待しているか、要求しているかを記述します。ユーザーの立場では、ConOps(Concept of Operation)としてまとめることが有益です。
Requirement Definitionでは、前述の利害関係者の期待を、システムが満たすべき技術的・定量的な要求へと変換します。システムの要件という言葉が該当します。期待から要件への変換作業には、機能要求や非機能要求の概念、狩野モデルなどによる品質要素の分析、などが利用できます。
Logical Decompositionでは、定義した要件を満たしていくためのシステムはシステムアーキテクチャなどの形で具体化されます。ここでは、OPMやSysMLなどのシステム記述言語が利用できます。
Design Solution Definitionでは、具体化されたシステムアーキテクチャが、ConOpsを満たすことができるか、利害関係者の期待を満たすことができるか、などを検証します。このプロセスではシミュレーションなどの定量的なアプローチも必要になります。必要に応じてStakeholder Expectationsからやり直すこともあります。これらの4つのプロセスを反復しながら、システムの設計は洗練され、確定します。
複数の設計変数により、複数の性能を満足するような設計問題に対して、デザインポイントではなく変数等を範囲として扱って設計します。設計変数の変更による非線形や影響や、性能間のトレードオフを含む複雑な設計問題で有益な手法です。
手法のコンセプトは明快で、複雑なシステムを扱う場合の基本的な考え方であるものの、設計変数を範囲として扱うことにより生成される複数の設計案を対象に評価を行う必要があるなど、製造業の設計工程への導入には工夫が必要となります。このため、現在では多くの書籍や企業向けサービスが存在します。
As society and industry itself are complex systems that are difficult to understand, we believe that the problems in society and industry are phenomena in which the desired emergent functions are not working for some reason or in which unexpected and undesirable emergence is occurring. For this reason, we consider an approach that covers from problem definition to problem solving by appropriately managing emergence in society and industry as a system. This approach, which uses systems thinking and related methods to think of the target as a system, is called a systems approach.
The Systems Approach is not a name that refers to a specific method or tool, but rather to a way of thinking about complex systems and approaching problems by explicitly considering them as systems.
In our laboratory, we incorporate the systems approach, which is an approach to solving problems from problem definition, into our educational programs by combining methods for describing system requirements based on interests, and describing functions and behaviors by focusing on the relationships among subsystems. (Reference material)
This section assumes FIGURE 4.0-1 of the NASA Systems Engineering Handbook (SP-2016-6105). We assume that the system design process consists of four iterations: Stakeholder Expectations, Requirement Definition, Logical Decomposition, and Design Solution Definition.
In Stakeholder Expectations, the relationships among stakeholders are defined using a method that includes some human elements, such as describing them in the form of a Stakeholder Value Network or summarizing the results of Structured Interview. In addition, the stakeholders and users will be able to define their own relationships. We will also describe what stakeholders and users expect and require. From the user's perspective, it is useful to summarize it as ConOps (Concept of Operation).
In Requirement Definition, aforementioned stakeholders' expectations are translated into technical and quantitative requirements that the system must meet. The term "system requirements" is applicable. To transform expectations into requirements, the concepts of functional and non-functional requirements, analysis of quality factors using the Kano model, etc., can be used.
In Logical Decomposition, the system for satisfying the defined requirements is materialized in the form of a system architecture. Here, system description languages such as OPM and SysML can be used.
In Design Solution Definition, we verify whether the embodied system architecture can satisfy ConOps, meet the expectations of stakeholders, and so on. This process also requires a quantitative approach such as simulation. If necessary, we may start over with Stakeholder Expectations. Through iterations of these four processes, the system design is refined and finalized.
For design problems with multiple design variables and performance requirements, this approach treats variables and other factors as ranges rather than single design points. It's a useful method for complex design challenges that involve nonlinear effects from design variable changes and trade-offs between different performance metrics.
The concept is clear and serves as a fundamental principle for handling complex systems. However, its implementation in manufacturing design processes requires innovation. This is because it generates multiple design options that must all be evaluated, making integration a challenge. Consequently, many books and corporate services are now available to assist with its adoption.