こんにちは、クラウド事業部 CI/CDサービスメニューチームの山路です。
今回は今年の2月7日に開催されたGitLab Connect Japan 2024に参加したので、内容の紹介と感想を書きます。なお本イベントの講演は後ほど動画も公開されるとのことなので、詳細はそちらをご覧ください。
GitLab Connect Japanとは
GitLab Connect JapanはGitLabが主催のDevOpsカンファレンスとして、2022年に初めて開催された国内のITイベントです。今回は2回目の開催で初めてのオフライン開催でしたが、 3月の上旬ごろには オンライン配信も行われるとのことです 当日の講演の録画・資料の提供もされています (2024/3/8追記) 。また会場には飲み物やアメニティに加え、同時通訳の方もいらっしゃり、英語の発表でも内容を理解できるよう配慮されていました。
GitLab Connect Japan 2024のページを見ると、以下のように紹介されています。
日本のDevOpsは米国と比較して大きく遅れています。これは、これまで築かれてきた日本独自の開発体制や工程が、米国を中心に発展してきたDevOpsの概念に合わないことがあるためです。そのため、米国の単なる追随ではなく、双方の差異を認識・理解し、その上で日本流のDevOpsを追求することが重要です。
このイベントでは、米国GitLabのメンバーが来日し、米国におけるDevOpsの最新動向をご紹介します。同時に、日本におけるGitLabのユーザーやパートナーが、具体的な事例や実践的なソリューションをご紹介します。このイベントが、日本流DevOpsを推進するためのヒントになれば幸いです。
この紹介文を見て、今回のイベントでは大きく2つのポイントに注目をして発表を聞いていました。
米国と日本のDevOpsにおける差分は何か日本流のDevOpsとは何か
各講演の紹介
ここからは各講演について概要を紹介しつつ感想を書いていきます。
1: Opening Remarks and Welcome Keynote: The Evolution of DevSecOps
はじめの2講演では、主にGitLabの方から、GitLabの現状や日本市場への注目度合い、将来のロードマップなどが発表されました。
最初の講演では、GitLab本社からもスピーカーを招き、ソフトウェアの変革に立ちはだかる課題やGitLabがそれをどう解決するか、GitLabの導入効果などが紹介されました。また後半ではCloudflareからエバンジェリストの亀田さんを招き、日本のソフトウェア開発に必要な要素、日本企業の現状などを紹介いただきました。
個人的には、GitLabのChrisさんから亀田さんへの質疑応答で、 米国と日本のDevOpsにおける差分は何か というテーマにつながるお話を聞けたと感じました。
- 日本では日本語を第一言語として会話できるが故に対面コミュニケーションに偏っている。
- 何か問題があると話し合い確認し合ってOKサインを出すことが多いが、これでは問題解決のスピードが出ない。
- 会話で問題を解決してきたので、システムで問題を解決することが苦手な面がある。
- セキュリティでいえば、例えばDevSecOpsツールを導入し、それが良ければGitLabなどを採用する、ツールに対してルールを適用し、開発者を自由にする。そういった転換が必要。
このお話から、日本は第一言語で会話ができるという環境が起因して問題解決やシステム化に課題を抱えている面があり、従来の対話での解決からツールでの解決・ルール化を進めることが必要である、と理解しました。
また、この質疑応答の後にGitLab 小澤さんが話された内容からも、米国と日本のDevOpsにおける差分として重要なことが聞けたと感じました。
- 日本マーケットとその他の違いとして、SIの存在がある。
- SI企業により効率的にできる面もある一方、内製化を考えたときに完全な内製化は難しくなるだろう。
- DX、ソフトウェア内製化においては、自社と他社を合わせたハイブリッドなモデルになるだろう。
- 自社内で完結するワークフローにはならない。
- SI企業や海外拠点も巻き込んだうえでのプラットフォーム化が必要だと考えている。
このように、日本ではエンジニア不足も相まってSIerに大きく依存しており、自社以外の企業とどのように連携してDevOpsを推進するかが重要、という点が見えてきました。
2: Next up for The DevSecOps Platform
2つ目の講演では、GitLabのSolution Architectの3名から、統合されたDevSecOpsプラットフォームの価値、GitLabのプロダクトロードマップ、そしてGitLab Duoという3つのテーマで発表されました。
GitLabは The DevSecOps Platform として、一つのプラットフォーム上でDevSecOpsの機能やツールを統合することを強みの一つとしていますが、具体的にどのような価値があるのか、企業がDevSecOpsのループを実現するプロセスから紹介しています。
はじめはチームごとに異なるツールを用いて自分たちのDevSecOpsを実現する ( Buid your own DevSecOps )、次に利用するツールチェーンを標準化する ( Best-in-class DevSecOps )、そして独自連携を深める ( DIY DevSecOps )、というプロセスが多いそうですが、各ツールを管理・連携するのは複雑で時間もかかり、開発効率を制限する要因ともなります ( ツールチェーン税 )。特にプラグインを利用する場合、それぞれのバージョンアップなどを管理するのは困難です ( プラグインの沼 )。そうではなく、はじめから単一のプラットフォーム上でDevSecOpsを推進することで、ツール間の連携やプラグインの沼に苦しめられることなくDevSecOpsを実現することにつながります ( DevSecOps Platform )。
※参考:
続いてプロダクトロードマップでは、GitLabで最近導入された機能や、今後実装予定の機能をいくつか紹介しました。
例えば Enterprise Agile Add-on は、Ultimateプランを利用する顧客向けのアドオンプランです。GitLabでソースコードを見ない非開発者と開発者が同じプラットフォームで協業することを可能にします。
また実装予定のものとしては、ソフトウェアサプライチェーンの一部としてIDEでのスキャン結果の表示やBuildアーティファクトの署名、複数あるポリシー（コンプライアンス、セキュリティなど）の一元管理、継続的スキャンなどが紹介されました。
さいごにGitLab Duoについて、GitLabが開発プロセスの全般でAIを活用していることに触れつつ、GitLab Duoのいくつかの機能 ( Issue description や Code Suggestions + Refactoring 、Explain this code など) が紹介されました。特にCode Suggestions+Refactoringのデモ中に、Code Suggestionsで生成したコードを更にリファクタリングしたコードが提案される様子を見て、「ここまでできるのか！」と驚きました。
GitLab導入企業からの発表
ここからはGitLabを導入した具体的な事例の紹介です。ここでは 日本流のDevOpsとは何か という観点で、特に関係すると思った部分を抜粋します。
3: “システム変革のリアル” ～いすゞ自動車におけるシステム開発手法のモダナイズとGitLab導入の軌跡～
本発表の中では、基幹システムの刷新を進めるうえで苦労した点を紹介されていたのですが、その一つとして「プロジェクト体制の構築」について紹介されていました。
- パートナー企業も含めて社内外で適切なメンバーをアサインするのが難しかった。
- DevSecOpsの経験あるエンジニア自体が希少だったため、当初は開発経験の豊富なエンジニアを中心にチームを構成したが、なかなか機能しなかった。
- これを改善するため、GitLab社のリソースの利用と、メンバーアサインの考えかたの変更を行った。
- 1つ目はDevSecOpsの知見を補填するため、GitLabのカスタマーサクセス、ハンズオン、ワークショップ、成果物レビューなどを利用すること。
- 2つ目は経験でなくマインドセットを重視したメンバーの再募集。
- メンバーアサインでは、それまでの固定概念にとらわれないこと、自分事として捉えられることを重視した。
- 今考えると、これまで取引があったから、大手だから、ではなく、しっかりコミットできる企業にお願いすれば良かったのではないか、と考えている。
DevSecOpsに詳しい人材はおそらく日本市場全体で見ても少ないと思うので、「コミットできるメンバーを集めること」「GitLab社のリソースを活用して知識をインプットすること」の2点は、別の企業やプロジェクトでも参考になる事例だと感じました。
4: みんなの銀行における DevOps 基盤の再構築
本発表では、新しいプロジェクトの立ち上げに伴い、2019年ごろから利用していたDevOps基盤とは別に基盤を構築・運用するに至った経緯とシステムの構成などが紹介されていました。
- 既存のDevOps基盤は、専用のDevOpsチームが各種セッティングを行うことで、中央集権的に統制の取りやすいこと、開発者が開発に集中できる環境を得られるという点でメリットがあった。
- 一方で何か作業をするときにDevOpsチームがボトルネックとなりやすいという課題があった。
- システム自体がブラックボックス化されていた面もあり、何かのエラーがCI/CD等で発生した時も、DevOpsチームがログを見ないと原因が判別できなかった。
- さらにアプリ側がエラーの原因だった場合には別チームに相談しないといけない、という現状があった。
- これを改善するため、既存のDevOpsでも利用していたGitLabの機能をさらに拡大し、GitLabのProject templateの利用などを行った。
- 新規Projectが必要な時はtemplateから作成するようにし、プロジェクトの準備時間を大幅に短縮した。
- DevOps基盤のブラックボックス化も軽減され、開発者もエラー等に対応できるようになった。
日本ではシステム構築を外部の協力会社に依頼するケースも多いことを考えると、「いかにシステムをブラックボックス化しないか」という観点は重要だなと感じました。また日本に限ったことではないですが、DevOpsチームがボトルネックとならないためにTemplateを利用するという実例は参考になりました。
5: 迷わず行けよ。行けば分かるさ。DevOpsの道。 〜三井住友海上が直面した「アジャイル開発推進の壁とその対処法」〜
本発表では、アジャイル開発を推進する中でスクラムを採用するも、思ったほどのスピードが出なかった、という課題からスタートします。スピードの上がらない原因はいくつかありましたが、その一つにパートナー会社との連携が挙げられました。ただしこちらは先ほどと異なり、システムのアーキテクチャ面での課題です。
- あるシステムやアプリケーションを開発するとき、一部はパートナー会社の環境で提供するものを利用する。会社としてセキュリティ面で厳しい基準を設けているため、社内ネットワークに外部から資源を移送するときは特に厳重なチェックリストをパスする必要がある。こういった要因から開発スピードが伸び悩んでいた。
- 複数の課題を解決するために必要だったのがDevOpsプラットフォームの導入だと判断した。社内の閉域網への移送を効率化するため、CI/CDパイプラインを導入した。
- GitLab SaaSを採用したが、SaaSと閉域網をつなげる部分で、セキュリティの安全をどう保証するか、社内調整も含めて大変だった。最終的には閉域網内でGitLab Runnerを構築、これを仲介役とした。Runnerからアウトバウンド通信でGitLab SaaSに接続すればよいので、資材を安全に社内に移送できる環境を用意できた。
本イベントの冒頭でも日本企業がセキュリティに注力することに触れられていたこともあり、セキュリティを担保しつつSaaSを活用する具体例として、とても興味深かったです。
パートナー企業からの発表
ここからはGitLabのパートナー企業から、様々な観点からDevOpsに関する発表がありました。
6: DevOps で企業価値を最大化する方法 ～なぜ、日本で DevOps が進まないのか～
本発表では、なぜ日本でDevOpsが進まないのか、そしてそれを改善するものとしてDevSecOpsを挙げています。
- エンジニアは忙しい。コードを書くだけでなく要件定義から運用まで多くのタスクを抱える。
- 組織にも課題がある。エンジニアの忙しい現状、エンジニアが足りない状況は理解しているが、何から始めればよいかわからない。プロジェクト管理も大変。
- DevSecOpsの導入と定着は課題解決につながる。例えばDevOpsフレームワークの一つにCALMSがあるが、こういったものを参考にして導入と定着を進められる。
- DevSecOpsを導入することで。開発スピードの向上、業務効率化などがもたらされる。最大の効果はエンジニアがより創造的な作業に時間を使えることであり、これがイノベーションの加速につながる。
- 本質的にはDevSecOpsの導入は投資なので、事業責任か経営責任のどちらかである。トップダウンで取り組むべきである。
※参考:
7: ビジネスを変革するValue Stream Management
本発表ではValue Stream Managementについてと、それに関する自社サービスが紹介されました。
- Value Stream Managementとは、顧客に価値を届けるまでのE2Eの活動を、定量的なデータを使って管理することを指す。現状のValue Streamの洗い出し、リードタイム・手戻り率などのデータを使った分析、課題に対する打ち手の検討・実施、継続的なモニタリングによる効果測定などを行う。
- GitLabと協業してValue Stream Assessmentコンサルティングサービスを提供している。
- Value Stream Mappingはプロジェクト内のチーム規模で実施しても効果は薄い。ボトルネックの検出はできても打ち手を出しづらい。プロジェクト全体を巻き込んで実施することで効果が出る。そういった点もサポートしている。
8: 先進事例から学ぶ DevSecOpsでセキュリティに取り組むコツ
本発表では事例を交えつつ、DevSecOpsでセキュリティに取り組むコツについて紹介されました。発表資料はこちらです。
先進事例から学ぶ DevSecOpsでセキュリティに取り組むコツ - Speaker Deck
- DevOpsでは顧客のフィードバックを受けて改善を繰り返す。しかしセキュリティについては問題が発覚してからでは遅く、取り返しのつかないことになりかねない。一方で従来型のセキュリティ対策を実施するのは、網羅性が高いこともあり困難 (チェックリストベース、など) 。そこでDevSecOpsに取り組むことが必要である。
- DevSecOpsで重要なのは文化、プロセス、技術にバランスよく取り組むこと。
さいごに
本イベントでは、GitLabの最新情報から事例を交え、Dev(Sec)Opsを実現するためのヒントが数多く共有されていました。私は普段インフラエンジニアとしてSI業務を担当していますが、SIとしても考えさせられるメッセージを多く受け取れたと感じています。講演後の懇親会でも様々なお話を伺えたので、とても楽しい時間を過ごせました。
最後に、弊社はGitLabオープンパートナー認定を受けております。 また以下のようにCI/CDの導入を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。
