ikasama over technology

忘れたくないことを忘れないために

Trello で夫婦共同 ToDo List を作った

個人的には少し前から Trello で ToDo List を作っていたけど、 最近は妻 *1 にも脳のメモリをオーバーするタスクが増えてきたので、一緒に管理することにした。

f:id:ikasamak503:20200107021139p:plain
Trello ボードの様子。ボード名は 人生

ルール

運用始めて一週間も経ってないので、まだ暫定だけどこんな感じ。

1. 週に一度、その週にこなすタスクを計画する
  • weekly レーンに今週やる予定のタスクを優先度順に並べる
  • 各レーンのタスクの優先順位や来週以降のざっくりした計画を確認する
2. 完了したタスクは都度 Done レーンに移す
3. 思いついたタスクはいつでも各レーンに投入してよい
  • 優先順位も好きに並び替えて良い
4. 週に一度、その週に完了したタスクを振り返る
  • Done レーンのタスクの完了を確認してアーカイブする
  • 完了した数や完了できなかった原因を振り返って、次回の改善にネタにする

あらゆるタスクを漏れなく管理するのは息苦しいので、 ぱっと思いついたが忘れたくないものをカジュアルにメモしておいて、 忘れないようにしていくのが無理がなくていいと思う。

妻の反応

妻は Trello のようなタスク管理ツールを使ったことはあまりないと思うけど(たぶん)、 アプリもサクッとインストールしてもう使いこなし始めている様子。 運用初日で 2 つのタスクを Done レーンまで持っていっていた。えらい。

f:id:ikasamak503:20200107032707p:plain
報連相もできている。えらすぎる。

期待する効果

  • 忘れるとまずいタスクを忘れずこなせるようにする
  • お互いのタスクを見えるようにして、負荷の確認やサポートができるようにする
  • うまくできたことを褒める習慣をつくる。良いコミュニケーションのきっかけにする。 *2
  • QoL の改善

まとめ

  • 夫婦共同の ToDo List を Trello のボードとして作った
  • 毎週振り返りして改善や褒めるなどする

しばらく運用してみて、何かアップデートがあったらまた記事を書こうと思う。

*1:厳密にはまだ入籍していないので婚約者。近日入籍予定。なので ToDo List にも入籍タスクがある。

*2:僕が寡黙で家であまり喋らないので

PHP カンファレンス北海道に行ってきました

phpcon.hokkaido.jp

セッション → アンカンファレンス → スポンサー LT → LT → 懇親会 という流れで見てきました。

感想: セッション

以下のセッションを聴講しました。

speakerdeck.com

PHP だけに限定せず、 汎用的なプログラミングや、 PHP を用いたアプリケーションの作り方を含んだ学び方・考え方の話。 職業エンジニアとなるための実践的な道標だと思います。いくつかは僕も過去に通った道ですが、またどこかで改めて振り返ってみようと思いました。


speakerdeck.com

フルリニューアルの話、前職では医療系のマッチングサービスをやってて、やっぱりフルリニューアルしてたので、しきりに「わかる」と心のなかで連呼していました。*1

  • 目的を見失わない。フルリニューアルはゴールではなく、スタート。新しい価値を素早く届けるための基盤を作ること。
  • フルリニューアルを行ってマイナスのインパクトが無い、ということはない

このあたりは金言だと思います。


speakerdeck.com

ブラウザテストがあると安心できるよね、やってみよう、という話。僕もほぼ同意見です。 API サーバーなら JSON 返してくるだけなので PHPUnit の Feature Spec で十分なんですが、 HTML をサーバーサイドでレンダリングする Web アプリケーションの場合はそうはいかないのでこういうテストが欲しくなります。

Selenium の難点は若干重いこと。ここさえなんとかなれば・・・。 あと Laravel Dusk を知れたのは大きな成果でした。次の Laravel Web アプリ案件に導入する予定です。


speakerdeck.com

AWS CDK、初耳でした。 プログラミング言語からコンパイルして CloudFormation テンプレートができて、デプロイまで出来るやつ。すごい。 似たようなツールに Pulumi があるけど、コレはお金がかかるので、 AWS がサポートしていて無料で使えるのは導入しやすそう。 でも僕は Terraform をやっていきたいので CDK は一旦様子見かな……。

感想: スポンサー LT

speakerdeck.com

弊社です。 書いてあることは社内の人からするとあるある、という感じの内容なんですが、社外の人はどういう印象を持たれたのか気になります。


speakerdeck.com

ス・マイル制度がいいな〜って思いました。特にアウトプットの価値を定量化するところは、見習っていきたい。

感想: アンカンファレンス

speakerdeck.com

MySQL, PostgreSQLアーキテクチャの違いとかあまり意識したことなかったので、それを知れるきっかけができたのは良かったです。

感想: LT

LT らしい LT を聞いたのは意外と始めてでした。 内容よりも、時間きっちりで喋りきってたり、勢いがすごいな〜、という印象のほうが強かったです。 個々のスライドのリンクは以下の Qiita 記事を参照してください。ちなみに LT 以外のスライドもほぼ網羅されています。

qiita.com

感想: 全体を通して

PHP カンファレンスと銘打ってますが、それに関連する技術も幅広く取り扱っていて多彩でした。 知らない技術スタックや考え方にふれるキッカケを得られたのが、自分にとっては大きな収穫だったなと思います。

その他

いま担当している案件で一緒に仕事している札幌オフィスのメンバー数名と直接会って話ができました。 今回の PHP カンファレンス北海道の参加の裏目的として達成できたので良かったです。

勉強し放題制度

カンファレンス参加に伴う旅費や宿泊費はゆめみの勉強し放題制度を利用して経費精算できます。*2 すごいぞゆめみ! でも本当は怖い。 経費精算するためにはアウトプットが必要なので、今必死になってコレを書いています。

www.yumemi.co.jp

懇親会のメシ

f:id:ikasamak503:20191001162152j:plainf:id:ikasamak503:20191001162155j:plainf:id:ikasamak503:20191001162158j:plainf:id:ikasamak503:20191001162200j:plainf:id:ikasamak503:20191001162204j:plain
懇親会のメシの写真。めちゃくちゃウマかった。

札幌についての知見

*1:僕はフルリニューアルの途中で辞めちゃったけど。今どうなってるのかなあ(遠い目)

*2:今回は金額が約 8 万円とでかいので、レビューが入ることになっています

株式会社ゆめみに入社して 2 ヶ月が経ちました

2019 年 7 月 1 日に入社したので、ちょうど 2 ヶ月です。 1 ヶ月や 3 ヶ月で振り返ることが多い気がしますが、個人的にはこのタイミングがちょうど良かったのと、気分も少しのったので、書くことにしました。

振り返り

7 月: オンボーディング、 Laravel と AWS 認定の勉強

最初の 1 ヶ月は、会社の売上に直接貢献する仕事はありませんでした。

ゆめみでは職能ごとのチームに所属した上で、そのチームが担当しているプロジェクトに参画するのが主流です。 私が所属したチームには 7 月の当初、ちょうどいいプロジェクトがありませんでした。 なので、使用予定の技術スタック ( Laravel, Lumen ) や AWS 認定の勉強をしていました。 結果的に AWS 認定は SAA を取得できたし、Laravel や Lumen に関しては腰を据えて勉強できて良かったと思います。

ikasamak503.hatenablog.com

ちなみに、資格取得の受験費用は勉強し放題制度によって全額補助されます。

note.mu

仕事がなくなったときこそ冷静に

一方で、入社時期に関わらず、メンバーや職能によってはクライアントワークが無いという状況は度々発生しています。 例えば、

  • 新規案件の受注を見据えて稼働予定を埋めていたが、最終的に失注した
  • サーバーサイドの開発規模を縮小することになった
  • その他、やんごとなき事情

とまあ、いろいろな理由で仕事がなくなることがあります。なくなったものは仕方ないですね。 とはいえ、仕事がなくなったからおしまい、とはせず、失注や仕事がなくなった事象に対する振り返りは行われているようです。 また、クライアントワークがない時期は自己研鑽や社内用ツールの企画・開発を通して将来への投資も行っています。

オンボーディング

note.mu

ここに書いてあるように、オンボーディングはまだ試行錯誤している最中という感じです。 僕が感じた課題点としては、

  • 情報が様々なツールやサービスに分散していて検索性が悪い
  • チームごとのオンボーディングは独自形式でバラツキがある

といったところです。 ちなみに、オンボーディングの一つの目安として「会社批判ができるようになる」という目標があって、 未だに会社批判をあれこれ考えていたりします。

8 月: クライアントワーク

4 月から開発している新規案件で、既存メンバーの引き継ぎという形で参画しました。 サーバーサイドの設計・開発という立場ですが、ものはほぼ出来ているので、いまはバグ改修や内部の改善といったタスクがメインです。 意外と Docker や AWS 関連の知識がチーム内で一番長けていたので、その分野でよく手を動かしたりレビューをやっていました。

入社して 1 ヶ月だけどお盆は 1 週間有給をとりました

ゆめみのメンバーは有給取り放題です。これは入社して間もないメンバーも対象です。

note.mu

法律や就業規則としては入社して半年経ってから有給付与ですが、それまでの有給が無い期間、この制度によって有給を取得することができます。

リモートワーク

週1回程度の頻度でリモートワークを実施しています。 現時点でリモートワークは、関わるプロジェクトマネージャーに確認をとる承認制となっています。 これは、プロジェクトによっては物理オフィスに出社してもらわないと困るとうケースがあったり(あるのか?)、 オフィスワーク推奨という考え方もまだあるためです。

note.mu

個人的には、IT エンジニアが働く場所なんてどこでもいいと思っているので、オフィスワーク推奨はよくわかんないですね。 一方で、リモートワーク推奨にしようという委員会ができていたり、 直近だと来年の東京オリンピックの時期は通勤どうするんだ、リモートワークか? という議論がされていたりします。

リモートワークの工夫の話をすると、最近は札幌オフィスのメンバーがプロジェクトにジョインされたこともあって、 ミーティング時は東京オフィスに数名集まっていても、全員が離れた場所から Zoom に繋ぐということをしています。 こうすることでビデオ会議で聞こえづらくなりがちな拠点内の会話がなくなって、全員が対等にミーティングに参加できていて良いです。

他、体験したゆめみの文化・制度

ウェルカムランチ制度

ざっくりいうと新入社員とランチ行く場合は会社から補助するよ、という制度。 いろんな人とランチ行けるので、入社時の繋がりブーストとして良いと思います。

プロポーザル・レビュー・リクエス

やりたいことをを明文化して誰かにレビューしてもらう制度。 全社員 CEO なので、やりたいことがあれば誰もが何でもやれる権限を持っているんですよね。 とはいえみんなそれなりに常識人なので、最初からぶっ壊れたプロポーザルが出てくることはないようです。

Bad News Fast

ゆめみには Bad News Fast という文化があり、「悪い情報」や「リスク」を最速で共有する Slack チャネルがあります。 これには、2 つの側面があると解釈しています。

  • 重大な問題を隠さずに報告できる雰囲気を作ろう
  • 全社をあげて一緒に問題を解決しよう ( 誰かを責めるものではない )

なかなか慣れない人も多いようですが、とても良い文化だと思います。

感想

  • 仕事がないとか、そんなこともあるんだ
    • 自社サービスをやっていた頃は無限に仕事があったので逆に新鮮
    • 勉強する時間がとれたのは良かった
  • 社内制度が素早いサイクルでアップデートされていくので、全部を追うのは大変
    • AWS みたい
    • 必要なものだけウォッチしよう
  • 制度の背景にある考え方を身につければ、すぐにキャッチアップできると思う
  • 有給取り放題やリモートワークで生活に融通がきくようになってよかった
  • ( オフィスのディスプレイがでかくて良いので ) 久しぶりに出社したいという気持ちになった
    • しかし、たまに冷房が効きすぎていて体調を壊す

次の目標

次は入社半年たったあたりで振り返ります。年末か年明けになると思います。

  • 会社批判
  • AWS 認定をもう 1 つとる
  • 通勤が楽なところに引っ越す
    • まだ、なんだかんだ物理オフィスへの出社が求められてる雰囲気がある
    • 今の通勤はさすがに時間がかかってしんどい
  • ゆめみの制度を使い倒す
  • 月 2 回程度のアウトプット

We are hiring!

株式会社ゆめみでは、成長意欲が高く、会社の制度やルールのあり方を再考して変えていきたいと考えていて、 入社して1ヶ月はタダ飯食いまくりたいし、有給もとりまくりたいと思っているメンバーを募集しています!

www.yumemi.co.jp

選考に入る前にざっくばらんな話ができるカジュアル面談もあるので、話を聞いてみたいという方は何らかの手段で僕に連絡をとるか、 以下の求人一覧ページの応募フォームからご連絡ください。

hrmos.co

awswakaran.tokyo #1 に行ってきました

www.awswakaran.tokyo

↑主催の開催後記です。 スライドへのリンクとかはこちらを参照ください。

感想

あるある要件を実現したい時のハマりがちポイントとその対策がわかった

「CloudFront にだけ IP 制限かけるだけで本当に大丈夫ですか?」 by @euxn23 さん 「Universal Application にありがちな LB ガチャ問題を解消する」 by @potato4d さん

  • どちらもフロントエンド向けのインフラ話でした
  • サーバーサイド勢からすると最初は「???」という感じ
  • 最後まで聞くと、ちょっとわかった気がした
  • 弊社はフロントエンドに最適化したインフラ構成を誰が考えているんだろう?

ようわからんけど入門するときのとっかかりが知れた

AWSが分からん人に送るFargateのススメ」 by @nametaketakewo さん 「CI/CDわからん」 by @y_ohgi さん

  • Fargete はちょうど使い始めたところだったので、色々学びがあった
    • 例えば Rails + Sidekiq worker とかはそれぞれ別サービスに分けちゃって良さそう
    • migration も別サービスに分けて完了したら即死させるとか
      • ここは単なるタスクの実行でもいい気はする
  • Ci/CD 話、 migration は 1 回 / 1 デプロイ!

当日限定の非公開コンテンツ

「そんなことあるんだAWS」 by オタクさん

  • 話聞いてるだけで面白かった
  • AWS の裏側がどういう挙動をしているのか探求する物語
  • そんなことあるんだ……
  • AWS ドキュメントの正式版は英語版、翻訳はあくまで参考なので違和感を感じたら原典にあたろう!

まとめ

  • ぜんぜんわかってない AWS が少しわかった
  • S3 難しい
  • そんなこともある
  • 英語のドキュメント読もう!

AWS 認定ソリューションアーキテクト – アソシエイトとして認定されました

aws.amazon.com

これをとりました。スコアは 909/1000 でした。 公開している認定情報はこちら

AWS 認定の種類やランクについては公式のドキュメントや、他の記事に譲ります。

AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS

バックグラウンド

AWS の知識や経験は初心者を脱しているかな〜というレベルです。

  • もともと SIer でオンプレミス中心のインフラエンジニアを 3 年半程度
  • AWS の実務経験は 1 年半程度
    • AWS 上にある自社開発の Web サービスのインフラ全般をメンテナンス
    • 新たに開発したアプリケーションやテスト環境の AWS 設計と構築

試験前の対策

試験前はがっつり勉強するというより、これまでの知識と経験、ちょくちょくインプットしてきたものを振り返るような形でした。

  1. サンプル問題 *1 の確認
  2. 模擬試験 ( ¥2,000 )
    • これで 9 割程度のスコアだったので新たに知識を詰め込まなくてもいけるだろうと判断
  3. Web 上にある問題集を眺める
    • ところどころ、内容が古かったり回答が間違っているものがあり
    • 未経験者・初学者はまず公式ドキュメントや書籍から学習する方がいいと思う
    • 経験者が振り返りに使う分にはコスパがいい

準備期間は 1 週間でした。

どうやって知識や経験を得るか?

これだけでは AWS 認定の取得を目指す人の参考にはならないので、個人的にどうアプローチすればいいと思うか書いておきます。 ほとんどが継続的に取り組むものなので時間はかかりますが、この方法で得た知識や経験は認定取得に関わらず確実に役に立つと思います。 試験内容も単なる暗記ものではなく、「ある前提条件においての最適解はどれ?」というような問いがほとんどのため、試験前に暗記して突破できる類のものではないです。

知識

  • 入門者向けの座学
    • 書籍で体系的な知識、 AWS で設計するときの考え方を学ぶ
    • 有料のトレーニングを受ける
  • 既に AWS 上で稼働しているシステムの AWS 環境を参照できるなら、どういう設計になっているか見てみる
    • 各種サービスの使い方や設定の意味を調べてみる
    • 基本は AWS のドキュメントを見て、それでもわからなかったらサードパーティの解説記事を見てみる
  • 新サービスの発表やアップデートをチェック
    • 全部に目を通す必要はなく、単に気になったものや既に使ったことあるもの、これから使う予定のあるものをピックアップしよう
    • 個人で AWS のアカウントを作ると毎週 AWS から最新のお知らせがメールで届くのでオススメ
      f:id:ikasamak503:20190721023954p:plain
      AWS からの最新のお知らせ
    • イベントレポートも手軽に最新情報をチェックできるので気になるものがあれば見てみよう
  • 先輩や同僚で詳しい人に相談や質問する
  • 勉強会に参加する
  • AWS がやたらと推してくるサービスやアーキテクチャを知る
    • DynamoDB とか DynamoDB とか

書籍は知識が体系的に、かつコンパクトにまとまっているので入門としては優れていると思います。 しかし AWS のサービスはアップデートが早く、特に紙媒体の情報は陳腐化しやすいです。 したがって、継続的なウォッチと知識のアップデートは必要です。

経験

  • 何はともあれ構築してみる!
    • 個人でも無料枠 *2 があるので、ちょっとしたサービスを動かすだけなら課金されない
    • 有料サービスも大抵が従量課金なので、数時間使ったくらいなら大した額にならない
    • まずは写経! チュートリアルはインターネットに溢れている
    • インフラをコード化とか高度なことはしなくていい、まずは Web の画面からポチポチしよう
  • チュートリアルができたら自分なりの工夫を入れてみる
    • 例えば
    • パブリックサブネットにあるデータベースをプライベートサブネットに置いてみる
    • メンテナンスしやすいセキュリティグループを考えてみる
    • シングルインスタンスを Auto Scaling させてみる
    • CloudFormation ( インフラのコード化 ) でやってみる
  • 他のチュートリアル悪魔合体してみる
  • トラブルシューティングする
    • 失敗からはたくさんのことを学べます
    • 本当はトラブルは無いに越したことないけどね
  • 勉強会等で登壇する
    • 得られた経験を整理するいい機会です
    • 僕はまだできてない

本試験の本人認証における注意点

TL;DR

  • 顔写真付きの証明書は運転免許証またはパスポートが無難
  • 日本のマイナンバーカードは政府発行の証明書として認識されないようなので避けたほうがいい

本人認証の書類として顔写真付きの証明書を持参し、テスト前に機械でスキャンする必要があります。 当日はマイナンバーカードを持参しましたが、何度スキャンしても NG 判定となって先に進めませんでした。 テスト用端末ではチャットでオペレーターとコミュニケーションを取ることができ、 端末操作に関する質問や、オペレーターからの指示がきます。 何度もマイナンバーカードをスキャンしていると、オペレーターからこんな質問がきました。

「それは政府機関発行の ID ですか?」

思わず「まじか・・・」と呟いていました。

ikasama「日本の自治体が発行する個人番号を確認するカードです」
オペレーター「確認します、少々お待ちください」

といってしばらく待たされました。 しばらく待っていると遠隔操作ソフト *3 のセッションが開始し、オペレーターが画面を操作し始めました。 試験アプリケーションを閉じて Windows のデスクトップが表示されて「おおっ」となったり、管理者ユーザーっぽいものに切り替えたり。 証明書スキャナーを起動するスタンドアロンのアプリケーションを起動して、 マイナンバーカードをスキャンするように指示 *4 されたり。 最終的には顔写真を撮る用の Web カメラにマイナンバーカードを近づけて認識 *5 してもらうということに。 なんとか確認は取れたことになって、試験アプリケーションの証明書スキャナーはスキップして進みました。 これだけで約 30 分くらい費やして変に疲れました。

次は

AWS 認定を取得すると模擬試験が無料になったり、本試験の受験料が半額になる特典があります。 せっかくなので Developer Assoiate か SysOps Associate を目指そうと思います。

まとめ

  • 知識は定期的にアップデートしていこう
  • AWS の推しを理解しよう
  • マイナンバーカードはオワコン

*1:ここからダウンロードできます https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

*2:https://aws.amazon.com/jp/free/

*3:具体的な製品名の公表ここでは控えます

*4:この間、コミュニケーションの手段がないので Windows のメモ帳で筆談しました

*5: 見えづらいとか、 2cm くらいの距離に近づけて、とか色々めんどくさかった

マーソ株式会社を退職します

6 月 30 日付けで退職、昨日 28 日が最終出社日でした。 2018 年 2 月から、約 1 年半お世話になりました。

マーソ株式会社 is 何

( 2019 年 6 月末時点の情報です )

www.mrso.jp

MRSO という Web サービスを運営している会社です。 MRSO は、人間ドックや検診を全国の医療施設から検索・予約できるポータルサイトです。 登録されている医療施設数は、国内の類似サービスの中ではトップクラスの規模です。

他にもこんな事業をやっています。

  • MRSO で利用できるギフト券、マーソギフト券の販売
    • 健康をプレゼントするとう考え方
    • ご両親に人間ドックを受けてほしい! というユースケースが多いようです
  • 企業向けの健診結果管理システムの開発・運用 ( toB )

何をしていたのか

MRSO の開発・運営に必要なほとんどの領域を担当していました。 具体的には、

  • 新機能の開発やバグ修正
  • 問い合わせ対応
    • 現行の仕様や不具合の調査 ( ほとんどの仕様がドキュメントに残っていない )
    • 一部機能の設定変更
    • エッジケースの手動オペレーション
  • 障害時のトラブルシューティング
  • データの抽出
    • こんなデータが欲しいんやけど、を SQL にゴリゴリとトランスパイルしていました
  • 開発環境、テスト環境、本番環境のインフラメンテナンス
    • インフラに明るい人が社内に他に居なかった
    • AWS, Apache Web Server, Nginx, Docker, MySQL, Jenkins

こんなことをやっていました。

他にも片手間で、

  • 技術的な相談
    • こういうことを実現したいけどどうしたらいい?
    • 壁打ち役
  • Slack bot を作る
  • 分かったことをひたすらドキュメントを残していく
  • 新卒 3 名 ( ベトナム人 ) の教育
    • 議事録をとらせて、あとで一緒に振り返り
    • モブプロ + TDD

もやってましたが、特に教育に関しては思いつきベースで取り組んだものの、 もっとちゃんと考えてあげたかったな~と反省しています。

何を残せたのか

具体的な成果物として残って、特に活用されている ( と感じている ) 順に並べてみるとこんな感じです。

  1. 本番環境相当のテスト環境作成
  2. テスト環境 Docker 化
  3. 社内にあった Jenkins サーバーを AWS 上に引っ越し
  4. メルマガの配信作業を都度から 月 1 回にまとめた
  5. 仕様などを調査したドキュメント
  6. CakePHP 2.x -> CakePHP 3.x のコア機能移植
  7. 管理画面のセキュリティ強化
  8. WordPress Plugin & CLI 開発

特に 1. 本番環境相当のテスト環境 は社内・社外関係者含めてめちゃくちゃ使われています。 網羅的な状態パターンのテストができていないと、本番環境の状態の再現してテストする必要があって、 そのコストをすっ飛ばせるようになったのは大きいです。 構築当初に想定していた以上の ROI だったんじゃないかと思います。

なぜ辞めるのか

会社や上司、同僚の仕事に対する考え方が合わない

一言でいうとこれにつきます。 具体的には、

  • エンジニアがあまり大事にされないと感じる
    • 入社して 1 年間は HDD 搭載の低スペックマシンで開発してました。せめて SSD
    • 研究や技術に投資する時間が計画されない
    • 営業と運用のマンパワーでなんとかしている感
  • フレックス・リモートワークなし、 9 時 - 18 時は要出社
    • 実際は出社しないとできない仕事はほとんどない
    • リモートでコミュニケーションをうまく取れない人が多いのは事実
  • 保守的な考えの人が多く、変化を恐れがち
  • 技術レベルの高い人がいない
    • みんな見様見真似で CakePHP を書いている
  • チームで成果を出すことを真剣に考えていない
    • 要するに個人プレーの集まりで仕事をしている感
    • とりあえず人を集めてリソース効率高く仕事を振ることはできる
    • 成果の品質やフロー効率は考えられていない
  • あまり情報をオープンにしない文化
  • 期限を守ることが最優先され、品質の妥協や残業でカバーといった手を打ちがち
    • 事前にプレスリリース打ってるわけでもないのに、みたいなのがちらほら
  • オンボーディング、教育が無
  • エンジニア採用をあきらめている感
    • このまま居ても優秀な人には出会えなさそう

こういうことが積み重なって入社直後からモチベーションが下がり、 遅刻や欠勤が目立つようになってしまいました。 単純に体調が悪い日もあれば家で自己研鑽する日もあり、 そうやって身に着けたスキルや経験を仕事に還元していくスタイルでやっていました。 しかし面談では勤怠が悪いと評価はできないと通達されてしまい、 その際に働き方や今感じている問題を話し合いましたが、解決は難しいと確信し、退職を決めました。

2019/07/01 追記 評価と反省点、よかったところ

一方的に前職のネガティブな面を書いているように見えるので、上司や同僚からの評価と自身の反省点、前職でよかったことも書いておきます。

上司や同僚からの評価

Good Point

  • キャッチアップが早い
    • 入社数日でバグ修正の Pull Request 出してた気がする
  • インフラ、特にネットワーク周りが強くて助かった
  • 問い合わせへの回答が丁寧で的確
  • 仕事の仕方がスマート

Bad Point

  • 勤怠が悪い
  • 期限切れのタスクを抱えたまま報告がないことが度々あった
  • 特にクリティカルなものに関しては一人で考えて決める前に相談して欲しい

???

  • 先生みたい ( 新人談 )

反省点

  • 勤怠不良がアウトプットの物量にも影響し、結果として担当タスクの完了が遅れるなどした
  • コミュニケーションで誤解や不安を与えるような伝え方をしてしまっていたかもしれない
    • 良いことも悪いことも包み隠さず発言していたが、社内の文化からは逆行していたように思う
    • とにかく「論理的」に「正しい」主張をするため、冷たい印象を与えたかもしれない
  • もっとたくさんコミュニケーションをとったほうがよかったと思う
    • 特にエンジニア以外ともっと話すべきだったな〜
  • 新人の教育にしっかり取り組めなかった

前職のよかったところ

  • 休みを取りづらいという雰囲気はあまりない
    • あれだけめちゃくちゃ休みまくってたけど逆に気を遣ってくれてもいた
  • 性格の悪い人は居なさそうだった
    • そういう人も自然とフェードアウトしていくのかも
  • ビジネス面でもまだ伸び代があると思う
  • ルールが整備されていないので自分たちでルールを作っていける余地がある

2019/07/01 追記終わり

次はどうするのか

株式会社ゆめみ でサーバーサイドエンジニアとして働きます。よろしくお願いします。

www.yumemi.co.jp

ゴリラ.vim #4 に参加してきました #gorillavim

gorillavim.connpass.com

当日飛び入りで参加してきました。 今回は神回という声もあって、そんなタイミングで参加できたのは幸運だったなと思います。

各発表のサマリと感想

翻訳プラグイン作った by ゴリラ さん @gorilla0513

docs.google.com

github.com

  • コマンドやバッファで入力した内容を翻訳
  • GAS ( Google Translate ) + Go + VimScript で実装
  • バッファに文字列を入力して Enter すると逐次翻訳されていく様は見ていて楽しい
    • 学生の頃、英単語の勉強のために xyzzy で似たようなことやってたな~としみじみ

https://camo.githubusercontent.com/bb7ce3f10042c5266c6dac15afe6b70def11ec93/68747470733a2f2f692e696d6775722e636f6d2f657a4c437253472e676966
リポジトリの README から拝借

GWで初めてVim Pluginを作った話 by かまたけんし さん @knsh14

docs.google.com

github.com

  • Vim のバッファ上の選択範囲から GitHub のリンクを作ってクリップボードにコピーするプラグイン
  • 便利!
    • コードレビューとかで「ここの実装見てみて」といったアドバイスするときに URL 欲しくなる
    • いつもブラウザでアクセスしてアドレスコピーしてた
  • 今のところ GitHub と GitLab に対応

  • Vim Plugin の作り方わからん
    • vim plugin 作り方 [検索]
  • wandbox, 手軽にいろいろ試せる SandBox 環境
    • 便利!
    • Vim Script が試せるのは初めて見た

wandbox.org

terminal-api について by てんなし さん @tnnsh1

speakerdeck.com

  • terminal mode ( Vim 8.0 )
    • Vim から terminal を使える mode
    • VSCode の terminal と同じようなことができる
  • vim-in-vim 問題
    • terminal mode で Vim を開くと Vim の中に Vim がネストしてしまう

vim-in-vimasciinema.org

  • terminal-api を使うと terminal mode から親 Vim へ通信ができる
    • Vim でファイルを開かせたり、関数を実行させたり
    • terminal-api での実行できる関数には命名規則があり、 Tapi_ で始まるものである必要がある

tapioka.vim

Neovim 0.4.0 新機能 フロートウィンドウについて by ドッグ さん @Linda_pp

speakerdeck.com

  • 既存のウィンドウの上にオーバーラップしたウィンドウを作ることができる!
  • 従来の Vim ウィンドウと同じように使える
  • はみ出すときは自動で位置とサイズを調整してくれる
    • こういうところ考えなくてよくなるのは楽!
  • フロートウィンドウを使った Plugin 例
    • git-messenger.vim
      • カーソル位置のコミットログをフロートウィンドウで表示 github.com
    • vim-iced
      • カーソル位置の Clojure の評価結果をフロートウィンドウで表示 github.com
  • 惜しむらくは Neovim の機能というところ
    • 本家 Vim にもほしい!
    • それか Neovim に乗り換えるか

飛び入り LT by tamy さん @__tamy

github.com github.com

  • comamnd-line fuzzy finder の紹介
  • 作者謹製の Vim Plugin もある
  • バッファをたくさん開いているときのバッファ選択とかに強い
  • fzf はいいぞ!
    • ぼくも enhancd と組み合わせて使ってます

飛び入り LT by ujihisa さん @ujm

  • ライブコーディングが印象的でそれしか覚えてない、、、
  • grep コマンドを VimScript で実装してみることに
  • 「美しいけど動かないコードより汚くても動くコードのほうが無限倍良い」、至言
  • 小さく実装して QuickRun を回す
    • スピードが圧倒的に違う、、、
  • マニュアルを参照しながら実装していく
  • 最終的に出来上がったコード ( 所用時間: 15 分 ) gist.github.com

  • 米国に行かれるそうなので、これが日本で最後の LT になるかもとのこと

    • 最後に面白いもの見させてもらいました!

飛び入り LT by はやぶさ さん @haya14busa

  • vim-easymotion でタブ移動する vim-hinttab を作った *1

github.com

  • タブにラベルを付与して表示させて、それをもってタブ移動できる
    • タブ 4 つ以上開いてるときは便利そう
    • でもぼくは tmux 使うから Vim の中であんまりタブ開かないかも……

VimConf 2019 の告知!

vimconf.org

全体を通して

  • Vim 初心者なので半分くらい話わからなかった
  • プラグイン作ってみるのもいいかなと思った
  • その前によくわからないままコピペで継ぎはぎした .vimrc をまともにしたい
  • 最終的にゴリラ、犬、猫、ウーパールーパー、隼が登壇し、人類より動物のほうがたくさん発表してた LT 会になりました
  • ぼくの HN は ikasama でイカ *2 なので動物側として近いうち LT 枠で参加を目指します

*1:勉強会中に、、、

*2:アイコンの白矢印はイカです。後から生えた設定です。