ツイキャスの録音をAnchorにアップしてPodcastのラジオ配信をお手軽に始める

ライスさんがやっているTokyoCoolBoysのラジオがツイキャスの録音をAnchorというサービスにアップしているのを見て、私もツイキャスで好んで配信しているけれど、ツイキャスでは録音を整理できないことに課題感を持っていたので、Anchorを試してみることにした。

Anchorとは

2019年にSpotifyに買収されたPodcast配信サービスで、音声データをアップすると、Anchor本体以外にもSpotifyその他のPodcast配信サービスにRSSを通して同時配信できるサービスのようだ。

試してみたところ、音声ファイルをアップするだけでリッチなUIの配信サイトがサクッと作れてSpotifyでも聴けるようになるので便利な印象だ。

ツイキャスの録音データをアップする

ツイキャスの録音をMP4形式でダウンロードできるので、そのままアップしても、必要な編集を行ってからアップしても良い。

私の場合はMacQuickTime Playerで簡単に動画の結合ができたので、ツイキャスの時間制限の関連で録音ファイルが分かれてしまっていたのをくっつけてアップしてみた。

まとめ

アメリカではPodcastのリスナーが1億人以上いるらしくカルチャー/ビジネス両面で大変なムーブメントになっているらしい。

Podcast配信するとただの内輪の雑談ツールだったツイキャスも何だかイケイケな趣味になったような気分だ。

一連の「弱者男性論」言及から見えて来た「弱者男性」概念のコアとその将来への提言 ―フェミニズムとのコンフリクト―

クリッツァ―さんの「弱者男性論」に批判的に言及した記事を発端として、Twitterはてな匿名ダイアリー(通称「増田」)で「弱者男性」の議論が盛り上がっている。

クリッツァ―さんの記事では「キモくて金のないおっさん」や「かわいそうランキング」、「女性の上昇婚志向」というワードが言及されていることから、Twitterのアルファ弱者男性論客*1の議論を念頭に置いていると思われる。

その一方で、増田の弱者男性論エントリやそこについたブコメを読むと、いわゆる「あてがえ論」とは一緒にしないで欲しいとの見解も頻出しており、どうやらTwitterのアルファ論客による論調こそが「弱者男性論」であると結論づけたのではミスリードな部分があるようだ。

そのような問題意識の元、ただ対立を煽りたいだけの野次馬的言及を慎重に排しつつ、一連の増田とそこに付いたブコメを、当事者的言及と解釈できるものを重視して読み解いてみたところ、「弱者男性」という一見して定義不明瞭な印象を受ける用語について、コアと呼び得るようなコンセプトがあることが見えて来た。

「男性」というだけで「強者」扱いしないで欲しい

結論から言うと、フェミニズムは「男性」という属性についてまとめて「強者(マジョリティ)」として批判するけれど、男性が皆強者ではなく、弱者の男性もいると認めて欲しいというのがそのコアだと解釈した。

'弱者男性への救い'が何であるのか、具体的にどのような社会的状況が実現されれば、弱者男性は救われるのか、という点について意見を募りたい。

弱者男性への救いとは、具体的に何か

弱者男性の地獄って先ず被害者・弱者として認識して貰えない事なので、先ずは弱者性を認めてあげる事かと。拙速に解決策を求めた結果「あてがえ論だ」と曲解される事が多く、正にそれこそが地獄の正体なのだと思う

2021/04/05 20:43

弱者男性への救いとは、具体的に何か

「男性は皆全員強者だ」論を見たときには、「こんな惨めな人生でも強者あつかいか……」とは思ったんで、せめて強者として扱うのはやめてほしい。どうせ救われぬ人生だけど、救われなかったことくらいは認めてほしい

2021/04/06 02:20

「弱者男性への救い」について素朴な疑問を呈した増田に対して、はてなスターが多い順*2に上から2つのブコメは同じ趣旨の内容に読める。

弱者男性弱者男性いってるけど、要するに男女関係ない弱者問題を訴えてる..

「弱者男性」は十把一絡げに男性を強者として叩くフェミニズムへの反発から生まれた言葉。ごく最近までは存在しないものとしてずっと無視されてきたんだよな。/無視し叩いてきた連中のすっとぼけたコメントが醜悪

2021/04/06 11:41

自分の観測範囲では、最近の弱者男性論はすもも始め女性の上方婚選好(≒「女が俺を選ばないのが悪い」)に帰着しがちなので。/frothmouth氏が推してる、この系統とは違う良い弱者男性論の論者を知りたいです。読むよ - muchonov のブックマーク / はてなブックマーク

基本的に男性一般を強者として殴らなければ"弱者"男性なんてわざわざ言う必要ないはずなんですよ。なぜなら頭のおかしい人以外は社会的弱者に男性は含まれないなどという差別的な思考はしないから

2021/04/07 22:34

また、別の増田についたブコメでよりダイレクトにそのコンセプトを述べているものもあった。「"弱者"男性」というのは男性というだけで強者と決めつけて批判するフェミニズムへのカウンターだと言うのだ。これはルーツに関するソース付きの議論ではないけれど「弱者」 + 「男性」という語構成はそういうことだと理解すると腑に落ちる。より広義に言うと、社会的マイノリティに寄り添う言葉は多く持つ一方で、個別の事情に関わらずマジョリティとされる男性には寄り添う言葉を持たないようないわゆる「リベラル」についての不信感がそのコアにあると読み取ることができるのだ。このように理解すれば、「弱者男性」という用語が非常に高い確率で「フェミ」や「リベラル」への批判とセットで用いられることへの納得感も出る。

ただ、漫画やアニメやゲーム等の二次元コンテンツに触れながら余生を生きていければ、それで良いなと言うのが正直な気持ちです。

しかし残念ながらそうした二次元コンテンツは昨今幾度も炎上を経験しており、時には好きな作品がその対象に成る事も有ります。

フェミニズムと「弱者男性」のコンフリクトの具体例としては、Twitterで度々炎上する二次元コンテンツへのフェミニズムからの批判が挙げられるだろう。

客観的な要件と思われるもの

上述の観点がコアコンセプトと思われるため、上の増田のように「結局「弱者男性」って誰なんだよ」と「弱者男性」の客観的定義を求めたくなるのは、実は「弱者男性」の本質ではないとも言える。その一方で、私がこれまで観測して来た議論に基づいて客観的要件と思われるものを挙げると

  • 経済的弱者であること
  • (経済的弱者であることと関連して)家庭を持てないこと
  • そのような状態を一定以上不幸に感じていること

これらの観点が重要と思われるけれど、個人差が大きくあり、「弱者男性」の具体的状態については上の範疇に留まらないと理解すべきだろう。家庭を持つことについては諦めている議論と諦めていない議論(その極端なものが「あてがえ論」)が両方とも弱者男性論として観測される点に注意が必要だ。

男性学は「弱者男性論」的関心をどう扱って来たか

フェミニズムとのコンフリクト

冒頭のクリッツァ―さんの記事では男性学が脱規範的議論に終始して*3弱者男性を具体的に救う議論をしていないことと、今後して行く必要があることが述べられているけれど、弱者男性論の本質が個別の弱者的状況よりもフェミニズムとのコンフリクトにあるとしたら、これは男性学が日本での発足当初から主要な問題意識として考えて来たテーマと言える(しかし、後からも述べるように、その前提が弱者男性論とは大きく異る)。

上野千鶴子さんが男性学について「フェミニズム以後の男性の自己省察であり、したがってフェミニズムの当の産物である」とした上で、「男性学とは、その女性学の視点を通過したあとに、女性の目に映る男性の自画像をつうじての、男性自身の自己省察の記録である」と定義しているように*4男性学はその発足からして「男性はフェミニズムとどう向き合うべきか」という問題意識を主要なテーマの一つとして来た。

対抗言論 反ヘイトのための交差路 2号

対抗言論 反ヘイトのための交差路 2号

  • 発売日: 2021/03/01
  • メディア: 単行本(ソフトカバー)

女性の性被害やDV被害を告発する#MeToo運動が二〇一七年に起きたが、被害を訴える女性に対し、被害を矮小化・無化する二次加害、女性の運動家や政治家に対する中傷・脅迫的なメッセージを送りつけるジェンダートローリング(gender trolling)など、バックラッシュの再燃とも言える現状がある。それは何事もなく暮らしてきた、もしくはジェンダーとはまた別の理由で不遇な状況を生きてきた男性たちが、突如「加害者」「抑圧者」として引きずり出され、その際に生じた抵抗感や不安、恐怖といったネガティブな感情に対処しきれず、過剰な防衛として加害に転じてしまう動態を示しているのかもしれない。女性から申し立てられた際の男性の脆さが、そこには現出している。

尾崎俊也・西井開「とまどいを抱える」

最近の動向で言うと、メンズリブ団体の「ぼくらの非モテ研究会」を主催する西井さんとその友人の尾崎さんが「とまどい」という用語でフェミニズムの訴えに触れたときに男性に生じるコンフリクトに注目している。「何事もなく暮らしてきた、もしくはジェンダーとはまた別の理由で不遇な状況を生きてきた男性たちが、突如「加害者」「抑圧者」として引きずり出され」はかなり弱者男性論の文脈に近い言及と読めるだろう。ただし、上の引用部分を見ても分かるように、フェミニズム支持の価値観の元、弱者男性論的現象に対して批判的な視点で書かれているため、弱者男性論と注目するテーマに一致は見られても、前提とする価値観に決定的な対立があると言える。この価値観の対立は上の議論に限らず、男性学の議論全般にあてはまるものだ。

男性の強者性は一枚岩ではない

弱者男性論は男性すべてが「強者」ではないと訴えるけれど、男性学においても男性が一枚岩の強者でないことは、主にコンネル(Raewyn Connell)の「ヘゲモニックな(覇権的)男性性」という概念の応用として論じられて来た。

コンネルは「どんなときでもある一つの形式の男性性が他の男性性よりも文化的に優位にある」として、これをアントニオ・グラムシの議論に依拠して「ヘゲモニックな男性性」と名付ける。一方、「従属的な男性性」は「男性集団のなかでの支配―従属の特定のジェンダー関係」において最下層に位置づけられているものを指す。次に「共犯的な男性性」は「家父長制の最前線部隊になることなくその利益配当を受けるような形で構築される男性性」、つまりヘゲモニックな男性性を体現せずに家父長制の利益配当を受けるような男性性のあり方を指す。コンネルによれば、「(男性性の)ヘゲモニックなパターンを厳密に実践している男性の数は極めて少ない」にもかかわらず、多くの男性が「全体的な女性の従属から生まれる男性一般の特権」を受けている。そして、コンネルは「エスニック・マイノリティのような搾取あるいは抑圧された集団のなかで生み出される男性性」を「周縁化された男性性」と呼ぶ。この周縁化された男性性は「ヘゲモニックな男性性と多くの特徴を共有しているが、社会的に脱―権威化されている」点が異なる。

ただし、このコンネルの議論で言うと「弱者男性」は「周縁化された男性性」よりも「共犯的な男性性」に近く、「ヘゲモニックな男性性」とともに女性を従属させ男性特権を享受する層ということになると思うので、この理論に基づいて「弱者男性」に寄り添うような議論を展開することは難しい。

以上見て来たように、男性学は弱者男性論の関心と共通する対象を論じて来たけれど、その前提とするフェミニズム支持の価値観に弱者男性論との決定的な対立があるため、弱者男性論には活用しづらいと言えそうだ。

弱者男性論の今後への提言

以上は弱者男性論を取り巻く状況の整理で、ここからは私の見解を書きたい。政治・経済の観点による問題解決は重要と思われるけれど、私は詳しくないのでこの記事では触れない。

Twitterアルファ論客主導の弱者男性論からの脱却

クリッツァ―さんの記事内での「弱者男性論」のように、ただ「弱者男性論」と言ったときに現状で最も想起される可能性が高いのはTwitterのアルファ論客が語っているところの弱者男性論だろう。しかし、実際には弱者男性論への関心はそこに留まらないことが今回の一連の増田やブコメによって示唆された。

ブコメで自分の心情を整理して吐露したり、極端な意見には「弱者男性の代表みたいな態度してそんなことは書かないでくれ」と異議申し立てをしたりと、色々と頑張って建設的な話に持ってこうと頑張っているのだが、すぐに疲れてしまう。

でも、黙ってしまっては、人と人との対立を煽るだけの極端な言論だけが残ってしまうだろう。

それだけはどうにも嫌で……もう少し書こうかなと……もう少しだけ頑張ろうかなと、そう思う。

この増田のように「そうでないもの」を語ろうとする試みを私は支持したい。

「弱者男性」論は疲れる

もっとも心に響いた。私も同じく疲れるから全ての弱者男性論増田は読めてないけど、理解を助け、弱者男性という言葉に人間味をもたらすブコメは読めてよかった。私は、弱者男性とかKKOという言葉や概念は解体したい。

2021/04/08 01:13

そもそもの問題として、「弱者男性」や「キモくて金のないおっさん(KKO)」という用語にはあまりにも女性への人権侵害的な言説のイメージが強いので、ueno_necoさんの言うように「弱者男性とかKKOという言葉や概念は解体」し、この用語を敢えて使わずに自身の関心を正確に語る試みがなされても良いと思う。

また、はてなブックマークブコメはてブユーザー以外からは参照しづらく、短文では論点が不明瞭なので、往年のはてな非モテ論壇の盛り上がりの再来は望めないとしても、もう少しブログ等でまとまった文章で論じる人が増えても良い気がする。

コミュニティの可能性

弱者男性同士の遊びのコミュニティに参加しているという話が肯定的に受け止められているのは希望がある。

メンズリブという選択肢

コミュニティの選択肢としてメンズリブもある。

私が主催しているメンズリブ団体「うちゅうリブ」の活動内容は上の記事にまとめてあるけれど、活動を行う中で、フェミニズムの男性批判に対するとまどいが話題になることも多い印象だ。ただし、メンズリブフェミニズムベースの活動という趣旨が強いため、決してフェミニズム的価値観を押し付けるようなことはしないけれど、フェミニズムがどうしようもなく嫌いという方には合わない場になってしまっているかとは思う。

まとめ

弱者男性論は非常に現代的な関心で、既存の男性学メンズリブでは、主にフェミニズムに対する価値観の相違を原因としてその問題意識に十分に応えることができない可能性がある。弱者男性論にはTwitterの議論でイメージされるような極端な反動的アンチフェミ言説に留まらない関心が含まれていることが示唆されるため、今後の展開を注視したい。

*1:白饅頭すもも小山晃弘島本など。

*2:2021/4/8現在。

*3:性愛文脈での脱規範的議論は論文レベルの「男性学」ではなく、田中さんの『男がつらいよ』のようなカジュアルなテキストに見られるものである点には注意したい。

*4:上野千鶴子「「オヤジ」になりたくないキミのためのメンズ・リブのすすめ」(『日本のフェミニズム 別冊 男性学』所収)

コミュニケーションへの苦手意識の克服とその先

3月末を最終出勤日として有休消化に入るため、全社集会で退職の挨拶を済ませて来た。約2年半勤めて、惜しまれるような雰囲気で、送別会もやって貰えるらしい。要するに普通の退職プロセスなのだけれど、私の人生を振り返ってみると「まともなプロセスで友好的にコミュニティを離れる」ことができたのが今回が初めてだと気づいた。

高校の部活も、最初に入った大学も、次の大学のサークルも、最初に就職した職場も、逃げるように途中で辞めて来た。毎回コミュニティの人間関係が徐々に悪化し、いづらくなるパターンだった。今までのコミュニティで人間関係が上手く築けなかったのはコミュニケーションに関するマインドセットに問題があったからだと今では認識している。何がまずかったか。

「浅い」コニュニケーションを軽視するのをやめる

これが一番まずかったのだけれど、昔の私は「浅い」人付き合いと「深い」人付き合いを区別し過ぎていた。つまり、お互いの価値観に高度な一致が見られ、趣味、学問、芸術などについて深い話ができる人間関係に価値があり、そうでないものに価値がないと考えていて、あまつさえ、浅い人付き合いを馬鹿にするような発言を積極的にしていた。これは今になっては完全に間違いだったと言える。

コミュニティでの人間関係は挨拶に始まって、雑談やコミュニティ運営に必要な(職場であれば業務上の)やり取りをただ積み重ねることにまず価値がある。話が盛り上がるに越したことはないけれど、価値観の高度な一致など必要なく、「そこにやり取りが交わされていること」自体に大きな価値がある。そういったやり取りを積み重ねる先に「信頼」が蓄積され、信頼のある人間はコミュニティで尊重される。

また「価値観の高度な一致」という幼稚な幻想を捨ててみると、人間はそれぞれに面白い。たとえ親密な関係にならなかったとしても人との会話それ自体が楽しく、一期一会的な味があると気づく。

コミュニケーションを恐れない ―普通の人はそんなにコミュニケーションが得意ではないと知る―

昔の私は、自分は世の中の普通の人と比べてコミュニケーション能力に劣っていると感じていて、例えば世間話などで上手く話題を選べないことなどを恐れて、挙動不審に陥っているような節があった。

今、特にコミュニケーションに苦手意識を持たない立場になってみると、実際あらゆる意味でコミュニケーションが得意で、そこを強みにしているような人はそんなにいないし、何らかの不安だったり苦手なコミュニケーションパターンを抱えている人がほとんどのように見える。

そういう適切な視座に立つと、上の世間話での話題が上手く選べなくて挙動不審になるとかの話も、そもそもコミュニケーションが得意な人が相手ならば自分が上手く喋らなくても話は弾むはずで、そうでないなら相手も自分と同程度以上にコミュニケーションが苦手ということなので、最善の努力をした上で話が盛り上がらないならそれは必ずしも自分が原因ではないと落ち着いて考えられるようになる。

なので、コミュニケーションが特に得意ではなくても、劣等意識を感じる必要はない。恐れのないテンションで臨むと、逆に他者の不安な気持ちが「見える」ようになって、場合によっては適切なサポートを入れることもできるかも知れない。

無難なコミュニケーションのその先へ

主に上の2つの観点のマインドセットの変更によって、今はコミュニケーションへの苦手意識がなくなった。これは大変な進歩なのだけれど、その一方で、無難なコミュニケーションの「型」に終始し過ぎているというのが最近の課題だ。

自分の中の尖っている部分を出したり、人と揉めたりすることへの忌避意識を少しずつ外していって、もう少し自然体で人と話せるようになりたい。今の私は人とのコニュニケーションを恐れてはいないけれど、過去の自分のように人間関係で失敗したくない、人から信頼される「まともなコミュニケーション」をしなくては、という点には強い恐れを抱いている。その恐れを解くことができればより本来的な自己をもってコミュニケーションに臨むことができるようになるはずだ。

30歳業務経験3年未満Web系エンジニアが転職エージェントを使って普通に転職したメモ

最近転職エージェントを使って転職したので、攻略や感じたことについてメモを書きたい。Web系エンジニアについて、社名を具体的に出すようなタイプの意識高い転職エントリは多いけれど、普通の転職活動の情報が少ない印象があるので、そういった参考になれば良いと思う。

転職概要

  • 中途でWeb開発の仕事を始めたジョブチェンジ組で、業務経験約2年半、年収400万円台から500万円台にアップさせるつもりで活動した
  • スキルレベルはRailsAPIモードのバックエンドとSPAのフロントエンドが書ける、インフラはチョットダケワカル、新機能開発プロジェクトの経験は比較的豊富、という感じ
  • 転職エージェント経由で15社書類応募して3社に内定を貰い、年収約90万円アップの条件で内定承諾した

転職エージェント

  • 市場感や面接での話し方のコツなど何も知らない状態だと色々と教えてくれるので助かる
  • エージェントの経験や能力の個人差が非常に大きい
    • レバテックやGeeklyのエージェントは全然頼りにならない感じだった
    • エージェントを使って転職したい方は私に連絡くれれば有能なエージェントの情報教えます
  • スケジュールの調整等を代わりに全部やってくれるので、多数の選考を同時進行しやすい
  • 企業研究に役立つ情報も色々と教えてくれる
  • 積極採用している企業の求人を紹介してくれるので、企業側の採用計画とのミスマッチが起きづらい
  • 内定時に年収の3〜4割の料金が採用企業に発生すると言われているので、エージェント経由以外の応募者と比べて採用判断で不利になりそう
    • 逆に言うと、内定獲得についてエージェントとの利害関係が強固に一致しているため、一緒に内定を取りに行く仲間として頼もしいとも言える

市場感

  • Web系エンジニアは圧倒的に売り手市場という感じだった
  • 業務経験3年程度(中級者)以上であれば引く手数多だと思う
  • 上場している有名企業を中心に受けたけれど書類と面接の通過率は予想以上に良かった

応募数

  • 15社に書類応募して13社通ってしまい、面接スケジュールが過密になってしんどかった
  • 本当に興味がある企業5社程度の応募で良かったと思われる

職務経歴書

  • そこまで詳しく読まれないことを前提として、主要なアピールポイントを上の方に分かりやすくまとめておくと良さそう

面接対策(一般)

  • 場数をこなすと面接はどんどん上手くなるので、一番最初のスケジュールに志望度の高い企業を入れるのはできれば避けたい
  • 職務経歴中心の自己紹介、転職理由、将来的になりたいエンジニア像、志望動機等の頻出の質問があり、基本的にどの企業でも同じような質問がされた
    • 転職理由と将来像と志望動機を一貫性がある形で構築すると良いというのが、エージェントに教えて貰った一般的な攻略法
      • これをウケが悪くなり過ぎない程度に本音に近い形で喋ることで、自分のやりたいことにマッチする企業かどうかこちら側からも見極めることができる
    • 自己紹介が当初長くなりすぎていて、途中から内容を絞って短くした
  • ハキハキとテンポ良く簡潔に分かりやすく答えることを意識するとウケが良さそう
  • 最後に質問時間があるので、事前に企業研究を良く行った上で、ビジネスモデル等について質問をすると好感触になりそう
  • とある人気企業の最終面接でカルチャーマッチや入社後の貢献イメージについてシビアに深堀りされてテンパってしまい、落とされた

面接対策(技術)

  • 自分が関わったプロジェクトで苦労したことやそれをどう乗り越えたかについてのエピソード、また実装上の工夫については聞かれることが多かった
    • どのプロジェクトについてアピールするかは事前に想定して、実装上の工夫について掘り下げて聞かれることを前提として詳しく準備しておくと良さそう
  • 技術的な観点は選考を通過するかだけでなく、内定後の社内グレードに基づくオファー年収にも関わってくるので、自分の業務経験や知識については可能な限り掘り下げて復習して臨むと良さそう
  • 質問に回答した内容について「それってどういうことですか?」みたいに2回くらい掘り下げられることを想定して、各技術トピックについての回答をイメトレしておくと良さそう
    • 掘り下げられたら答えに窮するような話題には自分からは触れず、理解度が一定以上高いトピックについてのみアピールすることを心がけると良さそう
  • 私が聞かれて困った質問は「DBのパフォーマンスチューニングやったことありますか」「大量アクセスを考慮した実装の工夫の経験はありますか」「Webアプリケーションにおけるキャッシュ利用について知っていることを教えてください」など
  • 個人開発の経験(私の場合短歌投稿サイトUtakataなど)は面接官の性格によっては話が盛り上がる(逆にまったく興味を持たれないことも多い)ので、職務経歴書に書いておくと良さそう

コーディング試験

何らかの実技試験がある企業も多く、形式には以下のタイプがあった。

メール試験

  • メールで送られてくる論述問題、プログラミング問題を2時間や3時間の制限時間内で回答して返信する
  • Google検索可能
  • Webアプリケーションの運用やパフォーマンス改善に関する論述問題と、オブジェクト指向プログラミング問題、アルゴリズム系のプログラミング問題の構成が多かった
  • アルゴリズム問題はググっても簡単に分からないような問題を出題して来るので、日頃から慣れていないと上手く回答することは難しい
  • Web APIを利用する問題は頻出と思われるため、フレームワークに依存しないHTTPクライアント利用については事前に慣れておいた方が良さそう
  • 必ずしも全問正解が内定の必要条件ではなく、アルゴリズム問題は解けなかったけれど内定が出た企業があった
  • 回答内容を後の面接でライブコーディングして更に掘り下げるタイプの選考をする企業があった

ライブコーディング試験

  • ビデオ会議ツールの画面共有またはHackMDのような同時編集ツールでリアルタイムにコーディングして回答する
  • FizzBuzz系のプログラミング問題(実行環境での実行あり)、ToDoリスト系アプリの要件を提示されテーブル設計する(実行なし)など
  • コーディング能力だけでなく、チーム開発上のコミュニケーション能力もチェックされる

アプリ開発試験

  • 簡単なWebアプリについて要件通りに作成してGitHubにアップして提出する

リファレンスチェック

  • 最終面接前後のタイミングで現職の上司、同僚にアンケート形式で職場での印象を書いて貰って提出する「リファレンスチェック」という仕組みを導入している企業がある
  • back checkASHIATOのようなリファレンスチェックサービスが利用されている
  • リファレンスチェックをお願いした人に転職活動していることを無断で経営者にシェアされてしまうトラブル*1があり、引き止め交渉があってちょっと大変だった

オファー

  • 最終面接を経て内定後、年収等の条件を提示されるオファー面談がある
  • この機会に残業時間等の条件を質問できるので、内定が出るまでの面接で労働条件についての質問をする必要はない
  • オファー年収については企業間での差がかなり大きくなる(私の場合3社で約50万円のレンジがあった)ため、選考が進んでいる企業については志望度がやや低くても安易に選考を辞退せず内定を取りに行った方が良さそう
    • 私の場合、当初の第一志望ではなくオファー年収が高い企業の内定を受諾した

個人的なキャリアプランについて

  • 現職が少人数ベンチャー企業であるが故のダメな部分を感じることが多かったため、もう少し体制のしっかりした企業が良さそうと思い、いわゆる大企業も受けてみたけれど、分業体制がしっかりし過ぎている会社は合わなそうだった
  • 私は技術力だけでなく、プロジェクト進行力とかビジネスサイド調整力などのコミュニケーション面も含めて勝負しないと相対的な価値が出ないタイプなので、そうなるとやはりベンチャー企業との相性が良いと再確認した
  • 転職後もかなりスタートアップ色の強い現場での仕事になる
  • 正直ベンチャーの「成長」周りのノリしんどいなあ、もっとマッタリ働きたいなあと思うところもあるけれど、流石に今のスキル感ではまだ守りには入れなさそうだった
  • ベテラン感のあるエンジニアになるのが直近の目標

*1:「やめて欲しくなくて」とのことだったけれど、勝手にシェアするのは流石にどうかと思った。

Next.jsでCMSにMDX形式で登録したコンテンツを利用する ―next-mdx-remoteの使い方―

Jamstackな構成では、CMSにどのような形式でコンテンツを登録するかが関心になって来るかと思う。

Markdownを採用する場合は、remark-reactやremark-htmlを使ってMarkdownをHTMLに変換できる。

ただ、実際にはMarkdownだと機能的に足りない部分が出て来そうで、MDXという、MarkdownにJSX(Reactコンポーネント)を埋め込める形式を利用すると捗る。

しかしこのMDX、CMSのような外部コンテンツとして登録する場合はどう使えば良いんだ?と思ったら、Next.jsの場合、next-mdx-remoteという便利なライブラリがあった。

next-mdx-remoteの使い方

例として、Next.jsのImageコンポーネントを利用してみる。

# プロフィール画像

<Image src="/images/profile.jpg" width="100" height="100" />

CMSには上のようなMDX形式で保存して、

Reactコンポーネントでこのように変換して利用できる。renderToStringhydrateメソッドの第2引数にMDXで利用しているReactコンポーネントを渡すといい感じに変換してくれるようだ。

JavaScriptで要素をフェードイン・フェードアウトで切り替える ―async/awaitでrequestAnimationFrameを使う―

妻の歌人としての個人サイトのトップページで、短歌をアニメーションで切り替える処理をJavaScriptで書いている。

jQueryには上のような専用メソッドがあるフェードイン・フェードアウト処理を自分でググりつつ書いてみたところ、試行錯誤できるポイントがあったのでまとめておきたい。

setTimeoutを使った当初実装

まずjQueryの実装は高度に共通化されていて読み解くのがなかなか大変そうだったので、ググって実装方法を探してみた。

このStack Overflowの回答が分かりやすかったので、参考にして実装してみた。

それがこれ。ループでsetTimeoutを使って100ミリ秒ごとに少しずつopacity(不透明度)を変化させている。

分かりやすい処理でちゃんとフェードイン・フェードアウトしたので満足しつつ、念の為他のサイトの実装例も色々と見てみたらもっと良い実装方法がありそうだった。

requestAnimationFrameを使ってより滑らかなアニメーションを実現

このサイトの実装例は明らかに私の当初実装より洗練されているように見えた。requestAnimationFrameというメソッドを使うと良いらしい。

このコールバックの回数は、たいてい毎秒 60 回ですが、一般的に多くのブラウザーでは W3C の勧告に従って、ディスプレイのリフレッシュレートに合わせて行われます。

ただし、setTimeout や setInterval は、ブラウザー側で再描画の準備が整っているか否かにかかわらず、必ず実行されてしまいます。また、ブラウザーのタブが非表示 (バックグラウンド) の場合でも常に実行し続けます。

一方で、requestAnimationFrame はブラウザーの負荷に合わせては 60 FPS 以内で再描画の準備が整ったタイミングで実行され、また、ブラウザーのタブが非表示 (バックグラウンド) にある場合は、発火頻度が自動で低下します。これにより、メモリーの消費を抑えることができます。

こういった理由で requestAnimationFrame はタイマーメソッドより、アニメーションの表現に向いていると言えます。一方で、正確な FPS を制御することはできません。

いい感じにブラウザのフレームごとにタイムスタンプを引数にしてコールバック関数を実行してくれるらしい。

このrequestAnimationFrameを使って上のように実装し直してみた。当初の100ミリ秒ごとの不透明度変更と比べて明らかにアニメーションが滑らかになっている。第2引数にフェードイン/フェードアウト持続時間durationを指定できるようになったのも分かりやすい。

async/awaitの利用

参考サイトと違うのはasync/awaitを使っている点で、

コールバック関数の引数にタイムスタンプが渡されることに注目して、1フレーム進んだ後にPromiseがタイムスタンプを引数にresolveして、const timeStampに1フレーム進んだタイムスタンプが代入される仕組みになっている。

その他の参考記事

Next.js + microCMS + VercelでJamstackなブログ付き個人サイトを作る

妻の歌人としてのブログ付き個人サイトをリリースしたので、技術的な観点をまとめておきたい。

Jamstack

f:id:fuyu77:20210111175547p:plain

これがサイトの構成図で*1、最近流行りのJamstackというアーキテクチャで作ってみた。

Jamstackは、静的サイトジェネレーターを用いてCMS等で管理するコンテンツをビルド時にすべて取得して、ユーザーアクセス前に用意しておいたHTML、CSSJavaScriptCDN経由で配信することで、画面遷移が非常に速い優れたパフォーマンスのサイト構築を可能にする。

CMS更新時のWebhook通知で自動デプロイする仕組みを入れることで、開発者がソースコードを触ることなく、サイト編集者で完結したサイト更新を行うことができるため、ビジネスから趣味の活動まで、静的サイト開発・運用の手段として有力な選択肢になるだろう。

  • 静的サイトジェネレーター
    • Next.js, Nuxt.js, Gatsby.js, Hugo, Jekyll等
  • ホスティングサービス
    • Netlify, Vercel, Firebase等
  • ヘッドレスCMS

Jamstackな構成をサポートする静的サイトジェネレーター、ホスティングサービス、ヘッドレスCMSには様々なサービスが覇を競っている状態で、ググると色々な構成例が出て来るので、サイトの目的や好みに応じてサービスの組み合わせを選ぶと良いだろう。私はNext.js(React)を使ってみたかったのでNext.jsとVercelを採用し、ITに詳しくない妻がサイトを更新するので、CMSには日本製で非開発者にもUIが分かりやすいと評判のmicroCMSを採用した。

Jamstackのメリット

実際にサイト開発、運用を経験して感じたJamstackのメリットについて書きたい。

お手軽ハイパフォーマンス

f:id:fuyu77:20210112181152p:plain

普通にNext.jsで開発してVercelにデプロイするだけでGoogleのPageSpeed Insightsで99のスコアが出るのはすごい。実際にサイトを触ってみてもページ遷移が非常に速いことが分かるだろう。

非開発者による更新も比較的容易

サイトコンテンツはすべてCMS上でMDX(Reactコンポーネントが使えるMarkdown)形式で管理している。microCMSにはリッチエディタ機能もあるけれど、仕事でリッチエディタを使っていて、想定外のHTMLタグが大量に混入して苦労することが多かったため、敢えてテキストエリアにMDX形式で入力する方式を採用した。

サイト更新者の妻はITにあまり強くないけれど、microCMSの管理画面を見ながら各APIのコンテンツ構成と、私が作成した初期コンテンツを元にMarkdownの説明を簡単にしたら、microCMS上でサクサクコンテンツ追加できるようになったので、noteやはてなブログのリッチエディタほど直感的に操作できないけれど、非開発者によるコンテンツ更新も比較的容易に行える感触だ。ちなみに妻にMarkdownエディタを紹介したところ面倒臭く感じたようで、microCMSの管理画面のフォーム上で直接更新して、デプロイ結果を見て実際の表示を確認していた*2。趣味のサイトであれば取り敢えずデプロイしてみる雑な運用もアリかなと思う。

開発体験が良好

Next.jsはReactベースのライブラリで、TypeScriptの導入も容易だ。TypeScriptの型チェックの恩恵を受けつつReactでキッチリとコンポーネント化できるフロントエンド開発は、普段仕事でBackbone.jsベースの複雑なSPAを触っていることと比較しても快適で、コーディングのモチベーションを終始高く保てた。Node.jsのライブラリ群も非常に充実している。

Next.jsは今回初めて触ったけれど、簡単なブログサイトを作ってデプロイまで行う公式チュートリアルが非常に易しく書かれているので、学習コストは低く感じた。

Reactの公式ドキュメントも日本語訳があり、分かりやすく丁寧に書かれていて助かる。

サイト制作手順

これから同様の構成で静的サイトを作ってみようという方への参考と自分用のメモのため、サイトリリースまでの手順を書いておきたい。工数的にはほぼ年末年始休暇中の作業でリリースまで持ち込むことができた。

  1. Next.jsのチュートリアルサイトを作成する
  2. GitHubチュートリアルサイトに名前を付けてリポジトリ作成する
  3. TypeScriptを導入する
  4. ESLintJavaScript Standard Style)を導入する
  5. CSSライブラリのBulmaを導入する
    • BootstrapをJSなしでCSSのみにしたような印象のライブラリ
    • 便利なスタイルが色々と用意されていて助かるが、 Bootstrapと同様に影響範囲が広くなるので、仕事で使うには注意が必要だと思った
  6. サイト構成・デザインを妻と相談しつつ決定する
    • ハンバーガメニューではなくフッターで4つのメニューを切り替える
    • トップページで短歌をフェードイン・フェードアウトで切り替えて表示する
    • 白背景に黒字をベースとし、アクセントカラーに緑を採用する
    • その他サイトタイトルやdescriptionなどを決定した
  7. ローカルにコンテンツを用意しつつ、各ページを作成する
  8. ローカルからmicroCMSにコンテンツを移動し、APIでコンテンツを取得する処理を書く
  9. CMSでMDX形式のコンテンツを管理する仕組みを導入する
  10. トップページで短歌がフェードイン・フェードアウトで切り替わる処理を追加する
  11. faviconとOGP画像を設定する
  12. VercelにGitHubリポジトリを連携してデプロイする
    • 環境変数(microCMSのAPIキー)の設定もGUIで簡単に行えた
    • GitHubにpush時の自動デプロイ機能がデフォルトで付いていて驚いた
  13. Vercel管理画面で独自ドメインを取得する
    • 分かりやすいUIでサクッと購入できた*3
    • 購入後自動で独自ドメインにアクセス可能になり、TLSSSL)の設定まで自動で始まって、約1時間後にTLS設定が完了した
  14. Vercel管理画面でDeploy用URLを取得し、microCMSのWebhook通知先に設定して、CMS更新時の自動デプロイを可能にする
    • Vercelのデプロイ用URLがエラーとなり機能しなかったが、Vercelのサポートに英語で報告したらすぐにバグ修正してくれた
  15. VercelからSlackにデプロイ通知する
    • プライベートでSlackを使っていないため、今回の実運用では採用していないが、仕事で使うならあった方が良いだろう
  16. サイト編集者にCMSの更新方法を案内する

*1:Slackのデプロイ通知については可能なことを確認したのみで、実際の運用は行っていない(プライベートでSlackを利用していないため)。図はDraw.ioを使って描いた。

*2:現状では30秒ほどでデプロイ完了する。

*3:お名前.comとは雲泥の差だ…。