SEエンジンとVプロセスの徹底解説― 分解と統合から導くV字モデル、V&V、反復・再帰の原理

前回はシステムズエンジニアリングの土台となる基礎概念、検証(Verification)と妥当性確認(Validation)について解説しました。

仲でも特に検証(Verification)と妥当性確認(Validation)は、システムズエンジニアリングの根幹を成す非常に重要な概念になります。
※ここからはシステムズエンジニアリングをSEと略します。

もし”理解があやしいな”と思ったら前回の内容で復習して欲しいと思います。

さて今回は、いよいよSEのプロセスの具体的な内容に入ります。具体的な内容と言っても、細かい作業レベルの具体性ではなく、SEプロセスの全体像を知ろうというレベルになります。

興味深いことに本記事のベースとなるNASA システムズエンジニアリング　ハンドブック自体がSEのアプローチで出来ているので段階的に細分化して理解させていく仕組みになっています。

本記事のメインの内容はNASA システムズエンジニアリング　ハンドブックの共通技術プロセスとSE エンジン（原題:2.1 The Common Technical Processes and the SE Engine)部分になりますが、SEエンジンを理解するためにはVプロセスの概念を理解する必要があります。

よって本記事では、Vプロセスとは？（前回の復習を含む）、共通技術プロセスとSEエンジンの順で解説していきます。

では始めましょう。

Vプロセスとは？

まずは以前に解説したシステムの定義の図解を思い出しましょう。

上の図の定義から物事をシステムとして考えると、システムは以下の図のように捉える事ができることを前々回に解説しました。

具体例として自動車、日本政府、宅配ピザのデリバリーサービスをシステムとして考えて図解しました。
※日本政府は複雑なので図の紹介は省略

ここまでは「システムとは何か？ ― 抽象度とMECEで理解する“システム思考”の基礎」の復習で、実際に存在するモノ・コト・サービスなどをシステムとして考えることを中心に解説して来ました。

ここからは具体例の自動車と宅配ピザのデリバリーサービスを使ってシステムを開発する・作ることを２つに分けて考えて行きます。

システムを開発する

新しいシステム、例えば具体例で出したような自動車や宅配ピザのデリバリーサービスを開発するときに、いきなり最初に開発する新しい自動車に使うネジやバネ、ベアリングなどを考えたりすることはほとんどないと思います。宅配ピザのデリバリーサービスにおいても同様に、最初から配達用の車両をどうするかを考える人はあまりいないと思います。

当然ながら自動車の仕様決定、エンジンなどの仕様の決定と段階的に使用を決めないと構成部品であるネジやバネ、ベアリングをどうするか全く決まりません。宅配ピザのデリバリーサービスにおいても、サービス内容のコンセプトを決めないと詳細は決定できません。例えばデリバリーエリアが高層マンション群だったらそもそも車両なんて使わずに自転車と配達員の組み合わせのが効率が良いかも知れません（ウーバーイーツに外注とか）。

このように、まずどんな自動車にするか？どんな宅配ピザのデリバリーサービスにするか？の全体の構想を決めないと具体的な個別の課題・問題を解決していくことは全くできません。

実際にシステムを開発する場合は人は物事を段階的に具体化して考えるわけです。その行為を図式化すると下図のようになります。

具体例の自動車だと完成車の仕様が決まる、パワートレインの仕様が決まる、エンジンの仕様が決まる・・・最後に個別の部品の仕様が決まるわけです。宅配ピザのデリバリサービスにおいてもサービスの概要が決まる、配送の内容が来まる、具体的な移動方法が決まると順番に決まりますね。

ここからがSEで非常に興味深いことに、システムを開発する各段階と物事をシステムとして分解したときの各抽象度が一致します。

これを一般的な開発で使う用語に直すと次のようになります。

これがSEの重要な概念で段階的に開発することを示しています。勿論のこと単一のサブシステム、サブサブシステムで行うのではなく同時並行的に各サブシステム、サブサブシステムにおいても段階的に開発します。

簡単に言うと人が無意識に行っていることを図式化したわけです。概念的にはシステムで実現したいことを段階的に分解し、数多の末端部品に分けて行くので、要素を増加させる工程になるわけです。

システムを作る

ここからはシステムを実際に作り上げることを考えて行きましょう。

ここではシステムの開発が完了したと考えて、末端の構成部品が出来上がった状態を考えて行きます。当然ながら末端の部品であるネジやバネ、ベアリングだけでは自動車になりえません。同様に宅配ピザのデリバリーサービスにおいても宅配車両だけでサービス全体が出来上がるわけではありません。

末端の部品の組み立て、末端の配送車両や人、設備を目的に沿って組み合わせることによって、特定の目的を果たす塊（サブシステム、サブサブシステム）が出来上がります。

その完成した塊（サブシステム、サブサブシステム）が段階的に他の塊（サブシステム、サブサブシステム）と統合されることによって自動車や宅配ピザのデリバリーサービスが出来上がるわけです。

この段階的に組み立てる、組み合わされることを、システムの概念を使って一般化すると下の図のようになります。

この段階的に組み立てられる・統合される過程も”システムを開発する工程”と同じように各段階が物事をシステムとして分解したときの各抽象度が一致します。

これを”システムを開発する”と同様に一般的な言葉に書き直します。

興味深いことに”システムを開発する”工程の正反対で、バラバラな末端の要素を段階的に統合していきます。この作る工程の面白いのは概念も”システムを開発する”工程の真逆で数多の末端要素を段階的に組合せ・統合するので最終的には一つのシステムに収束するわけです。

Vプロセス

ここまではシステムを開発する・作るを分けて考えてきました。

折角なのでこの2つの工程を統合させます。ただし単純に統合させると見辛いのでVの字に並べます。

これによって”システムを開発する・作る”工程の全体が一つの図で表されるわけです。

ここで右側の”システムを作る”工程の実現・統合の言葉をテストに言い換えて図を少し変更します。
※実際に実現・統合のためにはテストで確認しないと、上位の工程には進めない。

これが巷でよく見るVプロセスになるわけです。

Vプロセスをシンプルに述べると以下のようになります。

当たり前のことのように見えるかと思いますが、案外と複雑なシステムを実現するときのスタッフの一人として実務を行うと、自分が”何を、何のためにやってる？”のかがわからなくなることが多々あるので非常に重要な概念になります。

Vプロセスと検証(Verification)と妥当性確認(Validation)

ここで折角の機会なので前回の内容の重要な検証（Verification)とだと妥当性確認(Validation)をVプロセスを使ってイメージを強化させます。

まずは私流のポイントを復習します。

まずは検証から考えて行きましょう。

検証は定義通り、目標に対して実際はどうなっているかを確認する作業なのでVプロセスで考えると右側のテストの結果が左側の設計で設定した仕様を満たすかどうかを確認する作業と同じ意味になります。

よって図式化すると以下のようになります。

Vプロセスにおいての検証(Verification）は左右で整合が取れているかどうか？を表していて非常にわかりやすく、実際にどのタイミングで何を確認すればいいのかがわかりやすくなります。

ただし頂点の全体のテストにおいては検証(verification)かどうかについては、後で回収します。

次に妥当性確認を考えて行きます。

妥当性確認の定義は、目標に対し目的はどうか？なので、Vプロセスで考えると上位の工程と下位の工程が論理的に正しく繋がっているかどうか？の確認になります。

Vプロセスで具体的に例えると、左上の要求定義で導き出された目標に対し基本設計の目的はちゃんと合致しているかどうか？、右上で考えると構成要素（モジュール）の機能は、システム全体の担当役割をちゃんと果たしているかどうかの確認になります。

これを図式化すると以下のようになります。

Vプロセスにおいては、妥当性確認(Validation)は上下の階層の整合性を表していて非常にわかりやすくなっています。検証と同様に図から妥当性確認(Validation)は”どのタイミングでなにを確認をすればいいのか”がわかるようになっています。
※それでも妥当性確認(Validation)は、数値などで定量的に判断できる作業ではないので難しい。

ここで残った問題は、頂点の左右の要求定義と全体テストの繋がりです。ここまでのセオリーで考えると検証になりそうですが意味を考えると、”システム全体への要求が作ったシステム全体と合致しているかどうか”の確認になるので妥当性確認になるわけです。

つまり作ったシステムは単なるテストでの検証では、完全に期待通りに完成しているのかが確認できないので、実際の環境でシステムを使って確認する必要があることから妥当性確認になります。
※完成テストをどれだけやり込んでも、市場で多少のトラブルが出ることを思い出して下さい。

図示化すると以下のようになります。

左右の整合性でも頂上だけは妥当性確認になることがわかると思います。

ここまでの検証（Verification)と妥当性確認(Validation)を一つのVプロセスで表すと以下のようになります。

この検証、妥当性確認がVプロセスに入ることによって、システムを作る場合にいつ、どのタイミングで、何を確認するのかが理解しやすくなります。

この図によって、前回に解説したシステムズエンジニアの技術（Art)である、システムのバランス追求と妥当性確認のために、”いつ、どこを調査すべきかを知ること”を大きく支援することになります。

この検証と妥当性確認の工程をお互いの頭文字を使ってV&Vと呼ばれることもあります。

個人的な印象ですが、日本企業の業務においては一般的にプロジェクトを分解して、プロジェクトをタスクごとに個別に業務に分けて日程軸で管理することが多いと思います（ガントチャートが多いかな）。

この方法だと各単一業務の進捗・達成度確認には最適ですが、各業務の進捗。達成度がプロジェクトの全体にどうのような影響を及ぼすかは非常にわかりにくくなっています。特に見落としがちなのが各業務間の調整と確認です。この調整と確認スキルは個人の経験やスキルに頼ることが現状だと思います。

実際の有名な日本でのV＆Vの失敗の具体例をいくつか挙げて見ます。

他にもキリがないくらい問題があります。
※システムの設計で失敗しているから、各担当者がいくら頑張ってもなかなか問題が解決できない

解決策案としてガントチャートと並んで、プロジェクトを分解し、Vプロセスに書き出して管理すると各業務間の繋がりが可視化されるので各々の調子・確認作業の設定・抜け漏れや個人間スキル差のバラツキを少なくし業務効率化に大きく役に立つので非常にオススメです。

イメージとしてガントチャートで個別業務の進捗管理、Vプロセスでプロジェクト全体の進捗管理という感じで使うと効果的です。
※もし実戦方法、詳しいやり方やアイデアが聞きたい方は私に直接、問い合わせて下さい。

話が脱線しました、元に戻しましょう。

Vプロセスで理解するインターフェースの重要さ

ここでは、前回の重要な内容の一つである要素間の相互作用の繋がりの管理、つまりインターフェース、フローの管理の重要性をVプロセスを使ってより理解して行きましょう。

おさらいで、具体例の自動車システムの分解とフロー・インターフェースを思い出しましょう。

このフローとインターフェース管理が抜け落ちると何が起きるかをVプロセスで考えて行きましょう。

フローとインターフェースを全く気にせずに垂直に物事を進めた場合は、Vプロセスにおいて以下の図の所までは何のトラブルもなく進めます（縦割り業務）。

フロー・インターフェース管理をやらなかった場合はここから先が地獄の始まりになります。

もう、こうなったら最悪事態です。ユニット、モジュール、システムが組めない・期待通りに動かないので完全にやり直しになります。

このように図にして書き出すと当たり前のように感じると思いますが、おそらくは仕事などで皆さんも似たような経験があるのではないでしょうか？

自分のエンジン設計経験でもインターフェースの不一致・フローの不一致だと完全にやり直しレベルで致命傷です。部品の改修で済むレベルは稀です（取付寸法不一致、荷重伝達経路の不一致など）。

有名な日本でのインターフェース管理の大失敗例をいくつか挙げて見ます。

これも挙げたらキリがないくらい多いです。
※システムの設計で失敗しているから、各担当者がいくら頑張ってもなかなか問題が解決できないから現在も続く問題もあります。

このことからもシステムを開発する・作る行為においてはフローとインターフェースの管理が非常に重要になるのがよく理解できると思います。

実際のフロー・インターフェース管理のやり方は、このSE連載の後の記事、章でじっくりと具体的に解説します。
※もし直ぐにでもやり方・方法を知りたい方は、直接、私にお問い合わせください。

ここまでのことから前回で説明したシステムズエンジニアの役割はシステムの成功に非常に大きな役割を果たすことがよくわかると思います（今回の説明ではV&Vとインターフェース管理の重要性）。
※日本の具体的な失敗事例の原因のほとんどは、システムズエンジニアに相当する役割を果たす人が居なかったことだと思います。

ここまでがVプロセスと前回の内容の理解を深める内容になります。

システム解説の全容を理解したところで、各階層では実際に何をやるのかをNASA システムズエンジニアリング　ハンドブックの共通技術プロセスとSEエンジン（原題:2.1 The Common Technical Processes and the SE Engine)翻訳を主体に解説していきます。

共通技術プロセスとSE エンジン

NASAの規定であるNPR 7123.1（NASAシステムエンジニアリングのプロセスと要求事項）では、共通技術プロセスを”システム設計、製品実現、技術管理”という3つのセットに分類しています。
※NPR 7123.1は日本の一般的な会社で言うと社内業務規程、社内技術標準規格に近い感覚のもの。

これらの各プロセスの内容と、それらの相互作用および情報の流れを図示したものが、NPRのシステムエンジニアリング エンジンです。SEエンジンのプロセスは、最終製品（サービス、組織などのシステムの完成品）を開発し、実現するために使用されます。

※図の内容の詳細は後の章、記事で紹介するので、ここではなんとなくの理解で十分です。

図に示されるプロセス1から9は、プロジェクト遂行における具体的な”タスク（実務）”を表し、プロセス10から17は、それらの実務を遂行するための”横断的なツール”としての役割を担っています。

システム設計プロセス

システム設計プロセスの４つのプロセスは次のような目的で使われます。

これらのプロセスは、システムの最上位階層から最下層へと、それぞれの階層に対して適用されます。

システムの最下層にあたる要素は”製造、購入、または再利用（built, bought, or reused）”できるレベルに定義されるまで続けられます。
※製造、購入、または再利用できるレベルとは、具体的に実体化できるレベルのことを示す。例えば製品だったら部品レベル、組織やサービスなら個別の人や業務、部屋などの具体的なレベルのこと。

最下層（実体レベル）は実装によって生み出され、それより上の階層は、その実体を統合していくことでシステムが実現されます。

製品実現プロセス

製品実現プロセス（プロセス5～9）は、システム内の製品に対して、最下層の実体レベルから始まり、上位階層の統合製品へと向かって適用されます。

この製品実現プロセスは、各製品の設計解を作成するため（購入、コーディング、製造、または既存の再利用）、設計解を満たしステークホルダーの期待に応える製品の検証（verify）、妥当性確認（validate）、次の階層レベルへと移行させるために使用されます。

技術管理プロセス（横断的プロセス）

技術管理プロセス（プロセス10～17）は、以下の目的で使用されます。

SEエンジン内のシステム設計プロセス、製品実現プロセス、技術管理プロセスは、反復的かつ再帰的に何度も使用されます。

反復的かつ再帰的の定義

NPR 7123.1では、反復的と再帰的を以下のように定義しています。
※NPR 7123.1は日本の会社に例えると社内規格のようなモノ

これは、次のライフサイクルフェーズにおいて、システム定義を成熟させ各フェーズでの成功基準を満たすために、同じプロセスをシステムに対して繰り返し適用する場合にも当てはまります。

技術プロセスは、システムの初期コンセプトを、技術チームが製品を実装できるほど具体的な詳細レベルになるまで分解するために、再帰的かつ反復的に適用されます。

その後、最小の製品をより大きなシステムへと統合し、システム全体が組み立てられ、検証・妥当性確認され、移行されるまで（システムの完成）、再び再帰的かつ反復的に適用されます。

AS9100との整合性（民間航空宇宙産業向け規格との整合性）

AS9100とは、民間航空宇宙産業向けに開発され広く採用されている品質マネジメントシステム規格です。
※航空宇宙産業に携わる企業に対し、必ず適合しなければいけない規格。末端の部品レベルでも適合が必要

一部のNASAセンターではAS9100の認証取得を選択しており、契約業者にもNPR 7123.1の遵守を求める場合があります。

なおSEエンジン（システムエンジニアリング・エンジン）を実際にどのように使用するかについての詳細な事例を知りたければ、別の文書である”NASA Expanded Guidance for SE”を参照してください。
※本サイトでは拡張版の具体例を別記事で紹介します。

共通技術プロセス、SEエンジンとVプロセスの解説

ここでは、第2章で解説した共通技術プロセスとSE エンジンをVプロセスと結びつけて理解をより進めましょう。

本記事の2章での説明と同様にシステム設計プロセス・技術管理プロセス・製品実現プロセスに分けてVプロセスと合体させていきます。

システム設計プロセスとVプロセス

まずはシステム設計プロセスをVプロセスに当てはめます。

図からわかるように各階層でシステム設計プロセスを行うことによって設計対象システムがどんどん具体化・細分化されていくわけです。上位のシステム設計プロセスから具体化された要求、技術要求、論理解定義、設計解定義が下位のシステム設計プロセスに渡されて進んでいきます。

最終的には複数の部品図面や詳細な仕様書になって、本記事の2章の内容にあるように製造、購入、または再利用可能レベルとなり実際に調達することになります。

製造、購入、または再利用可能レベルの具体例は、自動車だとボルトやバネ、ベアリングなどのような個別部品レベルとなり実際に製造・調達・購入をすることになります。ただしここで面白いのが自動車会社がECUのような自社で製造しない部品を調達する場合は、ECUレベル以上に要素を分解する必要がないのでECUまでの階層でシステム設計プロセスは完了です（機能買い部品）。

宅配ピザのデリバリーサービスで考えるとピザの移動をウーバーイーツなどに外注する場合は、配達車両や配達員のことは考えなくても良いのと同じ理屈です（ウーバーイーツにやって欲しいことを依頼する=仕様書）。

技術管理プロセスとVプロセス

次に技術管理プロセスを考えて行きます。

技術管理プロセスは司令塔のような役割を果たします。

技術管理プロセスは各システム設計プロセスと常に連携し、各システム設計プロセスの管理・コントロールを行います（要求、技術リスク、構成、技術データ管理と評価）。

この技術管理プロセスによって各サブシステム、サブサブシステムの設計が適切にコントロールされることによって全体のバランスが最適化されます（妥当性確認とインタフェース管理）。

例えば、強力な権限があるどこかの担当や担当部署が勝手に仕様を決めて強力な独自解釈で物事を進めるような場合はこの技術管理プロセスによって抑え込まれます（抑えに入らなきゃいけない）。そうしないとプロジェクトは最初の計画から大きく逸れて行き、最悪な場合はプロジェクト失敗で中止です。
※どこかの部署が勝手にインターフェスを変えてしまって、システムが組めない経験がある人が多いはず。

逆に力がない、予算がない、人が少ない部署が担当している設計に対しては、技術管理プロセスによって積極的な支援が入り、全体のバランスを保たれます。

つまりこの技術管理プロセスが非常に重要で、前回に述べたSEの要である全体像(Big picture)を見てバランスを取ってシステムを最適化するプロセスそのものになります。

個人的な経験と観察から、日本においてSEやVプロセスの考え方を導入した結果、思うような効果が得られない最大の原因は、この技術管理プロセスが不十分、技術管理プロセスを行う人への権限不足だと思います。

製品実現プロセスとVプロセス

次に製品実現プロセスをVプロセスに当てはめます。

製品実現プロセスにおいてもシステム設計と同様に各段階のレベルに応じて同じ内容の製品実現を行います。ここで興味深いのはシステム設計プロセスとは異なり、数多の最小構成品がどんどん一つのシステムに統合されて行きます。

最終的に完成したシステムは、製品実現プロセスを通してVプロセスの左上の要求定義と妥当性確認(Validation)を行って一先ずの完成となります。
※次回、解説するライフサイクルがあるのでSEプロセス自体が終わるわけではない。

ここでついでに製品実現プロセスと共通技術管理プロセスを同じ図に載せます。

技術管理プロセスは各製品実現プロセスと常に連携し、各製品実現プロセスの管理・コントロールを行います（検証、妥当性確認結果の管理など）。

ただし、上の図の内容の技術プロセスの役割は通常運転時に過ぎず、真価を発揮するのは各製品実現プロセスでトラブルが発生した時に大活躍する重要なプロセスになります。

例えば上の図のように製品実現プロセスの構成品（ユニット）のテストで何かのトラブルが起きた時に、技術管理プロセスはそのトラブル内容を分析し、新たな知見を整理・反映し、新たな技術計画を策定して適切な階層からプロセスを再実行させます。
※実現性が全くない場合は、最上位の要求定義から見直しする場合もある。

まさに司令塔の役目を果たすことがここからよくわかると思います。

共通技術プロセス、SEエンジンとVプロセス

ここでの各プロセスとVプロセスの関係の解説をまとめた図が下の図になります。

かなり複雑な図になってしまいましたが、各プロセスがどこで、どのように実施され、何を生み出すのかが理解しやすいと思います。特に技術管理プロセスは上下左右に渡って全ての工程を管理する役目を補っていることがわかると思います。

本記事の第2章で解説した技術管理プロセスが横断的であることがより理解しやすくなったと思います。

反復的かつ再帰的とVプロセスの解説

最後に反復的かつ再帰的という概念は非常に重要なのでVプロセスを使ってより理解を含めて行きます。

反復的とVプロセス

まずは反復的を考えて行きましょう。再度、反復的の定義を書き出します

反復的の発動条件が”発見された不一致や要求事項からの変動”ということから、上のVプロセスで説明したようにどこかでトラブルが出たことと同じになります。

そのトラブルが発生した時は、修正のために再度プロセスを実行せよと言うことになります。

この内容を踏まえて反復的を図解します。

図でわかるように、例えば構成品（ユニット）のテストでトラブルが出た場合に、その場の修正で対応し先に進まないで、必要に応じてちゃんとプロセスを反復せよということです。
※必要に応じたプロセスの段階・量・範囲の見極めは技術管理プロセスの本領発揮分野、システムズエンジニアの腕の見せ所でもある

これがSEにおける反復的の意味になります。勿論のこと図では例として構成品（ユニット）のテスト段階でのトラブルを例にしましたが、どの段階でトラブルが起きてもプロセスを反復させます。

SEで反復させる大きな理由は、特定の階層、部位での修正対応だと、局所的な最適化が行われたことと同意になり全体バランスが欠けるのを防ぐためです。

私の経験では、局所的対応が全体に大きな影響を及ぼしてもっと大きなトラブルに繋がることも少ないです。皆さんもゲームなどのソフトウェアでいくらパッチ修正をしてもどうにもならないことがあるのを経験したことがあるかと思います。

局所的なトラブルでもシステム全体で受け止めることにより、最適なバランスを保つことを可能にしています。

再帰的とVプロセス

次に再帰的を考えて行きましょう。

まず再帰的の定義を再び書き出します。

再帰的は、なかなか普段は使わない言葉なので日本語の意味から解説します。

再帰的の日本語辞書的な意味は”あるものが、自分自身を再び参照したり含んだりする様子”のようです。ちょっとわかりにくいので筆者流に言いかえると”自分自身を振り返って自分が変化する様子”だとどうでしょうか？

私的なポイントとしては、”自分自身が変わる”と言うところがポイントになります。

これを踏まえてSEにおける再帰的を図解していきます。図解するシーンはVプロセスの左側、設計プロセスで妥当性確認をする場合を切り取って図解します。

図からわかるように単純に階層を戻るのではなく、階層を戻って自分が変化する、つまり再帰することがわかると思います。
※必要に応じた再帰の段階・量・範囲の見極めは技術管理プロセスの本領発揮分野、システムズエンジニアの腕の見せ所でもある

SEにおいての再帰的の大きな目的としては、特定の階層、箇所でのスタックによってシステム全体が成立しないことを防ぐことが理由になります。
※極端に言うと末端の部品設計が成立しないことを原因にプロジェクト全体が中止に追い込まれるのを防ぐ。

この再帰的により局所的なトラブルを上位階層を巻き込んでシステム全体で解決する重要な概念になります。

反復的かつ再帰的とVプロセス

ここまで反復的と再帰的をそれぞれ独立して説明してきました。ここでは、それを合体させてSEにおいて重要な反復的かつ再帰的を解説しましょう。

早速、図解します。図解のシチュエーションとしては、構成品（ユニット）のテストでトラブルが出た場合とします。
※本記事の第3章の製品実現プロセスとVプロセス内でのパターンと同じ

図からわかるように構成品（ユニット）のテストでトラブルが出た場合に、修正対応で先に進むのではなくプロセスを反復させて、各階層が再帰されて進むことになります。
※必要に応じた反復・再帰の段階・量・範囲の見極めは技術管理プロセスの本領発揮分野、システムズエンジニアの腕の見せ所でもある

これがSEにおける重要な概念の”反復的かつ再帰的にプロセスを実行する”の意味になります。

繰り返しになりますがここで重要なのが、単なる単なる修正ではなく反復的かつ再帰的にプロセスを再実行することによりトラブル階層（又は部位）の局所最適化ではなくて、全体の最適化を図るメインの仕組みになります。

これがSEの最大の特徴である全体最適化を担保する大きな一つです。私的には、プロセス内のトラブルを糧に全体が最適化される自己進化型のプロセスになっていると思います。

個人的に思うことですが、多くの日本企業や組織においては、反復（繰り返し）は得意ですが再帰的（特に上位階層）はかなり苦手だと思います。

メカニズムとしては、日本の”一度決めたことはやり通す”の精神と上位階層を担当する人・部署・組織は権限がかなり強いので、この2つが悪い効果を増幅するカタチで混ざり合い上位階層の再帰は絶望的に難しくなっています。

日本における反復的かつ再帰的を欠いた代表例をいくつか挙げて見ます。

他にもたくさんありすぎて挙げたらキリがありませんし現在、進行形の問題もあります。

特に日本への影響が大きかったのが福島第一原発の電源完全喪失（完全電源喪失のケースを再帰してないから対応が存在しない）でしょうか。

この過去に起きた代表的な問題からも反復的かつ再帰的なプロセスの再実行の重要性がかなり理解できると思うので、是非とも理解して欲しいと思います。

まとめ

まとめと言いつつも今回はボリュームが大きいかつ重要な内容なので、内容を簡単に振り返りながら私が経験から得たアドバイスを述べてこの記事を終わりにしたいと思います。

まず最初にVプロセスです。

Vプロセスについては、2010年代前半から流行り出して、現在では当たり前になった概念ですが本質を解説していることが少ないので今回でキッチリと解説しました。

V,プロセスの実戦のコツとしては、概念図をそのまま使うのではなく実際に自社、自分の業務を書き出してVプロセスに当てはめることが重要だと思います。
※なんでもファーストステップは、書き出して行動することです。

実際に具体的にVプロセスを書き出すことによって、実戦に即した有効なV＆V、インターフェース管理ができるようになると思います。

今では、Vプロセスは古い、スピードに対応できないと言われることもありますが、私の感じところはVのカタチを真似ただけで肝心なV&V、インターフェース管理をやってないだけな気がします。

また次々と新たなビジネスモデルがどんどん出てきますが、私が見た感じでは基本はVプロセスとSEの概念に見えるのでいつの時代でもVプロセスとSEの理解と実戦は重要だと思います。

次にVプロセスと共通技術プロセス・SEエンジンです。

Vプロセスと共通技術プロセス・SEエンジンで最も重要なのが横断的なプロセスである技術管理プロセスです。

この技術管理プロセスがしっかり機能しないとSEを導入しても効果が十分ではないことが多いと思います。司令塔がしっかり動かないと各システム設計プロセス、製品実現プロセスをどれだけ頑張っても全体としてはあまり意味がないので注意が必要です。

この司令塔の役割である技術管理プロセスの導入、確立が成功の大きなキーになると思います。

最後に反復的かつ再帰的にプロセスについてです。

本記事で最も重要なのが反復的かつ再帰的にプロセスを実施することです。

これがSEのプロセスの大きな核のひとつになります。ここまでいろいろと細かく多くのことを説明してきましたが、この反復的かつ再帰的なプロセスだけを導入しても効果がかなり出ると思います。

共通技術プロセス・SEエンジンの内容が踏襲できなくても、反復的かつ再帰的にプロセスをやるだけでも十分な効果を発揮することが多いと思います。

個人的には、最小の変更で効果を最大に発揮するなら、従来の実務プロセスを役割別に再整理し、SEの検証(Verification)と妥当性確認(Validation)、インタフェース管理、反復的かつ再帰的なプロセスの確立が落とし処な気がします。
※導入者やコンサルの腕の見せ所は、従来の実務プロセスとSEプロセスの融合。もし良かったら気軽に私にご相談ください。

以上、SEエンジンとVプロセスの徹底解説― 分解と統合から導くV字モデル、V&V、反復・再帰の原理でした。

次回はライフサイクルを解説します。

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

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