【コラム】freeeのエンジニアマネージャーに聞く！freeeの組織づくりに必要なこととは？

クラウド会計でトップシェアを誇る「クラウド会計ソフト freee」。その開発・運営を行なっているのが、五反田にオフィスを構えるfreee株式会社だ。

同社の事業領域は会計ソフトだけではない。「クラウド給与計算ソフト freee」「会社設立 freee」など、中小企業のバックオフィス業務を手助けする様々なプロダクトを展開している。

さらに、2012年の創業以来、プロダクトだけではなく、組織の規模も拡大を続けている。2017年3月末現在、250名の社員を抱えるまでに成長した。

組織が急速にスケールを進める中、freeeではどのように開発を行なってきたのであろうか。本稿では、エンジニアマネージャーを務める加来純一さんにお話を伺った。

加来純一（かく・じゅんいち）／freee株式会社 ソフトウェアエンジニア エンジニアマネージャー エンジニア採用担当。青山学院大学卒。ウェブサービスを運営する企業での勤務などを経て、2013年にfreeeへ入社。猫派。

チームはまだ無い。

――　まず、加来さんがfreeeにジョインされた経緯を教えてください。

加来　2013年秋頃、「履歴書とか職務経歴書は持ってこなくていいから、遊びにこない？」と声を掛けてもらって、当時まだ麻布十番の近くにあったfreeeのオフィスを訪ねたんです。そこで、代表の佐々木とCTOの横路と3時間くらい話をしました。

最後に「で、いつから来るの？」と言われまして（笑）。結局、2013年の12月にエンジニアとして入社しました。

――　当時はどのくらいの規模だったのですか？

加来　メンバーは全社で10名ちょっとでしたね。プロダクトもまだ「クラウド会計ソフト freee」だけでした。

――　加来さんはどのような業務を担っていたのですか？

加来　前職で「Ruby」を使ったサーバーサイドのエンジニアを務めていましたので、「クラウド会計ソフト freee」でも同じ領域を担当していました。

当時は、まだメンバーが少なかったので、レビューは行なっていたものの、チームとして開発するという概念はあまりない状態でした。

――　チームとして開発するようになったのはいつ頃ですか？

加来　新たなプロダクトである「クラウド給与計算ソフト freee」の開発が始まった2014年4月頃だと思います。もちろん、共通のアプリケーション基盤を開発するエンジニアもいるのですが、その辺りからプロダクトごとにチームが分かれていき始めました。

当時の社員数は20から30名ほどでしょうか。エンジニアも15名前後いたと思います。

――　実際にそのような体制に移行していかがでしたか？

加来　あるとき、設定した大きな目標が5つくらいあって、ほとんどその目標が達成できないことがあったんです。

ユーザーに対して価値を提供できていないし成果も達成できていないので、メンバーのモチベーションが上がらないなどの問題が出てくるようになりました。

「ちゃんとしたマネジメントが必要だね」という話になったのですが、担当を一人置くだけでは、20名規模のメンバーの仕事を理解してフィードバックすることは到底できませんでした。

そこで、日頃からチームについて話し合っていた私も含めた3名がマネージャーとして加わることになり、2015年7月から4人体制でマネジメントに取り組むようになりました。

――　マネージャー職に就いてからは業務がどのように変わりましたか？

加来　現在もエンジニアリングはやっているのですが、ボトルネックになってしまわぬよう、期限付きのタスクは持たないようにしています。

マネジメントに関しては、立場上いろいろな情報も集まってくるようになりましたので、チームの運営がうまくいくためのあらゆることを求められるようになりました。

――　マネジメントにおいてどのようなことを重要視していますか？

加来　持っている情報をあえてメンバーに何度も繰り返して伝えることです。そうしないと、メンバーも「これ、なんのためにやるんだっけ？」と当事者意識が出ない部分があったりするんです。実際に、自分が現場にいたときにもその経験はあったような気がします（笑）。

現在のプロジェクトでも、メンバーにはその意義を何度繰り返したのかわからないくらい伝えています。

――　なぜそこまで徹底されるのでしょうか？

加来　私たちは価値基準として「本質的（マジ）で価値ある」という言葉を掲げ、「ユーザーに対して本質的に価値のあるものを提供しよう」という考えを重要視しています。

この価値観に共感して入社してきた社員も多くいるので、彼らには情報もなく作業だけを指示するやり方は合わないんです。

ですから、私は会社や顧客の状況、課題などの情報をしっかりと共有します。そして、メンバー全員で話し合って、解決策に落とし込んでいくわけです。その結果として、いいプロダクトが作れていると思います。

求められる「共有力」

――　チームを円滑に運営するために行なっている取り組みがあればご紹介ください。

加来　エンジニア全体で行なう毎日の朝会では、「朝会改善部」のメンバーが常にプロダクト改善のための話し合いをしています。

また、組織がだいぶ大きくなり、エンジニア同士でも知らない人が増えてきたので、ランダムランチを企画したりしていますね。

これらはメンバーの自発的な活動です。

社員全員が理想を目指して、様々な改善を行なうことは、組織にとってとてもいいことだと感じていますね。そういう活動をすることを推奨したり細かいことを言って止めないようにしたりしています。

――　どのような開発手法を採用しているのか教えてください。

加来　全社として統一している開発手法はなく、チームごとに異なるのですが、どこも「スクラム的」なやり方になってきているように思います。完全なスクラムではないのですが、朝会で開発状況を共有したり、ウィークリーで振り返りを行ないながら進めています。

タスク管理はチームによって違います。看板型のものを使うチームが多いかもしれないです。「Trello」や「Zenhub」など。

――　ツールや技術の採択はどのように行なっているのでしょうか？

加来　CTOやマネージャーのような立場ではなく、チームのメンバーの誰かから自然発生的にあがってきて決めることが多いですね。

旗振り役となったエンジニアに「なぜこれを採用した方がいいと思うのか」をまとめてもらい、判断しています。

――　現在のマネージャーという立場になって、エンジニアリングを行なう割合は減っていますよね。どのような感情をお持ちですか？

加来　自分の手を動かしたいという葛藤はありますね（笑）。

私がマネジメントしているのは、自身もプレイヤーとしてずっと携わってきたアプリケーションの共通基盤を担当するチームです。だから、よく実情がわかるんですよね。自分で手を動かして改善してしまった方が早いと思うような段階もあるわけです。

――　単に手を動かせないことに対してだけではなく、そういった葛藤もあるわけですね。

加来　ただ、それをやってしまうと大きな改善は達成できないことも、もちろんわかっていました。ですから、2016年の4月にチームを新たにつくり直して、しばらく我慢して様子を見ていたんです。

すると、そのチームは以前と比較すると信じられないほど成長し始めました。あの時もし自分が手を動かしてしまっていれば、この成長は得られなかっただろうと感じます。

――　加来さんは、全てのエンジニアに「マネジメント力」は必要だと思いますか？

加来　マネジメント力がどこまでを指すかにもよるんですが、エンジニアにも「マネジメント力」は必要だと私は思います。でも、それは「エンジニアが最終的にはマネージャーをやるべきだ」という意味ではありません。

例えスペシャリストの立場のエンジニアでも、「今の状況で何を行なえばプロダクトがよくなるのか」を考えて、優先度に折り合いをつけたり、それを周りに共有することが求められると思います。先のツールや技術の採択についてもマネジメント力の一種なのではないかと思うんです。

――　スペシャリストにも「マネジメント力」が必要だということですね。

加来　スペシャリストとしての能力をどんどん伸ばしていこうと追求すれば、自ずと「マネジメント力」が求められ、身につくと私は思っています。ヒューマンマネジメントについては必要ないかもしれません。

――　具体的にはどのような力がマネジメントに求められるとお考えですか？

加来　スペシャリストとして今なにをすべきか優先度を付けることや、導入したい技術があるならそれについて何を調査するか何をしないかなど決めるような力が必要だと思います。広い意味での「マネジメント」ですかね。

マネージャーとして大切なのは「共有力」だと思います。freeeでは「あえて、共有する」という価値基準もあり、共有する必要がないと思うような情報でも、私はメンバーを信じてあえて教えるようにしています。

もしかしたら情報が足りないために、考えても解決できないこともあるかもしれません。ですから、マネジメントの際には情報を共有することが重要なんです。

そして、「ユーザーに対して本質的な価値を届けること」が、マネジメントにおいても開発の現場においても、一番の根本だと思っています。その達成のために、開発チーム全体で最善の取り組みが行なえるようにマネジメントしていきたいですね。