はじめまして！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です。
9月7日にBASE主催で「BASE Engineer 座談会 〜BASEの若手エンジニアがそれぞれの今と未来を語る！〜」というイベントを実施したのですが、その中のLTパートで発表した「Changelogを読んで自分のエンジニアキャリアを作る」でお話しきれなかった部分があったので、そこも含めてお話した内容を記事にまとめなおしました！
当日ご参加いただいてLTを聞かれた方も、そうでない方も、ぜひご覧ください！
「Changelog」と「エンジニアキャリア」がどう繋がるのか
早速この記事でお伝えしたいことから書いてしまうのですが、 Changelogは最新機能だけでなく、未来のビジョンも含めたプロダクトの情報の宝庫で、それらをうまく使えばエンジニアキャリアづくりに活かせる！ ということを記事を読んでいただいた皆さまには持って帰っていただければなと思っております。
ここからは、私がどういう経緯でChangelogを読むようになったか、Changelogを読むことでどんなメリットがあるのかについて、具体的に紹介していきます。
なぜChangelogを読み始めたのか
ことの始まりはdependabotくんの対応から
BASEにはショップオーナー向け管理画面で利用する社内用コンポーネントライブラリ「BBQ」があります。 今年2月頭頃、そのリポジトリに dependabot という、依存しているライブラリのバージョンアップ情報を調べ、アップデートするPull Requestを自動的に作成してくれるシステムを導入したところから話は始まります。
私は今年1月に入社したのですが、オンボーディング研修やたくさんのオリエンテーション、BASE内のコードリーディングを行っていた1ヶ月がちょうど過ぎた頃に、上記のような話題が上がり、実際に導入されることになりました。
ちょうどBBQのコードを読むきっかけにもなりそうと思って、空いた時間で参加させてもらうことになりました。
実際の dependabot の対応自体は難しいものではなく、自動的にOpenされるPull Requestを確認し、必要に応じて動作確認を行うだけです。
- dependabot が設定した頻度で
package.json/yarn.lock（Node.js関係のライブラリの依存関係情報が載っているファイル）をチェックする - アップデートが公開されているライブラリがあった場合に、そのライブラリのバージョンを変更した（
$ npm upgradeが実行された）Pull Requestが自動的にOpenされる - 「マージ待ってるよ～」状態になるので、それをチェックして問題なければマージする
実際にOpenされるPull Requestの例
上記対応の3つ目の「マージして問題ないかのチェック」の中で、BBQのコードリーディングついでに 該当ライブラリの利用箇所の確認 と 該当ライブラリのアップデート内容が書かれたChangelog確認 を行っていたのですが、BBQのコードに詳しくなれるのはもちろんのこと、副次的に BBQ以外にも知見を得れていること に気が付きました。
dependabot で見つかるもの以外にも世には色んなChangelogがある
少し話は変わって、それまではプロダクトのアップデート情報やChangelogを見ても、流し見するだけで真剣には読んでいなかったのですが、 dependabot の対応でライブラリのChangelogを読むようになってから自然と世の中のプロダクトのアップデート情報が気になるようになりました。
いくつか読んだ中で印象的だったものとしては下記2つで、これらは社内ドキュメントツールにざっくり翻訳してまとめた記事を上げてみたりもしました。
- https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/
- DBにかぶせたらGraphQLのエンドポイント生やせる君のHasuraに大型アップデートが入るアナウンス記事
- 複数DB接続できたり、使えるデータソースがPostgreSQL以外も対応するようになった
- https://developer.chrome.com/blog/new-in-devtools-90/
- Chrome 90でのバージョンアップ内容がまとまった記事
- flexboxがDevTools内でデバッグしやすくなったり、CWVが見れる機能がついた
やってみてわかったChangelogを読むメリット
LTの中では下記3つでまとめていましたが、時間の都合上1つ目の「変更点から、プロダクト・ライブラリがどう変化しようとしているのか気づくきっかけができる」についてしか触れることができませんでした。 しかし、個人的には2つ目、3つ目のメリットも非常に大きいと感じているため、こちらの記事でご紹介できればなと思います。
Changelogをフックにプロダクトを深ぼる
リリースされているフレームワークやライブラリ、アプリケーションなどはすでに一定プロダクトとして成立する形で出来上がってる構造になるので、どこから見ていいのかわからなくなることも多いです。
しかしながら、Changelogには多くの場合、アップデートされた内容とともにアップデートされた理由と関連するユースケースの情報（こういう使い方を想定して機能を追加しましたみたいなこと）が書かれているので、アップデート対象そのものの知識をつけるのに効率が良いというメリットがあります。
| これが | こうなる |
|---|---|
 |
 |
これは2つ目の「アップデートからその対象の全体的な構造・関連性について知るきっかけができる」というメリットに大きく関わる部分で、Changelogからアプリケーションやライブラリの構造を深ぼっていく糸口になりますし、どういった機能が関連しあっているのかに気づくきっかけにもなり得ます。
また同時に、Changelogに書かれている想定ユースケースから「そんな機能があったのか！」と気づく3つ目のメリットにも繋がります。 実際に、ChromeのChangelogを読んだ際にDevToolsの知らなかった機能をいくつも発見して驚いた記憶があります。（意外と深い階層に便利機能があって気づいてないことが多々ある）
技術力向上にはアウトプットが重要と言うけども
また、Changelogを読むだけでなく、（Changelogが英語記事の場合に）ざっくり翻訳して記事にまとめるという活動は自然とアクティブラーニングになって良い勉強になることを実感したので、合わせて紹介しておきます。
私は、学生時代に「知識の定着のためにはインプットだけではなく、アウトプットまで行うことが大事」と聞き、技術力の向上のために下記のような形で学習を行ってきていました。
とにかく勉強会に参加して知らない単語を知る（とりあえず情報に体当たりして、出てくるキーワードのインデックスだけ貼る） ↓ そこで知った単語をあとでググって調べてみたり、ちょこっとデモ環境を作って肌感覚を得る ↓ ☆（機会があれば）実践投入して更に自分の血肉にしたり、一定ラインを超えてきた辺りで手を動かして得たしくじりや知識を登壇・発表側に回る
このやり方は☆の発表まで持っていくところが肝要で、 登壇・発表側に回ることによって 、自分の知識が整理されるし、理解があやふやなところを再度調べ直して知識の深さが高まったりするので 得られるものが沢山ありました 。
しかしながら、常に身の回りに登壇・発表する場があるわけでもないのと、発表する場の期待値のコントロールであったり表現方法を考えたりしないといけなかったりで意外と1回のカロリーが高いという問題をずっと感じていました。
アウトプットの方法としては、登壇・発表まで行かずとも経験した内容をブログ記事にする学習方法なども選択肢にありますが、上述したとおり Changelog記事自体が構造的にとっつきやすいようになっているため、初級者を脱してさらに技術力に磨きをかけたい！という人にとって効率よく知識を吸収できる という点で効率的だと感じたので、個人的におすすめできるなと思いました！
最後に…
ここまでお読みいただきありがとうございました！
私がChangelogを読むようになった経緯と、実際にやってみて感じたメリットをつらつらと書かせていただきました。 読んでいただいた中で、もし少しでもここは良さそうだなと思うポイントがありましたら、ぜひ一度実践してみていただけると嬉しいです！
これからも価値あるプロダクトを作り続けられるようにするためにも、自分の技術力アップのためにも、色々なChangelogを読んで行ければなと思います！ それに、みんなでChangelogを読んでみよう会みたいなのを開催できたらなぁ…とか妄想したりもしています…！
最後に、イベントでお話したときの資料（ https://speakerdeck.com/gatchan0807/changelogwodu-ntezi-fen-falseensiniakiyariawozuo-ru ）と当日のアーカイブ動画（ https://www.youtube.com/watch?v=mslmwMd2_rM ）のURLを記載しておきます！ イベントでは座談会という形で社内の雰囲気なども感じていただけるかと思いますので、よければご覧ください！
