エンジニア向け社内勉強会「真剣.js」を開催しました

こんにちは。freee でフロントエンドエンジニアをやっている id:ymrl です。先日、エンジニアによるエンジニアのための社内勉強会「真剣.js」が開催されたので、その様子をご紹介します。

真剣.js とは

jsと名前についていますがJavaScriptとはあんまり関係がなく、「話を真剣に聞く」ための有志によるfreee社内のLT大会です。freeeでは何故か名前に .js のつく JavaScript に関係のないイベントがいくつかあります。元々は給料日に寿司を食べに行くのを「寿司.js」と呼びだしたのがきっかけだったとか。

今回の真剣.jsは業務が一段落してくる19時から社内のカフェスペースで開催されました。今回の発表者は全員がエンジニアでしたが、聴衆にはなかにはエンジニアではない社員の姿もちらほらとありました。

「祝日と休日」 id:ymrl

給与計算 freeeのような、祝日や休日の情報を保持する必要のあるシステムを開発するときに、それらをどう管理するべきなのかという悩みを発表しました。

祝日と休日 // Speaker Deck

「2017年代の進捗どうですか」 id:joe-re

「PivotalのWorkspaceの画像を毎朝Slackに貼ることで進捗を共有しよう、せっかくならAWS LambdaでServerlessな感じでやろう」と思ったものの、結局EC2インスタンスを立てました、という発表でした。

2017年代の進捗どうですか/sintyoku_doudesuka_in_the_2017 // Speaker Deck

今回はLambdaを諦めてEC2を使用しましたが、実際のfreeeのサービスではいくつかの場所ではLambdaも使用しています。

「取引ネットワーク分析の現場から」 @teppei_tosa

先日リリースされた取引ネットワーク推測機能を作る上で、どんなグラフ分析処理をしたのかという内容を、実際にApache Spark GraphXのコードをデモしながら発表しました。

この機能、実は「巨匠システム」で開発されたもので、これはエンジニアの投票で選ばれた「巨匠」が1ヶ月間で「サービスや会社に『非連続な成長』をもたらす施策」に自由に取り組めるという制度です。

巨匠システムについては以下の記事もごらんください。

「悔いる」 @kakkunpakkun

freeeではベテランになってしまったエンジニアによる、あの日作ってしまった不要なモジュール、クラス、テーブルたちを悔いながら消していく(Pull Requestを出していく)発表でした。

「ものすごくおそくてありえないほど遅い」「この一年での銀行の動き」 @rosylilly

フリーランスエンジニアとしてfreeeのISU(いい感じにスピードアップ)活動に参加している @rosylilly さんにも発表していただきました。Go言語でも処理内容や書き方によっては遅くなってしまうという内容の発表です。

真剣.js / shinken-js // Speaker Deck

「AWSを使った駐輪場シャッターHACKプロジェクト」id:teitei_tk

最近入社3ケ月を迎えた id:teitei_tk による発表も用意されていたのですが、残念ながら当日は出席できなかったので資料だけご紹介します。

AWS parking lot shutter hack project // Speaker Deck

freeeではビルの1階の車庫のようなスペースを自転車置き場として借りていて、しかし道路に面した出入り口のシャッターが内側からしか開けられなかったなかったため、「Slackでbotに命令すると操作盤に貼り付けられたサーボモーターでボタンを押して開けてくれる」というもの作ってを設置していました。しかし利用していたDBaaSの問題で現在は使えなくなっています(詳しくは@anzaitetsuによる記事をごらんください)。現在、これをAWSに移して構築をしようとしています。

おわりに

今回の真剣.jsは企画立案から会場の準備、当日の司会進行まで、ほぼすべてを @futoase ひとりがまかなって開催されました。freeeには業務内外含めさまざまなイベントがありますが、今回のように社員が自主的に集まって開催ということもしばしばあります。freeeの一員として楽しく働けるよう、社内でさまざまなイベントが企画されています。

freeeのエンジニアの話を聞いてみたい方、開発も社内イベント企画もやるぞという方、ぜひ人材募集ページからご応募ください

会社設立 freeeの開発を支えた3つのプラクティス

いよいよfreeeの開発チームブログが始まりました。初回を任されましたエンジニアの米川(@yonekawa)です。 記念すべき最初の記事ということで何を書こうかと考えたのですが、開設つながりで会社設立 freeeの話をしようと思います。 会社設立 freeeは「会社設立に必要な書類が5分で作成可能」なサービスで、リリースされてから現在までに3,000社以上の企業がこのサービスを利用して法人登記されています*1

順調に成長していると言える会社設立 freeeは、1年半ほど前にPM・ビジネス・UX・エンジニアの4人のチームで開発されました。 エンジニアは僕だけで、rails new してからリリースに至るまでの全てのコードを1人で書いていました。 そんな限られたリソースの中でプロジェクトを成功させるために、当時の僕たちが大事にした3つのプラクティスについて紹介します。これらのプラクティスは現在のfreeeの開発チームが大事にしている価値基準にも通じているので、freeeの開発文化についても知ってもらえると思います。

1. 神ドキュメントによるビジョンの明文化

会社設立 freeeのプロジェクトで一番最初に作られたのは、「神ドキュメント」と呼ばれるドキュメントでした。 神ドキュメントとは、会社設立 freeeの開発指針をFAQ形式でまとめたもので、以下のような内容が書かれています。

  • なぜ会社設立 freeeを作るのですか?
  • 会社設立 freeeのコンセプトを教えてください
  • 他のサービスではなく会社設立 freeeをつかう一番のメリットはなんですか?
  • 会社設立 freeeをリリースするビジネス目的を教えてください

f:id:yonekawa:20170127010542p:plain(実際の神ドキュメント)

このドキュメントが、リリースに至るまでの僕たちのすべての議論の出発点になりました。 「この機能は本当に必要か?」「神ドキュメントによると会社設立 freeeは〜〜を解決するのだから必要」のように、メンバー全員が同じ基準で価値を判断するためのツールとして機能していました。 経営陣にもこの神ドキュメントの内容はレビューを受けていたので、ビジネス面を含めた重要な意思決定も全く同じように判断できるようになっていました。

会社設立 freeeは「会社設立を圧倒的に楽にする」ことを目指して始まりましたが、プロジェクト開始時点では「圧倒的に楽って何?」という問いへの答えはまだ誰も持っていませんでした。それに対して1つのビジョンを示したのが神ドキュメントです。新しいサービスやビジネスでは意思決定や判断に迷うことが山ほどありますが、その時にメンバーの拠り所となり道標になるビジョンを明文化するのはとても重要だと学びました。

2. 課題を深く理解する

会社を設立をするときに何が必要か、どのような手続きがあるか知っていますか? 僕はこのサービスを開発するまで全く知りませんでした。 やはり実際の会社設立の手続きや法律を知らずに、ユーザーの課題の本質を捉えて仮説を立てることは難しいです。 特に会社設立 freeeは異なる役割のメンバーが集まったプロジェクトなので、効率的に議論を進めるにはそれぞれのメンバーの前提知識の差を埋める必要があります。

僕たちはプロジェクトのはじめに、会社設立の本を4冊買ってメンバーで毎日読み合わせました。同じ本を読むことで基準になる前提知識を揃える狙いがあり、メンバー全員がやろうと思えば自分で会社を設立できるようになるまで読み込みました。実際、いま会社設立 freeeが出力できる書類は最初に自分たちで手作業で作ったものが元になっています。

f:id:yonekawa:20170127010558p:plain(自分たちで作成した申請書類)

しかし会社設立の本は、細かいことは考えずにこうしろと書いてあることも多く、多くのユーザーにとって簡単なフローを実現するためには厳密な要件を知っておく必要があります。そのため開発中は、手続き上の不明点を専門家の方に直接質問できるホットラインを作っていました。これにより各手続き要件の裏にある背景や理由まで踏み込んで理解することができました。

会社設立の手続きや仕組みを深く理解することで、その手続きを簡単にするためのアイデアの妥当性を判断できるようになります。 「法務局には管轄があるから住所から管轄を検索して提示しよう」「公証役場に管轄は無いから近いところをサジェストしよう」のような検討もスムーズです。 「書類の提出などで外出することが多いのでスマートフォンに対応するのは必須だと思う」という主張も、メンバーの前提知識が揃っていることで実現しやすくなりました。 ユーザーの課題を解決するためのアイデアは思いつきだけではダメで、課題を知り、本質に向き合うことが重要だと改めて感じました。

3. デモドリブン

会社設立 freeeの開発は、今振り返ると異常な回数のデモの積み重ねによって進んだプロジェクトでした。 最も短い頻度で行われたデモはデイリーデモで、毎日のチームミーティング内に開発の進捗をデモする時間が設けられていました。 それに加えて2週間で区切られたスプリントのレビューにおいても、CEOやCOOに向けての進捗のデモがありました。 社内外の起業に関心がある人や起業を考えている人に、何も言わずに今動いている画面を見せて「さぁどうぞ」と丸投げしたこともあります。

ここまでデモにこだわったのは、会社設立 freeeが手続きを本当に簡単にするサービスを目指したからです。 神ドキュメントがあり、会社設立の手続きを勉強して詳しくなっても、実際にいま考えているアプローチが本当に簡単なのかは確証がありません。 考えたアイデアの妥当性を検証するには、たくさんのフィードバックを受ける必要がありました。 そのために、開発を進めればデモをするしかないプロセスと場を作り、未完成なサービスが人の目に触れる回数をとにかく増やす仕組みを考えました。

チームにとっても、日に日に機能が出来上がっていく様子を見る時間はテンションをあげる効果があります。そのため出来る限り目に見える機能をきちんと動く状態でデモすることを優先していました。この積み重ねがあり、スプリントの度に正しく動作が見せられる状態を維持したことで、リリース時の品質を高めることに繋がりました。

まとめ

ユーザー課題の解決を目指したサービスでは、課題へのアプローチを試行錯誤するための環境を作ることが不可欠です。会社設立 freeeでは今回紹介したプラクティス以外にも、さまざまな工夫によってこの環境を作ろうとしていました。

もちろん振り返って改善できるポイントはたくさんあります。 例えばデイリーのデモは、当然ですがバックエンドの実装に着手していると見せられるものがなく実施できません。今回は問題がなかったのですが、裏側の技術やアーキテクチャ上の問題が発生していたらもっとリズムは悪くなっていたと思います。 一方でそういった状況が起きた時にもチームとして柔軟に変化できることが重要で、それも含めて試行錯誤のサイクルを回すのがいい進め方だと思っています。

freeeのプロダクトづくりや開発プロセスは日々改善を繰り返しながら成長しています。このブログでは技術的な話題はもちろん、こういったプロダクト開発への取り組みについても紹介していきます。みなさんのユーザーの課題を解決する参考になれば幸いです。

freeeではユーザーの課題に向き合って試行錯誤をするのが大好きなエンジニアを募集しています。 興味のある方はぜひご応募ください。

f:id:yonekawa:20150416163937j:plain(デイリーのミーティング風景)

*1:2017年1月時点