2020-08-27

コロナ禍でリモートワークやってみてそろそろ半年なので振り返ろう

エンジニアリモートワーク

いつからやってるの？

自分の会社は反応よかったので２月初旬からリモートワークしてます。
コロナのニュース出た直後くらいに怖いから一応リモートワークに切り替えたいって伝えたら即日OKでるスピード感はうれしかったですね。

やってみて０〜１ヶ月目

普通に出勤時間がなくなったので快適に業務しつつも机と椅子がうーん。。。合わない、、、
あとディスプレイもほしいなー
でも、睡眠時間確保しやすくなったのサイコー！！

２〜３ヶ月め

会社からリモートワーク補助が出たので椅子を買い替え！
ゲーミングチェアにしたのでオフィスよりいいかも！
拡張ディスプレイも会社が買ってくれたのでいい感じになってきた！
業務的にはまだ個人のタスクをすすめるメンバーが多いので影響出てないな！

４〜５ヶ月目

うーん。。。思ってるよりチームの進捗出てないけどなんでだろ？？
→オフィスにいたときは横の席の人にちょっといいですか？って質問できたのにできてないからか！
→あと、ホワイトボードつかった認識合わせ出来てないから、認識合わせ用のドキュメントを都度作るコストが増し増しになってる！？

６ヶ月目（いまここ

上期が終わるから評価準備しないとなー
顔合わせてたときは声掛けして進めながら資料の状態とか確認して進められたけど、リモートだとなかなか難しいな。。。
わざわざ資料確認で声掛けしてオンラインMTG開くの心理障壁高いな。。。

今やってるチャレンジ

リモートワークは個人プレイはしやすいですがチームプレイにはまだまだ課題がある状態なので日々、改善策を考えて実施して振り返っての繰り返しです。
例を上げると

ホワイトボードの代用→figmaで代用してみる
会話するのにいま通話つないでいいですか？って言うの辛い→Discordで部屋作ったので勤務中は基本つないでおこう！（雑談はもちろんおｋ！
評価どうしようかな。。。→定期的な１on１で情報キャッチアップ

立ち話で住んでいたことが時間確保してMTGになってるので時間がかかるようになってきてるのがリモートワークでのネックですね。
コミュニケーションコストが上がることで認識齟齬や共有漏れ、心理的距離が遠くなるという悪循環をうまないために何をするべきか、何を使うべきかという課題と向き合うのが今後、下半期に向けてやるべきことなんだろうなーという感触です。

別の記事でも書いたのですが、やはりリモートワークは働き方改革の銀の弾丸にはなりえないなというところでしょうか。。。
そもそも銀の弾丸なんてないと思いますがｗ

リモートワークは用法用量を守って使いましょう！

2020-07-20

このご時世の有給消化はどうしよう。。。

働き方仕事リモートワーク

07/20,21,22を休めば９連休だな〜と思いながら本日（07/20）もリモートワークで働いております・・・
まあ、事業会社所属のバックエンド系エンジニア（最近はマネジメントの仕事がメイン）なので夏のキャンペーン的な準備や期の境に向けた準備で休めないのですがｗ

でも、コロナ禍のご時世で長い連休をつくっても遊びに行けないしなーとも思ってしまいます。。。
自分はロードバイクなどが趣味なのですが、たまに乗るときも

お店には基本的に立ち寄らない
水分補給は自動販売機で
人の多い道は通らない
マスク（ぽいもの）は外さない

などいくつかマイルールを作って走ります。
でも、やっぱり遠くまで行ったならご当地のお店に入りたいなー（と遠くからグーグルマップを見て思ってしまいます）＞＜
コロナ落ち着いたらまた来てそのときこそお店入るんだ！って気持ちで下見旅みたいになってしまいますね。。。
※そのときまでお店が続いていられるようにあとで通販とか探すプレイが板についてきましたｗｗｗ

有給の消化が義務化されてそんなに経たないうちにこの状況なのですが、消化の仕方で今のご時世でも考えられそうなものってなるとやはり

身体と心をやすめるためにごろごろするのだー
今週は５日も働きたくないぞ！

ってときにうまく使うのが良い気がします。
あとで長期連休にしたいからとっておこう！なんて言っているとすぐに消滅してしまいますしね（汗
※自分の周りにもけっこうそんな人がいます

ちなみに自分は月に１〜２日程度、用事がなくても有給とって家の掃除してたりゲームしてたり昼寝で潰したりと贅沢かな？って思うような消化の仕方にしています。

適度に働いて、適度に休むことも大事ですよね

2020-06-17

コロナになってからのコミュニケーションで思ったこと（気をつけよーって思ったこと）の箇条書き

仕事リモートワーク

どうしてもドキュメントベースになってくるんだけど、読んだ上で○○って解釈したけど認識あってます？ってとこからスタートしないと考えの押し付け合いになる気がする
↑が発生するとお互いに引くタイミングを逃すから収集つかなくなる
「○○って解釈したけど」って部分が割と重要でそこがないと読んでないORチラ見したけどこれってさーくらいで軽視されてる（してる）感が出てしまいよくない
「○○って解釈したけど」って部分が割と重要でそこがないとどんな解釈・理解をしているかがわからないので会話が成立しない可能性がある（お互いに）
認識のすり合わせをしてから「その場合、○○もいいと思うんですけどどうです？」って提案の流れのほうが話が進めやすい
知らない背景とか周辺がある率がオフィスにいたときより上がっているので（たまたまそばにいるから聞こえる系がない）自分がいいと思っていることをゴリ押しすると相手が不快になるって意識しておいたほうがよい
自分は背景とか周辺を知らないという意識で会話したほうがよいし、そのあたりがわからないと感じた瞬間にちゃんと聞くほうがよい
Slackのみでやり取りすすめるのは温度感がわからないので地雷を踏む場合もある
相手の求めているもの（回答）はなにかをきちんと確認してからコミュニケーションを進めないとお互いイライラする
自分の出す正解は相手にとっての正解ではない可能性があることをきちんと留意する（正義の見方にならないように気をつける）
相手の求めている部分より踏み込むときはどの程度まで踏み込んでも相手がイライラしないのか測りながらにしない話が破断になる可能性がある
ホワイトボードがあると話しながらそれを書き出してあとで写メを共有するというのができたが自宅だとそれができないので議事録とその回付は必須だと考えたほうがあとが困らない
コミュニケーションロスはお互い様、相手を一方的に悪く思わない・言わない、責任は全員で均等按分
所属（チーム）外とのやりとりは聖戦（ジハード）を起こさないように留意する、よかれと思っての行動でも聖戦の火種になりうるので注意する
※聖戦（ジハード）に関しては参考リンク参照

最後に、、コロナ関係ないけどイニシアチブの取り合い発生させるのはいくない。。。

参考：

eiki.hatenablog.jp

2020-06-15

リモートワーク（在宅勤務）してて必要だなって感じたもの

仕事リモートワーク

前提

自分はエンジニアとして開発業務をリモートワークで行っていますのですが、自宅でパソコンの前で仕事するという部分だけを前提で書いています。

最優先（MUST）

１．机
２．椅子

作業机はじゃまにならない程度で椅子を利用できる高さがあるものをおすすめします。
作業時の意識の切り替えもしやすいので座卓よりもお仕事する感が出ると思います。
自分はちなみにこんな感じのを使っています。仕事に必要な書籍なども管理しやすいのでおすすめです。

オーエスジェイ(OSJ) パソコンデスク左右入替可収納両用デスクブラック 112.5×50×121×78cm

メディア: ホーム&キッチン

自分は幸い作業机は前々から副業用に購入していたので今回は椅子を購入しました！
ちなみに会社のオフィスではアーロンチェアを使っていましたが、、、正直自分の体感ではゲーミングチェアのほうが腰に負担ないし楽ですね。。

GTRACING ゲーミングチェアスピーカー付きオフィスチェアデスクチェアゲーム用チェアリクライニングパソコンチェアハイバックヘッドレストランバーサポートひじ掛け付き PUレザー (GT890YJ-RED)

メディア:

[正規品] ハーマンミラーアーロンリマスタードサイズ:ミディアム/アームパッド:ビニール/フレーム:グラファイト/ベース:グラファイト/キャスター:カーペット用 AER1B23DWALPG1G1G1BBBK23103

メディア: ホーム&キッチン

自宅の作業部屋が個室なのでスピーカーで音楽流しながら作業してるとストレス軽減もできるのでいい感じです！
オフィスではできないことなので自分のスペース感が出てとてもよいです。

あるといいな（MORE）

１．拡張ディスプレイ
２．外付けキーボード

会社からの支給PCを持ち帰っている場合はノートPCであることが多いと思います。
ノートPCだと正直画面が見づらいなーなんてときは拡張ディスプレイをおすすめします。
最近は場所をとらないモバイルディスプレイも販売していますので検討の余地は十分にあるかと！
ちなみに自分はこれを使っています。
利用しているのが13インチのMacbookproなので大きさ的にも大体同じくらいのディスプレイが横に一つ増える感じになります。

モバイルモニター EVICIV 最新版モバイルディスプレイ 15.6インチゲームモニター IPS液晶パネル薄型軽量 USB Type-C/標準HDMI/mini DP スタンドカバー PS4/XBOX/Switch/PC/Macなど対応 EVC-1506

メディア: エレクトロニクス

外付けキーボードは拡張ディスプレイを使った際に両方のモニタを同じ距離感で使うためにあったほうが便利です。
顔を横に動かす必要なく両方のモニタを等間隔で見ながらキーボード入力ができるので便利です！

きっと今後こうなるのかな？予測

このまま、リモート勤務が常態化する業種や企業が増えてくるとライフワークバランスの考え方が変わってくるのではないかと感じています。
「月に数回オフィスに行けばいいや」「週末などに遊びに都心に出れればいいや」となってくると出勤しやすい場所に住もうという考え方から住みやすくて過ごしやすい場所に住もう！となってくるのではないでしょうか？
現に自分の周りでもリモートワークするにはちょっと手狭なので引っ越ししようって声も多く聞きます。
そろそろ住みやすい場所の取り合いが発生するかもしれないですね。

2020-03-26

cloud frontとlambda@edgeでUA判定をしてPCページとSPページを出し分けてみた

AWS Lambda サーバーレス

Qiitaに出してた記事ですが、Qiitaそのものが炎上してるようなのでこちらにも同じ記事を展開

cloud frontとlambda@edgeでUA判定をしてPCページとSPページを出し分けてみた

Webサービスを構築する仕事がきたのですが、ビジネスロジックが不要なサービスだったのでできるだけカンタンに作ろうと思いサーバーレス構築に挑戦してみた際にやってみたレポートになります。

使ったAWSのサービス

cloud front
lambda（ ＠Edgeはバージニア北部リージョンで関数作成する必要があります ）
S3
Route53（ドメイン設定の話なので今回は特に登場させません）
ACM（SSL証明書の話なので今回は特に登場させません）
Cloud Watch（lambdaを利用したら自動でついてきた）

やったこと

S3にHTMLを配置
cloud frontとS3を紐付け
ドメインにアクセスした際にどのHTMLを出すか設定（トップページの設定）
lambda@edgeにUA判定処理を実装
lambda@edgeとcloud frontの紐付け（トリガー設定）今回はViewerリクエストをトリガーに設定

ざっくり動くまででだいたい２〜３時間くらいでできました。

lambda側に設定する必要のあるポリシーの信頼関係※記載わすれてたので追記しました（2019/07/10）

アクセス権限はS3とCloudFrontによしなに設定してあげてください。お手軽にやるならフル権限つけてしまってよいかと思います。

~~~ { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "Service": "edgelambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ~~~

1〜３はいろいろなところに記事が落ちているのでlambdaのソースと引っかかったポイントを紹介します。

lambdaに実装したソース

~~~javascript 'use strict';

const whitelist = [ 'android', 'iphone', 'ipad' ];

const isSpBrowser = (uas) => { if (uas && Array.isArray(uas) && uas.length > 0) { return uas.some(ua => whitelist.some(w => ua.value.toLowerCase().indexOf(w) !== -1)); } return false; };

// User-AgentからPC・SP判定を行ない描画ページを切り替える exports.handler = (event, context, callback) => { const request = event.Records[0].cf.request; const headers = request.headers;

// console.log('headers.user-agent. = ' + headers['user-agent']);
if (headers['user-agent']) {
    // URI整理
    // cloud frontにトップページとして設定したindex.htmlがURIに入ってくるので除去
    var uri = request.uri.slice(-10) === ('index.html') ? request.uri.slice(0, -10) : request.uri;
    uri = uri.slice(-1) === ('\/') ? uri : uri + '\/';
    console.log('headers[user-agent] = ' + headers['user-agent'][0].value);
    // URI判定
    // ファイル読み込みで呼び出された場合中断
    if(uri.match(/(　\.png|\.css|\.js|\.jpeg|\.jpg|\.bmp|\.gif|\.pdf|\.svg|\.zip)/)) {
        callback(null, request);
        return;
    }
    // UA判定
    if (isSpBrowser(headers['user-agent'])) {
        uri = uri + 'SP用描画ファイル名'
    } else {
        uri = uri + 'PC用描画ファイル名'
    }
    console.log('uri = ' + uri);
    request.uri = uri
    callback(null, request);
    return;
}
callback(null, request);

}; ~~~

PC/SPの判定においてはこういう書き方もできます。（というか今はこっちのほうが推奨されてます） ※下記ソースで行う場合トリガーをオリジンリクエストイベントに設定する必要があります。（ビューワーリクエストイベントの後に CloudFront-Is-*-Viewer ヘッダーを追加されるため） ※Whitelist HeadersにHostsを混ぜるとS3へのリクエストはCloudFrontが署名を行う形になり想定外の挙動になる可能性があるので要注意

javascript // UA判定　前述コードのUA判定部分と置き換える if (headers['cloudfront-is-desktop-viewer'] && headers['cloudfront-is-desktop-viewer'][0].value === 'true') { uri = uri + 'PC用描画ファイル名' } else if (headers['cloudfront-is-mobile-viewer'] && headers['cloudfront-is-mobile-viewer'][0].value === 'true') { uri = uri + 'SP用描画ファイル名' } else if (headers['cloudfront-is-tablet-viewer'] && headers['cloudfront-is-tablet-viewer'][0].value === 'true') { uri = uri + 'SP用描画ファイル名' // タブレットでSP画面で見せる場合 } else if (headers['cloudfront-is-smarttv-viewer'] && headers['cloudfront-is-smarttv-viewer'][0].value === 'true') { uri = uri + 'PC用描画ファイル名' // SmartTVVでPC画面で見せる }

参考： https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-device

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-redirecting-examples

ポイント

ログはCloud Watchに出力されるがアクセスされたcloud frontのリージョンに出力されたのでlambdaを配置しているリージョンではない
ドキュメントは基本英語版が正
トリガー設定はlambda側からやるほうがらく
困ったら迷わず有料サポートを使う（結果そのほうが早いのでトータルでの費用が下がる）

最後に

イベントページなどの後ろにビジネスロジックがいらないサービスであればこの構成は結構おすすめできると思います。インフラ作業部分（エンジニアが必要な作業分）は大体５人日程度で収まったのでその分デザインやプロモーションにコストがまわせるのも強みかと ※初回なのでこれくらいですが慣れればもっと短くなる予感

2020-01-23

12/31〜1/10くらいまで倒れました。。。

仕事

大晦日の夜に急に熱がでて元旦にメディカルセンターに行ったのですが、、、
検査してもインフルではないし、、風邪？って診断されたのですがそのときに「血液中の酸素がめっちゃ少ないけど疲れてる？」って聞かれました。
まあ、忙しいし疲れてますね〜なんて言って薬もらったのですが、どんどん悪化する一方で。。
5日くらいには横になって寝ると気道から変な音がするようになって席が止まらず呼吸ができずで眠れず。。。
かかりつけの病院にやっと行けたら「喘息って診断したことあったっけ？」と言われレントゲン撮ったら「肺が炎症起こしてるね〜。。点滴打っていこうか」となり
点滴を打ったのですがそれから2日くらいほぼ改善せず。。
耳鼻科に行き、鼻と痰を取ってもらってようやく呼吸がすこしできるようになりました。。。

振り返ってみると疲れすぎてて薬も点滴にも身体が反応しなかったんだろうな〜と遠い目になりました。。。

繁忙期とは言え働きすぎには気をつけましょうね！

2019-11-08

最近チャレンジしてる(したい)ことのはなし

普段とは毛色を変えて、最近チャレンジしてる(したい)ことをつらつらと、、、

1.お絵かき

小さめのスケッチブック買ってちょいちょいお絵かきしようとしてまする。

あと板タブも買ったので

頭の中を発信するために書き出す訓練というのもありますが、純粋にお絵かきしたい。。

絵の練習やイラストの練習方法漁ってたりしますね。。

2.フォトショップの使い方覚える

ちょっと前から触ってるんですが、、

横文字多すぎてつらたん。。

なので感覚で触ってるのでそのうちちゃんとマニュアルとか読まねば！というのと教本読まねば！というお気持ち

3.カメラ

ちょっと前にミラーレス一眼のカメラ買ったのでもちっと構図の勉強とかしたいなーと、、

簡単な勉強しかしてなかったのでカメラの機能使いこなせてない気もするし、、、

あとはちゃんと撮った写真の加工できるようにフォトショップの勉強しないとなー、、

4.髪の色を変えてみた

黒→金→白金→オレンジ→アッシュ(いまここ)

職場がフリーダムなのでいろいろやろーという感じです。

5.ボイトレしてみたい

カラオケ好きなのでボイトレとか歌の勉強したいなー

勉強の仕方調べ方もわかってないけど、、、

6.お仕事は、、

今年度分の年収分の仕事量はとうに超えてる気がするのであとは趣味くらいに思って流してまする。

それでも日々仕事が増えるけど、、、

依頼から1月くらいでのリリース案件とかちょいちょい投げ込まれる。。

もうベテラン勢が少ないのでお気持ちはわかるんだが、、自分マネジメントしてる割に新卒に毛が生えたくらいしか給料もらってないからね、、、

調整から開発、テスト、リリースを一人でこなす案件多すぎ、、、

マネジメントしてるチームはそれはそれで大きい案件任せてるので差し込みたくないしな、、、

7.婚活、恋活

pairsは合わなかった

Omiaiも合わなかった

いまはwithやってみてる

とりま、、、異性って難しい。。。

彼方の女と書いて彼女と言った加地さん(eva)のお気持ちを最近理解。。

でも、彼女欲しい。。。

いや、かわいいなって女の子はいるんですけどね、、、声のかけ方がわからん。。

8.動画編集

教えてもらってお仕事できるようにする流れを取ってまする。

はやく覚えたいなー

9.副業

ちょこちょこいろんなことやってる

講師とかアドバイザーとかで使ってもらうのがよいかな

さて、年末も近いけどいろいろやってこー

11月の大洗のあんこう祭は凸る予定なので楽しんみ！！！

2019-09-19

SEO超入門の講義をしたときの内容

エンジニア SEO

運用さんや営業さん、人事部さん向けにざっくりとしたSEO入門話をやったのでその時の内容を公開します。

SEOってなんのこと

SEOとは、”Search Engine Optimization” の略で
検索エンジンに最適化することを指す単語です。

2019-09-06

評価のときの資料作成のコツ（個人的な）

仕事社会人

そろそろ多くの会社が上期評価の時期かな〜ということで評価のときに上長に提出する資料作成の個人的なコツをざっくりまとめてみます。
（これはツールを使ってるとかExcelだからとか関係ないコツになります）

書くタイミングの話

普段の業務で作るメモをそのままコピペできるように書いてしまうのが一番楽ができる方法だと思ってます。
ブックマーク機能使わないようにしてリンク集作っておいたり案件終わるたびにメモを評価用のところにコピペしてためておいて提出のタイミングで整形だけするとしておくと評価提出用の作業が最小限になるのでストレスも少なくすみます！

まあ、普段からタスクメモ作ってその中にリンク入れとくって癖を付ける必要はありますが、定期的に評価資料作らなきゃ〜！！って慌てなくていいので楽ができますし、過去案件の問い合わせのときとかにも作っておいた資料が利用できるので楽ができますよ

書くときの話

同じ案件に携わってた人やチームの人と一緒に書くのがよいです。
自己評価なんだから一人で書かなきゃ！っていうのは思い込みなので誰かと一緒にかいて互いに「コレやってたよね」「こう書いたほうがわかりやすくない？」「コレ書いたほうがいいよ」って話をしながら書いたほうが大体お互いを肯定しながら書けるので気持ちも下向きにならずに書けます。

自分はチームはメンバーが書くときにはリーダーの自分を捕まえてもらって一緒に書くことが多いですが、そのあたりもリーダーのお仕事なので全然OKってしてます。
そうやって書いてると自分が把握してる中でメンバーが書いてないなってことは伝えて書いたほうがいいよって伝えられますし逆に自分が把握してない部分も早めにキャッチアップできるので評価のタイミングの一発勝負にならないので助かります。

もんもんと一人プレイするとストレスになっちゃうなーって自分は感じてるのでそうならないようにして且つまだ提出しているわけではないので気をはらずに話しながら書くのが良いと思います。

と上期も終わるのでざっくり評価提出資料の自分なりのストレスレスな書き方をまとめてみました。

2019-08-22

最近よく作るAWSのインフラ構成図

AWS エンジニア lightsail

ちょこちょこ実際の事業上の都合で必要になって作るAWSでの構成があるので公開しておきます。

オンプレとAWS環境を同じドメインで共存させたい

特定ディレクトリはAWS、別のディレクトリはオンプレ（現行のサーバー）などの構築が必要になることがあったのでその時につくった構成はこんな感じです。

f:id:pergere:20190821173637p:plain — オンプレ＋AWS構成図

オンプレ環境にはCloudFront経由でしかアクセスをとおさないようにすることでキャッシュとかをある程度使えるようにしつつも今後オンプレの部分もAWSや他のクラウドに載せ替えたいといった際にはCloudFrontのビヘイビアの差し替えをすることでメンテ時間を短くできるなどがありますので順次AWSに移設していくなどもできるかなと思ってます。

lightsailを使ってCloudfrontも使いたい

lightsailを使って定額でWordPress作りたいけどlightsailの前にCloudFrontを配置してキャッシュをうまく使いたいなんて場合の構成はこんな感じにしました。

f:id:pergere:20190822173813p:plain — lightsailとCloudfront使ったインフラ構成

カスタムオリジンを使うことでオンプレの時同様にCloudFront経由のアクセスにしています。
lightsail自体にもDNSゾーンの機能があるのですがそれを使うとCloudFrontをうまく設定できなかったので現状はこのような構成にしています。

ちょいちょい、依頼主の現状の都合で作るパターンが溜まってきているので今後もある程度溜まったら構成図にしていきたいと思います。

2019-07-10

cloud frontとLambda@Edgeを使ってリダイレクト設定入れるやりかた

AWS サーバーレス

配下のWebサーバーではなくcloud frontとLambda＠Edgeでリダイレクトしたい

意図としては配下のEC2なりにアクセスを通してWebサーバー（nginx、Apacheなど）でリダイレクトするのではなく上位層でリダイレクトすることでWebサーバーへ不要なアクセスをさせない良いにしておきたい。

やりかた

①リダイレクトさせたい（アクセスさせたくない）URLをcloud frontのビヘイビアに設定する

[Behaviors]タブにてCreate Behaviorを押下
[Path Pattern]に"/hoge/*"みたいな感じでドメイン以下のURLを記載する
※ほか項目はよしなに入力して保存

②Lambda関数を作る

リージョンは バージニア北部 を選択（＠Edgeとして利用するため） IAMロールはアクセス権限はよしなに設定し信頼関係は下記で作成

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "edgelambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

コードの内容は下記を入力し保存する

'use strict';
 
exports.handler = (event, context, callback) => {
    const response = {
        // 用途に応じたhttpステータスを記載する
        status: '308',
        statusDescription: 'Permanent Redirect',
        headers: {
            location: [{
                key: 'Location',
                value: '飛ばしたい先のURLを記載',
            }],
        },
    };
    // リダイレクト用レスポンスを返す
    callback(null, response);
};

新規バージョンを作成し先程設定したcloud frontに紐づけし
イベントタイプは origin-request
パスパターンに先程作成したビヘイビアの[Path Pattern]に設定したものを選択
ボディを含めるはいいえで保存します。

基本これでリダイレクト設定完了です。

ひさびさにサーバーレス関連の記事を書いてみましたｗ
最近コード書いてなかったですがコード書くと楽しいですね！

2019-06-10

退職エントリをどう受け止めるべきだろうか？

仕事社会人退職エントリ働き方

最近ちょこちょこ退職エントリなどが話題になっているのでそれについて思うところをまとめてみました。

そもそも退職エントリってなんなのか

個人的な所感ですが退職者が内外に向けた遺書的なものかなと思ってます。
なので

もっとこういうことができたんじゃないか？
もっとこうしてほしかった！
残していく人たちへ

というような内容が多いと思っています。
総じて、退職者が最後に企業・組織に対して遺す最後のメッセージ・最後の未練やこうだったらという希望を綴る内容になっているものが多いと認識してます。

なんでこんなに話題になるのか

これは、前述にも上げた内容の中でも「もっとこうしてほしかった」という部分が大きい場合がピックアップされて取り上げられやすいからだと思います。
人の不幸は蜜の味じゃないですけど、人の不備を見て共感したり・便乗したりするというのは自分はリスクをおわず正義の味方面ができるので気分良くなりやすいですしね（個人的にはかっこ悪いと思いますが）
インターネットの匿名性の負の側面が発露した結果じゃないかなぁ、なんて思ってます。
※ちなみにインターネットやSNS否定派ということではなく正しくリスクなどを認識すべきだろうと思ってるだけです

企業や残っている社員はどう受け止めるべきか

基本的には恨みつらみが書かれていたとしても改善点を教えてくれてありがとう！のスタンスにしていくのが良いと思います。
物事は人によって見えてる面も捉え方も全く違うので、すべての人に好意的に捉えられるのは不可能です。
ですので、「そういう風に捉えてたんだ、教えてくれてありがとう。何か改善できないかチャレンジしてみるよ」というスタンスで組織改善の案だしをしてくれたと思うのがよいです。

「なんでこんな事言うんだ！」や「わー問題だ！」「そんなことは事実無根だ！」なんてリアクションを返してしまうとイメージもよくないし、周囲もおもしろがって騒いでいく一方ですし。。

なぜマイナス面の多い退職エントリが出てしまうか

コミュニケーション不足 の一言だと思います。

企業と社員、上司と部下、評価者と非評価者、さまざまな立場と関係性があると思いますが正しい質と量のコミュニケーションが不足しているためにこの退職エントリブームが発生しているのではないでしょうか？
この手のコミュニケーションで目指すべきゴールは唯一つで 「お互いに納得できる」 という状態をつくるこです。
では、納得できる状態はどのようにつくるのかということですが「背景・経緯」といった情報を正しく開示することと情報を落とすタイミングを適切に選ぶことが大切です。
情報を受け取る側にとってどのようなタイミングでどんな内容の情報が降りてくるのかというほは非常に大切です。
渡す側の都合ばかり考えてそれを見誤ると往々にしてハレーションの原因となります。
直近も育休復帰後に異動・転勤の事例が出て。。。という話がありましたが、企業側の言い分としては育休前から決まっていたが育休に入ってしまったため明けたあとに連絡したといった感じだったかと思います。（違ってたらごめんなさい）
これも、育休に入ってしまったためとせずに育休中にも連絡は取れたはずですし、育休に入るということは子供に関して考慮しなければならない面などもあったはずですのでそのあたりの話し合いは早めに行えたはずです。
ぎりぎりになって行えば双方ともに納得などできるはずもなく喧嘩別れになってしまうのも当然のことかと。

参考

partners.en-japan.com

法的な解釈というのもありますが、いくらそこに問題がないと言い張っても周囲からどう見えるかということも意識しなければならないのが企業として気をつけなければいけないことなのではないでしょうか。