マルチタスクを支える技術

はじめに

昨今の生成AIブームの盛り上がりに伴い、皆さんもAIエージェントに自分のやっている作業と並行して複数のタスクをお願いする機会も多くなったのではないでしょうか。

今回の記事ではマルチタスクを効率的に実行する方法について、自分が心掛けていることを心構え・準備・実行の3つのステップに分けて解説します。ぜひ皆さんもこの記事を参考にして自身の生産性のアップやAIエージェントを効率的に使いこなすために役立てていただけたら幸いです。

1. 心構え

マルチタスクをしない

まず、マルチタスクを効率的に実行するための心構えとして大事なことは「マルチタスクをしない」ということです。本末転倒に聞こえるかもしれませんが、自分の思想はシングルタスクを1つずつ地道に実行するのが結果として最も早いというものです。

その思想を実現するための準備や実行についてのノウハウを次節以降で説明していきます。余談ですが、「世界一流エンジニアの思考法」という書籍の中でも同様の考え方が書かれています。

世界一流エンジニアの思考法 | 牛尾 剛 |本 | 通販 | Amazon

2. 準備

タスクリストをドキュメントで管理する

シングルタスクを1つずつ地道に実行していくために重要となるのはタスク管理です。TrelloやAsanaなど専用のタスク管理ツールを使用するのも良いですが、自分はドキュメントツールを利用してタスクを管理しています。最初はGoogle Docsで始めたのですが、今は生成AIの台頭もありCursorを使用してマークダウンで記述しています（AIを使った自動化や内省などは特に実施してません）。

ドキュメントでのタスク管理の例

自分はタスク管理を実施する上で、ドキュメントを自分のもう一つの脳（外部記憶装置）として使うイメージを大事にしています。自分の頭の中にあるタスクリストをドキュメントに書き出して、書き出したら一旦そのタスクのことは忘れることで、目の前の作業に集中できるといった具合です。

また1日ごとにタスクリストを区切っているので、1日の初めにその日をロールプレイしてみるといったことも実施しています。タスクリストにはミーティングなどのスケジュールも含めて書き出しているので、ある作業を実施するには別の作業も必要であったり、ミーティングまでにこの作業を終わらせておく必要があるといった依存関係の整理や作業の抜け漏れチェックとしても活用できます。

タスクは1 ~ 2時間以内に終わるサイズまでを分解する

プロダクト開発におけるバックログでも同様ですが、タスクサイズが大き過ぎると考えなければいけない範囲が多くなり、着手するのが億劫になったり、なかなか進捗している感を得られなかったりすることがあるかと思います。

そこで当たり前のことではあるのですが、自分はタスクのサイズを1 ~ 2時間以内に終わるサイズまで分解するということを習慣にしています。マークダウンで箇条書きを使えばタスクの分割も簡単にできるため、タスク管理をドキュメントでやっている理由の1つです。

不確実性の高いタスクを優先して実行する

次はタスクの優先度付けの話です。タスク管理して順調にタスクをこなしているつもりが、思ったより進んでいない場合は優先度付けが間違っている可能性が高いです。人は楽な方向に流されてしまうものなので、意識して優先度付けをしないと簡単に終わる（不確実性の低い）タスクばかりをこなしてしまいます。

不確実性の高いタスクは分解や検証が必要であったり、手戻りが多いタスクとなるので、時間に余裕のあるうちに実行しておかないと、後になっては取り返しがつかない状況になってしまう可能性があります。そのため、余裕のある午前中や週初めの早い段階で難しい（不確実性の高い）タスクに取り組んでおくことが重要です。

また、自分が大学生の時にインターンをしていた会社の上司に「自分からの距離感を意識して仕事をするといいよ」と言われたことがあります。具体的には社外の取引先を巻き込むタスク、社内の同僚を巻き込むタスク、自分で完結するタスクの3つがあったときに、自分との距離感が遠い社外 > 社内 > 個人の順に優先度を付けると良いといったものです。これも自分との距離感が遠いということは不確実性の高い一因になるので、同じようなことかと思います。

3. 実行

シングルタスクに集中する

タスクの実行時には1つのタスクに集中して他のタスクのことは考えないようにしましょう。それだけです。

3分以内に終わるタスクはその場で終わらせる

業務中に口頭やチャットツールで質問を受けたり、タスクを依頼されることがあるかと思います。自分は3分以内に終わらせることができそうな質問やタスクはその場で終わらせてしまうことを意識しています。後でやろうとすると、タスクリストに追加する手間が発生してしまったり、他のタスクと思考を行き来するスイッチングコストが掛かってしまうので、すぐ終わりそうなタスクはその場でやってしまうのが結局は1番楽です。

終わりに

今回の記事ではマルチタスクを効率的に実行するための、心構え、準備、実行について簡単に解説してきました。

この内容は自分にとっては最適なものではある一方で、すべての人に使える内容かと言われるとそうではない気がします。自分もポモドーロテクニックなどの時間管理術を試してみたことがあるのですが、自分は時間で区切るというよりもタスクで区切るという考え方の方がしっくりきているので、全く合わなかったという経験があります。

なので今回の記事を見て、1つでも参考になる箇所があったり、自身のマルチタスクについて改めて考えるきっかけになってくれたら嬉しいなと思います。

頑張れば手に入るレアな日本ワインの入手方法（随時更新）

2023年にワインエキスパートを取得してから、日本ワインに興味を持つようになりました。自分が今暮らしている地域や土地でワインが作られていることに想いを馳せたり、観光のついでに有名なワイナリーを訪れたりと海外のワインとは違った楽しみ方ができることが日本ワインにハマるようになったきっかけです。

日本のワイナリーは海外のワイナリーと比べて小規模な生産者が多いため、生産量が少ないことが多いです。そのため人気なワインはすぐ売り切れてしまったり、入手困難になってしまいます。そこで今回は日本ワインに詳しくない人でも人気なワインを飲む機会が少しでも増えればと思い、人気で入手困難ではあるが頑張れば手に入る日本ワインを紹介したいと思います。

Kidoワイナリー

まず1本目は長野県塩尻市にあるKidoワイナリーです。映画「ウスケボーイズ」にもワイナリー当主の城戸さんをモデルにした人物が登場しています。

Kidoワイナリーではワインの販売方法は抽選となっており、ワインの種類によって年3回抽選が開催されます。抽選時期は春（4月中旬～下旬頃）、夏（7月中旬～下旬頃）、秋冬（11月下旬～12月初旬頃）となっており、抽選の形式や応募方法はHPで発表されるため、期間が近づいたら頻繁にHPをチェックするようにしましょう。ちなみに自分は今まで5回応募して2回当選という結果でした（ワインの種類によっても違うかと思いますが、倍率は2〜3倍くらい…？）。

sites.google.com

ドメーヌ・ミエイケノ

続いては山梨県北杜市、八ヶ岳の麓に位置するドメーヌ・ミエイケノです。神の雫というワイン漫画にも登場したワイナリーで、自分が初めてドメーヌ・ミエイケノのピノ・ノワールを飲んだ時は日本でこんなワインが作れるんだと感動した記憶があります。

ミエイケノのワインはオンラインストアでの先着順の販売になっています。例年だと6月に前年のシャルドネ、メルロー、ピノ・ノワールの3つのワインがリリースされます。また、12月には月香シャルドネという月の輝く夜、静まり返った畑で収穫（ムーンライトハーベスト）されたブドウを使ったワインがリリースされます。オンラインストアでの販売開始日や時間については、リリースが近づくとHPに掲載されるので、頻繁にチェックするようにしましょう。ミエイケノのワインはとても人気が高く、開始30分もすると売り切れてしまうことも多いので、できるだけリリース時間ちょうどを狙ってアクセスするようにしましょう。

www.mieikeno.com

GRACE WINE

お次は日本を代表するワイン品種である甲州に定評のある山梨県甲州市のGRACE WINE（中央葡萄酒）です。

GRACE WINEでは通常のワインはオンラインショップでも販売していますが、フラッグシップワイン（そのワイナリーでの最高品質のワイン）に関しては、HPからウェイティング・リストに登録したメンバーにのみ案内が送られるといった形態を取っています。例年1月に郵送でワインの案内が届くので、今のうちにウェイティング・リストへの登録を済ませておきましょう。

www.grace-wine.com

ラ・グランド・コリーヌ・ジャポン

次に紹介するのが、岡山県岡山市のラ・グランド・コリーヌ・ジャポンです。フランスのローヌでワイナリーを営んでいた大岡さんが岡山で立ち上げたワイナリーで、優しい味わいの自然派ワインが特徴となっているため、ワインをあまり飲んだことがない方にもおすすめです。こちらのワイナリーは書籍を通して知ったのですが、その書籍自体が読み物としても面白いので興味のある方はぜひ読んでみてください。

https://amzn.asia/d/1DDM8Zi

ラ・グランド・コリーヌ・ジャポンではHPからメール会員登録をしたユーザーにのみワインの販売を行っています。例年12月にメールで案内が届く形式になっているので、今のうちから登録を済ませておくのがおすすめです。

www.lgcj.jp

おわりに

今回の記事では頑張れば手に入るレアな日本ワインの入手方法を4本紹介しました。自分自身もワインを意識して飲み始めるようになったのはまだ最近で4本しか紹介できませんでしたが、仕入れた情報は随時更新していけたらと思っています。少しでも日本ワインに興味を持つきっかけになってもらえれば幸いです。

採用でオファー時に大事にしていること

お久しぶりです。

前回はてなブログを再開するというブログを書いたのですが、それ以来約1年ぶりの更新になってしまいました。 今月から週に1時間ブログを書く時間を取っているので、雑でもいいので備忘録的に書いていきたいです。

mitsuruya.hatenablog.com

今回は、直近会社に入社した同僚にオファー面談が良かったと褒めていただいたので意識していることを書いてみます。 オファー面談を担当している方をはじめとして、採用に関わる方にとって何かの参考になれば幸いです。

はじめに

最初に自分がオファーをする上でとても参考にしている記事を紹介します。

以下の記事では、dely株式会社のCTOである大竹さんがCPOである坪田さんに送った手書きのオファーレターが一部を除いて公開されています。 オファー時に必要な要素であったり、本気度を伝えることの大切さが伝わってくる内容です。

オファーまでの流れがストーリーとして書かれているので、純粋に読み物としても面白いです。

www.fastgrow.jp

オファーで大事にしていること4選

次に自分がオファー時に大事にしていることを4つ紹介していきます。

1. 期待値を伝える

オファーでは会社や組織の方向性と候補者のキャリアの方向性を擦り合わせていくことが何より重要だと考えています。社内のエンジニアのメンバーを見ていてもここが擦り合っているメンバーはいいパフォーマンスを発揮していることが多いですし、自分はメンバーとの1on1をする際にこれを1番の目的としています。

加えて期待値は短期、中長期の2つに分けて伝えるようにしています。

2. 相手に合わせる

オファー面談では話している項目自体は決めているのですが、候補者によってどこを重点的に話すかは変えています。

例えば、好奇心旺盛で新しいことをどんどんやっていきたい方に対しては今後の会社やプロダクトの展望や中長期の期待値を厚めに伝える、目の前のことを1つ1つ片付けていきたい方に対しては実際に入社時にやってもらうタスクや短期的な期待値を厚めに伝えるなどの工夫をしています。

3. 背伸びをしない

候補者の方からの質問をいただいた時に、こう答えたら敬遠されてしまうかなと思うことがよくあると思います。

確かに候補者にとって耳障りのいい言葉を話すことで短期的な採用の成果は上がるかもしれません。ただ、話したことと実態が異なると、短期離職を招いてしまったり、チームの崩壊といった最悪のケースに繋がってしまう場合もあります。採用は企業と候補者のマッチングなので、正直ベースで話してみて、それでダメだったら仕方ないと個人的には考えています。

4. 文章で伝える

オファー面談時に使っている資料は、最初は会社で使われていた資料を参考にしてGoogleスライドを使用していました。スライドは確かに見栄えはいいのですが、使用できる文字数が限られていたり、見た目に意識が向くので文章がダイレクトに伝わりづらいという課題がありました。

そこでNotionを利用してオファー面談の資料を作るようにしたのですが、準備の時間が削減できたり、自分の言いたいことをストレートに表現しやすいといったメリットがあり、個人的には変更してみてとても良かったなと感じています。

終わり

今回はオファー時に大事にしていることというテーマでライトな記事ではありましたが、久しぶりにブログを書くことができてよかったです。

これからも継続して書いていきます！

はてなブログを再開します

2016年の4月にエントリーを書いて以来、このブログには8年間全く投稿していなかったのですが、この度ブログを再開することにしました。

このブログはなんだったか？

このブログの初投稿を見てみると、2023年の12月7日でした。自分が大学の授業でWebプログラミングに触れて、プログラミングにハマり出したのが2013年の6月だったので、プログラミング始めたての自分が忘備録的に書いていたのが、このブログになります。

今読み返すと恥ずかしくなるような内容ばかりの記事ですが、アクセス数を見るとこんな記事でも少しは誰かの役に立っている実感が湧くのと、プログラミングに熱中していた当時の自分の気持ちが蘇ってきてとても懐かしい気持ちになれるので、消さずに残しておこうと思います。

またこのブログを書いていたおかげで、大学4年の当時にとある会社のエンジニアの方からインターンのお誘いを受けて、今の会社の代表と知り合ったというご縁もありました。

2016年以降の個人的な発信

2016年に記事を書いて以来、全く更新していなかったこのブログですが、自分個人としては会社のテックブログやnoteを中心に記事を書いていました。

• 記事一覧 - Gunosyデータ分析ブログ
• 記事一覧 - Gunosy Tech Blog
• 記事一覧 - mikan Developers' Blog
• 記事一覧 - PLEX Product Team Blog
• Jun Ishitsuka｜note

なぜはてなブログに戻ってきたのか？

個人の発信を振り返って、技術系のネタは会社のテックブログに主に書いていたので、個人の技術系のネタを書く場所が少ないというのが理由の1つです。それだとnoteやzennで良いのではという意見もありそうですが、noteはビジネスに寄り過ぎていてなんとなくゆるめのネタを書きづらい雰囲気があるし、zennだと技術ネタに限らず広く書いていきたいし、ということではてなブログに落ち着きました。

肩肘張らずに、定期的に継続して書いていけたらいいなと思っています。

シリコンバレーのIT企業が利用しているA/Bテスト手法まとめ

いま注目すべきシリコンバレーの有名なIT企業は新規のデザインや機能が有効かどうかを検証するためにA/Bテストを行っています。 その一方で、日本の企業も含め、A/Bテストを本番環境で導入している企業は非常に少ないです。 加えて、日本で言われているA/Bテストと海外で言われているA/Bテストは少々異なるものだと感じています。 日本のA/Bテストはフォームの最適化やデザインの修正にとどまっている一方で、海外のA/Bテストはプロダクト開発のサイクルの一部分となっています。

プロダクト開発のサイクルの一部としてA/Bテストを取り入れるためには、大量のテストを定常的に回していく仕組みが必要となってきます。 そこでデータドリブンであると言われているようなシリコンバレーのIT企業は自社でA/Bテストの基盤を作成しています。 今回は社内A/Bテスト勉強会で発表するために、シリコンバレーの有名IT企業がどのような手法でABテストを実施しているのかをまとめてみました。 ちなみに対象は以下の4社で、参考にしたのは各企業のブログがほとんどです。

• Twitter
• Linkedin
• Airbnb
• Pinterest

発表したスライド

各企業のA/Bテスト基盤における主な機能

シリコンバレーの各IT企業のA/Bテスト基盤について調べた感想は、部分部分で違った機能を提供してはいるものの、コアとなるような主要な機能はどこもちゃんと取り入れているなという印象でした。

下の表が機能一覧と導入している企業についてまとめたものです。これらの機能がどういったものなのかを簡単に説明していこうと思います。

※Metrics You FollowとCustom MetricsはLinkedinでしか用いられていない機能なのでここでの説明は割愛します。気になる人はスライドをチェックしてみてください。

• 自動集計
  • これは言わずもがなだと思います。手動での集計では手間がかかるため、どの企業もダッシュボードで数値を確認できるようになっていました。
• コホート
  • コホートはダッシュボード上で確認できる指標を国や性別、OSなどの属性ごとに見ることができる機能です。数値が変化していたときにそれがどの属性やグループで起こっているものなのかを簡単に確認することができます。
• Group Validation
  • Group Validationはテスト対象と比較対象のグループの割り振りが均等、もしくは意図した通りになっているかどうかをチェックするための機能です。裏側の仕組みにはカイ二乗検定が使用されています。
• t検定
  • t検定も全てのA/Bテスト基盤に用いられていました。テスト対象と比較対象の指標の値とp値が時系列で確認できるようになっており、p値が0.05以下になると棒グラフのバーが色付けされるようになっているシステムもあります。
• テスト期間
  • 検出力 (statistical power) が80%になるまでの期間を教えてくれる機能です。A/Bテストの終了までの期間をいつまでにするかの目安として役に立ちます。
• A/Aテスト
  • A/Aテストはテスト対象と比較対象に全く同じパターンを出す手法です。同じものを見せることでどのくらい値がばらつくのか、誤差の範囲なのかを確認することができます。また、AirbnbではGroup Validationのようにテストの割り振りが上手くいっているかのチェックにもA/Aテストを使用しています。

最後に

今回は社内A/Bテスト勉強会で発表させていただいた内容をブログにさせてもらいました。

この発表は社内向けのものとなってしまったのですが、社内外問わずにA/Bテストの知見を共有したり、みんなでA/Bテストの闇（落とし穴）を共有したりできる場を作れたらいいなと思っているので、勉強会の開催やA/Bテストに興味があれば@ij_spitzまでご連絡下さい！

デモグラフィック属性（性別・年齢）を予測する論文を読んだ

読んだ論文

Demographic Prediction Based on User’s Browsing Behavior

• Microsoftの論文（WWW2007）
• 引用数は145（2016/03/20時点）

Abstract

ウェブサイトの閲覧データからユーザーの年齢と性別を推定する

提案手法は次の3つのステップから成る

• デモグラ既知ユーザーのクリックデータからサイトの性別と年齢の傾向を推定する判別モデルを構築する
• ベイジアンフレームワークを用いてクリックデータからユーザーの性別と年齢を推定する
• デモグラ属性が近いユーザーは同じようなサイトを訪れるという仮定からスムージングを行う

Introduction

行動に基づくWeb広告は115%売上増、ブランド認知は3%高い

Problem Definition

Teenage: < 18
Youngster: 18 - 24
Young: 25 - 34
Mid-Age: 35 - 49
Elder: > 49

Demographic Prediction

協調フィルタリングはデータがsparseなため難しい

ユーザー属性を用いた予測は精度が悪いため、今回の手法を提案する

Webpages’ Demographic Tendency Prediction

Demographicが既知のユーザーのクリックデータからサイトのDemographic Tendencyを予測する

• Pr(c | wj) = Σ rij * ui(c) / Σ rij
• 10ユーザー以上に読まれなかったウェブサイトは信頼性に欠けるので除去した
• 手法はSVR
• 特徴量
  • サイトの単語データ
  • サイトの階層構造に基づいて、SVMで分類を行いカテゴリの素性を作成

Users’ Demographic Prediction

Pr(c | ui) ∝ Pr(c | {w})
               ∝ Pr({w} | c) * Pr(c)
               ∝ Π Pr(wj | c) * Pr(c)
               ∝ Π Pr(c | wj) * Pr(wj) / Pr(c) ∝ Π Pr(c | wj)

Demographic Prediction by Leveraging Similarity among Users and Webpages

サイトの数は膨大であり、ユーザーのクリックは少ないためスパースな行列が出来上がる

そこで推薦などにも有用な次元削減の手法であるLSI（SVD）を用いる

さらにユーザーとサイトの類似度を元に近傍の平均を取ってスムージングする

• Smooth Webpages’ Demographic Tendency Prediction
  • ベクトルのコサイン距離による類似度とサイトの単語内容による類似度からスムージング
• Smooth Users’ Demographic Prediction
  • ユーザーのコサイン距離が近いT個のユーザーベクトルの平均でスムージング

Conclusion

性別では80%、年齢では60%のF値での精度が得られた

予測精度としてはTeenageが47%、Elderが52%と低い

Feature Researchとしては職業や学歴、地域などDemographicの拡張を計画している

感想

性別推定は80%で比較的実用的なレベルだが、年齢推定は精度が60%と難しいタスクだなという印象。

スムージングで精度が20%ほど向上していて、推薦と同じようにスパースな行列をどうやって処理するかで精度にかなり違いが出てくる。

またTeenageとElderという分類しやすそうなものの精度が悪くなっているので、新たな特徴量を追加すれば若干精度は良くなりそうだと思った。

退職しました

TL;DR

新卒で入社したソシャゲの会社を1月末で退職することになりました.

今は有給を消化しながら, ブログを書いています.

2月からは六本木にあるニュースアプリの会社でデータ分析エンジニアとして働きます.

前職について

新卒で去年の3月入社だったので, 約11ヶ月間ほど正社員のエンジニアとして働いていました.

入社してから3ヶ月くらいは社内全体のインフラやシステムを見る部署にいて, 社内用サービスやツールの開発をしていました. ほぼ個人開発だったので, AWSのネットワーク設計からシステム構築まで経験できたことは非常に勉強になりました. また良かった点として, 使用する技術は比較的自由に選べたので, MEAN環境でのWEB開発でAngularやNode.jsに触れられたのも楽しかったです.

その後は分析の部署に異動して, 社内共通の分析基盤システムの構築, 集計用ツールの開発, 集計業務などをやっていました. 分析基盤は比較的大き目のシステムだったので, 設計してレビューの流れを繰り返しやらせてもらったことはとてもありがたがったです.

以下主な退職理由の抜粋.

• 切磋琢磨し合えるエンジニアや尊敬できるエンジニアがいなくなった
• 周囲のエンジニアとの技術ドメインの違い
• 今後のエンジニアとしてのキャリアを考えたときにデータ分析を強みにしていきたいと思った

新卒で入って1年も経たずに辞めるのかよとか言われそうですが, 内定をもらったときから考えるともう2年ほどになりますし, それから研究があったり色々な人にあったりと自分の進むべき方向もちょっとずつ変わってきたというのも感じていたので, 自分としてはちょうどいいタイミングだったのかなと思います.

これから

冒頭にもあった通り, 六本木にあるニュースアプリの会社で働きます.

会社を選んだポイントとしては,

• データ分析に強みを持っている
• 自社でプロダクトを持っていて分析を活かしたプロダクト改善ができる
• 技術ドリブンな会社である
• 一緒に働きたいと思えるエンジニアが多かった

という感じです.
今後ともよろしくお願いします.

P.S.
ブログタイトル変えました（・ω・）

社内LT会を開催してみた話

はじめに

皆さんもエンジニアならLTをした経験があったり, LTという言葉は聞いたことがあると思います.
よく勉強会やカンファレンスで行われているショートプレゼンのようなものです.

2015年の6月から社内LT会の開催を始めて, 今月のLTが4回目の開催でした.
今回の記事では, LT会を始めた背景や, どのように運営をしていったかという点について書きます.

参考. Wikipediaからの引用

ライトニングトーク（英: Lightning Talks）とはカンファレンスやフォーラムなどで行われる短いプレゼンテーションのこと。様々な形式があるが、持ち時間が5分という制約が広く共有されている。

背景

LT会を開催しようと思い至った背景として以下の3点がありました.

• 研修の内容を発表したい
• 社内のエンジニアの交流や勉強会が少ない
• ノウハウの共有が少ない

一つ目に, 僕は新卒入社だったので研修という名の個人プロジェクト（学んでいくスタイルの世で言う研修とは全然違います）をやっていました.
当然社内の方とランチなどさせて頂いたときに, 何してるの？みたいな感じで聞かれることが多かったので, この際LTで大々的に発表してしまいたいなと思っていました.

二つ目が社内のエンジニアの交流や勉強会が少ないという理由です.
会社の規模としては150人ほどで, プロジェクトも5つほど動いている会社なので, プロジェクト間の交流が希薄だなと入社してきた時に感じました.

最後がノウハウの共有が少ないという点です.
社内でWikiのようなものがなかったり, 社内の資産と言えるような技術があまりなく, 属人化している雰囲気がありました.
僕が個人でやっていた研修も, 他のプロジェクトとは技術領域がかなり違うものだったので, 研修でやっていた技術も共有できたらなと思っていました.

どのように運営をしていったか

LT会を開催するということは決めたものの, 勉強会を主催したりといった経験はなかったので, とりあえず情報を集めることにしました.
実際に開催されている勉強会やLT会に行ったり, Webで情報を探しました.
以下の3つの記事を参考にさせていただきました.

• 勉強会を半年運営して気づいた「強烈なリーダーシップで引っ張るのではなく、“場を創って提供する”リーダーシップもある」って気付かされた話 - Six Apart ブログ
• 勉強会を継続するために気をつけていること - Qiita
• 社内LT大会を開催しました！ - CrowdWorks Engineer Blog

特に参考にさせていただいたのは以下の部分です.

自分の好きなことをやる

自分は新しい技術が好きだったり, エンジニア文化のようなものが好きだったので, LT会という選択肢は間違ってなかったと思います.
またLT会なら個人が好きなことを話せるので, 参加者としても発表しやすいです.

仲間を見つける

参考の記事でも書かれているようにやはり一人で全部やっていくのは大変です.
告知や当日の司会, 会場準備, 買い出しなどやることはたくさんあるので, コアメンバーとして一緒にやってくれる人が必要です.
僕の場合は同期に協力を仰ぎました.
また以前勉強会を運営していた先輩からも助言をいただいたりしながら進めていきました.

無理はしない

開催頻度を考えるときに特に参考になりました.
当初は週1回や月2回なども考えてはみましたが, プレゼンの準備等も含めるとかなり大変になってしまうので, 結局1,2ヶ月に1回というペースに落ち着きました.

勉強会なんて、その気になれば来週からでもできる

これは本当に言葉の通りだと思います.
やる気のない人はいつまで経ってもやらないし, やる人はやります.

まとめ

LT会を開催してみて, 人が全然集まらず開催見送りとなってしまった悲しい時もありましたが, なんとか半年間で4回ほど開催することができました.
ある回で僕がクローリングについて話した時があって, それを聞いた先輩が後日, 「～のLTを聞いて, クローリングやってみようと思って, 勉強始めたよ」と言ってくれたことがありました.
些細なことかもしれませんが, 会社にとって少なからず良い影響を与えることができたと感じることができ, 行動することの大切さが身にしみました.
諸事情があって次回からのLT会の運営は同期に任せることになってしまったのですが, これからも続いてくれるといいなと思います！

2015年の振り返り

2015年の振り返りをしていなかったので, 今年も既に3日目ですが, 月ごとに軽く振り返っていこうと思います.
会社の都合上書かない方が良いこともあると思うので, ちょくちょく抜けていますが, ご了承下さい.

1月

卒論

2月

卒論発表, 卒業旅行で海外3カ国

3月

入社, 友達とサービスをつくるが失敗に終わる

6月

社内LT会の主催を開始, 人工知能学会, AWS Summit

7月

異動（働いていた部署がなくなる）, 友達とサービス開発を開始

10月

友達と開発していたサービスが失敗に終わる

12月

台湾旅行

総括

振り返ってみると, 昨年は失敗の年だったなということを身にしみて感じています.
友達と開発していたサービスが二本とも失敗, 入社してから入った部署もなくなる, といった非常に大きな失敗がありました.
個々の失敗は自分の中で腹落ちしているので, ここでは書きません.
最後に新卒で入社して感じた大事な事と来年の抱負を書いて終わろうと思います.

新卒で入社して感じた大事な事

• 挑戦をする（＝失敗をする）
• 当事者意識を持って, 成果にコミットする
• 考える（＝手を動かして書く）
• 専門領域を持つ
• 旅をする

来年の抱負

2015年はエンジニアリングの面ではたくさんの事を学ぶことができたと感じる一方で, データ分析や機械学習でのインプットが少なくなってしまった.
なので今年は特に統計モデリングや深層学習を中心にデータ分析を自分の強みにできるようにしていきたい.
そういった意味で来年は土台づくりの一年にしたいです.

Goオールスターズに参加してきた

10月11日の日曜日に, Goオールスターズという勉強会に参加してきました.

6つのセッションとパネルディスカッションがあり, とても内容の濃い勉強会でした.

懇親会のピザとビールもたくさんあって満足でした.

eventdots.jp

全体

全体としてはGoの思想や特徴といった話が思ったよりもたくさん出ていて, Goを使ったことのない人にも取っ付きやすい内容だったと思います.

Goの主な特徴としては皆さん仰られていましたが, だいたい以下の3つほどだったと思います.

• シンプルなビルドと単一バイナリによる移植性の高さ
• Goroutineによる並行処理
• 高速でリソース消費が少ない

21世紀のC言語とも言われていて, 発表していたメルカリの中の人はC言語で書いていたところを今だとGoで書いていると言っていました.

やはりちょっとしたツールや並行処理が求められるサブシステムのようなものに向いているようです.

ちなみにRustは21世紀のC++とスライドに書かれていました.

また自分はパッケージ管理にgomを用いることが多かったのですが, Goチームからの見解から判断するにバージョン1.5からリリースされているvendoringを使用したほうがいいとのことでした.

vendoringをサポートするGoの思想としては以下のような理由があります.

• ソースコードだけでビルドできるという利便性を重視
• バージョン1.xの間は互換性を重視
• Googleでの問題を解決することが最優先（依存側が追従 or ホスティングのパスで区切る）

パネルディスカッションではフレームワークの話題にもなりましたが, Goで作る規模のものならnet/httpで十分という意見が多かったです.

たしかに大掛かりなWebアプリをGoで書くというのは中々つらそうです.

ジェネリクスについてもインターフェースで十分という人が多かった.

Goによるモバイル・ゲーム開発

Goだけでモバイルアプリを作ろうというGo Mobileを使ったアプリ開発のセッションや, コミケでGo製ゲームを売った話というGo製のゲームエンジンを使用したゲーム開発のセッションもありました.

Go Mobileは開発スピードが早く2ヶ月前の内容が既に古い, ということも仰られていて, ライトなものを自分の趣味で作るにはあまり不自由しないが, 本番投入にはまだ早いとのことでした.

またGoの標準パッケージを使えるのも面白そうだなと思いました.

最後にじゃんけん大会で頂いたGopher君のぬいぐるみ

意外とかわいい。。