SIerの輪廻から解脱するための技術
モチベーション
最近「SIer界の輪廻からどうやって解脱したらいいですか？」
という話をちょくちょく耳にすることが増えた。
それに対する"解答"というわけではないのだけど、輪廻からの解脱を目指すにあたり、どんな要素技術を学ぶべきかについてはある程度指針を示せると思ったので今回は、選ぶべき技術と、その理由について解説していきます。
SIer界で輪廻転生を繰り返したい人はジャバ言語のラムダ式を禁止にすべきか議論するほうが大事だと思うので、こんな記事にクソリプする前にさっさと帰って、どうぞ。
TypeScript
解脱への第一歩は、なにはともあれTypeScriptだろう。
正直、この言語だけ覚えておけば、FaaS(Lambda, Cloud Functions)も書けるし、ReactによるSPAとか、なんならReact Nativeでアプリも書けるし、モダンな開発環境に必要なスキルセットがすべてまかなえてしまう。
もうちょっというと、エコシステムとしてのnode.jsを中心としたnpm文化圏に慣れ親しんでおくことが大事で、ライブラリの見つけ方だとか、公式ドキュメントの読み方だとかがスラスラできると
「おっ、こいつわかってんな」
感が出るので錯覚資産的にもおすすめである。
まぁ最近はyarnとかnpxとか使うんで、npm文化圏とかいうと語弊があるかもしれないが、その道のプロの人はお察しください。
TypeScriptを、雑に言えば「型付きJavaScript」と思っておけばOK。
OSを問わずにどんなプラットフォームでも動かせるし、環境設定も簡単なほうだ。ちなみにおすすめはanyenv+nodenvな。
個人的にはimport文の書き方が多彩すぎてクセがあるが、慣れの問題って感じなのでそのうちなんとかなる。
フロントエンドの絡んだモダンな現場では100%登場するといっても過言ではないので、迷ってるならまずはここから手を付けるべきなのは間違いない。
React+hooks
TypeScriptを使ってWebサービスを書こうと思ったらまず候補にあげたいのはReactだ。
正直、以前のReact+Reduxは冗長すぎて開発体験が非常に苦痛に満ちたものだったのだが、React hooksの登場により、完全にゲームが変わったと思う。
そして何よりDeclarative UI（宣言的UI）の老舗と言える存在だけあって、すばらしい開発体験を提供してくれる。
とにかくイライラさせられたコードの分散がReact.FCにまとまるようになって非常に見通しが良くなった。何より書いてて楽しいし、悩まない。
エンジニア個人としても、Hot Reloadが存在するので、そこそこ熟練するだけで、圧倒的な生産性を叩き出せる、すばらしいフレームワークといえる。
SPAを書く環境としても、Firebase/Amplifyという面倒見の良いmBaaSエコシステムも対応してるし、さっさとリリースしたいスタートアップや個人開発にはうってつけの処理系といえる。
なによりフルマネで構成したSPAというのは、お財布に優しいのだ。
一日で10PVしかないのに24時間インスタンス上げっぱなしとか、心折れるんですよ。人間だもの。
React界隈は進化が激しいせいで、ちょっと古い記事でもまるで役に立たないという問題も発生しがちだが（公式さえ古かったりする）まぁそこはググり力とか現役のReactメンターを捕獲するなりしてがんばろう。
なお、ケツモチはFacebookなので、将来性についても急にはしごを外される可能性が低そう、という安心感もある。
トピック：Declarative UI(宣言的UI)による設計パラダイムの変革
UIを手続き的に記述し、ステートを内包するような設計は、人類にはあまりに難しすぎるということで、宣言的UIが人類の救世主として台頭したことで、UI実装手法の勝負には決着がついたのが2020年現在。
宣言的UIの登場で、開発者が最も恩恵を受ける本質的な部分は
「ステートがわかればViewが決まる」
という点。
これが達成されたことにより、開発体験において最強のインパクトがある
「Hot Reload」
が可能になった。
簡単にいうと、コードや内的状態を変更するとリアルタイムに実行中のアプリケーションに反映されるということ。
これによる開発体験の向上は、生産能力にものすごいインパクトを与えたためチームの働き方や開発手法そのものにまで影響を及ぼすようになってしまった。
宣言的UIについて気になる方は下記の そな太さんのスライド が非常によくまとまっているので是非ご覧いただきたい。Flutter
Flutter
まぁいろいろ考えても、ネイティブアプリケーションを作ろうと新しく学ぼうというなら2020年現在、最強のクロスプラットフォームエコシステム（あえて環境と呼ばない）を提供してるのはFlutterだろう。
なにより毎秒ライブラリが追加されて毎週Flutter本体も便利になっていくという、実にホットな状況が続いている。
まぁ、flutter channel devとかで突っ走ってるとたまに「最新バージョンに追いついてないライブラリ事故」に巻き込まれるが、笑って許そう。
なんとなればFlutter Webを使ってWebアプリケーションまで書けてしまうし、HTMLやCSSの高度な（そして無駄な）テクニックを一切知らなくてもWebアプリケーションが書ける時代が到来した、というまさに時代の象徴である。
ケツモチとしてGoogleがいるせいで、Firebaseとの相性がやたら良いし、なによりプラットフォームとしての安心感は半端ない。
逆にいうと現時点ではAWSとの相性がちょっと微妙なところがあり、株式会社目黒ウェブサービス様におかれましてはさっさとAmplifyのライブラリを正式リリースしてほしいと思ってる今日この頃、いかがお過ごしでしょうか？
React Native
Flutterより先んじてxPlatを手掛けていたのもあるが、もとよりWebと親和性の高かったReact勢にとってはとっつきやすかったこともあり、Flutterと人気を二分するxPlat(クロスプラットフォーム）フレームワークがReact Nativeだ。
ただし、Flutterほどエコシステム全体が親切ではないし、なによりexpoはマジでツンデレなので、このメンヘラexpoちゃんと心中する覚悟が問われる。
あなたがすでにReactの免許皆伝ならばReact Nativeは悪くない選択肢だが、まっさらの状態からやるのであればFlutterをおすすめする。
とはいえ、どっちも触ったことある人ならわかると思うが、実のところモノリシックWebフレームワーク文化圏から比較すると、React NativeとFlutterが「ほとんど双子」のように見えるほどに文化的にも書き味も同系統といえる。
まぁ正直好きな方やればいいと思うし、ましてやMaterial-UI使ってると、記憶が混濁するレベルで、似たような事をやってる感じになる。
トピック：結局どっかでNativeレイヤーを触るんですよ
React NativeやFlutterによって各ネイティブ言語を触る機会はめっぽう減ったが、SwiftとKotlinは、文法ぐらいは読めるようになっておいたほうがいい。
各ネイティブにおけるUI実装の手法は正直、もう知らなくていいと思ってるが(ViewControllerとかActivityとかFragmentとか)、ハードウェアや各OS固有のワークアラウンドについてはある程度理解がないと、xPlat側だけで解決できないときに、どん詰まりしてしまう。
React NativeやFlutterのライブラリは結局Swift/Kotlinのライブラリを呼び出していたりするので、ライブラリに問題がある場合などの解析にはどうやってもネイティブ言語がスラスラ読める（書ける必要はない）程度の素養は必要になるのだ。
UIKitはどうてもいいがSwiftは読めないとあかん、ということである。
Firebase
「Firebase」はGoogleが紆余曲折の末生み出した、革命的なmBaaS/BaaSである。
本家Google Cloud Platform(GCP)をモバイル向けにリブランディングした仕立てになってるので、ちょっと関係性がわかりにくいかもしれない。まぁ親戚みたいなものだと思っておけばOK。
輪廻解脱においてフォーカスすべきサービスは「Firestore」これにつきる。
データ設計手法やセキュリティの確保についてはノウハウを必要とする部分ではあるが、学習コストに見合うとんでもない生産性インパクトがあるので、もはや必修技術といえる。
もはやKVSとかNoSQLという枠を超越していて、正直「Firestoreというジャンル」でしか語りようがない立ち位置になりつつある。
そしてFirestoreだけでは要件に対応できないときに現れるのがCloud Functionsだ。いわばFirestoreの影の存在ともいえる。FaaSのようにも振る舞えるし、SQLでいうところのストアドプロシージャとしても振る舞う事ができる。（若干制約もあるが）よくあるバッチ処理にも使用可能だ。
あなたが遭遇するであろうソリューションの98%ぐらいの課題は、Firebase単体で解決できてしまうだろう。
Amplify
「AWS使ったことある」はよく聞く単語だが「EC2にサーバを手動で立てた」の意味だったりするので、もはやなんの意味もないセンテンスだとみなすようになって久しい。曰く「あなたのAWSはどこから？」。
閑話休題。
「Amplify」は、Firebaseに遅れること数年、やっとAmazonが手を付けたmBaaSだ。
AWS全体となるとあまりに機能が多すぎて、SAの中の人(AWSの技術的御用聞き)さえ「えっなんすかその機能？うちにあったっけ...」みたいなことが発生する笑えない状況の中、とりあえずAmplifyのコマンドを叩くとAWSのサービスの中をいい感じに設定してくれるという、いうなれば敏腕秘書とかなんでも屋さんという感じ。
「AmplifyとAWS」は、FirebaseとGCPの関係に似ていて、AWSにおける定型的な設定やデプロイを肩代わりしてくれる、プラットフォーム支援の仕組み、といえるだろう。（特にAWSは権限周りがめんどくさい）
Amplifyにおける中核技術はAppSyncで、雑に言うと「データの読み書きを全部面倒みてくれるゲートウェイ」で、DynamoDBという古き良きNoSQLとの入出力とか、API GatewayからFaaS叩いたり、最近じゃRDBMSまで使えると豪語している。
それらすべてをGraphQLでやりとりするので、19世紀に流行ったHTTP RESTみたいな石器時代のサーバサイドインタフェースにフロント側が付き合わずに済むというのが最大のメリットといえる。
ただ、AmplifyはあくまでAWSのサービス構築を肩代わりしてくれるだけで、やはりAWS特有の問題にハマったりする。なので、結局はDynamoDB, Cognito, API Gateway, WAF, Lambda, Amazon SNSあたりには習熟が必要である。
まぁ困ってから深堀りすればよくなっただけ、導入のハードルは下がったと言えるだろう。
トピック：バックエンド不要論
いまだにmBaaSによってバックエンドが不要になったと主張する人がいるが、残念ながら筋違いと言わざる得ない。
実際のところ「バックエンドだけ考える人」は不要になったかもしれないが、「フロントエンドだけ考える人」も同じく不要になったというのが正解だろう。
必要な人材が「アプリケーションを書ける人」に集約されるようになったのがmBaaSがもたらした世界観というべきかもしれない。
シェル
仕事柄エンジニア教育をしているのだが、明らかに理解の妨げになっているのが「シェル」に対する無理解/不慣れという事が最近わかってきた。
SI界隈にいると支給されるマシンがWindowsなので、みんなが触る共用の開発サーバ上でおっかなびっくり触るのが関の山、おかげでほとんど習熟することがないようだ。
シェルというのは、本来コマンドをパカパカと刹那的に叩くものではなく、ストリーム処理の基本を学ぶ上で非常に重要なプラットフォームなのだ。
LPICに出てくるコマンドをいい感じにつなげるだけで、大抵の業務で必要なデータ処理は完遂できてしまう。
それ自身がプログラミング環境であり、IDEであるとも言える。
シェルのワンライナーで処理をする人を芸人呼ばわりする風潮があるが、コンピュータの本来の使い方はそっちのほうが王道なのである。ブラウザとかGUIでゴニョゴニョしようとするのは、素人でもなんとかデータ処理が行えるようにした苦肉の策にすぎない。
特に、HTML+CSSみたいなまるでアプリケーション向きでないフォーマットを使って、コンピュータによるデータ処理をなんとか素人にもやらせようとするほうがよっぽど変態的だということは認識しておいたほうがいい。
閑話休題。
シェルというのは、何をどうやってもコンピュータと付き合っていく上で、今のところ必須技術といえる。
シェルにそれなりに慣れていないと、現場で「えっviも使えないんすか」みたいな顔で見られるし、ファイルから文字列探すのさえ変なGUIツール頼りのダサい人間扱いされ、CI/CDなんかはシェルの知識がないとトラブったときには手も足もでなくなる。
とにかくシェル(bash/zsh)に慣れ親しむ事から逃げてはいけない。
それはじわじわと、あなたのコンピュータ人生を不幸にする。
まとめ
React+Amplifyでなんかつくって
Flutter+Firebaseでなんかつくって
たまにシェルでワンライナー書いて遊んでればいいと思います
それができなきゃ来世でがんばってね！
Follow Me!
この記事が気に入ったらサポートをしてみませんか？