27_2ndプロジェクトのコンセプト 【山の日本語学校物語】

これは、とある町に開校した「山の日本語学校（仮名）」の物語です。PBL（Project-Based Learning：プロジェクト型学習）を通して、ITエンジニアがどのように言語を学び、専門性を身につけていったのか、また、語学を専門とする日本語学校が、どのような組織として、専門領域や地域社会と結びついていったのか、さらには、そこでの教師の役割などを探究していきます。

下記のマガジンで連載しています。

山の日本語学校物語｜ヒラサワエイコ｜note

前回は、1stプロジェクトから浮かび上がった問題点について整理しました。今回は、この問題点をもとに、どのようにプロジェクトのコンセプトを考えていったのかについてまとめてみたいと思います。

前回の記事で整理した問題点は、2つありました。

1. プロジェクトを「自分ごと」として捉えられない

2. 日本語学校とITエンジニアコミュニティが解離している

これらの問題点は、「山の日本語学校」に関わる会社役員やITエンジニアからの指摘から浮かび上がってきたものです。そこで、まず、役員やITエンジニアがどんな点に違和感を感じたのか、どんな点が問題だと思ったのかを徹底的に話し合いました。

そして、「日本語学校」の中にいる私たち、教師や学生と、その日本語学校を外からみている会社役員やITエンジニアとは、見えている世界がずいぶん違うということに気がつきました。それが「やらされている感」という印象につながったことは、前回の記事にも書きました。

さらに、この認識の違いが、「このまま日本語教師に任せておいて大丈夫なのか」という不信感にもつながっていると感じました。26回でまとめたような問題点があるのは認めた上で、この不信感を取り除いていく必要があります。この見えている世界の違いを埋めていかなければ、いつまで経っても、目指すべきITエンジニアコミュニティに近づけないと思いました。

今回は、「学校組織」の外側にいる役員らのやりとりから、この解離をどのように埋めていったのかを説明します。そして、それらのやりとりから要件を絞り、コンセプトのアイデアを着想したところまでを説明したいと思います。

認識のずれを探る

前回の記事にも書いたように、日本語学校の内側と外側からでは、見え方がずいぶんと違っていました。教師と学生という固定化された関係性や、点数による評価が日常的に行われている「学校文化」と、「企業文化」には大きな解離があることをこの時点で認識しました。

では、この認識の決定的な違いはどこから生まれたのか。まず、この点を考えてみたいと思います。といっても、当時の話し合いをすべて記録していたわけではありませんので、私の記憶と、説明のために作成した資料から考察していきたいと思います。

1stプロジェクトのプレゼンテーションを見た役員からは、日本語のうまい下手についての指摘はほとんどありませんでした。それよりも、プレゼンテーションやアイデアの質についての評価が中心でした。特に、ビジネスピッチを想像していた役員にとって、私たちが示したプレゼンテーションは、イメージが全く異なっていたようです。

日本語教師という立場から考えると、日本語の質についての言及がなかったということは、それほど、自然に日本語を使用していたということになります。日本語教育としては成功とも言えます。それなのに、来日して3か月で、プレゼンやアイデアの質まで求められても... という気持ちになりました。とはいえ、認識に大きなずれがあるのは間違いありません。

様々なやりとりを整理すると、特に以下の2つの違いが決定的であるように思いました。

1. 最終到達点のイメージ

2. 結果重視か、プロセス重視か

まず、最終的にどこに向かっているのかという到達点のイメージ自体が全く異なっていると感じました。例えば、「プレゼンテーション」です。思い描いていたイメージを共有するために、ビジネスピッチの動画をいくつか紹介してもらいました。確かに、学会等の口頭発表をイメージしていた私とは、全く質が異なるものでした。

こんなイメージの相違があるまま、プロジェクトを運営していては、ずれた方向へ進んでいってしまいます。不信感が生まれても当然です。ここは、早急に軌道修正が必要だと思いました。

次に、結果かプロセスかの問題です。私は、教務を運営する立場として、1年半のコースという枠組みで学習をデザインしています。1期目で結果が出せるとは思っておらず、コース全体を通して、何を学ぶのかというプロセスを重視しています。この点は、結果を重視する役員とは大きなずれがあると思いました。「学習」という視点で考えたとき、ここは、絶対に譲れないコアな部分であるため、なんとか理解してもらわなければと思いました。

認識の溝を埋める

認識のずれにあげた「最終到達点のイメージ」については、これは、もう私自身が学ぶしかありません。このずれが、前回の記事にも書いた「問題点」にもつながっているからです。そのためには、最終イメージのすり合わせが必要です。ここは、私自身の問題です。

その点を踏まえた上で、最終イメージに到達するためには、ある程度の時間が必要であること、そして、そのプロセスに「学び」があり、だからこそ、PBLという学習形態をとっているのだということを説明することにしました。これは、「山の日本語学校」のあり方にも関係する、非常に重要な部分です。

そこで、卒業時には、どのような状態になっているのかという長期的な目標とそこに到達するまでの中期的な目標（各学期の到達点）をA4、1枚にまとめ、それを叩き台に話し合いをしました。具体的には、以下の概要を図式化して提示しました。

• 1期目：これから学ぶべきものは何かを知る

• 2期目：自分のやりたいことを掘り起こす

• 3期目：自分の関心をもとにリサーチをする

• 4期目：プロトタイプの制作

• 卒業プロジェクト：プロダクト制作

卒業プロジェクトの段階で、企業のコンペなどに参加できるようなプロダクト制作を目指すという最終目標を提示し、そのためにはどのようなプロセスが必要なのかを話し合いました。

この話し合いの結果、このような最終目標を設定するのであれば、起業家やITエンジニアの視点が欠かせないという指摘を受けました。一方で、私は、ただIT技術を身につけるだけでなく、自分が何をしたいのかという自身の関心を掘り起こすための活動が必至であるという主張をしました。それをしなければ、いくら技術面のサポートをしても、「やらされている感」は、拭えないだろうと判断したからです。

もちろん、これに「日本語学習」の要素を絡めていくことになります。しかし、どのプロセスにおいても、「言語」は重要な要素であり、言語学習を活動のベースに据えることは可能だと思っていました。ただ、その部分を前面に押し出すと焦点がぼやけてしまうので、日本語の部分はあえて詳細に説明しませんでした。当時の検討資料を見ても、「日本語」については、ほとんど言及していません。かなり相手の懐に飛び込んで話を進めていたようです。

コンセプトのアイデアを着想する

以上のような話し合いのプロセスを経て、2ndプロジェクトの要件を抽出しました。活動要件は、以下の3点です。

• 自分の関心ごとを掘り起こすことができる活動を設定する

• ITエンジニアを講師として招き、エンジニアから直接学ぶ機会をつくる

• 言語活動を枠組みのベースに据える

要件の一つとして、ITエンジニアを講師に招くことが提案されました。といっても、学生が得意とする領域や技術は、それぞれ違います。全員が一斉に同じ技術を学ぶのは無理があると思いました。それに、「やりたい」と思うことがあれば、最新技術を学ぶ方法はいくらでもあるだろうと思いました。自分のやりたいことがはっきり定まっていない今の段階では、いくら技術を学んでも、それこそ「学ばされている」という状態になってしまいます。

学生全員が必要とする「学び」とは何かを考えたとき、現段階では、第一戦で活躍するITエンジニアが、どのようにしてキャリアを築いてきたのかを知ることの方が優先順位が高いと考えました。

さらに、ITエンジニアは最先端の技術に触れながら、これからの未来を創っていく職業でもあります。ITエンジニアとして、どのような未来社会を指向しているのかを聞いてみるのもおもしろいのではないかと感じました。未来を指向することによって、最新の技術についても触れることになるだろうと予想しました。

こんなことを想像しながら、2ndプロジェクトのコンセプトを考えたとき、それぞれがどのような未来を考えているのかを形にしてみたらどうだろうかと思いました。未来を考えることは、自分のキャリアを考えることにもつながります。それぞれが妄想する未来には、自分の関心ごとが反映されるだろうと思いました。

さらには、自分がどのような未来を創りたいと思っているのか、それはなぜか。「私」を主語として言語化する作業は、言語活動の中心的な活動とも言えます。

こんな漠然としたアイデア（妄想の連鎖？）から、2ndプロジェクトのコンセプトを「私の未来予想図」としたらどうだろうと思いました。

役員やエンジニアに、このアイデアを提案したところ「それはおもしろそうだ」ということになり、このコンセプトをもとに、2ndプロジェクトをデザインしていくことになりました。

以上のように言語化すると、何かスルスルと事が進んでいるように感じるかもしれませんが、実際には、ここにたどり着くまで、心が折れそうなくらいしつこいやりとりをしました。問題点についても何度も観察記録を読み直し、詳細に分析しています。このような試行錯誤の繰り返しからコンセプトの着想に至りました。うまく論理的に説明できないのですが、何ていうか、こういうアイデアって、ある日ふと降りてくるのです。

ということで、現状から分析、整理した問題点（26回）と、話し合いによって導き出された要件をもとに、何とかコンセプトのアイデアを着想するところまでたどり着きました。次回は、このコンセプトをもとに、2ndプロジェクトの目標を設定していきます。

参考文献

今回は、学校文化の外側にいる会社役員やITエンジニアとの話し合いをもとに、コンセプトを着想するまでのプロセスを描きました。ここでは、「話し合い」や「やりとり」という言葉を使用していますが、お互いの認識のずれをすり合わせていく作業は、まさに「対話」だったと思います。

最近よく聞くようになった「対話」という言葉は、非常に広い意味で使われているように思います。誤解を招きかねないので、今回の記事では、あえて「対話」という言葉は使用しませんでしたが、以下の書籍に今回の「対話」のプロセスが説明されていると思いました。