6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話

ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。

 

「ちょっと検証してみた」程度のものも含めれば、AWSGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。

 

Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。

 

だけど、実際にいくつかのマネージドサービス使ってアプリやバッチの開発・運用をやり、その後Kubernetesでも3つの基盤構築をやって、その上で複数のアプリやバッチの開発・運用までやってみて思ったのは、大抵のケースではKubernetesを基盤に使うのが結局一番コスパ良いんじゃないか、ってこと。

 

まずKubernetes(EKS、GKE等)以外のマネージドサービスを使うことの何がつらいのかを書いておきたい。むしろその愚痴を吐き捨てることをモチベーションに今これを書いている..。

 

AWSで言うと、LambdaとかECSとかBatchとかCloud Functionsとか、GCPだとApp EngineとかCloud Runとか他にも色々あるけど、こういうのは基本的に全部ダメだと思った。

 

たとえば運用するアプリケーションが1つだけ、あるいは複数あっても全部単一のマネージドサービス上で統一して管理できるんだったら良いと思う。例えばLambdaならLambda、App EngineならApp Engineといった具合に。

 

だけど現実には複数のアプリケーションがあり、それらの個々の要件に応じて複数のマネージドサービスを使い分け、連携させる必要があって、そうなると結局はつらいことになる。

 

何がつらいかというと、それぞれのマネージドサービス毎に開発環境、デプロイ方法、認証、認可、サービス連携、イベントトリガ、ロギング、環境変数やシークレットの管理等の諸々の仕様やオペレーションが当たり前だけどバラバラで、いちいち各マネージドサービス固有の仕様を理解して、それぞれのやり方で扱わないといけない。

 

それぞれ出来ること出来ないことがあり、向き不向きがあり、制約もある中で、ドキュメント読んで仕様理解して検証して、上述した諸々の要素を各マネージドサービス毎に詰めていくというのは結構なコストがかかる。

 

いざ運用フェーズに入った時に、各マネージドサービスを行き来する際の脳みその切り替えにも結構な負荷がかかる。エンハンスの際には、まず思い出すところからはじめないといけない。

 

LambdaにPythonのモジュール入れるのどうやるんだっけ?デプロイってどうしてたっけ?AppEngineってローカルでどうやってテストするんだっけ?とか諸々。一応ドキュメントに書き残してはいても、それを読み返してああそうだったわ、って思い出すのが億劫。

 

今の現場だとdevelop、testing、staging、productionと4つの環境を作ってメンテしないといけないんだけど、サービスが増えてくると必然的にインフラのコード化が必要になり、そうなるとさらにつらみが増してくる。

 

クラウドのプロビジョニングツールといえばTerraform、Terraform使えば楽勝でしょ、という浅い考えで割と初期の頃からインフラのコード化は手を付けてたけど、これが思った以上につらい。日に日につらみが増していく。

 

例えばAWS上で複数のマネージドサービスを組み合わせてサービスを構成する場合、AWSの各リソースを全て個別に定義し、さらにそれらをどう紐付けるかを不整合無く定義することで、個々のリソースで構成されたサービスをAWS上に展開出来る。

 

「全てのリソースを個別に定義して、それらの紐付けを不整合無く定義する」ってのが中々ダルくて、定義ファイルが無駄に膨らんでいくし、リソースやマネージドサービス毎に全然違う書式で定義しないといけない。

 

しかもTerraformの定義を適用(apply)するのにめっちゃ時間かかるから、トライアンドエラーが高速に回せなくて、些細な修正かけるのに色々いじくり回してたら一日が終わってた、みたいな虚しいことが起こる。

 

この辺は自分のTerraform力の低さの問題かもしれないけど、とりあえずKubernetes使っておけば前述してきた問題の多くをKubernetesが間に入って吸収してくれる。

 

そもそもこのご時世、コンテナをそのまま動かせないマネージドサービスはその時点でかなり微妙だと思うんだよね。いや、はっきり言って終わってると思う。

 

とはいえコンテナのマネージドな実行基盤として普及してるECSにしろAWS BatchにしろApp Engine(Flexible)にしろ、コンテナを動かすための前提条件や制約や独自仕様が多過ぎるし、期待してたCloud Runもメモリ2GB、タイムアウトが最大15分という制約があって、特定のワークロードでしか使えない。

 

そうなると結局はプロビジョニングの面倒臭さという問題にぶち当たる。

 

Kubernetesが他のマネージドサービスと決定的に違うのは、他のマネージドサービスが「クラウドOSSを隠蔽して楽に使えるようにしてくれるもの」であるのに対し、Kubernetesは「OSS(Kubernetes)がクラウドを隠蔽してくれるもの」であるという点。

 

Kubernetesクラウド(内の各種リソース)よりもメタにあるというのがめちゃくちゃ重要で、それによってクラウドベンダ間の差異やら、リソース間の紐付けやら依存関係やらの面倒をKubernetesがかなり吸収してくれる。

 

AWSの個々のリソースを作って紐付けるってのが面倒なわけだけど、KubernetesKubernetesリソースが媒介になってAWSのリソースを抽象化してくれるので、それだけで大分プロビジョニングの負担が軽減される。

 

クラウド上のインフラとアプリケーションを同等のリソースとしてyamlで定義して、構築、デプロイが出来る。例えばIngressリソースをyamlで定義してapplyすれば、自動でセキュリティグループ(ファイアーウォール)やALBを作成して紐付けてくれる。

 

そしてプロビジョニングもめっちゃ速い。Terraformのapplyなんて二度とやりたくなくなった。最近はKubernetesに出来ることは全てKubernetesに任せて、それ以外のことは手順化してマニュアルでやる、みたいな割り切りをするようになった。

 

環境変数や認証情報の設定や読み込みも超楽。

Kubernetes上に乗せるアプリは全部同じyamlの書式で定義して管理すれば良いので、アプリ間をまたぐ際の脳みそのスイッチングコストも最小限で済む。

 

kubectlコマンドのいくつかのパターンを覚えておけば、全てのアプリに対して同じコマンドで確認や操作が出来る。コンテナとの距離感が近くて、普通にローカルでDocker操作してるのとさして変わらない操作感。

 

あとはバッチにもAPIにもワークフローにも使えるし、大抵のワークロードに対応出来る。リソースも自由に確保出来る。

 

唯一、DBやデータストレージだけはマネージドサービスを使って連携させる必要があるけど、これらもそう遠くない先にKubernetesリソースによって抽象化されると思う。多くのユーザーが欲するものはいずれ実装される宿命にある。

 

とりあえず自分が言いたいことは、AWSはECSなんていう未来の無い独自仕様のコンテナ実行基盤なんかさっさと廃棄して、EKSに開発リソース全振りしろや、ってこと。普通にFargate for EKSのログをCloud Watchに連携出来ないの困るんですけど。

 

最近はクラウドネイティブなんていう考え方がもてはやされてるけど、CNCFはあんな回りくどい定義をしないで、もっと具体的に「クラウドネイティブとはKubernetesのことだ!!黙ってKubernetes使え!!」って宣言した方が良いんじゃないか。

 

近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している

久しぶりにペラペラな思いつきを書き捨てて、寝ます。

 

2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。

 

AWSのReadshiftしかり。

 

なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。

 

Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。

 

Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変ってのもあるし、そういうニーズからAthenaっていうS3をストレージとして使用するマネージドなDWHが出てきたけど、これもS3上に配置するファイルの管理は自前でやらなくちゃいけなくて、その辺りの運用コストはバカにならないってことがまだ中々理解されていない。

 

この辺り色々と楽にできるようにするためのサービスとか出てきてはいるけど、そもそもS3のストレージを外部テーブルとして使用する、というアプローチそのものに性能面での限界があると思っていて、分散クエリエンジン専用の大規模クラスタをバックエンドに抱えているBigQueryには今後も切迫できないと思うんだよね。

 

あ、後は日系のベンダーが4〜5人(推測)で開発したであろうHadoopディストリビューションという名のゴミを売り込んで導入したりとかマジで詐欺行為を目の辺りにしたこともある。

 

それに比べればTreasure DataもReadshiftも良心的と言えるけど、それはあくまでBigQueryが無い世界における話。

 

BigQueryが存在しているこの世界においては、DWHとしてBigQueryを採用しないことはそれ自体がアーキテクチャとしての欠陥であり、アーキテクトとしての責務の放棄である、と言ったらさすがに言い過ぎかもしれないが、そういう偏見を撒き散らした方が今よりもマシな世界になる気もするのでむしろ撒き散らしていきたい気分。

 

このアーキテクチャの一番根本の選択ってめちゃくちゃ大事で、ここの判断をミスると後から挽回不能ってぐらい大きな負債を抱え込むことが運命付けられる。

 

リボ払いのように日々金利の返済だけに追われてがんじがらめになっている現場を最近這い出てきたばかりの身としては、切実にそう思うわけです。

 

にも関わらずコンサルとかベンダーはこの一番根本のアーキテクチャ選定において、ユーザーが既存のインフラをAWSに置いてるからって安直にAWS上にデータ基盤を立てようとしがちだし、安易にSaasとか使いがち。ユーザー側もそれを求めがち。

 

それは裏を返せば「BigQueryを採用することは適切ではない」という極めて証明が難しい主張を押し通している訳であり、将来に大きなツケを回す可能性があることに無自覚であるという意味で、もはや大罪だと言えよう。

 

DWHにBigQueryを採用しないことは大罪である

 

という風潮にしていきたい。

そんなのはケースバイケースだとか、言い過ぎだとか言われたって、大体の場合BigQuery使っておいた方が良いんだから仕方無い。

 

データ分析基盤というのは運用にすごくコストも手間もかかる代物であり、通常のシステム以上にスケーラビリティが求められる。

 

本当の意味でフルマネージドであり、スケールするDWHはBigQueryのみであり、どうせ大して熟慮せずにアーキテクチャを決めるんだったらとりあえず無思考にBigQueryを使っておけば良いよ。もう眠いし。

 

そしてデータエンジニアの仕事の多くはBigQueryに今後奪われていくでしょう。すでにそうなってきてるし。でもやることはまだまだ大量にあるので、当面は大丈夫。たぶん。

 

そういうわけなのでおやすみなさい。

プログラミングスクールというボッタクリ情弱ビジネスについての所感

世間には「あこぎな商売」というのが結構あって、最近流行りのプログラミングスクールとかいうのはまさにその「あこぎな商売」の典型だろうと思う。昨今の流行りのワードを借りれば「情弱ビジネス」であり、はっきり言ってしまえばボッタクリである。

 

プログラミングスクールがボッタクリである理由は単純で、高額なプログラミングスクールなんかで配布される教材や講習内容なんかよりも圧倒的にクオリティが高くて実践的な教材がネット上には大量に溢れており、しかもそれらはほぼ無料で手に入るから。

 

例えば日本ではそれなりに名の通ってるIT企業が新卒向けに数千万(推定)のコストをかけて本気で制作し、実施しているエンジニア向けの研修内容や教材が、ネット上で普通に公開されている。しかも大量に。

 

研修資料まとめ.md · GitHub

 

莫大なコストをかけて雇った自社の新人向けの研修なわけだから、クオリティの低いものを作れば損失に直結するため本気で良質なものを作るインセンティブがあるし、現場投入後にちゃんと戦力になれるような、実務につながる基礎知識やスキルを厳選して教えられる。

 

しかもそれらをネット上に公開するということは自社のリクルーティングのための宣伝の一貫でもあるので、下手なものを公開して自社の評判を毀損しないよう、第一線のエンジニアに講習内容の策定や監修、実施に関与させている可能性が高く、それによって品質が担保されることになる。

 

一方でプログラミングスクールはどうか。

 

プログラミングを教えることで利益を得るというビジネスモデルであるということは、出来るだけ安く講習や教材を制作し、出来るだけ高く売ることで利益が最大化する構造になっている。これはもはや構造的な欠陥だと言える。それも致命的な。

 

例えば先に挙げた企業の研修レベルの講習内容や教材を提供しようと思えば、現場の第一線で活躍しているエンジニアを招集して教材の制作、スクールの運営に関与させる必要がある。開発の現場でプロジェクトの中核を担ってるようなエンジニアを、プログラミングスクールはどうやって集めるというのか? 現場に身を置く感覚から言えば、まあ無理だ。自社に教育すべき優秀な若手がたくさんいる中で、わざわざ外部のスクールで赤の他人にそんな労力を割くインセンティブが見当たらない。

 

GoogleMicrosoftのエンジニアとまでいかないまでも、日本のそれなりに開発力を売りにしている企業の、それもリードエンジニアクラスの単価の高いエンジニアを現場から呼び寄せて、講習をやらせたり、教材作成をさせるなんてことは、普通に考えて相当難しい。というかほぼ無理。

 

かくしてクラウドソーシング等に「プログラミングスクールの講師大募集!!」なる依頼が大量に溢れかえることになる。最近はどうか知らないが、登録だけして使っていない某クラウドソーシングの僕のアカウントにも、ある時期毎日のように前述したようなプログラミングスクール講師の依頼メールが送りつけられてきていた。

 

依頼内容は「教材の作成とマンツーマンでのレッスン」で時給2000円〜だとか。

時給2000円に飛びつくような、どこぞの誰か分からないようなエンジニアに教材を作らせ、マンツーマンレッスンさせて利ざやを稼ごうと企ててるわけ。

 

単価の低いエンジニアをかき集めて、1時間3000〜4000円ぐらいで素人に売りつけるようなビジネスモデル。それが今乱立しているプログラミングスクールの実態だと見ている。

 

そんなもんに高い金をぶち込むぐらいなら、最初の方に挙げた企業が無料で公開してる講習内容に沿って学習した方が圧倒的に効率良く、しかも実務で求められる知識やスキルが身に付けられる。

 

別に企業が公開する研修に限らないでも、無料の良質な教材は他にもたくさんある。

例えばデータサイエンスの世界で知らない人はいないAndrew NgっていうGoogle Brainの共同設立者であり、Baiduの元副社長兼主任科学者の人が設立したCourseraっていう世界的に有名なオンライン講座のプラットフォームがある。

 

Couseraではスタンフォード大学とかイエール大学とかの世界の一流大学や、GoogleとかIBMとかの一流企業が公開しているコンピュータサイエンスやらデータサイエンスやらの講習が基本無料で受けられる。

 

しかも講習によってはGCPと連携してて、無料でGCP上でインスタンス作って、サーバー立てたり、プログラム動かしたりする等の実践的なトレーニングが行えたりする。

 

全てが完全無料というわけではないけど、講習自体は無料で、認定証を発行してもらうのが有料だとか、一定期間を過ぎると有料になるとかなので、使い方次第では無料でいくらでも良質な講習が受けられる。

 

他にも、データサイエンスやデータエンジニアリングを学びたいなら、それこそKaggleでもやれば世界中のデータサイエンティストや機械学習エンジニアによって大量に公開されている分析コードやノウハウが無償で見放題だ。一銭も払う必要が無いどころか、万が一にも上位のスコアを出せれば賞金までもらえたりする。

 

というのがオープンソースという思想が根付いているコンピュータの世界の教育・学習における元来の世界観であって、むしろ高ければ高いほど質は下がり、最も質が高いものは無料であるという逆説的な側面があることを、エンジニア志望者には中々理解しずらいかもしれない。

 

世界の超一流の大学や企業やエンジニアによって無償で良質な教材やオンライン講習が提供されている中で、時給2000円の微妙なエンジニアが提供する数十万円のプログラミングスクールが乱立しているこのチグハグ感。

 

値段が高いのはそれだけの価値があるからだと思ってしまうのはただの錯覚であって、むしろ順番が逆。利益を上げるためには値段を高く設定しなくちゃいけなくて、値段を高く設定するためにはマンツーマンで教えるという立て付けにする必要がある、っていう発想で今のプログラミングスクールの形態と価格設定になってると考えた方が良い。

 

無限に複製可能な学習コンテンツでは高い値付けができないから、人件費という名目で単価を嵩上げしている。商売として成り立たせるために。ある種の人月商売。

 

というわけで、今自分がエンジニア志望の立場に逆戻りしたとしても、絶対にプログラミングスクールなんかには入らないし、今その立場にいる人にはそんなもんに課金しなくても無償でいくらでも良質な学習教材が入手できるんだってことは、一応言っておきたい。

 

とここまで書いて、じゃあ大学はどうなんだ?数百万するじゃないか?って話が出てきそうだけど、大学は大学を出たということがこの社会では結構な価値になるので、当然ケースバイケースではあるけど、まあその辺のプログラミングスクールと比較するようなもんではない。

 

そもそもエンジニアの実務の中では「必要な情報を無料で手早く入手すること」や「独学・自走」が求めらるので、プログラミングスクールに大金を払ってしまう人というのはそういう素養が無いんじゃないかと思い、もし自分が採用担当者ならプログラミングスクール出身者を名乗る人はあまり採用したくはないと思う。

 

なんで無料ですぐに入手出来るような情報を調査せずに、そんな金と時間を無駄に費やしてるんだ?的な印象を持ってしまう。

 

そういう意味でマイナスの実績にすらなり得ると思うので、個人的にはやはりボッタクリにしか見えない。

とあるデータ分析/データエンジニアリングの現場からの雑感

※基本、酩酊状態でクソみたいな与太話を思いついたまま書き捨ててるだけなのであまり真に受けないようにどうぞよろしく。

 

僕がここ最近ナリワイとしているのは、大企業でデータ利活用を推進している or しようとしている現場に潜り込んで、データ分析周りの諸々の課題を主に技術面で解決する、という役回り。

 

といっても、自分が主戦場としているのは技術志向の強い人達が好みそうなGoogleとかメルカリとかリクルートとかヤフーといった自社サービスのテック企業ではなく、普通のユーザー企業に対するIT支援、いわゆるシステムインテグレーションです。

 

ユーザー企業向けのIT支援の領域では、みなさんが嫌悪している大手SIerが今なお幅を利かせており、ユーザーサイドの生え抜きのエンジニアが技術面含めてプロジェクトを主導したり、メンバーの中に有名なOSSのコントリビューターがいたり、みたいなシチュエーションにはそうお目にかかる機会はない。

 

ただ、データの利活用支援という業務の性質上、必然的に先端技術の知見が求められやすくなることもあってか、SIerと言ってもそれなりに技術的素養を持ったメンバーが収集されている印象はある。

僕の今いる現場のチームでも、統計やら数理最適やらの研究室出のメンバー比率がかなり多い。

 

業務課題の特性上、このベンダーのこのパッケージやサービス使っておけばOKみたいな定型的なアプローチでは対応できないし、業務課題と技術の結合度が強いので、上流と下流で完全分業して、俺はマネジメントやるからA君は設計をやって、B君とC君は実装だけやってね、という古き悪しき分業体制は成り立ちにくい。

 

日々移り変わる要件やアドホックな要求に対し迅速に対応しないといけないので、アジャイルでやらざるを得ないというのもある。

 

だからある程度フラットな体制が組まれているように感じるけど、そうはいってもやはり上位SIのプロパーが主にマネジメントを主担当し、小会社やエージェント等からかき集められた協力会社のメンバーが開発を主に担当するという基本的な図式は明らかにある。

 

これは業界構造が抜本的に変わらない限りは温存され続けるし、他の領域と比較したら多少フラットではあるかな、という程度問題。

 

話を少し戻すと、同じチームにいる統計やら数理最適の研究室出の人たちが何をやってるかといえば、半分はマネジメント業務で、もう半分は普通のSE業務だったりする。

 

これは前にも書いたけど、一般企業におけるデータ分析やデータ利活用の現場において、いわゆるデータサイエンティストは必要無いというのが現場の実感としてある。

 

今の現場で圧倒的に必要なのは、データ分析についてある程度の知見を持ったコンサルやSEやエンジニアであり、それは今後も変わることは無いと思ってる。

 

現場で行われている分析の多くは、ドメイン知識に基づいて変数間の相関を見たり、集計結果を時系列で並べて推移を見たり、集計結果をレポーティングしたりといった、これまでも企業によっては普通にやられてきたような基本的な分析作業が大半であって、高度な統計解析やら機械学習やらの出番というのはものすごく限られている。

 

これはユーザーやベンダーのリテラシーの問題というよりは、そもそも多くの現場ではそのような高度な分析アプローチが適合するような課題がそこまで存在していない、というのが個人的な考えで、これは2年前ぐらいからずっと思っていることでもある。

 

以下の占い記事を書いたのも、その実感に依拠しているところがある。

 

今データサイエンティストを目指してる人の7割が5年後に年収350万にしかなれない - データエンジニアの酩酊日記

 

データ基盤やデータの整備がもう少し進めばそのような高度な分析アプローチの出番が多少増えるかもしれないけど、それ以上に日々の泥臭いシステム運用やらエンハンス開発やらデータ整備やらに追われてそちらの人員補強が優先される流れになることが目に浮かぶ。

 

それらを担うのはデータサイエンティストではなく、SEやエンジニアになる。

仮に名刺にはデータサイエンティストと書いてあったとしても。

 

サンプル数は少ないけど、僕がここ数年で経験したいくつかの現場でも、基本的にデータ分析はドメイン知識を持ったユーザー側が主体となって行い、ベンダー側はあくまでユーザーの分析補助や、分析要件を踏まえたデータ基盤の構築・運用を行う、というような役割分担になっていることが大半だった。

 

逆にユーザー側が主体とならないデータ分析プロジェクトが上手くいくことは想像しにくい。データもドメイン知識もユーザーが握っているわけだから。

 

そういうわけで、データ利活用プロジェクトに招集される要員の多くはエンジニアであり、データ分析のスペシャリストとしてのアサインはそれほど多くはない。データ分析要員としてアサインされた人員も、実際の作業は通常のSEとさして変わらず、データマートからSQLでデータ抽出してレポートを作成したり、お客さんへの報告資料を作ったりといった、いわゆるデータサイエンティストという職種から一般に想像される業務内容からは乖離している内容が多いと思われる。

 

後は、AIの導入検討の要員としての人員調達はそれなりに見聞きしたし、自分のところにも案件が結構流れてきた。いわゆるPoC案件。

 

だけど、これは実需というよりは、ブームを利用したITベンダの売り込みとユーザーのリテラシー不足による一時的な仮の需要なので、蜃気楼のごとくそのうち消える。というかもう消え始めてる?

 

たぶんPoCでデータ分析要員としてプロジェクトに入った人員の多くは、結局何も成果が得られず切られたか、前述のような基本的な集計とかSQLでのデータ抽出みたいな簡単な作業要員としてあてがわれてるか、データ整備したりデータ基盤作ったりとか全然別のことやってると思う。

 

別にデータ集計とかSQLとかの基本的な分析作業を腐しているわけではない。むしろそれらが今の現場で求められていることであり、ユーザーが抱えている目先の課題解決のために必要であるというだけの話。

 

逆にどれだけ高度な技術を持ち合わせていようが、ユーザーが抱えている業務課題の解消に適合しなければ使うべきではないし、無理に使おうとすればユーザーの信用を失って契約を切られることになる。カレーライスを欲してる客にフォアグラのソテーを出してるようなものだから。

 

それらを踏まえると、今日本政府がやろうとしてる「データサイエンティストの大量育成」が仮に成功したとしても、その大量に育成されたデータサイエンティストが現場で大量に必要とされる未来が訪れるイメージが、現場の実感として全く持てない。

 

多くの場合、クリティカルな分析を行うためにはドメイン知識が重要になり、ドメイン知識の習得には長い年数を要することが多い。外部の人間であるベンダー側が提供できる価値は、ドメイン知識を持ったユーザーが行う分析を技術的な側面で支援することにあると思う。

 

そうすると今後必要になるのもやはりエンジニアということになる。

分析の手札や効率は分析基盤によって規定される。ユーザーが見たいデータにいつでもダイレクトにアクセスしてすぐに分析できる環境を整備することが重要になる。

そのような環境を作るためには、いかに出来の良い分析基盤を構築、運用し、ユーザーの分析要件に応じて迅速に改善し続けられるかがキーになる。

 

今日本でそれが出来ている大企業はかなり限られているはず。その根本原因は、ユーザー企業が優秀なエンジニアを抱えることをせず、外部に丸投げしていることにあると思う。

そして大手SIerをてっぺんとした多重下請け構造によって非効率な開発がはびこっていることが、出来の良いデータ基盤をユーザー企業が整備することをさらに困難にしている。

 

日本の大企業がシステム小会社を作ってシステム開発を丸投げしたり、ITベンダが孫受け会社を作って多重下請け構造になるのも解雇規制が根本にあると思うので、今後も解決することはたぶん無い。

 

というわけで、今後もそういう泥臭い現場に入って、色んな制約の中で自分に出来ることをやっていくしかないんだな、ということを悟った。

 

フリーランスのエンジニアやるなら45歳までに貯金5000万円作れないと死ぬ説

フリーランスになることを煽ることで自身のポジションを築いてる人がネット上には一定数いて、それに触発されてかフリーランスに憧れる駆け出しエンジニアを結構見かけることがある。

 

フリーランスのリスク面について言及してるブログとかもあるけど、最大のリスクについてはあまり言及されているのを見たことが無い。

 

よく見かけるのが、「自分で営業しないといけない」とか「不況時に仕事がなくなる」とかあるけど、そういうのはあまり本筋では無いと思う。

 

営業については、すでにフリーランスでエンジニアやってる人なら分かると思うけど、その辺のフリーランスエージェントに登録すれば向こうから勝手にガンガン仕事を売り込んでくるのが昨今の市況。

 

年収1000万ぐらいなら自分で営業なんかせずにエージェントに丸投げするだけでも十分達成できるし、むしろ自分で営業かけて仕事取ってるフリーランスのエンジニアの方が少数派じゃないかな。

 

不況で仕事が無くなるってのも、ある程度市況の需給を観察して、恒常的に需要があり続けるであろうスキルセットにステ振りしておけば、そこまでの大怪我はしないと思う。

 

じゃあ何が最大のリスクなのかというと、個人的には「年齢による賞味期限切れ」だと思う。

 

基本的にフリーランスのエンジニアとしての賞味期限は45歳までと考えておいた方が良いと思ってる。

 

ここで言う"エンジニア"というのは、開発をメインでやるポジションのこと、つまりコードを書くことをメインの仕事とするポジションを指している。

 

PMOとかITコンサルとかの上流になるともうちょい賞味期限が伸びるけど、そもそもそういうのがやりたくないから正社員じゃなくてフリーランスやってるエンジニアも多いと思うので、あくまで開発者としてやり続けることを前提として話をする。

 

で、開発者としてやる場合、40歳以上になると需要は確実に減っていく。

 

これはフリーランス向けの案件情報とかを漁ってみれば分かるけど、募集要項に「40代まで」とか、「45歳まで」とあからさまに明記してある案件は多いし、明記してなくても40歳以降はあまり望まないというのが多くの現場での本音である。

 

それに加えて、40代になると家庭を持つ層が増え、生活コストが上がっていくことで、簡単には今の契約を切って現場を変えるという判断を下しにくくなる。

 

現場を変えるというのはそれなりに負担がかかるし、リスクもある。

家庭を持てば時間的なリソースも限られてくるので、新しい技術に飛び乗ってキャッチアップするってことを繰り返すのも中々しんどくなる。

 

つまり、開発者として価値の高いスキルセットをメンテし続けるってことの難易度が上がっていく。

 

という感じで、そもそも加齢それ自体によって需要が減ることに加えて、加齢に伴う生活状況の変化によって、開発者としての価値を維持し続けることのハードルが上がるという二重苦が待ち受けている。

 

他にも、モチベーションを維持できなくなるとか、メンタルがやられるとか、健康に支障をきたすとか、長期間続けていればそういうリスクが顕在化する確率も上がる。

 

って考えた時に、45歳で自身の賞味期限が完全に切れることを見込んで、予め生活設計をしておくべきなんじゃないかと考えるようになった。

 

そのための手立てはいくつかあると思うけど、そこまでにある程度稼ぎ切ってしまうというのが自分の結論。

 

5000万ぐらい資本を作れれば、仮に年利3%で回したとして年間150万の収入になる。

それに加えて年間150万稼ぐぐらいなら、最悪エンジニアの仕事じゃなくて清掃でも警備員でも何らかの手段で稼ぐことは可能だろうと思う。

 

配当150万 + 労働収入150万で、300万。

 

仮に45歳過ぎても難なくフリーでエンジニアを続けれたとしても、単価50万で仕事を請けて1年の内3ヶ月だけ稼働するというセミリタイア的な働き方をしても、年150万の収入にはなる。

 

まあそれなりに現実味はありそうだ。

 

年間300万の収入が確保できれば、自分一人と親をギリギリ養っていくことは出来る。

 

もし家庭を持ってしまうと300万では無理で、もうちょいバッファが必要で、労働収入だけで年収400万以上とか稼がないと厳しいと思う。

 

自分の場合は、そういうリスクを見込んで家庭は持たないと決めているし、生活コストを極限まで切り詰めて、全てを資産構築に投下している。

 

具体的には、iDeCo(個人型確定拠出年金)に毎月68000円、小規模企業共済に毎月7万、それ以外は預金と株式にほとんど突っ込んでる。

 

ちなみに今の自分の月額単価は100万ぐらいなので、契約が途切れなければ年間1200万程度の収入になるわけだけど、生活コストは年収250万の見習いプログラマー時代よりも低い。

 

外食で1食700円以上はめったに使わないし、飲み会も旅行も一切行かない。交友関係はほぼ無い。というか自然と途切れた。

 

幸か不幸か、30半ばになって女性への興味もかなり薄れたので、女性との出会いや交友にお金を使うことも無くなった。

 

服は1年に1回、ユニクロで5000円程度買うぐらい。

 

仕事以外はただの引きこもりみたいな生活をしてるので、運良く今ぐらいの収入と生活コストを維持できれば、45歳までには5000万ぐらいの金を用立てられる見込みではある。

 

それでようやく将来の生活の見通しが少し立つ。

 

フリーランスエンジニアを目指す諸氏には、交友関係をほぼ断ち切り、貧乏学生みたいな清貧生活で一人孤独に生きていかないと将来の生活が見通せないようなフリーランスエンジニアという身分に、一体どんな夢があるのかと問いたい。

 

あいにく自分の場合はそういう生活が大して苦ではないので今は続けられてるけど、一般的に見ればそんな生活、憧れる要素0だと思う。

 

フリーランスエンジニアになって年収1000万とかで頭のぼせてタワーマンションとかに引っ越して散財するようなやつは、自分的にはただの無計画なアホにしか思えない。(実際そんなやついるかは知らないけど)

 

まあ、今好きなように生きて、なるようになれば良いと考えてた方が、人間らしい営みを送れるとも思うので、むしろそっちの方が幸せなのかもしれない。

 

そういう意味で、家庭を持ってる人は本当に尊敬に値する。

 

自分にそんなリスクを取る度胸は無いし、下手に小賢しくなってしまったので、よほどの幸運が舞い込まない限りは、この先、人並みの人生を送るのは無理そうだ。

 

アフィカスなしで、本音でITフリーランス向けエージェントを比較する

GoogleのAIの知能レベルが未だに低いせいで、エージェント情報みたいな金の匂いがする分野でググってもアフィカスサイトばかりが出てきて、本当のところどうなん?っていう本音の情報が中々掴めなかったりする。

 

どれだけ客観的に書かれてるように見えても、アフィリエイトリンクが貼ってあって誘導してる時点で信用力は地の底に失墜し、その瞬間ページはそっ閉じすることにしてる。

 

いっそvorkersや転職会議みたいな口コミサイトのフリーランスエージェント版でも作ろうかとも思ったけど、そんな手間かけるならアフィカスぐらいやらなきゃ割に合わんなということになってミイラ取りがミイラになりそうだしなぁ...。

 

というわけで、ネット上には中々本音で語られたフリーランスエンジニア向けのエージェント比較情報が見つからないのが実情で、そういう記事書いたら結構価値あるんじゃないかと思い、書いてみることにした。

 

で、最近丁度フリーランス協会っていう非営利団体が発表したエージェントの業界俯瞰マップを見て、これは中々役に立つんじゃないかと思ったのでまずは以下に紹介したい。

出典:【プレスリリース】「フリーランス白書2019」フリーランスと会社員のワークエンゲージメントに大きな差 フリーランスマッチングサービスのカオスマップも初公開 | フリーランス協会ブログ

 

このマップをベースにして、僕の個人的なエージェントの利用体験と評価を書き綴っていきたい。

 

このマップの中で世間の比較サイトでよく名前が上がっているものとしては、レバテックとかgeechsとかPE-BANKとかMidworksとかその辺りなんじゃないかな。

 

自分も大体どれも登録してて、電話 or 対面で面談したこともあるし、案件情報も流してもらってるので、それぞれの特徴や良し悪しはある程度把握してる。

 

以下にそれぞれの個人的な利用経験に基づく評価を書いていく。

 

  • PE-BANK

ここは老舗のエージェントで、以前までは首都圏コンピュータ技術者協会組合という名前で組合組織として運営されていたみたいです。

成り立ちが組合からなのか、良くも悪くも営利企業の匂いが薄い。営業もあんまやる気が無いというか、売り込みかけてこない。

最近はいくつかマージン率を公表するエージェントが出てきたけど、その先駆けがPE-BANK。ちなみにマージンは8〜12%となっていて、契約の継続期間に伴って最大8%まで下がる報酬体系になっている。

これは業界水準としてはかなり安いと思う。公表してないので実際のとこは分からないけど、自分の感覚ではたぶん業界平均で15%〜20%ぐらいは取ってるイメージ。

PE-BANKの個人的な印象としては、特定の企業と蜜に関係を持っていて、1つの取引先に対して大量に人を紹介してるイメージ。

僕は大体◯クルートさんの案件を紹介される。毎回される。毎回断って、それで終わる。

 

  • レバテック

たぶん一番有名なんじゃないかな。エージェントのアフィリサイトでも必ず上位で紹介されてる。

で、確かに他のエージェントよりも色んな面で優れてると思う。

何が良いかというと、まず基本的にエンド案件がほとんどである点。しかも、事前にエンドユーザーが公開されている。これは他のエージェントではほとんど無い。

基本エンドの企業名は伏せられていて、こっちが強く聞き出そうとして初めてコソッと教えてくれる感じのエージェントが多い中で、最初から情報が開示されてる点は信用できる。

ちなみに自社サービス開発系の案件がメインで、これはちょっと..みたいな微妙な企業の案件とか、商流が深い案件はほとんど紹介されない。

あと、担当となる営業の人がちゃんとヒアリングした上で、的確な案件を提案してくる。

営業体制がしっかりしてるのか、仕組み化されていて、各営業間で情報共有がされているのだと思う。

希望の分野に強い専任の担当者一人が提案してくれるのが良い。他のエージェントだと、色んな営業から五月雨で案件情報が飛んでくることが多い。

ちなみに登録すると専用の会員サイトにログイン出来るんだけど、そこに自分に対しての提案案件が随時追加されていって、興味があれば応募する、って感じ。

毎回案件の切り替えタイミングで利用するものの、結局一度もレバテック経由で契約までは至っていない。これは僕がウェブ系の案件が好きではないという個人的志向によるものだと思う。

 

 

と、ここまで書いて力尽きた。

これ意外にも10社ぐらい割と詳しい情報を書けるエージェントあるんだけど、疲れたので一旦中断。

 

もし需要がありそうならこの続きを書くか、別記事としてボリュームアップ版を書こうと思う。

 

「機械学習の基礎知識とSQLの経験1年で月単価100万円」の案件が流れて来た

4月末で今の現場を離れることに決めたので、5月からの新しい参画先の案件をここ1ヶ月ぐらい色々探してて、直近のデータ分析周りの市況感というのを肌で感じたので、その辺りのメモ書き。

 

ブログ名の通り自分はデータエンジニアを勝手に自称しているわけで、機械学習やらAIやらはあくまで部分的に関わる程度であり、どちらかといえばそれらを活用するためのインフラ整備をするのが本業だったりする。(本業にしてからのキャリアは浅いことを一応付け加えておく)

 

なので、鼻からデータサイエンティストとしてのキャリアを積もうとは思っていないわけだけど、業務領域的には割と近い部分もあり、特に今はまだ境目がくっきりしていない現場も多かったりするので、データ基盤屋としての案件を色々探してたりしてると付随的にデータサイエンティスト寄りの市況感も知れたりする。

 

例えば、今取引してる企業の別の部署から「機械学習を活用して色々やりたい」という別案件の打診を受けたので詳しく話を聞いてみると、「それやりたいことはデータ分析基盤の整備じゃん」ってなったり。

 

でもお客さんの側では「機械学習が出来る人」が必要だと考えていて、機械学習と言えばデータサイエンティストを連想し、「データサイエンティスト求む」みたいなことになってる。

 

たぶんこれに近い話はそこかしこで発生していて、現場で抱えている課題と、その課題解決に必要な人材要件がズレてしまっている。

 

なぜこのズレが中々補正されないのかと言えば、コンサルやSIやらがそのお客さんの無知を当て込んだ商法を繰り広げてるからというのと、後はお客さんの側でも「データ活用推進 = 機械学習による新たな知見の導出」みたいな大義名分が無いと稟議に通らないという大人の事情も多分にあるんじゃないかと思う。

 

ベンダとしては、お客さんから「機械学習やりたいんだよね」って声かけられたのに、わざわざ「それ機械学習の前にデータ基盤整備すんのが先ですね」と正論で冷水浴びせてご機嫌損ねるよりも、「そうですね機械学習やりましょう」と飲み込んでしまった方が簡単に話が進むし大きな金も落ちるだろうことは、僕みたいな末端にいるエンジニアでも想像に難くない。

 

そういうわけで、上手く騙されたいお客さんと、楽にキャッシュを得たいベンダとの間の共犯関係により、世の中には課題へのアプローチとか人材要件とかが歪められて案件化されたものが多く排出され、その一部がフリーランスである我々のような川下に流れ着いて来る。

 

ちなみに僕はフリーランスといっても直接営業して仕事取ったりしてるわけではなく、そういう営業活動とか出来ないしやりたくもないので基本はある程度信用できるエージェント数社に希望だけ伝えて、後は各エージェントから流れてくる案件を仕訳してピックアップするだけ、というご気楽な方法で仕事を得ている。

 

そんな手抜きなやり口でもそれなりに単価の良い仕事が簡単に決まってしまうわけだから、今が空前のAIバブルなのか、恒常的な需要によるものなのかは、3〜5年後までには決着が着くと思う。

 

とはいえ、AIバブルは間もなく崩壊するだろうと思いつつ1年以上経過してみて今の状況を見ると、まだ崩壊してないどころかむしろ活況の様相を呈していて、意外にこの活況は長く続くんじゃないかと思ったり、いやそう思い出したこと自体がバブル崩壊の兆候かもしれないとか思ったり。

 

そんなこんなで、僕のところに複数のエージェントから「機械学習の基礎知識とSQLの経験1年で月単価80〜100万円」みたいなタイトルに書いた通りの案件が複数流れてきて、なるほど、これは来るとこまで来てしまってるかもな、と思った。

 

ちなみにTwitterでちょっと話題になってたから調べれば企業名は分かると思う。

ただその企業だけじゃなく、別の経路でも似たようなスキルレベルと単価の案件は流れてきた。

 

1年前ぐらいに案件調べた時は、低スキル向けの月単価50〜70万ぐらいの案件と、高スキル向けの月単価100万前後の案件とに二極化していた印象だったけど、まさかここに来て低スキル高単価の案件が出回ってくるとなると、いよいよ怪しくなってきたけど、どうなるのやら。

 

フリーランスの利点の一つとして自由に案件選んだり、短期間で案件変えたりできるという自由さがあるわけで、目先の単価と怖いもの見たさに釣られて試しにどんなもんか入ってみようかという誘惑にかられつつ、理性に全力で制止され、人柱になることは叶わなかった。