ビジネスの急速な変化に適応すべく、多くの企業でデザイン思考やスクラムの導入が進んでいます。
しかし、なかなか効果が出ないのが実際ではないでしょうか？
この原因の１つとして、組織マネージメントの方法やマインドセットが従来から変わっていない事が考えられます。
デザイン思考やアジャイルを導入しても従来通りの組織マネージメントとマインドセットでは、効果は薄れてしまいます。
このような問題の1つの解としてManagement3.0というマインドセットがあります。
本会では座学とワークショップを組み合わせ、Management3.0をベースに「変化に強い”自己組織化したチーム”の作り方」を、プラクティスを交えてお伝えします。
参加されるみなさんに「今日から」使える考え方と技を持ち帰って頂こうと思います。

経済産業省のDXレポート2でも提言されている通り、日本でDXを加速するためには、ユーザー企業だけでなくベンダー企業のアジャイル変革も必要です。昨今人材の流動性が高まっているとはいえ、欧米に比べ日本では多くのエンジニアがベンダーに所属しており、その潜在パワーは、デジタルを活用した抜本変革とそれに必要な組織アジリティの向上に向けた重要な役割を担うことができます。

私自身もベンダーの可能性と重要性を信じ、永和システムマネジメント Agile Studioでの組織運営を通じて様々な変革に取り組んできました。具体的には、以下の組織的な取り組みです。

• 内製化を支援する開発支援サービスの提供
• ノウハウの提供主体となるための新しい技術の獲得
• ユーザー企業に認知してもらい変革に巻き込むためのマーケティング

これらは、結果的にDXレポートにおける、ベンダーに求められる4つの変革方向性（①ユーザー企業の変革を共に推進するパートナー、②DXに必要な技術・ノウハウの提供主体、③協調領域を担う共通プラットフォーム提供主体、④新ビジネス・サービスの提供主体）の①と②をカバーしています。

現在、これらの取り組みを継続発展し、しなやかな変革による新たな価値創造を目指しています。ユーザー企業のアジャイルに対する理解が進むにつれ、様々な支援を提供するアジャイルなベンダーも増えています。私たちはまだ道半ばではありますが、このセッションでは、これまでのAgile Studioや自治体（兼業している福井県CDO補佐官）での取り組みでのポイントをご紹介させていただきつつ、参加者の皆さんと一緒にアジャイルベンダーの未来について考える機会にできれば幸いです。

田舎でスクラムシリーズ16年目

ちんもの勤める会社が突然のアジャイルフィーバーになって1年。

経営陣と組織職が全員アジャイル研修を受け、全社方針にも組織戦略にもアジャイルの推進なるものが組み込まれ、顧客から多くのアジャイル案件がやってくるという状況になった。

果たしてこれは、長らくちんもが夢に見てきた世界なのか、そして会社人生の多くをアジャイルの展開に投じてきたちんもには、いよいよお役御免の時が迫っているのだろうか...。

アジャイル時代にSIerが抱える新しい課題に果敢に切り込むちんもの無謀な挑戦、聞いてやってください！

スクラムの中では、とっつきやすいのがふりかえり。手が出しやすく、ふりかえりからスクラムを始めたという話もよく聞きます。ただ、どれだけスクラムの経験を積んだ人でも、ふりかえりは難しく、奥が深いイベントです。

一昔前に比べると、Web・勉強会・カンファレンスなどで、ふりかえりの情報は手に入りやすくなっています。ただ、それゆえに、選択肢が多く、「何が正解なの？」「結局どうすればいいの？」と悩んでしまった経験がある人もいることでしょう。

みなさん、胸に手を当てて考えてみてください。
「ふりかえりは、うまくいっていますか？」

• うまくいっていないんだけど、どこがわるいのか…
• なんとなくうまくいっている気が…する？
• うちのふりかえりは完璧だ！ふりかえり完全に理解した！
• そもそもうまくいくって何だよ

何かしらの引っ掛かりを感じたあなた。
その引っ掛かりはとても大切です。
このもやもやがある今だからこそ、自分のふりかえりをふりかえりましょう。

ふりかえりを始めたばかりの人も、ふりかえりを日常的にやっている人も、毎秒ふりかえりやってるよという人も。

ふりかえりをふりかえるためのふりかえりチェックシートを用意しました！
さぁ、みんなでふりかえってみましょう！

Rettyのエンジニア組織は、2017年頃崩壊の危機にあった時期があります。

明確な船頭、責任者がいない中で停滞感が広がりなにもできないまま徐々に退職者が増えていくというサイクルに陥っていました。

そこから数年をかけて小さな取り組みを徐々に広げ、改善をかさね今では離職率も大幅に下がり、エンジニア組織だけではなく開発組織全体にアジャイルな思想が広がりつつあります。その過程はもちろん簡単なものではなく、多くの失敗や無力感を感じたことも数え切れないほどあります。

この過程のなかで自分が感じたこと、考えていたこと、表には出せなかったことなどを赤裸々にお話できればと思います。

Management 3.0 考案者のヨーガン・アペロ氏の著書に「Managing for Happiness」がありますが、現在、日本語訳を進めており、（うまくいけば）6月あたりに出版する予定です。

このセッションでは、出版に先駆けて本に出てくるプラクティスを無理くり全部詰め込んでひととおり体験してしまえるようなワークショップを実施したいと思います。

本に出てくるプラクティスは、以下のとおり12個とたくさんあるのをぎゅうぎゅうに90分に詰め込むので、おそらくジェットコースター的なスピード感満載のワークになるかと思いますが、それすら楽しんでもらえるような形で参加してもらえると嬉しいです！

ひとりで進行する予定なので、ワークはフィッシュボウル（参加者を内側の円と外側の円で分けて、内側の円の方にワークに発言する役割として参加してもらい、外側の人はそれを見守る役割として参加してもらう形）的に3-5人に直接的に参加してもらい、後の方にはそれを見てチャットなどで間接的に参加してもらう形にする予定です。

体験できるプラクティス（予定）

- Kudoカード

- パーソナルマップ

- デリゲーションボード

- バリューストーリー

- エクスプロレーションデイズ

- ビジネスギルド

- フィードバックラップ

- スコアボードインデックス

- メリットマネー

- ムービングモチベーターズ

- ハピネスドア

- セレブレーショングリッド

自分はこれまで4年ほど、OKRと向き合ってきた。

初めはムーンショットを追いかける好奇心や自身の成長につながりそうな期待で取り組むものの、チーム内でのコミュニケーションがうまくできているとは感じられなかった。
当時は評価制度と紐づいていたOKRだったが、年度末も自分が何を積み上げてきて何が評価されているのか、正直わからなかった。

こうして半分受け身で始まったOKR、今度は自分が社内に広める役割を少しずつ担っていくようになった。

漸進的に広まりが感じられるようになり、少しずつ自分達の共通言語になってきている手応えを感じていた。

はずだった。

実際には、現場では業務とのつながりを感じにくかったり、新しく参画された方にとっては未知なる取り組みだったりと、混乱の声が消えることはなかった。

5年目を迎えた今年、組織の判断としては「ツリー構造をやめよう。」と「ツリー構造じゃなければOKRではないいのでは？」の二つの声があったようで、ツリー構造をやめ、部門単位で取り組めることにフォーカスした目標設定を始めることとなった。

その矢先、OKRの取り組みに多大なる影響を与えて下さった小田中さん（下記リンク等参照）からOKRのお話を聞いたり相談する機会を得たことをきっかけに、このツリー構造、OKRの必須事項ではないことに気付かされた。

なんと、対話が必要な不完全なフレームワーク。これはまさに、スクラムと同じではないか。

ツールを使うことが目的となっていて、本来の目的を達成することを忘れてしまっていたことに気づいた自分は、過去にインプットした情報を再度洗い直し、Unlearnと現在の実態に適応するためのリビルドをすぐさま行うこととした。

本セッションでは、このUnlearnとリビルドした社内の目標設定に関するエピソードと、それに関連する仕組みづくりに奔走している経験を語り尽くします。

DevOpsの世界において、テストはどのような位置づけにあるのか？

テスターはどのように適応すればよいか？

DevOpsでは、開発チームと運用チームが一緒に仕事をすることが奨励されています。これにより、製品を提供するために協力する人々のネットワークが広がり、テストの境界が拡大し、テストの性質が進化する機会が生まれます。

開発チームが運用で利用可能なスキル、プラクティス、ツールを理解すると、テストは生産に向けて右肩上がりになる。例えば、本番同様の環境でテストを行うことができるオンデマンドインフラ、顧客指標から得られるA/Bテスト実験からのフィードバック、顧客からのフィードバックを迅速に提供するベータテストグループなどがあります。

DevOpsによって納品ペースが上がると、新機能のテスト戦略にも課題が生じます。開発チームは、リリースを過度に妨げることなく、どのように新機能を調査すればよいのでしょうか。テストの自動化、モニタリングとアラート、迅速な自動デプロイとロールバックなどのツールの賢い利用を含めて、テストアプローチを適応させることができます。

このセッションでは、Katrinaが彼女の著書「A Practical Guide to Testing in DevOps」からいくつかの考えを紹介します。また、DevOpsを紹介し、開発中、本番稼働中、インフラに対するテストのための一般的なDevOpsプラクティスをいくつか紹介し、DevOpsがどのように、そしてなぜテスト戦略を変えるかも説明します。

「スクラムは、楽しいかね？」→「はい！」
「スプリントレビューは、楽しいかね？」→「はい！」
「スプリントレトロスペクティブは、楽しいかね？」→「はい！」
「リファインメントは楽しいかね？」→「うっ。。。」
最後の質問に私はギクリとした。

他のイベントは良い思い出があるが、リファインメントは。。。。

現在、私達のチームでは、リリースしたプロダクトの機能改善を行うため、プロダクトオーナーと共に、リファインメントを行っている。

定期的にリファインメントを実施するも、プロダクトバックログの中身以前に、そもそもリファインメントで何をするのか？今日のリファインメントのゴールは？の認識があっていないことが多いことに気付く。お互いの目指すところが異なり、リファインメントがギスギス、殺伐、発散に次ぐ発散。その結果、優先度の並び替え、着手可能なバックログをReady(準備完了)するまでに時間を要していた。

それがリファインメント の苦い思いで、そして楽しめない要因に。。。何とかしたい。

このセッションでは、現在進行形で直面しているリファインメントに対しての、私達チームの課題や悩み、
その解決に向けた取り組みについて、お話します。
「リファインメントがうまくいかない」「リファインメントが楽しめない」という方々のご参考になれば幸いです。

複数人で１つのプログラムを作るチーム開発のテクニックとしてモブプログラミングという手法があります。これをプログラミング以外の作業もみんなでやろう、という発想にしたのがモブワークです。

私のチームではモブワークを基本としつつも状況次第であえて1人（ソロ）での作業を混ぜることで、チームの開発を安定させつつタスク完了までのリードタイムを短くする状態を実現しています。

モブとソロを織り交ぜた開発のメリットについて、実践で工夫しているポイントや実現までに苦労したことなどを通じてお話しします。
「チーム開発って結局何をすればいいんだろう」とお悩みの方へ事例の１つとして参考になれば幸いです。

私は Chatwork 株式会社にて、エンジニア・バックグラウンドで組織開発に携わっています。

Chatwork は今年で 11 周年を迎える息の長い SaaS となるのですが、社会の DX が加速することに伴って求められるプロダクト成長を実現するために、開発組織の構造変革や技術的負債へと向き合う必要がでています。

そのための組織開発は、不確定要素を持ちながらもスピードが求められるため、Chatwork においてはエンジニアと人事を一同に介した "DevHR" というチームを作り、スクラムを応用して PDCA を回しています。

本セッションでは、Chatwork における DevHR の活動を紐解くことで、組織開発や人事領域へのスクラムの応用可能性を考察します。

大日本印刷株式会社でアジャイルの推進活動を始めて7年目、社内の推進グループのリーダーになって丸1年になります。
最初は6名だった推進者も、50名を超える規模まで大きくすることができました。
暗中模索・手探りで進んできた推進活動も、最近少し余裕ができ周りが見えてきて、見える世界も変わってきた感じがあります。

大日本印刷は、純粋なベンダー企業でもなく、とはいってもユーザ企業でもありません。
企画・営業職の力が強く、開発者の数も力も存在感も不十分です。

そんな組織の中でどのようにアジャイル文化を浸透させてきたか、何と戦ってきたのか、どんな変化があったのか、
そして自分はこれから何と戦っていくのか、をお話ししたいと思います。

同じような境遇の方に聞いていただき、共感していただけると幸いです。

2020年始め、新型コロナウィルスの拡大により、人と会って話すことに大きな制限が生まれました。
仕事だけでなく様々な場面で、人と会って話すことがどれだけ価値のあることなのかを改めて知ることとなりました。
もちろん勉強会においても、この制限はとてつもない衝撃となりました。
それまでは大多数がオンサイトで開催されていたので、開催中止や延期に追われ、いつ再開できるのかがわからないまま、今のような状況に入っていったと思います。

不幸中の幸いか、この2年間でオンラインコミュニケーションのツールが現れ、進歩していきました。
2020年より前と同じように、人と顔を合わせて話すことが会いに行かなくてもできるようになってきています。
通勤せずとも仕事ができるようになっていき、そこで得られたノウハウが徐々にオンラインで勉強会を開催できる自信へとつながっていったのだと思います。
オンライン開催に切り替わったことで、それ以前に比べて、熱量が上がっているように感じています。
これは、きっとオンライン開催での地理的な制約がなくなったので参加しやすくなったこと、また途中で抜けるのもまたやりやすくなったのでお試しで参加しやすくなったためではないかと思います。
また、開催する側においても、会場を探すなどのコストが下がり、開催頻度が安定したり、あるトピックを思いついたらすぐに開催できるようになったので熱量が高いまま開催に漕ぎ着けられるといったこともあるのだと思います。

そして、その要因の1つにテキストチャットがあるのではないかと考えています。
リモートから参加する人の多くは、家族がいるプライベートな空間にいます。そういった方々には、声を出して話がしづらい、もしくは出せないといった制限があります。そういった状況でも、テキストであれば会話に参加することができます。

またテキストチャットのもう1つの効果として、雰囲気を残しておけるということがあります。
テキストチャットに残されているテキストは、整然とまとめられたブログによる参加レポートと比べ、そのときの雰囲気が読み取り易いと思います。
テキストチャットでは、参加者の顔（アイコンかもしれないけど）が見え、その人がどのような言葉遣い、リアクションで使われるコミュニティ独自の絵文字など、様々な表現方法があります。
時間の問題でリアルタイムで参加できなかった人たち、もしくは途中で退出しなくてはならなかった人たちにとって、テキストテキストチャットに情報が残っていると、そこからどのようなことが起きていたのかを想像することができます。
何も残っていないと、そこで何も有益な会話がなされなかったのか、それとも単に残っていなかっただけなのかという区別がつきません。ですので、その時の雰囲気を残して置けるか、というのはコミュニティを運営する上で重要になるのではないかと思っています。

このセッションでは、そういったテキストチャットで勉強会を楽しくするためのTipsを共有できればと思っています。

最近よく耳にするようになったコーチング。

興味はあるけどなぜか一歩目が踏み出せない・・・
なんかうさんくさい・・・
なにから始めればいいかわからない・・・
こうやって、悩み続けてもなにもすすまない・・・
いや、だからこそ飛び込んでみてから考えよう！！

そんな想いでコーチングの世界に足を踏み入れた5人の勇者たち。

はじめた動機、バックグラウンド、学んでいるもの、進度は違えど、
実際に行動しはじめた5人だからこそ話したいことがここにある。

コーチングを学んでいるもの同士が、お互いに問うことでお互いの思考を探ります。

達人たちの推しの世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はもしかして、あの偉人？あの概念？からこの答えに辿り着いたのだろうか？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界、推しに対する思いを覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

スクラムを勉強する方法はたくさんありますが、その中でも特に短期間でスキルアップしやすいのが各種研修への参加です。無認定のままアジャイルコーチとして数年やってきたkyon_mmがついにScrum Allianceの研修をうけてみました。また、実践者であるbleis-tift、アジャイルコーチであるoshige、ビギナーであるyamajiも各種研修をうけてきています。そこでたくさんのことを学び、研修の善し悪しについて考える機会もふえました。

今回はScrum Allianceの研修をうけてみた感想と、Scrum Allianceが策定している「この研修ではこれ学べるから期待しておけよリスト」に本当に研修が合致しているのかの検証結果をご紹介します。みなさんが研修をうけるさいの参考になれば幸いです。

野中郁二郎氏は言いました「知的体育会系になれ」と。

では、どの体育(スポーツ)を選考すればいいのでしょうか？

The New New Product Development Gameではラグビーチームのように、とは書かれています。

ですが、サッカーではいけない理由は書かれていません。どうせ一緒でしょ？と思われているアメフトではダメなのでしょうか。競技人口が多い野球やクリケットは。。。。

本セッションでは、野球/サッカー/アメフトなどいくつかのスポーツを比較しながら、そのゲーム自体の構造からアジャイル実践者の方々に特にラグビーの観戦をお勧めする理由を説明したいと思います。

長期間にわたり、保守・開発を続けていると、メンバーの間にいつの間にか上下関係ができてしまい、うまく行っていたスクラムチームがいまいちな状態になったことはないでしょうか？
私たちにもそのような時期がありました。そのようなチームに突如訪れたメンバー交代、そして入ってきたのは、アジャイルをやったこともなければ、エンジニア経験も浅いメンバーたち。
そのようなメンバーを中心として、チームを再構成する中で、アジャイル開発を体験したメンバーがどのように成長を遂げ、新しい形でチームを作り上げていったのかお話します。

チームを作るのに、何かとらわれのようなものを持っていないでしょうか？
チームとは何か、チームとして達成したいものは何か、私たちは何度も話し合い、自分たちにあった形で変えてきました。
アジャイルどころか、システム開発自体も知らなかったメンバーもいるなかで、スクラムを中心に取り組むこと、諦めることを先入観なしに行うことで、チームの雰囲気も変わり、大きく成長をすることができました。

チームビルディングに悩んでいる方のご参考になればと思います。

何かを学びたいと思った時の方法の一つとして、「読書」があると思います。
集約された賢人の知恵をもらうことが数千円の投資でできる読書は、物事を学ぶのに非常に投資対効果の高い方法であるはずです。

しかし、現実を見てみると、読書が思うようなペースで進められなかったり、読みたかったはずの本なのに読んでいる途中で苦しくなって挫折したり、読んだのに何も行動変容が起きなかったりと、読書を通して自分が思っているような姿になれず、悩まれている方も多くいらっしゃると思います。

本プレゼンテーションでは、ここ1年半で316冊の本を読む過程で自分が行ってきた、試行錯誤の結果(153個の読書方法を実践)の中から50個をピックアップして紹介する(※)ことで、読書の仕方に悩まれている方の一助になることを目指していこうと思います。

※ハイピッチで50個の読書方法を紹介しきるか、参加者の皆さんが気になる読書方法を幾つかピックアップしてゆっくり紹介するかは、当日に参加者の皆さんにアンケートを取って決めたいと考えています。

このセッションは、以前はそれほど気にしていなかったプロダクトそのものや、マネジメント、最近耳にするようになったプロダクトマネジメントについて、徐々に当事者になりつつある方に向けたセッションです。プロダクト作りに注力するチームや、プロダクトオーナーが知識の土台を揃えられ、異なる立場の人との効果的なコミュニケーションに役立ちます。

一言で「あっ (プロダクト|マネジメント|プロダクトマネジメント)ってそういうことだったのかー!」が得られるセッションです。ビジネス側やマネジメント層と区別される人達とも、よりスムーズなコミュニケーションができるようになります。私自身がプロダクト開発にはじめて接するときにはじめに聞きたかったことをお伝えします。

----

「プロダクトオーナーがボトルネックだ」という声をよく聞きます。ところが、私がスクラムを学び始めた10年前から続いています。問題があればみんなが喜んで解決してしまう開発者コミュニティでは、まるでアノマリーのようなテーマです。

しかし、もはやプロダクトの責任はプロダクトオーナーだけのものではなくなりました。プロダクトを明確に意識しなくても仕事として成り立っていましたが、すこしずつプロダクトという言葉があふれつつあります。スクラムでもプロダクトオーナーに加えて、プロダクトバックログ、プロダクトヴィジョン、プロダクトゴールというようにです。

同様にマネジメントという言葉もよく耳にするようになってきました。「マネジメントって何?」と聞くと、「何とかして達成すること」だったり「やりくりすること」という答えが返ってきます。しかし、明日からマネジメントをする人にとってみれば、それらの言葉では動きようがありません。仕事をしている過程で「マネジメントの仕事はしていないけど、やりくりは日常的にしている」という方も多いでしょう。

プロダクトもマネジメントも、明日から「こうすればいいんだ」と思える明確な表現が必要です。

また、近年はプロダクトマネジメントという言葉が良く耳にするようになりました。いろんな方がいろんな説明をされています。先ほどのプロダクトとマネジメントが組み合わさった言葉ですが、それがいったい何を指すのか、ハッキリと理解した感触は得られていないのではないでしょうか。

「開発側」「ビジネス側」という言葉があります。「ここまでは私たちの仕事で、それ以外のことは他の人達の責任」といった境界がよく話題に上がります。こういった境界は、複雑で難しい開発という仕事の中では、一時の心の平穏として役立つこともありますが、障害になることもあります。同じような境界を生み出す言葉に「現場」と「マネジメント」があります。これらの境界は、単に知らなかったり、やったことがないだけだったり、きっかけがなく関心が薄かったりするだけなのかもしれません。

このセッションでは、そもそもプロダクトとは何か、マネジメントとは何か、プロダクトマネジメントとは何かを明らかにすることを通して、これらの境界を溶かし、様々な専門家の力が結集する組織に向けて役立ててもらえたらと思います。

■参考文献
■■プロダクト
『競争の戦略』マイケル・ポーター
『企業戦略論』ジェイ・バーニー
『マーケティング』井上淳子、石田大典
『マーケティング戦略』和田充夫、恩藏直人
『コトラー&ケラーのマーケティング・マネジメント』フィリップ・コトラー、ケビン・ケラー
『コトラーのマーケティング入門』フィリップ・コトラー、ゲイリー・アームストロング、マーク・オプレニック

■■マネジメント
『新訳 科学的管理法』フレデリック・テイラー
『企業・市場・法』ロナルド・コース
『経営行動』ハーバート・サイモン
『オーガニゼーションズ』ハーバート・サイモン、ジェームズ・マーチ
『現代の経営』ピーター・ドラッカー
『マネジメント』ピーター・ドラッカー
『組織の経済学』ポール・ミルグロム、ジョン・ロバーツ
『キャプランとノートンの戦略バランスト・スコアカード』ロバート・キャプラン、デビッド・ノートン 
『マネジメントの世紀』スチュアート・クレイナー
『昇進者の心得』リンダ・ヒル
『組織の罠』クリス・アージリス
『マネジャーの実像』ヘンリー・ミンツバーグ
『戦略サファリ』ヘンリー・ミンツバーグ、ブルース・アルストランド、ジョセフ・ランペル
『世界標準の経営理論』入山章栄

■■プロダクトマネジメント
『プロダクト・マネジャー―開発から販売までの新しい布陣』ゴードン・エバンス
『プロダクトマネジメント―新製品開発のための戦略的マーケティング』グレン・アーバン、ニキルシュ・ドラキア、ジョン・ハウザー
『トヨタ自動車開発主査制度』塩沢茂
『スバル360開発物語』桂木洋二
『クラウン開発物語』桂木洋二
『主査 中村健也』和田明広
『P&Gウェイ』デーヴィス・ダイアー、ロウェナ・オレガリオ、フレデリック・ダルゼル
『製品開発力』藤本隆宏, キム・クラーク
『凄い製品開発』ジム・モーガン、ジェフリー・ライカー
『プロダクトマネジャーの教科書』リンダ・ゴーチェル
『世界で闘うプロダクトマネジャーになるための本』Gayle Laakmann McDowell、Jackie Bavaro
『プロダクトマネジメント』Melissa Perri
『プロダクトマネジメントのすべて』及川卓也、曽根原春樹、小城久美子
プロダクトマネジメントの歴史と進化 by Martin Eriksson 角正典
https://medium.com/waicrew/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E6%AD%B4%E5%8F%B2%E3%81%A8%E9%80%B2%E5%8C%96-e0d444f89615