$shibayu36->blog;

株式会社アンドパッドでエンジニアをしています。プログラミングや読書のことなどについて書いています。

Findyさんのイベントで「今の生産性向上活動で大切にしている考え方」という発表をしました

開発生産性を高めるヒントを最前線で働くエンジニアによる取り組みから考える会 - connpassのイベントで、「今の生産性向上活動で大切にしている考え方 〜開発チームに属した改善活動から得た気づき〜」というタイトルで、開発生産性に関する発表をしてきました。

speakerdeck.com

自分はこれまで、10年近く開発チームの中からボトムアップでチーム改善・生産性改善をしてきました。例えば、GitHubを使った開発フロー改善、チームごとの開発生産性の定量化・可視化、バリューストリームマップを使った、開発フローのボトルネック発見、CIの高速化などによる生産性改善、Findy Teamsを使った生産性可視化と改善などです。

それらの活動では失敗も成功もありました。その体験から、改善活動をしているときに裏で大切にした方が良い考え方についても明確になってきました。

そこで今回は、「今の生産性向上活動で大切にしている考え方」の言語化を試みて、発表することになりました。具体的には以下の三つのことを大切にしています。

このことについて、発表で深堀りしているので、興味があれば是非資料を見ていただければと思います。ちなみに僕は以下のスライドが気に入ってます。

他の発表の感想

他の方の発表も「わかるわかる」と頷きながら聞いていました。簡単にですが感想です。

開発者の生産性向上の始め方・育て方 〜生産性向上チームの 7 年間から見えてきた知見〜 宮田 淳平さん(サイボウズ株式会社)

  • スケールするにつれて、改善活動を支援先のチームと進めていく、自力で改善活動を継続できるように、というのが良い話だなと思いました。「自分達で改善する」のではなくて、「改善できる能力をインストールする」みたいな感覚
  • 利用は強制しない、もめっっっっっっちゃ大事だなと思いました。基盤チーム・生産性向上チームが、変に標準化してしまって、逆にプロダクトチームの工夫を阻害するというのがあるあるなので、自分自身も気をつけていきたいです

OKRと連動した開発スピード向上のための土台づくり 前島 治樹さん(株式会社hokan)

  • インシデントスコアを付ける、なるほどと思いました
  • 障害の根本対策をするとき、「クリティカルなものは根本対策してもう起こさないようにする」「クリティカルでないものは、あえて根本対策をせず別の施策を優先する」の両方が大切だと思っています
  • インシデントスコアをつけることで、うまく両方を満たせそうだと思いました

開発生産性をハックする話 神谷 健さん(ファインディ株式会社)

  • まずは「生産性高そう」から始めませんかというのが非常に良かったです。エンジニアをやっていると、その特性からか「生産性などのデータを取るならちゃんと定義を決めないと」と思いがちなのですが、最初から定義を決め過ぎようとすると動けなくなってしまうというのがよくあるので、参考になりました
  • 自分もPR数という指標は思ったより良さそうと感じてます。自分もよく「1日1PRくらい作れると良いペースですね」という話をしてます。PRを細かく分けてもらえると、素早いフィードバックが回るんですよね
  • その上で、指標を給与の評価には使いたくないよね、は本当にその通りだなと思いました

参考: これまでの自分の生産性向上活動に関する記事

Re: チームのベロシティを上げる vs. 安定させる

yigarashi.hatenablog.com

これが良い話だなと思ったので感想メモ。

「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ?」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象

「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば

  • 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない(例えばコードのメンテナンス品質が思ったより低い)時も、上げる意識だと終わりにしてしまいたくなる
  • 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち
  • 何となく、悲観方向で見積もりをつけてしまう

そのため自分は、「安定させた上で、その後は価値提供の量および価値提供のスピード(フロー効率)を意識する」ようにしている。

ただし、以下のコメントもめちゃくちゃ分かる。

チームのベロシティを上げる vs. 安定させる - yigarashiのブログ

安定を優先すべきと頭ではわかっているが、数値的に上がっているのを見てモチベーションにつなげたいときがある

2022/04/26 11:28
b.hatena.ne.jp

この観点に関しては、以下のように考えている。

  • 成功体験を積むために、一番気軽な「ベロシティが上がった!」という体験をしたいということがある。つまりチームが理解しやすくするために敢えてベロシティに着目する。
  • その場合も、少なくとも先導する側は、「安定してユーザーに価値提供ができるチームを作る」「最速で価値検証ができるチーム」など、最終的な目標への意識を忘れないようにしたい
  • かつ、ベロシティに着目することを徐々にやめられるように、少しずつアジャイルの知識をチームに浸透させることが必要だと思う
  • なんだけど、「ベロシティあげよう」使ってしまいがちなんだよな〜〜〜〜〜〜〜〜(自戒)

コード変更で抜け漏れやミスを少なくするための習慣

自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。

  • 毎回のcommit時
    • 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする
  • PullRequest作成時
    • filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする
    • ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に「確認したこと」としてまとめる。必要があればgifアニメを添付しておく