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

Transcript

1. freee 株式会社 開発速度を支える技術 2018.10.07 2018年情報科学若手の会
2. 大学院理工学研究科卒業 大学院では、初期の Ethereum を触ってました 2017年エンジニア新卒1期生としてfreee株式会社に入社 現在は、エンジニアとして、会計フリーをメインに開発 Web フロント、Ruby on Rails のサーバサイドの開発をはじめ、Golang、 Kubernetes を使ったプロダクトのマイクロサービス化にも挑戦している。 趣味は 仮想通貨（概念が好き）、Pokemon Go、あと酔うけどVR Hiroki NAKASHIMA 中島 啓貴 freee株式会社 プロダクト開発 2
3. freeeの事業 3 01 Section
4. 4 スモールビジネスを、世界の主役に。 アイデアやパッションやスキルがあればだれでも、 ビジネスを強くスマートに育てられるプラットフォーム 161億603万円 (資本準備金等含む) 従業員数 事業内容 クラウド型バックオフィスサービスの開発・販売 資本金 設立年月日 2012年7月 465名（2018年6月末時点）
5. 5 PRODUCTS
6. 6 6 会計 請求書 経費精算 債務管理 債権管理 人事労務 　バックオフィス業務の一番の無駄は、様々なツー ルに同じような情報を繰り返し入力する転記作業 です。時間がかかる上、作業ミスの温床にもなって いました。 　会計freeeでは請求書作成や債権債務管理など 経理業務に必要な機能を標準搭載。日々の経理 で入力した情報を自動で帳簿に反映し、転記作業 が極力不要な体制を実現します。 会計と経理を一体化 転記作業を排除し、管理が簡単に 6
7. 7 100万 サービス開始５年で 1,000,000 事業所数累計 事業所突破
8. 8 市場調査からもシェア No.1 35% A社 B社 その他 26% 23% ※出典：BCN　クラウド会計ソフト市場調査。n=418、webアンケート調査
9. 日本全国の中小企業の膨大なデータが集約 9 100万事業所の膨大なビッグデータが、 スモールビジネスの経営を強くする。
10. 中小企業がクラウドで連携する未来 10 あらゆる企業と、多様な仕組みが繋がり、 freeeは、ビジネスプラットフォームへと進化 経営効率化 在庫管理 入金管理 ファクタ リング 取引効率化 EDI 請求 ネッティング 決済 機会創出 ビジネス マッチング
11. 11 大事にしている価値基準 本質的(マジ)で価値ある ユーザーにとって本質的な 価値があると自信を持って 言えることをする。 理想ドリブン 理想から考える。現在の リソースやスキルにとらわれず 挑戦しつづける。 アウトプット→思考 まず、アウトプットする。 そして考え、改善する Hack Everything 取り組んでいることや持っている リソースの性質を深く理解する。 その上で枠を超えて発想する。 あえて、共有する 人とチームを知る。 知られるように共有する。 オープンにフィードバックし あうことで一緒に成長する。
12. freeeのエンジニアチーム 12 02 Section
13. 13 100+ Enginners
14. 14 目的志向を大切にしながら最新技術を積極的に導入 特定の技術に執着せずユーザーの課題を解決する最適な技術を選ぶ。
15. 開発合宿 15 10/4 - 05 箱根（と五反田オフィス）でエンジニア全員参加の開発合宿を実施 業務とかけ離れた非連続的な開発に取り組む
16. 16 共有する文化 リリース情報や技術的な挑戦や失敗は共有し 開発チームの全体のナレッジにします
17. 17 最近何故かキーボードが割れている人が多い
18. 組織の成長と開発現状 18 03 Section
19. 19 Github を使った基本的な開発フロー Pull Request (PR) Develop Pull Request できました！ レビューお願いします。 レビューします！ • 根拠と実装の正しさ • 最適なコードなのか • 動作 などを確認、コメントする。 最終的に、問題が状態で Develop にマージする 開発者 レビュアー 開発者はコメントをもとに コミットを重ねる PR が提出されマージされる = 新しい機能が追加された
20. 20 エンジニアチームのヘッドカウント 2017年新卒で入ってからヘッドカウントは1.5倍ぐらいになている このあたり集計がおかしい 2017Eng. 入社
21. 21 エンジニアチーム全体のPRの作成量 2017Eng. 入社 緩やかな増加 急激な増加 急激に開発速度が加速した一年だった
22. コミッターの増加が開発力に直結、人月の神話から逸脱した！？ ホントに急に開発力が上がったのか 22 全リポジトリのコミッター合計と比較してみる このあたり集計がおかしい マージされた PR数 コミッタ ヘッドカウント PR 数は伸び悩み
23. 23 PRODUCTS 自分が所属するチームが担当 機能の開発や改善がメインタスクですが、 開発環境の改善も並行して行っています。
24. 24 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作 機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い
25. • SCSS 25 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets • ES6 (ECMAScrip6) • JSX (React) • CoffeeScript モダンな JavaScript の規格や、DSL で記述
26. 26 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets DSL は実行できないし、モダンな JavaScript は動作が保証されていない • ES6 (ECMAScrip6) caniuse.com
27. 27 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets Webpack JavaScript や、CSS は 古いブラウザでも動作するよう トランスパイルし配信 ブラウザでは、動作が保証されていない nodejs のパッケージ
28. 28 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 超巨大なコードベース "*.rb" ファイル 数十万 行 "*.js" ファイル 数十万 行 "*.coffee" ファイル 数十万 行 （レガシーコード）
29. 29 会計フリーに変更を入れるエンジニアのイメージ 新規作成などの データ入力 申告書類作成の データ出力 日常的な会計 処理 申告のチームの変更範囲 設立のチームの変更範囲 会計のチームの変更範囲 メインに変更を加えている会計チーム以外も 機能開発単位で会計フリーには変更のPRがバシバシはいる環境 連携の関係で、変更に依存が生じる
30. 30 ヘッドカウントが増えて起こっていたトラブル • キャッチアップコストの増加 ◦ 超複雑な開発環境の構築 ▪ 新しく入った人が動かすまで２日ぐらいかかっていた • コミュニケーションコストの増加 ◦ レビューのペース低下、PR のマージまでのコメントの往復が増える ▪ コーディング規約・設計思想など基本的なミスの指摘 • 入り乱れるドメイン知識 ▪ すでに実装が存在するが再実装してしまう ▪ 他の機能への副作用に気が付かない実装してしまう 実際に生産性を上げるために行った取り組みを紹介する 人を増やしてもなかなか開発効率が上がらない状況
31. 開発環境の構築自動化とDockernize 31 05 Section
32. たくさんのアプリケーションに依存する会計フリー 32 管理 App A 管理 App B 開発するために、複数のアプリケーションを立ち上げない動作しない
33. すぐ壊れる実行環境と場当たり的な対応 33 管理 App A 管理 App B 変更が入ったり、開発マシンのOSバージョンの挙動の違い 環境構築資料が混沌を帰していた 資料も場当たり的な情報が 多く再現性が低い
34. Ansible による開発マシンの環境構築 34 Playbook Ansible 本来の Ansible の ユースケース サービスサーバ サーバの構成 を定義 開発マシン 最低限開発可能な環境構築を自動化 開発環境の構成 を定義
35. 期待していなかった効果も得られた 35 開発環境の構成 を定義 GitHub で管理することで、最新推奨の環境設定が一覧できる 構成の変更がPRで管理され変更理由を トレースできるようになった
36. アプリケーションに依存する会計フリー 36 管理 App A 管理 App B 開発するために、複数のアプリケーションを立ち上げない動作しない
37. それぞれのアプリケーションの実行環境が異なる 37 管理 App A 管理 App B v a.a.a 2.x.x v b.b.b 2.z.z 2.y.y アプリケーションの実行環境がそれぞればらばらで バージョンを切り替えられるような環境を構築する必要がある
38. CI を用いた Docker イメージの更新 38 管理 App A 管理 App B 依存アプリケーションの最新のイメージがECRに存在する状態を実現 CodeBuild Elastic Container Registory 管理 App A 管理 App B CI でソースコードから Docker Image を作成 最新のイメージとして保存
39. Docker による実行環境の仮想化 39 管理 App A 管理 App B v a.a.a 2.x.x docker compose で依存関係とミドルウェアを定義
40. Docker による実行環境の仮想化 40 管理 App A 管理 App B v a.a.a 2.x.x docker-compose 実行で最新のイメージが pull されそれぞれ副作用なく動作 Elastic Container Registory
41. 人間がやるのは無駄 Lint, Formatter の強化 41 04 Section
42. 42 コードの品質が下がりレビューの往復が増える Develop 開発ブランチの切り替え、動作確認、スイッチコンテキストなど 単純な作業時間以上に効率が落ちる Merge コメント 1. コメント確認する 2. ブランチを切り替える 3. コメントに対応する 4. 動作確認 5. レビューを依頼する 1. 依頼を受ける 2. ブランチを切り替える 3. コード確認 4. 動作確認 5. コメント
43. フロントのビルドのコストがとにかく大きい 43 差分ビルドだと早い数十秒が、 ブランチ切り替えによっては、キャッシュが効かずビルドを余儀なくされる場合もある
44. ESlint は導入していた 44 precommit hook commit push precommit がうまく動作しない、ルールがうまく検知しないという問題 適切でなければ コミットさせない 適切でなければ マージさせない 設定が変更が降り積もり ルールの全貌が 把握できない 引っ掛けているはずなのに 何故かすり抜ける CI で検知される
45. ESlint から、Prettier 併用へ 45 エディタでフォーマットを修正、フォーマットに従わないコードを作らせない Editor フォーマッタを導入 ルールの見直し
46. モノリスからマイクロサービスへ 46 06 Section
47. 47 会計フリーの開発イメージ ├── app │ ├── assets │ ├── controllers │ ├── models │ ├── views │ └── workers └── front ├── images ├── javascripts └── stylesheets 静的な HTML や、ロジックは、 Rails で動作 機能開発単位でチーム開発、フロントとサーバに実装を加える API リクエストへのリクエスト Web のブラウザ上での振る舞い
48. 複数の機能がサービスが混在 48 モデルA モデルB モデルD モデルE モデルC サービス1 サービス2 Ruby on Rails のモデルの振る舞いがサービスと強依存 デグレの発生・影響範囲の見積もりの難易度が指数関数的に増加 モデルが数百個存在 API も数百個存在 API 中で複数のサービス が実行される場合もある
49. のドメインを切り出した マイクロサービス ドメインを切り出し、単機能のマイクロサービスへ 49 モデルA モデルB モデルD モデルE モデルC サービス1 サービス2 マイクロサービス サービス クライアント ドメインの疎結合により影響範囲の分離 今まさにプロジェクトとして動いている状況でまだまだ効果は未知数 インターフェイスを明確化
50. まとめ 50 07 Section
51. 今後 51 • エンジニアがより攻めの開発を行うための施策とトラッキング中 • エンジニアが取り組めることはたくさんあるが、メインタスクが最優先なので、 スキマ時間を見つけてちょくちょく続けてゆきたい 各施策、たくさんのチームに協力してもらって実現しているのでむちゃくちゃ感謝 開発チーム全体で開発効率という課題に取り組み続けていきたい
52. 冬のインターン募集がもうすぐ始まるらしい 52 10月中旬から募集を開始するようなのでよろしくおねがいします。
53. スモールビジネスを、 世界の主役に。