成果報酬型の開発フロー
とある現場でお誘いをいただき、フロントエンド開発に関する勉強会を行わせて頂きました。
小規模な勉強会でしたが、初登壇ということで、気合を入れてやってきました！
みんな熱心に話を聞いてくれて、とても楽しかったです。
今日も現場の話ですが。
日本の開発の現場では、リモートワークの導入がうまくいっていなかったり、スクラム開発がいまいち機能していなかったりします。
自身が過去携わってきた現場でも、KPT を毎週行ったり、プランニングポーカーを導入してみたり、ZenHub を導入してみたりと、色々と試行錯誤されていました。
とはいえ一歩引いた目線で見てみると、確かに KPT やプランニングポーカーや ZenHub とかってどれも有用ですが、まだその前の段階がうまくいっていないのでは？と思うことが少なくなかったです。
つまり、タスクの切り方と、タスクをクリアするということを、もっとしっかり考えるべきではないかなーと。
どこの現場でも感じるのが、タスクの粗さであり、タスクの粒度が大きすぎるなぁと。
個人的に、タスクって小さく切って損はないと思っています、小さく切りすぎても良いよってことです。
自身がテックリードを務めるプロジェクトでは、メンバーになるべく小さくタスクを切って渡すようにします。
ここで言うタスクというのは、GitHub の場合必然的に Issue になるのですが。
小さい Issue を渡されたメンバーは、Issue が小さいのですぐにクリアすることができ、小さい PR を上げてきます。
自分はその小さい PR をさくっとレビューし、Merge を行います。
で、また小さい Issue を渡す…というフローを延々繰り返します。
小さい Issue を切ると Issue だらけになって大変じゃないのか？という疑問が湧くと思うのですが。
少なくとも、Web 開発の現場においては、そこまで Issue だらけになりません。
自分の場合、基本的に各スプリント内でクリアすべき Issue しか立てないですし、スプリントもかなり小さい単位で行うので、多く立てることができない、という感じです。
で、コツとしては、問題やバグが見つかった場合、すぐに対応する、というフローを取ることが大切です。
フロントエンド開発において、問題の先送りはまじでロクなことにならないと経験上思っているので、どんなに重いものであっても、次のスプリントまでには解決するよう心がけます。
と、口では偉そうなことを言ってますが、根本の技術を置き換えたりしない限りは、大概のケースで問題ってすぐに対応できます、しょせんフロントエンド開発ですし。
にも関わらず、問題を先送りにせざるを得ないケースって、どちらかといえばメンバーの技術力や知識、人間性に問題があるケースがほとんどなのかなーと。
きちんと作っていれば修正ってそこまで大変ではないです、きちんと作っていないから修正が大変なのは、もう言わずもがなですよね。
タスクが大きいほうが良い、みたいな妄言を言い放つ人はこの世の中そうそういないとは思っています。
にも関わらず現場レベルになると、なーぜかタスクがめっちゃでかい、みたいケースってすごく多くて。
タスクが大きいとクリアするのにも時間がかかるし、PR が大きくなりすぎて問題やバグに気づきにくくレビューの質が下がるし時間もやたらかかるし、スプリントもぐっちゃぐちゃになって良いことなんて何もありません。
ではなぜタスクを小さく切ることができないのか、それには大きく 2 つの理由があると思っていて。
- 小さいタスクを大量に切るのが面倒くさい
- 小さいタスクを切るだけの力量がない
かなーと。
1 については人間性的な話だと思っていて、これが理由な人ははっきり言ってクソ野郎だと思っています。
それこそがテックリードの腕の見せどころであり、モチベーターであるべき姿ではないのか？と。
2 についてはどこの現場にもつきもので、自分も常に悩まされます。
与えられた仕様に対して、どうやってクリアすべきなのかの正しい判断を行うことが出来ず、曖昧なタスクを切る、といったケースがこれに当てはまります。
通常であれば、まずは現場レベルでなく個人レベルでどうやったらクリアできるかいろいろ試した後、エビデンスの元細かいタスクを切ってやるべきなのですが。
いかんせん日本の現場は余裕がないため、そこまでの時間を割いてくれるケースってまれです。
もちろん、そこまでの技術力を有していないことも確かに問題かもしれません。
ケースバイケースだとは思いますが、基本的なことであれば、ある程度しっかりプライベートで勉強しておかないと太刀打ちできないよなーとも思います。
自分がテックリードを務める場合、各スプリントに入る際に、そのスプリント中にどこまで実装を行えば良いか、まずディレクターに確認を行います。
与えられた仕様に対し、まずクリアすべき Issue のみを立て、その Issue を各メンバーに割り振ります。
あくまで直近でクリアすべき Issue しか立てないため、Issue は少ししか立てられないです。
メンバーがクリアしている間に次にクリアしてもらうべき Issue を立て、PR が上がってきたらその Issue を割り当てます。
そのため、各メンバーは大体 2 つか 3 つくらいの Issue を常に抱えた状態になります。
各メンバーが抱える Issue が 1 つだと、PR を上げた後に暇な時間ができてしまうため、そういった状態を発生させないようにします。
スプリント中に目標まで達成できたら、そのスプリント中はタスクを割り振りません、好きにしていいよ状態ですね。
もちろん業務中なので勉強をしてほしいですが、そこらへんは各メンバーの意識に依りますし、特にこれといって制限はしません。
で、これこそがスクラム開発であって、リモートワークでもうまくいく方法なのかなーと勝手に思っていたり。
与えられた仕様に対し、適切なクリア方法を判断し、スケジュール感を明確にし、タスクを細かく切ること。
スケジュール内にタスクがクリアできたら、あとは好きにしたらいーよ、というのが本来仕事のあるべき姿だと強く思っています。
結局のところ、適切な課題感を持ることが大切であって、そこがテックリードに求められる一番のポイントなのかなーと。