GYOMUハック―ビジネスチームとの二人三脚―

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

これはGYOMUハック / 業務ハック Advent Calendarの14日目の記事です。

ビジネスチームの成長の歴史

会社はどんどん成長するもので、私の所属するfreeeも2012年の創業からぐんぐん成長してきました。

f:id:mirygoaround:20181214155609p:plain

それにともなって、さまざまなファンクションのチームが生まれ、日々業務を行なって居ます。初めはエンジニアとサポートから始まったのですが、マーケティングとセールスが生まれ、カスタマーサクセスが生まれ、パートナーセールスやチャネルセールスが生まれ、とどんどん規模が拡大してきました。

f:id:mirygoaround:20181214155953p:plain

このビジネスチームの急成長をエンジニアリングで支えてきたのがGYOMUハックです。

SaaSで乗り越えてきた3年間

freeeでは基本的にクラウドのツールを利用しています。セールスはSalesforceを利用していたわけなのですが、今思えば、Salesforceを利用していてよかったと思える3年間でした。

この急成長なので、1ヶ月後にはこのような業務が増えているからできるようにしてほしい、という急な依頼はざらにあります。

もし内製のツールだった場合、そもそもの要件に含まれていないので、機能改修が必要になります。しかし、Salesforceをはじめとする各種SaaSだと、機能自体は組み込まれていて、あとはどう使うかをカスタマイズしてあげればいいだけなので、かなり負荷が下がるのです。

円滑なハック〜改善〜のために

大切なコミュニケーション

コミュニケーションが大事とはよく謳われますが、私も本当にコミュニケーションが大事だと実感しています。

常日頃、ビジネスチームがどんな悩みを抱えているのか、雑談などでも聞けるようにアンテナをはっており、メンバーを見かけたら積極的に声をかけるようにしています。

そうすることで、相談するハードルを下げるようにしています。

あとは意図的にどんなことをやってきたのかを発信するようにしています。なるべく、表に出て、何か困ったらあの人に聞けばいいんだなという空気を作るようにしています。

課題把握は自分の目で

新しいものを作るにも、今あるものを改善するにも、まずは話を聞くところから始まります。その時に気をつけているのが、全部を鵜呑みにしないことです。

よく、「こういう機能をこう修正してください」みたいな依頼が来るのですが、そういうときは、何に困っていて、どういう状態にしたいのか」というヒアリングを行います。そうすることで、俯瞰して課題把握ができるのです。

また、実際に業務をしているメンバーの横で業務を眺めたりします。オブザービングと呼んでいるのですが、現場からあがる課題だけでなく、エンジニア視点でこれは実は課題ではないかというように気づけることが結構あるのです。

定着化はチャンピオンと共に 

改善系のタスクの難点は「今できているのになぜ変えるんだ」です。

慣れている見た目やツールが変わるのはかなり大変です。しかし、メリットをきちんと説明し、GYOMUハックを進めなくてはいけません。

そんなとき私たちは、現場からチャンピオンを選び、プロジェクトを進めていきます。

チャンピオンが現場の声を聞き、GYOMUハックとやりとりをする。最初は当事者意識が薄いメンバーも、一緒に働いているチームのメンバーが取り組んでいるので、自分ごととなって協力してくれる。そしてリリース後もチャンピオンが中身をよく知っているので対応できる。

機能や仕組みを提供するのはGYOMUハックですが、オペレーションを実際に作り、育てていくのはビジネスチームのみなさんなのです。

 GYOMUハックはサポートであり先導者

このようにビジネスチームの業務を支え、二人三脚で一緒に育てているGYOMUハックは縁の下の力持ち的なサポート役かもしれません。

しかし、ビジネスの成長を見据え、システム的な土台を整え、次に来るであろう未来に備えて施策を打っていくのもGYOMUハックなのです。

すべてのGYOMUハックはビジネスチーム無しではなりたたないので、良い関係を築きながら理想に向けて進めていけたらと思います。

 

Salesforce上で業務プロセスを組むときの考え方

はじめに

これはSalesforce Platform Advent Calendar 2018の9日目の記事です。

freee株式会社でGYOMUハックをしているmiryです。GYOMUハックについて知りたい方はぜひこちらをご覧ください。

mirygoaround.hatenablog.com

 

この記事を読んでいるみなさんはSalesforceを業務に利用している方や、Salesforce上のアプリ開発をしている方など様々かと思います。

私は今回業務構築の観点でお話したいと思います。

Salesforceでの業務プロセスの組み方

1.何をやりたいのかを明確に

Salesforce PlatformにはSales cloud、Service cloudをはじめとする様々な機能があります。まずは、いったいどのような業務を行なっていくのかを明確にします。

 

さまざまな業務が思いつくかと思いますが、まずは何をやるのか、そして今後何をやっていく可能性があるのかをイメージしておけるとよいです。

2.どんな数字を追うのか

どんな業務を行うのかが決まったら、それぞれの業務でどんな数字をSalesforce上で追っていくのかを考えて行きましょう。このとき、追うべき数字が決まっている必要はなく、大まかな方向性が決まっているとのちのち便利です。

  • アクティビティを追うのか
  • 商談化数を追うのか
  • クオリティを追うのか
  • 顧客満足度を追うのか

この辺りを出せるだけ出して行きましょう。

3.Salesforceの機能を調べる

Salesforceでは、ある程度の業務が標準機能で準備されているので、どういう風にSalesforce上で業務を組み立てるのかも自由にできます。

ヘルプページやTrailheadで調べられるので、どんなことができるのか調べてみるのもいいかもしれません。

他にもDevelopersEditionという無料で構築できる環境もあるので、そこで触ってみるのもいいでしょう。

一番のオススメはTrailheadで、ある程度データの入っている環境を立ち上げて、インストラクションとともに操作することができます。

4.実装設計する

機能を調べたら、早速設計です。Salesforceはカスタマイズがとても柔軟にできますが、少し(かなり?)癖もあります。

オブジェクト設計

まずはオブジェクト構成です。2で大まかに追いたい数字について決めたと思うので、Salesforceのレポートでどのように集計できるのかをイメージしながらオブジェクトの構成イメージを考えます。下記の図は簡易的なものですが、データモデル図を書くのもいいです。

f:id:mirygoaround:20181208195352p:plain

オブジェクト活用を考えるときのコツは、

  • 標準オブジェクトを活用する
  • 標準項目を活用する
  • カスタム項目を活用する
  • カスタムオブジェクトを活用する

です。それぞれどのオブジェクトにどのような内容を格納するのかを考え、標準のオブジェクトが使えるときは、標準のオブジェクトを利用しましょう。

プロセスの自動化の設計

効率化のための自動化は必ずあがるリクエストだと思います。その時の実装で考えるとき、私はこのような順で考えています。

  1. 数式で対応できるか
  2. 積み上げ集計で対応できるか
  3. LEXのコンポーネントで対応できるか
  4. ワークフロールールで対応できるか
  5. プロセスビルダーで対応できるか
  6. フローで対応できるか
  7. Apexで対応できるか

エンジニアにとっては、Apexなどでコーディングするのが楽なのですが、できるだけ前述の順序で実装計画を立てるのがよいです。

理由はApexなどのカスタマイズだと、メンテナンスが大変で、どんな処理が動いているのか把握するのが複雑になってしまうのです。

f:id:mirygoaround:20181208201124p:plain

あと、下記のような機能は標準で提供されているので、ぜひ使ってみてください。

  • リードのマージ
  • リードのコンバート(取引の開始)
  • 取引先のマージ
  • 取引先責任者のマージ
  • 承認プロセス

5.実装する

Salesforceの実装をする時、いきなり本番環境に反映するのはやめましょう。

前述のDevelopersEditionやSandbox環境などで思い通りの挙動をするのかをテストしてみてください。

かなり癖があるので、あれ、これはできないんだ!とかいう細かい制約があり、苦労することこの上ありません。笑

実際に触ってみて、動かしてみて、思い通りのものを実装してみましょう。

6.動作確認

業務に実際に関わる人にも動作を確認してもらいましょう。

最初から最後の業務の流れをデモして、そしてどのようなレポートができるかを作ってみて、想定通りの動きをするのか、無理なオペレーションになっていないのかシュミレートしてみましょう。そうしてチューニングするのがよいです。

f:id:mirygoaround:20181208201042p:plain

さいごに

これから、Salesforceで業務を組むという方向けに思考プロセスをかいてみました。簡単ではありますが、参考になればと思います。

 

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

さいごに

このような感じで、いろんなことを学んで、より良い形を試行錯誤しながらビジネスチームと二人三脚で進んできた3年間でした。最近は私のGYOMUハックのノウハウを外部の人にも共有したいなという気持ちが強まったので、このような記事を書くことにした次第です。

また、同じようなGYOMUハッカーと知り合いたい・繋がりたいという想いでGYOMU Hackers Guildというコミュニティを2017年に立ち上げました。

12/11にGYOMU Hackers Nightを開催しますので、興味のある方はぜひ参加して見てください!

f:id:mirygoaround:20180426160507p:plain

明日はfreee developers Advent Calendarでとっておきの記事を出すので、もしよろしかったらご覧ください!

adventar.org

また、freee株式会社では課題解決が得意なGYOMUハックエンジニアを大絶賛募集中ですので、興味のある方はぜひお声掛けください。

jobs.jobvite.com

最後までご覧いただきありがとうございました!

いつの日かGYOMU Hackers Nightで皆様にお会いできるのをお待ちしております。

GYOMUハック言葉綴りー序章ー

はてなブログでは久しぶりの記事になってしまいましたが、本日2018/10/19でfreee株式会社に入って3年が経ったのを機に、ちょっとした話を書いてみようかなと思いました。

freeeでやっていること

2015/10/19にfreeeにJoinしてから、私はGYOMUハック(a.k.a 業務ハック)というチームにいます。どんな仕事かというと、一般的にはBPRや社内SEと呼ばれているものに近いと思います。マーケティングチームやセールスチームなど、社内のエンジニアではないチーム(以後、ビジネスチーム)の人たちの抱える様々な課題をエンジニアリングで解決するチームです。今でこそチームですが、Join当初は一人チームでした。

f:id:mirygoaround:20181019184819p:plain

詳しいことは、今まで結構いろんなところで書いているのでリンクをおいておきます。

developers.freee.co.jp

codezine.jp

developers.freee.co.jp

これから書いていこうと思うこと

freeeで過ごしてきた3年での気づきや、運営しているGYOMU Hackers Guildというコミュニティでの気づきをゆるゆると共有したいなと思います。

たとえば、

  • 業務改善プロジェクトはなにからはじめる?
  • 業務改善プロジェクトをうまく回すには?
  • 業務改善≒クラウドサービス導入?

みたいなことです。

まずは「書くぞ!」という気持ちを表明して、自分に発破をかけようと思います。

次の記事で皆様にお会いできると嬉しいです。頑張ります。

 

わたしのslack利用術

今の会社に入って、slackを使い始めましたが、結構いろいろ便利だなーというのと、人によってかなり使い方も違ってくるんだなということで、自分の使い方みたいなのを紹介します。

Channel編

Channel、いっぱい入っていると大変で、@hereとか@channelとかで通知来るのが邪魔だと思ってました。

そこでやってる便利設定です。

お気に入りのChannelはstarする

残念ながらChannel一覧の並び替えの機能がないのが残念ですよね。そこで、starをしておくと、一覧の上のほうに表示されます。

f:id:mirygoaround:20170219144347p:plain

f:id:mirygoaround:20170219144614p:plain

部屋には入っておきたいんだけど……

Channelには入っておきたいけど、発言数が多くて気になってしまう!

そういう時は、Channelをmuteです。

f:id:mirygoaround:20170219144935p:plain

Muteすると存在を忘れてしまう!でも定期的にチェックしたい

そんなときは、MuteしてStarするのをおすすめします(`δωδ′)

@hereと@channelの場合は通知を切る

各Channelの歯車マークのNotification prefencesを開きます

f:id:mirygoaround:20170219143656p:plain

赤枠の部分にある@channel notificationsのところのチェックをすれば、通知が来なくなります。地味に便利です。

f:id:mirygoaround:20170219144003p:plain

 

Message編

Slackの発言ってすぐ流れちゃいますよね。それをうまく活用する術です。

@発言を見逃さない

右上にある@マークをおすと、自分への@発言が全部一覧ででてきます。これは便利です(`δωδ′)

f:id:mirygoaround:20170219145803p:plain

重要な発言にはstarをつける

あとで見返したい発言には、starをつけます!

f:id:mirygoaround:20170219145934p:plain

そうすると、右上の☆マークのところで全部一覧ででてきます。これも便利です。

f:id:mirygoaround:20170219150058p:plain

あとでリマインドする

とある発言を後でリマインドすることができます!

f:id:mirygoaround:20170219150314p:plain

/remind と同じ機能です。

小技:わたしのToDo管理

最近、自分にDMして発言を書いたり消したりしてToDo管理しています。

f:id:mirygoaround:20170219150703p:plain

よく使うGoogle ドキュメントなどを張っておいてインデックスにしておいたり、だれにも見えないところで好き勝手できるので割と便利です。

さいごに

ちかちかすると集中が切れるとか、リアルタイム性を求められるとか、情報量多くて負えないとか、slack苦手な人もいるかと思いますが、うまく付き合えれば結構便利に使えるツールにもなるのかなとか思います。(`δωδ′)<Happy Slack Life♡

はじめての転職から1年が経過してみて思うこと

はじめに

転職ブログをよく見かけますが、自分も書いてみたいなーと思っていました。がしかし、完全に機を逸してしまったところに、ふろしきさんのブログを読んで、私も1年後に書いてみよう!と思ってから約1年、とうとうこの時がやってきました。

ということで、転職から1年経ったエンジニアのブログです(`δωδ′)

自己紹介

どうもはじめまして、社会人6年目のみり(@mirygoaround)です。初めてはてなブログを書くので幾ばくか緊張しております。ブログというより小学生の感想文か日記みたいな感じになりそうですが、ご容赦ください。

2010年10月にフィリピン大学工学部コンピューターサイエンス学科卒業後、2011年4月1日にフューチャーインスペース株式会社(当時は株式会社アセンディア)に入社。そして2015年10月19日にfreee株式会社に入社しました。

前職ではシステムエンジニアとDBAをやっていて、今はWebエンジニアをしています。

www.freee.co.jp

転職のきっかけ

前職のフューチャーインスペース株式会社(以後FIS)では、某コンビニのシステムの保守を行っていました。

3か月の新人研修後のプロジェクト配属でしたが、配属後2週間でいきなり顧客折衝したり、保守とDBAのチーム掛け持ちをしたりと、なかなかチャレンジングな環境でした。要件定義からリリースまで、一通りのフェーズを経験できたことはとてもよかったです。

転職を考え始めたのは、2013年ごろです。同じプロジェクトで月次のルーティンワークが続いていて新しいことを覚える機会が減ってきたことがきっかけだと思います。

幸いチームの仲間にも環境にも恵まれていたのですが、どうしても自分の脳みそが腐っていく感覚から抜け出せませんでした。

そんな自分に危機感を覚えて、応用情報技術者試験をとってみたり、社内コミュニケーションサイトの作成をしてみたり、内定者フォローやOJT担当をしてみるなど、1年くらいいろいろあがいてみたのですが、もっと新しいことをやりたいという気持ちが強くなったのです。20代も後半、転職するならいまだ! と思いました。

初めての転職活動

初期

転職したいな、という気持ちもそぞろ、さて、何をすればいいんだろうと思って最初にしたことは、転職活動について調べることでした。

履歴書には何を書くのか、IT系企業の面接はだいたい私服でいいとか、そんな基礎的なところからのスタートです。

このころの私は本当にふわふわしてました。転職したいけど、環境変えるの怖いなーとか、自分はいったい何がしたいんだろうとか、本当に何も決まっていなかったんです。

そんな状態でしたがまずは転職サイトに登録するところから始めました。

お世話になったのはビズリーチさんのキャリアトレックです。 

お恥ずかしながら、めちゃくちゃクローズドな環境にいたため、世の中の企業事情が全く分からない浦島太郎でした。なので、どんどん向こうからレコメンドしてくれる、というのはとてもありがたかったです。

ころころは気になる会社を「気になる」しまくっていました。

 

ちなみに転職活動は誰にも言わずにひっそりこっそりでした。

業務終了後に面接のお時間をとってくださった企業の皆様ほんとうにありがとうございました。

中期

キャリアトレックでレコメンドされた中に、転職エージェントも何社かありましたが、何人かコンタクトしてみてGeeklyさんでいろいろお願いすることにしました。

自分が何をやりたいのか、どういう風になりたいのかをしっかり見つめなおして、言葉にしたのは多分このころです。

私は新しくて社会に貢献できることがやりたくて、自分も日々成長がしたいんだということを再認識しました。

そのためには会社も、今までのように受注しているところよりも、自社サービスを運営しているところの方が自由度が高いのではないかと思うようになり、Webサービス系の会社を受けるようになりました。

さてここで問題なのが今までの経歴で、一応はサーバサイドエンジニア、しかし4年半ほとんどコードを書いてこなかった私が、Webサービスの会社を受けるのはかなりのチャレンジでした。

エージェントに勧められる会社で面接を受けて、自分に合うのはどこだろう、自分を受け入れてくれるところはどこだろう、と、絶妙なマッチングを探す日々でした。

後期

何社か受けていたころ出会ったのが、freee株式会社です。会計には全く興味がなく、クラウド会計ソフト? ふーむ、という感じでお話を聞きに行きました。

結果、ものすごい衝撃を受けました。圧倒された、といってもいいかもしれません。

自由な雰囲気のオフィスに、すごいーと思っていたところに、会社のミッション「誰もが創造的な活動ができる社会」「スモールビジネスが強く、かっこよく活躍する社会」を実現すること。』です。あ、素敵だ、ここで働きたいって思いました。新しい技術をどんどん取り入れていくスーパー技術者集団がいる、その中で自分も成長したいという思いが強くなりました。自分のやりたいことと、freeeの姿がぴたっとあった感じです。

とまあ、私は働きたい気持ちが強くなるわけですが、採用してもらわないといけないわけで。笑

前述の通りほとんどコーディングをしてこなかった私が、こんなスーパー技術者集団のいる会社に入れるのだろうか……と、かなり不安でした。(というか、いまだによく採用してもらえたなと思っています。)

その後面接の際に自分の思いの丈をぶつけて臨んだ結果、ありがたいことに内定をいただく運びとあいなりました。

内定をもらったときに、私よりもエージェントの方が喜んでいたのが印象に残っています。びっくりマークと太字大文字だらけのメールが届いて驚きました。笑

いざ転職……の前に引き継ぎ

はい、内定をいただいて、よっし、転職だ! とはすんなりいかないものです。

内定をいただいた当初の予定日よりも1か月半後ろ倒しになりました。Orz

4年近く同じプロジェクトにいて保守をやっていたのですが、結構ドキュメントもそろっていてわかりやすかったものの、どうしても属人化してしまっていたところがありました。というよりも、私がほかの人より詳しかったのかな。

そんなあれやそれをドキュメントにまとめて、引き継ぎ作業。転職活動を始めてからドキュメントの準備自体は始めていたんです。わかりやすいドキュメント大事、超絶対。そんなこんなでばたばたと引き継ぎをして、有給消化に入りました。

freeeでの1年間

freeeでの1年はあっという間でした。え、もう1年? という気持ちがいまだにぬぐえません。そんな1年を振り返ってみます。

お仕事

入ってすぐ、まずどうしようと思ったのは、自分が何のチームに入るのか知らされていない、ということでした。

会計ソフトの開発をするのかな、簿記とか勉強するのかな、どきどき、と思っていたんですが、伝えられたチーム名は「GYOMUハック」でした。

ん、ぎょーむはっく? いったいなにをするの……?

どうやら、私1人のチームです。最初から不穏、ほんと不安。

さて、まずは開発環境の構築ですが、TortoiseSVNの世界から来た私はGitがよくわからず、悪戦苦闘。

本当に、えらい世界にやってきてしまったというタイムスリップ感を抱きながら前に進む日々でした。

そしてGYOMUハックがどんなお仕事をするかといいますと、簡単に言うと社内のエンジニア以外のみなさんの業務をエンジニア力を使って改善するお仕事です。

なので、私が一緒に仕事をする相手は営業であったり、マーケであったり、サポートセンターの人であったりと、エンジニア以外のみんなです。

彼らとコミュニケーションするうえで気づいたのが、徹底的に言葉が通じない、ということでした。

私はずっとシステムエンジニアをしてきて、営業の方やマーケティングの方とお話しする機会はほとんどありませんでした。そのため、彼らの使う用語の意味が全く分からなかったのです。

開発するにも触れたことのない新しい技術、一緒に仕事をする相手の言葉は私にはわからない。不安も大きかったですが、それよりもこの強敵をどうやって倒そうか、という気持ちのほうが強くて、わくわくしました。

右を見ても左を見てもすごい技術者のみなさん、そんなみなさんの力を借りて駆け抜けてきました。

そんなこんなで駆け抜けてきた私は、今も走り続けています。

1年前と違うことは、使っている技術もわかってきたし、エンジニア以外のみなさんの言葉も通じるようになったことです。エンジニアの中で一番エンジニア以外のみんなの業務をわかっていると思っています。

いろんな相談を受けるようにもなって、一緒に悩んで、解決していくのはとても楽しいです。その一方で相談の量も増えてきて、脳みそがパンクしそうな日々が続いています。

この1年インプットばかりでしたが、これからはどんどんインパクトを生み出せるように頭をフル回転させていきます!

いいところ

freeeのいいなと思うところは、褒める文化があることだと思います。CEOや経験豊富な技術者たちでも、良いと思ったことは「それ、良いですね」と口にします。

え、そんなこと? と思う方もいると思うのですが、結構新鮮でした。何せ、自分が当たり前だと思っていることでも、良いことだと指摘されることで、それって良いことなんだと自分が認識できるんです。

これは意外とモチベーションにつながるし、いろんなことを頑張ろうと思える気がします。なんでそうなるのかなと考えてみたところ、自分のできていないことやダメなところって、自分が1番わかってるんですよね。そういうときって自分の良いところをないがしろにしがちなんだと気づきました。そんなときに他者に褒めてもらえるということは自分で思うよりもインパクトが大きいです。

逆にダメなところって自分で分かっていて、できなくて悔しいとか落ち込んでいるときにダメなところを指摘されるとどんどん落ち込む負のループに陥りがちなんですよね……。

 

もう一つfreeeを語るうえで外せないものは5つの価値基準があることです。チームが違っても価値基準を指標にできるのは心強いです。クオーターごとに振り返りをしていることも良いと思っていて、チームの振り返りができるし、良い機会になります。

価値基準って社内の人ではそれぞれいろんなとらえ方をしているんですが、私にとっての価値基準は自分を限界の枠から一歩外に出してくれる便利な指標です。

物事を考えるときにはだいたいリソースや自分の限界に囚われがちですが、価値基準を思い出して本質的に価値のあることはなんだろう、理想ってなんだろうと考えることで、普段の自分なら考え付かないようなアイデアが生まれたりします。そのアイデアを実現するためにいろんなことをHackできないかと調べたり考えたりするようになりました。

物事を俯瞰的にとらえて、とよく口にしていましたが、それを具体的に示してくれたのがこの価値基準なのかなとぼんやり思っています。

あくまでこれは私の例で、ほかの人はまた違った考え方をしているのが面白いところです。

f:id:mirygoaround:20161019005306p:plain

のびしろ

freeeは急成長していて、実際この1年でオフィスも引っ越して、従業員の数も倍以上になっています。急激に拡大していて、いろいろ整っていないことも多いです。そして毎日が変革の連続です。

え、また変わるの? え、そうなるの? ということの連続で結構衝撃が大きい気がします。これは企業が成長し続けている証かなとも思いますが、やはりいまだに慣れないです。小心者なので毎日どきどきしてます。

でも、まだ行き届いていないところを創っていく挑戦もできるということかなと思って頑張る所存です。

というわけで、freeeは本当に成長途中の雛鳥ですね。のびしろだらけだと思います。

さいごに

転職をしてよかったかどうかと言われれば、思い切って良かったです。タイミングも良かったと思いますし、挑戦し続けられている今の環境に満足してます。

自分のやりたいこととマッチする職場が見つけられたことが結構大きかったかなと思います。

転職活動を始めたころはまさかベンチャー企業で働くことになるとは思ってもみませんでした。人生はどう転ぶかわからないものですね。

私はぺーぺーのエンジニアなのでまだまだ至らないことも多いし、やること盛りだくさんなので今の環境でさらに頑張ろうと思っています。(`δωδ′)。

FISでの4年半で培ってきたドキュメント作成や要件まとめの方法も今の職場で活きているのを実感していますし、データベースの知識なども本当に今も役立つことばかりです。それも含めて、今の自分があるんだなと実感しています。

前職でかかわっていたすべての皆さんと環境に本当に感謝です。

そして今一緒に働いているみなさん、これからもご迷惑をおかけしますかとは思いますが、精一杯頑張る所存ですのでよろしくお願いします。(*δ∀δ*)。

 

 

と、最後まで書いてみて、やっぱり感想文になってしまいましたね。苦笑

ここまで読んでくださったみなさん、最後までお付き合いいただき本当にありがとうございました!