DevOpsDays Tokyo 2025：ソフトウェア開発、ITインフラ運用などの領域でDevOpsを実現するための自動化やテスト、セキュリティ、組織文化に関する知見を共有するカンファレンス。グローバルで開催されており、日本では2025年、ハイブリッド形式で開催された。

SHIFTは、DevOpsを「当たり前」に使ってきた集団

秋葉：私は大阪出身で、2007年にエンジニアとしてのキャリアをスタートしました。

経済産業省が発行した『DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～』を読み、新しい技術を身につけないといつの間にか自分が崖の下にいてしまうことになるのではと強い危機感をもちました。

それで、技術を身につける場所として、2020年にSHIFTに入社しました。

松吉：私は11年ほどシステム開発会社で、携帯サイトやECサイトの開発を行ってきました。

当時、DevOpsという考え方はあまり定着していなかったように記憶しています。事業会社への転職を経て2017年にSHIFTに入社し、テスト自動化からDevOpsの領域に幅を広げてきました。

秋葉：私たちが大切にしていることは「あたま」を活用することです。

これは、「明るく、楽しく、前向きに」の頭文字をとったものです。加えて、トラブルが起きたときの対応方法「（情報を）集める、（情報を）たしかめる、前に進める」の頭文字でもあります。

「SHIFTはソフトウェアテストの会社」と認識されている方は、まだまだ多いかもしれませんね。実際に、私たちはテストのご依頼を多数引き受けてきました。そして、早期からテストの自動化に取り組んできた集団でもあります。

その後、CI活用の機運が業界全体で高まり、それがDevOpsと呼ばれるようになりました。振り返ってみると、私たちの取り組みはまさしくDevOpsだったわけです。

参考（外部リンク）： 第三者検証ポジションだからこその強みを発揮。SHIFTが「DevOps推進部」立ち上げに込めた想いを探る

最近になっても、SHIFTはテスト自動化やCI/CD構築のご依頼を多数引き受けています。ガートナーのレポートを見ると、ちょうど現在は「幻滅期」を抜け出して「啓発期」に差しかかるところですね。

つまり、日本ではこれからCI/CDに取り組もう、DevOpsを定着させようとしている企業が多いのではと推察しています。

私たちはDevOps文化を当たり前にしたいと考えていますが、「CI/CDを試してみたい」「テスト自動化を部分的に試してみたい」といった単発のご依頼に対するスポット的な支援では、お客様の文化を変えることはできません。

組織文化の変革は、プロセス／ツールの変化から

秋葉：お客様の文化を変えるための継続的な活動を定着させる要素として、私たちは「プロセス／ツール」をあげました。

組織文化を変えるには、非常に長い時間がかかります。プロセスとツールの整備が、組織文化の緩やかな変化によい影響を与えるのではないかと考えたのです。

第三者であるSHIFTがお客様の組織文化を変えることはむずかしいのではないか、という意見があがったこともあります。

しかし、私たちのタグライン「その常識、変えてみせる。」という言葉を胸に、現在でもお客様の組織文化を変えるための挑戦をつづけています。

例え話をひとつさせてください。いまからちょうど2週間前に、F1が日本で開催されましたよね。F1には、ウィリアムズというチームがあります。

このチームは、2025年からAtlassianと組んでJira™やConfluence™といったツールを使い、チームのコミュニケーションを改善していったところ、組織文化が変わり、順位を上げることができたという記事をご覧になった方はいますか？。

これも広くとらえれば、車が「Dev」、ドライバーからのフィードバックが「Ops」に該当するわけです。ツールを変えてDevOpsを実践し、組織文化を変えられた好事例といえるのではないでしょうか。

ガイド不要のCI/CD導入戦略が、現場の自走を促す

松吉：SHIFTに入社してから、私は非常に多くのお客様の現場を拝見しました。

いずれも、手探りでDevOpsを推進しようとしていた印象があります。そして、どの状況に対しても100点をとれる解決策の提示はむずかしいと感じました。

ただ、「多くのお客様にとって有用なプロセス／ツールの標準をつくり、及第点をとれるようにすることは可能ではないか」とも考えました。

そこでブランチ戦略をつくり、それを支えるツールやプロセスを検討しました。このブランチ戦略の内容は、のちほどお話しします。

CI/CDを導入するうえで、プロセスやツールの使い方を記述したガイドを用意しようとするお客様は多いのではないでしょうか。ただその量が多くなると結局は使われない、という状況になりがちです。

私たちのCI/CD導入戦略のコンセプトは、「ドキュメントを読まなくても1時間の説明会を聞けば使える」というものです。

理解の促進と導入後の改善がしやすいように、ガイド自体は用意するのですが、ガイドに甘えることなく使えるようなものを目指しました。

お客様組織の成熟度が高くない段階でも、自然とブランチ戦略や安全なデプロイができる状態が理想ですね。

ブランチ戦略の再設計で、日本の現場に最適な運用を実現

松吉：私たちは、日本のマジョリティ層には、Git FlowやGitHub Flow、GitLab Flowなどの複雑なブランチ戦略は向かないと考えています。

Git Flowは複雑なリリースバージョンをサポートするようなソフトウェア開発を前提に考案されたもので、普通のWeb開発などでは必要ありません。

そして、GitHub Flow。日本で採用されがちなウォーターフォール型の開発現場では、mainブランチのプルリクエストがマージされたものをテストして不具合を修正するというステップを経るため、すぐに本番リリースできないことが多いという問題があります。

使いこなすには成熟したチームが必要ですね。

最後に、GitLab Flow。日本では並行開発が多いですが、同じ環境ブランチを共有すると機能が混ざったり、本番障害においてhotfixを行おうとしたら次の開発機能が混ざり込んだりしてしまいます。

その分、環境ブランチを並行開発分用意する必要がありますが、これもコストが高くなってしまいます。

では日本のマジョリティによくあるケースに適用しやすいブランチ戦略とは何か？

私たちは、プロジェクト単位でブランチを作成し、その下で開発・テスト・不具合修正を行うシンプルなフローのブランチ戦略を提案しています。これを、「正常系」とします。

各ブランチの役割は、以下の通りです。

• mainブランチ…このブランチは唯一の永続ブランチとして、hotfixに備えて本番稼働中のコードと同じコードを保持する。
• projectブランチ…プロジェクトの名称をつけることで何を開発するブランチなのかをわかりやすくする。アジャイル開発ではsprintブランチとしても利用できる。
• workブランチ…Git flowにおけるfeatureブランチ。
• issueブランチ…テスト時の不具合対応などで利用する。

最終的にプロジェクトが完了したら、mainブランチにマージします。

次に、hotfixを利用するパターンについて。

基本的には、mainブランチにおける最新コミットは本番リリースと同じソースコードであることを踏まえて、mainブランチからのブランチを切り、そのもとで修正開発・テストを行うというシンプルな形です。

間違いを防ぐ「ガードレール」により、安心して開発できる環境をつくる

松吉：開発中に陥りやすい罠として、プルリクエストのターゲットブランチを間違えて作成してしまうことがあります。Gitに慣れていない開発者が多いなかで、こうした事故が発生することがあるため、注意が必要です。

また、バージョン管理が不十分な場合、デプロイやテストの資材をとり違えてしまうこともあります。開発中のアーティファクトにバージョンがなかったり、すべて同じバージョンになっていたりする場合ですね。

この場合、アーティファクト同一性を担保できずに本番障害に陥ってしまったり、QAをクリアしたバージョンがわからなくなったりする可能性があります。

こうした罠に陥らないための工夫として、ブランチ戦略にガードレールを設けることが重要です。

ガードレールとは、メインブランチでマージが可能なのはprojectブランチやhotfixブランチのみとするなど、間違ったブランチへのプルリクエストを防ぐ仕組みです。

ガードレールを導入することで、間違ったブランチへのマージを防ぐことができ、間違いからの修正といった無駄な時間を削減できます。

加えて、開発者がプルリクエストを安心して行えるようになるなど、心理的安全性の確保にも貢献しています。

また、このブランチ戦略ではオートバージョニングを実施し、バージョン管理を自動化することで、リリース対象のバージョンを明確にし、トレーサビリティを確保しています。

これによって、リリースモジュールをとり違える心配が不要になりました。加えて、問題が発生したバージョンの特定が容易になりました。

さらに、アーティファクトの同一性を担保することもできます。

これによって、テストを実施したアーティファクトを確実にリリースできるうえに、意図しないビルド差分をなくすことができます。

最後に、ブランチ戦略以外で工夫しているポイントをご紹介します。SHIFTはCI/CDパイプラインだけではなく、クラウドインフラの「型」も用意しました。これによって、使いたいインフラや言語を簡単に適用できます。

SHIFTの支援を受けたお客様からは、高評価を得ています。

秋葉：これらの取り組みにより、SHIFTはDevOps文化を普及させ、エンジニアリングの現場での品質担保を実現しています。ですが、日本企業において、DevOpsはまだまだ「当たり前」にはなっていません。

まずは、「あ」焦らず、「た」助け合いながら、「ま」まずは形から入ってみてもいいじゃない、という姿勢で十分だと考えています。

DevOpsを当たり前にするために、冒頭で述べた「あたま」の活用が重要と考えています。と、オチがついたところでセッションを終わりにしたいと考えております。ご清聴ありがとうございました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）