MUSASHI MIYAMORI / ENGINEER PROFILE
宮守 武蔵エンジニア・開発リード
要望の背景を整理し、仮説を立て、小さく試しながら、機能の実装まで進めることを得意としています。現在は実装の大部分をAIに任せ、課題整理・設計・検証・判断に重点を置いています。開発規約・自動検証・AIレビューを組み合わせ、チームが継続して品質を改善できる仕組みづくりにも取り組んでいます。
設計資料、コード、動作確認、ログを並行して確認できる環境を整えています。日々の開発に集中するための、私の仕事場です。
開発マシン：Mac Studio（M5 Ultra／メモリ96GB／SSD 2TB）
サービスの立ち上げから、
継続的な開発・改善まで。
目的・利用者・業務フローを整理し、優先順位と開発範囲を具体化。設計から実装、テスト、リリースまで一貫して取り組んでいます。
開発規約・ルール、レビュー、自動テストの整備・普及を通じたチーム改善を経験。現在は、自動検証とAIのSkill・レビューを組み合わせ、人の確認への依存を減らし、開発量が増えても回る品質管理を目指しています。
生成AIを使う機能や、情報を収集・構造化する仕組みを設計・実装しています。精度・処理時間・運用コストを評価し、継続運用を考えながら開発しています。
課題の理解から実装の検証、進め方の判断まで、次の強みを活かして開発を進めています。
| 強み | 具体的な行動 | チーム・プロジェクトへの価値 |
|---|---|---|
| 課題の理解 | 要望の背景や業務フローを整理し、本当に解決したい問題を捉える | 要件が固まる前から、解決すべき課題を共有できる |
| 問題の分解 | 複雑な課題を、調査・検証・実装できる単位に分ける | 優先順位と、最初に着手することが明確になる |
| 行動力 | 不明点に仮説を立て、小さく試して判断材料を集める | すべての要件が確定する前から、具体化を進められる |
| 検証力 | 実装やAIの出力を、目的・実データ・運用条件に照らして確かめる | 実際に使えるか、どこに問題があるかを早い段階で確認できる |
| 判断力 | 検証結果と予算・納期・事業優先度を踏まえ、採用・修正・次の行動を決める | 作る範囲や進め方を、根拠を持って決められる |
| 実装の速さ | TDDと自動テストで手戻りを抑え、仕様が固まりきっていない機能の変更にも素早く対応する | 初期実装から継続的な仕様変更まで、開発速度とコード品質を保てる |
| チームの改善 | 開発規約・自動テストを整え、品質の判断基準をリンター・FormatterやAIのSkill・レビューへ組み込む | 人の確認への依存を減らし、開発量が増えても品質を保てる仕組みを目指す |
| AI活用 | 調査・実装・情報整理の負担を減らし、検証と判断に集中する | 複数の案を試して確かめながら、課題解決を進められる |
開発で関わっている領域バックエンド・フロントエンドからインフラ・CI/CDまで。サービス全体を見ながら、要件整理・設計・実装・運用改善に取り組んでいます。
立ち上げから、
長期の保守・改善まで。
2017年6月〜2023年4月 / 業務委託
初期フェーズから約6年間、開発・保守・改善を継続。
2023年10月〜現在 / 業務委託
既存サービスの継続的な機能開発・改善に加え、同社の生成AI機能の設計・実装を担当。
2026年7月〜2026年8月 / 業務委託
データ収集処理の改善と、AIを活用した技術検証。
企画からWeb・iOSアプリの公開まで推進。チーフエンジニアとして、設計・実装を含む開発をリードしました。
顧客との折衝から、サーバー・ネットワークの要件定義、設計、構築までを一手に担当。事業側・現場側・開発側の会話をつなぐ、現在の仕事の土台になっています。
AIを本格的に活用する以前から、実装の速さを強みとしてきました。着手やコーディングの速さ、開発環境の整備に加え、TDD（テスト駆動開発）で期待する振る舞いを確かめながら実装し、手戻りを大きく減らしていたことが、その速さを支えていました。
自動テストで既存の振る舞いを確かめられるため、仕様の追加や変更、リファクタリングにも積極的に取り組めました。変更を重ねても開発速度と保守性を保つことを大切にしています。自分で設計・実装・テストを重ねてきた経験を土台に、現在はAIに実装を任せ、検証方法を選び、結果から採用や修正を判断しています。
開発にあたっては、目的・予算・納期・優先順位を整理することを大切にしています。技術的な論点も専門用語だけに頼らず共有し、何を作るか、何を後にするかをチームで考えます。
変更コストの高いDBの設計と検証に、特に重点を置いています。データの状態と制約を明確にし、アプリケーション側の処理をシンプルにすることを重視します。NULLは極力減らし、boolは必要な場合に限り、状態の表現にはEnum型も検討します。論理削除は十分な理由がある場合に選び、DBの制約や必要に応じたトリガーで不正なデータの登録を防ぎます。整合性とともに、パフォーマンスも大切にしています。
事業フェーズに合う、必要十分な設計を重視します。undefinedやoptionalなプロパティを極力減らし、データが取り得る状態を型で明確にします。制約が曖昧な配列を処理間で受け渡し続けず、Value Objectなどに制約と整合性を持たせ、各処理をシンプルに保ちます。
共通化は目的や責務が同じで、変更・保守の負担を減らす十分なメリットがある場合に行います。最初から作り込みすぎず、他のエンジニアも読みやすく変更しやすいコードに。既存システムは、事業を止めずに段階的に改善する進め方を大切にしています。
現在は、機械的に判定できる規則を厳格なリンター・Formatterで自動検証し、設計・保守性などの観点はAIのSkillとレビューの仕組みに組み込む方針です。繰り返し見つかる問題やチーム固有の判断基準を蓄積し、多くの問題を自動で拾える状態を目指しています。
人の確認が必要な変更をできるだけ減らし、メンバーや開発量が増えても品質を保てる仕組みを重視します。レビューする人の時間と注意力に依存する部分を減らすことも、開発組織の改善だと考えています。
金額計算など重要な処理には、期待する振る舞いを説明するUnit Testを必ず用意します。各APIには少なくとも1つのFeature Testを設け、変更後の正常動作を確認できるようにします。実装の内部構造を変えても壊れにくいテストを重視し、仕様変更やリファクタリングを継続できる状態を作ります。
AIによって自動テストの作成・修正にかかる負担が減り、その価値をより活かせるようになったと感じています。結果が速く返ること、保守しやすいことも重視し、PRレビューと組み合わせて改善を続けます。
使ってきた技術と、
開発での担当範囲。
現在取り組んでいる開発
GoとPostgreSQLを用いたデータ連携システムを設計・開発しています。HTTP API、DBスキーマ・クエリ、非同期ジョブを担当し、処理の重複や途中失敗を考慮したワークフローに取り組んでいます。
Go / net/http / chi / validator/v10 / pgx / sqlc / goose / River / PostgreSQL
生成AI機能の実務経験
生成AI機能の出力は、自動検証・実データとの比較・人による確認を組み合わせて評価します。精度・処理時間・運用コストを踏まえ、業務で使えるかを判断します。
データ収集では、Webサイトやドキュメントなど形式の異なる情報を扱います。取得・加工・検証を分け、要件変更や再処理に対応しやすい構成を設計します。
検証環境の構築・更新手順の整備
運用費と構成の単純さを踏まえ、EC2とDocker Composeを用いた検証環境を整備。フロントエンドとAPIのビルド・配置から、DBマイグレーション・初期データ投入まで、更新して動作を確認できるデプロイ手順をまとめています。
AWS CDK / EC2 / ECR / S3 / Systems Manager / Secrets Manager / Docker Compose
HTTP API・DB連携・非同期処理の設計と実装。
Webアプリの画面開発と、iOSアプリの開発。
DBスキーマ・クエリ・マイグレーションの設計と実装。API仕様・データスキーマの定義と入力検証を通じて、データの整合性を保つ。
生成AI機能と、Web・ドキュメントの収集・構造化の仕組みを設計・実装。ブラウザ自動化や、データ検証・再処理にも対応。
Webアプリ・データ処理基盤の構築・運用と、AWSのマルチアカウント管理。アプリ更新・DB初期化を含むデプロイ手順の整備。
自動テストの設計・実装、静的解析・コード整形、コードレビューや開発ルールの整備。
テスト・静的解析・ビルドの自動実行と、デプロイの自動化。
そのほか大切にしている本Clean Architecture、レガシーコードからの脱却、リファクタリング（第2版）、Clean Coder プロフェッショナルプログラマへの道、達人プログラマー