Rakuten Technology Conference 2019 @Nagoya

1. 楽天市場で使われている技術、
エンジニアに必要なコアスキルとは
Nov 9, 2019
Makoto Kawamura
EC Marketplace Development Dept.
Rakuten, Inc.

2. 2

3. 3
河村 真
• 楽天株式会社 ECマーケットプレイス開発部
ヴァイスジェネラルマネージャー
• 「楽天市場」サービスのアーキテクチャおよび次世代
プラットフォームの開発推進を担当
• 略歴
• ソニー株式会社（ソフトウェアアーキテクト）
• ソニー・エリクソン・モバイルコミュニケーションズ
株式会社
（現ソニーモバイルコミュニケーションズ株式会社）
（欧州赴任中、Director, Head of Global Software
Architecture）
• シンプレスジャパン株式会社（日本支社CTO）
• 2018年3月に楽天株式会社に入社
Makoto Kawamura
Vice General Manager,
EC Marketplace
Development Department,
Rakuten Inc.
Joined Rakuten in 2018
after experiencing CTO of
EC start-up and various
management roles in large
scale software
development organization
in MNC. Currently
responsible for architecture
and next generation
platform development of
Rakuten Ichiba service

4. 4
楽天市場で使われている技術

5. 5
楽天市場って
• 楽天グループの主要サービスの１つ / One of flag ship service in Rakuten Group
[楽天株式会社・企業情報・2019/10/13・https://corp.rakuten.co.jp/about/ ]

6. 6
楽天市場って
• インターネット通販No.1 / Japanese E-commerce No.1
[楽天市場への出店・開業案内・2019/10/28・https://www.rakuten.co.jp/ec/detail/?l-id=PC_top_1_mission_to_2_detail ]

7. 7
楽天市場って
• ４万店舗 / 40k shops
• ２億商品 / 200mil items
• 月33億PV / 3.3bil PV
• 〇兆円の年流通額
N-trillion JPY GMS
月間ページビュー数
[はじめての楽天市場・2019/10/13・https://event.rakuten.co.jp/beginner/ ]
[楽天市場への出店・開業案内・2019/10/13・https://www.rakuten.co.jp/ec/ ]
[楽天市場への出店・開業案内・2019/10/13・https://www.rakuten.co.jp/ec/compare/?l-id=PC_top_1_mission_to_3_compare ]
[2018年度通期及び第４四半期決算説明会・2019/2/12・http://corp.rakuten.co.jp/investors/assets/doc/documents/18Q4PPT_J.pdf ]

8. 8
楽天市場って
• でも使っているのは、ごく普通の言語・フレームワークです！
However we are using very standard languages and frameworks

9. 9
楽天市場って
• それなりに新しい技術も取り入れていますが、それでも超最先端ではありません
We use some new stuff but still standard ones, not looking cool?

10. 10
それに
• 楽天って自前主義？ Is Rakuten style all-by-ourselves-ism?
• 良く言われます..。 Yeah, we are frequently called so..
• そういう面もあります。Yes, somehow..
• 自前データセンター、自前クラウド…
• Public Cloudも使っていますが、主要サービスは自前DCです..
• We have our own data centers, cloud for main services
• We partially use public cloud but our main services are run on our own DCs

11. 11
なぜ？
• サービスの規模や性質によって、求められる作り方が
変わる Development style depends on size and characteristics of service
Mission Critical
(Service)
Experimental
(Service)
AvailabilitySpeed
スタート
アップ
（一般論）
楽天市場のよ
うに社会基盤
に近いもの
宇宙・医療な
ど間違いの許
されないもの
Reliability
新しい技術 枯れた技術安定運用できる技術
楽天グループ
にはここに属
するサービス
もある
New Technology Stable Technology Extremely Stable Technology
Mission Critical
Infrastructure
such as our serviceStartups

12. 12
なぜ？
• 求められる非機能要件のバランスも変わる
Non functional requirements and those importance also depend on size and characteristics of service
Availability
Performance Scalability
Reliability
Security
Maintainability Configurability
Portability
Usability
Efficiency
Auditability Recoverability

13. 13
最近話している話…
• Couchbase よさそうだね..
• 数百台くらいはクラスタ組んでテストしようか..
• 基幹サービスに使うならソースレベルで直せるエンジニ
アを雇うか育てないといかんかね..
(API Gateway
service)
(Document oriented
NoSQL DB)When we evaluate open source software we usually do extremely heavy load test no other company doing.
Also we usually don’t use as key component unless we hire engineer to maintain its code base.
One learning from specific open source module is enterprise edition has inferior performance than community edition.
This is found out in our load test and we decided to use community edition and develop missing functionality by ourselves.
• Kong
• うちのユースケースでは Community Edition のほうがパ
フォーマンスが良かった
• Enterprise版で欲しかった機能は自社開発すっかなぁ

14. 14
楽天の自前主義
• 楽天の自前主義とは
• 何かあったらすぐ直せるようにしておくため
• すぐ直せるように、使う道具は信頼に足るものを選ぶ
• 信頼に足るものがなければ、自分で作ることも時にはある
Rakuten’s “all-by-ourselves-ism” is intentional because our first priority is preventing service interruption by
all means. Thus we don’t use software components without thorough tests and without securing way to
trouble shoot. We avoid having uncontrollable external dependencies on our main services.
• すべてはビジネス（店舗様＋お買い物をするお客様）のため
• 楽天市場を落とさない！
障害がおきても、誰にも頼らず自力で素早く復旧する！

15. 15
落とさないための徹底的な対策
いかに早期（秒単位）に検知、回復させるか。
CDN SLB Frontend API DB
KVS
External
System
External
API
Queue
Frontend
Web
Server
API
Change TTL
Limit # of sessions
Route to static
contents
Limit QPS
Cut API
connection
Data Queuing
Switch over
Blue/Green
Increase instances
Restart
servers
お買い物の継続が最優先。外部要因であれば、機能を切り捨てる。
How to detect early and decide what actions are needed.
If external service is causing trouble, we cut them by compromising functionality

16. 16
これを継続して行う
• Analysis of past troubles
• Change management
• Load tests
• Monitoring / Detection
• Preparing various scenarios
• Assignment / Shift planning
• Training of trouble shooting
• Decision making and reporting
procedure
分類
過去のトラブルの原因分析と対策
システム変更点のトラックとレビュー
負荷テストシナリオ見直し
監視・検出方法の再確認
トラブル想定し対応シナリオ整備
当日の分担確認
トレーニングと予行演習
決定者・伝達方法・レポート
第XX期の施
策
次期へ申し送り
事項

17. 17
落とさないために必要な技術
• 自モジュールの既存コードや設計のしっかりした理解
• 周辺システムの理解（表層的のみならず使う上での留意点）
• ネットワークやインフラなどプログラムが動く環境の基本的な知識
• 新規設計の場合は、利用する部品の徹底したテストと評価
• ニーズのはっきりしない拡張性などエンジニアの自己満足に陥らない自制力
• 議論を通じて目的を理解・深堀りしそれを満たすシンプルな仕様や設計の発見力
• 他者にレビューしてもらう謙虚さと慎重さ
• 何をテストしないといけないかを考えだす観点抽出力
• 起こりうる問題・障害を考え予測する力
• 他チームに与える影響を考え、もれなく洗い出す力
Solid understanding source code and design
Understanding of surrounding sub-systems which interaction is requires (API and its behavior)
Basic knowledge of network and infrastructure which software is working on
Through test of software module we source externally
Avoid subjective wish to create ‘beautiful’ software. Typically extensibility which will never be used
Ability to keep simplicity on requirement and design through discussion on purpose of the work
Sincerity and carefulness utilizing review from other team members
Ability to define test strategy
Ability to list up possible problems and troubles beforehand based on experience
Ability to list up all affect to other modules/services

18. 18
落とさないために必要な技術
• 必ず考える、パフォーマンス
• 必ず実施する、ネガティブテスト
• 必ず考える、ロールバック案
• 必ず考える、モニタリングとアラートの実装
• 必ず考える、データリカバリーシナリオ、ツール、予行練習
• 他チームとの連絡・連携（ネットワークチーム、サーバインフラチーム、DBAチーム、サービ
ス・アプリチーム、事業、店舗様担当、ベンダー様担当、コールセンター）
これらをチーム作業できっちりやる能力！
コードはこれらを結実させた最終成果物です！！
Always consider performance
Always conduct negative testing
Always have a plan for roll back
Always implement monitoring and alert system
Always prepare data recovery procedure and toll, then practice
Always connect and synchronize with related teams such as network, infrastructure, DBA, business, vendors and call centers)
Ability to complete those tasks as a team. Code is not just a code but a final output all of those efforts and consideration

19. 19
落とさないために必要な技術
• もちろん、言語やフレームワークについての知識・経験も必要
ただし
• 言語やフレームワークは道具であって、トレンドは変わっていく
• 経験年数だけでは測れない
だから
• 言語によらない基礎をしっかり習得しておく
• Peer Reviewや優れたコードを読み込むことによって、その言語での洗練された書き方を学ぶ
• その言語やフレームワークがもたらした「新しい考え方」があれば習得する
• 実務で使う（前述のようなマインドを持って仕事をする）
• 必要に応じて（固執しないで）別の言語に進む
Skills and knowledge around each programming languages are necessary but popular language changes time to time.
Then it is important to learn basics which is programming language agnostic as well as new concept each new language introduces.

20. 20
言語によらない基礎
• 変数、制御構造、スコープ
• 型、比較、浮動小数点
• 関数、無名関数、ラムダ式
• 同期・非同期、例外
• 可読性、Coding Standard
• アルゴリズム、データ構造
• オブジェクト指向
• イベントドリブン
• 乱数、ハッシュ、証明書、暗号、モード
• Session、Cookie、HTTP Status Code
• メモリ、I/O、ネットワークの速度感覚
• メモリ、ディスクの使用量感覚
• プロセス、スレッド、GC
• シェルスクリプト、linuxコマンド
• VM、コンテナ
• MVC、DI、ステートレス
• マイクロサービス、BFF
これで全部ではありませんが..
Variables, Control flow, Scope
Type, Floating point
Function, Anonymous Function, Lambda Function
Synchronous, Asynchronous, Exceptions
Readability, Coding Standard
Algorithms and Data Structure
OOP
Event Driven
RNG, Hash, Certificate, Cypher, Mode
Session, Cookie, HTTP Status Code
Speed difference of memory, I/O, Network
Usage of local resource such as memory and disk
Process, Thread, GC
Shell scripting, Linux command
VM, Container
MVC, DI, Stateless
Micro service, BFF
This is not exhaustive list ..

21. 21
成功のための積み重ね
ビジネスでの結果
コード
言語によらないソフトウェア技術
サービスを開発をする上で必要な考え方・信念・視点
特定の言語やフレームワークの知識・経験
楽天市場では
特に「落とさない」
という強い意志と視点
「楽天市場」の開発では特
に土台の力を鍛えられる
日本のインフラの一部を
担う自負を持って
Code Assets
Achievement in business
Skills in specific programming language
Guiding principles of each services or company
Basics which is language agnostic
In Rakuten Ichiba service development, people learn solid professionalism. We also share responsibility and
high pride of running nation wide services which is now part of Japan’s social infrastructure.

22. 22
ソフトウェアエンジニアが活躍するために重要なコアスキル

23. 23
ソフトウェアエンジニアが活躍するために重要なコアスキル
• ソフトウェアが本質的に抽象思考の産物で、早いスピードで進化しているから
• ビジネスのスピードは速くなり、チームは小さくなり、メンバーとの密な共同作
業が重要だから
何を どのように
学ぶ！を で
抽象的思考能力
「知識」と
「経験」の
繰り返し
コミュニケーション能力
1
2
3
Core skills needed for
software engineers
/ What / How
Abstract Thinking
Communication Skills
Cycle of
“Knowledge”
acquiring and
“Experience”
acquiring
As software is essentially abstracted concept and its concept is rapidly evolving.
As speed of business and popularity of small sized team require tight corroboration
with members

24. 24
抽象的思考能力

25. 25
抽象的なものの例
E=mc2
ちょっと極端な例ですが..
This is extreme example though…

26. 26
• フレームワーク
• よくある説明
• 自分が呼ぶのはライブラリ、
自分を呼んでくれるものがフレームワーク
• 先輩アーキテクトの説明
• 何もしない何か ができる。そして、中身以外の全ての必要な事をしてくれるもの
• 何もしないアプリができる。アプリの中身以外の全ての必要な事をしてくれるもの
• アプリの中身だけに集中するための仕組み
• そのために徹底的に、中身以外を切り出し、仕様や機能を洗練化させ、どんなアプリからで
も使えるように結晶化させた
抽象的思考の例
Library
My code
Framework?
App framework generates an app which does nothing. i.e. frameworks enable us focusing on content of app. Framework is invented by
deeply thinking what is content of app and what are not. This is very difficult work of abstracting.
Framework

27. 27
Min. 50
Customers
• A/Bテスト
• よくある説明
• 複数のバージョンのWeb Pageや
アプリを同時にdeployして、
どちらのconversionが高いか試すテスト
• 先輩マーケッターの回答
• 「顧客が実際に買うかどうか見てみることによって
しかニーズはわからない」という考え方で行うあらゆる試行作業
• つきつめると、実際に開発しなくても「売ってみる」ことはできる
• 上記は、楽天市場ではやってはいけないが、クラウドファンディングサイトでは可能
抽象的思考の例
1,500
Order
Min. 50
Customers
1,500
Order
Min. 50
Customers
1,500
Order
Cancel Cancel Sell
In abstract thinking, A/B test is not just testing of multiple version of web page. All trial and error based on philosophy of “we never know
what customer wants except for test if they really push the button”. So we can sell before it is produced (e.g. in cloud funding program).
A/B Testing

28. 28
抽象的なものの例
• コールバック
↓
• Promise (ES2015~)
↓
• Async/Await (ES2017~)
関数
↓
関数ポインタ
↓
関数オブジェクト
↓
クロージャ
無名関数
↓
アロー演算子

29. 29
抽象的思考能力
• ソフトウェア開発の歴史
• 単純計算から複雑な事象のハンドリングができるように
• コードだったら、今まで数百行は書かなければならなかったものを１行で
• 天才達により、部品化、共通化、単純化、発想の転換、新しい概念の創出
• どんどん出てくる新しい「概念」に追いつけるかどうかが、技術を最先端に使い
こなせるか
• ビジネス・サービスも同じ
Software is purely conceptual so genius can create innovation using highly abstracted concept. How fast engineer can understand and
use such up to date innovation is key. Business and service are also conceptual so we can consider in the same way.

30. 30
我々は作る人？使う人？
Software
Developer
Software
User
Most of
Software
Developers
Industry Top Engineers
新しい概念を
作り出して
くる天才達
天才達が編み
出した概念や
部品を使って
システムを組
み上げていく
職人たち
職人たちが作った
システムを使って
便利な生活を送る
人たち
システムを
作る職人た
ち
We develop software to be used by many user. So we seem to be creators. But most of software techniques are developed by small
number of industry top engineers and we are just using those.

31. 31
我々は使う人かもしれないが
上から降ってくる新しい概念を即座に理解し、
開発業務やビジネスの効率化や高度化につなげていく能力
Software
Developers
自分で世の中に役に立つ新しい概念を思いつけるかもしれない
ソフトウェア技術者としての基礎スキル
（言語によらないCSの知識、
特定の言語での実装スキル、
テスト・運用・品質などのデリバリースキル）
Engineers should have basic skills, then develop an ability to understand and use abstract concept invented in industry as fast as
possible, and lastly aim to become top level engineers to invent evolutional concept.

32. 32
コミュニケーション能力

33. 33
コミュニケーション能力
• おしゃべりであれ、というわけではない
• （営業職のように）うまくしゃべれ、といっているわけではない
• でも、チームで１つのものを作らなければならない
You don’t have to be talkative.
You don’t have to able to be sales person.
But we need to communicate well to create a product as a team.

34. 34
コミュニケーション能力
• チームとして一体化した成果を出すための「コミュニケーション」
• 相手の意図をしっかり理解できるか、自分の思っていることを伝えられるか
• 「そういう意味だとは思わなかった」
• 「思っていたけど、言わなかった」
• 「言わないでも大丈夫だと思っていた」
• 「あの時言ったのに」
単に時間のロスだけでなく
ひどい場合は
プロジェクトの失敗や
組織の崩壊を招く
Key is how one can clearly explain one’s and know another’s understanding, intention, opinion, confidence, estimate and other thinking.
“I thought you already understood”, “I did not think I need to say”, “I am not sure you’ve understood, but I actually meant it”.. Those will not
only waste time but also make disorder in project and organization. How you can avoid this mentality and communicate clearly and
proactively..

35. 35
コミュニケーション能力
• 知らない、経験ないは恥ずかしくない（のではっきり言う）
• 素をだして良い。自分を曲げる必要もない。正直がよい
• さらけだす勇気は必要
• 今聞いたことでももう一回聞くことは恥ずかしくない
• 一度言ったから伝わるなんて思っちゃいけない
• 「もったいないコミュニケーション」をなくそう
• 仕事をスムースに分担できるようにして、チームのスピードを最大化させよう
あうんの呼吸が
作れるまでは、
何度でも聞く、
何度でも言う。
Over
Communicate !
Be rather simple person in communication not complex or hard-to-understandable. Ok to say “I don’t know”, “No experience”, “Please repeat”.
People don’t understand if you speak once so you need to repeat. Let’s kill those “unnecessary loss” and maximize the speed of team.

36. 36
どうやって体得するか

37. 37
どうやって体得するか？
知識と経験は両輪
• 知識を学んでも、実際に自分でやってみないと（ダメ出しされないと）実感として理解できない
• 知識を学んであれば、実際に経験したときに「あ、これはこういうことか」と実感で理解できる
• 逆に知識を持っていないと、折角経験しても、整理できず後で活用できる経験として残らない
言うは易く、体得するのは難しい
知識の例：
設計の大原則
• 小さく単純なBuilding Blockを組み合わせて、大きく複雑なものを作る
• Decoupling（ソフトウェア、プロセス、ビジネス…）
Knowledge from book or advice from others are precious as they are developed using so long time. Until you try and “feel” it, it will not
become your skill. Best timing is when you try then fail and when someone tells you why you failed referring the knowledge. Repeat the
process of “learn, try, fail and understand” in order to convert knowledge to your skill you can actually use.

38. 38
どうやって体得するか
• 学ぶ「知識」を選ぶのは比較的簡単
• 経験できる「リアルな仕事・プロジェクト」は、あまり選べない
• 今やっている仕事・プロジェクトを通じて「経験⇔知識」サイクルを回す
• 普遍的なことは、他のプロジェクトでも使える
• 勘は研ぎ澄まされて、他のプロジェクトでもすぐ気づけるようになってくる
You can choose what knowledge you will learn (like you can choose books to read). But it is hard to choose what project (=real experience)
you can try knowledge on. So all you can do is run “learn and try” cycle on your current assigned project. But many of skills are general
enough you can apply many projects. And the more you get skill, the your perception is sharpen up, so that you will understand the essence
of the things in quite good speed.

39. 39
の皆さんへ

40. 40
の皆さんへ
• 複数の会社を経験するのがおすすめ
• 大きい会社と小さい会社、両方の経験があると良い
• 大きい会社では、大きなプロジェクトの経験と、いろいろな「仕組み」を
• 小さい会社では、自分の力を試し、スピードや決める力を
• 職種を意識すると良い（エンジニア、プロジェクトマネージャ、プロダクトマ
ネージャ、ピープルマネージャ）
• 専門知識を習得した人材が、業界内で循環・交流することが
日本のソフトウェア産業全体を盛り上げるために重要！
My recommendation is to have working experience in multiple companies, preferably both in large and small companies. You can learn
systematic way of doing business in large company and you can learn speed and importance of decision in small companies.
Also I believe it is valuable for (Japanese) software industry by creating circulation of talents as it pushes up level of the work nation wide.