開発速度を支える技術 / The Techniques for Keeping The Development Speed

by Hiroki Nakashima

Slide 1

Slide 1 text

freee 株式会社開発速度を支える技術 2018.10.07 2018年情報科学若手の会

Slide 2

Slide 2 text

大学院理工学研究科卒業大学院では、初期の Ethereum を触ってました 2017年エンジニア新卒1期生としてfreee株式会社に入社現在は、エンジニアとして、会計フリーをメインに開発 Web フロント、Ruby on Rails のサーバサイドの開発をはじめ、Golang、 Kubernetes を使ったプロダクトのマイクロサービス化にも挑戦している。趣味は仮想通貨（概念が好き）、Pokemon Go、あと酔うけどVR Hiroki NAKASHIMA 中島啓貴 freee株式会社プロダクト開発 2

Slide 3

Slide 3 text

freeeの事業 3 01 Section

Slide 4

Slide 4 text

4 スモールビジネスを、世界の主役に。アイデアやパッションやスキルがあればだれでも、ビジネスを強くスマートに育てられるプラットフォーム 161億603万円 (資本準備金等含む) 従業員数事業内容クラウド型バックオフィスサービスの開発・販売資本金設立年月日 2012年7月 465名（2018年6月末時点）

Slide 5

Slide 5 text

5 PRODUCTS

Slide 6

Slide 6 text

6 6 会計請求書経費精算債務管理債権管理人事労務　バックオフィス業務の一番の無駄は、様々なツールに同じような情報を繰り返し入力する転記作業です。時間がかかる上、作業ミスの温床にもなっていました。　会計freeeでは請求書作成や債権債務管理など経理業務に必要な機能を標準搭載。日々の経理で入力した情報を自動で帳簿に反映し、転記作業が極力不要な体制を実現します。会計と経理を一体化転記作業を排除し、管理が簡単に 6

Slide 7

Slide 7 text

7 100万サービス開始５年で 1,000,000 事業所数累計事業所突破

Slide 8

Slide 8 text

8 市場調査からもシェア No.1 35% A社 B社その他 26% 23% ※出典：BCN　クラウド会計ソフト市場調査。n=418、webアンケート調査

Slide 9

Slide 9 text

日本全国の中小企業の膨大なデータが集約 9 100万事業所の膨大なビッグデータが、スモールビジネスの経営を強くする。

Slide 10

Slide 10 text

中小企業がクラウドで連携する未来 10 あらゆる企業と、多様な仕組みが繋がり、 freeeは、ビジネスプラットフォームへと進化経営効率化在庫管理入金管理ファクタリング取引効率化 EDI 請求ネッティング決済機会創出ビジネスマッチング

Slide 11

Slide 11 text

11 大事にしている価値基準本質的(マジ)で価値あるユーザーにとって本質的な価値があると自信を持って言えることをする。理想ドリブン理想から考える。現在のリソースやスキルにとらわれず挑戦しつづける。アウトプット→思考まず、アウトプットする。そして考え、改善する Hack Everything 取り組んでいることや持っているリソースの性質を深く理解する。その上で枠を超えて発想する。あえて、共有する人とチームを知る。知られるように共有する。オープンにフィードバックしあうことで一緒に成長する。

Slide 12

Slide 12 text

freeeのエンジニアチーム 12 02 Section

Slide 13

Slide 13 text

13 100+ Enginners

Slide 14

Slide 14 text

14 目的志向を大切にしながら最新技術を積極的に導入特定の技術に執着せずユーザーの課題を解決する最適な技術を選ぶ。

Slide 15

Slide 15 text

開発合宿 15 10/4 - 05 箱根（と五反田オフィス）でエンジニア全員参加の開発合宿を実施業務とかけ離れた非連続的な開発に取り組む

Slide 16

Slide 16 text

16 共有する文化リリース情報や技術的な挑戦や失敗は共有し開発チームの全体のナレッジにします

Slide 17

Slide 17 text

17 最近何故かキーボードが割れている人が多い

Slide 18

Slide 18 text

組織の成長と開発現状 18 03 Section

Slide 19

Slide 19 text

19 Github を使った基本的な開発フロー Pull Request (PR) Develop Pull Request できました！レビューお願いします。レビューします！ ● 根拠と実装の正しさ ● 最適なコードなのか ● 動作などを確認、コメントする。最終的に、問題が状態で Develop にマージする開発者レビュアー開発者はコメントをもとにコミットを重ねる PR が提出されマージされる = 新しい機能が追加された

Slide 20

Slide 20 text

20 エンジニアチームのヘッドカウント 2017年新卒で入ってからヘッドカウントは1.5倍ぐらいになているこのあたり集計がおかしい 2017Eng. 入社

Slide 21

Slide 21 text

21 エンジニアチーム全体のPRの作成量 2017Eng. 入社緩やかな増加急激な増加急激に開発速度が加速した一年だった

Slide 22

Slide 22 text

コミッターの増加が開発力に直結、人月の神話から逸脱した！？ホントに急に開発力が上がったのか 22 全リポジトリのコミッター合計と比較してみるこのあたり集計がおかしいマージされた PR数コミッタヘッドカウント PR 数は伸び悩み

Slide 23

Slide 23 text

23 PRODUCTS 自分が所属するチームが担当機能の開発や改善がメインタスクですが、開発環境の改善も並行して行っています。

Slide 24

Slide 24 text

24 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い

Slide 25

Slide 25 text

● SCSS 25 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets ● ES6 (ECMAScrip6) ● JSX (React) ● CoffeeScript モダンな JavaScript の規格や、DSL で記述

Slide 26

Slide 26 text

26 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets DSL は実行できないし、モダンな JavaScript は動作が保証されていない ● ES6 (ECMAScrip6) caniuse.com

Slide 27

Slide 27 text

27 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets Webpack JavaScript や、CSS は古いブラウザでも動作するようトランスパイルし配信ブラウザでは、動作が保証されていない nodejs のパッケージ

Slide 28

Slide 28 text

28 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 超巨大なコードベース "*.rb" ファイル数十万行 "*.js" ファイル数十万行 "*.coffee" ファイル数十万行（レガシーコード）

Slide 29

Slide 29 text

29 会計フリーに変更を入れるエンジニアのイメージ新規作成などのデータ入力申告書類作成のデータ出力日常的な会計処理申告のチームの変更範囲設立のチームの変更範囲会計のチームの変更範囲メインに変更を加えている会計チーム以外も機能開発単位で会計フリーには変更のPRがバシバシはいる環境連携の関係で、変更に依存が生じる

Slide 30

Slide 30 text

30 ヘッドカウントが増えて起こっていたトラブル ● キャッチアップコストの増加 ○ 超複雑な開発環境の構築 ■ 新しく入った人が動かすまで２日ぐらいかかっていた ● コミュニケーションコストの増加 ○ レビューのペース低下、PR のマージまでのコメントの往復が増える ■ コーディング規約・設計思想など基本的なミスの指摘 ● 入り乱れるドメイン知識 ■ すでに実装が存在するが再実装してしまう ■ 他の機能への副作用に気が付かない実装してしまう実際に生産性を上げるために行った取り組みを紹介する人を増やしてもなかなか開発効率が上がらない状況

Slide 31

Slide 31 text

開発環境の構築自動化とDockernize 31 05 Section

Slide 32

Slide 32 text

たくさんのアプリケーションに依存する会計フリー 32 管理 App A 管理 App B 開発するために、複数のアプリケーションを立ち上げない動作しない

Slide 33

Slide 33 text

すぐ壊れる実行環境と場当たり的な対応 33 管理 App A 管理 App B 変更が入ったり、開発マシンのOSバージョンの挙動の違い環境構築資料が混沌を帰していた資料も場当たり的な情報が多く再現性が低い

Slide 34

Slide 34 text

Ansible による開発マシンの環境構築 34 Playbook Ansible 本来の Ansible のユースケースサービスサーバサーバの構成を定義開発マシン最低限開発可能な環境構築を自動化開発環境の構成を定義

Slide 35

Slide 35 text

期待していなかった効果も得られた 35 開発環境の構成を定義 GitHub で管理することで、最新推奨の環境設定が一覧できる構成の変更がPRで管理され変更理由をトレースできるようになった

Slide 36

Slide 36 text

アプリケーションに依存する会計フリー 36 管理 App A 管理 App B 開発するために、複数のアプリケーションを立ち上げない動作しない

Slide 37

Slide 37 text

それぞれのアプリケーションの実行環境が異なる 37 管理 App A 管理 App B v a.a.a 2.x.x v b.b.b 2.z.z 2.y.y アプリケーションの実行環境がそれぞればらばらでバージョンを切り替えられるような環境を構築する必要がある

Slide 38

Slide 38 text

CI を用いた Docker イメージの更新 38 管理 App A 管理 App B 依存アプリケーションの最新のイメージがECRに存在する状態を実現 CodeBuild Elastic Container Registory 管理 App A 管理 App B CI でソースコードから Docker Image を作成最新のイメージとして保存

Slide 39

Slide 39 text

Docker による実行環境の仮想化 39 管理 App A 管理 App B v a.a.a 2.x.x docker compose で依存関係とミドルウェアを定義

Slide 40

Slide 40 text

Docker による実行環境の仮想化 40 管理 App A 管理 App B v a.a.a 2.x.x docker-compose 実行で最新のイメージが pull されそれぞれ副作用なく動作 Elastic Container Registory

Slide 41

Slide 41 text

人間がやるのは無駄 Lint, Formatter の強化 41 04 Section

Slide 42

Slide 42 text

42 コードの品質が下がりレビューの往復が増える Develop 開発ブランチの切り替え、動作確認、スイッチコンテキストなど単純な作業時間以上に効率が落ちる Merge コメント 1. コメント確認する 2. ブランチを切り替える 3. コメントに対応する 4. 動作確認 5. レビューを依頼する 1. 依頼を受ける 2. ブランチを切り替える 3. コード確認 4. 動作確認 5. コメント

Slide 43

Slide 43 text

フロントのビルドのコストがとにかく大きい 43 差分ビルドだと早い数十秒が、ブランチ切り替えによっては、キャッシュが効かずビルドを余儀なくされる場合もある

Slide 44

Slide 44 text

ESlint は導入していた 44 precommit hook commit push precommit がうまく動作しない、ルールがうまく検知しないという問題適切でなければコミットさせない適切でなければマージさせない設定が変更が降り積もりルールの全貌が把握できない引っ掛けているはずなのに何故かすり抜ける CI で検知される

Slide 45

Slide 45 text

ESlint から、Prettier 併用へ 45 エディタでフォーマットを修正、フォーマットに従わないコードを作らせない Editor フォーマッタを導入ルールの見直し

Slide 46

Slide 46 text

モノリスからマイクロサービスへ 46 06 Section

Slide 47

Slide 47 text

47 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い

Slide 48

Slide 48 text

複数の機能がサービスが混在 48 モデルA モデルB モデルD モデルE モデルC サービス1 サービス2 Ruby on Rails のモデルの振る舞いがサービスと強依存デグレの発生・影響範囲の見積もりの難易度が指数関数的に増加モデルが数百個存在 API も数百個存在 API 中で複数のサービスが実行される場合もある

Slide 49

Slide 49 text

のドメインを切り出したマイクロサービスドメインを切り出し、単機能のマイクロサービスへ 49 モデルA モデルB モデルD モデルE モデルC サービス1 サービス2 マイクロサービスサービスクライアントドメインの疎結合により影響範囲の分離今まさにプロジェクトとして動いている状況でまだまだ効果は未知数インターフェイスを明確化

Slide 50

Slide 50 text

まとめ 50 07 Section

Slide 51

Slide 51 text

今後 51 ● エンジニアがより攻めの開発を行うための施策とトラッキング中 ● エンジニアが取り組めることはたくさんあるが、メインタスクが最優先なので、スキマ時間を見つけてちょくちょく続けてゆきたい各施策、たくさんのチームに協力してもらって実現しているのでむちゃくちゃ感謝開発チーム全体で開発効率という課題に取り組み続けていきたい

Slide 52

Slide 52 text

冬のインターン募集がもうすぐ始まるらしい 52 10月中旬から募集を開始するようなのでよろしくおねがいします。

Slide 53

Slide 53 text

スモールビジネスを、世界の主役に。