patorashのブログ

方向性はまだない

6月になってやっていること

先月のやつは、これ。

patorash.hatenablog.com

特に5月から代わり映えしていないのだけれど、継続して取り組んでいることは以下の通り。

  • EffectiveRuby読書会
  • モブレビュー
  • スプリントプランニング
  • レビューをする曜日を決める等

主に変更点はないのだが、他に取り組んだことを上げるとすると、以下の通り。 (あくまで私が率いるチームの、です)

  • 開発チームのルールを明文化した。開発チームのメンバーに求める資質なども。
  • 後輩氏とペアでRundeckのジョブを作成した。
  • プルリクのマージはプルリクを作った人が行うことにした。

開発チームのルールを明文化した

これは、まぁうちのチームに人が増えることは滅多にないのだけれど、オンボーディング的な資料にもなるし、自分たちでも確認しやすくするためにやった。暗黙的なルールよりは、オープンであるほうがいい。

求める資質については、ざっくりとは「自律的に動けるようになろう」と言いたかったのだけれど、それってどういうことか?を私の言葉で箇条書きしといた。

チームのメンバーに求めるもの

  • ミスを隠さない・ごまかさないこと
    • ミスは誰にでもあり得ること。チームでリカバリし、対策を練りましょう。
  • 問題を抱え込まないこと
    • 小さな問題だったら対処できるけど、問題が大きくなってからだと難しくなります。チームで早めに対処できるように動きましょう
  • 汚い言葉を使わないこと
    • その言葉を使った人自身のイメージが悪くなるだけ。良いことはありません。
  • わからないことをそのままにしないこと
    • 質問する、調査する、わかったことを共有する
  • 業務で得られた知見は情報共有すること
    • ドキュメント化する
      • 他のチームでも役に立つ情報かもしれません
      • なにより、自分のためになります
    • 汎用的な内容はブログ等で発信してもよいでしょう
  • 確認・確認・確認!
    • たとえ、相手に投げたボールが戻ってこなくても、返信することをうっかり忘れてしまっていることがあるので、適宜、再度確認をお願いしましょう
  • 自分で課題を見つけること
    • 言われたことだけをやるのではなく、自分自身で課題を探し、よりよくしていきましょう。

これらをまとめた言葉でいうと、 『自律的に動けるようになろう』 となります。

こんな感じ。特に、汚い言葉を使わないってのはすごく重視している。論理的に正しくても言い方がよくないと感情的な不和が起きてしまう。

後輩氏とペアでRundeckのジョブを作成した

これは、スモール・リーダーシップで書かれていた「一人でやらない」を実践した。無論、一人でやったほうが早いのだが、滅多にやらないことこそ、一人でやらずに後輩氏とやることで、後輩氏にとってのブラックボックスを減らすことができたと思う。今後、Rundeckのジョブを作ったり修正することが発生しても、後輩氏に頼むことができるようになった。

プルリクのマージはプルリクを作った人が行うことにした

これは、上司の id:tech-kazuhisa が、うちのTeamsに id:Songmu さんのGitのワークフローの記事の話題を投稿していて、それに感銘を受けたのですぐに採用した。まんまだが、私のレビューが通ればOKみたいな感じになっていたからである。

songmu.jp

以下は、開発チームのルールからの抜粋。

コードの管理はチームの責任であることが大前提ではあります。 しかし、○○さんがOK出したのでヨシ!というような人に依存する形はよくないというところと、 自分のコードがちゃんとプロダクトに反映されていくという当事者意識を持ってほしいからです。

以下は、そんむーさんのブログから抜粋した内容になります。

レビューとマージ

  • 社内プロダクト開発においてはpull requestを出した当人がマージボタンを押す
    • これは意見があると思うが個人的にはこだわりのスタイル
    • 「自分が押したマージが本番に出ていく」という体験をしてもらう
    • コードベースへの当人のオーナーシップの醸成
  • レビューを通して開発した当人が安心してマージボタンを押せる状況を作り出す
  • 「リードエンジニアにレビューしてもらってマージしてもらう」はアンチパターン
    • 暗黙の権威が生まれ、勾配も拡大する一方となる
    • レビューしてもらえたから大丈夫だろう、と担当者が油断する
    • レビュワーの好みにコード全体が偏る
    • さらにはレビュワーが過剰に直させる、みたいなことも起きがち
    • →コードベースが「リードエンジニアのコード」から脱却できない

6月のまとめ

基本的によかったことを継続している。EffectiveRuby読書会は月曜日に2時間くらいやっているので結構進んでいて、あと2回くらいで終わりそう。コードレビュー時の視点として、知っておいてよさそうなことが結構あったし、標準ライブラリの便利な使い方とかも知ることができたので結構得るものが多かった。

集中できる時間が増えたので、メンバーを育成しつつも、成果を出しやすくなってきた。