PCの電源を入れたら何が起こるのか
- PCの電源スイッチを入れる
- マザーボード上のCPUが動き、ROMの中にあるBIOSというプログラムが動く
- BIOSがキーボード・HDD・グラフィックボードなどを初期化する(POST(Power-On Self-Test))
- ハードディスクからOSを起動するプログラムを取り出してRAM(メインメモリ(主記憶装置(作業用の領域)))にロードする(ブート・ストラップ)
- CPUが「メイン・メモリ」からWindowsのプログラム・データの処理命令を＜フェッチ＞して（＝取り出して）、その命令内容をデコードする(解釈する(CPUが理解できる機械語))
- CPUがデコードした命令内容を実行していくことで、プログラム（Windows OS）が開始される
OSが立ち上がるまでの処理の流れ
- 演算・制御装置である「CPU」が、Windows OSのプログラム・データ（＝ソフトウェア）を、「ハード・ディスク」から取得して、作業用の「メイン・メモリ」の上にロード（＝展開）する
- CPUが「メイン・メモリ」からWindowsのプログラム・データの処理命令をフェッチして（取り出して）、その命令内容をデコードする(解釈する(CPUが理解できる機械語))
- CPUがデコードした命令内容を＜実行＞していくことで、プログラム（＝Windows OS）が開始される
https://atmarkit.itmedia.co.jp/fdotnet/dotnetwork/dotnetwork01/dotnetwork01_02.html#runprogram
CPUの基本動作
- フェッチ
- メモリから命令を読み込む
- デコード
- 読み込んだ内容を解釈する
- 実行
- 命令に従って演算を行う
http://www2.kobe-u.ac.jp/~tnishida/course/2012/IS/3.CPU.pdf
メモ
BIOS（バイオス）：「Basic Input Output System」の略。パソコンのマザーボードに搭載されており、電源を入れて最初に起動するプログラムです。コンピューター内を初期化し、接続されているディスプレイやキーボードなどの周辺機器を読み込んで利用できる状態に整え、それから外部記憶装置（ストレージ）からOSを実行します。
ブートまたは ブートストラップ：コンピュータの電源を入れてからOSが起動するまでの処理の流れ
ブートローダ：このブート処理を行うソフトウェアのことである。
ROMは「ブート・プログラム」と「ROMローダ・ルーチン」というプログラムが記憶されている。
ブート・プログラム：マザーボード上のチップやメモリ、接続されている周辺装置などを初期化する。
ROMローダ・ルーチン：ディスク装置の先頭セクタを読み込む処理をする。
参考
http://www.cs.reitaku-u.ac.jp/infosci/os-kiso/os2003/text02-1.pdf
プロキシとは何か説明する
プロキシとは何か
インターネットを接続する際にネットワークの内部と外部をつなぐ代理をする。
フォワードプロキシ
クライアントとWebサーバの間に位置し、伝言する役割。(クライアント側に位置する)
クライアントはフォワードプロキシに要求し、フォワードプロキシがWebサーバに要求する。
フォワードプロキシはWebページからページを受け取りクライアントへ返す。
メリット1：Webサーバにアクセスしたのが誰かが分からない
フォワードプロキシありとなしを比較する。
フォワードプロキシなしの場合、WebサーバはクライアントPCの情報が分かる。
フォワードプロキシありの場合、Webサーバはプロキシサーバの情報が分かる。
-----
フォワードプロキシなし
クライアント → Webサーバ
クライアント ← Webサーバ
フォワードプロキシあり
クライアント → プロキシサーバ →→→ Webサーバ
クライアント ← プロキシサーバ ←←← Webサーバ
-----
例えば、悪意のあるWebサイトがアクセス元である私たちの情報がばれてしまうのを防ぐことができます。
メリット2：接続先の制限
フォワードプロキシありとなしを比較する。
フォワードプロキシなしの場合、悪意のあるサイトへアクセスできる
フォワードプロキシありの場合、悪意のあるサイトへアクセスを防止する
フォワードプロキシなし
クライアント → 悪意のあるサイト
フォワードプロキシあり
クライアント → プロキシサーバ ✖→→→ 悪意のあるサイト
-----
リバースプロキシ
クライアントとWebサーバの間に位置する。(Webサーバ側に位置する)
Webサーバの負荷分散が役割。
-----
クライアント →→→ リバースプロキシサーバ → WebサーバA
→ WebサーバA(複製)
-----
キャッシュサーバ
訪問したWebページを一時的に保持することで、応答時間が速くなる。
ログを残すことができる。
Webサーバへの負荷を減らせる。
再度読んで理解したい↓。
ログを取得できる
プロキシの設定
PCが使用するプロキシサーバを設定することができる。
目的
社内のTeamsでSharePointが見れない方がいた。
wifiやVPNで社内のネットワークにつなぐと見れるが社内のランケーブルでつなぐと見れなかった。
調査したところプロキシの設定がダメだったらしい。
参考文献
Webブラウザでwww.example.comを入力しWebサイトが表示されるまでの流れを説明する
ブラウザにwww.example.comを打ち込んだとき、裏側では何が行われているか
- クライアントがクライアントPCのWebブラウザにURLを入力する
- URLに含まれるドメインをDNSサーバに問い合わせる
- DNSサーバでドメインからIPアドレスを特定する
- DNSサーバからIPアドレスが送信される
- 取得したIPアドレスのWebサーバにデータを要求
- Webサーバは要求した内容に応じて、保存しているコンテンツ(HTML,CSS,画像など)を返す
- Webサーバから返されたデータをWebブラウザで表示する
ブラウザからDNSサーバに問い合わせる前にやっていること
- クライアントPCがブラウザのキャッシュに「www.example.com」のIPアドレスが残っているか調べに行く
- ブラウザにキャッシュが残っていない場合はhostsファイルを調べにいく
Windows:C:\Windows\System32\drivers\etc\hosts
CentOS:/etc/hosts
DNSサーバに問い合わせてIPアドレスを受け取るまでを深堀する
DNSサーバに問い合わせてwww.example.comのIPアドレスを取得する順番
- クライアントPCがDNSキャッシュサーバに「www.example.com」のIPアドレスは何か問い合わせをする
- ブラウザがクライアントPCのOSとして備わっている機能のスタブリゾルバを呼び出す
- スタブリゾルバがDNSのキャッシュサーバに「www.example.com」のIPアドレスは何か問い合わせをする
- キャッシュサーバがルートサーバへ「www.example.com」のIPアドレスは何か問い合わせをする
- ルートサーバがキャッシュサーバへ「com」の情報を管理するDNSサーバのいずれか(a.dns.com, b.dns.com, ...)に問い合わせるよう回答する
- キャッシュサーバが回答の中から1つ選んだ「com」のDNSサーバに「www.example.com」のIPアドレスは何か問い合わせをする
- 「com」のDNSサーバはキャッシュサーバに「example.com」のDNSサーバの情報を回答する
- キャッシュサーバが回答の中から1つ選んだ「example.com」のDNSサーバに「www.example.com」のIPアドレスは何か問い合わせをする
- 「example.com」のDNSサーバはキャッシュサーバに「www.example.com」のIPアドレスを回答する
- キャッシュサーバはクライアントPCにIPアドレスの情報を回答する
JPNICの記事で紹介している「名前解決の仕組み」が分かりやすい
キャッシュサーバがすでに「www.example.com」のIPアドレスを得ている場合(DNSサーバからIPアドレスを得た場合)
【図解】ドメインとは？をわかりやすく解説します - カゴヤのサーバー研究室
キャッシュを使う
クライアントPCがすでにwww.example.jpのIPアドレス情報を取得している場合、そのIPアドレスを用いてWebサーバにデータを要求する
キャッシュサーバがwww.example.jpのIPアドレス情報を取得している場合、クライアントPCはキャッシュサーバに対して問合せし、IPアドレスを取得する
WebブラウザとWebサーバとのやり取りを深堀する
- WebブラウザがWebサーバに対してTCPのコネクションを確立する
- Webブラウザが該当するIPアドレスのWebサーバにHTTPリクエストを送信してWebページのデータを要求
- Webサーバが受信したHTTPリクエストを解析
- WebサーバがWebブラウザに要求されたデータをHTTPレスポンスとして送信
- Webブラウザが受信したデータを解析してWebページとして表示
TCPのコネクション(3 way handshake)
コネクションを確立する。
- 接続元が接続先へ通信路を確保するために、データ転送の許可要求を出す「SYN(シン)：1, ACK(アック)：0」のパケット
- 接続先が接続元に許可と許可要求を出す「SYN：1, ACK：1」のパケット
- 接続元が接続先に許可を出す「SYN：0, ACK：1」のパケット
図にすると以下のようになる。
-----
ノード1 ノード2
CLOSED LISTEN
－－－SYN－－＞
SYN_SENT
ESTABLISHED ＜－ACK+SYN－－
SYN_RCV
－－－ACK－－＞ ESTABLISHED
-----
コマンドでTCPコネクションを確立すると以下のようになる。
sudo tcpdump host www.example.com and port 80
このやり取りをすますと、PC上でESTABLISHEDという状態になる。
ネットワークの接続一覧は「netstat」コマンドで表示できる。
https://wa3.i-3-i.info/word15428.html
※終了するときはコネクションを切断する
TCPのフラグ(コントロールフラグ)
URG(Urgent)：緊急に処理すべきデータが含まれている
ACK(Acknowledgement)：確認応答番号のフィールドが有効であること
PSH(Push)：受信したデータをバッファリングせず、アプリケーションに渡す
RST(Reset)：コネクションが強制的に切断されること
SYN(Synchronize)：コネクションの確立を要求する
FIN(Fin)：コネクションの正常終了を要求する
Webサーバとのやりとりを深堀する
TCPコネクションを確立する
通常はHTTPのウェルノウンポートの80番(HTTPSであれば443番)を指定し接続を要求する
HTTP接続が可能になったら、WebサーバはURLで指定されたファイルなどのリソースを取得しクライアントに返信する
メモ
URLとドメイン
ホスト名：www
ドメイン名：example.co.jp
FQDN：www.example.co.jp
jp：トップレベルドメイン
co：セカンドレベルドメイン
example：サードレベルドメイン
ドメイン名はどの部分？｜ドメイン基礎知識｜Zenlogic - 株式会社IDCフロンティアのレンタルサーバー
ホスト名とIPアドレスの例
ホスト名：www.google.co.jp
IPアドレス：172.217.161.67
SSL/TLSとは何か
- インターネット上でのやりとりを暗号化するプロトコル
- OSI参照モデルのセッション層に位置し、それより以下の層は保護しない
- SSLは他のプロトコルと組み合わせて使用する
- SSLの脆弱性が修正された新しいものがTLS
SSLで使用する技術
ハイブリッド暗号方式
盗聴対策。
共通鍵のデメリットである鍵の配布を公開鍵暗号化方式で実施。
- Webサーバは公開鍵と秘密鍵を作成
- Webサーバは公開鍵を公開し、秘密鍵を保管
- Webブラウザは共通鍵のもとを公開鍵で暗号化して送る
- Webサーバは共通鍵のもとを秘密鍵で復号
- WebサーバとWebブラウザは共通鍵のもとから共通鍵を生成
- Webブラウザはアプリケーションデータを共通鍵で暗号化
- Webサーバはアプリケーションデータを共通鍵で復号
メッセージ認証コード(MAC)
改ざん対策。
データとMAC鍵(共通鍵)を比較する。
ハッシュ関数に共通鍵の要素が加わるため、改ざんの検知と相手の認証をする。
ディジタル証明書
なりすましや否認対策。
相手が通信したい相手であることを保証する。
SSL通信の種類
他のプロトコルと組み合わせて使用することでプロトコルでの通信を保護する。
TLSハンドシェイク
・・・後日、またまとめたいと思います。
2021年度に取り組んだことを振り返る
この1年で何ができるようになったか振り返る回
1年前の自分と比べて、私はできることが明らかに増えていた！
技術
- Pyhtonを使ったWebアプリケーションの開発
- C#を使ったデスクトップアプリケーションの開発
- Microsoft SQL ServerとVB.NETを用いた生産管理システムの改修
- 納品した実行ファイルと同じソースコードが存在しない中、不具合改修と機能追加を実施
- ソースコードから稼働中のシステムのボトルネックを特定し、次期改修案件として仕事を受注
- 改修したコードを本番環境にデプロイ
- チームで本番環境のトラブルシューティング
- ユーザーから不具合をヒアリング・原因調査と対応
などなど。
この1年は、今までやったことのない技術にふれる機会が多かった。
「自分、それについてはよく知らないですけど、やってみます！」
— 特攻🔥つよつよエンジニアになった (@SOS26689573) 2022年1月31日
と言えたのは成長してる証だと思う
いい意味で自分の殻をやぶることができた気がします。
初めて扱うプログラミング言語や技術に対して戸惑いながらも調べたり質問したりすることで何とか乗り切ることができる！(というより、何事も挑戦しないと自分が成長できない)
今もガントチャートとにらめっこしながらプロジェクトを遂行して開発職を楽しんでいます。
ユーザーの声を聞いて、不具合の現象を確認しトラブルシューティングする。これはこれで楽しい。仮説があたったときはうれしいですし、仮説がことごとくはずれたときに先輩エンジニアさんに相談すると、先輩流のトラブルシューティング(秘伝のたれ)が垣間見れて非常に勉強になる。
「ユーザーがシステムを操作するうえでは問題はないと判明したから調査は終了するけど、なんでこの現象起きたの？」というものに出会うと、ちょっと悔しい。
こんな感じで、トラブルシューティングは私の感情をゆさぶってきます！
資格
4月の応用情報技術者試験が終了次第、資格の勉強はストップします。
というのも、時間は有限だからです。
限られた時間で何を学ぶかを意識しなくちゃ
— 特攻🔥つよつよエンジニアになった (@SOS26689573) 2022年3月24日
1つのことに時間をかけすぎて、他の勉強すべきことに時間をかけれない状態にはしたくない https://t.co/5uCxaQgwTH
忘れないための勉強と傾向を把握するための勉強にかける時間が惜しい。それよりももっと学ぶべきことがあるのでは？と思ったのです。
たとえば、(私とお話しした)サポートエンジニアの方が重視していたTCP/IP・OS・Webの仕組みあたりは理解して説明できるようになっておきたい。
ITというものは範囲がとても広い。だから同じことを何度も繰り返すことよりも知らないジャンルの知識をつけたり学んだことを深めることが市場価値を上げるうえで大事なのでは。
その他
- Linkedinに職務経歴をまとめる
- サポートエンジニアに興味を持つ
- サポートエンジニアのカジュアル面談をする
- 本選考に進めず
- 学習欲に火が付く
- このブログをはじめる
- ツイッターに1週間を振り返るようになる
チャンスに気づいたら、いつでもチャンスをつかめるように。そしてチャンスをつかみそこなうことがないように。
そのためにも常にアンテナを張り準備をし続けたい。
来年度の目標
健康で文化的な生活を送るエンジニアであり続けたい！
【2022年目標】
— 特攻🔥つよつよエンジニアになった (@SOS26689573) 2022年1月3日
全力×0.7で仕事する
得意領域を見つける
アウトプット増やす
メンターを見つける(社内外)
よく寝る・食べる・運動する
チャンスを見つけて転職する
漠然と抱えている不安を取り除く
恋人つくる
恋人つくる
恋人つくる
燃え尽きない程度に業務で力と成果を出し、社内・社外で活躍できるように今日も明日もちょっとずつ前進していくぞ！
そして、サポートエンジニアを目指す。今度こそ
私だって偶然をキャリアに活かしたい！では、そのために何をする？
「読み物として、面白かった!」で終わらすのはモッタイナイと思った
— 特攻🔥つよつよエンジニアになった (@SOS26689573) 2022年3月20日
本書記載の5つの行動特性に沿って実践して、「開発エンジニア→サポートエンジニアになれました💪」と言えるようになりたい！
そのためにも、どんな行動を社内社外でしていくべきかまとめなきゃ#偶キャリ本 pic.twitter.com/fBmwCRz7o5
そう、読んだだけで終わりにするのはモッタイナイと思ったのです。
アマゾンのリンク：https://www.amazon.co.jp/dp/B09VLHHVQD
5つの行動特性とは
好奇心：興味を持ったことには取り組んでみる
持続性：仮に失敗してもすぐにやめない
楽観性：生きているのでOKくらいの、失敗や不安ごとを重く捉えすぎない
冒険心：失敗を恐れずに始める
柔軟性：新しいものを受け入れ続ける。変化を歓迎する
このような行動特性を持った人が偶然を呼び込みやすいとされている。
この本には、偶然を受け入れて自身のキャリアにつなげた方の事例が多数紹介されている。本を読んだ限り、この5つの行動特性がそろってなくても偶然は引き起こせるようでした。
私の日々の活動と行動特性
サポートエンジニアに興味を持ちカジュアル面談をするも、選考に進めなかった。
選考に進めなかった原因は、求めるレベルに届いていなかったことと考えた。
幅広い知識を身に着けるため、基本情報技術者試験の勉強を合格した。
社内で技術的な話をすると「えっ、そんなことも知らないの？」と言われることがあり、試験に合格しただけでは、十分な知識が身についていないことを実感した。
また「サポートエンジニアに転職した方」のブログに「自分から情報発信できることを重視されているように感じた」と書かれていたのでさっそくブログを作成する。
beasupportengineer.hatenablog.com
サポートエンジニアに関して考えたことをまとめたり学んだ技術を説明する練習の場としてブログを活用できれば満足。もしかしたら採用担当の目に届くかもしれないと思い、1日のアクセス数が0でもかまわずブログを継続する。
4月半ばまでは応用情報技術者試験の勉強をし、その後はカジュアル面談で聞かれた技術について説明できるようにブログにまとめていきたい。
具体的には以下の4つをやる。
- TCP/IP：Linuxで動かしながら学ぶTCP/IPネットワーク入門(やる)
- Web：何をやろう？
- OS：ゼロからのOS自作入門(時間があればやる)
- 英語：自己紹介や経歴を話せるくらいのレベルになりたい。
行動特性に当てはめる
好奇心：業務で触れる機会がない技術に対しても学習する
持続性：サポートエンジニアの選考に進めなくても学習を継続した
楽観性：ブログやTwitterで発信し続けていれば採用担当の目にとまるかも！と考える
冒険心：1日のアクセス数が0の日があっても淡々とこのブログを更新する
柔軟性：やり方がよくないと思えば、やり方を変える
偶然の発生しやすさを計画的に高める
これまでの私の活動を振り返り、5つの行動特性に当てはめることができた。
私の存在を見つけてもらえるように発信する
この本を読んだとき、自分の存在を知っている人がそばにいて＆声をかけてもらって偶然をキャリアに活かしている人が多いような印象をうけました。
「私が転職したときはこんなスキルが評価されましたよ！」や「うちでは今こんな人材を探してまして…」といった情報を手に入れるためにも私の存在をアピールしつつ話しかけやすいオーラをまとわないとな・・・。
私はサポートエンジニアに興味を持っています！
サポートエンジニアを目指している人はここにいますよ！
お気軽に声をかけていいですよ。
私がどんな人物であるかイメージできるような内容を発信する
サポートエンジニアとして活躍している姿がイメージできなければ、たとえ自分の存在が知られていても声をかけてもらえない可能性があると思っています。
なので、読み手がイメージできるレベルで以下のことを説明できる状態にすることが有効ではないでしょうか。
- 現職での私の強みと強みが活きたエピソード
- サポートエンジニアに求める技術への理解度
- サポートエンジニアに興味を持ったエピソード
この辺りをまとめて、私がイメージするサポートエンジニア像と御社で活躍中のサポートエンジニアとの差が把握できたらいいなぁ。
他に考えていること
「王道の正面突破が難しいので、他の人と違う方法をとったらうまくいった」みたいな話がありまして、偶然から始めるキャリアプランと似てるな(もしかして一緒？)と思いました。
このnoteを併せて読むと、さらにアイディアが浮かんできそう。
おわりに
こんな感じで私は現在進行形で偶然を引き寄せようと楽しくジタバタしています。
正解がわかっていない問題に取り組むときほど頭をフル回転して何とかしようとする。
その過程が人間らしくて好きだし、サポートエンジニアのお仕事もこの状態に近い気がする。
ここまで、読んでいただきありがとうございます。
今後も私の行動や発信に注目してください！
お気軽に声をかけていいですからね。
開発エンジニアからテクニカルサポートエンジニアになった方のブログに共感したのです！
開発エンジニアからテクニカルサポートエンジニアになった方の話を見つけました。
現在、私は開発エンジニアであり、次のキャリアとしてサポートエンジニアを目指しています。私とこの方との間に共通する考え方があるか気になったのでまとめます。
私は「ここ」に共感した！
念願かなって Software Engineer として働いてみましたが、先日人に言われて改めて気づいたのが、僕は Software Engineer になりたかった訳ではなくて、Software Engineer をしてみたかっただけなんですね。
はじめてこの記事を読んだとき、1番ここが刺さりました。まるで自分事のように。
知識豊富のSoftware Engineerからの質問が刺さったことを思い出す。
「自宅ではプログラミングで何か作ったりしないんですか？」という質問にハッとさせられた記憶があります。『私は、本当に開発したいのか？』と。
私に質問した方は「これを自分の手で作りたいんだ！」といったものがあり、帰宅後も開発をされているようなThe開発エンジニアです。どうしても開発がしたくて仕方がないような感じ。
一方、私は帰宅してからプログラミングすることはありませんし、そもそも作りたいものがない(イメージできない)。
私は「Software Engineer になりたかったわけではなくて、Software Engineer する能力を身につけたかった」んだろうなと思いました。
Software Engineer は自分が担当する system については文字通り上から下まで責任持って自由にやれます("You build it, you run it" でした)が、担当外のものについては結局手が出せないことが多いなと感じました。言い換えると、自分が手を出せる範囲が非常に狭く深いです。
良くも悪くもこれなんですよね。自分が担当したsystemに対して色々できるのですが、担当したものしか手を出せない(ことが多い)。これはこれで楽しいのですが、systemが完成するまで短くて数カ月、巨大なsystemになると数年かかったりします。また自分が触れる技術は、参加したプロジェクトの担当箇所でほぼ決まるため、数年間で振り返ると、私がやってきたことは偏ってて意外と少ないのでは？と思ったりします。
IT業界に入って基本情報の勉強したときに「ITって、こんなに範囲広いのかよ！」と驚いていたわりには身に着いた技術の範囲は狭いかも。と感じています。
色んな技術に触れてみたい思いはあるため、今はSoftware Engineerとしてやっていけても、いずれは熱が冷めて飽きてしまいそうです。
Software Engineer以外の道としてSupport Engineerを目指している
プログラミングを触ったときに、「これさえあれば、何でも作れるのか！すごい世界だ！！」と思ったから私はSoftware Engineerになったわけですが、エンジニアの仕事は多岐にわたることエンジニアになって知りました。
現在は、Software Engineer以外の道としてSupport Engineerを考えています。(このブログのタイトルでもありますし。)
理由は4点
- 困っている方の力になるのがすき
- バグの原因を特定、解消できたらうれしい
- 困っている方の課題が解決できたら私もうれしい
- ユーザーの課題に対してブレずに応えたい
Technical Support Engineer がいいなと思った理由は、お客さんの課題を直接的に知ることができて、それを service 改善に自分でつなげやすいと思ったからです。Software Engineer だと、どうしてもそうした今起こっている課題を間近で見る機会というのは減ってしまって、ともすれば今開発しているものが一体何のためのものだったのかブレてしまうこともありがちです。
この辺は、まったく同じことを思いました。(ユーザーとの距離と開発にかかる期間がそうさせるのでしょうか。)
ユーザーのぼんやりした課題をうまく言語化してプロジェクトを開始するも、走り出している間に作りたいものがブレていき、最終的には「思っていたのと何か違うもの」が完成する。Software Engineerをやっていてもどかしい瞬間です。
Support Engineerはユーザーとの距離が近く、プロジェクト1つのサイクルが(Software Engineerと比べて)短く、課題とあるべき姿が明確なため、ユーザーの課題解決に特化できる点がいいなと思ったのです。
これからの私
業務で扱う技術・自分が興味を持った技術に関して今もこれからも貪欲に学んでいきます！(明日、面接しませんか？と言われるかもしれないですし。)
最近は、業務外に学んだこと(やったこと)を記録するようにしています。
※もちろん日々の業務も全力で取り組んでいます。
【今週の特攻🔥】
— 特攻🔥つよつよエンジニアになった (@SOS26689573) 2022年3月13日
応用情報午前(H30/H30)6割6割
午後DB,システム監査の内容まとめる
情シスSlack参加
情報セキュリティ10大脅威組織編見てる
Software Engineer → Technical Support Engineerになった方の記事読んで共感した部分をまとめている最中
90%くらいで働いた
チャンスをみすみす見逃さないように、今できることを積み重ねていきたい。
私はサポートエンジニアに興味を持っています。採用担当の方や現役エンジニアの皆さんからのお声がけ、いつでもお待ちしております！
