顧問
本記事では、
未経験者がプログラミングを学ぶのにマンツーマンがいらない理由
を解説していきたいと思います。
未経験者
未経験者
未経験者
あなたがこの記事を読む事で
- プログラミングがなぜ挫折するのか
- プログラミングを挫折せずに学ぶ方法
- プログラミング以前に身につけなければいけない能力
- プロとアマチュアITエンジニアとの違い
が分かるようになるでしょう。
ITエンジニアが何かよくわからない。という方は「プログラマー」や「システムエンジニア」と呼ばれる人たちの総称だと覚えておきましょう。
プログラミング未経験者が迷うIT業界の職種用語を徹底解説!目次
挫折率9割は完全独学の場合
プログラミングの挫折率は9割だ。
こういう言葉が、いつの間にやらよく脅し文句のように使われていますが、実際のところ本当にそうだなと思います。
私自身も独学未経験からいきなりプロのフリーランスITエンジニアとして7年以上バリバリと仕事をしていますが、独学していた当時は挫折の連続でした。
何度、ノートパソコンを逆パカにしてやろうと思ったことか。(逆パカってガラケー世代ならわかりますよね?)
私自身は根気のあるタイプですし、状況的に後が無い環境だったので、それでもやり遂げることはできましたが、「じゃあ、普通の人がクリアできるか?」というとやはり9割以上は挫折するだろうな。と実体験からも思います。
しかし、それは
完全独学だった場合のお話
です。
なぜなら、そもそもIT業界の教材の質が悪い、教え方が悪いからです。
知の呪縛による教材の質、教え方の問題
今でこそ、若干改善はされているものの未だ変わってはいません。
なぜかというと
知の呪縛
というものがあるからです。私の知り合いで保険営業マンで1億円プレーヤーをしていて、現在は大学で営業を学問として教えている方がいるのですが、しきりにこれを話しています。
知っているからこそ、知っているテイで話を進めてしまう
営業の世界でもお客さんに対して契約の取れない営業マンがよくやってしまうもので、業界ではよく「お客さんのおいてけぼり(おーい、お客さん置いてってるぞー。と上司にロープレでよく指導されます)」と呼ばれています。
僕はずっと営業をやっていたのでここらへんは容易いんですが、ITエンジニアが教えるとなると面白いくらいに99%が途端に「わかったテイ」で教え始めてしまいます。教材を作る時にも何人もの現役エンジニアに依頼したのですが、結局出来上がってきたものは未経験素人から見たらわけのわからない説明と内容だったので結局僕が全て作り直すほどという状況なんですね。
質問してきちんと初心者に分かる言葉で解決をしてくれる相手がいない
プログラミング未経験の方の恐らく99%は「質問出来る相手がいない」だと思います。
「よくわからないエラーが出てくる。参考書にはそんなこと書いてない。。」
「説明している単語自体わからない。解説の解説が欲しい。。」
「思った通りにならない。。参考書の通りにならない。。」
「作りたい機能があるが、どうググっていいのかググるキーワードがわからない。。」
「モチベーションが。。」
たまに「覚える事が多い。。」みたいな「いや、それは英語学習でもなんでもそうでしょ」という愚痴的なものもありますが要するに
「質問できる相手がいない」わけですね。モチベーションというのも「質問できず、解決できず、わからない」から「モチベーションが落ちていく」わけですから。
さらにもっと言えば
「質問してきちんと初心者に分かる言葉で解決をしてくれる相手がいない」
という事になります。
今でも「stackoverflow」なり「teratail」なり技術に関しての質問サービスがありますが、こういうサービスは僕も独学時に使った事がありますが、ほとんどの場合、未経験者にわからない単語を更に増やす解説をしてくるので、結局解決できない事の方がほとんどなんですよね。
質問できる環境はあれど「解決できるような初心者レベルでの解説を行なってくれる」環境ではないわけです。
中級レベルから一気に難解度が上がる
更に言えば、初心者向けの参考書であれば結構わかりやす物はゴロゴロあります。
HPを作るとか程度の「HP制作レベル(web制作レベル)」のやつであれば。です。
でも、いざ「webシステム開発」と呼ばれるような中級レベルのものになってくると途端に壁が厚くなってしまうんです。
「いや、いきなり壁厚くない?」
「高低差ありすぎて耳キーンなるわ。」
「子供の頃の孫悟空に対して、いきなり魔人ブウと戦えと?」
もう、ホントそんな感じです。
僕は魔神ブウと戦ってなんとか勝てましたが、ほとんどの未経験者は死んでいく事でしょう。(何度もいいますが、1000回はPCを逆パカしてやろうと思いました)
今でこそ、progateやら初心者向けサービスも充実はしていますが、それも結局は初心者向けです。実務に耐えうるものではなく、実務レベルとなってくると一気に未経験者にはまず登れない壁になってしまいます。僕も当時はprogateやスクールすらほぼなく、ドットインストールでサイコロを作って「で?」という環境でした。
- 質問してきちんと初心者に分かる言葉で解決をしてくれる相手がいないから挫折する
- 「知の呪縛」で「分かっているテイ」で教えてしまう教材がほとんど
- 中級者レベルになるほど一気に難易度が上がってしまう
挫折は教材の質、教える方が原因な事がほぼ
さっきの話でも出たようにそもそも教材がきちんとしていれば、乗り越えられるわけです。
「そんなばかな」と思うかもしれませんが、
例えばうちのウェブカツ場合だと「オンライン自習型」にも関わらず、理解ができずに挫折してしまう人は1割程度しかいません。
しかも、未経験者が趣味レベルのものを作るのではなく、
現役エンジニアも通うほどのプロレベルを教えていて挫折率1割ほどという業界では驚異的な数字なようですが、他社さんのマンツーマン型だと「未経験者9◯%」みたいな英会話で言えば「日常英会話レベルを教えている」状態で挫折率数%という状態です。
まず、「教材がテキストベースの文字だけ」というのはアウトです。
調べるとわかりますが、テキストベースの教材を使っているところほど必ずマンツーマンレッスンですよね。なぜかと言えば、「その教材では理解できないから」なわけです。
英語であればテキストだけでも理解は出来ますが、ITエンジニアというのは「建築家」と実際やっている事が同じなため、初心者ほど「動きのあるイメージで掴む」という事がとても大切になります。
テキストベースでの読み物形式のものよりは、イラストを多用して動きが伴った「動画形式」の方が格段にわかりやすいですし、専門用語を「分かったテイ」でなくきちんと解説してくれ、例を使って身近なものに例えるといった事をしているかが重要になります。
ただし、最終的にはテキストベースで理解できなければいけません。
なぜなら、「ドキュメント」と呼ばれるプログラミング言語の公式サイトであったり、仕事をしている中で不具合で「動かない」といった時の解決法なりは「ブログ」からでしかまずもって収集出来ないからです。
なので少しずつステップアップできるようにウェブカツでも動画形式からテキストベースに少しずつ移行していけるカリキュラムになっています。
冒頭で出てきたように
「よくわからないエラーが出てくる。参考書にはそんなこと書いてない。。」
「説明している単語自体わからない。解説の解説が欲しい。。」
「思った通りにならない。。参考書の通りにならない。。」
「作りたい機能があるが、どうググっていいのかググるキーワードがわからない。。」
というものも、結局は出てくるエラーがどんなものがあるのか説明してあればいいわけですし、専門用語を説明し、ググり方も前もって教えてあげればいいわけです。
ウェブカツの例だとカリキュラムが全て決まっている分、
「未経験者が陥る不具合」「未経験者が詰まる箇所」
がほぼ全て決まっています。さらには今までの先輩達が質問した内容が全てレッスンごとに閲覧出来るので詰まった時にはそこを見てしまえば解決してしまうんですね。
実際に40代の未経験主婦の方でも質問は結局1回しかせずに卒業されて就職しています。
40代主婦からの現役エンジニアに聞いたウェブカツのいいところ先輩達の通ってきた軌跡すべてがカリキュラムの一部となっているわけですね。
これが、「自分の好きなものを作るカリキュラム」の場合だとそうはいきません。
ただし、「自分の好きなものを作るカリキュラム」は仕事にしたいのならやめた方がいいと断言しておきます。
別にスクール経営しているからポジショントークしたいというわけではなく、現役エンジニアとして第一線で活躍する中で確実に感じているところです。
なぜなのか?はまたあとでお話していきます。
- 挫折は教材の質や教え方が原因であって、人がいないことではない
- 初心者ほど「動きのあるイメージで掴む」という事がとても大切
- 最終的にはテキストベースで理解できなければいけない
英会話と違い、人相手に話さなければ身につかないものではない
プログラミング「言語」と呼ばれるようにプログラミング学習は英会話学習にも似ていますが唯一違う点があります。
それが
人との会話ではなく、機械との会話
という点です。
英会話であれば「会話」と呼ばれるようにマンツーマンで相手がいなければ会話力は成長しませんが、プログラミングはというと「パソコンと会話する」ことでしか成長出来ないのです。
「パソコンと会話する」なんて、なんかオタッキーな感じもしますが、実際そうなんです。
パソコンとどんどん会話をしない限り、プログラミング言語という「語学の会話力」は上がらないんですね。
いくらマンツーマンで人と会話をしたところで、絶対にプログラミングとしての会話力は上がりません。
- プログラミング学習は人との会話ではなく、機械との会話
- 人とでなくパソコンと会話をしなければプログラミング会話力は上がらない
仕事にしたいなら「自走力」は必要不可欠
プログラミングを趣味にしたいのなら別ですが、
「ITエンジニアとしてプログラミングを学んで仕事にしたい」という人であれば「自走力」は必要不可欠です。
知らないことを明日から自力でやらなければいけない
なぜなら、
来週までに知らない事を自ら調べてやり通さなければならない
ということが実際の仕事現場では往々にしてあるからです。
仕事としてお金をいただいている以上、「出来ません」で通すことなど出来ません。
そんな時、上司に聞いてばかり、周りに聞いてばかりでは仕事になりません。
(もちろん、流石にレベルが高すぎる。現実的でない。とかってものは「出来ません」とちゃんと言いましょう)
上司は上司で仕事があり、周りは周りで仕事があるからです。あなたが質問に1時間費やすことで、上司の1時間を奪うことになり、その上司の時給はあなたよりも高いのです。周りに聞けば、周りの仕事が止まります。仕事が止まれば、プロジェクトがその分遅れます。
もちろん、「聞くな」というわけではないですし、実際現役エンジニア達も質問し合いながら仕事をしています。ですが、そこの根本を理解せずあれもこれもおんぶに抱っこで質問していると仕事現場では確実に「ダメ人材」確定です。
ウェブカツの例だとわざと「スムーズにいかない箇所」をいくつか作っています。また、わざと「教えない部分」も作っています。
わざとそうするのもこの現場で必ず必要になる「自走力」を鍛えるために他なりません。
マンツーマンだと相手がいますし気軽に聞けます。その分、甘えが出てくるのも事実です。
自分で調べ、自分で解決する能力
すなわち
自走力
は甘えている限りは培うことはできません。
相手の要望に沿ったものがきちんと作れる力が必要不可欠
また、実際の仕事現場では「お客さん」が必ず存在します。
お客さんの「要望」があり、その要望を汲み取って形にしていくのが「仕事」です。
特に副業など個人受注案件というものになれば「相手はIT素人」という場合も多く、「漠然としたイメージ」をちゃんとヒアリングし汲み取った上で「具体化してあげる」作業が必ず発生します。その上での「要望通りに作る」なわけです。
なので、「この機能作れないから外そう」とか「わからないからこのままでいっか」なんてことは仕事現場では許されないわけです。
当たり前ですよね。
例えば、あなたが建築士に何千万も払って家を建てる契約をしたのに
「ちょっと難しいんでこのドアノブなくしちゃってますー」
「時間なかったんでトイレは取り付けてませんけどいいっすよね?」
「風呂場は僕が好きな全面ガラス張りにしときましたよ!」
なんて事が許されるわけがありませんよね。。
ウェブカツではこういったいわゆる「現場力」をきちんと養える様に生徒さんはランダムな複数の「要件定義書」と呼ばれる実際の現場に沿った「仕様書」が渡され、試験官を対お客さんと想定してのヒアリングやコミュニケーションを行い、「決められた納期」の中でシステム開発を行った上で試験官のレビューを受けるようにしていますが、
「自分が好きなものを作る力」のその先の
「相手の要望に沿って納期が決まっている中で作れる力」が実際の仕事では必要不可欠になるわけです。
- 自走力はおんぶに抱っこでは鍛えられない
- 知らないことを明日から自力でやらなければいけないことが多々ある
- 周りに聞いてばかりでは仕事にならない
- 自分の好きなものが作れるその先の相手の要望に沿ったものがきちんと作れる力が必要不可欠
もちろん、レビューは必須
とはいえ、もちろん「人」はある程度は必要になります。
「レビュー」と呼ばれる「プログラムに欠陥がないか」「システムに欠陥がないか」といったフィードバックは未経験者ほど必須です。
なぜかというと未経験者の99%が作るプログラムというのは欠陥だらけだからです。
因みにうちでは経験者、未経験者向けでいくつもの要件の中からランダムで決まったものを作っていくんですが、そのレビュー項目は100項目以上にも及びます。
機能が顧客の要望通り満たされているかという「機能要件」と呼ばれる項目だけでなく、「使いやすさ(ユーザビリティ)」や「デザイン」「UI・UX」と呼ばれる仕様には書かれていない部分の「非機能要件」に至るまでのレビューを1次レビューと2次レビューの2回に分けて行なっていますが、そうするとやはり未経験者は必ず1次レビューで「欠陥だらけ」という状態に陥ります。
こういったように実際、初心者のほとんどが欠陥住宅を作る建築士のような状態です。でも、外観とか見た目は全く同じにしか見えないんです。それでも、プロから見れば分かりますし、それでは仕事としては大問題なわけですね。
素人目にはわからない家のちょっとの歪みもプロレベルではすぐ気づきますし、その歪みがどこに影響してしまうのかも想像出来るわけです。
現実の建築士でもきちんと建てるところもあれば欠陥だらけの家を作る人もいますよね。(もちろん、大抵は「あえて」わかっててやってるわけですが)
ITエンジニアも同じです。
だから、必ず仕事してやるのであればプロの目というものが初期の頃ほど必須になります。
また、学習初期の頃ほど「テスト」がとても大事になります。(ずっと大事ですが)
家も「耐震検査」なり「構造上問題がないか」などテストを必ずしますが、システムも同じです。どういうテストが必要か、どういうテストをするべきかという「勘所」のようなものを早めに養っておかないといつまで経っても欠陥住宅を作り続けることになります。
こういったのはウェブカツ の場合は「テスト部」というところでテストケースの作成やテストコード、テストライブラリといったものを学んでいきますが、こういったものは
好きなものを好きな様に作っていたのでは一向に身につくことはありません。
仕事である以上は「ハリボテの家」をいくら作ってもダメなんです。
- 未経験者ほどプロのレビューは必須
- 未経験者は必ず「欠陥だらけ」のシステムを作っている
- 未経験者ほど「テスト」を学ぶことが重要
まとめ
挫折するというのは結局のところ「わかりにくさ」でしかないんですね。
わかりにくい教材を補うために単に人でカバーしているのが現状です。
ウェブカツでも1回から使えるマンツーマンレッスンチケットがあるので、「ここだけどうしても直接教えてもらいたい」という場合には対応できる体制になっていますが、実際使う人はほぼいません。