CI/CDを通じて日本のソフトウェア開発を変えていくために今何が必要か？

Screwdriver開発者とJenkins川口氏が語る組織とコミュニティの課題

2019/08/20 09:00

　社会のあらゆる分野でデジタル化が進むなか、ビジネスにおけるソフトウェアの重要性が増しています。目まぐるしく変わる消費者の動向やビジネス環境の変化に、柔軟かつ迅速に対応できるソフトウェア開発手法である「アジャイル」が注目されるのと併せて、テストやデプロイを自動化し、より効率的で、スピード感のある開発運用環境を実現する手段である「CI/CD（継続的インテグレーション／継続的デリバリ）」への関心も高まりを見せています。今回、OSSのCI/CDツールとして著名な「Jenkins」のプロジェクトリードを務める川口耕介氏と、ヤフーでOSSのCI/CDワークフロー構築ツールである「Screwdriver」の開発に携わる中山亮介氏、高橋侑也氏が「CI/CDを通じて日本のソフトウェア開発を変えていく方法」について意見を交わしました。

ヤフーではCI/CDツール「Screwdriver」をどう使っている？

川口：今日は、CI/CDを通じた開発者の生産性向上に関して、いろんな情報交換ができればと思います。よろしくお願いします。最初に、ヤフーがOSSで開発されている「Screwdriver」について、紹介をいただければと思うのですが。

中山：「Screwdriver」は、もともと米Yahoo! Inc.（現: Verizon Media）社内で開発されていたCI/CDツールで、現在バージョン4です。当初はJenkinsのラッパーのような形で動くソフトウェアだったのですが、その中で見えてきた課題もあり、2016年ごろから完全に一から作り直すと同時にOSSとして開発を進めるようになりました。現在は、OSS版を軸に、開発者とユーザーを広げていこうとしているところです。

川口：僕の認識では、日本と米国のヤフーは完全に別の企業体として運営されていたと思うのですが、米国で開発したScrewdriverを、日本のヤフーで使うことになった経緯は何だったのでしょう。

高橋：技術協力している中で相互のリソースをより良く成果物に結びつけたいというテーマがありました。CI/CDツールとしては、ヤフーでも以前からJenkinsなどを入れてはいたのですが、部分最適になっていて、社内での集約や標準化をいかに進めるかという課題がありました。会社全体としてリリースするソフトウェアの品質を上げ、セキュリティを担保していくにあたり、当時、社内でCIをすすめる機運の高まりもあったことからも、米国で開発を進めていたScrewdriverが日本でも使えると考えました。

川口：現在、Screwdriverはヤフー社内でどのように使われているのですか。

中山：社内では100を越えるサービスやアプリケーションが開発されており、チームによって文化もデプロイ方法もさまざまです。DPS（Developer Platforms and Services）部門が提供しているテンプレートや共通のコマンドを使ってサクッと構築して使っているようなケースもあれば、組織内で独自にテンプレートを作って運用しているようなケースもあり、いろいろですね。

川口：そのあたり、ヤフーに限らずどんな会社であっても、デベロッパープロダクティビティを考える部門の課題なのかもしれないと思っています。中央集権にしてしまって、完全な標準化ができれば効率が上がることは分かっているものの、会社の規模が大きくなるほど、各チームの自立心が旺盛で、それぞれに独自のやり方があり、統一が難しい。恐らく、ヤフーでも苦労されているのではないかと思うのですが、どのような取り組みをされて、そこからどんな知見が得られたのかに興味があります。

中山：実はScrewdriverも、バージョン3までは、ツール側で決められたやり方のみをサポートし、それ以外のやり方は基本的に認めないという作りになっていたんですね。ただ、現実問題として、それだとどうしても困る人が出てきてしまいます。最新のOSS版であるバージョン4では、テンプレートやコマンドをチーム側である程度自由に作れるようにしておき、一方で、一度作ったものはScrewdriver内で使い回せるようにすることで、一定の自由さと利便性を確保するという方向性になっています。

高橋：脆弱性の検査などのように、会社としてどうしても全体で統一したいというプロセスについては、強制的に入れる仕組みもあります。ただ、CI/CDは人が絡む課題であり、現状ではプロセスを完全に統一することが難しい。特に大きな組織は、それぞれのチームの事情を無視して、かっちり固めすぎてしまうと、うまくいかないケースが多いのではないでしょうか。

川口：なるほど。やはり、苦労をされているのですね。海外の事例ですが、中規模くらいまでだと、中央集権化がうまくいっている組織もあるんですよ。500人くらいのエンジニアチームを抱えるイスラエルの会社なのですが、同社では全社規模でビルドの方式は1つに統一されています。アプリケーションのチームは、ビルドスクリプトは一切書きません。デベロッパープロダクティビティの部門が別にあって、彼らが「テストに時間がかかっているので、今月の目標はテストの並列化にしよう」と自分たちでゴールを設定し、実装するんです。アプリケーションのチームにとっては、ある日、出社するとみんなのテストが一斉に並列化されていたというイメージです。現場のエンジニアも「ありがとう！」みたいな感じで、特に気にせず自分たちの仕事にかかる……というふうに。

中山：すごいですね。どうしてそういう仕組みがうまくまわっているのか、興味があります。

川口：特に大きな組織では、このレベルの中央集権化が難しい理屈もよく分かります。例えば、連邦政府のソフトを開発している、ある企業では、オブジェクト指向の継承を彷彿させるようなテンプレートシステムを独自に構築しています。例えば、「退役軍人省向けのシステムでは、ビルドプロセスにセキュリティスキャンが必要」というルールがあったりするのですが、どのツールを使わないといけないかまでは決まっていない。それがアブストラクトメソッドのように定義されています。システム開発のチームが「じゃあ、このプロジェクトではFortifyを使おう」と決めて、テンプレートを継承してそれを入れると、うまいこと他のプロセスと噛み合って動くんですよ。

　こういう例を聞くと、素直に「スゴイな」と思うんですけれど、逆にそういうことをやろうとすると、非常に手間がかかるんですね。こういう「自由度」が、デベロッパープロダクティビティチームの生産性に貢献していないというのも、また事実だと思うんです。

中山：それは、抽象化のレイヤが必要以上に深すぎるというイメージでしょうか？

川口：ちょっと違いますね。僕が違和感を覚えるのは「下のレイヤをアプリケーションの開発チームにコントロールさせてあげないといけない」という空気がいまだにあることなんです。昔は、たしかにOSを含む実行環境やインフラの違いなどを考えてアプリケーションを作る必要があったので、完全な標準化が難しかったという事情もあるのですが、今ではKubernetesのようなものも出てきて、そのあたりの状況も変わっていると思います。

中山：たしかにそうですね。ただ、ヤフーの場合、「サービスが100以上あって、サービスごとに開発環境や開発プロセスを最適化している」という独自の事情が、標準化を難しくしている面はあるんです。Gitのブランチ戦略からして違っているチームのやり方を全体で統一するのは、現実的ではないのかもしれないと思います。

高橋：もちろん、CI/CD研修などを通じて「これを使って、こうやればうまくいく」ということを周知したり、それらをドキュメント化したりということはやっているのですが、あくまでも「推奨」であって、それを受け入れるかどうかはサービス側が決めるというのが現在の状況です。そのあたりのさじ加減をどうすべきかは、常に課題ですね。

川口：事情はよく分かりました。Googleのように、デベロッパープロダクティビティチームが最強レベルに達している組織だと「好きなやり方でやっていいけれど、俺たちの言うとおりにやれば、生産性は10倍上がるよ」みたいな空気を作れて、誰もそれ以外の方法でやろうと思わなくなったりするのですが、なかなかそのレベルに達せるものではないですね。個人的には、ぜひ、ヤフーのプロダクティビティチームにはそこまで進化してもらって、後進に道を示してほしいです（笑）。

中山亮介（なかやま・りょうすけ）氏

　ヤフー株式会社テクノロジーグループシステム統括本部セキュリティ＆コアテクノロジー本部。2011年にヤフーに入社。主に社内開発者向けのツールメンテナンスに携わる。2014年よりヤフー社内の「Screwdriver」のプロダクト責任者として開発、運用に携わる。Screwdriverを通じた社内外へのCI/CDの普及啓蒙を続けている。

OSSコミュニティは「やりたいことをやってもらう」と拡大する

川口：現在、OSSとして「Screwdriver」を開発している中で、メリットをどうアピールしていくか、コミュニティをどのように広げていきたいかについて、アイデアはありますか。

中山：まったく知名度がないところからのスタートなので、まずは「知ってもらう」ことが重要ですよね。ブックエンド、テンプレート、コマンドといった機能を使って、大勢の人が使いながらプロセスの共通化を進められるというのが特徴なので、ミートアップなどに出しながら「大きめな企業で使うとこんなメリットがあるよ」ということを知ってもらい、広げていければと思っています。

　あと、日本人にとっては「日本語のドキュメント」もまだまだ重要ですね。日本語での情報発信も充実させたいと考えています。

川口：今振り返って見ると、Jenkinsのコミュニティを広げていくにあたってカギとなったのは、一人ひとりの開発者が「やりたい」ことを、他の人が「やりたい」こととうまくコーディネートして、コレクティブ、つまり集団としての「やる気」をどう引き出すかの仕掛け作りだったような気がします。

　みんながやりたいことを、それぞれ好きにやれるような「砂場」を作っておくと、結果的にものすごい構造物ができあがっていくんですね。自分も、最初はその砂場でお城を作っていたのですが、どこかのタイミングで「砂場そのもの」を作っていくことにシフトしていったように思います。

中山：それは「使いやすい状態にして、ある程度様子を見る」みたいな感じでしょうか。

川口：最初のころは「CI/CDツールはこうあるべき！」という自分の考えをもとに、プロダクトを作っていたのですが、「それはほかの人にやってもらってもいいかな」と思うタイミングがあったんですね。そこから「他の人が面白いことをしやすい場を作る」ことを意識するようになりました。すると「こうあるべき！」という考えを持っている大勢の人が、どこからともなく集まってきて、作ってくれるんですね。

　一般に「開発者のコミュニティを大きくする」みたいなことを考えはじめると、「自分のやりたいことに、他の人たちをどうやって巻き込んでいくか」と考え始める人たちが多いんですが、それは、実はOSSの世界だとあまりうまくいかないんじゃないかという印象を持っています。単純に、みんな、人に言われたことをやるよりは、自分のやりたいことをやった方が断然モティベーションが上がりますよ。

中山：川口さんが、コミュニティの運営にあたって、そういう考えを持つようになった契機は何だったのでしょうか。

川口：原体験は、サン・マイクロシステムズ（以下、サン）にいた頃にやった、XMLによるデータマイニングライブラリ作りのプロジェクトだったかもしれません。当時、サンのCEOが変わって「これからは全部OSSだ！」という号令が掛かったのですが、現場としては経験もなく、どうやっていいのかも分からない。そんな中で、僕のいたチームが「まず、お前たちのチームがOSS化しろ。その結果で他も動く」みたいなことを言われたんですね。まさに「斬り込み隊」です。

　当初はナイーブで、「OSS化したら、みんな手伝ってくれるんでしょ？」くらいに思っていたんですが、全然人が集まらない。いろいろ試行錯誤が続いたのですが、ある日「アドオンインターフェース」のようなものを作って置いておいたら、どこからともなく、それを使ってコードを書いてくれる人が現れたんです。その時に「あぁ、みんながやりたいことをやれるようにすればいいんだ」ということが、何となくイメージできたんですね。それをもっと理論的に突き詰めていったら、どうなるのだろうというのが、Jenkinsを作る上での、僕の中のテーマの一つになっていました。

川口耕介（かわぐち・こうすけ）氏

　CloudBees CTO。Jenkinsプロジェクトリード。サン・マイクロシステムズ（現オラクル）在籍時にJenkinsの前身であるHudsonを開発。退社後、CloudBeesを立ち上げ、Jenkinsに関連した製品、サポート、サービスを開発しながら、ソフトウェア開発の効率化や、企業のデジタル改革のサポートに取り組んでいる。

「CD Foundationは、みんなが安心して参加できるお祭りの場にしたい」

中山：川口さんには、2019年3月に発足した「Continuous Delivery Foundation」（以下、CDF）について、どのような課題感から設立に動いたのかをお伺いしたいです。

川口：サンで開発していた前のプロダクトでの反省もあって、Jenkinsは、企業から完全に独立したOSSプロダクトとして開発を続けてきました。当初は「Software in the Public Interest（SPI）」という非営利団体の下でいろいろとやっていたのですが、規模が大きくなるに従って、完全なボランティアベースのSPIでなく、よりいろいろな側面からサポートしてもらえる体制が必要だなと考えたのが「Linux Foundation」傘下での活動を考えたきっかけの一つです。

　もうすこし広い視野で言うと、いろんな会社の中にある、デベロッパープロダクティビティに関する同じような悩みや、それを解決するための取り組みについて、ノウハウを共有する場を作りたかったというのがあります。そこでの知見がOSSとして再利用できるようになることで、結果的に世の中が前進するスピードが速くなっていくんじゃないかと思っています。

　もう一つ、日本企業の技術の人たちと話すなかで、現場ではCI/CDのような生産性向上の取り組みが必要だということは理解しているものの「会社からの手助けが得られない」と感じているということが分かってきました。多くの企業では、CI/CDが技術的なマターだと思われていて、経営者レベルで意思決定すべき事案だと思われていないんです。

　我々としては、CI/CDがビジネスにインパクトがある取り組みだということを経営者の人たちにメッセージとして発信していく必要がある。そのために日本経済新聞で取り扱ってもらえるような活動をしていきたいというのも、CDFを立ち上げた1つのモチベーションです。

　個人的に、オープンソースは転機を迎えていると思っています。かつて、OSSというとMITのヒゲを生やしたハッカーが作るものという認知でしたが、その後、企業がビジネスモデルの一環としてオープンソースをやるようになりました。そうなることで、プロジェクト数は一気に増えましたが、企業が主導しているプロジェクトには、ほかの企業が参加しづらいという事情もあります。結果的に、プロジェクトが分断されてしまい、行き詰まりつつあるのではないかという危惧を持っています。CDFは、いろんなエコシステム、さまざまなチームがカジュアルに混ざり合う、みんなが安心して参加できるお祭りのような場にしていきたいですね。

高橋：CDFは、Jenkins、Jenkins X、Spinnakerといったプロジェクトをホストしていて、川口さんのCloudBeesを含む多くの企業がメンバーになっていますよね。発案から、この形での立ち上げに至るまで、どのくらいかかったのでしょうか。

川口：Jenkins関連のファウンデーションにするという当初の構想が出てたのは、2年前。その後、CDFとして立ち上げるべきということで意見がまとまったのは1年前くらいでした。複数のベンダーを束ねた取り組みは、どうしてもすぐには動き出せません。そういう意味では、本当に長い道のりでした。ようやく組織として立ち上がり、これからやることがいっぱいあるという状況です。

中山：先ほど「経営者に対して、CI/CDがビジネスにインパクトのある取り組みだということをメッセージとして出していく」ことも、CDFの目標と話されていましたが、そのために具体的にどんなことをやろうとされているのでしょうか。

川口：「こういうのをやらなきゃね」というのは、財団のメンバーである企業間で意識合わせを進めています。CDFのメンバーには、SalesforceやeBayといったCI/CDのエンドユーザーも入っているのですが、そうしたところを集めて情報交換するような場を作ると、それがビーコンのような役割を果たしていくのではないかと考えています。エンドユーザーにとっては、自社が「技術的に先進の取り組みをしている」というブランディングができるという意味で、リクルーティング面でもメリットがあると思います。その意味で、エンドユーザーにも多く参加して欲しいですね。

　幸いにして、当初の予想よりも多くの企業がメンバーに入ってくれ、お金も使える状態になってきています。ただ、やはり基本的にCDFの活動にはパートタイムで関わる形になるので、進みが遅いというのがもどかしいですね。まずは人を雇って、ホワイトペーパー作りなどを含むマーケティングをきちんとやっていかなければと思っています。

中山：ヤフーの場合、経営層のCI/CDに対する理解はあると思うのですが、まったく課題がないかというと、そうでもありません。CI/CDはエンジニアのみが気にするものだと思われがちです。本当にCI/CDを効率的に回すためには、組織全体でワークフローを見直すべきなのですが、そういう部分での理解を得るのはなかなか難しいと感じますね。

川口：経営層がCI/CDの重要さを理解しているのであれば、次のステップとして、完全な標準化による効率向上を手伝ってもらうというというのもありますね。トップダウンでメッセージを出すことで、説得されやすい現場というのもありますし。

高橋侑也（たかはし・ゆうや）氏

　ヤフー株式会社テクノロジーグループシステム統括本部セキュリティ＆コアテクノロジー本部リーダー。2011年にヤフーに入社。中山氏と同じく、社内開発者向けのツールメンテナンス、パッケージリポジトリの管理などに携わる。2014年に「Screwdriver」の社内導入に向けて、米Yahoo! Inc.（現Verizon Media）のメンバーと一緒にScrewdriverの初期の運営を手掛けて今に至る。Screwdriverの開発、運用と合わせて、社内でのCI/CD研修などに携わる。

CI/CDが「ビジネスマター」だという意識はどうすれば生まれるのか

高橋：日本のユーザー企業における、デベロッパープロダクティビティへの関心度について、川口さんはどう見ていらっしゃいますか。

川口：日本企業の中で、世界の土俵で闘っている会社は、ある程度危機感を持って取り組んでおり、大規模に投資もしているという印象を持っています。

　その一方で、自社でエンジニアを抱えず「下請け」を使うという、日本のソフトウェア業界の構造的な問題が、CI/CDの効果的な運用を妨げる一因になっているようにも感じています。下請けを使う場合、契約の形態として「この機能を持つソフトウェアをいつまでに納入する」という形になりますよね。CI/CDは、基本的に「今後の成長を容易にする」ための仕組みなのですが、今後、別の会社と契約する可能性もあることを考えると、その仕組み作りへの投資に、経済的な合理性が生まれなくなってしまうんです。

　そうなると困るのが現場の技術者です。「これじゃダメだ。テストやらなきゃ」と思うので、何とか仕組みは入れたい。仕方がないので、有能なマネージャーに相談し、彼がゴニョゴニョやって、こっそり金額的に放り込む……みたいな感じにせざるを得なくなってしまう。こんなやり方を続けていたのでは、長期的にうまくいくはずがありません。米国企業には、ITに関する下請け文化はなく、どの会社でも、自社でエンジニアを雇います。そうなると、プロダクトへのマインドセットや取り組み方が明らかに変わってきます。

　この構造自体を何とかしないといけないは思うんですけれど、そうなると、テーマが大きくなりすぎて、デベロッパープロダクティビティの範疇を外れてしまうんですよね。

高橋：CI/CDの重要性が経営者に理解されるのと同じように、自社でエンジニアを抱えて、自社で情報インフラを維持し、改善していくことが、価値を生むのだいうことを理解してもらう必要があると思いますが、そのあたりの認識を変えていくのには、さらに時間がかかるでしょうね。

川口：1つの希望としては、オランダにある「INGグループ」と「ABN AMRO」という2つの大手金融系企業の例があると思います。10年前、この2社は共に「IT部門はコストセンターだから、アウトソースしていく」という方針を立てていました。しかし、IGNグループは途中で路線を変更。「アジャイル型組織」を作っていくことに注力するようになり、エンジニアも改めて自社で抱えるようにしたのです。この2社は、2019年の時点で業績に大きな差が出ています。どちらが高い価値を生み出せるようになったかは、いわずもがなです。

　ここから分かるのは、「どこかの段階で気づき、路線変更」ができれば、10年ほどのタイムスパンで状況を大きく変えられるということです。路線変更を決定したタイミングで、彼らがどのように問題をフレームしたのかが分かると、そのフレーミングは日本の経営者にもアピールするのではないかと思うんです。そして、それはたぶん「エンジニアの自社雇用」という小さなフレームではないのだろうと思います。

中山：あくまでも想像ですが、かつて経営の根幹は「ヒト」「モノ」「カネ」だと言われていましたが、今ではそれに加えて「情報」や「データ」の位置づけが大きくなってきています。それに気付いている経営者がいる企業は、路線変更に踏み切れるのかもしれませんね。

「アピール」と「多様性」で日本のソフトウェア開発はまだまだ変わる

川口：ヤフーは、日本のインターネットではトップと言っていい規模の事業を展開していて、なおかつ、OSSの領域でCI/CDに関わっているという点で特別な立ち位置にあると思います。それを踏まえて、今後、CI/CDの分野でどのように存在感を出していこうと考えておられますか。

中山：Screwdriverは、1つのプラットフォームで、ヤフーが抱える多種多様なサービスに使ってもらえているという点で、非常にユニークなプロダクトだと思います。それを自分たちで作り、運用もしているというのは、自分たちの強みの一つです。これまで、特にCI/CDに関して、社外に情報発信していくということはやっていなかったのですが、今後は、もっと積極的にアピールしていきたいですね。

高橋：社外の人たちに対しても「俺たちの作ったCI/CD、スゴイだろ」と自慢できるくらいのものにしていきたいと思っています。先ほど、川口さんが「CDFをお祭りの場にしたい」とおっしゃっていたので、その場にも参加できるようになりたいですね。

川口：ちょっと大きな話しになってしまうのですが、エンジニアが「エンジニアリングをやる理由」として「俺は良い仕事をしたんだ」と自分で自分に誇りを持ちたいというのがあるのではないかと思います。それが根幹にあるなら、自分の仕事を外へ発信するときに遠慮する必要はないと思うんです。

　相手に対して「へりくだる」とか「謙遜する」といった「日本的な良さ」はあると思うんですが、日本のエンジニアには、自分の矜持をもっと前面に出して、アピールしていって欲しいです。それは「いろんな人の意見を聞く」こととは矛盾しません。そういうアピールができる人の所に「ああ、この人と仕事ができると面白そう」と感じる人が集まってきます。いろいろな人が集まって、多様性のある集団が生まれ、そこで意見共有が始まると、結果として、1人ではたどり着けなかったようなところに到達できたりします。

　日本の場合、そういう意味でわりとコミュニティが「閉じている」印象があるんですよね。もっと「多様性」を受け入れてほしいと思います。一度、アメリカへ来てみたり、会社を変わったりする中で、多様性や、それによるソフトウェア開発の違いなどを感じてみるというのもよい経験になるのではないでしょうか。

高橋：自分は、一度、アメリカの開発チームと一緒にプロジェクトを推進した経験から、それをすごく実感できますね。メンバーの考え方もいろいろで、チームに入ってきたばかりの新人がガンガン主張するのにも、ちょっと驚きました。

中山：「新人が空気を読んで意見を言わない」というのもそうですし、カンファレンスなどでQAの時間に質問があまり出ないというのも日本独特ですよね。米国のカンファレンスでは、参加者が、たとえ内容を理解できていなくても（笑）、物おじしないで堂々と質問し、自分の意見を表明してます。ヤフー社内は結構オープンで、あまり上下関係で言いたいことを躊躇するような雰囲気はないのですが、今後は社外も含めて、自分からの発信を意識したいですね。

高橋：逆に、意見を言われる方、受けとる方も意識を変えていく必要がありますよね。これまで、そういう経験が少ないので、いきなり強くアピールされたり、意見を表明されたりすると驚いてしまうというのもあります。ダイバーシティが増していく中での組織の課題でしょうね。

川口：ここ10年で、ソフトウェアの作り方は大きく変わったと思います。かつてはチームで開発しているといっても、それぞれに役割が振り分けられての分業という形が中心でした。今は、ゴールに対してチーム全体でコミットして動くということが当たり前になってきています。たった10年で、それだけ変わるのであれば、日本での働き方のモード、新人への指導、アピールの仕方、議論の仕方といった、これまで日本の「古き伝統」として守られてきたものが、10年後には世界的に見ても最先端の、まったく別のものになっている可能性はあると思います。そういったものを生かせるように、ソフトウェア開発の方法論を変えていくこともできるのではないでしょうか。

中山：それについては、私たちもここ数年のパラダイムの中で同じようなことを考えていますね。ソフトウェア開発全体を見ると、さまざまなナレッジやベストプラクティスと呼ばれるものはありますが、まだまだ固まっていないところもたくさんあって、多くのチャレンジが残されていると感じています。

　例えば、ヤフーではスクラムなどのアジャイル開発手法も広く取り入れているのですが、全くの初学者にとってスクラムチームでの活動はそもそも仕組みや仕様などがわからないことが多すぎて周り道が多いのかもしれません。全くの初学者であれば従来のような徒弟制度的な形でサポートするほうが成長が早いかもしれないと感じることもあります。

　また、ある業務のための「セオリー」を新人に教えるにあたって、どうすれば一番効率がいいのかというのもその一つですよね。セオリーは「守破離」の「守」で、まず決まっていることをそのとおりにやってみることで、先に進むにあたっての逸脱や遠回りを避ける意味で重要なのですが、「ここを守って」というラインをどう設定するかというノウハウは、今のソフトウェア開発の世界にはあまりないように思います。昔からコードの「写経」というものはありますが、そこに、もうひと工夫あると、立ち上がりがもっと早くなるのではないかと考えたりもしています。

川口：「守破離」の考え方はよいですね。まだ固まりきっていない部分を、システマティックに体系化していくという試みは、非常に意味があると思います。

中山：川口さんのCDFへの思いを伺っていて、「CI/CDを普及発展させていくにあたってどう取り組むべきか」といった部分での「守」を体系化されていこうとしているのかなと感じました。「自分たちの工夫はとりあえず置いておいて、まずはこの部分を守る。そうするとうまくいく可能性が高まる」というCI/CDに関するナレッジが具体化されると素晴らしいですね。

川口：それができると、CI/CDを通じて「世の中の進化を加速させる」ことに大きく寄与すると思います。

高橋：CI/CDやアジャイルと言った分野は、ソフトウェア開発の中でも、まだまだチャレンジの余地が多い分野だと思います。われわれとしても、その実践にあたってさまざまな挑戦を続け、その知見を発信していきたいと思います。本日はありがとうございました。