ビジネスサイドの業務を支える改善と技術

Last updated at 2016-12-16Posted at 2016-12-15

どうも、こんにちは。2015年10月にfreeeにjoinしました @miry といいます。
GYOMUハックというチーム（1人）で、社内のエンジニア以外の皆さんの業務を理解し、課題をエンジニアリング力を用いて解決する業務改善を行っています。

これはfreee Engineers Advent Calendarの16日目の記事です（`δωδ´）

自分が課題解決を行うにあたって気をつけていることと、エンジニア以外の皆さんが使っている営業支援CRMツールであるSalesforce（Sales Cloud）で実装するときに気をつけていることなどを紹介します。

#業務改善ってなにをしているの
前提として、freeeに入る前はSIerでシステムの保守業務を行っていました。なので、業務改善のようなコンサル的な仕事はしたことがありませんでした。

そんな元SIerエンジニアが突然業務改善をやったらこういうことを気をつけるようになった、みたいなことを書いていきます。

##業務効率化するにあたって気をつけていること
私が気をつけていることはズバリ下記の3つです。

現場の現状を知る
やりたいことを鵜呑みにしない
人を巻き込む

###■現場の現状を知る
マーケティング、インサイドセールス、パートナーセールス、カスタマーサポートなど様々なチームがあり、当たり前ですがそれぞれ違う業務を行っています。
最初にやらなくてはいけないことは、彼らの業務を知ることです。

彼らが何を目標として、その目標の達成のためにどんなことをやっているのかをヒアリングしたり、オブザービングしたりして、業務の内容を整理します。

この時、私が助けられるのは定常作業の自動化であるとか、無駄なオペレーションの改善なので、業務の内容を一つ一つのオペレーションレベルまで把握するように気をつけています。
freeeのような成長を続けるスタートアップでは日々何かが変わっているので、都度話を聞きに行きます。

このときはとにかくいろんな人に話を訊きます。
一人の意見だけだと偏ったり、抜け漏れがあったりするので、フットワーク軽く訊きに行きます。

###■やりたいことを鵜呑みにしない
ここでちょっと気をつけていることは、彼らのリクエストや解決方法をそのまま鵜呑みにしないことです。

こんな課題のためにこんな機能を作ってほしい、と具体的なリクエストを受けることがあります。
そんなときにそれをそのまま作ってしまうのは危険だったりします。

なぜならその解決方法がものすごく局所的でボトルネックが別にあったり、もっと簡単な解決方法があったりするためです。

まずはなんでその機能が欲しいのか、そもそも何に困っているのか、何ができるようになったら幸せなのか、という情報を訊いて、そこから自分なりに情報を整理して、現状と合わせて解決方法を提示します。

意外とよくあるのが、実装までしなくても課題が解決することです。
今はここをこうしているけど、これをこうすることはできないの？　こうしたら課題は解決するよ！　みたいに、話している間に解決することが結構あります。

一点に囚われてしまうと、脇道に咲く花に気付かなかったりするんですよね。自分もそうなってしまわないようにいつも気をつけています。

###■人を巻き込む
私の肩書を振り返ってみます。GYOMUハックというチーム（1人）、そう、1人でたくさんあるチームの課題と闘っているのです。

でも実は本当に独りではありません。
私の知恵だけでは解決できない課題や、私の詳しくない技術要素にぶちあたることはよくあることです。
どのツールを使うのか、どの言語を使うのかが決まっているわけではなく、いろんな解決方法を模索しなくてはならないのに、本当に私一人だと、私の知識だけで閉じた解決方法しか思いつけなくなってしまいます。

そんなときは人を巻き込みます。詳しそうな人、得意そうな人を見つけて、さくっと相談に行きます。
フットワーク軽く、いろんな意見を訊く、常にインプットをやめないことが大事だと思っています。

#使っている技術
ここから少し話は変わってツールの話です。freeeではSalesforceを使っています。
特にセールスの皆さんはSalesforceを使っているので、GYOMUハックではその実装を行うことが多いです。

※画像はsalesforce world tour tokyoの様子です。あすとろくんすごいかわいいです。

この1年Salesforceと戯れてきて、大分仲良くなれたかなと思うので、仲良くなった方法をちょっとだけお伝えします。

##Salesforceと仲良くなるためにやっていること

Salesforceと仲良くなるためにまず第一に考えなくてはいけないこと、それは標準機能を使うことです！
標準機能からそれると、何かを実装したいとき、私は下記の順番で考えます。

カスタム項目の数式で実装できないか考える
シンプルなワークフローで対応できないか考える
それでもダメならトリガーを使う
最終手段でVisualforceに手を出す

こんな感じです。
やはりトリガー（Apex）やVisualforceの実装ともなると時間も必要なので、できるだけ簡単にできないかをいつも考えています。
最近ではプロセスビルダーとか便利な機能もでてるみたいですね。

##実装のとき気をつけていること

つぎに、実装するときに気をつけていることです。

標準オブジェクトの用途から逸れるようならカスタムオブジェクトを使う
連携しているシステムから乖離しない

freeeの各サービスの情報をSalesforceに連携しているので、その情報を連携するときにはfreeeのDBとSalesforceオブジェクトがかい離しないように気をつけます。
Salesforceでいうこれは、freeeのこのテーブル、とちゃんと対応できるようにしておかないとのちのちメンテナンスがかなり厳しくなります。

本当に最初の設計が肝心です。

##余談

見つけたら泣きたくなって激おこする FieldXX__c について。

Salesforceのカスタム項目を追加すると、API参照名のデフォルトが FieldXX__c になります。
これって何かというと、テーブルのカラム名なんです。