リーン開発の現場
という本のノートを描いて見た。この本は実例を交えながら紹介している本である。
当ノートは自分なりに本の中身を元にまとめて見ている。
個人的に後から考えてもいいのではみたいな章は省いたり、簡約したり纏めたりしてる。他にも自分で知っていることを含めて見たりもしているので必ずしもこれが正解とかは言えない可能性もあるのを忘れずに。
さて、そもそもアジャイルとかリーンとは何じゃ、ということをざっくり説明します。
ソフトウェアコミュニティの17人のオピニオンリーダーたちが2001年にユタ州のスキーリゾートに集まってソフトウェア開発を成功させる方法について議論しお互いの考えを擦り合わせていくうちにアジャイルソフトウェア開発という言葉が誕生しました。そしてソフトウェア開発を成功させる方法に関する共通のビジョンを見つけて文章化したもので、いわゆるアジャイルマニフェストと呼ばれる文章になったもの。
内容を以下に示す。
私達は、ソフトウェア開発の実践、あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を。
包括的なドキュメントよりも個人と対話を。
契約交渉よりも顧客との協調を。
計画に従うことよりも変化への対応を。
価値とする。すなわち、左記の事柄に価値があることを認めながらも私たちは右記のことに価値を置く。
- 顧客満足を最優先し、価値のあるソフトウェアを速く継続的に提供する
- 要求の変更はたとえ開発の後期であっても歓迎する。変化を味方に身に付けることでお客の競争力を引き上げる。
- 動くソフトウェアを２〜３週から２〜３ヶ月という短い時間の間隔でリリースします。
- ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働かなくてはいけません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
- 情報を伝える最も効率的な方法はフェイストゥフェイスで話すことです。
- 動くソフトウェアこそが最も進捗の重要な尺度である。
- アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなくてはなりません。
- 技術的卓越性と優れた設計に対する普段の注意が機敏さを高めます。 シンプルさが本質です。（言い換えると無駄なく作れる量を最大限にすること。）
- 最良のアーキテクチャ・要求・設計は、事故組織的なチームより生み出されます。
- チームがもっと効率を高めるかどうかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイルという言葉自体は2001年に誕生したが、ほとんどのアジャイルの方法論は１９８０年代にはすでに作られていた。アジャイルはこれらを包括的に指す言葉で、様々な共通点があればアジャイルとも言えなくもない。
つまり全てアジャイルとも言える。
逆に言えばではあるが、これらの共通点原則を持つものをアジャイルという多面的な表現を許容することでもあると考えれる。
ソフトウェア開発のフレームワークのことである。1990年ごろにできた。
スクラムは経験則に基づいたプロセス制御や複雑適用系理論を元にしている。
以下にコアコンセプトを説明する。
大人数で長い期間大きなものを作るのではなく、少人数で短期間で小さいものを作るのがスクラムであるということである。
XPの概要
1990年中盤に生まれたエクストリームプログラミングとは
シンプル
コミュニケーション
フィードバック
勇気
敬意
というジャンプばりの五つの価値を基盤にしたものである。
スクラムと並行して進化して来たためにほとんど同じ要素を持っている。例えばXPにおけるオンサイト顧客はスクラムのプロダクトオーナーとほぼ同一。
じゃあスクラムと何が違うかというと外向的か内向的かである。
スクラムはしばしばXPを取り囲んでると言われる。何故ならば組織構造の課題や外部とのコミュニケーションに着目しているからである。
ではXPはどうかというと、エンジニアリングプラクティスが主幹的だったりする。
- 継続的インテグレーション
自動ビルド、自動的な統合。そしてチームが開発したコードを自動テストする仕組み。これによって作業の品質が関わる早期のフィードバックをチームはより早く得ることができる
ペアプログラミング
- ペアでプログラミングする。学習や設計品質を最大限引き上げることができる。また欠陥の発生を最小限にできる。
ペアのレベル差が大きいと片方のレベルが格段に上がる。
テスト駆動開発
- テストコードを書いてテストを通すためのコードを書く。
またリファクタリングをしてコードを洗練させていく。
コードの共同所有
チームメンバは全員ソースを修正することが許されている。また奨励されている。これにより理解が進み協同的な感覚が生まれる。
インクリメンタルな設計の改善
- 初めはシンプルで実現可能な設計から始める。
- その後改善してブラッシュアップしていくアプローチ
カンバンの概要
カンバンはアジャイルソフトウェア開発におけるリーン的なアプローチだ。これは日本語から来てて工場にあるカンバンと同じところから来ている。つまるところ物理的な伝達システムのこと。
しかし、勘違いしてはいけないのが2004年にデイビットアンダーソンがソフトウェア開発におけるカンバンとしたのだ。間違っても天井に貼り付けるあのカンバンとは微妙に違う。
カンバンのルールを以下に示す
リーンの概要
リーンとは「TPS」というトヨタ生産方式を元にしたものである。（というかぶっちゃけ同じで西洋でTPSと呼ばれるだけの話。）このTPSという方式は様々なものに適用可能とされている。その中にはソフトウェア開発も含まれる。
よくある勘違いとしてアジャイルとリーンは共通の価値があるために親戚や同一視されるが起源は異なっている。
リーンは製造業から、アジャイルはソフトウェア開発から誕生した。お互いの原則は相性が良く、適用できる範囲も広い。
最近多いのは製品コンセプトの開発〜デリバリまでというエンドツーエンドの開発の流れ全体でアジャイルとリーンをどう組み合わせて適用していくのかということが探求されている。
このリーン（TPS）の原則を、リーンソフトウェア開発として提唱したのがメアリー・ポッペンディークとトム・ポッペンディークである。
全体を最適化する
システムの一部分の最適化に時間をかけても必ずしもシステム全体の最適化にはならない。
無駄をなくす
無駄とは、顧客に価値を付加することのないあらゆるものである。ソフトウェア開発では3つの大きな無駄がある。
品質を作り込む
プロダクトのテスト段階で毎回過度の欠陥が見つかるのであればプロセスに問題があると言える。
たゆまぬ学び
計画は立てることに意味があり、学びを得ることにその本質がある。この学びというのは実験を重ねることなどを指している。
成果の予測可能性はフィードバックにより高まる。
選択肢を幅広くもつ。
変化への耐性を持たせる。
意思決定を最終責任地点まで遅らせる。
- 取り返しのつかない所に来る前に（決定とも表現） 可能な限り学習をしてできるだけ実験を重ねる。
速く提供する
ステークホルダー全員についての深い理解と、彼らにとっての価値を何かということを考えるところをから始めるべき。
それによって継続的にビジネス価値を生み出していく流れを作る。
全員を巻き込む
優秀なメンバーは起床資源である。チームメンバーは公平かつ公正に適切に対価を得る人々であり、自律、熟達、目的に応じて意欲を感じるのだ。
改善を続ける
結果が重要なのではなく、人と結果を出せるシステムを育てるのが重要なのである。
つまるところある種の信頼が担保されたものを実行することである。
何言ってるんだって感じなのでつまるところ、
- 顧客の目で「価値」を定義。
2.その価値の流れを可視化する。
3.それを「エンドツーエンド」で「細く、速く」流れるようにする。
4.その流れの改善活動を現場で実際に仕事をしてる人が行う。
ということである。以下から実際に当該書籍を元に紐解いていこう。
一章 プロジェクトについて
スウェーデンの国家警察で作ってるPUSTという新しい捜査報告システムを元に紹介する。これを実現するにはある要件を満たす必要があった。
タイムライン
スタートは2009年9月から。一年後にはリリース。その後は隔月でリリース。
スケジュールの中で重要なマイルストーンは
1.0の最初のバージョン
1.4の警察全体で使えるようなったバージョン
早めにリリースしていくスタイルである。
理由としてはバグや思い込みなど仕様をすり合わせつつ行うことのできる点にある。よって頻繁なリリースをするというのは一度のリリースに抱えるリスクを減らすと言えるだろう。
また、リーンの特徴として開発のプロセスがどんどん変わって、進化し続けることが挙げれる。
スケジュール分割について
大きなプロジェクトでリスクを最小化する鍵は大きな像を分割する方法を見つけ出すことである。こうすることで、小さい機能を徐々に増やしていくことができてシステムを何度もリリースするインクリメンタルリリースを行える。リスク分散の観点からもユーザーにそれぞれ価値を送りフィードバックをされていくというより良くしたいという流れからも良い作業と言える。
今回の場合は地理的な場所と犯罪者別という点から最小化にかかった。
- リリース1.0から1.2
- 一つの地域のみに対応。
- 飲酒運転など武器の所持。よくある多い犯罪種のみ対応。
徐々に犯罪種のサポートを増やした
リリース1.3:
- ２つ目の地域に対する拡張リリース
これをメインリリースとした
リリース1.5
- 犯罪種別を追加押収品の管理システムなど他のシステムと統合したバージョンをリリース
このような形に分割した。
顧客について
これは警察組織のプロジェクトで顧客やユーザも身内であった。がこれは当該プロジェクトではある一人が主役である「顧客」として振る舞った。
エピックにあってるかどうか、詳細なフィードバックをもらうなどを行った。
（エピックは一般的には壮大な作品という意味だが、この文脈では大まかな要求、大きなストーリーという意味である。）
二章 チーム編成
ソフトウェア開発プロジェクトにおける難題の一つとしては適切な人数でチーム編成して、不空のチームが強調して動くためにはどうすれば良いのかというのが挙げれる。
メンバーの人数が増えるに従ってコミュニケーション問題やコラボレーションの難しさにぶち当たる。組織が成長する際によく発生する痛みの症状と同じ。
初めの小さい頃は疑問があれば人数が少なく近くにいることが多いのでどのように運営するかなど方針に対する容易に行えた。
これに対して、実際人数が増えたが上手くいけたのはメンバーが一つの場所で働いていたことにあるだろう。また柔軟にチーム編成を進化させた。今では５チームで行っている。
さて。
三つの開発チームは基本的によくあるスクラムチームで構成されている。職能横断型で、自己組織化していて、昨日全体と開発とテストする能力がある。
要求分析のチームは仮想的なチームでアナリストが所属していて、基本的に他のチームに所属しながらなので仮想的。
これによってプロジェクトメンバー全員が分散して配置されている。
また、この理由としてアナリストと各プロジェクトの人たちがコミュニケーションを取りやすいようになっている。
基本的に要求分析チームは３つの役割をこなすことになる。
何人かのアナリストは機能開発チームの一つに所属し、開発者からの質問に答えて要求を明確にするために、開発からチームの開発をサポートする。
何人かのアナリストはどの機能開発チームにも参加せずシステムの全体像の分析に重点を置いて取り組んでいいる。彼らはシステムの概要となる昨日エリアを定義するために、将来像を見定める。
残りのメンバーは上記の２つのうちどちらかに柔軟に横断して必要な作業を行う。
テストチームも同じように、
何人かのテスターは機能開発チームに属して機能レベつのソフトウェアテストやデバッグを手助けする。
何人かのテスターはシステムの全体像に対するテスターで、リリース候補版の概要レベルのシステムテストや結合テストの実施に力を入れている。
残りのメンバーは２つのうちどちらかに柔軟に横断して必要な作業をする。
初めはチームは担当する作業で分けて編成していた。要求分析チーム、テストチーム、機能開発チームをはっきり区別し、テスターやアナリストがいなかった。
しかし、これによってコミュニケーションの問題でスケールが上手くいかなかった。さらには担当するチームで分けてしまうとチーム間のコミュニケーションを文章で行ってしまうことが多くなった。そして問題責任の押し付け合いが始まってしまった。また、それぞれのチームは自分の仕事だけの完了だけをしようと考えがちであった。
例えば、アナリストであれば機能が本番環境にリリースするまでに行われる開発やテストに付き合わなくなったりする。これは要件定義を書き終え、自分の手から離れた時に機能に関する自分の仕事が完了したと考えてしまうからである。
コラボレーションの質は、スクラムのような職業横断型のチームに進化したことで劇的に改善した。
しかし、何でもかんでも一つのチームで行うのではなく、何人かのアナリストやテスターを機能開発チームから引き離してシステム全体を見るようにした。
三章 ミーティングについて。
当該書籍では朝10:15前までに３段階のミーティングを行う。
第一段階：機能開発のスタンドアップミーティング
自分たちが使っているtaskboardに立って今日やることや取り組むべき問題や課題について意見交換をしていく。
場合によっては昨日やったことや昨日やること、困っていることと言った3つのことを話すと言うことをしている。
第二段階：スペシャリティ同期（synchroの方）ミーティング
チームごとの話や各場所で行ったことを初めに決めたグループを超えて話し合う。
第３段階：プロジェクト同期ミーティング
これは組織をバラバラに考えて少数精鋭で行ったりする。これは全体的に長期的なスパンで俯瞰したり、フォーカスを広く持つことをひつようとする。
これらのミーティングの特徴として、ボトムアップからのアプローチであることが挙げられる。
細かいディティールから大きな対局へ見ていく。
その際には人を変え、場所を変え、問題を変えて課題を認識して解決していく。
これによって大きな問題を分割していくことができる。
また、これに関してはある固定した期間を持たせて無制限で行わない。また必要に応じてこれをなんどもイテレートする。
ex,9時ごろミーティングを15分、お昼に15分、帰り前に15分。
場合によっては柔軟に増やしていく。
四章 プロジェクトボード
プロジェクトボードとは、プロジェクトにおいてコミュニケーションの大元になるものとすべきものである。具体的にはプロジェクト全体の状況などを見せる。これは、カンバンシステムであったり、ストーリーマッピングであったり、様々な形が考えられる。
当該書籍におけるプロジェクトのカンバンを例に取ろう。
アイディア->機能->次の作るべき１０機能->開発->システムテスト->ユーザー受け入れテスト->本番
となっている。
これらはすべてフローとなっている。
何点か細かいディティール例をあげたいと思う。
ウォーターフォールとの大きな違いとしては、初めから要求を完全に分析しているかしていないかの違いである。
カンバンシステムでは全てのフェーズを並行して進める。これよってフィードバックによるアイディアを組み込みやすく、フローとして価値を作り続けているのである。
ここでもひとつ忘れるべきではない点について、緊急の課題や、ボトルネックについての処理である。
パターン的にはマーカーをつけていろんな人からフォローをもらわなくてはいけないとわかる。
しかし、これをどのように機能させればいいのか。少人数なら気にすることはないが、大人数ならばどのようにすればいいのか。
それについて次章に入ろう。
五章 カンバンボードをスケールする
一般的にプロジェクトが進むスピード大部分は、メンバーがどれくらい状況を理解しているかによって決まる。
もしも、メンバ全員が何をしていてどこにいるのか、何が起きてるのかを理解していれば同じ方向に進むことは容易であると言えるだろう。
そう。そのためのカンバンボードである。
しかしながら、人数が増えてやることも増えたら付箋だらけだったりカードだらけでとても扱いにくいものになるだろう。
そこでカンバンを分割してあげることをする。例えば開発についてであれば複数チームがいる際に、自分のところに今やるべきメインの課題などは機能開発チームが持っていることをメインのカンバンで示してあげて、議論が深くなるであろうディテールの部分は各開発チームのボードに書き込むなどをすると言ったことができる。
ここでのポイントは階層に分けることである。しかし流れスタックは溢れてしまうものなのでWIPの制御をして行うことなどをしよう。またちゃんと同期しないとあとあと大変なことになるので注意。
六章 プロジェクトゴールの管理
プロジェクトの全体のゴールを理解していると、プロジェクトメンバーはゴールに向かって集中するようになる。
それはそうという話ではあるんですが、実際に行っていくと意見の食い違い等があることがわかる。
なのでゴールへの理解のすり合わせを行う。具体的にはミーティングのプロジェクト同期ミーティングで行ったりするべき。
彼らは初めの方はなかなか難しいという評価をするかもしれない。しかしそれに対してどのようにモチベーションをあげていくのか。また、仕様書は共通認識ではないということを理解して、ストーリーマッピングをするということを行わなくてはいけない。
これらのことは定期的に行うべきである。これによって現状とゴールのチェックを行うというのは、進捗とチームの士気と意識についてを知ることである。
技術課題を捌くとバグを捌く
以下は章に合わせず必要なことを纏めて書き留めていく。
技術課題さばき
技術課題が出てくるのは仕方ない。なのでどれくらいそれにコストがかかっているかを機能の情報と別に用意して作る。要は機能カードと技術課題カードにそれぞれどれくらい労力を必要としてるか見えるようにしよう。
やるべきものにうまく乗っていくために。
例えばリファクタリング。あまりにも技術的負債が大きいと、とてもやりたくないものである。しかし、これを嫌だからと言って看過してしまうとその後技術的負債は増大していく。
この場合は、実際にこの脅威を可視化するといい。
この場合であれば実際にそのクラスファイルを印刷をかけて、どれくらいが理想のコードサイズであるかを示すべきである。
それによって僕らが行わなくてはいけない技術的負債の線引きガン見えてくるだろう。
また、リリースの前のパイロット版にはそれに対するリハーサルをコストとして見ていこう。どこまで用心することに越したことはない。
バグさばき
カンバンを使わないで捌くとテスターがバグを見つけて、開発のサイクルの終わりにバグを見つけては要求分析にプライオリティをつけて、変更管理ミーティングをしてそれに対するコストにシンクロさせていく。
が、しかしこんなのは厳しいのでしっかりとカンバンを使いたおそう。
バグを可視化する
何をやるべきでどんだけ今後やるべき仕事があるのか。あまりに多いならプロセス改善が必要だし、余裕があるならば今後のイテレーションに関する学習を行うことができる。
また、くりかえし起きてしまうバグに対してどのようにアプローチしていくか。繰り返し発生するバグのステージから引きずり下ろすために分割統治的なアプローチをかけていくべき。
例えば根本原因を見つけるために因果関係図を描くなどをすべき。
これを用いて本来やるべきモジュールなど、何が問題であるのかなど本質を捉えるのに役立たせる。
例えばこれによって、
バグの根本原因が必ずしも技術的課題だけではないということをまずはしっかりと念頭においてほしい。ここで述べてるのは自分の技術に依存しない整理して本質を得るために書いていることを再度認識しよう。
みんなもないだろうか。数学の計算をする際に急ぎすぎて字が汚くてケアレスミスをしてしまって間違ってしまったこと。これにプロジェクト開発は似ている。多くの人がそれによって手戻りで失敗してしまう。
プロダクト（方針や開発を進めること）の中で生まれたバグというのはプロセスのバグから生まれる症状である。じゃあプロセスってどうすればもっとより良くしていけるのかを考えていこう。
継続的プロセス改善とバージョン管理
プロセスをデザインするというのはとても難しい。何故ならばプロセスというのはスケーラビティを求められるプロジェクトに包まれるものである。つまり、プロセスもスケールして変化を求められる。
そこでプロセス改善エンジンを導入していく。要は機械学習と同じで評価関数を決めてそれに対して定常偏差を合わせていくといったイメージである。下に一般化して示す。
この三つである。これを行なっていくことで自己組織化を目指していく。
さて、これを行うに当たってチームの振り返りなどは必須である。
良くある振り返りの方法として、他者を呼んで、外部的視点を見てもらうことをしてもらうこと。他にも色々方法はある。
さて、それを通じて良くある改善内容としては
これらの振り返りのキーとして、エスカレーションポイントを用意することである。エスカレーションポイントとはチームを超えて影響を与えたる、一緒に解決したりする。たとえ他のことをしているとしても、お互いにプロセスの改善を行うことで視点が養われてシナジー効果が期待できる。
プロセス改善ワークショップ
振り返りの手引きをざっくり示したい。
これを開く意義は、仕事のベクトルを明確に、そして改善することである
当該書籍ではスクラムオブスクラムで示されているが、ここで話される取り組みというのは他にも適用可能だと考える。
以下に示す。
ワークショップではみんながさっさと話せるように心がけるべきである。今思っていることをサッサといってみようと投げるぐらいの勢いで手早くしていくのがいいだろう。
しかしながら目標を見失っていくのではダメで、期待すべき事柄をしっかりと示していくことが大切。
これは運用次第であるが、リーン主義で居続けるなら漠然としたことを許さない可能性もあるが、クリエイティブな、カンバンといったことであるならばブレインストーミングや直感で決めるというのも大切である。ただしいつかは抽象から具体に変えなくてはいけないのを念頭におくべき。
早すぎても難しい
当該書籍では興味深いことを述べている。
以前は変化が少ないことが問題であった。今回は変化が多すぎることが問題だった。
ほどほどというのが必要だと感じる話だ。
こういう時はプロセス改善提案書を書いて一手間加えるワンクッションを入れてもらうことにしている。
理由は提案者に対して簡単に出しすぎないようにする枷であり、何故こうしたいのかということの再認識をすることができるからである。
迷ったらシンプルな解決策を選ぼう。
因果関係図
根本原因分析を行うのに有用な方法である。
なんでこれが必要かというと、適当に解決するとまた浮き彫りになlって厳しいことになるからである。
具体例を挙げると
* 寝室に煙が充満してる
* 窓を開けて、また寝る（ダメな例）
* 煙の発生源を見つける。おっと危うく火事になるとこだったぜ（良い例）
といった話である。
A3シンキング
リーンシンキングの中核にある教えの一つとして、継続的なプロセス改善を表す「カイゼン」という言葉がある。
トヨタ曰くこの正しい問題解決手法を厳格に運用にしたからであると表現している。これをA3の用紙に描くのでA3シンキングという。
A3シンキングのサンプルやテンプレートはネットにあるので要参照
テンプレートリンク
因果関係図の使い方
基本的な流れはこう。
問題を選んで書き出す。
明らかな損害やそれの弊害を上向き（トップダウン）に突き止めていく
- つまりこの書き出した問題が理由として扱えるように描く
- 問題：リリースした奴がバグって死んでる
突き止め：リリースした奴がバグって死んでるー＞客がキレる
根本原因を下向き（ボトムアップ）に見つけていく。
- テスト不足
描く時間が不足してたなどが上の例には当てはめれる
図に現れた循環（基本的に悪循環）を特定して目立つように描く
図を洗練するために上記をイテレートする。
根本をどう解決するか（ミーティングに持ち込んだりする）
これを行なっていく。
もし今回の場合はテスト自動化のトレーニングとかが足りないとかそういうとこに帰着するであろう。
因果関係図の書き方
ぼっちなら線画ツール好きなの使って頑張ってくれ。
複数人8人以下ならホワイトボードや付箋と模造紙で書いて作ろう。
30人以下とかの大規模なら人数を分けて具体的な問題の一つに着目して纏めたりしておく。最後に持ち寄って纏めたりする
定期的にこれをちゃんと認識できるシステム組み込みが必要だったりするのでそこはアナログツールに頼ったりしていくべき。
よくある失敗
幅優先ではなく、深さ優先探索で見ていこう。
問題領域が広すぎる場合がある。分割可能な問題になのではないのかということを見極めよう。
簡略化しすぎない。専門用語ではなくできるだけ一般化した言葉で話すべきである。
具体例に頼ったり、専門用語に頼るのは説明ではない。一般化してる表現で説明してこそ本当の説明なのだ。
いらないのが出てくるけどそこは問題ではなく、根本に辿れるかが問題。あくまでブレインストーミングのような形でも問題はない。
個人攻撃をしないように気をつける。しばしば誰かが足を引っ張ってることがるだろう。しかしそれはチームで解決すべき問題だ。出来ないならばそれを解決するプロセスが工数なだけなのだ。そもそとして問題解決ができるのはそのシステムに要因があると仮定できた時のみなのだ。
なぜ因果関係図を使うのか
なぜやるかを意識して問題解決に当たろう。
終章 まとめ
なんでこんなのを纏めたかというと、学生が情報技術を学ぶというの通じて楽しいというのを続けたいならば、それを業務にうまくたたみこむ必要が有るんだぜということが最近よくわかってきたからというのが大きい。
結局最近思うのは実用技術＞＞＞大局的な開発手法ということがやればやるほど僕らは痛感するだろうと思う。現に本質的ではないgitがわからなくて右往左往してみたりまだまだ辛いものはある。精進したいものである。
間違えがあったらそっと教えてください。
参考文献
一問目はwhoisするだけだったのですが....（なぜかここで自分たちのコマンドから通らずこける）
ちょっと時間をかけてしまいましたw
その後出て来た管理者のメアドからSNSを漁り、見つけていくってことを行いました.ですが3つ目終わった地点で時間切れ.悲しい.さんまでGOってなんだよ...
ちょっと雰囲気をつかめばワンチャンありそうだったので来年もやりたいと強く思いました.
という
