スクラムマスターの役割とは何か？チームと環境の変化で“変わる”取り組みと“変わらない”原則

ヤフーとChatworkのスクラムマスターが語る「リモートでのスクラム」「大規模スクラム」

2022/08/24 12:00

　2001年の「アジャイルソフトウェア開発宣言」から20年以上が経過し、アジャイル開発の認知や実践は大きく広がりを見せています。一方で、社会や環境の変化に適応するように、その実践の形も、姿を変えながら進化を続けています。今回は、スクラムマスターを務めるヤフー田原慎也氏とChatwork 粕谷大輔氏に、「リモートでのスクラム」「大規模スクラム」など、アジャイル開発、特にスクラムにおける、ホットなトピックについて語っていただきました。

ともに複数チームでプロジェクトを推進する2人のスクラムマスター

田原：ヤフーの田原です。スクラムマスターを務めるようになったのは1年ほど前からで、まだ初心者です。今回は、自分のこれまでの取り組みをお話しして、エキスパートである粕谷さんに、いろいろと突っ込んで、教えていただければと思っています。

粕谷：Chatworkの粕谷です。こちらこそ、よろしくお願いします。田原さんが関わられたプロジェクトで、スクラムを採用したきっかけは何だったのですか。

田原：2021年に予定より1年遅れで開催された、国際的なスポーツイベントに関するプロジェクトで、はじめてスクラムを採用しました。

　過去に何度か、ウォーターフォール的な進め方で大規模開発を手がけた経験がありました。その際、度重なる仕様変更や、開発終盤に集中するテスト、大きな単位でのコードレビューで、開発者のやるべき作業が極端に増えてしまったり、設計からリリースまでの期間が長くなるにつれて、再確認の必要な事項が積み上がったりといった状況に課題を感じていました。

　スポーツイベントのプロジェクトは、開催期間が決まっており、コロナ禍の影響もあって、進行に柔軟性が必要になると感じ、以前から関心のあったスクラムをやってみようということになりました。その後も、スポーツイベントの北京大会や、現在、ヤフーで提供しているスポーツコンテンツ「スポーツナビ」の開発に、引き続きスクラムを取り入れています。

田原慎也（たわら・しんや）氏

　ヤフースクラムマスター。新卒で最初に入社した会社で、9年ほど、主に官公庁向けのシステム開発、インテグレーションを手がける。その後の転職先では、ソーシャルゲーム開発に携わり、アジャイル的な手法を経験。ヤフーには2014年に入社し、「Yahoo!ショッピング」の開発に携わった後、国際的スポーツイベントの特設サイト構築を担当。現在は、スクラムマスターとして「スポーツナビ」の開発・運用を手がける。

　粕谷さんは、いつごろからアジャイルやスクラムに関わられてきましたか。

粕谷：アジャイルでの開発をやるようになったのは、2012年に転職した会社からです。当初はスクラムではなく、エクストリーム・プログラミング（XP）から始めました。その次に入った会社では、これからスクラムに取り組もうとしているチームに配属され、XPの経験があったことや、個人的にも興味があって勉強していたことなどがあり、流れでスクラムマスターを務めるようになりました。後に管理職的な立場になったのですが、その中でも、自分のスクラムに関する知見を組織の中で広く適用していくことに関心を持ち、そのための活動をしていました。

　その後、自分が関わるチームでは、うまくプロジェクトが進むようになっていましたが、次第に、別の組織やチームで、自分のスクラムマスターとしての実力を試してみたいと思うようになり、現在の所属であるChatworkに転職しました。

　Chatworkでは、「Scrum@Scale」と呼ばれる、大規模開発向けのスクラムに取り組んでおり、現在、2つのチームを見ています。

　田原さんがスクラムマスターとして見ているチームは、どんなチームですか？

田原：構成としては比較的シンプルです。企画、デザイナー、エンジニア、プロダクトオーナーが参加していて、人数的には、国際的なスポーツイベントのプロジェクトの場合、1チーム7人前後の3チームといった感じでした。人数の比率としては「企画：デザイナー：エンジニア」がだいたい「1：2：4」くらいでしょうか。

粕谷：私が今、Chatworkで関わっているのはアーキテクチャを刷新するプロジェクトなため、メンバーはエンジニアが中心ですね。これについても、ゆくゆくは、いろんな立場の人が参加するクロスファンクショナルなチームに育てていきたいと思っています。

「スクラムマスターのやるべき仕事」をなくすのが仕事？

――お2人は「スクラムマスター」の役割をどう捉えていますか。

粕谷：スクラムの勉強をしていると、よく「スクラムマスターとは“サーバントリーダー”である」と言うフレーズが出てくるのですが、私としては、それに尽きると思っています。「チームが成果を収める」ために、やるべきことをすべてやる。目標達成を阻害する要因を取り除く。そして、チームの自発的な活動をサポートする。これらが、スクラムマスターの果たすべき、中心的な役割だと思います。

田原：私が意識するようにしているのは、なるべく「自分は手を動かさない」ことですね。コーチングに近い考え方かもしれませんが、例えば、チームの状況を見ていて、この先ボトルネックになりそうな部分があれば、メンバーに問いかけて、自発的な改善を促す。問いかけた際は「自分で答えを出さずに、相手に答えを出させる」ことを徹底するようにしています。スクラムマスターの役割は、チームの状況を俯瞰し、そのパフォーマンスを最大限に発揮できるような状態を作ることだと思っています。

粕谷：「スクラムマスターの役割」という観点で、象徴的なエピソードを思い出しました。社内のスクラムマスター同士の雑談の中で「チームに新しく加わるメンバーのオンボーディングは、スクラムマスターの仕事なのか？」という話題が出てきたんです。

　これについて、多少の議論をしたのですが、私としては「スクラムマスターがやるべき仕事」が存在する時点で、そのチームは「自発的」になりきれていないと感じます。もし、どのメンバーにも割り振られていないタスクがあれば、チームで話し合って、今回のケースでは、だれがそれをやるのかを決められるチームのほうが、より「自発的」だと思うのです。

粕谷大輔（かすや・だいすけ）氏

　Chatwork株式会社エンジニアリングマネージャー。アドバンスド認定スクラムマスター／認定スクラムプロダクトオーナー。2001年に大学卒業後、SI、ソーシャルゲーム開発を経て、SaaSサービスの開発エンジニアやディレクターを経験。2021年よりChatwork株式会社にて「Scrum@Scale」をベースにした開発組織づくりに携わる。共著に「Mackerelサーバ監視[実践]入門」（技術評論社）、「開発現場に伝えたい10のこと」（達人出版会）。「わかばちゃんと学ぶサーバー監視」（C&R研究所）では監修を担当。

田原：今、お話を聞いていて「これはスクラムマスターの仕事」という固定観念が、自分の中にもいくつかあったと気付かされました。

粕谷：スクラムの枠組みでプロジェクトを進めていく際、「この仕事は、だれがやる」という認識の固定化は、あまり望ましくないと思います。それは「このコードは、この人しか触れない」という「属人化」と同じだからです。そうした、役割の固定化、属人化が起こらない環境を整えるというのも、スクラムマスターの役目のひとつではないでしょうか。

田原：なるほど。ただ、プロダクトを作っていく上で、メンバーの属人的なスキルが発揮される場面というのは、少なからずありますよね。スクラムマスターとして、そのあたりのバランスはどのようにとっていくべきでしょう。

粕谷：そこは程度の問題ではないでしょうか。プロダクトに携わる「チーム」を維持していく上で、役割の属人化が進み過ぎないようにする必要があることは間違いありません。

　一方で、例えば「ソフトウェア開発」には、「職人技」というか「専門職」的な要素があり、属人化から完全に逃れることは難しいとも言えます。

　「この人がいなくなると、仕事がまわらない」ほど、属人性が高まった状態は良くないわけですが、例えば「完全に同じスピードや品質では難しいけれど、この人がいなくなっても、チームで同じようなことをやろうと思えばできる」という状況が担保できるならば、ある程度、チームメンバーが得意分野で尖ったことをやっていくのは良いことだと思います。その前提で、私は「尖っていけ」とメンバーの背中を押すこともありますね。

田原：たしかに、企画職としてチームに加わっているメンバーに「今回はプログラムを書いてほしい」というのは無理がありますよね。分業を基本にしている以上、ある程度の専門性が生まれるのは避けられないと思います。

　ただ、デザイナーとコーディングエンジニアの境目にあるような作業については、だれかに作業が集中して、厳しくなりそうなときに「手分けしてやってくれる人はいる？」と軽く呼びかけると、手を挙げてくれる人が結構いる印象もあります。

粕谷：そうですね。タスクの内容に応じて他に呼びかけて、手分けをする場面は、よくありますね。

　田原さんは、スクラムマスターとして他にどんな働きかけをしていますか。

田原：「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ」といったスクラムイベントの状況を観察して、発言が少なかったり、反応が薄くなったりしているメンバーに「あなたはどう思いますか」といった呼びかけをしています。

　また、その呼びかけに、何らかの反応や提案があれば、その内容を基本的に承認して、チームとして実行するようにしています。この「新しい提案を即座に取り入れられる」というのは、スクラムの優れた点のひとつだと思います。われわれの場合は、スプリントを1週間に設定していますが、実際にそれをやって、うまくいかない部分があっても、レトロスペクティブを通じて、すぐに調整やリカバリができるのですね。

　「発言を促し、承認し、やってみる」というプロセスを繰り返すことで、チームの自発性が高まるという経験を、これまでに何回もしてきていますので、これについては継続して心がけるようにしています。

粕谷：それは良い働きかけだと思います。私としては、今、田原さんが話されたようなことに加えて「マンネリ化を防ぐ」ことを、意識的にしています。

　スクラムマスターとしては、チームに成長を続けてほしいのですが、一度、スクラムの枠組みが回り始め、メンバーが慣れてくると、常に同じリズム、同じことの繰り返しで仕事が進みがちになります。その時には、若干タフな質問をして、チームの安定状態を、あえて揺さぶるようなことをしています。

「リモートでのスクラム」に感じたメリットと難しさ

粕谷：田原さんは、スクラムマスター歴1年とのことですが、最初から「リモートワークでのスクラム」が前提だったのですか。

田原：はい。実際にやってみて、リモートワークとスクラムの相性は、非常に良いと思うようになりました。

　特に便利だと感じるのは、コミュニケーション面ですね。われわれの場合、リモート会議に「Zoom」を使っているのですが、全体での話し合いの途中に、必要に応じて「ブレイクアウトセッション」でサブチームでの話し合いをして、終わったらまた全体に統合することもやっています。実際の会議室でのミーティングだと、こういうことは意外とやりにくいです。あとは、Zoom上にメンバーが業務時間中、常に入れる「常設ルーム」を設けておき、作業中に何かあれば、そこで呼びかけられるようにしています。

粕谷：Zoomの「常設ルーム」へ常に入っておくことに、抵抗のあるメンバーはいませんでしたか。自分も、リモートワーク時の常時接続を、チームに取り入れようと呼びかけているのですが、うまく浸透できずにいます。

田原：もしかすると、抵抗がある人もいたのかもしれません。ただ、ヤフーの場合、以前からリモートワークで、チーム単位の「常設ルーム」を使っているケースがあって、慣れている人が多かったというのはあると思います。

　粕谷さんは、対面でスクラムマスターの経験を積まれた後で、リモートに移行されたのですよね。ご自身では、対面とリモートとの違いをどう感じていますか。

粕谷：最初の会社では、1カ所に集まって働くチームで、完全に対面でのアジャイルをやっていました。次の会社は、東京と地方に拠点があるところでしたので、ミーティングにテレビ会議を使うなど、拠点間のコミュニケーションがオンラインでした。今のChatworkでは、最初からリモート前提でプロジェクトを進めています。

　私の場合、リモートではない環境での経験が多いので、特に最初のころにはギャップを感じました。リモートだと、それぞれのメンバーが持つ雰囲気や仕草のような、ノンバーバルな情報が、どうしても不足します。スクラムマスターにとっては、チームの「観察」が仕事のひとつと言われるほど、重要な意味を持ちます。当初は「リモートで、どうやって観察すればいいのだろう」と戸惑いました。

　実際にリモートでスクラムを進めるようになってからは、少しずつ慣れてきました。Webミーティングで表示される顔の映像や、チャットメッセージの行間などからでも、ある程度、その人のコンディションが分かるようになってきたんですね。得られる情報から「日常との差分」を見つけ出し、その差分の意味を考えてアプローチするという方法もあるということが分かってから、リモートでも「観察」が可能だと思えるようになりました。

　ただ、ブレインストーミングなど、「ひらめき」を得るための作業は、リモートだと難しいですね。久しぶりに対面でミーティングをすると、チームも「アイデア出しは、オフラインのほうがやりやすいよね」という雰囲気になります。いろいろな意見があるとは思いますが、チームで「ゼロからイチ」を作り出すような作業をリモートでやるのは、難易度が高いと感じています。

田原：たしかに、全体でのアイデア出しなどをする際は、Web会議ツールだけでなく、ホワイトボードのようなものがあったほうがいいですね。われわれの場合は、別途、クラウド上のホワイトボードツールを使ったり、画面共有をしながら話したりという感じで補っていました。

　ただ、その環境だと「リアクション」が分かりにくいのが、少し困りました。反応が見えないと、発言に対して、メンバーが賛同しているのか、あるいは困っているのかの雰囲気が読めず、やりづらいと思うことがありました。

粕谷：対面であれば、軽く見渡して、表情や顔色をうかがうだけでも、かなりの情報が得られますからね。

　あと、通常の会話についても、リモートでは、発言者が身構えてしまうというか、「良い子」になりがちな傾向があるように思います。実際に顔を突き合わせて話す時は、若干表現が雑でも、「本音」に近い、泥臭い話が出てきやすい一方で、リモートだと、どうしても「意図がきちんと伝わるか」を意識するせいか、発言が取り繕いがちになる傾向があるように思いました。

田原：特に、テキストコミュニケーションが中心になると、誤解を招かないよう、細かい表現に気を遣う人が増える印象がありますね。そのために費やす時間も増えている可能性もあると思いますので、直接対面で言えれば誤解が生じにくいなと思うことが、よくあります。オンラインはオンラインの良さを、オフラインはオフラインの良さを理解して工夫することが大事だと思います。

粕谷：関連して、「コミュニケーション」そのものが少なくなることに対する危機感もありました。私の場合は、デイリースクラムとデイリーレトロスペクティブで、1日に2回、メンバー全員が集まる時間を作るようにしています。ほかにも、モブプログラミングの枠を意図的に設けるなどの方法で、コミュニケーションの量を増やすことを意識しています。

規模が大きくなるほど難しくなる「認識合わせ」をどう実現する？

――お2人は、複数チームで共通のプロジェクトに携わる、いわゆる「大規模スクラム」に、スクラムマスターとして関わっていらっしゃいます。その際に生じがちな課題や、それをどうやって解決しているのかを聞かせてください。

田原：リモートに限った話ではないのですが、複数のチームで作業を進めていると、チームごとに、独自の文化や「暗黙知」のようなものが生まれてきます。それは、同じプロジェクトに関わっていく上で、邪魔になることも多いです。

　われわれの場合は、毎回、各チームからランダムに2～3人のメンバーを選んでイベントに参加してもらうようにすることで、「チーム間」と「チーム内」で認識がそろっている状態を保てるように工夫していました。

粕谷：「各チームの代表者でイベントを実施する」というのは、何らかの大規模スクラムのフレームワークに則ってやったのですか。

田原：特に何かを参考にしたわけではないですね。最初は単純に、ミーティングで参加者が発言しやすくなるような人数を考えて、代表制にしました。

粕谷：実は「チームから代表者を出す」というやり方は、スケーリングスクラムの手法にもあります。現場で、うまくいきそうなやり方を考えていくと、自然とその形になるというのは面白いと思いました。

田原：メンバー数は、3チームの合計で20人以上でした。この人数で何かやろうとすると、どうしても時間がかかりますし、ミーティングで発言しないメンバーも出てきがちになります。発言者を偏らせない意図で、ランダムにメンバーを決め、少人数のミーティングで発言を促したいという意図でした。結果、この形にしたことで、チーム間で認識を共有しやすくなりましたし、自発的行動も増えたと思います。

粕谷：「スクラム」の大きな目的として、独自に判断して動くことができる、自己組織化、自己管理化されたチームを作っていくことがあります。しかし、大規模スクラムにおいては、それぞれのチームが自主的に動くことで、見ている目的地や進む方向がバラバラになってしまうという副作用が生じることがあります。プロジェクトに関わるすべてのチームが、ある程度、同じ方向を向くようにそろえていくのが、大規模スクラムを進める上でのポイントです。

　やり方としては、1つのバックログアイテムを複数のチームで処理したり、プロダクトオーナー（PO）同士が集まって意識合わせを行う「メタスクラム」的な取り組みを行ったりといったものがありますが、そうした方法を通じて、最終的に「チームの目線を合わせる」ことが、大切で、難しい部分です。

　われわれの場合は「Scrum@Scale」というフレームワークを、大規模スクラムに取り入れようとしています。フレームワークに準じることで、ある程度、やるべきことが整理された状態でプロジェクトに臨むことができます。

　私が特に悩んだのは、PO同士のコミュニケーションを、いかに密にするかという点でした。メタスクラムに加えて、なるべく「雑談」ができる場所を設けるようにしていました。社内で「POわいわい会」という、雑談OKな集まりを企画するなどして、まずは、PO同士が目線や認識を共有できるよう、特に最初は意識しました。

田原：各POを中心にした意識合わせという点では、週1回の全員が集まるレビューの後で、POからスプリントの方針を共有してもらうといったことを、われわれもやっていましたね。

粕谷：その際、インセプションデッキは作っていましたか。

田原：DoD（完成の定義）は作っていました。プロダクトバックログアイテムをDoneとするために、何を満たさなければいけないかを定義したもので、全体で共通のものと、チーム個別のものを作るようにしていました。

粕谷：チームビルディングに関して、何か実施したことはありましたか。

田原：正直に言うと、最初のプロジェクトの時には、みんな忙しすぎて、チームビルディングを意識してやる余裕はなかったですね。逆に、忙しすぎることで一体感が生まれて、同じ方向を向きやすかったというのはあったかもしれません。Zoomの常設ルームでの雑談も活発でしたし、それはそれで良い傾向だったと思います。

粕谷：チームが大きくなるほど、関わる人数も多くなり、全員で集まって、合宿のような形でのチームビルディングをやるのは難しくなります。本来はやるべきなのですが、数十人のリソースを拘束して、1日をチームビルディングに費やすのは、スクラムマスターとして気が引けてしまうのも分かります。メンバーが多いがゆえの悩みですね。

スクラムの「多様性」を受け入れると世界が広がる

――スクラムマスターを始めたころを振り返ってみて、現在、同様の立場で課題を感じている人にどんなアドバイスをしたいですか。

田原：この対談に先がけて、粕谷さんの「スクラムマスターって何をする人なの？」というブログを拝見したのですが、「スクラムマスターは、スクラムのフレームワークを守らせる仕事ではない」という言葉を見て「あぁ、自分は当初、それをやっていたな」と思い出しました。

　特に最初のころは、「スクラムとは何か」という固定観念にとらわれすぎていたことがありましたね。そうすると、自由度がなくなってしまい、進行度にも悪影響が出るようになります。

　例えば、「プロダクトバックログアイテムに、ユーザーストーリーを持たせる」というのは、スクラムを実践する中で推奨されるもののひとつですが、ここで「アイテムの価値は何か」にこだわりすぎると、ものづくりが進まないのです。データベースにカラムを追加したり、APIを開発したりという作業に対して「ユーザーに価値を提供する」ところまでをひとまとまりで考えようとすると、議論をする時間が長くなり1スプリントでは完了できなくなります。最近では、ある程度、割り切って作業するようにしています。

　スクラムを採用する上で、型としての「フレームワーク」に則ることは大切ですし、有意義だと思います。ただ、それはひとつの手段でしかありません。最終的には、その型を守ることよりも、自分たちで自分たちのスクラムを作り上げていくことのほうが、より大切だと思うようになりました。

　「自分たちのスクラム」を通じて、良いプロダクトが作れていると実感できれば、メンバーも、自分たちの作ったものや、自分たちの仕事の進め方に対する「誇り」や「満足感」を得られるようになることを、今では実感しています。

粕谷：作り方の議論に時間を割きすぎて、実際に動くものを作る時間が減ってしまうと、スクラムの意味がないですからね。

田原：あと、国際的なスポーツイベントのプロジェクトでは、当初3つのチームで、それぞれにスクラムマスターを立てていたのですが、その時、自分は「隣のスクラムが良く見える」状態になったことがありました。

　特にスクラムマスターを始めたばかりのころは、他のマスターが回しているチームと、自分のチームの状況を比べて「あちらのチームはうまくいっているのに、自分はそうできてない」と感じてしまうことが多々あると思います。でも、そのあたりの課題感をメンバーに打ち明けると「そんなことはない」「今の進め方で良いと思っている」と、ポジティブな反応があることも多かったのですね。今では、自分のチームをほかのチームと比べすぎずに「自分たちのチームにとって、一番合うやり方を作っていく」という意識を持つことが大事だと思っています。

粕谷：他のチームを見て、良いやり方をしていると感じられるのであれば、自分たちもそのやり方を取り入れればよい話で、引け目を感じる必要はまったくないですね。それよりも、チームが納得して仕事をできていることのほうが大切です。

　では、私からは、スクラムマスターのキャリアについて触れましょうか。著名なスクラムトレーナーである、Zuzana Sochova氏（Zuzi）の『The Great SucrumMaster: #ScrumMasterWay』という本（日本語版タイトルは『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ』）には、スクラムマスターには「3つのレベル」があると書かれています。

　レベル1は「チーム内の関係性を整える」。レベル2は「チームと外との関係性を整える」。レベル3は「会社全体、システム全体を整える」。つまり、自分の影響範囲を、チームの内側から、外側へと段階的に広げていくことが、スクラムマスターの成長過程だと捉えることができます。

　スクラムマスターの仕事が「人やチームの関係性を整える」ことだとすれば、会社組織の中でも、例えば、VPoEやCTOといった方向性で、キャリアに幅広い選択肢が見えてくるのではないでしょうか。その意味で、スクラムマスターは、応用力の高いスキルだと言えます。今、スクラムマスターに関心を持っている人は、自信を持って勉強を始めるといいと思います。

参考：『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ』

「チームの成果」「メンバーの成長」がスクラムマスターの喜び

――最後に、スクラムマスターの仕事に感じている面白さと、今後チャレンジしたいことを聞かせてください。

田原：スクラムマスターという立場でチームに関わることにより、各チームがそれぞれのやり方で成果をあげ、メンバーが成長していく過程を見られることに面白さを感じています。チームにとっての「ゴール」は、最終的にスクラムマスターを必要とせず、自走できる状態になることです。実際に、自分が関わってきたチームも、徐々に自走できるようになってきており、そうした状況を見ると嬉しくなりますね。

　私自身、スクラムマスター歴はまだ1年ですが、経験を重ねるごとに、やり方はひとつではなく、さまざまな状況のチームがあり、そのチームに合ったさまざまなスクラムのやり方があることを実感しています。今後も、いろいろなチームを見ながら、多様な考え方、やり方を吸収していきたいと思っています。

粕谷：私はもともと、チームでの仕事が好きで、1人ではできないことを、チームとして実現することに喜びを感じるタイプでした。スクラムマスターとしても、チームのみんなが、1人では不可能な成果を、チームとして収めることができた瞬間に、最もやりがいを感じます。

　今、社内には、自分を含めて9人のスクラムマスターがいますが、今後は、新しくスクラムマスターになろうとする人を、育てていきたいという思いがあります。最終的には、優秀なスクラムマスターが社内に複数育ち、私自身はスクラムマスターをやらなくてもいい状況を作ることが目標です。その後は、会社全体のエンジニア組織の整備など、もう一段、広いスコープで仕事をしていきたいですね。

田原：今回、粕谷さんとお話しさせていただく中で、いろいろなことに気づけました。この1年、スクラムマスターとして、どう動いてきたかを思い出し、整理しながら話す中で、気づかされる部分も、納得する部分も多々あり、大変ありがたかったです。本当にありがとうございました。

粕谷：私も、コロナ禍の2年で、田原さんのように「リモートしか経験のないスクラムマスター」が、生まれていることを実感できたのが新鮮でした。私自身、当初はやりづらさを感じていましたが、既に慣れつつあります。環境の変化に適応するため、スクラムにもさまざまなやり方、形式が取り込まれ、多様性が高まっていることに、改めて気づけたのが面白かったです。こちらこそ、ありがとうございました。

著：高橋美津
写真：OGURA