やわらかテック

興味のあること。業務を通して得られた発見。個人的に試してみたことをアウトプットしています🍵

すごい人と比べて落ち込んでも続けるべき2つの理由

僕の一番の悩み😔

ずーっと悩んできたことがあります。

何をするにも、その業界にはプロや達人、先駆者、すなわち「すごい人」がいるのです。
それは偉大な商品の発明者だったり、プロだったり、ありえない程の年収を稼いでいたり、新規の技術の研究者かもしれません。

彼らの存在事態が悩みではありません。では、何が悩みなのかというと「彼らの背中はあまりにも大きく偉大である」という点です。自分も「コンピューター」という業界で同じ道を志そうと思っているのですが、とてもとても追いつける気がしません。

もちろん、彼らが途方もない努力、経験を重ねていることは承知しています。
なぜ憧れてしまうのか。カッコいいと率直に思うので、少しでも追いつきたいと思ってしまい、今の自分と比べてしまうのです。

自分には優れた才能も能力もありません。誇れるような学歴もありませんし、何かを成し遂げた経歴もありません。今まで何をしてきても上位50%程度がいいところです。

このような壁を感じると自分は萎縮をしていまいます。自分が取り組むことに意味はあるんだろうか、自分がやったところで二番煎じでしかないという気持ちになってしまいます。

結果的に何かを始める前、もしくは少し取り組んだ時点で諦めてしまい続かなくなったことがたくさんあります。

それでも続けるべき理由が2つある🔥

そうだとしても続けることが大切だという理由をずっと考えてきて、最近、納得のいく理由を2つ閃きました。
「頑張る事が大切!」「努力は報われる!」という...一般論ではなく、合理的な理由です。

理由1

1つ目は「あなたが続けると業界のコミュニティが大きくなる」ということです。

具体例を挙げるとすると、まだ日本ではマイナーで広く知られていない楽器があるとします。その楽器をたまたま見つけたあなたが、その楽器を始めてみました。

すると、日本での楽器のプレイヤーが増えるため、コミュニティは大きくなります。
コミュニティが大きくなると良い事がたくさんあります。より多くの商品が開発、改良されたり、マイナーだった楽器がyoutubeやニュースで紹介されたりと多くの人の目にとまる可能性が高くなります。

さらに人が増えると、コミュニティは繰り返し大きくなっていき上記の作用が繰り返し発生していきます。

コミュニティに属してるつもりはなくても、続けることで結果的にコミュニティは大きくなっていくのです。

理由2

2つ目の理由は「スタート地点は誰しも同じ。すごい人も過去にその道を通過している」ということです。

すごい人だって同じ人間です。過去に自分と同じように悩んでいた時はきっとあります。生まれ持ったもの、今までの努力の積み上げで一歩の大きさに違いはあれど、少しでも近づく、差を縮めるには同じ道を進むしかありません。

近道はないのです。地道にやるしかないと改めて気づきました。

総括📖

すごい人と比べて落ち込んだ時は2つの理由を思い出すようにしています。
自分が続けることでコミュニティは成長していくので、自分のやっていることが多くの人に知れ渡っていきます。そうすると、上記では書きませんでしたが、コミュニティが大きくなった結果、新たな仕事や価値が生まれることもあるでしょう。

近道はない以上、地道に続けるしかありません。誰しも同じ道を通ってきたと自分に言い聞かせましょう。

AmazonPrime会員だと無料で読めます

怖いコードレビューを楽しくするために自分が使っている絵文字を集計してみた

コードレビューって...怖いんだって😢

いつものようにTwitterを徘徊していると、Rubyのチェリー本などで有名な伊藤淳一さんがこんなツイートをされていました。

コードレビューに関するツイートで、「テキストだと何を考えての指摘なのか、どういう理由でそう思ったのかが伝わらない、伝えられない」という事があるから大変だよねという意図のツイートだと受け取りました。これはおっしゃる通りで、中々、テキストだけだと自分の意図が伝えるのが難しいですし、思った事を全てテキストにしていては時間がいくらあっても足りません。

自分もコードレビューをする立場となりまして、この悩みは毎日感じてします。
その解決策の1つとして自分はコードレビューをする時は可能な限り、強い言葉、冷たい言葉だと相手に誤解を与えないように絵文字を添えるようにしています。絵文字を添える事でなんとなく雰囲気が明るくなるのです。ひと昔の情報の教科書にはWEBでコミュニケーションをする時は顔文字を入れようと記述されてしましたが、それはあながち間違いではありませんでした。

newspicks.com

絵文字とコミュニケーションをテーマにした論文もいくつか出ているようです。

世間一般のコードレビューのイメージ

いつものようにラッコキーワード(旧:関連キーワード取得ツール(仮名・β版))を使って、「コードレビュー」という単語とよく組み合わせて検索されている言葉を調べてみると以下のようになりました。

related-keywords.com

  • コードレビュー やり方
  • コードレビュー 観点
  • コードレビュー 怖い
  • コードレビュー 偉そう
  • コードレビュー 嫌い
  • コードレビュー 傷つく
  • コードレビュー うざい

などなど...
想像以上に多くの人がコードレビューに対してネガティブなイメージを持っているのだということが分かりました。元々、口調が強かったり圧の強い人の可能性もあるでしょうが、先ほど紹介したテキストだと思っていることが正確に伝わらないという問題も絡んでいそうですね🤔

普段自分が使ってる絵文字を紹介するぜ😎

自分のコードレビューを受けてもらっている人に少しでも楽しい雰囲気を伝えるために、絵文字を使うようにしていると先ほど紹介しました。ある日、ふと自分がどんなコードレビュー中にどんな絵文字をよく使っているのかなぁ...と気になりました。
自分がgithubPullRequestに対してコードレビューを行った際にしたコメントを全取得して、よく使っている絵文字を集計してみました。

集計方法

githubAPIを使って特定のレポジトリのPullRequestに対して投稿されたレビュー(コメント)を全件取得します。そこから自分がレビューした内容でかつ、絵文字が含まれているレビューのみを抽出します。残ったレビューの中から、それぞれの絵文字をカウントし、登場回数が多い順にソートして集計を完了します。

集計に用いたレポジトリは以下になります。一度しか使わないであろう書き殴りのコードです。

github.com

補足として、githubAPIは1回のリクエストにデータの取得件数にリミットがかかっており100件までしか取得する事が出来ません。なので、全データの取得が完了するまでページネーションを用いて再帰的にデータを取得し、.txtに内容を書き出しました。
合わせてデータの集計には手軽さを求めてpythonjupyter notebookを使用しました。

対象のエンドポイント 
GET: /repos/{owner}/{repo}/pulls/comments

集計結果🏅

対象となったレビュー件数は全部で517件で絵文字が含まれていたレビュー件数は180件でした。まずは上位5件の絵文字を発表していきます。
(なぜか♂という記号が結果に含まれていましたが、おそらく「🙇‍♂️ = 🙇♂」が原因だと思われます)

  • 1位: 🤔 -> 登場回数: 80
  • 2位: 🙇‍♂️ -> 登場回数: 51
  • 3位: 👍 -> 登場回数: 14
  • 4位: 👀 -> 登場回数: 12
  • 5位: 💪 -> 登場回数: 4

1位の「🤔」は予想通りでした。自分はよく相手に疑問を投げかける時にこの絵文字を使うようにしています。相手に「マウントを取りたいわけじゃないよ!」「何を考えてそうしたのか教えてほしい!」という思いを込めています。
2位の「🙇‍♂️」はタイポや軽微な修正をお願いする時にそっと添えるようにしている絵文字です。小さな修正でも指摘されて、修正しておいてねと一方的に言われると当人にとっては結構なストレスだったりします。別の作業に取り掛かっていた場合などは特にそうですね。忙しい中、悪いけど、お願いします!という思いを込めています。

残りの絵文字は「ナイス!いい感じだね!」というハッピーでポジティブな思いを伝える時に使用している絵文字ですね。季節や流行りによって使う絵文字が変わるので、集計してみると色々な絵文字が出てきました。

👵🍨🌸🤚🎉🕺🌮🍧🍏🧹🐝😂
🕺

(なんだこれ...)

総括🤓

こういった絵文字を使うことで暗くなりがちなコードレビューを少しでも楽しい雰囲気になればと思っています。
ただ、一番大事なのは絵文字でもなく、コードレビューをする側も、される側もお互いにリスペクトを持つということです。やってもらえるのが当たり前ではありません。その上でテキストでのコミュニケーションに気をつける事が出来れば、なお良しですね。

では、楽しいコードレビューを🙇‍♂️

ブログ飯を読んではじめて書いた記事をリライトしてみた

なぜリライトしたのか🤔

先日ですが、「PV増やしたいなぁ〜」という想いから色々なブログを散見していると「ブログ飯」という書籍を一度読んでみると良いよという意見が多いことに気づきました。

値段も1000円程度で非常にお手頃だったので「とりあえず読んでみるか」と思い、ワンクリックで購入しました。また「ブログ飯」に関する詳細は感想は別の記事にしようと思っているのですが、本書の中で、以下のようなことが記述されており、僕の目に止まりました。

3ヶ月ぐらい記事数が溜まったら、最初のうちに書いた自分の文章を読み返してみましょう。
私も時々、ブログのメンテナンスのために昔の記事を読むのですが、いや、これが恥ずかしい。
よくこんな文章で自信満々に公開していたなぁ、と顔から火が出るぐらい恥ずかしいです。

合わせて、記事数を重ねる事に記述する力は変化し続けているので、過去の記事をリライトしてみるのも良いという意見がありました。良い機会なので、自分がはてなブログに初めて投稿した記事を考察しつつ、リライトしてみようと思いました。

はてなブログで初めて書いた記事🗒

すでにリライトしているので、Gistの方に移動させました。スタイルなどははてなブログの形式になっていませんが、当初のままの文章です。
直接内容を貼ってしまうと長くなってしまうので、外部リンクとして添付しました。

はてなブログに初めて投稿した記事 · GitHub

一部抜粋...

## 私は帰ってきた(自分目線)

初めまして。苗字が岡部なのでOKBと名乗っています
決してどこかの銀行を真似しているわけではありません
ブログ開設時(20190326)の時点で僕は22歳です
大学の学部を卒業したばかりの新米です

内容ですが、「新米エンジニアが一度挫折したブログを再び開設しました」というタイトルで「一度、挫折したブログをこれから再挑戦するぞ!」という記事になっています。丁度、この記事を書き始めた頃にマウントをとられまくってて、かなり悔しい気持ちで一杯だったのを今でも覚えています。

そんな思いが込められている記事ですが、重要なのはこの記事を見てくれた人がどう感じるか、どう思うかです。
まずは今の自分から見て、この記事がどう見えるのか考察から始めていきます。

考察👓

率直に良いと感じた点と悪いと感じた点を書き出してみました。
総評としては「楽しんで書いてるのは分かるけど、何を伝えたいのか分からない」といったところです。
こんな文章を書いていた頃があったんだなぁと思い返すと、確かに...恥ずかしい思いで一杯です...😅

良いところ

  • 自分の世界観がある(eg: 自分目線, (ボソ など)。今の自分が使わないようなユニークな文章の書き方
  • 内容が簡潔ですぐに読み終える事が出来る
  • 楽しんで書いているなぁと感じる
  • ビギナーならではの勢いのようなものを感じる

悪いところ

  • 口調が人によってはうざいと感じるかも
  • 「、」「。」があったりなかったりで統一感がなく読みにくい
  • 文字数が少ない。情報量が少なく、日記的で伝えたいことが何なのかよく分からない
  • ネガティブな単語が見かけられる(eg: アホなど)

リライト開始👷‍♂️👷‍♀️

タイトルの再設定

まず気になったのは記事のタイトルです。
「何を伝えたいのか分からない」と感じたのは誰に向けた記事なのかが定まっていないからです。当初の自分は特に考えもなく最初の記事だ!と張り切っていました。せっかくなので新しい記事のタイトルは読んでほしい層を設定したいので、読んでほしい層を箇条書きで書き出してみました。

  • ブログをこれから始めようと思っている人
  • 過去にブログをやっていたが挫折してしまった人
  • 新卒のエンジニア
  • ブログを始めようと思っている、迷っているエンジニア

まずですが、元々の記事にあった「新米エンジニア」という単語は見てもらいたい層と一致しないです。ここは素直に「新卒エンジニア」という単語を使います。Googleトレンドで確認してみても新卒エンジニアというワードの方が圧倒的に多いのです。

f:id:takamizawa46:20210814155232p:plain

合わせて、ブログをこれから始める人、挫折した人が調べているであろうキーワードを予測します。思いついたのは以下の5つです。

  • ブログ 続かない
  • ブログ 挫折
  • ブログ つらい
  • ブログ 無理
  • ブログ 難しい

そしてラッコキーワード(旧:関連キーワード取得ツール(仮名・β版))を用いて、それぞれのキーワードがどのようなキーワードと合わせて検索されているかを確認してみます。目的としてはユーザーがどのような検索結果を期待しているかを把握するためです。それぞれのキーワードと合わせて調べられているのは以下のようなワードでした。

related-keywords.com

  • ブログ 続かない -> 割合, 2ch, 理由, 副業, ダイエット, 仕事, 筋トレ
  • ブログ 挫折 -> 挫折率, 挫折した, 初心者, アフェリエイト, 中学受験, ライザップ
  • ブログ つらい -> 不妊治療, 更年期, 住宅クローン, 子育て, 貧乏, 独身
  • ブログ 無理 -> 無理ゲー, 収益化, 稼ぐ, 収益, 毎日更新
  • ブログ 難しい -> 書く, 言葉, 収益化, 続ける, 継続, 稼ぐ, アフェリエイト

意外だったのは、「挫折」「つらい」といったキーワードがブログに対しての挫折ではなく、とある何かに挫折した記録のブログを見たいという人が多いという点です。そんなことも知らずに以前の自分は「挫折」というキーワードをタイトルに使っていました。キーワード1つでユーザーの目的が変わるのは非常に興味深いです。

合わせて、それぞれのキーワードがどれだけ調べられているか比較してみました。あくまで比較であり、検索の総量を把握することは出来ませんが、どのキーワードを選択するかで悩んだ時にはGoogleトレンドは最高のツールです。

f:id:takamizawa46:20210814155856p:plain

上位3つのキーワードはこのようになりました。

  • 1.ブログ 難しい
  • 2.ブログ つらい
  • 3.ブログ 無理

ただし「つらい」というキーワードの上記の理由により候補外です。残るは「難しい」と「無理」ですが、難しいという言葉がタイトルで使うのは厳しいと判断したので「無理」という単語を使ってみます。試しに「ブログ 無理」とGoogle検索に入力すると予測ワードに「ブログ 無理ゲー」と出てきました。「ブログ 無理ゲー」というキーワードでバズっているブログあるようなので、そちらの波に乗っかろうと思います。

現時点で「新卒エンジニア ブログ 無理ゲー」というキーワードが決まりました。あとはエンジニアにフォーカスするために「エンジニア ブログ」とよく合わせて検索されている「アウトプット」「メリット」というキーワードを組み合わせて「【アウトプットは最強のメリット】新卒エンジニアが無理ゲーのブログに再挑戦します」というタイトルが完成しました🎉

related-keywords.com

本文の更新

随分とタイトルの選定に時間がかかってしまいました。しかしSEOではタイトルが非常に重要になるそうなので時間をかけるべき所だと考えています。
さて、残るは本文です。こちらは元の記事の構成を少し変えて、ほとんど新たな文章として書き直しました。構成として自己紹介を大きく取り除きました。
自己紹介は記事内に書くのはあまり良くなく、興味の有無が大きく分かれるため固定ページに記述し、リンクを貼るのが良いそうです。合わせて、何点か修正を行いました。

  • 自己紹介を本文から消した
  • 万人受けする口調に変更した
  • 分かる人には分かるネタをそっと添えた(オラオラ!
  • 動機と理由が自然に感じられるように過去 -> 現在という流れを意識した
  • 改行を適度に用いて、煩雑な文章に見えないようにした
  • ホップな雰囲気を出すために絵文字を用いた
  • 専門用語にはハイライトを当てた(eg: 元記事ではCSという単語がいきなり出ていた
  • 情報量を増やした。なぜ強い人になりたいのかという経緯を追加した

これで本文の更新も完了しました。

完成🤗

新たに完成した記事はこちらです🎉

www.okb-shelf.work

今の自分のブログっぽさが出ました。大満足です。こうして改めて振り返ってみると、自分の文章を記述する力も変わっているのだなぁと感じました。 まだまだ強くなりたいですが、こういったメリットがあるのもブログの良さですね。「誰でも出来るけど、やってる人はあまりいない」...。まさにその通りです。

【感想・まとめ】「関数型プログラミングなんもわからん。を考えよう」に参加してきました。

関数型プログラミングなんもわからん。を考えよう」とは🤔

connpass.com

ABAB↑↓BA (@ababupdownba) | Twitterさんが主催された関数型プログラミングの疑問や質問について、ひたすら有識者の方々が丁寧に回答をしてくれる・ディスカッションする会です。わかる枠わからない枠の2枠が用意されておりまして、初心者の方であっても気軽に参加することが出来ます。

ただ、質問して積極的に参加した方がより楽しめると思いますので、初心者であっても聞きたいことはいくつか用意しておくと良さそうです。 「お、面白そう!」と思いノリと勢いを元に、今回はわからない枠で参加させて頂きました。

主催者のABAB↑↓BAさん
twitter.com

勉強会はDiscordにて開催されて、カメラONは任意のボイスチャット主体で進行され、質問はFigmaに付箋として貼られていくものにひたすら回答するというスタイルでした。初対面の方が多い中で中々、話し出すのに勇気が要りますが、Figmaに質問を貼っておけばテーマとして扱っていただけたので聞きたい事が聞けて帰ってくる事ができました。

以下、個人的に気になった事と自分が質問した内容について簡単に自分の言葉でまとめてみました。他の質問や、参加者の方が書いてくださった丁寧な回答のメモが以下のFigmaの共有リンクから確認可能ですので、気になった方は覗いてみてください。

www.figma.com

気になった事 / 質問したこと🧐

関数をどうまとめればいいですかね…? オブジェクト指向はオブジェクトの責務でまとめたり…

難しい質問で場合による。
- オブジェクト指向との親和性はある
  - 型やデータ構造でまとめるのが基本
- 関数型だとかオブジェクト指向とかパラダイムによらない

この話を聞いて思い出しのはgolangの構造体に対して関数を定義した実装です。定義したデータ構造に対して、処理を作っていくというのがオブジェクト指向だろうが、関数型だろうが、手続き型であっても、ベストプラクティスになるのだと感じました。

type Pizza struct {
    Size int;
    Price int;
}

func (p Pizza) getSize() int {
    return p.Size
}

func (p *Pizza) setSize(newSize int) *Pizza {
    p.Size = newSize
    return p
}

play.golang.org

関数型らしい書き方ってどんな感じになるでしょうか…? オブジェクト指向っぽい書き方になってしまう…。

- 大切なのは読みやすいコードを書くこと
- haskellには制約が多い。変数はイミュータブルのみ。副作用は除外されている  -> haskellっぽい書き方
- 言語の文化に合わせることが重要。関数型らしさよりも気にした方が良い
- 理解のために言語のコアのパッケージがどう作られているのか見てみるのが良い

このテーマは自分もかなり気になっていました。自分が最初に触れた関数型言語elixirです。書籍プログラミングElixirでは以下のような内容を習得しました。

  • ループ構文がないため再帰関数を書くこと
  • map, filter, reduce等を使ってリスト主体のデータを処理するパイプラインを組み上げること
  • 無名関数、高階関数のパワフルさ

しかしhaskellなどに代表されるような、強力な型システムと型推論、純粋な関数と副作用の分離、イミュータブル(変更不可能)な変数については部分的に登場するものの、詳細は語られていません。そのためhaskellのような純粋関数型言語に謎の憧れがあったりました。haskellに近い状態になる書き方が正しいという先入観がありましたが、elixirにはelixirの文化があるのだということを改めて認識し、いっそう好きになりました。

とはいえ純粋な処理と副作用のある処理の分離、可能な限りイミュータブルな変数を使わないというのはどの言語でも共通して目指す所なのではないかなと感じました。

関数型の言語にはモナドとかの概念が出てくると思うんですけど、そこで圏論とかの数学的な知見の学習って必須だったりしますか?

- 必須ではない。なくても大丈夫
- 数学が出来なくても関数型言語を記述することは可能
- 圏論の知識を持つことで抽象的な理解をすることが出来る -> 他言語を触ったときに「あぁ、これね」と理解がしやすくなる

確かに。haskellというと圏論圏論というと数学...という非常に難しいイメージが先行しております。自分も過去にモナドについて理解しようと数学の定義を覗いて「おっ」となった事があります。しかし数学は数学であり、プログラミングはプログラミングとのことで、数学の定義が必ずしも値やルールの定義ではないので、知らないからコードが書けないわけではないそうです。

自分が現在読み進めている入門Haskellプログラミングでも「習得には書くのが一番だよ〜」と記述されていました。その通りですね。

関数型のパラダイムを学ぶことで得られる強みはなんでしょうか?

質問させて頂きまして、ご教示を頂きました🙇‍♂️

- 関数型言語だからバグが減ったような感じはしない
- バグが減らせている印象がある。
  - たとえばif分岐だとしても、Elm、HaskellだとElseも必ず書かないといけない
  - 全てのパターンを網羅する必要がある。 -> Null・Undefinedエラーにならない
- 例外的な扱いが型で扱えるので、失敗パターンを処理する強制力がバグを減らす効果があるように感じる
- 制約が強い言語であればあるほど、書き方が統一される
- テストが後付けで絶対に書ける(IOは難しい) -> 全ての関数が値を返す
- 型があることで変更に強くなるコードが書ける

たくさん回答を頂きました。変更に強くテストが書きやすいというのはバグを減らすという視点とはまた別の利点でした。忘れてしまいがちなnullのケースを必ず捌く必要があるというのも記述は大変になる分、やはり非常に強力です。現在、本番稼働で発生しているエラーのほとんどがnullによるエラーによるものです。このエラーがなくなれば、どれほど安心か...

まとめ📖

様々なテーマが扱われておりました。
今の自分には理解が難しいテーマもありましたが、関数型というテーマだけでこれだけ話が広がるというのは素晴らしい事だと感じました。合わせて、同じよう悩みを多くの方が抱えているということにも改めて気づくことが出来ました。モチベーションが上がりました。素敵な会をありがとうございました💪

connpass.com

www.figma.com

おまけ: 関数型に期待していること

現在、とあるプロダクトにてスクラムマスターという立場でチームメンバーが記述したコードをレビューする事が多くあります。その中で、変更される変数やファイル操作のような副作用が各所に見られており、実際にこれらがバグの現在になることが非常に多いです。またバグの発生時には上記の状態のコードは原因特定が非常に難しいのです。

いかにして関数型のパラダイムを取り込んで、バグの少ないコードを書き、プロダクトの品質を高く保っていくかという事に非常に期待を持っております。元々は興味本位で初めたelixirですが、今日の話を通して、自分の実現したい事がハッキリしました。

【配線スッキリ】macbookとswithへの給電が出来る最高のアダプターを購入した

ごちゃつく配線周り😓

僕は配線が見えるという状態があまり好きではありません。というか嫌いです。生活感が出るのが嫌で、可能な限り配線が見えない状態を作るように、頑張ってきました。色々と配線周りの最適化を進めてきましたが、ずっと残ったままの課題が1つありました。それが業務とプライベートで使用しているmacbookNintendo switchの配線の共通化です。

業務とプライベートで使っているのがmacbook(M1 AirとPro)の2台。そして気晴らし程度に1週間に2, 3回遊ぶのがNintendo switchです。使用の比率としては9:1程ですが、配線としては5:5の状態になっていました。

macbookmacbook air購入時に付属されていた純正の30W USB-C電源アダプターで給電を。Nintendo switchも購入時に付属されていた純正のアダプターで給電を行っています。

www.apple.com

コンセントの数には限りがあります。無印で購入したコンセントタップを使っていますが、2つのアダプターによって2つの口が使用されております。さらにアダプターはサイズが大きく、2つのアダプターを同時に使用すると4つの内の1つの穴が塞がれてしまい、結果的に3口が2つのアダプターによって使用されてしまっております。

www.muji.com

「アダプターを共通化できないものか...」と考えておりましたが、いくつか問題がありました。

問題🤔

アダプターの互換性

macbook Air付属のアダプターを使うことでmacbook(AirとPro)switchに給電をすることは実は可能です。しかしswitchの純正品のアダプターは15.0(V)×2.6(A)=39.0(W)になるので、数値的にはmacbook Airのアダプターでは給電が追いつかないという判断になります。じゃあmacbook Proのアダプターを使えば?と思うところですが、サイズが大きく自分が使っているケーブルオーガナイザーから飛び出てしまうのです。

またswitchのアダプターを使ってmacbookにも給電が出来るのですが、推奨されていないようです。詳細は専門外の分野なので扱いませんが、switchのアダプターは厳密にはtype-cではないそうです。

hanpenblog.com

switchの画面への出力

せっかくなので僕はswitchのモニターに出力して大画面で遊びたいと思っています。ゲームは大きい画面でやるのが良いですよね。switchをモニターに出力するのには最低でも30Wの給電が必要になるそうです。純正のアダプターはこの問題を丁度いい感じにクリアしています。では単純にWの数値が高いアダプターを買えば良いかというとそうではないようです。

テレビモードを行うことで出来るアダプターは限定的なようで、いくらかブログ記事を周回しましたが確定的な情報は得られませんでした。しかし最低でも30Wは必要になるという条件は間違いないと判断しました。ドックを経由してswitchをテレビモードでモニターに出力しようと試しましたが、macbookAirの付属アダプターではダメでした。しかしmacbookProの付属アダプターではモニターに出力される時とされない時がありましたが、出力されることを確認出来ました。

合わせてswitchは現状、純正の付属のドックを経由しないとテレビモードの出力をすることが難しいようで、いくつかUSB変換ハブを試しましたが、どれもダメでした。本当は1本のtype-cケーブルをmacbookswitchに刺して切り替えるという構想を考えていましたが、ここだけは諦めました。

購入したもの🎉

以上の問題点を踏まえて、自分が購入したのは「Lettop USB-C充電器 100W」になります。

(いつの間にか傷がついてしまった👀)

こちらの商品です。

type-cのアダプターで100Wもの出力をしてくれる優れものです。65Wのモデルもあったのですが、type-cのポートが2つもあるのならiPhoneも充電しちゃいたいなと思い100Wのモデルを選択しました。

非常に軽くサイズ感も丁度良いです。macbookAirの純正のアダプターと同じぐらいの大きさです。手のひらに収まります。

...。

とまぁ、この商品が良いものだというのはyoutubeなりで前情報をかなり調べていて事前に知っていたので当然なんですが、問題はmacbookに給電が出来て、ドックを使ってswitchをテレビモードでモニターに出力することが出来るかです。

macbookへの給電💡

アダプター -> USBハブ(HDMIケーブルとtype-cを1本のtype-cに変換) -> macbookと繋げています。

問題なく給電できました🎉
モニターへの出力を行いながらmacbookへの給電もされています。ケーブルも1本にまとめられても最高ですね。

switchへの給電 / テレビモード💡

アダプター -> switchドック(HDMIケーブルとtype-c)と繋げています。

モニターに出力することが出来ました。しかしUSBハブを用いた場合はやはりダメでした。アダプターの電圧もありますが、それ以外にも何かしらの条件がありそうです。switchのテレビモードに対応可能なUSBハブがあれば、ぜひ教えて頂ければと思います🙇‍♂️

総括🍸

Lettopのアダプターを購入してmacbookNintendo switchへの給電を共通化することが出来ました。大満足です。これでコンセントタップに一口空きが出来たので、何か新しくガジェットを買ったとしても大丈夫です。

こちらのアダプターですが、普段は5500円程で販売されていますがセール時であれば4000円程で購入出来るようですのでご参考までに。

https://graph.keepa.com/pricehistory.png?asin=B08R3DFRR4&domain=co.jp