こんにちは～。

50もあるクライアントと日々向き合い、鬼のように多いプラットフォーム機能に関して毎日えっさほいさとFAQしたり、どうやったら要望を満たせる機能を提案できるか、日々研究を重ねております。
DMMPF（たこちー）のhayashiです。

今回は、私たちのチームの重要ミッションである、DMMの全クライアントに正しくPFの機能を伝えるための工夫としてやっている日々の施策をご紹介します

前提

DMMはすごい事業数がある（50くらい）
プラットフォームのチームも20くらいある。#大変
そのチームごとに機能もたくさんある。（数えたことはありません…）

各クライアントが作りたい機能やサービスに対して、PFのAPIや機能やインフラ環境を正しく選定して、伝達する仕事を行っています。

そのために、 どの機能やAPIが最適で、どうやったら使えるか、を正しく手ほどきする必要 がある。
今回の記事では、それを実現するために日々私たちがやっている施策をご紹介したいと思います。

大小の問い合わせに対応し、そこから学ぶ

問い合わせの解決はチームメンバーに偏りなくやる
問い合わせの大小で解決までの手段を変更する
質問に対しては事業のナレッジをとにかく漁る
理解できたことは、チームにFBする（学習）

PFでは私たちのチームだけでも月間60件ほどの質問や相談があります。
中には秒で解決できることも、会議を何度も重ねて解決に促すものも様々です。
その対応にはチーム5名のメンバーを、バランスよく問い合わせに対応する工夫をしてます。
誰かに偏ると、結果回答できるスキルや知見が偏ってしまうので、苦手な分野でもできるだけ偏りなくアサインをすることを心掛けてます。
また、分かったことはチームにFBするようにして、自分だけの知識にせずそれを与える環境にしています。
結果、誰に相談がきても正確かつスピードをもって伝達できるようにしています。

問い合わせのボリュームからナレッジ化する。

ナレッジ化すべきもの質問にはフラグをつける
似たような質問はFAQ式ですぐにナレッジ化する

これは当たり前ではありますが、常設運用にするととても価値がでます。
ナレッジを作るのはかなり時間がかかりますが、FAQ式（一問一答式）でアーカイブする程度であれば、10分程度で終わりかつ量産されるので、困ったときに引き出せるようにしています。

PFの機能やAPIを正しく覚える

正しさとは仕様の理解だけではなく、変更の時系列も理解する
- 過去のパラメータの仕様が変わったこと
- 新しくできたパラメータの背景や用途を知る
APIの用途以外に制約を知る
APIの最適な利用ユースケースを知る
API仕様書をチームで読む

これも当たり前ではありますが、重要なのは小さい変化でもキャッチアップしておくこと。
またユースケースを知ることで、利用できても最適性がない使い方を提案しないように、提供側の背景を知っておくことを大切にしています。
さらに新しく参画したメンバーには、API仕様書を読み合わせることを行い、用途やデータの形やAPIごとのつながりをイメージできる学習施策を行っています。

APIナレッジは最新化する

プロダクト（専門）チーム以外でも必要に応じて更新をかける
- 補足資料とのつながりが必要であれば補記する
- 言い回しによって読み手が混乱しそうであれば表現を変える
管掌が変わるものはすぐに新しい管理元に移管をする

（最後に）機能やAPIに対して不足があると気づけば改修の提案を行う

どれだけAPIや機能があっても、多数を組み合わせないと使えなかったり、クライアントの要求に対する再現性がないものを提供し続ければそれは意味のないものになります。
汎用性を意識することも重要ですが、結果的に利用シーンにミスマッチな構成になっている場合には、カラムの追加を希望したり、API利用の複雑性を避けるためにアプリケーション化して提供するなどの解決方法を提案して、改修まで進めるようにしています。

今後やりたい施策

ナレッジの可読性を高める
ナレッジを1つのツールに集約する　など

そもそもクライアントが自己解決できるリファレンス環境にできないかな～と試行錯誤中です。

ご拝読ありがとうございました！

クライアントに対して正しく機能を伝達するには、こういった施策をルーティーン化し長期的かつ形骸化をしないように続けていくことが大切だと感じています。

施策の中には、コストを下げるための自動化の工夫も実践しているので、
興味がある方は以下もご参考くださいませ。

前提