システムデザインマネジメントを皆で学ぼう！

 （ご紹介） 2026年1月23日（金）新春PMセミナー2026 の基調講演にて慶應義塾大学大学院　当麻教授より、「モデリングシュミレーションを活用したこれからのプロジェクトデザインの提案」のご講演がありました。属人的なモデルではなく、システムズエンジニアリングを活用したディジタルでのプロジェクトモデルを使って、計画段階でシュミレーション効果を得るという貴重な事例紹介でした。このようなシステムズエンジニアリングの事例が拡大しています。ミッションエンジニアリングにも通じる内容だと思います。 （Systems Approachの勉強会にご関心がある人がおられましたら、ご連絡ください。）

  コンピテンシー（力）の獲得から、システムズエンジニアリングを理解するアプローチ システムズエンジニアリングを学ぶには、システムズエンジニアリング演習（芝刈り機演習、カレーライス演習、ヘルスケア事業開発演習、サービスロボット事業開発演習等）を最初に体験することが効果的です。それまで、耳にすることがなかった、「ライフサイクル」や「コンテクスト分析」、「ユースケース分析」、「機能のふるまい」、「物理の振る舞い」、「検証」など未知の演習体験ばかりです。できれば10〜20回くらいはやりましょう。なぜなら、形式知から暗黙知に変わる時間は、単なる回数✖️時間に比例するのではなく、対数時間に比例することが認知心理学（出典1）からも指摘されています。 第2ステップは、自分が解きたい衝動に駆られている「自分のモヤモヤ課題」をシステムズエンジニアリング演習の手順に従って、自分で格闘しながら、自らが新しい思考世界に入り込んで解いていくという体験が重要に思います。それによって、自分の課題解決にシステムズエンジニアリングは、「あのような形で有効なんだ」という貴重な実感が得られるからです。 第3ステップは、システムズエンジニアリングの方法論をより理解するために有効な方法があります。それは、スキル、コンピテンシーを高めていく方法です。Systems Engineering Competency Framework （出典2、出典3）やSystems Engineering Competency Framework Guide（出典4）が水先案内人になります。 指導者がいなくても、ひるむ必要はありません。 友人達とチームを組んで、チャレンジしていきましょう。 Systems Engineering Competency Frameworkのコンピテンシーエリアに記載されている項目をお互いに質問し合って、それに対する回答を皆で、知恵を絞って言葉に表す練習を開始してください。コンピテンシー記述自体が抽象度が高いのですが、こういう意味ではないかという説明を通じて、自己理解やイメージ（暗黙知表現、形式知表現）の確認をしていきましょう。 ＜コンピテンシー指標やサブ指標を言葉で説明する＞ 「〜〜が重要な理由を説明しましょう」 「〜〜を定義しましょう」 「〜〜をもう少し異なった視点で説明しましょう」 ...

  　　　　　　　シュナイダーのスマートファクトリーって知ってましたか？？ 　　　　　　　下記のYoutubeの20分以降から、フランスのシュナイダーの 　　　　　　　スマートファクトリーの実態が公開されています。 　　　　　　　2023年ガードナーのサプライチェーンのトップ企業です。 　　　 　　　　　　　 シュナイダーのフランス工場の紹介YOUTUBE 　　 　　　　　　　1. リーン方式を中核において改善を進めている 　　　　　　　　（27分35秒の開始・分析・実行・確認・集結のプロセス） 　　　　　　　　（書籍「トヨタ生産方式」大野耐一氏）                   　  　  2.世界の工場が同一の仕組みで動いている 　　　　　　　 　　　　　　　　（32分35秒の受注動態と生産動態の同期化） 　　　　　　　3.生産全体の指標化とコンサルテーションを実施 　　　　　　　　これをリーン方式で改善し、サイバーセキュリティまで 　　　　　　　　完全実施している 　　　　　　　　（34分23秒の生産全体の指標化のみどり色のチャート図）                     　   このようなデジタル化は経営トップが推進しているが、 　　　　　　　背後に業務のシステムモデリング化が必要なのは明らかであり、 　　　　　　　情報システム部門以外の現場のリテラシーの高さが必要である。                                                                2024.12.5

  　　☞　 モデルベースシステムズエンジニアリング導入の手引き 　　　出典：IPA独立行政法人　情報処理推進機構 　　　執筆：慶應義塾大学大学院システムデザイン・マネジメント研究科　西村秀和教授 　　　　　　株式会社会社　コギとマキナ代表取締役　鈴木尚志氏 　　　 　　　　DX時代、I Tエンジニアが花形の現代ですが、ITシステム開発やソフトウエア 　　　　開発現場は、決して楽観できる状態では無いように思います。本資料を読み返す 　　　　のはこれで10回目ですが、自分が未だ実践できていないことを反省する毎日です。 　　　　最前線でご多忙な管理者の皆様にも、お手隙の時間に本資料を閲覧いただき 　　　　その有用性について、お考えいただくきっかけになればと存じます。 　　　　本文35頁              モデルの実行や、ツールにあるシュミレーション機能は、開発の上流工程の  　　　　作業において、要求の妥当性確認や、それに対応する設計の検証を、開発の  　　　　実機テスト工程まで待たずに、モデルで確認可能とするものです。 　　　　これによって、手戻りを激減させ、大幅な開発コスト削減も可能になるのです。 　　　　本文41頁 　　　　MBSEのプロセスは、効率的なシステム開発を支援することを目的とし、 　　　　モデルを利用して、要求をまとめ、それを実現するアーキテクチャを設計します。 　 　　　　本文44 　　　　図22に示される通り、MBSEはソフトウエアエンジニアリングのみならず、 　　　　ハードウエアエンジニアやテスターに対しても大きな一助になったという評価が  　　　  得られています。                本文47            MBSEを適用し、これまでの文書ベースによるシステムズエンジニアリングの 　　　 効率について測定し、コスト評価を行いました。その結果、コスト効果という 　　　 側面に加えて、設計情報をほぼ完全に記述可能で、必要な情報を容易に抽出可能 　　　という理由から・・...

　 思考力を高めるステップアップコーチ9  　　未知の問題、不良定義の問題をイノベーティブに考える方法を学ぶために大学院に 　　行きました。しかし、シニア世代の私が、2013年からシステムアプローチを学び 　　始めたのですが、思考が動かず大変苦労しました。所属企業で30年間もかけて 　　蓄積してきた思考は、思えば先輩たちが構築してきた解決策を当たり前のように 　　引き継ぎ、そのまま丸呑みしてきたのかもしれません。 　　ここ10年間、どう成長したかをうまく説明できない私は、いつもピカピカの 　　修士一年生当時（2013年）から、現在状況の2点を無理やり比較しては、 　　考え方や世界観の違いの中に、私の成長があったのではないかと考えることに  　 しています。 　（1）自分がそもそも問題をどう解決してきたのか？ 　　思えばNEC時代に5つの難題プロジェクトに出会ってきました。悪戦苦闘してもがいて 　　はまっていくことも多かったです。自分がどう問題を定義しているか、うまく説明でき 　　ませんでした。今でもうまくは言えません。しかし大学院の門を叩いてから、五輪書の 　　ようなものを学び続けたおかげで、思考スタンスは変わっています。何のために問題を 　　解こうとしているのか、目的を言語化する習慣がつきました。パワーポイントで資料を 　　書きまくる前に、自分はどのようにして、その問題を解決しようとしているのかを  　 問います。 適切な扱い方とは、効果的なアプローチに思いを馳せる習慣が生まれている 　　ように思います。 　　・無意識下で考えていることを意識の上に引き出して叩く 　　・意識してやってきた事実を帰納化して、どこかで使えるように無意識下に刻む 　（2）メンタルモデルの壁 　　新しい思考の枠組みを考えているときに、以前から持っている思考の枠組みが 　　どうも邪魔をするようです。楽観的に解空間を探索しましょうと言われても、戦略的 　　な探索経験の無い私には、無駄に思えて気がのりませんでした。失敗することの 　　面白さやゆらぎを忘れていたのでしょう。極めつけは、そもそも物理空間に生きてきた 　　人間が抽象の空間を活用することの意味すら知らなかったのですから・・。 　　授業についていけない私は、そもそもエンジニアリングとは離れた「考える」ことに 　...

 思考力を高めるステップアップコーチ8 　出典： もはや「インプットでは差がつかない時代」なのに…残念なビジネスマンが 　　　　ハマる「網羅思考のワナ」 　　　　 https://gendai.media/articles/-/112273?imp=0 　　内田 和成氏の論考では、 網羅思考のワナに、ハマらないために、 　　何をしたらいいと言っているのでしょうか？ 　 　  「 本当に優れたリーダーとは「限られた情報で決断を下す能力」を磨いています。 　　調べすぎて「too late」にならないためにも、、、、    　 従来の常識である「インプット→アウトプット」というプロセスを、 　「アウトプット→インプット」に逆転させる必要があるとしています。 　 　　ここでいうアウトプットとは、単なるレポート、成果物だけではありません。 　　それは一部である。大切なのは、求められている「仕事の目的」です。 　　それを深く考え明確にした上で、 限られた情報の中で、「仕事の目的」に見合った 　「成果物（手段）」を考え出すこと、まさに「考える」プロセスがアウトプットの 　　質を決めるとしていています。「 アウトプット思考」の大切さを解いています。 　　私が、慶應SDMで学んだシステムアプローチは、まさにゴール（運用ステージ） 　　で達成すべき状態からデザインすることを指導しています。その仮説的なゴール 　　状態を要求定義として抽出する手法や、その具体策を考えるという手法を使いながら 　　アウトプットから考える思考を学びました。 　　学びはじめた当初、ゴールイメージとはそもそも抽象度が高い対象にも関わらず、 　　抽象も具体も区別がつなかい「具体の思考の世界」に住んでいた私は大変苦労 　　しました。「考える」プロセスそのものがわからない、集めた情報では足らない 　　中で、「わからない」ことを明確にして、知り得ている既知の知識を帰納化したり 　　演繹化したり、アイデアをずらしてみては俯瞰してみたり、近傍の解を探してみたり 　　するという、しぶとさを方法論を使う中で感覚的身につけてきました。道半ばです 　　が、システムアプローチのメタ方法論の凄さは実感しています。 　　アウトプット思考 　　ゴールから発想する 　　 　　完全にできるわけでは...