Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills needed for software engineers

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 41 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie 楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills needed for software engineers (20)

Anzeige

Weitere von Rakuten Group, Inc. (20)

Aktuellste (20)

Anzeige

楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills needed for software engineers

  1. 1. 楽天市場で使われている技術、 エンジニアに必要なコアスキルとは Nov 9, 2019 Makoto Kawamura EC Marketplace Development Dept. Rakuten, Inc.
  2. 2. 2
  3. 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. 4 楽天市場で使われている技術
  5. 5. 5 楽天市場って • 楽天グループの主要サービスの1つ / One of flag ship service in Rakuten Group [楽天株式会社・企業情報・2019/10/13・https://corp.rakuten.co.jp/about/ ]
  6. 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. 7 楽天市場って • 4万店舗 / 40k shops • 2億商品 / 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年度通期及び第4四半期決算説明会・2019/2/12・http://corp.rakuten.co.jp/investors/assets/doc/documents/18Q4PPT_J.pdf ]
  8. 8. 8 楽天市場って • でも使っているのは、ごく普通の言語・フレームワークです! However we are using very standard languages and frameworks
  9. 9. 9 楽天市場って • それなりに新しい技術も取り入れていますが、それでも超最先端ではありません We use some new stuff but still standard ones, not looking cool?
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22 ソフトウェアエンジニアが活躍するために重要なコアスキル
  23. 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. 24 抽象的思考能力
  25. 25. 25 抽象的なものの例 E=mc2 ちょっと極端な例ですが.. This is extreme example though…
  26. 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. 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. 28 抽象的なものの例 • コールバック ↓ • Promise (ES2015~) ↓ • Async/Await (ES2017~) 関数 ↓ 関数ポインタ ↓ 関数オブジェクト ↓ クロージャ 無名関数 ↓ アロー演算子
  29. 29. 29 抽象的思考能力 • ソフトウェア開発の歴史 • 単純計算から複雑な事象のハンドリングができるように • コードだったら、今まで数百行は書かなければならなかったものを1行で • 天才達により、部品化、共通化、単純化、発想の転換、新しい概念の創出 • どんどん出てくる新しい「概念」に追いつけるかどうかが、技術を最先端に使い こなせるか • ビジネス・サービスも同じ 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. 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. 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. 32 コミュニケーション能力
  33. 33. 33 コミュニケーション能力 • おしゃべりであれ、というわけではない • (営業職のように)うまくしゃべれ、といっているわけではない • でも、チームで1つのものを作らなければならない 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. 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. 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. 36 どうやって体得するか
  37. 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. 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. 39 の皆さんへ
  40. 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.

×