ITドカタの転職 一次面接で聞かれた質問集【回答編】

私が担当していた工程は、設計〜構築〜運用までです。

特に構築フェーズでは、以下2点を強く意識していました。

工夫①：設定項目は必ずダブルチェックする

構築作業で最も気をつけていたのは、
設定項目を必ずダブルチェックすることです。

これは上司から言われた、
今でも強く印象に残っている言葉がきっかけです。

「どれだけ経験が長くても設定ミスはある。
“この人なら大丈夫”という固定観念を捨てろ」

この言葉を聞いて以降、
自分の設定を過信しないことを徹底するようになりました。

一度設定した内容も、
・設計書
・パラメータシート
・実際の設定値
を照らし合わせて確認し、
「本当にこれで良いか？」を自分で問い直すようにしています。

結果として、
構築後の手戻りや初期トラブルを減らすことができたと感じています。

工夫②：自分が行った設定は必ずログとして残す

もう一つ意識していたのが、
自分が行った設定を必ずログとして残すことです。

これも上司から教わった考え方で、

「トラブルが起きたとき、
設定ログがあれば上司もすぐ把握できるし、
お客様への説明もしやすくなる」

という理由からです。

具体的には、

• LinuxなどCLI操作の場合
  → 実行したコマンドや設定内容をテキストエディタに貼り付けて保存
• Windows ServerなどGUI操作の場合
  → 重要な設定画面はスクリーンショットを残す

という形でログを残していました。

この習慣のおかげで、
・トラブル対応時の切り分け
・上司への状況共有
・後任者への引き継ぎ
がスムーズになり、
「作業が属人化しにくい環境」を作れたと感じています。

Windows ServerのHW保守切れに伴う、
サーバ機器更改案件を担当しました。

HW保守切れ案件は、

・止められない
・延ばせない
・トラブルがそのまま障害になる

という前提があり、非常に大変なプロジェクトでした。

一番の課題は「全体が見えない」こと

この案件で一番大変だったのは、
既存環境のドキュメントが不十分で、

・どのサーバが
・どのシステムで
・何に使われているのか

が一目で分からなかった点です。この状態で更改を進めるのは
リスクが高いと感じました。

まずやったのは設定差分の見える化

そこで、
既存サーバと更改後サーバの設定値対応表を作成しました。

・そのまま使える設定
・変更が必要な設定
・新たに追加された設定

を整理し、注意点は赤字で明示しました。

対応表を作ったことで、

・メンバーが確認ポイントを把握できる
・上司がリスク箇所を把握しやすい
・想定外の設定差分を減らせる

という効果がありました。

トラブルが起きたときに一番大事だと思っているのは、

「すぐ直すこと」よりも「状況を正しく把握し、共有すること」 です。

焦って場当たり的に対応すると、
かえって被害が広がることがあると感じています。

実際に意識していた対応の流れ

トラブルが起きた際は、
以下の順番を意識して対応していました。

・まず事象を整理する
・影響範囲を切り分ける
・事実と推測を分けて共有する

この段階では、無理に原因を断定しないようにしていました。

日頃から意識していたこと

日頃から、

・自分が変更した設定は必ずログを残す
・GUI操作はスクリーンショットを残す

ことを意識していました。

そのため、トラブル時も
「何を変更したか」「どこを触ったか」を
すぐに振り返ることができました。

ログがあることで、

・上司への状況説明
・原因調査
・お客様への説明

がスムーズになったと感じています。

周囲を巻き込むことも対応の一部

自分だけで抱え込まず、

・分かっている事実
・まだ分からない点
・次に確認したいこと

を整理した上で、早めに上司やメンバーに共有するようにしていました。

結果として、対応の方向性が早く定まり、
復旧までの時間短縮につながったと思います。

トラブル対応で学んだこと

トラブル対応は、
個人の技術力勝負ではなく、

「整理力」と「共有力」
が結果を左右する仕事だと感じました。

現在

現在は、自分で学習を続けることはもちろんですが、
同じ課のメンバーから日々技術を吸収する働き方をしたいと考えています。

また、自分が学んだことをそのまま自分の中で止めるのではなく、

・調べたこと
・試して分かったこと

をチームに共有し、
課全体として知識が増えていく状態を作りたいと考えています。

5年後

5年後には、
20代のうちに経験と学習を積み重ね、

・インフラ
・OS
・ミドルウェア

などを中心に、
一つに偏らない多角的な技術知識を身につけたいと考えています。

特定分野に尖るというよりも、
全体像を理解し技術的な判断ができるエンジニアになることを目標にしています。

10年後

10年後には、
特定の技術領域や業務分野において高い専門性を持ち、お客様からバイネームで信頼されるSEになりたいと考えています。
単に技術に詳しいだけでなく、お客様の課題や背景を正しく理解し、最適なシステム構成や運用まで見据えた提案ができることを強みとしたいです。
そのために、若手のうちから技術力の向上に継続的に取り組むとともに、日々のコミュニケーションを通じて信頼関係を築き、長期的に任せていただけるエンジニアへ成長していきたいと考えています。

周囲からは、

「一人で抱え込まず、周囲を巻き込みながら進める人」
と言われることが多いです。

分からないことや判断に迷うことがあった際に、
自分の中で完結させず、
状況を整理した上で相談する点を評価してもらうことが多いです。

具体的なエピソード

例えば、
作業や調査を進める中で不明点が出た場合、

・分かっていること
・分からないこと
・次に確認したいこと

を整理した上で、上司やメンバーに相談するようにしています。

そのため、

「状況が分かりやすい」
「話が早い」

と言ってもらえることがあります。

自分が意識していること

自分では、

「判断しやすい材料を揃えること」を意識して仕事をしています。

正解を持っていなくても、判断材料を整理して共有することで、
チームとして前に進めると考えています。

入社後の姿

入社後はまず、
担当する業務や環境を理解することを最優先に考えています。

分からないことをそのままにせず、

・自分で調べる
・先輩やメンバーに確認する
・学んだことを整理する

このサイクルを回しながら、
早くチームの一員として動ける状態を目指したいです。

数年後に目指す姿

自分自身での学習を継続することに加え、プロジェクトメンバーから積極的に技術を吸収し、まずは技術力をしっかり身につけたいと考えています。

自分一人で完結する勉強だけでなく、

・周囲の設計や構成を見て学ぶ
・レビューや打ち合わせの中で考え方を盗む
・実際の案件を通して理解を深める

こうした積み重ねで、
現場で通用する技術力を高めていきたいです。

その上で、

「なぜこの構成なのか」
「別の選択肢はなかったのか」

といった点を自分なりに考え、

判断に使える技術知識を増やしていきたいと考えています。

将来的な成長イメージ

将来的には、お客様から「この案件はあなたにお願いしたい」とバイネームで指名いただけるエンジニアになることを目指しています。
そのために、日々の業務を通じて技術力を着実に高めることはもちろん、プロジェクト内で他のメンバーの設計や実装、考え方を積極的に吸収し、自身の引き出しを増やしていきたいと考えています。
また、日常のコミュニケーションを大切にし、お客様の要望や背景を正しく理解したうえで、期待以上の提案ができるエンジニアへ成長していきたいです。