アウトプットの始まり
日本最大級のエンジニアコミュニティQiita プロダクトマネージャーの木尾の俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続き、ゲストは、Amazon Bedrock 生成AIアプリ開発入門の筆頭著者で、
KDDIアジャイル開発センター株式会社 テックエバンジェリストの御田稔さんです。
よろしくお願いします。
よろしくお願いします。
御田稔です。
御田稔さんとお送りする3回目のテーマは、アウトプットを続けるコツです。
今回はアウトプットについて、いろいろお伺いしていきたいなと思っています。
エンジニアの価値は、世界が決める。
転職ドラフトは、年収アップ率94%、平均年収アップ額148万円と、圧倒的な実績を誇るITエンジニア限定の転職サービスです。
今までのエンジニア経験を登録することで、厳選された企業から年収提示付きのスカウトが届き、リアルな市場価値が測れます。
気になる方は、転職ドラフトで検索してお気軽にご参加ください。
最初にお伺いしたいのが、御田さん、昔からパソコンをあさわっているというお話だったと思うんですけど、いつからアウトプット自体は外部へのアウトプットを始めているかをお伺いしてみたいです。
そうですね。かなり古いところで言いますと、私、小学生の終わり頃から中学生頃にかけて、自分でブログを立ち上げて記事を出したりしてたんですけれども、その時はテーマが魚釣りではあったんですが、発信という意味ではそのくらいの時にやった経験がありました。
ITとかエンジニアという文脈に関しては、私がKBDIに入ってしばらくAWS関連の業務をやった後に、2021年の暮れ頃、11月頃に初めてアウトプットを社外向けに行ったんですね。
その時はブログじゃなくて登壇が初めてだったんですけれども、その時、AWS界隈でかなり有名な山口さんというAWSコミュニティヒーローに認定されている方がいらっしゃるんですけれども、その方が運よくKBDIに中途入社で入ってきた時期がありました。
その山口さんという方が、今度社外のコミュニティでJawsUGというコミュニティで、こんな勉強会があるんですけれども、興味ある方いたら登壇してみませんかというようなお知らせを社内のコミュニティでTeamsのグループで発信してくれていたんですね。
コミュニティの影響
その時は私、KBDIでSREという名前がついたチームにいて、インフラとか運用関連のAWSに関する業務をしてたんですけれども、そのSREに関するテーマの登壇を募集しているということで、ちょっとしゃべってみようかなということで、そこに応募してみたのが私の最初のアウトプットでした。
そうなんですね。じゃあ、記事を書く前よりも登壇を先にされてらっしゃるってことですね。
そうなんです。
しかもそれが2021年。
はい。
3年前ぐらいってことですね。
そうですね。
結構直近ですね。
そうですね。
あ、そうだったんですね。もともと小さい頃からブログみたいなところで発信されてたと思うんですけど、そこから2021年まで他のアウトプットみたいなところは特にしてらっしゃらなかったってことなんですか?
そうなんですよね。どちらかというと私がエンタープライズな環境で、B2Bのシステム構築みたいなところに携わることが多かったので、周囲の方も含めてそもそも業務で学んだ技術試験を発信するみたいな発想があまりなかったですというのが正直なところで、
でも何か業務上困った時に検索をするとキータの記事が見つかったりみたいなことは結構あったんですけれども、ただあんまりそれを自分がやるみたいなことって特にイメージしていませんでした。
ただJawsUGみたいな技術コミュニティに参加をし始めると周りのみんなが当たり前のように日々登壇をしたりブログを書いたりっていうアウトプットの活動をしていたので、一回登壇を始めてからはブログの発信もチャレンジするようになりまして、キータの記事を多分私が初めて書いたのもちょうどその頃2021年の11月ぐらいかなと思います。
そうなんですね。じゃあもうそもそも最初の頃は発信するっていうこと自体の発想があんまりなくて、そこからコミュニティへ参加するようになって、自分も発信してみようかなってところで発信を始めたってことですね。
そうですね。
さらにどちらかというとマネジメント系の仕事が多かったですので、自分が日々ガリガリ手を動かしてシステムを構築したり開発してるわけではないので、自分には全然発信をするような技術力がないっていう先入観がすごくあったんですよね。
そういうのもあってあまりアウトプットしてこなかったと思います。
そうだったんですね。初めてアウトプットされたのが登壇だったと思うんですけど、その時はどういうモチベーションで登壇をされたんですか。本当に機会があったからだけなのか、やっぱりしてみようかなみたいな気持ちが強かったのか。
そうですね。人前で話をするっていうこと自体はもともと嫌いではありませんでしたので、自分のやってる仕事と直接関係ありそうなテーマで事例の話を求めているっていうことだったので、ちょっと自社の取り組みを社外に発信する機会にもなりますし、ぜひチャレンジしてみたいなということで申し込みましたね。
そうなんですね。そのタイミングだと他にアウトプットもされてなかったと思うので、自分の発信できる情報ってどう見られるか全然わからない状態じゃないですか。そこって怖くなかったですか。
そうですね。その時に私がやっていた業務がSREという当時流行り始めていたキーワードで、SREってサイトリライアビリティエンジニアリングの略なんですけれども、すごく雑に言うとITシステムの運用をうまく自動化してシステムの信頼性を上げていこうぜみたいな。
もうそれだけで何日も語れるようなキーワードに基づいた仕事だったんですけれども、そのSREというキーワードで仕事をしていると、社内でも自分たちは何のために活動をしているのかですとか、実際に社内で自分たちはこんなことをしているよっていう形で周知をしたりとか、結構自分たちの中だけじゃなくて社内でも外を意識した活動をすることが増えてきまして、
そういうところもあったので、社外に自分たちの活動を発信できる機会ということでポジティブに捉えていたかなと思いますね。
じゃあどちらかというと本当にポジティブにやっていこうって気持ちの方が強かったってことですね。
はい。
なるほど。実際登壇してみた時ってどういうフィードバックとかがありましたか?
そうですね。当時最初に登壇をしたコミュニティがJawsUGという日本のAWSの一番大きなコミュニティの中でも、いろいろ分野とか開催地域ごとに支部があるんですけれども、SRE支部というところでして、
今私はSRE支部の運営メンバーに入っているんですけれども、当時からSRE支部のちょうど立ち上げ後初回の第1回イベントでして、実際に私がライトニングトークを15分ほどだったんですが、
やった後にその場でもらえたフィードバックもすごく温かいフィードバックでですね、あるあるが詰まっててすごく共感できましたですとか、あとちょっと話の中にくすっと笑えるようなネタ要素も入れてみたりしたんですが、それがものすごく面白かったみたいなフィードバックだったり、
すごいコミュニティメンバーのいい人たちから温かいフィードバックをもらえたので、すごくそれがやる気につながりましたね。
そうなんですね。じゃあそこから本当にそこでフィードバックをもらえたからこそ、次の発信みたいなところへもつながっていったっていう感じですかね。
執筆とモチベーション
そうですね。
実際そこで登壇されてから執筆の方も始めてらっしゃると思うんですけど、登壇をするっていう形でのアウトプットと記事を書くっていうことのアウトプットの仕方って、出し方も違うのでもちろんプロセスとか気にしないといけないところとかは違かったりすると思うんですけど、
最初のその記事のアウトプットって終わり返しすんなりできましたか。
そうですね。ブログを最初に書いた時の記憶はですね、割と自分がエンジニアとして日々業務をする中で困った時に誰かの聞いたなんかのブログ記事がたまたまウェブで引っかかるようなことは結構ありましたので、
なんとなくどういう記事があるかっていうののイメージはついてましたので、私が最初に書いた記事はAWSに関する書籍を読んでハンズオンをやってみた時に、自分のメモも兼ねて実際にやってみたらこんな形でできましたみたいなのを記事にしたものだったと思うんですけれども、
そういうふうに割とテーマが決まっていたので意外とすんなり書けたというか、その時にちょっと驚いたのが結構ブログ記事を書くのって、それこそもう中学生の頃にブログを書いてたような時の記憶からすると、
なんかHTMLをめちゃくちゃ頑張って編集して文字に色付けたりとか大変だった記憶があるんですが、聞いたってすごくブログが書きやすくてですね、なんかもうマークダウンで簡単にマークアップできたりですとか、画像ドラッグアンドドロップですぐ貼れたりとかするので、なんか見栄えがめっちゃいい割には書く労力そんなにかからないなっていうのは一番最初に書いた時に思いましたね。
そうなんですね。そこで書くところの難易度みたいなのはあんまり感じずに、すんなりアウトプットの方も入れたってことですね。
そうですね。
そうなんですね。初めての記事の方のフィードバックはどうでした?なんか反応とか反響みたいな。
そうですね。書いた記事に対して例えばコメントがつくようなことって意外となくてですね、どっちかというとちょっとしたいいねとかストックがつきましたよみたいなリアクションだったりですとか、あとはそれを聞いた上で直接コメントとしてフィードバックをもらうというよりかは、SNS等で誰かがたまたま目にしてくれてツイッター上でコメントをくれるですとか、そういったことがあったりしたんですが、
最初のうちはそこまでビュー数も伸びてませんでしたので、いくつかいいねがつくだけでしたが、それでもちゃんと見てくれる人がいて、しかも好意的なフィードバックをもらえたってことで、やっぱりすごくモチベーションが上がりましたね。
そうなんですね。結構やっぱりそこのアウトプットのモチベーションってどう考えるかっていろいろあると思うんですけど、やっぱりそこの結構あんまり反応もらえないみたいのでやめちゃう人って多いかなと思っていて、そこらへんってミノルンさんとしてどんぐらい気にしているかとか、どんぐらい大事にしているかというとどんな感じですか?
アウトプットのモチベーション
そうですね。そこすごく大事なポイントだと思ってまして、個人的にはアウトプットに対するフィードバックありきでモチベーションを考えてしまうのではなくて、どちらかというとアウトプットをして人に何かを分かりやすく伝えるですとか、そっちの方に主なモチベーションを感じられないとアウトプットを継続的にやるのがもしかしたらハードルになるんじゃないかなと思ってまして、
というのも記事を書き始めて最初の頃ってまだ読者の方も少なかったりですとか、その記事を読んでくれる人も少なくて、結果的にリアクションがあまりつかないケースもたくさんあると思うんですよね。
なので、めっちゃ頑張って超対策を1本目記事書いたけど誰も反応をくれないということでがっかりしてたら、全然アウトプットって続かないと思うんですよ。
そうじゃなくて、まず自分の知識を文章とかスライドとか何かしらの形にして発信するそのプロセス自体が面白いものだと思いますし、そこにモチベーションを感じて続けていたらいつの間にかフォローしてくれる人が増えていて、
結果的にリアクションもたくさんつくようになったみたいな、そういう副次的なモチベーションとしてフィードバックを捉えられるとうまくアウトプットが続くんじゃないかなって思いますね。
教える楽しさとアウトプット
ありがとうございます。結構そういう同じような話をされている方って今までのゲストの方も多いなと思っていて、フィードバックではなくてアウトプット発信するっていうのをやり続ける。
その後にフィードバックとかないよりかはあったほうが嬉しいけど、それをある前提でやらないっていうのがやっぱり大事だよねみたいなのは結構今までの方もおっしゃってた気がするので、今回もなるほどなってお話聞いてて感じました。
今のお話に続けてちょっとお伺いしたいなと思ったところが、本当にアウトプットを楽しむって大事だなと思う一方、アウトプットを楽しむって何って思ってらっしゃる方もいらっしゃる気がしてて、何かを世に出すことのどこに面白さを見出すといいかみたいなところとか、
あとこういう感じで考えたりとかこういうものを発信していくと面白いよみたいなのがあればぜひアドバイスいただきたいんですけど。
そうですね、イメージとしては技術に限らず何か人にものを教えるみたいなことが楽しいかどうかっていうのがポイントの一つだと思ってまして、
例えば私学生時代にアルバイトで塾講師をしてたりするんですが、その時は相手がお受験をする小学生で国語を教えてたんですけれども、
入試問題で出てくる難しい現代文をいかに小学生でも分かりやすくこういう文章の流れになってるんだよっていうところを整理して教えて、
分かったって言って嬉しそうにする小学生を見てるとものすごくやりがいがあるというか、そういう人にものを教える感覚とアウトプットってすごく近いところがあると思ってまして、
そういう教えるっていう側面だったりですとか、あとは普段の業務の中でも日々仕事をする中でいろんなナレッジの断片が頭の中に溜まっていった時に、
ちょっとだいぶ分かってきたから一回自分の中で整理して書き出したいなみたいに思う時があるんじゃないかなと思うんですけれども、まさにそれもアウトプットの役割の一つなんですよね。
自分の中に培ってきたナレッジを形にして、さらにそれを他の人も見れるような形で世に出すことによっていろんな人がそれを見て学ぶことができますし、
その出力する過程で自分の学びもすごく整理されますと。さらにブログみたいなアウトプットのいいところって一回書いちゃえば基本的にずっと世の中に残すことができますので、
一度の労力でずっと継続的にそのアウトプットが勝手に発信をし続けてくれるんですよね。そういう意味でもブログを世に出すっていうところの楽しさとか価値ってそのあたりにあるんじゃないかなと思いますね。
ありがとうございます。本当に自分の中でもやもやあるものが言語化できるっていう気持ち良さと、その言語化したものが他の人にも役立つっていういわゆる貢献感というか自己効力感みたいなところと、
それがちゃんと自分の支査になって残り続けるっていうことの達成感というか、ちゃんと自分に積み上がってる感みたいなものを楽しんだりとか喜んだりするといいっていう感じですかね。
まさにその通りだと思いますね。
ありがとうございます。本当にこうやっぱりアウトプットをすると、むしろインプットがはかどるみたいなことってすごいあるなと思っていて、
なんか曖昧なものを書き出すと、ここまだちゃんとわかってないなってなって色々調べて、わかったからそれをまたすぐその文章に続きを書いてみたいなことって結構書き始めるとよくやることな気がするので、
やっぱりアウトプットをすると自分自身も何かしらインプットになるというか新しい学びの機会になるみたいなのがすごいあるかなと思うので、
力んで一個いいものを作ろうってよりもやっぱり普通にライフワークとしてアウトプットをメモをちゃんと取ったりとかそれを形にするみたいなのを日々息を吸うようにやるっていう方が結構気持ちよかったり楽しかったりするのかもしれないですね。
そうですね。これを言うと身も蓋もないんですが、実際に自分が書いた記事を隅々まで読んでくれる人って実はものすごく一部だと思ってまして、
なのですごく細部まで気をつけて何時間もかけて記事を書くよりもとりあえず一定の完成度で世に出しちゃう方が価値が高いと思いますし続けやすいと思うんですよね。
まさにそうですね。意気込んでやるってよりも本当に息を吸うように書きながらむしろ自分のために書いていくぐらいのノリでやるのがいいかもしれないなっていうふうに思いました。
組織におけるアウトプットの重要性
そうですね。ここまでで結構個人のアウトプットっていうところについては色々お伺いしてきたかと思うんですが、もう一個お伺いしたいなと思っていて、
そこがまさにエヴァンジェリスト的なお仕事をされているミノルンさんにだからこそ聞きたいってところでもあるんですけど、個人はそうやって楽しめばいいよねって思えば自分でやる人はやるしやらない人はやらないと思うんですけど、
組織でのアウトプットってなるとまたちょっと変わるところもあるんじゃないかなと思っていて、組織としてアウトプットしていきたいみたいなふうになった時にどういうアクションを取っていくべきかみたいなところもぜひミノルンさんにお伺いできたらなと思ってます。
そうですね。まず組織でアウトプットをする時に、例えば分かりやすく技術ブログを書こうみたいなことをイメージしますと、よくやりがちなのが自社のブランドを掲げて技術情報を発信するんだからちゃんとレビュー体制をしこうですとか、
そういったことが発生するケースってすごい多いと思うんですけれども、個人的には何か技術的な発信活動を組織としてするにあたっては一番大事なことがまずハードルを下げることかなと思ってまして、
例えばエンジニアの方が普段の業務もある中でプラスアルファとして社外に向けて何か発信をするようなことに労力を注ぐわけなので、普通にやってるとすごく大変ですし、なかなか続かなかったり書き手が現れなかったりしますと、
上からそれをやれって言って強制的にやらせてしまうとやっぱりモチベーションが湧きづらいですし、発信自体があんまり良くないものになってしまいますと、そうじゃなくてエンジニアが自ら発信してみようかなとポジティブに自主的に発信できるような文化を作るためには、
まずなるべく障壁を減らしてレビューをするにしても本当最低限のチェックだけですぐ記事を出せるみたいなそういう形にするのが大事かなって思いますね。
ありがとうございます。まず本当に最初走り出すところの一歩目でつまずかせないというか、そこでのモチベーションをできるだけ下げない状態の環境作りをするとかですね。
そうですね。
そこでこうなんて言うんですかね。自発的にやってくれる方はやってくれるんじゃないかなと思うんですけど、なんかこうやっぱりいろいろ理由つけてやらない方とかもいらっしゃるじゃないですか。
なんかこうまさかりが怖いとか例えばどういう内容を書けばいいのかわからないとか自分が知ってる知識ってみんなも知ってると思うみたいなことって結構あるあるな気がするんですけどアウトプットを踏み出せない。
なんかそういうところのご支援とかってどういうふうにやってらっしゃったりしますか。
そうですね。特に最初の方で大事なのが有望そうな人はそっと背中を押してあげるっていう最初のアクションが結構大事でして、
例えばこの人いろんなこと知ってるし文章書くのも得意そうだから背中を押せばやってくれそうだなっていう人に対しては個別に声をかけてみて、
ちょっと何々さんこういう分野得意だよねじゃあちょっとこういうブログ書いてみたらどうですかぐらいの軽い背中を押すっていうことはやってあげると割とそれだけで一人でに発信をしてくれる人っていうのは一定数いますと。
それだけじゃなくてじゃあなかなかそうやって背中を押してもどうやって書いたらいいかわからないみたいな人に対しては、
私自身が聞いたエンジニアフェスタの時に社内でアウトプット推進するためにやってたこととしては、じゃあネタがない人に向けてはネタを提供してあげましょうということで、
私自身は聞いたで時間があれば書いてみたいブログのネタみたいなのが死ぬほどあったりするんですけれども、
それをネタ帳として惜しみなく社内で公開してですね何かこの中で記事書けそうなことがある人いたら勝手に奪って記事書いていいよっていうふうに公開したりしましたと。
あとはテーマはあるんですけれども実際に筆が進まないみたいなケースもあると思うんですけど、
そういう方に向けては社内で何度か勉強会というかレクチャー会みたいなものをやりまして、記事を書く時に書き出しから上から順に書いてしまうとなかなか筆が進まないので、
何が言いたいのか一番もう中核の部分だけを雑に過剰書きで書いてから最後に表現を整えるといいですよみたいなそういった小手先のテクニックを含めて、
実際にもう実践してる人が社内で共有してあげる場を作るですとかそういったことをして少しずつアウトプットを増やしていったみたいなことをしましたね。
なるほどありがとうございます。今お話聞いててさすがにそれだけやってもらえたらみんなアウトプットするなって思いました。
もしかしたら大事なのってもちろんその瞬間瞬間でのサポートっていうのもそうだと思うんですけど、やっぱりサポートをしてくれるぐらいやっぱりアウトプットっていうものを組織全体で啓蒙されている感というか、
やっぱりこうみんなでやっていこうよってみんなが思っている感がやっぱりその人を動かすんじゃないかなっていうお話聞いてすごい感じました。
そうですね、逆に私の組織のケースで運が良かったことは、マネージャー陣とか社長とか会社の経営層を含めてアウトプットとかコミュニティに関する理解がそもそもあったみたいなところがすごく大きいかなと思っていて、
アウトプットの重要性
その上ですごく優秀な社員とかエンジニアが多かったっていうところもスムーズにアウトプットをみんなやり始められた理由だと思うんですよね。
逆にそうじゃない環境に関しては結構みんな苦しいものがアウトプットを現場の社員が進めたいという思いがあるけれどもなかなか上に理解してもらえないですとかそういったこと多いと思うんですよ。
そういう時の取っ掛かりとしてよくコミュニティの文脈で聞く話としては、もう何でもかんでも承認を求めてこういう活動をしていいですかって言ってやるんじゃなくて、なんというか草の根活動的に勝手に始めて後から結果がついてきて承認されるような形にしてしまえばいいよねみたいな考え方もよく言われたりするんですけれども、
承認を取るな謝罪せよっていうふうに言われたりするんですけれども、何か勝手にやって怒られたらごめんなさいって言って潔く引っ込めるというか、そういったスタンスで何から何までこれをやっていいですかって上の人の意見を求めてしまうのではなくて、直感的にきっとこれがいい活動だって現場のメンバーは分かってるんだから、
まずそれをうまく調整しながら実際にやってみて、ある程度結果が出てきたところで外からの声も含めて理解を得ようとすれば割とすんなり組織にアウトプット活動が受け入れられるんじゃないですかみたいな、そういったところがありますね。
ありがとうございます。本当にこうなんかやっぱりシステマチックにやっていくっていうよりも気持ちの方が大事というか、先に気持ちがあってそこに対して仕組みとかそういう承認とかルールっていうのが乗ってくると思うので、まずやっぱりみんなでやっていこうよって気持ちをみんなで調整していくのがやっぱり大事っていう感じですかね。
そうですね。それでいて大事なのが、やっぱり節度を守るっていうところは大事で、勝手にやると表現しましたが、社内ルールで厳密に決まってないようなところを攻めるやり方ではありますので、社内規定で厳密に禁止されていることは絶対にしないですとか、これをやったら会社の不利益につながりかねないなみたいなところは絶対にやらないとか、
そういった良識がある上での一種攻めの活動みたいなところをうまくやるっていうところが大事かなと思いますね。
本の紹介と感謝
ありがとうございます。
以上の3回にわたりありがとうございました。最後に何か告知などありましたらよろしくお願いします。
はい。私がコミュニティメンバーと一緒に執筆した書籍であるAmazonベッドロック生成アイアプリ開発入門AWS深掘りガイドという本が今年の6月に出ていますので、ちょっと生成アイ流行ってるしこれからやってみたいなみたいな方はAWSで実際に触りながら入門できる本となっていますので、ご興味がありましたらぜひお手に取ってみてください。
ありがとうございます。ということで、みのるんさん本当にありがとうございました。またお話しできる機会があったらなと思います。またお待ちしております。
ありがとうございます。
今回はアウトプットについていろいろお伺いをしてきました。本当にやっぱり他の今までのゲストの方もおっしゃってましたけど、やっぱりアウトプット自体を楽しむっていうのは本当にすごい大事なことだなって思いました。
個人もそうですし、組織としてやっていくという中でも、やっぱりアウトプット自体を楽しむっていうのが結構キーになっていくんだろうなというふうに感じています。
さて、この番組では感想や次回ゲストへの質問、リクエストなどお待ちしております。番組詳細欄にあるリンクより気軽にご投稿ください。
Xではハッシュタグ聞いたFMをつけてポストしてください。表記は番組名と一緒でQFMが大文字、残りは小文字です。
そしてApple PodcastやSpotifyのPodcastでレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、エンジニアに関する知識を記録、共有するためのサービスKiita、社内向け情報共有サービスKiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
来週も火曜日の朝6時に最新話が更新されます。番組のフォローをして最新話もお聞きください。
それでは3回にわたりありがとうございました。
お相手はKiitaプロダクトマネージャーの清野利史と、
KBDIアジャイル開発センターのみのるんでした。