Mi in progress

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

闇雲な「JavaじゃなくてKotlinやりたい!」という気持ちが消えた理由

前置き

先日このようなツイートをしたのですが、予想以上の反響を頂いて驚きました。

ツイートを読み返し、「この書きぶりだと様々な文脈を憶測できてしまうな」と思い、140字では書ききれなかった文脈の部分を本記事で書き起こすことにしました。

結論

知的好奇心・エンジニアとしての漠然とした成長の観点から、「プロダクトの言語をJavaからKotlinに変更したい」と思っていましたが、

  • 「事実・課題・解決策」に対する認知能力の向上
  • 言語仕様をトレードオフで考えること

により、「現在自分たちが抱えているプロダクトの重大な課題は、プログラミング言語を変えて解決するものではない」という結論に至りました。
さらに、Javaの素敵な所を自分なりに理解できたので、闇雲な「JavaからKotlinに変更したい」という気持ちが払拭され、漠然とした成長に対する不安を解消することができました。

この記事のゴール

記事を読んでいる方が、

  • 「事実・課題・解決策」の違いがわかるようになる
  • 漠然とした成長に対する悩みが解消される

という状態になること(なって頂けたら嬉しいなという気持ちです)

Java = イケてない」の風潮がとても辛かった

私は、

  • コンピュータ・サイエンスのバックグラウンド無し
  • Javaについては入門書をやった程度

という状態でエンジニアとして就職しました。
いざ研修も終わり、業務でJavaを書いていると、他の言語を使っている人たち(会社内外問わず)から、

  • 「やっぱり今どきScala(Kotlin)でしょ」
  • 「もうJavaの書き方なんて忘れちゃったよ、もう書きたくない(笑)」
  • Javaはイケてない」

と言われて、正直とても嫌な気持ちになりました。
未経験エンジニアとしてのコンプレックスのようなものも相まって反論できず、「そうなんだ...Javaってイケてないんだ...」と感じ、上記の発言を真に受けちゃったんですね。今思うと、「事実確認なしに真に受けていた」だけなのですが。
漠然とエンジニアとしての成長に不安を抱えるようになりました。

だから、事業部で言語選定の機会が与えられたときに「JavaじゃなくてKotlinやりたい!」と強く思いました。

大きな転機1:スクラム開発導入

そんな私にとって大きな転機となったのが、スクラム開発導入です。
スクラム開発自体が大きな転機になったというよりも、「スクラム開発の一つ一つのセレモニーを効率的に進めるにはどうすれば良いのか?」を考えたことが転機になりました。

私達の事業部では8月からスクラム開発を本格導入したのですが、全体で物事を決める際にとてつもなく時間がかかりました。実績としては、

  • 2時間で終えるはずの話し合いに丸2日かかった
  • 話し合いたいトピックが8つあったのに1つしか話せなかった

が挙げられます。
この状況を打破するべく、まずは現状把握ということで、記録を取ることを始めてみました。議事録と呼ぶには貧相な、「時間と話されている内容と個人的な感想」を簡潔にまとめたメモを徹底的に書きなぐってみたところ、あることに気づきました。

議論がまとまらなくなってくるのは、

  1. 課題がないのに解決策を言っている
  2. 事実がないのに課題を言っている
  3. 事実を課題として言っている

ときでした。どういうことか具体的に見ていきましょう。

1. 課題がないのに解決策を言っている

例: JavaではなくKotlinを導入する

=> 聞き手は、「導入することでどんな課題が解決されるのだろう?なんで導入したいんだろう?」と感じる

2. 事実がないのに課題を言っている

例: JavaではKotlinよりコード量が多くなるため、実装に時間がかかる

=> 聞き手は、「本当にそうなのかな?LombokIDEの予測変換があるから時間がかかると思わないんだけど。Kotlinの哲学である「簡潔」を言い換えただけなのでは?具体的事実が知りたい。」と感じる

3. 事実を課題として言っている

例: Javaではぬるぽが起きる

=> 聞き手は、「ぬるぽが起きたときにどう困るんだろう?」と感じる


...いかがでしょうか。
要するに、聞き手の頭の中に疑問がたくさん浮かぶと、確認したいことが増えちゃうので、本質的な議論の前準備に時間がかかるんですね。
中には「よくよく考えてみたら、課題なんてなかった」となり、議論するものがなくなるケースも。時間をかけたのに悲しいことです。

ちなみに上記の具体例は、脳内会議をしている中で出たものです。
脳内会議の末、「JavaじゃなくてKotlinやりたい!」という闇雲な思いから、

  • 本当にKotlinにしたいなら、どんな課題感を持っているのか言語化しよう
  • 汎用的課題を言うのではなく、自分たちのプロダクトで実際に起きている課題を言おう

という思いに変化しました。
特に、「汎用的課題」の存在に気づけたのが個人的に大きな成長でした。
汎用的、というのは勝手に名付けてしまったのですが、「世間一般的に言われている」という意味です。

汎用的課題に対する解決策を考えても、プロダクトの真の課題は解決できない可能性があります。
"オリジナル"課題を見つける能力を培っていきたいものです。

大きな転機2:HTMLパーサーの仕組みを知った

もう一つ大きな転機となったのが、HTMLパーサーの仕組みをこちらの記事で知ったことでした。

HTML がより「寛大」な姿勢をとっていることです。追加した特定のタグをうっかり削除したり、開始タグや終了タグを忘れたりしても許容されることがあります。XML の厳密で要求の多い構文とは反対に、全体的に HTML は「緩やかな」構文です。
これはわずかな違いのようでも、話は大きく変わってきます。HTML が広く普及した主な理由はこの寛容性にありますが(誤りが見逃されるため、ウェブ制作者にとっては楽になります)...

HTMLが広く普及した主な理由はこの寛容性にあります

この一行を読むや否や、Javaは寛容な言語なんだ! と閃き、これまで学んできたJavaの言語仕様が雪崩のごとく脳内に押し寄せてきました。点と点が繋がったような、今までモヤモヤしていたことが晴れたような感覚でした。
特にお伝えしたい寛容ポイントは、null許容です。

null許容

前提として、null許容は言語設計者本人が 10億ドル規模の損失をもたらす過ち と言うくらいですから、私自身も「null許容は様々な問題を引き起こしてしまうので、nullが許されない世界でコードを書きたい」と思っています。しかしながら、

null許容 = プログラマが雑なポインタの使い方をしていても許してくれる

という視点に立ってみたところ、Javaを最初学んだとき、ポインタのことで一切悩まなかったことを思い出しました。余談ですがC言語へ入門を試みたとき、ポインタで諦めてしまいました(今は大丈夫ですw)

Javaは内部でポインタ(is-aポインタ)を使っていますが、プログラマは基本的に意識する必要がありません。私の場合は業務でコードを書いた際、クラスを作って、インスタンスを作って...様々なクラスがインタラクションを始めたとき、「ぬるぽで落ちた!ああ、nullの時を考慮し忘れてた!」となり、ポインタを意識するようになりました。
これって、「最初は本質的にやりたいことに集中して、そのあとポインタで悩むことができた」と捉えることもできるのかなと。
そういった意味で、やりたいことの前にポインタで悩む必要がないのは、null許容の良い側面かなと私は感じました。

null許容の他にも、String定数プールやガベージコレクションなど、プログラマが本来ならば考慮しなければならないメモリの難しさを、Javaは巧妙に隠蔽しています。それに気がついて、Javaってよく考えられた言語だな、素敵だな」と愛しさがこみ上げてきました。

ポインタ扱いに対する寛容さが、多くのプロダクトで使われる要因の1つになったのだと、私は信じています。

High-level ergonomics and low-level control are often at odds in programming language design.
(高レベルのエルゴノミクスと低レベルの制御はしばしばプログラミング言語の設計においてトレードオフの関係になる。)

プログラミング言語Rustの公式ドキュメントにある一文です。
どんな言語でも、その設計の裏側では人間工学と機械制御の天秤を巡った苦悩があるのだと思います。
言語設計者の意図を理解した上で、自分(チーム)にとって、自分が携わっているプロダクトにとっての良し悪しを考えられるようになりたいです。

総括

2つの大きな転機により、気がつけば闇雲な「JavaじゃなくてKotlinやりたい!」という思いが綺麗さっぱり消え、

  • 自分が携わっているプロダクトの"オリジナル"課題は何かを特定できるようになりたい
  • 言語の仕組み・設計者の意図を理解した上で言語選定できるようになりたい

そういう目標が芽吹きました。
漠然とした成長への不安が、言語化された意思表明に変わった瞬間です。
一歩一歩目標に向かって進んでいきたいと思います。
ここまで読んでくださり、どうもありがとうございました!

Kotlin Fest 2018で学んだこと・気づき・自分で調べてみたこと

概要

Kotlin Fest 2018に行ってきました。
今日のブログ記事は、そこで見聞きして学んだこと・気づき・自分で調べてみたことをまとめたものです。

オープニングセッション by 長澤太郎さん

見聞きして学んだこと

Kotlinの歴史
  • 2011年7月 発表
  • 2012年2月 実装公開
  • 2016年2月 バージョン1.0リリース
  • 2017年3月 バージョン1.1リリース
  • 2017年11月 バージョン1.2リリース
Kotlinのリリーススタイル
Kotlinのコミュニティについて
  • JKUG
    • 2013年7月に創立
    • 活動目的
      • 勉強会の企画・運営・支援
      • Slackの運営
      • 助走読本(無料配布しているらしいので後でチェック)
  • KotlinConf
  • OSS活動
    • KEEP (言語への提案やそれに関する議論)
    • コンパイラIDE、ライブラリへのコントリビュートが可能
    • コントリビュートするとKotlinブログに名前が載る

気づき

素敵なオープニングセッションだなと思った理由深掘り
  • デザインが綺麗
    • マスコットキャラクターがとにかくかわいい
      • 日本語でKotlinは「小鳥」と掛けられること・イメージカラーの黄色と青色を見事に合わせた最強のイラスト
  • ビジョンが明確「Kotlinを愛でる」
  • みんながHappyになれるルールを提示
    • 登壇者へたくさんリアクションしよう
    • パックマンルール | 会話に入ってこれるようにスペースを開ける
    • 行動規範

自分で調べてみたこと

2011年7月 発表に関する情報
KotlinConfに関する情報
JKUGに関する情報
OSS活動に関する情報

オープニングセッション by 藤原聖さん

見聞きして学んだこと

「Kotlinを愛でる」に隠された思い
  • Kotlin in Actionの第2部のタイトル
  • 原著だとEmbracing Kotlin (Kotlinを抱きしめる)
  • 愛情を持って、より深く知るという意味
  • 翻訳の際に、抱きしめるより愛でるが適切という結論に
Kotlinの特徴
Kotlinの哲学
  • 実用主義
    • Javaの考え方がそのまま使える。新しい機能は既存のものを利用。学習が容易。
  • 簡潔
    • 読みやすさを重視。ボイラープレートは極力減らす。
  • 安全
    • 静的型付け。Null安全。スマートキャスト。
  • 相互運用性
    • JavaとKotlinの間は自由に行き来。ライブラリも既存のものをそのまま利用できる。
Kotlinを知るためのリソース

気づき

Kotlinの哲学に感激した
  • better Javaだけでなくrespect Javaも感じられる
    • まさに巨人の肩の上に立つの姿勢
    • respectな精神はユーザーフレンドリーにも繋がる
      • 新しいプロダクトを作るときに大事な姿勢だなと思った

自分で調べてみたこと

Kotlinを知るためのリソースに関する情報

Kotlinもう一歩 by 森洋之さん

スライド

見聞きして学んだこと

型(タイプ)とは
  • クラスと型は異なるもの
  • 型によって決まるもの
    • 変数や式のとりうる値の範囲
    • 行える演算や操作
<: という書き方
  • B <: A
    • AはBのスーパータイプ
    • BはAのサブタイプ
    • Aが期待される全ての箇所でBは使用可能
    • 例) Int <: Number
      • Int型はNumber型の範囲内
      • Number型はInt型の範囲内とは限らない (DoubleやLongかもしれないから)

Any

  • すべてのnull非許容型は、Anyのサブタイプである
    • Int <: Any, String <: Any はOK
    • String?はAnyのサブタイプではない

Nothing

  • Nothingは、あらゆる型のサブタイプである
    • Nothing <: Int, Nothing <: String?
    • どんな型が期待されている箇所であろうとNothingは使える

null許容型(Nullable)とnull非許容型(NonNull)

  • NonNullは、Nullable型のサブタイプである
    • String <: String?
      • String?が使えるところでStringは使える
      • Stringが使えるところでString?が使えるとは限らない

変位

  • B <: Aのときに、Foo<B>Foo<A>にどういう関係があるかを表すもの
  • invariant | 不変 <T>
    • サブタイプを引き継がない
    • B <: Aのときに、Foo<B><:Foo<A>でもなくFoo<A><:Foo<B>でもない
  • covariant | 共変 <out T>
    • サブタイプを引き継ぐ
    • B <: Aのとき、Foo<B><:Foo<A>
  • contravariant | 反変 <in T>
    • サブタイプが逆転する
    • B <: Aのとき、Foo<A><:Foo<B>
  • 変位アノテーションとしてinとoutがある

out修飾子

  • valしか使えない
  • getメソッドのみ
  • 戻り値にしか使えない

in修飾子

  • setメソッドのみ
  • 引数にしか使われない

気づき

理解できたこと
  • <:
  • Any
  • Nothing
  • null許容型(Nullable)とnull非許容型(NonNull)の関係性
ちょっとだけ理解できたこと
  • 変位
  • out修飾子
  • in修飾子

自分で調べてみたこと

Genericsに対する理解不足補填

How to Test Server-side Kotlin by 鈴木健太さん、前原秀徳さん

スライド

見聞きして学んだこと

テスティングフレームワーク選定基準
  • 自分たちが使用するwebアプリケーションフレームワークとの相性
    • spring-boot-starter-testのデフォルトがJUnit4だったのでそれを利用
  • IDEとの相性
    • KotlinTest 3.1.9では、クラス毎のテスト実行はできるがメソッド毎のテスト実行はできない
Kotlinならではのつまづきポイント
  • Kotlinのクラス/メソッドはデフォルトでfinal
  • Null / NonNollが厳密
    • nullを返すようなJavaのメソッドがあるとランタイムエラーになることがある | 例) Mockito.any()
    • DB上Nullを取りうるカラムの値をNot Nullプロパティにマッピングするようなコードがあると簡単に実行時例外になる
自作ツール作成時のモチベーション
  • Factlin
    • DbSetupのシンタックスは平易とはいえ、カラムの多いテーブルに対するセットアップコードを書くのは大変
  • Kotlin Fill Class
    • 大量のプロパティを持つクラスのコンストラクタを呼び出して初期化するのは大変
  • Kotlinの用のツールはまだまだ少ない印象なので今がチャンス!

気づき

  • テストをするにあたって、様々なツールが存在することを知った
  • 技術選定の際には、一緒に使うツール群との相性も大事であることに気づけた
  • 「大変だな」と思ったらそれはツール作りのチャンス!

自分で調べてみたこと

紹介されていたテスティングフレームワーク
紹介されていたアサーションライブラリ
紹介されていたモックライブラリ
紹介されていたDBセットアップライブラリ
紹介されていた自作ライブラリ

Kotlin linter by 釘宮愼之介さん

スライド

見聞きして学んだこと

Kotlin用のlint3種とその特徴
  • ktlint
    • formatをかけることができる(要実装)
  • detekt
    • lintの修正にかかる時間や複雑度も表示される
  • android-lint
    • 型を見ることができる
カスタムルールの作り方
  • Abstract Syntax Tree(AST)
  • PSI Viewerを使おう
    • PSI = Project Structure Interface
    • これを使うとnodeが持っているプロパティがわかるので、正しいlintを作る手立てに

気づき

自分で調べてみたこと

Kotlin コルーチンを理解しよう by 八木俊広さん

スライド

見聞きして学んだこと

コルーチンとはなにか
  • 一時停止可能な計算のインスタンス
  • スレッドに似ているが特定のスレッドに束縛されない
  • FutureやPromissのように値を返す場合がある
  • 継続状況を持つプログラムが容易に記述できる
Kotlinはどのようにコルーチンを実現しているのか
  • コルーチンをステートマシンに変換している
    • 中断と再開を状態遷移と見立てる
    • 再開に必要な情報をステートマシン内にキャプチャする
    • 内部状態を変化させながら実行する
  • ステートマシン変換のためにsuspend修飾子と継続を導入
  • 継続インターセプターにより、実行のスレッドを限定しない
コルーチンの基本的な使い方
  • Kotlin 1.1から登場
  • 各種機能はライブラリで提供
  • 1.3でstableになる予定
  • coreライブラリが提供するコルーチンビルダー
    • launch関数
      • 結果を持たないコルーチンを作成するコルーチンビルダー関数
    • async関数
      • 結果を持つコルーチンを作成するコルーチンビルダー関数

気づき

自分で調べてみたこと

How to Kontribute (v4 JP) by 磯貝佳典さん

スライド

photos.google.com

見聞きして学んだこと

コミュニケーション
  • Slack
    • Kotlinlang
  • YouTrack
    • "up-for-grabs"
      • 外部のコントリビューターさんよろしくおねがいします!のタグ
  • GitHub
    • プルリクを出すためだけの場
    • コミュニケーションの場ではない
    • YouTrackでコミュニケーションすること
おすすめのコントリビュート方法
  • Update README
  • Writing Documentation / Comment
  • おすすめはKT-20357
    • サンプルコードのないメソッドにサンプルコードを書く
  • Inspection
    • PSIViewerを使う
    • PSIElementVisitor

気づき

  • コントリビュートしたい(真顔)
  • PSIViewerはlintだけでなくInspectionを作るのにも便利
自分で調べてみたこと

総括

f:id:mi_progress_oOo:20180826230158j:plain

たくさん愛でました

愛でるだけでなく、大きな夢もできました。
Kotlinを書けるようになってきたら、このOSSにコントリビュートするという夢です。
github.com
大好きなRustにKotlinで貢献できるという私得OSSです。
たくさんコーディングして夢を実現させます😊

スクラム研修で学んだこと

この記事の概要

今月から事業部で大々的なスクラム開発が始まりました。
導入の前にまずはインプットということで、外部講師の方からみっちり「スクラムとはなんぞや?」を教えて頂きました。
今日の記事は学んだことを整理した内容です。

スクラム開発が生まれたビジネス的な時代背景

【昔】大量生産時代

  • マーケット: XXが枯渇している時代
  • KPI: アウトプットの量、薄利多売が成立していた

【現代】マーケットディスカバリー時代

  • マーケット: かゆいところに手を届かせたい時代、競合と競合のすきまを探す時代
  • KPI: 品質、面倒なことを解消してくれる度合い、ROIを高める・コントロールする

【今】マーケットクリエイト時代

  • マーケット: 情報が入りやすい時代、新しく生み出す時代
  • KPI: 他にないものを生み出す、ROIを高める・コントロールする

ROI

  • return on investment (投資した資本に対して得られた利益のこと)

ROIを高めるときの注意点

  • 結果を判断するための材料と高めるための材料は全く異なる
  • なぜ、いつ、それに投資するのか?が重要

スクラムとは

プロジェクトの現状を把握するためのフレームワーク

  • 現状を把握するのはとてもむずかしい
    • 把握するものが多い
    • 状況は刻一刻と変化する
  • 性悪説の観点でルールが定まっている
  • スクラムがフォーカスしているのは、investmentをコントロールするために必要な情報を収集するためのフレームワーク
  • 🙅returnを高めるためのものではない🙅

スクラムの組織体制

中央集権型組織は今のマーケット時代にそぐわない

  • メリット: 統制を取れる
  • デメリット: 意志判断が遅い・情報が古い、不適切になることがある
    • 刻一刻と状況が変わる今のマーケット時代にとって、このデメリットは致命的な影響をプロダクトに及ぼす

スクラムではTeam Based Organization (チーム中心型組織)を採用している

  • 第二次世界大戦のときにアメリカの人たちが使った体制
  • マーケットの市場変化を察知してゴールを変える権利を持つ人たち(Product Owner)、ゴールまで最短で推進する権利を持つ人たち(Teams)で分ける
  • Product OwnerとTeamsの間には上下関係はない
  • 会社は中央集権型が当たり前
  • 中央集権型の中で、どのようにチーム中心型組織を作っていくのか?を考える必要がある

Product OwnerとTeamsの役割

  • Product Owner | ROIの最大化
  • Teams | 生産性を向上

スクラムでは結果主義、手段はなんでもOK

  • つまり視点を変えると | 誰もが同じアウトプットになるように結果の定義を明確に、HOWは人に任せる

スクラムの考え方

  • 他の人が1時間かかる仕事を5分にするにはどうすればいいのか?
  • 様々なHOWについて寛容になる | 「経験上、XXの方が早く終わると思う」という価値観を捨てる

演習

2分間で60歩歩くプロジェクトを実践

  • 作業者に適宜歩き方を管理者として指示してみる => まるで歩けなくなることが判明
  • 何が問題だったのか?
    • 作業者の気持ち | なんでこのタイミングで?「止まれ」「右」というの?的確な指示を出してよ!
    • 管理者の気持ち | なんでこの指示でそうなるの?「右」といったら90度でしょ。

「やり方について口を出すのはやめよう」という考え方がスクラムでは大事

  • 口を出さないでプロジェクトが危機になったら?
    • みんなで仕事を進めていく中で、「気にしている」ことを言い合って、ケアしていけばいい
    • やり方を指摘しない
  • バウンダリーを明確にすることがファシリテーリングに最も重要
    • はみ出てはいけないラインを明確にする

質疑応答

ゴールはどう置けばいいのか?

  • ゴールがどんなものであるかというよりも、「なぜ?」を明確にしたり、チームに合った粒度にするのが大事

結果の評価は?

  • 速度と360度評価(チーム間でお互いに高めていく)

Product Ownerのあり方とは?

  • Product OwnerはROIの影響するかどうかのみ見る、優先順位の「判断基準」を伝える
  • Product BacklogやSprint BacklogはTeamがやる(Howだから)、「判断基準」を元に優先順位を付ける
  • 中間コストを減らすこと、「判断基準」を適切に伝えられることが大事

技術品質とDONE

品質には、製品品質と技術品質の2つがある

  • 製品品質 | マーケットが対価や価値を検証するモノ
    • 単体として担保、ユニーク性
  • 技術品質 | サービス提供者として担保しなければならないモノ
    • 社として担保、効率化
  • いくら癌にならないことが保証されていても、ユニーク性はない
  • しかし、癌になる可能性があればユニーク性がいくらあっても買ってもらえない
    • 技術品質が担保されていないと、ユニーク性はマーケットに受け入れてもらえない
  • マーケットの流動性を考えると、製品品質は技術品質になることがある
  • 技術品質は時代とともにどんどん増える
    • 効率化を考えないと、製品品質を考える時間がなくなる

技術品質の考え方

  • 一般論で考えると良い
  • 機械的に評価できるものでないといけない
  • 透明性がある

DONE

  • 自分たちで考えた技術品質定義
  • 「私達のプロダクトは最低限、これは絶対に担保しなきゃだめですよね」というもの

スクラム開発で大事なこと

TransparencyとInspectとAdapt

  • Transparency
    • その時点で正しい情報が一箇所に集められており、次の行動が誘発され続けている状態
    • 意味が理解できる状態
    • その時点で必要な情報がある
  • Inspect
    • RealityからGoalまでの差分を検証する
  • Adapt => 実際に実行した実績
    • 現状維持もAdaptした結果と考える
    • 「あなたは何のために行動しているんですか?」と言われて答えられる状態がAdapt

計画

  • 計画を立てる力を育む
    • 様々な想定外を包括した力強い計画
  • スクラムでは、想定外も踏まえた上でいくつかのプランを計画する
    • 想定外をどう取り扱うかの判断基準を考えることが先決
    • 1つのプランというのは意味がない
  • スプリント ... デイリースクラム以外の時間で一人で突っ走れるのが望ましい

総括

  • スクラムとは、プロジェクトの現状を把握するためのフレームワークである
  • ROIでいうと、investmentをコントロールするための情報収集をするためのフレームワーク
  • Product OwnerはROIの最大化、Teamsは生産性を向上させることに集中する
  • スクラムで大事な意識
    • 他の人が1時間かかる仕事を5分にするにはどうすればいいのか?
    • 様々なHOWについて寛容になる | 「経験上、XXの方が早く終わると思う」という価値観を捨てる
    • やり方について口を出さない、その代わりバウンダリーを明確にする
  • 製品品質は時代とともに技術品質になり、技術品質は膨れ上がる
  • 「技術品質をどう効率的に担保していくのか?」がまさにinvestmentをコントロールするための要
  • スクラム開発ではTransparencyとInspectとAdaptが大事
    • Transparency | その時点で正しい情報が一箇所に集められており、次の行動が誘発され続けている状態
    • Inspect | RealityとGoalとの差分が適切に評価できている状態
    • Adapt | 目的に向かって実際に実行できている状態
  • 刻一刻と変化するプロダクト開発の中で大事なのは、様々な想定外が洗い出された力強い計画
    • 想定外をどう取り扱うかの判断基準が存在していれば、みんなスプリンターになれる

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