| Attribute | Details |
|---|---|
| Name | ichi-h |
| Birthdate | 1997/05/14 |
| Birthplace | 北海道札幌市 |
| Residence | 兵庫県神戸市 |
| Education | 同志社大学 文化情報学部 中退 |
| Hobbies | 料理、哲学、創作 |
| MBTI | INTJ-T |
設計とは、問題を多面的に捉え、解決へ導くための道筋を描き出すことと捉えています。
ドメイン上の複雑な問題を解決するためには、まず問題を正しく理解し、解決すべき課題を明確にすること、つまりWhatやWhyを仮定することが必要になります。
そのうえでHowとしての解決手段を考え、実行し、最後に仮説が有効であったかを検証することで、初めて問題が解決されたかを判断することができます。
例えばビジネスの視点で見れば、何を問題として捉え、なぜそれを解決する価値があるのか、何ができれば問題は解決されるのか、何をもって解決されたと判断するのかなどを考えます。
また技術から見れば、それを具体的にどういった手法でそれを実現するのかを考えます。ここにはいわゆるアーキテクチャというマクロなものから、コードの一行一行といったミクロの視点まで含みます。
他にもデザインやセキュリティ、テストなど様々な捉え方がありますが、それらすべては問題を中心に繋がっており、抽象から具体まで連続的なグラデーションをもった設計として統合されることで、問題解決へと導くことができます。
これは技術にまつわることだけではなく、ビジネスや組織など、あらゆる問題解決において共通が見られるものだと考えています。
もちろん、完璧な設計というのは存在しませんし、それを目指すことが本質的な価値を生むわけでもありません。
これは言わば、その場その場で移り変わる問題の上で、不安定に揺れ動くシーソーゲームのようなもので、このバランスを取ること、つまり品質のトレードオフを適切に判断し、完璧ではないかもしれないが、有効と考えられる意思決定を継続することが重要と考えます。
こうした設計や問題解決を通じて、プロダクトに関わる人々はもちろん、組織全体がハッピーになるお手伝いができるよう、日々楽しく精進しています。
2022年1月から、株式会社Wizleapにて10名前後のエンジニア組織におけるテックリードエンジニアとして従事。複数のプロダクトにて上流から下流工程まで一貫して担当し、プロダクト開発はもちろん、レガシーシステムの抜本的な改善や技術基盤の整備、エンジニア育成から組織改革、採用まで幅広く携わることで、プロダクトの拡大・改善からエンジニア組織全体の成長と活性化に貢献。2025年7月に退職し、現在に至る。
BizとTechを横断し、両者の架け橋となりつつ、ソフトウェアや組織を内外から強くしたい。
| Attribute | Details |
|---|---|
| Employment type | 正社員 |
| Position | テックリードエンジニア |
| Responsibilities | 開発、システムデザイン、DevOps、プロダクトマネジメントなど |
「ソフトウェアの力で、すべての人のお金にまつわる意思決定をサポートする」をミッションに掲げ、相談件数10万件以上・相談満足度98%以上の実績を持つtoC向けお金の相談プラットフォーム「マネーキャリア」や、金融機関向けSaaSプロダクト「MCマーケットクラウド」「MCエキスパートクラウド」といった複数のサービスの展開、また金融事業者向けのコンサルティング事業も行うInsurTechスタートアップ企業。
2023年の12月には丸紅株式会社との資本業務提携契約を締結し、シリーズAとして単独で3.5億円の資金調達を実施。
| Attribute | Details |
|---|---|
| 事業内容 | Webサービス事業、保険代理店事業、金融商品仲介業、メディア事業、プラットフォーム開発 |
| 従業員数 | 67名(2025年5月1日時点) |
| エンジニア数 | 9名(2025年5月1日時点) |
| 資本金 | 350,000,000円 |
| 上場 | 未上場 |
上流工程では、ビジネス上の課題や意義などを検討する要求定義から、具体的なシステムへと落とし込むための要件定義の作成、またシステムを技術的に解釈するシステムデザインまで一貫して行い、下流工程でも自ら開発・保守・運用まで携わることで、ソフトウェアの外部品質・内部品質の両面から高品質なプロダクトの提供へと貢献した。
特に技術的な側面から発生する問題や、技術によって直接解決できる問題は積極的に企画・提案・実行を行い、プロダクトの改善から生産性の向上等に寄与した。
フルスタックな開発体制が敷かれていた当時、エンジニアごとにデザイン品質のムラが生じていた点や、将来的なUIライブラリの移行を見据えた際、当時のコンポーネント設計では対応が困難であるという技術的課題が存在していた。
また、既存のUIコンポーネントライブラリでは、プロダクトが要求するUI/UXを十分に満たせないケースも増加していた。
こうした課題を解決するために、自社でUIコンポーネントライブラリを開発するプロジェクトが立ち上がり、初期フェーズでは実装を担いつつ、将来的なフロントエンドの構成を見据えたライブラリの位置づけや設計の策定・レビュー、また関係者間の合意形成に携わった。
その後プロジェクトの引き継ぎを受け、プロダクトオーナー兼スクラムマスターとしてライブラリの開発・保守・運用を主導した。
ライブラリのリリース後は、エンジニアの学習のサポートまで行い、定着後に集計したアンケート結果では、使用した開発者の8割がCSSの詳細を意識することが減り、全員が開発速度の向上を体感したという回答を得ることができた。
また採用面でも、ライブラリ経由から面談へ進む応募者が増加し、エンジニア採用へと寄与した。
最終的にはtoB向け主要プロダクトすべてにおいて採用され、ライブラリが規定するデザインシステムに準拠したデザインを構築することで、一貫したUI/UXの提供を実現し、さらにはUI/UXにおけるマネージャー・デザイナー・エンジニア間でのコミュニケーション基盤を確立することに成功した。
保険にまつわる複雑なドメインを持つシステムをPHP + Laravelで開発していたものの、動的型付け言語による挙動の不安定さや、フレームワークに強く依存した設計による保守性の低さなど、多くの技術的課題を抱えていた。
これらを解決するため、生産性と堅牢さのバランスからGolangへの移行を推進し、ドメイン駆動設計(DDD)やClean Architecture、CQSパターンを組み合わせた設計を採用することで、堅牢で保守性・拡張性の高いシステム基盤の構築を行った。
型システムやLinterを用いた静的解析による事前のバグ検出、アーキテクチャが規定する責務分離によるコードの可読性とTestabilityの確保、CommandとQueryの分離によるSQLの最適化などにより、システムの安定性とパフォーマンスの向上、大幅なDX改善の実現に成功した。
また、Modular Monolithアーキテクチャを採用することにより、ドメインごとをモジュールとして隔離することで責務を明確化しつつ、将来的にMicroservicesへと移行しやすい環境を整備した。
フロントエンド由来のバグが多発していた既存のVueプロジェクトに対し、TypeScriptによる型補完がより強力に効き、かつ「値の監視」ではなく「変更の管理」を徹底できるReactへの移行プロジェクトを主導した。
他エンジニアとも綿密に議論しつつ、変更に強く堅牢なアーキテクチャの導入、型システムの厳格化、コンポーネント設計の見直し、パフォーマンス改善、必要があればバックエンドのAPI設計の見直しも並行して行うことにより、システム全体の品質向上や大幅なDX改善を実現した。
通常の開発と並行して継続的にリファクタリングを実施し、1年近くかけたマイグレーションをエラー0で完遂させ、その後もフロントエンド由来のバグを大幅に減少させることに成功した。
初期のエンジニア組織では、すでに常態化してしまった技術的負債の放置や、属人化した開発体制、また全員がフルスタックエンジニアとして開発することによるコード品質のムラなど、多くの課題を抱えていた。
こうした問題に対して、単に技術的に負債を解消するだけでなく、継続的に高品質なソフトウェアやその内部の仕組みを自律的に構築・維持できる組織を目指し、多角的に数多くの施策を実行した。
エンジニア育成の側面では、定期的な技術勉強会の開催、ペアプロ、コードレビュー、テストコード、開発前のシステムデザインといった施策を導入し、エンジニア一人ひとりの技術力向上を図るとともに、こうした文化を定着させることで、継続的な開発力向上を実現できる仕組みや環境を構築した。
開発体制の側面では、全員がフルスタックエンジニアとなってしまう体制から、バックエンド・フロントエンドの領域を考慮したタスク作成と分担を行う開発体制へ移行し、各エンジニアが得意とする領域に集中できる環境を構築した。
またこちらと並行し、タスクが分担された状態でもバック・フロント間のコミュニケーションが円滑にできるよう、OpenAPIを用いたスキーマ駆動開発を導入し、設計段階での齟齬が発生しにくい体制を同時に整備した。
採用面では、既存の採用プロセスから見直しを図り、技術要綱の検討から技術課題の作成・採点、面談の担当まで携わることで、主に技術的な側面から組織にフィットするエンジニアの採用を実現し、組織の強化へと貢献した。
👑: 3年以上の実務経験
💪: 3年未満の実務経験
🎨: 個人開発にて使用

2027年にエンジニアは不要になるのか - 生成AIでオートメーション化するソフトウェア開発とその先

Elm Architectureを参考に、メッセージで駆動する関数型ノベルゲームエンジンを作った

UIライブラリ非依存で、Elm Architecture風に状態管理ができるライブラリを作った

NixOS + Kubernetesで構築する自宅サーバーのすべて

意味から理解するプログラマーのためのMonad入門

ソフトウェアの品質定義と技術的な意思決定

リーダブルな命名はどこからやってくるのか