Grafana LabsがMeetupを開催。社内での開発体制やオープンソースを維持する苦労などについて語った

Grafana Labsが開催したObservabilityCON ON THE ROAD Tokyoの翌日、2026年3月18日に都内でGrafanaのコミュニティ向けのMeetupが開催された。ここでは開発部門のトップ、VP of EngineeringのDee Kitchen氏とOpenTelemetryのコントリビュータであるTed Young氏のセッションを紹介する。

Ted Young氏についてはGrafanaCON 2025でもインタビューを行っているので参照してほしい。

●参考：GrafanaCON 2025、Grafana Labsのキーパーソンにインタビューを実施（後半）

Dee Kitchen氏は社内の開発体制や原則やユニークな働き方などについて解説を行い、Ted Young氏はオープンソースによるソフトウェアが持続するためのヒントを経験を交えて解説するという内容になった。

Grafana Labsにおけるソフトウェア開発の原則について解説するDee Kitchen氏

Kitchen氏はGrafana Labsの利益の源泉であるGrafana Cloudの開発を念頭において解説を行っているため、オープンソースのGrafanaツール、LGTMスタックと呼ばれるLoki、Grafana、Tempo、Mimirなどの開発に関する解説ではないことに留意して欲しい。あくまでもクラウドサービスに対する開発の原則ということだ。

Grafana Labsのソフトウェア開発の原則。利用するツールも記されている

このスライドではソフトウェアデベロッパーに関する原則が解説されている。すべてリモート勤務、定期的にオンコール（Grafana Cloudのサポート、インシデント対応など）勤務が必須、エンジニアは必ずしも管理職になる必要がないこと、ソフトウェアのオーナーシップが明確であること、自律的であることなどだ。ツールについてはGitHub、Slack、Meetなどのツールに加えて、Claude Code、Cursorなどが挙げられている。興味深いのは「Be Descriptive not prescriptive」という部分かもしれない。規範を使って管理するのではなく、具体的に何をするべきか？ を明確にして行動しようという意味だが、ソフトウェア開発において合意がとれた仕様のみを実装するという発想に通じるもので、ソフトウェアがシンプルになりメインテナンスも容易になることを意味している。

開発はGrtafana Labsで単一のリポジトリを使って行い、コミットは80％がBotによって実行されているという。自動化を進めることで人的な仲介を極力省く発想であることがわかる。

リポジトリに対するコミットは80％がBotによって書かれていると説明

また社内からのイノベーションを推進するためのツールとして定期的にハッカソンを開催しており、毎回全体の半数のエンジニアが参加、ハッカソンで開発されたコードの半分が実際のサービスとして実装されていることを説明した。ハッカソンに参加するエンジニアには賞金が用意され、1位になるとチームのメンバーそれぞれに3000ドルが支給されるという。

四半期に一回開催されるハッカソンで作られた機能の半分は実際にクラウドに実装される

機能の開発については小さな変更のループを回すことで徐々に機能を実装する手法であり、そのためにはその機能の背景や解決する課題、提案された実装、これらに対する合意などをデザインドキュメントとしてまとめておく必要があることを説明した。ここからも行動の原則が「Descriptive（記述的）」であることがわかる。

自律的なソフトウェア開発を行うための原則

また開発したソフトウェアをオープンソースとして公開すべきなのか、それともプロプライエタリなコードとして公開しないのかについても解説を行った。

インフラに近いものはOSS、企業の意図が明確に示されているソフトウェアはクローズド

よりインフラストラクチャーでの利用が想定されるソフトウェアについては制約の少ないApache 2、機能が差別化につながるようなソフトウェアはAGPLでオンラインサービスであっても公開を義務づける。さらにその機能が絶対的な優位点を生み出すようなソフトウェアについては、プロプライエタリで公開はしないという原則だ。プロプライエタリの例としてインシデント管理やナレッジグラフが挙げられているように、その機能が大きな差別化になる、つまり価値を生み出すものはオープンにしないことになる。営利企業においては常識的な発想だ。

またエンジニアの働き方についても解説を行った。オンコールと呼ばれるクラウドサービス運用とインシデント管理にかかわる業務が毎月1週間の割合ですべてのエンジニアに割り当てられるという。これは実際に自分が書いたコードがどう使われているのかを理解し、インシデントが発生した時にそれを直すところまで責任を持つということを意味している。オンコールは1日12時間という勤務時間が割り当てられ、働く地域によって分担されることで世界規模で展開されるクラウドサービスが常にどこかの地域のエンジニアによって24時間、365日、運用管理されていることになる。

世界中のリモートで働くエンジニアが分担してインシデント対応を実施

またエンジニアはサービスレベルの目標値について責任を持ち、そのためのツールを開発しているという。

エンジニアはSLO（Service Level Objective）に責任を持つ

エンジニアはSLOだけではなくコストや発生した脆弱性に対しても責任を持つことが求められているという。またハッカソンにおいても、その機能がどのようにビジネスにプラスになるのか？ を明確化することを求められるという。セッションの後の質疑応答で「Grafana Labsのエンジニアはソフトウェアを書くだけではなく、ビジネス面での影響や運用面での責任を持つ必要があるということですか？ つまりエンジニアでありつつ、ビジネスマンであり、運用責任者である必要があると？」という質問には「その通りです」とKitchen氏は回答した。

次に登壇したTed Young氏はOpenTelemetryの開発経験を元に、オープンソースとして持続することの難しさなどを解説した。

プレゼンテーションを行うTed Young氏

Young氏はオープンソースを開発する理由として3つのことを挙げた。それは楽しいこと（Fun）、情熱があること（Passion）、仕事として持続すること（Professional）である。

OSSを開発する3つの理由。Fun、Passion、Professional

ここではプロダクトのサポートについて触れ、FunやPassionだけではソフトウェアのサポートという仕事は続けられない、そのためにはその仕事がProfessionalとして持続すること、つまり金銭的な要因がなければ、持続不可能であると説明した。

ソフトウェアのサポートは情熱だけでは続けられない。なぜならサポートは楽しくないから

またソフトウェアが個人のホビーのレベルから大規模なシステムにスケールするために必要はものは何か？ という問いを挙げて解説を行った。

個人のホビーからエンタープライズレベルにスケールするために必要なものは何か？

それはプロトコル、モジュラリティ、リダンダンシー、そしてマネーであると説明。

さまざまなパーツを組み合わせられるモジュラリティと巨大なシステムに耐えられる冗長化、そしてそれを実装可能にする金銭的なサポートはわかりやすいが、最初のプロトコルについては説明が必要だろう。ソフトウェアそのものの実装よりもそれを誰もが可能にする公開されたプロコトルがコミュニティの中で合意され定義されることでオープンソースは持続し、スケールすることができると自身がリードを務めるOpenTelemetryを例に説明している。つまりプロトコルが決まればそれ以降の実装はそれぞれが行えば良い、そこで競うことが可能になるという意味である。

OpenTelemetryとプロトコルの例を使って説明

プロトコルと実装の分離が必要であるという説明の中で興味深いのは「ベンダーに依存しないガバナンス」が必要であるという部分だろう。これは往々にしてオープンソースを発案したエンジニアが所属する企業がガバナンスを支配して企業の有利になるように誘導することを意味している。その中でCloud Native Computing Foundation（CNCF）を例に挙げて「CNCFはベンダーニュートラルを保証していない」と説明。

CNCFはベンダーニュートラルを保証していないと説明

これはCNCFに対する批判として常に挙げられるポイントで、オープンソースであっても特定のベンダーがプロジェクトに多大な影響力を持ってしまうということを挙げている。これはプロトコルと実装の分離とは違う次元でベンダーが自社の都合に合わせてソフトウェアの仕様や方向性を決めてしまうという状況だ。具体的にはソフトウェアの方向性を決めるSteering Committeeなどに同一企業から多くの社員が席を占めてしまうこと等であろう。

最後にソフトウェア開発における楽しさは自由であることに起因していると説明してセッションを終えた。

自由であることが楽しさの最大の要因

その後は参加者からの多数の質問に答えてMeetupを終えた。

参加者からの質問に答えるDee Kitchen氏（左）とTed Young氏（右）

すべてのセッションで必ず質疑応答を行うというGrafana Labsの慣例に従って、参加者からは多くの質問が寄せられた。英語から日本語への通訳の助けもあり、多くの参加者が疑問に思っていることをぶつけられたのではないだろうか。質問もSlidoの機能を使うことで参加者の質問を持ち帰ることができるのは、企業だけではなくコミュニティにとっても有効だろう。ぜひ、今後の企画に役立ててもらいたい。