Add eslint-disable for set-state-in-effect as a temporary workaround

Author: kimkim0814

package-lock.json

@@ -0,0 +1,141 @@
+---
+title: 【新人プログラマ応援】インフラに詳しくない僕が3週間でSAAを取得した方法 【SAA】
+tags:
+  - AWS
+  - ポエム
+  - 資格
+  - saa
+  - 新人プログラマ応援
+private: false
+updated_at: "2024-06-05T12:17:54+09:00"
+id: 014c8f26ffe16f1381ed
+organization_url_name: qiita-inc
+slide: false
+ignorePublish: false
+---
+
+## はじめに
+
+2022年9月にAWSのSAA(AWS Certified Solutions Architect - Associate)を取得したので、インフラに詳しくないエンジニアがわずか**3週間**でどのように合格をしたかをまとめようと思います！
+
+~~C02からC03に変更になり難易度もやや上がり範囲も増えたので当時は
+なんで後１ヶ月早く受けなかったんだろうと悔やんでいました~~
+
+資格に至った経緯としては、同年の6,7月頃からAWSを触る機会が増えてきたので
+まずは基礎を固めるために取得しました
+
+当時の筆者のスペックとして
+
+- エンジニア歴がちょうど2年弱
+- phpとvue.jsを用いたwebアプリケーションの開発がメイン
+- インフラについてはITパスポートレベルの知識のみ
+
+といったレベル感でそもそもAWSの知識も乏しく、インフラも詳しくありませんでした。
+
+## 勉強時間について
+
+基本的には平日は1日1時間、休日は2時間程度でテスト前日8時間と当日の朝に4時間
+といった形で良くはないですが所謂大学のテスト対策のようなカリキュラムで行なっておりました。
+
+合計の勉強時間は40時間弱ほどです。
+電車や病院の待ち時間なども上手く活用しておりました。
+
+どんな勉強法、学習ロードマップで取得したか気になりますよね?
+今回は**最短**でSAAを取得する学習ロードマップについて説明していきます。
+
+## そもそもSAAって?
+
+AWS Certified Solutions Architect – Associateの略称のことです。
+AWSの知識やスキルを認定する資格試験となっており、試験時間は130分で問題数は65問で選択式となっております。
+
+内容としては以下の通りになります。
+|分野 |出題の比較 |
+|---|---|
+| セキュアなアーキテクチャの設計 |30%|
+|弾力性に優れたアーキテクチャの設計 |26% |
+|高パフォーマンスなアーキテクチャの設計 |24% |
+|コストを最適化したアーキテクチャの設計 |20% |
+|**合計** |**100%** |
+
+## 学習ロードマップ
+
+概要から説明します
+
+1.何かしらの入門書を1週する
+2.Youtubeで学習する
+3.Cloud Techで問題集を解く
+4.Udemyで模擬問題集を解く
+
+正直言って、**資格に合格する**という観点だけで見ればハンズオンの方は一切やる必要はありません😇
+ですが、知識だけのインプットを行なっても実務で役立てにくいかなと思うので
+業務でAWSを触る機会or予定がある方はハンズオンも並列して進めることをおすすめいたします。
+
+自分は、資格勉強期間はハンズオンは極力せず(取得後にした)に
+勉強期間中はテストに出そうな部分は記事などにまとめてアウトプットするくらいでした。
+
+https://qiita.com/kim_t0814/items/215e82f4873149db6f6b
+
+### 1.何かしらの入門書を1週する
+
+いきなり過去問を解いたとしても、そもそも問題文の単語の意味がわからなければ
+過去問を解き答え合わせをしても何の定着もしません。
+
+自分はちょうどC02からC03の移行期間で受験したので下記の教材を使用いたしました。
+
+https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88-%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88-%E6%94%B9%E8%A8%82%E7%AC%AC2%E7%89%88-NRI%E3%83%8D%E3%83%83%E3%83%88%E3%82%B3%E3%83%A0%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE/dp/4815607389/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3TWV9AZYBU9BA&keywords=saa+aws&qid=1681962485&sprefix=saa+aw%2Caps%2C163&sr=8-2
+
+### 2.Youtubeで学習する
+
+資格試験においても動画教材は自分的にはめちゃくちゃおすすめです。
+メリットとして
+
+- 概要を網羅的に覚えることが出来る
+- 文字より音声込みの方が頭に入る(特に自分は)
+- 電車の移動時間中に学習しやすい
+
+### Youtubeおすすめ教材
+
+##### ・ AWS ソリューションアーキテクト アソシエイト試験 対策動画
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/fsz6G45A4H4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+Udemyの講師でもあるMaruchinさんが無料で出しているYoutubeの教材になります。
+何本か他の動画も見ましたが、こちらの動画が **テストでよく出る範囲を網羅** しつつ **短時間(1時間50分弱)** で学習することができます。
+Udemyの講師だけあって、かなり分かりやすいです。
+テスト前日の復習にもおすすめです。
+
+## 3.Cloud Techで問題集を解く
+
+1と2を取り組んだら大体の基礎知識はついていると思います！
+自分はその後に、Cloud Techの問題を1~200まで3周ほどしました。
+
+ポイントとしては1度に沢山解くというよりは、10問単位の小テスト形式にして9点数以上取るまでは
+次に進まないという形式を取っていました。
+
+問題集の効率の良い学習方法はCloud Techの運営者である黒川さんの動画で詳しく説明されております。
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/lJTh8n_q3Zw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+## 4.Udemyで模擬問題集を解く
+
+【SAA-C03版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）
+
+https://www.udemy.com/course/aws-knan/
+
+自分が受験した際はSAA-C02版での学習でしたが、C03に改訂後も変わらずおすすめとなっております！
+自分は演習試験の方を2-3往復ほどして、通常難易度の方は9割弱取れるようにして高難易度のものは
+8割ほど取れるようにしました。
+
+正直、高難易度のものは**試験の本番よりも難しい**です。
+
+テスト3日前に初見では4-5割ほどしか取れなかったので
+高難易度に関しては、初見で720点を切っても本番よりも難しいので諦めないでください！
+
+## 最後に
+
+今回は未経験の方やインフラの知識が無い方を対象にSAAの学習ロードマップを紹介しました。
+SAAはAWSの中で最も人気な資格ですし、インフラの知識が無い方でも勉強すれば取れる資格かなと思います。
+
+最初のうちは殆どがわからない単語だらけなので、過去問を解く前に最低限のインプットすることも頭の片隅に置いておいてください。
+
+SAAの勉強方法が分からない方の役に立てれば嬉しいです。

public/.remote/014c8f26ffe16f1381ed.md

@@ -0,0 +1,138 @@
+---
+title: 【第1章】要求を仕様化する技術・表現する技術 【要件定義】
+tags:
+  - 読書
+  - 本
+  - 設計
+  - 仕様
+  - 要件定義
+private: false
+updated_at: "2024-12-25T15:17:19+09:00"
+id: 07826324801ef80ca977
+organization_url_name: qiita-inc
+slide: false
+ignorePublish: false
+---
+
+## はじめに
+
+ここ最近、仕事で要件を考える、擦り合わせるという機会が増えてきており その重要性を改めて実感しています。
+
+設計が決まっているものをただ、実装する能力は身についている一方 要件定義や仕様書作成の能力が まだ足りないと感じることが多かったので今回は備忘録として「要求を仕様化する技術・表現する技術」で自分が覚えておきたいポイントをまとめていきます。
+
+殴り書きの側面が強いかもしれませんが、ご容赦ください。
+
+## 第１章
+
+大きなシステムでは、5000件を超えるようなバグが発生することもある。
+そのバグを修正するためには数万時間にも達するとのこと、時間にすると1人の作業員の10年分にも相当する。
+
+ここで注目したいのは、バグの過半が、**要求仕様に関連するもの**ということ。
+
+### 1.1 どこで問題が発生しているか?
+
+- バグなどの "エラー" の原因プロセス
+  - 5:3:2(仕様:設計:実装) の割合でプロセスエラーが発生している
+- 設計者テストが十分にできているところでは...
+  - 7:2:1(仕様:設計:実装) の割合でプロセスエラーが発生している
+- 実装上の仕様を設計の中で決めていくという考え方を変える必要がある
+  - 変えていかないと、派生開発での変更モレが起きる
+
+自分のイメージだと、 3:3:4(仕様:設計:実装)の感覚でした。
+ここから見るに、要件定義が重要ということがよくわかると思います。
+
+### 1.2 要件仕様のトラブルの実態
+
+- トラブルのケースは以下のようなものがある
+  - 要求していた仕様が実現していない
+  - 途中で変更を指示した部分が十分に調整されていない
+  - 仕様のモレが次々と発見されて、テストがまともに進まない
+- 仕様漏れ
+  - 仕様として記述するのが漏れてたために、対応するソースコードが書かれなかった状態
+  - 例えば...
+    - 本来なら受け取ったところで、必要な項目をチェックして問題ないことを確かめてから使用すべきだったがされていなかった(チェックすることが仕様書に書かれていなかった)
+    - そのまま数値を計算したところ累積データに異常な値が更新されてしまった
+- 解釈に違い
+  - 単純な仕様漏れと比べて、複雑である
+  - 例えば...
+    - 顧客(要件を出す人)と設計者の間での解釈の違い
+    - 設計者同士の認識の違い
+- 仕様の衝突
+  - 個々の機能で必要または有効と考えられる仕様をすべて実現しようとすると、異なる機能のいくつかの仕様間で衝突するという状態
+  - 早い段階で全体の仕様化を進めないと防げない
+
+### 1.3 曖昧な状態で作業に入っている
+
+- 構造が傷ついていく
+  - 現場では、「納期に間に合わない」という圧力がかかる
+  - 強引に送信のタイミングを遅らせたり、データをグローバルで参照したり
+    - 結果、プログラムの構造が崩れていく
+- 潜在バグの意味
+  - 潜在バグとは、今回自分が埋め込んだバグではない、前の人が埋め込んで発見されないままになっていたのを"たまたま" 自分が掘り出してしまった
+  - 潜在バグとして、分類した瞬間原因を踏み込んで探すことがなくなってしまう
+    - 次の担当者に向けた潜在バグを**仕込む** ことになる
+
+### 1.4 顧客からの仕様変更
+
+- 仕様の変更率が **50%** を超える組織もある
+  - 設計者がプログラムのコーディングを進めていく中で仕様な曖昧な箇所に遭遇
+  - そこで、依頼者に質問メールや確認のメールを発して仕様変更へ...
+- 最後になって機能に制限がつく
+- 担当者も、ソースコードには「具体的な仕様」が必要になり、「具体的な仕様を見つける目」になっている
+
+### 1.5 要求した機能を満たしていない
+
+- 要求を満たさない最大の理由
+  - 1.「要件仕様書」が「仕様」といえるレベルに達していない
+  - 2.完成品として含まれるべき 「品質要求」も記述されていない
+  - 3.関係者が、その不十分さに気づくためのスキルを持ち合わせていないこと
+
+関係者が、仕様書の不十分さに気づかない、仕様と呼ばれるレベルに達していないことはよくある事象ですね。
+
+### 1.6 納期の遅れとなって表面化する
+
+- 要件の仕様化が不十分だと、"予定通り"に設計工程に入っても何をやれば良いかわからない
+  - 結果として、**設計作業** が進まなくなる
+- 何度も作り直している
+- 仕様には設計方法を `誘導`する力がある
+  - 仕様によって設計する際のデータ構造の選択や処理方法が決まっていく
+
+### 1.7 品質要求に応えられないSE
+
+- 保守性要求に居直るソフト会社
+  - 「品質要求」を加えた顧客に対して、追加で料金をもらおうとする
+  - 家を建てる際に、`使いやすさ`を要求して追加料金を請求された
+  - それでいてコピペで3000行にも達するプログラムを平気で作ってしまう...
+- 品質要求を課さなかった発注側にも責任はある
+
+### 1.8 派生開発での仕様トラブル
+
+- 派生開発はトラブルが多い
+  - 逆にいうと、派生開発の中でこそ、**要求の捉え方と仕様化の能力が試される**
+- ソースから仕様を理解できるか
+  - 人のソースコードを読んで、要求の具現化の様子や設計の理解には、相当の修練と適切な経験が必要c
+- 変更要求(仕様)が表現されていない
+
+### 1.9 設計書が省かれてしまう原因になっている
+
+- 要求仕様書がうまく書かれない原因
+  - 「適切な設計書」が書かれていない
+- 設計レベルの仕様と混同
+  - 「設計仕様書」として書かれている
+    - 設計書に仕様が捕捉されている
+  - 仕様書と呼ばれるものが複数ある
+
+## まとめ
+
+いかがでしたでしょうか。
+
+「仕様のモレが次々と発見されて、テストがまともに進まない」 というのは、皆さんもあるのではないでしょうか。
+
+自分も直近のプロジェクトで、要件定義が甘かったために、後戻りが多くなり、実装が進まないという状況になってしまいました。
+特に、仕様を決めた後に実装を進めてる最中に仕様が曖昧なところを見つける(見つけてもらう)という部分に近いこともありこの本の内容は非常に役立ちそうだと感じました。
+
+単純に実装するスキルもそうですが、自分のためも兼ねて2章以降もまとめていきたいと思います。
+
+## 参照
+
+https://gihyo.jp/book/2010/978-4-7741-4257-9