「会計フリー」や「人事労務フリー」など、スモールビジネスを支援するサービスを支援しているfreee株式会社の開発チームでマネージャーをされている、エンジニアの長幡 陽太氏に同社で働く魅力やエンジニアになったきっかけをお伺いしました。
「会計フリー」や「人事労務フリー」など、スモールビジネスを支援するサービスを支援しているfreee株式会社(以下freee)。
今回は、開発チームでマネージャーをされている、エンジニアの長幡 陽太(ながはた ようた)氏にお話を伺いました。
目次
freeeは、「スモールビジネスを、世界の主役に。」というミッションを掲げていて、中小企業や個人事業主の方をターゲットに会計や労務といったバックオフィス業務を支援するプロダクトを出しています。
主なプロダクトとしては会計フリー、人事労務フリー、申告フリーの3つと、これから事業を始める方に向けて会社設立フリーと開業フリーというプロダクトを運営しています。
今はAJM、アソシエイトジャーマネという役割をしています。
うちでは、マネージャーのことをジャーマネって呼んでいるんですけど。
そうです。
AJMになってからはちょうど1ヶ月ぐらい経ちました。
それまでは1エンジニアとしてがっつりコードを書いていて、明細取得の機能拡張とか、マイクロサービスに切り出したあとの機能拡張のリリースをしたりしていました。
ジャーマネになってからの関わり方は、メンバーがプロジェクトを進める中でどうやったら集中して仕事ができるかということをメインで考えていて、環境づくりや運用の仕組みを整えつつ、自分のチームが生産的な活動にフォーカスできるようにする活動がメインですね。
インターンにfreeeを選んだのは割と偶然でした。
最初は2015年のサマーインターンに参加したんですけど、ある媒体でサマーインターンの募集をしているのをたまたま見つけたというのがきっかけです。
当時ものすごくプログラミングが出来たわけではないんですが、サークルでLaravelでアプリを作って運用したりはしていました。
その内容を書類に書いて応募したら、サマーインターンに合格して参加することができました。
そこからサマーインターンが終わって、次は長期のエンジニアインターンを探していたんです。
その話を当時freeeの人にしたら「じゃあうちに来なよ」って言ってくれまして。
そこからずっとインターンを続けて、最終的に内定をもらってそのまま入社しました。
そうですね。
そういう知識は最初分からなくて、いろんな人に聞き続けてなんとか分かってきました(笑)
大学で人間科学部っていう学部に通っていたのですが、その中の授業で触る機会があったのが最初です。
僕が入った学科は情報科学科というところで、どちらかというと理系寄りですね。
大学に入るまでは、特別ITが好きなわけでは無かったと思います。
パソコンに触るといってもネットサーフィンとかゲームをする程度。
中学時代に、パソコンを自作して家にネットワーク構築してみたいな友人がいて、彼のことをすごいなぁと思っていたくらいですね(笑）
大学受験のときもなかなかやりたいことが決まらなくて、志望校を何度も変えているうちに、最終的に情報科学科に入ってそこでやっと興味を持ったっていう感じですね。
そうです。
これは自分の中で結構明確なきっかけがありました。
当時、データサイエンティストとかAIって言葉がバズり始めていたのですが、それをいち早く扱った先生がいて、その人の授業を受けたときに「これは面白そうだぞ」ってなったんですよ。
いろいろ調べて、ゼミでデータサイエンティストとかそういうの勉強したいなと思っていたんですけど、「これってプログラムも書けないとできないよね？」ってことに気づきまして(笑)
じゃあ先にプログラミングやろうってなって、やり始めたらどんどんはまっていったって感じですね。
マネージャー視点だと、やっぱりチームのメンバーが気持ち良く仕事ができてることを感じれたときですかね。
直接そういう評価をもらえたときですね。
少し前の話になるのですが、僕がメインでプロジェクトの旗振りをしていた時にリリースが遅れてしまうことがあったんです。
どうにかして巻き返したいっていう思いが強く出た結果、メンバーとの関係性に不和が出てしまったんですね。
そこで「信頼関係ができてないのに、気持ちよく仕事ができるはずがない」と猛省して、マネジメントや人との付き合い方の本を読んで、よさそうだと思ったことをひたすら実践していきました。
そしたらメンバーから「柔和になった」という評価をもらえて、改善の兆しが見えた時に非常にやりがいを感じました。
– 逆に、メンバーとして手を動かしていたときはどういうところにやりがいを感じていたんですか？
「ユーザーのことを考える」と「ユーザーが分かりやすいプロダクトにするにはどういうコードを書けばいいか」という2つのことを考えるのがすごく好きでした。
僕自身、プロダクトへの愛が強いというか、プロダクトをもっとよくしたい、ユーザが使いやすいものにしたいって思いが強いんです。
今のチームで扱っているのは結構複雑なシステムで、比較的ハッピーが発生しやすいものなんですが、それをどうユーザーにとって使いやすくするかを考えるのもすごく楽しいです。
バグのことです(笑)
freeeでは「解決することによってユーザーをハッピーにすることができるから」という理由でバグのことをハッピーと呼んでいます。
もともとは「バグって言うと憂鬱になるからもっといい表現はないか…」というきっかけで安易に導入されたのですが、今でもその風習が残っています(笑)
それらを逐一つぶしていくっていうのも楽しいんですけど、もっと抜本的にハッピーをなくすにはどうしたらいいのかなとか、そういうことを考えて実行していくのがやりがいでした。
そこは結果論なのかなと思います。
ユーザーさんにプロダクトのファンになってもらいたいし、Twitterとかでfreeeのソフトが便利というつぶやきを見るだけでもうれしい。
僕自身、継続して使っていてファンになっているアプリも色々あるので、そういうプロダクトを作りたいと思いますし、ユーザーにもそう思ってもらいたい。
そんなことを考えているうちに、プロダクトそのものが好きになってたんだと思います。
今のチームはエンジニア歴が長いメンバーが多くて。技術的なこととか知識でいえば僕より詳しい人もいるので、頼りがいしかないです。
僕はマネージャーという立場ではありますが、年も一番若いです。
経験等で劣っている部分はどんどん頼って、チームをよくしていくことにフォーカスすることを意識しています。
チームはアプリケーション側とインフラ側で別れていますが、アプリケーション側ではfreeeが使う大事な機能の開発して、他社での経験厚いメンバーがどんどん改善案を提案してくれたりします。
あと、僕はインフラにあまり強くないので、インフラのチームのメンバーに助言をもらいに行ったりとか。
挙げ始めたらきりがないんですけど、頼もしいメンバーばかりです。
「ユーザーにとって価値のあるものを届ける」っていうことを社員全員が一番に考えているので、その考えの前では全員の意見が平等なんです。
年が上だとか下だとか、肩書きも関係ない。
そういった文化があるから若手でも意見を汲み取ってもらえて議論してもらえるし、そこは魅力だと思います。
ただ新しい技術だからって理由で取り入れるんじゃなくて、きちんと目的を考えて技術選定ができる人。そして本当に価値があるものを追求できる人。
あと、ユーザー視点を持てるというのはもちろんですが、社内とか社外とかのステークホルダーのことも考えて、自分の意見をただ押し通すだけでなくきちんと価値のあるアウトプットを出せる人。
最後は僕のチームの特性なんで特殊なんですけど、カオスサーフィンができる人。
freeeが求める人物像の1つに「カオスサーファー」というものがあります。
これは「目標を達成するために変化することをいとわず、過程にあるカオスを楽しむことができる人」という意味です。
常に変化する状況とか自分の力だけではどうにもできなかったりする状況でも、そういうカオスを楽しめる人。
我慢できる人じゃなくて楽しめる。
楽しんで前向きに捉えて、じゃあどうしていくかって落とし込める人にぜひ来てほしいなと思います。
僕もそうだったのですが、初学者の時って最初何からやればいいかわからなくて、一番いい方法を延々と模索してしまうかと思うんです。
そういう時は、まずはRailsチュートリアルやPythonチュートリアルのような、体系立って学習できるものを一つやってみるのが良いかなと思っています。
それをやっていくうちに「ここをこうしたい」みたいな思いが生まれてくると思うので、そこで色々調べて記事とかを見てみる。
そこで色々躓くと思うので、そういう時はなるべく1次ソースを追っていく、ということを心がけるとよいと思います。
あとはとにかくコードを書き続けるしか無いと思います。
バージョンごとの最新の情報等が網羅的に把握できるところです。
オリジナルの資料をしっかり理解することで、いろんな応用も利かせられるようになって、将来的にも力になるはずです。
– ありがとうございました！！
