こちらの記事は、LUUP のTVCM放映に合わせた一足早い「Luup Developers Advent Calendar 2024」の25日目の記事です。
こんにちは。株式会社Luup CTOの岡田(@7omich)です。
気付けば11月も最終週となり、1か月前倒しで始めたこの Advent Calendar も無事最後の記事を迎えました。
私がいまから頑張ってこの記事を完成させることができれば、めでたく今年もアドカレは完走となるわけです。
こういった発信活動に時間を見つけて取り組んでくれるメンバーに感謝をしつつ、このタイミングでこれまでを振り返り、私や周りのメンバーが悩んだことや決めたことを書き記しておこうと思います。
技術発信文化の醸成に悩んでいる会社さんは多いと思うので、私たちがどのような目的意識をもって、どのような仕組み（≒制度によるサポートや評価）を作っているのか参考になれば幸いです。
前提条件
私たちの会社・組織の状況は現在こんな感じです。
- 創業数年目の、toCサービス開発を行っている事業会社のスタートアップ
- 開発部門(Software Development部)の社員は10人前後
- エンジニア組織も含め全社的に事業成長目標へのコミットを重視しており、ハイペースな機能開発が求められている
- 技術広報や組織施策にかかわる専任担当者は存在しない（CTO以外にはEMも不在）
なかなか、「技術発信をがんばっていく」という目標に向かうのは大変そうに見えます。
ただ、小規模なITスタートアップ、もしくは大企業でも小さい開発部門だと似たような状況になっている会社も案外多いのではないでしょうか？
スタートアップでは、人もカネも少ない中で急速な事業成長やそれを支えるハイペースなプロダクト機能開発を求められることが常であり、技術発信のような長期的・かつ効果の見えにくい施策を優先度上げて着手するのは難しいことが多いかと思います。
（加えて、効率的な機能開発のため比較的メジャーで平易な技術スタックを採用していたり、開発組織が成熟していないため基盤が整っていなかったりなど、世の中にとって真新しい内容を発信するのが難しいと感じるケースもあると思います）
そんな状況でも、ここ3年間はなんとか Advent Calendar を通じた技術発信に取り組んできました。
これまでの取り組み
2021年12月(失敗)
正社員： 4名
- 11/25に私が「アドカレやらない！？」と言い始める
- 自部署から25本出し切るのは無理そうなので、他部署も巻き込み検討
- 結果、頑張れば不可能ではないが業務負荷が厳しそうなので断念
ということであえなく未実現に終わりました。
来年こそは、と闘志を残す。
2022年12月(成功)
正社員： 7名
- 9月末から準備、他部の方や業務委託の方にも書けそうな人には地道に声掛け
- 部内でアドカレ関連の発信担当者を立て、人集めや寄稿プロセスの整理など取りまとめを依頼
- 広報レビューで頻出の観点をまとめた原稿確認チェックリストを作ってもらい、
セルフチェック＋上長チェックのみでリリース（広報に大感謝！） - CIでtextlintが走るようにして、簡単な日本語表現の修正を自動化
前年度の失敗を踏まえて、多くの改善をしたうえで臨みました。
ただし、これでも直前の執筆依頼が飛んでしまったり、リリース予定日に間に合わなかったものがいくつかあったり、課題や負荷感は大きかったです。
2023年12月(成功)
正社員： 10名
- Publication に移行し、希望者は記事の発信元を個人アカウントにもできるように
- 10月から準備、11月から執筆声掛け開始で問題なく全埋まり
2年目はメンバーも増えてよりスムーズに完走できるようになりましたが、ほぼ全記事を上長の私が公開前にレビューしていたため、公開までのプロセスが重くなっていたことなどが課題でした。
2024年11月(成功)
正社員： 17名
- 11月からTVCMの全国放送もあるため、前倒しでやれたら面白いのではないかと10/16に発案
- 日程表を作成しオープンに記入依頼を出したところ、数日でほぼ全埋まり
- アドカレ発信担当者を2人立て、各所連携を一任
- レビューフローをセルフチェック＋各チームリーダー(1人)チェックに変更
- CIでプレビュー画像が自動生成されるようにして、PR上での確認を簡単に
3年目は、通常12月に実施している Advent Calendar を1か月前倒しで11月にやるというチャレンジをしました。
開始2週間前というかなりハードな思いつきであったにも関わらず、レビュープロセスの改善もあり今までで一番スムーズで安定した記事リリースができました。1,2年前は苦労していたアドカレの完走に余裕さえ出てきており、発信文化が徐々に定着しつつあることを感じています。
技術ブログでの発信以外にも、様々な勉強会の共催や、各種技術カンファレンスへのスポンサー活動なども現在は精力的に行っています。
こういった活動が、慌ただしくあり続けている本業のプロダクト開発と並行して行えるようになるまで、私が考えたことや部内で話し合ったことについて整理してみようと思います。
発信によるメリット
まず、わざわざインプット・執筆・レビューなどなど多くの時間を使って、直接会社の事業が進捗するわけではない技術発信を積極的に行う理由はなんでしょうか。
漫然と「発信は大事」と言っていても、その理由を（過去の経験などから）肌で理解している人以外は自然にやってくれることなどそうそうありません。
誰にとってどんなメリットがありそうか、その中でもどのメリットを享受するためにやっているのかのスタンスを明確にする必要があります。
会社にとって
会社から（上長から）技術発信を推奨するからには何らかの目的があるわけで、その目的を組織内ではっきりさせることは組織長の義務だと思います。
次項で触れる書き手個人のメリットも大事な要素だとは思いますが、「あなたたちのためにもなるんだから、頑張ってよ」といきなり言われても多くの人は納得しづらいでしょう。
弊社では現在、技術発信の目的を以下のように定めています。
-
採用のため: 技術面での企業認知度向上
LUUP というサービスやそれにまつわる技術領域、Luup のエンジニアが持つ専門知識や技術的な挑戦を発信することで、認知度の拡大や採用市場でのポジション形成に繋げる -
採用のため: パブリックな情報源の提供
Luup に興味を持ってくれた採用候補者とのやりとり、メッセージやカジュアル面談時の会話などで引用できるパブリックな情報源として活用できるものをたくさん置いておく -
ドキュメンテーションとしての活用
ブログ記事や発表資料をわかりやすい形で残しておくことにより、社内向けのドキュメントやTipsとして活用できるようにもなる
やはり、採用に繋がることを何より重視しています。
技術発信活動が長期的に採用に繋がればさらに事業成長を後押しすることになりますし、その資料が結果的に社内でも活用できるのであれば開発を加速させる一因にもなります。
私たちは『街じゅうを「駅前化」するインフラをつくる』というミッションを掲げて事業づくりをしていますが、技術発信はそのミッションに長期的に近づくための（機能開発、不具合改修、コスト削減などと同じような）打ち手だと考えて取り組んでいます。
「技術発信そのものを尊い文化として前面に押し出す」ことも素晴らしいですし、それができるキャパシティのある会社はすごいと思うのですが、私たちは前述したような企業フェーズの背景から、あえて強い目的意識を持ってやる選択をしました。
書き手個人にとって
上記に述べたような会社としてのメリットを成り立たせるために、仕事の一環として技術発信に協力してほしい。というのがベースの考え方であり、曖昧にしてはいけない部分です。
とはいえ、それだけでは書く側にとって少し味気ないですし、言われてやるだけでは楽しくないと思います。
技術発信関連の社内議論では、個人としてもこんなメリットがあるよねという整理をしました。
-
知識の定着
アウトプットする過程でファクトの精査や因果関係の整理を行うことで、自身の知識が体系化・深化され定着に繋がる -
個人のプレゼンス向上
発信内容や頻度によって技術界隈での個人の認知が上がり、今後の自身のキャリアにとっても大きなプラスとなる
もちろん、アウトプットを頑張っている自社の社員がそれによって他社に目をかけられたり、本人のプレゼンスが上がってサクサク転職していってしまったりしたら少し悲しいですが、長期的に「元々弊社にいたメンバーが今は各所で活躍している」という状況ができていけば会社や組織長としても冥利に尽きるものでしょう。
世の中にとって
それ以外に、自社の経済活動に関わらない面でも以下のようなメリットがあります。
-
Web上の集合知への還元
ソフトウェアエンジニアであれば誰しも、Web上でエラーの解決方法を検索したり、技術トレンドを収集したりといった経験があるかと思います。自分がハマったり工夫したりした経験を記すことで、自分以外の第三者にとってもいつか有益になるはず -
技術コミュニティーや業界の盛り上げ
特定の技術領域や特定の業界において発信記事が多く世の中に出るようになることで、界隈の盛り上がりやそれによって興味を持つ人の増加にも繋がる
そもそも根本的に、現代のアプリケーション開発はそのほとんどを他者によって作られたプログラムに依存しています。採用しているフレームワークやライブラリ、OSやコンパイラに至るまで、無償にせよ有償にせよ、全て技術コミュニティーの中で育てられた先人の集合知の上で動いているわけです。
その集合知の上に私たちが新しく作り出したものをわずかながらでも積み上げていくことは、技術者として生きていく上では当然の振る舞いではないかとも思います。
加えて、私たちの事業は「車両との通信が関わるIoT領域のプロダクトである」「モビリティ（マイクロモビリティ）という人々の生活に深く根ざした業界である」という少し特殊な属性をもっているので、この業界やコミュニティーにおける発信が盛り上がることは大きなプラスになると思って取り組んでいます。
どのように評価されるべきか
次に、会社として目的意識をもって臨むからには、技術発信の取り組みに貢献してくれた人がきちんと評価される状態も作らないといけません。
組織文化への投資や個人としてのカルチャー貢献をうまく制度の中で取り扱えている会社なら問題なさそうですが、直接的な事業成長へ全社で取り組んでいるようなフェーズの会社であれば、その効果を評価するのに悩むこともあるかと思います。
あくまで一例ですが、Luup では技術発信にまつわる成果を 「技術発信 = 長期的な採用貢献 = さらに長期での事業貢献」 と解釈し、超長期で捉えた時の事業成長につながる施策として評価するようにしています。
事業成長のための機能開発はやるけど発信も大事、技術ブランディングも大事、みたいな別枠に目標を置くのではなく、部として一番メインの事業貢献目標の1-1.の中に含めてしまっている状態です。
別枠で追っていた時期もありましたが、あまりに時間軸が違うため他の目標とのバランスや優先度を考えづらかったり、結果的にどうしてもサブプロジェクトっぽくなってしまったりと良い結果にあまりならなかったので今はやめました。
機能追加とリファクタリングが常に両輪で取り組んでいかなければならないのと同様に、プロダクト開発と技術発信も同じ事業貢献の目線で常に並行して着手していくものだと考えています。あるのはただ時間軸の違いです。
また、超長期施策だと捉えているからこそ、発信活動はそのプロセス自体が評価されるべきものであり、「採用に繋がったかどうか」「どれくらい拡散されたかどうか(?)」などの結果指標を目標に据えることは基本的にしないスタンスを取っています。
超えるべき壁
さて、そんな真面目な目的意識と確からしい評価制度を準備したとて、実際に部やチームのメンバーに発信活動を行ってもらうにはたくさんのハードルが存在します。
忙しすぎるとかネタが無さすぎるとかはさておき、中には心理的ハードルによるものもあります。
強制されるの辛い…問題
発信の得意なメンバーが少なく、ゆるく目標にしているとなかなか発信活動が進まない、かといって指名して強制で書かせるのはモチベーション的にもやりたくない、という状態です。
ここはマネージャーの腕の見せ所で、上述した目的意識について定期的に話題に出したり議論することで共通理解をつくったり、社内で面白い取り組みや大変だったプロジェクトがあれば「この内容記事にしてみるのどう？」と提案したりすると良いと思います。
もし社内に発信が得意だったり前職での経験があるメンバーがいれば、その人に時間を作ってもらい、先頭に立って記事執筆や登壇をしてもらうことで、周囲の人も真似しやすい環境を作ってハードルを下げていきましょう。
ちなみに、弊社のメンバーからは過去この話題を出した時に「むしろ仕事として強制された方が頑張ってやろうという気持ちになります」と言われ、その発想は無かったので少しハッとしたことがあります。事業貢献意識が高くてすごい。
組織によってはもしかすると多少の強制力がある方が逆にうまく進む時もあるかもしれません。くれぐれもモチベーションには気をつけて。
立派な内容書けない…問題
これも人によっては高いハードルになっているかもしれません。
近しい領域での他の人の発信を見て、「わざわざこんな簡単な内容で良いのだろうか…」と悩んでしまうパターンです。
発信のメリットについての節を読んだ方なら理解いただけると思いますが、発信活動の重要性はその内容の良し悪しだけに収まりません。どんなに短い記事でもWeb上に公開されることで企業の認知度向上や技術コミュニティーの盛り上がりに繋がりますし、どんなに簡単な内容でも誰か困った人を助けるかもしれません。
私が書いているこの記事も、偉大な経営者やCTOの先輩方からすれば当たり前の内容だと思いますが、今困っている駆け出しのスタートアップのマネージャーの役に立つかもしれません。
2セクションくらいの簡易な記事をいっぱいリリースすることもすごく大事です。レビュワーが大変なのでこんな長い記事ばかり書いていてはいけません。
（と、実際に Reviewer から突っ込まれました。気をつけましょうｗ）
おわりに
人も少なくまだまだ大変な状況のスタートアップだけど技術発信をあきらめず頑張っているよ、ということを色々考えた過程と共に話してみました。
この記事が今、あるいは今後どこかで悩んでいる誰かの救いになれば嬉しいです。
＊
そんな Luup では、発信文化も事業成長も同じ目線で大事にしながら、未来のモビリティインフラを一緒に創っていけるソフトウェアエンジニアを積極的に募集しています。
私自身や、各開発チームのリーダーともカジュアル面談で直接話せる応募フォームも掲載しておりますので、ぜひお気軽にお声掛けください。
Discussion