こんにちわ、クルーズ株式会社の鈴木です。   今回は開発の話というわけじゃないのですが、 Excel や スプレッドシート の新機能を使いこなして業務の効率化をしていこうという話をしようと思います。   表計算 ソフトは日々進化している！！ Excel 今も昔も様々な会社で使われている超定番の 表計算 ソフトです。 昔の話過ぎて記憶がかなり曖昧ですが、自分も確かExcel97の時代から触っていて、一番初めに使ったときはVLOOKUP関数すら使いこなせず、数式のエラーに苦戦していた記憶があります。 確か当時のパソコンのOSは Windows 95 だったはずなので発売が1995年… と考えると、約30年近く使っていることになります。   Excel 自体は1985年には存在していたようなのですが、PCがビジネスツールとして1人に1台まで普及するようになったのは Windows 95 以降だと思うので、 Excel がビジネスで使われるようになったのもおそらく約30年前くらいなのかなあと思います。そう考えると自分は相当な古参ユーザーだと思います。   余談ですが Excel 以前は、Lotusというソフトと、 ジャストシステム の製品で 表計算 ソフトがあったようですが、このあたりの歴史にはあまり明るくないです。   このように Excel の歴史は長く、その中で様々な機能のアップデートがありました。グラフがリッチになったとか、リボンUIが採用されるようになった、条件付き書式の設定ができるようになった、拡張子が4文字になったなどわかりやすいものもありますし、各シートで扱える行数が増えたなど処理能力的なものや、関数が増えたなど機能的なものなどさまざまなものがあり、新しいバージョンが出るごとに日々ソフトウェアとして進化しています。 また Google スプレッドシート も主要の Excel 関数が踏襲されていて、QUERY関数などのデータ抽出系の関数、REGEXEXTRACTなどの 正規表現 系の関数など独自のものもあり、 表計算 ソフト全般でみてもソフトウエアが日々進化しています。   一方で利用ユーザはそこまで進化していない？？ 上記のように Excel をはじめとする 表計算 ソフトは日々進化し便利になっているのに対し、その Excel を利用している人間はどうなんだろう？？と改めて自分の周りにある Excel ファイルや スプレッドシート を見てみると、あまりアップデートで入った機能や関数などが使われていないものもそれなりに存在しています。特に作成日が新しくゼロから作ったものでも、Excel97のころからあったような関数で数式組んでるなあって、もっと楽に帳票作れるのになあって思うものが多々あり、実は利用者はそこまでソフトウェアのアップデートの恩恵を受けれていないのでは？と思っています。 もちろん私自身がエンジニアで、「この関数使いづらいからもっと効率的数式の書き方とかないの？」とか「この処理ってセルのコピペで絶対ミスるから再利用性の観点でこうやって数式書いたほうがいいんじゃないの？」という長年エンジニアやってるから懸念に気づきやすかったり、調べる癖がついているというもあると思うのですが、それにしても「いやあ、これもっと効率よくできるでしょ」みたいなものもあります。   じゃあなぜ、利用者が最新の Excel をはじめとするソフトウェアの進化の恩恵を受けられていないのか？ こちら、あくまでも私の 私見 ですが以下の複合要因だと思います。   Excel というプロダクトの歴史が長く、よい意味で「完成された枯れたプロダクト」になってしまっていて、新しい機能や関数を使わなくても最低限のことはできてしまう。 Excel の使い方を体系立てて学ぶ機会が多くの場合、社会人1年目か社会人になる直前である。 新しい機能や関数について情報をキャッチアップする機会がない。   まず1についてです。 Excel ってどのレベルから使えるって言える？の会話でよく登場するVLOOKUP関数ですが、調べてみたところ1985年のリリース当初から存在しています。また条件付き集計関数のCOUNTIF関数はExcel97から存在しています。要するにビジネスツールとして1人に1台PCが支給される時代に Excel の主要な機能や関数はほぼ出来上がってるといえると言えます。 条件付き集計関数の話でいうと、複合条件下のカウントを行うCOUNTIFSという関数がExcel2007で登場しますが、この処理ってIF関数と、COUNTIF関数、あと真偽値(TRUE/FALSE)の概念が理解できていれば、新機能にキャッチアップしなくてもやりたいことはできてしまいます。このように基本的な機能に完成されていて、すでにある機能の組み合わせだけである程度の応用ができてしまうことが一因になっているのではないかと考えられます。     次に2についてです。 PCを使って業務を行っている人は多くの場合、 Excel を学ぶ機会が入社直後の研修であったり入社直前の学校の授業かと思います。 通常の研修カリキュラムはその時点の最新版のソフトウエアのバージョンで行うものの、以降それ以降は体系的に学ぶ場が無いためそこで知識がストップしてしまいソフトウェアの進化の恩恵を受けれなくなってしまうと考えられます。   最後に3についてです。 これは本当に書いてあるとおりなのですが、1の Excel がよい意味で「完成された枯れたプロダクト」になってしまっているため、能動的にキャッチアップに動く必要性に駆られないからなのでは？と個人的には考えています。   表計算 ソフトの進化でユーザが受ける最大の恩恵は「業務効率化」！！ 上記に記載のとおり Excel は非常に優れたビジネスツールであり、そのことが故にソフトウェアの進化して機能が追加されても能動的にキャッチアップに動く必要性に駆られにくい側面はあると思います。   じゃあ、利用ユーザはツールの進化に伴い、ツールの操作方法や関数の使い方など知識をアップデートしなくてよいのか？ こちらは明確に「No」です。新機能を使いこなすことで利用者にも様々な恩恵があります。 では新機能を使いこなすこと最も利用者が受ける恩恵は何か？それは「業務の効率化」だと考えています。   ツールとしてみた際の Excel 上での作業の効率化と、業務そのものの効率化の複数の視点で考えてみます。   反復操作が減れば作業の量が減るので、当然作業時間は短くなる 会社で Excel や スプレッドシート を使う業務の大半は集計や計算書の作成です。 その中でもよく使用される関数としてVLOOKUP関数があります。超定番の関数なのですが、いくつかめんどくさい点として 検索する値が、検索される表の一番左側にないと検索できない。 検索してセルに持ってきたい列が複数あると、列ごとにコピペで持ってきて参照列(第3引数値)を変更するしないとならない。 検索値が見つからなかった場合のエラー処理をIFERROR関数などで書かないとならない。 など考慮しないとならないことがあり、地味に手間です。特にめちゃくちゃ容量の大きい CSV ファイルをインポートした際など、検索列を CSV ファイルの先頭に持ってくるのですら処理が重くて待たされることもあります。 で、最近の Excel (パッケージ版ではExcel2021くらいから)はXLOOKUP関数という上記に列挙しためんどくさいことを行わなくてもよい関数が提供され、この関数を使用することで作業量が大幅に減ります。 XLOOKUP関数もそうなのですが、配列関数というものがあり、複数行や複数列を1つの数式で書くことができるので反復作業がなくなり作業量を減らすことができ、結果として作業時間が短くなります。   反復作業が減れば、数式ミスも確認も再作成も減り業務が効率化する 集計業務でめちゃくちゃ大事で、指導で手をやいていること。それは集計の正確性の担保です。 社内でヒヤリングしているとよくあるのが、新人が作成した集計やシミュレーションをもとに MTG しているとなんか数値おかしいぞってなり、その場でセルの数式を一つずつ確認をしたらコピペミスがあって MTG 時間が無駄になった。また再集計と MTG を行い直す必要性が出るので、さらに時間が無駄 工数 が発生するというような話。   もちろん、 表計算 ソフトをちゃんと使えていない本人にも問題があるし、事前の研修制度にも問題はあるし OJT トレーナーにも問題はあるとは思うものの、一方でコピペミスが発生する 根本要 因として、コピペして数式代入しないとならないセル自体が多いからです。 こちらも上記で紹介した配列関数が適切に使いこなせればコピペ自体が減り、確認項目も減り検算も効率化するし、必然的に集計数値の正確性も上がり、業務全体で見た効率も上がります。   新機能を使いこなして業務を効率化させよう！！ このように新機能を使いこなすこと、業務が効率化するという大きなメリットがあります。 表計算 ソフトは日々進化して便利な機能が次々と提供されています。そしてその恩恵は業務の効率化です。皆さんぜひ新機能について情報をキャッチアップしてみて下さい！   これだけは絶対に使ってみてほしい便利関数 長文になってしまいましたが、最後にこれ絶対業務が楽になるから使ってみてほしい関数を紹介します。   XLOOKUP関数( Excel / Google スプレッドシート で利用可能) 　　今回の業務効率化の事例として紹介した関数です。 　　検索作業がめちゃくちゃ楽になります。   ARRAYFORMULA関数( Google スプレッドシート で利用可能) 　　こちらも配列関数のような振る舞いをするもので、複数行あった際に一番初めの 　　行に数式を入れてしまえば一番最後の行までコピペをせずに同じ数式を適用して 　　くれるという関数です。 　　コピペ自体が減るので 表計算 上での作業自体も減るし数値の計算が間違うリスク 　　が減ります。   他にもこの関数使うととても作業楽になるよってものがあったら紹介していきたいと思います。

こんにちわ、クルーズ株式会社の鈴木です。   今回は開発の話というわけじゃないのですが、 Excel や スプレッドシート の新機能を使いこなして業務の効率化をしていこうという話をしようと思います。   表計算 ソフトは日々進化している！！ Excel 今も昔も様々な会社で使われている超定番の 表計算 ソフトです。 昔の話過ぎて記憶がかなり曖昧ですが、自分も確かExcel97の時代から触っていて、一番初めに使ったときはVLOOKUP関数すら使いこなせず、数式のエラーに苦戦していた記憶があります。 確か当時のパソコンのOSは Windows 95 だったはずなので発売が1995年… と考えると、約30年近く使っていることになります。   Excel 自体は1985年には存在していたようなのですが、PCがビジネスツールとして1人に1台まで普及するようになったのは Windows 95 以降だと思うので、 Excel がビジネスで使われるようになったのもおそらく約30年前くらいなのかなあと思います。そう考えると自分は相当な古参ユーザーだと思います。   余談ですが Excel 以前は、Lotusというソフトと、 ジャストシステム の製品で 表計算 ソフトがあったようですが、このあたりの歴史にはあまり明るくないです。   このように Excel の歴史は長く、その中で様々な機能のアップデートがありました。グラフがリッチになったとか、リボンUIが採用されるようになった、条件付き書式の設定ができるようになった、拡張子が4文字になったなどわかりやすいものもありますし、各シートで扱える行数が増えたなど処理能力的なものや、関数が増えたなど機能的なものなどさまざまなものがあり、新しいバージョンが出るごとに日々ソフトウェアとして進化しています。 また Google スプレッドシート も主要の Excel 関数が踏襲されていて、QUERY関数などのデータ抽出系の関数、REGEXEXTRACTなどの 正規表現 系の関数など独自のものもあり、 表計算 ソフト全般でみてもソフトウエアが日々進化しています。   一方で利用ユーザはそこまで進化していない？？ 上記のように Excel をはじめとする 表計算 ソフトは日々進化し便利になっているのに対し、その Excel を利用している人間はどうなんだろう？？と改めて自分の周りにある Excel ファイルや スプレッドシート を見てみると、あまりアップデートで入った機能や関数などが使われていないものもそれなりに存在しています。特に作成日が新しくゼロから作ったものでも、Excel97のころからあったような関数で数式組んでるなあって、もっと楽に帳票作れるのになあって思うものが多々あり、実は利用者はそこまでソフトウェアのアップデートの恩恵を受けれていないのでは？と思っています。 もちろん私自身がエンジニアで、「この関数使いづらいからもっと効率的数式の書き方とかないの？」とか「この処理ってセルのコピペで絶対ミスるから再利用性の観点でこうやって数式書いたほうがいいんじゃないの？」という長年エンジニアやってるから懸念に気づきやすかったり、調べる癖がついているというもあると思うのですが、それにしても「いやあ、これもっと効率よくできるでしょ」みたいなものもあります。   じゃあなぜ、利用者が最新の Excel をはじめとするソフトウェアの進化の恩恵を受けられていないのか？ こちら、あくまでも私の 私見 ですが以下の複合要因だと思います。   Excel というプロダクトの歴史が長く、よい意味で「完成された枯れたプロダクト」になってしまっていて、新しい機能や関数を使わなくても最低限のことはできてしまう。 Excel の使い方を体系立てて学ぶ機会が多くの場合、社会人1年目か社会人になる直前である。 新しい機能や関数について情報をキャッチアップする機会がない。   まず1についてです。 Excel ってどのレベルから使えるって言える？の会話でよく登場するVLOOKUP関数ですが、調べてみたところ1985年のリリース当初から存在しています。また条件付き集計関数のCOUNTIF関数はExcel97から存在しています。要するにビジネスツールとして1人に1台PCが支給される時代に Excel の主要な機能や関数はほぼ出来上がってるといえると言えます。 条件付き集計関数の話でいうと、複合条件下のカウントを行うCOUNTIFSという関数がExcel2007で登場しますが、この処理ってIF関数と、COUNTIF関数、あと真偽値(TRUE/FALSE)の概念が理解できていれば、新機能にキャッチアップしなくてもやりたいことはできてしまいます。このように基本的な機能に完成されていて、すでにある機能の組み合わせだけである程度の応用ができてしまうことが一因になっているのではないかと考えられます。     次に2についてです。 PCを使って業務を行っている人は多くの場合、 Excel を学ぶ機会が入社直後の研修であったり入社直前の学校の授業かと思います。 通常の研修カリキュラムはその時点の最新版のソフトウエアのバージョンで行うものの、以降それ以降は体系的に学ぶ場が無いためそこで知識がストップしてしまいソフトウェアの進化の恩恵を受けれなくなってしまうと考えられます。   最後に3についてです。 これは本当に書いてあるとおりなのですが、1の Excel がよい意味で「完成された枯れたプロダクト」になってしまっているため、能動的にキャッチアップに動く必要性に駆られないからなのでは？と個人的には考えています。   表計算 ソフトの進化でユーザが受ける最大の恩恵は「業務効率化」！！ 上記に記載のとおり Excel は非常に優れたビジネスツールであり、そのことが故にソフトウェアの進化して機能が追加されても能動的にキャッチアップに動く必要性に駆られにくい側面はあると思います。   じゃあ、利用ユーザはツールの進化に伴い、ツールの操作方法や関数の使い方など知識をアップデートしなくてよいのか？ こちらは明確に「No」です。新機能を使いこなすことで利用者にも様々な恩恵があります。 では新機能を使いこなすこと最も利用者が受ける恩恵は何か？それは「業務の効率化」だと考えています。   ツールとしてみた際の Excel 上での作業の効率化と、業務そのものの効率化の複数の視点で考えてみます。   反復操作が減れば作業の量が減るので、当然作業時間は短くなる 会社で Excel や スプレッドシート を使う業務の大半は集計や計算書の作成です。 その中でもよく使用される関数としてVLOOKUP関数があります。超定番の関数なのですが、いくつかめんどくさい点として 検索する値が、検索される表の一番左側にないと検索できない。 検索してセルに持ってきたい列が複数あると、列ごとにコピペで持ってきて参照列(第3引数値)を変更するしないとならない。 検索値が見つからなかった場合のエラー処理をIFERROR関数などで書かないとならない。 など考慮しないとならないことがあり、地味に手間です。特にめちゃくちゃ容量の大きい CSV ファイルをインポートした際など、検索列を CSV ファイルの先頭に持ってくるのですら処理が重くて待たされることもあります。 で、最近の Excel (パッケージ版ではExcel2021くらいから)はXLOOKUP関数という上記に列挙しためんどくさいことを行わなくてもよい関数が提供され、この関数を使用することで作業量が大幅に減ります。 XLOOKUP関数もそうなのですが、配列関数というものがあり、複数行や複数列を1つの数式で書くことができるので反復作業がなくなり作業量を減らすことができ、結果として作業時間が短くなります。   反復作業が減れば、数式ミスも確認も再作成も減り業務が効率化する 集計業務でめちゃくちゃ大事で、指導で手をやいていること。それは集計の正確性の担保です。 社内でヒヤリングしているとよくあるのが、新人が作成した集計やシミュレーションをもとに MTG しているとなんか数値おかしいぞってなり、その場でセルの数式を一つずつ確認をしたらコピペミスがあって MTG 時間が無駄になった。また再集計と MTG を行い直す必要性が出るので、さらに時間が無駄 工数 が発生するというような話。   もちろん、 表計算 ソフトをちゃんと使えていない本人にも問題があるし、事前の研修制度にも問題はあるし OJT トレーナーにも問題はあるとは思うものの、一方でコピペミスが発生する 根本要 因として、コピペして数式代入しないとならないセル自体が多いからです。 こちらも上記で紹介した配列関数が適切に使いこなせればコピペ自体が減り、確認項目も減り検算も効率化するし、必然的に集計数値の正確性も上がり、業務全体で見た効率も上がります。   新機能を使いこなして業務を効率化させよう！！ このように新機能を使いこなすこと、業務が効率化するという大きなメリットがあります。 表計算 ソフトは日々進化して便利な機能が次々と提供されています。そしてその恩恵は業務の効率化です。皆さんぜひ新機能について情報をキャッチアップしてみて下さい！   これだけは絶対に使ってみてほしい便利関数 長文になってしまいましたが、最後にこれ絶対業務が楽になるから使ってみてほしい関数を紹介します。   XLOOKUP関数( Excel / Google スプレッドシート で利用可能) 　　今回の業務効率化の事例として紹介した関数です。 　　検索作業がめちゃくちゃ楽になります。   ARRAYFORMULA関数( Google スプレッドシート で利用可能) 　　こちらも配列関数のような振る舞いをするもので、複数行あった際に一番初めの 　　行に数式を入れてしまえば一番最後の行までコピペをせずに同じ数式を適用して 　　くれるという関数です。 　　コピペ自体が減るので 表計算 上での作業自体も減るし数値の計算が間違うリスク 　　が減ります。   他にもこの関数使うととても作業楽になるよってものがあったら紹介していきたいと思います。

こんにちは。クルーズ株式会社CTOの鈴木です。   過去のテックブログにて「今後を見据えてFlutterの検証を始めた話」でも触れたとおり、インフラ構成を変える構想を今考えています。 あらためて要点でいうと、 MVC アーキテクチャ 、特にテンプレートエンジンの利用をやめるサーバは API の結果のみを返し、ブラウザの場合はフロントエンド フレームワーク がHTMLを組み立てブラウザに返すというものです。 上記を実現するものとしてフロントエンド フレームワーク の導入を検討しているというのが今回の話です。本ブログではその検証手順までの進捗をお話しします。 背景 背景としてはいくつかありますが、大きいものから順に記載すると ⓵表示速度やUI/UXの視点で見ると約半数のページに対して何かしらの改善できる項目があるのでそれを直していきたい。 ②上記を実現するのであれば何かしらの手段でフロントエンド開発の生産性を高められる仕組みを導入したい。　 です。   ⓵についてはあまり今回のフロントエンド フレームワーク の話というよりは、フロントエンド フレームワーク を導入する際に書き直して問題を解消したいよねという話のほうがニュアンスとしては大きいです。 但しどうせ解決するのであれば、Client Side RenderingやServer Side Renderingのように生成済みHTMLに対し仮想 DOM で差分だけを更新できる仕組みのあるものを使った方が表示速度を早められるので書き直してユーザ体感を上げる＆表示速度を早められる仕組みがあるものを採用したいという考え方です。 ②については コンポーネント ベースの組み合わせで作ることによる生産性を高めたいというのが実現したいことです。現状だと一部 smarty plugin でタグを返していますが、基本的には smarty 上でHTMLや java scriptを画面ごと書いている状態なのでこれの脱却を目指しています。 検証にあたり 今回この話をおこなうにあたり、Flutter同様で社内に十分な知見がある人がいない（全くないというと語弊があります、当然エンジニアなので興味関心があり、前職で趣味などで触っていた人はいます。）状況だったため、メジャーどころのreact.js(next.js)、vue.js(nuxt.js)について当社のフロントエンドエンジニアに、開発効率、パフォーマンス、手軽さ、開発効率、学習コスト、堅牢さなど10項目についてスコアリングを行ってもらい、スコアの高かったreact.js(next.js)でFlutterの時と同じように特定の機能を実装してみて生産性、学習コストを評価するという形で進めることとしました。 現在も進めている状況ですので、終わり次第、進捗をアップしようと思います。 次回は、本検証プロジェクトの結果は10月ごろにおこなう予定です。  

こんにちは。クルーズ株式会社CTOの鈴木です。 今回は、 ソースコード 品質の可視化を行う仕組みをとしてSonarQubeを導入してみようという話です。 www.sonarqube.org きっかけ ソースコード の品質の基準って何が適切なんだろうというところから話が始まっています。 私がCROOZ株式会社に入社した当時、Jenkins＋ CheckStyle ＋phpmdなど使って、 規約違反 や、重複やバグの疑いのあるコードを 機械的 に探してあげるというこ仕組みを構築し、運用していたことがあったのですが、運用に課題を感じていました。 理由としては、まずコーディング規約に違反があったからといってそれが一概に品質の悪い ソースコード とは言えない点、そして疑いがあるものをリストアップしたところでそれが疑いなのかそうじゃないのかの切り分けは結局開発者になり、ある程度継続的デリバリーを提供するツール内でフィルタリングができないと業務効率が悪く、結局開発者もツールが提供する情報を使わなくなると感じたためです。   SonarQubeも基本的な考え方は CheckStyle ＋phpmdなどと同じなのですが、大きく違うなと感じた部分については   ・ソフトウェアの品質メトリクスとして客観的に判断できる指標があり、それを基準として PDCA が回せそうであるから。 ・ PHP 以外に Android のコードについても静的解析が行えるから。 ・視覚的に分かりやすいから   の３点で、テスト的に私の横にあるデスクトップPCに一式インストールを行い実際のサーバサイドのソースとネイティブアプリの Java のソースでデイリーで実行しまずは使ってみました。 所感 ■GOODな点 ・ ダッシュ ボードが視覚的に分かりやすい。 ・issuesもphpmdと比較すると分かりやすいの精度が高い。 ■MOREな点 ・日本語の文献の量が少ない。特にカスタマイズしようと思うとしんどい。 ・現状のコードをそのまま解析すると膨大な検出件数となり、膨大なissuesが作成される。   基本的に日本語ドキュメントの量が少ないことが最も大きな問題だと感じています。特にQuality Profile周りの設定がよくわからず、結果として自分の中でいまいちな評価になっているのだと思います。 また、今の状況だとSonarQubeに頼らなくてもログファイル上のWarningでもっと先に対応しなければならない顕在化した品質の問題が見えているため、まずはログ上でWarning/Deprecatedが発生している箇所の修正を優先し、SonarQubeでソース解析を行った現実的に PDCA を回せるレベルの ソースコード にすることを優先したいと考えています。 上記とは別にSonarQubeのQuality Profile設定周りに詳しい方がいたら是非教えてください！

こんにちは。クルーズの鈴木です。   昨今、円安がすごいですよね。 年末あたり1ドル150円にまでになった時はさすがに驚きました。   さて、皆さんがお勤めの会社ではドル支払の クラウド サービスは利用しておりますでしょうか？ AWS や GCP などを利用されている会社はそれなりに多いのではないかと思います。 当社も AWS や GCP を利用しており、2022年ごろか急激に進み始めた円安の影響で当社でもドルで支払っているインフラコストは上昇し、ここ1年で約1～2割多く支払いをしている状況です。   今回は、この円安分の費用上昇分を削減すべく、ここ1年間で取り組んできたことについて紹介したいと思います。 個々の会社によって アーキテクチャ や、エンジニアリングチームの体制、得意分野など異なるとは思いますが、同じ悩みを抱えている方で何かの参考になればと思っています。   まずは考え方を変えるところから 「円安でインフラコストあがっちゃってさあ。(省略)。でどうしようか？」 という話を数名としたのですが、リアクションとして「どうしようもなくない？」という反応が大半でした。 確かにエンジニアの視点からみれば、 クラウド ベンダーはここ1年間同じ性能のシステムリソースに対して同じ金額をドルで支払っていて、かつ原因は為替でありエンジニアとしては為替変動はアンコントローラブルだから、まあ言ってしまえば「どうしようもない」です。 ただ、我々は日本で商売をしていて、お客様から日本円で料金をいただいて、サービスに必要なインフラコストを含む料金を日本円で支払っているので、ドル支払いの金額が変わらなくても、円安になれば日本円での支払額は増えてしまいます。   なので ・為替レート云々ではなく、インフラコストは円換算で考える。 ・要するに追加でコストを1～2割削減すればよい。 ・為替レートはアンコントローラブルだけど、実装やサービス選定などはエンジニアでコン トロール でき、ここで追加削減ができないかを考えればよい。 ・上記が実現でき、かつ円安→ 円高 に進めば何もしなくてももっとコストが勝手に下がる という考え方に基づいてどこの費用減らせる？を考えて取り組んできました。   コスト内訳を細かく分析する AWS や GCP をはじめとする各 クラウド サービスにはコスト内訳の見れる ダッシュ ボードがあります。 例えば AWS だとCost ManagementやCost Explolerなどです。 当社でも以前よりどのサービスでどの程度費用が発生しているか、各サービスの インスタンス 毎のメトリクスや、ZabbixやPrometeusなどをはじめとする監視システムで性能的な余剰が無いかなどは確認し、問題があればリソース見直しを進めていました。   だだここも、今までと同じ運用をしているだけでは新たな削減余地が見つけられないため、コストカテゴリ毎や、 インスタンス タイプ毎、 API の種類毎などディメンジョンを細分化して一体何の費用発生が多いのかを細かく見ていきました。   EBS料金、ネットワーク転送料金は削減余地あり コストを分析していく中でEC2やS3、ECSといったサービス単位で分類して考えがちですが、細かく見ていくうえでEBSに対しての費用割合が多いことに気づきました。 当社の場合、ECSやRDSなどのPaaSも使用していますが、EC2の利用も依然あり、端的に言えば仮想サーバの SSD です。 なのでEBSの料金を抑制するために以下を実施、現在も進めています。   ・ インスタンス のスペックアップにより稼働 インスタンス 数(EBS個数)を減らす。 　　→結果として インスタンス 数が減るのでEBSのボリューム数も減る。 ・DBを役割別に分ける＆ インスタンス サイズの最適化＆稼働 インスタンス 数を減らす。 　　→前提の思想は上記記載と同じでスペックアップで台数を減らす。 　　→役割別に分けることで、１ インスタンス あたりのEBSサイズを減らす。 　　→役割別に分けることで、役割毎に必要な稼働 インスタンス 数(EBS個数)を減らす。   またネットワーク転送については、細かく見てみると意図していない料金発生がありました。 具体的には CDN 上に配置できるような静的コンテンツに対して、EC2などへの直接参照や、 CDN 上に同一コンテンツがあるリソースなんだけどオリジンサーバを見ているケースです。 このあたりはコスト分析であたりを付けつつ、ソース上あたりを付け、参照先を差し替えるという地道な対応となるのですが現在進めています。   円安のタイミングにコスト削減を行う重要性 インフラのコストを削減は簡単にできるものばかりではなく、何かしらの作業 工数 がかかります。   例えば最小構成分を リザーブ ド インスタンス やSavingsPlans で購入するなど、「買い方」の工夫などは手間も少なく当社も既に取り入れています。 一方でインフラ構成変更やプログラム変更を伴うものもあり、そのような場合に開発、テストなどでそれなりの作業量が発生し、削減施策実施のタイミングや既存開発との優先度などでどちらを先にすべきかで議論になることがあります。 この議論の結論は私の考えとしてはどちらを優先にではなく、両方重要なものなので進めるが正しいと思っています。優先度の議論をすると進まなくなるからです。 当然エンジニアの人数には限りはありその中で何に注力するかという話は重要だと思っています。ただ注力しない = 全くやらないだけだと本当に進まなくなるので、できる範囲で。ただし1週間何もしないのではなく最低でもN時間はコスト削減に充てて少しずつでもよいので進めるという進め方にすべきだと考えて今進めています。   また為替レートはエンジニアから見るとアンコントローラブルだということは、今後上がるかもしれないし下がるかもしれない。であれば、円安のタイミングでコストの削減が行え、仮に仮に将来 円高 に動けば何もしなくてもさらにコストが下がる。そうすればその削減分でサービス向上のため投資ができる可能性があり、円安の今だからこそ改めてコスト削減余地が無いかについて見なおすべきだと考えています。   今回は具体的なインフラコストの削減事例としてEBS、ネットワーク トラフィック に着目した部分について紹介しましたが、ほかにもプログラム的に実施している処理のインフラサービスへの外出し、プログラム改修によるシステムリソース消費量の削減など鯖ざまな施策を行っております。 これらの施策についても機会があれば紹介したいと思っております。

こんにちは。クルーズの鈴木です。   AWS より昨年7月に発表があったとおり、今月よりElastic IPアドレス 以外のすべてのパブリックIPに対して課金が発生するような料金体系の変更がありました。 今回はこの話題について触れたいと思います。   Cost Explolerで VPC の料金が今月急に上がった 実はパブリックIP有償化の件は、既に社内から報告を受けていたものの６か月前だったことで、Cost Explolerで請求内訳をみても「 VPC 料金急に上がったんだけどなんでだ…？？。最近 VPC Peeringや VPC Endpoint新規で作ったっけ…？」 みたいな状況で、請求額が上がった理由がIP有償化だということにすぐには気づけませんでした。   ただ請求書のサービス別料金の内訳をよくよく見ていくと、以下のように VPC の内訳として「 IPv4 address per hour」の記載があり、それでパブリック IPv4 の料金有償化の件とつながりました。       月当たりどのくらいの追加課金となったか 当社の場合ですが、前月比で概ね250ドル VPC 料金が上がりました。 事前に発表されていたものなので見込んではいたもののせいぜい50～100ドル程度だと予想していたのですが、予想を大幅に上回る金額となってしまいました。   差異要因としては現在も調べているところですが、NATゲートウエイやALBなどのマネージドサービスの場合に複数サブネットにまたがる = 当然IPも複数必要になっている。 という部分の考慮が不十分だったのではないかと考えています。   パブリック IPv4 の有償化について サービス利用側として IPv4 の枯渇の問題は、私が大学に通ってた頃から言われていたことではあるものの今まで当たり前に使えていたものでかなり驚きました。 そして今月の VPC 請求額の急増をみて改めて IPv4 の枯渇に対する実感が沸いたというのが正直な感想です。   利用してるサービス全体の AWS 料金で見れば今回の有償化によるコスト増は1%にも満たないですが、ALBの統合などで IPv4 アドレスの利用を少しで減らせる余地が無いかについて今後取り組んでいきたいと考えています。また、続報を更新します。

こんにちは。新卒2年目のRYOBALです。 入社後1年間サーバーサイドエンジニアとして業務を行い、その後プロモーション部でプロダクト内のデータ分析や広告運用の業務を行っています。プロモーション部に異動し、これまでよりも数値を見る機会が増え、この部署にきて新たな学びもたくさんありました。 今回はそんな僕が業務を行っていく上で、特に為になったなと思った3つのことを実体験をもとに紹介します！ 1.情報収集が大事 自分から情報収集することはとても大切です。日々業務を行っているとそれが当たり前になってしまいついつい新しい発見をすることがなくなっていきます。特に僕はプロモーション施策や広告運用などをしていると数値を見ることが多く、数値で全て判断してしまいがちです。数値で判断するのは大事なことですが、もっと客観的にユーザー目線でユーザーは何を求めてサービスを利用しているんだろうと考えることも重要だなと日々感じています。 他社はどんな施策をしているのだろうとサイトや他の人の意見を聞き、情報収集することで新たな発見も多くあります。最終的にはユーザーにとって需要のあるサービスを作るのが本質的でとても重要なことです。 情報収集し毎日新たなことを1つ学ぶ習慣があれば、１年後のキャリアアップにつながるのでお勧めです。 2.優先するタスクと使えるリソースを考えること 日々仕事に取り組んでいると、目の前のタスクに一杯一杯になりすぎて、タスクの目的を見失いがちです。僕自身も目の前のタスクを終わらせようと夢中でやったものの、「あれ、よく考えてみるとこの作業やる意味なかったんじゃないの」となる時がありました。 そうならない為に自分のやるべきことを一度、俯瞰して整理することが大切です。 僕は朝イチに今日行うべきタスクは何かを考え、誰かに依頼する必要があるものは先に依頼をするなど優先順位をつけて仕事をしています。 また、直属の上司からは「より売上が期待できる仕事を行う」「使えるリソースは有効活用しなさい」と言われています。 「より売上が期待できる仕事」というのは、様々な施策の中でも「これをすることでより大きな売上が期待できる」施策のことです。僕は主に広告運用の業務を行っておりSHOPLISTというサービスの訪問者の増加、売上増加させる必要があります。 やりたい施策はいくらでもありますが、全てやっていては時間が足りません。そんな時は最も売上が期待できる施策を最優先として、業務に取り組み成果が出せるようにしています。 「使えるリソースは有効活用しなさい」というのは、【人・お金・時間】の中で最も限られているリソースは時間です。時間を有効活用する為にも、人やお金はリソースとして最大限使う必要があります。 特に、僕自身は広告代理店の方と共に広告成果を最大化するために日々業務を行っているので、全て自分1人で行おうとするのではなく、広告代理店の方のリソースを使いながら業務ができるかは成果にも大きく関わってくるのです。   仕事は1人で行うものではなく周りと協力して進めていくものです。周りを巻き込む力というのは、成果を出すだけでなく、効率よく仕事を行う上でも大切なことだと考えています。 3.一回きりで終わりではない。仕組み化が大切 業務を進めていくうえで仕組み化することはとても重要です。 日々の業務では、仕組化できるものが多くあると思います。 ・毎日更新しているスプシは自動で入力されるように仕組み化する ・誰に任せてもすぐにできるようにマニュアル化する など、仕組み化できる業務は多くあります。 僕自身も上司から仕組み化に関して指摘をもらったことがありました。 Twitter の広告配信で成果を上げるために、ある施策を上司に提案しました。 そこで言われたのが、「短期的にはそれで成果が上がるかもしれないけど、今後継続的にその施策で成果を上げるならどうする？今だと応用できないな」と。短期的な売上は作れるが、継続的に売上を作る施策にはなっていなかったのです。 僕と上司の視座が違うことを痛感した出来事でした。仕組み化というと、「誰もができるようにマニュアルを作ればいいんでしょ」などマニュアル化することだと感じるかもしれませんが、マニュアル化と仕組み化は少し違います。今回のように応用して使えるような仕組み化できるものが業務では大切だと考えています。   まとめ 今回は新卒2年目で業務を通して学んだ重要な3つのことを紹介しました。日々業務を行っていくと、たくさんの学びがあります。失敗したときの学びを次に活かすことが大切です。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。また、他にも面白い記事を発信しているので是非別記事も読んでみてください。それでは、また次回のブログで。 BYE☆ techplay.jp

こんにちは。クルーズの鈴木です。   昨今、円安がすごいですよね。 年末あたり1ドル150円にまでになった時はさすがに驚きました。   さて、皆さんがお勤めの会社ではドル支払の クラウド サービスは利用しておりますでしょうか？ AWS や GCP などを利用されている会社はそれなりに多いのではないかと思います。 当社も AWS や GCP を利用しており、2022年ごろか急激に進み始めた円安の影響で当社でもドルで支払っているインフラコストは上昇し、ここ1年で約1～2割多く支払いをしている状況です。   今回は、この円安分の費用上昇分を削減すべく、ここ1年間で取り組んできたことについて紹介したいと思います。 個々の会社によって アーキテクチャ や、エンジニアリングチームの体制、得意分野など異なるとは思いますが、同じ悩みを抱えている方で何かの参考になればと思っています。   まずは考え方を変えるところから 「円安でインフラコストあがっちゃってさあ。(省略)。でどうしようか？」 という話を数名としたのですが、リアクションとして「どうしようもなくない？」という反応が大半でした。 確かにエンジニアの視点からみれば、 クラウド ベンダーはここ1年間同じ性能のシステムリソースに対して同じ金額をドルで支払っていて、かつ原因は為替でありエンジニアとしては為替変動はアンコントローラブルだから、まあ言ってしまえば「どうしようもない」です。 ただ、我々は日本で商売をしていて、お客様から日本円で料金をいただいて、サービスに必要なインフラコストを含む料金を日本円で支払っているので、ドル支払いの金額が変わらなくても、円安になれば日本円での支払額は増えてしまいます。   なので ・為替レート云々ではなく、インフラコストは円換算で考える。 ・要するに追加でコストを1～2割削減すればよい。 ・為替レートはアンコントローラブルだけど、実装やサービス選定などはエンジニアでコン トロール でき、ここで追加削減ができないかを考えればよい。 ・上記が実現でき、かつ円安→ 円高 に進めば何もしなくてももっとコストが勝手に下がる という考え方に基づいてどこの費用減らせる？を考えて取り組んできました。   コスト内訳を細かく分析する AWS や GCP をはじめとする各 クラウド サービスにはコスト内訳の見れる ダッシュ ボードがあります。 例えば AWS だとCost ManagementやCost Explolerなどです。 当社でも以前よりどのサービスでどの程度費用が発生しているか、各サービスの インスタンス 毎のメトリクスや、ZabbixやPrometeusなどをはじめとする監視システムで性能的な余剰が無いかなどは確認し、問題があればリソース見直しを進めていました。   だだここも、今までと同じ運用をしているだけでは新たな削減余地が見つけられないため、コストカテゴリ毎や、 インスタンス タイプ毎、 API の種類毎などディメンジョンを細分化して一体何の費用発生が多いのかを細かく見ていきました。   EBS料金、ネットワーク転送料金は削減余地あり コストを分析していく中でEC2やS3、ECSといったサービス単位で分類して考えがちですが、細かく見ていくうえでEBSに対しての費用割合が多いことに気づきました。 当社の場合、ECSやRDSなどのPaaSも使用していますが、EC2の利用も依然あり、端的に言えば仮想サーバの SSD です。 なのでEBSの料金を抑制するために以下を実施、現在も進めています。   ・ インスタンス のスペックアップにより稼働 インスタンス 数(EBS個数)を減らす。 　　→結果として インスタンス 数が減るのでEBSのボリューム数も減る。 ・DBを役割別に分ける＆ インスタンス サイズの最適化＆稼働 インスタンス 数を減らす。 　　→前提の思想は上記記載と同じでスペックアップで台数を減らす。 　　→役割別に分けることで、１ インスタンス あたりのEBSサイズを減らす。 　　→役割別に分けることで、役割毎に必要な稼働 インスタンス 数(EBS個数)を減らす。   またネットワーク転送については、細かく見てみると意図していない料金発生がありました。 具体的には CDN 上に配置できるような静的コンテンツに対して、EC2などへの直接参照や、 CDN 上に同一コンテンツがあるリソースなんだけどオリジンサーバを見ているケースです。 このあたりはコスト分析であたりを付けつつ、ソース上あたりを付け、参照先を差し替えるという地道な対応となるのですが現在進めています。   円安のタイミングにコスト削減を行う重要性 インフラのコストを削減は簡単にできるものばかりではなく、何かしらの作業 工数 がかかります。   例えば最小構成分を リザーブ ド インスタンス やSavingsPlans で購入するなど、「買い方」の工夫などは手間も少なく当社も既に取り入れています。 一方でインフラ構成変更やプログラム変更を伴うものもあり、そのような場合に開発、テストなどでそれなりの作業量が発生し、削減施策実施のタイミングや既存開発との優先度などでどちらを先にすべきかで議論になることがあります。 この議論の結論は私の考えとしてはどちらを優先にではなく、両方重要なものなので進めるが正しいと思っています。優先度の議論をすると進まなくなるからです。 当然エンジニアの人数には限りはありその中で何に注力するかという話は重要だと思っています。ただ注力しない = 全くやらないだけだと本当に進まなくなるので、できる範囲で。ただし1週間何もしないのではなく最低でもN時間はコスト削減に充てて少しずつでもよいので進めるという進め方にすべきだと考えて今進めています。   また為替レートはエンジニアから見るとアンコントローラブルだということは、今後上がるかもしれないし下がるかもしれない。であれば、円安のタイミングでコストの削減が行え、仮に仮に将来 円高 に動けば何もしなくてもさらにコストが下がる。そうすればその削減分でサービス向上のため投資ができる可能性があり、円安の今だからこそ改めてコスト削減余地が無いかについて見なおすべきだと考えています。   今回は具体的なインフラコストの削減事例としてEBS、ネットワーク トラフィック に着目した部分について紹介しましたが、ほかにもプログラム的に実施している処理のインフラサービスへの外出し、プログラム改修によるシステムリソース消費量の削減など鯖ざまな施策を行っております。 これらの施策についても機会があれば紹介したいと思っております。

こんにちは。新卒2年目のRYOBALです。 入社後1年間サーバーサイドエンジニアとして業務を行い、その後プロモーション部でプロダクト内のデータ分析や施策提案などを行っています。今でもBigQueryで SQL を使ったデータ分析を日々行っています。 今では SQL を使った分析は欠かせないスキルで今後も業務で成果を出すために欠かせないスキルだと考えています。 今後、エンジニアや マーケティング 業務を行っていきたい方は身につけておくと非常に役立つスキルです。 今回はそんな僕が未経験から SQL を学ぶ上で知っておくべき勉強法を紹介しますのでぜひ最後まで読んでみて下さい。 そもそも SQL とは？ WEBサービス ではユーザーの情報を管理するためにデータベースが使われています。 データベースにはユーザーの購入情報やサイト内で販売されている商品情報など格納されており、そのデータベースを操作・定義・制御するために使われる言語が SQL （Structured Query Language）です。 SQL を使ってデータベースを操作するためには、 MySQL などの「データベース管理システム」が必要となり、データベース管理システムは SQL 命令文を処理することで、データベースの整理や検索を行ってくれるシステムです。 このシステムを使って、顧客情報や商品情報を管理し、日々のデータ集計やデータ抽出をすることが可能になります。 SQL 勉強法①まずは SQL の構文を理解する SQL は基本構文というものがあります。 まずは、その構文を理解し覚えることが SQL の勉強法に第一歩です。データベースには操作、定義、制御するのに下記のように表のように構文が変わります。 覚える構文はいくつかありますが、データ抽出にはSELECT句、FROM句、WHERE句の3つを覚えておくと最低限のデータ抽出はできるようになります。 データベースの操作 SELECT／UPDATE／DELETE／INSERT データベースの定義 CREATE／ DROP ／ALTER データベースの制御 GRANT／REVOKE／COMMIT／ROLLBACK 上記の基本構文を一通り押さえたら、テーブル結合やサブクエリ（ 入れ子 になった SQL 文）などの応用的な内容も勉強していきましょう。 僕自身も業務ではSELECT文を必ず使います。テーブルからデータを抽出する際に必ず使うので欠かせない構文です。 SQL 勉強法②サイトを使ってコードを書いていく SQL を覚えて理解するのためには、実際に自分の手で書いていくことが大切です。 僕も業務で SQL を書いていくことで自然と構文の使い方を覚えることができました。最初はサイトをみて必死に構文を覚えようとしていたのですが、なかなか頭に入ってきません。それよりも実際に自分で考えて手を動かす。これが最も効率良い勉強の仕方です。 Udemyや侍エンジニアなどプログラミングスクールの教材を使えば、実際に SQL を書くことができる環境を整えることができるので是非挑戦してみてください。 お手軽に無料で勉強していきたいという方はProgateやドットインストールを使って学んでいきましょう。環境構築などがなく、 SQL を1から学びたい方にもぴったりのサイトです。 僕がオススメするUdemyの教材は下記の「はじめての SQL 」です。 この教材のオススメの理由は、 ①データベースとは何かなど初心者基礎から学ぶことができる ②実際に SQL 文を記載していきながら進めることができる ③セクション13で応用問題として「 都道 府県別、月別平均客単価」を抽出するといった実際に業務で依頼するような問題があるので実践的である これを見るだけで初心者でも基礎的な内容が理解できるので興味がある方はぜひ見てみてくださいね。 他にもUdemyで「 SQL 」と検索を記載するとたくさんの教材が出てくるのであなたの興味のある教材を探してみてください。 SQL 勉強法③ひたすら SQL を書いてみる SQL を書く環境が整えばあとはひたすら SQL を書いて学んでいきましょう。 1年以上 SQL を触っていますが、まだまだ先輩社員の SQL 構文をみると「そんな書き方で抽出できるんだ！」と気づきがたくさんあります。 また、 SQL を書く上では不必要なデータ量を排除するために、WHERE文をどこで使うかなど負荷を考慮した抽出の仕方も知っておく必要があります。 ただ、闇雲にデータが抽出できればいいというものではないのも知っておくと良いでしょう。これも実際に SQL を書いて学んでいくことわかるようになります。 エンジニアにとって SQL は知っておかないと活躍できないスキルなのでこれからエンジニアになりたい方は絶対に身につけておきましょう。 まとめ 今回は未経験から SQL を学ぶ上で知っておくべき勉強法を紹介しました。 SQL を学ぶとはじめはコードの記載方法やテーブル同士の関連性を理解するのに時間がかかります。 ですが、一度基礎が理解できると様々なデータ分析を行うことができます。 僕自身も SQL を書けるようになったことで、サイト内での訪問者数や売上、広告経由のLTVなどプロモーションを行う上で必要な分析ができるようになりました。開発や マーケティング 部の方以外でも知っておくだけで活躍するスキルですので、ぜひ学んでみてください。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。また、他にも面白い記事を発信しているので是非別記事も読んでみてください。それでは、また次回のブログで。 BYE☆   最後に告知です！ 第12回目となる『テック ヒル ズ』を11月30日（水）に開催します。 今回のテーマは、近年注目を集める”コンテナ技術”についてです。 Docker、Openshift、 Kubernetes 、EC2、Fargateなど様々なコンテナ技術がありますが、  今回は、 Kubernetes とFargateの2つに焦点を当ててテック ヒル ズを開催します。 また当日は、㈱カカクコム 下國様、㈱ ナビタイムジャパン 萱島 様にもご登壇いただきます。様々あるコンテナ技術のメリット・デメリットの比較やコンテナ導入にいたるまでの話や、導入過程の苦労した話などからコンテナ技術に興味を持っていただくきっかけをご提供できればと思っております。 是非ご参加ください。 ■イベント概要：2022年11月30日（水）19時 ■登壇企業　　：クルーズ、カカクコム、 ナビタイムジャパン ■定員　　　　：500名 ■開催　　　　：オンライン開催 ▼お申し込みはこちら▼ techplay.jp

こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「 エンジニアも外部のメディアに露出することの重要性 」というタイトルでお話をしたいと思います。 僕自身の話をすると、メディアというのはおこがましいですが、本ブログの執筆・ Twitter アカウントの運用・イベントへの登壇を経験しております。 これらの経験をしていく中で、エンジニアの方がメディアへ露出している姿を目にすることが多くなりました。その中で感じた技術広報の重要性や実際に行っている広報活動についてお話しできればと思います。 駆け出しエンジニアの方はもちろん、エンジニアを目指している方、エンジニアでメディア露出へのご興味がある方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです！ 【重要】技術広報の大切さ 昨今エンジニア不足で悩まれている会社さんは多く存在しているかと思います。募集だけではなかなかエンジニアを集めるのは困難な世の中ではないでしょうか。そこでまず行うべきことが技術広報になってきます。   技術広報には、自社の技術力やエンジニアの働く環境に関する情報を外部に発信する役割があります。技術力の発信やエンジニアとして働く上での環境を発信することで企業のブランド力が向上し、優秀な人材が集まりやすくなるという利点があります。 この技術広報を行う上ではエンジニアの力が必要だと思います。知識はもちろん、技術力・環境について経験等を踏まえて語ることができるからです。 【紹介】私たちが行う広報活動とは ここでは実際に私たちが行っている技術広報活動についてお話しさせていただきます。 1つ目は、クルーズ主催の大規模テックカンファレンス「TECHHILLS」というものです。このイベントにはITサービスを提供する企業様を招いて特定のテーマについて話をしてもらうというものです。 直近だと7月27日に開催し、 アプリ開発 で注目されている「Flutter」「React Native」を用いた クロスプラットフォーム 開発という大テーマでクルーズ、 リクルート 、menuが取り組んだ事例をもとに、導入の背景や苦労した話をしていただきました。   2つ目は、小規模のイベントの開催です。TECHHILLSのように大きな規模ではなく小規模で、クルーズの技術力を中心にお話ししています。実際には弊社のCTOが登壇したり、 Ruby の生みの親であるまつもと ゆきひろ氏とディスカッションするなどの形で開催いたしました。 実際に僕自身もLT大会を主催し、学生参加のイベントに登壇させていただきました。 上記が主な広報活動となっておりますが、各イベント好評で本来の技術広報の目的である、自社 ブランディング の強化につなげられていると考えています。 【登壇】初めてのイベント登壇 先ほど軽く触れた僕自身が登壇したLT大会が人生初めての登壇であり、テーマは「若手エンジニアのしくじり体験とそこから学んでだこと」でした。自分自身のエンジニアとしての経験も浅く不安な気持ちが非常に大きかったです。ただ、実際に登壇する上で自身の経験を客観的に見ることができたし、エンジニアとしてもっと成長してレベルの高い内容で登壇したいという気持ちになりました。 自分の他にもエンジニア歴の短い方とお会いすることもでき、人脈という部分でもメリットがあると思いました。 また、実際に現場経験をした人が登壇することで、自らの失敗経験や成長するために行ったアクションを具体的に話すことができ、結果としてイベント自体の評価も高くなると感じています。 【発見】広報を活動を通して感じたこと これまで広報活動する中で感じたことは、優秀なエンジニアを集めるには技術広報が必要不可欠だということです。実際にイベントに参加いただける方は技術などへの非常に関心が強いという印象を受けました。こういった方は優秀なエンジニアの方が多いと思いますし、自社への関心などもあるということで採用にもつながりやすいと考えます。 また、現場で働くエンジニアが広報担当を担うことで、失敗や挫折など、エンジニアを経験したことがある人にしか話せない内容を届けることができるし、社内全体で広報への関心も高められることができると感じました。 さらには、個人の名前を売ることもできるので広報活動することで会社だけでなく自分にとっても有意義なものになるのではないでしょうか。 最後に 今回は、技術広報の大切や、私たちが行っている活動の一部をご紹介させていただきました。実際にはもっともっと細かく広報活動は行ってますが、実際に大きな成果を出せた時にまたお話しできればと思います。 最後まで読んでいただきありがとうございました。 また次回お会いしましょう！

こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「未経験からエンジニアになって思うエンジニアを経験するメリット」というタイトルでお話をしたいと思います。 僕自身、未経験からエンジニアになり1年間エンジニアをして開発部に所属しておりました。その後は事業部に異動となり現在に至ります。 そこで今回は、エンジニアという技術職を経験したのちにビジネス職に転向した際に感じたエンジニアを経験することのメリットについてお話しさせていただきます。 駆け出しエンジニアの方はもちろん、エンジニアを目指している方、エンジニアに少しでも興味がある方にとってためになるのではないかと思うので、最後まで読んでいただければ幸いです！ そもそもエンジニア人口ってどんなもん？ 僕自身、エンジニアを経験した人間の1人ですが、そもそも日本のエンジニア人口ってどれくらいあるのか気になって調べてみました。 日本のIT人材の人口は、ヒューマンリソシアによる国際労働機関( ILO )の公表データや各国の統計データの集計によると「およそ122万人」とされており、 アメリ カ・インド・中国に次いで世界4位ということでした。また、総人口に対して0.97%の割合で IT技術 者が存在している計算になります。 現状もIT人材の不足が叫ばれていますが、2030年には最大で79万人不足すると 経済産業省 が発表しています。 やはり、エンジニア不足はさらに課題となってくるのではないかと思います。 エンジニアを経験して身についたこと さて、実際に僕がエンジニアを経験したことで身につけることができたことは何かをご紹介させていただきます。 1つ目は「 ヒアリ ング能力」です。 ヒアリ ング能力とは相手の話を丁寧に聞いて理解することですが、開発をする上で依頼主が何を実現させたいのかを認識齟齬なく理解する必要があります。 ここで認識齟齬が生まれたまま侵攻してしまうと、いざ実装完了し確認を行ってもらうときに依頼主が思っていたものとは違うものであり、作り直しになる可能性が非常にいです。 そんな悲劇を起こさないためにも、依頼主と同じ目線で立ち、専門用語をわかりやすく噛み砕き ヒアリ ングすることが必要になります。そんな経験をしたことで ヒアリ ング能力を身につけることができたのではないかと思います。 ２つ目は「問題解決能力」です。エンジニアとして開発を行なっていると、一発で思い通りの挙動にはならないことがほとんどで、エラーが出てくるためそのエラーを解決するための問題解決能力が問われると思います。 何が問題でエラーが出ているのか、どうすればそのエラーを解消できるかという解決策を見つけることの日々だと思います。そんな日々を繰り返していくうちに問題解決能力を身につけらることができたと感じています。 身につけた専門知識は活かせるのか 前章では、正直エンジニアでなくても身につけることができるスキルを紹介しましたが、実際にエンジニア特有のITに関する専門的な知識も多少なりとも手に入れることができました。 そんな知識をビジネス職に移ってから本当に活かせるのか？という問いが出てくるかと思います。この疑問は自分自身エンジニアの頃から感じていました。 結論、エンジニアを経験して身につけた知識は活かせます。 弊社自体がファッションECサービスを運営しており、開発が付き物であるため、自ずと開発の方とコミュニケーションを取る機会が多いためです。実際にエンジニアを経験していることである程度システムの仕組みがわかっているのでコミュニケーションが円滑に進めることができます。 用語もいちいちわかりやすい言葉にしてもらわずにコミュニケーションが取れるため、どのように実装すればいいのかが具体的になり認識の齟齬も起きにくいです。 また、昨今はどの企業もIT化を推し進めているかと思うので、エンジニアを経験していることで、全くシステムがわからない人に差もつけられるかもしれません！笑 本当に必要とされる人材とは これまで、技術職とビジネス職を分けて考えていましたが、双方で必要とされるスキルを身につけたら最強の人材になれるのではないでしょうか。 これからの世の中を想像すると、今よりもっとデジタル人材の需要は高くなると考えられます。デジタル人材とは、データサイエンスやエンジニアリングといった「技術的・分析スキル」と、マクロ視点や課題解決能力、リーダーシップといった「ビジネススキル」の双方を持っているを人材だと考えます。そんな両刀使いができる人材はこれからも必要とされ続けるのではないでしょうか。 僕もそんな人材になれるように、エンジニアを辞めて今でもITの知識のインプットは欠かさずに行なっています。そしてビジネススキルを身につけるべく日々の業務にあたっています。 最後に 今回は「未経験からエンジニアになって思うエンジニアを経験するメリット」をお話しさせていただきました。 エンジニアの経験は絶対に無駄にならないものだと考えており、経験できたと心の底から感じています。この経験を活かして成長していけるように頑張ります！ 最後まで読んでいただきありがとうございました。 また次回お会いしましょう！

こんにちは。クルーズ株式会社CTOの鈴木です。   今回はFlutterアプリ⇔ API サーバ間の通信をgRPC対応した話についての事例紹介です。 gRPCってなに？ 平たくいうと Google が開発したネットワーク越しに別のコンピュータの関数を呼び出す仕組み (Remote Procedure Call)です。 イメージとしてはHTTPみたいな感じでクライアントからサーバ上にある関数、 API を呼び出すものなのでものすごくシンプルに見ればHTTPみたいな 通信プロトコル の一種でHTTPよりいろいろ優れているものだと思ってもらえればいいと思います。   gRPCってどんな特徴があるの？ 以下、わかりやすくするためにかなり簡略化して文章を書いているため、厳密にいうと個々の解釈違くない？？といった部分はおそらくありますのでご容赦ください。   HTTP プロトコル でRestAPIを実装した場合と比較した場合、gRPCでは主には以下のような特徴があります。 　① 双方向通信ができる(HTTP2準拠である) 　② バイナリ シリアライズ 　③ インターフェース定義をIDLという言語で記述しそれを再利用できる   ① 双方向通信ができる(HTTP2準拠である) gRPCではクライアントとサーバ間で以下の４方式の通信方式があります ・Unary RPC (1リク エス ト1レスポンス) ・Server streaming RPC (1リク エス ト複数レスポンス) ・Client streaming RPC (複数リク エス ト1レスポンス) ・Bidirectional streaming RPC (複数リク エス ト複数レスポンス)   一方、HTTPの REST API の場合は原則として1リク エス ト1レスポンスです。   ② バイナリ シリアライズ HTTPの REST API の場合、原則レスポンスはテキストで、 JSON 、 XML 、 YAML などで シリアライズ されているのに対し、gRPCの場合レスポンスはバイナリとなります。 これはテキストと比べると容量が小さくできることが期待できます。   ③ インターフェース定義をIDLという言語で記述しそれを再利用できる gRPCでは API の定義を.protoファイルというインターフェース定義言語で記載します。 そしてこの.protoはクライアントや API Docと共通で使用でき、バリデーション実装や API 設計にかかるコストの短縮が期待できます。   gRPCの実装ってどんな言語があるの？ 以下公式Documentの記載によると、2022年7月時点では以下の言語に対応しているようです C# C++ Dart Go Java Kotlin Node Objective-C PHP Python Ruby   grpc.io   実はgRPCは PHP に対応していない 公式Docによると PHP に対応しているように見えるのですが、正確にいうと PHP をClient としてgRPC通信が可能、ただしServerにはなれないということがわかりました。   ただ、以下文献にもあるように現時点ではできるようです。 qiita.com   但し導入の意思決定を行った当時は PHP でのサーバ実装は実現できていなかったため、以下のような構成によって実現をしました。   アプリと PHP サーバ間をgRPCさせる方法 まずどのようにgRPC通信させるかよりもgRPC通信によって得たいことを整理を行いました。   マストで実現したいこと ・通信量の圧縮 ・通信量の圧縮の結果としてのレスポンスタイムの向上 ・Unary RPC (1リク エス ト1レスポンス)通信の実現   マストじゃなくてもよいもの ・Unary RPC (1リク エス ト1レスポンス)以外の通信の実現 ※現時点で明確にメリットのある ユースケース があまりないため。   したがって、最も簡単にできるProxy をアプリと API サーバ（ PHP 実装）の間に挟む形での設計としました。     通信要件を整理すると ①アプリはGRPC Proxyサーバ に対してgRPCで通信を行う。 ②gRPCプロキシサーバがアプリからの通信をプライベートネットワーク内の 　Webサーバ( PHP )にHTTP プロトコル :80で転送する。 というものです。   これだけ見ると、WebサーバがmsgPackなどのバイナリ シリアライズ でアプリに返せばいいじゃんと思うかもしれません。 この指摘に対してはそのとおりです。今回この構成にした意図としては ・将来的にServer streaming RPC (1リク エス ト複数レスポンス)を実現するための検証 ・ API サーバとその他の API サーバ間通信をgRPC対応させるための検証 を兼ねているためです。   gRPCサーバ実装に C# を採用した理由 gRPCサーバの実装にさまざまな言語がある中で当社が C# を採用した理由は以下でした ・サーバサイド、コンテナの技術スタックとして既にあったものが C# とnode.js ・開発当時reflection機能や gzip 圧縮機能がnode.jsでは未実装だった   上記のため C# 実装にて行い、Kestrel上で ASP.NET CoreアプリケーションとしてgRPC プロキシを実装しそれを AWS Fargateで運用する形としました   実際のアプリtoサーバ間通信 gRPCサーバに万が一の不具合があっても従来のHTTPの REST API の通信に戻せるように、まずはアプリ起動時にHTTPの REST API でサーバの現状の プロトコル をを取得する API を叩きに行き、レスポンスがHTTP通信を示すものなら従来のHTTPの REST API でサーバに通信、gRPCを示すものならgRPC Proxyに通信する方式としています。   導入してみて API レスポンス容量のみで比較すると約1/10に圧縮がされ、サーバレスポンスとしては平均で約3～4割向上しました。   API レスポンス容量についてはバイナリ シリアライズ に加え、 gzip 圧縮の効果もかなり大きいのではないかと考えています。 理由としては ECサイト の API の場合、商品サムネ画像や関連商品画像など、 API レスポンス中に前方一致するURLが多いため、その共通部分が圧縮化されたことにより、レスポンスサイズが下がったことが主要因だと考えています。   今後について 今個人的に注目しているのがRoad Runner という GoLang で実装された PHP サーバです。 この アーキテクチャ はHTTPやgRPCを GoLang で受けて PHP をWorkerとして実行するものです。 実現性などまだ議論できるほど検討できてはいないですが、時間をとり検証していこうと思っている技術の一つです。   roadrunner.dev speakerdeck.com  

こんにちは。クルーズ株式会社CTOの鈴木です   今回はJenkins pipelineでFlutterのビルド時間を短縮化した件についての事例紹介です ビルド遅い問題をどうにかしたい アプリのビルドが遅い。 まあ遅いといっても約40分。通常時であればその間に別の仕事をしたり昼休憩をとったり時間をうまくやりくりしているので業務上そこまで問題があるわけではないのですが、緊急の不具合修正ですぐビルドして デバッグ ＆申請しなきゃ！みたいなときにこの40分という時間はとにかく耐え難く発狂しそうになります。 発狂しても何も変わらないことがわかっていても発狂しそうになります。 なのでこのビルド時間というのは1分1秒でも早くするのに何をしたらいいんだろうというのが今回のテーマです   当時はビルドマシンは Mac Studioの予定だった このビルド時間の問題が顕著になったタイミングはFlutterリリースを控え デバッグ を頻繁に実施していた2022年2月ごろです   以下の記事にもあるようにM1チップがビルドを圧倒的に早くできるという情報もあったことから、M1チップ搭載のMacStudioにビルドで困らないだけのRAMを積みマシンパワーでビルド時間を短縮させようと当時は考えており、M1 Ultra Chip(20 Core)搭載の Mac Studioを予約し、その上に一式環境構築してJenkinsのSlave Nodeとして追加して運用することでビルド所要時間を短縮化する計画を立てていました。   blog.codemagic.io   Mac Studioがいつまでたっても入荷せず… 発注を行ったのが2022年3月初旬だったのですが、当初から供給が追い付いていなかったのと中国ロックダウンの影響、ビルドでの用途のためカスタマイズモデルとして発注してしまったことなど様々な要因で一向に入荷せず、7月末時点でも入荷の目途が立たなかったことで、この問題が５か月間解決せず我慢の限界だったため、現時点で現実的に入手可能な Mac の最上位機種である Mac Pro （8 Core/ 16スレッド）のマシンと運用上の工夫によってまずはできる限り短縮化しようということでJenkinsの並列ビルドにてビルド処理の高速化を行いました   Jenkins Pipelineを使って各production とOSごとにビルドを並列化する Jenkinsにはバージョン2.0以降GitLabなどと同様に ビルドパイプラインを実現できる Pipeline Pluginがあり今回はこの機能によってビルドの並列化を実現しました。   現状ビルドに利用可能な Mac Pro は1台なので、今回はこの１台に各production(開発/RC/本番)×OS( iOS / Android )の計6つのビルドを並列化して処理するパイプラインとして構成しています。       ビルド時間はどのくらい短縮した？ ざっくりですが約40分⇒13分まで短縮ができました。 現時点でビルド中にCPUが100%に貼りついているので、ビルドマシンを分散すればさらなる短縮が目指せそうです。   iOS と Android では iOS のほうがビルドに所要時間がかかるので、MacStudio が納品されたら、 iOS のビルドを Mac Studio のノードで実行させることでさらなる短縮が目指せるのではないかなと期待しています。  

こんにちは。クルーズ株式会社CTOの鈴木です。   今回は、SHOPIST.com by CROOZの iOS / Android アプリをFlutterでリニューアルした話について書こうと思います。先日の7月27日に当社主催にて開催したテックカンファレンス「テック ヒル ズ」でもお話させていただきましたが、約1年間をかけ検証・機能移行を行い、現在公開に至りました。   過去記事と重複する部分などありますが、背景や何がどう変わったかについて改めて書かせていただいたので、リプレイス検討中の方や クロスプラットフォーム に興味がある方は是非読んでみてください。 背景 詳細の話は「 今後を見据えてFlutterの検証を始めた話 - CROOZ TECH BLOG 」にまとめておりますが、大きくは以下の２つです iOS / Android設計・実装言語 を共 通化 することによる生産性の向上 iOS / Android設計・実装言語 を共 通化 することによる技術スタックの統合   二次的なものを加えると、 フルスクラッチ で作り直すことにより、結果的に秘伝のタレ的なコードとの決別 が追加される感じとなります。   アプリリリース当時は、十分なアプリの開発体制が整っておらず、個人に依存していた部分が大きかったため、本来設計として共 通化 できる部分においても iOS / Android 間でプログラム設計が異なるなど言語以外の部分でも差異があり、設計に関する調査、保守コストを削減したかったというのも背景にはありました。   なぜFlutterだったか？ 実装言語を統合する手段としては、 クロスプラットフォーム 言語ないし フレームワーク がありました。XmalinやReact Nativeなど様々ある中でFlutterを選定した理由については、開発コミュニティの発展具合、情報量の多さ、参画するエンジニアのモチベーション、ライセンス上のリスクの大きく４点を各 フレームワーク で比較して最終的にFlutterを選定しました。   少し掘り下げると ①開発コミュニティの発展具合 これはわかりやすいかと思います。 OSS プロジェクトなのでコミュニティが盛り上がってないとバージョンアップやバグの修正などの活動が十分に行われず、アプリは完成したはいいもののリリース後にFlutterSDKのバージョンアップが行われず自分たちだけででFlutterSDKを保守していかなければならないリスクがあります。そのリスクを軽減するための評価項目です。 OSS のメリットを享受できないというリスクがあると考えていただければ理解しやすいかもしれません。 またUtility周りはゼロから作るよりもPackage,Pluginを積極的に活用して開発 工数 を減らしていきたいので、 OSS 活動が活発的なプロジェクトほど導入することで生産性を向上できるプロジェクトと考えていて、この項目を評価項目としていました。 OSS ではなく商用であっても、開発チームやコミュニティについては同じ考え方で評価をしました。   ②情報量の多さ こちらもわかりやすいかと思います。公式のドキュメントがどの程度あるか、公式以外の参考文献がどの程度あるか？ GitHub のIssuesで会話が流れているかなどです。   ③参画するエンジニアのモチベーション 今まではエンジニア寄りでも少し上流の主にマネジメントレイヤーの人たちの会話みたいになってしまったのですが、それとは別に参画するエンジニアが興味関心があり、チャレンジしていたいと思える技術要素かという視点の評価項目です。 エンジニアである以上、多かれ少なかれ新しい技術にはだれもが関心があるとは思うものの、一方でエンジニアである以上度合いが違えど自分が好む言語や技術というものが必ずあるわけで、そこに合わないものを入れちゃうとマジでモチベーションが駄々下がりするので、やったことないけど興味関心が持てる技術要素かについて社内のネイティブエンジニア数名にヒヤリングをして、選定の参考としました。   ④ライセンス上のリスク 「 今後を見据えてFlutterの検証を始めた話 - CROOZ TECH BLOG 」にも記載のとおりです。ここはリスク最小にしようねという話なので割愛します。   リプレイス中に苦しめられた諸問題 ①WebView周り Cookie 制御、HTTP/ HTTPS のMixedContents制御、JSで取得できるはずのイベントの取得ができない、一部call back動作がうまく動かないなど、WebView表示部分についてはなぜかうまく動かない系の問題が非常に多く、結局WebViewのPackageをFlutter公式のwebview_flutterからflutter_inappwebviewに切り替えてそこからさらに トライアンドエラー を進めながらなんとか問題が収束するに至りました。 基本的にメイン画面やUI/UXに凝る部分でWebViewを使うことはなく、Flutterの検証についてもメイン画面などのWebViewを使わない部分の検証がメインで、WebView部分についてはサーバコンテンツが表示され、表示崩れがなければ検証としては合格としていたためこの問題に気づくのが遅れ、修正対応に２～３週間ほど余分にかかってしまいました。なので私からのアド バイス としては、 WebViewのPackageをFlutter公式のwebview_flutterではなくflutter_inappwebviewにすべきだ。 ネイティブアプリなんだからWebViewを使う範囲はなるべく最小にしたほうが良い。（特に新規でアプリ作る場合は使わないくらいの気概で進めるべき） です。   ②テキストボックスへのキー入力で謎のクラッシュ発生 テキストボックスからLost Focusしたタイミングでアプリがクラッシュする事象が発生し、調査するも原因がわからずかなり苦労しました。ようやくクラッシュのタイミングで関係のない画面までrebuildされていることまではわかったものの、なぜrebuildが実行されるのかの原因がつかめず、1か月以上試行錯誤を繰り返していました。 結局キーボード表示時にMediaQueryがrebuildを実行させていることが特定でき、回避ははできたもののかなりこの問題には悩まされ、最後のほうはFlutter SDK に手を入れPull Requestするしかないとメンバーと覚悟を決めてFlutterSDKのソースを1週間読むまでしました   1年かけてFlutterリプレイスして得たもの ①約２倍の生産性 端的に言うと iOS / Android が同一設計同一実装にて実現できる フレームワーク と体制、 もう少し正確にいうと実際にはOS個別処理や端末個別処理はあるし、 デバッグ は両OS個別に行わなければならない項目もあるため本当に2倍にはならないですが、概ね2倍のスピードは手に入れられていると思います。   ②秘伝のタレ的なコードとの決別 もう一つ得たものとしては、上記の約２倍の生産性とも関連しますが、だれが作ったんだか何の意図があるのかもよくわからないコードを解釈しながら調査するという極めて無駄な業務から解放されたという事実です。 結構この調査にも今まで時間をとられていて、この決別を合わせると実際には２倍以上の生産性は手に入れられたのではないかと個人的には感じています。   Flutterリプレイスを検討している方へのアド バイス 最後に、Flutter導入を検討している方へのアド バイス です。 両OSを共通実装できるメリットというものは本当に大きいですが、やはり気つけるべきポイントはいくつかあるかと思い、私の視点ですが以下に記載します   ①WebView注意 これは既に記載してあるため割愛します。flutter_inappwebviewを使ったほうが良いのではという話です。   ② ナレッジに依存する部分が多い ドキュメントは正直かなり豊富ではある反面、やってみないとわからない。もう少し正確にいうと、文法や実装方法の習得は文献やUdemy 等の活用でできるものの、実現したいことに対し、何のクラス、何のプロパティを組み合わせて実現するのが最適かが トライアンドエラー を繰り返さないとわからないという問題です。 もうこの問題については、趣味がFlutterのメンバーに半年遊んでもらってfeed Backをもらうか、経験者を最低１名参画してもらうくらいしか思いつかないです。   ③バージョン更新が早い＆ReleaseNoteがわかりづらい あたりまえですが、Flutterは現在進行形で発展している技術なので、 Bash や SQL のように枯れている技術じゃないです。そのためFlutter SDK もパッケージのバージョン更新頻度も早いですし、Release Noteの記載も成熟したプロダクトと比較してしまうと結構荒いです。なのでこまめにバージョンアップはチェックし、ローカル環境で定期的に試すようにしたほうがいいです。   ちなみに当社ではfvmという Fluttterのバージョン管理ツールを使ってバージョンの管理をしています。Nodeでいうnpmのようなツールです。 fvm.app   今回は長文となってしまいましたが、ここ１年かけてFlutterでアプリをフルリプレイスした話を記事としてまとめました。 1年というと長いように感じるかもしれませんが、現状の仕様調査込み技術検証込みでの1年だったため今回紹介しきれないくらいの様々な学び、ナレッジがあるので、今後トピックとして共有していきます。   テック ヒル ズで公開させてもらった記事についてもこちらにリンクを貼っておきますので興味があったら見てみてください。   speakerdeck.com  

こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「 未経験エンジニアが成長するために必要なこと3選 」というタイトルでお話をしたいと思います。 未経験でエンジニアになった僕が、成長するために必要だと感じたことや、先輩エンジニアの方からアド バイス 頂いたことを元に、お話できればと思います。 エンジニアに限らず社会人として必要なことでもある内容となっているのでぜひ参考していただきたいです。 駆け出しエンジニアの方はもちろん、エンジニアを目指している方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです！ 【心得】エンジニアを目指すうえで必要な心得 まず、エンジニアを目指すうえで必要な心得からお話したいと思います！ 僕の所感として、エンジニアのイメージとしてかなりスマートな仕事だと思われている人が多いと思います。難しそうな文字を黒い画面で打ち込んでいるし、パソコンをカタカタしているのでそういったイメージになっているのではないかと思います。 ただ、表面だけ見ればそうかと思いますが、実際はかなり泥臭い作業だと思います。というのも、書いたプログラムが一発で思い通りの動きになるかというとそうでもありません。なので、エラーと向き合ったり、何度もテストをしたりすることが必要になります。地道な作業や調査を経て完了することが往々にしてあるので、そういった泥臭さを持っておくことは必要だと思います。 泥臭さはどんな職種でも必要だと思いますので、成長するためには必要な心得ですね！ 【その1】検索能力を高めよう ここからは具体的に必要なことを紹介していきます。 1つ目は「検索能力を高めよう」というものです。プログラムを書いていく中で実装方法が分からない・分からない関数というものが必ず出てきます。そして、その方法はたいていネットのどこかに載っています。この先人たちによって残された情報や、公式のリファレンスを参考に解決することがどのエンジニアをも行っている事です。 その中で、知りたい情報を最短で調べることが重要になります。ここで誤った情報をキャッチアップしてしまったり、時間をかけすぎてしまうのは非効率的です。 なので、検索能力を高めることは非常に重要なことになります。 具体的にどのように検索するのが良いのかというと、「実現したい事を、具体的に 言語化 し検索する」です。 例えば、 PHP で データベースから受け取ったデータ（配列形式）を別の配列と繋げたいという場面では、検索文言としては「 php 配列 結合」のようになります。 実現したい事＝配列の結合なので、検索文言としては実現したいことが具体的になっていると思います。 上記に例は、かなり簡単な例なのですが、複雑なものだとしても、1つずつ分解して 言語化 していけばほしい情報をキャッチアップすることができると思います。 検索能力を高めるというのは、エンジニアになりたての頃にかなり口酸っぱく先輩に言われましたので、非常に重要なことだと思います！ 【その2】納期を意識する 2つ目は、「納期を意識する」です。これは正直社会人としては当たり前に重要なことだと思います。なぜ挙げたかというと、納期を意識する上では、開発のスケジュールを引き、タスク管理を行うことが必要になります。 スケジュールを引きタスク管理を行うことは最初は難しく、僕自身もなかなかスケジュールどうりに進捗させることはできなかったです。ただ、スケジュールを引く中で、まず開発方針を考え、それぞれどう進捗させるかを考える力が鍛えることができます。 実際に僕は、開発方針を可視化できるようにスライドにまとめていました。この作業を行うようになってから、実装方法の蓄積や関数のナレッジを自然と集められるようになり、エンジニアとしての知識も広げることができました。 このように納期を意識することで、付随して必要になっていく作業が出てきます。それらを自ら考えて行動することで成長できるのではないかと思い、挙げさせていただきました。 【その3】めちゃくちゃ先輩を頼る 最後の3つ目は、「めちゃくちゃ先輩を頼る」です！最後の最後に頼るのかい！というツッコミもあるかと思いますが、正直成長するためにはかなり重要だと思います。 調べてもなかなか答えにたどり着かない、そもそもどうすればいいか検討が付かない等の壁にぶつかることがあると思います。その悩みに時間をかけすぎることはもったいないので先輩に相談することがどこかのタイミングで必要なのかな思います。 それぞれの 閾値 を置いていいかと思いますが、僕は15分調べて分からなかったり答えが出せない場合は先輩に相談していました。 先輩に相談するときに大事なのは、「何がしたいのか、どこまで調べたのか、どんな仮説を持っているのか」を明確に伝えることです。ただ聞くだけでは自分のためにならないし、相手もどこまでわかっていてどこで詰まっているのかの認識を合わせる事から始めないといけません。 相談するという事は少なくとも相手の時間を奪う事でもあるので、そこ意識を持つことは非常に重要です。 エンジニアになりたての頃の僕は、何も考えずに相談してしまったことがり、先輩に「自分で調べたのか」「どう考えているのか」を聞かれていました、、、 まとめ 今回は「未経験エンジニアが成長するために必要なこと3選」を紹介させていただきました。書いてる中で、3つともエンジニアだけではなくて社会人としても大事な意識だなと思いました（笑） まだまだ成長に必要なことはあると思いますので、いつかご紹介させていただきたいと思います。 最後まで読んでいただきありがとうございました。 また次回お会いしましょう！

こんにちは。新卒2年目のRYOBALです。 入社後1年間、全くの未経験からエンジニアとしてプログラミングを勉強し始め、試行錯誤しながら業務についていくので必死でした。そんな1年間を振り返り、若手エンジニアとしてやっておきたい「3つのすべし」を僕の経験を通して紹介していこうと思います。 これからエンジニアになりたい！エンジニアとして活躍したい人に参考になる記事なのでぜひ最後まで読んでみて下さい。 その① 命名規則 やルールの理解をすべし 仕事であれば何事もそうですが、エンジニアもまず基礎を知ることはとても重要です。 エンジニアはコードのコメントの付け方やメソッドの 命名規則 など社内独自のルールがあります。自分の書いたコードは周りのメンバーもそのコードを読み解く機会があります。エンジニアはチーム開発をすることがほとんどで、チームで開発をする上でルールに基づいて開発を進めていくことが開発のスピードが速まるのです。 特に経験の浅いエンジニアがコードを記載し、コメントの書き方も適当にしてしまうとベテランエンジニアからすると、このコードは一体何をしたいのかわからないとなってしまうこともあります。 経験が浅いエンジニアほどこの基本的な 命名規則 などルールに基づいて業務を進めていくことが重要になってくるのです。 その② 進捗報告を頻繁にすべし 業務を行っていくうえで上司から進捗を聞かれることは多々あります。頻繁に上司から進捗を聞かれるということは自分の進捗報告が甘いということになります。進捗報告がないからこそ上司が心配となり、あなたに聞いているのです。特に若手エンジニアはこの進捗報告を徹底して行うようにしましょう。 例えば、業務の進捗が悪くても進捗をきちんと伝えることでプロジェクトがスムーズに進みます。なぜなら、現状を伝えることで周りのメンバーもプロジェクトの進捗を把握することができ、遅れが出ていた場合の手助けができるからです。ここで一番大事なのはプロジェクトを進めてプロジェクトの目的を達成することです。進捗が悪くて怒られたくないと思って、リリース日近手助けを求めても周りに迷惑をかけてしまうだけです。そうならない為にも常に進捗報告をすることは重要です。 僕も最初は上司に「 20%の状態でもいいので報告しなさい 」と教わりました。早い段階で報告することで万が一やり方が間違えていても20%の状態であれば後戻りすることができるというのも進捗報告をするべき理由の一つです。 その③ 質問をとにかくすべし 「エンジニアは自分で調べて解決しろ」という考えの人もいるかもしれませんが、若手エンジニアはわからなければ質問をすることも大切だと思います。 例えば、コードエラーが出たので、自分で調べて解決しようとしていろいろなサイトを調べます。ベテランエンジニアの場合はすぐに解決法を見つけて解決できますが、若手エンジニアの場合は解決法が見つかりません。僕自身もいくつかサイトをググってみて調べても解決方法がわからず上司に質問すると、すでに僕がググったサイト内で解決方法が見つかったという出来事もありました。若手であれば解決方法が載っているサイトを見てもそれが解決方法だとわからないということも起こるのです。 その為にもわからなければ悩みすぎず、質問をしてしまうのが良いです。おすすめの方法は「15分調べてわからなければ聞く」などとググったり考える時間に制限を設けて業務をすることで時間を無駄にせず業務を進めていくことができます。 まとめ 今回は若手エンジニアとしてやっておきたい「3つのすべし」について紹介しました。一見誰でも簡単にできそうだと思うかもしれませんが、しっかりとできている方は少ないかと思います。この3つのすべしをするだけで成長スピードが速くなるので是非、新卒エンジニアの方は意識してみて下さい。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。また、他にも面白い記事を発信しているので是非別記事も読んでみてください。それでは、また次回のブログで。 BYE☆

こんにちは。新卒2年目のRYOBALです。 社会人になって1年が経ち、エンジニアや マーケティング 部で様々な業務をしてきました。今回は新卒からこの方法をしていれば、仕事を早くこなせていたという業務効率化について僕の経験を通して紹介していきます。新卒1年目の方や今より業務を効率よくこなしたい方はぜひ最後まで読んでみてください。 効率化手段①タイピング PCを使って業務を行う方は多いかと思います。 日々の業務で当たり前に使っているタイピングだからこそ、早くなった方が効率よく仕事をすることができます。 タイピングをするメリットは下記があります。 ・キーボードを打つ作業の仕事の生産性が上がる ・議事録が早く正確に取れる ・手書きよりも入力が速い CROOZ SHOPLISTの新卒研修でもタイピング研修があり、設定された合格ラインを超えないと配属させてもらうことができません。具体的な合格ラインというのはタイピングサイトを使って5分間で750文字以上入力できれば合格というものです。最初は新卒全員が300~400文字程しか入力することができません。750文字以上ってがっつり練習しないとかなり厳しいラインなんですよね。 それでも毎日コツコツ練習していると3か月や4か月後には750文字を達成することができます。中には1000文字以上入力できる人も出てくるほどです。 タイピングスキルが上がると必然的に文字の入力スピードが上がるので生産性も上がります。もちろんブラインドタッチもできるようになっているのでわざわざキーボードを見て入力することもありません。 僕は新卒の時にタイピングの勉強をしていて本当に良かったなと感じています。タイピングが遅いなと感じている人も練習次第で早くなるので是非、練習してみてください。 効率化手段②ショートカットを覚える 「社会人の方にとっては当たり前だよ」と思うかもしれませんが、ショートカットを覚えることも業務効率化には大切です。 【 Windows の場合】 ・コピー(Ctrl + C) ・貼り付け(Ctrl + V) ・上書き保存    Ctrl + S ・元に戻す    Ctrl + Z ・印刷ダイアログボックスの表示    Ctrl + P ・検索    Ctrl + F ・置換    Ctrl + H ・全選択    Ctrl + A など、基本的なショートカットからあまり知られていないショートカットまで数多くあります。ショートカットは普段使っていくと習慣になり自然と覚えられるものです。 例えば、 Excel で10,000行以上記載のあるシートのデータをコピーしたいとします。ショートカットを知らない人であれば、ひたすら下矢印を押して最終行まで選択してコピーしていくので1分以上かかるでしょう。 しかし、ショートカットを知っていれば、「Control+Shift+↓」を使えば1秒で選択することができます。 このようにショートカットを使える人と使えない人では仕事のスピードが変わってくるのです。特に、日々 Excel や スプレッドシート を使う人であればショートカットをいち早く覚えることをおすすめします。 効率化手段③関数 ショートカットと同じく Excel や スプレッドシート を使用する上で覚えておきたいのが関数です。 Excel 関数を使用すると、手作業とは比較にならないほど速く、正確にあらゆる計算を処理できます。作業効率や正確性を向上させる上で、関数の使用は必須。まずは、基本の関数を習得し、それからは業務の内容に合わせて必要な関数を習得することをおすすめです。 SUM    合計値 MAX、MIN    最大値・最小値 ROUND    四捨五入 IFERROR    エラー時の表示切替 IF    条件判定 IFS    複数条件判定 SUMIF    条件を指定して合計 SUMIFS    複数条件で合計 COUNTIF    条件を満たす値の数 COUNTIFS    複数条件を満たす数 VLOOKUP    値の検索・表示 が代表的な関数としてあります。 僕もSUMやVLOOKUP関数はよく使用していました。これまでSUMIFS関数を使用していませんでしたが、使い始めてからは「なんて便利な関数があるんだ！」と感動して頻繁に使っています。 関数は条件式が複雑になると覚えるのも大変ですが、使ってみると生産性が上がる関数がたくさんあるので是非勉強して使用してみてください。 効率化手段④目的を明確にして仕事をする 当たり前のことだと感じるかもしれませんが、意外にできていない人は多いです。 目的を知って仕事をすることで、正しい手段を選択して目的を達成することができます。 特に、上司から仕事を依頼されるのが多い新卒ではこの目的を把握せずに仕事をしてしまう人も多いです。なので、言われたことをただこなす部下になってしまいます。 もしかすると、自分がやっている仕事は目的とずれた仕事をしてしまい、最終的に結果に繋がらない仕事をしていることもあります。時間をかけても何も成果が出ない仕事なのです。そうならない為にも、今の仕事はどういう目的があってしているのか理解して行うようにしましょう。 また、目的を理解して仕事をしていれば途中で「別の方法をした方が目的を達成できる」と上司に提案することもできます。 課題を解決するための近道をする上でも目的を明確にして仕事をすることは業務効率化の一つとも言えますね。 まとめ 今回は仕事を効率よくこなす業務効率化について紹介しました。今回紹介した方法は僕も実際に新卒としてやっておいて良かった方法です。別の会社の友人はタイピングが遅いなどで仕事で苦労している人もいます。 タイピングや関数など当たり前に使っているものこそ早く習得することで今後の仕事のパフォーマンスも上がると思っています。 今後も業務を通して経験したことや役に立ったことを記事にして発信していくので楽しみにしてください。また、他にも面白い記事を発信しているので是非別記事も読んでみてください。それでは、また次回のブログで。 BYE☆

こんにちは。新卒2年目のKEN☆YAMAGUCHIです！ 今回は「新卒でエンジニアになってから、1年でどこまで成長できたか」という話をしたいと思います。 今年の4月で、入社から1年が経ったのと同時に、エンジニアの道に進んでから1年が経ちました。そこで今回はこの1年間を振り返りつつ、未経験でエンジニアになってから1年でどこまで成長できたのかをお話しさせていただきます。 本当に未経験でもエンジニアを目指せるのか・文系でもエンジニアになれるのか、気になっている方も多いのではないでしょうか？そう言った疑問を僕の実体験とともに紐解いていければと思います。 駆け出しエンジニアの方はもちろん、エンジニアを目指している方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです！ 【希望】未経験でもエンジニアを目指せる 結論から言ってしまうと、未経験でもエンジニアになることは可能性です。文系だろうが関係ありません。多少の向き不向きはあるかもしれませんが誰でもエンジニアになる事ができると思います。 自分自身、文系大学出身かつプログラミングの経験は一切ありませんでした。入社してから 基本情報技術者試験 の勉強や開発研修を経て本配属となりましたが、1年経った頃には複雑なプログラムの読解や、基本的に1人で開発を行うことができるようになりました。 もちろん、「独り立したエンジニア」にはなれていないのが現状ですが、サポートをいただきつつ案件の遂行ができています。僕は座学で学ぶより実際に手を動かしつつ学ぶ方が性に合っているので簡単ものからコツコツ経験を積ませてもらえたことが成長につながったと思います。 実際に期間ごとにどんな状態であったのか振り返ってきたいと思います。 【苦悩】エンジニア歴 1~3ヶ月編 エンジニアになりたてのこの頃は、わからないことばかりで非常に苦労したのを覚えています。この頃はまだ、研修中であったのでインプットがメインでありとにかく覚えまくることに力を使っていました。さらに、エンジニアの世界はカタカナ用語が多くて混乱していましたし、わからない用語が出てくるたびに google で検索しまくっていました。 開発研修も行っていましたが、これまで一切プログラミングの経験がなかったのでそもそもの仕組みや、簡単なプログラムを書くもの非常に大変でした、、、 全てが新しいことばかりで、学びが多かったので、食らいつくのに必死という感じでした。 【不安】エンジニア歴 3~6ヶ月編 エンジニアになって3ヶ月が経ち、いよいよ本配属となります。この頃開発研修も大詰めでしたが、本当に配属され実務で学んだことが使えるか非常に不安でした。 開発研修で使用していたプログラムはかなり単純なものでありましたが、実際に ECサイト のプログラムは複雑なものであるため、本当に大丈夫かなと震えておりました。 ただ、時間は止まってはくれないため、配属されることになります。いきなり1人で放り出されるのではなく、しっかりトレーナーの方がついてくれたので安心しましたww トレーナーとなってくれた方も未経験からエンジニアとなり、社内で活躍されている方でした。その方の勉強方法を取り入れつつインプットも続けておりました。 実際に開発案件を担当することとなり、初めてサービスに関わる開発経験することになりました。既存のコードを理解することから始まり、実際にコードを書くのですが、1人ではとてもじゃないけどできませんでした。 このように挫折経験をし、本当にエンジニアとしてやっていけるのかと、この期間はただただ不安でした。 【成長】エンジニア歴 6ヶ月〜1年編 不安を抱きながらも細かなものから経験を積んでいる状況でしたが、ある時、今まで学んでいたもの使用するというのが自然とできてくるようになりました。さらに、振られた案件も最初はどのように実現するかをまずは1人で考えてトレーナーに壁打ちするということを続けていくと、徐々に指摘されることも少なっていきました。 この期間では今までのインプットがしっかりアウトプットできるようになった期間だなと思います。 相談事がある時にだけトレーナーの方にサポートしてもらい、基本的に1人で案件を進められるようになり、やりがいも感じることができました。 自分としては一番成長を感じることができた期間かなと思います。 まとめ ここまで読んでいただければ分かるように、エンジニアなりたての頃は成長を感じることがなかなかできませんでしたが、半年から1年が立つ頃に成長を感じることができるようになりました。あくまで僕の例なので一概には言えませんが、僕と同じような成長曲線を描く方が多いのではないのかなと勝手ながら思っています。 偉そうに話していますが、まだまだ未熟なエンジニアであることに変わりはありません。トレーナーとなっていただいた、先輩エンジニアのように社内で活躍するエンジニアになれるように精進してきます！ 最後まで読んでいただきありがとうございました。 また次回お会いしましょう！

こんにちは。クルーズ株式会社CTOの鈴木です。 先月よりBigQueryへのデータ集約処理を実現する手段として、 クラウド のETLサービスのtroccoの導入を検討していて、現在テストを実施しています。 当社データ基盤の現状課題 データの鮮度問題 データソースは複数ありますが、現状最もデータ転送に時間がかかっているものはサービスの基幹DB（ MariaDB ）です。 現状、深夜に作成されるDBバックアップファイルをもとに、社内集計用DB（個人情報をマスクしたもの）を作成しており、それをデータソースとして PHP の転送プログラム経由で各テーブルごとにBigQuery上にデータの転送を行なっているため、前日のデータの集約完了が、当日の夕方以降になってしまいリアルタイム性が悪い状態となっています。 もっともビジネス上の要件として本当の意味でのリアルタイム性の要求があるわけではなく前日分が翌日に見れればよいのですが、現状だとその翌日が翌日夕方だったり、バッチが失敗した場合に リカバリ 時間が確保できなかったりするので、早められるのであれば早めたいという状態になっています。 現状Data LakeとData Ware Houseだけがあり、DataMartが存在し無い構成 正確にいうと、DataLakeとしてBigQueryが存在していて、Data Ware Houseというよりはデータマートに近いテーブルがBigQuery上に存在していて、それを各種管理画面やMetaBaseなどのレポートツールが参照している現状になっています。 設計上きれいじゃないという部分以外にもコスト面の問題があります。事実1年前比較でBIgQueryの利用料は約5倍に増えてしまっていました。（勿論BigQueryを活用し、データに基づく意思決定ができる環境整備を行なっているため、一定のコストが増える事は正しいことであるという認識ですがそれにしても増えすぎていて削減余地があるのではないかと考えています） 実現を検討している構成 要件の整理 当社環境について改めて要件を整理してみると要件は以下になります １．データソース Google Anaiytics FireBase 社内DB（ MariaDB 。 AWS 内のプライベートサブネットに配置） フラットファイル（ Amazon S3 ） 外部Web API ２．データ統合先 BigQuery ３．求められるデータ更新頻度 日次（大部分） 毎時（一部の トランザクション テーブル） 実現方式の検討 データの転送方式 Google Anaiytics　　： Google Analytics の機能でBigQueryに連携（変わらず） FireBase　　　　　   ：FireBaseの機能でBigQueryに連携（変わらず） 社内DB　　　　　　  ：SSをインストールしたEC2を設置し MySQL コネクタ経由 ログ：分割テーブルに対してInsertで転送 マスタ：シャーディングテーブルに対してInsert転送 S3　　　　　　　　  ：S3コネクタ経由 外部Web API                ：検討中。何かしらの方法でS3にPUTを検討 現時点では方式の検討を行っっているのとトライアル申し込みを株式会社primeNumberに行いアカウント開設を待っている状態です。 検証結果については別記事にてまた公開したいと思います。

こんにちは。新卒2年目のRYOBALです。 僕は2021年4月クルーズに入社後、未経験ながらも開発研修を通して、サーバーサイドエンジニアとして配属され、1年後に マーケティング 部に異動しました。 今回は未経験からエンジニアとして働いた僕が考える未経験からエンジニアを目指す人が知っておいたほうが良い4つのことについてお伝えしていきます。 これからエンジニアを目指していきたい方、今エンジニアとして働いている方の参考となればと思いますので、是非最後までご覧ください。 ①向き不向きがある プログラミングは正直なところ、向き不向きがあります。これからプログラミングがんばるぞ！という方でもいざやってみると「あれ、思っていたよりもエラー解消など地道な作業で全然楽しくないや」と思う方も多いです。 一方、コードを書いたり、成果物ができることに楽しさを感じ、「エンジニアが天職！」という方もいます。 僕自身もエンジニアってハッキングとかコンピュータですごいことできるんでしょ。と実際に自分で開発する前は思っていましたが、実際の仕事はそんな華やかなものではありませんでした。もちろん、経験を積めばプログラミングでいろいろなサービスを開発できたりはしますが、最初は全くわからなくて当然です。 自分にエンジニアの適性がありそうかどうかは実際にProgateやドットインストール、Udemyを使って最低限自分でコードを書いてみることが大事。 ②プログラミングスクールと実務は全然違う これからエンジニアになりたい方であれば「一度プログラミングスクールに行ってプログラミングを学ぼう！」と思っている方は多いのではないでしょうか？ プログラミングスクールでプログラミングを勉強するのは良いことですが、スクールと実際に企業に就職して実務で仕事行うのは少し違います。プログラミングスクールを決して否定しているわけではありません。実際どんなところが違うのでしょうか？ ・スキルのレベルが違う 実際に企業で働くと周りのエンジニアのレベルが高く、自分の知識だけでは全く役に立ちません。スクールではHTMLから CSS 、 Ruby など様々な言語を学ぶことができますが、実務で役立つレベルの知識ではありません。そういう意味でもスクール卒のエンジニアの場合でも就職してからは多くの知識を学ぶことに苦労します。 ・個人開発とチーム開発 プログラミングスクールでは個人で何か一つのサービスを開発することが多いです。 一方、企業では基本的にチームで開発をするので個人開発とは少し違います。 チームで開発する際は「既存のコードのルールを守る」「期日を守る」などチーム開発ならではのルールがあります。 中には3人程のチームになって一つのサービスを開発するチーム開発を行うというプログラミングスクールもありますが数少ないです。企業で働く形に近い形で学習したい方はチーム開発ができるスクールもおすすめです。 ③勉強が好きな方にはおすすめ プログラミング学習をすると、新しい知識を毎日習得していくので自分のスキルが身についていきます。エンジニアという職業は経験を積めば積むほど、スキルが自分にスキルが身につきます。なので、勉強が好きな人にはエンジニアという職業がおすすめです。 また、コードが書けると目に見えてできることが増え、それに対してやりがいを感じる人も周りには多くいます。 エンジニアの成長の感覚として、筋トレと少し似ているのかなと思います。筋トレもすればするほど、自分に筋肉がつき、成長の実感が目に見えます。筋トレはうそをつかないというのもよく言われていますが、エンジニアも同様正しいコードが書けると動作は必ずします。また、ITは日々進化しています。時代に取りに残されないためにも、日々情報をキャッチアップできる人が向いているでしょう。 ④企業によってエンジニアの仕事は様々 入社初めからがっつりコーディングをして学んでいきますが、企業によってエンジニアの仕事の範囲は様々です。 エンジニアの中でもフロント・サーバーサイド・インフラ・ネットワーク・テスト・ システムエンジニア など種類があり、テストはサービスに不具合がないか確認する作業で実際にコードを書かない現場もあります。 となると、がっつりコーディングをしたいと思ってエンジニアとして就職したのに実際の仕事は思っていたものと全然違うといったことが起きてしまいます。そうならないために就職する前にその企業の業務内容をきちんと確認することをしておきましょう。 未経験からエンジニアを目指すべき人がやっておくこと 未経験からエンジニアを目指すべき人がやっておくべきことはまず、自分自身でプログラミングを勉強してコードを書いてみることです。なぜなら、上記でもお伝えした通り、エンジニアという職業は向き不向きがあるからです。 実際に、今の時代エンジニアが流行っているからとプログラ ミンスク ールに通ったものの、やりがいを感じず、エンジニアとは別の職業についた友人もいます。ただ、流行っているというだけでやっていける簡単な職業ではないです。途中で挫折しない為にも一度、自分自身でコードを書いてみる経験はしておいたほうが良いでしょう。 まとめ 今回は未経験からエンジニアを目指す人が知っておいたほうが良い4つのことについてお伝えしました。プログラミング経験0から実際に企業でエンジニアを経験した僕が身に染みて実感した内容です。エンジニアという職業はやりがいがある業務もあれば、もちろん大変な業務もあります。興味を持った方はまずは一度自分自身で勉強して触れてみてくださいね。 クルーズに興味がある方はぜひ採用HPからご連絡くださいね。それでは、また次回のブログで。 BYE☆