読者です 読者をやめる 読者になる 読者になる

会計ソフトを作る上で避けては通れない和暦の話

エンジニアの大橋 @_tohashi です。会計freeeで確定申告や記帳機能などの開発を担当しています。

Webに限らず、日本向けのアプリケーションにおける特有の要素として和暦があります。プロダクトによっては最初から和暦を扱わずに西暦に統一してしまうという手もありますが、弊社のプロダクトのように会計や労務管理に関わるものの場合、決算書上の表記など和暦が必要とされる場面は多々あるため避けて通ることはできません。本記事ではUIや実装における和暦の扱いについてご紹介したいと思います。

f:id:t930:20170321155846j:plain

和暦の範囲

そもそも「和暦」とはどこからどこまでの期間を指すのでしょうか。Wikipediaによれば

和暦(われき)は、元号とそれに続く年数によって年を表現する、日本独自の紀年法である。邦暦(ほうれき)とも。また「和暦」は、西暦に対する表現としても使用されることが多い。 この手法自体は東アジアで広く行われてきたが、日本独自の元号を用いているため日本固有の紀年法となる。飛鳥時代の孝徳天皇によって西暦645年に制定された「大化」がその始まりであり、以来15世紀に亘って使われ続けてきている。 たとえば、西暦2000年は平成12年に当たる。明治改暦(明治6年/西暦1873年)以降、グレゴリオ暦を採用しており西暦とも月日が一致している。

とかなり広い期間が和暦とされています。

一方、日時の国際標準規格である ISO 8601 の日本独自の拡張である JIS X 0301 では、グレゴリオ暦に改暦された明治6年1月1日以降を規格の適用範囲内としています。

実際に利用する範囲から考えてみると、例えば弊社のプロダクトで日付入力が発生する箇所としては

  • 取引の発生日
  • 従業員の誕生日
  • 会計期間の設定
  • 固定資産の取得日

などがありますが、固定資産の耐用年数は最長でも水道用ダムの80年、公式に認定されている寿命の最長記録は122歳です。この場合システム上における「和暦」は、2017年現在においては JIS X 0301 の通り明治6年1月1日以降を考慮しておけば問題ないと言えるでしょう。

UI

日付選択UIにおける和暦の扱いとしては例えば下記のようなものが挙げられます。

元号選択

f:id:t930:20170321140018g:plain

和暦をユーザーに選択させる方法です。直感的ではありますが、入力したい年が西暦でしかわからない場合は調べる必要があります。実装面では「昭和100年」といったケースのバリデーションや、DBにDate型のカラムとして保存するのであればどこかでキャストするといった事が必要になります。

西暦と併記

f:id:t930:20170321140032g:plain

西暦と和暦を併記する方法です。西暦・和暦の片方しかわからなくても入力可能ですが、セレクトボックスが縦に長くなりがちという欠点もあります。

DatePicker

f:id:t930:20170321140034g:plain

JavaScriptによる実装もありますが、画像は Google Chrome において input type="date" を使用したもの1です。前後1年間ぐらいの日付を選択するのには便利ですが、生年月日のように数十年遡るような場合はあまり向いているとは言えないでしょう。

自由入力

f:id:t930:20170321140036g:plain

西暦・和暦どちらも入力可能にしておき、適宜パースして扱う方法です。扱うフォーマットの数によっては実装コストがそれなりに大きくなるでしょう。

いずれもメリット・デメリットがあるので、日付の用途に応じて最適なUIを選択していくのが大事ですね。

実装

続いて実装面における和暦の扱いを言語ごとに見ていきます。

Ruby

Ruby の Date クラスには JIS X 0301 書式の日付を返す jisx0301 というメソッドが用意されているため、このように簡単に和暦を得ることができます。

require('date')
Date.new(2017, 3, 15).jisx0301 # => "H29.03.15"

境界値も問題ありません。

Date.new(1989, 1, 7).jisx0301 # => "S64.01.07"
Date.new(1989, 1, 8).jisx0301 # => "H01.01.08"

上述したように明治6年以前は JIS X 0301 の対象外であるため、そのまま西暦(ISO 8601 拡張形式)が返ります。

Date.new(1873, 1, 1).jisx0301 # => "M06.01.01"
Date.new(1872, 12, 31).jisx0301 # => "1872-12-31"

逆に和暦をパースすることも可能です。

Date.parse('H29.01.01') # => #<Date: 2017-01-01 ((2457755j,0s,0n),+0s,2299161j)>
Date.parse('S50.01.01') # => #<Date: 1975-01-01 ((2442414j,0s,0n),+0s,2299161j)>

JIS X 0301 の範囲外でもパースできますが、グレゴリオ暦と太陽太陰暦のずれが考慮されていない点は留意が必要でしょう。

Date.parse('M5.12.31') # => #<Date: 1872-12-31 ((2405159j,0s,0n),+0s,2299161j)>
Date.parse('M1.01.01') # => #<Date: 1868-01-01 ((2403333j,0s,0n),+0s,2299161j)>

ちなみにこのような日付もパース可能です。

Date.parse('M50.01.01') # => #<Date: 1917-01-01 ((2421230j,0s,0n),+0s,2299161j)>

Java

locale を ja_JP_JP に設定することで和暦への対応が可能となります。

import java.util.*;
import java.text.*;

public class Wareki {
    public static void main () {
      Locale locale = new Locale("ja", "JP", "JP");
      Calendar calendar = Calendar.getInstance();
      DateFormat dateFormat = new SimpleDateFormat("Gyy.MM.dd", locale);

      // 西暦から和暦へ
      calendar.set(2017, 2, 20);
      dateFormat.format(calendar.getTime()); // H29.03.20

      calendar.set(1989, 0, 7);
      dateFormat.format(calendar.getTime()); // S64.01.07

      calendar.set(1989, 0, 8);
      dateFormat.format(calendar.getTime()); // H01.01.08

      calendar.set(1872, 11, 31);
      dateFormat.format(calendar.getTime()); // M05.12.31

      // 和暦から西暦へ
      dateFormat.parse("H29.01.01"); // Sun Jan 01 00:00:00 JST 2017
      dateFormat.parse("M6.01.01");  // Wed Jan 01 00:00:00 JST 1873
      dateFormat.parse("M1.01.01");  // Wed Jan 01 00:00:00 JST 1868
    }
}

Ruby と異なり明治6年以前もそのまま和暦に変換されるため、厳密には JIS X 0301 に準拠していないとも言えます。

その他

他にも Swiftなでしこなどが和暦に対応しているようですが、多くのプログラミング言語はそうではないため、ライブラリを使うか自前で変換ロジックを用意する必要があります。

例えば JavaScript では日付を扱うライブラリとして Moment.js が有名ですが、残念ながら和暦には対応していないようです。以下は西暦を和暦に変換する拙作のライブラリ wareki を基にした実装の一例です。

const eraDataList = [
  {
    code: 'H',
    firstDate: '1989-01-08',
  },
  {
    code: 'S',
    firstDate: '1926-12-25',
  },
  {
    code: 'T',
    firstDate: '1912-07-30',
  },
  {
    code: 'M',
    firstDate: '1873-01-01'
  }
];

function fillZero(value) {
  return `0${value}`.slice(-2);
}

function toWareki(value = Date.now()) {
  const dateObj = new Date(value);
  const year = dateObj.getFullYear();
  const month = dateObj.getMonth() + 1;
  const date = dateObj.getDate();
  let wareki = value;

  for (let i = 0; i < eraDataList.length; i++) {
    let eraData = eraDataList[i];
    let eraFirstDateObj = new Date(eraData.firstDate);
    if (dateObj - eraFirstDateObj >= 0) {
      let eraYear = year - eraFirstDateObj.getFullYear() + 1;
      wareki = `${eraData.code}${fillZero(eraYear)}.${fillZero(month)}.${fillZero(date)}`;
      break;
    }
  }
  return wareki;
}

toWareki('1989-01-01');
// => "S64.01.01"

新元号について

現在、天皇陛下の譲位に伴い平成31年元日より新元号となることが検討されています。当然 JIS X 0301 においてはまだ未定義のため、現時点では未来の日時は全て平成として扱いつつ、新元号の制定に伴うアップデートの準備をしておくのが良さそうです。

さいごに

日付を扱う上で和暦の対応は面倒なところもありますが、本記事が一助となれば幸いです。

ちなみに僕は昭和64年生まれなのですが、たまにこういう悲しい目に合います。

f:id:t930:20170321140039p:plain

freeeでは和暦にこだわりのあるエンジニアを募集しています!


  1. 一部ブラウザでは未対応

サービスをつくるエンジニアが機械学習を学ぶべき3つの理由

こんにちは。freee 共同創業者 CTO の横路です。

freeeは現在、「スモールビジネスに携わるすべての人が創造的な活動にフォーカスできるよう」というミッションのもと、テクノロジーによる中小ビジネスのバックオフィス効率化とデータドリブンな経営意思決定支援を実現すべく、スモールビジネスAIラボチームを立ち上げて活動しています。

その中で、サービス・プロダクトづくりをリードし顧客に価値を届けてきたソフトウェアエンジニアこそ機械学習を学び、顧客の課題解決のいちオプションとして身につけはじめるべきだという実感を得たので、エンジニアリング対象としての機械学習について紹介します。

サービスをつくるエンジニアが機械学習を学ぶべき3つの理由

サービス開発で顧客に価値を届けるソフトウェアエンジニアこそが機械学習を学ぶべきだと思う理由は、以下の3つです。

  • サービスが対象としているトピックについて 深いドメイン知識を持っている
  • サービスを開発して実運用できる 高い技術スキルを持っている
  • 機械学習エンジニアリングに関する ツールやノウハウが民主化してきている

機械学習を活用したプロダクトづくりで重要なのは、データそのものと、鋭い課題設定・特徴選択・実装・モニタリング・解釈のイテレーションです。そして、そこで必要になるのが、深いドメイン知識と実運用システムをつくるための技術スキル、最低限の機械学習エンジニアリングの知識です。

極端なことを言えば、これまでサービス開発でドメイン知識や技術スキルを得てきたエンジニアであれば、アルゴリズムの深い知識がなくてもデータドリブンなプロダクト開発をスモールスタートできる状況になっています。機械学習エンジニアリングのためのツールやノウハウは、それくらいにまで民主化されて手の届きやすいものになってきています。

もちろんデータアナリスト・データサイエンティスト・データエンジニアと明確に役割を分けたチームで密にやっていくという方法もあるだろうし、正確さや精度がビジネスにクリティカルに効くサービスなど、シニアなデータサイエンティストの参画が不可欠になるサービスもあると思います。しかし、サービスづくりの当事者であるエンジニア自身が「機械学習で顧客にどんな価値を届けていけるか」「シニアデータサイエンティストの手を借りるとどんな世界が実現するのか」の勘所を得るためにも、まずはじめてみることが重要だと考えています。

サービスづくりの現場においては、普段から深くドメイン知識に触れ、サービスづくりで課題を解決してきたエンジニアこそ、機械学習をつかったサービスづくりに最短でキャッチアップし、高速なローンチ&イテレートをすることができると思います。

機械学習を学ぶハードルは本当に高いのか?

実感として、機械学習エンジニアリングの全体観が見えればハードルは思ったほど高くないと思います。

ハードルが高く見える理由は3つあると思っています。

  • データがないと始められない
  • 機械学習の本や講習を受けただけでは、サービスに活かせるようにならない
  • 投資対効果が見えず、スモールスタートのしかたがわからない

データがないと始められないのは本当で、顧客の課題解決のためには、まず顧客の課題をよく理解して、それらに関するデータを集めなければなりません。逆に、先行するサービスでデータやドメイン知識の蓄積がある場合は、それだけで機械学習を検討してみる価値があると思います。

座学とサービス応用のギャップについては、これまでアルゴリズムの詳細や数式をはじめから強く意識させ、理論から理解していくタイプの入門書が多かったことも一因としてあるかと思います。それだけで挫折した人も多かったかと思いますし、Couseraの機械学習コースを受けたはいいが、次に何をやればいいのかわからないという現象もよく聞きます。

この問題や投資対効果が見えない問題については、機械学習のプロセス全体をおおまかに把握し、機械学習入門がカバーしている領域がその一部だということがわかれば、次のステップが見えてくると思います。Googleの例をはじめ、機械学習エンジニアリングのスモールスタートのやりかたなど、実践ノウハウが少しずつ共有されはじめてきたこともあり、実運用ノウハウの共有はこれからさらに活発化していくと思われます(後述しますが、freeeも発信していく予定です)。

f:id:yokoji:20170228103944p:plain

機械学習をプロダクトに活かすために、何をどう学ぶか

機械学習のプロセスをおおまかに把握したら、機械学習をプロダクトに活かすために最初に学ぶべきは、次の3ステップです。

  • 機械学習で解くべき問題を見つける
  • 基本的なアルゴリズムとツールの勘所を知る
  • データを扱うためのお作法・効果検証や投資判断の勘所を知る

一番重要なのは解くべき問題をシャープに見つけることで、そのためにはまず自分のドメイン知識がある分野に絞ってはじめてみることです。どんな領域のどんな問題に機械学習が適用されているのか?については、このページが参考になります。ほとんどの問題は機械学習でなくても解けますし、まずは簡単な経験則に基づいたルールベースの方法から始めて、シンプルなルールでうまくいくなら機械学習を使う必要はありません。

基本的なアルゴリズムとツールの勘所については、ある程度デファクトスタンダードが決まってきていて、それらを使っていくうちに精度と計算量のバランスなどがわかってくる印象です。アルゴリズム毎のインタフェースの違いはツールがうまく吸収してくれていることが多いので、アルゴリズム毎にライブラリを覚えるような手間は少ないです。

このあたりを身につける手段は、本当に充実してきていて、Pythonのモダンなツールで手を動かしながら機械学習の手法を学ぶ方法はたくさんあります。

筆者は、オンラインで対話式に手を動かして学べるDataQuestをベースに学習しつつ、Hands-On Machine Learning with Scikit-Learn and TensorFlowで足りないところを補完しました。Python機械学習プログラミング監訳者による読み方が参考になる)もとてもよかったです。

データを扱うためのお作法としては、データクリーニング・前処理・評価の習慣をつけておくことが重要です。手法はいろいろありますが、こちらも基本的にツールに含まれているので、簡単に利用することができます。データの素性を正確に把握しておくことは適切な結果を得るために非常に重要で、提供サービスの性質によっては、かなりシビアに見ていく必要があります。

効果検証については、戦略的データサイエンス入門が秀逸だと感じたのでぜひ一読をおすすめします。機械学習の性能で見るべきメトリクスを、ビジネス的な要件を踏まえた上で見る癖をつけられるようになりますし、体系的なデータリテラシーの基本が身につきます。メトリクス計測の仕組み自体は基本的にツールに含まれています。

サービスをつくるエンジニアのための機械学習勉強会を開催します

freeeでは以上の学ぶべきポイントを踏まえ、機械学習エンジニアリングの勉強会を2つ企画しています。

  1. 4月に「機械学習を活用したサービスづくり」について他社と合同勉強会をやります
  2. 社内の機械学習勉強会を、社外にも開放します

合同勉強会では、機械学習で解くべき問題をいかに見つけてどのようにプロダクトに昇華させたのか?開発プロセスやイテレーションはどうしているか?など、実際にサービスをつくり運用している各社から、実践的な内容をお伝えする予定です。

社内勉強会では、Couseraの機械学習コースの内容をベースにKaggleの演習問題を織り交ぜて、Pythonで手を動かしながらキャッチアップしています。これまでサービスづくりはバリバリこなしてきたが、機械学習にキャッチアップする時間がまだとれていないエンジニアの方に、ぜひ参加してほしいと思っています。

f:id:yokoji:20170228104141j:plain

これらの勉強会の詳細については、後日本ブログにて公開しますので、みなさまぜひご参加ください。

freeeの機械学習への取り組みはまだこれから加速していくところですが、本日プレス発表を行った金融機関向けのリアルタイム経営シグナルや、前回ブログで紹介したようなSpark GraphXを使った取引ネットワーク推測、会計向けの共通言語処理ライブラリ、会計上の処理モレ・ダブリ・ミスを自動で見つけてサポートする機能、経理処理マッチングの開発などもはじめていて、今後ブログや勉強会で具体的な取り組みや、機械学習で溜まっていく負債をどう解消していくかなど、実運用ノウハウを随時発信していく予定です。

まとめ

ハードルが高いと思われがちな機械学習ですが、サービスづくりに必要な機械学習は民主化が進み、エンジニアリングの対象になってきている実感があります。データの蓄積があるサービスに携わる、業務理解と技術力のあるソフトウェアエンジニアこそ、いま機械学習をはじめるべきではないかと思います。

機械学習の要求するエンジニアリングの癖をソフトウェア開発のベテランたちが深く理解し、(機械学習に比べたら)歴史あるソフトウェアエンジニアリングのプラクティスとうまく対比・融合させて発信・共有しあうことで、次世代のサービスづくりのプラクティスを築いていきたいですね!

最後に

freeeでは、データドリブンなサービスづくり、環境づくりを一緒にやっていくエンジニア、そして彼らと共に価値をつくりだすシニアデータサイエンティストを募集しています。セクシーなデータセットとサービスづくりのエンジニアリングのプロたちが集うfreeeで、データドリブンなプロダクト開発をリードし、一緒に日本の生産性を上げるチャレンジをしませんか?

エンジニア向け社内勉強会「真剣.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月時点