JaSST'14北海道レポート①

早速、JaSST'14北海道のレポート①を書いてみた。

和田さんの基調講演

目指すものは「動作するきれいなコード」 by ロン・ジェフリーズ
これはTDDを実施している開発者もテストエンジニアも同じ思い。

テスト駆動開発とは？

和田さんによるテスト駆動開発の説明があった。
今回はTDDを全く知らない人も参加者にいるので、かなり丁寧な説明をしてくれたと感じた。

• コードを書かないとわからないことが多い
• 綺麗な設計をしてから！ではなく、動かしてからきれいにする
• 重要なのはテストがある状態でのリファクタリング。

FizzBuzz問題のデモ

実際にFizzBuzz問題をt_wadaさんがデモしながら、TDDの話をしてくれた。

• 仕様をToDoリストに変更する。→ 個人的にはポイントだと思う。
• テストクラスの名前にはTestxxx と xxxTestの2流派ある
• 日本語でテストのメソッド名を書く → 日本で開発している場合はかなり有用
• 初めての場合はテストコードはゴールから考えていく
• テストコードのテストは実装コード。お互いにテストしあう関係
• 実際にテストで値を入れることで気づくことがある
• 二つ目のデータが正しいコードを導く（三角測量）

三重ループ

Why 頻繁なリリースとデモ
What アクセプタンステスト
How ユニットテスト

TDDの導入効果

MSやIBMの論文の事例の紹介。

• TDDで欠陥は６割〜７割減る
• 実装時間は２割~３割増える

テスト駆動開発を導入することで、プログラミングレベルの
軽微なバグっていうのは無くなる。
TDDを実施した後で出るバグは本質的なバグ。それに対処する。

ユニットテスト自動化してれば品質大丈夫！っていう人が多いので、和田さんにズバっと言ってもらって嬉しいなぁ〜

テストは品質を上げない

体重計を買っただけでは痩せないように、
テストでは品質を上げることはできないので、
品質を上げるためにはコードを修正する必要がある。
テストはあくまでもキッカケに過ぎない。

これは…身をもって体験してるｗ
体重計に乗ってるだけじゃ全く減らないorz

改善を我慢しなくても良い

以前は動いてるコードは触らないということで品質を保っていた。  
今は自動テストがあるので改善（リファクタリング）を我慢しなくてもいい。  
対象のソフトウェアの動作が変わったら、テストが教えてくれる。

やっぱり「動作しているコードを触らない』という方針だけだと機能追加には耐えられないだろうなぁ。常にDRYを意識しながらコードを書いていきたい。。。

開発とテストの人はもっと一緒になろう

TDDだけやっていれば品質があがるかというとそうではない。  
やはり第三者の視点というのが必ず必要になる。  
開発の人とテストの人が一緒にやることでもっと良いものを作ることができる。

本来、開発者とテストエンジニアは共通の目標があるはずなのに、いがみ合っていることが多い。でもそんなんじゃいいもの作れないよね。

感想

今回のJaSST北海道は基調講演に和田さんをお呼びしたことで、開発者からみた品質、テストの話を聞くことができた。JaSST東北でも関さんに来ていただいたので、JaSST東北〜JaSST北海道は開発者視点のテストという流れが繋がった感があってちょっと嬉しい。
和田さんの最後のメッセージにもあるように、開発者はテストの方へ、テストエンジニアは開発者に近づいていく必要があると思う。そしてお互いが交流することで知識の移転が行われるんだろうなぁ。
TDDだけで品質を担保することはできないし、テストだけで品質を上げることはできないから。

『牛タンとビールとアジャイルとプログラマの幸せ』

昨日はソニックガーデンの倉貫さんをお招きしての、『牛タンとビールとアジャイルとプログラマの幸せ』のイベントでした。

会場は楽天さんです♪
利休の牛タンを買ってきて全員で乾杯から始まる勉強会。これめっちゃいいわ。

倉貫さんの話はいつも刺激的だし、生き方自体がカッコイイなぁと思います。今回も凄いなぁと思ったことは沢山あったけど、自分の心に残ったことを書き留めておきます。

これから生き残る仕事は
０から１を作る仕事
 もしくは
何かの問題を解決をする仕事

日本は人口が減少していくので、頭数の勝負は新興国に分があるということも言ってて、それは本当にそうだと思う。

プロフェッショナルとは…
毎日自分のスキルを研ぐこと
前の日のコードよりカッコイイコードを書くのがプロフェッショナル

常に意識してないとダメだと思う。
毎日コード書かないとダメだ！！ ダメだ！！

信頼とは貯金のようなもの。積み重ねである。
毎週キチンと成果を届けると信頼はドンドン溜まっていく。
みんなは飲み会に頼り過ぎ（笑

確かにSkypeで毎週顔を会わせて話をして、毎週確実に成果を届けるのがやはり本質なんだろうな〜 継続的に価値を提供するというのが遠回りのようで、一番の近道だと思う。 ２次会でこっそり話してもらった『コードで女を泣かせるエンジニア』の話なんてまさにそれ！！

アジャイルとは結果である

自分がどうしても聞いてみたかったアジャイルとは何ですか？という質問に対しての倉貫さんの答え。ソニックガーデンとしてはアジャイルを特別意識していることはないけど、顧客の満足のためにを追求していったら、結果としてアジャイルになっていたとのこと。この話に付随して倉貫さんとアジャイルの出会い〜ソニックガーデンの立ち上げの苦悩の話もめっちゃ面白かった！！

ソニックガーデンでのレビューは二つ
・コードレビュー
・ワークレビュー

ワークレビューは師匠が弟子のKPTに対して行うレビューとのことです。KPTをレビューするというやり方は自分も新人教育のときに何回か実施したことあったが結構難しかった記憶がある。
早く本にならないかな〜とwktk。
http://kuranuki.sonicgarden.jp/2013/10/%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC.html
他人に指摘されずとも、息をするようにふりかえりを行うのが師匠とのこと。

3年後を見据えてソフトウェアを作ってはいけない

これは参加者からの「エンジニアが３年後を見据えたコードを書いた場合はどうしますか？」という質問の回答。自分も賛成でやっぱり未来を完全に見通すことはできないので、今の時点のベストがいいんだろうな〜って思う。

ER図みたいなものは書くが、モデル自体は書かない。

モデルは一体どうなんだろう？って思ってたので質問してみた。ほとんどはコードで担保しているということ。モデル自体の妥当性とかは見ていない。ただ関連の間違いなどは動作させれば分かると言っていた。

あるスレッシュホールドを超えると、バグが頻発するので、
そこまで行かないようにコードをコントロールする

これは本当にそうだよなぁ・・・
テストだけを見てるとなかなかコードの方に頭が行かないことがあるけど、コードをしっかり書くことで不要になるテストもあるんだろうな〜 デグレもありませんって言ってたし（笑

ソニックガーデンのコードレビューの原則はDRYであること

やっぱり『動作しているところは触らないで品質を保つ』という方針は、その瞬間はいいかもしれないけど継続的ではないんだろうな〜。そういう方針の場合は、コピーコードが増えていき、メンテナンスがキツくなり、テストも条件が増えていく。。。

会社の拡大と社員の幸せを天秤にかけるともちろん社員の幸せを取る

これ本当に実践しているのが凄いな〜
ここまで知行一致している人ってなかなかいないな〜って思う。

倉貫さん、本当にどうもありがとうございました！
また仙台で牛タン用意してお待ちしております♪　

ぐるぐるDDD/Scrum復習編

ぐるぐるDDD/Scrum復習編に参加してきた。 講師は原田騎郎さん。めちゃめちゃ面白い人です。

チームビルディング

知識があってもプロジェクトが止まらないということを身をもって体験するプチ演習。
中身は言えないけど、これはスゴい！！
全てのマネージャにやってもらいたいプチ演習ｗ

ぐるぐるDDD

お題は勉強会の支援システム。
最小の機能でリリースすべく、シナリオを決める。
プロダクトオーナーの井上さんに色々話しを聞いて、何が問題点なのかを聞き出す。
どうやらドタキャンされるとお菓子の分だけ赤字になることがあるらしい。。。あるある。
その後、チームのみんなでシナリオとモデルとコードで一回しする。
正直モデリングっていうのが本当に面白いなぁ〜って思った。

これは会社のみんなと共有したい！！
９月に原田さん来てくれるみたいなので絶対やるよっ！！

分かったこと

• どこまで考えるかによって、モデルが結構簡単に変わる
• シナリオで説明できないプロパティは入れない
• フル/レス/フル/レス/フルのようにステートレスを挟むとテストが発散しない
• モデルとシナリオとコードは常に３味一体
• プロジェクトが失敗したのは何かをヤリすぎたから。それを明確にしてないとふりかえりの意味はない。
• 作るもの、プロセス、人、新しくしていいのは１つだけ。いっぺんに新しくすると失敗する。
• 設計は何かに縛られている。最初はCPUやメモリなど。最近は人間の頭の中のキャッシュ！
• ビールを入れるとぐるぐるが止まる。（頭はぐるぐるｗ）

ということで、今日はモデリングやプロジェクトに関して沢山考えた・・・ これは縁だな・・・８月のSCRUM研修に行くのを決めた！

そしてジャンケンではSoftware in 30 Daysをゲット！ 近頃ジャンケンが強い（笑

ファシリテーショングラフィック（FG）の練習会

ファシリテーショングラフィック（FG）の練習会に参加してきた。 色々気づいたことがあったのでまとめておく。

そもそもの動機

そもそもは会社での会議がどうしても空中戦が多かった。ただ、そのときにホワイトボードを使って書くようにすると、明らかに効果があると実感していた。ということで、もう少しスキルをあげることができないかな～と思ってたところに、会社の友達からこんなイベントあるよ～ということで参加を決めた。

色は少ないほうが好き

ファシリテーショングラフィックには作例として色々な色づかいのグラフィックが載っているが、ごちゃごちゃしてイマイチ好きじゃない。個人的には色は少ない方が好き。でも自分の演習のときに色を変えたほうが絶対良いっていうところが見つかったので、そういうところは意識していく必要があるなぁ～って思った。

議論の納得感 ＞ 後での見やすさ

これも参加するまではあまり意識できてなかったけど、やっぱり自分がFGに求めている一番の目的は議論のときの納得感が重要なんだろうな。後で見たときにイイネーって思うのと議論のときに納得感があったわ～っていうのは違うんだと思う。 これは泡の会という飲み会の振り返りでも聞いてみたけど、みんな意見が違って面白かった。

FとFGを同時にすることは結構難しい

スキルが足りないのかもしれないけど、話ながら書くというのは結構難しい。 ワークのときはゆっくり話しているけど、本当に喧々諤々の議論を聞いているのをまとめるのはちょっと無理だろうな～。やっぱりグラフィッカーの存在をみんなが意識しながら進めていく必要があるんだろうな。

その場でフレームワークを考えることは無理！！

その場で新しい図を生み出すのは無理なので、事前に自分が使える図を増やしていく必要がある。マトリクス/マインドマップ/親和図/連関図とかが使える感じ。もう少しこのレパートリーを増やしてみたい。

短時間の中でイラストは難しい

ワークの時間が20分ということもあったが、やっぱり緊張の糸がずっと張っている感じ。その中でFとFGをやりながら絵を描くっていうのは難しかった。まあ誰かが意見を言ってるときにイラスト書いてたら、「聞いてよ！」ってなりそう（笑
もう少し時間に余裕があって緩むときがあればイラストかけるかも･･･

KPTの話でイベントに少し貢献できた（かな？）

ふりかえりのフォーマットでKPTを使っていたんだけど、他の人のチームを見るとTryの出し方が上手くできていないようだった。全体のふりかえりのときに話できる機会をもらえたのでKPTの書き方を参加者のみんなに伝えることができた。 せっかくなのでふりかえりのフォーマットに使ってもらいたいしね。 この前書いた論文が上手くつながっているような気がして、ちょっと嬉しかった♪

人が良かった

参加者も運営の人も色々な人がいたけど、みんな個性的で面白かった。運営に関わっているヨッシーさんの後輩ということもあるけど、初めて会った自分の意見をきちんと聞いてくれるっていうのはとっても凄いなぁ～と感じた。
自分は･･･できないかも（笑

ファシリテーショングラフィック読了

ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)

会社のミーティングが空中戦になることが多いので、ファシリテーショングラフィックの練習会に参加することにした。
事前に読んできてください指定されたので、会社の友人に借りて読んでみた。
個人的にはファシリテーションっていうのはあんまり好きじゃなかったけど、本を読むといいなぁとか使ってるなぁっていうのはある感じ。 ファシリテーション、ファシリテーションって言ってる人が嫌いだったんだろうな〜と過去を振り返ってみる（笑

気になったところ

P44
前もって議論の展開を考え、使えそうなツールを思い描いて…（略
それを会議が始まるなり押し付けるのは、あまり感心しません。
参加者のやらされ感が募る上に、「何か落としどころがあるな」と
勘ぐられ、抵抗力が生まれるからです。

これは本当にそう感じる。自由に意見をだしてくださいって言っておきながら、最後は自分の方向になんとか持っていこうとするのは本当に辞めてほしい。自分もそうならないように気をつけないと。。。

P79
気に入ったイラストがあったら、何度も練習してみてください。
使えそうなイラストを頭の中にストックしておいて、
これを使おうと決めたらスラスラと手が勝手に動くのが理想です。

せっかくの手書きなので、イラストは使わないとだね。
ちょっと練習しておこう。。。

P81
縦の論理と横の論理を意識しながら、話を聴きます。
縦の論理：前提〜根拠〜結論
横の論理：あるテーマに対する切り口

自分の中で何点か観点を用意すればいいということだ。マトリックスだとそれが横軸に表現されるので、マトリックス型の絵は書きやすいかも。

P86 
話し合いの進め方が気に食わなくて、反論ばかりする人もいれば、
自分の存在を認めて欲しくて過去の経験を語る人もいます。

確かにその通り。この一文がこの本で一番ズギュンと来た！
意見をする人の性格や欲求を考えることが１つの近道かもしれない。。。

P89
パーキングロットを使おう！
（テーマから外れた意見のときは）ホワイトボードや
模造紙の端などにスペースを取って、メモしておきます。

変なところで盛り上がるというのはあるので、こういうことを覚えておけばいいのかも。

感想

全体を通して見ると理論のところから、実際のやり方、そしてファシリテーターの思考の流れを書いた具体例もあって、分かりやすい本だと思う。
付箋を使ったり、A4用紙を使ったりと実践的なテクニックも乗っているので自分のやる気次第で明日から使えるはず。

自分がファシリテーターを好きじゃない理由

感想を書いていて、ファシリテーターがあまり好きじゃない理由がなんとなく分かった！今まで会った人の中には自分は知っているんだぞオーラを出したり、自分の落としどころに持っていこうというのが見え見えの人がいたからだと思う。
例えば上に書いたパーキングロットも名前を出さないで、ただ端に書けばいいのに、「これはパーキングロットと言って…」と説明を始める人がいたりする。正直ウザい。。。
反面教師としてそういう変な人にならないようにしようと強く誓った（笑

AgileJapan仙台サテライト 参加レポート③

教育は遊びから

一般社団法人イトナブ石巻　代表理事 古山隆幸さん

イトナブとは？

ペットボトルロケットにGoProつけてみた - YouTube

教育は遊びからということで町づくりをしている。
町づくりの団体は次の世代にうまく渡すことが使命。
若者が未来を考えられるようにしたい！

イトナブ＝IT×イノベーション×営む×学ぶ×遊ぶ
遊びが最終的にはイノベーションにつながっていくはず。

イトナブの方針

2021年までに石巻に1000人のIT技術者を作る

一歩でも半歩でも自分が動くと、変わるということを感じて欲しい。
大人は「面白い大人」「かっこいい大人」でなくてはならない。
子供たちはそれに触発されていく。

イトナブの教育方針

イトナブの教え方は「勝手育」。 自分でやってみて、何かが分からなくなったら聞きに来る。それでいい。
全国のハッカソンに武者修行に行くこともやっている。

イトナブの活動

• 東北TECH道場
• 石巻ハッカソン（http://itnav.jp/archives/228）

質問

【質問】
やる気のない人はどうするの？
【回答】
そっちのアプローチはしていない。
今やりたいと思っている人に情熱を注ぐ。

【質問】
目標の1000人ですが、今はどれくらい？
【回答】
今は開発できるのが60人くらい。
その中でもイケてる人は15人くらい。

感想

古山さんはパッと見、ただのカッコいいお兄さんだけど、芯はものすごく熱い人だなーって思った。
やっぱり地元を活性化するっていうのはいいことだし、そこに向かって色々なことを自分たちが楽しみながらやっているっていうのを感じた。
しゅうたろうという子供が「アプリ作ってシリコンバレーに行く」っていうのがめちゃくちゃカッコいいと思ったし、それを言える環境を作ってるイトナブという組織は凄いなぁ～って思った。

「要件は定義するものではない。見つけるものだ。プロダクトディスカバリーのすすめ」

楽天 半谷さん

本日のメッセージ

量は質に転化する
なので、たくさん失敗しましょう
全ては仮説である。
だからこそ、早く小さくリリースすべきなんです。

プロダクトバックログ

プロダクトバックログと要件定義とは違うの？

AngryBirdは要件定義から生まれたのか？？
参考）How Angry Birds started?
http://notes.fundersandfounders.com/post/82688778583/how-angry-birds-started

たまたま生き残っているものが、生き残っている。
定義するよりは発見しましょう。

ちょこっとワーク

20個の○に顔を書くワーク。 ブループの隣の人に渡して、好きなものを3つに☆印を付ける。 自分のところに戻ってきたら終了。 手を上げたらバラけていた。

全ては仮説と検証と実践

Product Discovery ステークホルダーを3人考えると色々な方面から見ることができて、良いプロダクトになる。

• リーンキャンバス
• 行動モデリング
• ペルソナ
• ユーザーストーリーマッピング
• プロトタイピング
• リリース計画

楽天さんの実例を交えて結構詳しく説明してくれた。 ここでは書けないのが残念（笑

質問

【質問】
使っているツールはなんですか？ 【回答】 アトラシアンの製品が多い。 Stashとか。

【質問】
ペルソナの妥当性はどうやって確認していますか？
【回答】
最初はググって作って、その後に実際に会ってペルソナを変更した。

感想

要件を定義するのではなく、量を作って生き残るものを見つけよう！っていうのは面白いアイディア。 それをABテストとかでウケるのを探していくって感じかな。
楽天さんでリーンキャンバスをキチンと使ってるって凄いなぁ～って思う。自分の会社はそこまで色々なプロダクトがないけど、本当にスタートアップのときはこういうの考えて方向性を定めていかないとブレちゃうんだろうなぁ～って感じた。。。

ちょこっとワークは面白かったのでぜひ自分の友人とかでもやってみようと思う。

AgileJapan仙台サテライト 参加レポート②

実際に遠隔でアジャイルをやってみて分かったこと

メンバーズ 角銅浩平さん

アジャイル最大の敵は距離

もし遠隔でアジャイルができたなら･･･ ・オフショア ・リモート開発 ・人材の採用の幅が広がる

パターンランゲージとは？

ContextとProblemとSolutionがセットになって、それに名前が付けられている。
GoFのデザインパターンもその一つ。
[参考]パターン・ランゲージ: 創造的な未来をつくるための言語
http://www.amazon.co.jp/dp/4766419871

遠隔のアジャイルパターン

場の共有

"雑談"を含めてチームメンバー間の情報共有が行われ、チームの一体感が醸成される。
→拠点間で常時テレビ会議を行う。

全員チャット

複数チームがあるときに他のチームにも有益な情報、ノウハウは共有されると全体が改善されやすくなる
→プロジェクトに関わらないメンバーもチャットに入れる

15分の朝会

問題が起きたときに共有、対処を早くすることでロスを最小にする
→朝15分くらいの短時間で共有を行う
→全員で準備して、スタンドアップミーティングにする
→すぐに解決しない問題は2次会で！

NTT(No Talk Time)

情報量が多いとかえって集中できないことがある
→「話しかけるの厳禁」の時間を作っている
午後の2時から5時をNTTにしている

ポケット一つの法則

プロジェクトが進んでいく過程で共有すべき情報が増えて、複数の箇所に保存されている →Wikiに情報を集約し、探すコストを下げる。
[参考]「超」整理法

壁の活用

定期的に確認しないといけないもの（インセプションデッキなど）は常に見えるほうがいい →両方の拠点に同じものを貼るようにしている
あえてアナログを選ぶことも必要

十分なドキュメント

過剰なドキュメントは作成しない。 →必要なドキュメントは作成する。（インセプションデッキ、ジャーニーマップ、ペルソナなど）

始めは同じ場所で

チームメンバーは近ければ近いほど良い →プロジェクトが始まるときは必ず顔を合わせて、チームビルディングを行う

定期的な訪問

チームメンバーの認識に自然とズレが発生することがある →イテレーション毎に顔を合わせて話す機会用いる

同じ釜の飯を食う

チームメンバーのひととなりを知ることは大事 →食べながら話すことはとても重要。 同じものを食べ、話すことは共通体験を生む

角銅さんからのメッセージ

一つだけでもぜひやってみて！！ アジャイルでみんなHappyに！！

質問

【質問】
仲を良くするために一番効果があるのは？
【回答】
一緒にご飯を食べるのが効果がある
仕事と全然違う話をするのもかなり効果がある

【質問】
ネットワークを突き詰めていけば0までいけますか？
【回答】
無理だと思うので、最低プロジェクトの開始には集まりたいところです

【質問】
定期的な訪問でずれるのは何でしょうか？
【回答】
東京の方が顧客と顔を合わせる機会が多いので、その情報を取りたい

感想

自分のチームをよく分析していて、東京と仙台の距離を感じさせないような工夫が一杯あった。
結構淡々と話していたけど、ここまでたどり着くのは色々試行錯誤があったんだろうな。 SonicGardenさんとスタイルが似ていることもあり、興味深々だった。

高専生と取り組むScrum（仙台高専 力武克彰さん）

なぜScrumか

高専生は実装は得意だが、実装だけでは価値は生まれない。
なので、価値を生み出すところをキチンと抑えて欲しい。

高専生＋方法論（PDCA）＝価値を生み出せる創造的技術者

取り組んだこと

ETロボコンへの参加（H23～H25）
スクラムの要素を取り入れながら実施した。

Webアプリ開発のプロジェクト 児童向け物語創作システム

実際にどうやっているのか？

力武さんがスクラムマスターとなり、高専生にプロダクトオーナーや開発者など様々な役割をふっている。

成果物

• プロダクトバックログ
• スプリントバックログ
• インクリメント
• スプリント計画ミーティング
• プランニングポーカーでの見積もり
• 昼会（デイリースクラム）
• デモ（スプリントレビュー）
• ふりかえり（レトロスペクティブ）
• ユーザービリティテスト

スクラムに取り組んでみた印象

一番使えると思っているのはふりかえりと計画ミーティング。これはチームの現在地を確認できる場として使える。 高専生は人間関係はできているが、逆にそれを壊すことを恐れるため一歩踏み出せないことがある。

開発対象の理解不足など、2週間で要求～受け入れまでを行うのは本質的に難しい
問題課題が見えると学生が自発的に動き出す。

スクラムマスターのお仕事はサーバーントリーダーシップ。
もっぱらお菓子の買出しを行っている。

困っていること

• 開発と研究のバランスが難しい。開発終わって論文を書かない
• 時間割が合わずにスクラムチームが揃わないことが多い
• スクラムマスターがサボる

情報共有

• Facebookグループで実施している
• Githubを使っている

環境・ツールについて

• コミュニケーションコストを下げる
• メンテナンスコストを下げる
• 学習コストを下げる

高専生が生き残るためには

• 「頼れる仲間」を「きちんと頼る」ことができればもう何も怖くない
• 組み込み系のPBLを実施している
• スーパーエンジニアとの出会い

質問

【質問】
モチベーションが低い人をどう持ち上げていくか？
【回答】
あの手この手で頑張っていますが悩んでいます。。。

【質問】
物書きは楽しくない
【回答】
本来は論文も含めて、プロダクトにするのがいいと思う

【質問】
2011年以前の学生とそれ以降の学生の違いは？
【回答】
昔は高専生ならではのガムシャラ力に頼っていた。
スプリント毎にやると効率的にできるようになってきた。

【質問】
出会いの場を作るためにはどうでしょうか？
【回答】
本当は仙台の近くにあればいいんだけど、なかなかそうも行かない。
平日の勉強会に行けるのはかなり意識が高い学生

感想

Scrumを忠実に実施している印象を受けた。
やっぱりグッと来たのは、以下の言葉。
高専生＋方法論（PDCA）＝価値を生み出せる創造的技術者
力武さんの、高専生をもっと高く売り込みたい！というのがとても素敵だと思った。