インフラ手順書テンプレートを作った話

これは何

インフラ的な手順作業書の書き方についてまとめたい。 このページのテンプレートをコピーして書き始めると、手順書がスムーズにかけることを目標としています。 ここに書いてあるものはコンフルエンスを前提として書いています。

インフラ作業をやるときには原則的に手順書を書いてチームメンバーにレビューしてもらいましょう。 予定していない作業をぶっつけ本番でやると、大幅に時間がかかったり事故がおこったりすることが多々あります。

手順を残しておけばどういう進捗状態になっているかすぐ分かりますし、これから近い作業をする人が参考にすることができます。 まったく手順資料がなかったとすると、すべての作業をゼロから考えなくてはならず、大きなコストがかかってしまいます。手順を作ること自体がコストではありますが、長期で見てコストが低くなると考えて資料化するべきだと考えています。

=============以下手順テンプレート=====================

タイトルは、実施日時が決まっている手順は年月日を書いておきましょう。例えば単に「メンテナンス手順」と書いてあると後から見た時にいつのかわからなくなりますが、「20180206 全体メンテナンス手順 MySQL Master昇格」 などと書いてあると大体タイトルだけ見て参考にできるか判断することが出来ます。

目次

目次はつけましょう。目次を見てよくわからない(階層がガタガタしているとか、節のタイトルが意味不明とか)の場合にはたいてい読みづらい資料になっています。

作業目的&作業概要(方針)

この作業書にかかれている作業の目的と概要を書きましょう。 目的を達成する手段は(場合によっては)沢山あるので、目的をはっきりさせて手順方針を決めた時点でチームレビューを受けたほうが手戻りが少なくて良いです。 目的と方針は表裏一体なので対で書くと良いのではと考えています。

作業目的

目的です。

作業概要

この手順の概要について数行程度で書きましょう。細かい手順だけがあると、それをすべて読まないと全体をつかむことが出来ません。

期限&スケジュール感

厳密な期限がある場合にはそれを根拠と共に書いておきましょう。チケットなどあれば貼っておくとよいです。  特に強い根拠がなくても期限の目安や目標時期だけ書いておいてもいいと思います。仕事を振った人が「このタスクはどれくらいかかるかな? いつ終わるのかな?」というのが把握できるようにする目的です。 ある程度タスクが洗い出されている場合には、いつごろにどのタスクをやるというロードマップを書いておくとよいです。厳密でなくてもよいので工数見積もりが書いてあるといいかもしれません(理由は同上)。

関連リンク

チケットや全体を通した参考資料を貼っておきましょう。前提知識やこれまでやられた似た作業手順を貼っておくのも良いと思います。 手順の個別項目に関連する資料はその場に貼っておいたほうが便利です。

手順に関わる調査資料などを子ページに置いていきましょう(コンフルエンスなど階層化できる場合)。子ページへのリンクが自動で表示されない設定になっている場合には子ページを表示するとしておいたほうが階層がすぐ分かって便利です。子ページのマクロは孫ページまで表示するように設定することもできます。

検討事項

検討内容によって手順が変わるような先に考えておくべき重要な検討事項について書いておきましょう。なければ不要です。 検討が終わったらそれをタスクに落とし込むか、「その他」項目や子ページにまとめるなどしましょう。

検討事項1

ほげ

検討事項2

ふが

事前準備

当日でなくてもできる作業については事前にやってしまいましょう。やった結果もまとめておきましょう。 特に他部署依頼など時間がかかりがちなものは先に潰しておきましょう。作業ボトルネックは何か? それを潰すには何をすればいいんだろう?という視点で考えるといい気がします。

事前準備1

ほげ

事前準備2

ふが

同期的作業タイムスケジュール

他チームと同期的にやらなくてはいけないとかメンテナンスの時間が決まっているなど、当日のタイムスケジュールを決める必要がある手順については書いておきましょう。非同期でできるものは事前作業としてやってしまいましょう。 同期的作業が特になければ、事前作業、事後作業ともに一つの項目にまとめてしまって良い。

実際にかかるだろうなという時間に追加してバッファや万が一の切り戻しの時間も考慮して決めましょう。

| 時間 | 作業内容概要&リンク | 担当者 | |:-----------|------------:|:------------:| |xx:xx ~ | 詳しい作業内容が長くなる場合には作業詳細に書いてリンクを貼っておきましょう。 | やること: @担当者 役割分担できそうなら相談して依頼しましょう。 | 長時間に渡る作業の場合には休憩時間なども考慮に入れましょう。人は休まないとミスをします。

依存関係があるサービスには連絡しておきましょう。その話をしたリンクもはっておきましょう。当日に連携が必要な場合にはその連絡内容もあらかじめ作っておくとテンパらなくてよいです。

同期的作業詳細

上のタイムスケジュールに書ききれなかった詳細な内容について書きましょう。上のタイムスケジュールにリンクを張りましょう。リンクは目次のものをコピーすると楽です。

設定更新がある場合には、その設定を確認できるコマンドなども一緒に書いておきましょう。可能であれば設定の一部だけでなく全部をカバーする確認方法を検討しておきましょう。

中作業1

作業は問題があった時に巻き戻せるように進めましょう。可能な限り一気にすべてを破壊的に進めるのではなく、徐々に次の状態に移行していきましょう。

少作業1

チェックボックスで細かく書いておいたほうがよい 終わったらチェックをつける

少作業2

好みではあるが、少作業にもタイトルをつけたほうが目次を見て流れがつかみやすい

中作業2

ふが

後処理

当日にやらなくてもよい手順についてまとめておきましょう。 忘れがちなのでリマインダやgaroon予定など入れておくとよいかもしれません。

その他

参考となる小話や調査について書く。分量が多いときには子ページに切り出しましょう。

非効率な仕事の進め方とルール化について(オートフォーマット編)

背景

最近ちょっとだけバックエンド開発の仕事をやらせてもらっている。 当然その分野の先輩がいるわけで、その人たちの書いたコードを修正したり追加したりするのが多い。

IntelliJを使ってPHPを書いているのだけども、オートフォーマットをしてPRを出すと細々とコメントがつくことが何度かあった。 私はREADMEに書いてあるルールに従ってIntelliJのオートフォーマッタを設定して修正しているだけなんだが、ここはこうした方が良いとか、最近の運用ではこうなっている、とか細々としたコメントが大量につく。 「クラス定義の後ろの "{" の前は改行しよう」とか「いや、ここは今はもうそのルールは古い」とか。そんなくらいの話。

問題点

おかしいな?と思ってヒアリングすると幾つかの問題がチームにあることがわかった。

  • READMEの記述が古い
    • 古いコードに引きずられてルールが作られていて、すでに誰も見ていない。新しく入った人だけがそれを見て振り回される。
  • 昔のコードをフォーマットするかしないかで意見が統一されていない
    • 自動フォーマッタを入れている人は修正を出すが、そうでない人も多い。ボーイスカウトルールとは(来た時より出る時には綺麗にしましょう)
  • 温かみのあるコミット分割
    • ある人は新規で追加した部分はフォーマッタかけるが、ファイル全体に修正がPRに出るといやなので、git add -pなどを用いて自分の変更箇所だけコミットするなどしていた。温かみ運用。毎回手動でやっているのか・・・

修正

私の提案

  • 形がい化したルールを削除(READMEに書いてあることは正しいものとする)
  • PRで議論をして満足するな。議論して決まったことは同じことを繰り返さずREADMEに明記すること。書いていないルールはそのPRを通す通さないには関係してはならない。直したければ別PRとして修正すること。
  • オートフォーマッタ設定の方法もかく。会社でライセンス買っていて大体みんなIntelliJ使っているのでその設定方法の明記。vim使っている人は従ってもらい同等のものを入れてもらう
  • 古いファイルもまずオートフォーマットしてそのコミットを分ける。必要に応じてPRも分ける。実作業と分けた方が良い(緩やかなルール)

できなかったこと

  • editorconfig などでルールの自動読み込み
    • すでにあるエディタ設定が優先だったし、PSRなど包括的なルールで設定できなさそうだった。これは知見が足りないだけかもしれない。

終わりに

上の提案はあくまで提案で、そのような内容をREADMEにかくPRを出してマージされた段階。 そのあとの運用はまた回してみて問題が出れば修正。

とにかく「繰り返しの無駄な議論」「細かすぎる指摘によるマージブロック」「温かみのある手作業」 こういうのをなくしていかなければならない。

誰かに質問をわざわざしに行くのが苦手な私が、それを克服した話

背景

私はもともと誰かに質問をするのが苦手な気質。 ランチや移動中にカジュアルな話をしていて「そういえば」くらいのノリで聞くのはできたけど、改めて「質問なんですけど・・・」みたいに人の席に行って聞くのが苦手だった。

問題点

エンジニアをやっていると分からないことはたくさん出てくる。 ドメイン知識についてや難しい技術について。

ドメイン知識についてはそもそも聞かなきゃわからないことが多い。 サーバの中をひたすらあさったり、コードを読んだりして推測することはできるけど、時間はかかる。

(自分にとって)難しい技術についても、ブログ読んだりドキュメント読んだりすればいつかは扱えるようになる。 大体の場合は通勤時間にスマホで雑にブログとか5個くらい読んで大まかな用途みたいなところを掴んで、公式ドキュメントで理念や細かいHowを読み込むと自分のものになっていく気がする。 たまにブログ情報も少なかったりドキュメントが貧弱なミドルウェアとかにぶち当り、無駄に時間をかけてしまう。

そういう時、詳しい人に「ねえねえ、10分だけちょっと最初の概要だけ教えてよ」と話を聞いて、そのあと自分で触ってみるとすっきり問題なく使えることが多い。

わかっちゃいるが聞けない

質問の仕方として「自分が何が分からないのかはっきりさせてから聞きなさい」と教育されてきたからなのかカジュアルに人に聞けない。 分からないことが分からない時には誰かに話してはいけないような気がしている。でもその時間が長く続きすぎるなら、10分だけ時間をもらったほうが良さそう。

克服しつつある

最近、あるプロダクトのSRE的な部分のリーダとして仕事をするようになった。 必然的に、誰かに技術や仕事の進め方、ドメイン知識を伝えないといけない。 私が仕事を振る時、相手に最初に短い時間をとってもらって出来るだけ方針やはまりどころを伝えようとするけども、それでも伝えきれないものが出てくる。または、ある程度進んだけど次のステップで困っているなどの相談がくる。 その時に(みんなじゃないけど)私の机のところにカジュアルに話を聞きに来てくれる人がいる。

仕事の進め方ってみんなやり方がバラバラで、Slackメンションしてから時間とってもらっていいでしょうか?みたいにちゃんとする人も、しゃべりながら近づいてきて問答無用で会話を始める人、逆に詰まっているのに話を全然持ってこない人など。 その中でピカイチの成果を出すのはやっぱり躊躇なく話を聞きに来る人。

こちらの時間は取られてしまっているのだけど、それでもその人がウンウン唸って詰まる時間が少ないので仕事はスムーズに進む。チームとしてトータルコストは低そう。 そういう風に人の仕事ぶりを見るようになって、忙しくなってきた自分がコストを低く結果を出すためには、やっぱり誰かの力をテコとして使うのがいいんだろうなと思ったりする。すべての内容を聞くのは相手の時間を使いすぎるのでいまいちだけど、一番詰まるところだけを人の力を使って解決してしまうのが良いのかなと。

終わりに

まだ克服できていない部分ももちろんある。意識して克服していきたい。 ”人に質問をする”のが苦手という断片的な部分よりも、最小コストで結果が出せているかな?という点にこだわっていきたい。 この文章を書いたのは、後から自分が見て、ちゃんと出来るようになっているかな?というのを確認したいがため。

チームがうまくまわるようにAnsibleのPlaybookでGitHubプルリクテンプレートを使いたい話

目次

背景

最近インフラを触り始めた人と一緒に働くことが多くなってきた。みんなに効率よく経験を積んでもらいつつ、インフラチームをうまく回すための施策を細々考えている。この記事はその中の一つについてのメモ。 私は「こういう内容が良いのではないか」と思って作ったものなので今後チーム内外の意見をもらって内容が書き換わる可能性は大いにある。

GitHubのテンプレート機能はどう使うか

レポジトリのルートディレクトリに PULL_REQUEST_TEMPLATE.md という名前でファイルを置くと、プルリクを作るときに自動的にその内容が書かれる。 詳しい置き方や仕様についてはググれば出てくるのでここには書かない。

テンプレートを作るにあたり気をつけたこと

  • 後からプルリクを見直したときに、何をやっているか分かるか。後から新人が入ってきたときにプルリクをトレースして学ぶことができるようにしたい。
  • 開発環境や本番環境に全て(半)自動反映になっていれば最高だが、今のところそうなっていない。 反映漏れ事故をなくしたい。
  • コードだけ書いて本番に反映せず満足してしまう人もたまに居るので、きちんとデリバリーしようという意識を持ってもらうために、それを促す記述を入れたい。
  • プルリクを出した後のネクストステップを意識するとスムーズに仕事が回るので、それを考えてもらいたい。
  • 時間は無限ではないので緊急度や重要度を意識して、やらなくて良い仕事はやらない。ネクストステップがない場合もある。
  • よく分からないことをプルリク出してもレビュアが気がつかなければプルリクが通ることがある。事故の元なので曖昧なことは表明してもらってみんなで解決したい。

テンプレート内容

# 概要
### 経緯
issueやconflenceリンクがある場合にはそれを張っても良い。

### このprの目的
課題は何か

### 変更点概要
この変更によりどう解決されるのか

# 本番/開発環境更新
### 反映タイミング
開発環境と本番環境への反映を行うタイミングを記述する。以下の選択肢から1つ選択して詳細を記述する。

* 開発環境に反映済み
  * 対象サーバを記述する
* マージ後開発環境にのみすぐ反映する
  * しばらく開発環境で動作を確認したい場合に選択。もしくは緊急度が低く、本番へは次のサーバリプレイス時に入れば良いという場合
  * 反映すべきサーバを書いておく
* マージ後すぐに本番に反映する
  * 緊急度が高い場合
  * 本番更新チケットを作成して、リリースタグを切って反映する。参考: http://hogehoge.jp
  * 反映すべきサーバを書いておく

### 動作確認手順
更新後に行う動作確認の手順を記述する。すでに開発環境で動作確認を行っている場合にはその内容を書く。
できるだけprを出した本人以外でも動作確認ができるように書く。自明な場合には記述しなくてもよいが、レビュアーはレビューをする段階で分からなかったら確認するのが望ましい。

# 関連issue/pr/外部リンク

# その他
### 今後の課題
次に解決すべき課題があれば書く。

### 実装に関する留意点
困ったことやイマイチな点など。

初めて会社でAPIを書いて学んだことメモ

これは何

普段主にインフラエンジニアとして働いている私が、会社で初めてAPIを一つ書いたので、そこで得た学びや考えたことを記録しておこうと思います。

何を学んだこと・考えたこと

仕様書を書こう

どのようなAPIなのか、目的やリクエストパラメーターやレスポンスフォーマットについて定義する。 特にAPIの場合はレスポンスフォーマットが変わるとクライアント側でパースするのに困ってしまうのではっきり定義しなければならない。 APIは使う側ありき。

レスポンスフォーマットの統一性

他のAPIとできるだけ揃えた方が良い。統一性がないと使う時に大変。 ドメイン全体でJSONのうちのMeta情報やDataオブジェクトをどのようなフォーマットにするのかというのを決めておき、各種APIはそれに従うのが良い。何も決めずに走り出すとメチャメチャになってしまうのでまず共通ルール。共通ルールはフレームワークへ落とし込んでおいて、そのフォーマットから外れなければ簡単にレスポンスを作れるようにしておく。 共通ルールをしっかり作っておくと大枠は固定されるので、後から細かいところをちょっと変えるにしても混乱が少ない。

DBで保持しているデータとAPIJSONのキー名は必ずしも合わせる必要がない

裏で使っている名前に引きずられがち。利用者にとって使いやすい名前にする。 例えばDBで公開状態をpublic_statusという名前で持っており、0,1の値を取るとする。どちらの値がpublicなのかちょっと分かりづらいと感じたとする。その場合、public_statusにこだわらなくても、APIレスポンスとしてはデータ要素が削除されているかというのが重要であるなら is_deletedという名前で返してあげるのが親切。

時間はUnixTimeで返そう

JSTUTCで帰っていると使いづらい。DBでJSTで保持していても変換してUnixTimeで返すと良い。

エラー応答についても定義しておこう

主なエラー応答やステータスは共通ルールとして定義しておこう。 各APIの仕様書においては、特殊な条件やちょっと迷いそうな場合についてエラー応答について記述しておこう。

仕様書はコードからすぐに参照できるように書いておこう

@see などで参照リンクとしておいておこう。 簡単な説明はコードにコメントしてしまった方が良いが、長くなるなら仕様書に切り出してリンクを貼っておくのを忘れずに。1セットで管理していく。

コードフォーマットはエディタに任せよう

エディタに微妙にフォーマット設定が入っていなくて細々としたPRコメントを沢山もらっしまった。 フォーマットについてはプロジェクトのREADMEにすべて明記して新しく入った人が迷わないようにする。可能であればエディタ設定ファイルなども共有しよう。 人間がやることではない。機械に任せられるのは機械に任せよう。

テストを書こう

PRコメントに長々と手動の動作確認の結果を書くのはよくない。TDDの考え方を取り入れて仕様が決まったら先にテストを書いてしまうのが良い。

コメント: とはいえ今回のケースでいうと、それなりにテスト書くのに苦労したので先に書くのは難しかったかも。Seleniumでテストを書いたのだが、他の開発者がMacだったが私だけWindowsでテストを回したので無駄に苦労した。開発環境は可能なかぎり教えてくれる人と合わせた方が良い。

同じような応答を返すWebFrontページがあるなら仕様を合わせよう

WebFrontページとソート順や件数などの仕様が異なると混乱を招く。仕様がくいちがうならその旨を理由と合わせて明記しよう。

障害電話受け1番になった時に使える三つの心得

これは何

システムに障害が起こった時に電話が一番にかかってくるようになった人のための心得。具体的な障害対応手順ではなくて、元気にSREエンジニアとして生き残っていくための心得。

心得

1. 本当の優先事項は何かを考える

仕事の電話がかかってきた。(仮に)今は奥さんの誕生日食事会の途中だ。さあ電話に出て対応をするか? そういう時には対応をしてはいけません。他の人に任せましょう。ほっておけば2番目の人が電話を受けてくれます。 人生で重要なことの優先順位をつけましょう。電話がかかってきたら必ず仕事、なんてことはやってはいけません。そういう風に考えていると24時間いつでもかかってくる電話を所持していると精神が持ちません。気をつけましょう。 エンジニアとしても人としても長生きしましょう。 (補足:待機人員として拘束時間になっているならちゃんと出ましょう。しかし特に決まりもなく電話を持たされている場合には法的には何も拘束力がないと理解しています)

2. 最初にやることを意識する

まずは他の人も呼びましょう。 あまりにも軽微な障害なら一人で対応しても良いですが、すぐに問題原因が特定できない可能性があるもの、影響範囲が狭くないものの場合にはチームメンバーが気がつけるようにSlackで@channelしましょう。躊躇なく。 その目的としては以下のような人員を増やす目的があります

  • 問題原因特定のための人員
  • 原因特定後、手作業が発生した時に対応する手として
  • 影響システムや社内一次報告、関係会社などに連絡する連絡人員として
  • SREの知見は少なくてもユーザ目線で障害発生や復旧を確認できる動作確認人員として

なんにせよチームメンバならやれることはあるはずなので人を集めましょう。 上にはいろいろ理由は書きましたが、一人で対応するとテンパったりミスをしたりするのでオブザーバでもいてもらった方が良いです。

3. 障害対応は実況しよう

やったことは生のコンソールログを含めてSlackに貼っておこう。他のチームの状況なども可能なかぎり一つのチャンネルに集める。これの目的は以下のもの

  • 途中から対応に参加した人が状況を把握できる
  • 手分けして対応をしている場合に他の人の状況が把握できる
  • ミスや考え違いをしていたら他の人が気がつくことができる
  • 振り返りに使うことができる(後で見て情報ないと本当に困るので、やってみると効力がわかるはず)

実際にやったことだけでなく、障害原因の予想や、対応方針、ふわっとした違和感なども投げましょう。少しでも情報を表に出してみんなで考えることが大切です。書くことで自分の考えも整理されます。

終わりに

これらは電話をもらって頑張って死にそうになっている同期や後輩を見て考えたことです。

長生きしましょう。 ストレスためすぎているなと思ったら電話をおいて海にでも出かけるのも良いです。この投稿で言いたいことはこれがほとんで全てです。

応用情報技術者試験を受けたので記録しておく

これは何

2017年10月にIPA応用情報技術者試験を受けました。12月合格発表で、結果が出た(合格した)ので、考えたことを記録しておく。

結果は?

点数は午前75、午後68ですれすれというほどでもないけどなんとも言えないところ。とはいえ、資格試験はボーダを超えるのが重要なので目標通りではあるのでOK。

応用情報って何

IPAが言ってる7段階のレベルの3に当たるもの。そろそろきちんとエンジニアとしてやっていくかな〜と考えているような人が受けるレベル。 午前試験と午後試験で分かれている。午前試験の開始が(特に私の所属する企業の)エンジニアの起床時間と比べて早いのが特徴的。 詳しいところ気になる方はググる感じでよろしくお願いします。

なぜ受けたか

  • 大学が化学系で、情報系出ていないのでコンプレックスがある
  • 受かると会社で一時金が出る
  • 幅広い知識も業界内の専門外の人と話す時に重要と思った
  • 経産省の調査で、諸外国含めたIT人材のレベルとお給金、的な資料を読んだ。だいたい自分のレベルとお給料の市場相場が一致しているのだなと気がついて、知識ベースアップのために受けてみることにした。(また、米国水準だと同じレベルだとお給金もうちょっと良さそうなので英語もぼちぼちやる) 参考資料: http://www.meti.go.jp/policy/it_policy/jinzai/27FY_report.html http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_global.pdf

対策は?

前提知識(試験前のレベル)

午前試験

過去問見てみると業務で見たような単語が多い。過去問道場で雑にやってみると午前試験が無勉強で4割くらい取れる感じだった。最初のテキスト半分くらい読み終わった終わった段階で午前試験の過去問5割くらいだった。

午後試験

午後試験は10分野のうち4分野選択するのだが、私はセキュリティ、アーキテクチャ、ネットワークが無勉強で5〜10割くらいでばらつきあるが平均で合格点取れそうだが、あと1分野はどれも5割切りそうなのでどれとるか迷うレベル。

勉強時間は

多分30時間くらい。移動時間にやっていたのが多いので測定不能だがだいたいこれくらいだろう。平日の移動時間に10分くらいの細切れ学習時間の積み重ねと、土日のどちらかの1〜2時間くらいをカフェでのんびり参考書読む感じだった。 おそらく午前試験に20時間くらい。午後試験に10時間いかないくらい。

学習内容

午前試験

  • 参考書を読む「キタミ式イラストIT塾 応用情報技術者 平成29年度」。この参考書はわかりやすくてよかった。他の参考書も買ったが、なぜそうなるのかとか書いておらず「公式」とか書かれていたのでゴミ箱に捨てた(比喩)。まずは本の7割くらい苦手分野を中心にざっくり読んだ。
  • 過去問道場というサイトで電車内でちまちま過去問やる。過去問題解きつつ、わからなかったら参考書やググる。気になったものがあったら好奇心のままに調べる(ただし移動時間10分くらいの長さだけ。基本深くは潜らない)。

午後試験

だいたい1週間前(本格的には前々日)から午後試験対策をした。参考書は2週間前くらいに中古の安いやつ買った。「2014 応用情報技術者午後問題の重点対策 (午後問題対策シリーズ)」。この本も解説が詳しくてなかなかよかった。正直あんまり読んでないけど。版は古いがどうせ資格試験なんて大して内容変わらないだろうと思っての安いやつ。試験では新しい話題も出てきていたが、正直ベースがあればやはり解けるので新しいのにこだわらなくてもいいなと思った。業界内にいる人は普段から最新技術もなんとなく話を聞いているだろうし。 セキュリティ、ネットワーク、アーキテクチャは傾向だけさらっと見て、あと一分野どうするか決めるためにいろいろ解いてみた。

どれにする? 午後試験の問題は当日選べる。一夜漬けするならどれだ。

  • マネージメント: 雰囲気で半分取れるが安定しない。博打なので無し。
  • 情報システム開発: 過去問見る感じだといろんなフロー的なのとか出てくる。雰囲気でとけるが、しっくりこないのでとりあえず無し。他に選択肢がなければやる。
  • アルゴリズム: 一つの大問に平均20〜30分が標準だが、問題によって40分くらい時間をかければ7割取れそう。できるようになれば硬いが、一夜漬けは無理そう。他の大問が早く終わって当日楽そうだったら(時間をかければ解けそうだったら)選ぶ
  • データベース: 正規化とか設計の方はなんか本読んだことあるのでわかるが、普段ゴリゴリにSQL書いていないので副問い合わせとかなんか空欄にされるとなんかよくわからん。1週間ちゃんと対策すれば7割硬そうだがとりあえず無し

当日ぱっと見、情報システム開発の分野がテストケースの話で点数そこそこ取れそうだったので選択。なんとかなった。

辛かったこと

  • これが一番難しいとされている。会場が家に近かったのでなんとかなった。
  • 会場が寒い。雨の日だったこともあり午前試験で凍えてしまった。次の日から風邪引いた。ちゃんと厚着していくこと。

やってよかったか?

  • 幅広いなんとなくの知識はついた。情報卒コンプレックスは多少解放されたが、次はさらに高度試験受けないと。完全解消にはやはり情報系大学院いくのが良いか。
  • 正直午後試験はもうちょっと時間かけてやった方が身になった。知っている知識でごり押しした。
  • BNF記法とか身近だけどあんまり意識していないものに触れられたのでよかった。
  • 一番よかったことは、勉強習慣がついたこと。受験時代にやったようなことを思い出したので最近プライベートでもいろいろ自発的に学ぶようになった。