ソフトウェアエンジニアが直接的に生み出すものはプログラムのコードそのものです。
しかし個人的な経験として成果物をコードそのものではなくプルリクエスト全体だと捉えることでぐっと仕事の質が良くなったので、その話について書いてみます。
※ 注：以降”プルリクエスト”は長いので”PR”と略します。
==================
「PRを成果物として捉える」というのはどういう意味かというと、「PRをなるべく丁寧に作ることを心がけ、他の人やあるいは未来の自分が見たときに背景や意図がわかるようにする」ことを指します。
実際PRのキレイさというトピックは実際世の中的にも重要だと認識されています。『プルリクエスト テンプレート』でググると、PRに「チケットURL」「修正背景」「レビューしてほしいポイント」「テスト観点」などの項目が入ったテンプレートが色々出てきます。
Githubでもチームで共有するPRテンプレートの機能がサポートされています。
PRテンプレートを用意しそこに書き込んでもらうメリットとしては『レビュアーがレビューしやすくなる』という点や『将来チームや自分が、コードが修正された背景をわかるようにするため』という点があります。
しかしもっと重要なメリットとして『修正意図やテスト観点などを記載しているうちに、自身の考慮漏れなどに気づける』ことがあります。
コーディング作業は、1行1行の詳細なロジックを集中して考える必要があり、どうしても近視眼的になりがちです。PRをキレイに書くという作業を通すことで、修正全体を俯瞰して捉えることができます。
修正する理由や修正のテスト項目漏れなどがないかについて考えてみる意味でも、PRをキレイに書くということは重要だと思います。
似た話としてPRレビューしてもらう前に、自身がレビュアーになりきってセルフレビューするのも非常にオススメです。
セルフレビューの際には、コードを1行1行丁寧に見ながらセルフコメントをつけていく作業をします。するとコードを書くときとは別の頭脳が働き、立ち止まって自分自身のコードを俯瞰して見れます。
それにより実装中には気づかなかったバグに気づいたり設計・実装の改善を思いついたりすることがよくあります。さらにいうと、レビュー作業自体がコードの課題点を言語化し分析する作業なので、自身のスキルアップにも繋がります。
（この話は以下記事でもしています）
実装より前にテスト項目を書いてしまうのも、私がたまに使う手です。テスト項目は空のPRを作って書いてもいいのですが、ローカルのメモに書くだけで大丈夫です。
TDD（テスト駆動開発）という有名な方式があり、あれはテストコードを書いてそれをパスするプロダクションコードを書くという手法ですが、PRのテスト項目を先に書いてそれを満たす実装を作るというのも広い意味では”テスト駆動開発”です（Kent Beckに怒られそうですが）。
当然ですが本家TDDとは違いこの手法ではメソッドやクラスの疎結合性などは担保されませんが、テスト観点漏れを減らせたり、あとは実装前に仕様全体を理解することでコーディングスピードを上げたり設計・実装が適切なものになるのを促したりすることができます。
逆に頭が疲れていてテスト項目がクリアに考えつかなかったり、あるいはコードをさっと書いてしまったほうが早かったりする場合は、とりあえずコーディングし始めてプルリクエストを作った後にテスト観点を書くのも悪くないです。
（『机上で考えるより、とりあえずコーディングし始めてあとでキレイにする』スタイルについては以下記事でも取り上げました。）
後付けか先付けかはさておき、いずれにせよ最終的にはPRをキレイな成果物として仕上げるのがポイントです。
==================
なおここまでの話はPRだけに限定した話をしてきますが、チケットやドキュメントを丁寧に書くことも同じ理由で仕事の質を上げることに役立ちます。
コーディングはどうしても細部に集中する作業なので、俯瞰して物事を見るタイミングをPR・チケット・ドキュメント等を書く作業時に取ることで、仕事の質が上がるというのが今回の話でした。
