yoshiki-0428

あなたを気にしている企業

キャリアビジョン


日本の価値を上げるプロダクトに自身の時間を投資したい

エンジニアとして長く働き続けるためには、 “作る” こと自体が目的ではなく、作ったプロダクトがユーザにどれだけ価値を届けているかまで責任を持てる環境 が必要だと考えています。 要件通りに作るだけではなく、課題の背景・事業の方向性・ユーザの行動を理解した上で、 チーム全体でプロダクトを育てていける文化に魅力を感じます。 その中で、自分ごととして判断し、改善に参加し、プロダクトをより良い方向へ動かすことが、 エンジニアとしての成長にも直結します。 機能追加や改修を「与えられた仕事」ではなく「自分が価値を作る機会」として捉えられる組織でこそ、 ユーザ視点を持ちながら長く熱量を持って働けると考えています。

プロジェクト経験

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

2020年/2年以内

手術用ロボット稼働状況リアルタイム監視ダッシュボードアプリ

# 案件概要 マイクロサービスアーキテクチャで構成されており、医療機器(IoT)からPOSTされるレコードをMessagingAPIでDBに保存をし、保存されたデータをリアルタイムにダッシュボードに表示させ、医療従事者に稼働状況などの監視情報などの価値を提供するシステム開発です。 # 課題解決 ## バックエンド別 ### 1000万レコード以上あるテーブルをサマリーする機能の速度を60秒から0.6秒の100倍にした話 - 1日に1秒間間隔で機器のステータス情報がDBのレコードに保存される仕組みがあり、そのレコードを1日毎、1時間毎でサマリーする機能があった。 - 日時情報を`to_char`関数で変換した値を`Group By`をしており、`レコード量が多ければ多いほど指数関数的にクエリー時間が増える`という課題があり、SQLチューニングし課題解決した - 案件の性質的に`要件定義、設計、実装のフロー`が早く、当時は`とりあえず`の実装になっていた。 - 試行したこと - `to_char`をする項目を増やしその項目に対し、Indexを貼る - 速度は倍になったが、実用でないため`不採用` - `Materialized View`を使用し、1時間毎の集計データをViewに保存し解決 - `100倍になりました。` ### Matelialized Viewの更新を`k8s`のCronJobタスクで自動化 - Materialized Viewは定期的にRefreshが必要であり、以下の方法を模索しコストの低いCronJobタスクで解決をした。 - 対象テーブルのInsertをトリガーにViewを更新する - 1秒間隔でInsertされるため、DBコストが高いため`不採用` - `k8s`のCronJobタスクで指定時間にRefreshコマンドを起動させる - 要件的に更新されるべきタイミングが1日毎だったため`採用` ### 海外タイムゾーンの対応 - 当時の課題 - システムを将来的には日本以外の国で使うことになるため、GMT基準でシステムが組まれていた。 - 課題は、APIとフロントエンド間は `どんな形(日時表示なのかUnixタイムスタンプなのか)`で`誰がローカル時間に変換する役目`を担うのか。 - 試行したこと - バックエンド側でバックエンドのシステムタイムゾーンで変換し日時表示で返却を行う - バックエンドの設定タイムゾーンで日時が変わってしまう。 - (アメリカから日本のサーバにアクセスされると日本時間で返却をしてしまう)国別にサーバを置くことは現実的ではないため不採用 - 取り扱う日時をUnixタイムスタンプにし、サーバ側では完全にUnixタイムスタンプで連携し、フロントエンド側で設定のタイムゾーンで変換を行う。 - フロントに一任することによりブラウザのタイムゾーンが適用されるためコストが少なく、海外タイムゾーン対応が実装できた。 ### SPAとAPI間の認証周りを`SpringCloudGateway`で解決した話 - 案件の認証の仕組み - `AWS Cognito`のような外部認証サービスを使用し`OAuth2`で認証することにより、ユーザログインを行う - 当時の状況 - 認証基盤の実装が`とりあえず`のもので正しく実装されていなかった(固定アクセストークンでシステムにログインをするような状態) - 試行内容 - SpringCloudGatewayという最新のFWの認証を使用しOAuth2の実装を完了(Api-keyやSecret-key、Redirect URLなどの設定情報を記述することで認証周りの処理を行ってくれる) - MicroService的な思想で構成されているため以下のような構成となる - `Front` <=> `SpringCloudGateway` <=> `API (BFF)` <=> `その他API` - 当時あまり日本語の情報がなかったが、GitHubのサンプルコードなどを参考にシステムを構築し解決しました。 ### 画像データ、マスターデータをRedisでキャッシュする対策 - 当時の課題 - APIサーバのリソースは限られており、余分に画像の取得などでリソースを無駄に使用していた - 解決内容 - 画像データやマスターデータを取り持つためにRedisでテキストデータで保存し、余分なリクエストを減らすことができた ## フロントエンド別 ![](https://www.optim.co.jp/wp-content/uploads/20201026_optim_1.png) ### 医療機器の3Dモデルをリアルタイムに動かすことができる`DigitalTwin`(手術ロボット)の稼働部分をThree.jsのAnimationでリアルタイムに動かす - 当時の課題 - TypeScript用のサンプルコードが少なく、Three.jsをリアルタイムで動かすという実装をしている人が少なかった - 解決内容 - 別チームに3Dモデルの作成、パーツごとの動きの設計をしてもらい、MessagingAPIで受け取ったパーツ動作情報をThree.jsに当てはめ、リアルタイムに動く機能を実装した。 - Animationクラスがリアルタイムの動きに対応していないので、別でWrapするクラスを作成し解決した。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

主にAIプロダクトの開発チーム(正社員2名・業務委託4名)を技術リードとしてマネジメントしていました。 具体的には、技術選定・アーキテクチャ設計・開発方針の策定、タスク分解、コードレビュー、仕様調整、開発プロセス整備(トランクベース開発、型共有基盤など)を担当し、チーム全体が同じ方向を向いて開発できる環境づくりを行っていました。
責務: チーム全体が自律的に開発へ取り組み、プロダクト価値を継続的に高められる状態をつくること 状態: AIプロダクト特有の仕様変更や不確実性に対応しながら、メンバー全員が背景・目的を理解し、迷わず判断できる状態 * **目的・背景が共有され、全員が同じ方向を向いて意思決定できる状態** * **仕様変更に強く、試行錯誤を前提にした柔軟な開発体制が維持されている状態** * **FE/BE の認識差がなく、共通の言語と基盤で開発できる状態** * **正社員・業務委託を問わず、自走しやすいタスク理解・仕様理解が可能な状態** * **プロダクト内外のメンバーが同じ情報源を見て、共通認識を持てる状態(Docusaurus によるドキュメント公開や NotebookLM による仕様理解支援)** * **スピードと品質を両立できる、安定したチームコンディション**
AIプロダクトは仕様変更が多く、不確実性の高い領域であるため、 「メンバー全員が背景理解を揃え、自律的に判断できるチームでなければ継続的な価値提供は難しい」 という前提に立ってチームづくりを行いました。 特に、属人的な判断や情報非対称が積み重なると、開発スピードと品質が同時に失われるため、 **仕組みで認知負荷を下げ、自律的に動ける環境をつくる**ことを軸に考えていました。 --- ## **① 設計背景が共有されず、判断が属人化していた問題への対応** 当初は、設計の意図や技術判断の理由(ADR)が明文化されず、 「なぜこの構成なのか?」が人に依存している状態でした。 新規メンバーや業務委託メンバーは背景理解が追いつかず、判断待ちが多発していました。 ### **→ 工夫:Docusaurus による設計ドキュメント整備とレビュー文化の定着** * すべての設計・方針・技術判断を Docusaurus に集約 * コードと同じリポジトリで管理し、常に最新化 * 意思決定前にドキュメントをレビューする流れを定着させ、背景を共有したうえで判断できる文化に変革 結果、判断基準が全員で統一され、認識齟齬が劇的に減りました。 --- ## **② 顧客との仕様認識がずれやすく、非エンジニアとの橋渡しに負荷がかかっていた** 行政や顧客との合意内容をエンジニアが解釈しなおす必要があり、仕様解釈の差が頻繁に生まれていました。 非エンジニアが仕様の前提を理解できないことも多く、会議のたびに説明が必要でした。 ### **→ 工夫:NotebookLM による“仕様検索”の仕組み化 + Figma / 仕様書の一元管理** * 顧客との仕様書・ドキュメント・Figma を NotebookLM に読み込ませ、自然言語でいつでも確認できる状態に * 会議前に各自で仕様確認できるため、議論の前提が揃う * 「これは仕様にあった?」「どの画面?」などの質問を AI に任せ、コミュニケーション負荷を削減 開発外メンバーとの橋渡しが圧倒的に楽になり、仕様理解のスピードが向上しました。 --- ## **③ トランクベース開発を“実際に運用できる文化”として浸透させるのに苦労した** AIプロダクトは試行錯誤が多いため、本来は小さなPRを高速に統合するトランクベースが適しているのですが、 従来のフローに慣れたメンバーは大きめのPRを出しがちで、文化として根付いていませんでした。 ### **→ 工夫:小さなPRの “意味” を繰り返し共有し、具体的なサンプルを提示して文化醸成** * 「なぜ小さく出すのか」「なぜ高速統合が必要なのか」を日々説明 * 理想的なPRのサンプルを作り、真似しやすい土台を用意 * 小さな成功体験をつくり、徐々にチームの当たり前として定着させた 結果、「小さく早く作る」スタイルが自然と回るようになっていきました。 --- ## **④ 別プロジェクトでは BE の OpenAPI 生成と FE 開発の速度が合わず、開発が停滞** BE のAPI設計が進むスピードと、FEが追随するスピードに差があり、 「API仕様の更新待ち」がボトルネックとなっていました。 特にAIサービスでは小さな仕様変更が頻発するため、FE側が遅れやすい状況が生まれていました。 ### **→ 工夫:完璧な後方互換より、97% の安定性と開発スピードを優先する意思決定へシフト** * エッジケース 3% のために開発全体が止まる状況を避けるため、スピード優先の基準を明確化 * まずユーザ体験に必要な大枠を固め、後続で微調整する運用へ * FE/BE の同期コストを軽減し、PM・デザイナーを含めた“意思決定のスピード”を改善 これにより、プロジェクト全体の開発リズムが整い、価値提供の速度が大きく改善しました。

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Zenn アカウント
あり
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

LLM の信頼性向上や評価基盤(RAG 評価、LLM 評価)をより深く扱える技術を身につけたいです。 大規模分散処理やストリーミング基盤など、AI プロダクトのスケールを支える基盤技術にも取り組みたいです。 安全な AI 運用を支えるセキュリティ・プライバシー領域(LLM セキュリティ)の知見も強化したいと考えています。

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

- 自律的に技術選定や設計を任され、少人数で高速に開発する環境です。 - 課題が曖昧でも、要件整理から基盤構築まで一気通貫で進められる場が得意です。 - 新規プロダクトをゼロから設計し、継続改善できる文化のチームで最も力を発揮します。

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
会社のブランド・知名度
やりたくない分野
金融
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと

# ✅ **その他のやりたいこと**

**AI・RAG・インフラ領域の深掘り**
LLM/RAG パイプライン、AI 評価基盤、インフラ(GCP・IaC)のような、
**AI プロダクトを事業レベルで支える技術**をさらに伸ばしたいです。

**新規プロダクトの立ち上げにも関わること**
ゼロイチで SaaS を形にしていく慌ただしさとスピード感が好きで、
変化の激しい初期フェーズで「どう作るか・何を作らないか」を決める工程にやりがいを感じます。

**長期運用を見据えたアーキテクチャ設計**
場当たり的ではなく、”数年後も運用できる基盤” を構築することに興味があります。
技術選定・方式設計・RAG 学習基盤など、アーキテクチャに関わりたいです。

**チームプロセスづくりへの関与**
トランクベース開発や型安全な仕組みづくり等、
**チーム開発の再現性を高めるプロセス整備**にも取り組みたいです。

**最適なチームサイズ**
5〜8 名程度の、小さすぎず大きすぎないチームで、
自律したメンバーと建設的に開発を進める環境が最も力を発揮できます。

# ❌ **やりたくないこと(避けたい環境)**

**「開発は依頼しておけばいいや」という軽視文化**
技術を対等に尊重し合えない環境や、
開発を下請けのように扱う文化とは相性が良くありません。

**意思決定が極端に遅い組織**
AI・SaaS などスピードが求められる領域では、
決裁が遅いプロセスはプロダクト価値に直結するため避けたいです。

**技術負債に対して感情的にネガティブな態度**
技術負債は当時の最善の選択であることが多く、
「適切に向き合い必要なところを改善する」という健全な姿勢を持つ組織で働きたいです。

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代前半
好きなテキストエディタ
Windsurf, IntelliJ, WebStorm
希望勤務地
東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
950万円
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?