ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

データベーススペシャリスト試験(令和2年度春期)勉強記録

始めに

令和2年度春期情報処理技術者試験及び情報処理安全確保支援士試験は新型コロナウイルス感染症拡大防止の観点から、試験実施を取りやめ(中止)となりました。

f:id:pato_taityo:20200329212051p:plain
当時、情報処理推進機構(IPA)に掲載されたお知らせ

私はデータベーススペシャリスト試験を目指して勉強していたので、試験中止は大変残念ではありますが、状況を考えるとやむを得ないでしょう。

次回の受験機会に向けて今回どのような準備を行ったのか、まとめておくことにします。

教材と利用方法

本エントリでは教材毎に略記表記を定義して用いています。

情報処理教科書 データベーススペシャリスト 2020年版

情報処理教科書 データベーススペシャリスト 2020年版

情報処理教科書 データベーススペシャリスト 2020年版

  • 作者:三好 康之
  • 発売日: 2019/09/17
  • メディア: 単行本(ソフトカバー)

略記:DB教科書

教科書・過去問解説のパートだけでなく、試験対策として学習方法と解法テクニックにもページが割かれています。また、会員特典として過去18年分の試験問題と解答・解説もPDFファイルで提供されています。

過去問のPDFファイルには白紙の解答用紙も含まれており演習に便利です。PDFファイルなのでパソコンやタブレットで閲覧することも可能ですが、試験問題を解く際にはページを行ったり来たりしたり書き込んだりするため、試験問題と解答用紙は印刷しないときついです。

データベーススペシャリスト過去問道場

データベーススペシャリスト過去問道場|データベーススペシャリスト.com

略記:DB道場

データベーススペシャリスト試験の午前Ⅱ問題の過去問を解説付きで提供しています。
スマホでも使いやすい画面で、スキマ時間を活用して取り組みやすいです。通勤中などには解き辛い計算問題を出題しないようにするオプション機能もあります。
アカウントを作成することで学習履歴機能を利用可能です。

午前Ⅱ試験は、当該区分のデータベース分野が中心になる。全25問中、18問~20問がデータベース分野の問題だ。しかもこのうち半数以上が、過去問題がそのまま出題される。(中略)したがって、午前Ⅱ対策の基本戦略は「まずは、過去に出題された問題を確実に解けるようにしておくこと」になる。
引用元:情報処理教科書 データベーススペシャリスト 2020年版

とあり、このサイトを利用して過去問に取り組むことは有用といえそうです。

応用情報技術者過去問道場

応用情報技術者過去問道場|応用情報技術者試験.com

略記:応用道場

応用情報技術者試験の過去問を解説付きで提供しています。「データベーススペシャリスト過去問道場」の姉妹サイトとなります。使いやすさも同様です。

午前Ⅰ試験は、応用情報の午前問題80問から30問が抜粋されて出題される。(中略)本格的に対策を取ろうとすると応用情報技術者試験の勉強をしなければならない。対策としては、午前Ⅰ試験専用の過去問題集を使って、ひたすら過去問題を繰り返し解く方法がベスト。
引用元:情報処理教科書 データベーススペシャリスト 2020年版

とありましたので、午前Ⅰ試験対策として利用しました。

勉強時間と進め方

勉強時間の測定にはStudyplusのスマホアプリを利用しました。

学習総合サイト Studyplus(スタディプラス)

2019/10 2019/11 2019/12 2020/01 2020/02 2020/03 小計
DB教科書 7.0 5.25 3.5 7.5 6.25 22.0 51.5
DB道場 4.0 0.0 0.0 0.0 0.5 2.5 7.0
応用道場 2.5 3.5 0.0 0.0 1.5 9.5 17.0
小計 13.5 8.75 3.5 7.5 8.25 34.0 75.5

DB教科書を最初から読み通しました。教科書パートの内容は既に頭に入っていることが多くありましたが、読み飛ばさずに読んでいくことで、たまに見つかる自分の苦手分野を意識し、知識の補強に努めました。

問題を解くにあたってDB教科書の教科書パートだけでは不十分でした。それでも問題の解説が丁寧に書かれているので、これを読み込むことである程度はカバーできました。足りない部分は他の本やサイトなどを参照しました。

家では家事・育児に追われてまとまった時間を確保できないため、午前Ⅰ・午前Ⅱ対策は通勤時間を使ってDB道場・応用道場で学びました。通勤の合間に進めたため計算問題に取り組むことはできませんでしたが、1周目の間で正答率は80%程度あり、基準点の60点を満たす自信となりました。

午後Ⅰ・午後Ⅱの過去問演習にはまとまった時間が必要なため、休みの日の子供が起きる前・寝た後に取り組んだり、会社で始業前・終業後に取り組みました。

勉強のコツ

私なりに編み出したコツをまとめます。

午前Ⅰ

私の場合は通勤時間しか割くことができなかったので、応用道場を利用して勉強することにしました。また、試験回選択のおすすめボタンを利用し、範囲を絞って取り組むことにしました。
それでも問題数は多く、かつ私の場合は正答率が80%程度あったので(基準点の60点に対して余裕あり)、もう少し割く時間を減らしてもよかったかもしれません。次回はこの判断のために午前Ⅰの過去問を解いて実力を測定する方法を考えています。

午前Ⅱ

私の場合、DB道場の1周目から正答率が80%程度ありましたが、午前Ⅱはデータベース分野中心の問題であり、午後Ⅰ・午後Ⅱ対策にもつながると考え、全問を完璧に解けるように繰り返し取り組みました。実際に午後Ⅰ・午後Ⅱ問題を解いていると、午前Ⅱの知識が役に立つことがありました。

午後Ⅰ・午後Ⅱ

午後Ⅰ・午後Ⅱはひたすら解いて慣れるのが合格への近道と感じました。

午後Ⅰ・午後Ⅱの過去問を細切れで解くのは難しいので、まとまった時間を確保して取り組むことをお勧めします。本番の試験時間と問題数が目安となります。
午後Ⅰ・90分・大問2問選択 ⇒ 大問1問当たり45分。
午後Ⅱ・120分・大問1問選択 ⇒ 大問1問当たり120分。
午後Ⅱの120分を確保するのが難しくとも、60分あれば切りの良いところまで解き進められそうです。

問題の解くペースを意識することが重要でした。できる限り時間を測りながら解くことをお勧めします。意外と試験時間が足りないことを痛感するはずです。

DB教科書では解法テクニックとして問題冊子に書き込んでいくことをお勧めしています。過去問の問題冊子に書き込むことには抵抗がある方もいるかもしれませんが(当初の私がそうでした)、本番の練習にもなると割り切って書き込むことをお勧めします。

過去問を繰り返し解いていると、同じようなミスを繰り返す傾向に気が付くことがあります。私の場合は午後Ⅱで以下のようなものが見つかりました。

  • 解けない小問にはまり込むことがある。5分考えても自明でなければ、解けるところから解くことにする。
  • 物理設計のバイト数計算で NOT NULL 制約をつけないときの+1バイトを考慮し忘れがち。
  • データモデルのリレーションの要・不要に迷うことがあるが、迷ったら描く。描き足りていないことのほうが圧倒的に多いため。
  • データモデルのリレーションの線は定規を使って描くこと。線の混みあうことが多く、フリーハンドだと見た目も効率も悪くなる。

このように教訓を書き留められたのは一部なので、今後取り組む際にはこまめに記録します。

DB教科書には「本書の解説は読むだけで力になる」とありました。今回は取り組む前に試験が中止となってしまいましたが、次回は通勤の合間にタブレットでDB教科書の過去問解説を読み込むことにもチャレンジしたいです。

終わりに

過去問を解いているうちに、自分が解法テクニックを覚えているだけに過ぎないのではないか、本当に自分の実力として身についているのか不安に感じることがありました。ですが、間違えた問題の解説と向き合っているうちに、自分の実力不足によって解けなかったのだと感じることがしばしばありました。

確かに解法テクニックはありますし、合格のためにはそれを知ることが必要です。ですが、ある程度の実力を兼ね備えなければ、合格は難しいと思われます。

業務で経験できることにはどうしても偏りが出てしまいますが、データベーススペシャリスト試験の問題(シナリオ)では多様な業種・テーマが扱われます。この試験勉強を通し、知識と(疑似的ではありますが)経験を積めることを期待しています。

次回の試験に向けて、日々精進してきます。

デブサミ2020「【13-B-4】質とスピード」聴講メモ

はじめに

Developers Summit 2020 Winter (Developers Summit 2020)
質とスピード
スピーカー:和田 卓人 [タワーズ・クエスト]
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2020【13-B-4】質とスピード #devsumiB #devsumi - Togetter

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ



品質は「~性」と言われる(例:保守性)。


基本品質は減点法の世界だ。
一方で魅力品質は無くてもよいが有ったら嬉しいことだ。

ショッピングサイトで言えば…
当たり前品質(基本品質):商品を購入できること。
一元的品質(性能品質):商品の品ぞろえ。


外部品質は「見える品質」であり、内部品質は「見えない品質」だ。
「見えない品質」はお客様には直接見えない品質だ。
そして、内部品質は犠牲にされがちだ。


品質を犠牲にするとは突き詰めると保守性を犠牲にすることになる。


保守性とスピードはトレードオフなのだろうか。


野戦病院のような開発現場がそこここにある。


増改築を繰り返し、屋根の上に家が建っているような状態になる。


保守性を諦めたことで動いたコードにふれるな、となる。そして、コピペが繰り返され、修正ミスが発生し、と爆弾処理のような開発が続く。


『中期的には逆効果になる』とは改修に余計なコストがかかることを指している。


汚さを意図的に選択することはできない。急いでいるから汚くても書こう、とはならない。


「要はバランス」で満足しているときは掘り下げ切れていないサインかも。本当にそれはトレードオフ構造なのだろうか?


品質とコストはトレードオフなのだろうか?

品質を上げられるのは94パーセントぐらいまで、がコストアップ説。

品質を上げれば結果的にコストが下がるというのがコストダウン説。
品質を上げるためには検査コスト+予防コストがかかるが、不良対応コストが下がることで、合計の品質コストが下がる。


ソフトウェアは作ってからが始まり。それ以降も仮説検証が繰り返される。


生産性は4つのメトリクスで計ることが増えた。

  • スピード
    • リードタイム
    • デプロイ頻度
  • 品質
    • MTTR(平均修復時間)
    • 変更失敗率


二律背反の「局所的」とは短期的ともいえる。


内部品質への投資の損益分岐点が1か月以内に現れるということは自分たちが報われるということ。損益分岐点が3年後だと自分事と捉えにくい(その頃には自分が現場を離れているかもしれない)が、1ヶ月なら自分事になる。


予算は動かせないことが多いし、品質は減らしても変わらないとわかった。であればスコープを削る。


質とスピードのトレードオフではなく、教育を犠牲にしていたのではないか。

デブサミ2020「【13-F-2】アプリケーションやシステムが悪い奴らに攻撃されたらどうなる?」聴講メモ

はじめに

Developers Summit 2020 (Developers Summit 2020)
アプリケーションやシステムが悪い奴らに攻撃されたらどうなる?
スピーカー:松岡 正人 [日本シノプシス]
の聴講メモです。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2020【13-F-2】アプリケーションやシステムが悪い奴らに攻撃されたらどうなる? #devsumiF - Togetter

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

シノプシス半導体のIPを売ることがメインだった。


【参考】

IPコア(Intellectual Property Core)とは、FPGA、IC、LSIなどの半導体を構成する再利用可能な回路コンポーネントの設計情報です。ソフトウェア開発においてはその設計情報を「ライブラリ」と呼ぶのに対して、半導体設計では「IPコア」や省略して「IP」と呼びます。IPコアには回路の種類、有償無償、ファイルフォーマットなどにおいて様々な種類が存在します。

IPコア - MATLAB & Simulink


シノプシスはコベリティを買収し、その後も買収を繰り返してプロダクトのラインナップを広げている。ソフトウェアの品質を高めることが目標となっている。

日本でもクオリティの問題が発生している。7payがその一例だ。


【参考】
セブン・ペイ - Wikipedia
7payの不正利用事件についてまとめられています。

これまでのクオリティとは正しく動くかどうかだったが、悪い奴らにとってそれは関係なく、悪いことに利用できるかどうか、それで金儲けできるかどうかが重要だ。

ここ数年はサイバーインシデントが脅威であると言われている。

サイバーインシデントは悪いやつが何かやらかすか(事件)、うっかりをやらかすか(事故)で発生する。

脆弱性は必ずしもバグから発生する訳ではないが、コード量が増えれば穴はどうしても増える。これをどう減らすか。

車はソフトウェアの塊になっている。リコールもソフトウェアの不具合で起きている。


【参考】
車載ソフトウェアの品質とセキュリティ向上を目指したシノプシスの取り組み - 日本シノプシスホームページ - Synopsys
ソフトウェアのコード行数で比較すると、車載ソフトウェアのほうがFacebookボーイング787よりも多いことを示すグラフが掲載されています。

2018年度のリコール件数は過去2番目の多さ、制御プログラムの不具合が影響大 - MONOist(モノイスト)
2018年にハイブリッドシステムの制御プログラムの不具合により、124万台以上を対象とするリコールが発生しました。


ボーイング737MAXの問題はソフトウェアの問題と言われている。悪い人がこうした問題を悪用するかもしれない。


【参考】
ボーイング737 MAXにおける飛行トラブル - Wikipedia

システムを止めると言うことはビジネスも止まるということ。自治体システムの障害や、OpenSSLのHeartbleedもそうだった。OpenSSLの問題は今も発生している。
開発者はその影響を会社のトップが正しく理解できるように説明しなければいけない。


【参考】
自治体システムの障害」はこちらです。

2019年12月4日に日本電子計算自治体向けIaaS(インフラストラクチャー・アズ・ア・サービス)「Jip-Base」でシステム障害が発生し、50自治体に影響が出た

自治体システム障害に進展、単独復旧不可は残り4% :日本経済新聞

OpenSSLのHeartbleed問題をわかりやすく解説した記事です。
「OpenSSL」とは何ですか?「Heartbleed」はどのような問題でしょうか? | マルウェア情報局


シノプシス半導体の会社だが、半導体にとってもソフトウェアは切っても切り離せない。コードの品質を上げなければいけない。

コード量は増えているし、組み合わせも増えている。複雑度のリスクが上がっている。組み合わせの一部で止まることが他に影響を及ぼすかもしれない。

今はいかに短い時間で開発しつつ、品質を担保するかが求められている。

日本は言葉の壁があるからセキュリティリスクが低いと言われていたが、今は翻訳で攻撃対象のシステムのドキュメントを読む時代となっている。技術の進歩がセキュリティリスクを高めた。

ソフトウェアの脆弱性は増えている。だが、それに対応できる要員がいない。

自分たちが何を扱っているのか、どんな課題があるのか、どうすれば対応できるか、を考えないといけない。

ソフトウェアは様々な要素の組み合わせになっている。
APIフレームワークOSS、OSなど。
これらを組み合わせたときに要素がどう連携しているかを可視化しないといけない。

シノプシスのSASTは静的解析ツールだ。コード量が増えると全てを目検では見切れないので、ツールで支援する。
静的解析Coverity(SAST) | シノプシス

インターフェースから脅威を考えるためにはNISTのセキュリティガイドを参照するのが良い。


【参考】
NIST (National Institute of Standards and Technology | NIST) のサイトから該当するドキュメントを探そうとしましたが、多すぎて上手く見つけることができませんでした。

IPA/ISEC が NIST の文章を翻訳して公開しているページも見ましたが、見つけられませんでした。
セキュリティ関連NIST文書:IPA 独立行政法人 情報処理推進機構


今はセキュリティに関する本・資料がある。そこからどんなアプローチで臨むかを考える必要がある。

脆弱性はリサーチャーと呼ばれる方が見つけるケース、ユーザーが見つけるケースと様々だ。そうした情報が集まるポータル(例:CWE)などを参照する。
https://cwe.mitre.org/

どんな怖いことが起こるのかということを脅威モデルといい、シノプシスの英語資料がある。
https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/threat-modeling-datasheet.pdf

サーバーの内側と外側の脅威は両方考えないといけない。インシデントには内部の協力者がいることがしばしばある。

脅威モデルではシステムの主要なアセットとその相互関係を可視化する。
脅威となる人(脅威エージェント)を想定する。脅威エージェントをシステムの領域に割り当て、何かしら悪いことをすると想定する。

セキュリティ管理策では悪いことをされると想定して何をするかを考える。例えば、レガシーシステムと接続しているのであれば、レガシーシステムは更新されずに脆弱性を突かれて脅威になりうると考えて、IP制限を実施するなど。

MITRE ATT&CK フレームワークにはどんな脆弱性を利用して攻撃のためのコードを作っているかのパターンがまとめられている。取るべき対策もまとめられている。取るべき対策は裏を返せば攻撃されるポイントでもある。認証情報窃取であれば "Credential Dumping" を参照のこと。


【参考】
今知るべきATT&CK|攻撃者の行動に注目したフレームワーク徹底解説
ATT&CK に直接リンクするより、このページで理解を深めることが有用と考え、紹介させていただきました。

脅威モデルを考えるうえで参考になるリソースを挙げる。
※注記:リンクは私が最も適当であろうと判断したサイトとなります。

(1) Microsoft STRIDE
脅威モデルを作るためのツールだ。
脅威 - Microsoft Threat Modeling Tool - Azure | Microsoft Docs

(2) OWASP CHEAT SHEET
Introduction · OWASP Cheat Sheet Series

(3) OAuth 2.0 Threat Model
RFCにもなっている。
OAuth 2.0 Threat Model and Security Considerations

シフトレフトし、品質を早い段階で対処することが必要だ。