GYOMUハックエンジニアが学んだこと

freee株式会社で初代GYOMUハッカーとして、GYOMUハックチームに所属しているmiryです。

今日はGYOMUハックAdvent Calendarの一発目として、3年間freeeで試行錯誤を繰り返しながら培ってきたものを書き連ねてみようと思います！

業務改善・業務効率化に携わっているという方も、GYOMUハックってなんだ、という方も、しばしお付き合いいただければ幸いです。

GYOMUハックとは

社内SEやBPR、ITコンサルなどビジネス要件に対して社内のシステム構築・業務改善・課題解決を行う人たちのことを総称してそう呼んでいます。freeeにおけるGYOMUハックは、マーケティング、セールス、カスタマーサクセス、サポートなどエンジニア以外のビジネスチームの業務の基盤を作ることをミッションとしています。日々生まれる彼らの悩みを聞き、課題を整理し、理想を共に考え、そして実現する仕事です。

freeeでは基本的にクラウドサービスを利用しており、Salesforce、Marketo、Pardot、ZuoraなどのSaaSを利用しています。GYOMUハックはそれらのクラウドサービスの構築や導入、運用・システムサポートなどを行っています。

f:id:mirygoaround:20181019184819p:plain

私たちGYOMUハックの目指す理想は、freeeのビジネスを世界最先端のビジネス組織に導くことで、私たちはそこに至るための道を作るITスペシャリスト集団とならなくてはならないと考えています。

developers.freee.co.jp

GYOMUハックを通して大事にするようになった3つのこと

3年間GYOMUハックを行なってきて、最近ではこうするとうまくいく、という自信のようなものも芽生えてきました。そして特に大事にしていることは次の3つです。

施策のゴールの認識合わせをすること
ツールに業務を合わせること
常に一歩先の理想を考えること

それぞれなんで大事に思うようになったかのストーリーをご紹介します。

施策のゴールの認識合わせをすること

どんな施策も始める時には、社内のステークホルダーを集めてキックオフミーティングを行います。そしてそのプロジェクトをなぜやるのか、何を成し遂げなければいけないのか、どのように進めていくのか、いつまでに何をやるのか、を最初に認識合わせをするようになりました。

業務改善の施策は、基本的に現場のオペレーションが変わることが多いです。そのため、ステークホルダーも多く、ふわっと始めてしまうとうまく回らないことが多々あります。今、この施策が動いているけどなんだっけ、このオペレーションが変わるけどなぜだっけ、という疑問が現場から生まれないように、施策の最初の認識合わせが必要なのです。

f:id:mirygoaround:20181128191238p:plain

ビジネス側かからすると、あれもこれも困っている、全部どうにかしてほしいという気持ちも大きいです。しかしエンジニアからするとあれもこれも対応していたら終わらない、リソースが足りない……といった苦悩があります。業務改善の施策を進めている間に、思いつく限りに次々要件が追加されて、それに逐一対応していたりすると、いつまでたっても施策が終わらずに、結局最初求めていたものとかけ離れた何かよくわからないものが出来上がってしまったりもします。それは結局誰にとっても嬉しくない状況なのです。

施策を進める上でお互いが辛くならないように、今回のこの施策ではいつまでにこの状態になっていることをゴールとします、そのほかはStep2で行いますなどと定義することで、ビジネス側もエンジニア側も納得した上で円滑に施策を進めることができるようになりました。

キックオフのミーティング後は定例を持つことで、進捗の共有とAIの確認、スケジュール感の再確認を毎回おこなっています。コミュニケーションを密に取り、お互いの状況を確認し合うことで、急な状況の変化にも対応でき、柔軟な対応ができているのも施策の関係者に明確なゴールの共通認識があって、同じ優先度を共有できていることが重要なのではないかと考えています。

ツールに業務を合わせること

最近では便利なSaaSのツールが登場していますよね。かくいうfreeeもそんなサービスの一つですが、弊社では営業の顧客管理をSalesforce、契約管理をZuoraで行なっていたりなど、さまざまなSaaSを活用しています。何かの施策を行うとなるとやることはツールの導入であるとか、機能の活用であることが多いです。

そもそもなぜSaaSが選ばれるかというと、こんなことに困っているという明確な課題のある人がいて、その課題に対してのソリューションをSaaSが提供していることが多いからなのだと思います。有名な言葉を借りると車輪の再発明をしない、ですね。そういったツールの導入は効率化や改善を考えた時にとても理にかなったものだと思います。

SaaSを提供している企業にはそれぞれのコンセプトがあり、そのコンセプトを理解するということがツールをうまく利用して業務を効率化できるか否かのかなり大きなポイントとなってきます。彼らのコンセプトにのり、彼らの考える業務フローで、彼らの考える使い方をすれば、ツールと仲良くなれます。しかし、実際問題すでに業務が回っているところに新しくツールを導入するのですから、そんなにすんなりうまくいくわけがありません。

エンジニア側がまずやらなくてはならないことは、ビジネス側が一体何に困っているのかと業務の本質の理解です。こんな課題がある→このツールはその課題を解決する機能がある→ツールを入れて終わり、ではなんの意味も為しません。ビジネス側の業務を深く理解し、なぜそのような業務を行なっているのかという歴史に寄り添い、そしてそこから大きく外れないように理想的な形を考える必要があります。業務を理解した上で、ツールの特性・コンセプトに業務を寄り添わせるのです。

f:id:mirygoaround:20181128191449p:plain

ツールの特性・コンセプトの啓蒙を行い、なぜこうするとうまくいくのかを説明し、体感してもらう。そうすることで、今までのやり方よりも新しいやり方にメリットがあると実感してもらうことで、運用が定着するのです。みんなで一緒にツールと仲良くなりましょう！

常に一歩先の理想を考えること

あれもこれも課題で、何から手をつければいいのか……そんな状態を経験している人はいないでしょうか。ビジネス側は課題の山に追われ、エンジニア側もあれもこれもよくしたいという思いばかりが募る。そんな状況になった時に、私が気をつけないといけないなと身にしみたのは、たどり着きたい理想を描いた上で目の前の課題に取り組むということでした。

目先の課題を解決する時、やり方はいろいろあると思います。その最適解を考える時に、私たちはいつか実現したい理想の形に一歩近くような対応を考えられるとベストです。ビジネスというものはどんどん成長するもので、その成長に合わせて業務もどんどん増えていきます。改善しているのに、それを考慮できていなかったら改善の対応がいつかまた負債になってしまうのです。

なるべく汎用的に、拡張性を考える。ピンポイントで対応するのではなく、俯瞰的に物事を捉えて、少し高めの目線から考えてみる。

私はそのようなことを常に意識しています。実はこれは結構辛いことで、効果が出るまでに時間がかかるので、その対応した直後はよくなっている実感はなかなか持てないのですが、数ヶ月経って、あれ？　いつの間にかよくなっているぞ？　と、ふっと気づくものなのだということに、最近気づきました。数ヶ月前の私が行なった施策が、別の施策で、「おお、ちゃんとこうなってるから対応できる！」といったことがよくあるので、私は昔の自分をこっそり褒めています。笑

一番嬉しかったのは、最近Salesforceが使いやすくなっている、便利になった、追いたい数字が簡単に取れるといったビジネス側からのフィードバックでした。理想を追い求めて少しずつ改善してきたのは無駄じゃなかったんだなと、ちょっと泣きました。