こんにちは。

オータムGMの長田です。

会社名にちなんだの季節にはなりましたが、まだまだ気温は高いですね。

それは我々社員も同じく、モチベーションの高い社員が中心となった勉強会を開催しました。

今回はそんなバックエンド領域を主戦場とするオータムのエンジニアトレーナーがどのようなコンテンツをしていたのかをハイライト形式でお伝えします。

非常に有意義かつ建設的な時間となりましたので、社内風景の一環としてご覧ください。

各トレーナーの講義内容はバラエティ豊か！

先鋒はサーバー知識から！

今回、長田も同席しながら講義を傍聴してました。

まずは今月から新しくトレーナーとなったKさん。

経験こそビギナーではあるものの、アサイン先ではインフラまわりの知識は日常茶飯事というほど活用しているとのことです。

そんなトレーナーKさんの展開する講義は「Linuxコマンドの概念とサーバー知識」です。

私もインフラエンジニアの経験をしたことが過去にあったので思い出に浸るように傍聴していましたが、参加されたエンジニアの方々は普段触れない部分でもあり、基本コマンドについてここにきて改めて学び直していました。

まずはコマンド名を受講者から挙げてもらい、それらがどんなことができるかを説明してもらいました。

例えば、ディレクトリを作成する「mkdir」やフォルダ間や階層を移動する「cd」など基本的なコマンドから、ファイル結合して出力する「cat」、コマンド履歴を参照する「history」など応用的なコマンドなどが列挙されて、みなさんそれなりの知識をトレーナーKさんにぶつけていましたが、それでも現場経験者の意地なのかそれらのコマンドが実際どういう場面で使われるのかを経験ベースでお話されていました。

トレーナーKさんはいい意味で受講者との距離感も近く、時間も目一杯使って各自質疑応答に答えていました。

聞くはいっときの恥聞かぬは一生の恥の如く、わからない人は積極的に疑問点とその理由を示しており、聞き専の人は1名もいませんでした。みなさんとても熱心に取り組まれてました。

次鋒はER図の書き方について！

続いて、普段から積極的にリーダーシップを発揮してくれているトレーナーDさんの講義。

こちらの講義内容は「ER図の正しい作り方」です。

バックエンドエンジニアともなれば、ER図を書くことはWEB開発する際のデータベース設計においては避けることのできない項目でもあります。

ER図の基本構成は下記4つから構成されています。

• エンティティ

→構築したいシステムが処理する「モノ」に名前を付けて定義したもの

• アトリビュート

→エンティティが持つ情報を細分化したもの

• リレーション

→エンティティ同士の関係性

• カーディナリティ

→1つのエンティティに対して、リレーションを有する他のエンティティがどのくらいあるか

今回はそのER図を作る上での考え方や必須要件などを共通のテーマから二人一組となって取り組まれていました。

まず、共通テーマとして「自動販売機アプリ」をもとにした各チーム固有の仕組みや要件をまとめる実践形式のお題でした。

参加された方々は普段は別々の現場や所属が異なる人など、連携面も側から見ていて懸念していましたがその懸念とは裏腹にとても活気付いてテーマに沿った要件をまとめていました。

それぞれ個性的な機能要件がありながらも、リレーションベースでER図は丁寧に書かれていたり、大胆な書き方だったり、健闘しつつも整合性が追いついていなかったりと、不慣れなりに和気藹々と作成されていました。

中でも、「あったら面白そうな機能」は各チーム個性的で、バラエティに富んだ解答もあれば、本当にあったら便利そう、面白そう！と思える機能など満載でした。

真打はリファクタリングのやり方！

勉強会も折り返し時間を経て佳境となり、大トリのパートになりました。

このトリを担当するのは、他トレーナーも羨望するほどの経験者トレーナーFさんです。

Fさんはパートナーとしてジョインしてくださっており、実務経験4年で得意言語はWEB案件ではマストでもあるJavaScriptやPHP、マークアップ言語です。FWもReactやLaravelなどまさにオータムの領域にはうってつけの経験エンジニアなため、質や経験の面で普段から他を圧倒するレビューをしてくださっています。

そんなFさんが実施したテーマは「リファクタリングをしてみよう！」です。

リファクタリングとは、簡潔に説明するとソフトウェアの動きや見た目を変えることなく、中身のプログラムやソースコードを整理することです。

リファクタリングをするメリットとしては

• 可読性

→引継ぎ時などコードを理解しやすくする

• 保守性

→ソフトウェアの劣化を防ぐ

• 開発速度の向上

→修正や機能追加が円滑化

主に上記３項目が目的でもあります。

優秀なエンジニアの一つの定義として、コストが安くて対応が早く、わかりやすいコードを記述することができることです。

これらを身につけるには正しいリファクタリングを実施していくことで、着実にスキルとして実践できます。

Fさんはこれだけに止まらず、さらに下記3点についても解説していました。

• DRYの原則

Don't repeat yourself ＝ 繰り返しを避けろ

• KISSの原則

Keep it simple stupid ＝ できるだけシンプルにしろ

• YAGNIの法則

You ain't gonna need it ＝ それはきっと必要にならない

見覚えや聞き覚えのあるエンジニアさんもいれば、「はて？」となるエンジニアさんもいるでしょう。

前述にもある通り、わかりやすいコードを記述していく上で重要な観点であり、これらが完璧にできているソースコードはもはや仕様書は不要になります。

この考え方も実にシンプルで効率と効果を重視していますね。

時間こそ他2名のトレーナーより少なかったですが、Fさんは真打なだけあって内容は非常に濃く、その場にいた誰しもが首を縦にうなづく光景に主宰の長田も感銘を受けていました。（笑）

好きこそ物の上手なれ

勉強会は楽しんだもの勝ち！

今回の勉強会は実は今年に入って2回目ではありますが、初回開催に比べても非常に有意義な時間となりました。

初回開催時にはテスト形式や実践形式のコンテンツを盛り込んだものの、いまいちそれが実用性があるものなのか、その場限りの座学なのかで留まっていました。

しかし、今回の勉強会では実際の現場での実務や自己学習時、エンジニアのキャリア形成において市場価値を高める上で必要な素養をただ座学として学ぶだけではなく、主体的にかつ他者との連携を要して、何よりもそれぞれが楽しみながら学んでいたのはこれからのスキルアップに向けた貴重な糧となったと思います。

毎回、トレーナー側も開催成功のイメージを持ちながらハードルを上げるよう教育統括の長田が捲し立ててますが今回はその効果が大いに発揮されたことでしょう。

オータムではこのような勉強会を隔月で開催しており、参加者数も軒並み増加しています。満足度も高い評価を頂けていますので、今後もさらに楽しく有意義な勉強会を開催していきます。本記事を読まれてご興味を持たれたり、勉強会に参加してみたい！と思われた方はぜひ一度お話しましょう。