瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

明日からできるチームの開発生産性の向上

明日からできるチームの生産性向上という小ネタです。

だいたいどこのチームでも通じる鉄板ネタを使ってます。 スクラムしてなくてもアジャイルでなくてもできるネタです。

これで成果出して信用稼いで、それで次のやりたいことをやらせてもらう布石作りにするのが目的だったりします。

1. Pull Requestラリーの削減

レビューを受ける側がPull Requestを出した際に、レビュワーがコメントを付けた後に1作業を入れます。
2人でペアプログラミングのような形で修正させます。
なぜ修正して欲しいのか、どうしてこの形ではよくないのか、どのようなかたちにすべきなのか。
その3点を説明しながら一気に直させることでレビューラリーを1発で終わらせます。

PRのOpenしてからCloseするまでの時間が一気に減ります。
また、同様の指摘が再発する率が減るので、今後の時間の節約になります。
PRのCloseまでのリードタイムが減るため、同時に開かれているPRも減ります。すなわちWIP数の削減につながります。

詳しい方法を聞きたい場合は私から聞き出してください。ビール一杯で話すはずです。

2. PRにテスト内容を追加

PR か Issueを最初に作った初期段階でRSpecでテストすべき内容を書きます。
初期段階、というのはコミットが行われていないか、最初の一回を行った段階です。
なお私の好みとしては1stコミットはspecファイルを空で作った "Implement fake spec of ...."にするのが好きです。
「今回のPRでテストすべき正常系。およびテストで保証したい異常系(存在する場合のみ)」を書くと、だいたいDoneの条件に近似します。
本質的にはどこまで書いたらDoneか、を書かせたいのですがそれを未経験者に理解させるのが難しいためこちらを書きます。
「これもっと細かくPRを分割できるよね?」「そもそもやりたいことがおかしくない?」というツッコミを実装を始める前の段階で発生させることを目的としてにSpecについてPRに書かせます。
ただし、JSでの処理をテストにおいて記述することは難しいです。

これはかなり効果があります。PRというかタスクの質を向上させ、手戻りや「成果に繋がらないタスク」を減らせるからです。
実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール二杯で話すはずです。

3. デザイナーからのコンテクスト説明

ProttやSketchにデザインをがっちり書く前に「ユーザーはこの機能を使ってなにをしたいか」「ユーザーにさせるUXをどう考えているか」「ユーザーはこの機能があるとどう嬉しいか」という説明を行います。
この説明の後にはデザイナーによるそう考えた仮説と根拠の提示、非デザイナーからの質疑応答があります。
時間はかかりますが、言語化された説明により開発サイドのモチベーションの向上やコンテクストの共有、「これいけるんじゃね感」や「腹落ち感」の醸成が期待できます。

つまり、ProttやSketchに実際にがっちり書く前に問題点の洗い出しとコンテクストの共有が行われるため、デザインの実装時間の短縮とデザインの効能発揮の打率向上が望めます。

個人的見解ですが、優秀なデザイナーの気合を入れたデザインは死亡フラグです。
実装者はProttoやSKetchからデザイナーの意図を推測し「リバースエンジニアリング」を行うため、再現度の面で粗が出ます。
また、ユーザーは優秀なデザイナーほど察しが良いわけでもなくストレスにも弱くまた流行のデザインと今までのデザインとの差異に拒否感を示しやすいので、おしゃれなデザインから意図を読み取れず離脱する傾向があります。

そこで一度デザイナーの脳内の現実歪曲フィールドから取り出し、「他人の眼」を経て揉み直すことでユーザーが受け入れやすく、また実装しやすいデザインを作れると考えています。
ペーパープロトタイピングなどでの非デザイナーの参画、特にディレクターやセールスの視点の取り込みもとても有効でした。

実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール三杯で話すはずです。