ProgateのWEBパスコースが終わった
最後の方はだいぶ駆け足感がありましたが、何とか頑張って終わらせました。
振り返ると、だいたい2〜3週間ぐらいかかってる感じでした。
基本的に仕事でプログラミング・コードを書くことがほぼないのだけど、プログラミング全くの初心者ではないので、自分なりにはサクサク進められた感じです。 とはいえ細かい所で気になった所も飛ばしてやってきた感はあるので、知識の定着というか、ふり返りという意味でも別のアプローチでやっていきたいと思ってます。
修了証はこちら。
Certificate of Web開発パス(Ruby on Rails) | プログラミングの入門なら基礎から学べるProgate[プロゲート]
今読んでいるもの
OKR
- 作者:クリスティーナ・ウォドキー
- 発売日: 2018/03/15
- メディア: Kindle版
まだ読んでます。
正直読んでる間はホラー小説にしか思えなかったのですが、前半部分も良い感じに終わり、一安心しました。 今まで仕事でOKRに向き合ったことは無かったのですが、今後OKRをベースにやっていくことになりそうなので、前提知識という意味もあって読んでいます。
OKRを導入すれば完璧とかではなく、目標に対してブレずに頑張ってやっていくためにはどうすれば良いかという一つの手法としてOKRが優れているという捉え方・認識をしています。
LeanとDevOpsの科学
こちらもまだ最初の方までしか進んでいません。
まだ最初の方しか読んでいないですが、科学的な裏付けがある（レポート・インタビュー・調査など）ということの大切さを感じます。 今在籍中の会社で、既に退職された人が書評をまとめられていたのですが、確かにこれは経営者や役員にも読んで欲しい一冊ですね。
これからやっていきたいもの
色々と調べていて、Railsチュートリアルとかが無料だし良いのかなと思いつつ、そもそもRuby自体をもう少し理解しておきたいという気持ちもあるので、Rubyを学ぶかチュートリアルやるかという感じです。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者:伊藤 淳一
- 発売日: 2017/11/25
- メディア: 大型本
Rubyを始めて2週間ぐらい経過した
色々あってRubyを勉強し始めることにして、2週間ちょっとが経過しました。 前職は管理職だったこともあって手を動かすことも減り、現職は情シス兼人事ということで手を動かす機会もほとんど無く、ほんとに久々に手を動かしています。
手を動かすことで、最近あんまり感じることのなかった「これこれ、コレだよね」感を感じることも多く、動作・仕様について調べる機会も増えました。 当たり前と言えば当たり前なんだけど、調べる中で分からないことも出てきて、それを調べて時間が無くなったり、ちょっと違う書き方をしてみて挙動をテストしてみるなどもあり、自分で試すことの大切さを改めて感じています。
そして、以前から興味があったけど実際に縁遠かったOKRについてもKindle本を買って読み始めています。 なんとなく聞いたことがあるけど、というレベル感だったのですが、本を50〜60％ぐらい読み進めて、これ個人でも出来るんじゃないかなと思っています。
Rubyの勉強も仕事が終わって家に帰ってきて、だいたい1〜2時間ぐらいする日がほとんどで、疲弊気味な時は10分でも15分でも軽めにやってます。 毎日続けることは大事だけど、1日出来なかったからといって凹む必要はないし、翌日やればいいだけだと思っています。 ※一日の遅れを取り戻すには〜と昔言われたことはあるけど
何が言いたいかと言うと、ちょっとしたきっかけがあり（色々あった）、それに対して自分でどうするべきかを考えて（Ruby勉強することに決めた）、実際に試行錯誤しながらやってみて（実際に手を動かした）、新しいものを取り入れて（書籍ではなくProgateで勉強し始めた）みると、意外と面白くて楽しく続けられています。 向き不向きは確かにあると思っていて、書籍を買って勉強してるともしかしたらRuby学習続かなかったのかなとか思ったりします。
他にも環境だったりタイミングだったり運だったりと色々あるとは思うけど、いきなり手を広げるのではなく、何か一つ決めて突き進みながら、徐々に周辺領域を学んでいくスタイルで暫くやってみようかなと考えています。
追記
正直ここまでRubyが面白いと思っていなかったのもあるけど、続けられている理由は「（外圧からの）必要に迫られて」というわけではないと思っています。 必要性は確かにあるんだけど、Rubyを理解して多少でも読めた方が仕事しやすいだろうし、きっと役に立つだろうなという自分自身への納得性が一番大きいのではないかな。 以前も似たような環境に身を置いたことがあったのだけど、その時とはちょっと状況も変わったし、自分も歳を取ったしで、あの時に今と同じ気持ちでいられたら、またちょっと違った未来があったのかもしれないですね。
私が面接をする時に聞いていること
面接で聞く内容・聞きたい内容ってその人の経歴次第なところもあるので、人によって聞いたり聞かなかったりしますが、こんなことを聞いたりしています。 質問一つとっても面接って正解がないと思うので、常に模索中です。 ※自分への備忘録的な意味もあり記事にしました
会社を辞めようと思う時はどんな時、どんな場面ですか？
仕事を辞めるって大きな選択肢だと思うので、そんな大きな選択肢を選ぶ時ってどういう時なんだろうというのを知りたいからです。
なぜ今の会社を辞めようと思うのですか？
当たり前と言えば当たり前なんですが、確認という意味もあり。
その中で気になること、例えばちょっと歯切れの悪い表現だったり、そういうのがあると掘り下げて聞いています。 深掘りすることで矛盾をつきたいとかボロを出させたいわけではなくて「何でそうなの」を聞きたいからです。
どんな組織ならフィットしますか？逆にフィットしないのはどんな組織ですか？
カルチャーフィットだったり、仕事の進め方のマッチ具合という観点で聞いてます。
現職年収と希望年収を教えてください
聞かないといけないことなので聞いているのですが、例えば現職年収に対して希望年収の差があると、その理由を聞いています。
例えば現職と希望に対して、大きな差（数十万円以上）があるとすると、なぜ年収がアップするのかの根拠を聞きます。 "いくら出すか"を判断するのは経営側ですが、人事として採用担当として聞くようにしています。
その根拠が何もなければ正直あんまり印象が良くないし、ちゃんと何らかの理由や根拠にがあれば、しっかり考えてるなと思います。
個人的なNGパターンだと・・・
- （その人の能力は置いといて）市場感覚としてxxx万円だから
- 今がxxx万円なので上がらなければ転職する意味がないから
個人的なOKパターンだと・・・
- 自分の経験と市場感を掛け合わせるとxxx万円が妥当なラインかなと思っています、それは自分の経験として〜があって、〜という理由で〜
- 前職はyyy万円で現職はxxx万円だった、（理由）があって下げたのでyyy万円に戻したい
- 〜のスキルに加えて独学で〜を身に付けた、〜も任せて欲しいのでxxx万円欲しい
これもボロを出させるとかではなくて、その年収の根拠を聞きたいという意図があります。 とはいえ実際に年収の根拠って、その会社が出せるかどうか・出すかどうか、というのが大きいというのが個人的な所感です。 会社によってはグレード・等級で年収幅が厳格に決まっていたり、グレード要件を満たしているかというのもあります。 しかし一番大事なのは、本人がどう考えているか・それを他人に説明できるかです。
現状維持か現状プラスアルファ程度という答えが返ってきた場合、それを自社のグレード・等級とその人の経験などに照らし合わせてみて、違和感がなければ突っ込んで話はしません。
どんな人が上司だったらやりやすいですか？
若手の方に聞いています、縁があって入社となった場合に上司となる人への情報共有にもなります。
人事・採用担当ということもあり、技術的な所については私はあまり突っ込んで聞かず、各部門の面接担当者に深いところは任せています。
転職は試験ではなく、マッチングの一種だと私は考えています。 なので、同じ会社に複数回応募して何度落ちたとしても、いつか合格する日が来るかもしれません。 逆にタイミングを逃すと入れなくなる会社もあるかもしれません。
最近ProgateでRubyを学んでる
色々な仕事の都合もあり、Rubyを学ぶ必要があってProgateで学習し始めました。 個人的にはプログラミング学習＝入門書を買って写経して、読んで写経して、動かないことに悩んでtypoを発見して…みたいな認識だったのですが、ちょっと縁があってProgateを始めました。
結論、自分に合ってたので即課金しました。
オンライン学習系って書籍に比べてボリュームが少ないんじゃないかとか、そんなイメージや偏見を勝手に持っていました。 しかし実際にやってみて、エッセンスだけ絞って書いてあって、コードをブラウザ上で入力して結果確認出来る、答えをdiffで見ながら確認出来る、不明点はワンクリックでヒントが出るなど、とてもとても便利でした。 こんなに楽ならもっと早めにやっておけば良かった…と思うぐらい、分かりやすくて衝撃的でした。 とはいえ書籍を否定するというわけではなくて、書籍の場合は書籍らしくボリューム感が厚めだったり、その分内容も濃かったりするんだろうなと思ってます。
自分の環境では仕事の都合でRubyという状況でしたが、Progateは約1千円/月の課金で制限なくコースを受講出来るのも良いですね。（他のオンライン系もそうだと思います） とはいえコンテンツの内容・幅にも限度はあるので、Progateで足りなくなった時には書籍を買うなりして知識の補強をしないとなと考えています。
書籍だと平均で2〜3千円/冊するので、コストパフォーマンスという観点では状況・環境にフィットすればかなりお得ですね。 Rubyでバリバリ開発するわけではないのだけど、知っておく必要があるという意味では、今の自分の状況・環境にはとてもマッチしていました。
今は平日でだいたい2時間ぐらい、土日だとずっとPCに向かってやってます。 サクサク進むので面白いし、とある成果物に対してステップバイステップで要素を学んでいくので、構築していってる感もあり面白いです。 久々にこういうちょっと手を動かして面白いなーと思うことに出会えたのも嬉しいし、仕事上でも必要なことなので一石二鳥です。 こういうサービスが20年前にあれば、自分も開発を避けずに開発エンジニアになれていたのかもしれない…と思う日々です。振り返っても仕方が無いね。
こういったことも、歳を取ると面倒になってしまって行動に移せない…ということが最近多々思い浮かぶので、とにかく勢い付けてやるしかないっすね、頑張ります。
「新しいことをやってみる」ということの大切さ
最近、意図的に「新しいことをやってみる」ということを頭で意識してやってみています。
実際そんなおおそれたことではないんですが、例えばこんなことです
- 普段買わないような商品を買ってみる（食べ物とか）
- 普段目にしているけど、行ったことがないお店に入ってみる
- 普段は見ないであろう映画・漫画に目を通してみる
- いつもと違う道を通ってみる
全部大したことないものなんですが、大したことないのに、実行に移すには結構コストがかかります。 コストというとちょっと大げさですが、今ここにあげたことを普段意識せずにやってみることが出来る人ってあんまりいないのかなって思っています。
特に30代後半になってくると、普段使っているものをついつい選びがちになってしまって、新しいことをしない傾向にあると自分では感じています。（実際に自分がそう） なので、意識しないと新しいことをしなくなってしまうし、意識しても新しいことをやるのって腰が重たいもんです。
いきなり全部やるのは難しいし気持ちも重たいので、軽いものからやるようにしています。
例えば、近所でよく見かけるけど入ったことがないスーパーに入ってみる。 思ったよりも安い場合もあれば、そうでもない場合もあるのですが、それって入ってみないと分からないことでもあります。 重い腰を上げて成果が出ない場合もあれば、やってみて成果が得られる場合もある、と置き換えられますよね。
自分の場合、だいたい5戦1勝4敗ぐらいで、そんな簡単に成果ってあがるもんじゃないなと思っています。 でも「安い店・良い店を見つける」が本当の成果ではなくて、普段と違うことをやってみるということが一番大事なのではと考えるようにしています。 新しいことをやってみることで、ちょっと刺激を受けて、たまに刺激＋ヒットがあって、小さな幸せを感じられます。
何でもかんでも仕事に結びつけるわけではないのですが、日常的な普段の行動から、ちょっと新しいことをやってみるという習慣をつけると、仕事をしている中でも「新しいことへの抵抗」が薄れるかなと思います。 そして「新しいことによる刺激」を受けることで、ちょっとずつちょっとずつ自分の意識や行動が変わっていっているのが面白いなーと感じる今日この頃です。
採用・スカウトを担当者として見ているポイント
こんにちは、11月よりSENSY株式会社というAIベンチャーへ転職しており、SENSYアドベントカレンダーの18日目を担当することになりました。
SENSY Advent Calenderはこちら
今何をやっているのか
SENSYでやっていることについてはコーポレートHPをご覧ください。
社内には神と呼ばれるBigQueryの使い手が多数在籍しており、先日もQiitaの記事でランクインしてました。 実際に私も数年ぶりに仕事でSQLを書いていて、BigQuery触るのは初めてだったり、SQLは基本ターミナルからしか叩いていなかったこともあり、とても便利な時代になったなぁと感動しています。
私が入社した立て付けとしては、情報システムが50%、プロジェクトに参加してのエンジニアリングが50%でした。
が、短い間に色々と紆余曲折あり、上記に加えて人事・総務・法務も任せてもらえることになりました。 大変ではあるし、忙しくもあるのですが、毎日楽しく仕事をしています。
その中でも今は特に人事の仕事に注力していることもあり、せっかくなので採用についてちょっと書いていきます。
スカウトをする際に見ているポイント
現在は主にビジネスサイドの方を対象として、Wantedlyでスカウト活動をしています。 媒体によって見るべきポイントは多少異なってきますが、今回はWantedlyに焦点を絞ります。
自己紹介
職歴をしっかり書くこと大事ですが、自己紹介も同じぐらい大事です。 スカウトするにしても、応募に対応するにしても、その人のヒトとナリをよく知りたいからです。 ベストは簡潔に書くことなのですが、それでもいくつかポイントがあります。
そのポイントはこれまでの経験で何をやってきたのか、どんなことが自分の強みなのか、などです。 簡潔に書くことで、読む側としても大枠が把握出来て、理解が進みます。 強みを書く理由としては、自社の欲しているポイントと強みが被っていれば、スカウトを送りやすく（受け取りやすく）なります。 イメージしやすいように、強みはできるだけ具体的に書くと良いでしょう。
このさきやってみたいこと
スカウトをするに当たって、ここも結構大事だなと思うようになりました。 企業によって変わると思いますが、私がスカウトする際はできるだけ「このさきやってみたいこと」がマッチする方に送っています。 例えば弊社はAIベンチャーなのですが、まったく異なる業界・領域をこの先やってみたいことに書かれていた場合、スカウトは控えることが多いです。 実際に話してみないと分からないというのは前提としてあるのですが、小さい組織でなかなか十分に手が回らないため、行動コストを抑えたいということと、頑張ってスカウトを書いても返事がもらえない可能性が高いからです。 逆に考えると、このさきやってみたいことと企業側のニーズがマッチしている場合、企業としては絶好のスカウト対象になります。
私がスカウトを始めて、意外とここを書いていない方も多かったりするので、ぜひ自分のキャリアを考えて、しっかり書いてみることをおすすめします。
本当に大事なこと
文章をしっかり書くこともそうなのですが、自己紹介、このさきやってみたいこと、職歴を振り返ってみて、改めて自分のキャリアの棚卸をすることが一番大事なことだと思います。 「ジョハリの窓」という考え方にもありますが、自分が気がついていない・強みと思っていない箇所が他人が見たら強みだということも多々あります。
もう暫くすると年末年始の休暇に入ります、せっかくなので今年一年やったことだけでなく、もう少し広げてこれまでのキャリアや今後やっていきたいことを改めて整理してみるのはいかがでしょうか？
マネージャーとして仕事をしている中で
両方とも読んでいて、なるほど、学びがあるなーと思った次第でした。 7月に入ってまだ2週間ですが、自分の今まで経験したことのない部門でのマネージメントをしています。 もちろん、これまでの経験を活かすこともできるけど、部門の仕事の大枠はやったことがない分野になります。
しんざきさんの記事を読み進めていく中で以下の記事について言及がありました。 これも読んだ時、まさにその通りだなーって思ったのと、自分もわりとそういう「ふわっとしたものを良い感じにする」ことをヨシとしてやってきたので、あるあると思いながら読んでました。 blog.tinect.jp
今やっている「マネージャー」の仕事って、現場で手を動かすことは出来ないし不要なんだけど、みんなの仕事を整理して会社の方針に向けて舵取りをしていく。 こういうことなのかなと思ってます、自分で手を動かすことができないので、尚更そっちの「マネージメント」が重要な仕事だと捉えています。
うちの会社の現場の人達も優秀なんだけど、優秀だからこそ他者との調整に時間を割くのはもったいないし、それで時間を使うなら手を動かす方に注力して欲しいなと。 他者との調整を雑用だとは思わないけど、色々な情報を鑑みて調整をしていかないといけないので、頭の中の使う箇所もちょっと違うと思っています。 そこでコンテキストスイッチを何回も発生させるとパフォーマンスも落ちるだろうと。
最近「経験のない部門でのマネージメントとは」みたいなことをずっと考えていたので、良い気づきになったなという今日この頃です。
マネージメント対象が5倍になった話
7月から異動があり、マネージメント対象が5倍になりました。5倍です。 5倍といっても1人が5人に変わっただけなのですが、1人の時と5人の時では動き方も大きく変わり、大変さと同時にやりやすさもあるなぁと思っている次第です。
1人の時のマネージメント
対象が1人の時というのは、自分と相手の関係性によって仕事がやりやすくもなり、やりづらくもなることがあるので、個人的には結構博打だと思っています。 相手がどんなに優秀であれ、自分がどんなに有能であれば、やはり相性があるからです。 有能な人は相性を通り越してスムーズに仕事はできるのかもしれないけど、やはり見えない所でダメージは蓄積されていってるのではないかなと。 ※お互い様ですね
マネージャー側のマネージメントスタイルによっても合う合わないがあるだろうし、上手くいくかそうでもないかというどちらかに寄りそうな気がします。
5人の時のマネージメント
まさに今の話なのですが、数の力が働いて良い感じにバランスが取れています。 マネージャーとメンバーの間にリーダーがいるというのも大きいです、これはマネージャーからメンバーに言えないことはあっても、マネージャーからリーダーに言えることがあるからです。 1人の時は言えないことも多く、任せられる範囲もせまかったのが正直ストレスポイントにもなっていたりしたのですが、5人の時には逆にそれがなくなりました。 しかしマネージメントの対象が増えたことによる、コミュニケーション量（1on1とか）が増えるので、そこは逆にタイムマネージメントも併せてしっかりやってかないといけないんだろうと思います。
人によって「マネージャー」の定義は異なると思うのですが、自分の場合は「リーダー含むメンバーの仕事を滞りなく進ませるために、障害を排除していく」役割だと考えています。 なので職位的に上だからえらいということはあまり考えていません、しかし役割的に出来ること・求められることが多いので、いわゆる立場の力を必要な時に行使することは大事だと思います。 ここで闇墜ちしちゃうと、権限ばかりを振りかざすマネージャーになってしまうのかなと。
そう考えると、マネージメントとは自分との戦いであるという側面もあるなと思った次第でした。
相手への気遣い
色んな会社を経験してきたのですが、ちゃんとしている会社（色々と語弊はあるけど）では「夜中にSlackのメンションを飛ばすの禁止」とやってました。 わりと当たり前のことだと思っていて、定時超えてメンション飛ばすってこと自体が自分的には普通のことじゃないので説明し辛い所もあるのですが、就業時間とそれ以外の時間を会社としてちゃんと分けているんだなと思っています。あえてそういうことを言う会社というのは。
昔は会社でチャットコミュニケーションがなかったこともあり、気にするかどうかは人それぞれな気がしますが、メンション飛ばされると通知が飛ぶのが普通だと思うので、それって相手に対する気遣いかなとも思います。 自分が定時を超えて仕事をしていても相手がどうかは分からないし、急ぎじゃないなら別に明日でもいいし、明日忘れそうなら自分で自分宛にリマインダーをセットすればいいだけの話だし。
自分が気にならないから相手も気にしないだろうというのは、コミュニケーションとしては危険側にたおした判断だなと思った今日この頃です。
人を動かす
読んでいてとても感銘を受けたので。 konifar-zatsu.hatenadiary.jp
4月からマネージャーに昇格したということもあり、最近は実務よりも部署間調整やマネージメントと考えられる仕事が増えています。 その中で最近特に感じるのが、抽象度の高い課題を取り組みつつ、足元の抽象度が低い課題にも取り組まないといけないということ。
プレイングマネージャーなのでそういう面もあるのですが、これって結構コンテキストスイッチが発生してむずいなと。 手元を見ながら大きく物事を考えないといけないので、ブレや漏れが発生したりして、いかんともしがたいのです。
こにふぁーさんの記事はいつも学びがあり、仕事に悩んだ時、人との関係性に悩んだ時に読むとヒントになることが多いのです。 読んでみて自分なりにどうだったかな、って考えやすいのもとても良いのです。
今後、自分が誰かに「納得感のある決定事項の伝え方」をしないといけない時、「腹落ちをさせる決定事項の伝え方」ってなんだろうと。 自分だったらこうするかなーというのを自分の中の整理も兼ねて書いてみます。
まず決定事項の前に背景を伝える
- 結論ファーストという言葉もありますが、結論が納得のいかなさそうなものだった場合、先に背景や事情を伝えるべきかなと考えています。なぜなら「結論が重すぎて」後の言葉が入ってこない可能性があるから。つまり背景を伝えることで、相手に結果を受け入れる心の準備をする時間を作ることになると思っています。
- これを怠ると「＊＊＊は考えなかったんですか？」とか言われるかもしれません、言われればまだ良い方で、自分では考えた結果却下したのに「検討していなかった」と思われる可能性があるからです。
私はあなたを信用していますよ・信頼していますよということを伝える
- 面と向かってそういうことを言う機会がないかもしれませんが、だからこそ言葉にするのは大事だなと思っています。信用・信頼が成り立っていないと話せないことばかりになってしまいます。
自分のことをオープンにする
- 場面や状況によりけりだとは思いますが、自分のことをオープンにすることも大事だと思っています。例えば自分自身も納得がいかないことを相手に伝えないといけない、そんな場合は一緒になって悔しがるとかではなく、丁寧に理性的に自分の気持ちや考えや思いをオープンに伝えることが大事だと思います。
他にも色々とありそうな気がするけど、こにふぁーさんの書いてることと被っているので割愛で。 一番大事なのは、それを頭で考えて、実行していくことですね。
そういうタイミングが来たら、相手に納得してもらえるように、ただし必要以上に迎合しないように気をつけていきたいと思います。
