プログラミング学習のスケジューリング

なぜプログラミング学習で挫折するのか？

プログラミングを難しくしている要因

割とよく話されているかと思うのですが、前提を合わせるためにも簡単に触れていきます。

ざっくりまとめるとプログラミング学習を難しくしている要因はこの辺りにあるのかなと思っています。

必要な知識量の膨大さ
非エンジニアリングにはない独特の概念・文化への適応の難しさ
膨大な知識量をカバーするための計画と実行の難しさ

いくつか要因は上げましたが、本当にゼロから始めた場合極論1週間とかそこらで修得できる物でもなく、エントリーレベルのエンジニアになるまでに必要な知識量の大さが1番の要因になっており、その知識量をなんとかするためのソフトウエアエンジニアの文化への慣れとか長期に及ぶ勉強期間をどう管理していくかみたいな問題が付随してやってくるという形です。

エンジニアになるために必要な知識

知識が膨大だみたいな話をしていても具体性がないので、じゃあ例えばどの辺りのことを理解しておく必要があるの？となるとおもうのですが、僕がMENTAで教えているフロントエンドのコースでは、

ITの基礎・・・webの仕組み、ハードウェアの仕組み、ネットワークなど
HTML/CSS・・・数ページの静的なwebページが作れるくらい
JavaScript・・基礎的な文法などなど、フォームバリデーションなどなど
サーバーサイド・・node.js,ruby, pythonなど何でも良いのでCRUDができるweb APIがつくれる。
Linux・・コマンドライン操作、linuxのファイルシステム、ディレクトリ構造などについて
バージョン管理・・git の使い方、ブランチ運用

あたりの知識をベースに、+α Reactなどのフロントエンドフレームワークを使えるようになると良いというようなことを案内させてもらっています。

みてわかるようにそれぞれ1項目を倒すだけでも結構時間が必要になるのとそれぞれの知識は繋がっているようで、各項目ごと違った癖があったりで日々勉強をしているメンティーさんを見ると本当に頑張ってるなと感じます。

解決策: スケージューリングにこだわる

ここまでエンジニアになるためには膨大な量3ヶ月〜半年くらいは少なくともしっかり計画たててコツコツ勉強しないといけなく、一筋縄にはいかないことがわかったと思います。で、ここからが本題なのですが、日々メンティーさんの勉強の様子だったり、相談を受けた時に「計画段階で結構失敗しているなぁ」という印象を受けることがあります。

僕自身最初のメンタリングでは、学習の計画について聞くことがあるんですが、計画を聞くとだいたい6ヶ月後を目処に転職したいみたいな時期感は出てくるのですが、その目標を達成するために「自分がどうなっていれば良いのか？どういう知識を得ていればよいのか？」みたいな所の解像度粗いというのがよくあります。

転職までの期間が6ヶ月だとするとインプット重視の基礎を整えられる時間は、ポートフォリオの作成期間や面接を受ける期間でだいたい最初の3か月くらいかと思うのですが、その中で上のような知識を網羅しようとなるとかなり忙しいですし本当に土日返上+平日は勉強しないと間に合わなかったりするはずです。なんですが、ここがあまり明確に意識できておらず1日に十分な勉強時間が確保できておらずどんどんスケジュールが後ろに倒れていってしまい、いつしか熱も冷めてしまい・・となりがちです。

と言った形でここまでが問題提起です。少なくない数の学習者さんがここのスケジューリングを改善すれうばもっとよくなる気がしたので今一度計画を見直すキッカケになればと思います。

勉強の計画の立て方

スケジューリングの大切さを語ったところで、ざっくり下記がそのステップになります。

転職する時期を決める
面接で聞かれる内容、アピールする内容をイメージする
ポートフォリオで作るものを決める(求人を参考にする)
テーマ毎の粒度で中期の勉強計画をたてる
1日に必要な勉強時間・勉強内容をきめる
1日単位・週単位で振り返りを行い計画を修正する。(時期が迫ったら機能をドロップする短期で補える方法を模索する)

面接でアピールする内容を先に決めておく、1日に必要な勉強時間・勉強内容をきめる あたりがポイントかと思っていますが、目標を明確にししてそれを1日の具体的なアクションに落とし込む、適宜進捗を見ながら軌道修正を行うあたりが大切になってきます。

1. 転職する時期を決める

言葉通りですが、全くのゼロから始めるのであれば少なくとも6ヶ月くらいのタイムスパンは必要かと思います。3ヶ月とかなると元々やってなかったりするとかなりキツイとは思うので、半年程度が妥当なラインかと思います。

2. 面接でアピールする内容を決める

転職を考えている方は、面接で話す内容を学習開始段階から考えておけると良いでしょう。

転職活動を始める時の前の期間はプログラミング自体の勉強やポートフォリオ作成などを行う準備期間になると思いますが、ここで何をやっておく必要があるのか？ということを明確にするためにも面接でアピールする内容を決めておけると良いでしょう。

面接で語る内容を具現化したものがポートフォリオで、そのポートフォリを作るための知識を日々の学習で身につける。

という考え方が根幹になります。

アピールと言っても100人に1人しか出来ないみたいな事をアピールする必要はなく、各社選考の基準は違うかと思いますがだいたい「webアプリのバックエンドからフロントエンドをざっくり作った経験があり仕組みを理解しているまたは入社後にキャッチアップできる」という部分を納得させられる程度のアピールができれば良いのであまり難しく考える必要はないです。あとは自分の中で目指したいエンジニア像みたいな物があればそれがアピール出来るようにその要素を自分のポートフォリオに盛り込めると良いでしょう。

このアピールする内容を決めるというのは限られた期間で「何をする必要があり、何をやらないのか」を決める所がゴールです。裏を返すと、面接で語る必要のないことはあまりやる必要がないです。（将来的に現場で必要な可能性もありますが、短期的に効率よく成長するためにはいち早く現場の経験を詰めることが第一と考えているので、面接時点で不要な知識は一旦据え置きます）

3. ポートフォリオで作るものを決める

ポートフォリオを作る時に考えるべきことは

面接あるいは書類選考でアピールするための機能が揃っているか？
必要な技術スタックを網羅しているか？
選考に足る複雑度のあるアプリであるか？

あたりです。

1. については自分がデザインとフロントエンドに興味があるならUIの実装にこだわってみる。フロントに加えてサーバも出来るようになってフルスタックに働きたいなどあれば、サーバサイド側で定時実行のバッチ処理を実装して組み込むなどのようにエンジニアとしての色が分かるように成果物を考える。

2. については自分が志望している業界・会社の技術スタックに合わない技術を使っているまたは不十分だったりするとそもそも面接にも進めなかったりするので自分が作ろうとしているポートフォリオにどのように技術スタックを取り込むかという形になるかと思います。必要なスタッフの確認は適宜wantedly,greenなどなど海外ならLinkedinなどなどIT系企業の求人が載っているサイトを見ると結構キーワードでリストアップされているのでいくつか求人をみて頻出な技術スタックを盛り込むようにすると良いです。

3. については、やはりtodoアプリでページ遷移なしのポートフォリオを持っていってもプログラミング経験はあるのはわかりますが、その人が現場のシステムを理解してプロジェクトにフィットできるかどうかのイメージは湧かないので、バック・フロントがあってawsやherokuなどにホストされていて、

よくあるwebサービスの

ログイン機能
ユーザーページ
サービスの根幹を実現する機能(CRUD+αを実装したもの)

あたりは実装されている必要があると思います。

またポートフォリオを考える時に

ポートフォリオのサービスを説明する文章
使用する技術スタック
簡単な機能がわかるワイヤーフレーム(Figmaなどのツールを使ってもよいし、手書きでも可)

あたりをざっくり書き出してみると頭で考えるよりはよりクリアにイメージできるでしょう。学習を始めるまでにここをやっておくと学ぶべき内容もクリアになるので良いかと思います。

4. テーマ毎の粒度で中期の勉強計画をたてる

上記で作成するポートフォリオを決めて、使用する技術スタックがわかったらあとはそれらを一つずつ学んでいければ良いでしょう。何をどれくらい勉強すれば良いかを調べるのはなかなか難しいですが、HTML/CSS、Reactみたいな粒度だったりすると何を学べば良いのかわからなかったりするので、 Reactだったら、

Reactの概要
ステートとProps
クラスコンポーネントと関数コンポーネント
hooks API(useState, useCallback, useEffect)
パフォーマンス最適化
useRefなどのそのほかのHooks

などなある程度トピックを書き出してそれぞれを勉強してみる形が良いでしょう。勉強する際にも何を学ぶのか？を明確にしておかないと何をして良いかわからなくてモチベーションが下がってしまうので、学ぶ内容をできるだけ細分化できると良いです。

ある程度細分化ができたらそれぞれの項目にかける時間を書き出してみてまとめて、それぞれに必要そうな勉強時間を割り出しましょう。

ここで実際の学習を進める時に気をつけるのは、ドキュメントを読むなどインプット自体はあまり時間をかけ過ぎなくてよくて「こういった項目がなんとなくあるんだな」という形であとで検索できたり戻ってきて読み直したりする程度で大丈夫です。最終的な業務を考えた時は「手を動かして作れる」ようになっていることが目標なのでしっかり普段からコードを書いて、アプリを作る過程に体を慣していけると良いでしょう。

6ヶ月くらいでフロントエンドで転職を考えているのであれば 3ヶ月のうちに

学習内容	期間
HTML/CSS	1週間
JSの勉強	1週間
Reactの勉強	1週間
Reactを使った簡単なアプリ作成	1週間
React, Reduxを使った簡単なアプリ作成	1週間
React+Redux+API通信を使った簡単なアプリ作成	1週間
Linuxの学習（コマンドラインやディレクトリ構造など）	1週間
MySQLなどのデータベースの学習	1週間
ブログのCRUDをできるようなWeb APIを MySQL+Express.js で作成	1週間
自前Web APIとReactを統合したアプリ実装	1週間

計 10週間

のような形で計画を立てられると良いでしょう。それぞれの項目の中には先程のステップで細分化した内容を順番に勉強していくような形です。また〜の学習、勉強のようなアプリ作成と書いていないような項目でもそれぞれなんらかのアウトプットを出すようにすると良いです。

HTML/CSSの学習であれば一つサイトの１ページを模写してみる、色の着いた四角い要素をよくあるサイトレイアウトに並べてみる、
Reactなら自分で設計をして◯×ゲームを実装してみる

のように自分の練習として、お題を考えて実装してみると学習効率が上がると思います。 Udemyのチュートリアルのようなものでも最初は良いのですが、自分で設計して実装した方が力は着くので、チュートリアル→自作アプリの順番で練習すると良いでしょう。

上の例では10週間で3ヶ月未満で書いていますが、おそらく学習しているうちに必要な要素が出てきたり想定外のこともあるのである程度バッファをとってスケジュールを引きます。

そのほか基本情報技術者試験に出てくるような情報処理的な知識も補完しながら進む必要があるので、適宜勉強の合間や移動時間などの隙間時間を見つけて学習できると良いでしょう。

5. 1日に必要な勉強時間・勉強内容をきめる

ここまでブレイクダウンできたらあとは1日に必要な勉強時間と1日のうちのどの時間帯に勉強するか、勉強内容を決めます。

勉強する中でも

テキストを読むだけですむもの
コードを書いて動かす必要があるもの

の二種類に分かれるので、読むだけで済み机に向かっていなくてもできるものは隙間時間に行うようにしたり勉強に疲れてゴロゴロするときになんとなく眺める。みたいな形で効率よく勉強できるように工夫しましょう。同じテキストの同じ文を繰り返し参照するようにすると記憶に残りやすいので、テキストやドキュメント記事は繰り返し読むのがおすすめです。

プログラミング学習は長い道のりですが、やはり一日の積み重ねが将来的な地力に繋がるのと時間が飽くと内容を忘れてしまい効率が悪いので机に向かわなくても勉強できる方法を確立して忙しい日でも勉強できると良いです。

また、6ヶ月などの遠い目標を達成するのに大まかな目標しかないと具体的なアクションが取れないので、

1日何時間程度勉強するのか？
何を勉強するのか？
どのように勉強をするのか？

というのを明確にして勉強できると達成感を感じながら学習を進められるので結果も違ってくると思います。

6. 1日単位・週単位で振り返りを行い計画を修正する

1日単位でのアクションプランが練れたら、簡単にで良いので定期的に計画の振り返りを行って計画を修正するようにしましょう。意外とReactのアプリ作成に時間が必要になったらその分他のスケジュールなどが後ろ倒しになるので、それの影響をみて「全体を終わらせる必要があるのに、一つのトピックに止まり過ぎていないか？」などなるべく長期的な視点にたって勉強のし過ぎや勉強のペースを考えて修正を行っていきましょう。

ここでの注意点は、細かい4.で決めたような中長期のスケージュールは動かしても良いのですが、6ヶ月で転職などのような 大きなスケジュールはなるべく変えない ことです。全体のスケジュールを伸ばしすぎると勉強が苦しくなってしまって挫折したりするので大きなスケジュールは変えずに「勉強する内容を少し削る」「ポートフォリオにつける機能を減らす」などして計画を調整できると良いです。

スケジュールを伸ばしに伸ばして打席に立てなくなると、自分に足りていない要素を見つけたり課題に気づいたりという機会が極端に減ってしまうので、計画後半の方で発生した遅延はやることを減らすことで対処しながらあとは対外的な面接などを通して自分の弱点を補いながら転職に繋げていくという方針が時間効率が良いです。

スケジューリングのまとめ

ここまででスケジューリングの方法は一通り説明できました。

転職する時期を決める
面接で聞かれる内容、アピールする内容をイメージする
ポートフォリオで作るものを決める(求人を参考にする)
テーマ毎の粒度で中期の勉強計画をたてる
1日に必要な勉強時間・勉強内容をきめる
1日単位・週単位で振り返りを行い計画を修正する。(時期が迫ったら機能をドロップする短期で補える方法を模索する)

繰り返しにはなりますが、1日1日のアクションプランと振り返り、面接でアピールする内容から逆算したポートフォリオを作るというのがおすすめですので、参考にしていただけると嬉しいです。ここまででスケジューリングの話は終わりですが、つぎに計画を立てる時や学習中の注意点みたいなものをまとめて終わりにします。

学習計画を立てる時・学習期間のNG集

スケジューリングの考え方は流れで説明しましたが、個人的に思う学習の効率を下げている習慣をまとめたので書いておきます。こちらに着いては賛否あるものもあるかもしれませんが一意見として気に留めておいて頂けると良いかと思います。

学習する内容・目的が不明瞭

上の説明でも、何回か書きましたが学習の目的を絞って学習するのがモチベーション維持の観点でも非常に大切です。「今日はHTML/CSSの学習をしよう！」みたいな粒度だと甘いので「Flexboxを使ったレイアウトの方法を勉強しよう」などなど明確に行動を起こせる目的をもった上で学習を進めると進捗の確認がしやすかったり何がわかっていて何がわかっていないかなどが明確になります。

これを意識づけできていると自分が理解していないトピックが明確になってくるので時間があるときにどこを補えば良いのかというのがわかってきて、隙間時間での勉強やりやすくなるはずです。また各技術書なども目的を持って読む必要があり、せっかく買ったんだからと先頭から後ろまで順番に学習する必要はないです。30分などの短時間で読み終えられる技術書なんてほとんどないので、自分が本当に知りたかった情報に辿り着くまでに息切れしてしまいます。

必ず技術書やドキュメントを読み進める前には目次を見て気になるところから読むようにしましょう。また新しい内容は繰り返し触れるのが記憶にも残りやすいので、一つの本の同じ箇所を繰り返し読むようにするとさらに良いです。特に技術形のドキュメントを最初読むことに苦労する方が多いですが、別に一回で理解する必要もないので繰り返し気が向いた時に訪れて目を通すようにしましょう。

勉強時間を確保するための工夫が十分でない

日々メンタリングをしていると業務が忙しくて・・・という形で立ち止まっている方をしばしばお見かけします。

今やっている仕事が大事なのはわかりますが、自分のキャリアを考えて勉強しているのであれば、優先的に時間を確保すべきで、仕事が忙しいというのはあまり理由にならないのかと思います。なにも残業した後でもしっかり勉強しろみたいな筋肉質な話をしているのではなく、

忙しくない部署に移動できないか交渉してみる
忙しくない会社に転職する
残業はしないと割り切って勉強の時間を確保する

みたいな形でキャリアの優先度を第一に考えて勉強の時間を確保した方が良いかと思います。

どこかで壺に大きい石からものを詰めていく話を聞いたことがある方もいるかと思いますが、やはり人間1日に集中できる時間は決まっているのでそれが本業で全て一杯になってしまうのは避けるべきです。(本業は適当で良いとは言っておらず、転職のための勉強が第一なのでそれに従って周りの環境を整えようという話です。) その他にも、隙間時間で勉強するテーマをメモしておいて、移動時間にググって理解する。などなど工夫を行うことで少しづつでも勉強の時間を確保できるかと思うので優先度などを考えながらうまく時間を融通できるようにしましょう。

ポートフォリオの完成に執着する

学習の後の方でポートフォリオの完成に執着してしまって就活が疎かになってしまう方がいるので気をつけましょう。コアな機能ができていないなどであればそれは終わらせる必要がありますが、実態として使えるようになっているのであればあまり完成に執着せずに先に企業に面談にいくなど対外的なフィードバックをもらえる機会を優先しましょう。

自分として納得できるところまで作り込みたいのはわかりますが、それよりも先にREADME.mdやレジュメなどの情報を充実された方が時間効率がよかったりします。現場で得られる経験の方が独学で得られる経験よりはるかに大きいのであまり完成に執着せず目標達成のためにより良い選択肢を選び取れると良いでしょう。

慣れた方法を続ける結果効率の悪い方法で学習を続けてしまう

学習とは慣れた方法を捨ててより良い効率の良い方法を身につけるということでもあるので、より効率の良い方法を探し続けて改善を入れられるようにしましょう。マウス操作が多かったり、コマンドラインでtabでの補完、↑での履歴を使用する。エディタの分割を使う、ファイルの全検索を使ってコードリーディングの効率を高める、ショートカットを覚えるなど初心者の方ができる工夫というのは数がしれないのでこれを日々身につける癖をつけましょう。

学習した内容を書いて覚える/ノートにまとめる

受験のときの学習の癖なのか、学習内容を書いて覚えたりノートに手書きでまとめたりする方がいますが、個人的にはこちらあまりおすすめできません。そもそもネット上の情報だったり書籍というのはそういった作業をしないで良いように情報をまとめたり検索性能を高めたりしているので、学習者の方がまとめるより質が高くてよくまとまっているものがネット上にあるはずです。

何かわからなかったら自分のノートをみるなどするよりは少しでも多くググってサイトの記事を読んで効率的に情報収集できるようにすると良いでしょう。ノートに情報をまとめるよりは、その情報に素早くアクセスできるようにリンク集を作っておくと良いと思います。僕は個人のSlackスペースを作ってそこにペタペタリンクを貼るようにしています。

ノートをまとめるにしてもPCのツールを使ってまとめるようにした方がPCスキル自体の練習にもなるしGithubのリポジトリを使ってまとめたりすればGithubの使い方にも慣れるので、業界でよく使われるツールを調べて積極的に使うと良いでしょう。

情報収集の習慣をつけない

再三言及はしているのですが、プログラミングのための知識は膨大なのでなるべく技術的な情報のアンテナはしっかり立てておくようにしましょう。経験者と未経験者ではこれらの知識量に圧倒的な差があるので日常的な情報収集の癖をつけられると良いです。実際に触ったことはないけど聞いたことのある項目を増やせると業界の全体像も掴みやすくなるのでTwitter, Qiita, Zennなど技術的な情報を得られるサイトから常に情報収集を心がけられると良いです。

コードを動かさない、コマンドを叩かない

いくら概要を理解していてもコマンドを思い通りに動かせない、コードを動かせないうちにはエンジニアへの就職は難しいでしょう。

これを解消するためには、実際に

コードを動かす
思い通りに動かない
原因を特定する
修正する

というサイクルを高速で回せるように練習する必要があるので、実際にコード・コマンドを動かす癖はつけられると良いでしょう。英会話を上達させたいのに、実際に英語を話すことなく文法ばかり学習しても英会話は上達しないようにプログラミングをも同じなので、なるべく遠回りせずにダイレクトに学習を進められると良いでしょう。

「なぜか動かない」など原因特定が甘い・疎かにしてしまう

初学者のうちは経験が少なくて難しいのですが、デバッグ（原因特定・修正）の能力というのはコーディングの早さに直結してくるので、ちゃんとエラーメッセージを読んで理解したり、プリントデバッグを使って問題の起きている箇所を特定したりして独力でデバッグを行えるように意識して練習しましょう。

ここができないといつまでも経験者に聞かないと実装が進まないのでプリントデバッグやステップ実行・エラーメッセージの読み方などを学んで実行・原因特定・修正のサイクルを高速に回せるようになりましょう。

あとがき

以上、ここまでプログラミング学習の計画の立て方をつらつらと説明しました。

メンタリングを行う中で結構就職までの計画の話をしたりするのですが、日々の学習に追われて全体の計画とか目標を見失ってしまっているなー、もったいないなーというのを感じたので、今回こちら思い切って書かせていただきました。

個人的に中長期定期な計画を立てる時にはまず目標から逆算してマクロな計画を作った上で、また別口でミクロな視点から実際に必要な時間をつみあげて両者を突き合わせて調整するというのが一番精度が高いのかななんて思っています。

ここではマクロが6ヶ月の全体計画でミクロが一日の中で何をどれだけ勉強するのか？というところになります。メンティーさんの話を聞いているとこのどちらかの見積もりが甘かったりなかったりするのでこれが両方できるだけでも、うまくモチベーションを保ちながら勉強を進めていけるのかなと思っています。やはり一日単位で目標がなかったりするとどうしても日々の忙しさに追われてなぁなぁになってしまったりするので学習を始める前にしっかりと計画を立てることをおすすめしています。

また、全体の計画を聞いてみるとバッファがほとんどなかったりするものもあるので、なるべく前倒しで終えられるようにできると良いと思います。マイクロソフトの元開発者で起業家の中島智さんの「なぜあなたの仕事は終わらないのか？」という著書にロケットスタート時間術という仕事術が紹介されています。もしも、10日で仕上げるタスクであれば、2割に当たる2日間で8割終わらせるつもりで取り掛かり、この2割の段階で、全体の6割以上終わっていなければ、スケジュール変更を検討する。というようなものです。

ここまで徹底する必要があるかはわかりませんが、締め切り当日にゴールを設定すると不測の事態や新しく見つかったタスクに対応できないので十分なバッファを持たせて計画を立てる必要はあるでしょう。プログラミング学習でも仕事の繁忙と重なった、体調を崩した、予想よりも理解に時間がかかった環境構築に詰まったなどは十分にありうるのでこれを念頭に計画を立てましょう。

プログラミング学習は新たにチャレンジすることも多いので、不確実性が高く簡単ではないタスクになると思いますが、こういったところを抑えながらコツコツと積み重ねていけることができれば必ず達成できるものかとも思います。

ぜひ、これから学習を始める方々、学習中の方などに参考にしていただけると嬉しいです。ありがとうございました。