ID:67404さん

### 課題 - 現金化機能のビジネス要件（「クリエイターポイント」の付与タイミングや有効期限など）や、使用する外部API（Trustdock / SBPS）は決まっていた一方で、業務フローやデータフローは未整備のまま開発フェーズに入っていた。 - ユーザー側UIは一部設計が進んでいたが、管理画面は未着手で運用面の視点が欠けており、TrustdockとSBPS間でのステータス不整合や中途半端なデータ状態による将来的な障害リスクについても社内では議論が行われていなかった。 ### 思考 - 誰がどの条件を満たしたときに、どの処理が動作し、どのような状態になるかを設計しない限り、安定運用は不可能だと感じた。 - 外部サービスがそれぞれ非同期でステータスを持つ中で、状態遷移の整合性を保つデータ設計とUI設計が必要だと判断。 - また、ユーザーの問い合わせやCS対応時に「ステータスの詳細、理由等が即座に把握できる運用体制」も求められると考えた。 ### 工夫 - 状態を複数のテーブルで極力持たず、整合性の取りやすい単一状態管理を目指した。 - ステータス設計を極力シンプルに抽象化し、「処理待ち / 進行中 / 完了 / エラー」に統一。 - 再処理や手動操作でも破綻しないように、処理の冪等性を意識した設計を各バッチ処理・Webhook連携で実装。 - 管理画面はUI設計から自ら着手し、情報の可視性・操作性を重視したモックを提示。 - 開発工数を抑えるため、本質的な機能に限定してデザイナーに明確な要件を提示。 - 経理向けの送金トラッキングには、処理履歴の可視化を目的として、専用のappend-onlyテーブルを導入。 ### 成果 - KYC〜送金までの現金化フローが初回リリースで安定稼働し、手動介入や障害ゼロを達成。 - 状態設計の簡略化により、CSチームの問い合わせ対応が迅速化し、社内運用の負荷がわずか。 - KYC・送金フローに関する全体像をもっとも正確に把握している立場として、仕様相談・QA・ドキュメント整備にも貢献。

### 課題 - WordPressを用いたコーポレートサイト制作会社において、仮ドメインの発行（開発環境構築）およびサイト公開作業（本番移行）が事務担当者1名に集中しており、業務負荷の偏りが課題だった。 - ユーザー追加やメンテナンスモード移行などの設定作業も含め、事務担当者の作業がプロジェクトのボトルネックとなっていて、社長も問題視していた。 - プロジェクトに参加した直後に自動化に向けてSeleniumを用いたが、UI変更に弱く、保守性が低いという課題に直面。また、GitHub Actions経由での自動操作は、海外IPからの攻撃を受けるなど、セキュリティリスクも顕在化した。 - 仮ドメインは認証をかけるとエンドユーザーの確認の手間が増え、かけないと公開状態になりセキュリティのリスクがあるというジレンマがあり、この両立が求められた。 ### 思考 - 単純な作業の自動化に加え、業務の再設計が必要と判断。 - UI依存の高いブラウザ自動操作だけに頼るより、WordPressプラグインとGo製CLIツールによる安定稼働・再利用性の高い構成へシフトする必要があると感じた。 - ツール導入で逆に工数が増えたり、メンテナンスで時間が取られることがないようメリットがある業務を選定する必要があると考えた。 - 既存のプラグインに頼るより、自社のニーズにあったプラグインやcliツールを作成する方が、引いては他社との差別化ができると考えた。 ### 工夫 - 自社製のWordPressプラグインを開発し、標準でサイトに搭載させ、外部からのREST API経由で設定が可能にした。 - GoogleスプレッドシートとGASを連携し、現場オペレーターでも操作可能な業務トリガーを提供。 - 認証フローでは、ユーザーに認証操作を意識させずに済むよう、クエリパラメータ＋ハッシュ認証によるトークン方式を採用。 - メインと共通キーワードから生成したハッシュをsecret_config.phpに保存し、トークン認証でログイン不要の軽量認証を実現。 - API実行元をIP制限とサーバー側制御で限定し、海外IPからのアクセスも遮断。 - 記事削除・ユーザー削除・パスワード変更など危険な操作は非公開とし、誤操作のリスクを排除。 - 自動化しすぎることでかえってセキュリティリスクが高まる箇所は全自動化を避け、半自動化でバランスを取る判断を徹底。 - 全ての処理結果はSlackに通知され、即座に成功/失敗を可視化する運用体制を構築。 ### 成果 - 案件受注ペースが増加したにもかかわらず、運用チームの増員は1名のみで済み、業務効率が明確に改善。 - 導入初期はエラーが散見されたものの、仮ドメイン発行〜サイト公開の一連業務が安定的に稼働。 - 作業担当者の負荷軽減に加え、営業の生産性も上がり、お客様に迅速に初期サイトを提供できるようになった。 - 仮ドメイン時点でのお客様への問い合わせ（架電）が0件になり、業務の混乱を解消。 - 開発したプラグインやCLIツールは現場で必須インフラとして定着し、運用チームから「誤って削除したため再提供してほしい」と要望が届くなど、なくてはならない存在となった。 - Slack上に通知が流れるようにし、目に見える形で“業務のDX化”を社内に浸透させた。