「チーム作りはプログラミングだ」とMisocaのエンジニア社長が豪語する理由

Web上で請求書の作成・処理が行える無料サービス「Misoca(ミソカ)」。2011年の11月にサービスを公開してから3年半で、ユーザー数は既に4万人を上回っている。

サービスを運営しているのはスタンドファーム株式会社。現在、6人のコアメンバーと4人の外部サポートメンバーからなる同社の代表・豊吉隆一郎氏曰く、「創業当初からリモートワークを推奨し、現在もチームメンバーに出勤義務は与えていない」と話す。社員10人中9人がエンジニアという組織をリモートでどのようにマネージしているのか、プログラマ集団をどのように1つのチームとして成り立たせているのか、お話を伺った。

15413_misoca_IMG_5131_580

豊吉隆一郎氏。スタンドファーム株式会社代表取締役。1981年岐阜県生まれ。岐阜工業高等専門学校 電気工学科を2004年に卒業後、TOYOSYSTEMとして個人事業でWeb受託開発業を開業。2011年、スタンドファーム株式会社を創立し、代表取締役に就任する。

フリーランス時代から7年。自前のサービスを持ちたいと感じて

-豊吉さんは高専を卒業後、企業に就職せずに個人で事業を行っていたそうですが、そこからスタンドファーム株式会社を立ち上げた経緯について教えてください。

高専時代から、企業のWebサイトやECサイト制作のお手伝いをしていましたから、卒業してからも取引を継続できるなと思っていました。また、「入りたくもない企業に頭を下げて就職活動するのはいかがなものか、だったら独立してしまったほうが早いのではないか」という考えもありました。それから7年ほど個人事業主としてWeb受託開発を行うなかで、自分でWebサービスの運営にも携わってみたい、という思いが次第に強くなりました。

そこで、僕が主催していた勉強会「CSNagoya」の共同主催者・松本(同社取締役の松本哲氏)に、2人で一緒に会社を立ち上げようと声をかけたのが創業の経緯です。

-つまり「Misoca」というサービスありきで、立ち上げた会社ではなかったんですね。

はい。最初に手がけたのはイベントの料金徴収の支援サービスでした。私たちが知り合うきっかけとなった勉強会では、懇親会もセットで行っていて、その料金の徴収が面倒でした。当時は、それを解決できるサービスがあまりなく、PayPalなどを使って事前決済できるシステムがあればいいと考え、自分たちの悩みを解決できるサービスを作りました。

ただ、同じことを感じている人たちも多くて、同時期にリクルートが「eventATND」というサービスを始めたり、「Peatix」や「Doorkeeper」などの類似サービスが台頭してきました。資本力もなく、たった2人でやっている状況では、「これは勝てない」と思い、方針転換して本格的に資本を投下していこうと考えたのが「Misoca」なんです。サービスの構想を考えてから、5カ月でローンチしました

このご時世、出勤の義務は非効率的

-「会計の無駄を省く」「業務の効率化」が「Misoca」の大きなコンセプトだと思いますが、リモートワークを推奨しているのも「無駄」を省くためなのでしょうか?

基本的にはそうですね。私自身、気分が沈んでいる日や雨の日に出勤するのは気がめいってしまうこともあります。だったら、最初から出社したくない日はしなくていい。重い腰を上げて会社に来なくても、自宅なら移動する必要なく仕事に取り掛かれますから、そのほうが絶対に効率的だと思っています。平日の毎朝10時30分に朝会をやっていて、Goolgeハングアウトで、その会議に参加していれば、OKということにしています。

-リモートだとメンバーがサボろうと思えば、いくらでもサボれてしまいますよね。そのあたりのリスクヘッジはどのようにしているのでしょうか?

たしかにそういうリスクはありますし、ビデオチャットのコミュニケーションは対面に比べると意思の疎通できるレベルが80%程度だと感じます。ですから、より意識的にコミュニケーションを図ることを心がけています。

弊社では、「毎朝の朝会」「週次の開発ミーティング」この2つの会議を中心に行っていますが、それだけでしっかりコミュニケーションを取れているので、大きな問題に発展したことはありません。

朝会では、今日何の作業をやろうとしているのか、タスクを報告しあって、進捗を共有しています。当社では、「Trello(トレロ)」というタスク管理ツールを導入し、メンバー全員に共有しているため、お互いの残タスクや、今取り掛かっている作業、滞っている作業がひと目でわかるようになっています。例えば、あるタスクが、しばらくの間消化されずに残っていた場合、その理由が誰ともなく質問されます。そして困ったことを共有する時間にも、問題の解決を社員のメンバー全員で議論するようにしています。こういう意識がメンバー全員に備わっているからリモートのメンバーがいても問題ないと思えるのです。

15413_misoca_03_580

Trelloの公式HPに掲載されている、使用イメージ画像。ひと目で抱えているタスクの中身がわかるようなデザインになっているのが特徴的だ

 

「自己組織化されたチーム」が理想

-これまでのHRナビの記事でも「未来に中間管理職の役割はなくなる」と東大の准教授が発言していますが、その考えに通じる部分はあると思いますか?

あると思います。私は「チームとはプロセスである。自己組織化されたチームを目指そう」と社員によく話しています。つまり、誰かに監視されているからやるとか、されていないからやらないというレベルの話ではなくて、常により効率的なサイクルを求めて、改善・検証を重ねていくことができるのが正しいチームのあり方である、と。

例えば、週の振り返りで「先週こういうことがよくなかった」という議題があがると、「次は打ち合わせの時間を短くしてみよう」とか、「別の新たなツールを試してみよう」といった話題が出ます。議題があがったときに、じゃあどうしようと思考停止になるのではなくて、「次の週だけ別の方法で試してみる」といった具合に、実験的でもいいからやり方を最適化していける、新しいやり方を提案しやすい雰囲気を意識しています。その共通認識があれば、働く場所がどこであろうが、関係ないと思っています。

15413_misoca_IMG_5122_580

お問い合わせ対応を当番制にしてからエンジニアの意識が変化

-社内での新たな取り組みはありますか?

ユーザーのお問い合わせにエンジニアも当番制で答えるという仕組みを、2週間前から導入しました。これまで、お問い合わせの内容は、ほぼ自動的に社内チャットツールの「Slack(スラック)」に流していて、全員が見られるものの、私1人で回答していました。あるとき、ふと思いついてこのシステムを導入しました。

「エンジニアはユーザーとのやり取りには興味がないかもしれない」という心配もあったのですが、ふたを開けてみたら、決してそんなことはなかった。年配のユーザーの疑問をダイレクトに知ることができて、エンジニアの満足度も高いようですね。また、リテラシーが高いユーザーに対して「すみません。現在、この機能はありません」と伝えるのが、どれだけ辛いかを実感してもらえるようになったことは1つの大きな経験値で、僕としてもうれしい部分ですね(笑)。

単にコードを書くだけではなくて、1つのサービスを成長させていくという目的を理解する上で、エンジニアがダイレクトにユーザーとのコミュニケーションや渉外をやっていくことは、組織としてプラスに作用していると感じています。

プログラマはキーボードを打つことにやりがいを感じているわけではない

-チームは自己組織化されていて、4月現在、サービスのユーザーも5万人目前と、勢いを感じるのですが、サービス開始からの3年半を振り返って大変だったことはなんでしょうか?

大変なことばかりでしたよ(笑)。先ほど、コミュニケーションを大事にしている、ということを話しておきながら、恥ずかしいのですが、私自身も話すことに苦手意識を感じていますし、外部の人にどうやってサービスを伝えていくか、という広報面をあまり重視してこなかったので、認知してもらうまでに時間がかかったと思います。

サービスローンチ直後の2011年に、TechCrunch Tokyoのスタートアップバトルのファイナリストに残ることができて、そこで業界の人に認知してもらえたのはすごく大きい経験でした。ただ、10回TechCrunchで紹介されても、見ていない人は見ていないじゃないですか。
そこをエンジニアは理解できないんですけど、そうした狭い考え方から経営者として、広くマーケットを意識して、サービスをアピールしていく視点を持つまでが大変だったなと。人から意見を伺うのは得意なんですけど、自分からサービスの強みを発信していくことがあまり上手ではなかったなと思っています。

あと、みんながエンジニアなので、問題が起きたときにどうしても仕組み・プロセスの力で解決しようとしてしまう癖があって…。よくよく考えたら電話1本3分で解決する問題を、みんなで頭を抱えて議論していたりとか、そういうトライ&エラーを何度も重ねてきました。

-エンジニアから経営者としての視点を持つことができた理由はなんでしょうか?

プログラムのいいところは、一度書いたらずっと同じように延々と動き続ける点。そして世の中に価値を提供し続けるという点だと思っています。その考えをもう一歩高い視点から見ると教育やチーム作り、会社経営もプログラムだと思えるようになったんです。

自分が知っている知識を教えてあげたら、その人が同じことができるようになる。例えば、ひとたび自転車の乗り方を教えたら、その子は生涯自転車を乗れるようになる。その仕組み自体に楽しみを見いだす人間なので、会社のチーム作りが、コード書きと同じかそれ以上に楽しいなと思っています。だから、組織としてサービス改善を自動化させていくために自分自身がコードを書くより、もっと俯瞰的なところから見てチームの仕組みを作っていくというほうが、より自然だと思えるようになりましたね。

誤解しがちなのが、プログラマってキーボードをカタカタと打っている作業自体にやりがいを感じているのではなくて、カタカタやっているうちに、プログラミングやシステムが自動化して動きだすことにやりがいを感じているのです。僕にとって、その自動化される部分がコードなのかチームなのかという違いなだけかなと思います。

もちろん人間なので、エラーもありますし、教えた通り動かない部分もあるので、チーム作りのほうが難しいのですが、「チーム作りはプログラミングだ。そうであるならプログラムが動かないのはプログラマの責任だ。チームが気持ちよく活動できるためには経営者として何ができるだろう」というつもりでやっていますね。

より効率的な請求書のあり方を考える

-最後に「Misoca」のサービスのこれからの目標、そして会社としての目標を教えてください。

「Misoca」は現段階で、PDFファイルで請求書をやり取りするというところまで進みましたが、その先の「未来の請求書のあり方」を、もっと考えていきたいです。例えば、スマホで作成・郵送までできる請求書サービスとか…。もっと効率的に請求書を送れるシステム、もっと短時間で見積書や請求書が作れる仕組みを作っていきたいですね。

数値目標としては、10万ユーザーを早く達成したいと考えています。IT業界以外では、まだまだ紙の請求書を郵送するのが当たり前で、すべてのやり取りを電子化するところまで行っていないので、そういう人たちにどうやってサービスの魅力を伝えていくか、そしていかにシンプルに請求書が作れるかというのを端的に示すのが、10万ユーザーを達成する上での課題だと認識しています。

私個人としては、エンジニアの能力が100%発揮できる環境作り、チーム作りに邁進していきたいと思っています。

(HRナビ編集部)