魅力的な技術アウトプットを出すために心がけている7つのこと
気がつけばめっちゃ久しぶりどころか2023年初のnoteとなります。
色々書くので一旦前置きしておきます。
なお、これは個人の見解・意見であり所属組織及び業務とは何の関係もありません。
【前説】このエントリーは
技術ブログや外部登壇、はたまた就職・転職活動において、
私（shinyorke）がどうやってアウトプット（スライド・ブログ・ドキュメント）を魅力付けしているか？その考えと少しだけテクニックを紹介
することを目的としたエントリーです。
ウケる・読まれる技術アウトプットを出したい
会社の技術ブログやイベントの資料をいい感じにしたい
魅力的なドキュメント（CVなど）を作って就職・転職に活かしたい
方に刺さるような話になっている可能性がありますが、基本的に私のポエムとして読んでいただけると幸いです。
あらすじ&今年の前半戦
本題に入る前にちょいとした近況報告を。
気がつけば今年も半分が終わった訳ですが、前半戦（1月-6月）でいくつかのアウトプットを皆さまにお披露目することができました。
※発表動画はこちら、開始1時間18分ぐらいから見ることを推奨
登壇・発表の機会を頂いた皆さま、そして何よりも私のアウトプットに付き合っていただいた皆さまありがとうございました。
ここに上げたやつはそれなりにウケたりバズったりしていい感じになったやつです、もし興味あるネタがありましたらご笑覧いただけると私が喜びます。
私がこういう技術アウトプットを定期的に出し始めたのは2012年が最初で気がつけば10年以上やっています&こういうアウトプットは大好きなのでまだまだ続けていくつもりです。
で、ここまで色々アウトプットを出して、皆さまからの反響（かっこよく言うとエンゲージメント）を頂いていると、
ウケる（成功した）アウトプット、案外再現性があるノウハウや考え方があるかも
しくじったアウトプット（&つまらない技術コンテンツ）にも非常に再現性があったりする
なんか最近、「アウトプットのコツって何ですか」ってよく聞かれるし、「いいアウトプットと駄目なアウトプットの再現性」を言語化したほうがいい気がしてきた
と思い立ちました。
とはいえ言語化難しいな、、、って思っていたところ、何人かの人とお話をしていく（&他者・他社の良いアウトプット・駄目なアウトプットを見ている）中で言語化のアイデアと構成が思いついたので書いてみることにしました。
基本的には自分の思想やノウハウについて書いていきます。
魅力的な技術アウトプットのために心がけていること
「エンジニアの技術アウトプット全般で気をつけていること」をあえて3つに絞るとするならば、
学歴や所属企業、職位および経験でのマウンティングをしない様、自己紹介を控えめにする。
「このエントリーを読むにはPythonでHello worldぐらいは書けてほしい」など、聴衆・読者への期待値を宣言する。
内輪ネタを極力回避する。アニメやマンガ、TVドラマ等を知っている前提での話はしない。
これは登壇資料もブログも共通して気をつけている事です。
自己紹介を控えめに
学歴や所属企業、職位および経験でのマウンティングをしない様、自己紹介を控えめにする。
もうちょっと優しく言うと、
誰が読んでも不快にならないコンテンツを目指す
といった所でしょうか、読む人全員が…というのは流石に無理だとしても、80%ぐらいの人が不快に思わない、であれば実現可能と考えています。
マウンティング（マウント）の意味ですが、
マウントとは、見えを張って相手よりも自分の方が優位だと見せつけるような言動を指します。
動物が自己の優位性を示すために相手にまたがることをマウンティングといいますが、人間の場合はまたがるのではなくさまざまな言動として現れます。
「言動や言葉で己が他者より優位である」事を示すのがマウンティングという行動な訳ですが（私の解釈としては）、これは技術アウトプットの場合、
所属企業名。誰しもが知っている会社であればそれだけでもオオッてなる。
職位（肩書）。CxOとかなんちゃらマネージャーとか強い役職はマウント取れそう。
学歴。高学歴な方は勿論なのですが、少し特殊な学歴でもマウントになるケースもあるので注意が必要。
職歴・経験。「Python歴10年」とか「東京リージョンができる前からAWS触ってました」とか老Guyに繋がるもの。
他にも色々あると思う（SNSのフォロワー数など）のですが私の考えおよびやってることとして、
経歴系の話は転職活動のCV（履歴書）なら堂々と載せるべき内容（自分の経歴として誇るべき内容なのでちゃんと載せる）ですが、大多数が見る・読むアウトプット的には大した意味を成さないので控えめに
しています、出すのが全く駄目っていうよりも経歴で威圧する書き方・表現はマイナスはあれどプラスは無いというか。
正直私もマウントを取れるような経歴をしているので最近のアウトプットでは、
自己紹介のスリム化。スライドなら1スライド、ブログ記事なら2, 3行で収める。
自己紹介は名前とアイコン、何してるか（仕事・趣味）をサクッと書く。
不必要と感じたら社名は出さない。
これで収めるようにしています。一応言っておくと、
所属企業や役職なんかの経歴を披露した所で技術的アウトプットが面白くなることはないです、面白くする要素はあくまでも中身にある
これに尽きるでしょう。
聴衆・読者への期待値を宣言する
「このエントリーを読むにはPythonでHello worldぐらいは書けてほしい」など、聴衆・読者への期待値を宣言する。
一言で言うと「オンボーディングをしましょう」ということです。
発表スライドなら最初の方のスライドで説明、ブログや資料ならサマリーとして書くとかそういう所でしょうか。
これは言葉で表すより例を出したほうがわかりやすいですかね。
最近の私の発表は毎回必ず「対象読者」「こんな方にオススメです」的なオンボーディングを入れるようにしています。
聴衆・読者への期待値（前提知識・モチベーション等）を宣言することで「合う人は最後まで見て・聞いてほしい」「合わない方は出てもらって大丈夫です」という「聴衆・読者への行動を促す」事をしています。
これは自分のブログや発表資料の反響から学んだ事でして、
ネガティブなコメント、面白くなかった等のコメントは真摯に受け止める
とはいえ、発言した方の情報・属性を見ると「そもそもこの人対象じゃなくね？」という例にも気がつく
「対象者をあらかじめ指定」「前提知識やモチベーションを明言」することで、合わない人は最初から読まない・聞かないというのが実現できるのでは？→実際にできた（ネガティブなコメントは減った&あっても対象じゃないと安心して見れるように）
ある程度バズる発表やブログの宿命でもあるのですが、「人気みたいだしひとまず読んでみるか」という感じでアクセスが来たり、オンサイト開催の発表でも「shinyorkeさんの野球の話面白いらしい」とか聞いて（これは非常に嬉しいことです、涙が出る程度に）人が来たりするのですが、そのContextだけだと期待値が合わなかったりするので、敢えて出ていく口を作ったりしています。
おっと、自分の話を長くしすぎました。
個人でも会社でも、技術ブログや登壇などで「多くの人に読まれたい」「バズりたい」欲が出てくる（もしくは会社や採用担当とかから要求される）こともあるかと思いますが、
一般公開する技術アウトプットにおいて、「多くの人が不快にならない努力」をする必要はあるが、「万人受けする、多く人が満足する」ための「過剰な努力」はすべきではない。
何故なら技術アウトプットはどうしても前提知識やモチベーションが必要でそれは万人が持っているものではないから。
と心がけたほうがいいと思います、「エンジニア採用するためにバズるコンテンツお願いします！」とか（素人に）言われたら上手く宥めながら最適解を考えましょう、やらないという選択肢も含めて。
内輪ネタを極力回避する
内輪ネタを極力回避する。アニメやマンガ、TVドラマ等を知っている前提での話はしない。
まずエンジニアの発表、アニメとかマンガの話をしがちです。それについては良い文化ですし、否定はしないのですが、どんなに人気なアニメやマンガ、TVドラマなどでも万人が知ってるわけじゃないので使い方を間違えると（技術アウトプットが）一気につまらなくなります。
この辺どう考えているか、Chat GPT（GPT-4）先生にも聞いてみました。
アニメやマンガ、ドラマなどの話や画像を引用することは、視覚的なエンゲージメントを増やし、聴衆とのつながりを強める効果的な手法です。以下にそのメリットと注意点を挙げてみます。
メリット:
1. 親近感: 同じ文化背景を共有している聴衆に対して、アニメやマンガなどの話を引用することは親近感を生むことができます。これは特に、若い世代や特定のサブカルチャーに所属する聴衆に対して効果的です。
2. 複雑な概念の説明: 物語やキャラクターを用いて複雑なアイディアや概念を説明することは、聴衆の理解を深めるのに役立ちます。
3. 記憶の強化: 物語は人々が情報を記憶するのに役立つと広く認識されています。一般的に、物語を通じて伝えられた情報は、単に事実を列挙しただけの情報よりも長く記憶に残ります。
注意点:
1. 著作権: あなたが使用する画像や物語が著作権に触れないように注意する必要があります。許可なく著作権のある素材を使用すると違法となります。
2. 共有の前提: 引用する話や画像が聴衆にとって理解可能で、彼らがそれに共感できるかどうかを理解することが重要です。例えば、特定のアニメやマンガを知らない聴衆に対しては、その引用が理解できないかもしれません。
3. プロフェッショナリズム: 場合によっては、アニメやマンガを引用することが不適切であると見なされることがあります。会議の文化や聴衆の期待を理解することが重要です。
適切に使用すれば、これらの引用はプレゼンテーションをよりエンゲージングで覚えやすいものにすることができます。ただし、注意点を理解し、引用が聴衆にとって有意義で適切であることを確認することが重要です。
最後の注意点「プロフェッショナリズム」は微妙な事言ってる気がしますが（間違っちゃいないけどマンガもアニメもコンテンツとして引用が適切なケースの方が多いような気も）、合ってる気がします。
私が最も懸念しているのは、「共有の前提」で、見ている人にとっては有名なシーンやセリフであったとしても、一定数知らない人は出てくるので結果「内輪ネタ」になってしまう事が多々あります。
（+画像系は著作権の問題も出てきます）
その他、内輪ネタの候補としては、
スポーツネタ、特に野球。私はめっちゃ野球ネタをやってますが、あらゆる手を使って内輪ネタの回避に努めています（後述）。
技術コミュニティの古株しか知らないネタ。勉強会やカンファレンスで通り名とかスラングとかを当たり前にだすのはいいとして、新規参加者が多い時は控える（もしくは説明する）ようにしないと。
特定の業界あるある。コンサルのあるある、スタートアップのあるあるetc…
芸能系のネタ。アイドルでもゴシップでもなんでも。
歴史ネタ。大河ドラマ等の時代劇も含む。
GPT-4先生が言う通り、内輪ネタは「親近感」「複雑な概念の説明」「記憶の強化」という強力すぎる効能（一言で言うとドーピング効果）があるので魅力的ではあるんですが、何気にこれらを上手くやって内輪ネタを使うのは高等テクニックだったりするので避けるか、前述した「聴衆・読者への期待値を宣言する」テクニックとの合せ技で回避（知らない人は聞かなくていいorそれ前提で聞いてとお願い）するのがベストかなと思っています。
私の野球ネタについては「聴衆・読者への期待値を宣言する」事で内輪ネタ感を回避する努力をしていて、
野球ネタを話す時は必ず「野球の話である」事を宣言する（不意打ちはしない）
「オオタニサンが誰か知っている」「三振・四球・本塁打の意味がわかる」等、最低限知ってほしい事はちゃんと宣言する。
可能な限り、ルールや球団、選手を知らなくてもいいように、公開データや客観的な指標で上手く肉付け・説明を行う
これをずっと徹底しています、元々私の野球ネタは「野球を知らない・オタクじゃなくても笑って楽しんで興味を持ってもらえること」を目指して作っているので（私を含めた野球オタクの内輪にならないように）。
ブログ・ドキュメントのひみつ
全般的に心がけている事以外に、ブログやドキュメント限定で心がけていることもあります。
これは過去にnoteでも書いたことがあります。
基本的には1st View（最初に目に入るところ）を頑張ることでいくらでも映えるのですが、
タイトルとサムネイルで説明ができるように心がける
TL;DRは絶対につける。TL;DRで説明ができると完璧
この2つ（+最初に語った3つ）を取り込めばいい感じになります。
タイトルとサムネイルで説明
興味を引く意味では「タイトルとサムネイル」この2つに全集中すべきです。
https://twitter.com/shinyorke/status/1650998165452242945?s=20
GW前後に悩みがちなキャリア話を自分のリアル話含めて書いてみました「お前は何がしたいのか」ブログ.
— Shinichi Nakagawa / 中川 伸一 (@shinyorke) April 25, 2023
エンジニアとして30代までにやってて良かった・やれば良かった事を自分のキャリアから振り返ってみた. - Lean Baseballhttps://t.co/s02zLv3YMO
上記はよく読まれたブログのツイートですが、
ブログとして書こう、と思いついたことを「エンジニアとして30代までにやってて良かった・やれば良かった事」というタイトルで素直な言葉にした
言葉だけで説明はキッツいので、「キャリア・スキル・アウトプット」「転職歴」のマトリクス表を描いてサムネイルにした
この2つの営みのお陰でSNSの限られたサイズでの説明ができるようになりました。
いきなり長々と文章を書く前に、
タイトルと見出しを決める。全体構想を考えて俯瞰した後に作文する。
タイトルと見出しを元にサムネイルになりそうな絵を考えてみる。説明ができるのであればイラストや写真でもOK。
会社の技術ブログを書いている人は特にこれやったほうがいいです、何だったらタイトルと見出し、サムネイルを作ったら一旦レビューに出すべきです（WIPなブランチをプルリクレビューしてもらって、方向性間違ってないか見てもらうのと同じような方法です）。
なお実践例は過去にもちょろっと公開しているので参考にしたい方は是非お読みください。
TL;DRは絶対につける
技術ブログ、基本的にはTL;DR（Too Long, Didn't Read、いわゆる要約）は付けるべきです（絶対とは言わないが）。
ブログ全体の要約を書くのが難しければ、「聴衆・読者への期待値を宣言」するのに使ってもいいと思います。
30代が終わる前に「公私ともに認める技術スキル」「マネジメントとロジカルシンキング」「英語」を実践レベルで使えるエンジニア（ITコンサル）になれると, 色々幸せになれると思う（自分の経験より&異論は認める）
エンジニア系職種, ITコンサルやプロダクトマネージャー等々, 細かい違いはあれどこの3つは共通してそうな気がします.
上記はバズったブログのTL;DRから引用なのですが、
タイトルとシンクロするように「30代でやってよかった・やればよかった」事をシンプルに語る（技術スキル、マネジメント、ロジカルそして英語）
「色々幸せになれると思う」という個人的な感想を書きつつ、読者に興味を引く
「エンジニアもコンサルもマネージャーも読むといいよ」としれっとオススメ
といった背景でこの様に書いたのですが結果大成功でした。
TL;DRを先に書いて本文を書いても、本文を書いた後にサマリーしてTL;DRを書いてもどっちでもいいのですがいずれにせよあると説明になるのでオススメです。
ちなみに私はTL;DRを先に書く派ですが、本文を書いた後に変更したり書き直したりすることもありますし、思いつかない場合は最後に書いたりします。
登壇のひみつ
ラストは講演やLTといった「人前で話す」時の心がけです。
これは過去にあまり言及していない話かも。。。
「掴み」「オチ」の作り込みは非常に重要。私はお笑い（漫才）の構成を元に学習して真似をしています。
自分の話す声・スピード・大きさを活かす。自分の特徴・個性を知って活かす戦略・作戦を決めて実行する。
「掴み」「オチ」の作り込みは非常に重要
トークの最初、「掴み」で興味を引いて、「オチ」で回収するとトーク全体がストーリーっぽくなってしっかりなるのでオススメです。
プレゼンのスライドの作り方やノウハウ、決め手は探せば探すほど色々出てくるのですが、私の場合は「漫才」を参考にすることでいい感じになりました。
元々漫才が大好きなのですが、いつの頃からか「爆笑問題さんみたいなスピード感で技術トークできたらいい感じになるのでは？」という思いつきでやってみたら上手く行ったので気がついたらそのような構成になりました。
自分が心がけているシステムとしては、
話の最初「掴み（もしくは枕と呼ぶ）」で聴衆が興味を引く（ツイートなどSNSでシェアする）ようなコンテンツを絶対入れる
掴んだ勢いで本編をさーーっと話す
最後、「掴み」で触れた話をちゃんと回収しつつ「オチ」を付ける。いわゆる「伏線回収」をすることで記憶付けて終了。
なお最後の「伏線回収」の件はNON STYLEさんの漫才から学習しました。
「人命救助」のネタが個人的には伏線回収の教科書になっています。
余談ですがNON STYLE大好き（M1優勝はリアタイでTV見てた程度には同世代）なので毎週新ネタ見てます。
自分の話す声・スピード・大きさを活かす
自分の話す声・スピード・大きさを活かす。自分の特徴・個性を知って活かす戦略・作戦を決めて実行する。
私の場合、自己分析および他者からの評価で、
テノールっぽい声なので聞き取りやすい
話すスピードは速めで早口になると早すぎる時がある
声は大きい方でマイクが無くても声が通る
ということがわかっているので、
テンポとスピードを重視した構成を目指す。1スライドあたりの話す量を減らす代わりに枚数を増やす。
重要なスライド・ワードはゆっくり話す&繰り返す。早口すぎて流れていかないように大切なことはゆっくり言ったり2度言ったりして印象に残す。
この2つを徹底しています。
ここで一個注意があるのですが、
声が小さい（大きい）、話すのが早い（遅い）、声が高い（低い）を無理に矯正する必要はありません、自分の個性を活かす最高の方法を見つけて実践すべきです。
矯正の辛さを味わうよりも、
色んな人に発表を聞いてもらって感想を聞く。まずは自分を知ることが大事。
自分の特性にあった話の構成および機器の調整を考える。
声が小さい・低いのが悩みであればマイクの入力レベルを上げたり等、機器を調整する（今どき地声で話すことも無いと思うので）
話すのが遅いのが気になるのであれば、スライド枚数を減らして全体の総量を減らし、重要なワードだけ残す。
といった努力をしたほうが健全です、個性は絶対活かすべきだと思うので。
話が商売の漫才師でも色んな人がいるように、技術トークも色んな人がいるんで無理に上手い人のマネをするんじゃなくて自分の個性を活かす方法を取りましょう。
なお、人前のトークがうまくなりたい人は「ひたすら練習」「時間内に話す」技術を身につけることが必須条件となります。
魅力的な技術アウトプットが自分のキャリアをいい感じにする
という訳で、「魅力的な技術アウトプットを出すために心がけている7つのこと」を紹介しました。
最後にもう一度おさらいします。
学歴や所属企業、職位および経験でのマウンティングをしない様、自己紹介を控えめにする。
「このエントリーを読むにはPythonでHello worldぐらいは書けてほしい」など、聴衆・読者への期待値を宣言する。
内輪ネタを極力回避する。アニメやマンガ、TVドラマ等を知っている前提での話はしない。
【ブログ・ドキュメント】タイトルとサムネイルで説明ができるように心がける
【ブログ・ドキュメント】TL;DRは絶対につける。TL;DRで説明ができると完璧
【登壇】「掴み」「オチ」の作り込みは非常に重要。私はお笑い（漫才）の構成を元に学習して真似をしています。
【登壇】自分の話す声・スピード・大きさを活かす。自分の特徴・個性を知って活かす戦略・作戦を決めて実行する。
この辺は他のエンジニア・技術系トークが上手い方の意見も聞いてみたいです、反対のアプローチでも上手く行ってる人はいると思いますし（特に内輪ネタの件は賛否両論めっちゃありそう）。
心がけの話はさておき確かなのは、
魅力的な技術アウトプットはエンジニアおよびビジネスマンとしての自分のキャリアをいい感じに豊かにするものである
これは自信を持って言えます、大変なところはありますがゾーンに入ってお披露目できるようになると色々キャリアが開けます。
このエントリーがそんな技術アウトプットを残す方々全般の参考になると嬉しいです。
最後に一つだけ。
このエントリーは何人かの友人やビジネスパートナー達との会話（主にお茶や食事）の中で得た知見・気づきの集合体が元で完成にこぎつけました。
楽しい会話、思い出がこのような形で言語化出来たことを心から感謝します。
どうも、ありがとうございましたー。
頂いたサポートは、書籍購入・コミュニティ支援および、個人プロダクト（開発中）のリソースとして活用させていただきます。