良質なアウトプットノウハウについて、ミクシィのエンジニアに聞いてみた。

良質なアウトプットノウハウについて、ミクシィのエンジニアに聞いてみた。

「インプット」と「アウトプット」を繰り返すことによってスキルアップや自己成長につながるのはご存じだと思います。インプットは勉強会への参加、情報収集など、比較的容易かもしれませんが、アウトプットとなると「ブログのネタがない。何を書いたらいいかわからない」「継続できない」「人前で発表するのは勇気がいる…」など中々思うようにできない方もいらっしゃるかもしれません。

そこで、積極的にtechブログ作成やカンファレンスや勉強会で登壇しているミクシィグループのエンジニアに、良質なアウトプットを継続的にできるような工夫や意識のコツヒアリング。どうすれば積極的なアウトプットにつながるのか、継続性が保てるのか、ヒントを伺ってきました。

 

目的を持ったアウトプット

「現在は年間10本ほどのカンファレンスや勉強会で登壇する機会がある」と精力的に登壇活動を行う執行役員の村瀬にヒアリングしてみると「アウトプットにどんな目的を持っているか」が大きなヒントになるとのことです。

━━━━そもそもアウトプット活動はいつぐらいからスタートしましたか。

19歳ぐらいのときからですね。始めは技術のTipsなどをブログからスタートしていました。あとは、勉強会への参加ですね。

━━━━なぜスタートしたのでしょうか。

根本には「色んな人の考えが知りたい」というのがあったからです。様々な人の様々な意見に触れて吸収し、自分の考えをまとめたい。そのためには自分が前に出て情報発信しないと情報がやってこないと思ったからですね。社内外問わずネットワーク構築も目的としてありました。

━━━━現在はイベントやカンファレンスでの登壇がアウトプットのメインだと聞きました。

昔から築いているネットワークのおかげで、様々な方面から「登壇してみませんか」とお誘いいただいています。そういえば、最近のイベント参加で意識しているのが2つあります。イベント会場の知らない人、例えば順番待ちしている前後の人と議論すること、もう一つは、アウトプットの先に何を目的としているかです。

ThinkJapan IBM Code Dayで登壇する村瀬

━━━━どういうことでしょうか。

私は議論で自分の考えをきちんと伝えることもアウトプットの一つだと思っています。そのため、初めて会った方とトレンドの技術でもノウハウでもきっかけは何でもいいので、何かについて話すようにしています。

━━━━緊張しますよね。

最初は(笑)。しかし慣れるとそうでもありませんよ。最初の話しかける勇気さえあれば、熱い議論への発展や知り合いにつながる可能性がありますから。もしかすると新しい価値が生まれるかもしれません。大勢のエンジニアが勉強会や技術イベントに参加しているわけですから、何か一つでも持って帰ったほうがいいかと思いますしね。

━━━━なるほど。”アウトプットの先に何を目的としているか”についてはいかがでしょうか。

登壇でもブログでも自分が情報を発信することで、何を目的にするかや何を得られるのかを突き詰めていくイメージです。知り合いを増やすのか、関係値を築くのか。例えば、私の登壇の場合、聞いてくれた方に何か一つでもためになる内容をもって帰ってもらいたいと思っています。そのため、参加されている傍聴者の属性やニーズに合わせて当初のテーマからアレンジするケースもあります。すると副次的ではありますが、懇親会などで「さっきの登壇内容についてですが…」と業種や業務領域が異なる方ともスムーズに会話に入ることができ、関係値の構築にもつながります。本来なら、知り合いになれなかった可能性が高いわけですから、効果的かと。

━━━━何かアウトプットについてアドバイスがあれば。

初めての人と会える場所にオンオフ問わずにいってみる。そして勇気を出して話しかけてみる。将来の自分への投資だと思ってやってみることですね。

 

気負わずに自分のペースで

新規事業開発室にて新規事業の責任者を務める大形は、「自分の思考を整理するためにアウトプットを続けている」とブログを公開しています。ブログを頓挫しないコツは“気負いしないこと”だそうです。

━━━━ブログを書き始める最初のきっかけは。

自分が陥った課題の解決方法を見つけた際に、記事として掲載することで誰かの役に立つのではないかと思い、技術ブログを始めたのがきっかけです。2003年頃ですね。当時はJavaScriptの記事をメインで書いていました。「俺、○○テクニック知ってるぜ」と自慢エントリもありますが(笑)。

━━━━ブログの面白さは。

シンプルに「はてブ」や「いいね」、コメントをもらえたりなどのリアクションが主なモチベーションでもありました。外部の方だと、積極的に意見を言ってきますから、大きな学びに繋がります。

また、稀にですが、界隈の著名人に反応をもらえる時もありますし、勉強会などのイベントにおいてブログが名刺代わりになり、外部の方とのリレーションが築ける場合もあります。

━━━━なるほど。

私の場合、思考の整理のためにブログでのアウトプットを行っていますが、あまり気負わずやることが継続できる秘訣ではないかと思っています。

━━━━どういうことでしょうか。

「良記事を出し続けなければならない」と一種の固定観念にとらわれないようにといいますか、自分のペースでやっていければと思います。

例えば、過去、業務でGoogleのFirebaseを使用する機会があったので、 Firebaseに関連するニュースを翻訳し、メルマガとして希望者に配信していたんですね。個人的には情報のキャッチアップに役立ちました。しかし、ニュースの取捨選択が思った以上に大変でしたので、10号ぐらい続けましたが止めてしまいました。

大形が作成していたメルマガ 10号で断念

━━━━挫折もあったのですね。

正直、しんどいと感じると続きませんしね(笑)。

━━━━ちなみに、その他アウトプットの工夫や取り組む上で意識していることがあれば教えてください。

当たり前ですが、迷惑をかけないように社外秘や個人名を出さないようにするなどですかね。あと、長文の記事になる場合は、書き終わった後すぐに公開するのではなく、一晩寝かすようにしています。実はサンプルコードが動作しない、説明の誤り、非公開情報など、書いた後だと気づきにくい箇所に一晩寝かすことで目がいきやすい。それによって記事の質を担保するように心がけています。

 

“諦め”が難しいほど簡単な習慣を

CRE(Customer Reliability Engineering)グループのマネジャーを務める豊川は、2017年頃から積極的にブログで情報発信をするようになったとのこと。目的は自己学習とチームの取り組みの啓発です。

━━━━2017年から積極的にブログでの情報発信に注力していると聞きました。

はい。その頃社内でCREのチームが誕生し、チームの意義や取り組みを広くに皆さんに知ってもらいたいとの想いがあったからです。“CREのエンジニア”と世間に認識されたらという想いがあります。それと私自身が、エンジニアのプレイヤーからリーダーとしてメンバーのマネジメントを担う立場となったこともブログでの発信に起因しています。

━━━━リーダーになったからと。

どうしてもコードを書く時間が減ってしまうので、これまで以上に学習する時間の確保が困難と想定されました。その時間の確保をアウトプットで実行したいと思いました。また、内容をブログに残しておけば誰かの役に立つのではという想いからです。

━━━━なるほど。豊川さんがアウトプットにおいて工夫している点は何でしょう。

Tech系の記事の場合、サンプルコードを記載するケースが多いので、実際にコードが動くか確認して誤りがないように細心の注意を払っています。公開後に実は動かないなんてことがあれば、読んでくれた方にご迷惑をおかけしますから。あとは技術ネタの選定ですね。

━━━━といいますと。

私の場合、セキュリティリスク対策系の記事についてはあまり書かないようにしています。記事内容に誤りがあると非常に迷惑をかけるというのもありますが、ビジネス要件的にどのくらいのコストをかけるかなど、様々な観点で考察が必要だと考えているからです。

豊川のtechブログ

━━━━確かに中途半端な知見で書くと、炎上も想定されます。

そうですね。そのため、記事ネタ選定はしっかり吟味する必要があると感じています。仮に炎上や記事内容の間違いなどが発生したとしても、誰にでも失敗はあるかと思いますので、お詫びや訂正内容の掲載など真摯な対応が必要だと思いますね。

━━━━他にアウトプットにおいてのコツは何かありますか。

続けることが大事だと思いますので、いかに習慣化できるかですね。あるアントレプレナーが言っていたのですが、習慣化するためには諦めるのが難しいほどタスクを小さくしてとにかく継続することが習慣化のカギと言っていました。

━━━━つまり。

歯を磨くとか、顔を洗うとか、日常の当たり前って習慣化できていますよね。例えば、「毎週ブログを書く」が難しければ、「毎週ブログを1段落書く」に。これが難しいと感じるのであれば「毎週ブログのネタを1つ考える」や「ブログの記事作成画面を開く」など、挫折が難しいほど、誰でも今すぐにスタートできるようなタスクにまで小さくしてしまえば、習慣化しやすいと思います。

 

自分にプレッシャーを。行動あるのみ

新規事業開発室に所属するフルスタックエンジニアの長岡は、勉強会への参加や登壇を積極的に行い、自分にプレッシャーをかけているそうです。

━━━━勉強会で登壇するきっかけは何だったのでしょう。

友人が主催している勉強会に誘われたことがきっかけです。会社外でエンジニアの知り合いを作りたいという想いもありましたから、ふらっと参加してみました。参加者と話していると基本的なところでつまずいている方が意外にもいたので、自分の知見が少しでも役に立つのではあればということで登壇しました。

━━━━登壇は緊張しませんか。

人前で技術に関する内容を発表すこと自体勇気がいります。しかし発表するというアクションを決めることで、発表内容で半端なことを言えない状況を作るという、あえて自分自身にプレッシャーをかけています。そのためにも誤ったことを言わないように内容を精査しますし、しっかり事前リサーチします。そのように自分を突き動かす状況を作っています。

━━━━あえて自分にプレッシャーをかけるのは、成長するため。

それが理由として一番大きいですね。あとは、アウトプットするだけで「成長への意欲がある」という外部への意思の表明にもつながりますし、様々なチャンスが広がると考えています。実際に外部の知り合いが増えましたし、様々な知見を吸収する機会が増えました。

━━━━なるほど。登壇ではどのような工夫をしているのでしょうか。

勉強会での登壇では技術に関連した新しいことではなく、体験談が多いですね。私自身が経験した失敗談などを元に、エンジニアがおちいりやすい課題の解決策がメインです。ただ資料の作り方や、発表の振る舞いなどはまだまだ改善の余地があると考えています。発表をリアルタイムに聞いていない方でも、見ただけで理解できるような資料を目指しています。

━━━━アウトプットについてアドバイスがあれば教えてください。

まずは勉強会に参加してみるということでしょうか。Web上で解決策を探すのもいいんですが、現地に足を運んでみるのもいいかと思います。登壇を見ていれば「私も発表したい」ともしかすると思えるかもしれません。一回登壇すると、それがきっかけで案外続けてみたくなるかもしれませんから。

アウトプットへの苦手意識が

2013年に新卒として入社しサーバーサイド、フロントエンド、アプリなど一通りの開発を経験し、現在AI・ロボット事業部のエンジニアマネジャー務める信田。入社してから数年間は、さほどアウトプット活動をしていなかったと話します。記事内容のミスの不安や、手間がかかる検証など、アウトプットへの苦手意識がありました。しかし2017年頃からは積極的にQiitaでの記事作成、技術共有会などでアウトプットしているそうです。

━━━━アウトプットに苦手意識があったそうですね。

そうですね。会社のブログに書くことに正直ためらいがありました。理由は、書くのが怖いというのが…。というのも記事内容に誤りがある情報を世の中にだしたくない気持ちが強かったんですね。誤りを防ぐためや、自分がたまたま使った時の事象が、一般的にそうであるのかの検証を厳密にやるのも手間がかかります。そこまで工数をかけ必要性はあるのか?と遠慮がちでした。社内用ドキュメントは書いてましたけどね。

━━━━確かに、大変ですよね。

それに加え当時SNS「mixi」を担当していまして、歴史ある大規模サービスでしたから、社内独自のライブラリを使った実装が多く外に出しづらかったのも正直ありました。個人的には大規模サービスの設計の思想や哲学などはとても勉強になりましたが。

━━━━なぜ社外へのアウトプットを意識するようになったのでしょうか。

新規事業に携わることになり、一人で全部作っていかなかければならない状況になりました。それによってオープンなツールを使用する機会が増えたことによって、外の情報から勉強することが増えましたし、逆に外に向かって書けることが圧倒的に増えました。人も増やさないといけないので、外に向かって技術的なやっていることを開示していく必要もありました。それと一人で開発しているとよく壁にぶつかるんですよね。

━━━━壁というと。

新規事業なので技術的なカバー範囲も広くすべてが壁だらけでしたね。大抵はググって壁である技術的課題を解決できるのですが、たまに情報が世の中にない場合があります。そのような課題を自力で解決した場合は「解決する情報がないけど、この課題にエンジニアがよくハマりそうだ」と思いネタ化しています。新規事業を担当して、外のオープンなツールを使用する機会が増えたことによって、書くことが圧倒的に増えましたね。

信田のtechブログ 「Qiita」を利用

━━━━得られたメリットは何でしょう。

採用活動において私やチームメンバーの書いた記事を見てチームに興味を持ってくれたという人が何人もいました。また、社外に向けての記事ではなくチーム内でもたくさんの記事を書いているのですが、それらはチームビルディングの面でうまく機能しています。というのも、チーム内で人によって情報格差が出るとすれ違いが起こりやすくなります。メンバー全員が少なくとも技術に関する情報を知っている、言わば情報の透明性が担保されている状態が理想です。特に私の事業部の場合、研究開発があり狭く深い領域にフォーカスしますし、チームが拡大すると技術領域において属人化の懸念があります。だからこそ、アウトプットで情報格差を無くし、お互いを理解するという点でアウトプットのメリットを感じます。

━━━━なるほど。他には。

やはり、どれだけ個人でアウトプットしてきたかで自分自身の市場価値も決まりますから、その辺は意識しています。あとは、「この記事が役に立ちました」とコメントなどをいただけると世の中に貢献できていると感じ、シンプルに嬉しいですね。

━━━━良質なアウトプットを実現するために心がけていることはありますか。

私も知りたいですね(笑)。良記事と言われるものを見ていけば共通のある種のテンプレートがあるのかもしれませんが。まぁ、強いていうなら、未開拓のトレンドの技術をいち早く書くなどがいいかもしれないですね。最新の技術などには世の中の反応が得やすいので、そこから道が拓けて来るかもしれません。

 

タイトルに書き溜めて、さぼり防止

認証領域において専門の知識を持つエンジニアの伊東は、アウトプットをしなければならないという意識がありつつも、ついさぼってしまいがちだそうです。如何にサボらないようにするか、答えは記事のタイトルだけ先に書いておくことでした。

━━━━伊東さんのアウトプットのきっかけは何だったのでしょうか。

サービスを構築する上で、私が担当している認証フローの設計やID連携をどうするかなどは重要な役割を担います。しかし、組織において認証領域を専任とするエンジニアの数が少ないケースがあります。会社によっては、専任を置かない場合もあります。そうなると社内で気軽に相談や議論できる仲間が少ないのも事実です。社外の方に聞いてみたら同じような課題を持っている方が多かったんですよ。

━━━━同じような課題を抱えている方がいたと。

これをどうにか打破できないかと考えた末、仲間を増やして、お互いにノウハウを共有し合えばいいのではと思い、最初はブログを、のちに勉強会を開催するようになりました。最近はQiitaに記事を書いています。私の足りない知見も社外の人と協力することで、補完できればと考えていました。

━━━━そうだったのですね。

ブログや勉強会での登壇でアウトプットを意識し続けていれば、アウトプットのためのインプットが習慣化されますし、初めてお会いする方でもある記事や登壇での発表内容を切り口にコミュニケーションのきっかけになり人脈形成につながります。基本的には新しい知見を仕入れては共有する、というスタンスですね。

伊東の「Qiita」ブログ

━━━━オープンマインドなんですね。

この領域を専門とするエンジニアの数が少ないですし、エンジニアのイベントにおいても認証をテーマにされるケースも少ないですからね。とはいえ、セキュリティの観点からもクリエイティカルな箇所ですから、標準仕様を使っている部分など公開できる部分は外部の人とも積極的に情報交換していくことは大事だと思います。

━━━━ブログ作成で工夫されている点はありますか。

実はサボり癖がありまして(苦笑)。そのため、1記事作成してから間が空くとどんどん書きづらくなりますので、記事作成のスケジュールを作っています。あとはネタを思いついたらタイトルにとにかく書き留めるようにしています。

━━━━書き留めですか。

書くつもりでいることが大事かと。間が空いたとしても後からネタの内容を思い出せますから、とにかくタイトルに書き留めています。

━━━━他に何か工夫はありますか。

一般的ではありますが、前提知識がない方向け、上級者向けなど記事ごとにターゲットを明確にしています。また、新しい技術のユースケースの記事でボリュームがありそうな場合は、複数記事に分けて読みやすさを意識していますし、作業がつらいですが出来る限りの検証は行うようにしています。

※伊東は、 2018年9月6日(木)~開催される「builderscon」でのセッションが決定しています。
パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと

 

ワンランク上の価値をだすために

「みてね」のエンジニアである清水は、「エンジニアブログでの投稿に加え、最近は技術カンファレンスでの発表機会も増えているとのことです。社内のプロフェッショナルが作成した記事に感銘を受け、自身もアウトプットを意識するようになったそうです。

━━━━まずはアウトプットのきっかけについて教えてください。

2011年8月に入社しまして、エンジニアブログの記事には、技術に関する貴重な記事が多数ありました。どれもおもしろく、私自身エンジニアとしてミクシィグループのエンジニアブログでデビューすることに一種の憧れを持っていました。

━━━━憧れがあった。

ええ。ここで記事を書くことはエンジニアとして名誉なことでしたから。そして2012年の12月に私にブログ作成の機会が訪れました。

━━━━憧れる先輩たちと同じ土俵でブログを書くことになったのですね。

先輩から何度も記事の修正依頼や内容のチェックなど厳しい洗礼を受けながらでしたけどね(笑)。

とはいえ、いきなり書いた記事で大きな反響がありまして。ブログの内容というよりも、なぜその技術を採用しているのかという視点でのコメントが多かったんですけど。これによって、世間から注目されている場所と再認識し、より技術視点での記事制作において励みになりました。「Qiita」でも書くようになりましたね。

━━━━反応があるとうれしいですよね。

そうですね。2013年頃に書いた記事が今でも読まれているみたいで、たまに「いいね」をもらいますよ。

━━━━清水さんは登壇活動もされています。

ある程度の頻度でTechブログを書いていくと、出版社から技術についての執筆依頼をいただくことが増えました。そこから技術界隈での人脈ができ、輪が広がり、「AWS Summit」や「TechLION」「Internet Week」「Think Japan IBM Code Day」など大きな技術系イベントでの登壇依頼が来るようになりました。

━━━━登壇を決定した理由は、自身のエンジニアとしての価値をあげるため。

そうですね。登壇依頼にお声掛けいただけるのは、エンジニアとして期待されている表れでもありますから。とはいえ、自分が得た技術スキルを世の中に還元することで役に立ちたい、という気持ちも強かったです。あとは業界の著名人とつながりが持てたのも大きいです。

━━━━ブログ、執筆、登壇でどのような工夫をしたのでしょうか。

一番大きいのは、何を伝えたいかを意識することですね。テクニックなのか、ノウハウなのか。私もスタートした頃は、その意識が低かったし、最初は読み手への意識が薄かったかもしれません。しかし、世のエンジニアの役に立ちたいという視点から、ブログや登壇での発表内容から何かを吸収してほしい、何か持って帰ってもらいたいという想いが強くなったので、より傍聴者に伝わるような情報の見せ方、プレゼン方法、ストーリーなどを意識するようになりました。何を伝えたいのかをはっきりさせることが良質なアウトプットにつながるのではないかと思います。

━━━━他にはありますか。

ブログや執筆では、技術検証をしっかりやることですね。私は記事を書く時間よりも検証時間をかけている事が多くあります。あとは、登壇資料やブログでもアウトラインを作ることでしょうか。完成形がイメージしやすくなるので、取り掛かりもスムーズかと思います。「ブログを書く」が苦に感じにくくなりますしね(笑)。

 

—・—・—・—・—・—・—・—・—・—

 

最後に

社内の様々なエンジニアにヒアリングしてからわかったことは、それぞれ自分に合ったスタイルでアウトプットを試行錯誤しながら実践しているようです。内容をまとめますと…

 

 目的を持つべし 何のためにやるのかを明確にすることで、効果が変わってくる
 自分のペースを持つ 続くように気合いを入れ過ぎてもNG、マイペース、マイペース
 習慣化する 継続率100%が達成できるような簡単な作業を続けることで習慣化できる
 記事や資料の制作物は一晩寝かす 完成直後は些細なミスに気付けない場合があるので、チェックは翌日に
 時にはプレッシャーも 期限や登壇決定など、時には自分を追い込む状況にして、奮い起こしてみることも必要
 タイトルを書き留めておく 記事のアウトプットで、サボリ防止、備忘録代わりにタイトルだけは作っておく
 技術検証は念入りに できる限りの技術検証を行う、面倒でもやるが鉄則

 

自分自身に合うアウトプットの最適な手法・考え方があるかと思います。これから活動をスタートしようと考えている方、積極的なアウトプットを検討している方は、上記を参考にしながら、自己成長や人脈形成などにつなげていっていただけると幸いです。

※記事内の一部リンクを削除しました(2020/4/6)

– – – – – – – – –  ※※※ - – – – – – – – –

■ pick up! ■

エンジニアを終える覚悟をしてまで、やりたいことがあった。実現した今、次の挑戦へ。
新卒1年目からモンストコラボ案件の主力に。大抜擢の理由は…?

PAGE TOP