JSTQB Foundation Level合格体験記
はじめに
JSTQB認定テスト技術者資格のFoundation Levelに合格したのでどんな勉強をしたかをメモしておきます
受験のモチベーション
同僚が何人か受けてて興味を持ちました。テストについての学びが浅いので体系的な知識を獲得しておきたいと思い受験しました。
試験内容
JSTQBのWEBサイトに記載されているシラバスの内容が出題範囲となっています。 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Overview__Version2018.J01.pdf
1時間60問を解きそのうち65%以上正答で合格となります。
勉強時間
大体6～8時間程度かなと思います。期間としては２日ほど勉強をしました。
勉強方法
まずはシラバスに一通り目を通しました。
その後はテス友というアプリで一通り確認テストをしたのと、スクエアリングサービスというサイトで模擬試験の問題を解いたりしました。それ以外は特に何もしていません。
感想
もともとSIerで７年働いていたので一般的な開発プロセスの知識は保有していたことから、学習としてはそこまでつまずくことはありませんでした。また、出題内容も基本情報処理技術者試験に出てくる問題と似た問題となっていました。Foundation Levelなのでそこまで難しくはなかったなと感じました。逆にいえばこれらの知識はあくまで基本知識であり、これを学んだだけでテスト品質が担保できる様にはならないなとも思いました。
終わりに
今後はオンジョブを通してテストの理解を深め、Advanced levelにも挑戦して行けたらと思います。まずは何か資格を取りたい！と思っている方は、是非チャレンジしてみてください。
エリック・エヴァンスのドメイン駆動設計 1部を読んだ感想
はじめに
最近「モデリングがうまくなりたい」、「設計っていったい何なんなのかを知りたい」というところから、UMLモデリング・オブジェクト指向の勉強を経てドメイン駆動設計にたどり着きました。入門書をかじり始めたのですが、同僚から「まずはエヴァンス本の一番重要な第１部を読んでみてほしい」とアドバイスもらったので読んでみました。
読書のモチベーション
DDDのとは何か？を自分なりに理解したい。モデルの探求が出来るようになりたい。設計が出来るエンジニアへとステップアップしたい。
印象に残った箇所
以下、印象に残った部分を書き残しておきます。
UMLで会話していることにびっくり
ドメインエキスパートとＵＭＬで会話してんだな・・・そこまでここにもっていけるのがすごい。そもそもエンジニアでさえ、ＵＭＬ記法を理解している人は少ないと思う。かくいう私もこの前まで理解していなかったうちの一人でした。
旧来のウォータフォール型と今自分たちがやってるアジャイル開発との対比
- 「ビジネスエキスパートがアナリストに反し、アナリストがかみ砕き抽象化し、プログラマに伝える」
- この構図はめっちゃわかる。SIer時代はほんとこれでした。
- 「フィードバックループが無いから知識は一方向に流れるだけで蓄積されない」
- ドメインモデルはドメインエキスパートと開発者を近づけるもの
輸送業のモデルの例
- 元々は荷物のある場所を別の場所に移動する、その時の日時を管理する、ためのモデルを作ってた。よくよく来てると、実はいろんな会社が輸送には介在してて発注者が管理したい対象は日次ではなかった。
- 最終的には、各会社間での責任の移動を扱うモデルだった。
すごいあるあるな話な気がしました。モデルの本質を見極めることの難しさはここにあると感じました。
モデルを言語の骨格として使用すること
UML図で表現できないこと
- ＵＭＬ図はモデルの最も重要な側面のうち２つが伝えられない。自然言語を慎重に使用することで回避する
- モデルがあらわしている概念の意味
- オブジェクトが何を行うことになっているか
- ＵＭＬをプログラムを書ける技術として使うとモデルの意味そのものが失われる
いやー、これも分かる。目的・概念が重要なのにいつの間にか失われる。。。
設計ドキュメントについて
- XPはコードですべてを表現する。動作しているコードのふるまいにはあいまいなところがないから。
- すでにコードがうまくやってることをドキュメントでもやろうとすべきではない
- モデルは形式ばらないその場限りのもの
- これは今後意識していきたい。
XPも学ぶ必要がありそう（自分の理想に近そうな開発手法な気がするので）。
設計ドキュメントの持つ最大の価値
- モデルの概念を説明すること
- コードの詳細を書き進める上で役立つこと
- モデルで想定されている使用方法について多少の洞察を与えること
モデル駆動設計について
- モデルは一つに（分析と設計それぞれでモデルを作らない）。
- この記述はすごくすっきりする。今までＵＭＬを学ぶときに分析モデルと設計モデルが分かれていることに違和感を感じていた。 また、UMTPを取得した後、ついつい「設計のやり方の基礎が身につきました」と言って「あれ？身に着いたのは設計じゃなくてモデリングか？」みたいなことも感じてた。切っても切り離せないモノってことなんだな。
- 複雑なデータ型をサポートする言語は、ドメインにおけるより自然な概念との一致が見られ始めている。しかし、複雑なデータ型はデータをまとめたものでしかなく、ドメインの活動的な側面は捉えていない。
感想
自分の現在のエンジニアレベルを客観視した
私は2年前に転職しフロントエンジニア３年目なのですが、転職した時点では「Reactって何？」、「Typescriptって何？」、「オブジェクト指向ってあれでしょ、継承とかカプセル化（用語しかしらない）」というレベルでした。そこからアジャイル開発とは？という開発手法から入り、JavascriptによるNext.js開発を経てフロントエンジニアの素養を養ってきました。直近半年ではモデリングの重要性を感じ、UML(UMTP)やオブジェクト指向について学びを深めてきました。
その結果、兎にも角にも何が書いてあるかは今のところほぼ理解できています（本来の意味で理解できたかは別だが）。この手の立派な技術書は中々読み進めるのが苦手なのですが、事前にUMLの勉強をしていたおかげで、紹介されるクラス図や相互作用図に対して拒絶することが無かったです。2年前よりは確実にエンジニアリングスキルが身についてきてると感じました。
本の内容自体も、著者が実際に経験したプロジェクトの中から具体例を交えて説明しているので、比較的頭に入ってきやすい構成になっていると思いました。
普段の仕事の進め方の反省になった
普段、私は業務プロセス図やワイヤーフレーム、ERDやDFDを使用しています。これらはモデリングに近い位置づけのものと感じていただが、ドメインモデルと比較して、図の使い方に違いがあると感じました。
また、業務プロセス図についてはドメインエキスパートとともに作成してきた感はありますが、 クラス図やERDを一緒に作成してきたわけではないので、設計が業務的振る舞いを正しく表せているのかは疑問に思ってきました。ダイアグラム自体はある程度練りあがっていることもあり、これをビジネスサイドの人たちに急に見せて議論して善しあしを判断するのも中々難しそう、と感じました。その点を踏まえて荒、MVPを早く作ってコードに知識を蓄積していった方がいいかもしれない、とも感じました（UIもコンソールベースの業務ロジックにする、とか色々やりようはありそう）。
終わりに
うーん、本質な理解には程遠いですね。何度も読み返して一歩ずつ理解していけたらと思います。
【感想】楽しくなければ仕事じゃない―「今やっていること」がどんどん「好きで得意」になる働き方の教科書を読んだ
はじめに
会社で「悩む時間を短くしてアウトプットを多くしていく」と表明したら、この本がそれ系の本だよ、３０分で読めるよ、と教えてもらったので読んでみました。
感想
筆者はめちゃくちゃポジティブな人なんだな、ということがひしひしと伝わってくる本でした。本の内容としては、筆者のポジティブな思考が一体どう形成されてきたのかを筆者の経験等を踏まえて１０章に分けて分かりやすく紹介してくれている本でした。その中でも印象に残った言葉を少しメモしておきます。
- キャリアアップのチャンスは自分ではなく人が与える
- 悩むより一歩踏み込む
- マズローの自己超越欲求
- アイディアはE=MC2(MISSION×COLLECT×CONNECT)
- 「HAVE TO」を「WHAN TO」に変える
- ミッション後付けても良いから持っていた方が良い
- ハングリー精神や夢がないことをモチベーションが湧かない理由にするな
- やる理由はないが、やらない理由はいくらでもある。だからやる
- ロールモデルを探すな。おまえがロールモデルになれ
- 知らないことを認め、知りたいと思う事
- なり得る最高の自分になる
- 過去は変えられる、なぜなら解釈の問題だから
- 一人で持つ夢は普通の夢、みんなで見る夢は現実
- 視点を変える第一の方法はもともと先入観を持っていない領域をおこなうこと
ちょいちょい筆者のボケっぽい表現がありつつ、サラサラと読めます。 真新しい話はありませんでしたが、「うんうん、そうだよね」と改めて思い出させてくれるそんな本でした。
おわりに
読み終わって、それなりにポジティブな気持ちになっていました。30分で読めると聞いていたけど、240ページあり、1時間30分かかりました。まだまだ修行が足りませんが、以前に比べて大分読むペースは早くなっているので日々精進していきたいと思います。
「ドメイン駆動設計 モデリング 実装ガイド」を読んだらDDDの概要が分かった
はじめに
今年度UMLモデリングを学び始めUMTP L3を取得したタイミングで、ドメイン駆動設計（DDD）に手を出したくなり、「ドメイン駆動設計 モデリング 実装ガイド」読みました。知識定着も兼ねて読んだ感想を書き残します。
モチベーション
今年度の目標はプロとして仕事をするエンジニアになる、と思っています。プロとして仕事をするにあたり一番重要なことはモデリング・設計ができることだと思います。良い設計ができるエンジニアに近づくために、DDDの入門として
のブログで紹介されていた
を読むことにしました。
私のレベル
社会人12年目。フロントエンジニア３年目。始めて３年もたったのですがDDDはまだ学んだことが無い初学者です・・・今年度からモデリングを学び始め、まずは２か月UMLの勉強をしてきました。
読書時間
大体6～10時間弱と言った所でしょうか。100ページくらいしかなかったので土日を使ってサクサクっと読めました。直近でモデリングの勉強をしていたことで頭に入ってきやすかったです。
どんなことが学べるのか
DDDにおける概要的な部分と実装イメージが学べたと思います。私は「現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法」
や「良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」 を読んだことがあるのですが、比較すると以下の様に少しずつ内容が異なるので、順番に読んでいくことでより理解が進んだ気がしました。 また、本書は章ごとにQ＆Aがあり、読者がつまずきそうな部分について解説してくれているのがとても親切に感じました。
- 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
- 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
- ドメイン駆動設計 モデリング 実装ガイド
本書を読んでの気づき
- やはり、設計の根底にはモデリングがあるということに良く気づかされました。本書もモデルの定義から始まり、「model:A system of abstractions that describes selected aspects of a domain andcan be used to solve problems related to that domain問題解決のために、物事の特定の側面を抽象化したもの (意訳)」とDDD Referenceでは定義されていますが、この上手く本質を捉えて抽象化する、というのがいかにうまく出来るかどうかでシステム開発の良し悪しが決まるのだなと感じました。
- ドメインモデル図における注釈の部分（各属性の詳細仕様）こそが、ドメイン知識であり重要な点だということも良く分かりました。要件定義工程では、概念モデルとして物事を抽象化し問題を捉えますが、そこにはドメイン知識は含まれていなかったりするので、ここを以下にドメインエキスパートから引き出すかがプロダクト開発成功のカギになりそうだと理解しました。
- 強く整合性を保つ必要性のあるオブジェクト群をひとまとまりの集約と見なす、という考え方は、UMLには出てこなかったので学びになりました。
- 私は仕事でReact / Next.jsを利用することが多いのですが、紹介されていた各アーキテクチャを踏まえて各層にどのような責務を与えればよいか考えさせられました。以下のような色んな方のブログも参考に考えて行きたいと思いました。 tech.yappli.io
その他
- 今回は短かったので、本を読み終わった後にコンセプトマップで全体を俯瞰して理解を深めてみました。ドメインイベントなど本書では触れられていないだったり、ドメインサービスの実際の使い方についてイメージが出来ていない部分などもあったので、また別の本を読みながら理解を深めていきたいと思いました。
おわりに
DDDの入門書としてはとても入りやすい本でした。初学者の方でどこから学んでよいか分からない！と思っている方にはお勧めです。
この本を入りとして段階的に読書を行い、最終的にエヴァンス本も読破していきたいなと思います。最後まで読んでいただきありがとうございました。
UMTPL1,L2,L3に合格したので道のりを晒していく
はじめに
UMLモデリングの認定試験であるUMTPについて、L1～L3までを取得しました。
ネット上にもあまり情報が無いので取得までの道のりや感想を記したいと思います。
取得のモチベーション
とにかくモデリング能力を上げて自信をつけたい！と言った所がモチベーションでした。
フロントエンジニアとして働き始めて３年目ですが、プログラムの書き方は分かるものの、ソフトウェアアーキテクチャ設計や、その前段の業務分析をシステムへ落とし込む部分で中々HOWのイメージが付かず、苦しい思いをしていました。
また、周囲を見渡すと、そのようなことが出来る人と出来ない人は二極化しているように思えました。長年コードを書いている人でも、設計の話になると結構適当で「前の職場での経験に基づくとこれが良さそう」、「前はこうやってました」と言った根拠が曖昧な発言が目立っていると良く感じていました。
そんな時に、同僚がUMTPという資格を取得したことを知り、調べてみるとどうやらオブジェクト指向モデリングについての資格の様でした。「これって、今の自分が一番欲しいと思っている能力じゃね？」と直感で感じ、資格取得をモチベーションにモデリング能力を鍛えることにしました。
私の技術レベル
UMTPの資格勉強を始めるまではオブジェクト指向については全く分かりませんでした。学生の時に授業でやったよな～くらいな印象です。また、勉強し終わって振り返ると、当時と比べて、オブジェクト指向の考え方も全く変わってる気がしてますのでゼロから勉強を始めたと言っても過言ではないかなと思います。（私が学生で習った時はおぼろげですが、継承についてやら説明してた記憶がありますし、getterやsetterも書くのが正しいやり方だった気がします。）
勉強した期間
2023年５月～６月末の２か月間
勉強の進め方
基本的には本を読み、時には問題集を解く、と言う形で勉強を進めました。
最初は色んな人のブログを漁って、どう勉強していくか当たりを付けてから臨みました。
- 参考にしたブログ
UMTP L1
UMTP L1受験についてはまず以下の本を読みました。
![[改訂版] UMLモデリング技能認定試験<入門レベル(L1)>問題集 -UML2.0対応](https://m.media-amazon.com/images/I/513Stpehr-L._SL500_.jpg "[改訂版] UMLモデリング技能認定試験<入門レベル(L1)>問題集 -UML2.0対応")
正直UMTP L1レベルはこのあたりを読んでおけば問題なく受かると思います。
UMTP L2
L2試験については、以下の黒本をやった上で、ホームページのサンプル問題を解きました。L1にと比較すると難易度は上がりますが、黒本に対して理解が出来ていれば、まぁ受かるレベルなのかなと思います。
- UML L2問題集
UMTP L3
L3試験はとても難しく感じましたが何とか受かりました。
L3試験は2022年12月から自宅で受ける形式に変わっており、ボーダーも60点から77点に大幅に変更となっており、難易度は上がっているんじゃないかと言う気がします。
L3試験を受ける期間は、仕事で要件定義～基本設計当たりの業務をやっており、その関係でER図やDFDを書いたり、どういうデータモデルが良いんだろう、と言うことを考えたりしていました。それが試験を受ける上で結構追い風になった気がします。
また、加えて良いソフトウェアアーキテクチャとは？と言う部分も考え始めており、その関係で
設計原則関連の本も読んでいました。どちらの本もオブジェクト指向に基づいて設計原則を説明する本となっており、基礎理解を深める上で大変役立ちました。
あとは、分からない部分をネットの記事を読んで補完したりしてから試験に臨みました。
受験結果
結果としては、各試験無事合格することが出来ました。
- UMTP L1 96点 (80%以上で合格)
- UMTP L2 82点 (65%以上で合格)
- UMTP L3 82.59点 (77%以上で合格)
受けてみた感想
受験する前と比べて、格段にモデリング能力は上がった気がします。
元々はUMLの読み方さえ分からなかったわけなので、業務をヒアリングでモデルとして書き出すノウハウが分かりませんでした。今はそのような要件定義用務への恐怖心は大分なくなった気がしています。また、IT関連の技術書には必ずと言っていいほどクラス図が出てきます。この時、UMLを学んでない人と読書会をしていると、「ああ、この人は雰囲気でUMLを理解しているんだな」と言うのが良く分かります。ダイアグラムをちゃんと理解した上で技術書を読んでいるかで、大分今後に差がつく気がします。皆さんも、是非モデリングを学び、資格取得することをお勧めします。
情報処理安全確保支援士合格体験記（令和5年春期）
はじめに
令和５年春期の情報処理安全確保支援士試験に合格したので勉強方法をメモしておきます。
今後受ける方の参考になれば幸いです
私のスキル
- フロントエンジニア3年目。しかしながら、7年ほどSIerでベンダー管理系の業務をしていたこともあり、応用情報レベルの知識は元々あったと思っています。
勉強期間
1月～３月の間で、週末最低2時間は勉強するようにしていました。
大体２５時間～５０時間くらい勉強しているのではと感じています。
勉強内容
最初はひたすら過去問道場で午前Ⅱの問題を中心に解きました。
間違えた問題もすべて解き終わってからは、過去問新しい順に春秋あわせて3年分ほど解いたと思います。
午後I・午後IIの問題は、インシデントに対してどう対応するかというストーリー形式の問題のため、知識問題というよりは国語の問題なので、過去問を多く解くことで出題の傾向や問題に対してどのようなニュアンスの回答が求められているのかを分析して対策をしていきました。
参考書として翔泳社の「情報処理教科書 情報処理安全確保支援士 2023年版」電子版を買いましたが、ほとんど中身は読んでおらず、過去問をひたすら解いてます。翔泳社の本に過去問の詳しい解説がついているのでそこは参考にしています。
当日の結果
結果は、可もなく不可もない点数といった印象ですが合格できてよかったです。TAC等の自己採点ではもっと低かったので、結構下駄が履かせられているのかなという気がしました。
最後に
令和5年秋季からは問題形式が大幅に変わるとのことでもしかしたら参考にならないかもしれませんが、昨今のセキュリティ人材不足からボーダーラインが下がると予想されており狙い目かもしれません。セキュリティついての基本的な知識は身につくので是非受けてみることをお勧めします。
「良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」を読んだ感想
本を読むモチベーション
- 良いコードとはどのようなコードのなのかを理解したいから
- オブジェクト指向設計について理解を深めたいから
- ITエンジニア本大賞2023で技術書部門大賞を取っていたから
https://www.shoeisha.co.jp/campaign/award/result/
私のスキルレベル
- エンジニア歴３年目。エンジニアになったのは良いが開発経験者がチームにおらず、ソフトウェアアーキテクチャ設計の仕方が分からない
- ソフトウェアアーキテクチャの設計が出来るようになりたくて、まずはUMLを学びUMTP L1，UMTP L2を取得。今年度UMTP L3は取りたいと思っている
- 現在はReact / Next.jsを利用しており関数型プログラミングについて学ぶ必要があるが、その前段としてオブジェクト指向設計を会得したいと思っている
読んでみた感想
- 大体２週間で読み終えました。平均１日3０ページほど読んでいましたが、結構サクサク読めるので時間があればすぐ読める技術書だと思います。
- 初級を脱して中級エンジニアになるくらいの人は本当読んだ方が良いと思いました。この本を読む前に「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」を読んでおくのも良いかもしれません。クリーンアーキテクチャ等を読んで難しくて挫折した経験がある方は、この本を読んでから再度読みなおすと良いかもしれません。
- 私はプロゲートレベルでしかJavaを扱ったことがありませんが、コードはJavaで書かれています。特にコードを読むのに困ることはありませんが、Javaを学んでおくとより読みやすいかもしれません。
- 第10章の「名前設計」の部分が一番印象に残りました。書籍では「目的駆動名前設計」と呼んでいますが、これがモデリングや設計の第一歩だなぁとひしひしと感じました。10章の概要については筆者がyoutubeでも紹介しているので参考にしてみて下さい。
https://www.youtube.com/watch?v=_qXG06v8HAI
副次効果
- 本書を読んで、大分オブジェクト指向設計についての理解が深まったと感じたので、その後は一気にSOLID原則やGRASP原則、GoFのデザインパターン、MVCモデルやMVVMモデル、レイヤードアーキテクチャ・クリーンアーキテクチャ・オニオンアーキテクチャなどソフトウェア設計に関わる諸々を改めて学び直してみましたが、大分理解が出来るようになっていました。ちょっとエンジニアっぽくなってきかなと感じました。
以上の通り、初心者から中級者の方には大分おすすめの本と思いますので是非読んでみてください。
