Productivity Engineering #4
クックパッドにおけるモバイルアプリ開発の工夫
(株)クックパッド テストエンジニア 茂呂さん @ichiko_revjune
クックパッドとは
- クックパッド 260万レシピ
- 月次利用者 6320万人
- アプリ利用 936万人
開発体制
機能毎にチームがあり、エンジニアデザイナがいる
エンジニアは3名ずつくらい
- 広告
- 会員
- 投稿
- 検索
- 技術部(全チームを横断する基盤的なチーム)
リリース間隔は2W～1M
毎日の料理を楽しみにするためにサービスを変えていく
- 理念通りに実装できているか？
- 理念通りに使われているか？ →効果測定測定
クックパッドはコミュニティサービス
- ユーザが離れていくことは損失
- ユーザが残念な思いをする体験は避ける
→実現するために、キックオフと確認会をやっている
キックオフ 30分 20名くらい
ディレクター、エンジニア、デザイナー（開発に関わる人すべて）
チーム間の情報共有
- もともとは朝会をやっていた
- 関係者が増えた、フルフレックスになって難しくなった
- Slackへ移行
- 他チームへの関心が薄くなった
- 観察で得られていたことがなくなった（疲れてそうだな、など）
- それぞれの施策がぶつかることが起きた（同時にやったら意味ない…効果取れない手実)
- 情報共有足りてない！キックオフやろう！
- 情報共有足りてないことはキックオフで解決できたが、疲れてそうみたいな進捗の部分は未解決
確認会
- マージ済みアプリを関係者みんなで触る
- リグレッションテストではない
- 解決したい課題：UI/UXを保ちたい
Effective Retrospective
(株) アトラクタ取締役CTO 吉羽龍太郎さん @ryuzee
開発プロセスに関するコンサル、トレーニング 本も書いてる
レトロスペクティブとは
ふりかえりのこと アジャイル開発で使われる アジャイル以外でもバックオフィス系で使っている人たちも。 使ってて困ったら僕に相談してね！
もっとうまくできるようにしよう
もっと課題を見つけたり、効率よくしていける
- ちょっとずつよくしていくためには、定期的な検査が必要
- 「あれ良くなかったよね」って振り返っても、次に活かされない（あるある）
- 長いプロジェクトだと、初期のことなんて忘れてる
- 仕事を強制的に止めさせる
- 車は急に止まれない。人間も同じ。
- 忙しいから止まれない→ますます事故る
- だから無理やり仕事を止めて、振り返る時間を作る
- 最悪、改善できなくてもいいから一旦止める
- Googleも言っている、心理的安全が大事
- 上長がいる、人事評価につながる…→本当のことなんて言えない
- その場を安全にすることが大事！！！
- 透明だから問題が明らかになる
- ふりかえりのメンバー選定が必要
- 口がうまくて話しに割り込むマネージャー→場を乗っ取っちゃう
- ファシリテーターが適切にさえぎっていく、みたいなのも必要
ふりかえりのやりかた
- 場を作る
- 心理的安全が保障された場を作る
- 忙しい中で参加してくれたことに感謝する
- 会議の冒頭で口を開かせると、その後の参加率があがる（研究結果）
- ルールを確認する（携帯NGとか）
- おすすめ小道具
- コーヒーやお茶
- チョコなど
- PC持ち込まないほうがいい
- おすすめ小道具
- データを集める
- 客観的なデータ
- イベント ミーティング、意思決定、メンバー変更、割り込み、障害など
- メトリクス バーンダウンなど
- あるデータをそのまま使えばよい
- 意見をもとに話し合わない。事実をもとに話し合う。意見をもとに話し合うと、本質的な解決にならない
- 「品質が悪い」 意見
- 「情報共有が不足」 意見
- 客観的なデータ
アイデアを出す
何をすべきか決定する
- 妥当なアイデアのうち、上位の課題を解決するものをやる
- 多すぎると行動できない→無駄になる。数個に限定する
- 誰がいつまでにやるのかはっきりさせる
意思決定の方法 拳から五本指（Five to Fist)
3本指 「良いとは思わないが自分はそれでよい」
日本人のyesはこれ
よくある失敗
- 雰囲気が暗い
- 同じ人ばかり話す
- 毎回同じ問題が出る
- 解決したはずの問題がまた出る
よくある失敗の原因候補
- 心理的安全が足りない
- 不明確なアクションアイテム(いつまでに誰が？)
- Doneの定義が明確じゃない（何がどうなっていれば完了なのか？）
- カイゼンボードを作って、通路などに置く
- マンネリ化
- 場所を変える
- やり方を変える（直近2週間のタイムラインをホワイトボードに書く）
- いろんな本出てる
振り返りは悪いことばかり話す場じゃない
良かったことも話そう
感謝を伝え合おう
昼間からやって、15時くらいにビールを飲みに行くとか最高
- Q.レトロにどれくらい時間かけてる？
A.チェックインに10分、KPTやったら30分、議論してアクション決めたら2～3時間くらい。 チームの熟練度が上がると短くしていける。1時間くらいで終わる。 短くなる副作用として、仕事を止めてる感覚がなくなり、仕事にすぐ戻って暴走する。 1日丸ごとやるのは無駄だと思う。
Q.チームが10人いる
A.そのあたりがぎりぎりだと思う。多くなるとコミュニケーションがとれない。 開発者3～9人、スクラムマスター1人がスクラムの範囲。 15人とかになるなら、2チームに分けたほうがよい。
Q.心理的安全を確保するために人を外す→その人がいるせいで安全じゃないと言ってることになる
- A.ケアすべきは、ポジションが上の人が会議を乗っ取ること。 アジャイルチームが日々開発しているので、その人たちが出すアクションアイテムが妥当なことが多い。 それが偉い人につぶされるのは防がなきゃいけない。 偉くてめんどくさいおじさんには「忙しいから来なくていいですよ」みたいな言い方もあるし、 スクラムマスターがそういうのを防ぐ役目。 それでも覆されるなら、さらに上長の許可をとる。 チームを良くできるのはチームの人だけ。 「偉い人が駄目っていうからできない」って言い訳してて、それでいいの？
スポンサー紹介
1分以内で。時間測ります
イーパーク 35秒
開発責任者も来てます
ヌーラボ
Backlogとか作ってます リモート開発についてあとでLTします
サイボウズ
プロダクティビティを重視してる 生産性専門のチームがいる
うるる
クラウドソーシング事業 おととい上場しました
ネクスト
4月からライフルに社名変更 全てのLifeをFullにしたい Home'sをやっている 自社で企画開発。マイクロサービス化もしてる 品質管理マネージャがあとで登壇する
メディアドゥ
電子書籍流通事業
CBcloud
物流の闇を解決するために…
Speee
スタンディングオベーション
タンスの中身を可視化するサービス どスタートアップ
自己言及的なチームを作る
GMOペパボ おおわだじゅんさん @june29
小保方さんと同じ誕生日です。よかったらオボちゃんて呼んで
少年漫画大好き
web大好き
自己言及
自己言及的なチーム
- 自分たちが過ごす日々に対して自覚的
- 良いことも悪いことも受け入れている
- それらについて会話している
なぜ自己言及的なチームをめざすのか？
- 自分たちの日々を自分たちでデザインする
- 誰かに強制されるとテンションとパフォーマンスが下がる
- 偶然に最高のチームが生まれることはない
- あるかもしれないけど、自分の人生をギャンブルにしていまう
- 自分たちの人生を自分たちで変えていけるという自信や誇りがパフォーマンスを上げる
問題は常に我々とともにある
- 気づいてない人
- 気づいたけど諦めてる人
- 気づいて騒ぐ、愚痴を言う
- 改善を提案する
- 気づいて改善する
- 気づいてその場から去る
好きの反対は嫌い じゃない
- ポジティブに自己言及→改善
- ネガティブに自己言及→発散
- 自己言及しない
- 無関心は扱いにくい。ポジでもネガでも言及があるのは関心があるということ
プロジェクトは何事もなければ失敗する
- 人が数人集まっただけではチームではない
- 僕たちはチームになっていく必要がある
- 人が集まっただけでは0点。何かをしていきながら100点に近づいていく
- 加点方式で捉えるようにしていく
- 減点方式だとトラブルを隠すようになっていく
- 優秀なナースがいるとシステムが改善されない
- 問題を個人が解決してしまい、上に共有されない
- 組織としての改善が進まない
- 日々チームに起こるイベントを受け止め、楽しむ
- ともにトラブルを乗り越えると信頼貯金がたまる
- ともに意思決定を繰り返すと価値観が醸成される
自己言及的なチームをつくる
- 言葉を尽くす
- 行動で示す 人に真似してほしい良い行動を自分がする
- それらを繰り返す
- 押し付ける以外のやり方で
- 価値観の押し付けはチームの価値観を壊す
- 人は基本的に変わりたくない
- 僕だって何もしないで年収倍になるならそれに甘んじる
- 自分が率先して行動し、チームが得する状況をつくる
- 振り返りは重要
お勧めの出発点2017年春
- ちょっとした「いいこと」から
- ブラウザ拡張、ユーザスクリプト
- 1Clickでも減らせれば…
- チャットボット
- 朝会の促し
- IFTTT
- Slack
- メールインテグレーション
- 天気
- Googleスプレッドシートas Cron
ソフトウェアエンジニアとして現代を生きる意義
- 俺たちがやらねば誰がやる
- 他のどの職種より活躍できる
心がけていること
- 立場が上の人と話す
- 視野を広く
- 関心を広く
- 他者や歴史から学ぶ
思考停止がこわい
Make Jenkins Great Again!
サイボウズ（株） 宮田淳平さん @miyajan
サイボウズの生産性向上チーム jenkins職人
jenkinsの歴史
- jenkinsの用途が拡大するごとに、複雑化
- 属人化問題（職人しか触れない）
- 他のCIツール登場
- 2.0化 この先10年を見据えたアップデート
- アップデートに伴い、ベストプラクティスも変わる
1.0
- デフォルトプラグインが入ってない＆プラグイン多すぎ問題。質が玉石混交
- パイプライン作りづらい問題
- ビルドスクリプトを複数プロジェクトで共有するのが難しい
- プラグイン化すればできるが、簡単じゃない
- UXが古い
2.0
- 推奨プラグインが表示される
- パイブライン全体が1ジョブ
- 設定ファイルが1つ。見通しが良い
- 過去プラグインとの互換性
- パイプライン実行前に構文チェックされる
- SharedLibraries
- ブルーオーシャンUI
- モダン
- 正式公開はされてない。プラグイン入れれば使える
はじめまして株式会社メディアドゥです
(株)メディアドゥ 濱口賢人さん
アプリケーション開発部 主任 27歳
電子書籍流通事業
楽しいところ
- 幅広いコンテンツに触れられる
- 自社開発、自社運用
- システム構築ノウハウ
チーム開発について
過去
- スピード重視で俗人化
- メンバーが増えて伝達が困難
- マネジメントをしながら開発の仕事も継続
- 後輩の育成に時間を掛けられない
取組中
まとめ
- 今までのメリットは活かすべき
- ボトルネックを特定して的確なツールを使う
- ツールに振り回されず、業務に合った運用を目指す
キャリアアップできるエンジニア できぬエンジニア
(株)Folkwell プロダクトマネージャ
キャリアアップできぬエンジニア
- 市場の評価＞社内の評価
- 重要な仕事が回ってこない
- 責任ある立場になれない
- 市場の評価＜社内の評価
- 市場から望まれないスキルセットになっている
キャリアアップできるエンジニア
- 市場評価 ≒ 社内の評価
- できるエンジニアは市場のニーズを確認して取り込んでいる
- 本人が望む待遇(給与もそれ以外も)を得ている
おすすめ
- 懇親会
- スカウトサービス
- 企業とのつながりが増える
- 悪いイメージがある…
- 大量スカウト
- 同じようなメールばかり
- お話でも → 「志望理由は？」
- 面談確約 → 書類選考で落ちる
こんなだから、スカウトは愛されなかった…
新サービス作りました
- 一括送信なし
- スカウトを受け取ったら自分の評価が分かる
- 温度感を選べる
最速で価値を提供する
(株)ネクスト 藤沢正通さん @masamichi
品質を考えるときの観点
- 狩野モデル
- 魅力的品質 なくても良い。あれば満足
- 性能品質 ないと不満
- 当たり前品質 ないと不満。あっても満足しない
- サービスの特性
- 無形性 サービスは形がない。買う前に見たり触れたりできない
- 非分離性 生産と消費が同時に発生し、提供者と不可分
- 変動制 時間や場所でサービスの質が変わる
- 消滅性 在庫することができない
- サービスの品質
- 有用性 クライアントがどのような成果を挙げられるか
- ユーザビリティ
- セキュリティ
品質改善のカタ
- 品質の仕様化
- どんな品質を求めるか言語化したもの
- ISO/IEC25010
- 実装
- モニタリングと改善
最速で価値を提供する
- 会社の行動指針の一つ
- トレードオフではなくANDの発想
- リードタイムを短くする
- 自動化する
- サイクルを速くすることで速く提供できる
バリューストリームマップ
- トヨタが始めたもの
品質に詳しい人とエンジニアが別。詳しい人がe2eテストを作ってくれているからエンジニアが甘えがち。 詳しい人を開発に巻き込むか、エンジニアが品質を学ぶか、どっちがいいか。
両方。でもエンジニアって覚えること多いから難しいよね… ネクストではテスト専門のチームを作っている。
品質のスピードはトレードオフだと思う
気持ちの問題として、両方解決したいなと思っている
リリースサイクルは
週2回、月8日間。数十案件リリース。 週2回のリリースに合わせるために無理をしたり、できているのにリリース待ちだったりする。リリース相乗りしたりして対応している。
スピードと品質のトレードオフのジレンマ
- チーム外からでは品質を上げられない。チームに入り込んで品質を上げる施策をするけど、入り込みすぎると、他のチームにとって良いことなのか分からなくなる。でも横断的にみられることが良いこと。
ペアプログラミングの使いどころ
タワーズクエスト(株) 和田卓人さん @t_wada
- ひとり歩きするスタンド
- 流しのペアプロ業
ペアプロとは
- キーボードを打つ人 ドライバー
- 横にいる人 ナビゲーター
HOW
- 作業を決める
- 目標を決める
- パートナーを頼りにし、支える
- 喋る 書いた人も書かない人も喋る こういうつもりでこう書いてます」とか
- お互い何をやっているか把握する
- 喜ぶ
大事なこと
- 大きいディスプレイが大事。指さして話す
- ドライバーの正面にキーボードを置く
- 考えていることを声に出すor紙や帆ワイドボードに書く
WHEN WHERE WHO
- やりすぎ禁止
- 疲れるので、最初は15分とか
- 3時間くらいやれればいい
いつやるか
- チームに新メンバーが入ったとき
- 不具合修正
- 間違いを防ぐ
- 不具合は大事な知識なので、二人でやる
- 新機能作成
- 新機能は必ずペア
- 既存機能で軽いものはソロ
- 既存機能で重いものはソロorペｱ
コードレビューのコミュニケーションを減らすのがペアプロ
- フィードバックが最速。WIPのプルリクより速い
- WIPプルリク文化が出てきたのは、手戻りを減らすために、早いうちに人に見せようという発想
- それより早く、リアルタイムでレビューできる
- 書き終えたコードを直されるより、その場で言われたほうがダメージが薄い
- レビューの「何度目ですか？」みたいな指摘つらい
FAQ的なやつ
「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない
- 結果だけじゃなく過程が見えるからいい
- 3つの案のうち、1つが選ばれた場合
- 他の案は何があったんだろう？
- なぜその一つが選ばれたんだろう？ →すごい学び
- コミットとコミットの間で失われるものに学びがある
- 本やGithubでは分からない
二人でやるとコストが倍になるのでは？
- 倍にはならない
- 二人で書いてもまあまあペイする
- ただし、常に生産性が倍以上になるわけではない
- ペアプロが活きる場面で使うのが良い
開発環境がバラバラでペア組めない
- Emacs使う人とペアプロなんて…
- 「お前の好みとチームの成功とで大事なのはどっち？」
- 好きな環境でやればいい
- キーボード一つが本来だけど、二つあってもいいんじゃない？
- ペアプロで価値を産めることが大事
揮発性が高い
- 常に集中を強いられる
- 本人たちは満足度が高いけど、チームの経験に残りにくい
- モブプログラミング
- 衆人環視プログラミング
- この中でペアをローテ
- 会議室2時間だけ取って、みんなが気になってたコードをリファクタ
上級者と初心者がペアになった場合、上級者側にメリットはあるの？
- 教えることが最大の学び
- 整理されていないと声に出せない
- 自分が発声したことの方が自分へのフィードバックとして定着しやすい
- ずっとプログラミングをやっていると、自分の開発環境が固定化していく
人がいるところでコード書けない…
- 心理的安全が大事
- まず仲良くなってからやる
- 仲良くなるためにやる、もある
- 全員がペアプロする必要はない
- 苦手な人が2割くらいいるという研究。全員ができるものではない
- それは個性だから尊重しないとだめ
- ペアプﾛしないで価値を出せる人はやらなくていい
「ここは俺が書いた」感がない
食わず嫌いはもったいない
- 苦手な人は尊重しなきゃいけない
- でも、やってみたら気に入る人も多い
- ペアプロは楽しい
技術がある人がいない環境でペアプロをやるメリットはある？
- 慎重にならないといけない。全員スキル1だとペアプロ以外にも立て直しが必要。
- 経験長い人、既存システムの知見がある人とペアを組むのは効果がある。
- 開発環境や文法レベルで知識がたりないズブシロ同士が組んでもあまり効果がない。パラで勉強したほうが良いくらいの効果。
- 上級者同士は意味がある。対立しがちな上級者の戦いをペアプロで解決してもらえると良い。
会場Q&A
どんな学びがあるか、どんなスキルを提供できるかを教えてほしい
- 和田さんとペアプロする人は、業務の仕様を説明しないといけない。短時間で業務を説明する必要がある。ふわっと理解していることを説明することで整理される。
非エンジニア(管理部門、マネジメント層)への説明で納得してもらうには？
- 許可より謝罪っていう有名な言葉がある。
- 説明しても意味がないって言っちゃったら身もふたもないけど、リファクタやペアプロは許可されにくい。
- 不具合修正だと上に説明しやすいし、許可されやすい。
- 不具合発生時はチームのレベルアップチャンスなので、状況者がどう考えて直すのかを新人に見せる。そのあたりから導入していき、既成事実化していくのが現実的なライン。
