MF KESSAIが、技術的挑戦を繰り返しながら サービス価値と開発のIKIOIを上げ続けてる話

Transcript

1. MF KESSAI が、技術的挑戦を繰り返しながら サービス価値と開発のIKIOI を上げ続けてる話 MF KESSAI 株式会社 CTO （兼SRE ） 篠原 祐貴（@shinofara ）
2. Index
3. 本日お話する事 MF KESSAI と登壇者について 創業からこれまでのサマリ これまでに発生したIssue とAction と反省 開発を支える文化とIKIOI を大事にする文化 採用に関する考え方と案内 おわり 1. 2. 3. 4. 5. 6.
4. MF KESSAIと登壇者情報
5. MF KESSAI という会社について corp.moneyforward.com マネーフォワード、子会 社「MF KESSAI」を設 立 手間もリスクもゼロ 、企業間後払い決済サー ビスを提供開始 中小企業の資金繰りの課題を解決、業務 効率化の一歩先へ お金のプラットフォ ームを提供する株式会社マネーフォワー ド（本社：東京都港区、代表取締役社長 CEO：辻庸介、以下「当社」）は、2017 年3月16日付で当社の1…… MF KESSAI 株式会社 2017 年03 月設立 株式会社マネーフォワード100% 子会社 大手町ビル内Finolab にオフィスを構える 初期は社員４名とインターン２名でスタート corp.mfkessai.co.jp MF KESSAI株式会社を設 立しました | MF KESSAI 株式会社 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 のコーポレートサイトです。企業情報、 ニュース、採用情報など様々な情報を掲 載しています。… corp.mfkessai.co.jp MF KESSAI株式会社 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 のコーポレートサイトです。企業情報、 ニュース、採用情報など様々な情報を掲 載しています。… https://corp.mfkessai.co.jp https://corp.mfkessai.co.jp/press/2017/06/mf- kessai 株式会社を設立しました/ https://corp.moneyforward.com/news/release/serv ice/20170620- mf- kessai/
6. MF KESSAI というサービスについて MF KESSAI サービス紹介動画 YouTube カンタンであんしんな企業間請求代行サービス「MF KESSAI 」
7. 登壇者（私）について 篠原 祐貴（@shinofara ） 1987 年1 月（32 歳） 現在の役割 CTO SRE Gopher （最近減りました） 入社時期 マネーフォワードに2016 年12 月 MF KESSAI は2017 年1 月頃から参加 よく使うエディタ Emacs( エディタではない） Goland Visual Studio Code lapras.com 篠原 祐貴さんのLAPRAS ページ LAPRASは、すぐれた機械学習技術とクロ ーリング技術を使い、インターネット上 でオープンになっている情報を集め、 「プロフィール」を自動生成します。… https://lapras.com/public/K6CCUJS
8. 技術系の登壇履歴 マネーフォワードの子会社MF KESSAIが選択したアーキテクチャ Speaker Deck GoとGCPとkubernetesを使った MF KESSAIの歴史 Speaker Deck 酔いどれGCPUG 2018/03/02 / PubSubとGAE/FEでサクッと大量にPDF生成出来るようにしたお話 Speaker Deck https://speakerdeck.com/shinofara/manehuowadofalsezi- hui- she- mf- kessaigaxuan- ze- sitaakitekutiya https://speakerdeck.com/shinofara/gotogcptokuberneteswoshi- tuta- mf- kessaifalseli- shi https://speakerdeck.com/shinofara/fedesakututoda- liang- nipdfsheng- cheng- chu- lai- ruyounisitaohua
9. 創業からこれまでのサマリ
10. History 2017 年 03 月 MF KESSAI 株式会社創業 05 月 Go で開発した社内サービスリリース 11 月 導入企業向けWEB ＆API V1 リリース、また社内サービスのドメインロジックをgRPC で独立させてリリース 2018 PubSub とGAE で大量にPDF 生成する為のPDF サービスリリース 消込サービス稼働開始 Nuxt,js で開発した社内管理ツールが複数誕生 データ解析・分析や、機械学習を用いた審査モデル構築に特化したチーム誕生 2019 08/23 Money Forward Developer's Stories XX/XX API V2 リリース
11. MF KESSAI が０から考え選択した技術 tech.mfkessai.co.jp 新会社「MF KESSAI」は どのような技術・インフ ラ・体制で開発している のか | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… マネーフォワードの子会社MF KESSAIが選択したアーキテクチャ Speaker Deck Go Docker Kubernetes （k8s ） Google Cloud Platform （GCP ） それは結果的にマネーフォワードと全く異なるアーキテクチャ https://speakerdeck.com/shinofara/manehuowadofalsezi- hui- she- mf- kessaigaxuan- ze- sitaakitekutiya https://tech.mfkessai.co.jp/2017/07/1/
12. アプリケーションの種類 4 4 4 6 6 6 8 8 8 0 0 0 2 2 2 2 2 2 0 0 0 4 4 4 6 6 6 1 1 1 6 6 6 24 24 24 0 0 0 6 6 6 12 12 12 0 0 0 2 2 2 1 1 1 1 1 1 2 2 2 3 3 3 Go Container Nuxt Container Python Container Other Container Cloud Functions GAE/Fe(Go Container) Firebase Hosting 2017 2018 2019 0 10 20 30 数字で見るMF KESSAI の開発 ものづくりメンバーの割合 Backend Backend Backend: 46.2 % : 46.2 % : 46.2 % Frontend Frontend Frontend: 7.7 % : 7.7 % : 7.7 % SRE SRE SRE: 15.4 % : 15.4 % : 15.4 % Designeer Designeer Designeer: 15.4 % : 15.4 % : 15.4 % Data Engineer Data Engineer Data Engineer: 7.7 % : 7.7 % : 7.7 % Data Scientist Data Scientist Data Scientist: 7.7 % : 7.7 % : 7.7 %
13. Dev(Sec)Ops に関わる技術で見るMF KESSAI の歴史 2017 年 Sentry （Error Tracking ） CircleCI （CI / CD ） Github （git ） Jenkins on GKE （CI / CD ） Stackdriver(Monitoring/Logging) Datadog （Monitoring ） 2018 Cloud Builder （CD ） Spinnaker （CD ） Stackdriver Profiler 2019 Opencensus Trace / Metrics Vaddy Github Actions(CI / CD)
14. 日々利用するツールで見るMF KESSAI の歴史 2017 年 Docbase Slack Github Asana Gsuite 2018 Zapier Zendesk Salesforce 2019 Miro
15. これまでに発生したIssueとActionと反省
16. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題！GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
17. 今回お話しない事 プログラミングの話など技術に踏み込むお話は今回はSKIP アーキテクチャの細かい選定理由やロジックなどもSKIP 1. 2.
18. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
19. gRPC 導入とService Discovery Admin(Go ) Cloud SQL Service Ingress Google Kubernetes Cluster 創業時は社内ツールという事もあり、とてもシンプルな構成 ※ この頃はGKE はとても無駄な使い方ですね
20. gRPC 導入とService Discovery Service Ingress 2017 年後半にWEB/API リリース時の構成 Service Ingress WEB(Go) Cloud SQL Service gRPC(Go) REST API(Go) Service Ingress Admin(Go)
21. gRPC 導入とService Discovery k8s Service Ingress gRPC(Go) Pod をデプロイする度に、クライアントでLost Connection 発生 k8s Service Ingress WEB(Go) Cloud SQL Service gRPC(Go) REST API(Go) k8s Service Ingress Admin(Go) デプロイ!! Connection Lost
22. 発生した理由 Kubernetes Service はPod の経路情報を返す仕組みである事 gRPC はコネクションを使いまわすこと Pod はデプロイやスケール毎に生死を繰り返しIP が変動し続ける事 deeeet.com Kubernetes上でgRPCサ ービスを動かす https://deeeet.com/writing/2018/03/30/kubernetes - grpc/
23. 解決するにはどうしたらいいのか Client Side LB Proxy LB Sidecar(Envoy/Linkerd/Istio と行ったService Mesh) 経路が変わるのであれば何かしらの手段で経路選択などを行えれば良い 2017 年時点で採用できた手法は、公式ブログ書かれている選択しになります。 https://grpc.io/blog/loadbalancing/
24. gRPC 導入とService Discovery Sidecar にService Mesh のEnvoy を追加して、gRPC とのProxy として利用 WEB(Go) Service Envoy WEB(Go) Envoy WEB(Go) Envoy
25. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
26. Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 2018 年初期 MF KESSAI はGo でHTML レンダリングをするサービスが２つ存在した Service Ingress WEB(Go) gRPC(Go) Service Ingress Admin(Go)
27. Go のhtml/template でHTML レンダリングして出力 Typescript でVue.js のクライアントサイド実装 ※ この辺りを詳しく知りたい方はブログを見てみてください フロント部分は何で何していたのか tech.mfkessai.co.jp MF KESSAIの現在のフロ ントエンド環境について | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2018/10 /frontend/
28. 現在では2 つのNuxt サービスが稼働しています。 Nuxt.js Nuxt.js GraphQL(Go) HTTP gRPC Cloud SQL Cloud SQL gRPC WEB gRPC(Go) Service A Service B tech.mfkessai.co.jp Go + gqlgenを使った GraphQLアプリケーショ ンサーバーの実装 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… ※GraphQL に関してはこちらのブログを参照 https://tech.mfkessai.co.jp/2018/08 /go- gqlgen- graphql/
29. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
30. どのような課題が存在したか 創業初期は社内ツールとシンプルな請求書生成バッチのみ wkhtmltopdf でPDF を発行して居たため柔軟にデザインを組み立て辛かった バッチは定期的に実行され、直列にPDF を作成していた 導入企業向けにWEB/API をリリースするタイミングから、請求書を発行する 日時を指定できる状態となる為、特定の日時にスパイクする事で、処理時間 がかかりすぎる懸念が生まれる
31. 数値は公開する事はできませんが、 月末月初にスパイクする請求書発行の動き
32. 課題に対して選択した施策たち tech.mfkessai.co.jp ChromeでPDF作り始め て十数か月の日々が流れ た | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… 酔いどれGCPUG 2018/03/02 / PubSubとGAE/FEでサクッと大量にPDF生成出来るようにしたお話 Speaker Deck Chrome Headless を使う PubSub + GAE/Fe で並列化 https://tech.mfkessai.co.jp/2018/08/chrome/ https://speakerdeck.com/shinofara/fedesakututoda- liang- nipdfsheng- cheng- chu- lai- ruyounisitaohua
33. 結果どうだったか Pros 並列数が増え続けても時間内で発行完了し続けられる状態に 軽いPDF も重いPDF も関係無く発行可能 処理途中に再実行により解決可能な問題が発生した場合は自動でリトライ実 行され解決 Chrome を使うことで請求書デザインの選択肢が広がった Cons 使われない夜中もFlexInstance のコストが掛かる デプロイが徐々に重くなり今では15min デプロイタイムアウトに苦しむ日々もあった スケール速度の問題 Chrome の起動周りに多少のコストが掛かる Cons はあるがPros の恩恵は大きい。がDX はよろしくないといった状況でした。 後半のスライドで更に解決編があります。
34. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
35. 様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い Kubernetes はkubernetes secret Cloud Functions / GAE はDeploy 時に一緒にデプロイ Run は、KMS で暗号化したファイルを起動時に取得して複合 全ての管理はCloud Repository で、デプロイ時に良しなにしている
36. 新しい秘密情報管理・配布の仕組みに求めた要件 各アプリケーション( コンテナや1function 単位) で認証を行う事ができる GCP のService Account 毎に取得できる情報を制限できる 開発者毎にアクセスできる情報レベルや、参照権限、書き込み権限をある程 度柔軟にできる。 GCP マネージド or Container レベルで運用できること 秘密情報のバージョン管理ができること
37. Hashicorp Vault を利用する事にした理由 サービス毎にServiceAccount を作成して、SA Key を使って認証が可能 ServiceAccount 毎には取得可能な秘密情報だけRead 権限を付ける KMS を使って暗号化される CLI やUI から秘密情報の追加や更新が可能 GCP 上で動かすために必要な情報は公式ドキュメントに存在している cloud.google.com シークレット管理のため に Compute Engine で Vault を使用する | ソリ ューション | Google Cloud https://cloud.google.com/solutions/using- vault- for- secret- management? hl=ja
38. 様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い GAE Vault(Run) Pod GCS KMS Functions Service AccountのJWT Tokenを使って クライアント認証を行う Cloud Run でHashicorp Vault を動かして秘密情報管理サービスとして立ち上げてみた
39. 結果どうだったか Pros アプリケーション起動時にしかリクエストが来ない事もあり、実行回数少な め＝Run の運用コストは低い Dockerfile とアプリケーションだけあればあとはgcloud コマンドでデプロイ できるシンプルさ Cons Run のスピンアップに多少コストがかかる 起動時にVault を利用可能状態にする処理（Auto Unseal ）が失敗する条件があることにより、事故につながる Vault が起動しないと他のアプリケーションの起動時に取得する秘密情報取得 に失敗してしまう。 そこで改めて、Kubernetes で運用する事に決意した
40. 様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い GAE Vault(Pod) Pod GCS KMS Functions Service AccountのJWT Tokenを使って クライアント認証を行う 基本的な構成は変わらずCloud Run からKubernetes に移行 Ingress / Service
41. tech.mfkessai.co.jp Cloud Native時代のMF KESSAIが選択した秘密情 報管理と配布について | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… 書ききれないので、ブログに公開しました。 結果どうだったか https://tech.mfkessai.co.jp/2019/08/next_secret_management/
42. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
43. そもそもObservability （可観測性）に課題あるよね このRPC どこからいつ呼ばれているのか このリクエストパフォーマンス悪いけど、どこがネックなのか このリクエスト走る時、このサービスリソース使いすぎてるけど何が原因？ この処理って何回実行されていて、平均的なレイテンシとか、Max はどれく らい？
44. Observability とはなにか www.infoq.com 可観測性とマイクロサー ビス Zach Jory氏は、スケールアップが可能で 管理の容易なクラウドネイティブアプリ ケーションの構築を可能にする上で、マ イクロサービスとサービスメッシュ実装 の可観測性がいかに必要であるかを論じ た記事を書いた。氏の主張は、我々が過 去数ヶ月にわたって公開した多数の記事 や、その中で取り上げてきたインタビュ ーの内容にも通じるものがある。… 可観測性とは、データの顕在化と情報へのアクセスの容易化です。通信がフェールした時、期待通りに実 行されなかった時、あるいは期待しない場面で発生した時、これが重要になります。サービス相互の稼働 時のインタラクションは監視し、管理し、コントロールする必要があるのですが、そのためにはまず、可 観測性と、マイクロサービスアーキテクチャの振る舞いを理解できることが必要なのです。
45. tech.mfkessai.co.jp OpenCensus meetup vol.1参加レポート | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… どのように向き合ったか OpenCensus Meetup に参加 アプリケーションにOpenCensus を導入 Trace(Stackdriver / Jaeger) Stats(Stackdriver / Datadog) Stackdriver Profiler を導入 https://tech.mfkessai.co.jp/2019/04/ opencensus- meetup- report/
46. PDF 処理が同時間に大量に発生した時 平均値を大幅に超え20- 40 秒も処理時間がかかってることが判明
47. PDF 処理が同時間に大量に発生した時 正常な場合はChrome 起動前にセマフォでロックしてる箇所が0.004ms ほど
48. PDF 処理が同時間に大量に発生した時 高負荷な場合はロック解除されるまで14737ms もかかってる場合も
49. 結果どうだったか GAE/Flex で捌けているが実はパフォーマンスが良くなかったことに気づけた パフォーマンスが良くない原因も特定が容易になった 注：Span を追加する必要あり
50. 今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.
51. GAE/FE を使ってることでPDF サービスに影響があったか デプロイに毎回平均13 分 デプロイタイムアウトに苦しむ日々もあった サービスの要件に合わないスケール速度 使われない夜中もFlexI nstance のコストがかかってる 前提として弊社でのPDF サービスが、GAE/Fe の特性にマッチしていないとい う背景もありますが、事象としてあげると
52. GAE とRun のデプロイ速度比較（MFKESSAI の場合） CD 環境がCircleCI から、Cloud Builder に変更になった事も影響はしていると思いますが、大幅な改善があり
53. 処理単位の実行時間 GAE とRun は初期は同じ数秒台、PubSub は成功が続くと徐々にPost 件数を増やしてくるため、 GAE ではスケールまで徐々に処理が長くなる傾向、ただしスケール後は数十インスタンスで 処理することになるため、比較的早くなる。 一方でRun は安定的に処理を実施 0k 5k 10k 15k 20k Cloud Run App Engine
54. 開発を支える文化とIKIOIを大事にする文化
55. 初期の開発文化 社内のmarkdown wiki にはこうかかれていました。
56. 変わりゆく開発文化 tech.mfkessai.co.jp みんなで寄ってたかって タスクを潰している話 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… tech.mfkessai.co.jp デザインスプリントを短 縮してやってみた | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… tech.mfkessai.co.jp MF KESSAIの開発文化 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2018/04/1/ https://tech.mfkessai.co.jp/2018/10/flow/ https://tech.mfkessai.co.jp/2018/06/design- sprint/
57. 開発組織がユーザに提供する価値の最大化を行い続けるために、 現在のパフォーマンスの可視化と将来向上し続ける為の指標とし「IKIOI 」が生まれました。 そして生まれた開発チームの生産性指標「IKIOI 」
58. IKIOI とはどんな指標か tech.mfkessai.co.jp DevOpsパフォーマンス 改善開発合宿 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2019/06/ikioi/
59. 8 8 8 9 9 9 13 13 13 16 16 16 16 16 16 10 10 10 17 17 17 16 16 16 16 16 16 14 14 14 18 18 18 20 20 20 16 16 16 24 24 24 7 7 7 33 33 33 38 38 38 41 41 41 36 36 36 17 17 17 33 33 33 23 23 23 32 32 32 21 21 21 30 30 30 35 35 35 28 28 28 22 22 22 26 26 26 4.2 4.2 4.24.7 4.7 4.76.7 6.7 6.7 11.4 11.4 11.4 8 8 8 5.6 5.6 5.6 8.9 8.9 8.9 14.4 14.4 14.4 11.9 11.9 11.9 7.7 7.7 7.77.8 7.8 7.8 10.4 10.4 10.4 6.7 6.7 6.7 10.3 10.3 10.3 4.7 4.7 4.7 13.3 13.3 13.3 16.2 16.2 16.2 17.2 17.2 17.2 18.9 18.9 18.9 13.4 13.4 13.4 16.5 16.5 16.5 7.9 7.9 7.9 12.2 12.2 12.2 8.9 8.9 8.9 12.7 12.7 12.7 15.6 15.6 15.6 10.2 10.2 10.2 8 8 8 20 20 20 Deploy IKIOI 2019/01… 2019/02/01 2019/02/15 2019/03/01 2019/03/15 2019/03/29 2019/04/12 2019/05/03 2019/05/17 2019/05/31 2019/06/14 2019/06/28 2019/07/12 2019/07/26 2019/08/09 0 20 40 60 ここ数ヶ月のIKIOI Deploy / week / Power 例) 2019/01 週のIKIOI は 8 / 1 / 2 = 4 7 月の本番Deploy 数は114 回
60. 毎週誰かが何かを良くしてる「よくする週」 というものがありました 今は３ヶ月に１回誰かがIKIOI をただひたすらに良くする「IKIOI 人」を 実施 SRE チームで基盤の作り直しなど CI / CD 高速化 CircleCI の処理高速化・並列数増加 Cloud Builder でのイメージビルド高速化 Spinnaker でデプロイまでの時間を短縮( 人が介入しないフローに) 開発合宿 https://tech.mfkessai.co.jp/2019/06/ikioi/ tech.mfkessai.co.jp DevOpsパフォーマンス 改善開発合宿 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… IKIOI 向上に向けての取り組み https://tech.mfkessai.co.jp/2019/06/ikioi/
61. 最終的に開発したらすぐ出せる状態とかそういった理想を描いて、 これからもIKOI を向上していきます IKIOI のこれから
62. 採用に関する考え方と案内
63. 採用に対する思い MF KESSAI の良い部分と悪い部分 どちらも知ってもらった上で、一緒に働きたい。 そのため選考に関して可能な限りオープンにすることを大切に しています。
64. ハンドブック github.com mfkessai/handbook handbook. Contribute to mfkessai/handbook development by creating an account on GitHub.… MF KESSAI という会社はB2B という事もあり、 個人ではなかなかイメージすることが難しいと思っています。 なのでGithub にhandbook を公開する事で誰でも会社、事業、チーム、アーキテクチャ、 採用に関しての考え方を閲覧することができるようにしています。 https://github.com/mfkessai/handbook/blob/master/guide/b ackend- interview.md
65. 採用ガイド github.com mfkessai/handbook handbook. Contribute to mfkessai/handbook development by creating an account on GitHub.… https://github.com/mfkessai/handbook/blob/master/guide/b ackend- interview.md
66. 最後に
67. herp.careers ソフトウェアエンジニア （Backend） - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア（Backend）を募集してい ます。… herp.careers ソフトウェアエンジニア （Frontend） - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア（Frontend）を募集してい ます。… herp.careers ソフトウェアエンジニア （Site Reliability） - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア（Site Reliability）を募集し ています。… www.wantedly.com あらゆる経験をして新規 事業をゼロから創るサー ビスデザイナー募集！ by 株式会社マネーフォ ワード マネーフォワードの法人・個人事業主向 けサービスは“企業のお金のプラットフォ ーム”をテーマに掲げ、 企業の【お金の流 れの計算・把握・管理...… おまちしております
68. オリジナルのThe Go gopher(Gopher くん) は、Renée French によってデザインされ、CC BY 3.0 ライセンスが適用されています。 https://github.com/egonelbre/gophers 内のGopher はCC 0 ライセンスで利用可能 1. 2. スライド内の各ライセンス周り