2022年4月26日に、**米国GitHubから「GitHub Desktop 3.0」がリリースされました。**GitHub Desktopはソフトウェア開発者にとっては必須ともいえるツールです。

この記事では、これからGitHubを利用してみようと考えているエンジニアの方に向けて、GitHubとは何か、GitHub Desktopを使うと何ができるのか、「GitHub Desktop 3.0」によって何が変わったのかについてやさしく解説していきます。

*【参考】：[GitHub Desktop 3.0でPull Requestとのインテグレーションを強化｜GitHubBlog](https://github.blog/jp/2022-04-28-github-desktop-3-0-brings-better-integration-for-your-pull-requests/)*

まずは、GitHub・GitHub Desktopの概要について確認しておきましょう。

GitHub（ギットハブ）は世界中の人々が利用し、**プログラムコードの保存・管理・公開ができる「ソースコード管理サービス」で、GitHub社によって提供・運用されています。**

GitHubの主な目的としては、世界中の人々に自身が作成したプログラムを主に無償で配布することで、その際に「商用利用は不可」といった条件を指定できます。この条件をlicence（ライセンス）と言います。

GitHubは開発プロジェクトや企業組織などで、ソースコードの管理に利用され、ソースコード管理に関わる手間やコストの削減に役立っています。また、ソースコードの公開・更新履歴（history）の閲覧・共有されたソースコードの修正・バグ管理など、さまざまな機能が用意されているためエンジニアにとっては非常に便利なサービスです。

GitHubではコマンド操作を通じてさまざまな機能を利用するのが一般的でしたが、**コマンド操作不要で、視覚的に操作ができるようにしたのが「GitHub Desktop」です。**「GitHub Desktop」はGitHub純正のツールで、無償で利用することができます。

GitHubDestopはエンジニア志望の方以外にも、Web制作に携わるコーダーの方やWebデザイナーの方にとっても便利なツールです。

またGitHub DesktopはWindowsはもとより、Mac（M1を含む）やLinuxにも対応したマルチプラットフォームであるため、エンジニアにとってはありがたいツールです。ただし、公式サイトで記載されているのはWindows用とMac用のみなので、Linuxで使いたい方は以下の参考サイトを参照してください。

*【参考】：[To install Github Desktop for Ubuntu](https://gist.github.com/berkorbay/6feda478a00b0432d13f1fc0a50467f1)*

## GitHub Desktop 3.0の変更点や特徴

GitHub Desktopの概略について理解できたところで、この度*2年ぶりのメジャーアップデートとして登場したGitHub Desktop 3.0の特徴や追加機能について見ていきましょう。*

GitHub Desktop 3.0は、主にプルリクエスト機能のコミットの破棄・並べ替え・修正などに関わるGit操作へのサポート改善が行われています。

他には、GitHub自体とローカル開発のワークフローを近づけるエキサイティングな機能も追加されています。**この機能追加と改善によって、開発プロジェクトなどでより一層の生産性向上や効率化が期待できます。**

*【参考】：[GitHub Desktop 3.0 brings better integration for your pull requests](https://github.blog/2022-04-26-github-desktop-3-0-brings-better-integration-for-your-pull-requests/)*

### プルリクエストのチェックバッジ追加

GitHub Desktop 3.0では、プルリクエスト番号の右に**「GitHubAction」のチェックが完了しているかどうかを示すバッジが新たに設けられました。**

バッジをクリックすると、「GitHubAction」のチェック状況、ジョブやステップの内容確認を行え、何か問題があればそれを修正して、再度チェックを実行することができます。

「GitHubAction」は2019年に追加され、これまでは外部サービスとの連携が必要だった自動ビルド、自動テストなどがGitHubのみで実現できる機能です。

### プルリクエスト通知機能の改善

通知機能があると便利ですが、不要な通知や重要性の低い通知は単なるノイズとなってしまいます。

GitHub Desktop 3.0では、関係するすべてのリポジトリや、すべてのイベントについて通知を行う代わりに、**作業中のリポジトリに関して重要な通知だけを送るように改善されました。**これにより、無用な通知に悩まされることは減り、より作業に集中できるようになります。

### プルリクエストのチェック失敗通知

GitHub Desktop 3.0から、**プルリクエストのマージに失敗や問題が生じると、通知が行われるようになりました。**さらに問題詳細を知らせるダイアログが表示され、ダイアログからブランチに戻って修正作業を行う、あるいはチェックのやり直しを指示することができるようになりました。

### プルリクエストのレビュー通知

GitHub Desktop 3.0では、**プルリクエストのレビュー通知が行われるようになりました。**この機能によって、メンバーが修正要求をしたのか、あるいはプルリクエストを承認したのか、単にプルリクエストにコメントしただけなのかなどがすぐに分かるようになりました。

また、修正要求や提案が上がった際には、直ちにそのブランチに画面を切り替え、すぐに対応することが可能です。

## GitHubを使う上で押さえておきたいこと

*Gitfubを利用する上で、最低限押さえておきたい用語や、機能があります。*ここでは入門者が知っておきたい用語と機能について解説をします。

ここではGitHubを使う上で、**最低限知っておきたい基本用語を7つ紹介します。**どの用語も頻繁に使いますので、この機会に覚えておきましょう。

*1：リモートリポジトリ*
リポジトリは倉庫を意味し、GitHub上ではディレクトリやファイルの情報を保管する場所のことです。リポジトリはディレクトリやファイルの変更履歴を記録し、ソースコードのバージョンの管理ができます。

リモートリポジトリは、インターネット上に保存してあるリポジトリを指します。開発者はリモートリポジトリからローカルPCにリポジトリを複製して、ローカルで作業し、作業の結果をリモートリポジトリと同期することができます。

*2：ローカルリポジトリ*
ローカル環境（開発者のPC）にあるリポジトリのことをローカルリポジトリと呼びます。ローカルリポジトリを新たにローカル環境に作成したり、リモートリポジトリから複製したりして、ローカルリポジトリ上で作成したプログラムのバグ修正や機能追加などを行えます。

ローカルリポジトリでの作業結果を他の開発者と共有したい場合は、リモートリポジトリにアップロードして公開することでできます。

*3：プッシュ*
ローカルリポジトリをリモートリポジトリと同期して、自分のコミットを反映させることをプッシュといいます。

また、チームで作業をしている場合には、他の人がプッシュして、リモートリポジトリに変更が加えられている場合もあります。プッシュに対し、リモートリポジトリの変更をローカルリポジトリに同期させることをプルといいます。

*4：コミット*
コミットとは、別名リビジョンとも言い、GitHub上のファイルに対する個々の変更のことです。ファイルに対してコミットをし、その変更を保存すると、一意の IDが作成されます。その際にコミットした変更点と、いつ誰が変更したかの記録を保持できます。

*5：ブランチ*
ディレクトリやファイルの変更履歴の流れを分岐させて記録したものをブランチといいます。オリジナルの履歴から分岐したブランチは、他のブランチの変更などの影響を受けません。

リリース済みソフトウェアなどに影響を与えず、バグ修正や機能追加を行う場合は、複数のブランチを作って、それぞれで修正や機能追加を進めることができます。作業が終了したブランチをオリジナルに統合することをマージ（統合）と称します。

*6：プルリクエスト*
当該プログラムの関係者、レビュワーに対してソースコードの変更を通知し、オリジナルの更新を依頼するための機能をプルリクエストといいます。1人では見逃しがちなコードの記述ミスやバグなどが発見しやすくなり、プログラムの品質向上にも役立ちます。

*7：フォーク*
GitHub上の自身のアカウント領域に対して、既存のリポジトリを複製する機能をフォークといいます。自身のフォークしたリポジトリでは作業内容の更新が行えます。

また、フォークした自身のリポジトリ更新結果を、既存のリポジトリに対してプルリクエストすることで、管理者はその更新内容を通知で把握することができ、リポジトリの共有を行わなくとも共同開発を円滑に行うことが可能です。

*【参考】：[GitHub 用語集｜GitHub Docs](https://docs.github.com/ja/get-started/quickstart/github-glossary)*

GitHubでは何ができるのか、*バージョン管理面とソースコード管理面からGitHubの機能について解説します。*GitHubは開発プロジェクトやチームでのプログラミングでよく利用されますが、他にはWEBデザイナーやWEB制作のコーダーにも、テキストデータの管理などで活用されています。

プログラムのソースコードなど、**ファイルの変更や修正の履歴を管理することをバージョン管理といいます。**

これにより、過去のある時点の修正内容を確認したり、その時点の内容にソースコードを戻したりすることができます。GitHubにはこのバージョン管理機能があり、新バージョンで不具合が発生した際に、正常な過去のバージョンに戻したり、バグの追跡を行ったりすることができます。

### ソースコードの管理ができる

GitHubではソースコードの共有だけではなく、**ソースコードの管理が行え、開発プロジェクトを円滑かつ効率的に進めるのに役立ちます。**GitHubではプロジェクトの進行や課題の管理、ソースコードのレビューなど、プロジェクトやチームでの利用でより効果を得やすいという側面があるからです。

具体的にはソースコード上の問題点、バグの再現手順などに関するタイトルやコメントを記録して、チームメンバーに対する情報の周知徹底や課題に対する進捗管理が行えます。

ここでは、**GitHub Desttopのインストール方法について紹介します。**以下はWindowsユーザー向けですが、Macユーザーも同じページにある『Download for macOS』からダウンロードできます。

*1.* 下記リンクよりGitHub Desktopの公式サイトにアクセスし、トップページにある『Download for Windows（64bit）』をクリックすると「GitHub DesktopSetup-x64.exe」ファイルがダウンロードされます。

*2.* 「GitHub DesktopSetup-x64.exe」を実行するとセットアップが開始され「Welcome to GitHub Desktop」画面が表示されます。

*3.* GitHubのアカウントを持っていない方は、「Sign in to GitHub.com」をクリックして、下段の「New to GitHub？ Create an account.」からGitHubで使用するe-mail、パスワードとユーザー名を登録し二段階認証が済むとGitHub Desktopが使えるようになります。

（注意）：「GitHubdl」はPython向けのGitHubライブラリーであり、GitHubのダウンロードとは無関係です。GitHubから個々のファイルやディレクトリをダウンロードするためのツールとして利用するものですので、混同しないようにしましょう。

*【参考】：[GitHub Desktop](https://desktop.github.com/)*

ここまでGitHub Desktop 3.0のリリースと絡め、GitHubとは何か、GitHub Desktopによって何ができるのかなどについて解説してきました。**GitHub DesktopはプログラマやWebエンジニアのGithub初心者などにとって役立つツールです。**

GitHub Desktop 3.0では新機能が実装され、さらに便利なツールに進化しています。これまで利用していた方や、まだ使ったことがない方もぜひ1度試してみることをおすすめします。

GitHubが新たに発表したクライアントアプリケーション「GitHub Desktop 3.0」とは何か？GitHubやGitHub Desktopの概要をエンジニア初心者向けに易しく解説し、「GitHub Desktop 3.0」の特徴や機能について紹介します。

「GitHub Desktop」はコマンド操作不要で、GitHubを視覚的に操作ができるようにしたデスクトップツール

メジャーアップデートとなった「GitHubDesktop 3.0」は主にプルリクエスト機能の改善が行われている

「GitHubDesktop 3.0」により、開発プロジェクトのさらなる生産性や効率向上が期待できる

GitHub Desktop 3.0とは？メジャーアップデートで何が変わったのか、概要を解説！

## コードレビューの概要と目的

**コードレビューとは、作成したソースコードをレビューすることで、記述ミスやバグがないかを確認する作業のことです。**プログラムの品質を向上させるために、必要不可欠な工程といえます。ここでは、コードレビューの重要な観点を把握するために、まず概要や目的について詳しくご紹介します。

**コードレビューとは記述したソースコードに間違いがないかどうかを自分以外の誰かに確認してもらうことです。**レビューを行う側の人をレビュアー、レビューされる側の人をレビュイーといいます。レビュアーは複数いる場合もあります。

*システム開発の際にコードレビューはよく実施されます。*例えば、システムの品質を担保するために、「レビュアーの許可がない場合にはコードを修正することができない」というルールを作るプロジェクトもあります。プロジェクトの発足時に、レビューにかかる工数の見積もりやレビューのルールを決めることが大切です。

**コードレビューの大きな目的は、システム品質の向上です。**レビュアーに作成したコードに対して指摘してもらうことで、コードをより良い方向に修正することが可能です。例えば、人間がコードを記述する場合、ケアレスミスは発生します。そのため、*コードレビューを行うことで客観的にコードを見てもらえるため、ケアレスミスに気づきやすく、結果としてシステム品質の向上が期待できます。*

また、**コードレビューは新人教育のために実施されることも多いです。**新人社員の場合、実務経験が豊富な上司と比較するとコードの実装スキルがありません。そのため、ソースコードを読む作業を通じて、新人社員はコーディングについて多くのことを学ぶことができます。例えば、他人のコードを読むことによって「コードの設計」「コードの書き方」「フレームワークのスキル」などを勉強することが可能です。*コードレビューを通じて開発者の意図を学べるため、スキルアップにつながります。*

さらに、新人社員の場合はコードを丁寧に読むことが多く、実務経験が豊富な社員だとコードレビューを行うことに慣れていることが多いため、ケアレスミスを見逃してしまうこともあります。そのため、新人社員がコードレビューを行うことで小さなミスを拾えることもできるので、**新人教育も兼ねてコードレビューを行うことも多いです。**

**コードレビューの目的が理解できたら、次は方法が重要です。**コードレビューの方法はプロジェクトによって異なることも多く、ここでは一般的なコードレビューの方法について詳しく紹介します。ただし、例外もあるので注意してください。

### コメントの種類を使い分ける

**コードレビューをする際のコメントは、主にレビュイーが対応しやすいように記述します。**そのためには、行間のない短文で理解しやすいコメントが大切です。*コメントは、対応必須の「MUST」とレビュアーの意見「IMO（In My Opinion ）」の2つに分類すると分かりやすいです。*また、細かい指摘を行う項目など他の要素を使うこともあります。

### コメントの仕方に気を付ける

**コードレビューにおけるコメントは、コミュニケーションの一貫にもなります。**そのため、コミュニケーションがスムーズになるようなコメントの仕方も大切です。プロジェクトによっては文字のみだけではなく、絵文字や記号を使用することもあります。

また、*コードレビューでは相手の良い点を褒めることも大切です。*例えば、上司がレビュアーで新人社員がレビュイーの場合に、新人社員が成長した点をコメントしてあげると、新人社員のモチベーションアップにもつながります。

厳しい指摘ばかりしていると、レビュイーにとってコードレビュー自体が「辛い」「怖い」とネガティブなイメージになる原因になります。また*コメントをメンバーに共有することで、チーム全体の学びにもなるでしょう。*

**レビュアーがコードレビューの際にコメントを記載するときは、理由や根拠もきちんと記述しましょう。**コメントで「〇〇に修正してください」だけだと、レビュイーは「なぜ？」と疑問を抱いてしまうことがあるので、*根拠を示すことで新人社員の学びにもつながります。*インターネット上の信用できる参考文献を利用して、コメントをした理由を記述しましょう。

参考文献としておすすめの本は「リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック」です。イラスト付きで解説されているため分かりやすく、日本語の解説もついています。

【参考】：[O'Reilly Japan-リーダブルコード](https://www.oreilly.co.jp/books/9784873115658/)

### マージ後でも修正可能かを意識する

**マージを行った後でも、修正可能かどうかを意識することは大切です。**レビューの修正はマージを実施した後でも少ない工数で修正することができます。一方、データベースの変更は修正するための工数が大きくなるので、マージ後に修正が大変かどうかを意識してレビューを行うことも重要です。

**相手に伝わりやすくコードレビューを実施するには、いくつかコツがあります。**コードレビュー初心者の方は、まず基本的なコツをおさえておきましょう。ここでは、コードレビューをするときに意識すべき3つのコツについて説明します。

コードレビューを初めて行う人必見！やり方を1から解説！

### 口頭でのレビューも利用する

コメントのみでのレビューが難しいこともあります。その場合は**対面レビューの口頭でレビューを行うことがおすすめです。**ただし、指摘内容についてはコメントとして残しておいた方が、あとでエビデンスとして活用できます。また、プロジェクトメンバーに共有することもできるので、チーム全体の学びにもつながるでしょう。

### コードレビュー観点のチェックリストを用意する

**コードレビューをする際には、チェックリストの準備も大切です。**チェックリストを用意することで、*コードレビューする際の抜けや漏れを減らすことができます。*また、コードレビューをどのような観点で行うか、チームで認識合わせが可能です。

### 進捗に応じて確認するポイントを変える

**進捗状況によって、コードレビューをするポイントを変えることも重要です。**作業途中のコードを「WIP」として、プルリクエストを出す方法もあります。WIPとは、「work in progress」の略称で、進行中や作業中のことを指します。プルリクエストとは、コードの修正をレビュワーに通知して、マージを依頼することです。*WIPの場合は、変更の前提となるところを重点的に確認します。*

例えば、コードの設計や実装の方針について問題はないかを確認することが多いです。また、この段階では細かい部分の指摘は不要です。コーディングが完了した後に、細かい部分についてもレビューを行います。

## コードレビューで指摘が多いポイント

ここではコードレビューの際に指摘が入りやすいポイントについて説明します。間違いやすいところは重点的にチェックし、バグの防止やレビューの効率化を目指しましょう。下記で説明する項目について詳細なチェックリストを作成すると、精度の高いコードレビューができます。

**仕様のとおりに実装されているか、UIが適切か、エラーを正しく返すことができるかなどの基本的な機能部分をまずチェックしましょう。**簡単なコードでもケアレスミスがないとは言えません。機能に影響する部分はユーザーに直接見えるものが多いため、重点的にチェックしてください。

**不要なロジックが残っている、コピペミスがある、同一のロジックが複数入っているなどは必ず指摘しましょう。**コードの記載ミスは、製品がバージョンアップされたときや新たにアサインされたメンバーが加わる場合など、開発を再開する際にトラブルの元になります。複数のメンバーで開発ができるよう、コードは読みやすく書くことが大切です。

複数の端末で接続した際に処理速度が低下する、重い処理が含まれているといったパフォーマンスの低下の原因となる部分もチェックすべきポイントです。**具体的には指定されたデータ型が正しい、可能ならトランザクションを使用する、外部リソースへアクセスする場合は1回にまとめるなどの対策をしましょう。**

**コードレビューは、工数やコストが多くかかることも少なくありません。**近年ではIT人材の人手不足が深刻化していることもあり、納期などの問題からコードレビューができないことも多いです。品質を一定に保つためには、レビュー効率を上げる必要があります。ここからは、*レビュー作業の効率向上に用いられるコードレビューツールを2つご紹介します。*他にも多数のコードレビューツールが存在しているので、ぜひニーズに合うツールを探して利用しましょう。

主要なコードレビューツールを紹介！ツールがなぜ必要かについても解説

**GitHubには、プルリクエストの画面にコードレビューのツールがあります。**無料でも使用できますが、データ量やアクション数などに制限があるため、企業単位でツールを活用する場合には有料プランの選択がおすすめです。GitHubを利用することで、レポジトリへのアクセス権があるメンバーに対して、プルリクエストごとにレビュアーとして割り当てることができます。プルリクエストを行ったエンジニアは、管理者に対してコードレビューの依頼が可能です。

*コードレビューツールを活用すれば、Gitにおけるコンフリクトをインターフェース上で解決できます。*また、追加したレビューツールと統合させることもでき、レビュー機能を拡張することも可能です。そのため、GitHub付属のコードレビューのツールは、すでにGitHubを利用している場合には、追加のインストールや設定が不要なことから最適なツールと言えます。

【参考】[GitHub](https://github.co.jp/)

**Review Boardとは、オープンソースのコードレビューツールでコードとドキュメントのレビューができます。**また、コードの比較を画面でわかりやすく表示することもできます。さらに、Webサイト上で試験版を利用でき、ソフトウェアをインストールして自身のサーバーで設定することも可能です。

*Review Boardはオープンソースということもあり、バージョンは日々更新されているため、使いやすいツールに日々発展しています。*また、Review Boardは他のツールと比較して学習曲線が緩やかなことも特徴です。

【参考】[Review Board](https://www.reviewboard.org/)

## コードレビューはシステム開発において大切な工程の1つ！

これまでに、コードレビューの概要・注意点・コツ・指摘ポイント・ツールについて詳しく解説しました。コードレビューとは、記述したソースコードを他の方が問題ないか確認する作業のことです。**コードレビューの最大の目的はシステム品質の向上です。**また、新人社員の教育としてコードレビューを利用することもあります。

*コードレビューのやり方として、コメントの仕方が特に重要です。*コミュニケーションの一貫ともなるので、コメントで絵文字の活用や対面レビューもおすすめです。また、コメントではよかった点について積極的に褒めることも意識してください。近年ではコードレビューツールも多くあるので、コードレビューに割ける時間がない方はぜひニーズに合わせて活用してください。

コードレビューとは、記述したソースコードに問題がないかどうかを自分以外の誰かに確認してもらう作業を意味します。また、コードレビューの最大の目的はシステム品質の向上で、新人社員にも任されることが多いです。当記事では、コードレビューの重要な観点について詳しく解説します。

コードレビューとは、記述したソースコードを自分以外が問題ないか確認する作業のこと

コードレビューの最大の目的はシステム品質の向上である

コードレビューツールを利用することでレビューの効率の向上が期待できる

コードレビューの観点とは？やり方や便利なツールについても紹介！

まずはコードレビューの*基本的なやり方を解説*します。どういう手順で行うべきか、1から説明します。初めてコードレビューを行う方は、まずはこちらをお読みください。

コードを読む前に、まず**「システムの仕様を把握すること」が重要**です。どのような機能をもつシステムなのか仕様を把握しないと、コードのどこを指摘したらいいのか分からず、仕様通りに書かれていない箇所の指摘もできません。

また、*コードレビューに慣れていない場合、仕様を頭に入れていないとコードが読み解けないことも多い*です。新人のコードレビューをする場合は、新人が関わっている箇所の仕様書を読み込み、何を作ろうとしているのか全体像を確認しましょう。

### コードを一通り読んで確認する

仕様書を一通り理解したら、コードを一通り読んでいきます。書き方が良くなかったり、非効率な処理をしていたりする部分などがあれば*メモ*しておきましょう。

また、**コードを自分の開発環境でも実行し、エラーが出ないかもチェックします。**開発環境が変われば、エラーが発生するケースも多いためです。こういった地道が作業が、コードレビューでは必要です。

メモした内容を基に、問題点を*口頭・Github・チャットツールなどで指摘*します。また問題点を指摘する上で、参考にした資料などがあれば提示・添付すると良いでしょう。新人が問題点に関する質問をしてきたら、きちんと答えられるようにしておくことも重要です。レビューをする際は**同じミスを繰り返さないよう、相手に分かりやすく伝えることを意識しましょう。**

## コードレビューで見るべきポイント

ここでは、コードレビューで見るべき具体的なポイントを紹介します。特に*コード量が多い場合、最初から最後まで熟読するのは大変*です。見るべきポイントを抑えて、そこを重点的に確認すれば、*コードレビューの時間を短縮*できるでしょう。1つ1つのポイントを詳しく解説していきます。

### 自社のコードルールに則っているか

まずは、**自社のコードルールにしっかり則って書かれているコードか**確認しましょう。インデントやコメントの書き方など、それぞれの会社でルールが設けられているはずです。

他の会社でエンジニア経験がある方の場合、*自社のコードの書き方ではなく、前職での書き方をそのまま使っているケースも多い*です。そういった場合は、自社のコードルールに則っていない旨を指摘しなければなりません。レビュー時はコードが自社のルール通りなのか、確認してください。

### コメントが分かりやすく書かれているか

コメントが分かりやすく書かれていないと、*仕様変更を行う際や他の人に担当部分を引き継ぐ場合に苦労します。*エンジニアによっては、コメントを全く書かない人や、逆にコメントが多すぎる人もいます。*ソースだけでなく、コメントが上手く挿入されているか確認する*のが良いでしょう。

### バグを生み出しやすい部分がないか

コードレビューを行う主な目的は、「バグを潰す」であることがほとんどです。プログラマーを数年続けていると、どの部分がバグを生み出しやすいか感覚が掴めていると思います。その感覚を頼りに、*バグが出そうな部分を重点的にチェック*しましょう。

たとえば、if文がネストされている部分や無限ループが使われている部分、変数名が分かりにくい部分などはバグが出やすいです。また、**なるべぐバグを生み出しにくいコードを書くように指示する**ことも大切です。

### 仕様変更の際に修正箇所が多くならないか

コードレビューの際は、**今後の仕様変更のことも考えて行いましょう。**仕様変更が発生すると予想される箇所のコードは、修正部分が少なくなるよう記述するのが重要です。たとえば、*同じような処理を関数にまとめる*などが該当します。後に修正箇所が多くなりそうな部分も、コメントしてあげることが大切です。

*例外処理が入っていない場合が割と多い*ため、そこも重点的に確認しましょう。ユーザーが想定外の動作を行った場合に、プログラムがエラー文を出さないかチェックします。例外処理が入っていない場合は、**例外処理を書く必要があることの旨と、書き方の例をコメント**しておきましょう。

## コードレビューを効率化させる方法

コードレビューは、*あまり時間をかけすぎるのも良くありません。*時間をかけすぎて自分の業務に影響が出てしまうことがあります。そこで、コードレビューを効率化させる方法を解説します。レビューすべきコード量が多い場合などは、これらを意識してみてください。

### レビューの目的を明確にする

**レビューの目的を明確にすることは重要**です。たとえば「バグをなくす」「効率的なコードの書き方を教育する」など、目的はそれぞれ異なります。レビューの目的が決まれば、その部分のみに絞って効率的にチェックできるでしょう。

### 自動コードレビューサービスを使う

「自動コードレビューサービス」というものもあります。コードを入力すると、**ツールがコードを自動解析してくれ、問題点をコメント**してくれます。たとえば、「Sider」は日本初の自動コードレビューサービスとして有名です。また、解析ルールをカスタマイズし、自社仕様にすることもできます。

もちろん、*こういったサービスに頼り切るのは良くありませんが、要所で活用することでレビュー時間を短縮できるでしょう。*「Sider」以外にも「Codacy」や「Hound」などいくつか種類はあるので、試しに使ってみてください。

レビューする箇所が多すぎる場合は、*役割分担を行うことも検討*しましょう。たとえば「コードが仕様書通りか確認する人」と「コードの書き方が規約に則っているか確認する人」に分けるなどです。

**役割分担することでピンポイントで確認でき、レビューの質も上がる**でしょう。役割分担に関しては、上司に相談してみるのが良いです。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

コードレビューする際の注意点も解説していきます。これらの注意点も意識しないと、新人との関係を悪くしたり、レビューの質低下に繋がったりします。*ある程度コードレビューを行ってきた人も、注意点を守れていないことが多い*です。どういった点に気をつけるべきか、1つ1つ解説していきます。

コードの悪いところを否定しても、*その人自身は否定してはいけません*。「なぜこんなこともできないのか」と、高圧的な態度を取るのも止めましょう。新人との関係を悪くしたり、相手がコードレビューを嫌いになることに繋がったりします。

悪い箇所を指摘する際は、**淡々と事実のみを話し、自分の感情を介入させないようにしてください。**また、絵文字などを使って柔らかい雰囲気を出すのもコツです。柔軟な対応を見せることで、レビュイーが新人でも萎縮することなく疑問点を質問してくれるようになるでしょう。あくまで「レビューするのは相手に対してではなく、コードであること」を意識するのが重要です。

### なぜこうすべきか根拠を話す

悪い部分を指摘する際はなぜこのような書き方をすべきか、*根拠を話すことも重要*です。たとえば「コード規約に書かれているから」という説明では、相手は納得できません。

コード規約に則るとどんなメリットがあるか、分かりやすく話すことが重要です。そうすることで初めて相手は納得し、改善もしやすくなります。

また、**レビューする際に参考にした本などがある場合は、それを見せるのも効果的**です。「なぜそうなのか」をきちんと説明することは、コードレビューをやる側の理解度アップにも繋がります。

コードレビューをする際は、*具体的な修正案も示してあげましょう*。その方が相手がどのように変更すべきか分かりやすくなります。また、**言葉ではなかなか伝わりにくい部分も理解させることが可能**です。もちろん、具体的な修正案を示すのは時間もかかるため、できる範囲で行いましょう。

悪い部分を指摘するだけでなく、*良い部分があれば褒めるようにしましょう。*コードレビューを行う上で大切なのは、**やる側とやってもらう側の信頼関係**です。悪い部分ばかり指摘するのは、信頼関係を築く上で好ましいことではありません。

また、良い部分を褒めることで、エンジニアとしての自信がつき、レビュイーの成長速度を早めることにも繋がります。良い部分や「なるほど」と思う部分も必ずあると思うので、コメントしてあげるようにしましょう。

書き手の意図が分からない部分は、*「なぜこういう書き方をしているのか」直接本人に質問*しましょう。質問することで、レビュアーの読解力が不足しているのか、コードの書き方に問題があるのかが分かります。

また、レビュイーの説明力や理解力をアップさせることにも繋がるでしょう。ただし、**問い詰めるような言い方はせず、穏やかな雰囲気を意識して対応することが重要**です。

## コードレビューはやる側もエンジニアとしての成長に繋がる

本記事では、コードレビューのやり方について解説しました。どういった手順でコードレビューを行うべきか、お分かり頂けたかと思います。

コードレビューはやってもらう側だけでなく、やる側もエンジニアとしての成長に繋がります。コードレビューを行うことで、読みやすいコードはどういった物なのか分かってくるため、*自分のコードを確認する上でも役立つ*でしょう。

ただし、時間をかけすぎると自分の業務に支障が出るため、**効率的にレビューを行うことも重要**です。コードレビューを頼まれた場合は、本記事で解説したことを意識して行ってみてください。

リモートで働くエンジニアの実態やメリット、デメリットについて紹介

本記事ではコードレビューのやり方を解説します。エンジニア2、3年目になると新人のコードをチェックする機会もあるでしょう。そこで、コードレビューで見るべきポイントや、効率的に行う方法を解説します。コードレビューをする予定のある方はぜひご覧ください。

コードレビューを行う際は見るべきポイントを抑える

コードレビューは時間をかけすぎるのも良くないため、効率的に行うことを意識する

コードレビューはやる側もエンジニアとしての成長に繋がる

## 主要なコードレビューツール

コードレビューはシステム開発の中で大切な工程の1つです。コードレビューを1行ずつ目で確かめていたら、工数が膨大になってしまうでしょう。近年では、工数の削減や正確性の担保などのためにさまざまなコードレビューツールがあります。ここでは、代表的なコードレビューツールを詳しく紹介します。

**GitHubとは、システム開発プロジェクトのためのソースコード管理サービスです。**ソースコードを更新したバージョンの管理機能・バグ追跡機能・SNSの機能が備わっているため、開発者にとっては必要不可欠とも言えるサービスです。**そしてGitHubには、プルリクエストの画面にコードレビューツールが備わっています。**無料でも利用できますが、データ量や月々に実施できるアクション数に制限があるため、チームやプロジェクト単位で使用する際には有償版を使用するのがおすすめです。

*GitHubでは、プルリクエストごとにレポジトリへのアクセス権をもっているユーザーをレビュアーとして割り当てることが可能です。*プルリクエストを提出したユーザーは、管理者にコードレビュー依頼もできます。変更履歴の確認やプルリクエストの議論、インラインでコメントを付けることも可能です。GitHubのコードレビューツールでは、Gitにおけるコンフリクトをインターフェイス上で解決することもできます。

また、マーケットプレイスを利用して、他のレビューツールと統合させれば、レビュー機能を拡張させることも可能です。*GitHubに備わっているコードレビューツールには、レビューに必要な機能が全て組み込まれているため、追加でダウンロードやパラメータの設定などは不要です。*
（参考：https://github.com/ ）

**Collaboratorは、SmartBear社が開発したコードレビューツールです。**Collaboratorではソースコードのレビューだけではなく、ドキュメントのレビューもできます。Collaboratorは有償ですが、無料試用版も用意されています。

*Collaboratorでは、他のコードレビューツールと同様に、Git・Subversion・Perforce・CVS・Mercurial・TFSなど、多数のバージョン管理システムをサポートしているのが特徴です。また、Jiraなどのプロジェクト管理ツールやEclipse・Visual Studioなどの統合開発環境（IDE）とのシステム連携することもできます。*Collaboratorには、レビュー管理とバグ追跡の機能もあり、プロジェクトメンバーを支援する機能も豊富です。他にも、ソースコードの修正・変更を確認し、欠陥を特定して特定の行にコメントを付ける機能もあります。
（参考：https://smartbear.com/product/collaborator/overview/ ）

**Review Boardは、Christian Hammond氏とDavid Trowbridge氏によって開発されたオープンソースのコードレビューツールです。オープンソースなため、開発者によって日々バージョンが更新されているのが特徴です。**Review Boardでは、ソースコードとドキュメントの両方のレビューを行うことができるほか、ソースコードをグラフィカルに表示することもできるため、ソースコードを更新した際の差異を比較するのが簡単です。Webサイトで試用版を利用することもできるため、1度試してみてから、プロジェクトなどに活用するかどうか検討も可能です。また、システムをダウンロードし、自身のPCにインストールしてセットアップすることもできます。

Review Boardを使用するためには、Pythonの実行環境が必要です。また、MySQLなどのデータベースの用意・ApacheなどのWebサーバーの設定・ソフトウェアを実行するためのライブラリなども必要です。Review Boardは、Git・Mercurial・CVS・Subversionなど多くのバージョン管理システムと統合することができます。また、Review BoardをAmazon S3に統合して、Review Boardの中でスクリーンショットの保存も可能です。
（参考：https://www.reviewboard.org/downloads/ ）

**Phabricatorは、Phacillity社が提供しているオープンソースのコードレビューツールです。**Phabricatorをダウンロードし､自身のPCにインストールするのは無料で行うことができます。また、ユーザー数も限定することなく使用でき、有償版ではクラウド上のサービスを使用することもできます。有料プランの場合、サポートも含まれているのが特徴です。Phabricatorは、Git・Mercurial・SVNの3種類のバージョン管理システムが対応しています。

例えば、プロジェクトのチームメンバーと事細やかに議論したい場合には、Phabricatorを利用すれば可能です。プレコミット・ポストコミットの両方のソースコードレビューができます。また、Phabricatorには、システム開発においてプロジェクトをサポートするための追加ツールが備わっています。例えば、バグを管理するビルトイントラッカーが提供されています。

*以上からも、Phabricatorには、開発効率を向上させるための機能はほとんど備わっているのが特徴です。プロジェクトが初期段階にある場合には、Phabricatorはおすすめと言えます。*
（参考：https://secure.phabricator.com/ ）

## コードレビューツールが必要な理由

コードレビューツールを使用する理由について気になる方は多いでしょう。最初に説明しましたが、**開発効率の向上やコストの削減が主な理由**として挙げられます。コードレビューツールを使用することで、他にも多くのメリットがあります。

*例えば、コードレビューツールを使用すれば、プロジェクトチームが継続的にコードレビューを確実に行えるようにサポートすることができます。*全てのコードレビューについて一元管理ができたり、問題の追跡や解決がわかりやすいように可視化したりすることが可能です。

*コードレビューツールによって、プロジェクトメンバーや関係者の間のコミュニケーションもサポートすることができます。*コードレビューツールを利用すれば、関係者間の認識齟齬を減らすことや、プロジェクトメンバーが議論しやすいプラットフォームを提供することができるため、無駄な工数を大幅に削減が可能です。

*また、コードレビューツールには、バグ・エラーの履歴を保存したり表示したりする機能もあります。*したがって、ナレッジの文書化・共有が簡単にできるようになります。コードレビューで文書化された履歴は、新しいプロジェクトの際に活かすこともできるため、大切なリソースです。 

そもそも、コードレビューについて詳しく知らない方も少なくないでしょう。**コードレビューの概要や目的を知っておくことは、コードレビューツールを採用する際にも役立ちます。**コードレビューとは、記述したソースコードをレビューすることで、エラー・バグがないかを確認する作業のことです。プログラムの品質を担保するためにも重要な工程の1つと言えます。ここでは、コードレビューの概要や目的について詳しく紹介します。

**コードレビューは、記述したソースコードを自分以外の誰かに問題ないか確認してもらうことを指します。レビューを行う人をレビュアー、レビューされる人をレビュイーと言います。**システム開発を実施する際に、コードレビューは必ずといてもいいほど実施されるでしょう。例えば、プロジェクトによってはレビュアーの許可がない限り、ソースコードを修正することができなかったり、次の工程に移ることができなかったりします。*コードレビューのルールは、プロジェクト発足当初に定めるのが一般的です。*

コードレビューの目的はいくつかあります。**主な目的は、ソースコードにエラーや設計上の問題がないか確認することです。つまり、システムの品質を担保することが大きな目的と言えます。**コードレビューの方法もさまざまですが、自身が記載したソースコードを上司や他のプロジェクトメンバーが確認することが一般的でしょう。

**その他の目的として、上司のソースコードを見て勉強するというように、新人教育にコードレビューが使われることもあります。**他人が記述したソースコードを読むことで、コーディング方法やフレームワークのスキルを身に付けることが可能です。*コードレビューによって、開発者の意図も把握できる良い機会となるため、スキルアップにもつながります。*

## コードレビューについて理解を深めてプロジェクトに適したコードレビューツールを導入しよう！

これまでに、主要なコードレビューツール・コードレビューツールが必要な理由・コードレビューの概要や目的について解説しました。**主要なコードレビューツールとして、「GitHub」「Collaborator」「Review Board」「Phabricator」などが挙げられます。他にも多種多様なコードレビューツールは存在するため、プロジェクトに合ったコードレビューツールを導入することが重要です。**

*コードレビューツールを導入する主な目的は、開発効率の向上です。また、そもそもコードレビューを実施する主な目的は、システムの品質担保です。*システムの品質を担保しようとして、レビューに工数を多くかけてしまうことは少なくありません。**そのため、開発スピードを高めるためにも、コードレビューツールを使用してみるのはおすすめと言えます。**

近年ではシステム開発の効率を高めるために、コードレビューツールはさまざまなものが存在します。そこで当記事では、主要なコードレビューツール・コードレビューツールが必要な理由・コードレビューの概要や目的について詳しく解説します。

主要なコードレビューツールは「GitHub」「Collaborator」「Review Board」「Phabricator」など

コードレビューツールを導入する主な目的は、開発効率の向上

コードレビューを実施する主な目的は、システムの品質担保

コードレビューの記事（1ページ目）