IDEから離れず、コード起点でプルリクやレビューができるCodeStream
日々の業務を効率よく進めるには、作業しやすい開発環境が必要だ。New Relicのソフトウェアエンジニア、齊藤恒太氏も、大好きなもの作りのために生産性も効率も爆上がりする、イケてる開発環境を求めてアップデートを欠かさないと明かす。だが、これがなかなか難しい。GitやIDE、Slack、Microsoft Teamsなど、開発作業で使うツールは案外多く、何かあるたびにウィンドウを切り替えたり、複数あるコミュニケーションチャネルをまたぎながらやりとりしたりと、一つ一つは小さな手間でも積み重なれば時間も集中力も奪うコストに変わる。その影響は個人にとどまらず、チーム全体のパフォーマンス低下に及ぶ可能性もある。
開発環境や周辺ツール、プロセスが開発者の足を引っ張っていては、開発者自身やチームがクリエイティブな仕事をできなくなる。そんな課題を解消するツールとして、齊藤氏は「New Relic CodeStream」（以下、CodeStream）をお勧めする。CodeStreamは、アプリケーションのテレメトリデータを関連コードと紐付けてIDE内に表示するプラグインソリューションだ。対応するツールは、VS CodeやVisual Studio、GitHub、JIRA、Asana、GitHub、GitLab、Bitbucket、Slack、Microsoft Teamsなど。広く使われているツールはほぼ網羅しているといっていいだろう。
タスクやイシューは、IDE内のCodeStream画面上に表示される。イシューの作成や確認、タスク修正してコミットしてからのプルリクエスト（PR）でのマージ、（レビューアによる）レビューなど、すべてこの画面上で完結する。これまでは必要に応じてツールを切り替えたり、ツール分散する情報の整合性を確保したりと、本来は時間を割くべきではない作業に時間を取られてきたが、それもなくなる。
特筆すべきは、コード中心にコンテキストが維持された状態で管理されている点だ。たとえば、タスクで作業開始すると、ブランチが自動的に作成される。また、PRでタスクをマージするとき、CodeStream画面内のPR一覧から新規プルリクエスト作成ボタンをクリックすれば、どのブランチのどこにマージされるかが表示される。
「従来は、整合性をとるためにブランチ名を決めたり、PRとイシューの関連づけを意識したり、複数の修正をしているときに注意深くブランチを切り替えたりと、細々としたことに気を配る必要があった。それが、CodeStreamを導入することでブランチの関連づけなどが自動処理されるので、煩雑な作業がなくなり、手動ミスも減り、開発に没頭できるようになる」（齊藤氏）
合わせてもうひとつ、CodeStreamではコード起点でコミュニケーションがとれる。既存コードのバグを修正するとき、そのコードを誰が書いたか分からないことがある。このときよくやるのは、コードをチャットツールにコピペしてチームメイトに聞き回る、コメント欄に埋もれたイシューやPRを過去に遡って調べるといった作業で、これがとても時間がかかる。特に最近は在宅勤務で開発することが増え、同僚との距離が遠くなった。コードレビューもWeb会議をセットアップして実施するも、気軽に会話するという感じではない。
CodeStreamでは、IDE内でコミュニケーションがとれる。たとえばコード内に意図が分からないメソッドを発見したら、“Add a Comment”を選択してディスカッションを開始。メンバーにメンションが飛び、コメントを開くと同時に表示されるコードの該当箇所を見ながら“Add Comment Back”で返信できる。メンションされた人がそのときIDEを開いていなかったとしても、連携しているSlackやTeamsから直接やりとりすることも可能だ。また、過去のやりとりもコードに紐付けられているので、修正の背景がすぐに確認できる。
さらに、コミット前の軽いレビューといったニーズにも応える。たとえば修正した箇所に問題ないかどうか、チームメイトに軽く確認してもらいたいということもあるだろう。そういうときは、コミットしない状態でCodeStream画面から“Feedback Request”を選択。ローカルのワークツリー内の修正コード一覧を表示して、その中から該当する未コミットのコードを選び、レビュー対象に登録。レビューアにレビュー依頼を飛ばす。レビューアは通知を見てIDEなどでコードをチェック、承認や修正依頼、コメント追加などして返すという流れだ。
「通常はマージやPR後にコードレビューを行うが、それではどうしても開発工程の後半にレビューが集中してしまい、一気にチェックするレビューアの負担も手戻りの負担も大きくなる。上流工程で早めに修正をかけることができれば、レビューは軽量化されて、手戻りも減る。それに、コードを気軽にレビューするという文化が醸成されれば、品質にも良い影響が出るはずだ」（齊藤氏）
開発者がオブザーバビリティを得ることで問題解決も迅速化する
上述しただけでも十分に理想的な開発環境が実現しそうだが、New Relic Observability PlatformとCodeStreamを連携させることで、開発者の能力を次世代に引き上げる、もっとパワーアップした環境が構築できると齊藤氏は熱く語る。
たとえば、運用チームから操作エラーのトラブルシューティング依頼が開発チーム宛てにあったとする。このとき、どのような状況でいつ発生したのか、頻出度はどのくらいか、いつビルドされたコードかといったヒアリングに始まり、ログをもらった上で、ビルド時のバージョンに戻してから調査を実施するといった作業が発生する。この対応だけで1～2日、最悪の場合は1週間の時間が溶けてしまった。エンジニアであれば、一度はそんな経験をしたことがあるだろうと齊藤氏は振り返る。
New Relic Observability Platformは、インフラからWebアプリ、モバイルアプリまで、フルスタックでシステム全体をリアルタイムで観測できるオブザーバビリティ（可観測性）プラットフォームだ。たとえば、アプリで発生しているトランザクション処理を詳細に追跡して性能のボトルネックやバグなどによる障害を、どのAPIで呼び出されたときにエラーがどの程度頻発しているのか、どのソースコードまたはDBクエリの問題なのか、アプリ側のどのコントローラー処理でエラーが発生しているのかといったレベルまで絞り込み、把握できるのが特長だ。
そのNew RelicとCodeStreamが連携すると、問題発生箇所のコードを自動的に特定し、「Open in IDE」ボタンからIDEを開いて、該当コードを確認できるようになる。IDEを使わない運用チームは、New Relicのチャット経由で開発チームのIDE内CodeStreamにメッセージを投げることができるので、コミュニケーションも円滑に行える。
「作業中のコードが最新のビルドバージョンではなく、ブランチを切った別のバージョンであっても、コミットハッシュ（commit SHA）から問題の構造箇所をピンポイントで特定できる」。そう述べる齊藤氏は、開発者がオブザーバビリティを得ることで、開発者視点からの迅速なトラブルシューティングが可能となり、開発や運用、QAのコミュニケーションコストを大幅に削ることができると説明する。
「新規サービスをタイムリーにリリースして改善し続けることが求められる今、開発者はコードだけ書いて、あとは運用チームやQAチームに投げて終わるという従来のやり方は、時代にそぐわない。開発者自らがアプリの性能やバグに対して責任を持ち、ユーザーの利用状況などを把握して分析、改善につなげるフィードバックサイクルに積極的に関わっていく。それが、開発者に今後求められる次世代スキルではないだろうか」（齊藤氏）
New Relicは無償でサインアップでき、CodeStreamも任意のIDEのプラグイン一覧から無償でインストールできる。効率的で快適なコーディング環境が整い、加えて次世代スキルまで身につけられるCodeStreamｘNew Relicの組み合わせ。「ぜひ試してみて、私と同じ興奮を味わってもらえたら幸いだ」と齊藤氏は述べた。
