【小ネタ】 GitHub Copilot Chat でインライン差分 ( Inline Diff ) が表示されないときの対処法
はじめに
2023/6/22 現在、GitHub Copilot Chat は Technical Preview です。 アップデートにより、改善される可能性が大いにあります、必要に応じて最新情報を追ってください。 本ポストにおける環境は以下の通りです。 VS Code のみで動作の確認をしています。
Visual Studio Code - Insiders Version 1.80.0
GitHub Copilot Chat v0.3.2023062201 ( VS Code Extension )
何が問題だったか
GitHub Copilot Chat は In-Editor Chat という機能を有しており、 エディタ上でコードを範囲選択すると、その部分を対象として Copilot とやりとりができます。
（詳細は👇公式のドキュメント参照）
この In-Editor Chat は非常に便利なのですが、 Copilot からの提案内容が、現在のコードに対してどのように変更があるのかわかりづらいことがありました。 以下、具体例を画像とともに紹介します。
例 : TypeScript で username を lastName と fisrtName に分解し、それぞれ Property としてセットする。
以下のようなコードがあります。
この username を lastName と fisrtName に分解し、それぞれ Property 名を与えてセットするよう Copilot とやりとりをします。 そのため下記部分を範囲選択し、 Ctrl + I ( macOS だと Cmd + I ) で In-Editor Chat を開きます。 チャット欄に 「 username を lastName と fisrtName に更新してください。」と入力し実行します。
そうした際、以下のように差分がわかりやすく表示されるのが望ましいですが、表示されない場合もあります。
なお、これをインライン差分 ( Inline Diff ) と呼ぶようです。
差分が表示されないときの対処法
インライン差分 ( Inline Diff ) が表示されない場合はおおむね以下のように、 copilot の提案内容がすでに現在のコードに反映されておりどのような変更があったか不明瞭な状態にあります。 この提案内容を適用してよいか、それとも破棄するか判断しづらいため、インライン差分を表示したいですよね。
対処法は簡単で、 discard ボタンの隣にある👇矢印から Show Inline Diff を選択すれば表示できるようになります。
注意事項
なお、私が試した version だとバグがあるようで、クリックしてもメニューが一瞬表示されすぐ消えてしまいます。 そのため tab キーでカーソルを移動し、 Enter で開く必要があります。
また、インライン差分が表示されていなくても Show Inline Diff にチェックがついた状態でメニューが表示されるバグもありそうです。 Show Inline Diff にチェックがついていても、選択すればインライン差分が表示されるようになります。
まとめ
まだ GitHub Copilot Chat は Technical Preview ですが、どんどん使い倒していきたいので、小ネタですがまとめました。
皆さんも良い Copilot ライフを。
インナーソースとプラットフォームエンジニアリングの親和性
この記事は GitHub Pages で公開していたブログのアーカイブです
はじめに
インナーソース ( InnerSource ) もプラットフォームエンジニアリング ( Platform Engineering ) もみなさん聞きなじみありますか？
どちらの概念も Gartner 社の発表する Hype Cycle for Software Engineering 2022 において黎明期にある、と発表されています。
(なおプラットフォームエンジニアリングについては Emerging Technologies Hype Cycle 2022 においても同様に黎明期にあるとされています)
ここではこれら2つの概念の関係性について考えていこうと思います。
インナーソースとは
インナーソース ( InnerSource ) とは、オープンソースの原則を社内にも適用して実践する取り組みや、その活動によって生まれる組織文化のことを指します。具体的には、インナーソーシングの対象となるソースコードを社内で公開し、社員が内発的動機に基づいて協働できる環境を整え、組織間のコラボレーションを促進します。
より詳しくは インナーソースで始める組織内オープンソース開発入門 をご覧になることをおすすめします。
プラットフォームエンジニアリングとは
プラットフォームエンジニアリング ( Platform Engineering ) とは、セルフサービス型のプロダクト型プラットフォームづくりを促進する概念です。
プラットフォームエンジニアリングについて詳しく理解するためには プラットフォームエンジニアリング(Platform Engineering)とは？ 解説と考察、 Platform Engineeringへの招待 を参照することをおすすめします。
プラットフォームエンジニアリングは、セルフサービス型とは対極にある依頼型でプラットフォームを提供してきた（であろう）インフラエンジニアの方々の関心が強いような印象です。
実際、勉強会での事例でも IaC や k8s などで構成されたプラットフォームをベースに語られています。
しかし、プラットフォームエンジニアリングはインフラに限らず、 UI ライブラリやバックエンドの認証プロセスなど適用可能な領域が広い概念だと考えています。
プラットフォームエンジニアリングの成功とその先にあるもの
プラットフォームエンジニアリングにおいて難易度が高いのはプラットフォームの継続的な利用や価値向上でしょう。 プロダクト志向が重要であることは間違いありませんが、それだけではプラットフォームの維持は難しいと考えられます。 プラットフォームの価値が継続的に上昇すると、そのプラットフォームのユーザーは増えるでしょうし、 それに伴ってフィードバック数も増えることが予想されます。 フィードバックが少ないうちは迅速に対応でき、ユーザーを満足させることができますが、 フィードバックが増えると対応が追いつかなくなり、「プラットフォーム維持チームは対応が遅い」という評価を受ける恐れがあります。 いくらプラットフォーム維持チーム内でフィードバックに優先順位をつけて対応をしたとしても、上述の評価を避けるだけの開発速度を達成するのは難しいでしょう。 また、フィードバックへの対応が遅いと、本来プラットフォームとして提供すべき機能をユーザー自身がプラットフォームの外で機能追加をする可能性があります。 これは車輪の再発明となり得るだけでなく、「使わなくていいプラットフォーム」という評価にもつながる可能性があります。
しかし、プラットフォームエンジニアリングにおいては、多くのフィードバックを効率的に処理する方法がまだ十分に検討されていないと思われます。 現状では、ほとんどのフィードバックに対して「実装を検討します」「今期は立て込んでいるので来期実装します」というような返答をせざるを得ないのではないでしょうか。 そこで解決策の一つとして出てくるのがインナーソースです。
プラットフォームエンジニアリングを取り巻く協働の形
改めてインナーソースについて軽く解説をしますが、インナーソースとは、オープンソースの世界の価値観や考え方を組織内にも取り入れ、協働を促進する取り組みのことです。 特にサイロ化され分断された組織間のコラボレーションを促進することを目的としています。 このインナーソース実践により得られる組織間コラボレーションを利用し、プラットフォームに対する多くのフィードバックを効率的に処理しようというのが、プラットフォームエンジニアリングにおけるインナーソースの可能性です。
具体的には、プラットフォームのリポジトリを社内向けに公開し、寄せられるフィードバックを Issue として登録してもらいます。 そして、プラットフォームのユーザーにも、必要であればこの Issue に取り組んでもらい、プルリクエストを作成してもらいます。 もちろんコードレビューは必須ですが、こうすることでユーザーは多くを待たずして必要な機能をプラットフォームとして利用することができます。 プラットフォームという特性上、あるユーザーが必要としている機能は他のユーザーが必要としている可能性も高いはずですから、これは車輪の再発明の防止ともなります。
ここまでの話からプラットフォームエンジニアリングにおいても、プラットフォーム維持チームとユーザーは組織を跨ぐ関係性であることがわかります。 加えてこの提供者・利用者の関係性は潜在的に対立関係になりやすいでしょう。 そのためインナーソースを実践し、プラットフォーム維持チームとユーザーを提供者・利用者の関係性から協働の関係性に移行させていくことが重要です。
さいごに
インナーソースはプラットフォームエンジニアリングを実践し、価値を提供し続けるプラットフォームをつくるために必要な取り組みの一つだと確信しています。 とはいえインナーソースは多くの日本企業において実践のハードルが高く国内の事例もまだ多くありません。 InnerSource Commons コミュニティではプラットフォームエンジニアリングという観点に限らず、インナーソース実践者を増やす活動をしています。 興味がある方はぜひ Connpass のコミュニティページや Slack への参加をお待ちしています。
インナーソースを日本でやるとはどういうことなのか
こんにちは、InnerSource Commons Japan の久保です。 みなさんインナーソース （InnerSource）は聞いたことありますか？ 概念自体は割と古くからあるのですが、日本のコミュニティができたのは2022年の7月ごろです。 それまでは日本語のコンテンツも少なく、日本の環境における知見などもあまりありませんでした。
私はこのポストを書く時点で一年ほど社内でインナーソースを実践しようとしたり挫折したりしていますが、 そんな中で得た知見だったり課題だったりをまとめるポストにしようと思います。
改めてインナーソース（InnerSource）とは
概要だったり定義だったりはすでに素晴らしい資料があるのでリンクをぺたぺたと貼っておこうと思いますが、 簡潔にまとめると以下の通りです。
「オープンソースの世界で成功した原則を社内にも取り入れソフトウェア開発に適用する。 また、そのための文化変革や組織間のサイロを壊す。」
より概要から詳しく知りたい方は👇の資料だったり、InnerSource Commons Japan の Youtube を参照してみてください。
伝統のある日本の大企業こそインナーソースをやろう
インナーソースとは組織間のサイロ・隔たりがある企業こそがやるべき取り組みです。 従業員規模が一桁二桁のスタートアップやベンチャーであれば、そもそもサイロなんて存在しないかもしれませんし、 ソースコードはすでに全社に公開されており、誰でもプルリクエストを投げられるかもしれません。
またいわゆるメガベンチャーと呼ばれるような企業は社員数こそ多いものの組織文化として既に醸成されている部分があり、インナーソースが寄与できることはなかったり限定的であると推察されます。
しかし、（伝統ある）日本の大企業はそうはいきません。 機能的分業の結果、業務の部分最適化が進み、組織間で対立が起きていて顧客に価値を届ける活動の妨げになっていたり、 セキュリティ・コンプライアンスなどの観点から大きな情報格差があって現場が適切な判断を下せなかったりなど現代のグローバルマーケットで通用する理想の組織とは程遠いのではないでしょうか。（諸説）
ですが、これらの課題はインナーソースの実践で改善する方向に力が働く可能性が大いにあります。 グローバルマーケットに対しての日本企業の競争力に課題ある現代、インナーソースは日本の大企業こそ実践するべきだと強く考えています。
ソースコードである必要はない
インナーソースという名称や、そのルーツに迫るとソフトウェア開発への適用にフォーカスしがちですが、 私は必ずしもソフトウェア開発に限る必要はないと考えています。 社内で管理されている規定やルール、テンプレートなど様々適用が可能なはずです。
例 : 服装に関するガイドライン
例 : 会議の際に使用する議事録等のテンプレート
着目すべき点はどこかで勝手に決まっていたりするものに対してフィードバックをすることで、協働を促すことができる点です。 もちろんフィードバックの受け口であったり、議論する場（ログの残るチャットベースが望ましい）を用意する必要性はあります。 ただ、オープンソース・インナーソースは GitHub などフィードバック・議論をする場（Issues）がもともと整備されていたというだけであり、 そういった場さえ用意できればインナーソースはなんにでも適用できる大きな可能性を秘めているはずです。
GitHub などでできることの代替手段を提供するだけなので、難しく考える必要性はないと思います。（実践は一筋縄ではいかないと思いますが）
議論する場として Teams や Slack などでチャネルを用意してあげればいいでしょうし、 インナーソースの対象となりうるもの（上記で言うところのガイドラインやテンプレート）が PDF として公開されているのであれば、そのベースとなっているであろう Excel なり Word なりのファイルを共有・編集権限の付与などしてあげれば良いでしょう。（原本が壊れないようにする工夫も必要です）
もちろん実践は一筋縄でいかないことが明白なのですが、難しく考えすぎて最初の一歩が踏み出せないのはもったいないです。
インナーソースという名称により生まれる課題
新しい取り組みへの抵抗
全世界に公開するオープンソースの「オープン」に対して、会社の内部にフォーカスを向けた「インナー」という名称は非常に的を射ていると思います。
社内でインナーソースを実践する上でインナーソースとは何かを関係者に説明をする機会が必ず訪れるはずですが、 そうなると「インナーソースはオープンソースを源流に持つ」という文脈を語ることは避けられないわけです。 そのまま工夫なく話をすると「既存の開発手法・文化を脅かす新しい何か」と捉えられるでしょう。 新しい取り組みを始めようとすると避けられない問題ですが、インナーソースも例外ではありません。
常套手段かもしれませんが、新しい取り組みはスモールスタート、小さく静かに始めましょう。 ある程度、実績が出来てから大きく広げる活動を始めるのでも遅くはないはずです。
私はアジャイル開発の実践をスモールスタートで始めたのち、社内に展開し一定の理解を得られた経験があるので、インナーソースでも同様の進め方が適切だと踏んでいます。
インナー"ソース" ( Inner "Source" )
もう一つ大きな問題があります。 それはインナーソースで破壊するべき組織間のサイロは必ずしもITや開発に詳しい組織とは限らない、という点です。 多くの（特に伝統のある）日本企業における組織構造は主に機能別分業をベースに構成されているかと思います。（営業部門・システム部門・マーケティング部門など）
すなわち、インナーソースとは営業部門とシステム部門間など異なる業務をこなす組織間にあるサイロを破壊することが真なる目標だと私は理解しています。 再三言及していますが、インナーソースはソフトウェア開発をルーツに持ちます。 伝統のある日本企業は業務の部分最適化がかなり進んでいるはずなので、営業部門はITに詳しくない可能性が大いにあると思います。（少なくとも私の環境は…）
となると、インナーソースについての説明を受けても「開発部門がやることであり、私たちは関係ない」と捉えられかねません。 この認識はオープンソースに対してインナーソースという名称がつけられた背景を伝えると、より強調されるかと思います。
このことからただでさえ変化に抵抗のある組織に対して、インナーソースという名称を利用することで携わる部門をより限定的にしかねないです。 そのためインナーソースではなく「情報の透明性を持たせる取り組み」や「部門間連携」など言葉を工夫して浸透させていく必要性があるかもしません。
さいごに
今回はインナーソースの概念・価値観をどのようにして日本企業に売り込んでいくのかについてまとめました。 そのため現代の日本企業におけるソフトウェア開発環境には踏み込みませんでした。 また別のポストでソフトウェア開発環境にフォーカスしてみます。
インナーソースについては InnerSource Commons Japan というコミュニティがあります。 Connpass や InnerSource Commons のページのリンクを貼っておくので、ぜひご覧ください。
