こんにちは、技術広報の yayawowo です。 今回は、 ラク スの開発組織メンバー達に 『2021年の気になったニュース』と気になった理由・ポイント を聞きました。 なお、昨年実施した内容もまとめておりますので、ご興味ありましたら是非 こちら をご確認ください！ 質問：皆さんの「2021年の気になったニュース」 を教えてください！ 目次 『2021年の気になったニュース』ランキング 1位：log4j ゼロデイ脆弱性 2位：みずほ銀行システム障害 3位：iOS15リリース 3位：GitHub漏洩 4位：NTTドコモ通信障害 4位：IE サポート終了 5位：Windows11 リリース 5位：PHP8.1 リリース 5位：Java17 リリース 5位：AlmaLinux リリース 5位：Apple AirTag 発表 5位：キャリアメール持ち運び 5位：Facebook 社名変更 5位：小説の続きを書いてくれるAI その他気になったニュース 終わりに 『2021年の気になったニュース』ランキング 以下は当社 ラク スの開発組織メンバーが選んだ『2021年の気になったニュース』ランキングです！ 調査概要 調査手法:任意アンケート( ヒアリ ングシート)※複数回答可 調査対象:当社開発組織メンバー(テッ クリード ・開発マネージャー含む) 調査項目:2021年12月22日迄のニュース 有効回答数:111回答 ランキング内容:得票数2票以上の2021年の気になったニュース 順位 ニュースタイトル(概要) 得票数 1 log4j ゼロデイ 脆弱性 12 2 みずほ銀行 システム障害 8 3 iOS15リリース 4 3 GitHub 漏洩 4 4 NTTドコモ 通信障害 3 4 IE サポート終了 3 5 Windows11 リリース 2 5 PHP8.1 リリース 2 5 Java17 リリース 2 5 AlmaLinux リリース 2 5 Apple AirTag 発表 2 5 キャリアメール持ち運び 2 5 Facebook 社名変更 2 5 小説の続きを書いてくれるAI 2 1位： log4j ゼロデイ 脆弱性 www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 社内でもかなり盛り上がっていた話題です。 気になったニュース、これに持ってかれました。 噂になっていたのと、丁度ＷＡＦ触る機会があったので気になりました。 マインクラフトにも影響があったので我が家の子供も知っていた点で影響の大きさを実感しました。 ログ出力というきわめて基本的なライブラリに 脆弱性 が見つかったことで、多くのソフトウェアが影響を受けた印象です。ライブラリを正しく最新に更新している企業ほど影響を受け、EOLになったv1.xを使い続けていた企業は影響を受けなかったというのも何とも皮肉な話だと思いました。 　 などなど 2位： みずほ銀行 システム障害 www.jiji.com ◆ ラク ス開発メンバーが気になった理由・ポイント 超上流工程が与える影響の大きさを垣間見た。 体制云々の話はさておき、今後この巨大なプロジェクトをどう改善していくのかが気になります。 定期的に話題が上がり、中の人大変だろうなと思いました。 修正の目途が立ったのか気になります。 　 などなど 3位：iOS15リリース support.apple.com www.commerble.com ◆ ラク ス開発メンバーが気になった理由・ポイント ユーザ視点では嬉しい限りですが、サービスへの影響がすごそうだなと思いました。 セキュリティはもちろん大事ではあるが 開封 にしても Cookie にしても影響の大きさのわりに本来の課題の解決を実感できていないもどかしさはある。 業界に与える影響が大きいと感じました。 　 などなど 3位： GitHub 漏洩 news.yahoo.co.jp www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 開発者の初歩的なミスによって甚大な被害が出たという内容に驚愕しました...。 もちろんそんなことはしないが、gitという意味では同じものを使っているので、そういうところは意識していかないとマズいと再認識させられた。 リモートワークが当たり前になって便利半面、企業セキュリティの抜け穴ができやすくなっているのかなと思いました。 今年で一番ヒヤッとしたニュースです。 　 などなど 4位： NTTドコモ 通信障害 japan.zdnet.com ◆ ラク ス開発メンバーが気になった理由・ポイント いかにNTTの通信網が広く普及しているのかが実感できました。 切り戻し時の作業で障害が発生したとのことで、１つのケースとして学びがありました。 通信 輻輳 (性能)の調査・テストはしっかりすべきだということが染みた。 　 などなど 4位： IE サポート終了 blogs.windows.com ◆ ラク ス開発メンバーが気になった理由・ポイント Microsoft は2022 年 6 月 15 日に IE のサポート終了を発表している点が気になりました。 ブラウザ互換性の面で開発者に苦労させてきた IE のEOL日程が、とうとう決まり感慨深いです。 フロントエンドエンジニアとしては IE 対応で苦しんだ経験があるので、時代の変わり目を感じました。 　 などなど 5位：Windows11 リリース www.itmedia.co.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 早く使ってみたいですが、私の個人PCにはまだインストールできていません・・・。 個人的にはWindows10以前の無骨なデザインが好きでした。 　 などなど 5位：PHP8.1 リリース www.php.net ◆ ラク ス開発メンバーが気になった理由・ポイント ラク スが主催する技術イベントやブログでも話題になりました。 技術イベント PHP8.1 の新機能について語り合う PHP TechCafe 【PHP8.1リリース記念】PHPerのためのPHP8.1をもっと語り合うPHP TechCafe ブログ PHP8.1 の新機能について語り合う・前編【PHP TechCafe イベントレポート】 PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 　 などなど 5位：Java17 リリース www.oracle.com ◆ ラク ス開発メンバーが気になった理由・ポイント Java17(LTS)が今年の9月にリリースされました。新しい機能だけではなく以前のバージョンよりパフォーマンスが良いということです。 Java 11から3年ぶりのLTSとなる Java 17がリリース。新しいライフサイクルポリシーのもと継続的に新しいバージョンがリリースされるようになったことは望ましいと言えるが、更新についていけない組織は辛そうだと思いました。 　 などなど 5位：AlmaLinux リリース codezine.jp ◆ ラク ス開発メンバーが気になった理由・ポイント CentOS7のサポート切れも迫る中、将来的にAlmaLinuxにお世話になるのかが気になってます。 ContOS8の代替先を見つけるのに苦労していた。 　 などなど 5位： Apple AirTag 発表 www.apple.com iphone-mania.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 4個入りを買って持て余しています。 悪用されそうだなと思っていたので、 Android 対応も確かに必要と思いました。 　 などなど 5位：キャリアメール持ち運び iphone-mania.jp ◆ ラク ス開発メンバーが気になった理由・ポイント 妻にドコモメール持ち運びできることを教えてあげたら大喜び、結構キャリアメールに紐づけしていることが分かった次第です。 文字コード の影響がないか気になりました。 　 などなど 5位： Facebook 社名変更 www.businessinsider.jp ◆ ラク ス開発メンバーが気になった理由・ポイント GAFA の一角が メタバース に本腰を入れたことに驚きました。Oculusの新モデルに期待しています。 サマーウォーズ のような世界が実現するのかとワクワクしました。 　 などなど 5位：小説の続きを書いてくれるAI otona-life.com ◆ ラク ス開発メンバーが気になった理由・ポイント 既存の作品や登場人物なんかを入れると、うまいこと関連を出してくる。これを一人で作ったらしい。すごいです。 Twitter の趣味アカウントで盛り上がってました。結構自然な仕上がりになるのがすごいです。 　 などなど その他気になったニュース ラク ス開発メンバーが気になったニュースはランキング入りしたもの以外にも多くありました！ サイボウズ の“駆け出しエンジニア”向け研修資料が話題　Web アプリ開発 やIT文化の基礎を無償公開 www.itmedia.co.jp 「 Visual Studio Code 」がインストール不要に。 Webブラウザ で動作 pc.watch.impress.co.jp Flutter 2.0リリース developers.googleblog.com Remix、 OSS 化 remix.run AWS がデータ管理の改善を目的とした4つの新たなストレージサービスを発表 jp.techcrunch.com Scala3リリース www.scala-lang.org Docker Desktopが有料化へ www.itmedia.co.jp Amazon EKS Anywhereが正式リリース www.publickey1.jp 終わりに ラク ス開発メンバーが選ぶ『2021年の気になったニュース』はいかがでしたでしょうか？ 今回、開発メンバー達から100以上の回答がありました！ ラク スでは日常からビジネスチャットの中で、話題性のあった技術ニュースの見解を発信し、意見を募っているのを良く目にします。 改めて、開発メンバー達の関心の高さを感じました！ 最後になりますが、本内容が皆様の情報探索の一助となれば幸いです。 では、2022年も引き続きよろしくお願いいたします！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、弊社サービス「配配メール」の開発に従事している id:soachr （そーく）といいます。 以前は id:north_mky というユーザで投稿していましたが結婚を期になんとなくユーザを変えました。 ID の由来はとくにありません。 今回は、駆け出しエンジニアさん向けに「 オブジェクト指向 」を PHP でプログラミングしようと思います。 対象読者 オブジェクト指向 の実務イメージがわかない・しっくりきていない駆け出しエンジニアさん if/for/配列などは理解して実装できる カプセル化 ？継承？ ポリモーフィズム ？なにがいいの？と思っている 記事を読んでわかること オブジェクト指向 で書かれたプログラムの良さがイメージできる オブジェクト指向 の入門書を改めて読み返して理解を深められるようになる オブジェクト指向 、正直よくわからんってなっていませんか？ オブジェクト指向 は プログラミング言語 によらない概念の話なので抽象的でわかりづらいですよね。 今回、言語は PHP でわかりやすく説明していきたいと思います。 はじめに 対象読者 記事を読んでわかること 身近なあのシステムをオブジェクト指向で書いたら…? なぜブログを題材にしたのか ブログにはどんな要素があるか見てみましょう 1. 記事 2. できる操作 3. ユーザ オブジェクト指向でこれらをプログラムに変換していきましょう 記事クラス ユーザクラス オブジェクト指向の良いところ カプセル化 継承 ポリモーフィズム（多態性） おわりに 身近なあのシステムを オブジェクト指向 で書いたら…? なるべくイメージがつきやすい題材として今回は 今まさに見ている”ブログ”を オブジェクト指向 でプログラミングしていくことにします。 なぜブログを題材にしたのか BtoC, BtoB のサービスに問わず、システムによくある画面・機能があるからです。 すべて書きだすと記事の文字数がすごいことになるのと、かえって情報が多すぎてわかりづらくなるので割愛します。 よくあるシステムの画面・機能 ブログ 閲覧画面 記事の閲覧画面 閲覧画面／ユーザが操作できるボタンなど 記事に対する”いいね” 編集画面 記事の編集画面 ブログにはどんな要素があるか見てみましょう ブログってどんな要素があるでしょうか。考えてみてください！ 1. 記事 ぱっと思い浮かぶのは、ブログと言えば「記事」ですね。 記事 タイトル 本文 "いいね"するアイコン 2. できる操作 ではできる操作はなんでしょうか。色々ありますが、 よくある操作は以下ではないでしょうか。 記事を作成する 記事を公開する 記事を閲覧する 記事に”いいね”する 3. ユーザ ここまでで見える部分や、よく行う操作についてはわかりました。 でも、目には見えないけれど暗黙的にある情報があります。 たとえば、 「ユーザがログインをしているかどうか」 です。 ブログは世界中の人がログインしなくても見られますし、一方でログインしていても見られます。 でも、両者では”できること”が違いますよね。 ログインしていない人は、”いいね”というアイコンを押したとしても、”ログインもしくは新規登録してください”と表示されることが多いと思います。 といったように、 そのシステムはだれが使うのかという情報 があります。 ログインしているユーザ ログインしていないユーザ（システムからみたら、閲覧画面を利用者に提供しているのでユーザですね） ブログを構成する要素をみてきました。 では、これを PHP を使って、 オブジェクト指向 プログラミングをしていきましょう！ オブジェクト指向 でこれらをプログラムに変換していきましょう 前章でみた情報を PHP を使い、 オブジェクト指向 で書くと以下のようになります。 記事クラス <?php class Article { // 1. 記事 private string $ title ; // タイトル private string $ body ; // 本文 private array $ likes = [] ; // "いいね" // 2. できる操作 // 記事を作成する public function create () : void { $ this -> title = "" ; $ this -> body = "" ; } // 記事を公開する public function publish ( string $ title , string $ body ) : void { $ this -> title = $ title ; $ this -> body = $ body ; } // "いいね"を追加する(ここはあとで説明します！) public function addLike ( LoginUser $ user ) : void { array_push ( $ this -> likes, $ user ) ; } } まず、記事に関する情報とできる操作を class Article{} でひとまとめにしました。 実際のシステムのイメージをそのまま落とし込んだ ようになって見やすいですね。 情報と操作が別々にあると、操作に必要な情報がどこにあるか探すのがとても大変になります。 実務だとプログラムの行数がかなり大きくなったり、プログラムファイル数が数十〜数百いったりすることはよくあります。 ですので、 意味のあるまとまり にすれば楽に理解できたり、修正できたりします。 （このことを「 保守性が高い 」といいます） ユーザクラス 一方、ログインしている・していない人は以下のように class xxxxUser{} を書きました。 一見ややこしく見えますが、このあとで良さが効いてきます。 ポイントは以下の通りです！ ログインしているユーザ、していないユーザも記事に対して"いいね"する関数 addLike() を持っている ログインしているユーザは、プロパティに ID とユーザ名を持っている 逆にログインしていないユーザは、ブログに登録していないので ID とユーザ名は持っていない <?php abstract class User { abstract public function addLike ( Article $ article ) ; } // ログインしているユーザ class LoginUser extends User { private int $ id ; private string $ name ; public function __construct ( int $ id , string $ name ) { $ this -> id = $ id ; $ this -> name = $ name ; } public function addLike ( Article $ article ) { // 記事にいいねを登録する $ article -> addLike ( $ this ) ; } } // ログインしていないユーザ class TempUser extends User { public function __construct () { // ログインしていないので、IDやユーザ名を持ちません } public function addLike ( Article $ article ) { // ログイン画面へ遷移する処理 } } // "ユーザ"を作るだけのクラス class UserFactory { public static function create ( ? int $ id , ? string $ name = null ) : User { $ user = null ; if ( is_null ( $ id )) { // ログインしていないユーザを作る $ user = new TempUser () ; } else { // ログインしているユーザを作る $ user = new LoginUser ( $ id , $ name ) ; } return $ user ; } } オブジェクト指向 の良いところ ここまでで、なんとなく良さそう・でも周りくどい書き方では、など色々思うところがあると思いますが、 オブジェクト指向 の良さを以下のキーワードを通して見ていきましょう。 1. カプセル化 2. 継承 3. ポリモーフィズム （ 多態性 ） カプセル化 カプセル化 は クラスの内部情報や操作を外部から見せないこと を指します。 1 プログラム上ではアクセス修飾子が実現してくれます。 PHP ではそれぞれ以下の違いがあります。 2 public どのプログラムからも呼び出せる protected 定義したクラス自体、子クラス、親クラスであれば呼び出せる private 定義したクラス内でのみ呼び出せる 今までお見せしたプログラムでは LoginUser クラスでアクセス修飾子を実は使い分けていました。 ( コメントアウト の ①,②) <?php class LoginUser extends User { private int $ id ; // ① private string $ name ; // ① public function __construct ( int $ id , string $ name ) // ② { $ this -> id = $ id ; $ this -> name = $ name ; } // 中略 LoginUser クラスは他のプログラムから呼び出そうとすると、 public をつけいてるコンスト ラク タと addLike() 関数しか呼び出せません。 プロパティ $id , $name は呼び出せません。 直接 $id を書き換えるシーンを想像してみてください。 ユーザを一意に特定する ID を書き換えるシーンは、ほとんどないと思います。 繰り返しになりますが、実務で扱うシステムは規模が大きいことが多いため、 内部仕様を完全に理解し記憶することはほとんどできません。 もし public で定義したプロパティを色々なプログラムで呼び出すと、 不具合が発生して修正するときに、 呼び出されている箇所をすべて調査し、関連するすべての操作や画面の仕様を理解する必要があります 。 また修正した場合に、呼び出されている箇所ですべてに対して修正前と同じ挙動になっているかを確認しないと、もしかすると 二次被害 で別の不具合が発生するかもしれません。 度々不具合が起きてしまうと利用者への信頼を失ってしまいます。 そのため、なるべくクラスの外で呼び出せるプロパティ・関数は少なくする →呼び出す側は内部情報を知らない →つまり カプセル化 したほうが、 保守性が高い のです。 継承 継承はより簡単にいうと、”引き継ぐ”という意味です。 ブログはログインしているユーザ、そうでないユーザが存在しますが、ログインの有無にかかわらず「”いいね”をする」という操作が存在します。 このように、 役割や立場は多少違うけれど共通の操作や情報を持つ ときは、継承を利用します。 前の章のプログラムを見返してみますと、User クラスの addLike() 関数が LoginUser , TempUser クラスに引き継がれています。 ポイントは「継承先クラスは継承元のアクセス修飾子が private 以外のプロパティ・関数であれば、 必ず 引き継ぐこと」です。 必ずがキモで、逆を言えば継承先クラスは必ず継承元のプロパティ・関数を持っています。 逆に持っていなければ、エラーとなるような制約もあります。 3 これでなにが嬉しくなるかですが、 結論からいうと開発や運用（利用者が不便なく使えるようにシステムを動かし続けること）をする人がシステムを理解し、どうプログラムを修正すればよいかがわかりやすくなります。 実業務ではほとんどの場合は、 1 つのシステムを複数人で開発したり運用したりします。 人によってそのシステムに対する仕様の理解度はまちまちです。 ですが、残念なことに開発には納期が決まっているのです。 限られた時間の中で、より早く必要な分システムを理解しなければなりません。 そのときに継承が使用されていれば、以下のように早くシステムを理解できます。 継承元クラスの役割を知ると、継承先クラスの役割がだいたい把握できる 継承先クラスの理解は、継承元との差分だけを確認すればよい 追加で継承先クラスを作成するときに、必要な関数を考える手間や書く手間を省ける ポリモーフィズム （ 多態性 ） ポリモーフィズム は今まで書いてきた クラスを利用する処理（=業務ロジックといいます） で良さがわかります。 <?php /***** 業務ロジック *****/ // 記事の投稿 $ article = new Article () ; $ article -> create () ; $ article -> publish ( "ブログのタイトル" , "ブログの本文" ) ; // 中略 // "いいね"をする $ user = UserFactory :: create ( $ id , $ name ) ; // ログインしている場合はID,ユーザ名が渡される $ user -> addLike ( $ article ) ; "いいね"をする処理をみてください。 ポイントは new をする処理がないことです。 引数にキーとなる情報（今回で言えば $id ）を UserFactory::create() という関数に渡しているだけです。 業務ロジックは、具体的にどのクラスを new する必要があるのか考える必要がなくなります。 次には 2 行目 addLike() ですが、ログインしているかどうかで 実際に実行される処理は異なります 。 ユーザはログインしていれば"いいね"ができ、ログインしていなければログイン画面へ遷移する処理が実行されます。 ではなぜ ポリモーフィズム が実現できているかですが、それには 継承 が関わっています。 4 もう一度ユーザに関連するプログラムを見てみましょう。 コメントアウト している ①②③ を順に見てください。 ① で User クラスを継承すると、②で定義された User クラスの関数を、③で $user が どのクラスかを意識することなく使用することができます 。 <?php abstract class User { abstract public function addLike ( Article $ article ) ; // ② } // ログインしているユーザ class LoginUser extends User // ① { private int $ id ; private string $ name ; public function __construct ( int $ id , string $ name ) { $ this -> id = $ id ; $ this -> name = $ name ; } public function addLike ( Article $ article ) { // 記事にいいねを登録する $ article -> addLike ( $ this ) ; } } // 中略 // "いいね"をする $ user = UserFactory :: create ( $ id , $ name ) ; $ user -> addLike ( $ article ) ; // ③ この 「やること（いいねをするという操作）」は決まっているけれど実際にどのように「処理」が実行されるかは隠蔽されている （業務ロジックで知る必要がない） ことを ポリモーフィズム （ 多態性 ）といいます。 おわりに 今回の例のようにすべて一人で書く場合は、プログラムの全容を理解しているので旨味は分かりづらいですが、実務では存在するすべてのプログラムを理解する機会はほぼないです。（時間がいくらあっても足りません） それなのに、そのシステムを修正するには修正する箇所のプログラムを理解する必要があります。 本内容から オブジェクト指向 を使うことで、"楽"にシステムを開発・運用することができるイメージを持てれば嬉しいです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com カプセル化 は人によって色々な意味合いを持つため今回はフォーカスを絞りました ↩ 最近の プログラミング言語 にはだいたいあると思いますが、言語ごとに仕様が異なります。筆者は Java を先に学んでいたので PHP との言語仕様の違いに戸惑いました。 ↩ この表現は正確ではありません。理解のしやすさのために 予約語 abstruct に触れていません。 ↩ この表現は正確ではありません。理解のしやすさのためにこのように表記しています。より厳密に言えば ポリモーフィズム という概念は継承という概念を含む概念です。 ↩

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」 というプロジェクトがあります。 以前、社外の方にこの取り組みについて紹介した際に好意的な反応を得られたので、この場でも紹介してみようと思います。 取り組みの発端 これまでの軌跡 継続のための試行錯誤 割り込み作業対策 認知度向上 取り組みのサイクル 大まかな進め方 おわりに ――この取組のつらみ 成果が出るまで時間がかかる 知見がいくらあっても足りない 取り組みの発端 ことの発端――と言っても何か目立った事件が起きたわけではないのですが、今から4年前の2017年2月に当時の開発部長（現在は開発本部長）の提案で、社内で比較的経験の長いエンジニア達が集められました。そこで ラク スの開発組織として技術的なノウハウ蓄積についての課題が語られ、それらについて ブレインストーミング する機会が生まれました。 かれこれ4年前の話なので、どういった議論が行われたのか詳細な内容は記憶に残っていないのですが、 ビールとつまみを用意して議論していたことは覚えています 以下のような議論をしていました。 新サービス立ち上げ時に新しい技術を使おうとしても時間的に余裕がない 新サービス立ち上げ自体が高リスクなので、技術面でのリスクを取れない 技術刷新行っていかないとエンジニア採用滞りそう 古い技術だらけになったら社内のエンジニアもやめていきそう 個人で使った経験があってもプロダクションレベルでの利用がないとリスキーと判断されがち とはいえ実サービスでは問題が出ない限りコストメリットの見えない技術刷新の優先度低い これらのことは結構どこの会社でも同じように抱えている悩みなのかな、と思います。 こういう議論を何度か繰り返した結果、 「普段から少しずつ検証しておくしかない」 という結論に至りました。 経営層もこういった課題感（特に人事面の課題（採用の停滞、エンジニアの流出）が強かったのではないかと 1 2 ）を共有してくれていたということもあり、4人で週1回午後を検証に充てる（＝週5時間）取り組みが始まりました。 これまでの軌跡 2017年5月ごろから サービス横断で集められた3名 のチームでスタート このときの検証テーマは「マイクロサービスの導入是非」 2017年10月ごろから 更に2名参加 2018年下期の半年間は 新サービス 立ち上げのために一時休止 2019年上期から活動を再開 再開時の検証テーマは「 あいまい検索の実現方法 」だったが、検証データを用意するために副次的に「 データ匿名化 」が必要になり、 2テーマ並行して検証 することに これまでは1テーマずつの検証だった 検証チームが2つに分かれ、 3人1チーム で検証 【データ匿名化】 tech-blog.rakus.co.jp ・ 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要 ・ 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？ ・ データ匿名化 第1回：匿名化された個人情報とは何なのか ・ データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？ ・ データ匿名化 第3回：個人情報を匿名化するプロセス ・ データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは ・ データ匿名化 第5回：データ匿名化の指標 ・ データ匿名化 第6回：実際の匿名化 【 機械学習 プロジェクトの進め方】 ・ 失敗しない機械学習プロジェクトの進め方入門 2020年4月にプロジェクトを運営する課として組織化 プロジェクト名も「技術推進プロジェクト」に改名 同時検証テーマ数が更に増え、 年間で7テーマずつ検証 を進行 検証チームの人数も 2, 3人と削減 【 機械学習 プロジェクトの進め方 続】 tech-blog.rakus.co.jp ・ 機械学習をコモディティ化する AutoML ツールの評価 ・ 機械学習モデルを組み込んだ Web アプリを Python 初心者が作ってみた 【サービス分割を見越した ドメイン 層設計】 ・ サービス分割に備えたモノリス（モジュラーモノリスとかアグリゲートとか） 【無停止リリース】 ・ 無停止リリース実現にむけていろいろ考えてみた（途中経過） ・ 無停止リリースを試してみた ・ サービスを止めずにアップデートを行う無停止リリース構成の検証 【モバイル クロスプラットフォーム 】 ・ モバイルクロスプラットフォームの技術検証 【GraphQL】 ・ GraphQLのアプリケーションへの組み込みを考える 2021年も継続的に技術刷新中 【静的解析】 tech-blog.rakus.co.jp 【 CSS プラットフォーム】 ・ PostCSSは開発標準ツールになるのか検証しました 【ユーザー認証】 ・ 認証規格まとめ 2021年版 - OpenID Connect & FIDO と OAuth 2.0 や SAML との違い 【ドキュメントDB】 ・ MongoDBについて調査・検証しました 継続のための試行錯誤 検証自体は 時間が与えられた 検証に必要な予算が与えられた 小規模なシステムを AWS 上で構築するために必要なくらいの予算 内部事情を把握しているエンジニア が揃っていたので、最初こそ手探りでしたが概ね順調に進んでいました。 割り込み作業対策 しかしこの手の従来業務と並行した取り組みは「従来業務の割り込みが増えて立ち消えになっていく」という展開はよくある話です。 本取り組みでも「ある程度経験のある現場のエンジニア」が参加しているため従来業務の割り込みが発生することは懸念されていました。 対策としては（当時はオフィスにも余裕があり会議室も確保しやすかったので）午後の5時間会議室を1つ占拠して自席から離れて作業するといった対策を取りました。 こういう話で「業務に影響でないの？」と心配される方もいるかも知れませんが、有休で休んだりすることを考えれば半日いなくても業務に問題が出ることはないんですよね。最初から毎週5時間いないことがわかっていればスケジュールもそれに合わせて引くだけです。 認知度向上 各所からの協力を得るために取り組み自体を認知してもらう工夫もしました。 成果を社内に還元する都合上、検証プロジェクトが社内で動いていることを知っていてほしいのですが、当初はプロジェクト名が決まっていないため「あの件」とか言われていたり、そもそもこういった取り組みをしていることも一部のメンバーしか知らない状態でした。 とりあえず取り組みに名前をつけようということで付いた名前が「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 です。私が面白がって提案した名前がそのまま採用されました。 やはり 命名 というのは大事で、名前をつけたことで社内の開発部門以外（広報や人事の方や、製品企画の方）にも「かみせんプロジェクト」として取り組みが認知され、採用活動の惹きつけの際にも紹介してもらえるようになりました。 その後、運営する部署が出来たので部署名にあわせて「技術推進プロジェクト（通称：ぎすい）」と呼ばれるようになっていきます。 取り組みのサイクル 本取り組みは実際に検証を始める8ヶ月前から準備を行っています。 まずは先数年間に渡って会社として身につける必要がありそうな技術要素を 技術ロードマップ としてまとめます。これは各サービスで技術選定を担当している担当者に ヒアリ ングを行い、その結果を元に毎年更新しています。 技術ロードマップとしてまとめられた技術要素群はサービス開発の中で採用していけるのが理想ですが、すべてを即採用するというのは難しいです。 そこで各サービスの翌年度開発計画で扱われない技術要素を、技術推進プロジェクトの検証テーマとしてピックアップしています。 ピックアップされた検証テーマに必要な人員を見積もり、翌年度の人員稼働計画に組み込みます。 もしかしたら「随分準備に時間をかけているのだな」「こんなに準備に時間をかけてはコストがかかりすぎるのでは」と思う方もいるかも知れませんが、例えば突然各サービスのエンジニアの稼働を「来月から12%ほど（＝週5時間）捻出してほしい」と相談しても無理な話です。協力したくても出来ませんし、直接的に売上に直結するわけではない活動に直近の開発計画を曲げてでも参加させるというのは良くない選択です。 そのため弊社では、翌年度の計画を立てる段階で考慮してもらい、各サービスの機能開発を妨げないようにエンジニアに参加してもらうようにしています。 期間やコストはかかるやり方かもしれませんが、このようにした方が継続的に技術刷新を行うことができると考えています。 大まかな進め方 本プロジェクトは旗振り役として「技術推進課」という組織が存在しているものの、検証を行う主なメンバーとしては各サービスのエンジニアに横断的に参加してもらい、週5時間（＝約12%の人員稼働）を確保して検証を進めています。 先述の通り前年度から計画を立てて進めているので、各サービス開発チームから提供してもらう人的リソースはおおむね確保できた状態で検証を進めることが出来ています 3 。 このように時間をかけてでも「各サービスのエンジニアによる検証」にこだわるのは検証した成果をサービスに還元していくためです。検証のみをフルタイムで行う検証専任チームを作れば、検証時間の確保は確実に出来ますし、突発での検証テーマの組み換えも比較的容易になります。しかし、検証チームとサービス開発エンジニアが分離することで成果の共有や、取り組みの認知に課題が生まれます。 本プロジェクトのような先行検証の取り組みは成果が出るまで非常に時間がかかる取り組みです。 開発組織内の認知度や、成果の共有により生まれる有用性の認識がなければ、いつ廃れてしまってもおかしくはありません。実際に他社のエンジニアの方と話していると「過去に有志で取り取り組んでいたけどなくなっちゃった」といった声もよく聞きます。 検証成果がまとまってから実際に活用されるまでに年単位のタイムラグがあるので「成果発表」という形式には限界があります。しかし「経験者がチーム内にいる」という状況であれば（離職しなければ）チーム内にノウハウとして残りますし、必要となったときにノウハウを引き出してもらえます。 おわりに ――この取組のつらみ 成果が出るまで時間がかかる 4年前から種を蒔き始めて、最近少しずつ芽が出てきた感じです 4 。 扱うテーマ数を増やしたのは去年からなので、2年後くらいにはもっと成果が活用されていくのではないかな、と思っています。どうしても目に見える成果が出るのが数年後になってしまうのがこの手の取り組みの辛いところです。自分たちが取り組みの意義を信じて、各部署に意義を理解してもらって、粘り強く取り組んでいかなければなりません。 知見がいくらあっても足りない サービス拡大とともに検証すべき技術が増えていることもあり、取り組みの規模が大きくなっている事自体は良いのですが、旗振り役を担うメンバーが足りません。現在は旗振り役を担う技術推進課の実働メンバーは私を含めて2名（東京大阪1名ずつ）なので、東京大阪それぞれもう1人ずつ欲しいところです。 純粋に人的リソースが欲しいということもさることながら、知見の範囲が不足しています。 例えば、私の場合はこれまでのキャリアから要件定義、プロジェクトマネジメント、アーキテクト、フロントエンド、バックエンド、サービス運用とそれなりの範囲の知見はあるもののあくまで ウェブアプリケーション エンジニアとしてのキャリアが主軸なので、インフラやセキュリティに関する知識や勘所といったところにはあまり自信がありません 5 。社内のインフラエンジニアの方々に話を聞きながらなんとかやっていますが、不自由なくコミュニケーションできるレベルの実務知識はないと効率の悪さを感じます。 なので、アプリケーションもある程度理解しているインフラエンジニア経験がある人が「技術推進課」に参画してくれると助かるなぁ、と日々思っています 6 。 というわけで株式会社 ラク スでは一緒に働いてくれるエンジニアを募集しています。詳細はこの下の各種リンクからお願いします。カジュアル面談などで「この記事見て興味持ったよ」って言ってもらえると私のモチベーションが上がるかもしれません。 「技術推進プロジェクト」のこれまでの取り組みは、以下もご参考ください！ ◆ 技術 スペシャ リストへのインタビュー記事 career-recruit.rakus.co.jp ※2021/12/16時点での情報です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 career-recruit.rakus.co.jp イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com 採用コストは直接的なコストでも1人あたり数百万かかりますし、ノウハウの蓄積という意味でも長くいてもらった方が効率が良くなるはず。 ↩ マザーズ に上場して1年ちょっと経って開発メンバーもちらほら入れ替わっていたというのもあるのかも。 ↩ 実際には障害対応であったり、サービスの開発プロジェクトが佳境を迎えていたりすると参加できない週があったりはしますが、多少は「仕方のないこと」として割り切っています。 ↩ 計測できていないものも含めれば「この技術は使わない」と判断する材料として成果を活用している事例もあるので結構ありそうですが。「当面の間はマイクロサービス化しない」とか。 ↩ 自宅でESXiサーバー運用したり、壁内LAN工事したりといったことはしているものの本職のインフラエンジニアのような実務に即した知識はたりません……。セキュリティ知識もテクニカルエンジニア（情報セキュリティ）（現 情報セキュリティスペシャリスト ）くらいは持っていますが本職の方がいてほしい……。 ↩ 知見の不足という意味ではモバイルアプリの知識や、AIとか ブロックチェーン の知識なども足りていないのですが、現状ではインフラ知識不足が一番の課題領域。 ↩

こんにちは。 ラク スインフラ部門にて従事しているas119119です。 ユーザ名に119という数値を2回使用しておりますが、特段意味はございません。 アルファベット順でaが1番目、sが19番目だったので、便宜的に使用しているだけとなります。 裏を返せば、asasasというユーザ名となるわけです。早速主題から脱線してしまいました。 今回、こちらのブログでは、 「仮想化について主観的に考えてみた」と題して、今後より一層の一般化・汎用化が想定される技術である仮想化について割と自由かつ奔放に考察 を交えて取り上げてみます。 今回のブログ構成は以下の通りとなります。 1. 仮想化について 仮想化の利点①／コストカット 仮想化の利点②／拡張性 仮想化の利点③／保守性 仮想化の利点④／柔軟性 仮想化の利点⑤／運用管理の負荷軽減 2.ラクスにおける仮想化についての現状 3.仮想化関連製品及びツール Nutanix Zerto Docker Kubernetes 負荷分散 死活監視 スケーリング 4.今後の仮想化活用にむけて 5.まとめ・総括 1. 仮想化について ここでは仮想化という概念について主観的な形で内容をまとめてみます。 新しい技術が次々と登場するICT業界において、比較的新規性があるような印象があるが息の長い技術ともなりつつあるのが 仮想化 ではないかと考えております。 仮想化とは、一般的にはハードウェアリソースを抽象化する技術であるとされています。具体的には、1台の物理的なサーバ内部のハードウェアリソースを論理的に分割し、複数の仮想サーバを同時に動作させることを可能とするものです。このことから、より規模の大きなサービスやシステムで積極的に活用されている技術の一つとなっています。 論理的という表現がやや抽象度が高い印象があるのですが、仮想化については端的には物理的な資源を別の資源であるように扱えるということで、実体を偽ることのできる技術だと考えることができます。 仮想化技術も複雑化してきており、その種類も ・サーバ仮想化 ・ネットワーク仮想化 ・デスクトップ仮想化 ・ストレージ仮想化 ・アプリケーション仮想化 などの複数の分類が可能となっています。 本稿では、最も一般的なサーバ仮想化を主として扱っていきます。 サーバ仮想化のイメージ※物理サーバ上で2つの仮想サーバが動作 では、仮想化の利点をいくつか挙げてみます。 仮想化の利点①／コストカット 仮想化技術を採用する利点はいくつかありますが、まずはコストのカットを挙げることができます。 物理サーバで構築していた場合でも、仮想化技術によって論理的な分割をすることで 仮想マシン を構築することができれば、活用されていないCPUやメモリなどのリソースを最適利用することができ、結果物理サーバ台数の減少につながり、最終的にはコストの削減につながると言えます。 仮想化の利点②／拡張性 次に拡張性があるという点です。 仮想化技術によって分割されたサーバに対し、必要に応じてCPUやメモリ、サーバ自体についても容易に追加や削除が可能となっており、柔軟かつ拡張性の高いシステムの構築を実現することが可能となります。 仮想化の利点③／保守性 待機させていたサーバへ稼働していたOSをオンライン状態で切り替えることによって、システムを継続させたままメンテナンスをすることが可能となります。 仮想マシン の実体はファイル *1 となるので、バックアップを作成し、当バックアップファイルから同じ仮想環境の復元が可能となります。 これによって同一機能を必要とする仮想OSを短い時間で大量にデプロイすることが可能となります。これを利用した技術としては、オートスケール機能を挙げることができます。 仮想化の利点④／柔軟性 サーバ構築作業が柔軟に可能となるという点も利点の一つとなります。 構築する際の 仮想マシン （ゲスト）のOSについては、必ずしもホストOSと同じにする必要はないということからも柔軟性の高い技術です。 仮想化の利点⑤／運用管理の負荷軽減 運用管理の観点からは、物理サーバを運用する場合と比較し、管理における負担が軽減されます。 例えば、従来の物理サーバで機材メンテナンスを行う場合には、システム停止の為に関係各所に調整、メンテナンス時間も深夜帯になることもあり得ます。 一方、仮想化環境で構築されたシステムのメンテナンスはそこで稼働している仮想OSをオンラインで別の物理機に移行できますので、特に事前の調整も必要なく、いつでもメンテナンスすることが可能となります。 仮想化技術に関して上記5つの利点を抽出してみましたが、システム構築を実現する上で検討する必要があるのは、コストであるのは間違いないと言えます。 仮想化実現のために必要なハードウェアやソフトウェアは有償である場合が多いと言えますが、小規模なシステム構築や安価な物理サーバでシステムを構築する場合には、仮想化を採用したことによって逆にコストが割高になってしまうこともあり得ます。 初期投資を抑えるためにサービスの立ち上げは クラウド を選択する会社も多数出てきています。 クラウド を選択した場合、そのままシステムが肥大化すると逆にオンプレミスのシステムの方が安くなる分岐点が存在します。 その分岐点に達した時にオンプレミスに戻す際は仮想化を選択することでよりリーズナブルにシステムを集約、低コスト化を実現できることも忘れてはならないポイントとなります。 仮想化として事実上の標準となっている VMware 社製品や追随する製品であると個人的には考えているNutanix社製品、 VMware の仮想環境ベースでの活用を可能とするZerto製品など、各社製品とのコラボレーションや仮想化技術をベースとした新しいサービスが続々と登場してきており、今後しばらくは仮想化技術の活用がより加速化していくのではないかと予想されます。 こちらについては、項目3のところで取り上げます。 2. ラク スにおける仮想化についての現状 現在 ラク スにおいては、旗艦製品と位置付けることができる楽楽精算を筆頭に楽楽販売、楽楽明細、楽楽勤怠といった楽楽シリーズ、メールディーラ等の多様な製品群を擁しております。 これらの製品群において、仮想化がメイン基盤となっている商材もあるようですが、一部の商材においては物理機での構築や運用を主としており、仮想化技術の導入についてはこれからという商材も存在します。 一方、販売増に伴いシステム規模が拡大している商材においては、運用コストの低減、メンテナンスの容易さなどを加味すると仮想化の検討や導入を行う動きはより推進されていくことが予想されます。 3.仮想化関連製品及びツール 仮想化技術において既に 業界標準 となっていると言える VMware 製品が導入候補として挙げられるかと思いますが、昨今、仮想化関連製品も多様化を極めている状況であると言えます。 ここでは 個人的に別のプロジェクトでも扱ったことのある製品をはじめ、仮想化を取り巻く製品群の一部について取り上げ、考察してみたい と考えております。 仮想化プロダクトとして既に一般化している VMware 製品や Hyper-V については、敢えてこちらで取り上げることは致しません。 現在の個人的な業務範囲内においても、深く扱っている技術や商品であるというわけではありませんが、過去に別のプロジェクトに参画した際に扱った製品もあり、仮想化技術を取り扱う際に重要な商品及び技術ではないかという認識を持っているので、個人的な経験も含めてここで取り上げておきたいと思います。 Nutanix Nutanixは、米国発祥の クラウド ソフト会社 として2009年からサービスを開始し、日本市場には2012年より 日商 エレクトロニクスによって導入が開始されました。 Nutanixという名前は製品名としても使用されており、最先端のハイパーコンバージドインフラスト ラク チャ（HCI：Hyperconverged-infrastructure）と呼ばれています。 ハイパーコンバージドインフラスト ラク チャ（HCI）においては、物理的なストレージ筐体を不要とし、複数サーバ上のストレージを仮想的な共有ストレージとして利用できる点が一つの特長となっており、仮想サーバやストレージ、付随するネットワーク等をまとめて管理できることから、シンプルな構成管理を可能としています。 個人的には複数のカタカナ用語を連結されると意味が把握しにくいイメージがあるのですが、仮想化ベースのITソリューション提供会社であり、より多くの機能を一括的な形で提供された仮想化製品となります。 実際、私自身が ラク スへ入社する前にNutanixの担当者とお話をする機会があり、そこで質問をしてみたのですが、Nutanix製品の実体は、 VMWare 製品と同じようなサービスやソリューションを提供しているものといった認識で概ね間違いないとのことでした。 提供されているサービスとして、まず挙げられるのが、Nutanixのハードウェアです。 サーバのようなものですが、ブロックという単位で区切った1ユニットまたは2ユニットサイズの筐体の中にノードを1台から4台まで収納できます。 筐体自体には電源ユニットとファンのみが搭載され、 ファームウェア アップデートの手間を省いている点 が特徴の一つとなっています。 Nutanixのハードウェアイメージ※2Uの筐体 ここでNutanix的観点から定義されているノードという表現が少々難解なのですが、 ブレードサーバ に格納する各サーバ単位のことを指すようです。 各ノードには仮想化されたCPUやメモリ、独自機能によってストレージ化されたディスクを 保有 しており、わずか2ユニットのスペースに仮想化基盤の構築が可能となります。 また、こちらのノードはオンラインでのスケールアウトが可能となっています。 ノード関連の特徴として、 RAID を採用しておらず、ノード単体での管理が可能 であるという点があります。 ノード単体が破損した場合でも稼働の継続ができ、ノードはオンラインでの交換が可能であり、さらには交換後に自動データコピーによる復元機能もあるので、高い可用性機能が実装されていると言えます。 次に、 ソフトウェアで制御できる範囲が広い点が特徴 の一つとなります。 CPUとメモリの仮想化機能、ディスクストレージ化機能、リソース一元機能など多様な機能をNutanixの専用ソフトで管理することができます。 ノードごとに仮想基盤を分散させることで、ノードの自由な拡張やバックアップによる可用性を確保できるなどの柔軟性が高い点は、大きな特徴であると言えます。 このことをSoftware-defined *2 と呼ぶそうですが、ここでも個人的にはあまり意味の理解が容易ではないのですが、要するにソフトウェアによってNutanixが管理する多様な機能をコン トロール するといったニュアンスであると理解しました。 各機能の管理については、 GUI 形式のPrismと呼ばれるコントローラによって実現されています。 Prismにおいては、 VMware vSphere Clientで確認するような要領で ダッシュ ボードが実装され、CPU使用率、メモリ使用率、ディスク使用率、IOPS、帯域、遅延状況などを 見える化 し、障害状況も一発で確認可能なようです。同様に 仮想マシン の作成、削除、バックアップ等の設定も可能となり、統合管理機能の一元化を図っていると言えます。 上記から、Nutanixに関しては、ハードウェア筐体のみならず仮想化実現ツールを含めてAll in oneで提供されているサービスであるということが大きな特徴となります。 基本は VMware の仮想化ソフトに似ているが、多様な機能の一元管理が可能となっており、その利便性から今後より一般化していくのではないかと予想しております。 Zerto Zertoは、2009年に米国はボストンにおいて創業された企業で、現時点ではHP社の傘下に入っています。 主力製品はZerto IT Resilience Platformと呼ばれるもので、主に仮想化基盤向けのDR *3 対策ソフトに強みを発揮しています。 個人的にも前職で 仮想マシン のシステム移行作業へ従事していた際に使用していたプロダクトでした。 他製品と比較してもユーザーフレンドリーなWebUIが印象的で、移行作業自体も失敗することは稀なケースと言えるほどで、パフォーマンス的にもかなり安定した製品でした。 主観的に言えば、 VMware 製品ベースでの使用が想定されているようにも見受けられます。 個人的にも間接的に聞いた話では、 VMware 社側からのZerto製品への評価も高いらしいとのことで、今後一層重要度が増すDR対策製品・サービスとして デファクト のプロダクトとして主流となっていくのではないかと予想しております。 Zerto製品の最大の強みは、とりわけ仮想化における仮想環境の レプリケーション 機能である と言えます。 これは、 プライベートクラウド 、ハイブリット クラウド 、 パブリッククラウド 上の異なるストレージ間や、異なるハイパーバイザー間でも レプリケーション が可能なことを売りにしていることからも伺い知ることができます。 前職で参画したプロジェクトにて扱った際にもサーバのハードウェア保守期限切れ対策として実施した マイグレーション 時に大きな効力を発揮しておりました。 Zerto主要機能の一つである Zerto Virtual Replicationの特徴 について取り上げたいと思います。 基本的な機能としては、仮想環境のレプリカ作成となります。 想定状況は多岐に渡るかと思いますが、例えば災害発生時などに仮想環境において稼働するサーバを素早く別のプラットフォームへ移行することで、サービス停止を回避する対策として用いられることが多いようです。 また、昨今、目に付くようになってきた ランサムウェア 対策としても有効性があるように見受けられます。 ランサムウェア によってサーバへのアクセスが制限された場合、 レプリケーション 機能を用いて仮想環境を復元することによって、データへのアクセスを可能とする手法も用途の一つとしてあるようです。 いずれにしても、サービス可用性の確保という昨今における最大の課題への対処製品としても有効なプロダクトと言えるのではないかと考えます。 Zerto一般情報によると、 レプリケーション 時には、 VMware vSphere、 Hyper-V 、 IBM Cloud（ベアメタル）、 AWS 、 Microsoft Azure間での利用ができ、異なる仮想環境間においてもプラットフォームに依存しない柔軟なデータの保護が可能となっているそうです。 実際には、 VMware vSphere上で使用するケースが多いのではないかと思いますが、多様な仮想環境下において互換性の高いサービスとなっています。 実際に VM の仮想化環境で利用したケースで考えると、ESXiホストにVRA *4 、vCenterへの紐づけが必要なZVM *5 のインストールが必要という状況でした。 これ以外には特に複雑な設定作業等は発生しなかったと記憶しております。 Zerto移行時のイメージ 次に、実際に参画プロジェクトにて実施したプラットフォーム間の移行作業について簡潔に触れてみたいと思います。 私が参画したプロジェクトでは、基本的に VMware 環境の 仮想マシン を別のESXiへ移行する際にZertoを移行ツールとして用いていたのですが、作業自体は通常2日間のスケジュール感で実施しておりました。 初日は、当時の現場では事前同期を実施する日として位置付けられ、ZertoにおけるVPGの作成日として設定されていました。 VPG（Virtual Protection Group）というのは、 リカバリ ーサイト（移行先）での復旧の単位であるとされています。 例えば、移行時に移行グループを作成して複数の 仮想マシン を分類し、まとめて処理できる機能があるようです。 ただ、私が参画したプロジェクトの現場では 仮想マシン のグルーピングはせずに、1台単位でVPGを作成して移行を実施しておりました。 その意味で、当時の現場では、VPG作成というのは単に本番移行実施前の事前同期を作成するといったものが一般的な認識となっておりました。 他方で、同日に複数のVPG作成が必要な場合もあり、1アカウントで6パラ（6チーム体制）にて6種類のVPG作成を実施した実績もありました。 しかしながら同時並行による影響のためか、VPG作成自体は問題なく完了しましたが、各VPG作成に当初の想定以上の時間を要したこともあったため、同じアカウントでの多数同時並行でのVPG作成作業は可能な限り避けるのが無難であると言えそうです。 ディスク容量の大きい 仮想マシン については、VPG作成が完了するまでに時間を要することが多く、午前中にVPG作成作業を実施、そのまま放置し翌日に作成が完了したことを確認するなどということもありました。 他方で容量が少ないものに関してはVPG作成も短時間で完了し、そのまま同日に移行作業自体を続行することも可能でしたが、顧客と移行スケジュールを調整済みとなるため、VPG作成日と本番移行日は別日で実施するのが通例となっておりました。 Zerto上での操作はVPG作成や本番移行を含めて基本的には全て GUI 形式のインターフェースで非常に操作が容易であった記憶があります。 プロジェクト内において通常は事前に設定値を記載したパラメータシートを仮想環境ごとに作成し、当シートを元に作業を進める形となっておりました。 蛇足ですがこのパラメータシートがかなりの曲者でして、入力項目が多岐に渡る上、移行対象が多数となる場合には、シート自体の デグレ や更新漏れ等が発生し、場合によっては移行当日にパラメータ内容を修正（レビュー済みであるにもかかわらず）といったこともありました。 状況によって柔軟に対応することも必要ということを痛感するとともに、Zerto製品の使いやすさによって設定値の間違いに気づけたことについても思い起こしました。 VPG作成時における設定値最終確認画面のイメージ VPG作成中のイメージ※State欄で進捗状況の確認が可能です 無事にVPGの作成が完了すると、翌日にはいよいよ本番移行を迎えます。 VPG作成自体は 仮想マシン を停止させる必要はなく、作成に何時間要したとしてもサービス停止は発生しないのですが、本番移行を実施する際にはサービス停止を伴います。 そのため、サービス停止の許容時間やマストのサービス再開時間を想定した上でスケジュールを立てなくてはなりません。 Zertoを利用した移行時では発生件数自体は僅かであった記憶がありますが、他方、他社製品を利用した移行時に移行先環境で正常に 仮想マシン を起動させることができず、結果ステップバックと呼ばれる移行前の状態への切り戻しが必要となる事態も発生しました。 その意味でZerto マイグレーション 機能は VMware 仮想環境の移行において相性がよく、移行作業時における安定性が高い印象を受けました。 本番移行については、同じくZertoの GUI 画面にて、下段の「Actions」から「Move VPGs」を選択します。 前提作業としては 仮想マシン の停止が必要となります。 この本番移行作業は前日に作成したVPGの実際の移行を行なうものとなり、前日のVPG作成時点からの本番移行作業における差分同期もセットで実施する形となります。 よって、通常はVPG作成後の翌日に移行を実施すれば同期すべき差分は最小で済み、実際の本番移行にそれほど時間を要しないため、VPG作成時点からMove VPGs実施までの間隔は可能な限り短縮すべきであると言えます。 VPG作成からMove VPGs実施までに何日も空いてしまうとそれだけ多くのデータ差分が発生するので、本番移行作業も時間がかかってしまう結果となるためです。 本番移行実施イメージ 無事に本番移行作業が完了すると、移行先の環境にて 仮想マシン がパワーオンの状態で立ち上がってきます。 その後は新環境に合わせて ネットワークアダプタ の修正を含む各種設定変更を実施し、旧環境からの移行が完了となります。 Zerto製品は非常にシンプルかつ安定性があり、障害発生が少なく高いパフォーマンス性能を備えたプロダクトとして、またDR対策製品としても、今後普及が加速化していくのではないかと予想しています。 Docker Dockerは、コンテナ型仮想化の代表的なソフトで2013年に登場しました。 一般的にはコンテナの実行やコンテナイメージの作成や配布を実行するためのプラットフォームであるされています。 コンテナ自体はOS上で実行されているプロセスのことを指し、それゆえOS上で共有されることになるため、OSのバージョン等による差分が発生した場合に動作しない等の影響を受ける場合があります。 コンテナ型とは、サーバ仮想化の一類型のことで、アプリケーションと実行環境をひとまとめにし、OS単位ではなくアプリケーション単位で仮想化を実現する仕組みのことを指します。 仮想マシン やゲストOSが不要となるというメリットがあり、ホストOS上にコンテナ型仮想化ソフトウェアをインストールすることでコンテナ同士を組み合わせて使用することも可能となります。 コンテナ型仮想化のイメージ※ゲストOS不要 一般的にデータはコンテナに含めないことで使用されることになるため、アプリケーション用のコンテナを破棄してもデータ自体が喪失することはなく、新しいコンテナを作成することでデータの継続的な使用が可能となります。 Dockerはコンテナ技術の デファクトスタンダード ツールであるとされ、設計思想としてユーザーファーストを掲げている通り、一般的には使用しやすいというフィードバックも多いようです。 その理由としては、オンプレミスから クラウド への移行が容易であったり、高い可用性及び有用性からアプリケーションを開発しやすいプラットフォームである点が挙げられています。 また、Docker Hubと呼ばれるライブラリのようなアプリケーション導入済みのコンテナイメージを集めたサービスも豊富に提供されており、必要なコンテナは容易に入手可能となっています。 Docker Hubについてですが、これはDocker社提供のコンテナ レジストリ サービスのことであり、ここからコンテナイメージの取得及びソフトウェア実行が可能となっています。 コンテナ レジストリ というのは、Dockerにて使用するコンテナイメージの保管および配布を担う構成要素のようなものとなります。 上記の通り、コンテナはその実体はプロセスであるがゆえ、プロセスごとにコンテナを分類することが推奨されています。 これは、分類することによって、負荷分散によってパフォーマンス低下の改善や共有プロセスへ同時にアクセスすることによる競合状態の発生回避にも寄与できるためであるとされています。 他方、コンテナが分類されることでシステムによっては増加した複数コンテナの管理が複雑かつ困難となったり、1つのシステムにパッチ適用をする場合などに、コンテナごとに対応が必要になったりするなどの煩雑さが発生するというデメリットもあります。 増加し過ぎたコンテナ管理の問題に対応するために、Swarm modeと呼ばれる クラスタ 管理機能も備えています。 Swarm とは日本語で言うところの「群れ」のことであり、Swarm modeで有効・無効を選択し、有効とされたノード群を クラスタ としての集合体として管理することが可能となります。 Web系システムのコンテナイメージ コンテナの管理については、コンテナの作成や削除による方法がありますが、削除する際には注意が必要となります。 コンテナ自体を削除すると、コンテナ上のデータも消えてしまうためです。 対処方法としては。Dockerに備えられた「ボリューム」と呼ばれる機能を使用することが考えられます。 ボリュームというのは、Dockerが管理する ディレクト リのようなものであり、通常の ファイルシステム と同様に名前での管理が可能であり、複数コンテナにデータを配布するなどのマウント機能も備えています。 またこのボリューム機能を使用すれば、複数コンテナでの ファイルシステム 共有も可能となります。 Dockerの機能の一つとして、コンテナを実行するためのテンプレートであるコンテナイメージの中にある ファイルシステム に「差分管理」という仕組みがあります。 これは、マスター的な情報がベースとしてあり、そのマスターとの差分点を記録することによって変更内容を管理する手法であり、これによりファイルの高速なデプロイを実現しています。 Kubernetes Kubernetes はDockerと同様にコンテナ型の仮想化ソフトの一種として、Dockerより1年遅れの2014年に登場しました。 開発したのは Google 社であるとされています。 なお、 Kubernetes というのは ギリシャ 語で「操縦士」という意味があるそうです。 コンテナ オーケストレーション ツール *6 とも呼ばれている通り、コンテナの指揮が可能ということで、自動化することによってコンテナの管理及び運用を容易化するものとされています。 コンテナの運用管理における必要な作業としては、 負荷分散、死活監視、スケーリングの3種類 を挙げることができます。 負荷分散 負荷分散については、複数コンテナがある場合に特定のコンテナへのリク エス トが集中しないようにする処理のことを指します。これにより処理時間の短縮や単位時間あたりに処理可能なリク エス ト数を増加させ、システム性能向上へ寄与します。 死活監視 死活監視については、コンテナが正常に稼働しているかを確認及び監視する機能のことを指します。 死活監視の方法としては、各コンテナへリク エス トを送信し、返答の有無を確認する手法があります。返答がある場合には正常稼働していると判断できるため、 Ping 疎通確認のようなものと同様であると言えます。 スケーリング スケーリングについては、コンテナへのリク エス トの規模に応じてコンテナ数を増減させることを可能とする機能です。 例えば、CPUやメモリ等に 閾値 を設定し、ある基準を超える場合にはコンテナを追加するといったような設定が可能となります。 Kubernetes がコンテナ管理をする上で、最小となる単位のこと「Pod」と呼びます。 1つのPod内では複数のコンテナ起動が可能となります。この複数のコンテナ起動管理を可能とするのが、 Kubernetes の特徴の一つであると言えます。 他方で、同じタイミングでの起動が必要ではないコンテナは別のPodで管理するのが効率的であるとも言えます。 また、各Podをグループ化して管理する単位のことを「レプリカセット」、レプリカセットをグループ化して管理する単位のことを「デプロイメント」と呼びます。 Pod、レプリカセット、デプロイメント対応関係イメージ Kubernetes のコンテナへのアクセスを実現するのは、「サービス」という機能です。 サービスは、コンテナへアクセスするためのエンドポイントを提供する役割を担っています。 エンドポイントは仮想の IPアドレス を持っており、当仮想 IPアドレス へアクセスすることで、エンドポイントにてコンテナの仮想 IPアドレス への変換が行われ、コンテナへのアクセスが可能となります。 エンドポイントはいわば、各コンテナへのアクセスの仲介を行なっている機能であると言えます。 また、サービスには負荷分散の機能も実装されています。 ラウンドロビン 方式で各Podへのパケット転送をサービスが制御することで、負荷を分散し、サービス可用性を高めています。 Pod内に複数のコンテナを 保有 している場合、コンテナ間の通信は localhost にて可能となります。 他方、Pod間通信にはPodに割り当てられた一意の仮想 IPアドレス を介して実行されます。 コンテナという手法に関しては、仮想化技術の中でも比較的新しい範疇に分類されるのではないかと思います。 Dockerが誕生してから僅か1年後に管理機能を向上させるように Kubernetes が登場してきたように非常にスピーディなペースで次々と新たなものが開発されてきている分野であるという印象を持っており、今後、更にコンテナの進化版のような技術が登場することになるのではないかと予測しております。 4.今後の仮想化活用にむけて 今後、仮想化環境をメインプラットフォームとする方向性へシフトしていく可能性は十分にあり、むしろかなり高い確率でそうなっていくのではないかと予想しております。 運用面で考えると本質的には物理環境と仮想環境で大きな差分はなく、仮想サーバが1台でもあれば、オンプレミスと近い運用設計が必要となります。 オンプレミスでの運用管理方法をそのまま再利用とまではならないまでも、これまでの運用方法を参考にしながら仮想化環境の運用方法を再設計することも可能となるのではないかと考えます。 コスト的な観点では物理サーバに対して仮想サーバが安価であることは一般的な共通認識であると言えます。 他方で、安価な物理サーバを利用した運用を実施する場合、必ずしも仮想サーバが常に優位な選択肢であるとは限らない場合があるというのも事実です。 仮想化導入時に プロプライエタリ な製品等の導入を選択肢とする場合、費用対効果を含め多様な視点から比較したうえで仮想化技術を導入すべきなのかを検討することが重要です。 パフォーマンスの安定性を考慮する場合は仮想化技術の導入を無思慮に推進するよりも、物理サーバでの安定した性能を追求する手法も一つの手段です。仮想化を推進する際、オンプレミスなシステムと性能を比較した場合、性能はオンプレミスよりも劣る場合があることは考慮が必要な点となります。 パンデミック など、昨今の予想できない事態の発生に備え、リモートワーク等を含めて遠隔で操作するVDI、 リモートデスクトップ の仮想化といった手法の採用も一般化しています。 その潮流の一環として、仮想化技術の活用も有効な選択肢の一つとなっていくのではないでしょうか。 5.まとめ・総括 いかがでしたでしょうか。 ここまで仮想化について個人の主観的な視点に依拠して奔放闊達な形で考えてみた内容を記述してきました。 仮想化の デファクトスタンダード とされる VMware 社製品のみならず、 VMware 製品と類似する機能を強化してAll in oneとリニアにスケールする性能を提供するNutanix製品、 VMware と合わせて利用されることで効果を発揮すると思われるZerto移行ツールなど、ソフトウェアの形態も多種多様に変化してきていると言えます。 それほど昨今の技術進化のスピードは著しく、ICT業界従事者としては常に動きをウォッチすることが求められていることには変わりなく、この風潮は一層加加速化しうると言うこともできるかと思います。 仮想化技術自体は一定の市民権を獲得しているようにも思われ、とりわけ VMware 製品が築いた牙城はそう簡単には崩壊しないのではないかとも言えます。 Nutanix製品が仮想化製品として VMware 製品にとって代わることがあれば、個人的には興味深いことであると思っております。 新しい技術や製品は最初に開発した事業体が大きなシェアを占めることになるのは明白であり、どれほど模倣に長けた企業であっても二番煎じの位置から秀でるのは容易なことではないと考えられます。 それを踏まえると、標準化された製品をベースに如何に更なる利便性を高めて、付加価値のあるサービスを提供できる技術、とりわけ クラウド との連携によるハイブリットDC化が次の動向となっていくのではないかと思われます。 仮想化関連技術に関して言えば、前述したZerto製品のように今後は仮想化技術とその他商品とのコラボレーション的な活用方法も、仮想化技術の主流の一つとなっていくのではないかと予想しております。 当ブログを最後まで読んでいただき、ありがとうございました。 ◆ 関連する求人情報はこちら！ ・ インフラエンジニア／マネージャー（東京） | 株式会社ラクス ・ インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス ・ インフラエンジニア[東京/楽楽明細] | 株式会社ラクス ・ インフラエンジニア（大阪） | 株式会社ラクス ・ インフラエンジニア[東京/楽楽労務] | 株式会社ラクス ・ SREエンジニア[東京/インフラ] | 株式会社ラクス ※2021/12/15時点での情報です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 一つのファイルとしてパッケージ化して扱うことを カプセル化 と呼びます *2 : 「ソフトウェア的に定義」といった意味合いになる認識です *3 : Disaster Recovery：災害時におけるシステム復旧の仕組みや体制のこと *4 : Virtual Replication Appliance： レプリケーション に必要なエージェントのようなもの *5 : Zerto Virtual Manager： レプリケーション 管理用のソフトウェア *6 : コンテナの管理運用を自動化するツールという意味合いがあります

注意 カスケードレイヤーは正式実装の機能ではないため、これから仕様変更の可能性があります。 目次 注意 目次 はじめに カスケードについて Origin and Importance Context Specificity Order of Appearance カスケードレイヤーについて The Style Attribute Layers 従来のCSS カスケードレイヤーの記述方法について 複数レイヤー 使用例（リファクタリング） 修正前のコード リファクタリングの準備 FLOCSS化 リファクタリング後 カスケードレイヤーをブラウザで使う方法 Windows Mac 注意 最後に 参考 はじめに こんにちは、フロントエンドチームのta_kameです。 今回は、今後実装されるかもしれない CSS の新機能カスケードレイヤー（ Cascade Layers）について紹介します。 CSS 設計では詳細度をなるべく均一に保つよう行いたいですが、 レガシー案件であったり、 サードパーティー の CSS が導入されている案件だと、 なかなか管理が大変です。 そこで紹介したいのがカスケードレイヤーです。 カスケードについて そもそもカスケードとは何か、ということになりますが、簡単に言うと、スタイルを適用するための優先順位のルールをまとめたものになります。 CSS ファイルを複数読み込んだり、同 CSS ファイル内でも複数箇所で書かれていたり、そういった場合どのスタイルが適用されるのか…ということです。一番よく気にする機会は詳細度かもしれません。 詳細度以外ではとくに意識することは少ないかもしれませんが、カスケードレイヤーについて紹介する前にまずは現在の仕様について確認してみます。 現在の CSS が適用される優先順位を決めるためのカスケードのルールはこちらです。 Origin and Importance Context Specificity Order of Appearance 英語の記述をそのまま引用してきたために、このままではわかりづらいので、1つずつ説明します。 Origin and Importance Originとはユーザーエージェント スタイルシート 、ページ作成者 スタイルシート 、ユーザー スタイルシート など、スタイルがどこで宣言されているかを示しています。 そしてImportanceとは CSS に記述する!importantのことです。 Origin and Importanceとはそれらの組み合わせの優先順位によるもので、下記の優先順位で適用されます。 トランジション ユーザーエージェント (!important) ユーザー (!important) 作成者 (!important) アニメーション 作成者 (通常） ユーザー (通常） ユーザーエージェント (通常） Context ContextとはShadow DOMなどのネストされたコンテキストの優先順位です。 異なる カプセル化 されたコンテキストからの宣言では、下記のルールで優先されます。 通常：外部コンテキストからの宣言が優先 important：内部コンテキストからの宣言が優先 言い換えると通常の宣言同士であれば外側から容易に書き換えることができるが、内側のimportantは外側からは書き換えられないということになります。 Specificity 詳細度による優先順位です。 ID セレクタ ーや要素 セレクタ ーなどの種類や数によって、一番詳細度の高い宣言が優先されます。 Order of Appearance 宣言が登場する順番による優先順位です。 ドキュメントの後ろの方で登場した宣言が優先されます。 カスケードレイヤーについて カスケードレイヤーが実装された場合のカスケードのルールは下記の通りになります。 Origin and Importance Context The Style Attribute Layers Specificity Order of Appearance The Style Attribute style属性の優先順位です。 現在style属性は Order of Appearance内 で定義されており、すべての スタイルシート のあとに宣言されるとされています。 カスケードレイヤー実装のタイミングではわかりやすく、 独立 となるようです。 Layers カスケードレイヤーは 新設 で配置されます。 カスケードレイヤーにより詳細度や登場順の影響を受けることなく、制御ができることになります。 従来の CSS 従来のカスケードのルールとカスケードレイヤーが実装された場合の違いを確認したところで、まずは従来の CSS のサンプルコードを紹介します。 < main id = "container" > < div class = "block" > < p class = "text" > カスケードレイヤー </ p > </ div > </ main > # container . block . text { color : blue ; } p { color : red ; } 大げさに詳細度を高めていますが、こちらは当然テキストのスタイルは 青 です。 カスケードレイヤーの記述方法について それではカスケードレイヤーを使用してみましょう。 具体的な記述方法ですが、@layerのあとに好きなレイヤー名をつけて、その中にスタイルを書いていくだけです。 @layer main { # container . block . text { color : blue ; } } p { color : red ; } color:blueの方が詳細度は明らかに高くみえますが、テキストは 赤 です。 つまり レイヤー化されていないスタイルが一番強くなります 。 詳細度がいくら高くても関係なく、レイヤー順の方が優先されます。 複数レイヤー レイヤーは複数記述することも可能です。 先にレイヤー名を宣言しておくと、順番を並び替えるだけでスタイルが適用されるので、より管理が楽になります。 @layer main ; @layer second; @layer main { # container . block . text { color : blue ; } } @layer second { # container . block . text { color : green ; } } 最初の宣言で@layer secondが後に宣言されているので テキストは 緑 です。 ここでmainレイヤーとsecondレイヤーの宣言を逆にしてみます。 @layer second; @layer main ; @layer main { # container . block . text { color : blue ; } } @layer second { # container . block . text { color : green ; } } すると、この場合のテキストは 青 になります。 現在mainレイヤーがあとに宣言されているのでmainレイヤーのスタイルがあたっています。 もしmainとsecondの別々のレイヤーで詳細度がそれぞれ異なる場合はどうなるでしょうか。 ためしにmainレイヤーの詳細度を下げてみます。 @layer second; @layer main ; @layer main { p { color : blue ; } } @layer second { # container . block . text { color : green ; } } 少し違和感があるかもしれませんが、 この場合でもテキストは 青 になります。 詳細度よりとにかくレイヤー順の方が優先されます。 使用例（ リファクタリング ） ※ リファクタリング 後の CSS は後述する起動オプション付きでブラウザを実行しないとスタイルが適用されませんのでご注意ください。 それではカスケードレイヤーはどのような場面で活躍するか…今回はカスケードレイヤー設計の観点で考えてみます。 たとえば、既存プロジェクトで大きな CSS ファイルがあるとします。 ファイルを分割したいと思うのですが、まずは1ファイル内で安全に行うべく、カスケードレイヤーを使用して リファクタリング を試みます。 そこで多少ひどい CSS をここに用意しました。 修正前のコード こちらのHTMLと CSS を使って、 CSS の リファクタリング を行っていきます。 リファクタリング の準備 まず、今回機能として紹介していませんが@importで CSS 内に別の CSS を読み込むことができます。 @import はすでに 実装済 みの機能ですが、カスケードレイヤーと組み合わせると名前付きでimportが可能となります。せっかくなのでHTMLでは1つの CSS を読み込むようにして、名前付きimportしてみます。 そして、いったん リファクタリング 用のレイヤーに既存の CSS をすべて入れます。 余談ですが、 CSS の@importはパラレルロードではないため、 CSS 設計を考える段階でSassの導入を検討してみてもよいかもしれません。今回はあくまでPureCSSということを前提としています。 @import url( https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css ) layer(normalize); @layer refactoring { body { font-size : 16px ; } # header { padding : 20px ; } # header . logo { height : 50px ; width : 200px ; background-color : blue ; color : #fff ; display : table ; } # header . logo span { vertical-align : middle ; display : table-cell ; text-align : center ; } . headline1 , . headline2 , . headline3 , . title { font-weight : bold ; } h4 . title { font-weight : 500 ; } . container { padding : 16px ; } . container . list { list-style : circle ; } . container . list . item { letter-spacing : 1px ; } . container . list . item : nth-child( 2 ) { color : red ; } . container . box { display : flex; flex-wrap: wrap; } . container . box . media { padding : 8px ; margin : 4px ; width : calc( 50 % - 8px ) !important ; box-sizing : border-box ; background-color : yellow ; } . container . box . media . img { width : 100 %; height : 100px ; background-color : green ; } } FLOCSS化 ここからFLOCSS化します。 まずはHTMLにクラスを付与するのですが、ためしにlist部分へ手を入れます。 < h2 class = "headline1 c-headline1" > LIST </ h2 > < ul class = "list c-list" > < li class = "item c-list__item" > HTML </ li > < li class = "item c-list__item c-list__item--em" > CSS </ li > < li class = "item c-list__item" > JavaScript </ li > </ ul > クラスを足しただけなので、何も変わりません。 そこにカスケードレイヤーを足します。 @layer c-list; /* ① */ @layer refactoring; /* ② */ @layer refactoring { ... } @layer c-list { . c-list { list-style : circle ; } . c-list__item { letter-spacing : 1px ; } . c-list__item--em { color : blue ; } } 試しにc-list__item--emへcolor:blueのスタイルを適用させようとしていますが、 現在の状態はrefactoringレイヤーの方があとに宣言されているので結局何も変わりません。 何も変わっていないことが確認できたので、①と②を入れ替えます。 @layer refactoring; /* ① */ @layer c-list; /* ② */ c-listレイヤーのスタイルが適用されました。 うまくいっているので、同様に切り分けながら リファクタリング を進めます。 どこまで分割するかという問題があるかもしれませんが、今回は以下のようなコードになりました。 リファクタリング 後 ※後述の起動オプション付きでブラウザを実行しないとスタイルが適用されないのでご注意ください。 1つの css ファイル内で分割が完了しました。 ここからファイルを分割していき、@importを使用して読み込むようにすれば完成となります。 カスケードレイヤーをブラウザで使う方法 使い方ですが、現在実験的機能のため Firefox Nightlyか Google Canaryでしか試すことができません。 起動オプションを設定して実行すると使えるようになりますのでご紹介します。 Windows Windows はショートカットのプロパティに起動オプションを追加して実行するだけで使えるようになります。 "C:\Users\username\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --enable-blink-features=CSSCascadeLayers 画像のように「サポートされていない コマンドライン フラグ --enable-blink-features=CSSCascadeLayersを使用しています。 これにより安全性とセキュリティが損なわれます。」と表示されていたらカスケードレイヤーが使えるようになっています。 Mac Mac の場合はターミナルから起動します。通常起動は下記コマンドで実行できます。 open -a /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary こちらに起動オプションを追加して実行します。 open -a /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --args --enable-blink-features=CSSCascadeLayers Windows と同様にメッセージが表示されていればカスケードレイヤーが使用できるようになっています。 また、毎回コマンド入力するのは手間なので、よく使う場合は Automator の設定を行います。 Automator はLaunchpadから起動できます。 「 シェルスクリプト を実行」から、起動オプション付きのコードを貼り付けます。 完了しましたら、メニューバーより「ファイル」→「保存」を選択して保存します。 この時フォーマットは「アプリケーション」としておきます。 これで次回以降はアイコンをクリックするだけで起動オプション付きの Chrome Canaryが実行できます。 注意 開発者向けの機能のため、ブラウザが意図しない挙動をするかもしれないので、使用についてはあくまで機能の確認程度に留めていた方がいいかもしれません。 最後に 今回はカスケードレイヤー(@layer)について紹介しました。 まだ実験的機能としてですが、カスケードレイヤーが CSS 設計や リファクタリング で活躍する日がくるかもしれません。 Sassのような記述ができる CSS ネスティングや、条件分岐ができるwhenなど、 CSS には他にも実装が期待されている機能はたくさんあります。 興味のある方はぜひ調べてみてくださいね。 参考 Cascade Layers? - CSS-Tricks The Future of CSS: Cascade Layers (CSS @layer) – Bram.us CSSのCascadingに追加されようとしているLayerという概念 CSS Cascading and Inheritance Level 4 CSS カスケード入門 - CSS: カスケーディングスタイルシート | MDN Takao Kamenoue エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 Windows の真っ黒い画面、「 コマンドプロンプト 」を聞いたこと・触ったことはありますでしょうか？ 中々触る機会が少ない方にとっては、抵抗のある画面ですよね…。 今回は、そんな抵抗をお持ちの方に向けに、 「 コマンドプロンプト 」について起動方法や基本的なコマンドをまとめさせていただきました！ コマンドプロンプトとは？ コマンドプロンプトの起動方法 プロパティの設定 オプション フォント レイアウト 画面の色 ターミナル 基本的なコマンド一覧 ファイル・ディレクトリ操作 実行結果例 OS操作 実行結果例 ネットワーク操作 コマンドプロンプト まとめ コマンドプロンプト とは？ コマンドプロンプト は、 Windows 上の「 コマンドプロンプト 」の画面を起動し、 「コマンド」と呼ばれる命令文を入力して操作するものです。 通常マウスを使って操作しているものを、キーボードを使って操作するインターフェースです。 ちなみにこれを CUI （Character User Interface ）とも言います。 後程、基本的なコマンド一覧をまとめておりますので実際にご自身のPCで操作を試してみてください！ コマンドプロンプト の起動方法 では早速、 コマンドプロンプト の起動方法についてご説明します。 コマンドプロンプト を起動する方法は、4通りありますので使いやすい方法をお選びください！ ① アプリ一覧から起動 ■ デスクトップ左下のスタートボタンをクリック ■ [ Windows システムツール]から[ コマンドプロンプト ]をクリック ■ [ コマンドプロンプト ]が起動 ② 「ファイル名を指定して実行する」から起動 ■ デスクトップ左下のスタートボタンをクリック ※[ Windowsキー ]＋[R]キーにて、「ファイル名を指定して実行」ダイアログを表示することも可能です。 ■ [ Windows システムツール]から[ファイル名を指定して実行]をクリック ■ ダイアログが表示されたら、[cmd]と入力 ■ [ コマンドプロンプト ]が起動 ③ 検索ボックスから起動 ■ デスクトップ左下の検索ボックスに[cmd] or [ コマンドプロンプト ]と入力 ④ ショートカットキーで起動 ■ [ Windowsキー ]＋[X]キーにて表示したダイアログから、[ コマンドプロンプト ]を起動 プロパティの設定 次に、 コマンドプロンプト のプロパティについて説明します。 ここでは、「オプション」「フォント」「レイアウト」「画面の色」の設定を変更することが可能です！ まず、[" コマンドプロンプト "のプロパティ]を以下の手順で開きます。 ■ [ コマンドプロンプト ]画面の左上にあるアイコンを右クリック ■ [プロパティ]をクリック オプション 【 出来ること 】 ・カーソルのサイズ　：カーソルの大きさを小/中/大に変更可能 ・コマンドの履歴　　：バッファーサイズ/バッファー数、古い履歴の破棄の設定 ・編集オプション　　：デフォルトは全てチェックが入っている状態 ・テキスト選択　　　：行の折り返し/テキスト選択キーの拡張設定 ・現在のコードページ： 文字コード の確認が可能 フォント 【 出来ること 】 ・サイズ　：サイズの変更 ・フォント：フォントの変更 レイアウト 【 出来ること 】 ・画面バッファーのサイズ：画面全体のバッファーサイズの変更 ・ウィンドウのサイズ　　：ウィンドウサイズの変更 ・ウィンドウの位置　　　：起動時の表示位置が設定可能 画面の色 【 出来ること 】 ・以下項目の色が変更可能 　- 画面の文字 　- 画面の背景 　- ポップアップの文字 　- ポップアップの背景 ターミナル 【 出来ること 】 ・ターミナルの色　：ターミナルの色変更 ・カーソルの形・色：カーソルの形と色の変更が可能 基本的なコマンド一覧 コマンドプロンプト の中でも良く使うコマンドを、用途別にまとめました！ 操作例、実行例も載せておきましたので、是非ご参考ください。 ファイル・ ディレクト リ操作 コマンドプロンプト 説明 cd ■指定したフォルダに移動 cd フォルダ名 ドライブ名: ■指定したドライブに移動 D: type ■指定したファイル内容の全表示 type ファイル名 more ■指定したファイル内容の部分表示 more ファイル名 find ■ファイル内で指定した文字列を検索 find "Hi" ファイル名 sort ■ファイル内容を行単位でソート表示 sort ファイル名 fc /n ■指定した2つのファイルを比較し、差分表示 fc /n ファイル名1 ファイル名2 comp ■指定した2つのファイルを比較結果を表示 comp ファイル名1 ファイル名2 where ■ファイルの場所表示 shere ファイル名 dir ■フォルダ/ファイルの一覧表示 dir ■フォルダ/ファイルの一覧を横表示 dir :d ■更新日時の昇順表示 dir /O:d ■更新日時の降順表示 dir /O-d tree ■ ディレクト リ構造のツリー形式表示 tree copy ■ファイルのコピー copy ファイル名1 ファイル名3 xcopy ■フォルダをコピー(コピー先有) xcopy /I ファイル名1 ファイル名3 ■フォルダをコピー(コピー先無) xcopy /Y ファイル名1 ファイル名3 move ■ファイル/フォルダ移動 move ファイル名 移動先フォルダ名 move フォルダ名 移動先フォルダ名 ren ■ファイル/フォルダ名の変更 ren ファイル名 変更後ファイル名 ren フォルダ名 変更後フォルダ名 mkdir ■フォルダの作成 mkdir フォルダ名 rmdir ■フォルダの削除 rmdirフォルダ名 del ■ファイルの削除 del ファイル名 実行結果例 上記にまとめた、ファイル・ ディレクト リ操作の実行結果例を一部まとめてみました。 ◆ type C:\Users\ユーザー名\Desktop> type test.txt Hello HelloHelloHello HelloHelloHelloHello Hi ◆ find C:\Users\ユーザー名\Desktop> find "Hi" test.txt ---------- TEST.TXT Hi ◆ fc /n C:\Users\ユーザー名\Desktop> fc /n test.txt test2.txt ファイル test.txt と TEST2.TXT を比較しています ***** test.txt 3 : HelloHelloHelloHello 4 : 5 : ***** TEST2.TXT 3 : HelloHelloHelloHello 4 : HelloHelloHelloHelloHello 5 : ***** ◆ comp C:\Users\ユーザー名\Desktop> comp test.txt test2.txt test.txt と test2.txt を比較しています... ファイルのサイズが違います。 ほかのファイルを比較しますか (Y /N )? N ◆ tree C:\Users\ユーザー名\Desktop\test> tree フォルダー パスの一覧: ボリューム OS ボリューム シリアル番号は 00000 XXX XXXX :XXXX です C:. ├─folder1 ├─folder2 └─folder3 ◆ ren C:\Users\ユーザー名\Desktop> ren test.txt test1.txt C:\Users\ユーザー名\Desktop> dir ドライブ C のボリューム ラベルは OS です ボリューム シリアル番号は XXXX :XXXX です C:\Users\ユーザー名\Desktop のディレクトリ 2021/ 12 / 06 15 : 32 < DIR > test 2021/ 12 / 06 14 : 58 52 test1.txt 2021/ 12 / 06 15 : 21 77 test2.txt OS操作 コマンドプロンプト 説明 path ■バスを全表示 path ■1つのパスを1行表示 echo %PATH:;=&echo.% set ■ 環境変数 の表示 set % ■指定した 環境変数 の表示 echo %JAVA_HOME% ver ■OSのバージョン表示 ver whoami ■ログインユーザーの表示 whoami vol ■ボリュームシリアル番号の表示 vol chcp ■ 文字コード の表示 chcp cls ■ コマンドプロンプト の画面をクリア cls Ctrl + c ■コマンドのキャンセル Ctrl + C 実行結果例 ◆ path C:\Users\ユーザー名\Desktop> echo %PATH:;=&echo.% C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0\ C:\WINDOWS\System32\OpenSSH\ C:\Users\ユーザー名\AppData\Local\Microsoft\WindowsApps ◆ % C:\Users\ユーザー名\Desktop> echo %JAVA_HOME% %JAVA_HOME% ◆ ver C:\Users\ユーザー名> ver Microsoft Windows [Version 10 .0.XXXX.XXXX] ◆ whoami C:\Users\ユーザー名>whoami rakus\ユーザー名 ◆ chcp C:\Users\ユーザー名\Desktop> chcp 現在のコード ページ: 932 ネットワーク操作 コマンドプロンプト 説明 ipconfig ■ IPアドレス の表示 ipconfig ■ IPアドレス の詳細表示 ipconfig /all getmac ■ MACアドレス の表示 getmac arp -a ■ ARP テーブルの表示 arp -a netstat ■使用中ポートの表示（ホスト名取得有） netstat ■使用中ポートの表示（ホスト名取得無） netstat -n ■使用中ポートの表示（待ち受け有） netstat -a ■ netstat のオプション確認 netstat /? nslookup ■ DNS に問い合わせる nslookup ping ■ネットワーク接続の確認 ping IPアドレス tracert ■ネットワーク経路の確認 tracert IPアドレス/ドメイン名 コマンドプロンプト まとめ コマンドプロンプト の基本をまとめさせていただきましたが、ご参考になりましたでしょうか？ コマンドプロンプト は、 Windows のPCをお持ちの方でしたらデフォルトで入っているツールになります。 是非、ご自身のPCで試しながら理解を深めることをおすすめします。 改めまして、 コマンドプロンプト を使う人にとって、少しでも一助となれば幸いです。 最後までお読みいただきありがとうございました！ Linux コマンドや bash を別記事にてまとめております。 ご興味ありましたら是非ご参考ください！ ・ よく使うLinuxコマンド一覧【最新版】 - RAKUS Developers Blog | ラクス エンジニアブログ ・ 【bash入門】bashシェルスクリプトの書き方 - RAKUS Developers Blog | ラクス エンジニアブログ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 今回は自身の iOS アプリ開発 における、 Xcode 周りの体験談についてまとめてみました。 　 iOS アプリ開発 には IDE として Xcode を使うのが一般的だと思いますが、 元々 Eclipse でサーバサイドの開発に携わっていた身として Xcode を使った開発は新鮮なものでした。 　 そんな体験談の中から、今回は3つを記事にしています。 この記事を読んで、「こんな使い方があったのか」といった気付きを得たり、「あるある」と共感いただけたり、 逆に「こういう使い方もあるよ」といったご意見をいただけたりしますと幸いです。 　 Xcode の紹介やインストール方法については、RAKUS Developers Blogに詳しい記事が投稿されています。 こちら記事もぜひご覧ください。 ・ 【超入門】Xcodeのインストール方法-iosアプリを実機にインストールするまで - RAKUS Developers Blog | ラクス エンジニアブログ お知らせ この記事は ラク ス Advent Calendar 2021 6日目の記事です。 よければ、Advent Calendarも見てください。 qiita.com 目次 はじめに 目次 体験談①：Xcodeでの画面作成 iOSアプリの画面とxibファイル 部品を配置する Auto Layoutの設定 部品とコードの紐づけ 使ってみた感想 体験談②：Xcodeでのデバッグ UI Hierarchy Memory Graph Hierarchy lldb 体験談③：Xcodeのバージョンアップ iOSのSDKとXcode 具体的な動作確認方法 新旧Xcodeを混在させる おわりに 体験談①： Xcode での画面作成 楽楽精算の iOS アプリ開発 における、 Xcode を使った画面作成について語ります。 iOS アプリの画面とxibファイル 2021年現在、 iOS アプリの画面作成における最新技術はSwiftUIだと思いますが、 楽楽精算の iOS アプリでは xibファイル を使った画面作成を行っています。 xibファイルは iOS アプリにおけるHTMLファイルのようなもので、 XML として保存されますが Xcode 上で直感的に画面の部品を配置していくことができます。 xibファイルの編集画面 この画面で以下を行うことができます。 xibファイルへ画面の部品を配置する 配置した部品同士のAuto Layoutを設定する 配置した部品とSwiftのコードを紐付ける 部品を配置する 画面に部品を配置するには、まず Xcode の画面右上にある「+」マークのボタンをクリックします。 上記のボタンをクリックすると、ラベル、ボタンといった部品の種類が表示されるので、 その中から配置する部品を選択すると、画面に配置されます。 部品の選択画面 Auto Layoutの設定 iOS には Auto Layout という仕組みがあり、設定することで部品の間隔やサイズを、 端末側で適切に表示させることができます。 Auto Layoutの詳細は割愛しますが、この設定もxibファイルの編集画面で行う事が出来ます。 やり方は、まずcontrolキーを押しながら一つ目の部品を選び、間隔や位置を設定する先の部品を選びます。 自身のサイズを設定する際などは、二つ目の部品として自信を選びます。 すると、設定するAuto Layoutの種類が表示されるので、その中から設定するものを選びます。 部品同士を選んでAuto Layoutを設定する 間隔やサイズのパラメータは、初期値として画面に配置されている部品同士の位置などから入力されるので、 変更したい場合は該当のAuto Layoutの値を編集可能です。 Auto Layoutの編集画面 部品とコードの紐づけ 上記の通り作成した画面の部品はSwiftのコードと紐づけることで、 タップされたときの処理を呼び出す、テキストを取得するといった事が出来ます。 紐づけ方はAuto Layoutと同様、まずcontrolキーを押しながら紐づけたい部品を選びます。 次に紐づける先として、対象のコードで何もない箇所を選択します。 あとは、プロパティ（outlet、outlet collection）として紐づけるか、 関数（Action）として紐づけるか選択すれば、 Xcode がコードを作成してくれます。 一連の操作はxibファイルとSwiftファイルに跨るので、エディタを二つ画面に表示させておくとやりやすいです。 部品とコードの紐づけ 使ってみた感想 このように、部品の配置を始め Xcode でのxibファイルの編集は直感的に行う事が出来ます。 また、上記以外でも端末ごとやダークモードのON / OFF、回転している / していないといった状態ごとに、 画面へどう表示されるかプレビューすることが出来ます。 もちろん、最終的には実機で画面崩れが無いか確認することにはなるのですが、 予め編集画面で確認することができるのは良いと思いました。 ただ、直感的に配置された部品とxibファイル内の記載を対応させて把握するのは難しく、 コードレビューではコミットされたコードではなく、 Xcode 上で見てみないと分からないのが辛いところです。 ※ Xcode というよりはxibファイルの話ですが 体験談②： Xcode での デバッグ Xcode を使った デバッグ について語ります。 UI Hierarchy デバッグ ポイントで止めている間は、画面左の Debug Screen で様々な情報を確認することができます。 確認できる情報は4つあるのですが、その内の一つが UI Hierarchy で、 その時表示されている画面の構造を確認することができます。 例えば、画面上のボタンが押せないといった事象が過去にあったのですが、 原因としてボタンの表示がビューのサイズを超えていたということがありました。 そういった事象があった場合の調査に使っています。 例：UI HierarchyでCoreNFCのサンプル画面を見てみる Memory Graph Hierarchy Debug Screenで見ることのできる情報の内、もう一つ Memory Graph Hierarchy を使う事もあります。 例えば、楽楽精算の ICカード リーダーアプリ（ iOS ）はCoreNFCを使って ICカード を読み取っているのですが、 他のアプリで ICカード を読み取るセッションが既に起動していると、セッション起動時にエラーになります。 が、他にアプリを起動していなくても、読み取りをリトライするだけでエラーになることがあり、 セッションのオブジェクトが削除されていないタイミングでリトライしているのではという仮説の下、 オブジェクトを調査するのに使いました。 例：Memory Graph Hierarchy でCoreNFCのサンプルコードを見てみる Debug Screenでは、他にもスレッド毎やキューごとにプロセスの状態を見ることができますが、 今回は割愛します。 lldb Debug Screen 以外にも、 Xcode では lldb というデバッガを使って、 Swiftコード の デバッグ を行う事が出来ます。 私は主に p 、 po というコマンドを使っており、前者は変数の値を確認するのに、 後者は式の評価、関数実行に使っています。 コード中に ブレークポイント を設定しておいて、アプリが止まっている間に、 画面右下のコンソールで(lldb)とある箇所にコマンドを打つことで実行可能です。 変数の値は止まっている間に変数にカーソルを合わせる、コンソール左のVariable Viewで見る、 といったことでも確認できますが、個人的にlldbの方が必要な情報を絞り易いのでよく使っています。 例：lldbで変数を見てみる 体験談③： Xcode のバージョンアップ 楽楽精算の iOS アプリ開発 における、 Xcode のバージョンアップについて語ります。 iOS の SDK と Xcode Java 等とは違い、 iOS アプリの SDK は Xcode に含まれています。 そのため、アプリの SDK バージョンを上げる = Xcode のバージョンを上げることになります。 また、 Apple はアップロード可能な SDK バージョンを定期的に上げていくため、 Xcode を定期的に上げないとアプリがアップロードできなくなります。 直近の例 developer.apple.com 2022年4月以降、App Storeに提出するiOSおよびiPadOS Appはすべて、Xcode 13およびiOS 15 SDKでビルドする必要があります。 なお、楽楽精算の スマホ アプリ開発 では、リリース予定のアプリをアップロードした際、 SDK のバージョンアップが必要なことに気づき、急ぎ Xcode のバージョンアップを進めたこともありました。 その時のエラー ERROR ITMS-90725: "SDK Version Issue. This app was built with the iOS 13.7 SDK. All iOS apps submitted to the App Store must be built with the iOS 14 SDK or later, included in Xcode 12 or later. 上記のように、 Apple はアップロード可能な SDK バージョンに関するニュースを出しているので、 iOS アプリ開発 者の皆さまは Apple の開発者向けニュースを定期的に確認するようにしましょう。 developer.apple.com 具体的な動作確認方法 上記の通り、 Apple はアップロード可能な SDK バージョンを定期的に上げていくため、 楽楽精算開発では定期的なバージョンアップのタイミングに合わせて Xcode をバージョンアップできるよう、 バージョンアップ後の Xcode でアプリがビルドできるか ビルドしたアプリが問題なく動作するか を確認しています。 特に動作確認については、アプリの全機能が問題ないか確認しています。 この辺りは自動テストを用意して 工数 を削減するのも手だと思いますが、いまのところそういった仕組みは無く、 NFC を使った ICカード の読取り機能、端末のカメラでの領収書撮影機能といった、 実機でないと確認しづらい機能もあり、動作保証対象のOSバージョンごとに手動でテストを行っています。 機能、動作保証対象バージョンを網羅した動作確認となると総テスト項目数は 764項目 ！ 直近行ったXcode13のバージョンアップ対応では、動作確認だけで3人日（= 24時間）かかりました。 このように、定期的に Xcode のバージョンを上げるのにも、それなりの 工数 を要しています。 新旧 Xcode を混在させる 楽楽精算としては定期的なバージョンアップで Xcode の新バージョンへ対応するということになっていますので、 それまでの間にリリースを行う場合、古いバージョンの Xcode でビルドを行う必要があります。 幸い、 Apple は旧バージョンの Xcode をダウンロードできるようにしているため、 必要な場合はそちらからダウンロードしてビルド用に使うことが可能です。 旧バージョンの Xcode が公開されているページ https://developer.apple.com/download/all/?q=Xcode また、楽楽精算の iOS アプリは fastlane でビルドを行っているため、 fastlaneが旧バージョンの Xcode を使ってビルドするような設定も必要です。 いまのところ、楽楽精算開発では開発者の MacBook でビルドを行っているため、 上記の設定は xcode -selectを使って行っています。 設定変更の例 // 旧Xcodeはそれとわかるように名前を変えておくと良い xcode-select --switch /Applications/Xcode_13_0.app fastlaneのビルド情報 ↑ xcode_path に設定したものが表示されている。 おわりに いかがでしたでしょうか。 個人的な感想として、コードを書く以外にも デバッグ やビルドにも関わってくるなど、 iOS の アプリ開発 には Xcode が付きまとうという印象を受けました。 また、定期的なアップデートが大変といった点はありますが、画面作成を直感的に行う事ができ、 今までの アプリ開発 では得られなかった体験も得ることができたと感じています。 将来的にどうなるかは分かりませんが、 iOS アプリ開発 では Xcode を使っていくことになると思いますので、 これからも Xcode に慣れ親しんでいければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、技術広報の yayawowo です。 フロントエンドエンジニアの皆様、今のフロントエンドを楽しんでおりますでしょうか？ 　 変化の多いフロントエンド領域を楽しむために・・・ ラク スが開催している 「フロントエンド LT会」で発表された資料をご紹介します！ フレームワーク や開発言語別にまとめておりますので、興味があるところだけを少し摘まむのも大歓迎です。 9月に開催した「フロントエンドLT会 - vol.4」は、参加者が500名越えとなるイベントなりました。 2022/1/19(水)に「フロントエンドLT会 - vol.5」を開催しますので、ご興味ある方は是非登壇/視聴申込よろしくお願いいたします！ rakus.connpass.com では、早速見ていきたいと思います！ イベント詳細はこちらからご確認ください。 ・ フロントエンドLT会 vol.1 -2020夏祭り- ・ フロントエンドLT会 vol.2 - 2020冬まつり ・ フロントエンドLT会 - vol.3 ・ フロントエンドLT会 - vol.4 フレームワーク Preact で手書き文字採点アプリを作ってみた React + Amplifyで アプリ開発 新規開発を止めないフロントエンドReactリプレイスの進め方とTips ピュアなJSしか使ったことのない人がReactを触った後の感想 SWRと状態管理 ユーザーが編集中の状態管理について考えよう Vue CLIプロジェクトにViteを導入検討してみた Vue.js と Chart.js でチャートを描画する Vue OptionsAPIからCompositionAPIに変換するツールを作ってみた VS Code Remote Containersを使った Angular開発 Nuxt.js + firebaseでハマったこと Blazor Web Assembly (C#) を触ってみた 開発言語 javascriptでも条件式を使いたい話 再帰関数を使ってみよう iframe sandboxでユーザー入力スクリプトを実行する HTML だけで UI を作る限界、あるいは無理なくユースケースと向き合っていくためには 疑似要素によるCSSセレクタ CSS のルールセットを高速に出力する VS Code 拡張を作った Lit Astro Something その他 Firebase + Bolt で もくもく会用のSlack botを作った話 docker-compose × Firebase Emulator でローカル環境構築 SVGでボーンアニメーションできない世界に絶望しないためのLT モナコインの投げ銭機能付きQiitaみたいなサービスを作った話 フロントエンドエンジニアの採用情報 終わりに フレームワーク Preact で手書き文字採点アプリを作ってみた 発表者： choo さん docs.google.com ◆ 発表のポイント ・フロントエンドの工夫3点 　① CSS フレームワーク は使わない 　②定義ファイルなどでサイズが多きものは遅延読込み 　③軽量版 React の Preact の導入 ・Preact は、ほぼ React と同じように使えるので、React 使いの人にはPreactめっちゃオススメ！ React + Amplifyで アプリ開発 発表者： nishikichi244 さん React + Amplifyで アプリ開発 from 虎の穴 開発室 www.slideshare.net ◆ 発表のポイント ・ API が自動生成できたり管理画面の実装の手間が省ける 　→ フロントのロジックの開発に集中できる！ ・ AWS のサービスになじみがある人は特におすすめ ・GraphQLを使った気になれた ・自分のト レーニン グを記録して振り返るアプリにしたい 新規開発を止めないフロントエンドReactリプレイスの進め方とTips 発表者： YuitoSato さん note.com ◆ 発表のポイント ・機能ごとにリプレイスしていく 　→小さくリリースすることで、新規機能開発と並行してすすめる ・変更が多い機能からリプレイスをする 　→二重の変更を避ける。早いタイミングでチームに布教できる ・副業、業務委託の方に協力してもらう 　 →フロントエンド特需に耐えるため。他社から設計を学ぶため ピュアなJSしか使ったことのない人がReactを触った後の感想 発表者： lcpj さん docs.google.com ◆ 発表のポイント ・JSXに使われる技術について 　→トランス コンパイラ Babel ・ステートについて ・ コンポーネント について 　→ ガンプラ を組み立てるようにコードを書く SWRと状態管理 発表者： koki さん speakerdeck.com ◆ 発表のポイント ・SWRの基本知識と特徴について ・SWRの自動再検証 ・ReduxからSWRを採用した理由 　→コードがとてもシンプル！ ・SWRを使った実装例の紹介 ユーザーが編集中の状態管理について考えよう 発表者： りゅーそう さん speakerdeck.com ◆ 発表のポイント ・Create⇔Update⇔Deleteの⇔の状態をどうデザインするか ・microCMSの事例紹介 ・ユーザーが「編集中」の状態は重要だが、本筋ではないためそれを念頭においてデザイン・実装すべし！ Vue CLI プロジェクトにViteを導入検討してみた 発表者： hatsune_k さん speakerdeck.com ◆ 発表のポイント Viteを導入してみて… ・アプリ起動まではできた ・想像より設定変更が面倒、コード変更も必要 ・導入には以下の3つの壁が残っている 　①SCSSの~@の エイリアス が読めない 　②Vuetifyの利用 コンポーネント を個別読み込みする必要がある 　③細かいデザイン崩れがあるのであたってないスタイルがありそう ・開発時ビルドは噂通り爆速 ・プロジェクトによっては即導入する価値はある！ Vue.js と Chart.js でチャートを描画する 発表者： SAW さん speakerdeck.com ◆ 発表のポイント ・Vue-chartjs の基本的な使い方を紹介 ・データの変更を検知してチャートをリアクティブに描画 ・実際の利用例を紹介 Vue OptionsAPIからCompositionAPIに変換するツールを作ってみた 発表者： miyaoka さん miyaoka.dev ◆ 発表のポイント ・Vue2のOptions API で書かれた コンポーネント をcomposition API を使った書き方に自動変換するツールの構築 ・どういう変換をしているのか？ 　１．入力値として Vue の SFC コンポーネント の文字列を受け取る 　２．vue-template-compiler で SFC から script 部分を抽出する 　３．TypeScript の compiler API で AST にする 　４．export default しているところの 各 options の値を読み取り、 新しい export に変換して出力する ・変換用の CLI として作ろうとしていたが、結局ブラウザで入出力の確認画面があったほうが分かりやすい ◆ リポジトリ GitHub - miyaoka/vue-composition-converter: Vue composition API converter ◆デモ Vue composition converter VS Code Remote Containersを使った Angular開発 発表者： honma12345 さん VS Code Remote Containersを使った Angular開発 from ShuheiHonma www.slideshare.net ◆ 発表のポイント ・remote containers導入前の問題点 →フロント開発の環境構築に時間がかかる ・remote containersの良い点 →フロントの開発構築が何より早い →ローカルマシンの構成に影響を与えない ・ AWS Amplityを利用したケースにも活用可能！ Nuxt.js + firebaseでハマったこと 発表者： Logy さん speakerdeck.com ◆ 発表のポイント ・ハマったこと 　①currentUser入ってない問題 　②コンソールエラー地獄 ・慣れない技術であっても基本に立ち返ることがトラブル解消への近道！ ・多少ハマったものの、認証機能はすぐに実装できた 　→Nuxt.js + firebase最高！ Blazor Web Assembly ( C# ) を触ってみた 発表者： nt-7 さん Blazor Web Assembly (C#) を触ってみた from Naito Oshima www.slideshare.net ◆ 発表のポイント ・Blazorとは？ →.NET( C# )を使って、SPA開発ができる フレームワーク ・どんな人に嬉しいの？ 　① ASP.NET 、 ASP.NET Coreあたりを触ることが多い方 　② C# 割と得意な方 　③今後 SPA 開発に興味がある方 　④Wasm で動く .NET ランタイム上の Blazor 開発に興味がある方 開発言語 javascript でも条件式を使いたい話 発表者： philomagi さん speakerdeck.com ◆ 発表のポイント ・条件文と条件式の違い 　→文は値を返さない、式は値を返す 　→条件式が使えると、細かいところでコードが簡略ができて便利 ・ JavaScript のif/switchは条件文 ・ JavaScript で条件式を使うために、ライブラリ化してみた 　→TypeScript対応 　→遅延評価対応 　→非同期にも対応 ◆ライブラリ ceiocs - npm 再帰 関数を使ってみよう 発表者： ita_3y さん speakerdeck.com ◆ 発表のポイント ・オブジェクトの探索等、 再帰 的な処理をしたい時は 再帰 関数が使えるかも ・ 再帰呼び出し をするときは、必ず終了条件があることを確認しよう ・等間隔の遅延を入れたい時は、setTimeout の 再帰呼び出し が良いかも ・ JavaScript で 再帰呼び出し をするときスタックオーバーフローに注意しよう iframe sandboxでユーザー入力 スクリプト を実行する 発表者： syumai さん speakerdeck.com ◆ 発表のポイント ・ユーザー入力 スクリプト の安全な実行には別OriginのWindowが使える ・別OriginのWindowは、iframe sandboxで簡単に使える ・Window Object間のmessage送受信にはpostMessageが使える ◆デモ GitHub - syumai/sandboxed-eval: iframe-sandboxed eval working on the browser. HTML だけで UI を作る限界、あるいは無理なく ユースケース と向き合っていくためには 発表者： yamanoku さん docs.google.com ◆ 発表のポイント ・フロントエンドとは、「すべてできる」それは本質ではなく表層の部分に責任をもつこと ・UIにまつわる責務を分解していく 　→詳細度に依存しない見た目（Utility CSS ） 　→ Webブラウザ 上の振る舞い（Web API （& JavaScript ） 　→UIの意味づけ（WAI- ARIA ） 疑似要素による CSS セレクタ 発表者： Takao Kamenoue さん speakerdeck.com ◆ 発表のポイント ・ セレクタ ーの種類 　①基本となる セレクタ ー（要素・クラス・ID） 　②属性による セレクタ ー（a[disabled],input[type="text"] ） 　③疑似クラスまたは疑似要素（a:hover,div::before） ・疑似要素を使用する際はブラウザでサポートされているかを確認する ・疑似要素ではそれぞれ利用できる CSS プロパティが異なる ・疑似要素を扱う際には アクセシビリティ にも気をつける。 アクセシビリティ に問題が発生するようならば代替案を検討する CSS のルールセットを高速に出力する VS Code 拡張を作った 発表者： kubosho_ さん speakerdeck.com ◆ 発表のポイント ・eCCStractor for VS Code の紹介 　→HTMLのクラス名やID名を抽出する 　→HTMLの他に、JSXと TSX も対応している ◆eCCStractor for VS Code のインストールページ eCSStractor - Visual Studio Marketplace ◆ GItHub GitHub - kubosho/vscode-ecsstractor: Extracting selectors from HTML / JSX / TSX and generate CSS file. Lit Astro Something 発表者： takanorip さん zenn.dev ◆ 発表のポイント ・LitでTailwind CSS を使う方法として、大きく2つの道がある 　①Shadow DOMを使わないようにする 　　・ createRenderRoot を使用してすべてをShadow DOMの外に出す 　②Shadow DOMのstyleの中にどうにかしてねじ込む 　　・windicssを使う： Windi CSS 　　・PostCSSで頑張る 　　・rollupを使う： GitHub - takanorip/lit-tailwind その他 Firebase + Bolt で もくもく会 用のSlack bot を作った話 発表者： RyoKawamata さん speakerdeck.com ◆ 発表のポイント ・Bolt + Firebase Functions で Bot は手軽に作れる ・勉強会開催前に Bot を温めておこう ・processBeforeResponseの設定を忘れずに！ docker-compose × Firebase Emulator でローカル環境構築 発表者： meijin さん zenn.dev ◆ 発表のポイント ・Firebase の使いどころと課題 ・Emulatorの概要とセットアップの全体的な流れ ・Dockerコンテナ作成手順 ・React Native Emulator と接続する方法 SVG でボーンアニメーションできない世界に絶望しないためのLT 発表者： miyanokomiya さん docs.google.com ◆ 発表のポイント ・ SVG でボーンアニメーションを作った話 ・資料作りの時間 < アニメーション作りの時間 ・岡田ーマンの SVG 素材+プロジェクトファイルをLT記念特別配布中 　→ 2021_06_30_LT_配布素材 - Google ドライブ ・主な使い方は以前zennにも書いたので参考に 　→ SVG岡田ーマンに命を吹き込む9のステップ モナコ インの 投げ銭 機能付きQiitaみたいなサービスを作った話 発表者： 石橋　龍（らいう） さん drive.google.com ◆ 発表のポイント ・ユーザ認証でデジタル署名を利用する（パスワード不要でユーザ認証！） 　→クライアント側に必要なもの：クライアントで発行した 秘密鍵 　→バックエンド側に必要なもの：ユーザの公開鍵 ・フロント側のロジック + ブロックチェーン で 投げ銭 ができる ・投機以外の用途で暗号資産を見てみると面白い応用がおもいつくかも？ ◆ GIthub GitHub - Raiu1210/omaemona_front フロントエンドエンジニアの採用情報 ラク スでは、フロントエンドエンジニアを募集中です！ ご興味ある方は以下内容をご確認ください。 ポジション 募集内容 マネージャー フロントエンドエンジニア／マネージャー（東京） | 株式会社ラクス エンジニア フロントエンドエンジニア（東京） | 株式会社ラクス ※2021/12/02時点での情報です。 開発拠点は 東京 です。 SaaS プロダクトの技術スタックは以下ブログをご参考ください！ tech-blog.rakus.co.jp 終わりに フロントエンド LT会で発表された内容はいかがでしたでしょうか？ 少しでもフロントエンドの初学者や、現役フロントエンドエンジニアの皆様のご一助となれば幸いです。 なお、冒頭でお伝えしましたが、「フロントエンドLT会 - vol.5」は2022/1/19(水)に開催予定です！ 毎度大盛況のイベントとなっておりますので、登壇/視聴されたい方は是非お申込みをお願いいたします。 イベントの詳細は以下をご確認ください！ ・ フロントエンドLT会 - vol.5 #frontendlt - connpass 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は、11月に開催した 【ラクスMeetup】急成長SaaSの生産性向上戦略／オフショア、SRE、属人化対策 の発表内容について紹介させていただきます！ 本イベントには、当社の中でも特に大型開発の楽楽精算を担当している、開発最前線のエンジニアが2名が登壇しました。 SaaS 開発に携わる方のご参考になれば幸いです！ イベントの詳細は以下をご確認ください。 ・ 急成長SaaSの生産性向上戦略／オフショア、SRE、属人化対策 - connpass 発表の紹介 楽楽精算のリリースプロセス最適化 多拠点開発の生産性を飛躍的に向上させるプロジェクト管理手法 おわりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ 楽楽精算のリリースプロセス最適化 登壇：根井 達規 [担当サービス： 楽楽精算 ] まずは、楽楽精算開発課の根井から「楽楽精算のリリースプロセス最適化」についての発表です！ 楽楽精算では開発チームからリリース担当者を選出し、プロダクト全体のスケジュールの策定から本番リリースまでの作業フローをリリース担当者が一括管理することで、開発全体の作業効率化を図りリリースの品質と精度を保ってきました。 本セッションでは、ユーザー数が増加し開発規模も拡大してくなかでの 開発成果物をどのようにして効率よくサービスインするのか リリース担当者の役割 取り組みから見えてきた課題 今後の作業効率化に向けた展望 についてご紹介させていただきました。 speakerdeck.com 多拠点開発の生産性を飛躍的に向上させるプロジェクト管理手法 登壇：樋口 朱理 [担当サービス： 楽楽精算 ] 楽楽精算の開発規模が大きくなり、 ベトナム 拠点でオフショア開発をしています。 言葉の壁、文化の違いで認識齟齬が起きやすい環境下において、多拠点開発における生産性は、多くの方が困っている大きな課題の一つかと思います。 楽楽精算開発が実践している、円滑なプロジェクト進行に欠かせないマネジメントのノウハウ、コミュニケーションのノウハウを楽楽精算の樋口よりご紹介させていただきました！ speakerdeck.com おわりに 「【Meetup】急成長 SaaS の生産性向上戦略／オフショア、SRE、属人化対策」はいかがでしたでしょうか？ 今回は楽楽精算開発課から2名の現役エンジニアに登壇いただきました。 ラク スのエンジニア自身も生産性の向上に向けたプ ラク ティスに日々取り組んでいます。 是非、楽楽精算の課題や教訓が SaaS 開発に携わる方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

（本記事は2024/6/6時点の情報にアップデートしております） こんにちは、技術広報の yayawowo です。 突然ですが、株式会社 ラク スと聞いて何を思い浮かべますでしょうか？ 弊社 ラク スでは、様々なプロダクトを展開していますが正直認知度は低いと思っております。 そこで今回、弊社についてもっともっと知っていただくため・・・ ラク スが展開している全10プロダクト 全10プロダクトの技術スタック インフラ/SRE/デザイナーの技術スタック について、ご紹介させていただきます！ SaaS 開発に携わる方、弊社に少しでも興味を持っている方の一助となれば幸いです！ ラクスが展開している全10プロダクトとは？ バックオフィス向け フロントオフィス向け 10プロダクトの技術スタック 楽楽販売 楽楽精算 楽楽明細 楽楽電子保存 楽楽勤怠 MailDealer 配配メール Curumeru blastmail & blastengine フロントエンドの技術スタック インフラ・SREの技術スタック インフラ SRE デザイナーの利用ツール UIデザイナー エンジニア/デザイナーの募集職種 過去イベント動画をYoutubeで公開中 終わりに ラク スが展開している全10プロダクトとは？ まずは、弊社が展開しているプロダクトを一覧で見てましょう。 いくつのプロダクトをご存知でしょうか？ バックオフィス向け 名称 主な利用部門 提供機能 リリース年 楽楽販売 複数のスタッフでデータや 情報共有が必要な さまざまな部門 ・販売管理 ・請求管理 ・稟議申請管理　 2008年 楽楽精算 交通費精算や経費精算の申請や 支払手続を行う 営業や 経理 部門 ・交通費精算 ・経費、出張精算　 2009年 楽楽明細 請求書、支払明細といった 帳票を扱う 営業や 経理 部門 ・帳票：請求書、納品書、支払明細 ・発送方法：WEB、メール添付、郵送、FAX　 2013年 楽楽勤怠 打刻や休暇申請を行う 全従業員 と 勤怠の締めを行う 総務人事部門 ・打刻機能 ・打刻修正、休暇、残業などの申請 ・休暇管理 2020年 楽楽電子保存 請求書、支払明細といった 帳票を扱う 営業や 経理 部門 ・帳票の電子保存・一元管理 2022年 フロントオフィス向け 名称 主な利用部門 提供機能 リリース年 MailDealer 複数名のスタッフでメール対応を している カスタマーサポート部門 ・問合せメールの返信状況管理 ・顧客との対応履歴管理 2001年 配配メール 見込客や顧客にメルマガを 配信している 営業や マーケティング 部門 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング 2007年 Curumeru 同じ ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング ・メールの承認フロー 2011年 blastmail & blastengine 見込客や顧客にメルマガを 配信している 営業や マーケティング 部門 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング - 3つ以上知っていてる方は、 ラク スマニアと言っても過言ではないですね！ 初めて聞いた！という方がおりましたら、是非サイトにいき、ご確認いただけますと幸いです。 10プロダクトの技術スタック では、我々 ラク ス開発本部についてご紹介していきたいと思います。 ラク ス開発本部のミッションは 「日本を代表する SaaS 開発エンジニア集団へ」 を掲げております。 また、弊社はおよそ2年おきに最新プロダクトをリリースしております プロダクトの技術選定は、「ベスト・オブ・ブリード（Best of Breed）」という考えのもとリリース時により良い最適な技術を採用しております。 そのような背景も踏まえ、 ラク ス開発本部にて扱っている10プロダクトの 技術スタック をこれからご紹介していきたいと思います！ 楽楽販売 図１：楽楽販売の技術スタック 楽楽販売 は、販売管理・案件管理をはじめとした、あらゆる社内業務をシステム化することができるWebデータベースシステムです。 Excel での業務管理を卒業して、販売管理などの業務を ラク にします。 リリースは2008年10月であり、14年以上続いているプロダクトになります！ また、楽楽販売の開発拠点は、 関西 となります。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 PHP MW PostgreSQL 、 Postfix 、 Apache 、Redis FW・ライブラリ Zend Framework 、 jQuery 開発ツール PhpStorm、GitLab、 GitHub Copilot CI・テスト Selenium /Selenide、 PHPUnit 、 JMeter 、Jenkinsｍ、PHPStan ※2024/6/6時点での情報です。 楽楽販売は、 CRM （BtoB向け）のシステムであり API 連携が多いのが特徴です。 また、お客様がノンコード（UI上）で処理を作成できるといったプロダクト特性があります。 楽楽精算 図２：楽楽精算の技術スタック 楽楽精算 は、経費・交通費・出張費・旅費・交際費など、お金にかかわる全ての処理を一元管理できる クラウド 型の交通費・経費精算システムです。 リリースは、2009年7月で弊社の中でも最も勢いのあるプロダクトであるため、開発規模も最大になります。 開発拠点は、 東京・ ベトナム です。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 Java 、Swift、Kotlin MW PostgreSQL 、 Postfix 、 Apache 、Room FW・ライブラリ Spring Boot、 jQuery 、Retrofit2 開発ツール GitLab、 IntelliJ IDEA、 Xcode 、 Android Studio 、Flyway、 Redmine 、 Github CI・テスト Selenide、Gradle、 JMeter 、 jUnit 、Jenkins、Bitrise ※2024/6/6時点での情報です。 技術の選定の大きな方針としては、保守性の観点で、なるべく普及しているものを選定するようにしています。 また、主要な開発言語は Java 、上記に記載したツールを利用し、開発を行っております。 楽楽明細 図３：楽楽明細の技術スタック 楽楽明細 は、請求書・納品書・支払明細・領収書などをWEB・メール・郵送で自動発行し、 印刷・封入・発送などの帳票発行の手間をゼロにする クラウド サービスです。 リリースは2013年9月、開発拠点は 東京・ ベトナム です。 市場の成熟とともに急激に伸びているプロダクトになります！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 Java 、TypeScript MW PostgreSQL 、 Apache 、 Postfix 、Docker FW・ライブラリ React、Redux、SpringBoot、JasperReports、 Lombok 、Jooq、 jQuery 、GraphQL 開発ツール IntelliJ IDEA、 Redmine 、GitLab、gulp.js、webpack、Storybook CI・テスト Gradle、 JMeter 、 jUnit 、TestCafe、SonarQube、Jenkins、Cypress、Spock ※2024/6/6時点での情報です。 サーバーサイドを Java で、フロントエンドをTypeScriptで構築しています。 サービスローンチから8年を数え、比較的古い アーキテクチャ となっているコア部分と、新しいFWなどを用いた部分とがハイブリッドになっています。 主要な新規機能開発部はサーバーサイドとフロンドを分離されており、SpringBootやReactを用いて開発をしています。 DDDを用いた設計手法の導入、 モノリス から バッチ処理 部分を分離して アーキテクチャ を更新する、オフショア開発をスタートするなど、 サービスの成長に合わせて開発手法や組織を変化させていっています。 ◆ 技術・デザイン情報ページ フロント刷新から設計手法アップデートまでバランス感覚を活かして幅広く推進 | ストーリー | 株式会社ラクス キャリア採用 楽楽電子保存 図４：楽楽電子保存の技術スタック 楽楽明細 は、楽楽明細と連携し、電子発行された請求書・納品書・支払明細・領収書などを 保存・一元管理できるサービスです。 電子帳簿保存法 対応により、ニーズが高まっているプロダクトです！ リリースは2022年、開発拠点は 東京・ ベトナム です。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 Java 、TypeScript MW PostgreSQL 、 Apache 、 Tomcat 、 Postfix 、Docker、 Kubernetes FW・ライブラリ React、Redux、MUI、styled-components、Spring Boot、Jooq 開発ツール IntelliJ IDEA、 GitHub 、Vite、Storybook CI・テスト Gradle、 JUnit 、SonarQube、Jenkins、 GitHub Runner、Jest、Cypress、argoCD ※2024/6/6時点での情報です。 楽楽勤怠 図５：楽楽勤怠の技術スタック 楽楽勤怠 は、主に中小企業3,000社超のバックオフィスの効率化を実現した クラウド 型経費精算システム「楽楽精算」の開発・提供で培った様々なノウハウを活用し、勤怠管理業務の効率化を実現する クラウド サービスです。 リリースは2020年10月となります！ 主な開発拠点は、 東京・ ベトナム です。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 PHP , JavaScript MW MySQL , Apache FW・ライブラリ Flow, Vue.js 開発ツール GitLab, PhpStorm CI・テスト Selenium , Ansible ※2024/6/6時点での情報です。 ラク ス社内では目新しい技術を多く利用しており、DDDを用いた設計思想を取り入れ、フロントエンドとバックエンドを切り離した開発を行っています。 開発側にPdM相当の人がいるので、開発主導でサービスをブラッシュアップしていけます。 MailDealer 図６：Maildealerの技術スタック MailDealer は、顧客からの問合せメールを共有・一元管理し、メール対応業務を効率化するツールです。 2001年4月にリリースされ、最も古いプロダクトとなります。 主要な開発拠点は 大阪・ ベトナム になりますが、フロントエンドは 東京 と拠点を分けた体制です！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 PHP 、Node.js MW PostgreSQL 、 Apache 、 Postfix FW・ライブラリ Laravel、 jQuery 、CKEditor、Socket.IO、Vue.js 開発ツール PhpStorm、 Redmine 、GitLab、Trello、 GitHub Copilot CI・テスト Selenium /Selenide、 PHPUnit 、Jenkins、Ansible ※2024/6/6時点での情報です。 主要な開発言語は PHP 。 リアルタイム通信部分にはNode.js（＋Socket.IO）も利用しています。 20年以上の歴史を持つサービスながら、オフショア開発、 リファクタリング や新技術のハイブリッド導入など新たな領域にもチャレンジし続けているサービスです！ 配配メール 図７：配配メールの技術スタック 配配メール は、中小企業の集客・販促活動に携わる方のメール配信業務を支援するメール マーケティング の実践に最適なメール配信サービスです。 リリース日は、2007年5月になります。 なお、MailDealerと同様、開発拠点は 大阪・ ベトナム ですがフロントエンドは 東京 になります！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 PHP MW PostgreSQL 、 Postfix 、Nginx、 Apache 、Redis FW・ライブラリ Slim、 jQuery 、Vue.js 開発ツール PhpStorm、 REDMINE 、GitLab、Docker、 GitHub Copilot CI・テスト Puppeteer、Jenkins、 JMeter 、 PHPUnit 、PHPStan、 PHP _CodeSniffer、PHPDoc、Ansible ※2024/6/6時点での情報です。 開発言語は PHP 、 フレームワーク は国産 OSS を自社拡張したものを採用しています。 大量メール配信による マーケティング ツールのサービス基盤を自社でメンテナンスしながら、初期リリースから15年以上サービスを継続させています。 また、近年需要が高まりつつあるデジタル マーケティング ツールとして、最新のWeb技術も取り入れながら機能強化を続けています。 変化の激しい マーケティング のビジネス領域に適応するため、 アジャイル 開発や プロダクトマネジメント 手法を取り入れることにもチャレンジしています！ Curumeru 図８：Curumeruの技術スタック Curumeru は、低コストで導入できる大量メール配信サービスです。 2011年6月にリリースされており、開発拠点はこちらも 大阪・ ベトナム ！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 PHP MW PostgreSQL 、 Postfix 、 Apache FW・ライブラリ jQuery 開発ツール PhpStorm、 REDMINE 、GitLab、 GitHub Copilot CI・テスト Jenkins、Ansible ※2024/6/6時点での情報です。 開発言語は PHP 、 フレームワーク は配配メールのものをベースに構築されています。 配配メールをベースにしつつ、 API 連携やメールリレーなどの大量メール配信機能をより強化した仕組みで構築されています。 初期リリースから約10年間、お客様のシステムのメール配信を支えています。 現在は ベトナム のオフショアチームが中心となって開発しています。 blastmail & blastengine 図１０：blastmail & blastengineの技術スタック blastmail と blastengine は、独自開発した配信エンジンと大規模ネットワークにより、280万通/時の超高速配信を実現した クラウド 型メール配信サービスです。 開発拠点は 東京 で、グループ会社である ラク スライト クラウド が扱っているプロダクトになります！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 TypeScript、 JavaScript 、 PHP 、 Java 、Go MW Apache 、nginx、jetty、 PostgreSQL 、MongoDB、RabbitMQ、 Memcached 、 Postfix FW・ライブラリ React、Laravel、 CakePHP 、SpringBoot 開発ツール Docker、GitLab、 Redmine 、StoryBook、OpenAPI、GitBook、Slack、 AWS 、 GitHub Copilot CI・テスト GitLab-CI、Jenkins、SonarQube、Jest、ReactTestingLibrary、cypress、 PHPUnit 、 jUnit ※2024/6/6時点での情報です。 マルチな言語環境、マイクロサービスの最適化を目指して日々邁進中です。 直近ではフロントエンドとバックエンドの分離を進めており、より ユーザビリティ や可搬性の高いシステムとサービス品質の向上を目指しています。 フロントエンドの技術スタック ラク スには各プロダクト開発チームの他に、フロントエンド開発を専門とする「フロントエンド開発課」があります。 楽楽シリーズ・ ラク スシリーズの各 SaaS 製品における新機能追加、パフォーマンス向上、技術的改善や刷新などを行っています。 様々なサービスにおいて活躍できる横断組織として、多様な業務に挑戦しています！ ◆ 技術スタック一覧 カテゴリ 内容 使用言語 HTML、 CSS 、 JavaScript 、TypeScript FW・ライブラリ React、MUI、RHF、zod、Tanstack Query、zustand、jotai、axios、Sass、Vite、webpack、ESLint、Prettier、Storybook、msw、Vue.js、Neos Flow、axios、npm、Sass 開発ツール GitLab、 GitHub 、ChatGPT Teams、 GitHub Copilot、 Redmine 、PhpStorm、 VSCode 、Swagger、 Figma CI・テスト GitLab CI、 GitHub Actions、Playwright、Jest、Vitest ※ JSP 、 jQuery は新規で作成しませんが、既存機能の理解や改修を行うことはあります。 ※2024/6/6時点での情報です。 インフラ・SREの技術スタック 前述した10プロダクトを支えているのが、インフラ部門になります。 今回はインフラの技術スタックだけでなく、社内バックオフィス業務の自動化を推進して頂くSREの技術スタックについてもご紹介したいと思います！ なお、インフラ部門の開発拠点は 大阪、東京 、SRE部門は 東京 です。 インフラ まずは、インフラの技術スタックをご紹介します。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 Python 、 PHP プラットフォーム On-Premise、 AWS （EC2、ECS、EKS、RDS、S3、Lambda など） ネットワーク Cisco 、 Dell 、Fortinet、F5Networks OS CentOS 、 Amazon Linux 仮想化基盤 VMware 、Nutanix MW MySQL 、 PostgreSQL 、 Apache 、 Tomcat 、Nginx など IaC Ansible、Terraform その他ツール Git、Jenkins、 Selenium 、Rundeck、Serverspec、 GitHub Copilot 運用・監視 Zabbix、Grafana、Prometheus、ElasticStack ※2024/6/6時点での情報です。 9割のサービスリソースをオンプレミスで構築しております。 オンプレミス環境でも自動化など、なるべくソフトウェア視点のアプローチが出来るようにHCIで基盤構築し運用効率化をしています。 今後のアップデートとしては、 クラウド で先行構築した クラウド ネイティブなコンテナ環境やCI/CD環境などをオンプレミス環境にフィードバックし、自動化、自立化を推進しつつもコスト優位性を出せるシステムを構築していきます。 SRE 続いて、SREの技術スタックをご紹介します。 ◆ 技術スタック一覧 カテゴリ 内容 使用言語 Go プラットフォーム On-Premise、 AWS 仮想化基盤 Kubernetes MW PostgreSQL , Amazon Aurora 、Redis, Kafka FW・ライブラリ Gin、gRPC 開発ツール GitHub 、Docker CI/CD GitHub Actions、ArgoCD、Argo Workflows、Argo Event、 Hshicorp Vault IaC Terraform、Helm 運用・監視 Grafana Stack ※2024/6/6時点での情報です。 主にGoを利用しており、一部 Python も併用しています。今後はGoに言語は統一していく予定です。 新しい技術スタック調査などを進めながらノウハウを各サービスへ広めることで、開発部門全体の アーキテクチャ 刷新へ寄与していきます。 デザイナーの利用ツール ラク スはエンジニアだけでなく、デザイナーも10つのプロダクトを支えております。 職種としては、UIデザイナーとなりますのでこちらの利用ツールも紹介していきたいと思います！ デザイナーの所属拠点は、 東京 になります。 UIデザイナー ラク スのプロダクトのUIをデザインします！利用ツールは以下の通りです。 ◆ 技術スタック一覧 カテゴリ 内容 デザインツール Figma コミュニケーションツール Mattermost、Zoom、 Google Meet、FigJam ※2024/6/6時点での情報です。 ラク スのデザイナーはバックオフィスをはじめとする、業務システムの管理画面をデザインします。 業務 ドメイン の知識を学びながら、顧客の課題を理解し、業務をデザインの力で解決します。 業務 ドメイン の知識習得や、デザインの勉強会・輪読会などをおこなっています。 エンジニア/デザイナーの募集職種 前述した通り、 ラク スでは全10のプロダクトを扱っており、 「日本を代表する SaaS 開発エンジニア集団へ」 を目指し日々精進しております。 そんな弊社ですが、まだまだ人が足りておりません。 そこで、下記に 各開発拠点ごとの募集職種を関連するプロダクトとともに整理しました！ 皆様のご応募、お待ちしております！！ 【開発拠点：東京】 カテゴリ 募集職種 関連プロダクト マネジメント エンジニアリングマネージャー 楽楽精算・楽楽明細・楽楽勤怠 エンジニアリングマネージャー／オフショア 〃 開発 サーバサイドエンジニア／Java 楽楽精算・楽楽明細・楽楽勤怠 サーバサイドエンジニア／PHP blastmail・blastengine プロダクトマネージャー 楽楽精算・楽楽明細・楽楽勤怠 プロジェクトマネージャー 楽楽精算・楽楽明細・楽楽勤怠 プロジェクトマネージャー／PHP blastmail・blastengine プロジェクトマネージャー／フロントエンド 楽楽明細・楽楽勤怠・メールディーラー リードエンジニア／フロントエンド 楽楽精算 フロントエンドエンジニア 楽楽明細・楽楽勤怠・メールディーラー iOSエンジニア 楽楽精算 Androidエンジニア 楽楽精算 QAマネージャー 楽楽精算・楽楽明細・楽楽勤怠 QAエンジニア 楽楽精算・楽楽明細・楽楽勤怠 SETエンジニア 楽楽勤怠 PMO/品質管理 プロダクト横断 Webエンジニア プロダクト横断 デザイン デザインマネージャー／プロダクト プロダクト横断 UIデザイナー／アシスタントマネージャー 楽楽精算 UIデザイナー 楽楽明細・楽楽販売・メールディーラー・配配メール UIデザイナー／ポテンシャル採用 楽楽明細・楽楽販売・メールディーラー・配配メール ※2023/5時点での情報です。 【開発拠点：大阪】 カテゴリ 募集職種 関連プロダクト マネジメント エンジニアリングマネージャー 楽楽販売・メールディーラー・配配メール エンジニアリングマネージャー／インフラ 〃 開発 リードエンジニア／PHP 〃 サーバサイドエンジニア／PHP 〃 プロジェクトマネージャー 楽楽販売 プロダクトマネージャー 楽楽販売 ブリッジSE MailDealer インフラ インフラエンジニア メールディーラー・配配メール・楽楽販売・Curumeru ※2023/5時点での情報です。 過去イベント動画を Youtube で公開中 弊社 ラク スでは、毎週技術イベントを開催しております。 現在 Youtube の「 ラク スチャンネル」にて、過去イベントの アーカイブ 動画を公開中です！ 各プロダクトの最前線で活躍しているエンジニアたちが、社内の取り組みを発信していますので是非お時間ありましたらご確認ください。 youtube.com なお、最新の アーカイブ 動画は ラク スDevelopers会員（技術イベント時に登録できるメール会員）限定に公開しております。 もし最新 アーカイブ 動画を見てみたい！という方、まずは技術イベントにご参加いただけますと幸いです！ ラク スconnpassページ ラクス - connpass 終わりに ラク スの技術スタックにご興味いただけたでしょうか？ 弊社の中では大型開発の楽楽精算を初め、様々なプロダクトが存在しております。 本ブログにより、1つでも多くプロダクトの名前を覚えていただけたら幸いです。 また弊社では、前述した通り募集職種が多くあります。 もし、どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っておりますのでお気軽に以下フォームよりお申込みください。 カジュアル面談お申込みフォーム カジュアル面談について | 株式会社ラクス キャリア採用 長くなりましたら、今後とも ラク スエンジニアブログをよろしくお願いします。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 「自動化（オートメーション／Automation）」 今、この言葉を聞いて胸がときめいた方に必見です！ 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・ 自動化大好きエンジニアLT会 ・ 自動化大好きエンジニアLT会 - vol.2 ・ 自動化大好きエンジニアLT会 - vol.3 ・ 自動化大好きエンジニアLT会 - vol.4 ・ 自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を構築_運用するまで Python製BDDツールでテストを自動化してみた ansible_specでテストをする話 SaasサービスのアプリをAnsibleでデプロイしている話 Ansibleの最新の動向を追ってみた ラクス共通Ansibleコードテンプレートを作った話 Rundeckの紹介 Rundeck,Ansibleを利用したImmutable検証環境構築 GitHub ActionsでGASのデプロイを自動化した 10年前に初めてVBAで業務自動化したときの思い出 ルーティンワークがあったら自動化しよう～バッチ処理のスゝメ～ Firebase + Boltで始める自動化のススメ 開発検証環境の自動化 App Store Connect APIキー対応してみた AWS CDK & CodeBuildの活用例とハマりポイント JobArrangerを用いた自動化の話 オートスケールする GitHub Actions セルフホストランナーを構築してる話 terraform plan 結果の検証を自動化するぞ！ with Conftest 自動化を習慣化する コーポレートエンジニアがタスク依頼をZapierで自動化した話〜いい自動化のすすめかた〜 SonarCloudをGitHub Actionsで自動化して品質が見えるようになった話 採用強化中の関連職種 終わりに 手動テストやインフラ構築は自動化しよう 発表者： @M_Yamashii さん speakerdeck.com ◆発表内容 ・インフラのコード化を行い、CI/CDパイプラインを構築 ・構築結果 　→開発者は GitHub にPush、マージするのみでデプロイまで可能 　→テストやインフラ構築に時間を取らず開発に専念可能 API テスト品質を向上させる Datadog Synthetic Monitoring 発表者： gtongy さん docs.google.com ◆発表内容 ・ API テスト自動化するに至った経緯 ・ API テストを自動化した話 コード品質の貯金を今日から始めよう！ ・ API テスト自動化によって、実装に当てる時間をまるっと削れる ・ 潜在的 なバグを未然に防げる基盤を作成 ・はじめは愚直。ただ一度設定すれば立派な資産に API テスト自動化とテストピラミッド 発表者： tom_asa さん APIテスト自動化とテストピラミッド from 友隆 浅黄 www.slideshare.net ◆発表内容 ・何のために自動化するのか？ ・PC/ スマホ アプリのE2Eテスト自動化の事例 ・テスト範囲を決めUIを通さずに出来ることを考えよう TestLink にテスト結果を自動的に登録 発表者： t_iseki さん speakerdeck.com ◆発表内容 ・ TestLink とは？ ・なぜ TestLink ？ ・めんどくさいことは機械に！ 　→ REST API を使ってテスト結果を登録 ・ TestLInk での困りごと Cypressでサクッと始めるE2Eテスト 発表者： 片岡　基 さん speakerdeck.com ◆発表内容 ・Cypressとは？ 　→特徴、インストール&起動～テスト実行方法 ・Cypress Studioとは？ 　→シナリオ実行～テスト実行方法 　→豊富な機能6選 自動テスト環境を構築_運用するまで 発表者： wanko さん speakerdeck.com ◆発表内容 ・アプリとサイトの自動テスト環境をゼロベースで構築した話 ・苦労したこと 　① iOS を動かせるようになるまで苦労した 　②端末の調達やツールの選定を考える必要があった Python 製BDDツールでテストを自動化してみた 発表者： ijikeman さん Python製BDDツールで自動化してみた from KeijiUehata1 www.slideshare.net ◆発表内容 ・BDD（ビヘイビア駆動開発）ツールの特徴 ・サンプルの実行例 ・メンテナンス後の確認結果 ansible_specでテストをする話 発表者： ijikeman さん Ansible specでテストをする話 from KeijiUehata1 www.slideshare.net ◆発表内容 ・ansible_specとは ・Ansibleのインベントリファイルとプレイファイルブックを使用してserverspecを実行 ・ansible_specの改良 ※改良したプログラムは Qiita をご確認ください Saas サービスのアプリをAnsibleでデプロイしている話 発表者： ijikeman さん SaasサービスのアプリをAnsibleでデプロイしている話 from KeijiUehata www.slideshare.net ◆発表内容 ・Ansible Playbookの事例 ・Ansibleのいけてないところ4つ ・おまけ）Ansible非同期処理について Ansibleの最新の動向を追ってみた 発表者： ijikeman さん Ansibleの最近の動向を追ってみた from KeijiUehata1 www.slideshare.net ◆発表内容 ・Ansibleのリリース年表 ・ansible-coreとansible（コミュニティパッケージ）のメンテナンスポリシー ・おまけ） python 、ansible-core、ansibleのバージョンを指定できるDockerfileを作ってみた ラク ス共通Ansibleコードテンプレートを作った話 発表者： ijikeman さん ラクス共通Ansibleコードテンプレートを作った話 from KeijiUehata1 www.slideshare.net ◆発表内容 ・Ansibleテンプレート化した背景 ・Ansibleテンプレート化の事例 　→共通処理、 ミドルウェア Rundeckの紹介 発表者： akio_shimonishi さん speakerdeck.com ◆発表内容 ・自動化とは？ ・自動化ツール「Rundeck」の紹介 ・サイト更新を自動化した話 Rundeck,Ansibleを利用したImmutable検証環境構築 発表者： NAGAKE さん speakerdeck.com ◆発表内容 ・Immutableとは？ ・複数バージョン毎の検証環境を構築した事例 　→利用ツール（Rundeck、Ansible、 GitHub 、仮想化基盤） ・困ったこと、まとめ GitHub ActionsでGASのデプロイを自動化した 発表者： shiorin さん Github Actionsで GASのデプロイを自動化した from ShioriSawada www.slideshare.net ◆発表内容 ・ログラスでのGAS活用事例 ・これまでのデプロイ方法と改善点 ・自動化の方法とは？ 10年前に初めて VBA で業務自動化したときの思い出 発表者： tsuemura さん speakerdeck.com ◆発表内容 ・データ入力の仕事を VBA で自動化した話 ・ Excel 関数による生成の問題点 ・自動化によって改善したこと ・自動化によって改善しなかった（改悪された）こと ルーティンワークがあったら自動化しよう～ バッチ処理 のスゝメ～ 発表者： 白栁隆司 さん speakerdeck.com ◆発表内容 ・何のために自動化するの？ ・自動化の基準とは？ ・ バッチ処理 （ Windows ）やShell（ UNIX 系）の活用方法 ・ バッチ処理 のコツ Firebase + Boltで始める自動化のススメ 発表者： mako_makok さん speakerdeck.com ◆発表内容 ・勉強会情報を毎日通知してくれるSlackアプリを作った話 ・使用ツールの利点、注意点 　→Cloud Functions（Firebase） 　→Firebase FireStore 　→Bolt For JavaScirpt 開発検証環境の自動化 発表者： Takahiro Yamada さん 開発検証環境の自動化@自動化大好きエンジニアLT会 - vol.2 from Takahiro Yamada www.slideshare.net ◆発表内容 ・専有リモート開発環境を構築した話 ・しんどかったところ、手付かずなところ 　→URLの正規化 　→ MySQL の初期化コスト App Store Connect API キー対応してみた 発表者： saten さん speakerdeck.com ◆発表内容 ・ App Store Connectの二段階認証必須で起きた問題 ・ Apple 周りのCI/CD 　→ App Store Connect API キーで対応 AWS CDK & CodeBuildの活用例とハマりポイント 発表者： yukiarrr さん speakerdeck.com ◆発表内容 ・ AWS CDKとは？ ・ AWS CodeBuildとは？ ・ AWS CDK & CodeBuildを使いPRごとにレビュー用の環境を構築した話 JobArrangerを用いた自動化の話 発表者： ryuhei55225 さん speakerdeck.com ◆発表内容 ・JobArrangerとは？ ・JobArrangerを用いたジョブ管理の仕組み ・JobArrangerの便利機能 ・JobArrangerでの苦労談 オートスケールする GitHub Actions セルフホストランナーを構築してる話 発表者： miyajan さん オートスケールする GitHub Actions セルフホストランナーを構築してる話 from Jumpei Miyata www.slideshare.net ◆発表内容 ・ GitHub Actionsとは？ ・実現したいこと、実現方法 　→ジョブの実行に合わせてオートスケールするセルフホストランナープールの構築 ・実際に使って分かった辛い点 terraform plan 結果の検証を自動化するぞ！ with Conftest 発表者： Futa Hirakoba さん speakerdeck.com ◆発表内容 ・Terraformとは？ ・terraform planの結果を自動で検証した話 　→背景、テスト方法の事例 　→plan結果をconftestで検証 ・Conftestの導入によって期待できること ・Conftestを使ってみての感想 自動化を習慣化する 発表者： yasuhiroki さん speakerdeck.com ◆発表内容 ・自動化を毎日するには？ 　→自動化のハードルを下げる ・過度な自動化は技術的負債になるのでは？ 　→そうならない努力は必要である ・技術的負債を残さない努力とは？ 　→小さく作る、テスト可能にする・・・など ・自動化のネタ探し≒ 言語化 コーポレートエンジニアがタスク依頼をZapierで自動化した話〜いい自動化のすすめかた〜 発表者： kaori_cho さん speakerdeck.com ◆発表内容 ・いい自動化とは、心のハードルを下げてくれるもの ・心のハードルを下げる自動化 3ステップ 　①観察する 　②てんびんにかける 　③お試しする SonarCloudを GitHub Actionsで自動化して品質が見えるようになった話 発表者： yusuke_sasaki さん docs.google.com ◆発表内容 ・SonarCloudとは？ ・ GitHub Actionsで自動化する話 　→SonarCloud導入は簡単！ 　→公式が導入手順を示してくれている 採用強化中の関連職種 株式会社 ラク スでは、エンジニアを積極的に募集しております！ 現在募集中の関連職種は以下の通りです。 開発拠点 職種 東京 インフラエンジニア／マネージャー（東京） | 株式会社ラクス インフラエンジニア[東京/楽楽明細] | 株式会社ラクス インフラエンジニア[東京/楽楽労務] | 株式会社ラクス SREエンジニア[東京/インフラ] | 株式会社ラクス 大阪 インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス インフラエンジニア（大阪） | 株式会社ラクス ※2021/11/25時点での情報です。 終わりに 自動化大好きエンジニアたちが語る、効率化・品質向上Tipsはいかがでしたか？ 自動化に関するTipsが幅広く、イベント終了時は頭がパンパンになりますよ！ また、発表者たちの自動化に対する熱量も高いため毎回大盛況のイベントとなっております。 主催側としても大変有難い気持ちでいっぱいです。 最後までお読みいただきありがとうございました！ 是非明日から始める、自動化ライフのご一助となれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 多言語対応とは さっそく環境準備から message.propertiesを作成する Configを設定する ResourceBundleMessageSourceを継承した独自クラスを作成する Controllerから作成したMultiMessageSourceを呼び出す 実行してみる まとめ はじめに はじめまして、バックエンドエンジニアのryrkssです。 今回、担当する開発業務にて、 Java の フレームワーク の中でも有名な Spring Framework にあるSpring Bootを使用して、多言語対応しましたのでそのお話をさせていただきたく思います。 多言語対応で調べたときの記事で動的ではない言語対応方法(ユーザの言語設定に左右されない)の記事が多い印象でした。 たしかにサンプルとしてはいいかもしれないんですが、実際のアプリケーションでは 動的に言語を切り替えたい はずです。 それをSpring Boot + Java で実現する１つの方法を記載したいと思います。 今回のゴールはブラウザ設定に応じた言語で Json レスポンスを返却するというところにおきます。 Spring Bootについてはこちらのブログでも紹介されておりますので参考までに。 ・ 【入門】Spring Bootとは～実践まで - RAKUS Developers Blog | ラクス エンジニアブログ 多言語対応とは その名前の通り、様々な言語に対応することです。 ※念のため補足ですが、ここでいう言語は 話し言葉 の言語であり、 プログラミング言語 ではありません。 さっそく環境準備から こちらは本記事の本題ではないので、さくっと説明します。 以下に手順を書いていきますが、皆さんのやりやすい方法で実行環境を作成してください。 Spring Initializrを使ってプロジェクトを作成 依存関係に org.springframework.boot:spring-boot-starter-web を追加 ※ lombok はお好みで。本記事では使用しています。 Controllerとレスポンスオブジェクトを作成 アプリケーションを実行する 　 Controller @RestController public class MultilingualController { @GetMapping( "/message" ) public ResponseData message() { return new ResponseData( "多言語対応" ); } } レスポンスオブジェクト @Value public class ResponseData { String message; } これでPostmanなどから API を叩けば、以下のような Json 形式でボディレスポンスが返ってくると思います。 レスポンス { " message ": " 多言語対応 " } ただ見ての通り、固定値の 多言語対応 の文字列を返しているだけなので、 当たり前ですが今のままでは他の言語で返してはくれません。 次からいよいよ多言語対応の実装に入っていきましょう！ 本題に入るので順序立てて説明していきます。 message.propertiesを作成する 実際に Json へ返すメッセージをpropertiesファイルで定義します。 ※ yaml でも可能ですのでこちらもお好みで。 本記事はpropertiesの例のみ記載しますので、 yaml の場合は適宜変換してお読みください。 Springでメッセージ管理を行いたい場合、基本的に org.springframework.context.MessageSource を使用します。 このクラスをDIし、使用することでpropertiesファイルから指定されたキーに紐づくメッセージが取得できるようになります。 まずはメッセージの出力元となるpropertiesファイルから作成します。 src/main/resources/ に以下2ファイルを配置し、それぞれ key= value の形でメッセージを記載します。 messages_ja.properties (日本語) application.success=成功 application.error=失敗 messages_en.properties (英語) application.success=succeeded application.error=failed デフォルトはmessages.propertiesが使用されますが、 messages_{ロケール}.properties のように末に対応したい言語の ロケール をファイル名に使用することでリク エス トにより使用するmessagesファイルを動的に振り分けることができます。 ※propertiesで用意していない ロケール がリク エス トで飛んできた場合にmessages.propertiesファイルが使用されます。ここでは分かりやすいように ja , en のみの用意で話を進めます。 ここでのポイントはmessagesプロパティ間でのキーは必ず同一にすることです。 MessageSource を使用するとき、propertiesファイルにあるキー名を指定してそれに紐づく Value を取得する動きとなります。 propertiesファイルの書き方は色々あるので気になる方は調べてください。 これで、出力するメッセージの元は作成できました。 続いて MessageSource の設定をConfigファイルに定義していきたいと思います。 Configを設定する xml ベースで設定もできますが、今回は Java ベースで設定を記述していきます。 ※個人的にはJavaConfigの方が分かりやすくて好きです。 ここでは MessageSource のベース設定をしていきます。 @Configuration public class AppConfig { @Bean public MultiMessageSource messageSource() { MultiMessageSource messageSource = new MultiMessageSource(); // ① messageSource.setBasenames( "messages" ); // ② messageSource.setDefaultEncoding(StandardCharsets.UTF_8.name()); // ③ return messageSource; } } ① MessageSource の実装クラス ResourceBundleMessageSource を継承してカスタマイズする独自クラス 簡単に言うとここでリク エス トヘッダーから Accept-Language を読み取り、それに応じたmessages_xx.propertiesの取得結果を返します。 ※詳細は後述します。 ② どのpropertiesファイルを取得対象とするか resources からの 相対パス かつprefix( _ まで)で定義 ※例: resources/sample/messages_ja.properties → sample/messages また、 messageSource.setBasenames("messages", "sample/paths") のように複数定義することも可能となっており、 自由に定義できるのでアプリケーションの設計により柔軟に対応できると思います。 ③ messages.propertiesを解釈する 文字コード をセット ResourceBundleMessageSourceを継承した独自クラスを作成する ここでは実際にリク エス トの情報を元に動的に messages_xx.properties からメッセージを取得する部分を作っていきます。 といってもこちらで実装する部分は少なく、Springに用意されている AcceptHeaderLocaleResolver というクラスが ロケール の判定を行い、returnしている getMessage メソッドで振り分けを担ってくれるので、その設定を定義してあげるくらいの実装になります。 public class MultiMessageSource extends ResourceBundleMessageSource { @Autowired HttpServletRequest request; // ① public String getMessage(String key, Object ... params) { // ② AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver(); // ③ localeResolver.setDefaultLocale(Locale.JAPANESE); // ④ localeResolver.setSupportedLocales(List.of(Locale.JAPANESE, Locale.ENGLISH)); // ⑤ return super .getMessage(key, params, localeResolver.resolveLocale(request)); // ⑥ } } ① HttpServletRequestをDIする 動的にmessages_xx.propertiesを振り分けるための情報のメインがこの中にあります。 このリク エス トヘッダー内の Accept-Language に設定されている値を⑥で出てくる localeResolver.resolveLocale(request) で使用します。 このヘッダーにはブラウザの言語設定の情報が入ってくるので、言語に応じた情報を返却するメインの情報源となります。 ② 呼び出すメソッドを定義 第一引数：messages_xx.propertiesに設定しているキー 第二引数～：messages_xx.propertiesにパラメータを設定している場合に使用 戻り値：Stringで返ります(messages.propertiesの Value 値) ③ 変換のメインクラスとなる AcceptHeaderLocaleResolver の インスタンス 化 ④ デフォルト ロケール を設定 ここで名前の通りデフォルトで使用する言語情報をセットします。 デフォルト ロケール がmessagesの振り分けに使用されるパターンは以下です。 リク エス トヘッダー内の Accept-Language がNULLの場合 後述する SupportedLocales に値がセットされていない場合 リク エス トヘッダーの言語設定と SupportedLocales の値がマッチしない場合 ⑤ サポート ロケール を設定 ここでは作成するアプリケーションがサポートしている言語は何かを明示的に指定します。 ※List型で渡すことに注意してください。 サポート ロケール がmessagesの振り分けに使用されるパターンは以下です。 サポート ロケール とリク エス トヘッダーの言語設定がマッチする場合 ⑥ 親クラス ResourceBundleMessageSource の親の親.... AbstractMessageSource のgetMessageメソッドの結果を返却 第一引数：messages_xx.propertiesに設定しているキー 第二引数～：messages_xx.propertiesにパラメータを設定している場合に使用 第三引数：Locale{ ロケール }を指定 ※こちらを使用してどのmessages_xx.propertiesから Value を引いてくるかを判定します 今回の多言語対応のメインである、第三引数で行っている localeResolver.resolveLocale(request) について説明します。 AcceptHeaderLocaleResolver クラスの resolveLocale メソッドでリク エス トヘッダーに応じた ロケール を取得してくれます。 そのため、 resolveLocale メソッドには引数として HttpServletRequest を渡してあげるだけでいわゆる動的な多言語対応が実現します。 resolveLocale メソッドでやっていることは前述した④、⑤で設定した内容とリク エス トを使用して ロケール 情報を返しています。 ...ただ正直この中身の作りはいまいちな気がしています。。 個人的には想定外の Accept-Language が来たときは一律デフォルト ロケール を設定してくれればいいと思っているのですが、確実に想定外が発生しないような動きにするにはデフォルト ロケール とサポート ロケール を設定する必要があります。 気になる方はそんなに難しいことはしていないので resolveLocale の中身を見てみてください。 また、私が調べてみた限りの情報なので、もしかしたらもっとうまい方法があるかもしれません。 これで多言語対応の内部ロジックは終わりです。 あとはControllerを少し修正して結果を確認してみましょう！ Controllerから作成した MultiMessageSource を呼び出す 冒頭で作成したレスポンスをべた書きしている MultilingualController を修正します。 @AllArgsConstructor @RestController public class MultilingualController { private final MultiMessageSource messageSource; // ① @GetMapping( "/message" ) public ResponseData message() { String message = messageSource.getMessage( "application.success" ); // ② return new ResponseData(message); } } ① カスタマイズしたメッセージクラス MultiMessageSource をDIする ② getMessage メソッドをコールし、引数にmessages_xx.propertiesに定義されているキーを渡す 　※ここではキーだけ渡してますが、パラメータを設定している場合はそれも渡すことが可能です。 実行してみる 実際に想定通りの言語で返ってくるか API を実行してみましょう。 Accept-Language=ja(日本語) 指定した通り日本語でメッセージが返ります。 { " message ": " 成功 " } Accept-Language=en(英語) 指定した通り英語でメッセージが返ります。 { " message ": " succeeded " } Accept-Language=de(ドイツ語)-アプリケーションで想定していない 言語コード 存在しない場合デフォルト ロケール で指定した言語でメッセージが返ります。 { " message ": " 成功 " } Accept-Languageヘッダーなし デフォルト ロケール で指定した言語でメッセージが返ります。 { " message ": " 成功 " } まとめ 長々と書いてきましたが、実際にコーディングするのはごくわずかです。 ほとんどはSpringの標準パッケージの中でよしなにやってくれるので非常に簡単に実装できました。 もちろん他にも作りこめば色々できると思います。 また、今回はブラウザの言語設定によってメッセージを切り替える例をご紹介しましたが、 他にもSpringで多言語対応をするやり方は調べれば出てきます。 例えばUI上で言語を選択して切り替えることもSpringの機能を使用して比較的簡単にできるようです。 気になる方は調べてみてください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、tatsumiです。 いきなりですが、 PHP の標準で用意されている関数について、いくつぐらい知っていますか？ 私は今まで PHP での開発経験がなく、7月ごろから PHP の勉強を始めたので、正直ほとんど知りません。。。 ただ、実際に PHP の開発に携わるようになって、関数を知っていることの重要性を改めて実感しました。 PHP を始め、どの言語でも言えることですが、 コードを読むのも、コードを書くのも、関数を”知っている”か”知らない”かで大きく変わってきます。 例えば、コードを読む場合、 関数を知っていればある程度スラスラ読めますが、関数を知らないと新たな関数が出てくる度に調べないといけなくなります。 また、コードを書く場合は、 コードを読む場合と同様に関数を知らないと毎回調べることになりますし、 場合によっては標準で用意されている関数を使わずに自力で実装してしまう、というケースもあると思います。 （実際に私も、自力で実装した後に関数が用意されていることを知ってショックを受けた経験が何度かあります。。。） PHP では多くの関数が標準で用意されています。 この記事では、その中でカテゴリ別によく使いそうな PHP の関数をまとめてみました。 PHP を使う際、こういう関数ってないのかなって思った時の参考にしてもらえればと思います。 www.php.net 文字列操作関数 strlen／mb_strlen（文字列の長さを取得） strcmp／strcasecmp（文字列を比較） substr/mb_substr（文字列を取り出す） trim（先頭と末尾の空白を取り除く） substr_replace／preg_replace（文字列を置換） strpos／preg_match（文字列を探す） strstr（指定文字以降の文字列を取得） substr_count（文字列をカウント） str_repeat（文字列の反復） str_pad（文字埋め） explode（文字列を分割） sprintf（フォーマット） 日付と時刻関数 date（現在日付を取得） getdate（日付を配列で取得） checkdate（日付の妥当性をチェック） mktime（指定した日付のタイムスタンプを取得） time（現在時刻を取得） gettimeofday（現在時刻を取得） ファイル操作関数 copy（ファイルをコピーする） fopen（ファイルを開く） fclose（ファイルを閉じる） fgetc（ファイルから1文字取得） fgets／fgetss（ファイルから1行取得） fpassthru（ファイル内容すべてを取得） fread（ファイルから指定した文字数分取得） readfile（ファイルを出力） filesize（ファイルサイズを取得） file_exists（ファイルの存在チェック） 数学関数 abs（絶対値） ceil（端数の切り上げ） floor（端数の切り捨て） max（最大値を取得） min（最小値を取得） 変数操作関数 empty（変数が空かチェック） intval（変数を整数値として取得） strval（変数を文字列として取得） settype（変数を指定した型に変換） gettype（指定した変数の型を取得） 配列関数 array（配列を生成する） list（配列を値を変数に代入する） PHP よく使う関数 まとめ 文字列操作関数 PHP: String 関数 - Manual strlen／mb_strlen（文字列の長さを取得） strlen(文字列) : int 文字列の長さ（バイト数）を取得します。 文字数を取得したい場合は「mb_strlen」関数を使います。 実行結果は以下のようになります。 <?php 　 strlen ( 'abc' ) --> 3 　 strlen ( 'あいう' ) --> 6 ?> <?php 　 mb_strlen ( 'abc' ) --> 3 　 mb_strlen ( 'あいう' ) --> 3 ?> strcmp／strcasecmp（文字列を比較） strcmp(文字列1, 文字列2) : int PHP で文字列の比較を行います。 比較結果として返される値は以下の通りです。 　文字列1 ＜ 文字列2 ⇒ 負の整数 　文字列1 ＞ 文字列2 ⇒ 正の整数 　文字列1 ＝ 文字列2 ⇒ 0 「strcmp」関数では大文字と小文字は区別されます。もし区別したくない場合は「strcasecmp」関数を使います。 実行結果は以下のようになります。 <?php 　 strcmp ( 'abc' , 'def' ) --> -197379 　 strcmp ( 'abc' , 'ABC' ) --> 2105376 　 strcmp ( 'abc' , 'abc' ) --> 0 ?> <?php 　 strcasecmp ( 'abc' , 'def' ) --> -3 　 strcasecmp ( 'abc' , 'ABC' ) --> 0 　 strcasecmp ( 'abc' , 'abc' ) --> 0 ?> 関数を使わず==や===でも比較することができます。 ただし、それぞれで微妙に比較結果が変わるため、用途に合わせてどれを使うかを検討しましょう。 substr/mb_substr（文字列を取り出す） substr(文字列, 開始位置 [, 文字数]) : string PHP で開始位置から文字数分の文字列を抽出します。 「substr」関数はマルチバイト文字に対応していないため、日本語を用いる場合は「mb_substr」関数を使いましょう。 実行結果は以下のようになります。 <?php 　 substr ( 'abcde' , 0 ) --> "abcde" 　 substr ( 'abcde' , 1 ) --> "bcde" 　 substr ( 'abcde' , 1 , 3 ) --> "bcd" ?> <?php 　 mb_substr ( 'あいうえお' , 0 ) --> "あいうえお" 　 mb_substr ( 'あいうえお' , 1 ) --> "いうえお" 　 mb_substr ( 'あいうえお' , 1 , 3 ) --> "いうえ" ?> 引数の開始位置や文字数に負の数を指定した場合は、末尾からの開始位置、文字数になります。 <?php 　 substr ( 'abcde' , -3 ) --> "cde" 　 substr ( 'abcde' , 1 , -1 ) --> "bcd" ?> <?php 　 mb_substr ( 'あいうえお' , -3 ) --> "うえお" 　 mb_substr ( 'あいうえお' , 1 , -1 ) --> "いうえ" ?> trim（先頭と末尾の空白を取り除く） trim(文字列 [, 取り除く文字]) : string 文字列の先頭と末尾から、空白文字を取り除きます。 取り除く文字が指定されている場合は、文字列の先頭と末尾から指定された文字を取り除きます。 ※「trim」関数で空白文字と見なされるのは" \t\n\r\0\x0B"なので、タブや改行を含みます。 実行結果は以下のようになります。 <?php 　 trim ( ' abc ' ) --> "abc" 　 trim ( ' abc ' , 'x' ) --> " abc " 　 trim ( 'xxxabcxxx' , 'x' ) --> "abc" ?> PHP では他に、先頭だけを対象にする「ltrim」関数や末尾だけを対象にする「rtrim」関数もあります。 substr_replace／preg_replace（文字列を置換） substr_replace(文字列1, 文字列2, 開始位置 [, 文字数]) : string 文字列1の開始位置以降の文字列を文字列2で置換します。 文字数が指定されている場合は、開始位置から指定された文字数分を置換します。 実行結果は以下のようになります。 <?php 　 substr_replace ( '1234567890' , '#' , 5 ) --> "12345#" 　 substr_replace ( '1234567890' , '#' , 5 , 2 ) --> "12345#890" ?> PHP では、引数の開始位置や文字数に負の数を指定した場合は、末尾からの開始位置、文字数になります。 「preg_replace」関数を使うと、 正規表現 を使用した置換が可能です。 preg_replace(検索文字列, 文字列1, 文字列2) 文字列1の中で、検索文字列に合致した文字列を文字列2へ置換します。 検索文字列は、 正規表現 を使った文字列を指定できます。 strpos／preg_match（文字列を探す） strpos(文字列1, 文字列2 [, 検索開始位置]) : int／false 文字列1の中で、文字列2が最初に現れる位置を探します。 文字列2が含まれない場合は、FALSEを返します。 実行結果は以下のようになります。 <?php 　 strpos ( 'abcdeabcde' , 'c' ) --> 2 　 strpos ( 'abcdeabcde' , 'f' ) --> FALSE 　 strpos ( 'abcdeabcde' , 'c' , 3 ) --> 7 ?> 「preg_match」関数を使うと、 正規表現 を使用した検索が可能です。 preg_match(文字列1, 文字列2 [, 配列] [, 動作フラグ] [, 検索開始位置]) : int／false 文字列1の中に文字列2が含まれるかを確認します。 含まれる場合は1、含まれない場合は0を返します。 文字列2には、 正規表現 を使った文字列を指定できます。 strstr（指定文字以降の文字列を取得） strstr(文字列1, 文字列2) : string／false 文字列1の中に文字列2が含まれるかを確認します。 含まれる場合は、文字列2を含んだ文字列の終わりまでを返します。 実行結果は以下のようになります。 <?php 　 strstr ( 'abcdefg' , 'cd' ) --> "cdefg" 　 strstr ( 'abcdefg' , 'xyz' ) --> FALSE ?> substr_count（文字列をカウント） substr_count(文字列1, 文字列2) : int 文字列1の中で文字列2の出現回数を返します。 実行結果は以下のようになります。 <?php 　 substr_count ( 'aabbbcccc' , 'b' ) --> 3 　 substr_count ( 'aabbbcccc' , 'd' ) --> 0 ?> str_repeat（文字列の反復） str_repeat(文字列, 反復回数) : string 文字列を反復回数分繰り返します。 実行結果は以下のようになります。 <?php 　 str_repeat ( "abc" , 3 ) --> "abcabcabc" ?> str_pad（文字埋め） str_pad(文字列, 文字列の長さ, 埋める文字, 文字埋めタイプ) : string 文字列の左、右、または両側を文字列の長さに合わせて、埋める文字で埋めます。 埋め込む位置は、文字埋めタイプで指定します。 左埋め：STR_PAD_LEFT、右埋め：STR_PAD_RIGHT、両側埋め：STR_PAD_BOTH 実行結果は以下のようになります。 <?php 　 str_pad ( "abc" , 8 , "X" , STR_PAD_LEFT ) --> "XXXXXabc" 　 str_pad ( "abc" , 8 , "X" , STR_PAD_RIGHT ) --> "abcXXXXX" 　 str_pad ( "abc" , 8 , "X" , STR_PAD_BOTH ) --> "XXabcXXX" ?> PHP では、埋める文字が指定されていない場合は、空白で埋められます。 埋める文字数が埋める文字の長さで均等に分割できない場合は、切り捨てられるので注意。 （マルチバイト文字を使用するときも注意） <?php 　 str_pad ( "abc" , 5 , "12345" , STR_PAD_LEFT ) --> "12abc" 　 str_pad ( "abc" , 8 , "あああああ" , STR_PAD_RIGHT ) --> 文字埋め部分が文字化けしてしまう ?> explode（文字列を分割） explode(区切り文字, 文字列 [, 要 素数 ]) : array 文字列を区切り文字で分割します。 要 素数 が指定されている場合は、先頭から要 素数 分を分割し、残りの文字列は配列の最後に格納されて返されます。 実行結果は以下のようになります。 <?php 　 explode ( " " , "aaa bbb ccc" ) --> [ "aaa" , "bbb" , "ccc" ] 　 explode ( " " , "aaa bbb ccc" , 2 ) --> [ "aaa" , "bbb ccc" ] ?> PHP では、文字列を分割する関数として「preg_split」関数や「str_split」関数もあります。 「explode」関数が簡単で汎用的に使えますが、用途に応じて PHP の関数を使い分けましょう。 sprintf（フォーマット） sprintf(フォーマット文字列 [, 任意の文字や値...]) : array フォーマット文字列に従い、任意の文字や値を使って文字列を生成します。 実行結果は以下のようになります。 <?php 　 sprintf ( "今日は%d年%d月%d日です。" , 2021 , 11 , 1 ) --> "今日は2021年11月1日です。" ?> 日付と時刻関数 PHP: 日付・時刻 関数 - Manual date（現在日付を取得） date(フォーマット [, 日時]) : string 現在日時をフォーマットに指定された形式で返します。 日時を指定した場合は、指定した日時をフォーマットに指定された形式で返します。 実行結果は以下のようになります。 <?php 　 date ( "Y年m月d日 H:i:s" ) --> "2021年11月1日 10:30:00" 　※ 現在日時が返される 　 date ( "Y年m月d日 H:i:s" , mktime ( 12 , 0 , 0 , 11 , 1 , 2021 )) --> "2021年11月1日 12:00:00" ?> フォーマットで使用できるフォーマット文字は以下のとおりです。 フォーマット文字 意味 a am または pm A AM または PM d 2桁の日付 D 3文字の曜日（Sun～Sat） f 月の英字（フルスペル） h 12時間単位の時間（00～12） H 24時間単位の時間（00～23） g 先頭に0をつけない12時間単位の時間（0～12） G 先頭に0をつけない24時間単位の時間（0～24） i 2桁の分（00～59） j 先頭に0をつけない日付（1～31） l 曜日の英字（フルスペル） L 閏年 は1、それ以外は0 n 先頭に0をつけない月（0～12）） m 2桁のの月（01～12） M 3文字の月（Jan～Dec） s 2桁の秒（00～59） S 英文の序数を表わす接尾語 (th ～ nd) t 指定した月の日数（28～31） U UNIX 時間（1970年1月1日からの秒数） w 数値で示す曜日（0～6） y 西暦（下２桁） Y 西暦（４桁） z その年の1月1日からの通算日 Z タイムゾーン のオフセット秒（-43200～43200） getdate（日付を配列で取得） getdate( [日時] ) : array 指定された日時の日付情報を配列で返します。 日時を指定しない場合は、現在日時の日付情報を配列で返します。 実行結果は以下のようになります。 <?php 　 $ today = getdate () 　 $ today [ "year" ] ---> "2021" 　 $ today [ "mon" ] ---> "11" 　 $ today [ "mday" ] ---> "1" ?> 返される配列のキーは以下のとおりです。 配列のキー 値 値の例 seconds 秒 0～59 minutes 分 0～59 hours 時 0～23 mday 月単位の日 1～31 wday 曜日の数値 0（日曜）～6（土曜） mon 月 1～12 year 年 4桁の西暦年数 yday 年単位の日 0～365 weekday 曜日の文字列 Sunday～Saturday month 月の文字列 January～December checkdate（日付の妥当性をチェック） checkdate(月, 日, 年) : bool 指定された日付が妥当かを確認します。 実行結果は以下のようになります。 <?php 　 checkdate ( 11 , 1 , 2021 ) ---> true 　 checkdate ( 13 , 1 , 2021 ) ---> false ?> 各パラメータのチェック内容は以下のとおりです。 パラメータ チェック内容 month 1～12の間かどうか day 指定されたmonthの日数の範囲内かどうか。（yearが 閏年 の場合も考慮される） year 1～32767の間かどうか mktime（指定した日付のタイムスタンプを取得） mktime(時, 分, 秒, 月, 日, 年) : int 引数で指定された日付のタイムスタンプを返します。 実行結果は以下のようになります。 <?php 　 mktime ( 12 , 30 , 30 , 11 , 1 , 2021 ) ---> 1635769830 ?> time（現在時刻を取得） time() : int 現在時刻のタイムスタンプを返します。 実行結果は以下のようになります。 <?php 　 time () ---> 1636085273 （現在時刻のタイムスタンプ） ?> gettimeofday（現在時刻を取得） gettimeofday() : array 現在時刻情報を配列で返します。 実行結果は以下のようになります。 <?php 　 $ currentTime = gettimeofday () ; 　currentTime [ "sec" ] ---> 1636085273 （現在時刻のタイムスタンプ値） ?> 返される配列のキーは以下のとおりです。 配列のキー 値 sec タイムスタンプ値 usec マイクロ秒の値 minuteswest GMT との差を分で表した値 dsttime サマータイム なら1、そうでない場合は0 ファイル操作関数 PHP: ファイルシステム 関数 - Manual copy（ファイルをコピーする） copy(コピー元のパス, コピー先のパス) : bool コピー元のファイルをコピー先にコピーします。 成功した場合はtrue、失敗した場合はfalseが返されます。 コピー先にファイルが既に存在する場合は上書きされるので注意！ サンプルコードは以下のとおりです。 <?php 　 copy ( "example.txt" , "example.txt.bak" ) ?> fopen（ファイルを開く） fopen(ファイル名, モード) : resource ファイルを指定されたモードで開きます。 ファイル名には、ファイルパスを含んだファイル名を指定します。 サンプルコードは以下のとおりです。 <?php 　 fopen ( "/home/example/file.txt" , "r" ) ?> モードには以下があります。 モード 意味 ファイル ポインタ ファイルが存在しない場合の挙動 r　　　　 読み込みモードで開く　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 先頭　　　 エラー r+ 読み込み／書き込みモードで開く 先頭 エラー w 書き込みモードで開く（ファイルの内容をクリア） 先頭 ファイルを新規作成　　　　　　　　 w+ 読み込み／書き込みモードで開く（ファイルの内容をクリア） 先頭 ファイルを新規作成 a 書き込みモードで開く（ファイルの内容はクリアせず追記） 末尾 ファイルを新規作成 a+ 読み込み／書き込みモードで開く（ファイルの内容はクリアせず追記） 先頭 ファイルを新規作成 x 書き込みモードで開く（ファイルが既に存在している場合はエラー） 先頭 ファイルを新規作成 x+ 読み込み／書き込みモードで開く（ファイルが既に存在している場合はエラー） 先頭 ファイルを新規作成 c 書き込みモードで開く（ファイルの内容はクリアせず先頭から追記） 先頭 ファイルを新規作成 c+ 読み込み／書き込みモードで開く（ファイルの内容はクリアせず先頭から追記） 先頭 ファイルを新規作成 fclose（ファイルを閉じる） fclose(ファイルポインタ) : bool ファイルを閉じます。 成功した場合はture、失敗した場合はfalseを返します。 サンプルコードは以下のとおりです。 <?php 　 $ file = fopen ( "/home/example/file.txt" , "r" ) ; 　 fclose ( $ file ) ; ?> fgetc（ファイルから1文字取得） fgetc(ファイルポインタ) : string 指定されたファイルポインタから1文字読み出します。 EOFの場合はfalseを返します。 サンプルコードは以下のとおりです。 <?php 　 $ file = fopen ( "/home/example/file.txt" , "r" ) ; 　 fgetc ( $ file ) ; ?> fgets／fgetss（ファイルから1行取得） fgets(ファイルポインタ) : string 指定されたファイルポインタから1行読み出します。 サンプルコードは以下のとおりです。 <?php 　 $ file = fopen ( "/home/example/file.txt" , "r" ) ; 　 fgets ( $ file ) ; ?> PHP の「fgetss」関数を使うと、取得した文字列からHTMLタグを取り除いた形の文字列を取得できます。 使い方は「fgets」関数と同様です。 fpassthru（ファイル内容すべてを取得） fpassthru(ファイルポインタ) : int ファイルポインタを EOF まで読み込み、結果を出力バッファに書き出します。 戻り値として、出力した文字数を返します。 この関数を実行後、「fclose」関数を実行しなくてもファイルは自動的に閉じられます。 PHP でファイルの先頭から出力する場合は、当関数を実行する前に「rewind」関数でポインタをリセットしておきましょう。 サンプルコードは以下のとおりです。 <?php 　 $ file = fopen ( "/home/example/file.txt" , "r" ) ; 　 fpassthru ( $ file ) ; ?> fread（ファイルから指定した文字数分取得） fread(ファイルポインタ, 取得するバイト数) : string 指定されたファイルポインタから指定されたバイト数分の文字を取得します。 第二引数は、文字数ではなくバイト数なので注意！ サンプルコードは以下のとおりです。 <?php 　 $ file = fopen ( "/home/example/file.txt" , "r" ) ; 　 fread ( $ file , 10 ) ; ?> 第二引数に「filesize」関数を使ってファイルサイズを指定すると、ファイル全文を取得できます。 readfile（ファイルを出力） readfile(ファイル名) : string ファイルの内容を出力します。 戻り値として、読み込んだバイト数を返します。 サンプルコードは以下のとおりです。 <?php 　 readfile ( "/home/example/file.txt" ) ; ?> filesize（ファイルサイズを取得） filesize(ファイル名) : int ファイルのサイズを取得します。 サンプルコードは以下のとおりです。 <?php 　 filesize ( "/home/example/file.txt" ) ; ?> file_exists（ファイルの存在チェック） file_exists(ファイル名) : int ファイルまたは ディレクト リが存在するかどうかを確認します。 存在する場合はtrue、存在しない場合はfalseを返します。 サンプルコードは以下のとおりです。 <?php 　 file_exists ( "/home/example/file.txt" ) ; ?> 数学関数 PHP: Math - Manual abs（絶対値） abs(数値) : int/float 指定された数値の絶対値を返します。 指定された数値がfloat型であった場合、戻り値の方もfloat型になります。 それ以外の場合はint型が返されます。 実行結果は以下のようになります。 <?php 　 abs ( 100 ) ---> 100 　 abs ( -100 ) ---> 100 ?> ceil（端数の切り上げ） ceil(数値) : float 指定された数値から、次に大きい整数を返します。 実行結果は以下のようになります。 <?php 　 ceil ( 100.1 ) ---> 101 　 ceil ( -100.1 ) ---> -100 ?> floor（端数の切り捨て） floor(数値) : float 指定された数値を超えない範囲で、最大の整数を返します。 実行結果は以下のようになります。 <?php 　 floor ( 100 ) ---> 100 　 floor ( 100.1 ) ---> 100 　 floor ( -100.1 ) ---> -101 ?> max（最大値を取得） max(比較する値1, 比較する値2 ... ) : mixed 比較する値の中で最大値を返します。 比較する値には、文字列も指定可能です。また、配列で渡すこともできます。 異なる型の値を引数として渡すのはやめましょう 実行結果は以下のようになります。 <?php 　 max ( 2 , 4 , 6 , 8 , 10 ) ---> 10 　 $ array = array ( 5 , 8 , 3 , 10 , 1 ) ; 　 max ( $ array ) ---> 10 ?> min（最小値を取得） min(比較する値1, 比較する値2 ... ) : mixed 比較する値の中で最小値を返します。 比較する値には、文字列も指定可能です。また、配列で渡すこともできます。 異なる型の値を引数として渡すのはやめましょう 実行結果は以下のようになります。 <?php 　 min ( 2 , 4 , 6 , 8 , 10 ) ---> 2 　 $ array = array ( 5 , 8 , 3 , 10 , 1 ) ; 　 min ( $ array ) ---> 1 ?> 変数操作関数 PHP: 変数操作 関数 - Manual empty（変数が空かチェック） empty(変数) : bool 指定された変数が空の場合はtrue、空でない場合はfalseを返します。 「empty」関数の結果一覧 値 結果 $val = 1 false $val = "" true $val = "0" true $val = 0 true $val = NULL true $val true $val = array() true $val = array(1) false intval（変数を整数値として取得） intval(変数, 基数) : int 引数の基数の値を基数とし、変数に指定された値をint型で返します。 基数が0の場合は、変数の値に基づいて基数を判断します。 変数の先頭が"0x"の場合は16進数、"0"の場合は8進数、それ以外の場合は10進数となります。 実行結果は以下のようになります。 <?php 　 intval ( 123 ) ---> 123 　 intval ( '123' ) ---> 123 　 intval ( '+123' ) ---> 123 　 intval ( '-123' ) ---> -123 　 intval ( 0123 ) ---> 83 　 intval ( '0123' ) ---> 123 　 intval ( 123 , 8 ) ---> 123 　 intval ( '123' , 8 ) ---> 83 　 intval ( true ) ---> 1 　 intval ( false ) ---> 0 ?> PHP でfloat型を扱いたい場合は、変数をfloat値で取得する「floatval」関数もあります。 strval（変数を文字列として取得） strval(変数) : string 変数に指定された値を文字列に変換してstring型で返します。 実行結果は以下のようになります。 <?php 　 strval ( 123 ) ---> 123 ?> settype（変数を指定した型に変換） settype(変数, 型) : bool 変数の値を指定された型に変換します。 変換に成功した場合はtrue、失敗した場合はfalseを返します。 型に指定できる値 "boolean"／"bool" "integer"／"int" "float"／"double" "string" "array" "object" "null" 実行結果は以下のようになります。 <?php 　 $ value = 123 ; 　 settype ( $ value , "bool" ) ---> $ value = 1 　 settype ( $ value , "int" ) ---> $ value = 123 　 settype ( $ value , "float" ) ---> $ value = 123 　 settype ( $ value , "string" ) ---> $ value = 123 　 settype ( $ value , "array" ) ---> $ value [ 0 ] = 123 ?> gettype（指定した変数の型を取得） gettype(変数) : string 指定された変数の型を返します。 型のチェックには、この関数ではなく「is_*」関数を使いましょう。 返される文字列 "boolean" "integer" "double" (float の場合は、"float" ではなく "double" が返されます) "string" "array" "object" "resource" "resource (closed)" ( PHP 7.2.0 以降) "NULL" "unknown type" 実行結果は以下のようになります。 <?php 　 $ value = 1 ; 　 gettype ( $ value ) ---> integer 　 $ value = 0.2 ; 　 gettype ( $ value ) ---> double 　 $ value = NULL ; 　 gettype ( $ value ) ---> NULL 　 $ value = 'abc' ; 　 gettype ( $ value ) ---> string ?> 配列関数 PHP: 配列 関数 - Manual PHP の配列に関しては、別の記事でまとめられていますので、そちらを参考にしてみてください。 PHPの配列機能のまとめ - RAKUS Developers Blog | ラクス エンジニアブログ 本記事では、上記記事で紹介されていない PHP の関数について記載します。 array（配列を生成する） array(値1, 値2, 値3 ...) : array 指定された値を用いて配列を作成します。 引数に指定した値に対して、0から添字が自動的に割り振られます。 値に"index => values"の形式で値を指定することで、 連想配列 を生成できます。 実行結果は以下のようになります。 <?php 　 $ values = array ( "りんご" , "バナナ" , "いちご" ) ; 　 $ values [ 0 ] ---> りんご 　 $ values [ 1 ] ---> バナナ 　 $ values [ 2 ] ---> いちご 　 $ values = array ( "a" => "りんご" , "b" => "バナナ" , "c" => "いちご" ) ; 　 $ values [ "a" ] ---> りんご 　 $ values [ "b" ] ---> バナナ 　 $ values [ "c" ] ---> いちご ?> list（配列を値を変数に代入する） list(変数1, 変数2, 変数3 ...) : array 配列の値を変数に代入します。 実行結果は以下のようになります。 <?php 　 $ values = array ( "りんご" , "バナナ" , "ぶどう" ) ; 　 list ( $ apple , $ banana , $ grape ) = $ values ; 　 $ apple ---> りんご 　 $ banana ---> バナナ 　 $ grape ---> ぶどう ?> PHP よく使う関数 まとめ 本記事では、 PHP の関数についてまとめてみました。 今回紹介した PHP の関数はごく一部で、 PHP では他にもたくさんの関数が用意されていますので、他にどんな PHP の関数があるのか興味があれば調べてみてください。 PHP でコードを書くときに、そういえばこんな関数あったな、と思い出せるだけでも全然違ってくると思います。 PHP の関数は自分で作成することもできるので、 PHP の標準で用意されていない関数があれば、自分で作ってみましょう。 それでは良き PHP ライフを！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、技術広報の yayawowo です。 皆さん！2021/11/21(日)に開催した JJUG CCC 2021 Fallに参加されましたでしょうか？ 今回は、 弊社エンジニアの登壇資料をまとめ させていただきましたので JJUG に参加した人、参加できなかった人のご参考になれば幸いです！ また、ロゴスポンサーとしても協賛させていただいております！ 目次 目次 ラクスエンジニアの登壇内容 勤怠管理サービスでの継続的テストの取り組み 変わりゆくAPI連携仕様との付き合い方 協賛内容 終わりに ラク スエンジニアの登壇内容 勤怠管理サービスでの継続的テストの取り組み 発表者： yuya yamaguchi 　　　　 2021/11/21 10:00〜 Track C (# jjug _ccc_c) Video:40min + Live:10min speakerdeck.com 楽楽勤怠の開発担当である山口さんより、 「勤怠管理サービスでの継続的テストの取り組み」というテーマで発表いただきました。 ◆発表内容まとめ 　 なぜ継続的テストを進めているのか 　１．勤怠管理サービスの特徴 　２．QA、SETエンジニアがいない 　３．リリースサイクルを短縮したい CIパイプラインへのテストの組み込み 　・CIパイプラインの対象範囲：Spring Boot 　・CIパイプラインへのテストの組み込みで利用したもの 　・4つのステージ構成（code/test/build/deploy) テストの自動化 　・自動化しているテスト（ ユニットテスト /パフォーマンステスト/E2Eテスト） 　・パフォーマンステストが自動化される前の問題 　　１．１つの Jmeter シナリオをテストするのに時間がかかる 　　　　→自動化されたので夜間に実施できる 　　２．手作業が多いので作業ミスが発生する 　　　　→Ansibleを実行するのみで発生しにくくなった 　　３．テスト結果を確認するためのグラフを作るのに大変 　　　　→Grafanaが自動的に作成してくれる まとめ 　・Gitlab CI上にテストの組み込み 　・パフォーマンステストの自動化 　　　　　　　　↓ 　継続的にテストをすることができる環境を構築することができた 視聴者からは 「パフォーマンステストの自動化、すごくコストかかってるので自動化したい」 「GitLab→ansibleでターゲットサーバー構築、 JMeter とansibleで負荷サーバーを構築、さらにansibleで負荷テストをキック。ansible強い！」 などといった、コメントが上がりました！ 楽楽勤怠開発課では継続的にテストをする環境が構築されたということもあるため、 今後の活動に注目していきたいですね！ 登壇者の山口さんが発表内容を詳細にまとめました！ 是非以下ブログも合わせてご確認ください。 tech-blog.rakus.co.jp 変わりゆく API 連携仕様との付き合い方 発表者： 太田 拓也 　　　　 2021/11/21 10:25〜 Track D (# jjug _ccc_d) Video:15min + Live:10min speakerdeck.com 続きまして、楽楽 労務 開発課の太田さんから、 「変わりゆく API 連携仕様との付き合い方」を発表いただきました。 ◆発表内容まとめ 　 API 連携してますか？ 　・ API 連携のメリット 　　→開発コストの削減 　・ API 連携のデメリット 　　→連携先システムへの依存 デメリットとどう付き合うか 　・サービス（楽楽 労務 ）について 　　→人事 労務管理 のサービス 　　→ AWS ECS/RDS/S3を作ったシンプル構成 　・モデル 　　→社内手続きで作られたデータが届出書の作成に使われる 　　→紙と電子申請のデータは同じデータを元に作成される 　・具体例 　　ケース１：仕様変更 　　ケース２：テスト 　　ケース３：モデルの違い まとめ 　・ API 連携にはメリットもデメリットもある 　・デメリットとうまく付き合うには、以下のような解決策がある 　　①値オブジェクト 　　②インターフェース+テストの組み合わせ 　　③腐敗防止層 　・うまく活用してメリットを享受しよう！ API 連携のメリット/デメリットを業務の取り組み事例とともにお話しさせていただきました。 視聴者からも 「 API 連携めちゃくちゃしてます！"障害の影響、仕様変更の影響、テストしづらい"ほんとそうですよね！」 「法改正による API 仕様の変更つらい。」 などといったコメントをいただき、共感を得ておりました！ 本内容が、HR Tech系のシステムをご担当されている方にとっての一助となれば幸いです。 また、太田さんが所属する、楽楽 労務 では技術情報の発信も行っております。 詳細は以下リンクよりご確認ください！ ◆「技術・デザイン情報」 career-recruit.rakus.co.jp 協賛内容 当社は、2021年5月23日開催した JJUG CCC 2021 Spring に続き、 2021年11月21日開催の JJUG CCC 2021 Fallに ロゴスポンサー として協賛させていただいております！ ccc2021fall.java-users.jp 今後も Java 関連の技術や事例を積極的に発信させていただきます！ 終わりに 弊社エンジニアの発表はいかがでしたでしょうか？ 是非 Java 技術者や、 SaaS 開発に携わるエンジニアの皆様の一助となれば幸いです。 技術発信はこれからも続く・・・ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 今回は、2021年4月に入社したフレッシュな新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 などなど、をインタビューしてみました！ 是非、新卒入社を検討している学生の皆様に ラク スの魅力が伝われば幸いです。 バックエンドエンジニア後編では、関西開発拠点にある 配配メール 開発課と メールディーラー ・ チャットディーラー 開発課に所属する新人エンジニア2名をご紹介します！ 配配メール開発課 森下繁喜さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします メールディーラー・チャットディーラー開発課 廣部知生さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします インターンシップのご案内 終わりに 配配メール開発課 森下繁喜さん 配配メール開発課 森下繁喜さん Q まずは自己紹介をお願いします 名前　　：森下繁喜(モリシタ　シゲキ) 卒業区分：学部卒 卒業学部：理系 趣味　　：サッカー、映画鑑賞、散歩 応募経路： インターンシップ 　 私は、 ラク スに入社するまでプログラミングはほぼ未経験でした。 大学では、数学を専攻し、専攻内容は数理 ファイナンス です。 就職活動を始めた際も、最初は証券会社や保険会社などの金融業界がメインでしたが、 コロナウイルス の流行がいつまで続くかわからない不安からコロナ禍でも安定的に雇用のあるIT業界に絞り、結果 ラク スに入社。 現在は開発エンジニアとして業務を行っています。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 応募のきっかけは、 インターンシップ で アプリ開発 を体験できるからです。 プログラミング未経験で、何から学んでいいかもわからなかったので 手っ取り早く経験を積めると思い応募しました。 Q ラク スへ入社した決め手は何ですか？ 入社を決めるのに２つの理由がありました。 　 ①：内定が出てからどれぐらい内定者に時間を使ってくれるかです。 　　内定後面談などは、ほかの会社でもありましたが ラク スは内定後面談が一番長く、 　　開発職、管理職、人事の方と多くのことを話すことができ、安心できました。 ②：私の入社を決める２つの指標の中で一番数値が高かったからです。 　　指標１は、自社開発であるかです。 　　自社開発であれば、受託やSESよりも多くの経験を積むことができると考えたからです。 　　指標２は、「 自己資本 当期純利益 率」「 総資産利益率 」「 流動比率 」「 自己資本比率 」の 　　4項目で自分の定めた％以上かです。 　　これらの項目は、会社の安全性と成長性を数値として見れるので活用しました。 Q 現在、どのような業務をされていますか？ 私は、配配メールの小規模改修を行っています。 お客様から頂いている問い合わせを基にバグの原因を探し、コードを改修していくことが業務の8割ほどを占めます。 2割に関しては、テストが中心です。 他の社員さんが改修した後のコードを調べてバグがしっかりと直っているの確認します。 こちらも大切な業務であり、なによりプロダクトのコード理解ににも繋がるのでテストを実施していて楽しいです。 Q 入社半年で見えた ラク スの魅力を教えてください 現在魅力に感じていることは、2点あります。 ①：私の成長を考えてくださっていることです。 　　毎週業務を振り分けていただくのですが、どのようなスキルが今必要なのかを私に合わせて 　　考えて下さるので、業務を進めていると成長を実感できます。 　　特に、私が嬉しいのは配属数か月で開発業務に携われることです。 　　IT業界についてインターネットで調べると、1年目はテストばかり任されると書かれたので 　　不安でしたが、 ラク スはそのようなことはなかったです。 ②：周りのメンバーがとても親切です。 　　一年目なので分からないことがほとんどです。 　　その中で、質問のしやすい環境を整えてくださったり、 　　意見があるときは1年目など関係なく互いに尊敬し、 　　話を聞いてくださるので毎日、この課で働くことが楽しいです。 Q 今後の抱負を教えてください 現在課題に感じていることは、Webへの知識が乏しいことです。 私が所属する配配メールは、メールシステムなのでメール プロトコル やWebの仕組みを理解していないとわからないことが多いです。 特にメール プロトコル に関しては、ほぼ無知だったので学習を重点的に行っていきたいです！ Q 就活中の学生の方々にメッセージをお願いします 就職活動を行っていると不安が多いと思いますが、何事も楽しむことが一番大切だと思います。 気楽にエンジニアと話せて現場で働くエンジニアの意見を聞ける機会ぐらいだと考えて応募するぐらいでもいいと思います。 また、 ラク スは インターンシップ 採用を行っているので、実際の開発を知れるチャンスだと考え応募してみてはいかがでしょうか？ メールディーラー・チャットディーラー開発課 廣部知生さん Q まずは自己紹介をお願いします 名前　　：廣部知生(ヒロベ　トモキ) 卒業区分：学部卒 卒業学部：理系 趣味　　：ゲーム、アニメ 応募経路： インターンシップ 　 廣部です。 大学では情報学を学んでいました。 好きな開発言語は Python です！ Q ラク スへ応募しようと思ったきっかけは何ですか？ 近畿圏でIT系の会社を探していたとき、 インターン 参加のオファーが来ました。 インターン に参加して、企業風土が自分にあってそうだと感じたため応募しました。 Q ラク スへ入社した決め手は何ですか？ 自社開発でサービスを提供していて、新サービスの開発にも積極的なためです。 Q 現在、どのような業務をされていますか？ メール共有管理システムである、メールディーラーの開発に携わっています。 20年もののサービスですが顧客数も多いため、保守的な運用をするのではなく、 積極的な新機能の開発に取り組んでいます。 新人の私は、主にバグ修正や軽微な変更の実装、新機能のテストなどを行っています。 Q 入社半年で見えた ラク スの魅力を教えてください 研修がしっかりしているところです。 入社してから3ヶ月は全体研修、そのあとも配属されたサービスごとに研修があります。 メールディーラーの研修では、実際に業務と同じフロー、同じコードをもとに研修を行うので、 研修終了後も非常にスムーズに業務に携わることができました。 Q 今後の抱負を教えてください 20年もののサービスということもあり、非常に機能が多く、仕様も複雑な箇所があります。 そのため、まずはサービスの全体的な理解を目標にしています！ テストやバグ修正を通して、主要な機能は触れたのですが、連携機能などはまだまだです。 Q 就活中の学生の方々にメッセージをお願いします 社会に出てなにがやりたいか、なになら続けられるのかが非常に重要だと思います！ インターンシップ のご案内 ラク スでは今年度も インターンシップ を開催しております。 少しでも ラク スに興味が湧いた方は是非お申込みをお願いします！ 【RAKUS Tech Lab（ インターンシップ ）】 https://fresh-recruit.rakus.co.jp/recruit/internship.html 終わりに 関西 後半編では、森下さんと廣部さんにお話を伺いました！ 関西開発拠点にはお二人が関わっているプロダクトの他に、 楽楽販売 と 楽楽労務 があります。 もし、関西に在住の学生の方は弊社を就職先の1つとして検討いただけますと幸いです！ なお、関東開発拠点でもバックエンドエンジニアが所属しておりますよ。 2021年新人インタビューはまだまだ続きますので、こうご期待！ エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 今回は、2021年4月に入社したフレッシュな新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 などなど、をインタビューしてみました！ 是非、新卒入社を検討している学生の皆様に ラク スの魅力が伝われば幸いです。 バックエンドエンジニア前編では、関西開発拠点にある 楽楽販売 開発課に所属している新人エンジニア2名をご紹介します！ 楽楽販売開発課 堀川慶太さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします 楽楽販売開発課 髙山大貴さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします インターンシップのご案内 終わりに 楽楽販売開発課 堀川慶太さん 楽楽販売開発課 堀川慶太さん Q まずは自己紹介をお願いします 名前　　：堀川慶太(ホリカワ　ケイタ) 卒業区分：学部卒 卒業学部：理系 趣味　　：運動、スポーツ観戦、ゲーム 応募経路： インターンシップ 　 こんにちは。堀川慶太です！ Q ラク スへ応募しようと思ったきっかけは何ですか？ 企業側からオファーが来るサイトでオファーが来たためです。 当時は就活にはまっていて、とりあえず片っ端から説明会や面談に参加していました。 自社開発をメインで行っているのも理由の一つです。 Q ラク スへ入社した決め手は何ですか？ 以下4点になります。 ・自社開発を行っている ・なんか古臭い大企業は嫌だった(最後まで安定の面などから迷った) ・大阪で働ける ・中小企業のサポートという業務内容が自分のやりたいことに合致した Q 現在、どのような業務をされていますか？ 配属後はまず研修を行いました。 それが終了すると、ちょっとしたバグやUIの不具合を修正しながら製品への理解を深めていきました。 現在は新機能の開発をお手伝いさせていただいたり、テストや不具合修正を行っております。 Q 入社半年で見えた ラク スの魅力を教えてください 自身の部署の話にはなりますが、驚くほどいい人しかいません。 怒鳴り散らす人は見たことありませんし、皆さんとても物腰も柔らかいです。 自分のやりたいこともある程度やらせていただけますし、良い会社だと思います。 よく皆さんがイメージをされるような怖い方は、一人もいないので安心して入社していただければと思います。 Q 今後の抱負を教えてください 製品理解を深める！ 自分一人で一定レベルの開発まで行えるようになる！！ Q 就活中の学生の方々にメッセージをお願いします 就活がんばってください。 東証 一部にも上がりましたし見栄えもいいと思います。 新卒のサポートもどんどん厚くなっています。 結局自分は何がしたいんだってことをもう一回考えて就職先決めていただければと思います。 楽楽販売開発課 髙山大貴さん 楽楽販売開発課 髙山大貴さん Q まずは自己紹介をお願いします 名前　　：髙山大貴(タカヤマ　ダイキ) 出身　　： 長崎県 卒業区分：学部卒 卒業学部：理系 趣味　　：映画・海外ドラマ・アニメ鑑賞、散歩、ファッション、ゲーム、読書 応募経路：直接応募 　 基本的に落ち着いており、温厚な部類の人間です。 どちらかといえばインドアなことが多いです。 大学では組み込み系のプログラミングを中心に学びました。 また、高校時代は工業高校に属しており、 危険物取扱者 乙種4類や 第二種電気工事士 等 あまり同業者が持っていないような資格をいくつか所持しています。 情報系の資格は 基本情報技術者 を取得しています。 そろそろ応用情報取りたいなぁと思っています。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 学生時代に ラク ス主催のLT会に参加したことがあり、以前から社名は知っておりました。 応募しようと思ったきっかけは、OpenWorkという会社の口コミを投稿するサイトでたまたま求人を見かけたからです。 Q ラク スへ入社した決め手は何ですか？ Web系の開発に興味があったのことと、コロナ禍で SaaS 形態のビジネスの需要が上がっていて会社に勢いがある印象があったので、会社と共に自分も成長していきたいと思い志望しました。 Q 現在、どのような業務をされていますか？ 現在は、以下業務を行っています。 ・研修、プロダクト理解、開発演習 ・軽微なUI・バグの修正 ・新規開発機能のテスト・ デバッグ などなど 　 技術スタックは以下の通りです。 使用言語： PHP 、 jQuery 、JS、HTML 開発で使うツール：Jenkins、sonerCube、GitLab、PhpStorm などなど Q 入社半年で見えた ラク スの魅力を教えてください 周りの社員の方々は業務に積極的で、向上心のある方が多いので、いい刺激になると思います。 質問に対して、回答を教えていただけたり、時には一緒に悩んでいただけたりと優しい方々が多いです。 年功序列 などのマインドもあまりないかなと個人的に思います。 Q 今後の抱負を教えてください アーキテクチャ に関する理解が十分でないので、プロダクト理解を深めることを意識しています。 自分が学んだ知識を溜め込むだけでなく、ブログやLTなどでときにはアウトプットしてみることも意識していきたいです！ Q 就活中の学生の方々にメッセージをお願いします 迷ったらとりあえず応募してみてもいいんじゃあないでしょうか。 インターンシップ のご案内 ラク スでは今年度も インターンシップ を開催しております。 少しでも ラク スに興味が湧いた方は是非お申込みをお願いします！ 【RAKUS Tech Lab（ インターンシップ ）】 https://fresh-recruit.rakus.co.jp/recruit/internship.html 終わりに 楽楽販売開発課に所属している堀川さんと、髙山さんにインタビューを行いました！ 新人研修終了後、楽楽販売開発課では軽微なUI・バグの修正を行いつつ 製品の理解を深める独自の演習があるようですね。 今後のお二人の活躍に期待です！ 次は、バックエンドエンジニア関西 後編でお会いしましょう！ エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 今回は、2021年4月に入社したフレッシュな新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 などなど、をインタビューしてみました！ 是非、新卒入社を検討している学生の皆様に ラク スの魅力が伝われば幸いです。 インフラエンジニア編では、弊社でインフラ開発課に所属している新人エンジニア1名をご紹介します！ 東京インフラ開発3課 橋本海里さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします インターンシップのご案内 終わりに 東京インフラ開発3課 橋本海里さん 東京インフラ開発3課 橋本海里さん Q まずは自己紹介をお願いします 名前　　：橋本海里(ハシモト　カイリ) 卒業区分：学部卒 卒業学部：文系 趣味　　：スポーツ観戦・動画鑑賞・買い物 応募経路：直接応募 　 橋本です。 大学は文系でしたが、独学でプログラミングを学んでいました。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 応募したきっかけは、一度本社に行った際の雰囲気がとても良かったからです。 また、自分が知っている広島の企業がサービスを利用していたのもきっかけの一つです。 Q ラク スへ入社した決め手は何ですか？ 以下4点です！ ・研修制度がしっかりしていた ・自社開発を行っていた ・会社の雰囲気がよかった ・成長できる環境が整っていると感じた Q 現在、どのような業務をされていますか？ 配属後は、インフラに関する研修をメインに行っています。 具体的には、検定の取得（ LPIC ）や仮想環境に各種サーバーを構築などがあります。 また、月に数回はデータセンターに行き、業務のお手伝いも行っています。 Q 入社半年で見えた ラク スの魅力を教えてください 私が考える魅力は２つあります。 1つ目は、安心して働くことのできる環境が整っている点です。 周りの先輩方はとても優しく、わからないことや困ったことはすぐに質問・相談することができます。 2つ目は、研修が手厚い点です。 インフラでは一年間の研修が用意されているので、安心して一年後、業務に関わることが出来ます。 Q 今後の抱負を教えてください インフラに関する基礎知識を身に着ける！ 少しでも早く研修を終わらせ、業務に関わる！！ Q 就活中の学生の方々にメッセージをお願いします ラク スはとても働きやすく、成長できる環境があります。 少しでも気になった方は、応募してみてください。 インターンシップ のご案内 ラク スでは今年度も インターンシップ を開催しております。 少しでも ラク スに興味が湧いた方は是非お申込みをお願いします！ 【RAKUS Tech Lab（ インターンシップ ）】 https://fresh-recruit.rakus.co.jp/recruit/internship.html 終わりに 今回は、配属後インフラエンジニアにて働く橋本さんにお話しをお伺いしました！ 独学でプログラミングをされ、現在は現場で活躍するインフラエンジニアへと成長し続けております。 弊社は各課によって、配属後の仕事は異なりますが研修制度も整っていますので安心してご入社ください！ では、引き続き別の課に配属された新人エンジニアのインタビュー公開をお待ちください！ エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 今回は、2021年4月に入社したフレッシュな新人エンジニアの皆さんに 応募きっかけ 入社の決め手 現在の業務内容 ラク スの魅力 今後の展望 などなど、をインタビューしてみました！ 是非、新卒入社を検討している学生の皆様に ラク スの魅力が伝われば幸いです。 フロントエンジニア編では、弊社でUI開発課に所属している新人エンジニア2名をご紹介します！ UI開発課　實久裕大さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします UI開発課　田口真輝さん Q まずは自己紹介をお願いします Q ラクスへ応募しようと思ったきっかけは何ですか？ Q ラクスへ入社した決め手は何ですか？ Q 現在、どのような業務をされていますか？ Q 入社半年で見えたラクスの魅力を教えてください Q 今後の抱負を教えてください Q 就活中の学生の方々にメッセージをお願いします インターンシップのご案内 終わりに UI開発課　實久裕大さん UI開発課　實久裕大さん Q まずは自己紹介をお願いします 名前　　：實久裕大(サネヒサ　ユウタ) 生年月日：1998年11月19日生まれ 出身　　： 新潟県 卒業区分：学部卒 卒業学部：理系 趣味　　：筋トレ・ゲーム・旅行・ YouTube 鑑賞 応募経路： インターンシップ 　 色々な場所を転々として東京に落ち着きました。 大学では情報系を学んでいて、現在はUI開発課のフロントエンドエンジニアとして働いています。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 大学3年の夏にサマー インターン や企業説明会に参加していて、その中に ラク スも含まれていました。 インターン の内容が アプリ開発 でしたが、私の学んでいた言語を使っていて興味を持ったのがきっかけです。 Q ラク スへ入社した決め手は何ですか？ 周りに干渉されず自由に開発を行いたいと感じていたので自社開発が魅力的でした。 また、 インターン や説明会で会社の雰囲気やオフィスを見れた事も決め手です。 最後は、早期内定だったので比較対象する企業数が少なかったので決めやすかったです。 Q 現在、どのような業務をされていますか？ 現在は扱っているプロダクトのバグ修正や新機能の追加がメインの業務です。 また、月に1度はリリースを行なっているので、仕様確認などの会議が多くあります。 割合としては、開発6割会議2割仕様書など作成2割です。 開発ではHTML・ CSS ・ JavaScript を使用し、ユーザーが操作しやすいようにボタンを追加したりプログラムの改善を行なっています。 UI開発課は出来てまだ日が浅いので、新しい取り組み(勉強会)や業務改善作業も行っています。 Q 入社半年で見えた ラク スの魅力を教えてください 規模感としては大手になりますが、自社開発なので新しい機能を考えたり、開発方法を考えたりと挑戦がたくさんできる環境です。 新人でも開発を行えるのでプログラミングスキルを身につける事ができます。 また、リリース時期などを ラク スで決められるので（例外もあります）、 のびのび作業を行えたり、 厳しい場合は作業分担を行うなど、初めて入社する企業としてはいいと思いました。 Q 今後の抱負を教えてください アプリ開発 経験を多く積む事が目標です。 課題としては現在は助けていただきながら業務をしていますが、独力で行えるようになりたいです。 Q 就活中の学生の方々にメッセージをお願いします 自分が何を仕事にしたいのか改めて考えてみてください。 IT業界（ ラク ス）の中にも、営業や人事の方もいますし、エンジニアはフロントエンド・バックエンド・インフラと様々な種類があります。 皆様の希望する業務が ラク スで叶えられることを祈っています。 UI開発課　田口真輝さん UI開発課　田口真輝さん Q まずは自己紹介をお願いします 名前　　：田口真輝(タグチ　マサキ) 卒業区分：院卒 卒業学部：理系 趣味　　：野球、ゲーム、アニメ鑑賞 応募経路：直接応募 　 田口です。 大学では深層学習に関する研究を行っていました。 元々PCやゲームなどのガジェットが好きで、それが講じてプログラミングの道に進みました。 Q ラク スへ応募しようと思ったきっかけは何ですか？ 大学の研究室の引継ぎが非常に杜撰で先輩のコードを読み解くのに一ヵ月以上かかり、それを改善するために Wiki を立ち上げたりしている内に業務効率化に興味を持ったのがきっかけです。 Q ラク スへ入社した決め手は何ですか？ 業務効率化を行っている企業の中で、最も会社も自分自身も成長出来そうな企業が ラク スだったので、私の中では就職先の選択肢は ラク スほぼ一択でした。 Q 現在、どのような業務をされていますか？ 配属後、二ヶ月ほどプロダクトや業務で必要となるエンジニアスキルについて学んだ後、現在は楽楽明細のフロントエンドエンジニアとして働いています。 業務内容としては、Reactを用いてページ画面やページ画面の部品作成を行っています。 Q 入社半年で見えた ラク スの魅力を教えてください 働きやすい環境なのが一番の魅力だと思います。 現在進行形で、配属したばかりでプロダクトに関する知識やコーディングルールが分からず色々とご迷惑をおかけしていますが、チームの方々は一つ一つ丁寧に教えてくださるので、質問や疑問点を遠慮せずに伺うことが出来ています。 Q 今後の抱負を教えてください 現在の課題はフロントエンドに関する知識が圧倒的に不足していることです。 大学時代は アルゴリズム やプログラミングのロジックを学ぶことが多く、フロントエンドには触れたことがほとんどありませんでした。 ですので、今後はフロントエンドスキルを広く深く学び、「私の所属はUI開発課のフロントエンドエンジニアです！」と胸を張って言えるようになりたいです。 Q 就活中の学生の方々にメッセージをお願いします 就職活動は色々な企業を知る良い機会なので、とにかく応募してみるのが良いと思います。 私も業務効率化関連以外の企業を受けて、これまで知らなかった企業や、CM等でよく耳にするような企業の方と話をすることができ、多くの学びを得られました。 これは ラク スについても同様で、直接 ラク スメンバーと話をして初めて知ることは意外と多いと思います。 是非 ラク スを含め、色々な企業に応募してみてください。 インターンシップ のご案内 ラク スでは今年度も インターンシップ を開催しております。 少しでも ラク スに興味が湧いた方は是非是非お申込みをお願いします！ 【RAKUS Tech Lab（ インターンシップ ）】 https://fresh-recruit.rakus.co.jp/recruit/internship.html 終わりに 今回は、配属後フロントエンドエンジニアにて働くお二人にお話しをお伺いしました！ 實久さんは インターンシップ 参加経由、田口さんは直接応募と弊社を知ったタイミングは異なりますが日々精進しながら業務を全うしております。 今後も、2021年度に新卒入社したメンバーを今後もご紹介していきますので、ご期待くださいませ。 エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 突然ですが、デザイナーの皆さんはデザインの知識をどのように学ばれていますでしょうか？ スクール（大学、専門など） 会社、仕事 WEB、オンライン（Udemyなど） など、様々あるかと思います。 とはいえ、日々変わりゆくデザインのトレンドをキャッチアップしていくのは時間と労力が必要ですよね。 そんな方に必見！ 弊社にて定期的に開催している、デザイナーによるデザイナーの為のデザインLT大会・・・ 「UI/UXデザイナーLT会」にて発表されたデザインTipsをまとめました ので、ご紹介させていただきます！ 記念すべき第一回目のまとめ記事は以下をご確認ください！ ・ 【UI/UXデザイナーLT会】を開催しました【登壇者15名御礼】 - RAKUS Developers Blog | ラクス エンジニアブログ 目次 目次 デザイナーとなっておもったこと UI/UXデザイナーになるには UI/UXデザイナーになるには (学習編) 〇〇デザイナーの違い ラジオボタンと初期値と必須マークの考察 設計業務チャレンジ 共創によるサービス創出プロセスについて（デザイン思考をベースに） サービス開発のUXデザインでひと手間加えた話 「デザインは反復である」ということをメンバーに理解してもらっておこう ノンデザイナーズデザイントーク 営業資料におけるデザインの重要性 デザインシステムとは 引き出しを設計することである ぼくのかんがえたさいきょうの地図検索 UI （特許出願中） プログラマが最低限抑えておきたいUI知識３選 取扱説明書制作のプロがkintoneの導入ガイドブックをガチで作ってみた Scalebaseのデザインシステムの取り組み 実践的OOUIデータモデリング ウェブアクセシビリティについて 最近のCSSで作るテーブルレイアウト Homeってなんですの？ UI/UXデザイナー、Webデザイナー募集中 終わりに デザイナーとなっておもったこと 発表者： kimukei さん speakerdeck.com デザイナーという職業柄から細かいことを気にしすぎ、その中でも良いデザインと思った主観な視点を紹介いただきました！ 例えば、バレンタインや受験時に発売されるお菓子、アイスのパッケージは既存のデザインを活かしつつ、受け取る側のことを考えた新たなデザインの価値をユーザに提供できているといった点です。 ◆発表内容のポイント 「よいデザイン」とは何か？ ・ サービス、製品に関わらずそれを見たり、使ったりするユーザが心地よく感じるデザインを提供していくこと ・考えさせないUI 　→利用者が当たり前のように使える設計 ・おもてなしのUX 　→利用された際に未来のアクションを提示 ・サービスデザイン 　→顧客が使いやすいようにデザインする取り組み 最後におすすめの書籍を6冊ご紹介いただいているので、発表資料を是非ご確認ください！ UI/UXデザイナーになるには 発表者： kimukei さん speakerdeck.com 元々 Webデザイナー だった経験から、UI/UXデザイナーになるためのノウハウをご紹介していただきました。 今回は「ユーザファースト」に特化してお話しいただいております！ ◆発表内容のポイント UI/UXデザイナーになるには ・ユーザーが求めていること、現状を正しく把握する必要 ・ユーザーの声を拾い上げていくことが重要 　→ UI/UXデザイナーはユーザーの代弁者 ・未来を見据えたUI/UX設計 　→ ユーザーファーストを意識する UI/UXデザイナーになるには (学習編) 発表者： kimukei さん speakerdeck.com UI/UXデザイナーになるにはの第二弾となる発表です。 1つ前の「ユーザファースト」に続き、今回は「学習」に特化し、おすすめの書籍を15冊ご紹介いただきました！ ◆発表内容のポイント UI/UXデザイナーの学習 おすすめ書籍 15選 １．　ノンデザイナーでもわかるUX+理論で作るWebデザイン ２．　UI/UXデザインの原則 ３．　 SF映画 で学ぶインターフェースデザイン ４．　UI GRAPHICS ５．　デザイナーのためのプロトタイピング入門 ６．　ほんとに使える「 ユーザビリティ 」 ７．　UIデザイン みんなで考え、 カイゼン する。 ８．　インタフェースデザインの心理学 ９．　UXライティングの教科書 ザ・マイクロコピー １０．UXデザインの教科書 １１．UXデザインの法則 １２．はじめてのUXリサーチ １３．行動を変えるデザイン １４．「ついやってしまう」体験の作り方 １５．「ユーザーフレンドリー」全史 〇〇デザイナーの違い 発表者： junyaonoda さん speakerdeck.com いつの間にか増えた○○デザインの種類が多すぎる…という思いから、ざっくりと種類と仕事の違いについて紹介いただきました！ 伝える系 広告、パンフレット、コーポレートサイト、LTなど 心に訴える。記憶に残す。 使う系 スマホ アプリ、Webアプリ、 GUI 、 ECサイト など 操作に迷わず目的を達成。新しい体験も。 発表者から伝えたかったことは、以下の通り。 ◆発表内容のポイント 事業会社のBtoB SaaS のUIデザイナーになって感じた5つのこと １．エンジニアさんが沢山いる ２．担当領域の業務知識の理解が必要 ３．顧客の声が直に聞ける ４．様々な部署の人と協力しながら仕事ができる ５．プロダクトの成長にやりがいを感じる ラジオボタン と初期値と必須マークの考察 発表者： junyaonoda さん speakerdeck.com 入力フォームの ラジオボタン には、「必須マーク」は必要なのか？ という疑問から発表者が考察を行いました。 発表者としての結論に行きつくため、 ユーザビリティ の専門家である ヤコブ ・ニールセン氏の意見や、優しいチームメンバー相談した経緯もとても参考になります。 ◆発表内容のポイント 結論 ・初期値の設定有無よりも、まずは大前提不可逆なシステムにしないこと ・初期値あり 　→システム上で、現在の状態から何かを変化させる機能を持った ラジオボタン は初期値を指定しておく ・初期値なし 　→アンケートのようなユーザーが選択肢を単純に選択するだけのものは初期値が入ってなくて良い noteにも内容がまとめられていますので、是非ご確認ください！ note.com 設計業務チャレンジ 発表者： junyaonoda さん speakerdeck.com 課題　　　・・・デザイナーがサービス開発の上流工程から参画は"これから" ありたい姿・・・プロダクトの成長やUX向上に貢献 上記のような背景から、設計業務へチャレンジした取り組みを発表いただきました！ 取組結果としては、目標件数を達成し、効率的&効果的に進めることはできましたが、反省すべき点も多々あったとのことです。 それを踏まえて… ◆発表内容のポイント 設計をやってみての気づき ・担当プロダクトの理解が深まった ・他のプロダクトでも役に立たせることができる ・自分は「こうしたい」と決める意思（勇気）持つこと 今後の活動にも期待しております！ 共創によるサービス創出プロセスについて（デザイン思考をベースに） 発表者： growup さん 【登壇用】共創によるサービス創出プロセスについて from 靖正 高橋 www.slideshare.net プロジェクトを進める以下3要素について、ご紹介いただきました！ プロセスデザイン ファシリテーション チームワークデザイン 今回メインとなるのは、 プロセスデザイン …課題解決をするために必要な手順になります。 ◆発表内容のポイント ・デザイン思考のメソッドをもとに、プロセスデザインを回す 　→メソッド 　　・あらゆる人と共創する 　　・あらゆる考えを仮想化する 　　・創造性を発揮することの必要性を訴える 　　・ア イデア に対して批判的な目を持ち、検証（テスト）によって検証する 　　・完璧を目指さない、何度も何度でも戻る 　　・ア イデア ではなく重要なのは インサイト ファシリテーション とチームワークデザインの詳細は、発表資料をご確認ください！ サービス開発のUXデザインでひと手間加えた話 発表者： Emy29 さん speakerdeck.com 発表者は、以下の問題点を感じていました。 ・全体設計を考えながらユーザーが良いと感じるものを作らないといけない ・【課題発見→フロー改善→画面設計】のデザインの流れを可視化したい そこで、既存の手法であるカスタマージャーニーマップとサービスブループリントを組み合わせながら課題から解決策まで書き出せるよう、改善Tipsをご紹介いただきました！ ひと手間加えたマップは、発表資料をご確認ください。 ◆発表内容のポイント 改善ポイント ・システム側、画面、フローなど多方面の課題を見つけられる ・課題から解決策までを現状の行動に合わせて俯瞰できる ・解決策の検討がしやすく、優先順位がつけやすい 得た知見 ・案件や状況に合わせて、既存のツールに工夫を加えることでUXデザインのフロー、アウトプットをより良くできる！ 「デザインは反復である」ということをメンバーに理解してもらっておこう 発表者： 711fumi さん speakerdeck.com デザイナー以外がイメージする開発の流れは一直線ですが、実際のデザイン工程は「抽象と具体」の反復作業によって完成に近づけています。 その反復作業が、不要な作業や手戻りとして受け止められてしまう場合もあると発表者は語りました。 本発表では、デザイナーである発表者から「認識のずれを無くすためにできること」をまとめとして紹介いただきました！ ◆発表内容のポイント ・デザイナーの考え方を共有しておく 　→作用工程やUI設計に向けて整理した情報など ・反復を促す「問い」を意識する 　→抽象度の高い話を進める場合、具体的な話から進める場合など ・UIデザインは「要件確定後の開発」ではなく「設計」と捉えてもらう 　→設計の一工程であり、変更が発生することを理解してもらう ノンデザイナーズデザイン トーク 発表者： くぼたさや さん speakerdeck.com 学習を通した成功体験をサポートするための企画（Learning Xperience）を行っている発表者は、教育システムのオペレーション改善をしています。 この仕事において一番大事なのは、「ユーザー目線第一」とのこと。 その仕事において一番大事と思えることを発表いただきました！ ◆発表内容のポイント ・課題の本質を捉えて解決できる仕組みを考えること大事 　課題の本質：メモ書き、ブレスト、 ヒアリ ングなど 　解決　　　：ア イデア を出してメリット/デメリットを考える 　仕組み　　：再現性が高い運用まで考える 営業資料におけるデザインの重要性 発表者： meia-hara さん speakerdeck.com デザインで受け取るイメージがいかに変わるかについて、以下2パターンで検証した結果をご紹介いただきました！ ・UI/UXを意識したデザイン ・意識していないデザイン 各デザイン要素の違いは、発表資料をご確認ください。 色、フォント、図、構成に違いがあることが一目でわかります！ ◆発表内容のポイント お客様に印象の残る営業資料を作成するには ・UI/UXを意識したデザインをすることが重要である ・検証を通して再確認できた デザインシステムとは 引き出しを設計することである 発表者： ShotaKugawa さん デザインシステムは引き出しを設計することである(20210714イベント発表資料@ラクス株式会社) from Shota Kugawa www.slideshare.net デザインシステムが必要な理由を引き出しを例に、別途 note にてまとめている内容をLT向けに発表いただきました！ ◆発表内容のポイント デザインシステム＝「引き出し」のデザイン ・component化 　→そんな情報が入るのか？を想定する 　 　→「引き出し」に入れるものを想定 「引き出し」のイメージは、発表資料が分かりやすいので是非ご確認ください！ ぼくのかんがえたさいきょうの地図検索 UI （特許出願中） 発表者： choo さん docs.google.com 件数を表示する地図検索UIを作りたい！ということで、実際に作成された経緯やサービスのデモを発表いただきました。 ◆発表内容のポイント ・件数を表示する地図検索UIの事例紹介 　→件数表示、ヒートマップ、行政区域ごとの色塗り ・個人開発した賃貸検索アプリの発表 発表時にデモいただいた賃貸物件検索サービス Comfyは、物件データの利用特許を得られたなかったため、2021/07に閉鎖したとのことです。 残念です…。 プログラマ が最低限抑えておきたいUI知識３選 発表者： 白栁隆司 さん speakerdeck.com エンジニアである発表者目線で、 プログラマ が抑えておくべきUI知識を発表いただきました！ 「"質の良い"仕事のためには、デザインは出来た方良い」という言葉が印象的でした。 ◆発表内容のポイント １．絶対座標・相対座標 　・絶対座標：画面上の1っ点を原点[0,0]とし、位置変化を扱う 　・相対座標：アイテム間の位置関係で決まる ２．間（空間） 　・情報に適度な間（空間）を作る＆省略（間引く） 　・協調なども活用して伝えやすくできる 　・コーディングにも活用できる！ ３．視線誘導　Zの法則 　・人間の視線はZ型に動く 　・チラシの多くはこのルール 取扱説明書制作のプロがkintoneの導入ガイドブックをガチで作ってみた 発表者： 情報親方 さん note.com 取扱説明書制作を仕事とされている発表者から、「kintone導入ガイドブック」を作った事例を紹介いただきました！ 「kintone導入ガイドブック」作成前は、「はじめてのkintoneガイドブック」という名で様々な課題（コンセプト変更、構成見直しなど）がありました。 課題を解決すべく、 目次をカスタマージャーニーマップ にした内容がとても参考になりました。 ◆発表内容のポイント 目次を カスタマージャーニーマップ に！ ・目次構成は「骨組み」 ・全体がわかる、どこを見ればいいかわかる ・ユーザーを最短距離で目的地を誘導 目次を活かたことで、お客様からも評価が高い取扱説明書になったとのことです。 是非皆様も目次を活かした構成にしてみてはいかがでしょうか？ Scalebaseのデザインシステムの取り組み 発表者： Tadaking さん speakerdeck.com 発表者が扱っているScalebaseの3つデザインシステムについて発表頂きました！ ・zeroheigth ・ Figma ・Storybook ◆発表内容のポイント ・UI コンポーネント を Figma だけでなく、その考えを伝えるためにドキュメント化することが大事 ・作成/保守の作業時間は必要だが、注力すべき所に時間を使うことができるようになり、取り組んで良かった ・発表者の取り組みは以下noteをご参考ください！ 　 Tadaki｜note 各デザインシステムの取り組み事例は発表資料をご確認ください。 実践的OOUIデータ モデリング 発表者： codyNog さん speakerdeck.com ・データ モデリング に困っている人 ・OOUI採用して本当にいいのか迷っている人 向けの内容となります！ UIから逆算的にデータ モデリング ができる事例と合わせて紹介いただきました。 ◆発表内容のポイント デザイナーがデータモデルをすると ・データ構造がコード上の実装と同期する ・ コンポーネント としても同期する 　→共通の世界観で開発サイクルが回る 発表資料の細かい事例（一覧表示UI、詳細表示UIなど）がまとめられておりますので、お時間ある際にご確認ください！ ウェブ アクセシビリティ について 発表者： nana さん speakerdeck.com アクセシビリティ とウェブ アクセシビリティ についてご説明頂いた後、具体的な対応策も合わせてご紹介いただきました！ 空港と公的機関で実際にあった訴訟例もまとめており、大変興味深い発表となりました。 ◆発表内容のポイント 比較的簡単にできそう&影響が大きいところ ・ コントラ スト 　→ コントラ ストチェッカーで検索！ ・キーボードだけで操作できるようにする ・スクリーンリーダーを考慮する 発表者は、老若男女問わず誰でも使いやすいサイトやアプリが増えてほしく、この題材としたそうです。 この発表を基に、そのようなサービスが増えてくれることを私も願っております！ 最近の CSS で作るテーブルレイアウト 発表者： 腹筋ローラーの力を信じろ さん walnut-insect-387.notion.site CSS Gridを使って、テーブルレイアウトをコンテンツ本来の幅とバランスを取りながらコン トロール する方法を発表いただきました！ テーブルはユーザーにとっては慣れ親しんだレイアウトになりますが、レイアウトに癖があり、結構難しいものである…確かにそうだなぁと共感しておりました。 ◆発表内容のポイント ・長いコンテンツにレイアウトが振り回されないようになった ・折り返しをいい感じに制御できた ・ CSS Gridは柔軟ですが、落とし穴も 　→ CSS Gridはすごい！ 　→ Chrome で数万〜数十万セル表示させたらスクロールが壊れた CSS Gridでテーブルを再構築した内容は、添付の資料をご確認ください！ とても詳細にまとめてくださっております。 また、発表者から宣伝にはなりますがWebのレイアウトと CSS の可能性を広げる最高の一冊を監訳したそうです！ 是非宜しければご確認ください！ Every Layout-モジュラーなレスポンシブデザインを実現するCSS設計論 Homeってなんですの？ 発表者： DameNianch さん note.com 遺伝子操作を使った アプリ開発 をされている発表者が、以下の遺伝子操作アプリの機能と Twitter の項目を比較し、Homeとは？という疑問を持ったことでこの発表テーマとなったそうです。 ・対象（編集）遺伝子の設定 ・画像の編集 ・編集画像の確認 ・動画の編集 ・編集動画のダウンロード ◆発表内容のポイント 視点の違い ・ユーザー vs 開発者　　　　　：HOMEとは？という視点 ・開発者 vs エセデザイナー　　：長いテキスト嫌だなぁ、という視点 ・エセデザイナー vs デザイナー：文字は読まず、アイコンを見ているという視点 ・デザイナー vs ユーザー　　　：文字読まなくても操作できてしまうという視点 開発者とデザイナーとの視点の違いについて、丁寧に考察してくださりました！ この結果を踏まえ、発表者はご自身で開発されている遺伝子操作アプリに、今後はアイコンを追加したいとのことです。 UI/UXデザイナー、 Webデザイナー 募集中 株式会社 ラク スでは、デザイナーを積極的に募集しております！ 現在募集中の職種は以下の通りです。 職種 UIUXデザイナー／マネージャー（東京） | 株式会社ラクス UIデザイナー（東京） | 株式会社ラクス Webデザイナー（東京） | 株式会社ラクス ※2021/11/18時点での情報です。 また、弊社デザイナーが発信しているnoteも是非ご確認ください！ note.com 2021/12/10(金)に開催する、 【ラクス】キャリア座談会 #13 UIデザイナーの仕事紹介 も是非！ 終わりに UI/UXデザイナーが語る、デザインTipsはいかがでしたか？ 今回、資料を共有いただいた方のみをご紹介させていただきましたが実際はもっと多くの方がデザインTipsをアウトプットする場として、弊社イベントを活用されております。 過去イベント UI/UXデザイナーLT会 UI/UXデザイナーLT会 - vol.2 UI/UXデザイナーLT会 - vol.3 UI/UXデザイナーLT会 - vol.4 UI/UXデザイナーLT会 - vol.5 250名以上の参加申込をいただくほど、大好評のイベントです！ 本記事を読んでいただき、本イベントにご興味を持ったデザイナーの皆様は是非、参加/登壇いただけますと幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 初めましてこんにちは。 ngerukatakataです。 営業上がりの未経験エンジニアとしてそこそこの期間を働いております。 担当する環境も当時の物からかなり様変わりしてしまい、 同じような仕事の仕方はできないものだなぁと感じている今日この頃です。 さて、今回は大きく変わったものの中でこの業界にかかせない 『監視』 について、 お話しさせていただければと思います。 まず先にお伝えしますと、今回お話しする監視ツールは Zabbix についてとなります。 この Zabbix を コマンドライン から操作することのできる Zabbix API の『入門』について お話させていただければと思います。 目次 はじめに 目次 背景 明日の監視生活を【楽】にしよう！ Zabbix API とは？ Zabbix API 超・入門 Zabbix トークンの取得！ Zabbix からグループIDとテンプレートIDの取得！ Zabbix へ指定したグループとテンプレートに所属するホストを作成！ Zabbix トークンの破棄！ まとめ 参考 背景 私が中途社員として入社してサービスに携わってから今にいたるまでで、 私の担当するサービスのインフラ環境は大きく拡大しました。 管理するサーバの台数は数台…せいぜいが十数台といったところから、 今では数百台といったところまで大きくなり、それにともなって運用のコストは肥大化を続けています。 当時は新たにサーバを用意するとなると構築を手作業で実施し監視を追加するには Zabbix を GUI でポチポチと手作業で操作しており、 当然ではありますが一日で構築することのできるサーバ台数は制限されておりました。 しかし、嬉しい悲鳴ではございますがサービスも順調に拡大していき、 最近は一度に作成しなくてはならないサーバ台数も膨れ上がっていき… 手作業なんてのは考えられないものとなりました。 そこで少しずつ運用上の処理の ジョブ化 やインフラ構成の 仮想化 、 そしてさまざまな処理の 自動化 なんてもの( Zabbix ではホストの自動登録)を導入しておりましたが、 監視内容の一部はどうしてもホストの自動登録機能だけでは痒い所に手が届かず、 仕方なく泣きながら手作業を行う… そんな運用になっていました。 1回ごとの作業はわずかな作業とはいえ、台数を重ねると運用的にも心情的にもやっていけるものではなく、 何とかもっと 【楽】 にやれないものか…とたどり着いたのが Zabbix API となります。 明日の監視生活を 【楽】 にしよう！ それでは前置きが長くなりましたが早速 Zabbix API について説明をさせていただきます。 Zabbix API とは？ 詳細な仕組みついては賢く偉い人がたくさん説明してくれているので… ごくごく簡単に言うと わざわざ GUI で管理画面にアクセスしなくても Zabbix のデータを取得したり、 Zabbix の設定ができるもの！ と考えてもらえるとよろしいかと思います！ 運用に携わるものの積年の悩みである無限の画面ポチーから解放されるものですね。 Zabbix API 超・入門 それでは実際に私が実施している Zabbix 監視の追加方法について、 実例をもとに説明させていただきます。 今回の実例は、以下に示すように Zabbix トーク ンの取得！ Zabbix からグループIDとテンプレートIDの取得！ Zabbix へ指定したグループとテンプレートに所属するホストを作成！ Zabbix トーク ンの破棄！ の流れになっていますので、ごらんの皆様もイメージしやすいかと思います！ Zabbix トーク ンの取得！ まず Zabbix API を使うには、以下の3つの情報が必要です。 管理画面のアクセスURL 管理ユーザID 管理ユーザパスワード こちらの3つの情報を使って、 Zabbix API とやり取りするための トーク ンを取得することで、 実際に Zabbix のデータを取得したり、 Zabbix へデータを登録できるようになります！ では早速 トーク ンを取得してみましょう。 curl -k -s -d ' { "jsonrpc": "2.0", "method": "user.login", "params": { "user": "[管理ユーザID]", "password": "[管理ユーザパスワード]" }, "id": 1, "auth": null } ' -H " Content-Type: application/json-rpc " https:// [ 管理画面のアクセスURL ] /zabbix/api_jsonrpc.php | gawk -F ' " ' ' {print $8} ' このコマンドを実行すると以下のような不思議な文字列が取得できると思います。 これが トーク ンといわれるものです。 9c22b1eade384b1c222e52d0fb4fa303 無事に トーク ンが取得できましたね！ それでは実際にこちらの トーク ンを使って Zabbx のデータの取得や Zabbix へのデータの登録を行いましょう！ Zabbix からグループIDとテンプレートIDの取得！ 実際にホストを登録するにあたって、 事前にホストを所属させたいグループIDとテンプレートIDを調べておきましょう！ それでは！先ほど取得した トーク ンを使って実際にグループIDとテンプレートIDを取得してみましょう！ まずはグループIDから取得してみましょう。 curl -k -s -d ' { "jsonrpc": "2.0", "method": "hostgroup.get", "params": { "output": "extend", "filter": { "name": [ "[グループの名前]" ] } }, "auth": "[トークン]", "id": 1 } ' -H " Content-Type: application/json-rpc " https:// [ 管理画面のアクセスURL ] /zabbix/api_jsonrpc.php | gawk -F ' " ' ' {print $10} ' このコマンドを実行すると以下のようなIDが取得できると思います。 これが グループID です。 25 続いて、テンプレートIDを取得してみましょう。 curl -k -s -d ' { "jsonrpc": "2.0", "method": "template.get", "params": { "output": "extend", "filter": { "name": [ "[テンプレートの名前]" ] } }, "auth": "[トークン]", "id": 1 } ' -H " Content-Type: application/json-rpc " https:// [ 管理画面のアクセスURL ] /zabbix/api_jsonrpc.php | python -mjson .tool | grep templateid | gawk -F ' " ' ' {print $4} ' このコマンドを実行すると以下のようなIDが取得できると思います。 これが テンプレートID です。 10484 無事にグループIDとテンプレートIDが取得できましたね！ それでは次はこちらを使って Zabbix へのデータの登録を行いましょう！ Zabbix へ指定したグループとテンプレートに所属するホストを作成！ ついに必要な情報が揃いました！ それではおまちかね、Zabbix に監視対象ホストの登録を行いましょう！ 揃えた情報を利用して、以下のようにコマンドを実施すると…… curl -k -s -d ' { "jsonrpc": "2.0", "method": "host.create", "params": { "host": "[登録したいホスト名]", "interfaces": [ { "type": 1, "main": 1, "useip": 1, "ip": "[監視したいIPアドレス]", "dns": "[登録したいホスト名]", "port": "10050" } ], "groups": [ { "groupid": "[グループID]" } ], "templates": [ { "templateid": "[テンプレートID]" } ], "inventory_mode": 1 }, "auth": "[トークン]", "id": 1 } ' -H " Content-Type: application/json-rpc " https:// [ 管理画面のアクセスURL ] /zabbix/api_jsonrpc.php | python -mjson .tool 無事登録できましたね！ これでまとめて一気にホストを登録できますね！ スクリプト などに組み込んで一気に登録してあげましょう！ Zabbix トーク ンの破棄！ 利用の終わった トーク ンはちゃんと破棄しておきましょう。 お片付けは大事です。 curl -k -s -d ' { "jsonrpc": "2.0", "method": "user.logout", "params": [], "id": 4, "auth": "[トークン]" } ' -H " Content-Type: application/json-rpc " https:// [ 管理画面のアクセスURL ] /zabbix/api_jsonrpc.php まとめ さて、実際の流れを通して Zabbix API の使い方の一例としてホストの登録方法についてご案内させていただきました。 単なるホストの登録…だけで言うと自動登録機能を使ったほうがもっと簡単にできますが、 それだけでは痒いところに手が届かないという人や、 Zabbix API を使ってみたいけどどうしたら！？って人が少しでも 【楽】 になれば幸いです。 また過去記事ですが Zabbbix の LLD (ローレベルディスカバリ) についての記事も書いておりますので 良かったらこちらも見ていただけますと幸いです。 ・ ちょっとうれしいZabbixLLDテクニックメモ - RAKUS Developers Blog | ラクス エンジニアブログ 参考 https://www.zabbix.com/documentation/current/manual/api エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com