はじめに 今携わっているプロジェクトの中で自分はテックリードとして動いていたのですが、9月からプロダクトオーナーが転職してしまうということで、自分がその役割を引き継ぐことになりました。 プロダクトオーナーは初めてやるので様々な本を読んでインプットをしていたのですが、 その中で『プロダクトマネージャーのしごと』を読んでいたときに第7章の『「ベストプラクティス」のワーストなところ』を読んでとても衝撃を受け、自分自身の経験と共に記事としてまとめたいと思い、この記事を書いています。 あたかも自分の言葉のように書いていますが、ほぼほぼ本からの参照ですし、自分なりの解釈を含めたり、自分の経験と照らし合わせたりしているので、この記事を読んで興味が湧いたら、ぜひ『プロダクトマネージャーのしごと』を読んでみてください。 7章だけではなく、全体的にも本当に良い本でした。 この記事でいうベストプラクティスについ

はじめに 6月に凄腕エンジニアさんから学んだ例外の話というQiita記事を書かせていただいたところ、かなり反響がありました。（2023年07月08日時点で570いいね、550ストック、はてなブックマークが560usersにブックマークされています） コメントなども目を通させていただいたところ、自分に基本的な例外の知識が足りないなと思ったので、いろいろな記事に目を通したり、本を読んだりして、インプットしました。 そのアウトプットとして今回記事を書きます。 エラーと例外 この記事ではエラーと例外という二つの概念は同じ概念で交換可能なものとして扱います。 （ソフトウェア設計のトレードオフと誤りより引用） Javaでは【プログラムではどうにもできない事態が起きた時に発生するものがエラー、そうではないものは例外】というような考え方があったり、他にも【想定内であれば例外、想定外であればエラー】という考

はじめに 最近コードを書いていてふと、今の自分は以前とは全く違う思考でコードを書くようになってるな。。。と気づいたので、少しまとめたいと思います。 以前 「本でこういうコードの書き方が良いって書いてあったな〜」 「本でこういうコードの書き方だめって書いてあったな〜」 「凝集度あげるためにデータとメソッドは一箇所にまとめた方がいいな〜」 「単一責務の原則に反しているからなおさないとな〜」 ↓ 実際に改善 ↓ 「よし綺麗になった」 最近 「使いやすい形のインタフェースになっているかな？」 「メンテのためにも共通化しておいたほうが良いな。。。」 「どういうデータ構造で持っておくのが嬉しいだろうか？」 「直感的に理解できるようになっているだろうか？意図などは伝わるかな？」 ↓ 実際に改善 ↓ 結果的に綺麗になっている 以前と最近との違いは？ 以前と最近の主な違いは、思考の過程で具体的に自分のコード

はじめに 管理画面を開発しているときに、いくつかポイントがあるなと思ったのでアウトプットします。 現場で行われるやり取りやコミュニケーションを考慮する URLでの共有 現場では 「こういう検索結果のこういうユーザーに対してこういう操作をしてください！」 というふうに他の人にURLを共有して指示を出したり、 「今月の対象はこの人達だから、確認お願い！」 というふうにコミュニケーションを取りながら業務を進めます。 ある状態のページをURLを通して共有したいことは多々あります。 URLに状態をもたせることは重要ですし、URLで表現できたら便利なことはたくさんあるのではないかなと思っています。 管理画面の開発をするときは、 そのページがどのようなコンテキストで共有される可能性があるのか、URLで表現できたら便利なことは無いかを考えてみる と良いと思います。 やり取り、コミュニケーションに必要な情報

最初に 皆さんはドキュメントとどのように付き合っていますか？ 前職はベンチャー企業ではあったのですが、割とウォーターフォールに近く、決められた仕様を満たしていればOKというふうな感じだったので、 仕様書を書いて、エンジニア数人で仕様書レビューをして、OKが出たら実装して、テスト前にテスト仕様書書いてテスト仕様書のレビューして。。。というふうに開発を行っていました。 今はスクラムマスターがいる環境でアジャイルで開発を行っています。 ドキュメントに関しては特に決まりはなく、開発者が書いたほうがいいなと思ったタイミングで書かれています。 ドキュメントは必要だという話は良く聞くし、ただ毎回しっかりドキュメント書くのも結構大変だよな。。。 というふうに思っていて自分の中でいい落とし所があればいいなと思っていたのですが、 最近一旦その落とし所を見つけた気がしたのでこの記事を書いています！ （アジャイル

はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある 注意 下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解

はじめに 運が良いことに自分は今、今まで出会ってきたエンジニアの中で一番凄いと思う人と一緒に働けています。 今の会社で働けていてよかったな〜と日々感謝しつつ、一緒に働いている中でたくさんのことを勉強させていただいています。 そしてそろそろアウトプットせねば！（使命感）と思いこの記事を書いています。 今回は技術以外のことで学んだこと、大切だと思ったことを書いていきます。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） （どれくらい凄いのかも本当は書きたいですが、この記事の目的とは離れてしまうので省略します。。。） （本当は【凄腕エンジニア】という言葉でくくりたくないくらいすごいエンジニアさんです。。。） ドメイン知識、業務知識の大切さ 今自分が参加しているプロジェクトではTさんが業務要件の整理やヒアリング、システムの設計、DBの設計を手掛けているのですが、 ドメイン知

はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth