ADRはじめました

■イベント
SansanモバイルエンジニアLT会 & 懇親会 〜春の新生活編〜
https://sansan.connpass.com/event/312187/

■発表者
Mobile Applicationグループ ⾚城 史哉

■iOSエンジニア 採用情報
https://media.sansan-engineering.com/ios-engineer

■Androidエンジニア 採用情報
https://media.sansan-engineering.com/android-engineer

Transcript

1. ADRはじめました Sansan技術本部 Sansan株式会社 技術本部 Mobile Application Group ⾚城 史哉
2. ⾚城 史哉(Fumiya Akagi) Sansan株式会社 技術本部 Mobile Application Group 前職ではAndroidアプリの受託開発に従事。 2019年にSansanに中途⼊社し、Sansan Androidアプリの開発・ 運⽤を担当。 直近数年は、Sansan Mobileアプリ開発チームのマネジメントを ⾏っている。
3. ⽬的 - Sansanで試してみた、モバイルアプリ開発におけるADR活⽤の事例を 共有する ⽬標 - 聞いている⽅の普段の開発に活きるような気づき・学びを得てもらう - 今⽇の懇親会の際に話のタネとなり、皆さんとワイワイ出来るように なる LTの⽬的・⽬標
4. - ADRとは？ - Sansan モバイルアプリ開発での活⽤事例 - ADRってアプリ開発でも有⽤？ アジェンダ（⽬標を達成するために、どのようなことを話すのか？）
5. ADRとは？
6. テキストベースの軽量なテンプレートを使⽤して、 アーキテクチャ上の設計判断を記録する。 軽量なアーキテクチャデシジョンレコード（Architecture Decision Records: ADR)は、実績のあるアーキテクチャ⼿法に対する開発者よりの アプローチだ。 設計判断を記録していく事で、それらを共有し分析することが⽤意になる。 意思決定の履歴を残すことで、現在のアーキテクチャについての コンテキストを、その過程と結びつけて提供できる そもそもADRとは何か？ ※書籍「Design It!」（O'Reilly）より引⽤
7. タイトル ADR 番号と説明的なタイトルを含める。 コンテキスト 判断がどんな状況で⾏われたかを説明する。 内容 ⾏った判断の内容を記述する。 ステータス 下書き、提案済み、承認済み、廃⽌、⾮推奨。 影響 判断がシステム、ステークホルダー、チームをどう変えるかを説明する。 ADRテンプレートの例 ※書籍「Design It!」（O'Reilly）を引⽤及び参考
8. - 設計判断をチームの責任において記録できる。 - 歴史を記録することで、設計の進化に関する展望を得られる - チーム全体を設計プロセスに巻き込める。 - ADRテンプレートを提供することで、チームメンバーのアーキテクチャ 志向を訓練できる - etc… ADRのメリット ※書籍「Design It!」（O'Reilly）を引⽤及び参考
9. Sansan モバイルアプリ 開発での活⽤事例
10. - 「なぜこの設計・ライブラリを採⽤しているのか？」という情報が ⾜りず、調査や開発に時間がかかる事が度々あった。 - Sansan Androidアーキテクチャは、 MVP -> MVVM -> Flux -> Fluxの改良版 と変遷している。 - 古い設計の画⾯を回収する際、キャッチアップコストが⾼くなる事がある - 設計や技術選定におけるレビュー・意思決定は⾏っていたが、 もっと質を向上させる余地があると感じていた。 ADRを導⼊した背景 ※書籍「Design It!」（O'Reilly）を引⽤及び参考
11. Sansan モバイルアプリ開発でのADRテンプレ
12. どのようなトピックでADRを書いているか - どのライブラリ/ツールを採⽤するか？その理由 - Mockライブラリ、Http Clientライブラリ に関して など - CIツールの選定 - 「テストライブラリの導⼊を検討したが、⾒送った」というケースも - 基盤クラスの設計 - Fluxアーキテクチャを実現するための、各基盤クラスの設計 - エラーハンドリングのクラス設計 - その他ルール等 - コーディング規約 - packageの分け⽅のルール
13. ADRを運⽤してみた感触（メリット） - レビューや意思決定の品質向上 - 強制的に判断理由を正しく⾔語化する事で、⼝頭での議論やフリーフォマットでの テキストを書くよりよい⽐較検討が出来ている - エンジニアの育成 - 「シニアなエンジニアがどのような基準で技術を選定しているのか？」 という知⾒をチーム全体で共有出来る - ADRというたたきがある事によって、エンジニア同⼠で、 新たな知⾒・観点を交換し合える頻度が上がった - 「設計を決める」というタスクの完了の定義が明確となる - 今までは「XXの設計を決める」という切り⽅をしていたが、 「誰がどう決めるのか？」が不明瞭になり、⻑期化してしまう事があった。 - 「ADRを作成し、承認を得る」と完了の定義を定める事で、 デイリースクラム等でうまく進捗していない際の軌道修正がしやすくなる。
14. ADRを運⽤してみた感触（デメリット・難しい点） - 短期的なスピードは落ちる - 質とのトレードオフになっていると⾒込んでいる - そこまで⽐較検討しなくても、リスク⾯で問題ない場合 「⼀定問題なさそうなので、⽐較検討せず決めた」というADRを残す という⽅法もあり - どこまでをADRとして扱うか？の基準が難しい。 - どの程度の意思決定なら、 コードベースでのPR Reviewや、Slack・⼝頭でOKとするか？ - 「ADRとして記録に残すべき事が漏れた」という事が無いよう、 チームやプロダクトの状況に応じて、統制を取る必要がある
15. ADRってアプリ開発 でも有⽤？
16. 有⽤なシーンは多いと思うが、もちろん開発現場の状況による では、どのような現場だと有効なのか？ ADRってアプリ開発でも有⽤？
17. 1. 開発に関わっているエンジニアが多い - 理由： - レビューの機会が⽣まれる事により、技術的な意思決定の質の向上が⾒込める - 幅広いエンジニアの知⾒を活かすきっかけとなる 2. 今後継続してサービスを提供し続ける⾒込みのプロダクトの開発 - 理由： - 「なぜこの意思決定をしたのか？」が明記される事により、 導⼊したライブラリの廃⽌やアーキテクチャの改善がしやすくなる。 3. 技術⼒を伸ばしたい - 理由： - ライブラリを選んだ理由を⾔語化する事そのものが、意思決定する上での トレーニングとなる。 - 「他の解決⽅法は無いか？」という事に意識を向けるのが強制されるので、 その過程で幅広い解決⽅法をしる事が出来る どのような状況にオススメ？
18. 1. プロジェクトやチームのミッションが定まり切っていない - 理由： - 判断軸がブレるため、意思決定に時間がかかったり、 議論のすれ違いが起こる可能性がある - 上記を避けるため、「リーダーポジションがすべて決める」 という⽅法が有⽤な場合もある 2. ⼀定以上のプロジェクトマネジメント⼒がある⼈材が居ない - 理由： - 調査はやろうと思えばいくらでも時間をかけられる。 - しかし、使えるリソース（時間）は有限。どの程度の調査でやめるかの判断を 適宜⾏える⼈がいないと、「開発に割く時間がなくなってしまった」 というケースもありえる。 どのような状況と相性が悪そうか？
19. - アーキテクチャ意思決定記録（ADR）とは何か - 「Design It!」(O’Reilly) 参考資料