Sansan株式会社 技術本部 Sansan Engineering Unit Mobile Applicationグループ 原田拓眞 テストと設計の関係、そして意思決定の記録。 成長し続けるアプリのための 

ツールや技術的な話はあまりしないかも - テストや設計に纏わる状況や課題は十社十色で、 これやればうまくいくと言うものはないから - 今回は「何のためにテストするのか」「どうしたらテスト・ 設計を改善していけるのか」という話 

- 依存関係が多い - 状態遷移が複雑で見通しが立ちづらい - UIにロジックがべったり - いろいろな副作用がある関数 - ひとつのクラスに責務てんこ盛り - etc... テストが書きづらいと感じたことは？ 

その感覚、設計の悲鳴かも？ 

- 依存関係が多い - 密結合な設計、DIできてない - 状態遷移が複雑で見通しが立ちづらい - 状態の定義や、状態遷移ロジックが分離できてない - UIにロジックがべったり - プレゼンテーション層とビジネスロジック層の分離不備 - いろいろな副作用がある関数 - CQSの原則に違反 - ひとつのクラスに責務てんこ盛り - 単一責務の原則に違反 冒頭の「書きづらさ」とは 

テストが書きづらい = 設計に改善余地がある 

書きづらい ↓ 書かない・捨てる ↓ 不具合が起きやすくなり、開発スピードが鈍化 ↓ … 放置しておくと悪循環へ入ってしまう 

テストコードを書く目的は 「不具合を防ぐ」ためだけではない 

アプリの成長を持続可能となるように支える 

アプリの成長を持続可能にするためのテストコード - アプリはさまざまな「変化」の中にある - 仕様変更 - 機能追加・削除 - 人の入れ替わり - 技術トレンドの変遷 - etc... → これらの変化に対し強く設計・運用できる事が大事 

でも設計方針変えるのって大変ですよね 

なぜ設計方針を変えるのって大変なんだろう - 長い間使っていて慣れているから？ - 合意形成が難しいから？ - 結論が正しいかわからないから？ - 影響が大きいから？ 

判断を資産にできてないから 

判断は資産 - ドラスティックな設計変更も、スモールスタートのコツコ ツとした改善も、大なり小なり「判断」を行っている - 実施した結果のそれ自体以上に、どのような課題に対し、 何を検討し、どうする判断をしたかが大切 - 「どうしてこうなっているのか？」を知ることで、設計改 善、アプリの成長を持続可能とすることにつながる 

しかし多くの場合、Slackのログ、PR、口頭、記憶、様々な ところに散らばってしまって、判断の内容が記録されず消えていく 

- 判断の内容を記録すること - 判断として決定したこと、経緯・背景、比較検討されたこ との体裁が整っており、読みやすいこと - ドキュメント作成負荷が軽いこと 判断を資産とするために 

- なぜその決定が行われたのかを説明し、将来その背景を理 解・議論することができるようになる - 設計変更の判断内容を振り返り、判断が適切であったか どうか、それを踏まえて今後どうしていくかが決められ る - 決定事項、経緯・背景、比較内容のフォーマットを整えて 議論することで、意志決定のスピードも上げる そのための「Architecture Decision Record」という枠組 

Sansanで使っているADRテンプレート 

- 80件近くの意思決定が記録されている - 承認者としてはiOS/Android双方のテクニカルリード - 全員の同意を取るとスピード感が薄れるため - レビューへの参加は誰でもOK - 決定事項は隔週のグループ会で共有される - 状態管理の設計についてはQ毎くらいで見直しと改善が 進んでいる - 長らく自動テストに乗っていなかったテストコードも、ADRで の議論、意思決定を通じて改善された Sansanでは約1年半くらい運用 

判断を資産に変えて、アプリの成長を支えよう