だらだらと思いついたこととか書くブログ

エンジニア的なネタとか備忘録とかを書いていく予定

嫌われる勇気の読書メモ

この本を読み始めた経緯

妻が持っていてオススメされていた本。

コロナ禍でテレワークが続く中で、当然ながらオンラインでチームのメンバーや関係者と仕事でのやり取りをする場面が増えていきました。

対面ではないやり取りをしていく際にあれこれ考えてしまったり、必要以上に発言について気にしてしまい、うまくいかないなと感じることが度々あったので、

何か改善のヒントが得られないかなと思い読んでみることにしました。

読んでみての全体的な感想

まずは本のサイズ感、厚すぎず薄すぎず、文字が大きめで読みやすいと感じました。

内容自体も青年と哲人の対話形式で話が進んでいくため、青年と自分を重ね合わせて読んでいくことで、

自分の中での考え方とアドラー心理学を元にした考え方との違いを教えてもらいながらアドバイスを受けているような感覚になり、とても理解しやすい構成になっているように思いました。

自分の経験と照らし合わせても、痛いところ突かれたなと思う箇所も多々あり、少し苦しみながら読んだ場面もあったように思います。

以下で気になった箇所や印象に残った箇所などについて書いていきます。

各章の感想と気になったキーワードなど

第1章 トラウマを否定せよ

アドラー心理学とはフロイトユングの心理学と違い目的論であるという説明から始まる章。

これまでの自分の考えとはまったく違う考え方、ここでガツンと頭を打たれたような感覚があった。

気になった箇所、キーワード

  • 変われないのは「変わりたくない」という目的のために自分で原因を作っている
  • 大切なのは「何が与えられているのか」ではなく「与えられたものをどう使うか」
  • いまの自分を"受け入れる"こと。「もしも〜だったら」という可能性の中に生きている間は変われない

第2章 すべての悩みは対人関係

全体的に気になったキーワードが多かった章だったので特に気になった箇所のみを抜粋。

対人関係が苦手な方で今まで原因論に基づいた考えで「どうすれば良いのか」を考え悩む事も多かったが、目的論を元にした考え方で自分なりに"勇気"を出してもっと変えていかないといけないんだと認識させられた章。

この章を読み、"答え"はきっと「自分の中にあるもの」なのだろうなと感じた。

気になった箇所、キーワード

  • 短所ばかりが目についてしまうのは"自分で自分を好きにならないでおこう"と決心してるから
    • これは「〜でなかったらこうであるはず」といったような可能性の中に生きることが出来るから
  • 今の自分を受け入れて、たとえ結果がどうであったとしても前に踏み出す勇気が必要
    • これを「勇気づけ」と呼ぶ

人生のタスクについて

人生のタスクとは下記の3つ。

一人の個人が社会的な存在として生きていこうとする時に直面せざるをえない対人関係のこと

  1. 仕事のタスク
  2. 交友のタスク
  3. 愛のタスク

第3章 他者の課題を切り捨てる

昔、仕事で先輩に「何にでも首を突っ込みすぎ」だとか「それは君のタスクではない」といったような指摘を良く受けていたことを思い出しながら読んだ章。

その時に注意を受けたことで変えられた部分もあるけれども、根っこではまだうまく自分のものに出来ていないんだろうなと改めて痛感させられた。

気になった箇所、キーワード

  • 他者の期待を満たす必要はない
  • 「これは誰の課題なのか」という視点から自分の課題と他者の課題とを分離する
  • 自分に出来るのは「自分の信じる最善の道を選ぶ」こと。自分がどうあるかを貫くことが「ほんとうの自由」につながる

第4章 世界の中心はどこにあるか

人の目を気にしすぎてしまうところがあるので「いかに自分が自己中心的であるのか」ということを認識させられたように感じた章。

他者への貢献をすること、そしてそれを自分で認めてあげることが「自分の幸せ」につながるという事なのかなと感じた。

ここの章の考え方は今の自分、特にオンラインでのやりとりが中心の今、とても大事にしていきたいと思った。

気になった箇所、キーワード

  • 他者からどう見られているかばかりを気にする生き方は"私"にしか関心を持たない自己中心的な生き方
  • 自らの主観によって「わたしは他者に貢献できている」と思えることで、自分には価値があると思える

第5章 いま、ここを真剣に生きる

もう一度読み返してみて"なるほど"と思えるような内容が散りばめられているなと感じた章。

1〜4の各章を自分の中に落としこんで実践できるようになってから読んでみると、また違う感じ方を出来るようになるのだろうなと感じさせられたまとめの章。

自分の弱いところ、出来ていないけど向き合っていかないといけないところが書かれているように感じた。

気になった箇所、キーワード

  • 自分に自信がないからこそ自意識過剰になる
  • 家事や育児、友人との交友や趣味などすべてに関心を寄せるべき
    • 人生の調和を欠いてはいけない
  • 人生とはダンスのようなもので「いま、ここ」が充実していればそれでよい。われわれは「いま、ここ」にしか生きられない
    • 趣味でダンスをやっていることもあり、本の中で一番、印象に残ったキーワード
    • ダンスでいうと見せるべき"いまここ"、"この瞬間"を精一杯、全力でやりきり生き抜いていくこと、の大切さというのがこの文から自分が感じたこと
  • 人生の意味は、自分が自分自身に与えるもの。困難に直面した時「これから何が出来るのか」を考えるべき

FTPのアクティブ/パッシブモードについて

目的

FTP接続のアクティブ/パッシブモードについてとデータ転送の関係などについて調べる必要が出てきて、色々と新たに知ることも多かったので備忘録を兼ねてまとめておく

FTPの接続モードと詳細

FTPについての基本情報

  • FTPは「コントロールコネクション」と「データコネクション」という2つのコネクションにより実現されている
    • コントロールコネクションは、ログイン認証やFTPコマンドの送受信を行うためのコネクション
    • データコネクションは、実際のデータを転送するためのコネクション。FTPコマンド毎にこのコネクションが作成される

アクティブモード

  • FTPサーバー側からFTPクライアントに接続する方式
  • デフォルトではコントロールコネクションにTCP/21番ポート、データコネクションにTCP/20番ポートを使用する

パッシブモード

  • デフォルトではコントロールコネクションにTCP/21番ポート、データコネクションには毎回ランダムで決まるポート番号Tを使用する
    • 通常はセキュリティ上、対象のポートレンジを指定してそのポートはファイヤウォールで許可しておくといった設定で利用される

アクティブ、パッシブ以外のモード

  • アクティブ、パッシブ以外に「EPSV(拡張パッシブモード?)」というものもあるらしい
    • EPSVは対になるEPRTとともにIPv6とNAT(Network Address Translation)に対応したコマンド
    • コントロールコネクションと同じ接続先に対してクライアント->サーバでデータコネクションの接続の確立も行う

参考

cos.linux-dvr.biz

www.binzume.net

  • telnetコマンドでFTP接続する場合に参照。それぞれのコネクションの使い分けなどの理解につながると思う

blog.naosan.jp

www.ibm.com

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略の読書メモ

及川卓也さん著のソフトウェア・ファーストを読んでみたので、その読書メモ

はじめに

IT業界、エンジニア業界で著名な及川さんが書かれた本ということで存在は知っていたので、本屋に立ち寄った際に目次をパラーっとみて見たところ、 「ソフトウェア・ファースト」とは何を指しているのか?また、「ソフトウェア・ファーストなキャリア」という見出しや章が気になったので購入し、読んでみました。

読書メモ

前半

ソフトウェア・ファーストとは

前半はソフトウェア・ファーストとは、から始まり、

ITやソフトウェアにおいての日本とそれを取り巻く世界の現状と課題、 そして、その課題に対して必要な変革について述べられていました。

以前の主流であったパッケージ型のソフトウェアではなく、 近年はSaaSなどによる産業のサービス化が主流となり、これまでとは開発の進め方やビジネス、サービスの考え方が大きく変わって来ている。

それに対応するためにIT活用やソフトウェアを核として課題解決をし、事業や開発を進めていく考え方がソフトウェア・ファーストとのこと。

日本が抱える課題とは

日本と欧米ではソフトウェアに対する考え方や関わり方があり、日本ではイノベーティブな開発が行いづらい側面がありそう。

日本は品質に対しての意識は高く、これまで製造業で培ってきたものがある。

「狩野モデル」を利用して、開発するソフトウェアやサービスに求められる品質を正しく定義することで、このような課題を解決していけるかもしれない。

あれば満足だが、無くても仕方ないと思われるような「魅力品質」がイノベーティブなプロダクト開発に繋がっていく。

今まではユーザーが欲しい物を作っていた時代だったが、今後はユーザーが欲しいものを見つけていく時代に移り変わってきているので、 時代の変化に合わせて考え方や開発の進め方なども変化や進化が必要。

後半

エンジニアのキャリアについて

後半はソフトウェア・ファーストな組織キャリア

キャリアパスについては前職や今の職場などでも同様のロールやポジションがあるため、個人的にはその定義の再確認といった部分が多かった。

ただ、近年よく聞くがイマイチ分かっていなかったエンジニアリングマネージャーのロールや、テックリードとの違いについてはこの本を通して何となく掴めた気がする。

しかし、結局は会社・組織毎に肩書とロールが異なってくる部分もあると思うので、あくまでも目安、参考情報として踏まえつつ、それぞれの文脈や組織によっての変換は引き続き必要なのだろうと思う。

及川さんのこれまでのキャリアについて

また、後半でとても興味深かったのは、及川さん自身のいままでのキャリアでのターニングポイントと、その時々に感じていたことなどがまとまっていた部分。

第一線で数々の経験をされてきた方の今までの変遷や足跡を辿ることで、 誰もがぶつかるであろう悩みや課題を同様に抱えていること、またそこに対してどのようなアプローチ、行動をしてきたのかということは今後の参考しつつ、今までの自分に足りなかったこと、今後必要なことの見直しにも繋げていければと思った。

全体を通して

まだまだ、うまく自分事に落とし込めていない部分などもあるので、時間を置いてまた読みつつ、自分が置かれている状況や今後の自分のキャリアやエンジニアとしての生き方について考えたいと思いました。

Kyash Meetup #7に参加してきました

Kyash Meetup #7

We are Kyash Direct 2019/11/14@Kyash

KyashさんのMeetupに参加させていただいたのでそのメモ。 最初にCTOの方からKyashやKyash Directについての説明があり、その後、各エンジニアのLTセッションがあって最後に懇親会という流れだった

LT 1 : Welcome to Kyash! by 椎野 孝弘さん

  • KyashDirectのエンジニアは4人
    • 全員サーバサイドエンジニアでフロントエンド専任はいないとのこと
  • ビジョンは価値移動のインフラを作る
    • お店や人々、そしてお金などの移動をスムーズに行うことでよりよい世の中にしていく?
  • これまでの主な歩み
    • 2015/01創業
    • サービスローンチから2年でVisaプリンシパルライセンスを取得
    • 2017/04にウォレットアプリKyashをローンチ
    • 2018から手数料2%でリアルカードの取り扱いを開始
    • Kyash directは2019/04から
  • Kyash Directとは?

    • KyashのAPIを開放して、自社ブランドカードの発行と決済を提供する法人向けサービス
    • 下記の機能を持っている
      1. カード発行
      2. チャージ
      3. 決済
      4. 送金(予定)
    • 現金や銀行口座などがファンディングソースだが、企業によっては仮想通貨や現金化に時間がかかるものに対応したりなどもしている
      • 例えば、用件によってはアフィリエイト報酬的なものなどをソースにすることも可能とのこと
  • Kyashの特徴

    1. イシュイング
      • Visaカード発行ライセンス、前払い式支払い手段を取得
    2. プロセッシング(決済処理)
    3. アプリケーション
  • Kyashの今後の展開

    • チャレンジャーバンクへ。給与受け取りや貯蓄など銀行の持っている機能を取り込んでいく
    • APIでプラットフォーム提供も。金融系のAWS的な存在のイメージ

LT 2 : 知識0からはじめる決済処理 by 松雪 俊さん

カード決済について

  • 請求的なことはクリアリング(売上確定)という ※その他カード決済に関わる用語、事業の概略について説明されていました

 アーキテクチャ

  • DDD(clean architcture) & MicroService
  • 各マイクロサービスはMessageBusで結合
  • sagaによる補償トランザクションで一貫性を確保

質問であがった内容

  • 静的型づけ(少数なども扱うため)で軽量なGoを選択
    • scalaと悩んだ。CTOは前職でscalaを経験

LT 3 : サーバーサイドエンジニア集団のためのElm by 鈴木 亮太さん

  • 管理画面について(Elm製)
    • Elmは静的型付け関数型のJS
  • アーキテクチャ
    • TEA(Model -render-> View -message-> Update ---> Model)
  • Elmのメリット -> 考えることが減る。サーバサイドエンジニアばかりのKyash向き(フロントエンジニアはいない)
  • Kyashでもtech lunchがあるらしい

LT 4 : 入門Certificate Transparency by 村上 孝則さん

  • SSl/TLSの中間者攻撃はむずかしい?
    • 証明書の誤発行も起きたりしている
  • CTとは
    • RFCで標準化されている仕様
    • CTに対応した認証局で証明書発行するとログサーバにログが記録される
      • 誤発行の検知が可能

質問で上がった内容

  • なぜ".co"なの?
    • kayash.comはすでにインドの会社に取得されていて使えなかったため

懇親会

  • サービス設計について

    • 法律や専門知識など関わってくるところもあるのでリーガルやエンジニアなどみんなでわっと集まって話したりしているのか?
      • そういうフェーズもある
        • 最初のフェーズではマネージャーなどが集まって決めている? ※ここよく分からなかった・・
      • 法律などはかなり専門的な知識が必要になるので、その辺りはもちろん気を払って対応している
  • インフラ

    • AWSを使っている。現状はKuberntesマネージドなどは使っていないとのこと
  • KyashDirectの開始でだいぶ収益も上がってきた
  • 歴の浅いメンバーも多い中で情報やドメイン知識などのナレッジ共有はどうやっている
    • 入社前の推薦図書があり、入社前にそこで最低限の知識はためておく
    • 人数も少なく風通しも良いため気軽に質問できる雰囲気がある
    • ドキュメントなどが整備されていないため、新規のメンバーなどがドキュメント化などのアウトプットをしつつ学んでいく
  • その他
    • 当日の参加者には入社予定の方やカジュアル面談を経て参加されている方もいた様子
    • 大半のエンジニアがここ1〜2年以内に入社されたメンバー

感想など

まずはオフィスが意外にもオープンな雰囲気があり、当初のイメージや金融周りの事業のイメージとだいぶ違った感じのオフィス、組織だなと感じた。 また、今回の登壇者の方々は全員、入社半年以内ということだったが事業やサービス、決済に関する知識をしっかり持たれていて、技術力だけではないエンジニアが揃っているのだなという印象を強く感じた。 それと同時に、メンバー皆Kyashのサービス愛もすごく感じて良い雰囲気の会社、チームだなというのも伝わってきました。 その影響もあってか懇親会もとてもフランクで話しやすい雰囲気でLT含めてとても良い時間を過ごさせていただくことができました。

LTのアーキテクチャの話が今回は一番興味がある話だったので、DDD+マイクロサービスを使っていることやSagaパターンを利用していることが知れた一方で、 モデリングや設計、運用についての話ももっと聞きたかったなというのが心残りでしたが、とても良い機会でした。ありがとうございました!

CODE COMPLTE 第1章 読書メモ

背景

ソフトウェア開発に携わるものとして読んでおくべき名著としてよく名前のあがるCODE COMPLETE。 上下巻揃えたものの、今ままでかいつまんで一部分読む程度で「ちゃんと読んだ」と言える状態になかったので、あと2ヶ月弱となった今年中に気になった箇所だけでも、しっかり読んでおこうと思い立ち、読み進めるとともに、後から見返したりできるようにちょっとしたメモがわりにこちらに書きました。

読書メモ

1.ソフトウェアコンストラクション

ソフトウェア開発の大部分を占める、開発の中心的なアクティビティのこと。どのプロジェクトでも必ず実行される唯一のアクティビティ。

コンストラクションのほとんどの部分はコーディングとデバッグだが、設計や計画、テストといったアクティビティも含まれる

コンストラクションは機械的なものでなく、創造力と判断力を必要とする

結果として、コンストラクションの方法をどれだけ理解しているかが、どれだけ優秀なプログラマであるかを決める。

2.ソフトウェア開発への理解を深めるメタファ

よく理解できないものをよく理解できるものと照らし合わせた結果、何かがひらめいて、解明できなかったテーマへの理解が深まることがある。メタファのこうした利用を「モデリング」と呼ぶ

メタファは、ソフトウェア開発プロセスを既知のアクティビティと関連づけることでその理解を促進する。

メタファをどれだけ理解できるかによって、ソフトウェア開発をどれだけ理解できるかが決まる

ソフトウェアメタファは「アルゴリズム」というよりも、「ヒューリスティクス(発見的)」という意味合いが強い。見つける方法を教えるだけで、何を見つけるのかは教えてくれない。 答えを見つけるために役立つテクニックの一つ。

ソフトウェアに関するメタファには様々なものがあるので、目的にあったメタファを組み合わせて利用すれば良い。

3.上流工程の必要性

プロジェクトの成功の行方は、コンストラクションが始まる前に大方決まってしまう。 コントラクションの前の下準備である、アーキテクチャ、設計、プロジェクト計画といった上流工程が大事。

準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである

準備を事前にどの程度まで完了しておくかについては、ソフトウェアの種類、プロジェクトの形式、技術的な環境、スタッフのスキル、プロジェクトの目標によって異なる。 大抵のプロジェクトは高い反復性を必要とするが、プロジェクトによっては逐次性を重視する場合もある

課題定義が十分でないと、コンストラクションの際に解決すべき課題ではなく、誤った課題を解決する羽目になる

要求の策定が十分でないと、課題の重要な特徴を見逃してしまう恐れがある。

アーキテクチャの設計が十分でないと、コンストラクションの際に解決すべき課題はあっていても、誤った方法で解決する羽目になる

プロジェクトにおいて、コンストラクションの準備がどのように行われたかを理解し、それに応じてコンストラクションのアプローチを選択する

4.コンストラクションの重要な決断

  1. プログラミング言語の選択
    • 使用する言語の長所と短所を把握しておく
  2. プログラミング規約を定める
    • 複雑なプログラムではアーキテクチャガイドラインがあると、プログラムが構造的にバランスのとれたものになる
    • コンストラクションのガイドラインがあると、各クラスが設計全体の信頼できるパーツとしてつなぎ合わされ、実装が調和のとれたものになる
    • プログラミングを成功させる鍵は、自由裁量によるばらつきをなくし、必要な箇所に思考を集中させること
  3. コンストラクションプラクティスの選択
    • 特定のプロジェクトに適さないものがあある
    • 適切なプラクティスを選択する
    • コンストラクションプラクティスの例
      • コーディング規約
      • マージ、ブランチ戦略
      • ペアプロやモブプロなどを導入するかどうか
      • テストコードの有無やレビュー体制
      • VCSを使うかどうか
      • 言語のバージョン、フレームワーク、Lint、CIなど
  4. テクノロジの波に乗って
    • テクノロジの波のどの位置に乗っているのかを把握する
    • どこにいるかによって、どういうアプローチが効果的なのか、もしくは可能なのかが決まる
    • テクノロジの波のどの位置に乗っているのかを見極め、それに応じて計画や予測を調整する

第1章の振り返り

ソフトウェアコンストラクションという、開発の大部分を占める作業についての定義や、それに関わる準備から実践までの作業の必要性、重要性について説いている部分で、 自分の感想や感覚としては、今までやってきたことや、ソフトウェア、サービス開発とはこういうものだというのが丁寧に整理され、言語化されていたのがこの章だと感じた。

アーキテクチャの部分については、自分は基本的にwebサービスしか携わってこなかったため他の分野ではこういうところに着眼するのかということが、ざっと見レベルだが垣間見れたように感じた。

1章の中では、自分は特に「メタファ」についての箇所はとても興味深かかったと感じた。 最近、思考法についてやDDDについての本を読むことが多く、どちらでも必要かつ重要な概念・スキルとして「抽象化」が取り上げられていたが、その抽象化を行う過程で必要となるのが「メタファ」であると考えている。

特に本書で、ソフトウェアのメタファについて、「ヒューリスティクス(発見的)」であるとされている点については、なるほどと思わされた。 今まで、何かしらの「答え」を探して「答え合わせ」をするようになってしまっていた部分が多く、 何かが違う、うまくいかない、と感じていた部分が、この言葉ではっきりしてきたように感じられた。

もちろん、ここが言語化されてクリアになったところですぐに何かが改善できるわけではないと思うが、今後はこの勘違いの沼に今後ハマらず開発を進めていくきっかけにはなりそうだと思う

今は次の2章を読んでいるところだが、ボリュームも多く内容もぎっしりなので、いつまとめられるか、そもそもまとめられるのかどうか不安・・

転職して1年が経過したので振り返り part2

現職に転職して約1年経過したのでその振り返りのPart2 Part1はこちら

2019年1〜10月

仕事面

年が明けて入社して3ヶ月くらい経ったので、少しずつ慣れきたりナレッジも増えてくる一方で、 思ったほど成長や成果を感じることがないなと思って焦り、序盤は朝いろいろ調べながら学んだり、なるべく数多くのタスクをこなそうとしていたように思う。 今振り返ると、自分に必要だったのはもっと1つ1つのことの集中して、その背後や周辺知識などをしっかり固めておくことだったように思うが、 当時は数や幅にこだわり中途半端な感じになってしまっていたように思う。

その後は結婚式の準備などでバタバタし、プライベート優先の期間があったため、そこで少しペース置いた後に、 また元のペースに戻して、今度は仕事の幅やレベルを中心に考えるようになったが、まだまだなんとかこなしている感が拭えず、調整ごともうまくいかないなど反省や後悔することも多い期間を過ごしていたように 今振り返ると感じる。 ただ、この期間の反省やここで焦った結果の行動が少しずつ、改善にはつながっているようにも思うので、もがいた期間もムダではなかったのかなと思っているし、そう願いたい。

また、仕事とはちょっと離れるが、9月には職場の同僚とISUCONというコンテストに出ることになり、7月くらいから同僚と集まって練習をしたりもした。 チーム外の人と集まって何かをやること自体も楽しかったし、ここを通じて得られたものも多く、結果は出せなかったがとても良い経験だったと思う。

仕事以外

生活面では3月に結婚式があったり、6月にはお休みをいただいて新婚旅行に行ったりで、その間にはダンスのイベントに出させてもらったりと上半期はとにかくイベント盛りだくさんで慌ただしかったが、 とても充実して楽しい時間を過ごさせてもらえたように思う。

結婚式に関しては、転職して間もないこともあり現職の人をほとんど誘えなかったことや、どなたに祝辞をお願いするかなどタイミングの問題などもあり非常にアタマを悩ませた。 ただ結果として、色々な方々のご協力、支援のおかげもあり、自分たちの希望に沿う形で対応していただくことが出来、おかげさまで思い出深い素敵な1日を過ごす事ができた。 助けたいただいた方々には本当に頭が上がらない思いです。

あと2月頃には目黒雅叙園で前撮りをした。式が洋装なこともあり、和装ですてきな庭園があるこちらでは、場所はもちろんスタッフの方々も素晴らしく素敵な写真をたくさん取っていただいた。 すでに人気のスポットだが、あらためてここはすごくオススメしたいスポットだった。

今後

まずは仕事面でもっとバリューを出していけるようにしたい。 そのためにはエンジニアとしての技術力はもちろん、調整ごとやファシリテート力に難がある今の状態をもっと改善していく必要があると感じる。 前職での最後の方から、課題感は感じつつも出口が見えなかった状態から少しずつ進むべき方向が見えてきたような状況までにはなれたように感じているので、 少しでも先に進みつつ早い段階でここをうまくコントロール出来るようにしたい。

また、仕事面、プライベート面ともに新しいことをやるという経験が少なくなっているので、今月から1つずつでも「何か挑戦すること」と、今年もとわずかなので、今年の間「継続して取り組んでいくこと」というのを掲げて、 実践を試みているので、あと2ヶ月強走りきりつつ、少しでも手応え・成果を感じられるように過ごしたい。 とりあえず新しい挑戦として、今月は初心者向けのフットサルイベントに参加して、初めての経験と盛大な筋肉痛を得てきたが、とても楽しかったので今後も自分のペースで参加したいと思う。 来月と年末に何するかまだ決められていないので、まずはそこをかんがえて見るところから

また「継続して取り組んでいくこと」については、このブログなどでアウトプットとして成果を出せればとは思いつつも、インプットばかりでうまく進められていないので、まずは重い腰を上げてみるところから頑張ってみようと思う。

おわり

転職して1年が経過したので振り返り

昨年の10/15に約10年間働いた前職を退職し、10/16より現職に転職した。 人生で初の転職を経て1年間経ったので振り返ってみる。 思ったより長くなりそうなのでまずはpart1。2018年の振り返りから

前職と現職について

前職も現職もwebサービスのエンジニアということで同様の職種での転職になる。 担当サービスは、前職ではメール・FAXといった低レイヤーなところから、法人予約サービス、口コミシステムや航空券予約システムなど色々担当したが、 基本的にはオンライン旅行予約システムの開発だった。 現職では動画配信サービスの契約、決済周りなどを担当することになり、今まで未経験の新しい部分を担当させてもらうことになった。

また、規模も前職では約200人弱で国籍も様々なところから、約80人くらいでチームメンバーは全員、日本人と大きく環境が変わった。

2018/10〜12月

仕事面

最初の1ヶ月は今まで色々と環境が違いすぎてとりあえず戸惑いながら1年を過ごした記憶 メンバーや関係者、タスクの進め方、会議や決め事などの進行の仕方など、あらゆることが新しい環境で変わったので、 もちろん変化の大小はあるけれども、社内のツールの使い方や担当サービスのことなど分からないことだらけだった。 幸いにもチームのメンバーが親切に色々教えてくれたので、そこから少しずつ情報をキャッチアップできたのは良かった。

1箇所にどうしても10年近くとどまっていて、かつ他の環境を知らないと、「今までの常識=世間での常識」みたいに思い込んでしまっていたところも多く、 そこでの戸惑いや最初になるべく早くバリューを出そうという焦りなどから、年内はいろいろと迷惑かけてしまったり、ちょっと変な方向に暴走してしまったことも少なくなかったように思い、ここは今でも反省しているポイントの一つ。

組織・環境について

出来ればチームのメンバー全員やその他の人何人かとランチに行きたいと思いつつ、チーム内の数人しか出来なかったのは、未だに残念でならない。 ただ、週1で10人弱くらいでやっている技術ランチにうまく潜り込めたおかげで、顔はわかるという人も増えたり、普段、業務で関わらない人と話をする機会を得られたのは良かったし、それが今にも続いているのはありがたいことだったので、ここは良かったポイントだと思っている。

前職に比べて仕事の面では、手続きやフローと言ったものがほとんどなく、組織も基本フラットなため、自分の業務に集中できる時間が増えた。 また、今までは運用などに取られる時間がかなり多かったが、そういったこともリセットされて今までにないくらい開発に集中させてもらえる部分については転職してよかったなと思えた。

仕事以外

生活面など仕事以外の部分では、11月に入籍をして、入籍前からちょっとだけ進めていた結婚式についてちゃんと考えることに。 結果としては、翌年の3月に式を行うことになったので、早速打ち合わせやら何やらの準備を始めることになった。 この時点では、それほどやることが多いわけではないが、初めて知ることがいっぱいあって情報量が多く、そこが消化しきれず結構バタついていた気がする。

その他にも家の方の用事があったり、結婚式の準備としてダンスのレッスンに2人で通うようにしたりで、休日はだいたい何かしらの用事が入っている、という状態だったかと思う。 あと、式にどれくらい、どんな人を呼ぶか?2次会とかはどうするか?あたりで結構、話した気がする。

年末

年末に向けて、以前からあるサービスの担当にちょっと関わらせてもらう機会をもらうことになり、 いわゆるレガシーシステムドメインナレッジなどから学んで、簡単な対応をしていくという機会もあり年末の仕事としてはそれでバタバタしていた。 ただ、今までさんざんレガシーシステムを経験してきた経験は少しばかり活かせたように思う一方、開発環境などでも思った以上にインフラ部分をサーバサイドエンジニアが触れなくてそのへんにはかなり戸惑ったし、そのあたりでもっと貢献したいと思っていただけに、そこについては残念だった。

そんなこんなで最初の3ヶ月を過ごしたが、 * ひたすら知識を入れつつ環境に少しでも早く慣れることが出来るように頑張った * 開発、特にコーディングに集中し今までとは良い意味で違う進め方が出来るようになってきた というのがこの間の所感でした

つづく