アジャイルジャパン仙台に参加して①

◇Keynote 1：「"Demand Technical Excellence" アジャイルにおける技術と品質の重要性」

James Grenning 氏

「アジャイルと品質」は気になっている問題だったので、 是非聞いてみたいと思っていた。 Jamesさんは「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶア>ジャイルな設計」の著者。


導入

アジャイル宣言から10年後。 Snowbirdに集まって、Debriefingを行った。 そこで話したことで記憶に残っているのは2つのこと。

Technical Excellence
Promote Individual [change]

まず、アジャイルな開発者に必要なのは『技術的卓越性(Technical Excellence)』ということ。 アジャイル開発の本だと暗黙の前提としてあまり書かれていないが、きちんと言ってくれて嬉しかった。


焼きなまし

アジャイルで一番重要なものはShippableコードということ。 近頃だとHardening Sprints(焼きなまし)と呼ばれるバグ出しのスプリントを入れることがある。 しかし時間通りには終わらずに燃える。 そもそもバグをなくすことが重要。 バグを追っかけることは技術的卓越性ではない！

最後にバグ出しの期間を取るわけだね。 個人的なイメージだと、全てのフィーチャーが出揃った後にシステムテスト、シナリオテストを実施するのがいいと思うけど、ここでデグレが出すぎると炎上するんだろうなぁと思った。

スクラムとXPの結婚

技術を高めるということは、バグを出さないこと。 スクラム、アジャイルで技術的な変化をしましたか？？ この問題を解決するために"スクラムとXPの結婚"を提案したいとのこと。

開発者に質問してみたところ、コーディング、デバッギング、テスティングのうち、ある人は90％をデバッグとテストに使っている。 デバッギング、テスティングは顧客にとっての価値を生み出さない。価値を出すのは新しい機能を実装すること。 printf、ステップ実行は1979年の技術今日でも見かけは変わってますが、同じ技術である。

おめでとう！！

これは"Debug Later Programming"じゃないか？

90%をデバッグに使っているのは厳しいなぁと思うが、大きな製品になるとこれくらいになるかも。


バグを入れて、しばらく後で見つかる。どのくらいで見つかるか分からない。バグ修正がバグを呼び出す。

バグはどこから来るの？？ 自分で入れたんでしょ？（Its our fault!)

テストを最後まで待つと最後に発見される。 日本は品質を作りこむということを知っている。 BigWaterFallではバグを管理し始める。

XPはエンジニアリングの技術的なプラクティスの集合 信頼性の高いソフトウェアが欲しいなら、最初からバグを作りこまないようにする。 TDDはダイクストラの方法を具体化したものだ。開発の流れを変えて、テストと開発を平行に行うようにする。これによって、開発とテストは欠>陥予防の連続体となる。 3分前のバグは簡単に見つけることができる。

バグの生存期間の話をしていたが、これは明らかに短いほうが良いと思っている。仕様書の場合はレビューで出したり、コードの場合はテストコードで出すのが短くする方法のひとつだと思う。 テストを先に書くという概念は今は普通だけども、改めてすごいなぁと思った。これだとコードレベルのバグの生存期間は限りなく0になるもんなぁ。。。


開発とテストの比重

UnitTestは絶対に必要である。 システムテストでは全てのパターンを試すことはできない。 システムは変更されることを嫌がる。 25%のバグが、変更箇所以外の別のところが壊れたものという結果もある。

テストと開発の努力の比率は1:1のように思いがちだが、実際の比率は開発が進むにつれ、テストに比重を置かざるを得ない。2回目のスプリント>のテストは回帰試験も必要になってくるからである。このギャップが、このリスクがプロジェクトが炎上する理由になっている。

確かに・・・納得。 ソフトウェアは共通化できるがゆえに思ってもいないところに影響がでることがあるんだよなぁ。 アジャイルな開発だと回帰試験はどうなんだろうと思っていたのでJamesさんの話を聞いてスッキリした。


テスト書かない暇は無いんじゃないの？

テストを書く暇は無いっていうけど、バグを追いかける時間はあるでしょ？テスト書かない暇は無いんじゃないの？ 他のプログラマーが理解できるコードを書くのがスキルになる。

スパゲッティなコードではソフトウェアの価値がなくなる。ソフトウェア大切な価値の一つは「変えられること」

自分はソフトウェアの価値は変更容易性にあると思う。ただそれゆえに壊れやすいという特性も併せ持っている。 日本はH/Wの品質管理を導入して、弱点を克服しようとしたがこれだと遅くなることが多い。1行の変更に1週間とかはザラだ。そうではなく、顧客の要求にギリギリまで対応できるというほうにフォーカスを当てていくべきなんだろうと思った。


アドバイス

Jamesさんからのアドバイス。

  • ものずくりのプロになれ(Become and expoert in your craft)
  • 透明性を高めて信頼を築け(Build trust make your work visible)
  • 新しい事に挑戦せよ(learn and try new things)
  • 組織のアドバイザーになれ(become advisor)

    マネージャーがモチベーションをさげるのは簡単で、絶対できない締め切りの設定、事実のみを責めたり、品質の低い仕事をさせる。

マネージャーのモチベーションを下げる方法は本当にあるあるで、もう黙って頷くしかなかった（笑


守備範囲を増やす

人は自分が知っている範囲で最善を行うので、チームのみんなが最新のプラクティスの知識を持っているようにする必要がある。そして自分の組織がその重要さを知っているようにする必要がある。

問題解決をするのであって、スクラムをすることが重要なのではない。スクラムマスターはモチベーションを下げるものを取り除いていく必要がある。チームに学ぶ活動を入れる。悪いものは積極的に見せて、チームで解決する。

知っている範囲で最善を尽くすっていうのはそうだよね。だから常に学んでいかないといけないわけだし、引き出しは多くないといけない。 また問題解決もその通りで、自分の仕事はソフトウェアを作ることではなく、問題解決することが仕事だと思うようにしている。


平鍋さん 「日本だからこそ品質を作りこむっていうのが重要」


自分の感想

いままでの本などでは聞けなかったアジャイル開発と品質についての話はめっちゃ面白かった。 テスト、品質について勉強しているというのもあるけど、アジャイルでずっと気になっていたことが少しクリアになった。 昨年は倉貫さんの話でアジャイルとお金の話がクリアになって、今年はアジャイルと品質の話がクリアになってちょっと嬉しい。

合わせてこれも読んでみたらめちゃ面白かった。 組み込みアジャイルコーチ James Grenning さん突撃インタビュー

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview1/

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview2/

五輪書（現代語訳） 宮本武蔵 読了

五輪書（現代語訳） 宮本武蔵

マンガのバガボンドから影響を受けて、宮本武蔵の五輪書を読んでみた。

約400年前の大剣豪の話だけれども、ビジネスやソフトウェアでも使えるようなことが書かれていて、かなり面白い。

特に勝つためにはどうするか、ということが散りばめられている。

自分が近頃気になっている世界No.1ゲーマーの梅原大吾さんと同じようなことを言っていて興味深い。是非、2冊を読み比べてみて欲しい！！


【地の巻】

二天一流という武蔵の兵法の概略が記されている。

武士にあっては、さまざまな武器・武具をつくり、その利点や用法をよくわきまえていることこそ武士の道というものであろう。武器の用法を習得せず、それぞの武器の利点をもしらないというのは、武士としては少々嗜みの浅いことではないか？

例えば言語、ライブラリを知り、それらの特徴を考え用法を取得してこそソフトウェアエンジニアと言えるんだろうなぁ。特に手持ちの小さな知識だけで戦わないように気をつけねば！

兵法の拍子にもさまざまあるものである。

・合う拍子･･･相手の呼吸に合う拍子

・違う拍子･･･相手の呼吸を外す拍子

・当る拍子･･･適した拍子

・間の拍子･･･間を取る拍子

・背く拍子･･･相手の拍子を崩す拍子

これは攻めたりするときのタイミングなんだろうなぁ。

相手の拍子を知り、敵の予想もしない拍子をぶつけることで勝つということ。


【水の巻】

心の持ちようが記されている。

この書に書き付けたことを、自分自身のこととして、ただ書付を見るとか、習うとか思わず、物真似をするというのではなく、すなわち自身の心の中から見出した道理とするよう、常にその身になってよくよく工夫しなければならない。

これは腹に落ちるまで自分で考えてやってみるを繰り返さなければいけないってことだと思う。知識からの実践を通して自分の中でフィードバックを繰り返す必要がある。

目の付けようは、観・見二つの目の付け方があり、観の目（大局を見る目）を強く、見の目（細部を見る目）を弱くして、遠いところを近くに見、近いところを遠くに見ることが兵法では最も大切なことである。

モノツクリはもちろん、レビューでも使えるこの考え方。

観の目をもって、大局を見失わないようにしていく必要がありそう。


【火の巻】

戦いのことが記されている。

敵になるということ。「敵になる」というのは、自分が敵になり替わって考えよ、ということである。

これは相手の立場になって、相手の呼吸を読めということ。

ソフトウェアを作成するときもユーザーの立場になることがあるが、競合会社がどのように考えているのかも考える必要がありそうだ。敵の立場になってみるというのはなかなかできないよなぁ。。。


【風の巻】

他の流派のことが記されている。

長い太刀を好む流派をバッサリと切っている。

場所、状況によって使うもの、効果的なものが違うということ。

目標は勝つことであって、長い太刀を使うことではない。

わけもなく長い太刀を嫌うのではない。長い太刀に偏執する心を嫌うのである。


【空の巻】

二天一流の兵法の道に入ることが記されている。

難しくて全体を理解できないが以下の文言はジンワリときた。

有るということを知って、無いということを知るということ、これがすなわち空である。

DDP（Defect Detection Percentage）を考えてみた

JaSST'13Tokyoに行ってきた。

レポートはおいおい書くとして、基調講演のGrahamさんが言っていたDDPという指標について考えてみる。

http://gihyo.jp/news/report/2013/01/3101

 

【DDPの定義】

DDP＝（テスト中に見つかった欠陥数）／（テスト中～リリース後に見つかったすべての欠陥数）のパーセンテージ

 

テスティングの価値を測る指標ということで、以下の前提を置いて具体的に見てみる。

【設定条件】

良いソフト（内在バグ20件）
悪いソフト（内在バグ100件）

良いテスト（内在バグの8割検出）
悪いテスト（内在バグの2割検出）

市場で使う人が多い（残存バグの全てを検出）
市場で使う人が少ない（残存バグの20%を検出）

 

Excelで計算してみると、こんなになった。

社内で発見されるバグの数だけで見ているとソフトウェアの作りが入ってくるため、テストの良し悪しが分からない。以下の黄色の箇所は件数で見ると同じ16件。

f:id:nemorine:20130220180542p:plain

 

でもそこをDDPで見るとソフトウェアの作りによらず、良いテストは80%、悪いテストは20%。なるほど！テスティングの価値を測る指標だ。

f:id:nemorine:20130220180601p:plain

 

ただ気をつけないといけないのは、市場での不具合の検出率。

ユーザーがたくさんいる場合はいいが、少ない場合はDDPに差異が生じる。

この場合は期間を長めにとって調整するしかないだろうなぁ。

f:id:nemorine:20130220180551p:plain

 

自分の中の結論。

「DDPはソフトウェアの作りの良し・悪しを取り除くことができる指標である。ただし市場ユーザーの数を考慮して、期間を設定する必要がある。」

他にも小さなプロダクトだとバグの件数が少ないため、たまたま市場バグが多いとDDPの値の変化が大きくなるとかはGrahamさんも言っていたなぁ。

後、個人的に気になっているのはフィードバックが遅くなりそうなこと。もう少し他の指標と組み合わせていくといいと思う。

簡単な計算だけど、自分で考えてみるって重要だと思ったToday！

「プロゲーマー 梅原大悟の勝ち続ける意志力」読了

Chikirinさんのブログを読んで、気になったのでAmazonで購入。
YouTubeにもあがっている「背水の逆転劇」。


背水の逆転劇

ストリートファイターを知らない人には何だかわからないと思うがマジで神業。
しかも体力ゲージが1ドット、一撃で死ぬというときの落ち着きと集中力。
ストリートファイターⅡは自分も死ぬほどやったゲームなので、梅原さんの凄さが良くわかる。。。


梅原さんはタイトルにもあるように勝ち続けることにこだわっているプロのゲーマー。
同じ格闘ゲームではなく、様々な格闘ゲームでタイトルを取っている。
梅原さん曰く、「勝つこと」と、「勝ち続けること」ということは全く別であると。
勝ち続けるためには常に変化が必要であると。

この本が面白いのはただのゲームが好きな人の話ではなく、人間やビジネスの本質を突いた本だということ。
他のビジネス書にありがちな、成功の部分だけに特化していないために、苦悩の部分もリアルに伝わってくる。
読み物としても面白いし、ビジネス書としてもすばらしいと思う。

 

ソフトウェア開発にも通じるものがあり、そのひとつであるアジャイル開発に通じるものがあると感じた。小さく失敗し、洞察を行い、また次につなげていく。
そして重要なのは、「戦略」ではなく「戦略を生み出し続けることができる力」にあると言っている。
スポーツ、株、勉強、ソフトウェア開発と様々なことに示唆を与えてくれる本だと思う。


以下、ズギュンと来た言葉。

「そもそも勝負の本質は、その人の好みやスタイルとは関係のないところにある。」

 

「自分を高めるということは、自分の引き出しを一杯にすることではない。より新しく、かつ良いものを生み出し続ける姿勢こそが遥かに大事なことではないだろうか？」

 

「失敗ばかりを恐れ、何もしないというのが一番いけない」

 

「自分を痛めつけることと、努力をすることは全然違う」

 

「結果に固執しないと結果が伴う」

 

「頂点を極めた人間は高みで構えて、挑戦者を受け止めなければいけない」

 

「若いうちから失敗癖をつけておけばトライ＆エラーが当たり前の習慣になる。失敗に強くなる。」

 

勝ち続ける意志力 (小学館101新書)

勝ち続ける意志力 (小学館101新書)

 

セキュリティテストについて考えてみた

先日CTF（Capture The Flag）という大会の地方予選に参加してきた。

http://ctf-challenge.jp/

ある環境に侵入してその中にあるフラグ（ファイル）を取るという大会。
攻撃する側の思考、手順を学ぶことで防御するときの手助けにするというもの。

さて、二日がかりの勉強会＋大会。これがなかなかハードだった。。。

一日目は基礎の講習。しかしセキュリティに関しての知識が足りないため、初めてのことが多い。
  ・セキュリティーホールの狙い方、防御の方法
  ・パスワードのクラックの仕方、防御の仕方
  ・SQLインジェクションの方法、防御の方法など実習を踏まえながら進めていく。
いやー 勉強になります。m(_ _)m
KAKAKU.comのSQLインジェクションなんかは結構有名だよね。

 

二日目は実際の大会。ヒント無しでどんどんフラグを取っていく。
パッと取れるところもあれば、なかなか取れないところもある。
これは大変だ。。。。
結果は4本あるフラグのうち1つしか取得できずに、下から2番目（くらい）。
次回参加する機会があれば、もう少し上を狙ってみたいなぁ。

 

ということで、終わってからセキュリティに関して考えてみた。

まずはJSTQBの確認。
******************************************************************
機能テストの一種であるセキュリティテストでは、
ウイルスなど、外部からの悪意ある脅威を検知する機能をチェックする。
                                              by JSTQB FL Syllabus
******************************************************************

悪意ある脅威を検知する機能をチェックするとあるが、「検知」だけではないと思う。
検知する機能とともに、侵入できない機能というのも重要だ。


******************************************************************
セキュリティツール
これらのツールは、ソフトウェアのセキュリティ特性を評価するために用いられる。
これは、データの機密性、完全性、認証、権限、可用性、否認防止といった、
データを保護するためのソフトウェアの能力を評価することを含む。
セキュリティツールの多くは、特定の技術やプラットフォーム、目的に焦点をあてている。
                                              by JSTQB FL Syllabus
******************************************************************

こっちは機密性や認証などちょっと書いてある。


自分が思ったのは一般的な機能テストとセキュリティテストは質が違うということ。
「検索の文字が間違って、検索データが表示されなかった」
「検索の文字列を変更し、全てのユーザーデータを持ち出し悪用する」

うーん やっぱり下の方が防ぐのは大変そう。
セキュリティーホールの情報、攻撃方法が日々更新されている以上、
最新の環境、最新の情報を元にテストを実施する必要がある。

OS周りなどは最新のパッチを当てたり、特定の設定を無効にしたり、ある程度確立された手法があるようだが、
アプリ側のセキュリティをテストする場合は経験ベースの探索的テストに近いテストになるようである。
実際のコストはどれくらいかと質問したところ20ページ程度のWebサイトで200万くらいらしい。。。

******************************************************************
探索的テストは、テストの目的が含まれたテストチャータを基にしたもので、
テスト設計、テスト実行、テスト記録や学習を並行して同じ時間枠内で実行する。
このアプローチは、仕様がほとんどなかったり、不十分であったり、
スケジュール的な余裕がない場合や、他の形式的なテスト技法を補完する場合に効果が大きい。
探索的テストは、テストプロセスのチェックや、きわめて重大な欠陥を見つけ出すのに役に立つ。
                                              by JSTQB FL Syllabus
******************************************************************


何はともあれ、初めてのハッキング体験とセキュリティテストについて考えるきっかけを与えてくれたCTFJapanには感謝したい。

 

（参考サイト）
IPAセキュア・プログラミング講座
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/web.html

Webアプリにおける11の脆弱性の常識と対策 - @IT
http://www.atmarkit.co.jp/fjava/rensai4/webjousiki11/webjousiki11_1.html

JaSST東海 参加報告No.3

そしてついに出番です！

 

テスト界で有名になりつつある北の塾長ことおぐちゃんのSIGセッション。

お題は「要求仕様書のレビューにはどんな視点が大事？」。

ここ名古屋はUSDMを実践で使っている地域としても有名なところ。

北海道美人のおぐちゃん×要求仕様のレビューは早々に定員を超えた。

本当にありがとうございます m(_ _)m

 

まずはおぐちゃんと自分の自己紹介から本日のルール。

ついで本日のルール。このルールに度肝を抜かれる参加者達。

ルールが気になる人は是非次回のおぐちゃんのSIGに（笑

 

1. レビューで何を見つけている？

アイスブレイク的に参加者それぞれの要求仕様書のレビューについて普段のやり方、または悩みなどを報告。参加者は船、カーナビ、カラオケ、エンジンなど色々な業界の人で、なんか話しを聞いているだけでも楽しくなってくる。

 

要求仕様書で気にしているものは業界によって違うのでかなり面白かった！

メモしたものを少し書いてみる。

・コピー元との差分

・やらないこと

・予算内であること

・シンプルであること

・使いやすいこと

・法律・規格に沿っていること

・伝わること

・テスト可能であること

・理解可能であること

 

個人的にはユーザビリティなどが前面に出てくるのかなと思っていたが、本当に業界によって、また役割によって違うんだなぁと実感した。

参加者でディスカッションしているときに、誰向けの？というのを意識する必要があるねという話になった。

 

2. 記述範囲を分ってる？

今回はTEF道で定義した要望、要求、要件、仕様の定義を使い、参加者の皆で考えていった。

話しは自然とUSDMのメリット/デメリットに。

理由の書き方は皆が苦労してそうだった。

自分も以前は凄い悩んだ結果、今は問題領域(=困っていること)を書くようにしている。厳密にいうとシステム要求より後を扱う本来のUSDMに沿ってはいないと思うのだが、個人的には本当に問題を解決するソフトウェアになっているか確認するときにかなり役に立っていると感じている。

 

他にも範囲が規定されているので、漏れが少ないという実感があるなど実経験を元にいい話を沢山できた。

 

3. 目的・観点をもってレビューしている？

ここで出したスライドは基調講演の湯本さんのスライドとそっくり！

今回のJaSST東海のテーマともあっていて、上手く繋がっている気がした。

 

ここでワイルドレビューの説明！

　「目的、観点を持たずにレビューをすることをワイルドレビューという」

これはJaSST北海道のワークショップで作った造語だが、なかなかに気に入っている（笑

 

TEF道のワークショップで使った資料を見せながら、観点の例としてちょっと説明。

・利用時の品質(ISO-9126の一部)

・外部および内部品質(ISO-9126の一部)

・要求仕様書が満足すべき性質の例(IEEE830-1998)

 

TEF道の色々な活動が輪のように繋がっているのを感じた。いい事だ。

 

4. 気づいたこと

2時間近く皆でワイワイ話して、最後に今回のSIGで気づいたことをお話ししてもらった。

これも色々あって面白かったので、メモしたものを少し書いてみる。

・困っていることが多い。共有する。視点を持つ。

・立場を考える。

・仕様が構造化されているということは強力なメリットである。

・観点、目的をもつ。

・USDMを勉強してみたい！

・指摘する人が満足するように仕様にわざと穴をあける。（←ほぼ裏技ｗ）

・要求仕様書に上位向けの視点が多かった。

 

 

SIGはJaSST東海の目玉企画と聞いていたが、実際に参加して確かにそうだと感じた。

どうしても受身になりがちなシンポジウムであるが、アウトプットする場があるというのは参加者にとっても有益だと思う。

ただし、運営は部屋の調整、人数調整などかなり大変そうだった。

自分達のSIGのオーナーは二人だったが、これは進め方などを考えるとかなり良かった。

ひとりだと微妙な間ができそうだが、二人いることでお互いにカバーできると感じた。

 

お世話になった皆さん、本当にありがとうございました！！

名古屋に負けないように頑張ります！！

 

＃JaSST'12 Tokaiに参加した人のブログを以下にまとめてみました。

あきやまさん：JaSST '12 東海参加してきました。

ヤマモトさん：ヤマモトの日記 

ボンツトさん：なんでもアウトプットしてみる日記

なかひでさん：テストに関していろいろ感じてきた 

いずみさん：きっと何者にもなれない自分自身に告げる 

 

JaSST東海 参加報告No.2

◇【テスト１年生シリーズ】はじめてのテスト技法～テスト技法でバグ退治～

チュートリアル （なのっち/森さん)

 

なのっちと森さんによる初心者向けのチュートリアル。

受講でも良かったのだが、今回は特別にスタッフとして参加させてもらい技法の講習を見せてもらった。

 

おっと！良いテストの条件。これ大事！

「漏れなし！無駄なし！バグ発見！」

語呂で覚えるソフトウェアテストとのこと。なるほどっ！！

 

最初のお題はWindowsアプリであるMayersの三角形判定アプリ。

 

まずはどういう形でもいいのでテストケースを書くという演習。

参加者の後ろからこっそりと覗くと色々なテストを書いていた。

どうしても判定ロジックに行きがちだけど、三角形が表示されることとか、画面が閉じることとか書いている人もちらほら。

おー すごい。自分だったら三角形の判定に執着しちゃいそう・・・

 

ここから技法の解説。秋山さんのテスト技法のポジションマップで解説。

と思いきや、変な形の人の絵が！？なんだこりゃ？！カメハメ・・・？

なんと！ド○ゴンボールの技のポジションマップが！！！！！（大マジ）

しかも格闘系だけにピンポイント系が多いとかマジで面白過ぎ。。

いやー 名古屋凄いわ。。。

 

ここでなのっちから森さんにタッチ。

テスト技法の説明入って、同値分割・境界値分析の説明。

仙台でも実施しているので参考にさせてもらおっとm(_ _)m

と思ったら早速分からないことが！！

 

「境界値分析の取り方には2値と3値の取り方があります」とのこと。

おーーー 知らなかったゾと思いつつ、考えてみる。

演習の合間を縫って森さんに聞いてみたり。。。

うーん・・・ なんかいまいち腑に落ちない。

ということで、後日の宿題。ここは秋山さんにTwitterで沢山アドバイスを貰う。

onとoffの考え方を完全に間違っていた。本当にありがとうございます！

同値分割・境界値分析の2値の選択と3値の選択

 

続きましてはホワイトボックステストのカバレッジの話し。

命令網羅、判定網羅、条件網羅の説明をしていた。

これってなんか分りにくいんだよね。。。

判定網羅と条件網羅って文字だけだと違いが分らない。

JSTQBのALの方に少し詳しく載ってますね。FLは・・・分りにくいorz。

個人的にはkz_suzukiさんのまとめが分りやすいと思う。

Coverageに関する言葉の整理

 

あーでもない、こーでもないと2値と3値のことを考えていたらチュートリアルは状態遷移へ。

さすがにマリオの状態遷移では無かったか・・・

 

それにしてもなのっちも森さんも説明が上手いなぁ。

沢山の本、沢山の経験に裏打ちされている雰囲気がたっぷり。

自分も頑張らなくちゃだね。

 

参加していた人が皆満足そうな顔をしていたのが印象的だった。

 

No.3へ続く。