プログラム

プログラムを写経するのやめませんか? 意味ないよ

Table Of Contents

  1. なぜプログラム初心者は写経に陥りがちなのか?
  2. 写経はプログラムの勉強ではない
  3. あなたが写経をやめるべき理由
  4. プログラムで大事なこと
  5. サンプルプログラムを動かすためにそのまま書くのは問題ない
  6. プログラムの勉強法
  7. まとめ

突然ですが、

  • プログラムを写経すると安心したりしていませんか?
  • 写経してプログラミング学習したと思っていませんか?
  • プログラミング学習の次のステップに行きたくない言い訳としてプログラムの写経をしていませんか?

俺はプログラムの写経はほぼ意味がないと思っています。

この記事ではプログラムを写経をすることの無意味さ語るとともにプログラミング学習者はどのようにスキルアップしていけばいいのかを説明していきます。
ぜひみなさんにはこの記事を参考にしていただき、そしてプログラムの写経が無意味だという感覚を持っていただきたいです!

なぜプログラム初心者は写経に陥りがちなのか?

まずはこの理由から説明したいと思います。

かくいう俺もプログラムを勉強し始めたての頃に写経したことがあります。
しかも俺の場合はルーズリーフに手書きでやっちゃったりしてました(笑

そんな経験を経ている俺自身、なぜプログラミング初心者が写経しがちなのかわかっているつもりです。

それではなぜプログラム初心者は写経に陥るのか?

プログラムの写経は安心する

一番の理由は、写経することによって安心できるからだと思います。
写経は何も考えなくていいし、結果として何らかのプログラムは出来上がります。
なので写経することによって何もやっていない自分を安心させることができます。

プログラムの勉強をしているふりができる

次の理由は、プログラムの勉強をやってる感を出せるからです。

写経は手を動かして難しいプログラムの塊をそのまま写すので、めちゃくちゃやってる感が出ます。
まるでどこかの映画で出てくるスーパーハッカーに自分がなれたと錯覚してしまうほどに気持ちいいです。

そして写経が終わった後はめちゃくちゃプログラムの勉強をしたつもりになれます。

でもプログラムの写経は無意味です

断言します。
プログラムの写経は全くの無意味です。

なぜなら、何も考えずにただ書かれている通りに書き写しているだけだからです。
ただただやってる感を出したくて、プログラムの勉強、スキルアップをしたくない言い訳を写経でごまかしているだけです。

写経するくらいならプログラムから一旦離れてリフレッシュするほうがまだ有意義だと俺は思います。

写経はプログラムの勉強ではない

あなたはある学習サイトで過去にやったことのある問題の答えを見ながら写経しているとします。

過去の問題の答えを書き写すことになんの意味もないです。

写経をして勉強したつもりになっているあなたに俺は聞きたいです。
プログラムを書き写す時、あなたはそのプログラムときちんと向き合っていますか?
そのプログラムがどのような動きをして、どうしてそのようなプログラムの構成になっているのか考えたりしていますか?

ただ何も考えず書き写しているなら全くの無意味です。
プログラムをただ書き写すことはプログラムの勉強、スキルアップに全くつながらないです。

後述しますが、写経するくらいなら「なんでこんな処理をしているのか?」「どうやって実現しているのか」をプログラムを読んで理解するほうが大事です。

あなたが写経をやめるべき理由

写経は実践的ではない

そもそも、実務でプロジェクトで開発しているプログラムを写経することなんてないです。

もし当たり前じゃんと思ったあなた、それではなぜ写経するんですか?
実務で写経しないとして、どうやって新たなスキルを学ぶべきか考えていますか?
今現在プログラムの学習で写経してる人は写経する以外のスキルアップする方法について考えたことはありますか?
プロのエンジニアになってあるプロジェクトに参加したとして、何か新しいスキルを学ぶ時どうするつもりですか?

ここで答えがすぐに出せない人は写経に依存しすぎています。

本当に写経大事ですか?
その写経意味あります?

スキルが上がらない

写経は目の前にある文字列を書き写しているだけに過ぎません。
何も考えず書き写しているだけでスキルが上がることは絶対にないです。

もしスキルを上げたいなら別のことに取り組むべきです。

プログラムは暗記するものではないから

写経の一つの目的として暗記することがあると思います。

プログラムは暗記するものではないです。
「プログラムを書く」ということは、頭の中にあるやりたいこと、実現したいことをプログラムという形で表現することです。
それを行うのに関数名だとか、メソッド名だとか、クラス名だとか覚える必要なんてありません。

メソッド名とかは覚えなくていいことはわかった。
それでは処理の内容を暗記するのは悪くないんじゃないの? と思われる方いると思います。
これも写経してまで暗記する必要ないです。

重要なのはあなたが写経対象とするプログラムでどんなことができ、どんなアプローチがされているのかということです。
これさえ確認しておけば、自分がプログラムで実現したい何かが出てきた時に、そういえばあんな方法でやってたなと思い出せます。
完全に覚えていなかったとしてもあの方法使えるんじゃないかとわかったら再度調べて確認すればいいです。

ここまで読んだ方の中で、基本的な関数名とか処理方法は暗記したほうがいいんじゃないのか? そっちのほうが効率いいでしょ、と思われる方がいるかもしれません。
ですが、関数名とかメソッド名とか処理の仕方とか、特別に写経して覚える必要はないです。
普段よく使うやつは自然に覚えます。
わざわざ写経しなくていいです。

俺は未だに文字列、配列の数を返す関数を覚えられないです。
多分一生覚えることはないと思います。

俺は仕事で色々なプログラム言語を触ります。
フロントエンド、バックエンドの両方に触れる機会も少なくないので、一つのプロジェクトで二つの言語を扱うことになることも結構あります。
例えば、フロンエンドがJavaScript or TypeScript、バックエンドがJava or PHP or C#などです。

このように、色々な言語を使っている内に各言語の文字列、配列の数を数える方法なんて忘れてしまいます。
配列の数を数える関数を覚えれば多少効率は上がるでしょう。
ですがそれを覚えるくらいなら、「あるアプリケーションの新機能を追加するためのアルゴリズム」を考えるための脳のリソースを確保しておくほうが有意義です。

「配列の数を数える」というような汎用的なこととはまた別の話ですが、もう少し頻度の少ない関数名などを覚えて何度も使うようことをしている時点で効率が悪いと思っています。
プログラムは共通化、アルゴリズム化して同じ処理をなるべく書かないようにするべきです。
それなのに暗記してよく使うということはそもそもプログラムの書き方とマッチしていないと個人的に考えています。

関数名とか特定の処理の仕方を覚えることには否定的ですが、プログラムで何ができるかは覚えるようにしています。

簡単な例だと、

  • forを使えば繰り返し処理ができるとか
  • こういう場面では三項演算子を使うことが有効だなとか
  • 先に無効な処理確認を行い、無効な場合はすぐにreturnして、それ以降に本来の処理を書くとか こんなことを覚えています。

プログラムではどのようなことができて、どのような考え方をすれば効率良く不具合の少ないプログラムを書くことができるか、ということは暗記というか考え方を覚えるようにしています。

もし新しい言語を学習する時、今自分が扱えるプログラム言語でできることがわかっていれば、新しい言語ではそれができるのかという学習アプローチができます。
その結果、今まで知らない手法でその言語で行えることがわかったりなど新たな発見があったります。

ただ写経をして指を動かしているだけではこの域には達することはないです。

時間の無駄

プログラムの写経には一種の気持ちよさがあります。

目の前にある写経対象であるプログラムを写すことによって目の前にかっこいいプログラムができあがるからです。
ですが、何も考えずに写したその結果は、キーボードのタイピングが上手くなっただけでプログラムの学習につながらないです。
つまりプログラミング学習の上で、写経は時間の無駄です。

特に、プログラムを書き写している時に自分が知らない単語、技術、スキルが出てきてもとりあえず写している人は本当に時間の無駄です。
なぜなら新たな情報について調べていないからです。

調べなくても書けるくらいのプログラムを書き写すのは、既に扱える技術で書かれているプログラムを書き写しているだけなので、新たなスキルに対しての習得に全く繋がっていません。
写経対象に新たな技術がなければなおさら写経は無駄です。

ただの思考停止だから

プログラム学習サイトで出題された答えを写経することはただの思考停止です。

写すくらいなら、そのプログラムを読む方がいいです。
むしろ読み込んでください。

もし写経したとして、次同じような課題が出てきてもほぼほぼ同じような書き方はできないです。
プログラムは、元のプログラムを見なければ、全く同じものを書くことはすごく難しいです。

プログラムで大事なこと

ここからは、プログラムを写経することの無意味さを語るのをやめ、プログラムで大事なことについて説明していこうと思います。

プログラムで大事なことは以下になります。

  • 考えること
  • 書くこと
  • 読むこと

それでは説明していきます。

プログラムは読むことが大事

写経は無駄と言いましたが、どんなプログラムも読むことは大事です。

写経対象のプログラムも読むなら無意味ではないです。

例えば、写経対象のプログラムを読むことによって、自分が知っている関数の新たな使い方を発見することに繋がったります。
自分が書いたプログラムと同じような使い方をしていれば、自分の使い方が間違っていないことを確認することができます。

自分が知らない技術が使われているプログラムを読むことは特に重要です。
知らない技術が書かれているプログラムを読むということは、そのプログラムを理解するということになります。
理解するには知らない技術について調べる必要が出てきます。
調べた結果、新たな技術を習得することになります。

この流れは実務では当たり前のように発生します。
実務で使われるプログラムは、たとえ知っている技術を使って書かれていたとしても、自分以外の誰かが書いたものであり、読んで理解する必要があります。
知らない技術、ちょっとした知らない書き方と対面した時、よく読み、調べ、理解していくということになります。

写経、暗記などをしているだけでは到底たどり着くことのできない領域です。

プログラムを読む、ということを普段から心掛けるようにするとスキルアップに繋がります。

俺は自分が使うフレームワーク、ライブラリ、気になる技術がオープンソースで公開されていたらソースコードを読みに行くことが多々あります。
読んで理解できれば、フレームワークなどの仕組みなど自分が一人でやっていては得られない知識を得られます。
プログラムを読むことはめちゃくちゃ大事です。

プログラムは書くことが大事

プログラムは書くことが大事です。

書くことと、写経は似ているように思ってしまいがちです。
ですが、プログラムを書くというのは、かならず何かしら考えて書くことになります。
何も考えずにただ写すだけである写経とは全く異なるので注意してください。

プログラムを書くということは最終的にプログラムを動かすということに繋がります。
もしかしてそのプログラムを動作させるには環境構築も行わなければならないかもしれません。
環境構築をやる機会というのは限られているので、どんな環境を構築してもスキルは上がります。
そしてその経験は、いつか業務で役に立つはずです。

プログラムを書いて動かすと、必ずといっていいほどエラーが発生します。
エラーが発生するとエラーを解決しなければならないです。
エラーを解決すると、なぜそのエラーが発生してしまったのか、そしてそのエラーについて理解が深まります。

プログラムを書く上で、自分が考えたロジックを書くことが大事です。
自分の頭の中にある考えを言語化することになります。
これはプログラムの本質でもあります。
自分がやりたいこと、実現したいこと、誰かがやってほしいこと、なんでもいいです。
考えて書いてみてください。
写経なんかとは比べ物にならないくらいレベルが上がります。

プログラムは考えることが大事

プログラムは考えることが大事です。
写経するくらいなら、アルゴリズムの一つでも考えるべきです。

プログラムは自分が実現したい課題を解決するものです。
プログラムを書くにはまずは考えをまとめなくてはならないです。

考えるということは、例えプロジェクトで仕様が決められていても発生します。

いつでもプログラムのことについて考えることは有意義です。

自分が考えたロジック、やりたいこと、課題のプログラムで解決するアプローチを考えるのが大事です。
例えば、HTML/CSSを使って自分が考えたレイアウト、思いついたレイアウトを実現するにはどうすればいいのかを考えるのも大事です。

考えたことを実現する上でほぼほぼ新たな技術に出会うことになります。
考えるということは新たな技術に出会うことに直結します。

サンプルプログラムを動かすためにそのまま書くのは問題ない

これまでプログラムの写経を否定してきましたが、サンプルプログラムをそのまま書き起こすことは問題ないです。
ですが、何度も言いますが何も考えることなくプログラムを写してしまう写経になってしまうと意味がないので注意してください。

サンプルプログラムは書き写している時に「あれこの処理見るの初めてだ」、「これどうやって動いているのかな?」など色々と発見があると思います。
このように考えながらサンプルプログラムを作ることが大事です。

書き写したサンプルプログラムはほぼ確実にコンパイルエラーが発生します。
実行時エラーも発生する可能性があります。
これは非常に実践的です。
実際のプロジェクトの現場でも日々同じようなことが起こります。

これらを乗り越えて書いたサンプルプログラムには価値があります。

そしてやって欲しいのが、サンプルプログラムの内容をほぼ全て理解することです。
ここはわからないけど課題の趣旨と違うから今はいいや、と放置しないでください。

放置した箇所はいつか対面することになります。
今の内にわからないなりに理解するのがいいです。
わからないなりに理解したものは次に同じような処理に出会った時、びっくりするくらいすっと自分の中に入ってくることが結構あります。
そうでもなくても「あ、この処理この前調べたところだ! 意外と複雑なことやってなかったんだ」となることがほとんどです。

注意してほしいことがあります。
それは、完璧に内容を把握したサンプルプログラムを何度も書かないことです。
完璧に内容を把握できたサンプルプログラムを書くことは思考停止で写経していることになります。
得られるものはないです。
同じサンプルプログラムを写経するくらいなら「次のサンプルプログラムに着手する」、「誰かが書いたコードを読む」、「どんなコードを書きたいかを考える」などを行ったほうがいいです。

プログラムの勉強法

以下にいくつかの例を紹介します。
写経したいとなった時に以下の方法を使っていただければなと思います。

参考書を読むこと

あなたがプログラムを全く書いたことがない、ほとんど書いたことがない初心者なら参考書を読むことをおすすめします。

そして参考書に書いてあるプログラムを実際に動かしてください。
先ほど説明した通り、サンプルプログラムを考えながら書くことは写経ではなく、意味のあるものです。
ぜひ実践してください。

ですが、完全に理解したサンプルプログラムを何度も書くことによって、写経することはやめてください。

ここまで完全に理解したプログラムを写経することを否定してきました。
ですが、そのサンプルプログラムを読み込むのはいいことです。
程度はありますが、プログラムを読むということは頭の中で処理の内容を理解し、プログラムを動作させずに処理内容を把握することに繋がります。
これも実践的であり、実際の現場でも頻繁に発生します。
むしろプログラマの仕事はプログラムを読むことと言っていいほどプログラマはプログラムを読んでいる時間が多いです。

参考書を読むうえで重要なことがあります。
参考書ではその言語で使用できる機能の使い方が出てきます。
機能の説明が出てくるたびにこの機能を使うと他にどんなことができるかを考えることです。
これができると自立してプログラムを0から書けるようになります。

参考書の選び方

参考書の選び方は以下の通りです。

自分がプログラムを使って何をしたいかを考えます。
ホームページを作りたいならHTML/CSS/JavaScriptの使い方についての参考書を買います。
今だとHTML/CSSをそのまま使うことはないのでReact、Next.jsのようなWebフレームワークについての参考書も読んだ方がいいです。

iOSアプリで、例えばToDoアプリを作りたいならXcode + Swiftの使い方についての参考書を買います。
AndroidアプリならAndroid Studio + Kotlinの使い方についての参考書を買います。

AI系、WebスクレイピングをしたいならPythonについての参考書を買います。

このように、あなたがやりたいことによって買うべき参考書は変わります。

漠然とプログラムを学びたいという動機でプログラムの学習を始めるのはあまりよくないです。
何から学習するべきなのかがわからなくなってしまうからです。
その結果、プログラムを学ぶことが目的になってしまい、そこから学習意欲の低下に繋がります。
そして写経地獄にに陥ってしまうでしょう。

学習サイトを使うこと

学習サイトは無料でできるものが多いのでいいとは思います。
ですが、自分は利用したことはないです。

学習サイトはある程度網羅的にできてるのかもしれません。
ですが、情報を低コストでたくさん詰め込めることが可能な参考書の方に比べて網羅性は低いと思います。
なので参考書で学んだ方が深く理解できると思っています。

やりたいことを実現してみる

あなたがプログラムの基本的な学習を覚えた初心者の方だとします。
次のステップとして「あなたがやりたいこと」を実現することです。

例えばプログラムを学んだ動機がToDoを管理できるWebアプリケーションを作りたいということなら実際に作ってしまうのがいいです。
いきなり作るのは難しいと思うので、小さな機能から実装していくのがおすすめです。

例えばToDoが登録されてることを前提として、JavaScriptでいうオブジェクトにToDoの情報(タイトル、やること、終わったかどうかのフラグなど)を入れておき、それらをHTMLでリスト表示したりすることです。
それが出来たら次はユーザーがテキストフィールドに入力して追加ボタンを押した後にオブジェクトに登録する処理を実装してみるとかです。

やりたいことがない人

やりたいことがないというのはあまりよくない傾向ではあります。

それでもステップアップしたいと考えているなら、簡単なプログラムの問題を解くというのも一つのステップアップ方法になります。
有名なものだと「FizzBuzz」、「ハノイの塔」などです。

ここで重要なのは実際のプログラムでの実装方法を見ずに、説明文(仕様ともいう)を読んで自分で考えて作成することです。
自分で考えてプログラムを書くことにより、ある課題に対するプログラムでの解決法を自分で導き出すスキルが身につきます。

ですが、恐らく最初は上手くできないと思います。
なので最終的には答えを見ることになります。
それでも問題ありません。

答えを見る時気を付けて欲しいことがあります。
それは書き写すことです。
もちろん写経もだめです。

答えを見て、どのような処理を行って実現されているのかを理解することが大事です。
理解した後、その問題の答えを見ずに頭で考えてプログラムを書くことが大事です。
こうすることにより、問題の答えとは異なるアプローチで解決できたり、ほとんど同じような処理だとしても変数名が異なったりなど個性が出ることになります。

これがプログラムを自分で考えて「書く」ことに繋がります。
やっている内に問題を解くだけでは満足できなくなってきます。
そしてだんだんと自分が何をやりたいのかが見えてくると思うのでやりたいことを実現するステップに移ってください。

流行りの技術、現場で使う技術について調べる

流行りの技術、現場で使う技術について調べることはおすすめです。

ですが、流行りを追いかけすぎるのはよくないです。
流行りを追いかけすぎるということは、実際に手を動かさずに情報収集のみを行いがちです。
そしてそんな人は、実際に手を動かしてその技術に触れていないにも関わらず、その技術のエキスパートかのように語ったりします。

英語圏の技術者の間ではそのような人をアストロノーカー(宇宙飛行士)と揶揄したりします。
宇宙飛行士のようにふわふわとし、地に足がついていないという意味が込められています。

SNSで情報収集する

SNSで情報収集するのもおすすめです。

TwitterなどのSNSは結構馬鹿にできないです。
ただタイムラインを眺めているだけでも、はっとさせられるような重要な発言をしている方がいます。
そういう情報は取りこぼさずかみ砕き、自分の血肉にするべきです。

エンジニアの知り合いと意見交換する

エンジニアと意見交換することは大変有意義なことです。
少し話しただけで自分の知らない領域の言葉が出てきます。
そこから興味を持ったものを深堀することによって色々と技術の枝葉が伸びていきます。

中にはエンジニアの知り合いが見つけづらいという方もいるかもしれません。
そんな方は、プログラムの初心者、プログラムのことを少しだけかじったデザイナーなどとも意見交換することをおすすめします。

他人は自分とは異なった視点でプログラムについて学習しています。
当然の話ではありますが重要なことです。
異なった視点でプログラムについて学習しているということは、自分の知らない知識、単語を知ってる可能性が高いです。
そこから深堀していくとお互いに有意義な情報交換に繋がります。

まとめ

この記事では、写経はプログラムを勉強してるふりをするための言い訳であることを伝えました。
この記事を読んだ方には正しいステップアップをしてもらい、技術力を高めてほしいと思います。