手が早い人に共通していること / 手を遅くしている要因

チームで開発を進めていると「あの人は手が早い」「自分は手が遅くて……」といった言葉を耳にする機会があると思います。
ここでの「手の早さ」とは開発速度を指すことが多く、早ければ早いほど良いものとされています。

そこでこの記事では、手が早い人に共通していることは何か、そして手を遅くしている要因とは何かについて考えていきたいと思います。

開発に必要な作業

作業は大きく分解すると、 インプット / プロセス / アウトプット の三段階に分類することができます。
ある課題を解決するための機能実装を例に、作業を細分化してみます。

インプット (成果物を作り出すために必要な材料や情報の収集)

1. 課題
そもそも依頼者がどのような成果物を期待しているかがわからなければ、作業をすすめることができません。
例えば「新規登録ができる」「ログインができる」などが挙げられ、開発者はまず何をすべきかを把握します。

2. 制約
多くのプロジェクトにおいては、成果物の一定以上の品質を担保するために課題とは別にいくつかの達成条件を設けているケースがあります。
例えば「Pull Request は1人以上に approve されなければいけない」「テストカバレッジは85％以上を維持すること」「Clean Swift を採用し、 API の呼び出しは Worker を通じて行う」といったものが挙げられ、開発者はこういった前提条件を理解している必要があります。

3. 技術、ツールなどの使い方
コーディングは何らかの言語によって記述されており、多くの場合はその上でフレームワークやライブラリ、外部ツールなどが使われています。
例えば「TypeScript」「React」「Next.js」「Sentry」などが挙げられ、開発者はそれらの使い方を把握している必要があります。

プロセス (集めた材料や情報を成果物に変換する処理)

1. 課題解決の方針検討
開発者はまず、自身が使い方を理解している技術やツールを用いて制約を満たしつつ、課題をどのように解決するかを検討します。

2. コーディング
開発の方針が立ったら、開発者はそれに従い実装を行います。

3. 実装内容のテスト、及びそれに伴う修正
実装が一区切りついた段階で、開発者は実装内容が達成条件を満たしているかを検証し、意図しない結果となる場合は修正します。

4. 第三者から指摘された内容の修正
チームで開発している場合、他のメンバがレビューを行い、実装内容を第三者がチェックする仕組みを取り入れていることがままあります。
その際に改善要望のコメントがあった場合は対応します。

アウトプット (成果物)

課題に対して実装したコードを、いくつかの説明文を添えて提出します。
例えば Pull Request などが挙げられます。

以上が インプット / プロセス / アウトプット に細分化した例となります。

手が早い人に共通していること

前の節で開発に必要な作業をより細かく分解しましたが、手が早い方はすべての工程において想定以上の時間がかかっていないことが考えられます。
言い換えると、手が早い方とは下記をほぼ満たしていることになります。

- 課題の達成条件を素早く把握できる
- チームの制約を理解している
- プロジェクトに用いられている技術やツールに精通している
- テストの NG やレビューのコメントが少なく、実装の手戻りがほとんどない

手が遅くなる要因

裏を返すと、手が遅くなる要因とは一部または全部の作業に想定以上の時間を費やしているということが考えられます。

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

まとめ

今回は、開発に必要な作業を細分化し、手が早い人に共通していることを列挙したあと手が遅くなる要因について検討しました。

手が遅くなる要因

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

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