Google スプレッドシートの関数でWebからデータを取得する

　Excel買うのはちょっと高いなぁと思っている時に重宝するのが、Google スプレッドシートです。ブラウザがあればどこでも使えて嬉しく、あのデータあのパソコンに入ってるのにとか、そういったことから開放されます。さらに他の人との共有も簡単なので、使い所沢山あります。
　そんなGoogle スプレッドシートですが、Googleならではというような機能もあります。その1つがImport系のセル関数です。幾つかあるのですが、Webからデータを収拾できるものが幾つかあります。地味だけど便利なので、簡単に紹介してみます。

Import関数

---

関数名	概要
IMPORTXML	XML, HTML, CSV, TSV,RSS/Atom XMLフィードなど、構造化データからデータをインポート
IMPORTHTML	HTML ページ内の表やリストからデータをインポート
IMPORTFEED	RSS, Atom フィードをインポート
IMPORTDATA	指定したURLのデータを、.csv形式または .tsv形式でインポート

　表をみてもらうと解るように、取得できるデータ種別が重複する部分があります。一方で、使い方としては少しづつ異なっているので、順番に見ていきましょう。

ImportXML

---

　個人的には、これを使う機会が一番多いです。関数名としてはXMLですが、構造化データを扱う関数となっています。構造化データというのは、それぞれの項目に意味を与えられたデータとなります。XMLやRSS,Atomであれば、それぞれの要素名・データというペアで出てきますよね。またCSV,TSVにしても、列ごとに項目名が与えられ行はその塊という形になっています。またHTMLも名前の一部がmarkup languageとなっているように、構造化データです。HTMLを取れるということで重宝します。

ImportXMLの使い方

ImportXMLの使い方は簡単です。取得先のURLと取得する部分（XPath_query）を指定するだけです。

構文

IMPORTXML(URL, XPath_query)

使用例

IMPORTXML("https://en.wikipedia.org/wiki/Moon_landing", "//a/@href")

　上記サンプルは、WikiPediaからリンク先一覧を取得しています。

　現実的にこの関数を使う時は、HTMLを取得対象とすることが多いと思います。何故ならWeb上のデータの殆どがHTML形式で提供されているからです。そこでポイントになるのが、XPathの書き方です。方法については色々ありますが、Chromeの機能を利用するのが一番ラクです。取得したい場所を選んだ上で、検証→Copy→Copy XPathで取得できます。こんな形で出てくるので、

//*[@id="cm_cr-review_list"]

ダブルコーテーションをシングルコーテーションに置き換えて利用します。

ImportHTML

---

　ImportHTMLは、HTMLページ内の表やリストからデータをインポートします。単純にHTMLを取得するのではなく、その中のテーブルかリストを取得するという、素直じゃないやつです。

ImportHTMLの使い方

取得先のURLと抽出するタグのタイプ（table or list）、出現順を指定します。一つ目のテーブル／リストを取得したい場合は、最後のindexは省略可能です。

構文

IMPORTHTML(URL, query, index)

使用例

IMPORTHTML("http://en.wikipedia.org/wiki/Demographics_of_India","table",4)

　取得例は、次のような形です。

　関数名からは予想できないようなものが取得できるので最初は面食らいますが、意味が解ると便利です。

ImportFEED

---

　ImportFEEDは、RSSフィードやAtomフィードをインポートします。ImportXMLでも実現できるのですが、RSSやAtomフィードに特化している分、余計な事を考えなくても欲しいデータが取れるようになっています。

ImportFEEDの使い方

取得先のURLとオプションを指定してます。オプションの一つ目のクエリは、取得するデータの指定です。デフォルトがfeedになっていて、通常の場合変更する必要はありません。見出しは、一番上の行に見出し行をつけるかどうかで、デフォルトでは付けないようになっています。最後のアイテム数は、取得するアイテム数です。無指定の場合は、全て取得します。

構文

IMPORTFEED(URL, [クエリ], [見出し], [アイテム数])

使用例

IMPORTFEED("http://news.google.com/?output=atom")

ImportDATA

---

　最後にImportDATAです。これは、CSVやTSVを取得します。何気にスプレッドシートで、他のCSVを扱うのは難しかったので、この機能は中々便利です。一方でCSVでデータ提供している所は、あまり無かったりします。

ImportDATAの使い方

取得先のURLを指定するだけという潔さです。

構文

IMPORTDATA(URL)

使用例

IMPORTDATA("http://www.census.gov/2010census/csv/pop_change.csv")

まとめ

---

　プログラマという人種は、わりとすぐにプログラムを書いて解決しようとしてしまいます。一方で、既に提供されている機能で実現できるのであれば、それを使うに越したことはないです。ケースバイケースで考えてみましょう。
　ちなみに上記の関数からアクセスした場合のユーザーエージェントは、次のようになっています。サイト側でブロックされている場合があるので、ご注意を

Mozilla/5.0 (compatible; GoogleDocs; apps-spreadsheets; +http://docs.google.com)

See Also:
環境構築レスでAmazonの商品レビューを取得する

データを集める技術 最速で作るスクレイピング&クローラー (Informatics&IDEA)

Rubyによるクローラー開発技法　巡回・解析機能の実装と21の運用例

IFTTTで雑にエゴサーチして通知する

　クローラー本を出していますが、可能であればプログラミング・レスで楽にしたいと思っています。そんな時にお勧めのツールが、IFTTTです。IFTTTは、説明不要かもしれませんが、Webサービス同士を連携するアプリです。今のご時世、サービス同士を組み合わせるだけで殆どのことが出来るのです。
　ということで、IFTTTとその他のサービスを利用してエゴサーチの仕組みを作ってみましょう。エゴサーチとは、自分の名前や自社の商品など検索することの俗語です。ご多分にもれず、私も自分の本のエゴサーチに勤しんでいます。今回、エゴサーチの収拾元としては、GoogleとTwitterとします。

IFTTT側の仕組み

---

　まずエゴサーチの仕組みの構築です。Twitterの場合は、単純に検索結果で新規のものの抽出です。Googleのものも検索結果の新着を使うのですが、これをWebサービスでどう実現するかが課題です。お勧めなのが、Google Alertです。Google Alertは、予め決めておいたキーワードが出てきたら通知するという素晴らしいサービスです。昔からあり、コンセプトも良いのですが何故かマイナーなサービスです。
　データの収拾元が決まったことで、IFTTT側の構成を考えてみましょう。今回は通知するだけではなく、可能であれば蓄積したいと思います。そこで、Googleスプレッドシートに保存していくことにします。通知が必要であれば、IFTTTのモバイルアプリを入れてAcitonをIF Notificationsに指定すれば大丈夫です。全体像をまとめると次のような図になります。

Googleアラートの設定

---

　Google Alertの問題点は通知方法です。デフォルトはEメールです。が、メールで送られても扱いづらいです。もう1つの通知方法としては、RSSがあります。これが意外に使えます。設定は簡単で、キーワードを入力し、オプションで頻度を"その都度"にし、配信先を"RSS"とするだけです。

IFTTT側の設定　Googleアラート編

---

　IFTTTは、Google Alertの通知とTwitter検索を別々に設定します。まず、Google Alertです。先に設定したアラートから、RSSのURLをコピーしておきます。そして、IFTTTで新規のレシピの作成をします。まずレシピのthisにあたる"Choose Trigger Channel "ですが、チャンネルとしてRSSを指定します。

次にRSSで"New feed item"を選びます

RSSのURLを入力します。

今度はthat側である"Choose Action Channel "の設定です。Google Driveを選びます。

詳細設定で、"Add row to spreadsheet"を選び新規の行を追加するようにします。

　これでレシピの作成は完了です。こんな感じでデータが蓄積されていきます。

IFTTT側の設定　Twitter検索編

---

　次は、Twitterの検索です。こちらは、Googleアラートの設定よりも簡単です。IFTTT側にTwitterのトリガーのパターンがあるので、それを利用します。初回利用時は、Twitterとのアカウント連携が必要になります。内容を確認して、許可を与えてください。

　"New tweet from search"を利用し、検索条件を設定します。

　アクション側は、先程のGoogleアラートと同様に設定します。さっくりと簡単です。

まとめ

---

　上記の検索を、自分でプログラムで組もうと思うとそれなりに大変です。これが、Webサービスを組み合わせることにより、15分程度で実現できるようになっています。また拡張性も優れていて、例えばもう少し細かくコントロールしたいのであれば、受けての方をGoogle Apps Scriptで取得するといったことも考えられます。アイデア次第でいろいろ出来るので、ぜひ試してみてください。

データを集める技術

Rubyによるクローラー開発技法　巡回・解析機能の実装と21の運用例

AWS本とクローラー本のKindle版がお買い得になりました。

　予定をとっくに過ぎているのに原稿が書けません。そんな秋の夜長ですが、自分が書いた本がKindle版で割引率が拡大しています。結構お得感が出ているので紹介しておきます。
　Kindel本は、改訂版が出た時に無料でアップデートできるという特典があります。技術書の寿命はせいぜい2年くらいですが、改訂で上手く生きながらえる場合もあるので、個人的には最近技術書を買う場合はKindle版しか買っていないです。

Rubyによるクローラー開発技法

---

　編集者も何故売れるのか解らないと言っていたクローラー本です。発売して2年半経ちますが、まだ読まれているようで、ブログやTwitterで感想かいてくれる人が今でもチラホラいます。著者としては嬉しい限りです。取得先のサイトの構成が変わっていることも多く、そのままでは動かないサンプルも多くなっていますが、枯れたツールを使っているので取得自体は同じようにできるはずです。
　この本のKindel版の割引率は高く、定価3,218円のところが30%引き（965円）の2,253円。さらに20%ポイント還元なので、実質1,803円となっています。紙の方もこれくらいの価格だと、もう少し試してみようという人も増えるのではないかなぁと思います。

Rubyによるクローラー開発技法　巡回・解析機能の実装と21の運用例

Amazon Web Services パターン別構築・運用ガイド

---

　発売して1年半が経ちましたが、今も着々と売れているAWS本です。内容的には、少し古くなっているところがあるので、多少手直ししたいところです。ただ、EC2やRDSなどの仮想インスタンス、VPCなどのネットワークを中心に扱っているので、基本的な所は変わっていません。ということで、今でも充分役にたつと思います。
　紙の本が3,672円ですが、Kindle版は20%割引（734円）の2,938円です。わりと常時20%ポイント還元セールしているので、実質2,351円で購入できます。定価が高いので、結構お買い得感がでています。

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

Amazon Web Services クラウドネイティブ・アプリケーション開発技法

---

　ノリノリで書いて収拾がつかなくなったのが、この本です。ページ数が多くて分厚く高くなりすぎたという点と、AWS側の進化が早すぎてAPI Gateway,Lambda,Cognitoの変化に涙しています。あと、SDK周りのバージョンアップも。ただ、わりと実用的な本になっているので、この本片手に写経して貰えれば今後のシステム開発の流れというのが垣間見れるのではないかなと思います。
　この本も、同様にKindle版が割引されています。定価3,974円が、20%割引（794円）の3,180円。さらに20%ポイント還元で実質2,544円となっています。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法　一番大切な知識と技術が身につく

感想

---

　お前が言うなと言われそうですが、PDFの作り方を、画像ベースではなくテキストベースに変えて欲しいです。検索できない技術書というのは、やっぱり悲しいし、困っている人が多いようです。根本のところは、技術書の流通量とコストの問題ですが、何とか打破できないですかねぇ。

家賃補助がある場合のマンション購入考

　たまに呟いていますが、マンションの内覧が好きです。正確に言うと、内覧をしながらその物件の10年後、20年後の価値を考え、購入するとどれくらいの利回りになるのかと妄想するのが好きです。そういう意味で、値付けパターンが単純な新築より、中古マンションをめぐるのが好きです。
　内覧の際に考えるのが、2つの観点です。1つは利回りで、もう一つはキャッシュ・フローです。無料の不動産情報誌とか読んでいると、簡単なローンシミュレーションなどは載っているのですが、それだけでは足りないように思えます。ということで、私の思考シミュレーションをまとめてみます。また家賃補助というサラリーマン的な観点も考慮してみます。ちなみに個人的な考え方なので、突っ込みどころは満載です。

キャッシュフローから考える

---

　キャッシュフローとはお金の流れです。手元に入ってくるお金と出て行くお金を差し引いたものと考えてください。住宅に関するキャッシュフローを考える上で、仮に現在の家賃が13万円として、同等＋αの住宅を購入しようとしたら4,000万円だったしましょう。フルローン・ボーナス返済なし・35年返済だと、毎月112,914円返済することになります。計算の単純化の為に11万円としましょう。ただし、ここに共益費や修繕費、固定資産税などがかかってきます。共益費と修繕費は全期間を通して月3万円と仮定し、固定資産税は年10万円と仮定すると、月8万3千円今日が必要になります。合計すると19万円強となります。キャッシュフロー的には、賃貸の場合より悪化します。
　ここまで書くと、マンションは最後に部屋が残るので資産価値があるという意見が出てきます。では、資産価値を含めて、次は利回りを考えてみましょう。

利回りから考える

---

　マンションの購入の際に考える利回りとは何でしょうか？究極的には、Exit（売却）を前提に購入金額から売却金額と経費（税金・共益／修繕費）を差し引いたものでしょう。しかしまぁ、一般的にいうと大幅なマイナスになります。そこで、自分が住んでいる分を他人に貸していると仮定して、周辺相場の家賃を参考に、それを収入と考えてみましょう。

購入金額：4000万
売却金額：2000万
居住期間：35年間
共益／修繕費合計：1,260万（3万円／月と仮定）
固定資産税合計：350万（10万円／年と仮定）
家賃合計：5,460万（13万円／月と仮定）

計算式　2,000万 + 5,460万 - 4,000万 - 1,260万 - 350万 = 1,850万

仮定ばかりで突っ込みどころ満載ですが、35年間住んだとしたら1,850万円のプラスですね。
家賃分を考えずにいると、単純に3,610万円のマイナスです。
単純に賃貸の場合の賃料総計は5,460万なので、2000万弱くらいは有利になっていますね。
（補修費が掛からないという前提ですが）

家賃補助について考える

---

　上記のこと検討すると、35年という長期スパンであれば購入の方が有利になります。しかし、購入の場合でも部屋の中の修繕費費というのは必要なので実際のところはもう少しコストが掛かってきます。一方で賃貸に比べると、購入の方が住宅の満足度は上げやすいというのも事実です。
　ただし、サラリーマン的に考えると、もう一つのファクターがある場合があります。それが、家賃補助です。家賃補助とは、マイホームの人は貰えないけど賃貸の人には補助してもらえるという、謎のシステムです。何故って合理的な説明は難しいですが、家賃補助があるという所は未だに多いと思います。
　正確にいうと家賃補助のシステムについても、補助分が税金掛かったり掛からなかったりと色々あります。今回は単純化して、月5万円の補助があると仮定します。すると、どうなるのでしょうか？家賃合計が5,460万から3,360万円になります。その差、2,000万円。上記の賃貸のメリット分を吸収する形となります。これを考えると、どちらを選んでも一緒というのが元日なんですね。
※今回は35年間で、部屋の価値が半分になると前提を置いています。これが値段が落ちない場合もあるし、1,000万円でも売れない場合もあるというのが分譲マンションの怖い所なのですね。ちなみに地方では、35年経つと全く売れません。

まとめ

---

　上記のようなことを考えると、それほど有利な物件というのが出てこなくなります。地味に家賃補助って大きいんですよね。結果、買わなくなっちゃいます。元々同じところに35年住む気もないですし、フルローンを前提にする気もありません。10年間というスケールで考えると別の結果がでる場合もあります。ということで、さっくりどこかを買うこともあるとは思いますが、考え方の一例として紹介だけしておきます。まぁ家ってのは、その人を取り巻く状況によって何が有利ってのは千差万別なので、自分なりの考え方持つとよいですよという話です

Ingress レベル16の私が、Pokemon Goを2日間やった感想

　ちょっと上から目線のタイトルにしてみました。ハマり過ぎるのが解っていたので、Pokemonはするつもりはなかったです。しかし、こんなに流行になってしまうと、どんなものか把握していないと差し障りが出るレベルなので始めました。まだ数時間やったレベルですが、現時点での感想はIngressの問題点を解決して万人向けに上手く調整してきたという印象です。

Ingressの問題点

---

　Ingressはよく出来たゲームですが、万人受けするゲームではないです。また、幾つかの問題点があります。それは、基本的には陣取り合戦なので他のユーザを敵と認識しやすいゲーム設計となっている点です。その原因の1つに、レベルとメダルが密結合している点にあります。レベル9以上にレベルをあげる為には、得点＋メダルの数が必要になります。そのメダルの中に幾つかに、他ユーザの行動によって左右される条件があります。その最たるものがガーディアン（守護者）というものです。このメダルは、ポータルという拠点を何日間か防衛しないと取得できません。金のガーディアンメダルを取るためには、20日間防衛する必要があるのですが、19日目とかに攻撃され陥落しようものなら攻撃した相手恨んでしまいますね。
　上記のようにIngressの基本は、2陣営に分かれての戦いになります。その為、どうしても敵味方の概念が出てきてしまいます。

Pokemon Goの場合

---

　それに対してPokemon Goの場合は、基本的には他のユーザの行動が自分のプレーに影響されない設計になっています。同じ場所でポケモン探していたとしても、取り合いという形にはなりません。その為、周りにプレーしている人がいても気になりません。リアルでのユーザ行動見ていると、複数人で一緒に移動したりと仲良くプレーしている人が目立ちます。
※ちなみに、Ingressの場合は他ユーザに遭遇する機会は少なかったのですが、他ユーザに気がついたら基本的にコソコソと撤退していました。

　この部分、Ingressで培ったノウハウを、よく活かしてるのが解ります。特に感じるのが、メダルとレベルを分離したことです。また、唯一の戦いの場であるジムバトルも、揉める要素が最小になっているように思います。まだルール理解していない部分も多分にありと思いますが。。。

解消していない問題

---

　もちろんPokemon Goになっても解決していない問題は沢山あります。例えば、都会・田舎の格差問題です。ポケスポットは、Ingressのポータルのデータを引き継いでいます。その為、Ingressのポータル過疎地はポケスポット過疎地になっています。ポケスポット以外にもポケモン出るようになっていますが、出現率でみるとやはり低いようです。そうなると、やはり田舎のユーザには厳しい作りとなっています。一方で、ポケスポットを連続で利用できる間隔が短くなっているので、Ingressに比べると少し緩和しているかなぁという気がします。

課金プレーについて

---

　Ingressの場合、殆ど課金する意味がなかったです。しかし、Pokemonの場合、ブーストアイテムはレベルアップでプレゼントされるか買うかしかないです。やっているうちに課金したくなる作りなので、上手いこと考えたなぁと思います。また、買わなくてもゲームは充分楽しめるので、廃課金とかの問題を出さない作りで良いと思います。

電池消費について

---

　体感レベルですが、電池の消費激しすぎます。モバイルバッテリーで充電していても、Nexus 5xだと電池が減ってきます。この辺り、バージョンアップで解消して欲しいですね。モバイルバッテリーが必須です。

感想

---

　データを持っているところ（Niantic）と、キャラクターを持っているところ（任天堂）は、強いですね。ただブランドに傷を付けないように、いろいろ苦労しているのが垣間見れます。いずれにせよ暫くはブーム続くと思われるので、ウォッチしていきたいです。

Anker PowerCore 10000 (10000mAh パナソニックセル搭載 最小最軽量* 大容量 モバイルバッテリー) iPhone / iPad / Xperia / Android各種他対応 マット仕上げ【PowerIQ & VoltageBoost搭載】*2016年1月末時点 A1263011

技術書執筆に関するお金の赤裸々な話

　本を書いてると、よく『儲かるの？』と聞かれます。私は決まって、『儲かりません』と答えます。総額ベースではそれなりに貰っているのですが、何故そう答えるか整理してみます。

印税の仕組み

---

　執筆に関する収入として、大きく２種類があります。１つはページ数に対しての単価が設定され、発売部数に関係なく支払われるタイプ。もう１つは、印税率を設定して書籍価格×出版部数×印税率が支払われるタイプです。前者は雑誌やムック本などに多く、それ以外のものは後者の印税のパターンが多いです。
　また印税にも契約条件が細分化されています。大きく分けると刷数に対して支払われるのと、実売ベースのものです。当然、筆者としては前者の方が有利になります。

１冊書くと、どれくらいの印税になるのか

---

　最近書いた『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』のケースで考えてみましょう。この本の価格は、3,680円＋税となっています。印税の対象は消費税は除外されます。税込み価格が3,974円ですが、3,680円に対して印税が支払われます。そして気になる印税率です。これは出版社や初版・増刷によって異なりますが、8〜10%というケースが多いのではないでしょうか。（詳細は内緒）そして、初版部数は技術書だと3,000〜4,000冊というところではないでしょうか。ということで計算式は次のようになります。

3,680（円） ×　3,000（冊）　× 0.08 = 883,200（円）

　88万円と聞くと、結構な金額に思えます。ただこれは、一人で全部書いた場合です。実際には、この本は6人で書いています。割り方は執筆者の間で取り決めですが、6等分したとしたら、147,200円です。どんどん小さくなってきましたね。

時間あたりの労働単価

---

　もう少し掘り下げて、時間辺りの労働単価は幾らになるのでしょうか。計算を単純化するために、1人あたり100ページで15万円支払われたとしましょう。ページあたり単価は、何と1,500円となります。そして問題になるのが、1ページをどれくらいの時間で書けるのか。一概に言えませんが、調査の時間とかを考えると2〜3時間は見ておいた方がよいでしょう。（もっと早く書ける場合もあるし、もっと時間が掛かる場合もあります。）3時間としたら、時給500円ですね。
　というところが、儲かりませんと答える所以です。まぁ上記は初版のみ考えていましたが、増刷時の旨味はあります。

感想

---

　とは言っても、儲からないから書くのは損だという訳ではありません。執筆に関する人生のボーナスは沢山あります。ということで、一度出すと繰り返して書いてしまうのですよね。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく (Informatics&IDEA)

See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

AWS Summit 2016 Tokyoの感想

　3日間のお祭りが終わったので、感想を残しておきます。私の立場としては、出展者やAWS本の著者、ベンダー、JAWSUG参加者など色々あります。まぁその辺りを無視して、ただの感想です。

出展者として

---

　AWS Summitのブースに立ったのは久しぶりでした。ブースに訪れてくれるユーザのAWSの関心の高さ・具体性が段違いに高いというのが印象的でした。たしか前にたったのは３年程前で、その時は情報収集段階という人が多かったです。今年は、もう既に導入している／導入検討している上で、具体的な悩みなどを色々聞くことができました。後のフォロー次第ですが、出展者側としては、AWS Summitはやはり重要な機会ですね。

AWS本の著者としてて

---

　ブースに『Amazon Web Services パターン別構築・運用ガイド』と『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』を並べて、立ち寄った人に紹介していました。パターン別構築・運用ガイドについては、結構な割合で知っている人が多くて嬉しい限りでした。一方で、クラウドネイティブ・アプリケーション開発技法の知名度はまだまだでした。もう少し広まればなぁと思います。まぁ発売１年と１ヶ月で、第４刷・初刷の差は大きいのかも。来年は、両方共しっているよと言われることを目指したいです。

セッション参加して

---

　ブースにいたり個別ミーティングをしてたりと、あまりセッションは参加できなかったです。参加したのは、２つのキーノートとウフルさんのIoTセッションです。前者については、昨年一年の振り返りと今年一年の方向性の確認のためです。概ね想定通りユーザー側の積極的利用が牽引するという形にいたのを確認できて良かったです。
※まぁこれも全国に広がったユーザコミュニティとそれを支えるエンジニアのお陰だと思いますが。
ウフルさんのセッションは、予想以上に良かったです。IoTというバズワードの陰で顕在化している問題もしくは落とし穴にハマりつつ乗り越えていった知見の共有が素晴らしかったです。

ランチ

---

　カレーが食べたかった。ただし、昨年の混雑を考えると仕方がないですね。

JAWS-UG

---

　JAWS-UGの認知を高める場としては、最高の場所ですね。スペースに対して人数が多すぎる部分はありますが、お祭りとしては大成功ではないでしょうか。ブースの片付けでLTは殆どみれず、ウルトラクイズは壇上手前で間違えたのは痛恨の極みでした。

感想

---

　お祭りのような３日間でした。今日からまた日常に戻って、一歩一歩進んでいきます。ただ３日間立ちっぱなしはシンドかったなぁ。