Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
大規模フロントエンドの
クリーンアーキテクチャ化
~ 年間売上1,000億円企業モノタロウの取組み ~
12019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved.
株式会社MonotaR...
次のどれかに悩んでいる人
● 複雑に依存しているシステム
● 技術的負債を抱えているシステム
● テストコードがないシステム
2
対象者
CleanArchitectureについて
● 詳しく知らなくても学びながら作れる
3
もちかえってほしいこと
アジェンダ
4
● 自己紹介
● 背景
● CleanArchitectureとは?
● 取り組んで得た知見
● まとめ
自己紹介
5
氏名 芝本 雅史 (shibamoto masashi)
誕生日 1994/02/14
出身 大阪
会社 株式会社MonotaRO
データマーケティング部門
趣味 個人開発
興味 K8s,GCP,MicroFrontends
twitter s...
株式会社モノタロウ
7
● 事業者向けに提供する間接資材の通信販売会社
● 年間売上1,053億円の売上 (2018年)
○ 前年比24.0%↑
■ 2019年売上計画1,305億円
○ 9年連続20%↑の成長率 (2009年~)※
※ htt...
背景
8
9
急成長するモノタロウだが...
10
急成長についていけてないものがある...
11
背景
shibamoto
MonotaRO FrontEnd ServerSide - Search Page 
my mental capacity
12
背景
Python
shibamoto
MonotaRO FrontEnd ServerSide - Search Page 
my mental capacity
13
背景
Python
独自MVC
フレームワーク
(テストコードなし)
shibamoto
MonotaRO FrontEnd ServerSide - Search Page 
my mental capacity
14
背景
Python
独自MVC
フレームワーク
(テストコードなし)
技術的負債
shibamoto
MonotaRO FrontEnd ServerSide - Search Page 
my mental capacity
15
背景
Python
独自MVC
フレームワーク
(テストコードなし)
技術的負債
新機能拡張
shibamoto
MonotaRO FrontEnd ServerSide - Search Page 
my mental capacity
16
背景
Python
独自MVC
フレームワーク
(テストコードなし)
技術的負債
新機能拡張
独自MVC
フレームワーク
開発者の退職
shibamoto
MonotaRO FrontEnd ServerSide - Search Pag...
17
独自フレームワークから
脱却しないと...!
18
独自フレームワークがシステムと
密結合していて無理...
19
テストコードがないから不安...
20
そんなときに!
21
背景
Python
独自MVC
フレームワーク
(テストコードなし)
技術的負債
新機能拡張
独自MVC
フレームワーク
開発者の退職
cleanArchitectureshibamoto
MonotaRO FrontEnd Server...
CleanArchitectureとは?
22
23
CleanArchitecture
特徴
関心の分離
一方向への依存関係
※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
24
CleanArchitecture
レイヤー名 役割
Frameworks &
Drivers
DBやフレームワークの詳細
Interface
Adapters
内外へのデータ変換
Application
Business Rules
ア...
● データベースやWebフレームワークの詳細
○ ex.
■ databaseへの接続設定
■ Webフレームワークの設定
25
関心の分離 - Frameworks & Drivers -
● 外→内
○ 外部アクセスからユースケースを呼び出し
■ ex.
● MVCの Controller
● 内→外
○ Enterpriseのデータを外部へ適した形に変換
■ ex.
● MVCのView (Presenter)
26
関心の分...
● アプリケーション固有のビジネスルールを
カプセル化
● データベース,UI,フレームワークから隔離
○ ex.
■ キーワードから商品を検索するユースケース
■ ユーザー情報を登録するユースケース
27
関心の分離 - Applicatio...
● 企業全体のビジネスルールをカプセル化
● データとメソッドを持つ
○ ex.
■ 商品情報のドメイン
● メソッド:特価の商品か判断する
■ ユーザー情報のドメイン
● メソッド:〇企業に属するか判断する
28
関心の分離 - Enterp...
● 依存関係逆転の原則
○ dependency inversion principle
29
一方向への依存関係
30
依存関係逆転の原則
※ https://ja.wikipedia.org/wiki/依存性逆転の原則
before
31
依存関係逆転の原則
after
※ https://ja.wikipedia.org/wiki/依存性逆転の原則
● フレームワークからの独立
○ Independent of Frameworks
● データベースからの独立
○ Independent of Database
● UIからの独立
○ Independent of UI
32
CleanA...
● テスト可能
○ Testable
33
CleanArchitectureの良い面
※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
● ソースコードのファイルが増える
○ 処理を追う時間がかかる
34
CleanArchitectureの悪い面
UIでは「Atomic Designによるコンポーネント
化」に取り組みました。
※ 今回は話しません。 35
CleanArchitecture以外の取り組み
取り組んで得た知見
36
1. 学習しながら開発
2. リリースを分割
3. 本質的なことに集中
4. テストの手段
37
取り組んで得た知見
● 先に幹となる処理を書いて、後から枝葉と
なる処理を書くこと
○ 根本となる設計から始められる
38
1. 学習しながら開発
CleanArchitectureって、
どこから開発したら良いんだ..?
39
1. 学習しながら開発
チームでCleanArchitectureについて
詳しい人はいないし...
40
1. 学習しながら開発
最初から最後までを1本通して
作ってみよう
41
1. 学習しながら開発
42
1. 学習しながら開発
Controller Use Case Entity Presenter
先に幹となる処理を書いて、後から枝葉となる処理を書く
キーワードから商品を検索
43
1. 学習しながら開発
Controller Use Case Entity Presenter
Use Case Entity
先に幹となる処理を書いて、後から枝葉となる処理を書く
キーワードから商品を検索
カテゴリから商品を検索
44
1. 学習しながら開発
Controller Use Case Entity Presenter
Use Case Entity
Use Case
先に幹となる処理を書いて、後から枝葉となる処理を書く
キーワードから商品を検索
カテゴリか...
● CleanArchitectureを学習しながら、段階的
に作成可能
○ 最初から完璧に設計するのが難しい
○ 試行錯誤→理想形
● デバッグが容易
○ アプリケーションの動作確認がしやすい
45
1. 学習しながら開発
● エンドポイント毎にリリースする等のリ
リース規模を分割すること
○ メンテナンスコストを削減するため
46
2. リリースを分割
● ソースコード
○ 約3,000行
○ 約10ファイル
■ プロダクト
47
2. リリースを分割
● ソースコード
○ 約15,000行
○ 約300ファイル
■ 約150ファイル
● プロダクト
■ 約150ファイル
● テスト
検索ペー...
● ソースコード
○ 約3,000行
○ 約10ファイル
■ プロダクト
48
2. リリースを分割
● ソースコード
○ 約15,000行
○ 約300ファイル
■ 約150ファイル
● プロダクト
■ 約150ファイル
● テスト設計&実装...
とにかく開発に時間がかかる!
49
2. リリースを分割
大量の変更ファイルを維持するのは大変
早くリリースしたい...
50
2. リリースを分割
リリースを早くするのには...?
51
2. リリースを分割
リリースをエンドポイント毎に分割しよう
52
2. リリースを分割
53
2. リリースを分割
Routing
requeast
特集ページ
検索ページ
商品ページ
54
2. リリースを分割
Routing
requeast
特集ページ
(CleanArchitecture化)
検索ページ
商品ページ
release
55
2. リリースを分割
Routing
requeast
特集ページ
(CleanArchitecture化)
検索ページ
(CleanArchitecture化)
商品ページ
release
release
56
2. リリースを分割
Routing
requeast
特集ページ
(CleanArchitecture化)
検索ページ
(CleanArchitecture化)
商品ページ
(CleanArchitecture化)
release
re...
● トラブルの原因調査が比較的簡単
○ ロールバックがしやすい
● アプリケーションのサービス提供をしなが
ら開発可能
○ 新機能追加のタイミングが調整しやすい
57
2. リリースを分割
● 本質的な部分以外に時間をかけないこと
○ 開発工数を抑えるため
58
3. 本質的なことに集中
本質的
● 独自フレームワークからの脱却
● テストコード作成
59
3. 本質的なことに集中
非本質的
● ユースケースの返り値はEntityの型
● Entityは不変オブジェクト
● Presenterにセットした値を取得する手段
● ...etc
60
3. 本質的なことに集中
● CleanArchitectureが目的ではない
○ 何がしたいのかよく考えること
● リファクタリングが容易
○ テストコードがあるから
61
3. 本質的なことに集中
● スナップショットテストを活用
○ 効率的に品質を高めるため
○ ex.
■ Jest, Puppeteer
62
4. テストの手段
システムリプレースのテストは
どうするの?
63
4. テストの手段
大規模なシステムだと、一からテスト
仕様書を書いて進めるのは非効率
64
4. テストの手段
● 「HTMLが変わってないこと」に着目
↓
スナップショットツールの活用
65
4. テストの手段
66
4. テストの手段
基本パターン
URLリスト
検索ページ
(CleanArchitecture前)
検索ページ
(CleanArchitecture後)
requeast
HTML
HTML
requeast
diff
機能網羅
スナッ...
67
4. テストの手段
ランダムパターン
URLリスト
検索ページ
(CleanArchitecture前)
検索ページ
(CleanArchitecture後)
requeast
HTML
HTML
requeast
diff
アクセスログ...
● テスト工程が簡単
○ テスト→バグ修正を繰り返す
● 非機能要件は別途テストが必要
○ プロファイリング
○ 負荷テスト
68
4. テストの手段
取り組んだ結果
Q1. 独自フレームワークからの脱却は?
A1. 独自フレームワークの処理をFrameworks & Drivers層
に寄せたことで、他のフレームワークと切り替えれるよう
になった。
フレームワークに求める機能を整理することが...
取り組んだ結果
Q2. テストコードは?
A2. プロダクションコードと同じぐらいの行数のテスト
コードを生成できた。
インターフェースをMockで差し替えるだけで、テスト
コードが容易に生成できる。また、一方向へ依存している
ため、上の層を気...
取り組んだ結果
Q3. 悪かったことは?
A3. 開発工数が予定以上に膨れてしまった。(約1.6倍)
原因の1つは、「CleanArchitectureの理解」と「業務知
識の理解」を並走して開発したため。結果、スピードが低
下した。
→ 業務...
取り組んだ結果
Q4. 良かったことは?
A4. 複雑だったコードが、適切な層に配置されたことで、
コードの見通しが良くなった。
ユースケースの種類や順序が明確になるので、
仕様を把握しやすくなった。結果、保守しやすくなった。
72
まとめ
● 依存フレームワークからの脱却する道筋が立った
● 開発工数が大幅に膨らんでしまう問題がある
● CleanArchitectureに詳しい人がチームにいなくて
もなんとかなる!
73
急成長するモノタロウと一緒に働いてみませんか?
● 自社開発・自社運用で、全社/全業務でITを駆使するテ
クノロジー企業です。テックブログもやってます。
● 本社は関西(尼崎)で、幅広い職種を募集しています。
○ ITエンジニア、データサイエン...
752019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved.
Nächste SlideShare
Wird geladen in …5
×

2

Teilen

Herunterladen, um offline zu lesen

大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~

Herunterladen, um offline zu lesen

Developers Boost KANSAI (2019.6.15 @Osaka) の発表資料です。

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~

  1. 1. 大規模フロントエンドの クリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~ 12019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved. 株式会社MonotaRO データマーケティング部門 芝本 雅史
  2. 2. 次のどれかに悩んでいる人 ● 複雑に依存しているシステム ● 技術的負債を抱えているシステム ● テストコードがないシステム 2 対象者
  3. 3. CleanArchitectureについて ● 詳しく知らなくても学びながら作れる 3 もちかえってほしいこと
  4. 4. アジェンダ 4 ● 自己紹介 ● 背景 ● CleanArchitectureとは? ● 取り組んで得た知見 ● まとめ
  5. 5. 自己紹介 5
  6. 6. 氏名 芝本 雅史 (shibamoto masashi) 誕生日 1994/02/14 出身 大阪 会社 株式会社MonotaRO データマーケティング部門 趣味 個人開発 興味 K8s,GCP,MicroFrontends twitter silver_birder portfolio https://silver-birder.github.io 自己紹介 6
  7. 7. 株式会社モノタロウ 7 ● 事業者向けに提供する間接資材の通信販売会社 ● 年間売上1,053億円の売上 (2018年) ○ 前年比24.0%↑ ■ 2019年売上計画1,305億円 ○ 9年連続20%↑の成長率 (2009年~)※ ※ https://pdf.irpocket.com/C3064/g9xd/i8RW/uNIX.pdf no.7 システムは主にPython
  8. 8. 背景 8
  9. 9. 9 急成長するモノタロウだが...
  10. 10. 10 急成長についていけてないものがある...
  11. 11. 11 背景 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  12. 12. 12 背景 Python shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  13. 13. 13 背景 Python 独自MVC フレームワーク (テストコードなし) shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  14. 14. 14 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  15. 15. 15 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  16. 16. 16 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  17. 17. 17 独自フレームワークから 脱却しないと...!
  18. 18. 18 独自フレームワークがシステムと 密結合していて無理...
  19. 19. 19 テストコードがないから不安...
  20. 20. 20 そんなときに!
  21. 21. 21 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 cleanArchitectureshibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  22. 22. CleanArchitectureとは? 22
  23. 23. 23 CleanArchitecture 特徴 関心の分離 一方向への依存関係 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  24. 24. 24 CleanArchitecture レイヤー名 役割 Frameworks & Drivers DBやフレームワークの詳細 Interface Adapters 内外へのデータ変換 Application Business Rules アプリケーション固有のビジネ スルールをカプセル化 Enterprice Business Rules 企業全体のビジネスルールを カプセル化 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  25. 25. ● データベースやWebフレームワークの詳細 ○ ex. ■ databaseへの接続設定 ■ Webフレームワークの設定 25 関心の分離 - Frameworks & Drivers -
  26. 26. ● 外→内 ○ 外部アクセスからユースケースを呼び出し ■ ex. ● MVCの Controller ● 内→外 ○ Enterpriseのデータを外部へ適した形に変換 ■ ex. ● MVCのView (Presenter) 26 関心の分離 - Interface Adapters -
  27. 27. ● アプリケーション固有のビジネスルールを カプセル化 ● データベース,UI,フレームワークから隔離 ○ ex. ■ キーワードから商品を検索するユースケース ■ ユーザー情報を登録するユースケース 27 関心の分離 - Application Business Rules -
  28. 28. ● 企業全体のビジネスルールをカプセル化 ● データとメソッドを持つ ○ ex. ■ 商品情報のドメイン ● メソッド:特価の商品か判断する ■ ユーザー情報のドメイン ● メソッド:〇企業に属するか判断する 28 関心の分離 - Enterprise Business Rules -
  29. 29. ● 依存関係逆転の原則 ○ dependency inversion principle 29 一方向への依存関係
  30. 30. 30 依存関係逆転の原則 ※ https://ja.wikipedia.org/wiki/依存性逆転の原則 before
  31. 31. 31 依存関係逆転の原則 after ※ https://ja.wikipedia.org/wiki/依存性逆転の原則
  32. 32. ● フレームワークからの独立 ○ Independent of Frameworks ● データベースからの独立 ○ Independent of Database ● UIからの独立 ○ Independent of UI 32 CleanArchitectureの良い面 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  33. 33. ● テスト可能 ○ Testable 33 CleanArchitectureの良い面 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  34. 34. ● ソースコードのファイルが増える ○ 処理を追う時間がかかる 34 CleanArchitectureの悪い面
  35. 35. UIでは「Atomic Designによるコンポーネント 化」に取り組みました。 ※ 今回は話しません。 35 CleanArchitecture以外の取り組み
  36. 36. 取り組んで得た知見 36
  37. 37. 1. 学習しながら開発 2. リリースを分割 3. 本質的なことに集中 4. テストの手段 37 取り組んで得た知見
  38. 38. ● 先に幹となる処理を書いて、後から枝葉と なる処理を書くこと ○ 根本となる設計から始められる 38 1. 学習しながら開発
  39. 39. CleanArchitectureって、 どこから開発したら良いんだ..? 39 1. 学習しながら開発
  40. 40. チームでCleanArchitectureについて 詳しい人はいないし... 40 1. 学習しながら開発
  41. 41. 最初から最後までを1本通して 作ってみよう 41 1. 学習しながら開発
  42. 42. 42 1. 学習しながら開発 Controller Use Case Entity Presenter 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索
  43. 43. 43 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索
  44. 44. 44 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity Use Case 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索 価格から商品を検索
  45. 45. ● CleanArchitectureを学習しながら、段階的 に作成可能 ○ 最初から完璧に設計するのが難しい ○ 試行錯誤→理想形 ● デバッグが容易 ○ アプリケーションの動作確認がしやすい 45 1. 学習しながら開発
  46. 46. ● エンドポイント毎にリリースする等のリ リース規模を分割すること ○ メンテナンスコストを削減するため 46 2. リリースを分割
  47. 47. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 47 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト 検索ページ - CleanArchitecture化 before/after
  48. 48. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 48 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト設計&実装に10人月 テストに6人月 検索ページ - CleanArchitecture化 before/after
  49. 49. とにかく開発に時間がかかる! 49 2. リリースを分割
  50. 50. 大量の変更ファイルを維持するのは大変 早くリリースしたい... 50 2. リリースを分割
  51. 51. リリースを早くするのには...? 51 2. リリースを分割
  52. 52. リリースをエンドポイント毎に分割しよう 52 2. リリースを分割
  53. 53. 53 2. リリースを分割 Routing requeast 特集ページ 検索ページ 商品ページ
  54. 54. 54 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ 商品ページ release
  55. 55. 55 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ (CleanArchitecture化) 商品ページ release release
  56. 56. 56 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ (CleanArchitecture化) 商品ページ (CleanArchitecture化) release release release
  57. 57. ● トラブルの原因調査が比較的簡単 ○ ロールバックがしやすい ● アプリケーションのサービス提供をしなが ら開発可能 ○ 新機能追加のタイミングが調整しやすい 57 2. リリースを分割
  58. 58. ● 本質的な部分以外に時間をかけないこと ○ 開発工数を抑えるため 58 3. 本質的なことに集中
  59. 59. 本質的 ● 独自フレームワークからの脱却 ● テストコード作成 59 3. 本質的なことに集中
  60. 60. 非本質的 ● ユースケースの返り値はEntityの型 ● Entityは不変オブジェクト ● Presenterにセットした値を取得する手段 ● ...etc 60 3. 本質的なことに集中
  61. 61. ● CleanArchitectureが目的ではない ○ 何がしたいのかよく考えること ● リファクタリングが容易 ○ テストコードがあるから 61 3. 本質的なことに集中
  62. 62. ● スナップショットテストを活用 ○ 効率的に品質を高めるため ○ ex. ■ Jest, Puppeteer 62 4. テストの手段
  63. 63. システムリプレースのテストは どうするの? 63 4. テストの手段
  64. 64. 大規模なシステムだと、一からテスト 仕様書を書いて進めるのは非効率 64 4. テストの手段
  65. 65. ● 「HTMLが変わってないこと」に着目 ↓ スナップショットツールの活用 65 4. テストの手段
  66. 66. 66 4. テストの手段 基本パターン URLリスト 検索ページ (CleanArchitecture前) 検索ページ (CleanArchitecture後) requeast HTML HTML requeast diff 機能網羅 スナップショットツールの流れ
  67. 67. 67 4. テストの手段 ランダムパターン URLリスト 検索ページ (CleanArchitecture前) 検索ページ (CleanArchitecture後) requeast HTML HTML requeast diff アクセスログ スナップショットツールの流れ
  68. 68. ● テスト工程が簡単 ○ テスト→バグ修正を繰り返す ● 非機能要件は別途テストが必要 ○ プロファイリング ○ 負荷テスト 68 4. テストの手段
  69. 69. 取り組んだ結果 Q1. 独自フレームワークからの脱却は? A1. 独自フレームワークの処理をFrameworks & Drivers層 に寄せたことで、他のフレームワークと切り替えれるよう になった。 フレームワークに求める機能を整理することができたた め、新たなフレームワークを採用する際に役立つ。 69
  70. 70. 取り組んだ結果 Q2. テストコードは? A2. プロダクションコードと同じぐらいの行数のテスト コードを生成できた。 インターフェースをMockで差し替えるだけで、テスト コードが容易に生成できる。また、一方向へ依存している ため、上の層を気にしなくて済む。結果、テストコードに 集中できる。 70
  71. 71. 取り組んだ結果 Q3. 悪かったことは? A3. 開発工数が予定以上に膨れてしまった。(約1.6倍) 原因の1つは、「CleanArchitectureの理解」と「業務知 識の理解」を並走して開発したため。結果、スピードが低 下した。 → 業務知識の理解者がメンバーにいると良い。 71
  72. 72. 取り組んだ結果 Q4. 良かったことは? A4. 複雑だったコードが、適切な層に配置されたことで、 コードの見通しが良くなった。 ユースケースの種類や順序が明確になるので、 仕様を把握しやすくなった。結果、保守しやすくなった。 72
  73. 73. まとめ ● 依存フレームワークからの脱却する道筋が立った ● 開発工数が大幅に膨らんでしまう問題がある ● CleanArchitectureに詳しい人がチームにいなくて もなんとかなる! 73
  74. 74. 急成長するモノタロウと一緒に働いてみませんか? ● 自社開発・自社運用で、全社/全業務でITを駆使するテ クノロジー企業です。テックブログもやってます。 ● 本社は関西(尼崎)で、幅広い職種を募集しています。 ○ ITエンジニア、データサイエンティスト、デジタル マーケター、プロダクトマネージャー ● お気軽にご連絡ください。 ○ shibamoto@monotaro.com 74
  75. 75. 752019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved.
  • MitsutoshiNakano

    Aug. 9, 2021
  • newpopsyoshioka

    Sep. 29, 2019

Developers Boost KANSAI (2019.6.15 @Osaka) の発表資料です。

Aufrufe

Aufrufe insgesamt

3.484

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

758

Befehle

Downloads

10

Geteilt

0

Kommentare

0

Likes

2

×