Productivity Engineering − Forkwell Meetup #4
【増枠！】Productivity Engineering − Forkwell Meetup #4 - connpass に参加したメモ。
チーム開発、改善のフローをどうやって回すかが大事。改めて感じた。 あとなんだかんだで、リモートとかで顔を合わせないことによるデメリットはなかなか埋められない。
@ryuzee さんの話きけたのはありがたかったな。ふりかえりは自分のチームでそこそこうまくいっている気がしていたけど、データを集めるって点で圧倒的に足りてないと思い知らされた。
@masamichi さんの品質の話。サービスのフェーズによって重要になる軸が異なるっていうのはナルホドと思った。ただ、これはユーザーストーリー駆動でやったら暗示的に解決されるのかも？とも。
@t_wada さん。ペアプロ。たまにやってはいたが、本質にたどり着いてなかったなと思った。来週やろう。本人もおっしゃっていたが、心理的安全がマジで大事だと思う。そのあたり、どうやって環境を作るかみたいな話も聞きたかった。
クックパッドにおけるモバイルアプリ開発の工夫 クックパッド @ichiko_revjune
- モバイルアプリの開発体制とか
- テストエンジニア
- 利用者は多いけどアプリ利用者が少ない
- モバイルは機能ごとにチームが分かれていて、技術部が共通基盤を担当。デザイナーも 分かれてる。クライアント/サーバーも両方同じチームにいる。
- 2w - 1m でリリース。1リリースで10人程度のエンジニアが関わる。
- 「サービスを変える」
- 意図した通りに変更されたか
- 効果が計測されているか
- ユーザーが離れる、は損失。
- 開発、テスト、リリースと分けている
- 開発：issue, PR
キックオフ
- ディレクター、デザイナー、エンジニア（みんな）
- チーム間の情報共有
- 朝会でタスク、施策を共有していたが、関係者が増えたりフレックスしたのでSlackに移行した
- 非同期に議論できるようになった
- 他人のタスクに言及しなくなってきた、関心が薄れていった
- タスクが順調か、疲れてないか、という情報がなくなった
- 1画面に複数プロジェクトが関与して表示崩れってのがあった
- kickoff でやろう
- 30m 20人くらい
- 他チームへの懸念を伝えやすい
- タスクが順調かとかはキックオフでは拾えていない。。
確認会
- ディレクター、デザイナー、エンジニア
- すべての変更をマージしたアプリを触る
- 一貫性、意図通りになっているか。リグレッションテストではない
- どんな課題があったか
- チームが独立していたので一貫性が損なわれていた
- 検証端末が多いので依存性をなくしたい
- ユーザーのパターンでNGになる、
- 1h, 15人くらい
- NG があったらリリースマネージャーが調整
Effective Retrospective アトラクタ @ryuzee
- スライドあるよ
- ふりかえりはアジャイルだけじゃないよ; 開発だけでもないよ
- KPT以外にもあるよ
- もっとうまくできるようにする
- 「あれ良かったね」「これよくなかったね」だいたい次のプロジェクトに反映されない。なので定期的に検査するのが大事。
- 「強制的に仕事を停止する」意外と大事。
- このままでいいのか一回止まる
- 心理的安全性がないと無駄だよ
場を設定する
- 冒頭に全員に口を開いてもらう。効果が上がる。研究結果も出てる
- 説明（タイムボックス、どこまでやるか、ルール確認）
- 道具
- コーヒー、甘いもの
- 付箋、ホワイトボード
- stopwatch
- PC使わない！議事録はホワイトボードを写真で
データ収集
- 客観的なデータ
- イベント、メトリクス、完成した成果
- 定性的なデータでもOK
- 過去の写真とか会議のログとか
- 「意見をもとに問題を解決しようとすると失敗する」factに基づかないと。
- 「品質が悪い」「情報共有が不足している」は意見。
アイデアを出す
- いきなり出した解決策が正しいことは少ない。分析して改善する
何をすべきか決定する
- 数が多すぎると無駄になる
- 誰がいつまでにやるのかはっきりさせよう
- fist to five (多数決じゃない方法)
終了
- 記録を残す。フォローアップのアクションを決める。
よくある失敗と対策
- くらい。特定の人しか喋らない。愚痴が多い。前回と同じになっちゃう。
- 安全性欠如。
- 不明確なアクション。トラッキングの仕組みができてない。
- マンネリ。KPTは毎回やると飽きる。同じ観点になりやすい。やり方変えてみる。場所を離れる。
- sprint retrospective でもタイムライン使っていいかも。
- getting value of agile retrospective
最後に, Q&A
- 日本人はあんまり褒めたがらない。ホメよう。
- 遅い時間にやらない。昼頃にやる。
- リモートだと
- 同期的に書き込めるツール使う。振り返りの時だけは全員集まる。
- 時間
- データ収集と別に2hくらい。チェックインに10分くらい。
- 短いと「仕事を止めてる」感じがなくなるという副作用。
- 人数
- 10人がギリギリ。兼務があるのならプロジェクトごとにやる、もあり。
- 「マネジャーが言ったからダメ」でいいのか！
- (直接伺った) 四半期だったり長期プロジェクトのふりかえりをタイムラインでやっているが、発散したり時間がかかる
- 最初からテーマ決めてやるといいかもね（タイムラインはあってないかも？）
- イベントの粒度が細かくなりすぎると発散する
- (思ったこと) まず issue (problem ではなく) を先に集めといて、その中から厳選する
- 人数が多いならワールドカフェ的にやるとか
- ryuzee さんは長期のふりかえりは普段やってないっぽい
- 最初からテーマ決めてやるといいかもね（タイムラインはあってないかも？）
自己言及的なチームをつくる GMOペパボ @jue29
- 自分たちが過ごす日々に対して自覚的であるチーム
- 自分たちの日々を自分たちでデザインする
- 問題は常にある
プロジェクトは何事もなければ失敗する
- チームを評価するとき減点方式で行くか、加点方式で行くか。人によって考えが違う。
- 加点方式のほうが良いんじゃないだろうか
- 減点だとチームメンバーがトラブルを隠す
- 「何もありませんでした」
- 優秀なナースがいるとその場で解決されてしまい、全体に共有されない
- トラブルを乗り越えることで信頼貯金が貯まる
どう作るか
- 言葉を尽くす。行動で示す。
- チームにとっての良さを言葉にする
- 個人の価値観の押し付けはチームの価値観を壊す
- 人は変化にストレスを感じるので「お得感」を出すと良い
どう変えるか
- ブラウザ拡張、chatbotで自動化。お得感。
Make Jenkins Great Again サイボウズ @miyajan
- スライドあるよ
Jenkins 2.0
- release から1年。
- ツールの用途、プラグインが複雑化。Jenkins職人問題。
- docker イメージあるよ
plugin 多すぎ問題
pipeline 作りづらい問題
- 複数ジョブのつなぎあわせだった。ビルド後に云々〜
- DSLでパイプラインを定義する。パイプライン自体が一つのジョブになっている
GUI 辛い問題
- 項目多すぎ。バージョン管理できない。
- Groovy でジョブの設定を記述。バージョン管理とか PR とかできる。
- ただしプラグイン側が対応する必要ある
DSL syntax
- Scripted Pipeline 手続き型。わかりづらい
- Declarative Pipeline シンプル。Lint 効く
- Declarative の中に Scripted を記述することもできる
共有ライブラリ
- script を複数プロジェクトで共有が難しい
- GitHub リポジトリからライブラリを読み込めるようになった。Grooby で書く
- Error は赤字で出す、とか使いまわせる。プロジェクトごとに指定できるので変更の影響範囲が絞れる
ビルド、デプロイ
- 設定が複雑。リポジトリの設定、ビルド・トリガーの設定などなど
- GitHub Organization Folder
- Organization 内のブランチを自動にビルドしてくれる
- ジョブごとに設定する必要がない
Blue Ocean
- UIダサい。
- Blue Ocean UI かっこいい（RC）
- Pipeline の設定 UI でやれる
今の懸念
最速で価値を提供する ネクスト @masamichi
- 品質について。
- 品質をどう改善するか。
- 最速で価値を提供する
品質
- 狩野モデル
- ビジネスフェーズごとに求められる品質が異なる。
- 初期は魅力的品質が必要。そのうち「当たり前」が求められる。だんだん競合が現れて「性能品質」が大事になる。
- サービスの特性
- 無形である、非分離である（生産と消費が同時）、変動する（提供者、時間、場所によってサービスの質が変化する）
- 作って終わりじゃない。そのあと品質を高めていく必要がある。
- 品質
- 有用性: ユーザーの利益になる、または損失を下げられる
- 可用性
- ユーザビリティ
- セキュリティ
- Webサービスの品質
- 組み込みだとユーザはサービスを所有する。問題が起きたら大変。出荷したあとに修正が困難なことが多い。
- Webサービスだとリリース後に修正できる。ユーザーの反応を見て改善できる。
品質改善の型
- 品質の仕様化
- そのプロダクトにどんな品質を求めるかを言語化する。
- ISO25010 で決まってるらしい
- 言語化されない品質は作られない！
- そのプロダクトにどんな品質を求めるかを言語化する。
- 実装
- 品質を高める技術
- 欠陥検出型、予防型
- テストで一気に消化するのが欠陥検出型、都度減らすのが予防型
- モニタリングと改善
- レスポンスタイム、安定性をモニタリング。脆弱性診断する。Net Promoter Score とる。
最速で価値を提供する
- 品質とは誰かにとっての価値である
- 内部品質: 開発者が書きやすい、メンテしやすい、も価値
- 一方でスピードも必要。これは単純なトレードオフじゃない。両立できるよう工夫すべき。
- リードタイムを短くする、無駄な工程をなくす。自動化する。
- Value Stream Map
- 原材料が加工されて顧客に渡るまでの経路を図にしたもの。どこがボトルネックになっているか。
- 各工程で無駄を探す。
- 計画だったらドキュメント、テスト、デプロイだったら自動化
Q&A
- 実装者が品質について設計者に甘えがち。
- 実装者も品質に歩み寄るべきだし、設計者も実装を理解すべき。実装者は学ぶことも多いのでQAを置くのもあり。
ペアプログラミングの使いどころ タワーズ・クエスト @t_wada
What
- driver と navigator でやる。運転手は視野が狭まるよね、という趣旨
- 先に目標を決める。始める。喋る（どっちも）。お互い何やってるか把握する。喜ぶ。交代する。
- 5分で交代する、とか。テストとプロダクションを交互に書く、とか。
When
- 疲れる。1日3hできたらいい方。
- 新メンバーが入ってきたとき。不具合を修正するとき。新機能を作成するとき (レビューの手戻りを防ぐ)。日、週に決まった時間に。
- あるチームでは新規機能だと必ずペアプロする、とか。
Why
FAQ
- コスト倍になるじゃん
- 開発環境が違う
- 揮発性が高い
- その二人は満足するけどチームの経験にならないのでは
- モブプログラミング（3人以上で）
- 週1回、それぞれが気にかけていた箇所をみんなでやる、とか
- 上級者側のメリット？
- 教えることで自分の知識が整理される （ドメイン知識、技術知識の両方）
- いろんな開発環境に慣れることができる
- プレッシャーが強い。。
- 心理的安全が一番大事。
- どうしても向いてない、って人は2割くらいいる。押し付けは良くない。
- 「ここは俺が書いた」感が欲しい
- コードは共有物である、というメリットの真逆。向いてない人はいる。
- ソロプロはOSS活動に費やす。Write Code Everyday.
Q&A
- 初心者同士だと効率悪い
- 上級者同士は効果ある。長〜い PR にならなくて済む。
- マネジメント層への説明 (コスト2倍になるんじゃないの)
- 事前に許可をもらうより後で許可をもらう。リファクタリングも同じ。
- 不具合修正は通りやすい（指差し確認、ダブルチェックと同じ）。
