Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20220305ISECON
Search
株式会社レヴィ
April 11, 2022
Education
0
330
20220305ISECON
株式会社レヴィ
April 11, 2022
Tweet
Share
More Decks by 株式会社レヴィ
See All by 株式会社レヴィ
2024-06-25 ソフトウェア設計における思考と学び方を考える 〜増田さんの思考を構造的に見える化してみる〜
levii
4
850
株式会社レヴィ会社紹介
levii
0
160
Sample-se-one-day-training
levii
0
450
SocSys34-Balus
levii
0
57
20230323TechDLT-vol9
levii
0
300
levii-buzzword-2022
levii
0
310
FIT2022_levii
levii
0
570
20220915modelingLT
levii
4
760
20220910SSDM
levii
0
580
Other Decks in Education
See All in Education
電子計算機のイロハ
kosugitti
1
1.5k
Course Review - Lecture 12 - Next Generation User Interfaces (4018166FNR)
signer
PRO
0
1.4k
LINE ミニアプリ開発のメリットとキャッチアップ方法
junghyeonjae
0
550
Gemini in Android Studio 使ってますか?
satoryo56
0
260
みんなのコード2023年度活動報告・2024年度活動方針/Annual report2023
codeforeveryone
0
190
いまからでも遅くない!サイバーセキュリティ人材育成
mnori0211
1
1.7k
英語学習から海外発表までの流れ
yasulab
18
4.1k
セキュリティ・キャンプ全国大会2024 S17 探査機自作ゼミ 事前学習・当日資料
sksat
2
530
week10@tcue2024
nonxxxizm
0
520
Epithelium Flashcards
ndevaul
0
830
Matz に頼られたので張り切って2時間ほどドイツと日本の互いの Ruby 学習事情についてディスカッションした話
yasulab
1
350
学習指導要領から職場の学びを考えてみる / Thinking about workplace learning from learning guidelines
aki_moon
1
450
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
21
3k
Statistics for Hackers
jakevdp
793
220k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Facilitating Awesome Meetings
lara
49
5.9k
Rails Girls Zürich Keynote
gr2m
93
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
18k
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
Embracing the Ebb and Flow
colly
83
4.4k
How to train your dragon (web standard)
notwaldorf
85
5.6k
Transcript
ゲームを用いた疑似体験による システムデザインの導入教育 第14回 情報システム教育コンテスト ◯三浦 政司(JAXA),萩原 利士成,南部 陽介,山舖 智也(株式会社レヴィ)
発表の流れ • 課題と目的 • 教材の概要 • 導入教育の流れ • 実践結果 •
まとめ 発表概要 • 実務経験の少ない若手社会人や学生が、システム開発の全体像と共に 設計・マネジメントの重要性を学ぶことのできる導入教材を開発しました。 • 協調型のボードゲームをプレイすることでシステム開発の流れや難しさを 疑似体験し、その後の振り返りで理解を深めることができます。 • 提案する導入教育によって実務経験の不足を補い、設計・マネジメントの 重要さと必要性を知った上で理論や方法論を学ぶ学習に移行することで、 効果的な情報システム教育を実現することができます。
課題と目的
設計 マネジメント 方法論 着目した課題 システム開発の経験がない(or 少ない)学生や新入社員・若手社員に対して 設計やマネジメントの理論、方法論、フレームワークなどを教えようとしても、 その必要性・重要性がわからないから、いまいちピンとこないし、腑に落ちない。 なぜそんなことを 考えるの?
なぜそのやり方が いいの? わざわざそんなことを するのは面倒では?
理論や方法論を学ぶ前に知っておいて欲しいのは… • システム開発の全体像、どんな場面があるのか • システム開発の難しさ • システム開発を難しくする要因 • システム開発で失敗しやすいところ どこで転びやすいか?
全体の地図
全体像や難しさをどう伝えるか?:理想 • 実体験から学べ • つくりながら学べ • 学びながらつくれ • 失敗から学べ
全体像や難しさをどう伝えるか?:現実 学習時間の制約 じっくり人材育成 の余裕がない 失敗できない image from https://nasa.gov
全体像や難しさをどう伝えるか?:理想と現実 理想 • 実体験から学べ • つくりながら学べ • 学びながらつくれ • 失敗から学べ
現実 授業時間の制約 じっくり人材育成 の余裕がない 失敗できない image from https://nasa.gov
そこで提案:ゲームでシステム開発を疑似体験
そこで提案:ゲームでシステム開発を疑似体験 ゲーム教材「ペジテの自転車」 • 応募者らが開発した独自のボードゲーム教材 • 自転車という誰もが知っていて機能や 構成要素をイメージしやすい題材を採用 • 自転車メーカーの新製品開発チームになり きってリソースをマネジメントしながら顧客
満足度の高い自転車を開発することにトライ ゲームだから • 学習者同士がコミュニケーションしながら 楽しく学ぶことができる • システム開発が失敗しても大丈夫 ゲームだけでなく • プレイ後のディブリーフィング(対話型の 省察活動)を通して理解を深める
あらためて、この教材の目的 疑似体験を通して学んで欲しいこと • システム開発の全体像、どんな場面があるのか • システム開発の難しさ • システム開発を難しくする要因 • システム開発で失敗しやすいところ
期待される効果 設計やマネジメントの必要性や重要性を実感し、 方法論やフレームワークを学ぶ準備ができる。 設計 マネジメント 方法論
教材の概要
None
勝利条件 ゲーム終了時に計算するスコア「顧客満足度」が 一定の値を上回ればプレイヤーチームの勝ち ゲーム「ペジテの自転車」の概要(1) ストーリー あなたはペジテ社という自転車メーカーの新製品開発チームのメンバーです。 限られた資源を有効活用して、顧客満足度の高い自転車を設計することを 目指しましょう。 ≧ 6
≧ 10 シンプル編 複雑編 ※シンプル編/複雑編 については後述 ゲームボード リソース トークン 1コ1人月 要求 カード 機能 カード イベント カード 行動 カード 視点 カード
ゲーム「ペジテの自転車」の概要(2) • プレイヤー数3~4人の協調ゲーム(チーム間の競争は可能) • 新製品開発チームのメンバーになりきって、自転車製品の設計開発にトライ • 基本的な行動は ◦ 顧客要求を見ながら必要な機能を考える ◦
リソースを消費して機能を設計する ◦ 隠れた要求を明らかにしようとする ◦ 最終的に製品をリリースして顧客満足度を評価する • システム開発に関わる様々な言葉や概念が登場 ◦ 顧客要求 ◦ システム要求 ◦ リソース ◦ 要求変更 ◦ コミュニケーションコスト ◦ プロトタイピング ◦ 規制 ◦ 不確実性 ◦ …
基本的なルール(1) プレイヤーのアクション • 手番ごとに機能か行動のカードをドロー • 最も基本的なアクションは要求を確認しながら 機能を設計する(機能カードを場に出す)こと • 機能の設計にはリソースを消費する •
他には:行動カードの利用、機能の廃棄、 リリース、プロトタイピング、休息 など 顧客満足度 • ゲーム終了時(リリース時または納期に 達した時)の機能が各要求カードに記述 された条件を満たしているかどうかで算出 • 裏向きになって隠れている要求もある (計算時には表にする) • 達成しても満足度は上がらないが、 未達成だと大きく下がる「制約」もある • 例)右図の場合は+3+3-2-2で 顧客満足度は+2(クリア条件満たさず) × 〇 〇 〇 ×
基本的なルール(2) イベントカード • 手番が一周するごとにイベントカードをドローする。 • イベントカードには要求変更や納期短縮など様々な 出来事が記載されていて、効果を発揮する。 • プレイヤーにとってネガティブなものとポジティブなも のの両方があるが、ネガティブなものの方が多い。
• 現実のシステム開発における様々な不確実性に相当。 プロトタイピング • 設計した機能の半分を捨てることで隠れた要求(裏面に なっている要求カード)を1枚だけ表にできる。 • 実行するために最低限必要な機能カードの枚数が定めら れている(MVPの概念に対応)。 • 複雑システム編では最低限必要な機能の数が大きく設定 されており、プロトタイピングするのが難しい。 コミュニケーションコスト • 自分が持っているカードの情報を他プレイヤーに共有 するためにはリソースを1つ消費する必要がある。 捨てる 表にする
シンプルシステム編と複雑システム編 システムコンテキストやシステム構成が複雑になると、設計開発の難しさや 適したアプローチが大きく変わることを反映し、2つのルールセットを構築 シンプルシステム編 複雑システム編 • 規制1枚/要求(表)2枚/(裏)2枚 • 初期リソース合計:30 •
勝利条件:顧客満足度 ≧ 6 • イベントカード枚数(納期):10 • リリース可能機能数:4 • 視点カードなし • 規制1枚/要求(表)4枚/(裏)4枚 • 初期リソース合計:45 • 勝利条件:顧客満足度 ≧ 10 • イベントカード枚数(納期):20 • リリース可能機能数:8 • 視点カードあり プレイの特徴 どんどんプロトタイピングして 序盤で顧客要求を明らかにすると有利 プレイの特徴 ▪ 慎重に相談して手戻りなく設計を進め ないとクリアできない ▪ プレイヤー間で様々な調整が必要
視点カード(複雑システム編でのみ登場) • 複雑な状況下では多数のステークホルダがいて、それぞれの視点や立場を 考える必要があることを反映したカード • 現実世界において視点や考え方を共有するのは簡単なことではないので、 自分が持つ視点カードの内容は他プレイヤーに共有・説明できないルール • プレイ開始時に1枚ずつ配布され、リリース時にオープンし、 顧客満足度を加算/減算する
ペジテの自転車のプレイから得られる教訓(一部) • 要求やニーズは最初から全てが明らかになっているわけではない。 • 目的や制約を気にしないと、いらないもの、使えないものが 出来上がってしまう。 • 限りあるリソースの中でシステムを実現しなければならない • どんなに気をつけていても、世の中や環境が変わってしまうこともある。
(不確実性) • 状況や対象が複雑になると、いろいろな視点が必要になる。 • 様々な立場や視点があって、しばしばコンフリクトする。 • コミュニケーションにもコストがかかるけど、 コミュニケーションは大事。 ※上記はゲームプレイ後のディブリーフィングで出てきた 発言・記述を収集して応募者らが整理したもの
導入教育の流れ
「ペジテの自転車」を使った導入教育の流れ(例) 方法論の学習や本格的な演習へ • 要求分析 • アーキテクチャ設計 • システムモデリング • プロジェクトマネジメント
• … チュートリアル シンプル編プレイ 複雑編プレイ ディブリーフィング
ディブリーフィング(対話型の省察活動) • ゲーム後に参加者間で対話しながら「ゲームの中でどんなことがあったか?」や 「その時どのように感じたか?」を振り返ることで、学びを深めることができる。 • 一緒にプレイした参加者がどのように感じたかを知ることで、自身の学びに加えて 他者の学びや視点も獲得することができる。 • 初学者でも効果的に議論が進むようにするために、振り返りの観点を与えている。 ディブリーフィングの様子
振り返りの観点(一部) • どのような良いプレイがあったか? • どのような悪いプレイがあったか? • シンプル編と複雑編はどのように 違ったか?それぞれに適した戦略は? • 現実のプロジェクト活動やシステム開 発と同じ/違うと思ったところは? • 分からない言葉や概念はあったか?
実践結果
実践例(1):工学系の学部教育 ペジテの自転車を活用した導入教育 システムモデルを使った 上流設計の方法論を学ぶ システムのプロトタイピングに挑戦 テーマ:地域問題を解決するIoT ▪ 工学部3年生向けのものづくり系PBL授業の導入教育として実践。 ▪ 導入教育で設計やプロトタイピングの意義を体感した上で上流設計の方法論を
学び、最後にIoTシステムのプロトタイピングに取り組んだ。 ▪ ゲームを用いた導入教育を組み込む以前の同じ授業と比較して: ◦ 設計の方法論に対する戸惑いや「形式的にやっている感」が減り、設計の 質向上を目指した積極的な質問や議論が多くなった。 ◦ プロトタイピングにおいて機能だけでなく価値の検証に着目できる学生の割合が増えた。 ※毎回の授業後に回収している振り返り記述などに基づいて担当教員が定性的に評価した結果
実践例(2):ソフトウェア企業の新入社員研修 ペジテの自転車を活用した導入教育 設計やマネジメントの 方法論を学ぶ演習 プログラミングやネットワーク/DB など個別の技術要素に関する研修 ▪ ソフトウェア企業の新入社員が全員参加する研修の冒頭で実施。 ▪ 導入教育でシステム開発の全体像や基本的な概念、設計やマネジメントの重要性について
学んだ上で、設計やマネジメントの方法論やフレームワークを演習形式で学習し、その後 要素技術を習得するための研修に移行した(要素技術研修は技術職候補のみが対象) ▪ 非理工系学部出身でシステム開発やプログラミングに関する知識・経験が全くない状態で 研修に臨んだ新入社員もいたが「導入教育でそれまで抱えていた不安を払拭でき、向上心を 持って方法論の学習や要素技術の研修に取り組むことができた」という振り返りを得た ※研修後に回収したアンケートおよび企業側が課した日報の記述を要約 非公開
実践実績(一部) • 大学の授業等で学生向けに ◦ 鳥取大学 ◦ 大阪府立大学 ◦ 北海道大学 ◦
神奈川工科大学 ◦ JAXA宇宙科学研究所 • 企業向けの研修で ◦ 大手SIer ◦ 大手光学機器メーカー ◦ 地方のソフトウェア企業 ◦ ゼネコンのDX推進担当部署 ◦ … • 各種コミュニティイベントで ◦ イノベーション研究会 ◦ …
学習者の声(1)※授業や研修実施後に回収した記述式アンケートから書き起こし 様々な要求があり、全てを満足するのは難しいことが体感できた。 また、同じ設計に対しても様々な視点があり評価が異なることが再 現されていたことが印象に残った。 ゲームという親しみやすい媒体で体験できたのでわかりやすかった。 現実と違う部分もあったけど社会人の人と一緒にやることで実際は どうなってるのかなどの話も聞けてよかった。 カードゲームを通して、できる限り多くの要求や顧客の視点での条 件を満たす開発や設計の仕方や行動の行い方を考えて積極的に行う ことができた。また、色々と相談を行うことでプロジェクトがどう
ゆう風に進行するのかを模擬的に体験することができた。
これまでシステムや設計という言葉について漠然としか理解してい なかったことに気づきました。ゲームやモデリングの練習を通して その意味や重要性についてよく分かるようになりました。 これまでシステム開発の経験が全くなかったので研修についていけ る心配でしたが、ゲームやワークを通して分かりやすく教えて頂い たので、理解することができました。 ゲーム、レクチャー、演習が全てつながっていて感動しました。シ ステムデザインの一連の流れを理解することができたので、これか らの自分の仕事を具体的にイメージできるようになりました。 学習者の声(2)※授業や研修実施後に回収した記述式アンケートから書き起こし
オンライン版の開発
オンライン版も開発 • コロナ禍により対面・集合型でのゲームプレイが難しくなってしまった。 • 授業や研修がオンライン化される中で、導入教育による全体像理解や 意義理解のニーズはさらに高まっている。 • そこで、オンライン授業やオンライン研修においても本提案の導入教育を 実施できる「ペジテの自転車オンライン版」を開発した。 •
すでにいくつかの授業や研修で活用しはじめている。 オンライン版 ・ブラウザ上でプレイ ・プレイヤーモードと は別にファシリテー タモードを搭載 ・シンプル/複雑編ど ちらにも対応
まとめ
まとめ 着目した課題 • 実務経験の少ない初学者は設計やマネジメントの必要性・重要性がわから ないので、いきなり理論や方法論を教えても腑に落ちず学習効果が低い。 開発した教材 • 教材:システム開発を疑似体験するボードゲーム「ペジテの自転車」 • 対象:大学生、企業の新入社員、若手社員などの初学者
• 流れ:ゲームで体験→対話型省察活動で理解を深める→理論や方法を学ぶ 期待される効果 • システム開発の全体像、基本的な流れ、基本的な用語と概念を理解する。 • システム開発を難しくする場面や要因を知り、重要な点、注意すべき点を 理解する。 • 理論や方法論を学ぶ準備が整い、その後に続く情報システム教育がより 効果的になる。