Hoshino

## 1. ドメイン駆動設計：業務の複雑さに合わせて設計を選ぶ力 『ドメイン駆動設計をはじめよう』で学んでいる、業務領域を「中核」「一般」「補完」に分け、領域ごとに設計への投資の度合いを変える考え方を、実務で使えるようにしたいです。 **なぜ** 現職では、人事部門・健康保険組合向けSaaSのテーブル設計や、複数チーム・複数ベンダーのテーブル定義を横断したレビューを担当しました。その中で、チームごとに同じ言葉の意味が少しずつずれたり、どこまでを1つのモデルで扱うかがあいまいだったりする場面を経験しました。境界づけられたコンテキストやユビキタス言語を使って、業務の境界と設計の境界をそろえられるようになれば、プロダクトが大きくなっても変更しやすい設計を保てると考えています。 ## 2. チームの状態に合わせたリーダーシップ 『エラスティックリーダーシップ』にある、チームの状態を「サバイバル」「学習」「自己組織化」の3つのモードで捉え、モードに合わせてリーダーの振る舞いを変える考え方を身につけたいです。 **なぜ** 現職では最大10名のチームで、1on1を通じてメンバーの特性や成長したい点を把握し、タスクを割り振ってきました。ただ、その判断は経験則に頼っている部分がありました。リリース前のように指示を明確にすべき時期と、メンバーに任せて学んでもらうべき時期を意識的に切り替えられるようになり、最終的にはリーダーがいなくても回るチームを作りたいと考えています。 ## 3. 期待値をそろえて進めるアジャイルな開発 『アジャイルサムライ』のインセプションデッキのように、プロジェクトの目的、やらないこと、優先するものを最初に関係者とそろえる進め方を実践したいです。 **なぜ** 技術的に正しいものを作っても、「何のために作るか」が関係者とそろっていなければ、手戻りや期待とのずれが起きます。今後は実装だけでなく、提案や企画の段階から関わりたいと考えており、そのためには関係者の期待値を最初にそろえ、短いサイクルで確かめながら進める力が必要だと考えています。 ## 4. Go言語 Go言語を体系的に学んでいます。roadmap.sh のカリキュラムに沿って基礎を学び、標準ライブラリ、SQLite、goose を使ったブックマーク管理の CRUD API を作りながら、Laravel との違いを整理しています。 **なぜ** これまで主に Laravel で開発してきましたが、フレームワークが隠している HTTP の処理や DB とのやり取りを自分で書くことで、バックエンドの理解を深めたいと考えました。また、シンプルな言語仕様、静的型付け、並行処理の扱いやすさ、単一バイナリで配布できる運用のしやすさから、Go はバックエンドだけでなくインフラまで技術の幅を広げるのに適した言語だと考えています。