やはり俺の技育展の発表内容は間違っている(意訳:人生初登壇しました)
やはり俺の技育展の発表内容は間違っている
こういうタイトルだと拡散力が上がるってどっかに書いてあったので....
気にしないで読み進めてください。。
先日の9月26日にてサポーターズさん主催の#技育展 に参加しました。テーマは「はじめてのアウトプット」ということでアウトプットを作ったハッカソンに参加してからこの登壇に到るまでの過程を見せたいなと思いお話ししました。
人生初登壇だったので、めっちゃ緊張しました。。
イベント詳細およびプレゼン資料
アウトプットを「展示」する学生向けテックカンファレンス「技育展」
-
伝えたかったこと
なかなか130人近くの学生に向けてプレゼンする機会はないので何を伝えたいかについていろいろ考えました。
「はじめてのアウトプット」に申し込んで通ったので、この夏にハッカソンに参加してアウトプットを作って技育展で喋るまでの過程、成長点を振り返って、「やってみよーぜ！」から広がる面白さを話したいと思いました。
反省点
3分の発表時間使い方
技育展の発表時間は5分なのですが、「はじめてのアウトプット」の分野だけ3分でした。３分間で喋る内容は
- 自己紹介
- StudyOurSelvesについて
- 反省点
- 写真あげMASKぁ〜？？について
- よかった点・反省点
- まとめ（よかった点）
- やってみよーぜ！
とだいぶ内容は削ったものの内容もりもりでした。
ハッカソンでのプレゼン資料(2つ)＋まとめた全体の話を3分でまとめたのでそこそこ難しい話ではあったのかなと思いました。
内容もりもりで伝えたいことが伝えきれなかったのかなと思います。
StudyOurSelvesについての魅力を伝えるために45秒だった時間配分をもっと増やすべきだったのかな（1分15秒ぐらいは欲しかったかな）
終了後のフィードバックでも、「反省点などの独自性があったが、もっとプロダクトについて入れてもよかった」とのことで確かになと感じました。プレゼンの練習や資料をみてくれた友人たちは、プロダクト作る側やプロダクト自体を知っている人だったので、もっとプロダクトの魅力について伝えたら良かったなと思いました。
全体の講評や受賞講評であった「一点集中型」という部分にした方が伝わりやすかったのかなと思いました。
遠くにいる情報系の友人に、終わったあと感想を聞いてみたところ、「後半、自分の話やないかー」とのこと。（10年前から変わらないらしい...）
第三者に聞いてもらって、フィードバックをもらって、伝わりやすいプレゼンや登壇を繰り返して「伝える力」を高めていきたいなと思いました。
やっぱり内容つめつめにするよりもプロダクトの魅力を伝えた方が3分だと面白いし伝わりやすいなと思いました。
おそらく今回、3分という限られた時間を考えると、この夏の過程よりも別のことを強調した方がよかったのかなと（やはり間違っていた...?)
あと練習のしすぎ説も懇親会で話しました。40テイクぐらいはやりましたね。。
2年後はYouTuberになれるらしい
「はじめてのアウトプット」のスポンサーLTのGMOさんのお話が興味深い内容で、2年前にアウトプットをしてみたら、会社のCMに出て、そのついでに旅行できて、小学生の先生になったり、役職もらえたり、最終形態YouTuberでお金を稼げるようになるらしいです。
どう転ぶかわからないけどこの夏はじめた「アウトプット」とかを続けていきたいなと思いました。2年後はYouTubeでお金をもらうんだ...
技育展を振り返って
最初のMatzさんの基調講演でもありましたが、「自分の価値」をどのように伝えていくかというのは、今後考えていく必要があると思いました。アウトプットは相手が自分の価値を測る基準にことができるのではないかと思いました。
私が参加した「はじめてのアウトプット」枠は、はじめて詐欺が半端なくてなんか完成度高いし、今後どんな強力兵器プロダクトを飛ばしてくるか分からない人たちばっかりだったので要注意です。（楽しみです）
ほとんど同世代なので、モチベはすごく上がります。Twitterで繋がったので今後が楽しみです。他のテーマとかもツワモノが揃いまくっていたとのことなので、やばい...
名前４文字かぶりの方とはじめて会えたのでよかったです。
一年後ぐらいにLTができるぐらいの面白いネタを作っていこうという感じ
— yama🌤️ (@y_a_m_a_y_a) 2020年7月18日
2ヶ月前に1年後ぐらいにLTできるようなネタを集めたいという趣旨のツイートをしていて、想定より10ヶ月ぐらい早くLTというか登壇できてしまったので驚きです。
来年もあるみたいなので、喋るの上手くなって帰ってきたいですね。無駄開発のブロック好きです。
-
自分たちのプロダクトの宣伝（3分で伝えられなかった部分）
残すかすごく迷ったスライド
ハッカソンやろうぜ！って誘ったらすぐにOKが通った話です。これができるのは強い。
StudyOurSelves
オンライン授業での「課題忘れたー」防止や、「みんなで勉強会をする」ことで学習効率が上がることに目をつけたWEBアプリケーション。
課題の期限をみんなで共有＆独自で作った勉強問題を共有することができます。
使った技術としては、FlaskとAzureをメインで使っていて、ベータベースは今回用にHerokuを使っています。
授業検索の類似度やログイン機能などが個人的なこだわりポイントです。（ただここはプロダクトの価値に直結する部分ではなさそう..)デザインもかっこいいデザインでもっとブラッシュアップしてレスポンシブ対応とかしたらもっと使いやすくなりそうです。細かい完成度は「ん〜」という感じですね。
リンク：http://studyourselves.azurewebsites.net/
#サマーハッカソン
— yama🌤️ (@y_a_m_a_y_a) 2020年8月16日
StudyOurSelvesの動作デモはこんな感じです。
みんなで共有して、オンラインでも一緒に勉強できるようにという感じです。 https://t.co/eNwUNh9Ch3 pic.twitter.com/FtntVzEWQG
明日のプレゼンで見せれなさそうな感じな場所。検索機能の実装(また類似度求めるやつやってた) pic.twitter.com/ZQtpfk48Eo
— yama🌤️ (@y_a_m_a_y_a) 2020年8月15日
詳しくはブログへ
写真あげMASKぁ〜？？
画像に簡単にモザイクやニコちゃんマークをつけられるWEBアプリケーションです。SNSとかにアップロードする前に使うことで、個人情報を隠したりすることができます。自動で顔認識してモザイクをかけることができます。（漂うパラサイト感）
https://t.co/5V5lk65Al2
— yama🌔 (@y_a_m_a_y_a) 2020年9月12日
WEB上で簡単に使えるので、ぜひ使ってくださいぃ！！！#hacku https://t.co/TXX8pzaki1 pic.twitter.com/x8mG8Vkr27
スライドにもありますが、フロントにVue.jsを使って、バックはFlask,OpenCVなどでAPIで繋いでいます。Azureでホスティングをしています。機械学習部分は、OpenCVとAzure Face APIを使っています。
フロントのページのユーザビリティはそこそこ高めなのかなと思います。
詳しくはブログへ
7月にあった技育祭で刺激を受けて、85日前に「アウトプットをはじめてみたかった」というブログを書いてわずか3ヶ月ちょいでここまでたどり着いてしまったので、これからも技術や色々なことを吸収して、面白そうなところを楽しくやっていきたいかなと思います。
Azureで失敗して１週間で学生クレジット8000円分を溶かしたお話
誰かが「時代はクラウドですよ〜」って言っていたので、クラウドを使ってみようという感じでAzureを3月に登録して、herokuとかを使わずにAzureでホスティングしたりしていたのですが、SQLデータベースを使った時に普通に失敗して１週間で残っていた学生クレジット8000円を溶かしてしまったので、その時のことを書きたい。
ちなみに、クレジットを使い切った後でも、無料の機能は使えるし（サブスクリプションをAzure Student Starterに切り替えることで継続して無料機能は使える）半年後にまた１万円をお代わりできるので、特に不満はない（逆にクラウドのいい勉強代になりました）
学生なら登録すると１万円分もらえて、一年後にまた１万円お代わりできる＆クレジットカードの登録が必要なくて、絶対にリアルマネーに手を出されないので、Azureとりあえず登録しておけ！！って感じです。
-
背景
サマーハッカソンにて、StudyOurSelvesというサービスを作りました。その時に使ったデータベースがAzure SQLデータベースでした。
- 2020/8/4
別のホスティングしていたアプリケーションでちょっといいサーバーを使っていたので、すでに20%使っていました。（メールで通知がきます。）
- 2020/8/15
- 2020/8/17
- 2020/8/17(その２）
- 2020/8/18
死亡....
ハッカソンが16日だったので、本当にすぐ使い切ってしまいました。
-
すぐ使い切ってしまった原因
モニターをしっかりしていなかった件
メールがきた時、「まだ50%だし大丈夫か〜」と思ってからすぐでした。
50%の通知がきた時に使っているインスタンスを切れなかったことが挙げられます。
一般ユーザーだと、プレビューでマネーモニタリングの機能が使えるらしいのですが、学生アカウントだと、まだ使えなかったので、どこが原因なのかがわからなかったことが挙げられます。
75%や90%の通知がきていた時、私は会津にいました。
スマホのブラウザだとインスタンスを止められなかったので、スマホアプリは必須ですね。（評価4.8で驚きました）
-
まとめ
課金をするときは、マネーモニタリングをしっかりしよう！
どこに何円使っているかを確認することが大事！
異常があったらすぐインスタンスを止めよう！（一気に課金されないように）
ということを学びました。
あと、
サーバーは積んだお金だけ強くなる
— yama🌧 (@y_a_m_a_y_a) 2020年9月12日
ということも学びました。
Azure使いやすかったので、次の3月にまたクレジットがもらえるのを待とうかなと思います。GCPやAWSも同じように学生クレジットがもらえそうなので、そっちも触って大失敗してみようかなと思います。
学生サイコー！！
-
学生アカウントでお金がどれくらい使われているかの確認方法
- https://www.microsoftazuresponsorships.com/Usageにアクセス
- www.microsoftazuresponsorships.com
- Azure for Studentsをクリック
- 使われている内訳がわかる
Open Hack U 2020 vol.3で最優秀賞をいただいたので色々振り返りたい
先日2020年9月12日に参加したOpen Hack U 2020 vol.3で最優秀賞をいただきました。まさか...という感じだったので、発表の時は思わず叫んでしまいました。
最優秀賞ダーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
— yama🌘 (@y_a_m_a_y_a) 2020年9月12日
心臓が飛び出るかと思った…
メンバーは前回の初めてのハッカソンの時と同じメンバーで、通算２回目のハッカソンです。
-
作ったもの
今回作ったものは、「写真あげMASKぁ〜？？」というWEBアプリケーションです。
いい写真が撮れても知らない人の顔が写っていたり、車のナンバーとかの個人情報が含まれていることがあってインスタにアップロードできなかったりする経験があると思います。私のインスタも全て風景です...
最近はSNSでの個人情報が原因とするストーカー被害もあるというテレビをやっていてそのような課題解決するアプリケーションを作りました。
モザイクだけではなく、スマイルのニコちゃんマークに置き換えるや感情認識をしてそれにあったニコちゃんマークに置き換える、文字をモザイクの機能があります。
デモ動画およびスライド資料&YouTube
youtu.behttps://youtu.be/fpYDOsU1ut8
https://t.co/5V5lk65Al2
— yama🌘 (@y_a_m_a_y_a) 2020年9月12日
WEB上で簡単に使えるので、ぜひ使ってくださいぃ！！！#hacku https://t.co/TXX8pzaki1 pic.twitter.com/x8mG8Vkr27
使用技術はフロント部分がVue.jsをメイン、サーバ部分がPython(Flask)をメインに使っています。画像処理や顔認識はOpenCV、AzureのAPI、サーバ環境構築はAzure static appとAzure web serviseを全力で使いました。
-
よかった点
-
アイデアをじっくり選定できた
よかった点はアイデア選定にすごく時間をかけることができたことがあげられます。
前回のハッカソンの振り返りで「使ってもらえるもの」という観点が足りなかったということですが、今回はアイデアを前半の半分近く、５日間ぐらいかけてしっかりアイデア選定して土台をしっかりと作れたのが大きいのかなと思います。
-
ユーザが簡単に使うことができた
今回の評価のしていただいた点として、「簡単にフィルタリングできる」ということがあります。ユーザ視点として、「自分たちが開発後も使いたいもの」を作るという目的もあったので、そこが生きていたのかなと思います。
最優秀賞は、Hack ID 18：Cos5year「写真あげMASKぁ～？？」
— Hack U🤘/Yahoo! JAPAN (@hackujp) 2020年9月12日
最優秀賞おめでとうございます🥇🎉
審査員中村からのコメント「昨今の事情を鑑みたり、まわりの人のプライバシーを考慮でき、簡単にフィルターを掛けられたりするのが良かった」#openhacku2020 #hacku
はじめは画像を扱うのでスマホアプリでもいいかなと考えていたのですが、インストールの手間がユーザに使ってもらうハードルになりうるのと、技術的にどうさわればいいのかわからなかった、Vue.js使えばぬるぬるサイト作れる！！ということでWEBアプリケーションとなりました。（サーバでOpenCV使う環境構築が意外とハードルでした）
- 作り込むことができた
私は、サーバ系をメインでやったのでわかりにくいのですが、アプリケーションを作り込むことができたことが今回の評価に繋がったのではないかと思います。
homeのページの使い方や説明の作り込みや、顔選択のボタンの工夫（例えば顔の数が多い時は、デフォルトでチェックがついているなど）です。
私はフロントに関してデバッカとしての役割が多く、使いにくいところとか機能についてめっちゃ色々issue立てたり要望していたので、文句だけ言う人間になっていました。
サーバ側としては、顔認識の枠付けの文字サイズや枠線の太さ決定のアルゴリズム、モザイクかける長方形が斜めの時の回転のアルゴリズムなど色々作っています。
-
これからの課題
画像のアップロードの時間が画像サイズに依存する
今回は1日限定で１ヶ月３万円の超強強サーバを用意しているので、そこそこ早いのですがまだ、アップロードには時間がかかる形でした。
サーバーは積んだお金だけ強くなる
— yama🌘 (@y_a_m_a_y_a) 2020年9月12日
高速モードを選択すると、画像の画質を下げたり、サイズを小さくする処理を行ってから実行するので時間は少なくなるのですが、できるだけ画質劣化を行わないで高速にできる仕組みを考えねばと言うのがハッカソン直前に思ったことでした。
- TwitterAPIやインスタとの直接の連携
- モザイク種類の増加
- 自分で選択してモザイクをかける場所を選択できる機能
- LINE BOTなどの対応（より使いやすくなる）
- 動画への対応
などが拡張性として考えているところです。
-
反省点
-
バグだし
一部のスマホで動かないケースがあると展示会で報告を受けました（最後の１時間でプッシュしたことで何かが変わってしまっていた...)
直前まで編集し続けるとこんなことが起きてしまうので、
安定板を当日朝までにリリースすることの大切さを知りました。GitHubのrelease機能バックアップをとっておくのにめっちゃ便利でこっからバシバシ使っていきたい。
直前のアップデートはできるだけ避けよう！！
- サーバの環境設定
サーバの環境設定やエラーで時間が食うことが多かったことです。大半は仕方がないことではあるのですが、サーバの環境構築はおそらく一番嫌いかもしれないです...インフラ系は難しいなと感じました。
-
テストコードを同時に書こう！
サーバ側を開発する上で感じたのは、開発したらテストコードをしっかり書こうと言うことです。今回はプログラムの下に、関数が動くかどうかの確認関数だけを書いたり書かなかったりしていたので、しっかりとプログラムを分けて、関数を呼び出す形で書くほうがいいと思いました。この前サーバ側のワークショックで使ったSwaggerUIとかの使用してデバックをしやすい環境を作りたいなと感じました。画像データをPOSTするのはそこそこ大変でした。
-
設計をしよう！
展示会で他のチームを回っていた時に、ちゃんと設計をやっているチームがあって、重要だなと感じました。今回は二週間と期間が前回よりも長めなので、シンプルな構成でもAPI戻り値のやり取りを実装前に設計するのは良さそうと感じました。
今回の開発の終盤の時に、機能を追加するために戻り値を増やすと言う少し危険なことをしていた（機能追加でエラーが起こる可能性が高かった）ので、そのようなことを防ぐために重要だと感じました。
- もっとサポーターの方に細かく相談すればよかった。
今回開発中盤にあった「なんでも相談会」で１時間近く企画面から技術面、発表の方向性やアイデアの発展性、追加機能など様々なアドバイスをいただいて開発の方向性が固まったと感じました。一方slackでの質問などは使わなかったためもっと使わさせていただけばよかったかなと思いました。懇親会でご一緒したチームではslack質問フル活用ですごかったと言う話をしていました。展示会でのフィードバックなど実際に完成版としてリリースする時に役立つので、アプリのクオリティに繋がると反省です。
-
プレゼン上手くなりたい！
タピオカのところがうますぎたので、あれくらい人を惹きつけるようなプレゼンがしたいですね。最初に普通に煽っていたので記憶に残りやすいとは思ったのですが、あれができるのはすごいと思いました。私は今月末に技育展で登壇するので、上手く喋ることができるくらい練習したいですね。
少しずつエンジニアの開発と言うのがこの夏にわかってきたなという感じです。この半年ハッカソンに初めて参加してから、Azureとかのクラウド技術からGutHubの使い方、チーム開発や綺麗なコードをかく（今回はわからなくなることはなかったが、ドキュメントがあるともっとスムーズになると感じた）ことを学びました。
やってみようぜ！ってノリで始めたものがどんどん繋がって、新しい学びにも繋がって、良い循環を作り出し始めているなと感じます。
9月26日には技育展での初登壇、今回のハッカソンの副賞でもある12月ぐらいにあるHackDayへの参加など、これからも色々イベントが待っています！！
迷惑メールに入っていて気がつかなかったけど、 #技育展 初登壇が決まったぜ！(びっくりすぎる)
— yama🌘 (@y_a_m_a_y_a) 2020年9月1日
はじめてのアウトプットからの夏休みの成長についてお話して、200万取ってみんなで焼肉パーティするんだ… pic.twitter.com/1CBoeaBvAa
（ちなみに「はじめてのアウトプット」枠の一番最後です！！）
HackDayは年齢制限なしのガチ勢たちとの熱い戦い、技術力やめっちゃいいアイデアでガチンコ勝負できたらなと思います。（めっちゃ楽しみ）去年の優勝副賞はテキサスにいけるやつだったらしいので、優勝目指して準備していきたいなと思っています。
Neural Computer Stick 2は以前OpenVINOを触った時に欲しいなと思っていたものなので、めっちゃ嬉しいです。機械学習の実行の時にあるとつよつよになれるので、めっちゃ嬉しい。OpenVINO環境構築が今までで一番めんどくさかったけど、速度は早いので強い。
ハッカソンに参加して思うのは、ものづくりって楽しい！と言うのと、３年間勉強してきたことが普通に役立っている！！と言うことです。
作っている時はそこそこ辛いのですが、発表をしてフィードバックがあると色々楽しいなと感じます。また、参加することで今まで見えなかった課題や大学での勉強の共通点がみたいなものが見えてきて面白いですね。
今年はオンラインなので、東京だけではなく全国の同年代の学生と話せるのも魅力です。
今回は、優秀賞２つが出た段階で諦めムード（優秀賞２つのクオリティってすごいなと思い見ていたので）、まさか最優秀作品賞をいただけるとは思っていなくて、発表の時心臓が飛び出るかと思いました...
これを糧に次のイベントや開発や勉強を頑張っていきたいです。
まさか最優秀賞とは…という感じです。(心臓に悪い…)
— yama🌘 (@y_a_m_a_y_a) 2020年9月12日
すごく嬉しいです！！
Hack Day2020の方のチャンスをいただいたので、次もいいものを作っていきたいです！！ https://t.co/waqItdGNUF
めっちゃ煽る名前になったのは、名前提出の締め切り直前会議前に、気晴らしに宇崎ちゃんは遊びたいをみてた影響が大きいことは確か。
— yama🌘 (@y_a_m_a_y_a) 2020年9月12日
初めてのハッカソン #サマーハッカソン 参加日記
先日、8/15,16にサポーサーズさんとVOYAGEグループさん主催の
サマーハッカソン〜オンラインでLVupする夏合宿〜 - connpass
に参加してきました。
チームは、以前からチームでの開発をやっていたCos5yearのメンバーで参加しました。結果は特になしという感じだったのですが、気がついたところと反省点を書いていきたいと思います。
今回作成したのは、コロナ時代にどうやったら今までのようにみんなで勉強や課題の期限の確認ができるかという課題を解決するために、ToDoとクイズを共有できるwebアプリケーションを作りました。(すみません、今は公開が止まっております…)
デモ動画はこちら
#サマーハッカソン
— yama🌒 (@y_a_m_a_y_a) 2020年8月16日
StudyOurSelvesの動作デモはこんな感じです。
みんなで共有して、オンラインでも一緒に勉強できるようにという感じです。 https://t.co/eNwUNh9Ch3 pic.twitter.com/FtntVzEWQG
リンクと資料
http://studyourtselves.azurewebsites.net/ (無料枠で復活させる予定です）
はじめてのハッカソン楽しかったです。
ハッカソン楽しい、少なくとも課題よりは100倍楽しい
— yama🌒 (@y_a_m_a_y_a) 2020年8月14日
- ハッカソン準備まで
せっかくなので、オープンな感じでslackに進捗状況書きまくったりアイデア会議の議事録を載せたりしました。1週間前からアイデア出しをはじめて、固めるまでに2,3回やりました。評価基準の「ワクワク感」をどのように出せるかという点が難しかったです。
- 開発開始
テストと日程が被っていたので、開発はテストが終わってからという事になりました。開発は木曜日から4日間で行いました。開発は意外とうまく進んで、一通り公開できるような機能は作れました。
- ハッカソン当日
プレゼンは3分でどう自分たちのプロダクトの長所を見せれるかについて考えました。使用技術や仕組みは全く説明しないで、「みんなで勉強できるんやーどやー」って感じのコンセプトで行きました。しかし、６０組以上もあるので中々、勉強の話はインパクトは少ないというか真面目すぎたかなって感じがします。(ワクワク感。。)
そういえば、発表順最後で、やっぱ引き運だけは持ってるなってなってる。
— yama🌒 (@y_a_m_a_y_a) 2020年8月15日
今回良かった点
- ハッカソンに出るという目標(2年前くらいに趣味垢でボソッと呟いた記憶があるが見つからなかった…)を達成できた。
検索したら2018年の12月にそんな感じのツイートしてた。
言って(思って)からだいたい一年後ぐらいに達成できるジンクス、自分は2年かかった。なぜ去年参加しなかったんだとふつうに後悔。
- 作りたいものをある程度作れる技術はとりあえずある事が分かった。
今までは、フレームワークの勉強は少ししかした事が無かったので、本当にアルゴリズムをそれっぽく書いてAOJに投げるぐらいだったプログラミングが使って遊べるぞって事を証明できた。
作りたいものがあって、それのために技術を調べて取得するのはすごく効率が良くて、その中で座学でやった内容を実装すると座学のより深い理解になって、非常に良いなと。先日、話題になった大学生がプログラミングができない問題(https://qiita.com/ike_7010/items/b7e016a70ff143722a3c) めっちゃわかるって感じになりました。
- 久しぶりに１つの目標に向かってアクションを起こすやつができた。
もともと中高で合唱をやってたこともあって、大会に向かってやることの感覚が懐かしいです。気合い入れすぎて半年とか一年とかかけちゃうと反動が大きすぎるので、2日間はちょうどいい感じでした。
- つよつよの人たちと競争をする事でつよつよの人たちがめっちゃ強いことを確認できた。
周りの人達、やっぱり強すぎませんか…
はじめての人が8割のハッカソンには思えなかったのだが…
- 今後の課題(チーム、個人)が多く見つかった。
課題だらけです。チームの課題としては、gitのブランチの分け方が下手すぎた…
完全に独学なのでプロのチーム開発の仕方を知らない点が多かった気がします。今回のハッカソンはみんなリポジトリを公開してくれているので、ちょっとどんな感じか盗んでやる！！
あと、綺麗なコードをかく大切さを思い知りました。少し時間かけて綺麗なコードを書いておくとあとでのバグ処理の時にすごい時間短縮ができる。
綺麗なコード書いてる自信がないなう
— yama🌒 (@y_a_m_a_y_a) 2020年8月14日
綺麗なコードを書くことの大切さをこの2日間で思い知ってる。自分でも関数なんて置いたっけ？になってる
— yama🌒 (@y_a_m_a_y_a) 2020年8月16日
色々追加しすぎて後から見返して大変でしたね。。
ソフトウェアの設計も長いスパンでの開発では特に重要なんだなと感じました。１ヶ月間この感じでやっていたら確実にわけわからなくなる。。
夏休み前に借りたリーダブルコードを読むことにします。
プレゼンもたくさんチームがある中で印象を残すにはもっと工夫が必要だと感じました。皆さんのプレゼン見てて普通に面白かったので楽しかったです。次回はどうしようか考えどころです。
個人としては、圧倒的に寝不足だったのが挙げられます。試験が水曜日にあって水曜日に日曜までのレポートが出てしまった&急なバイトでだいぶ余裕が無かった気がします。優勝チームは意外と開発期間は短かったらしく、プレゼン練習の時間は他の所を見てたらしいので、そこの差なのかなと。次の日から6時発の電車に乗る感じだったので、懇親会終わったら爆睡マストって感じでした。
- 雑談MTGで同世代や色々な人と話せて良かった。
前回の技育祭の懇親会でもそうでしたが、同じ分野の同年代の人と話すのはだいぶ刺激になります。大学でどんな授業やっているのかやハッカソンの進捗や就活の話まで色々な話が出来ました。
3回目のMTGでは参加者が少なかったので、主催の三浦さんとだいぶ深いところまで行った話が出来てすごく勉強になりました。
サマーハッカソンの雑談MTG1回目、色々話せて楽しかった。
— yama🌒 (@y_a_m_a_y_a) 2020年8月10日
周りのチームがどんな感じで進んでるかとか、オンライン開発のアドバイスとか色々知れた。同年代の交流ってやっぱり刺激が大きくて楽しい。
#techstudygroupjp
サマーハッカソンの雑談MTG3回目、少人数で、色々踏み込んだ話までできてよかった。
— yama🌒 (@y_a_m_a_y_a) 2020年8月14日
明日明後日でどんな作品が発表されるのか楽しみ。自分たちがどんな立ち位置で、どう今後へ繋げられるか楽しみ。
#techstudygroupjp
入賞、優勝チームを見て思ったこと
みんな納得という感じでした。ユーザーとして見て使いたいと思うものが通っている感じでした。また、実際にサービスとして公開しているものは使うまでのハードルが低い(画像を投げるだけとか、新規登録が他の認証など)と感じました。
ユーザを意識したビジネス的な観点とユーザビリティ的な観点が追加で特に必要だなと感じました。(デザイン的なユーザビリティは今回神ってると思います、画面遷移の流れとかはだいぶ改善が必要そうです)
あと、制作物の内容が非常に分かりやすいと感じました。一言で言いあらわせるもので分かりやすいと感じました。自分たちのチームは、期限のTodo共有+クイズ共有=共同でできる勉強アプリ(ここをもっと簡単に説明できればよかった)と感じました。
ハッカソンで賞をもらってるチームは、必要とされている課題を解決するプロダクトを作り、使ってもらうためにアピール出来ている、さらに使ってもらえる制作物であることが最低限の基準であると感じました。
感想
結果発表前の直前の個人的な優勝予想は、「ゲーミングAI画像生成」だと思ってました。ああいう技術の無駄遣い感の内容がすごく好きです。
60チームちょいあるのにアイデアの丸かぶりみたいなのが無くて、面白いなと思いました。
今回のハッカソンで思ったのは、自分は比較的クリエイティブな事が好きなんだなと思いました。作ってる最中は精神的にも体力的にも辛い時はあるのですが、おそらく作った後に公開するのがすごく好きなんだと思いました。今までは趣味(作曲やら)の方だけだったのが、本業(情報系)でも出来るようになって人生楽しくなりそうです。
モノ作るのがやっぱり好きなんやなって思うこの頃。
— yama🌒 (@y_a_m_a_y_a) 2020年8月15日
入選はできなかったけど、次どうすればよくなるかなんかわかった気がしたのでヨシ⬅️
— yama🌒 (@y_a_m_a_y_a) 2020年8月16日
めっちゃ疲れたけど楽しかった。#サマーハッカソン
チーム開発うまくいかなかった時となんかうまくいった時の差について考えてみる。
先日、授業で「機械学習を利用したアプリケーションの提案」についてのグループ課題（最終課題）が出たので、提案だけじゃなくてプロトタイプまで作っちゃおうというノリでチームの開発を進めたら、うまくいったのでその時のことをまとめたい。
また、同じメンバーで長すぎた春休み中に開発を行ったら、個々はいいところまで進んだが完成することができなかったので、その時との違いについて考えたい。
作っていたもの
- うまくいった時
授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーション。
プロトタイプはこちらに公開しています。
https://summary-classes-web.azurewebsites.net/
使用言語、フレームワーク
Python,Flask,Azureなど
- うまくいかなかったもの
AOJ（会津大学が公開しているオンラインジャッジ）がオフラインでもできるソフトウェア
うまくいかなかった時
はじめにうまくいかなかった時について振り返りたい。
昨年の12月、「チーム開発でぎっとはぶであじゃいる開発って響き、なんかかっこよくね」ということで始まったプロジェクトであった。
はじめは、GitHubの使い方、プッシュやマージ、プルリクについて学び、（一人でプルリク使うとなんか虚しくなるのでみんなでできてよかった）その後分担して作業を進めていった。
私が思う、うまくいかなかった原因、要因は以下の５つだと思う。
- 機能を細分化しすぎた
まずはじめに、機能を細分化しすぎた点があげられる。今回は、ネットワーク部、エディタ部、コンパイラ部に別れて作業を行った。それぞれ各一人が担当し、全く互換性がないまま個々の技術が実装されていってしまった。これが、一番最後に一つにまとめられない原因を作ることとなるのです。
- ビジョンがなかった
次に、作りたいものへのビジョンが明確でなかったのではないかと思う。（図１）のようにしっかりと、要件定義、設計を行ったのですが、機能を細分化しすぎたため、全体を統括するプロジェクトマネージャーみたいな人間がいなかったのが原因だと思う。
-
アジャイル開発とは…
３つ目に、アジャイル開発のレポートを書いた直後（ソフトウェア設計論について一通り履修済み）だったため、開発中意識はしていた（形）だったが、実際は小さなリリースを重ねるどころか、全体をまとめることができなかった。Visual Studioがmacがいい感じじゃなかったり、環境依存の問題やいろんな問題がありました。
- オンラインで繋げた時のみに作業をしていた
オンラインの進捗会議が、進捗の確認ではなく無言の作業時間だった。。。
-
ソフトウェアを作ることより、ソフトウェアに使われていた
タイトルはよくわからないですが、以下のようなことです。
ソフトウェアを作るという目標より、個々のパートのソフトウェアを作ることに集中してソフトウェア全体が見えていなかった。
はじめにも述べたように、ソフトウェア全体を管理するPMがいなかったのも大きな原因ではないかと思います。
- 使用する言語技術についての理解度がみんな違った
使用する言語はC#を利用しました。理由としては、オブジェクト指向が強めの言語で、個々で開発しやすい。OSに依存せずマルチなプラットフォームで使えるなどの理由から採用しました。しかし、メンバーのうちC#はネイティブでかけるのが一人、自分を含め残りの二人は初めてのC#だったので、はじめのC#の勉強会が少なかったのではないかなと思います（C++かけるからそれの++版と思っていたら意外と違かった）ただ、普通に皆コードはかけるので、新しい技術を使う際はみんなで勉強会を開いて行くべきだなと感じました。
-
デザイナーいなくね？
これが最大の原因です。xmlでデザインすることの難しさについて、技術選定や開発を始めた頃全く考慮していなかったのが一番の問題でした。今回は、ModenUIというフレームワークを調べて採用しましたが、なかなか難しかったです。
そして深刻なデザイナ不足でした。「どのように見せるか」についてはすごく大事ですね。
-
これらの結果
API叩いて、問題文取得や回答を送信するネットワーク部、Tabやインデント、{の自動補間に対応した何気に強いエディタ部、実行を押したらコンパイルしてテストケースのローカル実行のコンパイラ部。３つの機能が個々に完成しました。しかし、デザインや互換性の問題などから一つにまとめられませんでした。
また、この結果がわかったのは4月でした。
ここに、どこまでできたかを示しておきます。
・なぜかしれないけどうまくいった例
次にうまくいった例についての振り返りをしたいなと。
今回作成したのは、授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーションです。
文章要約には、bag-of-wordsで単語のベクトル化をして、２つの文章ごとの関連度を調べています。関連度が高い文同士を繋げて繋がっているものが多いぶんを抽出して実装をしています。（ちょうど授業で理論を習った内容だったのでよかった）
開発期間は一週間ぐらいです。意外とすんなりと作れてしまったのでびっくりです。
今度参加するハッカソンと似たような感じだったので、それの練習として作りました。
・よかった点
-
ビジョンについてすごく話し合った
今回の成功の要因は、作りたいものについてよく話し合ったことなのではないかと思います。チーム内の共有のScrapboxにくだらないものから真面目なものまでアイデアを書き連ねるページがあり、もともとそこにアイデアをだすという習慣がありました。それを元に、アイデア出しを３時間近く話し合い一番欲しくて、授業でやったら面白そうなもの（先生の話した内容をリアルタイムで要約できたら受けそうじゃない？）を選びました。
何のために作りたいか、どんなものを作りたいかを詳しく話し合ったことが今回の成功の要因なんじゃないかなと思います。
ちゃんとは意識していなかったが、要件定義をしっかりやったんだなと思います。
-
目標、期限があった
締め切り直前はブースト入りますよね。開発のモチベーションになったのではないかと思います。
-
アジャイル開発（とよんでいいものか）
すでにある手法を元に、どのような流れで作るかを決め、文章を要約する機能を一気に作りました。これで最初のプロダクトとしての形が出来て、この後の流れが明確になったのではないかと思います。その後、重要語検出やデザインの機能が加わり、バージョン名のないバージョンアップで機能が増えていきました。
-
作業の分業
前回失敗した作業の分業について、今回の開発ではうまく動きました。
ブラウザに表示までやったら、CSSやhtmlを書いてもらって、その後にバックエンドの機能を追加するなど、必要なものが分かったら作業を割り振るという内容が多く、よかったのではないかなと思います。また、使用をはじめに多く決めすぎなかったため、個々が実装したいものを追加で実装することが出来たのかなと思います。言い換えると三人の個性が合わさって出来たのではないかと思います。
しかし、設計をちゃんとやらなかったため、コードに冗長性があったり、プロジェクトの肥大化があったりの問題もありました。
-
同時平行ではない開発
今回は、はじめに大枠を作り、機能を追加していく形だったので、同時に違う作業をすることは少なかったのではないかなと思います。レポートに追われる日々の中、全員の予定が会う機会が少なかったという要因もあります。実際の開発では、効率が悪いので、平行して行える開発を考える必要があると思います。
-
製作会議は進捗確認でメインはプレゼンについて話し合い
今回の課題の内容は、「プロトタイプを作る」ことではなく「プロジェクトの提案」だったのでプロトタイプはおまけでした。（簡単に示せたらいいなと思っていたらいい感じのものが出来てしまって少し驚いています。）
そのため、どのようなプレゼンを行うかが製作会議の主な内容でした。前回のように、製作会議が実装の時間ではなく簡単な進捗の確認や方向性の確認だけだったので、アプリケーション自体、プロジェクト自体を話す時間が確保できたのが大きいのではないかと思います。
-
前回と今回の違い、今回の反省
前回と今回の最大の違いは、プロジェクト自体について話会う時間が多く、プロジェクトのビジョンが明確に共有されていたことだと思います。
今回はプロトタイプを作ることではなく、プロジェクトの提案がメインだったので、自分はコードを書く時間は会議の時間と同じぐらいだったと思います。
また、設計を明確に行わず個々のアイデアの出しあいでプロジェクトを作れたことはすごくよかったと思います。実際の開発では、確実に空中分解すると思いますが、ハッカソンなどの短期間のプロジェクトの場合は面白いアイデアが出てきて、仕様書を超えた良いものができるかなと思います。
一方反省点は、一人が開発をある程度まで進めそれに後から機能を追加していくものであったため、ロスの時間が生まれてしまったことです。
時間は有限ではあるので、より複雑なプロジェクトの時に時間的に間に合わない可能性があるのではないかと思います。
また、設計をしっかり行わなかったため、少し変更した同じコードを違う関数で定義することや、動作確認のjupyter Notebookファイルが大量発生してしまうなど、コードの冗長性やプロジェクトの肥大化が起きてしまいました。
同時に作業を進めていれば、競合が起きるのでフィードバックがしやすいのですが、完成した後に気がつくので、手をつけられないという問題がありました。
ここは、プロジェクトの大きさによって一長一短な気がします。
感想
なんかうまくいったのでヨシ←
ハッカソン出ようぜってラインで行ったら２分後にはOKが帰ってくるようなノリのメンバーなのでハッカソンもこんな感じで頑張りたいと思います。
以前からだいぶ感じているところではありますが、クリエーションって楽しいなと思います。
でもチーム開発って難しい！！（三人寄ればなんとかをうまく使いこなしたい）
----------------------------------------------
こっからは今回作ったやつを使って要約した結果です（半分の文章量にしています。）
summary-classes-web.azurewebsites.net
---------------------------------------------
先日、授業で「機械学習を利用したアプリケーションの提案」についてのグループ課題（最終課題）が出たので、提案だけじゃなくてプロトタイプまで作っちゃおうというノリでチームの開発を進めたら、うまくいったのでその時のことをまとめたい。 今回作成したのは、授業の音声をテキスト化し、文章を要約して重要語の補足説明を入れてくれるアプリケーションです。 文章要約には、bag-of-wordsで単語のベクトル化をして、２つの文章ごとの関連度を調べています。関連度が高い文同士を繋げて繋がっているものが多いぶんを抽出して実装をしています。（ちょうど授業で理論を習った内容だったのでよかった） 開発期間は一週間ぐらいです。意外とすんなりと作れてしまったのでびっくりです。 今度参加するハッカソンと似たような感じだったので、それの練習として作りました。
・よかった点 ビジョンについてすごく話し合った 今回の成功の要因は、作りたいものについてよく話し合ったことなのではないかと思います。チーム内の共有のScrapboxにくだらないものから真面目なものまでアイデアを書き連ねるページがあり、もともとそこにアイデアをだすという習慣がありました。それを元に、アイデア出しを３時間近く話し合い一番欲しくて、授業でやったら面白そうなもの（先生の話した内容をリアルタイムで要約できたら受けそうじゃない？）を選びました。 何のために作りたいか、どんなものを作りたいかを詳しく話し合ったことが今回の成功の要因なんじゃないかなと思います。 ちゃんとは意識していなかったが、要件定義をしっかりやったんだなと思います。 目標、期限があった 締め切り直前はブースト入りますよね。開発のモチベーションになったのではないかと思います。
アジャイル開発（とよんでいいものか） すでにある手法を元に、どのような流れで作るかを決め、文章を要約する機能を一気に作りました。これで最初のプロダクトとしての形が出来て、この後の流れが明確になったのではないかと思います。その後、重要語検出やデザインの機能が加わり、バージョン名のないバージョンアップで機能が増えていきました。 はじめの概形（フロントは昔書いたhtmlをそのまま） HTML,CSSを書いてくれて神ってなった @jimar884 重要語の検出機能が追加 @tomsoyaN WEBスクレイピングの機能が追加（重いのでβ版)@tomsoyaN !!??? 作業の分業 前回失敗した作業の分業について、今回の開発ではうまく動きました。 ブラウザに表示までやったら、CSSやhtmlを書いてもらって、その後にバックエンドの機能を追加するなど、必要なものが分かったら作業を割り振るという内容が多く、よかったのではないかなと思います。また、使用をはじめに多く決めすぎなかったため、個々が実装したいものを追加で実装することが出来たのかなと思います。言い換えると三人の個性が合わさって出来たのではないかと思います。 しかし、設計をちゃんとやらなかったため、コードに冗長性があったり、プロジェクトの肥大化があったりの問題もありました。
同時平行ではない開発 今回は、はじめに大枠を作り、機能を追加していく形だったので、同時に違う作業をすることは少なかったのではないかなと思います。レポートに追われる日々の中、全員の予定が会う機会が少なかったという要因もあります。実際の開発では、効率が悪いので、平行して行える開発を考える必要があると思います。 製作会議は進捗確認でメインはプレゼンについて話し合い 今回の課題の内容は、「プロトタイプを作る」ことではなく「プロジェクトの提案」だったのでプロトタイプはおまけでした。（簡単に示せたらいいなと思っていたらいい感じのものが出来てしまって少し驚いています。） そのため、どのようなプレゼンを行うかが製作会議の主な内容でした。前回のように、製作会議が実装の時間ではなく簡単な進捗の確認や方向性の確認だけだったので、アプリケーション自体、プロジェクト自体を話す時間が確保できたのが大きいのではないかと思います。 前回と今回の違い、今回の反省 前回と今回の最大の違いは、プロジェクト自体について話会う時間が多く、プロジェクトのビジョンが明確に共有されていたことだと思います。 今回はプロトタイプを作ることではなく、プロジェクトの提案がメインだったので、自分はコードを書く時間は会議の時間と同じぐらいだったと思います。 また、設計を明確に行わず個々のアイデアの出しあいでプロジェクトを作れたことはすごくよかったと思います。実際の開発では、確実に空中分解すると思いますが、ハッカソンなどの短期間のプロジェクトの場合は面白いアイデアが出てきて、仕様書を超えた良いものができるかなと思います。 一方反省点は、一人が開発をある程度まで進めそれに後から機能を追加していくものであったため、ロスの時間が生まれてしまったことです。 時間は有限ではあるので、より複雑なプロジェクトの時に時間的に間に合わない可能性があるのではないかと思います。 また、設計をしっかり行わなかったため、少し変更した同じコードを違う関数で定義することや、動作確認のjupyter Notebookファイルが大量発生してしまうなど、コードの冗長性やプロジェクトの肥大化が起きてしまいました。 同時に作業を進めていれば、競合が起きるのでフィードバックがしやすいのですが、完成した後に気がつくので、手をつけられないという問題がありました。 ここは、プロジェクトの大きさによって一長一短な気がします。
#技育祭 Day2に参加して思ったこと、感想
Day1と同じ感じで、メモを元に思ったことを書いていこうかなと、少しずつ書いていたら一週間たっていた。
テックカンパニーって結局なんだろう？
1日目のオープニングセッションで松本さんが面白い話をしていたのでどこにいくのか迷っていたのですが、この部屋にきました。
アジリティを高めていく
問題解決をするには問題の定義が必要である。
問題の原因は色々なところにあり、その[** 不確実性を少なくすること]がアジリティである。幅優先探索で試行錯誤して不確実なところを消していく必要がある。
この考え方は、課題の解決の時に重要な考え方だなと感じた。最適の解法を合理的に見つけるために、泥臭くやっている（矛盾しているけど、あっている気がする）と感じた。テスト対策の勉強をやるときも、出そうなところをやっていって不安がない状態でテストに望む（テスト勉強の理想）と同じ構図だなと感じた。
失敗のコントロール
失敗しても失敗から軌道修正できる、失敗をコントロールできる環境を作る。全体の組織の大まかな方向性、目標があることで、同じ方向性に探索をしていくことができる。
意思を持ち選択する
探索の方向性を決めるのは最終的には個人の意思である。
方向性が見えていても最終的にルートを決定するのは個人であるということ。
選択することはすごく辛いがみんなで不確実性を少なくしていく。
選択するということは、何かを選ぶと同時に何かを捨てるということであるが、意思をもつことでその選択の自信をつける、正しい（かについては分からないが）方向に進むことができるのだろうと思った。
探索の量は質に転化する
初めは何をすればより多くの情報を得られるかは分からない。しかし、探索の量を行うと、全容をつかむことができるため、質の高い探索ができる。
プログラミング始めた時にタイポで１時間溶かした経験は一つ一つのコードをみるようになって、どのように動いているかを把握できて無駄じゃなかったんだなと考えてみれば今に繋がっている気がしてなるほどなと感じた。
T字でなく山のような専門性
問題の本質は複数の領域に繋がる。理解の深いところを中心にその周辺分野を知らなくてはいけない。
= Connecting the Dotsの話にちょっと近いと感じた。
テックカンパニーはアジリティを高められる組織
- 自分の意思ももつ
- 探索し続ける
- ソフトウェアを中心に考える。
内容をnoteにまとめてくださっています。
技術で解決するとは何か〜KADOKAWAグループで実践している基盤提供とデータ分析の事例紹介〜
技術で解決するとは何か
「問題から真の目的を導き出し、資源の制約下で、目的を達成するための仕組みを構築する」
本当にこの通りだと思います。デザイン思考とかの考えでも表層的な問題ではなくその下にあるモノとは何をするためなのかとか考えたりしたなというのと似ている気がします。問題の解決は、仕様通りに作って解決するのではなく、問題のそのものを意識して解決することなんだなと思いました。
- 周囲の人が抱える問題を聞いてみる
- 問題から目的を決める
- 目的を達成するシステムを作る
- 周囲の人にシステムを作ってもらう
- 使った結果、残る問題を聞いてみる
- Goto 2
生まれた時間のもくもくタイム
一日１時間もくもくタイム（自由に色々試してみる時間）にするのをルーティンにすることで、技術者集団を作り、色々な価値を作る集団を作る。
ルーティンで新しいことを試す習慣はすごくいいなと感じた。自分も少しずつ自由な時間ができる時間を確保していきたい。一日１０分でもこういう時間があると変わってくるのかなと感じます。他にもニコニコ動画のシステム強化の話やエンタメはどこまでAI化できるかについての話なども出てきて面白かった。2017年から2019年のサーバーの入れ替えの時に全てのサーバーを捨てて、VMに入れ替えたのは英断だなって思った。確かに昔と比べてネットワークが安定したな感じます。
ものを書くときはだいたい下書きしていたり、授業のメモに使っているScrapboxの発明した増井先生の話たったので、今回楽しみにしていたセッションの一つでした。
コロンブス的発明
単純なんだけど、みんなが使いやすい＝コロンブス的発明
偉大な発明とは、案外当たり前だけど気づかなかったものが多い。論文を書くとすごく短くシンプルになる。簡単で便利で面白い発明がコロンブス的発明である。
- 問題の発見と解決
- 「問題発見・解決型教育」
- 従来の教育は知識伝授型
- 問題発見は難しい
- ボーっとしていると問題を発見できない
「ぼーっといきているんじゃねーぞ」ではないけど、普段見える世界の味方とそれ以外の違った見方が新たなアイデアの発想源何だなと感じました。
発想のプロセス
- 十分な知識を蓄える
- 解決したい問題についてよく考える
- しばらく寝かせる
- 突然思いつく
- 睡眠、シャワーなどによるきっかけ
- 忘れること
桜井和寿さんもお風呂とか何も考えてない時に、歌詞やメロディがぱって思いつくって言ってました🥴(コメントより）
ポールは夢で、メロディが生まれるしね。w（コメントより）
確かにリラックスしている時や、少し時間が立った時に何かしら思いつくことが多い気がします。いい感じのメロディはだいたいお風呂で思いつくもんなので、急いで着替えてボイスメモに入れ込む生活をしているので、すごくわかります。忘れることというのは、機械にはできない（最近のLSTMとは忘れることが擬似的に実装されている気もするが..)ので発想、思考には重要なんだなと思いました。
1部：21世紀型エンジニアの働きかた
エンジニアの未来は明るい
様々な分野でテック化の流れがあるため、２１世紀はエンジニアが不足する。
技術の裾野が広がり、技術の高度化と抽象化が進む。ノーコード、ローコードが進んで、誰でも技術が使えるようになる。７割の人がノーコード、ローコードで技術を使う人、残りの３割が技術を作り出す人になる。
活躍する人とは
- 技術への知的好奇心
- やり抜く力
- オーナーシップ
- チームワーク
活躍する人は技術に何しては知的好奇心のみである。
年収よりもライフタイムバリュー志向→ 21世紀型エンジニア
自分がどのようになりたいか、どのような価値の人間になりたいかを特に考えなくてはいけない。若いうちに技術的基礎力をつけて、どのように成長するか、チャンスを掴み次へと繋げるかについて考えることが重要だと感じました。
2部：［緊急企画］学生参加型 生ライブ！若手6人のぶっちゃけトーク
新入社員がすごくぶっちゃけていて、なかなかリアルな声でした。
技術レベルは、すごい人はすごかったが、幅があって技術に強いからという理由で採用をしているのではないなと感じた。（ただ、ある程度の技術力は持って就職しているなという感想でした）
給料についての話はだいぶリアルで懇親会でもぶっちゃけていたなという話をしていました。「今の給料で満足しているか？給料を上げるために自分で何をしているのか？」という話は、これからどのようになりたいか、どう成長するかの姿勢についてにつながっていて、深いなと思いました。どんな目標があってそれに向かってどのようにしているかという意識はどう価値を作っていくかについて重要な考え方だと思いました。
人事の人がどう思っているか
採用責任者面接では、どういう価値観を持って生きているか、今後どのように活躍するかについてみている。足元の技術は見ていない。今後の伸び代を見ている！一番伸びそう、成長しそうなところに配属をしている。
採用の人はどの分野の人でも「どのような価値観を持った人か」を見ているなと思いました。「企業とのインターンや就活は、お見合いだ」という話を聞いたことがあったが、企業の考え方や価値観が合致する人を選んでいるなと思いました。
懇親会
今回、なかなか楽しみだったのが懇親会で3回で色々な人とお話しすることができました。同年代の学生がどのように勉強していているかについて、なかなか情報を得ることができなかったので、すごく参考になりました。「学生は井の中の蛙」という話で狭いコミュニティの中で生きていたんだなと感じます。
つよつよの人も多かったのですが、自分のように今回の技育祭が初めての参加という人も多く、情報系が専門じゃない人もいて、現在地点はみんな誰も近いものだなと思いました。（頑張れば自分も追いつけるかもしれない）
インターン行った経験のある方の話（ランチは美味しかったのかなど）色々聞けてよかったなと感じました。群馬県境行ってみたいものですね。
最後に今回、技育祭に参加して本当によかったなと思いました。全国の自分と同じような情報系の学生が3000人も集まって交流をするという機会はなかなかなかったのではと感じます。どの方も色々いいこと言いすぎていて情報量過多だったのですが、聞いた話の中で多くの人が、「Connecting the dots」に関連したことを言っていて、自分が面白いと思った方向に進んでいければ、大丈夫なんだなと感じました。
来年も参加したいです。
#技育祭 1日目に参加して思ったこと、かんそう
聞きながら取ってたメモを元にまとめて、自分が思ったことを書いていこうと思う。
内容が半端なく多い２日間だったので、内容よりかは、自分の思ったこと（感想ではない？）が中心になるのではないかと思う。
https://talent.supporterz.jp/geeksai/2020/
オープニングセッションCTOパネルディスカッションエンジニアを目指す君たちに伝えたいこと
AIを使わなくてもいいじゃん問題
AIを使わなくてもいいじゃん問題のビジネス的な観点の話が興味深かった。
AIなんか使わなくてもif文で実装できるのに、ビジネス的にはAIを使った方が利益が出ることがある、価値があることがある（ビジネス的に）というのが印象に残った（おそらくツイートしている）
AI（ニューラルネットワークの機械学習）を使うべきか問題について、ちゃんとどこで使えるかを見極められるエンジニアになるという話は以前どこかで聞いたことがあったが、ビジネス的な視点も入ると歪みが生じることがあるという話。
AIでIoTを5Gでシンギュラリティ（コメントより）
名前だけかっこいいけど内容ないやつ。
ロールモデルは重要か
なりたい人の方向についていったら以外といい感じにいけるとのこと（ほんと？）
松本さんが言っていた、他人の思考トレースは面白い考え方だなと感じた。
思考パターンを自分ではなく、自分から離れて客観的に違った見方をする。そのような時に思考のトレースは有効で面白いのかなと感じた。
面白そうって重要
いろんなところで言っていたなと。
面白そうで動いても、結局は自分の行動なので、一つの法則性（軸）みたいなものが生まれるのかなと思う。文系のみんながやっているらしい自己分析は、好きなもを一覧にして関係性を適当に見つけたらある程度考えられるらしい。（大学3年になったらSPSS！！！という概念が存在しない世界線にきてしまっているのでここら辺はよくわかりにくい）
Withコロナ時代のテクノロジーとの向き合い方〜エンジニアを目指すキミたちに今、伝えたいこと〜
カメラとマイクにはお金をかけろ！！
自分もオーディオ系はオーディオIF使ったり人よりいいと思っているが、ケタ違いだった。
大学1年生の高校4年生化
この問題は、特に身近で顕著だなと思う。
ひたすらwhy？を言い続けてこれから脱却して、自分で考える力、答えのない答えにたどり着く力が必要なんだと思う。
物事にとらわえずイキリおじさんにならない肩に力が入っていないエンジニアになる
ただ好きなことを自分のペースでやっていくことが一番重要
→「好きこそ物の上手なれ」ってやつですね。
これからの時代に必要な技術力とは
プロダクトカンパニー
プロダクトをリリースして認めてもらえる。
見せてもらった動画の熱気がすごくて、達成感以上に楽しそうと感じた。
起業した企業の１割がfreee使っているらしくて、すごい。お金計算は、まあまあ大変（ものを作って売ったことがあるので）なので、それが大きくなった企業のお金計算を自動化できたら、使いたくなる。
→ケーキ屋さんやりたい人は経営をやりたい人ではない
という人たちを助ける、経営の時間を減らしてクリエイティブにさせるというビジョンがすごくいい。
プロダクトを作るだけだとプロダクトカンパニーじゃ弱い
→なぜそれが役立つのかを、サイエンス的に検証できるかが重要！！！！
（他の方も同じような話をしていたと思う。）
なぜこの技術を自分たちの会社で作るのかということを考えなくてはいけない
学生向けの部分
色々やっていきたいというパッションからの行動が大事！！
やるぞ！と思って成果を出せた経験が役に立つ。
10年後の自分をつくる〜はてながインターンで学生たちに伝えていること〜
アウトプットをしよう！！！
アウトプットすることで成長できる！
（人に教える時には、１０を知って１を教えるというのを、文化祭の展示の時に意識していた記憶がある）
アウトプットできる環境づくり、アウトプットをしやすくする文化！！
ということでほぼ衝動ではてなにもブログを書いている。
うごメモ世代なので、なかなかコメントが同世代で楽しかったです。
プログラミング楽しい！ (Azure 入門)
ちょまどさんの話、何回聞いても面白い。椅子くるくるとか、転職に悩んだ時間３秒とか...
最近Azureやべーってなって、色々いじってみて、なんか楽しいなとなっている。バックエンド系のことをほとんどやってくれているので、サーバーたてるのも、アプリケーション作るもの、フロントエンドの特に始めやすいところだけで作れる（ノーコード）なので、楽しくいじれていいなと思って、友人に布教し始めてる。
Connecting the dots
同時間にmatzさんも言ってたらしく、他の公演でも似たようなことを言っていたという印象のこの言葉。
好きなことが繋がっていって、最終的に一つになるというキャリアがおそらく最強で最高の生き方なんだなと思った。
→scrapbox的考え方に近い？？？
どれも内容深くて、濃いので体力と脳みそのCPUが間に合わなかった。
という感想です...
アウトプットを初めてみたかった
自己紹介・ブログの位置付け
こんにちは、yamaです。色々なHNでDTMやっていたり、プログラミングで遊んでいたりしています。
はてなブログでは、Qiitaとは違う思考的なことを書きたいかなと思います。
Qiitaは、すでにある技術についてのメモ、作ったものの過程の保存。こちらは、思ったことをソースもなくだらだらとかく内容にしようかなと。
なぜかnoteもやっているので、そこらへんとの分け方が難しい気がするが、どこに書くかは気まぐれな気がします。（noteではトマトの美味しさについて主に書いています）
アウトプットを初めてみたかった
「アウトプットアウトプット」と言われ続けて、だいぶ経ちましたがなかなかむづかしいなと感じていて、なかなかレポートに追われて追加で文字を書く時間が少ない気がするので、電車の中で書いたメモとかを元に感じたことを書いていく形かなと思っています。
インプットとアウトプットの関係は、「知ること考えること」という昔聞いた話と同じで、学ぶことのおもしろさ、本質なのかなと最近感じる。
知識を得るだけでは、テストで１００点取れる「知識バカ」になって、コンピュータの無限に覚えられる記憶力に負ける。
だから、知った知識からどのように考えるかということが学ぶことで一番重要だというお話。
このお話は、中学1年の時に学校に「思考の整理学」の本で有名な外山 滋比古先生が講演していた話で、8年ぐらい経って、ようやくその重要さを実感し始めてる。
メタノートという考え方は、「思考の整理学」の中で紹介されている非常にアナログな考え方で、2回か3回考えていい感じに忘れた思考をメモするノートです。自分は完全にスマホ第１世代だと思っているので、そっくりそのままはやりませんが、デジタルになってもやっていることは同じ思考のパターンなので、書いて残すことでアウトプットができるのかなと。そんな感じでやっていきます。
