More than 5 years have passed since last update.

Timers inc

プログラミング教育論【双方の立場】

Last updated at 2018-07-31Posted at 2018-07-31

プログラミング教育

最近流行っていますね。

プログラミングに対する参入障壁の低下だったり、ITエンジニアへの需要増加の波もあるのでしょうか。

最近では、国家まで出ずっぱる勢いでございます。
小学校を中心としたプログラミング教育ポータル

中でも、社会人や就職控えた学生向けのサービスの隆盛が盛んかなと思います。

パッと思いつくところでも、こんだけサービスがあります。
TECH::CAMP
TECH ACADEMY
Code Camp
DIVE INTO CODE
Kredo
etc...

各サービスの詳細についてはここでは割愛します。以下ご参照ください。

双方の立場

かく言う自分も、野外でやってそうなプログラミング教育サービスでRailsでのwebアプリケーション開発を学び、 プログラミング教育を受ける立場 で全く関係のない業界、職種からエンジニアになりました。

そして現在、上記のバックグラウンドも幸いし似たようなサービスで現在は、 プログラミング教育を行う立場 をする機会を頂き、本業の隙間時間に従事させて頂いております。

双方を味わった人間はなかなかいないはず‥ということで、右も左も分からない人は何に困るのか、自分が感じるアンチパターンだったり、反省だったり、隆盛するプログラミング教育サービスに対して思うことを自分なりに書き綴ってみました。

仕事

Railsで以下の流れでWebアプリケーション開発から公開までの流れをマスターしてもらう(JavaScriptはやらない)

インターネットの基礎知識(クライアントとサーバ、HTTP、DNSなど)
HTML
CSS
Ruby
データベース(MySQL)
Sinatra
Rails
デプロイ(heroku)

といった具合にオブジェクト指向やMVCアーキテクチャを学び、カリキュラムに沿って最後に自由課題のサービスを完成させる、シンプルなカリキュラムをビデオチャット面談とテキストベースの質問対応によってサポートします。

やってみて

技術的な質問に対しては、暦1年で入った自分は、周りの百戦錬磨エンジニアたちの反応スピードが速すぎてついていくのが必死です。ですが、担当する生徒さんに色々な人がいて面白いし、わかりやすく説明することの難しさを感じテキストベースでも口頭でも噛み砕いて伝えることのいい練習になっています。
また、受講後の感謝の言葉が嬉しいです。はい。

今まで担当させてもらった方々

・マーケターで、エンジニアと円滑にコミュニケーションしたい！
・ブログ開設など、高い意識を実際に行動に移している将来有望な大学生
・Pythonを最近授業で触り始めたらしい大学院生さん
・コード書いてみたいインフラSEさん
・ブラックを抜けてエンジニアになりたい系さん。<-昔の自分のよう。このタイプが多いです。
・マシンはデュアルブート、本業で.NETを使いこなす俺より出来るんじゃないかっていう迷い込んできたさん
...などなど

この通り、様々なバックグラウンドの人がいて、話していて面白いです。
今のところ自分の担当には良識のある方ばかりだが、当然モンスター生徒もちらほらいるらしいですが...。

大体の生徒の受講理由は、 現状からの脱却を希望する 方が多数を占めている印象です。
かく言う自分もそうでした。

アンチパターン

※以下は決して偉そうに語っているのではなく、気づいたら自分もそうしてしまっていた！と言う経験があってのお話です。

被教育者視点 (教える側に思うこと)

わからない言葉を当たり前のように使う講師が多い

当初教育を受けていた際は、横文字を使いたがるなエンジニアという生き物はと感じていました。
今も思っている、というより他職種の人も横文字を使いたがる。Web業界特有なのかもしれないですね。
相手が知りたいことがなんなのか、うまく汲み取って例えたり噛み砕いたりできることはとても大切だと思います。

エラーケースをパターン化しがち

質問と回答にズレが生じることが多かったが、状況の推測が早とちりな人にはその傾向があった気がした。
話の途中なのに、相手は多分こうです！と言うのだが、そんなことはすでにもう試している、やってみて、ほれみろと感じることが多かった。
逆にいうと、教えるのが上手な人は断定せず、ソースを読んだ上で自分のマシン上で再現してみたり、相手の話を逆質問で噛み砕いたり、と相手の立場に立つことを大事にしていた所感です。

考える時間を与えない

よくあるのが、よくわからない(知らない)ツールを説明もなく使い出したり、間違っているロジックを追い出し全く違う実装をして、あっという間に解決してしまいこれでいいですか？のパターン。
生徒はとりあえずカリキュラム上の問題解決はできるが、**なぜ**がわかってないので同じ壁にすぐぶつかる。
これは受ける側が、今どうなってるんですか？なんでこうなるんですかと言う視点を持てる人であれば、聞けばいいので問題ないが、課題を解決することが目的になってしまう人もとても多いのであまりよろしくないと思う。
反対に上手だなと思う人は、逆質問をよくするように感じました。なんでこうなったと思う？や受講生が当たりをつけたエラー原因の根拠をなんで、なんでと問い詰めたり。

初心を忘れている

プログラミングに限らず、ありがちな話だと思うのですが、なんでこんなこともわからないの...?と言う態度がプンプン香ってくるパターンと、こんなことは説明しなくてもいいよね！という設定で話を進められてしまうパターンです。
横文字にも通底しますが、自分も最初は右も左もわからなかったはず。
コード読めばわかるでしょ、とかドキュメント読めばわかるでしょと言う態度は思っても出しちゃダメですね。

教育者視点 (教わる側に思うこと)

エラーメッセージを読まない

エラーメッセージを読まずに、動きません、エラーが出ましたどうすればいいですか、と質問してくる人はとても多いです。
まず、赤い画面と対話しなければ成長しないし、**カリキュラムを進めることが目的**になってしまっており、なんでできないのかを考えてもらえないケース。
もちろんカリキュラムは難しくなっていくので、受講期間に比例してだんだん質問の量が増えてきているのに何も理解していないと言う状況になる。
読んだ上で質問してくる人は、仮説を立てているのでそこから検証を始められるし、なぜ動かなかったのかを教えればすぐに納得して、次は自分で解決できるようになっているので受講期間に比例してだんだん質問の量が減っていきます。
エラーメッセージは嘘をつかない。落ち着いてエラーメッセージを読むことの大切さを教えてあげなければならないかな~と思いました。

課題の達成を学習と履き違えてしまう

受講して質問しただけ、長時間勉強して**満足**してしまっている人。
自分で理解して、どこがどうなっているのかを説明できなければなんの意味もないし、すぐ同じ壁にぶつかって堂々巡りになる。
クレーマー気質の人にはなぜかこのタイプが多い気がします。
知識が有機的に繋がるまで辛抱できず、挫けてしまう前に成長している感覚を覚えてもらうことが大切そうな所感です。

プログラミング/ITエンジニア至上主義

これは各プログラミングスクールの煽り文句の影響もあると思うのですが、短期間のブートキャンプでプログラミングを学べばエンジニアに必ずなれると思い、さらにエンジニアになれば時代の寵児になれると思っている人は多い気がします。
車の運転で言えば、実務に入ったらオートマとマニュアルくらいの違いはあると思っていた方がいいですし、向いてない人にはとても辛い仕事だと思います。
それにオートマで運転できない人はまともなところは雇ってくれないです。卒業した結果、エクセル職人になっているケースやそもそもプログラム書かないでパソコンの修理なんてケースはざらにあると思っていた方がいいです。というかそういったケースを間近でみました。
とは言え、しっかり取り組み、モノにしていく人はしっかり飛ぶべき場所に羽ばたいていきます。

〜って何ですかって聞かれやすい言葉

一部ですが、無意識に使ってしまってそれなんですかって言われる言葉はたくさんあります。
使われた当時に分からなかった言葉もたくさんありました。

継承
コールバック
ラッパー
エスケープ
バインド
プロトコル
名前空間
API
インターフェース
トランザクション
ノード
...etc

これらを噛み砕いて日本語で説明できますか？

特につまづきやすいところ

つまづくところは以下のように不思議と共通することが多いです。自分も理解するのに時間がかかった記憶があります。

RailsにおけるMVCアーキテクチャの流れを理解すること（特にModelの役割とRoutingの役割）
gitのステージ / コミット / プッシュの流れ、はたらき、ブランチの仕組み、有用性
Rails独自のヘルパー(prefix、redirectとrender、params、form_forなど)
migrationファイルとDBの関係性

思うこと

この学習初期の段階では、知識よりも、裏にある設計や抽象概念の理解が何よりも大切かなと思います。

そして、理解する上ではできるだけかみ砕ける言葉で説明した方がいいと思います。

簡単な例だと

クラス（設計図のようなもの）
インスタンス（実際に出来上がるもの）

みたいな感じです。
ただ、上記も例外はあると思っているし、何でもかんでもかみ砕くわけにもいかないとは思います、抽象的なものは抽象的なものとして覚えた方がいい場合もある気がするのでそこらへんは難しい気がします。

まとめ

周りのメンターはフリーランスバリバリの猛者だらけなので、技術力的には圧倒的に下っ端だと思っています。

ただ、コーチとメンターの違いでよく言われるが、一歩先を歩けていれば障害物の避け方だったり、その道の最短の歩き方は教えられます。
そして、同じような経験をした（0からの遅咲きエンジニアデビュー）からこそ、より近い視点に立てるのかなとも思います。
むしろ時間軸的に近い体験をしたのだから、わからない部分、つまづきやすい部分に寄り添える立場でいなければならないですね。

技術の進歩が学習スピードを凌駕していて、全てをカバーし切れないこの世界においては、教える立場はこうでもいい気がします。

だからこそ、自分には技術力がない、歴が経験が...などと言わず、積極的に教えるという行動はしていってもいいのかなと思います。

傑作、[SOFT SKILLS ソフトウェア開発者の人生マニュアル]
(https://www.amazon.co.jp/dp/B01GDS0994/ref=dp-kindle-redirect?_encoding=UTF8&btkr=10)でも、教えることが何よりの勉強になると書かれていました。

また、そういった噛み砕いてわかりやすく伝える技術はディレクターさんや社内の非技術職の方と話すときにとても大切かなと思います。

まとめると、以下が双方の立場に大事かなと個人的には思います。

教える人

エンジニアとしての自分なりの説明責任を背負う
状況を自分に当てはめない
考える導線を引く
初心をキープする

教わる人

まず自分で格闘してみる
考えて自分で解決できる素養を養う
目的を履き違えない
プログラミング至上主義のような近視眼的発想を持たない

なんてつらつらと偉そうなことを書きましたが、自分にはまだまだできていないことだらけです。
思いやりのあるエンジニアを目指して、皆さん頑張っていきましょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

プログラミング教育論 【双方の立場】