とても大切なことを書いている文章だったので、特にエンジニアの入り口に立って歩き始めた方々には読んでいただきたい。
公式ドキュメント読めば5分で解決することで5時間もGoogleとにらめっこするな
なかなか言葉がぶっきらぼうで荒い感じにはなっているので、ちょっとむっとしてしまう方もいるかもしれません。
また、特にエンジニア一年生に公式を読め、といっても公式ドキュメントはなかなかとっつきにくい文章になっているのも確かです。
それでも、読もうとしなければずっと読まないままになってしまいます。まず、読もうとするということを決しておろそかにしないでほしいのです。
これは開発系のお話をされていますが、我々インフラストラクチャやバックエンドでも同じことが言えます。
特にインフラではこの言葉が飛び交います。
「RFCはどうなってる？」
もう伝家の宝刀です。RFC、つまりRequest For Comments。IEFEによるプロトコルやデータの標準化意見書です。ネットワークを取り扱う上で、RFCを避けて通ることはできません。
アプリケーション開発が、「メールアドレスの登録フォーム作って、メールアドレスをDBにストアするとき、必要となるmailaddressカラムの文字上限はまあ255文字でいっか」みたいな感じで作ったメールアドレスフォームは、いつか破綻するのです。
もちろん、正規化して255文字以上をフロントエンドが受け付けなければシステムとしては破綻しません。
ただ、そうだったとしても。
今度は逆に、存在して、実際に利用できるメールアドレスなのに登録できない、というクレームが発生しうるのです。
メールアドレスに使える文字種、@移行のドメイン部についての定義、ファイルのフォーマット、httpやssh、TCP/IPのプロトコル仕様、とにかくインフラに関する標準化はRFCを軸にしています。そして、このRFC、読みにくさで言えば慣れていないとほんと読みにくいと思います。
あれはいわゆるアプリケーションやフレームワーク、言語仕様やライブラリの公式ドキュメントの比ではありません。
クラウドファーストにおいて、AWSやGoogle、Azureなどを利用する際にも、この公式を読む、という癖があるかないかが大きな差異をもたらします。AWSを例にとれば、AWSの公式ドキュメントはとんでもないレベルで大量の情報の塊です。あそこで解決しないものは、どれほどGoogleに問い合わせてもまず解決しません。
AWSには、いわゆるチュートリアルドキュメントをはじめとし、一般の利用形態向けのドキュメント、API仕様書といった一般技術ドキュメントに始まり、膨大な量のソリューションサンプルをも提供しています。
皆さんがこんなことできるといいな。とか、あんなことをしたい。と思ったことの大半は、実はもうソリューションサンプルとして作られていて、それはAWSのドキュメントの中に転がっているのです。
それだけではなく、AWSのblogもバカにできません。
ちょいちょい、「こんなもん作ったぜ」という記事がアップされ、サンプルのgithubのリンクが提示されます。リンク先はCloudFormationのテンプレートスタックになっていることが一般的で、そのままcloneしてbuildしたら構築され、動作が検証できます。CloudFormationさえ読めるなら、何をすればよいのか、一目瞭然なのです。
問題は膨大すぎるのと、ドキュメントリンクがまとまっていなくて求めているドキュメントにたどり着くだけでも一苦労、という点を除けば、大変素晴らしいものです。
Qiitaなんかに聞いたところでしょうがないのです。決して利用しないわけではないですが、一次情報がそれだけ充実しているのに、二次情報三次情報にあたってもしようがありません。そんなものを読む時間があるなら、公式を読む努力に時間を使うべきなのです。公式の内容を理解する補助として、二次情報や三次情報にあたるべきだと思うのです。
読む努力さえ続けていれば、ある日突然、なんか読めるようになってしまいます。そして、公式ドキュメントさえあれば戦える気分になる時が来ます。
私はTerraformを愛用していますが、TerraformやAnsibleも公式ドキュメントを読むのが基本ですね。というか、むしろそれ以外で読むものといえばGithubのサンプルコードくらいです。特にTerraformはアップデートが早いので、ほんの数か月前のQiitaの「これがお勧め！」なんて記事を読んだところで、今のバージョンのそれと合わせたときにTerraformからこんなことを言われるのです。
「その機能次くらいで廃止予定だから修正しとけよ」
もしくは、何も言わず動いてくれますが、実はもう新しい機能がリリースされていて、もっと簡潔に書けるようになっていたり、スマートに書けたりするようになっていたり。
公式ドキュメントは、決してアンタッチャブルなドキュメントではありません。読みにくい、あるいはとても難読であるケースは多々ありますが、技術文書とはすべてそういうもので出来てしまっています。もちろん、とても読みやすいケースもありますが…。
それを理由に読まない、あるいは読むべきではないというのはあまりにも暴論です。
我々はエンジニアです。
エンジニアとしてプロとして、仕事を行います。
ですので、エンドユーザーに向かって「公式ドキュメントを読め」などとは言いません。そんなこと言えるはずもありません。彼らはプロではないですし、彼らは我々がそれを彼らに代わって行ってくれるから、我々をプロとして依頼し、信頼してくれ、そしてそこに価値があると考えるからこそ、お金を支払ってくれるのです。
だからこそ、同じエンジニアに向かっては言いいます。プロでなければならないと考えますし、そうあるべきだと思っています。
価値のない仕事を積み重ねてしまったら、失われるのはそのエンジニアの信頼だけではありません。
そのクライアントは、エンジニアというものを、業界そのものを信頼できなくなってしまいます。
だからこそ、そういう仕事の積み重ねをしてしまっている人には、思わず言いたくなってしまう気持ちは、なんとなくわかります…。
あとこの人の他のnote読んで、ああ、言葉荒っぽいけど真面目な人だなぁ、と思いました。
