“開発自動化のカルチャー”はどう作る？　マイクロサービス導入時に注意すべきポイント

マイクロサービスのアプリケーション開発のポイント

新野淳一氏（以下、新野）：ちょうどコンテナの話が出てきましたが、コンテナを使ったアプリケーションを作るというのはマイクロサービス的な考え方に近づいていくと思うので、そのまま3つ目のアジェンダ、マイクロサービス。

実際にコンテナを使ったアプリケーションを作るということはよく言われていることなんですけど、「クラウドネイティブ的にマイクロサービス的なアプリケーションをコンテナを使って開発します」というとき、戸倉さんならどういうところがポイントだとお話をしますか？　起塚さん太田さんにも順に聞いていこうと思います。

戸倉彩氏（以下、戸倉）：マイクロサービスのアプリケーション開発のポイントとしては、私は大きく2つお伝えしています。

1つがオープンソースの取り組みになります。まだまだ企業によってはオープンソースとの向き合い方に関して試行錯誤されていたり、例えばマイクロサービスでアプリケーションの開発をやるうえで環境自体がかなりオープンソースと……。

新野：Dockerもオープンソースだし、Kubernetesもオープンソースだし。IBMの例で言うと、Red Hatのスタックは全部オープンソースですからね。マイクロサービスを実現するうえで、オープンソースとの付き合いは避けて通れないですね。

戸倉：そうなってくると、例えば下で動いているものは、コミュニティがサポートしているものを使うのか、それともちゃんとベンダーがサポートしているものを使うのか、というようなところですね。

要は環境を構築するだけではなくて、実際にはそれを運用していかなければいけないので、運用のこともイメージしながら。なにか問題が起きたときに、どういう設計になっているかによって、そこに掛かる負荷が変わってくるので。

マイクロサービス化するという部分を、いきなり手広くやるのではなくて、慣れていないうちはきちんと目的に合っているところから徐々にフェーズを踏んでやっていくということもポイントになってくるかなと思います。

新野：1つはオープンソースとの付き合い方で、2つ目はいきなりではなく手をつけられるところからつけていく。

戸倉：そうですね。

新野：ちなみにどのへんが手をつけやすいところだと思います？

戸倉：これはやはり企業の体制であったり。最近、コンテナを触るエンジニアのバックグラウンドがかなりばらつきがあるというのがすごく感じるところです。

新野：スキルのばらつきなのか、ジャンル？

戸倉：両方ですね。コンテナはインフラ寄りの人たちもすごく期待しているし、またデベロッパーも自分がやりたいことに集中できるという意味で期待しています。コンテナ上でアプリ開発をするということになると、ある意味DevOpsと言われているデベロッパーとオプスの両方が交わって運用していくようになってくるので。

例えば、すでにインフラの人が仮想化をきちんと過去からやっていて、あるいはクラウドでの運用管理にも慣れている場合だと、そこで載せられそうなところ。あるいは、コンテナの特性を活かす意味で、例えば、アプリケーションの開発を早いサイクルで検証しなければいけないというところは、クラウドネイティブは相性がいいかなと思います。

新野：開発環境を先にクラウドネイティブ化するほうが話が早そうですね。なるほど。おもしろいですね。

マイクロサービス化にあたって経営層を説得するには

新野：起塚さんもクラウドネイティブ的、マイクロサービス的なアプリケーションに足を踏み入れていらっしゃると思うんですけれども、どのへんから入っているのか。あるいは、実際にやってみてここがポイントだと思われるところはどういうところですか？

起塚宏道氏（以下、起塚）：先ほどから、なにも知らないところからスタートしていると言っていますけども、始めるポイントとしては経営層をどう説得するかというところ。やっぱり経営層がお金をかけてくれないとなかなか進まないなというのは本当に実感しています。

弊社の場合、新事業ということもあって比較的投資してもらいやすかったのはラッキーでした。

お金を引っ張ってきたら、僕たちの場合はIBMのグローバル・ビジネス・サービスにクラウドネイティブやクラウドの開発について教えてもらいました。「ある程度スキルを手に入れた」ということで今はやっていないんですけども（笑）。

たぶんここに来られている方はかなり実感しているとは思うんですけど、マイクロサービスというのはかなり難しくて、今まで自分たちが考えていたものがゴロっと変わったりすることが多いんですね。

僕たちはけっこう早めにマイクロサービスにとりかかっているとは思うんですけれども、今までの知見というのがないところに対して、知見のある人の意見を聞けるというのはすごく大事です。

IBMとか、ほかのところでもいいんですけども、マイクロサービスをやったことがある人にサポートに入ってもらって、対価を渡してしっかりと教育してもらうというのがすごく大きいポイントだなと僕は思っています。

新野：もう少しそこの2つのポイントを詳しくお伺いしたいんですけど。2つというのは、1つは社長に直談判してできるようにしたっていう（笑）。何が足りなかったのかという話と。もう1つは、マイクロサービスの経験者に話を聞いて習ったというときの、何が印象に残ったかというのをお伺いしたいです。まずはどういう権限をもらったのか、あるいはどういう予算を取りにいったのか。そちらから聞いてもいいですか？

起塚：予算を取る前に、そもそも役員に見せる資料からある程度マイクロサービスを意識した作りを持っていくというところはもちろん大事です。そのうえで先ほど言ったように金融のお客様が対象なので、その堅牢性であったり、マイクロサービスを使ったときにこういったメリットがありますよということをしっかりと資料にして、こういったことをしたいので支援を絶対してくださいと。

僕たちより役員の人たちは詳しくないので、「やりたかったらやったらいいやん」とは言われるんですけど、そのときにやはりどれくらいの費用がかかるのかというところをしっかりと見せる。僕たちも「費用がいくらかかるかわかりません」と言っちゃうと、やはりお金は出してもらえないので、「これをしたいのでこれだけかかります」というかたちでお願いするとよかったですね。（笑）。

新野：えらい人が「今までどおりやればいいじゃん」と言う可能性もあったかもしれないわけじゃないですか。そこはどう説得されたんですか？

起塚：1つラッキーなのは、僕たちには今までがなかったというところですね。「こうするのが今のトレンドです」というところで説得できたのはラッキーでした。

新野：なるほど。じゃあ少し話題を変えて2つ目の質問で、起塚さんはマイクロサービスやクラウドネイティブ的な経験がないところからIBMの支援を借りて学んで、今（マイクロサービスに）取り組んでいらっしゃる。学びの過程で印象的だったことをいくつか教えていただいてもいいですか？

起塚：もともと僕たちは3人で始めたというのは最初に話しましたけれども、人数が少ないからPaaSでやりました。そのときIBMからKubernetesを使うと便利ですよというかたちで紹介されたんですけど。いまだに、「僕、ちょっと騙されたかな」っていう。

新野：どのへんが？（笑）。

起塚：やはり僕たちとして、最初にPaaSを選んだのはインフラの知識がないところからスタートしたのに、「Kubernetesいいですよ」と言われて、確かに良さげで、教えてもらいながら始めたら、「めちゃくちゃインフラの知識いるやん！」って。

今にして思えば、本当のインフラエンジニアに比べるとぜんぜん知識は要らないんですけれども、それでも僕たちからするとインフラの知識が要る。IBMと話をすると、当然かなりインフラの知識を持っているんですね。それを見て、やはり僕たちもAnsibleとかそういったものを使わないといけないなと。本当になにを学んでいったらいいのかということが少し見えてきたのが印象的でした。

インフラ周りの責任分界点

新野：今どんな課題を抱えてらっしゃるのかも聞きたいんですけど。それを聞く前に太田さんにコメントをもらってもいいですか？　

今起塚さんから、アプリケーションエンジニアもKubernetesを使うとインフラのレイヤーのことを知らなきゃいけないというコメントがありました。これは本当ですか？

太田航平氏（以下、太田）：イエス＆ノーだと思っていて。というのは、たぶん今のお話を聞く限り、インフラ専属の方がいらっしゃらないから。

新野：いないですね？

起塚：いないです。

太田：だから下回りのことも見なきゃいけないという話が大きく含まれていると思います。その一方で、僕がイエスと言った理由は、アプリケーションの観点からインフラの部分をいじりたいというシーンが出てきたときに、それをいじれる自由度の高さがKubernetesにはあるので。

そういう意味で、インフラの知識があったほうがよりKubernetesを活用できます。コンテナ自体も、仕組み上はただのLinux関連の命令を呼んでいるにすぎないので、より深いところを知っていれば知っているほどコンテナ自体もより活用できるというのは正しいと思います。

新野：なるほど。あとで太田さんには改めて詳しく聞くつもりなんですけど。太田さん的にはアプリケーションエンジニアがそうやってKubernetesまでいじるのを是としますか？　それともインフラエンジニアに任せろと思いますか？

太田：ケースバイケースじゃないですかね（笑）。個人的な意見で言えば、そこは組織で制約を設ければいいと思っています。あいまいな部分は対話によって埋めることもできますし、様々なやり方があるのではないでしょうか。

あとは、今持っている知識と、その組織でカバーできる範囲を考えたうえで責任分界点を設定してあげることが、基盤を設計したり全体のアーキテクチャを作るうえでは非常に重要だと思っています。

新野：ありがとうございます。ちょっと起塚さんにマイクを戻していただいて。起塚さんの話を続けて聞きたいと思っているんですが、今の太田さんのコメントに反論したいこととかあります？　

起塚：とくにないです（笑）。やはりKubernetesをやって、インフラエンジニアに対しては前ほど重要性が減ってきているのかなというところで。アプリケーションエンジニアが兼任できてしまうという。これがしんどさでもあり、いいところだと思います。

新野：起塚さん的にはインフラエンジニアを採用しようかなとか育てようかなという気持ちにはなっているんですか？

起塚：やりたいとは言ってるんですけど、なかなかバジェットがつかないというところですね。

マイクロサービス的なアプリケーション開発のハードル

新野：そのあたりも含めて、今Kubernetesを使ったマイクロサービス的なアプリケーション開発にチャレンジされていらっしゃるところですよね？　

起塚：はい。

新野：苦労話とかもしあったら教えていただけませんか？　ここがハードルになっているとか、あるいはここはすごくうまくいってるという話でもいいんですけど。

起塚：やはりマイクロサービスで開発するうえでは、マイクロサービスらしく作りたいじゃないですか。ただマイクロサービスで作るときに、今までのオブジェクト指向などの古い技術の場合だとデザインパターンだったりアンチパターンだったり、そういったノウハウというのがすごくあるんですね。

ただ、マイクロサービスに関してはまだここから先の話なので、どのプラットフォーム、あるいはどのスキルが要るかもわからないんですけど、情報が少ないというところがかなりきついですね。とくにマイクロサービスに関しては、ほとんど洋書を読むしか情報を入手する手段がないというところがやっぱりつらい。

それともう1つあるのが、マイクロサービスをやり始めて、一番最初につまずくのが2つくらいあると思っていて。1つはDDDですね。Domain driven Development（ドメイン駆動設計）。DDDは日本ではたぶんスキップされちゃってるんだと思うんですよね。

開発の人数が少ないので、開発委託をお願いすることがけっこうあるんですけど、そもそもマイクロサービスの切り出しができない。ドメインドリブンができないのでマイクロサービスの切り出しができないというところがあります。

新野：そもそもマイクロサービスでサービスごとに切り出すときには、ドメインを意識して切り出さなきゃいけない。だけどそれをどうやったらいいのかというちゃんとしたガイドラインがなかなか見つけにくい。

起塚：それとデータですね。データの持ち方が今までとカルチャーがまるっきり変わってしまうというところですね。そこでかなり苦労していますね。

マイクロサービスを始めるときに誰もがつまずくポイント

新野：けっこう残り時間が少ないので、もうちょっと聞きたかったんですけど、太田さんに。

太田さん、先に聞いてもいいですか？　データのところすごく頷いていらっしゃいましたけど、それはどういう意味だったんでしょう？

太田：僕はドメイン駆動とデータはものすごく密接に絡んでいると思っていて。先に超つらい話をするんですけど、僕が以前関わっていたプロジェクトで、マイクロサービスのようなものを作ったことがあって。

そのときにデータベースの構造がものすごくぐちゃぐちゃになったことがあって。具体的には、マイクロサービスとしてコンポーネントが分かれているはずなのに、いろいろなDBからいろいろな情報を参照するみたいな構造になってたんですね。モノリスのアプリケーションだったらその構造が当たり前なんですけど、マイクロサービスだと変わってくる。それを原則として知らずに作っちゃった人がいて、とんでもないことになりました。

なので、ドメインを切り出すというのもすごく大事だし、それと同じタイミングでデータ構造をきちんと定義してあげるというのがマイクロサービスを開発するうえで非常に重要だと思っています。

新野：それ少し……まだ僕ちゃんと理解できてないかもしれないですけど、最初の失敗の話は、アプリケーションのモジュールは分かれていたのにデータベースはなぜかモノリスっぽくなっていたのでちゃんと分離するのに成功しなかったということですか？

太田：そういうことです。マイクロサービスを始めたら最初に誰もがつまずく道だと思います。

新野：ということは、本当はちゃんと分離するためにはデータベースそのものもいい感じに区切ってそれぞれ独立するように作るべきであると。

太田：そうですね。僕たちはECサイトを作っているのでECサイトを例に出すと、例えばユーザーが「ある商品を買いたい」と言ったら、まずユーザーデータ情報があって、アイテム、商品一覧があって、それを誰がいつカートに入れたかというカート情報があって、それを買った、買わなかった、みたいな決済情報があって……と複数の情報が必要になります。

それぞれがユーザー情報を参照したり、どのアイテムがどのカートに入っているか参照するみたいなテーブルがあるんですけど、それをデータベースの中でjoinして引っ張ってくるのではなくて、ちゃんとマイクロサービス上で呼んであげないとそのマイクロサービスは破綻してしまいます。

新野：大事な話ですね。でも、いかに難しいかというのが考えただけでもわかりますね。

太田：そうですね。あと通信のオーバーヘッドが一気に上がってしまうので、そこも重要なポイントだと思います。

重要なのは、ちゃんとテストを書くこと

新野：今のお話も大事なポイントで。それ以外にもなにかマイクロサービスでポイントがあれば教えてください。

太田：これも組織論の話になっちゃうんですけど、相互理解をしないと難しいと思っています。さっきのドメイン駆動とかデータ構造の分割の話は、インフラレイヤーも適切に分割する必要があるし、サービスも適切に分割する必要がある。ひいては、開発の中のコードの設計も適切に分割する必要があるんですよ。

適切という言葉はすごく便利なんですけど、要するに「いい感じに」とか「いっちゃんええやつ」みたいなふわっとしたもので終わってしまうんですよね（笑）。でも、そこが一番泥臭いところであり重要になってくるので、インフラとか開発とか関係なくちゃんとプロダクトとして決めて共通化してあげるということが大事になってきます。

新野：それは誰が決めるんですか？　それってある意味組織分割に近いわけじゃないですか。組織構造とコードの構造は似るってよく言いますよね。なので、うまく切り分けるには組織上もいい感じに切り分けなきゃいけないと思うんですけど。

太田：そこで苦労してるタイミングで、コンウェイの法則や逆コンウェイの法則を意識するのはちょっと違うと思うんですね。結果としてそうなることもありますが、結局は1人ひとりが自分ごととしてやっていくことに帰結すると思うんですよね。

新野：なるほど。でも、太田さんはそれについて気をつけているところはあるはずですよね。

太田：下からはボトムアップで、上からはトップダウンでちゃんと意見を言い合える心理的安全性を保てるところじゃないですか。

新野：カルチャーの話も当然開発サイクルの自動化に関わってくると思うので、これをうまく回していくうえでどうしていらっしゃるのか教えていただけませんか？

太田：まずはちゃんとテストを書くことだと思います。

新野：なるほど。

太田：テストを書かないと、デプロイできるできないも判定が難しくなってしまいますし、「ああ、なんでこんなしょうもないミスやらかしたんだ」ということに気づけない可能性もあります。なので、ある程度の型の安全性を保ったり、型のない言語でも型推論にちゃんと頼れるようにテスタブルなコードを書くのが大事です。それをさらに自動化で回していくということも大切だと思います。

僕たちが普段やっている余計な作業の自動化を推進することも大事です。ドメインを切って、ちゃんとアプリケーションを設計して、よりよいコードを書くことに集中できる環境づくりというか。

新野：なるほど。あと、こういう環境を構築することそのものもハードルだったりするじゃないですか。これは例えば太田さんの部門だとどう解決されていらっしゃいます？

太田：そこでもやっぱり対話が重要になるかなと。今動いているCI/CDパイプラインは僕が2日くらいで書いたやつなんですけど、それが今でも動いているというのがおもしろい話だと思っていて。何を一番解決したいかをしっかりヒアリングして、開発者の気持ちに寄り添いながら作ったものなんですよね。

開発を自動化するカルチャーをどう作ったか？

新野：ありがとうございます。起塚さんにもこの話題で、開発に取り組んでいらっしゃいますよね？

起塚：はい、やってますよ。

新野：具体的にはどういうことをやっていて、どういうハードルがあると感じていらっしゃいます？

起塚：やはりテストも確実に大事なので、ユニットテスト、インテグレーションテスト、最近だとアクセシビリティテストまでをどうやって自動化するかというのは、ずっとテーマにしてやっていっています。

それ以外で開発プロセスというところでいくと、やはりスクラム開発ですね。スクラムとの親和性が高いので、スクラムをどう回していくのかというとどうしても開発が大きくなりがちなので、その上にある大規模スクラムをどう回していくかはすごく大事です。

ちょうど2月の頭にベトナムに行ってきたんですけど、ベトナムのオフショアベンダーでこのCI/CDを回すためにということで、パイプラインを書ける人を一緒にベトナムに連れてきて。ベトナムのマネージャーと話をしながら、ベトナムでテストをするためにどういうパイプラインを作るのかを聞き取りながら、ベトナムで開発して帰ってきたというようなこともやっています。

新野：ちなみに、テストを書くとか開発を自動化するカルチャーというのは、組み込みのときにはあったんですか？

起塚：ぜんぜんなくて。来週くらいに組み込み向けのテスト自動化について講演してくれということで、社内で勉強会をやろうかなと思っています。

新野：逆に、クラウドネイティブ的なカルチャーが組み込みのほうに影響を与えているということなんですね。

起塚：そうですね。

新野：ということは、やはり価値が理解されつつあるということなんですかね？

起塚：そうですね。

新野：どんな価値を理解されたかとか、どんなふうに変わってきたのかを少し聞いてもいいですか？

起塚：やはり組み込みのほうもそうなんですけども、開発のカルチャーが変わってきていますね。今までと違って、顧客にどういう価値を提供するのかというところになってきているので、もっと顧客に寄り添ったデバイスになってきていて変更がすごく多い。特注もすごく多い。そのときに、やはりテストで1ヶ月2ヶ月かかっちゃいましたではちょっと話にならないというレベルになってきていますね。

新野：最後にテストを持ってくると、そこに時間がかかっちゃうという感じなんですね。ただそういうカルチャーがないところに、「これから君はコードを書くたびにテストを書くんだ」というのは、心理的なハードルはあるんじゃないですか？

起塚：ありますけども。最初に一緒に始めた先輩社員が上手にカルチャーの伝授をやっていっています。やっぱり僕たちもモブプログラミングとかかなりやるので。

新野：みんなでプログラミングするやつですね。

起塚：そのときにもう書いて当たり前ということを刷り込んでいくようにしていますね。

新野：なるほど。それによってたぶんベトナムの人にも、オフショア先にもそういう刷り込みをやったんですか？

起塚：ベトナムの場合は言葉が通じないんですけど、管理をしてくれている委託先がいるので、そこと一緒にやって何回もやりとりをして、「このテストだとダメだ」とか言いながらやっていますね。

新野：テストの書き方もレベルというか、上手い下手があるわけじゃないですか。そこも教えつつということですか？

起塚：やはりモブプロをやるとけっこう揃ってくるような感じは確かにありますね。

新野：なるほど。モブプロいいですね。そういういい例、僕は実は初めて聞いたので、いいなと思いました。

継続的な学習の重要性

新野：じゃあ戸倉さんにも。開発プロセスをうまく回していくためには。

戸倉：私がセミナーなどをしているときに少し驚いたのが、自動化を回していくためにはやはりテクノロジーを活用していかなければいけないんですけれども、ずっとオンプレで育ってきたエンジニアの方って、自動化、仮想化に抵抗感というか、「自動化しなきゃいけないんだっけ」みたいな感じになっていますね。

自動化できるツールは世の中にいろいろありますし、Kubernetesもそうですけども、オープンソースになっているツール自体も常に進化し続けているので、やはり自動化を回すということは、1回自動化をセットしたらそのままではなくて、わりと継続的な学習をさせながら回していくというところは1つ気をつけないといけない部分じゃないかなと思います。

新野：「手動でもいいじゃん」と言う人は多いと思うんですけど、そういう人に対してどういう言葉を返してますか？

戸倉：「寝る時間なくなるよ」と言っています。

新野：「ビルドコマンド打てばいいじゃん」みたいな。

戸倉：そうですね。私VSCodeの連載をしていたりするので、けっこういろんな方とVSCodeの話をしたり、たまに「スニペットどんなの登録してる？」という話をしたときに、Kubernetes系だったりコンテナを回すためのスニペットをやたら入れている人がいますが、これはツールの中で解決できるんじゃないでしょうか。

「この人も自分で1個1個コマンドを実行してテストしていきたい人なのかなぁ」というのが、実は開発ツールを見せてもらうと見え隠れするというのがあります。

表現としては、よく「自分もインストールしていく」と。バージョンアップしていかないとクラウドネイティブはどんどん前に進んでいっているので、一緒に自分たちも新しいものを受け入れながら加速していこうという言葉はかけるようにしています。

新野：さっき起塚さんがモブプログラミングがすごく役に立っているというか、うまく巻き込めているという話をしていましたが、うまく巻き込む手法はなにかお持ちですか？

戸倉：Visual Studio Codeの中にLive Shareという共有できる機能があって、私はけっこうそれを使っています。

新野：Live Shareって、別々のパソコンの画面を同期できるというやつですね。

戸倉：そうですね。両方にVSCodeが入ってなければ実現しないんですけれども。そういうエディタも無料でわりと手軽にモブプログラミングできるようなものも増えているので。

あまり構えなくても楽しみながらやれるというのが、今はすごくいい時代であり、モブプログラミングの醍醐味でもあるかなっていう。

新野：ペアプロだったりモブプロだったりですね。ツールを使うのはいいですね。

クラウドネイティブを導入する人に向けたアドバイス

新野：というわけで、残り時間が少なくなってきましたので、最後はみなさんに一言ずつ、これからクラウドネイティブを導入し発展させていく気持ちを持っている人たちに少しアドバイスをいただいて、そのあと質疑応答があれば対応したいと思います。アドバイスを一言いただけませんか？

戸倉：私は、やはりクラウドネイティブが日本で発展するかどうかは自分たちにかかっていると思います。いろいろな人たちが国内でいち早く使って、そしてオープンソースになっている部分にはみんなでそこに参加していく。

テクノロジーも変革を起こしていくということで、最後は自分たちがクラウドネイティブの恩恵を最大限に受けられるかなと思うので、クラウドネイティブにあまり馴染みのない方は、これを機にまずは手を動かすところから始めてみていただければと思います。

新野：じゃあ起塚さんもアドバイスをお願いします。

起塚：手を動かすというのは大事なんですけども、やはりIBMのようにわかっている人にいろいろな指導を受けて……クラウドネイティブやマイクロサービスは間違っちゃうとかなり遠回りしちゃうので、なるべく最短距離を走っていってほしいなと思います。あとはIBMの方にお願いなんですけど、マイクロサービスの本を出してください。

新野：情報充実は大切ですよね。ありがとうございます。太田さん。

太田：僕は2つあって、1つ目が自分で勉強するときにどうしたらいいかというポイントですね。それに関しては今起塚さんもおっしゃっていたんですけど、ベンダーを使ってみましょうというのと。

あとは、僕自身Docker MeetupやCloudNative Days Tokyoというカンファレンスを開催する身でもありますので、コミュニティを活用してほしいなと思います。オープンソースというところもあって、ものすごい知識を持った人たちがたくさんいますし、もしかしたらあなたと同じ経験をした人もいるかもしれません。というところで、仲間を見つけるというのも重要かなと思います。

2つ目が、たぶんみなさん、社内の人にどうやってこういう技術を広めていったらいいか迷っていると思うんですけど、僕は成功体験を与えてあげるのがすごく大事だと思っています。結局、メリットを感じられないと使う気にならないので。

そういう意味で、さっき言ったようなモブプロだったり、スクラムを使って……スクラムって本質的には一定の成果をそこそこの人数で出すためのメソッドなので、強い人が1人いる段階だとけっこうばらつきが出ちゃってあんまりうまくいかないんですけど、初心者の人がいっぱいいる段階でスクラムを使ってやってあげるというのはいいんじゃないかなと思ったりはします。

新野：ありがとうございます。