こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「コーディングがくそ過ぎて人格否定された」という話をしたいと思います。 コーディングとは、プログラムを書くことでありますが、このコーディングにもいろいろな作法的なものがあります。今回はそんな作法やコードの見易さを深く考えずに開発していたら痛い目を見た経験をお話させていただきます。 駆け出しエンジニアの方はもちろん、エンジニアを目指している方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです！ 【心躍】初めての開発経験 入社後の開発研修を終え、いよいよ配属されることになりました。こちらの開発研修の内容について、 こちらの記事 が公開されているので気になる方がいらっしゃいましたら是非そちらも読んでいただければと思います。 さて、僕の配属先は、バックエンドと呼ばれる社内の管理画面や対ブランド向けの管理画面を開発する部署でした。この時期にちょうど、対ブランド向けの管理画面のリプレイスするというプロジェクトが進行しておりました。そのためこのプロジェクトに アサイ ンすることとなりました。 僕が担当することとなったタスクは、新規で開発が必要なものであり、一からプログラムを作ることとなりました。 当時、新規の開発ともあり 心を躍らせながら 開発作業を行っていました。 【失態】コーディングがくそ過ぎた、、、 約2か月ほど、色々と壁にぶつかりながら、そしてトレーナーの方の力を借りつつ開発を進めていた矢先、組織変更が行われ、当時行っていた担当案件を開発の途中で同期のエンジニアに引き継ぐことになりました。 当時粛々と開発を進めていく中で、恥ずかしながら、要件さえ満たせればいいという考えでいたため、 ソースコード の共 通化 や可読性などの考えを軽んじていました。 引継ぎが終わり、引継ぎ相手にプログラムを見てもらうと、共 通化 や可読性などの考えが全く反映されていないコードだと気づかれ、「変数名も分かりづらいし、共 通化 もされてない(怒)」と激しく詰められてしました。 【教訓】コーディングで意識すべきこと このように、要件を満たせばいいと勝手に考え開発進めた結果、詰められ、失笑されるといったしくじり経験をしてしまいました。 そんな僕から良いコードを書くためのコーディングで意識すべきことを3つほどお伝えさせていただきます。 ①何か月後かの自分が見ても理解できるか ②変数名の 命名 は、我が子に名前を付けるのと同等 ③コードを書き始める前にプログラムの完成形をイメージをする 上げたらきりがないくらい意識すべきことはあると思いますし、熟練のエンジニアさんにとっては当たり前だと怒られてしまいそうですが、温かい目で見ていただければと思います(笑) ①何か月後かの自分が見ても理解できるか 1つ目は、未来の自分が見ても理解できるかです。プログラムを書いているときは、自分で理解できていると思いますが、何か月後かの自分はほとんど他人であるといわれたことがあります。当時は理解できていても何か月後かにコードを見てみたら理解できない、またはとても分かりづらいなんてことになってしまいます。そのためにも未来の自分でも読みやすいかを軸にコードを書くことを意識すべきだと考えています！ ②変数名の 命名 は、我が子に名前を付けるのと同等 2つ目は、少し大げさですが、我が子に名前を付けるのと同じくらいの気持ちで変数名を 命名 すべきだという事です。変数名を考えるのに時間をかけすぎてしまうのはよくないと思いますが、その変数がどんな役割りなのか、何を格納しているのかを変数を見ただけで分かるように 命名 することで、読みやすいコードになると思います。 実際にしくじり経験をした後から、変数名の 命名 にはとても気を遣っています(笑) ③コードを書き始める前にプログラムの完成形をイメージをする 3つ目も僕は重要だと考えており、完成形やある程度のイメージを持ったうえでコードを書き始めることで、ここは共 通化 できるなとかを考えながらコードを書き進めることができると思います。 しくじり経験をしたときはとりあえずコーディングしながら考えようという意識でいたので、行き詰ってしまっていたリ、共 通化 の意識を軽んじてしまいました。 【推薦】コーディングを学べる本 前章でお伝えしたものは、自分が考えるものであり、意識すべきことのほんの一握りでしかありません。なので本章では、駆け出しエンジニアの方や、エンジニアを目指している方、僕と同じようにコーディングがくそだといわれてしまった方におすすめの本を紹介させていただきます。 1つ目は「 リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック 」という本です。こちらは先輩エンジニアの方にお勧めされ僕自身も読みました。 こちらの本は、特定の プログラミング言語 に特化したものではなく、プログラムを書く際に意識すべきことや、良いコードを書くためにはどのようにすればいいかが書かれています。 エンジニアになったばかりの人でも読みやすいものだと思います！ 2つ目は「 良いコード／悪いコードで学ぶ設計入門 」という本です。 こちらの本は オブジェクト指向 型の言語を元に書かれており、 オブジェクト指向 プログラミング言語 の基礎知識があって、設計を学びじめようと考えている方向けになっています。どんな構造が良いものなのかを理解するために、設計の基本的な考え方や、クラス設計などについてコードを元に解説してくれます。 1つ目の本より少し難しいかもしれませんが、設計の基本的は考え方を学べるのでお勧めです！ 【まとめ】 今回はコーディングがくそ過ぎてしくじってしまった話をさせていただきました。失敗を経験したことで意識的にコードを書くことができるようになったので、今となってはいい経験でした。 実際、先輩エンジニアの方はかなり細かいところまでコードを見ているなと実感しています。なので、人格否定をされてしまう前に最低限のコーディングの基礎を身に付けておく必要があると思います！ 本を読んで完璧に身につけるのは難しいと思います。なので僕も先輩エンジニアにコードをレビューしてもらいながら学んでいるところですので一緒に頑張りましょう。 それではまた次回お会いしましょう！

こんにちは。クルーズ株式会社CTOの鈴木です。 以前の投稿で「 フロントエンドのエラー監視Sentyを導入した話 」でSentry導入の話をしましたが、コアウェブバイタルの監視についてもSentryで最近行うようになったため事例共有をしたいと思います。 Core Web Vitalsの重要性 2021年に Google は、Webページのユーザー体験（UX）の向上を目指して、Web Vitalsという概念を導入することを発表し、特に検索の表示順位に影響を与える指標としてCore Web Vitals を定義しています。 Core Web Vitals のビジネス インパク トについては以下の記事をを参考にしてください。 developers-jp.googleblog.com パフォーマンス計測上の課題 Core Web Vitalsを可視化するツールは Google Search Console をはじめとして様々ありますが、JSエラーと同様に特定のブラウザや特定の条件でしか発生しない課題について網羅的に把握が困難であり、単純に開発者や SEO 担当者が自分のPC上で計測を行うだけでは圧倒的に情報が不足していました。 またページ表示が遅い理由の把握も、遅いページの特定ができれば開発者ツールなどで調査可能ですが、具体的に問題のあるページがなんなのかについては、Webサーバのログや Google Analytics の情報 からし か判断できず、効果的な原因究明が十分に行えておりませんでした。 上記の問題の解決手段としてSentry のPerfomace Monitoringでの監視を実施しています。 導入背景としては 既にJSエラー監視やLaravelのエラー監視で社内で活用実績があること 端末・回線・ブラウザといったような利用環境に関連する情報が取得できること Slack連携が可能で即時通知ができること があります。 運用 Core Web Vitals ＋ LCPについて、以下の 閾値 を設けて監視し、引っかかったものは改善するよう運用そしています Warning ：Good とNeeds Imprrovement の 閾値 の80％以上 Critical.  ：Good とNeeds Imprrovement の 閾値 越え 運用する中で技術的にハマったこと CORSの設定が必要であるということに導入後しばらく気づかず計測が正しくできない、また一部外部サービスとの連携が正常にできない状況になってしまっていました。   特にSentryは日本語の文献が少ないため導入当初全く気づかず、原因の特定にそれなりに時間がかかってしまったことが反省点です。 docs.sentry.io 運用していく中で見えてきたこと 大きなところでいうと 実は実行待ちになっている スクリプト もあり、中には非同期で呼び出せるものも含まれていた。 使われていない スクリプト も読み込んでいた。（正確にはどのページでも共通にも見込んでいたが、そのページでは使っていなかった） 外部連携で使用しているJSファイルの実行に時間がかかっていたものがあった 開発者が意図しない海外 CDN を呼び出している箇所があった（使用しているJSライブラリが海外 CDN を参照していたことがわかった） です。なので今の時点だとほとんどが Google Developer Toolでわかる内容が有益な情報でしたという状態です。 これだけだと Google Developer Toolで十分じゃない？という結論にはなってしまうのですが、Core Web Vitalsの視点で見て課題があるページが発見できることと、フロントエンドエンジニアだけではなく、エンジニア職種全員がSentryというツールを利用することで、問題のある トランザクション のCore Web Vitalsの数値や、各 トランザクション 中のタイムライン上での各リソースファイルの読み込み・実行状況を把握できるようになったことは導入の効果として大きかったと考えています。 特に、この SDK （JSファイルって）っているの？とか、この処理ってサーバ側でやった方が実行速度短縮できない？とかこのJS、 CSS ファイルは自社契約の CDN 上から呼んだ方が早くない？そもそも API が遅すぎるから結果として全体が遅くなるんじゃない？などのディスカッションを様々な技術職種のメンバーと行えるようになったことは極めて重要だと思っています。 まだ運用を始めて間もないですが、Sentryを活用してWebページのユーザー体験を向上させていきます。

こんにちは。新卒2年目のRYOBALです。 僕は入社後サーバーサイドエンジニアとして配属され、一年後にあたる今年4月から マーケティング 部に異動しました。 元々、 マーケティング 部の業務には興味を持っており、タイミングよくこの機会に希望した部署に異動となりました。 今回は マーケティング 部に移動して1か月が経ったので、エンジニアから マーケティング 部に移動して気づいたエンジニア経験をして良かったことをお伝えします。 マーケティング 部ってどんな仕事をしているの？エンジニアの経験って何に役立つの？と気になる方に参考となる記事なので、ぜひ最後までご覧ください。 そもそもエンジニアとしてどんなことしてたの？ マーケティング 部に移動して気づいたエンジニアとして良かったことを語る前にこれまで僕がエンジニアとしてどんな業務を経験したのかお伝えします。 入社後3か月間の開発研修後、サーバーサイドエンジニアとして配属され、 PHP やLaravelを使って社内管理画面の改修、Metabaseを使って管理画面の移行（詳しくは こちら の記事）を行ってきました。 実際に社内で使われている管理画面の改修など実際に ソースコード を触っての開発、データベースの操作をするなど基礎的なエンジニアとしての業務を行ってきました。 このような開発経験を通して、僕は マーケティング 部に移動しました。 マーケティング 部に移動して一番最初に驚いたことが、、、 マーケティング 部でも開発の知識がないと話にならない！？ マーケティング 部に移動して一番最初に驚いたことは「開発の知識がないとついていけない！」ということです。 僕が行っている マーケティング 部での業務内容はBigQueryを使った施策の分析です。例えば、このキャンペーンは何人の利用者がいて、どのくらい効果があったのかなどBigQueryを使って集計し、施策を分析します。BigQueryを扱うので、 SQL は書けて当然の現場です。 開発部の経験があったので多少 SQL の知識はありましたが、それでも大変な内容でした。 1,000行近くになるクエリを書くなどこれまで経験したことのない長いクエリを書くことになり、頭が追いつきません（笑） 今思うと、エンジニアだからといって、0からクエリを書く機会ってあまりないのかなと思っています。 新規プロダクトの場合は別ですが、既にプロダクトが存在している場合はデータの取得はすでに完成されたクエリでできている状態です。なので、データの取得方法を変えるなど修正がある時にしかクエリには触れません。 そんなこともあり、開発部でガッツリ SQL に触れていなかった僕はBigQuery上のデータベースのルールやクエリを書くことに慣れることが大変でした。 エンジニア時代に経験していて良かったこと マーケティング 部での業務を通してエンジニア時代に経験していて良かったと思うことは主に2つです。 1. SQL ・データベースの知識 2.開発経験 まず1つ目の SQL ・データベースの知識ですが、前述したとおり、業務内容がBigQueryを使って分析するということもあり、この知識がなければ仕事になりません。 「 SQL ってなに？」という全くの未経験の状態からだと相当大変だったと思います。そう思うと、エンジニア時代に少しでも学んでいたことが今の仕事に繋がっているんだと実感しています。 2つ目の開発経験ですが、これはエンジニア視点で物事を考える意味で役立っています。 マーケティング 部から開発部に対して新機能の実装など依頼をする機会は多々あります。その際に、ここの ソースコード をいじると実装できそうだなと開発者でなくとも何となく想像することができます。そうすると、開発部のメンバーに依頼がしやすくなり、リリースまでどのくらい 工数 がかかるのもイメージができます。 どの部署の人でも開発の知識があるのとないのとでは、開発者との仕事の進め方に雲泥の差が生まれます。 「マーケターはプロモーションができれば良いからプログラミングの知識なんかいらない！」と思う人もいるかもしれません。ただ、 マーケティング を考えられる プログラマー が仕事ができるようにプログラミングができるマーケターも強いです。 マーケティング だけやプログラミング、営業だけなど一つのことができればよいという時代終わりつつあるかなと思います。 まとめ 今回は新卒エンジニアから マーケティング 部に移動して気づいたエンジニアとして経験して良かったことについてお伝えしました。 2つの部署を経験して、改めて開発の知識はどの部署でも必要なものだと感じました。特にIT業界で勤めている人であれば、ITスキルは必要不可欠です。 自分は営業だからといって、ITの知識を無視できるわけではありません。 これからの時代に活躍するためにも開発経験やITの知識は重要になってくるでしょう。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。また、他にも面白い記事を発信しているので是非別記事も読んでみてください。それでは、また次回のブログで。 BYE☆

こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「リモートワーク下におけるコミュニケーションの難しさと解決方法」についてのお話をしたいと思います。 昨今、 新型コロナウイルス 感染症 拡大に伴いリモートワークを導入する企業が増えていると思います。そんなリモートワークを配属直後から経験し、リモートだからこそ感じた難しさといかに解決したのかを紹介したいと思います。 また、対面だろうが非対面だろうが、コミュニケーションを取る上で大事だと感じたことをお話できればと思いますので、最後まで読んでいただければ嬉しいです！ 【配属】配属された瞬間にリモートワーク！ 僕が入社するタイミングは新型コロナが流行し、世の中的にもリモートワークすることが一般的になってきている状況でした。弊社でももちろん、リモートワーク制度を導入していて、僕も配属されてからリモートワークをすることが多くなりました。 読んでくださっている方の中には、新入社員はなるべく出社した方が良いと思われる方もいるかと思います。ただ、出社したとしてもトレーナーをしてくださっていた先輩社員がリモートワークなので、出社しようがしまいが非対面でのコミュニケーションが余儀なくされる状況でした。 そんな状況の中でリモートワークを始めたわけですが、当初は「リモートで働いている自分スマート！」と思っていました（笑）。 意気揚々とリモートワークをしていたわけですが、徐々にリモートワークにおけるコミュニケーションの壁にぶち当たることになります、、、。 【衝突】リモートワークにおけるコミュニケーションの壁 リモートワークにおけるコミュニケーションのほとんどは、チャットで行うわけですが、口頭であれば難なく伝えられる内容を、文字に起こすことに難さと時間がかかることを感じました。 直接であれば、困っている現象や分からない部分を見せながら聞くことができたりしますが、チャットだと画像を添付して伝えることが限界な気がします(動画で伝えることもできますがあまり現実的ではない)。そのため、チャット上でのコミュニケーションでは 言語化 する能力が低いと伝えたいことが全然伝わらないといったことが起きてしまいます。 配属当初は分からない事ばかりで、質問することが多かったのですが、そもそも開発知識が乏しかったり、コミュニケーション時に意識すべきこと(後述します)を意識しておらず、うまく 言語化 することができませんでした。そのため、正しく伝わるまでに複数回のラリーが必要になることもありました。 本格的に開発作業を行うようになり、いよいよチャットだけのコミュニケーションでは太刀打ちできなくなりました。 なので、プログラムがうまく動かない時や、実装方法が分からない時は画面共有を行い ソースコード を見てもらいながら、教えてもらっていました。これでだいぶコミュニケーションを楽に取れるようになりました。 ソースコード の画面共有をしながら「どこどこのの〇〇を〇〇に修正して！」などの指示をもとに実装や修正をするわけですが、少しラグがあったり、 PHP 構文の書き方が分からない場合はプラスでもらう必要があり、まだまだ時間がかかってしまいます。 【発見】まさかの解決方法 画面共有で ソースコード を見せながらのコミュニケーションでもまだまだ時間がかかってしまっていたと述べていますが、この ソースコード を見せながらの実装や修正することは所謂 ペアプログラミング のようなものに近いかなと思います。特に未経験のエンジニアの方は実際に ソースコード を見てもらいながら修正等を行うことがあるのかなと思います。 ここで紹介するのはそんな作業を効率的にできる機能です。 それは、 Microsoft 製コードエディター「 Visual Studio Code 」の機能の一つである「Live Share」というものです。これは、一つのソードコードを複数人で閲覧・編集することが可能で、 デバッグ 操作等も可能なので ペアプログラミング やコードレビューに便利な機能となっています。 つまり、この機能のおかげでわざわざ画面共有をせずとも、お互い ソースコード を見ながらコミュケーションが取れるわけです。この機能を発見し使用してみると、とてもスムーズに開発や修正を行うことができるようになりましたし、教える側にとっても教えやすいという声も頂きました。 さらに、その場でざっくりとしたプログラムだけ作ってもらい、詳細なプログラムは自分で考えるといったような進め方もできるので、とても有効な機能かと思います。 【自戒】コミュケーションで気を付けるべきこととは！？ 前章で述べたような、便利な機能に頼った解決方法もいいかと思いますが、本質的な解決策はコミュニケーション能力を向上させることではないかと思います。 僕自身、１年目は特に、質問や助けを求めることが多かったですし、うまく伝えることができないことも多々ありました。 そんな中で、どんなことを意識すれば相手に伝わりやすく円滑なコミュニケーションが取れるのか自分なりに考えていました。 そこで、僕が質問や助けを求めるときに、どんな意識をしたらうまく伝えられようになったのかを3つほど紹介させていただきます。 ①結論から述べる ②どこまで分かっていて、どこで詰まっているのか明確に ③分からないなりの仮説を持つ 上記の3つを意識すべき理由として、質問される側は、その人は「①何が分からないのか・②どこまで分かっているのか・③どのように考えているのか」が分からなければ、そこの確認から始めなければなりません。 かなり当たり前のことですが、ここをしっかり 言語化 で来ていないと無駄なラリーが生まれてしまいます。 【まとめ】 今回はリモートワークの中でいかにコミュニケーションコストを下げたのかについてお話させていただきました。 新卒で入社してから自立するまでは、多くのコミュニケーションを取る必要があると思います。そのため、コミュニケーションコストを下げることは自分にとっても、コミュニケーションを取る相手にとっても大事なことだと思います。 社会人2年目になり、自ら発信することも増えてくると思います。そんな時に意識することはもっと増えていきます。また、物事を正しくわかりやすく相手に伝えることはビジネスマンにとって非常に重要なスキルの1つだと思ています。 コミュニケーションの訓練をしっかり行い、コミュニケーション能力激高のエンジニアになれるように頑張ります！ 今回はこれくらいにして、また次回の記事でお会いしましょう！

こんにちは。クルーズ株式会社CTOの鈴木です。 2021年の10月ごろからフロンエンドのエラー監視としてSentryを導入してしています。 導入から6ヶ月が経ち、運用にも乗ってきたので事例として共有したいと思います。 JSのエラーが原因で立て続けに問題が起こった 当時、特定ブラウザだけボタンを押しても動作しない問題や、サービスとしては正常に動くんだけど効果測定用に送っているイベントが発火しない問題が立て続けに起き、原因の特定と修正に長いものだと３営業日かかってしまうことがありました。 この件で問題だと感じた点は以下です。 サーバと違って、ブラウザ上で動作するものは明示的にログをどこかに送ってやらない限り実行しているブラウザ上でしかエラーに気づけない。 特定ブラウザのみで発生する場合、問題が発覚しても開発者がその問題を特定するまで時間がかかる。（再現条件の特定に時間がかかる） 表示に影響しない計測系のイベント発火は見落とされやすい。（表示上は正常なため） 上記問題を解決する方法の一つとして、以前に AWS Fargate上に構築したコンテナ上で動作するLaravelのエラー送信で使っているSentryでJSのエラー監視を行うことにしました。 Sentryの導入 導入はドキュメントの通りに行い、非常に容易に出来ました。 検知されたエラーはIssuesという形でチケットとして上がってくるので、運用としては 検知されたエラーはフロントエンドの専門職種長が対処が必要かどうかをまず判断する。 対処が必要なものは担当者を アサイ ンして、 リファクタリング タスク化する アサイ ンされた担当者は修正し、直近のリリースに混ぜ込んで修正リリースする。 という形で行っています。 またエラー内容や件数といった情報は、エンジニア全員の参加する会議体の中で共有し、今どのような問題は発生しているかについてエンジニア全員が知ることができるようにしています。興味のある人はSenty上から詳細レポートを見れるよう、アカウントもエンジニア全員に配布しています。 Sentry以外で実施していること 実際にサービス側で発生していたエラーの中では、開発環境でも起こっていたけど気づかずにリリースされてしまったものも含まれていたため、eslintも合わせて導入しています。 これは各個人の開発環境と、GitLabに連携したJenkinsのCI/CD環境で動作しており、前者はデプロイ前にエラーが出ていないことの確認に、後者はエンジニア全体に共有するためノレポーティングとして活用しています。 なので、リリース前にエラーを最小にする＋サービス上で発生していたエラーを早期検知できるようにするという２段構えでJSエラーへの対応を行なっています 運用していてよかったこと・課題感 ざっくりとですが、 よかったこと 品質メトリクスとしてエラー件数が可視化ができること（共通の品質目標としてエラー0件を目指すんだ！と言えることと、実際に件数が見えること） 発生しているデ バイス ・ブラウザの情報が取れるため、原因の特定にかかる調査時間が短縮できること 課題感 動作保証ブラウザで発生以外からのエラーレポートが雑音になる タグマネージャによって ソースコード 管理外でHTML内に挿入されるJSのエラーの場合、検知しても問題の特定に時間がかかるケースがある（ ソースコード から追えないため） ダッシュ ボードなどまだ効果的に活用しきれていない部分がある。 です。 自分自身がサーバの経験の方が長く、フロントエンド分野について全てが把握できているわけではないため、技術寄り視点というよりは管理寄りな視点での感想となってしまいましたが上記のように感じています。 その他、エラー検知だけでなくパフォーマンス計測にもSentryを活用すべく、Performance Monitoring の運用も並行して進めていてその内容についても改めて共有します。

こんにちは。クルーズ株式会社CTOの鈴木です。 今回は、ブラウザベースの IDE の AWS Cloud9の話です。 先日に「 クルーズで5年ぶりに新入社員向けにプログラミング研修を再開した話 」でも触れたとおり、当社では、新入社員向けの研修の一環で職種に関係なくIT リテラシー の教育の一環としてプログラミングスキルに関する研修も実施しています。 その中で、今年の内定者向けの研修から AWS Cloud9を使い、HTML、JS、 PHP の基礎的な研修で活用しています。 新人向けにプログラミング教育を実施する理由 クルーズグループでは、新卒社員向けの募集職種として営業、開発などの職種別採用は現在実施しておらず、「新卒」という一つのくくりで採用を行い、ビジネススキルの教育もITスキルの教育も内定者全員共通の内容で実施しています。 新卒向けにITスキル教育の一環としてプログラミングの研修を実施している理由としては、当社がインターネット上でサービスを提供しており大前提としてインターネットに関連する知識や経験がないと企画の立案や効果検証を効果的に行えないこと、また自社プロダクトとしてインターネットサービスを開発していく上でプログラムの設計・実装に関する知識がないと要件を決めきれないことがあり、入社の前から基礎的な教育を内定承諾後よりリモート研修という形で実施しています。 入社後については、素養や適性を判断し配属部門が決定され、ビジネスサイドの部門に配属されるメンバーは、4月に営業部門配属、エンジニア部門に配属されるメンバーは引き続き3ヶ月の開発の研修を経て開発部門に配属となります。 内定者研修でCoud9を採用した理由 初期環境構築を個々で行う必要がない 前述のように専門職種としてエンジニア職採用をしておらず、基本的に環境構築の経験のない人がほとんどです。 そのような状況で、仮に Vagrant やDockerでローカル開発環境を配ろうにもまず Vagrant やDockerの動作環境を作ること自体がハードルが高く、かつ昔のように土日集まって研修を行うといったことが出来ないです。 また初期構築につまづくと、もうその時点でプログラミングに苦手意識を持ってしまう人もいるので、手軽に簡単なコードを書いて実行できるものはないかと色々考えた末、 AWS Cloud9を採用しました。 実際には一番初めに特定のコマンドを流して環境構築は行ってもらうのですが、PC上での環境構築とは違い、EC2上での構築でかつ、OSバージョンなどの初期構成に差がないので初期構築にハマって研修運営が滞ることがなく非常にやりやすかったです。 IDE ＋サーバとして機能するのでCoud9上で完結できる 環境構築を必要としないプログラミングの研修手段としては、他にもオンラインエディタもあります。 ただオンラインエディタの場合、目的によってエディタを使い分けなければならない事やこの部分はサーバサイド言語で書いて、ここはフロント実装して、成果物はGitで管理してといったような実際の開発に近いことを行うことが難しく、実際の IDE として機能するものがCloud9だったというもの選定の理由として大きいです。 特に IDE 上から インスタンス に対しOSコマンド操作ができることや、Webサーバの成果物のプレビューができることが大きく、実際にtailコマンドでログを確認しながら デバッグ できることのメリットは大きかったです。 手軽に実践できる環境が欲しかった 当社ではプログラム教育に力を入れているものの、新入社員全員が入社後開発職種として活躍することを期待しているわけではないです。 開発の知識を新入社員全員が理解していることが共通で求められ、そこから先は素養や適性判断でエンジニア部門配属の人はさらに３ヶ月間、クラス設計やGit-Flowなどのお作法的な内容から、DB設計やチューニングなど様々なことを学んでいきます。 なのでまずは手軽にコードをかけてそれが成果物として見れて、 リポジトリ 操作ができる環境があればよく、その要件を満たせたため採用しています。 導入してみて 手軽にコードをかける環境としては最適！ 特に環境構築面は（環境を構築させる側の視点で言っています）はすごく手間が少なかったです。 研修を受ける側の人にとっては初めて使う IDE なので多少は戸惑っていたものの、1時間くらいの操作で IDE の基本的な操作には慣れてきていたので、研修用途としては最適だと判断しています。 一方で業務上の利用を考えると、ブラウザベースでマルチディスプレイ対応してないから生産性どうなんだろうとか、 VSCode 上で行っているファイル保存時のLintとか諸々どうしようとか考えないとならないことはまだ多いのですが、ブラウザと電波さえあればどこでも開発できる手軽さはものすごく魅力なので、DaaS的な活用も今後検討していきたいと思っています。

こんにちは。クルーズ株式会社CTOの鈴木です。 今回は開発の話とは少し話がずれるのですが、5年ぶりに新入社員向けプログラミング研修をしましたという話をしたいと思います。 CROOZ では2013年度から2016年度のエンジニアとして配属する新入社員までは新入社員向けの教育としてプログラミング研修を配属前の3カ月間行っていました。 その後紆余曲折あり2017年度以降はしばらく行うことがはなかったのですが、今年度より実施の運びとなりました。 プログラミング研修を新入社員に行っている理由 それは、プログラミングがビジネススキルの一つだと考えているためです。 当社はインターネット上でサービスを運用しており、ITについての知識を持った上で活用できなければ、良いサービスを提供し続けることができず、いつかは生き残れなくなります。 また、今後はますます技術が発展しインターネットを通じたサービスが身近になっていきます。そのような時代になるとき、プログラミングというスキルは必ず必要となってきます。 なぜならプログラムで書かれたものの上でサービスを展開しており、それがどのような仕組みで動いていて、エンドユーザや従業員にどのような役割をしているのかが理解でき、それを要件として決められないと新しい価値や機能を提供することができず、結果としてビジネスに取り残されてしまうためです。 なので極論を言うとプログラムを書けることが重要というわけではなく、コンピューター上でサービスを提供するにはどのような仕組みが必要で、どのようなプログラムを作る必要があるのかという「プログラムの考え方」や設計の仕方、要件の出し方や、プログラムを製造するプロジェクト管理の一覧の流れについて学ぶことがとても重要となります。 このようなことから、プログラミングは最強のビジネススキルであると言われることもあります。 世の中の動きとしても、 ・米General Electric社の会長兼CEOのジェフリー氏が「今後採用する20代の社員に関しては、採用する職種にかかわりなくプログラミング能力を必須とする方針」を表明している。 ・ Wantedly CEOの仲氏は「最初の『モノ』を作る段階で必要になるプログラミングの方が、いまや MBA よりも圧倒的に需要が高い」と発言している。 ・ ドワンゴ が監修した書籍「プログラミングは最強のビジネススキルである」の中で、「現代において人とどう付き合うかではなく、コンピュータとどう付き合うかが重要で、そのために方法論としてプログラミングを学ぶことが最も有効な戦略である」という記載がある。 ・ 楽天 では約2万人の全従業員に対し、初級レベルのプログラミング能力を必須とする方針を2019年に出している。 など、ビジネススキルとしてのプログラミングに今注目がされています。 当社のプログラミング教育について 前提として、クルーズグループの新卒の募集としては総合職種なので、入社時点で大部分の新入社員はプログラミングスキルを身に付けていません。 プログラミング教育については、内定承諾時から入社までに実施する教育と、入社後に3カ月間かけて実施する教育と大きく2つに分かれます。 内定承諾時から入社までに実施する教育では主に開発者と会話するために必要なITの用語やプロジェクトの管理手法に関連する知識、各種サーバの役割といった自分が開発者に適切に開発の依頼を行うために必要な基礎知識の習得と、コンピュータ言語として SQL と Google App Script の習得を行います。 これは、どの職種においても配属後に開発者に対して適切な開発リク エス トを行い、課題解決のために自身でデータの抽出を行い分析ができるようにするために入社前教育として実施しています。 入社前教育終了時にプログラミング習得の素養を判断し、素養ありと判断された人については入社後3カ月かけてプログラミングスキルの習得をしていきます。 研修で具体的に何を行っているかなどの内容についてはまた別の投稿で書いてきたいと思います。

こんにちは。新卒1年目のRYOBALです。 社内のMDやプロモーション部、開発部などが使用している管理画面が存在するのですが、今回はその管理画面の一部をMetabaseというツールに移行する業務を行ったので、その内容について発信していきます。 これまで Metabase を使ったことがある方、これから使う方、私がどんな業務をしているのか気になる方はお楽しみできる内容だと思います。 Metabaseってそもそも何？ Metabaseとは、Metabaseプロジェクトによって開発されている オープンソース ソフトウェアのデータ可視化ツールです。データ可視化ツールは ダッシュ ボードソフトウェア・BIツールとも呼ばれています。Metabaseで可視化したデータを分析に役立てることができます。 また、Metabaseでは他のも下記のような豊富に、機能がありとても便利なツールです。 ・グラフの種類が豊富 ・ LDAP や Google アカウントを利用した認証 ・利用頻度の高い検索条件の登録機能 ・Slackとの連携 ・日本語対応 そもそもなぜ今回、管理画面の一部をMetabaseに移行することになったのか。 それはこれから新たに管理画面の改修が発生した場合、Metabaseに移行しておくと改修がしやすくなるからです。なぜ、改修しやすいのか説明していきます。 まず、現在のサイト管理画面は PHP をメインに開発されています。 管理画面では SQL を使って検索結果の表示やデータの登録、編集、更新などを管理画面上でボタン一つ押すだけで可能になっています。 例えば、新しく商品を追加したいときには必要な情報を入力して「商品登録ボタン」をクリックすると商品登録ができるような仕様になっています。 今回、管理画面からMetabaseに移行した画面は SQL でSELECTしてデータを取り出し、クエリの結果を画面に表示させている画面です。つまり、データの登録や更新作業がないので、Metabaseに移行ができる画面です。 Metabaseに移行しておくことで、今後画面の改修を行う際に、わざわざコードを修正することもなく、操作しやすいMetabaseで改修ができるというメリットがあるのです。 Metabaseへの移行が思ったより難しかった件 Metabaseでは SQL を直接記載して結果を出力できるので、 SQL さえ書くことができれば特別難しくなく操作ができます。 しかし、これが思ったより苦戦したんです。。 最初は SQL を記載するだけで集計結果がすぐに出て、棒グラフや円グラフなどビジュアライズも簡単にできたので、「これは便利すぎる！」と感動していたのですが、ある時、つまづいてしまいました。 具体的にはMetabaseならではの記載方法がある点につまづき苦戦しました。 MetabaseではMetabase独自の SQL の記載方法があります。 例えば、変数は{{}}を使って記載するなど普段、 SQL に触れていても知らない内容が多数ありました。 もちろんわからないことはググればある程度出てくるのですが、Metabaseの文献は案外少なく、Metabaseのバージョンによってできることとできないこともあり、なかなか調べるのも大変でした。。 英語が分からないながらも海外の文献も調べてMetabaseについて毎日調べました。 学生の時にもう少し英語の勉強すればよかったと改めて感じた。。(笑) そんなこんなで苦戦しながらもなんとか仕様を理解して、順調に管理画面を Metabase に移行していましたが、そんな時にある問題が起きます。。 何度やっても集計結果が合わない 管理画面の SQL を特に変えることなく、Metabaseに移行しているのにも関わらず集計結果が合わないのです。 内容自体は同じなのに、集計結果が合わないなんて何が起こっているのかさっぱりわかりませんでした。(笑) 問題の原因はMetabaseの特有の記載である[ ]の使い方でした。[ ]で囲むと、囲まれた範囲内の変数が入力されたときのみ、その中の構文が評価されます。 例えば、WHERE [[ and {{product_name}} ]] という記載がある時に これは変数product_nameの中に値があればWHERE句として構文が読み込まれます。 このルールを知っていれば、全く問題ではないのですが、このルールを知らずに長い時間苦戦してしました。 この問題が解決した時は嬉しくて涙が出るほどでした。。(笑) 社内の管理画面をMetabaseに移行してみて 今回社内の管理画面をMetabaseに移行してみて自分自身、これまでツールの移行作業は「すごく手間のかかる面倒な作業だ」と思っていましたが、実際にやってみると意外に自分でもできるし便利だと実感しました。 もちろん、途中で苦戦することもありましたが、それでもこれまで経験がない作業を経験できたことは良かったと思っています。 普段当たり前に使っているツールでも最初は誰かがツールの設定、初めての人でも使いやすいようにマニュアルを作成するなど、陰ながらの努力がされているのだと感じました。今後も社内では様々なツールが導入されていくと思うので、その際は進んで手をあげていこうと思います。 まとめ 今回は社内の管理画面をMetabaseに移行するといった内容についてお伝えしました。 世の中では日々便利なツールが誕生しています。 社内の生産性を上げる上では欠かせないツールもたくさん存在しています。そんなツールが出た際に、いち早くキャッチアップし、移行することで社内の生産性が上がると今回仕事を通して身にしみて感じました。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。それでは、また次回のブログで。 BYE☆

こんにちは。クルーズ株式会社CTOの鈴木です。 以前の投稿で「 AWS Auto Scaling によるインスタンス管理に切り替えた話 」を話をしましたが、今回は、新規プロジェクトより管理画面でEC2ではなくコンテナでのサービス運用を開始した話について書こうと思います。 本番環境でコンテナ化を進めている理由 ローカル環境を含む開発環境でコンテナを利用するケースは多いですが、本番環境であえてコンテナを導入していない会社もあるのではないかと思います その中でも本番環境でコンテナを導入することのメリットについて、私は以下のように考えています。 ①インフラ保守コストの削減 単純に インスタンス 費用だけで考えればEC2をはじめとする仮想サーバと変わらないか、むしろ仮想サーバのほうがコストは安く運用できるかもしれません。 ただし、一方でOSのメンテナンスはインフラ部門としてはし続けなければならず、インフラ全体の 工数 から見れば微々成るものではあるものの、永続的にメンテナンスコストが発生します。 コンテナを利用することでOSのメンテナンスにかかる 工数 を削減し、別の価値のある仕組み化を実現する 工数 に充てることが可能となります。 ②より柔軟にスケール可能なインフラを実現し、サービスレベルを向上させるため ここがもっともメリットとしてはとしては大きいと考えています。 現状のEC2ベースのオートスケールではスケールアウトに約10～15分ほどの時間がかかっています。 昔のように手動で構築している時と比較すれば半分には短縮できたものの、例えば急に負荷かかっても10分～15分の間のサーバ台数の増加は見込めず、その時間はサイトに繋がりづらくなったり、最悪の場合にサービスダウンの可能性があります。 コンテナを利用することにより、デプロイにかかる時間を数分に短縮が可能で、より柔軟にスケールできるインフラの実現ができることが期待できます。 ③ TCO (トータルコスト)の削減 デプロイ時間の短縮により、サーバの役割によっては敢えて冗長構成を行わず1台で運転することでコストダウンが図れるものがあるのではないかと考えています。 例えば、社内の特定ユーザしか使わず、仮に数分のサービスダウンであれば運用上受容可能なサービスであればシングル構成で運用する。1日数時間だけ動けばいいバッチ インスタンス であれば1台構成でその時間だけ運転し、コンテナが落ちても立ち上げ直して再実行するなど。 同じサービスレベルであっても、デプロイ時間の短縮によりシングル構成で運転できる インスタンス が生まれ、その部分のコストの削減が可能ではないかと考えています。 ④ クラウド ベンダのしばりがなくなる コンテナ化により、ベンダー移行が容易になることが得られるメリットとしては大きいと考えています。 今までは特定の クラウド ベンダーで構築した場合、仮に品質やコストに優れた後発ベンダーやサービスが出てもシステムの移行が非常に困難でした。 コンテナ化により、 クラウド ベンダー間の縛りがなくなり、インフラ調達面での柔軟性の向上が期待できます。 上記の理由で、Web 及びバッチについては現在コンテナ化の利用を、DBやメールサーバについてはPaaSの利用を進めており、今回は新規で構築する管理画面よりコンテナでの運用を開始しました。 コンテナ化において苦労したこと １．ドキュメントの少なさ 今回コンテナの基盤として AWS Fargateを使用しましたが、想定よりもトラブルシュート面でいろいろ苦労しました。 特に既定の設定でTaskを構築しデプロイしてもコンテナ内にファイル書き込みできるものと出来ないケースがあり、その原因の特定など、 AWS 公式ドキュメントに記載がない部分がありそれを トライアンドエラー で切り分けながらの構築であったため非常に苦労がありました。 この部分については、率直に言って AWS 側には改善いただきたい部分だt考えています。 ２． デバッグ のしづらさ これはある程度仕方がない部分ですが、OS部分がマネージドになっている部分、OSを直接操作することができないので、インフラ構築面の デバッグ での苦労はありました。 結局ECS EXEC コマンドが公開されたおかげでOS側へのコマンド実行ができるようになったため デバッグ は容易になりましたが、基本的にはしづらいです。 なので一度構築するまでは結構苦労する部分があるのではないかと思います。 今後の展望 現在新規構築の管理画面のみコンテナ上で運用しており、しばらく運用のナレッジの築盛期ののち、定期的に実施しているOS/ ミドルウェア のバージョンアップのタイミングに合わせ逐次切り替えを行い、最終的にはWebおよびバッチ インスタンス についてはコンテナに切り替えていくことを考えています。 もちろん、現時点での話なので、運用の中で出てくる課題によってはコンテナという選択肢以外にEC2のような仮想サーバを採用するケースや、 AWS API Gateway ＋Lambdaや GCP のCloud Functionといったマイクロサービスの採用の可能性も当然ありますがまずは運用でナレッジを蓄積していこうと考えています。

こんにちは！クルーズ株式会社の広報担当です。 今回は先日開催した社内イベントについてご紹介します！ 今回はクルーズの技術PR顧問に就任した Ruby の生みの親Matzさんこと まつもとゆきひろ 氏にも参加いただき、LT発表やディスカッションを行いました。 今回のイベントの背景 今回のイベントには2つの目的がありました。 ・技術PR顧問に就任した まつもとゆきひろ 氏に、当社の技術スタックを知ってもらう ・一緒に働くメンバーにどのような人がいるかを知ってもらう。 SHOPLISTには、開発部21時フィードバックという、新しい技術の導入や、働き方を改善するための施策を経営陣と直接話して即時に決定していくという取り組みを行っています。 ただ、一緒に働いているメンバーがどんな技術をどう取り入れ、どう活用しているのかというような情報を共有する場はなく、社内共有できる場を設けようと思いイベントを開催いたしました。 イベントのコンテンツについて 今回のイベントはメンバーからのLT発表とまつもとさんとのディスカッションの大きく2つのコンテンツで開催しました。 LT発表会には3名参加しましたが、読書の効率化アプリを開発した話やアイドルが好きすぎて遠征ドルオタのための便利サイトを作った話、1年目のしくじった話と 癖のある発表でした（笑） 3名とも OSS を活用し、自分の理想とするモノを作りあげる執念は 非エンジニアの私 からし てもかなり面白い内容となっていました。 まつもとさんとのディスカッションでは、事前にメンバーから募った質問への回答を中心に Ruby を開発するまでの背景やどういう体制で開発を行っているのかという話からエンジニアの キャリアパス や、組織体制の話、リモート環境をどう整えているのかなど様々なテーマでお話いただきました。 Ruby 開発のお話をメインでしていただきましたが、 ご自身の業務効率のためにツールを開発したり、 Ruby 以外にも開発してきた OSS について普段聞くことのできないお話もしていただけました。 業務時間後にイベントを開催しましたが、30名以上のメンバーに参加していただき、 「まつもとさんと交流ができてよかった。」「普段聞けない裏話まで聞けて良かった。」などうれしい感想まで聞くことができました。 社内イベントも今後定期的に開催していきたいと思います。 最後に 4月13日（水）19時から弊社主催のテックイベント『TECHHILLS』を開催します。 まつもとさんをモデレーターにメルカリさん・CADDiさんにも登壇していただきます。 イベント申込・詳細確認は以下ご確認ください。 techplay.jp

こんにちは。今日から2年目に突入したエンジニアのKEN☆YAMAGUCHIです。 今回のテーマは、僕がちょうど1年前に経験した開発研修についてです。開発研修とは具体的に言うと、4月に入社してから、開発部に配属されるまで行った、3か月間の研修のことです。この3か月間の開発研修ではいくつかの研修を行いましたが、その中でも最初に行った研修である「じゃんけんゲーム」の開発についてお話ししたいと思います。 ちなみに、今回じゃんけんゲームの開発は、僕が初め開発というものを経験した、思い出深いものとなっています。 最後まで読んでいただければ嬉しいです。 【始動】いざ開発研修スタート 4月に入社してから待っていたのは3か月間の開発研修でした。研修は、大まかに分けると、 基本情報技術者試験 の勉強・ SQL 研修・プログラミング研修の三本立てでした。 文系出身の僕はもちろんプログラミングは行ったことがなかったので、開発知識は全くのゼロからのスタートとなります。 そんな不安な思いを抱きながらスタートした研修ですが、まず初めに シェルスクリプト を使用して簡単なif文を作成してプログラムを書くことになれるところから始まりました。 そして徐々にプログラムを書くことや、プログラムの仕組みなどに慣れてきたころに、じゃんけんゲームの開発を行うことになります、、、 【衝撃】じゃんけんゲームを作りなさい！？ ここからは僕が開発した初の成果物にあたる、じゃんけんゲーム開発についてお話させていいただきます。 ベテランエンジニアの方には、じゃんけんゲームと聞いて懐かしい思い出、駆け出しエンジニアの方であれば、新鮮な思い出ではないでしょうか？ じゃんけんゲームは、ifやforeach、配列がどんな書き方を学びながら開発できるものであり、難しい php の関数を使うことなく開発できるので、プログミング初心者とってはいい教材だと考えています 。 じゃんけんゲームの流れは簡単に下記のようなものです。 プレイヤーがじゃんけんの手を選ぶ 「勝負」ボタンをクリックして値をPOSTする POSTを受け取ったらコンピューターの手をランダムで選ぶ (配列) プレイヤーとコンピューターで勝負する (条件分岐) 勝敗とプレイヤー、コンピューターの手を画面に表示する 相手の手を配列に格納したり、条件分岐で勝敗判定をしたりと、初歩的なことを学べます。 今思うとすごく簡単なプログラムですが、当時は苦戦していました、、、（笑） そんな中でも、徐々に開発ができてきてもう完成したと確信してテストを行っていました。実際にじゃんけんをしていると、判定が「負けしか」出ていないことに気づきました。 選択した手とコンピューターの手では絶対に勝っているのに判定は「負け」、、、この時の絶望感は大きいものでした。自分の手で作ったものが動くこと・逆に正常に動かないといったものに慣れていない頃だったので、ちょっとのエラーや正常な挙動に一喜一憂しておりました。 【絶望】何回やっても「負け」判定 何度試しても「負け」の判定は治らないので、コードを見てどこが間違っているのか考えてみました。 勝敗判定を行っているのは、条件分岐であるのでif文が間違っているのではないかと目星を付け注意深く見てみると、完全にif文の記述が間違っていたことに気が付きました。 というのも、今回じゃんけんゲームを作る際に、手を「グー、チョキ、パー」という文字列ではなく、「１，２，３」という風に数字で管理していました。 そうするとif文の中で、「＜・＞・＝」を使用し勝敗判定をすることができます。その使い方を間違えてしまい「負け」になる確率が高くなってしまったのです。 そして、正しいif文に修正を行い再度試してみると、何度やっても正しい勝敗判定をしてくれました。 【完遂】じゃんけんゲーム開発で学んだこと そんなこんなあり、じゃんけんゲームを完成させることができました。配列の仕組み・条件分岐など、プログラミングの基本的なことを学べたと同時に、エラーとの向き合い方・プログラミングは泥臭さが大事であることを学びました。 今回のように単純なプログラムではエラーの解消は比較的簡単ではありますが、複雑な作りになっている webサービス でそう簡単にいきません。 エラー解消や地道にログを確認するなどの泥臭さは、エンジニアに必要な要素の一つだと考えます。 今では、エラーが起きても焦らず、ログを確認して修正することができています。 そして何より、自分の手で作ったものが実際に動くことにとても感動しました。その気持ちを今でも忘れておらず、小さなことでもサービスに反映されたときはうれしいし、やりがいを感じています。 【まとめ】 今回は「じゃんけんゲーム」をテーマにお話しさせていただきました。 僕のように未経験でエンジニアを目指している人も読んでくれているかもしれませんが、プログラミングは一見するとスマートに見えるものです。しかし実際には、泥臭さくコードやログと向き合うことが多いです。 ただ、その先にあるやりがいは大きいなものがあると思います。特に自社でサービスを開発していれば、直に自分の行った開発の効果や課題を肌で感じることができ、やりがいを感じられると思います。 4月に入社してから、新卒でエンジニアになるという貴重な経験をさせてもらえていますが、まだまだ未熟なエンジニアであることを日々感じています。 ただ、この経験を無駄にせず、地道に学んでいき、スーパーエンジニアになれるよう精進していきたいと思います。 これからエンジニアを目指す方、僕と同じような駆け出しエンジニアの皆さんに、「自分と同じように頑張っている人間がいるんだ」というささやかな心の支えや学びの共有ができればと思います！ 最後に、、、 じゃんけんゲームを完成させることができたあの頃の自分は、次なる開発でまた絶望することをまだ知らないようです、、、 この話はまたの別の記事でできればと思います。 お楽しみに。  

こんにちは。クルーズ株式会社の鈴木です。 今回はジョブ管理サーバとしてRundeckの導入を検討している話です 経緯 主な経緯としては ⓵cronでやっているジョブスケジューリングの外出し ②ジョブの実行状況の可視化 ③ジョブ失敗時の リカバリ 処理の効率化 です。 現状cronでジョブ管理しているのですが、各サーバごとに時間でキックしている状況なので、各cronで実行している バッチ処理 の実行時間の把握が困難であったり、何かの拍子で処理が失敗したりした際に関連するバッチすべてターミナル上から一つずつ手動 リカバリ を行う状態だったため、何かしらのジョブ管理ツールの導入で運用の効率化が図れないかを考えていたところ、要件を満たせそうなツールとしてRundeckがあったため検証を行っています。 運用する際に想定する要件 ⓵ジョブ実行NodeはEC2上のバッチ インスタンス で SSH 接続でジョブ実行する。 ②接続用の SSH ユーザとバッチ実行時の SSH ユーザは異なる。 ③管理画面へのユーザ認証は LDAP 認証。 ④HA構成とする。(サービスではないためウォームスタンバイ可) 現状 ⓵～③部分の要件については検証済。 ④のHA構成をどう実現するかについて今調査をしているところです。 以下文献によると仕組みとしては用意されていてできるような記述になっています。 docs.rundeck.com ただ「Available in Rundeck Enterprise」となっていて、Rundeck Enterpriseという有償版のものがあるまではわかったのですが、提供元や価格まで調べられておらず、現在調べているところです。 まさに今絶賛検証中なので、情報をお持ちの方がおりましたら是非教えていただきたいです。

こんにちは。2021年4月にクルーズグループに入社した新卒のRYOBALです。 元々、自分自身がファッション系 ECサイト をよく利用しておりその中で自社サービスを知って、より多くの人にサービスを使ってもらいたいと思い入社し、現在、サーバサイドエンジニアとして主に社内管理ツールのシステム改修を行っております。 今回はクルーズグループに入社して約1年になりますが、入社時の3ヶ月間の開発研修についてお話ししたいと思います。 マーケティング 希望だった僕が開発未経験からのスタートで様々な格闘をしながら研修をしていたので、開発未経験・経験者の方どちらもお楽しみできる内容だと思います。 開発未経験の新卒が開発研修。わからないことだらけの毎日。 クルーズグループでは開発の知識を身につけようと入社前から SQL や 基本情報技術者試験 の勉強を行います。入社後の4月以降は新卒メンバーの適性を見て、今年は7名が開発部署に配属されました。7名中6名が開発全くの未経験からのスタートだったので、新卒自身も「まさか自分が開発部署に配属されると思わなかった」と困惑気味。。 入社前から開発に関する研修を行っていたとはいえ、実際に入社してからはわからないことだらけの連続でここからは怒涛の開発研修のスタート。また、開発までの習得目標は下記の内容で、これを実際の アプリ開発 などを行いながら習得していく流れで進んで行きました。 ① 基本情報処理 技術者模試午前（8割正答） ② Linux 操作（基本操作コマンドの習得、Shell スクリプト 作成） ③GIt Bash （鍵作成、CLONE、PULL、PUSH、コンフリクト解消） ④ PHP 言語（クラス実装まで） ⑦ SQL （自社サイトでのデータ抽出）   基本情報技術者試験 の学習と毎日のテスト 4月に入社以降、最初の研修内容は 基本情報技術者試験 の学習と過去問のテスト。 エンジニアの方であればこの試験のことをご存知かと思いますが、簡単に言うとITエンジニアが共通して理解しておくべき基本的な知識を体系的に学習することができる資格です。その中でも午前問題と午後問題に分かれており、午前問題をまずは学習。学習することで、コンピュータやシステムが動作する仕組みからデータベース、ネットワークなどエンジニアとして必要だよね。という知識を頭に入れておこうという目的です。 「たかが普通の資格の勉強でしょ」 と思う方もいるかもしれませんが、これがなかなか大変。。 というのも、基本技術者試験の午前問題の全体の8割程の点数を3回連続で取れるまでは研修期間中毎日過去問を解いてテストを行うのです。資格の合格ラインは約6割と言われているので、そのさらに上に行くというなかなかハードすぎた内容。 そもそもPCや スマートフォン は毎日触っているけど、コンピューターの内部とはなんてこれまで知ろうともしなかったので「CPUって何それ」「ロール フォワ ードとか聞いたこともない」みたいな状態からのスタートでした。初めて過去問を解いたときは全体の3割も解けず、いきなり心が折れかけたのを覚えています(笑) 最初の1週間は全体の大体3割、たまに4割の点数を取ることしかできず。。。 苦しかった。。。。（笑）   ですが、毎日やっていくと自分の中で、得意な範囲と苦手な範囲がわかってくるので重点的に学習する内容も次第にわかっていきます。 苦戦しながらも徐々に点数が伸びていき、1ヶ月半後くらいには全メンバーが6割の点数を3回連続取ることができていました！ 振り返ってみると毎日毎日大変でしたが、1ヶ月半で基本的なITの知識が身についたと感じるので、非常に充実した時間でした。 この知識は配属後、エンジニアとしてやっていく上で基礎となる必要な知識で、SHサービスを支える上でもサーバーやDBなどの知識は役立ちます。これはエンジニアに限らず、営業や マーケティング 系の部署で働く場合でも「知っておくだけでサービスの見え方が変わるな」と思った研修の一つでした！ 苦戦しながら開発したブログサイト 基本情報技術者試験 の学習と並行しながら、 シェルスクリプト を使ってファイルの作成などコマンドを使って基礎的な学習や PHP を使ってジャンケンゲームや問い合わせフォームなどの開発をしました。 また、実際に書いたコードはGitLabと呼ばれるバージョン管理ツールを使って上司に確認してもらうなど実際に開発の現場で使われているツールを使いながら日々学んでいきました。 そのような学習を約1ヶ月間行い、いよいよ本格的な アプリ開発 としてブログサイトの開発へ。 PHP やBootstrapを使っての開発です。機能としては会員登録やログイン、記事の投稿、記事に対する返信の投稿、編集機能などが盛り沢山。 また、開発を進めるにあたって、依頼者にあたる上司に実際にどんなサイトを開発したいのかを ヒアリ ングし、求められた要求に対し、実装の内容や納期も考えるという実際にエンジニアの業務を行なっていく上で必要となる流れを経験することができました。 実際に依頼者に ヒアリ ングをしている時には「依頼者が何を求めているか考えて発言してる？」「提案ベースで話して」などとコミュニケーションを取る上で必要なことが足りていないと指摘を受けたことも。。 エンジニアの仕事はただ言われたことを開発するだけではないと身に染みて実感した瞬間でした。 要求を聞き、 ヒアリ ングした後は実際に要件定義書を作成し、画面設計、データ設計、URL設計、ER図の作成など開発を実現するために上流工程の部分を行い、上流工程を終えると次は開発やテストなど 下流 工程に着手します。 実際にコードを書いていきながら、必要な機能を一つ一つ実装させていき完成に近づけていく。 開発を進めていく上で最も大変だと感じたのは納期を見据えながら開発をしていく難しさです。開発前から納期日を逆算し開発の予定を決めていましたが、実際はそんなにスムーズに開発が進んでいくものではありません。 ブログのログイン機能や記事の編集機能の実装にエラーが出て、ググってもなかなか上手く動かない。予定よりもどんどん遅れが生じて、納期が迫ってくる。。 今思えば、そもそも納期の見積もりが甘かったり、実装の調べ方も全然できていないなど原因は様々ありますが「開発の現場ってこんなに大変なんだな」と実感したことを今でも覚えています。 実際の現場では見積もり時に想定していなかったような問題にたびたび直面します。その時のためにも「このくらいであればタスクが終わるだろう」と楽観的に見積もりをするのではなく、バッファを持たせた場合も考えて見積もりをすることが大事です。 試行錯誤しながらも無事にブログサイトが完成し、入社して約2ヶ月足らずで自分一人の力で「ブログサイトを開発するなんて凄い(笑)」と我ながら思い、自信にもなりました。　 チームで取り組んだ ECサイト 開発 ブログ機能が完成した次は4人チームで書籍の ECサイト の開発です。初めてのチーム開発で、個人で開発するよりも楽しく難しさもありました。開発の流れは前回同様、依頼者への ヒアリ ング、要件定義書の作成、開発・テストへの流れで進めていきます。 個人開発とは違い、メンバー同士でチャットで密にコミュニケーションをとりながらタスクを行なっていく必要があります。 例えば、 ソースコード にコメントの記載がなく何の処理をしているのかわからない、Gitでのコンフリクトが起きているのにもかかわらず解消せずに開発を進めてしまうといったような問題が起きてしまう。。 これらの問題は個人開発であれば起きませんが、チーム開発をする上では起こりうる問題です。 一方で、メンバー同士でコードレビューをすることで自分とは違ったロジックを使って実装をしているところを見て参考にするなどチーム開発でしか学べないこともたくさんありました。チーム開発を経験したことで、配属後の業務にもスムーズに合流することができたといったようなメリットもあり、研修時代にチーム開発に取り組めるのは非常に良かったと感じています。 また、弊社はファッション通販サイトを開発しているので、同じEC開発をこの時に経験できたこともその後に役立ちました。ログインした後のUIはどうするのか、商品の注文ボタンを押してからの流れはどうなるのか、実際のサイト上と比較しながらDB設計を自分たちで考え、開発を進めていきました。 ECサイト って一般ユーザーからすると「商品を選択→注文」といったようにシンプルに見えますが、実際はいろいろな機能が入っていてかなり複雑。。そのようなこともこの期間に知ることができたのは良い経験だったと思います。   まとめ この開発研修を実際に経験できたのはこれから仕事をする上で、非常に役立つ内容だったなと感じています。今回お話しした内容はあくまで一部で細かなところを話すと他にもいろいろな学習や開発を経験してきました。期間は3ヶ月弱でしたが、その時間は非常に密な時間で学びがたくさんありました。IT企業として開発サイド・ビジネスサイド問わず、ITに関する知識があればコミュニケーションをスムーズに取ることができ、業務にも活かせると実感しました。 今後もエンジニアとして経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。それでは、また次回のブログで。BYE☆

こんにちは。2021年4月に新卒入社した「 KEN☆YAMAGUCHI 」です。 現在、開発部に所属しておりサーバーサイドエンジニアとして、主にサイト内の販促プロモーションの機能開発をしています。 今回は、私が開発未経験でエンジニアになって感じたことや、実際の開発研修内容についてお話しさせていただければと思います。 少し長いですが、最後まで読んでいただければ嬉しいです。 総合職採用なのにまさかのエンジニアに、、、 まず、私は総合職採用でクルーズグループに入社しました。当然内定をもらった時に エンジニアになることなんて1ミリも考えずにいました 。 内定者は、入社前研修で SQL や 基本情報技術者試験 の勉強を行いますが、ITの知識をつけることを目的としているだけだと考えていました。 しかし、入社前研修期間中のある日、「13名いる新卒メンバーの適性を見て、そのうちの約半数を開発部署に配属とする」と告げられました。選ばれたメンバー7名は４月には配属されず追加で開発研修を行いました。 私もそのメンバーに選ばれ、エンジニアとして社会人生活をスタートすることになります。 開発の経験などもってのほか、全くITの知識すらない自分がエンジニアとなる姿は想像もつきませんでしたし、エンジニアリングに興味もなかったので不安でいっぱいでした 。 ここから怒涛の研修がスタートします、、、。 新卒を未経験でも開発部配属する理由とは 2018年～2020年までの間、新卒の開発研修は行っておらず全員開発部以外の職種に配属なっておりました。 そんな中、 ITの知識だけでなく実際にエンジニアとして働くことで、開発部以外の部署に転向した後も、開発側とのコミュニケーションを円滑に進める ことができ、それが会社にとって有益であるとして新卒未経験でも開発部に配属することが決定されました。 開発部に配属されたからと言ってずっとエンジニアとして働かなければならないわけではなく、新卒社員の育成の一環であり、 それぞれの自らが描くキャリアを最優先に考えてくれます 。 新卒未経験エンジニアを育成する研修内容がハードすぎた さて、ここからは先述した開発研修についてお話したいと思います。 開発研修は大きく下記3点に分かれていました。 ① 基本情報技術者試験 の勉強（午前問題の正答率8割がボーダー） ② SQL 研修（サイト内のデータ抽出作業） ③ PHP 研修（じゃんけんゲーム作成・ブログサイト作成・簡単な ECサイト 作成） 基本情報技術者試験 の勉強はいわば座学のようなもので、 SQL 研修・ PHP 研修は実技のような感覚でした。 ① 基本情報技術者試験 の勉強 基本情報技術者試験 とは、その名前の通り、主に プログラマー ・ システムエンジニア などのIT職に従事する人、あるいはこれから従事しようとする人達を対象とした試験です。試験では「IT業界で働くために必要な基本的知識を持っているか、情報処理に必要な論理的な考え方はできるか」などを試される問題が出題されます。また経営やマネジメントについてもある程度の知識が問われます。そのため試験勉強を通して全般的なIT力の向上が望めるものです。 試験の合格基準は正答6割ですが、 成果指標は正答率8割 と厳しい設定がなされていました。そもそも3割にも満たない正答率でしたので、厳しすぎだろ！と怒り交じりの弱音を吐いていたのを覚えています(笑)。 弱音を吐き続けても仕方ないので、気持ちを切り替え、毎日過去問を解いては間違えたところの復習を繰り返す中で、苦手分野の洗い出す作業を行いました。苦手分野を潰しつつ得意分野の正答率を上げることを意識して勉強をし、何とか正答率8割のボーダーをクリアすることができました。 ② SQL 研修 この研修では私たちのサービスが抱える膨大なデータを使って様々なデータ抽出課題をこなしていきました。 ここでは主にデータ抽出を行いましたが、躓いた所は複数のテーブルの結合、サブクエリ、WITH句なを使用して抽出するクエリ作成です。 今エンジニアの方が見ていたら怒られてしまうかもしれないですが、内部結合と外部結合の違いをよく考えずに、適当にLEFT JOINで結合していた覚えがあります(笑)。ただここの使い分けは、複雑で長いクエリを作成するときは意識する必要があるため、今でも意識して行っています。 そしてWITH句についてですが、複雑なデータを取得する際に使用され、簡単に言えば、クエリの中にクエリを作ることです。実際サブクエリを使用するとかなり読みづらくなってしまます。 そこで使用するのが、WITH句です。WITH句を 使えば「クエリ内に新たにテーブルを作る」ことができます。サブクエリ自体もクエリの中にクエリを書くので、非常に似ているのですが、WITH句で書くとそのテーブル内で何度でも使い回すことができる点が大きく違います。 また一般的にWITH句はサブクエリと比較すると、可読性が高くなります。ただパフォーマンス観点等を考えると使い分けが必要ですが、、、 ③ PHP 研修 PHP 研修では先述したようにじゃんけんゲーム・ブログサイト作成・ ECサイト 作成を行いました。 正直メインであるこの研修が一番しんどかったです。（笑）もちろん ソースコード に触れたこともないわけですから、じゃんけんゲームを作ることに苦労しました。コンピュータがグーしか出さないとか、勝っているのに「負け」と判定されてしまったりと上げたらきりがないくらいエラーとの戦いでした。 まず最初に学んだことは、IF文でした(笑)。分岐処理はプログラミングの基本でもあると思いますが、そんな初歩的なところでも躓いていました、、、 そこから、foreachを使用して繰り返し処理を学んだりしました。ここで出てきた配列に関して一番難しかったところかもしれません。 連想配列 ともなると吐き気がしてきました、、、 そしてブログ作成や ECサイト の作成になると、ログイン機能実装や記事の作成・更新削除など、難易度は上がりました。やっとの思いで合格点をもらえる成果物を完成させることができました、、、 ここの研修はかなり内容が濃いのでここでは簡単に触れるだけにしたいと思います。 ただ、 Google先生 を人生で最も使用した期間だと自負しています(笑)。 開発研修を経験して ここまで読んでいただくと、開発部配属になった時の心境・実際の研修内容を分かっていただけたかと思います。 ここではそんな経験が どんな心境の変化をもたらせてくれたのか をお話ししようと思います。 今まで、 WEBサービス が裏でどんな仕組みで動いているのかなんて考えたこともなく、プログミングなんて難しくて到底自分にはできないと考えていました。 もし開発部配属にならなければ、その仕組を学ぶことや、プログラミングの経験をできなかったと思うので、非常に貴重な経験をさせてもらえていると思っています。 この経験はいつかエンジニア以外のどの職種でも絶対に活きてくるものだと確信 しています。 次はそんな経験をした自分が考える、未経験でエンジニアを目指す際にどんな会社選びをしたらいいのか、について生意気ながらお話ししたいと思います。 未経験でエンジニアを目指すならどんな会社を選ぶべきか 今この記事を読んでくださる人の中にはエンジニアの世界に足を踏み入れようとしている方もいるかもしれないので少しこのテーマについても触れておきたいと思います。 まだ、エンジニアになって1年も経ってない自分が口にするのは大変恐縮ですが、自社開発を行う会社でエンジニアとしてスタートすることをお勧めします。 理由としては、以下3点です。 ①保守性の高いコードを書く機会が得られやすい ②エンドユーザーが見えやすい ③様々な部門との連携が必要 ①保守性の高いコードを書く機会が得られやすい 自社開発の企業は、成果物を納品して終わりの企業とは違い、ずっと同じサービスを開発します。そのため、拡張性、保守性の高いコードを書く必要を常に意識しなければなりません。ここは肌で感じている部分であり、コードレビューでよく指摘していただけます。 ②エンドユーザーが見えやすい 自社開発のエンジニアは、納品して終わりではなく、実際にそのサービスを利用したユーザーからのフィードバックをもとに、開発を進めます。自分が開発した機能が、しっかりと使われていることが分かるので、非常にやりがいを感じやすいと思います。 ③様々な部門との連携が必要 ここは一見デメリットのように捉えられがちですが、開発だけしかできないエンジニアより、ビジネス的な観点も持っているエンジニアの方が市場価値的に高いと思うからです。 まとめ エンジニアの世界とは無縁だと考えていた自分が、今ではエンジニアとして（何とか）働けています 。 開発研修はかなり濃いので、別の機会にお話しできたらと思います。 改めて、 ITスキルはとても重要であり幅広い分野で求められているスキル なので、エンジニアとして経験を積ませてもらえていることにとても感謝しています。 まだまだ未熟なエンジニアなので、日々精進します。 そして自分の成長もこのブログを通して感じてもらえたら嬉しく思います 。 そしてこの記事が少しでもお役に立てればと思いますので、今後もお楽しみにしてください。 それでは次回のブログでお会いしましょう！

こんにちは。クルーズ株式会社CTOの鈴木です。 以前の投稿で「 AWS Auto Scaling によるインスタンス管理に切り替えた話 」をしましたが、今回はもう一歩踏み込んで、時間帯や負荷見合いで インスタンス 台数を変動させ、その変動分の インスタンス をスポット インスタンス を使うことでトータルでインフラコストをもっと下げられないかを検討した際の話をしたいと思います。 SHOPLISTで採用している AWS の各種 インスタンス の購入方法 SHOPLISTでは現在主に以下の３パターンの インスタンス の買い方をしています １．Compute Savings Plans ・現在主に利用している契約。 ・主にEC2の購入で年数回に分けて購入。 ・計上は前払費用として資産化し、それを毎月に分けて償却。 ２．コンバーティブルRI契約（全額前払/前払無し） ・Savings Plansができる前に契約していたEC2に適応していた契約。 ・現在は主にElastiCacheの契約として利用。 ・ インスタンス の世代の発表を予測し1年で買うか3年で買うかを判断。 ・計上は前払費用として資産化し、それを毎月に分けて償却。 ３．オンデマンド契約 ・Savings Plans 更新時に将来的に削減が見込まれるのでその契約から外れた インスタンス 分。 ・季節需要やセール需要で一時的にしか稼働しない変動 インスタンス 分。   今回は「 季節需要やセール需要で一時的にしか稼働しない変動 インスタンス 分 」について、本当に必要な需要量をもっと突き詰めて考えると需要のある時間外が限定されるので、ここの部分を スポット インスタンス を利用することで AWS のコストを落とせないかを検討しました。 今回実施したコスト削減のシナリオ 基本的には下記３つを組み合わせてコストを下げるシナリオを立てて進めました。 ①需要量によって変動分のサーバの運転時間を時間単位で減らすことによって運転時間を減らす。 ②変動分のサーバのタイプ、時間当たりの単価の安いをオンデマンドからスポット インスタンス にすることで、時間当たりの単価を落とす。 ③Web インスタンス をオンデマンドおよびスポット契約ともに、 AMD インスタンス をさいようすることで、サーバ単価自体を落とす。   スポット インスタンス は、 AWS もWebページでアナウンスがあるとおり、 AWS クラウド 内のEC2の余剰キャパシティを使うことにより、オンデマンド契約の料金として比較して最大で90%の割引を受けられる契約です。 一方、余剰キャパシティを利用している分、空きキャパシティが不足した場合、新規受付が中断されたり、最悪の場合稼働中のスポット インスタンス が中断され、回収され稼働台数が減るリスクがあります。 一応仕様上2分前に通知が来るようですが、現状2分で新規 インスタンス の起動完了は難しく余剰台数を増やすことで回避する設計をしました。   例えば、今まで6台のCompute Savings Plansで動いていたサーバで、うち3台が24時間稼働、残り3台がピーク時間帯のみ運転する仕様の場合、以下のような台数構成で構築をしました 　・Compute Savings Plans  　　　　　　　　　　　　　　…　３台 　・オンデマンド インスタンス （ピーク時間帯のみ稼働）　…　２台 　・スポット インスタンス （ピーク時間帯のみ稼働）　　　…　２台   変動分全台をスポット インスタンス にするよりは削減効果は少ないものの、そもそも稼働していない分のコスト削減ができるので今よりコストが下がるのと、そもそもWeb インスタンス 全体を AMD インスタンス を利用することで微々たるものですがコストダウンを図ります。 結論 Auto Scalingの対象 インスタンス で見ると、今までのCompute Savings Plansのみの場合と比較して約2割～3割の削減が実現できました。 2割～3割としているのは、そもそも今まで手動で増強/縮退運転をしていたにしても季節変動やセール影響での台数変動はあり、単純に前月比や前年同月比で削減効果を比較できないためですが、確実にコストの削減はできています。   今後の課題 現状Web、画像周りについてはAuto ScalingやManaged Service を使うことでコストの削減が着実に進んできているのですが、一方でDB インスタンス は柔軟にスケーリング運用できておらず、かつ元々の インスタンス サイズが大きいためコストの削減が一向にできていない状況となっており、コスト上の今後の大きな課題はDB インスタンス の費用を以下に減らすかにあります。 こちらはDB インスタンス 側でどうこうするというよりも、まずはプログラムの作りを見直し、DBのスレーブサーバ台数を減らすことがもっともう効果的だと考えており、プログラムの見直しにより削減を進めたいと考えています。  

こんにちは。クルーズ株式会社、社長特命執行部執行責任者の松島です。 社長特命執行部って なんでも屋 なのでなんでもするんです。仕事の範囲はボーダレス。 今回自分からは当社が運営しているファッション ECサイト 『SHOPLIST.com by CROOZ』にて自分がオーナーとして取り組ませてもらっているプロジェクト、 「本当に必要な実装の時間を確保するために、無駄な デバッグ 時間を削減」 の話の 第2回目 をお話ししていきたいと思います。 ◆結論、Autifyだけでは開発+運用には耐えられなかった 補足しますが、 Autifyだけで開発＋運用に耐えられなかったのはSHOPLISTの開発方式や開発手法等諸々の影響によるところが大きい と考えていますので、Autifyがサービスとしてどうこうという話は全く別物となります（ 自分個人としては非常に優秀なツールだと思っています ）。   なのに何故Autifyだけでは開発＋運用には耐えられなかったのかは後述します。   なお、この記事においては2021年10月時点でのAutify社の仕様を前提とした話となっています。Autify自体が非エンジニアでも使えるツールであるため、 非エンジニアの方も小難しい話がでてきたな？と思わず、 見て頂ければ幸いです 。 ◆Autify導入の経緯 導入の理由ですが、自分が2021年10月時点で各種UI自動テストツールを見て回った中で一番シンプルでかつ必要な汎用性を保持していたためというシンプルなものです。   この デバッグ 時間の削減の話が出てきた際に会社としては元々全環境を1つのツールでテストを実施できたほうが楽だろうという事で某クライアント型ツールを導入しようとしていて、実際に検証もすすめていました（弊社CTOの鈴木が進めていました）。   ですが、某クライアント型ツールは自分が研修に参加した事で非エンジニアには習得が不可能と判断、最終的にはAutifyの導入に切り替えました。   単純に会社としては ・「 GUI 」 ・「昔から長く使われていて」 ・「全プラットフォーム対応可能」 というツールスペックから非エンジニアでも使えるだろうと導入を進めていたのですが、   実際には ・「ツール固有仕様が多い」 ・「エンジニア経験が無ければツールとしてのパフォーマンスが発揮できない」 という部分が強すぎたため、某クライアント型ツールは非エンジニアには使えないと判断。   当時10数個のツールを検証した結果、Autifyが目的と合致したため導入したというのが経緯になります。 ◆Autifyと某クライアント型ツールの比較 松島個人の解釈が多く含まれますが、以下のような差があります   ◆Autify 〇自分は1日でシナリオ作成から簡単なテストの定期実行までできた 〇 GUI で Chrome 拡張機能 を使う必要があるが利用が簡単 〇専門用語が少ないというかメインとなるUIがそもそも少ない ×ヘッドレスブラウザで動作するのを前提としているためリプレイが無い 　 ※これはシナリオ作成のところで疑似リプレイみたいな使い方ができる ×ツール自体は非常に簡単だが管理側の整備が追い付いてない為、 　運用ルールを敷くことが超大事 　※シナリオ管理周りがかなり粗いため、 　　大規模サービスであれやこれやと大量のテストボリュームがあることを 　　実施するには向かない   ◆某クライアント型テストツール ×レクチャーに参加したが1日ではテストシナリオを完成させることができず 　 定期実行のやり方等は全く分からないという状態だった △ GUI はクライアントの専用ツールで使いこなせば細かい厳密な対応ができる ×専門用語が多すぎる、操作UIも複雑 〇リプレイは何回でもリプレイ機能の利用が可能 〇このツール専門の職人のような領域になるとDB連携したりかなり高機能 〇大規模サービスであまり変更が定常的にかからない事を実施するのに向いている 　※シナリオ作成コストが高い為この判断 厳密にできたり、使いこなすことでパフォーマンスが高いのはあくまで某クライアント型テストツールだと思いましたが、今回は会社の方針も非エンジニアが扱えるという事からAutifyを選択しました。 エンジニアチームで昨日の全ても使い倒して扱っていくツールを選定するという前提で判断するという話だった場合はまた別の選択をしたかもしれません。 ◆Autifyだけでは開発+運用には耐えられなかった理由 ここはAutify社の仕様によるところになりますし、カンファレンスに参加されている方なら一度は聞いたであろう話です。 ・Autifyには月の実行回数に応じた課金があった この課金体系が原因で開発＋運用にはとても耐えられないものでした。   ・デフォルトの月の実行回数は1,000回です(契約にもよる)。 ・1,000回だと30日x30シナリオを実行しただけで900回消費してしまう ・シナリオ作成後の自動実行テストを試せるのは100回/月しか残らない   さらに ・環境が変わるごとに1回の実行回数を消費してしまう 　※ Chrome ,Edge, Safari の3つのブラウザで実行するとシナリオ1つにつき3回かかる ・PCとSPで別のシナリオを使うため環境でさらにシナリオ1つにつき2回かかる   上記を整理すると ・1つのシナリオを3つのブラウザで、PC,SPそれぞれで毎日10回実行すると ・3(ブラウザ)x2(PC,SP)x10回x30日=1,800   一応この1,000回という実行回数は契約上回数追加が可能なのですが、上記の回数の増加式からすると100回や200回増えたところで 焼け石に水 です。 エンジニアからすれば、開発中は環境で変更をしたら ・自動で全チェックしたい ・全チェックして問題があったら修正→再度全チェックしたい というような事が成立するのが理想的です。   1日1人エンジニアが開発中に10回ぐらい上記の全チェックをぶん回していた場合 ・3(ブラウザ)x2(PC,SP)x10(回)=600回 ・600(回)x10(回開発実行)x30(日)=180,000回 上記のように非現実的な数字になりましたね。 シンプルにAutifyだけでは開発運用に耐えられなかったのは、回数制限制約が厳しいという事につきます。   おそらく運用している企業では工夫をして扱っていると思うのですが、回数が厳密すぎてその工夫をすることでまた開発の管理コストを圧迫しそうだなという事で、すべてをAutifyでやるのはやめよう！という判断に至りました。 ◆次回は… 今回は意図せず Autifyを導入しようとしたけれど解決しなかったよ という話をしただけになってしまいました。   自分個人としてはAutify自体は非常に優秀なツールだと思っています。 そのため次回は Autifyの有効活用の仕方、活用ポイント についてお話しようと思います。是非、エンジニアの方にも非エンジニアの方にも役立てていただければと思います。

初めましてクルーズ株式会社、社長特命執行部執行責任者の松島です。 CROOZに2012年入社後、諸々紆余曲折ありまして、現在は本社で技術上がりの なんでも屋 をしています。   今回自分からは当社が運営しているファッション ECサイト 『SHOPLIST.com by CROOZ』にて自分がオーナーとして取り組ませてもらっているプロジェクト、 「本当に必要な実装の時間を確保するために、無駄な デバッグ 時間を削減」 の話をしていきたいと思います。 ◆先に結論を書いてしまうと… 今現在SHOPLISTでは 某クライアント型テストツール、Autify、nodejs、puppeteerを使用して デバッグ 時間を削減する取り組みを実施 しています。絶賛取り組み中です。 今現在絶賛取り組み中のため対応が完了したところまではお話できないのですが、それぞれをどんな意図と経緯で使うことになったのか？導入をしてみてどうだったのか？等を一通りお話しできる範囲で話せればと考えています。   なお、この記事においては非エンジニアに向けての内容も多く含まれるものとなるため、 特に非エンジニア職の人にも見て頂ければ幸いです。 ◆本当に必要な実装時間って何？ 「本当に必要な実装の時間」とはつまり「新しい開発や既存の改善」を行う時間 です。   ECサイト であるSHOPLISTの開発業務には大きく以下の2つの業務があります。 【業務１】日々の運用業務 【業務２】新しい開発や既存の改善   上記の２つの業務のうち 「【業務１】日々の運用業務」に大きく時間を割かれ… 「【業務２】新しい開発や既存の改善」にも大きく時間を割かれ… 結果として時間が足らなくなり 「開発のスピードが超鈍化」 するという問題が発生 していました。   この 「開発のスピードが超鈍化」 問題を改善す るために 「本当に必要な実装の時間を確保するために、無駄な デバッグ 時間を削減」 するというのが今回の趣旨です。 なお、最初に話が降ってわいたこの時の自分の感想としては「なんでそんなに デバッグ に時間かかってるの？」という疑問符しかないところからのスタートでした。 ◆開発の速度を加速するための2,500時間 ではまず、「無駄な デバッグ 時間」とはどれぐらいあったのか？でいうと、まずプロジェクトスタート当初の集計ではSHOPLISTの デバッグ 時間は開発部全体で2,500時間/月が発生していました。 ・1人1月の稼働時間が160時間(8時間x20日) ・2,500時間/月は人数に直すと約15人/月分 これは会社としては大きなコストとなりますし、さらにエンジニアでしか対応ができない内容となっていた場合非常に不毛な2,500時間の稼働になります。 正直2,500時間も無駄な事やってるぐらいなら他の事したい！って思いますよね。   シンプルに言ってしまえば15人月分のコストを デバッグ の時間として使わず、さらに追加開発ができるなら、 ・【メリット１】サービスとしてユーザーに対して改善できる ・【メリット２】開発として開発体制に対して改善できる ・【メリット３】会社として新たなビジネスへの挑戦ができる 当然ですが2,500時間の デバッグ 時間を他に使えるようにすれば、「本当に必要な実装時間」に変えられることができればメリットは数えきれないほどあります。 ◆ デバッグ 時間を削減するためにする事 デバッグ 時間を削減するには単純な話、如何に手作業を減らすか？という点につきますが、解決方法としては単純に３つです。 ・解決策１．そもそも デバッグ がいらないようにする ・解決策２．自動でエラー検知されて常に自動で デバッグ されるようにする ・解決策３．手作業で デバッグ していたものを自動で デバッグ されるようにする 当たり前の話ですが、究極目指すべきは解決策１のみです。 解決策１だけだと当然サービスが回らないので解決策２が必要となります。 解決策２までやっても新規開発等の際の デバッグ は常に発生するため解決策３となります。 ◆次回は… 今回は主に デバッグ で話す話の全体像、課題、課題解決時のメリット、解決策、を一旦お話させてもらいました 。 自分（松島）がディレクター、プランナー、フロントエンドエンジニア、サーバーエンジニア、アプリエンジニアと 様々な経験を持つ異色の経歴のため、一般的な解決策と異なり職種をまたがった解決策 を次回以降お話できればと思います。   具体的に解決策が分からないと意味ねーじゃんと思うこともありそうですが、各課題の解決への筋道が思いのほか長く面倒だったため、細かく書くために複数回に分けさせてください。   次回は Autifyの導入関係 についてお話していく予定です。  

こんにちは。クルーズ株式会社CTOの鈴木です。 今回はFlutter の検証を始めましたという話です。もちろんSHOPLIST.com by CROOZのアプリをリプレイスすることが目的での検証です。決して趣味の話じゃないです(笑) 背景 実はSHOPLISTのインフラ構成を変える構想を今考えています。要点でいうと ・MVＣ アーキテクチャ 、特にテンプレートエンジンの利用をやめる ・サーバは API の結果のみを返し、その API はブラウザ、アプリ共通とする。 ・ブラウザの場合はフロントエンド フレームワーク がHTMLを組み立てブラウザに返す。 ・ネイティブは iOS / Android を統一言語で実装して開発生産性を上げる。 今回はこの最後の iOS / Android の実装言語統一の話です。 言語統一の目的については以前の投稿であげた「 SHOPLIST.com のシステムをモダンなアーキテクチャに変えようとしたら予想以上に闇が深かった話 」の課題の部分でもあげた iOS の場合SwiftとObject-C、 Android の場合 Java とKotlinが機能毎に混在して開発していることと、 アプリ開発 の社内の技術スタックをFlutterに統一することで アプリ開発 の生産性を上げることです。 まず、 iOS の場合SwiftとObject-C、 Android の場合 Java とKotlinが機能毎に混在していることについて、実はそこまで顕在化した課題というのはないです。もちろん多少は非効率な部分はあるのですが、新規実装はSwift、Kotlinで行い、既存部分の改修の時に直せるものは書き直す、そうでないものはObject-Cと Java で書くということができる状況で iOS のエンジニアであれば両言語対応できたため生産性が低くなっているというわけではないです。 潜在的 なリスクとしてはObject-Cや Java の実装をこのまま続けていると、どこかのタイミングで Apple や Google にリリース申請した際に、そのリリース申請が通らないんじゃないかという漠然としたリスクがあることです。このように現在そこまで非生産的な状況でないことと、リスクとしてはかなり抽象的だったため、 レガシーシステム を脱却することとして2020年中に行う事柄には含めなかったのですが、今回は対応を検討することにしました。 もう一つの理由の社内の技術スタックの統合の話です。 こちらの方がやる意義としては重要だと考えています。今当社のネイティブエンジニアは主に iOS を担当する人、 Android を担当する人に分かれていて個別のラインで開発を行っています。また過去の経緯で内部的な設計も異なっている箇所があり、ちょっと古いたとえにはなってしまうのですがXamarinのような クロスプラットフォーム 言語で開発するようにしてしまった方がアプリ製造にかかわるトータル 工数 が削減できるのではと考えました。またこれを機に各OSごと2言語で開発している状況もなくせれば一石二鳥なので クロスプラットフォーム 言語の検証を始めたというのが今回の背景です。 Flutterを検討するに至った背景 前提として、社内にFlutter経験者がいない中での検証スタートであるため、まずはネット文献で調査し、そのあと実際に1～2カ月ほど特定機能を実装して導入の意思決定をするという形で計画しました。 まず以下の記事のようにすでに比較をされている方の情報を複数集め、Flutter、React Nativeの2つにまで候補をしぼりました。 qiita.com その後、文献を見ながら トライアンドエラー を繰り返して進めていく形で検証を進めていく形となるため、文献の量を調査しました。調べ方としては極めてシンプルで Google トレンドでの検索状況で比較しています。   Google トレンド 上記のように、ここ1年で見ると圧倒的にFlutterのほうが情報量が多いです。 もう一つの側面としてはReact Nativeの開発元である Facebook とコミュニティのライセンスについても純粋な BSDライセンス ではなく、独自に BSDライセンス に特許条項が付帯されており、営利目的のサービスを運営するにあたりリスクとなりうる内容を含んでいるように見受けられたため、今回はFlutterを検証の対象としました。 FaceBook コミュニティの独自のライセンスの話はこのサイトに詳しく解説があります。 検証の進めかた 繰り返しですが社内にFlutter経験者がいないため、ネット文献で調査し、そのあと実際に1～2カ月ほど特定機能を実装して課題の有無を評価していくという形で検証を進めています。 具体的な評価の項目としては ・現在使用している SDK やライブラリで利用できないものはないか？ ・実装していて生産性が悪くなる要素はないか？ ・実装をしていて機能的に実現ができないなど、制約になることは無いか？ ・アプリでの動作でレスポンスやCPU使用率など劣化する部分はないか？ の大きく4項目を比較していく形で進めています。   現在検証を始めて約１カ月経ちますが、今の時点で分かっていることとしては ・ SDK で動かないものはないが、1つだけFlutterから使うと実装が複雑になるものがある。但し SDK 提供元より対応バージョンの提供が受けれる。 ・パフォーマンス上今のアプリとさほど変わらない。 ・実装については学習コストは当然必要だけどそれ以外で生産性が著しく落ちるものはない という評価です。 あと2週間ほどで検証対象の特定機能の実装が完了するので、その完了を待って最終的には導入の意思決定を行いたいと思っています。  

こんにちは。クルーズ株式会社CTOの鈴木です。 今回はFastlyCDNのImage Optimizerを使ってSHOPLIST.comをWebP対応させた話をしたいと思います。 www.fastly.com 背景 背景としては主に二つで、一つ目は画像フォーマットをWebPに対応させることにより通信の トラフィック 量を減らすこと、二つ目はEC2 インスタンス 上にNginxとsmall_lightで構築されているサムネイル生成処理をImage Optimizerに代行させることで、EC2 インスタンス 上の変換処理プログラムや ミドルウェア の保守をなくすことです。 前者については、実は1年前から気にはなっていた技術要素だったのですが、当時はまだ iOS 版のサファリが未対応であったため、まだ導入先でいいよねという判断をしていたのですが、2020年の9月に iOS 版サファリもWebP対応することが発表され、いよいよ導入時期に達したということで今回導入に踏み切りました。当時、「Can I Use?」 で調べたところ、Usage としては85%ほどでした。   後者については副次的なものではあるものの、中身が ブラックボックス 化してきているうえ、 コアコンピタンス の思想でいえば積極的にアウトソースするものだと考えその両方が実現できる仕組みとしてFastlyCDNのImage Optimizerに着目し導入に至りました。 基本的な仕組み 本来FastlyCDNのImage Optimizerの仕組みではHTTP HeaderのAccept-Encodingでリク エス ト元ブラウザがWebPに対応しているかどうかで画像を自動変更して返す仕組みがあり、設定をされた CDN を経由するだけでプログラム側では何もせずにWebP変換されたコンテンツを使うことが可能ですが、今回は以下の理由からImage Optimizerの機能ではなく、WebP対応とそうではないオリジナルの画像URLを出しわけるようにしています。 ① CSS 内のパーツの一部として画像を読んでいる箇所が多く、すべてを自動変換できない。 ②WebPの圧縮率を一律にすると商品画像が目に見て分かるレベルで劣化するケースがある。 とくに後者は悩まされました。特に見る人×ディスプレイの性能×商品素材の材質によって商品画像が汚く感じる画像があり複数商品カテゴリの商品画像を様々な世代の端末、社内の様々な年齢の人に見てもらい、アンケートを取った結果として、現実的に圧縮率一元は不可という結論になりました。 結論、ブラウザと商品画像の特性に応じ、オリジナル画像、WebP ロスレス 画像、WebP圧縮画像をサーバ側で出しわけてHTMLを生成する形を取り、その後リリースまでの間に同じように複数商品画像を社内の複数のユーザにいろいろな端末で確認して違和感のない状態になっていることを確認して、その後リリースとなりました。 まとめ まず トラフィック 量についてはざっくりですが3割ほどの削減となりました。ただ、これは月変動があるのでもう少し期間を見て改めてどこかで共有できればと思います。 またブラウザや端末シェアの変更により今後は対応ブラウザが増えるため トラフィック 量については何もしなくてもある程度は下がっていくことが見込まれそれも含めまたどこかで共有できればと思っています。 ※ネイティブアプリについては両OSとも対応済です。 副次的な目的だったEC2 インスタンス 上で行っている独自のサムネイル作成処理については停止できたものの、それ以外の画像関連の処理がまだ動いており、完全停止には至っていないいないため完全に停止まではいかなかったですが、処理の大部分をFastry上に持って行けたことによってサーバリソースが大幅に落とせたため インスタンス 台数やサイズを落とせてコスト上は抑えることはできました。残りの処理の書き換えについては リファクタリング として実施していきたいと考えています。

こんにちは。クルーズ株式会社CTOの鈴木です。 前回の投稿「 WebインスタンスのOS/PHPバージョンを最新安定版にあげた話 」の最後で少し触れましたが、今回Webおよびバッチ インスタンス については各セール開催の都度、いちいち手動でEC2 インスタンス を作成しなければならず、急にサーバを増やす際に、EC2のイメージを元に インスタンス を作成し、 ソースコード 同期を行いバランサーに追加する作業が必要で非常に面倒でした。   そのため、Web インスタンス については、起動テンプレートの構築とEC2 Auto Scaling上での インスタンス 管理を行う方式に切り替えを行っています。 Auto Scaling導入の進め方 Auto Scalingの導入は目的ごとに大きく３つのフェーズに分けて進めていきました ① 既定の インスタンス 台数分を常に稼働できるようにすること 　⇒ 仕組みとしてのAuto Scalingの導入。 要するに必要台数のうち インスタンス 障害で1台死んでも、自動で1台がスケールアウトして、トータルで必要台数を確保できる状態を維持すること。   ② 負荷に応じて自動で増強/縮退運転できるようにすること 　⇒ 負荷対策/サービスダウン防止のための導入 要するに本来のAuto Scalingの機能を活用して、サービスダウンを防ぎ、機会損失を防ぐこと。   ③ 負荷＋時間に応じて自動で増強/縮退運転できるようにすること 　⇒ コスト最適化のための導入 要するに需要量に応じて運転制御をすることでコスト削減を行うこと。 実施する際に苦労したこと １． インスタンス ID、 IPアドレス が常に変わる問題 サービスとしてはAutoScalingは非常にうまくできているのですが、今までEC2で運用していたシステムをそのままAutoScalingで運用しようとすると、いろいろ運用面で苦労することがあります。 その一つが IPアドレス など、 インスタンス 情報がスケーリング実行都度に代わってしまう問題です。   いままで当社だと、 SSH でサーバにログインする際やZabbixなどの監視エージェントが監視サーバにログを送るときのホスト名はEC2 インスタンス 構築後に社内の 命名規則 に従い、 Linux のホスト名および社内 DNS ( Active directory ）上にAレコードとして登録し、その名前で SSH 接続を行ったり管理サーバにログ送信する運用をしていました。   今回Auto ScalingでEC2の運転を管理することによって、上記の運用ができなくなり、ホスト名で SSH 接続ができなくなる。監視システム上でどの インスタンス 化の把握が困難になるなどの問題あり、緊急時に問題が発生している インスタンス の特定が困難になるのではという懸念がありました。 根本の話だと、そもそも SSH でWeb インスタンス に都度接続する運用自体に問題があるのですが、一方でアクセス集中でWebプロセスが固まった際にkillするために SSH 接続を行う必要がありその際に接続先の特定に手間取るのはリスクであり対処として、踏み台サーバ上で aws ec2 describe-instancesコマンドを実行して、tagと インスタンス IDとプライベートIPを表示する シェルスクリプト を用意し、そのシェルで接続先IPを検索できるようにして踏み台サーバ上で接続先の インスタンス の IPアドレス を検索できるようにする仕組みを準備し運用に備えました。   ２．実環境上で実際のサーバ増強/縮退運転のテストを安全に行うのが結構手間な問題 これは結構地味に大変な話なのですが、 閾値 を調整して強制的にスケールアウト/スケールインできても、本当に負荷が都合よくかかってくれてスケールアウトしてくれることがあまり発生しない。 SHOPLISTほどの規模になると、テスト上問題なく動作しても簡単に本番導入させづらい。 という問題はあり、地味に苦労しました。 進め方としてはにはALBのTarget Group 毎にASGを準備しているので、負荷変動の少ないASGから順に導入し、 閾値 を調整してスケールアウト/スケールインが頻繁に発生するような状況を作り、1カ月ほど運用を行い、通知含み問題が無いことを確認してから負荷変動の大きいASGも導入していく形で進めていきました。   ３．Auto Scalingの SNS 通知が読みづらい問題 こちらも地味な話なんですが、 SNS の通知の内容が分かりづらく… というか、Auto Scalingに関係なく、監視目的で SNS 通知を使うとだいたい、内容が分かりづらく、経験則的に「あー、この通知だと多分こんなこと起こってるｗ」みたいな感じの対応をしています。 まあ、頑張ればカスタマイズできるのかもしれないのですが、優先度としては低い話なので今は静観しています。 実施してみて 導入を開始して約半年たっていますが、今のところ問題の発生はなく順調に動作しています。 また、今作成している「 AWS AutoScaling とEC2のスポット インスタンス を組み合わせてWebサーバのコスト削減した話」でも触れますが、変動分の インスタンス の起動時間が短ければ変動分の インスタンス をスポット インスタンス で構成すればWeb インスタンス のコストとしては約2～3割ほどは実績としては減っておりコスト面でのメリットはありました。(当社の場合Compute Savings Plans で全額前払および一部前払で購入しているため、コストの削減効果としては導入直後にすぐは出ず、契約更新時となりました。) 今後 AWS Auto Scalingを導入する方へのアド バイス AWS Auto Scalingは素晴らしい仕組みではあるものの、当社のようにオンプレから仮想サーバに移行する形で クラウド 化したシステム（簡単に言うと仮想サーバとしてEC2を使って クラウド 移行を行っているシステム）の場合、インフラの運用設計や監視設計が インスタンス 名やプライベートIPが固定で運用されているケースが多く、オペレーションの見直しも含めて実施を検討してみてください。   ということで、今回は AWS Auto Scaling による インスタンス 管理に切り替えた話について書いてみました。 次回は、続編として「 AWS AutoScaling とEC2のスポット インスタンス を組み合わせてWebサーバのコスト削減した話」について投稿したいと思います。 ------------------------------------------------------------------------------------------------- ※2020年の内容を記事にしており、2020年11月以降PHP7サポート切れをはじめとした 脆弱性 リスクへの対処は完了しております。