AWS reinventを快適に過ごすためのTips

f:id:m-sato-lvgs:20200108172806p:plain

こんにちは、msatoです。

12月1日よりはじまったAWS re:Invent 2019に、当社からは私を含むエンジニア2人が参加しました。

re:Inventでの学習効果を最大限に高めるために、快適に過ごすためのTipsを紹介します。

f:id:m-sato-lvgs:20200108173436p:plain

移動編

reinventは複数の会場があり、会場によってはバスで数十分かかります。 地図上はさほど離れていない用に見えますが、端から端までで約4kmあります。 (MGM GrandからEncoreまで、徒歩で約50分)

会場内もとにかく広いです。 移動で消耗しないためのTipsを紹介します。

歩きやすい靴は必須

re:Inventでは、とにかく歩くことになります。

日によっては、歩数が20000歩を超えたこともありました。 (日本人の1日あたり平均歩数は、約8000歩)

靴ずれや移動で疲れないために、歩きやすい靴必須です。

f:id:m-sato-lvgs:20200108173601p:plain

帰国日が一番多かったですが、reInvent期間中は平均15,000歩くらいになっています。

セッションはできるだけ同じ会場にまとめる

できるだけ移動を少なくできるように、予定を組むことをおすすめします。 会場間の移動で、30分以上かかることもあるので時間を無駄にしてしまいます。

有意義に過ごすために、日によって会場をまとめる・overfloowルームを活用するなどしたほうがいいです。

こまめな給水を心がけよう

周りが砂漠のため乾燥しています。 疲労をためないために、こまめな水分補給をおすすめします。

給水スペースは会場の至るところにあるので、活用しましょう。

宿泊編

ホテルは「ザ・ベネチアン/パラッツオ」おすすめ

「ザ・ベネチアン/パラッツオ」がおすすめです。

理由は、メイン会場だからです。

メイン会場では、Keynoteや前夜祭(MidnightMadness)が行われます。 単純に行く回数が多いと思われるので、宿泊先にしてしまえば移動時間を短縮できます。 (私自身も、期間中毎日1回は「ザ・ベネチアン/パラッツオ」行きました)

水の確保が大切

ホテルの部屋にも水のペットボトルがありますが、高いです。 また自販機もないため、水の確保が面倒です。

近くのドラックストアでまとめて買うのがおすすめです。 「WealthMart」「CVS」などで買うことができます。

1ガロン(約4リットル)の容器で買うとコスパがいいです。 初日に1人 1~2本買っておけば手間が少ないです。

同じことを考える人は多いみたいで、初日は売り切れてました。 できるだけ早めの時間に買いに行くことをおすすめします。

写真撮り忘れましたが、こんな感じです。

f:id:m-sato-lvgs:20200108173636p:plain

ポータブル加湿器を持っていこう

ラスベガスはとにかく乾燥してます。 私は1日目、就寝時に口の中が乾きすぎて起きました。

日中のパフォーマンスを低下させたいために、睡眠の質は確保したいところです。

タオルを濡らして加湿するのもいいのですが、最近は持ち運びに便利な小型の加湿器があります。

値段もリーズナブル(1000~2000円)なので、日本で買っておくことをおすすめします。

セッション編

予約できなかったセッションでも、当日並べば受けれる事が多い

セッションは事前に予約することができます。 しかし、人気のセッションを予約するのはなかなか難しいです。

「どうしても受けたいけど、予約を取れなかった」場合は、当日並んでみましょう。 当日席が用意されているため、並んでみると受けれることが多いです。

開始の30分~1時間前に行けば高確率で受けれます。 人気のセッションは、1時間半前くらいに並ぶのをおすすめします。

ハードウェア系のワークショップ受けてみよう

ハードウェア系(Deepracer、Deepcomposer、Alexa、IoT系)のワークショップおすすめです。

おすすめの理由は、2点あります。

  • 普段触る機会がない人が多いと思うので、刺激になる
  • ワークショップでハードウェアを貰えることがある

今回は、DeepcomposerやDeepracerがもらえたそうです。 (聞いた話では、昨年はAlexaとかももらえたとか。)

知識も増えて、帰国後も学習できるハードウェアが手に入り一石二鳥ですね。

f:id:m-sato-lvgs:20200108173701j:plain AWS Deepcomposer

セッションカタログはこまめに確認しよう

reInventの期間中もセッションやワークショップは追加されます。

追加されたセッションは一瞬で埋まってしまうこともあります。 こまめに確認して、受けたいセッションを逃さないようにしましょう。

new launch」とかでセッションカタログを検索すると見つけやすいです。

最後に

実際にreInventに行ってみて、知っていたら便利そうなことをまとめました。 快適に過ごして、reInventの学習効果を最大限にしましょう。

AWS Lambdaとストレージゲートウェイを使用したグローバルストレージの設計に参加してきました

f:id:m-sato-lvgs:20200108172806p:plain

こんにちは、msatoです。

AWS re:Invent2019のワークショップ「ARC313 Architecting Global Storage with AWS Lambda and storage Gateway」のレポートになります。

概要

企業は、AWSテクノロジーのベストプラクティスを使用して、オンプレミスとクラウドの両方で世界中の生産施設に資産を同期する方法を探しています。このセッションでは、AWS Lambda、Amazon API Gateway、Amazon Simple Storage Service(Amazon S3)、AWS Storage Gateway、AWS Directory Service、およびAWS Fargateを使用して、世界中の従業員のコラボレーションを可能にするサーバーレスグローバルストレージプラットフォームを構築する方法を学びます。

Companies are searching for ways to synchronize their assets to their production facilities around the world, both on-premises and in the cloud, using best practices with AWS technologies. In this session learn how you can use AWS Lambda, Amazon API Gateway, Amazon Simple Storage Service (Amazon S3), AWS Storage Gateway, AWS Directory Service, and AWS Fargate to build a serverless global storage platform to enable employee collaboration around the world.

スピーカー

Paul Roberts Rob Hilton Principal Solutions Architect , Amazon Web Services

レポート

構成図

f:id:m-sato-lvgs:20200108172846j:plain f:id:m-sato-lvgs:20200108172903j:plain

動画ファイルを格納できるグローバルストレージの構築です。

具体的にはアテナに動画編集者がいて、トロントから確認したいというケースでした。 (アテナは読み書きが可能で、トロントでは読み込み)

AWSのマネージドサービスを使用して、サーバレスで作ります。

使用するサービス

  • S3
  • 動画ファイルを置きます
  • masterとstudio(読み込み専用)というバケットを作ります(masterがアテナで、studioがトロント)
  • StorageGateway
    • クライアントからSMBでS3をマウントさせるためです
  • AWS Fargete  - フロント部分に使います
  • AWS API Gateway
    • リクエストを受けて、lambdaを起動します
  • AWS Lambda
    • masterにアップロードされた際に、studioのバケットにコピーします

まとめ

オンプレで作ったらかなり手間がかかりますが、AWSのサービスを使うことで簡単に作れました。 また、サーバレスのためコストや運用の手間もほとんどありません。

StorageGateway使ったことがなかったので、ワークショップで実際手を動かしながら作れたのはいい経験になりました。

グローバルストレージを構築する機会はなかなか無いと思いますが、このアーキテクチャは色々応用が効く気がします。

JAWS-UG 初心者支部#21 reInventReCap&LT大会で登壇してきました

f:id:m-sato-lvgs:20191220160236p:plain

こんにちは、msatoです。

reInventで学んだことのアウトプットのために、JAWS-UG 初心者支部でLTしてきました。

JAWS-UG 初心者支部とは

以下引用です。

AWSをこれから活用したい人や一緒に勉強する仲間が欲しい人を主なターゲットとしています。 AWSへの理解を深めていただくお手伝いをすることはもちろんのこと、みなさまがより楽しく学び、よりステップアップしていくためには不可欠となる、初心者支部の卒業→JAWSの他支部へと巣立つためのお手伝いをします。

イベント概要

12/6-12/6にラスベガスで開催されたre:InventのreCap(振り返り)と、LT大会が行われました。

JAWS-UG 初心者支部#21 reInventReCap&LT大会

登壇してきました「IAM Access Analyzer使ってみた」

f:id:m-sato-lvgs:20191220160328j:plain

reInvent期間中に発表されたサービス「IAM Access Analyzer」について話してきました。 資料は公開していますので、ご興味のある方は是非ご覧になってください。

伝えたかったことは以下です。

  • ポリシーの設定ミスによる意図しないアクセスを防ぐとことができるサービス
  • 無料で簡単に有効化できる
  • 「AWSアカウント作成時のやることリスト」に入れたほうがいいと思うほど、有用なサービス

最後に

「アウトプットしないことは知的な便秘」LTで度々出てきて印象的でした。 いい言葉ですね。アウトプットしなきゃという気持ちになります。

JAWS-UGではアウトプットの機会を提供してくれています。

特に初心者支部はLT初心者でも、発表しやすい雰囲気があります。 今回のようなLT大会もたまにやっているので、初めてのLTにおすすめです。

HRE(Human Resource Engineering)を提唱して開発リソースを整理する試み

Leverages Advent Calendar 2019 - Qiita 最終日を担当します。ITインフラの研究職からSREを経て、現職ではいつの間にかVPoEのようなことをやっています久松です。キャリアを拗らせて唸っているうちにこういうキャリアになった、と説明しています。

今回はHRE(Human Resource Engineering)と題しましてエンジニア組織のカタチとマネージメントについてお話させていただきます。昨今のエンジニア組織マネージメントの難しさに悩む方々は多いかと思います。組織図や開発関係者一覧、タスク量計算をしていて「何だこれは」と思っている方々も多いのではないでしょうか。私自身、VPoE的な業務に取り組むにつれ、ふとインフラエンジニアだったあの頃と似通った着想に至りました。組織図をCDPっぽく描くというのが今回の主テーマです。何故EMやVPoEといったソフトなスキルを持ったポジションが求められるのか、エンジニア組織運営の難しさを理解する一助になれば幸いです。

従来型の会社組織

データセンター(会社)の中で全てが収まっています。室温から空調まできちんと整えられています。オンプレミス環境のオペレーションに関わったことのある方は思い当たると思いますが、物理サーバのホスト名に拘ったりして可愛がりますね。落ちると悲しいし、涙します。

増設(採用)は好ましいことですが、ラック(会社の物理空間)に限界もあります。計画はしっかりとデータセンター管理会社(バックオフィス)と連携しておく必要があります。

サーバやプロセスの監視も必要です。異常発生時はその現場に駆けつけましょう。ハードウェア(フィジカル)・ソフトウェア(メンタル)・ネットワーク(人間関係)など様々な課題が有りえますので、それらを吸い上げる仕組みや関係性づくり(1on1等)が必要です。

f:id:t-hisamatsu:20191218201109p:plain
従来型組織

遠隔開発拠点

都内でのエンジニア採用が難しいと感じた場合、遠隔地で採用をかけるケースも多く見られます。海外でオフショアだったり、国内でニアショア、もしくは地方支店の一角を開発拠点にするケースもあります。その場合、意識すべきは意思疎通です。遠隔地に居る分、伝送遅延はありますので何往復も意思疎通するとその分ロスが発生します。何の機能を本社に残し、何を機能を外に出すのかが重要になります。社内組織として設ける場合は「外注感」「下請け感」が出ないようにしなければならず、機能ごと任せてしまうというのは一つの解法だと考えています。

f:id:t-hisamatsu:20191220185617p:plain
遠隔開発拠点

SES

正社員でまかなえない業務が発生した場合、SESが登場します。フリーランスだったり所属会社の正社員だったりします。契約単位は時間のケースが多いですね。さながらパブリッククラウド的な形。同じドメイン(社内)で稼働をお願いするためにDirect Connect利用のケースもあるでしょう。ALB(タスク分配)やCloudWatch(勤怠管理)も必要です。

f:id:t-hisamatsu:20191220185822p:plain
SES

請負、コンサル

機能を部分的に他社に依頼するケースもあります。アプリケーション開発を受託開発に出すケースもあれば、チューニングといったスポット依頼のケース、AI開発や分析のような専門性の高いケースもあります。

AWSで言うところのManaged Service利用のようなセットアップと運用を丸々委託するパターンもあれば、Facebook APIやTwitter APIなどをインターネット経由利用するように基盤に乗っかるパターンもあります。

重要なこととして障害・仕様変更・サービス終了などにより依頼先が(一時的にでも恒久的にでも)応答しなくなった場合、極力本番環境に影響しない形での実装と運用が必要です。私も前職ではFacebookベースのサービスのインフラを担当していましたが、先方都合の部分はいかんともし難いものでした。「他人の褌で相撲を取っている」という感覚を忘れてしまうと大事になりがちです。

f:id:t-hisamatsu:20191220185923p:plain
請負、コンサルとの契約

社内副業

俄に流行の兆しですね。新卒採用イベントにて他社さんの会社説明などを聞いていると「実は取り組んでいます」という会社さんがちらほら居られます。これはつまり外注という選択を取る前に社内の余剰リソースでタスクを消化させようという動きです。余剰リソースを有効活用という意味合いでは仮想化のようなものですね。

加えて弊社調査でも言及させて頂きましたが、若手エンジニアには限られた時間でできるだけ複数の経験を積みたい(複業)というタイムパフォーマンス志向が見られます。

余剰リソースの有効利用や、複業に応える解答としては肯定できる社内複業制度ですが、労務や制度的な難易度が高いです。実務的な観点で問題となるのは「タスクの切り分けとマネージメント」が挙げられます。

f:id:t-hisamatsu:20191220190021p:plain
社内副業制度

クラウドソーシング

タスクを細切れにして外部に依頼します。特にインフラを構築せずともリクエストを投げるとリザルトが返ってくる様はさながらLambdaです。ただしプロセスの信頼性は低く、タイムアウトする可能性もありますのでプロセス管理が重要となります。

f:id:t-hisamatsu:20191220190107p:plain
クラウドソーシング

(エンジニア)組織のミライノカタチ

経営層の視点で「働き方改革は誰のためにあるのか?」と問われると「メンバー層」を対象にしたものではないかと答えています。特に能動的な行動を好むメンバー層への働き方改革の影響は大きく、所謂自社メディアと呼ばれる企業、それも他社との比較がしやすいITベンチャー密集区ではその直撃を免れていないように思います。

あるスタートアップ事業さんでは正社員は数名のみが在籍し、タスク分解を徹底し、残りは全てフリーランスで事業展開をされています。出勤日は固定ではなく、カレンダーに稼働時間を登録して貰った上で消化していくというスタイルを取られていたりもします。稼働可能な時間(スキマ時間)に稼働するスタイルはスポットインスタンスと言えます。

経営目線で考えると会社とは何か(少なくとも社員数は重要ではなくなる)、正社員には何を期待し何を残すのかを考えなければならない時代に来ています。オンプレミスとパブリッククラウドのハイブリッド構成だとデータベースをオンプレミスに残すケースが多いですが、会社組織であれば事業イメージをカタチにする企画職や、開発管理をするPM業務が該当するかと思われます。こうした人達をどこから連れてくるのか、育てるかというのも課題となってきます。事業コンセプトだけが会社に残るケースもあるのではないでしょうか。

一方、メンバー視点で考えると働き方改革を前に「ええじゃないか」と踊るのではなく、前回記事の指名される理由が必要になってきます。自分の自己責任が叫ばれる時代の中、どの立ち位置で、時間・成果のいずれの報酬体系で、どう渡り歩いていくのかを意識しなければなりません。また、弊社レバテック事業においてもこうした流動性の高い不確実な時代の流れを捉えつつ、日本一の相談相手として歩まなければならないと考えています。

f:id:t-hisamatsu:20191220190127p:plain
タスク細分化による組織のミライノカタチ

最後に

働き方の多様化が進み、自社のみでの開発組織の完結が難しくなってきた現在、人的マネージメントは困難を極めています。だからこそEMやVPoEといったソフト面の職種が登場したのだと考えています。

こうしたデザインパターンに載せて考察していくとHRとSREで共通点が見つかったり、マネージメント上の課題が発見できたりするというのが今回提唱したHREです。インフラエンジニアの基本であるトポロジ図やCDPに倣って、自社の組織図を書いてみるのも一興ではないでしょうか。

今回は書くと棘のあることはあえて伏せているのでいつの日かあるかも知れない書籍化に取っておきます(DRとかオートスケーリングとかマルチクラウドとかクラウド移行とかリプレイスとか)。

qiita.com

FirestoreとLINE Messaging APIでチャットシステムを内製してる話 〜運用での学びを添えて〜

はじめに

はじめまして!
Leverages(レバレジーズ)Advent Calendar 2019 18日目担当の吉澤です。

普段は、看護師向けの転職サイトや社内システムの開発・運用などをしています。
今回は、LINEでの顧客対応に用いられるチャットシステムの構築についてと実際運用してみてどうなの?みたいなところを書いていこうと思います。

何作ってるの?

↓ざっくりこんな感じのやつを作っています。

開発に至った背景については以下の記事に書かれています。

markezine.jp

LINEのMessaging APIとFirestoreを用いて、社内のSFA/CRMシステムから顧客とLINEのやり取りができるような機能です。

以下、内製のSFA/CRMシステムを社内システムと略します。

構成

全体的な構成としては以下の様になっています。

サーバーサイド

まず、ユーザーがメッセージを送るとLINEサーバーからWebhookを受け取ります。受信時のメッセージの取りこぼしがあると、そもそものコミュニケーションツールとしての役割を満たせなくなってしまうため、ここは特に気を使わなければならない部分でした。
そのため、Webhookを受け取ったらペイロードをそのまますぐにキューに追加し、仮に後続の処理に問題があったとしても、ログから復旧できるような構成にしています。

サーバーサイドは慣れ親しんでいたという理由もありlaravelを利用しています。
キュードライバはAmazon SQSを使おうかとも思いましたが、当時SQSがFIFOに対応していなかったこともあり1回のみのメッセージを保証したかったのでRedisを利用しています。
後は順にキューから取り出し、Firestoreへの保存など受信時の処理を行っています。

クライアントサイド

次にメッセージを表示するクライアント画面ですが、ここはVue.jsとfirebaseのsdkを用いて、該当ユーザーのメッセージのcollectionをリッスンし、変更があればステートに追加していくといった割と一般的な処理になっています。
自力でWebSocket使って...みたいなことをしなくていいのでfirebaseほんと楽で便利ですね!

ただ当時、「Firebaseの読み取り超過で○百万円飛んでった 😇」みたいな記事が上がっていたのと、実際にリリース後どのくらいの読み取りが発生するかが予想しづらい状況であったため、ドキュメントの読み取り数には警戒していました。

そのため対策としてメッセージを20件ずつローディングするようにしたり、オフラインキャッシュを利用するなどして読み取り数を削減していました。今思うとFirestoreの無料枠も大きいのでそこまで警戒する必要もなかったかもと思っています。

通知機能

メッセージ受信時の通知に関しては、FirebaseCloudMessagingとServiceWorkerを使ってプッシュ通知をしています。
普段、通知許可を求められると不快に感じてしまうタイプではあるんですが、こういう利用用途が限られていてユーザーに使ってもらうことが前提の場合はサクッと実装できて便利だなと思いました。
社内システムにおいては、サポートブラウザが限定できる点や実装効率の面でもPWA周りの技術のメリットを享受しやすいのではないかと思いました。

ーーー

全体的には、このような構成で何とか一年近く運用できています。

加えてメッセージのやり取り以外の面でも、LINEログインを用いたオウンドサイトからの登録や定期的なメッセージ配信など集客面での機能追加なども行っています。

最近、LINE側でも頻繁に機能追加されているので、いろいろできそうで面白いですね😉

運用してみて

このプロジェクトにおいては、技術面以外でも多くの学びがありました。

まず、これまで顧客とのLINEでの連絡は通常のLINEを利用していました。
これを内製のシステムに乗り換えるとなると提供されていない機能があったり、実装工数などの兼ね合いでどうしても今まで出来ていたことが出来なくなる機能が存在します。
狩野モデル *1 でいうところの当たり前品質が「本家のLINEで出来ていたこと」に該当していたように思います。
当然、利用者からすれば不便に感じる部分があったかと思います。

また、移行において仮にLINEで出来ていたことを実現できていたとしても、それだけではただ代替性が高いだけで、移行コストの方が高く感じてしまうのではないかと思います。(自分に置き換えてもそうなので、w)

そのような状況の中で、社内システムの開発・運用において以下のような点が重要だと感じました。

背景・目的への理解

何か新しいものを導入する際にはその背景や目的を明確にすることはもちろん、それが現場の人たちの中でも共有され、腑に落ちているかが重要だと思います。

よく職種間のやり取りにおいて、専門的な用語でなく相手が理解しやすい言葉でのコミュニケーションを心がけようと言われますが、たとえ言っている内容を理解できたとしても、それがどのくらい重要であるかという温度感は担当する役割によって違っていたりします。
全員が納得するのは中々難しいかもしれないですが、そういった認識のギャップを埋めていく動きも必要であると感じました。

ただ納得してもらうために、不用意に決定を曲げてしまうと本来の目的から逸れていってしまうこともあるので、その塩梅は中々難しいように感じます。

実際にはチームメンバーが現場への説明、疑問や不安の払拭、改善要望に対する対応目処の伝達など、とても献身的に働きかけてくれたこともあり、理解が得られていったように思います。

エンドユーザーの視点を持つ

ここでいうエンドユーザーはサービスにおける最終的な顧客のことを指します。

社内システムの開発において、システム自体の利便性を高めるということはとても重要ですが、それが最終的にどうユーザーに還元されるのかという視点を持つことも必要だと思います。

例えば

  • システムのレスポンス速度を改善することによって、現場の業務効率が上がり、ユーザーへの対応速度が上がる

  • データを入力しやすくすることによって、今まで個人の中に埋もれていたような情報が蓄積されるようになり、ユーザーがより詳細な情報を得られるようになる

などのようなことです。

普段、開発をしていると目の前のタスクの消化だけに目が行ってしまったり、自分は何のサービスを作っているのかが分からなくなってしまう時があるので、立ち返るという意味でも重要であるように感じます。

また、担当の職域が違うとその担当内での視点に寄ってしまいがちですが、同じ視点で議論することによって共通認識が取れやすくなるように思います。

同じサービスを提供する者同士として、目的は共通であるという前提の理解と、お互いがユーザーの視点に立ち、何ができるかを一緒に考えていくという姿勢が重要だと感じました!

We Are Hiring !

レバレジーズでは一緒に働く仲間を募集しています!
創業14年目を迎え、より一層テクノロジーでの課題解決が求められるフェーズになってきたように思います。
技術での事業貢献、ユーザーファーストでのサービス作りなどなど、ご興味ある方、是非ご連絡お待ちしております!!

https://recruit.jobcan.jp/leverages/show/b01/7682recruit.jobcan.jp

*1:顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデル | wikipedia:狩野モデル

「横浜」に「開発拠点」作ってみた

はじめに

レバレジーズメディカルケア株式会社CTOの内田です!

横浜に開発拠点を作ってみたらイイ感じだったので書いてみました、興味ある方どうぞ!

本題

福岡など地方にサテライトオフィスなど聞く事も増えました。 IT会社(だけではないですが割愛)は東京に集中していて、これは諸説ある所だと思っています。

なので本社は渋谷スクランブルスクエアですが今回、横浜にも開発拠点を作ってみました

社長と拠点作成の話をしたあと「身体バキバキに鍛えたいッス!」と雑談してたら、 ここの本格的な筋トレ器具も何機か横浜に送ってくれる事に、オフィスはここの3F、キレイだし横浜駅も徒歩圏で、鍛えれるし、素敵です。

↓いきなりですがかわいい横浜拠点のメンバーたちw

それでは、実際に 横浜を選んだ自身とメンバーたちによる比較を感じたままに紹介します。

比較 (体感比)

通勤

渋谷本社への電車はギュウギュウなのに対し、横浜支店は逆方向だから空いています。横浜近郊に住んでいる人以外にもメリットがあるようで、朝の集中力はチームとしても大事にしているので嬉しいです。

賃貸相場情報をHOME'sで見てみました。(2019/12時点)

渋谷駅

不動産・住宅情報サイトLIFULL HOME'S - 渋谷駅の家賃相場

  • 1K 12.13万円
  • 1LDK 28.08万円
  • 2LDK 51.59万円

横浜駅

不動産・住宅情報サイトLIFULL HOME'S - 横浜駅の家賃相場

  • 1K 8.61万円
  • 1LDK 14.11万円
  • 2LDK 21.69万円

駅付近の相場だと思いますが参考にはなりそうです、思ったよりもすごい差でした。(横浜駅から一本離れれば更に安いですがそこは一旦割愛)

入外出 (出勤やランチ)

渋谷

どこを歩いても人が沢山でお店も混みがち、エレベーターもなかなか来ない。色々と待ったり混雑が多めです。

横浜

意外にも平日は混まなくて、エレベーターもすぐ来る。色々と待たなかったり混雑が少なめです。

まとめ

総合した効果として皆がいうのを要約すると以下、

  • 集中力が上がった
    • 通勤コストの削減と、スモール化による周りの目の減少と考えています。
  • 会社への好感度が上がった
    • 働き方の多様化に応えて貰えたことや、この総合点の高い環境に感謝しているのかも。

これがQoLの重要性なのだと感じる日々です。

オマケ

スカイスパのコワーキングスペースでの1on1

スカイスパに仕事上がりに徒歩数分で行けるのも最強ポイントですw

ちなみに、プロサウナー達の厳正な審査による"今行くべき全国のサウナ11選"で6位の施設がスカイスパです。

ぜひお試しあれ!

エンジニア生存戦略論と、生存に向けての場の提供

メディアシステム部 部長の久松です。

今回のテーマに関わってくるので自己紹介させて頂きますと 2000年からIT革命真っ只中のIT業界にインフラの研究開発から入り、20年が経とうとしています。

  • 20代 大学教員を目指す
    • インターネット動画配信、P2Pをテーマに研究員として活動
    • 博士進学翌年にリーマンショック、その後 事業仕分け・震災
  • 30歳 学術からビジネスへの転身
    • 博士取得と共にポスドクのポジションが無期延期になり、就活も難航し、就職課に「進路未定」で提出
    • 高学歴ワーキングプアとしてアルバイトプログラマに(額面で月給15万円)
    • ベンチャー企業に就職後、やがてインフラ責任者をやりながら気がつけばリクルーターに
  • 現職への転職
    • エンジニアの取りまとめの役割ですが、ほぼVPoE
    • エンジニア紹介事業のレバテックでは技術顧問としてエージェントの専門性向上を担当
    • エンジニアキャリアに悩んだり採用したりするうちに新卒・中途採用、オンボーディング、新卒・博士キャリアをテーマにしたセミナーをするようになる

今回は私が現在、レバレジーズ社員やエージェント教育の過程でお話しているエンジニアの生存戦略とその機会提供についてご紹介させて頂きます。

エンジニアを勤め上げるにあたっての脅威

人生100年時代と言われている中、年金の支給タイミングの後ろ倒しを加味すると80歳程度までは 何かしらのキャリアチェンジ・ジョブチェンジを繰り返しながら行きていく必要があります。 特にITエンジニアとしては

  • 技術トレンドの移り変わり
  • AIによる自動化
    • Sketch2CodeだったりAmazon CodeGuru Reviewerだったり足音は聞こえますね
  • 「巨人の肩の上」に乗ったできる若手
    • 構築がスムーズな開発環境、溢れる教材、溢れるソースコード、QA環境・・・
  • 海外からの高度人材
  • フリーランスやクラウドソーシングの一般化による有期のスポット人材の増加

を考えなければなりません。

生き残りやすいエンジニアの特徴

私自身が事業仕分けられたということで需要の底を経験したということもありますが、20年の間に

  • ITバブル
  • クラウドバブル
  • SNSバブル
  • ソーシャルゲームバブル
  • AIバブル

と各種のバブルと共に数多くのエンジニアの栄枯盛衰を見ることができ、生き残りやすいエンジニアの特徴が見えてきました(図)。 これを意識し、メディアシステム部のエンジニアには様々な機会に挑戦してもらっています。

エンジニア生存戦略

ベースとなる基礎知識

計算機の基礎、インターネットの基礎が挙げられます。特にインターネットの低レイヤについての知識はJavaScriptのフレームワークのようなハイレイヤーの技術に比べると革新速度はゆっくりですし、パケット交換方式は当面続きそうなので臆することなく身につけておくことをおすすめします。

専門性 2つを時流に合わせて変化

ヒトとは基本的に怠惰なものなので「可能であれば身につけた一つの技術で生涯食べていきたい」と思いがちです。 ただIT業界とは無情なもので5年程度でパラダイムシフトが発生し、身につけた技術は骨董品になります。 加えていかにも流行りそうな顔をして近づくバズワードというのもあります。

どちらか一方の専門分野が廃れても良いように2つの専門性、加えて時流に合わせて変化させることが必要です。

コミュニケーション力

他業種とのコミュニケーション力です。よくあるできるエンジニアの凋落パターンとして、

「いつも何をやっているのかよく分からないし、何を話しているか分からないし気難しそうなので話しかけにくいけど流行りの技術を身に着けているらしいので今は仲良くしておくと得だ」

と、周囲に思われているうちは需要があるものの、流行の終焉と共に周りから人が居なくなるというものです。

いざというときに周りに助けを求めるためにもコミュニケーションは取りましょう。転職してもフリーランスになっても繋がりは役に立ちます。

リーダーシップ、マネージメント、プレゼンテーション、教育、採用より2つ以上

いくつか補足をしておきます。

プレゼンテーション

プレゼンテーションはブログの投稿でも構いません。その人が何をしているかを自分以外に積極的に知ってもらう術を持っているかということです。

短期的には予算の出どころに対する説得や説明に繋がります。中期的には「指名をもらう」ことに繋がりますし、怠ると控え目に表現して「忘れられてしまう」ということになるケースも多くあります。  

教育

教育は自分の持っている技術や知識を後進に伝えられるかどうかです。特に知識の更新の早いIT業界では、知り得た事柄をまとめて周りに拡散していくという能力が強く求められるようになっています。

採用

採用はチームビルディングに繋がります。人材不足という中でどれだけ自分の属している組織に勧誘し、人を引き込むことができるかというスキルは年々高まっています。

まとめ

1990年前後の金融バブルを解説する専門家の間でも目にしますが「バブルの中に居る人はバブルだと思わない」と仰っしゃります。先に述べたIT界隈のバブルの中の人も、永遠の需要と反映を信じている人が多く居ましたが、今のエンジニア売り手市場もバブルですし弾けてから改めて認知されるでしょう。

良いのか悪いのか分かりませんが80歳まで労働しなければならないと仮定した場合、ジョブチェンジやキャリアチェンジを想定して生きなければなりません。   一つのヒントとして「これは自分の仕事じゃないな」という仕事が目の前に現れたとき、それを受け入れるか拒否するかというのが分かれ目になるのではないかなと考えています。

Engineering Manager vol.2 Advent Calendar 2019 qiita.com