テーマ：「システムズエンジニアリングを駆動する力～複雑性への対応～」
・・・ 佐藤 健司 （檜垣造船株式会社）
プロジェクトは、その複雑さと境界の曖昧さによって成功の不確実性が増す中、新しいプラットフォームを活用した革新的なイノベーションによって、業界の地図が大きく塗り替えられてきています。また、多様な技術領域が交錯する中、これまでの画一的な取り組みではプロジェクトの成功を収めることがますます難しくなっています。こうした状況下で革新的なビジネスモデルを実現し、企業の成長をリードするためには、既存の安全領域から飛び出し、日々挑戦と成長を目指す人材が欠かせません。
今回、システムズエンジニアリングの知識を駆使し、プロジェクトマネジメントの最前線で活躍するビジネスドライバーとなる人材の育成についての課題と解決策について探り、皆さまと議論できればと考えております。
（Agenda）
第二部 システムズエンジニアリング
・その意味（前回）
・駆動する力（今回）
・規範的な力
・ディシプリン
・適用の滞り
・コンテクストの理解
・その意思決定
前回は、「第2部 システムズエンジニアリング ： 1．その意味」 について議論しました。
今回は、「第2部 システムズエンジニアリング ： 2．駆動する力」 について議論します。
システムズエンジニアリング適用を駆動する力（ドライバー）として、組織の内部・外部の要因やニーズについて議論をすすめていきます。
＜事前配布資料＞ by佐藤さん
＜佐藤さん講話内容＞
ノート形式で、＜講話内容＞が記述されています
＜質疑内容＞
後半のフリーディスカッション内容が再現されています 文責：岩下
・レーシングカーの設計をシステム化しようと試みていたとき、難しかったことは、「クルマが走る、あるいはクルマを速く走らせるとは、そもそもどういうことなのか」という、根源的な問題が、実は自分でも分かっていなかったということでした。
レーシングカー自体は、物理法則に基づいてモデル化することはできます。しかし、ドライバーが、レーシングカーを実際に操作し、周回ごとにめまぐるしく変化する条件に合わせながら、最終的な結果を目指して、最適な走り方をどのように選択しているのかが分からなかったのです。
最初は「ドライバーを含めてモデル化すれば答えが出るはずだ」と考えて取り組みましたが、複雑すぎてなかなかうまくいかない。モデルを理解できたとしても、今度は現実どおりにコントロールができないという問題が起こります。
ところが、人間を実際のループに入れると、その複雑なことがコントロールできてしまう現実がある。実際のレーシングドライバーは、シミュレーションよりも速いラップタイムで走っているという事実があるのです。「一体これは何なのだ？」というところが、非常に大きなテーマとして浮かび上がりました。
システムズエンジニアというのは、実際に起こっていることや実在するものを、ある形でルール化して、それを論理的に「どうすべきか」を考える仕事だと私は概念的に捉えています。ただし、人間をシステムに組み込む必要がある場合、人間は単純にモデル化できない部分があり、それが後々大きな問題につながるのではないかと、今日のお話を聞いていて、直感的にそう感じました。
また、システムを要素へ細分化していっても、要素間のつながりから予期せぬ創発特性が生じ、複雑さが増してしまう話もありました。細分化を繰り返し、精度を上げていくといっても、最終的には行き詰まってしまうことがあります。そこで、もう一つ挙がったのが「抽象化」という考え方でした。
わたしにとって抽象化は、「シンプルにする、どんな状況でも通用するような普遍的な原則や根本を見つけ出しておけば、応用をいくら重ねても大枠は揺るがない」というイメージです。
この二つのアプローチ「細分化」と「抽象化」のあいだで頭の中がぐるぐるしていて、まだ答えを出せていません。
細分化と抽象化は、一見すると互換性がなさそうですし、真逆からのアプローチだけに、いろいろ混ざるとコンフリクトを起こしそうな気もします。それをどう整理して、相互に補完し合えるのかがわかれば、ぐっと視界が開けるのではないかと考えています。
特に会社のようなシステムの合併では、人間が入っている複数の要素を統合しようとするので、難しさが増します。先ほどのお話しにあった企業文化や価値観、そして暗黙の領域について、これらを全てマニュアル化して整理することは簡単ではありません。しかし、そうした部分まで含めて統合を進めないと、独自性のある強い経営は実現できない、というのが経験的に言われていることです。
細かくルール化して、ディシプリン（規律）という形で厳密に定めていく方法もあるでしょう。しかし、企業統合の過程において、「プリンシプル（原則）」はどうなっているのか、という疑問が必然的に出てきます。「そもそもの大原則は何なのか、それがきちんと共有できているのか」という点こそが本質的に重要です。そこをもう少し踏み込んで、より深く理解したい、そんなことを考えながら聞いていました。
⇒カルビンフレームワークの中で、混沌としている状況から、複雑な状況に変える手法として、要素を細分化し、細かくしていくアプローチもあるとお話しました。しかし、単純に要素を分解しても、全体像をつかむことはできません。そこで重要なの
が、要素同士のつながりや関係性を捉えることです。「木を見て森を見る」という言葉があるように、全体を俯瞰しながら、新たな視点を加え、要素と要素とを繋げていく作業が必要です。このプロセスは、システムズエンジニアリングの基本的な考え方であり、部分と全体を行ったり来たりしながら進めていくことが求められます。
考えてみると、実は「混沌とした状態」というのは、実はシステムズエンジニアリングを理解しているからこそ「混沌とした状態」として見えているのではないでしょうか。今の状況が「混沌とした状態」であれば、抽象的に物事を捉え「複雑な状態」にするフェーズでしょうし、「複雑な状態」であれば具体的に要素に分解し「込み入った状態」にするフェーズかもしれません。
システムを抽象化するフェーズなのか、細分化するフェーズなのか、その見極めができれば、最終的にいまの状態をどう収束させ、どう方向づけ、加速させていくのかが、わかると思います。
そういう意味で、システム化の困難さというのは、今の状態の認識とその状態への対処にあるのではないかと感じます。問題の対象領域を解きほぐす筋道を自分なりに見えているかどうかが大事だと思うのです。たとえば「細分化」といっても、「どこまで細分化するのが有効で、どこで止めるか」という問題もあります。「ある程度までは有効だけど、それ以上やっても無駄」というラインがあります。だからむやみに細かく分けるのではなく、あるところで区切りをつけ、実際にやってみて理解を深めるということは、プロジェクトにおいてはかなり重要だと思います。
・それ以前に「ここまで理解できていて、どこが理解できていないのか」を把握するプロセスが欠かせません。この認識プロセスがないと「とりあえず全部試してみよう」となってしまい、手間ばかりかかって大変なことになります。
細分化や積み上げ式の構造理解といった作業は、コンピューターのほうが得意になりつつあります。
統計的なアプローチ（帰納法的なアプローチ）であれば、ChatGPTのようなAIがある程度のパターンを示せます。でも人間には「概念化」や「抽象化」で一気に飛躍する力がありますから、統計的に割り出された答えを見ても直感的に「何かちがうよな」と気づくことができます。そこは機械とは違うところです。
人間は類似点を見つけて、関係ないと思っていたものから新しい発見や応用を生み出すこともできます。それは人間ならではの強みだと思います。ただ、その一方で機械に任せられるところはどんどん任せたほうが、人間の得意な部分を最大限に活かせるという意見もあって、そこの“役割分担”をどう決めるかが一番大事なのかなと思います。
理論的に理解する部分と、感覚的に違いを見分けてしまう部分の両方があって、そこでは抽象化が働いているのでしょう。違うものを「似ている」と思って取り違えることもあれば、「似ているのにどこが違うのだろう？」と考えて、まだ見えていない要素（ダークマター）の存在を仮説として思い浮かべる。人間は「存在しないもの」を想像して仮説を立てるのが得意で、そういう部分こそが人間の強みなのかなと思います。
帰納法や演繹法、アブダクション（仮説検証）などもありますね。これらを活用しながら、形式知に表現していくかという部分が重要ではないでしょうか。ビジネスエコシステムの中で、問題の対象領域を共有化していくためには、形式的手法が欠かせません。思考の飛躍や新たな視点を一旦形式知化し、筋道を立てていくことが必要です。このような過程でシステムズエンジニアリングが大きな駆動力となると考えています。
「分ける」という作業自体は、すでに概念化しているのです。実際のものはアナログ的に全部が連続していますが、それを何らかの形で単純化したり、離散化し、分割することで理解しやすくなったり、扱いやすくなったりします。ですが、それで全てが解決するのではなく、必ずデメリットも伴います。取りこぼした部分や、連続的なつながりを無視するのではなく、ちゃんと認識しておく必要があります。
また、大局的に把握するのは大切ですが、対象として優先順位を上げるのか、下げるのかということがポイントになります。そこがすごく興味深くもあり、難しい部分でもあります。
例えば、今は、よくわかっていない部分については、優先度を下げ、いったん留保して検討を進めてみる。ただし、その留保した部分が存在していることを意識し続けることが重要となります。「理解不足の部分は、いつか理解する」ということを、常に意識しておくという感じです。
・先ほどの事例紹介についてですが、ディジタル・ビジネス・エコシステム、ディジタル・エンジニアリング・エコシステムというイメージは、ゴールとしてはそうだろうなと思うのですが、誰がそのエコシステムを実現していくのでしょうか。
プログラムマネージャーのミッションなのか、システムズエンジニアのミッションなのか、プロダクトマネージャーのミッションなのか、誰がその世界を実現する役割を担うのでしょうか。
⇒ディジタル・エンジニアリングを実際どう進めていくかというポイントですが、重要なのは、「コンセプト・オブ・オペレーションズ（Conops：Concept of Operations）」を生み出すプロセスです。Conopsからブループリントをどのように描いていくか、そのブループリントを結果的に関わるみんなが「うんうん」と納得できるようなステークホルダーのバリューネットワークをつくるにはどうしたらいいのか、ということです。
それを実現できるのは、システムズエンジニアリングの視点を持ったエンジニアではないかと思うのです。普通の機器を個別に設計する人でもなく、プロジェクトを管理して進める人でもなく、むしろ全体の構造を捉えて、どういうネットワークや仕組みが必要かを考えられる人だと思います。
そういう人材がどこから出てくるのかは私自身もはっきりとは分かりませんが、「こういう世界観がある」と誰かが思ったときに、自然とハブになる考え方を持った人は出てくるのではないかと思います。なぜならエコシステムは、共同で創りあげ、進めていくものだからです。
誰かが「私がリーダーです！」と旗を振るのではなく、一緒に取り組む中で「あの人が結果的にリーダーだったのかな」という形になっていくものだと思えるのです。だから「誰がやるか」というより、実際にみんなが集まっていくと、自然とそういう仕組みができあがっていくと私は考えています。
⇒デジタル・エンジニアリングの分野では、モデルベースド・システムズエンジニアリング（MBSE）のアプローチをどのように活用するかが課題となります。MBSEのレベルに至っていない段階では、各部門が個別にデータを保持し、それぞれのシステムが独自にインターフェースを持つ「ストーブパイプ型」モデルが一般的です。
この仕組みでは、インターフェースの設計や維持には高いコストがかかり、効率性が損なわれるという課題があります。この課題に対しては、エコシステム内でインターフェースを統合・最適化することで、デジタル・エンジニアリング全体を加速させる新たなアプローチが求められています。ストーブパイプ型モデルと統合型エコシステムとでは、コミュニケーション・コストや手戻りの頻度、各部門間のすり合わせ頻度・速度に大きな差が生じます。だからこそ、システムの切り口や役割分担の決め方が重要となってくるのです。
・思考の飛躍という意味では、人間はパターンを組み合わせたり、全然違うところにパターンを見いだしたり、あるいはあえて「間違った」解釈をして新しいアイデアを出したり、そういう「非連続的」な力を持っています。これはAI的な思考とは違う人間ならではの能力なのだと思います。
全体性という観点で考えると、プログラムの「全体性」とかをいろいろ話し合ってはいますが、結局のところ「エコシステム」まで視野を広げないと本当の全体性とは言えないのではないかと思います。そのエコシステムの視点が私たちの議論の中に出てこないし、ガイドブックにも入っていない。そうなると、どうしても部分の話だけになっている、と改めて感じています。
⇒エコシステムを考えるときは、やはり自然界から学ぶしかないと思います。アブラムシやテントウムシ、アリ、ハチ、花などが、どうやって共進化や共生をしているのか、それをビジネス・エコシステムとしてイメージしたときに、「ハチは誰が担当する？ 花は誰が担当する？ アリやテントウムシは誰が担当する？」といった役割分担を想定することで、ビジネス・エコシステムは、作られるのではないでしょうか。
そう考えられる人たちが、どこから資金を調達してリソースを得るか、どのように構想を作り上げていくか、そこには何かしらのパターンがあるはずなのです。だからこそ、エコシステムという言葉が広く使われていて、それは自然界をはじめ、いろんなところからそのパターンを見つけ出し、自己組織化できる仕組みを作り上げようとしているのではないかと思うのです。少し抽象的になってしまいましたが、イメージとしてはそんな感じですね。
・以前「編集工学研究所」で、編集を勉強したことがあります。そこで学んだことに、論理だけでは伝えきれないことを「たとえ」を使って説明することの大切さがあります。なぜ「たとえ」を使うかというと、概念を共有しやすくするためなのです。理屈だけでは表現しきれない、あるいは分析しきれない部分も「たとえ」を使うと人間はパッと理解できる。そんな感覚があるのです。
先ほどのエコシステムの事例でも、組織と人体の類似性があるなと感じました。たとえば、組織の「骨格」が歪んでいると、「筋肉系」が緊張してストレスがあちこちに溜まり、動きが悪くなって可動域が狭くなる。それが血流の悪化、つまりお金が回らなくなる状態を生み出して、いくら資金を投じても届かない。さらに、情報系は神経系のようなもので、圧迫されると鈍くなったり、誤作動を起こしたりします。だからこそ、まずは「構造」をしっかり整えないと、どんなにお金をかけても改善しない、ということをある組織改革の場面で目にしたのです。組織改革の例をとっても、自分の身体にたとえてみると、意外に分かりやすい。そういう「たとえ」をうまく使って、組織や個人の能力を高めることに応用できないかな、と思っています。
⇒ある会計事務所の創立者が「会社というのは法人格と呼ばれるくらいだから、人間のように人格を持っているものだ」というたとえをしていました。まさにその通りだと思いますし、さきほどのお話もとても納得できるものです。
イエス・キリストも聖書の中でよくたとえを用いて説明しますが、その理由は、世の中の人々が聞く耳を持たないからと説明しています。そんな聞く耳を持たない人たちに対して、どうやって伝えていくかが重要だったのです。そのために、たとえや物語を使うことが必要なのです。
PMAJでも「物語」という形でいろいろなことを伝えています。物語もまた、抽象的なことをよりわかりやすく伝えるための大切な手段です。共感を得ながら理解してもらうには、たとえや物語といった具体的なイメージが必要なのだとあらためて感じました。
・「システムがうまく機能しない4つの要因」は、ビジネスを進めるうえで起こる問題をまとめていると思いますが、実際のところ、それだけに限らず、さまざまな要因でシステムが途中でうまくいかなくなることがあります。システムがうまく機能しない要因をビジネスシステム全体の話としてとらえ、何か問題が起こったときには早めに元に戻して、また回せるようにする仕組みが必要だと思います。そういう部分をシステムズエンジニアリングの考え方でうまくサポートしてほしい、というのが私の要望です。
具体例として、昔勤めていた会社では、電話交換機を作っていました。交換機の国際システムに関する製品計画を3年ぐらいかけて練るという仕事だったのです。交換機は船の例に近く、動きが比較的読めるので「先読みができる」世界でした。ですから、あらかじめ問題を分析し、「システムがうまく機能しない4つの要因」にも陥らないように設計や製品を作りこむことが比較的やりやすかったのですね。
ところが、ビッグローブ（BIGLOBE）のようにインターネットのサービスでは、12カ月かけて開発し、いざ売り出したと思ったら、3日で「もう売れなくなった」というような事態が起こることもあります。3カ月かけて作ったサービスが3日でダメになるわけですから、次の手を同時並行で常に用意しておかないといけなくなる。先読みが効く製品と、先読みが効かないサービスでは、当然アプローチが変わってきます。
システムズエンジニアリングの考え方の中で、こういう「先が読める場合」と「先が読めない場合」の違いをどう扱えばいいのか、そして「システムがうまく機能しない4つの要因」を回避するためにできることは何なのか、こういったことを教えてもらえたらと思います。
⇒先ほどご紹介した「DevOps」（少しずつリリースしては運用し、また開発に戻るというアジャイル的な作り方）が、今のトレンドであり成功事例になっているのではないかと感じます。
サービス開発においては、先が見えない中で大きく投資してしまうよりも、少し作っては軌道修正し、また少し作っては軌道修正するという形でピボット（方向転換）を重ね、最適な方向を定めていく方が効率的だからです。開発段階から運用を視野に入れ、運用チームと一緒になって作っていき、リリース後すぐに運用側に引き渡してフィードバックを得る。運用からのフィードバックをさらに開発に反映して、どんどん広げていく。そうした流れが必要だと考えています。
ビッグローブの例で「3か月かけて作ったものが3日で売れなくなってしまった」という話がありました。そのとき、3日で売れなくなったという事実をどうやって開発チームにフィードバックし、それを次の開発に活かす仕組みをつくるのか。つまり、意思決定の中に「運用で得たフィードバックをどのように取り込むか」を常に組み込んでおかないと、外部からの情報をうまく活用できない開発になってしまうと思うのです。そのためには、意思決定プロセスの中に、実行（オペレーション）を踏まえた視点を組み込んで開発を進める必要があります。単にモノを作るだけでなく、運用からのフィードバックを受け取り、それを次の開発に反映する体制を整えておくことが、今求められている開発スタイルだと思います。
・3日ほどで「これはダメだ」とわかる部分はあるのですが、長く使ってみるとわかってもらえる部分もあります。たとえば、日産やホンダのように、電気自動車とエンジン自動車、電気製品とエンジン製品の「いいとこ取り」をしようとすると、CO₂排出の問題をはじめ、小さな話から大きな話まで、さまざまな論点が出てきます。そうしたなかで「作る」「売る」「環境を守る」という要素が一体となって動くのは、なかなか難しいように思いますが、システムエンジニアリングという考え方を勉強してみると、なるほど原則はこうなっているのか、と理解できて、とてもありがたく感じました。
⇒さまざまな知識を持つ人が集まるとき、同じプラットフォーム上で話をしないと十分な共有や議論ができないことがあります。その点で、フレームワークは重要なツールだと思います。
・自分の感じていることですが、システムというものは基本的にうまくいかないものだと割り切っています。そもそも、仕事が複雑になればなるほど、多くの人がついていけなくなるものだと思っています。お話の中にも、「混沌」という言葉がありました。私はそうした「混沌」を無理に解明しようとはせず、むしろ「混沌は混沌のままでいい」と割り切っています。
ただし、複雑なものでも、関係性だけははっきりさせておかないと現場は動きません。関係性を明確にすることが重要だと思います。その関係性も時間が経つにつれて変化します。最初に想定していた強弱や太さが変わっていくので、末端の人たちの捉え方も全く違ってきます。結果的に、どうやっても完全にうまくいくことはありません。だから、失敗が当たり前の世界だと思えば、誰かを恨むことも少なくなります。恨みが連鎖して怒りが広がると、最終的には皆が黙り込んでしまい、さらに複雑な状況に陥ります。
それは非常に人間臭い世界です。だからこそ、リーダーもメンバーも、人間性や力量が必要になってきます。怒らず、憎しみを抱かせずに仕事を進めることが、複雑な問題を少しでも見えやすくする鍵だと思います。そういう人間臭くて泥臭い世界で、私はこれまで生きてきたと感じています。
・システムズエンジニアリングが基礎であるという話がありました。この基礎をしっかり学ぶことが大事だと思います。現在の社会では、誰がどのようにこうした知識を学び、理解を深めていくべきなのでしょうか。特に、学生や若い世代だけでなく、その他の年齢層にも重要だと思います。今日の会のような場は非常に良い機会ですが、こうした場をどのように設けていくべきでしょうか。例えば企業では講義や勉強会が開催されている例はあるのでしょうか。また、現在の状況について、進んでいる部分や課題があれば教えてください。
⇒現在、産官学が連携して取り組みを進めています。例えば、産業界からはモデリングツールの提供が行われています。一方、政府は国策として、特定分野の知識や技術を確保することに力を入れています。たとえば、船舶関連では、さまざまな機械や知識をしっかりと保持・発展させる必要があります。これは、日本が海に囲まれ、物流の約99%以上を海運に依存しているため、国力を維持する観点からも重要です。
船舶の製造現場では、限られた人材で新しい環境やルールの変化に対応する必要があります。そのため、産官学のグループが集まり、システムズエンジニアリングという知識体系をどう身につけるかを模索しています。現在、海事分野ではアメリカの教育機関を通じて知識や技術を学び、それを日本にフィードバックする形が取られています。国内では、慶應義塾大学のSDM（システムデザインマネジメント）など、限られた機関でしか学ぶ機会がないため、世界的なネットワークを活用し、リモート学習の環境も整えつつあります。このようにして、日本の技術や知識体系をさらに広げていく取り組みが進められています。
・プロジェクトマネジメントやプログラムマネジメントといった分野についてですが、現在、これらを専門とするシステムエンジニアがまだそれほど多くないように思います。例えば、IT系以外の分野で「システムズエンジニア」と名刺に書かれるような人も、まだあまり見かけません。こうした専門性を持つ人が増えていくことが、これからの社会にとって重要だと感じます。より多くの人がプロジェクトマネジメントやプログラムマネジメントを活用し、広範な分野で貢献していけるようになると良いですね。
⇒ここ数年で、日本でもシステムズエンジニアリングの資格取得者が徐々に増えてきています。PMP資格が広まり始めたのは、今から30年以上前のことです。当時は、主に海外で資格を取得するケースが多く、そこで得た知識やスキルを活かして日本でも活動してきた方々がいらっしゃいました。現在の「システムズエンジニアリング」の資格も、アメリカなど海外で取得し、その経験を日本でどう活用するかを模索している状況だと言えます。
・大学の講義では、システムエンジニアリングの基礎がしっかりと学べ、考え方の一つのヒントとして、自分のものにしていくことが大切だと感じました。自分の中に取り込み、自分の思考力の中に深めていくことで、より応用できるようになるのではないかと思います。これからもより多くの人がこの考え方を学び、活用していく必要があると感じました。ちなみにそのINCOSEの資格体系とはどういうものでしょうか？
⇒Systems Engineering Professional (SEP) 認定は、システムズエンジニアリングの知識を開発し実践へ適用するキャリアを通じた進化を正式に認定します。INCOSEは、ASEP、CSEP、ESEP の 3 つのレベルの認定を提供しています。
アソシエイトシステムズエンジニアリングプロフェッショナル（ASEP）：システムズエンジニアリングの実務を始めたばかりの方、またはこれから実務を始めたいと思っている方には、ASEP が最適です。この認定資格は、システムズエンジニアとしてのキャリアを始めたばかりの方を対象としています。ASEP は「書籍による知識」はあるけれども、システムズエンジニアとしての経験はまだ豊富ではない方向きです
サーティファイドシステムズエンジニアリングプロフェッショナル（CSEP）：システムズエンジニアリングの専門的な職務経験が 5 年以上ある現役のシステムズエンジニアであれば、CSEP が最適です。（学位の種類によっては、5年のSE職務経験以外に、要求される年数のエンジニアリング職務経験が必要になります。）エキスパートシステムズエンジニアリングプロフェッショナル（ESEP）：認められたシステムの実績を持ち、長年のシステムズエンジニアリング専門職の経験を持つシステムズエンジニアリング リーダーであれば、ESEP が最適です。
https://www.incose.org/certification
最近、SEPの話がかなり活発になってきて、ボランティアとして情報を広めようとする人たちが日本でも増えてきています。ワークショップや情報交流会、メーリングリストなどが次々に生まれてきているので、これからさらに広がっていくのではないかと感じています。
・システムズエンジニアリングの話を聞くと、自分の視野が広がる感じがいつもします。これまでは部分的な問題ばかりに集中し、その部分を一生懸命に解決しようとしていました。しかし、システムズエンジニアリングについて話を聞くと、全体を俯瞰する重要性に気づきます。例えば、これまで解決できなかった課題が、意外な部分に影響を与えていることが分かります。それを発見することで、問題解決へのアプローチが変わることがあります。
皆さんの質問やコメントから、フィードバックの仕組みやタイミングが重要だと感じました。適切なタイミングで適切なフィードバックを得るために、システムエンジニアは全体を俯瞰して仕組みを作る必要があると感じています。システムズエンジニアリングでは、一つの解決策が全体の問題を一気に解決する「テコの原理」のような考え方もあります。実際に、そういった事例は存在するのでしょうか？
⇒システムズエンジニアリングにおいて、レバレッジポイントを見つけて成功した事例があります。具体的な事例は、先ほどご紹介したVモデルやWモデルを活用した事例となります。
フィードバックのタイミングをどのように設定するか、という点に関しては、例えば最初に要求を作成する際に、フィードバックをしっかりと行うことが重要です。要求を作成した時点で、運用をしっかり理解し、運用においてバリデーション（妥当性
確認）ができるようなプロセスを組み込むことです。そして、その実世界をモデル化したリファレンスを準備し、それを仕組みとして組み込むことで、徐々に実行段階へと移行できるようにする必要があります。
これまで戦闘機の開発では、1機あたり10年以上かかっていましたが、近年の事例ではボーイングが構想から初飛行までわずか３年で実現したというものがあります。このような情報がもっと身近にあると、非常に刺激的になると思いますが、私自身具体的な成功事例を持ち合わせていないのが少し残念です。
・初めての参加ですが、皆さんの質疑応答を聞いていて、とても勉強になると感じています。認識されにくい複雑性をどう解決するかという点で、ここに示されているカルビンフレームワークが有効なツールの一つであると理解してもよろしいでしょうか。これを実行するフェーズはどこに位置するものなのか、少し疑問があります。これは、構想や計画の段階で行うものなのでしょうか？
⇒複雑性を理解するというフレームは、あまりなく、今のところはカルビンフレームワークが有効なのかなと感じています。
複雑性に対して、いつ、どう対処していくのかとなると、早い段階から始めた方が良いでしょう。最初の段階から、「どのようにリスクを抑え込んでいくのか」、という視点が重要だと思います。しかし、日本の社会の中で、リスクマネジメントやリスクについての話はよくされるものの、システム開発の中で想定されるリスクや複雑性について、「どのようにそのリスクや複雑性が顕在化するのか」、というメカニズムについて十分に話し合っている人たちはあまりいないと思います。
このような話をする人たちは、多分、宇宙開発の安全システムを見ているような人たちや、そういった専門的な立場にいる人たちぐらいではないかと思います。ですので、専門家や現場の利用者、運用する人などがこの段階で参加し、議論を重ねていくことで最終的に行動に繋がる、というプロセスがあります。このプロセスがいわゆるPoC（Proof of Concept）に当たるのでしょう。
次回は、そろそろ具体的に、こういうことをすると、うまくいくよというようなところも、ご紹介できればと思います。事例も含めて、そのツールも実際に使ってみるとか、そういったところをできたらなと思います。
以上
今後も「プロジェクト SE 懇談会」というタイトルで、議論を継続する予定です
2ヶ月に 1 回程度で開催していきたいと考えています。ご参加をお待ちしています！
＜注＞
資料は改訂される可能性がありますのでご了承ください。