hikariru

[hikariru]

アウトプットしてたらつながりが増えて助けられた話

この記事は 『エンジニアの登壇を応援する会』Advent Calendar 3日目のエントリに後日滑り込んだものです。

2018年の忘年LT大会がはじめての「エンジニアの登壇を応援する会」イベント参加でした。 2019年はちょっとだけ普段しりごみしていた種類のアウトプットやってみるようにしたら エンジニアコミュニティのゆるいつながりに助けられたのでお礼を兼ねて記事を書きます。

初勉強会スタッフ

初勉強会スタッフした

これまで物理的な行動を起こすことはとてもとても苦手だったのですが ちょうど求職中だったのもありふらっと勉強会のスタッフをしてみました。 テンパりやすい性格のせいでスタッフだけでなく参加者さんにも迷惑かけた面あるかと思います、ごめんなさい。 ただ、この行動を起こしたおかげでコミュニティの知り合いが増え、ゆるやかな心の支えを得ることができました。 みなさま本当にありがとうございました。

モッククラスの使い方ついての問いかけ

モッククラス、下から見るか？横から見るか？

悩んでいたことをインターネットの海に投げかけてみたら、つよい方々から丁寧にお返事をいただけました。

https://irof.hateblo.jp/entry/2019/07/17/233048

http://kyon-mm.hatenablog.com/entry/2019/08/22/152444

https://irof.hateblo.jp/entry/2019/07/18/140046

インターネット上でも実は言及が少ないカテゴリっていうのはまだあるんだなという気づきを得たので 今後も何かあったら同様の記事を書いていきます。

久々にLTで登壇

吉祥寺.pm #19でLTしてきた

ちゃんと技術の話したのは初めてかもしれません…。 懇親会で「LTしてた人ですよね！」って声をかけていただきTwitterアカウントをフォローしあったりすることが多くあったので声掛けるの苦手な身としては本当にうれしかったです。 システム開発の現場における社会学的なことを話してみたいなという思いがあるのでまた登壇の機会があったら頑張ります。

もくもく会主催

殿ヶ谷戸庭園もくもく会をした

本当にもくもくしただけなのですが、場を自分で作るというのが大変新鮮でした。 エンジニアの登壇を応援する会や吉祥寺.pmで知り合った方も来てくださって設営や撤収作業を手伝ってくださり 人とのつながりについて本当に感謝しどおしの日でした。

アウトプットで厄も払うぞ

と、実は31歳で前厄だったんですよね。来年の本厄もアウトプットをして強く生き抜いていきます。 今年はお世話になりました！来年もよろしくおねがいします！

[hikariru]

殿ヶ谷戸庭園もくもく会をした

殿ヶ谷戸庭園もくもく会 - connpass

なぜやったか

せっかく国分寺市民になったのでどこかで勉強会でも主催しようかと思っていたところ@kawasimaさんからここも借りれるので是非選択肢にと殿ヶ谷戸庭園の紅葉亭を教えていただいたのでとりあえず予約した。ちなみに都立公園なので市民割引は殿ヶ谷戸庭園にはない。

どうやったか

計画は@noriakihoriuchiさん、設営は @bainarianさんと@chiroruxxxxさんにめっちゃ手伝ってもらった。後片付けも参加者各位の腕力でスムーズに終えることができた。つまり私は予約をしただけ。ありがとうございました。

感想

イベントそのものに関して

ふらーっと散策に出かける人がいて、ゆるい雰囲気がよかった

手伝ってもらいすぎてありがたかった

お菓子持ってきてくれる人が多くてありがたかった

わたしは無力だ…

会場に関して

めっちゃ趣ある。エアコンが目立たないようになってる

Suicaで入場可能(財布を忘れた人情報)

8人でも多いと感じた(空気がこもっていた)

10畳間にしかコンセントとエアコンがない

6畳間は雪見窓を下ろしてリラックススペースにしてもいいかも

四阿に人が多くてうるさい。こんな場所で句会や茶会ができると思えなかった。

長テーブルじゃなくて椅子にマシン載せたりしたほうが片付けが楽かも。私一人だったら設営できなかった。

茶殻は持ち帰る必要があるのでお茶を作るのには割と抵抗がある

湯沸かしポットと急須、湯飲み茶碗は予約なしで借りられる

皆さんありがとうございました！次やるかどうかは堀内さん次第です。

[hikariru]

吉祥寺.pm #19でLTしてきた

LTしてきました。

資料

https://www.slideshare.net/HikaruUchiyama1/botkit4x-has-come

補足

どうして最後にいきなりBoltを勧めてきたのか

概ねスライドに書いた通りなんだけど、 純粋にイベントハンドリングするだけであれば現状Boltのほうが単純なコードで済むから。 BoltにはHubotからの移行ガイドも用意されている。Hubot, 一応最終更新は2019年2月に行われているけれど内容は些末としか言いようがない。

Hubotみたいにディレクトリー掘りたい

kou029w/daraz-sanを参考にするとよさそう。つまり自前実装。

Bolt勧めておいてBotkit使ってるってどういうこと

バグ対応のワークアラウンドは(一応)ある。検証してないけど。 Botkitの優れている(とわたしが感じる)点はSlackApp内で独自イベントのトリガー発火・イベントハンドリングが可能な点。 複雑なことをやろうとしたら多分Botkitのほうがきれいに書ける。ので私個人はまだBotkit捨てない。

反省

シンプルにまとめるとどうしても笑われる

多分比較をしっかりして補足部分ちゃんと話せばよかったんだけど 5分でまとまる内容ではないのでこういう構成にしてしまった。

次は社会学的な話をしたい

心理的安全性の出どころと心理的安全性とは何であって何でないのかの話を聞いていて、 やっぱり私はチームにおける社会学の話が大好きだと再確認させられた。勉強し直すか。

追記

cronジョブ自体は流せそうです。ExpressReceiverの中のappはExpress.jsなのでルーティングイベントを書けばいいっぽい。あと、EventEmitterAPI直で叩かせればコンテキスト無視して喋らせることができるの、そりゃそうすぎて一気に目が覚めたぜ！

https://blog.solunita.net/posts/develop-slack-app-comfortably-fast-receive-http-request-for-cron/

[hikariru]

[WIP]君の(チームの開発プロセスの)名は

「ウォーターフォール」、正しく理解できてる？

セブンペイ問題の根本要因。日本の悪習慣「ウォーターフォール」

「ウォーターフォール」が「ノンアジャイル」の意で使われているようだ

蓋を開けたら「メテオフォール」だった、とかやめてよね！

みんなでレールを敷いていこう

開発プロセスは個人じゃなくてチーム・組織ぐるみで作っていくもの

製品が売れないのは個人の努力が足りないせいじゃなく組織力不足

誰のおかげで製品が売れる？

営業・サポート・開発の相互作用で製品が育っている

「(営業|サポート)のおかげで製品が売れている」って卑屈になるのはやめよう

機能をたくさん作れば売れるわけじゃない

売れる機能を作れば売れる(あたりまえ)

どうやって「売れる」機能か判断する？→顧客へのヒアリングなど

あ、吉祥寺.pm #19でLTします。 多分botkitっていうbotのフレームワークの話をします。

[hikariru]

モッククラス、下から見るか？横から見るか？

タイトルは完全に適当です。元ネタすら知らない。

1行で言うと

単体テストの際にモッククラスを使うべきか否か悩みはじめたので有識者各位の意見がほしい。

モック使わない派の意見

モックを使うと、モックのI/Oに従属したテストになってしまう。 従来モッキングフレームワークはここまで手厚い機能を提供していなかった。 異常系のテストをしないのであれば依存クラスは実体を用いるべきではないだろうか。 また、結合テストを書いた場合コード量が増えてレビューコストが上がるが、ペイするのか。

モック使う派だった私のふんわりとした意見と悩み

テストピラミッド

確かにモックを使わない派の「モックのI/Oのテストになってしまう」という指摘は正しいと思う。 単体テストの役割は「対象クラス単体のロジックの正しさを保証する」ことに集中すべきではないだろうか。 実体クラス同士の辻褄が合っていることを保証するのは結合テストで行うべきだと思う。 どんなフレームワークも利用する人の要求に応じて機能を拡張してきた。原点より今あるべき姿を考えたい。

例えば単体テストでどのモッククラスが何度呼ばれたか(もしくは呼ばれなかったか)のアサーションは チェックのためのテストとしてとても有効にはたらいていると感じる。

テスト記述・レビューのコスト

実際のプロジェクトでテスト(敢えて単体・結合と定義しない)を書く場合実体を使ったほうが楽だと感���た。 ただ、こ���まで見てきたプロジェクトでは単体テストしか記述しないものがほとんど、 一部のプロジェクトでE2Eテストが書かれており、結合テストが記述されているプロジェクトはなんとひとつだけだった。

では、単体テストしか記述していないプロジェクトにドキュメントが存在していたかというと大体ない。 動くコードに付随する結合テストを記述するのと、日々変化していく機能についてドキュメントを書くこと どちらがレビューやメンテンナンスのコストが低いだろう？私は前者だと思う。

とはいえきっとビジネス的な要求を開発チームが汲んで結合テスト以上のテストは今後も省略されていってしまうんだろう。 実践的には実体クラスを使うのが「正しく」、教条主義的に単体テストと結合テストを書きたがる私は「間違っている」のかもしれない。

[hikariru]

入社から2ヶ月エントリ

※やめてません。いつも退職エントリで貼ってないから貼りたかっただけ。

前回から半月しか経ってないじゃねーかとの声もありそうだけど、 ほら、キリがいいほうがいいでしょ。

やったこと(あったこと)

会社とか

資金調達

これによって会社のできることは増えるけど同時にビジネス的なプレッシャーの増大も起きるので うまく令和の荒波を泳ぎきっていきたさ。

セミナースペースオープン

収容人数30人程度見込みらしい。

自分

業務そのもの

仕事は考古学状態であまり進んでいない。あとこの会社で自分がどんな価値を提供するのか自分でも確信が持てず困っているところ。 体調は相変わらず悪くて(プライベートで引っ越しをせざるを得なく、割と大変)医者からだいぶまずい状態とは言われている。 会社には伝えてあるし理解もされている様子ではあるけど、稼働率の著しく悪い社員なので正直切られても文句言えない。

チームに対して

ふりかえりの定義の話をした

ユーザーストーリーマッピング本を勧めた

会社自体はウォーターフォール式の開発を標榜しているんだけどそこにアジャイル的なエッセンスを加えてもいいと思っている。

採用に関して

少し声かけたりしてるけど実績にはつながってない。仲間増えろ増えろー。

わかったこと

「悪い人」がいない

他人に害意を持とうとする人、いるところにはいるけど現職にはいない。 本当にみんなが各自の思うベストを尽くしていると信じられる。これは結構貴重だと思う。

人が足りない

AndroidエンジニアとUI／UXエンジニアが足りてなくて大変そう。フロントエンドエンジニアももっといていい気がする。 募集要項はDMくれれば送るのでTwitter経由で連絡ほしい。

ためしたいこと

アジャイルの話をもっとする

「正しいものを正しくつくる」とか「持続可能なソフトウェアの開発」とか目指していけるといいなあとか思っている。 ソフトな貯金を吐き出す代わりに技術面の経験値を上げていきたい。もちろんソフトな貯金は今も個人的に増やしている。

イベント開催

やりたい。まずは営業チームから設営ノウハウの吸収をする。開催自体は周りが落ち着いたタイミングになると思う。

[hikariru]

入社から1ヶ月半経過エントリ

入社から1ヶ月半経ってました。はっや。GWはさんでるからだけど

よかったこと

本社移転

めでたい。ちかい。きれい。夢が広がる。ディスプレイも今まででいちばんでっかいのでかわいがってる。

ぷるりを生やした

まだ小さいのを数個だけだけど、みんな見てくれてうれしい。

技術的な会話のやりとり多い

強い人が多い。経験値のたまる音がする。まだレベルは上がってない。

面白い人が多い

斜め後ろの人プスープスー笑いすぎだと思う(ひとのこといえない)

改善の機運がある

みんなモチベーションたかい。ウェーイって感じではないけど地道なやっていきのっていきがある。

なんとかしたいこと

別拠点の難しさ

ある。海峡二つ挟んでるからな。工夫はしているけどまだなんかできると思うから提案したい。

キャッチアップ速度

おそすぎわろた…わろた…わろえない…TDDは多少助けになってるけど私がこれまでPHP使ってるとかフレームワークに強く依存したプロジェクトに多く関わっていたせいか難航してる。引き続きやっていく。

体調

完全に自分と気候のせい。カウンセリングに通ってるので徐々に改善されると思いたい。

ひとすくない

私の右隣も斜向かいも真後ろも空席でスースーする。(移転前までは席不足だった) JavaやAndroid、フロントエンドのどれかに多少自信ある人は秋葉原でうちるさんと握手！(お茶は出ますが私の由来物ではないので安心してお飲みください) GitHubアカウントとかスキルセットわかるものあると話が早い。@hika_riruまで連絡ほしい。

[hikariru]

就職した

していました。

業種・職種

まるっと言うとSaaS屋さん。言語はJava。Groovyしかわからないのに。

入社理由

はっきりしたポリシーに基づいて商品・ソリューションが顧客に届けられている

部署間の隔たりの薄さ

入社してからわかったこと

東証一部上場企業以上に色々しっかりしてる

業務において感情的なやりとりが発生しない

社内からの「スプラトゥーンを持ってきて」圧が強い(怖い)

今後やりたいこと

インフラ周りのキャッチアップを進める

人が増えることに備える・復習のため形式知をドキュメント化する

健康を取り戻す

無職の間にやっていたこと

おせち作り

ホットケーキを焼く修行

FGO

FTL

Slay the Spire

Darkest Dungeon

干し芋

引っ越し前なので物理的に何か送られてくるとちょっと困ってしまう

KyashのQRコード貼っておくのでどうしてもなにか送りたい人はキャッしてください

主に飲み会で財布を忘れたときなどに活用されます

ID: hikariru

[hikariru]

Python Koansで修行している

今のところ30%くらい。道のりは遠い。ただ、ドキュメントを読んだりするよりずっと理解できていると感じるし、実際にアプリケーション作ってみる必要がないのでだいぶ楽。

https://github.com/hikariru/python_koans/commits/learning

[hikariru]

Teamwork OP

Paizaで問題解いてたらJSだと厳しいのが出てきてぐぬぬりながらPHPで回答した。くやしいのでPythonに入門してる。今はインタプリタ入れてチュートリアルを読んだところ。リストとかタプルとかまだ何もわからんけどとりあえずstringがimmmutableなのはすごくいいと思った。リストとかタプルとかはまだわかんない(重要)のでPython Koan通してTDDでわかろうとおもう。

ここまでは前置きで、私がチームで仕事するにあたって大事にしている(けどうまくいっていない)考え方の話をしたいと思う。 前置きはあれだ、ただのポエマーではないですよアピール。

Teamwork OP

https://youtu.be/ugXC7g3p0JU

League of Legendsというゲームのマナー啓発動画。

要約

ゲームは楽しくやりたいし、勝てたらもっと楽しいでしょ？

個人の小手先のスキルよりチームワークが大事

怒りや責め合いは勝利を遠ざけることが統計的に証明されている

振る舞いと成果に相関性があることも統計的に証明されている

ポジティブな言動を多くするプレイヤーのほうが平均より多く勝利し、ネガティブな言動を多くするプレイヤーのほうが平均より多い敗北を経験している

助け合うほうが勝率が高い

Is Teamwork OP on REAL Jobs?

ポリシー

仕事は楽しくやりたいし、成功したい

小手先のスキルを重視するよりチームで助け合って成功を目指したい

気に入らないことがあっても怒ったり責めたりしないようにし、周囲がネガティブな言動をしたら止めたい

チームに貢献したい気持ちがあることを広く伝えていく

チームメンバーは助けるし、自分も助けを求める

ゲームと現実は違う(あたりまえ)

世の中必ずしも仕事を楽しみたい人ばかりじゃない

世の中必ずしもチームで仕事したい人ばかりじゃない

世の中必ずしも返報性の原理に従う人ばかりじゃない

世の中必ずしも成功と報酬が結びつくとは限らない

プログラマーとしてお仕事している以上どうしてもスキルは大事

ゲームと違って短時間で切れる縁ではないのでどうしても不満が相互に蓄積しがち

ゲーム内の理想や道徳と現実の乖離に耐えきれなくなって爆発することがだいぶ多い気がしている。

じゃあどうしたらいいのか

わかりません！一緒に正解を見つけてくれる仲間がほしい！！！

[hikariru]

吉祥寺.pm17行ってきた(感想)

https://kichijojipm.connpass.com/event/118082/

多分3回目の参加。うちるさんは犬でバカなので雑な感想を生やします。

Talk1: 報恩謝徳！自分も出張1on1始めます！

やっぱり社外の人と1on1めっちゃやってみたいんだけど女性なので既婚者男性と業務外でサシはだいぶ抵抗あるのでにゃーんだなあとおもいつつ、こういうムーブメント増えてほしい。

Talk2: なぜぼくがbitcoinに心奪われるのか

ちょっと資料もう一回ゆっくりみたい。仕組みが面白そうだった。

Talk3: タイトル未定

長生きしているコミュニティ運営の話。気合いはつよい。私も関わってるコミュニティに貢献していきたいなと思った。ちな正式タイトルが公式に出てない。

LT1: いまさらUML

UMLなにもわからないけどカジュアルに書けるようなしくみがあるなら私も書いてみようかなって気持ちになった。

LT2: Interfaces in Perl5

Interfaceがない！ラーメン屋で修業しよう！ってならずに自分で作る姿勢尊敬する。PHPにもEnumなくてラーメン屋で修行したくなるけどOSSで補完してくれてるしこういう人たちありがたい。

LT3: 相談・質問に報いる

突然の紙芝居LT。 相談受けたときに知識の再整理できるのはすごくわかるんだけど、一度相談受けた相手のこと考え続けるのはすごく負荷の高い行為なのではないかと思った。すごい丈夫なのかうまく消化しているのか気になる。

LT4: riot.jsのすすめ

69歳の方。親より年上で学び続けていらっしゃるのがすごい。Reactだとデザイナーとの協業に支障があるっていうの、この方がおっしゃると最高に説得力ある。ライブラリの開発もされてる。

LT5: 私とスプレッドシート

鎌倉の某社の方。つよい。Perlの人なのにGoで結局書いててオッってなった。数学力つよい。(あとタイムテーブル考慮して巻きつつちゃんと喋るのすごい)

LT6: YAPCと俺

登壇とかちょっと向いてないなーって思ってたら「登壇すると転職できる」と聞いてやる気が出た(クズ)

LT7: YAPCに 行けば 人生が 変わる

本当に人生が変わってた。

LT8: そーだいさんがspawn

勢いが凄まじいけどいい話してくださる。

[hikariru]

なりたくてプログラマーになったわけじゃないけどプログラミングは好きだった

面談で「どうしてプログラマーになったんですか？」って聞かれてだいたい雑な返答しかできないのでこれもまとめる。

TL;DR

他になれるものがなかったから生活のため仕方なくなった。

中学・高校時代: 雑に「ホームページ」を生やす

なぜか周囲で「ホームページ」を作ることが流行していたので生やした。 最初はMSNのPersonal HomePagesで、 その後はinfoseekとかninjaとか使ってた。ホームページビルダーが割と汚いHTMLを吐くので途中から自分で打つようになった。 途中からCSSもちゃんと使うようになった。 最終的にはStrictなHTMLとCSSを書くとかテーブルレイアウトしないとか、そういうところにこだわるオタクになった。 プログラミングは画像をランダム表示するJSのコードをどっかから拾ってきてカスタマイズするくらいの理解。

大学時代: Delphiでプログラミングデビュー

社会学部に入ったのに選択必修科目でDelphiでのプログラミングを強いられた。 最初は何もわからなかったけど、それがくやしくてコードやレジュメを真面目に読んだら すぐ課題終わらせられるようになったので「あ、プログラミング向いてるんだ」って思った。 講師からTAに勧誘されてTwitterやりながらTAしてた。私語してるラグビー部とかソフトボール部の男子学生の後ろで威嚇し続けたり、 プログラミングアレルギー発症している学生を宥めながら一緒にレジュメを見直してコード書いたりしていた。 途中で授業で扱う言語がDelphiからJavaに変わったので(むしろどうしてこれまでDelphiだったのかマジで謎)授業潜ってEclipseでJava書いたりしてた。

就活: やる気が出ない

履歴書を書くときに資格欄に何も書けなかったのでとりあえずITパスポートを1ヶ月1日1時間くらい勉強して取った。 でも、プログラマー=長時間労働というイメージが固着していたのでひたすらプログラマーから逃げていた。 4年生の2月になってもない内定だったので腹をくくって転職エージェントさんところ行ったら プログラマーになることを強く勧められたので諦めて社畜になる覚悟で2社受けさせられ、 文教系の開発会社の内定を3月の上旬に滑り込みで取った。実際はSESだったのはまた別の話。提出してしまった履歴書は以下の通りです。

新卒の時なぜか書類選考を通過した伝説の履歴書です。ご査収ください。 pic.twitter.com/kVIOLD3UYA

— うちる🐶XPだいすき女子 (@hika_riru) 2019年1月30日

[hikariru]

履歴書: 関心の変遷

他の人たちの会話ながめてて、「あれ、どうして私今の関心に至ったんだっけ？」って疑問に思ったので書き連ねてみる。

1. 1社目: プログラミングが楽しい

新しい言語・新しいフレームワーク、新しい技術を使って色々やるのが楽しかったころ。 ひたすらコードを書いて、もっと色々新しいことができるようになれば自分はどこでも通用するプログラマーになれると信じていた。 それを応援してくれる人もいて、一番何も考えず自分の楽しさを追求していた。 汚いコードを書くと更に汚いコードが書き足されることや、jQueryでインタラクティブなフォームを作るととっても壊れやすいことがわかった。 リーダブルコードやAngularJS、vue.js0系に手を出したのがこのころ。

2. 2社目: チームって楽しい(けどすごく難しい)

SESだと会社の都合でキャリアがごっちゃごちゃになることがわかったので、自社サービス開発をしている会社に入った。

こんにちは沢山の新しいこと + 本の山

アジャイルとはなにか、スクラムとはなにか、リーン開発とはなにか本を読まされた。 前職の案件で幾度か発生した混乱は無軌道なプロジェクト管理が原因だったことがわかった。 アジャイルってすごい、スクラムってすごい、魔法のステッキかも？くらいに素敵に見えた。 まあ実際アジャイルもスクラムもすごい難しいのは今はわかってるんだけど、若いと素直に新しいことが素敵に���える。 でも英語とテスティングは全然わからなくて帰りの電車で泣いてた。 (当時の先輩へ: 今の私が先輩の立場だったなら1日15分は後輩と向き合う時間を作ると思うんですが、あなたはどう思いますか？)

「知ってる技術で開発したい」

色々あってチームに人が増えて、そのうちの一人がこう言った。 みんながキラキラしたキャリアを望んでいるんじゃない、俺はただ仕事をして金をもらいたいんだ。 なんじゃこいつって思ったしその人個人のことは正直好かんけど、でも視界の中に苦しんで仕事してる人いるのはしんどかった。 今でもどうしたらよかったのかわからない。正解を今でも探している。

さよなら先輩、こんにちは社外の世界

先輩が辞めた。辞める前に色々引き継いでいったんだけど、ひとつ私だけが引き継いだものがあった。社外の人とつながること。 当時のチームメンバーから「あの人の一番の強みは人脈」って言われたのもあり、先輩の飲み会についていった。 みんなすっごく優しいけど何言ってるか全くわかんねえ！でも、とりあえず社外に目を向けると楽しいことがわかった。

3. 3社目の最初の部署: 人をたくさん集めるとチームになる？

チーム開発の技術をもっと磨きたい！そう思って転職した。

力こそパワー

テストが真っ赤。カンバンはWIPが大量。朝会は足が痛くなるくらい続く。膨れ上がる要件。 上司のパワーを借りながらだいたい全部倒した。 SESを否定する意図はないんだけど、パートナーさんは言われたことをやることが価値で、 社員は言われていないことをやることやパートナーさんにお願いすることが価値。 社員に対してパートナーさんが多すぎると問題が発生しても拾われない。SESを否定する意図はないんだけど。 つまり、徒にパートナーさんを増員してもチームにならない。経験して初めて知った。SESを否定する意図はないんだけど。

KA-BOOOOOOOOM!!!

自分の開発タスクはあるけどコードの治安は維持しないとだし、パートナーさんの抱えてるタスクが複雑化したりしてたら 介入しないといけないし(だってパートナーさんは反論できないから)で色々考えることがありすぎて私は爆発して休職した。 パワーを持ったメンバーとの社会学的な音楽性の違いもあった。

4. 3社目の亡命先の部署: もっとサービスを愛したい

倒れる前から同期や同僚たちと相談していて、復職時に亡命した。亡命先には別の価値観で動いてる別世界があった。 大企業は広大。今も彼らとは飲みに行く程度に仲良しです。あ、最初の部署の人たちともTwitterで絡む程度には仲いいです。

ノンエンジニアとの遭遇

お菓子をあげたりもらったりしながらノンエンジニアとユーザーさんやユーザーさんを取り巻く世界の話をした。 頑張って説明して、相手も頑張って理解してくれた。 調査や開発の過程でたくさんの人が様々な思いを持ってサービスを作ったり使っていることを知った。 Webサービス、最高じゃん。必ずしも最新技術じゃなくたってみんなを幸せにしたいしできるんじゃん。そういう気持ちが持てた。

5. 4社目 Webサービスって何？

直近のブログで書いたから省略。頑張った。 体を壊すときって自分の強みが限界値超えて発揮されてるときでもあると思う。 ちょっと歯止めが利かなさすぎる体質なだけで。てへぺろ☆

ああ、空のアジェンダのお出ましだ。 不具合は共有してって言ってるだろ。 巨大な要望が攻めてくる。 外部キーのいらないテーブル設計はないんだよ。

まとめ

書いててやっぱりよくわかんなかったけどオデッセイだねえって感じ。でもきっと正解に近づいてる。知らんけど。

[hikariru]

初勉強会スタッフした

目標設定の技術を勉強する会 #1でスタッフ参加してきた。

受付をしていました。感想: クンフーが足りない。またやる。登壇もしたい。

[hikariru]

対応に困るスカウト

Twitterでずっと転職してるよねって言われるけど絶対@kamekoopaさんのほうが長いと思う。

過去対応に困ったスカウトDM例を挙げていくのでスカウトDM送る人は参考にしてほしい。 無視されるのも辛いと思うけど勢い良く送られてきたものを無視するのも良心がしくしく痛む…。

1. 立場がわからない

社名だけ書かれてもだいぶ困る。 CTOなのかCEOなのか現場のエンジニアなのか名乗っていただけるとうれしい。

2. 募集要項がわからない

Wantedlyの募集ページとか貼ってくださるだけでかなりわかりやすくなる。

3. 露骨な採用専用アカウント

500人くらいフォローしているとだいたいフォロイーの誰かからはフォローされているものなのだけど、 そういうのがさっぱりないアカウントから声掛けられると評判聞きようがなかったりして困る。

4. コーポレートサイトの情報が薄い

ミッションやプロダクト・サービスについて��記するとだいぶ安心感がある。投資家さんも見ると思うので充実させておいて損はないと思う。

5. 求職post読んでない

斜め上のスカウトくるとプレッシャーで泣きそうになる。

以上、ご査収ください。

[hikariru]

MarkdownをPDFにする

職務経歴書を持続的メンテナンスが可能なようにprivate gistで管理しているんだけど、今回の転職活動でURLでない提出を求められることがあった。

色々試した結果これが一番よかった。

https://github.com/yzane/vscode-markdown-pdf

見た目がシンプル

文字化けしない

ページ番号振ってくれる

特にテーブルの表示のシンプルさはしびれる。

おすすめ。

[hikariru]

2019年のお正月をした

つくったもの

右上から左下へ

エビの旨煮

ナッツごまめ

栗きんとん

筑前煮

ブリの照り焼き

数の子

黒豆

お酒は日本酒を用意するのが大変なのでフォーナインを1ダース用意した。クセがないのでおせちとの相性もよかった。

写真にはないけど小松菜とかまぼこだけのシンプルな雑煮も作った。