アウトプットの大切さをエンジニアに聞いてみた。

西村「はじめまして、シニア テクニカルトレーニング マネージャー の西村です。よろしくお願いします。」

全員「はい、よろしくお願いします。」

写真左上： 西村 航 (アマゾン ウェブ サービス ジャパン合同会社 シニア テクニカルトレーニング マネージャー)
写真右上： 山下 光洋 (トレノケート株式会社 技術教育エンジニア)
写真左下： 臼田 佳祐 (クラスメソッド株式会社 シニアソリューションアーキテクト)
写真右下： 松井 英俊 (株式会社スタートアップテクノロジー テックリード)

西村「まず最初にこれまでの経歴を簡単に教えていただけますか ? 臼田さんから。」

臼田氏「子供の頃からパソコンをさわるのが好きで、親が自衛官ということもあって、高校は高等工科学校という自衛隊の高校に進学しました。自衛隊の中でのエンジニアを育てる学校だったのですが、私のテリトリーはその中でも暗号機や無線機でした。高校卒業後も自衛隊で仕事をしたのですが、IT エンジニアとしての仕事をしたいという思いがつのってきました。20 歳の時に自衛隊を除隊して 4 年制専門学校に入って IT をみっちり勉強しました。その後はネットワーク機器の販売会社に入社してネットワーク・セキュリティ周りを担当していましたが、 AWS に出会ってから仕事で AWS に関わりたいなと思っていたタイミングでクラスメソッド株式会社に転職し、今に至ります。」

西村「ほんわかした雰囲気があるので自衛隊の入隊経験があるのはちょっと意外でした。次は山下さんお願いします。」

山下氏「はい、これまでの経歴を話してくださいと依頼された時に作成した画像をベースにお話させてください。」

西村「経歴までアウトプットしてるんですね !」

~ 山下さんのこれまでの経歴をまとめた年表です。経歴までアウトプットするとは流石 ~

山下氏「キャリアの最初は不動産会社のリゾートホテル開発事業で、データベースなど含めたシステム内製化を行いました。これまで手書きだった領収書などの書類をドットプリンターで印字して自動出力できるようにしたところ、同僚に喜ばれました。 IT の自動化がもたらす恩恵を感じられたので、めちゃめちゃ嬉しかったですね。その後はソフトウェア受託開発で開発業務を行っていたのですが会社が倒産して、飲食業の情報システム部門に入ってメールサーバーの自動化をしたりしてました。その後は専任担当者がいない会社で情報システム部門を作る過程で自社ビル内のサーバーリソースが不足した時に Amazon EC2 を知って AWS に出会いました。その後は自分の個人ブログを AWS に移行したり、AWS のイベントに登壇したり、AWS の本を出版したりして、AWS 認定インストラクターになって今に至ります。」

西村「私は AWS に入社する前から山下さんのブログを見ていたので不思議なご縁を感じます。最後に松井さんお願いします。」

松井氏「高校は情報技術科で今で言うところの IoT の走りみたいなことをやっていて、コンピュータサイエンスを勉強したり、Java や C 言語でコードを書いていました。その後は自動車会社の企業内訓練校で 1 年間勉強して、設備保全系の仕事や機械メンテナンスや電気工事など担当して退職しました。その後は本当に転々としていて、インターネット系の商材を売ったり、土木系の解体工事の日雇い仕事だったり、太陽光パネルを設置したり IT からは離れていました。その後に入った会社では社内システムの Ruby での内製化を担当したり開発業務をする過程で EC2 や Amazon RDS を使うようになりました。その会社を退職して、故郷の静岡の会社に入って仮想デスクトップ環境構築などを行いつつ、 社内で Git の手解きをしたり、JAWS 浜松支部 で AWS でなにか作って LT したりしました。その後やはり Web やクラウドの技術にもっと注力したいという思いが強まり、縁あって同じく地元の Web 制作の会社に転職し、そこでも引き続き個人的な活動を続け、builders.flash で記事を書いたりもしました。その後に今の会社に入りました。」

西村「紆余曲折あって IT に原点回帰したキャリアですね。皆さん、ありがとうございました。ここからはざっくばらんにアウトプットに関する話をしていきたいと思います。」

臼田氏「反響があったという意味では、私は [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました というブログ記事ですね。セキュリティに関して深堀りしたというのもあるんですが、内容も初級から上級まで、ガッツリ書きました。」

~ セキュリティ対策が全部記載されているので、ブログ記事の中でも書かれている通り “ちょー長い” です。網羅性が素晴らしく、読み応えがあります。SNS でのシェア数が驚異的です。~

山下氏「私は JAWS で登壇した 情シス必要論 ですね。情シス不要論という単語が流行っていたので、自身の経験も踏まえて情シス必要論を話したところ、話題になってメディアの方に取材されたりしました。」

ご自身の実際の経験から情シスで出来ること・やるべきことが凝縮された資料になっています。必要とされる情シスになる、はとても良いメッセージですね。

松井氏「私は JAWS DAYS 2021 の配信環境を構築した ときですね。ただ環境を構築するだけではなく、アーキテクチャの説明を 会社のブログ でも書きましたし、複数のイベントで説明してアウトプットしました。AWS Serverless Hero に選出いただいたキッカケでもあるので思い入れがありますね。」

~ JAWS DAYS 2021 の配信環境を IVS + サーバーレス でシステム構築し、4000 人 ( ! ) 近くの視聴者がいたにも関わらずスムーズな配信を達成しました。~ 

西村氏「なるほど。私は入社して最初に書いたブログ記事ですね。 AWS 公式ブログに勉強方法 (自宅で学ぼう ! AWS 初学者向けの勉強方法 6 ステップ !）の記事を書きました。自分が担当するトレーニングで勉強方法をお客様から聞かれることがあったので、トレーニングがあるたびに勉強方法に関して自分が書き溜めていたメモを毎回板書していたんですが、それをまとめてブログにしたものになります。」

~ AWS の初学者向けの勉強法に関してまとめたリンク集になります。この記事がキッカケになって、以降は勉強方法に関連する記事を書くようになりました。~

臼田氏「たとえば、自分でなにか知りたいことがあった時に検索したとします。最初の 1 個めに出てくる記事で目的が達成できなくて、最初の 1 個めから 3 個めまでに出てくる記事を全部読んで目的が達成できた場合、確実にブログを書きますね。どういうことかと言うと、現状は 自分の知りたいことがインターネット上で 1 つの記事でまとまってない ということなんです。そのため、自分が 1 つのブログ記事でまとめて書けば、自分と同じ疑問をもった誰かのためになると思うからです。そこまで厳密じゃなくてもいいかもしれませんが、世の中の情報源で適切なものがないと気づいたときに今後の自分のためにアウトプットするかぐらいの気持ちで良いかなと。」

山下氏「生きている限り何かしらやっているので気づきは絶対あると思いますし、何でも発信すればいいと思います。発信する時に自分の中でのハードルを上げすぎない方がアウトプットする習慣は継続しやすい かなと。たとえば、ご飯を食べたお店の情報とかでもいいと思うんですよね。お店の名前をネットで検索して 3 年前のネット記事がヒットしたときにそのお店が今営業してるかわからないですけど、1 週間前に Twitter でココに食べに行きましたって自分が発信すればそのお店が営業してるんだなって誰かには伝わるじゃないですか。」

臼田氏「数撃ちゃ当たるじゃないですけど、どういう記事が多くの人に読まれるかとかって予測できないですからね。」

山下氏「個人のブログでも過去の記事と内容が重複していないかは気にしますが、なんでも書きますね。既存のハンズオンに関する記事を見て、そのとおりにやってみるとソフトウェアのバージョン違いなどで上手くいかないことが多いので、既存記事を引用する形で自分なりの工夫やハマった点を追記して書いたりしますね。あとは YouTube とかも最近取り組んでいます。書籍は静的情報なので、書籍を読んだ人のフォローアップとしての動的情報を YouTube にアップしています。実際の手順とかって動画で見るとイメージしやすいですし。」

松井氏「確かに動画だと確実に同じ手順で進められる安心感はありますね。」

西村「松井さんはどうやってアウトプットのネタを探しますか ?」

松井氏「締め切り駆動型なので、締め切りが決まってから本気だします。」

全員「それは分かる !!!」(西村補足 : 全員のこころが一つになった瞬間でした。)

松井氏「これアウトプットしたいなって思っていても流れちゃうことって多々あるので、誰かに期待される状況を作って自分を追い込む方が性に合っている気がします。社内勉強会が毎週木曜日にあるんですが、いつも直前に内容を決めますし。何を話すかアウトプット前提でインプットするというか、アウトプットすることが決まっていると必然的にインプットする かなと。なにかアウトプットの機会があったときに、やります ! って反射的に手を上げて締め切りがセットされて、そこから逆算する感じで動いていますね。」

山下氏「それ、私も同意です。積極的に自分から手を挙げるのは大事ですよね。依頼してもらった時に断ったら、再び依頼してもらえなくなった経験もありますし。 1 回目を逃すと 2 回目は来ないなと。やってみてから考えた方が良いかなと。できるようになってからやろう、余裕ができてからやろうと思うと、やりたいと思った時にもう終わってたりするんですよね。」

臼田氏「イベントに登壇するときは自分も締め切り駆動で動きますね。具体的に何を話すかは完全に後回しです。先日 AWS re:Invent の内容を振り返るイベントが社内であったのですが、自分が登壇を立候補するのも前日に決めました。あとは、常にアウトプットした方が良いなと思うネタはストックしているので、そこから選べばいいかとゆるく考えています。一気にやろうとしても仕事の割り込みは必ず発生するので、締め切りにむけて少しずつアウトプットを形にしていけばいいかなと。割り込みが発生して間を空けたほうが客観的に自分の書いた文章を見れる気もします。」

西村「私は最初にブログを書いたときは、同僚でブロガーのカックさん (@kakakakakku) にブログに関して色々と教えてもらいましたね。アウトプットすることを意識したのも、最初から誰かのために書くとか考える必要はなくてメモから始めればいい、と言われたことがキッカケでしたね。過去の自分がこういうメモがあったら助かっただろうな、忘れるかもしれないから未来の自分のためにメモしておこうかな、ぐらいの気持ちで始めると良いかもしれませんね。」

~ カックさんのブログ記事 (技術ブロガーを育てる！ブログメンタリングで何を教えているのか - kakakakakku blog) の中でも、アウトプットとは何か ? なぜブログを書くのか ? に関してステップバイステップで分かりやすく説明されています。~

臼田氏「お客様に対して普段プリセールスする際に、お客様が既に自分のブログ記事に事前に目を通してもらえることがあるときですね。素直に嬉しいという気持ちもありますし、既に記事を読んでもらっていて共通認識がある状態でミーティングができる ので話が進めやすいです。」

松井氏「コミュニケーションコストが減らせるメリットはありますよね。」

臼田氏「よく使うブログ記事はブックマークしておいて、ミーティングで説明したい内容がある時にシュッと出せるのも便利ですね。外部に公開していれば、ブックマークしてなくても検索すればすぐ出てきたりしますし。」

西村「誰でもアクセスできるようにインターネット上に自分のメモを保管するイメージですね。」

山下氏「私の場合は、AWS に関する内容を自分のブログで書いているので、もともと自分のブログの読者だった方が自分のトレーニングに受講者さんとして来てくれたりしますね。トレーニング中に画面のイメージ図や手順などを見せたい時に、ブログに事前に書いて置けばその記事をベースにすぐ説明できるのでスムーズです。あとは自分のブログも AWS 上で動かしているので、どういうアーキテクチャで構築しているかとか話すと結構喜んでもらえます。人事ご担当の方が私の書いた本を読んでくれていて、トレーニングの講師として直接指名してもらえたりします。」

松井氏「アウトプットの質を見てエンジニアとしてのレベルを知ってもらえるメリットはありますよね。私も今の会社の CTO が、私が builders.flash で書いた記事 (AWS Amplify と Vue.js を使って、基本的な認証と CRUD 操作ができる Web アプリケーションを作る) を見ながら AWS Amplify を勉強していたみたいで、採用に直接影響したかは分かりませんが認知してもらえていたことは面接時にプラスに働いていたと思います。会社のカルチャーとして、社外へのアウトプットで会社のプレゼンス向上に寄与することを評価してくれますし。アウトプットって雪だるま式に膨らむ ので、どこかでブログを書いたり LT したりすれば、それを見た人が声をかけてくれて、次の活躍の場を紹介していただけて、わらしべ長者みたいになると感じます。」

山下氏「それ分かります。情報は発信する人に集まる のを実感しますよね。フィードバックももらえますし。」

西村「見てくれた人からフィードバックをもらえるのは大きいですよね。私も先ほどお話した勉強方法に関する記事を書いて、それを読んだお客様から資料として読みやすいようにプレゼン資料の形式だと良いとフィードバックをいただいたことがありました。非常に良いアイデアだなと思って、ブログ記事をプレゼン資料の形式に修正して内容をアップデートして AWS Summit Online 2021 で登壇 (初学者向け AWS 学習パス ~まずはクラウドプラクティショナー認定資格から~) しましたが、社内勉強会で使いますというありがたいコメントをいくつかいただけました。」

臼田氏「現職で書いたブログを見た人に声をかけていただいて、Security JAWS の運営に携わるようになって JAWS DAYS 2018 に登壇することができましたね。それが初めてのイベント登壇だったんですが、それ以降も様々なイベントで登壇するキッカケになりました。」

西村「アウトプットすることでセキュリティに詳しい人として認知されるようになったということですね。」

臼田氏「前職では無線機器に関する製品主管 (製品に 1 番詳しい人) だったので、社内展開向けのトレーニング資料などを作っていたんですが、社外に出すまで至らなかったんです。社内にクローズドだった資料だったので外部公開できず、いろんなお客様に都度都度同じことを何回も説明するのは効率悪いなと感じるので、社外に対してブログを公開すれば 1 回の投稿で済む のは効率もよいと感じます。アウトプットするカルチャーに憧れて今の会社に入ったというのもあります。」

山下氏「私は自分のブログ記事 (思っていることを口にしたらこうなった) でも書いたのですが、アウトプットした内容を目にした方から取材を受けたりして露出が高まったことで、今の仕事につながりました。ほかは外部に向けたインプットは社外の人に知ってもらえるだけでなく、社内の人を説得する材料にもなりますよね。社内の人を説得したい内容を、社外に向けて発信する。そうすることで、世の中の動きと自分の動きがあっているか、外のモノサシで見てみてどうか、と客観的に照らし合わせることができるので、説得力を増すことができます。」

西村「社外のお客様からの評判が良かったら、社内の人も納得しそうですね。」

山下氏「社内向け資料は発表しても 1 回で終わりなので、少しもったいなく感じるんですよね、検索しても引っかからないですし。もちろん社外秘の情報は省く必要はありますが、誰かの目にとまるパブリックな場所に置くほうが見て貰える人が増える可能性はあると思います。」

松井氏「私は原点的なところだと、JAWS 浜松支部に入って初めて LT した時ですね。JAWS でよく言われる “100 回の勉強会参加よりも 1 回の登壇へのチャレンジの方がより大きな成長ができる” ことを実感できたので、登壇に対して積極的になりましたね。同じ技術で共感できる人と話せるコミュニティの醍醐味を感じられましたし。JAWS 浜松支部はどんな LT をしてもマサカリが飛んでこなかったのがありがたかったので、最初はアウトプットに歓迎的なコミュニティで発表すると良いかなと思います。」

~ JAWS-UG は AWS を利用する人々のユーザーコミュニティです。「支部」の形でグループを持ち、それぞれのテーマに基づいて活動を行なっています。JAWS のホームページは コチラ です。~

西村「ちなみに、臼田さんと山下さんは AWS 認定インストラクター として AWS の公式トレーニングを担当していますが、どういう影響がありましたか ? 広い意味で考えるとトレーニングもアウトプットかなと思い。」

臼田氏「人に伝えるという意味ではアウトプットですが、通常のイベント登壇とトレーニングは全く身につきスキルが違います。通常のイベントだと一方的に話すスタイルですので、聞き手がイベント後にゆっくり知識を咀嚼すれば OK だと思います。トレーニングの場合は 1 日か 3 日間という限られた時間でお客様に知識をしっかり身につけて帰ってもらう必要があるので、重要な部分を確実に抑えて理解度を確認しながら対話的に進めていきます。そのため入念にストーリーなどを練ります。」

山下氏「私もイベント登壇とトレーニングは違う脳を使っている感覚がありますね。対話的に進めるのは強く意識しています。お客さんと話しながら進めると多種多様な質問がきて、日々自分の知識強化につながると感じます。自分が教えながらも、リアルタイムで現場の話など含めてお客様に教えてもらっているなと感じます。」

臼田氏「私は最初にひととおり実機をさわってみますね。やることを全部やります。その後にブログを書き始めますが、事前にガッツリ実機をさわっていて書きたい中身が頭の中にあるので、伝えたい内容を凝縮したブログ記事のタイトルを 1 番最初に書きます。サムネイルとタイトルを見て、ブログ記事を読むか決める人が多いのでタイトルは特に気を使います。書く流れとしては、頭の中にレイアウトが決まっているので、上から順番に概要を書いていきますね。あと、ブログを書くには 2 つの意味での『ショウカ』が必要だと考えています。」

西村「(今から良いこと言いますよの顔してる。)」

臼田氏「1 つ目は消化ですね、ブログ記事を書いていく中で様々な内容を咀嚼して吸収する。2 つ目は昇華ですね、ただやったことをそのままログとして書くのではなくて、読み物として参考情報を足してより高いレベルにもっていく。書きながら少しでも不明な点があったら全部理解する必要があるので、大量のブラウザタブで外部リンクなどを立ち上げておくと引用しやすくてスムーズです。ちなみに Zenn だと スクラップ機能  があるので、記事を書く前にやっていることをメモして引用できたりします。」

山下氏「私の場合は検証系ブログ記事を書く場合は、実機をさわるのと並行してブログ記事を書きますね。」

松井氏「それはスピード感ありますね。」

山下氏「実機をさわり終わった時点で、私の検証系ブログ記事はもう書き終わっています。」

西村「北斗の拳のケンシロウみたいな言い方しますね。」

松井氏「実機をさわりながらだとエラーとかバンバン出ませんか ?」

山下氏「はい、バンバン出ます。ただ、技術的なことを検索するときって、うまくいってないときとかエラーが起きてるときがほとんどじゃないですか ?」

臼田氏「たしかにアルアルですね。」

山下氏「エラーメッセージで検索した人が辿り着ける先にしてあげたいなという思いがありますので、エラーとかは今後そのエラーにぶつかる人のためにそのまま記事に記載して、後でエラーが発生しない手順を別で公開します。過去には Amazon Linux にRedmine 環境構築する場合に エラーと対応をそのまま記載版 と 手順整理版 の 2 つを用意しました。あとは、自分が写真撮影 OK のセミナーやカンファレンスとかを聴講したときは、ハンズオンイベントならスクリーンショット取りながら記事を書いて終了後にすぐに記事公開して、講演イベントなら講演内容はスクリーンのスライドを撮った写真を引用してそこにコメントを追記していって記事を改定終了後にすぐに公開します。イベント参加レポート系の記事は後で書くってなると絶対にやらないので、遅くとも当日中に公開した方が良いですね。」

松井氏「自分がアウトプットするときは、ウケがよさそうなネタかどうかを最初に強く意識 しますね。言い換えるなら、ウケた時に副次的効果を期待するといいますか。読んでくれた人の反応が無いとモチベーションが上がらないので。単純に AWS でこういうサービスが出ました ! だけではなく、開発現場にいる開発者にとってどういうメリットがあるのかまで深堀りして書くようにします。特にハンズオンを作る場合は、AWS のマネージドサービスをメインにした内容にしています。開発者が実際に現場で使えるし、本質的な作業にフォーカスできるので、ハンズオンの完走率も高くなって達成感も得られるんですよね。マネージドサービスのメリットを実機を通して感じると言いますか。AWS が提供しているマネージドサービスはさわってみるとサクサク進められますし。専門的な人の痒いところに手が届く部分も押さえつつ、初学者の人にキャッチーに伝えるべき部分も意識します。」

臼田氏「嘘を書かない、ファクトベースで書くってことですかね。途中で事実と推測が混ざった記述は邪魔で、見る人にとっては できる or できない の事実で十分だと個人的には思います。実際に自分が実施した結果を書いて、推測を書くなら推測の根拠を書く。事実と推測を分けて書く のは重要だと思います。あとは、一般的な話だと思いますが、必要以上にネガティブに書かないってことですかね。例えば 〇〇 社の 〇〇 というサービスが良くないとかブログで書くよりは、その 〇〇 社に直接フィードバックした方が改善される可能性も高いと思います。」

西村「社内でブログを書く際に事前レビューとかしますか ?」

臼田氏「基本的にはブログを公開した後に、それを読んだ別の社員がフィードバックして修正を入れていく形ですね。とは言っても完全放置とかではないので、入社して最初にブログを書くときに書くべきでないこととかの重要事項はキッチリ伝えます。アウトプット初心者じゃなかった人なんていない ので、まず書いてみることから始めるのが大事かなと。」

山下氏「私も事実だけを書くというのは臼田さんと同じ意見です。あとは、受け手側のことを想像してメッセージングする ようにしています。自分では良かれと思っていても相手にはマウントになるんじゃないか、萎縮させるんじゃないか、などは常に意識しています。例えば簡潔に書きすぎて怒っていると誤解されたり、文字だけのアウトプットだと意図が正しく伝わらない可能性もあるので、表現には配慮しないといけないかなと。配慮しすぎると書けなくなるので難しさはありますが。」

西村「山下さんは何冊も書籍を書かれていますが、書籍を書く時に注意していることはありますか ?」

山下氏「本は最も気を使う媒体ですね。書き直しの手間が大きいので、間違ったことを書けないプレッシャーが大きく、入念に試しに試して書きます。ただ語尾を合わせるとかの体裁は編集者の方がキレイな大人に文章にしてくれます。あれは職人技です。こないだ出版した本では勉強疲れの間にくすっと笑ってほしいというピュアな思いで、ちょっと笑える練習問題なんかも作りましたが、問題がふざけすぎではないか ? というフィードバックもあったので真摯に受け止めました。」

臼田氏「VS Code だと textlint があるので、 自分で薄めの技術書を作る人とかは textlint で体裁チェックしてたりしますよね。」

西村「校正チェックを自動化できるの便利ですね。」

松井氏「私は正しいことを書くのと同時に、間違ったことを書かない ことを強く意識しますね。例えば情報ソースを明示的にするのは常に心がけています。ハンズオン手順とかは、書き終わった後にもう 1 回読者目線で全く新しい環境で最初から最後まで動作確認します。あとは、断定的な書き方を極力避けるとかですかね。条件付きでこうなる場合もある、など正確さを意識して書きます。」

西村「確かに正確さは重要ですね、書き手の信頼にもつながりますし。本日はどうもありがとうございました。アウトプットの話が中心でしたが、エンジニアとしてのあり方などお話しさせていただき非常に面白かったです。」

全員「ありがとうございました。」

いかがでしたでしょうか ? アウトプットするかどうかを悩んでいた方がこの記事を読んで、小さなことからコツコツと ! アウトプットするようになっていただけると幸いです。まずは過去の自分や未来の自分のためにメモを取ることから始めてみて、少しずつ外部に公開していくと誰かの幸せにつながるアウトプットになっていくのかもしれません。ぜひぜひ一緒にアウトプットしていきましょう。

そして「アウトプットがなぜ大切かを話す座談会しましょう。事前に目次とかは決めずに、出たとこ勝負でいきたいと思います。きっと大丈夫です。」という私からのカジュアルすぎるインタビュー依頼を快諾いただいた 臼田さん・山下さん・松井さん に、この場を借りて改めて御礼申し上げます。

この記事が少しでも “How to be a Developer” な皆様のお役に立てれば幸いです。
また別の記事でお会いしましょう ! それでは !