Goブログ

Go開発者調査2022年第2四半期結果

Todd Kulesza
2022年9月8日

概要

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

主な調査結果

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

これらの結果の読み方

この投稿全体を通して、調査回答のチャートを使用して、調査結果の証拠を提示します。これらのチャートはすべて同様の形式を使用しています。タイトルは、調査回答者が見た正確な質問です。特に記載がない限り、質問は複数選択式で、参加者は単一の回答しか選択できませんでした。各チャートの副題には、質問が複数の回答を許可していたか、複数選択式ではなく、自由記述のテキストボックスであったかが記載されています。自由記述のテキスト回答のチャートについては、Goチームのメンバーがすべての回答を読み、手動で分類しました。多くの自由記述の質問には、さまざまな回答がありました。チャートのサイズを妥当なものにするために、最大10個の主要テーマに凝縮し、その他のテーマはすべて「その他」にまとめています。

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

方法に関する注記

ほとんどの調査回答者は、調査への参加を「自己選択」しました。つまり、Goブログ、@golang on Twitter、またはその他のGo関連のソーシャルチャネルで見つけました。このアプローチの潜在的な問題は、これらのチャネルをフォローしていない人は調査について知る可能性が低く、これらのチャネルを密接にフォローしている人とは異なる回答をする可能性があることです。約3分の1の回答者はランダムにサンプリングされました。つまり、VS Codeでプロンプトを見た後に調査に回答しました（2022年6月1日～6月21日の間にVS Code Goプラグインを使用していた全員が、このランダムなプロンプトを受け取る確率が10％でした）。このランダムにサンプリングされたグループは、これらの調査結果をより広範なGo開発者コミュニティに一般化することを支援します。ほとんどの調査質問では、これらのグループ間に意味のある違いは見られませんでしたが、重要な違いのある少数のケースでは、読者は「ランダムサンプル」と「自己選択」のグループに回答を分類したチャートを確認できます。

ジェネリクス

型パラメーター（一般的に_ジェネリクス_と呼ばれます）のサポートを含むGo 1.18がリリースされた後、ジェネリクスに関する初期の認知度と採用状況、ならびにジェネリクス使用における一般的な課題や障害を理解したいと考えました。

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

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

また、ジェネリクスを使用しようとした調査回答者に追加のフィードバックを共有してもらいました。励みになることに、10人に1人の回答者が、ジェネリクスが既にコードを簡素化したり、コードの重複を減らしたりしたと述べています。最も一般的な回答は、「ありがとうございます！」のバリエーションや一般的な肯定的な感情（43％）でした。比較のために、回答者のわずか6％だけが否定的な反応や感情を示しました。上記の「最大の課題」の質問の結果を反映して、回答者の約3分の1がGoのジェネリクス実装の限界に達したことを議論しました。Goチームは、この結果セットを使用して、これらの制限の一部を緩和できるかどうか、またはどのように緩和できるかを判断しています。

セキュリティ

2020年のSolarWinds事件の後、安全なソフトウェア開発の実践は改めて注目を集めています。ソフトウェア部品表（SBOM）、ファズテスト、そして最近では脆弱性スキャンを作成するためのツールを含む、この分野での作業をGoチームは優先しています。これらの取り組みを支援するために、この調査では、ソフトウェア開発のセキュリティプラクティスと課題に関するいくつかの質問をしました。具体的には、以下を理解したいと考えました。

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

私たちの調査結果によると、静的解析ツールは広く使用されています（回答者の65％）が、脆弱性を見つけるために現在使用している回答者は少数です（35％）、またはコードセキュリティを向上させるために使用している回答者も少数です（33％）。回答者によると、セキュリティツールは、ほとんどの場合、CI/CD時に実行され（84％）、開発者が開発中にローカルでこれらのツールを実行することは少数です（22％）。これは、私たちのチームが実施した追加のセキュリティ調査と一致しており、その調査では、CI/CD時のセキュリティスキャンは望ましいバックストップであることがわかりましたが、開発者は多くの場合、これが最初の通知には遅すぎると考えていました。依存関係に脆弱性がある可能性があることを_構築する前_に知りたい、またはバージョン更新によって脆弱性が解決されたことを、CIで追加のテストの完全なバッテリーを実行するのを待つことなく確認したいと考えていました。

また、安全なソフトウェアの開発に関する最大の課題についても回答者に尋ねました。最も広範囲にわたる困難は、サードパーティライブラリのセキュリティを評価することでした（回答者の57％）。これは、GitHubのdependabotやGoチームのgovulncheckなどの脆弱性スキャナーが対処できるトピックです。その他の主な課題は、追加のセキュリティツールの機会を示唆しています。回答者によると、コードを記述しながらベストプラクティスを常に適用することや、結果として得られたコードに脆弱性がないことを検証することが困難です。

アプリケーションのセキュリティを向上させるためのもう1つのアプローチであるファズテストは、ほとんどの回答者にとってまだかなり新しいものでした。職場で使用していると回答したのは12％だけで、Goの組み込みファズテストツールを採用したと回答したのは5％でした。ファズテストの使用を困難にしている理由を尋ねる自由記述式のフォローアップ質問では、主な理由は技術的な問題ではありませんでした。上位3つの回答では、ファズテストの使用方法が理解できない（23％）、ファズテストやセキュリティ全般に時間を割くことができない（22％）、および開発者がファズテストを使用したい理由と時期を理解できない（14％）ことが議論されました。これらの調査結果から、ファズテストの価値、ファズテストを行うべきもの、およびさまざまなコードベースへの適用方法について、さらに取り組む必要があることがわかります。

脆弱性の検出と解決に関する一般的なタスクをより深く理解するために、回答者に過去1年間でGoコードまたはその依存関係に脆弱性を見つけたことがあるかどうかを尋ねました。 見つけた回答者には、最新の脆弱性の発見方法、調査・解決方法、そしてその過程で最も困難だった点について、さらに質問を行いました。

まず、脆弱性スキャンが効果的であるという証拠が見つかりました。回答者の4分の1が、サードパーティの依存関係の1つに脆弱性を見つけたと言っていました。ただし、脆弱性スキャンを使用していた回答者は約3分の1に過ぎませんでしたが、何らかの脆弱性スキャナーを実行したと回答した人の回答を見ると、この割合は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年にgopls言語サーバーを介してVS CodeのGoサポートを強化して以来、Goチームはgoplsに関連する開発者のペインポイントを理解することに関心を持っていました。現在goplsを使用している開発者から多くのフィードバックを受けていますが、リリース直後に多くの開発者がgoplsを無効にしたかどうか疑問に思っていました。これは、特に問題のあるユースケースに関するフィードバックを聞いていない可能性があることを意味します。この質問に答えるために、goplsをサポートするエディターを好むと回答した回答者に、goplsを使用しているかどうかを尋ねたところ、わずか2％がそれを無効にしたと言っていました。特にVS Codeの場合、これは1％に減少しました。これにより、代表的な開発者グループからのフィードバックを聞いているという確信度が高まりました。goplsで未解決の問題が残っている読者は、GitHubで問題を報告してください。

ワークスペースに関しては、多くの人がこの調査を通じてGoのマルチモジュールワークスペースのサポートについて初めて知ったようです。VS Codeのランダムプロンプトを通じて調査を知った回答者は、以前ワークスペースについて聞いたことがないと答える可能性が特に高かったです（ランダムにサンプリングされた回答者の53％に対し、自己選択した回答者の33％）。ジェネリックスの認知度についても同様の傾向が見られました（ただし、両方のグループでより高く、自己選択した回答者の93％がGo 1.18でジェネリックスが導入されたことを知っていたのに対し、ランダムにサンプリングされた回答者の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エコシステム全体を改善するのに貢献しています。世界中のGophersを代表して、感謝申し上げます！