ID:83445さん

# プロジェクト経験概要 大手ゲームメーカー向けに、12言語以上の多言語展開を含む静的HTML/PSDコンテンツを 大量制作する案件において、ディレクター兼エンジニアとして単独で業務自動化システムの 設計・実装・運用を担当。 見積もり1,778人日の作業を、独自スクリプト群により実工数88人日(約1/20)に圧縮し、 利益率93.4%、外注費率4.5%を達成した。 # チーム情報 ディレクター/エンジニア:1名(自身) デザイナー:1〜2名(社内) コーダー:案件によって0〜1名 ※自動化システムの設計・実装はすべて自身が単独で担当 # 開発・実装内容A:Photoshop JSXによる画像自動生成パイプライン 【概要】 各キャラクター・アイテムごとに、規定のレイアウトで多言語バリエーション画像を 生成する必要があった。当初の見積もりではデザイナーが手作業で1点ずつ PSDを開いて差し替える前提だったが、対象は数千点規模。 【どのような機能の開発・実装か】 PSDテンプレートに対して、JSON定義から以下を一括処理するJSXを自作: - レイヤー単位での画像差し替え(キャラクター画像、背景画像、装飾要素) - テキストレイヤーへの多言語テキスト流し込み(12言語以上) - Photoshop変数機能と組み合わせた大量バリエーション出力 - 言語別のフォント自動切り替え - 書き出しファイル名のルール化と自動命名 【課題・問題点】 - 多言語化により1点あたりの実作業時間が手作業では現実的でない - 言語ごとにフォントが異なり、レイアウト崩れが発生する - 確認用の中間成果物(InDesign確認資料)も毎回手作業で作成していた - デザイナーが習熟するコストが高く、属人化のリスクがあった 【打ち手・使用した技術】 - Photoshop JSX:レイヤー操作・テキスト差し替え・書き出し処理を自動化 - InDesign Scripting:確認用の一覧資料を自動生成、レビュー工数を削減 - Shell:複数PSDの一括処理パイプラインを構築。watchフォルダ式で 「指定フォルダにJSONを置けば書き出しが完了する」運用に - Photoshop変数機能:言語別バリエーションの差分管理に活用 - すべて自身が単独で設計・実装 【成果】 - 見積1,778人日 → 実工数88人日(約1/20に圧縮) - 利益率93.4%(外注費率4.5%) - デザイナーは「JSONを書く」「最終出力を確認する」だけで成果物が完成する 運用フローを確立 # 開発・実装内容B:確認資料の自動生成システム 【概要】 クライアント向けの中間確認資料(全成果物の一覧PDF)を毎回手作業で 作成していたが、案件後半では1回の確認サイクルで数百ページ規模となり、 資料作成自体がボトルネックになっていた。 【どのような機能の開発・実装か】 - 書き出した画像群を自動で取り込んでInDesignドキュメントを生成 - 1ページあたりN点のグリッドレイアウトで配置 - ファイル名から自動でキャプションを生成 - PDF書き出しまでをワンクリック化 【課題・問題点】 - 確認資料の手作業ベース運用では、確認サイクルあたり半日以上を消費していた - 確認漏れ・配置ミスのリスクがあった 【打ち手・使用した技術】 - InDesign Scripting:成果物の自動配置・キャプション生成・PDF出力 - JavaScript (ExtendScript):InDesignのドキュメント生成ロジック - 自身が単独で実装、デザイナー・ディレクター双方の運用工数を削減 【成果】 - 確認資料作成工数を1回あたり半日 → 数分に短縮 - クライアントへのレビューサイクルを高速化、案件全体の納期短縮にも寄与 # 開発・実装内容C:ディレクターとしての要件定義・クライアント折衝 【概要】 初期トライアル案件時に、別ディレクターが担当した際の見積もり不備が原因で クレーム一歩手前の状態となっていた。途中からディレクターを引き継ぎ、 要件の再整理・スコープ調整・追加見積もりの交渉を実施。 【どのような機能の開発・実装か】(※非エンジニアリング業務) - クライアントとの仕様再ヒアリング、認識齟齬の解消 - 工数再見積もりと追加費用の提示・合意形成 - 信頼回復のための継続的なコミュニケーション設計 【課題・問題点】 - 既に発生していた工数オーバーをどうクライアントと共有するか - 信頼関係が悪化した状態からの巻き返し 【打ち手】 - 自動化システムの開発により、追加スコープを「追加費用ありで吸収可能」と提示 - 透明性の高い工数報告と、自動化による効率化の見える化 - 「効率化システムによる利益率改善」を継続案件のセールスポイントとして再提示 【成果】 - クレーム化を回避し、利益率93.4%を達成 - 来期も継続契約を獲得、複数の追加案件にも発展 - クライアントからの信頼を取り戻し、現在も拡大中

# プロジェクト経験概要 大手出版社のライツ事業部向けに、書影・バナー素材の監修管理システムを 新規構築したプロジェクト。要件定義・設計・テスト計画・運用保守を ディレクター/プロジェクトマネージャーとして単独で担当(実装は社内エンジニアが担当)。 当初は1編集部のみの導入だったが、運用実績が評価され、現在は全マンガ編集部で 使用される基盤システムへ成長。稼働4年間トラブル0件、月100件以上の監修依頼を 処理する安定稼働を維持している。 年間売上1,026万円、利益率78.6%。 # チーム情報 ディレクター/PM:1名(自身) エンジニア:1〜2名(社内、実装担当) クライアント側:複数編集部のマンガ編集者、ライツ事業部担当者 自身の担当:要件定義、設計、テスト計画、運用保守対応、クライアント折衝、改修ディレクション エンジニアの担当:コーディング、サーバー構築・運用 補足:同クライアントのデジタル販売部向けに、自身が以前ディレクションした 類似システムが存在。その経験を本案件に活かしている。 # 開発・実装内容A:多種メディア対応の監修フロー設計 【概要】 従来メールベースで行われていたバナー素材の監修フローを、Webシステム上に 集約するための業務システム設計。 同クライアントのデジタル販売部向けに、自身が以前ディレクションした 類似システムが既に稼働していたが、ライツ事業部の要件は対象メディアの種類・ ワークフロー・関係者構成が大きく異なっており、別システムとして再設計が必要と判断。 【どのような機能の開発・実装か】 - 静止画バナー(JPG/PNG)・アニメーションGIF・PDF・動画ファイル(MP4)の プレビュー機能を一画面で統合 - 素材プレビュー上に枠を描画してコメント可能なUI(ピンポイントで指摘可能) - ステータス管理(新規/監修中/OK/再依頼/承認済) - 履歴データベースとして全変更履歴を保持 【課題・問題点】 - 既存のデジタル販売部向けシステム(自身が以前ディレクション)はノウハウがあったが、 ライツ事業部要件にはマッチしなかった - 対象メディアの種類が異なる(動画・アニメGIFへの対応が必須) - ワークフローが異なる(編集部チェック → 取引先確認 → 編集部承認の3段階) - 関係者構成が異なる(複数編集部 × 複数取引先のマトリクス) - 「既存システムをカスタマイズ」では破綻すると初期段階で判断、別システムとして再設計 - メールベース運用では、どのバージョンが最新か把握困難だった - 多種メディアをひとつのUIで扱う必要があった(動画ストリーミング含む) - マンガ系のため著作物として履歴保持の要求が強かった 【打ち手・使用した技術】 - 既存システムの設計思想(ステータス管理・履歴管理・通知設計)は流用しつつ、 ライツ事業部用に仕様を全面再設計 - 動画はAWSのメディア変換サービスでストリーミング形式に変換し、 サイト上でプレビュー可能に - アカウント権限・所属会社による表示制御で、複数の協業社が 情報漏洩リスクなく同一プラットフォーム上で運用可能な設計 - リマインドメール機能による業務フロー自動化(担当者への通知設計) - 使用技術:PHP / JavaScript / MySQL / AWS(メディア変換・S3) / Linux 【成果】 - メールベースの業務をシステム上に集約、運用負担を大幅に削減 - 「監修履歴がデータベースに残る」点を評価され、ライツ事業部の標準ツールに - 同クライアント内で複数事業部にまたがるシステムを継続的に担当することで、 クライアントとの長期信頼関係を構築 # 開発・実装内容B:他編集部への横展開と多社協業対応 【概要】 当初1編集部のみだった導入が、運用実績の評価により全マンガ編集部へ 拡大。それに伴い、複数編集部・複数取引先(電子書店等)が同一システムを 使用する状態となり、アクセス制御と運用設計の再検討が必要になった。 【どのような機能の開発・実装か】 - 編集部単位での依頼管理(他編集部の依頼は見えない) - 取引先(電子書店等)単位での表示制御(他社の依頼内容は見えない) - アカウント権限による画面表示の動的切り替え 【課題・問題点】 - 取引先同士は競合関係にあるため、情報の見せ方を厳密に制御する必要があった - 編集部ごとに微妙にワークフローが異なる - スケールに伴い、月間依頼数が10件→100件超に増加 【打ち手・使用した技術】 - 多テナント的なアクセス制御を設計(編集部 × 取引先のマトリクスで権限管理) - ワークフローの差分はステータス定義の追加で吸収できる設計に - パフォーマンス問題が出る前に、検索・フィルタ機能を強化 【成果】 - マンガ系編集部全体での利用に成長 - 月100件超の依頼処理を稼働4年間トラブル0件で維持 - 定期改修・運用保守費用として継続的な収益化(年間1,026万円、利益率78.6%) # 開発・実装内容C:長期運用における信頼性確保 【概要】 稼働4年トラブル0件という安定運用は、初期設計だけでなく 継続的な運用保守設計の結果。 【どのような機能の開発・実装か】(※運用設計) - クライアント側からの改修依頼を起票→仕様確認→実装→テスト→リリースの 運用フローを確立 - 改修内容のドキュメント化を徹底し、長期メンテナンス性を担保 - 重大障害が起きないようテスト計画を毎回再設計 【課題・問題点】 - システムを担当するエンジニアが交代する可能性に備える必要があった - 4年の運用中にクライアント側の体制変更・取引先追加が複数発生 【打ち手】 - 仕様変更時は必ず影響範囲ドキュメントを作成し、エンジニアと共有 - リリース前テストを必須化(クライアント側でのUATも標準化) - クライアント側の連絡窓口を一本化し、依頼の取りこぼしを防ぐ運用設計 【成果】 - 稼働4年トラブル0件 - クライアントからの信頼維持により、運用保守費用が安定収益化 - 関係性を活かし、別の年表サイト案件の受注にも繋がっている

# プロジェクト経験概要 全社的なクラウド基盤として、AWS Serverless構成のテンプレート化と 新規SaaS商材としてのパッケージ化を実施。CTO直下のPX推進担当として、 構想・設計・実装・運用・社内展開までを単独で担当。 最初の適用事例として、社内のライブエンタメ事業部向けに 100名超のライバー向けレポートシステムを構築。手作業ベースだった運用を Webシステムに昇華し、人件費を極小化した。 # チーム情報 構想・設計・実装・運用:自身単独 社内ステークホルダー:CTO、各事業部の業務担当者 実装方針:AWS CDKによるIaC化を徹底し、複数案件への横展開を前提とした テンプレート化を行った。コーディングは生成AI(Claude Code、Cursor)を 活用しつつ、アーキテクチャ設計・統合・デプロイ判断は自身が行う体制。 # 開発・実装内容A:AWS CDKによるServerlessテンプレートの設計 【概要】 全社で再利用可能なAWS Serverless構成を、AWS CDKで完全にコード化した テンプレートとして整備。 【どのような機能の開発・実装か】 構成要素: - Frontend:S3 Hosting + CloudFront(Custom Domain via Route53) - Backend:API Gateway + Lambda(複数Function構成) - Database:DynamoDB(複数Table構成) - Security:WAF v2、ACM(SSL)、Rate Limiting - IaC:AWS CDK(TypeScript)で全構成をコード化 - CI/CD:GitHubコミット → CDK deploy → CloudFront invalidation の自動化 【課題・問題点】 - 受託案件で毎回サーバー構成を作り直すと、構築・運用コストが膨大 - 外注サーバー費が利益を圧迫していた - 案件ごとに微妙にカスタマイズが必要だが、ベース設計は共通化したい 【打ち手・使用した技術】 - AWS CDK(TypeScript)で全構成を**コード化**し、新規案件にはStackを 複製するだけで基本構成が完成する状態に - 環境分離(本番/R&D)を別AWSアカウントで運用し、デプロイフローを統一 - WAF v2でIP制限を組み込み、管理画面アクセスを保護 - ドメイン管理(Route53)・SSL(ACM)・CDN(CloudFront)を一括で デプロイできるStack設計 - TypeScriptは自身の弱点領域だったため、Claude Code/Cursorを活用し 生成 → 検証 → 統合の流れで開発 - 設計判断・最終統合・デプロイ判断はすべて自身が実施 【成果】 - 新規案件のサーバー構築工数を**ゼロベースから数時間レベル**に圧縮 - 外注サーバー費を削減、新たな収益源として社内に展開可能なパッケージ化 - 営業時の提案用Mockサイトもこの構成で即時構築可能となり、受注確度向上に貢献 # 開発・実装内容B:ライバーレポートシステム(最初の実適用) 【概要】 ライブエンタメ事業部の業務として、100名超の所属ライバーへ毎月パフォーマンス レポートをExcelで配信していたが、集計・PDF化・配信がすべて手作業で 人件費が嵩んでいた。これをWebシステムに置き換えた。 【どのような機能の開発・実装か】 - ライバー個別のログインとダッシュボード閲覧機能 - 月次レポートの自動生成(配信時間・再生数・ギフト数等のKPI表示) - グラフによる時系列推移の可視化 - 管理者向け一覧画面(全ライバーのKPI俯瞰) - ライバーごとの個別コメント・フィードバック欄 【課題・問題点】 - 100名超のレポートを月次で個別Excelで作成していたため、業務担当者の 工数が膨大 - ライバー側からのレポート閲覧体験も統一されておらず、配信ミスのリスクもあった - 業務担当者は非エンジニアであり、CMS的な使いやすさが必要だった 【打ち手・使用した技術】 - API Gateway + Lambda(×4 Functions)による軽量バックエンド - 認証Lambda(Cognito連携) - データ取得Lambda(管理者用) - データ取得Lambda(ライバー用) - 管理用Lambda(コメント・データ更新) - DynamoDB(×4 Tables)でデータ管理 - ユーザーテーブル / レポートテーブル / コメントテーブル / 監査ログテーブル - フロントエンドはS3 + CloudFrontで静的配信 - グラフ描画はChart.js - 業務担当者向けのCSV一括インポート機能を追加 - すべて自身が単独で設計・実装・デプロイ 【成果】 - 月次レポート作成工数を大幅削減(数人日 → 数十分) - ライバー側からも閲覧体験が改善されたとフィードバック獲得 - システムをテンプレートとして、他事業部への横展開も検討中 # 開発・実装内容C:Mock提案による営業支援への展開 【概要】 受託案件の営業フェーズで、提案時に動くプロトタイプを用意できると 受注確度が上がる。これを上記Serverlessテンプレートを使って実現。 【どのような機能の開発・実装か】 - 提案案件ごとにサブドメインを切り、CloudFront経由でアクセス可能なMockを 数時間で構築 - WAF v2でIP制限し、対象クライアントのみアクセス可能に - 提案後、不採用の場合はCDKでStackを削除するだけでクリーンアップ完了 【課題・問題点】 - 静的なワイヤーフレームだけでは提案の質に限界がある - 動くMockを毎回作るとコストがかかりすぎる - 提案不採用時のクリーンアップも煩雑だった 【打ち手・使用した技術】 - AWS CDKで「提案用Mock Stack」をテンプレート化 - WAF v2でアクセス制御することで、本番想定の体験を安全に提供可能に - IaCのため、提案不採用時はStack削除コマンド1つでクリーンアップ完了 【成果】 - 営業時の提案品質が向上、受注確度の改善に貢献 - 内部リソース(外注サーバー費・構築工数)の発生なしで運用可能