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

by Recruit

Slide 1

Slide 1 text

制約が多い⼤きなプロダクトに新卒で⾶び込み、バリバリ案件開発に貢献するようになるまでの道のり。株式会社リクルート河内友佑 Developers Boost 2021 A-5

Slide 2

Slide 2 text

⾃⼰紹介株式会社リクルート河内友佑 Swift/Java/Kotlin 2020年新卒⼊社 2020年7⽉タウンワークアプリチーム 2021年4⽉オフショアと協働開始所属名前技術スタック職歴趣味最近学びたいこと写真撮影・野球観戦英語・ベトナム語

Slide 3

Slide 3 text

お話の前提 2 今⽇お話しすること Beginnerが⼀⼈前のPlayerになるまでに取り組んだことの善し悪し今⽇お話ししないこと個別具体の技術の話今⽇のお話の注意点想定している参加者 1. これから既存プロダクトに参画する予定のある⽅。 2. これから既存プロダクトで新規参画者を受け⼊れる予定のある⽅。

Slide 4

Slide 4 text

⾃分の初期値 3 なにがわからないのかわからない質問⼀つするのにも、どう聞けばいいかわからないろくに検索ができない。⼊社1⽉後の⾃分アプリ配属が決まったが、ネイティブアプリ開発経験はゼロどこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。 ︖ ︖︖ 研修スケジュール 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉座学 OJT研修現場配属初めてiOSに触れる

Slide 5

Slide 5 text

今⽇のお話 4 1. タウンワークの現状 2. 技術と既存コードの理解編 3. 品質担保の理解編 4. 事業内容の理解編

Slide 6

Slide 6 text

タウンワークの現状 5

Slide 7

Slide 7 text

歳⽉を重ねることでメンテナンス性が落ちてしまっている 6 タウンワークの現状は先輩⽅が⽅々で登壇・発表している。タウンワークiOSについてタウンワークiOSアプリの複雑性と制約の中でいかに品質を守ってきたかの取り組みについての発表タウンワークの開発プロセスについてタウンワークチームの開発リードタイムを削減するために、開発プロセスをチューニングした話 https://speakerdeck.com/rtechkouhou/kokoshu-nian- jian-falsetaunwakuiosapurifalseenziniafalsetiyarenzi https://speakerdeck.com/rtechkouhou/taunwakuwodorai busaserutameninantiyatuteaziyairuwoyametahua

Slide 8

Slide 8 text

歳⽉を重ねることでメンテナンス性が落ちてしまっている 7 タウンワークの現状は先輩⽅が⽅々で登壇・発表している。システムの複雑性とそのチューニングレガシーシステムにおける様々な問題をひとつひとつ紐解いて改善していった話 https://speakerdeck.com/rtechkouhou/taunwaku90mo-yuan-gao-falsejie-zai- wozhi-eruregasibatutipahuomansutiyuningu-number-devsumi-number- devisumid どれも、これまで積み上げてきたシステムが制約・負債となったことで⽣まれた問題に向き合っているお話。制約・負債の前提を理解しないとまともに開発できない。

Slide 9

Slide 9 text

開発メンバーやリリース頻度も品質に影響を及ぼしうる 8 タウンワークアプリのざっくり規模感守らなくてはならない制約 ▍初回リリース ▍総リリース回数 2011年5⽉3⽇ 200回以上 ▍総コード⾏数 Swiftのみ約10万⾏ ▍⾃動テストケース数約1100ケース ▍⼿動テストケース約2600項⽬ ▍週間訪問回数約100万回 ▍開発体制 iOSのみ約20名 ▍リリース頻度継続して２週に１回 1. 複数⼈が並⾏して案件開発を⾏い、決めた期⽇にリリース作業を⾏う。 2. 求職者と企業のマッチングを妨げるような外部品質毀損をおこしてはいけない。開発速度を維持しながら、商品に影響があるような障害を起こしてはいけない

Slide 10

Slide 10 text

改めて⾃分の初期値 9 なにがわからないのかわからない質問⼀つするのにも、どう聞けばいいかわからないろくに検索ができない。⼊社1⽉後の⾃分アプリ配属が決まったが、ネイティブアプリ開発経験はゼロどこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。 ︖ ︖︖ 研修スケジュール 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉座学 OJT研修現場配属初めてiOSに触れるタウンワークで開発することの難しさをわかってないタウンワークのことを知らないどうなっていたいかどうなっているべきかがわかってない。

Slide 11

Slide 11 text

何がわかっていなのか整理してみる。 10 なにがわからないのかわからない質問⼀つするのにも、どう聞けばいいかわからないろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らない解像度が低いのであまり意味がない問題の分割をする。 1. 技術の話か 2. タウンワークの話か都度、識者から聞くしかない。コードの理解が問題⾔語知識が問題事業理解が問題開発してみないと何が難しいかわからない

Slide 12

Slide 12 text

何がわかっていなのか整理してみる。 11 なにがわからないのかわからない質問⼀つするのにも、どう聞けばいいかわからないろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らない解像度が低い問題の分割をする。 1. 技術の話か 2. タウンワークの話か都度、識者から聞くしかない。コードの理解が問題⾔語知識が問題事業理解が問題開発してみないと何が難しいかわからないこの辺りの”知らない”を”わかる”状態にすることがタウンワークで⼀⼈前の開発者になるために必要

Slide 13

Slide 13 text

技術と既存コードの理解編 12

Slide 14

Slide 14 text

何がわかっていなのか整理してみる。 13 ろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らないコードの理解が問題⾔語知識が問題

Slide 15

Slide 15 text

メンターとメンティーの⽬的感 14 技術のインプットと開発プロセスのインプット技術を学ぶことはもちろんタウンワークで開発をするにあたってのチームの動き⽅やプロセス、チームとして最も重要なこと、優先順位なども理解しないといけない。技術と既存コードの理解案件開発できるようになりたい。そのために⾔語の理解とOSの理解をした上で、わからないことをなくして、霧を晴らしたい。メンターの⽬的感⾃分の⽬的感

Slide 16

Slide 16 text

iOS/Swiftについての理解を深める 15 AB除却 l 会社から提供された教材での⾔語学習。 l 循環参照についての知識インプットや AutoLayout などへの知識をつける。 l タウンワークのスルーテスト項⽬を⼀つ⼀つ実施しながら、どういった仕様になっているのかを把握する。 l 過去案件について、数パターンでの実装案を考え、実際に実装してみる。 l メンターとメリット・デメリットの⽐較を⼀緒にする中で、プロダクトにおける⼤事な観点を学ぶ。 l 機能実装はしないが、既にあるABテストをソースコードから除却することで必要なテストと品質担保の基礎を学ぶ。実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプット⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 17

Slide 17 text

iOS/Swiftについての理解を深める 16 AB除却実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプット体系的な知識が⾝に付くいくつかの⾔語を触ってみて、差分から学べる⼈であれば、この⽅法は有効。困ったときに辞書的に使うこともできるので、⼀冊持っておくことは⼤事。実際に書けるまでのハードルが⾼い開発経験が浅いと辞書的な教科書から⼀度に学べることは多くない。 IDEが発展しているので、⾔語仕様として重要な箇所やライフサイクルなどを学んだ上で、実際に⼿を動かしてみる⽅がキャッチアップは早い。⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 18

Slide 18 text

iOS/Swiftについての理解を深める 17 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットオフィシャルのTutorialに勝るものはない Androidを学習するにあたって、CodeLabを利⽤することがあったが、圧倒的に初期理解には強い。iOSでも公式がtutorialを⽤意してくれているので、実際に書きながら学ぶのがかなり効率が良い。まずはIDEを使いこなせるようになる定義ジャンプやツリー表⽰、Viewから関連する実装へ⾶ぶ、デバッグなど IDEの機能を使いこなせるようになることが理解への圧倒的な近道。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 19

Slide 19 text

iOS/Swiftについての理解を深める 18 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプット画⾯遷移や特殊な動きがわかるプロダクト規模が⼤きくなると画⾯遷移の種類の多さや特殊なポップアップ、起動種別ごとの挙動の違いなど、相当な既存仕様への知識と理解が求められる。仕様書があればベストかもしれないが、弊プロダクトは「実装が仕様書」だったので、もっとも仕様書に近いスルーテスト項⽬書を使って仕様のインプットにつとめた。関連の実装の場所は別途理解が必要どこの画⾯がどのクラスで実装されているのか、起動はどうやって区別しているのかなどの実装の実体は別に理解する必要がある。「どうすれば特定の画⾯の実装に最速で到達できるか」のノウハウが⼀番⼤事だったように思う。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 20

Slide 20 text

iOS/Swiftについての理解を深める 19 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプット画⾯共有しながらの実践が最⾼効率関連実装がどこにあるかを調べる⼒があるかないかで初速が⼤きく変わる。関連実装の調査はノウハウだけをメンターが教える⽅法が最速。メンティーが画⾯を共有しながら、メンターの指⽰で実装をたどれるようにすれば、かなり早くキャッチアップができるようになる。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 21

Slide 21 text

iOS/Swiftについての理解を深める 20 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプット実装時の幅が広がる同じ機能を実装するにしても、実装には善し悪しがある。何が良い実装なのかを理解するためには場数を踏むしかないと思っている。思いつく限りの実装⽅法を試してみることで、既存コードの理解と⾔語やOSへの理解の両⾯を深めることができる。レビューコストがかかる書きっぱなしでは意味がないので、レビューと振り返りを⾏う必要がある。チュートリアルからいきなりこのフェイズに⾶ぶので、レビューと指摘はかなり根気がいるもの(だったと思う) AB除却⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 22

Slide 22 text

iOS/Swiftについての理解を深める 21 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットレビュー時にリファレンスがあると⼀気に学習が深まる教材から実プロダクトに⾜を踏み⼊れると、やはり段差が⼤きいので基本から理解していないことがザラにある。再学習⽤のリファレンスがあることで⼀気に理解が深まる。また、進化の早い⾔語では、今の主流や歴史的経緯などをその際にインプットされることで、既存コードの課題感共有も⼀気にできるメリットがある。 1. 公式のドキュメント 2. 関連する社内資料 3. 参考になるテックブログ AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 23

Slide 23 text

iOS/Swiftについての理解を深める 22 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットライブラリに頼らず実装する新しいライブラリを導⼊する際の影響範囲調査や特定は特殊スキル。ライブラリを使わずに複数パターンの実装⽅法を検討することが早々に戦⼒になるためには⼒になる。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 24

Slide 24 text

iOS/Swiftについての理解を深める 23 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットプロダクトに合う実装を理解できる QCDの観点でどの実装が今のプロダクトに合っているかを理解することができる。また、どういった実装にどんなリスクがあるのかを会話できるので⼀度に学ぶことが⾮常に多い。⾒積もりの想定ができるようになるある変更に対してどれぐらいのコストがかかるのかについて⼤雑把に理解できるようになる。アプリでいうと下記のように分割して捉えると良い。 1. 画⾯の全体変更 2. 画⾯の部分変更 3. ロジックの変更 4. 通知の追加などOS機能の利⽤ AB除却⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 25

Slide 25 text

iOS/Swiftについての理解を深める 24 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットメンティーが意⾒を持つこと複数パターンで実装した上で、どれがどんな観点で良いのか悪いのかについて、まずは意⾒をもつことが⼤事。下記の観点で⾃分の考えを作った。 1. 実装速度(必要な⼿数・⼯数) 2. 他の実装者が引っかかる罠になっていないか 3. 既に⾮推奨、または今後⾮推奨になりそうな実装ではないか。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 26

Slide 26 text

iOS/Swiftについての理解を深める 25 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットリリースまでのフローを体感できる実際にソースコードに変更を加えてリリースまで⾏うことで、チーム開発としてどこでどうして品質を守っているかを⽐較的安全に体験することができる。詳細は品質担保の⽂脈で後述 AB除却どのABクラスを除却するかを決めるのは難しい意思決定の段階でどのABを除却するかを決めることが後々重要になってくるが、プロダクト内でのコンフリクトを正確に把握できていない状態ではその意思決定は難しい。まずは除却するABテストは識者が決めてしまって、数をこなした⽅がここでの⽬的は達成できると思う。⾃分の学習フロー ~初⼼者から半⼈前編~

Slide 27

Slide 27 text

iOS/Swiftについての理解を深める 26 実装の⽐較数パターンで機能の実装テスト項⽬と機能の⽐較教材でのインプットチームでの開発フローを意識し、細かな共有を⾏うチームの開発フローを守ることがこのフェイズで最も⼤事なこと。チームが⼤きければ共有ミスによるデグレの影響も⼤きくなるので、なるべく動き⽅をリストアップして⼀つ⼀つ丁寧にコマを進めるべき。ここで初めてコンフリクトやデグレの恐怖を知ることになるので、特に参画者がチーム開発初⼼者の場合はこの時点で気軽に相談できる⼈がいないと⼿が⽌まるか⼤ダメージを与えるかになりうる。 AB除却⾃分の学習フロー ~初⼼者から半⼈前編~ 気づきとTips

Slide 28

Slide 28 text

何がわかっていなのか整理してみる。 27 ろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らない Clear Clear

Slide 29

Slide 29 text

タウンワークで開発することの難しさの解像度が上がった。 28 タウンワークで開発することの難しさをわかっていない技術のインプットと開発プロセスのインプット技術を学ぶことはもちろんタウンワークで開発をするにあたってのチームの動き⽅やプロセス、チームとして最も重要なこと、優先順位なども理解しないといけない。技術と既存コードの理解案件開発できるようになりたい。そのために⾔語の理解とOSの理解をした上で、わからないことをなくして、霧を晴らしたい。メンターの⽬的感⾃分の⽬的感再掲

Slide 30

Slide 30 text

タウンワークで開発することの難しさの解像度が上がった。 29 品質担保の理解品質担保と開発速度の両⽴チームメンバーとのコミュニケーション複雑な仕様とトラップのような実装ソースコードだけでわからない仕様たくさんある現役の⾮推奨残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様点在するドキュメント離職に伴って消えたドキュメント整備されていない社内ライブラリ同時にたくさんの案件が⾛る発掘される既存バグタウンワークで開発することの難しさが⾒えてきた

Slide 31

Slide 31 text

タウンワークで開発することの難しさの解像度が上がった。 30 品質担保の理解品質担保と開発速度の両⽴チームメンバーとのコミュニケーション複雑な仕様とトラップのような実装ソースコードだけでわからない仕様たくさんある現役の⾮推奨残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様点在するドキュメント離職に伴って消えたドキュメント整備されていない社内ライブラリ同時にたくさんの案件が⾛る発掘される既存バグタウンワークで開発することの難しさが⾒えてきた共存しながら開発していくトレーニングをする

Slide 32

Slide 32 text

⽬的感 31 １開発者として独り⽴ちする。たくさんある課題を知った上で、どうやって案件開発をしていくかを学ぶ。どんな案件でも担当できるようになるために、いかに共存するかを学びたい。

Slide 33

Slide 33 text

iOS/Swiftについての理解を深める 32 オフショアとの協働 l メンターとステップバイステップで会話をしながら案件実装を進める。 l あくまで⾃⾛での実装だが、品質についてはメンターのダブルチェックをもらう形でリリース l XcodeとSwiftのバージョンアップに伴うプロダクトへの影響調査とテストを実施。 l 外部影響を極⼩にするため、ログに関する実装への影響を担当。 l ⾃⾛で案件開発を開始。 l レビュアーとしてメンターとリードエンジニアがいる状態。 l 品質担保も⾃分の責任の範囲。 l 主要動線に絡むリスクの⾼い案件を担当。 l 通常のテストだけでなく、⼤きな障害につながりうる箇所のリスクを低減するための⽅法を学び、実践する。 l オフショアと協働しながら、品質と速度を両⽴した開発を推進する。リスクの⾼い案件実装⾃⾛での案件実装 Xcode12対応補助輪付き案件実装⾃分の学習フロー ~半⼈前から⼀⼈前編~

Slide 34

Slide 34 text

iOS/Swiftについての理解を深める 33 オフショアとの協働リスクの⾼い案件実装⾃⾛での案件実装 Xcode12対応補助輪付き案件実装⾃分の学習フロー ~半⼈前から⼀⼈前編~ 主に品質担保の⽅法と考え⽅を学ぶ具体的な話は後述します。⾒通しを⽴てるために⼩さくたくさん作る新規で提案されたエンハンス案件ほぼ全てに対して、実際に動く最⼩限のプロトタイプを作成し、⼯数の⾒通しを⽴てるということをやり続けた。下記の両⽴ができ、⼀気にプロダクトへの理解が進んだ。 1. なるべくたくさんのコードを読むこと 2. 知らないiOS/Swiftに関する知識を吸収すること気づきとTips

Slide 35

Slide 35 text

iOS/Swiftについての理解を深める 34 オフショアとの協働リスクの⾼い案件実装⾃⾛での案件実装 Xcode12対応補助輪付き案件実装⾃分の学習フロー ~半⼈前から⼀⼈前編~ リスクの⼤きさに応じて設計やテストを調整し説明するリスクの⼤きさによって、外部品質を保つための設計を重視する必要が⽣まれる。どのように安全に倒すのか、どのようにテストを実装するのかという設計や実装⾯での配慮や調整をするとともに、開発側で想定しているリスクとリスクに対する対応を開発者として説明するという過程も経験する。

Slide 36

Slide 36 text

iOS/Swiftについての理解を深める 35 オフショアとの協働リスクの⾼い案件実装⾃⾛での案件実装 Xcode12対応補助輪付き案件実装⾃分の学習フロー ~半⼈前から⼀⼈前編~ 要件定義とレビューで品質コントロールを実施する具体的な業務内容はここでは省略します。タウンワークアプリの案件開発を⽀えるオフショアチームの成り⽴ちとこれから具体的な話が本年度のiOSDCで発表されています。 https://www.slideshare.net/AtaruOsaka/iosd c-japan-2021-250227442

Slide 37

Slide 37 text

iOS/Swiftについての理解を深める 36 オフショアとの協働その後⾃分の学習フロー ~半⼈前から⼀⼈前編~ 継続的に最新情報をキャッチアップする公式のドキュメントやブログ、イベントなどで最新情報をキャッチアップし続ける。 • OS/IDEの更新情報 • 新機能のキャッチアップ • カンファレンスなどでの情報収集

Slide 38

Slide 38 text

品質担保の理解編 37

Slide 39

Slide 39 text

タウンワークで開発することの難しさの解像度が上がった。 38 品質担保の理解品質担保と開発速度の両⽴チームメンバーとのコミュニケーション複雑な仕様とトラップのような実装ソースコードだけでわからない仕様たくさんある現役の⾮推奨残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様点在するドキュメント離職に伴って消えたドキュメント整備されていない社内ライブラリ同時にたくさんの案件が⾛る発掘される既存バグタウンワークで開発することの難しさが⾒えてきた

Slide 40

Slide 40 text

タウンワークで開発することの難しさの解像度が上がった。 39 品質担保の理解品質担保と開発速度の両⽴チームメンバーとのコミュニケーション複雑な仕様とトラップのような実装ソースコードだけでわからない仕様たくさんある現役の⾮推奨残ったまんまのABクラス Very Fat VC テスト項⽬に載っていない仕様点在するドキュメント離職に伴って消えたドキュメント整備されていない社内ライブラリ同時にたくさんの案件が⾛る発掘される既存バグタウンワークで開発することの難しさが⾒えてきたどう品質を守るかを知らないとまともに案件開発できないことを知った。

Slide 41

Slide 41 text

⽬的感 40 負債と共存して開発を進める何が負債なのか、本来どうあるべきかを学んだ上で、タウンワークがどういう状態にあるかを俯瞰する必要があると思った。ずっとメンターから⾔われ続けていた「タウンワークで必要なのは品質担保である」というところに向き合う必要が出てきた。

Slide 42

Slide 42 text

品質担保の理解 41 “As is”と”To be”の理解 “To be”の理解プロダクトの品質担保についてのあるべき姿を知ることが必要。例えば下記のような内容を⼀通り理解しておく必要がある。 1. テストピラミッド 2. テストがしやすい(書きやすい)アーキテクチャ “As is”の理解実際のプロダクトでは、理想状態とはかけ離れていることがある。下記の内容の理解が不可⽋。 1. 何を防いで、どこまで許容するのかの線引き 2. テストが書けない(書きにくい)コードの中で、どのようなテスト設計をするか 3. 既存コードでどのような障害・バグが起こり得るのか

Slide 43

Slide 43 text

品質担保の理解 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

Slide 44

Slide 44 text

品質担保の理解 43 ”As is”の理解 1 何を防いで、どこまで許容するのかの線引きテストをする時間も⼯数に含まれているので、無限にテストをするというわけにはいかない。どのレベルの障害を防ぐかの線引きと、その考え⽅をリードエンジニアやプロダクト責任者から聞くことがプロダクトにおける品質担保の前提を知る上で⼤きな⼒になった。対象ユーザ⼤対象ユーザ⼩事業への影響⼤ × 絶対に防ぐ × 絶対に防ぐ事業への影響⼩ △ なるべく防ぐ △ なるべく防ぐがコストはかけすぎない

Slide 45

Slide 45 text

2 テストが書けない(書きにくい)コードの中で、どのようなテスト設計をするかコードの追加・修正による影響範囲についてどこまでテストするべきかを学ぶ。 1. 修正に伴う影響範囲を特定し、テストが必要になる箇所を洗い出す 2. メソッドごとにテストコードは書ける限り書く 3. Viewなどテストを書けない部分はどう正当性を担保するか学ぶ 4. どのOS/どの端末でテストをするべきか学ぶ 5. 主要動線への影響がある場合はさらにテスト範囲を広げる品質担保の理解 44 ”As is”の理解

Slide 46

Slide 46 text

3 既存コードでどのような障害・バグが起こり得るか過去の障害履歴やポストモーテムなどをなるべくたくさん読む。先⼈たちの失敗に関する資料から、「どういった理由による障害が多いのか」を学ぶことが既存コードの弱点理解に繋がる。品質担保の理解 45 ”As is”の理解 27% 35% 15% 5% 外部サービスの障害の影響アプリや端末に関する仕様の考慮漏れ実装時のロジック不正端末やOSのバグタウンワークアプリの過去障害の傾向

Slide 47

Slide 47 text

品質担保の理解 46 影響範囲を理解する上で役⽴った３ステップ STEP 1 ABTestクラスの除却実装の⼀部を除却し本反映させる中で既に存在したテスト項⽬書のうち、どこが不要になるかを学ぶ STEP 3 IDE/SDKの更新対応アプリ特有だが、⾃分が加えた更新ではない変更について、公式のドキュメントなどを照らし合わせて影響範囲を特定し、必要なテストを構成し実施する⼒を得る STEP 2 ABTestクラスの実装実際に案件の実装をする中で、⾃分が加えた変更に伴う影響箇所の品質担保に必要なテストを構成する能⼒を得る Xcode12対応 Appleによる更新ドキュメントを元に、 • 影響がない実装 • 影響がある実装 • 影響の有無がわからない実装に分類し、下⼆つについてさらにソースコードから影響範囲を特定する。テストの必要性を検討することで、ライブラリ更新タスクのようなときでも必要な品質担保⼿段を考案・実施できるようになった。

Slide 48

Slide 48 text

品質担保の理解 47 起こしたバグ・障害から学ぶ 01 バグの検知 02 バグの原因調査 03 バグの修正 04 バグの振り返り 05 振り返りの共有とアクション⾃分が担当した案件はリリース後の様⼦を⾒る。バグが存在した場合、早急に原因調査と報告・共有を⾏う必要に応じて、修正を実施する。なぜバグが仕込まれたのか、なぜそれを認識できなかったのかについて振り返りを実施振り返り結果をチームに共有し、次回以降再発させないために必要なアクションを提案・実施する

Slide 49

Slide 49 text

品質担保の理解 48 起こしたバグ・障害から学ぶ 01 バグの検知 02 バグの原因調査 03 バグの修正 04 バグの振り返り 05 振り返りの共有とアクション⾃分が担当した案件はリリース後の様⼦を⾒る。バグが存在した場合、早急に原因調査と報告・共有を⾏う必要に応じて、修正を実施する。なぜバグが仕込まれたのか、なぜそれを認識できなかったのかについて振り返りを実施振り返り結果をチームに共有し、次回以降再発させないために必要なアクションを提案・実施する冷や汗をかき体で覚える。改めて”まずい実装”を理解できる。修正をするべきか、切り戻しをするべきかなど、ビジネス観点で考えることがたくさんある。バグは混⼊させても、流出させてもいけない。なぜどこにも引っ掛からなかったかを考えると、⾃分が忘れている観点が⽣まれることがある。開発フローの改善や、CI/CDによる事前検知など⼀段階視座を上げた⾒⽅ができるようになる。

Slide 50

Slide 50 text

何がわかっていなのか整理してみる。 49 ろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らない Clear Clear Clear

Slide 51

Slide 51 text

事業の理解編 50

Slide 52

Slide 52 text

事業の理解編 51 商品知識の理解(プロダクトの背景理解) 商品知識を学ぶ開発をする上で、事業がどのように動いているかを知る必要がある。タウンワークはアプリから直接の売り上げがあるわけではないので、 • どのような商品を誰に提供しているか • 商品をどのように実装しているか • 商品ごとに実装の細かな違いがあるかといった内容の理解が必須である。プロダクトの背景知識は社内ドキュメントと実装、チームメンバーからのヒアリングで学んだが⼀つでも⽋如していると相当な時間がかかったと思う。

Slide 53

Slide 53 text

事業の理解編 52 チームメンバーの理解開発組織以外の動き⽅を知る誰がどのような意思を持って⾏動しているかを知ることが実装のしやすさに影響する。エンハンス案件を提案するプランナーやデザイナーとコミュニケーションを取り、実装の複雑性を下げることが品質担保に繋がる。そのために、開発チームの輪を超えて会話をする必要がある。開発メンバーの特徴を知るコロナ禍、在宅での仕事でメンバー各⼈とのコミュニケーションを取るのが難しくなっていた。時間の解決に委ねてしまったが、メンバーとのコミュニケーションハードルの有無が開発のスピードに与える影響はかなり⼤きかったと⾔える。誰が技術に強く、誰が既存仕様に強いのかなどのメンバーの特⻑把握は重要だった。

Slide 54

Slide 54 text

わからないがなくなり、⾃信とともに案件と向き合えるようになった。 53 ろくに検索ができない。どこにどんな実装があるのか分からない⾔語理解が⽢く、ビルド時にコンパイルエラーが起きることもママアーキテクチャの理解と経験が浅く、コードが綺麗なのか汚いのかもわからない。タウンワークで開発することの難しさをわかってないタウンワークのことを知らない Clear Clear Clear Clear ⾃信を持って開発ができる状態になる。

Slide 55

Slide 55 text

次のステージへ。 54 負債を潰していくこれまでは負債を制約と捉えて実装をすることができるようになったに過ぎない。ここから先は効果の⾼い負債と向き合って解消していける⼈材になっていく必要がある。触⼿をAndroidにのばしアプリならなんでも︕⼈材になるこれまでの学習フェイズで良かったところをつまみ⾷いしてAndroid開発に携わるようになった。オフショアチームと共により開発しやすいチームにする負債解消と案件開発を平⾏でできるチームにするために、オフショアチームを強化していく。これから新規で⼊ってくる⼈たちが『負債と共存しながら、仕⽅なくこうする』みたいな実装をせずに済む未来を作りたい。いずれこの内容の発表ができるように頑張ります💪

Slide 56

Slide 56 text

55 ご清聴ありがとうございました。