うーふ(@uufu_engineer):積極的なのになかなか提案が通らないエンジニアがいる。「この2つのAPI、1つにまとめませんか？」とか「この処理Lambdaに切り出しませんか？」とか。単体で見れば、別に悪くないんだけど、彼の提案が採用されることはあまりない。そのAPIが複数のマイクロサービスから呼ばれているなら、呼び出し元の移行や後方互換の考慮が必要になる。他の実行基盤があってデプロイや監視の仕組みまで整っているなら、そこだけLambdaにするとむしろ運用コストが増えてしまう。つまり、「ゼロベースでの最適解」と「今この瞬間の最適解」は異なるということ。既存のコードベースが今の形になったのには理由がある。過去の制約や当時の優先順位、途中での方針転換など。それを踏まえずに案を出しても、良い課題解決にはならない。その点、優秀なエンジニアほど理想論に逃げず、良い意味で「今できる最善」を考えているなと。新しい技術や設計パターンを学ぶのと同じくらい、「今どうなっているか」「なぜそうなったか」を愚直に追う姿勢が大事。座学に逃げないよう注意しなくては。

2026.08.12 11:33

積極的なのになかなか提案が通らないエンジニアがいる。「この2つのAPI、1つにまとめませんか？」とか「この処理Lambdaに切り出しませんか？」とか。単体で見れば、別に悪くないんだけど、彼の提案が採用されることはあまりない。そのAPIが複数のマイクロサービスから呼ばれているなら、呼び出し元の移行や後方互換の考慮が必要になる。他の実行基盤があってデプロイや監視の仕組みまで整っているなら、そこだけLambdaにするとむしろ運用コストが増えてしまう。つまり、「ゼロベースでの最適解」と「今この瞬間の最適解」は異なるということ。既存のコードベースが今の形になったのには理由がある。過去の制約や当時の優先順位、途中での方針転換など。それを踏まえずに案を出しても、良い課題解決にはならない。その点、優秀なエンジニアほど理想論に逃げず、良い意味で「今できる最善」を考えているなと。新しい技術や設計パターンを学ぶのと同じくらい、「今どうなっているか」「なぜそうなったか」を愚直に追う姿勢が大事。座学に逃げないよう注意しなくては。

150

Forward to community