Content last updated 2025-09-12

バリューストリームディスカバリ

GitLab を利用する多くの見込み顧客や顧客にとって、ソフトウェアデリバリのパフォーマンス改善は重要なビジネスアウトカムとなっています。残念ながら、ソフトウェアデリバリプロセスに内在し増大する複雑性のため、組織のソフトウェアデリバリのバリューストリームは、しばしば数十、場合によっては数百の手作業による設定の接点や受け渡しで構成されています。一般的に、現状のプロセスに対する可視性と理解が不足しており、ソフトウェアデリバリの改善を特定し測定することが困難になっています。現状のソフトウェア開発バリューストリームを理解せずに、組織はソフトウェアデリバリ能力を意味のある形で改善しない領域に時間、労力、資金を投じるリスクを負います。

GitLab のアカウントチームは、見込み顧客や顧客がバリューストリームの概要と理解を得るのを支援することを提案するべきです。

このページのコンテンツは、見込み顧客や顧客のバリューストリームをよりよく理解するために利用できるさまざまなアプローチ、ツール、成果物を概説しています。現状のより良い理解、ボトルネックの特定、ソフトウェアデリバリパフォーマンスのベースライン測定の確立により、GitLab は見込み顧客や顧客が、迅速かつ継続的にデリバリされるインパクトのある変更と改善の実装を通じて、重要なビジネスアウトカムを達成できることを保証できます。

アプローチ

GitLab では、バリューストリームディスカバリプロセスは、基本的な議論から指標やデータで満たされた精緻な探索まで、クライアントの多様なニーズに対応するように調整できます。

その旅は、ソフトウェアデリバリの課題と影響を受けるビジネス目標についての初期的な洞察を提供する、シンプルな会話から始まるかもしれません。もうひとつの、より詳細な出発点としては、さまざまなチームとの複数の議論があり、現状のソフトウェアデリバリプロセスの全体的かつ簡潔な見方を提供しますが、指標に深く踏み込まないものです。代替的な「ハンズオン」体験は、開発者の「a day in the life」に焦点を当てた終日セッションの形で、日々のワークフローへの実践的な洞察を提供します。最後に、戦略的で深く成果重視のアプローチを必要とする方々のために、包括的でエグゼクティブが後援するワークショップを提供しています。これらの構造化された複数日にわたる複数チームのイベントは、詳細な指標と調整された推奨事項を伴う、バリューストリーム全体のエンドツーエンドの概要を提示します。

このスペクトラムのアプローチは、シンプルな対話から集中的なワークショップまで、必要なエンゲージメントの深さに対応できることを保証し、クライアントのソフトウェアデリバリの効率性と効果性を高めるための関連性のあるインパクトのある洞察を提供することを常に目指しています。

バリューストリームディスカバリセッション

バリューストリームディスカバリ（VSD）は、組織または一連のチームがどのように顧客に価値を提供しているかを明確に理解することを目的としています。VSD は、目的、時間のコミットメント、利用可能な顧客/チームのエンゲージメントレベルに応じて、さまざまな手法を使用して実施できます。

一般的なバリューストリームディスカバリ手法

ディスカバリセッション（バリューストリームコンセプト付き）： バリューストリームマッピングのコンセプトを標準的なディスカバリセッションに統合します。これは GitLab の Command of the Message アプローチとよく整合しており、顧客の現状、望ましい未来の状態、成功を測定するために使用される指標を理解することに焦点を当てます。顧客のバリューストリームが、より大きなビジネス目標の達成にどのように結びついているかを把握することが極めて重要です。
「Day in the Life」： 確立された「Day in the Life」SA プラクティスを活用して、価値あるバリューストリーム情報を抽出します。初期の観察は単一のチームに限定されるかもしれませんが、得られる指標と洞察は妥当な基盤を提供します。理想的には、この演習をバリューストリーム内の複数のチームを含むように拡大して、より大きなクロスファンクショナルな可視性を実現します。
バリューストリームディスカバリセッション（インフォーマル）： バリューストリーム全体からの代表者を含む、焦点を絞ったセッション。完全なワークショップよりも構造化されていませんが、それでも顧客のバリューストリームを理解することを優先し、時間が許せば即時的な改善領域を特定する可能性があります。
バリューストリームワークショップ： このハンドブックページの下で詳述されている包括的なアプローチ。

顧客フォーカス手法

バリューストリームディスカバリは、エンドユーザーへの価値提供における課題を明らかにすることを目的としているため、エンドユーザーに焦点を当てた手法は価値があります：

カスタマージャーニーマッピング： 顧客がバリューストリームと相互作用する体験を視覚化します。タッチポイントをマップし、痛点を特定し、ジャーニーを改善する機会を発見し、提供される価値全体を強化します（Lucidchart 概要）。
Voice of the Customer（VOC）： バリューストリームでの体験について、エンドユーザーから直接フィードバックを集めるためにアンケート、インタビュー、ユーザーテストを採用します。この定性的データは、顧客のニーズ、フラストレーション、改善領域への洞察を提供します（Gainsight 概要）。

手法の選択

最も適切なアプローチを選択する際に考慮すべき要因は以下のとおりです：

時間制約： よりシンプルな手法は、忙しいスケジュールに合わせやすいです。
エンゲージメントのレベル： 顧客/チームには深いワークショップのバンド幅があるか、またはより集中度の低いアプローチがより適切でしょうか？
緊急性： バリューストリームが対処できる即時的な痛点はありますか？よりシンプルな手法はより速い洞察を提供できる可能性があります。
望ましい成果： 目標はハイレベルな理解か、それとも完全なワークショップを必要とする詳細なアクションプランか？

重要な注意： 選択された手法に関係なく、バリューストリームディスカバリの中核的な目的は、顧客の価値提供プロセスを協力的に理解し、非効率を特定し、最適化の機会を見つけることです。

バリューストリームワークショップ

プロセス

見極め

バリューストリームワークショップを実施するには、GitLab の現場チームと見込み顧客や顧客の双方からの非自明な時間投資が必要です。この時間投資に対する適切なリターンを確保するために、機会は以下の基準を満たすべきであり、満たさない場合は例外を設けるべき理由を説明してください：

エグゼクティブスポンサーと強い関係を持っている
アカウントの総アドレッサブルマーケットが少なくとも 1000 GitLab ユーザー（コマーシャルアカウントの場合は 100 ユーザー）である
見込み顧客や顧客がソフトウェアデリバリパフォーマンスや関連プラクティス（ソフトウェアサプライチェーンのセキュリティ、クラウドマイグレーション、アプリケーションのモダナイゼーション、開発者エクスペリエンスと効率性など）の改善に焦点を当てている
エコノミックバイヤーと関係を築いている
社内チャンピオンを特定し、関係を確立している
POV（Proof of Value）の前にバリューストリームワークショップを位置づけ、ボトルネック、ステークホルダーにとって重要な主要指標を理解することを推奨します。これは、ディール成立の価値ドライバーとして POV を開始する前に成功基準に合意する機会も提供します。

機会が適している主要な指標には以下があります：

特定の日付までに以下の 1 つ以上を達成するための具体的なイニシアチブがある
- 開発者エクスペリエンスと効率性の改善
- ソフトウェアを提供する能力を変革または客観的に改善
- DevOps 能力のモダナイゼーション
- ソフトウェアサプライチェーンのセキュリティ
- 特定のアプリケーションまたは複数のアプリケーションのモダナイゼーション
- 新しい重要なアプリケーションを市場に提供
- クラウドへのマイグレーション
顧客が現在 GitLab の一部の機能を使用しており、プラットフォームをより活用することがソフトウェアデリバリのアウトカムをどのように推進するかに関心がある
カスタマーサクセスにとって、バリューストリームワークショップは、現在のソフトウェアデリバリのバリューストリームのボトルネックを特定することで、新しいユースケースへの拡大や現在の採用の改善の機会を発見するのに役立つはずです
既存の顧客が、ソフトウェアデリバリパフォーマンスを推進するために、当社のバリューストリームアナリティクス機能の採用に関心を示している

バリューストリームワークショップのスコープは、常に明確に定義されるべきです。明確に定義されたスコープは、適切な人々がチームに含まれていることを確保し、何に焦点を当てるべきかについて合意するのに失われる時間のリスクを減らします。このため、GitLab がファシリテートするワークショップのスコープは、常に DevSecOps のスペース内であるべきです。

教育とコミットメント

成功するバリューストリームワークショップには、ソフトウェアデリバリのステークホルダーと、顧客のバリューストリームを構成するさまざまなプロセスに精通した人々によるワークショップへのコミットメントが必要です。プロセスとその組織にとっての価値を理解せずには、参加者は成功するバリューストリームワークショップを確保するためのコミットメントを欠いてしまいます。見込み顧客や顧客に対し、メリット、プロセスの詳細、必要なコミットメントについて教育してください。このステップを支援するために、見込み顧客や顧客向けにカスタマイズしてバリューストリームワークショップポジショニングデック - (録画) を活用してください。

バリューストリームワークショップは高度なディスカバリセッションであり、初期の機会ディスカバリとテクニカルディスカバリの両方が事前に実施されていることが期待されます。

主な利点

現在実施されているソフトウェアデリバリのバリューストリームまたは「本番への道筋」のディスカバリと文書化
- ソフトウェアデリバリパフォーマンスの進捗を測定するための合意されたベースラインを確立
- 手作業による設定の接点や受け渡し、その他のバリューストリームのボトルネックを特定
- プロセス改善のロードマップを作成
- 価値提供プラットフォームへの投資収益率を理解
- DevSecOps ライフサイクル内で従来サイロ化されていた機能間の協働を促進

見込み顧客や顧客がプロセスとその利点を理解した後、ファシリテートされるワークショップやインタビューをスケジュールすることでステークホルダーとワークショップ参加者からのコミットメントを確認します。ディスカバリセッションの期間を見積もり、文書化されたバリューストリーム、推奨事項、リードアウトが提供されることを期待として設定します。

必要な時間のコミットメントは？

上記のゴールと利点に焦点を当てると、最小限実行可能なバリューストリームワークショップを完了するために必要な時間は、組織ごとに異なります。ワークショップは網羅的な議論や調査を必要とすべきではありません。さまざまなバリューストリーム参加者とステークホルダーの可用性とコミットメントに応じて、プラクティスは完了に最短 4 時間から、複数日にわたる複数セッションで最長 15 時間かかる可能性があります。

準備

バリューストリームワークショップトラッキング Issue

バリューストリームワークショップを検討する際の 最初のステップ は、バリューストリームディスカバリチームに意図を通知し、見込み顧客/顧客に関する可能な限り多くの情報を提供することです。それを行うには：

バリューストリームディスカバリプロジェクトで新しい Issue を作成してください
request_value_stream_assessment というラベルのテンプレートを使用してください

これにより、GitLab のチームはバリューストリームディスカバリの進捗を追跡し、取り組みにチームメンバーを割り当てることができ、これは次の準備ステップの主要な要件です。

内部準備ミーティング

顧客にバリューストリームワークショップを位置づける前に、内部準備ミーティング（非同期可）を持つことが極めて重要です。ミーティングのゴールは以下を議論できるようにすることです：

機会（SA エンゲージメントのための SFDC リンクを含むべき）
主要なプレイヤーと顧客の役割
これらの主要プレイヤーがどの指標で測定されているか
アカウントチームが認識している、これらの主要プレイヤーの OKR
バリューストリームワークショップから期待される成功した成果は何か
顧客に提供する主要なスライドを選ぶ
ポジショニングと顧客プランニングセッション中に行う主要なディスカバリ質問を選ぶ
レビューすべき重要な Chorus 録画
GitLab エグゼクティブスポンサーを特定し連絡する

ポジショニング

初期の顧客ポジショニングは、主要なステークホルダーに対してバリューストリームアセスメントを位置づけ、顧客の賛同を得ることができます。顧客ポジショニングには以下を含めるべきです：

バリューストリームワークショップとは何か？
バリューストリームワークショップは何を含むのか？
バリューストリームワークショップに関わる主要参加者は誰か？
バリューストリームワークショップから顧客に期待される成果は何か？

顧客とのプランニングミーティングの次のステップとして、プロジェクトまたはいくつかのプロジェクトを特定することが重要です。

ポジショニングセッションの出発点として使用できるリソースは以下のとおりです：

顧客とのプランニングミーティング

バリューストリームワークショップの計画は、適切な期待、焦点、関与する人々があれば、一般的に 1 時間以内に行うことができます。

バリューストリームワークショップを計画する際には、バリューストリームトランスフォーメーションチャーターを使用することを推奨します。

バリューストリームを定義する

マップする予定のバリューストリームは何か？
マッピングプロセスはどこで始まり、どこで終わるか？
どのコンテキストや条件が考慮されているか？
バリューストリームを通じて作業が流れるきっかけとなるトリガーイベントは何か？
デマンドレートはどのくらいか？（このバリューストリームに関連する 1 日、1 週間、1 か月などあたりの受信作業量）
（任意）どのチーム、プロジェクト、機能などがマップされているか？
境界と制限を定義する
- 望ましい未来の状態を見るとき、チームが運用しなければならない特定の制限（財務、システム、顧客、組織、物理的など）が存在する可能性が非常に高い
- これは、非現実的な望ましい未来の状態や、定義された時間枠で単に達成できないものを作るのを避けるために重要です
時間枠を定義する（顧客はどのくらい速く未来の状態を実現する必要があるか？）

これらの質問への答えがなければ、私たちは可能な変動の各々を理解しようとして大きな時間とエネルギーを費やすリスクを負い、しばしば定義しにくい指標（「状況による」のトラップ）になってしまいます。そのため、これらの定義がワークショップの前に確認され合意されることが極めて重要です（一般的にプランニングミーティングの一部として）。

バリューストリームワークショップ

人
プロセス
ツール
ワークフロー
質問

人

役割	責任	GitLab の役割
スクライブ	主な目的としてセッションを文書化し、エグゼクティブブリーフィングテンプレートを作成するために後で使用される、出現する主要指標を捉えるチームメンバー。	AE、Shadow SA、CSM
ファシリテーター	バリューストリームマッピングプロセスに完全に精通したチームメンバーで、セッションをリードする責任を持ち、議論がトピックから外れないこと、適切なレベルおよび必要なペースを保つことを確保する。	SA
アカウントリーダー	望ましい未来の状態について議論する際に見込み顧客の長期的な戦略的ビジョンが考慮されることを確保し、現在の状態に追加のコンテキストも提供できる。バリューストリームワークショップ参加者とミーティングをスケジュールする。各セッション後にサマリのフォローアップメールを送信する（テンプレート）。Salesforce 内の VSW トラッキングフィールドを更新する。	AE

プロセス

私たちが進めるプロセスは、ハイレベルでは以下のとおりです（機能ペルソナ/チームごと、単一のワークショップまたは複数のミーティングにわたって）：

なぜここにいるのか？（エグゼクティブスポンサー主導）
プランニングミーティングで設定された期待を再確認する
1. バリューストリームの開始点と終了点
現在の状態
1. 初期のプロセス「ウォークスルー」/情報ディスカバリ
  1. ペルソナ/チームごとに人、プロセス、技術を捉える（情報ディスカバリガイド）
2. 2 回目のプロセス「ウォークスルー」（必要な場合）
未来の状態を設計する（すべてのペルソナを含む単一のワークショップを行う場合、またはスポンサーとのプランニングミーティングで）
1. 期待を再度確認し、チームが作成しようとしているターゲットに沿ってチームを整える
2. 「正しい仕事」を決定する（バリューストリームが最適となるためにどのプロセスとステップが必要か）
  1. プロセスとプロセスステップが本当に不要な場合は、それらを削除する
  2. 全体的な プロセス時間とリードタイムを増加させることができる場合、プロセスとプロセスステップを追加する
3. 仕事を流す
  1. 可能な限り、すべてのプロセスブロックでリードタイム（LT）、プロセスタイム（PT）を削減し、より高いパーセント完了および正確（%C&A）を達成することを目指す
  2. リーンの対策と改善ツールを使用する
4. 仕事を管理する
  1. バリューストリームが意図したとおりに機能しているかどうかをどのように測定するか？（KPI）
  2. 誰がバリューストリームのパフォーマンスをモニターし管理するか？

ツール

リモート：
- Google Sheets - Value Stream Mapping Template
- Zoom、MS Teams、または Google Meet
- バリューストリームマップのビジュアライゼーション用の LucidChart
  - LucidChart は IT 管理アプリケーションです。LucidChart のアクセスがあるかどうか不明な場合は、ブラウザの Okta インターフェースに移動し、「Search Your Apps」を選択して LucidChart SSO が利用可能かどうかを確認します。利用可能な場合、LucidChart があなたに割り当てられており、Okta から起動して、チームが共有しているすべての LucidChart ドキュメントで協働できます。利用可能でない場合、LucidChart SSO はまだ割り当てられていません。
  - Okta で LucidChart SSO が割り当てられていない場合は、「access-requests」プロジェクトに移動し、「Lucid Chart」をリクエストする Issue を提出してください。Issue をマネージャーに割り当て、IT::to do ラベルを追加してください。アクセスリクエスト Issue の例はこちらで見つけられます。
  - アクセスリクエストが緊急の場合は、アクセスリクエスト Issue へのリンクを #it_help Slack チャンネルに貼り付け、緊急である理由のメモとともに it-help を @ メンションしてください。
オンサイト：
- 付箋
- ペン
- 大きなホワイトボード

ワークフローの例

アイデアから本番へ
本番インシデントへの対応
ツールチェーンのアップグレードと保守

アイデアから本番へ

Idea to Production

本番インシデントへの対応

Response to Production Incident

ツールチェーンのアップグレードと保守

Toolchain Upgrading and Maintenance

エグゼクティブブリーフィング - 発見事項を要約する

バリューストリームワークショッププロセスの一部としての最終ミーティングは、発見事項と次のステップのプレゼンテーションです（エグゼクティブプレゼンテーションと呼ばれていますが、双方向の議論となることが期待されています）。このミーティングのハイレベルなトピックは以下のとおりです：

プランニング成果のサマリ；何のプロセスがマップされ、どのようなターゲット目標が作成されたか
現在の状態のマッピングのサマリ（VSM 図とともに）
提案された未来の状態のマッピングのサマリ（VSM 図とともに）
主要な違い、期待されるプロセスとビジネスのメリットを強調する
推奨事項のウォークスルー
トランスフォーメーションプランのウォークスルーと合意の獲得。トランスフォーメーションプランは、最良の結果を得るためにプロフェッショナルサービスとともに構築すべきです。機会でプロフェッショナルサービスをどのようにポジションするかについてはこちらをご覧ください
次のステップを定義し、レビュー日を提案する

エグゼクティブブリーフィングのテンプレート例はこちらで見つけられます。お客様のニーズに合わせて適宜変更してください。

最終ミーティングの前に、追加のフィードバックを集めるため、チャンピオンや主要ステークホルダーとエグゼクティブブリーフィングをレビューすることを推奨します。次に、合意を得るために、より広いチームに共同で提供することがゴールです。

顧客/見込み顧客からの FAQ

顧客にとって何のメリットがあるのか？
- ソフトウェアデリバリライフサイクルの無料のハンズオンコンサルティング分析（現在の状態、未来の状態、改善領域を含む）
- 業界の同業他社と比較してどこにいるかの競合分析。このレポートには、4 つの DORA メトリック（DevOps パフォーマンスの良い測定基準として広く認識されている）の最新ベンチマーク値が含まれています State of DevOps Report 2021。
- 未来の状態に到達するための戦略的計画とともに、目に見える、または見えない課題を克服する方法に関する推奨事項
顧客にとっての典型的な成果は何か？
- シリコンバレーの医療機器企業では、バリューストリームワークショップを行うことで、リリースサイクルを 6 か月から 1 か月に短縮するための具体的で実行可能で現実的な採用プランが提供されました。
- 金融サービス銀行では、バリューストリームワークショップを行うことで、自分たちのプロセスを同業他社と比較する機会と、プロセスを改善するための明確な道筋が提供され、最終的に品質を高めながらソフトウェアをより速くリリースすることで望ましい ROI を達成できました。
- 金融サービスのお客様は、バリューストリームワークショップと GitLab への投資を組み合わせることで、以下の成果を実現しています：
  - 市場投入時間の短縮
  - デプロイ頻度の増加
  - 変更のリードタイム短縮
  - 変更失敗率の改善
  - トランスフォーメーション変更を推進するために必要な能力の獲得（デジタル、DevOps、ソフトウェアデリバリ、モダンアプリケーションなど）
通常どのチームが関与するか？
- アプリケーション開発チーム、品質エンジニアリングチーム、DevOps、それからアプリケーションセキュリティから始めます。
始めるのに最適な場所はどこか？
- 最もビジネスクリティカルなアプリケーションまたは市場投入時間の要件がより厳しい代表的なアプリケーションを選択してください。
我々のチームから多くの時間投資が必要か、または我々のチームは他のプロジェクトで忙しい
- バリューストリームワークショップで集中的なディスカバリを行うのに、チームあたり 1 時間または 1.5 時間かかります。私たちのシリコンバレーの顧客では、4 つの異なるチームを 4.5 時間でインタビューしました。グループ設定で行うことを望まない場合は、最も忙しくないチームから始めることができます。
1 つのチームずつインタビューできるか？
- はい。その場合は、アプリケーション開発チームから始めたいと思います。これは、顧客の開発プロセス（アイデア-本番）プロセスの概要を理解するのに役立ちます。

Salesforce トラッキング

3 分間のビデオ概要では、以下に説明するフィールドとプロセスをカバーしています。

アカウントリーダー（AE）は、以下に概説する Salesforce 機会レベルの VSW トラッキングフィールドを維持する責任があります：

VSW Start Date - 見込み顧客/顧客との VSW キックオフコールの日付。（これは見込み顧客/顧客との最初のミーティングで、VSW を実施することにコミットした後、VSW ワークショップの計画を議論するためのものです。）
VSW End Date - VSW のリードアウトが見込み顧客/顧客に提示された日付、または VSW ステータスが「Stalled」に設定されている場合、見込み顧客との最後のミーティングの日付。
VSW Status - VSW のステータス
- Planning - 内部的な見極めとプランニングが行われています。このステップ中に資格を満たさない場合は、ステータスを削除してください。このステータスが設定されているとき、VSW 開始日は設定すべきではありません。
- Pitched - 見込み顧客/顧客に VSW を位置づけました。このステータスが設定されているとき、VSW 開始日は設定すべきではありません。
- Accepted - 顧客が VSW の実施に合意し、キックオフコールをスケジュールしました。このステータスが設定されているとき、VSW 開始日は設定すべきではありません。
- In-process - キックオフコールを実施しました、VSW を積極的にファシリテートしている、またはリードアウトのために結果をまとめているところです。
- Completed - VSW のエグゼクティブリードアウトを見込み顧客/顧客に提示しました。VSW 終了日が設定されるべきです。
- Stalled - 進行中でしたが、見込み顧客/顧客が応答しないため、追加のインタビューをスケジュールできません。VSW 終了日が設定されるべきです。
VSW Readout - VSW リードアウトミーティングからのセンチメント。
- Positive - 見込み顧客/顧客は私たちの推奨事項に非常に受容的で、進歩的な次のステップがあります。
- Neutral - 見込み顧客/顧客は受容的でしたが、明確な次のステップはありません。
- Negative - 見込み顧客/顧客は私たちの推奨事項に受容的ではありませんでした。
VSW URL - リードアウトプレゼンテーションとその他の VSW 成果物を含む google drive フォルダの URL。
VSW Start Date Net ARR - （自動入力フィールド）VSW 開始日が入力されるときの機会の Net ARR。

ソリューションアーキテクトは、アクティビティを記録する際に、以下の SA アクティビティタイプを活用すべきです

VSW Pitch
VSW Execution

トレーニングとイネーブルメント

トレーニングと VSW 成果物の単一の信頼できる情報源は、関連する HighSpot ページで見つけられます。

バリューストリームワークショップ概要

このコースは、GitLab アカウントチームが見込み顧客や顧客に対し、顧客のバリューストリームの軽量なアセスメントを提供することによってどのように支援すべきかについての概要を提供するように設計されています。このコースは、見込み顧客や顧客のバリューストリームアセスメントを実施するために使用されるアプローチ、ツール、成果物を概説します。

LevelUp での GitLab バリューストリームワークショップ認定

過去のイネーブルメント

貢献方法

協働とイテレーションの精神において、このフレームワークを継続的に改善するためにご協力ください。貢献の方法には以下が含まれます：

このページを改善するためのマージリクエストを作成する
バリューストリームワークショップ Issue にフィードバックやタスクを追加する
#customer-success および #solutions-architects Slack チャンネルで経験を共有する
ポジショニングデックへのフィードバックや更新を提供する、または独自のバリエーションへのリンクを提供する
このページにファシリテーション録画、サマリ文書、その他の成果物へのリンクを提供する
#value-stream-discovery Slack チャンネルで協働する

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

ページのソースコードを見る - ページの編集 - please contribute.