ID:83962さん

## プロジェクト経験概要 新規企画された自動精算機、およびクライアントごとのカスタマイズ案件における、UI（ユーザーインターフェース）の開発と、レシート等の印字物のレイアウト要件定義からカスタマイズ・実装までを担当。前任者からの引き継ぎ直後から参画し、2名という少数精鋭の体制の中、バックエンド担当者と緊密かつ効率的に連携しながら、各種案件を完遂しました。 ## チーム情報 * **役割:** メイン開発者（フロントエンドUI実装およびレイアウトカスタマイズ全般を担当） * **体制:** 全2名（バックエンド開発者1名、自身1名） ## 決済状況に連動する動的なUI画面の開発 ### 【概要】 新規企画された自動精算機における、エンドユーザー向け操作画面（UI）の開発。 ### 【どのような機能の開発・実装か】 現金・クレジットカード・QRコード決済など、複数の決済手段や進行ステータスに応じて、画面遷移や案内アナウンスをリアルタイムに切り替える動的なUI画面の実装。 ### 【課題・問題点】 開発メンバーが「バックエンド1名、フロントエンド（自身）1名」の計2名しかおらず、各自の担当領域の実装に集中する必要がありました。そのため、互いの進捗や仕様変更に伴うコミュニケーションコストを可能な限り削減し、いかに手戻りなくスピーディーに開発を進めるかが大きな課題でした。 ### 【打ち手・使用した技術】 * **密なコミュニケーションに依存しない「インターフェースの早期合意」**: 実装に入る前の段階で、バックエンド担当者と画面遷移に必要なAPIのデータ構造を厳格に定義・合意しました。 ### 【成果】 * バックエンド担当者と「最低限かつ要点を押さえたコミュニケーション」のみで、認識のズレによる手戻りをゼロに抑えました。 * 互いの開発スピードを最大化させた結果、当初の予定よりも前倒しで画面開発を完了させることができました。 ## レシートレイアウトカスタマイズ ### 【概要】 精算完了時に出力されるレシート・領収書等の印字物に関するレイアウトの要件定義とカスタマイズ実装。 ### 【どのような機能の開発・実装か】 クライアントごとの多様な要望に応じた印字内容・レイアウトの仕様を定義し、既存の印字エンジンをベースにカスタマイズ・修正を行う業務。 ### 【課題・問題点】 クライアントごとに要望（レシートに載せたい項目や文字サイズなど）が多岐にわたるため、バックエンド側から送られてくるデータの項目と、画面側で定義するレイアウトデータのマッピング（紐付け）の考慮漏れが発生しやすい状態でした。また、文字数が多い場合の自動折り返しなど、実機での見た目の調整において、バックエンド側との細かな仕様の調整が頻繁に発生する懸念がありました。 ### 【打ち手・使用した技術】 * **レイアウト要件定義の仕組み化**: バックエンドから届く決済データのフォーマットを先回りして把握し、「どのデータが、レシートのどの位置に、どう印字されるか」の対応表（マッピング定義）を事前にバックエンド担当者と明確にすり合わせました。 ### 【成果】 * 要件定義の段階でデータ構造のすり合わせを徹底したため、実装時のデータ不整合による手戻りがなくなり、効率的なレイアウト量産が可能になりました。 * 2名体制というリソース制限の中でも、クライアントごとの細かな要望を1つずつ正確に反映し、品質の高い印字カスタマイズを安定してリリースできました。

## プロジェクト経験概要 POSシステムに蓄積された売上データを、顧客企業が指定する任意のフォーマットに変換して提供するための「コンバーターWebAPI」の開発を担当。ドキュメント化されていなかった既存DBの複雑な計算ロジックを自ら読み解き、営業担当者を介して顧客の要望を正確に仕様へ落とし込み、設計から実装・テストまでを単独（1人）で自走して完遂しました。 ## チーム情報 * **役割:** 単独開発者（要件定義、仕様解析、設計、実装、テストまでを全般的に担当） * **体制:** 自身1名（要件の調整役として営業担当者が数名） ## 既存POSデータの複雑な計算ロジックの解析と要件定義 ### 【概要】 顧客企業へ提供するための、売上データの抽出・変換仕様の定義。 ### 【どのような機能の開発・実装か】 POSシステム特有の複雑なデータ構造（値引き、返品、消費税の端数処理、複数店舗の合算など）を正確に把握し、顧客が求めるデータ形式と1対1で整合性が取れるようにマッピング・計算ロジックを定義する業務。 ### 【課題・問題点】 既存のDB構造や計算方法に関する詳細な仕様書が整備されておらず、コードを自力で読み解く必要がありました。また、営業担当者が持ち帰る顧客の要望（「こういうデータがほしい」）と、実際のDBから抽出可能なデータ構造の間にギャップがあり、そのまま実装するとデータの不整合が発生するリスクがありました。 ### 【打ち手・使用した技術】 * **リバースエンジニアリングによるロジックの可視化**: 既存のDBスキーマや過去のソースコードを徹底的に解析し、ブラックボックス化していた売上計算ロジックをドキュメント（または仕様定義シート）として可視化しました。 ### 【成果】 * 仕様が可視化されたことで、営業担当者も顧客への提案がスムーズに行えるようになり、リリース後の修正も迅速に対応できた。 ## 柔軟なデータ変換を行うコンバーターWebAPIの開発 ### 【概要】 解析したロジックをベースに、リクエストに応じてデータを変換・出力するWebAPIの実装。 ### 【どのような機能の開発・実装か】 DBから高速にデータを抽出した上で、顧客指定のデータ形式に変換してレスポンスを返すAPIの実装。 ### 【課題・問題点】 POSの売上データは非常に大容量であり今後の顧客ごとのフォーマット追加に柔軟に対応できる拡張性も求められました。 ### 【打ち手・使用した技術】 * **拡張性を意識した設計の導入**: データ変換部分を共通のインターフェースとして切り出し、新しいフォーマット要望が来ても、既存のコアロジックを修正することなく「変換モジュール」を追加するだけで対応できる設計にしました。 ### 【成果】 * 保守性の高い設計にしたことで、今後別の顧客から同様のカスタマイズ要望が来た際にも、**数日程度で迅速に新規フォーマットを横展開できる基盤**を構築できました。

# プロジェクト経験：POSシステム設定ツールのリファクタリングおよびインターフェース設計 ## プロジェクト経験概要 既存POSシステムにおける、50以上の設定機能を持つ設定ツールのリファクタリングプロジェクトに参画。各機能の基本設計書を読み解き、バックエンドとの新たなデータ連携（インターフェース）の設計から、実装、単体テストまでを一貫して担当。膨大な機能群に対して正確かつ効率的なリファクタリングを繰り返し実施し、システムの安定性向上に貢献しました。 ## チーム情報 * **役割:** メイン開発者（設計書の確認、インターフェース設計、実装、テストの全般を担当） * **体制:** 6名（適宜、既存仕様の確認等でバックエンド担当者と連携） ## 開発・実装内容A：50種以上の設定機能における基本設計の読み解きとインターフェース設計 ### 【概要】 肥大化・複雑化していた既存設定ツールと、バックエンドシステムを繋ぐインターフェース（API仕様やデータ構造）の再設計。 ### 【どのような機能の開発・実装か】 店舗情報、メニュー、消費税、端末設定など、50箇所以上ある各種設定機能ごとに基本設計書を参照し、バックエンド側と不整合が起きないようなデータのやり取り（Request/Response）を新たに定義・設計する業務。 ### 【課題・問題点】 対象となる設定機能が50以上と非常に多く、機能ごとに基本設計書のフォーマットや情報の粒度にバラつきがありました。また、各機能を個別に設計・実装していくと、データの受け渡しルールがバラバラになり、全体のコードが再びスパゲッティ化（複雑化）してしまう懸念がありました。 ### 【打ち手・使用した技術】 * **インターフェースパターンの共通化と標準化**: 50以上の設定機能を観察し、データ通信における共通パターン（「設定取得」「設定更新」「バリデーションチェック」など）を共通インターフェースとして抽象化。これにより、機能ごとにつどゼロから設計するのではなく、標準化された共通ルールに則ってスムーズに設計を進められる仕組みを作りました。 * **バックエンド担当者との認識の早期同期**: 設計段階で共通のインターフェース仕様を固め、設計書ベースでバックエンド側とすり合わせを徹底することで、実装フェーズでの手戻りを最小限に抑えました。 ### 【成果】 * 共通化されたインターフェース設計により、設計段階での手戻りや考慮漏れを未然に防ぎ、50以上の機能を一貫した設計ポリシーで整流化できました。

# プロジェクト経験：自動精算機のリファクタリングおよび後継機種の新規プロダクト開発 ## プロジェクト経験概要 既存の自動精算機のリファクタリングプロジェクト、およびその設計を踏襲した次世代後継機種の新規プロダクト開発に従事。先代機種の開発を通じて蓄積したシステム全体の深いドキュメント・ドメイン知識を武器に、後継機種開発ではUI側の詳細設計から実装、アドホックテストに加え、UI・バックエンドを横断した不具合調査と修正まで、領域を限定せず幅広く担当しました。 ## チーム情報 * **役割:** メイン開発者（詳細設計、実装、テスト、クロスドメインの不具合解析・修正を担当） * **体制:** 全7名（バックエンド、フロントエンド開発者含む) ## 開発・実装内容A：先代の知見を活かした次世代後継機種のUI詳細設計および実装 ### 【概要】 同一系設計（アーキテクチャの踏襲）による、新機種に向けたUIアプリケーションの新規開発。 ### 【どのような機能の開発・実装か】 先代機種で挙がっていた課題やユーザーの操作性を改善しつつ、新しいハードウェア（筐体）や新機能に対応した操作画面の詳細設計、および実装。 ### 【課題・問題点】 「同一系設計」とはいえ、新機種に伴う新たな要求仕様が加わるため、既存の共通ロジックをベースにしながら、いかに破綻させずに新機能を組み込むかが課題でした。また、7名のうち自動精算機プロダクトに関わったことあるメンバーが私を含めて2名という体制で新規開発を進めるため、設計段階から実装・テストを見据えた「手戻りのない精密な設計」が強く求められました。 ### 【打ち手・使用した技術】 * **ドメイン知識を活かした詳細設計（使用技術：c++、go）**: 先代機種のリファクタリング時に把握した「バグが起きやすい箇所」や「拡張性のボトルネック」を考慮し、新機種のUIコンポーネント設計においては密結合を避け、機能ごとに独立性の高い構造へ落とし込みました。 * **網羅的なアドホックテストの実施と品質の担保**: 仕様書通りのテストだけでなく、自動精算機特有の「ユーザーの予期せぬ画面連打」や「決済途中のキャンセル」など、実機でのイレギュラーな操作パターンを想定したアドホックテストを自ら計画・実行し、潜在的なバグを徹底的に潰しました。 ### 【成果】 * 先代機種の資産を最大限活かしつつ、拡張性の高いUI基盤を構築したことで、プロダクトの知見が少ないメンバーが多いながらスケジュール通りに新規プロダクトのUI実装を完遂しました。 ## 開発・実装内容B：UI・バックエンド領域を横断した高度な不具合調査と修正 ### 【概要】 開発中およびテストフェーズにおいて発生した、システム全体の不具合（バグ）の解析と原因究明・修正対応。 ### 【どのような機能の開発・実装か】 画面の表示異常や、バックエンドとの通信エラー、決済ステータスの不整合など、再現性の低いバグや原因が特定しにくいトラブルに対してログやコードを解析し、修正を行う業務。 ### 【課題・問題点】 自動精算機はハードウェア、UI、バックエンドが複雑に連動しているため、不具合が発生した際に「どこに原因があるのか」の切り分けが非常に難しいという課題がありました。特に開発者が互いの領域を「自分の担当外だから」と突き返していては、原因究明に多大な時間を要するリスクがありました。 ### 【打ち手・使用した技術】 * **フルスタックな視点でのログ・コード解析**: 自身の担当（UI）だけに閉じこもらず、先代機種の全体知識を活かしてバックエンド側のソースコードやAPIの通信ログ、データベースの内部状態まで自ら潜って調査しました。 * **原因の早期特定とバックエンド担当者との協調修正**: 「UI側の考慮漏れ」「バックエンド側のデータ構造の不備」など、バグの根本原因と証拠をソースコードベースで突き止め、バックエンド担当者とスムーズに連携して最小限の時間で修正パッチを適用しました。 ### 【成果】 * 領域を限定しない自走的な不具合調査により、バグの調査から修正完了までのリードタイムを大幅に短縮。 * UI・バックエンド双方の品質を底上げし、プロダクト全体のリリース前品質の劇的な向上に貢献しました。

# プロジェクト経験：病院向け自動受付後払い登録機（後継機種）の開発およびUIチームリード ## プロジェクト経験概要 病院向け自動受付後払い登録機の後継機種開発プロジェクトにおいて、UI開発チームのリードを担当。バックエンドとのインターフェース設計や、協力会社を含む開発メンバーのマネジメント、タスク管理、コードレビューを主導。自身もプレイングマネージャーとしてフロントエンド実装を担当し、スケジュール通りのリリースと高いプロダクト品質の両立を実現しました。 ## チーム情報 * **役割:** 開発リーダー兼UIメイン開発者（メンバーマネジメント、インターフェース設計、コードレビュー、一部実装） * **体制:** UIチーム全体で約5名（社内メンバー2名、協力会社エンジニア2名） ## 開発・実装内容A：複数ベンダーが参画する混成チームのマネジメントとコードレビュー ### 【概要】 UI開発チームにおける、社内外メンバーの進捗・タスク管理、および実装品質の担保。 ### 【どのような機能の開発・実装か】 要件定義に基づいてタスクを分解・配分し、協力会社を含む複数のエンジニアの実装をハンドリング。成果物に対してコードレビューを行い、設計ポリシーの統一や不具合の早期検出を行う業務。 ### 【課題・問題点】 協力会社のエンジニアや社内メンバーなど、スキルセットや得意領域が異なるメンバーが混在していたため、コードの品質や設計方針にバラつきが生じるリスクがありました。また、病院向けの登録機は個人情報や決済機能に関わるため、バグやセキュリティの脆弱性を徹底的に排除しなければなりませんでした。 ### 【打ち手・使用した技術】 * **厳格なコーディング規約の整備**: 開発着手前に、共通のコーディング規約や設計テンプレートを用意。初めて参画された協力会社の担当者の方がスムーズに参入できる準備を整えた。 * **手戻りを防ぐ2段階コードレビューの実施**: まずは「設計・コンポーネント構成」の段階で方向性を合意し、その後「実装完了」のタイミングでコードレビューを行う2段階のプロセスを採用。協力会社のエンジニアとの認識齟齬を最小限にし、手戻り工数を削減しました。 ### 【成果】 * 実装のバラつきを抑え、リリース前のテストフェーズにおける**UIバグの発生率を最小限に抑制**。 * 協力会社の開発スピードを最大化させ、混成チームながら予定通りのマイルストーンをすべて達成しました。

# プロジェクト経験：外食向け自動精算機（後継機種）開発におけるスクラムマスターおよびPM ## プロジェクト経験概要 外食向け自動精算機の後継機種開発プロジェクトにおいて、UIとバックエンド、QAとの連携開発を担うスクラムチームにスクラムマスター（SM）として参画。チーム内のアジャイルプロセスの定着・自走化を支援しつつ、要件定義のサポートや、スクラム外のプロジェクトマネジメント（ステークホルダー調整、期日管理）を統合的に担当し、高難度なプロダクト開発の円滑な進行を実現しました。 ## チーム情報 * **役割:** スクラムマスター兼プロジェクトマネージャー * **体制:** スクラムチーム全体で約15名（プロダクトオーナー1名、自身1名、開発メンバー13名） ## 開発・実装内容A：スクラムプロセスの導入とチームのベロシティ（開発生産性）向上 ### 【概要】 UI・バックエンド、QA連携開発チームに対する、スクラム開発プロセスの導入、定着、および継続的改善。 ### 【どのような機能の開発・実装か】 スクラムイベント（プランニング、デイリー、レトロスペクティブなど）の設計・ファシリテーション、およびチームの進捗（スプリントベロシティ）を阻害する障害の排除・改善活動。 ### 【課題・問題点】 UIとバックエンドという異なる領域の連携部を開発しつつ、QAによる品質確認を進めら必要があり、互いのタスク依存関係が見えにくく、スプリント（開発期間）の後半に「バックエンドの実装が遅れてUIのテストができない」といったボトルネックが頻出していました。また、初期段階ではアジャイルやスクラムの作法への習熟度にバラつきがあり、見積もりの精度が低いという課題がありました。 ### 【打ち手・使用した技術】 * **依存関係の早期可視化とスプリントプランニングの改善**: タスクの依存関係を早い段階でカードやカンバンツール（[miro,Redmineなど]）上でマッピングし、スプリントの開始前に「どの順番で連携APIの合意をすべきか」をチームメンバー間で対話するプロセスを確立しました。 * **対話型のレトロスペクティブ（ふりかえり）による課題改善**: 「KPT」などのフレームワークを活用し、「なぜ遅れたか」を他責にするのではなく、「どうすればチームとして早くテスト環境を整えられたか」という解決策（Action）をメンバーから自発的に引き出すファシリテーションを行いました。 ### 【成果】 * スプリントを繰り返すごとにチームのベロシティが安定。タスクの見積もり精度が向上し、**ベロシティのスコアも当初の3倍まで向上**させました。 * メンバー間で技術領域を超えたサポートが自然と生まれる自走型チームへと成長させました。 ## 開発・実装内容B：スクラム外のプロジェクトマネジメントおよび要件定義サポート ### 【概要】 アジャイル開発チームの外部に存在するステークホルダー（営業、ハードウェア担当など）との調整、および要件定義のサポート。 ### 【どのような機能の開発・実装か】 スクラムチームが開発に集中できるよう、外部との仕様調整、期日・全体スケジュールの進捗管理、および抽象的な「外食店舗向け要件」をスクラムのバックログ（開発要件リスト）に落とし込むための要件定義サポート業務。 ### 【課題・問題点】 開発チームは「スプリント単位での柔軟なアジャイル開発」を求めていた一方、ビジネスサイド（営業やクライアント）やハードウェア（筐体開発）チームは「全体のリリース期日や、確定した仕様」を求めるウォーターフォール型の動きをしていたため、開発プロセスと期日のギャップによるコンフリクト（対立）が起きやすい状態でした。 ### 【打ち手・使用した技術】 * **アジャイルとウォーターフォールのギャップを埋めるバッファ＆マイルストーン管理**: 全体スケジュールから逆算した「マイルストーン」を明確にしつつ、スクラム側には「今スプリントでどこまで終わればリスクが低いか」を翻訳して落とし込みました。 * **プロダクトオーナー（PO）と連携したユーザーサクセスの言語化**: 抽象的な要望を、「ユーザーはレジでどんな体験をしたいのか」というユーザーストーリーとして定義。要件定義の不確実性を下げてからスプリントに投入することで、開発中の仕様揺れによる手戻りを排除しました。 ### 【成果】 * 外部ステークホルダーとのコンフリクトをゼロに抑え、ハードウェアの筐体開発スケジュールとも完全に同期して「外食向け自動精算機」の新規リリースを完遂。 * 「技術チームが今何を作っているか」「何が遅れているか」を非技術者であるステークホルダーにわかりやすく開示・レポーティングし、プロジェクト全体の透明性を劇的に高めました。

# プロジェクト経験：自動荷積みフォークリフトにおけるリアルタイムセンサー・ミドルウェアの開発 ## プロジェクト経験概要 トラックへの自動荷積みを行う自律型フォークリフトシステム開発において、各種センサーから得られる大容量のリアルタイムデータと、車両の走行・リフト動作といった物理的な制御アクションを遅延なく正確に連動させるための「コアシステム」の実装・最適化を担当。ハードウェアとソフトウェアの境界におけるミドルウェアレイヤーの開発を行いました。 ## チーム情報 * **役割:** ミドルウェア開発メインエンジニア * **体制:** 全4名（wcs開発者1名、車両制御開発者2名、ミドルウェア開発者2名(自身と前任者)） ## 開発・実装内容A：ROS 1からROS 2への移行および通信ミドルウェアのリファクタリング ### 【概要】 システムの近代化と信頼性向上を目的とした、ROS 1からROS 2への通信ミドルウェア層の全面リファクタリング。 ### 【どのような機能の開発・実装か】 LiDARや各種センサーデータ、WCSからの指示、車両の制御アクションなどを仲介するミドルウェアにおいて、ROS 1ベースだったノード群、トピック通信、およびサービス通信をすべてROS 2（rclcpp）ベースへと移行・再設計する業務。 ### 【課題・問題点】 社内にROS 2の知見を持つ有識者が一人もいない完全な手探りの状態でした。自身にとってもROSおよびROS 2は未経験の領域であり、ドキュメントの読み込みから実装プロセスの確立まで、すべてを単独でインプットしながら進める必要がありました。 ### 【打ち手・使用した技術】 * **ROS/ROS 2の体系的な自己インプットと概念実証（PoC）**: 公式ドキュメントや最新の技術論文、オープンソースのコミュニティ情報などを自ら徹底的に読み解き、ROS 2の内部アーキテクチャを体系的に学習。本実装に入る前に、最小構成での通信デモ（PoC）を構築し、ROS 2の動作特性やROS 1との差異を身を以て検証・理解しました。 ### 【成果】 * 社内にノウハウがない状況から、**独力でのキャッチアップと検証を重ね、ROS 2への全面リファクタリングをトラブルなく完遂**。 * **自身が社内初の「ROS 2有識者」**となり、得られた知見や移行手順をドキュメント化して社内へナレッジシェアできる基盤を作りました。

# プロジェクト経験：開発本部におけるエンジニア採用・育成・定着推進（組織活性化プロジェクト） ## プロジェクト経験概要 開発本部内におけるエンジニアの採用加速および育成早期化を目指し発足した「組織活性化チーム」の初期メンバーとして参画。採用フェーズにおける母集団形成（スカウト）から、カジュアル面談・インターンシップ対応、入社後の技術研修（基礎講座の講師）、そして入社後のメンター（定期1on1）までを一貫して担当し、エンジニア組織の拡大と組織定着に大きく貢献しました。 ## チーム情報 * **役割:** 組織活性化推進リーダー（採用・育成・メンター業務全般を牽引） * **体制:** 全4名（部長、課長、事務員、エンジニア(私自身)） ## 開発・実装内容A：エンジニア採用プロセスの推進とカジュアル面談・スカウトアプローチ ### 【概要】 エンジニア採用におけるスカウトアプローチから選考・カジュアル面談の実施、およびインターンシップの企画・講師。 ### 【どのような機能の開発・実装か】 各種スカウトサービスを用いた求職者のレジュメ選定とアプローチ文章の送付。カジュアル面談において、開発現場のリアルな雰囲気や技術スタックを魅力的に伝えるエバンジェリストとしての役割、およびインターンシップの技術講師。 ### 【課題・問題点】 人事担当者のみのスカウトでは、技術的なバックグラウンドがマッチする優秀なエンジニアへ心に刺さるアプローチができず、返信率が伸び悩んでいました。また、カジュアル面談においても、求職者の技術的な興味に踏み込んだ対話ができず、本選考（面接）への移行率をいかに高めるかが課題でした。 ### 【打ち手・使用した技術】 * **エンジニア視点でのパーソナライズド・スカウトの実施**: 人事と密に連携し、候補者のGitHubやQiita、ブログ等のアウトプットを自身で詳細に確認。「なぜあなたに声をかけたのか（技術的な共感ポイント）」を文面に盛り込む、徹底したパーソナライズスカウトを行いました。 * **技術的な興味に寄り添うカジュアル面談の設計**: 一方的な会社説明ではなく、求職者のこれまでの経験や「今後挑戦したい技術」をヒアリングし、自社でそれがどう実現できるかを技術的な観点から具体的にイメージ例を提示する面談スタイルを確立しました。 ### 【成果】 * スカウトの返信率が向上し、本選考への移行率・内定承諾率の向上に直接的に貢献。 * カジュアル面談の満足度を引き上げ、会社の「技術的な認知度」を社外に広める役割を果たしました。 ## 開発・実装内容B：新卒・未経験向け技術研修（育成）および入社後の定着メンター（1on1） ### 【概要】 配属された新卒および未経験メンバーを早期戦力化させるための教育体制の構築と、定着（リテンション）支援。 ### 【どのような機能の開発・実装か】 エンジニアとしての基礎知識（Git、DB、Webの基礎、開発プロセスなど）を網羅した研修プログラムの構築および講師としてのレクチャー。入社後の定期的な1on1ミーティングを通じた技術的・精神的なサポート。 ### 【課題・問題点】 新卒や未経験メンバーが配属された際、現場のプロジェクトごとに教育コストの負担が偏っており、体系的な教育ドキュメントが不足していました。また、配属後の環境変化により、新メンバーが孤立感や不安を抱きやすく、定着率（エンゲージメント）の維持が課題となっていました。 ### 【打ち手・使用した技術】 * **実践的なエンジニア基礎講座のロードマップ策定**: 単なる座学ではなく、「実際に手を動かしてAPIを作成し、プルリクエストを出してレビューを受ける」といった、現場の実際の開発フローに即した実践的なオリジナル研修コンテンツを開発し、自ら講師を担当しました。 * **心理的安全性を担保した定期1on1の実施**: 新卒・中途全社員を対象に1ヶ月、3ヶ月、半年、1年のタイミングで、30分程度のメンター1on1を仕組み化。技術的な課題（コードの書き方や設計の悩み）の解消だけでなく、キャリアプランの相談やチーム内での人間関係のケアを積極的に行い、心理的安全性を高めました。 ### 【成果】 * 未経験・新卒メンバーが**配属後、想定よりも早い段階で実際のプロジェクトへ貢献（実開発へのアサイン）**できるレベルまで自立を加速させました。 * 丁寧なメンタリングにより、担当した社員の**早期離職率を極めて低く抑え**、組織全体のエンゲージメント向上に貢献しました。