概要

この記事では、2022年6月に実施されたGo開発者調査の結果を共有します。Goチームを代表して、ジェネリクス、セキュリティツール、ワークスペースなど、Go 1.18で導入された新機能を使った経験についてお聞かせいただいた5,752名の皆様に感謝申し上げます。皆様のおかげで、開発者がこの機能をどのように発見し、使用しているかについて理解を深めることができ、この記事で説明するように、さらなる改善のための有用な洞察が得られました。ありがとうございました！💙

主な調査結果

• ジェネリクスは急速に採用されています。回答者の大部分は、ジェネリクスがGo 1.18リリースに含まれていることを認識しており、約4人に1人の回答者がすでにGoコードでジェネリクスを使い始めていると回答しました。ジェネリクス関連のフィードバックで最も多かったのは「ありがとう！」でしたが、開発者はすでに初期のジェネリクス実装のいくつかの制限に直面していることは明らかです。
• ファジングはほとんどのGo開発者にとって新しいものです。Goの組み込みファズテストの認識はジェネリクスよりもはるかに低く、回答者はファズテストを使用することについて、いつ、なぜ使用するのかについて、はるかに不確実性を持っていました。
• サードパーティの依存関係は、セキュリティ上の最大の懸念事項です。既知の脆弱性を持つ依存関係を回避することが、回答者にとって最もセキュリティ関連の課題でした。より広く言えば、セキュリティ作業は計画外で報われないことが多いため、ツールは開発者の時間と注意を尊重する必要があります。
• 新機能の発表方法を改善できます。無作為に抽出された参加者は、Goブログを通じて調査を見つけた人々よりも、最近のGoツールのリリースを知らない傾向がありました。これは、Goエコシステムの変化を伝えるためにブログ記事以外にも目を向けるか、これらの記事をより広く共有するための努力を拡大する必要があることを示唆しています。
• エラー処理は依然として課題です。ジェネリクスがリリースされた後、Goを使用する際の回答者の最大の課題はエラー処理に移行しました。しかし、全体として、Goに対する満足度は依然として非常に高く、回答者がGoをどのように使用しているかについては、大きな変化は見られませんでした。

これらの結果の読み方

この記事全体を通して、調査回答のグラフを用いて、調査結果の裏付けとなる証拠を提示しています。これらのグラフはすべて同様の形式を使用しています。タイトルは、調査回答者が見た正確な質問です。特に明記しない限り、質問は多肢選択式で、参加者は1つの回答しか選択できませんでした。各グラフのサブタイトルには、質問が複数の回答選択肢を許可していたか、または多肢選択式の質問ではなく自由形式のテキストボックスであったかが示されています。自由形式のテキスト回答のグラフについては、Goチームのメンバーがすべての回答を読み、手動で分類しました。多くの自由形式の質問は多種多様な回答を引き出しましたが、グラフのサイズを適切に保つために、上位10テーマに凝縮し、追加のテーマはすべて「その他」にまとめました。

読者が各調査結果の根拠となる証拠の重みを理解できるように、回答の95%信頼区間を示すエラーバーを含めています。バーが狭いほど、信頼度が高くなります。場合によっては、2つ以上の回答にエラーバーが重複していることがありますが、これはそれらの回答の相対的な順序が統計的に意味がない（つまり、回答は実質的に同点である）ことを意味します。各グラフの右下には、「n = [回答者数]」という形式で、グラフに含まれる回答者の数が表示されています。

調査方法に関する注意点

ほとんどの調査回答者は「自己選択」して調査に参加しました。つまり、Goブログ、Twitterの@golang、またはその他のGo関連のソーシャルチャネルで調査を見つけました。このアプローチの潜在的な問題は、これらのチャネルをフォローしていない人々は調査について知る可能性が低く、熱心にフォローしている人々とは異なる回答をする可能性があることです。回答者の約3分の1は無作為に抽出されました。これは、VS Codeでプロンプトを見てから調査に回答したことを意味します（2022年6月1日から6月21日までVS Code Goプラグインを使用していたすべての人が、この無作為なプロンプトを受け取る確率が10%でした）。この無作為に抽出されたグループは、これらの調査結果をGo開発者のより大きなコミュニティに一般化するのに役立ちます。ほとんどの調査質問では、これらのグループ間で意味のある違いは見られませんでしたが、重要な違いがあったいくつかのケースでは、読者は回答を「無作為サンプル」と「自己選択」グループに分類したグラフを見ることができます。

ジェネリクス

Go 1.18が型パラメータ（より一般的にはジェネリクスと呼ばれる）のサポートを伴ってリリースされた後、ジェネリクスの初期の認識と採用がどのようなものであったかを理解し、ジェネリクスを使用する際の一般的な課題や障害を特定したいと考えました。

調査回答者の大多数（86%）は、Go 1.18リリースの一部としてジェネリクスが出荷されたことをすでに認識していました。ここでは単純な過半数を期待していましたが、予想よりもはるかに高い認識度でした。また、回答者の約4分の1がGoコードでジェネリクスを使い始めており（26%）、そのうち14%は本番環境またはリリースされたコードですでにジェネリクスを使用していると回答しました。回答者の過半数（54%）はジェネリクスを使用することに反対していませんでしたが、現時点では必要性を感じていませんでした。また、回答者の8%がGoでジェネリクスを使いたいと考えていましたが、現在何らかの理由でブロックされていることがわかりました。

一部の開発者がジェネリクスを使用できない原因は何だったのでしょうか？回答者の大多数は、次の2つのカテゴリのいずれかに分類されました。まず、回答者の30%は、パラメーター化されたメソッド、改善された型推論、型の切り替えなど、ジェネリクスの現在の実装の制限に達したと述べました。回答者は、これらの問題がジェネリクスの潜在的な使用例を制限したり、ジェネリックコードを不必要に冗長に感じさせたりすると述べました。2番目のカテゴリは、まだジェネリクスをサポートしていないものに依存することでした。リンターが採用を妨げる最も一般的なツールでしたが、このリストには、組織が以前のGoリリースにとどまっていることや、Go 1.18パッケージをまだ提供していないLinuxディストリビューションに依存していることなども含まれていました（26%）。急な学習曲線や役立つドキュメントの不足は、回答者の12%が挙げました。これらの主要な問題に加えて、以下のグラフに示すように、回答者は、あまり一般的ではない（しかし依然として意味のある）さまざまな課題について教えてくれました。仮説に焦点を当てることを避けるため、この分析には、すでにジェネリクスを使用していると述べた人々、またはジェネリクスを使用しようとしたが何らかの理由でブロックされた人々のみが含まれています。

ジェネリクスの使用を試みた調査回答者には、追加のフィードバックを共有するよう求めました。心強いことに、回答者の10人に1人が、ジェネリクスによってすでにコードが簡素化されたか、コードの重複が少なくなったと述べました。最も一般的な回答は、「ありがとう！」または一般的な肯定的な感情のバリエーションでした（43%）。比較すると、否定的な反応または感情を示したのは回答者のわずか6%でした。上記の「最大の課題」の質問からの調査結果を反映して、回答者のほぼ3分の1がGoのジェネリクス実装の制限にぶつかったと述べました。Goチームは、これらの制限の一部を緩和できるかどうか、またどのように緩和できるかを決定するのに役立つように、この結果のセットを使用しています。

セキュリティ

2020年のSolarWinds侵害を受けて、安全なソフトウェアを開発する実践は新たな注目を集めています。Goチームはこの分野での作業を優先しており、これにはソフトウェア部品表（SBOM）の作成ツール、ファズテスト、そして最近では脆弱性スキャンが含まれます。これらの取り組みを支援するため、この調査ではソフトウェア開発のセキュリティ実践と課題についていくつかの質問を行いました。特に理解したかったのは、次の点です。

• Go開発者は現在どのようなセキュリティツールを使用していますか？
• Go開発者はどのように脆弱性を発見し、解決していますか？
• 安全なGoソフトウェアを作成する上での最大の課題は何ですか？

私たちの結果は、静的分析ツールが広く使用されている（回答者の65%）一方で、現在それを使用して脆弱性を発見している（35%）またはその他の方法でコードのセキュリティを向上させている（33%）回答者は少数派であることを示唆しています。回答者によると、セキュリティツールはCI/CD時に最も頻繁に実行され（84%）、開発者が開発中にこれらのツールをローカルで実行していると答えたのは少数でした（22%）。これは、私たちのチームが実施した追加のセキュリティ研究と一致しており、CI/CD時のセキュリティスキャンは望ましい最終防衛策であるものの、開発者はこれを最初の通知には遅すぎると考えることが多く、依存関係が脆弱である可能性を構築する前に知るか、PRに対して一連の追加テストを実行するためにCIを待たずにバージョンアップが脆弱性を解決したことを確認したいと考えていることがわかりました。

また、回答者に安全なソフトウェアを開発する上での最大の課題について尋ねました。最も広範な課題は、サードパーティライブラリのセキュリティ評価でした（回答者の57%）。これは、脆弱性スキャナー（GitHubのDependabotやGoチームのgovulncheckなど）が対処できるテーマです。その他の主な課題は、追加のセキュリティツールが必要であることを示唆しています。回答者は、コード作成時にベストプラクティスを一貫して適用することが難しいこと、および結果として生成されたコードに脆弱性がないことを検証することが難しいと述べました。

アプリケーションセキュリティを高めるもう1つのアプローチであるファズテストは、ほとんどの回答者にとってまだかなり新しいものでした。仕事でそれを使用していると答えたのはわずか12%で、Goの組み込みファジングツールを採用していると答えたのは5%でした。ファジングの使用を困難にしているものについて尋ねる自由回答形式のフォローアップ質問では、主な理由は技術的な問題ではなく、上位3つの回答は、ファズテストの使い方がわからないこと（23%）、ファジングやセキュリティ全体にもっと時間を割く時間がないこと（22%）、および開発者がファズテストを使用したい理由と時期がわからないこと（14%）でした。これらの調査結果は、ファズテストの価値、何をファズテストすべきか、そしてそれをさまざまなコードベースに適用する方法について、まだコミュニケーションの努力が必要であることを示しています。

脆弱性の検出と解決に関する一般的なタスクをよりよく理解するため、過去1年間にGoコードまたはその依存関係に脆弱性があったかどうかを回答者に尋ねました。脆弱性があったと答えた人には、最新の脆弱性がどのように発見されたか、どのように調査および/または解決されたか、そしてプロセス全体で最も困難だったことは何かを尋ねる質問を続けました。

まず、脆弱性スキャンが効果的であるという証拠が見つかりました。回答者の4分の1が、サードパーティの依存関係のいずれかに脆弱性を発見したと述べました。しかし、回答者の約3分の1しか脆弱性スキャンを全く使用していなかったことを思い出してください。何らかの脆弱性スキャナーを実行していると答えた人々の回答を見ると、この割合はほぼ2倍になり、25%から46%に増加します。依存関係やGo自体に存在する脆弱性の他に、回答者の12%は、自身のコードに脆弱性を発見したと述べました。

回答者の過半数（65%）が、セキュリティスキャナーを通じて脆弱性を発見したと述べました。回答者が最も頻繁に挙げた単一のツールはGitHubのDependabot（38%）で、他のすべての脆弱性スキャナーを合わせたもの（27%）よりも頻繁に言及されました。スキャンツールに次いで、脆弱性を発見する最も一般的な方法は、リリースノートやCVEなどの公開レポート（22%）でした。

回答者が脆弱性を認識した後、最も一般的な解決策は、脆弱な依存関係をアップグレードすることでした（67%）。脆弱性スキャナーの使用についても言及した回答者（サードパーティの依存関係の脆弱性について議論している参加者の代理）では、この割合は85%に増加しました。回答者の3分の1未満がCVEまたは脆弱性レポートを読んだと述べ（31%）、自分のソフトウェアが脆弱性の影響を受けたかどうか（およびどのように影響を受けたか）を理解するための詳細な調査に言及した回答者はわずか12%でした。

脆弱性がコード内で到達可能であったか、またはそのサービスに与える可能性のある影響について調査を行ったと答えた回答者がわずか12%であったことは驚きでした。これをよりよく理解するために、セキュリティ脆弱性への対応で最も困難だったことについて回答者が述べたことについても調べました。彼らは、依存関係の更新が何も壊さないことを確認することから、go.modファイルを介して間接的な依存関係を更新する方法を理解することまで、ほぼ同じ割合でいくつかの異なるトピックについて説明しました。このリストには、脆弱性の影響や根本原因を理解するために必要な調査のタイプも含まれています。しかし、これらの調査を行ったと答えた回答者にのみ焦点を当てると、明確な相関関係が見られます。脆弱性の潜在的な影響について調査を行ったと答えた回答者の70%は、それをこのプロセスの最も困難な部分であると述べました。その理由には、タスクの難しさだけでなく、それがしばしば計画外で報われない作業であったという事実も含まれていました。

Goチームは、アプリケーションが脆弱な依存関係をどのように使用しているかを理解する必要がある、より詳細な調査が、組織に対する脆弱性によるリスクを理解するため、またデータ侵害やその他のセキュリティ侵害が発生したかどうかを理解するために不可欠であると考えています。したがって、私たちはgovulncheckを設計しました。これは、脆弱性が呼び出された場合にのみ開発者に警告し、コード内の脆弱な関数を使用している正確な場所を開発者に示します。これにより、開発者がアプリケーションにとって真に重要な脆弱性を迅速に調査することが容易になり、この分野での計画外の作業全体が削減されることを期待しています。

ツール

次に、ツールに焦点を当てた3つの質問を調査しました。

• 前回の調査以降、エディターの状況は変化しましたか？
• 開発者はワークスペースを使用していますか？もしそうなら、使い始める際にどのような課題に遭遇しましたか？
• 開発者は内部パッケージのドキュメントをどのように扱っていますか？

VS Codeは調査回答者の間で人気が高まり続けているようで、Goコードの優先エディターであると答えた回答者の割合は2021年の42%から45%に増加しました。最も人気のある2つのエディターであるVS CodeとGoLandは、小規模企業と大規模企業の間で人気に違いは見られませんでしたが、趣味で開発を行っている人はGoLandよりもVS Codeを好む傾向がありました。この分析には、VS Codeの無作為抽出された回答者は含まれていません。調査への招待を受けた人々は、招待を配布するために使用されたツールを好むと予想され、まさにその通りでした（無作為抽出された回答者の91%がVS Codeを好みました）。

2021年にVS CodeのGoサポートをgopls言語サーバー経由で強化するように切り替わって以来、Goチームはgoplsに関連する開発者の不満点を理解することに関心を持ってきました。現在goplsを使用している開発者から健全な量のフィードバックを受け取っていますが、リリース直後に多くの開発者がgoplsを無効にしたのではないかと疑問に思っていました。もしそうだとすると、特に問題のあるユースケースに関するフィードバックを聞き逃している可能性があります。この質問に答えるために、goplsをサポートするエディターを好むと答えた回答者に、goplsを使用しているかどうか尋ねたところ、無効にしたと答えたのはわずか2%でした。特にVS Codeでは、この割合は1%にまで低下しました。これにより、代表的な開発者グループからフィードバックを聞き取っているという自信が高まります。goplsでまだ解決されていない問題がある読者は、GitHubに इश्यूを提出してお知らせください。

ワークスペースに関して言えば、多くの人がこの調査を通じて初めてGoのマルチモジュールワークスペースのサポートについて知ったようです。VS Codeのランダムなプロンプトを通じて調査を知った回答者は、以前ワークスペースについて聞いたことがないと答える可能性が特に高く（無作為抽出された回答者の53%に対し、自己選択した回答者の33%）、この傾向はジェネリクスの認識についても観察されました（ただし、これは両方のグループで高く、Go 1.18にジェネリクスが導入されたことを認識していた自己選択した回答者は93%に対し、無作為抽出された回答者は68%でした）。一つの解釈として、Goブログや既存のソーシャルメディアチャネルを通じて現在到達できていないGo開発者の大規模な視聴者がいることが挙げられます。これらは伝統的に、新しい機能を共有するための主要なメカニズムでした。

回答者の9%がワークスペースを試したことがあり、さらに5%が試したいが何らかの理由でブロックされていることがわかりました。回答者は、Goワークスペースを使用しようとする際のさまざまな課題について議論しました。ドキュメントの不足とgo workコマンドからの役立つエラーメッセージが上位を占め（21%）、続いて既存のリポジトリのリファクタリングなどの技術的な課題（13%）が挙げられました。セキュリティセクションで議論された課題と同様に、このリストにも「時間不足/優先順位が低い」という項目が見られます。これは、ワークスペースを理解して設定するためのハードルが、提供されるメリットと比較してまだ少し高すぎることを意味すると解釈しています。おそらく、開発者がすでに回避策を講じていたためでしょう。

Goモジュールのリリース前、組織は内部ドキュメントサーバー（godoc.orgを動かしていたものなど）を運用して、従業員にプライベートな内部Goパッケージのドキュメントを提供することができました。pkg.go.devでもこれは変わりませんが、そのようなサーバーをセットアップすることは以前よりも複雑になりました。このプロセスを容易にするために投資すべきかどうかを理解するため、回答者に今日の内部Goモジュールのドキュメントをどのように見ているか、そしてそれが彼らの好む作業方法であるかどうかを尋ねました。

結果によると、今日、内部Goドキュメントを見る最も一般的な方法はコードを読むこと（81%）であり、回答者の約半分はこの方法に満足していましたが、かなりの割合が内部ドキュメントサーバーを希望していました（39%）。また、そのようなサーバーを構成・保守する可能性が最も高いのは誰か尋ねたところ、回答者は2対1の差で、専門のITサポートまたは運用チームのメンバーではなく、ソフトウェアエンジニアだと考えていました。これは、ドキュメントサーバーがターンキーソリューションであるか、少なくとも（例えば昼休みの間に）1人の開発者がすぐに稼働させられるほど簡単であるべきであることを強く示唆しています。これは、この種の作業が開発者のすでに満杯の仕事リストにさらなる責任を追加するという理論に基づいています。

ヒアリング対象者

全体として、回答者のデモグラフィックおよびファーモグラフィックは、2021年の調査以降、実質的に変化していませんでした。回答者の過半数（53%）はGoの使用経験が2年以上であり、残りはGoコミュニティへの参加が新しい人々でした。回答者の約3分の1は中小企業（従業員100人未満）に勤務し、4分の1は中規模企業（従業員100～1,000人）に勤務し、4分の1は大企業（従業員1,000人以上）に勤務していました。昨年と同様に、VS Codeのプロンプトが北米とヨーロッパ以外の地域での調査参加を促すのに役立ったことがわかりました。

回答者のGoの使用方法

前のセクションと同様に、回答者のGoの使用方法に関して、統計的に有意な前年比の変化は見られませんでした。最も一般的な2つのユースケースは、API/RPCサービスの構築（73%）とCLIの作成（60%）のままでした。線形モデルを使用して、Goの使用期間と構築しているものの種類との間に何らかの関係があるかどうかを調査しました。Go経験が1年未満の回答者は、このグラフの下半分にあるもの（GUI、IoT、ゲーム、ML/AI、またはモバイルアプリ）を構築する可能性が高いことがわかり、これらの分野でGoを使用することに関心があることを示唆しています。しかし、1年間の経験後に急激に減少するということは、これらの分野でGoを扱う際に開発者が重大な障壁にぶつかることも意味しています。

Goでの開発時、回答者の大多数はLinux（59%）またはmacOS（52%）を使用しており、圧倒的多数がLinuxシステムにデプロイしています（93%）。今回の調査では、Windows Subsystem for Linux（WSL）での開発という回答選択肢を追加したところ、回答者の13%がGoでの作業時にこれを使用していることがわかりました。

感情と課題

最後に、過去1年間のGoに対する全体的な満足度または不満度、およびGoを使用する際に直面する最大の課題について回答者に尋ねました。回答者の93%が「ある程度」（30%）または「非常に」（63%）満足していると回答し、これは2021年のGo開発者調査で満足していると回答した92%と統計的に有意な差はありませんでした。

何年もの間、Goを使用する際の最も一般的に議論される課題として常にジェネリクスが挙げられてきましたが、Go 1.18での型パラメータのサポートにより、ついに新しい最大の課題が生まれました。それは、古くからの友人であるエラー処理です。確かに、エラー処理は、特定のドメイン向けのライブラリの不足または未熟さ、開発者がベストプラクティスを学び実装するのを助けること、および列挙型やより関数型プログラミング構文のサポートなど、型システムへの他の改訂を含むいくつかの他の課題と統計的に同点です。ジェネリクス後には、Go開発者が直面する非常に長い課題の尾が続いているようです。

調査方法

この調査は、2022年6月1日にgo.dev/blogとTwitterの@golangを通じて公に発表されました。また、6月1日から21日の間に、Goプラグインを通じてVS Codeユーザーの10%にランダムにプロンプトを表示しました。調査は6月22日に終了し、部分的な回答（つまり、調査を開始したが終了しなかった人々）も記録されました。特に迅速に調査を完了した（30秒未満）または複数選択式の質問ですべての回答選択肢をチェックする傾向があった回答者のデータは除外しました。これにより、5,752件の回答が残りました。

回答者の約3分の1は、ランダム化されたVS Codeプロンプトから来ており、このグループは、GoブログやGoのソーシャルメディアチャネルを通じて調査を見つけた人々よりもGoの経験が少ない傾向がありました。線形およびロジスティックモデルを使用して、これらのグループ間の見かけ上の違いが、この経験の違いによってよりよく説明されるかどうかを調査しました。ほとんどの場合、そうでした。例外はテキストに記載されています。

今年は、Stack Overflow、JetBrainsなどの開発者調査と同様に、生データもコミュニティと共有することを強く望んでいました。残念ながら、最近の法的指導により、現時点ではそれができませんが、これに取り組んでおり、次回のGo開発者調査の生データを共有できることを期待しています。

まとめ

今回のGo開発者調査は、Go 1.18リリースからの新機能に焦点を当てました。ジェネリクスの採用は順調に進んでおり、開発者は現在の実装のいくつかの制限にすでに直面していることがわかりました。ファズテストとワークスペースの採用は遅れていますが、これは主に技術的な理由ではなく、主な課題は、いつ、どのようにそれらを使用するかを理解することでした。これらのトピックに集中する開発者の時間の不足も課題であり、このテーマはセキュリティツールにも波及していました。これらの調査結果は、Goチームが次の取り組みの優先順位を決定し、将来のツールの設計アプローチに影響を与えます。

Go開発者調査にご参加いただき、ありがとうございました。皆様にとって有益で興味深いものであったことを願っています。最も重要なことは、長年にわたり私たちの調査に回答してくださったすべての方々に感謝申し上げます。皆様のフィードバックは、Go開発者がどのような制約の下で働き、どのような課題に直面しているかを理解するのに役立っています。これらの経験を共有することで、皆様はすべての人にとってGoエコシステムを改善するのに貢献しています。世界中のGopherを代表して、皆様に感謝申し上げます！