初めまして、今年新卒入社した北井です。 研修が本日で終わりなので振り返っていきたいと思います。
まずは軽く自己紹介させてもらうと、中学卒業後に、高専の情報工学科に入り、C,C++,PHPなどを学んで、卒業研究ではC++を使ったシステムを開発しました。その後、フィンテックの領域を学ぼうと、大学の経済学部経済工学科に編入したんですが、入ってからは学生起業に興味を持ってしまって、講義では経営学とか計量経済学中心に学び、放課後起業していたので、技術的なことをほぼ触らない生活をしてました。弊社には、今まで学んだことを生かせそうな職場で且つ起業や新規事業に前向きな印象から入社しました。
研修の全体的な特徴で言えることは、コロナによってリモート研修だったことですかね。BN含め社員の殆どの人とあったことがない状態での研修は、4月の頭の方は特に違和感がすごかったです。（笑） 個々の研修については他の方も説明してくれていると思うので、以下に自分の印象に残った研修についてのみ書いていきます。
続きを読むこんにちは、入社1年目の山下です。大学では情報工学を専攻していて、AIによるメディア処理の研究をしていました。 そのため、授業や研究室でC言語やJava, Pythonを触る機会はありましたが、研修を受けるまではScalaを触ったことがありませんでした。 Scala以外にも今回の研修で学んだDocker, AWS, embulk等触ったことがなかったため、うまくできるか不安でしたが、手厚いサポートのおかげで無事研修を終えることができました。 セプオリの研修について、簡単にまとめたのでセプオリ入社希望の方に読んで頂ければ幸いです。
セプオリにはチームが8つあり、各チームの事業内容・チームカラーについてプレゼンを聞く機会がありました。 チームカラーが分からないまま配属になると不安に感じてしまうので、予め説明を受けることによって不安が払拭されたと思います。
研修のスタイルは大きく分けて2種類のスタイルで行われていました。 「講義形式」と「自習＋質問形式」です。 研修の内容については以下の記事に詳しく書いているので割愛します。
スライドや研修テキストに沿って進めていく形式の研修です。 今年はリモートだったので、Zoomを使用し講師の方と6人の同期（自分含む）で通話しながら行っていました。 このタイプの研修は、説明→演習→説明→演習という形で進行していきます。 イメージとしては学校の授業を思い浮かべてもらえると良いと思います。 今年の研修では、マインドセット研修やScala研修テキストを用いたプログラミング研修・セキュリティ研修 がこれに当たります。
教材を自分で読み、問題を解き、分からないところを講師の方に質問して進めていく形式の研修です。 ソフトウェアテスト技法研修・Docker研修・オブジェクト指向研修等、ほとんどの研修がこちらの形式でした。 このタイプの研修は、完全に自分（or 自分たち）のペースで進めていく形になります。 詰まったところが出てきたら長時間一人で考えてしまうのではなく、ある程度調べても分からないのであれば講師の方に質問した方が良い シチュエーションに遭遇することが多かったので、良い質問の仕方・時間の使い方を学ぶことができたと思います。
どちらのタイプの研修においても同期同士で助け合う機会があり、お互いに理解を深めることができたので良い研修でした。
2週間に1回、30分間、メンターの先輩社員とMeetで面談がありました。 仕事の悩み・私生活の悩み等を聞いてもらえる機会として利用し、QOLを高めることができたと思います。
毎日、その日一日のよかったこと・悪かったことを振り返るMTGがありました。 このミーティングでは新卒だけでなくメンターや講師の方も参加し、次のような メリットを得る機会になりました。
1 on 1や振り返りの時間によって研修中の心理的安全性が担保されており、セプオリが良いカルチャーを持っている会社であることを実感しました。
3ヶ月の研修のラスト2週間にチーム研修がありました。 今年のチーム研修は3人1組で執り行われ、古着屋のECサイトを作るというテーマでした。 この研修では原田さんにPOの役割を担ってもらい、我々は開発メンバーとして要件定義から行いました。
基本的にはこれまでの研修で学んだ知識を発揮する集大成のような場で、先輩に聞いた話だと、実際のチーム開発にも繋がる部分があるようです。 今まで研究にせよ趣味にせよ個人開発しかほとんどやってこなかったので、チーム開発自体に対しての理解を深める良いきっかけになりました。 要件定義から本格的に開発するのは初めてで試行錯誤の毎日でした。工夫した点としては リモートなのでコミュニケーション機会が少なくMTGの回数を増やすなどの対応をしましたが、他のメンバーに圧をかけないように 何気なく話しかけるコミュニケーションコストは大きいと感じました。他には、我々のチームでは各メンバーが満遍なく技術に触れるようにした方が良いと思い、タスクの割り振りを技術領域ごとではなくユーザ登録機能などの一連の処理ごとにしました。そのため、学んできた技術を一通り復習することができたと思います。
最初は研修内容を問題なく吸収できるか不安でしたが、研修体制を作り上げた講師の方々の努力もさることながら、 講師の方・メンター・新卒によって毎日改善案を出し合っていくことで、研修をよりよいものへ変えていくことができました。 具体的な内容は（再度掲載になりますが）こちらを見ると良いと思います。
リモートワークを3ヶ月に渡って行ってきたことで、リモートの強み・弱みが多少わかりました。
強みとしては
質問内容やその回答をテキストに残せること
自宅から研修を受けられるので通勤時間がかからないこと
オフィスよりも静かな環境で集中できること（個人差あり）
休み時間に近くのスーパーに買い物に行ける
弱みとしては
他の社員との雑談の機会が損なわれること
パフォーマンスが自宅環境に強く依存しやすいこと
機微な言葉や感情を伝えづらいこと
がありました。個人的には差し引きプラスだと思っているので、コロナウイルスの感染が収束した後も リモートワークが働き方のオプションとして選べるような形になって欲しいなと思いました。
業務に繋がるものであれば年間7万円まで資格の受験費用等を会社が負担してくれます。 今自分はこの制度を利用して、月額制のOSS-DB Silverのオンライン問題集を利用しているので助かっています。 問題集で勉強が充分にできたら、同じく受験費用を申請しようと思っています。
業務のために必要な技術書・マウス・キーボードの購入費用を会社が負担してくれます。
技術書は単価が高いので、コップ本が読みたいときに利用させていただきました。
こちらの制度で購入したものは会社の所有になるので、不要になったら会社に返さなければなりません。
社用PCとしてMacBookが支給されます。新しいモデルのMacBookProなので性能が良く快適にコーディングすることができます。
研修について自分なりにまとめました。過ぎればあっという間でしたが、充実した研修を受けることができました。 自分はメンタルが弱い方なので、心理的安全性を重視したセプオリのカルチャーには本当に助けられました。 配属先でもセプオリのカルチャーに敬意を払いながら自分らしくパフォーマンスを残していきたいと思います。
こんにちは、2020年4月に新卒で入社した金渕です。7月1日付でチームにジョインとなり、4月から行ってきたBN研修も終わりを迎えるということで、研修全体で得られたこと、感じたこと、困ったこと、不安だったことを率直に記したいと思います。
こんにちは。新卒2年目の原田です。
以前は開発チームに所属していましたが、現在は教育チームに所属しています。
その背景として、私は昨年から個人的な目線ですが社内に教育に対して興味ある方や協力的な方が多くないように感じており、何か自分にできることはないだろうかと考えることがありました。先輩方にも何度かお話をさせていただき、当時自分がやるべきことやアクションにアドバイスしてもらいました。
また、過去にプログラミングではなくスポーツですが、人に教えて、その人が活躍した時にとてもやりがいを感じたことがあり、教育自体にも興味を持っていました。
以上から、会社に要望を出して今年の3月から教育チームに所属することになりました。
2020年度新人研修の教育カリキュラムを、前年度と比較して大幅にアップデートしたので紹介します。
ちなみに今年度は6名の方が入社してくれました！👏
続きを読むこんにちは。CTOの河内です。
多くのプロジェクトがスタート時はそうである通り、我々のプロジェクトもAPI仕様がありませんでした。 最初は規模が小さく問題として認識されていなかったのですが、規模が大きくなり、また開発者の入れ替わりを経験するごとに、「この API って何返してくるの？」という問いに答えられる人が段々といなくなってきました。 「ソースが仕様だ」とサーバの実装を読めばもちろん答えられるのですが、ソースコードを読み解く時間がかかるため効率的ではありません。 また、サーバ実装が唯一の情報源となるため、ロジックが何かおかしいと感じても、それが仕様なのかバグなのか判断できない状態でした。
API仕様を先に定義し、通信上の疑問にはAPI仕様で答えられるようにしたかったのです。 これは一般的な課題で、日本CTO協会が2019年12月に公開した DX Criteria DX Criteria では API 駆動開発として触れられています。 「なぜ、重要か。」に書かれている以下の文章は、我々が実現したかったことを言い表しています。
ネットワーク経由のAPIを基準にシステムを開発することで、他のシステムと連携しやすくなります。 またシステムがレガシー化した際に交換したり、改善したりといった手が打ちやすいものになります。 人が使う見た目の作りだけでなく、エンジニアにとっての作りが質を生み出します。
我々のシステムで対象となる API は REST ベースです。 REST ベースの API を記述する仕様記述フォーマットは OpenAPI*1、API Blueprint、RAMLなどいくつかあります *2。 この中では対応しているツールが多く、インターネット上の情報が豊富な OpenAPI を試すことにしました。
*1:以前は Swagger と呼ばれていた。
*2:ゼロからシステムを構築する場合は grpc-web も有力な選択肢になりそうですが、既存システムの仕様を記述するには向かないため選択肢から外しました。