はじめに
この記事は、オフショア開発中で発生する問題点を解決する1つのツールとしてGitHub Copilotが使用できるのではないか？というところからスタートしました。
問題解決に向け様々なツールを試している中の１つで、まだ新しい機能だったこともあり記事にさせていただきました。
使いこなせていない部分があったり、最新のバージョンでは機能アップしている可能性もありますが、参考にしていただければ幸いです。
現状の課題・改善したい点
現在オフショア開発を行っており、その中で品質の確保を行うためにソースコードのレビューを実施するようになりました。
オフショア開発ではコミュニケーションギャップ・開発体制の差など様々な問題点があります。それぞれの問題がどういうことなのか簡単に解説します。
①コミュニケーションギャップ
これは簡単に言うと言語の壁ですが、単純にそれだけではない側面があります。
例としてコードレビューは以下のような流れで行っています。
※不具合対応時の例
コードレビューの実施についてはGitHubやコードエディタ上で行うことも可能ですが、仕様をどのように理解しコーディングしているか、テストケースをどのように考えているかを確認するためにこの形式をとっています。
このようなコードレビューを行っていると２つの大きな問題点が挙がってきます。
- 情報伝達に時間がかかる
- 翻訳者が入ることで時間がとられてしまう。やり取りの回数が増えてしまう。
- やりとりの中で情報が欠落する
- やり取りの回数が増えることで情報が欠落する。
- 翻訳者が技術者ではない（技術力が低い）ケースが多く十分に情報が伝達されない。
②開発体制の差
オフショア開発の体制は、発注側の体制に対しオフショア側の人数が多いケースがほとんどです。
このような体制下の場合、コードレビュー対象のソースコードが多くなるため、レビューする側のリソース不足が問題になります。
③その他細かい問題
さらに細かい問題点としては以下のようなものが挙げられます。
- ソースコードのコメント問題
- ソースコード内のコメントの言語がオフショア先の言語になる。
- オフショア先が複数あると様々な言語のコメントがつく。
- そもそもコメントがない。
- 品質に関する問題
- 独特なロジックだったり、メンテナンス性が悪い。
- 末端の技術者は経験が少ない人も多くコーディングのレベルにばらつきがある。
このような課題をどうにか解決できないか？ということで、
コードレビュー時にGitHub Copilotを検証することになりました。
GitHub Copilotをレビュー機能としてつかってみた
そもそもGitHub Copilotって？
公式のサイトにはこちらの記載があります。
「GitHub Copilot は AI コーディング アシスタントであり、コードをより速く楽に記述できるため、問題解決とコラボレーションにより多くのエネルギーを集中できます。」
説明を見る限り、基本的にはAIによるコーディングのアシスタント機能であるとなっています。コーディングの補助以外にも、GitHub上でのチャットによるコードレビューも行えるようです。
詳細な機能や価格についてはGitHubの公式サイトに「GitHub Copilot とは何ですか?」という記事がありますのでこちらを参照してください。
＜公式サイト＞
https://docs.github.com/ja/copilot/about-github-copilot/what-is-github-copilot
検証する機能・前提
ソースコードの管理はGitHubで行っています。
今回コードレビューの支援として使用する機能は、GitHub Copilotの GitHub Copilot Chatによるコードレビューを行い、現状の課題に対してどこまで効果があるのかを検証していきます。
※ソースコードについては場所によりトリミング、モザイク処理を行っています。
簡単な修正のケースで使用感を確認
GitHub上にあるレビュー対象のPullRequestを表示します。
PullRequest画面の【Files Changed】tabを選択後、下の参考画像の矢印がついているボタンを押すと【GitHub Copilot Chat】のWindowが表示されます。
ファイル指定でChat機能を使用する場合には、対象ファイルの【･･･】ボタンからChat Windowを開きます。ファイルを個別に指定しない場合には画面下部のアイコンをクリックします。
今回はファイル指定ではなく、画面右下のアイコンをクリックしてChat Windowを表示します。これでコードレビューの準備ができました。
GitHubのPullRequestの画面上で操作できるので使いやすいですね。
コードレビューの実施
試しに今回のPullRequestに関してレビューしてもらうことにします。入力するワードは、
今回の修正についてレビューしてください。日本語で
最後に「日本語で」を入れない場合、英語でレビュー結果が返ってくるので言語指定をしています。一度日本語でレビューされるとその後は日本語になるようです。
ワードを入力後、１０秒かからないくらいでこちらの画面が表示されました。
表示は１行１行徐々に描画される動きです。
修正ファイルが３ファイルで修正箇所も多くない為か、待たされる感じはありません。
修正内容は「金額を入力する際のチェック条件を変更する」修正を行いました。
コメントの内容を見てみます。
- ３ファイル共に金額チェックの条件が修正されているとの解説が入っています
- 条件に使用されている変数が、金額に関する変数であるとソースコード内のコメントから読み取っているようで、解説の中で「金額や税額に関するチェック条件の追加」と解説されています
- ３ファイル目に関してはソースコードの描画が省略されており、「２ファイル目と同様に金額チェックの条件を修正しました。」と解説されています
変数、条件分岐などで正確にコメントを入れると、Copilotのレビュー精度も上がるようです。また、全く同一の修正が行われている場合には解説を割愛する動きもするようです。
あとは、PullRequest時につけられたコメントを元に、どういった修正が行われているかのまとめが表示されています。
この程度の内容であれば解説はいらないとなるかもしれませんが、
「レビュー者は修正されたソースコードを初めてみる」、「他者が作成したソースコードは確認しづらい」という点からも、ソースコードを見なくても大まかな修正内容の概要や、修正された箇所が表示されるのはよいのではと思いました。
課題の検証
もともと挙がっていた課題としては、要約すると以下のような問題がありました。
- やり取りに時間がかかる
- やり取りの中で情報が欠落する
- コメント
- 特殊なロジック
このようなケースを検証するため、
次は少し特殊なケースの修正に対してコードレビューをかけたいと思います。
修正内容はこちらの内容です
マスタデータを取得する非同期処理を実行した後に後続の処理を行うように変更する
元々の処理の場合、非同期処理により処理の順番が前後するような問題が発生したため、今回の修正を行いました。
早速修正後のソースコードに対し、Copilot Chat機能でコードレビューしてもらいます。
結果はこちらです。
変更点の概要を見ると、
非同期処理が完了した後に既存の処理を続行するように変更と、こちらの意図していた概要が記載されています。
このような非同期処理による処理の順番が前後してしまうような特殊な処理の場合、翻訳時に意味が伝わりにくかったり、翻訳者が意味を十分理解できないこともあり、このレベルの解説がレビューの最初に出ると時間短縮にもつながり非常に助かります。
また、今回のソースコードはコメントがついていませんが、コメントがついていない場合でも技術者が見れば意味の分かる解説になっています。
更に概要以降のコードレビュー内容を確認してみます。
先ほどの画像ではレビュー内容がすべて表示しきれなかったので、こちらに後続の内容を添付します。
【評価と提案】という項目が続き、
今回のソースコードの修正に対する評価と改善点が提案されています。
ここではエラーハンドリング追加の提案や、コードの可読性に対してのアプローチ例が細かく提案されています。
現状の課題としてソースコードが独特なロジックになっている、メンテナンス性が悪いという問題点もあり、その部分についても今回のケースではレビューしてくれています。
ソースコードのリファクタリングについては開発時にコードエディタ上のCopilot機能で対応できますが、コードレビュー時にもGitHubのPullRequest上で最終判断ができるのは便利かもしれません。
複数ファイルのソースコードが修正されたケース
開発規模が大きくなると、１回のプルリクエストで複数のファイルが修正されてくることがあります。そういった運用にも耐えられるのか確認してみました。
今回は27ファイルが修正されたPullRequestに対して一括コードレビューをかけてみます。
最初に【変更されたファイルとその内容】が羅列されました。すべてが表示されるまで20秒程度の時間でした。
内容はまさに概要説明といった感じの内容ですね。
先ほどの課題の検証で行った単独ファイルのコードレビューとは明らかに粒度が違います。
その後、次の画像のように10件ほど概要が表示された後、【プルリクエストの詳細】と【コメント】が続きました。
【プルリクエストの詳細】には変更ファイル数や追加行数などが表示されていますが、その数の割にはレビューの内容がざっくりしています。
ちなみに、【プルリクエストの詳細はこちら】のリンクを押してもGitHubのPullRequestの画面に戻るだけでした。
ファイル数が多い場合には、ファイル個別でコードレビューしたほうが良いかもしれません。
まとめ
簡単な内容ではありましたが、ここまでGitHub CopilotのChat機能をレビューで使ってみての感想をまとめます。
GitHub Copilot 良いと感じた点
- 思った以上にちゃんと修正内容の概要を説明してくれる
- ソースコードを細かく知らなくても修正概要が簡単にわかり、レビューのとっかかりになる
- レビューのパフォーマンスが割といい
- コードエディタ上での修正提案のようなものもやってくれる
- 既にGitHubを運用しているのであれば導入が楽
良かった点は、PullRequestに対する修正内容のレビュー結果をすぐに出してくれるところです。ファイル指定でコードレビューを行った場合は解説の精度も良く、オフショア開発のような修正対象のソースコードを開発時に見ていないケースでは、レビューのとっかかりとしては良いのかなと感じました。
GitHub Copilot 懸念点
1. 運用コストがかかる
2. あくまで補助機能であり万能ではない
3. 大量の修正ファイルがある場合にはサマリされるため個別のレビューが必要
4. ソースコードを十分理解している場合は効果が薄いかも
5. 他ファイルへの影響範囲調査が若干弱い
1と2についてはこのようなツールを使用するうえでは必ず発生する問題ですね。
Copilotを使ってレビューしても最終的には自分で判断することは重要です。
3については記事の中で紹介したように一括レビューにはあまり向かないと感じました。
一括レビューとならないようにコードレビューの運用をうまく考える必要がありそうです。
4は、自身が開発中のソースコードの全体を把握しており、他の人のソースコードをパッと見るだけでも何を修正しているかわかるような状況なのであればコードレビュー機能を使用する必要はないと思います。
例えば大規模な開発で複数のチームが関わっているような環境であれば、１つ１つの開発をソースコードレベルまで把握することは難しいのでそういったケースでは有用と思います。
5については記事では挙げませんでしたが、
コードレビューの際に「他のソースコードへの影響範囲は？」のようなワードで確認したところ、具体的な影響個所ではなく、「こういうケースでは影響があるかも」、「修正対象のメソッド・変数を使用している個所は確認が必要です」のようなふんわりとした回答になっていたので、影響範囲の調査目的で使うにはパワーが足りないと感じました。
さいごに
私が行っているようなオフショア開発の場合は、うまく活用することで課題を解決できる可能性はあるのかなと、今回の検証で感じました。
またコードレビュー機能を調べていく中で、DeepSeek-Coderなど違う製品についても触れる機会もでき、そういった製品についても今後検証できればと考えています。
記事が長くなってしまいましたが、ここまで読んでいただきありがとうございました。
皆様の業務に少しでもお役に立てば幸いです。