熱脳しゃちょのブログ -31ページ目

熱脳しゃちょのブログ

おせっかい焼SE兼プログラマ兼……の辛い日々と、思う事なぞ

いらない。

 

マジいらない。

 

そもそも、パブリッククラウドってSRE的なものをクラウド事業者に任せるための仕組みなんだから、SREは限りなく薄くなるはずなんだよ。

なのに、SREが傲慢な門番と化してるプロダクトが目につく。

 

「設定より規約」

は、こういう「隠れ設定を知っているかいないか」「暗黙の運用ルールを知ってるか知らないか」って要素を消して、つまらん手動運用を排することで安定運用を目指すものなのに、TerraformファイルとSREチームが延々と太っていくところの、なんと多いことか。

「そういうものを増やすことで、俺を切り捨てられないようにしている。これを複数の会社でやることで、業務委託費を積み上げてる」とか自慢げに語るSREエンジニアにあったことがある。

こいつ、端的に言ってクズ。

それに集られてる経営者たちはマヌケ。

 

QAも同じ。

サービスがさらに巨大化複雑化し続けている現在、E2Eとかで品質を保証なんてできるわけがない。

チェック表が莫大になっていて、全部チェックできない。

どころか、絶対にテストケースが網羅されてない。

新機能のテストもろくに準備されない。

すっとどうなるか?

穴だらけテストをやってるふり、ただのアリバイ作りをしてるだけだから、リリースするたびに障害が発生するし、裏でこっそり致命的なデータを増殖させていたりする。

なんのためのDevOps、自動テストだよ、と。

 

これは裏を返せば、設計実装エンジニアの負担、責任が無茶苦茶重いってことでもある。

だからこその、土日祝日盆暮正月、勉強しないとまにあわんのだ。

こういった本質的に高度な内容を、AIに投げるとか、わけわからん。

 

SIerのOJTでPM勉強してきました系。

そのうちでも、ものを考える頭があるなら救いがあるのだが「僕が『やってきたこと』は絶対正しいです」って変な自信を持った教科書ガイド脳だと、マジで救えん。

 

「画面と帳票で用件定義して、1画面ごとに設計していきます」

とか、

「今それは考えないでいいです」

とか、

「業務ドメインごとに分割して設計します」

とか、それではダメだ、ってのが理解できない。

 

なぜそれではダメかと言うと、SIer系PMが前提としている世界が

こんな感じで、この売上を最大化することを前提としているから、自社サービスでそのまま適用したらあかんのだ。

 

SIerのプロジェクトは本質的に、開発は最短最小限、運用は引き延ばし最大限に、というのを指向している。

将来のことを考えて準備する時間は無駄。むしろ害悪。

だが、自社サービスだと全部逆の結果をもたらす。

将来のことを考えて準備しないと、突然死を招く。

SIer的PM「HowTo」のカーゴカルト的適用は、自社サービスにとっては致命的になる。

実際、今まで関わった炎上現場、相談受けてる底なし沼現場は、ほぼもれなく、このようにして構築されている。

「PM必要だから、SIer出身者を探そう」って安直暗愚な発想が遅延信管付き地雷を埋め込むことになったというわけだ。

# 最後まで面倒見る必要ないとか酷いじゃないか! って反論がSIerからはあるかもしれんが、だらだら売上を上げられるからぶら下がってるだけだし、じゃ、NHKの営業基幹システムを元々請け負ってたところはどうしたんだよ? と。

 

自社サービス開発の場合、この損失を回避、あるいは最小化するために、初期設計、基盤構築等々に無茶苦茶気を使う。

初期の規約化、抽象化、検証容易化が生死を分けると言っていい。

そこらをちゃんとやれば、具体的な実装はジュニアの子に任せられるし、そういう設計は勉強になる。

 

んだが、開発を「創造」ではなく「作業」だと心得違いしている連中には、理解できんらしいんだよな……。

 

#あと、Fatな設計ってのも、SIer的には売上になるが、自社サービスだと損失になるんよな。