bobtabo

# プロジェクト経験概要 二次流通プロダクト「Selloop」の一環として、千趣会との共創サービス「kimawari（キマワリ）」の内製化プロジェクトを主導。 VPoE兼一人目エンジニアとして、kintoneによる既存運用からの脱却と、独自システムへの刷新、および開発組織の構築を完遂。 # チーム情報 - 役割: 開発責任者（VPoE）兼 一人目エンジニア - 体制: 私（バックエンド全般、アーキテクチャ設計、採用）、ディレクター1名、インフラ2名、デザイナー2名、運用2名、Biz 4名 # 開発・実装内容A ## 【概要】 - 一人目エンジニアとしてシステム全体のアーキテクチャ設計を主導。 - プログラムの実装については、以下のコンポーネントすべてを独力で完遂した（※デザイン・インフラ構築は専門メンバーが担当） - 3つの主要Webアプリケーション（ユーザー / クライアント / スタッフ向け） - 業務の核となるバッチ処理群 - 独自Laravelパッケージ（3サイト + バッチ横断のアプリケーション基盤） ## 【どのような機能の開発・実装か】 - 共通アプリケーション基盤の開発: 各サイトの vendor 配下にインストールして利用するLaravelパッケージを独自開発。 - クロスドメインな設計: ユーザー、クライアント、スタッフという異なる役割を持つ3システム間で、データの流れやクラス設計を一貫させるための基盤提供。 ## 【課題・問題点】 - プロダクト継続性の危機: - 開発開始から半年で、プロダクト責任者を含むBiz側メンバーが相次いで離脱。 - Webプロジェクト未経験のBizメンバー1名と自身のみという体制になり、プロダクトの定義や方向性を維持することが極めて困難な状況に陥った。 - ナレッジの属人化と分散: - 3サイト間で共通する複雑なビジネスロジック（査定・申込フロー等）を、少人数の開発体制で品質を落とさず、かつ整合性を保ちながら実装し続ける必要があった。 ## 【打ち手・使用した技術】 - プロダクト視点での開発リード: - Biz側の知見不足を補うため、エンジニアの枠を超えてプロダクト視点での要件定義・UI設計・意思決定を自身が主導。 - ドキュメント化（DB設計、ワイヤフレーム、仕様書）を徹底し、メンバー離脱によるナレッジの欠落を防いだ。 - PHP 8.2 / Laravel 10: - 一人での開発スピードを最大化しつつ、後の「エンジニア採用のしやすさ」という市場性を考慮して選定。 - DDD（ドメイン駆動設計）の導入: - 共通言語としてDDDを採用し、ビジネスルールを明確に定義。 - これにより、後のエンジニア採用時にもスムーズなオンボーディングが可能な土壌を作った。 - 独自Laravelパッケージによるロジック共通化: - 「1箇所の修正で全サイトに反映させる」という保守効率の最大化を狙い、共通ドメインロジックをカプセル化したパッケージを構築。 - リフレクション等を駆使し、3サイトのデータの流れを高度に抽象化したクラス設計を実施することで、開発リソースが限られた状況下での生産性を極限まで高めた。 - ブルー/グリーンデプロイ: - ローンチ後の頻繁な機能改善を前提とし、ダウンタイムを最小化しつつ安全にリリースできるCI/CD環境を構築。 - 技術スタック - 開発環境：Mac / Docker / PhpStorm - 言語、フレームワーク：PHP 8.2.x / Laravel 10.x / JavaScript / JQuery - インフラ：AWS / ALB / ECS / Fargate / Aurora / ElastiCache / CloudFront / S3 / QuickSight / Athena / SES / WAF など - CI/CD：GitHub Actions / CodeDeploy - 構成管理：CloudFomation / Terraform - 監視：CloudWatch / Datadog - バージョン管理：GitHub - タスク管理：Backlog - コミュニケーション：Slack - ドキュメント：Notion / Google Workspace / miro / Figma / draw.io など ## 【成果】 - 定量的成果: - 立ち上げメンバーのほぼ全員が離脱するという危機的状況下でも、2024年2月に3サイト同時リリースを実現。 - 4月には**月間申込数2万件（従来比約2倍）**を達成。 - 定性的成果: - VPoEとして、技術選定からビジネス側の穴埋め、その後の正社員採用立ち上げまでを一人で完遂。 - 最終的に自分以外のオリジナルメンバーが不在となってもサービスを継続・成長させられる、極めて高い堅牢性を持つアーキテクチャと組織基盤を証明した。 --- # 開発・実装内容B ## 【概要】 - 内製化を円滑に進めるための、親会社からの独立したAWS環境の構築および、決済（法人カード導入）の整備。 ## 【どのような機能の開発・実装か】 - インフラ環境の独立化: - 親会社のインフラ部による制限を排し、自社で迅速にリソース操作が可能なAWSアカウントの新規取得と環境構築。 - 決済運用の適正化: - AWS利用料等の支払いのための法人クレジットカード導入の推進。 ## 【課題・問題点】 - 運用の高コスト化: - 当初は親会社のAWS環境を間借りする予定だったが、設定変更のたびに親会社のインフラ部への申請が必要であり、0→1開発におけるスピード感を著しく阻害するコストとなっていた。 - 不適切な決済手段とリスク: - 法人カードが存在せず、AWS利用料（月額100万円超）を「銀行振込（経理コスト大）」または「エンジニア個人の仮払い（多大な心理的・経済的負担）」で対応せざるを得ない状況だった。 - 別グループ会社では社員が月160万円を仮払いしているという、ガバナンス・リスク管理上の重大な課題が発覚した。 ## 【打ち手・使用した技術】 - 独立したAWSアカウントの取得: - 開発スピードと自由度を担保するため、親会社との議論を重ね、所属先独自のAWS環境構築へと舵を切った。 - 法人カード作成の主導: - 「コスト削減」と「エンジニア保護（リスク回避）」の観点から、経営・経理層へ働きかけ、法人カードの作成を自らコミット。 - 技術者が技術に集中できる「当たり前の環境」を組織的に整備した。 ## 【成果】 - 定性的成果: - 入社後の最優先課題として法人カード作成とAWS独立環境を完遂。 - これにより、外部組織への申請待ち時間をゼロにし、アジャイルな開発体制を確立した。 - 組織への貢献: - 開発組織だけでなく、会社全体の決済基盤の適正化に貢献。 - VPoEとして、技術領域に留まらず、事業を推進するための組織的なボトルネックを解消する「当事者意識」を証明した。 --- # 開発・実装内容C ## 【概要】 ITリテラシーの乖離があるステークホルダー間の合意形成と、リファラルによる開発ラインの早期立ち上げ。 ## 【どのような機能の開発・実装か】 - プロジェクト・マネジメント: - プロダクトの実現可能性（Feasibility）の担保と、開発工程の可視化。 - 採用・チームビルディング: - 自身のネットワークを駆使した、信頼できる初期開発メンバーの選定とアサイン。 ## 【課題・問題点】 - 非現実的な要求とリテラシーの壁: - 「kintoneで運用中サービスがあるから、すぐ内製化できる」「3ヶ月でリリースしたい」といった、Web開発の構造を度外視した無理な要求が常態化していた。 - 開発資産の不在: - kintone運用はソースコードの流用が効かないため、実質的に完全な「0→1開発」をゼロから設計・実装する必要があった。 ## 【打ち手・使用した技術】 - 定量的データに基づく交渉（WBS/工数算出）: - 「無理」と否定するだけでなく、全タスクを洗い出しWBSを作成。 - 「概算20人月」という具体的な数字と根拠を提示することで、経営陣・ステークホルダーと現実的なリリーススケジュールの合意を取り付けた。 - テクニカル・エバンジェリズム: - Webサービス開発プロセスを丁寧にレクチャーし、「積み上げの技術」であることを理解させた。 - リファラル採用の活用: - 採用媒体に頼る時間的猶予がない中、自身の元同僚へ直接声をかけ、技術力と信頼関係が担保されたメンバーを招集。 - 最短ルートで「戦えるチーム」を作った。 ## 【成果】 - 定性的成果: - 無謀なスケジュールによるプロジェクトの破綻を未然に防ぎ、健全な開発サイクルを確立。 - 組織への貢献: - 技術的知見が皆無だった組織において、エンジニアリングの標準的なプロセス（設計、WBSによる見積もり、適切な体制構築）を定着させた。 --- # 開発・実装内容D ## 【概要】 - 開発速度向上を目的としたエンジニア採用要件の定義および、経営層との期待値調整。 ## 【どのような機能の開発・実装か】 - 組織スケーリングの戦略策定: - 開発スピードを最大化するための最適な採用スペックの定義。 - 技術経営・交渉: - 開発リソースの増員が生産性に与える影響についての合意形成。 ## 【課題・問題点】 - 人数と速度の単純比例という誤解: - プロジェクト中盤、経営層より「エンジニアの人数を増やせば、その分だけ開発速度が数倍に上がるはずだ」という、ソフトウェア開発の特性を度外視した増員要求を受けた。 - コミュニケーションコストの増大リスク: - 無計画な増員は、既存メンバー（当時は自分一人）の教育・調整コストを爆発させ、逆に開発速度を低下させる「ブルックスの法則」に陥る懸念があった。 ## 【打ち手・使用した技術】 - 「エンジニアの質」を重視した採用基準の策定: - 単なる人数合わせではなく、即戦力となるための具体的な技術スタック（Laravel/AWS等）と、自律的に動けるシニアレベルのスペックを言語化。 - 論理的なリスク説明: - 「エンジニアの質によって速度アップの幅は変動すること」「不適切な人材を採用した場合、コミュニケーションコストが増大し、かえって速度ダウンを招くリスク（ハズレの際の実害）」を率直に提示。 - VPoEとしての期待値コントロール: - 経営層に対し、追加人員が立ち上がるまでのリードタイムを含めた現実的な生産性向上のシミュレーションを共有し、理解を得た。 ## 【成果】 - 定性的成果: - 経営層に「エンジニアリング組織における採用の難易度とリスク」を正しく認識させた。 - これにより、質を妥協した無理な採用を回避し、結果として開発クオリティと進捗の安定を維持した。 - 組織基盤の確立: - 後の正社員採用立ち上げ時に、一貫した「質の高いエンジニア」の採用基準を適用できる土壌を構築した。 --- # 開発・実装内容E ## 【概要】 - サービス成長と継続性を担保するためのエンジニア正社員採用の立ち上げと、スタートアップのフェーズに適した選考プロセスの構築。 ## 【どのような機能の開発・実装か】 - 採用戦略・プロセスのフルスクラッチ構築: - 採用責任者として、ターゲット定義、求人メディア選定、選考フロー設計、面談実施までを牽引。 - 技術経営・採用市場の適合性定義: - COO・PdM への市場価値に基づく給与レンジの適正化および、選考体験の最適化。 ## 【課題・問題点】 - 「一人目エンジニア」への過度な依存: - アプリ設計・実装を独力で完遂したことで、周囲に「一人で大丈夫」という誤認が広がり、事業継続上の重大なリスクであるワンオペ体制が固定化されそうになっていた。 - 市場感と乖離した非現実的な採用要件: - COO、PdMから、年収レンジは「400〜700万円」「年収600万で単独でプロジェクトを完遂できる30代前半」という無名スタートアップとしては不可能な要望が提示されていた。 - 知名度の低さに伴う選考離脱リスク: - 大手や有名企業と同じ選考プロセスを模倣することによる、候補者の離脱や採用スピードの低下が懸念された。 ## 【打ち手・使用した技術】 - 市場データに基づく「現実」の提示と予算交渉: - 30代前半エンジニアの希少性と市場価値を説き、年収レンジを「500〜800万円」へ引き上げることを主導。 - 単なる予算増ではなく、経営に対し「質の高い人材を確保するための投資」としてコミットした。 - 選考体験の最適化（書類選考スキップ）: - 採用スピード向上と差別化のため、スカウトからカジュアル面談を経て応募に至った場合は、書類選考をスキップするフローを導入。 - 大手や有名企業とは異なる柔軟な対応で、優秀な層への接触率を高めた。 - 期待値調整によるコーディングテスト実施: - 離脱率上昇を予測しPdMと議論。 - 最終的に「テスト結果で採否を決めず、面談時の技術ディスカッションの話題にする」という折衷案で、候補者の負担とPdMの要望をバランスさせた。 - リファラル採用への戦略的シフト: - 自身のネットワーク（元同僚等）への直接のアプローチを並行して実施。 ## 【成果】 - 定性的成果（組織知の獲得）: - コーディングテストによる予測通りの離脱率上昇を受け、**「無名スタートアップにおける初期採用はリファラルが最良である」**という戦略的結論を組織に定着させた。 - VPoEとしての意思決定: - 経営層に「エンジニアリング組織における採用の難易度とリスク」を正しく認識させ、エンジニアを事業成長のパートナーと捉える文化を構築した。 - 事業継続リスクの可視化: - ワンオペの危険性を指摘し、たとえ公募結果がゼロであっても、リファラルを含む多角的な採用チャネルの重要性を証明した。 --- # 開発・実装内容F ## 【概要】 - 技術的制約の極めて強い外部配送システム（佐川EDI）との連携において、本番環境に依存せず徹底した品質検証を可能にするための「仮想・佐川EDI」の設計・開発。 ## 【どのような機能の開発・実装か】 - 配送連携自動化の実現: - SFTP経由での集荷依頼CSV送信、および固定長データでの荷物状況（受託・集荷・配完）の自動取り込み。 - 「仮想・佐川EDI」の開発: - AWS Transfer Family、ECS Scheduled Tasksを活用し、佐川側の挙動（ファイル移動、ステータスに応じた返却ファイル生成）をスタブで再現する擬似サーバーの構築。 ## 【課題・問題点】 - 検証環境の不在と制約: - 佐川EDIにはサンドボックス環境が存在せず、テストと本番が同一環境という極めてリスクの高い仕様だった。 - 本番モード移行後はテスト送信ができず、弊社側のDev/Staging環境での継続的な結合テストが物理的に不可能な状況だった。 - 現代開発との乖離: - 通信回数制限（1時間に1回）、固定長データ、REST APIの不在など、自動化とスケーラビリティの妨げとなる制約が山積していた。 - 人材のミスマッチ: - 外部の業務委託エンジニアではこの複雑な制約に対応できず、設計・実装が完全に停滞していた。 ## 【打ち手・使用した技術】 - 仮想化によるリスクの局所化: - 佐川側の本番環境に接続せずとも開発を完遂できるよう、佐川の挙動を模倣した**「仮想・佐川EDI」**を自ら設計。 - AWS Transfer Family / ECS: - インフラチームと連携し、SFTPサーバーをAWS上に構築。 - ECS Scheduled Tasksを用いて、送信されたCSVを解析し、DB上の申込内容に基づいた「貨物返却ファイル」を動的に自動生成するロジックを実装した。 - インターフェースの共通化: - 本物の佐川EDIと仮想・佐川EDIを、.envファイルの切り替えのみで透過的に扱えるように設計し、テスト容易性を確保した。 ## 【成果】 - 定性的成果: - 「本番環境でしかテストできない」という致命的な詰み状況を、自作のスタブ基盤により解消。 - 開発期間中に何度でも配送シナリオをテストできる環境を提供し、ローンチ後の佐川連携におけるクリティカル障害をゼロに抑えた。 - 組織的成果: - 不可能と思われた外部制約を技術力でねじ伏せ、プロジェクトを前進させた。 - この実績は、「技術でビジネスを止めない」というリードエンジニアとしての信頼を盤石なものとした。

# プロジェクト経験概要 買取申込・査定機能をモジュール単位で外部提供するプラットフォーム構想の立ち上げ。 VPoE兼アーキテクトとして、拡張性と再利用性を最大化した技術戦略の策定および、リファラルによる開発体制の構築を主導。 （※要件定義が一段楽ついた頃、経営方針の変更により、ペンディングとなる） # チーム情報 - 役割: 開発責任者（VPoE）兼 アーキテクト - 体制: 私（技術戦略）、PdM 1名（自身の人脈からアサイン）、Biz 3名（経営コンサル・企画等） # 開発・実装内容A ## 【概要】 - 外部提供を前提としたモジュール型プラットフォームのアーキテクチャ方針設計と技術選定。 ## 【どのような機能の開発・実装か】 - プラットフォーム基盤設計: - クライアント企業のサービスに組み込める「買取申込」「査定」機能のモジュール化。 - 技術選定: - 将来的な高負荷、組織拡張、採用の難易度を多角的に考慮した技術スタックの定義。 ## 【課題・問題点】 - 多角的なトレードオフの解消: - 0→1開発のスピードを維持しつつ、プラットフォームとしての高い拡張性と、将来的なメンテナンスコストの抑制を同時に実現する必要があった。 - 開発コストの最適化: - ゼロからの構築でありながら、スピード感を持って要件を形にするための効率的なインフラ構成が求められた。 ## 【打ち手・使用した技術】 - リファラルによる即戦力PdMのアサイン: - 自身のネットワークから、信頼の置ける専任PdMを業務委託で招聘。 - 技術戦略の指針のみを自身がコントロールし、詳細な推進を委任する体制を作ることで、プロジェクトの停滞を防いだ。 - Go言語（バックエンド）の戦略的採用: - 以下の3つのロジックに基づき、言語を選定。 1. 高トラフィックへの対応: - プラットフォームとして将来的な外部提供を見据えた際、高いスループットと並行処理能力が不可欠と判断。処理速度に定評があるGoを選択した。 1. 採用市場における優位性: - 当時の技術トレンドとして「モダンな開発環境」を提示することで、エンジニアからの注目度を高め、無名スタートアップにおける採用難易度を下げる狙い。 1. 既存リソースの最大活用: - 立ち上げ初期の開発メンバー内にGo経験者が2名在籍しており、学習コストを抑えつつ、設計の質を担保した状態で最速でローンチできる現実的な選択肢であった。 - インフラ構成の再利用（ECS/Fargate）: - 既存の「kimawari」プロジェクトで検証済みのAWS構成（Terraform管理）を流用。 - インフラ設計の工数を削減し、アプリケーション開発にリソースを集中させた。 - 技術スタック - 開発環境：Mac / Docker / JetBrains IDE - フロントエンド：React / Next.js / TypeScript / Tailwind CSS - バックエンド：Go / フレームワーク検討中 - インフラ：AWS / ECS / Fargate / Aurora / ElastiCache / WAF など - CI/CD：GitHub Actions / CodeDeploy - 構成管理：Teraform - 監視：CloudWatch / Datadog - バージョン管理：GitHub - タスク管理：Backlog ## 【成果】 - 定性的成果: - 自身がボトルネックになることを回避し、技術とビジネスの橋渡しが円滑に行われる体制を構築。 - VPoEとして、個人の技術力に頼らずに「プロジェクトを動かす仕組み」を短期間で作り上げた。

# プロジェクト経験概要 クレジットカード情報流出インシデント（約80万件）を受けた、第三者機関の指摘に基づく決済代行管理基盤の全面刷新。 PCI DSS再審査合格を至上命題とし、「負の遺産」が積み重なったレガシー環境からの脱却と、モダンな開発・運用体制への移行を指揮。 # チーム情報 - 役割: 開発マネージャー 兼 シニアエンジニア - 体制: - 部長（要件定義）: 決済・金融領域で20年以上のキャリアを持つ業務のスペシャリスト。 - 私（計画・技術選定・開発統括）: 技術面の責任者として、レガシー刷新の戦略と実行を指揮。 - エンジニア3名（正社員1名、業務委託2名） # 開発・実装内容A ## 【概要】 - 「職人芸」と「コピペ」で構築されたカオスなソースコードの資産管理正常化と脆弱性対策。 ## 【どのような機能の開発・実装か】 - バージョン管理体制の確立: - ファイルサーバー管理・本番直接編集という運用を廃止し、GitHubベースの開発フローへ移行。 - 緊急セキュリティパッチ適用: - PCI DSS審査基準を満たすため、PHP7.4/FuelPHP1.8.2への緊急アップデートを完遂。 ## 【課題・問題点】 - ガバナンスの完全な欠如: - ソースコードがファイルサーバーに置かれ、デプロイは「サーバーへの直置き」や「本番ファイルの直編集」が常態化。 - 変更履歴を追うことが不可能な状態だった。 - 「サンコイチ」構造の複雑怪奇な設計: - 3つのサイト（1つは外注、2つは非エンジニアがコピペで構築）が、1つのFuelPHPフレームワークをシンボリックリンクで共有して稼働。 - 一箇所の修正が予期せぬ範囲に影響を及ぼす、極めてリスクの高い構成だった。 - 仕様を把握する人物の不在: - 「サンコイチ」構造を作り上げた非エンジニアの担当者が既に故人となっており、社内にシステムのロジックや背景を理解している人間が一人も存在しなかった。 ## 【打ち手・使用した技術】 - GitHub移行とCI/CDの布石: - まず「誰が、いつ、何を変えたか」を可視化するため、ファイルサーバーからGitHubへ全資産を移行。 - 直接編集を禁止する運用ルールを徹底した。 - 環境の分離と標準化: - フレームワークをシンボリックリンクで共有する不健全な依存関係を解体し、サイトごとに独立した環境で管理・デプロイできる構成へと整理した。 - 専門性を活かした役割分担の徹底: - 決済代行という極めて高い業務知識（ドメイン知識）が求められるリプレイスにおいて、自らが要件定義を抱え込むのではなく、決済・金融一筋20年のプロである部長に要件定義を依頼。 - これにより、技術側（自分）は「20年もののレガシーコードの解体」や「GitHub移行によるガバナンス構築」といった技術的難題の解決に100%注力できる体制を構築した。 ## 【成果】 - 定性的成果: - 「誰も触れず、誰も全貌を知らない」という事業継続上の最大のリスクを解消。 - 組織が管理可能な「エンジニアリングの資産」へと引き戻した。 - PCI DSS審査への貢献: - 不透明だったシステム構造を透明化することで、第三者機関による厳格なセキュリティ審査に耐えうる状態を作り上げた。 --- # 開発・実装内容B ## 【概要】 - PHP8対応を見据えた、フレームワーク選定（Laravelへの転換）と段階的リプレイス計画の策定。 ## 【どのような機能の開発・実装か】 - 次世代技術スタックの選定: - FuelPHPの継続利用を断念し、Laravel 9への全面移行を決定。 - サステナブルな移行ロードマップの作成: - 業務停止リスクを最小化する段階的なリプレイス計画の立案と実行。 ## 【課題・問題点】 - フレームワークの限界: - FuelPHPのままではPHP8への追従が困難（コアファイルを直接修正するしか手段がない）であり、将来的なセキュリティリスクとメンテナンスコストの増大が明白だった。 - スキルの属人化: - 非エンジニアが構築した箇所を含め、ソースコードのブラックボックス化が進んでおり、単純なアップデートでは対応できない領域が多大だった。 ## 【打ち手・使用した技術】 - Laravelへのフルリプレイス決断: - 「今動いているものを直す」のではなく、将来的な採用市場性（エンジニアの確保しやすさ）とエコシステムの恩恵を考慮し、PHP 8.1 / Laravel 9 への刷新を決断。 - 段階的移行（Strangler Fig Pattern的アプローチ）: - 一気に全てを入れ替えるのではなく、機能単位で段階的に新システムへ移行する計画を策定。 - 業務委託メンバーへのスムーズな引き継ぎ体制を構築した。 ## 【成果】 - 定性的成果: - 会社の命運を左右するPCI DSS再審査合格に向けた道筋を確定。 - 技術経営的成果: - 「コピペで動くシステム」から「設計思想に基づいたプロダクト」へと転換させることで、将来的な機能拡張とセキュリティ担保のスピードを劇的に向上させた。 --- # 開発・実装内容C ## 【概要】 有休消化中に発生した、未経験者の無許可操作による本番障害の調査・収束と、再発防止策としてのアクセス管理徹底。 ## 【どのような機能の開発・実装か】 - 障害調査・事後対応: - 退職前の有休消化中に発生した本番環境停止の緊急調査と復旧。 - 技術的統制の再構築: - 「誰でも本番環境に触れる」という極めて危うい運用体制の抜本的改善。 ## 【課題・問題点】 - 採用基準の不一致によるリスクの顕在化: - 部長判断で採用された「運用保守経験のみの未経験層」がチームに混在。 - スキルセットが本プロジェクトの難易度に達しておらず、開発からは外していたものの、本番環境への物理的なアクセス権限が残っていた。 - 「やってみたい」という安易な動機による本番操作: - 引き継ぎで伝えた「GitHubからのプル」という手順を、検証環境と誤認して本番環境で無許可で実行。 - デプロイ後のパーミッション設定漏れにより、決済管理機能が完全に停止する重大な障害が発生した。 ## 【打ち手・使用した技術】 - フォレンジック的調査の実施: - 有休消化中であったが緊急対応し、サーバー上の操作ログとデプロイの形跡から、障害原因が「無許可のGitプル」であることを特定。 - アクセス権限の厳格化とワークフローの導入: - 再発防止のため、該当エンジニアをサーバー立ち入り禁止処分とし、全てのエンジニアに対して**「本番アクセスには部長（または責任者）の事前承認を必須とする」**という厳格な統制を敷いた。 ## 【成果】 - 定性的成果: - 属人的かつ善意（好奇心）による本番障害のリスクを身をもって組織に示し、「本番環境は聖域である」というエンジニアリングの規律を再徹底させた。 - 組織防衛: - 本番環境への不用意な立ち入りをシステム・ルールの両面から制限することで、自身の退職後も同様の事故が発生しないための安全策を講じた。

# プロジェクト経験概要 20年間にわたり外部委託されていた自社決済システムの全面刷新。 「特定個人（68歳ベンダー）への完全な依存」という、事業継続上の致命的なリスクを解消すべく、ソースコードの奪還と管理体制の正常化を指揮。 # チーム情報 - 役割: 開発責任者（マネージャー）兼 シニアエンジニア - 体制: - 前半（〜6ヶ月）: - 私、社長、取締役、社内協力者（他部署のマネージャー、テックリード） - 後半（6ヶ月〜）: - 私、新部長（決済専門家）、ディレクター1名 - エンジニア3名 - 業務委託（2名）: - SES会社の社長（決済領域のスペシャリスト）および、同社のエンジニアメンバー。 - 高度なドメイン知識を活かした設計・実装を担当。 - 正社員（1名）: - 他チームで戦力外通告を受け、総務部預かりとなっていたメンバー。 - 部長の打診により、エンジニアとしての再教育を目的に私の配下へアサイン。 - 既存開発ベンダー1名（68歳・個人事業主／仕様の独占者） - ※契約上は大手SIerを介在させていたが、実態はリバースエンジニアリングによるドキュメント作成のみで、開発の全権と仕様は個人ベンダーが握っている状態だった。 # 開発・実装内容A ## 【概要】 「ベンダーロックイン」の解消とソースコード資産の回収。 ## 【どのような機能の開発・実装か】 - ソースコード管理の正常化: - 68歳の個人ベンダーの自宅PCにのみ存在した最新ソースコードを回収し、GitHubへ移行。 - 開発フローの構築: - Eclipseビルドされたclassファイルの差分をサーバーへ手動配置する「20年前のデプロイ方式」を廃止し、モダンなCI/CDの土台を構築。 ## 【課題・問題点】 - 「剥がしたくても剥がせない」依存構造: - システム仕様の全てが68歳の個人ベンダーの頭の中にしかなく、会社としてベンダーを交代させることが不可能な「詰み」の状態にあった。 - SIerの形骸化: - 大手SIerは契約上の窓口に過ぎず、仕様を把握していないため、トラブル発生時に誰も対応できないリスクがあった。 - 資産管理の崩壊: - 最新のソースコードが社内には存在せず、ベンダーの自宅PCでしか管理されていないという、金融基盤として極めて危険なガバナンス欠如が常態化していた。 - ビルドツール（Ant/Maven等）も未使用で、再現性のある環境構築が不可能だった。 - ベンダーのリテラシーギャップ: - 開発の鍵を握る68歳のベンダーはGit未経験であり、移行に対する心理的・技術的ハードルが極めて高かった。 ## 【打ち手・使用した技術】 - 対人スキルを駆使したソースコード回収: - 仕様を握る高齢ベンダーを否定して反発を招くのではなく、敬意を払いながら「万が一の際の保全」という名目で、Eclipse + EGitのマニュアルを自作してレクチャー。 - 3ヶ月かけて、自宅PCからGitHubへの資産移行を完遂させた。 - ブラックボックスの可視化: - ベンダーが「ドキュメントを書かない」ことを前提とし、大手SIerがリバースエンジニアリングした資料と、自身による1,800ステップの生Javaコードの読み解きを突き合わせ、仕様を「組織の資産」として再定義した。 ## 【成果】 - 定性的成果: - 「特定個人への依存（Bus Factor 1）」という経営上の最大リスクを解消。 - ベンダーを「剥がせない」状況は維持しつつも、万が一の際に会社が自力で修復・継続できる「資産のコントロール権」を取り戻した。 --- # 開発・実装内容B ## 【概要】 5年計画のリプレイスロードマップ策定と新アーキテクチャ設計。 ## 【どのような機能の開発・実装か】 - モノリスの解体: - 10種の決済機能が密結合したモノリシック構成を、機能単位で独立して開発・デプロイ可能なマイクロコンポーネント構成へ再設計。 - ハイブリッド構成の採用: PHP (Laravel) と Java (Spring Boot) を使い分け、ライブラリの制約をクリアしつつ開発生産性を高める方針を策定。 ## 【課題・問題点】 - 技術的負債の極致: - 15年前のライブラリや、HTTPセッションにエンティティを詰め込んで引き回す設計、JSP内のスクリプトレットの嵐など、改修そのものが高リスクな状態だった。 - 大規模障害の発生: - Javaアップデートに伴う原因不明のメモリリークに対し、Tomcatの定期再起動で凌ぐという極限の運用環境下で、抜本的な解決（リプレイス）が急務だった。 ## 【打ち手・使用した技術】 - 現実的なリプレイス戦略の策定: - WBSに基づき、5年という長期スパンでの段階的移行計画を立案。 - まずは影響範囲が限定的かつ重要な「Pay-easy決済」を先行リプレイス対象とし、早期の成功体験（クイックウィン）を狙った。 - モダンなスタックへの投資: - AWS (ECS, Aurora, Lambda等) と Docker をベースとした、スケール可能で保守性の高いインフラ・実行基盤への刷新を設計した。 - 技術スタック - 既存構成 - プライベートクラウド / Linux / Oracle / Java / JSP - 新アーキテクチャ方針 - AWS（ECS / Aurora PostgreSQL / ElastiCache / Lambda など） - PHP（Laravel）＋ Java（Spring Boot）による分離構成 - Dockerベースの開発・実行基盤 【成果】 - 定性的成果: - インシデント発生（Yahoo!ニュース掲載）という最悪の状況下で、経営層に対し「場当たり的な対応ではなく、未来の成長を担保する技術戦略」を提示し、予算と合意を取り付けた。 --- # 開発・実装内容C ## 【概要】 リーダーシップの空白期間における「政治的・技術的舵取り」。 ## 【課題・問題点】 - 入社初月のトップ不在: - 自分をスカウトした部長が入社月に退職。 - 決済ドメイン知識がなく、かつ仕様を隠蔽するベンダーが存在する中、半年間、直属の上司がいない状態でプロジェクトを推進せざるを得なかった。 ## 【打ち手・使用した技術】 - ステークホルダーの再定義: - 部長不在の期間、社長・取締役と直接対話し、「ベンダーロックインの危険性」をビジネスリスクとして説くことで、リプレイスの正当性を担保し続けた。 - ベンダーとの絶妙な距離感の維持: - 仕様を握るベンダーを「排除すべき対象」ではなく「リプレイスを成功させるためのリソース」として扱い、リプレイス計画（Pay-easyの先行刷新など）への協力を取り付けた。 ## 【成果】 - 定性的成果: - 新部長が着任した際に、即座に実装・実行フェーズへ移行可能な「精度の高いリプレイス計画」と「経営層の合意」を整えて引き継いだ。 --- # 開発・実装内容D ## 【概要】 他部署で「戦力外」とされたメンバーの最終評価（再起判定）および、開発組織の品質管理。 ## 【どのような機能の開発・実装か】 - 人材評価・育成ジャッジ: - 部長よりアサインされた、toCチームを「干された」正社員メンバーに対する、エンジニアとしての適正判定と再教育の試行。 - 技術コミュニケーションの標準化: - 68歳の外部ベンダー向けGitHub移行マニュアルの作成を通じた、ドメイン知識の言語化・手順化。 ## 【課題・問題点】 - 定性的な「戦力外」判定の検証: - 前チームからは「クリエイティブではない」という抽象的な理由で排除されていたが、具体的な欠陥が不明確であり、「再生可能か否か」の最終判断を下す必要があった - 極めて高い要求水準のドキュメント作成: - ターゲットが「20年前の技術で止まっている68歳の高齢エンジニア」であり、最新のWikiツールを排した「Word/PDF形式」かつ「一歩も迷わせない圧倒的な具体性」を持つマニュアルが求められた。 ## 【打ち手・使用した技術】 - 「ユーザー視点」を問う実務試験のアサイン: - 高齢ベンダーへのGitHub移行支援をタスクとして与え、以下の能力を測定。 - ターゲットへの共感力: - Notion等のモダンツールを避け、相手の環境に合わせた形式を選択できるか。 - 再現性の担保: - スクショの質、手順の網羅性、名称の整合性など、システム開発の基本である「緻密さ」があるか。 - フィードバックとリテイクの実施: - 散々な成果物（レイアウト崩れ、名称の乖離、視認性の低さ）に対し、改善の機会を何度も与え、向上心の有無を確認。 【成果】 - 定性的成果（組織防衛）: - 1ヶ月の試行の結果、**「全体を俯瞰する能力の欠如」と「クオリティに対する妥協」**がシステム開発において致命傷になると判断。 - 本人の自覚も確認した上で、1ヶ月で総務部へ戻すという決断を下し、開発チームの品質低下を未然に防いだ。 - 基準提示: - その後、自ら1週間で完璧なマニュアル（リハーサル済みの手順書）を完成させ、ベンダーのGitHub移行を成功させた。 - これにより、組織に対し「エンジニアが追求すべきプロフェッショナリズムの基準」を背中で示した。

# プロジェクト経験概要 大規模ECサイト「SHOPLIST.com」の検索チームにて、表示速度改善施策を主導。 **「1,200テーブル規模の巨大モノリス」「10年超のレガシーコード」**という極めて難易度の高い環境下において、バックエンド側からパフォーマンス最適化を遂行した。 # チーム情報 - 役割: バックエンドエンジニア - 体制: プランナー2名、フロントエンド 1名、バックエンド 3名（私含む） # 開発・実装内容A ## 【概要】 - 大規模レガシー環境における表示速度改善（WebP化）。 - サイト全体の画像フォーマットWebP化による、データ転送量の削減。 ## 【どのような機能の開発・実装か】 - WebP配信基盤の改修: - 自社フレームワーク上の検索一覧表示ロジックを改修し、動的なWebP画像呼び出しを実装。 ## 【課題・問題点】 - 技術的負債の極致: - テーブル数1,200超、10年ものの巨大モノリスであり、ソースコード内にSQLがベタ書きされ、一つのメソッドが850ステップに及ぶなど、微小な改修がシステム全体に波及しかねない極めて脆い構造だった。 - 情報の断片化: - 社内Wiki（Confluence等）が存在せず、仕様が大量のGoogleスライドに散在。 - ドキュメントから正解を導き出すことが困難な環境だった。 ## 【打ち手・使用した技術】 - コード解読と安全な実装: - 密結合したレガシーコードを読み解き、既存のJPG/PNG配信を維持しつつ、モダンブラウザに対してWebPを優先配信するロジックを、影響範囲を最小限に抑えて組み込んだ。 - 技術スタック - AWS、Apache、MariaDB、PHP7.4、自社フレームワーク、GitLab、Vagrant、PhpStorm ## 【成果】 - 定量的成果: - 画像データサイズの30〜50%削減に成功。 - 大規模トラフィック環境下でのページ読み込み速度（LCP）を改善し、UX向上に寄与。 --- # 開発・実装内容B ## 【概要】 入社直後からの全方位的なシステム診断と、中長期的な抜本改善案の提示。 ## 【課題・問題点】 - 採用時とのギャップ: - 求人票の「PHP/Laravel」という記載に対し、実態は保守限界を迎えた自社フレームワーク。 - 自身のスキル（DDDやモダンな開発フロー）が活かせない環境であることを早期に察知した。 ## 【打ち手・使用した技術】 - 抜本的なリプレイス案の提示: - 場当たり的な改修の限界を指摘し、マイクロサービス化や最新環境への刷新を提言。 - 単に「できない」と言うのではなく、技術的負債がビジネスに与えるリスク（採用難、保守コスト増）を言語化して伝達した。 ## 【成果】 - 定性的成果（プロ意識の証明）: - 「エンジニアとして得るものがない」と判断した際、自身の市場価値を毀損させないために早期に身を引くという決断を下した。 - この「技術に対する誠実さ」と「判断の速さ」は、後のVPoEとしての組織構築における「採用基準の厳格化」という強い信念の礎となっている。

# プロジェクト経験概要 国内最大手プラットフォーム企業からの新規受託案件。 社内にJava経験者が不在という状況下、唯一の経験者として、退職前の3ヶ月間で「Javaによるバックエンド基盤の設計」と「持続可能な開発体制の確立」を完遂。 自社の実績作り（国内最大手プラットフォーム企業案件）という経営的価値を技術面から支え、後続メンバーへ確実にバトンを繋いだ。 # チーム情報 - 役割: バックエンドリーダー（社内唯一のJava経験者） - 体制: マネージャー1名、アプリエンジニア3名、マークアップ1名、バックエンド3名（私含む） # 開発・実装内容A ## 【概要】 PHP主体の組織において、Javaによる高品質なバックエンド開発を可能にするベース構築。 ## 【どのような機能の開発・実装か】 - バックエンドの雛形（ベース）構築: - 退職後の開発継続を見据えた、Spring Boot 2 / DBFlute を用いた堅牢なAPI/DB基盤の設計。 ## 【課題・問題点】 - 技術リソースの極端な偏り: 「国内最大手プラットフォーム企業案件」という会社にとって極めて重要な実績になる受託であったが、社内にJavaの実務経験者が自分しかおらず、かつ自身の退職が3ヶ月後に迫っているという、極めてリスクの高い状況だった。 - 品質と継続性の両立: - 自分の退職後、Java未経験者や後任の業務委託が開発を引き継ぐ際、品質を落とさず、かつ迷わずに実装を進められる「仕組み」を作る必要があった。 ## 【打ち手・使用した技術】 - 「誰が書いても品質が保たれる」アーキテクチャ設計: - DBFlute等のツールを活用し、型安全かつ冗長なコードを排除できる開発フローを定義。 - ドキュメントと実装の同期: - 退職後に「なぜこの設計にしたのか」が不明確にならないよう、設計意図をコードとドキュメントの両面に残し、属人性を最小化させた。 - 技術スタック - 発注元プライベートクラウド / MySQL8.0 / Java11 / SpringBoot2 / DBFlute / Dozer / MyBatis Migrations / Gradle / Vonage Video API / GitHub / Docker / IntelliJ IDEA ## 【成果】 - 定性的成果: - 「退職前の3ヶ月」という限られた期間で、後続メンバーが迷わず機能開発を継続できるJava開発の土台（ベース）を完成。 - 会社にとっての重要案件を、自身の離脱後も揺るがない「持続可能なプロジェクト」へと昇華させた。 --- # 開発・実装内容B ## 【概要】 - メンバー離脱という不測の事態における、開発ラインの維持とナレッジ移管。 ## 【課題・問題点】 - 主力メンバーの2週間での逃亡: - 採用した業務委託が2週間で離脱し、一時的にバックエンドが「自分一人」に。 - 未経験者への引き継ぎ: - 後任の業務委託がJava未経験であったため、極めて短期間でのキャッチアップが至上命題となった。 ## 【打ち手・使用した技術】 - 徹底したロジカル・レビューと伴走: - 未経験者に対し、単なるコード修正ではなく「Java特有の作法や設計思想」を論理的に指導。 - 自身が作り上げたベースコードを教材とし、実践的な引き継ぎを行った。 ## 【成果】 - 定性的成果: - 自身の退職時点で、後続メンバーが自走して機能追加を行える状態まで引き上げた。 - **「唯一の経験者がいなくなってもプロジェクトが死なない」**体制を作り上げ、プロとしての責務を全うした。

# プロジェクト経験概要 大手損害保険会社向けの新規プロジェクトにおいて、バックエンド全般を担当。 新卒エンジニアが作成したプロトタイプを、本番運用を前提とした堅牢なアーキテクチャへ再構築。 拡張性の高い設計への全面リプレイスと、位置情報を活用した高度な計算処理の実装を完遂した # チーム情報 役割: バックエンドエンジニア 体制: ディレクター1名、バックエンド1名（私）、アプリエンジニア1名、インフラ1名 # 開発・実装内容A ## 【概要】 「動くだけ」の状態だったプロトタイプを、本番環境の負荷と保守に耐えうる設計へ刷新。 ## 【どのような機能の開発・実装か】 - アーキテクチャの再定義: - 既存のFat Controller / Fat Model構成を廃止し、Controller → Service → Modelの3層構造へ移行。 - ソースコードの全面刷新: - 責務分離を徹底するため、既存のソースコードをほぼ全量リプレイスし、可読性と保守性を劇的に向上させた。 ## 【課題・問題点】 - 保守性の欠如: 新卒エンジニアによって構築された既存コードはロジックがコントローラーに集中しており、将来的な機能追加や不具合改修が極めて困難な、いわゆる「スパゲッティコード」の状態だった。 ## 【打ち手・使用した技術】 - Laravel 5.6によるService層の導入: - ビジネスロジックをService層に集約し、各クラスの責務を明確化。 - テーブル設計の最適化: - 運用を見据えた追加テーブル設計を行い、将来的なデータ拡張に対応可能なスキーマを再定義した。 ## 【成果】 - 定性的成果: - プロトタイプ段階での懸念を払拭し、商用サービスとして安定稼働可能な品質へ引き上げた。 --- # 開発・実装内容B ## 【概要】 緯度経度および測地系を考慮した距離計算ロジックの実装、および外部ギフトサービスとの連携。 ## 【どのような機能の開発・実装か】 - 高精度な周辺スポット検索: ユーザーの現在地からポイント付与対象店舗を検索する機能。 - ポイント交換連携: 蓄積したポイントを「Giftee API」を通じてデジタルギフトへリアルタイム交換する機能。 ## 【課題・問題点】 - 距離計算の精度と検索速度の両立: - 地点データが増加する中、単なる平面計算では地球の曲率による誤差が生じ、ポイント付与の公平性に欠ける懸念があった。 - また、これらをアプリケーション層（PHP）で処理するとレスポンスが大幅に低下する課題があった。 - 測地系への対応: - 扱うデータによって日本測地系と世界測地系（WGS84）が混在する可能性があり、これらを正しく扱わなければ計算結果に数百メートルの誤差が生じるリスクがあった。 ## 【打ち手・使用した技術】 - 測地系を考慮したSQL球面三角法の実装: - MySQL 5.7において、測地系（Geodetic System）の違いを考慮した球面三角法の計算式を直接SQL内に実装。 - 既存のロジックに修正を加え、計算精度を向上させつつ、データベース側でソートとフィルタリングを完遂させることで、サーバー負荷を抑えた高速な半径検索を実現した。 - Giftee API連携の堅牢化: - ポイントという金銭的価値を扱うため、トランザクション管理を徹底。 - ネットワークエラー等の例外発生時にもデータ不整合が起きないよう、冪等性を担保したエラーハンドリングを構築した。 ## 【成果】 - 定量的成果: - 地点データが大量にある状態でもミリ秒単位の高速レスポンスを維持。 - 位置情報の計算誤差を最小限に抑え、信頼性の高いポイント付与基盤を構築した。 - 定性的成果: - リリース後、ポイント交換における不整合や位置計算ミスによるトラブルをゼロで抑え、大手損保会社の厳しい要求水準を満たす品質でプロジェクトを完遂させた。 --- # 開発・実装内容C ## 【概要】 「美しいソースコード」を範とした、新卒エンジニアへの技術指導。 ## 【課題・問題点】 - チーム内の若手エンジニアにおいて「動くコード」と「良いコード」の区別が曖昧であり、組織全体の技術水準の底上げが課題となっていた。 ## 【打ち手・使用した技術】 - 背中で見せるエンジニアリング: - 自らがリプレイスしたソースコードを通じて、正しい責務分離や命名規則、DRY原則の体現を提示。 - 個別コードレビューの実施: - 私のコードに感銘を受けた新卒エンジニアからの自発的な依頼に応じ、別プロジェクトのコードに対しても「綺麗に書くコツ」を惜しみなく伝承するレビュー・メンタリングを実施した。 ## 【成果】 - 定性的成果: - 「コードを綺麗に描けるようになりたい」という後進の意欲を引き出し、チーム全体のコード品質に対する意識を劇的に向上させた。 - 単なる開発者としてだけでなく、技術文化の伝道師としての役割を果たした。

# プロジェクト経験概要 DMM.makeの基盤となるECサイトおよび管理サイトのバックエンド開発を担当。 長年の運用で蓄積した深刻な技術的負債（未使用機能・テーブルの乱立）により、ビジネス側の要求に応えられなくなっていた開発体制の正常化に向けた継続的改善を実施した DMM.makeのECサイトおよび管理サイトの運用・機能開発を担当。 # チーム情報 - 役割: バックエンドエンジニア - 体制: サーバーサイド3名（私含む）、フロントエンド1名、関連部署（企画・運用）。 # 開発・実装内容 ## 【概要】 「調査だけでスプリントが終了する」硬直化したレガシーコードの整理。 ## 【どのような機能の開発・実装か】 - 不要資産の特定と削除: - コードベースおよびDB内に残存していた未使用機能、および実体のない未使用テーブルの徹底的な整理・削除。 - Java 7 / Seasar2 環境の保守: - 当時のJava 7およびSeasar2というレガシーな技術スタック上でのパフォーマンスチューニング。 ## 【課題・問題点】 - 機能追加の「実質的不可能」状態: - 技術的負債が限界に達しており、影響範囲の調査だけで2週間のスプリントを使い切る状況が常態化。 - ビジネスサイドからの新規要望を技術的理由で断り続けなければならず、事業成長を阻害していた。 ## 【打ち手・使用した技術】 - コードと実データの突合によるデッドコードの排除: - 単なるコード読み解きだけでなく、実際のデータ移行やアクセスログから「本当に使われていない機能」を1つずつ特定し、安全に切り離した。 - 地道なリファクタリング: - 複雑に絡み合ったJSPやSeasar2のロジックに対し、機能改修のたびに周辺コードの整理を行い、認知負荷の軽減に努めた。 - 技術スタック - AWS / MySQL5.6 / Apache / Tomcat8 / Java7 / Seasar2 / JSP / Maven2 / Bitbucket / Jenkins ##【成果】 - 定性的成果: - 「触れる箇所」と「触れてはいけない箇所」の切り分けを明確化し、ブラックボックス化していたシステムの一部を可視化した。 - 劇的な刷新には至らなかったものの、運用継続に必要な最低限の透明性を確保した。

# プロジェクト経験概要 長年ブラックボックス化し、保守が限界に達していたDMM.makeのECおよび管理サイトのリプレイスを「一人リーダー」として起案。 **100画面規模の開発を少人数で完遂するための「コード自動生成基盤」の構築と、複数のフレームワーク構成を比較検討した「最適な技術選定」**を主導した。 （※本プロジェクトはフレームワーク選定完了後、部門方針の変更により中止となった） # チーム情報 役割: リーダー / エンジニア 体制: 私（1名） # 開発・実装内容A ## 【概要】 将来的なメンテナンス性と開発速度を両立させるための、最適なフレームワークスタックの選定。 ## 【どのような機能の開発・実装か】 - 技術スタックの比較検証とプロトタイピング: - 100画面規模のシステム開発を見据え、複数のバックエンド構成、複数のテンプレートエンジンを組み合わせたプロトタイプを作成し、パフォーマンスと開発生産性を検証。 - 段階的リプレイス方式の立案: 現行システムと新システムを並行稼働させ、機能単位で段階的にトラフィックを移行するためのアーキテクチャ設計および移行ロードマップの策定。 ## 【課題・問題点】 -　技術の混迷: 既存システムがJava 7/Seasar 2という古い環境であり、かつブラックボックス化した独自ライブラリに依存していたため、刷新にあたっては将来の拡張性を担保できる「標準的かつ堅牢な構成」が急務であった。 ## 【打ち手・使用した技術】 - 4つの技術スタック案の比較評価: 以下の構成案を策定し、学習コスト・開発生産性・実行速度の観点からプロトタイプを用いて評価した。 - 【構成1】Struts 2 / Spring Framework / DBFlute（既存技術の延長） - 【構成2】Spring フルスタック（標準性重視） - 【構成3】LastaFlute フルスタック（軽量性重視） - 【構成4】Spring Boot 2 + DBFlute（採用案）: - Springの標準性と、DBFluteによる型安全かつ柔軟なDBアクセスを組み合わせた「ハイブリッド構成」を選定。 - 周辺技術の徹底検証: テンプレートエンジンについてもThymeleaf / Mayaa / Pebble等を比較し、開発メンバーのスキルセットと描画パフォーマンスのバランスから最適なものを採用した。 ## 【成果】 - 定性的成果: - 自身の直感に頼らず、**「複数の構成を定量的・定性的に比較した技術選定資料」**を作成することで、上層部に対し技術的妥当性を論理的に説明し、プロジェクトの承認を勝ち取った。 --- # 開発・実装内容B ## 【概要】 サーバーサイドコードの約50%を自動生成するツールの開発。 ## 【どのような機能の開発・実装か】 - Google Sheets API × Velocity: - スプレッドシートの定義からDTO・Entity・バリデーション・API基盤を自動出力するジェネレータを独自開発。 - Java 8 / Velocity / JAXB / Jackson を駆使し、ボイラープレートコードを徹底排除した ## 【課題・問題点】 - リソース不足と大規模開発の矛盾: - 100画面を超える大規模システムを、限られた工数で高品質に実装しなければならないという物理的な制約。 - ヒューマンエラーの排除: - 定義情報と実装の乖離（整合性崩れ）を最小限に抑える必要があった。 ## 【打ち手・使用した技術】 - Java 8 / Velocity / Google Sheets API: 定義情報を直接取得し、テンプレートエンジン（Velocity）を用いてボイラープレートコードを高速に出力する仕組みを採用。 - JAXB / Jackson: データのマッピングとシリアライズを最適化し、API連携の基盤を半自動化した。 - 技術スタック - Java8 / Google Sheets API v4 / JAXB / Jackson / Velocity / Maven3 ## 【成果】 - 定性的成果: - 100画面規模のシステムを一人で立ち上げるための「武器」を自ら作り上げ、実装フェーズの工数を劇的に削減する道筋をつけた。 --- # 開発・実装内容C ## 【概要】 - 仕様書もソースコードも存在しない「他社製独自ライブラリ」の解明と、安全なリプレイス。 ## 【課題・問題点】 - 「開かずの箱」と化したコアロジック: - サイトの核となる部分に、開発元の独自ライブラリが使用されており、ソースコード提供も拒否され続けてきた歴史的背景があった。 - ドキュメント不在: - ライブラリ仕様がブラックボックス化しているため、不用意にリプレイスすれば既存のビジネスロジックを破壊するリスクが極めて高かった。 ## 【打ち手・使用した技術】 - リバースエンジニアリング（デコンパイル）の実行: - 提供されないソースコードを待つのではなく、独自ライブラリをデコンパイルすることで直接ロジックを読み解くというアプローチを選択。 ## 【成果】 - 定性的成果: - 「技術的に不可能（または極めて高リスク）」と思われていたブラックボックスの解析に突破口を開き、リプレイスの現実的な道筋を示した。

# プロジェクト経験概要 自社ゲーム基盤（Laravelベース）の数少ない経験者として、新規タイトルのメインエンジニアに選抜され参画。 バックエンド開発の主導に加え、チーム拡大に伴う新規エンジニアのOJTを担当した。 開発コスト見直しによりプロジェクトは中止となったが、基盤側の致命的なパフォーマンス課題を解決する「汎用バルク処理コンテナ」を独自に構築し、チーム全体の開発効率向上に寄与した。 # チーム情報 - 役割: メインエンジニア / OJT担当 - 体制: 約30名規模の開発チーム # 開発・実装内容 ## 【概要】 - 自社ゲーム基盤の制約を突破し、大量データ処理時のデータベース負荷を劇的に低減する仕組みの構築。 ## 【どのような機能の開発・実装か】 - バルク処理管理コンテナの開発: アイテム一括配布などの大量データ更新において、データベースへのアクセス回数を最適化し、一括処理（バルクインサート/アップデート）を安全かつ容易に実行するための管理クラス群の設計・実装。 ## 【課題・問題点】 - 共通基盤の設計欠陥: - 当時の自社ゲーム基盤にはバルク処理が未実装であり、一括処理時も内部でループを回して1件ずつSQLを発行する仕様だった。 - 大規模トラフィックが想定される3Dゲームにおいて、この仕様はDB負荷の急騰とパフォーマンス低下を招く致命的なリスクであった。 - 開発停滞のリスク: - 基盤チームへ改善要望を出し続けていたが対応が遅れており、アイテム配布機能の実装期限が迫る中、基盤のアップデートを待つことができない状況だった。 ## 【打ち手・使用した技術】 - 基盤の機能を活用した追加実装: - ゲーム基盤の共通クラスを利用しつつ、基盤がサポートしていなかったバルク処理ロジックを「アイテム配布管理クラス」として独自に実装。 - アイテム配布管理クラスの拡張: - 当初は自身の担当機能であるアイテム配布を安全に行うためのクラスとして開発したが、同様の課題を抱える他メンバーからの要望を受け、「どの機能からでも容易に組み込める」ようにインターフェースを汎用化。 ## 【成果】 - 定性的成果: - 基盤側の欠落を個人の実装力で補完し、プロジェクト全体のパフォーマンスリスクを解消した。 - 自作したコンテナがチーム内で「使いたい」と言われる水準の品質であったことは、**「現場の課題を抽象化して解決する」**リードエンジニアとしての資質を示す実績となった。

# プロジェクト経験概要 人気IPのブラウザゲーム化プロジェクトにバックエンドエンジニアとして参画。 自身にとって初となる「Laravelベースの社内ゲーム基盤」の習得に並行して、ゲームAPI開発から管理ツール、フロントエンド制作まで幅広く担当した。 このプロジェクトでの確かなアウトプットが評価され、次期プロジェクトでのメインエンジニアへの抜擢に繋がった。 # チーム情報 - 役割: バックエンドエンジニア - 体制: 約30名規模の開発チーム # 開発・実装内容 ## 【概要】 社内ゲーム基盤を用いた、ゲームコアロジックのAPI開発。 ## 【どのような機能の開発・実装か】 - ゲームAPI開発: - ログボやクエスト等のゲームサイクルを支えるAPI設計・実装およびテスト ## 【課題・問題点】 - 未知の独自基盤への適応: - Laravelベースではあるものの、独自の拡張が施された大規模な社内基盤を使いこなす必要があった。 - 開発スピードを落とさずに、基盤の作法を理解し、高品質なコードを書くことが求められた。 ## 【打ち手・使用した技術】 - 実戦を通じた技術習得: - 既存の基盤コードを徹底的に読み込み、仕様を早期に把握。 - PHP 7 / Laravel 5.1の標準機能と基盤特有の機能を組み合わせ、要件に合致するAPIを迅速に構築した。 - パフォーマンスへの配慮: - RedisやMongoDBを活用したデータアクセスを実装し、高負荷を想定したデータ構造の最適化を意識した。 ## 【成果】 - 定性的成果: - 短期間で基盤のスペシャリストへと成長し、大規模開発においても遅滞なく機能提供を完遂。 - **「新しい技術・環境への適応力」**をチーム内で証明した。

# プロジェクト経験概要 gloops製のスマートフォン向けブラウザゲームエンジンをベースとした、DMM向け新規ゲーム開発を主導。 当初800テーブルだったDB構造が開発中の機能追加により880テーブルまで肥大化する中、エンジンの全容解明から、PC・SP両対応への過酷なカスタマイズを完遂。 また、採用における手痛い失敗を教訓とした「時短バイト採用」へのシフトなど、開発マネージャーとして組織の安定化にも大きく貢献した。 ローンチ3ヶ月後に会社は倒産したものの、システムは他社へ移管され約5年間にわたり安定運用された。 # チーム情報 - 開発マネージャー 兼 バックエンドエンジニア（先行アサインにより一人で基盤構築・解析を実施） - 体制: チーム全体21名（企画7、開発6、演出2、デザイン5、インフラ1） # 開発・実装内容A ## 【概要】 - ドキュメントが一切存在しない巨大な既存エンジンのリバースエンジニアリングと、開発に伴うDB拡張。 ## 【どのような機能の開発・実装か】 - 大規模DBのメンタルマッピング: - 最終的に880テーブルまで増殖した複雑なDB構造（SQL Server）の解析。 - リバースエンジニアリング: - 設計書がない5,000ファイル以上のソースと300件のストアドプロシージャの全容解明。 ## 【課題・問題点】 - 圧倒的な情報量とカオス化: - 当初800テーブルだったエンジンに、社長の意向による機能追加が重なり、最終的に880テーブルまで増加。 - 設計書がない中で、どのテーブルにどのデータがあるか、開発効率を落とさずに把握し続ける必要があった。 - 徹底した継続解析: - 「毎日見ていれば覚える」という執念のもと、ソースコードとDBを愚直に突き合わせ続ける解析作業を継続。 - ユーティリティ化による制御: - バラバラだった2,000箇所のURL生成箇所を、自作のURL生成ユーティリティに集約し、DBの物理構造変更に強いアーキテクチャへと修正した。 ## 【打ち手・使用した技術】 - 地道な整合性確保: - URL生成を担う汎用ユーティリティを自作し、全URL生成をそこへ向けるよう1箇所ずつ修正・動作確認を1週間かけて徹底。 - ドキュメント化の徹底: - 後続メンバーが迷わないよう、解析結果を機能一覧とフロー図に落とし込み、マイルストーンとしての入金条件（DMMへの成果報告）をクリアした。 ## 【成果】 - 定性的成果: - 参画から約8ヶ月で全880テーブルの役割とデータ構造を完全に把握。 - 全体を把握している人間が一人もいない」という壊滅的状況を打開し、開発チームが稼働できる土台を独力で築き上げた。 --- # 開発・実装内容B ## 【概要】 - 1,500万円の入金条件である「PC版の動作」を、数時間という極限のタイムリミット内で完遂。 ## 【どのような機能の開発・実装か】 - PC版レイアウトおよびサウンド継続再生機能: - SP版をiFrameで包み込みつつ、ページ遷移してもBGMが途切れないサウンド制御構造の構築。 ## 【課題・問題点】 - 極限のデッドライン: - 月末17時に「今日中にPC版が動けば1,500万円入金される」という経営課題が突如発生。 - 18時から作業開始し、当日中に完了させる必要があった。 - 技術的制約: - 単なるiFrame化ではページ遷移ごとにサウンドがリセットされるため、ゲーム体験として不完全だった。 ## 【打ち手・使用した技術】 - 多重iFrame構造によるサウンド維持: - 全体をさらに外側のiFrameで囲い、そこにサウンドスクリプトを常駐させることで、内部のページ遷移に影響されない「サウンド流しっぱなし」の状態を実現。 ## 【成果】 - 定性的・定量的成果: - わずか6時間の超高速実装により、1,500万円の資金調達（入金）に直接貢献。 - 技術力と執念で会社の危機を救い、プロジェクトを事前登録開始まで導いた。 --- # 開発・実装内容C ## 【概要】 - スキルミスマッチ（経歴詐称）による開発停滞を打破するための、柔軟な採用モデルの確立。 ## 【課題・問題点】 - 採用のミスマッチ: - 「Java経験・リーダー経験あり」として採用した業務委託者が、実際にはHTMLの差し替えすら3日経っても完遂できない極度のスキル不足（経歴詐称）であることが判明。 - フロントとサーバーサイドの区別すらつかない人材に教育コストを奪われ、プロジェクトの進捗が著しく阻害された。 ## 【打ち手・使用した技術】 - 厳格なスキルアセスメントと判断: - 3日間で技術レベルを正確に測定し、即座に戦力外と判定。 - 契約上の制約を考慮しつつ、リソースを無駄にしないためのタスク管理に切り替えた。 - 採用戦略の抜本的変更: - フルタイム業務委託への依存を止め、**「家庭の事情や身体的理由でフルタイム勤務はできないが、高い技術力を持つ層」を狙った「時短バイト採用」**へと舵を切った。 ## 【成果】 - 定性的成果: - 時短バイトとして4名の優秀なエンジニアを採用することに成功。 - 画一的な採用基準では見逃されがちな「実力者」を柔軟な雇用形態で確保することで、開発組織の質と安定性を劇的に向上させた。

# プロジェクト経験概要 受託案件の獲得に難航する中、大手企業（バンダイ）の企画コンペ参加を契機に、自社ゲーム開発へシフト。 既存のゲーム開発経験はあったものの、未経験領域であるR-18市場の厳しい洗礼を受け、2度にわたる大規模なブラッシュアップを敢行。 ご褒美は「静止画のみ」という初期実装から、市場基準のアニメーション・ゲーム性を備えたプロダクトへ、開発全般をリードした。 # チーム情報 役割: 開発リーダー / バックエンドエンジニア 体制: 企画3名、開発4名（私含む）、演出1名、デザイン1名、インフラ1名 # 開発・実装内容A ## 【概要】 - 受託開発から自社R-18タイトル開発への劇的な方針転換に伴う、1週間での仕様決定と開発着手。 ## 【どのような機能の開発・実装か】 - ゲームシステム全般の実装: - PC・SP両対応および、管理機能全般の設計・実装。 ## 【課題・問題点】 - 受託獲得の難航と方針転換 - 当初は受託開発を目指していたが、設立間もなく実績不足のため案件受注が難航。 - 打開策としてバンダイのゲーム企画コンペに参加。 - コンペの結果を待つ間（最終的に連絡なし）、自社開発へのシフトを決定した。 - プラットフォームに合わせた企画の選定: - コンペ用に複数の企画が検討された際、その中にあった「ナイトワーク物」高評価だったが「バンダイには適さない」と冷静に判断し、提出を見送っていた。 - しかし、DMM向けの自社開発にあたっては、この企画がターゲット層に最適であると判断し、R-18仕様へと昇華させてベース案に採用した。 ## 【打ち手・使用した技術】 - 超短期仕様策定: - 9名全員参加の1週間MTGにより、既存の企画をR-18仕様に寄せた詳細仕様を最短で確定。 - PHP 5.4 / CakePHPを採用し、最短での完成を目指した。 ## 【成果】 - 定性的成果: - 同年内に全機能の実装を完了。 - 未整備な環境下で、不採用の企画すら「自社の強み」へ転換して形にした。 --- # 開発・実装内容B ## 【概要】 - 外部評価で指摘された「ゲーム性の欠如」を克服するため、演出やゲームシステムを徹底的にブラッシュアップ。 ## 【どのような機能の開発・実装か】 - ゲームロジックおよびフロントエンド機能の広範な実装: - クエスト進行、報酬計算、ユーザーデータ管理、およびそれらに付随するフロントエンドのインタラクション制御全般。 ## 【課題・問題点】 - 大規模な仕様変更への対応: - 外部評価により「アニメーションの必須化」と同時に「ゲームとしての面白さ」の向上が突きつけられた。 - 演出担当がアニメーション制作に専念できるよう、それ以外の膨大なシステム改修を迅速に完遂させる必要があった。 ## 【打ち手・使用した技術】 - 全方位的なシステム実装: - 他のバックエンドメンバーの負荷を考慮し、演出以外のほぼ全ての機能改修を自ら引き受けて実装。 - 機能と演出の分離設計: - 演出担当が「魅せ方」に集中できるよう、バックエンドのロジックとフロントエンドの繋ぎ込みを整理し、複雑なゲームサイクルを破綻なく動作させる土台を構築した。 ## 【成果】 - 定性的成果: - 2度のブラッシュアップを経て、2015年8月に事前登録を開始。 - 自身が機能面を完璧に網羅・実装したことで、市場で戦えるレベルのプロダクトへと再生させた。 - この経験は、**「不測の事態においても、プロジェクトの成功に必要な全機能を一人で作り上げる圧倒的な完遂能力」**の証明となった。

# プロジェクト経験概要 Amazon上のゲームソフト情報を収集・集約するゲーム記事キュレーションサイトの構築。 親会社CTOの方針によりWordPressの採用が決定していたが、WordPress特有の凄惨なスパゲッティコードによる運用リスクを回避するため、リクエストを横取りして独自フレームワークで処理するアーキテクチャを独力で構築し、開発効率と保守性を劇的に向上させた。 # チーム情報 - 役割: 開発リーダー / アーキテクト - 体制: 企画4名、開発2名（私含む）、デザイン1名 # 開発・実装内容A ## 【概要】 - WordPressをベースとしつつ、その内部ロジックに依存しない、Java（Struts2 + S2JDBC）ライクな独自PHPフレームワークの設計・開発。 ## 【どのような機能の開発・実装か】 - リクエストインターセプト機構: - WordPressの設定が読み込まれ処理させる直前のデッドスペースを特定し、リクエストを横取りして独自Controllerへディスパッチする仕組みを3日で実装。 - DI / ORM / AOP / アノテーションの自作: - PHPのマジックメソッドやリフレクション、PHPDocタグを活用し、Javaの開発経験を活かせる高度な機能を7日で実装。 ## 【課題・問題点】 - WPの構造的欠陥: - 管理画面でのページ作成時にPCのフルパスがDB登録されるなど、チーム開発が困難な仕様や、コアコードがスパゲッティ化しておりカスタマイズが極めて危険な状態だった。 - 技術スタックの制限: - 親会社の方針により、得意とするJava（Struts2等）の使用が許されず、PHPとWordPressのみで構築しなければならなかった。 ## 【打ち手・使用した技術】 - 運用重視の設計判断: - WordPressを直接カスタムすると「運用で死ぬ」ことが予見されたため、自宅と会社を往復する3日間でMVCの基礎を完成させ、DIやORM（Join対応）/ AOP / アノテーションまでを計10日間で自作。 - AOPの実装: - PHPのマジックメソッドを用いて、JavaのServiceメソッド単位のトランザクション管理に近いインターセプト機構を構築。 ## 【成果】 - 定性的成果: - 劣悪な環境下において、Java開発時と同等の生産性と高い保守性を実現。 - 後続の運用チーム（オブジェクト指向未経験者含む）への引き継ぎ後も、深刻なトラブル報告なく安定稼働させた。 --- # 開発・実装内容B ## 【概要】 - サイト構成上の制約である「フルAjax」を、メンテナンス性を損なわず最小工数で実現するためのライブラリ選定と実装。 ## 【課題・問題点】 - JavaScriptの属人性リスク: - 同僚がゴリゴリなJS実装を進めていたが、その直後に退職が決定。 - 複雑化したJSコードを引き継ぐことは将来的なメンテナンスの崩壊（メンテ死）を意味していた。 ## 【打ち手・使用した技術】 - Xajaxの採用: - PHP側でAjax挙動を記述できるXajaxを導入。 - これにより、フロントエンドの挙動ロジックをバックエンド（PHP）と一元管理できる体制へ強制的に移行した。 ## 【成果】 - 定性的成果: - ソースコードをPHPだけで完結させることで、ロジックの分散を防ぎ、一人でも全画面の挙動を完全に制御・保守できる状態を構築した。 --- # 開発・実装内容C ## 【概要】 - ユーザーの入力揺れ（全角・半角、ローマ数字、機種依存文字など）を吸収し、Amazonと同等の高い検索精度を実現するための正規化ロジックの設計・実装。 ## 【どのような機能の開発・実装か】 - 検索キーワードの正規化エンジン: - ユーザーがいかなる形式（例：ドラクエ3、ドラクエⅢ、ドラクエｉｉｉ）で検索しても、システム内部で同一のキーワードとして扱い、確実に対象をヒットさせる変換処理の実装。 ## 【課題・問題点】 - 検索ヒット率の低下: - ゲームタイトルには「3」や「III」といった数字・記号が含まれることが多く、ユーザーによって入力形式がバラバラであった。 - 全ての入力パターンを網羅した複雑な検索クエリを組むのは処理負荷が高く、開発効率も悪いという課題があった。 ## 【打ち手・使用した技術】 - 「フォーマットの統一」によるシンプル化: - 複雑な検索パターンに対応するのではなく、**「あらゆる入力を一定のフォーマットに正規化してから検索に回す」**という設計方針を採用。 - 多段階変換ロジックの構築: - 全角スペース、タブ、改行、および不要記号（!, ・, 「」, 【】, ～, -, |, ｜ 等）をすべて半角スペースに集約。 - ローマ数字（Ⅲなど）、機種依存文字のローマ字、アルファベットのローマ字（III, iiiなど）をすべてアラビア数字（3）へ変換。 - 英数字は半角、カタカナは全角に統一。 - PHPによる高速変換: - 正規化フィルタを通すことで、DB側の検索処理を極めてシンプルな等価比較や前方一致に落とし込めるようにした。 ## 【成果】 - 定性的成果: - Amazonの検索ロジックに匹敵する「入力形式に依存しない柔軟な検索体験」を実現。 - ユーザーの検索ストレスを排除し、サイト内の回遊性と利便性を劇的に向上させた。 - 技術的洞察: - 「複雑な問題に対し、入力側を整理することで処理側の複雑さを解消する」というアーキテクト的アプローチを体現した。

# プロジェクト経験概要 アウトソーシング先が開発を断念した、同時接続4名で限界を迎える極めて低品質なブラウザゲームを引き継ぎ、プロパーエンジニアのみで全面改修。 1万件発行されていたSQLを1件に集約するなどの抜本的なパフォーマンス改善を行い、目標DAUを大幅に上回る商用サービスへと再生させた。 # チーム情報 役割: 開発リーダー / バックエンドエンジニア 体制: 企画3名、開発6名（私含む）、デザイン1名、インフラ1名 # 開発・実装内容A ## 【概要】 「5人目がログインするとタイムアウトする」致命的なパフォーマンス不備の解消。 ## 【どのような機能の開発・実装か】 - ログインシーケンスの全面刷新: - ログイン直後のファーストビュー表示におけるデータ取得ロジックの再構築。 ## 【課題・問題点】 - N+1問題の極致: - キャッシュありきの設計ながら、ループ内でキャッシュ参照とDBへのSELECTを繰り返しており、1ユーザーのログインにつき1万クエリが発行される異常な実装となっていた。 - 結果、5人目の同時アクセスでDBが限界を迎え、サービス全体が停止する状態だった。 ## 【打ち手・使用した技術】 - クエリの集約とキャッシュ戦略の適正化: - 依存関係を整理し、ループ内クエリを徹底的に排除。 - 1万件発行されていたクエリを、JOINや適切なデータ構造の検討により「1件」のクエリへと集約した。 - 技術スタック - Linux / nginx / MySQL / memcache / PHP5.3 / Smarty / JavaScript ## 【成果】 - 定量的成果: - 同時接続数の制限を事実上撤廃。 - 最高DAUは2,000人に達し、改修当初の目標であった「100人で遊べるようになる」という夢を20倍の規模で達成した。 --- # 開発・実装内容B ## 【概要】 - 多次元配列の相互参照が入り乱れるスパゲッティコードの解体と、開発基盤の整備。 ## 【課題・問題点】 - 絶望的な保守性: - 各要素が相互参照する複雑な多次元配列、SQLのベタ書き、二重送信対策の不在など、開発メンバーが離脱するほどの劣悪なコード環境であった。 - 制約条件: - 経営判断により「作り直し」が認められず、稼働中のシステムを改修し続ける必要があった。 ## 【打ち手・使用した技術】 - 汎用DBアクセスライブラリの構築: - 全てのDBアクセスを抽象化するライブラリを自作。 - エンティティ導入によるデータ構造の正規化: - SELECT結果を配列ではなくエンティティに格納する方式へ変更し、カラムフェッチの冗長な記述を徹底排除。 - 「神クラス」への外科的アプローチ: - 手出し不能な「補正ロジックの神クラス」に対し、ロジック自体を壊さぬよう前後にフック処理を噛ませることで、安全に機能拡張を実現した。 ## 【成果】 - 定性的成果: - 壊滅状態だったプロジェクトを1年半かけて正式リリース（2013年4月）まで導いた。 - カオスな状況下で「捨てる」選択肢がない中、現実的な解を積み重ねて完遂させた。 --- # 開発・実装内容C ## 【概要】 - 正式リリース後、運営効率化のためにJava（Struts2/Seasar2）を用いてゼロから構築した管理機能の開発。 ## 【どのような機能の開発・実装か】 - マルチDB参照機能: - 複数存在するゲームサーバーそれぞれのデータベースを、一つの管理画面上から動的に切り替えて参照・操作できる機能を実装。 - 全般的な運用ツール開発: - ユーザー検索、アイテム配布、ログ解析など、運営に必要な全機能を一人で設計・実装。 ## 【課題・問題点】 - 物理的に分離されたDBへのアクセス: - ゲームサーバーが複数台構成であり、サーバーごとに独立したDBを保持していた。 - 管理画面からそれぞれのDBへ安全かつ容易に接続を切り替えるロジックを自前で実装する必要があった。 ## 【打ち手・使用した技術】 - 動的データソース切り替えの実装: - Java / Seasar2の機能を活用し、管理画面上の操作に応じて接続先DBの定義を動的に切り替える仕組みを構築。 - 運用上のボトルネックを技術的に解消した。 - 技術スタック - Linux / nginx / Tomcat / Java / Struts2 / Seasar2 / S2JDBC / S2Chronos / Mayaa / JavaScript / JQuery / Maven2 / SVN / Eclipse ## 【成果】 - 定性的成果: - 運用フェーズにおいて、エンジニアが手動でSQLを叩くコストをゼロにし、非エンジニアでも安全に全サーバーの状況を把握・操作できる環境を完遂した。 --- # 開発・実装内容D ## 【概要】 自社サーバーでの集客苦戦を受け、mixi、Yahoo!モバゲー等へ展開するためのシステム改修および決済連携。 ## 【課題・問題点】 - 自社集客の限界: - 当初は自社サーバーのみで運用を開始したが、集客が想定を下回った。 - ビジネスを存続させるため、既存の巨大なプラットフォームへ相乗りする戦略への転換が急務となった。 ## 【打ち手・使用した技術】 - プラットフォーム連携の実装: - 各プラットフォーム特有の認証・認可、およびQuicPay、WebMoney、mixi、Yahoo!モバゲーといった多様な決済基盤とのAPI連携を網羅的に実装。 - プラットフォーム知見の蓄積: - 各社で異なるレギュレーションやAPIの特性を一つずつクリアし、短期間での多角展開を実現。 ## 【成果】 - 定性的成果: - プラットフォーム展開により集客課題を解決し、サービス寿命の大幅な延長に成功。 - ここで得た「ゲームプラットフォームへの適応知見」は、後のDMM GAMESプラットフォームにおける開発を成功させるための確固たる基盤となった。 --- # 開発・実装内容E ## 【概要】 イベント開始時に発生した設定漏れに対し、最短ルートでのリカバリを完遂。 再発防止策として、属人的な運用を排した「手順のドキュメント化・仕組み化」を徹底した経験。 ## 【どのような機能の開発・実装か】 - イベントNPC出現制御: - 定刻（朝10時）に特定の座標へイベント用NPCを自動出現させるバッチ処理およびマスタデータ管理。 ## 【課題・問題点】 - 重大な設定漏れの発生: - イベント開始直後、NPCが出現していないことが発覚。 - 原因は、マスタ設定の準備作業が自身の記憶のみに依存しており、多忙な中で作業が抜け落ちてしまったこと（ヒューマンエラー）であった。 - リアルタイムでの状況判断: - 通勤中の電車内で障害を検知し、出社までの数十分間、いかに被害を最小限に抑えつつ復旧させるかという判断が求められた。 ## 【打ち手・使用した技術】 - リスクを最小化した緊急リカバリ: - 出社直後にDBを確認。 - NPC出現予定の座標に偶然にもユーザーが存在しないことを瞬時に把握し、「今なら最小限の影響で復旧可能」と判断。 - 即座に緊急メンテナンスを入れ、マスタ設定と出現バッチの再実行を行う最短ルートでのリカバリを完遂した。 - 属人性の徹底排除（ドキュメント化）: - 自身のミスを「たまたまの失念」で終わらせず、運用体制の欠陥として捉え直した。 - 以降、全てのイベント準備手順を頭の中から出し、**「誰が作業しても再現可能なチェックリスト付きドキュメント」**へと落とし込む仕組みを構築した。 ## 【成果】 - 定量的成果: - 発生から数十分という短時間でイベントを正常化させ、ユーザーへの影響を最小限に抑えた。 - 定性的成果: - プロダクト運用における「個人の記憶への依存」を完全に脱却。 - この日を境にドキュメント文化を定着させたことで、以降、同様のマスタ設定ミスによる障害発生率をゼロに抑え込み、運用の品質を抜本的に向上させた。

# プロジェクト経験概要 親会社が展開する結婚式場サービスのサブプロジェクト。 正式リリース時にサイトが「空の状態」になるのを防ぐため、アサインから2週間で会員登録機能を独力で完遂。 戦略的な先行リリースにより確保した会員から口コミを収集するサイクルを確立し、11月の本番ローンチ時点で豊富なコンテンツを備えた状態での垂直立ち上げを実現した。 # チーム情報 役割: 開発リーダー / バックエンドエンジニア 体制: 企画3名（親会社）、開発2名（私含む）、デザイン2名（親会社）、インフラ1名 # 開発・実装内容A ## 【概要】 - 正式リリース前に会員と口コミ（コンテンツ）を確保するための、キャンペーン連動型登録システムの完全独力開発。 - 正式リリースに向けたサービス全般の開発。 ## 【どのような機能の開発・実装か】 - 先行リリース機能（独力実装）: - Amazonギフト券キャンペーンと連動した、会員登録・認証・応募管理システムの構築。 - 全体開発（8割担当）: - 口コミ投稿、式場検索、管理画面など、サービスを構成する機能の大部分。 ## 【課題・問題点】 - スッカスカ」状態の回避: - 新規サービスにおいて、リリース時に口コミがゼロであることは致命的なビジネスリスクであった。 - アサインからわずか2週間で、会員を集めるための土台を完成させる必要があった。 ## 【打ち手・使用した技術】 - 運用を逆算したシステム設計: - 親会社が登録会員へ連絡し、リリース前に口コミを収集・蓄積できるようなフローを想定して開発。 - 圧倒的な実装スピード: - 8月25日のアサインから9月中旬のリリースまで、他メンバーが驚愕する速度でJava / Struts2 / Seasar2を用いた開発を一人で完遂させた。 ## 【成果】 - 定量的・定性的成果: - 予定通り9月中旬にリリース。 - 集まった会員から事前に口コミを収集することで、正規ローンチ時に「コンテンツが充実した状態」を作り出すことに成功した。 - ビジネスの成功に直結する「コンテンツの垂直立ち上げ」を技術面から完全に支え切った。 --- # 開発・実装内容B ## 【概要】 - amChartsを用いたグラフ表示に不可欠な、複雑な集計ロジックと連携バッチの構築。 ## 【課題・問題点】 - 親会社からの「なる早」要求に対し、自ら「1日で対応可能」と宣言。 - 複雑な集計仕様のため、技術的には1日では極めて困難なボリュームであった。 ## 【打ち手・使用した技術】 - 有言実行のコミットメント: - 宣言を遵守するため、PostgreSQL上のデータ集計ロジックを最適化し、amCharts連携用のバッチを最短経路で設計。 ## 【成果】 - 定性的成果: - 宣言通り1日で実装を完遂。 - 技術力のみならず、言葉に対する責任感と突破力を示したことで、親会社から「伝説的な開発スピード」として絶大な信頼を得た。

# プロジェクト経験概要 東日本大震災に伴う節電対策として、iOS/Android向けアプリを緊急開発。 Android版の実装に加え、サーバーサイドの全機能（バッチ、API、プッシュ通知基盤）およびDBを含むシステム全体の設計を独力で完遂。 当時テスト運用中だったC2DM（Googleクラウドメッセージングの前身）をいち早く導入し、リアルタイムな情報提供を実現した。 # チーム情報 役割: 開発リーダー / フルスタックエンジニア（Android・サーバーサイド） 体制: 開発2名（私含む）、デザイン1名（親会社）、インフラ1名 # 開発・実装内容A ## 【概要】 - 外部データ（東京電力提供）の自動取り込み、およびユーザーへのリアルタイム通知を支えるバックエンド全般の設計・開発。 ## 【どのような機能の開発・実装か】 - 電力使用状況データ取込バッチ: - 東京電力が提供するCSVデータを解析・DBへ格納する自動化処理。 - プッシュ通知基盤（C2DM）: - 当時テスト運用段階だったGoogleのC2DMを採用した、ユーザーへのプッシュ通知機能。 - システムアーキテクチャ設計: - DB設計を含む、アプリとサーバー間の通信プロトコルの策定全般。 ## 【課題・問題点】 - 未確立な技術への対応: - C2DMは当時まだ新しくドキュメントも少ない中、電力逼迫状況を即座に知らせるための通知基盤を短期間で安定稼働させる必要があった。 ## 【打ち手・使用した技術】 - 先行技術の採用: - Java6 / Struts2 / Seasar2 をベースにしつつ、最新のC2DMを実験的に導入。 - 現在地情報をGoogle Map APIと連動させ、居住エリアに応じた最適な情報を提示するロジックを実装した。 ## 【成果】 - 定性的成果: - 社会的ニーズの極めて高い局面において、インフラデータとモバイルを繋ぐ一連のシステムを設計・実装し、スピード感を持ってデリバリーした。 --- # 開発・実装内容B ## 【概要】 - Androidアプリの実装、および地図上での会員数集計データのビジュアライズ。 ## 【どのような機能の開発・実装か】 - 地図上へのデータマッピング: - マップ背景上に、節電宣言を行った会員数をエリアごとに集計して表示する機能。 ## 【課題・問題点】 - ハードウェアの描画制限: - 当時のスマートフォンのレンダリング技術では、地図上に動的な数値を美しく配置することが困難であり、ピクセル単位での緻密な調整が求められた。 ## 【打ち手・使用した技術】 - 泥臭いUI調整の徹底: - フレームワークの機能に頼り切るのではなく、座標計算とレンダリングの挙動を解析し、当時のスペックで最大限視認性を高めるための「ピクセル調整」を徹底的に実施した。 ## 【成果】 - 定性的成果: - 「誰が・どこで・どれだけ節電しているか」という会員の行動を可視化することで、ユーザーの節電意識を高めるサービス体験を実現。 - 同僚がObjective-Cのメモリ管理（スタックエラー等）に苦戦する中、Android側およびサーバー側の基盤を盤石に構築した。

# プロジェクト経験概要 検索順位チェックツール「GRC」にインスパイアされた親会社サービス「FerretRC」を開発。 Java による高度なマルチスレッド制御、低レイヤーの座標計算を含む UI 拡張、リフレクションを駆使した独自フレームワーク構築、さらにはインストーラー作成（NSIS）までを網羅。 Web 開発の常識が通用しない「デスクトップアプリ特有の難所」を全て独力で突破した。 # チーム情報 - 役割: 開発リーダー / アーキテクト / メインエンジニア - 体制: 開発3名 - CTO: スクレイピング・インフラ担当 - 同僚: 帳票担当 - 私: 全体クライアントアプリ/アップデーター/管理サイト/Web API等の残り全てを担当 # 開発・実装内容A ## 【概要】 - 最大 20 本のスレッドが並行動作する、Seasar2 (Uruma) ベースのマルチスレッドアプリケーションの設計・開発。 ## 【どのような機能の開発・実装か】 - 高度なマルチスレッド制御: - スケジュール実行、各検索エンジンの収集スレッド、UI 更新スレッドなど、複数の非同期処理を破綻なく管理。 - 独自フレームワークの構築: - Seasar2 (Uruma) を DI コンテナとして採用。 - UI とイベントを完全に分離するアーキテクチャを設計し、バリデータや Entity/DTO の自動生成ツールも自作して開発効率を最大化した。 - UI 設計の複雑性: - SWT 標準のエディタでは、ウィンドウリサイズ時にデザインが崩れる、あるいはソースコードがスパゲッティ化するというデスクトップアプリ特有の課題があった。 ## 【打ち手・使用した技術】 - ライブラリのハックによる UI 最適化: - ウィンドウリサイズ時にメニューブロックの高さ等を固定するため、継承不可（protected）であった SWT のレイアウトクラスをプロジェクトソース内に配置。 - ステップ実行を繰り返しながら、ピクセル単位の座標計算を「直感」と検証により書き換えることで、独自の動的リサイズ処理を実現した。 - パフォーマンス最適化: - CTOが担当するスクレイピング処理の負荷軽減のため、LinkedHashMapを用いたキャッシュコンテナを自作。 - スレッドセーフを考慮した設計により、全体のレスポンス性能を大幅に向上させた。 ## 【成果】 - 定性的成果: - Web フレームワークの制約を超えた「OS 制御に近い Java」を使いこなし、既存のデスクトップアプリ製品に劣らない高いユーザビリティを実現した。 --- # 開発・実装内容B ## 【概要】 - XML 定義に基づき、無限階層のメニューを動的に生成・制御するコンテキストメニュー制御機構の構築 ## 【課題・問題点】 - メンテナンス性の確保: - 右クリックメニューの項目や階層が増えるたびに UI コードを修正するのは非効率であり、動的な表示／非表示やアクションの紐付けを宣言的に記述する必要があった。 ## 【打ち手・使用した技術】 - メタプログラミングの活用: - メニュー構造を XML スキーマで定義し、JAXB でオブジェクトマッピング。 - java.lang.reflect（リフレクション）と再帰処理を組み合わせ、メモリが許す限り無限に階層化できる メニュー制御を開発した。 - アクションの抽象化: - 項目選択時の挙動を動的に呼び出し、UI とロジックの完全な分離を達成。 - 15 年経った現在でも自身の「最高傑作」として鑑賞するほどの抽象度を実現した。 ## 【成果】 - 定性的成果（技術的完成度）: - XML 定義のみで複雑なメニュー構造を制御可能にし、UI とロジックの完全な分離を達成した。 - 長期的価値: - この設計は 15 年経った現在でも自身の「最高傑作」として鑑賞し続けるほどの高い抽象度と保守性を誇り、Web 開発における難解な課題解決にも通ずる「アーキテクトとしての原点」となった。 --- # 開発・実装内容C ## 【概要】 - JasperReportsを用いた帳票出力機能において、保守性を維持するためのアーキテクチャ設計と、チーム内での設計思想の徹底。 ## 【どのような機能の開発・実装か】 - 帳票出力基盤の設計: - 複雑な検索順位データの可視化を担うJasperReportsの導入。 - レンダリングクラスの分離: - GUIエディタ（iReport）にロジックを埋め込ませず、Javaクラス側で計算・データ取得を行う「見た目とロジックの完全分離」の設計。 - ベテランエンジニアによる「楽」への傾倒: - 開発を担当した10年以上のキャリアを持つ同僚が、GUIエディタの利便性に負け、エディタ内に複雑なDB検索や数式を直接埋め込んでしまった。 - これにより、仕様変更が極めて困難な「カオスな帳票」が生まれるリスクが発生した。 ## 【打ち手・使用した技術】 - アーキテクチャの事前定義: - 開発着手前に「エディタは見た目のみに留める」ようレンダリングクラスを準備し、強く警告。 - リカバリとリファクタリング: - カオス化した箇所のロジックを可能な限りJavaクラス側へ移譲する努力を継続したが、過度な作り込みと納期制約により完全な修正が困難な状況を経験。 ## 【成果】 - 定性的成果: - 最終的に、その同僚が後の追加要望対応で「言う通りにすれば良かった」と吐露するほどの保守性の差を実証することとなった。 - この経験から、「どんなにベテランであっても、ツールの利便性による設計崩壊を防ぐための強制力（コードレビューやCIによる制約）の重要性」を深く認識し、その後のプロジェクトでの徹底したコード品質管理に繋げている。 --- # 開発・実装内容D ## 【概要】 - Maven2、Ant、NSIS を組み合わせた、ソースコードから Windows インストーラー（EXE）までの一括ビルド環境の構築。 ## 【どのような機能の開発・実装か】 - 配布・更新基盤の開発: - アップデーター、不要ライブラリのクリーナー、サーバー側のアップデート API の一貫した実装。 - インストーラーの高度な制御: - NSIS を採用し、OS 判定やレジストリ操作を含むスクリプトを手書きで実装。 ## 【課題・問題点】 - 運用の複雑性: - デスクトップアプリは配布後の修正が困難なため、アップデートの仕組み自体に極めて高い信頼性が求められた。 ## 【打ち手・使用した技術】 - Ant によるパイプライン構築: - Java ビルドからインストーラー作成までを Ant で一発実行できる環境を構築。 ## 【成果】 - 定性的成果: - 開発から配布までの複雑な全工程を自動化し、ヒューマンエラーを排除。 - ビジネス的には短命に終わったが、技術的には「Java で実現できるデスクトップアプリの極致」に到達した。

# プロジェクト経験概要 キャリア初期から一貫して0→1の受託開発・自社サービス開発に従事。 Java、Delphi、Visual Basicなど多岐にわたる技術を習得し、20代からリーダーとして設計・実装・チームマネジメントを牽引。 オークションサイトや業務基盤システムなど、ミッションクリティカルなシステムの構築を完遂してきた実績を持つ。 # 開発・実装内容A：オークションサイト開発（2009年06月～2010年03月） ## 【概要】 - 2名体制でスタートした0→1の受託開発。 - 開発中盤での会社倒産と共同開発者の離脱という極限状態を、組織を動かす力で突破したプロジェクト。 ## 【どのような機能の開発・実装か】 - オークション基盤のフル実装: - 入札・落札ロジック、会員管理、決済連携など。 - 運営用管理ツール: - 全データをコントロール可能な管理画面の開発。 ## 【課題・問題点】 - 「会社倒産」と「ワンオペ」への急変: - 実装が50%程度進んだ段階で所属会社の倒産が決まり、ペアを組んでいたマネージャーが引き継ぎなしで離脱。 - 開発リソースが枯渇し、納期遵守が絶望的となった。 ## 【打ち手・使用した技術】 - 圧倒的な実装量によるカバー: - Java6 / Struts2 / Seasar2 (S2JDBC) / Mayaa を駆使し、残りの実装を一人で推進。 - 組織を動かすリソース調整: - 単に手を動かすだけでなく、CTOに直接交渉して社内からテスト要員を確保し、開発部長には客先同行を依頼するなど、エンジニアの枠を超えてステークホルダーを調整した。 ## 【成果】 - 予定通りローンチを完遂。 - サービスは他社へ無事移管され、その後数年にわたり安定運用された。 --- # 開発・実装内容B：メーカー向け／国際物流システム開発（2005年04月～2005年09月） ## 【概要】 - ソニーのデジカメ商戦に向けた、部品流通の需給バランス管理システムの構築。 ## 【どのような機能の開発・実装か】 - 需給バランス監視機能: - 物流全体を監視し、在庫の最適化を図る核心ロジック。 - テーブル・ストアド・クラス設計: - 複雑なデータ構造の全体設計。 ## 【課題・問題点】 - 仕様のブラックボックス化: - 全プロジェクトで2名しか詳細を知らない難解な仕様。 - 環境依存の致命的エラー: - ローカルでは動くが、結合環境でのみJavaからストアドが実行できない。 - Oracleドライバーのバージョン不一致を疑うも、公式の同バージョンjarと結合環境のjar（WebLogic同梱）でファイルサイズが異なるという怪現象に直面した。 ## 【打ち手・使用した技術】 - 低レイヤーの徹底調査: - Oracleドライバーをデコンパイルし、公式jarと結合環境のjarを比較。 - WebLogic同梱のjarから一部のOracle実装が削ぎ落とされている事実を突き止め、共通チーム側の原因であることを解明した。 - 超高速実装: - カオスな仕様を2週間でテーブル設計から実装まで完遂。 - 新日鐵SOL（一次請け）の担当者の横に張り付き、その場での指摘・修正を繰り返して品質を練り上げた。 ## 【成果】 - 4次請けの立場ながら、共通チームすら気づかなかった基盤側のリスクを特定。 - 需給バランス機能を完成させ、デジカメ商戦のロジスティクスを支えた。 --- # 開発・実装内容C：カタログ会社向け／商品データ管理システム開発（2003年07月～2003年12月） ## 【概要】 - 外部から「最終ジャッジ（使えなければ解雇）」として送り込まれた未経験者・リストラ候補者らに対し、技術指導とマインドセット改革を断行。 - 半年後、彼らを元の会社で部下を持つリーダー層へと成長させた、人材開発における成功事例。 # 【どのような機能の開発・実装か】 - 技術習得と当事者意識の醸成: - 未経験言語（Delphi/PL/SQL）の習得、および受動的な「指示待ち」から能動的な「エンジニア」への意識変革。 ## 【課題・問題点】 - 絶望的なチーム構成とマインド: - アサインされた5名のうち4名は、別会社で「リストラ候補」の烙印を押された40代・30代の未経験者層（COBOLプログラマー、テスター、製品管理）。 - 「イベント」という概念すら知らない 状態でありながら、当初は「指示がない」と不満を漏らす極めて受動的なマインドセット。 - 残る1名のSIer新卒も、意欲は高いが開発実務は未経験という、戦力として計算できない状態からのスタートであった。 ## 【打ち手・使用した技術】 - 「本質の理解」を促す教育の断行: - 「PCを触っていればイベントぐらい知っているだろう」という先入観を捨て、自ら**「イベントドリブン講義」**を緊急開催。 - 基礎概念の徹底的な言語化により、スキルの断絶を埋めた。 - 個々の適性に合わせた「成功体験」の設計（戦略的配置）: - Delphi（イベント駆動）に馴染めないメンバーに対し、その特性を否定するのではなく、彼らの得意な「シーケンシャルな思考」を活かせるPL/SQL専門職やPMO補佐へ役割を再定義。 - あえて背伸びしたタスクを与え、それを完遂させることで「自分でも作れる」という自己効力感を植え付けた。 - 「当事者意識」への点火（MTG同行）: - 最もセンスのあった31歳のCOBOLプログラマーを、あえて顧客との要件定義MTGに同行させた。 - 現場の熱量や顧客の悩みに直接触れさせることで、「作業員」から「課題解決者」へと意識を劇的に転換させた。 - デッドマーチを「連帯感」へ転換: - 1,000個の課題（その多くは不当な仕様変更）に対し、リーダーとして顧客側と冷徹に交渉する背中を見せることで、チーム内に「我々の成果を守る」という強い結束力を生んだ。 ## 【成果】 - 「リストラ候補」から「エリートリーダー」への変貌: - プロジェクト終了から半年後、彼ら全員が元の会社で部下を持つリーダーへと昇進したという報告を受ける。 - 単にツールが作れるようになっただけでなく、デスマを「自らの力で完遂させた」という成功体験が、彼らのエンジニア人生を180度変えた。 - 定性的評価: - 技術力が低い人間を排除するのではなく、「どうすれば勝てるチームになるか」を個々人のポテンシャルから逆算して再構築するマネジメント能力を証明。 - これは現在のVPoEとしての「組織を育てる力」の原点となっている。 --- # 開発・実装内容D：住宅販売向け／XML構文チェックソフトウェア開発（2002年04月～2002年12月） ## 【概要】 - 大手SIerの設計ミス（手動XML作成）によるパースエラー頻発を解決するためのバリデーター開発。 ## 【課題・問題点】 - 技術的・時間的制約: 当時Javaおよびオブジェクト指向は未経験。 - しかしMac版の開発が必要となり、納期はわずか1ヶ月であった。 ## 【打ち手・使用した技術】 - 言語の壁を越えた独力開発: - Windows版をVB6で先行リリース後、Java (Swing) を自学自習し、1ヶ月でMac版を構築しきった。美しさに逃げず「仕様通りに動き、納期を守る」ことを最優先に実装した。 ## 【成果】 - パースエラーをクライアント側で100%遮断し、運用の抜本的改善を達成。 - この経験が、後の技術習得スピードの速さに対する自信となった。 --- # 開発・実装内容E：バイク便向け／配車システム開発（2000年04月～2001年03月） ## 【概要】 - 「GPS付き携帯電話」がこの世に存在しなかった時代に、専用ハードウェア端末と地図情報を連動させた、当時としては驚異的な「配車自動化システム」の構築。 ## 【課題・問題点】 - 当時はライダーのリアルタイム位置把握手段がなく、配車は全て熟練者の勘に頼っていた。 - これを自動化するため、専用のGPS端末を全ライダーに搭載し、サーバー側で受信・処理する仕組みをゼロから構築する必要があった。 ## 【打ち手・使用した技術】 - Visual Basic / Perl / Oracle を使用。 - 時代を先取りした設計： - 全ライダーが携行する専用GPS端末から送信される緯度・経度情報を、サーバーで受信。 - 最短到着ロジックの実現： - 受信した座標データを地図上にマッピングし、配達先までの距離をリアルタイム計算。 - 「最短で到着可能なライダー」をシステムが自動選別して配達依頼を行う。 - 配達依頼を受けたライダーは、携帯端末にて承諾／拒否操作し、配達完了後は携帯端末にて完了操作するという、現代のデリバリーサービスと同様の設計を20年以上前に実現していた。 ## 【成果】 - 配車業務のDXを完全達成。 - 要件定義からサーバーセットアップ、顧客教育、常駐保守までを担い、現場のライダーがシステムを使いこなすまでを支え切った。 --- # その他のプロジェクト実績サマリー | 期間 | プロジェクト名 | 役割 / 技術 | 概要 | | :--- | :--- | :--- | :--- | | 2008/12-2009/02 | 顧客情報総合管理システム | Java, JasperReports | RailsとJava帳票の連携設計・開発。 | | 2008/08-2008/11 | 社内グループウェア連携 | **リーダー** / Java, iBatis | Aipoと自社システムのDB連携・同期設計。 | | 2005/10-2006/02 | SNSデータ連携システム | **サブリーダー** / Java, Hibernate | レコード会社向け。要件定義からバッチ・Web全般の設計を担当。 | | 2004/01-2004/04 | 音声ファイル転送システム | **リーダー** / Delphi, Java | メーカー向け。異言語間の通信プロトコルおよびDB連携を設計。 | | 2003/01-2003/06 | 建物共済管理システム | **リーダー** / Delphi, Oracle | 共通関数・コンポーネント開発およびメンバー育成。 | | 2001/04-2002/03 | 販売管理システム開発 | VB6, PL/SQL | ネットワークメーカー向け。帳票出力および会計連携を担当。 | | 1999/07-2000/03 | ネットワーク製品品質検証 | Linux, Windows | 台湾製製品の日本語環境検証および英語マニュアルの翻訳。 | | 1998/11-1999/05 | 顧客管理システム「ALADIN」 | COBOL, Oracle | NTTドコモ向け超大規模プロジェクトでのシステム調査・設計・実装。 | | 1998/01-1998/05 | 対潜水艦作戦情報管理システム | VB, Oracle | 自衛隊向け。ミッションクリティカルな現場での障害修正を担当。