初級者にとっては“補助輪”、中・上級者にとっては“ブースター”　自作ライブラリ開発のハードルをグッと下げてくれる「GitHub Copilot」の使い方

タイミー社・バックエンドエンジニアの新谷氏

新谷哲平氏：では「GitHub Copilotを使って自作ライブラリを作ってみよう」という題でタイミーの新谷が発表させていただきます。よろしくお願いします。

簡単に自己紹介をさせてください。タイミーでバックエンドエンジニアをしています。書くことがなかったので、好きなものはカレーと書いてみたんですが、自分が好きなカレーはジャワカレーです。みなさん、おすすめのカレールーがあれば今回のハッシュタグを使ってポストをして教えてください。よろしくお願いします。

簡単に、タイミーの紹介をさせてください。タイミーとは、働きたい時間と働いてほしい時間をマッチングするスキマバイトサービスです。

ただいまとても伸びていて、YoYで4.7倍に成長しています。これってすごい数字なんじゃないかなと思っています。また、エンジニアも例に違わず足りておらず、エンジニア採用をやっています。

タイミーでは、「GitHub Copilot for Business」、業務で使える枠が余っているので、業務で「GitHub Copilot」を使いたいよという方は、まずはカジュアル面談からよろしくお願いします。

発表の目的とアジェンダ

というのは前置きとして、さっそく入っていこうかなと思っています。

まず簡単に、「こんな人向けの発表です」というところから。今回の発表は、「GitHub Copilot、最近よく聞くけれど結局まだあまり使ったことがないんだよね」という方が、「いや、これ便利じゃん。ちょっと触ってみようかな」になるところを目指したいと思っています。

GitHub Copilotをもう使いこなしているよという方は、「わかる〜」みたいなツイートをしたり、これからデモをするので、デモの応援などをよろしくお願いします。

目次について説明をします。まずは、なんで自作ライブラリなのかというところ。次に、実際にデモを交えて紹介して、やってみてどうだったかを簡単に自分なりにまとめたいなと思っています。

なぜ自作ライブラリを作るのか？

まず、「なぜ自作ライブラリなのか」ですが、今回は対比として業務アプリケーションを持ってきました。業務アプリケーションが固有のドメインロジックを持つというのは、当たり前ですよね。

プラス、業務アプリケーションのコードが丸々公開されていることはあまりないと思うんですね。バックエンドならたまに公開されていることもありますが、iOS、Androidとかだと、もう本当にないんじゃないかなと思っています。

対して自作ライブラリというと、固有のドメインロジックが少ない。しかも、優秀なライブラリのオープンソースはたくさん公開されている、データセットが多くて、こっちのほうが補完の性能が高いのではないかと思っているので、自分はライブラリの作成をおすすめしたいなと思っています。

とはいえ、これは相対的な話かなと思っていて、自分も業務の開発でGitHub Copilotは使っていて、生産性の向上を感じているので、業務においてGitHub Copilotが有用ではないよ、という話ではないことはご認識ください。

valid?メソッドを実装する

では、「実際に実装してみる」というところに入っていこうかなと思っています。今回は、デモを交えながら紹介していきます。こちらのソースコードは、後で「Twitter（現X）」にも流すので大丈夫です。

まず、簡単に前提についてお話をします。今回はRubyのコードなのですが、なるべくRubyの知識がなくても大丈夫なように解説をしていこうと思っています。

今回は、my_active_model gem、ライブラリを作成中だとしましょう。今、実装できているのはここまでです。attribute :nameと書くと、対応したコンストラクタと、getterやsetterが定義されます。

今回はこれに対して、valid?メソッドというのを実装してみたいと思っています。どういう変更があったかというと、attributeに対して、第2引数にstringやintegerというものが増えているのと、valid?メソッドですね、これが増えているというかたちになっています。

デモ

では、デモに移りたいと思います。今見えているのがサンプルコードの、テストコードのようなものだと思ってください。

Userクラスがあって、name、ageがあります。（スライドを示して）ここのコメントアウトしているところをこれから実装していきたいと思います。

まず、今の状態で動きそうですかね。今の状態でnameがteppeiでageが26というので、いいかなと思っています。

では、このテストコードを書いていきましょう。さっそくCopilot君が、「stringなんじゃない？」と言っていたり、ageで「integerなんじゃない？」と教えてくれました（笑）。早いですね。attributeで引数が足りないのでダメって怒られています。

では実装をしていこうと思います。まずは、attributeの引数にtypeを追加します。attributesの情報を保存したいので、ハッシュを持たせて……賢すぎるな、ちょっと。

（会場笑）

もしかすると、キャッシュが残っているかもしれませんが（笑）、やりたいことがそのまま提案されてしまって困っているんですが、保存した情報を基にattributesメソッドを生やしたいなと思っていて、インスタンス変数のattributesが返るようになっています。

これで、少なくともこちらの上のattributeメソッドのエラーはなくなったんじゃないかなと思っています。valid?メソッドがNoMethodErrorと言われていますね。

では、次ですが、valid?……キャッシュが残っているのかな？　なんか賢すぎるんですが。

（会場笑）

いったん置いておきます。デモの練習をしていてちょっと気づいたんですが、valid?を先に実装しようとするよりも、valid_type?というメソッドを定義したほうが賢いことに気づいたんですよね。

これを補完してもらおうと思います。何を提案してくれたんだ？　typeに、ここに、シンボルではなくクラスが入ってくるぞ、というのを実装しているんですかね。そうではないので、case……なんか出てきていますね。これ、ちょっと待ってくださいね。値と型を渡すほうが、メソッドとしてはすっきりしてそうな気がする。これでどうなるんだろう？　補完を採用してみましょう。

これで、stringが渡されたら、Stringクラスのインスタンスかどうか、integerが渡されたらIntegerかどうかをチェックしてくれるようになったかなと思っています。

これを基に、valid?を実装してくれるんじゃないかなという見立てでいかがでしょうか。補完をそのまま採用してみました。

attributesから全フィールドに対して値を取得して、validかどうか、validでないものが1つでもあればfalseを返して、全部スルーすればtrueが返る。正しそうな実装に見えます。

では、これを実行してみましょう。すると、user.valid?がtrueが返ってきていることがわかります。

では、試しにageをstringにしてみましょう。そうすると、きちんとvalid?がfalseになっているので、引数による型の検証がうまく動いているんじゃないかなと思っています。

これで、valid?メソッドはいったん実装は完了です。1度、スライドに戻ります。

to_hメソッドを実装する

次に、to_hメソッドを実装したいと思います。こちらは、連想配列ですね。連想配列の値に対して、フィールドの情報が全部入った連想配列を返したいとします。

では、これも実装していきます。to_h……もう補完してくれているんですよね。賢すぎる気がするんだよな。こちらを採用しましょう。

まず、attributesの全フィールドに対して、each_with_object。これはほかの言語でreduceのような関数になっています。引数に渡したもの、空のハッシュにどんどん値を代入していくというメソッドなので、これでいけるんじゃないですか？

はい、実行します。to_hで、nameにteppei、ageが16というかたちで、何も実装していないんですが、きちんとメソッドが定義されたことが確認できると思っています。

to_jsonメソッドを実装する

最後に、to_jsonメソッドを実装しようと思います。こちらは、先ほどと形は似ているんですが、JSONの文字列ですね、文字列を実装してみましょう。

では、さっそく、to_json……おっ、出ましたね。to_hメソッドを利用して、「Hashクラスのインスタンスにto_jsonメソッドが入っているだろうから、それを使ったらいいんじゃない？」。賢い。

では、実行してみましょう。

ごめんなさい、コメントアウトを外していませんでした。実行すると、あら、エラーになりましたね。（スライドを示して）これが、NoMethodErrorと言っている。

これは知っていて、Rubyでは、jsonライブラリをrequire、インポートしないと、Hashにto_jsonメソッドが生えてこないんですよね。これでto_jsonメソッドも実装できたんじゃないかなと思います。

というふうに、ちょっと今回は賢すぎたかもしれませんが、何も書かなくても自作ライブラリの一機能が実装できるというのがわかったかなと思っています。

「GitHub Copilot」の活用で自作ライブラリ作成のハードルはグッと下がる

最後に、やってみてどう感じたかというところです。

一言で言うと、自作ライブラリ作成のハードルがグッと下がったんじゃないかなと感じました。

1つ目としては、「飽きる前に最低限仕上げられる」。これが個人的にはかなり大きいと思っています。

自分の実体験として、「あっ、いいアイデア思いついた、やってみよう」と思って作り始めはするんですが、飽きて完成しないんですよね。

なので、開発生産性でいうと、生まれていないのでゼロだと思っているんですよ。ただ、今回のGitHub Copilotを使えば、飽きる前に最低限の実装を仕上げられる。最低限の実装さえ仕上げられれば、「ちょっと改善するか」という気持ちになって続けられるので、アウトプットがなかったものが、1が生まれるので、生産性は無限大なんじゃないかなと自分は思っています。

また、学習教材としてもいいなと思っています。先ほどのeach_with_objectメソッドとか、ふだん使わないメソッドの使いどころとかを知れたり、ライブラリ特有の抽象的なコード、今回のデモではあまり紹介できなかったんですが、そういったコードも提案してくれるので、勉強にもなるんじゃないかなと思っています。

ということで、初級者にとっては開発の補助輪として、中級者、上級者にとっては開発のブースターとして、GitHub Copilotを、一家に一台いかがでしょうか？　ということで終わらせていただきます。ご清聴ありがとうございました。

（会場拍手）