本記事は
わた推し～AWSアワードエンジニア編～
2日目の記事です。
💻
1日目
▶▶ 本記事 ▶▶
3日目
💻
小西秀和です。
先日、2020、2021年に引き続き、2022年のAWS ALL Certifications Engineer(旧称：APN ALL AWS Certifications Engineer)、AWS Top Engineer(旧称：APN AWS Top Engineer) (Service)に選出されました。
今回はこれらの当社選出者達によるブログ企画「わた推し～AWSアワードエンジニア編～」の記事の一つとして、私が推すAWSサービスを紹介します。
「推し」というテーマということもあり、いつにも増して個人的、主観的な主張および長文となっていますので、その点はご了承ください。
私の推しのAWSサービスは「AWSドキュメント(AWS Documents)」です。
私自身、数年前まではAWSドキュメントを辞書代わりという位置づけで使うことが多かったのですが、近年、AWS関連の実務・自主研究に加えてAWS認定取得、ブログ投稿、書籍執筆といったアウトプット活動を通して、後述するようなAWSドキュメントの奥深さがわかったことがAWSドキュメントを推す理由です。
そのAWSドキュメントの魅力について語る前に、福澤諭吉の「学問のすゝめ」を模したブログ記事のタイトルにした理由を話したいと思います(ただ単にゴロがいいからではありません)。
「学問のすゝめ」を引き合いに出す理由
福澤諭吉の「学問のすゝめ」は明治初期の四民平等が始まった時代に書かれた書籍です。
なぜか「天は人の上に人を造らず人の下に人を造らず」が有名な文言として挙げられることがよくありますが、単純に平等を主張している本ではありません。
私なりに「学問のすゝめ」の趣旨を簡単にまとめると次のようになります。
- 「天は人の上に人を造らず人の下に人を造らず」と言われているが、実際には学問に勤める人とそうでない人で大きな差がある。
- 学問の要は活用できるかどうかにある(学問の理想を高くしすぎない。飯を炊き、風呂の火を焚たくことなども学問である)。
- 独立とは自分にて自分の身を支配し他によりすがる心がないことを言う。
- 独立ということは一人だけではなく、一つの国にも言えることである。
- 一人一人が学問を志し、独立してこそ一つの国が独立する。
つまり、四民平等の時代を生き抜くには、一人一人が独立して世の中に活用できることを学び続ける必要があるという主張がこの本から読み取れます。
当時は現在と時代や国際情勢が異なるため、「独立」という言葉が使われていますが個人に焦点を当てるとその使われ方は「自立」の意味に近いと思います。
ちょうど今から150年前に初版が出版された「学問のすゝめ」は現代に読むと時代錯誤な部分を含むのは当然です。
ただ、歴史の中で注目すべきなのは時代を重ねても変わらない普遍の価値観で、現代でも各個人が主体的に自立して世の中に活用できるものを学習し続けることの重要性は普遍であると私は考えています。
今回、AWSにおける学習について話す前提としてまず、この価値観を先にお伝えしておきたいと思い「学問のすゝめ」を模したブログ記事のタイトルにしました。
(余談ですが、「学問のすゝめ」は私が中学の読書感想文を書くために読んで純粋に好きになった本です。卒業大学は関係ありません。)
AWSを主体的に自立して学習していくために必要なもの
さて、AWSに話を戻します。
私は各個人の主体的で自立したAWS学習を最も効果的に促進することが「AWSドキュメント(AWS Documents)」を読むことだと考えています。
そのように考える理由には次のものがあります。
AWSドキュメントの熟読は主体的な学習意欲を促進する
冒頭で記載したように私は数年前まではAWSドキュメントは熟読せず、必要な情報がある箇所を検索して調べる程度で正直なところ苦手意識もありました。
後述しますがAWSドキュメントは各サービスごとの差はいくらかありますが、非常に情報量が多く最初から最後まで読むにはかなりの根気が必要です。
ただ、AWS認定取得、ブログ投稿、書籍執筆といったアウトプット活動を積極的にするようになってからはその活動の過程で何度もAWSドキュメントを読むことになり、次第にその奥深さがわかってきました。
まず、AWS認定の取得では特にベータ版に合格するための学習にAWSドキュメントが必要不可欠でした。
ベータ版のAWS認定では認定向けの学習リソースが少ない場合が多く、受験する言語も英語だけであるため、出題対象と考えられるAWSサービスについてAWSドキュメントでくまなく学習し、試験に出そうな英語の専門用語や言い回しもAWSドキュメントから確認しました。
次に、ブログ投稿と書籍執筆では自身が書く対象のテーマに関して後述するようなAWSドキュメントの熟読と実際のAWSサービスの実践の行き来を繰り返すことで理解を深めながら記事を完成させていくことに役立ちました。
特に書籍執筆で担当した練習問題の作成では業務以外の時間をすべてAWSドキュメントの熟読に費やすような時期もありました。
このようなアウトプット活動をしていく中で自然にAWSドキュメントを軸とした学習スタイルが自分にできてきたわけですが、AWSドキュメントを読むことは慣れれば思ったほど苦ではありませんでした。
むしろ、AWSドキュメントは自分の知らなかった情報やなるほどと好奇心を高める内容が多く、加えてAWSサービスの理解が深まっていく充実感もあり、それまで以上に学習意欲が高められる実感があります。
人のやる気はとりあえずやり始めると自然に発揮されると聞いたことがありますが、AWSドキュメントも苦手意識を持ちながらも、とりあえず継続的に読んでみて読むことに慣れて来れば、自然にAWSドキュメントを主体的に自立して読む習慣もできてきます。
AWSドキュメントは抽象化と具体化のバランスが取れた豊富な情報が詰まっている
個人差はありますが、人には物事を抽象化して短い時間で全体を想像する能力があると思います。
これは概要や図から複数のエンティティ同士の関係性や流れを時系列で全体的に概要を掴む場合に効果を発揮します。
例えば、各AWSサービスの主要なポイントを解説している「AWSサービス別資料」は資料にもよりますが、詳細な文章、手順、実装による解説よりも全体的な抽象度を高めた上で重要な点に的を絞って部分的に具体化して説明しているものが多いと思います。そのため、短時間で各AWSサービスの全体像、ベストプラクティス、アーキテクチャ例をインプットすることができます。
一方で具体度の高いAWSサービスに対するアプローチは実際にAWSサービスを使ったりコーディングをしてみることです。
AWSサービスを実際に使ってみることは使用したAWSサービスの範囲に限定はされますが、実際の動作を確認して利用可能なレベルまで理解度を高めることができます。
そこから少し抽象度を上げると「AWS Workshops」など実際のAWSサービスにおける実践的な操作を説明するコンテンツが挙げられます。
しかし、具体度の高いアプローチは深い理解が得られるものの実際の作業量が多く、全体的な仕様を把握せずに手を動かすことを中心に学習をすすめると見逃してしまう機能や設定方法が発生する可能性もあります。
また、権限・費用・時間などが障壁となって実際に試すことができない機能も場合によっては存在します。
そのため、特定のAWSサービスを専門的に使いこなせるようになるためには必要なアプローチですが、限られた時間で多数のAWSサービスの仕様や関係性を把握するような場合には向いていません。
このように学習方法ひとつをとってみても抽象化と具体化のレベルは様々ですが、人は普段あまり意識していなくても抽象化と具体化を駆使して物事を理解したり、説明したりしていると思います。
ただ、抽象化と具体化を意識して物事を観てみると必要とする理解度を得るために何をすればいいかターゲッティングがしやすくなります。
一般的に製品のドキュメントという位置づけは実際に使用しなくても製品の機能、特徴、使い方がわかるものが多いです。
加えてAWSドキュメントでは推奨事項であるベストプラクティス、トラブルシューティング、他のAWSサービスとの連携などについても記載されています。
さらに、特に制限なくマネジメントコンソール上から使える機能はもちろん、バックエンドの表面上見えない仕様、権限・費用・時間の制限などで個人として使用することが難しい機能まで様々な情報が豊富に詰まっています。
おそらく抽象化と具体化のバランスの感じ方は役割やAWSへの関わり方などに応じて人それぞれだと思いますが、前述のようなことから私はAWSドキュメントが抽象化と具体化のバランスが取れているコンテンツだと感じています。
AWSドキュメントは各AWSサービスごとに構成や書き方に違いがある場合もありますが、全般的に文章と必要十分な図表で説明を試みようとしていることが見受けられます。
このように、極力文章中心に詳しく解説され、複雑な概念を必要に応じて図表にしたドキュメントを読むことによって、文章を論理的に読み取り、自分の頭の中で図式化して学習する習慣が身につきます。
これは決して「わかりやすい」を追い求めるアプローチではないですが、私はこの習慣が主体的で自立した学習をするために必要なことだと考えています。
前項で書いたようなAWSドキュメントを主体的に自立して読む習慣ができれば、AWSサービス別資料など(抽象化)で主要な機能を把握した後、AWSドキュメントの熟読(抽象化・具体化の平衡)と実際のAWSサービスの実践(具体化)の行き来をしながら繰り返すことで全体を意識した実践的なAWSの学習が主体的に自立してできるようになってきます。
また、AWSドキュメントを軸として学習をすすめていると、自分の学習対象としている概念を理解するために必要なものが、より抽象化されたアプローチで全体像を把握することか、より具体化されたアプローチで実際の使用を実践することかの判断がしやすくなるという利点もあります。
AWSドキュメントはインプットとアウトプットを繋ぐ
最初に私がアウトプット活動の中でAWSドキュメントを読み、学習意欲が高まった話をしましたが、私以外にもAWSに関するアウトプットをする人は非常に多いと感じています。
AWSが他のクラウドサービスと比べて特徴的なのは多くのコミュニティがあり、個人レベルでもAWSに関するアウトプットをするエンジニアが多いことです。
抽象化した内容でアウトプットするパターン、具体的に実践した内容をアウトプットするパターン、抽象化された内容と部分的に具体化した内容を組み合わせてアウトプットするパターンなどその特徴や観点は様々ですが、目的に応じた情報収集に役立つものが多いと感じています。
このようなアウトプットはAWSドキュメントを読むことなどの座学と実際にAWSを動かしてみる実践のいずれかまたは組み合わせによって得られたインプットから生み出されていると考えられます。
そして、AWSドキュメントはAWS公式のコンテンツなのでインプットとアウトプットの両方でその確度の高い情報を活用することができるため、アウトプットの参考元や根拠としてよく参照されることがあります。
AWSドキュメントを主体的に自立して読む習慣ができれば、確度の高い情報をインプットし、それを根拠にしたAWSサービスの実践やアウトプットをすることができるようになり、そのインプットとアウトプットの繰り返しがAWSを主体的に自立して学習する習慣に繋がります。
AWSドキュメントはHTML、PDF形式で無料公開されている
あと、単純なことですがAWSドキュメントはインターネットに接続できれば誰でもどこでも必要なときに必要なだけ読むことが可能です。
提供されているAWSドキュメントの形式はHTML、PDFなので移動中の電車内や何かの待ち時間でもPCやスマートフォンからすぐにインプットを開始できます。
非常にシンプルですが、AWSドキュメントを好きなときに見れるということはAWS認定取得、ブログ投稿、書籍執筆など学習目的を問わず、AWSを主体的に自立して学習する習慣の継続を強力にサポートします。
参考：
Welcome to AWS Documentation
Tech Blog with related articles referenced
まとめ
今回は私が推すAWSサービス「AWSドキュメント(AWS Documents)」を読むことが各個人の主体的で自立したAWS学習を最も効果的に促進するという話を中心に思いの丈を書きました。
記事の中で抽象化と具体化についての考えを書きましたが、「文章」というものは非常に抽象化と具体化の自由度が高いです。
個人的には極力すべてのことを文章で表現できることが理想だと考えており、私のブログ記事は基本的に文章(およびプログラムコード)中心で構成しています。
ただ、図表を完全否定する立場ではなく、IT分野で複数のエンティティ同士が関係し合うフローやその時間的変化すべてを文章で表現することは膨大な文章量と時間の浪費となるため必要十分性を考えた上で図表を使用するようにしています。
ましてデザインの分野となると文章の限界を感じています。
しかし、文章の抽象化と具体化の自由度を活かせる内容はたとえ文章力が未熟でもその力を磨くために文章化してアウトプットをするようにしています。
文章は自由度が高い一方でコントロールも難しいですが、それを理由にした安易な図表の使用は避けるようにしているのです。
こうした自身の文章に対する考え方のヒントになったのもAWSドキュメントの構成や記述スタイルでした。
さて、最後にAWSドキュメントに関して一つだけ注意することがあります。
前述した内容で「AWSドキュメントはAWS公式のコンテンツなのでインプットとアウトプットの両方でその確度の高い情報を活用することができる」と書きました。
この中で「確度の高い」と表現した理由はAWSサービスそのもののアップデートが非常に早く頻繁にあるため、AWSドキュメントの内容が追いついていない場合があるからです。
私も実際にAWSサービスを実行した内容とAWSドキュメントの内容が異なることを見つけたことがあり、AWSサポートに問い合わせると内容が追いついていなかったということが何回かありました。
特にAWSドキュメントの日本語表示の場合には翻訳の関係でよくあることなので基本的にAWSドキュメントは英語表示で読んだほうがいいでしょう(日本語で読みたい場合はAWSドキュメントを英語表示にした上でブラウザの翻訳機能等を使うのも良いと思います)。
そして、サービスアップデートから暫く経っても英語表示でAWSドキュメントの内容が実際のAWSサービスの動作と異なる場合はAWSサポートなど何らかの形でAWS側に伝えたほうがAWS利用者全体のためにも良いと思います。
ただ、例え稀にこのようなことがあったとしても私のAWSドキュメント推しは変わりません。
理由は多少の記載内容の相違が、この記事で説明したようなAWSドキュメントの有意義性を覆すほどのインパクトではないからです。
私はこれからもAWSドキュメントをAWSを主体的に自立して学習していくための軸として活用していこうと思います。
おまけ
今回はAWSドキュメントを推しに推したものの、以下が今まで私が推してきたAWSサービスの遍歴です。
Amazon EC2→Amazon S3→Amazon Route 53→Amazon CloudFront→AWS Lambda→AWS CloudFormation→AWS CDK→AWS Step Functions→AWS CodePipeline→AWS Amplify→AWS Systems Manager→AWS Documents(←今ここ)
※過去推しのサービスを再び推すようになった場合を除く
正直な所、その時その時で活用機会が変化するので、なかなか一つのAWSサービスの推しで居続けることができないんですよね。
次はどのAWSサービスを推すのでしょうか。。。
