Mi in progress

研究者の道ではなく、エンジニアになることを決意した人のブログ。

SmartHRさんのエンジニアの入社歓迎会の練習をする会に行ってきた

概要

昨日はSmartHRさんのエンジニアの入社歓迎会の練習をする会に行ってきました。

smarthr.connpass.com

入社歓迎会の練習に参加する経験は、もしかしたら後にも先にも今回だけかもしれないので、思ったことを書き留めてみました。

ここがすごいよ入社歓迎会練習

歓迎の本気度

  • 受付で名刺とTシャツのプレゼント
  • 盛大な拍手で自席へ案内される
  • 参加者全員で自己紹介
    • 自己紹介のテンプレが「前職は...」「SmartHRに入社したきっかけは...」とガチっぽい
  • 第一回SmartHR入社おめでとうクイズ大会開催

f:id:mi_progress_oOo:20180613005536j:plain

完全に歓迎会だった。私SmartHRに入社するのかと錯覚した。

とにかく面白い

  • サイゼリアでガチコース料理
  • サイゼリアに超絶詳しい社員さんがいる
  • クイズ大会の最終問題が「SOはなんの略か?」でサイゼリア・オリーブオイルが答えだった
  • クイズ大会の優勝チームにサイゼリア・オリーブオイルがプレゼントされる
  • カブもプレゼントされる
  • 社長さんが爽やかにSOとカブをプレゼントする

参加者も面白い

  • 一緒の席になった人がRust界隈のフォロワーさんだった(これは本当に偶然でびっくりw)
  • RustとKotlinの話で盛り上がった
  • 抽選に外れた人たちが「歓迎会の練習の練習」をやっていた

まさか入社歓迎会の練習でRustの話をするとは夢にも思ってなかったです...

総括

想像以上のクオリティで歓迎して頂き、最初から最後まで楽しくて仕方なかったです。
本気の入社歓迎会練習ごちそうさまでした😊

おまけ

今日芹澤さんのログミー記事がバズってました。

logmi.jp

芹澤さんと開発チームの作り方について語りたかったです(´;ω;`)

「社員数に対して部活がめっちゃたくさんある」という話で盛り上がって終わりました😂😂😂

優秀で気さくなエンジニアの皆さんと一緒に働きたい方はぜひ、SmartHRさんにお話を聞きに行ってみて下さい!

【再録】Research Fund 2.0 - 新時代の研究費事情 - を終えて

この記事は、TGSW2016でオーガナイザーを務めたセッションの議事録を再録で、内容自体は2016年10月時のものです。

もともとはMicrosoft OfficeのDocs.comに公開していたのですが、2017年12月15日に廃止されていたのを今日知りました。
ずっとリンク切れのままにしておいたなんて恥ずかしすぎる😇
とても思い出深いセッションでしたので、こちらに再録という形で公開させて頂きます。

TGSW2016 ... 2016年9月18日につくば国際会議場で開催された筑波大学主催の国際シンポジウムです。

Research Fund 2.0 - 新時代の研究費事情 - を終えて

それは、新たな時代の幕開けでした—

近年、技術の進歩や社会の変化によって研究費を獲得する手段が多様化してきました。科研費や財団といった大きな団体のみから研究費を獲得してきた時代をResearch Fund 1.0というならば、一般の個人や中小企業から研究支援を受けることが容易となった現在は、Research Fund 2.0と呼ぶことができます。本セッションでは、様々な形で研究費に携わっている専門家を招聘し、Research Fund 2.0という時代の全貌を明らかにしました。

今回は、密度の濃かった3時間を更に濃縮した、とびきりのエッセンスを主催者目線で以下に書き起こしたいと思います。

f:id:mi_progress_oOo:20180609215437j:plain

1st 国から得られる研究費 – 加藤英之氏 (筑波大学 URA研究戦略推進室)

トップバッターは筑波大学URA研究戦略推進室の加藤英之氏。

URAとは、University Research Administratorの略で、研究者とともに研究活動の企画・マネジメント、研究成果活用促進に従事する人材のことを指します。加藤氏には、「国から得られる研究費」をメインテーマとして、学問活動を支える経済構造を分かりやすく紐解いて頂きました。

学問の成果として国民が受け取るものとは

国から得られる研究費といえば、科研費が一番に思い起こされます。科研費の財源は主として税金ですが、税金を科研費に使うことで国民には一体どのような恩恵があるのでしょうか。

この答えとして「豊かさ」が今回提示されました。豊かさは、簡単に数値化できるような経済的な効果だけではなく、心や精神、文化的な意味も含まれるそうです。例えば、オリンピックで日本選手たちが金メダルに輝くと、日本中がわっと盛り上がりますよね。「日本の選手ってやっぱりすごい」「同じ日本人として誇りに思う」このような心理的効果が、科学技術の発展にもあるということです。

日本国民としての誇りを豊かにする、こういった意味での「豊かさ」は普段着目されないので、今回のお話はとても新鮮でした。

公的資金の重大な危機を打開する多角的戦略

基礎研究から応用研究まで、ありとあらゆる学問領域を支える科研費。今それが重大な危機に瀕しています。

日本の税率が全体的に低下しているため、税金として入ってくる国のお金が少なくなっているのです。その分お金は富裕層に貯まっていき、彼らが金融機関に預けた貯蓄を国が国債として借りています。国債は借金だから緊縮する必要があると一般的に考えられているため、科研費を削減していこうという流れになったわけです。

このような危機的状況にあって、研究者はこれからどうしていくべきか。

シンポジウムの初めを彩る、見事な締めの言葉で加藤氏はご講演を終えてくださいました。

「これから講師の方々に解決策を伺い、今後どのようなことをしていけばいいか考えていきましょう。」

f:id:mi_progress_oOo:20180609215513j:plain

2nd 民間助成団体から得られる研究費 – 長谷川均氏 (株式会社ジー・サーチ)

続いてご登壇頂いたのは株式会社ジー・サーチの長谷川均氏。

長谷川氏は、コラボリーという日本最大級の研究助成・奨学金検索サイトを手かげていらっしゃいます。コラボリー誕生秘話や民間助成金の裏話など、普段知ることのできないような民間助成金事情を教えて下さいました。

コラボリーとは

マッチングによって日本のサイエンスを加速したい。

その一心でスタートさせたのがコラボリー/Grantsでした。これまで扱ってきた事業内容とは異なり、初めは何もかもが手探りだったため、長谷川氏は助成財団や大学の研究推進部をたくさん回ったそうです。ヒアリングの結果、以下のような問題点が浮き彫りとなりました。

  • 助成財団側: 運営を支える常勤職員が少なく、広報まで手が回らない。主な広報手段は、大学へのポスター送付、メルマガ配信やWebサイト告知で、助成財団を知らない新規研究者からの応募を獲得するのが非常に難しい。
  • 研究推進部側: 情報収集が捗らない、専攻や研究科の間での情報流通が乏しい。

これらの問題点を一挙に解決するべく、コラボリー/Grantsでは詳細な条件で自分に合った助成金を探すことが可能となっています。

民間助成団体は若手を応援したい

長谷川氏のお話でとても印象的だったのが、民間助成団体は実績よりアイデア重視で申請書を選んでいるということでした。今では何億という科研費を稼いでいらっしゃる先生方も、若い頃は少額の民間助成金から挑戦していき、実績が増えたら大きな科研費に挑戦しているそうです。

そんな若手の味方である民間助成金ですが、採択率が低いという印象が強く、「応募しても採択されないのでは?」と感じている若手研究者のみなさんもいらっしゃるかと思います。実際に、トヨタ財団は4.6%、稲盛財団は10%ほどの採択率で、科研費よりも低いです。

しかしながら、財団の中の人から言わせれば「実際の」採択率は高いそうです。というのも、財団が掲げている目的に目を通さずに、他で落とされた申請書をそのまま使いまわした申請書が多く、そのような申請書を除けば、実際は4, 5倍の倍率で採用されているとのことです。

財団の多くが、自財団の助成金が掲げている目的に関する問い合わせを受け付けていますし、中にはプログラム・オフィサーを設けているところもあるそうなので、困ったらぜひ問い合わせてみて下さい、と長谷川氏はアドバイスされていました。

f:id:mi_progress_oOo:20180609215537j:plain

3rd クラウドファンディング – 柴藤亮介氏 (アカデミスト株式会社)

ここからは、新興の研究費獲得方法についての講演です。初めに、アカデミスト株式会社の柴藤亮介氏から、Research Fund 2.0においてクラウドファンディングがどのような位置づけで、アカデミアの発展に貢献できるのかを中心にお話して頂きました。

アカデミスト誕生秘話

アカデミスト株式会社では、日本初の学術系クラウドファンディングサービスを展開しています。クラウドファンディングとは、クラウド(群衆)とファンディング(資金調達)を組み合わせた造語で、何かを成し遂げるために不特定多数の人からお金を集めることを意味します。アカデミストでは、研究費を一般の人から集めることができます。

このような革新的なサービスを興すきっかけとなったのは、柴藤氏が物理学を研究していた学生時代に、「他の人はどんな研究をしているのだろう?」と疑問に思い、お互いの研究分野を紹介しながら飲む交流会を開いたことだったそうです。

学生同士の交流会にとどまらずに、研究の魅力を外へ発信するような場所を作りたい。アカデミストは、柴藤氏が築きあげてきたアカデミアと社会を繋げる架け橋なのです。

Research Fund 2.0という時代の真骨頂

Research Fund 2.0とはいかなる時代なのか。主催者である私は短絡的に「一般の個人や中小企業から研究支援を受けることが容易となった時代」と定義しました。

しかしながら真骨頂は別の部分にあることを柴藤氏は語って下さいました。

それは「研究のオープン化がインターネットによって容易になった時代」であるということです。オープン化というのは単純に「研究内容」が世間に遍く知れ渡ることだけではなく、「研究者自らの発信」が遍くことを指します。

これはResearch Fund 1.0の時代にはなかったことです。大抵の人は、研究内容を目にするのは新聞や大学公式Webサイトだったのではないでしょうか。

ましてや、その研究をしている研究者と直接関われるとは夢にも思わなかったと思います。それがクラウドファンディングを通すことで、研究者は国や財団の方針でアイデアを抑えることなく発信でき、支援者は気軽に研究者と話すことが可能となりました。

f:id:mi_progress_oOo:20180609215519j:plain

4th 寄附 – 渡邉文隆氏 (京都大学iPS細胞研究所基金グループ)

続いて京都大学iPS細胞研究所基金グループの渡邉文隆氏より、研究を支える寄附とはどんなものであるのか、事例を交えて説明して頂きました。

渡邉氏は日本で数少ない研究所専属のファンドレイザーで、非常に先駆的な基金事務局運営をされていらっしゃいます。

研究を長期的に支える寄附金

iPS細胞研究所では現在(※2016年9月当時)395名が教職員として在籍しています。

「研究を医療の現場に、必ず持っていくんだ」という山中伸弥教授の強い目的意識を共有して研究しているそうです。

日本の叡智が集うこの場所で、正規雇用で在籍しているのはたったの30名(※2016年9月当時)。信じられないことに、9割の人が任期付きの非正規雇用です。どうしてこのようなことが起こるのでしょうか?

それは、獲得している財源のほとんどが期限付きだからです。長期的な雇用を実現するための受け皿として、渡邉氏が資金調達を受け持つiPS細胞研究基金は非常に重要な存在と言えます。

人件費の面で研究を支えるということは、研究そのものだけではなく、その研究に携わる人の生活を支えることでもあるのです。

寄附金を始めとした長期貯蓄可能な財源を有する大学や研究機関は、そうでない大学や研究機関と比べて、安定的に研究を行うことのできる可能性が高まるため、若手研究者の就職先として相対的に良いのでは、ということも説明して下さいました。

寄附金を募るときの心構え

続いて、個人から企業まで様々な人から寄附金を募るにあたって、寄附者に誠意ある対応をすることが重要であると伝授して頂きました。

  • たくさんの寄附が集まってきたとしても、その一つ一つに丁寧な対応ができる事務処理体制を整えること。
  • 風評等にセンシティブな寄附者感情への配慮ができること。
  • 反社会的勢力と接点を持たぬよう徹底的にリスク管理に慎重になること。

部局全員でこれらの意識を共有して持つことが大切だそうです。寄付文化はまだまだ日本では浸透していませんが、これから大学や研究機関にとって非常に重要な財源になることは間違いないでしょう。

研究機関の基金事務局を正しく運営するためには、寄附者への配慮ができて、なおかつサイエンスも理解できる能力が不可欠です。ファンドレイザーを専門とする人財の育成が、日本のアカデミアの課題かもしれません。

f:id:mi_progress_oOo:20180609215543j:plain

5th 企業と研究者を直接つなげる – 坂本真一郎氏 (株式会社リバネス)

最後に、株式会社リバネス坂本真一郎氏から、同社設立のきっかけや、不採択となった申請書を産業界で活用することを目指すプラットフォームL-RADについて詳しくお話して頂きました。

株式会社リバネス設立のきっかけ

リバネスは2002年に理系の修士博士の学生たちで設立した会社で、「理系の学生もビジネスの勉強をしないと会社でやっていけないのではないか」という不安から毎週勉強会をしていたものの、「実際に自分たちで経営してみないとわからないね」という結論に至ったのが起業の発端だったそうです。

会社の理念である「科学技術の発展と地球貢献を実現する」べく、最先端研究と一般人を繋ぐ架け橋として、サイエンス・リテラシーの向上のための実験教室からスタートしました。

そこから、会社独自のPDCAならぬQPMIサイクルで会社を経営してきたそうです。

QPMIサイクルとは、Question, Passion, Mission, Innovationの頭文字を取ったもので、リバネス社員それぞれが持つQuestionとPassionを尊重し、生み出されたMissionからチームを作り、新たなInnovationを起こしていきます。そのためリバネスの事業領域は幅広く、会社経営支援からWEB漫画連載まで、十人十色のInnovationがあります。

坂本さんのPassion

研究者がもっと研究をできる環境を作っていきたい。

この熱いPassionのもと、坂本さんが最初に手掛けたのはリバネス研究費の設立でした。

2009年頃から始めたこの研究費は、これまで33回の公募で1億円以上の研究費を提供してきました。このような活動を進める中で、坂本さんは不採用になった申請書が二度と日の目を見ないことに勿体なさを感じるようになったそうです。

これはリバネス研究費に留まらず、科研費や民間助成財団でも同様のことが言えます。Aという公募の為に作成した申請書が落選した場合、別の公募Bに申請するためには、再び申請書を作り直さなければなりません。さらに、落選した申請書は誰も見ることができません。

また、研究の早い段階から研究を知ることが出来るのは共同出願がしやすくなるということで、企業側からもニーズがあることがわかりました。

そこで生み出されたのがL-RADというプラットフォームです。

L-RADでは基本情報(匿名)と詳細情報(実名)の二種類の申請書が用意されており、企業側は研究者のネームバリューに囚われることなく申請書を見ることができます。

さらに詳しく情報を見たいと判断したら詳細情報の閲覧ボタンをクリックし、以降はお互い実名でのやり取りとなります。

このようなサービスにおいて研究者側が最も懸念するのは「特許にならなくなる」「アイデアが盗まれてしまう」ことだと思います。

特許に関しては、リバネスをハブとして研究者と企業が秘密保持の規約を結んでいるため問題ありません。また、アイデアに関しても、企業側はリバネスと「L-RADの利用目的は共同研究先の探索に限定する」ことになっています。

一方、企業側にも知ってしまうリスクがありますので、匿名公開である基本情報の段階で、知るべきかどうかを判断できるようになっております。

研究者側と企業側の両方に寄り添った素晴らしいプラットフォームだと主催者は感じました。これからより一層普及していくことでしょう。

f:id:mi_progress_oOo:20180609215516j:plain

パネルディスカッション Research Fund 3.0に向けて

パネルディスカッションでは関西TLOの田部博康氏にも加わって頂いて、総勢8名でこれからの研究費事情について議論を交わしました。

産官学連携について

まずは産官学連携について、うまく連携させるためにはどのようなことが必要なのか、どのように進めて行くべきなのか、企業と大学を繋ぐTLOとしてご活躍されている田部氏からご意見を頂きました。

  • 田部氏(意見): 産官学連携において、大学側は0から1を、企業は9より上のことを行おうとするので、2から8の部分を誰が受け持つかで問題になります。具体的には、有用な薬が発明できたけど臨床実験は大学と企業どちらが受け持つのかということですね。ヒト・モノ・カネの部分を受け持つ場所が足りていないのです。

  • 柴藤氏(質問): 2から8を補うことができるケースはあるのでしょうか?

  • 田部氏(回答): 公的な研究資金で補えるケースはあります。応用研究に近いものですね。それから、企業様同士でコンソーシアムを作り、みんなでお金を出し合ってリスクを分散させる方法もあります。

  • 長谷川氏(質問): 産官学連携はなかなかうまくいっていないように思えるのですが、何か工夫はされているんですか?

  • 田部氏(回答): 模索中ですね。産官学連携への工夫は私自身のキャリアパスにも絡んできますし、「そもそも産官学連携のプロってなんなのだろう?」と日々考えています。

  • 渡邉氏(意見): アメリカでは2から8のところをベンチャーキャピタルが埋めていますね。ただ、最終製品の価格のところで投資に対する上乗せを行うので、価格が跳ね上がるという問題があります。

  • 田部氏(意見): 京大では150億円のベンチャー出資が行われましたね。

  • 加藤氏(意見): 産官学連携に興味を持っている人は少ないですね。日本の学問は伝統的に基礎学問が高尚で重要であると思われています。2から8の層を厚くしていくべきです。私はもともと基礎研究をやっていましたが、企業と共同研究をして「役に立つ」という観点で研究したことで初めてわかった基礎的な知見もありました。産官学連携の面白さを知った先生から発信してもらえばいいと思います。

  • 坂本氏(意見): 今日本のベンチャーキャピタルは10兆円くらいのファンドを持っていて、投資の勢いがありますね。リバネスとしても、面白いベンチャーを掘り起こして一緒に会社を興したり、ベンチャーと大企業をつないだりしていきたいと思っています。

研究費について

続いて、研究費について研究費を与える側、受ける側それぞれの意見を交換し合いました。まずは与える側から、研究助成における課題と展望についてお話をして頂きました。

  • 長谷川氏(意見): 財団の大きさによって事情は異なってきますね。大きな財団は毎年多くの募集があるので困っていません。むしろ、単に「お金がいい」からという理由で自分たちの目的にそぐわない申請書がたくさんくることに良い印象を持っていませんね。逆に中堅や小さい財団は、応募者の多様性がなくて困っていらっしゃいます。広報費にかけるお金が少ないので、同じ大学内でも一部の研究科でしか掲示されないということもあります。

  • 加藤氏(意見): 小さな財団が集まってコンソーシアムを作り、業務をシェアすることでコストを削減できるのではないでしょうか。各々の財団の思いやビジョンはそのままで。

  • 長谷川氏(意見): おもしろいですね。似たようなことを考えたことがありますが、なかなかハードルが高いです。電子申請の設備もないですし、財団毎のフォーマットを揃えるのが大変なんですよね。L-RADのようなところで、申請を受けて財団に見てもらうのがよさそうです。

  • 坂本氏(意見): アメリカでは落選した申請書を財団が閲覧できるようにするサービスをやろうとしていますよね。財団では申請書チェックをしているのが大学教授であることが多くて、コンペティターが見てしまう問題があるため、L-RADでは導入は難しいですね。

続いて、研究費を集める側の皆さんからもご意見を頂きました。

  • 柴藤氏(意見): 科研費や財団への公募は研究者の皆さん慣れていらっしゃって出しやすいのですが、クラウドファンディングはハードルが高いと言われますね。大学側が研究者のクラウドファンディングを支援しますよという流れができれば一般化するのではないかと思っています。ただ大学側が運営を担当するのは大変ですから、クラウドファンディングに興味がある人が集まって大きなコンソーシアムを作っていけたらいいですよね。

  • 林氏(質問): クラウドファンディングは尻込みしてしまっています。リソースはどれくらい必要ですか?研究をうまくアピールできるか自信がないのですが、一歩踏み出すにはどうすればいいのでしょうか?

  • 柴藤氏(回答): そこは私達アカデミストがサポートします。研究に集中しすぎると何が面白いのかわからなくなってくることがありますけど、他の人が見るとわかってくることがあります。そのことを研究者の皆さんにお伝えしたいですね。それからリソースについては、人によります。アピールが上手な人はすぐに書き終わりますが、苦手な方は時間がかかってしまいますね。

  • 田部氏(質問): 研究の面白さを伝えるというのは、URAと似ていますね。URAとのコラボレーションはあるのでしょうか?

  • 柴藤氏(回答): 今後検討していきたいと思っています。

  • 加藤氏(意見): クラウドファンディングはわかりにくい分野にはお金が集まりにくそうですね。大学の広報とのコラボレーションは考えないのでしょうか?

  • 柴藤氏(回答): これからのソーシャルにおいて研究者が自分自身で発信することが強みになっていくと思っていますので、大学の広報とのコラボレーションは考えていませんね。

  • 坂本氏(意見): 先生の中には営業力がすごくて、企業にスポンサーとして付いてもらって勉強会を開いている先生もいらっしゃいますね。稼げる先生はもっとアクティブにいけばいいと思います。

  • 渡邉氏(意見): アクティブな先生にはコンプライス面のリスク回避として、リサーチサポートの充実がアクティブになればなるほど大切になってきますね。うっかり話しすぎてしまって、特許にならないこともありますので。

研究支援者としてのキャリア

最後に、研究支援者としてのキャリアについて渡邉氏と田部氏に仕事内容ととりまく環境についてお聞きしました。

  • 渡辺氏: 私はiPS細胞研究所で広報チームをマネジメントしています。仕事内容としては会社のマーケティングと同じようなことをしていますが、求められる知識の量が会社よりも多いですね。大変ですがやりがいがあるお仕事ですよ。

  • 田部氏: 私は大学の先生と企業のつなぎ役として、先生方には研究のヒヤリングや特許申請についての相談を受けたり、企業の皆様からお金を獲得しにいったりしています。営業マンのような仕事で、これまでの研究キャリアが使えなくて寂しく思います。支援者はあくまで支援者で、どっちつかずとなってしまっていて自分は何のプロなのだろうかと考えてしまいますね。

f:id:mi_progress_oOo:20180609215524j:plain

さいごに

昨年の12月に今回の学生企画のお話を頂いてから昨日までの約9ヶ月間。

未熟な企画からスタートし、たくさんの人に支えられて今回の素晴らしいシンポジウムを開催することができました。自分の立場に見合わないような素晴らしいプレゼンターの皆様に恵まれて、企画者冥利に尽きました。

Research Fund 3.0に向けて、現状の整理と今後の課題を浮き彫りにすることができたと思います。特に、最後にアドリブでお話させて頂きましたが「様々な立場の人が真剣に研究費について考え、奮闘している」ということを改めて感じることができ、日本の研究業界はもっともっと明るくなっていくと確信しました。

最小限の勉強で基本情報技術者試験に合格した話

概要

今回のブログ記事は、学び方を学んだというお話です。
基本情報技術者の試験勉強をするにあたって、長年の悪い癖を矯正できたので記念にブログに残しておこうと思い立ちました。
誰かのお役に立ったら嬉しいです。

これまでの私(AsIs)

  • スケジュール管理をしない
  • 頑張れるだろうという発想で見積もる
    • 平日の夜も勉強する前提で考えしまう
    • 休日も10hくらい勉強する前提で考えてしまう
  • 教科書を1ページから順番に読む
  • 過去問を解くのを後回しにする
  • わからない所があると、そこにリソースを取られて先に進めなくなる

このように超非効率的人間でした...

今でもよく覚えているのですが、院試勉強のときに所属研究室の教授から、
「わからないところで逐一調べていたら終わらないよ。一回教科書を読み通して全体を掴んでみなさい。」
と叱られたものです。

どうなりたいか(ToBe)

最小限の勉強で試験に合格したい!
これに尽きました。

やってみたこと(HOW)

1. とりあえずスケジュールを引いてみた

スプレッドシートの横軸に日付、縦軸に

  • すでに決まっている予定
  • 過去問の種類 (H29秋試験, H28春試験など)
  • 教科書の章 (第一章 ハードウェア など)

を書いてみました。
すでに決まっている予定を書いたのが個人的に一番の収穫でしたね。
「この日曜日は終日出かけるから、勉強のリソースにカウントできない」
と認識しておけば、お出かけを心から楽しめるし、勉強すると決めた日に集中して勉強できました。

2. 平日は一切勉強できない前提で見積もる

  • 通勤中に読もう...
  • 昼休みに読もう
  • お家帰ったら読もう...

あなたそれ絶対できないから!!!!!!!
怠け者な自分を認めて平日は一切勉強できない前提に立ってスケジュール管理をしました。

3. 教科書を最初から読むのをやめた・教科書から読むのをやめた

試験日までの予定を俯瞰して、「教科書を最初から読んでたら絶対終わらない」ということ気づきました。
そこでよく出るマークの付いた章から読んでいったのですが、全然頭に入らない。
ここであることに気づきました。
必要に迫られないと覚えられないのでは...?
ということです。

4. 出題されたところを付箋で可視化

教科書から読むのを早々に辞め、過去問を解いて出たところを教科書で調べて付箋を貼るようにしました。
私が学んだ過去問には、各問題に「よく出る」「キホン」というタグ付がされていたので、それも付箋に書いて貼りました。
4回分の過去問から可視化した結果がこちら。

f:id:mi_progress_oOo:20180603164843j:plain

同期に引かれましたが、どのページが最も出題率が高いのか一目瞭然となりました。
付箋が多いページから見直していくことで優先順位をつけて学ぶことができ、副次効果で通勤中も勉強できました。

総括

効率的に勉強するには、

  • スケジュール全体を俯瞰する
  • 怠け者な自分を認める
  • 教科書を最初から読まない
  • 必要に迫られるように仕向ける
  • 優先順位を可視化する

がポイントであることを学びました。
プログラミング言語の勉強でも使えそうです...
Rustの効率的な勉強法を確立できてないので、今回学んだことを活かして勉強しようと思います。

使った教科書・過去問のご紹介

f:id:mi_progress_oOo:20180603171504j:plain 五十嵐順子さんのかんたん合格シリーズ本。おすすめです!

JJUG CCCで聴講したセッションまとめ

Introduction to MicroProfile Metrics #ccc_i1

スライド

www.slideshare.net

メモ

  • Eclipse MicroProfileが提供するMetrics APIについてのお話
  • マイクロサービスを対象とした監視用API
  • アノテーションを利用することで簡単に実装できる

調べてみたこと

MicroProfileとは

公式サイト

マイクロサービスアーキテクチャに最適化したJavaを実現するための「MicroProfile」、Eclipseの正式プロジェクトに

JMX/RMIとは
  • JMX = Java Management Extensions
  • RMI = Remote Method Invocation
    • ネットワークを通じてプログラム同士が通信を行い、異なるコンピューター上にあるオブジェクトのメソッドを呼び出すための技法
JAX-RS, CDIとは

ディープラーニングシステムの導入と運用で学んだ事 #ccc_i2

メモ

AIのユースケース
  • 画像から販売量推定
  • 携帯電話の不正利用チェック
  • データからのレコメンド
  • 顧客セグメンテーション
  • PREDICTIVE MAINTENANCE
ディープラーニングシステムを始める上での注意点
  • まずはシステム全体を俯瞰して考えよう (Production ML Lifecycle)
  • 全チームを巻き込もう
  • 機械学習の能力とビジネス価値はマッチするのか?を考えよう
  • 機械学習を決定する前により簡単なソリューションがあるならまずはそれで始めよう
  • クラウドの費用

調べてみたこと

Eclipse DeepLearning4Jとは

公式サイト

公式YouTubeチャンネル

ゴンザレスさんおすすめのディープラーニング入門書

Deep Learning: A Practitioner's Approach

Deep Learning: A Practitioner's Approach

  • SkymindのCo-founderであるAdam Gibsonさん執筆の本、つまりDL4J開発者が書いてる本
  • ディープラーニング系の本は行列の話から始まりがちで、いわゆるバックグラウンドが数学の人を対象とした本が多い
  • それに対してこの本はプログラマがわかりやすい内容となっている

Scala製システムを4年間運用することで起きた様々なことへの対処 #ccc_i3

メモ

Mackerel4年間運用の軌跡
  • 194週連続新機能リリース
  • Playframeworkのバージョンアップ
  • sbtのバージョンアップ
  • 機能の廃止
  • チームメンバーの移動
  • プラットフォームをデータセンターからAWS
運用をし続けていくなかで学んだこと
  • 運用において大事なのは、採用技術とそれにまつわるコミュニティの近さ
  • コミュニティが近ければ、有識者や開発者からアドバイスがもらえる
  • スキルマップでチーム内の技術力を可視化
    • 各技術に対するメンバーのスキル状態を点数化することで、「このチームに足りないスキルはなにか」を可視化
    • 誰かが抜けたときの影響を点数で表せるから、「こういうポジションの人がほしい」という依頼を会社にしやすい

調べてみたこと

はてな研修用教科書

github.com

How to Properly Blame Things for Causing Latency: An Introduction to Distributed Tracing and Zipkin #ccc_i4

スライド

speakerdeck.com

メモ

  • 英語講演だったのでメモが全然取れなかった(´;ω;`)
  • 次回は取れるようになれてたらいいな...
  • Adrian Coleさんの英語は発音が綺麗でとても聞き取りやすかった
    • 「日本の皆さんはツイッターが大好きですよね。宮崎駿の作品が放映されるとすごい呟きますよね。」というお話に笑いました

調べてみたこと

Zipkinとは

公式サイト

分散トレーシングシステムとは

engineering.linecorp.com

Qiita - 分散トレーシングシステムのZipkinを使ってみた話

REST APIに疲れたあなたに贈るGraphQL入門 #ccc_e6

スライド

www.slideshare.net

メモ

GraphQLとは
  • GraphQL vs RESTという形で紹介されることが多い
  • RESTの次のパラダイム
  • AWS AppSyncを利用することで簡単にGraphQLが使える
  • リアルタイム機能とオフライン機能を簡単に実装できる
GraphQLの概要
  • GraphQLはAPI用のクエリ言語であり、TypeSystemを使用してクエリを実行するためのサーバー側のランタイム
  • クライアントがサーバーからデータを取得、変更、購読できるようにするためのデータ言語
REST APIの疲れるところ
  • API仕様ドキュメント管理が大変
  • 叩き方を理解するのが大変
  • ドキュメントと実装がずれてて喧嘩
  • 1ページを表示するのに何個もAPIを叩かないといけない
  • せっかくイベントドリブンに作っていてもサーバーとの接続は複数
GraphQLのメリット
  • クライアント、サーバー間のインターフェイスがクリーンに
  • イベントドリブンで書くことができる

調べてみたこと

GraphQL

公式サイト

AppSync

AWS AppSync

JJUG CCCにボランティアスタッフとして初参加した話

JJUG CCCとは?
JJUG CCCとは、毎年春と秋に開催される日本最大のJavaコミュニティイベントです。
初級者から上級者まで、幅広い層を対象とした良質な講演を聞くことができます。
今回私は、初参加にして初ボランティアスタッフ参加もさせて頂きました!
とても素敵な経験をしたので、記事として残したいと思います。

 

ボランティアスタッフはどんなことをするの?

  • 各セッション部屋のタイムキーパー
  • 聴講者用椅子の追加などの部屋運営
  • 参加者誘導
  • ブース部屋でのドリンク配布
  • 懇親会会場設営・他諸準備

が主なお仕事です。

 

ボランティアスタッフをしてみてよかったこと
Javaへ貢献ができる
普段の業務だけでなく、プログラミングに関する様々な知識を学ぶ上でもJavaには大変お世話になっています。
その恩返しとして、ユーザー会でのボランティアスタッフをすることは他のこと(コミッターになる、講演者になる等)よりも難易度が低いものだと感じました。
これからプログラマとしてもっともっと成長して、大きな貢献もしていきたいです😊

 

いろいろな人に話しかけやすい
ボランティアスタッフをやっていると色々な人に話しかけやすくなります。
特に講演者の方には必ず挨拶をするタイミングがあるので、そのときに質問もできちゃいます。
実際に、ディープラーニングの講演をされていたGonzalezさんに、ご挨拶のついでに「おすすめの入門書はどれですか?」と質問させて頂きました。
一般の聴講者として参加してたら緊張して話しかけられなかったと思います。

 

友達を作りやすい
カンファレンスに行って新しい友達を作るのは至難の業...私は懇親会で誰とも話さずに帰ることが多いです😅
そんな人見知りでもボランティアスタッフとして参加したら、スタッフとしてご一緒した皆さんと自然と打ち解けられました。

 

ボランティアスタッフはどうしたらなれるの?
私はJJUGの公式アカウントのツイートを見て応募しました。

次回もボランティアスタッフやろうと思ってます。
この記事を読んでくださった皆さんも、ぜひ一緒にボランティアスタッフやりましょう!!


 

ボランティアスタッフKPT

最近プライベートな出来事もKPTにまとめるのが趣味になってまして...
今回のボランティアスタッフ経験もKPTをメモしておこうと思います。

KEEP

  • 笑顔で挨拶
  • やれそうな仕事を積極的に探していく
  • わからないことはすぐに聞く

PROBLEM

  • 混んできたセッション会場で「詰めてお座り下さい」という案内をできなかった
  • 英語は理解できるのに、英語で返答できなかった
  • 最初から力みすぎて、打ち上げまで体力が持たなかった

TRY

  • もっと積極的に案内できるようになる
  • 英語のスピーキング力を向上させる
  • また英語のセッションの会場スタッフやりたい!
  • 体力温存する、レッドブルウコンの力予め買っとく

業務を通じてレイヤー化アーキテクチャを学んだ話

どうもこんにちは。

気づけば年末の振り返りから1ヶ月経ってしまいました...もっとブログを書く習慣を付けたいです。

さて、今回のテーマはレイヤー化アーキテクチャについてのお話です。

前々スプリントで実装した案件が、非常に学びが多いものだったのでブログに載せることにしました。

 

どんな案件だったのか

扱った案件をそのまま書く訳にはいかないので、今回は架空のサービスを考えます。

それは、恋活マッチングサービスです。

仮に、えんむすびという名前を付けましょう。

えんむすびでは、会員は自分のプロフィールを書くことができ、異性の会員はそれを閲覧することができます。しかしながら、このような恋愛に関するサービスではイカガワシイ人物の影が潜むものです。

怪しげな外部サイトへの誘導、イカガワシイ誘い文句などなど...健全なプラットフォームを脅かす会員を根こそぎブロックするべく、会員のプロフィールは審査員がチェックしています。


f:id:mi_progress_oOo:20180204225234p:plain

えんむすび(仮)の概要

そんな中、審査員の方から次のような依頼を受けました。 

審査員「会員様のプロフィールを審査するときに、禁止ワードをハイライトさせる機能をつけて欲しいです。それから、禁止ワードの追加・削除が気軽にできるようになりませんかね...」

私「なるほど。確かに今の仕様だと、禁止ワードの追加や削除は直接エンジニアがSQLを叩くしかないですもんね。ハイライト機能のついでに、追加や削除を審査員の方ができるようにしましょう!」 

 

要件定義

審査員の方からの要望を元に、上司や先輩からアドバイスを頂きながら次のような要件定義をしました。

 1)禁止ワードの登録・削除・検索ができる専用の画面を作成する

 2)禁止ワードの登録・削除・検索は、RDSを参照する

 3)会員のプロフィールを審査で表示する際、禁止ワードが存在していた場合はそのワードをハイライトさせる

 4)ハイライト時の禁止ワードは、RDSではなくRedisを参照する

 5)Redisの禁止ワードは寿命24時間のキャッシュとし、期限切れの際はRDSのデータを新たにセットする

 

実装してみた

早速何も考えずに実装してみました。

それがこちらです。今見ると目を覆いたくなる酷い実装です...。


f:id:mi_progress_oOo:20180204225244p:plain

修正前の実装

RDSとRedisに関する処理をLogicというクラスにひとまとめにしているのが酷いです。

さらに、要件5)を満たすための業務ロジックの中で、RDSとRedisのORマッパーが一緒に呼び出されているという悪夢のようなメソッドを生み出していました。

Redisの世界にRDSへの依存ができてしまっていたのです。

 

修正してみた

そこでLogicをRDS用とRedis用に分けた修正版がこちらになります。


f:id:mi_progress_oOo:20180204225248p:plain

修正後の実装

要件5)の部分は、赤色のActionで実装しました。

これで、少なくともRDSの世界とRedisの世界は分けられたのですが...(実際に実装したのはここまでです)

レイヤー化アーキテクチャにするとしたらどう書けるんだろう?

という興味が沸々と湧いてきたので、 DDDやクリーンアーキテクチャの勉強も兼ねて、レイヤー化を考えてみることにしました。 

 

レイヤー化アーキテクチャとは

色々な記事を読んで、レイヤー化にも様々な手法があることを学んだのですが、Spring MVCアーキテクチャが一番今回の案件に適していると感じました。実際に書いてみたのがこちらです。


f:id:mi_progress_oOo:20180204225251p:plain

レイヤー化された実装

主にこの2つの記事が参考になりました。

2.4. アプリケーションのレイヤ化 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.3.1.RELEASE documentation

MVC の Model 肥大化への対処 - Qiita

これらを読んでいて、今回の案件はLogicをRepository(ドメイン層)とRepositoryImpl(インフラストラクチャ層)の2つに分けたほうがいいことに気がつきました。

というのも、使用するDBサーバーやORマッパーを柔軟に変えたいと思った時に、あまり業務ロジックと関わって欲しくないからです。

インターフェイスというのは規格という意味で、その実態がどのように実現されているかどうかは、ドメイン層は知らなくていい」

ということを以前教わったのですが、ようやくその意味を深く理解できるようになりました。「DBサーバーとこんなやりとりをします」という決まり事だけRepositoryに書いて、ORマッパーを使った実装はRepositoryImplに書けば良いのです。

そうすれば、「今度はMySQLじゃなくて、PostgreSQLにしよう」となったときも、DBサーバーとのやりとりは書かれているので、安心してRepositoryImplだけを変更することができます。これは、ドメイン層にとっても優しいし、エンジニアの同僚にとっても優しい仕様だと感じました。

 

ついでにPlantUMLも使ってみた

せっかくなのでクラス図の練習をしたいと思い、PlantUMLを使ってレイヤー化した際のクラス図を作ってみました。

ControllerとRepositoryImplの中身は省略しました。


f:id:mi_progress_oOo:20180204225254p:plain

PlantUMLを使ったクラス図

ついでにコードも載せますね。

@startuml

skinparam class {
    BackgroundColor #FFFBF2
    ArrowColor #1253A4
    BorderColor #FFB600
}

interface NgWordRepository {
    NgWord createNgWord(NgWord ngWord);
    void deleteNgWord(Long NgWordId);
    List<NgWord> selectNgWords(NgWordType type);
    boolean existsNgWords(NgWord ngWord);
}

interface NgWordCacheRepository {
    List<NgWord> selectNgWords(NgWordType type);
    void setNgWords(List<NgWord>);
    boolean existsNgWords(NgWord ngWord);
}

class NgWordRepositoryImpl
class NgWordCacheRepositoryImpl

class NgWordService {
    NgWord createNgWord(NgWord ngWord);
    void deleteNgWord(Long NgWordId);
    List<NgWord> fetchNgWordCache(NgWordType type);
}

class NgWordController {
}

NgWordRepository <|..NgWordRepositoryImpl
NgWordCacheRepository <|..NgWordCacheRepositoryImpl
NgWordService ..> NgWordRepository
NgWordService ..> NgWordCacheRepository
NgWordController ..> NgWordService

@enduml

PlantUMLの使い方はこちら3つのサイトが参考になりました。

Open-source tool that uses simple textual descriptions to draw UML diagrams.

PlantUML Cheat Sheet - Qiita

PlantUML を便利に使うための3つの Tips - Qiita

 

まとめ

今回業務で2つのDBサーバーを使う案件を実装したことで、レイヤー化アーキテクチャの利点を理解することができました。

百聞は一見に如かずならぬ、百見は一実装に如かずだなと。

どんなに本や記事を見ても、自分で実装するまでその大切さはわかないことを学びました。

もちろん、知っていなければわかる以前の問題なので、本や記事でのキャッチアップは重要です。これからもっともっと読まなきゃです。

でも、同じくらいコードを書かなきゃだめだなとも思いました。

読み書きに励んでいきます。

今年の振り返り

今年もあと一時間を切ったので簡潔に振り返る。

 

1月 ~ 3月

2つのバイト先を掛け持ちしていて、一方ではイベントを開催(研究者向けのクラウドファンディングをリアルでやってみた)したり、一方では訪問看護系の方々に取材に行って記事を書いたりしていた。

Progateを鬼のようにやっていた。(レベル300超えになり、会社の先輩方に「レベル300超えの子」と覚えられていた)

休学していた大学に退学届けを出しに行った。教授陣の所に行く(やめるには簡単な面談が要る)のは結構しんどかったけど、研究者の道ではなくエンジニアの道に進もうと思った決意は揺るがなかった。改めてその頃の決意を振り返ると、

 

1.研究費をもらって研究をし始めて、「直接人の役に立たない研究でお金を貰う」ことにひどく罪悪感を抱くようになった。私にとって化学は、知的好奇心を探求するための純粋な学問であり、自然と対話したくてやっているのであり、人のためにするものではなかった。

2.高校時代に、自分が作った手作り放電管キットが中学高校の先生方に評価され「これ私も作っていいですか?」と言われてものすごく嬉しかったことを思い出し、「やっぱり誰かの役に立つものが作りたい、誰かの役に立つものが作れるのが嬉しい」と感じる自分に気がついた。

3.エンジニアの友達がPC1つで様々なプロダクトを作っているのを見て、「化学者は実験室が無いと仕事ができないけど、エンジニアはPCさえあれば、家でも職場でもカフェでも仕事ができるんだな」と驚き、強烈な憧れを頂くようになった。

4.とにかくコーディングが楽しくて仕方がなかった。

5.博士号を生半可な気持ちで取る気は全くなかった。二兎を追う者は一兎をも得ず。エンジニアになりたいと決めたんだから、全力でそちらに振り切ろうと思った。

 

という感じだった。

3月の中旬に就職先から本が届けられ、Javaの本をもりもりやっていた。

 

4月

入社。全体研修と座学メインの研修。

 

5月, 6月

HTTPサーバー研修。

「サーバーって作れるの...?」「サーバーって何...?」と超不安になったのをよく覚えてる。二次情報禁止・見ていいのはオラクル公式サイトとRFCのみという制約の中で、一番最初の課題でソケットについて必死になって調べたなぁ。

自作サーバーでブラウザに文字や写真を描画できるようになった驚きと喜びは忘れられない経験になった。すごく嬉しかった!

この頃Rustに出会った。

 

7月, 8月

事業部に配属になり、Twitter研修。

「知ってるフレームワークRailsのみ」な状態で、Spring boot, Flyway, Hibernateという摩訶不思議なものたちを前に死にそうになりながらTwitterを作った。奇跡だと思う。なんで作れたのか自分でもわからない。ものすごく力が付いた課題だった。

詳しく書きたいけど時間が...

 

9月, 10月, 11月, 12月

仕事が始まる。ここも詳しく書きたいけど時間が....

自分のプロダクトで喜んでくれる人がいて、それがすごくすごく嬉しくて、「やっぱりエンジニアになってよかった」と心から思う瞬間がたくさんあった。

自分の決意は間違ってなかったと思った。

 

( ゚д゚)ハッ!もう新年だ!

明けましておめでとうございます。

今年もよろしくお願いします。