ID:69354さん

【プロジェクト概要】 - 自社サービスのユーザ情報を集約する、Single Source of Truthのための社内基盤のAPI/画面サービスの構築。 【実行した主な問題解決】 1. 海外出身のテックリードのサポート - 問題: ドキュメント整備や他チーム調整の進捗が芳しくない。 - イシュー: 日本語ネイティブではないテックリードの、日本語の設計Doc作成/日本語で行うチーム間ミーティング・調整の負荷を以下に減らすか？ - 制約: メンバ（私）も、開発タスクを抱えており、リソースに余裕があるわけではない - 打ち手 - Doc作成: まずリードに「正しい日本語文法を気にしなくていいので」Doc作成するように提言->細かい文法は私の方で修正するというプロセス設計、実行 - 他チーム調整: 基本はリードを立てて、「マイナーな日本語表現が登場した」、「意思疎通の齟齬が生まれたかも」というシーンで割り込んでファシリテートする - アウトカム: ２人の工数効率が最大が最大化される形でボトルネック解消 2. 実装しながら、Biz側と仕様を共同構築 - 問題: 仕様の手戻り、そもそも決まっていないことに対する確認リードタイムがかかっていた - イシュー: 仕様を決定する意思決定権の所在・プロセスを以下に明瞭化するか？ - 制約: １案件に対して避けるPMのリソースが極小 - 打ち手 - エンジニア主導で仕様を決めていく - 決定者はPM。意思決定にあたり、1. 推奨案 2.オプション 3. 理由（比較軸） とう形式でPMに提案するフォーマット/プロセスの整備 - アウトカム: 納期通りのリリースを達成 【技術要素】 - typed python - Django Rest FrameworkによるAPI開発 - Docker - ALB-Fagate-Auroraなどなどの構成。IaCはCDK - CICDIパイプラインの構成。IaCはCDK - 社内IDaasとのOIDC認証 【実績・取り組み等】 - バックエンド全般を担当。 - 分散トランザクションでの一貫性の設計 - バックエンドサービスのインフラを担当。 - データモデルの設計、実装。 - インターネットフェイシングなAPIの開発。 - CDKによるパイプラインを独学し構築。 - 監視系についても実装 【チーム構成】 - 5名（PM: 1、Biz: 、1リード:1、エンジニア: 2 ） - メンバーエンジニアとしてアサイン

【プロジェクト概要】 - https://trend-insights.fa-biz.deloitte.jp/ - 一般公開サービスのフロントエンド担当。 - キュレーションした記事情報を全文検索エンジンに溜め込み、それに自然言語処理を施した分析結果をビジュアライゼーションする。 【行った問題解決】 1. 一般公開レベルのUIに引き上げる - 問題: UI/UXのクオリティを一般公開toCサービスとしての水準に引き上げる必要性が存在。（ステークホルダが納得していなかった） - イシュー: デザイナーリソースが不在の中で、以下にtoC商業レベルのUI/UXにもっていくか？ - 制約: 社内のデザイナーリソースの確保が困難 - 打ち手 - 技術スタックの再選定: UX確保という課題実現のため、django+templateで書かれていたフロントエンドを、Reactに再選定/リプレース - デザイナ負荷最小限の形での協業: フロントエンドエンジニア（私）がデザイン含め実装する -> ブラッシュアップ必要なポイントのみをフィードバックしてもらう形をとった - UIデザインはプライベートでどうにか最小限キャッチアップ - アウトカム: ステークホルダに納得いただくレベルまで UIを引き上げ、無事リリース 【技術要素】 - React、HTLM/CSSのコーディング全般をほぼ独力で担当。レスポンシブについても対応。 - RadixUI、stitches(CSSinJS)、Jotai(状態管理)などのライブラリを選定、使用 - データ処理はd3.js、そのビジュアライゼーションはsvgで実施(その過程でチャート系ライブライも一通り検証)。 【実績・取り組み等】 - 当初、djangoのビューとJavaScriptで書かれたいたフロントエンド(モック的状態)を全面的にReact＋TSにリプレース。 - モック的状態からのUX/UIのブラッシュアップをデザイナーと協業で実施 - フロントエンドのライブラリは全て独自で調査、チーム説明の上選定し実装。 - 状態管理については当初recoilを使用していたが、ライブラリによりメモリリークを発見、jotaiに乗り換えることで問題解決した 【チーム構成】 - エンジニア３名 - メンバとして参画

【プロジェクト概要】 - 社内向けサービスのAWSへのシフト案件（AzureVM -> AWS）。インフラと認証部分の機能追加を担当。 【バリュー概要】 - 社内業務アプリの、セキュリティと手動運用コストの課題を解消 - 費やせる期間・コストを踏まえ、移行戦略から移行後アーキテクチャまで提案->実装 【行った問題解決】 1. コスト期間制約の中での移行戦略提案・実行 - 問題: 既存の社内アプリについて、1. セキュリティリスク 2. 手動運用負荷=運用コスト高 が存在。特に、コスト面について利用部門から懸念が存在していた - イシュー: 潤沢ではない予算・期間の中で、如何に1. セキュリティリスク 2. 手動運用負荷を減らすか？ - 打ち手 - アプリの構造は変えずに、ECS+AuroraへのReplatformを見積り提案・実装 - アウトカム: 社内エンドユーザのコストに対する納得感も獲得しつつ、自部門の運用負荷軽減 【技術要素】 - PythonのDjangoアプリ - Docker - ALB-Fagate-Auroraなどなどの構成。IaCはCDK - 社内AzureADとのSAML認証 【実績・取り組み等】 - AWS構成設計から担当（上位者のレビュー有り）。 - インターネットに面さない、プライベートなVPCの中での構成 - IaC（AWS CDK）を独学し使用 - 監視系についても実装

【プロジェクト概要】 - コンサルとしてのアサイン - salesforceベースの業務系のQA -> 次期改修案件の要件定義 【行った主な問題解決】 1. クライアントから信頼獲得 - 問題: 支払っているコンサルフィー相応のバリューが出ているか、クライアントからの不審が存在した。 - ex) 定期的に、ワーキンググループのエリアにそれとなく視察に来る - イシュー: 根本的なスタイル/熱意レベルの領域での信頼を如何に獲得するか？ - 制約: join直後で、現場のドメイン知識など無い - 打ち手 - 非論理的だが「本気でやった」としか言いようがない - プライベートでドメイン知識にキャッチアップ - 発生している時間あたりのフィーを意識し、常に張り詰めて動く - アウトカム - クライアントの「見回り」はなくなり、後に50名を超えるコンサルのデリバリーに繋げた。 - 莫大な売り上げを計上した案件の最初の３人のメンバのうちの一人であった。 2. 現場システムの知識補完 - 問題: 対象となるシステムのQAおよび次期改修要件定義にあたり、既存要件が不明 - イシュー: 現場レガシーシステムについて、自社に有識者が不在の中で如何に仕事を完遂するか？ - 制約: 既存要件のノウハウがあるキーマンは、自社とは別のベンダに存在 - 打ち手 - 自社の作業スペースではなく、ベンダの常駐しているビルに出社 -> 隣などに陣取り、コミュニケーション - こちらも、クライアントに近い立場からの情報を早期提供するなど、giveを意識 - クライアントへもノウハウ共有の必然性説明 -> トップダウンで指示いただく - アウトカム - QAおよび次期改修要件定義について納期通り完遂 - 有識者保有ベンダとのコネクション 3. 自社への不当なリスク転移の回避 - 問題: 対象知識が全く無い状態で、受け入れテスト実施にアサインされる。期間も短い - イシュー: 役割範囲・期間等についてクライアントと事前に握っていない中で、如何に自社リスクを抑えつつタスク完遂するか？ - 制約: 「無理だ」とは言えない - 打ち手 - 期間を考慮し、現実的なQAプランを提案、説得 - 重点的に保証したい機能など、優先度をクライアントと協議->決定というプロセスを取る - 自社として「保証するのはこの範囲ですよ」を明確に握る - アウトカム - クライアントの納得感も獲得しつつ、納期通りにタスク完遂 - 自社にリスクを不当に転移されることを予防した 【技術要素】 - salesforce(基幹系) + djangoの受付システム（テストを担当） - salesforce(基幹系) + djangoの受付システム（次期改修の要件定義を担当） - excelなど