ID:81981さん

2026年2月回 指名


まだ何もありません

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

  • BASEがID:81981さんのレジュメを見ています。
    2026.02.12
  • LegalOn TechnologiesがID:81981さんのレジュメを見ています。
    2026.02.12
  • LayerXID:81981さんのGitHubを見ました!
    2026.02.12
  • LayerXがID:81981さんのレジュメを見ています。
    2026.02.12
  • エス・エム・エスがID:81981さんのレジュメを見ています。
    2026.02.12
  • キャディID:81981さんのGitHubを見ました!
    2026.02.12
  • キャディがID:81981さんのレジュメを見ています。
    2026.02.12
  • technersがID:81981さんのレジュメを見ています。
    2026.02.12
  • カカクコムがID:81981さんのレジュメを見ています。
    2026.02.12
  • BASEがID:81981さんのレジュメを見ています。
    2026.02.12

キャリアビジョン


責任と判断を構造化する設計エンジニア

## 判断を個人の能力に依存させない構造をつくる 私は、技術単位ではなく「責任と意思決定の流れ」から設計を考えます。 ・誰が判断するのか ・どこで不確実性が発生するのか ・責任が気体化していないか ・属人化せず再現できるか これらを構造として整理し、プロジェクトを安定化させることを主軸にしてきました。 --- ## 実務で担ってきたこと - レガシー資産の構造整理と移行基盤設計 - リリース設計・構成管理プロセスの再設計 - 判断基準の明文化と責任境界の整理 - 手作業依存業務のツール化による安定化 技術スタックは目的達成のための手段であり、 言語やフレームワークの羅列よりも、 「どう構造化し、どう安定化させたか」を重視しています。 --- ## 今後志向する環境 ・判断を引き受ける文化があること ・責任を曖昧にしない設計ができること ・改善が属人化で終わらないこと 構造で議論できる組織でなければ、 本質的な改善は起きないと考えています。 --- ## なぜこのキャリアを考えているか これまでの経験から、実装作業だけではなく、 設計・構成・リリース・運用まで含めて関与し、 属人化を排除し、再現可能な判断構造を設計する立場で価値を出したい 特に、リリース前後の判断や運用設計が不十分なまま進むことで、 本番障害や属人化が発生し、 結果として現場の負担が増えるケースを何度も見てきました。 そのため、目先の作業効率や一時的な成果よりも、 「本番で問題を起こさない設計であるか」 「問題発生時に調査・切り戻し可能な構造であるか」 を判断基準として設計してきました。 属人化や場当たり的な判断で回る体制は、 短期的には成立しても、 中長期的には必ず破綻します。 その歪みを放置せず、 構造として是正することが自分の役割だと考えています。 --- ## 具体的にやりたいこと 具体的には、以下のような役割・取り組みを通じて 価値を出したいと考えています。 - 影響範囲を把握した上での変更判断 - 後続メンバーでも再現可能な運用フローの構築 - 設計・リリース・運用を含めた全体最適の設計 --- ## 実現したい状態 現場で判断を担いながら、 システムやチームが長期的に無理なく回る状態を作り、 構造で問題を潰し続けられる環境で、 設計者として継続的に価値を出し続けたいと考えています。 --- 構造の歪みを見つけ、 設計で是正し、 再現可能な状態にする。 その責任を担う立場で、 継続的に価値を出し続けたいと考えています。

プロジェクト経験

2023年/2年以上

基幹系システム モダナイゼーションプロジェクト

## プロジェクト経験①(レガシー移行/変換基盤・構成管理設計) ### 役割 構造設計/変換基盤整備/構成管理・リリース設計 ### 背景 COBOL→Java移行プロジェクトにおいて、 変換処理が手動確認工程に依存しており、 1案件ごとに再検証・再実行が発生していた。 また、 - 変換結果の状態管理が統一されていない - ログ粒度が揃っていない - 切り戻し判断基準が定義されていない 状態で運用されていた。 --- ### 実施内容 - 変換処理の依存関係整理およびバッチ化 - 実行ログのフォーマット統一と出力標準化 - 成果物単位での状態管理定義(未変換/変換済/検証済 等) - 切り戻し可能なスナップショット設計 - 構成管理ルール・バージョン付与基準の明文化と定着 --- ### 成果 - 変換基盤を仕様変更なしで2年間固定運用可能な状態へ安定化 - 変換工程の再検証頻度を大幅削減 - 構成起因の本番障害 0件を維持 - 個人判断に依存していたリリース可否をルールベースへ転換 --- ### 波及効果 - 不確実性の低減により、チームをリリースフェーズへ再配置可能に - 火消し対応の削減により、設計業務へ工数集中が可能に --- ## プロジェクト経験②(構成管理・リリース設計再構築) ### 役割 構成管理設計/リリースフロー再設計/判断基準整備 ### 背景 複数チームが関与するプロジェクトにおいて、 - バージョン定義の認識差 - リリース単位の不統一 - 変更影響範囲の曖昧さ - 「誰が判断するか」が明確でない状態 が常態化していた。 結果として、 リリース可否判断が個人依存になり、 調整コストと心理的負担が増大していた。 --- ### 実施内容 - リリース単位/依頼単位/デプロイ単位の定義分離 - リリース可否チェックリスト策定(影響範囲/差分/依存確認) - 変更管理フローの図式化と承認ポイント明確化 - ヒアリングシートによる各チーム認識差の可視化 --- ### 成果 - 判断フローの標準化により確認往復回数を削減 - チーム間認識差の構造的解消 - リリース後の想定外手戻りを抑制 - 調整負荷を個人からプロセスへ移行 --- ### 補足 単に「手順を整えた」のではなく、 - 概念の定義 - 判断の責任境界 - 状態管理の整合性 を整理し、 人に依存せず回る構造を設計した。 設計導入後は、 個人が火消し役になる状況を発生させない状態を維持している。

2020年/2年以上

公的金融関連機関向け業務システム開発

## プロジェクト概要 公的金融関連機関向け業務システムの開発・改修案件に参画しました。 金融機関向け制度を支えるシステムであり、 高い正確性・再現性・説明責任が求められる環境でした。 単純な機能追加や改善ではなく、 「変更してよいこと」「変更してはいけないこと」を明確に区別しながら 業務・制度・システムの整合性を保つことが重要なプロジェクトでした。 --- ## 課題・制約条件 - 公的制度に関わるため、仕様変更の影響範囲が非常に広い - 一見すると技術的に改善できそうな点でも、 制度・業務上の理由から変更が許されないケースが多い - 誤った解釈や安易な最適化が、 金融機関・制度全体への影響につながるリスクがあった --- ## 取り組み・判断したこと(自身が行ったこと) - 技術的な正しさだけで判断せず、 業務仕様・制度背景を踏まえた上で 「どこまで手を入れるか」「どこは触らないか」を明確に線引き - 変更を行う場合は、 影響範囲・前提条件・制約を整理した上で実装を進め、 想定外の挙動が発生しないことを重視 - 技術的に改善余地があっても、 制度的リスクが高い箇所については 無理な最適化を行わない判断をした --- ## 成果・得られた価値 - 制度・業務との整合性を維持したまま、システム改修を実施 - 不必要な変更によるリスクを回避し、 安定した運用を継続できる状態を維持 - 技術だけでなく、制度・業務を踏まえた判断が求められる 環境での開発経験を積むことができた

2019年/半年以内

自動運転(ADAS)向け 車載ECU 上流仕様定義案件

## プロジェクト概要 自動運転(ADAS)機能に関する上位要求を解析し、 それを人命を脅かさないシステム仕様として成立させることを目的とした 車載ECU向け上流工程に参画しました。 本案件では実装を前提とした設計ではなく、 「自動運転として何を実現したいのか」という抽象的な要求を、 システムとしてどのような振る舞いをすれば成立するのかを整理し、 安全性を検証しながら仕様書として文章化することが主な役割でした。 --- ## 背景・課題 自動運転機能は、一例としてレーンキープアシストやオートハイビーム、 自動車線変更といった複数の機能が組み合わさることで 自動運転レベル(Tier)を構成します。 しかし、これらの要求は 「こういう運転を実現したい」という抽象的な表現が多く、 そのままではシステム仕様として不十分でした。 特に、 - 各機能がシステムとしてどのように振る舞うべきか - どの条件・状態で機能が有効/無効になるのか - その振る舞いが人命安全の観点で問題ないか といった点を明確に定義しなければ、 実装・検証以前に仕様そのものが成立しないという課題がありました。 --- ## 対応内容(Process) 自動運転に関する上位要求を読み解き、 レーンキープアシストや自動車線変更などの各機能について、 システムとして必要な振る舞いを整理しました。 各機能が - どの入力を受け - どの条件で動作し - どのような状態遷移を行うのか を明確にし、 自動運転レベルを満たすために システムとして何を保証すべきかを検証しながら、 仕様として文章化を行いました。 また、仕様が人命を脅かさないことを前提に、 安全性の観点から矛盾や曖昧さがないかを確認し、 関係者間で認識齟齬が起きないよう整理・明文化を行いました。 --- ## 成果・結果 抽象的だった自動運転要求を、 システム仕様として成立するレベルまで落とし込み、 各機能の振る舞いを明確化しました。 プロジェクト自体は最終的に失注により解散となりましたが、 自動運転という高度かつ人命に直結する領域において、 仕様を安全要件として定義・検証し、 文章として成立させる上流工程の実務経験を得ることができました。

マネージメント能力

このマネージメント能力は公開されていません

アピール項目


アウトプット

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

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

未入力です

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

未入力です

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
サービス・プロダクトへの応用
既存のサービスやプロダクトに生成AI(API利用など)を組み込み、LangChainやLlamaIndexなどのフレームワークを使った開発経験
モデルの構築・研究開発
LLMのファインチューニングや、独自モデルの構築経験

キャラクター

直近で一番やりたいこと
現場にいたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
分析力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
広告 / ファッション / アダルト / 仮想通貨
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きなテキストエディタ
未入力です
希望勤務地
その他地域 / リモート勤務
常時リモートが必要
希望年収
900万円
ご意見箱

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

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

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