考え方

考え方

『具体と抽象』で学んでも、抽象化を実務で忘れてしまう|設計の失敗から考える

『具体と抽象』(細谷功 著)を読んで、抽象化を単なる「共通化」だと思い込んでいたことに気付かされました。汎用テーブルを作った失敗や、人が作った抽象的な処理を追えなかった経験を交えながら、具体と抽象をどう往復すべきか、忘れないための備忘録を残します。
考え方

同じジャンルの本を4〜5冊読んだら、1冊を厳選するのをやめた

レビューを読み続けて1冊を厳選するより、同じジャンルの本を4〜5冊読んだ方が共通点をつかみやすかった。瞑想・睡眠・設計の本で試した学び方の記録です。
考え方

技術者面談で、技術力より受け答えを見ている理由

SESなどの技術者面談で面接官と応募者の両方を経験しました。面接官として受け答えのどこを見ているか、自分が面談を受ける時に何をしているかを書きます。
考え方

リリースに3〜6か月かかる状態を問題と決め、開発の進め方を変えた

新機能のリリースに3〜6ヶ月かかる現状を「生産性の低さ」と定義し、Git・テスト・設計書・AI導入を進めた。開発速度が約30%改善するまでと、その後に生まれた新たな課題の記録です。
考え方

100時間近く残業した炎上案件で、実装と交渉の仕方が変わった

炎上案件を勧める記事ではありません。100時間近い残業や休日出勤を経験した中で、手戻りを減らす実装・顧客との交渉・ゴールから逆算する計画力を得た過程を振り返ります。