なんだろ？
設計失敗、実装失敗して逃げ出すの、やめてもらっていいですか？
と言いたい。
みんなが迷惑するから。
開発初期は「あの機能が動くようになった」「この機能が動くようになった」って盛り上がるんだけど、「次の機能を実装だ」となったとき、設計失敗、実装失敗していて詰んでいるのに当の技術者たちが最初に気づくんだよね。
当然だけど。
で、逃げる。
新しいこと始めたいとか、あれやこれや前向きな理由を並べたり、チームの雰囲気ガーとか他人のせいにしたり。
絶対、設計、実装失敗したので辞めますとは言わないw
気づけない間抜けな技術者は、何が起こっているか理解できないまま取り残される。
で、ポンコツシステムが残る。
経営者とか、それを売ろうとしている営業は、かなりのお金と時間をかけて作ったものだから、立派なシステムだと思ってる。
取り残された技術者も、不具合が多いけどそこそこ立派なシステムだと思ってる。
ちょっと手直しすればなんとかなると思ってる。
みんなよくわからないまま、ポンコツシステムをいじり続ける。
そのポンコツシステムを、高い金出して使うクライアントがいる。
しんどいね。
新サービスの広告記事を鵜呑みにして、大したテストもせずに「最新のサービスを使ってシステム構築だ〜！」とやってるサービスは大概ポンコツなんだよね(使いこなしてるサービスもあるけど、ごく稀)。
新サービスの紹介広告記事には、当然「新サービスの」紹介広告なので、既存サービスとの比較が乗っていたとしても新サービスが不利な点は紹介されないかわかりにくくされてるとか、有利になるときの前提条件がボカされているとかしてるし、採用側がその有利になる前提条件が自分たちがこれから構築するサービスに当てはまってるか判断してなかったり、判断する能力に欠けていたりする(同時アクセス数1000以上、とかいう条件になってるのに、同時アクセス数がたかだか数十しか見込めないサービスに採用してるとか、アクティブユーザー率が80%以上の業務用アプリでしたとか、それなら普通にRDB使えよ、みたいな)。
ダメシステムのほとんどは「いや、このサービスの前提で、なぜこれを採用した？」となってる。
この採用がうまくいっていれば、そこまで酷い事態にはならないはずなんだよね。
ここが失敗していると、まず間違いなくそのサービスの根幹部分に関わっているはずなので、リカバリの難度が格段に上がる。
で、闇が深いのが、こうやって失敗した技術者が「前職では××という新サービスを使ってシステムを構築しました。識者です」って自己紹介して転職している、って事実(個人的にはスタートアップホッパーと呼んでる)。
採用側は「あの新サービスを使ったことがあるんですか。すごい」って採用しちゃうんだよね。
でも残念ながら、かなり高い確率でその技術者は「あの失敗は繰り返さない。あれは運が悪かっただけだ。次は別の新しいサービスを採用して、画期的な新サービスを作るんだ」ってやる気を出して、やっぱり同じ失敗を繰り返すんだよね。
だって、なぜ失敗したか理解してないから。
設計失敗では、1リクエストの処理だけ分解分析して、同時に複数リクエストが飛んでくるとか考えてないことが多い。
これは、開発、テストの時、1リクエストだけで動作確認すると動くんだよね。
だってそう作ってるから。
で、お客さんを入れ始めて「うほっ♡ 続々と採用が決まってる」となって、同時に複数リクエストが被るようになってはじめて問題が発覚する。
これは本当に多い。
「いや、みんなで同時にリクエストしたけどちゃんと動いた」って言い張るんで状況聞いたらみんな同じデフォルトの条件で同じ操作してんのね。
「後ろのサービスのキャッシュが効いてるだけじゃない？」って条件変えさせたら、三人がリクエストしただけでサーバが応答しなくなった、みたいな「何をテストしてるか理解してる？」みたいな笑えない話もある。
そう言う時、技術者は「サーバ増やせば解決」みたいに楽観視してるけど、「サーバ増やして原価が上がったら当然損益分岐点も上がって黒字化が困難、あるいは売れば売るほど赤字が増える」サービスになって、既存のクライアントを切ることもできないし値上げすることもできない、みたいな時間と共に加速度的に死が迫る状況に追い込んでいるのに気づかない。
というか、気づけない。
個別クライアントでは絶対黒転しない計算になって、毎月新規開発費を取らないと赤字化するってサービスがあったんだけど、それって赤字にならないように新規受注するたびにクライアントが増えるので月々の確定赤字額が増えていくとかいう「どうして誰も気づかないんだ？」みたいな状況に陥っていた。
「帳簿上は」後ちょっとで黒転する感じだったんだよね……。
実装失敗は、意識高い系の構築手法を、理解もしないでWebページで紹介されているままなぞる「カーゴカルト系」の失敗が圧倒的に多い。
このレベルのカーゴカルト系には、より低レベルの「コピペして不要な部分を消せてない」カーゴカルト系を見下して笑う技術者が多いような気がしてる。
どんな技術も使い所があるし、持て囃されている(いた)からといって絶対正義とは限らない、ということが理解できてない。
当初は正義と思われたけど、すぐに副作用があることが発覚して使い方には注意みたいな話になった技術も、日本ではその当初の「正義」といわれた頃の「やってみた系記事」しか紹介されてなかったりして、「それ、副作用があるよ。今起こってる障害の原因の一つがそれ」と言っても「そんなWebページ見たことない」とか逆ギレされて、「うわ〜、マジか……」となったことは、ちょいちょいある。
意識高い系の実装手法は「論理的に整理してみた」系が厄介。
オブジェクト指向が、関係あるものを近くにまとめて、極力一箇所(ファイル)の修正で済むように「囲い込む」ことで、巨大化するシステムのメンテナンスコストを下げる、という側面も持つ手法なのに、「あえて関係箇所をソース全体に撒き散らす」みたいなことをして、先人の知見と逆行してたりする(紹介記事の出来が悪いか、ちゃんと読めてないかのどちらか)。
既存のと似たような要素を追加したい、と言われて5、6ファイルをばらばらと修正しなきゃいけないとか、レビューしずらいだろ、と思うんだけどな。
「あ、それは、あそことこことそこと××と……を修正してください」って、メンテしづらくね？と思うんだけど、その「あそことこことそこと××と……」という修正箇所を「把握している自分ってできる技術者だ」って思ってるんだろうね、というのが態度からありありとわかる。
完全把握しないと触れないシステムなんて、モジュール化とかがなぜ必要か理解できてる？ と思うんだけどね。
日本語の解説Webページにやたら詳しかったり、やたらと囀る技術者は、使う側からすると頼もしく見えるかもしれないけど、実は
地雷率が高い
ように思う。