私の一週間の過ごし方
こんにちは。FFGアジャイル開発チームの 上司は現場ネコ と申します
私は銀行の支店で4年半ほど住宅ローン担当や法人営業をしたのちキャリアチャレンジ制度を使ってアジャイル開発チームに入りました
経験の浅さで周囲に劣るので、Webアプリ開発に関する素養を身に付けるために、仕事で携わっているPJの模倣環境を自宅で再現してみるなどして、日々精進しています
さてさて、今回のブログですが…今回は私が所属している開発チーム（俗称: ハイエナ）の一週間の過ごし方を紹介していきたいと思います
実世界のハイエナはまさに「食うか食われるか」という厳しい自然界で生きてますが、FFGのハイエナ共は会社でどう生息しているのか、など社内の様子が少しでも伝わればいいなと思います
ハイエナの開発サイクルについて
チームハイエナは、以前、ﾘﾏﾙﾏｶｰ氏の記事
で触れられていた、ペアプロによるトランクベースな開発ではなく、マージリクエスト&コードレビュー方式で開発を行っている集団です
私と同じ銀行員コンバート組である友人K氏の他に、新卒1年目等がおり、基本的に経験が浅いのでそういうプラクティスを取っている訳です
ちなみに、アイリスオーヤマ製大画面を買って貰って、製品評価ブログまで書いておきながらも
最近は大画面でのコードレビューを行っていません(・ω<) ﾃﾍﾍﾟﾛ
(その話は後ほど...)
話は戻りますが...
2019年6月にチームが発足したのですが、基本的な技術が身に付いてきた2019年9月から新規プロダクトを0ベースで作っています
とはいえ
Webアプリケーション開発における基本的な技術の習得
と
スクラムによるプロダクト開発
の両立が難しかったため、スクラムには手を出さず、ひとまずはシンプルなタスク管理で週次のサイクルで仕事を回していくところから始めています
そのようなバックグラウンドも踏まえながら、一週間の過ごし方を見ていただきます
一週間の過ごし方
元々は
というような一週間を過ごしていました
月曜日に行うプランニングでは、向こう一週間で消化できそうなバックログを決定するだけにとどめ、細かなタスク分解はデイリー会議で行っていました
ちなみに、会議以外の残り時間はひたすら開発作業に充てています
しかしながら
見積もりに対する実績のズレが毎日少しずつ生じ、木曜日までにタスクが終わらない
といったり
タスクが日をまたいでしまい、１日のど真ん中で取り掛かるバックログを選択。結果、個々人でタスク分解してしまうなどデイリー計画がおざなりになりがち
という課題が露見したため、ベロシティを安定させつつ、予定通り一週間が終われるような過ごし方を模索してみようということになり、トライ & エラー方式で色々試してみることにしました
次に試した方法は
であり、今までデイリー会議で行っていた細かなタスク分解作業を、月曜日にまとめて行ってみることにしました
この方法のメリットは
月曜日の時点でタスクが細かく分解されているため、一週間の開始時点での見積もりが立てやすい
です
この結果、一定の成果は得ることができましたが、デメリットとして
木曜日は脳内記憶が薄れた状態でタスクに取り掛かることになる(月曜日にタスク分解しているから)
月曜日にまとめて一週間分のプランニングをみっちり行うので、プランニング後半ともなるとヘトヘトになる
という課題が挙げられました
特に後者（ヘトヘトになる件）については、タスク分解の精度にも関わってきます
よって我々は再度別の方法を試すことになります
それは
です
二日毎にプランニングを行うスタイルを試してみました
この形式による目玉的なメリットは
計画を立てるスパンが二日なので計画と実績がズレにくい
です
短期間の予定を細切れで立てる方が、長期間の予定を一気に立てるよりも計画通りに遂行しやすい
というのは明白ですよね
また
水曜日に月・火がどうだったかプチ振り返りを行うことにより、水・木でテコ入れ修正できる
こともメリットだと感じております
成果として、この方法を採用してからは、計画通りに一週間を終えられている頻度が高いです
このようにハイエナの一週間の過ごし方は、日々改善のテコ入れが入っています
コードレビューについて
先ほど述べた通り、ハイエナはペアプロをやってないので、マージリクエスト方式で開発をしています
このやり方についてもトライ&エラーを繰り返し、今の形に落ち着いたという経緯があります
そもそも最初は下記大画面
で、モブレビューしていました（毎日16:45~17:45で）
しかし
コード理解スピードが異なり、各々が自分のタイミングで疑問を拾いにくい。結果、コードの共同所有に支障をきたす
担当者とテックリーダとのやりとりになりがち
というような問題点が出てきたため
作業ブランチを切った担当者が他メンバー全員にマージリクエストを依頼し、メンバーはすぐにコードレビューを行う。で、メンバー全員が👍したら、masterブランチにマージさせる、という今の形に変えました
この辺が大画面でのモブレビューをやめた理由です
で、これのメリットは
レビュアーは自分のペースでマージリクエストを確認することができる
です
とはいえ
レビュアーのスピードにより、マスターブランチにマージされるタイミングが遅れ、作業が頓挫することがある
レビューという業務も増えるので、プログラム書いていてノリに乗って来た時でも一度手を止めてレビューする必要がある
という弱点も秘めてます
また、コードレビューを依頼したマージリクエストがそもそもテスト通過してなかったら見る価値ないよね！
とかコードレビュー依頼来ているのにレビューするの忘れている！
などの課題が、振り返り会議であがったため
マージリクエストが作成、またはマージリクエストに変更が入ったタイミングでユニットテストを回す仕組み
や
レビュー忘れている人には通知を送る仕組み
も導入しました
我々のチームはこうして、プロダクトの品質を保ちつつ、コードの共同所有化を実現しています
ここまでやって初めて、ペアプロでトランクベースの開発を行うことがベロシティ出やすいのだとわかった感じでした......
でも、マージリクエスト方式の方が、よりコードの共同所有感は高い気がします
メンバーで議論した結果が、discussionという形で残っていくのも財産だなぁとしみじみ感じています
まとめ
というわけで、チームハイエナの一週間の過ごし方を紹介させていただきました
「日々をどういう風に過ごしているのか?」という部分が少しでも伝わったでしょうか?
プロダクト開発に慣れてきたら、スクラムにも挑戦していきたいと思っています