授業の形態
|
|
講義、演習又は実験、実習、実務経験講師
|
| |
|
アクティブラーニング
|
|
学生が議論する、学生が自身の考えを発表する、フィールドワークなど学生が体験的に学ぶ、学生が文献や資料を調べる
|
| |
|
授業内容と方法
|
【授業内容】
本演習は、アントレプレナーシップ演習（前期前半・第1クォーター）で合意したバトンパス文書（核心問い・制約地図・MVP構想・ステークホルダーマップ）を起点に、それを工学的に実現するプロセスを実践する場である。
本演習の中核は仮説の検証である。MVP（Minimum Viable Product）仮説を「検証可能な形」に変換し、各自の専門性を活かして実装・検証するプロセスがシステムエンジニアリングの本質である。
本演習は、機械工学・エネルギー環境・建築・社会基盤・電気電子・知能情報の大学院生が混成チームを編成する。プログラミング能力の有無を問わない。各自の専門ツール（Matlab・Rhino・Python・Unity・Excel・Arduino等）やバイブコーディングを活用して「MVP仮説を最小限で検証できる形」を作ることを目的とする。
情報科学は「他分野の専門知識を接続し、計算・シミュレーション・可視化・最適化によって仮説を検証可能な形にする媒介」として位置づける。建築の学生が実際に家を建てる必要がないように、情報科学系の学生も完成したシステムを一人で作る必要はない。それぞれの専門が「計算・シミュレーション・可視化・最適化」という形で他分野の知識に乗っかり、統合する——このプロセス自体がシステムエンジニアリングである。
例えば、社会基盤系の学生が「津波シミュレーションによるセメント配合の最適化」を問いとして持つなら、情報科学系の学生が数値計算を担当し、材料・構造の専門知識がパラメータを定義し、建築系の学生が施工制約を与える。「誰の専門性がどこで機能するか」を設計し統合することがシステムエンジニアリングの核心である。
授業の全体構造はVモデル（要求定義→設計→実装→Verification→Validation）に基づく。ただし15回の演習を通じてアジャイル的に反復・改善することも許容する。学習の起点は「翻訳」である——アントレ演習のバトンパス文書（問いの言語）をSE演習の入力（工学の言語）へ変換する作業が第1フェーズの核心となる。対応関係は次の通りである。核心問い（HMW文）→機能要件、制約条件の地図→非機能要件・制約条件、MVP構想→アーキテクチャの初期仮説、ステークホルダーマップ→利害関係者要求。
【授業方法】
本授業は対面で実施する。
各回は概念インプット（座学）とチーム演習の組み合わせで構成する。
第12回はフィールドワーク（当事者へのValidation）を実施する。
進捗は毎回の開発記録シートに記録しWebClassを通じて提出する。
第8回に設計レビュー（中間発表・ポスター形式）、第14回にハッカソン（当事者へ届ける）を行う。
実務家教員は、実践・ブレスト・演習場面のファシリテーターおよびアドバイザーとして機能する。
具体的には、チームの設計判断に対して「現場ではどう見えるか」「この前提は実際に成立するか」「こういう事例がある」という実務の文脈を提供する。
特に、設計・実装・Validationの実践フェーズにおいて、学生の設計判断への即時フィードバックが重要な学習機会となる。
本演習では、VerificationとValidationを明確に区別して学ぶ。
- Verification（検証）は「作ったものが設計仕様を満たしているか」
- Validation（妥当性確認）は「それが当事者の問いに答えられているか」
この区別は、エンジニアが「動く」と「役に立つ」を混同しないための根本的な思考様式である。
|
| |
|
URGCC学習教育目標
|
|
自律性、社会性、地域・国際性、コミュニケーション・スキル、情報リテラシー、問題解決力、専門性
|
| |
|
達成目標
|
本演習終了時に、学生は以下のことができるようになることを目標とする。
①【翻訳と要求定義】
アントレ演習で合意した核心問い・MVP構想を工学言語（機能要件・非機能要件・制約条件・性能指標）に翻訳し、「何をもって仮説検証成功とするか」の指標を設定できる。
②【アーキテクチャ設計と役割分担】
混成チームの専門性を活かしたサブシステム分解を行い、インターフェース（何のパラメータを・どんな形で・隣のサブシステムに渡すか）を設計・合意できる。とりわけ情報科学の役割（計算・シミュレーション・可視化・最適化のいずれか）を明示的に設計できる。
③【実装と設計根拠の言語化】
自身の専門ツール（Matlab・Rhino・Python・Unity・Excel・Arduino等）またはバイブコーディングを活用して担当サブシステムを実装し、「なぜそのツール・手法を選んだか」を設計根拠として言語化できる。
④【Verification & Validation】
「設計通りに動いているか（Verification）」と「当事者の問いに答えられているか（Validation）」を区別して実施し、Validationを通じた問い直しを次の設計へ反映できる。
⑤【統合と発信】
サブシステムを統合し、当事者・外部ゲストに対してハッカソン形式でデモ発表を行い、「MVP仮説の検証結果と次の問い」を根拠をもって発信できる。
|
| |
|
評価基準と評価方法
|
評価の基本方針：完成したシステムの機能数や技術的複雑さではなく、仮説検証のプロセスと設計根拠の言語化を評価する。「プログラミングができるか」を評価しない。評価の主体は学生間の相互評価であり、教員評価はその補完とする。
評価区分と配分
①座学成果（開発記録＋要求定義書＋検証記録） 40%
以下の3要素で構成する。開発記録シート（全14回・毎回授業後WebClass提出）：「今回の設計判断・詰まった点・次の行動」を100字以内で記述。評価観点：設計思考の変化が具体的に記述されているか／詰まりの原因を設計の問題として捉えているか。要求定義書（第4回提出）：教員提供の標準テンプレートに基づき作成。評価観点：翻訳の精度／性能指標の明示（「何をもって成功とするか」）／役割分担と情報科学の位置づけ。実装・検証記録（第11回提出）：V&V実施の記録。評価観点：VerificationとValidationの区別／設計修正プロセスの記録
②中間発表・設計レビュー（第8回） 25%
ポスター式同時展示（全チーム同時，30〜40分）。学生間SQG相互評価（15%）＋教員評価（10%）。学生間相互評価をメインとする。評価観点：設計根拠の言語化／アーキテクチャの整合性（誰の専門性がどこで機能するか）／仮説と検証手段の対応／分析・可視化の設計
③ハッカソン・最終発表（第14回） 25%
ライトニングトーク（3分）＋デモセッション（巡回形式）。学生間SQG相互評価（15%）＋教員評価（10%）。学生間相互評価をメインとする。評価観点：仮説の検証結果の鮮明さ／分析・可視化の「当事者への意味ある提示」／Validationから得た問い直しの言語化／バトンパス文書との対応（問いが深まったか）
④個人評価 10%
チーム内の相互評価（ピア評価）とグループワークへの貢献度で評価する。各メンバーが他メンバーに対して「①最も貢献したこと、②自分が最も学んだこと（相手から）」を記述するピア評価シートを第14回終了後に提出。評価観点：専門性を活かした貢献の具体性／チーム協働への主体的関与
合計：100%
補足
・ハッカソンおよび中間発表への参加は評価の前提条件であるが、参加そのものを点数化しない
・SQGフォーマット（相互評価）はアントレ演習と同じ形式を継続する（Strengths・Growth・Questions）
・要求定義書は教員が標準テンプレートを提供する。テンプレートの様式に沿って記述し、様式に含まれない必要備考を学生側で追記できるかを評価の観点の一つとする
・学生間相互評価の記述品質（SQGフォーマットに則り根拠をもって書けているか）自体も評価対象となる
|
| |
|
履修条件
|
|
アントレプレナーシップ演習を事前に履修していること。
|
| |
|
授業計画
|
▶ Vモデル構造：要求定義（第1〜4回）→ 設計（第5〜8回）→ 実装・検証（第9〜12回）→ 統合・発信（第13〜15回）
▶ アントレ演習との接続：バトンパス文書（核心問い・制約地図・MVP構想）を起点とする
▶ ツールの多様性：Matlab・Rhino・Python・Unity・Excel・Arduino・バイブコーディング等、専門性に応じて選択する
▶ 実務家教員（兼村 光・PRATAP ALOK）：全15回参加。実践・演習場面のファシリテーターおよびアドバイザーとして機能する
第1回 ガイダンス ＋ バトンパス文書の受け取り ＋ 当事者への再接続計画
アントレ演習のバトンパス文書を受け取る。SE演習の設計哲学「術→技」を確認する。アントレ演習第9回で接触した当事者がいる場合、SE演習でも会いに行くことを確認し、連絡・アポイントの計画を立てる。実務家教員：バトンパス文書を実務の視点から読み、「現場で何が問われているか」をコメントする
第2回 SE概念の座学①——Vモデルとは何か
座学：Vモデルの全体構造（要求定義→設計→実装→Verification→Validation）。なぜ上流の判断が下流を決めるか。VerificationとValidationの違い——「動く」と「役に立つ」は別の問いである。ソフトウェア工学を専門としない学生にとって必要な最低限のSE概念を習得する
第3回 SE概念の座学② ＋ 翻訳演習——アントレ語をSE語へ
座学：機能要件・非機能要件・制約条件の三層構造。性能指標とは何か（「何をもって成功とするか」を数値や基準で示すこと）。実習：バトンパス文書の「核心問い」を機能要件の文に書き換える翻訳演習。実務家教員：「この要件の書き方では現場で通じない」「この制約は見落としがち」というリアルな指摘をファシリテーションに交える
第4回 アーキテクチャ設計——専門性の地図を描く
サブシステム分解と役割分担の初期合意。インターフェース定義：「何のパラメータを・どんな形で・隣のサブシステムに渡すか」を言語化する。情報科学の役割（計算・シミュレーション・可視化・最適化のいずれか）を明示的に設計する。実務家教員：役割分担の設計に対して「この分担は現場でうまくいくか」を問いかける。要求定義書（教員提供テンプレートを使用）提出。なお、第12回フィールドワークの実施に向け、倫理審査の必要性を確認し、必要な場合は本回までに担当教員へ連絡すること（アントレ演習段階での申請を推奨）
第5回 サブシステム設計——各専門が自分のパートを設計する
各自が担当サブシステムの設計を行う。ツールの選定（Matlab・Unity・Python・Rhino・Excel等）とその選択根拠を言語化する——「なぜこのツールか」を説明できることがSE的思考。プログラミングができない学生は「何を計算させたいか・何を見せたいか」を言語化し、情報科学系メンバーに渡す設計をする。実務家教員：ツール選択の相談に乗り、過去の事例を提供する
第6回 分析設計と意味ある可視化
「分析」とは仮説と結果を接続する行為である。感度分析（どのパラメータが結果を最も左右するか）の考え方。「意味ある可視化」とは何か——「当事者が見て判断できる提示形式」を設計する。Excelによる分析・可視化も立派な成果である。各チームが分析設計書（何を分析するか・どう見せるか・当事者に何を判断してもらうか）を作成する。実務家教員：「この可視化で当事者は何を判断できるか」をファシリテーションの軸に置く
第7回 設計統合——サブシステムをつなぐ
各チームが設計書を持ち寄り、インターフェースの整合性を確認する。「Aが渡す値の単位・型・範囲はBの入力と合っているか」を対話で確認する。ここで出てくる「つながらない」「前提が違う」「単位が合わない」が、設計の最も重要な学習場面。実務家教員：「こういうインターフェースの不整合は現場でよく起きる」という文脈で学習を支援する
第8回 中間発表——設計レビュー（ポスター形式）
全チーム同時展示（30〜40分）。ポスター必須要素：①要求定義書、②アーキテクチャ図（専門性の分担が見えること）、③分析設計書（何を・どう見せるか）、④MVP仮説と検証方法の明示。相互評価はSQGフォーマット（Google Form）で随時記入・提出。学生間相互評価をメインとする。実務家教員：全ポスターを巡回し、実務の観点からフィードバックを提供する
第9回 実装①——各専門ツールで動かし始める
「最初の1つのパラメータが動いたら成功」という最小単位を決めて着手する。詰まった場所を記録することが重要（設計の甘さが見える）。情報科学系メンバーが他専門の「計算してほしいこと・見せたいこと」を受け取り、コーディング・バイブコーディングで実装する。実務家教員：チームを巡回し、詰まりに対して「こういう方法もある」という選択肢を提示する
第10回 実装②——つなぐ・壊す・直す
サブシステム間のインターフェースを実際につなぐ。「設計時に合意したはずの値が合わない」「単位が違う」「前提条件が違った」などの問題が出る。これがVerificationの素材。実装の詰まりをチームで共有し、設計の修正点を明確にする。実務家教員：「こういう失敗は現場でも同じ」という実務文脈で問題を相対化し、修正判断をサポートする
第11回 Verification——設計通りに動いているか
Verification（設計仕様を満たしているか）とValidation（当事者の問いに答えられるか）を区別する。チームごとにVerificationチェックリストで自己点検。「動いていない部分」の設計上の原因を特定し、次回のフィールド持参に向けて調整する。実務家教員：「これは現場に持っていける状態か」の実務基準でチェックフィードバックを行う。実装・検証記録 提出
第12回 Validation——当事者に「作ったもの」を持っていく（フィールドワーク）
アントレ演習第9回で接触した当事者がいる場合、同じ当事者に再訪する。フレーム：「前回お話を聞かせていただいた問いに対して、これを作りました」。「これはあなたの問いに答えられていますか」「どこが違いますか」「この前提は正しいですか」を問う。「前回と今回で何が変わったか」を当事者の言葉で記録することが最重要。当事者との接触がなかったチームは、ステークホルダーマップをもとに新たな当事者を設定してValidationを実施する。実務家教員：フィールドワークに同行し、当事者との対話のファシリテーションを担う
第13回 統合・整合——全体を一つにする
各サブシステムを統合し、チームとして一つの「動くもの」にする。ハッカソンで当事者に届けられる状態に整える。プレゼンテーション設計：「何を・誰に・どう見せるか」を決める。実務家教員：「これを初めて見る当事者が理解できるか」の観点でリハーサルフィードバックを行う
第14回 ハッカソン——動くものを当事者に届ける
前半・ライトニングトーク（各チーム3分）
——「核心問い・仮説・何で検証したか・Validationから得た問い直し」を宣言する。
後半・デモセッション（巡回形式・40分）
——当事者・外部ゲスト・他チームが実際に触れる・見る・問う。
SQGフォーマット（Google Form）で相互評価を記入・提出。学生間相互評価をメインとする。
外部ゲスト招待の有無は運営状況に応じてオープンとする。
実務家教員・教員による総評（10分）
第15回 振り返り ＋ 研究・社会実装へのバトン
ピア評価シート記入・提出（個人評価用）。
自己評価レポート作成（50分）——「術（アントレ）→ 技（SE）の変化」と「最も設計判断が変わった瞬間」を記述する。
全体共有（30分）——各チームが「設計が最も変わった瞬間」を発表。
実務家教員：「現場エンジニアとして、この演習に参加して何を感じたか」を最後に議論する
|
| |
|
事前学習
|
各回の授業前に、前回の開発記録シートを見直し、担当サブシステムの設計・実装に関連する情報を30分程度調査すること。特に次の回は追加的な事前準備が必要である。
・第1回前：アントレ演習のバトンパス文書（核心問い・制約地図・MVP構想・ステークホルダーマップ）を再読し、「工学的手段で何が実現できそうか」を考えておくこと。
アントレ演習第9回で当事者と接触した場合は、その連絡先を確認しておくこと
・第4回前：要求定義書（初稿）を作成してくること。
教員から提供されるテンプレートに基づく
・第8回前：ポスターを作成してくること（メディアについては、講義中に指示）。
必須要素：要求定義書・アーキテクチャ図・分析設計書・MVP仮説と検証方法の明示
・第12回前：アントレ演習で当事者と接触した場合は、当事者へのアポイント取得を行うこと。
見せるもの（シミュレーション・モックアップ・可視化ダッシュボード等）の準備を完成させておくこと（目安：2時間）。
「前回のやりとりの何を踏まえてこれを作ったか」を当事者に説明できるよう準備する
・第14回前：ライトニングトーク用スライド（1〜2枚）とデモ（動く状態）を完成させてくること（3分厳守）
|
| |
|
事後学習
|
各回の授業後に、開発記録シートをWebClassへ提出すること（100字以内、目安：10分）。
記述内容：「今回の設計判断・詰まった点・次の行動」を具体的に記述する（出席の確認ではなく、内容の品質で評価される）。
特に次の回は追加的な事後学習が求められる。
・第12回後（必須・重要）：当事者へのValidation記録を「見せた内容・当事者の反応・問い直された仮説」の3層で整理し、第13回の統合方針として文書化すること（目安：2時間）。
とりわけ「アントレ演習時の当事者の発言と、今回の反応の違い」を明記すること
|
| |
|
教科書にかかわる情報
|
|
|
| |
|
教科書全体備考
|
|
授業で配布する資料・設計書テンプレート（要求定義書・アーキテクチャ図・分析設計書・Verificationチェックリスト・ピア評価シート）を教材として使用する。
|
| |
|
参考書にかかわる情報
|
|
|
4873115914
|
The Lean series
|
|
アッシュ・マウリャ著 ; 角征典訳
|
|
オライリー・ジャパン
|
2012
|
|
|
|
4798163686
|
|
|
西村直人, 永瀬美穂, 吉羽龍太郎著
|
|
翔泳社
|
2020
|
|
|
|
476490506X
|
HCDライブラリー, 第0巻
|
|
山崎和彦, 松原幸行, 竹内公啓著 ; 黒須正明 [ほか] 編
|
|
[近代科学社]
|
2016
|
|
|
|
4274066983
|
|
|
Esther Derby, Diana Larsen著 ; 角征典訳
|
|
オーム社
|
2007
|
|
|
|
| |
|
参考書全体備考
|
|
各テーマ毎に指示する。
|
| |
|
使用言語
|
|
日本語
|
| |
|
メッセージ
|
この授業は「完璧なシステムを作る」授業ではなく、「仮説を手で確かめ続ける」授業です。
プログラミングができなくても、設計はできます。「何を計算させたいか」「どのパラメータを変えると何が変わるか」「その結果を当事者にどう見せれば判断できるか」を言語化する力こそが、システムエンジニアリングの核心です。建築・社会基盤・機械・エネルギー環境・電気電子の専門知識は、情報科学と組み合わさることで初めて検証可能な形になります。情報科学は道具であり、皆さんの専門知識こそが問いの本体です。
「設計通りに動かない」「前提が違った」「当事者の反応が想定外だった」——これらはすべて、問いの解像度が上がったサインです。
本授業では、語句の意味確認や一般的知識の調査など、開発記録シートの本文等の解答生成に当たらない範囲での生成AIの参考利用を認める。提出物の本文の生成を目的とした使用は認めない。利用した場合、明確な説明ができることを確認する。
|
| |
|
オフィスアワー
|
|
教員の業務都合によって調整する可能性があるため、事前にメールでアポイントすること。
|
| |
|
メールアドレス
|
|
この項目は教務情報システムにログイン後、表示されます。
|
| |
|
URL
|
|
|
| |
|
|