筋トレの記録のはずが

筋トレの記録をつけるはずが、エンジニアとして技術的なこととかを書いてしまうブログ。

AWS Certified Developer - Associate合格のために何やったか書いておく

 以下の本の問題と、AWSが公開している模擬試験をひたすら解き

サービス別資料 | AWS クラウドサービス活用資料集

を最後は見るということで1発合格でした。

 

f:id:toda-chan:20210801190815p:plain

AWS合格証

自分がインフラエンジニアじゃなくてサーバーサイドのエンジニアだったからか、2回落ちたAWS SAAよりかは優しかったです。

これで、 AWS SAAと合わせて2冠目。

Webエンジニアが日商簿記2級受かったので試験の難易度や何をやったのかまとめておく

日商簿記2級受けようと思った動機

・ある程度の年齢いくとPL読まされるようになったから。それと、PLやBS読めないと、やばいWebサービスの施策を止められないため。

楽しいことなんてコストも迷惑もかからんかったら勝手にしたらいい。なんだけど、ヤバいものを止めるのにはロジックが必要で、そのロジックの一つとして簿記は使えそうな気がした。特にサービスの持続可能性の観点から、簿記は使えるんじゃないかと。倫理やモラルや教養がない奴に倫理やモラルや教養でヤバいものを止めようとしても無駄で、コスパの方が説得力がありそうに思った。

エンジニアはPLもだけど、BS読めるようになった方がいい。普段負債って言ってる技術的負債って具体的に何よ?とか、じゃあWebサービスにとっての資産って何よ?って話とか、これは研究費として費用計上の方が良いんじゃね?とか。

そんな感じで色々エンジニアとして会社のお金のことに関しては考えることがあったので、その謎を解き明かすために(以下略

 

日商簿記2級の勉強期間

・約4ヶ月の間、土日祝日勉強してました。そこそこ長い。正月休み潰れました。

 

ネット試験?ペーパー試験?

・ネット試験2回目合格です。1回目は試験問題を解く時間の配分ミス。最初に絶対、どの問題が解きやすいかどうか、ざっと問題を全体的に見ましょう。散々問題集で言われている地雷問題の配分が、ネット試験とペーパー試験では違う気がする。そこは個人差?

 

難易度

・早起きチャレンジがある応用情報処理取るよりかは優しくて、AWSソリューションアーキテクトアソシエイト取るより難しい。あと、簿記3級のペーパー試験よりは優しいような。しかもペーパー試験だと、金額のカンマや桁間違えるとか気が付きにくいけど、ネット試験だと、金額のカンマが自動で入ってくれるので、字が汚い民族としてはかなり助かる。

 

勉強したこと

 ・以下の2つのテキストで勉強した後は、ひたすら過去問を解く。

 

 

 

資格取ってみた感想

・取って良かったと思う。前述した動機が満たせたのに加えて、特に商業簿記だけでなく、工業簿記の考え方はPMにないとまずいって思った。PMなるつもりしばらくないけど。コストは削るものではなくて、業務プロセス含めて設計するものだって考え方は工業簿記に近くて、単純にPLだけ見てたらよく分からないと思う。

そもそもDDDで表現するドメインってどうやって勉強してるんですかね

 掲題の件、多分ビジネス書じゃだめなんですよ。

 

この手のやつ。 

業務別データベース設計のためのデータモデリング入門

業務別データベース設計のためのデータモデリング入門

  • 作者:渡辺 幸三
  • 発売日: 2001/07/01
  • メディア: オンデマンド (ペーパーバック)
 

 

グラス片手にデータベース設計 販売管理システム編 第2版 (DB Magazine Selection)

グラス片手にデータベース設計 販売管理システム編 第2版 (DB Magazine Selection)

  • 作者:梅田 弘之
  • 発売日: 2016/02/09
  • メディア: 単行本(ソフトカバー)
 

 

――システム構築の大前提―― ITアーキテクチャのセオリー

――システム構築の大前提―― ITアーキテクチャのセオリー

  • 作者:中山 嘉之
  • 発売日: 2018/06/10
  • メディア: 単行本(ソフトカバー)
 

 

プログラミング自体より、ドメインがどう進化するかで設計迷うわけですよ。脳みそとろける感。

 

詳しい人に話を聞いたらわかるし出来るレベルじゃないんですよ。現場も実は詳しい人いなくてなんとなくやってるとか、それはやったらあかんことお願いされるとか。例えは、伝票は上書きしたらあかんのやで...月をまたいだ会計と合わんようになるだけちゃうんやで、というのをエンジニアが止めるとか。こんな感じで、エンジニアが、単純に儲かれば何してもいいわけじゃないという文化を作ることを意識して、それをコードに落とすこともあるわけですよ。そういうのって、会計の本読むことも必要なんですけど、それだけじゃないもの求められて脳みそ溶ける感。

 

あと、中小企業診断士とかリテールマーケティング検定(販売士)とかに関連した本はSKUのSも知らなかった人間なので、ドメインに関する会話でわからなかったことがあったときに、辞書みたいに引いてる。脳みそとろける感。

 

で、こういう記事もね。実務で異常系対応の地獄とか。

https://shiodaifuku.io/articles/%E6%B1%BA%E6%B8%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E4%BD%9C%E3%82%8B%E3%81%BE%E3%81%88%E3%81%AB%E3%81%93%E3%82%8C%E3%81%A0%E3%81%91%E3%81%AF%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%93%E3%81%86

普通にwebサービス作ってきた人と、決済系やってきた人とでは、異常系の想定が違いすぎて、わちゃわちゃするんですよね。信頼でなんとかするものと、事業に必要な安全安心を守るために必要なものとでは違うっていうのをすり合わせるので大変だったり。

 

人間、激務で疲弊するんじゃなくて、こういう倫理的な対策が現場の俗人的なことに疲弊するんで、信頼も安全安心を守るためには、システム的な対応は必要なんですよ、って話を落とすのに大変なんですよ。システムサイドとしては、人間を危険な場所に置きっぱなしにすると、オペレーションも事業進捗も遅くなるんですよ、事故の処理対応で、って。

 

ドコモの事件とか他人事じゃないですね。web屋さんと決済やってきた人とではこの辺りのドメインすり合わせる時に、異常系想定増やすと、人信頼してないのかとか、そもそもそういう業務が出るのは何故か、それはシステムの責務じゃなくて窓口の責任、とかに話いきがち。でも、窓口でも止められないという現実の業務に関するすり合わせむずいなーって。窓口守れなくて、窓口を危険にさらしてしまうのはシステムの問題でごめんね、とか。

 

個人的には、技術単体より、ドメイン自体の学習とすり合わせの方が大変だなって感じがしますね。

 

LaravelでDDDするときに参考にする本

 これの他に何があるのか知りたい。

この本は、DDDも良かったけどTDDを最終章で紹介してたの良かった。