強い上司は福利厚生
以前勤めていた会社の強いエンジニアの人が「強いエンジニアがいるのは福利厚生」と仰っていました。
意味合い的には、強いエンジニアがいる環境で切磋琢磨されて、自分自身もすごく成長出来るといった意味合いだった気がします。（何年か前なので）
あれから数年、やっと自分もその意味が分かるようになったのですが、私の場合は「強い上司は福利厚生」ということにたどり着きました。
"強い"という言葉には色々な意味がありますが、簡単に書くと"尊敬できる"という言葉へ置き換えられると思います。
"尊敬できる"にも色んな意味があるのですが、仕事の進め方・姿勢であったり考え方であったり、知見の深さや言葉の分かりやすさなどすごいなと。
他にも具体的にどんな所がというのは沢山あり過ぎて言語化が難しいのですが、"強い上司"のもと、自分の足りない所を自己認識して、パワーと知恵をもらって自分が成長出来るというのは素晴らしいことだなぁと最近感じています。
"福利厚生"というのは、そういった尊敬出来る上司のもと、考え方や姿勢を学んで自分が成長していけるという意味合いです。
非金銭的報酬として、中長期的に見るとこれ物凄いメリットなんじゃないかな。
めちゃくちゃ高い壁だけど、いつか乗り越えていくぞという気持ちをここに記録しておきます。
転職して暫く経過した
転職してから、気がついたらおおよそ2ヶ月ぐらい経過してました。
最近になって気がついたのは、誰かのブログ記事を読んで、それに触発されて「あー、なるほど。自分も思ったことを書こう。」みたいなことが多いです。
そういう風に見知らぬ誰かに気づきを与えるとか、啓発できるのってすごいなと思います。
この2ヶ月でやってきたこと
コードを書く仕事ではないので相変わらずコードは書いていないのですが、エンジニアを取り巻く環境の整備であったりなどをずっとやっています。
なかなか大変なことも多く、自分が知らなくて「えっ、そうだったの？」ということもあるのですが、ある意味で新しい発見も多くて面白さを感じて仕事をしています。
入社してからずっとリモートということもあり、新入社員ならではのコミュニケーションで難しく感じる部分がより難しく感じることあるのですが、ぼちぼち頑張ってやっていっています。
新しい職場・チームにジョインした時に気をつけた方が良いこと
ところで、私は自分でも不思議なことに転職回数が物凄く多いです。
かなりではなく、物凄く多い方だと思ってます。
もう何回目の新入社員体験だっけというのはあるのですが、いいかげんいい年齢になってきたこともあり、新入社員体験にも多少の慣れが出てきました。
転職して（あるいは似たような場面において）これを気をつけておく・やっておくといいかなーと思うものをつらつら書いてみます。
自分の立ち位置を把握・認識・確認する
結構大事なことだと思います。
自分の役割・立ち位置は何なのか、それは組織の方向性やミッションとどのようにリンクしているのか、これを理解していないと歯車がうまく噛み合いません。
必ずしも自分のやりたいこと・やりたくなってきたことが組織の目指す方向性と一致するわけではないので、立ち位置をしっかり確認した上で、バリューを発揮していくのが良いです。
過去の自分の経験ですが、社長直轄で新規チームの立ち上げポジション入社したのは良かったものの、関連する他部署が認識している私の役割とズレがあり、入社早々「えっ？」ということがありました。
必ずしも"自分の役割をみんな同じように認識してくれている"ということではないので、上司・同僚と認識を合わせていくことは入社早々においては大事なことだと感じています。
自分の得意領域を作る・得意領域を発揮する
十数年前に今でいうSESで働いていた時、出向先の人から言われました。
自分の得意領域を作ると、そこが自信につながって良いサイクルが回っていく・回していける可能性が高まります。
20代前半だったので「自分の得意領域を作る」だったのですが、そこそこ歳をとった中途になると、自分の得意領域で最初のバリューを発揮することが大事です。
ここでいう得意領域とは、ハードスキルだけではなくソフトスキルも含んでいます。
例えば、私は今まで色んな会社・組織・チームで仕事をしてきたこともあり、周囲への働きかけだったり調整ごとは得意かなと自分では認識しています。
現職においても、そういったスキルは物凄く大事な場面が多々あり、そこを評価してもらえて今ここにいるんだと思うこともあります。
まずは自分の得意領域で周囲に認めてもらう・自分が何者なのかを知ってもらい、そこから次の一歩を踏み出すことが大事です。
最初に書いた「私ってこういう役割でここにいます」とセットで知ってもらうことで、「何者なのか」が認識されやすくなります。
これは逆に自分が中途入社の方を受け入れる際にも言えることです。
その人の得意分野や立ち位置を知ることで、コミュニケーションをとるハードルも下がります。
周囲に興味をもつ
一緒に仕事をしていく人達に興味を持つことは大事なことです。
顔色をうかがうとかではなく、その人の得意分野・不得意分野・個性などを知ることでコミュニケーションも取りやすくなり、組織・チームにもはやく馴染むことができます。
自己開示をする
自分の役割・立ち位置というのとは別の観点で、私はいつも新しい職場・チームでは積極的に自己開示をしています。
私に対して興味を持ってもらうというよりも、知ってもらうことでお互いにコミュニケーションを取りやすくしたい、スムーズにやっていきたいという思いからです。
特にチームリーダー以上の役割で働く場合、これは凄く大事なことです。
「相手に話をしてもらうには、まず自分から」と考えていることもあり、プライベートの深い所まで話す時もあります。
相手に同じレベルを求めるとかではなく、私はここまで話すことができますというサインを送っている感覚でしょうか。
自分に自信をもつ
入った組織が自分が想定しているよりもハイレベルで、やっていけるのか不安になった。
担当チームのメンバーのクセが強くて、チームを率いていけるのか不安になった。
知らないことが多すぎて、どこから手を付けていいのか分からなくなった。
これらは全部自分の経験でもありますが、自分に自信をもたないと上手くいくものもうまくいきません。
なぜそこにいるのか、それは自分以外の誰かから何らか認められたのでそこにいる、それを認識するだけでも自信をもつことにつながります。
そんなこんなで、難しいこともありますが、それらも含めて楽しくやっていけてるので良かったな〜という今日この頃です。
社内やチームに強いエンジニアがいるというのは一種の福利厚生だと自分は思うのですが、それと同じく強い上司がいるというのも一種の福利厚生だと思うのです。
いつか自分がそう思われるように、日々頑張ります。
DXエンジニアになって2週間が経過しました
こんにちは。
転職して2週間が経過しました、1日出社し、翌日からはずっとリモートという過酷な状況が続いていますが、元気でやっています。 この2週間で思ったのは、今まで属してきた中で一番大きな組織なので、難しいことも多いなということです。 例えば「エイヤ！」でやれることが出来なかったり、色々と気にしないといけないことが多くあり、なかなか難しいなと。 ただこれらはネガティブな意味ではなく、ポジティブな意味でそれだけのサービスに携わっているという認識をしています。 そういった意味でも、この歳になっても新しい発見が多く、やり甲斐を感じる日々です。
職種はDXエンジニアということで、Developer eXperienceを高めていく仕事をしているのですが、実際には自分が想像していた上に幅が広いです。 このDXという観点自体がものすごく広いのですが、会社の規模によっても求められることが大きく変わるであろうし、組織のフェーズによっても求められるものが変わるのだなと思います。
めちゃ雑に書くと、過去に携わった「エンジニアをワクワクさせる」ために知恵を振り絞ってやっていく仕事だなと思っています。（今時点では）
「エンジニアをワクワクさせる」とはなんだろうか、これは人それぞれなので色んな解釈があると思いますし、答えはないと思っています。 自分の仕事や行動で誰か一人でもワクワクしてくれれば…と今までは思っていたのですが、それだとスケールしないので、スケールさせるためにどうするかを考える日々です。
などとぼんやり考えている中で、良い話にめぐりあったので貼っておきます。
エンジニアリングマネージャーではないけど、エンジニアリングマネージャーの要素は知っておかないといけないなと思ったし、とにもかくにもインプット量が足りなくてヤバイみたいな状態なので、引き続き頑張ります。
最後に
今まで〜エンジニアという職種を何度か経験したのですが、いつも「開発しないし、プログラミング出来ないしなぁ（適性ないしなぁ）」と思っていたのですが、エンジニアとは技術力を以て設計・構築・開発をして課題を解決していく職種であると言われたこともあり、胸を張ってDXエンジニアと名乗っていこうと思います。（胸を張れるように頑張る）
転職しました
4月末でSENSYを退職し、5月からカカクコムに入社しました。 自分の記録という意味も込めて、エントリー書いておきます。
これまでやってきたこと（前半）
前職では情報システム担当者兼エンジニアリング担当として入社しました。
兼というのは、情シスとしては1ヶ月分丸々やることがそんなにないよねっていうこともあり、兼務という形です。
入社して最初のころは日々の情シス業務に加えて、プロジェクトメンバーとしてBigQueryを触って簡単なSQLを書いたり、ほんの触りのデータサイエンス業務をやってました。 SQL書くのが数年ぶりということもあり、当時技術書典で気になっていた「わかりみSQL」を買って勉強しながらSQL叩いてました。
わかりみSQLは評判通りの良書なので、これからSQL触る人にはとってもオススメです。
その後、プロジェクトが落ち着いたタイミングで社内状況にも変化があり、情シス兼人事総務採用担当という形で仕事をすることとなりました。 これまで人事採用の経験は「事業部側として採用する立場」ではあったのですが、人事としての立場では経験はありませんでした。 実の所、仕事としての人事採用に昔から興味があり、今回は自ら手を挙げたところ任せてもらえることとなり、その点については本当に経営陣に感謝しています。
これまでやってきたこと（後半）
後半は主に人事採用に力を入れて、会社の全部門（管理部門、ビジネス部門、エンジニアリング部門）の採用に関わりました。 短い期間ではありましたが、結果としてビジネス部門でもエンジニアリング部門でもオファーを出させていただき、複数名の方に入社いただけました。 採用の仕事を通じて「自分の考える採用」が出来たのは、今でも心から良かったなと思っています。
「自分の考える採用」とは、当たり前のことを当たり前にやる、です。
特にスカウトにおいて、ある程度のテンプレート化は必要ですが、
- スカウト対象の方のプロフィールをちゃんと読んで
- このさきやっていきたいこととマッチするかを考えて
- ちゃんと理由を添えてスカウトをしていますよ
ということを伝えるようにしました。
私はこれらをとても当たり前のことだと思うのですが、自分の原体験として「ほんとにプロフィール読んでスカウト送ってるんだろうか？」というものや、スカウトに「開発経験ありませんが、それでも大丈夫ですか？」と送ったら次の返信で祈られたり、候補者体験を損なうような経験がありました。
100%完璧な仕事というのは難しいですが、少なくとも候補者体験を損なうようなことはあまりしたくないなという思いの元、スカウトを頑張って送りました。 スカウト作業ってやってみると思っている以上に大変で、すぐに時間が溶けたり、母集団を形成できなくなったりします。 なのでキーワードを変えてみる、対象を広げてみるなどの試行錯誤もしつつ、3ヶ月ちょっとで3桁のスカウトを送ることができました。
スカウトの返信率はだいたい10%前後と言われており、15%でちょっと高い方らしいのですが、これらのことが奏功したのか返信率平均20%という結果に落ち着きました。 返信があれば良いというものではないですが、一つの指標として人事未経験者が自分の経験をベースに頑張って、この数値を出せたので素直に喜んでます。
また、採用を進めていると自分からスカウトしたものの、見送りになることも多々あります。 私の経験からも自主応募の場合、見送りとなった理由を教えてもらえないことが多いです、理由を教えてもらうためにもエージェントを経由した方が良いという話も聞きます。 なので基本的には極力見送りとなった場合においても、その理由を添えるようにしていました、これも自分の原体験からです。
転職はマッチング
私が候補者の方にも伝えていることなのですが、転職とはマッチングだと捉えています。 採用する企業側と同じく、候補者の方にも不必要に下手に出ずに「自分はこの会社とマッチするかどうか」を見て欲しいし、見るべきです。 なぜならミスマッチで入った場合、お互いに苦労するし、悲しい気持ちになりかねないからです。 もちろん入ってからでないと分からないことは多いし、全部が全部開示すべきという話ではありません。 かといって、情報を隠せという話でももちろんありません。
そういった理由もあり、話せる範囲のことはお話しし、出来る限り候補者の味方であるように努めました。
転職はマッチングだという理由に、縁とタイミングもあると思っています。 例えば時間を空けて複数買い応募して見送りが続くも、結果的に採用された話をたまに聞きます。 その人の能力であったり、会社側の人員充足状況や事業フェーズによって入りやすい・入りにくいというものが存在します。 なので、入りたい会社に一度落ちたとしても、諦めずにアタックすればいつか叶う日も来るかも知れません。 ※もちろん継続的に自分をアップデートすることが大事です
カカクコムへの入社経緯
Twitterではないのですが、いわゆるソーシャル転職という類に入ると思います。 とあるSlackのワークスペースで求人募集を知り、仕事内容が面白そうだったことと、これまでの自分の経験が色々活かせそうだということもあり、コメントを投稿された方に声をかけ、カジュアル面談でお話ししましょうとなりました。 ソーシャル経由というのは初めてだったのですが、カジュアル面談の前でも「実際どうなんです？」みたいに気軽に聞けるのはとても良いなと思いました。 実際に私もSlack上のちょっとしたやり取りを経てカジュアル面談行ってみたいなという気持ちが固まりました。
しかし正直カジュアル面談を受けた段階では転職自体の意思がなく、他社ではどんなカジュアル面談をやっているんだろう、参考にさせてもらおうという気持ちも多少ありました。
が、カジュアル面談で話が弾み、トントン拍子に一次面接のご案内をいただき、無事通過して二次面接へと進みました。 一次面接の段階で転職の意欲が高まっており、上司にあたる方との面接でも色々な話（今後のビジョンや困っていることなど）を聞けたこともあり、無事オファーをいただけて一安心しました。
「転職はマッチング」と自分でも書いていますが、Developer Successという職種もわりと新しい分野ですし、会社側としてもある程度の経験者を求めているということもあり、本当にタイミングが良かったんだなと感じています。
カカクコムでやること
食べログ事業部にてDeveloper Successチーム（DXチーム）のチームリーダーを担当します。 Developer Successとは文字通りシステムやサービス開発プロセスの改善をすることで、エンジニアのパフォーマンスを向上させ、サービスを利用するお客様へより良いユーザー体験を届ける支援をするチームです。 2019年10月に発足したばかりということなので、まだ出来たばかりですが、その分いろいろ出来ることもやれることもあって楽しそうと思っています。
自分のキャリアとしてカスタマーサポート・テクニカルサポート・カスタマーサクセスの経験があるのですが、それらの観点も十分活かしながら、エンジニアリングに近い所で仕事をしてきた経験も発揮出来るのかなという期待の気持ちもあれば、大企業でやっていけるかなというちょっとだけ不安な気持ちもあります。
最近はずっとベンチャーが続いていたことと、これまで勤務した会社の企業規模的には最大で100人前後だったということもあり、面接でも結構突っ込まれたのですが、まずは自分の手元・足元をしっかり固めて頑張っていきたいなという気持ちでいます。
Railsチュートリアル第5章メモ
5.2 Sassとアセットパイプライン
- SaasのSCSS記法を利用することで色々な機能が使える
- ネスト
.center { text-align: center; } .center h1 { margin-bottom: 10px; } /* この書き方をSassを使うことで以下のように書き換えられる 下のh1は.centerを継承している */ .center { text-align: center; h1 { margin-bottom: 10px; } h2 { color: red; }
#logo { float: left; margin-right: 10px; font-size: 1.7em; color: #fff; text-transform: uppercase; letter-spacing: -1px; padding-top: 9px; font-weight: bold; } #logo:hover { color: #fff; text-emphasis-color: none; } /* これがこうなる-idの場合は&を使ってネストする- */ #logo { float: left; margin-right: 10px; font-size: 1.7em; color: #fff; text-transform: uppercase; letter-spacing: -1px; padding-top: 9px; font-weight: bold; &:hover { color: #fff; text-emphasis-color: none; } }
- 変数
- カラーコード等を定義する時に便利
$light-gray: #777; h1 { color: $light-gray; } h2 { color: $light-gray; }
5.4 リンクのテスト
- rails generate integration_test テスト名 で統合テストのテンプレートが作成できる
- assert_selectのオプションを使用してリンクのテストができる
# "?"の部分に引数のabout_pathを入れている、リンクが存在するかどうかの確認 assert_select "a[href=?]", about_path # "count: 2"でroot_pathのリンクが2つあるかどうかの確認 assert_select "a[href=?]", root_path, count: 2
- assertの使用例は"表 5.2: assert_selectのいくつかの使用例"を参照
5.4の最後の最後で統合テストが失敗。 失敗箇所は"/about"と"/contact"が見つからないとのこと。
やったこととして、 - ルーティングの確認（正常だった） - HTMLソースの確認（/aboutも/contactも見つかった） - 最初は"/about"がfailしたので、その行をコメントアウトしてテスト続行→"/contact"も失敗となる - RailsチュートリアルからコードをコピペしてもNG - header部分のテストはOK、footerに関わる2箇所がNGなのでfooterが原因…？ - ということも考えたけど、時間かけて悩んでも仕方が無いこと、とりあえず見るべきところは見て、やるべきことはやったので先へ進むことに。。
うーん、謎
Railsチュートリアル第4章を終えた
良かったこととか色々
- putsとprintが理解出来た、putsしか知らなかったのでprintないのかと思ってた…
- putsは改行文字を含んだ出力になる。
- printは改行文字を含まない出力になる。
- なのでprintに改行文字を含ませると、putsと同じ出力になる。
- メソッドの書き方・使い方に多少慣れてきた
悩んだところ
その他
オブジェクト指向が難しいって初めてこの業界に入った、もう20年近く前にも同じようなこと聞いた気がするなぁなど
Railsチュートリアル第3章を終えた
OKRを読み終えた
OKRを読み終えました。
突然ですが、個人的にMBOって好きじゃないのです。 自分にとってのMBOの記憶というと、もう10年ぐらい前の話でネットワーク保守周りをやっていた頃に遡るのですが・・・
- NW稼働率99.98%を維持する
- B級/BC級障害発生件数を＊件に抑える
とか、アンコントローラブルな数値目標で全体の50%以上を占めていたのですね。当時25歳ぐらいった気がするので、もう10年以上前ですね。 NW稼働率99.98%を維持するために何が必要なのか、という観点は確かに大事なのだけど、主体的にそれに対して何かができる環境でもなく、そのためのスキルアップだったり何かを学べる環境というのでもなかったので、単純に減点方式の目標というイメージしか無くて辛かった思い出です。
なので、それに対してOKRは評価システムとしてどうなんだという気持ちで変な先入観があったのですが、本書を読み進めていく内に最初は「なにこれホラー小説じゃん」という気持ちから、徐々に「OKRすごい！個人でもやってみたい！」という気持ちに変化していきました。 OKRは4半期毎、つまり3ヶ月ごとに設定して突き進んでいくという所に変化に対する柔軟性を感じられたのが自分にとっては新鮮味がありました。
ちょっと色々書いてみようと思ってはみたものの、実際に自分がOKRを導入した職場で働けていない、個人としてもOKR考えられていないということもあり、あまり書けることもないのでこのへんで。
色々と落ち着いた頃には、仕事じゃなくて個人としてのOKRというものを考えてみたいなと思えるぐらいの良書でした。
- 作者:クリスティーナ・ウォドキー
- 発売日: 2018/03/15
- メディア: Kindle版
Railsチュートリアル第2章を終えた
良かったこととか色々
- 事前にProgateのWEBパスコースをやっていたので、Railsのdb周りとかも多少理解できていた
- dbの複数テーブルを関連付ける
has_manyとかbelogs_toとかはProgateで出てこなかったので、なるほど感があった - VSCをRubyいじるようにちょっとプラグイン入れたりした
- Progateの場合はmigrateファイルを編集してmigrateしてたんだけど、generateコマンド実行時にそのままカラムも一緒に指定したりと色々と違いが分かった
悩んだところ
- 演習でちょっと悩んだ所があったけど、概ねだいたい出来た
- 書く→確認→エラー→typoとかがあるので、エラーメッセージの確認大事
その他
- 下処理としてProgateで事前に勉強しておいて良かった
Railsチュートリアル第1章を終えた
ちょっと前からやっていた、Railsチュートリアルの第1章を終えました。
良かったこととか色々
- 事前にProgateのWEBパスコースをやっていたので、Railsのファイル・ディレクトリ構成とかMVCが浅く分かっていたので良かった
- ProgateのWEBパスコースの最後でRubyとRailsの環境構築が終わっていたので、AWSのCloud9使わなくて済んだ
- heroku初めてだけどなんとかなった
悩んだところ
- rootのページを変える項番にて、チュートリアル通りに変えてみたのにRailsのトップページが何も変わらなくて悩んだ
- herokuのサインアップ周り、CLIでやるんだろうけどそもそもどうやんのかなというのでちょっと悩んだけど、何とかなった
その他
- 色々と考えるとCloud9使うのが便利そうだけど、ちょっと色んな事情があるのでローカル環境で継続しようと思っています
- 数年ぶりにgithubコマンド勉強し直した
- 普段はissueでのやり取りぐらいしかしない
- まだよく分からない所は多々あるので、引き続きやっていく
参考にしたもの
ローカルで触っていることもあり、今どのブランチだっけってのを分かりやすくするために参考にさせてもらいました
ちょっと古い記事だけど、rails newコマンドでバージョン指定する件について調べたら伊藤さんの記事が出てきた
