LADRのすすめ＆先行技術検証PRJの紹介 / Introducing-LADR-and-Technology-verification

by moomoo-ya

Slide 1

Slide 1 text

#RAKUSMeetup 新サービス立ち上げ時の技術選定と、サービス立ち上げに向けたラクスの取り組み（仮） 2020.8.25 RAKUS Meetup Aug. Isamu Suzuki

Slide 2

Slide 2 text

#RAKUSMeetup 新サービス立ち上げ時の技術選定と、サービス立ち上げに向けたラクスの取り組み（仮） 2020.8.25 RAKUS Meetup Aug. Isamu Suzuki 長い

Slide 3

Slide 3 text

#RAKUSMeetup LADRのすすめ＆先行技術検証PRJの紹介 2020.8.25 RAKUS Meetup Aug. Isamu Suzuki

Slide 4

Slide 4 text

#RAKUSMeetup 鈴木勇 / Isamu Suzuki ● 2013年にラクスへ中途入社 ● ガンプラ部部長 ● 先行技術検証とかアーキテクチャ選定とか技術イベント司会とか ● 上流から下流まで経験済み PjM含むフルスタック系 ● C/Java → JavaScript → Python/TypeScrpt ● 自宅にNuro光開通した ● 約10年ぶりに自転車買った ● Fat Project作者

Slide 5

Slide 5 text

#RAKUSMeetup 今日話すこと ● アーキテクチャ選定時にやると少し幸せになれること ● 新規サービス立ち上げに向けてどんな活動をしているか

Slide 6

Slide 6 text

#RAKUSMeetup 新サービスのアーキテクチャ選定

Slide 7

Slide 7 text

#RAKUSMeetup 2018年楽楽労務立ち上げ

Slide 8

Slide 8 text

#RAKUSMeetup

Slide 9

Slide 9 text

#RAKUSMeetup このときの社内の様子 ● 東京拠点の開発言語は主にJava ※ ● FWはSeasar2 ○ 新しめのサービスでも 2012年以前に開発開始 ● モノリシックアーキテクチャ ● インフラはオンプレミス ↑こうしている理由は長くいる人が　経験で何となく把握している感じ ※大阪では主にPHPを使っています

Slide 10

Slide 10 text

#RAKUSMeetup なんにせよ

Slide 11

Slide 11 text

#RAKUSMeetup 新しい技術を導入したりしなかったりすることになる新しい技術を導入したりしなかったりすることになる

Slide 12

Slide 12 text

#RAKUSMeetup 「導入しなかった」記録を残したい ● 「導入したもの」は後に残るので記録しなくても残りがち ● 「導入しなかったもの」は後から見るとわからないことが多い ○ 検討はしたのか？ ○ 検討の上でなぜ導入しなかったのか？ ○ 今後も導入すべきではないと判断したのか、その時点の事情なのか

Slide 13

Slide 13 text

#RAKUSMeetup LADR Lightweight Architecture Decision Records

Slide 14

Slide 14 text

#RAKUSMeetup ● ADRは米Sabreの Michael Nygard氏発案 ● ThoughtWorks社の Technology Radarで紹介 ● 技術要素を4段階評価 ○ Hold：慎重に ○ Assess：よく調査して ○ Trial：挑戦の価値あり ○ Adopt：採用を推奨 https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records

Slide 15

Slide 15 text

#RAKUSMeetup ● 2017年11月にAdoptに昇格 ● 要約すると ○ 重要なアーキテクチャーの意思決定を、その文脈や結果とともに記録するためのテクニック ○ WikiやWebサイトではなくコード管理に含むことを推奨 ○ ほとんどのプロジェクトで採用しない理由がない https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records

Slide 16

Slide 16 text

#RAKUSMeetup Lightweightなのでやることはかんたん ● ADRのフォーマットを決める ● アーキテクチャ選定の意思決定 ● フォーマットに従って記録 ● ソース管理（gitなど）に格納

Slide 17

Slide 17 text

#RAKUSMeetup . . .

Slide 18

Slide 18 text

#RAKUSMeetup 要領わかんないし、フォーマット決めるのが面倒

Slide 19

Slide 19 text

#RAKUSMeetup 公開されているテンプレート ● joelparkerhenderson / architecture_decision_record ● deshpandetanmay / lightweight-architecture-decision-records ● peter-evans / lightweight-architecture-decision-records ● jgreeners / LADR ※英語のものしか（たぶん）ないので　頑張って読みましょう https://github.com/peter-evans/lightweight-architecture-decision-records

Slide 20

Slide 20 text

#RAKUSMeetup . . .

Slide 21

Slide 21 text

#RAKUSMeetup 何を記録すればよいのかニュアンスがわかりにくい

Slide 22

Slide 22 text

#RAKUSMeetup ご用意いたしました

Slide 23

Slide 23 text

#RAKUSMeetup moomoo-ya / LADR-template ● 完全日本語版 ● 何を書くべきなのかを記載 ● もちろん各自カスタムしていくとなお良きかと ● 使いやすいMITライセンス ● https://github.com/moomoo-y a/LADR-template

Slide 24

Slide 24 text

#RAKUSMeetup

Slide 25

Slide 25 text

#RAKUSMeetup で、役に立つの？

Slide 26

Slide 26 text

#RAKUSMeetup 2018年から 1年半ほど経った 2020年1月

Slide 27

Slide 27 text

#RAKUSMeetup グループ企業のアーキテクチャ選定 ● サービスのソフトウェアリプレイス的な計画 ● 「マイクロサービスにするべきかどうか」「コンテナの利用はどうか」 ○ 聞き覚えのある検討項目

Slide 28

Slide 28 text

#RAKUSMeetup やってました

Slide 29

Slide 29 text

#RAKUSMeetup ※注意※ 今回のケース） 1年半経過 → 判断をそのまま流用していけない「議論のスタート地点を前にずらす」イメージこの手の議論は想像以上に時間がかかるので少しでもショートカットできるのは嬉しい

Slide 30

Slide 30 text

#RAKUSMeetup LADR の Pros / Cons Pros ● 選定理由が記録に残る ○ 通常1年後には忘れている ● 相談されたときに楽 ○ 「あそこにあるよ」で済む ● 新規メンバーの疑問解消 ● 軽量だから更新が続く ● 経緯を知った上で判断が出来る Cons ● 記録するのがちょっと手間 ○ しかし大した手間ではない ● “LADR”が発音しにくい ○ 今日も何度も噛んでます

Slide 31

Slide 31 text

#RAKUSMeetup 新サービス立ち上げに向けた日々の取り組み

Slide 32

Slide 32 text

#RAKUSMeetup そもそも新サービスの立ち上げは忙しい

Slide 33

Slide 33 text

#RAKUSMeetup 理想と現実流行りのフレームワーク話題の言語最新のツールイケてる設計手法改善された開発プロセスいつからマネタイズできますか？

Slide 34

Slide 34 text

#RAKUSMeetup 新サービスの立ち上げは忙しい ● リリースするまではコストにしかならない ● 最低限の機能（MVP）でいち早いリリースが求められる ● 「ノウハウのある技術で」となりがち ● そもそも技術面より業務要件まとめる方が困難＆優先

Slide 35

Slide 35 text

#RAKUSMeetup 開発の未来に先手をうつプロジェクト 2017年2月ごろから　　かいはつのみらいにせんてをうつ「開発の未来に先手をうつ」かみせんプロジェクトとしてプロジェクトが始動（命名は後日つけました）

Slide 36

Slide 36 text

#RAKUSMeetup 何やるの？ ● 今後使う見込みの技術を先行検証するプロジェクト ● サービス横断的に選抜した4名でスタート ○ 途中で1名追加参加 ● 半期ごとに1テーマ、毎週5時間 ● サービスへの導入を想定して検証 ● ラクスは複数サービスあるので個別にやるとコスパが悪かった

Slide 37

Slide 37 text

#RAKUSMeetup 発足の経緯技術の更新やらんとあかんよなやりましょう利益もあがってるしね現場は漠然とした不安感は持っていた経営層からのオーダー

Slide 38

Slide 38 text

#RAKUSMeetup ３年経って……順調に拡大中 ● 「かみせんプロジェクト」→「技術推進プロジェクト」に改名 ● プロジェクトを推進する担当部署が設立 ● 参加メンバーも10名を超えました ● テーマも複数テーマを並行して検証を進めています

Slide 39

Slide 39 text

#RAKUSMeetup 最近の成果はテックブログで公開中 https://tech-blog.rakus.co.jp/archive/category/かみせん『マイクロサービスアーキテクチャにおけるサービス分割の難しさ』『失敗しない機械学習プロジェクトの進め方入門』

Slide 40

Slide 40 text

#RAKUSMeetup 宣伝

Slide 41

Slide 41 text

#RAKUSMeetup 明日はフロントエンドLT会司会します Gatsby.jsテーマについて話します

Slide 42

Slide 42 text

#RAKUSMeetup Thank ☺ you ● アーキテクチャ選定時は記録を残そう ○ LADRはいいぞ ○ 割とすぐに活用される ● 新サービス立ち上げに向けて備えをしよう ○ 見えてからでは間に合わない（ことが多い）