【読書メモ】コーチング以前の上司の常識「教え方」の教科書
- 作者: 古川裕倫
- 出版社/メーカー: すばる舎
- 発売日: 2012/07/12
- メディア: 単行本
- クリック: 2回
- この商品を含むブログ (2件) を見る
コーチングとティーチングは使い分けが必要と言いますが、どう使い分けるのかはあまり明確ではありません。この本は基本的なことはコーチングに頼る前にしっかり教えるべきという主旨でまとめられています。
「教える」ことで、部下はかならず成長します。これが、どんな手法よりも一番シンプルで、着実に部下が成長するやり方なのです。
一方で、以下のようにも述べています。
いつまでのずっと一方的に教えよと申しているわけではありません。ある一定のレベルに達したら手綱を放して、よき相談相手として意見を求め、リスペクトすべきです。
どいういう部分がティーチングに適しているのかを理解することで、コーチングとティーチングを使い分けるための参考できると思いました。その基本の「教え方」の流れをピックアップしてまとめます。
教えるときの心構え
まずは教える側の心構えについて解説されています。全部で10の心構えについて解説されています。個人的に特に重要だと感じたのは以下の2点です。
- 自分の成長なくして、部下の成長なし
- 待つのも仕事
基本の「教え方」
- 部下の実力を見抜く
- まずは教える相手の実力を知る
- 長所／短所
- 褒めて伸ばす／叱って伸ばす
- 行動力
- 理解力
- プラス思考／マイナス思考
- まずは教える相手の実力を知る
- 仕事の流れを説明する
- 完成形を見せる
- ゴールのイメージ
- 分けて指示を出す
- ステップごとに区切る
- 時間の目安を伝える
- ToDoリストを作らせる
- スケジュールを共有する
- タスクや締め切りの見える化
- 決めたとおりに実行する
- 先入れ先出しで、なるべく予定を変えない
- 3つの責任
- 結果責任は上司
- 遂行責任は部下
- 報告責任は部下
- 3つの報告
- 結果報告
- 経過報告
- 完了報告
- 報告の形
- 要件
- 結論
- 理由・経緯
- 事実と推測を分けて伝える、所感は最後に聞く
- 着実に進行させる
- ごまかしや曖昧を指摘する
- 完成度を上げる
- まず「精度」を求め、次に「スピード」を求める
これらの基本はしっかり教えることで部下が成長できるとして、具体的な「教え方」がまとめられています。最近は一人ひとりの自主性を重視してあまり直接的な指導をしないケースもありますが、これらができていない場合は本人の経験や気付きに任せるのではなく、まずはティーチングとしてしっかり教えるべきということだと思います。これらを整理してチェックリスト化し、コーチングなどの手段に入る前の教育段階として指導すると良いかもしれません。
困った部下の「教え方」
次に、具体的な状況ごとの教え方について解説されています。
- やり方に問題がある
- 指示と違うことをする
- 仕事の質が悪い、仕事が雑
- すぐ知ったかぶりをする
- 期限を守れない
- 何でも依頼を引き受けてしまう
- 余裕を持って仕上げることを知らない
- 完成度にこだわりすぎる
- 何度も同じ間違いをする
- ケアレスミスが多い
- 仕事のツメが甘い
- 単純作業で手を抜く
- 報告が中途半端
- 悪い報告が上がってこない
- 報告が少ない、詳細を話さない
- 報告をメールで済ませる
- 積極性に欠ける
- 曖昧な返事で結局やらない
- 会議で発言しないで後で文句を言う
- 評論家気取りで動かない
- 周りの士気を下げる
- よく遅刻する
- 自分の仕事しかしない
- 言い訳が多い
- 客先で上司の話の腰を折る
これら全てが必ずしもコーチングが不要というわけではないかもしれませんが、経験させる・任せるだけでは育たないケースであることは意識しておくと良さそうです。あるあるの事例が集まっているので、本書の教え方も参考にしてコーチングとティーチングを織り交ぜて教育するのが良いのだろうと思いました。
ワンランク上の「教え方」
最後は自主性を引き出す教え方について書かれています。
- 決断させる
「1つだけ大事なことを言いなさい」
一人前＝意見を持ち＋行動に移す
ドラッカーの引用
リーダーのしごととは目標を明確にして成果を出すこと 目標を達成したら、リーダーは次の目標を作れ
このレベルまで来るとコーチングの要素のほうが強いかもしれません。実際に書いてある内容もコーチングに近いと感じました。このあたりでティーチング要素からコーチング要素へ割合を転換していくのが良いということだと思います。
全体通して具体例を元にしてあるので読みやすく、基礎をしっかりティーチングして、徐々にコーチング要素を増やしていく過程を理解するのに役立つ書籍でした。
【読書メモ】生きている会社、死んでいる会社
生きている会社、死んでいる会社―ー「創造的新陳代謝」を生み出す10の基本原則
- 作者: 遠藤功
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2018/02/23
- メディア: 単行本
- この商品を含むブログ (3件) を見る
BOSSとの1on1で話題にあがって興味を持って読んだ本です。タイトルから分かる通り会社の経営者やマネジャーが読むようなゴリゴリのビジネス書ですが、変化の激しい現在のビジネス環境に沿った内容なので、アジャイルの思想に通じる部分も多く現場の視点で読んでも参考になる部分はたくさんありました。アジャイル開発は、ビジネスから切り離された従来のモノづくりの工程を見直し、ビジネス側に引き込むことを目指して考えられた開発手法であることを改めて感じました。そして、この本の内容が理解できてもアジャイル開発は理解できないというのは矛盾を孕んでおり、EMが現場をアジャイルに変えれないのはミドルマネジメントとして「生きている会社」への道筋を作れていないかもしれないという危機感にもつながってきます。
というわけで開発の現場のリーダーやマネージャーも読むべき本かと思います。実際、ミドルマネジメントの重要性にも1章まるごと割いて触れています。以下の記事でも著者自身が解説しています。
書籍は3部構成になっています。開発の現場視点で個人的に刺さったポイントをまとめておきます。
会社の目的は「創造」
会社は社会に必要とされる限り存続し続けることができる。これを突き詰めると、会社の目的は社会や顧客が必要とする価値を「創造」し続けることであると述べられています。
挑戦ー実践ー創造ー代謝
挑戦と実践の重要性として、Googleのエリック・シュミットの以下の言葉が引用されています。
プロダクト開発はより柔軟で、スピードが求められるプロセスになった。劇的に優れたプロダクトを生み出すのに必要なのは巨大な組織ではなく、数え切れないほどの試行錯誤を繰り返すことだ。
創造し続けるためには挑戦と実践も重要であり、会社が為すべきことは「挑戦ー実践ー創造」の3つに集約されるとしています。
そして、生きている会社であるための最後のピースが「代謝」です。著者は、経営は「老化との闘い」とも述べています。生きている会社であり続けるためには、定期的な新陳代謝を行い、新たな「挑戦ー実践ー創造」のサイクルを生み出すのです。
業務改善の4つの視点「ECRS」
本編とは少し話がそれますが、代謝のための業務改善の視点として「ECRS」が紹介されています。大事なのはこの順番に改善を進めることです。
- Eliminate（やめる）
- Combine（集約する）
- Replace（代替する）
- Simplify（簡素化する）
「生きている会社」の3つの条件
熱
会社を創業したときの熱気や高揚感を共有し、広げていくことの難しさとして慶應義塾大学の清水勝彦教授の言葉が引用されています。
経営理念があるとか、ないとか、ビジョンが明確だとか、明確でないとかというのは、本当はあまり意味のない議論です。大切なのは、経営理念、ビジョンの意味を自ら実感・共感できるかどうか、イメージできるかどうかということであり、納得することです。ですから、言葉だけでなく、その背景、ストーリーを語らなければ、理念の共有は難しい。 逆に言えば、言葉なんてどうでもいいのです。
これは経営だけでなく、組織やプロダクトに対しても昨今ではよく言われることです。
理
現実と向き合い、徹底的に理詰めすることの重要性も述べられています。
大切なのは現実と向き合い、「事実」（fact）に徹底的にこだわることである。 一次情報にこだわらなければ、リアリズムのある「理」にはなりえない。底の浅いロジックよりも、たとえ断片的ではあっても「決定的な事実」（conclusive fact）こそが「理」を担保する。
ここでは変化の激しい現代の状況を表す「VUCA」という言葉も紹介されています。
- Volatility（不安定性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（曖昧模糊）
また、陳腐で平凡なことも徹底的に磨き上げるこもと重要であるとし、そのポイントの1つである「スピードを武器にする」ことについて以下のように述べています。
- 敏捷性（agility）は非凡な移動速度だけでなく、動作の方向性を正確に決定する判断の質や速さも含まれている。つまり「速さ×的確性」が敏捷性である。
- 変化が常態化している中では、実行したあとの「リアクション」、つまり学習、対応のスピードの重要性が高まっている。
情
情とは人の「心」のことであり、
「生きている会社」になろうと思うのであれば、人の「心」が仕事にあらわれるような努力と工夫が不可欠である。
と述べています。全員がやりがいを感じて働いている会社が生きている会社なのです。
どうすれば「生きている会社」をつくることができるか
具体的にどうするかについて、実践すべき「１０の基本原則」がまとめられています。ここは本書の大事な部分だと思いますがとても書ききれないので本書に譲ります。
「突破する」ために必要な6つの力
生きている会社にとって、突破するミドルマネジメントが重要であるとしています。マネジメントの中で比較的若い層でじっくり取り組むだけの時間があり、リスクをとって挑戦できるポジションであるからです。「突破する」とは生きている会社のための「挑戦ー実践ー創造」を推進することです。そのために、ミドルマネジメントは6つの力が必要であるとしています。
- 観察する力
- 跳ぶ力（発想転換）
- 伝える力
- はみ出る力
- 束ねる力
- 粘る力
リーダーに求められる5つの資質と行動様式
最後に生きている会社を支えるリーダーに求められる5つの資質と行動様式をピックアップします。現場のリーダーにとっても大事なことだと思います。
- 時代に先んじる
- ネアカである
- 現場に寄り添う
- 逃げない
- 最後は責任をとる
※参考
【勉強会メモ】Mobile Act OSAKA #10
- 日時：2019/07/26(金) 18:40 〜 21:30
- 場所：Osaka Innovation Hub (大阪イノベーションハブ)
前回は予定が合わず、久々となりましたがMobile Actに参加してきました。いつもはiOSネタが多い印象がありましたが今回はFlutterあり、UI/UXネタありと幅広いテーマで面白かったです。別の用事があって懇親会はほとんど参加できなかったのが残念でした（いつもおいしいビールが出るので…）。エチゴビールの新製品は自分で買って飲みます。
なお、次回もすでに募集が始まっています。
TakuyaOhashi 「5分で振り返るFlutter」
Flutter
使い方
- 公式からFlutterダウンロード
- Android Studioのプラグイン導入
- Material Designのwidgetが豊富
- iOS向けのテーマCupertinoもある
- AndroidとiOS別々にもできる
React/Native,Xamarinと何が違う？
- ReactでもC#でもない
- レイアウトのパーツはすべて自前
- 全く同じにできる
アクションシート
ネイティブのコードでそれぞれ実装する場合
- MethodChannel
- Event
- PlatformView
PlatformViewWidget
- ネイティブのViewをFlutterの画面に描画できる
- AndroidView,UiKitView
Flutter Webはどう？
- まあまあいい感じに動く
- Chrome以外は不安定
SwiftUIとかJetpacComponse
Unity UI Widgets⇒こんなのもあるらしい
- Flutterから派生してUnityでFlutterっぽく記述
KatsukiNakatani 「Android Material Component 1.1」
Material Components
- マテリアルデザインを実現するためのUIライブラリ
- 旧ADSL（Android Design Support Library）
- appCompatのAndroidX移行とともにADSLもMaterialComponentに
- Refactor to AndroidXを実行するとAndroidX化とともに変換される
バージョニングの変更
1.0.x- 基本的にネームスペースが変わっただけ
1.1.x- 大幅に変わる
- まだAlpha版
テーマ継承元の変更
1.0.x- Theme.AppCompoat
1.1.1
まとめ
- AndroidXへ移行してMaterialComponentに変更
- 新しいスタイルも増えて柔軟にデザインできる1.1.xはおすすめ
usami-k 「SwiftUI による ViewController からの解放」
Swift UIとは
特徴
- 宣言型シンタックス
- UIをシンプルな記述で実現
- データバインディング
- デザインツール
- コードとプレビューの同期
- コードでもプレビューでも編集できる
- 複数のプレビューを同時に確認できる
- すべてのAppleプラットフォームで
SwiftUIとViewController
UIKitからみた場合
- ViewControllerがない
- 重要な役割だった
- 扱いが難しく厄介な存在
- 実装がふくれあがる傾向
- アーキテクチャ設計を使う最いどの立ち位置で扱うのが難しい
- ViewControllerで悩まなくていい
役割
- 画面の管理
- UIパーツのレイアウト
- 画面のライフサイクル処理
- 画面とデータとの連携
- ユーザーからの入力受付
- データの変更を画面に出力
SwiftUIでは
- View
- UIパーツのレイアウト
- 画面のライフサイクル処理
- Combine
- ユーザーからの入力受付
- データの変更を画面に出力
役割の分離
各種アーキテクチャの実装の再考
SwiftUIとUIKit
UIKitを利用する
- UIKitでできていたことがSwiftUIでできないケースがある
- UIコンポーネントが足りない
- 部分的にUIVIewやUIViewControllerの助けを借りる必要がある
UIViewの利用
- UIViewRepresentable protocol
- 公式ではMapKitのMKMapViewをSwiftUIのViewとして扱う例が紹介されている
UIViewControllerの利用
- UIViewControllerRepresentable protocol
- 公式では（以下略
結局ViewController使ってる
- とはいえSwiftUIのViewの役割
まとめ
- 悩みが減った
- シンプルな実装でUIが作れる
- データバインディングは今後の課題
numa08 「What/Why/How MVVM」
What
- iOSアプリ設計パターン
- 作者: 関義隆,松館大輝,史翔新田中賢治鈴木大貴杉上洋平
- 出版社/メーカー: PEAKS
- 発売日: 2018
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
※追記
Amazonでは取り扱っておらず こちら から購入可能とのこと。
著者のかたからご連絡を頂きました。
Why
How
- FWを分けた
- 想定していない依存が生まれないように
- ビルドの高速化
- すべての画面をUIViewCon
- ViewModel
- Input
- Output
- bind
- StoryBoardを用意
ai 「SoftwareDesignerのしごと」
みんなSoftwareDesigner
- UI Designer
- UI Engineer
- DesignEngineer
- UX Designer
- Graphic Designer
- UX Engineer
ソフトウェアは何でも作れる
- 道具と人
- 人と道具は共進化
道具
- 創造的で自由な道具
- 抽象度の高い道具
- Modal⇒抽象度 低
- Modeless⇒抽象度 高
抽象度の低い道具
- Model
抽象度の高い道具
- 初めてなのによくわかる使いこなせる
できるだけModelessで作ろう
原則
- Object-Verbの操作構文
- 対象が見えていて、任意の順序でアクセスできる
- 直接的かつ可逆的な操作
- 状態変化をリアルタイムにフィードバック
ソフトウェアは何でも作れる
- 何でもObjectにできる
- 何でも実在化できる
何をエンパワーするか？
- それをデザイナーがする
参考
Modeless and Modal
itok 「Background App Refresh Taskがやってきた」
Background App Refresh Taskがやってきた
Background Processing Task
- 数分動ける
- DBのメンテナンスとかMLの学習とか
準備
- capability→background modes
タスクの識別子を列挙
タスクを登録する
- 投入する
- 実行
- キャンセル処理ができる
- パラメータ
- earlistBeginDate
- 遠すぎる未来はだめ
- 1週間以内くらいが望ましい
- 最短なので実行されるとは限らない
- 遠すぎる未来はだめ
- processing task
- requiresNetworkConnectivity
- requiresExternalPower
- CPUを使う仕事をする場合はtrue
- earlistBeginDate
- デバッガからタスクの実行や期限切れをテスト可能
fukumoto 「本当にあったハイブリッドアプリの怖い話 納涼スペシャル」
恐怖!死者のプラグイン
怨霊?!無人のはずのプロジェクトにビルドエラーの影
- Monaca上のプロジェクトが突然ビルドできなくなった
- Gitログでは改変されていない
- Monaca上のソースを確認
- cordova-plugin-firebaseがGoogle側の仕様変更でビルドエラーになる
怪奇!音もなく消えるプラグイン
- 要件に合うプラグインを探していた
- 見つからなかったので有償のプラグインを購入
- 事前の動作確認はしていた
- いざ実装するとメソッドはない
- Androidのみバージョンがあってなくてビルドエラーを起こさずに静かに除外されていたことが判明
- Monacaではビルド成功時、ログがあとから見れない
阿鼻叫喚！恐怖の公式issues
- 有償プラグイン
- どうしてもうまく実装できていない
- しばらく検証
- 公式のバグを疑い始める
- 高圧的な公式サポートで助けを求めれなかった
プラグインによる怪奇現象があとを絶たない
- お参り（サポート常用確認）
- 供養（廃止と実装のやりかえ）
↑が必要
yukihiko_a 「iOSで3Dの姿勢推定のONNXモデルを使ってUnityちゃんを動かしてみた」
- 姿勢推定（Pose Estimation）
- RGB画像から人体の姿勢を推定する
- 顔認識のからだ版
- 関節一（肘や手首）の部位を特定
- 主に DLを使う
ONNXとは
- Open Neural Network Exchange
- DLのフレーム枠感で学習モデルを好感する
- すべてのFWをサポートしているわけではない
- 新しい論文の技術が取り込まれるには時間がかかる
姿勢推定を学習→ONNX→COreMLToolで変換→CoreMLで実装
実際に作ってみたアプリ
【勉強会メモ】PWA Night OSAKA キックオフ ～PWAのミライや活用方法をみんなで考えよう～
- 日時：2019/07/23(火) 19:00 〜 22:00
- 場所：TAMコワーキング大阪
PWAってなに？トレンドの背景を考えてみる
角谷さん@TAM
PWA＝次世代のWeb体験
https://appsco.pe/ PWAで作られたサイトの一覧
いざ調べてみると概念的すぎてよくわからない
Googleの説明
- Reliable
- Fast
- Engaging
特徴
- オフライン対応
- プッシュ通知
技術面
- Service Worker
- Manifest
本質はよりよいウェブ体験をつくること
⇒PWAは（最新の環境に合わせた）先進的なWebアプリケーションのこと
先進的？
- ブラウザは絶えず進化している
- プッシュ通知
- ホームボタン
- 将来⇒ブラウザのAPIが充実
Progressive Enhancement
PWAも同じで新しいブラウザの新しい機能を取り込んでよりよい体験を追求していく
こえのブログ
- オフラインでもサイト表示
- 記事の下書き保存
- 音声録音
- オフラインレコーディング
- オフライン検知-通知
- 録音開始/終了バイブレーション
- デスクトップPWA
デスクトップPWA（Spotify）
トレンドはどんな感じで進んでいきそうか
- ブラウザが進化すれば前に進む力が働く
- iOSのプッシュ通知など
- クロスプラットフォームアプリとしてのPWA
- MicrosoftもPWA押し
- Google スプレッドシートからPWA
Web高速化のススメ
中津川さん@MOONGIFT
よく使うWebサービス
読み込み3秒の基準
- 2016年…20%が離脱
- 2018年…53%が離脱
売上への影響
早くすれば利益が伸びるならそこに投資すべき
- Gwifiは1日500M
- 切れると128kbps制限
- 追加購入したいが、サイトが遅い…
- JavaScript動かない
- jQueryの読み込みでエラー
高速化？
- お金を使う
- サーバ増強
- ネットワーク回線強化
- 技術対策
- DOM改善
- ネットワーク改善
- プログラム改善
Webフロントエンドのボトルネック
- レンダリングが遅い
- ネットが遅い
- JSが遅い
DOM改善
- 仮想DOMを使う
- React/Vue/Riotなど
- DOMを更新すべきかどうかはフレームワークに任せる
- UI情報をJavaScriptにあらかじめもたせることで、データ通信量を大幅に減らせる
- DOMの幅/高さを指定する
- 画像の高さがずれたときのDOM再計算が重い
- テキストも可変にせず溢れたときの処理を入れる
- iframeを使うと再計算処理が走らないので高速化する
- ※実際やると結構地獄なので注意
UI/UX系改善
ネットワーク改善
- Cache APIを使う
- JSから操作できるローカルプロキシ
- 任意のURLコンテンツをキャッシュ
- Cache API
- Service Worker内で動作するキャッシュシステム
- URLをキー、レスポンスをバリューにしたKVS
- 有効期限などがないのでWorkboxと組み合わせると吉
- キャッシュパターン
- メリット
- ネットワークアクセスを大幅に減らせる
- オフラインでもWebアプリケーションが使える
- ※jQueryだけでも登録しておくと早くなる
- 注意点
- キャッシュを自動更新する仕組みはない
- 削除、更新する仕組みを作っておかないと大変
- 開発中はネットワークファーストで開発する
JSの速度改善
- WebAssemblyを使おう
- Webブラウザ上で動くバイナリフォーマット
- 超高速
- WebAssembly
- プログラミング言語ではない
- DOMが扱えない
- ネットワークが扱えない¥
- DOM/ネットワーク利用
- WASMからブラウザに依頼し、ブラウザが返す仕組み
- RustとGoで対応
- Canvas/WebGL
- メモリを直接書き換える
まとめ
- DOM描画が遅い⇒仮想DOM
- ネットワークが遅い⇒Cache API
- JSが遅い⇒WASM
マーケティングから考えるPWAのエンジニアリングによる打開策
榊原さん
capacitor
各アクセス数：3つ並べている
使っている人はほとんどいない
- Web Payments/Payment Request API
- Push通知
Wordpress PWA
HideOkamotoさん
PWAは初回のロードは早くならない
- CDNやNginxPHP7
- 生HTMLだけが一番はやい
WordPressでPWA
- インフラ・アプリに投資
- モバイル：Responsive Web Design
- インストール：プラグイン
- SPAは必要ない
- インストール可能はRWD
PWA plugin for WP
できないこと
- manifest.jsonの生成以外のすべて
本当に欲しい物
- どのサイトでもほしいのはオフライン、低速通信への対応
- Service Workerの実装
Service Worker + Dropbox API
kudoさん
- ファイル操作に必要なものは網羅
- 認証はOAuth2
- 自分のアカウントなら専用token発行可能
- いろいろある
【勉強会メモ】E2E Test Automation Day 2019 with Selenium (Osaka)
- 日時：2019/07/20(土) 13:00 〜 19:00
- 場所：楽天株式会社大阪支社
Selenium Conf Tokyo をきっかけに関西にも広げようということで、楽天さんバックアップでの関西初開催でした。E2Eテスト関連は昨今需要が増えてきているものの関西の勉強会ではあまり取り上げられない分野なので非常にありがたいイベントでした。内容もとても充実していて、今後の現場で活かしたいと思える内容でした。
余談ですが、懇親会で伊藤さんとお話した時に何年か前に私が投稿したSeleniumの記事を覚えて頂いていて感激とともに恐縮してしまいました。それ以降Selenium関連であまりアウトプットできていないので今日もらった知見をまた今後につなげていきたいです。
E2E Test Automation Day 2019 with Selenium
Woohyeok Kim さん
www.slideshare.net
Selenium Conf Tokyo のKeynote概要
Multi-Browser Testing Strategy Map
Sekine Yasufumi(mercari Inc) さん
マルチブラウザの自動テストの必要性は高まっているが簡単ではない
ブラウザシェア
DevOpsでのテスト
- どの場面でも行う必要がある
- 自動テストは必須
マルチブラウザの自動テストが重要
W3C WebDreiver
- 標準技術として取り入れられた
- Webブラウザの標準機能としてブラウザベンダーがサポートしていく
- Safari,Edge、など主要ブラウザサポート
- iOS13 iOS Safariでもサポートアナウンス
- IEはW3C未サポート
- Selniumコミュニティがサポート
マルチブラウザのテストの難しさ
問題点1：W3Cに準拠していないケースまだある
- SafariではGet Element Textの仕様を満たしていない
W3Cの判断が分かれるケース
準拠していないケース
- 仕様の判断が分かれるケース
- ブラウザ独自の対応が必要
- 対応ブラウザを増やすほど難易度があがる
問題点2：OSとブラウザの組み合わせ
- デスクトップ
- モバイル
問題点まとめ
- デスクトップモバイル全てに対応すると組み合わせが非常に多い
- 開発環境、CI環境の構築・メンテナンスが難しい
Multi-Browser Testing Strategy Map
- Fidelty
- ブラウザとOSの組み合わせをどれだけ増やすか
- Feedback
- 実行の時間を減らす
初期段階
- 片手間で導入の段階を抜けるにはSpecialistが必要
- ここは早く抜けたほうが良い
次のステップ
- Feedbackレベルを上げる⇒Functional…1ブラウザだけでも構築
最後のステップ
- Fideltyを上げていく
- 最大限にすることが良いとは限らない
- SaasのBrowser Test
- 同時実行数で決まるため高速化xブラウザxOSはけっこうな利用料がかかる
- 20並列だと月40万
別の戦略
- Fidelityだけを上げるパターン⇒NonDevOps
- 時間をかけてでも品質を上げたいケース⇒SIerなど？
- あまり推奨しない
メルカリでは？
- プルリクエスト
- QA環境デプロイ
- 本番リリース時
自動化テストを始める前に
Yadori Yohei(Rakuten Inc) さん
www.slideshare.net
テストに関する最近のトピックス
- フロントアプリのRegressionテストが86%自動化
- モブテスト設計
フロントエンドチームは過去に2度テストの自動化に失敗している
- 最初から完璧な素晴らしいテスト自動化を目指しすぎた
- 案件の差し込みやプロジェクトの予定変更が多く、健全な計画が組めない
- 20にんで支えていたシステムを急に5人で支える事になった
- 信頼貯金はマイナス
- また自動化すると言いにくい
どうやったらテスト自動化できるか？
盗塁しよう
- ピッチャーが気づかないうちに進塁
- いつの間にかできている状態になればベスト
- 成果が出ればアピールできる
盗塁の準備
- タイムボックス⇒10%ルール
- 自分の好きな改善をしていいルール
- Minimum Vialble Productを意識
- ある程度形になるまでのコストを気にしなくても良い
担当者⇒モブ
- １人でやるにならない
- 考え方の共有
- フラットな組織と文化の醸成
振り返り⇒Retro/Pro-spective
- ビジョンが見えるようになる
- 目指す目標を定期的に確認
- 前向きになれる
成果
- 全ページエラーチェック
- スクショでの新旧比較
- 全体の86%テスト自動化
将来
- レグレッションテスト100%
- Dockerに入れて自動化
まとめ
- 小さな成果から
- モブは一体感を出すのに最適
- 過去と未来の話はバランス良く
Appiumを製品のコアに活用する
Ito Nozomi(TRIDENT Inc) さん
www.slideshare.net
Appium
Magic Pod
- Saas
- コードレス
- バックエンドはAppium
直面した課題
- ユーザーはAppiumに慣れていない
- 品質への要求がシビア
- Magic Podのコマンドは基本的にAppiumコマンドのラッパー
- 一部のコマンドの実装は複雑
遅延ロード要素のScroll/Swipe
- 課題
- Appiumには特定の要素が表示されるようにスクロールする機能
- XCUITest Driver：遅延ロードされる要素が見つかるまでスクロールできない
- UiAutomator：一部の要素で動かない
- 対策
- swipeToコマンドを作っている
- 要素が見つかるまでスワイプしている
なんでもWait
- 課題
- 待ち処理の記述は難しい
- 何を待つのかわからない
- 対策
- waitWholeRendered
- 画面キャプチャの結果が変わらなくなるまで待機
- 人間の感覚と同じ
- 残っている課題
- スクリーンショットを撮るのはすぐ終わるがイメージの比較に時間がかかる
- ロードアニメーションがないと困る
iOS picker wheel
- iOSの課題
- pickerに特定の値をセットするのが面倒
- Pickerの移動方向が現在の値によって変わる
- 対策
- inputToPicker
- 少しずつスワイプすることで値をセット
- スワイプ方法を自動計算可能
- inputToPicker
- 今後の改善
- 数値以外の判定
- 曜日、都道府県、国名
- 課題
- 巨大のツリーの取得に時間がかかる
- タイムアウトで空になることも
- テキスト中の改行が含まれない
- 対策
AIロケーターの活用
- Deep learning画像認識で要素を特定
- Magic PodはAIロケーターを活用
- NN+OCR
- UI map
- AIロケーターによる要素検索
- AIの認識結果が常に安定しているわけではない
キーボードを隠す for 日本語
- 最後のキーを探して押す
Appiumをもっと安定して信頼できるものにする
- デグレの防止
- Appium自体のテストを用意
- Magic Podに重要な機能のテスト
- 実機やエミュレーターでテスト
- コミッターとのコラボレーション
- 日本人コミッターにコンサルティングや修正を依頼
- バグ報告機能を搭載
- 多くの問い合わせは実際にはバグではない
- 問題を切り分けてAppium開発コミュニティへ報告
将来の計画
- Espresso DriverとUiAutomator2 Driverの併用
- WebdriverIOに以降
- AIモデルをappium-classfier-pluginに移行
ポスト「テスト自動化」を見据えて ~水平思考と探索的テストの世界~
Masanori Kawarada さん
なぜ探索的テストの話をするのか？
理由1
- 探索的テストが未来のテスターのしごとになる
- テスト自動化の進歩が著しい
- UIテスト自動化＋APIテスト自動化⇒手を動かすテストがどんどんなくなる
- プログラムだから開発者がテストを理解しテスト自動化を推進するようになる
- 品質専門家の需要は無くならない
- 最適な品質保証の形は各業界。各社・書くプロジェクトで異なる
- それぞれに応じたQAプロセルを作り出せる
- スタートアップは早くから品質の重要性
- QAは水先案内人
理由2
- 日本語で手に入る探索的テスト情報が少ない
- Google検索結果
- 探索的テスト：372万
- Exploratory Testing：3,710万
- 日本語の書籍も無い
- Google検索結果
探索的テストのアプローチとしての水平思考
テクニック・技法・実践
- テストチャーター
- タイムボックス
- ペアテスト
⇒ググれば出てくる
アプローチ・原論・理屈
例）選手32人のトーナメントは何試合あるか？
- 垂直思考
- 32人の半分が1回戦⇒その半分が2回戦…
- 水平思考
- 32人のうち1人が優勝で残り31人は1回負けるので31試合
ポストテスト自動化を見据えて
- 形式的テスト⇒チェックを埋める
- 探索的テスト⇒コンパス的に探す
World Quality Report 2018-19
QA・テスト戦略の目的第1位は「顧客満足」
テストとは
- 知っていることと知らないことのギャップを埋める
- 形式的テストと探索的テスト
- 形式的テストは自動化しやすいが探索的テストは自動化しにくい
頭をつかう必要がある
- 頭を使わなくていいことは機械にやらせる
- 頭をつかわなければならないことは人間がやる
頭をつかわなければならないこと？
- 専門のテストエンジニアが探索的テストをやる
世界で最も優れているテストツールは人間の頭脳
LTは簡単なメモのみです。
Introduction to Cypress
Shiiba Mitsuyuki(Rakuten, Inc.) さん
Test Assistant Pro のSelenium対応
Ishikawa Tatsuya さん
Groovy Test Fixture
Kitamura Kandai さん
- Testcontainers
- テストコード内でDocerコンテナを起動
- Wiremock
- モックのAPIサーバを立てる
Effective Android UI Testing
Lindsay, Diarmaid さん
世界のカンファレンスから~次に世界に飛ぶ人へ~
mkwrd さん
