freeeの脆弱性診断と管理のこれから

この記事はfreee Developers Advent Calendar 2019 の 22 日目です。

酒飲みエンジニアのlivaです。今年の健康診断で尿酸値が8.6という高数値になりました。まだ痛風発作は出ていませんが、いつ出るかヒヤヒヤしながらお酒を飲んでいます。

普段はCSIRT専属エンジニアとして、各プロダクトに対する脆弱性診断やペネトレーションテストなどの作業を行いつつ、検出された脆弱性のトリアージや修正対応などの業務を行っています。

毎年春に新卒研修で行っている研修のおかげか、社内では攻撃者として名が通っています。今年の研修では物理的な攻撃を受けそう*1でしたが、居場所を隠していて事なきを得ました。なかなか物騒な新卒たちです。

さて、この記事では今社内で静かに進めている脆弱性診断や管理の刷新プロジェクトを紹介します。


現在持っている課題感

脆弱性診断や管理では以下のような課題感を持っています。

  • 脆弱性診断結果が活用できていない
  • ライブラリに存在する脆弱性が管理されていない
  • Kubernetes(以下K8s)やDockerなどのコンテナ類に対して脆弱性スキャンが回っていない
  • インフラ周りの脆弱性診断が実施されていない

特にライブラリに存在する脆弱性が管理されていないK8sを利用したサービスやその他インフラに対する脆弱性スキャンが実施されていないのはまずいと考えました。 このあたりに手を入れる過程で、日常的に回している脆弱性診断の結果も活用していこうとプロジェクトにまとめていきました。

プロジェクトの概要

以下のレイヤーに分けてスキャンを実施します。

  • Webアプリケーション
  • サーバー/ミドルウェア
  • コンテナ/K8sクラスタ
  • 脆弱性管理

Webアプリケーションはさらに2つ*2に分けています。

  • ブラックボックステスト(動的診断)
  • ホワイトボックステスト(静的診断)

これらのスキャン結果はAPIを介してAWSのS3に集約します。 S3に集約した結果はKibanaで作成したダッシュボード上で一元的に表示し、これまでの推移や各プロダクトの現在と過去、脆弱性への対応状況が分かる状態を作ります。

また、各ツールはGitHubActionやAWS Lambdaを利用して自動化し、なるべく人が介在しない状況を作ります。

各レイヤーごとにやること

Webアプリケーション

HCL社の提供するAppScan Standard*3を使っており、引き続き使います。しかし、こちらはブラックボックス診断しかサポートできず、ホワイトボックス診断がサポートできません。 そのため、Cloud版であるAppScan on Cloudを利用します。 AppScan on Cloud*4はブラックボックス診断とホワイトボックス診断に加え、iOSやAndroidアプリケーションのスキャナとしての使用もできます。 StandardとCloudを併用する理由は、Standardと連携できるのとCloudではAPが使えるためにスキャン作成から結果取得までAPIで完結させることができるためです。 そもそもfreeeでは以下のような流れでAppScan Standardを使用していました。

  1. AppScan Standardを使ってスキャンシナリオを作成する
  2. 作成したスキャンシナリオを使ってスキャンを行う
  3. 結果を出力してGoogleDriveに保存

3で結果を保存するのはいいのですが、膨大な量のスキャンファイルを一つずつ見ていくのはとても労力のかかる上に非効率でした。 ここにAppScan on Cloudを導入することで、結果をブラウザ上で一覧できるようになります。

サーバー/ミドルウェア

オープンソーススキャナであるOpenVAS*5を使用します。スキャナとしては老舗であり、品質は安定しています。 専用のEC2インスタンスを構築し、そこから弊社が提供しているプロダクト・サービス全体に対して定期的なスキャンを実行します。

コンテナ/K8sクラスタ

記事執筆(12/13)時点ではまだ未定ですが、候補の絞り込みは終わっていてその中のプロダクトを使います。 どちらもコンテナとK8sクラスタを網羅してスキャンを実施できる見込みです。 上記以外にECRに存在するイメージに対して定常的にtrivy*6を使用します。 すでに特定サービスのCIには埋め込んでいて、GitHub上でPullRequestを作成する度にスキャンを走らせていますが、結果は活用できていません。 今後は各PullRequestに流すのではなく、ECR上にUploadされたタイミングで回します。

脆弱性管理

ビズリーチ社の提供しているyamory*7というサービスを利用します。 本サービスの良いところとしては「公開されているPoCを収集してくれる」「自動トリアージが実態に即している」点が挙げられます。 どちらも担当が手動でやろうとすると膨大な時間がかかるため、スキャンの段階でこれらが終わっているのはとても助かります。 ただ、全ての結果を素通りさせるわけにはいかないので、適宜CSIRTの担当(私)がチェックする必要はあります。 結果は過去分から全て集約されるため、yamory内で情報管理できるのもメリットです。対応状況もこちらでわかるようになっています。 「脆弱性対応時のコミュニケーションをどうするか」という課題はまだ残っていますが、叩き台だけ作ってあとは実際に動かしつつ最適解を見つけていくことになるかと考えています。

全体のイメージ

話してきた内容をまとめると以下のようなイメージになります。各ツールからLambdaを叩く部分はまだ暫定です。

プロジェクト完了後のイメージ
プロジェクト完了後のイメージ

プロジェクトはまだ始まったばかり

12月で無事に一部を除いたツール選定と方針決めが完了したため、年始から作り込みを始めていきます。 このプロジェクトを完遂し社内で活用されることにより、プロダクトに存在する脆弱性が可視化され、より強固なプロダクトが作られる未来を実する土台になればと考えてます。


freeeでは一緒に働く仲間を募集しています。 興味のある方はぜひ一緒に働きましょう。

www.wantedly.com

それと、弊社で定期的に行われているfreee Tech Nightの5回目が1/21に開催されます。開催するごとに違ったテーマで話を聞くことができるイベントです。freeeに興味のある方はぜひ参加登録してみてください。

freee-tech-night.connpass.com


明日は弊社CEO佐々木大輔の登場です。普段ならなんのことはない出来事が後日ちょっとしたおもしろエピソードに化けました。

お楽しみに。

Firebaseで作るお手軽業務アプリ

こんにちは。freee APIチームでエンジニアをしているkotegawaです。

去年のAdvent CalendarではAPIのスキーマ駆動開発についての記事を書いて、APIの基盤を整える話をしました。 おかげさまでfreeeの公開APIも当時からendpoint数が40個以上増え、今では freee アプリストア というfreee APIを使ったアプリのプラットフォームに60以上のアプリが並ぶほどの盛況ぶりになっています。

今回はそんなfreeeのAPIを使ってAPIチームがFirebaseを使って自らアプリを作ってみた話をしてみます。

「外貨建取引管理アプリ」をfreeeアプリストアで表示したスクリーンショット
freee アプリストアに掲載しているfreee製アプリ「外貨建取引管理アプリ」の例

この記事はfreee Developers Advent Calendar 2019の21日目の記事です。

会計のWebアプリを作った背景

そもそも本体のアプリを作ろうとした背景は2つあります。

1. freeeのAPIを使った業務アプリのユースケースを提供したい

freeeのAPIは10月にも31種類のendpointが追加されるなど、かなりのペースで増えています。 現状のfreee APIには「勘定科目を更新できるAPI」「取引の支払行作るAPI」「税区分の一覧を取得できるAPI」など、渋いラインナップが揃っていますが、 一方で会計という業務ドメインの複雑な性質上、リソースベースで多くのRESTfulなAPIを提供していても、「具体的にどんなアプリを作ればいいのかわからない」「それぞれのAPIの使いみちがわからない」というフィードバックをもらうことがよくありました。

そんなことなら、自分たちでfreee APIを使った業務アプリを開発して価値提供しつつ、そのアプリをサンプルユースケースとしてアプリストアに公開しようというのがアプリを作ろうという判断になった直接的な理由です。

2. モノリシックになりつつある本体リポジトリとは切り離して、素早く仮説検証したい

freeeは今や、個人事業主から上場企業の方々まで、幅広いユーザーに使って頂いています。 幅広いユーザーに価値を届けられているというのは大変誇らしい一方で、すべてのユーザーに同じインターフェースや仕様で満足していただくのは日々難しくなっているのも現実です。

たとえば前受/前払金の管理や外貨を使った取引登録・試算管理など、事業所の規模や業種によって運用もまちまちです。 これらの機能を実装するには今までfreeeにはなかったデータの概念を持ち込む必要がありますが、リリースから7年近くが経過している会計freeeのリポジトリで、データ構造を変更したりアプリケーションロジックを大きく変更しようとすると、大きなコストがかかってしまいます。

そこで、クイックに仮説検証サイクルを回してより多くのユーザーにハマるUI/UX・仕様を探る手段としても、本体のプロダクトとは完全に疎にアプリを作るのは合理性があるという判断になりました。

何故Firebaseを選択したか

社内のプロダクトは基本的にAWS上で作られていますが、今回スモール業務アプリをクイックに作成する上で「freee本体とは疎に作る」という前提があったため、技術選定に制約がない中、Firebase/GCPの利用を選択しました。

その最も大きな理由としては、Webアプリ構築コストの低さと認証機能の充実度にあります。

Webアプリ構築コストの低さ

FirebaseでのWebアプリはサーバーレスで低コストで構築できます。(下記構成図参照)

Firebaseアプリの構成図
Firebaseアプリの構成

それぞれの構成要素をかんたんに解説すると、

  • Hosting・・・静的ファイル(HTML, Javascript, CSS)をデプロイ・ホストできる。カスタムドメインの設定も可能
  • Cloud Functions・・・サーバーレスで動作するfunction(今回はnode.jsで書きました)
  • Cloud Firestore・・・NoSQLのデータベース(ネストできるKVSのイメージ)。DynamoDBなど他のNoSQL DBと同じように、やはり多少の慣れは必要
  • Cloud Storage・・・高耐久性、高可用性のオブジェクトストレージ

FirebaseのSDKやリファレンスはかなり充実しているのでこれらの構成要素の繋ぎこみやデプロイもローコストで実現できました。

サーバーを立ててミドルウェアの設定を書いてネットワークの設定をして・・・という従来私が経験していたフルスクラッチのWebアプリ開発と比較して、かなりコストが低くなったのを感じました。

充実した認証機能

Firebaseの特徴の一つとして、認証機能が充実している点が挙げられます。

Firebaseでデフォルトで提供されているログインプロバイダのスクリーンショット。各種サービス名が並んでいる
Firebaseでデフォルトで提供されているログインプロバイダ

その中でも今回は、「カスタム認証」という、Firebaseの認証サーバーをから特定のタイミングでログイン用のトークンを発行できる機能を使いました。

freeeでは現時点ではOpenId Connectのような認証基盤を持っていないため、freeeと疎にアプリを作ろうとすると、通常アプリ用のID/Passwordを持つか何か他のログインプロバイダを利用する必要があります。

ただこのカスタム認証を使えば、アプリの見かけ上、「freeeアカウントを使ってアプリにログイン」という動きを実現することができます。

「カスタム認証」を用いた認証の流れの図。freeeのログイン画面→API認可画面→アプリの画面という流れになる
「カスタム認証」を用いた認証の流れ

この認証の仕組みをざっくりと解説すると、以下のようになります。

  1. アプリにやってきたユーザーが未ログインなら、freeeの認可画面にリダイレクトさせる
  2. 認可後、freeeのアクセストークンの取得が確認できたら、認証用のCloud FunctionsのURLにリダイレクトさせる
  3. Cloud FunctionsでFirebaseのカスタムトークンを取得し、そのトークンが有効であればログイン中のセッションとみなす

かんたんに図にまとめてみました。

カスタム認証のフローの図
カスタム認証のフロー

このカスタム認証を利用するために、ユーザーはわざわざアプリ用のID/Passwordを準備しなくても済むようになり、アプリ側でもログイン情報の管理が不要になります。

カスタム認証に関しては、LINEなどを例にしたサンプルコードも公開されているので、大いに参考になりました。

運用の課題

credentialな情報はFirebase上でどう管理するか?

freee APIを利用しているアプリの特性上、freeeのAPIをコールする上でアクセストークン、リフレッシュトークンの利用が必須です。

これらの情報はアプリ上で永続化しておかないと、APIコールのたびにユーザーに認可してもらわないといけなくなってしまいます。とはいえ、アクセストークン、リフレッシュトークンをそのままFirebaseに保存しておくわけにはいかないので、暗号化には少し工夫が必要でした。

多くのアクセス数があまり想定されないアプリであれば、 Cloud KMS(Key Management Service)を使って暗号鍵の管理をするという手段もありますが、$0.03/10,000 オペレーションという従量課金制を見て少し足がすくみ、他の手段を考えることにしました。

Cloud KMSの料金表。鍵使用オペレーション(暗号化/復号)は$0.03/10,000 オペレーション
Cloud KMSの料金

Cloud KMSの代替案

今回採用した手段は、このようなものです。

  • 暗号化・復号化の鍵をCloud Storageに保管し、そのStorageには特定のCloud Functionsしかアクセスできないようにする
  • 暗号化のkeyはGoogle Cloud Scheduler(≒定期実行できるCloud Functions)で定期的にKey Rotateする

セキュアな情報をCloud Strageに保存する場合の取り扱いの図
セキュアな情報の取り扱い

このあたりのロジックは、後述するサンプルアプリのリポジトリにも反映させているので、興味があれば参考にしてみてください。

GCPプロジェクトではユーザーに対してもCloud Functionsなどの機能に対してもService Accountという役割を紐付けて特定の権限を付与したり外したりできるので、そのへんをうまくコントロールしていくのがポイントになります。

デプロイの運用

FirebaseのCLIはかなり充実していて、ログインからプロジェクトの作成・選択、デプロイまでワンコマンドで実行可能です。

特にデプロイに関してはhostingとCloud Functionsを同時にデプロイできるなど、projectの構成要素を「1アプリ」としてまとめて本番にアップロードすることができるので、開発をしていくうえではとても便利です。

一方で、本番環境のアプリも誰でも手元のCLIからデプロイができてしまう状況を作ってしまうのはリスキーなので、CIからしかデプロイができないようにするといった仕組み作りが必要になります。

firebase SDK for freeeとサンプルアプリを作りました

後日正式なリリース告知がありますが、firebase SDK for freeeとそのSDKを使ったサンプルアプリをβ版としてリリースしました。

github.com

github.com

Firebase SDK for freeeにはカスタム認証を用いたログイン実装やfreee APIをコールするwrapperが含まれており、そのロジックを用いてサンプルアプリを実装しています。 Firebaseやfreee APIに興味がある方がいれば、是非使ってみてください。

明日はバリバリの攻撃者の発想でfreeeのセキュリティを守っている @liva さんによる脆弱性診断と管理の話です。お楽しみに!

障害訓練、これ見てやってみよう

こんにちは。freee で CISO 兼 CIO をやっている土佐と申します。 この記事は freee Developers Advent Calendar 2019 の20日目です。

みなさん、障害訓練てやってますか?

やんなきゃいけないとは思いつつ、なかなか腰が重くなる仕事ですよね?

わかります。

当社では、今年の10月に大規模な障害訓練を実施し、非常に多くの学びがあり、継続的にやっていこうと意識が高まっております。

この記事では、訓練の企画から実施までを円滑に実施するために、ある程度フレーム化したものを紹介したいと思います。障害訓練の参考になればと思います。

なお、これは陸上自衛隊出身で当社のCSIRTマネージャーを勤めている 粟津さんの知見がふんだんに盛り込まれています。彼がいてくれて本当によかったと心から思います。

まずは重い腰をあげる

専任の担当者がアサインされてでもしていない限り、片手間での対応にならざるを得ないのが障害訓練です。日々忙しいなか、どうしても腰が重くなってしまいますよね。これをエイっと、みんなの「よしやるか!」を引き起こすための何かが必要になってきます。

汎用的な手段ではないかもしれませんが、当社では標語を作りました。

「あの日を忘れない。10月は障害訓練月間」

あの日とは、去年の10月31日にやらかしてしまった 大障害です。ちょうど去年のアドベントカレンダーで弊社の平栗がお詫びと学びを共有させていただいています。

この障害は当社にとって本当に大きなもので、これ以降、様々な危機管理対策、品質向上対策を行ってきました。それは色々全社を巻き込んだものであるため、全社員の危機意識も向上できていると思います。

関東大震災が発生した 9月1日を防災の日としたことに倣い、10月を障害訓練月間とすることで、あの障害で高まった意識を風化させることを防ぎ、また全社で取り組むべきイベントという意識づけを狙いました。

このようなポスターも、社内の各フロアの扉に貼って、オンラインだけでなくオフラインでも啓蒙に繋がるような取り組みにしました。

「10月は障害訓練月間」と書かれたポスター。背景は日経コンピュータにfreeeで発生した障害が掲載されたときのページの写真
障害訓練月間ポスター

ちなみに、この背景画像になっているのが、日経コンピュータの「動かないコンピュータ」シリーズに掲載された、あの障害の記事のページです。このシリーズに載ったことも、当社にとって非常に大きなインパクトになりました。

まずテーマを決める

さてまずはテーマを決めないといけません。障害対応に関係することが多い各チームのキーマンを招集し、定例会の日程を抑え、テーマの議論に入りました。

テーマは、「障害訓練を実施することで ◯◯ ができることが確認できる」というような形で検討します。

当社が具体的にどういうテーマでやったかを記載するのは差し控えさせていただきますが、例えば、以下のような感じです。

  • XXXのパターンの障害発生時にノーダウンで縮退運用に移行できることを確認する
  • いつも障害対応をするメンバーがいなくても、障害時の顧客コミュニケーションができる(属人化されていない運用が確立していること)を確認する
  • 内部不正の発生を迅速に特定して、顧客・メディアへの消火対応を行えることを確認する

訓練概要と参加メンバーを決める

テーマが決まったあとは、訓練概要を決めます。

  • どういう原因で、どういう事象が発生するのか
  • どういう影響範囲を想定した事象なのか
  • どこまでの対応を訓練の中でやるのか

訓練概要が決まれば、実際に訓練に参加してもらうメンバーを確定します。

日程を決め、予定を押さえる

メンバーが固まったらとっととメンバーの予定を押さえます。ある程度長時間になるので、早めに押さえておくといいですね。また会議室も早めにおさえておけるといいでしょう。

よりリアリティを求めて、予定を確保せずに抜き打ちでやる手もありますが、訓練を回す難易度がかなり上がってしまうので、やはり予定を確保しておいたほうがいいと思います。「抜き打ちに耐えられる」をテーマにするのであれば別ですが。

また訓練実施日だけでなく、振り返りの会議の日程もおさえてしまいましょう。

準拠したいガイドライン・マニュアルを決める

実際に事象が発生した時の対応として、どういう行動を取るべきかが記載されたガイドラインやマニュアル、手順書のドキュメントについて確認をしましょう。

これによって、訓練時の行動に対して評価ができますし、訓練とそれまでの準備を通してドキュメントの有効性についても確認できます。

準拠すべきドキュメントが存在していない場合は、訓練実施までにそれを準備することをタスクに組み込みましょう。さらにそのドキュメントが一定程度有効かを机上演習で事前に確認しておけると、とてもいいと思います。

参加メンバーの役割分担を決める

参加メンバーは「統制する側」と「参加する側」に分かれます。

統制する側は訓練をコントロールする役割です。参加する側は、訓練を受ける側ですね。

中途半端にどちらにも所属するようなメンバーを作るべきではありません。きっちり分けるようにしましょう。普段、障害対応に参加することが多いとか、障害対応運用を構築することが多い立場のメンバーが統制する側に立つのが良いと思います。

統制する側には、以下の役割が必要です。

  • 統制統括役

    • 訓練フェーズへの遷移を決めて新しい状況を訓練に与える
    • 参加メンバーの行動を俯瞰できる環境にいる
    • 訓練そのものに対する問い合わせに対応する
    • 訓練が思うように進まない場合にフォローをする
  • 仕掛け人役

    • 仮の相手を演じる。
    • 内部不正を行う人、メディア記者、官公庁担当者、顧客担当などなど
  • 記録役

    • 参加メンバーの行動をメモっていく
    • 教訓となりそうなこと、準拠すべきドキュメントから逸脱した行動などは、積極的に記録していく
    • 随時写真や動画などを撮っておくことも振り返りに役立つ

シナリオを決める

時系列に沿って、どういう事象が発生するのか、それに対してどういう対応を期待するのか、次のシナリオに遷移するのに何が必要か、統制側からフォローする範囲は何かを決めます。 下記のように、「タイムボックス」に時系列ごとのシナリオを記載しました。

  • 状況
    • 11:00~12:00
    • メディア記者から情報漏洩の速報を15:00に配信するという連絡が届く
  • シナリオ
    • PR担当の XX宛に電話で、情報漏洩のタレコミがあり、それを受けて速報を15:00に配信するという連絡がくる
    • PR担当はセキュリティ担当にエスカレーションし、そこからさらに経営陣へのエスカレーションが行われる
    • 参加チームは速報が出るまでに取るべき対応をとる
  • 訓練側に期待すること
    • [ ] 記者からの連絡を正確にセキュリティ担当にエスカレーション
    • [ ]セキュリティ担当から迅速に経営陣へエスカレーション
    • [ ] 記者に具体的な情報を引き出す交渉を行う
    • [ ] 従業員向けに社外からの問い合わせへの回答方針をアナウンスする
    • [ ] 関連事象の社内調査を実施する
  • 遷移条件
    • 上記が全て満たされる
    • あるいは12時になってしまう
  • 統裁側の統制
    • セキュリティ担当へのエスカレーションまではもし実施されない場合にはフォローを行う

なお、訓練であることをしっかり見分けられる統制は必要です。

例えば、本番のインシデントを共有するの同じチャネルでインシデント情報を共有する場合は、文頭に 【訓練】 とつける、など。また、この記号をつける統制について、訓練実施前日などに共有しておくことも大事です

また、事象が発生したことを表現できる素材は、可能な限りリアルに用意しておくと、よりリアリティのある訓練ができて効果的です。例えば、SNS上で炎上しているツイートのスクリーンショットとか、メディア記事サイト、漏洩した顧客情報のスクリーンショット、実際に不正操作をしたログ、などなどです。

訓練の実施

全ての準備が整ったらいよいよ訓練の実施です。

訓練を実施している最中にどうしても起こってしまうのは、「どこまでが与えられた状況で、どこからはリアリティ持って対応をしないといけないこと?」と参加メンバーが戸惑ってしまう状況です。これに迅速に回答できるように、統制側は緻密にシナリオを組んでおくべきですし、訓練最中の問い合わせに回答できるように準備しておくべきです。準備できていない点について問い合わせを受けたら、慌てずに統制サイドで迅速に議論し、その場その場で方針を決めていきましょう。

振り返り

振り返りまでちゃんとやることはとても大事です。 やってみて得られる気づきは必ずあるものです。またそこからTODOも発生すると思います。そのTODOをきちんと実行できるようにフォローしていきましょう。

実際に freee でやってみてどうだったか

まずは、「やれてよかった」「やってよかった」という感想が一番強いです。やってみて、色々な気づきが得られて、参加チームが自発的に「おかわり訓練」をやってくれるなどの動きも見られました。また、思った以上に経営陣含め、社員が積極的に関わってくれて、会社のチームとしての強さを感じることもできました。また、この手の「やばい感じのお祭り」が好きなメンバーというのは一定数いるもので、そのことと、それが誰かなのかがよくわかったのも面白かったです。トップダウンでやるよりも、そういうメンバーを負担かけすぎない程度にうまく巻き込んでいくことで、ムーブメントっぽく進めることができると思っています。

一方で準備不足、運営の未熟さを感じる場面も多かったので、その辺りはよく学んで次回に生かしていきたいと思います。

WANTED!

freeeでは freee の危機管理能力を爆上げしてくれる次世代CISOを積極募集中です!

jobs.jobvite.com

明日は?

明日は freee でもっとも尖った、活きのいい若手エンジニア kotegawa くんの出番です!お楽しみに!

freeeが関西で開発組織を立ち上げてから1年半が経ちました。

こんにちは、freee OSAKAで開発部長をしている 竹田 です。この記事は freee Developers Advent Calendar 2019 の 20日目の記事です。

去年は freeeが関西で開発組織を立ち上げた理由 という記事でエモい話を存分にしたので、今回はより具体的に前回の記事から1年が経ったいま 「どういうメンバー」で「どういう環境」で「どういう開発をしているのか」を書きたいと思います。 関西でも楽しみながら最先端のwebサービスを開発できるよ!ということが伝われば幸いです。

freee OSAKAとは

改めて紹介。freeeは2018年4月に大阪に開発組織(=freee OSAKA)を立ち上げました。 オフィスは大阪のグランフロント大阪にあります。私は1人目のエンジニア兼エンジニアリングマネージャー兼プロダクトマネージャーとして、組織とプロダクトの両面からfreee OSAKAを進化させていくという役割で働いています。

freee OSAKA専用のTシャツもあります(3種類)

freee OSAKAオリジナルTシャツ
freee OSAKAオリジナルTシャツ

freee OSAKAの方針

freee OSAKAでは立ち上げ当初から以下のような方針を掲げています。この方針は1年半がたった今でも変わらず貫き通しています。


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

メンバー構成

1年前は5名だった組織も今では13名までスケールしました。 また闇雲に人を増やすのではなく、プロダクトをゼロから開発できる構成にするために 「プロダクトマネージャー、スクラムマスター、エンジニアリングマネージャー、UXリサーチャー、UXデザイナー、エンジニア、QA(Quality Assurance)、SRE(見習い) 」と幅広くwebサービスを開発するために必要な人材が集まっています。規模感としては小さなベンチャーのような感じで、それぞれの得意な部分を融合させながら全員で顔を突き合わせて開発を進めています。

作っているプロダクト

freee OSAKAでは主に2つのプロダクトを担当しています。

  • 人事労務freee の一つの領域を開発
  • 完全に新規のプロダクトをまるっと開発

1つ目の既存プロダクトについては、freee OSAKAの小回りの効く体制を活かしてスピード感を重視して開発を行っており、この1年半で大小含め30以上の機能リリースを行っています。

2つ目の新規のプロダクトについては、ゼロから全ての開発をfreee OSAKAで行っています。freeeの既存のプロダクトは既に多くのお客様にご利用いただいておりますが、そこに続く完全に新しいプロダクトを開発しています。開発プロセスからアーキテクチャまで全てを自分たちで考え、試行錯誤しながら実行しています。

開発する環境や設備

これはfreeeの全エンジニアが同じ待遇で、PC、椅子、モニタ、書籍など、開発メンバーの仕事の効率や楽しさを向上させるための環境が用意されます。freee OSAKAに関しても勿論同じ条件で、開発を行っている中で環境によるストレスを感じる場面は非常に少ないです。

こんな感じで4Kモニタを利用したモブプロもよくやっています。

4kモニタでモブプロ
4kモニタでモブプロ

あとはキーボードが割れている人もいます。

f:id:yt-yt:20191220082406j:plain
キーボードが割れている様子

リモートワークも盛んで、ハングアウトを使って4箇所を繋いで朝会を実施することも。

1歳のお子様が全員の進捗を確認する様子
1歳のお子様が全員の進捗を確認する様子(右下の人は遅れてそうですね)

開発プロセス

freee OSAKAでは、しっかりとしたスクラムで開発しています。
これに関してはちょうど昨日、スクラムマスターをしているリョウくんが分かりやすい記事を書いてくれたので、そちらの記事をご覧ください。 彼は新卒入社ですが、スクラムマスターとして非常にバランス良くメンバーを導いてくれており、開発メンバーに加えて、営業やカスタマーサクセスなどビジネスサイドのメンバーも含めて、本気でスクラムを実行しています。

developers.freee.co.jp

また、大きな開発の前にはキックオフとしてメンバーの一人が副業で経営している古民家を改装した宿 オオミシマスペース で合宿を行います。

海沿いにある素敵な宿です

オオミシマスペース
オオミシマスペース

全員で顔を突き合わせて仕様やアーキテクチャを決めます

f:id:yt-yt:20191219215325j:plain

全員で顔を突き合わせて仕様やアーキテクチャを決めます

真面目に働いている様子
真面目に働いている様子

肉です 肉です

魚です 魚です

かわいい奴もいます 犬です

勉強会への参加や登壇

freee OSAKAではメンバーが社内外の勉強会にどんどん参加し、どんどん情報発信することを応援しています。

たとえば 大阪で一番大きなgoのコミュニティ umeda.go の主催メンバーがいたり umedago.connpass.com

アクセシビリティの祭典という日本最大のアクセシビリティのイベントで登壇したり accfes.com

サンディエゴで行われたGopherCon 2019 に参加したり developers.freee.co.jp

活発に活動しています。この他にもいくつものイベントで登壇していますので見かけたら気軽に声をかけてみてください。
またこれまではオフィスの関係で勉強会を主催するスペースがなかったのですが、来年は更に広いスペースを確保する予定です! そこで勉強会の主催、勉強会の会場提供(50名以上いけます)などガンガン行っていく予定ですので是非楽しみにしておいてください。
場所もこれぞ大阪という感じの非常に面白く意外な場所です!お楽しみに!

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

最後に1年前の記事からの繰り返しになりますが、freeeが関西に開発組織を立ち上げた理由は「関西のエンジニア市場を盛り上げて変えていきたい」からです。
freeeでは、働いている人々の効率を上げ、本質的な活動にフォーカスできるようにしたいという考えで様々なプロダクトを提供しています。 組織作りにおいてもその信念を忘れずに、これからもエンジニアがどこでも活き活きと楽しみながら働ける場所を作っていければと考えています。

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

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

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

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

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