ぐーちょきぱーでなにつくろう。なにつくろう。

いきなりアホなタイトル記事ですいません。

ちょっと一緒にお仕事させていただいている会社様の方から、「Lambdaってどうよ?」というとってもざっくりとしたご質問をいただいたりして、改めて。

AWS Summitなんかに行っていると、世の中すっかりServerless。みたいな気分になりますが、さすがにいくら何でもそれはないわけで、現実においてはまだまだphpだって元気ですし、Web系をメインにされているところではLambdaなんかめったに触りませんよ、なんてのも少なくはないでしょう。

まあ、フロントS3においてバックエンドをAPI Gateway+Lambdaで。みたいな開発も少なからず増えてはいるのでしょうけれど。要するにAmplifyなんですが、AmplifyはAmplifyで制約もありますし、普通にやれるならSAMなりつこて低レイヤのパラメータ定義したほうがいいでしょうし、Serverlessの質問をインフラの人間にする、というのはなんというかいたたまれない気分にはなりますね。こちらとしてはServerlessがコケればコケるほど仕事があるんですが、一向にコケる気配はありません。というかコケるとも思えませんが。

さて、これは実はこの話、Lambdaと従来の開発の比較にされやすいのですが、外野のインフラから言わせてもらえば、その比較そのものが誤りである(ケースもある)、というように見えるのです。こんなもん、適材適所でしょう。という風に見えているわけですね。

さて、ただ、まあ開発サイドにおいてLambdaベースの開発、というものがなんとなく普段やってないから二の足を踏む、というのもよくわかる。

 

だって私だって普段触んないAzureやって、って言われたらコスト増えますもん。ストレージアカウントって何。ってなりますもんw

どっちもくっそ似たようなもんですが、それでも細かい仕様は違っていて、なんか一つやるのに調べることが多いわけで、そりゃあ普通に時間かかりますしクオリティなんて落ちますよ。

これってまあラベリングの功罪だとも思うんですけどね。Azureやりたいって言われたら多分私、その案件まるっと他社に回しますよ。だってそのほうが「お客さんのためになる」「お客さんのメリットが大きい」って即座に判断できてしまいますから。でも、会社だとそうも言ってられない。

上から「できない理由を探すな」とか、それを足掛かりに次の案件が!とか言われ、しくしく泣きながらよくわからんネタを調べながら、でも時間がかかってしまいながら、でもでも、クライアントに出している見積もりをそんな理由で大きく増やすこともできないから「バーンダウンしてる!」って進捗会議でなじられる。で、やってる本人は最初っからこのコストと内容じゃ無理、ってわかってしまっているから、「俺最初にできませんって言ったよね!?」みたいな不満をため込む。

これを軽視している、というのはたぶん経営層の無能っぷりの露呈だとは思いますが、これ、やっぱり結構多いです。ここでいったん、経営層はエンジニアというものが畑で毎年収穫できるお野菜ではない、ということをキモに銘じておくべきだと思います。

まあ、もっとも、品質問わないなら毎年畑で収穫自体はできるんですが。

つまり、よほどアホのエンジニアでもない限り、エンジニアの「できません」は「(この納期とこの仕様だと)できません」といってるだけで、別に後ろ向きなこと言ってるつもりは皆無なんですね。で、こうしたらできる、って言おうもんなら高すぎる時間かかりすぎるってお前らが否定するのがわかってるから一足飛びに結論として「(お前の要求とすり合わせができないから、この納期と仕様じゃできないし、お前とそれを合うようにすりあわそうにもお前が妥協することはないから)できません」って言ってる場合があります。個人的には何一つ後ろ向きではなく、前向き発言ですので、当然ここから議論の発展が可能です。

だってこれ言っている意味は「あくまで僕がやるなら」できませんって言ってるだけ、ってことですから、当然この発言をする側は「この納期と仕様を満たすエンジニアなりサービスなりはこんなのがあると思う、あるいはこうするべきだと思う」って代替案が出せるんだよ。言ってる側はまあ最初からそれを言えやって思ってるかもしれないけど、エンジニアたるもの、「できる?」って聞かれたら当然「(自分で)できるかどうか」と聞かれているに等しいわさそんなもん。

まあ言い方ってもんはあるけれどもw あとエンジニアの振りしたエンジニアじゃないやつの「できません」はたいてい「(やったことないから/むつかしそうだから)できません」なので、じゃあどうしよう、って相談したら黙ります。わかりやすい。

そもそもじゃあいつになったらできるようになるんだよ、と突っ込みたい。

 

この話はまた別にやるか。

 

えっちらおっちらやってクオリティ低い結果をプロダクトにするくらいなら、僕はAWSでクオリティを上げて提供したいですから、AWSで、と言いますし、それが通らなきゃよそに振りますよ、そんなおかしいことじゃないでしょう。もちろん、AWSもAzureもGCPもOCIもAlibabaもIBM CloudもSakura Cloudもニフクラもなんもかんも同じように同じ構築レベルで同等クォリティで出せるならやりゃあいいと思いますが、そんなスーパーエンジニアなんか見たことないですね。クォリティを大きく下げればいるかもしれないけど。

だって、こんなの開発の人に「あなた『開発者』なんだからphpもC++もC#もVBもPythonもRubyもNodeJSもTypeScriptもWhitespaceも完璧ですよね」って言っているのと同じですもの。こんな暴論ぶちかましてくる相手と仕事とかしたくないでしょw Whitespaceが完璧な技術者とか、もうそれ人間じゃないよ。

さて、こういうのは多分にラベリングの功罪だとは思うんですけどね。言語が使えることと、とマイクロサービスの設計・構築ができること、は別ですし、それも含めて「開発の持つ技術力」なんです。

なので、インフラの人間は開発の人間をかなり観察します。そのうえで、「どこまでできる人か」「どんな壁を提示したら乗り越えてくれるか」「これ以上の壁を提示したら乗り越えてくれなくなる(コストオーバーの可能性がある)からこれを組み込むのはやめよう」とか、多分、皆さんが思っている以上に余計な事考えています。

そりゃあね。Web案件なんて大半がやろうとおもやあS3+Lambda+APIでまとまるでしょそんなもん。技術論だけでいうなら、できない理由なんかほとんどないもの。そこにかかる開発側の支払うコストとか、そういうの全部無視していいならインフラの出す設計書なんてもうLambdaとAPIとPub/SubとKinesis/SQSとDBとかしか出てこないだろそんなもん。

でも、それじゃあダメだよね。理想論と空想と妄想に染まった「ぼくのかんがえたさいきょう」をぶちかましたって通らんよ。そこにはその中に組み込むアプリケーションを作る別の人がいて、運用をする別の人がいて、システムを更新する別の人がいて。

みんなが使えなきゃ意味ないんだよ。絵に描いた餅は食えないんだよ。

そして、この当たり前のことは、開発者やエンジニアは十分にわかってる人が多いんだけど、これを決定的にわかってない人がたまにいる。営業とか経営層とか中間層とかにも多いけど、それはまだいい。はじめっからテクニカルな議論の中にいないから、彼らはカネと時間とで計算をしているので、スキルで計算をしていないし、技術を勘案には入れてこない(のが基本原則だね)。

 

問題は、エンジニアとして存在しながらエンジニアの苦労と疲弊を理解せず、理想論だけで「俺が作るわけじゃねぇし」って立場をとるプレイヤー。

うちは、SRE的にチームでやらせてもらうことが多い以上、クライアントもチームの一員である、という認識だし、できもしねぇことを口にするクライアントサイドのエンジニアなんかチームに要らねぇよ、という立場をとる。だって、責任負う気がゼロってことだもの。SREとして成り立たないし、根底をぶち壊してくるならこちらも対応としてはSREじゃなくて受託案件的に納品したらしーらねー。ってやる。だってそうしてほしいからそういう態度なんだろう?w

まあ、そういうタイプはいろんなとこにいたりはするんだけど、よく見かけるのは社内SEでよく見かける。特に、情報収集に熱心なSEほど、偏りやすい。世の中はこんなにかっこいいことやってんのに俺らは。頼めばやってくれるんじゃね? 俺内容はよくわからんけど。みたいなノリだとは思うのだけど。

 

分かるよ? メリットだけ言えばマイクロサービスで実装できるだろう。それがコストも安いだろう。ランニングはね。運用を自分たちがすること考えても、マイクロサービスならやることないから楽そうだ、って思えるんだろう。

マイクロサービスにはマイクロサービスなりの運用と監視があって、そっちの概念はそもそも、レガシーのメトリクス監視もクソ満足にできていない人には概念からしてわけわからんってなりやすいと思うんだけど、彼らはメトリクス監視=運用だから、APMだとかディープモニタリングとかカオスエンジニアリングが運用だとか思ってないんだ。

というか、SREとかを組み込んでいかなきゃいけないんだ、という意識があったら絶対に言えないんだよ、メンバーの力量を超えた要求をコスト判断だけで出す、ってのは。

何がおきてるのか、ってことなんだけど、これはおそらく、「基本的な思考がウォーターフォールとモノリシックアプリの開発」のまま、「技術面だけをマイクロサービスに置き換える」という行為の結果だと思っている。だから、社内SEで発生しやすい。

違うんだよなぁ…。マイクロサービスってのは「技術」じゃなくて、「思想」とか「文化」の領域にあるものだ。アジャイルとかと同じ。やるなら全部だ全部。部分リプレースなんか意味あるわけないだろ、混乱しか生まないよそんなもん。

 

そういう意味では、結果としてのプロダクトでは最終運用する社内SEにマイクロサービス運用監視における高度な解析とDevへの参加を求めることになるが、そうなると彼らは違和感を感じるんだよね。だって、基本がレガシーシステム作ってるつもりで、縦割りで役割分割しているつもりだから、なんで開発の責任を自分たちも負うのかが分からない。僕ら運用だもん。ってなる。コード見て、って言われても見ない。だってわかんないもん。

これが、SREでチーム組む側からは無責任、と見えるし、向こうからはプロに頼んだのになんで俺らが学習コストとか払うんだよ、ってなる。要するに思想がマッチしてない。

ここの調整をきちんとできる中間の営業サイドってほとんど見たことがないので、どうしたってここに技術系営業が出張らなきゃならなくなるけど、彼らだって現場の最新技術に追い付いているわけでもないから、今のクラウドなんかの速度だと2,3周周回遅れなケースだってある。それを責められはしないけれど。

 

正直に言う。

 

現状のクラウド回りの技術進捗って、世界でトップレベルの頭のいいのが集まって、「こんなんあったらすごくね!?」みたいな勢いでくっそ常識外れの速度で開発を推し進めている。

で、当然だけどそれを使う側も相当あたまのいい連中が「これすげぇや!」ってなってくっそ頭のおかしい速度でサービス作ってる。

 

で、だ。

 

それが、世界の全部なわけないだろ。そんな全員頭いいやつしかいなかったら、えらいことじゃないかwwwwwww 世界中の全員が9秒台で100m走れるわけじゃない。

AWSがサービスリリースして一週間で自社サービスをリファクタリングして新サービスを組み込んでより高性能なサービスにリニューアルした話

とかまあSummitでもDevDayでもなんでもいいけど、こんなタイトルのセッションしょっちゅうある。言っとくけど、これただの自慢だからな!!!!!w エンジニア同士で相手煽ってるだけだからな!真に受けるな!w いや、まあ真に受けてもいいけど誰でもできることじゃないんだよ。

誰でもできることじゃないからセッションでしゃべってんだよ。

だってそうだろう。バッティングフォームを改善したら3日で打率が20%向上した話。を大谷から聞いて、それを草野球のチームに「同じことやって同じ成果出せよ、やきう選手だろ」って言ってるのと同じなんだよ。

 

やきう選手にも草野球とアマ野球とプロ野球とメジャーリーガーがいるんだよwwwwww分かれよそれくらいwwwwwwwww その中にもトッププレーヤーと有象無象プレーヤーといろいろいるんだよw

 

で、プレイするやきう選手のレベルに合わせて試合を組むんだよwwwwwwwwそれが設計とかに組み込まれているものの本質の一つなんだ。

まあ何がいいたいかよくわかんなくなってきたけども。

 

発注側がやり方にまで干渉するのは基本的にやりすぎなケースが多い。最初からマイクロサービスで作りたい、ならそういう要件でRFPが出ているべきで、MVCやらPoCであーでもないこーでもないってやってるところに後出しで制約ぶちかますのは、基本そっぽ向かれると思うぞ。

注意しといたほうがいいと思う、特に技術に傾倒しちゃった社内SE系の方々は。

若い子がそうなるのは別に「若さだなぁ」ってにやにやできるけど、中年すぎのおっさんにやられたらキモいだけだよ。裏打ちのない暴走なんて若さにしか許されねぇだろそんなもん。