パウリのしこう

しこうをまとめます

「またここに来たい」「そこに行きたい」と思わせる場にする #emconf_jp

学びになるだけでなく、 「楽しかった。また来たい。」 「今回行けなかったけど、次こそは行きたい。」 そう思わせるようなカンファレンスにしたい。

🔷 セッションは魅力的！でも、それだけでいいのか？

EMConf JP 実行委員会のパウリです！

昨年に引き続き、 EMConf JP 2026 も大盛況に幕を閉じましたね！

今年もオープニングを務めました！朝から満席！！

さて、 今年もセッション内容、めっちゃ良かったんじゃないでしょうか

今年は昨年からセッションルームを1つ増やした上でも、倍率は20分枠：約17倍、40分枠：6.5倍と、そんな狭き門を潜り抜けた珠玉のセッションたちでした🔥

採択されたトークはどれも素晴らしい内容で、開催後のアンケート結果では93.9%の方が良かったと感じていました✨

タイムテーブルにも休憩しながら見れるギリギリのセッション数を詰め込みました💦

「そろチェキした後、話すのが難しかったです」

昨年も募集状況からセッション内容が期待できることは明らかだったので、これを聞くだけの設計ではなく、自主性や関係性構築もしてほしいと思い「そろチェキ」という、ネームカードにある割印を合わせてチェキを撮ろう！って企画をしました

ただこれに対してのフィードバックで、

「知らない人ともチェキ撮ってみたけど、共通点や話題を見つけて話し続けるのが難しかったです」

という声がありました。

確かに「ネームカードの柄が揃っただけ」という繋がりで一緒にチェキを撮るというのは、話すきっかけ作りはできるかもしれないですが、その後話し続けるフックとしては弱いかもしれないと気付かされました...。

ここから「自然と人が交わる仕掛け」の設計へと意識が向いていきました。

ちなみにこのチェキについて、元々仲の良い方や、WEBで繋がってなくてEMConf JPで初めて話した方が記念としてチェキを撮ると盛り上がっていたので禁止という形にはせず、今年は当日スタッフの提案により、記念パネルとチェキを持って会場を歩き回るという形での実施となりました🚶

最高！

オフライン体験の質が問われる

さらに、どんなに良いセッションがあっても、物理的な参加を忌避されてしまっては元も子もありません。

「混雑しすぎて動きづらかった」

「知り合い同士が喋っているだけで、楽しみきれなかった」

「荷物の出し入れが多く面倒だった」

などと思われてしまったら、「わざわざオフラインで開催する意味はないんじゃ？」となってしまうかも...。

オフライン開催ならではの温度感・体験を提供するのと同時に、オフラインならではの面倒ごともなくしていきたい🔥

守りたい、この笑顔

「楽しかった。また来たい。」を個人の胸の中で終わらせない

昨年に引き続き今年も開催し、また懇親会では「来年も開催するぞ宣言」がされました🔈

今後も年々開催されていくとなると、リピーターの方も楽しみつつ、毎年やるなら、常連だけが楽しい場になるのは避けたい。

毎年コンテキストが蓄積されていき、それを前提としていくと排他的になってしまう。 初めて来た人が「なんか入りづらい」と感じた瞬間、多様性が失われかねない。

だからこそ、参加者同士だけでなく、参加していない人とも EMConf JP をつなげたい！

🔷 EMConf JP 2026 で続けたこと、新しくやったこと

「わかるー！ウチもこんな状況で〜...」コミュニティで話が盛り上がる時

実際に何をやったかに入る前に...

私は EM Oasis をはじめとしたコミュニティでの活動や、勉強会イベントで話していく中で、EMとしてついついやってしまう行動や考えなど話している時に盛り上がりを感じました。

「あの人でも、ついついこれやっちゃうんだ」「やっぱこれ難しい課題なんだ」と共感を得たことから、「じゃあこれも...」と話が広がっていく...。 その流れで、ともに雑相（ザッソウ）のように課題に対する改善策について話されていったりと、ただ楽しいだけでなく、難しい課題にともに取り組む空気がそこにはありました。

そんなゆるく話せる環境を作りつつ、その共感を参加者だけでなく、参加できなかった方にも届けるべく思わずシェアしたくなる仕組みづくりをカンファレンスでもできないかしら？

「EMのそういうところ展」の爆誕💥

そこで、某有名展示会から着想を得て、「EMのそういうところ展（以後：ところ展）」が爆誕しました。

EMが頑張る空気作りや、ついついやってしまう振る舞いなど、「あるある〜」な話題をゆるいイラストとともにパネル形式で掲示してみました！ これにより、

  • オフライン開催ならでは感
  • 参加者同士の会話のきっかけ
  • 会場の様子をSNSへ投稿するきっかけ
  • セッション・会話疲れした時にも休みながら楽しめる

が実現できました！

ところ展のひろがり 〜楽しい空気は休憩室から飛び出していく〜

さらに、ただ展示するだけでなく、自由記入もできるホワイトボードも用意しました！ 結果、想定していなかったEM仕草がどんどん書き込まれた。ホワイトボードの前で足を止めた人同士が、自然と話し始める...。

EMのそういうところ展自由記入ボード
EMのそういうところ展自由記入ボード

さらに先述したチェキ企画ともコラボできるよう、自分自身がところ展のパネルになれる顔ハメパネルを作成し、2〜3人で一緒に枠の中でポーズを取って撮影できるようにしました。

SNSでもワイワイしてくれた！

これで EMConf JPに来たことがない人のタイムラインにも、EMの興味関心だけでなく、普段口にはしない日常も流れたかも？

モリモリ盛り上がり

実際にフリー入力コーナーに立っていると、こんな光景が生まれました。知り合いが来て話し込む。そこにまた別の知り合いが来る。気づいたら、知らなかった人同士がつながって話し始めている。人と人との接点を生むきっかけになったのは、まさに意図通りでした。

パウリも話しました！

結果として...

アンケートの「よかったと感じた企画」では40.1%とセッションに次ぐ2位を記録 🎉

一見、おまけ企画に見えるかもしれないですが、学びになるだけでなく「楽しい」が付随すること、これは私にとっては Must でした。

SNS　―EMConf JPに興味を持っている方へ常に最新の情報を届け続ける

私自身カンファレンスに参加する中で、カンファレンス内の情報をどこで得ていたかというと、SNSでハッシュタグや公式の投稿をみて、移動したり次の行動を決めていました。

また、実は昨年のアンケートで「参加しようと思ったきっかけ」のうち、なんと 57% の方が「SNSを見て」だったんです！

そのため公式アカウントでは開催前だけでなく、開催中もスタッフ協力のもと定期的にSNSを更新し、お知らせを伝えるだけでなく、会場内の動きを SNS 上でも表現していました。

これにより、セッション毎のアナウンス、Ask the Speaker、サイン会のスケジュール、アンカンファレンスなど会場内で今何が起こっているのかを俯瞰的に見れるようにし、参加していない方でも会場の雰囲気を感じ取ることができました（と思います！）

ネームカードとサイネージの設計　―手荷物ゼロで情報にアクセスできる仕組み

これまで私が参加してきたカンファレンスでは、パンフレットを別途配布されて、その中に会場マップやタイムテーブルが載っていることがありました。

ただ私はズボラなので、バッグの中に押し込んで結局そのまま出すことはないまま...。ってことが多々ありましたw

そのため、今回の EMConf JP 2026 では「手荷物を増やさず、手元ですぐ情報を見られる状態」を目指しました。

解決策は、ネームストラップへの情報集約です。

使用頻度に応じて、ホルダー内と別添カードに分けて設計しました。

配置 内容 理由
ホルダー内（表面） 名前・プレーリーカード・名刺 常時見える必要がある
ホルダー内（裏面） 全企画の説明 一度読めば十分。出し入れ頻度が低い
別添カード（表面） ブースラリーのスタンプカード シールを貼るため頻繁に取り出す
別添カード（裏面） 会場マップ すぐ確認したい

さらに細かい話ですが、首から下げた状態でカードを裏返して会場マップを見たとき、天地が逆さまにならないよう印刷の向きまで設計しています。

パッと確認したい参加者（私）は、少しの負担でもストレスに感じることが想定されたので、一瞬も手間にならない状態にしたかったためです。

ストラップの先のカード

ちなみに、当初はネームカードの裏面や別添カードに各セッションルームのタイムテーブルも載せることを検討しました。

ただ 3 セッション分の情報をポストカードサイズに収めるのは無理があるし、「この部屋であっているっけ？」と確認したくなるのは、部屋の前に立ったときです。

そこで、各セッションルームの前にサイネージを設置し、その部屋のタイムテーブルを表示するようにしました。 （実現したのは 941 さん）

こんな感じでタイムテーブルが確認できます！

いちいちWEBページを開いて確認しなくても、部屋の前に行けばわかる状態、これも楽ですよね。

（…とかっこよく言いましたが、デザインをギリギリまで粘っている中で会場視察に行き、活路を見出した結果だったりしますw）

企業やプロダクトから外れた環境での「場の設計」が EM の地続きなスキル？

EMの仕事は、管掌範囲の組織が最大限の力を発揮できるような環境を整えることだと考えています。

その中には開発プロセス改善やらチームビルディングやら育成・評価やら、時には採用などなど... 時に間接的に、コードを直接書く以外の形でも、組織の地力を高めていくこともあります。

マネジメント業務を続けていくと、管掌範囲の拡大、組織の自律性向上、マネージャーの育成など、組織課題を直接解決することから間接的へ、つまり徐々に支援対象の課題解決を促す「場を設計する」こともスキルとして必要になっていきます。

チーム内で本音を吐露する場の設計。そもそも本音を吐けるような関係性構築の場の設計。チーム外との連携を円滑にするための場の設計...。

「このままでいいか」ではなく「もっと良くできないか」と考え続ける。その姿勢がイベントの体験に表れている ...と信じています。

小さなエスカレーションでも全力で取り掛かります

そして忘れてはならないことがあります。そもそも開催できること自体がすごい という事実です。

実行委員だけでなく、開催に携わったすべての関係者が場を成立させている。 見えない準備と調整の積み重ねがあります。 関係者への敬意は、どれだけ強調しても足りません。

開催当日、早朝から事前に会場を確認するスタッフ一同

来年のEMConf JPへ向けて　―あなたの意見を聞かせて！

「ここに来たい」と思ってもらえる場は、一度の成功では作れません。毎年少しずつアップデートしながら、参加者との信頼関係を積み上げていくものです。

最後に、この記事を読んでくださったあなたに問いかけたいことがあります。

あなたが参加した「場」で、「またここに来たい」あるいは側から見て「そこに行きたい」と思ったきっかけは何ですか？

その答えが、来年の EMConf JP を作ります。

新しい顔と知った顔が混ざり合うあの瞬間を、また作りたい。

また来年、あなたに「またここに来たい」「そこに行きたい」と言わせて見せます。

これ元ネタわかった人おるんかな？

まずは「やってみる」ではなく「手を挙げる」までだな。と思った

以前とあるイベントをやった際、集客観点での設計で致命的なミスをしてしまった。

 

やっぱ「まずはやってみる精神で首を突っ込む」のは良いけど、徹頭徹尾その精神でいていいわけではないと再認識。

 

今思い返して、どうすれば気づけたか？を考えると、結論必要な「観点」がないと難しかったと思う。

 

Think Different ではなくUXデザインやWEBマーケティングに共通する体験設計の話。

この体験の「焦点」はあっていたが、「観点」が足りなかった。

 

失敗自体は悪くないけど、納得のいく失敗をしたい。

 

この失敗は「失敗から学びに繋がった」のではなく、

「途中でリスク回避・体験改善策を思い出した」ことが個人的に気に入らない。

 

企業としては甚大なミスではなかったんだけど、自分なりの「誠実」を表現しきれなかったことがよろしくない。

まずは「やってみる」じゃないんだよ。まずは「手をあげる」までなんだよなぁと。

 

手をあげた上で、やるにはその領域の専門知識があるはずだから学習しながら進めるか以前学習したことを思い出すことから入る。

 

失敗してから考えるじゃない。それで迷惑がかかっている人がいる。

人には人の人生がある。その人生の貴重な時間を蔑ろにしてはいけない。

 

一緒の時間を過ごすなら、常に最高のパフォーマンスで望む。手は抜かない。

そのために事前に学んで、活かす。これができなかったのが不甲斐ない。

 

まだまだ自分には知識の「定着」が足りない。脊髄反射で回答できる程度に学習しなければ。

「言語化支援力」がAI時代の専門職の生き方となる

AIによる「専門職」は不要ではないが、ある点において敷居は下がった

昨今AIのあのツールを使えばデザイナーは、エンジニアは、ライターは不要になる…と耳にします。

こういった発言をするのは、往々にして「当該専門職以外の方」であることが大半だろうなとスルーしていました。

が、その本心としては「その職務を軽んじる発言はどうなんだい」と、クリエイティブやエンジニアリングの奥深さを知らず、表面的な出力だけを見て語られているように感じていたのも事実です。

この感情的な反発は一旦脇に置き冷静に現実を見つめると、確かにAIの進化によって「それっぽいもの」を出力できるようになったという点においては、「専門性の敷居」が劇的に下がっているのもまた事実です。

これまでソースコードを書けなかった方が、有名落ちゲーっぽいゲームを作成できるようになったりと、実際にその効果を感じている方もいると思います。

本記事では、この専門性の敷居が下がった環境下での専門職の振る舞いについて、また必要となる「言語化支援力」についてまとめます。

 

既存の生存戦略と、そこにある「もう一つの視点」

私はエンジニアの界隈に身を置いていますが、この状況下で専門職がどう生き残るかについて、様々な議論を目にします。

  • 「AIを扱うマネージャーやディレクターになろう」

  • 「コードそのものより、文化や組織のコンテキスト（文脈）を理解した発想力が重要になる」

これらの主張にも納得できます。

AIはあくまでツールであり、この出力結果に責任を負うのは人間です。

では今後、専門職として手を動かし続けるために必要な「共通のスキル」とは何でしょうか？

 

AIを使いこなす鍵は「構造の理解」にある

そもそも、AIを使って「正確で質の高い出力」を出せる人は、一体何が違うのでしょうか。

それは、「当該生成物がどのような構造で、どのように表現されているのか」の解像度が圧倒的に高いという点です。

例えば、AIにプログラムを書かせる場合を考えてみましょう。

ただ「いい感じのアプリを作って」と頼んでも、AIは自身の脳内にある「正確で質の高いモノ」を出力しません。

 

ではいざ「実用に耐えるもの」を出力するにはどうすれば良いでしょうか？

それには、出力される成果物にどのような論理性があるのか、その思考プロセスがどうあるべきかを知っている必要があります。

仮にAIがそのプロセスを瞬時に出力したとしても、その中に使われている単語や概念、プロセスそのものが正しいかどうかを判断し、理解できなければ、修正も応用もできません。

つまり、結果として「専門知識」は不可欠だと考えています。

AI時代であっても、むしろAI時代だからこそ、ブラックボックスの中身を推測し、評価できる専門性が求められます。

 

これまで専門職と呼ばれていた人々は、専門知識を持たない人（クライアントや他職種）に対して、その専門性を提供してきました。

これからは、「専門知識を持たない人が、AIを使って何かを作れる前提」がある中で、「（専門職であれば）正確で質の高い出力を出し続けられる」という相対的な優位性が発揮されることになります。

 

相手を始点とした「言語化支援力」

ここで必要となるのが相手が表現しようとしている曖昧なイメージや目的を深くヒアリングし、時に相手自身でも気づいていなかった出力へ導く力である「言語化支援力」です。

 

これからの専門職の仕事は、単に成果物をゼロから作ることだけではありません。

AI時代においては、非専門職である相手が「何を作りたいのか」「どう表現したいのか」という曖昧なイメージを形にする手助けこそが、最大の価値となります。

また先述の通り、AI を用いて「正確で質の高い出力」を出し続けるには、特定専門領域の解像度の高い理解を元とした単語や概念、プロセスを AI に伝える必要がありました。

これは、いわゆる「言語化能力」の一端ですが、今回の「言語化支援力」では、その始点が自身の考えではなく相手が言葉や表現しきれていないイメージから、それを汲み取り解釈し翻訳することだと強調したかったため、言語化「支援」力としています。

 

言語化支援力でAI時代の専門職として生きる

専門職以外の方が、専門職のようなことをAIを通じて行おうとする時代。

そこで私たちに求められるのは、彼らを否定することでも、AIと競うことでもありません。

彼らの「やりたいこと」を、私たちの持つ専門性というフィルターを通して、AIに正しく伝えること。そして、AIが出してきた答えが正しいかを即座に判定すること。

「相手の想いを言語化し、専門的な言葉に翻訳する力」

この「言語化支援力」が、AI時代における専門職の新しい存在意義であり、生き方となってくると考えています。

 

チームの安定性を高める「カオスチーミング」を考えてみた

【いなくなったら困る人】が突然いなくなった！に対処する「何か」が欲しかった

退職や、ネガティブ・ポジティブな意味合いの長期休暇は、これまでの社会人経験の中で幾度となく発生していました。

これらは自分の視点だと、いつ発生するか分からないですし、もちろん他メンバーから見た私も例外ではないと思います。

仮に私がいなくなっても業務は止まらないとは思いますが、私だからできている判断や行動もあるかもしれません。

ここに対して事前に引き継ぎをしようと、考え方や手法、各種権限などの資料を作成しようとしていると、時間がかかるかかる。

また作成し切っても、実感が得づらいのではないか？とも思っていました。

そこで考えついたのが「カオスチーミング」です。

 

カオスエンジニアリングっぽく、チームでも何かできないかな？

まずカオスエンジニアリングとは、Netflixをはじめとする先進企業が実践する手法であり、システムに意図的に障害や混乱（カオス）を起こし、その耐障害性や回復力をテストするアプローチです。

実運用環境下で「起きるかもしれない問題」を早めに炙り出して、サービスやシステムをより堅牢にする目的があります。

 

ここから着想を得たカオスチーミングとは、あえて混乱や障害を意図的に導入し、チームの回復力や学習力を高めることをとします。

私たちは往々にしてチーム内で「不測の事態が起きない」ことを前提に業務やプロジェクトを進めてしまいます。

しかし、現実の組織やプロジェクトには常にメンバーの離脱、突然の計画変更、チーム内外のコミュニケーションロスなどの 「チーム障害リスク」 が潜んでいます。

 

ハイパフォーマンスなチームを解散するのは単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ

by アラン・ケリー

この言葉を受け、じゃあ「外発的な要因でハイパフォーマンスなチームが解散してしまうことになったら？」に対しては何かしら手を打ちたいと思っていました。

 

これらのリスクが実際に顕在化してから慌てるのではなく、事前に発生させてみよう！というのがカオスチーミングです。

 

カオスチーミングの狙い

  1. 変化や困難への対処、意思決定力の向上
    環境の変化や予定外の困難に対処し、チームが素早く柔軟に対応できるよう強化します。

  2. 知識のサイロ化防止
    キーとなる業務知識や人脈が特定メンバーに依存しすぎている場合に、それが顕在化しやすくなり、対策を立てられます。

  3. プロセスの透明性向上
    チームの各種プロセス（意思決定の流れや役割分担など）を見直すことで、継続的な改善を促します。
    また表出化していないコミュニケーションチャネルの洗い出しも期待できます。

 

他にもありそうですが、こんなところですかね。

 

カオスチーミングの実施ステップ

1. 仮説を立てる

可能であれば「私が1週間いなくなったら、Xプロジェクトはどうなるのか？」「急に顧客から仕様変更が入ったとき、チーム内で誰が調整できるのか？」のような、障害・混乱が実際に起きた場合の「チームとしての課題仮説」を立てます。

ただし、この仮説を立てるというのも容易なことではないと思いますので、「なんとなくHOGEが発生したらヤバそうだけど、何がヤバいかは言語化できてないので、カオスチーミングやってみてヤバかったことをリストアップしたい」くらいで実施しても良いかと思います。

 

2. チームに「意図的な混乱」を導入する

1. を元に、以下のような「意図的な混乱」を導入します。

 

2-1. メンバー離脱シミュレーション
あるメンバーを意図的に休暇扱いにし、他メンバーが代役を務めます。また、その離脱者は別のことをするか本当に休暇する必要があるので、普段できない長期計画や個人的な仮説検証などリストアップしていおくと良さそうです。

 

2-2. ロールシャッフル
リーダーや特定担当者を入れ替えてみる。短期の「リード交代」を実施します。

 

2-3. 情報共有チャネルの制限
通常使っているチャットツールやメールを一時的に制限し、別のコミュニケーション手段をテストします。

 

2-4. スプリントやゴールの変更
進行中のプロジェクト目標やタスクを突然変更し、新しい方針を即時共有・実行してみます。

 

3. ふりかえりで学びと改善策を言語化する

チーム内の反応・コミュニケーション量・成果物の遅延などを定量・定性の両面で記録し、分析します。

また分析結果を踏まえた具体的な改善策をチーム全体に共有し、改善策をチームのプロセスやルールに組み込み、次回以降のカオスチーミングも継続して実施し、チームとしての成熟度を上げることを目指します。

 

カオスチーミングを安全に導入する3つのこと

  1. チーム課題の探索が目的であり、個人攻撃が目的ではない
    「意図的な混乱」であっても、個々のメンバーが攻撃されていると感じないように配慮します。目的はチーム力向上であり、特定の人を責めるものではないことをしっかり周知します。

  2. 段階的に導入する
    いきなり大きな混乱を起こすと業務に深刻な支障が出てしまう、また課題の要因が複雑に絡まってしまい、分析が困難になる可能性があります。まずは小規模・短期間で検証します。

  3. 定期的な振り返りの場の設計
    「やりっぱなし」ではなく、すぐに学んだ知見をフィードバックし、チームのプロセスやルールをアップデートし続ける仕組みを用意します。

 

まとめ

「カオスチーミング」は、カオスエンジニアリングの発想を人間のチームに適用し、組織やプロジェクトに潜む潜在的リスクや課題を意図的に浮き彫りにして強化する手法です。

普段の業務では見過ごしがちな依存関係やコミュニケーションロスを早い段階で発見し、学習することで、いざ本当に危機が訪れたときの対応速度や柔軟性が格段に高まります。

  • 「本当に起きたら困る事態」をあえて起こして学ぶ

  • チームメンバー全員が当事者意識を持ち、小さな実験を繰り返す

  • 失敗からの学習を素早く組織全体に展開する

これらを定期的・継続的に行うことで、しなやかなチーム体制を築くことが可能になります（多分）。

技術の領域だけでなく、人やプロセスを含めた総合的なレジリエンス強化を目指すうえで、カオスチーミングというアプローチも選択肢の1つにしてみてはいかがでしょうか。

 

 

EMConf JP 2025 登壇スライドまとめ

本ページ投稿時点で公開されている EMConf JP 2025 の登壇資料をまとめました ご連絡いただければ、追加で公開された資料も追記していきます

※ 表記揺れ等あってもご容赦ください

キーノート

ホールA

ホールB

「PREOモデル」で整理する技術広報の専門性

技術広報活動が活発になってきた

昨今のエンジニア界隈では技術広報活動が活発になっているようい感じています
先日企画推進した「DevRel Guild Conference Mini」ではオフライン参加50名、オンラインも合計すると100名以上の登録数となり、「技術広報というキャリア」を歩んでいる方も増えてきているようでした

一方で、よく 「技術広報ってどう評価すればいいの」
「技術広報の活動やスキルって再現性ないよね」
と耳にします

（私個人の特性として）再現性のない状態を放置するのは、自身としても技術広報をキャリアとしたい方々にとっても好ましくないと思っています
またこういった中でも、この活動を推進する方が、キャリアとして不安に思わないためにも、まずは専門性を評価できるような叩き台を作り、これを元に界隈の標準を作ろう！と決心しました
そこで本記事では、「PREOモデル」と名付けたフレームワークを通じて、技術広報の専門性を少しだけ具体化してみます

結論

技術広報の専門性は以下4つの力に分けられる

  • 戦術策定力（Planning）
  • 関係構築力（Relationship）
  • 情報表現力（Expressiveness）
  • 組織構築力（Organization）

PREOモデルの図示

前提

  • パウリが実施している技術広報業務のストリームを整理した結果です
  • 現在PREOモデルは試験運用中です（2025/02/11時点）

PREOモデル作成の過程

本モデルは以下のようにまとめていきました

  1. 技術広報目線でのストリーム整理のため業務を書き出す
  2. 業務内でどのような専門性が必要なのかを整理
  3. 1.2.を図示する（下図）
  4. 広報のオクトパスモデルをベースに技術広報のスキルを整理
  5. 自社の評価基準や組織の状況を鑑み、4つのスキルへ抽象化

技術広報業務のストリーム

PREOモデルそれぞれに期待される専門性とは

ここではPREOモデルそれぞれに期待される専門性を高いレベルと低いレベルで分けて説明します また説明の順番はPREOではなく、ストリーム順となっております （本来は5段階で言語化されていますが、文量の都合で割愛）

組織構築力（Organization）

▼ 高いレベル

  • 技術広報組織のビジョンを策定し、組織をリードできる
  • 事業戦略と技術広報戦略を調和させ、相乗効果を生む戦略を策定できる
  • 組織や個人のブランディングを損ねる問題を、未然に防ぐプロセスを構築できる

▼ 低いレベル

  • 技術広報組織が短期的に実施する活動を計画することができる。
  • 技術広報起因で問題が発生した際、関係各所へ相談のもと、これの解決に当たっている。

【補足】

ここでは技術広報活動を組織的に推進するため、以下3つのスキルを挙げています。

  1. 技術広報組織の構築と牽引
  2. 企業内における技術広報のモメンタムの形成
  3. 企業、組織、個人のブランドを損なうリスクの低減

広報組織力、戦略構築力、危機管理力など、いわゆる組織マネジメントの能力を要します。

戦術策定力（Planning）

▼ 高いレベル

  • 技術動向を予測し、将来性のある情報を収集できる。
  • 戦略に応じて既存の手段に捉われない方法を比較検討し、高い効果が見込める選択肢を提示できる。

▼ 低いレベル

  • 自社技術の一部について、人づての情報を収集する。
  • 関係者の助けを得て、自身の考えを発言できる。

【補足】

ここでは技術広報活動の戦略を実現する戦術をどのように立てているのかを挙げています
高いレベルでは、自発的に自社開発組織の現状を把握し、未来志向で不確実性に対して仮説・検証できるような提案ができることを想定しています
一方低いレベルでは、技術的な知見が乏しかったり、感覚的な施策策定をしており、常に有識者の助けを借りる必要があることを想定しています

情報表現力（Expressiveness）

▼ 高いレベル

  • 業界全体の技術力向上に寄与する革新的コンテンツを作成する。
  • 自社技術分野で、オピニオンリーダーとして自身か自社メンバーで情報発信する。

▼ 低いレベル - 定型的な情報発信を支援のもと実施する。 - 既存チャネル（SNS、自社ブログなど）で情報発信を行う。

【補足】 ここでは情報の発信力や言葉通り表現についてを挙げており、その情報や情報の表現に独自性、話題性、希少性などが十分に組み込まれた状態を想定しています

高いレベルにあえて「オピニオンリーダー」を明記したのは、情報を企業からの単一方向の情報発信とならないよう明示的に「人」を立てると良いと考えたためです
現代ではSNSが根付くなどの理由で、顧客との接点や情報の流通スピードが加速度的に高まるなどの背景で、従来の単一方向的な情報発信ではなく、双方向かつ多層的なコミュニケーションが求められるようになってきています
この背景から、その企業と企業が利用している技術を語ることのできるメンバーを社外へ露出させることで、その技術を象徴するメンバーとして認知を獲得するだけでなく、企業が企業として情報発信するより身近に感じてもらいつつ、計画的でも偶発的にでも双方向なコミュニケーションが期待できる のではないかと考えています
また上記オピニオンリーダーについて「自身か自社メンバー」としており、自身でなくても良い理由についても補足すると、技術広報の（外向けな）目的は「自社の技術・開発組織の適切な認知を得る」ことであることが前提とした場合、この発信元は自身でも自社メンバーでも問題ないと考えているためです

また、ここでは明言していませんが「革新的コンテンツ」の文脈では、配布物の製作やイベントの体験設計などのデザイン能力も含まれています
技術広報のサブスキル的に、自身でUI/UXデザインを担っても良いですし、上記オピニオンリーダーの考えと同様にUI/UXデザイナーと協業しても良いでしょう

関係構築力（Relationship）

▼ 高いレベルでの期待

  • 開発者コミュニティを作成・成長を促進し、共創関係を構築する。
  • 技術広報の活動内容や成果を、社内報やイントラネットなどを通じて積極的に発信し、社内全体に周知している。
  • 社内の開発者と双方向コミュニケーションの場を設定し、効果的なファシリテーションにより技術広報活動への意欲が高めることができる。

▼ 低いレベルでの期待

  • 社内外の限られた開発者との関係構築を行う。

【補足】 ここでは先述の各種専門性の発揮を円滑にするための関係構築に焦点をあてています 例えばとある技術カンファレンスにスポンサーし、登壇とブース設営をすることになった際に、全てを技術広報単独で実行すると、自社の開発組織や環境の魅力が伝え切るのは難しいです そのため、ほとんどの場合（組織のサイズや自身の専門性にもよりますが）自社の開発者に登壇依頼をしたり、ノベルティ製作やブースなどの各種体験設計をデザイナーに相談することになるかと思います その際自社の他業種のメンバーとの関係性が構築されていないと、やけに仰々しい対話になったり、ブレインストーミングなど創発性が必要な場面でも、場が硬直してしまい思った成果が出なかったり、迅速な対話ができなかったりする恐れがあります そのため、諸々の活動の質の向上及びアジリティのある価値創出の地盤として、この関係性構築は大いに寄与すると考えています

また上記では社内的な観点で例を挙げていますが、もちろん社外に向けた関係構築も各種活動を円滑にすることに寄与します 例えば特定技術の共同勉強会を共催するにあたり社外に知り合いがいると、仰々しいメールではなく、チャットや立ち話ついでなどで話を進めることもできるようになります（もちろん失礼のないよう配慮は必要です！）

実際に使ったらいい感じだった

良い点

  1. キャリアマネジメントへの転用ができている
    • 別途技術広報専任メンバーのピープル（とりわけキャリア）マネジメントをする中で、「戦術策定力だと自分はどのレベルだと思う？」とお互いの視点でレベルのすり合わせをしたり、「私は4レベルで、次の半期ではHOGEを考え・実行できると次のレベルへ上がれそうです」と単位期間内での挑戦を軸がある状態対話することで、その解像度を高めることができています
  2. チームビルディングや組織戦略への転用ができている
    • PREOモデルを元にチーム内でスキルマップを作成することで、チーム内の得手不得手が明確になり、今後の採用計画や他組織内との連携指針にもなります
    • スキルマップを元に評価への納得性や、何のレベルだと、どの業務が、どの程度移譲できるかなどにも活きそうです
      • ここについては、すでにRACI図で業務単位での責務を整理できているので、これもまた適切な期待の調整が可能となっています
      • また現状任せる範囲（期待、権限移譲の度合い）について対話だけで済ませてしまっているが、別途デリゲーションポーカーを用いて、より明確な権限の移譲度合いを示そうと思っています

課題点

  1. 定義されている専門性がまだ抽象的なため、細かな対話が必要となっている
  2. 筆者が調べ、活動した範囲での「技術広報像」を言語化しただけなので、そのキャリアの多様性を表現しきれていないかもしれない

おわりに

これから技術広報活動をするぞ！という方は、ぜひこれを参考に活動してみて、そのフィードバックをいただければと思います🙏 またすでに技術広報活動をしていて、今後何の専門性を延ばせば良いか、また技術広報というキャリアに悩んでいる方へは、この記事が何かしら助けになることを祈っています😊

「主観的な文章」で生成AIで出力された文だと思われない記事にする

結論

客観的ではなく、主観的な文章で記事を書く

例文

客観的な表現： 「スマートフォンは非常に機能的で、主に〇〇な用途で使われており、××な点が評価されています。」

主観的な表現： 「スマートフォンで評価されているのは××ですよね。私はその中でも特に△△な点が気に入っています。以前旅先で〇〇な体験をしたからです。」

この表現を入れると良さそう

以下を用いて、自身が「経験した」「感じた」ということを伝えると良いと思いました
1. 【一人称】私は、僕は、私にとって
2. 【思考】〜と思います、考えています
3. 【行動】〜をしています、していました
4. 【問いかけ】〜ですよね、〜でしょうか
5. 【感情】〜と感じました、〜が好きです

「生成AI」と記事作成の付き合い方

「生成AIで出力されたっぽい記事」は悪？

前提として、出力に際して学習したデータがどうのこうのは論じるつもりはないです
その上で、生成AIで出力されたっぽい文章は悪ではないんじゃないかなと考えています
客観的な評価や事実のみをまとめる記事では、断定的で主観が入らない文章になるのは一定仕方のないことかと思いますし、そういった文章の方が読みやすい場面もありますよね

生成AIの使い所は？

私は、「記事にしたいニュアンスはあるけど、言語化ができない or 面倒な時」に使っています
例えば、「アーキテクチャ選定って、どういう組織にしたいかって絡むよなー。具体的にはこう...ほら...あるだろう！」みたいな
そんな時に「アーキテクチャ選定って、どういう組織にしたいかって絡みます。その理由を5つ提示してください」と生成AIに投げるとか
で、その出力されたものに対して、「そうそう！それが言いたかった！」な、言いたかったニュアンスにもっとも近い単語や文章を選択していけば良いんだろうなと思います

感想

私が記事を書くモチベーションは、
1. 自分の脳内整理
2. 誰かに自身の経験・感動を伝えたい
3. 誰かに自身の経験からなる類推・定理を伝えたい
なので、生成AIっぽい文章にはならないとは思っていました
しかし改めて見てみると、文章がかためなので、もっとラフに書いたほうがいいのかなー？とも思っています
ので、本記事はできるだけラフに書いてみたつもりです

補足

下記みたいな「:（半角コロン）」も生成AIで出力したっぽいなーと感じる
なんか良さげなタイトル:タイトルの補足的な文章 とか

  • ホゲホゲ
    • ホゲホゲの要素①:「ホゲホゲの要素①」の概要説明
    • ホゲホゲの要素②:「ホゲホゲの要素②」の概要説明

とかね
こういう時は、「:」ではなく「〜」とか別の記号とか表現にするだけで回避できそう