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