手が早い人になるために

前回の記事( https://note.com/kazumatsudo/n/n0616b5ed95fa )では、開発に必要な作業を細分化し、手が早い人に共通していることを列挙したあと手が遅くなる要因について検討しました。

手が遅くなる要因

- 課題の達成条件の把握に時間がかかる
- チームの制約を理解しきれておらず、作業の際にしばしば確認している
- プロジェクトに用いられている技術やツールに明るくなく、頻繁に使用方法を調べている
- テストの NG やレビューのコメントが多く、実装の手戻りが多い

今回は、これらの問題点を改善するアプローチを検討し、いかにして手が早い人になるかを考えていきたいと思います。

手が遅くなる要因に対処する観点

個人で作業を進める場合と比較した際に、チームで作業を進める上で考慮しなくてはならないポイントがいくつかあります。
そのポイントは、プロジェクトの進行を遅くするものだったり、逆に加速させてくれるものだったりしますが、概ねメンバとの認識合わせに起因するものだと考えられます。
今回はその認識合わせのポイントとして、具体的に 参考にする / 人に聞く / たたき台を用意する の3つの観点から、それぞれの要因への対策を検討したいと思います。

「課題の達成条件の把握に時間がかかる」件についての対策

課題は方針のみが示されており、詳細の検討は開発者に委ねられているケースがしばしば見受けられます。
達成条件がまとまっていれば開発者はすぐに実装に着手できますが、そうでない場合は着手前に大きく時間を取られることとなります。

【参考にする】
開発しているプロダクトがどんなにオリジナリティがあるものだったとしても、機能ごとに細分化して比較すると他のサービスとほとんど差が無くなる機能もあるかと存じます。
例えばログイン機能は大半のサービスに実装されており、本質的な操作に大きな差はありません。
そのため、いくつかのサービスに触れることでゴールのイメージを持つと良いかと思います。

【人に聞く】
機能によっては他のサービスに近いものがなく、詳細を詰めようにも想像がつかず途方に暮れてしまうこともあります。
これは時間をかけることで解消できる問題ではないため、課題を依頼した人により詳しい情報を聞きます。

【たたき台を用意する】
達成条件が固まってきたら、課題を依頼した人に対して条件のすり合わせを行い、合意を得ます。
この時、すり合わせは複数回発生するものだと考え、特に1回目をできる限り早く行うことがポイントとなります。
というのも、たまに課題を依頼した人自身が曖昧なイメージしかもてておらず、何が良くて何が悪いかを判断できないケースがあるためです。
この状態で詳細を固めても OK を貰える確率が高まるかというとそういうわけでもないため、ブラッシュアップに時間が掛かりそうであればある程度のところで区切りをつけ、まずは詳細を固める方向性が正しいかどうかの確認に注力します。

「チームの制約を理解しきれておらず、作業の際にしばしば確認している」件についての対策

前回の記事にて、制約を「成果物の一定以上の品質を担保するために設けた課題とは異なるいくつかの達成条件」と述べましたが、これは明示的なものだけではなく暗黙的なルールとなっていることもままあります。
文書化されていればセルフチェックが可能ですが、そうでない場合は確認のしようがないため、芳しくないフィードバックとなって返ってくる可能性もあります。
またそういったドキュメントが存在しない場合、開発者の検証が本人の裁量に委ねられ、確認事項の検討に時間が取られたりなど非効率な作業時間が生じます。

【参考にする】
マージされた Pull Request は、言い換えれば「チームのすべての制約をパスした成果物」です。
そのため、どういった課題に対しどのようなアプローチを採用して検証した結果、どんなフィードバックが返ってきているかを過去の Pull Request から学び、自分自身が作業をすすめる時に真似すると良いかと存じます。
逆に Pull Request やそれに準ずるものがチームにない、または Pull Request はあるがやりとりはほとんどなくそのままマージされているということであれば、制約は存在しないにほぼ等しいので不必要に臆することなく Pull Request を作成すれば良いことになります。

【人に聞く】
別の解決策は、チーム内のメンバに制約について確認することです。
とはいえ、いきなり「制約はなんですか？」と質問したとしても、回答が広範になって自分の作業範囲とピントが合わなかったり、回答者がその場で回答を思い浮かばずお茶を濁してしまうケースがあります(そして、レビューする段になってバツが悪そうに「ああ、このケースでは……」とフィードバックをもらうことになります)。
そうならないために、質問は課題に即したものであるなど、具体的なものであることが望ましいです。

【たたき台を用意する】
せっかく制約をその場で理解しても、人間は悲しいことにすぐ忘れてしまうものです。
そこで、チーム内で学んだことはその場でドキュメント化することで、後々振り返ることができるようになります。
第三者も理解しやすいような文書で Wiki や README に記しておくことがチームとしては理想かもしれませんが、心理的抵抗があるようならまずは手元のメモ帳にまとめるところから始めても良いかもしれません。

「プロジェクトに用いられている技術やツールに明るくなく、頻繁に使用方法を調べている」件についての対策

エンジニアには誰しもその技術にはじめて触れる瞬間があり、どんなにベテランの方であっても最初から精通している人はいません。
とはいえ、だからわからなくても仕方がないと開き直っても生産性に寄与することはないので、いかに素早く動くものを作れるかを考えていきたいと思います。

【参考にする】
プロジェクトにあるソースコードは、「最も身近にある、そのプロジェクトで採用されている技術の応用例」と言い換える事ができます。
普遍的な知識を得たいのであれば公式ドキュメントを参照することを勧めたいですが、具体的に動かす方法が知りたければ既に動いているものを観察することが手っ取り早いです。

【人に聞く】
当たり前といえば当たり前ですが、ソースコードがあればそのコードをコミットした人がいます。
そのコードをコミットした人は少なくとも指定された技術を用いて機能を実現するスキルを持っていると言えますので、その方に助言を仰げば有効な回答が得られるかと存じます。

【たたき台を用意する】
当たり前つながりで恐縮ですが、自分が確実にわかる範囲で実装することを心がけることは非常に重要です。
もしかしたら他によりよい実装方法があるかもしれない、と考えて調べることはとても良いことです。
しかし、納得がいくまで調査した結果、実装が期日までに間に合わなくなってしまっては元も子もありません。
まずは自分が一番慣れている方法での実装を試み、その上でタイムリミットまで余裕があるようなら、別解としてはじめて検討してみても良いかもしれません。

「テストの NG やレビューのコメントが多く、実装の手戻りが多い」件についての対策

レビューで改善要望を受け取った時、開発者は修正作業が発生します。
これが容易に完了するもの(例えば誤字脱字の修正など)であれば工数はほぼ無視できるかもしれませんが、考慮が漏れているケースがあったりプロジェクト内の制約を守れていない場合、修正に大きく時間がかかることがあります。

こういった手戻りは実装が進むにつれて深刻なものとなっていくため、早期発見できるかどうかがポイントとなります。
「チームの制約を理解しきれておらず、作業の際にしばしば確認している」の項目で述べたように、過去の Pull Request を参考にしたりメンバに具体的に質問をすることで、成果物の方向性が最初からズレないようにすることは大切です。
また、レビューは完了してはじめて依頼するのではなく、段階的にチェックしてもらうことで、作業を進めていくうちにだんだんコースから外れてしまっていたというようなことも避けられるかと存じます。

まとめ

今回は、手が遅くなる要因を 参考にする / 人に聞く / たたき台を用意する の3つの観点から検討し、いかにして手が早い人になるかを考えました。
次回は、エンジニアをサポートする立場になった時に、どのようにして手が早いエンジニアに育てていくかを検討したいと考えていきたいと思います。