iOS Test Night #10 に行ったメモ

ブログを引っ越ししましたので，5秒後に移動します

今月からソフトウェア品質管理部門で仕事をするようになったこともあって，DeNAさんで行われたiOS Test Night #10に参加してきました．

イベント概要

• 2019/04/16(Tue) 19:30-20:30
• 株式会社ディー・エヌ・エー 24F サクラカフェ
• Twitterハッシュタグ: #ios_test_night

目的

XCTTestやXCUITestを使ったテストはやったことがあったけど，PJや組織の特性によってそれ以外に選択・組み合わせ可能な要素にどのようなものがあるか学ぶ．

発表

19:35-19:50 15分枠(1) ぎぎにゃん / Azure Pipelines for iOS使ってみた

• スライド
• Azure PilelinesでXcodeプロジェクトのビルド（テスト）をする話
• 小さい型にはまったプロジェクト（ライブラリとか）なら簡単にCIできる
• パッケージ依存性があったりCDが必要な場合はちょっと面倒
• カッコイイところ
  • 早い，安い
  • macOS/linux/windowsのコンテナが使える！！
  • GUIでパイプライン設定が作れ，YAMLに吐ける
  • ローカル環境のmacOSをスレーブにできる（セルフホスティング）
  • XUITest/Appiumとかも使える
• 適用プロジェクトは限られそうだけど，試してみたい

19:50-20:05 15分枠(2) susieyy / Snapshot Testing

• スライド
• Snapshot Testing
  • 正しいSnapshotとのdiffを取ってテストする
  • テストピラミッドのUTの中で上位に相当するレベルのテスト
  • 状態ごとの画面カタログとしても利用している
• iOS SnapshotTestCaseを使ってる
• 通信やアニメーションの途中でSnapshot取らないような工夫はいくつか必要
• Snapshot Anything
  • 画像だけじゃなくてビューやJSONデータなど，なんでもSnapshotできる
  • ビューのフレームワークと階層など，UIの中でも変更の少ない部分をテストできる
  • よりドメインテストに近いレベルのテストができる
• iOS SnapshotTestCaseはちょっとおよび腰に感じたけど，SnapshotAnythingはアリだなと感じた

20:05-20:10 5分枠(1) imaizume / iOSアプリのテストを書きたいのに書けないあなたへ

• スライド
• まずはすでにテスタブルで書きやすいところから書く
• 大域変数をリポジトリパターンにするなど，テスタブルにリファクタリングしていく
• 設計を責務単位にできるようにしていく
• 良いアプローチだと感じた

20:10-20:15 5分枠(2) AkihisaSengoku / RxSwiftのテスト入門

• スライド
• RxSwiftのObservableをテストするために，RxTestのTestSchedulerを使った
• RxSwiftは使ったことがないけど，そんなにObservableに合わせてテストする必要があるんだろうか・・・と疑問に思った
  • @orga_chem さんが言ってのがその解なのかな？（よくわかってない）

例えば、こういう感じ。 https://t.co/UEg1lrbj3N #ios_test_night https://t.co/FfGausuCSx

— クニワッ (@orga_chem) April 16, 2019

20:15-20:20 5分枠(3) kariad / Viewのテストどうやりますか?

• スライド
• PresenterのテストでViewのテストを代替することもできる
• UTならUIControlやSuccinctが便利
• ROIに応じて適切なテストをしよう
• ところどころ野菜の絵文字が出てきて美味しそうだった

20:20-20:25 5分枠(4) tobi462 / Swift で ParameterizedTest をやってみた話

• スライド
• XCTestではサポートされていないParameterizedTestを自前実装した話
• 単にリストにテストデータを持たせてforでテストしても，どのテストデータがコケたのかわかりずらい
• カスタムassertの実装により，テストデータの行を表示できるようにした
• OSSにした: YusukeHosonuma/SwiftParamTest
• カスタムassert初めて知った

「思考・論理・分析」を読んだメモ

ブログを引っ越ししましたので，5秒後に移動します

波頭 亮 著「思考・論理・分析」を読んだメモです．

思考・論理・分析―「正しく考え、正しく分かること」の理論と実践

読む前の考え

• 人から論理的だと評価してもらうことがままあるが，自分自身が「論理的である」とはどういうことかを言語化できない
• 「分析」が「調査」という意味程度にしか認識できておらず，何をすれば「分析」と言えるのか理解できていない
• 本書を読む目標として，「思考，論理，分析とは？」に対して一言で答えられるようになりたい
• また，今までの論理的思考，分析に足りなかった考えや行動を是正したい

本書の評価

• 思考，論理，分析の定義を端的に言語化できるようになり，適切な論理，分析のために留意すべき点が理解できた
• 随所に図解が挿し込まれていて，これが非常に分かりやすかった
• 個人の知識や特性による思考の違いや，心理が論理の妥当性に及ぼす影響にも触れられていて，単なる理論の解説に終始せず実践的する上での留意を記している点が良い
• 分析における情報の可視化方法（図解方法）は少々冗長なので読み飛ばしても良い
• イシューアナリティクスは，おそらく「論理や分析は方法論であって，問題・課題定義を正しく見据えることが大事」という意味として捉えたが，それと論理・分析とのつながりがいまいちよく理解できなかった

活用

• 他人から「論理的である」と評価されているのは恐らく形式的論理性でという意味合いが強く，自身では客観的妥当性（腹落ち感，本書でいうファクト）はまだ不十分なことが多いのではないかと感じた
  • 因果の強さや直接的連動性（論理展開の距離感）はそんなにズレていないと思う
  • 演繹であれば既呈命題のファクト，帰納であれば観察事象のファクトの根拠をもっとしっかりと用意するようにしていく
• 今まで「分析＝情報収集＋構造化（視覚化）」として仕事をしているところがあり，目的設定と合目的的メッセージのアウトプットが欠けていたように思うので，今後は分析にあたっての目的やプロセスの設定を意識する
• 普段曲がりなりにもディメンションとクライテリアを意識して思考していたが，そのような観点や切り分けの視点を明確に意識していく

先月読んだ本と今月の読書予定（2019年4月）

ブログを引っ越ししましたので，5秒後に移動します

先月の読書実績

漫画，雑誌は除いています．

実績	Fav	本
✅		ロウソクの科学
✅		数学ガール
✅	⭐	フォーカス・リーディング
✅		思考・論理・分析

今月の読書予定

新規・継続	本
🆕	あなたもいままでの10倍速く本が読める
🆕	ソフトウェア工学の基礎
🆕	ソフトウェア工学の勧め(上)

先月読んだ本と今月の読書予定（2019年3月）

ブログを引っ越ししましたので，5秒後に移動します

先月の読書実績

漫画，雑誌は除いています．

実績	Fav	本
✅		エンジニアの知的生産術
✅	⭐	聴く! 技術士二次試験 一発合格のツボ
✅		これからのマーケティングに役立つ、サービス・デザイン入門
✅		Lean UX 第2版
▶		フォーカス・リーディング

今月の読書予定

新規・継続	本
🆕	思考・論理・分析―「正しく考え、正しく分かること」の理論と実践
🆕	あなたもいままでの10倍速く本が読める

LEAN UXを読んだメモ

ブログを引っ越ししましたので，5秒後に移動します

ジェフ・ゴーセルフ著「LEAN UX」を読んだメモです．

Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

ざっくり言うと， エリック・リースによる"前書き"にあるように，「局所的にLeanを実践しているが，組織全体として最適化されていない」問題はよくある話で，それを解決する方法論としてUXに視点を置いて組織改革を行う，という手法です．

読む前に知りたいと思った質問

• リーンスタートアップや他のLEANシリーズとLEAN UXとの違いや関係
• アジャイル開発とLEAN UXをどう結合させるか
• 組織にリーンのマインドを定着させるためにはどのような戦術があるか

全体所感

• LEAN UX＝デザイン思考＋アジャイル開発＋リーンスタートアップ
  • リーンスタートアップとUXベースのデザインを組み合わせ，共生的に共存させるもの
  • デザイナ以外の人もデザインプロセスに関与する
• 重要なマインドセット
  • 透明性の維持
  • コラボレーティブ（全員参加）
  • イテレーティブ
• BMLループを回すことや，小さく失敗し早く成功する価値観はリーンスタートアップと同様に感じた
• ユーザ価値やビジネスゴールと実現方法（機能）を紐つけて，ビジョンから顧客へ提供するものまでを一貫するという点でIMPACT MAPPINGとの共通点を強く感じた
• デザイナ以外の人もデザインプロセスに関与するための方法論が途中まで読んでもイメージが沸かなかったが，デザインスタジオの説明を読んで少し理解できた
• アジャイル開発との共存については具体例があるものの，あまりうまくイメージできなかったので実務の中で試行してみる必要性があると感じた
• デザイナが活動をリードするのが望ましいが，現実的にチームの中でデザイナがその立場で動けるかどうかは組織の文化が強く障壁になりそうだし，難しい組織が多いように感じた．アジャイル開発と同様，いきなりプロセスを適用するのが難しい場合は，LEAN UXのプラクティスを組織課題の解決として小さく適用するところから始めるのが良さそうに感じた．

1章 かつてないほどに高まるLean UXの重要性

• Amazonは平均して11.6秒に一度の割合で本番環境に新たなコードを追加している
• 継続的にデリバリし学習するのがよい
• 機能やドキュメントではなく顧客価値や"効果"（outcome, not output）に焦点を合わせる
• チーム全員がコラボレートし続ける継続的エンゲージメントでは情報伝達のための膨大な資料は不要（アジャイル開発の価値観と同じ）

2章 Lean UXの原則

• LEAN UX
  • ＝デザイン思考＋アジャイル開発＋リーンスタートアップ
    • デザイン思考：人間を直接的に観察することを原動力とするイノベーション手法
  • コラボレーティブかつ部門横断的
  • チームの共通理解
  • デリバリよりも学習
• 原則の要約
  • チームが一体となり，情報が透明性をもって共有され，共通理解されている状況を作る
  • 機能ではなくユーザ中心とした課題解決・顧客価値・アウトカムに焦点を当てる
  • 早く多く失敗し，未検証で顧客価値の無い中間成果物といった無駄を最小限にする
  • 繰り返し形にし，学習を続ける

3章 ビジョン、フレーミング、アウトカム（成果）

• 検証すべき仮説を効果的に正しく設計する方法の話
• 成果に焦点を当てるために，検証ステートメントとして宣言する
  • 課題ステートメントやワークシート（リーンキャンバス，リーンダイアグラムでよさそう）から推測・仮定のリストをつくる
  • 仮説ステートメントに変換する（仮説検証キャンバスでもよさそう）
• 仮説の分類して考える（ビジネスの成果，ユーザ，ユーザの成果，機能）
• ペルソナ作成はイテレーティブに行う（一回作って終わりではない）
• ペルソナの効果
  • 共通理解（「犬」と聞いて誰もが同じ概念を想像しないのと同じ）
  • 自分たちがユーザであるという錯覚の排除
• ビジネスゴールを達成するために起こさせるユーザの行動と，そのために提供する機能，という考え方がIMPACT MAPPINGと共通項が多いように感じた

4章 コラボレーティブ・デザイン

• 仮説定義における実際のプラクティスの話
• コラボレーティブ
  • ≠ヒーローベース
  • 共通理解と当事者意識を促進
  • ドキュメントの量は減る
• デザインスタジオ
  • メンバによるインフォーマルなコラボレーションセッションを補うもの
  • 解決策のブレスト
  • 1-2-4でアイデアの集合知化を行う
  • 結果は常に参照可能な場所に置く
• デザインシステム
  • ビジュアルデザインのフレームワーク（パターン）
  • AppleのHIGが代表的な例
  • （特にプロトタイプにおいては，）一からデザインを考えるのは悪手
  • ソフトェア開発でパターンやフレームワークを使うのと同様

5章 MVPとプロトタイプ

• 実際のMVP構築における留意点の話
• 行動を測定できるMVPを作る
• 学習目標と，そのために必要な計測を意識する（BMLのLから思考する）
• MVP構築と学習効果のROIを考慮する
• 嘘の機能（つながらないボタン）の手法は，必要な際に思い出せるようにしておきたい（ユーザの印象が悪くなることもあるので，用法用量は守る必要あり）

6章 フィードバックとリサーチ

• MVPを評価する話
• コラボレーティブにイテレーティブにリサーチする
  • 「一口サイズ」のリサーチを繰り返す
  • リサーチを専門家に丸投げしない
• 矛盾するフィードバックの対処
  • 異常値は一旦置いておき，次回以降のイテレーションでパターンに沿うかどうか見てゆく
  • 他のソースを使って検証する

7章 Lean UXとアジャイル開発の共存

• 全員が参加し，デザインプロセスをチームメンバ全員で共有する
• プロセス
  • インタラクションデザインとデベロップメントを並行させるスタッガードスプリント
  • ディスカバリとデリバリを並行させるデュアルトラックアジャイル
  • スタッガードスプリントでもデュアルトラックアジャイルでも，人をユニットに分けるのは悪手で，全員がすべてのプロセスに関わるのがよい
  • スプリント計画などのタイミングに合わせてデザインプロセスを設定する方法が考えられる
• デザイナはアジャイル開発プロセスのすべての活動に参加すべきである
• なんとなくわかるが，実際の活動がどうなるのかイメージがつきにくいので，実務で試す必要がありそう

8章 Lean UXの実践に際して組織に求められる変革

• 結果より成果を重視する
• 役割を超える
• 部門横断的
• ワークスペースの設置（同じ場所，中間成果物の掲示）
• BDUP(Big Design Up Front)，アジャイルフォールを避ける
• speed first, aesthetics second
  • 継続的改善，UXの負債の追跡

9章 ケーススタディ

• LEAN UXやその適用系による成功事例の話
• コラボレーティブなデザインプロセスへの変革
• ペルソナとユーザインタビューと共感マップによる認識の補正イテーレーション
• サービスデザインの適用

「エンジニアの知的生産術」を読んだメモ

ブログを引っ越ししましたので，5秒後に移動します

西尾 泰和著「エンジニアの知的生産術」を読んだメモです．

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

全体

• 経験のあるKJ法や，好きな外山滋比古氏の理論がよく引き合いに出されていて，全体的に理解しやすかった
• 第6章「アイデアを思い付くには」が自分にとっては一番理解が難しかったが，フレームワーク依存問題など陥りやすい罠や持つべきマインドが解説されていたのが良かった
• 著者の理論モデルが多くの過去のモデルから成り立ってきたのが読んでいてよくわかり，出典が逐次提示されているので，理論のトレースがしやすい本だと感じた
• 折に触れて読みたい本だった

第1章 新しいことを学ぶには

• 学びのサイクルは情報収集，モデル化，検証
• インプットしたもののまとめや他者への説明などのアウトプットは検証の有効手段
• 自身のインプットのやり方に欠陥があることを思い知った
  • 他人が確立したモデルをそのまま自身に取り入れようとして，理解した気になってうまく活用できていなかった（p43 パターン本から学ぶ）
  • 読むのが遅く，遅すぎて全体像が掴めない悩みがあったが，全部を読もうとするのではなくつまみ食いをすることが大事
  • そのために目標を明確し，全体像を把握する
  • 時間は貴重なのだから，遅延評価的勉強法を考慮したインプットを心がけたい
• やる気を維持するために「ゴールを明確にする・近くする」は普段よく考えていて共感できた
• やる気に関する問題は，最近読み直した「モチベーション2.0」の自律性・卓越・目標の3点に共通していると感じた

第2章 やる気を出すには

• 7つの習慣の「重要事項を優先する」における緊急・重要マトリクスおける「重要かつ緊急」を減らし，「緊急ではないが重要」を増やす（緊急性分解理論）
• GTDでは，価値観はボトムアップで言語化する
• 優先順位付けは比較軸や不確定性から比較が難しく，日々の具体的なタスクを観察（計測）しながら事後的にできるようになる
• ポモドーロテクニックはタイムボックスで終わりを設定することでやる気を持続させるが，スクラム等の手法も同様に感じた
• 通知や割り込みを緊急性の高さと勘違いしてしまうのは陥りやすい罠なので，マインドセットや仕組み化が大事に感じた
• 7つの習慣の「終わりを描く事から始める」はとても共感しており，仕事において必ず意識するようにしているので，本書でも取り扱っていて良かった（終了条件や目的を置かずに仕事をする人のなんと多いことか！）

第3章 記憶を鍛えるには

• 反復的にアウトプットするのが長期記憶化のコツ
• 認知的に高度な作業をした方が記憶にとどまる
• 不適切な難易度によるモチベーションの低下は経験が多々あり，Ankiの自動保留の仕組みはよいアプローチに感じた

第4章 効率的に読むには

• 開いている本・閉じている本（筆者の結論の有無），登山型の本・ハイキング型の本（概念の積み上げの有無）という捉え方は初めてだったので新鮮だった
• 準備の大事さ，段階的詳細化，繰り返し読むこと，のコンセプトは今後の読書で意識していきたい
  • Whole Mind System試してみる
  • フォーカス・リーディングとあなたもいままでの10倍速く本が読めるは読んでみようと思う
• 遅読家で，理解が悪いことと認識しながら読書法の改善を図っていなかった
  • おそらく1度通して読んでおわりと考えているから，読み漏らすのが怖くて時間をかけ過ぎて読んでしまっているのだと思う
• そこで次回の読書からやりたいこと
  • アウトプットを前提として読むこと
  • 1ページ目から通して読まないこと
• 具体的な方法（仮）
  • 目次と導入から読むところを絞りつまみ食いする
  • 章ごとに感じたことや意見や疑問をまとめる
  • 目次に戻り全体マップでの位置を把握する
  • 以下ループ

第5章 考えをまとめるには

• KJ法のA型図解化/B型文書化のステップは知らなかったので実践してみたい
• 新しい構造を生むために，分類を先に決めてトップダウンする（KJ法をやる意味がなくなる）のではなく，ボトムアップで分類する
• 手法のチューニングは確かに大事だが，いきなりチューニングするのではなく，まずは守破離の守のステップとして原則に倣うのが良さそうに感じた

第6章 アイデアを思い付くには

• U理論の谷を下りるために，他人の視点を大事にすることや，SECIモデルを意識することや，フレームワークにしがみつかないことが肝要（自分の枠を壊す必要がある．KJ法において分類を先に付けないことと似ている）
• 他人の視点を理解するために，クリーンな質問（Clean Language）や絵に描くことやNM法などで，抽象概念やメタファから身体的感覚の（具体的な）イメージに解凍する
• なかなか理解が難しい章だった
• アイデアが生まれるのは管理できるものではないという考えは外山滋比古氏から学んでいて違和感がなかったが，アイデアを検証するという考えは自分にとって斬新だった（普段業務で触れているリーンスタートアップの考えなのに，個人のアイデア発想にそれを適用する考えを持っていなかった）

第7章 何を学ぶかを決めるには

• 数学と科学では，正しいということの捉え方が異なり，個人の意思決定はそれらとも異なる
• Steve JobsのConnecting Dotsは事後的にしかわからないので，戦略をベースに学ぶしかない
• かけ合わせ（ふたこぶの知識）や連続スペシャリストによる差別化戦略はよく意識していて，意図的に学ぶものを選択することがあったのでとても共感できた
• いままで社内でひとつの部署に留まらず色々な部署を転々としてきていて，そのことにデメリットを感じていたが，戦略として有効に考えるきっかけになった（人や組織，コミュニティを横断する知識・役割を基盤に成長する）

「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモ

ブログを引っ越ししましたので，5秒後に移動します

「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモです．

これからのマーケティングに役立つ、サービス・デザイン入門 -商品開発・サービスに革新を巻き起こす、顧客目線のビジネス戦略

読む前に設定した「知りたいこと」

• サービスデザインとはなにか，を言語化できるようになる
• カスタマージャーニーの概念と具体的手法を知る

全体

• サービスデザインにおける思考や精神が身につく本で，手法やフレームワークの具体的手法の解説は少ない
• 「解説：日本のサービスデザインの現場」の章で述べられていたが，カスタマージャーニー（に限らず，あらゆるフレームワークや方法論）を使えば問題が解決すると誤解されている例が多いが，なぜそれをするのか（Why）の理論と精神を身に着けないと効果はないと感じた
• その意味でも，具体的手法を実践する前に読むと良い本だった

序章

なぜ（why）？

• ほとんどのことが決めつけや仮説のままシステム化されてしまっている（お役所仕事）
• 「なぜ」（それが必要なのか，その方法なのか，使いづらいのか）を考えることが必要

サービス・デザインとは何か

• ビジネスを顧客目線で体系的に編成する取り組み
• UX（顧客付加価値）を提供することを目的とする
• 購入時点のみならず製品・サービスのライフサイクル全体をデザインする
• 情報を常に正しく提示しないと満足度は下がる
• Whatが衛生要因になったいま，Howが価値を生む
• ここではHowを思考せよとあったが，もっというとStart With Whyが重要なのだろうと感じた

なぜこのプロセスをデザインと呼ぶのか？

• デザインとは価値観やアイデアに形を与えること（無形→有形）
• 理解しやすく，使いやすく，識別しやすく，美しくあることが良いデザイン
• 問題定義のためにカスタマージャーニーマップ，仮説検証，タッチポイントを考える

カスタマー・ジャーニー

要求は決して「もの」ではない

• 顧客の目線で世界を見る
• リアルで意味のある世界にするために対象グループ，ペルソナを規定する
• 購入のタイミングだけでなく，前後・背景を含めライフサイクル全体を考える
• ペルソナから見る世界をモデル化するためにカスタマージャーニーマップ，共感マップを利用する
• 顧客の大半は苦情を訴える行動を取らない（立ち去る方がコストが安い）ので，苦情の発生はその背後に潜在的な苦情が10倍程度あると認識する
• 疑問：ペルソナは考えようと思えば無数に考えられる．必要なペルソナを設定・選定する指針は？
  • 同僚のデザイナの人に教えてもらった
  • 例えば
    • 対象のサービスの特性から考えられるユーザグループを，相反するユーザ特性を考慮して軸で分ける
    • 例えば，2軸でユーザグループを分け，各象限ごとに代表的なペルソナを作る
  • 単に設定したペルソナだけではなく，上記ユーザグループの全体像があると，ペルソナの妥当性（そのペルソナが対象ユーザに当てはまること，例外的でないこと）を他者へ説明する際も，論拠がしっかりする

仮説の検証

• 量的データ・ビッグデータには過去の購入した情報だけしかなく，背景・カスタマージャーニー・Whyが含まれていないので，トレンドを把握するには役立つが，思考や感情を洞察するには役立たない
• インタビュー，グループディスカッション，ワークショップを正しく行い洞察を得るためには，注意深い設計とファシリテーションが必要（対話法，観察法の習得が必要）

顧客接点（タッチポイント）

• 事業体が提供する価値と顧客が受け取る価値が食い違っていないかに注意する（機能や性能がすでに衛生要因になっていないか，など）
• テクノロジの進化と現実世界の課題・変化により，顧客は不満を表明し公にする強い力を得た
• カスタマージャーニーの中で，顧客が受け取る価値が最も高い顧客接点を考察し，その場面のUXを高める

この種の課題への組織的な取り組み

• 責任者の不在，組織のサイロ化は耳の痛い話で，サービスや製品の改革以前に組織改革が重要という主張は素直に同意できた