ポッドキャスト: [ビデオポッドキャスト] ニコール・フォーシュグレンと考える摩擦のない開発者体験

## ビデオを見る: ## 文字起こし **トーマス・ベッツ**: こんにちは、InfoQ ポッドキャストへようこそ。私はトーマス・ベッツです。今日は、DevOps および開発者生産性において最も著名で重要な人物の一人である、ニコル・フォアグレン博士にお話しできる光栄があります。彼女はマイクロソフト、GitHub、Google といった企業で生産性の向上を主導し、『Accelerate』や『DevOps ハンドブック（第 2 版）』というベストセラー書籍の著者でもあります。彼女の最新作『Frictionless』では、開発者の摩擦（friction）を特定し除去することについて論じています。昨年 11 月には、サンフランシスコで開催された QCon の基調講演でこのテーマについてお話しされており、本日はその内容について議論してまいります。ニコルさん、InfoQ ポッドキャストへようこそ。 **ニコル・フォアグレン**: ご招待いただき、ありがとうございます。 ## 開発者体験（DevEx）における摩擦の有用性 [01:07] **トーマス・ベッツ**: QCon でのお話しの中で印象に残っているのは、開発者生産性は単にビルド時間の短縮やツール性の向上だけではないという点でした。私たちは、常に私たちを遅らせているこれらの摩擦ポイント（friction points）に目を向ける必要があります。なぜ「摩擦」という概念が DevEx に関する議論を枠組みづけるのに有用なのか、また、あなたが言うところの「摩擦」の具体例をいくつか教えていただけますか？ **Nicole Forsgren**: はい、もちろんその通りです。摩擦という概念は、開発を改善するための最良の領域を探し、どのように改善できるかを考える上で非常に役立つと思います。従来、多くのプロセスが手作業に依存していたり、過度な手順を必要としたりするケースがありましたが、それらはしばしば脆く、すぐに破綻してしまう傾向がありました。現在も AI においては同じことが言えますね。AI はさまざまな形で現れます。 今私たちが目にするコード生成の自動補完機能などは、まるで魔法のように突然現れることもあります。しかし、それが逆に、リリースやデプロイといった以前は手作業で行われていたプロセス（多くの企業で一般的です）におけるビルドアップの過程で、追加的な摩擦ポイントを生み出す結果にもなり得ます。現在、多くの企業が膨大なバックログを抱えていますね。つまり、摩擦が生じている箇所は、負荷と速度が増加し始めた際に、システムがどこで脆くなり、ひび割れを起こす可能性があるかを示す重要な指標となるのです。 ## DevEx に注目すべきは誰？ [02:16] **トーマス・ベッツ**: 脆くて崩れそうなものについて話すとき、それは開発者のマシンや特定のサービスだけの問題ではなく、会社全体の課題になり得ます。それがすべてにどう影響するか？誰が DevEx（開発者体験）に関心を持つべきでしょうか？ソフトウェアにおける最も難しい問題の一つは名付けですが、「DevEx」という言葉は「ああ、あれはコーディング担当者が対処しなければならないことだ」のように聞こえがちです。しかし実際にはより大きな問題であり、他の人々にもこの問題を認識させ、それが会社全体として私たちにどう影響するかをどうやって示せばよいのでしょうか？ **ニコル・フォアグレン**: それは非常に良いご指摘です。DevEx はそこにおいて少し挑戦的な側面があるかもしれませんね。開発上の摩擦や価値の提供といった文脈で捉えられることもあります。しかし、人々が関心を持つべき理由は、私たちが経営陣に繰り返し伝えたり、リーダーシップ層がこれらの派手な見出しを読み進める中で理解している通りです。「1 時間で新しい製品や機能を立ち上げ、デプロイできる」といった内容の headlines です。それは確かに興奮を呼びます。 完全に現実的な話ではありませんが、そのような状況において、リーダーシップに対して非常に洞察に富み、有益な情報を提供できるのは、この高速な道筋に乗りたいと願う場合や、AI を活用してこれらの素晴らしいことをすべて実現したいと考える場合です。そのためには、いくつかのシステムやプロセスを見直す必要があります。なぜなら、現状では多くの部分が開発者や開発パイプライン、つまり開発体験に集中しているからです。しかし、あなたが指摘されたように、必ずしも開発者だけとは限りません。セキュリティおよびコンプライアンスレビューの場合もあり、歴史的には大きな行き来があり、時には「セキュリティ・シアター」と呼ばれるような状況で、数週間にわたって交渉が行われたこともあります。 これは今や非常に難しく、すでに人手不足に陥っているセキュリティおよびコンプライアンスチームにとって圧倒的な負担となっています。また、リリースやローンチがどのようなものかについても考える必要があります。現在、多くの大企業が候補となるビルドを手動で選択し、それをテストに通し、さらにカナリア展開を行うというプロセスを踏んでいます。手作業が多く、引き継ぎが発生し、独自の判断ポイントが存在する限り、負荷と摩擦が増えるほど、そのようなプロセスが破綻するリスクが高まります。あなたが言われたように、それはビルドだけのことではありません。脆く、破綻しやすい承認プロセスである可能性もあり、その場合、ビジネス側は影響を受けます。なぜなら、状況の変化があまりにも急速だからです。 つまり、今朝の最新のモデルは、3 ヶ月前や 2 ヶ月前にはできなかったことを実行しています。したがって、競争のペースや業界のペースに追いつこうとする場合、たとえ機能開発の一部を加速させるだけであっても、追加されるあらゆる摩擦が、私たちの作業を遅らせている要因や、潜在的な脆弱な分岐点を浮き彫りにすることになります。 ## 迅速なフィードバックによる摩擦の可視化 [04:42] **Thomas Betts**: はい、人間が動く速度とコンピュータが動く速度の違いという考え方に通じるものがあると思います。長年にわたり、人間の速度であれば問題なく機能する多くのプロセスが開発されてきました。メールのプロセスを完了するには数日かかることがありますが、それは構いません。その間、私は他のより速い作業に集中できます。 AI やその他の自動化があらゆる分野に浸透するにつれ、単にコードを高速で記述できるようになるだけでなく、ユーザーストーリーも迅速に作成できるようになります。 これらすべてが圧縮され、結果としてプロセス全体がコンピュータの速度で動作し始めます。その時こそが摩擦が生じる瞬間であり、私たちはより速く、さらに速く、そしてさらに速く摩擦とぶつかり合い、それが火を起こすことになります。 **Nicole Forsgren**: その通りです。特に今、エージェント型ワークフローにおいて非常に興味深く刺激的な開発が進んでいる最中ですからね。かつてビルドが遅かったためにビルドを高速化し、さらに並列化して同時に実行できるようにしたのと同じことが、今起こっていますよね。もはや一人の開発者と一つのエージェント、あるいは数人のエージェントという関係ではありません。ある開発者が多数のエージェントをオーケストレーションし、それらのエージェントが自ら仕事をオーケストレートし、自らの問題を解決するという形になっています。そのため、あらゆる摩擦点は増幅されてしまいます。 ## DevEx の指標 [05:52] **Thomas Betts**: はい。では、どのようにしてこれを測定すればよいのでしょうか？過去に用いられてきた指標にはどのようなものがあり、AI 時代へと移行し自動化がさらに進む中で、それらは依然として機能するのでしょうか？同じ指標を使い続けるべきなのか、それとも指標自体が変わる必要があるのでしょうか。 **Nicole Forsgren**: これが大きな問いですね。一部の指標はそのまま残るでしょう。一方で、一部の指標は確実に変わるはずです。例えば、コード行数（Lines of Code）は、もともと良い指標ではありませんでした。 **Thomas Betts**: 確かにひどいものでした。 **Nicole Forsgren**: しかし、それは常に指摘されていました。現在、私たちはある意味ではコード行数という指標は完全に無意味なものであるという空間にいます。なぜなら、適切なプロンプトがあれば、私は数百行のコードを生成できるからです。他方、これは非常に特定の文脈においてのみ有用である可能性があります。例えば、私たちのコードベースがどのように見えるか、時間が経つにつれてそれがどのように進化しているか、そしてそれが現在のモデル調整やモデルトレーニングに何を意味するかといった文脈です。 なぜなら、私たちが特定の方式でアーキテクチャ設計し、設計し、コーディングした歴史的なコードベースでモデルを調整する場合、あるいはそれについて仮定を持っている場合、まもなく私たちのコードベースの少なくとも 1% が機械によって書かれたものになるという、ゼロではない非常に大きな割合になったときに、それが何を意味するのか。そのループにフィードすることに対して何が言えるのか。ML や AI の多くの専門家にとって、私たちが知っているのは、投入されるデータは単に増幅されるだけだということです。そのため、初期のデータやトレーニング、推論セットで捉えきれない何かが、予期せぬものに変化してしまう可能性があります。これが指標の一つの例ですが、重要な指標は一つしかないという考え方はなく、状況によって異なる指標が重要になるのです。 私たちが以前から持っている多くのフレームワークは、今日でも非常に重要です。例えば DORA を見ると、これはパイプラインに焦点を当てています。リードタイムの速度、つまり完了までにどれくらい時間がかかるか、デプロイ頻度、つまり一定期間におけるボリュームです。また、変更失敗率という品質指標や、MTTR（平均復旧時間）といった回復に関する指標も含まれています。私がこれらの活動を開始した当時は、ソフトウェア開発パイプラインを徹底的に計測・設計することが、私たちが行える最良の取り組みの一つでした。 これにより変動性を低減し予測可能性を高めることができますが、これらのフレームワークは、アイデア創出から実装・コーディング、そして本番環境に至るまでの製品開発全体、ソフトウェアデリバリー、機能開発のすべての分野で依然として適用可能です。なぜなら、スピードもスループットも品質も重要であり、これらを通じてプロセスを評価できるからです。 開発者や開発者の生産性を考える際、SPACE というフレームワークもここでは有効ですね。満足度を見ることができます。開発者は自分が持っているツールやパイプラインに満足しているでしょうか。パフォーマンスは、再び品質の成果物に関わるものです。プロセスの結果は何でしょうか。A は活動です。すべてのカウント、コード行数はどうでしょうか？あまり良いものではありません。コミット数、PR 数、一定期間内のレビュー数などです。コミュニケーションとコラボレーションでは、人々は情報の大部分をどこから得ているのか、あるいはシステムはどのように通信できるのでしょうか。API は比較的うまく機能しているでしょうか。そして完全な効率性として、どれくらいの時間がかかるでしょうか。 これらのいくつかを拡張する機会があると思います。一つには、これらはエージェントについても同様に当てはまる可能性があります。エージェントにとって使いやすさはどの程度でしょうか？エージェントの満足度はどうでしょうか？直接尋ねることはしないかもしれませんが、そうする場合もあるでしょう。しかし、それは異なる種類の摩擦として表面化するかもしれません。 いくつかの次元を追加することも検討すべきかもしれません。ここでは「信頼」が思い浮かびますね。信頼は…常に重要視されてきました。システム管理者コミュニティでは、私たちは常に信頼を中心に据えてきたはずです。システム管理者や SRE（Site Reliability Engineer）のことです。しかし今、開発者たちはそれをより意識し始めています。なぜなら、彼らは以前から比較的予測可能なシステムの中で働いてきたからです。 次に「コスト」について。コストは昔から存在する要素ですが、現在では計算リソースのコストがどれくらいか、キャパシティ（容量）はどうなるかといった点で、明確なトレードオフを迫られています。例えば、「100 のタスクをこなすために 1,000 個のエージェントを展開し、人間 1 人を置き換えるべきか？もしそうすれば、すべてのシステムがダウンしてしまうのではないか？」という問いに直面しています。 この話題には多くの指標がありますが、これはその長編版のようなものです。特定の指標に対する答えは持っていません。なぜなら、それは環境や文脈、利用可能なデータ、そして何を明らかにしようとしているかによって大きく異なるからです。 ## DevEx とシステム思考 [09:46] **Thomas Betts:** はい、あなたが言おうとしているのは、生産性を測定しようとしているということだと思います。再び「開発者体験（Developer Experience）」という言葉に戻りますが、より良い開発者体験があれば、あなたの基調講演のタイトルであった「摩擦からフローへ」のように、DevEx がすべてを素晴らしいものにするのです。「そうだね、それはそうだが」と思いつつも、「開発者」と「開発者体験」という名前のせいか、私たちは改善しようとしているのはそれだけだと考えがちです。しかし、常に大きな視点で捉えるべきなのです。それは常にソフトウェアのデリバリー（提供）に関わることであり、まさに私たちが目指していることです。 **Nicole Forsgren**: その点は非常に重要だと思います。システム全体の視点を持つことで、何が起きているのかをより深く理解できます。確かに初期段階では、早期のシグナルが得られる開発者に焦点を当てることもありますが、常に重要なのはシステム全体です。開発者は常に何らかのシステムの中で作業を行っています。それが手動プロセスのみからなるシステムであっても、メインフレームに依存したシステムであっても、クラウド上で高度に自動化されたシステムであっても、あるいは最近では多数の AI エージェントや AI ツールを活用するシステムであっても、すべてはシステムの一部として機能しています。 **Thomas Betts**: はい。コード行数が極めて不適切な指標であるというあなたの例についてですが、これはかつて生産性の代用指標として使われていたことがあります。「1 日に 100 行のコードを書ける versus 10 行しか書けない」といった比較です。しかし、私は実際に使用される 10 行の完璧なコードの方が、100 行のゴミのようなコードよりもはるかに価値があると思います。 **Nicole Forsgren**: その通りです。時にはコードを削除することが正解となることもあります。では、それをどう測定すればよいのでしょうか？ ## AI エージェント、コード品質、開発者ワークフロー [11:08] **Thomas Betts**: しかし、システムが正常に納品され、安定して稼働し、ダウンタイムが発生せず、かつ迅速に多くの小さな変更を加えられるという目標を達成できている場合、その測定可能性はやはり「デベロッパーエクスペリエンス（Developer Experience）」と呼ばれるものに戻ってきます。しかし、それは単なる一つの要素ではなく、これらすべての他の要因を含んだものです。そこで私が指摘したいのは、あなたが最近おっしゃったアイデアについてです。つまり、「エージェントにデベロッパーエクスペリエンスについて尋ねる」という発想ですね。コーディングエージェントを持っている場合、そのエージェントに対して「進捗はどうですか？」と尋ねるのか、それとも「私の指標を要約してほしい」「DORA（Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Restore）などのデータを要約してほしい」と依頼するのでしょうか。 **Nicole Forsgren**: 現時点では私はエージェントにそのような質問はしていませんが、近い将来それが実現する世界も来るかもしれません。この内容が公開される頃には、すでにその世界にいる可能性もありますね。しかし、言葉で問いかけたり、エージェントが開発・コードを納品する様子を示すいくつかのデータポイントを眺めたりすることで、機会があると考えます。私たちは人々に話を聞く際に探しているような要素を検出できるはずです。例えば、「あなたの業務の中で本当に難しいことは何ですか？」「いつもイライラして怒鳴ってしまうのはどんな時ですか？」といった問いです。また、エージェントが何度も同じプロセスをやり直さなければならない特定の工程や問題がないか、どこかで摩擦が生じていないかを観察することもできます。あるいは、直接エージェントに尋ねることも可能です。その結果として何が得られるのかを確認できるのです。 彼らの仕事の下流への影響、あるいは彼らが実現できる成果を見ることができます。そこで私は、エージェントや AI が働く文脈を問い直す機会があると考えます。これにより、エージェントがどれだけよく機能するか、またシステム内でそれらをどのように準備しているかが明らかになります。同時に、コンピュータはまだ対応できていない困難で創造的な課題に答えるために、開発者をより良く準備し支援する方法について考え直すきっかけにもなります。 **Thomas Betts**: はい。そしてそれは、ワークフローがどのように進化しているかという点に戻ります。私たちは往々にして AI コーディングエージェントに焦点を当てがちです。それが最も簡単な部分でしょう。GitHub Copilot や Claude Code がありますね。これらは私のためにコードを書き、「この関数を書いて」という指示から、エージェントに作業を任せて考えさせ、解決させる段階へと進化しています。このエージェントモデルはソフトウェア開発ライフサイクル全体で展開されています。製品管理の分野では PM の隣に座って支援する製品管理エージェントも登場し、スクラムマスターやバックログ管理、ストーリー作成、タスク分解を助ける人々も、言語を扱うという根本的な性質ゆえに、さまざまな形で現れています。 大規模言語モデルは言語を生成する際に優れています。私が話した「C」の概念、つまりコミュニケーションとコラボレーションについてですが、私が問いたいのは、人間がより良くコミュニケーションを取るためにこれまで取り組んできたことをどう活かすか、そしてループ内にエージェントが存在する場合や、効果的なコミュニケーションパターンがあればこれらのエージェントツールの活用を支援できるかどうかです。 ## AI 時代におけるコミュニケーション、ドキュメンテーション、コンウェイの法則 [14:02] **Nicole Forsgren**: そうなる可能性が高いと思います。あなたが触れられた例の一つとして、作業を細分化し、エンジニアが実装できるように非常に明確で構造化された要件を提供することが挙げられます。私たちは、非常に明確な要件と明確な設計ドキュメントの間には違いがあることを知っています。また、どのレベルのエンジニアがそれを処理できるか、あるいはどのレベルのエンジニアに任せるべきかについて、より曖昧なドキュメントが存在することや、ドキュメントにおける不明確さという課題にも直面しています。 では、設計ドキュメントや機能ドキュメント、機能仕様書が非常に明確であれば、そのコミュニケーションは人間との間でも高忠実度であるのと同様に、エージェントとの間でも高忠実度になります。おっしゃる通り、それは言語の問題に帰着するからです。したがって、私たちがよりよくコミュニケーションし、仕様が明確になるほど良いのです。これも一つの例です。 また、API をより明確に定義して文書化することも重要です。つまり、エージェントがそれを使用する場合や、社内で頻繁に使われるものの外部には文書化されていない内部ライブラリ（ある企業内での一時的な使い捨て的なもの）の場合などです。確かに、多くの開発者は、もし自分がそれを数回使用し、そのエッジケースを知り、どこに「ドラゴン」が潜んでいるかを知っていれば、それで十分だったかもしれません。 しかし今、シニアレベルのタスクをある程度こなせるジュニアレベルの開発者がいますが、多くのガイダンスが必要です。これは API や、私たちのシステムがどのように通信するかについても言及できることです。 ## AI をファーストラインサポートとして活用することのメリットとリスク [15:23] **トーマス・ベッツ**: はい。はい、システム境界が適切であれば、システム同士がどのように対話するかは、チーム間や組織の構造とソフトウェアの構造が同じように対応しているはずです。コンウェイの法則がこの文脈で適用されます。まだ AI 版の補遺を記した人はいないと思いますが、もし複数のエージェントがチームをサポートする形で組織を分割・再編成した場合でも、この法則は依然として当てはまります。つまり、「私たちはこれらの人材を抱えており、それぞれに役割を支援するエージェントを配置している」という考え方が、アーキテクチャにも反映されるはずです。 **ニコル・フォアグレン**: はい。ここ数年、AI がチーム内およびチーム間のコミュニケーションに与える影響について、またそれをどう捉えればよいか、何が良く何が良くないかについて議論してきました。歴史的には、若手開発者が新人研修中や新しいコードベースの学習時、あるいは新規プロジェクトを引き継ぐ際に、チーム内のシニアエンジニアに多くの質問をするケースが多く見られます。これは素晴らしいことです。シニアエンジニアが最も効果的にできることのひとつは、チームメンバーの詰まりを解消することです。しかし、これもまた課題となります。 私のチームには、それこそが彼らの全てであり、そこに誇りを感じているシニアエンジニアもいました。しかし、彼らは多くのブロック解除作業に追われ、自分自身の技術的な仕事をする時間がほとんどありません。それはある意味で難しい状況です。一つのことに非常に誇りを持っている一方で、別のことができないことに対して少し悲しんでいるからです。 さて、今では多くのエンジニアが「AI ファースト」へと移行しており、質問を投げかけています。これは私たちの時間を解放する良い側面があるかもしれませんが、同時に奇妙な道やラビットホール（脱線）、あるいは「亀の背にまた亀」というように、思いもよらない奇妙な場所に導いてしまう可能性もあります。 そこで考えなければならないのは、コードベースをよく知る AI エージェントに質問したり、会話したりする際に、どのような適切なチェックポイントがあるのかということです。そして、自分の計画や発見をチーム内でそのコードベースを本当に熟知している誰かと確認・検証するのは、いつが適切なのでしょうか？ **トーマス・ベッツ**: そして、チームや企業に新しく加わった人にとって、それは出発点によって異なります。スタートアップでゼロから始める場合、コードがまだ存在しないこともありますよね。すべてを一から構築する必要があります。頼れる例もありません。もし頼れる例があれば、「ああ、こうすればいいんだ」と言えるでしょう。「エージェントに聞いて、読んでいるコードを説明してもらおう」などです。しかし、レガシーコードもあり、これが望ましいやり方ではないと知りつつ、より良いものに移行したいと考えているが、より良いものの具体的な例がまだ示されていない場合、「いつもそうやってきたのだから、そのまま続けなさい」といったフィードバックを得るかもしれません。 **ニコル・フォアグレン**: それは私たちのパターンに合致しています。 **トーマス・ベッツ**: はい。一方、シニアエンジニアは「昔はこうしていた」と言うでしょう。私たちはそれをやめたいのです。新しいことをしたいと考えていますが、それがまだエージェントが参照するドキュメントや、新しく入った開発者が参照する資料のいずれにも記録されていない可能性があります。そのため、やはりこれらの人々を関与させる必要があります。 ## ドキュメンテーション、RAG モデル（Retrieval-Augmented Generation）、そして持続可能なプラクティス [18:06] **ニコル・フォアグレン**: はい、その通りです。文脈に即した方法で働く必要があるという点にも少し立ち返ると思います。小規模で機敏なスタートアップと大企業では状況が全く異なります。一方で、10 年後には撤回されるかもしれませんが、普遍的に真実であり続ける要素もあります。例えば、良質なドキュメントはそうですよね。どんなに機敏なスタートアップであっても、README や基本的なドキュメントがなければ、それは一定期間しか持続できません。いずれ限界が来て破綻します。コードベースが作成されてからの時間が経てば、必ずそのドキュメントが必要になります。 そして現在、AI にはコードを分析し、少なくともコードのドキュメント化を支援してくれる非常に興味深く有望なツールが多くあります。これは今後もしばらく真実であり続けるでしょう。なぜなら、私たちがプロンプトを入力したりフィードバックを求めたり、エージェントに作業を依頼する際、それらは私たちが持つコードやドキュメントを参照するからです。RAG（Retrieval-Augmented Generation：検索拡張生成）モデルを構築する場合、人間にとってもエージェントにとっても作業結果がより明確になるよう、彼らに対して何を明確化したいのかを考える必要があります。 ## 開発者体験（DevEx: Developer Experience）に対するステークホルダーの合意形成 [19:11] **トーマス・ベッツ**: 少し方向を変えてお話ししましょう。これはあなたが基調講演や『Frictionless』という書籍でお話されていた内容の一部ですが、どうすればこれを会社全体が納得して受け入れるものに変えられるか、つまり、「この摩擦を取り除きたい」というアイデアから、「これに焦点を当てよう」「これに投資すべきだ」という合意形成へと至り、これらの課題を改善しなければならないという認識に至るプロセスについてです。ステークホルダーの合意形成はどのように変化しているのでしょうか？あるいは、AI を導入する前の状態からどう始まるのか、そこから話を始めることもできます。つまり、単に指標を持っている、あるいは指標の収集を開始できる段階から、CEO や CTO が納得して信じるようなストーリーを語れる段階へとどう移行していくのかについてです。 **ニコル・フォアグレン**: いくつかの点は、依然として概ね真実であり続けるでしょう。つまり、私たちは自社のビジネスや組織の優先事項と整合性を持たせたいと考えています。また、彼らが抱えている問題を理解し、その問題を解決したいとも考えています。そのため、多くの場合、私たちが持っているデータを文脈化し、それらの問題を解決するために提案するものや、確実に最優先課題であるとわかっているものに合致させることが重要になります。ただし、この戦略の姿は、組織内のあなたの位置や、組織自体が置かれている状況によって少し異なる可能性があります。 したがって、組織内でこの課題が認識されておらず、関心がなく、他の緊急事態に対処する必要がある場合、あなたが個人貢献者（IC）または1 線管理職であるなら、現地で一定の影響を与えるためにできることはありますし、それを上位に持ち上げることを考え始めることもできます。一方の極端なケースでは、CTO またはインフラ担当副社長が、「ソフトウェアをより迅速かつ高品質・高信頼性・高安定性で開発・提供すること」が最優先事項であると宣言している場合もあります。 そして、その取り組みを主導するために雇われることになります。それが DevEx の改善なのか測定手法の改善なのかによって多少の違いはありますが、対象となる聴衆が少し異なる可能性があります。展開戦略も若干変わるかもしれません。チームとの連携は引き続き行いますが、どのチームと協力したいかを考えることができます。引き続き情報発信を行いますが、ステークホルダーは1 線管理職や個人貢献者である場合とは少し変化するでしょう。例えば、私が個人貢献者として最初の報告先を選ぶ際、CTO に直接報告することはまずないでしょう。 どちらの場合でも、ビジネスの優先事項やニーズ、解決可能な課題と整合させることが重要です。そうすれば共感を得られ、会議の参加者も頷きながら「なるほど、確かにそうだ」と理解し、「これが私の必要とする形で整合している理由がわかった」と納得するからです。 ## DevEx を活用して製品品質を向上させる [21:40] **Thomas Betts**: 例を挙げると、企業から「顧客からバグの報告が多く、多くのリリースが行われた結果、顧客によって問題が検出され、品質スコアに影響している。これに焦点を当てたい」という声が上がることがあります。これが最優先事項となります。そして、「バグを書かないようにする」のではなく、DevEx（開発者体験）を見直し、どう改善するかを考えるのが一つの手段ではないかと言えば、それが「どれくらいの頻度でリリースを行っているか」「デイリービルドはあるか」といったAccelerateやDORA指標に関連する項目に結びつきます。より速く行えば、その分上達します。 もし「壊すことが多いから、6 ヶ月間はリリースすべきではない」と言うなら、それは根本的に正しくありませんよね？ **Nicole Forsgren**: その通りです。そして、それは重要な指摘ですね。つまり、製品や機能の信頼性が低く、バグが多い状況では、顧客エンゲージメントや顧客フィードバックは非常に低くなるはずです。そのような場合、所属する組織のリーダーシップ層、あるいは適切なステークホルダーに対して、「これは私たちにとって大きな問題だと理解しています。現在対応が進められており、これが優先事項であることも承知しています。この問題をどう解決するかを検討中です」と伝えることができます。 その一つの方法として、開発者体験（Developer Experience）に目を向けることができます。その場合、相手は「えっ？」と思うかもしれません。しかし、「はい」とお答えできます。なぜなら、私は従来のソフトウェア開発ライフサイクルがどのようなものか大まかに理解しており、これらの問題が本来検出されるべき主要な領域を特定できるからです。さっそく確認してきます。私の直感では、これらの中には非常に手作業に依存したプロセスや、優先度が低かったために整理されずに残された古びたテストスイート、あるいは不安定なテストが含まれているはずです。 そのため、経営層にとっては、これらの課題を優先事項として結びつけることが自明ではないことが多いのです。 システム開発に従事している私たちには、少数のプロセスやゲートがこれらと直接関連していることがわかります。しかし、常にソフトウェアの世界に浸っているわけではない人々にとって、それはあまり明確ではありません。そのため、そのような文脈で説明することは非常に役立つことがあります。 ## セキュリティ、コンプライアンス、リスクに基づくアプローチ [23:40] **トーマス・ベッツ**: はい、これはまさに摩擦点に関する考え方につながりますね。セキュリティやレビュー、安全性といったものをすべて撤廃しろと言っているわけではありません。それらがブロックとならないようにする方法を見つけるのです。時には、セキュリティレビューという追加ステップを設けることが、別のバックログの発生を引き起こしている可能性にも気づく必要があります。 **ニコル・フォアグレン**: その通りです。まさにその通りです。 **トーマス・ベッツ**: ああ、そうですね。手動テストが必要なので、2 週間に一度だけテストを行うことにします。突然、多くの項目が追加され、コードの 2 行を変更しただけで「チェックしたか？壊していないか？」と確認できるような細かな変更をすべてテストできなくなります。 **ニコル・フォアグレン**: はい、まさにその通りです。セキュリティやコンプライアンスレビューの観点でも、長年見てきたように「古いものが再び新しいもの」となる現象が起きます。リスクベースのアプローチを採用し、低リスクとみなされる変更については、アテステーションモデル（保証モデル）を経由させ、規定されたテストモデルに従わせることができます。これは非常に軽量で監査可能であり、追跡され、遵守されますが、実際には多くの大企業や小企業ではこれが実施されておらず、高リスクの変更とは明確に区別されるべきです。高リスクの変更には、人の目を通す必要があり、議論が必要であり、多くの人を巻き込む必要があります。 しかし、すべてを同じように扱うと、高リスクの変更は本来そのために設計されていないプロセスを高速で通過してしまったり、自動化によって問題ないはずの低リスク変更が、不適切な目のチェックや議論、長時間の会議に晒されたりします。そうすると、いずれ人々は飽きてしまい、結果として高リスクリリースにおいて質の低い判断を下すことになります。 **トーマス・ベッツ**: はい、はい。繰り返しになりますが、答えは常に「状況による」ですよね？文脈に応じた回答が必要です。ある種のトリガーで、「これはリスクが高いので追加のプロセスを経てください」とか、「閾値に達していないので、これは簡単なゴム印処理で通過します」と言える仕組みが必要なのです。 **ニコル・フォアグレン**: はい、まさにその通りです。 ## 定性的データと定量的データの比較 [25:27] **トーマス・ベッツ**: つまり、データを収集し、アンケートを実施した上で、どのようにアプローチすべきかという点について、まだ議論の余地があると思います。あなたの著書では、定性的（qualitative）および定量的（quantitative）な測定について言及されていましたね。システムから指標を取得できる場合もありますが、それが必ずしも有用とは限りません。単に入手可能なデータが得られるだけかもしれません。コード行数も取得できますが、それが何を示すのでしょうか？あるいは、ソフトウェアのリリース頻度はどうでしょうか？これらのデータは、おそらく計測機能（instrumentation）によって収集されているはずです。一方、アンケートはより定性的なフィードバックを集めるために実施されます。開発者に「何が問題か」を尋ねれば、彼らは問題を明確に教えてくれます。 **Nicole Forsgren**: 彼らは何がダメなのかを告げます。そして今、特に AI が多くのことを変え、人々に SDLC（ソフトウェア開発ライフサイクル）のあり方を再考し、再発明するよう促しているこの時期において、私はそう思います。数年前には、外側のループを圧縮する世界が来るかもしれないと述べました。まだそこまでは到達していないと思いますが、おそらく近づきつつあるでしょう。プロトタイプから直接本番環境へ進む世界では、「信頼できるのはシステムデータだけだ」と言いながら一歩引いて考えることは本当に難しくなります。なぜなら、新しいツールやシステムを非常に速く作っているため、それらを計測（インストゥメンテーション）していないからです。 これは通常、新規開発者や内部製品、さらには外部製品のビルダーにとって最優先事項ではありません。計測（インストゥメンテーション）、テレメトリー、観測可能性（オバザビリティ）です。もう一つの問題は、変化があまりにも急速であるため、計測手段を構築し、データウェアハウスやデータレイク、データファブリックに投入してすべての計算を行うまでに数週間かかることがあるということです。そして、物がこれほど急速に変化する中で、開発者数名に直接聞き、あるいは開発者数名を観察して、「現在の開発ワークフローはどのようなものですか？今、最大のボトルネックは何ですか？」と尋ねることは、非常に強力であり、少なくとも何もしないよりは遥かに良いことです。場合によってはプロセスが原因となることもあれば、システムが原因となることもあります。 時には、それは単なるメンタルモデルに過ぎないかもしれません。彼らは全く異なる物事について考えることに慣れていないのですから、システムデータがそれを表面化させることはできませんよね？なぜそうなのかを私たちに教えてくれるわけではありません。したがって、特に状況が急速に変化する際には、これを省略することもあります。もしデータがないのであれば、アンケートやインタビュー、観察があなたの味方になるでしょう。 **Thomas Betts**: はい。これは「一つのことだけやる」か「すべてやる」かの二択ではなく、優先順位をつける問題ですよね？ **Nicole Forsgren**: はい、そうです。ポートフォリオアプローチを持つことですね。 ## 着手点：クイックウィンとローカルの勢い [27:42] **Thomas Betts**: はい。実際に努力を払うなら、どこから始めるべきかどうやって特定すればよいのでしょうか？大きな課題に取り組むのか、小さなことから始めるのか、確実に成功するものに焦点を当てるのか。どこへ向かうべきでしょうか？ **Nicole Forsgren**: 一部は状況次第ですが、いくつかの比較的耐久性のある指針原則がありますよね？まず着手点については、常に多くの開発者に話を聞くことです。たとえ指標やデータ、数値を持つある程度成熟したプログラムに参入する場合でも、数人の開発者と話すことで最低限の文脈が得られます。そして多くの場合、計測機能が備わっていないために見過ごしていたであろう追加的な洞察や要素を表面化させることができますよね？したがって、これは非常に役立ちます。 また、まずはQuick Win（短期間で達成できる成果）から始めるべきでしょう。そこには手頃な果実（低垂れ枝の果物）が転がっていることが多いのです。問題に対する理解を検証するために何ができるでしょうか？アプローチの一つを試して勢いをつけ、チーム内で共通の勝利を築くことです。歴史的に、社内インフラに関する作業は必ずしも称賛されるものではありません。それを評価する企業文化も存在し、私はそのような環境を愛しています。しかし、すべての人がそれに慣れているわけではありません。なぜなら、それは顧客に直接届くものではないからです。したがって、チーム内でその勢いを築きつつ、他の場所でもこれらの成果を紹介し、目を細めて見ても何が開かれたのか、あるいは年末までに以前は不可能だと思っていたことを達成するためにどのように役立つかを示すことができれば、それは素晴らしいことです。では、人々と話し合い、Quick Winを手にした後、次は何が来るのでしょうか？ それは組織内のどこにいるかによって大きく異なると思います。私は先ほどこれに言及しました。もしあなたが自分自身でこの取り組みを行い、草の根運動として行うのであれば、間違いなく自分のコントロール範囲内で始めるべきです。誰と話すことができますか？チームと連携できますか？ハックウィークを開催できますか？単に少し面倒なだけでなく、それが複数の開発者にどのように影響するかを明確に見通せるような「ペーパーカット（小さな不便さ）」を取り除くことはできますか？それがどのように摩擦や混乱、そして遅延を生み出しているのかを理解することはできますか？ もし CEO からこれを改善するために雇われたのであれば、あなたのスコープは少し異なるものになるかもしれませんね。ステークホルダーも少し異なります。チームと連携してパイロットを実施することは依然として非常に可能性が高いですが、これは同時に、内部のビルドおよびリリースシステムが IC（Individual Contributor）として完全に破綻している場合、それが最善の出発点ではないという機会でもありますよね？エグゼクティブであっても、やはり最善の出発点ではありませんが、組織全体にわたるスコープとコントロールを持っているため、プロジェクトの初期段階で非常に現実的な候補となり得ます。 ## DevEx の拡大：チーム、部門、および組織レベルのパターン [30:08] **Thomas Betts**: はい、これもまた状況によります。私は、1 人の開発者が 1 日かけて行うものから、ハック・ザ・スデ（Hack Thursday）として木曜日を休みにし、技術の木曜日として独自の小プロジェクトに取り組むケースから、チーム全体が「1 日または 1 週間を割いて取り組む」というケース、さらには「1 週間を専用に充てる。ChatGPT を全社員に配布し、エンタープライズライセンスを取得して学習する時間を設ける」と宣言した企業全体に至るまで、あらゆる事例を見てきました。プログラミング部門からマーケティング部門に至るまで、各部署がそれぞれのやり方でこれらのツールを活用する方法に取り組んでいました。これは、「小規模なグループでこれが機能することが分かったなら、それをやや大規模なグループに広げられるか？会社全体に展開できるか？そのような普及があるのか？」という問いに関わる事柄です。しかし、これもまた、誰がどのようなことを目指しているかによって結果は異なる可能性があります。 **Nicole Forsgren**: チームや企業文化についてもですね。これも「場合による」という難しい質問ですが、この分野の多くの人々、エンジニアやプロダクトマネージャーは非常に賢明です。組織の脈拍を測り、何がフィットすると思うかを判断するのは私たちが得意とするところです。だからこそ、時々振り返って、本書でもそうしていますが、「これらはいくつかの実践可能なこと」をお伝えしています。あなたの会社の中で最も共感を得られるものを選んでください。文化と完全に相反するようなものではなく、良いフィット感があるものを見つけてください。それが勢いを築く手助けにもなるからです。 ## Quick RICE を用いた改善の優先順位付け [31:23] **Thomas Betts**: あなただけでなく、私も略語がお好きですね。本書から学んだ「RICE」や、改善の優先順位付けのためのクイック RICE テクニックについて、もう少し詳しくお話しいただけますか？ **Nicole Forsgren**: もちろんです。RICE は優先順位付けを考えるための手法です。プロダクトマネージャーは製品開発において常にこれを用いています。実際に RICE を適用する際は、以下の要素を検討します：Reach（到達範囲）：総獲得可能市場規模はいくらか？つまり、この特定のプロジェクトや摩擦ポイントによって影響を受ける社内の開発者数はどれくらいか？Impact（インパクト）：その影響の大きさはどの程度と予想されるか？秒単位、分単位、それとも週単位か？Confidence（信頼度）：解決しようとしている課題、あるいは排除しようとしている問題を達成できるという確信度はどれほどか？そして Effort（労力）：これにはどれほどの困難が伴うのか？また、どの程度の期間が必要となるか？ さて、従来の RICE では、人々が数値を使用していることがわかります。これは本書の後半でも概説した通りです。つまり、数値を算出し、計算を行うのです。RIC を E で割ることを目指します。なぜなら、最小限の労力で最大の成果を得たいからです。ただし、Quick RICE は、プロジェクトを開始する段階では少なくとも役立ちます。私たちはすぐに成果を出せるものを探しており、直感で判断することもできます。それは高、中、低のどれでしょうか？多くの場合、候補となるプロジェクトが三つ、四つ、あるいは五つあるはずです。誰かが「これは知っているから直す」と言うでしょう。素晴らしいですね。その候補をリストに追加してください。インタビューを行い、データを分析すると、おそらく数件の候補が残るでしょう。 Quick RICE はこれに役立ちます。「この項目は高で、あの項目は…」と簡単に言えるからです。RIC が高くて E が低い場合、これは開始の候補として非常に適していると言えます。一方、到達範囲が低く、インパクトが低く、自信も低く、かつ努力が必要度が極めて高い場合は、文脈によっては別ですが、通常は最良のスタート地点とは言えません。もしかすると、研究機関に所属しているのかもしれませんね。あるいは R&D を行っており、人々が不可能だと考えることを実現するために、1 ヶ月や 1 クォーターといった時間枠を設けて取り組む必要がある場合もあるでしょう。 **トーマス・ベッツ**: はい。Quick RICE は直感によるチェックですが、私はここで単純な数学のアルゴリズムに到達したことを思い出しました。ただし、数値を自分で算出する必要があります。それは、「よし、すべての項目にもっと重み付けをする必要があるな」と思わせました。5 分で終わる話ではありません。これには数日かけるつもりです。 **ニコル・フォアグレン**: その通り、まさにそうです。これも文脈に大きく依存します。組織によっては数値が必要で、計算過程や数学的な根拠を見たいというところもあります。しかし一方で、「私が評価したいのはこれらの要素だ」と述べるだけで済む場合もあります。そして後ほど、より詳細な RICE（Reach, Impact, Confidence, Effort）分析を行う際には、考慮すべき追加の要素をいくつか含めることがあります。例えば、それが組織目標とどのように整合しているかです？また、リーチやインパクトだけでなく、DevEx の概念の中で他にどのような要素を検討すべきでしょうか？これらは、モメンタム（勢い）を得る能力にも言及するからです。 それは継続的で十分な資金が投入されている取り組みに密接に関連していますか？それを把握しておくのは良いことです。なぜなら、それが境界線上にある場合、その判断を後押しする要因になる可能性があるからです。 ## LLM をコミュニケーション、正当化、および盲点の発見に活用する [34:09] **トーマス・ベッツ**: 各種ステークホルダーへの説明やコミュニケーション文書の作成、あるいは適切な質問を投げかけるために、LLM（大規模言語モデル）を活用した経験はありますか？ **ニコル・フォアグレン**: はいといいえです。私は、まずしっかりとした箇条書きリスト、少なくとも下書きから始めるのが最善だと気づいています。その後、それを自分の声に合うように調整し、見落としている点や、言葉は使っているが意図とは全く異なる部分を補うよう努めています。そして、いくつかの作業を行うことが非常に役立つことも発見しました。つまり、自分が気に入ったメッセージを確立したら、それをもとに草案を作成できるようになり、さらに質問を投げかけることができます。「何を考慮し忘れたのか？」「どこに穴があるのか？」「どのような批判に備えるべきか？」「私の支持者となりそうな人は誰で、反対者となりそうな人は誰か？」 そして、それをコミュニケーション戦略の構築にも活用できます。私たちは歴史的にコミュニケーションが苦手ですが、これを製品として扱う必要があります。『フィールド・オブ・ドリームス』のように「作ればみんな来る」という考えは通用しません。また、無理やり使わせることもできません。開発者は強制されたものは使いません。CI/CD ツールでも同じことが起こりました。誰もが自分たちの Jenkins を立ち上げてしまったのです。そこで私はこう言います。「この内容をエグゼクティブ層向けにどう枠組み立てればよいか？彼らの主要な課題はこれです。彼らが関心を持つのはこれです。エンジニアリングディレクター層向けにはどう枠組み直せばよいでしょうか？個人貢献者（IC）向けには、彼らが何を重視するかを踏まえて再構成してください」 したがって、これは異なる聴衆にどのように伝えるかを考える際に役立ちます。私は過去にもこの手法を行ってきました。ツールとして愛用しているのは、多くの場合、私の考えと合致するからです。しかし、たまに私が気づかなかった何かを拾い上げたり、新しいアイデアを提案したりすることもあります。その点で、非常にスピードアップできます。 **トーマス・ベッツ**: はい、LLM（大規模言語モデル）が私の盲点を特定してくれるときは特に役立ちます。そして、それを記録し続けることで追跡可能にし、「ああ、確かに X についてや誰かの視点について考えるのを忘れがちだ」と言われると、本当に「これも話す必要があることを忘れないでね」と教えてくれるのが素晴らしいです。 **ニコル・フォアグレン**: はい、ここで一つ付け加えるなら、数回反復するうちに、少し混乱し始める傾向があります。たとえ「いや、戻って」「いいえ、それは私が求めたことではない」と指示しても、あるいは順調に進んでいる場合でも、基本的にはキャッシュをクリアして、そのチャットを終了し、新しいチャットを開始するのが非常に役立つことがあります。現在、多くの世代が文脈の一部を追跡していますが、もし文脈をリセットしたいのであれば、新鮮な視点を得ることができます。 ## 即座に DevEx（開発者体験）への影響を与えるための実践的な出発点 [36:31] **トーマス・ベッツ**: はい、その忘却の力を借りてリセットして始めるのは素晴らしいですね。では、即座にインパクトを与えたいリスナーの方のために、個人貢献者（IC）でもチームリーダーでも組織内の上位リーダーでも、すぐに始められる小さな変化として、複合的な開発者体験（DevEx）の改善につながるものをお勧めしますか？ **ニコル・フォアグレン**: もちろんです。ほぼ誰でもできる最善の方法は、開発者に直接声をかけることです。同僚でもよいですし、優先度の高いチームのメンバーに「仕事はどうですか？」と聞いてみてください。あるいは、もう少し焦点を絞った質問も効果的です。「あなたの仕事の最も難しい部分はどこですか？」「いつもイライラして怒っているのはどんなことですか？」「あなたにとって多くの作業を可能にする鍵となるものは何ですか？」。これだけで、現状についてのイメージが得られ、さらに他の 2〜3 人に同じように聞いて、共通点がないか確認できます。また、これまでに行われた作業や既存のドキュメントがあるかも確認してみましょう。大規模言語モデル（LLM）もこの目的に非常に役立ちます。 大量の情報を入力させて要約させることで、過去に何が行われ、何が試され、何が成功し、何が失敗したかを浮き彫りにできます。また、「これまでそう言われてきたが、一度も成功したことがない」という暗黙の前提がある場合もあります。「だからやめよう、うまくいかないだろう」となるかもしれませんが、実はそれが真の問題であり、人々が過去の成果に固定観念を持っているため、別の表現方法で捉え直す必要があるのかもしれません。 ## DevEx の未来：進化し続ける開発者の役割 [37:47] **トーマス・ベッツ**: さて、これはあなたが何冊も著書を書かれているほど熱心に語られるテーマですが、DevEx の未来について何があなたを興奮させるのでしょうか？今後数年間でこの分野がどのように進化していくとお考えですか？ **ニコル・フォアグレン**: ああ、ここには素晴らしいことがたくさんあります。正直に言って、私が最も興奮するのは、エンジニアや開発者の役割が進化している姿を見ることです。私たちは長年にわたりその変化を目にしてきました。アセンブリ言語を記述していた初期の時代にはメインフレームがあり、その後クラウドが登場しました。多くの波が押し寄せましたが、新しい技術が登場するたびに、歴史的に行ってきた作業の多くが自動化されるようになります。しかし、それがもたらしたのは、私たちが解決できる新たな問題や、取り組むことができる新たな創造的なアプローチについて考えるための扉を開いたことです。そこで、この変化が再び起こるのを観察することに興奮を覚えていますし、私の職業人生の中で少なくとも数回のそのような転換点を目にすることができたのは、とても幸運だったと感じています。 **トーマス・ベッツ**: はい、その枠組みは素晴らしいと思います。アセンブリ言語を書いたりパンチカードを使ったりしないことを嬉しく思いますが、私が高レベルで作業できる基盤を築いてくれた人々には感謝しています。つまり、私はあなたのビジネス課題を解決しているのですから。 **Nicole Forsgren**: 私の最初の仕事はメインフレームでした。その仕事をとても愛していました。その一部も特に好きでした。私が携わっていた言語の一つでは、テキストレイアウトがまだパンチカードに収まるように非常に制限されていました。なぜなら、それが始まりだったからです。そのため、時々あの頃の作業を懐かしんで冗談めかして言うこともありますが、楽しかったし、グリーンスクリーンはいつも最高でした。私たちが成し遂げてきた進歩と、これから向かう先について本当に興奮しています。 ## Closing [39:20] **Thomas Betts**: はい。では、これで締めくくりましょう。あなたの新書『Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era』ですね。共著者はアビ・ノダさんですか？ **Nicole Forsgren**: はい。私のウェブサイトと彼のウェブサイトの両方に、書籍または書籍サイトへのリンクがあります。そこには約 100 ページのワークブックがリンクされており、それらは無料です。これらは書籍に付随するものです。私たちは、できるだけ多くの人にツールを提供しようと思いました。もし今すぐ書籍を購入できない場合や、購入したくない場合は、ぜひワークブックを試し始めてください。すでにそこに十分な文脈があるため、そこから多くのことを実現できます。 **Thomas Betts**: 素晴らしいですね。では、ニコールさん、今日お越しいただき改めてありがとうございます。非常に素晴らしい議論でした。 **Nicole Forsgren**: すばらしいです。本当にありがとうございました。お会いできて嬉しいです。 **Thomas Betts**: そしてリスナーの皆さん、またすぐに InfoQ ポッドキャストの別のエピソードでお会いできることを願っています。 ## About the Author ## ニコール・フォアスゲン ドクター、ニコール・フォアスゲンは Google Cloud で研究と戦略に従事しています。彼女は「Shingo Publication Award」を受賞した書籍『Accelerate: The Science of Lean Software and DevOps』の共著者であり、これまでに実施された最も大規模な DevOps 調査の主要研究者として知られています。彼女は Google への売却を含む成功した起業家、教授、パフォーマンスエンジニア、そしてシステム管理者としても活躍してきました。彼女の業績は複数の査読付き学術誌に掲載されています。 さらに表示する表示を消す ポッドキャストの最新情報は、当社の [RSS フィード](http://www.infoq.com/podcasts/frictionless-devex/) を通じてご確認いただけます。また、以下のプラットフォームでもご利用可能です。 [SoundCloud](https://soundcloud.com/infoq-channel) [Apple Podcasts](https://itunes.apple.com/gb/podcast/the-infoq-podcast/id1106971805?mt=2) [Spotify](https://open.spotify.com/show/4NhWaYYpPWgWRDAOqeRQbj) [Overcast](https://overcast.fm/itunes1106971805/the-infoq-podcast) そして [YouTube](https://youtube.com/playlist?list=PLndbWGuLoHeZLVC9vl0LzLvMWHzpzIpir&si=Kvb9UpSdGzObuWgg)。 このページからは、録音されたショーノートにもアクセスできます。すべてにクリック可能なリンクが含まれており、そこからオーディオの該当部分へ直接移動することができます。

ポッドキャスト: [ビデオポッドキャスト] ニコール・フォーシュグレンと考える摩擦のない開発者体験

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト