下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

データ基盤を改善するアルバイトを募集中です

f:id:yuzutas0:20171218090720p:plain

データ基盤を改善するSREのアルバイトを募集中です。 春休みにひと稼ぎしたい・腕試しをしたい学生さんなど、お知り合いにいましたらぜひご紹介頂けると有難いです。

<仕事の魅力>

こちらのエントリーをご参照ください!

yuzutas0.hatenablog.com

<募集概要>

【想定対象】

データ基盤に興味のある学生エンジニア

【テーマ】

課題発見・解決型(SRE)

【仕事の流れ】

  1. データ基盤チームの抱えるシステム課題(Problemチケット)から挑戦したいものを1つ選ぶ(もしくは起案する)
  2. 関係者ヒアリングや技術調査を行い、改善案・設計の叩き台を作る
  3. ホワイトボードで設計ディスカッション → TODOを洗い出す
  4. TODOを捌いてProblemを解決する
  5. 成果をまとめて社内勉強会でプレゼンテーションする(可能であれば外部登壇などもご相談)

【技術環境】

  • 開発言語: Python, Node.js, Java, Ruby
  • インフラ: GCP, AWS, オンプレ
  • 作業用PC: Mac book Pro
  • 必要なもの・欲しいものがあれば要相談

【おすすめポイント】

  • 目的・制約を踏まえた最適なシステムの設計・構築を経験できます
  • 技術カンファレンス登壇者や起業経験者と同じ環境で仕事ができます
  • 主体性と実力さえあれば年齢や立場を問わずチャンスを掴むことのできる職場です

【日程・頻度】

  • 週2日〜5日、1日当たり4~7時間を想定
  • 2019年1月〜3月のうち2〜3ヶ月間を想定(希望・実績によっては延長の相談余地あり)

【報酬】

月10万円〜月60万円(交通費別)

  • スキルや稼働日数によります
  • 本人のコミットメントと推定される周囲からのサポートを加味して契約時に金額を判断します

【勤務地】

東京駅・京橋駅周辺(リモート業務については応相談)

【募集人数】

1人

【必要条件】

  • いずれかのプログラミング言語RDBMSLinuxサーバ環境を用いたソフトウェアの開発・運用経験
  • GitHub、CIツール、自動テストの活用経験
  • TCP/IP、HTTPなどのネットワークプロトコルについての基礎知識
  • システムの全体構成を把握し、技術的問題(例:パフォーマンス低下)の原因を発見、解決するための能力
  • システムのパフォーマンスや信頼性を向上させるのに必要なアプリケーション、ミドルウェアへの機能追加、バグ修正を行うためのプログラミング能力
  • ソースコードの保守性を維持するためのリファクタリング習慣
  • 要件定義から運用管理まで一連の工程に携わり、プロセス上のボトルネックに対して主体的に改善した経験
  • 公式ドキュメントの調査や、海外のエンジニアとGitHubやStack Overflowでやりとりできる英語力
  • チーム開発におけるコミュニケーション能力

※研究室、アルバイト、OSSコントリビュート等の活動での実績・経験を想定しています。

【歓迎条件】

  • Pythonと以下いずれかのプログラミング言語(Node.js、JavaRuby)を利用したソフトウェアの開発・運用経験
  • 非同期・分散処理を伴うシステムの開発・運用経験
  • Fluentd等のミドルウェアの導入・運用経験
  • DockerやKubernetes等のコンテナ技術の利用経験
  • さくらやAWSGCP等の各種クラウドサービスによるインフラ構築・運用経験
  • TensorFlow、Chainer、Caffe等を使用した機械学習システムの運用経験
  • CIツールやテストコードの導入・装着経験
  • 利用者ヒアリングや外部事例リサーチにもとづいたシステムの企画・導入・改修経験
  • 中長期システム保守計画の策定、サービスレベルの定義、キャパシティプランニングの策定経験
  • 過去に自分で作った技術的負債や障害原因を、自分自身で解消した経験
  • OSSの公開、コントリビュートの経験

【求める人物像】

  • 主体的に課題を発見して解決策を推進できる方
  • 自己学習やアウトプット、振り返りが習慣化している方
  • クロスファンクショナル志向で業務の幅を広げることを楽しめる方
  • システム利用者の意見を踏まえて、価値創出に対してコミットできる方
  • 暗黙知や属人化をシステムやドキュメントに反映しないと気が済まない方
  • (プログラミング関係なく)過去の人生で何らかの圧倒的成果を出した経験がある方
  • 技術カンファレンスで登壇できるような圧倒的な成果を出すつもりがある方

【応募方法】

紹介者経由でご連絡ください。直接の対応は致しかねます。

【紹介してくださる方へ】

やるからには最高の環境を提供したいので、ぜひ全面的な支援をお願いしたいと思っています。

  • (紹介者として)具体的な推薦理由を提示できる
  • (紹介者として)定期的な1on1を通したアフターフォローができる
  • (紹介者として)そのくらいエネルギーを注ぎたいと思える

これら全ての条件を満たせるようなマッチングができると最高です。 お手数をお掛けしますが、どうぞよろしくお願い致します。


なお、人材要件を整理するに当たってメルカリさんの採用ページを参考にさせていただきました。 この場を借りてお礼申し上げます。問題があれば取り下げますので、お手数ですがご指摘いただけると幸いです。

データ基盤エンジニアの面白さ

データ基盤エンジニアという仕事の魅力について、質問を受ける機会がありました。

何が魅力なのか。どういう面白さがあるのか。どこにモチベーションがあるのか。 せっかくなので自分なりに考えをまとめてみます。

5つの面白さ

ざっくりまとめると、データ基盤エンジニア(あるいは:分析基盤エンジニア・データエンジニア)というのは、「主体的に働きやすく」「スキルを(伸ばし/広げ)やすく」「キャリアアップに繋げやすい」仕事だと思います。

1. データ活用担当への第一歩として

データ分析や機械学習を仕事としてやりたい。だけど、職務経歴としてはアプリケーション開発やインフラに強みがある。 この立場の人がキャリアをピボットするための踊り場として、データ基盤の担当になることがあります。

持ち前のスキルを活かしてデータ基盤の構築・運用に関わるところから始めます。 データ仕様に詳しくなっていき、徐々に活用側へと染み出していくことで、キャリアの軸足を移します。

2. 技術的なチャレンジとして

趣味開発ではなかなか接する機会のない規模のデータを捌くことになります。 ISUCONでのパフォーマンスチューニングや、アドテク・動画配信の基盤担当者に近いモチベーションかもしれません。

「多少作りが悪くても動けば良し」というわけにはいきません。 それゆえか少数精鋭チームで技術力の高い人たちが集まっているように思います。

3. 幅広い業務知識を学ぶ機会として

扱うデータには様々なものがあり、事業ドメインと密着しています。

いわゆるWEBサービスのデータ基盤であれば、会計(売上)、マーケティング、ユーザー行動あたりのデータを扱うでしょう。 各業務領域の担当者と連携する機会もあるでしょう。

工夫次第でスキルや経験を広げやすく、将来的に潰しが効きやすいT字型人材となります。

4. 稼ぐネタとして

データ基盤人材の需要は供給を圧倒的に上回り、給料の良い職場に移りやすいだろうと推察されます。

露出機会のあるリーダー格人材ならヘッドハンティングを受けているはずです。 私もたまにお声掛けいただくことがあります。

米国では既にマネージャー職と匹敵する給与テーブル(年俸約1700万円)となっています。

IT業界で平均年収の高い職種はソフトウェアエンジニアリングマネージャ、データウェアハウスアーキテクト、ソフトウェア開発マネージャなど。米Glassdoor - Publickey https://www.publickey1.jp/blog/18/itglassdoor.html

5. オーナーシップを持つポジションとして

データ基盤の構築・運営では、一連のシステム群をいかにマネジメントするかが重要です。 目に見えやすい画面をベースにして会話できるものではなく、非エンジニアが中途半端に口出しする余地は少ないです。

ソフトウェアエンジニア自身がオーナーシップを持って計画・推進していくことが期待されます。 それゆえに透明性を担保して説明責任を果たせないとアウトですが。

(ビジネスモデルや組織文化によりますが)アプリケーション開発担当だと、ときには下請け構造や無理な納期コミットになりがちです。 基盤担当ならば正しいと思えるものを無理のないペースで作りやすい立場だと言えます。


データ基盤エンジニアの面白さをざっくりまとめるとこんな感じでした。

思っていること

最近はあっちこっちで「データ基盤エンジニアの採用を強化したいね」ということをよく話します。 アナリストや機械学習をやりたい人ばかりが増えても、なかなかビジネス価値に繋がりにくいからです。

ということで採用を強化したいのですが、他の分野と比べても明らかに人材不足です。 私が若手ITエンジニアに話を聞くと「そもそもデータ基盤に興味がない」「何が面白いのか分からない」といった意見が最も多かったです。

まぁそうだよなと思う反面、喰わず嫌いはもったいないなぁと思ったりもします。 この記事を通じてほんの少しでも興味を持ってもらえたら嬉しいです。

やるなら今だ!!!!!

【追記】

絶賛募集中です!!!!!

yuzutas0.hatenablog.com

寄稿しました:@IT「データ基盤」大解剖(全4回)

f:id:yuzutas0:20181016110318p:plain:w250

概要

ITmedia様の@IT(アットマーク・アイティ)に連載記事を寄稿しました。

記事一覧

殴り書きのメモ

振り返り(執筆)

  • 執筆ツールは最終的にGoogleDocsで落ち着いた。
    • レビュアーと共同編集が可能。
    • 最終成果物はWordに出力して受け渡しが可能。
  • 書き出して初めて気付くことがある。
    • 例えば、システム設計については大まかな意図だけを伝えるつもりだったが、実際に書いたら抽象的で分かりにくくなって方針転換した。
    • 当初想定の通りにはいかない。慣れないうちは「どんどん書いて、どんどん書き直す」スタンスが良さそう。
  • テキストで情報を伝えるのは難しい。
    • 図解を多用した。分かりやすくなる。
    • プレゼンスライドだと【おしゃれな画像+メッセージ】で鼓舞しているように見えても、同じ言葉を【テキスト単体】で書くと説教臭くなってしまったので大幅に修正した。

振り返り(進め方)

  • 執筆であっても仕事の勘所は同じ。
    • 例1:最初に全体の方向性を合意形成する。
    • 例2:早い段階で20点版を提示してフィードバックをもらう。
  • 色々な人にレビューを依頼した。
    • @int_ttさん、@akito0107さん、@shoitoさん、その他お世話になった皆様、ありがとうございました!
    • 自分よりスキルのある人にツッコミをもらうと勉強になる。
    • 複数人にレビューを受けたのは正解だった。
      • 「全員から指摘される箇所」と「一部の人に指摘される箇所」を区別できる。
      • ソフトウェアエンジニアにも派閥があるので、同じ言葉に対する受け取り方が人によって違う。
      • 普段そこまで一緒に仕事をしていない人のほうが、先入観がないので客観的にコメントできる。

振り返り(コンテンツ)

  • 記事の位置付けは「ケーススタディ」に振り切った。
    • 「データ活用」というテーマについて「ハンズオン」「用語の解説」は世の中に山ほどあるが「ケーススタディ」がまだまだ不足していると考えた。
    • MBAで経営を学ぶ時と同じように、テクノロジー活用に関しても豊富なケーススタディを参照することで、バズワードに振り回されない意思決定ができるようになると良いのではないか。
  • 伝えたいことの1割も書けなかった(悪い意味ではない)。
    • むりやり詰め込むと伝わらない文章になってしまう。筆者と読者には情報の非対称性がある。
    • 例えば「データ基盤においても進化的アーキテクチャを踏まえて設計しましょう」という旨の長文があったが丸々カットした。
      • というのも、どうしても解説事項が多すぎて、記事全体の趣旨が変わってしまうから。
    • ポジティブにカットして「今回の連載とは別のネタが見つかった!」くらいの心持ちが望ましい。
      • 「進化的データ基盤アーキテクチャ」(?)という別のテーマに切り出して考える。
      • 記事もデータ基盤システムと同じ。疎結合にして責務を分ける。
      • 記事の「数」を脳内KPIにしている人は、自然と分割する発想になるだろうなと思った。
      • ブログを書いて、反響を勝ち取って、その実績をもとに企画を持ち込んでやるぜ!くらいのモチベーションだと最高。

おまけ

【永久保存版】明日から朝型に切り替えるためのベストプラクティス

生活リズムを朝型に切り替えるために、数多の試行錯誤を経て、私が辿り着いたベストプラクティスである。 この手順の通りにやれば明日から朝型に切り替えることができるだろう。

注意事項

  • 睡眠薬は使わない。精神的なものが原因の場合はこの手法は通用しない。
  • 早起きに切り替える日は寝不足になるので、自動車運転などの安全性・正確性が求められる行為はしない。

意識しておきたいこと

なぜ朝型に変えたいか

人生を豊かにするためだ。 早起きすると時間に余裕が生まれる。 時間に余裕があると心に余裕が生まれる。 心に余裕があると人生に余裕が生まれる。

例1: 朝10時に打ち合わせがあるとしよう。1

  • 朝8時に目覚めたら残り2時間。身支度と移動で時間を使い切ってしまう。
  • 朝6時に目覚めたら残り4時間。事前に資料に目を通したり、気掛かりな別件を片付けることもできる。

例2: 朝の30分で自己投資ができる。

  • 研究者なら論文を執筆する時間にできる。アクセプトが多い研究者は執筆量自体が多く、定期的な作業時間を設けることが鍵だ、という主張もある。
  • 新しいスキルを身につける時間にできる。工夫によっては20時間でそれなりのアウトプットを出せるようになる。毎日30分なら1.5ヶ月で成果が出る。

なぜ他の時間帯ではなく朝に自己投資をするのか。答えは簡単だ。 「後で今日の分をやらなければ」と焦りながら1日を過ごすのではなく、「既に今日の分はやり終えた」という充実感を伴って1日を過ごせるようになるからだ。 前向きな気持ちで過ごせるようになるからだ。

何が早起きを阻害するのか

寝坊は繰り返す。 遅く起きるとその日はなかなか夜に寝付けない。 そして結局翌朝も遅く起きることになる。

体内時計の仕組みとして必然的にそうなる。 起床して目に強い光を取り入れたタイミングから一定時間後に睡眠誘発物質が分泌されるためだ。

朝型に切り替えるためのキードライバー

何が何でも1度早起きをする。 身も蓋もない話だが、これが全てである。 個人的な経験則だが、眠くないときに眠るよりも、多少の睡眠不足でも頑張って起きるほうが実現性は高い。

体内時計がリセットされるのは、起床して目に強い光を取り入れたタイミングだ。 そのため朝の早い時間に光を浴びることがキードライバーとなる。

寝坊を繰り返すのと同様に早起きもまた循環する。 早く起きると、その分だけ夜早い時間に眠くなる。 早く眠って、そしてまた翌朝早く起きる。この繰り返しになる。

これは朗報だ。 遅い時間に入眠して、無理やり早起きした日は寝不足状態となる。非常に辛い1日になる。 しかし、その1日を乗り越えれば、自然と早起きサイクルに切り替えることができるのだ。

# 手順リスト(前日編)

NOT-TO-DO: 前日にやらないこと

  • 昼寝・仮眠。
    • 理由:夜に寝付けなくなるためだ。
  • 酒の大量摂取。
    • 理由:個人差はあるが私の場合は頭が痛くなって夜に寝付けなくなる。

TO-DO: 前日(昼)にやること

  • [ ] ペットボトルの水を買う。
    • 理由:起きてすぐに水を飲めるように枕元に置くためだ。
  • [ ] しっかりと食事を摂取する。
    • 理由:お腹が空いて夜に眠れないという事態を防ぐためだ。
  • [ ] 有酸素運動。ランニング、サイクリング、水泳あたりが良いだろう。できれば1時間は運動を続けたい。
    • 理由1:体を疲れさせるためだ。
      • もともとが運動不足なら、これだけで寝つきが良くなるだろう。早く寝れば早く起きやすくなる。
    • 理由2:発汗しやすい身体にするためだ。
      • 体内温度を下げることで人体は眠りにつく。発汗による体温低下を昼間のうちに身体に練習させておく。入眠しやすくなる。
      • 目がさめたときに汗で身体がベトベトして気持ち悪くなるので、翌朝すぐに布団を出てシャワーを浴びたくなる。布団から出やすい状況を作る。
    • 理由3:血流の巡りを良くする。
      • 起床後に体温を上がりやすくする。寒いと布団に包まりたくなるが、暑いと布団から外に出たくなる。布団から出やすい状況を作る。
      • 頭に血が巡ると目覚めやすくなる。熱いシャワーを浴びると目が覚めるのと同じ。布団から出やすい状況を作る。
    • 理由4:頭や心ではなく身体で動けるようにするためだ。
      • 1時間も運動していると、後半は無心でひたすら動き続けることになる。翌朝は寝不足状態のため、頭で考える余裕はない。無心で淡々と作業を進めることになる。ゆえに無心で淡々と動くことに慣れておく必要がある。

TO-DO: 前日(夜)にやること

  • [ ] アラームをセットする。できれば専用アプリを使う。iOSのオススメは「Sleep Meister」というアプリだ。眠りが浅くなったタイミングで大音量のアラームを流してくれる。
  • [ ] 窓の外から太陽光がちょうど目に当たるように布団(ベット)・枕・カーテンの位置を調整する。
    • 理由:目覚めるためには外の光が必要不可欠だ。太陽光は100,000ルクス、曇りや雨でも5,000〜10,000ルクスとなる。室内照明はたったの500〜1,000ルクスなので、圧倒的に光の強さが違う。眩しくて自然に起きる、という状況を予め作っておこう。
  • [ ] エアコンで適温にしておく。起床予定の30分前にエアコンを切るようにタイマーをセットする。
    • 理由1:適温にすることで、暑くて(もしくは寒くて)眠れないという状況を避ける。入眠しやすくなる。
    • 理由2:起床30分前にエアコンが切れることで、夏場は暑く、冬場は寒くなる。30分もあれば暑すぎて(もしくは寒すぎて)強制的に目がさめる。
  • [ ] ペットボトルの水を枕元に置いておく。
    • 理由:朝起きたらすぐに飲めるようにしておく。水を1杯飲むだけでも頭に血が巡って目が覚めやすくなる。
  • [ ] 風邪薬や漢方薬を服用する。オススメは葛根湯。
    • 理由:睡眠不足、エアコン付けっ放し、そして温度の急変化など、体調を崩しやすい要素が揃っているので、先に薬を飲んでおく。プラシーボ効果でも十分だ。
  • [ ] 翌日の荷造りをする。
    • 理由:せっかく早起きしても家でじっとしていたら二度寝したくなってしまう。翌日は丸1日を外で過ごすのが望ましい。翌朝は寝不足状態なので、荷造りのような知的作業は困難だ。事前に用意しておこう。翌日はカフェでスマホをいじるくらいしかできないので充電器は持っておきたい。着る服も前日のうちに整えておこう。

手順リスト(当日編)

NOT-TO-DO: 当日にやらないこと

  • 二度寝。これだけは絶対にダメ。絶望への片道切符。きちんと起きて外に出ないと、体内時計をリセットできない。
  • 過剰な昼寝。横になって眠ってはいけない。30分以上眠ってもいけない。寝入ってしまい、夜に寝付けななくなる。それでは早起きサイクルに切り替わらない。

TO-DO: 当日(朝)にやること

  • [ ] 布団から出る。
    • 耳:前日の準備が完璧ならば、眠りが浅いタイミングでアラートが鳴り響く。
    • 目:前日の準備が完璧ならば、太陽光で目が覚める。僅かな理性で目を大きく開き、光を取り込もう。体内時計をリセットするように身体に指示しよう。
    • 肌:前日の準備が完璧ならば、部屋の暑さ(あるいは寒さ)と発汗で、身体中が気持ち悪くなる。本能が命じるままに布団から出よう。
    • 口:前日の準備が完璧ならば、発汗で喉はカラカラのはず。目の前にはペットボトルの水。本能が命じるままに水を飲もう。頭に血が巡って目が覚めるだろう。
  • [ ] シャワーを浴びる。
    • 発汗で身体はベトベトのはずだ。本能が命じるままにシャワーを浴びよう。
    • 少し熱くなるように温度を調整しよう。頭に血が巡るのが分かるはずだ。
  • [ ] 布団を畳む
    • 前日の有酸素運動と、浴びたばかりの熱いシャワーで、シャワーから出たあとも身体はすぐに汗をかくはずだ。そんな状態では布団にもう戻れない。仮に布団に入っても暑すぎてすぐに出たくなるだろう。汗が引いたときに二度寝しないように布団を畳もう。
  • [ ] 家から出る。
    • 前日の準備が完璧ならば、着る服や持っていく荷物は揃っている。無心で身支度を行って、さっさと外に出よう。
    • 外に出たら目を大きく開けて光を取り込み、家から離れよう。
      • 室内と室外で太陽の光の強さは約40倍ほど違う。外に出て光を浴びることで体内時計を完全に朝型に切り替えることができる。
      • 家にいると二度寝や昼寝を許しがち。家に帰るのは夜だ。それまではオフィスやカフェで時間を潰そう。

TO-DO: 当日(昼・夜)にやること

  • [ ] 昼を乗り越える。
    • 高度な知的作業はできないだろう。かといって寝不足で身体を動かすのは危険だ。カフェでスマホをダラダラと眺めるくらいしかできないだろう。あるいは漫画喫茶でコミックを一気読みするとかね。たまにはそんな日があっても良いじゃないか。
    • 何度か耐えがたい眠気に襲われるはずだ。そのときは10分だけタイマーをつけて、机に伏す形で仮眠を取ろう。それだけでも睡眠誘発物質の分泌は抑制できる。
  • [ ] 22:00まで粘ってから帰宅する。
    • 帰宅したら、きっと睡魔には勝てない。つい布団に横になってしまうだろう。帰宅時間を通して入眠時間を調整するのだ。22:00以降に眠るように調整しよう。22:00以降に入眠することで、次の起床が日の出に近付い時間となるように調整できる。2
    • 夜に帰宅したら、あとは本能が命じるままに眠りにつこう。翌朝きっと早く起きられるはずだ。

おわりに

生活リズムの運用・保守

早起きサイクルに1度切り替えたからといって、仕事や趣味で徹夜が続けば、また生活リズムは狂ってしまう。 戦いは果てしなく続くのだ。

  • 事前予防策:なるべく徹夜をしない。朝に出来ることは朝にやろう。計画を立てて行動しよう。
  • 事後対応策:同じように1日寝不足を覚悟して、早起きに切り替える。

胸に手を当てて自分の生活リズムを見直してほしい。 言い訳をしたくなる時もあるだろう。仕方のない時もあるだろう。夜型でいいやと思考停止したくもなるだろう。

だけどもし「朝型に切り替えられたらもっと上手くいくのに」と、心のどこかで少しでも思っているならぜひ挑戦し続けてほしい。 自分の弱さを認めた上で、失敗を繰り返した上で、それでも諦めずに生活を改善し続ける強さを持ってほしい。 日々の生活を改善するということは、きっと自分の人生を自分でコントロールするための第一歩なのだと思う。

参考文献


  1. まぁ私は午前に打ち合わせを入れないようにカレンダーでブロックしているのだが。WEB業界は出社が遅い風潮がある。だからこそ人が少ない午前は個人ワークが捗るし、誰かが寝坊してミーティングがグダグダになるような事態を避けることができる。「午前の打ち合わせNG」ルールは長いこと運用を続けているが、自分でも驚くほど上手く回っていると思う。

  2. レム睡眠・ノンレム睡眠は1.5時間周期のため、入眠から起床まで6時間〜7.5時間が望ましい。22:00になる前に眠ってしまったら夜中の3時台に目覚めることになる。この時間に起きてしまうと次の入眠がさらに早まって「どんどん起きる時間が早くなる悪循環」に陥る。かといって二度寝をすると、寝すぎで翌日の日中は頭が動かず、夜になって目が冴えてしまって、結局眠れないサイクルに戻ってしまう。だからこそ22:00以降の入眠を目標にするのが望ましい。

『転職の思考法』を読んでキャリア棚卸しシートを作りました

概要

『転職の思考法』を読みました。

  • この記事のターゲット
    • 転職に関心がある人
    • 将来のキャリアについて悩んでいる人
    • 今の環境のままではダメだと思っている人
  • この記事で伝えたいこと
    • 『転職の思考法』はオススメです
    • 「キャリア棚卸しシート」を作って公開したので良かったら使ってね

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

もくじ

どのような書籍か

本書は小説形式を採用しており、主人公の転職に伴走する形で話が進みます。

転職の過程で

  • どのようなシチュエーションがあるのか
  • どのような心境の変化があるのか
  • どのようなミスをしがちなのか
  • どのような考え方(思考法)が必要になるのか

これらの解説がなされていきます。

転職に興味がある方、いまの環境に漠然とした不安がある方は、ぜひ一度手に取ってみてはいかがでしょうか。 エピソードが分かりやすくて読みやすいですし、気付かなかった視点を得ることができるはずです。

読んだきっかけ

上司との1on1で今後のキャリアについて相談したところ「これ読みやすいぞ!ロジックが明瞭だからお前に合うと思う!」と勧められました。 本人のためになると思ったら、転職の本であっても部下に勧められるような、こんな上司に自分もなりたいなと思いました。

ざっくり内容

転職活動とはマーケットに自分を売り込む行為です。 自分という商品をいかに高く売り込むか、様々な角度から考えることになります。

  • 経済全体でどの分野が伸びているのか(これから伸びていくのか)。
  • どのような人材がいくらで求められているのか(これから求められるのか)。
  • 自分のスキルや経験をどういう人がどういう理由で欲しがるのか。

本書を読むと、実際に転職する・しないは別として「いつでも転職できるようにキャリアデザインを描くこと」が重要だと認識できるようになります。 その結果として今よりも前向きに働けるようになるはずです。

ざっくり感想

私の観測範囲ですと、特にソシャゲ会社にいた方々の中には、このあたり上手く計算して転職しているなぁという方がいますね。 反対に、いわゆる外コンに新卒入社した方でも、転職先の経営企画部門が雑務だらけで「こんなはずではなかった」という声を聞くこともあります。

そうした話を聞いていると、転職活動中(入社前)に会社の実態を予想するのはなかなか難しそうだなぁと、漠然とした不安がありました。 しかし、本書を読んだことで、ある程度のリスクはコントロールできそうだと思えるようになりました。

キャリア棚卸しシート

せっかく読んだからには何かしらアクションに繋げたいということで、本書の論点をスプレッドシートに書き出しました。 本書は「エピソード形式による分かりやすさ」が魅力である反面、「何から始めたら良いの?」という点は読者の力量に委ねられているように思います。 シートに書き出し、自分のキャリアを棚卸しすることで、書籍を行動に繋げることができるはずです。

自分の状況をシートに書き出した

f:id:yuzutas0:20180907104637p:plain

↑こんな感じです。イメージ。

......すると......

著者からリプライが来ました

......ということで......

シートを公開しました

f:id:yuzutas0:20180907104652p:plain

↑こんな感じです。イメージ。

ぜひご自由にご利用ください。 以下のリンクから開いていただけると、シートのダウンロードやコピーが容易に行えます。 https://t.co/kD0cSy4G6S

個人的に響いたところのメモ

最後にざっくりメモです。 読んでいて「なるほど」と思ったのは以下の4つ。

1. マーケットの伸びについて

競合を含めて全体が伸びている市場に乗っかるべし、という話が書かれています。 これは転職先企業のドメイン分野という意味でも、スキルという意味でも、セルフブランドという意味でも重要だと感じました。

例えば

  • ドメイン分野:一昔前のソーシャルゲーム。最近だとオンラインデーティング。
  • スキル:一昔前ならモバイルアプリ開発。最近だとデータサイエンスや機械学習
  • セルフブランド:一時期大量に現れたDeepLearning芸人たちは上手かった。扱う画像や芸風が微妙に1人1人異なっていて、個性を形作っていました。

私なんかは、ついついオリジナリティを追求しようとして、悪い意味でニッチな分野に逃げ込みがちです。 しかし下手に独自性を意識する必要はないのだと本書を読んで思いました。 上手い事例をマネしていれば、自分が持っている他の要素との掛け合わせで、結果的にオリジナリティが出るのかもしれません。 それが自分を売り込むときのキャッチコピーとなるのでしょう。

本当かどうか分かりませんが、クラウドワークスというサービスは創業者のアイデアではないそうです。 ベンチャーキャピタリスト(VC)の助言を元にした事業だという話を聞いたことがあります。 当時は「自分のアイデアでゼロからやらない起業家もいるのか」と不思議に思ったのです。 しかし今思うと、むしろVCのほうがマーケット嗅覚も優れているでしょうから、賢い進め方だなぁと思います。

2. 人的資産について

自分の市場価値を決める要素の1つが人的資産だと本書では述べています。 今の会社を辞めても仕事を指名してくれる人は何人いるか?と問いかけています。

バイネームで指名が来ないようでは話にならないと言われているようで、私にはグサッと来ました。 情報過多で何もかもが玉石混合の時代だからこそ、仕事は信頼できる人に縁故で頼みたいということもあるでしょう。 ふらっと遊びに行って、しれっと案件を取ってくるような動き方ができると最高ですね。

足掛けとしては、外部とコラボしやすい部署・仕事に就いたり、副業として週末フリーランスをやったり、コミュニティ運営の手伝いから始めるのが良さそうです。 とはいえ無理に人脈作りを目的にしてしまうと、なかなか長続きしないような気もします。 趣味を楽しむとか、スキルを向上させるとか、そういった取り組みとセットで結果的に資産が付いてくるような形が望ましいですね。

3. 経営層の中途採用比率について

「その企業に転職して本当に活躍できるのか」を判断するための基準の1つとして紹介されています。 経営層の中途採用比率が低ければ、中途入社しても活躍しにくい環境の可能性が高いからだそうです。

言われてみると確かにそういう会社はあるなぁと思いました。 入社してから「この会社は中途が活躍しにくい」と気付くのは辛すぎますね。

また、読んでいて思ったのですが、経営層に就任するまでの年数やキャリアパスも見た方が良さそうです。 サイバーエージェントのように20代若手が役員になるようなスピード感のある会社なのか。 あるいは、表向きはメガベンチャーと言いながら、10年以上勤務しないと社内の階段を上がれないような会社なのか。 はじめから経営枠で採用した人がポジションを占めるのか、現場で活躍した人が出世して新しいチャレンジに挑める環境なのか。

役職というのは1つの例に過ぎませんが、挑戦に対して前向きな会社とそうでない会社の差はこういったところにも出てくるのでしょう。 個人の市場価値を効率的に高めるという点においては、挑戦に前向きな会社のほうが魅力的と言えます。

4. 会社の強みについて

「その企業に転職して本当に活躍できるのか」を判断するための基準の1つとして紹介されています。 会社の強みと職種が一致するほうが自由に動きやすいからだそうです。

これはよくある話ですね。例えば、データサイエンティスト。 データサイエンティストとして入社しても、組織にデータを使う文化がなかったり、データ自体も使い物にならないと、成果を上げるのは大変です。 しかも商品設計やオペレーションなどのビジネス構造は、データ活用を前提としない形で最適化されています。 「君が1人目だ」「ぜひ会社を変えてほしい」と言われても、いざやろうとすると、そもそものビジネス構造を根本的に変えなければならなくなります。 今までそのやり方で何とか勝ってきたのに、急にやり方を変えろと言われても、経営層や現場からすると「いやちょっと待てや」という話になります。

似た例は枚挙に暇がありません。ソフトウェア製品のように見えるけど、実際は営業力がキードライバーということもあります。 デザイナーやエンジニアが画面UIを磨き込むよりも、営業が売るための商品を追加したほうが売上が伸びやすいです。 そうなるとインハンス開発チームはいわば社内下請け部門になりがちです。 そうした環境でこそ学べることもあるので一概に良し悪しは言えません。 しかし、個人の市場価値を高めるような成果を上げるのは時間が掛かりそうです。

よくある話なのですが、じゃあどうやって見極めるのか、というのが難しい。 本書では、見極め方として「商品設計」に加えて「経営陣の経歴」を見るように述べています。 目から鱗でした。言われてみればその通りだ。 ITに疎い営業出身のメンバーが立ち上げた会社は、ITに頼るよりも、自分たちの持っているツテや売り方を活かしてビジネスを発展させるはずです。 結果的にビジネス構造は、IT屋が入社しても活躍しにくいものになります。 そしてそのビジネス構造こそが会社独自の強みだったりするわけです。 そうだよなぁ。良いとか悪いとかじゃなくて、そうなるよなぁ。

おわりに

転職の思考法を身につけるということは、「自分がすぐにでも活躍できる場所を見つける力」であり、「高いオファーを出してでも自分の活躍に期待してくれる人たちと一緒に働く力」なのかもしれないと思いました。 その力を身につけるためにも、私自身、もっと外を向いていきたいと思いました。まずはポートフォリオサイトでも作るか。

ということで、少しでも心に響いた方がいらっしゃいましたら、お気軽に@yuzutas0までお声掛けください。 やっていきましょう。

めでたしめでたし。

デブサミ2018夏に登壇しました #devsumi #dataops

Developers Summit (通称デブサミ) 2018 Summer【C-1】にて登壇しました。 「いかにDataとOpsを繋げるか」というテーマで担当現場での取り組みや学びについてお伝えしました。

f:id:yuzutas0:20180807213925p:plain

ちなみにDataOpsというタイトルを採用した背景については、会社のメンバーズブログに寄稿したので、そちらも合わせてご参照ください。 機会があれば「なぜトップダウンではなくボトムアップ型・プル型のデータ組織が重要なのか」についてもどこかで解説したいものです。

Developers Summit で登壇してきました! - リクルートテクノロジーズ メンバーズブログ

08/23追記

もくじ

事業のグロースを支えるDataOpsの現場

セッション概要

データの民主化、データ基盤の構築、分析チームの立ち上げ、機械学習プロジェクト。世を見渡せばキラキラした事例に溢れています。 しかし、いざ自分たちでやろうとしてもなかなか上手くいきません。理想に辿り着くためには、泥臭い過程が存在します。

本セッションでは「登り方や道のりを知りたいんだ!」という方に向けて、DataOpsの観点から案件・システム・プロセス・文化・組織をエンジニアリングしてきた現場 のリアルをご紹介します。 データ活用に携わる全てのエンジニアが今すぐ行動するためのヒントを持ち帰っていただければ幸いです。

https://event.shoeisha.jp/devsumi/20180727/session/1764/

スライド

以下、エモい部分を抜粋。 具体的なエピソードはぜひスライドでご参照ください。

データ活用案件による価値創出

f:id:yuzutas0:20180807215533p:plain

f:id:yuzutas0:20180807215559p:plain

f:id:yuzutas0:20180807215627p:plain

f:id:yuzutas0:20180807215653p:plain

効率的なプロセス

データ抽出・集計業務

f:id:yuzutas0:20180807215724p:plain

機械学習システムの構築

f:id:yuzutas0:20180807215801p:plain

使われる基盤システム

f:id:yuzutas0:20180807215819p:plain

f:id:yuzutas0:20180807215918p:plain

安定したチーム運営

f:id:yuzutas0:20180807215936p:plain

f:id:yuzutas0:20180807220012p:plain

データの民主化(組織文化)

f:id:yuzutas0:20180807220035p:plain

f:id:yuzutas0:20180807220056p:plain

f:id:yuzutas0:20180807220115p:plain

f:id:yuzutas0:20180807220146p:plain

質疑応答セッション(一部抜粋&加工)

Q1. やるべきことが多すぎる問題について

Q1. コンサルタントとしてクライアント企業のデータ活用を支援する立場です。 データの収集から活用、さらには継続的な運用・改善と、やるべきことが多岐に渡りますが、これらを一手に引き受けるのは非常に大変だと感じています。 どのように工夫なされていますか。

A1. 1人が全てを担うのではなく、得意な人に得意な部分をお願いする、という形で案件を差配しています。 また、スライドにあるように「データの民主化」を重視しており、業務を担っている現場の部署が試行錯誤できるように支援しています。

Q2. データ基盤のサービスレベルについて

Q2. サービスレベルの設計や運用方法について詳しく教えてください。 サービスレベルというとレスポンスタイムや稼働率のことですか。

A2. データ基盤というサービスが、社内の利用者に対して約束する品質レベルが、データ基盤のサービスレベルとなります。 スライドにあるように「誰がどのようにデータを使っているか」というユースケース観点で期待事項を定義します。 夜間バッチがこけてデータの疎通が失敗したら、翌朝に出社した人がデータを見ることができないので、サービスレベル違反です。 データパイプライン上のどこかで問題が起きているはずなので、その不具合をシューティングしたり、リトライのような対応作業(ワークアラウンド)を実施します。

Q3. データ集めが大変という問題について

Q3. データ活用していこうということで、同じように部署を立ち上げて任された立場です。 いざ始めてみるとデータを集める部分で苦労しています。 オフラインが絡む業種ですので、紙で管理しているデータが多いです。 OCRで読み込むという話もあったのですが、そもそも該当の紙を集めるのが大変です。

A3. 各論としては、POSのようなシステムで管理するといった話になりそうですが、かなり大きな経営判断・業務改革になりそうですね。 スライドですとSRE(ログ収集のシステム構築)やオフショアリング(手入力業務を外部委託する)といったトピックと通じるものがありそうです。

本日の内容からお伝えできる部分があるとすれば「小さく試す」ということでしょうか。 全部のデータを最初から集めるのは大変ですが、目的に必要なデータをプルベースで取得することはできるはずです。 最初に集めようとしていたデータの2割だけで、目的の8割は達成できるかもしれません。 例えば、全国の結果は分からなくても「この地域のデータを集めてこういう予測ができるようになった」といった具合です。 より短いリードタイムで小さな成功体験(あるいは失敗体験)を積み重ねることで、強いデータ活用組織になっていくのではないかと私は考えています。

実況・ご意見

いわゆる「機械学習をやってみました」みたいなバズりやすいタイトル・内容ではないので、どこまで関心を持っていただけるかは不安でした。 蓋を開けてみると、第一線でご活躍されている方々を中心として、多くの反応をいただくことができました。 本当に伝わるべき人たちには伝わったのではないかと安心しています。

デブサミ2018夏「事業のグロースを支えるDataOpsの現場」へのフィードバック - Togetter

余談

デブサミ史上最多のスライド枚数になった、という認識でいます[要出典]。 狂気の枚数でクレイジー枠を受賞しようとしたのですが、上には上がいました。 おそらく今回のハイライトはとあるセッションで出てきたこちらの名言ですね。

なお、他の方々の登壇資料は以下のページにまとまっています。 Cookpad勢はしっかりしているなぁ、SILVER EGG勢はぶっ飛んでいるなぁという印象。

Developers Summit 2018 Summer、講演関連資料まとめ:CodeZine(コードジン)

登壇した感想

1つ目。自分にとって1つの節目となりました。 実は、3年前に同じ枠で当時の上司が登壇しており、今回の発表はそのオマージュとなっています。 また、4年前に(一方的に)お世話になった方に、同じ登壇者として控え室で挨拶することもできました。 偉大な先達たちに追いつけたとは口が裂けても言えないですが、1-2歩くらいは近付けたのではないか。 そう思えた会でした。いや、せいぜい0.5歩かな……。

2つ目。この事例はAさんが頑張っていたなぁとか、このノウハウはBさんに教えてもらったなぁとか、思い出しながら資料をまとめました。 結果としてSpecial Thanksが100人近くなってしまいました。 1人でも欠けていたら全然違う状況になっていたはずなので、間違いなくSpecialにThanksしています。 1人1人の活躍をありありと思い出すことができて、本当に多くの人たちの力を合わせてやってきたんだなぁと実感しました。 チャンスを与えてくださった人、手助けいただいた人、実際に業務を担っている人に対して、感謝の気持ちしかありません。

3つ目。他の発表を聞いたり、参加者と話をしてみて、改めてDataOpsの視点は必要だと思いました。 このタイミングでこのスライドを公開できたことは、社会的にも有意義なはずだと思いますし、自分がその担当者となれたことを誇りに思います。 今はまだ一部のアーリーアダプターにしか理解されない(そもそも興味を持っていただけない)内容です。 しかし、これから国内各社でデータ活用が進むと、多くの方々が似たような壁にぶつかるはずです。 その時に参考事例として何かお役に立てたら良いなぁと期待しています。

4つ目。この発表の直後に、期待値の高かったプロジェクトが1つ失敗してしまい、本当に難しいなぁと思いました。 まだまだ周囲から理解されない場面も多かったり、見立て通りに上手くいかないことだらけです。正直めちゃくちゃ逃げ出したいです。 一方で、逃げ出したいくらい難しい問題をいかにハックするか、いかに企てを画(えが)くか、もっと楽しんでいける自分でありたいとも思っています。

最後に

関係者の皆さま、参加者の皆さま、運営者の皆さま。 素敵な機会を与えていただき、誠にありがとうございました。

f:id:yuzutas0:20180807213839p:plain

螺旋を制御する

ポエム第五弾。

どっちつかずの中庸ではなく、極端と極端を行き来させることでバランスを取りましょうという話。

例:「機能軸組織」と「事業軸組織」

例えば。組織運営で「機能軸組織」と「事業軸組織」のどちらにするのかという議論があります。 機能軸組織とはデザイン組織、データ組織、QA組織のようなものです。事業軸組織とはXXXプロダクトチームのようなものです。

マトリクス型組織というのもありますが、メンバーを指導・評価する上司が事業軸もしくは機能軸の片方に寄らざるを得なかったり、360度評価で時間を掛けて丁寧にやっていたりするので、口で言うほど簡単な運用ではありません。 どちらかに軸足を置きつつ、留学制度や社内勉強会でもう片方の弱みを補うような制度設計で工夫しているのが実状でしょう。

では事業軸と機能軸のどちらが良いのでしょうか。 それはビジネスや組織のフェーズ、あるいは市場環境によります。

あるフェーズでは機能軸組織に該当分野のプロフェッショナルを集約することで該当分野の知見を貯めて品質を高めます。 しかし、ずっと機能軸組織だと、事業コミットへの力学が働きにくくなり、価値の創出やニーズへの柔軟な対応ができていないと感じる場面が出てきます。

あるフェーズでは事業軸組織に多様な分野のプロフェッショナルを集結することで事業ニーズに柔軟に対応します。 しかし、ずっと事業軸組織だと、複数の部署で同じようなことをやって、品質・速度・コスト面で無駄を感じる場面が出てきます。

つまり、2つを交互に入れ替えながら、徐々に組織を成長させていくことになるのです。 そこではコンテキストのリセットと再発見が螺旋のように繰り返されるのです。

例:「中央集権」と「現場判断」

例えば。社内標準システムを中央集権的に作るのか、それとも現場判断で作るのか。 現場と言っても人数が増えてきたら、今度はチームごとにツールを分けるのかどうなのか。 ドキュメント管理をそれまで使っていたConfluenceで全て管理するのか、チームによってはScrapboxやGoogleDocsを使うようにするのか。

統一したら使いにくいと言い出す者が現れて分散する。 分散したら混乱を招くと言い出す者が現れて統一する。 ひたすらこの繰り返しです。 徐々に適応したものが生き残ることで、進化していくのです。

ソースコードを共通化するのか分けるのかと同じです。 その都度リファクタリングしながら分離・結合を繰り返してシステム設計を進化させていくのです。

通化の問題については、ある程度までは共通化して、ある程度からは自由にすることになるでしょう。 国が定める国法もあれば、地方公共団体が定める条例もあります。 しかし問題は、その「ある程度」が時代と共に変わっていくということです。

だからこそ「監査」や「選挙」といった形で、定期的に見直しが行われるような破壊・再生のプログラムが設計されるわけです。 その一貫として、事態が共通化に寄れば断片化を求める声が生じ、事態が断片化によれば共通化を求める声が生じるのです。 自己進化可能なシステムが必要だということです。 ソフトウェア開発のツール選定についてであれば、レトロスペクティブのようなセレモニーで、そしてチームがスケールしたらScrum of Scrumsのような横断機会で、会話がなされるわけです。

揺れ動きをハックする

強力な原理・原則はアナロジーによって万物に適用できるものです。 子供の友情も同じです。喧嘩と和解を繰り返して相互理解を深めているのだと、解釈することができます。 バイオリズムも同じです。呼吸も、食事も、睡眠も、発汗も、筋肉痛も。 景気循環や潮の満ち引きや季節が巡るのも同じです。

循環があることで、停滞や腐敗に対して、刺激や新陳代謝になるわけです。 「振り子ではなく螺旋」(by 技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck)という言葉で表現されるように、その循環では少しずつ何かが変わっているはずです。

揺れ動かない組織は、レバレッジの効いていない組織であり、成長を諦めた組織だとも言えます。 組織とはエコシステムの一種であり、動態なのだと思います。

そこで求められるマネジメントとは、Chaosにする(刺激を与える)だけでもなく、Lawにする(秩序をもたらす)だけでもありません。 揺れ動きによって許容外の被害が出ないように制御したり、再びもう一方へ揺れ戻すときに対応できるようにすることもまた重要な役割です。 ルールを統一するけど逸脱したい人は逸脱できる余地を持たせるとか、自由にやれるけどその範囲は限って小さく始めるとか、そういった制御が必要になります。 組織の成長が螺旋であることを踏まえて、現状への静的な最適化ではなく、将来の動態を踏まえて最適化するようにメタ視点からマネジメントするのです。

螺旋を駆け上がる

先日、自分が頑張って整理した組織が、また混乱していくのを見て「なんだかなぁ」と思ってしまいました。 新規参画者の無邪気な提案を受け入れたくない、という気持ちになったのです。 しかし、これで良いのだと理解しました。自分が老害になりつつあることを自覚しました。 新しいフェーズに成長して、さらなる螺旋を駆け上ることを、喜ぶべきだったのです。

もしかしたら自分たちが当時上手くいかなかったことでも、時間が経過して状況が変わって、やってみたら上手くいくかもしれません。 やらせてみてダメだったら、口で説明するよりも早く同じ目線に立ってもらうことができて、むしろ協働しやすくなるかもしれません。 中途半端に時間を稼いだところで、いずれ変化は生じることになります。停滞や硬直化は、腐敗や相対的劣位を招き、変化を促す者が台頭します。 だったら、どんどんやりたいようにやって、良いものは取り入れて、ダメなものは切り戻して、組織自体についてABテストを高速に繰り返したほうが生産的です。 螺旋を駆け上り、時計の針を進めるのです。

もしかしたら抽象度をあげていくと、仏教の六道輪廻転成も同じことを指しているのかもしれません。 先日、奈良の寺院で和尚さんの話を聞いて思ったのですが、輪廻からの解脱とは「時の螺旋」に振り回されずにマネジメントすることなのではないかと。 物事の本質が変わらないのであれば、時代背景や姿形は違えど、論理の行き着く先が同じだったとしても不思議ではないですよね。川は流れていくものですから。 そう考えると、1000年前を生きた人たちの思考や言葉が、巡り巡って自分の考え方に影響を及ぼしたということになります。 同じように、自分のやったこと、たとえそのままの形では残らなかったとしても、螺旋の一部として、道しるべとして、何かが残り、行く末に影響を及ぼすのかもしれません。

なので、過ぎたことに執着せず、変化に対して柔軟に向き合い、同じことの繰り返しと思えるような事柄に対しても前向きに捉え、螺旋が上に登るように適切に制御していきましょう。

枕草子 (角川ソフィア文庫―ビギナーズ・クラシックス)

枕草子 (角川ソフィア文庫―ビギナーズ・クラシックス)