ISC322 ソフトウェア開発
水曜 5-6-7限 15:25–19:30 ／ I-212 ／ 担当 太田啓路（ohtak@icu.ac.jp）
つくりたいものを、実現する方法論
プログラミングは 2 割 — 残り 8 割を学ぶ
AI が分解し、あなたが判断し、仲間が確かめる
よく使うリンク
授業の概要
ソフトウェア開発を題材に、「つくりたいものを、他の人と協力して実現する」ための方法論を学びます。
実際のシステム開発でプログラミングが占めるのは2割程度。残りの8割——目的を決め、作業に分解し、計画し、失敗に備え、小さく試し、使う人の目で見て、確かめて、届ける——が主題です。
題材はアプリでなくても構いません。卒論・就活・学園祭・展示・事業、「実現したいこと」なら何でも。毎回の実習で自分のプロジェクトを育て、最後は 3 人チームで制作・発表し、フィードバックを受けて直します。
授業時間
水 5-6-7限
15:25–19:30（6限後半〜7限は実習）
評価
出席 50%／課題 50%
詳しくは「評価と課題」
使う AI
Claude・Gemini（無料）
課金は不要
連絡・提出
Moodle
出席・コメントシート・課題
授業のルール
出席
出席は、コメントシートとは別に、Moodle の出席機能で取ります。授業時間内に、各自で登録してください。
コメントシート
- 毎回、授業時間内に Moodle へ提出します（最後の 10 分を取ります）。やむを得ず退出する場合は当日 24:00 まで。
- 「授業を受けたことが分かる」内容を書いてください。コメントは次回シェアし、質問には次回答えます。
- 共有したくない部分は、
//共有なし 文章 //のように囲んでください。 - 初回（9/16）は、自己紹介と「つくりたいもの・プロジェクトにしたいもの」を書いてもらいます。
授業を欠席した場合（欠席レポート）
資料（この HTML 資料＋補講ビデオ）を読んで欠席レポートを提出すると、その回の出席点の8割で出席とみなします。
忌引き・教育実習の場合は、レポートを出せば10割とします。
| 分量 | 締切 | 提出先 |
|---|---|---|
| A4 2枚（3コマ分） | 授業日の1週間後 24:00 | Moodle「欠席レポート」（コメントシートとは別） |
レポートに書くこと
- 欠席した授業の日付
- 授業内容の要約（資料を読み、その回の要点を自分の言葉で）
- いちばん印象に残った事例・名言と、その理由
- 自分のプロジェクトにどう活かすか
- 疑問点や、太田への質問
上の 5 点に加えて、その回の実習を自分でやった成果物（9/16 なら自分のプロジェクトの WBS）を添えてください。実習が主役の授業なので、成果物なしのレポートは出席の代わりになりません。
AI 利用の約束（シラバス §13）
- 提出物は、自分で説明できるように理解する努力をする（分からない部分は調べる・AI に聞き直す・人に聞く）
- AI に任せた部分と、自分が判断した部分を提出時に明示する
- AI 生成物は出発点。レビュー・検証・改善は提出者の責任
- 個人情報・機密・第三者の著作物をプロンプトに入れない
評価と課題
| 区分 | 割合 | 中身 |
|---|---|---|
| 出席 | 50% | Moodle の出席＋毎回のコメントシート（欠席レポートの扱いは「授業のルール」） |
| 課題 | 50% | 課題1 計画書 15%／課題2 MVP・KPI・受入条件 15%／課題3 WS 成果物 8%＋最終レポート 12% |
| 課題 | 出題 → 締切 | 提出物 |
|---|---|---|
| 課題1 | 9/16 → 10/7 24:00 | 今日と同じスプレッドシート 1 本にまとめる（新しく作らず育てる）: 前提（最初の一歩を含む）／WBS（担当＝人・AI 支援・確認者／完了条件／待ち時間）／ガント（Mermaid か日付列）／リスク登録票（9/23 で作る）／最初の一歩を実際にやった記録／AI 利用ログ |
| 課題2 | 9/30 → 10/13 24:00 | MVP 定義＋KPI ツリー＋受入条件 2 本 |
| 課題3 | 10/28 → 11/4 | チーム制作物＋仕様＋AI／人間の分担＋検証ログ |
| 最終レポート | 11/4 → 11/18 24:00 | A4 2枚: 初期計画 → 受けたフィードバック → 採否の理由 → 直した結果と再検証 → 卒論・就活等への応用 |
テスト・期末試験はありません。授業外学習の目安は週 225 分。課題は日本語・英語どちらでも可。行数の多さや AI の使用量ではなく、「自分で判断した跡」と「検証の証拠」を評価します。
用意するもの（すべて無料）
- ノートPC（毎回の実習で使います）とスマートフォン
- Claude（claude.ai）— メールアドレスで無料登録。Settings › Capabilities で「Code execution and file creation」を ON にすると表や図（Artifacts）が使えます
- Gemini（gemini.google.com）— Google アカウントで即時。Claude の上限に達したときの切替先
- Google アカウント（スプレッドシートで WBS を提出します）
| サービス | 無料でできること（2026-09-16 確認） | 上限 |
|---|---|---|
| Claude（無料） | チャット・コード生成・表や図の生成（Artifacts）・Projects 5 個・ファイル添付 | 5 時間ごとにリセットされる回数上限（数は非公表） |
| Gemini（無料） | チャット・Canvas・画像生成・Deep Research | 5 時間ごと＋週の上限。添付は 32k トークンまで |
| ChatGPT（無料・参考） | 文章・表・Mermaid のテキスト。データ分析・画像・Canvas は別枠の上限 | ガントを画像や xlsx で出させると途中で止まることがある |
授業の成果物は Markdown の表と Mermaid のテキスト（mermaid.live で描画・登録不要）に固定します。どのサービスでも無料で出せる形です。Copilot・Cursor・Claude Code などは紹介はしますが、提出物の前提にはしません。
スケジュール（9/16〜11/4・毎週水曜 5-6-7限）
| 日付 | テーマ | 実習（6限後半＋7限） | 課題 |
|---|---|---|---|
| 9/9 | 休講 | ||
| 9/16 | ガイダンス＋作業分解（WBS） 資料 | 自分のプロジェクトの WBS を AI と作り、検証する | 課題1 出題 |
| 9/23 | リスク管理 （祝日ですが授業を行います） | 自分の WBS にリスク登録票・プランB → 計画を直す | |
| 9/30 | MVP・KGI/KPI・再計画 — 小さく素早く始める | 自分のプロジェクトの MVP と KPI ツリー | 課題2 出題 |
| 10/7 | UX/UI | 紙スケッチ → AI で画面案 → 相互批評 | 課題1 締切 10/7 |
| 10/14 | テスト・デバッグ | 受入条件を書き、AI が作ったテストをレビュー | 課題2 締切 10/13 |
| 10/21 | モデリング（仕様＝完成の条件）＋チーム結成 | 3 人チームで課題 → CANVAS → 仕様 v0 | WS 準備 |
| 10/28 | ワークショップ：制作・発表 | 3 限まるごと制作、最後に発表（1 チーム 6 分） | 課題3 出題 |
| 11/4 | 成果物の評価・フィードバック | 相互試用 → 改善 → 再検証 | 最終レポート 締切 11/18 |
日程は変わることがあります。確定版は毎回、授業内とこのページで案内します。
資料一覧
| 日付 | 資料 | 内容 |
|---|---|---|
| 9/16（水） | ガイダンス＋作業分解（WBS） PDF | 授業の位置づけ・スケジュール・ルール・無料 AI・名言集・WBS の 3 ルール・太田流 AI で WBS を作る・実習の手順とプロンプト |
| — | 過年度の受講生が作った WBS（参考事例） | 2020 年度〜の 10 件（卒論・アプリ・就活・試験・新聞・進路）。太田コメント付き。xlsx |
| — | WBS 提出シート（Google スプレッドシート） | 実習・課題1 の提出先。テンプレのシートを自分のドライブにコピーして書き、「リンクを知っている全員が閲覧可」にして共有シートの自分の行に URL を貼る |
| — | WBS テンプレ 2026（xlsx） | WBS／記入例／Mermaid／手分解メモ の 4 シート（上のシートが開けないとき用） |
| — | 欠陥入り練習 WBS／保存済み AI 初稿（卒論の例） | 実習の配布物 |
これからの回の資料は、授業の前後にここと左のメニューに追加します。
名言集（出典が確かなものだけ・各回の冒頭で 1 つずつ）
"Adding manpower to a late software project makes it later." — 遅れているソフトウェア開発に人を足すと、さらに遅れる。
Fred Brooks, The Mythical Man-Month (1975)
"There is no single development … which by itself promises even one order-of-magnitude improvement." — 銀の弾丸はない。
Fred Brooks, "No Silver Bullet", IEEE Computer (1987)
"Program testing can be used to show the presence of bugs, but never to show their absence!" — テストでバグの存在は示せるが、不在は示せない。
Edsger Dijkstra, Notes on Structured Programming, EWD249 (1969)
"The price of reliability is the pursuit of the utmost simplicity." — 信頼性の代価は、極限までの単純さの追求。
C.A.R. Hoare, Turing Award Lecture "The Emperor's Old Clothes" (1980)
"premature optimization is the root of all evil." — 早すぎる最適化は諸悪の根源。
Donald Knuth, Computing Surveys 6(4) (1974)
"Beware of bugs in the above code; I have only proved it correct, not tried it." — 正しいと証明しただけで、試してはいない。
Donald Knuth (1977)
"There was no choice but to be pioneers; no time to be beginners." — 先駆者になるしかなかった。初心者でいる時間はなかった。
Margaret Hamilton, WIRED (2015)
"It's easier to ask forgiveness than it is to get permission." — 許可を取るより、あとで許してもらう方が簡単だ。
Grace Hopper, Chips Ahoy (1986)
"Optimism is an occupational hazard of programming: feedback is the treatment." — 楽観はプログラマの職業病。治療法はフィードバック。
Kent Beck, Extreme Programming Explained (1999)
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — 人間に分かるコードを書くのが良いプログラマ。
Martin Fowler, Refactoring (1999)
"Talk is cheap. Show me the code." — 口先はいい。コードを見せろ。
Linus Torvalds, LKML (2000-08-25)
"You can't trust code that you did not totally create yourself." — 自分で全部作ったのではないコードは信用できない。
Ken Thompson, "Reflections on Trusting Trust", Turing Award Lecture (1984)
"We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change." — まず、難しい設計判断・後で変わりそうな設計判断を列挙せよ。
David Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules" (1972)
出典が揺れるもの（「Make it work, make it right, make it fast」「LOC で進捗を測るのは飛行機を重さで測るようなもの」など）は載せていません。
補講ビデオ（9/9 休講分）
休講した 1 回分は、補講ビデオの紹介で補います。テーマと公開日は後日このページと Moodle で案内します。視聴したら、次回のコメントシートに一言書いてください（出席点には入りません）。
候補: ツール群の実践（Trello・マインドマップ・Mermaid gantt・Claude/Gemini の使い方・「1 文でアプリを作る」デモ）ほか。
連絡先
太田啓路（情報科学メジャー）— ohtak@icu.ac.jp
質問はコメントシートかメールで受け付けます。欠席の連絡もメールへ。