第二新卒の転職を成功させる方法【戦略編】

第二新卒で転職した記事がけっこう読まれてるみたいです。

(みんな転職したいんだね…)

 

lyrisist-lily.hatenablog.com

 

ネット上に第二新卒で転職した人の情報があまり転がってないので、自分の体験談は第二新卒で転職したい人にとって価値がある情報だと思います。

有料noteにすることも考えましたが、自分の利益よりも困ってる人の助けになることを優先したいので、無料で体験記を公開します。

 

この記事について

転職の経緯は上の記事に書いているので、この記事では具体的に第二転職での転職活動をどのように行なっていたか?というところにスポットをあてています。

実際にいただいた質問に対する自分の回答を載せています*1が、自分が転職したのがコロナ禍前だったこともあり、同じことをしてもうまくいかない可能性があります。その点にご留意ください。

そもそも第二新卒って?

実は、第二新卒という言葉に法的なものなどハッキリとした定義はありません。一般的には「新卒で入社して3年未満の求職者」を指すことが多いようですが、辞書などで調べてもその解釈はさまざま。

年齢で言えば、4年制大学卒業から考えると25~26歳ぐらいまでになりますが、第二新卒を募集する企業によっても定義が異なるため一概には言えません。

※学校は卒業したが、一度も就職したことがない(社会人経験がない)場合を指す「既卒既卒者)」という言葉もあります。

引用元:https://tenshoku.mynavi.jp/knowhow/nisotsu

(強調は作者による)

自分の場合は浪人(1年)をして学部卒で就業し、社会人2年目で転職しました。

何かを学ぶのに年齢は関係ないとは思いますが、特に専門職の場合は積み重ねがダイレクトに仕事の出来(と給与)に反映されます。

なので「あ、ファーストキャリア間違えたかもしれん」と思ったら早めに職場に見切りをつけるのも大切だと思います。

いつ頃から転職活動を始めれば良いでしょうか?

早くて10月からでしょうか。それよりも前に転職活動を初めてもあまり求人数がないと思います。理由としては

  1. 会社ごとに採用費用が決められている(下期は10月開始の会社が多い)
  2. 新卒採用の結果で調整してから第二新卒の面接をしたい

という会社側の都合のためでしょう。だいたい採用活動が活発になるのは10月以降の会社が多い気がします。なので、10月くらいから転職エージェントに登録したり、話を聞きに行くといいと思います。自分の場合、以下のようなスケジュールで転職活動を行いました。

 

11月:転職活動を始める(エージェント登録、履歴書作成など)

121月:面接

2月:内定職場に退職届を出す

3月:有休消化

4月:入社

前職を辞めずに転職活動したんですか?

はい。無職になると、貯金を切り崩して生活することになるので「どこでもいいから早く就職しなくちゃ」ってなってしまいますなので辞めるのは転職先から内定が出てからの方がいいですね。

また第二新卒で転職する場合、面接官に早期離職者のレッテルを貼られてしまうことに注意は必要です。

Twitterだと毎年GW明けくらいに「入社して1ヶ月で辞めました!」みたいな話が流れてきますが、大抵の会社だと「入ってもすぐ辞めるリスク人材」として捉えられてしまうと思います。

また10月になってもコロナ禍の影響で募集数が減っている可能性があるので「エージェントに登録だけしておいて、気になる募集があったら応募してみる」くらいのゆったりした気持ちで徐々に転職活動をするのもいいかと思います。

入社1年目の10月頃から第二新卒の転職を始めてもいいでしょうか?

いいと思います!私の周りの第二新卒組だと、1年目で転職している人もちらほらいたので。

自分の場合は1年目は営業職で「現職でもう少し頑張りたい」と粘っていましたし、そもそも成果を出せないまま辞めてしまうことに抵抗がありました。

とはいえ、頑張れども頑張れども成果は出ず、「逃げ出したい」と思うようになりました。前職では営業からレポート作成関係の部署へ配属転換もしてもらったのですが、前職の会社全体の業績が悪かったこと、やりがいのある仕事がなく、自分の成長に繋がらないことがどうしても受け入れられず、2年目の秋に「やっぱ無理だ!転職しよう!」と決意しました。

 

転職活動は大変ですか?

仕事をしながらの転職活動だったので時間の調整が難しかった、というのはあります。幸い前職でフレックス制度を使えたので早めに退勤して面接することができましたが、そうでなければ面接の調整で手こずっていたかもしれません。

また以前は大阪在住で、応募していた企業の所在地が東京だったのでスカイプなどで面接/面談することが多かったです。

また二次面接以降では実際に顔を合わせて面接している企業が多かったので、そのたびに東京まで面接に出向いていました。

週末が面接で埋まってしまうので少し疲れましたが、とはいえ希望する仕事をしたいという気持ちや、とにかく現状から抜け出したいという気持ちがあれば、なんとかなると思います(急に根性論でごめんなさい)。

 

直接応募、エージェント経由、どちらがいいの?

「エージェントでも自社サイトでも募集をかけている場合」であれば、自社サイトから応募した方がいい、という話は聞いたことがあります。エージェント経由で採用が決まった場合は企業がエージェントに報酬を支払うシステムになっているので、企業側はできるだけ採用活動にかけるお金を節約したいみたいです。

知り合いの採用担当者は「自社サイト経由で応募してきた場合とエージェント経由で応募してきた場合、ほかの条件が一緒だったら自社サイト経由で応募してきた人を採用する。」と言ってました。

エージェントに求人数は結構あるもの?

業界や業種、自分の希望する待遇にもよると思います。自分は5、6個くらいエージェントに登録してたこともありますが、求人数は結構ありました。大抵のエージェントは毎週水曜日に求人情報を更新していたので、毎週それをチェックして応募していました。

求人のチェックと応募を習慣にしてしまえば機械的に作業すればいいだけだけなので楽です。

エージェントを利用すると無料で履歴書の添削をしてもらえたり、面接の日程を調整してもらえたりするので便利ですよ。

 自分が使ったエージェントについて、以下に紹介しておきます。

doda

個人的に一番使いやすかったです。

担当者が付いて、自分の希望やアピールポイントを洗い出してくれました。

あと担当者とLINEやり取りできるのもよかったです。仕事していると電話に出れないことが多いので…

doda.jp

エン転職

求人数と質がちょうどいい感じでした。

employment.en-japan.com

 

リクナビネクス

案件数は多いのですが、質が自分の希望するものとは一致していなかったです。あと担当者が鬼電してくるので対応が面倒でした。

next.rikunabi.com

Green

またIT系に特化した転職サイトにGreenがありますが、これは求人数が多い割に質がイマイチな印象でした。ベンチャーが多い。

www.green-japan.com

 

ビズリーチ

www.bizreach.jp

コンサル系のいわゆる「ハイクラス求人」が多かったですが、とある企業とカジュアル面談をしたら「それってコンサルじゃなくて反響営業では」と思う場面が多かったですね。コンサルの定義なんて人によるんでしょうが・・・。

またBizリーチに登録すると企業のオファーに返答できる他に、小規模なエージェントとも面談して案件を紹介してもらえます。これが割と良質な求人を提案してくれるところもあったのですが、第二新卒の求人数は少なめという感じでした。

あとBizリーチ経由で面談したエージェントで割と鼻につく感じの人が多かったのであんまり好きじゃなかったです。そもそも自称ハイクラスってかなり痛くないですか。

 

TOEICの取得は転職に有利になりますか?

ぶっちゃけ関係ないですもし担当業務に英語が必要ならTOEICでハイスコアを出した方がいいでしょう。また当然ながら外資系を受ける場合はTOEIC頑張った方がいいと思います。これは募集要項にスコアの基準が書いてあると思うので、それを満たしていることを履歴書に書いておきましょう。

 

↑とはいえアルクTOEIC講座は続けやすくてスコアアップに一役買ってくれました。エンジニアだと英語読めないと話にならないので、TOEICの勉強はやっといて損はないと思います。

 

プログラミングスキルは転職でアピールできますか?

これも先のTOEICや簿記と同じで、応募先の職種にもよると思います。

「業務に活かせるものならなんでもアピールに使う」のがいいと思いますが、転職先と関係ない資格であれば特にアピールには使えないと思います。

Pythonを使って業務を効率化しました!」みたいな事が言えればいいのですが、プログラミング(と環境構築)は周囲にフォローしてもらえないと習得が難しいと思いますし、そのためにプログラミングスクールに高額な費用をかけるのはちょっと違う気がします。

代わりにOffice関係の資格(MOSなど)は取っておくといいかもしれません。どの業界でも業務でExcelを使う場面はありますし。

mos.odyssey-com.co.jp

関数を組んだり、マクロを設定したり、VBAExcelで使えるプログラミング言語のようなもの)を使えるようにしておくとどの職場でも重宝されると思います。

 

またプログラマーやエンジニアとして転職する場合、コーディング試験があったりする場合もあるのでプログラミングスキルがあることに越したことないと思います。

(自分はコーディング試験がないところばかり受けてましたが…)

 

何かあれば質問どうぞ

他にも質問があればTwitterhttps://twitter.com/wakavaaaa)までどうぞ。

この記事が少しでもお役に立てれば幸いです。

 

*1:質問者からの承諾を得ています

ソフトウェアのテストをするわよ!

単体テストをするにあたって、テストデータの作り方がわからない!となったので記事にまとめておきました。ソフトウェアの開発プロセスではコーディングの後にテストを行い、これをクリアしたら結合テスト以降へと進んでいきます。

共通フレームでのテスト関連の流れ

コード作成→単体テスト→ソフトウェア結合→ソフトウェア適格性確認テスト→システム結合→システム適格性確認テスト

この中でテストデータを作成するにあたって必要だった知識をまとめておきます。

テスト計画:テスト観点の選定 

テストケースを作成する際、どういった観点に基づいて評価を行うのかが「テスト観点」としてまとまっています。ソフトウェアを製造する会社であれば、何かしら「テスト観点一覧表」のようなものがあり、その中から今回自分が携るテストでは何を採用すべきなのかを取捨選択することになると思います。

例えばスケジュール管理システムであれば「実在する日時が入っているか」「日時の入力形式はあっているか」「登録されたスケジュールを正しく表示しているか」といったものがテスト観点です。

また、こうしたテスト観点はT.Ostrandの提唱する以下の4つに分類できます。

User-view(ユーザー視点)

例えば、データ登録機能のテストを行う場合、User-view(ユーザー視点)では、実際のユーザーの動きを想定した、正しいデータの入力をした場合、間違ったデータを入力した場合などをテストします。

 Spec-view(仕様視点)

求められている仕様をきちんと満たしているか、正しい動きをするのかをテストします。

Fault-view(バグ視点)

入力途中で通信が切れた場合や、異なる形式のデータが送られてきた場合など、考えられるバグや、わざとバグが起こりそうなことをテストします。

Design-view(設計・実装視点)

設計の構造自体にバグはないか、動作していても脆弱な実装になっていないか、などをテストします。

https://webrage.jp/techblog/software_testing_point_of_view/ 

またこの他にも、ソフトウェア品質評価に関する国際規格(ISO/IEC 25000)では、機能性、信頼性、使用性、効率性、保守性、移植性の6つを評価されるため、それらを意識したテスト観点をもつことも、国際的な信頼の確保に有効です。

https://webrage.jp/techblog/software_testing_point_of_view/

 

またこうしたテスト観点で「条件を網羅しているか」「入力値が正しく処理できているか」を判定するためのテストは以下のように「ブラックボックステスト」「ホワイトボックステスト」があります。現在はこの用語自体が使われる場面は減ったと思いますが、テスト観点の中には必ず含まれています。

ホワイトボックステスト

テスト対象関数またはメソッドの内部構造に着目し、条件分岐や繰り返しなどの各部分を確実にテストします。関数・メソッド中のすべての命令を実行する命令網羅(ステートメントカバレッジ)、すべての分岐条件で真/偽の両方の分岐を通るようにする判定条件網羅(デシジョンカバレッジ、または分岐網羅、ブランチカバレッジとも呼ばれます)などがあります。そのため、網羅率の測定(カバレッジ解析)や条件を網羅するためのテスト値の抽出などが必要になります。

ブラックボックステスト

テスト対象関数またはメソッドの外から見た機能(入出力)に着目し、コードが期待される機能(仕様)を満たしているかどうかを検証します。仕様に関わる検証であるため、テストケースの作成や結果の確認には、人間による判断が必要になります。

https://www.techmatrix.co.jp/t/quality/unittest.html

 どのテスト観点を採用するかは案件(の予算)によって異なるため、案件ごとに観点一覧表から適当なテスト観点を選択する必要があります。

 

静的解析ツール

どのテスト観点を採用するかを決めたら、まず静的解析を実施します。静的解析は、コードを実行せずに行なう検証です。単体テストを行う前に実施することが多いと思います。静的解析ツールで検出できる問題は以下の通りです。

コードの可読性に関する問題

また静的解析ツールを使用した際のメリットは以下の通りです。 

  1. 優れたコーディングパターンを自動的に推進でき、コードが任意のコーディング標準に準拠していることを確認できる。
  2. アプリケーション独自のエラー(発見されたエラーの再発防止) テストでバグが発見されたとき、バグの原因を突き止めて、コード中に他に同じような問題を持つ箇所がないかどうかを確認できる。
  3. バグの原因となったコーディングパターンを、避けるべきパターンとしてルール化すれば将来にわたって同じバグが発生するのを防止できる(発者の負担を増やすことなく、エラー再発防止策を自動的に開発プロセスに組み込むことができる)

  https://www.techmatrix.co.jp/t/quality/static-analysis.htmlより一部改

3の「ルール化」に関して静的解析ツールはコードが必要以上に複雑になることを防ぎます。この機能を「メトリクス解析」と呼び、以下のような観点でコードを解析します。 

メトリクス解析

  • クラス、メソッド、メソッド引数などの数
  • クラス、メソッドの処理の複雑さ
  • クラス間の依存関係

単体テストユニットテスト

静的解析ツールを通したら単体テストを実施します。

単体テストユニットテストと呼ばれることもあります)は、プログラムを構成する比較的小さな単位(ユニット)が個々の機能を正しく果たしているかどうかを検証するテストです。

https://www.techmatrix.co.jp/t/quality/unittest.html

単体テストを実施するにあたり、コードで呼び出す/呼び出されるモジュールが作成されていない場合があります。(呼び出し元の設計が追いついてなかったりする場合ですね…)

f:id:lyrisist-lily:20200920151629p:plain

(引用元:https://www.techmatrix.co.jp/t/quality/unittest.html

このような場合は実際の呼び出し側の代わりにテスト対象を呼び出すドライバ

実際の呼び出し先の代わりにテスト対象から呼び出されるスタブを作成します。

 

ドライブ、スタブはテストデータとは別のフォルダに格納することが多いようです。

 

テストの評価

テストの進捗管理をする際に役に立つ指標が「カバレッジ」です。テストの性能を評価する際にも使用されます。

 

カバレッジは、所定の網羅条件がテストによってどれだけ実行されたかを割合で表したものです。

網羅条件が命令であれば、命令網羅と呼ばれ(またはステートメントカバレッジC0とも呼ばれます)、すべての実行可能な命令のうち、テストで実行された命令の割合を意味します。

そのほかに、すべての判定条件(if文による分岐など)のうち、テストで実行された判定条件を意味する判定条件網羅(ブランチカバレッジC1とも呼ばれます)などがあります。

https://www.techmatrix.co.jp/t/quality/coverage.html

 

 

以上!!

あれから僕たちは何かを信じてこれたかな

「自分のことを信じられない」という気持ちが若干ある。

自分自身に対する不信感は、自分の心と体をコントロールできないことによるものだ。

 

最近は新しい職場にもインチュニブにも慣れてきたけど、

昨晩は知らないうちに寝てしまい、午前3時に目が覚めた。

寝落ちする前の行動を思い出せなくて困惑した。

 

少し薬の量を増やしたので意識がシャッキリしている時間は長くなったが、

その分副作用も強く出ているのだと思う。

 

昨晩はおそらくインチュニブの副作用で眠ってしまったのだけど、インチュニブの薬効が切れた頃に多動で目が覚めたのだと思う。すごく仕組みがわかりやすい。

 

自分はカフェインでお腹が痛くなりがちなので、眠気対策としては「昼寝をすること」ぐらいだろう。

ーー

終業してから、同期とLINEをした。

同期が「基本情報技術者試験が延期になった」というニュースを教えてくれた。

そこから資格取得の話になり、AWSのトレンドの話になり、現時点での仕事内容に関する話になった。

 

その同期と自分は同じプロジェクトチームに属している。

3週間ほど一緒に働いてみて、彼は仕事を断るのが苦手なタイプと言うのがわかった。

とはいえ依頼ごとに全て対応できているので、そもそも断る必要がないのかもしれない。チーム全員からの質問を受けて、所属元の仕事(雑務)もこなし、プロジェクトの仕事も前倒しで実施していた。

とはいえ口には出さないが、彼が他のメンバーの質問に対応をしている時、少し困った表情をしているのが気がかりだった。

 

自分が他人のことを「気がかり」だと思うのは初めてのことだった。

気がかりと言っても不安ではなく、

「守らなければいけない」とか「役に立ちたい」といった前向きな気持ち?

 

彼に限らず、他のメンバーのひととなりがわかってきた。

声色がいつもより低いだとか、体調を崩してお休みしているだとか、「胃が痛い」と言う話を聞いたりして、その度に全員に対して「気がかり」にはなっている。

そして気遣いの言葉をかけたりしている。

(自分が前職時代に体調を崩た時、先輩から気遣いの言葉をかけられると孤立感が減り、とても安心した)

 

そんなところを見てくれていたのか、先の同期から「しっかりしてるね」と褒めてもらえた。こんな言葉をかけられたのは人生で初めてのことだった。

ーー

 

私はこれまで「信頼できない」と言われる側の人間だった。

自分をコントロールできないので自分でも自分を信じられないし、他人のことは自分を攻撃してくる敵だと思っていた。

だけど今は同期のことを守りたい、だとか、人生を良いものにするために貢献したいと本気で思っている。

 

「何かを信じる」とか「信頼する」という状態がどんなものなのか、正直今でもよくわからない。だけど、役に立ちたいとか、そういった気持ちがある。

ーー

宮沢賢治の評論で見田宗介の本がある。

その中で宮沢賢治の自分自身を憎む気持ちを「焼身願望」と言う形に結実するものの、世界の美しさ(本の中では「存在の祭り」と呼ばれている)に触れることで,現実の世界に帰っていくという話をしている。

本の中身は忘れてしまったので「存在の祭り」どのようなものだったかは思い出せないが、自分自身は会社の同期の美しさに触れて、ようやく地に足が着いてきたように思う。

宮沢賢治―存在の祭りの中へ (岩波現代文庫―文芸)
 

 

僕のメンタルのヤバいやつ

今日はちょっと多動で寝付けないので日記を書く。

 

最近、浅い眠りの中で自分が暴れていたり、暴言を吐いたりしている。

そして、自分で自分の行動にびっくりして起床する。

頻度としては3日に1回程度。

ーー

確か去年の今頃は心身共にヤバくなっていた。少しだけ無理な労働や勉強をしていたら、熱が出た。しかし当時はそんなことも気にせず出社していた。

金曜日に「やっと休みだ」と思って寝ていると、激しい咳で目が覚めた。

咳き込んだついでに吐いてしまい、吐瀉物が気道に入ってしまった。

咳が咳を呼び、止まらない。過呼吸になってしまっていた。「あ、これ死ぬかもしれん」と思いながら絞り出すように深く咳き込んだ。

意識が朦朧とし出したが、救急車を呼ぶべきかわからなかったのでスマホで♯7119を押した。♯7119は救急車を呼ぶべきか相談できるダイヤルだ。

ーー

「呼吸できません」と相談したら救急車を手配するから住所を言うように伝えられた。

(それはそうだ)

幸いにして、休日に急患に対応している病院の近くに住んでいたので5分くらいで救急車が到着した。

キャスター付きのベッドに横たわり、自分の現在の体調と経緯を告げる。

ーー

問診や採血、レントゲンの撮影をし、1週間ほど入院することになった。

病名は忘れてしまったけど、気道がひどく炎症を起こしていたらしい。

 

入院して初めの2日間は急患用の部屋にいた。

ナースセンターが近く、目が届く安心感はあったが、同室の患者が昼も夜も何か叫んでいた。当時の恋人にお願いしてCDプレイヤーとCDを持ってきてもらい、昼も夜もBill Evansの「Never Let Me Go」を聴いていた。

youtu.be

 

主治医は無駄なことは聞かず、淡々と対応してくれた。自分とそこまで年齢が変わらない、若手の医師だったと思う。

4日目にもう退院できると告げられた。

「この度はお世話になりました…ちょっと仕事で張り切り過ぎちゃいました。もう無理しないようにします」と言うと、主治医は少し考える素ぶりをして

「他人に迷惑をかけること、自分の健康を守ることができれば何してもいいですよ」と返してきた。

てっきり「無理しないようにしてくださいね」と返されると思っていたので、少し意外だった。たぶん主治医は自分よりも苦労し、なおかつ乗り越えてきた人なんだろう。

これまで医学部に合格し、国家資格を取り、そしていま深夜の急患対応をしている人間がこれまで抱え、乗り越えてきた問題と苦悩に想いを馳せた。

 

ーー

冒頭に書いたが、最近少し睡眠障害の気が強まっている。

入院した時の同室の患者(全員がお婆さんだった)に似てきている。

誰彼構わず、昼夜も問わず、1人の人間が叫び続ける光景。

こんな光景に遭遇すると、自分の感情を喜怒哀楽のどこに分類すればいいのかわからなくなってしまう。そして自分自身が浅い眠りの中で叫び、暴れている。

インターネットで自分の障害と思われる単語で調べてみると「時には隣で寝ているの人の首をしめることもある」と書いてあった。

この症状自体は薬を飲めば収まるものの、自分の行動に責任を持てない上、他人に危害を及ぼしてしまう可能性がある、と言うだけでとても怖い。

 

今のところ睡眠時だけの症状だが、覚醒時に自分が他人を殴ったり、危害を加えていたらどうしよう…と考えてしまう。

 

変身(インチュニブで)

「ある朝、グレーゴル・ワカバがなにか気がかりな夢から目をさますと、自分が寝床の中で一匹の普通の人間になっているのを発見した」

インチュニブという向精神薬を飲んで3日目のことだった。

カーテンを開けると、ベランダには枯れた植木鉢が3つ。服を着替えようとクローゼットを開けると、そこには服がぐちゃぐちゃに詰められている。本棚の本は雪崩を起こし、台所はシンクに鍋が2つも放置されている。

 

「一体ここはどこなのだろう…?」

 

確かに自分の部屋で寝ていたのだけど、寝ている間に誰かが部屋に入り込んできて部屋をめちゃくちゃにしていったのではないかと思えてくる。

自分の身体は昨日の自分と同じものだし、記憶は繋がっているのだけど、自分を操る自分というか、自分を認識する自分が他の人と入れ替わったような気がする。

これまでの連続性が失われた感じ。

ーー

2020年の時点で日本で発達障害の症状を改善するための薬は3つ認められている。

コンサータストラテラ、インチュニブだ。

 

コンサータはちょと管理が難しく、乱用防止のために手続きを色々しないといけなくなってしまった。ストラテラは効くのだけど副作用(吐き気、胃痛、頭痛、悪夢)があり、あまり飲めなくなっていた。

ストラテラを飲みたいが副作用で飲みにくい」と医者に相談したところ、インチュニブを処方されるようになった。

インチュニブはもともと高血圧用の薬として開発され、これまで小児の発達障害の薬としても使用が認められていた。2018年に大人の発達障害にも処方されるようになった。

インチュニブは副作用として眠気があるのだけど、就寝前に服薬すればちょうどぐっすり眠れる。日中にも眠気が出ることは出るのだが、15分の休憩を2回ほど取れば十分だった。この程度であれば日常生活に支障は出ない。

ーー

カフカの『変身』ではある日突然虫になってしまうが、私の場合はある日突然「普通の人間」になり、これまでの自分が虫だったことに気付く。

 これまでの自分を虫と呼ぶことに若干の抵抗があるのは、虫が嫌いだからだろう。

虫には虫の認知があり、生活がある。それはそれで忌み嫌うものではないし、人間社会の中に虫が溶け込むのも可能ではある。ただ人間から人間として扱われたければ、虫が人間の真似をするのでは不十分で、人間そのものになる必要がある。

いまさら人間扱いされなかったことに対して被害者ヅラをするつもりはないが、

まあなんというかこれまでの自分は虫だったんだなあ、と思う。

虫は虫扱いされるのが当然だ。

 

しんみりしてもどうしようもないので、これからの日々を淡々と過ごしていきたい。

インチュニブを製造している武田薬品のみなさん、処方してくださった品川こころのクリニックのドクター、そしてこれまで応援してくれた人に感謝したい。

インフラ設計〜保守運用をするわよ!

前回はソフトウェア設計の方法をみたので、今回はインフラについて。

 

 この本で取り上げられていたのは要件定義〜基本設計のフェーズ。実際に参加するプロジェクトは保守や運用から入ることになりそうなので、実務とは少し乖離がある前提を頭に入れながら読み進める。

 

コンピュータシステムにとってインフラとは

そもそもコンピュータシステムにとってインフラとは何だろう?

 

インフラというのもともと、サービスや機能を提供するための土台を指す。

ことにコンピューターシステムにおいては以下のような要素が「システムインフラ」と呼ばれる。

  • ハードウェア
  • ネットワーク
  • オペレーションシステム
  • ミドルウェア

システムインフラでは利用者が不都合なくサービスを利用するために、安定したサービスを提供すること、また障害に備えた仕組みづくり、将来の拡張性などが求められる。

 

 

インフラエンジニアが担う設計範囲

そしてインフラエンジニアが担う設計範囲は以下の3点。

 

インフラの設計工程では要件定義書をインプットにする。

アウトプットに基本設計書(概要設計書、外部設計書など)詳細設計書(パラメータ設計書やプログラム設計書、内部設計書など)を作成する。

製造工程

前工程での設計に従って、システム環境を構築するのがインフラでの製造工程に該当する。具体手にはOSのインストールやミドルウェアの設定など。

システム設計の内容通りに環境構築を行うため、まずは構築手順書構築後の検証手順書を作成する。

 

テスト工程

テスト工程では、構築したシステム上で開発したOS、ミドルウェア、アプリケーションなどが要件定義、設計通りに正しく動作することを確認する。

テスト工程には、以下のようなテストがある。

単体テスト

プログラムを構成する部品ごとに、動作確認をするテストのこと。インフラエンジニアによる単体テストでは、サーバ単体でのOS、ミドルウェアによる機能確認を行う。

結合テスト

部品間の接続(インターフェース)の動作確認をするテスト。インフラエンジニアによる結合テストでは、サーバ間のOS、ミドルウェアの機能間連動確認を行う。例えばWebサーバとDBサーバを連携させるようなテスト。

システムテスト

本番運用を想定したシステム全般に関するテスト。本番運用を想定するため、日次、週次、月次、年次に発生するシステムの運用を実際に稼働させて動作確認や検証などを行い、システム要件が満たされているかを確認する。

例えば、以下のようなことを検証する。

・ピーク時のレスポンスおよびスループットが要件を満たしていることを検証

→高負荷状態でもシステムリリースに問題ないか

・障害発生時や災害発生時のシステム切替・回復・業務復旧の一連のプロセスを検証

→機能および手順の妥当性・通常日、特定日などイベントを狙った実際の稼働シナリオテストを検証

→実際の稼働時と同じ状況下で業務設計を行い、機能面や性能面での問題がないか

運用テスト

システム運用部が実際のオペレーションマニュアルに基づき、本番同様の動作環境と運用体制でシステム全体の機能や運用についてテストを実施する。

ユーザ受け入れテスト

導入後のユーザ業務利用を想定したテスト。

業務利用ユーザが業務要件を充足しているかを確認して行う。また業務フロー、事務手続きと整合性が取れているかの最終確認も打鍵して行う。

インフラ設計のセオリー --要件定義から運用・保守まで全展開 p28

運用保守工程

システム稼動の開始後、システムの安定稼動を目的にシステムの運用保守を行う。

運用保守業務の代表例は以下の通り。

監視運用

障害や不具合の早期発見を目的に行う運用。

以下の5点を行う。

プロセス監査

サービス継続のためにサーバ上で稼動し続ける必要のある特定のプロセスが支障なく稼動しているかを確認する。例えばWebサーバであればhttpプロセス、APサーバであればWebアプリケーション・サーバのプロセス(Javaプロセス)が監査対象のプロセスとなる。

 

メッセージ監査

エラーログ監査のこと。システムに異常が発生した時、OSや製品にエラーメッセージが出力されるので、これを定期的に監視する。

 

リソース監査

システムを構成するサーバのCPU、メモリ、ディスクなどの各種リソースが適切に使用されているかどうかを監視する。監視基準として、一般的には各リソースの使用率が使われる。例えばCPUであれば、要件定義の段階で「CPU使用率が@%以下となるシステム構成を採用する」といった形で定義されるので、この値を越えることがないように監視を行う。

そして監視結果として、ある通知が行われた場合、この通知が一時的なものだったのか、継続的に発生する可能性があるものなのかを見極める。

ハードウェア監査

通常、ハードウェアになんらかの障害が発生した場合、その障害発生を示すログファイルが出力される。ハードウェア監査では、これらログファイルにエラーが出ていないことを継続的に確認する。

ジョブ監査

バッチ処理が予定した時間に終わっている、あるいは予定された時刻までに完了している、といった定期的な実施処理が想定の範囲内に開始、完了しているかを監視する。

実行すべきジョブが全て正常に実行され、正常に終了されているかの監視を行うと共に、遅延が生じていないかを確認する。

 

バックアップ運用

バックアップにはシステムバックアップとデータバックアップの2種類ある。

システムバックアップはOSを含むイメージバックアップ。システム障害からの復旧を目的としている。

データバックアップはデータ破損や紛失に備えて復旧するためのバックアップ運用。

なぜバックアップが必要なのか?

業務で使用するデータは、業務サーバが使用している「物理的なディスク上」に書き込まれています。しかしながら、残念なことにディスク装置は10年利用出来るものではありません。

ディスクは磁性体がついた円盤をモーターで回転させながら利用するストレージ媒体であるため、必ずいつかは壊れてしまいます。

さらに、予測できない不慮の事故のためにディスク装置が壊れてしまう可能性もあります。ディスク装置が壊れていなくてもOSが起動しなくなる可能性もあるのです。

https://www.activeimage-re.com/column/backupcolumn01.html

HDDはディスクを物理的に円盤を回すので衝撃で傷ついていつか壊れてしまうし、SSDフラッシュメモリも年々劣化するらしい。

こうしたディスク装置はバックアップが必要。

ウイルス対策運用

アンチウイルスソフトの導入やパターンファイルと呼ばれるワクチンソフトを定期的に更新するなど。

バッチ、ファームウェア運用

ウイルス対策同様、システムに悪影響を及ぼす可能性を排除するためにセキュリティパッチやファームウェアの適用を定期的に行う。

自動化運用

定期的なサーバの再起動やログ転送などを自動で運用する仕組みのこと。

シェルスクリプトでの自動化処理開発など。

 

ITサービスマネジメント

ITサービスを運用する上で、問い合わせ対応などの業務も欠かせない。

ITサービスマネジメントのベストプラクティス集であるITILには以下のような業務が載っている。

 

サービスサポート:日常的なサービス運用

・サービスデスク:利用者からの問い合わせを受け付ける

・インシデント管理:障害などのサービスを阻害する事象(インシデント)に対応し、サービス状況を回復する

・問題管理:インシデントが発生した根本的な原因を解決し、未然に防ぐ

・サービス資産管理および構成権利:所有するIT資産を正確に把握し、管理する

・リリース管理および展開管理:実際に変更を実施し、ユーザー教育などを行う

 

障害対応の一般的な手順は以下の通り。

受け付けと記録→分類・判別→(可能なら)応急処置→優先度決定→原因究明・解決

 

サービスデリバリ:中・長期的なサービス業務

・サービスレベル管理:サービス品質(水準)について合意・管理する

→利用者と提供者がサービス水準について交わす合意のことをSLAと呼ぶ

・ITサービス財務管理:会計処理や課金処理などを実施する

・キャパシティ管理:負荷に適切に対応できるか監視し、必要ならば修正する

・ITサービス継続性管理:緊急事態における復旧処置などを検討・実施する

・可用性管理:信頼性や保守性を高める

 

ソフトウェア設計をするわよ!

今週はSpring(Javaフレームワーク。ファイルがめちゃ多い)を使ったソフトウェアの設計をしたので、ソフトウェア開発全体の流れを書き残しておこうと思います。

エンタープライズアーキテクチャ

組織全体の業務とシステムを統一的な手法でモデル化したものをエンタープライズアーキテクチャと呼ぶ。次の4階層で体系化されている。

設計段階のうちどのフェーズが完了しているのか、また、これから何を検討しないといけないのかを把握するために以下の用語は(SIerにいる人は)略称も含めて覚えておいた方が良さそう。

 

ビジネスアーキテクチャ(BA):業務活動

データアーキテクチャ(DA):企業が利用する情報やデータ

アプリケーションアーキテクチャ(AA):情報システムの構造

テクノロアーキテクチャ(TA):システムに必要な各種技術要素

 

ソフトウェア開発の流れ

システムの発注側と受注側がシステム開発について、作業分担について明確な認識を保つためにガイドライン「共通フレーム」が制定されている。共通フレームはISO/IEC 12207:2008 の翻訳である JIS X 0160:2012に準拠している。何が言いたいかというと、世界水準に準拠してるよってこと。

 

最新版の「共通フレーム2013」では

企画プロセス、要件定義プロセス、システム開発プロセス、ソフトウェア実装プロセス、ハードウェア実装プロセス、運用・サービスプロセス、保守プロセスを規定している。

 

https://www.ap-siken.com/kakomon/30_aki/img/65.gif

https://www.ap-siken.com/bunya.php?m=18&s=1&no=1

 

それぞれのプロセスで何を決めているのかを見ていきます。

企画プロセス

システム化構想の立案システム開発計画の作成が行われる。

システム化構想の立案段階では、 以下のような点に注意して課題の整理を行う。

  1. 経営上のニーズ、課題の確認
  2. 事業環境、業務環境の調査分析
  3. 現行業務、システムの調査分析
  4. 情報技術動向の調査分析
  5. 対象となる業務の明確化
  6. 業務の新全体像の作成
  7. 対象の選定と投資目標の策定

またシステム開発計画では経営事業の目的、目標を達成するために必要なシステム化の方針やシステムを実現するための実施計画を策定する。

たとえば、平成30年秋の応用情報技術者試験ではこんな問題文が出ている。

AIなどの情報技術を利用した自動応答システムを導入して,コールセンタにおける顧客対応を無人化しようとしている。

この企業が,システム化構想の立案プロセスで行うべきことはどれか。 (平成30年秋 問65)

 ここでの正解は「AIなどの情報技術の動向を調査し,顧客対応における省力化と品質向上など,競争優位を生み出すための情報技術の利用方法について分析する」。この問題で問われているのはあくまで立案プロセスなので、具体的にどのようなシステムにするかといったような文言が入っている選択肢は誤りとなる。

(具体的なスケジュールや開発体制、概算コストなどを策定するのはシステム化計画の段階)

 

要件定義プロセス

要件定義プロセスでは、業務上実現すべき要件である業務要件定義と業務要件を実現するために必要な情報システムの機能を明らかにする機能要件定義、パフォーマンスや信頼性、移行要件などの非機能要件定義がある。

システム開発プロセス、ソフトウェア実装プロセス

ウォーターフォールモデルでの各工程は以下の通り。

ウォーターフォールモデルの流れ

f:id:lyrisist-lily:20200819144316p:plain



引用元:http://www.pursue.ne.jp/jouhousyo/sysad/kaihatu/water_fall.html

 

 

外部設計、内部設計では「何をやっているか」「どのような成果物が必要か」まで知っておく必要がある。

要求仕様書を元に、利用者の立場から見た論理的な設計をするのが外部設計で、

外部設計書に基づき開発者の立場から物理的な設計をするのが内部設計

外部設計

操作画面や操作方法の構成(ユーザーインターフェース)や、帳票など印刷物の書式、ハードウェアや他のソフトウェアとの接続・連携仕様、データベースの構造などを決めることが多い。

外部設計(ED)とは - IT用語辞典 e-Words

 

帳票設計

こでは単に紙に印字されるものだけではなく、PDFファイルやCSVファイルの形態で電子的に出力され 、後からプリンタで印字が可能な出力物も帳票の一種として扱っています。

https://www.ipa.go.jp/files/000004517.pdf

論理データ設計

システムに必要なデータ項目を選定し、入力データ項目と出力データ項目の関連性(データ構造)、ファイル仕様などを決める。代表的な成果物は下記の通り。

 

ER

情報のまとまりを「エンティティ」、情報の相互関係を「リレーションシップ」として、利用するデータをモデル化して表現したもの。エンティティとリレーションを表現するシンボルを用いて作図する。業務で取り扱うデータ構造を発注元に確認できる。

❷エンティティ一覧

❸エンティティ定義

CRUD

業務とエンティティの関係を示したもの。

 

https://www.ipa.go.jp/files/000004517.pdf

 

内部設計

機能分割・構造化

サブシステムをプログラム単位に分割する

物理データベース設計

ファイル構成法、記憶媒体、レコードレイアウトを決め、アクセス時間や要領などを見積もる

入出力詳細設計

外部設計を元に、さらに具体的な画面設計、帳票設計を行う。 

 

テスト

共通フレームでのテスト関連の流れ

コード作成とテスト→ソフトウェア結合→ソフトウェア適格性確認テスト→システム結合→システム適格性確認テスト

 

ブラックボックステストホワイトボックステスト

ブラックボックステスト:外部仕様に着目してテストケースを設計

同値分割→同値クラスごとに代表値をとる

限界値分析→同値クラス間の境界値をとる

 

ホワイトボックステスト:内部制御構造に着目してテストケースを設計

命令網羅→全命令を実行する

判定条件網羅(分岐網羅)→全分岐を実行する

複数条件網羅→各条件の全組わせを網羅する

 

結合テスト手法

トップダウンテスト

・最上位から下位に向けて結合していく

・仮の下位モジュールであるスタブを利用

 

ボトムアップテスト

・最下位から上位に向けて結合していく

・仮の上位モジュールであるドライバを利用

・並行して複数のテストを進めやすい

 

システムテスト

以下のようなテスト群で設計仕様を満たすかを確認

・機能テスト:機能仕様を満たしているかを検証

・性能テスト:スループットなどのシステム性能を検証

・負荷テスト:負荷をかけ、業務に耐えられるかを検証

・例外テスト:エラー処理などを正しく表示するかを検証

保守プロセス

保守プロセスは、障害への対応、性能の改善などを行うために、納入後のシステムやソフトウェアを修正すること、又は変更された環境に適合させることを目的とする

平成25年春期問41 保守プロセスの目的に関する説明|ITパスポート試験ド

ットコム

 

 

ソフトウェア設計の感想

とにかく画面遷移図を見ながら外部設計、内部設計を進めていきました。

また各種UMLについて、あらかじめどのような図が存在しているのかは理解できていましたが、各種UMLの特徴はつかめていなかったのを痛感しました。

「イベント名を知りたい場合はどの図?」みたいな疑問にスッと答えられるようになりたいと思います。

今回はそれができず、参照する際に関係ないファイルをたくさん開いてしまいました。

 

またSpringはOSSなので、何か変更があった際に品質の保証ができません。

なので社内で別途部品として保存して・・・(「ラップ」というらしい)という作業が必要なんだとか。

こういった作業をして、社内で使える共通フレームや部品を提供している人とは仲良くしておこうと思いました。