あなたのスプリントレビューは盛り上がっていますか?

アジャイル開発を始めて4年になりますが、意義のある・活気のあるスプリントレビューができることもあれば、お通夜のような・審議のような・辛いスプリントレビューをしてしまうことが今でもあります。皆で褒め合うだけでなく、皆で責め合うだけでなく、「またやりたい」と誰もが感じられるスプリントレビューを開催する秘訣はないのでしょうか。

Regional Scrum Gathering Tokyo 2020でこの悩みを共有したところ様々な方からアドバイスをいただけました。このセッションではその内容を整理し、実際に自分たちで実践した感想を加え、よりよいスプリントレビューをするための知見を共有したいと思っております。

大事な活動である「ふりかえり」。だが、難しい活動でもある。

スクラムの重要なイベントの一つである「スプリントレトロスペクティブ／ふりかえり」。
チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。

スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
ふりかえりが反省会のようなムードになってしまう。
チームのためのアクションが出ず、なかなかチームがまとまらない。
アクションは出たものの、なかなかカイゼンされているように思えない。
こういった悩みを持つ多くの現場を見てきました。

ふりかえりは、難しい活動の一つとして考えられがちです。
時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。

ふりかえりとファシリテーション

ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
そのうちの一つが「ファシリテーション」という考え方です。

進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。

ファシリテーションというものをあなたがどうとらえるか。
そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。

COVID-19とふりかえり

COVID-19の影響を受け、チームの姿は大きく変容しました。
ふりかえりも、著しい影響を受けたイベントの一つです。
ニューノーマルな世界が形成されていく中、ふりかえりはどのような姿を見せるのでしょうか。
これまでの先人の知恵や、私たちが培ってきた経験は使えないのでしょうか？

そこまで悲観することはありません。
このセッションでは、昨今のオンライン環境におけるふりかえりの新しい姿と、私たちが考えるべきこともお伝えできると思います。

このセッションについて

このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。

COVID-19で変わったチームの姿。そして、この環境下でふりかえりにおいて変わるもの、変わらないもの。
チームの形成、そしてチームの成長。チームのグラデーション。
ふりかえりのファシリテーションと、マインドセット。

「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。

みなさんの現場ではすでにスクラムを導入済みでしょうか。

最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。

本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。

このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。

基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。

そういった固定観念が社内外充満している中、
SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。

特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
札幌のエンジニア達がLeSSに近しい姿をトライ＆エラーしていく
天竺への道程（現在進行形）を等身大で聞いていただければと思います。

• アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
• 複数拠点横断スタッフとのリモートワークによるチーミング。
• クライアントとのカルチャーギャップ。
• 自分自身含めたメンバーのマインドセットの成長。
• などなど・・・

“I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.”

― J.R.R. Tolkien, The Two Towers

スクラムのイベントなので、エクストリームプログラミングの話をしたいなと思いました。

私が最初にアジャイルに触れたのは、2000年頃、XPの記事や書籍、さらにXPを導入したプロジェクトにプログラマーとして参画したときでした。まだアジャイルという言葉はありませんでした。ペーペーのSIerプログラマーだった私はXPと遭遇して、プログラマーがさらに大好きになり、同時にただプログラミングが好きなプログラマーではいられなくなりました。プログラミングは趣味も含めて10年以上、フルタイムジョブとしては2年目くらいという、XPに触れたタイミングは幸運でした。

XPはプログラマーの仕事を楽しくし、人生を幸せにします。プログラマーは指示通りに手を動かす歯車ではなく、創造性と専門知識を持った一個の人間です。同時に、プログラマーは安穏としてプログラムを書いてるだけでは済まず、顧客やその他すべての職種の人とコミュニケーションし、協力して、やるべきことをしなければなりません。プログラマーはプログラマーだから愛されるのではなく、生み出す価値が故に愛されます。XPは究極(エクストリーム)なので、プログラマーは究極的に最高の仕事をします。時間不足やスキル不足に追われる代わりに、ユーザーの期待と品質のバーを最高に設定して越えていく仕事が楽しくないわけがありません。プログラミング、ものづくりという仕事の意味をXPに塗り替えられた私は幸運でした。

2000年に発行された『XP エクストリーム・プログラミング入門』(第1版)を見返すと、XPのユニークなプラクティスとして紹介されているものがいかに当たり前になっているかに驚かされます。テスト自動化、リファクタリング、コードの共同所有、継続的結合、シンプルな設計。当時の私にとっては、XP、Java、オブジェクト指向設計は不可分なものでした(時代背景的にも多くの人が似た状況だったのではないかと思います)。アジャイルなソフトウェア開発が発達するのと、並行して進歩する開発技術は表裏一体でした。将来当然となるプラクティスに早く触れられたのは幸運でした。

XPは日本において(だいたい世界でも)現在に続くアジャイルのムーブメントを引き起こした先鋒であり第一の波でした。私はXPに心酔するのと同時にコミュニティに熱狂しました。アーリーアダプターの人たちがたくさん引き寄せられました(一過性ではなく、いまでもずっと活動されている方もたくさんいます)。そうした中で、コミュニティに参加したり、登壇の機会をもらったり、運営側を経験することにもなりました。人前で話をするなんてまっぴら御免と思っていた私にとって、幸運な機会がたくさんありました。

XPはソフトウェアの作り手と使い手とを引き裂いた人工的な傷口を癒やし、全体性を取り戻す試みです。私は最初にXPに触れられて幸運でした。XPはプログラマーとして守るべき規律を示しながら、プログラマーの本来の役割は顧客やユーザーに歩み寄り、価値を生み出し続けるために一緒に働くことであるという、長く続く道にそうと知らずして進み始められたからです。オブジェクト指向設計やJavaといった技術だけを追求していたら、もしかしたら一生見つけられなかった道です。幸運だったとしか言えません。

(上記はプロポーザル時点で考えている概要で、今後おおきく変化する可能性があります。4月になったら「XP: An East Asian smiley emoticon representing a happy face sticking out its tongue.」みたいな話になってる可能性もあります。悪しからずご了承ください)

「ゼロからつくる！リモートスクラムチーム」からタイトルを変更しました。

プロポーザルを出した時点では以下のようなことをお話しするつもりでした。

小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

その状況から、

• いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
• 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
• リモートでもチームとしてワークするために試行錯誤している話

をお伝えしたいです。

それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。

でも、一部メンバーによってプロジェクトは推進されています。

チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。

アジャイル札幌で人気のコンテンツ「紙粘土スクラム」。
紙粘土と侮るなかれ、毎回リアルな現場のようなドラマがあります。
その中の失敗をアンチパターンとして紹介します。

紙粘土スクラムに特化したアンチパターンではなく、例えば下記のような実際の現場でもあるあるのアンチパターンになっています。

アンチパターン：チャラオーナー
対象：PO
プロダクトオーナーが開発者に対してイメージトークしかしない。例えば「もっとカッコよく」「いい感じで可愛く」「品質をあげよう」など。
改善ポイント：開発者とPOで具体的な例を挙げて認識合わせをする。事前に画像でイメージを共有する。

アンチパターン：妄想の暴走
対象：DEV
ステークホルダーが近くにいるのに、まったく聞かず仮定を積み上げて難しい仕様や不要なものまで作りすぎてしまう。POまで妄想に加わるとチームとして完全にアウト。
改善ポイント：仮説という認識を持って、ステークホルダーと対話する。

チームのあり方・チームでの成長の仕方が着目される昨今、IT業界を目指す若者たちも、いち早くそういったノウハウ・方法・ツールに触れ、体験的に学ぶことが肝要でしょう。

アクティブラーニングの活用などで学生が主体的・対話的な活動を求められる近年の学生達は、けれどもチームを組むとなると、ゴールにむけて役割・立場・責任を当てはめる分担的チームワークを求めがちです。

チームを形作り成長させるためのノウハウは、教育現場でも彼らに新たなチームのあり方・チームでの成長の仕方への気づきを促し、「チーム活動」を再認識させることは可能なのでしょうか？

大学教育の情報系カリキュラムにおける個別の試行事例から検討してみます。

遠隔のチームメンバーとのミーティングやスクラムイベント、どうしていますか？

チャット、TV会議、ホワイトボード共有ツールなどがありますが、うちのチームではどれも満足できませんでした。

バーチャルでメンバーとあって、付箋やボードを無限に広げて使える場、チームで占有できるプロジェクトルーム、欲しくないですか。

まだ、機材や制約もありますが「現実よりも便利に働ける場」を目指してバーチャルワークプレイスを作っています。

わたしたちのチームメンバー5名は、スクラムイベントを毎週そこで行っています。

少し未来の働き方を紹介させてください。

紹介動画: https://www.facebook.com/ricoh.jp/videos/808565413001238/

チーム、組織、会社、役割、契約、業種・・・
私たちの仕事にはいろんな状況があるので、つい、
「It depends（ケースバイケースだね）」
と言いたくなってしまうときがあります。

しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

こんにちは！

こんにちは、及部です。

私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

伝えたいこと

教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ？」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

それでは、スクラムフェス札幌大会でお会いしましょう。アディオス！

去年、別のイベントで登壇したときの内容をアップデートしてお送りします！

社内へアジャイルを推進していく中で、いくつもの失敗や衝突がありました。
振り返ってみるとその原因は、アジャイルに対する期待値のギャップだったり、目的不明のプラクティス導入だったり、捨てきれないこれまでのやり方だったり。

でもそこに「それはダメ！」「そうじゃない！」と迫っても、「”よくわからないアジャイルというもの”は随分と面倒なんだな。」と終わってしまうかもしれない。まずはアジャイルがどんなものかを正しく知ってもらうのが良いんじゃないだろうか。

そんな中で見えてきた、私の感じた「アジャイルを始めるにはこのあたりから取り組んでいくと良さそう」を紹介します。

なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。

はじめに

本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
見積りをやめてから起こった問題やその対処についてもご紹介します。

また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

Introduction

本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
アジャイル開発における見積りについては「アジャイルな見積りと計画づくり（AEP）」という素晴らしい書籍でその有用性や有効な実践方法が示されており、私自身もその有用性について同意しています。

しかしながら、見積りには負の側面があることもまた事実であるように思われます。
RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

そもそも、なぜ見積りが必要なのでしょうか？

そして、本当に必要なものは見積りなのでしょうか。

この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか？」という仮説にたどり着きました。
それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

この私達のプロセスでは、モブプログラミングが鍵となっています。

本セッションでは、私達がどのように見積りをせず開発をしているのか、その方法論を紹介するとともに、
見積りをやめたチームの事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

見積りの負の側面と価値

見積りの負の側面について、私達の考えをまとめます。
私達が考える見積りの負の側面は、以下の「３M」に集約されます。

• 数値化による「コミット圧力」… 納期の「ムリ」
• 数値化による「仕事量の最大化」 … 仕事の「ムダ」
• 数値化による「正確であるという錯覚」 … 精度の「ムラ」

そしてこれらは、見積りを「数値化すること」により発生すると考えています。

もちろん、見積りは負の側面ばかりではありません。
見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
計画づくりとは価値の探求なのだ。
– アジャイルな見積りと計画づくり

見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

見積りの負の側面の根源である「数値化」を行わず、
見積りから取り出したい「価値」を抽出する手法

と定義づけています。

スクラムと見積り

私達はスクラムを実践しています。

見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
見積りをやめて以来、ずっと問い続けてきました。

スクラムガイドには「見積り」という言葉が９回登場します。
それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

• リリース計画づくり … PBIの優先順位付け
• スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
• 進捗管理 … 残作業を確認し、計画を更新する

見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
これが私達のたどり着いた答えです。

我々は、以下の方法でこの意思決定を行っています。

• 優先順位付け / バックログリファインメント
  • PBIのサイジング … 直近のPBIを １スプリント以下のサイズ に調整
  • C3D(Cost of Delay Divided by Duration)
• キャパシティ / スプリントプランニング
  • PBIのスループット
  • スプリントゴール
• 進捗管理 / デイリースクラム
  • SBIのスループット
  • モンテカルロ法 … 過去データからの ‘予測’
• スプリント（開発作業）
  • モブプロ
    • WIP制限 … 安定性・予測可能性の向上

「見積しない」 開発と現実

このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

• 「見積りしない」の始め方
  • どのように上司を、ビジネスを巻き込むのか？
• 「見積りしない」計画づくり
  • どのように先の見通しを立てるのか？
• 「見積りしない」開発の課題
  • 見積りをやめてから、チームに降りかかる課題と対応
• 「見積りしない」で納期を守る
  • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには？

まとめ

Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

AEPから１０年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

北海道でそだち上京、23歳で組織初のスクラム導入。転職してなんちゃってアジャイルだと数年たってから気付いてスクラムの再導入。どちらも期待と不安がいりまじった時間をすごしましたが、とても楽しい時間になりました。私が当時どのようにスクラムを導入したり、変化させていったのか。そしていまならどうやるのかという考察をお話します。

ScrumMasterや開発Teamの皆さん
「Product Ownerの責任は、Scrum TeamのROIを最大化なんで頑張ってください！」
「それでリターンいけるんですか！？納得感いまいちっすね」
とばっかり、Product Ownerに言ってませんか？

それを言いたい気持ちは、わかりますよ。
そして、言われている意味も責任もわかってますよ。
でも、ですよ！何か、おかしくないですか？
ちょっと遠すぎやしませんか？

よくよく考えてみました。

エンジニア、デザイナーの経験のあるPOやSMは多くいる。
一方で、PO経験のあるSMや開発Teamって少ない。
だからこそ、みんなPOことがわからないから、冒頭のようなコミュニケーションが発生したり、
また、冒頭のようなコミュニケーションで留まったりすることが多いのではないでしょうか。
（本当に多いかどうかは、あくまで仮説です）

そこで、Product Backlogのネタを作っていくために、どんなことを考えたり、
いろいろなことを心配しながら、仕事に取り組んでいる日々の心の声を
皆さんと共有してみようと思います。

僕の発表を踏み台にして、POの実務的な意味での理解を少しでも増していただいて、
より素晴らしいScrumチームが世に増えるための参考になればと願っています。

「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
「このエピソードは、どこでも起きうる話なのだろうか？」
「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか？」

事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか？

レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。

今、現場で起きている課題の先に光があるのだろうか？そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。

※本セッションは、「アジャイルチーム成長の過程ってどんな感じ？(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を１つにまとめて再構成するものになります。

数年前から札幌でスクラムを実プロジェクトにて実践してきました。

まわりではスクラムの事例が少なく、なかなか相談できる環境も多くはない状況でした。

その中での収穫は、自分たちで考え実践したことにより多くの失敗を経験することができたことです。

このセッションでは、これまでの経験から得た［失敗］そしてどのように［改善］していったかを紹介します。

スクラム視点での正解ではないかもしれないですが、これからスクラムに取り組む方や実践していてうまくいかない方の微力ながらヒントになればと思っています。

初めまして、北のグラフィックレコーダー、木村あゆみと申します。
北海道&札幌のトークイベントを中心に、話を絵と文字でリアルタイムに可視化する「グラフィックレコーディング（＝グラレコ）」を描いています。

北海道・札幌で講演を描くというスタイルでは、第一人者として活動しています。

エンジニアさんの間でも、
・チーム内外の相互理解を深めるため
・より良い場をファシリテートするため
などを目的として、ホワイトボードを活用したり、グラレコを活用したりする機会が増えていると感じています。

「絵が描けないと難しそう・・・」

と思われがちですが、ちょっとした道具や簡単なスキルを覚えるだけで、場をより良く可視化することができます！

現場で実践しているコサカさんの経験からも、
スクラムを通じて「現場をより良くしたい」と思っているみなさんにとって、グラレコのエッセンスは、即使える新しい武器になると考えています。

私たちと一緒に簡単なワークをしながら、グラレコを体験してみませんか？

楽しい時間を通じて仲間も増える、素敵な時間を過ごしましょう！

システム受託開発を生業とする会社でエンジニアとして働き始めて10年、アジャイルという世界があることを知りつつも自分とは遠い世界のように感じて、勉強する気にはならなかったり、ちょっと書籍を読んでみても現実感がなくて自分には関係ないものと思いがちでした。

わたしがスクラムというやり方があるらしいぞ、と知って取り組み始めて2年が経ちました。

これまで、色々なことがしっくりこずにもやもやしながら悪戦苦闘を続け、本を読んでみたり、トレーニングにいってみたり、アジャイルコーチに来てもらったり、コミュニティーに参加してみたりしてやっと何かを掴みかけたと思いきや「なにもわからない」状態に突入した話などができればいいなと思っています。