勉強会：Bonfire iOS #3 に参加してきた。
さて、気づけばどうやら久しぶりのブログ更新のようです。
今回は、Bonfire iOS #3 というヤフーが開催しているIOS系の勉強会に参加してきました。 yj-meetup.connpass.com
第3回の今回のテーマは「品質」ということで、様々な会社・プロダクトに携わっている方たちが品質について発表してくださいました。
iOSの勉強会というと、開発Tipsやテストといった技術的なテーマが多い中、面白いテーマだなぁと思いました。
いつものように箇条書きメモ＋感想みたいな感じで順番に書いていきたいと思います。 スライドがアップされたら更新していきたいと思います。
Yahoo!天気アプリを少人数でも支えられた理由
- 自己紹介
- iOS歴3年
- Swift
- 大阪から
- Y天気アプリ
- 利用者あわせて600万
- 天候があれると1000万
- 統合ランキングでも1位をなんども
- 体制
- 企画
- メンバーと新機能を決める
- PMもエンジニア経験ある
- 企画が実装も踏まえて話を進めてくれる
- Sckethでエンジニアがプロと
- 職種の垣根をこえて進められる
- 開発フェーズ
- 最初から実機で進めている
- シミュレータでは感じられない操作感などがわかる
- デザイナーに見てもらうときも、いろいろな実機をもっていく
- ヘルプデスクから端末を借りられる
- テストフェーズ
- 天気アプリならでは
- 天気情報を見せるのがメイン
- 入力などはないのでそのあたりのセキュリティなどの考慮はあまりない
- プラットフォームが整っている
- 生活の一部
- 毎日起動されるアプリなので、見た目の品質が重要
- ユーザは細かいことでも気になる
- コンテンツの品質
- 災害発生時の動き
- 8面モニタで情報収集をしている
- 災害発生時にすぐに分かるように
- 8面モニタで情報収集をしている
- サービスマネージャが天気予報士の資格を持ってる
- 予想しながら動くことも
- アプリチームは？
- ユーザが必要そうな情報は発信
- 手動で通知をうって、ユーザに知らせる
- チャット上で通知の文言を相談する
- 事実を提供する
- 災害時
- 一部はWebViewなのでデザイナが更新できる
- 災害が落ち着いてから情報が十分だったか振り返り
- ピンチのときにユーザを助けてこそ会社の信頼につながる
- 災害発生時の動き
- まとめ
- 少人数PJを支える強力な社内システム
- 見た目に徹底
- 他
- MixLeap
- 大阪2拠点になります
- 毎週イベントを開催している
- フォロー歓迎（Twitterアカウント）
- MixLeap
私も普段から利用している「Y!天気」アプリの発表でした。
まず、iOS/Androidエンジニアが1名ずつという点に驚きました。そういった少人数でも品質を保つ大勢や仕組みが非常に参考になりました。
参考になることばかりだったのですが、あえてピックアップするとすれば以下が特に参考になりました。
- 前バージョンからのコード差分を見る
- 毎日起動されるアプリなので、細かいUIについても拘る
- サービスマネージャが天気予報士の資格を持っている
当たり前な品質を支える様々な仕組みと、天気というサービスに特化した品質の考え方が取り入れられていて、とても戦略的にサービスを開発・運用しているのだと強く感じました。
iOS アプリエラー監視のための設計と効果
- 自己紹介
- 開発速度を2倍にした
- 趣味はTODO
- エラー監視とは？
- アプリで発生したエラーをサーバに送る
- クラッシュレポート
- Crashlyticsなど
- クラッシュ以外のエラーも監視できる
- 内部状態の不整合とかも
- エラー監視の特性
- 広範なバグを検知
- 発見が遅い
- バグが埋め込まれてからの時間が短いほうが嬉しい
- 特殊ケースのバグは発見が遅くなる
- 下から2つ目
- 最後の砦
- ユーザからの問い合わせはあるいみNG
- 理想のバグ検知
- ダメ検知
- 発見までの時間が長くなる
- エラー監視は特殊なバグを検知する手段
- それ以外はそれより前のフェーズで見つけるべき
- エラーレポーターをカスタマイズ
- NSErrorではなくSwiftのErrorで送信できるように
- 発生元のオブジェクトを渡す
- DEBUGと本番を分ける
- DEBUGでも送信したほうがベター
- 区別できれば良いのではないか？
- NSErrorへの変換
- domain/codeで設定される
- 発生元をreporterとしてdomainに含める
- エラーメッセージを含めてはいけない
- 同じ不具合が別のバグとして分類されてしまう
- 実際に組み込む
- ハードコード
- 単一責務原則に違反する
- 単体テストでエラーレポートが送信されてしまう
isTestフラグ
- Observerパターン
- エラーReporterを監視者として、エラーが発生したら送信
- テストの時にはエラーレポーターを使わない
- Observerパターンを使える場所は限られる
- Modelはだいたい監視できる作りになっているはず
- RxのObservableを使っている
- エラー監視にはObserverパターンが適している
- ハードコード
- 困ったケース
- 結果
- ユーザの手元で発生しているバグの種類や規模を把握できるようになった
- 重要度のジャッジが出来るようになった
- ユーザの手元では予想外のエラーが起こっていることに気づく
- 特定のキャリア回線で発生する不具合など
- Sandboxのレシートじゃないと再現しないとか
- 副作用
- テスターの動作確認中にエラーレポートが飛んでくる
- ユーザの手元で発生しているバグの種類や規模を把握できるようになった
- まとめ
- エラー監視で、テスターが発見できない不具合が発見できる
- 宣伝
- ランチ募集
モバイルアプリの開発において、避けては通れないエラー監視をどのように扱うか、またどのように設計したら良いかという発表でした。
Twitterのタイムラインでも話題になっていましたが、エラーの種類とそれがどこで発見されるべきかという図がとても分かりやすかったです。こういったことは開発が忙しくなると特に忘れがちなので、こういった図にまとめられているととても良いと思いました。（チームメンバーが見える位置に貼っておくというのもありかと思いました）
そしてエラー監視の設計についてはObserverパターンを利用すると良い、という話が後半でした。Observerパターンを採用することで、単一責務の原則を守ることが出来て、かつ不要なときは観測者（Observer）を外せば良い、という考え方はよくできているなぁと思いました。
あと、エラーレポートに詳細なメッセージを含めない、DEBUG環境でも区別できるようにした上で送信してしまう、というのも参考になりました。（私が以前関わっていたiOSプロジェクトでは、DEBUG時は送信しない設定にしていました）
スタートアップでのQA
- 自己紹介
- QA？
- 会社や組織によってまちまち
- 入社時の肩書として、QAエンジニアを選んだ
- プロダクトの品質を広範囲でサポートしたい
- テストは品質保証の一手段
- 2年間でやったこと
- 価値の高いテストに集中する
- テストに限られるリソースは限られている
- 関係者を巻き込む
- セールス・サポート：おさわり会
- E2Eテストは同じリポジトリで管理
- QAエンジニア以外でもテストコードをかけるように
- 自動化
- 時間ができたら自動化に取り組む
- テスト・デプロイの自動化
- 開発・運用の持続可能性を高める
- TORETAはプロダクトのライフサイクルが長い
- 5年・10年、それ以上も？
- ドキュメント
- 書くのもメンテするのもかなりのコスト
- 書きすぎないを意識（問い合わせがあったら書く、くらいの感覚）
- 手動テストケースを追加した理由を残す
- 長く時間が経つと、なぜ追加したのかわからなくなることも
- Markdownで書いて履歴として管理する
- 長くプロダクトを育てていくために
- サポート運用の課題を技術で解決する
- サポートの意見を製品に活かす
- サポートチーム、アカウント管理チームと週1ミーティング
- お知らせ機能
- 問い合わせ番号
- 設定画面の文言改善
- まとめ
- スタートアップは総力戦（みんなで協力する）
- 顧客のことをよく知る
- 価値が高いことに集中する
- プロダクトの問題をプロダクトだけで改善しない
- プロダクト品質 x サポート品質
- お隣さんとはアイディアが眠っている
飲食店向けのiPadで予約管理できるサービスにおいて、QAエンジニアとしてどう関わったかという発表でした。QAエンジニア歴10年ということで、参考になる話ばかりでした。
個人的には、顧客やプロダクト、サービスの性質（ライフサイクルが長い、B2B）を考えた上での取り組みが行われていることが、とても素晴らしいと感じました。とくに「顧客のことをよく知る」というのは品質を考えていく上でとても大切なことだとあらためて思いました。
ちなみにテストケースをMarkdownでバージョン管理するというやり方は、以前取り組んだものの失敗した経験があるので、機会があればもう一度挑戦してみたいなと思いました。
QA組織とiOSのテスト
- 自己紹介
- LINE株式会社
- サービスQAチーム
- LINEファミリーアプリを担当
- QAエンジニア歴9年
- 社内インタビュー
- QAエンジニアのロール
- QA？
- テスト管理全般をする
- 上流からどういうテストが必要可考えて、プロダクトの品質を評価
- SET
- テスト自動化
- Tester
- 手動テスト
- QAエンジニアに必要なスキル
- 幅広いスキルセットが必要
- チームにQAとしてアサイン
- 静的テスト
- インスペクション（仕様レビュー）
- 欠陥の防止
- 動的テスト
- ブラックボックステストとか
- 欠陥の摘出
- QA？
- 品質評価の考え方
- 取り組み
- テストケースの見える化
- テスト実行結果
- テストケースは誰でも見えるように
- テスト結果とBugを紐付ける
- どのテストによってBugが生まれたか開発者がわかりやすい
- グレーボックステストのアプローチ
- iOS固有のプラットフォーム
- テストしている側がプラットフォームを理解していない
- テスターもヒューマンインターフェースガイドラインを読む
QA組織としてどのようにプロダクトの品質を判定、リリースしているかについての発表でした。
BTSなどのメトリクスをきちんと測った上で、QCDとのバランスを考えた上でリリース判定しているというのが非常に良いと思いました。
私は以前とあるプロジェクトで開発していた時にQA組織がメトリクスを測っていたのですが、とてもレアケースな不具合が（一般的に想定される利用ケースではまず発生しないようなもの）多くあったことを理由に品質が不十分であると判定された経験がありメトリクスについては懐疑的でした。（QA組織はきちんと仕事をしてくださった、とも言えますが）
今回の発表ではメトリクスを測った上で、それだけを正解（あるいは正義）にしていないのが個人的にはとても好印象でした。
あと品質の見える化を行うというのは、とても良い試みであると感じました。
SmartNewsアプリの品質
SmartNewsアプリの品質 from firewood
www.slideshare.net
- 自己紹介
- 荒巻 賢一
- 趣味：いろいろ
- SmartNewsの品質
- ニュースコンテンツへのこだわり
- アルゴリズムを改善し続ける
- 広告へのこだわり
- 広告もコンテンツの一部である
- ピクセル単位で調整したり
- 開発
- ブランチ：git-flow
- pushでXcode Serverでビルド＆テスト
- prototypeでベータ配布
- スプリント
- iOS/Androidで2週間単位
- QAは1週間単位で交互にテスト
- iOSの標準に従いつつ必要なら変更
- けい素解析で折り返し
- なめらかなページめくり
- BTS
- Apple Developer Technical Support事例
- iOS 9.0のみでクラッシュ
- WKWebViewのキャッシュがたまり続ける
- アプリ実装のこだわり
- 星マークの歪み
- AppStoreでは正方形に内接（星としては歪み）
- クリスさんより（XCUITest）
- ゴールデン街に詳しい人はぜひ
- ビルドサーバの構成
- サーバは2台
- Productionビルド用
- Testビルド用
- Xcode Serverの次バージョンを確認
- 問題なければProductionにインストール
- 本物のハードウェアやシミュレータでUIテスト
- UIテストは時間がかかるので、Production用のビルドに影響しないように
- XCUIAutomation
- Obj-C
- accessibilityIdentifier: ローカライズに依存しない
- accessibilityLabel: 目が見えない人のため
- VoiceOver用のステートが入っている
- ツール
- push simulation
- log exposure
- Swiftでユーザの操作のようにテストが書ける
- enumが使いやすい
- nestedなenumにするとコード補完で画面のエレメント構造がわかる
- namespaceとして使う
- Objc-Cブリッジが不要
- アプリ内のステートを公開する必要はない
- 世界中の良質な情報を届ける
SmartNewsアプリの品質への考え方や取り組みについて、2名からの発表でした。
前半はSmartNewsアプリの品質についての取り組みについての発表でした。
SmartNewsはアプリ実装について結構なこだわりを持っているとのことで、なめらかなページめくりや良質な見た目など、UI/UXにとてもこだわっているとのことでした。このあたりは求められる（あるいは目指す）品質が、プロダクトやサービスなどによって全く異なるということをあらためて思い出させてくれました。
後半はビルドサーバやUIテストの実装についての発表でした。
ビルドサーバは2台構成にしていて、新しいものを導入する時には1台のマシンに導入した上で、問題がなければ新しいマシンにも導入する、といったビルド環境を壊さないようにする取り組みは参考になりました。
XCUITestについては、enumを名前空間（ネームスペース）として利用する方法は良いなと思いました。静的型付けでIDE上でコード補完が効くSwiftという言語を有効活用した、良い方法だと思いました。
ところでSmartNewsは「世界中の良質な情報を必要な人に送り届ける」というミッション（あるいはビジョン？）を持っているそうです。
”船を作りたければ、海へのあこがれを説け”という有名な言葉がありますが、プロダクトやサービスがこうした向かうべき方向についての軸を持っているのは重要だとあらためて思いました。
短期大規模開発の品質とスピードの両立について in ライブコマース
- 自己紹介
- 開発工数3ヶ月で無事故でライブコマースを乗り切った
- ライブコマース？
- アプリをタップするとライブ動画が配信される
- いいね、コメントなどを複数のアプリで共有する
- ライブ配信
- RTMP（RealTimeMessagingProtocol）
- NGINX
- CDN
- 視聴アプリ
- HLS
- Appleが企画したライブストリーミングの企画
- キャッシュとかもできる
- やることいっぱい
- デモアプリのメリット
- 完成のイメージを固められた
- 実現への自信が持てた
- 社内での説得力がます
- 有識者とのコミュニケーションもできた
- コードを流用できる
- 実際に本番コードに組み込んで流用
- 簡易動作確認環境
- 問題の切り分けに繋がった
- 品質・スピードを上げることができた
- テスト
- 振り返り
- Good
- ミニマム開発から広げることができた
- 社内から知見のある人を見つけることができた
- 精度の高いテストができた
- Bad
- 省いたところはある
- Good
ライブコマースという、アプリからライブ動画を見れて、そこでの「いいね」やコメントなどを複数アプリ感で共有する機能の開発を短期間で行った際の取り組みについての発表でした。
よく言われることですが、実際に動く簡易版の実装を行うことはとても大切、かつ効果的だとあらためて思いました。特に自信への繋がりや、有識者とのコミュニケーションに繋がったのは、とても良いと思いました。
あとは社内で利用者を集めて、本番同等の環境でテストを行うという取り組みはとても良いと思いました。やはり開発時には気づかない不具合も出てくるので、品質を上げるためにはそうした取組は必要だと思いました。
全体を通して、とにかく戦略的に開発を行ったのだという空気を強く感じました。
懇親会
お寿司を頂きました、美味しかったです！
感想
あまり他のiOS勉強会では話題に上がらない「品質」というテーマで、バラエティに富んだ発表を数多く聞くことが出来てとても有意義な勉強会でした。
私があらためて思ったのは、プロダクトやサービスによって品質の考え方は異なるということでした。画一した「品質」というものは存在せず、品質の考え方については結局自分たちで考え抜かなければならない、ということです。
それを実現する上で、様々なプロダクトやサービスにおける実際の取組みが聞ける、というのはとても良いことだと思いました。（おそらく発表者の方々も、他の発表で得るものがあったのではないかと思います）
勉強会の企画・運営をしてくださった方々にお礼申し上げます。
蛇足
久しぶりのブログのせいか、なんだか文章が稚拙な気もしますがご容赦を。
