---
title: "能力 · Charlie Tang Hoong"
url: https://cv.tanghoong.com/ja/capabilities/
locale: ja
description: "顧客の要件把握と提案定義、応用 AI と業務自動化、ソリューション設計と基幹システム連携、本番運用、そして技術面のデリバリー —— 各項目はそれを裏づける事例にリンクしています。"
---
# 提供できること

事業にとって何をするかで分類しています。ツールは各項目の下に置いています。順序は意図的です。

## 顧客の要件把握と提案定義

課題を抱えている本人と直接やり取りします —— 運用担当者、創業者、顧客側のエンジニア —— 不完全な要望を、範囲が明確で、金額があり、「完了」の定義が共有された提案に変えます。これは両側から経験しています：事業会社の内部では業務プロセス担当としてドキュメントのない経理・物流の業務を図にし、外部のエンジニアとしては AI システムを買ったことのない中小企業の案件評価を行いました。

関連技術: 要件把握 · As-Is / To-Be 業務整理 · 費用を含む構築見積もり · 着手前の書面合意 · 関係者ワークショップ

## 応用 AI と業務自動化

実際の業務のなかで動く必要がある AI です：帳票からの項目抽出と、書き込み前の人による確認工程。カスタマーサポート AI の知識構成、ツール呼び出し、会話管理、有人への引き継ぎ。そして経理と物流にまたがる、もともと手入力だった RPA。

関連技術: OpenAI / Claude APIs · RAG · 検索チューニング · prompt のバージョン管理 · tool calling · OCR（PyTesseract）· Power Automate · Datagrand RPA · Selenium · LangChain / LangGraph（評価済み）· Ragas（PoC）· n8n · Dify

## ソリューション設計と基幹システム連携

つながる前提で作られていないシステム同士をつなぎます —— 顧客の旧来 ERP、API のない元システム、外部の EC・決済プラットフォーム、メッセージキュー、そしてその間に挟まる人手の工程。繰り返し出てくる判断は「買うか作るか」で、私は両方を十分な回数やってきたので、本当に面白い問いがどこにあるかを知っています：どの制約が「買ってきた部品」を成立させなくするのか。

関連技術: REST API 設計 · OpenAPI / Swagger · webhooks · OAuth 2.0 / JWT · RabbitMQ · Redis · PostgreSQL / MySQL · Shopify API · Stripe · PayPal · 侵襲的でない連携

## 本番運用と信頼性

動き出したあとも、責任は私にあります。長い処理は最初からではなく途中から再開します。失敗は、人がまだ手作業に戻せる時点で表に出します。キューで処理し、遅い 1 件が次の顧客を待たせないようにします。送信は冪等にし、再読み込みで二重に走らないようにします。使われていないリソースは、抱えたままにせず解放します。

関連技術: queue workers · 非同期処理 · チェックポイント再開 · 冪等な送信 · キャッシュ戦略 · Docker · NGINX · CI/CD · AWS / GCP / Azure · 監視とアラート

## 技術デリバリーと関係者調整

私が率いるのはデリバリーと技術判断であって、人数ではありません：チームの意見を聞いたうえでの最終的な設計・技術選定の決定、チームが実際に従うコードレビューの運用、そしてエンジニアが本当に詰まっている場所から引き出すこと —— 私の経験では、それはほぼ必ずコードではなくインターフェース契約です。

関連技術: 技術リード · コードレビュー運用 · メンタリング · スプリント計画と作業分解 · 3 言語でのデリバリー（English · 中国語 · Bahasa Malaysia）

## 業務で使う言語

英語、中国語、マレー語で仕事をしています。