Nikaeraintokyo.

🤖 AI時代における個人の幸福 (2025/07/15)

Mon, 14 Jul 2025 00:00:00 +0000

最近、AIエージェントの話題が「効率化」というビジネス観点ばかりが取り沙汰されている気がしている。また個人が力を持つみたいな話も多い認識だが、個人の幸福に繋がる話は余り見かけないことに違和感がある。

理想の AI時代が到来すれば無条件に全員が幸福になると思われているからか、ただ個人的には余りそう思わないので所感を書き散らしてみる。

ちなみに AI周りは日進月歩なのでタイトルに日付を付けることにした。後々また考え方が更新されたら新たな記事で綴るようにしたいと思う。

AIが瞬時に答えを出し、依頼を完遂してくれる世界。それは一見すると理想郷のようにも映る。ただ、人間が根源的に持つ「意義ある成果を自ら得た」という欲求はそれで果たして満たされるのか。

Suno を触っていても感じるが、クリエイティブにおいても「AIガチャ」のような受動的な体験は、大半の人はおそらくすぐに飽きてしまうのではないかと感じている。ソシャゲの飽きと同じかもしれない。

そこには、試行錯誤の末に何かを成し遂げた時の満たされた感覚、いわゆる自己効力感がすっぽりと抜け落ちているからだと感じる。

プロセスを無視して結果だけを享受する状況は、自らの能力に対する信頼や、行動することの意義そのものを見失わせる危険性を孕んでいそうだ。

では AIとどう向き合えば、より個人の幸福に近づけるのか。

最近考えているのが、AIを探究するための「パートナー」として捉えるアプローチ。探究対象は自分自身でも既に対象が存在してればそれで良くて、人生で没頭する時間の総量を増やすのに使うイメージである。

探究対象が無い人は自分自身への理解が足りてない可能性が高いので、AIで過去から自分の価値観を炙り出すと言ったことをすれば良い。他には AIからコーチングや認知療法など受けてみても良いかもしれない。

自分自身の価値観は何なのか。何に喜びを感じるのか。 AIに問いを投げかけ、返ってきた答えを吟味し興味関心を深めていく。引いては行動に繋げるループを回していくことで、思いがけない自分の成長に繋げていく。

以前好きなアーティストや音楽の時代背景を深掘ることをよくやっていた。そこから新たな気づきを得て感動を得た体験が多々あった。教養が深まることにも繋がったし、そういった成長の実感は素直に喜びに繋がる。

成長というと高尚に聞こえるが、フロムゲーを頑張って攻略したみたいなものも含めて言っている。単に以前より上手くなった実感みたいな。

また自分自身の探究も深まれば自ずと幸福に繋がる行動や取捨選択も可能になりそうなので、後は惰性で一般的に幸福とされる人生が送れそうな気がする。自分の創作する物語を 100%味わい尽くして楽しむ感覚である。

とここまで話してきて物語思考感が出てきたので紹介しておく…w

Amazon.co.jp: 物語思考　「やりたいこと」が見つからなくて悩む人のキャリア設計術 (幻冬舎単行本) eBook : けんすう（古川健介）: 本

よく一般的に言われる AIで働かなくて良い時代が来たら義務感から解放され、純粋な「楽しい」という動機で行動できる。という世界が来たとしても、その「楽しい」が見出せない人には辛い時代が来そうである。

ただ「楽しい」だけでなく、それらが社会からも一定評価されないと持続可能ではなく「楽しい」を享受し続けられない気もするので、ここまで語ってきて何だが、諸々単純な話ではない気はしている…w

💪 脱力という最強の構え

Sat, 14 Jun 2025 00:00:00 +0000

前期の評価で、会社の業績が芳しくないにも関わらず自己評価を引き上げる形で最高評価を付けて頂けたのだが、何故そうなったのか考察した。

結果、以前書いた記事の合わせ技で、説明が付きそうだったのでバーっと書いてみる。結論、「脱力で始め、着地するまで動く」 に達した。

育児エンジニアの学び｜nikaera

2,104字

🎯 目標管理と運用は二つで一つ

Tue, 06 May 2025 00:00:00 +0000

今期、初めて組織の縦横が揃った形で目標設定ができた。かつプロジェクト単位で全体の動きも自動的に目標達成に向かう状態になっていた。だが目標達成の進捗・成否については、誰も気にしていないように見えた。

現在は状況を鑑みて目標を、目的も含め見直す動きが発生している。なぜこのような事態が起きていたのか、考えてみたので雑多に書いてみる。

明確な目的はチームの指針であり、価値の拠り所になる。でも目的が完璧でも、それだけで機能することはない。目標達成に近づいている実感を得られる “運用” が無ければ、美術館に飾られている絵と同じである。

目標は抽象であり、運用こそが具象である。 例えメンバーに目標を意識付けても、自己効力感がなければ行動も伴わないだろう。ただの文字列として目的や目標を覚えても、腹落ちしなければ意味はない。

それらの問題は、主体的な目標達成に向けた行動が賞賛される文化づくりや、自己組織化を促す権限設計など行わない限り解決が難しいだろう。

目的や目標の決めは、ただのスタートラインにすぎず、フィードバックループや振り返り等もなければ、組織の健康状態が誰も把握できず、知らずのうちに自分たちの置かれている状況も把握出来なくなってしまう。

運用が目的に接続していない状態で、目標管理を構成する重要な要素として、運用が認識できる仕組みを組織に組み込むにはどうすれば良いか。

目的や目標を決める際に、達成に向けた運用も併せて設計することが肝なのかもしれない。 例えば、大局的なロードマップがある場合、紐づくプロジェクトはボトムアップで議論を重ねて検討を推進するなどである。

目的や目標の決めから、チーム全体を巻き込みつつワークショップのような形で議論を行う。ハレの機会として非日常を演出して、日常では築けないレベルの相互理解を醸成する話題 (理想とか) を語り合う。

組織効力感がぶち上がる中で、目的や目標に関する議論がされると、自然創発的に目標達成に向けた議論や運用も各所で行われる事もあるかも。

目的を語るとは、運用を語ることであり、理想と現実をつなぐ視点が必要なのだろう。 そして目標管理は最早アートと呼べそうなほど高度な気がしてきたので、その観点で運用に取り組めるとテンション上がりそう (小並

蛇足: 次こそは良い感じに最強の目標を、と意気込んで↓を読んで取り組んでたはずなのに、やはり実践の中で研鑽と学びを積んでいくしかない

Amazon.co.jp: アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ eBook : 小田中育生: Kindleストア

🎯 いかなる時も、行動の起点は自分から

Sat, 29 Mar 2025 00:00:00 +0000

仕事において、規定の役割や方針に従って期待通りの成果を出そうとする人がいる。外部からの評価を伺いながら、行動を実行するタイプである。

上記は一見すると、ドライでプロフェッショナルな仕事人に見える。

しかし、評価軸の起点を外部に委ねると、評価されない場合、他責に陥り周囲に不満を抱えがちである。外部からの評価に対する認識ずれは、自己効力感や組織効力感の低下に直結しやすい。

また、お膳立てされた規定の範囲内でしか行動していない場合、当人は多大な成果が出てる認識でも、外部からはそう見えない状況が発生する。

この状況を打破するには、評価軸は自ら定めることが重要である。自分の価値観を大切にし探求的アプローチが取れる状況を作ることで、個性が発揮される形で成果が出しやすくなり、評価に繋がりやすい。

何かチームに不満があるときは、自分軸で積極的に解決に動き出す。他者理解は周囲を適切に巻き込みながら獲得していくアプローチで進める。

主体となり仮説を立て行動すると、意義ある学び・成長が得られる。そうして得られる経歴・経験はキャリアにも多大に寄与し、自己効力感は高まり、成長と評価に好循環が生まれていく。

何れにせよ上位職やリーダーを担うようになると、不確実な状況下で意思決定や行動することが求められるため、主体的に解くべき意義ある問いを発見するスキルはキャリアアップにも極めて重要になってくる。

そもそも、不確実性が高い状況下で仮説を立て、行動に繋げられるスキルが無いと見做されれば重要な仕事は巡ってこない。会社の評価に縛られ、自ら行動が起こせない状況は不健全であり、キャリアの停滞を招く。

自分の道は自分で作る。もっと自由に個性を活かして組織やチームのために行動してみることは、自己実現と評価の両立の実現に結びつくと思う。

何より、楽しく充実した仕事が行えて幸福な日々が過ごせそうである。

🥋 守破離という最強の型

Sun, 23 Feb 2025 00:00:00 +0000

チームメンバーとの 1on1 を通じて最近感じたことがある。それは守破離という日本古来の考え方こそ全てに通ずる最強の型なのでは無いか ということである。具体的には、下記の構造が全てにハマるなと感じている。

型を守る（守）：期待通りの活躍ができる
- 外部からの信頼が得られ、安定した評価が得られる状態
- 基盤が構築されることで、後の建設的な挑戦への準備に繋がる
- 守に留まりすぎると諦観や不満が生まれてくる
  - ココで逃避的な行動を取ると次のステップ（破）には進めない
  - 守を突き詰めていっても、期待を超える活躍は基本無い
型を破る（破）：現状に疑問を持ち、挑戦する
- 型に疑問を持ち、現状の慣習やルールに挑戦している状態
- 型の深い理解があって初めて、意味のある挑戦が可能になる
- 挑戦を積み重ねた上で蓄積された知見が革新に繋がる
  - 知見を重ねていかないと次のステップ（離）には進めない
  - 破を闇雲に行なっても、注意散漫で革新は生み出せない
型を作る（離）：独自の型を創造する
- 積み重ねた知見から、最初の型から完全に離れた姿になる
- 強みや個性を最大限に活かした創造的な状態になる
- 今まで見られなかった成果が創出できるようになる
  - その後は再び守の状態に戻り、安定を目指すことになる
  - 離には留まれないため、守に素早く移行することが鍵となる

最初は忠実に型を守り、期待に応えることで安定した基盤を築き、その上で敢えて既存の型を破る挑戦を行い、最終的に独自の型を創造する。上手くいけば、著しい達成感が得られ、幸福の最大化に繋がるだろう。

上手くいかなくても、自分は挑戦したという誇りを胸に充実した人生が送れるようになる。といったことを考えると、自身の幸福度を最大化する心得として守破離はとても大切なのでは無いかという気になってくる。

必要だと思うから行動するという行為は一見理にかなっているように見える。しかし、自分がやりたいからやり、意味は後から考える方が内発的動機に裏打ちされた挑戦が持続できて幸福度も高そうに感じる。

つまりは、諦観や不満が生まれてきたら意識的に本能に従った行動をとり、積み重なった知見から何か新たな発見をしていくだけで自然と充実した人生が送れるようになっていくのでは？という仮説が出たという話。

注意として、偉大な先人達が積み上げて体系化したナレッジを見も学びもせず、型無しの状態で守破離は実行できない。何でも良いので、お手本や理想系から逆算した、自分にハマる型を発見することが肝要になる。

蛇足

自分は音楽制作に憧れがあったのだが、ずっと思う通りに作曲出来ず満足できなかった。しかし AI を用いた作曲で自分が好きになれる高品質な音楽がバコバコ生成可能になり、多大な幸福を獲得している実感がある。

作曲に必要な型が、プロンプトというテキストになったことで自分の表現力が如何なく発揮できている感覚があり、捉われから自由になった。

これは自身の欲求が失われていなかったから実現できたことであり、日々の欲求を大切にして生きていきたいなと感じた 出来事であった。

AI を活用して生成した楽曲は下記にあるので、音楽制作にずっと興味のあった人は今からでも是非試してみて欲しい。世界がひらけると思う。

nikaera | Join me on Suno

Suno is building a future where anyone can make great music.

🌱 スタッフプロジェクトの種を蒔く

Wed, 05 Feb 2025 00:00:00 +0000

今期開発チームは OKR に戦略ベースで貢献していくことにした。エンジニアリングを用いて効果的に貢献が可能な戦略をチームで描きつつ、そこに向けて各メンバーが Will 駆動で戦術展開していく流れである。

結果、チーム全員が同じ方針に向き、多様な観点から積極的に貢献に動く様子が見られる。まだ 1ヶ月しか経ってないが下記の動きが見て取れる。

あるメンバーはチーム全体にアジャイル文化を浸透させるべく、プロダクト開発のフロー効率最大化を PdM チームと協力しながら推進し、AI 活用を広めるオンボーディング活動なども積極的に行っている。
- 今まではリソース効率に振っていた進行のせいで、注意散漫かつ不確実性の高い進行が続いていた。まずはフロー効率に最適化するべく、マインドセットのアップデートから丁寧に行っている。
あるメンバーはコミュニティの健全性が測れる仕組みを用意するために、大前提となる世界観の言語化から、仮説検証項目の洗い出し、AI による分析のための戦術検討を推進している。
- 普段表に出ない開発メンバーだが、若干あったという心理障壁を乗り越え、アジェンダのレビュー依頼が来たり、自主的にセクションを跨いだステークホルダーを集めてキックオフしていた。

アウトプットベースのプロジェクトという形で降ろしてしまえば、工夫の余地は余り無くなるため、良く言えば正解が見える状態で進行も楽だったと思う。不確実性が少ないため、マネージャーも管理はしやすい。

しかし、それでは個々のケイパビリティが発揮されたモチベーション高い状態での進行・委譲は難しかっただろうなと感じる。

上述からの学びとして、OKR 貢献のための戦略はその性質上、全体を巻き込まなければ推進が難しい状態に必然的になるため、 スタッフプロジェクト のようなものが生み出しやすいなと感じた。

これは必然的に各チームメンバーの成長に繋がるだろうし、転職する際にもアピールポイントとして使える経験となるだろうし、EM としてもチームのアピールやチームメンバーの評価向上に使えるため、とても嬉しい。

ただミスった時のダメージも、例えば今後チームを超えた協力を取り付けることが難しくなる、等々それなりに出る可能性が考えられる。そこは過去記事の下記一節の通り、EM として全力でサポートしていきたい。

メンバーがチームを越境してリーダーシップを発揮する

可能な限り成功確率を上げるため、サポートは惜しまずに行う

リーダーシップシフト雑感｜nikaera

1,584字

📅 2024年の雑な振り返り〜人に恵まれた〜

Tue, 31 Dec 2024 00:00:00 +0000

最初に結論を書くと 人に希望が持てた一年だった。 自分は正直言うと、人の選り好みが激しいタイプだった。自分から一方的に相性が悪そうとか、諸々の意味でプレゼンスある人に話しかけたら迷惑かもしれない、とかで自分から話す人を制限したりしていた節がある。

ただそれは杞憂というか思い上がりすぎた。業務で関わりの無かった人達やカンファレンスの人達に素直に興味があったので、素直に話しかけたら会話が途切れるとかも無く、普通にめちゃくちゃ楽しく話せる経験がたくさん積めた。これは自分が本当の意味でどう見られてるかを気にしなくなったことが大きいのかもしれない。

保育園での送り迎えでの父母同士のやり取り、子供達からも認知されて話しかけられることが増えた。多分 5年前の自分に伝えたら想像できないと言われるだろう、っていうほど話すことに抵抗が無くなった感じがある。

人が怖いと感じていた自分が、人に救われている感覚がある。今後も一期一会を大切にして、積極的に人と良い関係性を築いていきたい。そういう意味で言うと来年の抱負は関係性を深めたいになるかもしれない💭

⚠️ マネージャーが信頼を失墜させる時

Sat, 28 Dec 2024 00:00:00 +0000

最近マネージャーがタスクの背景を伝えず緊急度高めでメンバーに振り、意図したアウトプットが一撃で出ず烈火の如くブチギレる事案を見た。

更に悪いことに、マネージャー自身もタスクの発端となった背景を把握しておらず、ほぼやり直しのような形でタスクが振り直されていた。

上記は典型的な、秘伝のタレでマネージャーを続けた人物に多い傾向の認識がある。ソルジャータイプのプレイヤーが成り上がり、能力が足りない状態でティール組織でいう、レッドやアンバーに近いスタイルである。

最早古典と言って差し支えないデッドラインにも掲載されている、所謂下記以外の “管理ごっこ” で仕事した気になっている管理職のことである。

正しい管理の4つの本質

適切な人材を雇用する

その人材を適切にあてはめる

人々の士気を保つ

チームの結束を固め、維持する

前述の行為でメンバーを体調不良に陥らせたり、精神的に病ませることで、チームは瓦解しながらも闇雲に頑張るようになっていく。チームの組織効力感は地に落ち、マネージャーのご機嫌や正解を伺うようになる。

マネージャーは「やっぱ俺が率いないとダメだな、このチームは」みたいな現場との認識の乖離で世界が断絶されていく。こういったマネージャーはプレイング能力は高いので現場の作業を自身で行い巻き取ろうとする。

チームメンバーを子供として扱い、チームがマネージャーのサポーターとして振る舞うようになった結果、マネージャーがボトルネックとなり、いつまで経ってもチームのケイパビリティは向上しなくなる。

更に悪いことに、マネージャーは自分のペースに合わせることをチームに求めるため、大体ハードワークするメンバーを評価対象とする。そして同質性を持ったメンバーが昇格する事で同じ悲劇が連鎖する。

マネージャーの口癖は「もう一人の自分が欲しい」「自分の分身が欲しい」といった具合であり、個性も多様性も失われたチームは単なる作業者として扱われる。それ故作業量をこなすためのハードワークが評価される悪循環といった形である。メンバーの才能は 5%も発揮されないのでは？

またマネジメントへの理解が「結局はヒトモノカネの話」で括る人もいるが、その程度の解像度の方が体系的にマネジメントを学んでいるとは到底思えない。大局的に言えば正しいそうだが、甘く見ているなーと感じる。

ちょっと気が滅入ってきたのでココまでにするが、本来マネージャーは事業や組織に良い影響を与えるためにチームのケイパビリティを最大化するのが本来の役割であるはずだ。

構成するメンバーの才能などを見極めていち早くチームとして成果を上げてもらうための、仕組みを作ったり学習機会を与えたり仕事の振り方を工夫したりする必要があるのはマネージャーの役割である。

マネージャーはチームを機能させることが主題のはずなので、自身こそ代替可能な存在にしていかなければならない。各チームメンバーの個性を遺憾無く発揮し表舞台で活躍できるようにすることが重要である。

チームは画一的に扱えないため、今までの経験をそのまま適用することは無理で、常に観察や興味を持ってチームメンバーと関わり、対話しながら相互理解を深めたり、才能を解放することは不可欠である。

そのために必要となる能力は学習可能なものであり、マネージャーは常に業務に関するドメインのみならず、広範に及ぶマネジメントに関わる知識もキャッチアップしていかなければならない。

自分は下記でいうミッションチームの EM を担っており、PdM チームは別途存在するため、PdM 領域は浅く他の領域を強化している。

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

本記事は、Engineering Manager Advent Calenderの１日目です。はじめにエンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの...

🏛️ 灯台としてのプロダクトビジョン

Sat, 28 Dec 2024 00:00:00 +0000

現在所属しているチームでは、トップダウンのミッションをベースとして駆動してきた側面がある。プロダクトビジョンはローコンテキストに揃っておらず、拡大する中で各セクションでサイロ化が進行している。

現状を放置していると、日々アウトプットに勤しむだけのビルドトラップにハマった集団になるという危機感から、自律的にプロダクト価値を共創可能にするためのビジョンをローコンテキストに整備することとなった。

現在は前述の資料を作成するためのキックオフが開催されたというフェーズなのだが、自身もコアを形作るメンバーとして携わることになった。

そこで、後からプロダクトビジョンを定義するにはどうすれば良いか、またカルチャーデックや OKR のように、綺麗に作ることに満足して実運用がおざなりになりがちな問題にどう立ち向かうと良さそうか考えてみた。

現状のプロダクト開発の状況を一旦整理してみた。

すでにリリースされて数年以上経過している
チャーンレートは低く抑えられており、一定価値は届けられている
各セクションは各々の実業務に最適化されたプロセスを構築済み
- プロダクトビジョンにフォーカスできているかは不明確

上記を鑑みると、アウトカムは一定生み出せていそうなので、プロダクトビジョンについては PO/PdM から語られる内容を、ローコンテキストに整備するだけで叩きとしては十分そうに見受けられる。

サイロ化した各セクションの戦略が課題かもしれない。全体として目線が揃っていないことで、創発的な取り組みがセクションを超えて検討できず、インパクトのある打ち手が全体として出しづらい状況になっている。

現状各セクションを超えて何かを依頼する時に遠慮があるのは前述課題があるからではないか。プロダクトビジョンに沿った提案ができているか不明瞭なまま他セクションに相談を持ちかけるのはハードルが高いだろう。

またプロダクトビジョンが定義できたとして、内発的動機付けとなる各セクションの意思も大切にしたい。各セクションの意思とプロダクトビジョンが良い相互作用を起こし進化を遂げつつ浸透することで、プロダクトの理想にチーム全体が一丸となって向かいながら成長できると理想である。

そこで検討した結果、まずは各チームの現状の強みやありたい姿をメンバー同士で語ってもらい言語化することが大切なのではないかと感じた。

トップダウンで降りてきた内容ではなく、敢えてメンバーのプライベートやキャリア展望、自己効力感が得られる取り組みを曝け出してもらうことからチームの輪郭を象っていくイメージである。

その後、メンバー全員が組織効力感を感じる戦略を描きつつ言語化し、Will をコンフォートゾーンを突き抜けるほど先鋭化させたものを目的として扱う。出発点がチームとなるため自らの意思でコミットメントしやすく、目標も Will から練っていけば良いため想像が付きやすそう。

チームの戦略とプロダクトビジョンを整合させる部分は、マネージャー陣が期待値調整や言葉の橋渡しをすることでカバーする。また積極的にコラボレーションのサポートを行い、セクション間での対話のハードルを下げることで、自然創発的な取り組みが生まれる空気を醸成していく。

つまり、プロダクトビジョンは灯台として、チーム戦略を正す必要があるか、向かう方向の妥当性など検査する際に利用する。

結果として、チームのアクションアイテムが自然とプロダクトビジョンの実現に向かう行動と紐付き、各メンバーの才能が開放された状態で日々の業務に取り組める状態になるとベストなイメージがある。

ここまで語ってきた内容がすんなり上手くいくわけがないとは思いつつ、現状のチーム状況を見てみると実現不可能とも思わないので、一旦挑戦して知見が得られたら、また言語化して記事に残したいと思う。

P.S. 書くときのムードが、朝は森、夕方は川、夜は夏の夜にすると、自分は筆が乗りやすくなることが分かってきた ✍️💨

🗣️ 言い切りや断定の言葉が苦手

Wed, 11 Dec 2024 00:00:00 +0000

何かの話題を話しているときに「〜絶対になります」「〜が正攻法です」のような言い切りや断定の言葉が出てくると脳内アラートが作動してしまう。

システムと向き合う際、論理主義的な姿勢を取るのは当たり前だとは感じる。ただ、対人やチームの内発的動機付けされた創発的な試みや発言に対して、ハナから経験もしていないのに詳細に外から持ってきた論理を元に事の顛末を説明されても、単に押し付けがましい態度だなと自分は感じてしまう。

ネガティブケイパビリティが低くスグに解を見出そうとしてしまう態度と言っても良いのかもしれない。コミュニケーションやコラボレーションを通じて探求する態度を取らない限り、意見を受け入れてもらうことは、その解がどれだけ正しかろうとチームに乗り気な態度を取ってもらうことは難しいだろう。

ソフト面を軽視してハード面で解決を試みる態度は、トップダウンで正解を降ろしてくるメンバーを頼るチーム体制になりがちで、それはケイパビリティの限界を個人に委ねている状況である。それは EM としては嫌だなーと。

しかし、言い切りや断定の言葉も接頭辞に「現状のまま行くと〜」「特定のケースでは〜」「現状のチーム規模だと〜」が付いたり、「〜絶対になると思います」「〜が正攻法の 1つです」と言ってもらうだけで自分の中では一気に建設的な対話や議論ができるワードだなとなるので、脳内で変更して受け取るよう訓練していきたいなと思う。（自分が変わっていくスタイル）

チームに主眼を向けた形で、メンバーの自発的なチャレンジには積極的にナッジングし学びに昇華することでチームのケイパビリティ向上に繋げ、生じた結果の責任は EM が負う感じで学びをチーム組織に蓄積貢献していきたい所存。

👥 リーダーシップシフト雑感

Sun, 27 Oct 2024 00:00:00 +0000

先ほど下記の本を読み終わって、色々と気づきがあったので書き留めておくことを目的に記事を書き始めたのだが、調査の過程で更に思考が深まったのでそれを一旦雑に書き散らしてみる。

リーダーシップ・シフト　全員活躍チームをつくるシェアド・リーダーシップ | 堀尾志保, 中原淳 |本 | 通販 | Amazon

まず記事を書くに当たり色々調査したところ、実はマネージャーのスタイルには種類が複数あり、適切に発揮することが大切であることを知った。

管理職として知っておきたい7つのマネジメントスタイル | Indeed (インディード)

またリーダーシップにも多種多様なタイプが存在しており、個人の特性によって使い分けを意識することが大事であることについても言及があった。

11 種類のリーダーシップ徹底解説: 自分に合ったスタイルの見つけ方 [2025] • Asana

令和時代の理想のリーダー像と 11 種類のリーダーシップを解説。自分に合うスタイルを理解し、チームを導く力を高めるヒントがわかります。

🔄 交流を図るためのふりかえり

Sun, 27 Oct 2024 00:00:00 +0000

最近チーム定例のアジェンダの先頭に “ふりかえり” という項目を用意して、雑多に箇条書きで書いた内容をシェアするだけの取り組みを行なっている。それがめちゃ上手くワークしてる気がするので言語化しておく。

端的に言うと下記がチーム内部で発生しているように見受けられる。

カジュアルなタスク等のシェア内容から生まれる雑談が楽しい

ウィンセッションのようなやり取りで自己効力感も増している
各メンバーがお互いに興味関心を持つようになったと感じる

雑談から相談に繋がることも多く、雑相が自然発生している
リモート MTG にも関わらず、自然と全員ミュートオフで参加している
- ミュートオフやリアクション推奨などのルールは一切設けていない

カジュアルに “ふりかえり” というアジェンダを入れたのは、EM として各メンバーを定性的に評価可能なログとして残したい意図があったのだが、チームビルディングに繋がる効果があったのは意外だった。

チームメンバーの大半がリモート勤務していることも関係しているのかもしれない。対面でなくバーチャル上で心から対話を楽しめるようになることは自然な自己開示にも繋がり、仲間意識が強まる効果はありそう。

このようなバーチャルな交流は、同僚のことを、より偽りがなく、人間的で、信頼できる人間だと認識させる作用があることがわかった。個人的な絆を育む上でも、仕事で協力関係を築くうえでもプラスになる資質だ。

他のアジェンダには、“課題共有” や “雑談コーナー” など用意していたのだが、カジュアルな “ふりかえり” を用意するだけで不要になった。

形式的な定例 MTG は大体システマチックになりがちで、主体的な参加を求めるのが難しいイメージがあるが、メンバー間の対話をコーディネートするイメージで開催するとマンネリ化が防げるようになるのやも。

🤝 連携のための礎を築く

Sun, 27 Oct 2024 00:00:00 +0000

最近働いていて、チームで動けてないという話をよく聞く。チームで動けていないということを深掘りしていくと、連携がうまく取れない旨の課題を伝えられることが多い。連携がうまく取れるとはどういうことなのか。

連携自体は各職能ごとでは日常やっていることのように思う。適宜状況をシェアして協力することは、どこでもやっているだろう。ただ、連携のレベルを職能間で上げることは、同職種内でレベルを上げるより難しい。

職種間でセクショナリズムが問題になることはよく聞く話である。が、最近コレが本質的な原因なのでは？と思うことが 1つある。それは、他の職能について興味を持てていないのでは？ 、と言うことである。

例えば、業務をスムーズにするために連携したいというコンテキストが存在する中で、他チームの状況を具体的に知りたい欲求があるとする。

自分たちの業務の状況は明確に把握しているため、他チームから状況を引き出したい。ただ、他チームとしては対話を通じて丁寧にコンテキストを共有してくれないと、一方的に頼まれていると感じるだろう と思う。

コンテキストは、その発端となった事柄や検討の経緯など他者が腹落ちした意思決定を行うのに必要な情報を指す。つまり、頼まれた側にも連携したいと感じてくれるためには、納得してもらうフェーズが必要だと思う。

ココで他の職能に対しての興味を持っているかどうかが響いてくると感じている。 一方的な視点から連携を求めたところで相手の理解は得られず、精々得られたとして、形式的な進捗連絡が行われるのが関の山だろう。

対話を通じて興味があると相手に感じてもらい、双方が歩み寄るスタンスになって、初めて連携というワードを出すのがタイミングとしてちょうど良い気がしている。まず下地として相互理解を深めるイメージ。

表面上の連携を行うことは無駄なプロセスを作ったり、本質的でない刹那の解決策を取ることにも繋がり、特にリーダーほど「早く問題を解決しなきゃ」と善かれと思ってやってしまいがちなことかもと感じる。

相互理解が十分深まった上で、気を遣わずに色々と率直に話せるようになり、初めて本質的な対話が可能になるイメージがある。 そこからは、相互に連携を図るための議論が建設的にできるイメージがある。

そう考えるとチームで仕事をするレベルを上げていく最も初期段階に必要なのは、気を遣わずに話すための土台を構築することなのかもしれない。

ワイワイ話せるだけではなく、気を遣わずに相互に率直に感情や意見が吐き出せる状態を、連携可能な状態だと認識しておきたい。 結局、相互理解のための努力を怠らない事が大事ということなのかも。

P.S. 所謂、心理的安全性で言われることだなーと見返して思ったけども、連携を図る上で最初期に行うべきフェーズとして見落としがちやも。

👴 おじいちゃん子

Sun, 20 Oct 2024 00:00:00 +0000

ふと ↑ を久しぶりに聞いて、亡くなったおじいちゃんのことを思い出している。Fantom が出てから 1年後におじいちゃんは亡くなった。“道” は亡くなる直前のお見舞いを毎日していた頃から何度も聞いていた思い出深い曲である。

おじいちゃんが亡くなる直前は何も考えたくなくて、夜に音楽を聴きながら無限に散歩していたことを思い出す。歩きながら思い出を振り返り、散歩しながらずっと泣いていた。(すれ違った人からすれば恐怖だったかもしれない…w)

社会人になって、おじいちゃんからは定期的に電話を貰っていた。直接会って話す機会は、社会人になってからは稀な状況だった。

月並みだが、今思うと直接会う機会を設けたり、一緒に温泉旅行とか行って色々恩返ししたかったな。

大切な思い出や当時の思いを書き残しておくことで、おじいちゃんに対する想いの供養に繋がりそうだなと思ったので、つらつらと雑に文章で残してみる。

自分は幼い頃から兄弟の中でも特に祖父に可愛がられていた。幼い頃はよく仕事のトラックに乗せてもらって、道中のコンビニで必ず欲しいものを買ってもらっていた。今でも毎度コーヒー牛乳を買ってもらってたことを思い出す。

おじいちゃんの家に行くと毎回必ずジャガイモのお味噌汁を作ってくれた。しょっぱい味付けが凄く好きだった。そのことをおじいちゃんに伝えたら、家に行くたびに作ってくれるようになったのだ。

小学生の頃はゲームやおもちゃはなんでも買ってくれた。手を繋ぎながら地元のシータというゲームショップに通った思い出や、当時の店内の詳細な様子など今でも思い出せる。おじいちゃんに何かを頼んで断られた記憶は一切ない。

ゲームを買ってもらった後はおじいちゃんの家で夢中になって遊んでいた記憶がある。五時を超えても遊んでいると親からおじいちゃんに電話があった。まだ遊び足りない時は親に泊まって行くとよく伝えて、実際に泊まっていた。

親は何故かおじいちゃんのことが気に入らない様子だった。悪態を吐いたり、キツく当たることも多かった。親とおじいちゃんが一緒の場にいる時は物凄く辛かった記憶がある。いたたまれない気持ちが抑えられず心を無にしていた。

こんな優しいおじいちゃんに対して、強く攻撃する言動が親から出るのを見るのは耐え難く、よく自分の部屋に避難したことを覚えている。その後知ったのだが、実はおじいちゃんは僕以外には厳しく当たるエピソードが多々あった。

しかし、僕にとっては優しいおじいちゃんだったので、よく親に不快だから攻撃的な言動は止めてくれと言った覚えがある。その時は「あなたは特別おじいちゃんから大切にされてるもんね、ごめんね」と言われたことも覚えている。

高校生で引きこもり気味になった時は、よく「コンビニに行くけど何か買ってくるものはあるか？」と聞いてくれた。「何もないよ、大丈夫」と言っても、おにぎりやサンドイッチを必ず買ってきてくれていたことを思い出す。

今思うと色々気にかけてくれていたんだろうなと思う。学校に行く時は家を出る前に「お金はあるか？」とよく聞かれた。あるよと言っても何かあった時のためにと、五千円もくれていた。お金は使わずにずっと貯めていた。

大学生になってアルバイトを始めてからも上記は変わらなかった。その後地元が大嫌いだった僕は社会人になった直後に引越し先を決め、一人暮らしを始める。当時そのことを切り出した時は親が家を出るのを止める中、おじいちゃんは何も言わず普段通り接してくれていた。

今は子供が二人いる身だから分かるが、気にかけている子供が一人暮らしを始めると言い出したら、止めるまでは行かなくても何か言っておきたい事の一つや二つくらいありそうだ。しかし、おじいちゃんからは何も聞かなかった。

おじいちゃんは定常的に具合が悪くなっても、稀に実家に帰ることがあると、必ず自分の部屋から出てきて僕と会話をしてくれた。その度に親はおじいちゃんに対して「大丈夫か？」と聞いていた。

親に聞いたところ、関節が痛く歩くのも相当辛い状況なのに愚痴一つ吐かず部屋から出てくるのは、僕が実家に戻ってきた時だけとのことだった。嬉しかったが、同時におじいちゃんに辛い思いをさせている罪悪感があった。

時間も経ち、そんな事が何度かある中、おじいちゃんが仕事中に倒れたという連絡が来た。脳出血とのことで、命に危険があるのですぐに来て欲しいと言われ、仕事を抜けて病院にタクシーで向かったことを覚えている。

到着してから病室で対面した時の衝撃は今でも覚えている。いつも優しく接してくれていて普段と変わらなかったおじいちゃんが、良くテレビで見る危篤な状態の様子になっているのを見て、悲しみよりも虚無が襲ってきた。

病室に到着してからは家族が、一番関係の深い僕が一対一でおじいちゃんと同じ空間に居られるようにと、病室から出てくれた。

しばらくおじいちゃんはずっと目を閉じていたのだが、一瞬だけ目を開けてくれた。その時に目があったのだが、自分と目が合うと目を見開いて手をこちらに差し伸ばしてくれた。

本当はその時にこちらからも手を伸ばすべきだったのだが、自分は情けないことに目を逸らして目を瞑ってしまった。今思うとおじいちゃんの死を認めたくなかったのと、涙を見せたくないという思いでそうしてしまったのだと思う。

その後泣くのが落ち着きおじいちゃんを見ると、辛そうな顔で寝ていた。どう言った感情だったのかは分からないが、自分の取った行動に絶望してしまったのだとしたら本当に申し訳ないことをしてしまったなと思った。

そこからはとても早かった。毎日面会時間目一杯通っていたが、五日後には病院の先生から緊急で呼び出されて、最後の時間と宣告された。親は仕方が無いねと、穏やかにその様子を見守っていた。

その瞬間が来たときはもちろん泣いた、が、病室で最初に対面した時よりは泣かなかった。恐らく毎日面会して帰宅後泣いてたことに加えて、ある程度準備が出来てたからだろう。物心ついてから初めて身近に死を感じた瞬間だった。

その後、法要を済ませた後は、すぐに仕事に復帰した。何故ならおじいちゃんだったら、ずっと自分のことで悲しまずに自分の人生を生きて欲しいと言うだろうなと思ったからだ。今までの接し方から、なんとなくそう感じた。

できればおじいちゃんには結婚したり、子供が出来るまで生きてて欲しかったな。今まであまり良い姿が見せられなかったので、重要なライフイベントを親よりも見てて欲しかった。ただそれは自分の祈りに近いエゴであると感じる。

自分はおじいちゃんから多大な影響を受けている。人に優しくあろうとしたり、自分がされて嫌なことは絶対にしないとかは、その典型である。

そう言った特性は子供達にも受け継いでいきたいなと思うが、おじいちゃんは「そんなことしなくて良いよ」とか言いそうだな。

👶 育児エンジニアの学び

Sun, 13 Oct 2024 00:00:00 +0000

突然だが刃牙という漫画に郭海皇という人物がいる。

真なる強さを求めて独自に『理合』の鍛錬を重ね、気の遠くなるような月日の中、これまでの自身の強さの象徴にして結晶であった自慢の鋼の肉体が衰えていく絶望に耐えながら、ひたすら研鑽を積み重ねるという人生を歩み、現在に至る。

上記は仕事に言い換えると、仕事にアイデンティティや楽しさを感じるほど積極的に取り組んでいた人が、強い制約の中持続可能な仕事への取り組み方にシフトするようなものだと感じている。

自分はまさに上記の状況に当てはまるエンジニアなのだが、どのように足掻きながらシフトしていったのかを、自らの記憶ために書き記していく。

前提

家庭環境はご家庭によって千差万別なため僕の環境を前提として記してみる。

共働きでお互いフルリモートの環境で働いている
育児家事の分担は、大体育児を僕がやって家事は奥さんがやっている
- 平日は朝と夕方までの家事を行なっている
- ↑ は仕事の状況によってはできないこともある
休日は家族で過ごしている
- 基本的には子供が楽しいと思える時間が過ごせるように頑張ってる
- 故に休日・祝日・連休の方が体力を消耗しがちで疲れる…w
平日は基本 10:00-16:30 の間だけが全力で働ける時間（コアタイム）
- 夫婦間の合意事項として、子供達が寝るまでは個人行動は無し
子供は 3歳と 2歳と 0歳がいる
- 第三子は言わずもがな睡眠は安定せず、第二子は暴れ盛りで、第一子は生活リズムが安定してきている感じ
夫婦共々両親はお互いに未だ現役で働いている
- そのため、親を頼るだとか預けるだとかのムーブは不可能

学び

基本姿勢として、一旦全てを捨てさることが超重要だった
- 最初の 1年くらいはもがいていたが、途中から全てを投げ捨てた
- 何かにチャレンジするとか、余暇で遊ぶとか勉強とか不可能だった
独身時代の習慣を持ち込もうとすると、全て家庭トラブルに繋がった
- 習慣を捨てるのはメチャ難かったが、意識的に捨てた
- 育児が始まったら、熱中できる趣味も捨てざるを得なくなった
  - 一人で没頭してやる趣味とかは育児始まったら不可能だった
新たな日常に体を慣らすことに全力で意識を傾けた
- 体と心が新たな生活に馴染んでくるまでは何も考えなくて良かった
- 育児やってると勝手に筋肉とか体力とかも時間経過で付いてきた
仕事はほどほどで、家庭に全振りでバランス的にはちょうど良い
- 育児が始まると家庭が戦争になるので、仕事に全力になるのは無理
- 仕事を頑張りたいっていう人ほど辛いのは分かるが、耐えた方が良い
- 仕事で自分が居なくても問題無い状態を、本気で自分事で捉えられる
  - 結果メチャ自分のレベルが上がった実感が得られた（仕組み化）
- 自分が頑張らなきゃ、で踏ん張ると色々積む（夫婦の時間も取れない）
夜に頑張れば良いやとか、夜に遅れを取り返せば良いやの考え方は終わる
- 仕事が溜まってようが、眠くなったら絶対に寝るのを優先した方が良い
- 仕事の評価とかどうでも良い、夜眠い場合は仕事を捨てて寝る
- 低年齢の子ほど寝かしつけに成功したら、一緒にそのまま寝る
  - 深夜に起きまくるので、寝れる時に回復するために寝る心算で
朝眠い状態を迎えてしまうと、その日一日をドブに捨てることになる
- 独身なら色々融通効かせられるが、育児中は融通が効かせられない
一日のうちに何かしら自分の時間が取れて、趣味・勉強とかできたら偉業
- 早朝 ~ 始業時間にかけてやりたいことやる習慣をつける
  - 育児中は早朝 ~ 始業時間以外の時間帯は不確定要素が多すぎて、やりたいことはほとんど出来ないと言っても過言ではない
  - 夜型の人も、半強制的に朝型になるので朝に活動の比重を傾ける
色々な事柄で楽することに全力を傾ける
- 育児家事仕事全般で楽することに全力を傾けることが結果良い
- 色々楽に対応可能になってくると、今現在に意識も傾けやすくなる

結論

良い意味で脱力して手が抜ける状況を色々地道に作り続けていく
- 育児は長期に渡って行うため、持続可能な思考や仕組みを作る
- 本当の自分とか意識しない、持続可能じゃない要素は全て捨て去る
家庭環境はそれぞれで全く異なるので他の家庭ではとか考えない
- あの人は育児中なのに色々出来ててすごいとか考えなくて良い
自然体で生活が出来、気力が湧いて、初めて自分のための行動で全然良い
仕事よりも家庭の方が大切
- 家庭は一度崩れたら立て直すのが大変すぎる
- 取り返しが付かなくなるリスクもある（特に育児関連は揉めやすい）
- 仕事はどうとでもなると思うが、家庭は無理なため全力でコミットする
やりたい事も何もかも捨ててくと、セルフコントールできるようになる
- そうなると何が起きようが、対して精神力を削られずに済むようになる
- 自分がやろうとしていたことが中断されようが何も感じなくなってくる

育児奮闘中から日常になるまでの学びを書いてみたが、改めて思い返すと総じて無理をするなっていう感じだな。あの人はできているのに、あの人は凄い仕事ができるしコミットできてるのに、とかも当初はめっちゃ思ってたなー。

💬 即時性の無いコミュニケーションも大切にしたい

Sat, 12 Oct 2024 00:00:00 +0000

自分は同期的コミュニケーションが苦手だ。対話を行う際のリズムが他者と比較して遅いので、その場で満足の行くコミュニケーションが取れたことは今までのことを思い返してみても無い。

同期コミュニケーションは基本的に始めた側のリズムに合わせることが多く、それに合わせる形で相互に気持ちを通わせることが目的であると感じる。

そこにはバンドセッションのような、空気に合わせてみんなで作品を作り上げる感覚がある。その場で満足できる時間を作ることが主目的だと感じる。（もちろん、それはそれでかけがえの無い時間であると感じる）

ただ深く相互理解を行いたいと考えたときに、全体のリズムを重視したバンドセッションのようなコミュニケーションは辛いと感じてしまう。相手のことを深く考えて洞察するための時間が無いから。

その点、心境やプロセスを綴りながら書く文章でのやり取りはすごく好きだ。ただそれは軽量なチャットのようではなく、重厚な手紙のような文章である。

言語化し推敲や内省のプロセスを経た内容を見返してみると、相互理解以前に自身への深い理解に繋がることが多々ある。それを元にしたコミュニケーションができると、相互に意識的に心の対話ができる感覚がある。

自身の理解を経たコミュニケーションができた時の満足度は非常に高く、言いたいことが本当に言えた感覚が得られる。それは、自分の発言でさえ、本来深く洞察しなければ理解ができないものなのであろうと感じる。

そうなると他者への理解が容易で無いことも想像が付きやすくなり、他者とのコミュニケーションの際にレッテルを貼らなくて良くなるなと感じる。

つまり、自分が苦手であると感じる人物に対して不快感の前に、理解が足りないなという自覚に至りやすく、自分のような内向的な人間にコミュニケーションの戦闘力を授けてくれるような感覚がある。

そう考えると、自分のような即時性のあるコミュニケーションが苦手と感じる人たちには是非文章を、クオリティなど度外視で書いてみて欲しいと感じる。 （僕がそういった人たちの思考や文章をとても読みたいのもあるが…w）

そもそも散文的に文章を書くことは、とても創造的な作業で楽しいと、今この文章を書いていても心から感じる。最近は全く文章が書けてなかったけども、これからはボチボチ再開していこうかな。

P.S. しずかなインターネットのように散文的に文章が書けて、似たような人たち同士で偶発的に閉じた交流ができるようなアプリとかって無いのかな…w

📝 リスペクトの欠如が及ぼす自己効力感の喪失

Sat, 12 Oct 2024 00:00:00 +0000

他者の行動や判断、決断に不満を持つことは誰しもがあると思う。僕がそう感じた時に大切にしているのが、結論までのプロセスを聞くということだ。

プロセスを可視化し理解することで相手の思考軸を具体的に捉えることができ、受け入れることが出来ずとも、納得できるようになるからだ。納得ができればモヤモヤが晴れた状態で建設的な議論が行えるようになる。

ただ個人的には納得できるだけではダメで、相手と中長期的に関係性を気づいていく上では、リスペクトに至るまでが非常に大切だと感じる。 リスペクトまで至れない場合は、自らリスペクトできる点を積極的に探すべきだと思う。

対話を積極的に行いコンテキストを深掘りし、自らに無い視点や知り得なかった制約に気づくことで、リスペクトが抱けるようになることは案外結構ある。

何故理解だけでなくリスペクトまでが大事だと考えているかというと、人は感情を無視して論理だけでは持続的な行動ができないと考えているからだ。

例えば、上長の決断で進める施作に反対の立場だが、仕事上強くコミットせざるを得ないとする。その場合リスペクトがあれば、自分の取れうる手段でこの人に貢献せねばという理解からの行動に繋げられると思う。

自分の知らない分野での専門性に対してもリスペクトが持てれば、相互に力が発揮できる形での協力体制について想いを巡らせることもできるだろう。

もしリスペクトが無ければ、自分の方が上手くやれる自信があるのにと、感情が思考を阻み行動が思うように実行できないだろうなと感じる。結果として、本人の能力を最大限に発揮することは難しくなるだろうなと。少なくとも持続的な行動や協力するための行動は難しくなりそう。

頭ではリスペクトが必要だと理解しているのに感情が伴わない場合や、自身の能力に自信がある人ほど、特にこの状況に陥りやすいと感じる。

リスペクトが無いコミュニケーションというのは、案外色んな部分で本人の意図しない形で表出していて、それは結構外から見られていることがある。

そうなると、Disagree and commit の姿勢で物事に取り組んでいても、時間と共に相互の信頼関係にズレが生じてきてしまい、どちらかが無理をするか回避行動を取ってしまうだろうなという感覚がある。

それらを補うほどのインセンティブがあれば別だが、相当なプレゼンスがある人で無い限り、そういった機会が与えられることは一般的には無いと思う。

ここで一番厄介になるのが、自己効力感の喪失である。自己効力感は幸せに直結する要素の 1つであると考えているので、ここの主導権は失いたくない。

リスペクトの欠如がなぜ自己効力感の喪失に繋がると感じるかというと、周囲から理解の姿勢を得ることが難しくなり、孤立に繋がる点が挙げられる。対話の気力すら失ってしまうことに繋がり、悪循環が生まれるイメージ。

一度孤立してしまうと、周囲と繋がるためのコストが不必要に増大してしまい、信頼関係回復のために疲弊してしまいそうだなと感じる。もしくは時期尚早な回避行動を取ってしまいチャンスを逸してしまう懸念もありそうだなと。

ただし、自分の軸と照らし合わせた時に、どう頑張ってもリスペクトが全く持てない場合もあると思う。その場合は潔くその場を離れる判断をした方が良いと感じる。それは自分のためであると同時に相手のためにもなるだろう。

しかしそれは最終手段である。自身の今後を思えばこそ、異質な人とも支え合えられるような関係性が築けるようなスキルを身につけることは重要である。 それを具体に言語化すると、リスペクトなのであろうと帰結する自分がいる。

リスペクトが意識的に持てるスキルを身につけることは、多様性を認めた上で、自身の欠点を客観的に見られるスキルの言い換えなのかもしれない。

ちなみに僕は音楽が大好きなのだが、たまに全く普段聞かないようなジャンルを意識的に聴き始めることがある。最初は嫌いだと感じていたものも挑戦したりする。すると不思議なことに「あ、今だと聴けるな」となることがある。

そこからジャンルを深掘りすることで、確立された背景なども知ることができ、普通に音楽を聴く以上に感慨深い体験を得ることができたりする。リスペクトとは興味の幅を押し広げるスキルとも言えるのかもしれない。

論理的な思考が先行している人でも、リスペクトがスキルだと言われれば、案外容易に様々な人たちに対してリスペクトが抱けるようになりそうだなと感じる。いわゆる HRT と呼ばれるスキルセットとも呼べるのかもしれない。

そう考えると、リスペクトはシンプルに自身の可能性や自己効力感を高めるために身につけた方が幸せになりそうだなと感じるし、引いては周囲に対して幸福を与える人になれる可能性を秘めた素敵なものだなと感じてきた…w

📔 2021年の振り返り

Fri, 31 Dec 2021 00:00:00 +0000

はじめに

本記事のカバー画像は 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 年でした。来年は今年の変化を形にしつつものにしていく感じで行きたいです。記事にできそうな技術ネタもめっさ溜まってるので放出しまくりたいです。強めのエモネタもいくつかあるので、良さげなタイミングで放出したいです。

📔 ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する

Sun, 05 Dec 2021 00:00:00 +0000

はじめに

この記事は AWS Advent Calendar 2021 の 5 日目の記事です。

Fargate で Node.js アプリのメトリクスを Prometheus Agent をサイドカーコンテナとして動かして、Amazon Managed Service for Prometheus (AMP) に送信して Grafana で見られるようにしてみました。

ちなみに Promethus Agent はまだ実験的な機能なため、実務での利用は推奨しません。

本記事の環境構築には AWS CDK を利用しています。

動作環境

Node.js v16.13.0
AWS CDK 2.0.0 (build 4b6ce31)
Prometheus 2.32.1

環境構築

早速環境構築を進めていきます。まだ AMP については CDK から操作できないようでしたので、ワークスペースの作成については AWS コンソールから手動で行います。(2021/12/06)

aws-aps を利用することで AWS CDK からでも Amazon Managed Service for Prometheus のワークスペースを作成すること確認できましたので、そちらの利用を推奨いたします… 🙇🙇

lib/prometheus-agent-test-stack.ts のコードも修正済みで AWS CDK で Amazon Managed Service for Prometheus のワークスペースを作成するように編集しました。(2021/12/18 追記)

📔 Unity で iOS/Android アプリの設定値をセキュアに扱う方法

Sun, 15 Aug 2021 00:00:00 +0000

はじめに

iOS/Android でユーザーの情報をセキュアに扱う必要があったので、調査したところ Android には EncryptedSharedPreferences が存在することを知りました。iOS には Keychain Services が存在します。

今回は Unity の iOS/Android プラットフォーム上で設定値を保存するための実装を行う必要があったので、Unity から扱えるようネイティブプラグインを作成しました。今後もこういった要望はありそうでしたので、記事として手順や内容を書き記しておくことにしました。

本記事内で紹介しているコードは下記にアップ済みです。

GitHub - nikaera/Unity-iOS-Android-SecretManager-Sample: EncryptedSharedPreferences および Keychain Services を Unity から利用する Unity サンプルプロジェクト

EncryptedSharedPreferences および Keychain Services を Unity から利用する Unity サンプルプロジェクト - nikaera/Unity-iOS-Android-SecretManager-Sample

📝 Azure Cosmos DB でソートしようとするとフリーズする

Mon, 05 Jul 2021 00:00:00 +0000

MongoDB 用 API で Azure CosmosDB 向けの開発を行っていたのですが、sort 実行時にエラーが発生してしまいリソースが取得できなくなる問題が発生してしまいました。

結論から言ってしまうと、この Stack Overflow の回答通り対処すれば解決可能なのですが、簡易的に日本語でも解決策を記しておきます。

また、本記事内容の問題に遭遇したときに見つけたのですが、事前に Azure CosmosDB の Docker イメージを利用しておけば、CosmosDB 特有の挙動に気づけるようになるかもしれません。私は MongoDB の Docker イメージを利用して開発や動作検証を行っておりました。

公式サイトでの MongoDB 用 API でのインデックス管理についての記事を見ていくと下記の文言が出てきます。

クエリに並べ替えを適用するには、並べ替え操作で使用されるフィールドに対してインデックスを作成する必要があります。

そのため、例えば MongoDB の ORM である Mongoose の利用例でいうと、スキーマを定義する際に下記のようにソートに利用したいキーに対してインデックスを指定する必要があります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema1 extends Document {
  _id: string;

  // ソートしたいキーには index を付ける
  @Prop({ index: true })
  sort!: number;
}
const schema = SchemaFactory.createForClass(TestSchema1);
export const TestSchema1 = schema;

また、範囲検索を行いたい場合は各キーにインデックスを作成することで可能になります。

@Schema({ timestamps: { createdAt: "created_at", updatedAt: "updated_at" } })
export class TestSchema2 extends Document {
  _id: string;

  @Prop()
  start_at: Date;

  @Prop()
  end_at: Date;
}

// start_at と end_at で範囲検索を行いたいため、
// それぞれに unique インデックスを作成している
const schema = SchemaFactory.createForClass(TestSchema2)
  .index({ start_at: 1 }, { unique: true })
  .index({ end_at: 1 }, { unique: true });

export const TestSchema2 = schema;

地味な Tips のような記事ですが、割とハマりました。。この記事が同じ轍を踏んでしまっている方の参考になれれば幸いです 😇

📔 マイペースに技術研鑽を継続する方法

Fri, 25 Jun 2021 00:00:00 +0000

はじめに

本記事のカバー画像は tookapic from Pixabay の画像です。

技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。

昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃

ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。

技術研鑽のサイクル

自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。

「きっかけ」：実現したい開発アイデアが浮かぶ

Image by Hans Braxmeier from Pixabay

個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。

アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。

また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。¹

「行動」：開発アイデアを検証可能な形で実装する

Image by Sasin Tipchai from Pixabay

開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。

例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。

技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。

まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。

「みかえり」：過程で得たもの全てをアウトプットする

Photo by Greg Rakozy on Unsplash

成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。

上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。

成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。

具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。

ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤修一さんの Youtube 動画と同様の考え方に自然に至りました。

全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮

おわりに

現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。

また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違

この記事内容がどなたかの行動を起こすきっかけとなれれば幸いです！🙏

当たり前ですが NDA に触れるような内容を自身の成果として公開してしまうのは絶対にダメです。あくまでも一般的な技術知識のみを自身の得た知見として公開するというスタンスです。 ↩︎

📝 pytest で alembic のマイグレーションを行う方法

Thu, 24 Jun 2021 00:00:00 +0000

はじめに

FastAPI と SQLAlchemy を利用して Web API 開発を行っていた際、SQLAlchemy のマイグレーションツールである alembic を利用していました。

ただ E2E テストを書こうとした際に、pytest 実行中に alembic でデータベースマイグレーションを行う方法が分からず模索していました。結果的にマイグレーションのやり方は分かったものの一応今後も利用するかもしれないため、その内容を記事として残しておくことにしました。

本記事内で利用しているソースコードを含む FastAPI プロジェクトを GitHub リポジトリ上にアップしておいたので、詳細を確認されたい方がいればご参照くださいませ。

alembic でマイグレーションを行う

conftest.py にグローバルで利用するマイグレーション用の fixture を定義すれば OK です。

# conftest.py

import os

import alembic.config
import pytest
from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from sqlalchemy_utils import database_exists, create_database, drop_database

# テスト用の初期データを定義した module を import する (必要があれば)
# from .seed import users, contents


# 指定したパラメータを用いて alembic によるデータベースマイグレーションを行う
# 引数のデフォルト設定では全てのマイグレーションを実行するようになっている
def migrate(migrations_path, alembic_ini_path='alembic.ini', connection=None, revision="head"):
    config = alembic.config.Config(alembic_ini_path)
    config.set_main_option('script_location', migrations_path)
    if connection is not None:
        config.attributes['connection'] = connection
    alembic.command.upgrade(config, revision)


# テスト実行用にセットアップされたデータベースのセッション情報を扱う関数
# scope に session を指定することでテスト全体で一回だけ実行されるようにする
@pytest.fixture(scope="session", autouse=True)
def SessionLocal():
    test_sqlalchemy_database_url = os.environ['DATABASE_URL']
    engine = create_engine(test_sqlalchemy_database_url)

    # 既にテスト用データベースが存在していたら破棄する
    if database_exists(test_sqlalchemy_database_url):
        drop_database(test_sqlalchemy_database_url)

    # テスト用データベースを作成する
    create_database(test_sqlalchemy_database_url)

    # 環境変数 DATABASE_URL で指定したデータベースに対して、
    # マイグレーションを行いテスト実行に必要なテーブルを一括作成する
    # 第一引数に指定している alembic は `alembic init <環境名>` 実行時に指定した環境名を入力
    with engine.begin() as connection:
        migrate("alembic", 'alembic.ini', connection)

    Base = declarative_base()
    Base.metadata.create_all(engine)
    SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

    # テスト用の各種データを追加する (必要があれば)
    # db_session = SessionLocal()

    # for user in users:
    #     db_session.add(user)
    # db_session.commit()

    # for content in contents:
    #     db_session.add(content)
    # db_session.commit()

    # db_session.close()

    # テスト用データ追加後のセットアップ済みの状態で
    # テスト用に利用する SessionLocal を返却する
    yield SessionLocal

    # テストが全て終わったら、テスト用データベースを破棄して、
    # SQLAlchemy のセッションも切断する
    drop_database(test_sqlalchemy_database_url)
    engine.dispose()

FastAPI の pytest への適用例

上記を関数を利用する方法は各自のテスト環境によって異なると思いますが、一応私が FastAPI のテストコードを書く際に利用したソースコードを元に参考例を載せておきます。

📝 Chrome 拡張で 1つのウインドウを使い回す方法

Sun, 20 Jun 2021 00:00:00 +0000

Teemo という Chrome 拡張を開発したのですが、その際 1 つのウインドウを使い回す構成にしたいなと考えていました。

例えば何も考えずに chrome.windows.create を Chrome 拡張を開くたびに呼び出すと、呼び出すたびにウインドウが新規作成されてしまいます。そうすると、都度画面に不要なウインドウが出てきて邪魔になるだけでなく、手動で不要なウインドウを消す作業をユーザーに強いることとなってしまいます。。🙃

上記のような挙動が望まれるケースもあると思いますが、Teemo ではウインドウ間を頻繁に行き来するため、ショートカットを利用して拡張機能を呼び出すことを見込んでいました。そのため、ショートカットを利用して拡張機能を呼び出すたびにウインドウが新規作成され続ける挙動は望んでいませんでした。

1 つのウインドウを使い回すためには、chrome.windows.create 時に作成される window の id を保持しておきます。その後、Chrome 拡張が呼び出されるたびに window が既に存在するかどうかを保持していた id を元にチェックします。既に window が存在していた場合はそれを使いまわします。存在していなかった場合は、chrome.windows.create で window を新規作成します。

// window の id を保持しておくための変数
let vid = -1;

chrome.browserAction.onClicked.addListener(function () {
  // vid の値を元に Chrome 拡張で開いた window の取得を試みる
  chrome.windows.get(vid, function (chromeWindow) {
    // エラーが無く、既に window が存在している場合は、
    // そのステータスを { focused: true } にすることで最前面に呼び出す
    if (!chrome.runtime.lastError && chromeWindow) {
      chrome.windows.update(vid, { focused: true });
      return;
    }

    // 上記以外のパターンでは window を新規作成する
    chrome.windows.create(
      {
        url: "index.html",
        type: "popup",
      },
      function (window) {
        // 新規作成した window を使い回せるようにするため、
        // vid 変数に window の id を保持しておく
        vid = window.id;
      }
    );
  });
});

上記コードで 1 つのウインドウを使い回すことが出来るようになるはずです。✅

📝 Node.js パッケージを公開するための GitHub Actions を構築する

Sun, 20 Jun 2021 00:00:00 +0000

react-emoji-textarea の開発を行った際、リリースを作成したら自動的に Node.js パッケージにライブラリが公開される仕組みがほしいと考え、GitHub Actions でそれを実現することにしました。

その際、公式サイトに公開されている内容を参考に GitHub Actions を作成したのですが、そのまま利用すると私の環境では下記のエラーが発生してしまいました。

error Couldn't publish package: "https://registry.yarnpkg.com/@nikaera/react-emoji-textarea: You do not have permission to publish \"react-emoji-textarea\". Are you logged in as the correct user?"

上記のエラーについて調査しながら改修したところ、最終的に下記の GitHub Actions で Node.js パッケージを公開できるようになりました。secrets.NPM_TOKEN には NPM Token を登録します。

name: Node.js Package
on:
  # workflow_dispatch を追加して手動でも実行できるよう改修
  workflow_dispatch:
  release:
    types: [created]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "14.x"
          registry-url: "https://registry.npmjs.org"
          # registry.npmjs.org へアクセスする際は必ず認証を試みるオプションを追加
          always-auth: true
          # scope には自分のユーザ名を指定
          scope: "@nikaera"
        # .npmrc に https://registry.npmjs.org アクセス時に利用する認証情報を記載する
      - run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
      - name: Build react-emoji-textarea 😆💖
        run: |
          yarn install --frozen-lockfile
          yarn format
          yarn build
      - run: yarn publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

📔 チャットの短文作成に便利な Chrome 拡張機能を開発してみた

Sat, 12 Jun 2021 00:00:00 +0000

はじめに 📝

最近とある事情により Twitter の DM を利用しているのですが、Slack などのように絵文字をショートカット入力できないことにフラストレーションが溜まってきていました。そのため、絵文字をショトカで入力可能にしてくれる Chrome 拡張機能を探したのですが見つけられませんでした。

そこで、無いなら作ろうということで Teemo を開発しました。

ソースコードは GitHub 上で公開しています。何かご要望等ございましたら PR や Issue 作成頂けますと喜びます。Teemo の実際の挙動については下記の動画で確認できます 🎥

考えていたこと 💭

今回 Teemo の開発を行うに当たり、考えていた点は下記になります。

よくある : 入力からの絵文字ショートカットを導入する
- Slack や GitHub、JIRA などではおなじみの入力方法 ⌨️
パレットから選択する際は半角英数字で検索できるようにしたい
- Twitter では日本語で検索しないと絵文字が探せない 🔍
- 普段英数字で絵文字検索をするので目的の絵文字が見つけづらい 🕵️
拡張機能を利用することで文章入力の煩わしさが増加することは避けたい
- コピペや文章クリアの機能等にもショトカ利用できるようにしたい 💨

プロトタイピングしながら友人に進捗をシェアしながら開発は進めていきました。本当は個人で利用する想定で進めていたのですが、割と評判が良かったため Chrome ウェブストアに公開するのを目標に動いていました。そして、Chrome ウェブストアで公開できるクオリティを目指して動いたことで満足のいく拡張機能が作れました。

📔 GameCI で Unity の CI 環境を GitHub Actions で構築する

Sat, 29 May 2021 00:00:00 +0000

はじめに

先日同僚が Unity の CI 環境を構築するためのライブラリである GameCI について教えてくれました。早速 GameCI の GitHub Actions を利用して、サンプルプロジェクトで色々動作検証してみたところ、Unity の CI 環境を楽に構築できることが分かりました。

もちろん、Unity Cloud Build を利用すれば CI 環境の構築は以前から楽にできました。しかし、選択肢の 1 つとして GameCI を持っておくことで、サクッと GitHub Actions に統合する形で Unity の CI 環境を導入できるのは他には無いメリットを感じました。

本記事で紹介しているソースコード、及び検証時に利用したプロジェクトは GitHub にアップ済みですので、手っ取り早く内容を把握されたい方は下記をご参照くださいませ。

GitHub - nikaera/Unity-GameCI-Sample: Sample project for building a CI environment for Unity using GameCI with GitHub Actions.

Sample project for building a CI environment for Unity using GameCI with GitHub Actions. - nikaera/Unity-GameCI-Sample

📝 Rails で config/database.yml よりも ENV['DATABASE_URL'] の設定が優先される話

Sat, 29 May 2021 00:00:00 +0000

MySQL を利用する Rails プロジェクトを起動しようとしたところ、下記のエラーが発生しました。

bin/rails s
# データベースアダプターには mysql2 を選択している状態なのに postgresql で接続しようとしている
Error loading the 'postgresql' Active Record adapter. Missing a gem it depends on? pg is not part of the bundle. Add it to your Gemfile. (LoadError)

# config/database.yml ファイルの中身一部抜粋

# mysql2 をデータベースアダプターとして利用しているため、
# PostgreSQL 接続のための pg ライブラリの追加を求めるエラーが発生しているのは何かおかしい。。
default: &default
  adapter: mysql2
#...

何でや、、と思い Rails のドキュメントを読んでいた所、公式サイトに Connection Preference に関する記述を見つけました。

Since pool is not in the ENV[‘DATABASE_URL’] provided connection information its information is merged in. Since adapter is duplicate, the ENV[‘DATABASE_URL’] connection information wins.

📝 Pillow を使って画像に縦書きテキストを埋め込む

Sat, 22 May 2021 00:00:00 +0000

はじめに

縦書きテキストを画像に埋め込みたいと頼まれたので、
Python 製の画像処理ライブラリ Pillow を使ってサクッと実装してみました。

一応ソースコードは Gist にもアップ済みです ✍️

Embedding Japanese vertical writing characters into an image using Pillow.

Embedding Japanese vertical writing characters into an image using Pillow. - main.py

📔 Zenn の記事を DEV に自動的に同期させる GitHub Actions 作ってみた

Sun, 21 Mar 2021 00:00:00 +0000

はじめに

去年 DEV のアカウントを作成したものの、今まで全く有効活用出来ていませんでした。

DEV にはカノニカル URL を設定出来るので、常々 Zenn の記事を投稿する際にクロスポストしたいなと考えておりました。そこで、Zenn に記事を投稿したら、自動的に DEV にも記事を投稿 & 同期する GitHub Actions を作ってみました。

GitHub - nikaera/sync-zenn-with-dev-action: Just sync Zenn articles to DEV.

Just sync Zenn articles to DEV. Contribute to nikaera/sync-zenn-with-dev-action development by creating an account on GitHub.

📔 Gatling で複数ユーザ認証した情報を元に負荷テストする

Mon, 15 Mar 2021 00:00:00 +0000

はじめに

今までは JMeter でしか負荷テストを行ったことなかったのですが、最近 PlayFab で CloudFunction の負荷テストを行う際に Gatling を初めて利用しました。

今回の負荷テストでは、各ユーザ毎のレートリミットの制限等も考慮した実利用時を想定した形で行うことが要求されたため、単一ユーザの認証情報を使い回すことは望ましくないと考えました。そこで、複数の認証済みユーザの情報を元に PlayFab の CloudFunction の負荷テストを実施したのですが、若干実装に苦戦したため手順について記事として残しておくことにしました。

また、本記事では Gatling のセットアップから記載していますが、該当コードやその説明を早く見たいという方は 複数ユーザ認証を行うテストシナリオを実装する 項目をご参照ください。

動作環境

macOS Big Sur
Java OpenJDK 12.0.1
- 未インストールの方は事前に公式サイトから OpenJDK をインストールしてください

Gatling の環境を整える

Gatling には 2 種類のセットアップ方法が用意されています。 スタンドアローンなツールを直接公式サイトからダウンロードするか、Maven や sbt といったツール経由でダウンロードするか選択できます。

どちらの方法でセットアップするかについてですが、新規でテストケースを Gatling で書いていく用途だと前者になり、既存のプロジェクトに Gatling を取り込む用途だと後者になるかと存じます。

本記事では、前者のスタンドアローンなツールを直接公式サイトからダウンロードする方法で Gatling の環境をセットアップします。

公式サイトから Gatling をダウンロードする

Gatling のトップページに遷移して、ページを 2 Ways to use Gatling の項目までスクロールした後、ダウンロードボタンをクリックします。

DOWNLOAD GATLING'S BUNDLE にある DOWNLOAD NOW ボタンをクリックする

ファイルダウンロード後はダウンロードした zip ファイルを適当なフォルダに展開して配置します。早速ターミナルで展開したフォルダ内にある ./bin/gatling.sh を実行して、正常にコマンドが実行できるか確認してみます。

📔 PlayFab の API 制限に引っかかった

Sun, 14 Mar 2021 00:00:00 +0000

はじめに

PlayFab で CloudFunction を利用しているときに API 制限に引っかかってしまいました。負荷テストをした際に初めて気づいたのですが、公式ページにも言及が無かったため発覚が遅れてしまいました。そのため、PlayFab に依存していた機能を部分的に外す必要が出てきてしまい苦労しました。

本記事では、上記のような事態に陥る方を減らすため、API 制限に気づくまでの軌跡を辿りながら、PlayFab の CloudFunction を利用する際の注意点について、記事として残しておきたいと思います。

PlayFab の API 制限に引っかかった要因

PlayFab の CloudFunction を利用すると、PlayFab 経由で独自 Web API を実行することが可能になります。また、CloudFunction 経由で独自 Web API を実行すると、PlayFab ユーザ情報が含まれたパラメタが含まれた状態でリクエストが飛んでくるため、その情報を利用することでサーバーサイドで PlayFab の操作を行うことが出来るようになり大変便利です。

そのため、あるプロジェクトでは PlayFab CloudFunction を Azure Function や AWS Lambda のような FaaS を使っている感じで利用しておりました。そして、その利用の仕方は誤りであったことに後々気づきます…

負荷テストを実装するフェーズで CloudFunction を大量に叩いてみる

PlayFab の CloudFunction を実行するにあたり利用した PlayFab の API は Server-Side Cloud Script - Execute Function というものになります。

同接 2000 人想定で負荷テストのシナリオを実装することが求められていたため、その通りシンプルに 2000 件同時に Server-Side Cloud Script - Execute Function を実行するシナリオを Gatling で組んでみました。すると、何回やっても数十件以上は必ずエラーが発生していることが分かりました。

📝 Jest で private readonly な値をモックする方法

Sun, 07 Mar 2021 00:00:00 +0000

Jest でクラスの private readonly な変数を差し替えたい時に若干引っかかったのでメモっておきます。タイトルでは Jest とありますが、本記事の内容は JavaScript でモックする際の有効な手法の 1 つとして利用することが可能です。

結論から言うと変数を差し替えたい場合は下記のような記述になります。

const mockValue = "";
Object.defineProperty(service, "privateReadOnlyValue", {
  value: mockValue,
});

ちなみに関数を差し替えたい場合は下記のような記述になります。

Object.defineProperty(service, "privateSumFunction", {
  value: jest.fn((a, b) => a + b),
});

各種テストケースで使いまわしているインスタンスの private readonly な変数をモックした場合、値をリストアしたいケースも出てきました。その場合の記述としては、下記が有効でした。

// tmpService 変数に service インスタンスを clone して利用する
const tmpService = Object.create(service);
Object.defineProperty(tmpService, "privateReadOnlyValue", {
  value: "",
});

参考リンク

📔 Vercel の定期デプロイを GitHub Actions で実現する

Thu, 04 Feb 2021 00:00:00 +0000

はじめに

最近 catnose99 さんのチーム個々人のテックブログを RSS で集約するサイトを作った（Next.js）を利用させていただく形で会社のテックブログを構築しました。

Kadinche Tech Blog

カディンチェ株式会社は、エンジニアリングで社会的価値を生むことに特化した会社です。社会に向けた研究開発や実験を行いながら、物質的な豊かさではなく、知恵/経験的な豊かさを創出することに取り組みます。技術の発展こそ、人類の発展であるという信念を持ち、先端技術を用いた問題解決への意識を持って行動します。その一環として 2008 年の会社設立当初から、xR の受託開発に日々取り組んでいます。

📔 Actix web で HttpOnly な Cookie を設定する

Sat, 23 Jan 2021 00:00:00 +0000

はじめに

最近 Rust を勉強するため、Actix web で Bloggimg という Web アプリケーションを作りました。その際、セッション管理のために Cookie を利用したのですが、その際の手順及び設定方法についてまとめておきます。

本記事では Rust や Actix web のインストール方法については説明しません。Mac であれば brew install rustup して rustup-init した後、PATH に $HOME/.cargo/bin を追加するだけで大丈夫なはずです。詳細なインストール手順については公式サイトをご参照ください。

開発環境については VSCode の Rust Plugin がオススメです。Rustup で Rust をインストールしている場合、設定から Rustup の PATH を $HOME/.cargo/bin/rustup にするだけで利用可能です。設定手順の詳細はこちらをご参照ください。

動作環境

Mac mini (M1, 2020)
- Rust 1.49
- Actix web 3
- Serde 1.0

# Cargo.toml

[package]
name = "cookie_test"
version = "0.1.0"
authors = ["nikaera"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
actix-web = "3"
serde = { version = "1.0", features = ["derive"] }

サーバー側で Cookie を設定するため、HTTP レスポンスヘッダーに Set-Cookie を含める形でセッション情報をクライアントへ渡します。その際、最低でも Cookie の属性に HttpOnly と Secure、SameSite=Strict は設定します。実際の Cookie を設定するための Actix web でのサンプルコードは下記になります。

📔 AWS Lightsail Containers に Actix web をデプロイする

Sat, 23 Jan 2021 00:00:00 +0000

はじめに

Actix web で Web アプリケーションを作ったのですが、技術勉強も兼ねていたので、デプロイ先も今まで試したことがないものを試そうとしていました。そこで、日頃業務でも AWS を利用しているということもあり、去年末に発表された AWS Lightsail Containers をデプロイ先に採用しました。

AWS Lightsail Containers へのデプロイ自体は非常に簡単でした。また、デプロイにあたり Rust の Docker イメージ作成のやり方も学べました。今回はそのあたりの手順をまとめる形で記事として書き残しておくことにしました。

Actix web の Docker イメージを作成する

開発したアプリケーションでは React でフロントエンド開発をしていて、ビルドしたものを Actix web の public フォルダに配置する形で公開しています。そのため、下記の Dockerfile ではマルチステージビルドを利用しておりますが、本質的には FROM rust:1.49 以降の記述が Actix web に関するものとなります。

# React ビルド用のイメージ
FROM node:14.15.4-alpine3.10 as client_builder

ARG REACT_APP_API_URL
ARG REACT_APP_GYAZO_AUTH_URL
ARG REACT_APP_GA_UNIVERSAL_ID

WORKDIR /client
COPY ./client/package*.json .
RUN yarn install

ADD ./client .
RUN yarn build

# Actix web ビルド用のイメージ
FROM rust:1.49

# Actix web にアクセスするためのポートを公開する
EXPOSE 8080

# Actix web プロジェクトのフォルダをイメージに追加する
WORKDIR /server
ADD ./server .

# プロジェクトフォルダ内で `cargo install` してビルドを生成する
RUN cargo install --path .

# 不要になったファイル群を削除する
RUN ls | grep -v -E 'templates' | xargs rm -r

# React ビルド用のイメージでビルドした内容を Actix web ビルド用イメージに追加する
COPY --from=client_builder /client/build ./build
RUN mkdir tmp

# `cargo install` コマンドで生成したビルドを実行して Actix web を起動する
# 下記のコマンド名称は Cargo.toml 内の [package.name] に準ずる
CMD ["bloggimg-server"]

また、Docker ビルド時のオプション管理を楽にするため、Docker Compose を利用しました。単一の Docker イメージをビルドする際にも利用しておくことで、後々コンテナを追加して連携させたいときにも即座に対応できたりでオススメです。

📔 ブログを書く用途に特化した Gyazo のツールを開発してみた

Sun, 10 Jan 2021 00:00:00 +0000

はじめに

いつもブログ記事に載せるキャプチャ画像の編集 & アップロード先として Gyazo を利用させていただいているのですが、日々使っている中で不満に感じる点もちょくちょく出てくるようになってきました。

そのため、3 連休を用いて Rust の勉強がてら Bloggimg というウェブアプリケーションを作ってみました。ソースコードは MIT ライセンスで GitHub のリポジトリにアップしております。ちなみに最初は Gyazo for Blog という名称で開発をしていたため、本記事内のスクショには Gyazo for Blog という文字列が出てきますが、現在は Bloggimg という名称になっております。。

Bloggimg を開発したのは、ブログ記事を書く際に利用する画像のアップロードから加工、マークダウンとして利用するまでのフローを最適化したかったからです。ブログ記事を書く際に、記事内で用いるスクショ画像の加工や、そのアップロードにすごく時間を取られてしまうなーと日頃から感じていたのでそれを解決したかったのです。✅

開発中に得た知見等については別途技術記事として書いて残す予定です。

考えていたこと

今回 Bloggimg の開発を行うに当たり、考えていた点は下記になります。

画像の編集ツールは引き続き Gyazo に用意されているものを使う
- 既に最高に使いやすい 👑
キャプチャ画像をアップロードする際に、自動的に特定のコレクションに紐付けるようにする
- 技術記事毎にコレクションを分けて管理しているため、技術記事を書いている最中にアップするキャプチャ画像は全て特定のコレクションにまとまっていて欲しい
ワークスペースのようなツールを目指し、ブログを書く時だけに使える機能を開発する
- 例えば、ワンクリックで画像マークダウンの記述がコピーできたり、画像のアップロードをし直しやすくするため画像削除がお手軽に出来るよう削除ボタンに即アクセス出来るようにしたり…

特にアップした画像を 自動的に特定のコレクションに紐付けるようにする については本記事で紹介しているウェブアプリケーションを作成するキッカケとなった点なので外せない点でした。

使い方

Bloggimg の使い方についてご紹介いたします。

ログインする

Bloggimg を利用するためには、まず Gyazo アカウントでログインして頂く必要がございます。トップページの右上にあるログインボタンから Gyazo アカウントでログインします。

1. トップページ右上に配置されたログインボタンから Gyazo アカウント認証を行う

2. Gyazo アカウント認証が正常に完了したら、再度トップページを開く

3. トップページを開いた時に Gyazo にアップした直近の画像が確認できるはずです

📝 AWS Lambda で cron みたいに定期実行する

Mon, 04 Jan 2021 00:00:00 +0000

コンテナをホットスタンバイさせるために EC2 でインスタンス起動して cron で ping 飛ばしていたのですが、コスト的に勿体ないなーと思っていました。しかし、「AWS Lambda 使えばいいじゃん」という指摘を受け、確かにってなったので cron で定期実行していた ping 処理を AWS Lambda + EventBridge で置き換えました。

実は Heroku Scheduler とか使って同様のことをしていた時期もあったのですが、10 分毎しか実行できない制約があったりして使い勝手が悪かったので、後々も使っていけそうな知見な気がしたのでメモがてら記事で残しておくことにしました。

まず、AWS Console から Lambda サービスを選択して関数を新たに作成します。

1. AWS Lambda のトップ画面から関数作成のための画面に遷移する

2. 必要な情報を入力して Lambda の関数を作成する

関数が作成でき次第、ping 処理を書いていきます。http リクエストを行うためのライブラリとして Node.js の標準モジュール(https) を利用します。

Lambda 関数作成直後の index.js は下記のような記述になっていると思います。

// index.js
exports.handler = async (event) => {
  // TODO implement
  const response = {
    statusCode: 200,
    body: JSON.stringify("Hello from Lambda!"),
  };
  return response;
};

こちらを Node.js の標準モジュール(https) を利用する形で下記のように書き換えます。

📔 理解したを受け入れたと捉える人たちに辟易する

Sat, 02 Jan 2021 00:00:00 +0000

はじめに

本記事のカバー画像は Vladimir Fedotov による Unsplash の画像です。

最近「ちゃんと理解してくれた？」ということを聞かれた時に「理解したけど、そういう行動を取るつもりはない」というと、「理解してないじゃん」と言われることが何回かあったので、その時の対処法及び感じた心情などをこの記事で吐露したいと思います。

年始からこういう記事を書くのは気が引けたのですが、あまりにも本記事タイトルのような方と多く遭遇したため…

理解するということ

「理解する」というのは、相手の言動の意味が正しく分かったということを意味します。 その言動をそのまま自身に取り入れることは意味しません。例えば、犯罪者の行動理由が正しく分かったところで、それを自分の行動規範に取り入れることはしないはずです。

双方がコミュニケーションを取り正しく分かったという状態になっている前提ですが、「理解したけど、そういう行動を取るつもりはない」という発言を受けてから「理解してないじゃん」という言動を発してしまうのは勘違いも甚だしいです。

上記はもはや理解した・してないとかの次元ではなく、相手を自分の言動でコントロールしたいがために会話している状態と捉えられても文句は言えません。 一種のマインドコントロールに近いかもしれません。

ちなみにこの傾向は、直接話したいと言ってくる人に多いです。しかも、そういった人に限り相手の都合を考慮せずに何回も同期的なコミュニケーションを取ろうとしてきたり、スグに語気を強めて自分が不満であることを感情でアピールしようとしてきます。また、「絶対」とか「必ず」とか「必要」という言葉を不適切に多用する傾向が多いです。
例えば、突然語気が強くなったり、攻撃的なメッセージの後に「電話して」等送ってくる人らが該当します。更に特筆すべき事項としては 怒ったと思ったらいきなり優しくなる DV の典型的なパターンであることが多いです。

筆者はコミュニケーションは双方の歩み寄りが前提で成り立つものと考えている ので、そういったやり取りになってしまった場合は残念ですが、親戚だろうが親族だろうが関係なく断絶か、それが出来ない場合は自分から可能な限り距離を置くようにしています。

受け入れるということ

「受け入れる」というのは、相手の何らかの言動をそのまま自分に取り入れることを意味します。 相手の言動を理解した上で、自分が間違っていたり知識不足であった場合に、それを認めて言動を正しく自身に取り入れるということは視野を広げる上で重要です。

しかし、注意点として「理解してないけど受け入れる」場合は、自分で何も考えないで言動を取り入れることを意味するため危険です。

世の中には根気よく話せば伝え方を変える等の工夫をせずとも無条件にこちらを説き伏せることが出来ると思ってたり、一回考えを相手に話しきったらその思いが全て伝わり、勝手にこちらがその思い通りに行動すると思っている人が意外と多いです。

上記のような人物への対策としては、自分の言動の主導権を他人に握らせないが基本戦略となります。 そういった人物は会話のペースや話の進め方が自分勝手なことが多いので、そこで折れずに反応もせずに自分の意思は持ちつつ、適当にいなすような感じで話を流すと無駄に疲れずに済みます。

例外として、自分が相手の言動に勝手にレッテルを貼り一方的に理解したつもりで、「受け入れない」という選択肢を取ることはオススメしません。自分の視野を狭める行為だからです。

つまり、理解するという行為はどんな状況であれ双方が取り組むべきであるが、受け入れる行為はお互いに選択の自由があるという前提を忘れずにいるべきと考えます。特に、こちらが決める権利があるはずの選択肢を、逆も然りですが、どんな人物が相手だろうがコントロールする権利は一切無いのでそのような話が出たときは注意する必要があります。

いずれにせよ、受け入れるというのは行為は、理解という前提があった上での、主体的な行動の結果であるべきと考えています。

自分を押し殺して受け入れるということ

前項でも簡単に説明した、「理解してないけど受け入れた」状態のことを指しますが、その場合のメリット・デメリットは下記になると考えています。

メリット
- 相手の言動が 自分にとって 100% 正しかった場合 、自分だけでは対処できなかった問題を解決できる可能性がある
- 自分が納得することはないかもしれないが、 少なくとも相手を納得させることは出来る
  - あくまでも、少しの間は相手を静かにさせることが出来るかもしれない程度
- 自分で考える労力を割くことが出来る。物事を真剣に検討するのにはそれなりの労力がかかる
  - ただし、自分で物事を検討して行動するための方法が身につかない。他者に依存する
デメリット
- 無意識下に相手の意のままに行動させられる可能性がある
  - 経緯はどうであれ、自身の言動の責任は自身に帰属するため、責任を取る必要がある
  - 自分の言う通りに相手が動いてくれることが嬉しいと感じる人種は存在していて、その人達に面倒を見るといったような名目で監視されるようになる
- 自分が検討して取り入れたわけではないため、その結果の是非に関わらず学びが薄い
  - 結果を反省して、自分の知見として次に繋げることがしづらい
- 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく
  - 与えられた選択肢の中から最後に後悔しない決断が出来るのは自分しかいません
  - 選択肢の意味を正しく理解しないまま行動すると、失敗したときのダメージが大きくなります

上記を見ていただければ分かる通り、メリットは非常に薄い上に基本的にデメリットに直結するような内容が多いです。 つまり、メリットに感じる点は刹那的な効用であって、本質的には問題の要因でもあるということです。

また、上記の中で最も重要な観点は 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく という点です。筆者はこの点を生きていく上で非常に重要な点の 1 つと考えています。

その理由として、主体的に行動を起こすエネルギーが無くなると、1 日過ごす際の時間を有効活用できなくなったり、重要な決断をいつまでも先延ばしにしてしまうようになり、人生を楽しむ時間が削られていくと考えているからです。

要は、面倒だからと言って理解せずに受け入れたり、他人の意見に忖度して決断を行うという行為を繰り返してしまうと、時間を浪費したり、1 日に楽しい時間を過ごせる割合が減っていき幸せの総量が減るということです。

理解したを受け入れたと捉える人たちへの対策

まず距離を置くという対策をオススメします。反論や反発はオススメしません。時間を浪費するだけでなく、無駄にダメージを負わされる可能性が高いです。また、強い言葉で一方的にコミュニケーションを取られた後「反省している」「言い過ぎた」等の言葉で優しくされたとしても決して距離は近づけないでください。もしそれで距離を近づけてしまうと相互依存のような形になっていき粘着されやすくなります。

📔 2020年の振り返り

Thu, 31 Dec 2020 00:00:00 +0000

はじめに

本記事のカバー画像は 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 年もマイペースに色んなことにチャレンジしていければなーと思っております。

📝 React で highlight.js を適用する方法

Wed, 23 Dec 2020 00:00:00 +0000

Zenn.badge を作成する時に React に highlight.js を組み込もうとしたのですが、若干躓いてしまったので対処法についてメモっておきます。

React は既にプロジェクトにインストール済みと仮定します。

# 一応 React をインストールするためのコマンドは ↓
npm i --save react react-dom

まずは highlight.js を NPM or Yarn でインストールします。

# NPM で highlight.js をインストールする
npm i --save highlight.js
yarn add highlight.js

その後、React ソースコードに highlight.js を組み込みます。ソースコードの全体像は下記のとおりです。

import Head from 'next/head'
import styles from '../styles/Home.module.css'

import React, { useState, useEffect } from 'react';

/**
highlight.js を import する
*/
import hljs from 'highlight.js/lib/core';

/**
シンタックスハイライトしたい言語のみ import として登録する
今回は html をハイライトしたかったので xml を import した

デザインは highlight.js/styles/~ を変更することで調整可能
https://highlightjs.org/ のトップページから各種デザインについては確認可能
(コード右下にある style の右側リンククリックで各種デザインのプレビューが可能)
*/
import xml from 'highlight.js/lib/languages/xml';
import 'highlight.js/styles/github.css';

hljs.registerLanguage('xml', xml);

let inputChecker = null;
export default function Home() {
  const [user, setUser] = useState('nikaera');
  const [previewUser, setPreviewUser] = useState('nikaera');
  const [badgeCode, setBadgeCode] = useState('nikaera');
  const [style, setStyle] = useState('plastic')

/**
useEffect のタイミングで hightlight.js の初期化を行う。
called プロパティを false にすることで highlight.js で、
コードが変更された場合でも常にシンタックスハイライトすることが可能
*/
  useEffect(() => {
    hljs.initHighlighting();
    hljs.initHighlighting.called = false;
  });

  useEffect(() => {
    /**
    シンタックスハイライトしたいコード input フォームへの入力内容に応じて動的に変わる
    */
    setBadgeCode(`  <!-- Like のバッジ -->
  <a href="https://zenn.dev/${user}">
    <img src="https://zenn-badge.herokuapp.com/s/${user}/likes?style=${style}" alt="${user} likes" />
  </a>

  <!-- Articles のバッジ -->
  <a href="https://zenn.dev/${user}/articles">
    <img src="https://zenn-badge.herokuapp.com/s/${user}/articles?style=${style}" alt="${user} articles" />
  </a>

  <!-- Followers のバッジ -->
  <a href="https://zenn.dev/${user}/followers">
    <img src="https://zenn-badge.herokuapp.com/s/${user}/followers?style=${style}" alt="${user} followers" />
  </a>

  <!-- Books のバッジ -->
  <a href="https://zenn.dev/${user}/books">
    <img src="https://zenn-badge.herokuapp.com/s/${user}/books?style=${style}" alt="${user} books" />
  </a>

  <!-- Scraps のバッジ -->
  <a href="https://zenn.dev/${user}/scraps">
    <img src="https://zenn-badge.herokuapp.com/s/${user}/scraps?style=${style}" alt="${user} scraps" />
  </a>`);
  }, [user, style]);

  const handleChange = (event) => {
    if (inputChecker)
      clearTimeout(inputChecker);

    inputChecker = setTimeout(() => {
      clearTimeout(inputChecker);
      inputChecker = null;

      setPreviewUser(event.target.value);
    }, 1 * 1000); // 1 seconds

    setUser(event.target.value);
  };

  const handleSelect = (event) => {
    setStyle(event.target.value);
  }

  return (
    <div className={styles.container}>
      <Head>
        <title>Zenn.badge</title>
        <link rel="icon" href="zenn.svg" type="image/svg+xml" />
        <meta name="description" content="GitHub Profile に載せるための Zenn の各種スコアバッジを作成するためのウェブサービス" />
        <meta name="keywords" content="Zenn, GitHub, GitHub Profile, Shields.io" />
        <meta name="author" content="nikaera" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta property="og:url" content="https://zenn-badge.vercel.app/" />
        <meta property="og:type" content="website" />
        <meta property="og:title" content="Zenn.badge" />
        <meta property="og:description" content="GitHub Profile に載せるための Zenn の各種スコアバッジを作成するためのウェブサービス" />
        <meta property="og:site_name" content="Zenn.badge" />
        <meta property="og:image" content="https://zenn-badge.vercel.app/ogp_image.png" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://zenn-badge.nikaera.vercel.app/">Zenn.badge!</a>
        </h1>

        <p className={styles.description}>
          <a href="https://zenn.dev/" target="_blank" rel="noopener noreferrer">Zenn</a> のスコアを GitHub 風のバッジに変換するサービスです。
        </p>

        <div>
          <h3>注意事項 &rarr;</h3>
          <p>下記の事項にご留意ください。</p>
          <ul>
            <li>12時間ほどデータがキャッシュされます</li>
            <li>100%の動作を保証するものではありません</li>
            <li>APIの利用数制限などにより、表示されない事があります</li>
            <li>GitHub Profile にご利用ください</li>
          </ul>

          <h3>アカウント名を入力してください &rarr;</h3>
          <input type="text" value={user} onChange={handleChange} />
          <select name="style" value={style} onChange={handleSelect}>
            <option value="plastic">plastic</option>
            <option value="flat">flat</option>
            <option value="flat-square">flat-square</option>
            <option value="for-the-badge">for-the-badge</option>
            <option value="social">social</option>
          </select>

            { /* pre -> code タグ内に highlight.js で
            シンタックスハイライトしたい内容を出力する */ }
          <pre style={{ width: '80vw' }}>
            <code className="xml">
              {badgeCode}
            </code>
          </pre>

          <h3>プレビュー &rarr;</h3>
          <h4>Likes 👍</h4>
          <a href={`https://zenn.dev/${previewUser}`}>
            <img src={`https://zenn-badge.herokuapp.com/s/${previewUser}/likes?style=${style}`} alt={`${previewUser} likes`} />
          </a>

          <h4>Articles 📝</h4>
          <a href={`https://zenn.dev/${previewUser}/articles`}>
            <img src={`https://zenn-badge.herokuapp.com/s/${previewUser}/articles?style=${style}`} alt={`${previewUser} articles`} />
          </a>

          <h4>Followers 👱</h4>
          <a href={`https://zenn.dev/${previewUser}/followers`}>
            <img src={`https://zenn-badge.herokuapp.com/s/${previewUser}/followers?style=${style}`} alt={`${previewUser} followers`} />
          </a>

          <h4>Books 📚</h4>
          <a href={`https://zenn.dev/${previewUser}/books`}>
            <img src={`https://zenn-badge.herokuapp.com/s/${previewUser}/books?style=${style}`} alt={`${previewUser} books`} />
          </a>

          <h4>Scraps 🗑️</h4>
          <a href={`https://zenn.dev/${previewUser}/scraps`}>
            <img src={`https://zenn-badge.herokuapp.com/s/${previewUser}/scraps?style=${style}`} alt={`${previewUser} scraps`} />
          </a>

          <h3>問い合わせ &rarr;</h3>
          <div>
            下記 GitHub の Issue で <a className={styles.link} href="https://github.com/nikaera">nikaera</a> にメンションを付けてご連絡ください。
            <ul>
              <li><a className={styles.link} href="https://github.com/nikaera/zenn-badge">Zenn.badge</a></li>
            </ul>
          </div>
        </div>
      </main>

      <footer className={styles.footer}>
        制作者:&nbsp;<a className={styles.link} href="https://zenn.dev/nikaera" target="_blank" rel="noopener noreferrer">nikaera</a>
      </footer>
    </div>
  )
}

📔 Hugo で React + TypeScript を利用してサクッとウェブサイトに RSS リーダーを追加する

Tue, 22 Dec 2020 00:00:00 +0000

この記事は Static Site Generator Advent Calendar 2020 22 日目の記事です。

はじめに

Hugo のウェブサイトに組み込む RSS リーダーを TypeScript で開発してみたいと思い調査したところ、Hugo の最新版には ESBuild が組み込まれていて、非常に手厚く JavaScript の開発環境がサポートされていることが分かりました。 本記事では紹介していませんが Babel も利用できるようです。

また、NPM パッケージも利用できるため、普段のウェブ開発と同様の流れで開発ができ、各種ライブラリを用いた開発も非常に楽でした。今回は Hugo で JavaScript 開発する方法を RSS リーダーの開発を例に上げ、そこで得た知見についても交える形で記事として残しておくことにしました。

ちなみに本記事内容は Hugo で JavaScript 開発する方法に焦点を絞ったものなのですが、ウェブサイトに RSS リーダーを組み込むことに焦点を絞って見たい方は RSS リーダーを Hugo の Data Templates で実装する から見ていただくことをオススメします。

Hugo で JavaScript (React + TypeScript) の開発環境を整える

まず、TypeScript のビルドは ESBuild に任せることができるため何も行う必要はありません。 そのため React 開発用パッケージのインストールのみ行えば大丈夫です。

Hugo プロジェクトのルートディレクトリで下記コマンドを実行し、package.json を作成してから、React の開発に必要なパッケージをインストールします。

npm init -y
npm install --save react react-dom

無事パッケージのインストールが完了したら、早速 TSX ファイルを assets/js/App.tsx に作成してしまいます。

📝 Hugo で外部リンクを target="_blank" で開く方法

Thu, 17 Dec 2020 00:00:00 +0000

Hugo で設定した外部リンクを開くときは別ウィンドウで開けるようにしたかったので、Hugo のテーマファイルをオーバーライドして対応しました。外部リンクが設定されているときのみ a タグに target="_blank" rel="noopener noreferrer" が追加されるようにしました。

テンプレートファイルは GO の HTML テンプレートで書かれているので、その書式にしたがって a タグの属性を書き換えることで、外部リンクの場合は target="_blank" rel="noopener noreferrer" を追加します。

下記は hugo-PaperMod で、メインメニューの a タグに target="_blank" rel="noopener noreferrer" を追加するときのサンプルになります。

<ul class="menu" id="menu" onscroll="menu_on_scroll()">
    <!-- `.Site.Menues.main` の要素数 (メニュー数) ループします -->
    {{- range .Site.Menus.main }}

    <!--
        要素内の .URL にアクセスすることで設定されているリンクにアクセスする。
        設定されている URL のプレフィクスが https:// or http:// であれば、
        絶対リンクが設定されているはずなため、外部リンクが設定されているとみなす。
    -->
    {{- $is_abs_url := or (strings.HasPrefix .URL "https://") (strings.HasPrefix .URL "http://") }}

    <!--
        もし外部リンクが設定されていれば、そのまま .URL の内容を出力する。
        そうでなければ、内部リンクを language プレフィクスを付与した形で出力する。
    -->
    {{- $menu_item_url := (cond $is_abs_url .URL (printf "%s/" .URL) ) | absLangURL }}
    <li>
        <!--
            外部リンクが設定されていたら ($is_abs_url が true なら)
            a タグに target="_blank" rel="noopener noreferrer" を設定する
        -->
        <a href="{{ $menu_item_url }}" {{- if $is_abs_url }} target="_blank" rel="noopener noreferrer" {{- end}}>
            <span {{- if eq $menu_item_url $page_url }} class="active" {{- end }}>
                {{ .Name }}
            </span>
        </a>
    </li>
    {{- end -}}
</ul>

📔 MediaPackage 用の CloudFront ディストリビューションを AWS SDK で作成する

Tue, 15 Dec 2020 00:00:00 +0000

はじめに

とある事情で MediaPackage のエンドポイント用の CloudFront ディストリビューションを AWS SDK で作成する機会がありました。その際得た知見をソースコードを交えながら備忘録として記事に残しておきます。

本記事内容で紹介しているソースコードは Gist にも同じ内容でアップしてあります。

ちなみに MediaLive + MediaPackage + CloudFront の構成でインフラ構築したい場合は、CloudFormation が MediaPackage にも対応したので CloudFormation の利用を推奨します。

本記事内容はあくまでも何らかの事情で、後から CloudFront ディストリビューションを MediaPackage エンドポイントに紐づけたいケース等で参考になると思われます。

実装内容

作成したソースコードの内容は下記になります。最下部の createDistributionForMediaPackage が本記事タイトルに該当する関数です。

import { CloudFront } from "aws-sdk";
import * as url from "url";

import {
    CreateDistributionWithTagsResult,
    GetDistributionResult,
    UpdateDistributionResult
} from "aws-sdk/clients/cloudfront";

export class CloudFrontClientForMediaPackage {
    private cloudFront: CloudFront;

  constructor() {
    this.cloudFront = new CloudFront({
        region: "ap-northeast-1",
        apiVersion: '2020-05-31',
    });
}

/**
 * CloudFront ディストリビューションの情報を取得するために利用する
 * @param id CloudFront ディストリビューションの ID
 * @return ディストリビューションの情報を取得する
 */
  async getDistribution(id: string): Promise<GetDistributionResult> {
      const distribution = await this.cloudFront.getDistribution({
          Id: id
      }).promise()

      return distribution;
  }

  /**
   * CloudFront ディストリビューションの設定内容を取得するために利用する
   * @param id CloudFront ディストリビューションの ID
   * @return ディストリビューションの設定内容を取得する
   */
  async getDistributionConfig(id: string): Promise<CloudFront.DistributionConfig> {
      const config = await this.cloudFront.getDistributionConfig({
          Id: id
      }).promise()

      return config.DistributionConfig;
  }

  /**
   * CloudFront ディストリビューションを削除する
   * @param id 削除したい CloudFront ディストリビューションの ID
   */
  async deleteDistribution(id: string) {
    const distribution = await this.getDistribution(id);

    await this.cloudFront.deleteDistribution({
        Id: id, IfMatch: distribution.ETag
    }).promise()
  }

  /**
   * CloudFront ディストリビューションを無効化する
   * @param id 無効化したい CloudFront ディストリビューションの ID
   * @return 無効化した CloudFront ディストリビューションの情報
   */
  async disableDistribution(id: string): Promise<UpdateDistributionResult> {
      const distribution = await this.getDistribution(id);
      const config = distribution.Distribution.DistributionConfig;
      config.Enabled = false;

      return await this.cloudFront.updateDistribution({
        Id: id,
        IfMatch: distribution.ETag,
        DistributionConfig: config
      }).promise();
  }

  /**
   * MediaPackage のエンドポイント用の CloudFront ディストリビューションを作成する
   * @param id CloudFront ディストリビューションを判別するための ID
   * @param mediaPackageArn MediaPackage チャンネルの ARN
   * @param mediaPackageUrl MediaPackage エンドポイントの URL
   */
  async createDistributionForMediaPackage(
      id: string,
      mediaPackageArn: string,
      mediaPackageUrl: string
    ): Promise<CreateDistributionWithTagsResult> {

    // 1. url モジュールを用いて URL 文字列をパースする
    const mediaPackageEndpoint = url.parse(mediaPackageUrl);

    /**
    2. MediaPackage のエンドポイント URL から FQDN を取得する。
    後述する CloudFront ディストリビューションのオリジンのドメイン名としても利用する
    */
    const mediaPackageHostname = mediaPackageEndpoint.hostname;

    /**
    3. MediaPackage のエンドポイント URL のフォーマットは
    https://<AccountID>.mediapackage.<Region>.amazonaws.com/**** となっているので、
    FQDN の先頭部分を文字列分割で取り出すとアカウント ID が取得できる
    */
    const accountId = mediaPackageHostname.split('.')[0];

    // 4. 後述する CloudFront ディストリビューションのオリジン ID として、アカウント ID を利用する
    const targetOriginId = `MP-${accountId}`

    /**
    5. createDistribution ではなく、createDistributionWithTags 関数で、
    CloudFront ディストリビューションを作成する。MediaPackage との紐付けにタグを利用するため。
    */
    return await this.cloudFront.createDistributionWithTags({
        DistributionConfigWithTags: {
            Tags: {
                Items: [
                    /**
                    !!!!!重要!!!!!

                    6. CloudFront ディストリビューションに紐付けたい
                    MediaPackage エンドポイントのチャンネル ARN を
                    mediapackage:cloudfront_assoc で定義する。

                    mediapackage:cloudfront_assoc を定義することで、
                    CloudFront ディストリビューションと
                    MediaPackage チャンネルを紐付けることが可能となる。
                    */
                    {
                        Key: 'mediapackage:cloudfront_assoc',
                        Value: mediaPackageArn
                    },
                    {
                        Key: 'Id',
                        Value: id
                    },
                    {
                        Key: 'Product',
                        Value: 'product'
                    },
                    {
                        Key: 'Stage',
                        Value: 'dev'
                    }
                ]
            },
            DistributionConfig: {
                CallerReference: new Date().toISOString(),
                Comment: `Managed by MediaPackage - ${id}`,
                Enabled: true,
                /**
                7. CloudFront ディストリビューションのオリジンには 2つ設定します。
                1つが MediaPackage のエンドポイントに対するものと、
                もう 1つが MediaPacakge サービスに対するものです。

                基本的には MediaPackage のエンドポイントに対するオリジンを利用します。
                例外時に向けるオリジンが MediaPacakge サービスに対するものになります。
                */
                Origins: {
                    Quantity: 2,
                    Items: [
                        {
                            DomainName: mediaPackageHostname,
                            Id: targetOriginId,
                            CustomOriginConfig: {
                                HTTPPort: 80,
                                HTTPSPort: 443,
                                OriginProtocolPolicy: 'match-viewer'
                            }
                        },
                        {
                            DomainName: 'mediapackage.amazonaws.com',
                            Id: "TEMP_ORIGIN_ID/channel",
                            CustomOriginConfig: {
                                HTTPPort: 80,
                                HTTPSPort: 443,
                                OriginProtocolPolicy: 'match-viewer'
                            }
                        }
                    ]
                },
                /**
                8. CacheBehaviors のいずれにも当てはまらなかった場合の
                キャッシュの振る舞いを定義します。

                MediaPackage は タイムシフト表示機能を使用する際等で、クエリ文字列に start, m, end を利用しています。
                そのため、それらの文字列は WhitelistedNames に含め QueryString には true を指定しておきます。

                DefaultCacheBehavior に引っかかる挙動は例外的扱いなので、
                使用するオリジンは MediaPackage サービスのものを設定します。
                */
                DefaultCacheBehavior: {
                    ForwardedValues: {
                        Cookies: {
                            Forward: 'whitelist',
                            WhitelistedNames: {
                                Quantity: 3,
                                Items: [
                                    'end', 'm', 'start'
                                ]
                            }
                        },
                        QueryString: true,
                        Headers: {
                            Quantity: 0
                        },
                        QueryStringCacheKeys: {
                            Quantity: 0
                        }
                    },
                    MinTTL: 6,
                    TargetOriginId: "TEMP_ORIGIN_ID/channel",
                    TrustedSigners: {
                        Enabled: false,
                        Quantity: 0
                    },
                    ViewerProtocolPolicy: 'redirect-to-https',
                    AllowedMethods: {
                        Items: [
                            'GET', 'HEAD'
                        ],
                        Quantity: 2,
                    },
                    MaxTTL: 60
                },
                /**
                9. CloudFront のエラーコード全ての TTL に 1sec を設定します。
                MediaPackage のエラーのキャッシュが長時間持続してしまうと、
                その間は MediaPackage で正常に配信できているとしても、
                復旧できない状態となるからです。
                */
                CustomErrorResponses: {
                    Quantity: 10,
                    Items: [
                    {
                        ErrorCode: 400,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 403,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 404,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 405,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 414,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 416,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 500,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 501,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 502,
                        ErrorCachingMinTTL: 1
                    }, {
                        ErrorCode: 503,
                        ErrorCachingMinTTL: 1
                    }
                    ]
                },
                /**
                10. CloudFront ディストリビューションのキャッシュの振る舞いを 2つ定義します。

                それぞれの設定内容は基本的に DefaultCacheBehavior で定義したものと同様です。
                しかし、利用するオリジンは MediaPackage エンドポイントに向けたものを利用します。

                1つは Microsoft Smooth Streaming での配信時に利用する
                index.ism に対するもので Smooth Streaming を true に設定しています。

                もう 1つは上記 Microsoft Smooth Streaming 以外の
                全てに当てはまるストリーミングに適用されるものになります。
                */
                CacheBehaviors: {
                    Quantity: 2,
                    Items: [{
                        MinTTL: 6,
                        PathPattern: 'index.ism/*',
                        TargetOriginId: targetOriginId,
                        ViewerProtocolPolicy: 'redirect-to-https',
                        AllowedMethods: {
                            Items: [
                                'GET', 'HEAD'
                            ],
                            Quantity: 2,
                        },
                        ForwardedValues: {
                            Cookies: {
                                Forward: 'whitelist',
                                WhitelistedNames: {
                                    Quantity: 3,
                                    Items: [
                                        'end', 'm', 'start'
                                    ]
                                }
                            },
                            QueryString: true,
                            Headers: {
                                Quantity: 0
                            },
                            QueryStringCacheKeys: {
                                Quantity: 0
                            },
                        },
                        SmoothStreaming: true
                    }, {
                        MinTTL: 6,
                        PathPattern: '*',
                        TargetOriginId: targetOriginId,
                        ViewerProtocolPolicy: 'redirect-to-https',
                        AllowedMethods: {
                            Items: [
                                'GET', 'HEAD'
                            ],
                            Quantity: 2,
                        },
                        ForwardedValues: {
                            Cookies: {
                                Forward: 'whitelist',
                                WhitelistedNames: {
                                Quantity: 3,
                                Items: [
                                    'end', 'm', 'start'
                                ]
                                }
                            },
                            QueryString: true,
                            Headers: {
                                Quantity: 0
                            },
                            QueryStringCacheKeys: {
                                Quantity: 0
                            },
                        }
                    }]
                },
                PriceClass: 'PriceClass_All'
            }
        }
    }).promise()
  }
}

createDistributionForMediaPackage で作成したディストリビューションは、公式ページに記載された手順で作成した CloudFront ディストリビューションと同等のものになります。

📔 Moonlander というエルゴノミクスキーボードのススメ

Sun, 13 Dec 2020 00:00:00 +0000

はじめに

最近 ErgoDox EZ からの乗り換えで Moonlander というエルゴノミクスキーボードを使っているのですが、諸々非常に満足しています。コンパクトながら安定感のある打ち心地でカスタマイズ性も高く、試行錯誤しながら自分好みにセットアップして使い勝手を最適化することができます。

バックライトがあり、デフォで様々な光り方が用意されているのも非常にカッコよいです。あまりキーボードのバックライトを気にしたことは今まで無かったのですが、何となく 1日毎にエフェクトを切り替えると良い気分転換になります。なんとなくだけど。。ｗ

また、これについてはエルゴノミクスキーボード全般に言える話で Moonlander に限った話では無い気がしますが、体がこわばった姿勢にならなくなり、肩が開いてリラックスした姿勢でタイピングできます。

そのため、長時間 PC で作業していても、呼吸が浅くなりづらく、肩への負担も少なく感じます。現に筆者はキーボードを変えただけで生活習慣変えた覚えがないにも関わらず、長時間作業しても疲れにくくなりましたし、肩こりになりにくくなりました。
毎年冬になると肩こりになる体質だったのですが、ErgoDox EZ を採用し始めてから肩こりに悩まされることは無くなりました。

今回はそんな気に入って仕事プライベート問わず酷使している Moonlander についての紹介記事を書いていこうと思います。

ちなみに筆者はキーコンフィグを軽くカスタマイズしている程度のライトユーザーです。

セットアップが簡単

Web から簡単にキーコンフィグを設定することが可能です。キーコンフィグ設定のためのサービスは Ergodox EZ Configurator というやつです。名前に Ergodox がついていますが ZSA Technology Labs から購入可能なキーボード全てに対応しています。(Moonlander にも Planck にも対応)

今回は Moonlander Mark I を利用する

Search layouts ボタンをクリックすることで、他の人が既にカスタマイズしたキーコンフィグをダウンロードしたり、そのキーコンフィグを元に自分用のキーコンフィグをカスタマイズすることも可能です。
ちなみにデフォルトのキーコンフィグは Configure ボタンをクリックすると確認することができます。もちろん、そこからキーコンフィグをカスタマイズしていくことも可能です。

また、カスタマイズした設定内容は常に Ergodoz EZ Configurator に保存されるので、後から細かくキーコンフィグを修正していくといったことも可能です。最初のうちは頻繁にキーコンフィグに微修正入れると思うので、めっちゃ便利でした。

Ergodoz EZ Configurator の Search layouts で “coding” で検索した結果

📔 Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

Thu, 10 Dec 2020 00:00:00 +0000

この記事は Static Site Generator Advent Calendar 2020 10 日目の記事です。

はじめに

Zenn や Qiita, note など様々なウェブサービスで記事を書くにつれて、ふと雑多な内容で自分の好き勝手に記事を書いて公開できる自分のブログが欲しくなりました。そこで、自分のブログを作ろうと思い調査したところ、SSG で作るのが手っ取り早そうだったのと、その中でも一番ラクにウェブサイトが構築できそうな Hugo を採用しました。

また、デプロイは簡単に行いたかったので、デプロイ先として GitHub Pages を採用しました。独自ドメインの割り当てから HTTPS 対応まで無料でできるかつ、使い慣れている GitHub をデプロイ先に使えることが決め手でした。

Hugo で自分のブログを構築して GitHub Pages で公開できるようになったのですが、ブログ内容を更新したり記事を書くたびにビルドしてデプロイをするのが、意外と面倒なことに気づきました。そこで、GitHub Pages action を用いて、ビルドしてデプロイするという作業は自動化しました。

上記までの作業をすることで、自分のブログを書いたり更新することだけに集中できる環境を整えることができました。ウェブサイトを作りこむ以外は、簡単ないくつかの作業をするだけで Hugo で満足のいく自分のブログを書く環境が整えられたので、その手順についてまとめてみました。

ちなみに本記事の手順で実際に作成した私のブログは下記です。

Nikaeraintokyo.

More information about nikaera.

📔 誕生日のノリでアドベントカレンダーに投稿予約して感じた変化

Sun, 06 Dec 2020 00:00:00 +0000

はじめに

まず、私の誕生日は 11/6 なので本日 12/6 は誕生日からちょうど 1ヶ月後になります。

誕生日なので何か書くことにした✍️ | なんでもに参加しました！ https://t.co/1NXySfMlak #Crieit #crieit_advent_calendar @crieitcommunityより
— 𝚗𝚒𝚔𝚊𝚎𝚛𝚊 (@nikaera) November 2, 2020

はい。完全にノリで参加しようと投稿予約してから、後日確認して気づきました。。ｗしかし、その間違えに気づいてから、何を投稿しようかなあと考え始めた時に、ふと「以前の自分だったら絶対ノリでアドベントカレンダーに登録するっていう行動しないよなあ」ということに気づきました。

そこで、今回は以前の自分と比較して、今の自分がどう変わったのか考察してみることにしました。この記事書いてるときは誕生日からまだ 1週間経ってないし、ちょうど考察するには良い機会かなと思って。

以前の自分

Photo by Luis Villasmil on Unsplash

以前はやりたいことがあっても全部後回しにしてしまっていました。何故かと言うと仕事やプライベートも含めて、他に直近でやらなければならない、もしくはそう思いこんでいる TODO があったときに、それらが残っていると次々に心配事や考え事が増えていってしまい、やりたいことに集中出来なくなるからです。

つまり、やりたいことは本気で集中できるタイミングが来たらやろうと考えていました。

そのため、読もうと思って買った本を読みたい、買って届いた新作ゲームをやりたい、OSS 活動をしてみたい、ライブラリを自分で作成してみたい等々のやりたいことは全て後回しになっていました。

何も考えないでサクッと取り組めるプレイ済みのゲームを遊んだり、気に入っている Youtube の動画を何度も繰り返し見たりして時間を浪費していました。

ボーッとしながら何も考えないで過ごす時間や遊ぶ時間は気力を養う上で重要で必要だと認識しているのですが、それだけを余暇に費やすのは少し勿体ないなと感じていました。

そして、ある時ふと気づきました。多分このままの生活してると連休とか仕事の区切りのタイミングとかでしか、自分がやりたいことに取り組むことはできないな と。。ちなみに、私はいわゆる ON/OFF みたいな切り替えが出来ないタイプなので、「仕事が終わったらスイッチを OFF にしてプライベートを全力で楽しむようにする」とかは無理なタイプです。

そこで、過去自分が気分がノリ続けて作業できたり、新しいことに挑戦し始めたときのことを思い返しながら、現状改善のために簡単に出来ることからやってみようと 1年前くらい前から行動を起こし始めました。

試したこと

Free-PhotosによるPixabayからの画像

まず、前提として下記項目はあえて頑張って解決するとかは諦めました。理由は中学生くらいの時から「そうだったなあ」って感じていることだったので潔く諦めた感じです。

仕事プライベート関係なく、やりたくない面倒な TODO を意識してしまい無駄に疲れる
- ふとした瞬間に思い出して不快になるかつ、それらの TODO は後回しにしてしまいがちなので、更に不快になる機会が増えてきて、結果疲れ続ける
やるべき必要がある TODO が増えてくると最優先で迅速に全部片付けたくなる
- それらが意識の端にあると心を休めた状態で日々を過ごすことが難しくなってきて、結果疲れ続ける

上記の解決を諦めても、やりたいことが自然と出来る環境が作れるようにしようとしました。

仕事プライベート問わず TODO の総量を減らしていく

TODO が増えてくることによって、やるべき TODO も必然的に増えてきます。最初は優先度の低い TODO だったのに、作業していくうちにそこから更にやるべき他の TODO が生まれてくることもあります。

そのため、そもそも仕事でもプライベートでも優先度とか関係なく TODO を日常的に増やさない努力を行いました。 割とお願いされたら何でも引き受けてしまいがちだったので、そこは常に意識するようにしました。

📔 GitHub 接続時の ~/.ssh/config の書き方

Thu, 19 Nov 2020 00:00:00 +0000

はじめに

本記事ではタイトルの内容に加えて ~/.ssh/config に対する基本的な理解を深めるため、各種設定項目に関する説明も付随して行います。GitHub を例に挙げてはいるものの、Bitbucket や GitLab、Git サーバへ接続する際にも利用可能な ~/.ssh/config の設定について記載しております。

`~/.ssh/config` の書き方

まず GitHub へ接続する ~/.ssh/config の設定を見ていきます。GitHub で認証に使用する SSH キーは登録済みで秘密鍵は ~/.ssh/github へ配置している想定です。

SSH キーが未登録の場合は公式サイトの手順に従って鍵の生成・登録までを行っておきます。

# ~/.ssh/config

Host github.com
    IdentityFile ~/.ssh/github
    User git

~/.ssh/config の各種設定項目は下記になります。

項目	説明
Host	ホスト名を指定する
IdentityFile	接続時に使用する秘密鍵を指定する
User	接続時のユーザ名を指定する

設定を行うことで github.com に SSH 接続する際、ユーザ名に git が指定され、~/.ssh/github に存在する秘密鍵を用いて SSH 接続を試みるようになります。

早速 github.com 接続時に正しく認証が通っているか確認するため、適当なプライベートリポジトリを git clone してみます。

プライベートリポジトリを git clone した実行結果 (成功)

無事に git clone できることが確認できたら成功です。

📔 Serverless のプラグインを TypeScript で作成する方法

Sun, 08 Nov 2020 00:00:00 +0000

はじめに

Serverless Framework を使っていて、度々デプロイ時に手動で設定していた作業内容を自動化したいなと思い、プラグイン作成の知識習得も兼ねてライブラリを作成し NPM で公開してみました。

https://www.npmjs.com/package/serverless-amplify-auth

今後も開発する可能性はありそうなので Serverless のプラグインを TypeScript で作成する際の手順をまとめておきました。各手順はザックリと紹介しつつ、主にその過程でハマった点や工夫した点に重きをおいて記事を書いていきます。

動作環境

Node.js 12.19.0
Serverless Framework
- Framework Core: 2.10.0
- Plugin: 4.1.1
- SDK: 2.3.2
- Components: 3.3.0

開発環境を整える

本記事の内容を最後まで実践した際の最終的なプロジェクトのディレクトリ構造は下記になります。

tree -I node_modules -L 2 ./
./
├── example # ライブラリの動作検証用のサンプルコードを配置するフォルダ
│   ├── handler.js
│   ├── package.json
│   └── serverless.yml
├── lib     # src フォルダ内のファイルをコンパイルした結果を配置するフォルダ (ライブラリとして利用する際に含まれるソースコード群)
│   ├── index.js
│   └── index.js.map
├── package-lock.json
├── package.json
├── src     # Serverless プラグインのソースコードを配置するフォルダ
│   └── index.ts
└── tsconfig.json

基本的には TypeScript で Serverless Framework の Plugin を書いてみる | Developers.IO の手順をなぞっていくだけで環境構築自体は可能です。そこで、ここでは自分なりに工夫した箇所について記載していきます。

Portfolio 💼

Mon, 01 Jan 0001 00:00:00 +0000

Interview 🎤

10年勤めた会社を転職。その経緯と想いとは？ - LAPRAS NOTE
- 2022 年時点での nikaera の思考がまとまっています

Blog 📝

Qiita
- 軽めの内容の記事を書くのに Qiita を利用しています
Zenn
- 整理整頓した記事を書くのに Zenn を利用しています

What I made 🔨

Teemo 💕
- 📔 チャットの短文作成に便利な Chrome 拡張機能を開発してみた
Bloggimg
- 📔 ブログを書く用途に特化した Gyazo のツールを開発してみた
Zenn.badge
- Zenn のスコアを GitHub 風のバッジに変換するサービス
selekted.club
- tumblr の音と映像のフィードを連続再生できる Web サービス
立体ホームラン競争
- web1week の時に作成した Web で出来る 3D ゲーム
チャレンジカレンダー
- web1week の時に作成した 30Days Challenge が作成できる Web サービス
精密適正テスト
- unity1week の時に作成したゲーム
バーチャル食べ放題
- unity1week の時に作成したゲーム

Profile 👦

Mon, 01 Jan 0001 00:00:00 +0000

開発者として 🔨

大学院時代は友人 2 人と一緒にチームを組んで Android/iPhone アプリ開発や Web サービス開発をしていました。また、受託として Android/iPhone アプリ開発を請け負っていました。そのおかげで今でも Objective-C はある程度は空で書けます。

現在は AWS を用いたバックエンドの開発を主に行っています。様々な技術領域に興味がありゼネラリストの指向性が強いです。実際に人に使ってもらえるプロダクトを作ることや社会貢献可能なプロジェクトに参加することに興味があります。

開発それ自体を楽しめる気質はあるものの、基本的には開発を課題解決のための手段として捉えています。0 からプロジェクトに関わる様々なことに携わりたいタイプの気質が強いエンジニアです。また、個々が苦手な部分を補いあいながら、遠慮なく改善点を指摘しあえて、楽しく心理的に安全に開発できるチームが好きです。

個人開発はプロトレベルで自分が作ってみたいものを思いついたら作るみたいな感じでやってます。あとは web1week や unity1week に時間があれば参加しています。作ったものは基本全部 GitHub にアップしています。そこで得た知見は他の人のためにもなれれば嬉しいなということで、Qiita や Zenn にまとめています。

1 つの会社に所属して個人で技術力を高めていくことに限界を感じているので、開発チームへのお誘い等あれば、是非 Contact からお誘い頂けると嬉しいです。ひととなりは個人としてからご確認いただけます。

また、あまり有効活用できておりませんが Lapras を利用しています。自分の能力値が可視化される感じがゲームやってるみたいで楽しいです。

個人として 🚶‍♂️

長男です。人生で大切なことは大体ゲームから学びました。小学生の時から引きこもって仕事できる環境に憧れていました。現在は無事それが叶う環境で働けていて満足しています。ガラスのハートの持ち主で HSP の気質があるかもしれません。

特に下記の傾向が顕著にあります。

動揺するような状況を避けることを、普段の生活で最優先している

仕事をする時、競争させられたり、観察されていると、緊張し、いつもの実力を発揮できなくなる

社会人になってからは、会食恐怖症の気も出てきましたが、なんとか元気にやってます。このような人間なので、仕事もプライベートもできるだけストレスが無い状態を保つよう心がけています。生きるの大変。

最近は自己開示して積極的に弱みをさらけ出し、周囲の理解得ることでだいぶ生きやすくはなってきました。更に自己開示の副次的効果として、あまり動揺するようなことも無くなってきました。

基本的に孤独を愛する傾向にありますが、Death Stranding をプレイしてからは考え方は若干変わりました。気の合う大切な仲間との関係性にフォーカスして仲を深くすることを大切にするタイプです。

好きなこと 🌟

趣味はコンシューマーゲームと音楽とコーヒーで、ベースギターと読書と個人開発も好きです。

ゲームのジャンルは雑多に好きで PlayStation Store とか My Nintendo Store とか酒飲んで流し見しながら、インディーゲーとか含めて頻繁にジャケ買いしたりしています。最近はそのせいで積みゲーが増えているのが悩みです。

音楽もジャンルは雑多に好きですが、ずっと昔から好きなアーティストに Nikakoi と erast がいます。そう考えると IDM のジャンルが特に好きかもしれないです。気になる音楽のインプット/アウトプットは tumblr で行っています。

コーヒーは大好きで 1 日に 5 杯とか飲みます。生豆を買って自家焙煎も行っていますが、迂闊にもストックしていた生豆が切れてしまったときは届くまでの繋ぎとしてやなか珈琲とかに豆を買いに行ったりします。つまり、やなか珈琲の豆が好みです。

ベースギターは社会人になってから始めました。ベースギターを始めた動機は近所迷惑にならなそうだったからです。あと裏方が好きなのも関係しているかもしれません。プレイヤーとしては Joe Dart に憧れてます。エレキギターは高校の時から社会人になるまではやっていました。

Contact 📥

Mon, 01 Jan 0001 00:00:00 +0000

nikaera への問い合わせページ

RSS Feeds 🔖

Mon, 01 Jan 0001 00:00:00 +0000

自分の技術記事の RSS Feed

Nikaeraintokyo.

🤖 AI時代における個人の幸福 (2025/07/15)

💪 脱力という最強の構え

育児エンジニアの学び｜nikaera

🎯 目標管理と運用は二つで一つ

🎯 いかなる時も、行動の起点は自分から

🥋 守破離という最強の型

蛇足

nikaera | Join me on Suno

🌱 スタッフプロジェクトの種を蒔く

リーダーシップシフト雑感｜nikaera

📅 2024年の雑な振り返り 〜人に恵まれた〜

⚠️ マネージャーが信頼を失墜させる時

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

🏛️ 灯台としてのプロダクトビジョン

🗣️ 言い切りや断定の言葉が苦手

👥 リーダーシップシフト雑感

11 種類のリーダーシップ徹底解説: 自分に合ったスタイルの見つけ方 [2025] • Asana

🔄 交流を図るためのふりかえり

🤝 連携のための礎を築く

👴 おじいちゃん子

👶 育児エンジニアの学び

前提

学び

結論

💬 即時性の無いコミュニケーションも大切にしたい

📝 リスペクトの欠如が及ぼす自己効力感の喪失

📔 2021年の振り返り

はじめに

出来事

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

おわりに

📔 ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する

はじめに

動作環境

環境構築

📔 Unity で iOS/Android アプリの設定値をセキュアに扱う方法

はじめに

GitHub - nikaera/Unity-iOS-Android-SecretManager-Sample: EncryptedSharedPreferences および Keychain Services を Unity から利用する Unity サンプルプロジェクト

📝 Azure Cosmos DB でソートしようとするとフリーズする

📔 マイペースに技術研鑽を継続する方法

はじめに

技術研鑽のサイクル

「きっかけ」：実現したい開発アイデアが浮かぶ

「行動」：開発アイデアを検証可能な形で実装する

「みかえり」：過程で得たもの全てをアウトプットする

おわりに

📝 pytest で alembic のマイグレーションを行う方法

はじめに

alembic でマイグレーションを行う

FastAPI の pytest への適用例

📝 Chrome 拡張で 1つのウインドウを使い回す方法

📝 Node.js パッケージを公開するための GitHub Actions を構築する

📔 チャットの短文作成に便利な Chrome 拡張機能を開発してみた

はじめに 📝

考えていたこと 💭

📔 GameCI で Unity の CI 環境を GitHub Actions で構築する

はじめに

GitHub - nikaera/Unity-GameCI-Sample: Sample project for building a CI environment for Unity using GameCI with GitHub Actions.

📝 Rails で config/database.yml よりも ENV['DATABASE_URL'] の設定が優先される話

📝 Pillow を使って画像に縦書きテキストを埋め込む

はじめに

Embedding Japanese vertical writing characters into an image using Pillow.

📔 Zenn の記事を DEV に自動的に同期させる GitHub Actions 作ってみた

はじめに

GitHub - nikaera/sync-zenn-with-dev-action: Just sync Zenn articles to DEV.

📔 Gatling で複数ユーザ認証した情報を元に負荷テストする

はじめに

動作環境

📅 2024年の雑な振り返り〜人に恵まれた〜

`~/.ssh/config` の書き方