駑馬十駕
ポエム

これはポエム。独断と偏見まみれ。

なぜ?

エンジニアが足りないから。あとシステムというのは作って終わりではないということ。後者についてはまだ別の機会に書ければと思う。

まあ、まずこれに尽きる。プログラミングスクールの勃興やフリーランス志向、コロナの影響によるリモートワークの促進などでエンジニアという職業にスポットライトが当たる機会が増えエンジニアを志す人は加速度的に増えているという印象。別に何かデータがあるわけではないし、自分自身いわゆる駆け出しエンジニアと呼ばれる人に出会ったことがないので正確なことは言えないけど、Twitterで流れている情報をみると増えていると断定して良いと思う。ただ残念ながら欲しいのはジュニアレベルのエンジニアではなく、要件を自分で理解して自走して実装できる人。いわゆるシニア層のエンジニアは依然として人材不足だ。

さて、話は打って変わってソフトウェア開発は10年前とはおそらくまるで違った風景に変わっているのではないだろうか?様々な世界中の高品質なサービスがスマートフォンやタブレット、PCを通じて人々のインフラと為している。おおよそ全ての領域においてビッグカンパニーが提供する便利で高品質なサービスでカバーされている今、質が低くてもいいから早く市場に出せ!と言う概念は文字通りには受け取れなくなってきているのではないだろうか。最初から高品質なサービスをリリースしないと顧客は見向きもしてくれないし、バグや使いにくさがあろうものならすぐに代替サービスに乗り換えられてしまう。どの領域もレッドオーシャンである以上同じ領域で挑むならかなりのクオリティのサービスを出すしかないし、空いている領域で特化したソフトウェアを開発しようとすると高度なドメイン知識を持った上でソフトウェア開発に挑まなければならず、これはそうそう簡単なことではない。

ここまでダラダラ書いてしまったが、つまるところ

ビジネスサイドが求めるソフトウェアのクオリティは上がり続けている上にどれも専門知識が必要になってきている

これに尽きる。BtoB SaaSであればなおさらそう。一昔前であればレンタルサーバの上でRailsと言う単一の技術で作れば良かったのかもしれない。しかし快適なUIインタラクションや日に数百GB単位で増えるデータ、秒間数万アクセスのトラフィックが珍しく無くなった今、そのような構成では太刀打ちできなくなってしまった。

ブラウザ上で稼働するJavaScriptのプログラムを構築するエンジニアはフロントエンドエンジニアと呼ばれ、最近ではFrontend DevOpsやUXエンジニアなどフロントだけでも数種類のエンジニアが存在する。フロントエンドの技術の移り変わりは目まぐるしく、キャッチアップするだけでも一苦労だが、どれも前の技術的課題を解決しているもので良いサービスを安定的に供給してくためには避けては通れない。

サーバ上で稼働するプログラムを構築するエンジニアはバックエンドエンジニアと呼ばれ、ブラウザやモバイルアプリ、デスクトップアプリなど様々な媒体から要求されるデータを正確に99.9%以上の確率で正確に数ミリSec以内に返すことが求められる。ソフトウェアが解決する課題が複雑化している以上、プログラムをコードに書き起こす難易度も比例して上がる。もちろんこちらもフロントと同じく一昔前と比べて選択できる言語やツールのバリエーションは豊かになった。もちろんそれぞれの言語・ツールには特性があり、何を選択するかで生産性は変わるし、ひとつ選択を間違えると後に大きな代償を支払うことになる。ソフトウェアが提供したい質や開発スピード、チームメンバーとの相性を見極めた上で慎重に選ぶ必要がある。もちろんこれはフロントエンド開発にも言えることだと思う。

さて、ブラウザで稼働するプログラムもサーバ上で稼働するプログラムも肝心のサーバがないと動かない。そのサーバを構築して運用するのがインフラエンジニアと呼ばれる職種の方々だ。AWSやGCB、Azureといったクラウドインフラが全盛の今、バックエンドエンジニアが手を伸ばして担当することも珍しく無くなったけど、ソフトウェアの規模が大きくなってくるにつれ専門知識を持った人がチーム単位でいないと継続的に安定して運用することは難しくなる。ここで出てくるのがいわゆるSRE(Site Reliability Engineer)と呼ばれるエンジニアだ。サービスを安定稼働させる上で必要なデータを取得するための基盤を構築したり脆弱性のチェックなどソフトウェアを安定的に稼働させると言う責務を担う。各社自分達のソフトウェアを安定して供給するためSREチームを結成することは当たり前になった。

では上記のエンジニアを集めれば開発は万事うまくいくのだろうか?もちろん少数精鋭で開発が進むケースも珍しくないけど、大規模なアプリケーションはどうしたってチーム開発になる。そうなるとチームのマネジメントできる人間が必要そうだね?いわゆるEM(Engineer Manager)ってやつだ。一昔前はウォーターフォール開発っていう一度決めたら滝の流れの如く上から順にきっちり開発していくスタイルが主流だったけど、毎日ユーザヒアリングを重ねて欲しかった機能の仕様や優先度が毎日変わる現代の開発には合わなくなってしまった。そこでアジャイル開発と言う手法が編み出された。しかしアジャイル開発は運用するにはそれなりに技術と経験が要求されるもので、人を雇ったからといって解決されるものではない。最近はスクラムマスターと呼ばれる職種の方が各企業のエンジニアチームに入ってアジャイル開発の指揮を取っていることも珍しくない。指揮者がいないと簡単にチームは空中分解してしまうからね。

さらにドメイン知識が要求されるサービスであればビジネスサイドが持つ知識や本当に欲しい機能をうまく聞き出して技術難易度を把握した上でスケジュールを引ける人間だって必要だ。多くの会社ではこの役割をPMがになっているんじゃないかな?重要なのは技術がある程度わかっていること。一見ボタンをひとつ追加するだけの簡単な機能追加に見えても裏側のシステムを1年かけて全て刷新しないといけないようなことだってある。そこら辺の事情を理解できていないまま簡単にホイホイ機能追加の仕事をエンジニアにアサインしてしまうとエンジニアチームからは不満が噴出してデスマーチへの第一歩を踏み出すことになる…。まあ、技術のわかるPMなんてそうそういないのも現実なんだけどね。

ああ、そういえばエンジニアリングを以って経営に携わる人が必要だった。そういったポジションの人がいないとビジネスサイドの人間の意見だけで開発の意思決定が行われてしまう。これの何が悪いのかって?それの最悪の最終系がみずほ銀行だよ笑。ま、CTOってやつだ。

最近だと動作テストを専門に行うQAエンジニアという職種の方もいるね。BtoB SaaSであればバグを見つけたり期待通りにソフトウェアが動いているかを確認するための守護神として絶対に確保したいエンジニアだ。

さて、ここまで書いた内容をまとめた上で開発に必要な人種をリストアップしてみよう。

フロントエンドエンジニア

バックエンドエンジニア

インフラエンジニア(SRE)

QAエンジニア

PM

EM

CTO

これだけの人種が必要なんだ。しかも当然各ポジション1人じゃないよ?

そういえば技術顧問が抜けているね…笑。自分の感覚だと

フロントエンドエンジニア 3名

バックエンドエンジニア 3名

インフラエンジニア(SRE) 2名

QAエンジニア 1名

PM/EM 1名

CTO 1名

合計11名か。おおよそ平均クラスのエンジニアの年収が肌感覚で500~600万だから年間の人件費は5500~6600万かな。もちろんこれはエンジニアチームだけだ。実際にシステムを開発するためにはデザイナーが必要だし、エンジニアを採用するための人事だって必要だろう。採用ツールを使うことだってあると思う。それらも加味するとあれよあれとと言う間に1億くらいいってしまいそうだね。しかもエンジニア採用が加熱して各社がお金という金の弾丸で殴り合っている今そう簡単に歴のあるエンジニアを採用することはできない。しかもエンジニアというのは流動性の高い職種で自分に合わなかったり待遇や環境面で不満があると簡単に転職されてしまう。特にビジネス色が強い会社だとCTOがよほどエンジニア組織をコントロールできていないといけない。

これだけ集めても予定通りのスケジュールで開発が進まないことだってザラだし、そもそもこれだけのエンジニアを自社で採用するのは本当に難しいと思う。別にこの記事では僕の感覚を列挙するだけのものでこの現実に対して何か解決策を提示するわけではない。ほんと、難しいよね…。幸い僕はエンジニアなので対して実力派ないけどバグありまくりでよければ初期のプロトタイプを自力で作るくらいの実力はきっとあるはずなので自分でなんとかするかな。もちろん開発スピードは遅いけど。何を使って開発するかって?もちろんRailsだよ。

それじゃ。