制約が多い大きなプロダクトに新卒で飛び込み、バリバリ案件開発に貢献するようになるまでの道のり。 / DevBoost2021_YusukeKawauchi

2021/12/11_Developers Boost 2021での、河内の講演資料になります

Transcript

1. 制約が多い⼤きなプロダクトに新卒で⾶び 込み、バリバリ案件開発に貢献するように なるまでの道のり。 株式会社リクルート 河内 友佑 Developers Boost 2021 A-5
2. ⾃⼰紹介 株式会社リクルート 河内 友佑 Swift/Java/Kotlin 2020年 新卒⼊社 2020年7⽉ タウンワークアプリチーム 2021年4⽉ オフショアと協働開始 所属 名前 技術スタック 職歴 趣味 最近学びたいこと 写真撮影・野球観戦 英語・ベトナム語
3. お話の前提 2 今⽇お話しすること Beginnerが⼀⼈前のPlayerになるまでに取り組んだことの善し悪し 今⽇お話ししないこと 個別具体の技術の話 今⽇のお話の注意点 想定している参加者 1. これから既存プロダクトに参画する予定のある⽅。 2. これから既存プロダクトで新規参画者を受け⼊れる予定のある⽅。
4. ⾃分の初期値 3 なにがわからないのかわからない 質問⼀つするのにも、どう聞けばいいかわ からない ろくに検索ができない。 ⼊社1⽉後の⾃分 アプリ配属が決まったが、 ネイティブアプリ開発経験はゼロ どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 ︖ ︖︖ 研修スケジュール 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 座学 OJT研修 現場配属 初めてiOSに 触れる
5. 今⽇のお話 4 1. タウンワークの現状 2. 技術と既存コードの理解編 3. 品質担保の理解編 4. 事業内容の理解編
6. タウンワークの現状 5
7. 歳⽉を重ねることでメンテナンス性が落ちてしまっている 6 タウンワークの現状は先輩⽅が⽅々で登壇・発表している。 タウンワークiOSについて タウンワークiOSアプリの複雑性と制約の中でいか に品質を守ってきたかの取り組みについての発表 タウンワークの開発プロセスについて タウンワークチームの開発リードタイムを削減する ために、開発プロセスをチューニングした話 https://speakerdeck.com/rtechkouhou/kokoshu-nian- jian-falsetaunwakuiosapurifalseenziniafalsetiyarenzi https://speakerdeck.com/rtechkouhou/taunwakuwodorai busaserutameninantiyatuteaziyairuwoyametahua
8. 歳⽉を重ねることでメンテナンス性が落ちてしまっている 7 タウンワークの現状は先輩⽅が⽅々で登壇・発表している。 システムの複雑性とそのチューニング レガシーシステムにおける様々な問題をひとつひと つ紐解いて改善していった話 https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai- wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number- devisumid どれも、これまで積み上げてきたシステムが制約・ 負債となったことで⽣まれた問題に向き合っている お話。 制約・負債の前提を理解しないと まともに開発できない。
9. 開発メンバーやリリース頻度も品質に影響を及ぼしうる 8 タウンワークアプリのざっくり規模感 守らなくてはならない制約 ▍初回リリース ▍総リリース回数 2011年5⽉3⽇ 200回以上 ▍総コード⾏数 Swiftのみ約10万⾏ ▍⾃動テストケース数 約1100ケース ▍⼿動テストケース 約2600項⽬ ▍週間訪問回数 約100万回 ▍開発体制 iOSのみ約20名 ▍リリース頻度 継続して２週に１回 1. 複数⼈が並⾏して案件開発を⾏い、決めた期⽇にリリース作業を⾏う。 2. 求職者と企業のマッチングを妨げるような外部品質毀損をおこしてはいけない。 開発速度を維持しながら、商品に影響がある ような障害を起こしてはいけない
10. 改めて⾃分の初期値 9 なにがわからないのかわからない 質問⼀つするのにも、どう聞けばいいかわ からない ろくに検索ができない。 ⼊社1⽉後の⾃分 アプリ配属が決まったが、 ネイティブアプリ開発経験はゼロ どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 ︖ ︖︖ 研修スケジュール 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 座学 OJT研修 現場配属 初めてiOSに 触れる タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない どうなっていたいか どうなっているべきか がわかってない。
11. 何がわかっていなのか整理してみる。 10 なにがわからないのかわからない 質問⼀つするのにも、どう聞けばいいかわ からない ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない 解像度が低いのであまり意味がない 問題の分割をする。 1. 技術の話か 2. タウンワークの話か 都度、識者から聞くしかない。 コードの理解が問題 ⾔語知識が問題 事業理解が問題 開発してみないと何が 難しいかわからない
12. 何がわかっていなのか整理してみる。 11 なにがわからないのかわからない 質問⼀つするのにも、どう聞けばいいかわ からない ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない 解像度が低い 問題の分割をする。 1. 技術の話か 2. タウンワークの話か 都度、識者から聞くしかない。 コードの理解が問題 ⾔語知識が問題 事業理解が問題 開発してみないと何が 難しいかわからない この辺りの”知らない”を”わかる”状態にすることが タウンワークで⼀⼈前の開発者になるために必要
13. 技術と既存コードの理解編 12
14. 何がわかっていなのか整理してみる。 13 ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない コードの理解が問題 ⾔語知識が問題
15. メンターとメンティーの⽬的感 14 技術のインプットと開発プロセスのインプット 技術を学ぶことはもちろんタウンワークで開発をするにあたってのチームの動き⽅やプロセス、 チームとして最も重要なこと、優先順位なども理解しないといけない。 技術と既存コードの理解 案件開発できるようになりたい。そのために⾔語の理解とOSの理解をした上で、わからないこ とをなくして、霧を晴らしたい。 メンターの⽬的感 ⾃分の⽬的感
16. iOS/Swiftについての理解を深める 15 AB除却 l 会社から提供された 教材での⾔語学習。 l 循環参照についての 知 識 イ ン プ ッ ト や AutoLayout な ど へ の知識をつける。 l タ ウ ン ワ ー ク の ス ルーテスト項⽬を⼀ つ⼀つ実施しながら、 ど う い っ た 仕 様 に なっているのかを把 握する。 l 過去案件について、 数パターンでの実装 案を考え、実際に実 装してみる。 l メ ン タ ー と メ リ ッ ト・デメリットの⽐ 較を⼀緒にする中で、 プロダクトにおける ⼤事な観点を学ぶ。 l 機能実装はしないが、 既にあるABテストを ソースコードから除 却することで必要な テストと品質担保の 基礎を学ぶ。 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット ⾃分の学習フロー ~初⼼者から半⼈前編~
17. iOS/Swiftについての理解を深める 16 AB除却 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット 体系的な知識が⾝に付く いくつかの⾔語を触ってみて、差分から学べる⼈で あれば、この⽅法は有効。困ったときに辞書的に使 うこともできるので、⼀冊持っておくことは⼤事。 実際に書けるまでのハードルが⾼い 開発経験が浅いと辞書的な教科書から⼀度に学べる ことは多くない。 IDEが発展しているので、⾔語仕様として重要な箇 所やライフサイクルなどを学んだ上で、実際に⼿を 動かしてみる⽅がキャッチアップは早い。 ⾃分の学習フロー ~初⼼者から半⼈前編~
18. iOS/Swiftについての理解を深める 17 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット オフィシャルのTutorialに勝るものはない Androidを学習するにあたって、CodeLabを利⽤することがあったが、圧倒 的に初期理解には強い。iOSでも公式がtutorialを⽤意してくれているので、 実際に書きながら学ぶのがかなり効率が良い。 まずはIDEを使いこなせるようになる 定義ジャンプやツリー表⽰、Viewから関連する実装へ⾶ぶ、デバッグなど IDEの機能を使いこなせるようになることが理解への圧倒的な近道。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
19. iOS/Swiftについての理解を深める 18 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット 画⾯遷移や特殊な動きがわかる プロダクト規模が⼤きくなると画⾯遷移の種類の多 さや特殊なポップアップ、起動種別ごとの挙動の違 いなど、相当な既存仕様への知識と理解が求められ る。仕様書があればベストかもしれないが、弊プロ ダクトは「実装が仕様書」だったので、もっとも仕 様書に近いスルーテスト項⽬書を使って仕様のイン プットにつとめた。 関連の実装の場所は別途理解が必要 どこの画⾯がどのクラスで実装されているのか、起 動はどうやって区別しているのかなどの実装の実体 は別に理解する必要がある。 「どうすれば特定の画⾯の実装に最速で到達できる か」のノウハウが⼀番⼤事だったように思う。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~
20. iOS/Swiftについての理解を深める 19 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット 画⾯共有しながらの実践が最⾼効率 関連実装がどこにあるかを調べる⼒があるかないかで初速が⼤きく変わる。 関連実装の調査はノウハウだけをメンターが教える⽅法が最速。メンティー が画⾯を共有しながら、メンターの指⽰で実装をたどれるようにすれば、か なり早くキャッチアップができるようになる。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
21. iOS/Swiftについての理解を深める 20 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット 実装時の幅が広がる 同じ機能を実装するにしても、実装には善し悪しが ある。何が良い実装なのかを理解するためには場数 を踏むしかないと思っている。思いつく限りの実装 ⽅法を試してみることで、既存コードの理解と⾔語 やOSへの理解の両⾯を深めることができる。 レビューコストがかかる 書きっぱなしでは意味がないので、レビューと振り 返りを⾏う必要がある。チュートリアルからいきな りこのフェイズに⾶ぶので、レビューと指摘はかな り根気がいるもの(だったと思う) AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~
22. iOS/Swiftについての理解を深める 21 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット レビュー時にリファレンスがあると⼀気に学習が深まる 教材から実プロダクトに⾜を踏み⼊れると、やはり段差が⼤きいので基本から理解し ていないことがザラにある。再学習⽤のリファレンスがあることで⼀気に理解が深ま る。また、進化の早い⾔語では、今の主流や歴史的経緯などをその際にインプットさ れることで、既存コードの課題感共有も⼀気にできるメリットがある。 1. 公式のドキュメント 2. 関連する社内資料 3. 参考になるテックブログ AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
23. iOS/Swiftについての理解を深める 22 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット ライブラリに頼らず実装する 新しいライブラリを導⼊する際の影響範囲調査や特定は特殊スキル。ライブラリを使 わずに複数パターンの実装⽅法を検討することが早々に戦⼒になるためには⼒になる。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
24. iOS/Swiftについての理解を深める 23 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット プロダクトに合う実装を理解できる QCDの観点でどの実装が今のプロダクトに合ってい るかを理解することができる。 また、どういった実装にどんなリスクがあるのかを 会話できるので⼀度に学ぶことが⾮常に多い。 ⾒積もりの想定ができるようになる ある変更に対してどれぐらいのコストがかかるのか について⼤雑把に理解できるようになる。 アプリでいうと下記のように分割して捉えると良い。 1. 画⾯の全体変更 2. 画⾯の部分変更 3. ロジックの変更 4. 通知の追加などOS機能の利⽤ AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~
25. iOS/Swiftについての理解を深める 24 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット メンティーが意⾒を持つこと 複数パターンで実装した上で、どれがどんな観点で良いのか悪いのかについ て、まずは意⾒をもつことが⼤事。下記の観点で⾃分の考えを作った。 1. 実装速度(必要な⼿数・⼯数) 2. 他の実装者が引っかかる罠になっていないか 3. 既に⾮推奨、または今後⾮推奨になりそうな実装ではないか。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
26. iOS/Swiftについての理解を深める 25 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット リリースまでのフローを体感できる 実際にソースコードに変更を加えてリリースまで⾏ うことで、チーム開発としてどこでどうして品質を 守っているかを⽐較的安全に体験することができる。 詳細は品質担保の⽂脈で後述 AB除却 どのABクラスを除却するかを決め るのは難しい 意思決定の段階でどのABを除却するかを決めること が後々重要になってくるが、プロダクト内でのコン フリクトを正確に把握できていない状態ではその意 思決定は難しい。 まずは除却するABテストは識者が決めてしまって、 数をこなした⽅がここでの⽬的は達成できると思う。 ⾃分の学習フロー ~初⼼者から半⼈前編~
27. iOS/Swiftについての理解を深める 26 実装の⽐較 数パターンで 機能の実装 テスト項⽬と 機能の⽐較 教材での インプット チームでの開発フローを意識し、細かな共有を⾏う チームの開発フローを守ることがこのフェイズで最も⼤事なこと。チームが ⼤きければ共有ミスによるデグレの影響も⼤きくなるので、なるべく動き⽅ をリストアップして⼀つ⼀つ丁寧にコマを進めるべき。 ここで初めてコンフリクトやデグレの恐怖を知ることになるので、特に参画 者がチーム開発初⼼者の場合はこの時点で気軽に相談できる⼈がいないと⼿ が⽌まるか⼤ダメージを与えるかになりうる。 AB除却 ⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips
28. 何がわかっていなのか整理してみる。 27 ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない Clear Clear
29. タウンワークで開発することの難しさの解像度が上がった。 28 タウンワークで開発することの難しさをわかっていない 技術のインプットと開発プロセスのインプット 技術を学ぶことはもちろんタウンワークで開発をするにあたってのチームの動き⽅やプロセス、 チームとして最も重要なこと、優先順位なども理解しないといけない。 技術と既存コードの理解 案件開発できるようになりたい。そのために⾔語の理解とOSの理解をした上で、わからないこ とをなくして、霧を晴らしたい。 メンターの⽬的感 ⾃分の⽬的感 再掲
30. タウンワークで開発することの難しさの解像度が上がった。 29 品質担保の理解 品質担保と開発速度の両⽴ チームメンバーとのコミュニケーション 複雑な仕様とトラップのような実装 ソースコードだけでわからない仕様 たくさんある現役の⾮推奨 残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様 点在するドキュメント 離職に伴って消えたドキュメント 整備されていない社内ライブラリ 同時にたくさんの案件が⾛る 発掘される既存バグ タウンワークで開発することの難しさが⾒えてきた
31. タウンワークで開発することの難しさの解像度が上がった。 30 品質担保の理解 品質担保と開発速度の両⽴ チームメンバーとのコミュニケーション 複雑な仕様とトラップのような実装 ソースコードだけでわからない仕様 たくさんある現役の⾮推奨 残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様 点在するドキュメント 離職に伴って消えたドキュメント 整備されていない社内ライブラリ 同時にたくさんの案件が⾛る 発掘される既存バグ タウンワークで開発することの難しさが⾒えてきた 共存しながら開発していく トレーニングをする
32. ⽬的感 31 １開発者として独り⽴ちする。 たくさんある課題を知った上で、どうやって案件開発をしていくかを学ぶ。どんな案件でも担 当できるようになるために、いかに共存するかを学びたい。
33. iOS/Swiftについての理解を深める 32 オフショアとの 協働 l メンターとステップ バイステップで会話 をしながら案件実装 を進める。 l あくまで⾃⾛での実 装だが、品質につい てはメンターのダブ ルチェックをもらう 形でリリース l XcodeとSwiftのバー ジョンアップに伴う プロダクトへの影響 調査とテストを実施。 l 外部影響を極⼩にす るため、ログに関す る実装への影響を担 当。 l ⾃⾛で案件開発を開 始。 l レビュアーとしてメ ンターとリードエン ジニアがいる状態。 l 品質担保も⾃分の責 任の範囲。 l 主要動線に絡むリス クの⾼い案件を担当。 l 通常のテストだけで なく、⼤きな障害に つながりうる箇所の リスクを低減するた めの⽅法を学び、実 践する。 l オフショアと協働し ながら、品質と速度 を両⽴した開発を推 進する。 リスクの⾼い 案件実装 ⾃⾛での 案件実装 Xcode12対応 補助輪付き 案件実装 ⾃分の学習フロー ~半⼈前から⼀⼈前編~
34. iOS/Swiftについての理解を深める 33 オフショアとの 協働 リスクの⾼い 案件実装 ⾃⾛での 案件実装 Xcode12対応 補助輪付き 案件実装 ⾃分の学習フロー ~半⼈前から⼀⼈前編~ 主に品質担保の⽅法と考え⽅を学ぶ 具体的な話は後述します。 ⾒通しを⽴てるために⼩さくたくさん作る 新規で提案されたエンハンス案件ほぼ全てに対して、実際に動く最⼩限のプロトタイ プを作成し、⼯数の⾒通しを⽴てるということをやり続けた。下記の両⽴ができ、⼀ 気にプロダクトへの理解が進んだ。 1. なるべくたくさんのコードを読むこと 2. 知らないiOS/Swiftに関する知識を吸収すること 気づきとTips
35. iOS/Swiftについての理解を深める 34 オフショアとの 協働 リスクの⾼い 案件実装 ⾃⾛での 案件実装 Xcode12対応 補助輪付き 案件実装 ⾃分の学習フロー ~半⼈前から⼀⼈前編~ リスクの⼤きさに応じて設計やテストを調整し説明する リスクの⼤きさによって、外部品質を保つための設計を重視する必要が⽣まれる。ど のように安全に倒すのか、どのようにテストを実装するのかという設計や実装⾯での 配慮や調整をするとともに、開発側で想定しているリスクとリスクに対する対応を開 発者として説明するという過程も経験する。
36. iOS/Swiftについての理解を深める 35 オフショアとの 協働 リスクの⾼い 案件実装 ⾃⾛での 案件実装 Xcode12対応 補助輪付き 案件実装 ⾃分の学習フロー ~半⼈前から⼀⼈前編~ 要件定義とレビューで品質コントロールを実施する 具体的な業務内容はここでは省略します。 タウンワークアプリの案件開発を⽀えるオフショ アチームの成り⽴ちとこれから 具体的な話が本年度のiOSDCで発表されています。 https://www.slideshare.net/AtaruOsaka/iosd c-japan-2021-250227442
37. iOS/Swiftについての理解を深める 36 オフショアとの 協働 その後 ⾃分の学習フロー ~半⼈前から⼀⼈前編~ 継続的に最新情報をキャッチアップする 公式のドキュメントやブログ、イベントなどで最新情報をキャッチアップし続ける。 • OS/IDEの更新情報 • 新機能のキャッチアップ • カンファレンスなどでの情報収集
38. 品質担保の理解編 37
39. タウンワークで開発することの難しさの解像度が上がった。 38 品質担保の理解 品質担保と開発速度の両⽴ チームメンバーとのコミュニケーション 複雑な仕様とトラップのような実装 ソースコードだけでわからない仕様 たくさんある現役の⾮推奨 残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様 点在するドキュメント 離職に伴って消えたドキュメント 整備されていない社内ライブラリ 同時にたくさんの案件が⾛る 発掘される既存バグ タウンワークで開発することの難しさが⾒えてきた
40. タウンワークで開発することの難しさの解像度が上がった。 39 品質担保の理解 品質担保と開発速度の両⽴ チームメンバーとのコミュニケーション 複雑な仕様とトラップのような実装 ソースコードだけでわからない仕様 たくさんある現役の⾮推奨 残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様 点在するドキュメント 離職に伴って消えたドキュメント 整備されていない社内ライブラリ 同時にたくさんの案件が⾛る 発掘される既存バグ タウンワークで開発することの難しさが⾒えてきた どう品質を守るかを知らないと まともに案件開発できないことを 知った。
41. ⽬的感 40 負債と共存して開発を進める 何が負債なのか、本来どうあるべきかを学んだ上で、タウンワークがどういう状態にあるかを 俯瞰する必要があると思った。 ずっとメンターから⾔われ続けていた「タウンワークで必要なのは品質担保である」というと ころに向き合う必要が出てきた。
42. 品質担保の理解 41 “As is”と”To be”の理解 “To be”の理解 プロダクトの品質担保についてのあるべき姿を知ることが必要。例えば下記のような内容を⼀通り理解しておく 必要がある。 1. テストピラミッド 2. テストがしやすい(書きやすい)アーキテクチャ “As is”の理解 実際のプロダクトでは、理想状態とはかけ離れていることがある。下記の内容の理解が不可⽋。 1. 何を防いで、どこまで許容するのかの線引き 2. テストが書けない(書きにくい)コードの中で、どのようなテスト設計をするか 3. 既存コードでどのような障害・バグが起こり得るのか
43. 品質担保の理解 42 ”To be”の理解 “ 書籍から学ぶ 「初めての⾃動テスト※1」「テスト駆動開発※2」 などの著名な書籍を通して基礎を学ぶ。 “ テックブログから学ぶ Just Say No to More End-to-End Tests※3 などのテックブログから考え⽅を学ぶ。 “ 先⼈のスライドから学ぶ ソフトウェアテストや品質担保に関する過去の発 表スライドなどを漁って学ぶ。 “ OSSから学ぶ 整備されたOSSを覗いて、どのようなアーキテク チャでどうやってテストを実装しているかを学ぶ。 Viewがないライブラリなどはほぼ完全にテスト コード化されているので理解が捗る。 ※1: Jonathan Rasmusson 著、⽟川 紘⼦ 訳「初めての⾃動テスト――Webシステムのための⾃動テスト基礎」 O'Reilly Japan, Inc. ※2: Kent Beck 著、和⽥ 卓⼈ 訳 「テスト駆動開発」 オーム社 ※3: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
44. 品質担保の理解 43 ”As is”の理解 1 何を防いで、どこまで許容するのかの線引き テストをする時間も⼯数に含まれているので、無限にテストをするというわけ にはいかない。どのレベルの障害を防ぐかの線引きと、その考え⽅をリードエ ンジニアやプロダクト責任者から聞くことがプロダクトにおける品質担保の前 提を知る上で⼤きな⼒になった。 対象ユーザ⼤ 対象ユーザ⼩ 事業への影響⼤ × 絶対に防ぐ × 絶対に防ぐ 事業への影響⼩ △ なるべく防ぐ △ なるべく防ぐが コストはかけすぎない
45. 2 テストが書けない(書きにくい)コードの中で、どの ようなテスト設計をするか コードの追加・修正による影響範囲についてどこまでテストするべきかを学ぶ。 1. 修正に伴う影響範囲を特定し、テストが必要になる箇所を洗い出す 2. メソッドごとにテストコードは書ける限り書く 3. Viewなどテストを書けない部分はどう正当性を担保するか学ぶ 4. どのOS/どの端末でテストをするべきか学ぶ 5. 主要動線への影響がある場合はさらにテスト範囲を広げる 品質担保の理解 44 ”As is”の理解
46. 3 既存コードでどのような障害・バグが起こり得るか 過去の障害履歴やポストモーテムなどをなるべくたくさん読む。 先⼈たちの失敗に関する資料から、「どういった理由による障害が多いのか」 を学ぶことが既存コードの弱点理解に繋がる。 品質担保の理解 45 ”As is”の理解 27% 35% 15% 5% 外部サービスの障害の影響 アプリや端末に関する仕様の 考慮漏れ 実装時のロジック不正 端末やOSのバグ タウンワークアプリの過去障害の傾向
47. 品質担保の理解 46 影響範囲を理解する上で役⽴った３ステップ STEP 1 ABTestクラスの除却 実装の⼀部を除却し本反映させる中で既に存在したテスト項⽬書 のうち、どこが不要になるかを学ぶ STEP 3 IDE/SDKの更新対応 アプリ特有だが、⾃分が加えた更新ではない変更について、公式 のドキュメントなどを照らし合わせて影響範囲を特定し、必要な テストを構成し実施する⼒を得る STEP 2 ABTestクラスの実装 実際に案件の実装をする中で、⾃分が加えた変更に伴う影響箇所 の品質担保に必要なテストを構成する能⼒を得る Xcode12対応 Appleによる更新ドキュメントを元に、 • 影響がない実装 • 影響がある実装 • 影響の有無がわからない実装 に分類し、下⼆つについてさらにソースコードか ら影響範囲を特定する。テストの必要性を検討す ることで、ライブラリ更新タスクのようなときで も必要な品質担保⼿段を考案・実施できるように なった。
48. 品質担保の理解 47 起こしたバグ・障害から学ぶ 01 バグの検知 02 バグの原因調査 03 バグの修正 04 バグの振り返り 05 振り返りの共有とアクション ⾃分が担当した案件はリリース後の様⼦を⾒る。 バグが存在した場合、早急に原因調査と報告・共有を⾏う 必要に応じて、修正を実施する。 なぜバグが仕込まれたのか、なぜそれを認識できなかったの かについて振り返りを実施 振り返り結果をチームに共有し、次回以降再発させないため に必要なアクションを提案・実施する
49. 品質担保の理解 48 起こしたバグ・障害から学ぶ 01 バグの検知 02 バグの原因調査 03 バグの修正 04 バグの振り返り 05 振り返りの共有とアクション ⾃分が担当した案件はリリース後の様⼦を⾒る。 バグが存在した場合、早急に原因調査と報告・共有を⾏う 必要に応じて、修正を実施する。 なぜバグが仕込まれたのか、なぜそれを認識できなかったの かについて振り返りを実施 振り返り結果をチームに共有し、次回以降再発させないため に必要なアクションを提案・実施する 冷や汗をかき体で覚える。 改めて”まずい実装”を理解できる。 修正をするべきか、切り戻しをするべきかなど、ビジ ネス観点で考えることがたくさんある。 バグは混⼊させても、流出させてもいけない。なぜど こにも引っ掛からなかったかを考えると、⾃分が忘れ ている観点が⽣まれることがある。 開発フローの改善や、CI/CDによる事前検知など⼀段 階視座を上げた⾒⽅ができるようになる。
50. 何がわかっていなのか整理してみる。 49 ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない Clear Clear Clear
51. 事業の理解編 50
52. 事業の理解編 51 商品知識の理解(プロダクトの背景理解) 商品知識を学ぶ 開発をする上で、事業がどのように動いているかを知る必要がある。タウンワークはアプリから直接の売り上げ があるわけではないので、 • どのような商品を誰に提供しているか • 商品をどのように実装しているか • 商品ごとに実装の細かな違いがあるか といった内容の理解が必須である。 プロダクトの背景知識は社内ドキュメントと実装、チームメンバーからのヒアリングで学んだが⼀つでも⽋如し ていると相当な時間がかかったと思う。
53. 事業の理解編 52 チームメンバーの理解 開発組織以外の動き⽅を知る 誰がどのような意思を持って⾏動しているかを知ることが実装のしやすさに影響する。 エンハンス案件を提案するプランナーやデザイナーとコミュニケーションを取り、実装の複雑性を下げることが 品質担保に繋がる。そのために、開発チームの輪を超えて会話をする必要がある。 開発メンバーの特徴を知る コロナ禍、在宅での仕事でメンバー各⼈とのコミュニケーションを取るのが難しくなっていた。 時間の解決に委ねてしまったが、メンバーとのコミュニケーションハードルの有無が開発のスピードに与える影 響はかなり⼤きかったと⾔える。 誰が技術に強く、誰が既存仕様に強いのかなどのメンバーの特⻑把握は重要だった。
54. わからないがなくなり、⾃信とともに案件と向き合えるようになった。 53 ろくに検索ができない。 どこにどんな実装があるのか分からない ⾔語理解が⽢く、ビルド時にコンパイルエ ラーが起きることもママ アーキテクチャの理解と経験が浅く、コー ドが綺麗なのか汚いのかもわからない。 タウンワークで開発することの難しさをわ かってない タウンワークのことを知らない Clear Clear Clear Clear ⾃信を持って開発ができる 状態になる。
55. 次のステージへ。 54 負債を潰していく これまでは負債を制約と捉えて実装をすることができるようになったに過ぎない。 ここから先は効果の⾼い負債と向き合って解消していける⼈材になっていく必要がある。 触⼿をAndroidにのばしアプリならなんでも︕⼈材になる これまでの学習フェイズで良かったところをつまみ⾷いしてAndroid開発に携わるようになった。 オフショアチームと共により開発しやすいチームにする 負債解消と案件開発を平⾏でできるチームにするために、オフショアチームを強化していく。これから新規で ⼊ってくる⼈たちが『負債と共存しながら、仕⽅なくこうする』みたいな実装をせずに済む未来を作りたい。 いずれこの内容の発表ができるように頑張ります💪
56. 55 ご清聴ありがとうございました。