2018-12-27

WindowsでCaps LockをCtrlに、JISキーボードをUSキーボードにする方法

Windowsをよく再インストールするけど、その度にCaps LockをCtrlにする方法を調べている気がする…。年末なのでまた再インストールしました。

（備忘録。そのうちちゃんと書く）

regedit

Caps -> Ctrl

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]

name	value
Scancode Map	00,00,00,00,00,00,00,00,02,00,00,00,1d,00,3a,00,00,00,00,00

JISキーボード -> USキーボード

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]

name	value
LayerDriver	kbd101.dll
OverrideKeyboardIdentifier	PCAT_101KEY
OverrideKeyboardSubtype	0

参考

Windows/TIPS/レジストリを修正してCAPSLOCKの割り当て変更 - yanor.net/wiki

2018-12-26

今更だけどghqを使ったリポジトリ管理を布教したい

Shell

ghq を使ってない人は人生の1割損してる。

本題

自分が ghq を使い出して数年経ったが、周りには案外、こういうリポジトリの管理ツールを使っていない人が多いらしい。絶対リポジトリの管理ツールはあったほうが良いので、ここで今更ながら宣伝しておく。 ghq 使います。

Goのインストール（準備編①）

まずはGoのインストールから。自分は goenv を使っている。（言語のバージョン管理は ○○env をよく使ってる）

goenvのインストールはこちらから。

GitHub - syndbg/goenv: Like pyenv and rbenv, but for Go.

goenvのインストールが完了したら、goをインストールする。インストールできるバージョンは goenv install --list で確認できて、このリストは ~/.goenv で git pull したら更新される。

$ goenv install --list
  （省略）
  1.11rc2
  1.11.1
  1.11.2
  1.11.3
  1.11.4

目的のバージョン（たぶん最新バージョンでいい）を見つけたらそのバージョンをインストール。インストールしたGoは goenv global で設定できて、 goenv versions で確認できる。

$ goenv install 1.11.4
  （インストールのログ）

$ goenv global 1.11.4
$ goenv versions
* 1.11.4 (set by /home/user/.goenv/version)

GOPATHの設定

実はGoには元々リポジトリ（外部ライブラリ）を管理する機能が備わっている。

リポジトリの管理は環境変数 GOPATH で設定されているディレクトリ（デフォルトは ~/go ）で行われて、 go get で取得したリポジトリはここに入るようになる。ソースは $GOPATH/src に保存されて、 ghq みたいにバイナリが付属するやつは $GOPATH/bin にバイナリが入る。

ただの外部ライブラリ管理ディレクトリのように思えるが、Goのプログラムを開発するときはリポジトリを GOPATH の下に置いておかないとimport周りが面倒くさくなるので（経験談）、実は普通のリポジトリもここに置いて一元管理しておいたほうが良い。そのため、 GOPATH にはこれから自分がリポジトリ管理に使いたいディレクトリを設定しておく。

自分の場合は ~/Work を設定している。リポジトリとかプログラムの管理は全部ここでやってて、 $ work で ~/Work に飛ぶエイリアスもある。（あと、 $GOPATH/bin をパスに追加しておこう）

# bashrc
export GOPATH=$HOME/Work
export PATH=$GOPATH/bin:$PATH

function work { cd ~/Work; }

ghq（とpeco）のインストール（準備編②）

pecoは go get でバイナリを取得できなくなったこともあり、Linuxだとちょっとだけ手間になった。ここではダウンロードしたソースをbuildする方法でpecoをゲットする。（ releases/peco_linux_amd64 のところはOSによると思う）

$ go get github.com/peco/peco
$ cd $GOPATH/src/github.com/peco/peco

$ make build
$ cp releases/peco_linux_amd64/peco $GOPATH/bin

ghqのインストールは go get で行える。これだけで $GOPATH/bin にバイナリが入るので、それを利用できる。

$ go get github.com/motemen/ghq

ghqの設定

ghqは go get のようにリモートリポジトリをまとめる機能を持っていて、このためにGOPATHのようにghqの設定も記載しておかなければならない。設定するファイルは .gitconfig の [ghq] 部分で、一番下に次の例のように、 $GOPATH/src のパスを追記するだけで良い。

（環境変数使えるのかな……。自分は ~/Work/src を設定していた）

[ghq]
  root = ~/Work/src

インストール作業は以上。

スーパージャンプ！（本編）

結論から言うとこの関数をbashrcに追記して使用する。関数名は何でもいいが、自分は入力のしやすさから repositories の re としている。

# bashrc

function re {
  local path=$(ghq list --full-path | peco --query "$LBUFFER")
  if [ -n "$path" ]; then
    if [ -t 1 ]; then
      cd ${path}
      echo 'jump to' ${path}
    fi
  fi
}

仕組みとか

ghq が使えるようになって設定も完了しているなら、現在 ghq と go get がリポジトリ管理に使うディレクトリは同じものになっているはずだ。（ $GOPATH と .gitconfig の設定）

試しに ghq list で確認してみると、さっきGoでクローンしたリポジトリが出力される。そして、今回欲しいのは --full-path を付けたfull pathのリスト。

$ ghq list --full-path
/home/shion/Work/src/github.com/motemen/ghq
/home/shion/Work/src/github.com/peco/peco

この結果をpecoに食わせて、pecoのQUERYと選択した行を出力してくれる機能を使ってリポジトリを絞り込んでいる。ここで取得したパスは変数 path に保存され、チェックなどが行わた後にそれを使って cd で移動する。 echo は消しても良い。

Gitリポジトリのクローン

Gitリポジトリのクローンは ghq get を使う。これは別に go get でもいいけど…。

ghq get https://github.com/githubtraining/hellogitworld

これで設定したディレクトリの下に、パスで区切られたいいかんじの階層でリポジトリが保存される。 ghq list を実行しても確認できるはず。

ローカルにしかないリポジトリの管理

ghq list で取得できるのは、指定ディレクトリ以下の .git を含むディレクトリのパスだ。（ ghq get で取ってきたものだけ、というわけではない）

自分の場合、ローカルのリポジトリは local というディレクトリに保存している。パスで言うと $GOPATH/src/local 。ここで例えば rails new とかで自分のプロジェクトを生成し、 git init で .git を作成することで ghq list でパスを取得できるようになる。

$ ghq list
local/my-local-project

実行例

$ pwd
/home/user

$ re
jump to /home/user/Work/src/github.com/peco/peco

$ pwd
/home/user/Work/src/github.com/peco/peco

2018-12-23

エンジニア、会社に給料を上げてもらうのは難しい説

ポエム

この記事が腑に落ちたので、思いついたことをちょっと書く。

blog.tinect.jp

本題

それなりの給与がもらえるかどうかは「人に投資すると売上が伸びる会社で働いているかどうか」

この一文が腑に落ちた。これは言い換えると、「人に投資することで売上が伸びる会社は、社員の給料を上げやすい」ということだろう。

エンジニアは職業柄、投資をされたところで会社の売上を直接伸ばすの難しい。そして何より、投資の結果が見えにくい。（知識労働者あるあるなのでは）

このような原因もあり、多くの企業でのエンジニアへの投資は最小限とされている。つまり、給料が突然上がることがほとんどない。

ほとんどの場合、エンジニアへの投資は先行投資だ。スタートアップ企業では、良いエンジニアを集めてモチベーションを高めるために先行投資を行う光景をよく見る。ただ、これはスタートアップだから先行投資が行われるというわけではなく、事業が少なく、投資の結果が見えやすいスタートアップが投資を行いやすい環境にあるだけなのだろうが…。（お金がないスタートアップの話もよく聞くので、一概にこうとは言えない）

逆に、体力はあれどモチベーションのような不確定なものに投資を行わない大企業などは先行投資ではなく成果報酬となりがちだ。社員が多い場合はなおさらその傾向がある。こういう企業では残念ながら、経営者は今エンジニアに払っている給料が十分なものだと考えているので、エンジニアの給料を上げるなんてことはほとんどしない。開発環境（PCなど）への投資のような、比較的安価な先行投資すら知ったことではないという経営者も多いのも事実。

PCの性能は生産性に直接繋がるが、残念ながらモチベーションへの投資がそのまま利益に繋がるわけではない。そのため、こういった先行投資を行わない企業で働くエンジニアが自分の給料を上げてもらうのは、大変な活動となりがちだ。

そのためにはエンジニアは何をするべきか。成果が見えにくいのなら、実績として結果が残ることを行うしかない。ここで言う結果とは、 直接的な会社の利益 である。

エンジニアの給料を上げる方法（例）

直接的な会社の利益とはどういったものか。以下は簡単な一例。

例えば、 社内のワークフロー改善を行い続ける ようなことだ。これはモチベーション改善や環境改善とかではなく、もっと根本的な、仕事の工数を削減するようなワークフローの改善という意味。削減された工数はだいたい数値に現れるし、改善したことによって社員や顧客の満足度が向上したのならなお良い。いわゆる業務コンサルのような仕事。

または、実際に 自分が仕事を引っ張ってくる 選択もある。自分が所属している会社が中小企業であるなら、自分がそれなりの仕事を引っ張ってくれば間違いなく会社の利益となるからだ。（これは営業のような仕事…。）しかし、所属している会社が大きいとこれは難しい。大企業ではそれなりに単価が高い仕事を求められがちなため。

このような、直接会社の利益となる活動を行うことが確実にエンジニアが給料を上げる第一歩だと考えた。エンジニアではあれど、直接的な利益を生み出そうと思うとエンジニア以外の仕事もこなさなければならない。

この結果を持って、「私は業務のワークフローを改善し、結果として○時間の工数を削減した。（会社のために仕事を持ってきた）そして今後もこの活動を行い続けるため、私に投資してもらいたい。」と強気に役員とかに凸して認めてもらおう。

エンジニアらしい選択肢として、 エンジニアとしてめっちゃ頑張る （ヘルプ入りまくって、ツール作りまくって、社内活動頑張る）という選択もあるが、これで給料が上がるかは難しい話だ。その活動を認めるかどうかは経営者次第なところが大きく、会社としてのエンジニアへの理解が求められる点でもある。（こういうことができる人は、エンジニアへの理解がある会社で働くべきでは）

おわりに

エンジニアが給料を上げるには、例えば次のような、直接的な利益を生み出すエンジニア業務外の活動などが効果的だという話をした。

業務の工数を削減できるようなワークフロー改善の継続（コンサル）
自分が仕事を引っ張ってくる（営業）

キーワードはおそらく「会社の利益」と「継続」。

エンジニアへの理解が無い会社だと、エンジニアの満足度向上などモチベーションに関わる活動のほとんどは評価のポイントにならないので、その点は注意。

給料を上げる難易度は会社によって違う。エンジニアへの理解があり、なおかつ体力のある企業であれば給料を上げることは容易だろう。しかし、エンジニアへの理解が無い会社であるなら、それは難しいものになる。多くの企業では管理職になることで給料が上がるキャリアプランが準備されているが、これもエンジニアとして働きたい人には辛い選択でもある。

どうしても難しそうなら 転職するしかない（オススメ）

2018-12-20

大規模アプリ開発系コンテストでの生存戦略

ポエム

ここで言う 生存戦略 とは、いかにコンテストで勝ち抜くか、という点に焦点を当てたものだ。コンテストでの優勝にはある種の運、例えば発表する環境や審査員のバックグラウンドなども関わってくるため、優勝を目指すのではなく、いかに優勝に近付くことができるかという記事。

本題

大規模なアプリ開発系のコンテストでは、単純なアプリを作るだけでは審査員の目に止まらない。

こういったコンテストでは大概、そのアプリを使うことによって 日常に起き得るどのような問題を解決できるのか という点が最も重要視されており、これをクリアすることが開発者にとっての最初のハードルになる。（中小規模のコンテストでは純粋な面白さが重視されることもあり、この限りではない）

だからといって、ただ単純に問題を解決できるアプリを応募しただけで勝ち抜けるという話でもない。

自分がいくつかのイベントに参加し、実際に多くのチームの発表や作品を見て感じた、勝ち抜くためにアプリに組み込むべき基本的な要素は次の4つだった。この何れかが抜けているだけでコンテストで勝ち抜くことは難しくなる。

問題提起
解決方法の提案
結果と規模
フィードバックと反映

この要素は必ず必要なもので、ほとんど例外はない。（ハッカソンは別）

また、コンテストで会場展示・プレゼンを行う場合は、この4つの要素を端的に分かりやすく伝えるためのトークスキルなど、マーケティング能力のようなものも必要になってくる。優勝しようと思うのであれば、ここまでの準備を完璧にこなす必要がある。

以下の項目では、各要素で何を行うか・どんな点に注意すれば良いかを記載している。

問題提起

アプリを開発する前に、まずは身の回りでどのような問題が発生しているかを探る必要がある。そしてコンテストに応募するアプリはその問題を解決するものであるものが好ましい。具体的な問題へのソリューションであることで説得力をもち、審査員に納得感を与えることができる。

さらに、ここで提起する問題はグループの日常的な問題であればなお良く、ターゲットは若ければ若いほうが良い。なぜなら若い世代のグループ、例えば学校のクラスの間で話題になれば、利用者は特に爆発的に広がりやすいからだ。より広い範囲で問題を解決できるものはそれだけ評価が高い。

コンテストではそのアプリが正式に公開された後の道筋が見えるかどうかも一部では評価の対象となる。ただ問題を解決するだけでなく、利用者をどのようにして増やすかも考えなくてはならない。この時、例えばターゲットが若い世代のグループであり、実際に問題解決を行えており、口コミで広がりそうなものであれば評価はより高いものとなる。

ポイント

身の回りの、誰もが感じるような問題を提起する
グループか若い世代、またはその両方が抱える問題を提起したほうが良い
提起される問題は誰もが納得できるものである必要がある
- ニッチな問題でも、具体的な例を見せるなどでカバーは可能

解決方法の提案

提起した問題をどのようにして解決しようとしたかという部分。この部分が実際にアプリ開発を行うフェーズになる。

まず、提起した問題をどのようなアプリで、どのような機能で解決に導くかを考えなければならない。そしてここで提案する解決方法は確実に現在の問題を解決、または緩和できるものでなければならない。この解決方法は難しい技術や最新の技術を使うよりは、簡単でも 現実的 であるほうが好ましく、結果として納得感も与えられる。（作るのも楽だし、展示やプレゼンをする場合は質疑応答も答えやすい）

実際のアプリ開発だが、ここではできるだけUI/UXに拘るべきだ。審査員は背後の技術やコードにはほとんど興味を持たず、問題に対して得られるソリューション、そして扱いやすさや操作感でアプリを評価する。APIの設計やソースコードのロジックに拘るならば、その時間をできるだけフロントエンドの開発に当てたほうがコンテスト的には良い。

ポイント

問題を確実に解決・緩和できる解決方法を提案する
簡単でも現実的な解決方法と技術を提案する
バックエンドには拘らず、フロントエンドにできるだけ時間を割く

結果と規模

提案した解決方法を実施した結果、実際にどれほどの規模で問題を解決することができたかの項目。具体的にはユーザーテストを行うフェーズ。

多くの作品は 解決方法の提案 で止まってしまって、ユーザーテストまで行われていないことが多い。しかしこのユーザーテストはコンテストで勝ち抜くためには必須と言っても良い項目であるため、必ずやっておいたほうが良い。ユーザーテストを実施していないのであれば、その作品はユーザーテストを実施した他の作品に敗北することになる。

なぜ重要かというと、このフェーズをこなして具体的なテストの年齢層や手応えを提示することでより強い納得感を審査員に与えることができるからだ。ここで得られる納得感は何よりも重要で、単純なユーザーテストの結果だけでなく、例えテストだとしても 実際に運用された事実 を審査員に印象付けることができる。幅広い年齢層にテストしてもらえたならなお良く、得られる納得感も強いものになる。

他にもアプリ以外の面だが、開発者の行動力やマーケティング能力、広域的なコミュニケーション能力などを評価してもらえる可能性がある。これは公開後にアプリを広めることができるか、ユーザーが望むものを作ることができるかなど、先述した そのアプリが正式に公開された後の道筋 と繋がっている。

ポイント

解決方法の提案 で終わらないこと
ユーザーテストを行い、提案する解決方法の納得感を与える
ユーザーテストを行った事実、実際に運用したという事実で印象を与える

フィードバックと反映

ユーザーテストは 結果と規模 で終わりではない。フィードバックはそれに対してのアクションとセットだ。実際にユーザーテストを行いどのようなフィードバックを得たか、そのフィードバックをどのような形で実現したか（または、どのような理由でフィードバックを実現しなかったか）も重要な点になる。

ユーザーテストの結果どのようなフィードバックを得たか、そしてそのフィードバックに対しての自分のアクションをセットにして提示することでより強い納得感を審査員に与えることができる。自分のアクションをセットにできないのであれば、そのフィードバックは提示しないほうが良い。

これもアプリ以外の面となるが、フィードバックの反映は実際、フィードバックから問題点や妥協点を探り、自分のアクションに落とし込めるかを問われる。これは先述したように、ユーザーが望むものを作ることができるか、またはアプリそのものの寿命にも関わる部分であるので、このあたりも評価される可能性がある。

ポイント

フィードバックは必ずアクションとセットで提示する
フィードバックに対してどのような改変を行ったか、行わなかった場合はなぜそうしたのかを提示する
協調性を求められる部分なので、そのアクションに至った結果もあったほうが良い

おわりに

納得感、納得感としつこく言ってきたが、これは本当に重要な点で、コンテストで勝ち抜こうと思うなら最も意識しなければならない点になる。なぜなら、どれだけ良い物を作ってもその意味や熱意を相手に伝えることが出来なければ、絶対にコンテストを勝ち抜くことができないからだ。

コンテストを勝ち抜く作品には単純に問題を解決する力（アプリの品質）のみならず、今後実際に広く運用される未来が見えるか、その際に確実に様々なシチュエーションで問題解決に貢献できるかも問われる。この部分をクリアするには幅広い層の実際のユーザーテストとフィードバックが必要不可欠であり、これを行うためのマーケティング能力や広域的なコミュニケーション能力も必然的に求められる。

最後になるが、企業のAPIを活用したコンテストの場合、その企業の全てのAPIを使う必要はないということをアドバイスしておく。LINE BOOT AWARDSは LINE Messaging API と LINE Clova を使ったコンテストだったが、最優秀賞の2作品はどちらもMessaging APIしか使用していなかった。結局求められているのは、どのような問題を解決できるか、ということだったのだ。

2018-12-18

2018年の振り返り

振り返り

2018年も残り1週間ちょっと、今こそ今年の振り返りの時期ではないでしょうか。

この記事では自分の今年の振り返りを行います。とはいっても今年は大したことしてませんでした。来年は頑張りたい気持ち。

仕事

そのうち転職するという意思表示まではしましたが、どこに転職するとかしたとか、そういうのは今のところありません。退職エントリーも書いてないし…。

業務では相変わらずサーバー周り（バックエンド、フロントエンド、AWSとかIoTとか）を担当することが多くて、そのへんの知見は貯めさせてもらったかなと感じます。特に、インド人のエンジニアと1週間ランチ行ったのは刺激的でしたね（料理も）。

イベント

小さなところには何度か顔を出させてもらいましたが、今年はやっぱり LINE BOOT AWARDS でしょうか。このためにわざわざ東京まで行きました。（秋葉原を練り歩き、唐揚げ食べ放題を食べて帰った思い出）

shiopon.hatenablog.jp

優勝できなかったけど、いろいろと学びはありました。1125作品中の30作品くらいに選んでもらえたのも嬉しかったし、コンテスト型発表会の生存戦略とか、そういうところを自分で考える良いきっかけになりました。（これの感想の記事書いてないですね。下書きのままだった…）

あと技術関係ないけど、12/13のSPYAIRの大阪ライブに行ってきました。テンション上がっていたのか、今となってはもう何も思い出せないライブです。

www.spyair.net

技術

AWS

やはり自分の中で外せないのはAWSで、仕事でも個人でも開発は1年中AWSと共にありました（去年もそうだったかも）。特にハッカソンみたいなスピード感が必要な開発のときはAWSに助けられっぱなしで、やっぱりちょちょいって作る時の Lambda + API Gateway + DynamoDB は強いんですね。

去年・一昨年くらいからAWSを初めてもうだいたい一般的なWebアプリとかストレージとかには小慣れてきたくらいでしたが、今年は特に画像解析とかAWS IoTとKinesisで大量データ処理とかちょっと変わり種を触らせてもらう機会が多くて、流行りの技術にちょっとは乗っかることが出来たかなという印象です。

CloudFormation
Kinesis（Data Streams、Data Firehose、Video Streams）
Redshift
Rekognition
AWS IoT
EKS
etc

GitHub

公開したリポジトリはプラクティス的なものが大半でした。リポジトリの整理と称して雑多なものを削除したらだいぶスッキリしてしまったのでちょっと思いついたやつをぽこぽこ生やした次第です。

以下思い出。

shiopon.net は自分の公開Resumeとして作成し始めたページですが、文章を考える段階で燃え尽きました。つまり未完成ですがこれはGitHub Pagesで公開中。来年迎えるまでには書ききってしまいたい。。。

handbook は 自分なりの攻略本を作ろう という個人的な企画で作り始めていて、最初はGitBookでHTML生成して個人のドメインで公開して〜ってやっていました。正直面倒くさかったのでGitHubのリポジトリでmdファイルをまとめる形で作りなおしてます。今の所GitBook時代の遺産を多く書きなおしている状態でまともなページは少なく、荒削りなページも多い…。

redux-starter-kit は自分がReduxに熱かった時に作っていた自分用のテンプレートです。公開しているのは「俺はRedux派の中でも modular style 教の人間だ」というのを主張するためでもありました。Nuxt.jsが生まれた今、自分の中でのこいつの存在意義は…。

line-bot-frame はAWS上で簡単にLINE BOTの環境を作成できるCloudFormationのテンプレートとLambdaのコードです。LINE BOT作るハッカソンで活躍します。（レスポンスのメッセージタイプにいろいろ対応したらみんな使ってくれるかな）

cloudformation-chain は自分がCloudFormationのテンプレートを死ぬほど書いていた頃、ネストしないスタックを連続で作成するソリューションが欲しかったので作ったものです。これを使えばネストしてないスタックを沢山作れる。

express-controller-pattern はExpressのコントローラーパターンを試した例。これはExpressのベストプラクティスとなり得るか…。

その他

大雑把に、今年は特にこれ触ったなあと印象に残った技術（AWS除く）。

LINE Messaging API
Kubernetes
Nuxt.js
Redux
Express
FFMpeg

LINE Messaging API は実際にハッカソンで使ったってのもありますが、考えられる限りで最強のユーザーインターフェースだと感じました。手軽に実装できるし、ありがちだけど煩わしいデザインの作成がいらない、メッセージを表示するための様々な機能が存在するなど。開発者にとっても楽できる部分が多くて、良い物でした。LINE BOTを作成する際は line-bot-frame も参考にしてください。

Kubernetes は個人で勉強していましたが、結局実際の業務で使うことは無かった…。来年は開発環境とかに組み込んでいけたらいいなと。

Nuxt.js は年末に触り始めたフレームワークで、なんというか、Webアプリとかマイクロサービス作成における銀の弾丸な印象。今からWebアプリ作るんならとりあえずこれ使っとけ！って言えるくらい、いろいろな管理がとにかく楽で、VueとVuetifyのおかげもあってロジックを書けないデザイナーとかでもとっつきやすいのも嬉しい。あんま使えてないので来年も使っていきたい。

さいごに

振り返ってみると、今年はずっとNode.jsでWeb（主にSPA）やってましたね。スーパープログラマーである皆様の振り返りと見比べると、随分見劣りするものですが…。来年はもう少し活動して、いいかんじのこと書けるように頑張りたい気持ちでいっぱいです。

来年はとりあえずKubernetesとKnative使ったOSSなんか作りたいなあと思ってたら、 GitLab Serverless に先を越されていました。知覚動考ですわ…

Shiopon Labo

しおぽん（@shiopon01）の個人ブログです

WindowsでCaps LockをCtrlに、JISキーボードをUSキーボードにする方法

Caps -> Ctrl

JISキーボード -> USキーボード

参考

今更だけどghqを使ったリポジトリ管理を布教したい

本題

Goのインストール（準備編①）

GOPATHの設定

ghq（とpeco）のインストール（準備編②）

ghqの設定

スーパージャンプ！（本編）

仕組みとか

Gitリポジトリのクローン

ローカルにしかないリポジトリの管理

実行例

エンジニア、会社に給料を上げてもらうのは難しい説

本題

エンジニアの給料を上げる方法（例）

おわりに

大規模アプリ開発系コンテストでの生存戦略

本題

問題提起

ポイント

解決方法の提案

ポイント

結果と規模

ポイント

フィードバックと反映

ポイント

おわりに

2018年の振り返り

仕事

イベント

技術

AWS

GitHub

その他

さいごに