🛬

Webアプリの作り方を、知識ゼロの人に手引きする試み

2024/04/09に公開

プログラミング入門

idea

予備知識ゼロの人を対象読者に、Webアプリの作り方を手引きする記事をnoteに3年がかりで連載しました。PV数は少なく、対象読者からの反応は皆無だったものの、いろいろ学びがありました。

そこで、玄人筋の方々が読むZennに場をうつして、宣伝を兼ねてやったこと、わかったこと、つぎにやることなど、共有したいと思います。

各記事はこちらから辿ることができます。

連載の背景とねらい

背景：IT人材不足

IT人材不足が叫ばれて久しいです。一方、プログラミングスクールが社会に供給する卒業生たちには、IT人材としての適性が欠けていることが多いというジレンマも、けっこう知られているようです。

そもそも、適性を測ることじたい難しい話であって、アメリカの大学のコンピュータサイエンスの学位すら、適性を判断する材料にならないらしいですけどね（いわゆるFizz-Buzz問題の問題）。

ねらい

ところで本来、ITの仕事は、適性のある人にとってみれば、けっこーちょろい、らくに良いカネになる仕事でもあります。しかも、技術を身につけるために必要なリソースは、授業料を払わなくても、タダでネット上に転がっています。ただ、どこで何から拾い集めれば良いのか、初心者には分からないだけのこと。

だとすれば、予備知識ゼロであってもIT人材としての適性があるひとに、「技術を身につけるためのリソースの拾い集め方」（ググり方）を手引きする無料のリソースを作れないものでしょうか？

このようなことを友人と会話をした結果として、私が入門記事をnoteに連載してみることになりました。この連載を読んだ適性のある人が、プログラミングに興味を持ち、IT人材となれたなら目的は達成です。

やったこと

記事一覧

心構え・開発環境準備編

Web フロントエンドその１静的コンテンツ編

ここまでは書いていて困るところは、とくにありませんでした。ただし、Webブラウザの開発者ツールを指す一般名称が無いのには、まいりました（08回の記事）。

Web フロントエンドその２スクリプト編

ちょっと乱暴だったかもしれませんが、初手からDOMを扱いました。「A=A+1」とか「数あてゲーム」みたいなのを書かせて、プログラミングを始めるのではなく、「理屈はともかく、具体的なモノを動かして遊ぶ」ことからプログラミングに入ってもらいたいという思ったためです。

「if と boolean」（15回）、「for-each と iterable」（16回）はセットで紹介したいというのは、私のけっこう強いこだわりでした。

Web バックエンドその１ HTTP 初歩編

「シェルの使い方しらなければ、npm使えないじゃん」と気づいて、慌てて19回目の記事を足したあたりで、ちょっとこの連載は簡単には終わらないぞと気づきます。

Herokuの無料プランが終わったのは大きな痛手でしたが、当時 render.comの日本語記事が少なかったらしく、25回目の記事は、不本意にも連載中最もPVを集めた記事になってしまいました。

21回目の記事で書いた、聖徳太子の図は自分で気に入っています。

関係データベース編

ポスグレのインストールを案内するのが意外と面倒でした。

29回目のスケールアウトと排他制御の回は、連載中ではちょっと異色のポエム回です。コンピュータシステムであっても、人間組織であっても、オーバヘッドの発生原因となる構造は共通している、ということは結構、声を大にして言いたいです。

Web バックエンドその２ DB を用いた Web アプリ編

32 回の async/awaitの回は我ながら労作です。

バックエンド編の始まりのころからですが、「知っておいてほしいキーワードをググっても、まともな説明がヒットしない」「ChatGPTに訊いても、その説明は私の頭にも、すっと入らない」というのが頻発。新しい概念にひとつ触れるたび、ひとつ記事を書くはめになり、フロントエンド編にくらべてペースがスローモーになってしまっています。

Web バックエンドその３認証認可編

認証認可はとても面倒なので触れたくなかったのですが、その面倒さに触れないわけにはいけないだろうということで書きました。ついでにミドルウェアの話ができて良かったとは思っています。

総括

42 回ちょっとハードな長旅を終えて

以上、Webアプリつくるにあたり、基本的なところをまるっと全部、という感じで技術をさらいました。ちなみに私は「フルスタック」という言葉には違和感を覚えてるタチです。

心掛けた記事のスタイル

連載の狙いから、記事のスタイルはおのずと定まりました。

読者には手を動かしてもらい、動く喜びを感じてもらう

自分が作ったモノが思い通りに動く喜びは、何にも替えられませんので。（ま、自分の思い通りにヒトを動かせる喜びには、かなわないですが）

過去の記事で紹介していない知識は、前提とせず都度解説する

知識の習得の前提に、別の知識が必要になると、とてもウンザリするものです。そこで、ゼロから一つずつ積み上げるように技術を習得できるよう、記事の順番にはとても気をつけました。

とはいえ、一度前提を知ってしまっている身にとって、そこに前提知識が必要であることに気づくのはとても難しいことです。そこで、なるべく自分の経験のない技術スタックを紹介することにしました。

具体的には、私はJavaおじさんなのですが、そんな私がJavaを教えようとすると、どうしても紹介すべき内容が抜けおちてしまうのではないかと思ったわけです。そこで、ほとんど私も触ったことのないNode.js周辺の技術を使うことにしました。

そして、「理解したうえでないとググれない」ような基礎的な概念については、丁寧に説明することにしました。なにより、丁寧に説明しようとすると、自分にとって勉強になりますから。でもまあ、難しいですね。

ググりゃ分かるものは、さわりやキーワードしか紹介しない

いっぽう、「ググれ」「ChatGPTれ」で済ませられるものは、なるべくそれで済ませるようにしました。

「何でググればいいのか」が分かるようになるためには、そもそも何を理解しておかなければいけないか。その順番を間違えないようにだけ気をつけました。

適性のない人は置き去りにしてよい

記事で読者に示す課題は、解けずに脱落するひとが出てもやむないレベルのものを設定しました。あえて難しいものは作りませんでしたが。

それに、「適性のない人だって卒業させなければいけない」ことこそが、プログラミングスクールが抱える最大の矛盾ですので。

フレームワークやマネージドサービスには極力頼らない

All in Oneなフレームワークにはなるべく頼らず、個々の要素技術を低レイヤでちゃんとさらいました。ORMみたいなものも使いませんでした。

これは、フレームワークの多くは、そもそも個々の要素技術に対する理解がある人に向けて、開発の省力化を助けるためのツールでしかないと思うからです。フレームワークの導入により開発生産性は上がっても、技術習得の効率はむしろ下がると思います。

これは単に私がRailsが食わず嫌いだったり、Djangoが食ったうえで嫌いだったりというのもあります。完全に私の好みですが、私は "Explicit is better than implicit" の考えが好きで、"convention over configuration" の考えが大嫌いだったりします。

また、Railsの上にのってコードを書いてきたプログラミングスクールの卒業生が、自分が書いたコードが結局どこでどう動いているか理解できていないため現場で詰んでいる、という悪評をWebで読んだというのもありました。

記事執筆の心構え

頑張らない

イヤイヤ書くのはいやなので、頑張らないようにしました。スキマ時間でダラダラ続けたせいで、連載の完結に3年かかってしまいましたが、飽きずになんとか一区切りついたのは我ながらエライとおもいます。

自分で面白がる

これは普段の仕事も同じですね。金を出してくれる人のために働くなんて、まったく下らないですが、面白さをみつけて面白がろうすれば、辛さも減るし生産性も上がるものです。というわけで、記事中気の向くままに脇道に逸れることがあっても、そんな自分を許しました。

PVや反応を目当てに書かない

PVやいいねなどの反応は目指さないことにしました。他人のウケを狙って、自分で面白がれないものを書くのはしんどいので、ひたすら自分自身からの「いいね」を目指しました。

わかったこと

書いていてわかったこと

学ばなければいけないことがめちゃくちゃ多い

まさか、42回も記事を書くはめになるとは、思いもよりませんでした。当初の想定の倍以上です。

しょぼいWebアプリ1つ作るのにも、意外と多くのことを知らなければいけない、そして意外と多くのことを私は身につけているもんだ、ということは大きな発見でした。

ネットに分かりやすい説明がない

記事を書き始めたときには、ポイントとなる概念について、私自身が解説するつもりはありませんでした。「XXXとはどういうことか、ググってしらべてください」とか、「このページに分かりやすい説明があります」とかで済ませるつもりだったのです。

ところが、私自身が一生懸命ググっても「分かる人向けにはこの説明でいいんだろうけど！」「意味を知らない人に、こんな説明でわかるか？」というような説明しか見つからない概念が、意外と本当に多かったのですね。私のググり力が足り無かっただけなのかもしれませんが。

仕方なく、ポイントとなる概念を、私自ら、記事で説明することが連載の後半になるにつれ、多くなってしまいました。

ネットに無い分かりやすい説明を、私になら書けるのか、そんなわけないでしょ、という感じもしますが、できる限りのことはやったつもりです。もちろん最初は心細かったです。ですが、途中からChatGPT4にレビュアーになってもらったのでだいぶ心強くなりました、本当に大変世話になりました。ChatGPTは私を褒めて伸ばしてくれました。

私がフロントエンド技術に全く興味を持てないということ

フロントエンドとサーバサイドで、記事の熱の入り方が違うのに気づきました。いま仕事でもReactとか使っているし、UIやUXの重要性は分かっているつもりなのですけどね。

記事への反応からわかったこと

PV数

ビュー数トップ2の記事のタイトルに「Render.com」が入っています。

どうも執筆当時、Render.comの日本語記事が無かったみたいで、これがSEO的に効いたみたいです。私の記事の狙いや好みとは真逆で、特定のサービス名やライブラリ名などの固有名詞が出ているところに、人が集まるみたいです。

とはいえ、PV数は目的ではないので、数は追いませんでした。「数を追う」仕事には就きたくないもんだ、とも思いました。マーケティングとかやる人は大変ですね。

好意的なコメントを１つ頂きましたが、それだけです。まあわたしも、ブログの記事にコメントなんかしないですし、そんなもんでしょうかね。

ま、コメントをもらうために記事書いたわけじゃないので。

スキ数

何にスキをもらえるのかは、ついによく分からなかったです。

つぎにやること

同僚にこの記事を共有

知人に宣伝しまくって、この記事経由でトラフィックを流入させて、PVがどれだけ伸びるか見届けたいとおもいます。

noteはつづける

ある程度のペースでつづけたほうがいいと、note運営自身が言っているので。今後はポエムみたいな記事や、さいきん覚えたPythonに関する記事を書こうと思っています。

最後に

以上、私の振り返りを、共有しました。

この記事の読者には、新人技術者や、若手技術者に対してモノを教える立場の方も多いかと思います。教え方に困ったとき、私の書いたnoteの一連の記事、またはその一部でも、何かしらのヒント、もしくはテキストとして、お役立ていただければ、幸いです。

宣伝

noteには転職Tipsも書いています。こちらもよろしければぜひ。