2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
佐々木大輔氏(以下、佐々木):せっかく今回書籍を書いたみなさんに来ているので、この本をどんな人に読んでほしいですか? というところと、読んだときにどういうところを学んでほしいのかというところ。そこらへんを改めて著者からのメッセージということで1人ずつお願いしたいと思います。千葉さんからお願いしていいですか?
千葉淳氏(以下、千葉):一応今回『みんなのAWS』っていうタイトルなので、みんなって書いています。基本的にはみんななので、なんでクラウドが出てきたみたいな背景からベストプラクティスから実際に手を動かすみたいなところまでカバーしています。新しくAWSを始める方に見てほしいですし、今EC2とか触っている方にも見てもらえるような内容になっているんじゃないかなぁと思っています。
佐々木:ありがとうございます。書いた章順序で聞こうかな。次、臼田さんお願いしていいですか?
臼田佳祐氏(以下、臼田):まさにみんなに読んでほしいというところは千葉さんが言ったとおりです。そうなるようにベストプラクティスの部分はしっかり手厚めに書いています。その中で僕はセキュリティが得意なのでセキュリティの部分のベストプラクティスについてもしっかりと触れつつ、実際どうやって使うのか、どうやって考えるのかみたいなところも押さえています。
書いてある全体の内容としてはAWSのスケールからするとほんの一握りの部分ですけど、なるべくベストプラクティスを押さえつつある程度体系的に学べるという感じになっています。しっかり体系的に押さえたいっていう方は、EC2はないんですが、それでもちゃんと体系的になっているので(笑)。とくにセキュリティについても僕はちゃんと押さえています。
もう少しセキュリティに特化した話をすると、AWSのセキュリティって2種類あるんですね。AWS自体を使うためのセキュリティとあとは実際に上に乗せるアプリケーションのセキュリティですね。大きく分けるとその2種類の要素があって、それぞれどうやってやっていくかっていう考え方について書いてあります。
端的に言うとAWSを使うためのセキュリティはやっぱり新しい要素なのでちゃんと覚えましょう。逆に上に乗せるものは既存のセキュリティの考え方の延長線上なので、そこをしっかり押さえましょうということ。かつAWSのサービスを使うとそれが簡単になるので、ぜひ使いましょうねっていう感じで書いています。
そんな感じの内容になっているので、セキュリティよくわかんないなっていう方でも入りやすくなっていると思います。ぜひ読んでみてください。
佐々木:ありがとうございます。すごくよくまとまった話が来て、このあとの人めっちゃ話しづらいだろうなと思います。
じゃあ聖剛さんお願いしていいですか。
渡辺聖剛氏(以下、渡辺):私の担当が監視・モニタリングで、オンプレでやっているやり方とAWS、クラウドインフラって同じところもあれば違うところもあります。
やらなきゃいけないことっていうのは大きくはあるんだけれども、やり方が違うとか。変わったことでやらなくてよくなったものとか。あえて追加してやらなきゃいけないこととか。考え方が変わるところがあるので、そこを書いたつもりです。
さっきの新しいものがどんどん増えてっていうのもあるんですけれども、クラウドインフラになっても考え方が変わらないところはたぶんこの先も共通していくかなと思います。そのへんを読んでもらえればいいかな。たぶんほかの人もそういう見方をすればどんどん通用できるものがあるので、そのへんを見てもらえればなと思っています。
佐々木:ありがとうございます。じゃあハマコーさんお願いします。
濱田孝治氏(以下、濱田):ここを読んでほしいっていう、僕が書いた中で1つだけ言うとすると、2の8ですね。CloudFormationでハンズオンで構築していくところをぜひやってほしいです。GitHubで公開して動かせるようになっていて、僕が考え得る限りの、俺が考える最強のCloudFormationになっています。
佐々木:ははは(笑)。
濱田:最強のCloudFormationって何かって言うとちゃんと運用に乗せて各リソースのライフサイクルを考えてやっていくためにはこういう分割の仕方をしたほうがいいねっていうところまで踏み込んで書いています。
それを見つつ、いろいろ動かして、そのうえでできあがったリソースのプロパティとか眺めて「ああ、こんな感じでできあがっているんだなぁ」っていうのを見てもらえるとけっこう広範囲にいろいろな部分が学べると思います。それをぜひぜひ手を動かしてやってほしいというふうに思っています。もし動かなかったら遠慮なく僕のTwitterにでも文句言ってください。
公式ドキュメントにはほぼ載っていないような感じで秘伝のタレを書きました。
佐々木:ありがとうございます。じゃあ江口さんお願いします。
江口佳記氏(以下、江口):どんな人に読んでもらいたいか、何を学んでほしいというところだと、やっぱりクラウドならではのどうサービスを活用してアーキテクチャを作っていくかということを学んでほしいと思っています。
私が書いたところはどっちかと言うとCloudWatchのセッティングの仕方を丁寧に解説しているような章になっています。今までオンプレで経験があるけどクラウドでどういうアーキテクチャを作っていっていいかっていうのがわからないという方もけっこういるかと思います。そういう方たちに学んでほしいなと思っています。
佐々木:ありがとうございます。じゃあ菊池さんお願いしていいですか。
菊池修治氏(以下、菊池):読んでほしいのはみんなに読んでほしいんですけど(笑)。何を学んでほしいっていうのはですね。EC2じゃなくていきなりFargateが出てくるとか。手を動かしながらそういうのを学べるところではあるんですけど。ぶっちゃけサービス何使うかとか、細かい機能とかって時が経てば変わります。意識したのはモダンな作り方、クラウドを活かした作り方がこうやるとできますよっていうあたりです。
そこからAWSの考え方とかクラウドを使う考え方のベースの部分というのを感じてもらえればいいのかなと。それはきっとサービスの仕様がちょっと変わっていってもそんなにブレることはないし、ほかのパブリッククラウドでも共通して使える力になるのかなと思います。
佐々木:ありがとうございます。じゃあ加藤さんお願いします。
加藤諒氏(以下、加藤):私は3章について主に話すんですけど、AWSって聞いたときにIaaSだなってパッと今思った人とかにとくに読んでほしいなと思います。3章はサーバーレスアーキテクチャなんですが、いわゆるインフラじゃないんですね。AWSというサービスを使ってものを作っていくということを体験できるようになっています。
あと学んでほしいこと。3章をインフラエンジニアの方に実際に本を読みながら紹介しているものを作ってもらって、衝撃を受けてほしいです。ふだんインフラエンジニアの扱う範囲ではサーバーレスってあんまりやらないと思うんですけど、ものすごい開発体験があります。こんなにも簡単にアーキテクチャができちゃうのかと。本当にものの数時間でプロダクションレディなスケーラブルなアーキテクチャが作れちゃうっていうのを体験してもらいたいですね。
とくにAWS CDK、いわゆるInfrastructure as Codeなんですけど、一般的にInfrastructure as Codeをやるとゼロベースで作ることを考えるとマネコンで作るより遅くなるんですね。パラメーター見て、こうだよねって調べながら作っていく。それに対してAWS CDKはむしろCDKを使ったほうがマネコンで作るより早く作れる。この体験、私初めて触ったときめちゃくちゃ衝撃的だったので、ぜひこれを体験してほしいです。以上です。
佐々木:ありがとうございます。ハマコーさんがチャットに書いていましたけど、熱いっすね。メッセージが(笑)。
濱田:熱いっすね~。でもたしかにそうなんですよね。僕も『みんなのAWS』読んで学ぼうかなと思っています(笑)。
佐々木:自分の好きなことを熱く語れることはすごくいいことだと思います。じゃあ藤井さんお願いします。
藤井元貴氏(以下、藤井):実際にAWSを使ってなにか作ってみたいなと思っている方にとくに読んでほしいと思っています。
そのうえでどういうことを学んでほしいかというと、実際に本のとおりに作るハンズオンとか、2章3章4章とあるんですけど、いろいろ選択肢があるわけですよね。いろいろなサービスがあるし、いろいろな組み合わせがあるし、どうしていいかわからんと。
というところでこの本ではこういう仕組みでやっているのは理由は何か。本に書いてあることもあるんですけど、理由は何だろうと。僕が今こういうものを作るんだったら別の方法のほうがいいんじゃないかっていうところで、ちょっとそこで立ち止まって疑問に思ってもらって。
じゃあそっちやってみてどうなんだろう。ああ、こっちのほうがいいじゃんかっていうふうになるのかどうか。なってもならなくてもどっちでもいいんですけど、そういったところで学んでほしいなと思っています。以上です。
佐々木:ありがとうございます。最後ですね。甲木さんお願いします。
甲木洋介氏(以下、甲木):データ分析周りも今非常にたくさんのサービスが出て、どこをどういうふうに使ったらいいのかっていうのがわからなくなっちゃっている人はけっこう多いです。最近だとデータウェアハウス、データレイクとかそういう新しい言葉が出て。それは一体何なの? どういう違いがあるの? とか。そういうところもわからない人はけっこう多いので。
そこの部分を一旦AWSだったらそういう意味ですよっていうふうに整理をしたうえで、藤井さんのハンズオンで作ることになるデータを実際にQuickSightで画面まで見ましょうっていう。そういうハンズオンが内容として用意されています。一通りAWSでデータ分析を作るの、どうしたらいいのかなっていうのがぜんぜん見当つかない人に1つのサンプルとしての基本的な型っていうのを提示したつもりです。
そういうお困りの人に見てもらうと嬉しいなと。最低限の用語の定義とか、そういったところも読んで理解してもらうだけでもだいぶ価値はあると思います。おすすめです。読んでください。
佐々木:ありがとうございます。
佐々木:じゃあ最後の項目で、最新のAWSテクノロジーをキャッチアップするコツ。さっきチラッとみなさんもお話されていたように書籍から体系的な技術を身につけて基礎をしっかりさせるというのはもちろんなんですけど。
最新のサービスのアップデートを追ってないと実際やろうと思ったときに、例えば設定画面が違うとか機能が違うとか、あるいは以前できなかったことができるようになったとかっていうのは数多くあると思います。
基礎の技術を身につけることと、最新の技術を身につけるというのは両軸で両方やらなきゃいけないことだと思うんですけど。その中でもAWSのアップデートは非常に早いので、どうやってそこをみなさんがキャッチアップしているのかというのをお聞きしたいです。とくに発言されたい方いらっしゃいませんか?
濱田:AWSどっぷりやり始めてからわかったんですけれども、早道はないと思っているんですね。僕の感触で言うとある程度1つのサービスを長い間追わないと、AWSがこのサービスをどうしていきたいのかっていうのがわかりにくいんですね。
ある程度長く触っていると、例えばコンテナ周りでもFargateって共有ストレージ使えなかったのが、都度使え使えって言われているのが、EFSが対応して一気に使いどころが広くなったりとか。やっぱり進化の方向性っていうのがあるんですね。
そういう流れがある程度わかってくるとどんどんどんどん便利になっていくな、このアップデートはこんな意味があるなってわかってくるので。実はそういう流れの中で進化の方向性ってわかってきます。
僕の私見で言うと、なにか好きなサービスを見つけて1年間その最新のアップデートを追い続けるっていうのを腹を据えてやるっていうのが実は一番の近道かなと思ったりします。
佐々木:プログラム言語とかもそうですよね。表面だけサンプルコード見てパッと書くのは誰でもできるんですけど。結局その関数とか機能がなぜ出てきたのかって、過去のマージの歴史を見てこないとわからないことがあります。今できることだけを見るのではなくて過去の経緯もちゃんと知りつつ、そこから未来をちゃんと見るっていうのは重要なことだと思いますね。
ほかにいらっしゃいませんか? どうやってAWSの最新技術を身につけているとか。キャッチアップしているとか。
臼田:けっこうやってこないと流れがわからないっていう話を今ちょうどハマコーさんがされていたので、逆に言うと流れをわかりやすく説明しているブログをうちの会社はけっこうあげているんじゃないかなって思っています。
僕も自分の得意な分野はそういうふうに書いているんですが、自分が得意じゃない分野って流れがわからないことが多いので。ほかの人が書いているブログ、とくにブログの新しいサービスが出ましたっていうリリースの最初の数行に書かれている経緯みなところとかを読むと、なぜそのサービスがリリースしたのかとか、何が嬉しいのかっていうのがけっこうわかりやすく書いてあることが多いなと思います。それをめちゃくちゃ参考にしていますね。
濱田:完全にそうですよね。Developers.IOですけど。みんなそうですけど、僕も必ずアップデート書くときは今まで辛かったことがこのアップデートでこう嬉しいみたいなのを冒頭に書くようにすごく意識しています。Developers.IOはそういうポイントをきっちり見てもらうと進化の方向性みたいなのがわかるかなと思うので、そこは着目してほしいですね。
佐々木:みんな自分のところのブログが好きすぎて、隙あらばブログの話をし始めるっていう(笑)。
臼田:まあでもAWSのリリースの文章も見ますけど、ブログのほうがわかりやすいですよね(笑)。
佐々木:まあまあまあ、そうですね。じゃあちょっとアンバサダーの菊池さんにも聞いとこうかなと思うんですけど。どうですか? 菊池さん。
菊池:キャッチアップするコツ……そうですね。みなさんいろいろな立場があると思うんですけど、AWSを実際使っている立場に身を置くのが一番いいんじゃないかと思います。
使っていないとインプットだけで身につけるってけっこう大変だしモチベーションも続かなくなってきます。自分たちでサービス運営しているものでAWSを使うとか、あとはAWS使ってなにか提供するとか。そういう環境にいれば自然とわりと身についてくるかなぁとは思います。
佐々木:まあまずは触ってみるっていうのは間違いなく一番大事ですよね。ありがとうございます。じゃあハマコーさんに並んでわりと新しめの技術のところの文章を書いていた加藤さんにも聞いてみようかな。
加藤:僕はけっこう最近リリース情報とかはAWSのSAさんをTwitterでフォローして、たいていその人たちがつぶやくので、それを見て「あ、新機能出たな」っていうのを見ることが多いですね。
そのツイートにたいてい「この機能ってこんなのだよ」って書いているから、それを頭に入れた状態でドキュメント読んでみて「ああ、本当だなぁ」とか「本当にそうか?」とか「俺だったらこう使うかな」とか考えながら軽く触ってみてキャッチアップしていくということをやっています。最新のキャッチアップはほとんどそうですね。
あともうちょっと具体的な話で言うと、AWSのAPIに変更があったときに通知が拾えるとか。AWSのドキュメントに変更が入ったときにそれをアナウンスしてくれるTwitterアカウントとかがあるので、そういうのを見て「あ、新しいのきているな」っていうふうにキャッチアップしています。
佐々木:ありがとうございます。そのへんのキャッチアップはいろいろ自らプロアクティブに情報収集しなきゃっていうところがいっぱいありますかね。ありがとうございます。
菊池修治
クラスメソッド株式会社 シニアソリューションアーキテクト
加藤諒
クラスメソッド株式会社 サーバーレスエンジニア
甲木洋介
クラスメソッド株式会社 プリセールスアーキテクト
濱田孝治
クラスメソッド株式会社 シニアソリューションアーキテクト
藤井元貴
クラスメソッド株式会社 サーバーレスエンジニア
渡辺聖剛
クラスメソッド株式会社 ソリューションアーキテクト
臼田佳祐
クラスメソッド株式会社 ソリューションアーキテクト
江口佳記
クラスメソッド株式会社 エンジニア
千葉淳
クラスメソッド株式会社 オペレーション部 部長
佐々木大輔
クラスメソッド株式会社 取締役兼AWS事業本部長
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには