デブサミ2020参加メモ Day1
この記事について
イベント参加直後の自分の思い出す用メモとして残しているため、整理できていなくて散らかった内容になっていると思いますが、ご了承ください。
当日の僕のTwitter実況タイムライン twitter.com
2日目の記事 nabless.hatenablog.com
CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見
優れたパフォーマンスのチームか否かは、CI/CDの下記メトリクスで測ると良い
- デプロイ頻度（ワークフローが開始される頻度）
- 変更のリードタイム（ワークフローの動作時間）
- 平均修復時間（グリーンに変わるまでに要する時間）
- 失敗の頻度（ワークフローの失敗率）
デプロイ頻度
- 多くの企業が、高頻度のデプロイにチャレンジしている
- 1日に10回以上デプロイは多くない
- 優れたチームは、1日に数回のデプロイがある
- フィーチャーフラグを使って、リリースとデプロイを切り離すと良いかも
リードタイム
- 90%は30以内の動作時間
平均修復時間
- デフォルトブランチの場合、50%は1h以内に、25%は15分以内に修復
- 30%は90日で1回も失敗していない
失敗の頻度
- 27%のワークフローは失敗
- トピックブランチの失敗に起因
noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦
www.slideshare.net
noteのグロースモデルのPoint
- 単一のKPIを追わない（UXが悪くなる）
- バランス良く成長させた
- 数字が落ちているところを補強する
Noteのグロースモデルを支えるチーム
質とスピード
一般的にトレードオフとされる子たち
- 時間
- 予算
- 品質
- スコープ
品質が犠牲にされやすい…
品質を犠牲にすれば…
- 短期的にはスピードを得られる
- 中期的には逆効果になる
- 長期的には致命傷になる
- 長期的はわかる。
- じゃあ、短期的〜中期的の間はどこ？それは後で。
- 長期的はわかる。
ここから、品質を深掘っていく
- 品質とは
- 誰かにとっての価値である
- 日本語でいうと「〜性」 = ilitys（保守性、メンテナンス性、拡張性…）
- 狩野モデル
- いいかえると…
- ユーザから見える品質、見えない品質
- 外部品質
- 利用時の品質、、製品品質
- 機能要件、
- 品質には外部・内部があり、犠牲にされるのは内部品質である場合が多い
- ユーザから見える品質、見えない品質
- いいかえると…
犠牲に捧げた内部品質（仮説）
- Maintainability 保守性
- テスト容易性
- 理解容易性
- 変更容易性
- つまり、保守性とスピードと言い換えることができる
- 保守性の低さ（≒技術的負債）がもたらすもの
- ひとつひとつの変更に余計な手間がかかる
- 前は1週間でできていたものが、何故か3週間くらいかかることに…
- ひとつひとつの変更に余計な手間がかかる
- 保守性の低さ（≒技術的負債）がもたらすもの
- つまり、保守性とスピードと言い換えることができる
短期的と中期的の境界は？
- スピードを落とせば、保守性は上がるか？
- 上がらない。技術力に依存する。
- 品質アップはコストアップか？コストダウンか？
- すでにたくさん議論されているから調べてみてね
品質"実質無料" とは？
- 向上させることで、手戻りを減らせる
- 「品質向上のためのコスト」が、「品質向上で減らせたやり直しにかかるコスト」を上回ることにより、結果的に"実質無料"
品質は制御変数ではない
- 品質を高めることで、デリバリーが高速になる
- 「短期的にも長期的にも、崩壊したコードを書く方がクリーンなコードを書くよりも常に遅い」と言う方もいる
コードの品質を高く保っていた「にもかかわらず」、速いのではなく、コードの品質を高く保っていたからこそ、速い。
- 品質は、劣化すればリードタイムが増加
- リードタイムが増加すれば、仮説検証プロセスが回らない
4つのキーメトリクス
- リードタイム（ユーザに届いて使えるまでの時間）
- デプロイ頻度
- MTTR（平均修復時間）
- 変更失敗率
本当の関係
- 内部品質がスピードを生む
- スピードが学びのループを生む
- ループが外部品質を生む
- 外部品質が競争力を生む
- 競争力が売り上げを生む
- 売り上げが内部品質を育む
質 vs スピード という概念は、根本的に間違っている二律背反の関係は、局所的なものでしかない
内部品質への投資の損益分岐点はいつ来るのか？1ヶ月以内に現れる。
※テスト自動化の損益分岐点：4回
つまり、質への投資をすることは、1ヶ月以内に自分たちが利益を享受する。内部品質の顧客は自分たちそのものである。
- 時間に対してやるべきことが多すぎる場合、何をすべきか？
- スコープを削る （or リリース日を延期する）
- スピード＆質は、何とトレードオフオフになるか？
- 教育、次世代への投資、多様性
メンバーの成長と、その成長のために必要なフィードバックや学習の時間が、本当にトレードオフになっている
ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
ツイートなし
セッション説明から個人的に（勝手に）期待していた内容ではなく、お話は上手だったのだが、ミスマッチだった感があった。 大きな単語を使ってるところは今後もそういったリスクはあるかも…気をつけよう。
Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦
www.slideshare.net
だいたい、大きな企業の理念ってのは立派なことが書いてあるものなんで、まぁ立派なことが書いてあります
Oneチームで一体となってイノベーションできた
- 数年掛けたプロジェクトをリリース！が、1年で使われなくなった。
- 何故か？
- 必要なものが変化していた
- 何故か？
何言ってるかわからん！2週間やるから作ってみろ！
こんなこと言える部長さん超素敵じゃないですか
チームをつくるモブプログラミング ～内側と外側から語る～
モブプロ ≠ エンジニアプラクティス
モブプロの種類
- チームをブーストするモブプロ
- 仕事をドライブするモブプロ
おすすめ本 →モブプロベストプラクティス
目的とゴールを定めた方がいいよ
Q モブプロを始めるときにどう始めれば良いか？特に、ネガティブな反応をされたときには？
- 期限付きで実験してみようよ！
- 外部ですでにやっている人を連れてくる
Q 個人作業したいと言われたら？
- 先ずはやってみて欲しい。その上で、こんなことは個人で、みんなでと決めていくとよい
モブプロ × 知識移転
- 暗黙知を伝えるには、一緒にやるしかない
- モブプロは、レビューおじさん問題への一つの解決策になる
- なぜなら、レビューの目的（検査・学習・強化）の内、検査・学習をカバーしている
- 肯定としてのレビューはモブプロで代替可能
- が、全体を見ながらのフィードバックは弱い
- ふりかえりに近いレビューを取り入れるとうまくワークする
- なぜなら、レビューの目的（検査・学習・強化）の内、検査・学習をカバーしている
Q レビューの中でどんな会話してる？喧嘩にならない？
- 喧嘩になって困るチームもある。
- が、建設的なチームになるチャンスでもある。
Q 「わからない」と言えない人はでない？
- いると思う。
- ドライバーを大目にやらしてあげる以外でも、定期的に「ここまででわからないことは？」とふりかえる時間をとる。
モブプロを、仕事に活かすか、チームに活かすかでアプローチが変わる
心理的安全 ≠ なぁなぁ、仲良しクラブ ↓ 実験して、「これじゃだめじゃん！」「あれやってみよう！」的な状況
Q 仕事を分担するよりも生産性落ちるんじゃないの？
- 単純作業ならそう。
- その上で、人数が多すぎるとモブは効率は落ちる（例では10人とか）
- スキルを身につけて、中期的にチームに対する寄与できるようになってくる。
- なので、短期的には確かに厳しい。中長期的に見てほしい。
Q 程よい学習状態に身を置くために工夫していることは？
- そもそも、安定している状態ってそんなに無いのでは？
- 誰かが、チームに影響が無い様にしている。ので、自分たちからそれを取りに行くと良い。
Q コーチ目線で、「モブプロをうまく使えてるなー」というチームの特徴
- 楽しそう
- ドライバーを積極的に取りに行こうとする、固定化しない状態
- マネージャー等がチームをほっといてくれている
モブプロの全体性
- モブをうまくやるためには、インテグラル理論の4象限？を全体的にみる必要がある（だったかな…）
まとめ的な
- ずっとモブプロをするのが正解ではない。
- 状況によってソロ、ペアも取り入れる。
- 場面場面で最適な選択をすることが大切
- 一緒に行動（同じ画面をみる）することが大事なわけではない
I / You から We へ
モブプロはチームだ！！
非公式懇親会
@narinarita1980a さんの粋な計らいにより、 @higuyume さんとPodcastやります宣言を公衆の面前でしたのはこちらのアカウントです、乞うご期待ください。#devsumi https://t.co/Al7poOAKJ6
— なべさん@家電大好きおじさん (@watanabeisan) February 13, 2020
