Poem

最近チーム定例のアジェンダの先頭に “ふりかえり” という項目を用意して、雑多に箇条書きで書いた内容をシェアするだけの取り組みを行なっている。それがめちゃ上手くワークしてる気がするので言語化しておく。 端的に言うと下記がチーム内部で発生しているように見受けられる。 カジュアルなタスク等のシェア内容から生まれる雑談が楽しい ウィンセッションのようなやり取りで自己効力感も増している 各メンバーがお互いに興味関心を持つようになったと感じる 雑談から相談に繋がることも多く、雑相 が自然発生している リモート MTG にも関わらず、自然と全員ミュートオフで参加している ミュートオフやリアクション推奨などのルールは一切設けていない カジュアルに “ふりかえり” というアジェンダを入れたのは、EM として各メンバーを定性的に評価可能なログとして残したい意図があったのだが、チームビルディングに繋がる効果があったのは意外だった。 チームメンバーの大半がリモート勤務していることも関係しているのかもしれない。対面でなくバーチャル上で心から対話を楽しめるようになることは自然な自己開示にも繋がり、仲間意識が強まる効果はありそう。 このようなバーチャルな交流は、同僚のことを、より偽りがなく、人間的で、信頼できる人間だと認識させる作用があることがわかった。個人的な絆を育む上でも、仕事で協力関係を築くうえでもプラスになる資質だ。 他のアジェンダには、“課題共有” や “雑談コーナー” など用意していたのだが、カジュアルな “ふりかえり” を用意するだけで不要になった。 形式的な定例 MTG は大体システマチックになりがちで、主体的な参加を求めるのが難しいイメージがあるが、メンバー間の対話をコーディネートするイメージで開催するとマンネリ化が防げるようになるのやも。

最近働いていて、チームで動けてないという話をよく聞く。チームで動けていないということを深掘りしていくと、連携がうまく取れない旨の課題を伝えられることが多い。連携がうまく取れるとはどういうことなのか。 連携自体は各職能ごとでは日常やっていることのように思う。適宜状況をシェアして協力することは、どこでもやっているだろう。ただ、連携のレベルを職能間で上げることは、同職種内でレベルを上げるより難しい。 職種間でセクショナリズムが問題になることはよく聞く話である。が、最近コレが本質的な原因なのでは？と思うことが 1つある。それは、他の職能について興味を持てていないのでは？ 、と言うことである。 例えば、業務をスムーズにするために連携したいというコンテキストが存在する中で、他チームの状況を具体的に知りたい欲求があるとする。 自分たちの業務の状況は明確に把握しているため、他チームから状況を引き出したい。ただ、他チームとしては対話を通じて丁寧にコンテキストを共有してくれないと、一方的に頼まれていると感じるだろう と思う。 コンテキストは、その発端となった事柄や検討の経緯など他者が腹落ちした意思決定を行うのに必要な情報を指す。つまり、頼まれた側にも連携したいと感じてくれるためには、納得してもらうフェーズが必要だと思う。 ココで他の職能に対しての興味を持っているかどうかが響いてくると感じている。 一方的な視点から連携を求めたところで相手の理解は得られず、精々得られたとして、形式的な進捗連絡が行われるのが関の山だろう。 対話を通じて興味があると相手に感じてもらい、双方が歩み寄るスタンスになって、初めて連携というワードを出すのがタイミングとしてちょうど良い気がしている。まず下地として相互理解を深めるイメージ。 表面上の連携を行うことは無駄なプロセスを作ったり、本質的でない刹那の解決策を取ることにも繋がり、特にリーダーほど「早く問題を解決しなきゃ」と善かれと思ってやってしまいがちなことかもと感じる。 相互理解が十分深まった上で、気を遣わずに色々と率直に話せるようになり、初めて本質的な対話が可能になるイメージがある。 そこからは、相互に連携を図るための議論が建設的にできるイメージがある。 そう考えるとチームで仕事をするレベルを上げていく最も初期段階に必要なのは、気を遣わずに話すための土台を構築することなのかもしれない。 ワイワイ話せるだけではなく、気を遣わずに相互に率直に感情や意見が吐き出せる状態を、連携可能な状態だと認識しておきたい。 結局、相互理解のための努力を怠らない事が大事ということなのかも。 P.S. 所謂、心理的安全性で言われることだなーと見返して思ったけども、連携を図る上で最初期に行うべきフェーズとして見落としがちやも。

ふと ↑ を久しぶりに聞いて、亡くなったおじいちゃんのことを思い出している。Fantom が出てから 1年後におじいちゃんは亡くなった。“道” は亡くなる直前のお見舞いを毎日していた頃から何度も聞いていた思い出深い曲である。 おじいちゃんが亡くなる直前は何も考えたくなくて、夜に音楽を聴きながら無限に散歩していたことを思い出す。歩きながら思い出を振り返り、散歩しながらずっと泣いていた。(すれ違った人からすれば恐怖だったかもしれない…w) 社会人になって、おじいちゃんからは定期的に電話を貰っていた。直接会って話す機会は、社会人になってからは稀な状況だった。 月並みだが、今思うと直接会う機会を設けたり、一緒に温泉旅行とか行って色々恩返ししたかったな。 大切な思い出や当時の思いを書き残しておくことで、おじいちゃんに対する想いの供養に繋がりそうだなと思ったので、つらつらと雑に文章で残してみる。 自分は幼い頃から兄弟の中でも特に祖父に可愛がられていた。幼い頃はよく仕事のトラックに乗せてもらって、道中のコンビニで必ず欲しいものを買ってもらっていた。今でも毎度コーヒー牛乳を買ってもらってたことを思い出す。 おじいちゃんの家に行くと毎回必ずジャガイモのお味噌汁を作ってくれた。しょっぱい味付けが凄く好きだった。そのことをおじいちゃんに伝えたら、家に行くたびに作ってくれるようになったのだ。 小学生の頃はゲームやおもちゃはなんでも買ってくれた。手を繋ぎながら地元のシータというゲームショップに通った思い出や、当時の店内の詳細な様子など今でも思い出せる。おじいちゃんに何かを頼んで断られた記憶は一切ない。 ゲームを買ってもらった後はおじいちゃんの家で夢中になって遊んでいた記憶がある。五時を超えても遊んでいると親からおじいちゃんに電話があった。まだ遊び足りない時は親に泊まって行くとよく伝えて、実際に泊まっていた。 親は何故かおじいちゃんのことが気に入らない様子だった。悪態を吐いたり、キツく当たることも多かった。親とおじいちゃんが一緒の場にいる時は物凄く辛かった記憶がある。いたたまれない気持ちが抑えられず心を無にしていた。 こんな優しいおじいちゃんに対して、強く攻撃する言動が親から出るのを見るのは耐え難く、よく自分の部屋に避難したことを覚えている。その後知ったのだが、実はおじいちゃんは僕以外には厳しく当たるエピソードが多々あった。 しかし、僕にとっては優しいおじいちゃんだったので、よく親に不快だから攻撃的な言動は止めてくれと言った覚えがある。その時は「あなたは特別おじいちゃんから大切にされてるもんね、ごめんね」と言われたことも覚えている。 高校生で引きこもり気味になった時は、よく「コンビニに行くけど何か買ってくるものはあるか？」と聞いてくれた。「何もないよ、大丈夫」と言っても、おにぎりやサンドイッチを必ず買ってきてくれていたことを思い出す。 今思うと色々気にかけてくれていたんだろうなと思う。学校に行く時は家を出る前に「お金はあるか？」とよく聞かれた。あるよと言っても何かあった時のためにと、五千円もくれていた。お金は使わずにずっと貯めていた。 大学生になってアルバイトを始めてからも上記は変わらなかった。その後地元が大嫌いだった僕は社会人になった直後に引越し先を決め、一人暮らしを始める。当時そのことを切り出した時は親が家を出るのを止める中、おじいちゃんは何も言わず普段通り接してくれていた。 今は子供が二人いる身だから分かるが、気にかけている子供が一人暮らしを始めると言い出したら、止めるまでは行かなくても何か言っておきたい事の一つや二つくらいありそうだ。しかし、おじいちゃんからは何も聞かなかった。 おじいちゃんは定常的に具合が悪くなっても、稀に実家に帰ることがあると、必ず自分の部屋から出てきて僕と会話をしてくれた。その度に親はおじいちゃんに対して「大丈夫か？」と聞いていた。 親に聞いたところ、関節が痛く歩くのも相当辛い状況なのに愚痴一つ吐かず部屋から出てくるのは、僕が実家に戻ってきた時だけとのことだった。嬉しかったが、同時におじいちゃんに辛い思いをさせている罪悪感があった。 時間も経ち、そんな事が何度かある中、おじいちゃんが仕事中に倒れたという連絡が来た。脳出血とのことで、命に危険があるのですぐに来て欲しいと言われ、仕事を抜けて病院にタクシーで向かったことを覚えている。 到着してから病室で対面した時の衝撃は今でも覚えている。いつも優しく接してくれていて普段と変わらなかったおじいちゃんが、良くテレビで見る危篤な状態の様子になっているのを見て、悲しみよりも虚無が襲ってきた。 病室に到着してからは家族が、一番関係の深い僕が一対一でおじいちゃんと同じ空間に居られるようにと、病室から出てくれた。 しばらくおじいちゃんはずっと目を閉じていたのだが、一瞬だけ目を開けてくれた。その時に目があったのだが、自分と目が合うと目を見開いて手をこちらに差し伸ばしてくれた。 本当はその時にこちらからも手を伸ばすべきだったのだが、自分は情けないことに目を逸らして目を瞑ってしまった。今思うとおじいちゃんの死を認めたくなかったのと、涙を見せたくないという思いでそうしてしまったのだと思う。 その後泣くのが落ち着きおじいちゃんを見ると、辛そうな顔で寝ていた。どう言った感情だったのかは分からないが、自分の取った行動に絶望してしまったのだとしたら本当に申し訳ないことをしてしまったなと思った。 そこからはとても早かった。毎日面会時間目一杯通っていたが、五日後には病院の先生から緊急で呼び出されて、最後の時間と宣告された。親は仕方が無いねと、穏やかにその様子を見守っていた。 その瞬間が来たときはもちろん泣いた、が、病室で最初に対面した時よりは泣かなかった。恐らく毎日面会して帰宅後泣いてたことに加えて、ある程度準備が出来てたからだろう。物心ついてから初めて身近に死を感じた瞬間だった。 その後、法要を済ませた後は、すぐに仕事に復帰した。何故ならおじいちゃんだったら、ずっと自分のことで悲しまずに自分の人生を生きて欲しいと言うだろうなと思ったからだ。今までの接し方から、なんとなくそう感じた。 できればおじいちゃんには結婚したり、子供が出来るまで生きてて欲しかったな。今まであまり良い姿が見せられなかったので、重要なライフイベントを親よりも見てて欲しかった。ただそれは自分の祈りに近いエゴであると感じる。 自分はおじいちゃんから多大な影響を受けている。人に優しくあろうとしたり、自分がされて嫌なことは絶対にしないとかは、その典型である。 そう言った特性は子供達にも受け継いでいきたいなと思うが、おじいちゃんは「そんなことしなくて良いよ」とか言いそうだな。

突然だが刃牙という漫画に郭海皇という人物がいる。 真なる強さを求めて独自に『理合』の鍛錬を重ね、気の遠くなるような月日の中、これまでの自身の強さの象徴にして結晶であった自慢の鋼の肉体が衰えていく絶望に耐えながら、ひたすら研鑽を積み重ねるという人生を歩み、現在に至る。 上記は仕事に言い換えると、仕事にアイデンティティや楽しさを感じるほど積極的に取り組んでいた人が、強い制約の中持続可能な仕事への取り組み方にシフトするようなものだと感じている。 自分はまさに上記の状況に当てはまるエンジニアなのだが、どのように足掻きながらシフトしていったのかを、自らの記憶ために書き記していく。 前提 家庭環境はご家庭によって千差万別なため僕の環境を前提として記してみる。 フルリモートの環境で働いている 育児家事の分担は、大体育児を僕がやって家事は奥さんがやっている 平日は朝と夕方までの家事を行なっている ↑ は仕事の状況によってはできないこともある 休日は家族で過ごしている 基本的には子供が楽しいと思える時間が過ごせるように頑張ってる 故に休日・祝日・連休の方が体力を消耗しがちで疲れる…w 平日は基本 10:00-16:30 の間だけが全力で働ける時間（コアタイム） 夫婦間の合意事項として、子供達が寝るまでは個人行動は無し 子供は 3歳と 2歳と 0歳がいる 第三子は言わずもがな睡眠は安定せず、第二子は暴れ盛りで、第一子は生活リズムが安定してきている感じ 夫婦共々両親はお互いに未だ現役で働いている そのため、親を頼るだとか預けるだとかのムーブは不可能 学び 基本姿勢として、一旦全てを捨てさることが超重要だった 最初の 1年くらいはもがいていたが、途中から全てを投げ捨てた 何かにチャレンジするとか、余暇で遊ぶとか勉強とか不可能だった 独身時代の習慣を持ち込もうとすると、全て家庭トラブルに繋がった 習慣を捨てるのはメチャ難かったが、意識的に捨てた 育児が始まったら、熱中できる趣味も捨てざるを得なくなった - 一人で没頭してやる趣味とかは育児始まったら不可能だった 新たな日常に体を慣らすことに全力で意識を傾けた 体と心が新たな生活に馴染んでくるまでは何も考えなくて良かった 育児やってると勝手に筋肉とか体力とかも時間経過で付いてきた 仕事はほどほどで、家庭に全振りでバランス的にはちょうど良い 育児が始まると家庭が戦争になるので、仕事に全力になるのは無理 仕事を頑張りたいっていう人ほど辛いのは分かるが、耐えた方が良い 仕事で自分が居なくても問題無い状態を、本気で自分事で捉えられる - 結果メチャ自分のレベルが上がった実感が得られた（仕組み化） 自分が頑張らなきゃ、で踏ん張ると色々積む（夫婦の時間も取れない） 夜に頑張れば良いやとか、夜に遅れを取り返せば良いやの考え方は終わる 仕事が溜まってようが、眠くなったら絶対に寝るのを優先した方が良い 仕事の評価とかどうでも良い、夜眠い場合は仕事を捨てて寝る 低年齢の子ほど寝かしつけに成功したら、一緒にそのまま寝る - 深夜に起きまくるので、寝れる時に回復するために寝る心算で 朝眠い状態を迎えてしまうと、その日一日をドブに捨てることになる 独身なら色々融通効かせられるが、育児中は融通が効かせられない 一日のうちに何かしら自分の時間が取れて、趣味・勉強とかできたら偉業 早朝 ~ 始業時間にかけてやりたいことやる習慣をつける - 育児中は早朝 ~ 始業時間以外の時間帯は不確定要素が多すぎて、やりたいことはほとんど出来ないと言っても過言ではない - 夜型の人も、半強制的に朝型になるので朝に活動の比重を傾ける 色々な事柄で楽することに全力を傾ける 育児家事仕事全般で楽することに全力を傾けることが結果良い 色々楽に対応可能になってくると、今現在に意識も傾けやすくなる 結論 良い意味で脱力して手が抜ける状況を色々地道に作り続けていく 育児は長期に渡って行うため、持続可能な思考や仕組みを作る 本当の自分とか意識しない、持続可能じゃない要素は全て捨て去る 家庭環境はそれぞれで全く異なるので他の家庭ではとか考えない あの人は育児中なのに色々出来ててすごいとか考えなくて良い 自然体で生活が出来、気力が湧いて、初めて自分のための行動で全然良い 仕事よりも家庭の方が大切 家庭は一度崩れたら立て直すのが大変すぎる 取り返しが付かなくなるリスクもある（特に育児関連は揉めやすい） 仕事はどうとでもなると思うが、家庭は無理なため全力でコミットする やりたい事も何もかも捨ててくと、セルフコントールできるようになる そうなると何が起きようが、対して精神力を削られずに済むようになる 自分がやろうとしていたことが中断されようが何も感じなくなってくる 育児奮闘中から日常になるまでの学びを書いてみたが、改めて思い返すと総じて無理をするなっていう感じだな。あの人はできているのに、あの人は凄い仕事ができるしコミットできてるのに、とかも当初はめっちゃ思ってたなー。 ...

自分は同期的コミュニケーションが苦手だ。対話を行う際のリズムが他者と比較して遅いので、その場で満足の行くコミュニケーションが取れたことは今までのことを思い返してみても無い。 同期コミュニケーションは基本的に始めた側のリズムに合わせることが多く、それに合わせる形で相互に気持ちを通わせることが目的であると感じる。 そこにはバンドセッションのような、空気に合わせてみんなで作品を作り上げる感覚がある。その場で満足できる時間を作ることが主目的だと感じる。（もちろん、それはそれでかけがえの無い時間であると感じる） ただ深く相互理解を行いたいと考えたときに、全体のリズムを重視したバンドセッションのようなコミュニケーションは辛いと感じてしまう。相手のことを深く考えて洞察するための時間が無いから。 その点、心境やプロセスを綴りながら書く文章でのやり取りはすごく好きだ。ただそれは軽量なチャットのようではなく、重厚な手紙のような文章である。 言語化し推敲や内省のプロセスを経た内容を見返してみると、相互理解以前に自身への深い理解に繋がることが多々ある。それを元にしたコミュニケーションができると、相互に意識的に心の対話ができる感覚がある。 自身の理解を経たコミュニケーションができた時の満足度は非常に高く、言いたいことが本当に言えた感覚が得られる。それは、自分の発言でさえ、本来深く洞察しなければ理解ができないものなのであろうと感じる。 そうなると他者への理解が容易で無いことも想像が付きやすくなり、他者とのコミュニケーションの際にレッテルを貼らなくて良くなるなと感じる。 つまり、自分が苦手であると感じる人物に対して不快感の前に、理解が足りないなという自覚に至りやすく、自分のような内向的な人間にコミュニケーションの戦闘力を授けてくれるような感覚がある。 そう考えると、自分のような即時性のあるコミュニケーションが苦手と感じる人たちには是非文章を、クオリティなど度外視で書いてみて欲しいと感じる。 （僕がそういった人たちの思考や文章をとても読みたいのもあるが…w） そもそも散文的に文章を書くことは、とても創造的な作業で楽しいと、今この文章を書いていても心から感じる。 最近は全く文章が書けてなかったけども、これからはボチボチ再開していこうかな。 P.S. しずかなインターネットのように散文的に文章が書けて、似たような人たち同士で偶発的に閉じた交流ができるようなアプリとかって無いのかな…w

他者の行動や判断、決断に不満を持つことは誰しもがあると思う。僕がそう感じた時に大切にしているのが、結論までのプロセスを聞くということだ。 プロセスを可視化し理解することで相手の思考軸を具体的に捉えることができ、受け入れることが出来ずとも、納得できるようになるからだ。納得ができればモヤモヤが晴れた状態で建設的な議論が行えるようになる。 ただ個人的には納得できるだけではダメで、相手と中長期的に関係性を気づいていく上では、リスペクトに至るまでが非常に大切だと感じる。 リスペクトまで至れない場合は、自らリスペクトできる点を積極的に探すべきだと思う。 対話を積極的に行いコンテキストを深掘りし、自らに無い視点や知り得なかった制約に気づくことで、リスペクトが抱けるようになることは案外結構ある。 何故理解だけでなくリスペクトまでが大事だと考えているかというと、人は感情を無視して論理だけでは持続的な行動ができないと考えているからだ。 例えば、上長の決断で進める施作に反対の立場だが、仕事上強くコミットせざるを得ないとする。その場合リスペクトがあれば、自分の取れうる手段でこの人に貢献せねばという理解からの行動に繋げられると思う。 自分の知らない分野での専門性に対してもリスペクトが持てれば、相互に力が発揮できる形での協力体制について想いを巡らせることもできるだろう。 もしリスペクトが無ければ、自分の方が上手くやれる自信があるのにと、感情が思考を阻み行動が思うように実行できないだろうなと感じる。結果として、本人の能力を最大限に発揮することは難しくなるだろうなと。 少なくとも持続的な行動や協力するための行動は難しくなりそう。 頭ではリスペクトが必要だと理解しているのに感情が伴わない場合や、自身の能力に自信がある人ほど、特にこの状況に陥りやすいと感じる。 リスペクトが無いコミュニケーションというのは、案外色んな部分で本人の意図しない形で表出していて、それは結構外から見られていることがある。 そうなると、Disagree and commit の姿勢で物事に取り組んでいても、時間と共に相互の信頼関係にズレが生じてきてしまい、どちらかが無理をするか回避行動を取ってしまうだろうなという感覚がある。 それらを補うほどのインセンティブがあれば別だが、相当なプレゼンスがある人で無い限り、そういった機会が与えられることは一般的には無いと思う。 ここで一番厄介になるのが、自己効力感の喪失である。自己効力感は幸せに直結する要素の 1つであると考えているので、ここの主導権は失いたくない。 リスペクトの欠如がなぜ自己効力感の喪失に繋がると感じるかというと、周囲から理解の姿勢を得ることが難しくなり、孤立に繋がる点が挙げられる。 対話の気力すら失ってしまうことに繋がり、悪循環が生まれるイメージ。 一度孤立してしまうと、周囲と繋がるためのコストが不必要に増大してしまい、信頼関係回復のために疲弊してしまいそうだなと感じる。もしくは時期尚早な回避行動を取ってしまいチャンスを逸してしまう懸念もありそうだなと。 ただし、自分の軸と照らし合わせた時に、どう頑張ってもリスペクトが全く持てない場合もあると思う。その場合は潔くその場を離れる判断をした方が良いと感じる。それは自分のためであると同時に相手のためにもなるだろう。 しかしそれは最終手段である。自身の今後を思えばこそ、異質な人とも支え合えられるような関係性が築けるようなスキルを身につけることは重要である。 それを具体に言語化すると、リスペクトなのであろうと帰結する自分がいる。 リスペクトが意識的に持てるスキルを身につけることは、多様性を認めた上で、自身の欠点を客観的に見られるスキルの言い換えなのかもしれない。 ちなみに僕は音楽が大好きなのだが、たまに全く普段聞かないようなジャンルを意識的に聴き始めることがある。最初は嫌いだと感じていたものも挑戦したりする。すると不思議なことに「あ、今だと聴けるな」となることがある。 そこからジャンルを深掘りすることで、確立された背景なども知ることができ、普通に音楽を聴く以上に感慨深い体験を得ることができたりする。リスペクトとは興味の幅を押し広げるスキルとも言えるのかもしれない。 論理的な思考が先行している人でも、リスペクトがスキルだと言われれば、案外容易に様々な人たちに対してリスペクトが抱けるようになりそうだなと感じる。 いわゆる HRT と呼ばれるスキルセットとも呼べるのかもしれない。 そう考えると、リスペクトはシンプルに自身の可能性や自己効力感を高めるために身につけた方が幸せになりそうだなと感じるし、引いては周囲に対して幸福を与える人になれる可能性を秘めた素敵なものだな と感じてきた…w

はじめに 本記事のカバー画像は sasint による Pixabay からの画像です。 今年は良くも悪くも変化のあった年でした。特に 1 月から暗雲立ち込めすぎて終わった…と思ってたことを思い出しました。。ｗ 来年の自分が今を振り返れるように、今年始めからの記憶を引っ張り出しながら総括しました。ただ今年の初めの方の記憶については大分薄れていて覚えてる限り記す感じで。。 今年問わず作ったものは Tech ページに、技術記事については RSS Feeds にまとめてあります。 出来事 1 月 400 万をドブに捨てることとなる (詳細についてはいつかアウトプットしたい) 諸々人生を真剣に考え始めるキッカケとなる ただそんな中でも自費で M1 Mac mini を購入していた…w Rust 入門のため Actix Web で Gyazo の利用者向けウェブアプリ作ってた Bloggimg ってやつで知見を 記事 として残してた Bloggimg をデプロイした際に得た知見は この記事 で残してた 得た知見は記事として残す行動が習慣化してきた 2 月 テックブログを Vercel 上に Team Blog Hub 使って開設した その際の知見を この記事 でまとめてた 3 月 仕事で初めて Gatling を使った その際の知見を まとめた記事 当時を思い出すと手触りは悪くなかったし、出力されるレポートも見やすかったけど k6 + Grafana のほうが慣れればカスタマイズ性も含めて良い印象 Zenn の記事を DEV に共有するための GitHub Actions を開発してた -> sync-zenn-with-dev-action DEV のアカウント作ってたけど全く使っていなかったので有効活用のためクロスポストできるようにしたいがモチベだった気がする 負荷テスト対策のためのアレコレを記事にまとめていた [Tips] Jest で private readonly な値をモックする方法 - Qiita 📔 PlayFab の API 制限に引っかかった - Qiita Azure + PlayFab で初めて開発したけど、それなりに落とし穴にハマったりコンソールが個人的に見辛かったりしてマイクロソフトェ… になってた記憶…w 4 月 Twitter DM や Lapras でちゃんとしたメッセージをいただけるようになり転職を意識し始める 自分の技術者としての能力が外の世界で本当に通用するのか、試したくなってきた時期だった気がする 個人的にも気になっていた企業様からメッセージいただけたりした感じで嬉しかった 技術教材を作ってみないかのお誘いが Twitter DM で来てた めちゃくちゃしっかりと記事を見てくださって感想をいただけたのと、ドキュメント作成能力は今後絶対に向上させたいスキルの 1 つだったので、受けさせていただくことに決めた SecretSky を VR で見てめっちゃ盛り上がってた 人生初の履歴書作成が数年分の経歴が溜まっていたので、めちゃくちゃ大変すぎて疲れ果てていた 転職の意思がなかったとしても定期的に経歴の欄を更新していくことを決意 5 月 GameCI で Unity の CI 環境構築してみてた この記事 に知見まとめてた 大規模プロジェクトでは GitHub Actions で GameCI 使うときは、セルフホストランナー 必須だなと感じた 転職することを決意し、転職先が決まり 8 月から働けることになる 転職のための作業に時間を割きたくなかったことと、最初から興味がそそられるオファーを色々いただけたのでスグに決められた 6 月 転職することを会社にご報告した 大学生の頃からの関わりも含めると 10 年近く期間があるのでめちゃくちゃエモくなった 自分の技術研鑽のサイクルが確立してきたので、記事として残しておいた 会社の同僚に感銘を受けて真似すると言われてめっちゃ嬉しかった 諸々仕事も落ち着いた段階だったけど、引き継ぎ項目が多かったので 2 ヶ月後の 8 月から転職先で働かせていただくことになる 7 月 エンダーリリーズ にハマり倒してプラチナをゲットする 有給休暇で 1 ヶ月休んでたけど、パートナーに開発の勉強を教えててほぼ自分の時間はなかった… あと長期休暇を取ってみて、今度もしまたそういった機会があったら半年くらい休みたいなと思った 8 月 転職先で仕事が始まる Unity + OAuth2.0 関連をやり始める モバイルアプリでセキュアに情報を保存するための知見を 記事 で残してた 9 月 API インフラバックエンド関連をやり始める ステートフルなインフラバックエンドをやり始める 大規模なステートフルなインフラバックエンド関連の経験が皆無だったので新鮮で楽しいになる ロストジャッジメントにハマり倒す。ストーリーもめっちゃ好きでプラチナを取る educative で教材を書かないかお誘いが来てめちゃくちゃビビる 現在進行形で教材書いてることもあり、今回は受けないことに決めた 10 月 Unity + OAuth2.0 関連が一旦落ち着く とにかくステートフルなインフラバックエンド関連やってた 想定利用者数が想像より桁違いに多かったので色々焦りながら勉強しまくりの日々を過ごす 早々に負荷テストのクラウド環境を整備して開発の度に回してパフォーマンス計測したりしてた インフラのみならずアプリケーション開発も並行して担当していたため、シームレスに開発が進められたのは良かったが、やること多すぎワロタ状態に突入 11 月 我武者羅にステートフルなインフラバックエンド関連やってた おかげでスケールイン・アウトから監視、諸々含むシステムの安定性向上がようやく安心できるレベルまで持っていけた 知見をメモる時間ももったいないになってしまったので、とりあえず諸々 Notion に書きなぐってた 12 月 今まで培った知見を何もアウトプットしていないことに気づき焦る 来年から頑張ろうになる (えっ とりあえずアドベントカレンダーには参戦した ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する 4 月から進めていた技術教材の初稿ができて推敲しまくりステータスに入る おわりに 今年は割と波 & 緩急のあった 1 年でした。来年は今年の変化を形にしつつものにしていく感じで行きたいです。記事にできそうな技術ネタもめっさ溜まってるので放出しまくりたいです。強めのエモネタもいくつかあるので、良さげなタイミングで放出したいです。 ...

はじめに 本記事のカバー画像は tookapic from Pixabay の画像です。 技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。 昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃 ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。 技術研鑽のサイクル 自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。 「きっかけ」：実現したい開発アイデアが浮かぶ Image by Hans Braxmeier from Pixabay 個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。 アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。 また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。1 「行動」：開発アイデアを検証可能な形で実装する Image by Sasin Tipchai from Pixabay 開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。 例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。 技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。 システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。 まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。 「みかえり」：過程で得たもの全てをアウトプットする Photo by Greg Rakozy on Unsplash 成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。 例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。 上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。 成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。 アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。 具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。 ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤 修一さんの Youtube 動画 と同様の考え方に自然に至りました。 全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。 ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮 おわりに 現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。 また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違 この記事内容がどなたかの行動を起こすきっかけとなれれば幸いです！🙏 当たり前ですが NDA に触れるような内容を自身の成果として公開してしまうのは絶対にダメです。あくまでも一般的な技術知識のみを自身の得た知見として公開するというスタンスです。 ↩︎ ...

はじめに 本記事のカバー画像は Vladimir Fedotov による Unsplash の画像です。 最近「ちゃんと理解してくれた？」ということを聞かれた時に「理解したけど、そういう行動を取るつもりはない」というと、「理解してないじゃん」と言われることが何回かあったので、その時の対処法及び感じた心情などをこの記事で吐露したいと思います。 年始からこういう記事を書くのは気が引けたのですが、あまりにも本記事タイトルのような方と多く遭遇したため… 理解するということ 「理解する」というのは、相手の言動の意味が正しく分かったということを意味します。 その言動をそのまま自身に取り入れることは意味しません。例えば、犯罪者の行動理由が正しく分かったところで、それを自分の行動規範に取り入れることはしないはずです。 双方がコミュニケーションを取り正しく分かったという状態になっている前提ですが、「理解したけど、そういう行動を取るつもりはない」という発言を受けてから「理解してないじゃん」という言動を発してしまうのは勘違いも甚だしいです。 上記はもはや理解した・してないとかの次元ではなく、相手を自分の言動でコントロールしたいがために会話している状態と捉えられても文句は言えません。 一種のマインドコントロールに近いかもしれません。 ちなみにこの傾向は、直接話したいと言ってくる人に多いです。しかも、そういった人に限り相手の都合を考慮せずに何回も同期的なコミュニケーションを取ろうとしてきたり、スグに語気を強めて自分が不満であることを感情でアピールしようとしてきます。また、「絶対」 とか 「必ず」 とか 「必要」 という言葉を不適切に多用する傾向が多いです。 例えば、突然語気が強くなったり、攻撃的なメッセージの後に「電話して」等送ってくる人らが該当します。更に特筆すべき事項としては 怒ったと思ったらいきなり優しくなる DV の典型的なパターンであることが多いです。 筆者はコミュニケーションは双方の歩み寄りが前提で成り立つものと考えている ので、そういったやり取りになってしまった場合は残念ですが、親戚だろうが親族だろうが関係なく断絶か、それが出来ない場合は自分から可能な限り距離を置くようにしています。 受け入れるということ 「受け入れる」というのは、相手の何らかの言動をそのまま自分に取り入れることを意味します。 相手の言動を理解した上で、自分が間違っていたり知識不足であった場合に、それを認めて言動を正しく自身に取り入れるということは視野を広げる上で重要です。 しかし、注意点として「理解してないけど受け入れる」場合は、自分で何も考えないで言動を取り入れることを意味するため危険です。 世の中には根気よく話せば伝え方を変える等の工夫をせずとも無条件にこちらを説き伏せることが出来ると思ってたり、一回考えを相手に話しきったらその思いが全て伝わり、勝手にこちらがその思い通りに行動すると思っている人が意外と多いです。 上記のような人物への対策としては、自分の言動の主導権を他人に握らせないが基本戦略となります。 そういった人物は会話のペースや話の進め方が自分勝手なことが多いので、そこで折れずに反応もせずに自分の意思は持ちつつ、適当にいなすような感じで話を流すと無駄に疲れずに済みます。 例外として、自分が相手の言動に勝手にレッテルを貼り一方的に理解したつもりで、「受け入れない」という選択肢を取ることはオススメしません。自分の視野を狭める行為だからです。 つまり、理解するという行為はどんな状況であれ双方が取り組むべきであるが、受け入れる行為はお互いに選択の自由があるという前提を忘れずにいるべきと考えます。特に、こちらが決める権利があるはずの選択肢を、逆も然りですが、どんな人物が相手だろうがコントロールする権利は一切無いのでそのような話が出たときは注意する必要があります。 いずれにせよ、受け入れるというのは行為は、理解という前提があった上での、主体的な行動の結果であるべきと考えています。 自分を押し殺して受け入れるということ 前項でも簡単に説明した、「理解してないけど受け入れた」状態のことを指しますが、その場合のメリット・デメリットは下記になると考えています。 メリット 相手の言動が 自分にとって 100% 正しかった場合 、自分だけでは対処できなかった問題を解決できる可能性がある 自分が納得することはないかもしれないが、 少なくとも相手を納得させることは出来る あくまでも、少しの間は相手を静かにさせることが出来るかもしれない程度 自分で考える労力を割くことが出来る。物事を真剣に検討するのにはそれなりの労力がかかる ただし、自分で物事を検討して行動するための方法が身につかない。他者に依存する デメリット 無意識下に相手の意のままに行動させられる可能性がある 経緯はどうであれ、自身の言動の責任は自身に帰属するため、責任を取る必要がある 自分の言う通りに相手が動いてくれることが嬉しいと感じる人種は存在していて、その人達に面倒を見るといったような名目で監視されるようになる 自分が検討して取り入れたわけではないため、その結果の是非に関わらず学びが薄い 結果を反省して、自分の知見として次に繋げることがしづらい 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく 与えられた選択肢の中から最後に後悔しない決断が出来るのは自分しかいません 選択肢の意味を正しく理解しないまま行動すると、失敗したときのダメージが大きくなります 上記を見ていただければ分かる通り、メリットは非常に薄い上に基本的にデメリットに直結するような内容が多いです。 つまり、メリットに感じる点は刹那的な効用であって、本質的には問題の要因でもあるということです。 また、上記の中で最も重要な観点は 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく という点です。筆者はこの点を生きていく上で非常に重要な点の 1 つと考えています。 その理由として、主体的に行動を起こすエネルギーが無くなると、1 日過ごす際の時間を有効活用できなくなったり、重要な決断をいつまでも先延ばしにしてしまうようになり、人生を楽しむ時間が削られていくと考えているからです。 要は、面倒だからと言って理解せずに受け入れたり、他人の意見に忖度して決断を行うという行為を繰り返してしまうと、時間を浪費したり、1 日に楽しい時間を過ごせる割合が減っていき幸せの総量が減る ということです。 理解したを受け入れたと捉える人たちへの対策 まず距離を置くという対策をオススメします。反論や反発はオススメしません。時間を浪費するだけでなく、無駄にダメージを負わされる可能性が高いです。 また、強い言葉で一方的にコミュニケーションを取られた後「反省している」「言い過ぎた」等の言葉で優しくされたとしても決して距離は近づけないでください。もしそれで距離を近づけてしまうと相互依存のような形になっていき粘着されやすくなります。 ...

はじめに 本記事のカバー画像は Michal Jarmoluk による Pixabay からの画像です。 今年は結果的にプライベートと仕事の両面で充実した年にできました。来年の自分が今を振り返れるように、今年始めからの記憶を引っ張り出しながら総括しました。 今年問わず作ったものは Tech ページに、技術記事については RSS Feeds にまとめてあります。 出来事 1月 Death Stranding のプラチナ獲得 弊社に面接にいらっしゃったベテラン開発者の方に何でうちに応募してくださったのか聞いたら、僕の Twitter や Qiita アカウントを見てくださり技術力がありそうと判断してくれたからと聞いて爆嬉しかった ambr オフ会参加 (オフィシャルなオフ会に初参加) Quest 用アプリケーションの初リリース体験実績解除 申請時の知見の一部については Qiita 記事 として投下 Android で AR アプリケーションの開発及び、マルチプレイを可能にするバックエンド開発を担当した 2月 Docker で各種モバイル VR 向けの Unity ビルドが出来るようにした フルリモートでアジャイルな開発チームにジョインする (WebView/ReactNative/iOS/Android) 主は ReactNative の iOS/Android のネイティブプラグイン開発 コア機能の実装にのみ注力しパフォーマンスチューニング等々を行っていたためポジション的にはひたすら地味だった 3月 note デビューした 初投稿は 精神衛生を保つため Chrome で Twitter を閲覧している時にフォロワー数を非表示にする っていうやつ お題が「Home」の web1week に参加した 参加した時に投稿した記事はこちら 4月 会社の Medium ブログ開設 したのと、いくつか記事を寄稿した Azure Kinect DK の開発環境構築から KinectFusion のサンプルを動かすまで 最短で Magic Leap 1 の開発環境を構築する 色々工夫して iPhone TrueDepth を WebRTC でブラウザに転送して、Three.js で表示する仕組みを実現した Twitter でシェア してみたら、予想だにしないことに一方的に尊敬していたエンジニアの方々からいいねを貰えてモチベが爆上がりした CloudFormation と和解。IaC の利便性を完全に理解し始める 今更 SEKIRO にハマりまくる & プラチナトロフィー獲得 デス・ストランディングから学んだこと が現在の自分の考え方の基礎として根付き始める 全ての考え方を 0 or 1 ではなく、グラデーションにハメ込むことが出来るようになった 5月 再びお題が「Like」の web1week に参加した 参加した時に投稿した記事はこちら (あとから確認したら投稿先を間違えていた…) Medium に目次が無いことに不満をいただき Chrome プラグインを作成する プラグインの紹介記事 まで書いてたけど全くインストール数伸びなかった、、けど今みたら 12人ほど使ってくれている人いるぽくて嬉しい お題が「密」の unity1week に 参戦した 6月 S3 + EventBridge + CloudWatch + CloudFront + MediaLive + MediaPackage + AppSync + Amplify + DynamoDB + Cognito + Lambda + API Gateway + SSM という AWS ガッツリなインフラ構築から、バックエンド開発及び iOS アプリ開発までをおもむろに始めた まず DynamoDB の仕様にハマる (自分のリサーチ & 勉強不足によるせい…) つぎに MediaPackage + CloudFront の構築 に苦戦する そしてデバッグが辛くなり Serverless Framework でエラーを検知して Webhook で Slack に通知を飛ばす方法 を実践し始めたりしていた シェンムー3 のプレイを開始。ワクワクするし美しすぎる町並みに興奮し、しばらくの間深夜までプレイする日々が続く 映画の HELLO WORLD を見て、劇中 3回号泣する 元々は Unity で作られたシーンがあるという記事 を見て興味を持ち見ようと思い立った感じだった 7月 ひたすらトラブルバスターしてた (一番忙しかった気がする) 8月 Ghost of Tsushima にハマりまくる & プラチナトロフィー獲得 DDD 開発の際、DI コンテナ入れたいよねっていう話から TypeScript 環境で利用可能なライブラリを調査して InversifyJS と tsyringe を見つける 最初 InversifyJS を発見してそれで開発をしていたものの、microsoft 製の tsyringe を発見し、「メンテナが大手だしコンストラクタインジェクションだけしか使わないし、こっちのが良くね？」という話になり InversifyJS から tsyringe へのリライト作業を行う…w AWS SDK for Go で関数の引数と返り値を Type で定義するっていう考え方は非常に参考になった 引数が *Input という定義で、返り値が *Output という定義で分かりやすく読みやすい 自作 iOS ライブラリの CocoaPods 対応について C++ 周りの linker error に対する解決のためのアドバイスを急ぎ求められたので、共有された情報から自分がハマった経験に照らし合わせてソレっぽい対策案を共有したらガチッとハマって解決でき、経験が生きた感がめっちゃあって、めちゃくちゃ嬉しかった 9月 フライパンでコーヒーの焙煎を始める チャフの飛散に苦しめられるが、風呂場で作業することで諸々ストレスフリーになる このときはまだ、後ほど焙煎機を購入することになるとは夢にも思わなかったのである… Azure を用いた開発に本格的に携わり始める その際得た知見は Zenn で 本としてまとめた。本来は記事として書くつもりだったが、分量が増えすぎたため記事内容を分割して、本としてまとめた PlayFab CloudFunctions のための関数実装のために Azure でシステム構築していたため、PlayFab にもそれなりに詳しくなる とある案件から別案件に移る際に、 「えー、〇〇 に行っちゃうんですか。nikaera さんは今後も 〇〇 を一緒にやっていって欲しいのに」 って結構強めに言われたことが未だにめちゃくちゃ嬉しい シンガポール現地のフリーランスの方と仕事を共同で進めることになる。技術に関する事柄やプライベートに関する事柄のやり取り等々、全て英語でコミュニケーションを行わざるを得なくなり、そのおかげで英語でコミュニケーションを取ることに一切抵抗が無くなる 10月 約 10 年ぶりに私用携帯を HTC EVO から iPhone 12 mini に機種変する 開発用途でなく普段生活で使うことのみを考慮するということであれば iPhone 12 mini は最強にオススメできるスマホです 会社支給のスマホで 7年近くを賄っていたため、特に不便がなかったため… AWS Amplify への PR がマージされる もとは serverless-amplify-simulator の Issue で議論していたのだが、改修すべき内容は amplify-cli にあったのでそちらで PR を提出した 細かくづまづいた点を進捗共有兼ねて Issue で一人投稿しまくっておくと、他の開発者の役にも立てるし自然とその問題に詳しくなっていくし、OSS 活動への取っ掛かりとしては最高なんじゃないかと勝手に思い始める NPM に初自作ライブラリを公開する serverless-amplify-auth という Amplify 開発を行う際は必ず行うであろう IAM Policy の制限を Serverless で行うことが出来るようにするやつ 11月 Hugo で自分のブログ(nikaera.com)を GitHub Pages 上に構築する カジュアル面談した人に Qiita のネタ記事 見ましたって言われて嬉しいよりも恥ずかしいが上回った Etsy でアクセサリ販売している方に日本のフリマ事情を詳細にお伝えしたらおまけのプレゼントを送付してくださった ちなみに購入物は Death Stranding の ドリームキャッチャー Moonlander が自宅に届きテンション上がって紹介記事を書く 12月 今年学んだ重要なことを 記事 として残しといた (これもある意味総括な気がする) GitHub Profile を充実させる こんな感じ -> https://github.com/nikaera 更に GitHub Profile を充実させるために Zenn のバッジを作成するサービス を作った Lapras の技術力スコアが 3.36 になってた 基準とか良く分からないけど純粋に上位 13% に入ったと言われてるのは嬉しかった いくつか空いてたアドベントカレンダーに参戦した MediaPackage 用の CloudFront ディストリビューションを AWS SDK で作成する Serverless のプラグインを TypeScript で作成する方法 AWS Lambda を用いた他社製品との連携システムが好評で、去年から今年末まで特に目立った不具合等も起きずに運用できたため、次期開発に繋がりそうとの連絡があり開発者として爆喜ぶ おわりに 今年は後半からすごい勢いでギアが入ってきた感があり、諸々活動するための足がかりを作れた気がします。身も心も進化したなと思えて成長できたなという充足感は割と高めな 1年だったので、この勢いのまま 2021 年もマイペースに色んなことにチャレンジしていければなーと思っております。 ...