Visual Studio Code＋Draw.io IntegrationでUMLなどの作図を便利にする

Visual Studio Code(VS Code) にDraw.ioの拡張が追加されたと聞いて使ってみました。

marketplace.visualstudio.com

UMLだったり、説明資料だったり、図を書くときにぴったりな機能です。普段からVS Codeを使っていれば環境構築も1分ぐらいで終わるので使ってみてはどうでしょうか。

Draw.ioとは

Draw.ioはUMLやフロー図など様々な作図ができるツールです。オンライン上やデスクトップアプリケーションとして使えます。今回、VS Codeでも使えるようになりました。
www.diagrams.net

操作画面

操作画面は以下のとおりです。VS Code 上でストレスなく作図できます。おどろきです！

インストール方法

VS CodeのExtensionsでdraw.ioを検索するとDraw.io Integrationが見つかりますのでインストールするだけです。簡単！

使い方

編集のはじめかた

drawioかdrawio.svgの拡張子をつけたファイルを作成、編集すると作図画面が表示されます。

シェイプ(図形)の追加

作図で使用するシェイプを追加できます。More Shapes...を選択すると選択画面が表示されるので欲しいシェイプにチェックを入れてApplyで追加できます。

図をXMLで編集する

図を見ながらXMLで編集できます。チュートリアルには書いてあったのですが少し詰まりましたので手順をまとめておきます。

1.VS Codeを2画面にする
VS Codeの「View→Editor Layout」から「Split 〇〇」を選択します。(〇〇はDownでもLeftでもお好きな分割で良いです)

2.XMLファイルとして開きなおす
右上の「・・・」から「Reopen With...」を選択し、「Text Editor」を選択するとXMLファイルとして開かれます。

すると以下のように作図タブとXMLタブが同時に編集できます。

XMLを修正するとリアルタイムで図が修正されていきます。検索しながら編集したり、同じような修正を何か所も行う場合はXMLで修正したほうが便利ですね。

まとめ

VS CodeでDraw.ioの拡張を試してみました。VS Codeを使っていれば簡単に作図環境が構築できるので便利です。.drawio.pngファイルの編集機能のリリースも予定されていますので、さらに便利になりそうです。(本記事執筆時のDraw.io Integrationのバージョンは0.5.2です)

LeSSのルールとヒントが学べる「大規模スクラム Large-Scale Scrum(LeSS)」 の本を読んだ

参考：Overview - Large Scale Scrum (LeSS)

スクラムをスケールさせる方法を知るため大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法を読みました。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

アジャイルをスケールさせるフレームワークはいくつかあってLeSSはその内のひとつです。他にはScaled Agile Framework、Scrum@Scale、Nexusあたりが有名だと思います。

LeSSはスクラムを出来るだけそのまま大規模にしたフレームワークです。5秒でLeSSを説明するなら「スクラムの開発チームが複数になってそれ以外はスクラムのまま」です。なのでプロダクトバックログは全体で一つです。スプリントバックログは開発チームごとにあります。ルールは簡単ですが、実践するには難しそうに感じますよね*1。だからこそ、基本のスクラムがうまくまわっていないと失敗しやすくなると思います。*2

本書は各章ごとに1チームのスクラム(通常のスクラム)、LeSS(2〜8チームのスクラム)、LeSS Huge(それ以上のスクラム)の説明があり、LeSSだけでなく1チームのスクラムについても多くのヒントがまとめられています。

目次

1 LeSS でもっと多く
2 LeSS
第I部 LeSS の構造

• 3 導入
• 4 顧客価値による組織化
• 5 マネジメント
• 6 スクラムマスター

第II部 LeSS のプロダクト

• 7 プロダクト
• 8 プロダクトオーナー
• 9 プロダクトバックログ
• 10 DONEの定義

第III部 LeSS スプリント

• 11 プロダクトバックログリファインメント
• 12 スプリントプランニング
• 13 調整と統合
• 14 レビューとレトロスペクティブ

第IV部 More or LeSS

• 15 次は何をすべきか?

付録A LeSSのルール
付録B ガイド

スクラムとLeSSの大きな違いは体制

スクラムは、1人のプロダクトオーナー(PO)、3～9人の開発チーム、スクラムマスター(SM)で開発をします。LeSSは1人のPO、2～8の開発チーム、1～3の開発チームに対して1人のSMで開発します。LeSS Hugeは人数が多いためいくつかのエリアに分けます。そのエリアは要求エリアと呼ばれ、4～8の開発チームとエリアプロダクトオーナー(APO)で構成されます。1人のPO、複数の要求エリア、1～3の開発チームに対して1人のSMで開発します。POは全体のプロダクトに責任を持ち、APOは各要求エリアに責任を持つことで負荷を分散しています。

LeSSのチーム体制のイメージ

LeSS Hugeのチーム体制のイメージ

イベントはほぼスクラムのまま

LeSSはスクラムと同等のイベントを実施します。大人数になるため実施方法が変わるイベントもありますが目的は変わりません。たとえば、スプリントプランニング1はPO＋各チームの代表者(or全員)＋SMで各チームが何を作るか決定します。スプリントプランニング2は各チームに分かれてどう作るかを決定します。

LeSSになって追加されるイベントはオーバーオールプロダクトバックログリファインメントとオーバーオールレトロスペクティブです。プロダクトバックログリファインメントやレトロスペクティブは各チームや複数チームで実施しますが、オーバーオール〇〇は全チーム参加で開催されます。

スクラムと同じく、理解は容易、習得は困難

スクラムのベース知識があればLeSSのルールを理解することはたやすいですが、導入や運用していくことはスクラム以上に難しいと感じました。本書はLeSSのルールだけでなく導入や運用を成功させるヒントが学べます。そして、そのヒントはLeSSだけでなく、通常のスクラムにも当てはまる内容だと感じました。

1 LeSS でもっと多く

1 「LeSS でもっと多く」はなぜLeSSでつくるのかを知れます。僕は以下の一文でスクラムやLeSSの良さを再認識させられました。

スクラムは必要最低限のプロセスしか定義されてないため、初期段階では不完全な状態で開発を始め、継続的に学習しスクラムフレームワークの枠内でプロセスを改善していくことになります。

過去に受けた認定スクラムマスターの研修でも「スクラムは問題を見つけるためのフレームワークで、何も解決しない。」と教わりました。スクラムやLeSSを導入するとすぐに課題が見つかると思いますが、それは正しい状態でそこから学習、改善していくフレームワークだと言えます。

4 顧客価値による組織化

4 「顧客価値による組織化」はコンポーネントチームとフィーチャーチームについて学べます。コンポーネントチームはフロントエンドとサーバサイドのように技術で分けたチームで、フィーチャーチームは機能に必要なスキルを集めたチームです。LeSSは顧客中心の原則があり、フィーチャーチームを目指していきます。スクラムも同じくフィーチャーチームを目指しています。

機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
※スクラムガイドより開発チームの特徴を抜粋

フィーチャーチームは以下のメリットとデメリットがあると書かれています。
メリット

• 明確な機能の所有権・・・顧客中心の機能にチームが責任を持てます
• 遅延を引き起こす依存関係がない・・・複数コンポーネントの影響があっても別チームの開発待ちになりません
• 顧客の言葉で話す開発組織・・・誰のために作っているか理解し、より目的のある開発ができます

デメリット

• システムのより多くの部分を学ぶ必要がある・・・複数コンポーネントの知識が必要です
• 乱雑なコード/設計に繋がる可能性がある・・・コンポーネントへの責任が薄れ、コード/設計は劣化する可能性があります
• 作業の分割方法に影響する・・・コンポーネント単位の作業分割を機能単位の分割に変える必要があります

僕の過去の経験上はコンポーネント単位でチームやタスクを分けていることが多いです。デメリットとして書かれている「多くの知識が必要」がネックになり作業効率を考えてコンポーネント単位に分かれがちだと思います。コンポーネントチームからフィーチャーチームへの移行はモブプロやペアプロが1つの改善手段だと思います。本書ではフィーチャーチームの導入マップを使った導入方法も紹介されています。

参考：Feature Teams - Large Scale Scrum (LeSS)

8 プロダクトオーナー

8 「プロダクトオーナー」はPOとしての原則と運用のヒントが学べます。POはスクラムでも難しいですが、LeSSになるとさらに難しくなるでしょう。LeSSを使って成功するプロダクトを作るにはPOの理解と行動が大切で、本項目はそれが学べます。本項目で特に参考になった内容はPOがやってはいけないことです。以下のタスクは行わず、チームに任せようと書かれています。

• 依存関係の調整やチーム間の調整
• チームの仕事の予想と計画
• 見積り
• 各メンバー一人ひとりまでの情報の伝達

チーム間の調整はPOの立場的にやってしまいがちだと思いますが、これをチームに任せられる状態になれば強い組織だと思います。SMがPOをフォローしてPOの負担を減らしていかないと開発がまわりません。POの立場になる人は開発以外の社内作業も多いイメージですので、過負荷にならないようにSMやチームにタスクを任せながら、意思決定のための時間を増やしたいですね。

13 調整と統合

13 「調整と統合」は自己組織化された調整と統合を複数チームで行うヒントが学べます。LeSSではチーム同士の調整はチームに任せられています。そのためにも自己組織化されていることが求められます。本項目では15のガイドが紹介されていてどれも共感できる内容でした。

• ただ話す
• 調整しやすい環境
• コードでのコミュニケーション
• 継続的にインテグレーションする
• コミュニティ
• クラスチームミーティング
• 複数チームの設計ワークショップ
• 現在のアーキテクチャワークショップ
• コンポーネントメンター
• オープンスペース
• トラベラー
• 偵察
• スクラムオブスクラムズをしない方がいいかも
• リーディングチーム
• テクニックを混ぜ合わせる

すぐできて効果が高そうな項目は「ただ話す」です。他のチームことが分からなくて、そこから話が進まない場面がありますよね。解決は簡単で分からないなら聞けばよいというヒントです。チームが違うと自分たちで壁を作ってしまって、相談するにもハードルが高くなりがちです。そのハードルを低くしてチーム間の調整が楽にできれば解決できる問題は多いと思いました。

まとめ

スクラムをスケールさせる方法を知るため大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法を読みました。読む前に抱いていた印象よりも通常のスクラムどおりでした。LeSSのルールだけでなく、進めるためのヒントがまとまった書籍なので、LeSSを導入する際にはおすすめの一冊です。

*1:軽量、理解が容易、習得は困難

*2:スクラムやアジャイルに関わらず大規模な開発は難しい

リポジトリの一部だけcheckoutするGitコマンド：sparse-checkout

大きなリポジトリを扱うときにリポジトリの一部だけcloneしたい時があります。そんなときに使えるコマンドがgit sparse-checkoutです。Partial Cloneとgit sparse-checkoutコマンドを使うとリポジトリの一部ディレクトリだけcheckoutできます。

Partial Clone機能を使うと不要なオブジェクトを除外してダウンロードできるので、大きなリポジトリもサイズを抑えて素早くcloneできます。
git-scm.com

Partial Cloneしたリポジトリに対してgit sparse-checkoutを使って必要なファイルだけcheckoutします。Git 2.26でgit sparse-checkoutにaddが追加され使いやすくなっています。
git-scm.com

今回の検証に使ったgit version は 2.26.2 です。

2020/08/29 追記

git 2.27以降は同じ手順が使えないので注意です。
iucstscui.hatenablog.com

概要

リポジトリの一部だけcheckoutするにはPartial Cloneで最小限のデータをcloneし、sparse-checkoutで必要な部分だけcheckoutします。

使い方

Partial Cloneで最小限のデータをcloneする

Partial Cloneはcloneコマンドのオプションを使って実現します。
git clone --filter=blob:none --no-checkout <リポジトリ名> <ディレクトリ名>

--filter=blob:noneオプションはblobオブジェクト*1のダウンロードを除外します。--no-checkoutはclone完了後のcheckoutを行いません。これによりファイルをダウンロードせずにcloneできるためサイズが抑えられます。

以下は同じリポジトリに対してオプションを変えてcloneした場合のサイズの違いです。--filter=blob:none --no-checkoutを使った場合にサイズが節約されていることがわかります。

git clone https://github.com/git/git.git
→185 MB
git clone --no-checkout https://github.com/git/git.git
→144 MB
git clone --filter=blob:none --no-checkout https://github.com/git/git.git
→65 MB

sparse-checkoutで必要なディレクトリだけチェックアウト

--filter=blob:none --no-checkoutを使ってcloneした場合、ディレクトリ内は空の状態です。sparse-checkoutコマンドで必要なディレクトリをcheckoutします。

1. sparseCheckoutを有効にする

git sparse-checkout init --coneコマンドでsparseCheckoutを有効にします。

ルートディレクトリのファイルが展開され、サブモジュールが初期化された状態になります。ディレクトリ関連はcheckoutされません。

2. パターンを指定してディレクトリをcheckoutする

パターンの指定は2種類あります。

git sparse-checkout set <パターン>

指定したパターンに一致したディレクトリがcheckoutされます。例えば、git sparse-checkout set DocumentationでDocumentationディレクトリがcheckoutされます。

git sparse-checkout add <パターン>(Git 2.26 で追加)

指定したパターンが追加され、一致したディレクトリがcheckoutされます。例えば、git sparse-checkout set Documentationのあとgit sparse-checkout set ciとした場合、ワーキングツリーにはciディレクトリだけcheckoutされています。同じ条件でgit sparse-checkout add ciとした場合、ワーキングツリーにはDocumentationとciディレクトリがcheckoutされます。

3. 指定しているパターンを確認する

git sparse-checkout listでsparseCheckoutに設定しているパターンが確認できます。

4. sparseCheckoutを無効にする

git sparse-checkout disableでsparseCheckoutが無効になり、リポジトリの全ディレクトリがcheckoutされます。

補足

sparse-checkoutを使っている場合でもコミットやプッシュ、ブランチの切り替えは可能です。

まとめ

一部だけclone(checkout)したい場合に便利なgit sparse-checkoutを調べました。大きなリポジトリを扱う場合に効果があります。過去に紹介した取得するコミット数を減らしてclone するshallow cloneと合わせて知っていると状況に合わせた使い分けができます。
iucstscui.hatenablog.com

参考URL

github.blog
github.blog
github.com

おまけ

読み方(調べるまで分からなかったので)
sparse-checkout：スパース チェックアウト
Partial Clone：パーシャル クローン

*1:blobオブジェクトはファイルの内容が格納されたデータです

パタン・ランゲージは作り手と使い手を近づける / アレグザンダー勉強会 に参加した

2020/05/14に開催されたアレグザンダー勉強会 2020/05に参加しました。アレグザンダーやパタン・ランゲージについては詳しくありませんが、デザインパターンやFealess Changeなどパタンに関する技術に触れてきました。アジャイルとも関連があるアレグザンダーについて知識を深める良い機会だと思い参加しました。

alexander-study.connpass.com

どういった思いで勉強会を立ち上げたのかはkyon_mmさんの記事を参照いただくのが良いです。
note.com

第1回は参加したみなさんでアレグザンダーの理論を使って生き生きとしたコミュニティにしていくにはどうすれば良いのかを話し合いました。講義形式の勉強会ではありませんでしたので体系だったまとめではありませんが、雰囲気を伝えつつ、僕が印象に残ったことをまとめていきます。

勉強会の雰囲気

Discord(コミュニケーションツール)とMural(オンラインホワイトボード)を使って進行していきました。付箋を使いながらどんなコミュニティにしたいのか話をしていき、その途中途中でアレグザンダーの話が盛り上がる、熱量のある会でした。

当日のホワイトボード

印象に残ったこと、感じたこと

パタン・ランゲージは多様性を大切にし、文化をうむ考え方

パタン・ランゲージは何か特定の問題に対応するための解決集のような印象を持っていました。それゆえに「このときはコレ」といった繰り返し起こる良い再現性を言葉にして伝えるためのツールと考えていました。その考えは間違ってはいないけど、足りてなかったと感じています。今はパタンをうむプロセスや、作り手と使い手を近づけることも含めてパタン・ランゲージだと考えています。また、この作り手と使い手の近い状況が生き生きとした環境を生むと考えています。

SECIモデルと重なる部分がありそう

SECIモデルは暗黙知から形式知、形式知から暗黙知を「共同化(暗黙知)」「表出化(形式知)」「連結化(形式知)」「内面化(暗黙知)」という4つのステップで考えるフレームワークです。
anagileway.com

パタン・ランゲージも暗黙知を形式知にし、その形式知同士を組み合わせて一つの知識にするので似ている部分があると感じました。パタン・ランゲージもSECIモデルのように成長していくと考えると新たな気づきがありそうです。

生き生きとしたコミュニティについて考える

勉強会が終わってからも生き生きとしたコミュニティはどういう状態なのか考えていました。個人的な考えとして運営と参加者や、登壇者と参加者など、発信側と受信側が近い状況を保つことは生き生きとしたコミュニティを運営するポイントだと考えています。コミュニティには職種が違ったり、テーマについての知識量が違ったりと色々な方が参加されます。その誰もがコミュニティに貢献出来て、誰もがコミュニティから何かを得られる場にできれば良いなと思います。

まとめ

第1回目のアレグザンダー勉強会に参加しました。今までの僕はパタン・ランゲージについて狭い知識だったことに気づき、今後のパタン・ランゲージを学ぶ楽しみが増えました。パタン・ランゲージとSECIモデルとの共通点も気になるので合わせて調べていきたいと思います。

関連記事

SECIモデルはScrum Fest Osaka 2019で初めて知りました。
iucstscui.hatenablog.com

git pullでerror: The following untracked …やYour local changes…が出たときの原因と対処

Gitに慣れていないときはgit pullを実行したさいにエラーが出て困ることがあります。1度対処方法が分かれば大したことないのありませんので本記事ではgit pullで起こるエラーと原因、解決方法をまとめておきます。

追跡されていないファイルでエラー

error: The following untracked working tree files would be overwritten by merge:
<ファイル名>
Please move or remove them before you merge.

git pullしたとき、remoteと同じファイル名で追跡されていないファイルがローカル環境にあってエラーになっています。対処法は一時退避するか、削除するかです。

一時退避する

git stash -aでスタッシュ領域に退避できます。その状態であればgit pullが成功します。退避したファイルはgit merge stash@{0}でマージすることもできます。

削除する

該当のファイルが不要な場合、git clean -fdで削除できます。

変更中のファイルでエラー

error: Your local changes to the following files would be overwritten by merge:
<ファイル名>
Please commit your changes or stash them before you merge.

git pullしたときにローカル環境のファイルが変更中のためエラーになっています。対処法は一時退避するか、変更を取り消すかです。

一時退避する

上記と同じくgit stashでスタッシュ領域に退避できます。この場合「-a」オプションはなくてもgit pullが成功します。*1

変更を取り消す

git restore <ファイル名>で変更を取り消します。その状態であればgit pullが成功します。

まとめ

git pullを実行したさいに一度は発生するエラーについてまとめました。Gitコマンドを使った対処法の紹介でしたが、エラーになったファイル名を変更して一時退避してもいいと思います。やりやすい方法で対応していきましょう。

git stash、git clean、git restore、それぞれのコマンドについては別でも記事を書いています。
iucstscui.hatenablog.com
iucstscui.hatenablog.com
iucstscui.hatenablog.com

*1:-aを付けてても大丈夫です

変更を一時退避するGitコマンド：stash

開発中、最新の環境にしたくてPullしたとき、競合することはありませんか。または急ぎで別の開発を頼まれて今の変更をコミットせずにおいておきたいことはありませんか。

そんな時に使えるコマンドがgit stashです。git stashは現在の変更点を一時領域に退避(スタッシュ)できます。
git-scm.com

今回の検証に使ったgit version は 2.26.2 です。

変更を退避する

git stashコマンドはHEADとの差分がスタッシュされます。スタッシュされるファイルはオプションによって変わります。以下のフォルダ構成でオプションによる違いを確認していきます。

root/
　├ commit.txt
　├ change.txt
　├ new.txt
　└ ignore.txt

commit.txtは追跡されているファイルです。
change.txtは追跡されているファイル＋変更ありのファイルです。
new.txtは追跡されていないファイルです(開発中で新しく作ったファイルの想定)。
ignore.txtは.gitignoreで無視ファイルに設定しています。

git stash

スタッシュされるファイルはHEADと差分がある追跡されているファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt

git stash -a

スタッシュされるファイルはHEADと差分があるすべてのファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt
• new.txt
• ignore.txt

git stash -u

スタッシュされるファイルはHEADと差分がある無視ファイル以外のファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt
• new.txt

git stash -k

スタッシュされるファイルはHEADと差分があるファイルです。ただし、ステージングエリアに登録しているファイルの変更は残ったままです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt

スタッシュの一覧を確認する

git stash listコマンドでスタッシュの一覧が表示されます。

stash@{0}: On master: option-all
stash@{1}: On master: option-non

git stashコマンドで-m <コメント>オプションをつけてコメント付きでスタッシュすると一覧表示したさいにわかりやすくなります。

スタッシュの変更内容を表示する

git stash showコマンドでスタッシュしたさいの変更内容が表示されます。

change.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

スタッシュの変更内容を反映する

git stash popコマンドでスタッシュの内容をワーキングツリーに反映します。また、反映後はスタッシュから削除します。
git stash applyコマンドでスタッシュの内容をワーキングツリーに反映しますが、反映後にスタッシュから削除しません。

スタッシュを削除する

git stash clearコマンドですべてのスタッシュを削除します。
git stash drop コマンドで1つのスタッシュを削除します。

TortoiseGitで使う

TortoiseGitでもgit stashが使えます。基本はCUIと同じで、操作がGUIになるだけです。

変更を退避する

右クリックメニューからStash changesをクリックします。

ポップアップにメッセージや、オプションを選択してOKをクリックでスタッシュします。

スタッシュの変更内容を反映する

右クリックメニューからStash Popをクリックでスタッシュの内容をワーキングツリーに反映します。

まとめ

変更を一時退避するgit stashコマンドを調べました。過去にスタッシュしたのになぜかファイルが退避されてないということがあったのですが、オプションの指定ができてなかったんだと気づきました。知っているつもりのコマンドも改めて調べることは大切ですね。

変更された行のコミットを確認するGitコマンド：blame / おすすめのツールはVSCode＋GitLens

前回の記事はgit bisectを紹介しました。
iucstscui.hatenablog.com

今回は同じくバグ調査に役立つgit blameです。
git blameは変更された行の情報(コミットのハッシュ値や更新者)を確認するコマンドです。誰が変更したか分かれば変更の意図などを確認できますよね。
git-scm.com

以下のそれぞれの環境で使う方法についてまとめていきます。

• CLI
• VisualStudioCode＋GitLens
• TortoiseGit
• GitHub

サンプルコード

git bisectの記事で使ったコードを使って検証しました。
github.com

CLIで使う

基本的な使い方

git blame <ファイル名> を実行するとそのファイルの変更一覧が確認できます。

<省略>
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 21)             else if (num % 3 == 0)
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 22)             {
YYYYYYY (iucstscui 2020-05-05 22:05:26 +0900 23)                 return "Fizzzzzzzzzzzzzzz";
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 24)             }
<省略>

左からコミットのハッシュ値、更新者、日付が表示されます。

特定の行を調べる

-Lオプションを使うことで表示数行数を絞り込めます。

行番号指定で絞り込み

以下は10行目から20行目を表示します。
git blame -L 10,20 -- <ファイル名>

以下は10行目から10行を表示します。
git blame -L 10,+10 -- <ファイル名>

正規表現で絞り込み

以下はキーワードの文字がヒットした行付近を表示します。
git blame -L /キーワード/ -- <ファイル名>

過去の情報を見る

以下は指定したリビジョンより過去の情報が表示されます。
git blame <コミットのハッシュ値> -- <ファイル名>

VisualStudioCode＋GitLensで使う

VisualStudioCodeのGitLensという拡張機能をインストールするとgit blameと同等の機能がより使いやすくなります。
marketplace.visualstudio.com

選択行にgit blameと同等の情報が表示されます。

選択行の空白の部分にマウスオーバーすると変更差分が表示されます。

上記ポップアップのChangesをクリックすると差分が表示されます。

GitHubで使う

GitHubでもgit blameが使えます。

GitHubでファイルを表示後、右上のBlameボタンをクリックします。

変更箇所にコミットメッセージが表示されます。

上記のコミットメッセージをクリックすると差分が表示されます。

TortoiseGitで使う

TortoiseGitでもgit blameが使えます。

ファイルを右クリックし、Blameを選択します。

ポップアップが表示され、変更箇所にコミットのハッシュ値が表示されます。

まとめ

変更された行の情報が確認できるgit blameを紹介しました。なぜ変更されたのか経緯を調べるために便利なコマンドです。GitLensが使えるVSCodeが一番扱いやすそうでした。