ウィルパワーを5ヶ月間マネジメントしてエンジニアとして超集中力を保った話

shutterstock_1055471537.jpg

※この記事は私の下記のqiitaからの移行記事です。

qiita.com

はじめに

PLAID Advent Calendar 2018 の第10日目は、7月からプレイドにjoinしているソフトウェアエンジニアで、武井壮アカウントをめざしている @tai-hey が担当します。

私はSIerから今年30歳で業界を越えた転職をしてきまして、スタートアップのスピード感と考え方に刺激的な毎日を送っています。

まず、この投稿内容にした動機について話します。 転職してきて、今までとは全く違った環境、業務を行っているため、即戦力でできる範囲は限られています。業務を経験する中でいち早く戦力化できるようになりたいので、少なくとも自身の集中力を最大限保っている状態でないと実現は難しいと考えたので一部書籍を参考にした箇所と、前職の段階から実践していることを合わせてエンジニアとしてのユースケースに落としてみました。

5ヶ月この書籍を実践して、ある程度実例として実績をつめたことと、エンジニアのユースケースとしてアジャストできたので、ここで一度整理するために advent calendar として投稿することにしました。

一部、参考にした書籍は こちら(自分を操る超集中力) です。

対象の読者

この投稿はアウトプットを出す際に集中力というフローを実践して、エンジニアのユースケースとして落とし込んだ実績を記載しています。 私は以前SEとしてビジネスサイドも経験しているため、集中力を保ちパフォーマンスを上げるという面では共通しているところがあるのかと思いますので、汎化させてビジネスサイドの例に当てはめてもいいかもしれません。

リスト

今回記載するtipsのリストは下記の通りです。他にもいろいろやっていますが、効果の高いと判断したものを抜粋しています。 見ていただき、自分にフィットしそうだなという習慣を取り入れていただければと思います。

  • ウィルパワーを使って集中する
  • ウィルパワーを余計なことで減らさない
  • ウィルパワーを回復する
    • 早寝早起き
    • 最低睡眠時間

ウィルパワーについて

先に本記事のメインの考え方となるウィルパワーについてお伝えします。ググってみるといろいろでてくるのですが、これは心理学者ロイ・バウマイスターという人が提唱した考え方らしく、一人一人が持ついろいろ生活する上で必要な意思の量(ドラクエでいうMPみたいなもの)だと思ってもらって良いと思います。

私が大事にしているポイントは - 起きた瞬間からこのウィルパワー(MPみたいなもの)を使い続ける。 - なるべく余計なことで減らさないようにする。 - 睡眠によって回復する。 となります。

最大容量は個人差によりますが、しっかり回復すれば一日消化しきることはなかった(一日しっかり集中できるようになった)ので、今回はブログの言及対象外にしたいと思います。

私が実践を通して生活習慣を改善していった結果、エンジニアのような知的生産型(アウトプットとしての生産性が大事な)職種は体力ももちろんですが、このメンタル的なウィルパワーが重要なことがわかりました。

体力はある程度体感としてわかるので把握しやすいですが、ウィルパワーについては知らず知らずに消耗しているケースが多いので、かなり生活習慣を見直せば効果的なケースが多いと思っています。

実践リスト

ウィルパワーを使って集中する

では、集中すること自体においてエンジニアのユースケースに効果のあったものを中心に紹介していきます。

  • ポモドーロテクニック ポモドーロテクニックググるとたくさんでてきます。30分(25分作業・5分休憩)サイクルで実施します。 プログラミングをするにあたってコードを書いたりしている際に、同じことでぐるぐるしてしまって先に進まないケースってありますよね。ポモドーロテクニックはタスクの進捗にかかわらず、時間で区切って休憩をいれるので、休憩の際に脳が勝手に整理してくれるみたいです。確かに休憩の間(私はこの間に水をくんだりトイレにいったりしています。)にあれ?そういえばあの方法はどうだろうか、誰々さんに確認したらどうだろうか、とコードの別解法やそもそもコード以外にも起こすべきアクションを思いつくことが多かったです。

  • あらゆる通知を切る スマホはかなり時間を奪ってしまうことはいろいろなところで言われていますが、特に友達からのLINE通知が来たり、その他アプリの通知が多かったり、集中力を遮って効率的にウィルパワーを使えなくなってしまいます。スマホはその場にあるだけで気になることが多いので、私はスマホはリュックにしまったり、視界から入らないようにしています。 似たような話で、slack通知やmac自体の通知があります。すべての通知をONにしておくと不要な通知が入って一瞬目線が右上に移ってしまい、集中力を遮ってしまいます。私はmacは基本おやすみモードにして通知を表示させないようにしています。 また、slackは不要なチャンネルはミュートにしています。緊急な場合は自分宛てにメンションがくるはずなので、slackチャンネルの右側にメンションがあれば赤い数字がでるので、ポモドーロテクニックの休憩の段階で確認します。これでだいぶ深く集中する(途中で現実に引き戻されない)ことが多くなりました。

  • 実施するハードルを下げる このノウハウは行動科学マネジメントというメソッドが一部絡んでいるのですが、人が物事を集中する時で、やる気が出ないときはとりあえず作業を始めてみると集中しだす、という原理があります。プログラミングを始めるときや、バグの調査などでなんとなくやる気が出ないときはプログラミングをやろう、バグの調査をしよう、と考えずに、とりあえずPCを開く、とりあえずissueを開くというように先をあまり考えずに行動だけ始めるといつの間にか本当にやるタスクをやっている、という状態に持っていけます。意識を強く使ってしまうとタスクのスタート時にウィルパワーを多く消費するので、私は腰が重いタスクだと感じる時はこれを意識して早く集中するようにしています。

ウィルパワーを余計なことで減らさない

ウィルパワーを気にして生活していく中で、ウィルパワーはなにか考えるたびに消費するので、業務以外で減らすのは個人的に許せなくなってきました。 その中で生活習慣を変えたものを紹介します。

  • 通勤電車 通勤電車はウィルパワーを全力で削ってきます。特に満員電車のストレスは戦闘機パイロットのストレス以上というのを聞いたことがあります。私の大事なウィルパワーを業務以外で削るわけにはいかないので、私は朝6時台の電車にのるか、それをすぎるようならピークを過ぎた8時後半の電車にのるように変更しました。乗り換えの際も早く急行に乗るよりも、一本遅らせて座れる電車を選ぶようになりました。これで大事なウィルパワーを温存します。

  • ミニマリズム 人は物があるとそれに意識を持っていかれる性質があるそうです。おそらくこれは物があるとそれを管理するコストや、ものを見ることでその情報を処理するコストを無意識に使ってしまうようです。私も実感があって、最近昔の服や本を捨てようかどうか悩んでいる時期があって早く判断してしまえば考えることがなくなるので、ウィルパワーを無駄に消費してしまっていたと感じています。 いろいろ捨てていくうちにテレビも捨ててしまいました。テレビは受動的に不要な情報も入ってきてウィルパワーを使い過ぎてしまっていたので個人的には良い判断だったと思っています。

ウィルパワーを回復する

毎日使い切ったウィルパワーは回復させなければ次の日は100%の状態でタスクをこなすことができなくなります。 そのためには体力と同じで回復をしっかり行わなければいけません。ウィルパワーの回復は睡眠が回復の主要方法のようで、睡眠の質が翌日のパフォーマンスに影響することがわかりました。

  • 早寝早起き 早寝早起きはかなり個人差が出ると思います。できるエンジニアは夜型が多いイメージがあり、一回ゾーンに入ると夜通しプログラミングする、というエンジニアは特にイメージしやすいかと思います。社内外問わず、確かに私の知っている優秀なエンジニアは夜型が一定数いると思っています。私はエンジニアになった当初、その流れに乗って夜通しやってみようと思いましたが、どうしてもその次の日などになるとパフォーマンスがかなり下がってしまうので、夜型にはなれませんでした。 私は朝型が身体にあっているようで、調子が良いときは朝5時台に起きて、6時台の電車に乗っています。朝の時間は生産性が高いため、技術的なインプットや実装の設計などの自身が重要と考えるタスクを実施しています。

  • 最低睡眠時間 最低睡眠時間もこれも人それぞれですが、私は最終的に7時間ちょっとの睡眠時間がベスト、というところにたどり着きました。はじめは6時間で大丈夫だろうと生活を行っていましたが、どうしても3〜4日経った段階で頭がまわらない状態が続くようになってしまいました。これは実際の眠気と差異があるからだと思っています。おそらくカフェインとかで目が覚めているけど頭が回っていないゾンビ状態だと思っています。こちらの時間は個人で睡眠時間の計測と日中のパフォーマンスを確認してみると最適な時間がわかるかと思います。

さいごに

いかがでしたでしょうか。エンジニアとして集中力を保つことが出発点となりましたが、もう少し業務に余裕が出てくれば、業務外の活動(LTや自作サービスなど)に使う余力がでてくるのでは、と推察しています。これをきっかけに生活全体が改善され、この5ヶ月でかなりQoLが向上したと思っています。 これ以外にも食のとり方やトレーニングなどの生活習慣改善を行っているので別の記載に投稿していきたいと思います。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

多能人材になれ!ソフトウェア開発の職種の壁を攻略〜シンクロ率100%ソフトウェア開発補完計画〜

f:id:tai-hey:20191216110639p:plain

この記事は プレイドアドベントカレンダー23日目です。

はじめに

私は プレイド のエンジニアの大平 (@Victoria_Peak_) と申します。グーグルとロードバイク、筋トレが大好きです。特技は早起きです。

twitter.com

2019 年も年末に向けて後少しのところ、みなさまどうお過ごしでしょうか? そろそろ今年の振り返りなどする頃ではないでしょうか。

私の 2019 年はかなりチャレンジングな年となりました。SE・PM キャリアとして7年勤めた野村総合研究所を辞め、プレイドに2018年の7月に転職しました。

PMキャリアからエンジニアキャリアへのレーンチェンジのため、スキルセットは新卒の時と同じゼロになり、業界も SIの基幹システム系 から Web業界のマーケティング周りへと、環境が激変した中でチャレンジした一年となりました。

振り返りの中で、未経験からwebエンジニアとして一年半勤めた中で業務経験から、一つ考察をしてみましたのでこのエントリとしてご紹介したいと思います。


対象読者

  • 十数人以上のソフトウェア開発組織に在籍し、環境がすぐに変えられないが自分を適応させたい人
  • 自分を磨くことを通して職種の壁を超えたい人
  • ポータブルスキルを持ち、どんな環境や会社にいっても自分を適応させたい人
  • 職種の壁を感じていて、どうにかしたい人
  • ソフトウェア組織の確認・認識合わせの作業に疲弊している人
  • 未経験からレーンチェンジをしようとしている人
  • ビジネスからエンジニアになろうとしている人


目次

目次は大きくわけて3章構成となっています。 私のエントリは相変わらず長い(今回は1万字)ので、さらっと見たい方は下記で概要をつかみ、見出しを飛ばしながら見ていただければと思います。

  • 1.モデリングはソフトウェア開発の共通言語になる
  • 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
  • 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる


言葉の定義(職種の壁)

エントリ内で「職種の壁」という言葉がでてきますが、これは「職種と職種の境界」と「職種毎のスキルセットの境界」の意味でつかっています。別の職種の経験がなく、コミュニケーションなどに説明や経験が必要な状態を指します。




1.モデリングはソフトウェア開発の共通言語になる

転職してから一年ほど経った後、業務の経験を昇華させて整理し、9月にモデリングベースでフロントエンド設計を見直した記事を執筆しました。

tech.plaid.co.jp


フロントエンド設計概念の依存関係を整理し直す中の気づきを整理したのですが、この執筆の中でモデリング起点でシステムが構築されることに気づくことができました。

モデリング起点は私のエンジニア活動でのバイブルになりました。モデリングに可能性を感じる日々、その中で年末に向けて仕事やそれ以外でもいろいろな活動の中で模索していきました。


- ブログエントリの反響 〜そして気づき〜

エントリの内容にコメントをもらったり、LTで発表して実際の反応を聞いたりしている中で、ある一つの共通点に気づきました。

私の想像以上にみなさまの職種の境界線に対する関心が高いことです。

要約すると下記のような話が多いように感じました。

仕事をしている中で「プロダクトの今の仕様についてはエンジニアさんの言うことが正しいから」「ここはデザインの範疇だからデザイナーさんに任せよう」

と思いつつも、

「本当にその仕様はそうあるべき?ユーザーを考えたらこうならない?」 「デザインはアートっぽくキレイにするだけじゃなくてプロダクトの使いやすさによせられない?」 「やっぱりもう少しプロダクトの仕組みにも踏み込んで理解したい」 「(聞くのはこわいけれど)分かれば自分の仕事をもっと質を高められるはず」

と思っていたり。


- ビジネス × システム = △  デザイン × システム = ??

やはり私の想像以上に世の中にはまだ職種境界というものが多く存在し、人はその境界を意識し、ストレスを感じているのではないでしょうか。

元々一人で作成するようなものだったソフトウェアは、成果物として大きくなるほど、作業分担化が進みました。

既にビジネスとシステムの関係性については、下記のエンジニアブログにて、私の経験則も踏まえ記載しています。みなさんもご存知の通りビジネスとシステムは密接に関わっており、意識するかと思います。 私もここを経験として知っているからこそ、ビジネスとシステムの役割の壁は壊せると思っていましたし、それに向けての活動をすすめています。

tech.plaid.co.jp


私も9月のエントリのネタになったプレイドでの活動の中で、みなさまと同じように、デザインとシステムに壁を感じていました。

9月のエントリで活動を整理した際に、壁に気づいてからというもの、今度はどうやったらデザインとシステムの壁を超えられるのかを考えるようになりました。

私は日頃からソフトウェア開発では、職種の壁はないと信じているのですが、まだ半信半疑になっていました。

その中であるワークショップに出会うことで確信を得ることになりました。


- OOUI との出会いでデザインとシステムの壁撤廃が確信に変わった。

この確信のきっかけとなったのは弊社のブログでも取り上げられている下記のワークショップです。私もこのワークショップに参加しました。


note.com


前から OOUI には注目していて、弊社のデザイナーの 鈴木さん とはよく会話をしていたのですが、このワークショップを紹介いただき、参加することになりました。

詳細は上記エントリを確認いただきたいのですが、ワークショップの内容は、まさに私が今までやっていたモデリングの内容そのもので、OOUI はモデリングベースで UI を考察する、「構造を起点とするデザイン手法」だと解釈しました。

このワークショップを通して、元々感じていたデザインとシステムの境界を超えるためには、OOUI はとても有効で、デザイナーもエンジニアもモデリングを共通言語として学べば、ソフトウェア開発の可能性をまだまだ広げられると確信を持ちました。


以前から私はビジネス × デザイン × エンジニアの全ての境界線を取り除けば、ソフトウェア開発をより確実に迅速に進めることができるのではと信じてやみませんでした。今回はそれを裏付けるような内容に興奮さえ覚えました。

そのようなことを考えていると、今年の弊社の活動の中でとても良い事例が既に行われていました。下記のアドベントカレンダーを参照いただければと思います。


note.com


このビジネス × デザイン × システムは モデリングベースを共通言語として壁が撤廃できることが確信に変わったところでもう少し考察を進めたいと思います。

今度は組織に目を向け、ソフトウェア開発の組織構成について考察をしてみることにします。ここからは図で段階を追って説明することにします。下記の2点について論じようと思います。

  • 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
  • 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる


2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている

私自身あまりソフトウェア開発の歴史は詳しくないのですが、ソフトウェア開発は一つのソフトウェア完成品の成果物を作成するのに、はじめは一エンジニアだけで作成したのが、コードの肥大化と共にいつの間にか役割の分化が進みました。


- 個人のソフトウェア開発

f:id:tai-hey:20191215103739p:plain
個人のソフトウェア開発

ソフトウェア全能神創世記

まずは最小単位の一人でアプリを作るケースです。 エンジニアが一人で作成するケースがイメージしやすいでしょう。 この段階ではデザインも好きに決めていいですし、ローンチ後のビジネス展開も一人で決められます。 有名なアプリたちもこのようなケースから始まったものは多いのではないでしょうか。 プロダクトが手にとるようにわかり、自分が神様になった感覚ではないでしょうか?


- 少人数チームでのソフトウェア開発(細かい・少量のバケツリレー)

f:id:tai-hey:20191215145115p:plain
チームのソフトウェア開発

役割分担が始まる。軽く話しながらそれぞれがそれぞれを分担することで開発スピードは上がる。

少人数スタートアップなど、チームでのソフトウェア開発のイメージです。 作業メンバーが分かれるので、作業工程は Vue.js設計地図 でも書いたように、ビジネス → モデリング → デザイン → システムの順で進んでいきます。

役割分担はもちろんビジネスとシステムやモデリングを同じ人がやるケースもありますし、デザインもビジネスの人が書くこともあるでしょう。そこらへんは垣根がありません。出来る人がやるイメージでしょうか。

作業の流れは大まかに左から右に流れ、細かい・少量のタスクのバケツリレー形式でタスクがいったりきたりしています。

プレイドもほぼこのようなチームが複数あるゲリラ組織的なチームになります。ただ組織全体の話になるのでその解説は割愛します。


- 会社のソフトウェア開発(細かい・大量のバケツリレー)

f:id:tai-hey:20191215145619p:plain
会社のソフトウェア開発

作業コスト・コミュニケーションコストが爆増

これ以上大きくなってくると一つのソフトウェアでも様子が変わってきます。人数が増え、一気に組織的な(十人〜数十人規模など)開発になります。みなさまが会社で開発しているケースがこれがほとんどではないでしょうか。一つの職種が2人以上になった時点でこの概念に入るかと思います。

作業の流れはかわりませんが、バケツリレー(タスク)の量が格段にあがります。バケツリレーの種類も、依頼調整に加えて確認のバケツリレーが多くなってきます。会社としてどのようなシステムにすべきなのかという点で工程間の人々の距離が遠くなり、書面確認などでの間接コストが高くなります。ここらへんはみなさん体感で分かるかと思います。

[ソフトウェアを良くする活動] < [認識を合わせるための間接的な活動] → そして私たちはリスクヘッジに疲弊する

本来効率化のために作業分担しているにも関わらず、職種間で余計なコミュニケーションコストが増えています。 ソフトウェア自体を良くする活動に注力すべきだと思うのですが、 「誰かがいった何かを確認する」ために職種間で認識を合わせる何かのリスクヘッジのために日々追われることになります。

言った言わないを繰り返さないために確認工程は肥大化し、確認用ドキュメントを作り、やっても意味のないようなチェックが横行し、私たちは疲弊していきます。


- 私はソフトウェア開発の時代の揺り戻しをかけたい

機動力を失った開発組織

このように疲弊してしまった組織はソフトウェア開発の機動力を失います。

時代として一人でやっていたシステムは分担化が進み、中〜大規模になることが多くなりました。 感の良い方はお気づきかもしれませんが、単純に作業をするだけではなく、特に会社のソフトウェア(少人数のチームでももちろん)では、人数がここで大きなファクターが存在します。

  • 作業工程(見えるバケツリレー)
  • 意思疎通(見えないバケツリレー)☆

そうです、意思疎通です。意思疎通は見えていないコストですが、やっかいなことにこの意思疎通はタスクに具現化します。このために私たちの貴重な時間や労力を奪われています。

意思疎通を可視化する

先程お話したように、意思疎通を具現化したものが細かい定義書だったり、確認のメールだったり、打ち合わせだったりします。意思疎通がソフトウェアの本質以外を肥大化させます。

一章で考察してきたようにモデリングは共通言語になります。共通言語にしただけで全てが解決するとは限りません。そうです、役職の壁がハードルになるのです。先程は作業工程のみの図でしたが、ではこの意思疎通を含めたコミュニケーションの相関図を書くと、下記のようになります。

f:id:tai-hey:20191217090941p:plain
開発のコミュニケーション組織相関図(意思疎通 追加ver)

こちらはモデリングを共通言語にそれぞれがコミュニケーションをとる相関図です。真ん中の相互矢印はメインの意思疎通で、点線は実際のバケツリレー(タスク)となります。開発職種もA,B,Cさんの3職種となります。


意思疎通を撲滅させる

私はより良いソフトウェア開発を考えた時に、今後は一人でソフトウェア開発をしていた前の状態に揺り戻しをかけたいと思っています。規模感が小さくなることはおそらく無いと思いますので、それを保ったままシステムをさも一人で作っているよう(全員Aさん)に近づけたいのです。

f:id:tai-hey:20191215155746p:plain
開発のコミュニケーション組織相関図(理想)




3. 多能人材で職種の壁を無効化し、私はソフトウェア全能神になる

ではそのような規模が大きくなりがちなシステムを、さも一人で開発する(全員Aさん)ようにはどうすればよいのでしょうか?壁を撤廃するといっても本当にできるのでしょうか?


- 多能人材を目指す

越境ではなく境を無効化する

少なくとも、仮にモデリングを共通言語にしたとしても認識をあわせるコミュニケーションコストは絶対にかかります。では、意思疎通を撲滅させるためにはどうすればよいのでしょうか?現実的な解を模索していきます。

私はそれを自分自身を多能人材にすればいいという発想に至りました。つまり私が全部Aさんになることができればいいのです。

巷ではよく「エンジニアのわたしが○○チームで頑張った、越境した」と聞くことがあります。

それでも確かに素晴らしいと思うのですが、まだそれでは人の意識の壁は超えられていません。私はどんな環境でもソフトウェア開発とそれを取り巻くチームとのシンクロ率100%を目指したいと思っています。

多能人材は「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」です。

この人材像が達成できると、極端にいうと、メインの矢印である職種間の意思疎通が不要になり、役職の壁が無効化され、コミュニケーションコストがゼロに近づきます。それに伴い確認のバケツリレーもなくなります。



なぜかというと

  • エンジニアの私がデザイナー(ビジネス)を「見聞き、理解」して「教えてもらいながら」開発する

よりも

  • エンジニアの私がデザイナー(ビジネス)を「やったことがある」ので「なにを考えているかを手にとるように把握できている」

には圧倒的な差があると思っています。これを目指したいと思っています。




- 環境はすぐには変わらない。自分自身を鍛え、適応させろ

なぜ環境を変えずに自分を変える方向を選択するようになったのか?

組織自体を組み替えたり、という方法もあるでしょう。これは完全に好みと私の生き様に近いのですが、私は転職や複数組織に携わった経験から、会社など他人や環境を変えるのは社歴の浅い人やポジションの関係もありすぐに変えるのは難しい事が多いです。組織自体を変えるにも時間がかかり、必ず変えられるとは限りません。自分を変えるのであればそれよりも遥かに簡単で確度が高いです。

自分が多能になれば、自分がジョインするだけで組織や環境に関係なくソフトウェア開発を一つに補完できると思うし、すぐに効果がでるはずなのです。

なので今回は環境は変えず自分を鍛えて開発適応度を上げていく、という方法で模索していきたいと思います。自分が強くなれば組織を変えられるかもしれない。なので先に自分が強くなる方を選びます。


- どのようなキャリアパスで経験していくのか。(ただし、これは茨の道)

まあ、言うは易く行うは難しです。この人材になるには生半可な継続時間だと達成できないと思っています。私はこれまでも、この先も、長い戦いを覚悟して目指します。 いろいろな人からも無理だとか組織を変えたほうが速いとかという意見も聞くことになるでしょう。でも私は進みます。

先程お話した「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」というのは、それぞれを経験しているからこそリアルタイムに化けられるのです。

そのためにはビジネス、エンジニア、デザイナーをそれぞれ数年は経験することが必要になってきます。

少なくとも私は今の時点でビジネス(PMキャリア)7年 → エンジニア(1.5年)なので理想に近づいてきています。ビジネス × エンジニアのメリットも感じております。

では、どのようにキャリアパスを歩んでいくか、自分の経験を積んでいくかの計画をこれから述べていきます。


- ソフトウェア開発体制の実態

f:id:tai-hey:20191215160955p:plain
キャリアをどう歩んでいくか

私たちのとりまく環境は実際こうなっており、まずこの図をベースとして表現をしてみました。これからどうやって一つにしていくかを実態に落として考えていきます。


- コミュニケーションするのはリーダー

f:id:tai-hey:20191215161316p:plain
キャリアをどう歩んでいくか

システムの共通言語はモデリングであると述べました。そのモデリングをつかって、各職種チームとコミュニケーションを取ります。実質はリーダーのような人(図の白抜きの人)を中心に仕様やデザインを検討していくことになるでしょう。

この際先程の大量のバケツリレーが行われるコストがネックになるのですが、これを多能人材は解消することになります。下記の図のように、この人たちをAにすること が目指す方向性となります。

f:id:tai-hey:20191216005812p:plain
茨の道のゴール



- スタートはメンバーから

f:id:tai-hey:20191216010034p:plain
茨の道第一歩目

スタートはみなさま新卒時など、よくあるようにこうなります。赤い人のようにメンバーからスタートです。


- 普通はここまで

f:id:tai-hey:20191216010225p:plain
普通はここまで

普通はそのまま何年か経つとリーダーになり、コミュニケーションの先頭に立つことになります。ビジネスでもいろいろな守備範囲があると思いますので、ビジネスの中で経験を踏んで極めたりして価値を出し、そのまま定年を向かえるのも全然正解です。(エンジニア、デザイナーもしかり)


- メンバーに戻る勇気をもって、あえてレーンを変える

f:id:tai-hey:20191216010526p:plain
メンバーに戻る勇気をもって、あえてレーンを変える

でも目指す方向は全部Aさんにすることですので、このまま甘んじててはいけません。ここであえてレーンを変えます。メンバーに戻りますし、スキルセットはゼロになりますし、年収は下がるでしょうし、怖いですがやります。私は既にビジネス(SE・PM) から エンジニアになっているので、これは一回クリアしています。私は今この状態です。


- あとは繰り返し

f:id:tai-hey:20191216011123p:plain
何年か経つとこうなる(Cさん→Aさん)

はい、ここまでくるとわかりますね。あとはこの繰り返しです。


- 最後のレーンチェンジ

f:id:tai-hey:20191216011252p:plain
最後のレーンチェンジ

ここでもう一回やってみましょう。


- 更に数年でやっとゴール

f:id:tai-hey:20191216011432p:plain
完成形

はい、これで晴れてBさんもAさんとなり、全てがAさんになりました。ここまできて晴れて「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」多能人材となりました。

こうなったあとのメリットは先程述べたとおりですが、ここまで来た後が本番だと思っています。

正直ちょっとここまでいけるのかどうなのかは自分でもわかりません。挫折してしまうかもしれないし、別の方向にいってしまうかもしれません。 現時点で私の意志は堅く、多能人材に挑戦したいです。私は今2段階目の途中なので、まずはエンジニアをしっかり続けて、CさんをAさんにする活動を続けていきたいと思います。


まとめ

はい、いかがだったでしょうか?年末ですので、今年の振り返りから現状の把握、将来像を考察してみました。みなさまの今後のキャリアのご参考になれば幸いです。 ソフトウェア開発はまだまだ可能性があります。私は今エンジニアという構造の中身の方に身をおいていますが、可能性を感じるその気持ちは日に日に強くなっております。

今回は職種の壁をテーマに執筆しましたが、どうにかしてこの壁を撤廃・攻略し、その一心で今後も活動を続けていきたいと思います。

2019年、みなさまはどのような自分だったでしょうか。 2020年、みなさまはどのような自分にしたいでしょうか。

私もそんな問を自分に問いかけながら年を越したいと思います。

最後までお読みいただきありがとうございました。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

SIer/年収1000万を手放した私 〜選考全落ちを経験しながらもやりたかったこと〜(中編)

f:id:tai-hey:20190923133222p:plain

はじめに

みなさま、お久しぶりです。

私は プレイド のエンジニア、大平 (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで プレイド で勤務しています。

twitter.com


本エントリは、去年年末に執筆した、 前編 の続編となります。

www.taihey-blog.com

※前編の反響が私の想像以上に大きく、続きを読みたいといろいろな方々から応援を頂きました。ありがたいことに家族や友人、twiter、ブログのコメントでもたくさんのコメントを頂きました。ありがとうございました。



- 本連載の構成と中編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで)
- 中編 (退職〜プレイド入社まで) ※本エントリ
- 後編 (転職後〜現在まで)


本連載は、私が自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。昨年は転職含め怒涛のように環境が変わっていきました。恵まれた大企業の環境から個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦しておりました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

中編はその苦労の直前(といってもここでも大変なのですが)、転職活動の内容となります。

転職してから私は、Webエンジニアとして一年の間、twitter などで、SI から Webエンジニアへの転職に関する議論をいろいろ見てきました。どういうやり方が正かどうかはわからないのですが、その議論を見た上で私の転職活動を振り返ってみました。今思うとポートフォリオを作ったりする正攻法ではないと思っているため、この頃の私の転職戦略はあまりおすすめできないと思っています。私自身、はじめての転職だったのでかなり手探りで活動をしておりました。年齢も30歳直前を迎えていたため、転職に焦っていたのも事実です。慌てながらも転職活動をしていたので、一種の体験談として読んでほしいと思います。

まずは、前回の振り返りからいきましょう。

- 前回のあらすじ

(前編参照) 新卒で文系SEとして野村総合研究所(以下NRI)に入社した私は、普通のNRI社員として働いていました。なれないITの仕事に苦労しながらも、このままSEとしてキャリアを積み続けるのだと疑わず、順風満帆な人生を歩んでおりました。しかし、6年経ってプログラミングスキルが満足に身についていないことに違和感を覚え、G's academy (以下 G's )に入学します。

https://gsacademy.tokyo/gsacademy.tokyo

G's で必死に深夜まで(または朝まで)プログラミングを業務と並行して書いた数ヶ月。その中で G’s のメンターであるWebエンジニアの方々やモダンな技術に触れていくことで、自身のキャリアの方向性を考え直し、レーンチェンジを決意します。

「30歳直前を迎えた今、恵まれた環境を捨てても本当にやりたいこと、将来像を追いかけたい」

PM・業務を考えるマネジメントメインのロールモデルではなく、エンジニアとして構造や処理を考えるロールモデルを目指し、転職を決意します。


それでは、ここからは前編の続きからとなります。退職を決意した2018年2月、後転職活動開始のエージェント探しからとなります。

3月/転職活動開始、エージェント選定

- 転職ってどうやるのか。とりあえず情報収集だ。

仕事ではやりたいこと(前編のブログ参照) を業務内容にしたい、その一心で転職を決意します。 とはいえ、始めての転職活動となるので、並走していただくエージェントを選ぶところからはじめました。今はリファラルや wantedly なども方法だったりしますが、当時の私はweb系の友人も多くなければ、カジュアル面談という概念を転職活動ではじめて知るくらいの転職知識が皆無の状態でした。

また、動き出すにはまずは情報収集・インプットが大事。自分が市場からどう見られているのか(市場価値)、やりたいことがどれくらい実現可能かどうかも知る必要があります。そこを明るくするためにもエージェントとの面談活動の目的でもありました。

- やりたいことを深堀りしながらエージェントを選定する。

普通の転職エージェントや、IT業界全般が強いエージェント、Web 系特化のエージェントなど、各エージェントの特徴をネットや友人などに聞き、情報収集を行いました。本編とは少しそれますが、wantedly にてカジュアル面談を繰り返し、自分のやりたいことと市場価値の情報収集も行いました。

トータルで5・6社くらいのエージェントと面談を行いました。それぞれの面談の中で自分の市場価値ややりたいことがどれくらい妥当性があり、転職する際にどのようなモデルケースがあるのかをすり合わせていきました。

- やりたいこと・キャリア・自身の市場価値が見えてくる。

面談をいくつか繰り返す中で、下記のことが明確になってきました。 例外のケースが有るかと思いますが、私が感じた内容となります。

  • 30歳という年齢は労働市場として未経験レーンチェンジは、ほぼラストチャンスであること
  • 自分が20代で積み上げてきたキャリアはエンジニアというよりも PM ≒ ビジネスサイド
  • 自分が将来的になろうとしている将来像は長期的に見れば可能性はある
  • 短期的にやりたいことはプログラミング
  • レーンチェンジとして業務未経験のハードルはやっぱり高い。ここはチャレンジ。

が見えてきました。

面談の中で自分で明確になった箇所や、労働市場からどう見えているかをすり合わせていく中で、自分のやりたいことと経緯・キャリアの簡単なスキルマップをパワーポイント作成しました。このパワーポイントを作成することでかなり自分の転職活動の軸が明確にすることに役立ちましたし、実際に面接官に渡して説明したりすることもありました。こちらは別ブログでまた紹介したいと思います。

- エージェントの決め手はやりたいことの理解深度。

今回の私の転職は、待遇等ではなくやりたい業務内容の優先順位が一番高かったため、 企業選びに対して企業選定の精度を高めるためには業務内容を正しくエージェントと同期させる必要がありました。

その前提を踏まえた上で、それぞれの面談を通して、あるエージェントに決めました。今までやってきたこととこれからどんなレーンチェンジをするかを、面談をしていく中で一番よくヒヤリング頂き、理解して頂けたと感じたことが決め手になりました。

例えば、その方はジーズアカデミーをご存知で、その中の活動内容もよく理解してくれていたことでした。他のエージェントはIT業界自体は詳しかったりするのですが、お願いしたエージェントはその中でもサーバーサイドとかフロントエンドの話や、技術のより詳しい範囲での理解をしてくれていたことが会話の中で読み取れました。また、実際に私と似たようなレーンチェンジ事例を担当されていたことも決め手となりました。これは巡り逢いかなと思っております。

面談前後も感触と心境を聞いて頂いたり、他の企業との日程調整を丁寧にしてくださり、かなり助かりました。とても感謝しております。ありがとうございました。

4月/退職・転職応募開始。しかしメガベンチャー・有名企業・大手のエンジニア職に応募全落ちで撃沈。

- 転職活動の前にまずは退職だ。

ここまでの活動で、エージェントも決まった、やりたいことも固まってきた、というところまで来たのですが、転職活動よりも先にやることがあります。NRI への退職願です。

通常であれば現職を続けながら並行で転職活動、ということになるでしょう。ただ、30歳直前という年齢を鑑みていち早く業務でプログラムを書くため、とりあえず先にやめることにしました。おそらくテンパって頭がおかしくなっていたのでしょう。と今になって思います。

並行でやってしまうと、面接をするタイミングも業務後になりますし、内定をもらったとしても現状の業務と調整し、退社日を決め、有給も取って、、となると半年後とかになってしまう可能性もありました。今となっては数ヶ月くらいそんなに変わらないのではと思っているのですが、当時はとりあえずやめることにしました。

ここは NRI の方に本当に感謝なのですが、理由を説明したら快く応援してくれ、業務と要員の調整を行っていただけました。スムーズに4月末を最終出社とすることができました。ありがとうございました。

- もう後はない。転職活動応募開始。

会社も無事退職することができたので、転職活動の応募を開始します。もう後には戻れません。転職活動がはじめてではありますが、自分の市場価値がどこまでいけるのかチャレンジしてみようとまずはチャレンジングな応募を中心に行いました。

選定企業軸はエンジニアファーストで、自身がコードを書く業務につけること、テッキーな社員が多いことです。その軸の中からなるべくレベルの高い企業を選定しました。

エージェントとも相談し、その評価軸からレベルの高いメガベンチャーや大手インターネット企業20社ほどを受けることにしました。

まだ始めたばかり。応募企業も就活のときとは違い、転職活動では十数社受ければいずれかはいけるだろう、と強気でいました。私自身正直どこか受かるだろうと高を括っていました。それが甘かったのです。

- 結果は全落ち。

結果は全落ちでした。4月の NRI 最終出社の時点では残り一社のところまで来ておりヒヤヒヤしていましたが、希望していた企業だったのでその最終面接が終われば転職活動は終わりにする予定でした。

しかし最終面接で落ち、応募企業にすべて落ちることになりました。 送別会の時に、「今転職活動どんな感じ?」と当時の上司や同僚に聞かれ、「全部落ちました、一からですねぇ」と笑ってごまかしていましたが内心はかなり不安だったのを覚えています。敗因は書類で半分以上落ち、プログラミングのテストと併せた筆記で落ちるところも多かったです。想像ですが、未経験30歳直前でコードを書く職を受けるということのハードルの高さ、プログラミング技術力がシンプルに足りなかったのだと思っています。まあそれは落ちるよね、と落ち込みながらも納得していました。

(内心)ああ、どうしよう、終わった。もう一度一からやり直しだ。

ここでエージェントに改めて相談に行くことに。。。






5月/追加15社Web企業を中心にエンジニア職で再チャレンジ。

- 気を取り直して再チャレンジ。

5月に入りました。新緑で天気もよく、世間は超大型のGWだったりするのですが、私の気持ちは真逆。そんな気持ちの余裕はなかったのです。

でも全落ちしたからといって落ち込んでいる場合ではありません。後戻りはできないのです。前に進むしか無い。そう自分に言い聞かせて活動を再開します。ていうかそもそも先に辞めてしまったお前が悪い。お金だって半年前はやめるなんて思ってないから転職活動に向けて特別貯金なんてしていない。もって数ヶ月しかない。まさにキングダムの壁将軍状態。兵糧(貯金)がない。昔に遊びすぎた。

今後受ける企業軸は変えず、エンジニアファーストでコードを書かせてもらえる企業中心のままです。エージェントに相談し、追加で企業を選定しました。

兵糧がないのに反省の色が見えません。やっぱり頭がおかしかったのでしょう。

今回はある程度選考が通るようになります。エージェントに選考企業を配慮して頂いた結果が功を奏しました。

- 面接中に感じた違和感。

書類選考は通るのですが、少しここで違和感を感じます。

面接をしてみると、エントリーする職種の業務内容が、クエリとかデータを作ったりもするビジネス職でした。また、エントリーはエンジニアだけれども、選考の途中でコードを書く系のビジネス職での選考をおすすめされるのです。

おそらくエージェントがエンジニア職希望です、と出しても、企業側のある程度受け入れを考えると、エンジニア職ガッツリよりも、エントリーはコードを書くビジネスとして入り、いずれエンジニア寄りにいったほうがよいという判断なのです。確かにもともとSEだったのでそのほうがバリューもでやすいし、待遇もそんなに落とさなくてよいし、客観的に見ても合理的な判断だと思います。

それと最終的な将来像がITコンサルタントITアーキテクトエバンジェリストをかけ合わせたような人材(詳細は別ブログで)になりたいので、そのためにコードを書ける職種につきたい、と書類に書きましたし、面接でそう言ったのでそう思われるのも無理ありません。

ですが、私はかなり違和感を感じます。

- 違和感を内省を重ねて明確に。

ここで内省を重ね、その違和感を深堀りしていきました。

「そうだ違う。私は今すぐエンジニアになりたいのだ。はじめは業務でほぼ100%コードを見ていたいのだ。そうしないと業務内でコードを書く濃度が薄くなっていまう。一番キャリアのネックになっているプログラミングの成長が遅くなってしまう。最速で将来像に近づかなければ。」

こういう周りになんて言われても将来像にこだわるところが要領悪いなと31年生きてきて思います。

申し訳無かったのですが、内定を頂いていた企業も選考を進んでいる企業もエンジニアでないならばと辞退させて頂き、応募する企業を再度検討することになるのです。

6月/修行だ。年収3分の1でもいいからと必ずコードをかけるエンジニアになれる企業を中心に応募。

さあさあ転職活動が泥沼の様相を呈してきました、これはもつれ込みそうです。久々に昔のことを書いていてほんと頭がおかしいなと思うのですが、もう少しなので筆を進めていきます。

- 3度目の正直。再度応募企業を見直し。

5月の面接の内容と、感じた違和感について素直にエージェントに伝えたところ、嫌な顔一つせず、再度選定を進めて頂けました。仕事とはいえ本当にありがとうございました。。。

流石になりふりかまっていられません。エンジニアとしてコードを書けるところであれば、条件は度外視です。スタートアップ、ベンチャー中心にとにかくコードを業務で書ける職種の軸でエージェントに選定してもらいます。自分でもネットで企業を調べながら選定企業を加えてきます。もう必死です。

それでも順風満帆には行かず、スタートアップもどこも受け入れてくれるわけではなく、エンジニア業務経験のないのであれば体制上余裕がないのでまず受け入れられない、という企業も実際にありました。確かに現状スタートアップの中にいて体制の余裕の少ない企業が多いのも共感できます。

- プレイド との出会い

そんな中受けていた一社の中に プレイド がありました。面接したのは6月の中旬。選定企業の中でも最後のほうで、本当に軌跡に近かったと思います。面接の時点で他の会社から内定がでていたのもあり、そんなに猶予もありません。

一次面接時はまだ五反田のオフィス。今ほどは大きくないオフィスビルの窓際の駅の見える小さな会議室で面接したのを覚えています。



- 話せば話すほど プレイド の文化・考え方に惹かれる。

一次面接、二次面接と進んでいくにあたって、なにか他の会社とは違う惹かれるポイントを感じます。なんかこの会社、他と考え方が違う。変だ。

考え方の普通じゃなさはまた別の機会に置いておき、プレイドに惹かれた理由、マッチした理由を紹介したいと思います。

- 私がしたい「技術力で市場を作ること」の気づきと共感。

まずスキルよりも将来的な志向性で見られていたことが大きかったです。私の将来像(ITコンサルタントエバンジェリストITアーキテクトをかけ合わせたような人材像)に共感していただけました。そこまで特に進展がなかった将来像でしたが、新しく言語化してもらえました。

「ああ、大平さんは技術力を武器に市場を作っていきたいんだね。」

なるほど、たしかに市場を作っていく、という言語化はしていませんでした。思ったよりこの言葉が私の中でしっくり来ており、面接時に更に将来像が明確になったのは久々でした。この将来像に共感してもらえて、今でも社内でもその話をすることがありズレていないのが実感できます。

- 将来像へのスキル構築プロセスが自由だった。

次の点ですが、将来像へのスキル構築のプロセスも自由度が高かった点が挙げられます。5月の面談のように、普通のキャリアであれば、コードを書くビジネス職の採用になるはずだと思います。私は最終的にはそちらに近い方向に向かいたいのですが、プレイド はしっかりエンジニアとしてコードを書くことを尊重してくれたことがマッチしていた要因の一つでした。二次面接で当時のCTO(現CPO)と面接した時は、いつかはフロントにでるかもしれないが、まずは納得のいくまでコードをかいてよい、ということが決め手となりました。フロントに出るイメージも、100%ビジネスなのか、70%ビジネスで30%エンジニアなのか、スタンスも自由に決めて良い。とのことでかなり自由度の高さに惹かれました。

- Google リスペクト文化

それと Google リスペクトの文化です。私はミーハーなので Google 大好きです。NRI の時から Google の働き方や考え方に憧れて書籍を読んでいたくらいでした。プレイド 社内でも Google 文化をリスペクトしているし、実際にやりとりもある、という話を聞けたの惹かれた理由の一つです。

- そして入社

本当にそこからはトントン拍子で話が進みます。最終的に5社ほど内定を頂いており、どの会社も魅力的な企業でかなり迷いましたが、6月下旬には プレイド に内定受諾の返事をし、7/1から入社となるのです。

はぁ、、ここまで長い道のりでした。はじめはどうなるかとは思いましたが。。 有給も尽きているため、行き着く暇もなくここから私のエンジニア生活が始まります。。。ここからが本当の勝負ですし、本当に大変です。。



最後に

中編エントリをお読み頂きありがとうございました。 最後に心境変化のまとめと今後の方向性を少し追記して終わりにしたいと思います。

- 転職活動を通じて変化した心境と覚悟。

正直4月で全落ちしてしまった時にはどうしようかと思っていました。転職するなんて数ヶ月前には思っても見なかったので、貯金もしておりませんでした。もともと金遣いが荒くロードバイクとか飲み会にかなり使っており、辞めてから数ヶ月やりきれるかどうかという状況でもありました。とはいえやめてしまったので転職活動をやるしかありませんでした。ここはかなりしんどかったのを覚えています。あきらめて内定の出そうなところに落ち着きそうですが、将来像になるために繰り返し内省してモチベーションを保ち、納得して転職活動を終わらせるまで頑張ったのを覚えています。

また、覚悟が変わりました。NRI・大企業という恵まれた環境や年収を捨てていますので、もちろん以前より年収が下がっていますし、普通にしていたらこれ以降伸びるとは思いません。前職では大企業ですしほぼ会社の業務に乗ることで給料がでていたと思いますし、ある程度昇給もしていったはずです。

ただ、これからの人生は違います。そういう生活や環境は捨てました。プレイド はスタートアップなので、大企業ほどの個人への後ろ盾はありません。しかも移った職種は技術力がシビアに問われる世界であるwebエンジニア。自分の市場価値・個人としての実力を意識して磨いていかなければいけない職種です。ただ、必死に手を動かしスキルを磨けば市場価値も年収も上がっていくはずですし、なにか私個人としてのバリューをダサなければいけません。今後はエンジニアとしてその市場価値の追求もこだわっていきたいと思っています。

- 次回について

長めの体験談エントリでございましたが、お読み頂きありがとうございました。 転職するまでを書いてきた本連載ですが、次回が一番苦労した経験、後編:挫折の章となります。 30歳、レーンチェンジをしたことでどんな点が苦労したのか、メンタル的に変えなければいけなかったのか、スキルとして何を苦労したのか、業務でやっていくのにどうやって克服していったのかを綴っていきたいと思います。

前編中編間よりは間は開かないと思いますが、もう少々お時間をいただければと思います。それでは、後編エントリでまたお会いしましょう。

www.taihey-blog.com




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

SIerに7年いて幸せで染まりかけたのに、年収1000万を手放してWeb業界で本当にやりたかったこと(前編)

f:id:tai-hey:20200102175043p:plain※2018/12/26 少し内容をブラッシュアップしました。

この記事は、#しがないラジオ 2 Advent Calendar 2018 - Adventar の21日目の記事となります。

私は プレイド のエンジニア、大平 (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで プレイド で勤務しています。

Kaz_Shio / SIerと自社開発 エンジニアのリアル:デジタル人材の探究 (@Victoria_Peak_) | Twitter

と申します。

adventar.org twitter.com

はじめに

投稿のきっかけと動機

私は今年の6月に野村総合研究所(以下NRI)を退職してスタートアップでエンジニアとして働き始めました。 はじめにメンターとしてついてくださったのが「gamiさん」

twitter.com

でした。その時はgamiさんはしがないラジオをやっている、SEからWeb系に転職って同じ境遇だなあと思っていたくらいでした。 今回弊社でも社内のEngineer Blog と、PLAID Advent Calender のブログとして一つ書き、なにか個人的に記載するネタを、ということでこの退職エントリ的なものを書こうと思い執筆に至りました。

tech.plaid.co.jp

qiita.com

今までしがないラジオは聞いたことなかったのですが、SIer脱出マニュアルはこれを機に読ませていただきまして、共感する箇所が多々ありました。どうSIerから転職するかとか、転職のためにどのような活動を行うべきかという観点では他のブログなどで多く語られているかと思いますので、今回はなぜSIer向きで幸せだったのにやめるまでの決意に至ったかの考え方に焦点を当てたいと思います。



本連載の構成と前編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで) ※本エントリ
- 中編 (退職〜プレイド入社まで)
- 後編 (転職後〜現在まで)


本連載は、私が自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。昨年は転職含め怒涛のように環境が変わっていきました。恵まれた大企業の環境から個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦しておりました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

前編は新卒で入社したNRI時代から始まり、その中でキャリアをどう見直し、何をきっかけに転職を決意したのかを綴っております。

私はSIerに7年も在籍していて給料もよかったですし、このままずっと定年まで会社にいるのかなと思っていましたし、幸せでした。そんな私が30歳目前で転職(転職先はまだ弊社に決まっていませんでしたが先に退職しました。)をした理由と経緯についての一つの実例として読んでいただければと思います。ちなみに退職理由も前職に説明して温かく送り出していただいていますので、ご安心ください。。


対象読者

  • エンジニア・ビジネスサイド問わず、30代未経験でレーンチェンジを考えている方
  • SIerでSEからWeb系に転職を考えている方
  • SEでも幸せな路線を探している方
  • ITコンサル志望の方
  • SEで技術が好きな方

1.文系学部生から技術を身につける(SE1年目〜3年目)

入社当初、周りは優秀な同僚ばかり

就活当初、私立文系の学生(経済学部)でコンサルタントを目指していました。コンサルタントといっても、戦略・業務・IT・会計etc..など職種分類がたくさんあります。私はコンサルタントの中でも、組織の仕組みや構造を改善することにフォーカスしたかったので、IT業務コンサルを目指すことにしました。コンサルタントとして大成するためには、まず技術を習得するべきだと思い、技術が身につき優秀な社員が多いと聞きNRIに入社しました。同期を見てみると文系学部卒の私からしたらプログラミング言語って何?状態から始まったので、習得スピードがあまりでなかったのですが、周りの理系院生の同期たちは研修や業務の習得スピードが早く、劣等感を感じていました。その辛さから今考えてみると、文系学部生→IT企業でSEというのは一種のレーンチェンジだったのかもしれません。

大企業の場合は育成担当や部としても育成計画を立てるため、手を動かせるSEとして一人前にさせよう、という社内の方針もあって、開発(COBOLでしたが、、)や本番作業などを経験させていただきました。初心者なりにもITというものがプログラムやデータの作りが肝になること、一緒に働いていた手を動かせるパートナーさんやNRI社員はとても印象深かったことを今でも覚えています。将来についても疑いはなく、いつかはプログラムやデータを自在に操り、手を動かせる人材になれると思い業務に励んでいました。

目の前の業務をこなすことで精一杯

目の前の業務をこなすことが不安を取り除くことが第一優先で、作業内容も2年目からはマネジメント業務(パートナーさんの開発やテストの管理など)がほとんどになってくるのですが、2〜3年目くらいまではDBの移行作業や本番データのパッチ当て(データの更新作業)、開発環境の調査など手を動かせることがありましたので、技術を身につけることにあまり違和感を覚えていませんでした。

ただ、技術を身につけるという意味だと途中まではあっていたのですが、1年目以降、ものづくりが自分でできる & プログラムを作る、という面では全く経験していないことに少し違和感を持ち続けながらも、目の前の業務に精一杯でした。

2. SEとして一人前になる(SE4年目〜6年目)

SEとしては順当に経験を積む

そんな違和感を持ちながらもSE3年目までに2プロジェクトを経験しました。3つ目の金融系プロジェクトは4年ほど長く経験するプロジェクトとなり、順当にSEとしては経験を積んでいきます。給料も上がっていくし、仕事としても任される範囲の規模も大きなものになっていくので、成長している実感があり充実していました。

業務内容は本番障害の緊急対応や、超大規模(最大数百人規模)だったプロジェクトのライブラリ管理担当として7〜8つもあるサブシステムの開発調整を行ったり、複数サブシステムにまたがる開発の顧客への説明資料の作成や仕様やシステム設計のとりまとめを行ったりしました。IT初心者だった私がプロジェクトの中核を担うまでに貢献できるまでになっていたので、安心感を覚えていたのがこの頃でした。また、プロジェクト全体のモジュールの構成変更などを考えて推進することを経験したことにより、プログラムの構造まで携われていることに満足していました。このまま定年までいくのかとまだ疑ってなかったですし、幸せでもありました。

3. G's academy でWeb業界にふれる(SE6年目後半〜7年目前半)

違和感を取り戻すために行動する(6年目後半〜7年目前半)

そんな中、プロジェクトとしても落ち着いている時期で、仕事に余裕がでてきましたので、目の前の業務よりも将来像を考えるようになりました。その考察の中で私はやっぱりプログラミングができていないことの違和感を再度思い出します。社内のプログラミング関連の研修を受け出しましたし、自分でも集中的にやるべきだと思って自費で数十万払い、まずは普通のプログラミングスクール(Java silverくらいまでの授業)に通いはじめました。平日の日中は業務、夜はプログラミングスクールで体力的にもしんどかったですが、プログラミングできるようになりたいという思いが強く、通うことができました。プログラミングに関して少しだけ理解が深まりましたが、ものを作れるレベルかというとそうではなく、演習をなぞるレベルにとどまっていました。プロダクトを作れるようになるとまではいきませんでしたので違和感が取り切れていませんでした。

G's academy でWeb業界・技術に出会う(7年目の後半)

他にもプロダクトを作れるようになるプログラミングスクールはないかと探し始めました。そこで出会ったのが「G's academy」です。

私はこの Dev 9期生として試験に合格し、通い始めます。今まで会うことのなかった様々な人や技術との出会いがあり、大きな人生の転換点となります。

https://gsacademy.tokyo/gsacademy.tokyo

HTML、CSSの基礎からJavaScriptPHP、Laravelなど毎週土曜日に授業が行われ、木曜日までにその技術や習っていない技術でも自由に取り入れて課題を作成します。また出てくる技術もWeb業界では一般的なのかもしれませんが、今まで関わったことのない技術ばかりだったので、毎週ワクワクしていたのを覚えています。この時はまさにプロダクトを作る、という私の7年間解消できなかった違和感を解消できそうと思いましたし、とても楽しい期間となりました。また、金曜夜の徹夜でプログラミングする合宿に参加するなど、ほんとうに夢中になってコードを書き続けました。

4. 本当にやりたかったこと (構造や処理を考えるワクワク感)

NRIで行っていた業務内容との違いに気づく

G's academyで講師のWeb系のエンジニアさんと話す機会やLTを聞く機会が多くなり、SE(NRIで私が行っていた業務)とWeb系のエンジニアで大きな違いがあることに気づきました。

  • SE:構築した後の「管理(設計書や顧客調整やプロジェクトマネジメント)」や「顧客の業務」をメインに業務を行う
  • Web系:「構造(アーキテクチャ)」または「処理(プログラム)」についてメインに業務を行う

toBでの話。toCは顧客=ユーザーの利用となります。

PLAID Engineer Blog の記事でも記載したのですが、どのシステムも構造(アーキテクチャ)、処理(プログラム)、管理(設計書や顧客調整やプロジェクトマネジメント)、「顧客の業務」、「生み出す価値」で構成されると考えています。

tech.plaid.co.jp ※2.1 価値創造のためのシステムとその構造について:を参照

SE(NRIのような顧客向かいがメインなSIer)はクライアントの個社用のシステムを作っているので、業務にどのような影響があるか、を深く知っていなければなりません。NRIでやっていた金融系のプロジェクトでは、金融の業界知識がないと顧客の求める仕様もわかりませんし、個社用のシステムは構築できないため、業務知識や管理にパワーが割かれます。既に構築された構造を変えにくいシステムを運用するには、管理にフォーカスして業務の影響がないようにコントロールすることがメインになります。新規構築だったとしても構造を考えるプロジェクトにはなりますが、NRI社員だけだと単純に人手がたりないのでパートナーさんに仕事をお願いすることになります。パートナーさんのタスクや品質の管理業務も業務の大きな割合を占め、構造ばかりを考えることは割合として少なくなります。

社内を見てみても自身でプログラミングをしている人とか新技術の話をしている人はマイノリティでした。(当初私がジーズアカデミーで習った浅めな情報を話しても知らない人が多数でした。)技術ぽい人は少数でした。

WebエンジニアはtoB系だと業務知識は少なからず必要になるかとは思いますが、LTなどの界隈をみても技術志向のエンジニアのLT内容は、新しいフレームワークだとか、JavaScriptの仕様が新しくでたとか、k8sの新しいアーキテクチャだとか、Google Cloud Platform の使い方だとか先進的な技術をSIerよりは積極的に取り入れ、しかも自分で実装しているように見えました。そんな話を聞くたびにこのような「構造」「処理」をメインに語れるエンジニアがとてもかっこいいとワクワクしたことを覚えています。

Webエンジニアになると決意する

Web業界のWebエンジニアのロールモデルに憧れた私は下記の結論に至ります。

  • 「プロジェクトマネージャとして業務や管理をメインに語れるロールモデル」よりも、
  • 「webエンジニアとして構造と処理をメインに語れるロールモデル

を目指そう。

入社当初はSIerとして技術を理解しているコンサルタントとして働きたいと思っていたのですが、情報技術は思いの外深く、より技術を語る道にのめり込んでいきました。情報技術を知れば知るほど、ITも知ってて経営を進められる人材から、技術特化の方向にグラデーション的に意識が傾いていきました。

5. (考察)本当にやりたかったことを判断する切り口

前章までWebエンジニアを目指す経緯まで述べました。ここからは考察となります。辞めると決断するにあたり2つの切り口が大きな判断材料となりましたのでご参考までに読んでいただければと思います。

人が組織(会社)に属し続けたいと思う基準

やめようか悩んでいる時にtwitterを眺めていたら、会社に属し続ける基準についてのツイートを見つけました。下記の3点の内2点に魅力があれば人は会社に居続けやすい、ということを見て、納得感が強かったことを覚えています。

  • 仕事

私の場合は人と仕事が魅力がなくなってしまったと思っています。言い換えると、魅力というよりも上記の点が自分のイメージとミスマッチすると、辞めやすいとなるかと思います。

△人: はじめは情報理系出身の院生だとか、上級のSEの方だとか、優秀でITについて詳しかったですし、追いつけないんじゃないかと思っていました。ただ3年も4年も勉強を続けていると、ある分野では「あれ?私のほうが詳しいな。」と思うようになってきてしまった点が要因としてあります。 また、私の年代以上になってしまうと社内ではプロジェクトマネージャーのロールモデルを目指し始めるので、技術寄りのロールモデルが見つかりにくかったこともミスマッチになってしまった大きな要因かと思います。

△仕事: これは前の章までで述べたように構造を考えることが業務内容として少なくなっていったため、Webエンジニアとして処理と構造をメインに考える仕事に付きたかった、となります。

◎金: これは魅力的でありましたし、最後まで後ろ髪をひかれてました笑 このまま行けば普通に給料も上がっていきますし、正直高給取りとして裕福な生活も手に入れられました。

30歳という年齢

お金に後ろ髪をひかれながらも最後に退職の決め手になったのは、30歳という年齢です。 実は社内でも「処理と構造を考えるロールモデル」をずっと探したのですが、異動するコストや時期もありますし、異動したところで本当にやりたいロールモデルが見つかるのか難しいのではと判断しました。 また、転職市場を調査(エージェント、wantedlyでカジュアル面談、人材業界関連の友人と相談)してみました。今までプログラミングの業務経験のない私はWebエンジニアとしてレーンチェンジするにはかなりギリギリのライン(転職市場では不利)であることがわかりました。私の業務経験からするとコンサルタントやマネージャー職としては需要があるものの、Webエンジニアでゴリゴリプログラミングするというのは需要は相対的に少なかったです。

30代目前にしてここでほんとうにやりたいことをやらないとまた2・3年後も同じようなことで悩む、というG's academy時代の恩師の言葉もあり、年収がたとえ半分とかになってもやりたいことをやろうと決心します。目指したかった処理と構造を考えられるエンジニアになるにはレーンチェンジは今しかないと思い、退職の決断をします。

※この時はまだ転職先を決めておらず、退職を先にすることになりますが、その奮闘は後半で書くことにしたいと思います。

まとめ

長めのエントリを読んで頂きありがとうございました。最後に今回の内容を簡単にメッセージとしてまとめたいと思います。

  • 自分がどのような姿になりたいかというのは、経験を積む中で少しずつ解像度が上がっていく
  • なりたい姿ややりたいことの違和感はずっと残るので違和感は早めに解消したほうが良い
  • 30歳という年齢付近で決断が人生を大きく左右する



次回について

前編にて転職を決意した私ですが、その後を 中編 に記載したいと思います。 そして私は何をおもったのか、転職先を見つける前に先にNRIを辞めてしまいます。それが吉と出るか凶とでるのか。転職してプレイドに入るまでどのような転職活動を行ったのかを、次回は綴っていきたいと思います。


www.taihey-blog.com




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com