言語化の練習帳：Technical Support Manager's Note

解析基盤を自作する：過剰な問い合わせへの「技術的」な回答を探して

今日は「サポート品質の維持」と「解析の効率化」の両面で動いた一日でした。 1. 問い合わせの「抑制」と「誠実さ」のバランス メールの検疫理由に関する詳細な問い合わせを頻繁にいただくお客様がいらっしゃいます。中には業務上の必要性が不透明なケースもあり、リソースの観点からは抑制も必要ですが、サポートとしてはメーカーとしての見解を誠実に返さなければなりません。 この「過剰な問い合わせへの対策」と「適切なレスポンス」の着地点を検討しました。 2. ないものは作る：Grafana + Loki で解析基盤を構築 製品の挙動（PR）を再現・確認するため、社内に独自の解析環境を構築しました。 お客様環境で動作確認をするわけにはいかないため、試行錯誤の結果、以下のスタックでログ解析基盤を作成しています。 構成: Eメールセキュリティ製品 → Nginx（待ち受け） → Promtail → Loki → Grafana 工夫した点: 製品が出力するシスログの形式（RFC3164）が古く、直接Lokiに送るのが難しかったため、Nginxをプロキシとして挟み、JSON形式のログを

組織の目標と、現場の「体温」。

今日は朝のルーチンであるサポートケースの状況共有から一日が始まりました。 午前：製品アップデートとプロセスの追跡 夜間に海外の開発マネージャーから「ホットフィックス（緊急修正）」リリースの連絡が入っていたため、朝一番で製品担当者へ共有。併せて、先日来進めているRMA（機器交換）プロセスのアップデート会議への出席依頼が届いていたので、カレンダーの調整を行いました。 午後：全社の方針と、足元のチーム状況 午後は、日本国内の各部門リーダーが集まる「All Handsミーティング」に参加しました。昨年の業績フィードバックから今年の目標まで、2時間に及ぶ共有。組織としての大きな方向性を再確認する時間となりました。 一方で、現場では「体温」を気にする場面も。 季節柄か、お子さんのアデノウイルス感染や、メンバー自身の急な体調不良が重なりました。穴が開いた業務をどうカバーするか、他のメンバーへの依頼や調整に動くのもマネージャーの大事な仕事です。勤怠システムでの承認作業を進めながら、健康管理の難しさを痛感しました。 夕方〜夜：明日に向けた布石 夕方からは、開発チームとの仕様確認に関する継続的なや

「調整」の一日：製品の宿題からグローバルの新プロセスまで

今日は朝9時から深夜まで、とにかく「調整と確認」が目まぐるしく続く一日でした。 午前：製品の「理想」と「現実」を繋ぐ まずはPR（製品改善リクエスト）の優先順位決めから。営業さんは「売上のために」、SEさんは「競合に勝つために」と、それぞれの視点がありますが、そこを整理してプロダクトマネージャーに繋ぐのが私の役目です。 深掘りしてみると「製品Aの問題だと思っていたら、実は製品Bのバグだった」なんて新発見もあり、開発への相談ルートを練り直す一幕もありました。担当者の離職などで止まっていたロードマップのフォローも欠かせません。 その後は、チームのシニアエンジニアによるナレッジ共有会に参加。旧バージョンの情報を、最新バージョンに照らし合わせて「今使える知識」にリバイズしてくれる取り組みは、本当に心強いですね。 午後：グローバルの仕組みを「日本流」にアジャスト 午後はRMA（機器交換）の新プロセスについての会議。グローバル主導のプロジェクトですが、日本には独自の商流や「日本語住所」の壁があります。 グローバルに対し、「いや、日本のお客さまにはUAT（受け入れテスト）が必要だ」と現場の声を

再発防止の仕組みと、コミュニケーションの「前提条件」を整える

月曜日。週末の間に溜まった案件の整理から、今週が始まりました。 今日は特に「再発防止」と「問い合わせの抑制」という、サポート組織にとって永遠の課題に向き合う時間が多い一日でした。 1. 開発部門への改善要求：再発防止の「納得感」 まず対応したのは、パートナー企業様を経由したお客様への回答です。 製品設定の問題で、回答済みではあるものの、お客様から「ピンポイントで何が問題なのか」について完全な納得をいただけていない状況でした。 改めて詳細を整理した結果、これは現場の運用回避ではなく、開発プロセス自体の改善が必要であると判断。開発部門へ正式に改善要求を上げました。 目標は、単なる事後処理ではなく、「どのような対策を打ったから、もう再発しないのか」を、自信を持ってお客様に説明できる状態にすること。開発からの回答を待つ段階ですが、一歩踏み込んだ提案ができたと感じています。 1. 問い合わせの「過剰」を、用語の共通言語化で防ぐ 次に、セキュリティ製品特有の「誤検出（False Positive / False Negative）」に関する問い合わせが頻発している件につい

指示と背景、そして自律性。

【Fact：連休明けの技術フォロー】 連休明けの火曜日。海外チームは動いているため、休み中のメールやJira（バグトラッキングシステム）のチケットをチェックすることから一日が始まりました。 APIの仕様変更により、特定のリクエストが通らなくなる問題が発生しており、開発チームとフォローアップを行いました。具体的には、レスポンスから不要な情報を削ぎ落とし、必要なデータのみを抽出するクエリ（MQL）の最適化について、製品チームと協議しました。 【Feeling：マネージャーがどこまで「手」を出すべきか】 元エンジニアということもあり、どうしても自分自身で検証を行い、エビデンス（証拠）を取りたくなってしまいます。マネージャーとしてのフォローのつもりでJiraにコメントを入れることも多いのですが、これについて他のマネージャーから「本来エンジニアがやるべきことを肩代わりしてしまい、彼らの成長の芽を摘んでいるのではないか」という指摘を受けました。 正直なところ、この言葉には少し凹みました。 私には私なりの考えがあります。一つは、テクニカルな理解があることを示すことで、エンジニアからリスペクト

はじめるにあたって

1. はじめに サポートエンジニアを20年経験し、ひょんなことからマネージャーになって3年が経ちました。現場のコードやログと向き合ってきた時間の方がまだ長い、そんなマネージャーです。 2. なぜ、いま「言語化」なのか AIが答えを瞬時に出す時代だからこそ、自分が何を考え、どう感じたのかという『プロセス』を言葉に残しておく必要性を感じています。自分の思考の癖を知り、解像度を上げるための稽古場としてここを使います。 3. このブログで書くこと 華やかな成功法則ではなく、日々の判断の迷いや、現場とマネジメントのギャップ、あるいは技術と人の接点について、淡々と整理していきます。 4. これからのこと 誰かの役に立つかはわかりませんが、基本以下のような視点で、まずは自分のために書き残してみます。 * Fact（事実）: 今日、何が起きたか？ *

Coming soon

This is site title, a brand new site by Daisuke Ota that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!