ちびはむ
chibiham
より良いものを、
「何を
横浜で
主に扱ってきた領域
それぞれの
設計と 仕様
- 認証認可と
APIの 設計関連記事: 認証認可アーキテクチャの変遷(全5回) - 仕様と
議論の 構造化関連記事: 「仕様」の正体 - 設計判断を
残す 仕組み関連記事: 認知的技術的負債
インフラと 運用
- インフラの
構築と コード化関連記事: ECS Fargateで必要なリソースの全体像 - 障害や
性能問題の 調査
プロダクトの 機能
- 決済機能の
組み 込み - マルチテナントの
SaaSと 管理画面
主な技術
TypeScript / React / Next.js / Nest.js / Ruby on Rails / Java (Spring Boot) / AWS / GCP / Terraform / Docker / PostgreSQL / MySQL / Redis
プロジェクトごとの詳細な経験は、お問い合わせいただければお伝えします。
仕事の進め方
前提も、
- 問い何がより良いかを探る。
- 設計変化に応えられる構造へ。
- 実装小さく試し、確かめる。
- 記録学びを次の判断につなぐ。
記録から、また問いへ。考える、つくる、また考える。
得意なこと
混乱した仕様・議論の構造化
こんがらがった要求や停滞した議論を分解し、関係者全員が納得できる形に言語化します。チーム開発の現場で最も頼られてきたのはこの場面です。「仕様とは何か」自体を継続的に考察し、思考を公開しています。
アーキテクチャ設計とトレードオフ判断
唯一の正解がない場面で、要件・チームの状況・運用の制約を踏まえて選択肢の損得を明示し、決め切ります。認証認可アーキテクチャの設計変遷を体系的に整理した連載や、事業会社での決済機能の組み込み・SaaSのAPI設計の経験が土台です。
詰まった問題の突破
原因不明の障害や性能問題を、フロントエンドからインフラまで層をまたいで掘り下げて解決します。粘り強い追求は設計だけでなく、「動かない・遅い・不可解」の解明でこそ発揮されてきました。
知識の仕組み化
設計判断や暗黙知をドキュメント・ADR・ナレッジベースとして残し、チームの認知負荷を下げます。「毎回すり合わせている」状態を負債と捉え、構造として解消するアプローチを実践しています。
ちびはむについて
- 名前の由来
- 「ちびはむちゃん」を高速で言うと「千葉ちゃん」に聞こえる(?)から
- 拠点
- 神奈川県横浜市
- 学んだこと
- 理学部 物理学科
お 仕事のご 依頼・お 問い 合わせ
お仕事のご依頼や、個人開発のアプリ・サービスについて。お仕事のご依頼は、内容やご希望の時期をお書きください。
- フォームに内容を書いて送ってください。
- 入力したメールアドレスに、確認のメールが届きます。
- 内容を確認して、メールでご連絡します。
XのDMでも受け付けています@chibiham_zzz