コードレビューをボトルネック化させないタスクの進め方

普段開発を行っているときコードレビューをすると思います。

しかしコードレビューの指摘と修正が繰り返されいつまで経ってもマージできないということが往々にして発生します。
レビューに何を求めるかはチームや組織によってまちまちですが、少なくともレビューの遅延が原因でマージやリリースが遅れるような状況は健全ではありません。

自分が入ったチームで行って効果的だったのは、実際に手を動かす前にタスクを全員で見る時間を作ることです。
もう少し具体的には開発の方針を決めてしまうことです。設計と言ってもいいかもしれません。

チームで開発をしていると言ってる割にこれをやっていないチームは意外と多い印象です。
各エンジニアがそれぞれ領域を持っているけどレビューはやらないといけないのでレビューだけ他のエンジニアにしてもらう…とか。

設計をどのくらいまでやるかはチーム内のレベル感に寄ると思います。
新しく入った人がいたりルーキーみたいな人がいるときはスケルトン作るくらいまでやってもいいかもしれません。

というかレビューが爆発してるパターンのときは大抵の場合、よくわからないけどそれらしいものを作ってレビューに出してそこで初めて設計レベルの指摘をされてほぼ全作り直し…というようなパターンが多いので、チーム内でその領域に詳しい人と一緒に全部作るくらいのことを最初はやってもらうくらいでもいいと思っています。

年数とか関係なくその部分のことをがわからないならわかるようにして、全員の前提知識を増やしてあげることが大切です。

スクラムフェス三河2021

参加してました。体調がアレだったので流しながら見てたりしてたので特に自分の中に残った部分だけ。

www.scrumfestmikawa.org

POはチームに口出ししてはいけないというやつを体感した話

今のチームでスクラムを始める時、多少時間はかかってもプランニングはやりきりましょうということをメンバーに対して話していて、合意も得ていた。

しかしPO（=事業部長）が無駄なMTGやってませんかと言ったことで一部のメンバーが過敏に反応して時間内に収めることを優先しようという動きを始めてしまった。

既存の考え方はなかなか変わらない。
MTG時間=無駄な時間という一般的に正しいと強く信仰されている言葉と、事業部長という立ち位置の人の発言というのがかなり大きかったのだと思う。

一応、この状態でもうまくいくならいいかと見守っていたものの、やはりプランニングが形骸化し始めている*1軌道修正をはかりたいところ。

POに対して「開発チームのプロセスに口出ししてはならない」というのが言われていますが、こういうことだったんだなーと初めて理解できました。
ある意味経験を得られてよかった（笑）

*1:各タスクやる人が見積もりしてねとか

なぜプロジェクトは予定通りに終われたのか

2月から関わっていたプロジェクトが無事に終了した。

タイトルでは予定通りと言っているが、実際には自社開発サービスのリプレースなので何かあったらリリース延期とかは出来る状態。
とはいえ、当初目標と定めていた6月末リリースを無事に終えられたので予定通りと言ってもいいと思う。

開発体制

• エンジニア2人とデザイナー1人の3人チーム
  • デザイナーもReact、TypeScript結構書ける
  • エンジニアはcss書けない
• RailsアプリからフロントエンドをNext.jsにリプレース
  • TypeScriptとGraphQL
  • NxとRelay（この記事では触れない）

目標を達成できたのはなぜか？

小さいチーム

• 人数が少なかったので意志決定と情報の共有のコストが少なかった

メンバー全員ある程度のスキルが揃っていた

• 全員がReact,TypeScriptおよび周辺の開発知識は一通りあった
• ただ、cssはデザイナーしか書けなかったためそこが少しネックになった
  • その時間を使ってエンジニアはリファクタリングやCI整備を進められた

フィードバックループ

• 毎日夕会を行いその日に起こった困りごとはその日に潰せていた
• 自分以外の2人は毎日出社していたため密なコミュニケーションを取っていた模様（自分は週1出社）*1

フェーズごとの設計

• 段階的にリリースを行うことになっていたため、フェーズごとにおおまかな設計を行った
  • 一つ前の開発で問題だったことをフィードバックして予め設計時に決めるなどの改善も行った
• ここで決めたことと今動いてるシステムを迷いなく作業ができる
  • 自分だけリモートでコミュニケーションが少なくなっても進められる状態だった

社内システムである

• 既存システムがあるのでそれを見ればよかった
• 再現が厳しいものはビジネス側と交渉して落とし所を探ることが出来る
  • 社内だからというだけでなくお互いの要求を並べて尊重できる組織文化があったこと

個人の感想

ある程度スキルと経験の揃った人がきちんと予定通りに終わらせるためにどうすればいいか考えて動いた結果、というのが正直なところ。

あとは社内システムなので融通を効かせられるのも大きい。
実際に納期延ばしてとかこれやめにしてとかは言ってないけどいざとなったら相談できるのと、無理な仕様が来ても難しいと言える関係は安心感がある。

自分としては「React,TypeScript,Next.jsわかるよね？」ということで招聘されたので無事に役目を果たせてホッとしているところ。

*1:今は出社は任意だが2人は家の事情等で出社を選択していたらしい

スクラムのMTG時間を削れと言われた

1週間のスプリントで毎週1時間ずつレトロスペクティブとプランニングをやっている。

スクラム1ヶ月ほどやってみてメンバーはそこそこいい感じの手応えを感じていたっぽいところ、上司からこの取組についてフィードバックがあり「メンバーのやりやすいようにやってくれて構わない」と言ってくれつつも遠回しにMTGを削って効率化しろという指摘をされた。

自分としてはまたいつものかと思いつつも「予定としてのMTG時間だけ削ってもその分だけ見えないところに分散するだけですよ」みたいなことを言って一応この時間の確保は続けさせてもらうよう話をしていた。

しかしその週のレトロスペクティブで時間を減らそうという話が出てしまった。
その週、レビューが爆発してリリース出来ないタスクが発生していて今後どうするという話をしていて当事者たちは「プランニングで厚目に見たい」という意見だったが他の人は「時間が増えてしまうので関係者だけでやればいいのでは」という意見だった。
まるで自分たちは関係者じゃないみたいな物言いでショックだった。同じチームなのに。

それとMTG時間を減らすことが目的になっていたのと、何よりそうなった原因が上司からの命令だったというのが情けない。
始めるときに1時間って長いって言われがちだけど〜みたいな話をして納得してもらったはずなのになー。まぁ1ヶ月経てば忘れるか。。。

ちなみに、自分は毎回1時間全部使い切れとは思ってない。
早く終われて作業にかかれるならそれに越したことはない。
ただ、現実問題が起こっている状況でコミュニケーションを削るのはありえないというのが自分の考え。

試してみればよかったのだろうか。

MTG30分削れば儲かるのか？を率直に聞いてみればよかったのだろうか。

ここまで書いてみて、実はMTG時間短縮云々じゃなくてメンバーに対して疑念が出来てしまったところがしんどいのかなと思った。

ここまでやってきたときに協力的っぽい感じがしたのは自分に関係があるところだったからなのか、目に見えやすかったからなのか等々考え始めてしまってしんどい。

混乱期に突入したのかなと思えばまぁ前進してる感じはするのでいいけど、このままだと形骸化して崩壊しそうなのでなにか手を考える。
すぐに悪くなるものへの対策はしやすいけど長期間に渡って効いてくるものは納得してもらうのがなかなか難しいね。

とりあえずモヤモヤを溜め込んでしまったのでここで吐き出しておく。

人事異動の時期

期の変わり目でそこそこ大きめの人事異動が発生している。

人員配置の最適化といえば聞こえはいいけど個人的な感想だけ言えば、半年かけて作ってきたチームや文化がリセットされてたまったもんじゃないと思う。

一般的にチームが機能し始めるようになるには3ヶ月〜半年程度かかると言われている。
んで、自分が今期面倒を見てきたチームも半年経ち今は技術的な相談くらいしか面倒を見ていない。要するに自律的なチームになれている。

しかし今回の異動で6人チームから3人が異動になったのとチームの事業的な役割も変わった。
新しい人が入ってきたわけじゃないというのは若干マシだけどまたここが機能するようになるまでの数ヶ月、模索の期間が続くはず（形成期、混乱期）

ちなみに自分は今回の異動とは別にひとあし先に異動になっている。
自分の異動の話を打診されたときは、既にチームは機能していたしこのような大きめの人事異動の話は全く出ていなかったので安心して承けたつもりだったんだけど…。*1

とはいえこれはあくまで会社全体のうちの一部署一組織しか見てない自分の感想なので、全社レベルの視点で見ると正しいのかもしれない。今の自分にはわからないけど。

そういえば評価面談をしたとき、現場レベルでのマネジメントは問題ないからもう一段上の視点（？）でのマネジメントを学んでほしいというようなことを言われた気がする。

これはいわゆる「経営者視点を持て」というアレだと思ってるので避けたいんだけど、それとは別に上が何を考えているのかは知っておいたほうがいいのかもしれない。
けどこれって社内政治とかそういうのに繋がりそうという気もしている。

求められていることをもう少し明確にしたほうがいいかもしれない。
その中から汎用的なものを探すという道筋が良さそう。

*1:あと、入社当時に上長になるはずだった人のところに行けるということで喜んで承けた

スクラムしてないのにスクラムマスターと呼ばれて

2020年も終わりですね。

部署が変わってからの仕事上の役割を決めるときになぜかスクラムマスターという名前の役割を与えられていた。

ただしチームはスクラム開発はしていない*1

これには理由があって、

• もともと配属されるはずのチームでアジャイル・スクラム開発の経験をチームに広めてほしいという話があったこと
• （手を動かす以外に）改善の活動をやりますよということをチーム内外へ明示すること

これらのことを上司が配慮してくれたことによる（と理解している）
とはいえ実際にそういう役割だと認識してくれたのは上司2人だけだったけどｗ

自分としては手を動かして成果物を作る以外の活動をする大義名分を得たと解釈して思う存分やらせてもらいました。

具体的なことは過去記事に書いてますが、いろいろ失敗しつつも経験や考えをもとに試したことが奏功したことは自分にとって大きな経験だったと思います。

来年やることはこれを自分のスキル・知識として明確化することですね。
これをやらないと今回の経験がただのラッキーパンチで終わったり自分がボトルネックになる可能性があるからです。

あと、問題・課題はきちんと捉えられているのに解消するための表現が下手くそという指摘もされてるので…。もう少し伝える力を身に着けなければ。

激動の2020年お疲れさまでした。

*1:スクラムしてるとは？という話はあるが少なくともチームはスクラム開発しているという意識はない状態