Contents
プログラミングのキンドル独学の学習内容
プログラミングを生業とするには道のりが険しすぎる
まず始めに言ってしまいますが、プログラミングスクールでちょっと勉強したくらいでは、ソフトウェア開発者として仕事をするのはかなり厳しいです。
本記事はかなりの長文です。しかし、「都合の悪いほんとうのこと」を一生懸命書きました。プログラミングを学ぶことによって後悔をしないために、ぜひ目を通していただければと思います。
プログラミングスクールで教えているのは、ソフトウェア開発全体のごく一部に過ぎません。後述しますが、プログラミングそのものだけ熟達しても、需要ある人材にはなれません。需要ある人材になろうとすると、「おぼえないといけないこと」がとにかく多いです。
プログラミングは、本研究所で扱うスキルのなかで、一番、それも圧倒的に「おぼえないといけないこと」が多いです。しかも「おぼえていたら嬉しい」ではなく、「おぼえないと話にならない」というハードルの高さです。
プログラミングスクールやユーチューバーが話さない実状です。「プログラミング・ソフトウェア開発はこんなにも大変ですよ」と言ってしまったら、やりたがる人がいません。
でも考えてみてください。「パソコンをちょっとカタカタやる」だけのカンタンな仕事だったら、「世の中でIT人材が不足する」なんて言われるはずないです。
そもそも「求められているIT人材」というものと、プログラミングスクールの講習内容とに天地の開きがあります。
本記事では「求められているIT人材」を目指したリスキリングについてのべます。しかし、その道のりはあまりに険しい。はっきりいって、残り9つのスキルの学習に切り替えたほうがいいのでは？ と思います。
それでも「自分はプログラミングをまなんで、ちゃんとしたソフトウェアエンジニア・IT人材になるんだ！」とか「ITサービスを自力で開発してザッカーバーグになるんだ！」という気概のある方は、以下を読み進めてみてください。
「同じことを繰り返しやらないようにする」自動化が目的
コンピューターにあれやれこれやれと命令を書いていくことがプログラミング と言われますが その目的は同じことを繰り返しやらないようにするというものです
つまりプログラミングの目的は自動化です自動化にこそ価値があります
そもそもコンピューターでないとできない計算っていうのはほとんどありません。いくらでも時間かけていいならば原理的には人間がそろばんや計算尺で計算しても同じことができますコンピューターは人間のやっている操作をただ繰り返し模倣しているに過ぎません
プログラミングというのは その模倣作業をどのような順序で行えばよいかをわざわざ書いているだけです
新型コロナウイルスの飛沫がどのように飛ぶかというのをスーパーコンピュータで分析したニュースがありました大規模な計算をコンピュータープログラムによって実施するという事に非常に高い価値がある という良い例ですね
しかし一般的なソフトウェアでは 複雑な計算や方程式を解くというよりも 数字や文字を帳簿から地方へ書き写す帳簿上から削除する 帳簿上の記録を更新するといった操作の方が圧倒的に多いです
こうした帳簿の凄さについても 原理的には人手でできるものばかりです コンピューターはヒトデの操作を帳簿についても模倣しているわけです
コンピューターによって帳簿の操作をすることの意義 というのは 人手を介さなくてよいという一点に尽きます 調合をめくったり書き込んだり消したりするための帳簿係を 雇わなくても 機械を設置しておけば言われた通りの仕事ができるわけです
機械は間違えないし正確だし 文句をいうこともありません 自動化といえばロボット という印象がありますが 肉体を持たないコンピューターであっても言われた操作が電子的にできるという点では ロボットと同様の自動化を担っています
ビジネスの現場では rpa と呼ばれて ソフトやつ買った ホワイトワーカーの仕事の自動化が近年めざましく進んでいます
一方でソフトウェアに関わる技術者の人数は 十分ではありません様々な現場でのソフトウェアによる自動顔 実現していくためには もっとたくさんのソフトウェア技術者が必要になるとされています
残念ながらソフトを作る作業自体は漫画やイラストを書くのと同様に 手作業で一文字ずつプログラムコードを書いていかなければなりません
自動化の背後には ソフトウェア技術者の並々ならぬ苦労が あるということです そんな苦労をしてでも自動化をすることに大きな価値があるため、プログラミングを学ぶことの意義が ますます大きくなっています。
時間効率向上・労務費削減
ここに プログラムによって自動化をすることによって得られる ご利益とは何でしょう
それは仕事における 時間効率の向上 そして労務費の削減です あらゆる発明は 基本的に時間を節約するためのものです
例えば自動車も飛行機も 人が移動する ための時間を減らすための発明です 冷蔵庫も 食品を冷やすための 冷却剤や保冷剤を持ってこなくても電気だけで食品や冷やせるように したので 冷却材の運搬時間の 削減になっているわけです
コンピュータプログラムは 人手で帳簿作業や 計算を 行わないことによって 人が 関わる 時間を 削減しています したがって労務費を削減し 経営効率を上げることができます
人の側も 単純作業から 解放されるというメリットがあります AI やコンピューターが 人類から仕事を取り上げてしまう という懸念が以前からあります。しかし、帳簿や計算のような繰り返しの作業については明らかに コンピューターで 実行した方が 効率的だし効果的です
一方で AI やコンピューターが苦手とする 仕事もあります
例えばコンピューターが何をすれば良いか 決めていくこと自体 実はできません 人間味のあるような感情表現 その感情表現に基づく創作活動 あるいは 共感を得ながらの 対人交渉 不透明不確実な状況下での意思決定 などは人間の方が 得意であり続ける 仕事です
労務費削減をしたいのは単純作業であって クリエイティブな 仕事について人を割り当てて注力していきたい というのがこれからの経済活動の在り方です
プログラミングの もちろんこのクリエイティブな仕事 に含まれます ソフトウェアエンジニアも デザイナー家 イラストレーター童謡 クリエイターであると言えます
あいまいなビジネス環境の中での対人交渉も エンジニアに求められるので これからもそふかやプログラミングはなくならない仕事 と 断言できます
入力は何？出力は何？
自動化の意味と、プログラミングという仕事の価値について確認しました。狭義のソフトウェア開発 そしてプログラミングについて述べていきます 。
プログラミングといえば、いわゆるプログラミング言語を使って「文字を一文字ずつ打ってプログラムコードを書いていく作業 」を指します。コーディングともよびます。
しかし、単にコードを書く作業は 「ソフトウェアを作る」ということと大きく違います。
たとえば、「ある入力がこういうデータ、 対応する出力はこういうデータ 」とあらかじめ決めてあったとしましょう。決まった入力から期待する出力を吐き出すような 一連の手続きをコード化するのが、プログラミング作業です。
ところが、いまの例をよく考えてください。入力が何か、出力が何かという「そもそもの設定」は、 誰がどう決めるのでしょうか？ ペーパーテストのように天下りで 定義されているはずがありません。
さらに、この入出力の組が 何段も何段も 重なって、初めて全体のソフトウェアになるはずです。
何段にも重なった構造をどうやって組み立てるのでしょうか？ ビジネスの論理を表現するのに全体が何段の論理であるべきか。ビジネスの情報を管理表現する適した様式の帳簿はどうあるべきか。どうすれば適切に決められるのでしょうか ？
「（プログラミングではなく）ソフトウェア開発」では、入力・出力・帳簿様式・論理の段数など、ビジネスの論理を手作業で明確にしていきます。つまり、人手作業の場合の手続きを、すべて形式化（マニュアル化）しなければなりません形式化の中で、「論理そのものを作る作業 」と「プログラムコードそのもの書く作業」とがあります。
ソフトウェア開発の現場では、「論理そのものを作る作業」を設計と呼びます。そして「プログラムコードそのものを作る作業」をプログラミングと呼んでいます
「プログラミング」だけができるようになっても、ソフトウェア開発ができるとはいえません。プログラミングと共に 設計ができるようになる必要があります。
ソフトウェアの設計技法についての知識やノウハウを心得ておかなければ、スキルとしては不満足なのです。
「通しで動く」ことの大切さ
設計ができるようになるためには、プログラミングのほかにどんなことを考えるのでしょうか？
一言で言って 通しで動く というところに 全体を持って行く気持ちとノウハウが必要です。 全体を通して動くソフトにする というのは 、要素を プログラムとして書いているだけでは 達成できません
コードの実物がなくても 全体の論理を通して 不都合がなければ 通しとしてはオーケーです。
日本では プログラムコードそのもの書く人をコーダーと呼び、設計を担う人を システムエンジニアと呼ぶことがあります。求められているのはシステムエンジニアです。ただのコーダーは あまり人材としての価値がない とみなされます。
一方で アメリカの西海岸では コードと設計の両親をプログラマーが担当します。 西海岸では プログラマーはプログラムを作っていると意識ではなく、事業を作っているという意識なのです。
プログラミングにリスキリングに取り組む場合のマインドはどうあるべきでしょうか。やはり、 何らかの事業に直接貢献するのを目指す、ビジネスを担う人材を目指すべきです。ビジネスを担う手段として プログラミングを学ぶことが求められます。
保守が大切。開発資料が大切。
プログラミングスクールで プログラミングの技法を習って 卒業制作を経てて晴、れてエンジニアデビュー・・・と思ったら 、現実は違います。
ソフトウェアとして一通り完成させて、納品できるようなものを作り上げるのは、とても重要な経験でく。しかし、実は納品はゴールではなくスタートなのです。
開発ソフトウェアを納品した顧客先では、 そのソフトウェアが ビジネスの現場でずっと動いていきます。10年、20年という単位で動いていくこともありえます。
「10年20年もそのままで通用するのか」と思うかもしれません。現場では多少の使いにくさは運用でカバーしていきます。 ソフトの現状に合うように、うまく職場のルールのほうをを決めたり変えたりしながら、ソフトを使い続けていくのです。
しかし、ソフトに深刻な不具合やバグがあった場合はどうでしょうか？ やはり開発元にお願いして、不具合を調査・修正してもらう必要があります。
このような修正が発生するのは納品してから何年か経った後の可能性もあります。不具合修正が求められた時、おそらく当時の開発チームは解散してしまって、開発者たちは別のプロジェクトに従事しています。
そこで、保守作業時のために開発ドキュメントをしっかり残し、品質保証をすることが重要です。実際に、ソフトウェア開発現場では開発資料を作ることがかなり重視されます。
一般に、ソフトに深刻な不具合が生じた場合には、顧客はかなり困った状況にあるはずです。業務が止まってしまうこともありえます。一刻も早く不具合修正が必要です。
設計当初からかなり時間が経過してしまうと、当時自分で書いたコードですら意図がわかりません。「何年か前の自分は他人」ということです。まともにコードを分析していては、解決までに相当な時間を要します。
不具合調査時に、まとまった資料があれば 調査時間をかなり短縮できます。そして早期に不具合を修正できます。
不具合修正の場合に、元々の保守契約期限というものもあります。この期限が切れていれば、保守改良には特別料金を請求することができます。
顧客にとっても早く解決したいので、とにかく困ってるから、 価格交渉よりも、お金を早く払って解決してしまおう」と考える場合も多いです。相見積もりもできないので、いわゆる言い値が通るのです。
納品後の保守というのは、非常においしいビジネスであるのです。保守時の利益率を高くできるかは、不具合修正までにかかる労務費しだいです。
利益率を高くしてビジネスに貢献するためにも、将来の保守を見越して開発ドキュメント資料を充実させておく必要があります。
ところが、プログラミングスクールでは、開発資料については教えていません。つまり開発資料に「どのような項目を、どのくらい詳しく書けばよいか」を教えてくれません。ソフトウェア開発チームの現場に入って、初めて開発資料の作り方を知ることになると思います。
そのため、ソフトウェア保守の現実を知らずに、フリーランスのソフトウェア開発の仕事を（スクールで習ったことだけで）請け負うのは危険です｡
なにしろ、長期的な保守をするノウハウをもっていないのです。保守ができないことで信頼を失ってしまうと、「あの人は保守まで見てくれない」という評判で、結果的に仕事を続けられなくなるかもしれません。
ソフトウェア自体だけでなく、自分自身が長くキャリアを続けて活躍していくためにも、開発資料づくりはとても大切です。
よい開発資料とは何なのか、よい開発資料を書くにはどうすればよいのか。プログラミングとセットで、開発資料の書き方も学んでおく必要があります。
プログラミング言語の選び方
まずはなんでもいいのでプログラミング言語をひとつ選んで文法・作法をおぼえましょう。実はソフト開発では複数のプログラミング言語を扱えるようになる必要があります。
まったくのプログラミング未経験者の場合は、とにかくひとつのプログラミング言語に慣れるべきです。いろんな他のプログラミング言語もわかるようになります。
こだわりがなければ、以下の三択から選びましょう。
- Javascript
- Ruby
- Python
Javascriptだけわかるだけで、ウェブ開発ができるようになります。派生技術に流行廃りがありますが、基本部分はさほど代わりません。AI系の機能もpythonから移植されて使えるようになっているので、JavascriptだけでAIアプリを作ることもできます。「あまりたくさんのことをおぼえないで始めていきたい」という場合は、とにかくJavascriptだけ仕上げましょう。
Rubyは国産のプログラミング言語なので参考書、教本、解説動画もたくさんあります。もちろん仕事もたくさんあります。最小限の手間でウェブ開発ができてしまうRuby on Railsという仕組みがあります。「はやく動くものを仕上げるところまでいきたい！」という気持ちが強いなら特にオススメです。Rubyは老舗中小企業から大企業まで幅広く使われているので、無難に仕事を得たいならRubyがオススメです。
PythonはAI関係の進展が強力です。意外に歴史のあるプログラミング言語なので、教科書、教本、解説動画もたくさんあります。仕事はJavascriptやRubyよりは少ないです。Rubyでの開発はどちらかといえば技術面で伝統的・保守的なソフトが対象なのに対して、Pythonを使った開発は技術面で野心的・先進的なものが多いです。スタートアップやベンチャーで活躍を狙うならPythonがオススメです。
そのほかにC言語、Javaなどが有名ですが、プログラミング初心者だと挫折しやすいと思います。最初は回避しておくのが安全です。
とにかく「ひとつのプログラミング言語を継続性に学ぶ意欲を保つ」というのが大事です。なるべくカンタンで扱いやすいプログラミング言語で、まずはプログラミングそのものに親しんではいきましょう。
そして練習のプログラムを書いていきます。どんな上級者でも、新しいプログラミング言語の学習を始めるときに通る道です。
基礎の反復練習の徹底
プログラミングスクールやユーチューバーがあまり言わないことを言います。
プログラミングは頭の良さや要領の良さとは無関係です。公文式、スポーツの素振り、楽器の吹き方のごとく、ただただ反復練習が大事なだけです。基礎の反復練習。これに勝るものはまずありません。
初心者は、ややこしい計算法とかデータの保有構造を学ぶのは、とにかく後回しです。凝った処理手続き（アルゴリズムという）を学ぶと、挫折するだけです。
とにかく初めは、ifとかforといった、基礎の制御構文を徹底して反復練習していくべきです。アタマで考えなくてもできるようにしていくことが反復練習です。
たとえばforという繰り返し同じことを実行する構文があります。このときに「うーん、繰り返しだから、ここは、、、forだっけ？ あれ、forの後ろって何て書くんだっけ、本のどこにあったっけ？ ノートにメモったかな？」とかやっていては、まったくダメです。
かけ算九九がありますね。「6 x 4は？」といわれたら、普通は「24」と即答しますよね。わざわざ「えーと、6が4個あるから、6+6+6+6か。えーと、12, 18, 24と。答えは24か」などと考えませんね。考えずに答えが即答できる状態にしないと、かけ算九九は意味をなさないからです。だから子どもの頃、あんなに皆が反復練習をぶつぶつ言いながら取り組んでいたのです。
プログラミングも同じことです。なんなら楽器やスポーツと同じ。基礎動作をいちいちアタマで考えないでできるようにしないといけません。自転車のペダルの踏み方や、バスケットのドリブルや、ギターの音の出し方など。ひとつひとつの動作をいちいち考えていては競技や演奏になりません。
まず始めは、簡単かつ似たような練習問題で、基礎を徹底的に反復練習する。
かんがえてみてもください。そもそも学校の勉強も大半は基礎の反復練習を求めていただけです。数学の因数分解だとか、英語の作文だとかは、膨大な反復練習をこなして初めてできるようになるのです。頭がいいかどうか問われるものは少ないのです。暗記などはあからさまに反復練習。目で見たり声に出した回数が大事だっただけです。
キンドル本では、めちゃめちゃやさしい基礎問題だけ集めたような、初心者用練習問題の本があります。ていねいな解説は不要と割り切り、ひたすら似たような初歩問題が100個200個と続くようなキンドル本です。バカにできません。これこそ反復練習にうってつけの教材です。
市販書籍は基礎の反復練習を半ばとばして、すぐにややこしいアルゴリズムやソフト開発に入ってしまいます。それではだめなのです。
反復練習をサポートする教材は、キンドル本にたくさんあります。キンドル本で大量に反復練習をしていきましょう。「１日一冊まるまる終える」を一週間つづけるだけで、かけ算九九のごとく、プログラミング言語を道具として使える手応えが出てきます。
毎日、朝と夜に、大量の練習問題を高速に「流して」いきましょう。英単語の暗記と同じ要領です。ノートにまとめたりはしない。テキストへの書き込みも不要。ただ、何度もなんども目を通していけばそれでオーケーです。途中で立ち止まったり、苦行はやめましょう。とにかく練習問題を進めて、大量に浴びていきましょう。
テキストでの反復練習で自信がついたら、paizaなどの学習サービスでパソコンに向かって練習問題を解きましょう。難しいやつは不要です。基礎構文を何度も打ち込んでいきます。やればやるほど早くなります。
そして「あ～なんか集中してなくても、ほぼほぼ考えずにノータイムで答えられるようになっちゃったわ～」というレベルになればオーケー。初心者脱出は目前です。
ウェブ開発をおぼえる
キンドル本などで基礎の反復練習ができたら、実際の開発技法を学んでいきます。
ソフトの構成方法はおおむね三種類です。今仕事がたくさんあってオススメなのはウェブアプリ開発です。ウェブアプリはパソコンとスマホの両方で動かすことができるし、ソフト開発の基礎形態が明快です。
- ネイティブアプリ開発（スマホのアプリストアで入手するソフトの開発）
- ウェブアプリ開発（ブラウザ上で操作するソフトの開発）
- パソコンソフト開発（PCで操作するソフトの開発）
ウェブアプリは３つの要素で構成されます。
- フロントエンド 見た目
- バックエンド 背後の情報処理
- データベース 情報の蓄積
フロントエンドは基本的にJavascriptでつくります（PythonやRubyでつくる方法もあります）。見た目（インターフェース）を司ります。ボタンを押したときとか、チェックをつけたら項目が消えるとかですね。フロントエンドは、ブラウザを表示している端末（スマホとか）で動いてくれるソフトです。
バックエンドはJavascript, Ruby, Pythonのいずれかでつくります。おぼえることを増やしたくない場合はバックエンドもJavascriptを採用するのでいいと思います。バックエンドは、ブラウザの表示とは独立して、遠隔のコンピューター（サーバー）で動いてくれるソフトです。
データベースはちょっと厄介です。データベースのソフトもサーバーに搭載されています。
実はバックエンドもフロントエンドも、入力・出力の情報やデータを覚えていられません。暗記はまったくせず、つねに右から左へ流してしまうのです。フロントエンドもバックエンドも「処理はするが覚えない」のです。
しかし、一回こっきりの処理だけならいざ知らず、過去の経緯や履歴をまったくおぼえていないのは困ります。人間同士なら、「つねに初対面」のようなものです。会話がまったく成立しません。
フロントエンドやバックエンドが覚えないかわりに、必要な情報を書き込んでおいて逐一参照できる「共有の帳簿」があればよさそうですね。
この「共有の帳簿」がデータベースです。データベースの操作には、記録の挿入・参照・更新・削除という四通りしかありません。この四通りの基本操作に、いろいろな付帯条件を組み合わせることで複雑な帳簿操作を実施します。データベースという帳簿をどのように操作するかは、プログラミング言語で書きます。
データベースの操作には、データベース特有のプログラミング言語をふつうは使います(JavascriptやPythonでデータベースを操作する方法もあります)。
一般には、SQL(Structured Queey Language)を利用して帳簿をつくります。SQLによって「かっちりとした」帳簿を作ることがビジネスでは求められます。なぜなら、帳簿の様式の充実度や冗長性が、ソフトの保守のしやすさに直結するからです。
したがって、ウェブアプリ開発のためには、最低限二つのプログラミング言語を学ぶことになります。
- Javascript
- SQL
見た目そのものを作るには、いわゆるホームページ作成のための装飾言語が必要です。
- HTML
- CSS
HTMLは大したことがありません。普通にかいた文書（wordとかメモ帳で打った文書）に、「タグ」とよばれる装飾をつけていくと出来あがります。
CSSはちょっと難しくて、Bootstrapとよばれるデザインパッケージの使い方を知る必要があります。ただ、これは暗記とか反復練習よりも、都度ウェブ検索して引っ張ってくればいいものです。
ということで、HTMLとCSSはちょっと教本や解説動画をみれば簡単に始められます。というか、Javascriptを学ぶ中で必然的に出現してくるので、自然に通る道だといえます。
いずれにしても、バックエンドやフロントエンドをより高機能にしていきたい場合は、さらに別の要素技術を都度学んで投入していかなければなりません。新しいことをたくさん投入していかないと、「通し」で動くようになりません。
さて、もちろんSQLも徹底的に反復練習が必要です。帳簿の更新のときはupdate文を使いますが、「えーど、レコードを更新？するのか、、、こういうときはupdateだったづけ？ updateの後ろにくるのって、まず何だったかな、、」という調子では、やはりダメです。
キンドル本にSQLの基礎練習問題集もあります。Javascriptなどと同様に、徹底的に反復練習をしましょう。アタマで考えないでできるようにしておかないと、データベースを道具として使えません。
チーム開発のために
会社ではチームで開発するので、バック、フロント、データベースをそれぞれ分担していきます。
しかし、リスキリングとしてプログラミングを学ぶ場合には、フロント、バック、データベースの全部を一通り網羅する経験をもちたいです。「どこがどのくらい得意か、大変か」ということを心得ていないと、そもそもチーム作業もできないからです。
チームで開発に取り組む場合は、全部を我流ですすめるわけにはいきません。チームでの取り決めのもとで開発を進めないといけません。
たとえば、ファイルの名前や、変数や関数の名前の付け方なども「大文字をつかうのか、アンダースコア_を使うのか」すらも決めておかないといけません。
なぜなら、チーム作業では、互いの書いた設計やコードのすべてを互いで把握できません。「お互いが書いたところがどう影響しあうのか」を綿密に詰めながら、なるべく独立に取り組める工夫をします。そのためには「各人の謎の独自性」みたいのが排除されている必要があります。
「各人の謎の独自性」を排除するために、キチンと記録を残し、相互見直し（レビュー）を実施します。「プログラムの動作としては合っているけど、書き方はダメ」というケースを見つけ、早めに修正していくわけです。
チーム作業の経験はなかなかひとりでは詰めませんが、意識して練習しておくことはできます。
以下の事柄は、チーム作業を想定して押さえておくべきです。
- Gitの使い方
- GitHubの使い方
- GitHubでどのような記録をどのように書いておくべきか
- コードテストのかきかた
- テストの自動化の仕方
- GitHubでのCI化
- READMEの書き方
- ソフト更新履歴の書き方
- コーディング規約の考え方
- コード自動整形ツールの設定
そして、設計資料の書き方というのが残ります。設計資料には、機能要件と非機能要件の両方を記述します。
機能要件には次のことを書きます。
- 個別の機能の目的
- 関連する入力情報のサイズや型
- 期待する出力情報のサイズや型
- データベーステーブル定義
- データベース更新条件
- 開発中に見つかった不具合
- 想定する不具合とリスク評価
非機能要件にはたとえば次のことを書きます。
- ソフトウェアの実行環境の構築方法
- 手動バックアップ方法
- 自動バックアップ
- バックアップによる復旧方法
- ソフトウェア全体の稼働状態の確認方法
- データベースの帳簿様式の更新方法
- サーバーの停止可能条件
- サーバーの応答時間限界
- サーバーの受付可能数
- オープンソースの著作権
これらの項目を見てみるだけでも「ソフトウェア開発の現場では開発資料が重要」と述べた理由がわかるかと思います。
キャリアの出口
ソフトウェア開発を生業としていきたい場合には、プログラミングそのもの以外にも網羅的な知識と実務経験が重要です。
未経験からリスキリングしようという場合には、相当の覚悟と根性をもって取り組まないといけません。
プログラミングは「ちょっとできる」くらいが一番悪いです。「ちょっとできる」だとIT系下請けになって、長時間労働が待っています（IT土方）。
フリーランスにも穴があります。「月単価80万円すごい！」みたいのは、80万円という数字は本当だとしても、すごい！というのは嘘です。大手IT会社のエンジニアに外注したら、最低でも月単価は100万円です。プロジェクトリーダーとかは150万円から250万円とかです。「80万円」というのはとんでもなく低いです。
そもそもフリーランスでも、それなりの会社の主体であるプロジェクトチームに一員として入るはずです。つまり、月単価が150万円とかになるはずです。
そうした満足いく収入を得ようと思ったら、キャリアとしては「強い自社製品をもっている会社での上流開発」に携わる必要があります。
そのためには「ちょっとできる」ではなく「全部できる」という水準を確保しておく必要があるわけです。
キンドル独学のアウトプットの場は？
もちろん勉強勉強勉強、、、ではいつまでもアウトプットできません。
実践的なアウトプットとしては、「大規模なオープンソースプロジェクトに参画する」ということを目指しましょう。
有志のソフトウェア開発者たちが、自分たちと世の中に役立つソフトウェアを無償提供しています。「すべてのソフトウェア知的財産は人類全体で共有されるべき」という思想があります。この思想によってソフトウェア産業がとてつもない速さで拡大しているともいえます。
「有志開発者が無償提供している」ソフトウェアは、そのプログラムコードがすべて公開されています。プログラムコードのことをソースコードとよぶので、公開されているものをオープンソースとよびます。オープンソースのソフトウェアをOSSとよびます。
OSSプロジェクトにはプロのソフトウェア開発者が多数参画しています。大規模・有名なOSSであれば、商用ソフトウェアさながらに設計資料も作成・公開・更新されています。コードの修正更新時も綿密な審議（レビュー）を経ています。まさしく「プロのチーム開発の現場」そのものです
敢えて言います。「OSSに参画しろ！」と。OSSプロジェクトに継続的に貢献する能力があれば、ほぼ確実に能力は認めてもらえます。
もちろん、自分だけのポートフォリオをつくるのでも構いません。その場合はGitHubに公開しましょう。設計資料もCI環境もセットで公開しましょう。「プログラミング以外の周辺のこともできる」とアピールできる材料をしっかり全部揃えましょう。
しかし、ポートフォリオをそこまで作り込むのは未経験では不可のと思います。だからこそ、「手本」のあるOSSプロジェクトに飛びこんでいくべきなのです。
満足いく収入・待遇が得られるかは自分次第。迷っているなら、プログラミング以外のスキルを学ぶことに切り換えましょう。
本記事を読んでも迷いがないなら、すぐに始めていきましょう。OSS目指して、まずはJavascriptの反復練習から！
まとめ
ここに