20261008_エンジニア勉強会

2026年10月8日に実施したエンジニア向けの社内勉強会の発表資料です。

Transcript

1. ソフトウェア⼯学の基礎で掴む勘所 エージェントのコード、どこを見る？ 2026.10.08 v12 ©Algomatic 1
2. はじめに 自己紹介 2023年4⽉〜（前職） 2025年10⽉〜 AIエンジニア yuu.f @yuufdev github.com/fyuuki0jp 好きなこと AI（LLM∕Diffusion Model）、TypeScript、クラウド、ネイティブアプリ開発 新しい技術を、⼿を動かして追うのが好きです 普段はゲームをして過ごしています。 AI時代のソフトウェア⼯学 勉強会 ©Algomatic 2
3. はじめに 勉強会のモチベーション 01 02 03 気楽に聞く 質問はいつでも 手を挙げてみる カジュアルな会です。メモも取らなく 途中でも⼝頭でどうぞ。最後に Q&A の ときどき挙⼿をお願いします。正解は1 て⼤丈夫 時間もあります つではありません AI時代のソフトウェア⼯学 勉強会 ©Algomatic 3
4. ⽬次 01 はじめに：いま起きていること 02 1つのPRで、兆候を探す 03 振り返って、仕組みにつなぐ 04 まとめ Content AI時代のソフトウェア⼯学 勉強会 05 Q&A ©Algomatic 4
5. 今⽇の登場⼈物 ソフトウェア工学をつくった人たちの言葉を借りる どれも数⼗年前の⾔葉。エージェントの PR を読むときにも、そのまま使える PZ Edsger W. Dijkstra David L. Parnas オランダの計算機科学者 ソフトウェア⼯学の研究者 最短経路のアルゴリズム 1972年の論⽂で、モジュールの 構造化プログラミングを提唱 分け⽅を⽰した 情報隠蔽の考え⽅を広めた 1972年 チューリング賞 Martin Fowler、Kent Beck MJ Pamela Zave、Michael Jackson ソフトウェア開発者、著者 ⼿書きの⼩論 EWD を残した 要求⼯学の研究者 Fowler：『Refactoring』の著者 Zave：AT&T の研究所で研究 Beck：XP とテスト駆動開発を広 Jackson：JSP の考案者 めた 2⼈ともアジャイルソフトウェア 1997年、要求と前提の関係を整 理 開発宣⾔の起草者 写真：Wikimedia Commons（切り抜き）。Dijkstra∕Hamilton Richards, CC BY-SA 3.0 Oshineye, CC BY 2.0 David L. Parnas∕Hubert Baumeister, CC BY-SA 3.0 Martin Fowler∕Ade Kent Beck∕Mulling it Over, CC BY-SA 2.0。Zave、Jackson は写真なし AI時代のソフトウェア⼯学 勉強会 ©Algomatic 5
6. はじめに 引っかかったまま、Approve していない？ 動作確認と CI で分かるのは、壊れていないことだけ。設計や要求のずれを指摘するには、⾔葉がいる Open feat: 開始24時間を切っても取り消せるようにする エージェントが作成 34ファイル +412 架空の例 −388 すべてのチェックに成功しました Approve Request changes でも、⾔葉にならない レビューする⼈の頭の中 「なんか変」 「この仕様で合ってる？」 「同じの、前にも⾒た気がする」 「この処理、ここに書くもの？」 「変更範囲、⼤きくない？」 なんとなく Approve する か、「なんか変なので見直し て」とだけ返す AI時代のソフトウェア⼯学 勉強会 ©Algomatic 6
7. はじめに コードの大半を、エージェントが書き始めている 数字の定義は会社ごとに違う。⽐べるより、向きを⾒てほしい 75% 80%超 100万件超 Google の新規コードのう Anthropic でマージされる GitHub Copilot のエージェン ち、AIが⽣成しエンジニアが コードのうち、Claude が書 トが作ったPR（2025年5〜9 承認した割合（2026年4⽉） いた割合（2026年5⽉） ⽉） AI時代のソフトウェア⼯学 勉強会 90% AIを使う開発者の割合 （DORA 2025） ©Algomatic 7
8. はじめに エージェントが書く量に、人のレビューが追いつかない 全部は読めない。だから私たちは、⾒る場所を絞り、引っかかった所を短く正確に返す必要がある 5件に1件超 GitHub のコードレビューのうち、エー ジェントが関わっているもの（2026年5 ⽉） AI時代のソフトウェア⼯学 勉強会 45.7% AIの出⼒の正確さを、信頼していない開 発者（Stack Overflow 2025） 8倍 Anthropic のエンジニアが1⽇にマージす るコード量（2024年⽐。⾏数なので過⼤ 評価とも注記） ©Algomatic 8
9. はじめに 1968年、作るソフトウェアに人の手が追いつかなくなった 計算機の進歩に、作り⽅が追いつかなかった。その危機感から、ソフトウェア⼯学が始まった 1960年代 その結果 1968年10月 計算機が急に速くなった 作るほうが追いつかない NATO 会議（西ドイツ、 1台で多くの仕事をこなせるようになり、⼤ ⼤きな開発が遅れ、予算を超え、品質が出 Garmisch） きな OS や業務システムが求められた（IBM なかった。OS/360 の開発は、のちに 研究者と実務家が集まり、作り⽅を⼯学と System/360、1964） Brooks が『⼈⽉の神話』で振り返った して議論した。会議名の「ソフトウェア⼯ 学」は、あえて挑発的に選んだ⾔葉 出典：Naur & Randell 編 NATO 会議報告（1969）、Brooks『⼈⽉の神話』（1975）。1968年を「ソフトウェア危機」の起点とする説明には、歴史家から異論もある （Haigh） AI時代のソフトウェア⼯学 勉強会 ©Algomatic 9
10. はじめに 58年前のエンジニアも、同じことで困っていた 作る量に⼈が追いつかない問題も、⾔葉が曖昧で伝わらない問題も、ソフトウェア⼯学はすでに経験している 1968 2026 NATO 会議 作り⽅が、計算機の進歩に追いつかない 作る量に、人の手が追いつかない 計算機が⼤きいほど、プログラミングも⼤問題に 量 （EWD340） 自然言語で書けば楽、は誤り 必要なのは、曖昧さの少ない正確な⾔葉（EWD667） ⾔葉 エージェントが書く ⼈より、エージェントが多く書く 書く量に、人のレビューが追いつかない コードの⼤半をエージェントが書き、読む⼈の時間は増えない 指示は、自然言語で書いている 曖昧なところは、エージェントがそれっぽく埋める 写真：Edsger W. Dijkstra（Hamilton Richards 撮影、2002、CC BY-SA 3.0、Wikimedia Commons、円形に切り抜き） AI時代のソフトウェア⼯学 勉強会 ©Algomatic 10
11. はじめに ソフトウェア工学は、2つの方向で答えてきた 読む側は違和感に名前をつけ、作る側は構造で防いできた 今⽇はこっち 今⽇は最後に少しだけ 「なんか変」に、名前をつける 構造で、防ぐ 読む側 → 勘所を掴む 作る側 → アーキテクチャで⾒なくて済むようにする 引っかかった所を、名前で⾔えるようになる 境界、型、テスト、lint で守って、読む量そのものを減らす 例：Code Smell（Fowler と Beck、1999） 例：「業務のルールは決済SDKを import しない」を lint で守る なぜ勘所から：仕組みを作るにも、どこが危ないかを知っている必要がある それに、勘所は明⽇のレビューからすぐ使える AI時代のソフトウェア⼯学 勉強会 ©Algomatic 11
12. はじめに 構造で防ぐ話は、この登壇資料で深掘りできる 今⽇は読む側に絞る。作る側を知りたい⼈は、あとでこの3本を読んでほしい ミノ駆動 ミノ駆動 t-wada（和⽥卓⼈） 「設計次第でAIコードの読む量は 「目的で駆動する、AI時代のアー 「予防に勝る防御なし（2025年 減らせる」 キテクチャ設計」 版）」 今こそ聞きたいソフトウェア設計 #2 アーキテクチャConference 2025（2025-11） PHPカンファレンス福岡2025（2025-11） （2026-09） ⽬的からモジュールを分けて、変更しやすく 誤りを後で⾒つけるより、起きにくい設計に 契約、副作⽤の隔離、抽象化で、読む量を する する 減らす speakerdeck.com/twada/ speakerdeck.com/minodr speakerdeck.com/minodr growing-reliable-code- iven/designing-for-cod iven/purpose-driven-ar php-conference-fukuoka e-reading chitecture -2025 AI時代のソフトウェア⼯学 勉強会 ©Algomatic 12
13. 名前をつけた⼈ Fowler と Beck は、「なんか変」を Code Smell と呼んだ Martin Fowler、Kent Beck 1999 『Refactoring』第3章「Bad Smells in Code」。直し⽅は第2版（2018）の名前 表に出る兆候に名前をつけ、効きそうなリファクタリングを添えた 1つの場所が、別々の理由で変 Divergent Change わる 同じ知識が、複数の場所にある Duplicated Code Shotgun Surgery 1つの変更で、あちこち直す → フェーズの分離 → 関数の抽出 → 関数の移動 今⽇のゴール 「なんか変なので直して」ではなく、どこが、なぜ気になり、どう直してほしいかを、名前を 使って伝えられるようになる 写真（Wikimedia Commons、切り抜き）：Martin Fowler∕Ade Oshineye, CC BY 2.0 AI時代のソフトウェア⼯学 勉強会 Kent Beck∕Mulling it Over, CC BY-SA 2.0 ©Algomatic 13
14. Code Smell Fowler と Beck は、24種類の Code Smell を挙げている 全部を覚える必要はない。今⽇の題材で出てくるのは、⾚の4つ 肥大化 Bloaters Long Function Large Class Long Parameter List 変更を妨げる Change Preventers なくてよいもの Dispensables Divergent Change Duplicated Code Shotgun Surgery Data Clumps Speculative Generality Primitive Obsession Data Class Lazy Element Comments 結合しすぎ Couplers オブジェクト指向の誤用 OO Abusers その他（第2版で追加など） Others Feature Envy Insider Trading Repeated Switches Mysterious Name Middle Man Refused Bequest Message Chains Temporary Field Mutable Data Global Data Loops Alternative Classes with Different Interfaces ⾚：今⽇の題材で出てくるもの。分類は Mäntylä ほか（2003）の5分類を参考に、第2版の名前に合わせた AI時代のソフトウェア⼯学 勉強会 ©Algomatic 14
15. ⽬次 01 はじめに：いま起きていること 02 1つのPRで、兆候を探す 03 振り返って、仕組みにつなぐ 04 まとめ Content AI時代のソフトウェア⼯学 勉強会 05 Q&A ©Algomatic 15
16. 今⽇の題材 教室予約サービスに、CS から Issue が1つ届いた 参加者が予約し、主催者が教室を開き、決済サービスがお⾦を動かす。取消と返⾦は利⽤規約が決めている 参加者 教室予約サービス（架空） 教室を予約する⼈ ヨガや料理の教室。受講料は 6,000円 主催者 教室を開く⼈ 教室と定員を登録する 教室を探して予約する 利⽤規約：取消と返⾦ 受講料を事前に払う ⾏けなくなったら取り消す 中⽌することもある 取消は開始24時間前まで 取り消したら全額返⾦ 主催者都合の中⽌も全額返⾦ 決済サービス 外部 ⽀払いと返⾦を処理する Issue #128 直前に来られなくなった参加者が取り消せず、無断⽋席になる。席をキャンセル待ちの⼈に回したい CS が起票 → 24時間を切っても取り消せるようにしたい。エンジニアがエージェントに渡して、PR が届いた AI時代のソフトウェア⼯学 勉強会 ©Algomatic 16
17. 今⽇の題材 エージェントは、34ファイルの PR を返してきた 動くし、CI も通る。私たちはこの差分を、どこから読めばいいか feat: 開始24時間を切っても取り消せるようにする Files changed 34 +412 −388 ‧ CI 緑 エージェントに渡した指⽰ src/cancel/CancelController.ts +3 −9 「Issue #128 を対応して」 src/cancel/CancelButton.tsx +6 −14 直前に来られなくなった⼈が取り消せず、 src/i18n/ja.json、en.json +8 −8 無断⽋席になる。24時間を切っても取り消 ほか 6 ファイル（取消メールの⽂⾔） +48 −52 せるようにしたい ほか 3 ファイル（FAQ の⽂⾔） +22 −26 test/cancel.test.ts +18 −11 ほか 20 ファイル（スナップショット） +307 −268 AI時代のソフトウェア⼯学 勉強会 ©Algomatic 17
18. 4つの視点 私たちは、まず指示を見て、次にコードを見る 指⽰の抜けは、コードをいくら読んでも⾒つからない。コードの兆候は、Code Smell の名前を⼿がかりに探す コードを見る前：指示と要求 Issue と、エージェントへの指⽰の中にある兆候 1 要求 ⽬的 何のための変更？ コードを見る：Code Smell Fowler と Beck が名前をつけた、コードの兆候 2 アーキテクチャ その判断、どこに置く？ 3 モジュール ルールはまとまってる？ 4 抽象化の判断 どこを抽象化する？ コード AI時代のソフトウェア⼯学 勉強会 ©Algomatic 18
19. 視点 1∕4（コードを⾒る前） 要求：何のための変更？ 足りない前提を Biz に確かめ、指示に書き足す エージェントが期限を消したら、24時間を切った取消も全額返⾦になった。返⾦額は誰も決めていない エージェントの変更 取消の依頼 取り消して、全額を返す 直前でも、全額？ 期限の if ⽂が消えただけ 暗黙の前提 兆候（コードの外：指⽰と要求の中） 書いていない前提に、コードが頼っている 最初の指⽰ ⾜りなかった前提 直した指⽰ 「Issue #128 を対応し 「直前」は開始24時間 「#128 を対応して。開始24 て」。席を空けたい、 を切ってから？ そのと 時間を切ってからの参加者都 だけ きの返⾦は？ Biz の答 合の取消は、返⾦0円（Biz と Issue の「直前」が何時間前か、そのときいくら返すかは、ど えは「0円」 合意済み）」 こにも書いていない ⾃然⾔語の指⽰には、曖昧さが残る。前提を⾔葉にして減らす Edsger W. Dijkstra, EWD667 の要旨 写真：Hamilton Richards, CC BY-SA 3.0 効く原則 1本の「24時間」の線が、取消と返⾦の両⽅を決めていた 返⾦額を決めるのは Biz。エージェントに埋めさせない 要求分析 要求は、仕様と、仕様が頼る前提がそろって満たされる 出典：Pamela Zave、Michael Jackson「Four Dark Corners of Requirements Engineering」（1997） AI時代のソフトウェア⼯学 勉強会 ©Algomatic 19
20. 視点 2∕4（Code Smell） アーキテクチャ：その判断、どこに置く？ エージェントは、画面の入口に返金と決済を詰め込んだ 直した指⽰で、エージェントに出し直してもらった。判断がどこに置かれたかを⾒る Divergent Change CancelController（画⾯の⼊⼝） ⼊⼒を受け取って、結果を返す 画⾯が変わったら 兆候（Fowler & Beck） 1つのモジュールが、別々の理由で何度も変わる 返⾦のルール（24時間） 返⾦の規約が変わったら 画⾯、規約、決済のどれが変わっても、この関数を直す 決済SDKを直接呼ぶ 決済サービスが変わったら 業務のルールが、決済SDKを直接知っている（依存の向きが 逆） 1つの関数が、3つの別々の理由で変わる 効く原則 関心の分離 変わる理由ごとに、別の場所に置く 名付け親：Edsger W. Dijkstra「On the role of scientific thought」（EWD447、1974） AI時代のソフトウェア⼯学 勉強会 写真：Hamilton Richards, CC BY-SA 3.0 ©Algomatic 20
21. 視点 3∕4（Code Smell） モジュール：ルールはまとまってる？ エージェントは、同じ返金ルールを2か所に書いた 取消の処理と返⾦予定額の表⽰が、それぞれ別々にルールを持っている 取消の処理 返⾦予定額の表⽰ 予約を取り消す ⾦額を画⾯に出す Duplicated Code 兆候（Fowler & Beck） 同じ知識が、複数の場所に書かれている 返⾦ルール（24時間） 返⾦ルール（24時間） 返⾦の期限が、取消と表⽰の2か所にある 規約の変更：期限を48時間に どちらも単体では正しく動く。変わるときに、⽚⽅だけ直ると ずれる ⽚⽅だけ直されると、表⽰と実際の返⾦がずれる 効く原則 情報隠蔽 変わりそうな判断を、1か所に隠す 名付け親：David L. Parnas「On the Criteria To Be Used in Decomposing Systems into Modules」（1972） AI時代のソフトウェア⼯学 勉強会 写真：Hubert Baumeister, CC BY-SA 3.0 ©Algomatic 21
22. 視点 4∕4（Code Smell） 抽象化の判断：どこを抽象化する？ エージェントは、変わらない所を抽象化した 変更が広がったのは期限の⾔葉で、34ファイルに散らばった エージェントが抽象化した所 変更が広がった所 返金のルール 「24時間前まで」の期限と文言 RefundRuleEngine CancelButton.tsx RefundRule（interface） i18n ja.json / en.json 登録されたルール：1つ 取消メール 6ファイル FAQ 3ファイル Shotgun Surgery 兆候（Fowler & Beck） 1つの変更のために、あちこちを少しずつ直す 期限の変更が、画⾯、⽂⾔、メール、FAQ に散らばった スナップショット 20ファイル 変わる予定は、まだない 今回の変更で、34ファイルに広がった 変わらない所の汎⽤化も兆候（Speculative Generality） 抽象化が効くのは、変更が実際に広がる所。変わらない所の汎⽤化は、読む量を増やすだけ 効く原則 凝集度 ⼀緒に変わるものは、1か所に集める あわせて YAGNI：今いらない物は作らない（Extreme Programming、Kent Beck ほか） AI時代のソフトウェア⼯学 勉強会 写真：Mulling it Over, CC BY-SA 2.0 ©Algomatic 22
23. 全体像 私たちが気になった所は、どれも名前のある兆候だった 視点 1 要求 2 アーキテクチャ 3 モジュール 4 抽象化の判断 AI時代のソフトウェア⼯学 勉強会 気になったところ 期限を消したら、24時間を切った取消も全 額返⾦になった 画⾯の⼊⼝に、返⾦ルールと決済SDKがあ る 同じ返⾦ルールが2か所にある 変わらない所を汎⽤化し、期限は34ファイ ルに散らばった 兆候 → 効く原則 暗黙の前提 → 要求分析 Divergent Change → 関心の分離 Duplicated Code → 情報隠蔽 Shotgun Surgery → 凝集度 なぜ気になるか 「直前」の意味も返⾦額も、誰も決めてい ない 規約、画⾯、決済のどれが変わっても、同 じ関数を直す 規約が変わると、⽚⽅だけ直ってずれる 次に期限を変えるときも、34ファイルを直 す ©Algomatic 24
24. 勘所を仕組みへ 名前がつけば、兆候をルールにできる 何度も出る兆候は、lint や AGENTS.md に渡す。そうすれば、⼈もエージェントも毎回⾒なくて済む 名前がついた兆候 ルールにすると 暗黙の前提：決めていない業務ルール Issue テンプレートに「まだ決めていないこと」の欄 Divergent Change：判断が画⾯の⼊⼝にある ドメインから決済SDKの import を、lint で禁⽌する Duplicated Code：同じルールが2か所にある AGENTS.md に「返⾦のルールは refundYen だけが持つ」 Shotgun Surgery：期限が34ファイルに散らばる 期限と案内⽂は1つの定義から参照する。AGENTS.md にも書く AI時代のソフトウェア⼯学 勉強会 ©Algomatic 23
25. まとめ 「なんか変」を、直してほしいことまで名前で伝える 今⽇の PR に、私たちは名前つきのコメントを4つ返せる 名前があると：同じ PR に返すコメント 名前がないと 暗黙の前提 「なんか変なので、⾒直して もらえますか」 Divergent Change 開始24時間を切ってからの取消の返⾦額が、決まっていません。Biz に確 かめるまで⽌めます CancelController が、画⾯、規約、決済の3つの理由で変わります。返⾦ ルールを分けてください どこが、なぜ気になり、どう直してほ しいかが、相⼿に伝わらない Duplicated Code Shotgun Surgery AI時代のソフトウェア⼯学 勉強会 返⾦ルールが、取消の処理と表⽰の2か所にあります。1か所にまとめて ください 期限を変えると34ファイルに広がります。期限と案内⽂を1つの定義から 参照してください ©Algomatic 25
26. 勘所を育てる 勘所はいろんなコードを見ることが重要 題材ではなく、⾃分のいつもの PR で、このサイクルを回してほしい 01 気づく 02 名前をつける 03 確かめる 04 振り返る いつものPRで「なんか変」と感 どの兆候か、ソフトウェア⼯学の テストを書く、関係者に聞く、 当たったか外れたかを残す。何度 じたところに、印をつける 名前で⾔ってみる エージェントに反論させる も出たら仕組みへ 次のPRへ smell は、直観につけた名前 確信は、正しさとは別 年数だけでは育たない 多くのコードを⾒て⾝についた「なんか変」に、 「絶対おかしい」と感じても、確かめるまでは仮 当たったか外れたかが分かる経験を、繰り返すと 名前をつけたもの 説（Kahneman & Klein 2009） 育つ 労力は外注できるが、能力は外注できない（t-wada 2025） AI時代のソフトウェア⼯学 勉強会 ©Algomatic 28
27. まとめ ソフトウェア工学は、問題に名前をつけて進んできた 名前があるから、私たちは⼈にもエージェントにも、短く正確に伝えられる カプセル化 同値変異 ⼩さな変更 凝集度 技術的負債 単⼀責任 テスト容易性 Duplicated Code 関心の分離 依存性逆転の原則 要求分析 YAGN 情報隠蔽 リファクタリング 業務ルール I DR Shotgun SurgeryY Code Smell Divergent Change 間違った抽象化 Rule of Three 事前条件 事後条件 結合度 境界値分析 変更容易性 依存の向き レイヤードアーキテクチャ ドメインモデル KISS 関⼼事 仕様 境界 ADR 不変条件 モジュール インターフェース アダプタ mutation testing 契約による設計 回帰テスト 用語を正しく理解して、違和感を名前で伝えよう AI時代のソフトウェア⼯学 勉強会 ©Algomatic 29
28. Q&A AI時代のソフトウェア⼯学 勉強会 ©Algomatic 30
29. 参考⽂献 もとにした資料 設計の考え方 ミノ駆動「⾒えないものを探る要求要件定義に必要な基本的思考」2026-10 データと研究 Pichai 2026、Google Cloud Next 2026（2026-04-22） Anthropic Institute 2026 “When AI builds itself” ミノ駆動「設計次第でAIコードの読む量は減らせる」今こそ聞きたいソフト ウェア設計 #2、2026-09 ミノ駆動「⽬的で駆動する、AI時代のアーキテクチャ設計」アーキテクチャ Hitzig et al. 2026 “Agentic coding and persistent returns to expertise” Conference 2025 森篤史「良いコードとは何か - エンジニア新卒研修」2021 GitHub Octoverse 2025 / GitHub Blog 2026 “Agent pull requests are ohbarye「状態、結合、複雑性、コード量の順に最適化する」2022 ほか everywhere” DORA 2025 / Stack Overflow Developer Survey 2025 Parnas 1972 / Metz 2016 / Fowler “Yagni” “CodeSmell” Kahneman & Klein 2009 American Psychologist 64(6) t-wada（和⽥卓⼈）「AI時代のソフトウェア開発を考える（2025/07版）」 （開発⽣産性 Conference 2025） Google eng-practices “What to look for” “Small CLs” / Nygard 2011 Dijkstra EWD340（1972）/ EWD447（1974）/ EWD667（1978ごろ） t-wada「予防に勝る防御なし（2025年版）」PHPカンファレンス福岡2025 Zave & Jackson “Four Dark Corners of Requirements Engineering” ACM TOSEM 6(1)（1997） Naur & Randell 編 “Software Engineering” NATO 会議報告（1969） Fowler “Refactoring” 初版1999∕第2版2018 AI時代のソフトウェア⼯学 勉強会 ©Algomatic 31
30. 参考⽂献 写真のクレジットとライセンス 写真はすべて Wikimedia Commons から。円形に切り抜いて使⽤（変更あり） Edsger W. Dijkstra：Hamilton Richards 撮影（2002）CC BY-SA 3.0 “File:Edsger_Wybe_Dijkstra.jpg” David L. Parnas：Hubert Baumeister 撮影（2002）CC BY-SA 3.0 “File:David_Parnas.jpg” Martin Fowler：Ade Oshineye 撮影（2008）CC BY 2.0 “File:Martin_Fowler_(2008).jpg” Kent Beck：Mulling it Over 撮影（2005）CC BY-SA 2.0 “File:Kent_Beck_1.jpg” CC BY 2.0：https://creativecommons.org/licenses/by/2.0/ CC BY-SA 2.0：https://creativecommons.org/licenses/by-sa/2.0/ CC BY-SA 3.0：https://creativecommons.org/licenses/by-sa/3.0/ AI時代のソフトウェア⼯学 勉強会 ©Algomatic 32
31. ©Algomatic 33