技術士第二次試験を受験してきました
ブログを引っ越ししましたので，5秒後に移動します
7/15(月)に，国家資格である技術士の第二次試験を受験してきたので，そのメモです． 第一次試験は去年受験し，合格していました．
試験概要
- 日時: 2019/07/15(月) 10:00-16:30
- 場所: 後藤学園（池袋）
私のレベル感
- 大学では情報システム系の学科を専攻
- ITベンダでシステム開発のお仕事を約15年ほどやっている（主にアプリケーションエンジニア，システムアーキテクト，小規模の開発プロジェクトリーダの役割として）
- IT関係で，以下の資格を持っている
- IPA 基本情報技術者（2002年度）
- IPA テクニカルエンジニア（ネットワーク）（2003年）
- IPA ソフトウェア開発技術者（2004年）
- IPA 情報セキュリティスペシャリスト（2011年）
- MCPC IoTシステム技術者検定中級（2017年）
- IPA システムアーキテクト（2018年）
受験にあたって感じていた不安
今年度は試験制度の変更があり，事前にアナウンスされていました．
選択科目はII-1が択一問題になるだけで，II-2とIIIは去年度までとほぼ同じだろうと予想していましたが，必須科目がどのような形式になるかは試験当日までわかりませんでした．試験時間が30分短くなるので，去年度までのような参考資料の提示は無いだろうと予想していました．
実際は，選択科目はほぼ予想通りでした．必須科目は設問が4つになったのは意外でしたが，そこまで予想とズレはなかったので，試験時に大きな動揺はありませんでした．
試験日までの勉強内容
試験勉強自体は1月から始めましたが，時期によってムラもあり，本格的に生活の大部分の時間を割き始めたのは5月に入ってからでした． 1月からの約24週間の期間で主に以下のような方法で勉強をしました．
- 参考図書を読む・聴く
- 技術ノートの作成
- 日経コンピュータの購読と閲覧
- 技術セミナ・コミュニティへの参加（これは試験勉強関係なく，通常の自己研鑽の一環）
- 過去問を解く
- 選択科目II-2（H24）
- 選択科目II,III（H30, H29, H28, H27, H26, H25）
- 必須科目I（H24, H26）
- 試験の前週に，試験会場の近くのレンタルスペースで，試験当日と同様の時間割でシミュレーション模試を実施
一番時間を使ったのは技術ノートの作成とその刷り込みで，基本的には「聴く! 技術士二次試験 一発合格のツボ」で紹介されている方法を参考に行いました．
試験後に振り返って，どのような勉強をしたらより良かったか
- I,II-2,IIIの対策をもっと重点的にすればよかった
- 技術ノートの作成と刷り込みに多くの時間を割いていたが，それが直接的に有効なのはII-1のみで，配点の高いI,II-2,IIIへの対策が疎かだった
- または，I,II-2,IIIを意識した技術ノート作りが十分にできていなかったのかもしれない
- 時事問題や業務課題を例に，どう課題解決・業務遂行を行うかという視点で，もっと知識の体系化を図れるとよかった
- 参考図書の数
- 同僚や同業者と，特定の課題や技術についてディベートするような機会を設けられると良かった
当日の会場と受験者の印象
年度や会場によって条件が異なると思うので，参考程度に．
- 30代以上の年代が多いように感じた
- 女性比率は1割未満
- 机が狭く，あまり多く物を置けない（個人ごとの学校机のような机だった）
- 受験番号票（≠受験票）は机に貼り付けてあったため，机から落ちてしまう心配はなかった
- 教室の時計が試験官の時計より5分遅れていたため，紛らわしかった
- 会場のビルが古く，トイレにウォッシュレットがなかった
- 試験中にトイレ行く人が結構いた（5人以上）
その他気づいた点
- お昼休みに必須科目Iの再現論文書いたのが良かった（シミュレーション模試では，すべて終わってから書いたが，必須科目Iの内容を思い出せなかったので，試験当日はご飯を食べながら午前の再現論文を書いた）
- 必須科目Iの選択問題番号を書いてないことに終了15秒前に気づいて慌てて書いた
- たった1文字で全てを棒に振るところだった・・・．
- 試験が終わってから冷や汗が止まらないくらい，本当にゾッとした
- 基本中の基本だが，当日の緊張感や焦りの中，書き忘れは十分起こりうるので，絶対に書き忘れないように工夫が必要
- 第一次試験でもそうだったのでそれほどビックリしなかったが，受験者が自ら解答用紙を回収ボックスに持っていく回収形式だったので，持っていく途中で書き直す人が出たりしないのかと，不正防止の観点で運営に対して要らぬ心配をしてしまった
当日の持ち物
作成していた当日の持ち物リストです．ご参考まで．
- シャーペンx2
- シャー芯
- 消しゴムx2
- 鉛筆
- 鉛筆削り
- 定規
- 受験票（事前に写真撮っておくと便利）
- 時計（試験官の時計に同期させるために，時刻調整の操作に慣れておくこと）
- 水のペットボトル
- ブドウ糖のカケラ（糖分補充用）
- MacBook（再現論文作成用）
- 電卓（机が小さいと邪魔になるし，ほぼ使うこともないので，小さいものが良い）
- 靴下の替え（当日雨だったため）
その他，私は用意しませんでしたが，会場のトイレにウォッシュレットがない場合に困る場合は，携帯ウォッシュレットを用意すると良いでしょう．
試験の手応え
前述の通り，II-2とIIIの対策が不十分だったこともあり，かなり失敗感の強い結果になってしまいました・・・．
| 科目 | 手応え |
|---|---|
| 必須科目I | ◎ |
| 選択科目II-1 | ◎ |
| 選択科目II-2 | × |
| 選択科目III | △ |
- 選択科目は問題全体をサラッと見た瞬間に，特に無理そうな部分が無かったので「もらった」と油断したのかもしれない
- II-2でかなり苦戦してしまい，論理が破綻し説得力のない解答になってしまった
- そのせいでIIIの時間も短くなってしまい，十分に論理展開ができなかった
- 一応解答用紙はすべての問題で最終行まで埋めはした
結果
10月末に結果が発表予定なので，発表されたら追記します． 自信がなくても，発表前から口頭試験の対策は始めるべきなのが辛いところです・・・．
先月読んだ本と今月の読書予定（2019年7月）
ブログを引っ越ししましたので，5秒後に移動します
先月の読書実績
漫画，雑誌は除いています．
| 実績 | Fav | 本 |
|---|---|---|
| ✅ | ⭐ | 技術士第二次試験 合格する技術論文の書き方 |
| ✅ | 餃子屋とフレンチでは、どちらが儲かるか？ |
今月の読書予定
| 新規・継続 | 本 |
|---|---|
| ▶️ | あなたもいままでの10倍速く本が読める |
| 🆕 | ソフトウェア工学の勧め(上) |
QuALiTy~QAエンジニアによるLT大会~ 参加メモ
ブログを引っ越ししましたので，5秒後に移動します
本日チームスピリットで行われたQuALiTyに参加したメモです．
イベントメタデータ
全体
- 参加者はQAメインの方が多かった
- QAと開発の協調を視野に入れた考え方や活動をしている例が多く勉強になった
- カスタマーサクセスというロールを初めて聞いた
LT
エンジニアリングマネージャー視点で見るQAチームの存在意義（@saik1010/ウエディングパーク）
- メディアごとに存在するチームを，横断的にQAチームが支援する
- テスト専任者ではなく，直接的なQA作業以外も何でもやる自動化基盤の構築など）
- テスト自体はウェブディレクタもやる
- 所感
- EMの立場からQAをテスタonlyではない存在として見ていることに感心した
- 自身の組織ではこれに加えシフトレフトや全社生産性向上などもミッションとしているので，より幅広いのだなと比較して感じられた
新卒2年目開発エンジニアがなぜ QA エンジニアを目指すことになったのか？（02さん）
- 開発からQAへ転身
- QAしていないPJで大変な思いをした
- QAを学んで再発を防ぎたい
- 専門性を身に付けたい
- 他の人がチャレンジできる環境を作りたい
- 少しずつQAエンジニアリングを試している
- 所感
- 自身は今年度から品質マネジメントを行う組織に入るまで，積極的にQAに関わろうとしていなかったが，「興味の塊」と捉えていることがすごい
- 社内にQAエンジニアがいないから外の勉強会行ったり，できるところから試していて素晴らしい
大切なことは全てエンジニアに教わった（tsuemuraさん）
- 開発エンジニアとQAエンジニア
- 強い開発エンジニアはテストも強い
- QAエンジニアはドメイン知識が強い
- 開発からは障害調査方法（デバッグ，ログトレース），QAからはテスト技法，ケース作成方法などを教え合う
- お互いに強くない部分を少しずつ一緒にやってみて理解を深めていく
- 所感
- 開発とQAがうまく強調して仕事をできている環境を実践できているのがすばらしい
- 開発対QAに限らず，異なるロールはお互いに得意な分野は異なるので，同様な協調マインドが必要だと感じた
テスト自動化にチャレンジ～課題と新たなステップ～（m_yokotaさん）
- Selenium+Pythonで自動化したが，いまは行えていない
- メンテナンスが追いつかない
- HWの手動操作などもある
- TestimとかDatadogとかKatalonとかAutifyとか調査・検証中で，これらを使って今後も自動テストを続けていく
- 所感
- 独自に学習をしたりQiitaにまとめたり，その実践をこのようにLTで発表したり，行動がすばらしい
- AI自動テストはウォッチすべきと感じたので，倣って調査・検証したい
QAと開発の境界を飛び越えてみる (riririusei99)
- 開発対QAでの漠然とした不安
- GWにTECH:CAMPの開発研修に参加して，TODO Webアプリも作ったことで，視点の違いや開発寄りのノウハウが溜まった
- JaSST北海道参加予定
- 所感
- 異なるロールの意識を知るために踏み込んでみるスタンスが学ぶべきと感じた
気づいたら仕事が楽しくなっていた話（Erika Kanasugiさん）
- QAがチームに1人ずつ入っている組織構成
- 以前はQAが蚊帳の外で，仕様が明確になっていなく，見えない中で欠陥と戦う辛さがあった
- 社長の一声で組織改革し，要件定義を担うことになり，大きく状況が変わった
- 知らぬ間に越境していた
- 所感
- 蚊帳の外状態の辛さ，納得感が得られることにより状況が打開していく感じがとても共感できた
永遠のQa（t_isekiさん）
- 5年前からQAチーム発足
- 目的・計画・興味が「ない」ことが問題になっていたので，プロセスを定義して改善している
- 今後はシフトレフトも視野に高品質・効率化を目指す
- 所感
- QAの失敗を歴史上の空母に例えるなど，引き込まれるプレゼンだった
- CPM法，固定3レイヤ法など，知らないテスト設計技法が挙がっていたので，あとで調べる
CI/CD Test Night #4 参加メモ
ブログを引っ越ししましたので，5秒後に移動します
本日DeNAで行われたCI/CD Test Night #4のメモです．
イベントメタデータ
- 日時: 2019/06/20(Thu) 19:15-20:55
- 場所: 株式会社ディー・エヌ・エー 21F
- 主催: DeNA SWET
- イベントページ
- Twitterハッシュタグ: #cicd_test_night
LT
19:25-19:40 15分枠(1) hisa9chi：「MacStadium使ってみた」
- MacStadium | Apple Mac Infrastructure & Private Clouds
- DeNA SWETでの利用
- 所感
- まあまあのお値段だけど，24/7なので法定停電などに影響されない
- ハイスペックマシンを短期利用したい時には良いかも
19:40-19:55 15分枠(2) manabusakai：「CI/CD パイプラインを最速で組み立てるための 4 つのポイント」
- CIパイプラインの構築をいきなりCIサービス上で試さない
- 今はCircleCIをローカルで試せる（
circleciコマンド）
- 今はCircleCIをローカルで試せる（
- 依存関係をDockerイメージにしてPullする
- 所感
- あまりパイプライン構築をする機会はないけど，やるときに疑問に感じてたことを見事に説明してもらって助かった
- CircleCIの機能は結構進化しているみたいなので，機能をたまにウォッチせねばと思った
19:55-20:05 10分枠(1) TaiheiMishima：「Voicy iOSのCI環境をゼロから整えた話」
20:10-20:20 10分枠(2) ikesyo：「Travis CIのBuild Matrixを活用して、Swift製ライブラリをLinux対応させる」
- Xcode11のSPMはiOS/macOS向けのアプリにも使えるようになった！
- SwiftのDockerイメージがある→CIで使う
- TravisCI Build Matrix
- TravisCIはmacOS無料！（MacStadium使っているらしい）
- 所感
20:20-20:25 5分枠(1) ShuheiKitagawa：「5分でわかった気になるTEKTON」
- CD.FOUNDATION
- Linux Foundationがやってる
- TEKTONがホストされている
- TEKTON Pipelines
- k8sのネイティブリソースを使ったパイプラインを作る
- CI/CDの実行エンジンとしてCI/CDから委譲することができる
- 所感
- 全く知らなかった知識が得られた
- 普及はもう少し先だろうけど覚えておきたい
20:25-20:30 5分枠(2) Yuki Tamazawa：「ソフトウェア品質を支えるE2Eテストのビルドパイプライン作り」
- オリンピックチケット外れた
- JapanTaxiでSETやってる（QA，シフトレフトなど）
- mac miniでJenkins+AppiumでE2E実行し，TestRailに結果を流す
- 所感
- ここでもBitriseを使用しているとのこと！使うのが当たり前の雰囲気だから今度試してみようと思った
- JapanTaxiはテスト部隊を作って品質活動ちゃんとやってるんだなーと感じた
20:30-20:35 5分枠(3) ikuma_hayasaka：「老後必要資金2000万円時代に送る、Azure Pipelinesによる継続的テスト」
- Azure Pipelinesで個人開発におけるCI/CDのコストを削減する
- appiumのスクリーンレコーディングも
brew install ffmpegで可能 - 所感
- 前になにかのイベントでもAzure Pipelinesが無料だと聞いてたので，使ってみようと思った
20:35-20:45 10分枠(3) mats：「expoアプリ開発におけるCI/CD」
- キャンセル
先月読んだ本と今月の読書予定（2019年6月）
ブログを引っ越ししましたので，5秒後に移動します
先月の読書実績
漫画，雑誌は除いています．
| 実績 | Fav | 本 |
|---|---|---|
| ✅ | TQMとその進め方 (QC入門講座) | |
| ✅ | ⭐ | ソフトウェア工学の基礎 |
| ▶️ | あなたもいままでの10倍速く本が読める | |
| ▶️ | 技術士第二次試験 合格する技術論文の書き方 |
今月の読書予定
| 新規・継続 | 本 |
|---|---|
| ▶️ | あなたもいままでの10倍速く本が読める |
| ▶️ | 技術士第二次試験 合格する技術論文の書き方 |
| 🆕 | ソフトウェア工学の勧め(上) |
エンタープライズアジャイル勉強会 2019年5月セミナー レポート
ブログを引っ越ししましたので，5秒後に移動します
5/16(木)に参加したエンタープライズアジャイル勉強会 2019年5月セミナーのメモです．
イベント概要
エンタープライズアジャイル勉強会の紹介
講演: モノリスなアプリからマイクロサービスへ - クラウドネイティブなアプリ開発における CI/CDプロセスとDevOpsツール -
講演者
- 株式会社 FIXER Technical Fellow, Evangelist 鈴木章太郎さん
- 株式会社 FIXER Marketing & Sales Division, Cloud Evangelist 横山依子さん
講演要旨
- マイクロサービスとは何か？なぜそう設計・実装する必要があるのか？
- 実装するにはどんなことを考慮する必要があるのか？
- など基本的な解説をサンプルアプリを通じてご説明し、DevOps ツールで実際に CI/CD のデモなどをご紹介していきます。
FIXERについて
- 設立10年
- コアサービス: cloud.config
- 運用監視，保守
- クラウドの自動化と管理
- cloud.config Boot Campやってます
クラウドサービスの需要が高まる背景
- DXに対応するための，意思決定の高速化やビジネスプロセスの変革
- プラットフォーム（win2008とか）のEOLに伴う，オンプレのリプレースやマイグレーション
- 政府の方針（取り組み）
マイクロサービス
- 背景
- レガシーマイグレーションや新規開発をする際は，責任分界点が明確なのでSaaSを推奨しているが，ビジネス要求とのバランスからサービス開発が必要になる
- 大規模システムをモノリシックに構成する際の問題を解決する必要性が高まる
- コンテナ技術などの環境が整ってきた
- 特徴
- デメリット
- 運用管理コストは増大
- データ整合性担保が難しい
- 結合テストが難しい
- MSによる例（ホテルのシステムをマイクロサービスで開発）
マイクロサービスを支える技術
- Docker
- 資源効率性が高い
- 移植性が高い
- 大量コンテナ化に対し，オーケストレーションが必要→k8s
- オートスケール
- blue green deployment
- rollig update
- k8sは，実際はマネージドサービス使うのがベター
- 大規模化すると，データ整合性やk8s上のサービスの通信の統制が問題に→Istioなどのサービスメッシュ
- Windowsだけで開発できる環境が整っている
- .Net core
- Docker for Windows
- VS2019のコンテナサポート
- Azure DevOpsでコンテナ・マイクロサービスのDevOpsを簡単に管理できる
- コンテナリポジトリ
- プルリク，コードレビュー
- ビルド，テスト
- デプロイ
- 他にもAzureにいっぱい便利なサービスがあるので要チェック
（自分がした）QA
- Q: 「クラウドバイデフォルトの推進」で民間のパブリッククラウド利用を推進しているとのことだが，医療情報のクラウド保存に関する3省2ガイドラインのようなガイドラインもあるのか？
- Q: マイクロサービスの特徴で，開発チームの小規模化と管理の容易化が挙げられていたが，コンウェイの法則的に，マイクロサービスを適用する場合は，組織改革を並行させないと問題が起きやすいか？
- A: チームがそのサービスを全部知っていることが理想的なので，そうあったほうがよい
- Q: マイクロサービスは，サービスメッシュなどの適用なしに実現できるものなのか？Istio/Envoyとか使わない選択肢もありえるのか？（データ整合性の担保など）
- 大規模・複雑化していないシステムはマイクロサービスにする効果が薄い
- 大規模システムのマイクロサービスにおける各サービスの協調は自前管理が難しい
- ↑この2つにジレンマを感じるが
- A: まずは小さな規模でもいいので適用してみるのが有用
- マイクロサービスの感覚をつかむ
- 特定サービスに投資を集中できる
- 大規模なものに対しての適用は，サービスメッシュを考えたほうがよいが，規模の大小については，両方からアプローチするのがよい
先月読んだ本と今月の読書予定（2019年5月）
ブログを引っ越ししましたので，5秒後に移動します
先月の読書実績
漫画，雑誌は除いています．
| 実績 | Fav | 本 |
|---|---|---|
| ✅ | ⭐ | FACTFULNESS（ファクトフルネス） |
| ▶️ | あなたもいままでの10倍速く本が読める | |
| ▶️ | ソフトウェア工学の基礎 |
今月の読書予定
| 新規・継続 | 本 |
|---|---|
| ▶️ | あなたもいままでの10倍速く本が読める |
| ▶️ | ソフトウェア工学の基礎 |
| 🆕 | ソフトウェア工学の勧め(上) |
