一周回って元に戻った話
また半年くらい更新してなかったのか。
お久しぶりの方、お久しぶりです。
今回は勉強会まっったく関係ないただの近況報告です。
2018年の12月にカスタマーサクセスとしてベンチャー企業に飛び込んでかれこれ1年半。当時のエントリはこんな感じ。
あれからまあ、いろいろありました。
いやあ、大変でした。特に去年の後半。
業務量云々じゃなくて、もうね、ストレスがすごくて。
何が辛いって、飛び込んだ会社、エンジニア組織が機能不全を起こしていたのです。
つまり開発のロードマップが進まない。仮にもプログラミングでおまんま食っていた身、プロダクトの粗が見えることもあるんですが、それが一向に潰れていかない。
ところで「衛生要因」という言葉をご存知でしょうか？
主に人事の文脈で使われている言葉で、足りないと不満になるが、一定水準を超えると、それ以上の満足は得られにくいような要因を指します。職場と社員の関係ではお給料が代表的です。
もうちょっとイメージしやすいところでは、「職場からネットがつながる」とかですね。遅すぎるとイライラするけど、超高速だからといって「この会社は最高だ！」とはならない。
逆に「動機付け要因」と呼ばれるのが、あったらあっただけ嬉しい要因になります。
で、この理論はマーケティングの世界で、プロダクトに応用されることもあります。
新機能は（ニーズにマッチしていれば）動機付け要因。
安定的に運用されていて、バグが少なくて……というのは衛生要因です。
これはスタートアップあるあるだと信じているのですが、私がカスタマーサクセスとしてジョインした当時、会社はとにかく動機付け要因を重視していました。
衛生要因は顧客だけでなく、営業や経営層にとっても「あって当たり前」と認識されがち。「コストをかけなければ実現できない」ということを、開発側もうまく説明できていなかったのですね。
当たり前ですが、場当たり的な機能追加を繰り返すと、コードは複雑化していきます。徐々にリリース頻度は下がり、肝心の新機能もなかなか表に出せなくなる始末……
このような状況で、カスタマーサクセスが顧客に対して取れるアクションは自ずと限られてきます。
その数少ないアクションは、どれを取ってもあまり気持ちのいいものではありません。
Moral injuryというと大袈裟かもしれませんが、罪悪感で沈み込むことが増えてきた私は、少しずつ、自分の仕事に集中することもできなくなっていきました。
モニタの前に座ってはいても、思考がぐるぐると回って、「あれ、次って何をやればいいんだっけ？」となることが増えていきました。
それも一日や二日の話ではありません。朝から晩まで定時待ちおじさん状態です。私、こんなに無能だったっけ？
あまりにも生産性が上がらないので、これはおかしいと思い、病院へ。
すると「抑うつ状態」の診断で、休職する運びとなったのでした。
と、ここまでがネガティブな話。
幸い薬が合っていたのと、精神的な問題に理解のある会社だったこともあり、程なくしてエンジニアとして復帰ができました。
すると、なんということでしょう。
開発組織、以前とは全くの別物に生まれ変わっているではありませんか！
見ている視点が中か外かというレベルではありません。
せっせと優秀なエンジニアを採用し、足りなかった衛生要因にもリソースが割かれ、ご機嫌で建設的なコードレビューが飛び交う……
そこには「チーム」ができていたのです。
もちろん課題も少なくありません。特に強力なのが言語の壁。
日本語が喋れないエンジニアもいれば、英語が喋れないエンジニア（私だ）もいる。
もっというと開発以外の社員は英語喋れないメンバーが大多数なので、ビジネス要求のヒアリングや優先度・スコープの交渉など、日本語が喋れないとしんどい仕事も多々あります。
一人の開発者としてそんなチームの状況を見ているうちに、久しく忘れていた気持ちが湧き上がってきました。
「このチームのために尽くしたい」
「彼らが大きな価値をデリバリーして、報われる環境を整えたい」
そのための手段として、2018年の私はビジネスサイドに飛び込むことを選びました。
営業の論理を理解し、バランスの取れた落とし所を顧客と交渉できるようになれば、もっと周りのエンジニアの力を市場に届けられると思った。
ですが結局それは「相手（=ビジネスサイド）を変えようとする」アプローチに過ぎなかったのかもしれません。
2020年の私は、開発チームの中から、同じことを実現しようともがいています。
その仕事は世間では、「エンジニアリングマネージャー」とか呼ばれているようです。
まだまだひよっこで、肩書きも無印の「エンジニア」。
それでも目指すものが言葉として見えた以上、次にすべきことも少しは明確になったのだと思うのです。
思えば、開発スキルの習熟もそこそこにマネジメントを求められる空気が、最初の会社を去った理由の一つでした。
結局壮大な回り道だったような気もしますが、「急がば回れ」という言葉もあります。
これまで培ったものが無駄ではないと信じて、精進していく所存です。
WEBエンジニアじゃないけどWEBエンジニア勉強会#14に紛れ込んでみた話
- はじめに
- 何故マイクロサービスにするんだっけ？
- 失敗から知るAWSサーバレス ~ API Gateway Lambda編 ~
- 愛されるダッシュボードの作り方
- アジャイル好きのウォーターフォールとの付き合い方
- mdx-deck v3 and code-surfer v3
- GAEによるPythonWEBアプリケーションの高速開発
- How Can They Know That? A Study of Factors Affecting the Creepiness of Recommendations
- おわりに
はじめに
まさか半年どころか9ヶ月間も空けちゃうなんて！
と思ってメモを見返したら、勉強会自体2ヶ月ぶりとかでした。
気分は社会復帰です。たまに外に出るの大事。
ということで、社会復帰にも最適なやさしいせかい、WEBエンジニア勉強会 #14 に一般参加で潜入してきました。
web-engineer-meetup.connpass.com
本当にWEBエンジニアだった頃に何度かお邪魔していますが、改めてご紹介すると、WEBサービス・SI問わずWEBエンジニアが集うコミュニティです。
個人開催にも関わらず2〜3ヶ月に一度のペースというハイペースで開催されております。参加者・登壇者とも若手〜中堅多め。
今回の会場はカサレアルさん。待合室がどことなくホテル風で和む。
さて、タイムテーブルをご覧いただければわかるように、この勉強会、前座枠というものがあり、スタート前にも誰かしらなんかしゃべっている状態なのですが。
入ったら急にお肉の試食会がはじまって動揺している #WEM14
— ney (@tom_myz_) August 30, 2019
こうなった。
よく考えたら人工肉なので「お肉の試食会」ですらなかった。食べなかったけどおいしいようです。畑の肉しゅごい。
前置き（？）が長くなりましたが、各登壇のレポートに移ります。
何故マイクロサービスにするんだっけ？
スポンサーセッションだからと侮るなかれ。スピーカーの多田さんはJava、特にSpring界隈ではちょっとした有名人なのです。勉強にならないわけがない。
内容はスライドの通りです。マイクロサービスのメリデメちゃんと考えようねって話と理解。
初心者からベテランまで、万人に効くテーマではないでしょうか。
マイクロサービスに限らず、「流行ってるし、イケてる感じだから」で手法を選ぶと高確率で痛い目を見る気がします。屍の山を築いたマイクロサービスとアジャイルはもちろん、クラウドの新機能をノリで使った時とかも後悔しがちなイメージ。
言語はサーバレスだとサポート確認必須だけど、あとは意外となんとかなる気がする。このへんの、「流行りに乗った結果、クリティカルになる／ならないライン」は個人的に若干興味があります。
話が飛びました。マイクロサービスやるならハチの本読んどくといいよって社内のわりと強いエンジニアが言ってました。諸事情により英語版で読みましたが、確かに一回目を通すとよさげ。
失敗から知るAWSサーバレス ~ API Gateway Lambda編 ~
サーバレスあるあるな落とし穴を超絶具体的に、かつわかりやすくシェアしていただいたセッション。回避策もしっかり書かれていて嬉しいスライドです。みんな苦労してるんだなあ。
受託の現場離れすぎてわからないのですが、お客さんがサーバレス指定してくる理由が気になるところ。他のシステムと平仄合わせるためとか？それとも雑誌とか読んで言ってくるのかなあ。
愛されるダッシュボードの作り方
最初に至極どうでもいい感想言います。
スライド表紙の愛され感がすごい。
しかも登壇前にバッチリconnpassでシェアしてあるという如才なさ。これは愛されますわ。
JupyterHubをデモ配布に使うというアイデア、作り手目線だとめちゃくちゃアジリティ高くて素敵な反面、社内ユーザーにも相応のITリテラシーが求められそうなところ。
そのあたり、どう解決していったのか、あるいは解決しなくていいくらいITリテラシー高いユーザー層だったのかなど、気になるところ。
いずれにしても重要なのは「イテレーションを早く回す」ことなので、仕組み自体は組織に合わせて色々なパターンが考えられそうです。奥が深い。
アジャイル好きのウォーターフォールとの付き合い方
「ウォーターフォールを批判したいわけではないが、ウォーターフォールに向いているエンジニアもいれば、アジャイルに向いているエンジニアもいる。」
という言葉に重みを感じます。
工程をまぜまぜするやり方としてはTDDが真っ先に思い浮かびましたが、そうか、リバース・エンジニアリングで仕様書作るってのも確かにそうですね。
しかも仕様書と実装の間に「ヒューマンエラーによる乖離がないことが保証されている」って現場からしても超絶助かる話でWin-Winでは。
えっ生成した仕様書が秘伝のエクセルフォーマットに合ってない？そんな殺生な。
mdx-deck v3 and code-surfer v3
code-surfer-v3.naturalclar.now.sh
うまく埋め込めているか若干自信がないのですが、これに関しては余計な説明はいらないでしょう。とにかくスライドを見てくれ。code-surferの動きが気持ちよすぎる。
お仕事とかで継続的に使うにはAlpha版で破壊的変更モリモリなのが不安要素ですが、一回きりの登壇用であれば問題なし。
オンラインのトレーニング資料とかに使っても映えそうです。遊んでみよう。
GAEによるPythonWEBアプリケーションの高速開発
GCPネタ。「GAEはいいぞ！」ってなるかと思いきや微妙になりきらなかった話。
デプロイ遅いのは毎回バイトコード作ってて時間かかってそうな気もするけど、よくわかりません。Pythonの実行時のしくみ、コンパイルのタイミング以外Javaとそこまで変わらないようにも見えるんだけど、どうなんだろ。インタープリタ型とコンパイル型の境界線がわからない。
言語・フレームワーク変えまくりながら、ヘルスチェックだけのAPIデプロイするのにどのくらい時間かかるか、とかベンチマーク取ってみても楽しそう。
どのくらいリクエスト捌けるか、という観点でのベンチマークは見つかった ( https://medium.com/growthops/google-appengine-benchmark-f9961ae82e42 ) のですが、デプロイにどのくらい時間かかるかを計測したものは発見できませんでした。
How Can They Know That? A Study of Factors Affecting the Creepiness of Recommendations
トリは論文紹介です。
スライドが見つからなかったのですが、元ネタは多分これ。
https://interactivesystems.info/system/pdfs/907/original/RecSys-19.pdf?1566216344
「今日だってことに今日気づいて、昼休みに読んでスライド作りました」
という驚異のスピードと、そのスピード感で仕上げたとはにわかに信じがたいレベルの面白さを兼ね備えたヤバいセッションでした。
Creepinessという言葉はピンとこなかったのですが、検索エンジンが有能すぎる時に「えっなんで知ってんのキモ」ってなるあの感じをCreepinessって表現するようです。
Creepinessを感じやすい性格は「社会的信用が低い」「合理主義者」
Creepinessを感じやすい話題は「医療・健康」のようなセンシティブな話題
Creepinessを感じる原因は「なぜそれを薦められたのかがわからない」こと
……などなど。結果自体にそれほど驚きはなかったものの、きちんとデータで示されると興味深い内容です。
昔よりマシになったとはいえ英語読むのやっぱり得意じゃないので、日本語でこういうインプットもらえるのはすごいありがたいし、楽しい。
エンジニア向け、大人の論文輪講とかやってるとこないですか（真顔）
おわりに
終始個人的な感想ばっかでアレですが、本当に、参加してよかった。
開発の前線を離れて半年以上。参加動機は技術トレンド追えてない危機感が半分、気分転換が半分、という感じでした。
登壇の内容自体が勉強になるのはもちろんのこと、前線で頑張っている等身大の姿に、いい刺激をもらってリフレッシュできました。
えらい人がイケイケでWe're hiring!する勉強会もあれはあれで非常に勉強になるのですが、肩に力を入れて聞いているのも疲れるもの。
「開発って楽しいよね！」「もっと楽しく開発できたらいいよね！」というシンプルな想いを再確認する意味でも、こういうコミュニティの存在は素直にありがたいと思います。
しかし転職したばっかなのに、腰を据えて開発やりたい欲が募って困ります。
とりあえず美味しいお肉食べよう。
次回は10月〜11月開催、場所は渋谷のセンが濃厚なようです。
ご参加の方はお見逃しなく。
感想文：人前で喋って思ったこと
喋ってきてしまいました。
web-engineer-meetup.connpass.com
発表は大丈夫だねって卒論発表のときも社内勉強会のときも言われたんですが、とんでもない。人前めっちゃ苦手で発表の類は毎回吐きそうです。できればやりたくない。
しかも強いWEBエンジニアをあっと言わせる最先端の知見なんぞあるわけもなく、前日夜あたりは「なんでノリと勢いだけでLT申し込んでしまったのか……」みたいな心持ちでした。
が、結論。申し込んで本当によかったです。
やってみたきっかけ
そもそも今回、力不足覚悟で喋ってみようと思った理由は、「エンジニアが本業じゃなくなる前に、世に出なかった記事たちを供養したい！」という思いがあったからです。
実ははてなブログの下書きに、ちょっとテクニカルな残骸がいくつか残ってるんですよ。「JavaエンジニアがScalaを勉強した話」とか「sbtでクリーンアーキテクチャを実装する」とか。下書きすら消したのもあるけど、中には5000文字くらい残ってるのもあって。WEB小説とかで1話5000文字ってまあまあ読んだ感ありますよ。
でも結局これらの記事は完成しませんでした。
書いて、寝かせて、読んで、を繰り返しているうちに、完成像がわからなくなっちゃったんです。勉強すればするほどわからなくなって、ドツボにハマった感がありました。
ここから加筆して公開まで持っていくイメージはわかない。でもちょっと頑張ったからなんらかの形でアウトプットはしておきたい。
そう考えたときに「5分くらいでふわっと喋る」のは、まあアリかなあと感じていたのです。
準備
まあまあ時間かかりました。新規コーディング作業ゼロなのに。
資料づくりは要領よく行かないし、時間配分はわかんないし、外は寒いし。最後は関係ないか。
何より「実名で適当なこと言って炎上したらどうすんの？」って思うと怖い。
自分自身の責任でやるって決めたわけで、何かあったときに火消ししてくれる上司はいません。当たり前だけど。
結果はどうあれ、普段の10倍気をつけてプレゼン作った気がします。
当日
とにかく吐きそう。
かろうじてメモは取ってましたが、一般参加のときほど呑気にツイートできない。緊張をアルコールで紛らわそうとしてペースを考えずに飲酒。手元にあるのがほろよいで助かった。
そして登壇開始。機器のご機嫌も良さそうだし、練習は4分50秒台だったし、普通に喋れば大丈夫なはず……！
と思って参加者のみなさんを見た瞬間、なんかもう全部飛びました。
時間を余裕でオーバーしたことだけは覚えている。すみませんでした。
感想
改めて、これまでお話を聞いてきたスピーカーさんたちの凄さを感じました。
だって機器の接続悪くても、苦労して作ったデモがちゃんと動かなくても、彼らはちゃんと与えられた時間で最善尽くして喋ってくれてた。
多分その数十分のためにめちゃくちゃインプットして、アウトプットしている。
一瞬しか映らないスライドも、きっとその一瞬と同じ時間では作れない。
勉強会で一番勉強するのは、ひょっとしたら、発表のために一番時間と労力を割いた人なんじゃないかという気持ちにすらなりました。
今まで心のどこかで「自分とは全く立場の違う強いエンジニアさんだ」と思っていた人たちがグッと身近になって、同時に「全然かなわない」と痛感する。
今回私が得たものは、きっとそんな経験でした。
拙いLTを聞いてくださった皆さんには、感謝半分、申し訳なさ半分……という感じですが、「あんなんでいいなら一回やってみようかな」と思った方がいたのなら、望外の喜びです。
運営でもなんでもないので滅多なことは言えませんけど、「機会があるならやっちゃいなよ！」と本気で思います。
相変わらず人前で喋るのは好きじゃないけど、やってみて本当に良かった。
貴重な機会をいただけたことに、心から感謝します。
あなたが読んだ本は、まず間違いなく私も読みたい。
こちらに参加してきました。
参加理由
DevLOVEさんは月曜日から3日連続でイベントですが、私が参加するのはこのイベントのみ。
きっかけとしては、11月は1ヶ月で15冊の読書にチャレンジしよう！と計画を立てたことでした。普段の1.5倍か2倍くらいなので、私にとってはまあまあハードな数字です。
出入りしている読書会でビジネス書はけっこうお薦めしてもらうのですが、ある程度出来上がったコミュニティということもあって紹介される本が相当被るんですよね……
なのでもうちょっと別の本も知りたいなあという気持ちでの参加でした。
アジャイル界隈の人ってなんかやたら本読んでるイメージあるし。
今更ながらビブリオバトルも行けばよかった。
紹介された本
並びは発表順です。
推薦図書のamazonへのリンクはDoorkeeperのイベントページにあるみたいですよ！
Learn Better――頭の使い方が変わり、学びが深まる6つのステップ
買おう。というか買った。
紹介内容はわかりやすいスライドに沿って進行したので、補足とかはあんまりないです。
ネットで拾ってきた目次のテキストを眺めながら、市谷さんのテンションが上がってたのが印象的でした。
学習曲線の話は読書にも応用がきくとのことで、15冊達成したら来月は新規N冊+再読M冊みたいな目標設定も面白いかなとかつらつら考えておりました。
隙あらば「ファイブフィンガー」みたいな用語が飛び出すのはさすがDevLOVEさん。
ある程度共通言語がある人で読書会やるとこういう感じになるのかと、ちょっと新鮮でした。
やらないこと戦略 最大限にクリエイティビティを上げる時間管理術
"Don't Read This Book"という挑発的な原題。
スライドで見せてもらいましたが、原書の表紙デザインが最高にかっこいい。
紹介内容としては、
- 「やることリスト」でなかなかチェックがつかないと、人間はツァイガルニク効果（続きが気になる現象）によって不協和を感じるので、「やりたいこと」のうち本当に重要な3個を残して「やらないことリスト」に入れてしまう。
3ヶ月経っても何も起きなかったタスクは本当にやらなくていい。
（チケット管理システムに「いつかやる」系のタスクがうず高く積まれているのはあるあるだと思うんですが、どうでしょう？） - ライフプランを3段階で立てる。
- 自分のハッシュタグを決める。このとき、「ではないテスト」をする。作ったハッシュタグに「ではない」をつけて、該当する人が十分に多いか確認する。
「クリエイティブ」をハッシュタグにしたいと思ったときに、「クリエイティブではない」と自称する人が半数以上になるか検討する。多分ならないので、この場合は意味が広すぎる。 - 1+1=3になるチームワークだけが「やることリスト」に入る。
- プロジェクトを選ぶためのフローチャートが付いていていい感じ。
という感じ。ちょうど「やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける」読んでたところで、割と似たようなこと言ってるなという印象も。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
人の心がわからないことに定評のあったリーナスを引き合いに出しつつ、チームで大事なことは何か、プロダクトにとって大切なことは何かを考える紹介でした。
「パフォーマンスは高いが攻撃的な人」をどう考えるかというのは面白いなと。チームの居心地がよければ別に良いし、その一人のためにチーム全体のパフォーマンスが損なわれるなら対策を考えないと行けない。なるほど、と思いました。
31枚目にあるような「コードが汚れるからできればやりたくないです（やるなら大規模なリファクタしたいので工数ください）」は覚えがありすぎてウッてなりました。その節は大変申し訳ないことを。
あと正直読書会できるような職場クッソ羨ましいです。
NETFLIXの最強人事戦略～自由と責任の文化を築く～
えっ人事の本？と思ったら、組織文化の本みたいです。
従業員の3分の1をリストラする必要に迫られたNETFLIXが、「最高のシリコンバレー文化」と絶賛されるに至った（らしい）文化作りの話。
時間の都合上序盤の章をかいつまんでご紹介いただきました。
「経営陣が従業員のためにできる最善のことは、同僚にハイパフォーマーを採用すること」の言葉には「ほんそれ」と思わず頷きました。卓球台や社員旅行より、優秀な人と一緒に仕事できる方が嬉しい。あ、でもコーヒー飲み放題は大歓迎です！！（個人の感想です）
また「継続的にメッセージを伝えるのが重要」という点に関して、リモートワークと組み合わせて語っていただけたのは貴重だったなと。
内容的には「モチベーション3.0 持続する「やる気!」をいかに引き出すか」とかあわせて読みたいかもしれない。自律性(オートノミー)を重視した文化にするとこうなる、というケーススタディ的にも読めそうに感じました。
チームという粒度でも活かせる話が盛りだくさんらしいので、早めに読んでみたいと思います！
感想
アジャイル界隈の人ってなんかやたら本読んでるイメージある
→実際読んでた
お二人とも多い月は20冊くらい読まれるそうです。多読！
本の選び方についても言及されていました。
amazonで気になるカテゴリの書籍を毎週チェックするやり方、もうちょっとネタ切れが近づいてきたらやってみようかな。
非常に楽しく過ごさせていただいて、あっという間の2時間でした！
Webエンジニアをやめることにしました
新卒4年目、SIerから自社開発の会社へ……というありがちなキャリアを歩んできましたが、ご縁があって12月から3社目に移ることになりました。
次の会社でのポジションはエンジニアではありません。
リーダーとかマネージャーとかそういう話でもなく、ほぼ未経験のカスタマーサクセス として働くことになりました。
どうしてそういうキャリア選択をしたのか？どうしてその会社なのか？という話を、今日はしたいと思います。
つまりは突然の自分語りです。
なぜWebエンジニアをやめるのか
一言でいえば、「これからもWebエンジニアとしてお賃金をもらい続けるのはキツイかな」って思ったから。
ここ数年でプログラミングの学習コストは劇的に下がったと思います。
オンラインの学習サービスが充実し、ネット上には無料の情報が溢れています。
専門学校に通わなくても英会話教室と同じくらい手軽にプログラミングを習うことができるし、お金がないならなんとか最初のアウトプットさえ頑張れば、オープンな環境でアドバイスをもらいながら成長していく道もあるかもしれません。
さらにリモートワークへの興味や業界各位のイメージ戦略も手伝って、Webエンジニアという道を検討する人はかなり増えてきたのではないかと感じます。エビデンスはなく、ただの肌感覚ではありますが。
それ自体は喜ばしいことだと思いますし、Webエンジニアになりたいという人はなるべく応援したいという気持ちもあります。
一方で自分自身のキャリアを考えると、Webエンジニアとしてこの先もずっとやっていくのはなかなか厳しいものがあると感じました。
Twitterで転職系のハッシュタグを見たことはあるでしょうか。
300万、400万といった希望年収が並びます。
額面20万から30万くらいでしょうか。新卒並の水準です。
日本語が通じなくてOKなら、オフショアだと同じくらいの金額でけっこうハイレベルな人が雇えるようです。
そう考えると、300万とか400万の年収で納得できないのであれば、相応のバリューを提供できると雇い主に証明していく必要がありそうです。今の会社に勤めている間は仕事で証明すれば良いだけですが、市場の判断はどうでしょうか？
一流のプレイヤーは問題ないかなと思います。
凄腕で通っていればテッキーな企業は年収が高くても採りたがるでしょう。エンジニアの生産性の差は嘘か真か10倍とか100倍とか言われていますから、3~4倍くらい吹っかけても企業的にはお釣りが出ます。
ただ残念ながら、「あなたは世界で戦えるような一流のエンジニアか？」と聞かれると……とても「はい」とは言えないですね。
そうなるともう、コモディティ待ったなしかなと思うのです。だってWebエンジニアのスキルって証明するの大変だし。採用試験でよくあるプログラミングの実技って、あれだいたいエンタープライズのシステム開発じゃなくて競技プログラミングですからね。
今すぐ高給の仕事にありつきたいならWebエンジニアは十分に良い選択肢だと思いますが、そろそろ次の選択肢についても考えどきかなと思いました。オリンピックのあととか中小企業バタバタ死にそうなんで特に。
（未読で恐縮ですが「10年後の仕事図鑑」とか読むとエンジニアのコモディティ化についてさらっと書いてあるらしいです）
なぜカスタマーサクセスなのか
正直に言えばこの点は、明確な回答を持っていません。
実際、カスタマーサクセスに限定して仕事を探していたわけではなく、いくつかの選択肢を考えていました。
ただ、「今までのキャリアをリセットして、新卒と同じラインからスタート」は経済的にもけっこうキツイかなという想いがあり、Webエンジニアの経験をある程度活かしつつ、より抽象度の高いスキルを磨ける仕事が良いなとは思っていました。
具体的には人前で喋る経験、交渉する経験、数字を追いかける経験などです。
UXに強い会社に行くとか、コンサル系の会社に行くとか、そういうことも検討しました。結果がカスタマーサクセスなのは完全にご縁です。
なぜその会社なのか
わらしべ長者みたいな流れで内定をいただいたので、半分ノリで意思決定しています。どんなわらしべルートかというと、こんな感じ。
- 勉強会で話題にのぼったビジネスマッチングアプリを使ってみる
- アプリ経由で人材系の会社に勤めているXさんに会う
- Xさんに上のような話をしたところA社を紹介される
- 面談で会ったA社人事のYさんが別の会社(B社)を紹介してくれる
- B社に面談に行くと、新卒で入った会社で一緒に仕事をしたZさんが面接官
- B社から内定が出て話がまとまる
Yさんは私とZさんが知り合いだということは全く知らずに紹介してくださった模様。人事の目ってすごいっすね。
上記4.〜6.まで１週間くらいという爆速転職活動。「会社の意思決定の速さ」は個人的に注目しているポイントで、その点は印象がよかったです。
何より、社風が合わないリスクが低いのがよかった。社員10数人のうちZさん含め2人と一緒に仕事をしたことがあり、性格的にもそれなりに合う人たち。彼らが生き生き働いているのであれば大丈夫だろうと、そう思った次第です。
まあWebエンジニアやめると言っておきながらアレですが、全力でコミュ障こじらせていたエンジニアの私をよく知っている人たちと働くことになりますので、なんだかんだコードは読むだろうし、場合によっては書くかもしれません。
別にエンジニアリング自体に飽きたわけでもなし、まったり何か作ったりするかもしれません。
とはいえ、肩書きとしてのエンジニアとかデベロッパーとかは来月いっぱいをもってしばらくおやすみです。
ブログ自体は何らかの形で続けていくつもりですが、コンテンツをどうするかは考え中。平日の勉強会にいけるかもわからないし、そもそもエンジニア以外おことわり系のコミュニティもありそうなんで。実質企業の採用イベントみたいなやつとか。
今回はこんなところで。長い自分語りにお付き合いいただいてありがとうございました！
WEBエンジニア勉強会にお邪魔してきた話
気がつけば前回からだいぶん間が空いてしまったのですが、これ行ってきました！
web-engineer-meetup.connpass.com
私自身、こちらのイベントは7回目(多分)に1回参加して、今回が2回目です。
会場も広く、前回以上に大盛況！初心者歓迎ということもあってか、参加者はお若い方が多かった印象です。
最近新しく業界に入ってくる人たちのコミュ力の高さというか、横のつながり積極的に作りに行くスタンスがすごい。
開催レポートはOSCAさんが書いてくださっているので、内容が気になる！という方はこちらをご覧いただくと話が早いかと。資料へのリンクもがっつり貼ってくださってます。
私からは参加者目線での雑感など、簡単にお届けできればと思います！
以下、枠ごとの感想です。
- WEBサイトが「できた！」と安心する前に最終チェックすること
- Docker Compose 利用者から見た Kubernetes 開発環境構築入門
- Webエンジニアの常識とは？
- モノ作りができるエンジニアになること
- garoonからgoogleに！（カレンダー移行）
- 覚醒するアクセシビリティ
- リーダブルコード
- まとめ
WEBサイトが「できた！」と安心する前に最終チェックすること
主催のOSCAさんの登壇です。個人的には今回、一番刺さったお話でした。
特にWebサービス納品するSIerさんは要チェック。
内容的には
などなど、ちゃんと準備しましたか？という感じ。
この記事とか内容的には近いかもしれません。
要件定義から含めておくのが理想……とはOSCAさんの談ですが、抜けやすいんですよねえ。共感しすぎて呟きが止まらなくなりました。
今回WEBエンジニア歴1年未満の方も多かったとのことで、非常に有意義な時間だったのではないでしょうか。
Docker Compose 利用者から見た Kubernetes 開発環境構築入門
流行りの(?)Kubernetesについて。
Kubernetesの基本的な考え方はもちろん、Docker Composeと比べて何が嬉しいのかや、移行の手順についても盛り込んでくださっていて、とっつきやすいお話でした。
個人的にコンテナオーケストレーションはそこまで興味がない分野でして(Docker Composeは業務で仕方なく使っている)、「もうちょっと熟れてきてから触ればいっかなー」みたいな考えでしたが、発表を聞くとぼちぼち勉強するタイミングが来ているのかな？なんて思います。コミュニティで盛り上がってるレベルから、実務で普及するフェーズに入ってきているというか。
特にミッションクリティカルなサービスを作っている場合など、「プロの仕事」としてサービスを作るのにお役立ちですね。
Webエンジニアの常識とは？
一言で書くと、「基礎は大事」という内容でした。
確かにWeb界隈の技術的なトレンドってビックリするくらい変化が激しいですよね。
特にフロントエンドは毎年違うフレームワークなりライブラリなりが推されていて、もはや訳がわかりません。Nuxt.jsとか「気がついたらそこにいた」みたいな……
そんな中でも基礎はそこまで変わっていない、というのはまさにその通りだと思います。新人の頃に覚えたStrutsの内部構造はもはやほとんど役に立ちませんが、「HTTPリクエストとはなんぞや？」というのは今でもバッチリ使ってます。
「基礎は大事」って言葉だけを見ると当たり前に感じてしまいますが、折に触れて確認したいポイントです。久しぶりに座学のお勉強もしたくなりました。
モノ作りができるエンジニアになること
「肝心なのはエンジニアになった後」「一人でモノ作りができると強いぞ」という強烈なメッセージを受け取った10分間。
これもITエンジニアとしてこれから頑張ろう！という方にとって、すごく良い時間だったのではないかと思います。
インフラからフロントまで通しで面倒見ていけると、仕事の幅が広がりますよね。開発部隊が小さいベンチャーとか、基本設計的なところとか。あと純粋に楽しい。
garoonからgoogleに！（カレンダー移行）
結論：Goはいいぞ！
Goでカレンダー移行をした話です。
時間的な制約もあって超特急の発表でしたが、手順をしっかりと踏んだスライドが素敵でした。
覚醒するアクセシビリティ
やりたかっただけですごめんなさい。
とまあ冗談はさておき、アクセシビリティはユーザビリティ以前の問題！というお話でした。5分という短い枠でしたが、熱いトークだった……！
アクセシビリティ周りって調べてもまだまだ資料が少ないんですよね。もっと長い枠でがっつりお話伺いたかった。
リーダブルコード
タイトル通り、可読性の話。
読みやすいコード書こうぜ！にとどまらず、「チームとしてコーディング規約をちゃんと纏めていこう」とか「それでもコードレビューは揉めるもの」とか、より実践的なチーム開発の場を想定してお話くださったのが印象的でした。
自分自身のコードレビューを振り返ると「好みの問題かもしれませんが…」みたいなエクスキューズをよく置いてしまっていて、チームとしての方針をきっちり整理しておくことでより有益・客観的な指摘ができるのかなーなんて。
まとめ
いやあ、行って良かった(小並感)
会場の雰囲気がすごくオープンで、登壇者の皆さんもイベントの成功にすごく協力的な雰囲気。巻きで進めた後半の疾走感がすごかったです(笑)
いいコミュニティだなあ、なんて勝手に和んでおりました。
発表テーマは初心者の方にも優しい内容が多かった感じ。
私自身はそろそろ初心者名乗れなくなってきてますが、「できてるつもり」のポイントを再確認する良い機会になりました。
(今回不参加でしたが)懇親会も登壇者との距離感がかなり近かった記憶があります。
勉強会に行ってみたいけど、丸一日のカンファレンスはちょっと重いかも……みたいな方にも猛烈にオススメしたい！
次回は10月末〜11月とのことで、予定が合えばまた是非参加させていただきたいなと思います。
では、今回はこの辺りで。
Developers Summit 2018 Summer に行ってきたぞ！
毎回大盛況のDevelopers Summitが、7/27に東京で開催されました！
実は春も申し込んでいたのですが、運悪く社内行事と被ってしまい泣く泣くキャンセルしたのでした。
その分今回は気合いを入れて申し込……んだはいいものの、セッションが追加されるたび一瞬で満員に！
あまりの人気さに何度マウスを持つ手が震えたことか……結局事前予約取れなかった枠あるし……
そういう状況ですので、今回は畑違いの機械学習系セッションにも構わず突撃しております。
ちゃんとお話を受け止め切れているか自信がないぞ……？
参加者層は平日日中ということもあってかスーツのおじさま率が高めな印象。そして圧倒的男女比でした。
詳細についてはおそらくちゃんとしたライターさんが記事にしてくださるでしょう！（他力本願）
が、私からもいち参加者としての感想など、軽くお届けしていけたらと思います。
- ソニーが提供するディープラーニングの開発環境の紹介と活用事例
- AI時代におけるエンジニアの生存戦略
- Hashicorp Vault on Google Cloud Platform
- Alibaba Cloudで実現する、クラウド時代のデータ分析基盤の設計とその道のり
- ソーシャルゲームを分析せよ！〜社内分析チームの立ち上げから学んだデータ分析のための組織と技術
- EdTechトップランナーに学ぶ！幸せに生きるための学び方
- データと戦うエンジニアLT！
- その他
ソニーが提供するディープラーニングの開発環境の紹介と活用事例
朝イチはソニーの成平さんのセッション。こちらのツールをご紹介いただきました。
自分はAIわからないマンなので、初っ端にAIが今どういう状況なのかを説明いただいた段階でもうビックリ。画像認識の精度はとっくに人間を超えていて、今なお年率50%くらいの勢いで精度が向上しているとのこと。
昔と比べて扱いやすくもなり、ビジネス側の人がどんどんディープラーニング使い始めている状況だそうです。デモも拝見しましたが、確かにこれは非エンジニアでも余裕で触れそう！
ブログも日英両方で更新されるそうです。
日本語情報にアクセスしやすいのは、特に素人にとっては嬉しいところ。
ONNXにも対応しているそうなので、TensorFlowやらChainerやらをお使いの方も安心……かと思いきや、若干含みを持たせた口ぶりの成平さん。移行などを検討する場合は、事前にこの辺りはチェックした方が良さそうです。
個人的に気になったのは、「機械学習でモノを言うのはデータ量」「なんだかんだ力技」というポイント。
SoRの時代にどれだけのデータ資産を築いたかが、AIを使った施策に効いてくるという印象です。これは古くからきっちりIT投資して、データの蓄積を進めてきた大企業に有利なはず。
結びつけるのは乱暴かもしれませんが、昨今の銀行リストラ祭りの話が脳裏を過ぎります。安定を求めて入社した人の多い大企業ほど、AIの威力が高くてリストラが進むのでは……とか妄想していると、ちょっと皮肉な感じも。
あとソニーの人もGitHubでOSS活動とかやるんだなあ……みたいなヘンな感慨がありました。 国内のメーカー系ってその辺りなんとなく保守的な印象があったので。
AI時代におけるエンジニアの生存戦略
B会場で続けて受講。
パソナキャリアの高坂さんとDATUM STUDIOの安部さんによるセッションです。
大前提として日本のAI市場は人不足！
「Society5.0に対応するためには、AI人材の育成の抜本的な加速化が必要」
と言われているようです。
不勉強でSociety5.0はじめて知りましたが、これですかね。
とはいえ私のような門外漢からすると、「AI人材」ってどういう人材なのかがイマイチピンと来なかったりします。
Pythonで機械学習のコードを書いていて、最先端の機械学習の論文が読めて、統計の専門的な知識があって……みたいな、スーパーマンが頭に浮かびます。敷居が高い。
そこをバッチリ整理してくださったのが安部さん。
データサイエンティストに求められる要素は「ビジネス」「統計」「エンジニアリング」の３つあり、組織全体として３要素をカバーするのが基本、とのこと。
ただし専門分野が分かれると「無理解の壁」が生じがち……だとか。
従来の開発現場でも「ビジネス」と「エンジニアリング」のコミュニケーションに問題があるケースというのは多かったんじゃないかと思いますが、要素が増える分、チームビルディングには一層注意を向けていく必要がありそうです。
面白かったのが終盤の質疑応答コーナー。
高坂さんの質問に安部さんが答えていく、というスタイルで展開されたのですが、質問の内容が鋭い鋭い。
「今のAIってバブルなんじゃないの？」
「エンジニアの仕事すらAIに取って代わられるんじゃない？」
など、データサイエンティストにちょっと興味はあるけど先々続けられるか不安……という層にグッと刺さる内容でした。
Hashicorp Vault on Google Cloud Platform
ランチセッションは、クレデンシャル管理ツールVaultのお話を聴きにいきました。スピーカーはgrasysの守永さん。
正直現状のクレデンシャル管理にそこまで問題意識を持っていなくて、あんまりVaultの嬉しさが実感できてないです……
人の入れ替わりが激しい大規模プロジェクトとか、セキュリティ認証かなんかの関係でめちゃくちゃ監査が厳しいプロジェクトとかだと必要になってくるんでしょうか。
Vault関連の情報について、ブログでの発信を予定しているとのことでした。
ちらっとgrasysさんのブログ拝見した感じ、だいたい月イチ更新のようです。Vaultに限らずHashicorp製品に興味のある方は、たまにチェックしてみるといいことあるかもしれません。
サンドイッチの写真撮ったので載せときます。解像度がでかいwww
Alibaba Cloudで実現する、クラウド時代のデータ分析基盤の設計とその道のり
午後イチ……のセッションは取れなかったのでブースを冷やかしつつ休憩。
（立ち見する元気がなかった）
14:00からの枠はSBクラウドから、森さん、Haさん、井浦さんのセッションです。
気合の入った配布資料をいただいたので一瞬「会社説明会……？」とか思いましたが、ビジネス的な部分から、論文レベルの濃い技術ネタまで盛り込んだAlibaba Cloudの宣伝セッションでした。
国内大手ECサイト1年分のトランザクションを、たった1日で記録することもあるという中国のモンスターECサイト。それを支える技術ということで、分散FSの独自実装はじめ様々な工夫が凝らされている模様。
特にリソース管理とジョブスケジューリングを担当するFuxiについては詳しく説明いただきました。元論文これかな？幸い中国語ではなく英語なので、興味のある方はチャレンジしてみては。
http://www.vldb.org/pvldb/vol7/p1393-zhang.pdf
むかし社内でPaxosの話をした時にもちょっと思ったんですが、もしかして学生時代に研究室内部でやってたような論文紹介、社会人のエンジニア向けにやるのって需要ある……？
気になる性能、お値段、セキュリティですが、性能・コストパフォーマンスについては国際的なベンチマークでAWSなどの競合を差し置いてトップを叩き出しているとのこと。セキュリティ面も「マルチテナント設計思想」で、当局がデータを勝手に覗き見……なんてことはできないそうです。
出自が出自だけにビッグデータの取り扱いには特に力を入れているようで、BI・可視化ツールも提供しているとのこと。
もちろん多少のポジショントークはあると思いますが、これからクラウドの移行など検討する場合は十分候補に入ってくるのではないでしょうか。
（無料トライアルもあるそうですし）
資料は加工かかったツルツルの紙質だし、アンケートのお礼はえらいしっかりした手提げだし、さすがAlibaba儲かってんな、という下世話な感想を抱いてしまいました。
ソーシャルゲームを分析せよ！〜社内分析チームの立ち上げから学んだデータ分析のための組織と技術
続いてはgumiの今村さんのセッション。
パッと聞いてわかりやすいお話だったこともあり、内容についてはtogetterがいい感じにまとまっています。
病院の例えはいいですね。
社内分析チームと外部のデータ分析会社をどう使い分けるのか、端的に表す例えじゃないかと思います。
聞いていて感じたのは、社内分析チームが力を発揮しやすい組織とそうじゃない組織がありそうだ、ということ。
「直接的な成果になりづらく、空振りも多い」データ分析チーム。裏を返せば彼らを最大限活かすには、細かい施策を嫌がらず、失敗も許容する文化が必要なのではないでしょうか。
EdTechトップランナーに学ぶ！幸せに生きるための学び方
さて、来ました。個人的に今回、一番面白かったセッションです。
スピーカーはLoiLoの杉山さん。
「ロイロノート・スクール」というアプリを手がけていらっしゃいます。
自分はいち情弱ゆとり世代として、「アウトプットの大切さといい、積極的に仕事を取りに行く姿勢といい、社会人になる前後に学ぶべきマインドが多すぎる！」と常々頭を抱えているのですが……驚きました。
ご紹介いただいた学校の授業風景は、一目で「子供が主役」とわかる、ザ・アクティブラーニング。小学生のプレゼン動画見せてもらいましたが、信じられないくらい上手。
音楽の授業で自撮りしながら歌う風景はなかなかシュールでしたが……確かに録音してみてわかることもあるよね……
こういう教育を受けた子供達があと10年かそこらで労働市場に出てくるのかと思うと、楽しみな反面、脅威にも感じます。彼らとしっかり向き合っていけるように、自分自身も成長していきたいですね。
データと戦うエンジニアLT！
最後はLT！4名のスピーカーが登壇されました。
トップバッターは司会も務められたミーカンパニー田野口さん。
「ゴッド」っていう肩書きがずるいw
内容的にはMySQL UDFでデータを綺麗にする話。
手入力されたデータってたまにとんでもないの入ってますよね。
「MySQL UDFの裏側で普通のシステムが動く」みたいな話があり、面白かった反面、腕のいいアーキテクトがいない現場で使うとあっという間に黒魔術が生まれる気配を感じました。ご利用は計画的に。
２番手は犬塚さん。なんと学生さんです。
クックパッドで学生って聞くともうなんか凄腕っぽい気配がして震える。
クックパッドのレシピに紛れ込んだ「手順もどき」を検出した話。Deep Learningまでやらなくても、ロジスティック回帰で92%とか結果出たそうです。
「やるべきことを、やるべき順で」という言葉が印象的でした。
機材の不調で順番が入れ替わり、Reproの今井さんが次に。
機械学習の精度をビジネス的な価値にどう結びつけて行くかが重要だ、という当たり前だけど忘れやすい話をしていただきました。
AWS SageMakerはいいぞー、とのこと。
大トリはシルバーエッグ・テクノロジーから田本さん。
これ、すごかった。
単語レベルじゃなくて文字レベルのCNNを使って、誤字・脱字に強いネガポジ判定器を作った話。
何がすごいって、分かち書きの必要がないところ。
素人考えですが、漢字とか絵文字の多いデータセットではこのアプローチってすごく自然なんじゃ……？と思います。英語、日本語、中国語でどういう特徴が出るのかとか、めちゃくちゃ興味あります。
その他
嬉しかったのが、プリントオンデマンドの書籍が平積みで売ってるところ！
「ちょっとほしい……でも申込フォームとか書くほどのモチベーションは……ほら今月もう◯冊買ったしここは我慢を」
みたいな本が普通に売られているわけで、まあ買うよね。
流石に運営人数もしっかり確保されていて、ちょっとした困りごとにも丁寧に対応していただけました。
反省としては、やっぱ機械学習系のセッションは本職のデータサイエンティストの方が100倍楽しめただろうなという点。業界動向はじめ勉強になりましたが、予備知識が足りなかったのがとにかく悔やまれます。。
もし次の機会があれば、立ち見は承知で聞きたいセッションに突撃しようと思います！とりあえず前日深夜までお酒を飲むのはやめよう！！
