社内エンジニア向け研修|AWSセミナー復習会を開催しました! | Gizumoの研修の秘訣
こんにちは!Gizumoの安藤です。先日、社内エンジニア向け研修「AWSセミナー」の復習会を開催しました!(第1回開催時の様子をご紹介した記事もあるのでぜひご覧ください!)https://www...
https://www.wantedly.com/companies/gizumo-inc/post_articles/482805
Gizumoの小松です!
みなさまにGizumoのことをさらに知っていただきたいと思い、メンバーのインタビューを行っています。
今回は、クラウドエンジニアの『伊藤』にお話をお聞きしました!
伊藤さんは、Webエンジニアからキャリアをスタートし、社内でプログラミングの研修講師を経験した後、現在はクラウドエンジニアとしてAWSを用いたインフラ構築を担当しています。また、社内でAWSセミナーを開催するなど、Gizumo全体の技術力向上に大きく貢献しているメンバーの1人です。
「Webエンジニアからクラウドエンジニアにキャリアチェンジした経緯」や「Gizumoの技術力について感じていること」などをお話してもらいました!
伊藤さんが担当するAWSセミナーの様子はこちら▼
もともと大学在学中に独学でプログラミングを勉強していました。プログラミングの学習を進めるうちにあっという間にのめりこんでしまって、大学で学問を究めるよりも早くITの仕事がしたいと思い、中退してIT業界での仕事探しを始めました。
そこで、未経験でもエンジニアとして受け入れてくれるGizumoを見つけました。創業期のベンチャー企業で一緒に会社を作っていくのが楽しそうだと感じたこと、Gizumoで働いている人の雰囲気が面白そうだったことから入社を決めました。
まずはバックエンド研修にてPHPとフレームワークのLaravelを中心に学び、研修が終わってからはECサイトのリニューアルを行うプロジェクトに参画しました。新しく機能を開発するというよりは、デザインを一新するにあたってそこに紐づいているバックエンドの実装を改修するような内容です。仮想サーバーの構築やセッティング周りを任せてもらっていて、そこからインフラが好きだと思うようになりました。
その後、PHPのバージョンアップのプロジェクトを数件経験し、メンター(※研修講師)になりました。
入社後のプログラミング研修では、同期に教えながら自身の理解を深めるような学習スタイルをとっていました。そのときの教える姿勢を評価していただいて、メンターというポジションにお声がけをいただいたように思います。自分自身も教育への関心が高かったので、快諾してメンターになりました。
メインのメンター業務では、エンジニアを目指す研修生にバックエンドの教育を行っていました。その他、カリキュラムの執筆やバックエンドチームのマネジメントも担当しました。
教育業務と並行して受託開発にも携わりました。受託開発では、AWSインフラ環境の設計、構築、ランニングコストの見積もり、構築にかかるイニシャル工数の算出等々インフラに関連するタスクを任せていただき、とても貴重な経験を積ませていただきました。構築に関してはIaC(※Infrastructure as Codeの略。インフラ構築をコードを用いて管理すること。)を活用して、運用・保守フェーズのことも考慮した設計・構築を心がけていました。当時はAWSを扱えるメンバーが少なかったので、実際に動かしては失敗して…を繰り返していて、空いてる時間はひたすらAWSの公式を見たり書籍を読んだりと、常に勉強して知識をキャッチアップしていました。
いろいろな業務を並行するのは大変でしたが、同じチームのエンジニアからたくさん刺激を受けて楽しく働くことができたと思っています。
メンターを経験する前はプレイヤーとしての意識が強かったので、渡されたタスクをただこなしていくような働き方をしていました。そうするとそのとき自分が触れている技術に目が向きがちだったのですが、メンターを経験してからは、”人材をどう育成していくか”、”組織に対してどう貢献していくか”、”組織をどう活性化していくか”という部分に関わることが楽しいと感じるようになりました。視野も広がりましたし視座も高くなったと思います。
異動した理由は、大きく3つあります。
まず、「メンターをやらないか」とお声掛けいただいたときから、いずれはメンターをする中で得た経験をベースに、また新しい社外プロジェクト先に行きたいと思っていました。エンジニアを育成することももちろん大切ですが、育成したエンジニアが参画できるプロジェクトを確保するのも同じくらい大切です。自分が活躍することで新人エンジニアが参画できるプロジェクトの数を増やせたら良いなと考えました。
2つ目の理由ですが、本社で働いているメンバーとプロジェクト先で働いているメンバーとの間で、会社に対する関わり方や姿勢に差があると感じていました。私が社外のプロジェクトに異動して本社で働いていたとき以上に活躍することで、その課題に一石を投じられるかもしれないと考えました。SES事業を展開する会社にとっては非常に難しい問題ですが、まずは自分から動くことで、そこに続いて会社を盛り上げてくれる人が増えると良いなと思っています。
最後は、やっぱりインフラに関連する業務が楽しいという点に尽きます。もっとインフラの経験を積んでスキルアップし、ゆくゆくは得た知見をGizumoに還元できたらと考えています。
プロジェクト先のシステムの基盤、例えば機器やクラウドのOSや言語のバージョンが古いので、そこを新しい基盤に移行するようなプロジェクトです。ただ移行するだけではなくて、移行するシステムのインフラの要件を定義して整理したり、個別のシステムのインフラを設計・構築・運用しています。インフラの基盤の上にはアプリケーションがあるので、アプリケーション開発側のメンバーとも連携を取りながら、システムが問題なく稼働するように基盤を移行します。インフラチーム単独で黙々と作業するのではなく、マネージャーやアプリケーション開発チームと、日々コミュニケーションを取りながら業務を進めています。
組織やプロジェクトによってインフラエンジニアの定義も異なり、求められる業務内容や役割は変わってきます。そのためあくまで一例になりますが、私の参画しているプロジェクトでは、AWSクラウド上でアプリケーションを動かせるシステム基盤を設計・構築・運用保守していくのが主な業務です。
流れとしては、「こんなシステムを動かしたい」という話をいただいたら、システムに必要なインフラ要件をヒアリングしていきます。その後、ヒアリング内容を元に構成図を書き起こしたり、構成を構築することによって月額で発生する費用や構築に要する工数を算出したり、必要であれば技術調査や検証を行なったりして、マネージャーとご相談します。実際に構築する構成が固まったら、どのように構築するか細部の設計に入ったり、 インフラのコード化を進めます。あとは実際に構成をAWS上に構築して、アプリケーションチームが開発したアプリケーションを載せてリリース。その後は運用保守をしていくといった感じです。
その他、インフラについてのお問い合わせを受けたら調査したり、障害が発生したら復旧にあたるといった突発的な業務も普段から行なっています。
AWS Lambda関数上でPythonを書く程度で、バックエンド・フロントエンドの言語のコードを書くことはほとんどありません。AWS CloudFormation(※インフラをソースコードで管理するサービス)やDockerfile(※Dockerで作成するコンテナイメージを管理するためのファイル)、Webサーバの設定ファイルといったところをよく触ります。
バックエンド・フロントエンドの言語をガッツリと書けなくても良いですが、読めるようにしておく、その言語ごとの特性や実行環境の仕組みを知っておくということは、インフラの構築にも活きてくるので非常に重要だと思います。
オンプレミス(※自社のサーバーやデバイス上で運用するシステムを指す)からクラウドへの移行を検討されるお客様の中にはセキュリティ面を懸念される方も多いのですが、オンプレミスと比較したときにクラウドのセキュリティレベルがどれくらいかを説明するのは難しいです。ここを上手く説明できないと、「クラウドに移行します」という合意は得られないので、もっと提案力を強化しなければと考えております。
また、難しいゆえに面白いところですが、オンプレミスよりもクラウドの方がインフラとアプリケーションの垣根がより無くなります。ローカル開発環境の構築やCI/CD、ミドルウェアやDBやセキュリティといったインフラとアプリケーションの中間領域に対して、どうアプリケーションチームと連携して対応していくかは、ハードスキルはもちろん、ソフトスキルが多分に求められるところだと思います。
非効率な業務に対して効率を改善したいと考えられる人や、自動化や運用の改善が好きな人は向いていると思います。クラウドは直接ユーザーに触ってもらえるわけではないですが、アプリケーションが動く基盤を作る縁の下の力持ちのような役割なので、そこに魅力を感じてくださる人もマッチすると思います。
アプリケーション開発をしていたときよりも上流の工程に携わることが増えた点が良かったです。インフラの設計・構築・運用を担当するエンジニアとして、システムの非機能要件を定義・整理したり、マネージャーの方々とお話をして合意を形成したりと、プレイヤーとしてアプリケーションの機能開発をしていた頃とは動き方が大きく変わりました。
また、どれだけUIがリッチでかっこ良くて、機能が豊富で便利なアプリケーションを作ったとしても、インフラの基盤が脆いと足元から崩れてしまいます。そういった重要な部分に関わることができるのがとても刺激的で、インフラエンジニアに転身して良かったと思います。
Gizumoにはフロントエンド・バックエンドのアプリケーション開発ができるエンジニアは多く在籍していますが、アプリケーションを動かす基盤となるインフラ構築・運用ができる人は少ない状況です。
Gizumoは今、”人を育てる会社” から "人を育てるだけでなく、モノも作れる会社" への転換期を迎えています。そこで作られたモノが安定して動く基盤を構築・運用できるエンジニアも今から育成していきたい、というお話をCOOの安藤さんとしていたところ、AWSの大型セミナーを開催させていただく流れになりました。
全15回で毎回ハンズオンを通して体系的かつ実践的にAWSの学習ができるというのがAWSセミナーのメリットになりますが、メンバーには意欲的に参加していただけているように感じています。セミナーの実施によってどのような成果が得られるかは今後次第かと思います。
現在は第1期を開催中ですが、2期は今よりもっとAWSを体系的かつ実践的に理解できるセミナーとするために、予習復習のコンテンツ含めて今後の拡充を計画しています。
どのようなキャリアにしていくかはまだ明確になっていませんが、プレイヤーやマネージャーどちらを中心にやっていくとしても、インフラが自分のキャリアの主軸にあることは間違いないです。
ゆくゆくはインフラ部隊を作って拡大していくような働きができると面白そうですが、まずは自身が今よりも高いレベルでインフラを扱えるように引き続きスキルアップしていかなければと考えています。
オンプレミスの知識と経験を得たいと思っています。
お客様にオンプレミスとクラウド、それぞれでシステムを構築する場合のメリット・デメリットを説明する機会があるのですが、クラウドに知識が偏っているとどうしてもポジショントークになってしまうところがあるように感じています。オンプレの知識もクラウドと同じくらい身につけた上でお客様に説明し、お客様の希望によってはオンプレでの構築も対応できるようになれば、自身の活躍の幅をもっと広げられると考えています。
そのために、ネットワーク側の勉強をしたり、仮想ネットワークを構築したり、ミニPCを購入して物理的に繋いでみる等々スキルアップに励んでいます。
年々社内の技術レベルは上がっていると感じていますし、ナレッジもどんどん蓄積されています。Gizumoで活躍しているエンジニア1人1人がプロジェクトを通してすごく貴重な経験をしているので、その経験を上手く引き出せる機会や場所がもっとあれば、さらに技術力の高い会社を目指せるんじゃないかなと思います。
やりたいという意思を表明すればやる気次第でどんどんステップアップしていける環境があるので、そこがすごく魅力的です。自分もプロジェクトを経験をしてメンターになってそこからまたプロジェクト先に出たり、AWSセミナーを開催させてもらったりと、やりたいことに挑戦する機会をたくさんいただいています。
プロジェクト先にいるエンジニアと会社間で、より細かく具体的な目標面談があると良いと思っています。
プロジェクト先に居続けて会社との関わりが薄くなると、どうしても個人の目標達成だけに意識が向いてしまいます。「会社として個人にどうしてほしいのか」「個人の目標達成のために会社は何ができるのか」といった話し合いができる機会が増えると、メンバー1人1人がさらに活躍できるように感じます。
「この人はすごいな。この人が抜けたらプロジェクトが回らなくなりそうだな。」と思われるような、チームや組織に良い影響を及ぼせる、技術的にも人物的にも強いエンジニアが”良いエンジニア”だと思います。
私は技術的にも人物的にもまだまだ未熟だと痛感する毎日なので、良いエンジニアに少しでも近づけるようにもっと努力していきます。
自分のスキルを高めるだけでなく、身につけたスキルを会社の技術力向上に還元する姿勢がとても素敵ですね。Gizumoの研修講師やセミナー講師は未経験から研修を受けてエンジニアになったメンバーも多く、プロジェクト先で得たナレッジを後輩に教えて育てていくような、良いサイクルができているように思います。
今後もさらに技術の高い会社に成長していきますので、エンジニアを目指す皆さんもぜひ一緒に会社を盛り上げましょう!