原田一也 / DI Architect
696 posts

原田一也 / DI Architect
@Harada_BI
「いつでも辞めます」と言えないエンジニアは生涯足元を見られます。 必要なのは技術力ではなく『流動性/選択肢』。 単価を跳ね上げ、案件を自由に選べる絶対的な立場を構築する具体策をまとめました。 🎁9割が知らないIT業界の搾取構造を破壊し、あなたが“選ぶ側”になる 【撤退という最強の生存戦略(PDF)】 無料公開中


PMの鉄則ですね。 「人はミスをする」という前提(性悪説)でシステムを設計するからこそ、実際の運用では「人」を信頼し、裁量を持たせることができます。 この切り分けができていないプロジェクトは、管理のための管理が増幅し、メンバーが疲弊していくのを何度も見てきました。


私の知人の未経験インフラエンジニア志望者が入社前に「入社2年目から設計構築案件に入れる」と言われてとある企業に内定承諾をしたらしいです。 ですが、承諾した後で「やっぱり最初は情シスあたりに行ってもらうことになりそう。設計構築へ行けるのは5年後くらいになる。」と話が変わったらしく不信感を抱いています。 私も実際に似たような経験をしたことがありますが、残念なことにSES企業ってこういう嘘をついていることが珍しくないんですよね。 こうでもしないと人を採用できないのか理由はわかりませんが、どうにかならないもんですかね〜…😔



新人エンジニアとペアプログラミングをすると、成長を阻む共通パターンが浮かび上がってきます。 自分のコードは読み返すのに、使っているフレームワークやライブラリのコードは「難しそう」と避け続ける。この小さな回避が積み重なるほど、成長の上限は静かに下がっていく。コードを読む習慣は単なるスキルではなく、エンジニアとしての伸び代そのものを決める変数です。 もう一つはエラーへの向き合い方。焦って闇雲に試すのではなく、メッセージを正確に読み、仮説を立てて検証する。この確認サイクルを短く回せるかどうかが、1年後・3年後の実力差に直結します。 qiita.com/hirokidaichi/i…

仕組みは性悪説、運用は性善説 人はミスするし、楽な方に流れる。だから仕組みは、崩れない前提で設計する。 でも運用まで疑い始めると、チームは疲弊する。信頼して見守る。 プロジェクトは、このバランスで。

「AIでコーディングしてる」 じゃなくて 「AIがコーディングしてる」 なんだよなぁ







