技術広報から技術コミュニケーションへ

こちらは iRidge Advent Calendar 2017 最終日の記事になります。

![](https://qiita-image-store.s3.amazonaws.com/0/49113/cefed27d-d3cb-3bd1-2ec7-5ea8442e18dd.png)

2017年は「技術広報」という言葉がIT企業でもバズっていました。これまでは歴史の長いメーカーや研究開発組織における技術広報ばかりでしたが、今では[Google検索](https://www.google.co.jp/search)でも[多くのページが検索できるようになった](https://www.google.co.jp/search?q=%E6%8A%80%E8%A1%93%E5%BA%83%E5%A0%B1)気がします。

## 前提: 会社情報

組織によっても「技術広報」「技術コミュニケーション」の文脈は異なりますので、この記事における前提情報を書いておきます。

- [「集客、販促でネット・実店舗連携の「ＯｔｏＯ」施策支援。スマホ位置情報連携サービスを展開」(100%)](https://stocks.finance.yahoo.co.jp/stocks/profile/?code=3917.T)する企業
- [「O2Oソリューションを技術提供」「企業のスマートフォンアプリの開発を請負」の2分野](http://net.keizaikai.co.jp/archives/18825)をビジネスにする企業
- [従業員数 74人](https://www.release.tdnet.info/inbs/140120171208432850.pdf) (2017年10月末現在)
- [エンジニア 22人](https://speakerdeck.com/tnir/iridge-with-python) (2017年9月時点)
- 社外エンジニア 多数 (cf. "[iRidge with Python](https://speakerdeck.com/tnir/iridge-with-python)")
- 広報 1人 (2015年から兼任1（営業系部署兼任）、2016年6月から専任1（営業系部署所属）)

## 世界と社内の状況

ガートナーの担当者が2013年に[「2020年には、企業内のあらゆる予算がIT関連になり、全ての企業がテクノロジー企業になる」と予想](http://itpro.nikkeibp.co.jp/article/COLUMN/20131024/513514/)したように、B2Bとしてソリューション技術提供やシステム開発請負を展開する企業としては、顧客企業以上に自社がテクノロジー企業になる必要がありました。が、社外・社内コミュニケーション担当者は非技術系の担当者であることが続いていました。

社外・社内コミュニケーション担当者（広報）が専任化したタイミングで、担当者とディスカッションを重ねることができました。
多数の組織での就業経験が豊富であった中途の方が入社と同時に着任されたことはラッキーで、たくさんの示唆を得ることができましたが、その中で、技術的な要素に対する理解が少ないことが課題の一つとして挙げられていました。

## 組織的な「技術広報」の立ち上げ

多くの企業同様に会計年度ごとに組織の見直しをしているため、2018年期から「技術広報」のタスクフォースを立ち上げることになりました。

その際、名称に「広報」を入れることには賛成ではなかった（「技術コミュニケーション」としたかった）のですが、社内全員のこの活動に対する認知を最大化するため、名称を「技術広報」としました。双方向のコミュニケーションハブであることの説明をすることに時間をかけても得られるものが少ないだろうと判断したもの理由の一つでした。

また、最近のIT企業における「技術広報」のバズでは採用というコンテキストのみが強調されることが多いことにも違和感を感じていました。スコープが企業のステークホルダーと一致するように、顧客企業に対しても技術的に優位であることを伝えること、プロダクトやサービスそのもの自体への技術的還元、開発者エクスペリエンスの向上もゴールに含めることにしました。

### インプットを増やす

技術広報（・技術コミュニケーション）と聞くと、アウトプット！！！とマイクロ秒で返ってくることが多いです。

クライアントワーク中心の業務になってくると、新しい技術を取り入れようとするモチベーションが下がる、と話に聞いたことがありますが、それが現実になっていました（個人的感想です）。

インプットの習慣がある人からすると、インプットの習慣がない状況から習慣化することは簡単なことではありません。

そこで、インプットを増やす、インプットの質を高めることにしました。通常のオンラインでのブログ記事を通じた技術情報収集やオフラインのミートアップへの参加を通じたインプットを増やすことは比較的簡単に実践できました。一方で、海外のトップカンファレンスに参加するということはハードルが高かったと言わざるを得ませんでした。海外のトップカンファレンスに参加すると、最低30万円の追加費用（渡航・宿泊・カンファレンス参加費etc.）および最低5日間の人件費がかかってきます。これを投資と判断するための経営判断にはさらなる時間が必要だと判断し、今回は自社への制度導入を見送ることにしました。

ただ見送るだけでは悲しいので、自力＆有休で[KubeCon + CloudNativeCon North America 2017に参加](https://speakerdeck.com/tnir/kubecon-plus-cncon-na-2017-recap)することにしました。

これを契機に来年以降は「海外のトップカンファレンスへの参加」をルール化していきたいと思っています（個人的希望です）。

### アウトプットを増やす

アウトプットの代表としては、オンラインでのブログ記事があると思います。[エンジニアリングブログ](https://eng.iridge.jp/)を再開しました。考慮した点は[エンジニアリングブログの再始動](https://eng.iridge.jp/post/2017/engineering-blog-relaunch/)に書いていました。記事数を追わない代わりに、質を高めることを狙っています。そうしてしまうと一方では気軽にアウトプットできなくなってしまいますので、[Qiitaオーガニゼーションを併用する](https://qiita.com/organizations/iridge)ことを再周知することで、数量を維持しつつ、質を維持したブログを維持できればと思います。

#### Qiita Advent Calendar

この記事も1要素として含まれているアイリッジQiita Advent Calendarを昨年に引き続き実施しました（2度目）。

[昨年のアドベントカレンダー](https://qiita.com/advent-calendar/2016/iridge)は4人参加で6記事。

![iridge-advent-2016-summary.png](https://qiita-image-store.s3.amazonaws.com/0/49113/36dba518-ecce-3523-ed90-d0a7bcb97c42.png)

それに加え、参加した4人のうち2人は退職済みということで今年は実施が危ぶまれました。今年の12/1〜12/25の期間中に、平日は17日間ありますので、目標としては17記事（前年比+11記事）でした。が、蓋を開けてみれば、2017年は11人が参加し、

![iridge-advent-2017-summary.png](https://qiita-image-store.s3.amazonaws.com/0/49113/9aa36b6e-5fb5-87f4-afe9-64926738d2b0.png)

24記事（前年比+18記事）を達成しました。目標に対し163%の達成率でした。

![iridge-advent-calendar-2017.png](https://qiita-image-store.s3.amazonaws.com/0/49113/cefed27d-d3cb-3bd1-2ec7-5ea8442e18dd.png)

25記事目が書けるかは現時点では不明。24記事のうち、15記事は今年入社の方が投稿されたため、既存社員の投稿数も伸びてきたようです。

#### オフラインイベントへの主催・登壇

インターネットの力により、技術情報のオンライン化が進んだとは言え、IT企業集積地においてはオフラインのネットワーキング・コミュニティは現在も強い意味があると感じています。

そこで、オフラインのイベント（勉強会）の開催および登壇に力を入れました。まだ道半ばですが、強化したいセグメントを抽出し、担当をアサインすることにより、少ない技術広報担当者でも多くのイベントでのプレゼンスを高められるようにしていく必要がありました。また、コミュニティにおいてもゼロからイチを作ることはエッジ感を伝える上でも技術戦略の上でも非常に大事であり難しいので、そこを重点に置きつつも、一方で安定的な企業認知という意味では[継続的なイベント実施によるコミュニティの成熟](http://shacho.beproud.jp/entry/2017/06/20/175238)も価値があるので、バランスを取りながら実施しています。

毎月全社に対して実績（数）を共有していますが、登壇実績として、担当者の私のみならず、毎月誰か技術広報担当ではないエンジニアがリストされている月が連続していることは嬉しいことです。

### インプットからアウトプットへの連携

インプットとアウトプットの仕組みを作っただけではなかなかうまくフローが流れないことも感じていました。日々の業務の中で技術的挑戦をしていなければ、アウトプットには結びつきませんし、要素技術ばかりをインプットしてもそれをつなぎ合わせて一つのシステムとして構成するには別の技術が必要となります。そこで組織には、技術COEの存在が必要です。「COE」というまた聞き慣れない言葉が出てきました（実際これを社内に出したときに知っている人が一人もいませんでした）が、[center of excellence](https://en.wikipedia.org/wiki/Center_of_excellence)の略で、組織横断的集団や中央組織と説明されることが多いようです。COEというワードの認知度が低すぎたため、技術基盤とも言い換えられるので、社内では技術基盤という言葉を使うことにしました。
技術基盤も組織によってばらつきのある用語であるので、不安感はありますが、アクロニム（略語）ではないので、多少馴染みやすいようです。

技術基盤ファンクションを提供するため、口頭やチャットツール（Slack）などで技術的に相談しやすい雰囲気を作り、これにより、個々人がインプットしてきた要素を組み上げるという「形にする力」を高めていき、アウトプットに結びつくことを狙いました。

### 開発者エクスペリエンス (DX)

開発者エクスペリエンスとはdeveloper experience (DX)の訳語で、ユーザエクスペリエンス(UX)やカスタマーエクスペリエンス(CX)の開発者版にあたります。

この技術広報タスクフォースでは、開発者エクスペリエンスの向上も目的に含めています。技術コミュニケーションというコンテキストで、開発者エクスペリエンスを向上している組織もあるようです。

- [ドワンゴの「技術コミュニケーション室」（技コミ） #とは](http://ch.nicovideo.jp/dwango-engineer/blomaga/ar1161598)

どのようにDXを向上しているかについては別の記事に譲りたいと思います。

## 個人の活動

組織としての仕組み作りをしてきたものの、2017年、個人としてはペースダウンをした感じがありました。一方で、2016年末には想像できなかった展開も数多くありましたので、以下にリストしておきます。

- [GitLab.JP](https://gitlab-jp.connpass.com/)の運営にジョイン、GitLab Tokyoの立ち上げとGitLab Meetup Tokyoのオーガナイズ
- [Prometheus Tokyo](https://prometheus.connpass.com/)の立ち上げとMeetupのオーガナイズ
- [Kamiyacho.k8s / 神谷町Kubernetes](https://k7o-k8s.connpass.com/)の運営が休眠に :sob:
- [GitLab Core Teamのメンバー就任](https://about.gitlab.com/core-team/)
- [Cloud Native Computing Foundation (CNCF) のCloud Native Ambassador (CNA)に就任](https://www.cncf.io/people/ambassadors/)
- [Docker Meetup Tokyo](https://dockerjp.connpass.com/)の運営にジョイン/巻取り＆Meetupの再始動

なぜこのような変化があったかというと、国内・グローバルともにコミュニティの力が強くなってきた（KubeCon + CloudNativeCon North America 2017のどこかのキーノートでも同じようなことが言われていました）ことを感じていたため、（前年から続けてきた）コミュニティの活動を増やしていった、ということでした。

2018年はどういう時流になるかは分かりませんが、組織の事業戦略に合った技術との関わりをしていきたいものだと思いました。
また、この記事をきっかけにCTO/CIO/VP of Engineeringが不在の組織における技術広報・技術コミュニケーション・技術戦略について話し合えるチャンスが増えていけばと思っています。

それではよいお年を。