*************************************************************************************** セッションS3-c 分科会 テーマ: 新しいモデル駆動開発教育のあり方を探る コーディネータ: 久住 憲嗣 (九州大学) 日時: 9/2 10:30-12:00 参加人数: 約12人 *************************************************************************************** H: 新しいモデル駆動開発教育のあり方を探るということでセッションを始めます。モデ ルを使った開発のスタイルを教育するのは大変だと思います。教育者の立場でも大変です し、現場の立場でも若者にモデルを使った開発を教育するのは大変だと思っています。教 育に関してETロボコンやセミナーなど、様々な取り組みがあると思います。さらに進んで、 モデル駆動開発となるとさらに教育が難しくなると思っています。  私はモデル駆動開発をあまり外では話していないのですが、モデル駆動開発の一種であ るドメイン化言語を使った開発の教育を話したりしています。50人以上に話して、私が知 る限りではしっかりと使えるようになった人は5人くらいしかいません。歩留まりが1割 をきっているような惨状です。実際に私の大学や、今日お話いただく方が実施しているの ですが、ある種はうまくいっているのですが、ある種はうまくいっていないというのが現 状になります。  今日のセッションでは、何をおしえたらいいのかを議論をして、クリアにしていきたい と思っています。最終的には、教育の方法論が全然できあがっていないので、何を教育し たらいいのか、大学でできることは何なのか、授業でできることは何なのかを考えてみた いと思います。  今回は、専門学校でモデル駆動開発を試しているお話を赤山さんにお願いしています。 また、私からは別のアプローチとして、ETロボコンの九州地区大会の特別企画として地域 のみなさんにモデル駆動開発を無理矢理にでも使っていただこうと、モデル駆動開発プロ セス審査の取り組みを話します。その取り組みと惨状をお話します。さっそくですが、赤 山先生にお話いただきます。 ----------------------------------------------------------------- 事例紹介1 赤山聖子 (九州技術教育専門学校) 産業界と連携した組込みソフトウェア技術者養成プロジェクト  ~専門学校生にMDDを教えよう~ -----------------------------------------------------------------  みなさんこんにちは、九州技術教育専門学校の赤山と申します。モデル駆動型開発をや りたいということがモチベーションとしてありまして、モデル駆動型開発の教育のお話を します。  それでは背景を踏まえて、学校の紹介をします。熊本県に専門学校を2校持っています。 情報システム工学科の中に、組込みシステムコースと情報工学コースがあります。私が組 込みシステムコースを立ち上げる担当になってから3年が経ちます。今回は、情報システ ム工学科の教材の一部を開発したお話になります。  私たちの学校で組込み教育を始めるにあたり、ETロボコンに参加しました。2008年に九 州地区大会が始まり、その年から組込みシステムコースを始めることになったので、2008 年からETロボコンに参加しています。プログラミングだけでなく、モデリングや設計など を教育する必要があるという議論をしながら、新しいコースのカリキュラムを決めていき ました。毎年ETロボコンに参加する中で、そのコミュニティの中でどのような教育が必要 なのかを伺うことができました。幸い、2009年にはチャンピオンシップ大会に参加するこ とができました。  しかし大変なこともありまして、ETロボコンに参加するにしても、学校で教育するにし ても、ソフトウェア設計をしっかりしないといけないということになりました。ただUML を教えても、学生からは何に使うか分からないと言われ、UMLの記述が正しいのかも分か らないと言われました。また、プログラミングとモデリングの授業は別々にあるため、コー ディングして動いていれば、いいのではないかと言われることもありました。  設計が必要だと感じてもらい、それを上手に楽しく教育できる方法はないかなと考えて おり、モデルが動いたら楽しいのではないかと思い、モデル駆動型開発に取り組みました。 産業上開発効率があがるというメリットがあるのですが、教育のメリットもあると思い、 MDD(モデル駆動型開発)の教育を始めました。  取り組みの目標としては、モデリングや品質を意識できる学生を育てることです。さら に、モデルをソフトウェア開発のどのような場所で使われるのかをしっかりと理解しても らいたいと思っています。できるだけ早い次期に理解してもらうことで、その後の学習に 役立つと思い、早期教育を考えています。ある程度、C言語の文法の知識があることを前 提の知識としています。  この講座の特徴ですが、MDDを積極的に利用することで、モデリングに集中できるよう にしています。通常ですと、設計、実装が終了するまでテストができないのですが、MDD だと設計したものをすぐに動かすことができます。そのため、設計したものを早い段階で テストすることができ、学生さんのモチベーションが下がらずに開発できるのではないか と思いました。また、何度も作り直すことができるため、モデルの質が向上するのではな いかと考えています。  カリキュラムですが、高卒の学生さんが半年プログラミングを学習した後に、組込みの ことを学ぶために作成しています。カリキュラムは基礎編、応用編、PBL編と3部作ってい ます。基礎編ではモデルは一切利用せず、とりあえずロボットを動かします。形は違うの ですが、ETロボコンで利用する筐体を用いてプログラミングします。  応用編では、ハンドコーディングしたものに対し、モデルを作成しMDDで開発するよう にしました。演習課題ですが、架空の運送会社を想定し、ロボットにより荷物を運ぶとい うものです。内容ですが、ハンドコーディングしたものの一部をリバースモデリングし、 またモデルから生成されるコードがどういうものかを、同じ教材を用いて勉強してもらい ます。最終的にはモデルを書いて何が良いのかを実感してもらうために、演習課題に対し て変更を加えます。変更に対し、皆でモデルをどのように変更したら良いのかを考えても らいます。モデルで開発したため、早く変更に対処できたということを実感してもらうよ うにしています。  基礎編ではセンサーの扱い方など、組込みプログラミングの基礎を学習します。応用編 では、コードに対しモデルがどのように変換されるのかを学習します。知って欲しかった のは、モデルからコードに変換されるときに、変換ルールがあるということです。また、 一定のルールに従ってプログラムを作るということを知って欲しかったです。変換ルール があるため自動変換できるということが、MDDの話になります。あとは、モデル作成とテ ストを繰り返すことで、モデルを良くするということを教材のメインとしました。  初めての学生さんがいきなり単独で行うのは厳しいので、はじめは皆でモデルを作成す るようにしていました。最終的には、こちらで指定した2つのクラスの以外の状態遷移図 が記述されたものを渡しておき、指定した2つのクラスの状態遷移図を記述することを課 題としました。これによりある程度敷居が下がりました。この段階ではまだ、クラスを自 分たちで書くということはまだできません。  PBLは2週間行われ、新しい機能を追加することを課題とし、クラスの変更、設計の変更 が必要なことを気づいてもらうようにしました。基礎編、応用編、PBL編全体を通し、20 日間のコースになっています。ここで、実際の様子を動画でお見せします。 -------------------- 動画再生 ------------------- 基礎編、応用編、PBL編、それぞれの実際の様子が映し出された -----------------------------------------------  実証講座としては、基礎編3日、応用編4日、PBL編14日の3部構成です。学生さんのアン ケートには、期間が短く大変だったというものがあったのですが、内容を理解してくれた 学生さんもいました。モチベーションを高く保ったまま実施できたことが大きかったと思 います。  今回はソフトウェア設計の教育をMDDを用いて行う方法を提案しています。モデルをそ のまま動作させることができ、設計、実装、テスト、改善を早く繰り返せるため、楽しく、 早く学習できるのではないかと考えています。 以上です。 --------------------------- 事例紹介終了 --------------------------- H: 会場から質問はありますか。MDDを使ってモデリングを教育することは、完璧とは言え ないですが、成功していると言えます。ただし、MDDを開発に利用できているとまでは言 い切ることはできないのがこのプロジェクトの現状です。出来ているのはMDDの開発体制 に仕込まれている状態から、改良したりアプリ開発ができるというところです。 ----------------------------------------------------------------- 事例紹介2 久住 憲嗣 (九州大学) モデル駆動開発プロセス審査 初審査を終えて -----------------------------------------------------------------  簡単にETロボコンでの九州地域の取り組みを紹介します。今年からモデル駆動開発プロ セス審査というものを始めました。大きな長期的な目標は、モデル駆動開発を導入して、 開発できる技術者を養成することです。開発コストや納品期限の強いプレッシャーがある ため、自動化技術や上流での検証を進めない限り、日本のソフト産業界に未来はないだろう と言われています。  具体的な実現方法として、ETロボコンを通して自動化技術の導入や利用のセンスを磨い てもらおうと考えています。また、どのように働き方を変えていけば良いのか、自動化技 術が実用的であることを実感してもらおうと思います。  実際の現場の状況に合わせ込まないことには、これらの技術というのは実際に使われな いと思っています。そのため、ETロボコンで利用してもらい、自分たちの開発方法に導入 することで、どういうときにうまく利用でき、反対にどのような時には利用できないのか を体感してもらうのが1つの目標になっています。  また、実際に開発ツールを利用してもらうことで、本当に使えるのかと懐疑的な人に対 し、実際に利用できることを実感してもらいたいと考えています。実際に現場で利用でき ることを分かってもらえるのですが、一方で万能な道具ではないため使えない場合もあり ます。その辺りの感覚をつかんでもらうことが重要だと考えています。  この活動を始めるにあたり、入門的な内容のモデルベース開発セミナーを3月に行いま した。また、具体的なツールを利用したMDDの実践セミナーを6月に実施しました。こちら は実際のETロボコンの筐体を利用しました。他の取り組みになりますが、ドメイン特化型 の言語開発講座を行いました。この場合のドメインはETロボコン走行体であり、その制御 用言語の開発をしましょうという内容です。  これらの活動に並行して審査基準を決めました。私たちとしては、MDDをどこに導入し たのか、どのように導入したのかが重要だと思っており、導入プロセスと開発プロセスと いう2つの項目で審査基準を決めました。導入プロセスですが、1.MDDをどこに、どのよ うに導入するのか、2.既存資産をどのようにとらえるのか、3.効率的にするため、どの ようなチームを作り、役割分担をするのか、の3つの観点で評価します。  開発プロセスと成果物に関してですが、1.MDDに適したソフトウェアアーキテクチャは どのようなものか、2.自動生成や上流でのシミュレーションや検証は行ったか、3.効果 はどうか、の3つの観点で評価します。  実際に実施したところ、九州地区では34チームのエントリーがあり、審査対称になるの は6チームでした。実際にMDDがそれなりにできていたのは3チーム、コードとモデルを同 期させるラウンドトリップ型のMDDを行ったのが1チーム、コンパイル型のMDDを利用した のが2チームでした。これらから、セミナーだけでは導入は大変だと分かりました。  作成されたモデルを見たところ、ソフトウェアアーキテクチャのリファクタリングには 貢献したと思っています。ラウンドトリップ型のMDDを行ったチームが言っていたのです が、コードからリバースモデリングを実施することで、非常に大きな部分があることが分 かり、分割を実施することができたそうです。  過去の資産を利用した開発を一部のチームが実施していました。ただし、できていない ことも多々あります。例えば、適用範囲の適切な設定ができていない印象がありました。 もしくは、限られた枚数から読み取るため、表現できていないのかもしれません。モデル を利用した上流での検証はできていない状況です。MDDを利用した分業も進めれていない と思いました。  MDDとは関係ないが、モデルとしてなぜその技術を適用するのか、どのように適用した のか、その効果はどうだったのか、の3点セットが書けていないのが実状であり、評価が できないことがありました。  これらのことから、我々が九州地区の方に多大な期待をしていたことが分かりました。 個人的には、MDDのモデル適用のレベル毎に評価する方法が必要だと思いました。ここま でがETロボコンの活動の話になります。質問はありますか。 S: 1チーム何名程度で、どのようにETロボコンに参加しているのか。 H: チームの規模は大きくなく、どのチームも5、6名くらいです。多いところは10名程い ます。私のところでは、技術導入が1人、総合戦略が2人、実装が2人で役割分担しました。 S: モデルを書いているのは何人ですか? H: 2人ないしは3人です。 S: 全員モデルを読み書きでき、情報共有できるのが前提ですか。 H: どのチームもそうであるかは分かりませんが、そうです。 A: 過去はできる学生さんがやってしまっていたが、今年は皆でやりたいということが大 きかったです。MDD教育の効果だと考えています。皆でモデルを書いてから、次にそのモ デルをもとに分担をどのようにするのかを考えていました。また、PBLを行っていたため、 分業については考えていました。現在は、分担した作業のマージに苦労しています。 I: モデル駆動開発適用には段階があると思いますが、それを紹介していただきたいです。 H: 確固たるものがないのでぜひ議論したいです。大雑把ですが、まずはお絵描きとして モデルを書く、設計図に落としてモデルを書く、ここまでは今までのモデリングです。 さらにMDDを利用した体制の下で働けるレベルがあります。これは、設計なのかもしれ ないし、検証かもしれません。最後にはMDDの技術を適用して、プロセスの設計ができ るレベルだと考えています。 J: 審査基準の中に、システムを理解してどのようにモデリングをするのかという項目が 入っていないのはなぜですか。 H: 新しい走行戦略を考えたときに、なぜそれをいれたのか、どのようにやったのか、効 果はどうであったのかということを、定量的でなくてもいいので、しっかりと書くという ことが教育としてなされていると思っていました。認識不足でした。 --------------------------- 事例紹介終了 --------------------------- H: 議論に入りたいと思います。特に学校教育ということをいうと、モデル駆動をやるこ とで、モデリングはできるし、モデルでの開発体制下で働ける素地はできてきたと思って います。その上の、モデル駆動開発を導入するという点では、学校ではできていないと思っ ています。そもそも、学校でこのうような教育ができるかは疑問です。最終的には、設計 自動化技術であったり、検証技術を自分たちのドメインに取り込み、働けるようにするの が必要だと考えています。  フロアの皆さんにお聞きしたいのですが、モデル駆動開発が可能になるため、モデル駆 動開発を仕込めるようになるためには、どのような教育活動をした方がよいのか議論した いです。この段階でコメントはありますか。 N: モデルを書くときはある程度大きな目的があると思います。 今回の教育において、モデルを書く目的というのはどこにあったのでしょうか。 A: モデルに限らないのですが、ソフトウェア設計をしっかりするため設計書を書きたい。 その設計書を書くときにUMLを利用しているので、UMLを書けるようにしたいということで す。あとは、モデルを用いることで、大人数での開発が行いやすいことを理解してもらい たいというのが目的にありました。 N: あえて厳しいことになりますが、前者はモデルを書くことが目的になっているように 思います。モデルを書くことが目的ではなく、書いて何かを得ることが目的だと思います。 前者はモデルを書くことが目的になっており、後者は全体で見える化をするといったこと が目的になっていると認識しています。 A: そうですね。自分たちで書いているものを全体で共有し、品質の良いものにするとい うことが目的です。 H: 結果として、見える化をしてチームで共有するということが目的になっています。も う一つは、プログラミング言語としてのモデルとして書いて、自動生成できる、シミュレー ションできるということが目的になっています。本当は後者ばかり考えていましたが、む しろ前者の効果の方が大きいというのが個人的な感想です。 N: 個人的な感想では、UMLでのコード自動生成は現実的に難しいと思っています。UMLの 目的は見える化になっているように思います。作っている人にとってはモデルというのは 重要ではなく、人がいなくなったときに、設計情報をどのように残していくのかといった ところが大きいと思います。これらについてコメントをいただけないでしょうか。 H: UMLベースのコード自動生成はできないとは思っていません。見える化が重要であると いうことはそのとおりだと思います。個人的な感覚ですが、最初の開発ではUMLベースの 開発は行程が減らずに、とんとんくらいになっており、再利用することで開発効率があが ると思っています。実際に私のとこと、赤山さんのとこの学生さんは苦しんでいたので、 3年くらいモデル駆動開発をしないとペイできないと思いました。 A: 教材の中で基礎編、応用編はペアで作ることが基本になっています。PBL編では4、5 名で取り組みます。この際、もともとのペア同士をくっつけてチームにしています。基礎 編、応用編で作成したものに機能を追加しようとしたときに、ペアで開発したモデルを紹 介したり、議論することにモデルを活用しましょうということを行いました。 L: モデルにして見える化する目的はなんですか。企業にいる立場からすると、見えるこ とで何が生まれるのか疑問です。 A: コンポーネントの単位として個人で作成し、全体で見える化して利用します。 L: 見える化により理解がしやすくなるのはいいのですが、このような特性を持ったモデ ルをソフトウェアに適用することで、何が達成できるのかが分かりません。この部分が先 ほどからの議論で抜けていると思います。個人の考えですが、まず、ソフトウェア技術者 を教育しようとしているのか、コーディングワーカを教育しようとしているのかどちらか をはっきりする必要があると思います。  コーディングワーカは海外にたくさんいるため、日本の産業でコーディングワーカは中 国に負けてしまいます。そうであれば、日本ではモデルでデザインするまでにとどめてお き、海外の人にコーディングしてもらう方が良いと思います。そうなると、コーディング やリバースモデリングなどではどうでも良くなり、コードを書くのではなく、モデルを書 けるようにしなければならないです。システムをどのようにモデルで書くのかを勉強させ なければならないと思います。  コードを書いてリバースモデリングして変換されることを勉強しても何も役に立たない です。なぜこのようなことを話しているのかというと、自分がここ2週間ほど若いエンジ ニアと話していたときに、彼らが全くこれらを理解していなく、苦労したからです。 H: 基本的にはおっしゃる通りで、抽象化されていないモデルは意味がないと思います。 つまり、抽象的なとこで働けるようにならないと、私たちに未来はないというご意見だと 思っています。抽象化をどのように教えるのでしょうか。私も悩んでいる分野の一つで、 自分たちの対象を、どのように抽象化するかを教えることができていなく困っています。  対象分野を整理し抽象化し、抽象化したどの部分に技術が適用できるかなどを判断でき る人が、優秀な技術者だと個人的には思っています。何かいいアイディアをお持ちや、取 り組んでいる方はいないですか。 Y: 昔、○○さんがプログラムの勉強をするよりも数学をやれと言っていました。初等教 育でプログラムを教えるときに、関数の概念が分かっておらず、関数化するというプログ ラムの抽象化のときにつまづいてしまいます。やはり、大学生になる前の早いうちに、数 学をやったほうがいいと思います。  プログラムを教育をされているかたは別意見だとは思います。このような抽象化能力は 育成しにくく、さらにモデル化だと内容が増えるのでさらに難しいと思います。 H: 私は世の高校生に物理、数学を勉強してもらいたいと思っています。実際に物理、数 学を勉強したほうがいいと思う人はいますか(会場にいたほぼ全員が挙手)。それ以外でや はりプログラミング教育をしたほうが良いと思うご意見はありますか(会場内にはいない)。 S: モデル駆動から教育を始めるときと、プログラミング教育をしてからモデル開発を教 育した場合では、どちらが定着率がよいですか。 A: 最初はプログラミングありきでモデル教育をしていたのですが、実際はモデルとコー ドとの関係は教育できておらず、モデルを重点的に教育するべきだったと思います。抽象 化教育も重要だと分かっていますが、一通りの流れを知ってほしいということから、カリ キュラムは先に述べた形になっています。 H: 事例ですが、アメリカで高校生にモデルをとにかく書かせてみせることをしたそうで す。例えば、クラス図とかで手のモデルや、血圧計のモデルを書いてもらったそうです。 簡単にクラス図の概念を教えると、わりときれいにモデルが書けたそうです。  信州大学の香山先生の結果なのですが、ソフトウェアエンジニアに書かせると、散々な 結果になるそうです。結局ソフトウェアエンジニアだと、クラスの概念とプログラムの要 素の結びつきが強いため、切り離して抽象化することが中々できないという結果になって います。結論としては、モデルから入った方が良いのではないかというのが、ある人たち の意見です。私も個人的にはそう思っています。 O: モデルを強調しすぎると、きれいなモデルでも動かないものができるのではないでしょ うか。 H: 教育の順序の話であり、それを教えていくべきだと思います。このような試みがどの くらい成功しているのかは分かりませんが、それなりに抽象的なレベルで動作することを 評価できる枠組みであったり、そのようなツールを、活動を通じて教育していくべきだと 個人的には思っています。性能的なものであれば、評価モデリングやシミュレーションを すれば良いと思います。プログラミングの教育の順序や内容は考えるべきだと思っていま す。 O: クラス図を書くときに、実装がどのようになっているのかを意識している人はいるの かなというのが疑問です。 H: 新しい視点が持ち込まれたと思うのですが、モデルの世界にいってしまうと、若手技 術者がいなくなるという指摘だと思います。私も同じような危惧を持っています。ただし、 モデル駆動開発の世界は、小数の超優秀な技術者が普通の技術者を引っ張って物事を成し 遂げる世界だと思っています。このような小数の技術者は全てを知る必要があるのだと思 います。上から下まで知っている人が、全体の抽象的なことを決定し、その間をモデルを 書ける人が埋めていくのだと思っています。 L: 数学の話ですが、ステートマシンが書けない人はそもそもソフトウェアを書くべきで はないと思います。先ほどの若手エンジニアの話になるのですが、ステートマシンを書か せると誰も書けないのです。まともなソフトウェアが書ける理由がないというのは、非常 に重要なことだと思います。ステートマシンが書ければ大抵のことができるのです。  先ほどの、コードからモデルになったら、コードが書けなくなるという話ですが、ハー ドの世界で何年前かに議論していました。回路図からHDLの世界に変わってしまったとき に、自動生成したものは後から触れないし、分からないではないかと言われていました。 しかし、今やそのようなことを言う人はいません。なぜ自動生成できることを、ソフトウェ アの人は未だに手で書くことにこだわっているのか、個人的には不思議です。極端な話で すが、自動生成して動作するならそれでいいのではないでしょうか。 H: そういう観点もありますね、ソフトウェアの多くの部分はクリティカルではないので、 細かいことを気にするなというのはごもっともな意見だと思います。その辺りも理解でき る技術者が育てばいいと思います。 S: HDLの世界に抽象度を上げるのを引っ張っていった人たちは、どのような人たちなので しょうか。 L: 僕の経験ですが、引っ張っていった人たちは、現場でハードウェアを設計していたエ ンジニアの人たちでした。なぜ毎日遅くまで回路図を書かなければならないのかと疑問に 思っていたので、HDLが導入されるときに皆こぞってそこにいきました。最初のツールは 自社で作成していました。途中からは規格化されたものを利用するようになったのが現実 です。 K: 10年くらい前にそのような議論をしていました。開発の現場の人たちは最初はとまど うのですが、1つ1つのプロジェクト毎に対応していくと、2年くらいで成り立っていきま した。 D: ソフトウェア屋さんもアセンブラからCにと抽象度は上げていきました。今のモデルは 抽象度は上がらず、うまみがないのが問題だと思います。結局UMLは言語と同じ抽象度レ ベルなので、それを上のレイヤーに持っていかないと、投資対効果が少ないのだと思いま す。 H: 実際にステートマシン図以外の抽象度が上がっていないというのが現実だと思います。 L: そもそもモデルは高い抽象度で書くべきものなのに、プログラミング言語の代わりに 利用しているのでややこしい。正しい使い方をせずに展開できないのは当たり前の話であ り、まずは正しい使い方をしましょう。その正しい使い方の教育をすることを期待してい ます。 H: ステートマシンを教育するいい方法を知っている人たちはいますか。 L: 私はもとはハードウェアから入っており、先ほど言ったHDLはステートマシンを書く ために作られた言語です。ハードウェアを設計するためにはステートマシンを書けること が当たり前です。  若手技術者がステートマシンが書けないということで、仕方がなく、山に登って下りて くる、けがしたらすぐに下りてくる、雨が降ったらテントを張って、天候が回復したら下 りてくるということを、ステートマシンで書いてくださいと、日常のことを書かせること から始めました。それでも、10人いると3人しか書けませんでした。特に、事故が起きた らビバークしないといけないということをつかめたのは1人だけでした。日常に近いとこ ろから始めるというのは、先ほどの高校生の話に近いものがあると思います。 H: ドリルをステートマシンを使ってやるのはいいかもしれないですね。 Y: クラス図の話ですが、なぜ言語に近く作ったのだろうかと疑問です。クラスという名 前にしたら、言語を意識してしまう。もう少し抽象度を高く、図式化するような方法を考 えるべきだと思います。  教えるというと、意外と大学の先生はこの手のことを知らないです。自分が最後に触っ ていたものでこり固まっているのではないでしょうか。大抵の学生は、カーネルやドライ バを書くことはないので、社会に出たらモデルを書くなどに費やす時間が最も長いので、 いまだにC言語など古い技術を教育していることに問題があるのではないかと、たまに思 います。 D: 会社にいると縄文時代のような開発スタイルにも関わらず、その意識を持っているエ ンジニアは少ないです。学生には本来のMDDの美しい姿を教えていただきたい。 H: 化石のような授業をしていて、赤山さんの活動の発表会にボスを連れて行ったら、大 学よりいい教育をしていると言っていました。大学で先端的なことを教え、仕方がないの で古い技術を利用しているという位置づけを教えていくのが教育として重要だと思います。 赤山さんとこの学生さんが就職すれば、会社の開発環境に対して古いと思える最初の世代 がくるのではないでしょうか。 A: そうあって欲しいと思い活動してます。長い間業界で活躍できるように、どのように 技術が変わっていくかを知ってもらいたいというモチベーションで、このような活動をし ているのですが、専門学校の卒業生はコーディングするような場所にいきます。そのため、 専門学校でモデルを教えるのは、意味がないのではないかと言う人が多くいます。コーディ ングも実際教育しないと就職につながらないのが現状です。 H: 赤山さんのような活動されているとこの学生さんを積極的に採用していただくなどの 仕組みができれば、もう少し変わるのかなと思います。個人的に思うのは、システム全体 をしっかりと捉えて、ドメイン毎に分けていくことを教えたいと思っています。これをし ないと、どこに技術を適用していいのか分からないことになると思います。このような教 育をされている方はいますか。 L: ステートマシンを書けない人に対して実験をしました。この実験とは、神奈川のある ところから、ミラノにいくルートを書き出してもらうというものです。10人に15分の時間 をあげ、調べてもらいました。すると、10人中10人全員が、まず玄関を出て、この道を進 みと、全て順番に書いていました。それを一人ずつ発表してもらいました。  最初は3分、次は30秒、10秒、5秒と減らしていきました。どこかのタイミングで、イタ リアまで飛行機で行く、空港からは電車、最後はタクシーと説明すればあっと言う間に終 わるのです。しかし、彼らは書き出したことを順番にずっと説明しました。時間が限られ ると早く言おうとしました。早く言おうとする内容は、何ら抽象化されていないものです。  彼らとディスカッションしたことは、自分が取り組んでいること、例えば、どこかへ行 く時の制限事項は何ですか、お金なのか、時間なのか、安全性なのかといったことに、着 目しているはずでしょうと。そういったことから抽出していけば、飛行機で行くことが大 事なのか、最寄り駅まで歩いていくことが大事なのか、自ずと出てくるでしょうと。この ようなことを考えさせることに取り組んでいます。 H: ちなみに30秒にしたときに抽象化して話せた人は何人いるのですか。 L: ゼロです。全員だんだん早く話そうとするので、できませんでした。非常に驚きの結 果でした。 H: ある程度まで時間を減らしたら抽象化すると思ってやられたのですよね。 L: そう思っていたら、一生懸命早く話しただけでした。 A: だんだん減らしていくというのはどのようにですか。 L: 最初のチームからだんだん減らしていくので、途中から皆がざわつきだします。10人 いるので、最初の人は3分にし、そこから減らしていきます。後ろの人には抽象化する時 間を上げているにも関わらず、どうやって早く話すかを考えていました。最終的には抽象 化することを説明しました。 H: 最終的にはどのように抽象化を教えるのかという話になってしまいました。その他に ありますか。 D: 新入社員の研修で、時計のカード(アナログ、デジタル、目覚まし、腕時計など)を配っ ておき、それらを分類するワークをしています。分類の仕方を見せ合い、どのように分類 したのか意見交換することをやり、相手の視点をしるということをやっています。面白い のが、その時計の中に、砂時計や日時計などを入れると、そこでパニックになります。そ ういうことで、いろんな人が様々な視点を持っていることを交換しています。 H: 大きなドメインを小さなドメインに分割するということでは、重要な観点だと思いま した。 ■まとめ 結論としては、やはり抽象化をしっかりと教えないといけないという感じがしました。実 は、私が後期から大学の講義でMDDを教えるので、どのような内容を教えるべきか参考に するために、このセッションを開きました。 以上。