00:00
今日お話ししたいのは、行動中心アプローチのコース開発過程です。
これを話そうと思ったのは、毎年行っている行動中心アプローチのコースが、11月の初めから始まるんですね。
これはJFNDでやっているやつです。
前にカナダにいた時も、カナダのJFを主催でやっていましたけど、
それで、振り返りを兼ねて、お話ししてみたいなと思ったんですけど、
まず、僕がカナダにいた時でも、こちらのインドに来た後でもいいんですけど、
この行動中心アプローチのコースに参加したことがある人はいらっしゃいますか?
もしあったらハートマークいただければと思いますがどうでしょうか?
もしない人は涙のマークでリアクションいただければと思います。
はい、Vサインきてますね。
参加してたという意味ですよね。ありがとうございます。
僕が実際に関わってきたコースの中で、
たぶん、ちゃんと教材化されて本まで出版されたのは、
ITエンジニアのための日本語のコースだったんですね。
2008年に、出版社のアルクさんから
仕事の日本語IT業務編というタイトルで出版されています。
この当時は、実は僕は行動中心アプローチという言葉を知りませんでした。
知ってたかな?
あんまりそんなに意識はしてなかったですね。
少なくとも各課に行動目標というのが書いてあるんですね。
どの課にもね。
だけど2008年というのはまだJF日本語スタンダードができる前ですね。
もうCFRはできてましたけど、
2008年はまだ、確か2010年にJF日本語スタンダードができたと思うので、
それも実は全然参考にする前でしたね。
出版したのは2008年なんですけど、
実際にはこのコース開発をしていたのは2005年とかそのぐらいなんですね。
その後3年間、2004年くらいにこのコース開発をして、
実際そのコースで運用して、
日本に帰ってきてからこれを出版したという感じだったので、
実際このコース開発をしていた頃は、
まだそんなに世界の反対の方でようやくCFRができて、
03:00
まだその時代ですので、
あまり行動中心アプローチということは意識はしていなかったんですけど、
でも今思うとそれが僕のですね、
行動中心アプローチ的なコース開発に関わった本当に原点のようなものだったので、
それについてちょっとご紹介しながらお話ししてみたいと思います。
まずですね、開発の経緯というのは、
当時はですね、国際交流基金から在家のプロジェクトのセンターですね、
そういうところに僕は参加していたんですね。
で、その同じ在家のITの専門家という人がいてですね、
そのIT専門家から、
井出さんという方なんですけど、
井出博之さんという方ですね。
そのITの専門家から協力の依頼があったんですね。
で、それがどういう仕事かというと、
要するに日本で働くためのITエンジニアの育成のコースだったんですよ。
もちろんね、モンゴルと日本ではだいぶそのITの使用環境も違うので、
そのIT的なことも教えなければいけないし、
それだけではなくてもちろん日本語もちゃんとしゃべれるようにしなきゃいけないわけなんですよ。
ですけど、僕はですね、
全然IT業界とかで働いたことがないので、
何を教えればいいのか全く見当もつかないという、
そういう状況だったわけですね。
要するにニーズ、
普通はコース開発というのはまず最初にニーズ分析というのがあるんですけど、
そのニーズをしろうにも、
だってITのね、
モンゴル人のITエンジニアに何を勉強したいですかって言ったって、
彼らだってですね、日本でどういうニーズがあるかというのは分からないわけですよ。
何をすればいいのか分からないからですね。
それで、コースが始まる前に僕が色々勉強したのがですね、
ITエンジニアの仕事ぶりということですね。
本当にありがたいことに、やっぱりね、これがね、
画家とかね、歌手とかそういう人だったら、
仕事ぶり、仕事の方法とかっていうのはあんまりオンラインに載ってないかもしれないんですけど、
やっぱりITエンジニアの方っていうのは、
インターネットとかとね、親和性が非常に高いので、
そういうですね、
ITエンジニアの仕事の方法みたいなのはもういくらでもあったんですね。
もう時間があっても読み切れないぐらいすごい沢山の資料がありました。
これは本当にとても僕にとってはありがたい、ラッキーなことだったんですね。
当時は、まだ主流と言ってもよかったのかな、
ウォーターフォール型っていうその開発過程が結構主流というか、
その当時でももう既に伝統的なという立場でしたけど、
そういうウォーターフォール多岐ですよね。
ウォーターフォール型の開発過程、プロセスっていうのが一応主流だったようだったんですね。
06:00
それでそのウォーターフォールというのはどういうものかというと、
滝みたいに上から水が落ちていって、
一回下の段階に落ちたらもう二度と上には戻らないという、
そういうスタイルの開発過程です。
例えば最初に要件定義というのがあって、
これはシステム開発ですね。
システム開発の過程、プロセスなんですけど、
最初に要件定義というのがあって、
このシステムでは何をしなければいけないのか。
例えば銀行のお金のATMのお金を入れて、
それを数えてというような、
例えばそういうことです。
何をしなければいけないのかということですね。
その次に要件に従って設計図を書くということですね。
設計図。
そして設計はちゃんとした後でそれに従って開発をすると。
開発というのは実際にプログラミングでコードを書くとか、
そういうところですね。
開発ができたらテストをして、
そのテストでうまく、
多分普通は当然いろんなバグとか出るので、
バグとかも直しながら、
それが終わったら納品して、
納品した後に補修という仕事があるとかですね。
そういう感じで仕事の流れがすごく分かりやすいんですよ。
これがほぼそのままシステムエンジニアが対面するコードリストになっているわけなんですね。
でもこれがそのまま教材にはならないわけですよ。
さらに実際にエンジニアの人たちがどんな資料を読んで、
かつどんなコミュニケーションを口頭で、
周りの上司とか同僚とか顧客とかね、
そういう人たちとどういうコミュニケーションをしなければいけないのかというのは、
これだけでは分からないので、
そこでもっと細かいコードリストを作りました。
上司からこういう指示を受けて、
終わったらそれを報告するとかですね。
そういう感じですね。
このあたりもですね、
僕本当に外部の人間なので、
この辺はここまでは想像なわけなんですよね。
でもやっぱりそれが絶対にあっているはずがないというのはあったので、
在下のIT専門家の方の協力を仰ぎながら、
協力というか監修に近いですね。
いやこんなことはしませんとか、
そういうダメ出しとかも結構ありましたけど。
そういうのもあって、
こういう細かいコードリストも作りました。
実際には僕が想像していたのとは全然違うという、
そういうこともかなりあったみたいですね。
でも実際は、
09:00
このコードリストを作るというところまでが、
たぶん一般の日本語教師にとっては、
一番難しい部分だと思います。
自分の知らないコードとかだったらね。
なのでですね、
僕が主催している行動中心アプローチのコースでは、
自分がよく知っている行動について、
コードリストを作る。
そのコードリストに基づいて、
行動中心アプローチのコースを開発するということが、
望ましいというふうに僕は思っています。
僕は実際の開発、
僕のITエンジニアのコースの開発過程では、
その次に会話モデル、
モデル会話みたいな、
そういうものを作るところに進んだんですけど、
今はですね、
現代の行動中心アプローチのコース開発では、
この間にキャンドゥを作るというのが、
さらに入ることが多いと思います。
これはどうしてかというと、
ただ単にですね、
コードリストになっていると、
例えば上司から要件定義を、
要件定義書という資料をもらって、
それを読むように言われて、
あとその締め切りとかもね、
言われて、
それを締め切りまでにちゃんと内容を読むとか、
そういう行動があったとしても、
それがですね、
コースが対象としているレベルと、
合っていないときとかがあったりするわけですね。
あるいはそれが抽象的で、
例えば要件定義書にしたって、
ものすごい分厚い要件定義書もあれば、
そうでもない要件定義書もあるわけですよね、
そのシステムの規模によって全然ね。
なので、
それがはっきりしていないと、
全然そのコースの目標がクリアできたかどうかが、
わからなかったりするわけですね。
なので、
そこをCan Doの形に落とし込むには、
普通はですね、
条件というところと、
対象というところがあります。
すみません、
Can Do Statementをご存知の方は、
いらっしゃると思いますけど、
Can Do Statementの要素の中には、
もう変えられないところとかもあるんですね。
例えば場面とかっていうのは、
もうITエンジニアで、
その会社の中でどういう部署っていうのは、
それはもう多分変えられないですよね。
その場面と条件と対象っていう、
要するに対象っていうのは内容のことなんですけど、
日本語のね。
例えば要件定義書とかメールとかそういう対象と、
それから最後に行動っていう、
その4つの要素がCan Do Statementには入っているんですけど、
12:00
そこでレベルの調整で主に使えるのは、
条件のところと対象のところだけなんですね。
条件のところは、
例えばその要件定義書、
例えばもっとページ数とかもあったらいいと思いますけど、
何ページぐらいの要件定義書で、
すべての漢字にRubyが振ってあればとかね、
そういう条件があれば、
それが条件として出てくるわけです。
もう一つは対象っていうところですね。
その対象っていうのは、
それからその対象っていうのは要件定義書とか、
そういう自分が読んだり書いたりしなければいけない日本語の部分です。
例えば同じ書くにしても、
要件定義書を書くっていうのと自分の名前を書くだったら、
全然難易度が違うわけですよね。
なのでその条件のところと、
読んだり書いたり聞いたり話したりする対象の部分を変えることによって、
そのCan Do Statementのレベルを調整することができるわけです。
それで一定のそのコースにあったCan Do Statementをたくさんリスト化するという、
そういうのが普通はこの間にありますね。
その後で会話モデルっていうのを、
その後に僕が実際にこのITエンジニアのコース開発の過程でやったのが、
その会話モデルを作ったっていうことですね。
その会話モデルもたくさん作っておいて、
それでそこに必要な文法とか語彙とかがあるので、
あくまでも行動目標に必要な会話モデルを作って、
その会話モデルに必要な文法とか必要な言葉を言語知識として教えるという、
そういうスタンスになります。
だけど今の、この2022年の段階では、
第二言語習得の理論というのもだいぶそれから発展したんですよね。
2000年代の前半というのも第二言語習得というのはある程度はあって、
例えばクラッシュセンサーの大量のインプットとかそういうのもあったんですけど、
まだ僕のこの時にはそれほどたくさんの懲戒のインプットも用意して、
それでたくさん聞いてもらうとかそういうことはしてませんでしたけど、
今コース開発をするんだったらもちろんそういうことが中心になってくるんじゃないかなというふうに思いますね。
ここで今お話ししたようなことを実際に体験するコースというのが、
最初にも申し上げましたけど11月から始まります。
特にこの行動中心アプローチは、これまで海外中心だったんですけど、
日本の国内も文化庁の日本語教育参照枠で行動中心アプローチでいきましょうと明記されてあるので、
日本の国内の方も急に勉強しなきゃいけないことになっちゃったような人も
15:04
たくさんいらっしゃるんじゃないかと思います。
本当に今までの文系シラバスの教科書にただ単に行動目標をつけて、
それだけでは全然行動中心アプローチというものではないので、
文化庁の人とかはちゃんとその辺分かっている人がいますから、
そんなのダメですとか言われちゃうこともあるかもしれませんので、
本当に必要なある方はぜひ参加していただければと思います。
そのあとですね、Twitterの方でお申し込みの、仮のお申し込みのGoogleフォームなんですけど、
それをちょっと共有しておきますので、
ご関心のある方、必要のある方はそちらでお申し込みいただければと思います。
それではですね、リスナーの皆さんも、
もし今までこの行動中心アプローチに参加したことがないけど、
でも参加してみたいというふうに思う方がいらっしゃいましたら、
ハートのマークをいただけますでしょうか。
あるいは、既に参加したこともあるけど、
今度サポーターとして参加してみたいとかね、
そういう方も歓迎しますので、ぜひいらしてみてください。
それでは本日もムラスペにご参加くださいまして、ありがとうございました。
今日のですね、この行動中心アプローチのコース開発過程って、
そういう音声配信につきまして、
ご質問とか感想とかコメントとかありましたら、
ぜひムラスペのハッシュタグ付きでご共有いただければと思います。
それでは本日も良い一日をお過ごしください。
今夜の花錦で皆さんにお会いできることを楽しみにしております。
そして冒険は続きます。
