![\"\"](\"https://www12.a8.net/0.gif?a8mat=3H3QZH+5K1O1E+3L4M+BW8O2\")
という講座と、実践編：React NativeとFirebaseで作るiOS/Androidアプリ：お店レビューアプリ開発編
![\"\"](\"https://www17.a8.net/0.gif?a8mat=3H3QZH+5K1O1E+3L4M+BW8O2\")
という講座で勉強しました。\nこんにちは。妹尾です。フリーランスでフロントエンドエンジニアをやっています。詳しいプロフィールはこちらから。
2021年の目標を先日立てましたが、目標だけ立ち上げて振り返りをしなければ何の意味もないので、今後月次もしくは隔週でのスプリントのように目標管理をしていこうと思います。
2021年の目標として立てたものはこちらからどうぞ。
古いライブラリの置き換えが正直かなりしんどかったです。
外部ライブラリをjest.doMockでモックしてあげて、jest.isolateModulesして干渉させないようにして...と、単なるコンポーネントに対してテストを書くよりよっぽど難しかったけれど、非常に勉強になりました。
JestとReact Testing Libraryの使い方はこれで少し分かってきたので、普段からもちゃんとテストを書けるようにしたいところ。
\nReact Native入門：ニュースアプリを作りながら覚えよう/Hooks対応版という講座と、
実践編：React NativeとFirebaseで作るiOS/Androidアプリ：お店レビューアプリ開発編という講座で勉強しました。\n
ライブ配信駆動開発は14日やってみました。
日々ブログの機能追加やデザイン面の調整、バグ対応などを進めていました。
ブログを開設して1ヶ月経ちました。
週に2,3本書くのを目標にしていたので若干下振れです。
1月のPVが1500程度で、この数字が良いのか悪いのかはよく分かりませんが、技術メインのブログなのでまぁそれくらいのもんだろうと思っておきます。
今月読んでいただいたトップ3が以下の記事。
Google AdSenseは申請してもうすぐ2週間経つのですが音沙汰なく...これでNGだったら勘弁してほしいところです笑
Google Search Consoleの設定がちゃんとできていなかったみたいなのとちゃんと検索に乗るのは早くて3ヶ月くらいとのことなので気長に検索流入が増えていくのを待とうと思います。
余計な間食もなく、体重が着々と落ちていっているのは嬉しいですね。
Fit Boxing2が楽しくて続いていたのですが、体をひねったときに肩を痛めてしまって今は運動量が落ちています。
夜型を改善しようというのを目標にしていたのですが、ついつい1時くらいまで起きてしまうので意識して改善しようと思います。
そして余談ですが、今年の1月4日、応援しているFC東京がルヴァンカップを制して9年ぶりにタイトルを手にしました！！✨![](\"https://images.microcms-assets.io/protected/ap-northeast-1:c7c8182c-88d5-4972-a4d4-22b5f7904ef2/service/gens-blog/media/136091525_3638051532944962_5448376864168559050_n.jpg\")
本当に嬉しかった。今年1年頑張れる。今年こそはリーグタイトルを取りたいですね。
ちゃんと目標管理できるように記録として残しておきます。
それではこの辺で。
目標管理でもあるので2月中頃にも進捗書こうと思います。
こんにちは。妹尾です。フリーランスでフロントエンドエンジニアをやっています。詳しいプロフィールはこちらから。
今日は「フロントエンド開発入門」という本について紹介していきます。
本書はWeb系エンジニアに興味を持っている方、特にフロントエンド技術に興味を持っている方に特にお勧めな書籍です。
Webフロントエンド開発が未経験の方でも十分に読める内容であり、フロントエンドに携わったことのある方ならばより深く共感を持って読めると思います。
本書はフロントエンド開発の変遷や、必要とされている技術、アジャイル開発のようなWeb系開発の手法について解説がされているため、現代フロントエンド開発へ入門するための教科書と言えるでしょう。
![](\"https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/1771/9784798061771.jpg?_ex=200x200\")
最近のWeb開発ではフロントエンドの技術が必須です。とはいえ、HTMLに追加される新しい要素や属性、増えていくCSSプロパティやルール、年々アップデートされるJavaScriptなど、複雑かつ膨大な情報を整理するだけでも大変です。本書は、初級者向けにフロントエンド開発支援ツールの選び方や使いこなし方、効率的に開発をするための基礎知識が身につく入門書です。複数の支援ツールから「なぜそれを使うのか」選択する基準がわかります。（秀和システム「この本の内容」 説明文より引用）
Webフロントエンド開発において、非常に技術・ツールは流行の変化が早く、「どこから学び始めれば良いかわからない」「学習できたと思ったらまた次のツールが出てきた」などの感想を持つ方もいるでしょう。
しかし、著者も記しているように2010年代に比べると混沌とした技術変遷は穏やかになりつつあります。
それでもフロントエンドエンジニアが担当する技術領域は広範囲に渡ります。
この本ではフロントエンドのWebアプリ開発領域で主要となる技術・ツールについて、「なぜその技術・ツールを使うのか」を主眼において解説されています。
「変わり続けるプラットフォームで変わらないことを学ぶ」と帯にも書かれていますが、本書を読むことで変わり続けるWeb開発記述の変遷の中でベースとして身に付けておきたい知識を得ることができます。
本書の構成は大きく3部構成です。
パート1は紹介されたツールが「何を解決するもので」なぜ「導入するのか」を、これまでのフロントエンドの歴史的変遷を踏まえて理解するパートです。
パート1では以下のことを学ぶことができます。
一部コードは書かれているものの、ここで重要なのはコードよりも雰囲気を掴むことなので、特に初心者の方はパート1だけでもまず読み進めても良いでしょう。
特に開発現場での仕事の進め方について触れられている点は非常に良い点でした。
パート1で、フロントエンドに求められる技術スキルの範囲はやはり広いということが理解できると思います。
パート2はフロントエンド開発の基盤構築からライブラリ・フレームワークの導入、設計・実装方法など、実際の開発現場のことを想定しながら学習できるパートです。
パート2では以下のことを学ぶことができます。
実際に手を動かしながら読み進められるパートです。
このパートではReact, TypeScript, styled-components, Jestが取り扱われていますが、昨今のフロントエンド事情からしてもこれらの技術を触れる・理解できているのは重要だと思います。
意識が薄れがちなパフォーマンスにおいてもLightHouseとGitHub Actionsを使った定期的なパフォーマンス計測が紹介されており、実践的な内容になっています。
パート3ではパート2よりもさらに発展的な内容が解説されています。
フロントエンドエンジニアとして開発チームでどう仕事に取り組むべきか、マインドセットなども紹介されています。
パート3では以下のことを学ぶことができます。
保守運用フェーズで必要となってくるデータ解析や、エラーモニタリングについて、また、スクラム開発の詳説がなされています。
フロントエンドはユーザーから見える部分、いわばユーザーがWebサービスを使用するかどうかの入り口に当たるので、日々Google Analyticsなどの解析ツールを使いこなして、サイト・アプリ改善に活かしていくことがビジネスの成功に繋がります。
ある意味でビジネスに深く関われるのがフロントエンドが重要かつ面白いと個人的に思う点です。
OSSやコミュニティなどへの貢献について記されているのもこのパートです。
どれもモダンフロントエンドを志向する現場で使う可能性の高いものです。
「フロントエンド開発入門」という本について紹介しました。
本書が発刊されたのは2020年10月なので、ブログ執筆現在(2021年1月)でもほぼ最新のフロントエンド開発事情を知ることができる本でもあります。
自分の経験から振り返ると、SIerからフロントエンドエンジニアへ転身する時点でこの本に巡り合いたかったと思いました。
フロントエンドエンジニアを志す人、今フロントエンドエンジニアとして従事している人、HTML/CSSはやってみたけど次に何をすれば良いかわからない人にぜひ読んでみていただきたいです。
JAMStack・・・JavaScript / API / Markupの頭文字。
JavaScriptで外部APIを叩いてMarkup(HTML)を構成する技術のこと。
このブログはJAMStackな技術を用いて作成しました。
作るに至ったきっかけやメリット・デメリット、そこで得た知見などをブログ構築の一番手の選択肢であるWordPressと比較しながら紹介します。
そもそもJAMStackって何？という方は、先日2021年の「フロントエンドエンジニアに求められそうなスキル」という記事の中でJAMStackについて紹介している箇所があるので併せて読んでいただければと思います。
https://blog-sorellina-coda.dev/articles/mi8bywjolf
イケてる技術＆好きな技術で自前のブログを作りたい！というのがモチベーションの源泉です。
以前Nuxt.js, Contentful, Netlifyを主に使ってブログを構築したこともありましたが、ブログそのものを更新しなくなってしまいました。
その前のブログをそのまま使うでもよかったかもしれませんが、
という点から、Next.js / TypeScript / Vercel / microCMSの構成で作り直すことにしました。
結果としてトップページ、記事ページともにLighthouseで高スコアが出るくらいの改善がなされました。![](\"https://images.microcms-assets.io/protected/ap-northeast-1:c7c8182c-88d5-4972-a4d4-22b5f7904ef2/service/gens-blog/media/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-01-23%2023.36.26.png\")
やはり静的Webサイトの生成はパフォーマンスに優れていますね。
ページ遷移も非常にサクサクで、体験もよく感じています。
正直、ブログで収益化を目指すならWordPressで作った方が圧倒的に立ち上げが速いと思います。
ブログ向けのテーマやプラグインも充実していますし、事例も豊富です。
SEO対策もすでに整っているテーマなどが販売されていますし、WordPressブログは始めるだけならとても簡単です。
ただ、ページデザインの自由度はJAMStackブログに軍配が上がると思いますし、偏見が入りますがWordPressのセキュリティ対策が正直面倒に感じています。
今、個人開発でWordPressか...という若干過激派思想的な部分も正直あります。
JAMStackのメリットは、SPA(Single Page Application)としてクライアントサイドで動くため、自前でサーバーを立てたりレンタルサーバーと契約する必要がないところです。
静的なアセットをVercelなどのホスティングサービスに乗せて配信しているだけなので、サーバーの管理をする必要がありません。
例えばWordPressだとサーバー側でページを構築するため、サーバーが停止してしまった場合にブログの読者にページを提供できなくなってしまいます。
JAMStackの場合、ページの構築はビルドを行うタイミングになるので、仮にサーバーが不具合で止まるとしても記事・ページを新しく作る段階で影響を受ける程度です。
すでに配信されているページには影響を受けません。
また、レンタルサーバーを契約すると大体月々1000円ほどかかる見込みですが、JAMStackなこのブログは「完全無料」で動いています。ドメイン代で年1000円ちょっとかかってます🙇♂️
今後ブログを収益化すると考えるとこのランニングコストの差は大きいと思います。
JAMStack構成ではサーバーを基本的に持たないため、攻撃の入り口になるような対象がなく、安全性を保ちやすくなります。
WordPressのセキュリティ対策が面倒と前述したのは、WordPressはサーバー上で動くためです。
世界の約3割のサイトがWordPressで構築されていると言われており、攻撃者からすればWordPressのサイトをターゲットにすることも多いです。
常々脆弱性対策をしなくてはならないのがWordPressのデメリットとも言えます。
ログインページを/wp-admin/のままにしていませんか？攻撃者の格好の的ですよ。
JAMStack構成の場合、ページをサーバーからの返却ではなく静的アセットとして事前生成しておくことでCDN(Content Delivery Network)から配信できるので非常に高速です。
サーバーでの処理を挟まないため高速化が実現できているというわけです。
ブログとしての用途だとコメント機能など一部例外はありますが、動的に値が変わる要素はほぼ無いので、オリジンサーバーを介して配信する必要がありません。
また、静的アセットの配置などもGithub連携などCI/CDの構築が容易である点はメリットだと思います。
JAMStackブログでは、View、API、ホスティングをそれぞれ別のサービスを用いて作るため、例えばViewのところが気に入らなくなった時に他のところは残して作り直すのが容易です。
例としてNext.js / microCMS / Vercelでこのブログは作っていますが、今後Next.jsが落ち目になり新しいフレームワークで作った方が良いとなれば、Next.jsの部分は他の技術に置き換えてmicroCMSでブログコンテンツの管理は続ける、ということが可能です。
各サービスで責務の分離がされているので障害時にも何が悪いかの切り分けがしやすいのもメリットだと思います。
WordPressには先人たちの作った数々のプラグインやテーマが存在するため、デザインを深く考えなくてもいい感じのブログが作れます。
一方JAMStackブログでは内部処理やUIコンポーネントはパッケージ、ライブラリとして提供されているものがあるものの、基本的には自分でページデザインを考え、コンテンツデータ取得の処理を書かなくてはならないため、構築まで時間がかかります。
WordPressならおそらく1時間もあればブログとしての体を成すものが作れると思いますが、JAMStackで0から作るとそれ相応の時間がかかります。
僕はいろいろ調べながら作って2〜3週間くらいでブログの体を成す形に仕上げました。
JAMStackは作成したコンテンツを公開する際に、コードをビルドしてHTMLなど静的アセットを生成し配信しています。
コードのビルドがいつ終わるかはページ数次第なので、「17時ぴったりに情報解禁！」と思って17時に公開ボタンを押したとしてもビルドが終わるまでの数分間はページ表示ができません。
WordPressならコンテンツ公開の時点でサーバーにコンテンツを登録し、ユーザーが見に来たタイミングでページを作るので時間通りに公開も可能で、(調べてないので分かりませんが)タイマー配信もできるのではないでしょうか。
先述の通りコンテンツ公開の都度全てのページに対してビルドを行なっているので、ページ数が多いと公開まで時間がかかってしまいます。
もちろんビルド中にはそれまでに公開しているコンテンツに影響は無いので個人ブログ程度の分量ならほぼ影響はありませんが、ニュースサイトのように莫大なページ数を持つWebサイトにはJAMStackは向いていないと言えます。
JAMStackではいくつかのサービス、フレームワークを組み合わせて構築するので、「どれを使って構築していいかわからない！」となる場合がありそうです。
WordPressならWordPressだけで完結できるのでJAMStackのこのサービスの組み合わせは煩雑に写るかもしれません。
どの組み合わせがいいか迷ったときはNext / microCMS / Vercelで良いのではないでしょうか。
メリットのところでも書きましたが、合わなければそのサービスの部分だけ置き換えることも十分可能です。
ざっと箇条書きにします。
JAMStackは2021年現在、注目されている技術であり、ブログの構築の場合WordPressよりも運用コストは低いと考えています。(導入コストは若干高いですが...)
JAMStackブログの構築は以下のようにメリットが多くデメリットも実はほとんどない手法だと思います。
知見のところで述べましたが、フロントエンドエンジニアを目指したい人ほどJAMStαckでブログを立ててみるのは有効な気がしています。
Viewの部分はゴリゴリJSフレームワークを使って作りますし、APIとの接続≒バックエンドとの連携は現場で必ず使う技術ですし、ブログを立てた後はそこに学習記録を残していくことで求職時のアピールにも繋がります。
トレンドな技術でブログを立ててみたい！という気概があればぜひJAMStackに挑戦してみてはいかがでしょうか。
00:00 Studioという、クリエイターが作業の様子を淡々とライブ配信するサービスが昨年末に正式リリースされました。
こちらのサービスで約1ヶ月(毎日ではありませんが)ライブコーディングを続けてみました。
そこで、自分の作業の様子を配信することで感じたいくつかのメリットを書いていきます。
きっかけは2つのそして後述する2つの記事を読んだことです。
Qiita: 生放送駆動開発を1000日やったら進捗出たのでみんなもやろう！
note:「プロセス・エコノミー」が来そうな予感です
「自分の作業の様子を生放送で配信する」こと、「作業の様子(プロセス)を共有することがお金を稼ぐメインになる時代がきている」ことから、(人に見られているというプレッシャーから)自分の作業の進捗を出すだけでなく、自分や自分の作品・サービスの認知度向上、ファンの獲得が狙えるよ、ということです。
自分一人での開発だとだらけてしまいがちなところも人の目があるとサボることもできないので、「これは良いかもしれない！」と思い昨年末からライブ配信駆動開発を始めました。
この1ヶ月では、このブログ(https://blog-sorellina-coda.dev/) の開発の様子を配信していました。
ReactNativeで作りたいアプリもあるのでそれに向けた勉強の様子(Udemyで勉強しています)を配信したこともあります。
先述の通り、見ている人がいる以上作業をサボることができません。
大体1時間から2時間弱毎回配信をしていますが、「ここまでやろう」と決めていたところよりもさらに先まで作るくらいの進捗が出ることもあります。
視聴者が自分の作っているWebサービスの様子を知っているので、よく個人開発で起こりがちな「モチベーションが続かずリリースしないでお蔵入りする」ことが避けられると思っています。
個人開発の敵はある意味「孤独」だと思っていて、誰か他の人に作っている様子を共有することでその孤独感を解消しつつ作業を進めることができるのは大きなメリットだと感じました。
また、配信でしゃべりながら作業を進めることで、ラバーダッキング手法(ゴム製のアヒルのおもちゃに話しかけることで、頭の中で問題が整理されて解決を導く手法)のように詰まった時の解決も容易になることがあります。
しゃべることで後述の「アーカイブを動画メモとして使う」ことの威力も上がります。
暴論ですが、人は自分が書いたコードの意図を忘れます。
だからこそコメントをコードに残すべきで、文字情報をコードに残しておくことで意図を思い出すことができます。
さらに踏み込んだ内容として、自分の配信をアーカイブして、そのアーカイブ動画をメモがわりに見ることができるので、コメントとして文字化したものだけでなく思考・プロセスを確認することができます。
文字情報だけだと欠けてしまうような、「どう考えて、どういうサイトを検索して、どういう解決策を試したか」というプロセスが残るため、次に似たような実装をする時の思い出すきっかけや、「あの参考にしたサイト、どうやって探したんだっけ…」と忘れた時も動画メモを通して確認ができることもあります。
00:00 Studioでは自分の配信をアーカイブすることができるので、上記のメリットを享受できます。
自分の作業の様子やサービス開発の様子を発信し、視聴者が自分や自分のサービスのファンになってくれることもあります。
SNSが発達した現代において、発信することで「まず、知ってもらうこと」が容易になってきました。
ライブ配信は大きな広告を出すことなく人にリーチできる手段の一つだと思っています。
また、こうしたライブ配信を通じて自分を知ってもらい、仕事に繋がる可能性もあります。
百聞は一見に如かずと言いますか、普段どう勉強や開発をやっているかわからない人よりも、勉強や開発の様子を配信している人の方がプログラミングの実力や普段の様子などを知れる分、採用担当者が経歴書だけを読むより説得力が強いのは明らかだと思います。
00:00 Studioでは「差し入れ」と称して小額から投げ銭がいただける制度もあるのでちょっとしたおこづかいがもらえるかもしれません。
Youtube Liveだといくつか収益化までハードルがあるのでさくっと始めたい人には00:00 Studioの方が敷居が低いと思います。
個人開発だと自分の書いたコードのレビューは誰にもしてもらうことが基本的にはできず、詰まった時も自力で解決する必要があります。
自分のコーディングの様子を配信しているので、視聴者からアドバイスや解決策をコメントしてもらえることがあります。
自分がドライバーで、視聴者がナビゲーターとなる擬似的なモブプログラミングが配信を通してできるので、詰まった時の解消スピードもたった一人で進めるよりも上がります。
これはかなり限定的なメリットです。
00:00 Studioで配信をする前はYoutube Liveで2,3日ライブコーディング配信をしたことがありました。
Youtube Liveでは配信のためにOBSというソフトを使う必要があり、操作に慣れがいる部分があります。
たまたま業務で動画配信のためにOBSを使う機会があり、操作方法を知っていたのですんなりと作業できたことがあります。
一般に動画の配信はOBSを使うことが多いみたいですね。OBSはかなりメモリを食うみたいで、M1チップでないMacbook Proを使っているのでファンがめちゃくちゃうるさく回っていました。
00:00 Studioは画面共有で配信するスタイルなので負荷が少ないみたいです。
この記事では個人開発をしているエンジニアに向けに書いていますが、初学者のエンジニア志望の方にもライブ配信駆動開発は有用な手法だと思います。
「初心者だと作業が止まりがちで見る人がつまらないのでは…」という心配もあるかもしれませんが、視聴者からのアドバイスを受けられる可能性もあります。
エンジニア転職の際にも「ライブ配信で勉強の様子を配信していました！コードを書く様子はアーカイブ動画に残っているので見てください！」とアピールできます。
学習の様子やポートフォリオ作りを配信していたりすると、自分で考えて、勉強してWebサービス・ポートフォリオを作っている証明にもなりますね。
アピール材料は多いに越したことはありません。
主に画面共有の形で配信することが多いですが、「見せてはいけないもの」を見られてしまわないかは気をつけましょう。
請けている案件のフォルダだったり、Google検索の履歴だったり、.envの秘匿情報だったりと、思いがけず配信してしまうと時に事故の原因になりかねません。
僕は基本的にデュアルディスプレイで配信して、片方を配信用画面、もう片方を退避用のスクリーンとして使っています。
配信を始める前に配信用のディスプレイをchromeとVSCodeだけにして配信しています。
手間はありますが一時的に.envを触る時は退避用のスクリーンで操作することにしています。
ライブ配信駆動開発でモチベーションを高めながら開発を進めることがこの1ヶ月はできているので、とても有用な手法であると実感しています。
一つ自分の改善点を挙げるとすると、夜に配信することが多く、子供が隣の部屋で寝ているので音声オフで配信することも多く、動画メモとしての使い方の威力半減や視聴者さんとのコミュニケーションがテキストベースになってしまうことです。
統計など取ってはいませんが音声オフの時はオンの時よりも視聴者さんの離脱率が高いような気がします...音声オンで喋りながらの配信の方がもしかしたら良いかもしれません。
最後に宣伝になりますが、ほぼ毎日、大体22時ごろにライブ配信をしながら開発をしています！
コメントなどいただけたらとても嬉しいです！
00:00 Studioのマイページリンクは↓
https://0000.studio/gengineer
SIer所属のシステムエンジニア(SE)の方にはもしかしたら耳が痛い話かもしれません。
「俺はプログラミングなんかしないで、1つの会社でマネジメントして稼いでいく！」という方には不向きな内容です。
結論から言うと、SIer所属でプログラミングを業務で行っていない場合、もし転職やフリーランス転身を考えた時に「詰む」可能性があります。
かつて自分も金融系元請けSIerとして新卒入社し、4年目頃から一切業務上でプログラミングをすることがなくなっていきました。
そうした状況に危機感を感じ、動くなら20代のうちと考えたため、5年目途中でSIerを退職、フリーランスに転身しました。
僕のように文系卒・SIer所属で「業務でプログラムなんて書いてないな…この先不安だな...」と思っている方に読んでいただければと思います。
Sierの仕事はプログラミングスキルがない場合でも成り立つようになっています。
プログラミングをしなくても
といった仕事があります。
上記の仕事は上流と呼ばれるマネジメント系統の仕事ができるのであれば、それなりの給与(1,2年目でも額面500万くらいはもらえてました。元請けだったからではありますが)はもらえます。
一方で、ドキュメント作成やテスト、ユーザーからの問合せ対応などを中心にしている場合、転職時に市場が求めるスキルがついているかと言われると「ノー」かもしれません。
SIerでのテストは、全てがそうとは言いませんが、人力で目視で、Excelにエビデンスのスクショを貼って確認するパターンが多く、テストコードを書く文化があるとは言い難いものです。
そしてプログラムを書かない場合、得てして「自社のシステムに詳しい」が、世間一般で使われている技術には疎くなる可能性が高くなります。
一般にSEは「手に職がある」と言われることが多いですが、システムエンジニアとしての市場価値を考えるとプログラムのわからないエンジニアは転職の難易度が上がります。
仮にWeb系自社開発企業への転職やフリーランスへの転身を目指すとすると、企業から求められるのは手を動かしたシステム開発経験です。
どんなプログラミング言語で何年ほど開発経験があるのかを問われ、その経験が乏しい場合は採用を見送られるか、転職先でもテストやドキュメント作成の仕事に追われることになるでしょう。
日本の終身雇用制度はもう長くは持たないとされている中、本当に「手に職」をつけてIT業界に留まるならばプログラミングの知識・経験は必須だと考えています。
むしろプログラミングをせずに何年もSIerに留まっていた場合、新卒社員よりも年を取ってしまっている分市場価値は下がっているかもしれません。
場合によっては詰みます。
テストやドキュメント作成、マネジメントをやるにしても結局のところプログラミングの知識が求められることを忘れてはいけません。
SIerにおいてSEにプログラミング経験がないと、その案件は燃えやすくなると言えるでしょう。
要件定義や基本設計においてもプログラミング経験がない人が行う場合、開発フェーズで考慮漏れの問題が見つかりがちで「要件が固まってないじゃないか」とか「そもそも設計がクソだ」と案件炎上することもあります。
不具合対応でも同じく「顧客からシステム不具合の連絡を受ける」→「SEが課題としてExcelに事象をまとめる」→「事象の解決策がわからないので下請けのベンダーにお任せする」→「SEがベンダーからの回答を(プログラムのことがわからないので詳細が割愛されて)顧客に伝える」→「顧客に伝わらなくてさらなる問合せに...」と、不毛な伝言ゲームになることもあります。
「これ俺ら要らなくない？直接ベンダーさんから顧客に伝えてもらうのが確実じゃない？」と思うことがかつて実際にありました...
実際にどのようにプログラムを組むことでシステムが動いているかを知ることで、適切な設計の知識や開発手法、扱っているシステムの全貌がわかってくると僕は思っています。
確かに一生マネジメントとして同じ会社で生きていくなら良いのかもしれませんが、SIerのマネジメント職は役職に比例してストレス過多＆残業地獄になることも多いです。
36協定ギリギリ、もしくはオーバーするほど働いて、体を壊して休職される方も見てきました。
SEはシステムエンジニアの略とされていますが、プログラミングでシステムを構築する業務を行わない場合、「システム」を「エンジニアリング」していると言えるのでしょうか。
プログラミングをしないSEの業務は主にマネジメントや顧客との折衝、テストや問合せ対応など、WordやExcelを主に使うドキュメント作成ばかりです。
Excelで設計書を書き、テスト結果をスクリーンショットしてExcelに貼り、各業務フェーズの終わりに上層部へ報告する際にExcelで見栄えよく資料を作る...もはやSE＝資料エンジニアの略ではないかと思ったこともあります。
「システムを使った、もの作りをしています！」と掲げた会社で資料しか作らないとなると...必要な仕事だとわかってはいるものの考えるところがありますね。
プログラミングを勉強しましょう。
自社が使っている言語からでも、転職に向けて興味のある言語からでも良いです。
システム内製部署に部署異動を願い出て、プログラミングをする側に回してもらうのも選択肢としてはありますが、「確実に異動ができるわけではない」、「年次が上でマネジメント寄りの仕事しかさせてもらえない」というケースもあり得るので、少なくとも独学するよう行動するのが良いと思います。
プログラミングを通してSIerの仕事のクオリティが上がるならそれはそれで良いですし、転職するにしても「SIerでしたが、プログラミングは経験がある」というステータスだと完全な未経験からの転職よりも有利にはなると思います。
なんの言語をやればいいかわからない！という場合はまずJavaScriptをやってみると良いです。
ユーザーが触る画面を持つシステムを作っている場合はほぼ間違いなく(バージョンはめちゃくちゃ古いかもしれませんが)JavaScriptは使われています。
JavaScriptをおすすめする理由は以前書きました。こちらも目を通してみると良いかもしれません。
プログラミング学習の最初の一歩にはJavaScriptが有力な選択肢である4つの理由
僕はユーザー系金融元請けのSIerに新卒で入社し働いていました。ユーザー系のSIerならまったり高給という巷の噂に釣られた形です。
幸い大きい企業であることからコンプライアンスの意識も高く、よく聞くデスマーチ的な会社で寝泊りは経験しませんでしたが、長い時は22時まで残業を週5で、しかも始業は8時台と、Web系エンジニア職とはかなり解離があると思っています。
最初に配属された部署がシステム内製部署だったため、Javaでのプログラミングを業務で経験できたことは運がよかったです。(今思い返すと自動テストなんてなかったのでめちゃくちゃ辛かった...)
システムの担当異動でプログラミングを業務内ですることはほぼなくなり、まさに資料エンジニアになって危機感を感じたところで退職しました。
「人も、自分も使うようなものを作って社会と自分の生活を便利にしたい」という思いがあったので、ただの資料作りよりも自分の手でプロダクトを生み出すことのできるエンジニアになりたいと思い転身しましたが、今のところは良い判断ができたんじゃないかと考えています。
文系卒でもシステムエンジニアにはなれます。引く手数多です。ただプログラミングを仕事にすることがないかもしれません。
本当にそれでいいかは考える必要があります。
経験ができたからこそわかったことなので難しいのですが、ここで書いたことは最初に内定が出たからという理由でSIerに入社を決めた当時の自分に言い聞かせたいことです。
今似たような立場に置かれている人にとって考えるきっかけになれば嬉しいです。
そして余談ですが同じ仕事をしているのに銀行からの出向で来ている同年次のメンバーの方が給料が高く部長職も出向行員でポストが埋まるので、SIerのような仕事がしたいなら最初からSIerのような子会社ではなくシステム部門に入るべきだと思います。
先日「フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと」という記事を読みました。
こちらの記事で挙げられている10個のポイントを踏まえて僕の考えを述べていきたいと思います。
近年React・Vue・Angularの三つ巴で推移していたJavaScriptフレームワーク・ライブラリですが、日本においてはReact・Vueの2強体勢になってきた印象を受けます。
Vueの方がタグテンプレート形式であるためHTML/CSSに慣れたWebクリエイターの方でも触りやすい、理解しやすいという利点からデザイナーがHTML/CSSを書くようなプロジェクトでは好まれて採用されるケースがあるようです。
一方でTypeScriptとの相性はReactに軍配が上がり、型安全でスケールしやすく開発効率が高いのはReactだと考えています。
個人的にはReactを推したいですが、2021年にから新たに学ぶのであればReact・Vueのどちらを採用しても有用であると言えます。
その他の選択肢としてSvelteも名前が上がるようになってきていますが市民権を得るにはもう少し時間がかかりそうですね。
JavaScriptフレームワークで開発されるSPAの弱点として初回ローディングの遅さやSEOの対策などが挙げられますが、アプリのビルド時に静的なファイルとして書き出すStatic Site Generation(SSG)と言う手法でその弱点を回避することができます。
静的なHTMLファイルとして書き出されるので、CDNにキャッシュを配置しておけるし、ページ遷移時にはSPAとして動的に変更ができるので非常に高速です。
少し前はReact製でSSGするならGatsby.js、と言う情勢でしたが、特に注目しているのがNext.jsです。
Next.jsはServer Side Renderingが主のフレームワークでしたが最近はSSGを推しているようで、Incremental Static Regeneration(ISR)が注目されていますね。
SSGの弱点がアプリのビルド時に全てのページを再出力する必要がある点でしたが、ISRでは設定した一定時間ごとにバックグラウンドでデータの再取得・HTMLの再生成が行われます。
こうすることでアプリ全体を都度再ビルドすることなく変更を反映させることができるのが利点です。
JAMとはJavaScript、API、Markupの頭文字で、JavaScriptで外部APIを叩いてMarkup(HTML)を構成することを意味しています。
主に静的サイトジェネレーター、ヘッドレスCMS、ホスティングサービスを使って構築されます。
ヘッドレスCMSで入力フォームを作成し、サービスで使うコンテンツをまとめ、APIとして公開します。
静的サイトジェネレーターでアプリをビルドする際にAPIを叩いてコンテンツを取得、HTMLなど静的コンテンツを生成します。
そして生成した静的コンテンツをホスティングサービスから配信します。
ほぼGitでマネジメントができるので開発効率も非常に良いですね。
ヘッドレスCMSはmicroCMS、Contentfulなどが有名どころで、microCMSは日本製と言うこともあり情報にリーチしやすく重宝しています。
静的サイトジェネレーターは上述の通り。Next.jsが個人的にはアツいです。
そしてホスティングサービスはNetlifyやFirebase Hostingなどがありますが、Next.jsを使うのであればVercel1択だと思っています。
Vercel社がNext.jsの開発母体と言うこともあり、VercelにNext.jsアプリを乗せればよしなにやってくれることが非常に多く、あえて他のホスティングサービスを利用する理由が見つかりません。
このブログは上述のSSG及びISRを取り入れ、Next.js×microCMS×VercelのJAMStackな技術スタックで開発されています。
開発体験もユーザー体験も上々だと感じているので、しばらくはNext.jsとVercelでWebアプリやWebサイトを開発していきたいなと思っています。
Progressive Web Application(PWA)はWebアプリケーションをiPhoneやAndroidのネイティブアプリのように提供できる技術で、Webとスマホアプリの両面を兼ね備えたようなアプリです。
AppStoreからのインストールも不要でホーム画面へのアイコン追加やプッシュ通知ができるなど、ネイティブアプリのような使用感を得ることができます。
常々注目はされている技術ではありますが、スマホユーザー側にそれほど認知されていないようで普及が進んでいません。
また、執筆時点でPWAに必要なService Workerと言う技術がSafariに対応しておらず、iPhoneがシェアを多く占める日本のスマホ市場では向かい風な状況なのかもしれません。
GraphQLはFacebookが開発しているWeb APIのための規格で、クエリとレスポンスデータの構造が似ていること、スキーマによる型付けができることが特徴です。
クライアント側はシンプルに書けること、そしてREST APIと違ってエンドポイントが1点となることから複数のAPIを叩いてデータを統合して...と言うことをしなくてよいのが利点だと考えています。
1回のリクエストで必要なデータのみ取得することが可能なのがREST APIでの構築との違いだと思います。
ただ、サーバー側のリゾルバーを書くのがクライアント側に比べると複雑で、N+1 SQL問題が発生しやすいと言うのが難点です。
リゾルバーを書くのをマネージドにするためにHasura GraphQL Engineが個人的には良いソリューションなのではと思っていて、PostgreSQLまたはMySQLのデータソースを元にGraphQLのリゾルバーを自動生成してくれるので、バックエンド側で複雑なことをしない限りは有用な選択肢だと考えています。
Hasuraは注目するだけしてまだアプリに落とし込めていないのでしっかりと運用してみたいと思います。
記事同様、VSCodeで十分すぎるパワーがあると思っています。
WebStormのようなJet Brains製品のような有料エディタも非常に有用なのですが、拡張性の高いエディタが無料で使え、有料のエディタと遜色ない点がVSCodeを使う理由です。
LiveShareの機能でオンラインペアプログラミングもできる優れものです。
フロントエンドのテスト、特にビジュアルは変更が多いため「テストなんて書いてもなぁ...」などと言われたこともありますが、開発中に予期せぬエラーを見つけやすくなったり、コードレベルでの機能の担保ができるのは大きな利点です。
(目視とExcelへのスクショを貼りまくったSIer時代を思い出す...)
テストを書かぬままのコード変更はリファクタリングではなくただの破壊的変更だ、と言うことも聞いたことがあります。
Storybookを使ったUIコンポーネントテスト、Jestでのユニットテストやスナップショットテスト、React-testing-libraryでの結合テスト、SeleniumでのE2Eテストなど、アプリ品質を確保するためにも使いこなせるようになりたいですね。
リーダブルコードを読みましょう。随分前の書物にはなってしまっていますが、「なぜクリーンなコードを書くべきか」概念は掴めるはずです。
エンジニアとして働くと、コードを書く時間よりも調べたり既存資産のコードを読む時間の方が長かったりします。
そして自分が書いたコードですら人間は愚かなので意図を忘れるのです。
変数名が省略されていたり一つの関数に複数の意味があるようなものを作らないなど、日々気をつけて開発したいですね。
複数人で開発する上でGitを使わない開発はほぼないと言えます。もちろん個人開発でもGitは必須です。
記事にないGitコマンドの中では最近amendやrebaseはよく使っています。コミットログの変更・修正になるので使い所は考える必要がありますが、コミットログと言うプロジェクトコードの歴史はきれいに管理していきたいですね。
上記の中でも最も必須スキルだと思います。
エンジニアはただパソコンを前にして一人で開発だけを進める仕事ではなく、複数人のチームで進めていくことが主になります。
特にリモートワークが普及しつつある昨今、オンラインでのコミュニケーションをいかにとることができるかは重要視されていると思います。
10つのスキル、2021年のフロントエンドエンジニアに求められるものとしてとても共感できるものでした。
付け加えるとしたらTypeScriptですかね？もはや当たり前だと言うことで元記事には挙げられていないのかもしれませんが。
PWAやGraphQLはまだまだ自分にとって知識不足だと思いましたし、フレームワークなどわかったつもりになっている技術もあると思います。
フロントエンドフレームワークは今年も引き続きNext.jsに注目していきたいなと思っています。
基礎を疎かにせずこれからも精進していきたいですね。
近年「フロントエンドエンジニアになりたい！」と言う声をSNSでよく聞きます。
「フロントエンドエンジニア」という肩書き・名乗りを聞いて、皆さんはどういったエンジニア像を思い浮かべるでしょうか。
巷で言う「フロントエンドエンジニア」は以下の2種類に大別されるので、誤った認識を持たないように注意が必要です。
フロントエンドエンジニアと言うくくりでも、話が噛み合わなかったり、そもそも主眼に置いている価値観が違ったりとで不幸を生むケースがあります。
Web制作者がフロントエンドエンジニアを求めている企業に応募したところ、企業はWeb開発者を求めていた...なんてミスマッチを生んでしまった例を聞いたことがあります。
フロントエンドエンジニアの肩書きの方がどちらの属性であるかを理解しておくと、無用な軋轢も減るのではないでしょうか。
今回は主にWeb初学者の方に向けて、両者の特徴を挙げてみます。
僕はWeb開発者寄りのフロントエンドエンジニアですが、この記事で申し上げたいことは「Web制作者とWeb開発者のどちらが優れているか」といった議論ではありません。あらかじめご認識おきください。
まずはWeb制作・クリエイター業務についてです。
Web制作者・クリエイターの業務は、以下のようなものが主となります。
企業・案件によってはデザイナーがデザインカンプまでを作成、HTML・CSSマークアップをフロントエンドエンジニアが担当するといった分業がなされます。
ただ、僕はWeb制作者に求められるのは上記の業務の中でも「Webデザイン」のスキルが重要視されると考えています。
JavaScriptやPHPによるプログラミングスキルよりも、デザインスキルやマークアップスキルの方が重視されると言えるでしょう。
(セマンティックにマークアップができることはWeb開発者にも求められることですが...)
エンドユーザーのUXを向上させ、クライアントのビジネスの成功に結びつけるためには相応のデザインスキル・優れたUI/UXへの理解がWeb制作者に求められます。
そしてWebシステムの開発を主に行うWeb開発者・ディベロッパーの業務について。
Web開発者・ディベロッパーの主な業務は以下のようになります。
範囲が広すぎて書き切れないですね。
BFF（Backend For Frontend）の構築とかもおそらくフロントエンドWeb開発者の担当領域だと思います。
Web制作者と比較するとプログラミングのスキル、アーキテクチャへの理解、パフォーマンス改善などがより求められると考えています。
近年はWeb制作に比べるとJavaScriptよりはTypeScriptで書くことが多く、jQueryは使わなくなってきている印象が強いです。
そしておおよそ組織内にデザイナーがいるので、制作者に求められるデザインスキルを開発者に求められることは比較的少ないです。
さらにシステム保守の観点から、疎結合で、堅牢で、保守性の高いコンポーネント設計を考えて設計・実装することも重要です。
フロントエンドエンジニアは、Webデザインスキルが重視されるWeb制作者とWebプログラミングスキルが重視されるWeb開発者に大別されるということを書きました。
フロントエンドエンジニアの担当範囲は本当に広いです。それゆえ同じ「フロントエンド」というワードの中で制作ベースの考えと開発ベースの考えで乖離が起きたりするケースがあります。
例えば「Web制作はプログラミングであるか否か」みたいな議論ですね。
個人的にはHTML/CSSはあくまでマークアップ言語で、動的処理を中心としたプログラミングとは別物、という考えです。
しかしながらWeb制作者でもJavaScriptによるプログラミングをするでしょうし、Web開発者でもデザインツールを使ってそれを元にコンポーネント設計などをするわけです。
両者の境界は非常に曖昧なものなので、明確に住み分けができるものではありません。
言ってしまえばただの言葉の定義の問題なので。
フロントエンドエンジニアを自称するものとして、制作と開発のどちらに軸足を置くか、そのスタンスは明確にしておきたいですね。
僕自身はWeb開発者としてアプリケーションを作ることを軸にし、時々Web制作もやるというスタンスでこれからも取り組んでいこうと思っています。
どっちもできるほうが面白いし仕事の幅も広がりますからね。
プログラミング未経験のあなたに。「プログラミング言語、どれを学べばいいの？」という疑問の解決にはJavaScript（JSと略されることもあります）を学習すると今後の選択肢が大きく広がる理由を解説します。
自分がフロントエンドエンジニアとしてJavaScript / TypeScriptを普段から書いているので「ポジショントークだ！」と思われる方もいるかもしれませんが、そんなことはありません。事実最初の一歩はJavaScriptを選択するのが最良だと実感しています。
JavaScript はウェブページにて複雑な機能をできるようにするプログラミング言語です —ウェブページが読み込まれるたびに、単にあなたが見ている静的な情報を表示する以上のことをしています— 更新されたコンテンツの定期表示や、インタラクティブな地図や、2D/3D グラフィックのアニメーションや、ビデオジュークボックスのスクロールなど — たぶん JavaScript が組み込まれています。
MDNより引用
JavaScriptはGoogle ChromeやSafariのようなWebブラウザ上で動かすことのできる（ほぼ）唯一のプログラミング言語です。
(HTML 、CSSはマークアップ言語という見解なのでここではプログラミング言語として取り扱いません。)
「ブラウザ上」で動くことから、サーバーを介すことなくHTMLやCSSを動的に操作することが可能です。
この特徴はRuby, Java, PHPなど他のサーバーサイド言語とは一線を画しています。
Javaというワードが出たので少し補足をすると、JavaとJavaScriptは全くの別物です！！メロンとメロンパン、ハムとハムスターくらい違うようなものです。JavaScriptを勉強したのに略して「Javaができます！」なんて宣言しようものなら全く見当違いなプロジェクトに入ってしまうことでしょう。
先述の通り、JavaScriptはブラウザ上で実行ができるプログラミング言語です。
Google Chromeの開発者ツール(キーボードのF12ボタンで開きます)のコンソールタブでも記述・操作が可能で、JavaScriptがどんなものかはすぐに体験することができます。
JavaScriptの主な用途としてHTML・CSSを操作するため、書いたプログラムによって操作されたHTML・CSSが目に見える形で変更されることが確認できます。
これはプログラミングの楽しさを知る上で重要なことだと思っています。結果が目に見えるのはやりがいを非常に感じやすいです。
ブラウザ上で動かすことのできる言語はJavaScriptのみであるという点が他言語との明確な違いになります。
かつてはPHPやRubyなどのサーバーサイド言語でHTMLを生成してSafariなどのブラウザで表示できる形態にして、ブラウザ側のJavaScriptで動きを少しつけてあげることが主流でした。
近年は、バックエンドとフロントエンドの境界線を引く潮流であり、バックエンドではデータを処理した上でフロントエンドに必要なデータを送り、フロントエンドで受け取ったデータに基づいたHTMLの組み立てを行うことが主流です。
2010年代のフロントエンド開発の技術革新の動きは目まぐるしく、React、VueなどのJSフレームワーク・ライブラリの躍進、Node Package ManagerのようなOSSライブラリ管理の発達、コードフォーマッティングやテストライブラリの拡充など、フロントエンド開発が効率的になり、かつ動きが大きくレスポンスも速いリッチな画面を作ることが容易になってきています。
これまではバックエンド言語を主に書くエンジニアが片手間にJavaScriptを書くことが多かったのですが、アプリケーションにリッチな画面を求めたいビジネスは年々増えており、フロントエンド専任のエンジニア(モダンフロントエンドエンジニア)の需要が右肩上がりになってきています。
面白いユーザー体験（UX）を作るためにはリッチなフロントエンド、つまりJavaScriptの活用が欠かせないことになってきています。
すなわちJavaScriptを確りと身に付けられれば需要増のモダンフロントエンドエンジニアの入り口に立つことが可能ということです。
プログラミング言語学習において、教材ではView部分もサーバーサイド言語で行っていることがありますが、ViewはReactやVueなどのJSフレームワークに任せてしまう時流になっているので注意が必要です。
JavaScriptがブラウザ上で動くことは前述しましたが、JavaScriptはNode.jsというサーバーサイドのJavaScript実行環境でも動かすことができます。
また、React NativeというiOS/Androidアプリを開発するためのフレームワークが存在し、JavaScriptを書くことができればスマートフォンアプリまで開発することができるのです。
つまり、バックエンドもフロントエンドも、スマホアプリでさえも全てJavaScriptで大筋作ることができるというわけです。
これはスタートアップなど人数のあまり多くないチームや個人開発で非常に有用です。言語間のスイッチングコスト(プログラムの書き方の作法の違い)がほぼ無いからです。
広く開発に使うことのできる言語ということで、将来性も抜群です。
Node.jsの伸び代はかなり有ると思っており、今後も注目しています。
Webアプリケーション開発においてJavaScriptは必須であることから、JavaScriptを使う開発者は非常に多いです。
PHPとJavaScript、RubyとJavaScriptなど併用して使っていたエンジニアも大勢います。
ユーザーが多いということはそれだけ知見が集まりやすいことに繋がります。初学者が困ったときに他のエンジニアに質問をした際に解決できる可能性も高いということです。
JavaScriptのユーザーコミュニティは活発であり、例えばQiitaの投稿数ランキングでも常にJavaScriptは上位にランクインしています。
また、JavaScriptのOSSライブラリも積極的に開発が進められています。
Node Package Managerを活用してライブラリを使うことができるため、自身が使いたい機能を探せばそれに見合うライブラリが存在することも多いです。
ライブラリの活用で車輪の再発明をする必要がないのです。（車輪のチューニングは必要だったりしますけどね）
一方、少し注意が必要なのはJavaScriptの言語改定のところです。
2015年にJavaScriptの構文に大きく変更がかかり、より安全で便利に、そして効率的にプログラムを書くことができるようになりました。
インターネット上では未だに非推奨となったvarを変数宣言に使うような記事もあったりするので、情報源が古くなっていないかは注意しましょう。
JavaScriptは「実行結果が見えやすいため学習モチベーションが高めやすく」、「フロントエンド開発の唯一の選択肢のため専門性も高く」、「バックエンドやスマホアプリ開発にも応用の効く汎用性の高い言語であり」、「開発ユーザーも多くて情報を得やすい」パワフルなプログラミング言語であることをご紹介しました。
新たなライブラリやフレームワークも次々開発されて活発であるため、将来性も高く進化し続けている言語であると言えるでしょう。
ぜひ最初の一歩にJavaScriptを選んでみてはいかがでしょうか。
JavaScriptから派生したTypeScriptの紹介は今回は留めておきます。昨今のデファクトスタンダードはTypeScriptなので、最初からTypeScriptを学ぶことも非常に有用な選択肢です。
ProgateのNode.jsコースは学ぶ順序としては理にかなっているなと思ったのでこちらも覗いてみてください。
https://prog-8.com/paths/node
明けましておめでとうございます。本年もどうぞよろしくお願いいたします。
新年を迎えるにあたり、2021年の目標を立てました！
目標だけは立派な状態になることなく、ちゃんと実績も伴う2021年にしたいと思います！
2020年初から新型コロナウイルスの流行により、世界中で普段通りの1年は過ごせなくなるような1年でしたね。
生活様式がガラリと変わったこの1年について、自分がどういうことをしていたか振り返ってみます。
2019年9月にフリーランスになったため、1年以上をフリーランスとして生き残る事ができました。
2020年はフリーランスエンジニアとして計4社のクライアント様とお付き合いさせていただきました。
業界、会社の規模の大小、扱う技術などそれぞれ違いを肌で感じることができ、1つの会社で勤め上げていては経験のできないような知見を幅広く得ることができました。
フルコミットだけでなく週3、週2で並行稼働をさせていただいたり、週5勤務の傍で1日数時間副業ベースでお仕事をさせていただいたり、時間の使い方や融通をどう利かせるか、非常に勉強になった1年でした。
体感としては週5フルコミットの方がスイッチングコストの少なさやお任せいただける案件の粒度(腰を据えて取り組めるかどうか)の面で優れているなと感じたので、2021年も方針は継続したいと思っています。
フリーランスになって初めてご契約させていただいた会社で、新聞のWeb版を更新・新規機能開発をするお仕事でした。
バックエンドのテンプレートエンジンに集中していたリソースを、責務の分離・開発サイクルの高速化を行うためVue/Nuxtを使ってのリプレースに取り組んだり、デザイナーさんと共同で既存ページのリニューアルをしていました。
コンテンツも非常に多かったので、数ヶ月スパンで各コンテンツにリニューアルをかけていくのは日々新たな発見があって楽しかったです。
4月からはコロナウイルスの影響で原則リモートワークとなりましたが、ある程度お仕事に慣れた状態でリモートワークに移る事ができたのはロスが少なくよかったことかなと思います。
技術的にもチャレンジングなことをしてみようという環境であったので、ご縁があればまた協働させていただきたいなと思っています。
地方創生BtoBコミュニティプラットフォームを開発するベンチャー企業様とのお仕事でした。
ベンチャーらしくスピード感があり、ベータ版から正式版へのリリースの間にデザイン、フロントエンドアーキテクチャのブラッシュアップに取り組ませていただきました。
案件内で素のReactからNuxtへの置き換え -> やっぱり既存資産を生かすためNextへ置き換えというシフトチェンジがありましたが笑 モダンフロントエンドの知見を広げる良いきっかけになりました。VueよりもReactの方がいいと思うようになったのもこの頃です。
フルコミットしたい私の意向と予算の都合で契約は満了となってしまいましたが、コロナ禍で地方創生を目指す機運は高まっていると思うので今後のご活躍が楽しみな企業様でした。
現在もお付き合いさせていただいている企業様で、オンライン教育事業を手がけています。
昔から僕が好きなコンテンツを提供されていた企業でもあり憧れの企業様と協働できることを嬉しく思っています。
現在はメディア周りのリファクタリングに取り組んでいるのですが、ただのWebページよりも難易度は非常に高く感じていて、JavaScriptの基礎を見直さなくてはと痛感しています。
プロパーのエンジニアの方々、参画されているエンジニアの方々のレベルも非常に高く、なんとか自分の実力が見合うようにと必死です。
父の事業のお手伝いとしてWeb制作及び保守をさせてもらっています。
ホームページのリニューアルと題して、技術について当初はNuxtで静的サイト生成&Netlifyにホスティングさせるように組んだのですが、ドメイン周りの変更に難があり、結果旧サイトで使っていたWordPressでのテーマ開発しなおし&デザインは発注することになりました。
デザインスキルも身に付けなくてはいけないなと...WordPressはちょこちょこキャッチアップしていければ良いかなと思っています。
HTML/CSS/JavaScriptは当然のものとして割愛。
フォーマットはpotato4d氏のこちらをまねさせていただきました。
業務と個人開発で使ったことのある技術を羅列しています。
羅列すると長いですね笑
2020年序盤はVue/Nuxtを中心に使っていましたが、Reactを知ってからはVueより圧倒的にReactの方が書きやすい、理解しやすい、TypeScriptフレンドリーという事がわかりReactを主軸にすることとしました。
Vueは確かにHTML,CSSが書けると書き味が良さそうに見えますが、templateに型補完が効かなかったりemitやv-modelなど双方向に影響を与え合うコンポーネントが書けるため修正の影響範囲が意外なところから発見されるパターンが起こりえて辛みも感じました。
2020年はNext.jsの盛り上がりが顕著で、2021年に個人開発をするならVercelでホスティングしつつNext.jsの恩恵に乗っかるのが間違いがないのかなと思いました。
また、業務でWeb Componentsを使う機会がありましたが、Shadow DOMの概念が難しかったり、開発手法はまだまだ確立されていない印象を受けました。
触っててかなり難易度が高かったなと記憶していますが、今後主流になるようなら確りとキャッチアップしたいです。
2021年はWebフロントエンドに留まらずReact Nativeでスマホアプリ開発に挑戦したりNode.jsを学習してバックエンドまで作れるようになりたいと考えています。
今年の3月に無事に娘が誕生しました！
スクスクと順調に大きくなってきていて、毎日かわいさが更新されていきますね。
それに伴い最近引越しをして、娘を育てやすい環境に移りました。リモートワークが中心になったので必ずしも交通の便がいいところに住む必要がなくなったのは一個人の話としてはコロナの不幸中の幸いかもしれません。
娘は「ママ」と喋れるようにはなりましたが「パパ」はもう少し時間がかかりそうです。
平均的な赤ちゃんよりも成長が速そうで、寝返りもお座りもハイハイも伝い歩きもすぐにできるようになっていました。天才かもしれません。親バカですねw
来年は手を繋いで公園でお散歩とかできるようになったらいいなぁと思っています。
今年はコロナ禍でFC東京のサッカー観戦にスタジアムまでは2月までの2試合しか行けなかったのが残念でした。(ACLの2試合なのでJリーグは見れてない)
年明けのルヴァンカップ決勝はなんとか見に行く事ができるので、コロナをもらってこないように気をつけつつ優勝に向かって闘うチームを見届けたいと思います。
4月頃にJリーグスタグル名鑑というWebアプリをリリースしました。
しかしながらコロナの影響で今年はスタジアムグルメの提供に制限があり、自分自身もスタジアムまで行けていないということもあり盛り上がりはほぼほぼ無い状態です。
アプリ開発にも時期や旬、時勢によって影響を受けるということを身をもって学びました。
その後もちょこちょこと趣味で開発を進めましたが、リリースには至っていないもの(リリースしたけどすぐ閉じたもの)ばかりなので、Webアプリで何かちゃんと運営できるものを開発したいですね、、何かちゃんと運用できるアプリを作りたいです。
また、このブログをNext.js×TypeScript×microCMSの技術スタックで開発しました。(執筆時点ではまだ未完成ですが)
Nuxtで作ったブログよりもパフォーマンスがかなり良くなっており、Next.js、Vercelはかなり伸びそうな実感を得ています。
このブログを作るにあたり00:00 Studioというサイトで毎日作業配信（ライブ駆動開発）をすることにしました。
人に見られることによって作業進捗へのモチベーションを維持しています。
習慣としてかなり良いと思うので、ブログの開発が終わっても続けていきたいですね。
参考）Qiita: 生放送駆動開発を1000日やったら進捗出たのでみんなもやろう！
フリーランスに転身してからサラリーマン時代より見た目上のお金は多く入るようになったので、投資を勉強して投資信託や米国高配当ETFを積立購入しています。
税金や投資などを知ると、これまでの浪費が本当にもったいなかった、社会人になってすぐ投資を始めておくべきだったと後悔するくらいでした。
特にふるさと納税はもっと早くやるべきでした。得しかしない制度ですね。
フリーランスにとって退職金は存在しないのでiDeCoや小規模企業共済などを使ってうまく節税・老後の資産形成をしなくてはと思っています。
楽天経済圏にどっぷり浸かることでポイントで生活費を支払い、支出を最適化してより自由に過ごせるように来年も頑張りたいと思います。
FC東京＆西武ファンですが5と0のつく日の前日は楽天・ヴィッセル神戸に勝ってもらってもいいかなと笑
2020年もあっという間に過ぎました。
仕事にもコロナの影響はありましたが、リモートワークを中心にしたことによってワークライフバランスはかなり向上したと思っています。
通勤ってストレスなんだなぁ...というのと自分が朝9時前にオフィスに着いて仕事を始められるような体にはできていないという事がよくわかりました笑
2021年も引き続きコロナの影響は残り続けそうですが、自分も家族も健康には気をつけて過ごしていきたいです。
いちエンジニアとしても来年はさらにスキルアップしていきたいです！
先日「フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと」という記事を読みました。
こちらの記事で挙げられている10個のポイントを踏まえて僕の考えを述べていきたいと思います。
近年React・Vue・Angularの三つ巴で推移していたJavaScriptフレームワーク・ライブラリですが、日本においてはReact・Vueの2強体勢になってきた印象を受けます。
Vueの方がタグテンプレート形式であるためHTML/CSSに慣れたWebクリエイターの方でも触りやすい、理解しやすいという利点からデザイナーがHTML/CSSを書くようなプロジェクトでは好まれて採用されるケースがあるようです。
一方でTypeScriptとの相性はReactに軍配が上がり、型安全でスケールしやすく開発効率が高いのはReactだと考えています。
個人的にはReactを推したいですが、2021年にから新たに学ぶのであればReact・Vueのどちらを採用しても有用であると言えます。
その他の選択肢としてSvelteも名前が上がるようになってきていますが市民権を得るにはもう少し時間がかかりそうですね。
JavaScriptフレームワークで開発されるSPAの弱点として初回ローディングの遅さやSEOの対策などが挙げられますが、アプリのビルド時に静的なファイルとして書き出すStatic Site Generation(SSG)と言う手法でその弱点を回避することができます。
静的なHTMLファイルとして書き出されるので、CDNにキャッシュを配置しておけるし、ページ遷移時にはSPAとして動的に変更ができるので非常に高速です。
少し前はReact製でSSGするならGatsby.js、と言う情勢でしたが、特に注目しているのがNext.jsです。
Next.jsはServer Side Renderingが主のフレームワークでしたが最近はSSGを推しているようで、Incremental Static Regeneration(ISR)が注目されていますね。
SSGの弱点がアプリのビルド時に全てのページを再出力する必要がある点でしたが、ISRでは設定した一定時間ごとにバックグラウンドでデータの再取得・HTMLの再生成が行われます。
こうすることでアプリ全体を都度再ビルドすることなく変更を反映させることができるのが利点です。
JAMとはJavaScript、API、Markupの頭文字で、JavaScriptで外部APIを叩いてMarkup(HTML)を構成することを意味しています。
主に静的サイトジェネレーター、ヘッドレスCMS、ホスティングサービスを使って構築されます。
ヘッドレスCMSで入力フォームを作成し、サービスで使うコンテンツをまとめ、APIとして公開します。
静的サイトジェネレーターでアプリをビルドする際にAPIを叩いてコンテンツを取得、HTMLなど静的コンテンツを生成します。
そして生成した静的コンテンツをホスティングサービスから配信します。
ほぼGitでマネジメントができるので開発効率も非常に良いですね。
ヘッドレスCMSはmicroCMS、Contentfulなどが有名どころで、microCMSは日本製と言うこともあり情報にリーチしやすく重宝しています。
静的サイトジェネレーターは上述の通り。Next.jsが個人的にはアツいです。
そしてホスティングサービスはNetlifyやFirebase Hostingなどがありますが、Next.jsを使うのであればVercel1択だと思っています。
Vercel社がNext.jsの開発母体と言うこともあり、VercelにNext.jsアプリを乗せればよしなにやってくれることが非常に多く、あえて他のホスティングサービスを利用する理由が見つかりません。
このブログは上述のSSG及びISRを取り入れ、Next.js×microCMS×VercelのJAMStackな技術スタックで開発されています。
開発体験もユーザー体験も上々だと感じているので、しばらくはNext.jsとVercelでWebアプリやWebサイトを開発していきたいなと思っています。
Progressive Web Application(PWA)はWebアプリケーションをiPhoneやAndroidのネイティブアプリのように提供できる技術で、Webとスマホアプリの両面を兼ね備えたようなアプリです。
AppStoreからのインストールも不要でホーム画面へのアイコン追加やプッシュ通知ができるなど、ネイティブアプリのような使用感を得ることができます。
常々注目はされている技術ではありますが、スマホユーザー側にそれほど認知されていないようで普及が進んでいません。
また、執筆時点でPWAに必要なService Workerと言う技術がSafariに対応しておらず、iPhoneがシェアを多く占める日本のスマホ市場では向かい風な状況なのかもしれません。
GraphQLはFacebookが開発しているWeb APIのための規格で、クエリとレスポンスデータの構造が似ていること、スキーマによる型付けができることが特徴です。
クライアント側はシンプルに書けること、そしてREST APIと違ってエンドポイントが1点となることから複数のAPIを叩いてデータを統合して...と言うことをしなくてよいのが利点だと考えています。
1回のリクエストで必要なデータのみ取得することが可能なのがREST APIでの構築との違いだと思います。
ただ、サーバー側のリゾルバーを書くのがクライアント側に比べると複雑で、N+1 SQL問題が発生しやすいと言うのが難点です。
リゾルバーを書くのをマネージドにするためにHasura GraphQL Engineが個人的には良いソリューションなのではと思っていて、PostgreSQLまたはMySQLのデータソースを元にGraphQLのリゾルバーを自動生成してくれるので、バックエンド側で複雑なことをしない限りは有用な選択肢だと考えています。
Hasuraは注目するだけしてまだアプリに落とし込めていないのでしっかりと運用してみたいと思います。
記事同様、VSCodeで十分すぎるパワーがあると思っています。
WebStormのようなJet Brains製品のような有料エディタも非常に有用なのですが、拡張性の高いエディタが無料で使え、有料のエディタと遜色ない点がVSCodeを使う理由です。
LiveShareの機能でオンラインペアプログラミングもできる優れものです。
フロントエンドのテスト、特にビジュアルは変更が多いため「テストなんて書いてもなぁ...」などと言われたこともありますが、開発中に予期せぬエラーを見つけやすくなったり、コードレベルでの機能の担保ができるのは大きな利点です。
(目視とExcelへのスクショを貼りまくったSIer時代を思い出す...)
テストを書かぬままのコード変更はリファクタリングではなくただの破壊的変更だ、と言うことも聞いたことがあります。
Storybookを使ったUIコンポーネントテスト、Jestでのユニットテストやスナップショットテスト、React-testing-libraryでの結合テスト、SeleniumでのE2Eテストなど、アプリ品質を確保するためにも使いこなせるようになりたいですね。
リーダブルコードを読みましょう。随分前の書物にはなってしまっていますが、「なぜクリーンなコードを書くべきか」概念は掴めるはずです。
エンジニアとして働くと、コードを書く時間よりも調べたり既存資産のコードを読む時間の方が長かったりします。
そして自分が書いたコードですら人間は愚かなので意図を忘れるのです。
変数名が省略されていたり一つの関数に複数の意味があるようなものを作らないなど、日々気をつけて開発したいですね。
複数人で開発する上でGitを使わない開発はほぼないと言えます。もちろん個人開発でもGitは必須です。
記事にないGitコマンドの中では最近amendやrebaseはよく使っています。コミットログの変更・修正になるので使い所は考える必要がありますが、コミットログと言うプロジェクトコードの歴史はきれいに管理していきたいですね。
上記の中でも最も必須スキルだと思います。
エンジニアはただパソコンを前にして一人で開発だけを進める仕事ではなく、複数人のチームで進めていくことが主になります。
特にリモートワークが普及しつつある昨今、オンラインでのコミュニケーションをいかにとることができるかは重要視されていると思います。
10つのスキル、2021年のフロントエンドエンジニアに求められるものとしてとても共感できるものでした。
付け加えるとしたらTypeScriptですかね？もはや当たり前だと言うことで元記事には挙げられていないのかもしれませんが。
PWAやGraphQLはまだまだ自分にとって知識不足だと思いましたし、フレームワークなどわかったつもりになっている技術もあると思います。
フロントエンドフレームワークは今年も引き続きNext.jsに注目していきたいなと思っています。
基礎を疎かにせずこれからも精進していきたいですね。