freeeのプロダクトセキュリティを高めるための取り組み

この記事はfreee Developers Advent Calender 2018 21日目の記事です。

 

こんにちは、freeeでCSIRTとソフトウェアエンジニアの二足のわらじを履く liva です。

社内では「攻撃する人」で通ってます。日常の本人は至って無害です。

 

早いものでもう年末で、この記事が公開される日は会社の忘年会です。

きっと今年もどんちゃん騒ぎです。お酒は好きですが酒に呑まれてインシデントを起こさないように気をつけたいところです。

 

freeeのプロダクトは日々様々な機能開発が行われ、短いスパンで各種リリースされ、プロダクト自体が大きくなっています。

それに伴って外部からの侵入や情報漏洩を狙った攻撃を受ける可能性が増えてきています。

この記事ではそういったことを防ぐために社内で行ってる取り組みを紹介します。

1週間前に公開されたeijiさんの記事よりはプロダクト寄りのお話になります。

developers.freee.co.jp

 

 

商用ツールを利用した脆弱性診断

freeeのプロダクトは大規模でとてもじゃないけど人が全部見切れる量ではありません。そこで脆弱性診断に特化した商用のツールを利用して日々スキャンをかけています。いわゆる内製化です。1年かけてようやくメインプロダクト1つを完了させられました。巨大すぎるぞ。

ツールは「現状どうなっているか」を把握するために利用しています。検出されてきた脆弱性は以下の観点で対応要/不要のハンドリングを行っています。

  • その脆弱性の存在確認
  • その脆弱性を突かれた場合の被害と影響範囲

ツールは機械判定なため、どうしても誤検知の問題があります。そのため、まずはその脆弱性が本当に存在するのかを確認します。誤検知であることがわかった場合は、そこで対応は終了です。

存在していることがわかった場合、その脆弱性による被害と影響範囲を調査します。ここで言う「被害」とは金銭的であったり、社会的信用であったり、様々です。情報が漏洩する場合は社会的信用が、サービスダウンを引き起こす場合は金銭的な被害と社会的な信用が失われます。被害を想定し、その影響範囲を想定し、対処する/しないの判断を行っています。

対処する場合、機能によっては私が修正することもありますが、そのコードを実装した人にお願いすることもあります。現状は私が修正を行うことが多いです。

 

外部ベンダーへの脆弱性診断依頼

ツールだけではが存在するのでそれの対応として外部のセキュリティベンダーに依頼することもあります。第三者の専門家に依頼するため、私が業務の合間に片手間で探すより安心感があります。

依頼時は

  • 実施時期
  • 対象プロダクト
  • 仕様書や関係ドキュメント

の3点をまず伝えて、ざっと診断の規模を測ってもらいます。ざっくり出してもらった後は規模の調整をして、環境準備やベンダーから送られてきたヒアリングシートへの記入等を行い、診断を実施してもらいます。あとは報告書を受け取って内容を吟味します。修正の要否をざっと出した後、開発チームに脆弱性の修正を依頼、終わったところで再診断を実施します。このあたりはどこのセキュリティベンダーも同じ流れでしょう。

特定の期間中、第三者に見てもらえるのでとても助かります。

 

     

 

商用ツールは主に既存プロダクト、外部ベンダーは新規プロダクトと使い分けています。

プロダクトの性質によっては新規プロダクトであっても商用ツールを利用して回すこともあり、その場合の手動で見る箇所は私が担当しています。私は元々セキュリティベンダーで脆弱性診断をやっていたので、このあたりは慣れています。ある程度管理できる環境で攻撃を試せるので、第三者の立場でやっていた頃に比べて、とても気楽にやっています。

 

     

 

脆弱性診断以外で進めていることとして、開発者向けに脆弱性診断のTips集を作成して、PRレビュー時の動作確認に活かしてもらおうという試みが進行中です。その第1段としてTips集を作成しているのですが、この記事を書きながら並列で進めています。この記事が公開される頃には社内にも公開されているでしょう(多分)。

開発者にやってほしいという理由としては、コストと手戻りの省力化です。脆弱性診断を実施する頃になるとプロダクトはほぼ完成していてリリースを待っている状態です。そこで脆弱性を検出し、修正を行うとなると多大な手戻りが発生します。時間やコストの無駄になるため、PRを出した段階で最低限確認してほしい項目を出して、それを開発者に確認してもらい、必要なら修正してもらおうと考えています。

このあたりはまだ固まっていないので年始から本格的に検討していく予定です。

 

また、社内エンジニア向けのイベントとしてQ毎にhardeningというのをやっています。

悪いこと考えるおじさん’sがわざとセキュリティホールを作ったサーバーとプロダクトを用意して、参加者に配ります。2日間でセキュリティホールを探して修正、修正期間が終わるとおじさん’sが攻撃を仕掛けます。

今年の新卒で入社したエンジニアとバリバリの現役エンジニアを対象に2回実施して、概ね好評でした。

こちらは過去に本ブログで記事が公開されているのでよかったらどうぞ。

developers.freee.co.jp

 

freeeでは一緒に働ける人を募集中です。

jobs.freee.co.jp

 

CSIRTエンジニアも募集中です。

www.wantedly.com

 

明日は弊社の第1号社員平栗さんです。

freeeが関西で開発組織を立ち上げた理由

こんにちは、freeeの関西支社で開発部長をしている yoshi と申します。この記事は freee Developers Advent Calendar 2018 の20日目です。

この記事では、今年立ち上げたばかりのfreee関西支社の開発組織の紹介となぜ関西に開発組織を作ったのか、その理由を書きたいと思います。

freeeの関西支社開発組織

freeeは2018年4月から関西支社に開発組織を立ち上げました。 オフィスは大阪のグランフロント大阪にあります。私は1人目のエンジニア兼エンジニアマネージャーとして、組織を立ち上げ拡大していきつつ、プロダクトもばりばりと開発していくという役割を担っています。昔からエンジニアリングもマネージメントも好きなので、プレイングマネージャーとして働き、自分のチームのエンジニアが楽しそうに活躍している様子をみるのが生きがいです。

f:id:yt-yt:20181220161743p:plain
グランフロント大阪

2018年12月時点で入社予定の方も含めるとメンバーは5名まで増えており、安定して開発を行っていける体制が整いつつあります。 先月リリースされた 人事労務freee とSlackの連携機能は関西チーム単独でSlack社とやり取りを行い開発しました。

jp.techcrunch.com

また「なにかあればとりあえずたこ焼きを焼いておく」という思想があり、freee社内では通称「チームたこやき」といかにも関西らしい名前で呼ばれています(ちなみに私は福岡出身です)

米油を使うとおいしい
米油を使うとおいしい


東京とそれ以外の地域で働くエンジニア事情の整理

今回の本題に入る前に少しだけ、前提となる状況を整理しておきたいと思います。

エンジニアは働く土地に関わらずパフォーマンスを出すことができる

freeeでは何人ものエンジニアが東京以外の土地で働いています。freeeに限らず、開発に必要な環境や情報が揃っている状態を作ることができれば、働いている土地によってパフォーマンスが大きく変動することはないと感じています。ネットワークやwebサービスの進化により、PCとネットがあればどこでも仕事ができる世の中になってきました。

東京とそれ以外の地域だと待遇に差があることがまだまだ多い

私は関西で12年ほどエンジニアとして働き、転職も数回しているのですが、ほぼ同じような仕事内容でも東京のほうが条件が良いということが多々ありました(年収ベースで100万〜200万くらいの差があることも)。実際に私の周りでも、この差を感じ東京に移住したエンジニアが何人もおり「地方で技術力を身に着けたのち、東京の企業に転職し待遇を上げる」というのは一つの代表的なキャリアプランとして考えられています。

東京とそれ以外の地域だと情報量や勉強会の量に大きな差がある

TECH PLAY というテクノロジーをテーマとした勉強会を横断的に検索できるサイトで、都道府県でフィルタをかけてイベントを検索した結果です。

■ 開催地:大阪府 で検索
https://techplay.jp/event/search?pref=27

大阪府で開催される勉強会

■ 開催地:東京都 で検索
https://techplay.jp/event/search?pref=13

東京都で開催される勉強会

実に10倍以上の差があります。これはエンジニアに限らず、地方で働いている様々な職種の方が皆さん感じておられると思いますが、東京に比べるとやはり圧倒的に情報を得たり共有する場が少ないです。


この3つの状況を整理したときに、非常に「いびつな状態」になっていると感じました。

エンジニアは働く土地に関わらずパフォーマンスを出すことができる
 → それなのに東京以外とそれ以外の地域では、待遇にも情報にも格差がある

この状況を改善できれば、東京以外のエンジニアもより幸せに働けるはずです。

freeeが関西に開発組織を立ち上げた理由

最後にようやく本題です。最後はシンプルにいきます。
立ち上げた理由は「まずは関西のエンジニア市場を盛り上げて変えていきたい」ということです。
freeeでは、働いている人々の効率を上げ、本質的な活動にフォーカスできるようにしたいという考えで様々なプロダクトを提供しています。組織立ち上げにおいてもその理念に沿って「いびつな状態」を少しずつ改善して、エンジニアがどこで働いても活き活きと楽しみながら働ける場所を作っていければと考えています。

その目的を実現するためにfreeeの関西開発組織では以下のような方針を掲げています。


  • 働き方の多様性を広げ、エンジニアが自然体で活躍できる環境を作る
  • 仕事内容、待遇面での差を一切作らない
  • 関西という土地ならではの楽しいことをする
  • 関西でプロダクト開発に関する情報発信をどんどん行っていく
  • これらを実現することで関西のエンジニア市場を盛り上げる

これが実現できれば「地方で技術力を身に着けたのち、東京の企業に転職し待遇を上げる」というプランだけではなく、そのまま地方で働く、もしくは(いま東京で働いている方を含めて)生活の状況に応じて働く場所を変えるといった選択肢を広げることができるのではないかと考えています。これから関西を盛り上げるためにいろいろなことをやっていきますので、ぜひご期待ください!

またfreeeで一緒に働きたいという方も物凄く募集していますので、興味ある方は気軽にご連絡ください(エンジニアに限らず、デザイナーの方、PMの方幅広く募集しております)

一緒に楽しい未来を作っていきましょう

freeeを担うWebアプリケーションエンジニア募集@関西オフィス - freee 株式会社のWeb エンジニア中途の求人 - Wantedly

関西拠点: U/Iターン大歓迎!UI・UXデザイナー募集!! - freee 株式会社のUI/UX デザイナー中途の求人 - Wantedly

明日はlivaさんの記事です。お楽しみに!

RailsのAPI開発にスキーマ駆動開発を導入して、品質と開発スピードを高める

こんにちは、freee API開発チームのkotegawaです。 この記事はfreee Developers Advent Calender 2018の19日目の記事です。

freeeのAPI開発

freeeでは今年の7月から、API開発専任チームが新設されました。 API開発チームでは、

  • 社外向け新規APIの開発
  • API開発基盤の強化
  • 新規プロダクトの開発

などの業務を社内の認証基盤チームやインフラチームと協力しながら行っています。 今日はAPIチーム発足前にfreeeが抱えていたAPIの課題と、それを解決するために導入したスキーマ駆動開発について紹介します。

APIチーム誕生前の課題

もともと弊社のAPIの課題として、以下のようなものがありました。

  • APIドキュメントと実際の実装に差異があった
    • 開発する度にAPIドキュメントを更新することにメンテナンスコストがかかっており、また手動で更新するオペレーションをとっていたことで、ミスも生まれやすい環境にあった。
  • デグレ問題
    • 社外公開するAPIと社内向けのprivate APIで共通のロジックを使っている箇所が多く、private APIへの変更が、社外APIへの予期せぬデグレ・バグや事前告知のない変更を生むことがあった。

どうやって解決したか

上で挙げた課題を解決するために、APIチームではSwagger(Open API)を用いた スキーマ駆動開発 という手法を取り入れました。

その内容としては、APIスキーマ(仕様書)をjsonやらyamlやらで記述していけば、APIドキュメントやリクエストのvalidation、E2Eテストがスキーマに基づいて自動生成されるような環境を目指していくというものです。

実際にスキーマ駆動開発をどのような技術で実現していったか、以下で解説していきます。

Swagger(Open API)

Swaggerは正式にはOpen APIという名前になってますが、RestfulなAPIの仕様策定・実装するためのオープンソースのフレームワークです。 Swagger のスクリーンショット

画面左側のようにjsonやyamlでSwagger Specという仕様に基づいてスキーマを記述していけば、その周辺ツール群がよしなにAPI開発に必要なものを自動生成してくれます。 Swagger公式ツール群の例としては、以下のようなものがあります。

  • 上記画像の右側のようなAPIドキュメントを自動生成してくれるSwagger UI
  • APIクライアントやmockサーバーを自動生成してくれるSwagger Codegen

committee

Swagger周辺のツール群には上記の公式のもの以外にも多くのがあります。その1つがcommitteeというgemです。

committeeによるRequest Validation

committeeはRackのミドルウェアで動作するgemで、Swagger Specに基づいて記述されたjsonを噛ませてあげれば、そのスキーマに基づいて、公開APIへのリクエストに対してvalidationをかけてくれます。

例えばschema jsonに以下のような定義をすると、

{
  "name": "walletable_type",
  "required": true
  "type": "string",
  "enum": [
    "bank_account",
    "credit_card",
    "wallet"
  ],
  "description": "口座区分 (銀行口座: bank_account, クレジットカード: credit_card, 現金: wallet)"
}

まずは上記が反映されたAPIドキュメントが自動生成され、

image.png

定義した型やenumに反したリクエストを送ると、committeeがRackの層で検知して、↓こんな感じでerror responseを返してくれます。

[ 必須parameter未指定の場合 ]

{
  "status_code": 400,
  "errors": [
    {
      "type": "validation",
      "messages": [
        "walletable_type が指定されていません。"
      ]
    }
  ]
}

[ 指定した型定義やenunの定義から外れたparameterが来た場合 ]

{
  "status_code": 400,
  "errors": [
    {
      "type": "validation",
      "messages": [
        "walletable_type は string で指定してください。",
        "walletable_type は [bank_account, credit_card, walle] のいずれかを指定してください。",
      ]
    }
  ]
}

ただし、committeeがやってくれるのはRackの層で例外を吐いて英語の文字列のエラーを返してくれるだけです。(エラーの種類にかかわらず、raiseするのは単一の例外クラスでmessageが違うだけという、ちょっと不親切な感じ。)

Rack層の例外を拾う仕組みや、英文のエラーをパース・構造化して、意味がわかる形でユーザーに返すロジックは別途実装が必要になりました。

committeeによるResponse Validation

committeeにはリクエストの制御だけでなく、レスポンスの制御も可能です。 具体的な実装としては、RailsのE2E(Requet Spec)で用いる get put 等のメソッドをオーバーライドして、committeeのチェックを噛ませることによって、現在返しているレスポンスがスキーマで定義しているものと相違ないかを確認しています。

現在はこのチェックをCIに組み込んで、APIのレスポンスに影響があるような変更があった場合は検知できるような仕組みにしています。

Swagger, committeeを導入してよかったこと

APIの品質

リクエストを動的に、レスポンスを静的にスキーマと相違ないかチェックできるようにできるようにしたことによって、

  • APIドキュメントと実装の差異
  • APIレスポンスへの意図せぬデグレ

といった冒頭で挙げた問題を自動で防げる仕組みをつくることができました。

schema jsonからAPIドキュメント、validation、E2Eテストを生成し、ユーザーはそれらを得ることができる
雑なイメージ図

また、スキーマから吐き出したAPIドキュメントを事前にQAチームに共有しておくことで、効率的にQAテストを進めることができるようになりました。

APIの開発スピード

開発スピードの観点から見ても、以下のようなメリットがありました。

  • APIを新規開発する際に、スキーマから記述することで、仕様書としてPMにレビューを依頼できる
  • 今まで個別のendpointごとに記述しなければならなかったvalidationが大幅に減った
  • responseの中身をチェックするテストを手動で書いていく必要がなくなった
    • 今までは expect(json['id']).to eq 1 といった感じ、一つ一つのフィールドの値チェックをするために膨大な量のテストを書いていました。

このように、APIを品質・開発スピードの両面で改善ができたので、Swagger, committeeの導入はやってよかったなと思っています。

新たに生まれた辛み

一方で今の運用に何の不自由も感じていないわけではありません。

50を超えるエンドポイントの詳細を1つのjsonファイルに記述していく大変さはやはりあります。 しみじみと思うのが、jsonはやはり基本的に人間が手書きするのに適した形式ではないということです。

このような問題に対して考えている今後の解決策は、

  • スキーマをyamlで記述していく
    • Swaggerはyamlでも記述できますが、yamlもyamlでネストが深くなると辛みも深くなるので根本的な解決にはならない
  • jsonファイルの分割
    • jsonを書く業から逃れられるわけじゃないので、これも根本的な解決にはならない
  • Protobufでデータ構造を定義して、jsonにシリアライズする
    • protoc-gen-swaggerというプラグインを活用すれば、Swaggerに対応した形式のjsonファイルも吐き出せる

将来的には「Protobufでスキーマを記述してSwagger形式のjsonにシリアライズ」というよりは、REST APIからgRPCに移行して今のSwaggerツール群がやってくれてることをまるっとProtobufに任せるというのもできればいいなという気持ちがあります。 ただgRPCの普及度を見るとさすがに時期尚早感が強いなと思っています。

freee APIの今後について

APIのさらなる拡充をしていくと同時に、APIチームから新プロダクトもリリース予定です。(正式発表はまた後日ということになっているので、お楽しみに。)

その他にも、

  • 多言語対応APIクライアント
  • Webhook API
  • GraphQL対応
  • AWS lambdaによる実行環境の提供

等々、夢のあるバックログがたくさん積まれています。

API開発チームでは、もっと多くの方に快適にAPIを使っていただけるよう、これからも邁進していきます。是非freeeのAPIを試してみてください。

freee Developers Community | freee Developers Community

また、一緒にAPIを開発していってくれるエンジニアも募集中です。ご興味あれば、ご連絡ください。

freee株式会社 採用情報

明日は関西のたこ焼きチームから大きな存在感を出しているyoshiさんの記事です。お楽しみに!

「業務が一瞬で終わるという価値」を追い求めて ー 決算申告チーム・ハミルトンインタビュー

こんにちは、freee採用チームの西木です。

今回は、freeeで働く個性豊かなエンジニアを紹介する企画の第二弾です。 ということで、決算申告チームに所属する新進気鋭のエンジニア、ハミルトンこと高山湧気さんに話を聞いてみました。

(*第一弾、AWS Container Heroに就任したSREエンジニア・九岡の記事はこちら→前編後編

高山湧気さんの写真

ーfreeeに入社したきっかけを教えてください。

前職では大企業向けのBtoBをやっていて、僕は会計とかHRの製品を作っていたんですが、何となく一区切り着いた時に、他の会社ってどうやって開発とかしてるのだろうと気になり転職エージェントに登録したんです。そこでfreeeを紹介され、話を聞いてみると転職したくなりました(笑)

ーよく似た業種だったんですね。前職とfreeeの違いはありますか?

プロダクトの計画を立ててからお客さんに届くまでのスピードですね。入社して衝撃だったのは、何か機能の開発を任されて、1週間ほどで作ってレビューが終わると、気がついたらお客さんが使っていたりとか。freeeのスピード感はすごいですよ(笑)

高山湧気さんの写真

ー簡単に「決算申告チーム」の仕事と、その中でハミルトンが何をしてるか聞かせてください。

チーム全体では、アドバイザー(公認会計士・税理士・社労士など)さん向けのプロダクト開発をしています。その中で僕が担当しているのは、年末調整でアドバイザーさんの申告をサポートする機能(申告freee)と、新しくリリースした顧問先管理freeeの開発です。あとはアドバイザー検索機能など、全てがアドバイザーさんに関する領域ですね。

ーエンドユーザーさん向けとアドバイザーさん向けのプロダクトは、どこが違いますか?

相手が専門領域なので、より高機能なものが求められています。アドバイザーさんにとっても、お客さんに対しての価値をfreeeのプロダクトに依存してる部分があるので、使いやすい上に細かな作業もできるものが好まれますね。 またスモールビジネスをターゲットにしているfreeeにとっても、その間にアドバイザーさんがいることで、さらにfreeeのプロダクトの価値を引き出してくれるので良い関係性を築くためにも良いものを作らないといけません。

高山湧気さんの写真

ーアドバイザーさん向けだからこそ、苦労した部分や面白い部分はある?

わからない言葉やシステムも多く、最初はとっつきにくさはありました。でもチーム内に税理士や公認会計士の資格を持っている人がいるので、聞けば優しく教えてくれました。そうやって前提条件を調べたり聞いたりした上で、教えてもらったことを鵜呑みにすることなく、仮説を立てて検証やアプローチをするようにしています。 そしてプロダクトに新しい機能をうまく反映させ、「この機能、良かったよ」と褒められた時の達成感は半端ないですね。アドバイザーさんから必要とされるものは、身近ではなくレベルも高いのなので、非常にやりがいはあります。

ー仮説立てるのにも、けっこう理解してないといけませんよね? 例えば、新しくチームに来た人はどういう風に勉強しているのでしょうか?  

チーム内のコミュニケーションが多いんです。『とりあえずやってみる→議論する』の流れが徹底されてますね。もっと詳しくいうと、「そもそも何だこれ」→「詳しい人からの説明」→「実際作る」→「コード追う」みたいな作業を、チーム8人で協力しながらやってます(笑)。「わからないことは、聞いてよ」っていう雰囲気があり、それが各々の勉強に繋がってるんだと思います。

ーコミュニケーション取りやすくするための工夫とかありますか?

スクラム開発を取り入れて、フレームワークでやっているところですかね。看板ボードをみて進捗状況を確認しながら、進行中のものは、困っていることがないか聞き合ったりしますね。わざわざ報告しなくても、看板上で見られるのでわからないことが尋ねやすいと思いますよ。

高山湧気さんの写真

ースクラム開発を初めて、コミュ力アップ以外に良かったものはありますか? 

優先順位を決める必要があるので、自分たちのできるキャパシティをわかった上で、削るものを決めることができました。3ヶ月で出来ることも予測がつくので、闇雲に頑張るよりは、必要なものだけに集中できていると思います。 マネージャーがわりと自由にやらせてくれる人なのも大きいですね。スプリントに載せる前に、何を載せるのか考え、プランニングポーカーでみんなでポイント出して……という教科書通りのアジャイル開発をガチでやってるっていうのはチームの特徴ですね。だいぶ時間を投下していますが(笑)。

高山湧気さんの写真

ープロダクト内部の話を聞かせてください。 年末調整の機能開発って、どんなことやってるんですか?

主に役所に申告するの部分の開発ですが、データの集計は「人事労務freee」が自動でやってくれるので、そこはノータッチです。そこから必要なものだけを持ってきて、申告書への自動転記、または電子申告をできるようにしています。あとは「会計freee」の支払調書でも同じように、申告freeeに連携させています。

ーあえてエンドユーザーさん向けのプロダクト(会計freeeや人事労務freee)と分ける理由はなんでしょう?

UIが明確に違っていて、アドバイザーさんって紙提出のフローを長年やってるので、紙ベースの方がいいという方も多いんです。だから紙の形で見せてあげるのは税理士さんのためでもあります。

ー紙の形にするって、freeeの目指す世界と違うのではないですか?

申告をする機能のソフトは世の中にあって、それと同じことができるのというのも大事なんです。「昔からの慣れたやり方でもそのまま出来ますよ」というのは安心感に繋がりますし。紙に書くこともできるし、電子申告することもできるというように幅を持たせるのが大事だと思います。 さらにfreeeのソフトで自動的にできる範囲のことをやった上で、アドバイザーさんしか出来ないような細かな作業もできる設計にしています。

高山湧気さんの写真

ー技術的なことも教えてください。フロントとサーバーどれくらいの割合ですか?

フロント5.5、サーバー4.5くらいですかね。

ーどんな言語やフレームワークで開発されているんですか?

サーバーはRuby on Railsで、フロントはReactですが、あんまり言語に対してのこだわりはなくて。強いていうなら型とかある方がいいですね(笑) 申告freeeはフレームワーク化されてて、一つの帳票を作るってことに対して、本気出せば3時間くらいでA4の紙一枚くらいの機能はできてしまうんです。わりと生産性がいいというか、うまく作れていますね。

ーどうしてうまくいったんですか?

ひとえに初期の設定が上手かったとしか言えないですね。最初から種類を増やすことが容易にできるように作ってあって、汎用性が高いのでありがたいです。僕は設定が完成した後から入社していますが、かなり感謝しています。

ーここは大変というところはあった?

一番大変なのは、様式改定とか、毎年税が変わることに追従したりすることですね。あとはロジックが複雑で、近くに税理士がいても、仮説立てたりとかそういうところには手を抜けない。難しいものを理解しないといけない場面は多いです。 そのほか、顧問先管理freeeでは膨大なやりたいことが出てくるんですけど、どこに絞ってどこに価値を出していくか決めて、実際に検証することですね。

高山湧気さんの写真

ー決算申告チームが目指すものを教えてください。

エンドユーザーに価値をだすことが根本にあるのは確かです。それを目標にしつつアドバイザーに働きかけることを考えると、効率化ですね。つまり「業務が一瞬で終わる」という価値です。 顧問先からデータを集めたりそれをチェックしたりする作業が、まだまだ効率化されていない領域だと思っています。簡単にチェックできたり、大量の書類を封筒に入れたりせずにすむようにしたいですね。 時間を気にすることなくエンドユーザーに向けて価値あるアドバイスができるという状態も、その先にあるのだと思います。アドバイザーさんを通して、スモールビジネスに従事する人を幸せにしたいです。

ー自分の中でもっと良くしたいと思っているところは?      申告の種類とか、対応できる幅をもっともっと広げたいですね。既存の製品と同じことができるのは当たりまえで、そこからもっと追求していきたい。他のクラウド製品、会計freeeや人事労務freeeと繋がっているからこそ広がる世界は、まだまだこんなもんじゃないと思います。

クラウドにあるからこそ確認がしやすかったりとか、一つの申告書を誰かが一斉に申告するとか、顧問先からデータをもらわなくても勝手に会計freeeに入ってるとか、そんな機能を利用して、アドバイザーの仕事を進めやすくするのにもっと貢献したいです。

ーこの先もっとやっていきたいことは?

とりあえず今はfreeeでやりたいことがいっぱいありますね。こんなに新しいことに積極的に挑戦できる場所ってなかなか出会えないので、将来どうなっていくか楽しみなんです。スモールビジネスが効率化してゆくのを、自分の目で見たいですね。

ー最後に、こんな人にfreeeに来て欲しいってありますか?

テクノロジーで世の中をよくすることに、喜びを感じている人がいいですね。