AWSの認定資格は新人が取得する必要はない～アソシエイトでも・・

とうとう時代の流れなのか、がっつり仕事でAWSを使う機会が到来。

基礎的な研修を受けて以来触っていないので、改めて勉強することに。

↓研修の感想は以下参照↓

以前から、資格はあったのが、最近になって知名度も上がり受験する人が増えているようだ。その証拠に、「AWS認定ソリューションアーキテクト」の参考書が結構な数発売されている。(一時期流行ると噂され、噂に終わったOSSDBとは大違い。。。)

そこで、AWSの勉強しつつ、資格も取ろうということで、以下の参考書を購入。

<Amazon Web Services エンタープライズ基盤設計の基本>

この参考書は読みやすく、初心者でも非常に参考になる。

が、この本を読んで

AWSの認定資格は、

• 勉強して身に着いたことを確かめるための資格

であり、闇雲に勉強して取得しても何も意味がないのではないか？と強く感じた。

IT系の資格は自動車免許や宅建などと違い、取得することにあまり意味がない傾向が強いが、よりその傾向が強いってのが率直な感想である。

新人や基礎ができていない若手におススメしない理由にも紐づく。

■理由①：OS/NW/DBなどの基礎知識がないと理解が深まらない

クラウドといっても、ベースとなるネットワークやOSはオンプレと考え方が変わらない。自動で設計をしてくれるわけでもないので「どう構築するか」の設計は従来通りやる必要がある。

例えば、ネットワークの基礎知識がないと、セグメント分けなどがよくわからないまま構築を進めてしまい、AZ(アベイラビリティゾーン)の仕組みをうまく使いこなせない可能性がある。極端な話、同一AZに構築してしまい、当該AZが落ちた時におじゃんになってしまう。ってこともありえなくもない。

おっさんの小言かもしれないが、

ある程度「基礎知識や歴史」を知っていないと、その機能がある背景や本質が良くわからず、ひたすら横文字(ELB、EC2、EBS、DynamoDB etcetc)、及び、問題のパターンの暗記に終始してしまい結局、テストの次の日にはすべて忘れてしまうってオチになりかねない。

(今後革新的な技術が台頭したら、基礎や歴史は不要になるが、直近20年はそんなことは起きないと予想。)

■理由②：ITの基礎知識が身に着かない

• 情報処理試験なら試験区分の分野、CCNAならネットワーク、Oracleならデータベース、LPICならオペレーションシステム

といったように、勉強することで、多少なりとも使い勝手がよい共通的な基礎が身に着く。しかし、残念ながら、AWSの資格では汎用性の高い基礎知識は身に着かない。

ITのベース知識習得を目的にしているのであれば、すぐに勉強対象を変更した方が良い。難易度の割に身に着くものが小さい。

ここまでネガティブなことばかり書いてしまったので、ここからはポジティブなことを！！！！

あくまでおススメしないのは、基礎ができていない人であり、基礎がしっかりしている人には非常に有効な資格である。

• オンプレ構築で苦労したことが数回のクリックで実現できる感動
• あふれ出てくる活用イメージとわくわく感

勉強していて楽しく感じられる数少ない資格なのでは！？

次回ちょっと時間を見つけて勉強方法や難易度を解説します。(´・ω・`)(´・ω・`)

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

良書：『ソフトウェアシステムアーキテクチャ構築の原理』の読破を目指して

システムのアーキテクトを名乗るなら、読まなければならない本。それが、

• ソフトウェアシステムアーキテクチャ構築の原理　第2版

• ITアーキテクトの決断を支えるアーキテクチャ思考法

• ニック・ロザンスキ、オイウェン・ウッズ　著

• (榊原　彰　監訳　牧野祐子　訳)

だそうだ。一応これを教えてくれた人は、アーキテクトとして尊敬できる方だったので、モノは試し読んでみることに。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

 第一の壁（本の値段が高い）

なんと定価が5200円。しかももう新規に出版されていないのか、amazonでは単行本はプレミア価格になっており、値段が倍近くに・・・(Kindle版は5040円で売っているが、電子書籍はおススメしない。次の章でその理由は解説。)

メルカリやヤフオクで探した方がコスパは良いかもしれない。

この手の値段が下がり辛い専門書系は、メルカリで買うのが一番おススメ。少しは値切れるし、何よりたまにびっくりするぐらい相場と比較して安く売られている時があるからだ。（価値がわかっていないのか、すぐに手放したいのかは不明）

第二の壁（デカイ、重い）

普通の単行本よりも大きいため、手軽に読めない。(Kindle版をおススメしない理由がこれ。iPad Proレベルの大きさだったらよいが、普通のスマホでは読めないと思う。)

ページ数も600以上あり、分厚い。電車で立って読むのは不可能。鞄に入れると、筋トレになるのでは？って感じるぐらいの質量になる。

なんとか壁を乗り越えつつ、読み進めているが、本の大きさと質量が邪魔をして中々進まない。他の本や参考書に浮気しつつ、ゆっくり読み進めることに。

ざっくりとした感想は、

文字が多く、日本語訳が？？？ってなるときもあるが、印象に残る内容は結構ある。

せっかくなので、この本に興味？を持ってもらえるように少し紹介してみる。

• architecture descriptionは、stakeholderが理解できなければならない。

→おっしゃるとおり。パワポ一枚に綺麗にまとめることがゴールではない。理解させる工夫が大事。ただし、あまりにもdocumentを読まない人が多すぎる。いくらいいい設計、計画書を作っても「当事者意識を持って真剣に読んでくれる人」がいなければ、その価値は9割減。

• 複雑なシステムの機能的特徴と品質特性を、そのステークホルダーに理解可能かつ価値のあるような単一のモデルでとらえることはできない。

→一枚紙信者に是非訴えたい。一枚で表現できないものはこの世にいっぱいある。ちゃんとカテゴライズして、必要な資料を作るべき。資料だけではなく、デモや映像によるモデルの表現をしてもいいのでは？

↓以下は浮気タイム↓↓

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド　より

• 要求分析者が実装困難な要求を出してくる。

→ビジネスアナリストにろくな人がいないのは、全世界共通なのか？？自身の経験的には内部外部含むビジネスアナリスト(BA)と呼ばれる人と一緒に仕事をしていい思いをしたことはない。職業病なのかトラウマなのか、名刺にビジネスアナリスト的な役職、役割が記載されていたら、反射的に身構えてしまう。非常に申し訳ないのであるが、、、

• 健全な技術チームであることの一番の兆候がリリース頻度の高さ

 →この考え、広めたい！！！

アジャイル、DevOps、高速開発etcetcの流行り言葉は、結局は「一秒でも早くリリースすること」が目的。この目的さえちゃんと認識できていれば、急にアジャイルを導入するといって現場を乱したり、DevOps実現するとかいって使いもしない高額なツールを購入したりすることはないはず。アジャイルやれば高速開発できると考えている、お花畑な人たちに、ひたすら音読してほしい。新しいことやる前に、先に既存のプロセスで改善、廃止することあるでしょ。誰も何もしゃべらない、止めない、無関心を装うガバナンス対応とか、ガバナンス対応とか、ガバナンス対応・・・・

次回に続く、、、(´・ω・`)(´・ω・`)(´・ω・`)

その次回はいつになるのやら。( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)

プログラマー／SE／コンサルタントが使えそうな用語集～Part1～

最近、働き方改革！？の効果を実感してきた。明らかに、数年前よりは帰る時間が早くなっている。そして何よりも、上司、クライアントの意識が変わってきた。

• 徹夜してまでやれ
• 土日使ってでもやれ

といった、無理難題を押し付けられる機会も相当減った。テレビなどでは、有休休暇の取得が義務化されても、

• そんなの無理だ、有休なんて取ったことがない、長時間労働が改善されない

等々ネガティブな意見もあるが、少なくとも、私の周りは変わってきているのは事実。

お陰で時間的なゆとりができてきたので、本を読む機会が非常に増えた。本を紹介するとだらけてしまうので、気になったキーワードを解説／紹介したいと思う。

普通のサラリーマンでもできる! 「週末コンサル」の教科書

＋＋＋＜ユーザーインサイト＞＋＋＋

・ユーザーの本質的な欲求や本音　

[使用例]

A：うーん何故、この商品は売れないのか。。

B：アンケートしてみれば？

C：いや、そんな上っ面をみてもしょうがない。大事なのはユーザーインサイトだ。Google Analytics などを使用して、売れてる商品と売れてない商品の導線の違い、サイト滞在時間などを分析し、ユーザーの本質的な欲求を明確にする必要があると思う。

＋＋＋＜アヒル曲線＞＋＋＋

・資源を3割削れば、成果はゼロ 

[使用例] 

A：システム更改をしたいのだが、コストリダクションの圧力が。。。

B：このままだと当初見積もりの5割でやる羽目に・・・

C：アヒル曲線の法則を考えると、そのプロジェクトの成功確率は限りなく0に近いね。資源を3割削られると、ほぼほぼ成果がゼロになるといわれているのに、5割も削られるなら、そのプロジェクトに絶対に携わらない方がよい。

＋＋＋＜喜捨＞＋＋＋

・その名の通り、喜んで捨てる。

[使用例]  

A：マイナンバーポータルってまったく利用されてないんだって～

B：保守費とか維持費考えたら喜捨すべきものだよね。普通。税金で運営するっていいな。

＋＋＋＜技術的負債＞＋＋＋

・本来は資産とすべきソースコードなどが、年月が経つにつれてゴミと化すこと。

[使用例]  

A：このホストコンピューターに10万行のソースファイルがあるんだけどなんなに？

B：そんな知っている人がいれば、そもそも10万行になっていない。技術的負債やな。

＋＋＋＜マイクロマネジメント＞＋＋＋

・上司が部下に対して、些細なことでも口を抱いてくること。

[使用例] 

A：ちょめちょめさんってさ、メール一通、一通に文句いってくるよね。暇なのかね。

B：暇というか、不安なんだよ。確かにちょめちょめさんは仕事ができるかもしれないが、それと同じことを部下に求めてもね・・結果マイクロマネジメントになって、部下のモチベーションも下がるわで、誰も幸せになれない。

＋＋＋＜無意識バイアス＞＋＋＋

・無意識にバイアス(考え方や意見の偏り)をもってしまうこと

[使用例] 

A：僕が作った資料を、ちょめちょめに説明しても反論ばかりで何も進まない。ストレスだわーー

B：でも同じ資料をC君が説明したら絶対反応違うよね。C君ってちょめちょめにあからさまに好かれてるし。

D：そういうのって無意識バイアスっていうらしい。最近、外資系企業を中心に流行ってるって2ちゃんに載ってた。性格、要旨、人種、性別などなど、人は無意識に偏った判断をしてしまうらしい。ま、でもちょめちょめに嫌われるAは、自身にも大いにお問題があるともうけどね。平気でお客さんにはったりかますところとか。( ﾟДﾟ)

Part2に続く。。。

最近「カイゼンジャーニー」って本を読んだのだが、紹介したい言葉が多いので、気合入れて用語集をシリーズ化したい(´・ω・`)(´・ω・`)

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで