Submit Search
Upload
某S社のddd(メイリオ)
•
Download as PPTX, PDF
•
20 likes
•
7,743 views
kumake
Follow
2015/08/07 DDD 勉強会
Read less
Read more
Software
Report
Share
Report
Share
1 of 35
Download now
Recommended
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
増田 亨
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
ドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイル
増田 亨
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
Tadayoshi Sato
Recommended
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
増田 亨
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
ドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイル
増田 亨
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
Tadayoshi Sato
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
増田 亨
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】
増田 亨
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
Koichiro Matsuoka
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
増田 亨
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
ちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てる
増田 亨
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
増田 亨
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
Mao Ohnishi
楽天エンジニアライフ
楽天エンジニアライフ
Rakuten Group, Inc.
More Related Content
What's hot
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
増田 亨
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】
増田 亨
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
Koichiro Matsuoka
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
増田 亨
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
ちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てる
増田 亨
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
増田 亨
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
What's hot
(20)
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
ちいさなオブジェクトでドメインモデルを組み立てる
ちいさなオブジェクトでドメインモデルを組み立てる
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Similar to 某S社のddd(メイリオ)
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
Mao Ohnishi
楽天エンジニアライフ
楽天エンジニアライフ
Rakuten Group, Inc.
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
Toshiyuki Hirata
新規事業を加速させる技術
新規事業を加速させる技術
Mao Ohnishi
InDesign正規表現勉強会_名古屋_0727
InDesign正規表現勉強会_名古屋_0727
ShinyaNakagawa
Spark MLlibではじめるスケーラブルな機械学習
Spark MLlibではじめるスケーラブルな機械学習
NTT DATA OSS Professional Services
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Preferred Networks
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Takashi Someda
Xcodeの管理を楽に - Jenkins編 -
Xcodeの管理を楽に - Jenkins編 -
Toshiyuki Hirata
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
Masataka Sato
コードレビューをより良くする Danger x Android
コードレビューをより良くする Danger x Android
Toshiyuki Hirata
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
DeNA
DeNAにおけるSWETの役割
DeNAにおけるSWETの役割
Toshiyuki Hirata
クラウド活用で実現する、開発・保守の効率化
クラウド活用で実現する、開発・保守の効率化
Hiroshi Koyama
サーバーレスの話
サーバーレスの話
真吾 吉田
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
株式会社スカイアーチネットワークス
ここが良かったDatadog
ここが良かったDatadog
tyamane
[CTO Night & Day 2019] ML services: MLOps #ctonight
[CTO Night & Day 2019] ML services: MLOps #ctonight
Amazon Web Services Japan
スマートフォンWebアプリ最適化”3つの極意”
スマートフォンWebアプリ最適化”3つの極意”
Koji Ishimoto
Xamarin概要と活用方法
Xamarin概要と活用方法
Yoshito Tabuchi
Similar to 某S社のddd(メイリオ)
(20)
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
楽天エンジニアライフ
楽天エンジニアライフ
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
新規事業を加速させる技術
新規事業を加速させる技術
InDesign正規表現勉強会_名古屋_0727
InDesign正規表現勉強会_名古屋_0727
Spark MLlibではじめるスケーラブルな機械学習
Spark MLlibではじめるスケーラブルな機械学習
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Xcodeの管理を楽に - Jenkins編 -
Xcodeの管理を楽に - Jenkins編 -
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
コードレビューをより良くする Danger x Android
コードレビューをより良くする Danger x Android
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
DeNAにおけるSWETの役割
DeNAにおけるSWETの役割
クラウド活用で実現する、開発・保守の効率化
クラウド活用で実現する、開発・保守の効率化
サーバーレスの話
サーバーレスの話
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
ここが良かったDatadog
ここが良かったDatadog
[CTO Night & Day 2019] ML services: MLOps #ctonight
[CTO Night & Day 2019] ML services: MLOps #ctonight
スマートフォンWebアプリ最適化”3つの極意”
スマートフォンWebアプリ最適化”3つの極意”
Xamarin概要と活用方法
Xamarin概要と活用方法
某S社のddd(メイリオ)
1.
某 S 社
の DDD -どうしてこうなった駆動開発- @kumake1004
2.
自己紹介 名前@kumake1004 ‒ Sansan 株式会社
アプリケーションエンジニア ‒ 2011年入社 (5年目) 仕事 ‒ 法人向け名刺管理アプリのサーバーサイド実装 ‒ アプリエンジニアとインフラエンジニアの板挟みにあうこと 興味 ‒ .NET (C#) / DDD / テスト / マネジメント
3.
どうしてこうなった駆動開発とは 職場で DDD 導入したら失敗しました ‒
(個人の感想です) 再挑戦を始めたところ、、、 ‒ 漠然と思いはあって、良い機会なので振り返って言語化します ‒ という普通の失敗事例紹介 つまりただの出オチ
4.
- 実践ドメイン駆動設計 コアドメイン
(スクラム) における集約の使用 “彼らには DDD の経験があまりなかった。そのため、チームは DDD に関 してちょっとした間違いを犯した。” “最終的に彼らは、自分たちが集約を扱った経験を糧にして成長した。私達も 同じように成長できるはずだ。彼らの悪戦苦闘ぶりから学び、自分たちのソ フトウェアを作るときに同じ状況に陥らないようにしよう。”
5.
DDD 導入の背景 名刺管理 Web
アプリケーション ‒ C# / ASP.NET / PostgreSQL 他 ‒ 生まれて 8 年なので色々つらい(トランザクションスクリプトはやだ!) ‒ もっと早くて質の良いソフトウェアを開発できないか? どうやって? ‒ 3 年くらい前に大きな新機能追加がきた ‒ この機会に設計や実装を見直そう ‒ DDD っていうのがあるらしい。流行ってる
6.
DDD どうだった? 導入に失敗した ‒ (個人の感想です) どうなった? ‒
仕様を読み解くのが大変 ‒ 以前に比べて生産性が下がった ‒ 品質も特に上がってない
7.
DDD どうだった? いいこともある ‒ 実装の共通化への意識は上がった気がする ‒
レイヤの役割は以前より明確になった ‒ まれに生産性が大きく上がることがある
8.
失敗の原因 まぁ勉強不足 ‒ 正しいけど話終わっちゃうので ‒ 以降の話はいったんこれを忘れてお聞きください
9.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
10.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
11.
ひとつのモジュールに詰め込みすぎた 事象 ‒ 全部同じ名前空間 ‒ 文脈が分からないので使っていいか分からず、もしくは普通に見つからず再 利用が進まない ‒
勇気を出して使うとある日突然全く関係ない(と思った)修正でバグる 原因 ‒ ドメインモデル(図)を書かないから境界が分からない ‒ 再利用の可能性を捨てきれない(お前が思っているほど汎用的ではない)
12.
ひとつのモジュールに詰め込みすぎた 反省 ‒ とにかくドメインモデル(図)を書く ‒ 再利用は(いったん)忘れる ‒
分けすぎは(多分)「継続的な統合」でなんとかなる ‒ 分けなさすぎを分けるのは大変 • 影響範囲とか
13.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
14.
ユビキタス言語やモデル(図)がない 事象 ‒ 文脈が読み取れないので影響範囲が分からない ‒ ドメインエキスパートが加わらない
= 実装者の視点になってしまう ‒ 実装視点になる =「意図の明白なインタフェース」にならない 原因 ‒ 面倒(実際面倒) ‒ ドメインエキスパートが嫌がる ‒ チームメンバーも嫌がる
15.
ユビキタス言語やモデル(図)がない 反省 ‒ 自分だけのものでよいので作る ‒ WHY
を説明してもイマイチ ‒ それより、しつこく図を使って、価値があることを分かってもらう • 何か話す時には図を見せながら説明する • 何か質問されたらとりあえず図を出して考えるふりをする(実績あり)
16.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
17.
リポジトリだけ頑張りすぎた 事象 ‒ 高度な抽象化と汎用性を兼ね備えた高機能リポジトリ ‒ Entity
Framework を想像してもらったら大体合ってます ‒ 自分たちで作ってしまったので、リポジトリ追加するときが苦行
18.
19.
リポジトリすごい 上手く流用できると ‒ かなり便利で生産性も上がる 裏はどんな実装なのか? ‒ 式を全て
Expression で保持 ‒ SQL 発行直前に、Expression から自分で SQL 構築 ← え?
20.
SELECT 文の作成処理 ‒ つらい リポジトリがあまり作られない ‒
楽をするためにリポジトリラッパーが氾濫 • HogeGetService クラス ‒ どうしようもないときは既存クラスを拡張 • さらに巨大に ‒ つらい
21.
リポジトリだけ頑張りすぎた 原因 ‒ ひとつの集約や Entity
に関わるテーブルが多すぎる ‒ インフラ層の課題をインフラ層で解決しなかった • Entity Framework 使えない • SQL が複雑で、複雑な抽出条件をもらわないとデータアクセス出来ない、速度出ない 反省 ‒ 集約や Entity は小さく • Unit Of Work、結果整合性 ‒ インフラ層の課題をドメインモデルに寄せない • SQL リファクタリング、SQL チューニング、キャッシュ
22.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
23.
遅い 事象 ‒ 遅ォォォォォいッ説明不要!! ‒ 具体的には
Entity の復元が遅い 原因 ‒ ひとつの集約や Entity に関わるテーブルが多すぎるので SELECT 遅い ‒ キャッシュしてないので SQL の発行回数が多い ‒ リフレクション
24.
遅い 反省 ‒ DDD はインフラ層の問題を解決しない ‒
CQRS、キャッシュを検討する ‒ リフレクションによる自動化ではなく、テンプレートによる自動化 ‒ 集約や Entity を小さく保つ
25.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
26.
大きく始めた 事象 ‒ 全実装の 1/5
がいきなり DDD に ‒ 失敗の予感を感じても方向転換したり引き返せない ‒ 今更違う設計にもできず、負債を産む機械になってしまった 原因 ‒ レガシーを憎みすぎた ‒ 自分たちの力量を客観視できていなかった
27.
大きく始めた 反省 ‒ 始めは小さく、段々大きく ‒ レガシー、意外といいやつじゃん •
「Sansan はレガシーでよかったんですよ!」発言(実話) ‒ DDD にすべき箇所とそうでない箇所がある
28.
やらかし一覧 なんでもサービスにしてしまった ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
29.
その他 万能 Service ‒ 実装場所に困ったら
Service ‒ 困って無くてもとりあえず Service
30.
その他 ドメインモデル貧血症 or Fat
Model ‒ サービスが万能過ぎて実際やることない ‒ 意識高い系 Entity (超でかい)
31.
その他 お?Value Object ってフォルダがあるな。。。 ‒
開いて見てみる ‒ Value Object じゃなかった _人人人人人人人人人人人人人人_ > Value Object じゃなかった <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ^Y ̄
32.
まとめ
33.
どうしてこうなった Iterative に作らなかった ‒ DDD
ってこういうことねで実装 => 振り返りがないので間違いに気づけな い レガシーの課題を継承してしまった ‒ 新しい仕組みに気をとられて、レガシーの問題を整理できなかった ドメインモデル(図)を作らなかった ‒ ドメインエキスパート視点での関心事を明確に出来ない ‒ メンタルモデルと実装が結びつかないので冗長になっただけ
34.
どうしてこうなった、からの 基本に忠実に、振り返りながら ‒ 特にドメインモデル(図)を必ず作る • 面倒だけど絶対に役に立つ。上手く出来なくても過程だけでも大事 ‒
小さく始める 適用範囲を絞る ‒ レガシーも一概に悪ではない 失敗から学ぼう ‒ どうしてこうなった?と思ったときはある意味チャンスでもある ‒ ささいな失敗経験の積み重ねが応用に活きてくるので、みんなも失敗事例を共有してください
Download now