1年間で感じた、社内ツール開発のポイントと注意点

エンジニアのamakawaです。先日、リリースから関わってきた社内ツール（CRM）がリリース1周年を迎えました。めでたい！🎂

この1年間、開発・改修・運用サポートの全てに携わり、開発の難しさを何度も感じました。

それと同時に気づいたのは情報の少なさです。
toC>toB>>>>>>社内ツール、という印象で参考にできる情報があまりにも少ない。

だからといってtoCやtoBの方法をそのまま取り入れられるか？といえば、恐らくNOです。
社内ツールは、課題発見から解決まで社内で行うからこそ、出来ること・気を付けるポイントがあります。

「情報が無いなら発信だ！」ということで、自分が課題発見→解決方法の決定→運用の各フェーズで気をつけていることをまとめました。

ToC・toBサービスと社内ツールの違い

ユーザーとの距離が近い

社内にユーザーがいるので、ヒアリングやトラブル時の現状把握のしやすさはメリットです。

一方で、メリットを活かすにはユーザーと適切にコミュニケーションを取らなければいけません。
ユーザーの意見に振り回されて差込み作業が続いたり、「直接意見を言ったのにいつまでも対応しない」と思わせてしまうと、距離の近さが裏目に出る場合があります。

ユーザーは社内ツールを使わなければいけない

社内ツールにおいては、ユーザーはツールに多少の不備があっても離脱は許されません。

そのため、少しの使いづらさが積もり積もってユーザーに大きなストレスを与えます。また、CS/BSの作業に支障を与えればそれはコストです。

フローの変化への対応と運用カバーのバランス

社内ツールでは、サービスフローの変化に素早く対応して、提供コストやトラブルを減らすことが重要です。

一方で、フローの全てにツールを合わせると改修コストが爆上がりするので、運用カバーと改修の線引きをする必要があります。

使用方法のバラつきが悪影響を与える

toCだと「ユーザーが新しい使い方を発見して、サービスの幅を広げてくれた！」という話もありますが、社内ツールではユーザーごとの使用方法のバラつきが、データやサービスフローの一貫性に影響を与える場合があります。

そのため、ドキュメントの共有など運用面まで気を使う必要があります。

これらの違いを前提として、課題発見→解決方法の決定→運用の各フェーズで気をつけている点をまとめました。

課題発見

課題を見つける方法は、大きく分けて「自分で見つける」「ユーザー（CS/BS）に課題を共有してもらう」の2つです。ユーザーとコミュニケーションが取れるメリットを活かして、弊社では仕組み作りも含めた工夫をしています。

自分で見つける工夫

関係者のslackチャンネルは全部見る

弊社はslackを使っているので、CRMを使用しているチームのチャンネルは全部読んでます。

直接の課題が見つかることは少ないですが、「例外的な対応が増えて運用でカバーしているな」「この作業は時間がかかっていそうだな」と気づく点はあります。フローやチームの現状を把握しておくと、改修時の打ち合わせがスムーズになったり、課題の重要度を測るヒントにもなります。

声かけ

リリースした直後は「CRMで困っていることないですか？」と、通りすがりや昼食時に声かけしてました。
何かのついでにサラッと聞くと、検索フォームの位置など細かな違和感も教えてくれます。

バグ報告の仕組み作りができていないリリース直後は、結構効果がありました。

課題を共有してもらう工夫

バグ報告・要望ボードを作る

別プロダクトを参考に、TrelloでCRM用のバグ報告・要望ボードを作ってもらいました。
要望やバグを記載したカードを作成すると、slackに通知が流れるので、開発チームがGithubでissue化→改修しています。

slackでは情報が流れてしまいますし、口頭だと互いに手を止める必要があるので、Trelloは便利です。

Trelloカードから改修に必要な情報を掴むために「課題の概要」「バグなのか要望なのか」「緊急度」「要望の背景」「バグが起きた状況」は必須項目としています。また、記載ルールはいつでも見れるようにesaにまとめています。

お礼はちょっと大げさに

仕組み作り以外にも、心理的なハードルの低下も大切です。

トラブル時に「忙しいのにすみません」と申し訳なさそうに声をかけてくれる方がいます。ミスを指摘したり、仕事を増やしている様に感じるのかもしれませんが、報告には感謝しかありません！

そこで、slackでは「報告ありがとうございます！！めちゃめちゃ助かります！！🙇‍♀️」のようにカジュアルな口調や絵文字を多めに使います(プライベートはもっと適当)。

自分の意見に意味がある、と実感してもらう

ユーザーにとって、バグ報告は本来の業務ではありません。しかし、プロダクトを改善するためには彼らの協力が必須です。

そこで必要なのは「自分の意見には意味があった」という実感かと思います。
わざわざTrelloに要望を出したのに、その後は何も分からない...では、二度と意見を言ってくれません。

そこで、Trelloのバグ報告・要望ボードはCRMに関わる全員が閲覧可能になっており、自分の出した要望のステータス(Todo/In Progress)をいつでも確認できます。

また、検証した結果、要望に対応できないと分かった時もTrelloカードを黙って削除することはしません。技術的な理由も含めて丁寧に説明をします。

意見を出せばツールが変わる、と感じてもらうことで、要望を出す心理的ハードルも下がるはずです。

解決策の発見

社内ツールのメリットは、ユーザーの協力が得やすいことです。
課題の詳細も直接聞けますし、使っている場面を見ることも可能です。一方で、距離の近さからユーザーの意見に影響されすぎないように気をつける必要があります。

それはシステムで解決しないといけない？

要望を見たらまず「本当に改修は必要か？」と考える必要があります。

エンジニアの仕事は課題を解決することで、システムを作るのは手段の1つです。
そのため、既存の機能で対応が可能であれば、改修は工数のムダです。
Trelloに「欲しい機能」ではなく「困っていること」を書いてもらうのも、エンジニアが一緒に解決策を考えたいからです。

解決策を考える際は、必ずユーザーと話します。
実際に起きたケースや現在の対応を詳しく聞いてみると、まったく予想と異なる解決策が見つかることもあるので、ここには時間を使います。

その結果、運用カバーをお願いすることもあれば、数日で機能を追加することもあります。

運用カバーの場合でも、他チームと一緒にドキュメントを整備したり、経理用のスプレッドシートを修正するなど、サポートする場合が多いです。

エンジニアがどこまでやるか？は難しい問題ですが、個人的にはツールが使える環境整備も仕事だと思っているので、手厚めにやってます。

改修にせよ、運用カバーにせよ
- 関係者全員が納得ができる
- ミニマムかつベストな解決策を実現する
の両方が大切だと感じています。

それは本当の課題？

ユーザーと話す際に気をつけるのは、ユーザーは具体的な解決策の話に引っ張られがちということです。

課題を知るために「最近起きた事例について、詳細を話してください」とお願いしても

「例外的な対応を取らないといけないユーザーが増えて、CSの対応が追いつかないの。一人ひとりユーザーの詳細画面を開いてメモを確認するけど、時間がかかって終わらない。
だから、ユーザーの一覧画面でも分かる目印をつけて欲しいな。赤とか青とか色付きのラベルを作って、色で意味付けをしたい。
Trelloみたいに、CS側で自由にラベルを作れるようにはできない？」

 のように、解決策の要望までどんどん出てきます。

しかし、ここで「ラベルか…どう作ろうかな」と考えてはいけません。

なぜなら、この時点では「ラベルをつける」が解決策になるか分かりません。課題があまりにも不明確です。
「『例外的なユーザー』とはどのようなユーザーか？」から深堀る必要があります。

上記は実際にあった要望ですが、会話を続けると最終的に「例外的なユーザー」は2種類に分けられて、別々の対応が必要だと分かりました。
さらに、課題も「例外的な対応が必要なユーザーがいる」と「ユーザー数が増えて見落としが起きそう」の2つに分けられました。

課題が曖昧では、ユーザー本人の提案でも正しいとは限りません。

それは正しい解決策？

ユーザーの「ラベルの色分け」という提案が解決策になりうるとしても、そのまま取り入れてOKかは分かりません。

どうして、文字色の変更ではなくラベルなのでしょうか？文字色の変更と文言付きのラベルでは、実装コストも既存UIへの影響も異なるので明確にしたい部分です。

この時ユーザーが「ラベル」と言ったのは、恐らく社内で使っているTrelloをイメージしたからです。ユーザーは自分が知っている範囲で案を出してくれるので、話を「具象→抽象」に戻さなければいけません。

私：「ラベルが欲しいのは、他のユーザーと例外対応のユーザーを区別するためですか？それなら、〇〇の機能がありますよ」
CS：「区別はしたいけど〇〇じゃダメ。だって〇〇は△△や××の状態のユーザーにも使っているし、詳細画面まで開かないと分からない。例外対応のユーザーは一覧画面で分からないと支障が出そう。」
私：「どんな支障が出そうですか？」
CS：「他チームとの連携とか。この時は□□チームの対応も変わるから。」
(つづく)

「他のユーザーと例外対応のユーザーを区別する」というように、提案された機能を少し抽象的な部分に戻すことで、解決策の要件を探ります。
その際、より具体的な要件を知るために既存の機能と比較することがよくあります。

この会話だけでも
- 例外対応のユーザーが、既存の△△や××ステータスのユーザーと明確に区別できる
- 重要度が高い情報だと分かる
- □□チームにも分かる方法でユーザーを区別できる

が、要件になりそうだと分かりました。

この段階では要件が絞れたらOKとして、ユーザーが気にしていた色や形についてはほぼ話しません。
デザインは既存UIとのバランスや情報の重要度を考慮したいので、デザイナーの力を借ります。

このように、解決策を見つける段階では、ユーザーが話したいことを止めたり、話を引き戻してでも必要な情報を見つけなければいけません。

普段一緒に働いてCSやBSと距離が近いほど、この作業は難しいかもしれません。多少嫌がられても、正しいものを作るぞ！という気持ちが必要です。

それはシステムだけで解決できる？

業務に使うツールはほぼ100％、前後にオフラインの作業があります。ここに対応できないと予想外の理由でシステムが使えなくなります。

実際にあった怖い話

私がCRMの開発時にやらかした話です。

CRMをリリースする数日前、エクセルで管理していたユーザー情報がすべて入力・管理できるようになり、CSと機能の最終確認をしていました。

そこで言われたのが

で、これってどうやって報告書を作るの？

でした。

報告書？？なにそれ？？

よく聞くと、「今まではエクセルで情報管理をしていたから、社外（弊社はBtoBtoC）への報告書もエクセルをコピペして作成していた。CRMではどうやって報告書を作るの？」という話でした。

報告書の存在を知らなかったので、もちろんそんな機能は無い。

「それじゃ使い物にならない！」と言われ、慌ててCSV出力機能と、CSVをコピペして報告書を作成するスプレッドシートを作りました。
リリースは1週間延びて、CTOを巻き込んで休日出勤したのは忘れません...。

このように、システムがシステムだけで完結することはほぼありません。
内部で入力したデータは必ずどこかで使用され、他の場所へ共有されている可能性もあります。

サービスフロー（ツールでサポートする部分以外も！）を確認して、
- 入力したデータがいつ、どこで、誰に使われるか
-後から入力されたデータを使う人は困らないか

を保証しなければいけません。
この時は、リリース前に気づけましたが、実際のフロー上で発覚すると社外にも影響を与えるところでした。

運用

システムも使われなければ意味がありません。追加した機能が使われているのか、放置されているなら原因を知る必要があります。

ユーザーはその機能が使えているか？
最初に書いたように、社内ツールはユーザーごとの使用方法のバラつきが悪影響を与えます。

先日も、ユーザーの一部がある機能を知らなかったことが原因の一つで、トラブルが起きました。「使わないのが悪い」ではなく、開発チームも協力して、機能を確実に知っている/使える環境を整えなければいけません。

この時はチームをまたいでドキュメント整備を行い、新規入職者にもルールや機能が伝わる仕組みを作ってもらいました。

「運用でカバー」が増えていないか？
短期的な対応であれば運用カバーもありますが、常習化するとCSの負担が増加してトラブルになります。

知らぬうちに運用カバーが増えているなら、開発チームがフロー上の問題や要望を上手く拾えていない可能性があります。
また、タスクが後回しになって運用カバーを増やしているならば、優先度の見直しが必要です。

最後に

社内ツール開発は決して表舞台に見える仕事ではありませんが、サービスを支える大切な仕事です。

何より、一緒に働いているメンバーに直接お礼を言ってもらえたり、毎日CS/BSの皆さんがCRMを使っている光景を見ると、リリースから1年経った今でも嬉しくなります。

より良い社内ツール開発が、より良いサービス提供に繋がることを信じて、これからも開発を続けます。

また、これから社内ツール開発に関する情報がもっと増えることを期待しています！