とちぎRuby会議08 食に関するメモ #toruby

6月29日に開催した『とちぎRuby会議08』でわたしが担当した『食』に関するメモです。

ランチセッションのお弁当

今回のお弁当は『石窯イタリアン アンジェロ』さんに作ってもらった。

５月にアンジェロさんと打ち合わせをした。お弁当のボリューム感について悩んでいそうだったので「参加者の８割くらいは男性で２、３０代くらいの方もわりと多いかな……」と言ったところ「唐揚げのようなガッツリしたものがいいでしょうか？」と聞かれたので、前回（一昨年）のとちぎRuby会議07の『からあげ弁当』の話をした。（ランチセッションで用意した『からあげ弁当』の影響でパーティーのお料理が大量に余ってしまう事案発生。詳しくはこちら）

…かと言って少なすぎるのも困るんですけど……いい感じにお願いします…！とおまかせ（丸投げ）した結果が、こちらのお弁当。

１品１品、丁寧に作ってあるのわかる。彩りも豊か。夕方からはじまるパーティーのお料理とかぶらないように作ってくれた。気にしていた量も（全体的に見て）少なすぎず多すぎずだったと思う。というのは、パーティーのお料理が不足することもなかったし、大量に余ることもなかったから。

コーヒーマシン

• アンジェロさんにお借りした。とても良かった！
• ダークチェリーという豆だった。飲みやすかった。
• 何人かの方からレンタル料金を聞かれた。お料理なども全部こみでお願いしたので単品の金額はわからない。
• 開場前に設置＆使い方を教えてもらった。前回と同じ機種だったのに使い方をすっかり忘れていた。
• 適宜、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。簡単だけど１年後はまた忘れてると思う。
• 挽きたてのコーヒーは香りもいいし美味しい。売れ行きもよかった。
• 講演の最中にガーーッと豆を挽く音が響くの非同期処理ぽくて、好き。

用意した飲み物

• ペットボトル（２リットル）２８本
• 前回（８月開催、参加者数は今回とだいたい同じ）「１８本用意してほとんど残らなくて、あと５、６本あってもよかった」→ 今回増やしてみたけど１０本くらい残った。足りないよりは良い！
• お持ち帰りしてくれたみなさん、ありがとうございます。
• ウィスキンソン ジンジャーエール（辛口） ２４本
• パーティー用に冷やしたものを持ってきてもらった。
• 未開封の３本は @arton さんに持っていってもらった。ありがとうございます。
• そうそう、アンジェロさんがクーラーボックスで大量の氷を持ってきてくれた。冷たいほうがいいでしょうからって。
• 氷を用意するのは思いつかなかった。アンジェロさんさすがアンジェロさん。

軽食つきのパーティー

• ケータリングも『石窯イタリアン アンジェロ』さんにお願いした。
• お料理の搬入などはスムーズで特に問題なし。３０分くらいでセッティング完了。
• 今回のお料理もとても美味しかった。見た目も美しいし、食べやすいように工夫してある。
• いつも写真を撮り忘れるんだけど今回は忘れなかった。

• 毎回お料理の名前が分からなくて（あの美味しかったあれ）みたいな感じになっていたので、今回はお願いしてメニューをつけてもらった。
• 名前が分かるとこんなツイートができるのだ。名前重要。

とちおとめのパンナコッタ、美味しかったなー（2回目）#toruby pic.twitter.com/d1XLcCKd7Y

— miwa (@miwa719) 2019年6月30日

• ワインのコルクがこんな風に使えるなんて！（きれいなコルクは捨てないで取っておくか）
• ワインは赤と白１本ずつ持ってきてもらった。
• 白ワインは氷で冷やしておけばよかった。クーラーボックスに残っていたんだよね。氷。いま気がついた。
• 前回のメモによると「赤ワインはわりと早いうちになくなった。白ワインがグラス１杯分残った」→ 今回はほとんど残ってた。@ardbeg1958 さんがいなかったからかな。面白いな。
• ワインは @emorima さん @youchan さんに持っていってもらった。ありがとうございます。
• アルコール類の準備はよく分からないので（飲まない人もいるし）今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思う。
• @you_ssk さんが日本酒２本を差し入れしてくれた。ありがとうございます。
• アンジェロさんから『電気式石窯ピザ』使用のご提案があった（素晴らしい）
• 電源事情がクリアできれば挑戦したい…！焼きたてのピザはどう考えても美味しいに決まってる。

• 軽い気持ちで『電気式石窯ピザ』を調べてみたら１００万円くらいする。びっくりした。
  
  
  
• Lightning Talks は途中で短めの休憩時間を入れると良かったかもしれないね。お料理を取りに行ったり、コーヒーを淹れたりできるから。

その他

• テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます！
• お菓子の包装紙を使っていい感じに飾る方法を覚えた。@suginoy さんありがとうございます。セロハンテープの端っこを折り曲げておくとはがすとき楽になる小技も教えてもらった。

• @takkanm さんのお子ちゃまがかわいくて癒された。会場のうしろに並べた椅子でお昼寝してた。@m_seki のブランケットが大活躍！

• 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。 

追記（2019-08-18）

当日の本会の様子が『るびま』に掲載されました。思い出し用に貼っておきます。

magazine.rubyist.net

うちのチームのプログラマーはなぜテストがうまいのか

うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。

— miwa (@miwa719) 2019年6月24日

医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。

うちのチームのプログラマーはなぜテストがうまいのか。いくつかの要因が思い浮かびましたが、その中でも「毎日１時間、システムレベルのテストをしている」のが大きいのではないかと考えました。この記事では、タイトルから期待される結論（なぜうまいのか）を書くつもりはないのですが（ごめんなさい）システムレベルのテストをすることで得られそうなことをメモしておこうと思います。プログラマーがこんなにテストしてるチームはこれまで見たことがありません。これを１５年以上もやってるってすごくないですか？*1

プログラマーが毎日システムレベルのテストをしている 

うちのチームのプログラマーは全員、毎日１時間「テストの時間」が割り当てられています。テストの時間は朝会終了後の10:00〜17:00まで。好きな時間に勝手にやるスタイルではなく予め決まっていて、時間割表（テストPC * 6時間）はびっしり埋まっています。プログラマーAさんは10:00〜11:00（テストPC-001）、プログラマーBさんは14:00〜15:00（テストPC-002）のように。プログラマーCさんがテストPC-003の前に座ったら、わざわざ時計を見なくても（ああ、もう16時か）と分かるくらいに常態化しています。

この記事での「システムレベルのテスト」は「テストPC（ほぼほぼ実機環境）の前に座り、お客さまが使うのと同じようにソフトウェアを触るテスト」のことです。JSTQB*2で定義されている「システムテスト」とはすこし違うかもしれません。

テストは『本日のおすすめテスト』*3に従って実施します。テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。時間がきたら（テストが途中でも）おしまいです。そんなにビックリするようなことはしていないと思います。

システムレベルのテストをすることで得られそうなこと

• 自分が開発していない製品、機能そのものを知ることができる
  わたしたちの製品はそこそこ大きいこともありソフトウェアに関する部分だけでも複数のチームで開発しています。ひとつのチームが複数の製品を同時に開発しているので、プログラマーがシステムレベルのテストをするということは、自分以外のプログラマーが作った製品、機能も当然触ることになります。

• お客さまがどのように使うのか（ワークフローなど）を知ることができる 
• 実機での処理速度感
• システムレベルで見たときのバックグラウンド処理（特に他のチームが開発しているもの）を知ることができる
• 実際の現場に近いユーザーデータ環境がどういうものかを知ることができる
  開発PCだと少なめのデータやお決まりのテストデータで試すことが多いのではないでしょうか。
• 意地悪テストの残骸を見ることができる
  テストPCはテスターも使っています。テストPCを触るということはテストの残骸（データや操作履歴など）を目にすることになるので、どのようないじめ方をしているのかを知ることができます。
• 開発履歴を知ることができる
  テストケースからその機能の開発履歴（開発日記）が簡単に辿れるようになっています。どのような経緯で開発（設計、実装）してきたのか、関わったプログラマーは誰で、いつどんな変更が入ったのか、過去にどのようなバグが検出されたのか、どのように修正したのか…などがわかります。実際、開発日記を読みながらテストしているプログラマーの姿をよく見かけます。 

テストケースに書いてないことも試している

先ほど「テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。」と書きました。でも「テストの時間」にプログラマーが検出したバグを見るとテストケースに書いてないことも試しています。テストケースを誤読して偶然見つけたものもありますが「これ、絶対バグを見つけにいってるでしょ」と思うものも多いです。どういう心境でテストしているのでしょうね。「テストの時間」はプログラマーの帽子を脱ぎ、テスターの帽子をかぶっているのでしょうか。

おわりに 

うちのチームのプログラマーはテストがうまい自慢と「システムレベルのテストをすることで得られそうなこと」をメモしました。毎日テストをしているからテストがうまくなる（訓練みたいなもの）とも思いましたが、それだけではないのも実は分かっていて、いつか言語化できたらいいなと思っています。

*1:中の人たちはこれがすごいことだと分かってないのもすごい。自分たちの開発にはこれが必要だと認識してやってる感じ。

*2:Japan Software Testing Qualifications Board

*3:膨大なテストケースの中から現在の開発の状況に応じていい感じにテストケースを選んでくれるレコメンドシステムがあります。@m_seki が作りました。

ピクシー絵本の思い出

手のひらサイズ(10cm*10cm)の小さな絵本です

当時読んでいたものは引越しの際に捨ててしまい（あとになってそれを悔やんでいた）2000年にフェリシモ出版から復刻されたときに買い直しました pic.twitter.com/Eb6cwrA7QP

— miwa (@miwa719) 2019年5月3日

この中でも特にお気に入りだったのが、こちらの５冊。

当時、お出かけする時にはポシェットの中にピクシー絵本を２、３冊しのばせていくのが習慣になっていて（京浜東北線の電車の中でよく読んでいた）この５冊が選ばれることが多かったように思います。

この５冊のどこが気に入っていたのだろう？と思いながら読んでみたのですが、面白いことに気がつきました。『ひもぐつ』以外の４冊は「何かを作るお話」なんですよ。

ピクシー絵本の内容は「動物のお話」「家族のお話」「仕事のお話」「数のお話」「冒険のお話」「友達のお話」など多種多様です。その中で「何かを作るお話」が何冊も上位を占めるのですから「何かを作る」ことに対して、特に興味を持つ子供だったのかもしれないですね。

そんな子供も大人になり、医用機器を作る仕事に就き、毎日毎日「作っては壊し、また作る」ことを３０年近くやってますが、一向に飽きることがありません。

ちなみに『ひもぐつ』は、こんなお話です。

あたらしい赤いひもぐつを買ってもらった主人公（トーマス）が、お母さんにひもを結んでもらって出かけたら、かけよってきた子犬にひもぐつのひもをほどかれてしまいます。家にもどってお母さんにひもを結んでもらおうとしましたが、お母さんはパンを作っていて手が離せません。そのあともいろんな人に頼むのですがみんな忙しくて結んでもらえない。「だれも手伝ってくれないなんてひどいよ」とがっかりしていると、女の子が通りかかります。「わたしが教えてあげるわ。結び方をおぼえて自分で結べばいいじゃない」

トーマスは練習し自分で結べるようになりました。８９回目で！

これを読んで（わたしもひもぐつのひもを結べるようになりたいなー）と思いました。最後のページには「くつひもの結び方」が載っていて、まだ履いたことのない『ひもぐつ』に憧れ、眺めていた記憶があります。*1

*1:『ひもぐつ』は「できないことができるようになったお話」であり、そこにも惹かれる要素はあったと思いますが、当時は「ひもぐつへの憧れ」が強すぎて、著者が伝えたかったことは受け取れてなかったなぁ。

誰も使ってない機能にバグが見つかった時にどうするか

ある機能にバグが見つかりましたが、その機能を使っている人はいません。
1. バグを直す
2. 放置する
3. 機能を削除する
品質が上がるのはどれ？製品価値が上がるのはどれ？

— HARADA Kiro (@haradakiro) March 8, 2019

 

Twitterのタイムラインにこんなツイートが流れてきました。面白い問いですね。数年後にこれを見てどう思うのか（今の自分と比べてどう変わったのか、または変わらないのか）に興味があるので考えたことをメモしました。（自分宛てなので好き勝手に書いてます）

なお、考えている最中「いつか誰かがその機能をうっかり使うかもしれない」呪縛に取り憑かれて何度も脱線したので「その機能は未来永劫、絶対に使われることはない」を前提とします。あと「誰も使わない機能をなぜ作った？」「他の機能は大丈夫なのか？」についても考えないことにします（書いておかないと妄想が思考を邪魔するので書いた）。

「3. 機能を削除する」について

この中だと「機能を削除する」が好きです。めっちゃ好き。こんな風に書くと「好きとか嫌いで仕事してはいけません」と叱られてしまいそうだけど「機能を削除する」が好き。今の自分ならこれを選びます。

誰も使ってない機能だとしても製品の一部として提供している間は何かと手間がかかります。新しい機能を追加したり、既存の機能を変更するたびに誰も使ってない機能との関連や影響を考えるだろうし、リリースのたびに誰も使ってない機能が正しく動くことをテストしなればならないし。ちょっとした手間であっても塵も積もれば山となるわけで大変なんだよぅ。誰も使ってない機能にコストをかけるのはバカらしいのでやりたくない気持ちもある。そこに労力をかけるくらいなら、違うこと（やるべきこと）に使いたい。仕事とは言え（誰も使ってない機能なのに…）と思いながら作業するのは精神的に苦痛です。

「機能を削除する」ためのコストはかかるけど、以降「誰も使ってない機能」に関してコストはかかりません。良い。

お客さまにとっての価値

元々使ってないので機能を削除しても何も変わらないのかな。個人的にはシンプルになって良いと思うけど。その機能分プライスダウンするなら価値は上がりますか？何に価値があると思うのかは人それぞれでむずかしいと感じるけど、価格は分かりやすいと思う（この文脈では「安かろう悪かろう」は無いものとします）。それ以外だと何だろう。今後は「誰も使ってない機能」のために消費していた（消費するであろう）リソースを他の何かに割り当てられると思えば「新しい価値」を提供することは（計算上）可能のはずなのだけど…

「1. バグを直す」について

製品として提供してしまった機能はそう簡単には削除できません（少なくともうちの製品はそうです）。となると「バグを直す」か「放置する」のどちらかを選ぶことになります。ここで「バグを直す」を選びたくなるのは…自己満足なのだろうな。バグがあるのが分かっているのに直さないでいるのは気持ちが悪い。直せばスッキリする。ただそれだけなのだな。バグを直すには多少なりともコストがかかるので「未来永劫、使われない機能」なら放置した方が安い。

お客さまにとっての価値

元々使ってないのでバグを直しても何も変わらない。うっかりリリースノートに「バグを修正しましたっ」と書いたら（そんな機能は使ってないし、むしろ要らなくね？）（それよりもこっちの機能をどうにかしてほしい）とか思われたりしてね。価値が下がってしまう可能性がある。

「2. 放置する」について

お客さまにそのような問題があるということをお知らせした上で「放置する」なら受け入れられそう（自分が）。何もしないでそのまま放置するのと、バグを直すことにしたのに（優先順位が最下位のため）いつまでも直さないでいるのは似ている。これについてはまだ自分の中にうまく取り込めていない感じ。全てのバグを直すことはできないのは分かっているんだけどな。完璧主義者でもないのに変なの。

お客さまにとっての価値

元々使ってないので放置しても何も変わらない。問題を公表したことが良いイメージ（誠実性や透明性など）につながるのなら、なんらかの価値を与えられるかもしれない。うーん。ちょっと無理があるね。何も変わらないですね。

ここまでのまとめ

本題とは外れますが「自己満足のために仕事してる部分がある」が観測できたのはよかったです。これからは暴れる前に何かを主張する前に（これは自己満足かな？）と問いかけるようにしたい。あと熱中してる時とか…（身に覚えがある）。スッキリした時もかなり怪しい。スッとしたとかツイートしてる場合じゃないわよ（笑）。すこし消化不良するくらいが私にはちょうどいいのかもしれないな。いずれにせよ、仕事に自己満足はいらない。

「多数決で決める？」

開発現場で課題や問題を解決していく最中におこる「小さな会話」が「よいチーム」をかたち作る（のではないか）という仮説から、うちのチームでよく使われる「フレーズ」をいくつかのイベントで紹介したのですが、とうとうボット化する者が現れました。これは感慨深い…。ありがとうございます！

yoshitake-1201.hatenablog.com

ちなみに私達は、資料で詳しく紹介されてないフレーズが通知されたときは「こういう風に使ってるんじゃないかな？」と想像しながら意見交換しています。
（なお、我々の中では「多数決で決める？」というフレーズは、「このままだと多数決になっちゃうよ、それでもいいの？」という感じで使っているんだろうという結論になりました。今度ご本人たちにお会いしたときにどういう感じで使っているのか聞いてみようと思っています）

詳しく紹介していないフレーズもこんな風に話題にしてもらえるのは想定外でした。これもまた嬉しかったです。福岡と栃木ではいつお会いできるか分からないので（笑）「多数決で決める？」というフレーズについて解説しておきたいと思います。

こんな良いことが起きる

• 決めようとする、決まる
• ハッとする（関さんに決められてしまう、やばい！）*1
• それまで黙っていた（実は意見のある）人が口を開く（そうならざるを得ない）
• もう少し（ちゃんと）考えたくなる、考える
• 難しいかもしれないけど、より良いものを選べる

状況

• どうでもいいことを話しているわけではないのに、みんながノッてこない
• 論点がずれてきた
• こうしたほうが良いと薄々気がついているのに言わない（やれるのにやりたくない雰囲気を出してる）
• 間違ってはいないけど（最適解ではない）安易な方に流れてしまいそう

解説

「多数決で決める？」は「多数決で決めちゃダメなもの」に使います。普段の開発の中で何かを決めたり選んだりするシーンってよくあると思うのですが、多数決で決めていいものなんて無い（そういう開発を私たちはしていない）んですね。みんなそれは分かっています。

状況にも書きましたが、話し合っているうちに論点がボヤけてしまうことってあるんですよ。だんだん理詰めではなくなってきて「納期がー」とか（もう今日は結論までたどり着けなくてもいいかぁ）と時間切れを狙って（るように見えるだけかもしれないけど）ダラけてしまう、みたいなの。ないですか？

そんな時に誰かが「じゃあ、多数決で決める？」と言うと（いやいやいや、そうじゃないだろwww）と思いますし、その一言で場の雰囲気も変わります。みんなでクスッとするのがいいんですよ。

おまけ

「多数決で決める？」と似たフレーズで「うなずきんで決める？」があります。意思決定支援ツール『うなずきん』に話しかけると「うんうん」と頷いてくれるので、自分の都合のいいように話しかけて使うんだけど、たまに頷かない（首を左右にふる）時がある。うちのチームに３個くらいあります。

うなずきん NatureVer. Green

おまけのおまけ

うなずきん以前の意思決定支援システム（懐かしい）

*1:間違ってはいないけどヘンテコで難しいやつにされる可能性がある

何かを始める時に『やめどき』を決めておく

２０１９年が始まって１か月半が過ぎようとしています。『今年の抱負』のようなものを設定しなくなってからだいぶ経つのですが、今年は５０才を迎える記念すべき年なので、何かひとつ新しいことを始めたいな！と思っています。

始めるより終わりにするのが大変

何かを始める時ってそれなりに労力が必要です。始めてからそれを継続するのも大変なんですけど、一番大変なのは（途中で）やめる時です。自分（たち）でやるぞ！と決めたことをやめるわけですから、多少の痛みを伴います。でも痛いのは嫌なので無意識に避けてしまうのか、なかなかやめられないんですよね。

やめどきがわからない（わかりづらい）ケースもありますね。ダイエットなどは目標体重があるので比較的わかりやすいと思いますが*1、チームの風通しを良くするために朝会を導入します！みたいなケースです。風通しが良くなればいいのですが、どうなんでしょうか。

『やめどき』を決める

うちのチームでは、何かを始める時に『うまくいったらどうなるの？』（風通しが良くなるとどうなるのか、どんな良いことが起きるのか）について話します。それと一緒に『やめどき』を決めておく場合があります。最近だと新しい技術に対する調査がそうだったかな。まだ誰も正解を知りません。「調査は明日までね。そのあとはまた考えよう」ー うまくいってもいかなくても「明日まで」というのがとても重要です。これがないと永遠に…ということはないでしょうけど２、３日なんてあっという間に溶かしそうですよね。

朝会の話に戻ると「１か月限定」でやってみるのはどうでしょうか。１か月やったらおしまいです。で、チームのメンバーから「どうしても続けたい。私たちには朝会が必要なんだ！」という声があがったら、また「１か月限定」でやってみるのです。こうすれば（それほど風通しが良くなったわけでもないけど、朝会自体は悪いことではないし…）と、その効果に疑問を持ちつつも何となく続ける、ということがなくなります。

『やめどき』を決めておいたほうが良いケース

• はじめてやるもの
• 正解がわからないもの
• ゴールが設定しづらいもの
• 効果がわかりにくいもの
• 難しそうなもの
• やること自体は悪くない（むしろ良い）もの
• とりあえず始めようとしてるもの
• 熱中してしまうもの
• ずっとやる（継続できる）と思っているもの
• やりたくないけどやらないといけないもの
• やりたいけど躊躇してしまうもの

『やめどき』を決めておくと「やめる時の労力がゼロ」になるだけでなく「何かを始める時のハードル」もちょっぴり下がるような気がしませんか？…というわけで、私も１か月限定でやってみようと思います。体幹を鍛えたい。まずはプランクから！

Nike Training Club

• Nike, Inc
• ヘルスケア／フィットネス
• 無料
• 

*1:実はダイエットってやったことがないのであれですが、目標体重になってからもダイエットは続くのでしょうか？体重を維持するためには続くのかもしれませんが、それはダイエットとは言わないのだろうと思い「やめどきがわかりやすい」一例として挙げました。→ 調べました。ダイエットとは「健康または美容上、肥満を防ぐために食事を制限すること。転じて、何らかの方法で減量すること」だそうです。この記事では「目標体重になった。これ以上は減量したくないのでダイエットをやめる」ため「やめどきがわかりやすい」ということにします。（脚注は便利なのでどんどん使っていきたい）

お客さまから見た『落とし穴』という視点

近所のBOOKOFFで仕事関連の専門書を購入しました。ウルトラセール中（全品20％OFF）*1で、定価4,000円（税別）の本がBOOKOFF価格で510円、さらに20%OFFの408円でした。

デジタルイメージングの落とし穴 CT&MRI編―CT・MRI検査の進め方とスキャンテクニック

近くに医療系の大学があるので毎回わくわくしながら専門書のコーナーを覗くのですが、これは私の中での専門書（医学系）部門ベスト３に入るくらいの掘り出し物！新年から縁起が良いです。

２０年前に発行された本ですが、医師や診療放射線技師（以下、お客さま）が本当にやりたいこと、目指したいものは基本的には変わってないように思います。本のタイトルにもありますが、これまでお客さまから見た『落とし穴』という視点では考えたことがありませんでした。同じものでも視点が変わると違って見えたり（ああ、そういうことだったのね）と理解が深まったりします。とても楽しみです。

専門的な内容ですので読んだからすぐに分かるというものでもありませんが、医療の現場でお客さまがどのようなことを懸念している／していたのかを知り、落とし穴に落ちないよう（技術で落とし穴自体を塞げるなら塞ぐような*2）手助けがしたいです。テストの合間の休憩時間などを使って１年かけてゆっくり読んでいこうと思います。

*1:BOOKOFFウルトラセールは１月１日〜１月４日です

*2:難しい問題は今でも残っているかもしれないし、２０年経った今だからこそ実現できるものがあるかもしれない