弊社で毎月開催し、 PHP エンジニアの間で好評いただいている PHP TechCafe。 2021年10月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「Laravel 入門を語り合う」のテーマで開催しました。 rakus.connpass.com Laravel導入手段 スグに始められるLaravel ここ一年で勢力図が大きく変わった 環境構築が選べるLaravel 環境構築は語りたいことが多い お隣さんが気になるLaravel Local環境で完結させたい派？Local環境を汚したくない派？ Laravel開発手段 サクっと作れるLaravel ルーティングについて Controller作成 ControllerからViewにパラメータを渡す Migrationについて Modelについて おわりに Laravel導入手段 前半のテーマでは、Laravelの開発環境構築手段についてDocker、ローカルマシン、仮想環境と系統ごとに気になるものを掘り下げながらのディスカッションが行われました。Laravel Sailが便利過ぎて秒で環境構築ができるのでLaravelの学習がスグに始められるというのが話題の中心になりました。 スグに始められるLaravel ここ一年で勢力図が大きく変わった 約一年前の PHP TechCafeで、当時リリースされたばかりの Laravel Sail について話した事を振り返りながら、この一年でLaravel Sailが公式のDocker環境にまで急成長したことが話題になりました。 これには docker-laravel を作られた @ucan_lab さんご自身もLaravel Sailの勢いの凄さについてコメントされていました。 Laravel Sailについては他にも Dockerの知識がなくても使える curl でURLパラメータに指定したサービスのコンテナだけが実装されるのが凄い所 各種DBやRedis、 Memcached などの様々な ミドルウェア をあわせて利用できる インターン の学生にも人気がある などの賞賛する声が多く挙がっていました。 環境構築が選べるLaravel 環境構築は語りたいことが多い 環境構築のテーマは PHP TechCafeの語り合うメンバーでも語りたいことが多く、紹介を兼ねて次のような話題で盛り上がりました。 Docker系 Laradock 全てが詰まったLaravel Docker環境。 黎明期はみんなこれを使っていた。 Docker系 docker-laravel 日本語で解説されているので解りやすかった。 Laravel Sailが主流になるまではお世話になった方も多い筈。 ローカルマシン系 Valet Mac 限定だがとにかく軽量で早い。 仮想環境系 Homestead 以前はこれがスタンダードな環境構築だった（古いバージョンだと公式に書いてあった）。 お隣さんが気になるLaravel 「（案件の本番環境で使うかは別として）勉強する時にどれくらいの人がLaravel Sailを使っているんだろう？」という疑問を切っ掛けに、他の皆さんが環境構築をどうされているかが気になる展開になりました。 Local環境で完結させたい派？Local環境を汚したくない派？ Local環境で完結させたい派「サービスの規模によるがDockerを立ち上げなくて済む」 Local環境を汚したくない派「何でもいいからDockerに入れて困ったら消してしまえってしてますね。」 などの双方の意見が出される中 「５名程度の開発でテストサイトの場合だったら何を使うか？」 とのチャットで寄せられた質問に対して意見を出し合いその場で答える場面もありました。 クライアントやデザイナーとの情報共有レベルなら何でも良さそう Laravel Sailで共通の環境を立ち上げて気軽に使えば良さそう プロダクト開発の中でのテストの目的ならインフラ担当者やマネジメントレベルの議論も必要だろう などの意見が出ていました。 Laravel開発手段 サクっと作れるLaravel ここからは後半のテーマとしてデータの追加・変更・削除が行えるToDoアプリ作成を例に、Laravelで開発を進める手順の解説が行われました。 「Laravelの公式リファレンスは情報量も多く便利だが何から進めて行けば良いのかが掴み辛い」という意見もあり、今回のテーマが参考になりそうな内容でした。 ルーティングについて ViewであるBladeファイルを新たに用意しweb. php にそのルーティングを追加して画面に表示させる実演が行われ、URLパラメータを取得したり、Viewへパラメータを渡す方法なども合わせて紹介されていました。 web. php 実装例 <?php Route :: get ( '/hello' , function () { return view ( 'hello' ) ; }) ; Bladeファイル実装例 < h1 > PHPerのための「Laravel 入門を語り合う」PHP TechCafe </ h1 > < div > < p > Hello World! </ p > </ div > web. php への追加とBladeファイルの作成のみで画面が作れる事から やっぱりサクっと作れるのが良い。 がっつり書き込まなくてもある程度期待通りの動きをしてくれるのは作っていて楽しい。 などの意見が出ていました。 Controller作成 Controllerの作成方法としてLaravel Sailでartisanコマンドを使っての方法が紹介されました。 ./vendor/bin/sail artisan make:controller HelloController ここでは注意点として、 rootユーザで php artisanコマンドを使ってしまうと作成されたControllerファイルの所有者もrootユーザになり、WEBサーバからのアクセスもroot権限でないと出来なくなってしまうので、Laravel Sailの使用がお勧め と説明されました。 「（それは）あるあるだね」などの共感コメントも多く寄せられていました。 関連してResource Controllerについても終盤におまけとして紹介されていました。 Controller作成のartisanコマンドにresourceオプションを付けるとデータの取得、追加、更新、削除を行うメソッドが自動的に追加される機能の事で、今回のToDoアプリに必要なメソッドも一通りまかなってくれる内容との説明がありました。 Controllers - Laravel - The PHP Framework For Web Artisans ControllerからViewにパラメータを渡す Controllerファイル実装例 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; class HelloController extends Controller { public function index () { return view ( 'hello' , [ 'name' => 'Rakus' ]) ; } } ルーティングの項ではリク エス トされた際に直接Viewを表示する解説でしたが、ここではControllerを呼び出しその処理結果をViewに渡す開発に即した作成方法を解説しました。 Controllerクラスのメソッドでリク エス ト情報を受け取る方法や、「機能毎にControllerを割ってファイルを分割する方が管理もしやすく複数人での開発もやりやすい」といった実例紹介もありました。 「RoutingにControllerの処理を書くとどうなるか」 との質問がコメントで寄せられましたが、これに対してrootキャッシュが通らなくなるという回答がありました。 「通常はアクセスが来た時には PHP の コンパイル が走って二回目以降は処理が早くなりますが、それが出来なくなる」と解説されました。 Migrationについて Webアプリに不可欠なデータベースの管理についてMigrationでテーブル作成する解説が行われました。 Laravelのデータベースクエリビルダが用意されているので使用頻度が低めでCreate Table文に馴染みがなくても「これ一つ書いたら作られるんですよね？」となるのが便利な一方で、「 SQL の書き方を忘れるっていうのはありそうだ」などの意見も出ていました。 複雑な結合をさせたい場合、「Modelの使い方をマスターしていない場合でも、LaravelにはDBクラスもあって SQL を直接自分で書くことも可能」との補足説明もありました。 Migrationファイル実装例 <?php use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class CreateTodoTable extends Migration { /** * Run the migrations. * * @return void */ public function up () { Schema :: create ( 'todo' , function ( Blueprint $ table ) { $ table -> id () ; $ table -> timestamps () ; }) ; } /** * Reverse the migrations. * * @return void */ public function down () { Schema :: dropIfExists ( 'todo' ) ; } } Migrate実行時の処理であるup関数で作成するテーブルのTimestamp型カラムについての解説では次のような意見が出ていました。 レコードの作成時や更新時に自動的に日時がセットされるので便利 知らないうちに全部やっているっていうのがLaravelっぽい 「テスト用の環境に SQLite を使っているが、Migrationのコードに手を加えないと SQL が上手く動かない場合があるのですが、どうしていますか？」 とのチャットの質問では参加者の方々に採用しているデータベースについて決を採る場面もありました。 結果は SQLite を使っていない派が多数を占めていました。 Dockerでそのまま入っちゃうからあんまり気にせず PostgreSQL とかでやっちゃいますね… 本番環境でも実行しているMigrationなのであればテスト用環境のデータベースは MySQL などを使い、Migrationファイルをいじらずに済ませるのが無難なのでは？ などの意見が挙がっていました。 Migration実行のartisanコマンド ./vendor/bin/sail artisan migrate テーブルを作り直す場合に ロールバック せずともテーブル削除とMigrate実行をセットで行ってくれる便利なmigrate:freshコマンドや、関連して初期データを投入してくれるseederの紹介も行われていました。 Modelについて ./vendor/bin/sail artisan make:model Todo 内容が盛り沢山で最後は駆け足になりながらも、実際に画面を動かしModelクラスを経由してDBのデータ取得・登録・編集・削除が容易に行える様子を実演して締めくくりました。 今回のTeckCafeで解説した内容はHackMDにまとめられていますので合わせてご覧ください。 hackmd.io おわりに 『 PHP TechCafe』では今後も PHP に関する様々なテーマのイベントを企画していきます。 是非、皆さまのご参加をお待ちしております！ connpass.com ◆ PHPTechCafeの過去公開したイベントレポートも合わせてご確認ください！ ・ PHPerの今とその先について in 2021 【PHP TechCafe イベントレポート】 ・ PHP8.1 の新機能について語り合う・前編【PHP TechCafe イベントレポート】 ・ PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 ・ PHPUnit の始め方について語りあう 【PHP TechCafe イベントレポート】 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

開発本部の本年度（2022年3月期）の取り組みについて １．エキスパート人材の育成・強化 ２. プロダクトマネジメント機能の強化 ３．新しい技術の習得　 こんにちは。 ラク スの開発組織を統括している開発本部長の公手（くで）です。 先月2/8に記念すべき第1回「RAKUS Tech Conference 2022」を開催致しました。 多くの社外のエンジニア様にご参加していただき、大変ありがたく思っております。 そのオープニングセッションで ラク スのエンジニア組織について発表させていただきました。 speakerdeck.com ラク スのエンジニアも何名か聞いてくれており、 「もう少し頻度上げて開発組織全体の取り組みを社外に公表していっても良いのでは？」 というフィードバックもあったことから、早速 ラク スのTechブログに投稿してみることにしました。 今後も、 不定 期ではありますが、投稿できればと思っています。 以下、「RAKUS Tech Conference 2022」のレポートも是非ご確認ください。 tech-blog.rakus.co.jp 開発本部の本年度（2022年3月期）の取り組みについて ラク スの決算期は3月末です。 本年度もあと1か月を残すのみとなりましたが、本年度に重点的に取り組んだことについて書いてみました。 ラク スの開発本部では、毎年9月から部門ごとに翌期の取り組みについて考え始めます。 その後、12月に各部のエンジニア リングマ ネージャーが集い、翌期の重点取り組み事項を決めます。 基本的には会社の5か年の中期経営計画に合わせて、5か年の組織ロードマップや技術ロードマップを作成しています。 ラク スの中期経営計画については以下のIR情報をご覧ください。 www.rakus.co.jp そのロードマップには、5年後の到達地点から逆算して1期目～5期目の取り組み事項が描かれています。 9月からの作業は、内外の状況の変化などもあるため、ロードマップをアップデートし、翌期にやることを具体化していくといったことになります。 ラク スの開発本部は250名の組織であり、20以上の課やチームが存在します。 それぞれの組織で、現場の要望、共通課題などをリストアップし、エンジニア リングマ ネージャーたちが各組織のロードマップを作成しています。 さらにそれらを俯瞰し、抽象化して、開発本部全体の組織ロードマップを作成します。 ロードマップに書かれている翌期の取り組みの中から、より重要なもの、開発組織全体に関わるものを 選び出して重点取り組み事項として5～6つぐらいまで絞り込んでいます。 昨年掲げた、今期の重点取り組み事項は以下の6項目でした。 《今期の重点取り組み事項》 エキスパート人材の育成・強化　 プロダクトマネジメント 機能の強化 新しい技術の習得　 組織 ブランディング オフショアの強化 データセンター移転 今回は、これらのうち、3点を取り上げ、当社の課題感などを共有できればと思っています。 　 １．エキスパート人材の育成・強化 実は ラク スは一つのプロダクト開発組織がそれほど大きくなく、（多いチームでは50名を超えるぐらい）、10名～20名ぐらいで開発しています。 数年前はさらに少人数で開発をしていました。 その時代は、どちらかというとバックエンドもフロントエンドもできてプロジェクトマネージャーもできて要件定義等の上流工程もできるという、全方位に活躍できるようなエンジニアを育成したり、求めたりしていました。 しかしながら、このように何でもできるエンジニアというのは育つのに時間もかかりますし、そういった志向のエンジニアが必ずしも多いわけでもなく、採用も難しいです。 組織の人数を増やしていく必要性から、役割の分化が必要であるということに少し前から気が付きました。 そこで、各領域・領域のエキスパートを育てたり、採用したりする方向に変わってきました。 エキスパートになるために必要とされるスキルセットをまとめ、再現性のある育成プランを作っていく、取組を1昨年前より始めています。 今期も継続して取り組んでおり、一定の成果が出てきています。 具体的には以下のようなエキスパート人材の採用や育成に取り組みました。 プロジェクトマネージャー 各 ドメイン のエキスパート フロントエンドエンジニア モバイルエンジニア QAエンジニア ブリッジSE インフラコア技術(オンプレ仮想化）のエキスパート など。 まだまだ各領域で不足感はあるものの、育成が進み、採用による増員もできました。 ２. プロダクトマネジメント 機能の強化 プロダクトは成熟してくると、何を開発するのかが非常に難しくなってきます。 例えば、市場に後発で投入したプロダクトは、当面は他社と勝負できるように劣後点をつぶしていく必要があり、開発すべきことは山ほどあります。 また、 PMF を達成した後は、顧客からの要望が一気に増え、顧客の要望満たすための開発が当面続きます。 しかしなら。数年も経過すると製品も成熟してきて、お客様の要望も少なくなってきます。 こうなってくると、今度は何を開発するか考えることが難しくなってきます。 ラク スの場合も、リリース後10数年経過したサービスではその領域ではトップシェアを誇り、機能ラインナップでもほぼほぼお客様のニーズを満たせるサービスにもなってきています。 ただ、そこで終わってしまうとプロダクトの成長も終わるので、顧客が気付いていない 潜在的 なニーズを探し新しい付加価値を作って行くことになります。 いくつかの商材ではそういった新しい付加価値をどんどん生み出す力が不足気味です。 数年前から、組織として プロダクトマネジメント 力の強化に取り組んでいます。 今期は、 プロダクトマネジメント 担当者のつくり、プロダクトマネージャーの採用強化を進めるとともに、また、プロダクトマネージャーを強力に補佐ですべき役割であるUIデザイナの拡充も一定進みました。 ３．新しい技術の習得　 クラウド サービスは、10年、20年と開発が続いていくサービスです。 ラク スでもメールディーラーでは18年、配配メールは15年、楽楽精算はで11年と続いています。 その間に、Webの技術はどんどん進化し、新しいことができるようになってきています。 しかしながら、進化の流れに合わせて新しい技術ををどんどん製品に取り入れられるわけではありません。 昨今、当たり前となったマイクロサービスであれば新技術投入はやりやすいですが、レガシーな アーキテクチャ で開発を続ける限り、新技術に触れるたり検証する機会はどうしても少なくなっています。 しかしながら新しい技術は実際に振れて試してみないとなかなか身につきません。 組織として、どんどん後れを取っていきます。 また、いざ新サービスを立ち上げる時に、技術習得から入っているとリードタイムもさらに伸びます。 使ったことがない技術だから、、、ということで、稼働の制約などからも敬遠したりするようなことがありがちです。 ※当社も過去に数度そういう選択をしてきました。リリースの速度感を考えると間違いだったとは思っていませんが、、、 そこで ラク スでは、Webの デファクト スタンダートな技術、あるいは デファクト になり得そうな技術については、各プロダクト開発で使っていなくてもノウハウを習得しておくべきということで、数年前に、有志達により、「かみせん」というプロジェクトが発足し、週に一回数時間だけ集まっての小さな研究活動（というか技術習得活動）がスタートしました。 このプロジェクトで得たノウハウで、実際に新規サービスのリリー スリード タイムに貢献出来たり、プロダクトが抱えていた問題の解決に役立ったりと小さいながらも一定の成果が見え始めました。 今では、その試みを推進する組織（技術推進課）に昇格させ、開発本部の組織的な取り組みとしています。 目新しいもの使ってみるという視点から、既存サービスの抱えている課題感を解決できそうかという視点で研究テーマも選定しています。 今期は以下のようなテーマに取り組み、このうち3件が来期のプロダクト開発に活用されることになりました。 認証関連 コンテナ オーケストレーション 不具合の早期検知（ APM ） CSS プラットフォーム サーキットブレーカパターン ドキュメントDB AI領域 来期も新しいテーマに向けて取り組んでいきます。 技術推進課の取り組みをまとめた記事です。 こちらも合わせご確認ください！** tech-blog.rakus.co.jp また、 ラク スでは一緒に働いてくれるエンジニア・デザイナーを積極募集中です。 まずは相談だけでもという方は、カジュアル面談も大歓迎です！ rakus.hubspotpagebuilder.com お気軽にどうぞ。 では次回は残りの3つについて、ご報告できればと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 第1回 形式 反省点、改善の余地 第2回 形式 第1回から継続 第1回から変更 反省点、今後の展望 アンケート結果 次回以降の輪読会で読みたい本のテーマ 参加メンバーからの意見・感想 おわりに 参考 はじめに こんにちは。mtaaaです。 ラク スのフロントエンドチームでは、2021年上半期に週1回の輪読会を開催していました。 1人では読むハードルの高い、内容重めの書籍を勉強する場としてだけでなく、メンバーの交流の場としても有意義だったため、単発で終わってしまうのはもったいないと考えました。 下半期も開催すべく主導で動いたので、 輪読会のノウハウや改善点、参加メンバーの声を共有したいと思います。 第1回 書籍は「 CSS設計完全ガイド ~詳細解説+実践的モジュール集 」 書籍の選定については、参加するメンバーが担当するプロダクトがそれぞれ異なる状況から、言語や フレームワーク に依存した内容ではなく、フロントエンドエンジニア全般に生かしやすい内容のものとしています 形式 参加人数は10人前後 Google Jamboardに読んだ内容の感想、気付き、派生した情報共有を各々が書き込む 毎週業務時間内で同じ時間に1時間枠を設け、30分間読書&Jamboard書き込み、30分間Jamboardに記載の内容や書籍自体を深掘って内容の理解や各開発者の目線ごとの意見共有 1回で30~40ページを読み進める 主催のメンバーが ファシリテーター を毎回行い、読む範囲の指定やJamboardの作成といった事前の準備や周知、当日の進行を取りまとめていた 完全リモートでの開催(情勢もあり選択肢がこれだけ) 反省点、改善の余地 主催のメンバーに負担が集中してしまっていた 1回のボリュームが多く、読み切れなかったり、予習前提になってしまったりした面があった 発言が一部メンバーに固定されがちだった 第2回 書籍は「 リファクタリング(第2版): 既存のコードを安全に改善する 」 第2回では、上記課題を改善することに加えて、主催を含めメンバーの負担をできるだけ減らして参加しやすくなる会を目指しました 形式 第1回から継続 参加人数は10人前後 Google Jamboardに読んだ内容の感想、気付き、派生した情報共有などを各々が書き込む 毎週業務時間内で同じ時間に1時間枠を設け、30分読書&、30分書籍の特にJamboardに記載の内容を深掘って内容の理解や各開発者の目線ごとの意見共有 第1回から変更 ファシリテーター を当番制にして全メンバーに回るようにし、当日の進行を盛り上げやすいように毎回2人設定した オフィスのオープンスペースでの開催がメイン(途中から情勢を鑑みてリモートでの開催に) →リモート開催をZoomからGatherに移行し、オフィスで開催しているような感覚を得られた 読み切れない場合や、事前の予習が前提となりがちだったため、1回で15~20ページを読み進める →これに伴って輪読会自体の開催期間が伸びたが、参加者は事前準備を気にせず、本だけ持って当日を迎えればいい状態を作れた 元々参加自由ではあったが、これを明言し、回によって参加不参加があっても問題ないことを強調した →メンバーが業務とバランスを取りやすい環境を作れた 開催期間終盤に参加者アンケートを取った →出席率、満足度、形式についての要望、輪読会自体への感想、要望、今後読んでみたい書籍のテーマなど 主催となった私が準備したのは本の発注と読む範囲の選定、日程の周知くらいであり、一度走り出した後は私がいなくとも回る形を作れたので、今後輪読会を開きたい、というメンバーが気軽に主催できるサンプルにはなったように思います。 Gatherでのリモート開催の様子 反省点、今後の展望 読む時間より議論の時間を長めに確保する 発言者が偏りがちだったため、少人数でのグループを作って雑談感覚で意見交換する形式も試してみたい 輪読会数回ごとにメンバーの意見や情報共有をまとめてマガジン化してみたい 各メンバーの業務都合で ファシリテーター の急な変更が何回も発生してしまった →事前にある程度予習しておきたい人もいたため、直前に交代が決まると準備できなかった アンケート結果 輪読会出席率 来期以降の開催について 内容の満足度 次回以降の輪読会で読みたい本のテーマ リーダブルコード React/Vue TypeScript/ JavaScript Git 設計 オブジェクト指向 デザインパターン といったものが挙げられていました。 特にリーダブルコード等プログラミングの基本について学びたい要望が多かったです。 参加メンバーからの意見・感想 異なるプロダクトを担当し、かつバックグラウンドの違うメンバーが揃っており、本の内容から派生したフロントエンド技術全般の情報共有が非常に有意義 普段は積極的には読まないような厚い内容の本が読めた 担当プロダクトが異なるために交流の少ないメンバーの意見や、他プロダクトでの開発ケースでの話を聞ける機会になった 本の内容が開発に生きた 前提知識や、基礎的な内容の復習になった 議論が単純に楽しい、リフレッシュになる おわりに 今回は、社内輪読会での試行錯誤について書いていきました。 輪読会は本来の目的である、1人で読むには難しかったり、重かったりする書籍を読む機会を設けるだけでなく、普段交流の少ないメンバーと話せる場所としての需要が大きいように感じました。 本記事が読んでくださった方の輪読会開催の一助になればと思います。 ここまで読んでいただきありがとうございました。 参考 オンライン輪読会を2回主催して、やめた取り組みのいくつか 技術書の輪読会を定着させるまでの道のりで学んだこと エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 突然ですが、変化の多いフロントエンド関連の情報を日頃どのようにインプットされておりますでしょうか？ SNS やWeb記事、最近では Podcast という方もいると思います。 しかしながら「時間に余裕がない！」という方も多くいらっしゃるはずです。 そんな方のために、 ラク スでは フロントエンド関連の最新ニュースや記事を定期的にピックアップし、エンジニア同士が楽しみながら学習するためのコミュニティ『フロントエンドTechCafe』 という憩いの場を定期的にご提供しております。 本記事では、2020年～2021年に開催した「フロントエンドTechCafe」のイベント内容をまとめております！ フロントエンド領域の知見を高めたい方 フロントエンドエンジニアを目指している方 フロントエンドTechCafeにご興味ある方 などなど、是非ご参考いただけますと幸いです。 【目次】 フロントエンドTechCafeとは 2020年度開催 フロントエンドのニュースや記事を紹介して語り合う会@TechCafe（Vue,TS成分多め） 「Vue.js 3.0」を語るフロントエンドTechCafe 「2020年の振り返りイチオシ情報」を語るフロントエンドTechCafe 「フロントエンド開発の便利ツール・設定・プラグインなど」を語るフロントエンドTechCafe 2021年度開催 「フロントエンド開発の便利ツール・設定・プラグインなど」を語るフロントエンドTechCafe #2 「再入門！フロントエンドエンジニアが押さえておくべき技術」を語るフロントエンドTechCafe ラクスのエンジニアと話をしてみたい方へ まとめ フロントエンドTechCafeとは 「”フロントエンド” TechCafe」は、 JavaScript などフロントエンド関連の技術要素を軸としてエンジニアと技術が交差する憩いの場（カフェ）になることを目指しています。 主に、 JavaScript に関して学習中の初級エンジニア～シニアエンジニア を対象としておりますが、 エンジニア同士の学びの場をつくり、エキスパートまでの自己成長を支援 学びの場を一緒に支援して頂けるエキスパート以上の方の参加も大歓迎 私たちと皆さまが共に成長できる場としたい という思いで開催をしております！ なお、 ラク スで採用している技術要素の関係から、 JavaScript やTypeScriptなどの話題が多くなる可能性がございます。 そちらはご承知おきくださいませ。 2020年度開催 フロントエンドのニュースや記事を紹介して語り合う会@TechCafe（Vue,TS成分多め） rakus.connpass.com 初開催したのは、2020/7/31です。 初回の議題は以下のような内容でした。 ＜ 導入トピック ＞ ・2020年の11の必見のフロントエンドトレンド 参考にした記事から注目ポイントを厳選し、今後のトレンドについて意見交換をしました。 ＜ Vue.js関連情報 ＞ ◆ Vue3 RCリリース 新機能である Composition API 、 Teleport 、 Fragments 、 Emits Component Option について紹介。 また、Vue Composition API のメリット/デメリットをまとめた記事を見た上で、コンポ―ネント間でのロジックの断片化などの課題感を実際の現場状況と踏まえ協議しました。 ＜ TypeScript関連情報 ＞ ・ TypeScript4.0で導入された新機能 ・ TypeScript、JavaScritpの誕生背景や歴史 ・ TypeScriptの enum についての評価 などなど ＜ ES関連情報 ＞ ◆ ES2020リリース ・仕様一覧（ Finished Proposals ） ・ JavaScript : Latest Stage-4 features についてご紹介しました。 イベント当時にStage4まで進んでいる提案リストもあるようです。 ＜ サーバーサイド関連情報 ＞ DenoとNodeのパフォーマンス比較記事を紹介。 ＜ JavaScript ・フロントエンド全般 ＞ 残り時間を利用し、 JavaScript ・フロントエンド全般の気になった記事を基に議論しました。 JavaScript ライブラリを読むコツや、DOMとうまく付き合う方法などがありました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「Vue.js 3.0」を語るフロントエンドTechCafe rakus.connpass.com 2020/11/11に、「Vue3」をテーマに2回目のフロントエンドTechCafeを開催し、 リリースノート 、 vue3マイグレーションガイド: イントロダクション 、 RFC を見ながら 以下議題について当社出演者が語り合いました。 Vue3新機能の紹介と現場エンジニアの声 Vue2との比較 Vue2 -> Vue3移行時に気になるポイント 参加者も300名近くなり、 「CompositionAPIは嬉しい」 「プロダクトが大規模化する中でコードの分割をするも、2系のmixinでは難点が多そう・・・」 「UnitTestも書きやすくなりそう」 「Vue3への移行は？」 などが話題となり、大変盛り上がりのあるイベントとなりました。 「2020年の振り返りイチオシ情報」を語るフロントエンドTechCafe rakus.connpass.com 第3回目は2021/2/10に開催！ タイトルの通り、2020年のフロントエンド関連の様々なニュースのうち、出演者イチオシのものを選んで語り合った会です。 ＜ 印象に残った・興味深いトピックス ＞ ◆ Vue3リリース リリースノート 、 マイグレーションガイド などでリリース内容の確認をしました。 ◆ Chromium edge のリリース www.publickey1.jp 旧edgeとの違いや、サポート終了の話で盛り上がりました。 ◆ webpack5リリース webpack.js.org webpack（=モジュールバンドラー）とは？ webpack5変更点とは？ といった観点で記事をピックアップし、語りました。 ◆ TypeScript4.0 のリリース devblogs.microsoft.com 追加機能をまとめたQiitaの記事を見ながら、どのように導入ができそうか話しました。 今回のアップデートは、安全性や利便性を高める比較的安定した機能追加が多かったとこのことです。 弊社メンバーは、「機能よりも VSCode の構文ハイライトの高速化が気になった」とのことでした。 ◆ Vuex4リリース github.com Vue4の基本的な使い方は前バージョンと変わらないが、初期化が大きく変わっているとのこと。 リリース内容だけでなく、その他のエコシステムやUIライブラリなどもピックアップしております！ ◆ Babel 7.9.0リリース 7.9.0 Released: Smaller preset-env output, Typescript 3.8 support and a new JSX transform · Babel 8.0に向けた準備。 JSX変換の最適化やパンドルサイズの縮小が追加されました！ ＜ ツール・ライブラリ ＞ ◆ Vite github.com Viteは、ノーバンドルなビルドツールです。 ビルドが遅いという話がメンバーからよく話に上がるVue CLI と比べてると、開発は楽になりそうであると話題になりました。 ◆ core-jsのメンテナンス再開 core-jsとは、babelのpolyfill内部で使われているモジュール集であり、 ブラウザによっては実装されていないPromiseやArray系の関数を使えるようにするものです。 ここでメンテナンスを取り巻く状況についてをご紹介しました。 5年間、1人のメンテナによってメンテナンスがされ続けていたが、交通事故を起こしてしまい開発が停止。 メンテナが2020/10に復帰し、開発が再開されたのことです。 メンバーからも、 ・多くの人が利用していると思うが開発継続には人員や収益などのリソースが必要 ・開発が終了するリスクを考えると、自身も何かしらの形で利用している OSS へ貢献していきたいと思わされた のような意見がありました。 ◆ StateOfJS2020（10000人のエンジニアによる投票結果） 2020.stateofjs.com それぞれの分野のランキングの推移は…？ ◆ Denoの紹介やNodeとの違いなど Denoは、Node. jas の作者であるRyan Dahlが新たに作った JavaScript の実行環境です。 deno.land 本時間では、Node.jsの問題点やDenoの特徴について、参加者と話をしました。 その他トピックとして、 ES2020とES2021 Moment.js の非推奨化 ReactとVueとSvelteで同じアプリを開発してみて比較した記事 などをピックアップし、限られた時間の中で参加者と一緒に楽しむことができました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe rakus.connpass.com 2021/3/10に開催した本イベントは、参加申込が450名を超える大人気イベントとなりました！ では早速、当日お話しした内容を見てましょう。 ＜ ラク スエンジニア＋参加者の皆さまお薦めのツール類 ＞ ※イベント申込時に、参加者の皆様にアンケートを実施しました。 ◆ VSCode 拡張 live share visualstudio.microsoft.com 複数人同時編集可能 ペアプロ などで使えそう LiveServer marketplace.visualstudio.com 参加者アンケートの結果 ・ vscode の 拡張機能 ・簡単にwebサーバが立ち上げられる ・ローカルで作ったペライチhtmlから API 叩くときに便利。 ・ Chrome のデフォルト設定ではローカルhtmlファイルから外部ソースを参照すると、デフォルトではorigin:nullでCORSエラーにひっかかるため Visual Studio Code Remote Development code.visualstudio.com VSCode の拡張パック 名前はRemoteとあるが、リモートマシン上の開発の他、コンテナやWSL上での開発でも使用できる リモートマシン/コンテナ/WSL上関係なく、同じ感覚で開発ができる 参加者アンケートの結果 ・ Windows 環境でもWSL2( Linux ) + Dockerで開発環境を整えられてとても便利です！ ・ Linux 上なのでDockerのファイルアクセスも物凄く素早いです Regex Previewer marketplace.visualstudio.com 正規表現 チェックが VSCode 上で気軽に行える JSON to TS JSON からTypeScriptの型を生成してくれる Bookmarks シンプルにコードにブックマークをつけてサイドバー管理できる 修正のし忘れ防止や実装揃えたい時にとても便利である Bracket Pair Colorizer 2 marketplace.visualstudio.com 括弧の対応を可視化できる（ex：括弧に色がつく、範囲もわかる） Todo Tree marketplace.visualstudio.com プロジェクト中のTODOコメントなどを一覧化できる indent-rainbow marketplace.visualstudio.com インデントに色づけし深さを可視化できる Auto Rename Tag marketplace.visualstudio.com ペアになっているHTML / XML タグの名前を自動的に変更してくれる拡張である ◆ 開発者ツール / Chrome 拡張 Vue.js Devtools chrome.google.com Vue.jsで書かれたアプリの デバッグ が楽になる Vue.jsの開発をサポートするブラウザの 拡張機能 JavaScript Errors Notifier JSエラーをdevツールを開いていなくても通知してくれる DevTools z-index chrome.google.com devツールでz-indexが確認できるようになる Pesticide for Chrome chrome.google.com 要素に枠線が付くのでUI崩れやpadding,margin調整ミスに気付きやすくなる Firefox の開発ツール developer.mozilla.org Firefox でF12押したら出てくる開発ツール iMacros chrome.google.com 上記、 Chrome 用 参加者アンケートの結果 ・ブラウザマクロのアドオンで、JSソースを3個まで入れることが可能で便利 ◆ Webページ関連（参考情報系） MDN developer.mozilla.org Can I use caniuse.com HTML, CSS , JavaScript の機能についてブラウザの対応状況が分かるのが便利 IE 対応や、新しい機能を利用したい場合に参照すると便利 ◆ JSライブラリ json server www.npmjs.com REST API のモック作成が簡単に行える バックエンドに先行してフロントエンド開発を行う時には便利 htmlhint www.npmjs.com htmlの構文チェックを可能 vue.jsのv-htmlを利用制限を行う際に役に立つ Testing library testing-library.com 実装の詳細に関係なくUIのテストを書けるライブラリ Reactでは公式推奨のテストライブラリとなっている ◆ API 関連 Swagger swagger.io REST API の設計、 ドキュメンテーション 、モック作成などを行うツール群 OpenAPI仕様に準拠 Postman www.postman.com API クライアント 開発時に API のテストなどを行う際に任意のリク エス トを送信しレスポンスを受け取ることが可能 自動テストの機能など、テスト用機能の他、モックや ドキュメンテーション などの用途にも活用可能 WireMock wiremock.org API のモックツール リク エス トに対する多様なマッチング判定による柔軟性 リク エス トの記録／再生による効率的なモック作成可能 参加者アンケートの結果 一番簡単にサーバサイドのモックが作れると思っている Open API generator openapi-generator.tech 定義ファイルから言語に合わせた API リク エス トの ソースコード を生成する その他のツールとしては、 インテリセンス（コード補完など）ツールである Tabnene や kite 、 Bootstrapなどと同じ CSS フレームワーク の一種である tailwindcss などがあげられました。 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 2021年度開催 「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe #2 rakus.connpass.com 3/10に開催した「「フロントエンド開発の便利ツール・設定・ プラグイン など」を語るフロントエンドTechCafe」が大好評ということもあり、2021/6/16に同テーマにて再演しました！ ＜ ラク スエンジニアのお薦めのツール類 ＞ ◆ VSCode 拡張 Jest Runner テスト関数ごとに1クリックでrun/debugできるので便利 ◆ Google Chrome 拡張 OneTab chrome.google.com 開発に使うわけではないが、 chrome のタブをストックしておくツール 調べ物などで大量にタブを開いておくと、どこになにがあるかわからなくなったりメモリを使うので一時退避にオススメ Awesome Screenshot chrome.google.com 画像・映像キャプチャの取得、ダウンロード、共有をまとめて行える chrome の画面だけではなく、デスクトップ画面全体やカメラのみにも対応 stylus chrome.google.com ページに好きな CSS を設定でき、保存もできる などなど、前回ご紹介したツール等も踏まえてフロントエンド開発に欠かせない便利ルール・設定・ プラグイン をご紹介させていただきました！ 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io 「再入門！フロントエンドエンジニアが押さえておくべき技術」を語るフロントエンドTechCafe rakus.connpass.com 2021年度最後のフロントエンドTechCafeは、 ラク スのフロントエンドエンジニアの目線から押さえておくべき技術を6テーマにてご紹介しました。 本テーマは、弊社フロントエンドエンジニアが執筆した以下記事を参考にしておりますので合わせてご確認ください！ tech-blog.rakus.co.jp ＜ JavaScript ＞ ◆ DOM操作の仕方 DOM(DocumentObjectModel）とは、ブラウザが表示しているHTMLの要素を JavaScript で操作しやすいようにしたデータ構造です。 また、「操作しやすい」といっても、最近では直接DOMを扱うこと自体を避けるようにもなってきています。 【DOM操作の例】 <!DOCTYPE html> < html > < head > < meta charset = "utf-8" > < title > タイトル </ title > </ head > < body > < section > < img src = "example.png" > < p > リンクは < a href = "https://foo.example.com/" > こちら </ a ></ p > </ section > </ body > </ html > リンクの要素を取得する const link = document.querySelector('a'); リンクの文字列を変更する link.textContent = 'あちら'; リンクのURLを変更する link.href = 'https://bar.example.com'; ◆ ES6（ES2015）以降の記法 ES( ECMAScript )とは、 JavaScript の標準規格を定めたものです。 JavaScript と ECMAScript の関係ですが、 JavaScript はあくまでブラウザ上で動作する スクリプト言語 で、厳密にはブラウザによって仕様が異なります。 ECMAScript は、 JavaScript の標準規格で、各ブラウザは ECMAScript の仕様に沿って JavaScript を開発しています。 ◆ API 呼び出し フロントエンド開発ではバックエンドの API 呼び出しの知識が必須となります。 この辺りもJS フレームワーク 任せなことが多いが、基礎知識として覚えておくと良いと思います。 API 呼び出しの書き方例は以下の通りです。 【FetchAPI】 // APIを呼び出した結果をconsoleログに出力 const url = 'https://foo.example.com/api' async function callApi() { const res = await fetch(url); const text = await res.text(); console.log(text); } callApi(); XMLHttpRequest （XHR）と jQuery での書き方は、 ShowNote をご確認ください！ ＜ TypeScript ＞ ◆ TypeScriptの特徴 JavaScript に変換されれます。 また、TypeScriptで書かれたプログラムを実行したい場合、TypeScriptをそのまま実行するのではなくTypeScriptを JavaScript に変換させて実行します。 // typescript const foo: string = 'foo' ; 👇 // javascript "use strict" ; var foo = 'foo' ; ＜ フレームワーク ＞ フロントエンド フレームワーク とは、UIの コンポーネント 化やリアクティブなデータバインティング処理をまとめたものです。 ◆ フロントエンド フレームワーク の種類 以下、メジャーなものを抜粋しました。 Vue.js jp.vuejs.org 特徴 公式ドキュメントの日本語訳が多い SFC （単一ファイル コンポーネント ）を採用 React ja.reactjs.org 特徴 公式でUIライブラリと言っているがVue.jsとよく比較される Angular angular.jp 特徴 TypeScript標準採用（＝開発に必須） フルスタックフレームワーク を自称しており、Viewの構成だけでなく一通りの機能が入っている 当日は フレームワーク の世界/日本のシェア率を比較したりしました！ その他に、 コンポーネント 指向や仮想DOMについても分かりやすく整理し、参加者の皆さんで語り合いました。 ＜ ④SPA（Single Page Application） ＞ SPAとは、（極めてざっくり言うと）ユーザーがアクセスするWebページは空の最初の１ページのみで、バックエンドの API を呼び出し動的に画面の要素の構築、画面遷移を行うタイプのアプリケーションことです。 近年では、Webアプリケーションでも、 スマートフォン のアプリのような柔軟で表現に富んだ操作性や体験が求められることが多くなったため、SPAが重要とされております。 ＜ テスト ＞ ◆ テストの種類 テストの種類は以下があげられます。 イベント当日は、各テストのメリット/デメリットについてお話ししました。 静的テスト 単体テスト 結合テスト E2Eテスト ＜ メジャーなブラウザ ＞ 最後にメジャーなブラウザについてご紹介しましたが、時間が限られおり読み上げる程度で終了してしまいました…。 取り上げたブラウザは以下の通りです。 Google Chrome Internet Explorer Firefox Safari Microsoft Edge 議題内容の詳細（記事リンク）などは、以下ShowNoteをご確認ください！ hackmd.io ラク スのエンジニアと話をしてみたい方へ ラク スでは、フロントエンドエンジニアだけでなく幅広い職種で採用を強化しております。 とはいえ、まだ応募する段階ではないという方には カジュアル面談 をご案内しております！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんとお話をしたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 まとめ フロントエンド関連の最新ニュース・記事について語り合う、「フロントエンドTechCafe」のまとめはいかがでしたでしょうか？ フロントエンドエンジニアを目指している方 フロントエンド領域を学習し始めた方 再度学習されたい方 などにとって本ブログ及び、フロントエンドTechCafeが有意義な情報となっていますと幸いです。 2022年度もフロントエンドTechCafeの開催を予定しております！ ご興味持たれる方がおりましたら、是非ご参加くださいませ。 次回、フロントエンドTechCafeは、 ラクスconnpassページ にてご案内させていただきます。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、クリエイティブ課　木村圭です。 クリエイティブ課は、 ラク スグループ内で提供しているサービスに関するWebサイトやパンフレットなどのデザイン業務を担っています。 現在、マネージャー職をしていますが、前職までUI/UXデザイナーをしておりました。 僕自身が、これまで学習した書籍や最新の関連書籍を含め、ご紹介します。 これから、UI/UXデザイナーを目指したい方やデザインにご興味のある方なども含め、ご参考になればと思います。 最初に読んでほしいUI/UX書籍はこれだ! ノンデザイナーでもわかる UX+理論で作るWebデザイン UI/UXデザインの原則 UIデザイン　みんなで考え、カイゼンする。 SF映画で学ぶインタフェースデザイン アイデアと想像力を鍛え上げるための141のレッスン ほんとに使える「ユーザビリティ」 -より良いデザインへのシンプルなアプローチ UI GRAPHICS 成功事例と思想から学ぶ、これからのインターフェイスデザインとUX UXデザインの教科書 UXデザインの法則 ―最高のプロダクトとサービスを支える心理学 UX戦略 ―ユーザー体験から考えるプロダクト作り インタフェースデザインのお約束 ―優れたUXを実現するための101のルール はじめてのUXリサーチ ユーザーとともに価値あるサービスを作り続けるために UXライティングの教科書 ユーザーの心をひきつけるマイクロコピーの書き方 あわせて読んでほしい書籍はこれだ! バグトリデザイン 事例で学ぶ「行為のデザイン」思考 人間中心設計入門 (HCDライブラリー) インタフェースデザインの心理学 第2版 ―ウェブやアプリに新たな視点をもたらす100の指針 行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する ビジネスデザインのための行動経済学ノート バイアスとナッジでユーザーの心理と行動をデザインする デザインリサーチの教科書 未来ビジネス図解 これからのデザイン思考 はじめてのカスタマージャーニーマップワークショップ「顧客視点」で考えるビジネスの課題と可能性 できたら読んでほしい書籍はこれだ! ノンデザイナーズ・デザインブック なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 DX 時代のサービスデザイン Good Service DX時代における"本当に使いやすい"サービス作りの原則15 「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ 融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 101デザインメソッド ―― 革新的な製品・サービスを生む「アイデアの道具箱」 脳のしくみとユーザー体験 認知科学者が教えるデザインの成功法則 「ユーザーフレンドリー」全史 世界と人間を変えてきた「使いやすいモノ」の法則 カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで コンヴィヴィアル・テクノロジー 人間とテクノロジーが共に生きる社会へ ラクスのデザイナーにもおすすめ書籍を聞いてみました! 大人気のデザイン書シリーズ けっきょく、よはく。 余白を活かしたデザインレイアウトの本 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 誰のためのデザイン？ さいごに ラク スのデザイナーについて知りたい方は、以下記事をご参考ください！ tech-blog.rakus.co.jp 最初に読んでほしいUI/UX書籍はこれだ! 「UI」「UX」に関連した書籍を抜粋しました。 古い書籍もありますが、体系的に学べたり、そこから新しい気づきがあったりすることもあります。 ノンデザイナーでもわかる UX+理論で作るWebデザイン 川合 俊輔 (著), 大本 あかね (著), 菊池 崇 (監修) 「ノンデザイナーでもわかる」と書籍タイトルにある通り、基礎から考え方、実践まで簡潔にまとめられています。 「UX」を理解することから始まり、UXをビジネスに役立たせる方法を紹介し、WebサイトのUI設計への話を進め、具体的なデザイン手法について解説されています。本書にも書かれていますが、章ごとに内容が区切られているため、読みたいところから進めて行くことも可能です。 ・理論に基づいたデザインが実装可能になる ・人間心理をベースに、デザインの良し悪しを判断することができる ・UX設計からUIデザインにする方法が学べる ・Webでのデザイン思考が身につく まずは基礎から学んでみるのはどうでしょうか。 UI/UXデザインの原則 平石 大祐 (著) 「ユーザー心理/行動に則って考える」ことがUI/UXデザインの第一歩である UI/UXデザイナーに求められるレベルも年々あがってきており、UI、UXの違いを理解すること、ユーザーニーズを正しく理解し、それをUI/UXに落としこむことが重要になる。結果、ビジネスの可能性を高めることにつながることが書かれています。実例も紹介されており、内容としても非常に読みやすいです。 UIデザイン　みんなで考え、 カイゼン する。 栄前田 勝太郎 (著), 河西 紀明 (著), 西田 陽子 (著) UIデザインの業務を体系的に学べます。 「デザインプロセス」そのものをプロジェクトチーム全体で共有しながら開発を進めていく手法の具体的な中身と、どのようにして現場で取り入れていけばよいのかを、事例も交えながら、できるだけわかりやすく伝えています。またUIをデザイナーだけでなく「チームで作り上げる」という視点からも解説されています。デザイナーやエンジニア、UI/UXに興味のある方にとって、誰のための「デザイン」なのか、あらためて考えるきっかけになるかもしれません。 SF映画 で学ぶインタフェースデザイン ア イデア と想像力を鍛え上げるための141のレッスン Nathan Shedroff (著), Christopher Noessel (著), 安藤 幸央 (監修, 翻訳), 赤羽 太郎 (翻訳), 飯塚 重善 (翻訳), 他 2014年刊行の古い書籍です。 SF映画 からインターフェースデザインを学ぶというテーマで書かれています。実際、世の中に登場していなかった、携帯電話やタッチパネルなど映画の世界では10数年以上も前に登場していたりします。 「 スター・トレック 」「 スター・ウォーズ 」「アイアンマン」などを実例として、紹介されています。またインターフェースだけでなく、しっかりと作り込みがされていますので、映画の中で配色も学ぶことができるのではと思います。 書籍を通して、現在の SF映画 を観ると新しい発見があったりするのではないでしょうか。 ほんとに使える「 ユーザビリティ 」 -より良いデザインへのシンプルなアプローチ エリック・ライス (著), 浅野 紀予 (翻訳) 「製品やサービスの ユーザビリティ を向上させ、より良い利用体験を実現するための方法とは」 UXデザインの第一人者であるエリック・ライスさんの書籍です。本書にも書かれていますが、思い出したくもないほどの長いことサービスデザインや製品デザインのプロジェクトの数々に首を突っ込んできたそうです。 「 ユーザビリティ 」とは何かからはじまり、豊富な事例をもとに ユーザビリティ の問題を洗い出し、解決するための手法をまとめた実践的ガイドブックとなっています。各章ごとに10箇条のチェックリスト、おすすめ書籍、キーワードが掲載されていて、2013年刊行ではありますが、実用性の高い内容だと思います。 UI GRAPHICS 成功事例と思想から学ぶ、これからの インターフェイス デザインとUX 安藤剛 (著), 水野勝仁 (著), 萩原俊矢 (著), ドミニク・チェン (著), 菅俊一 (著), 鹿野護 (著), 有馬トモユキ (著), 他 インターフェイス に向き合うデザイナーたちの実践と思考を記録した、2015年刊行の新版です。世界の成功実例と、この領域に携わる研究者および実践者の知見を得ることができます。本書は、2018年刊行ですが、僕自身は振り返る場として読んでいたりします。UI/UXデザイナーは、常に世の中のデザインとふれていることが重要だとあらためて実感できると思います。 スクリーンショット など写真が多数掲載されてますので、アプリケーションの時代ごとの配色なんかも気づきがあるかと思います。 UXデザインの教科書 安藤 昌也 (著) 「ユーザーエクス ペリエ ンス(UX)」とは何か。 「ユーザー体験(UX)」を軸とし「UXデザイン」について、1.概要、2.基礎知識、3.プロセス、4.手法と体系的に学んでいくことができます。また教科書というタイトル通り、様々な専門用語の基礎知識から、魅力的な製品・サービスをデザインするための流れとその手法がしっかりと書かれています。人に説明するときにも、内容が活用できたりします。 ・UXデザインをはじめたい人 ・UXデザインに悩んでいる人 ・UXデザインを極めたい人 UXデザインの法則 ―最高のプロダクトとサービスを支える心理学 Jon Yablonski (著), 相島 雅樹 (翻訳), 磯谷 拓也 (翻訳), 反中 望 (翻訳), 松村 草也 (翻訳) 「なぜこのデザインがいいのか?」 著者Jon YablonskiさんがUXデザインと交差する心理学の法則をまとめたウェブサイト「Laws of UX」を元に構成されています。 「意思決定にかかる時間は選択肢の数と複雑さで決まる」、「タッチターゲットに至るまでの時間はターゲットの大きさと近さで決まる」などの10の法則を、各章において、ポイント、概要、起源、事例、結論にまとめて紹介されています。なるほどと思う法則や考え方など事例とともに解説されており、読みやすいです。面白くてあっという間に読み終わると思います。僕はそうでした。 UX戦略 ―ユーザー体験から考えるプロダクト作り Jaime Levy (著), 安藤 幸央 (監修), 長尾 高弘 (翻訳) 本書は、企業戦略としてユーザー体験の価値向上を取り入れ、プロダクトを成功へと導く「UX戦略」についての解説書となります。 UX戦略の考え方にもとづき 潜在的 顧客、競合他社製品、バリュープロポジション(提供価値の創造)といった要素の分析や評価を行い、革新的ユーザー体験を持つプロダクトを作り出す手法について、著者の豊富な経験から実例を使って解説されています。デザインとビジネス戦略を起点とし、何をしていく必要があるか学べると思います。 UXはデザイナーだけでなく、製品開発に関わる全職種のメンバーが考えるべきと書かれており、どちらかというとマネージャーやサービスをリードする方に読んでもらいたい書籍になります。 インタフェースデザインのお約束 ―優れたUXを実現するための101のルール Will Grant (著), 武舎 広幸 (翻訳), 武舎 るみ (翻訳) 「優れたUXを実現するための101のルール」 本書では、デジタル製品のデザインに役立つ広範な指針がまとめられています。 製品の ユーザビリティ や性能を高める上で必須かつ基本のツボをマスターすれば時間を節約し 顧客満足度 をアップできるテクニックがコンパクトなルールとして紹介されています。説明もわかりやすく、読みやすいと思います。 タイポグラフィ 、コン トロール 、カスタマージャーニー、各種要素の統一、UX全般に関わるプ ラク ティスに分類されているのでリファレンス的に読むことも可能です。ユーザーエクス ペリエ ンスを向上させるための指針を学んでいけます。 はじめてのUXリサーチ ユーザーとともに価値あるサービスを作り続けるために 松薗 美帆 (著), 草野 孔希 (著) 弊社にはまだありませんが、職種として「UXリサーチャー」を採用している企業を最近よく見かけると思います。 そもそも「UXリサーチ」とは何をしているのでしょうか。本書では、現役リサーチャーの方が、解説してくれています。適度に図やイラスト、写真なども入っていて、すごく読みやすいです。 「UXリサーチ」に興味がある方、何から始めたらいいか悩んでいる方にお勧めです。 UXライティングの教科書 ユーザーの心をひきつけるマイクロコピーの書き方 仲野 佑希 (監修), キネレット・イフラ (その他), 郷司 陽子 (翻訳) 「マイクロコピー」を知っていますか。 みなさんが目にする、送信フォーム上のボタン、登録フォーム、エラーメッセージなどに表示される1行のテキストのことを指しています。 本書を読むことで、たった1行のマイクロコピーがユーザーの行動に影響することを理解し、どのように書くべきか、どこに配置するべきか学べると思います。 あわせて読んでほしい書籍はこれだ! より人を理解すること、心理学や行動から学べる書籍となります。 バグトリデザイン 事例で学ぶ「行為のデザイン」思考 村田 智明 (著) 「人の行為に注目すればあるべきデザインが見えてくる」 この本を読んだとき、衝撃を受けました。ものすごく整理されており、学びがたくさんあります。人の行為を、時間を追って観察していけば、それを妨げるもの、それが「バグ」。 6つのバクとして定義されており、非効率、迷い、矛盾、負環、心理、誤認で分類されています。それぞれのバグについて、事例をもとに解説されています。「行為のデザイン」のワークショップの ケーススタディ も紹介されており、進め方も記述されています。 人間中心設計入門 (HCDライブラリー) 山崎 和彦 (著), 松原 幸行 (著), 竹内 公啓 (著), 黒須 正明 (編集), 八木 大彦 (編集) 「人間中心設計(HCD)」として初めて刊行された入門書になります。 人間中心設計とは、 ユーザビリティ 、ユーザエクス ペリエ ンス(UX)、デザイン思考の共通の基盤となる考え方です。 本書は、節が見開きで構成されており、図や表が多数配置されていて、初めての方にとっても非常にわかりやすいと思います。シリーズで出版されています。 インタフェースデザインの心理学 第2版 ―ウェブやアプリに新たな視点をもたらす100の指針 Susan Weinschenk (著), 武舎 広幸 (翻訳), 武舎 るみ (翻訳), 阿部 和也 (翻訳) 行動心理学者 スーザン・ワ インチェ ンクさんが2012年に刊行された書籍の改定版です。 人はどう見るのか、人はどう読むのか、人はどう記憶するのか、人はどう考えるのか、人はどう注目するかなど、全10章にわかれて解説されています。科学的な研究から導き出された、100の指針を例とともに紹介されています。デザイナーだけでなく、企画やエンジニアの方にもおすすめの本です。 行動を変えるデザイン ―心理学と 行動経済学 をプロダクトデザインに活用する Stephen Wendel (著), 武山 政直 (監修), 相島 雅樹 (翻訳), 反中 望 (翻訳), 松村 草也 (翻訳) 本書は、 行動経済学 と心理学をもとに、人々の行動、日常習慣を変える「行動変容」を促すプロダクトをデザインしていくための書籍です。実践的な知識や視点を学ぶことができます。行動には、あらかじめ5つのことが直前に生じています。ユーザーの行動が実行されるために通過しないといけない5つのステージ「キュー、反応、評価、アビリティ、タイミング」があり、「CREATEアクションファネル」として紹介されています。このアクションファネルは、どこで人々が離脱したのか把握することができます。デザイナーだけでなく、サービスや製品開発に携わる方も必見です。 ビジネスデザインのための 行動経済学 ノート バイアスとナッジでユーザーの心理と行動をデザインする 中島 亮太郎 (著) 「 行動経済学 の本ですが、むずかしい専門書ではありません。」 と書かれている通り、デザイナー視点で図解されていたり、最初から要約が掲載されており、非常にわかりやすいと思います。 テーマとしては「 行動経済学 をビジネスデザインに活用すること」 行動経済学 の理論を知るだけでなく、新しいサービスやプロダクトの開発に活用することが目的と書かれています。 ・個別の理論ではなく全体構成で仕組みを理解できる ・図で多く用いることで理論がパッと見てわかる ・ 社会心理学 やデザインなどの観点も織り交ぜている ・商品やサービスなどへの活用方法に言及している ・実際のビジネスを想像しながら読むことで楽しく学べる デザインリサーチの教科書 木浦幹雄 (著) 僕自身、「デザインリサーチャー」という職種があることをこの書籍を読むまで知りませんでした。 本書では、「デザインリサーチ」の入門書として、「1章.デザインのトレンド」「2章.デザインリサーチの概要」「3章.デザインリサーチのプロジェクトの進め方」「4章.デザインリサーチの導入・運用」の構成で紹介されています。 読み進めていくことで、デザインリサーチの重要性が理解できると思います。 新しいプロダクトをつくられる方、既存プロダクトを改善を検討されている方、おすすめです。 未来ビジネス図解 これからのデザイン思考 小山田 那由他 (著) 「デザイン思考」とは何か。 そもそも「デザイン」とは何かからはじまり、プロセス、様々な領域の製品・サービスの ケーススタディ ーが掲載されており、事例を通してデザイン思考の実践に役立つ内容を学んでいけます。また、イラストなども豊富で非常にわかりやすくまとめられています。 はじめてのカスタマージャーニーマップワークショップ「顧客視点」で考えるビジネスの課題と可能性 加藤 希尊 (著) 「顧客はどのような体験をし、何を感じているのか?」 顧客視点で始め、自社視点で今の状況を見直し、改善していく。「カスタマージャーニーマップ」の有効性、マップを作成するためのワークショップの方法、まとめ方など解説されています。活用事例も掲載されていてお勧めです。サービスに携わるチームでワークショップを展開することで、チーム内の意識統一やコミュニケーション力向上にもつながる可能性大です。 できたら読んでほしい書籍はこれだ! UI/UX視点から少しずれますが、デザインをしていく方はもちろん、サービスに携わる方にぜひ読んでほしい書籍です。 ノンデザイナーズ・デザインブック Robin Williams (著), 米谷 テツヤ (監修, 翻訳), 小原 司 (監修, 翻訳), 吉川 典秀 (翻訳) 2004年刊行から、第4版まで刊行されているロングセラーの書籍です。 良いデザインの作品に共通している「4つの基本原則」が紹介されています。 読みやすい、伝わる、わかりやすいなど、デザインの見た目をよくしていくためにはどんな点に気をつけるべきか学べます。 デザイナーではない方にも、おすすめの基本となる一冊です。 なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 筒井 美希 (著) デザインに関するものごとを「目で見て楽しめる」形にまとめられた書籍となります。文字組み、言葉、文章、色、写真、グラフ・チャートなど参考事例とともに紹介されています。デザインを良くするヒントが、タイトル通り目で見て学んでいけます。テザイン本ですが、UIデザインにも活用できる学びがあると思います。デザイナーだけでなく、デザインに興味のある人にもおすすめです。 DX 時代のサービスデザイン 廣田章光 (著, 編集), 布施匡章 (著, 編集), 瀨良兼司 (著), 井登 友一 (著), 仙波 真二 (著), 宗平 順己 (著), 山縣 正幸 (著) 本書にも書かれていますが、DXという言葉を目にする機会が増えていると思います。DXとは「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念だそうです。このDX時代に、サービスを受ける人の体験と感情の価値を最大化するためにはどうしたらいいのか。サービスデザインを通して、基礎、顧客理解、事業創造など順序だてて学んでいけると思います。 Good Service DX時代における"本当に使いやすい"サービス作りの原則15 ルー・ダウン (著), ヤナガワ智予 (翻訳) 「サービスとは何か?」 本書は、イギリス政府でデジタル改革を推し進めてきた著者が教える、デジタル・トランスフォーメーション(DX)時代のサービスデザイン入門です。 DX時代における「本当に使いやすい」サービス作りについて15の原則でまとめられています。あらゆるサービスに関わる方にぜひ読んでいただきたい本になります。 「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ 玉樹 真一郎 (著) 「あらゆる人の心を動かす方法」 任天堂 で Wii というゲーム機の企画を担当されていた玉樹真一郎さんが書かれた書籍になります。当時「ゲームはどうやって心を動かしているのか?」について議論・分析・研究を重ね、学び、商品企画に活かしていたそうです。 本書では、1.「つい」やりたくさせてしまう、2.「つい」熱中させてしまう、3.「つい」誰かに言いたくさせてしまう、という3つの手法について体系的に紹介されています。誰もが遊んだことのあるあのゲームから解説されて読み進めていくのも楽しいと思います。 融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 渡邊恵太 (著) 「世界が変わったのだから、デザインも変わらなくてはならない」 2015年刊行の書籍ですが、今読んでも発見があると思います。 テク ノロ ジー の進歩により、ますます変容する世界を捉え、デザインしていくためには? これからのものづくりのための最重要キーワード「自己帰属感」を軸に、情報を中心とした設計の発想手法を解き明かす。UXやIoTの本質を掴みたい人に向けて書かれている本です。 101デザインメソッド ―― 革新的な製品・サービスを生む「ア イデア の道具箱」 ヴィジェイ・クーマー (著), Vijay Kumar (著), 渡部 典子 (翻訳) 本書では、 イノベーション のプロセスを7つのモードにわけています。 「1.目的を見出す、2.コンテクストを知る、3.人々を知る、4. インサイト をまとめる、5.コンセプトを探求する、6.解決策を練る、7.製品・サービスを実現する」 各モードごとに多数のメソッドが紹介されています。プロジェクトを進めるにあたり、チームや仲間と取り組むことで、意識統一や振り返ることなど、活用できそうな内容だと思います。UI/UXデザイナー以外でもおすすめな一冊です。 脳のしくみとユーザー体験 認知科学 者が教えるデザインの成功法則 ジョン・ウェイレン (著), 高崎拓哉 (翻訳) ユーザー体験は、「脳内」で起きている。脳の6つの認知プロセスを知ることで、ユーザーの心をつかむことができ、最高の体験をデザインしていくことができる。 本書では、人の体験を構成する要素「シックス・マインド(視野・関心/記憶/感情/意思決定/言語/空間認識)」を理解し、顧客のニーズや視点をより正確に特定できるようになるための方法が解説されています。その知識を製品やサービスのデザインに応用する方法を学ぶ実践書となります。 「ユーザーフレンドリー」全史 世界と人間を変えてきた「使いやすいモノ」の法則 クリフ・クアン (著), ロバート・ファブ リカント (著), 尼丁 千津子 (翻訳) 「ユーザーフレンドリー」とは、使いやすいこと、わかりやすいこと、扱いやすいこと。経験の浅いユーザーにとって使いやすい、わかりやすいこと。ユーザーのニーズを念頭に置いてデザインされたもの。 コンピューターが登場し、インターネットが普及しはじめ、誰もが情報を取得できるようになり、現代だと、 スマートフォン が登場し、人々の生活をさらに一変させたと思われます。「ユーザフレンドリー」が社会に浸透してきた歴史から、世界と人間を変えてきた「使いやすいモノ」の法則を学んでいけます。 カイゼン ・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 市谷 聡啓 (著), 新井 剛 (著) 本書は、ソフトウェア開発に携わる人を対象として書かれているのですが、チームとして活動していこうとしている方、チームの取り組みで悩まれている方などにとっても気づきのある一冊だと思います。 アジャイル をこれから始める人などにもおすすめです。 コンヴィヴィアル・テク ノロ ジー 人間とテク ノロ ジー が共に生きる社会へ 緒方壽人 (著) 「コンヴィヴィアリティ」 思想家イヴァン・ イリイチ が提唱した概念を足がかりに、これからの人間とテク ノロ ジー のあり方について紹介されています。人間は道具をつかっているつもりで、実は道具に使われていてと冒頭に書かれているのですが、確かに、誰もが スマートフォン をもつ世の中となり、 スマートフォン をさわっていない日はない気がします。第3章「人間とデザイン」でデザインについてふれられています。あらためて考えさせられることがあると思います。 ラク スのデザイナーにもおすすめ書籍を聞いてみました! 以下、 ラク スのデザイナー達が選んだ「おすすめの書籍」です。 前述にてご紹介した書籍も何冊かあるかと思います。 ランキング概要 手法：任意アンケート（ ヒアリ ングシート）　※複数回答可 対象： ラク スのデザイン組織メンバー 有効回答数：24名 ランキング内容：投票数2票以上の技術書 順位 書籍名 投票数 1 なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉 8票 2 けっきょく、よはく。 余白を活かしたデザインレイアウトの本 6票 3 オブジェクト指向 UIデザイン──使いやすいソフトウェアの原理 5票 4 ノンデザイナーズ・デザインブック 2票 4 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 2票 4 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 2票 4 誰のためのデザイン？ 2票 『なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉』と『ノンデザイナーズ・デザインブック』は 私の方でも紹介させていただきましたので、それ以外の書籍を簡単にご紹介させていただきます。 大人気のデザイン書シリーズ けっきょく、よはく。 余白を活かしたデザインレイアウトの本 ingectar-e (著) どんなデザインにも余白があると思います。余白をうまく使いこなすことで、情報の整理につながり、結果、洗練されたデザインとなる。事例を紹介しつつ、色、フォントなど学べることがあると思います。 あたらしい、あしらい。 あしらいに着目したデザインレイアウトの本 ingectar-e (著) 「いいデザインはあしらいがていねいなんだ!」人気シリーズの第3弾です。「あしらい」とは「装飾」「ディテール(細部)」のこと。NG例から問題点を洗い出し、OK例を提案し、どんな修正を行ったかについて解説されています。 ほんとに、フォント。　フォントを活かしたデザインレイアウトの本 ingectar-e (著) 人気シリーズの第2弾です。いろんなフォントがあり、どれを選べば、どう使えばいいのか。 「センス」がとわれます。たくさんの使用例とともに、センスを磨いていけると思います。 オブジェクト指向 UIデザイン──使いやすいソフトウェアの原理 ソシオメディア株式会社 (著), 上野 学 (著, 監修), 藤井 幸多 (著) 「 銀の弾丸 、OOUI。」かなり インパク トのある表紙です。 オブジェクト指向 ユーザーインターフェース (OOUI)とは、目当てとなるオブジェクトを起点としてUIを設計することになります。対象を選んでから行動におこす。実践演習も紹介されているので、学びながら理解していけると思います。 誰のためのデザイン？ D.A.ノーマン (著) 初版刊行からロングセラーとなっている書籍です。冒頭にある「どんな新しいテク ノロ ジー が出現するか予測できる人もいない、だが確実に予測できるのは、本書に述べるデザインの原則は変わらず残るということである。」デザイナーだけでなく、製品やサービスに携わる方に読んでほしい一冊です。 さいごに いかがでしたか。気になる書籍は見つかりましたか。 少しでも興味のある本があれば、ぜひ、手にとって読んでいただけると幸いです。 あなたにとって最良の本との出会いがあることを祈っております。 また、 ラク スでは、現在、UIデザイナー、 Webデザイナー を募集中となります。 書籍の購入費補助もあります。 ご興味ある方いましたら、ぜひ、下記採用サイトから、ご連絡ください。 尚、カジュアル面談も大歓迎です。UI/UX、デザインについてお話しましょう。お待ちしております。 クリエイティブ課　木村圭 おすすめの技術書を紹介している、以下関連ブログも是非ご確認ください！ tech-blog.rakus.co.jp tech-blog.rakus.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは。 ラク スでインフラを担当しております渡邊(kw21)と申します。 今回はサーバ・アプリケーションの 冗長化 に今なお広く利用されているHA クラスタ ソフト「Pacemaker」について、 特にActive/Standby(1+1)構成 クラスタ で発生しうるスプリットブレインに焦点を当ててご紹介いたします。 はじめに HAクラスタとは？ Pacemakerとは？ クラスタノード間の通信とインターコネクト スプリットブレインとは？ クォーラム(定足数)とは？ 2ノード構成でのクォーラムの考え方とPacemakerでスプリットブレインを防ぐ仕組み スプリットブレイン発生後の対処 Pacemaker まとめ 参考 HA クラスタ とは？ HA クラスタ とは「複数のコンピュータをつなげ、全体で1つのコンピュータのように振る舞わせることでシステム全体の 稼働率 を高める技術」のことです( LINUX-HA JAPAN より引用)。HAは「High Availability」の略で日本語で高可用 クラスタ とも呼ばれます。 様々な開発コミュティ及びベンダーからHA クラスタ ソフトが提供されており、古いものでは30年ほど前から存在するパッケージもあります。 昨今では、 パブリッククラウド やコンテナ オーケストレーション を利用したシステム構築が主流になりつつありますが、オンプレミスな環境で冗長システムを構築する際の選択肢としてはHA クラスタ もまだまだ有力な候補のひとつです。 ＜HA クラスタ を利用して可用性を高めた例＞ 下図は2つのサーバでActive/Standby(1+1)構成 クラスタ を実装した例です。 クラスタ に組み込んだサーバは クラスタ ノード と呼ばれ、本記事内では1号機をノード#1、2号機をノード#2と表記しています。 通常運用時はActiveノードであるノード#1へクライアントからのアクセスを受けます。 ノード#1が何らかの障害でダウンした場合、それを検知した クラスタ ソフトがノード#2をStandbyからActiveに切り替え、ノード#2側でクライアントからのアクセスを受けられるようにします。　　 このように、Activeノードがノード#1からノード#2に切り替わることを フェイルオーバー と呼びます。　　 HA クラスタ ソフトでシステムを 冗長化 するとフェイルオーバーにより障害発生時のダウンタイムを最小化させることができます。　　 本記事内では主にActive/Standby(1+1)構成 クラスタ を取り上げていますが、その他にも両現用として稼働させるActive/Active(1+1)構成や、Standbyサーバを複数用意したN+1構成など、ソフトや目的によって様々なシステム構成を選択することができます。 Pacemakerとは？ Pacemaker は OSS の代表的なHA クラスタ ソフトのひとつで、2022年2月現在は ClusterLabs というコミュニティが開発提供しています。 厳密にはPacemakerとはHA クラスタ ソフトを構成する コンポーネント の一つであるリソース制御機能部分の名前のことなのですが、Corosyncなどの他 コンポーネント を含めた クラスタ ソフト全体のことを指して便宜的にPacemakerと呼ばれることもあります。 HA クラスタ の コンポーネント としてPacemakerと組み合わせてよく利用される Corosync は主に クラスタ 制御機能を担っており、 クラスタ 内のメッセージングやクォーラム機能を提供しています。クォーラムについては後ほど詳しく紹介します。 Pacemakerで管理する対象のアプリケーションや IPアドレス のことを リソース と呼び、Active/Standby(1+1)構成 クラスタ ではActiveになったノードでリソースが起動します。 Pacemakerには様々なアプリケーションをPacemakerリソースとして扱うためのリソースエージェント(RA)という コンポーネント も存在し、例として下記のような種々のアプリケーションをリソース登録することができます。 仮想 IPアドレス ：各 クラスタ ノードのローカル IPアドレス とは別に、Activeノードでのみ有効になる IPアドレス を設定できます。「virtual ip」を略して「vip」とも呼ばれます。 共有ディスク ： クラスタ ノードとは別の NFS サーバなどをリソースとして設定します。Activeノードがを NFS サーバの共有領域をマウントして読み書きを行うことで、フェイルオーバーした際に新たにActiveとなったノードからも引き続き NFS サーバ上のデータを読み書きすることができます。 Webサーバ・DBなどの ミドルウェア ： Apache や PostgreSQL など、アプリケーションとして利用したいsystemdサービスを設定できます。ノードがActiveになると同時にリソースとして該当サービスも起動されます。 Pacemakerは クラスタ ノード上のリソースの起動状態を監視しており、リソース故障を検知すると設定に従ってフェイルオーバーやリソースの再起動・停止などを行います。 リソース故障 とは、Pacemakerで管理されるリソースに何らかの異常が発生したことを指しており、例えば「リソース設定した共有ディスクのサーバがダウンし、マウントできなくなった」「リソース設定した PostgreSQL サービスが停止した」などの事象がこれにあたります。 また、Pacemakerの クラスタ やリソースについての設定は pcs というツールを利用します。 pcsはコマンドやWebUIでPacemaker クラスタ を管理するための コンポーネント で、各種設定及びPacemaker クラスタ の起動停止や状態確認の機能も提供しています。 クラスタ ノード間の通信とインターコネクト 各 クラスタ ノードの死活監視・リソース状態監視を行うために、 クラスタ に所属する各ノードは同一ネットワーク上で疎通可能な状態である必要があります。 クラスタ ノード間を通信させるLANのことを インターコネクト (または系間LANやハートビートなど)と呼びます。 構築するサーバやネットワークの設計方針にもよりますが、インターコネクト用のVLANを作成したり通常のLANと兼用させたりする場合もあれば、1+1構成の両サーバをLANケーブルで直接繋いで疎通させるような場合もあります。 ノード間の死活監視がインターコネクトを通して行われている以上、インターコネクトが疎通できなくなることは各ノードにとって対向ノードがダウンしたこととほぼ同義であり、 インターコネクトはHA クラスタ の安定稼働における大変重要な要素 となっています。 例えば、インターコネクトに何らかの異常が発生し クラスタ ノード間の通信が切れた場合、下図のようにノード#1とノード#2はそれぞれお互いのノードの疎通が取れなくなるため、「ノード#2(または#1)がダウンした」という判定になります。 インターコネクトが単一の障害ポイントとならないよう、設計時によく考慮する必要があります。 Pacemaker/Corosyncの クラスタ の場合はcorosync.confで各ノードで利用するインターコネクトの経路を設定することができ、複数の経路を指定することでインターコネクトを 冗長化 することもできます。 Pacemaker クラスタ でノード間の通信が切れてしまった場合に各ノードはどういった挙動をとるのか、次の項で説明します。 スプリットブレインとは？ スプリットブレイン (split brain)とは、インターコネクトが切れるなどの原因でノード間の疎通が取れなくなった際にStandbyノードがActiveに切り替わることにより、同一環境内に本来複数存在してはならないActiveノードが複数発生してしまう状態のことです。 設定されているリソースの内容にもよってはデータ破損やIP競合が発生し、重大な事故に繋がる可能性があります。 下図の例ではActive/Standby(1+1)構成のPacemaker クラスタ でスプリットブレインが発生し、ノード#1とノード#2両方がActiveとなり、リソースが両方のノードで起動してしまった例です。 本来1ノードからの書き込みしか無い設計だったディスクに対し、複数のノードからの書き込みが発生しデータ破損・ロストが発生してしまう可能性があります。 私自身が経験した例だと、Active/Standby(1+1)構成でノード#1の NIC 故障が発生し、一時的にインターコネクトが不安定になった結果、ノード#1がActiveのままノード#2もStandbyからActiveに切り替わってしまったことがありました。 インターコネクト切断時にスプリットブレインが発生するか否かに関わる要素として、次の項ではPacemakerにおいてクォーラムという考え方で各ノードの挙動を制御する設定について紹介します。 クォーラム(定足数)とは？ HA クラスタ における クォーラム (quorum・定足数)とは、一言で表すと「 HA クラスタ として動作できる権利を得るための、自ノードが通信できるノード数の最低数 」のことです。 分かりづらいため、下図で3台構成の クラスタ での例を示します。 クラスタ に所属するノード#1・#2・#3のうち、インターコネクトの異常等によりノード#1のみ疎通できなくなったとします。 この状態から「ノード#1」と「ノード#2・#3」のどちらがHA クラスタ として稼働を継続できるか、投票システムのような形で判定されます。 各ノードは「自分を含めいくつのノードと疎通ができるか」という数を認識しており、図の場合、ノード#1はノード#2・#3とは疎通できないため自分自身のみの投票数で 1 。ノード#2・#3はそれぞれ自分自身とお互いは疎通できるため、投票数はそれぞれ 2 。 通常、3ノードの 過半数 である"2"がクォーラム(定足数)として設定されていることが多いため、クォーラムを獲得した「ノード#2・#3」側の クラスタ パーティション がHA クラスタ として稼働を継続します。 その後、設定に応じてノード#1は クラスタ から切り離され、ノード#2または#3がActiveとなってリソースが起動されます。 では、2ノードで構成されるActive/Standby(1+1)構成 クラスタ の場合はどのように判定されるでしょうか。 2ノード構成でのクォーラムの考え方とPacemakerでスプリットブレインを防ぐ仕組み 2ノード構成の クラスタ の場合、そもそも 過半数 という図式が成り立たないため、ノード#1と#2が切り離されたとしてもどちらもクォーラムを獲得することはできません。 Pacemakerにはクォーラム無しとなった場合の挙動を設定できる「 no-quorum-policy 」という クラスタ プロパティがあります。 no-quorum-policy では下記の4つのポリシーを選択することができます。 ignore 　：全リソースの管理を続行(=リソース起動状態にする) freeze 　：何もしない(動いてるものは動いたまま、止まってたものは止まったまま) stop (デフォルト)　：全リソースを停止する suicide 　：影響を受ける クラスタ ー パーティション 内の全ノードを排他処理(フェンシング)する no-quorum-policy を ignore 以外にしておけばインターコネクト切断時にもリソースが複数ノードで重複して起動する心配は無いのですが、しかしそれではActive/Standby(1+1)構成で突発的にActiveノードがダウンした場合にも同じ挙動が適用されてしまい、Standbyが機能しなくなってしまいます。 PacemakerでActive/Standby(1+1)構成を取る場合、Activeノードがダウンした際にフェイルオーバーして新たにStandbyノード側でリソース起動させるためには、 no-quorum-policy を ignore に設定しておく必要があります。 一方、 no-quorum-policy を ignore に設定した場合、前項で紹介したようなインターコネクト断が発生した際には ノード#1　：クォーラム獲得無しのためリソースは起動状態のまま ノード#2　：クォーラム獲得無しのためリソースは停止状態から起動状態へ という挙動となります。 したがって、PacemakerでActive/Standby(1+1)構成を実装する場合、障害のきっかけ次第ではスプリットブレインが発生し得る構成となります。 その上で、Pacemakerにはスプリットブレインを回避するための仕組みが複数存在します。 ＜スプリットブレインの発生を防ぐ仕組み＞ STONITH 　：制御 不能 となったノードを強制的に停止や再起動(フェンシング)させる機能です。各ノードの電源制御デ バイス へのアクセスが必要です。 SFEX 　：Activeノードが共有ディスク上にフラグを作成することで 排他制御 を行うリソースです。共有ディスクを使う構成で利用可能。 VIPcheck 　：インターコネクトは別の経路で仮想 IPアドレス の割当て状態を確認することで 排他制御 を行うリソースです。仮想 IPアドレス を使う構成で利用可能。 上記の 排他制御 を利用せずスプリットブレインを防ぐことができなかった場合、システムとしては障害となる可能性が非常に高いと考えられます。 次の項では、スプリットブレインが発生してしまった後の対処について考えてみました。 スプリットブレイン発生後の対処 PacemakerのActive/Standby構成で、スプリットブレインが発生してしまったらどう対処すべきでしょうか。 ここではパターンとして ①：一時的に クラスタ ノード間通信が切断され両Activeとなってしまったが、その後再び クラスタ ノード間通信ができるようになった場合 ②：完全にノード間の疎通が切れ、両ノードがActiveで稼働したままとなった場合 の2つについて考えてみます。 ＜①：両Activeとなった後、再び クラスタ ノード間通信ができるようになった場合＞ ノード間通信が復活すると、各ノードは一時的に クラスタ から切り離されていたお互いのノードを再び クラスタ に組み込もうとします。 Pacemaker クラスタ への組み込みが始まりノード間の情報連携が再開すると、リソースが両方のノードで起動されてしまっていることが認識されます。 実際に弊社検証環境のPacemaker Active/Standby構成 クラスタ で再現させてみたところ、Pacemakerのログに以下のようなメッセージが出力されました。 (native_create_actions) 　error: Resource virtual_ip is active on 2 nodes (attempting recovery) (native_create_actions) 　notice: See https://wiki.clusterlabs.org/wiki/FAQ#Resource_is_Too_Active for more information リソースとして登録していたvirtual_ipが2ノードでアクティブとなっているので復旧を試みます、というメッセージです。 Pacemakerではリソースが複数のノードでアクティブとなった場合の挙動を「 multiple-active 」というオプションで設定することができます。 multiple-active はデフォルトでは「 stop_start 」となっており、いったんすべてのノードでリソースを停止させた後、片方のノードで起動するという挙動となります。 つまり、一度スプリットブレインが発生してしまっても瞬時にノード間通信が復活した場合は自動でリソースが再起動し復旧するという機能が備わっています。 ただし、一時的とはいえ両ノードでリソースが起動してしまうことには変わらないため、登録しているリソースごとにクライアントやデータへの影響を考える必要があります。 また、登録しているリソースが再起動 不能 なタイプだと両ノードでリソース故障状態(起動できないor停止できない)となり、STONITHによるノード強制停止や手動復旧が必須となります。 ＜②完全にノード間の疎通が切れ、両ノードがActiveで稼働したままとなった場合＞ サーバやネットワーク構成・インターコネクトの接続方式にもよりますが、スプリットブレイン対策を何もしなかった場合に起こりえるパターンです。 両ノードがActiveのまま稼働し続けているということは、本来複数ノードで起動してはならないリソースが複数ノード上でActiveとなってしまっているということです。 そして、場合によってはリソースとして設定している共有ディスクや IPアドレス 競合等が故障として判定されない限り、異常な状態でクライアントからのアクセスやデータ書き込みをし続けてしまっているかもしれません。 ハードウェアとしての故障はもちろん、本来書き込みされてはならない場所・タイミングでデータが書き込まれるということは、データ不整合やロストといった重大なインシデントに発展する可能性が非常に高いです。 慎重にサービス停止を検討し、システム全体の通信の流れやデータの書き込み方式を基にデータを精査することをおすすめいたします。 ※筆者は未経験です。 Pacemaker まとめ 手軽に冗長構成環境を構築できるPacemakerですが、障害発生時にどのように動作させたいか、またはどのように想定外な異常を防ぐか慎重に検討すべきポイントがいくつも存在します。 本記事でご紹介したもの以外にも、より柔軟にPacemaker クラスタ を制御する設定項目が多数存在します。 開発コミュニティであるClusterLabsのドキュメントや、日本でPacemakerを含む Linux HA クラスタ を普及させている Linux -HA Japanの資料をよく参照し、事故の無い安定したHA クラスタ を楽しみましょう。 参考 ClusterLabs： https://clusterlabs.org/ LINUX -HA JAPAN： https://linux-ha.osdn.jp/wp/manual/pacemaker_outline 過去の セミ ナー資料も多数公開されており、大変参考になります。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 皆様こんにちは。 インフラ開発課でインフラエンジニアをしているsnnmrです。 ラク スで働きだしてかれこれ数年、その中でも比較的使用頻度の高い iptables について改めてまとめてみました。 はじめに iptablesとは Netfilterとは iptables 書式 よく使うオプションとチェイン filterテーブル natテーブル mangleテーブル rawテーブル conntrackエントリについて iptables まとめ Linux の理解をより深めたい方へ以下関連おすすめブログ ・ ls コマンド 【使い方 まとめ】 ・ find コマンド 【使い方 まとめ】 ・ iptables まとめ【Linux ファイアウォール】 ・ sed コマンド【使い方 まとめ】 ・ vi コマンド【使い方まとめ】 ・ Linuxのファイル操作でよく使うLinuxコマンド ・ 初心者のためのawkコマンド ・ 実務で使える！基本的なシェル（Linux）コマンドの話 ～forとsed～ ・ 【Linux】今振り返りたい、プロセスって何？ iptables とは まず、 iptables - Wikipedia で確認してみます。 iptables は、 Linux に実装されたパケットフィルタリングおよびネットワークアドレス変換 (NAT) 機能であるNetfilter（複数のNetfilterモジュールとして実装されている）の設定を操作するコマンドのこと。Netfilterは、いわゆる ファイアウォール やルータとしての役割を果たす。 IPv4 用の実装が iptables で、 IPv6 用の実装が ip6tables である。 Linux カーネル 2.4以降では、Netfilterというパケット処理のための フレームワーク をもっており、これの設定を操作するツールが iptables である。 　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　引用元： https://ja.wikipedia.org/wiki/Iptables iptables は、netfilterを操作するためのものです。 フィルタリングやNATを行っているのはkernelモジュールのnetfilterとのことです。 Netfilterとは Netfilterについても調べてみましょう。 The netfilter project enables packet filtering, network address [and port] translation (NA[P]T), packet logging, userspace packet queueing and other packet mangling. The netfilter hooks are a framework inside the Linux kernel that allows kernel modules to register callback functions at different locations of the Linux network stack. The registered callback function is then called back for every packet that traverses the respective hook within the Linux network stack. 　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　引用元： https://netfilter.org/index.html ( Google翻訳 ) netfilterプロジェクトは、パケットフィルタリング、ネットワークアドレス[およびポート]変換（NA [P] T）、パケットロギング、ユーザースペースパケットキューイング、およびその他のパケットマングリングを可能にします。 netfilterフックは、 カーネル モジュールが Linux ネットワークスタックのさまざまな場所にコールバック関数を登録できるようにする Linux カーネル 内の フレームワーク です。登録されたコールバック関数は、 Linux ネットワークスタック内のそれぞれのフックを通過するすべてのパケットに対してコールバックされます。 netfilterを使用してパケットフィルタリング、NAT変換等の処理を行う。 更にコールバック関数を使用し、さまざまな場所に処理を組み込めるといったものでしょうか。 弊社のサービスの一部で LVS （ Linux Virtual Server ）を使いL4負荷分散を導入しているんですが、これもNetfilterのコールバック関数を使っています。 iptables 書式 iptables ではパケットを4つのテーブルに分けて処理をします。 iptables のよく使うテーブルとコマンドの例を紹介します。 よく使うオプションとチェイン チェイン 内容 INPUT 入ってくるパケットに対して適用 OUTPUT 出ていくパケットに対して適用 FORWARD 転送パケットに対して適用 PREROUTING ルーティング前に適用 POSTROUTING ルーティング後に適用 オプション 内容 -s (--source) パケットの送信元を指定。特定のIPや範囲を指定 -d (-- destination ) パケットの宛先を指定。※指定方法は↑の「-s」と同じ -p (--protocol) パケットの プロトコル （ tcp 、 udp 、icmp、all） -i (--in-interface) パケットを受信するインターフェース名 -o (--out-interface) 送信先 インターフェース名 -j (--jump) ターゲット（ACCEPT、 DROP 、 REJECT 等）を指定（LOGでログをとることが可能） filterテーブル filterテーブルはパケットの出入りを制御することができるため、サーバのメンテナンスしたりするときにもよく使うやつですね。 filterテーブルでよく使うチェインは「INPUT（入ってくるパケットに対して適用）」とか「OUTPUT（出ていくパケットに対して適用）」です。 その他にも「FORWARD（転送パケットに対しての適用）」などがあります。 [ root@localhost ~ ] # iptables -t filter -I INPUT -p tcp -s xxx.xxx.xxx.xxx --dport 80 -j DROP これは「-s」で指定した接続元 IPアドレス で80番ポート宛のパケットを DROP （破棄）するといった設定になります。 「-t」でテーブルの指定をしない場合は、filterテーブルが指定されます。 natテーブル NAT（Network Address Translation）テーブルは、パケットの中身を書き換えることが可能です。 natテーブルで使用できるチェインは 「PREROUTING（ルーティング前に適用）」 「OUTPUT（出ていくパケットに対して適用）」 「POSTROUTING（ルーティング後に適用）」 があります。 [ root@localhost ~ ] # iptables -t nat -A POSTROUTING -o eth0 -s 192 . 168 . 10 . 10 -j MASQUERADE 上記は、 IPマスカレード の設定例です。 eth1にプライベートネットワーク、eth0に IPマスカレード で使用する グローバルIP が設定されている環境（ルータなど）を想定しています。 [ root@localhost ~ ] # iptables -t nat -A PREROUTING -d 192 . 168 . 10 . 10 -p tcp --dport 25 -j REDIRECT また、上記は「-d」で指定された宛先アドレスの tcp パケットを25番ポートへリダイレクトする設定です。 上述しましたが、弊社ではL4負荷分散を使用しているので、LBサーバ配下のサーバに上記設定を行い、L4で分散されたパケットをこれで処理させていたりします。 mangleテーブル mangleテーブルはパケットのIPヘッダの中で定義されている TOS （Type Of Service）フィールドを書き換えることが可能です。 [ root@localhost ~ ] # iptables -t mangle -A OUTPUT -p tcp --sport 443 -j DSCP --set-dscp 46 上記は、443ポートから出ていくパケットにDSCP値「46」を設定して優先度を上げる例です。 弊社では、一斉メール配信サービスを提供しているため、実際にDSCP値の設定をしており管理画面へのアクセス（ tcp /443）のパケットの優先度を上げてたりします。 rawテーブル rawテーブルはパケットに特定のマークを付け、追跡を除外したりするときに使用します。 書式としては以下のように書き、22番への tcp 通信をト ラッキング しない場合の例です。 [ root@localhost ~ ] # iptables -t raw -I PREROUTING -p tcp --dport 22 -j NOTRACK 今まで全く使ったことが無いので実際にためしてみました。 rawテーブルに設定する前に、 ssh した時のト ラッキング を確認してみます。 ※ ssh 接続元の IPアドレス は「172.20.100.120」です。 [ root@localhost ~ ] # cat /proc/net/nf_conntrack | grep 172 . 20 . 100 . 120 ipv4 2 tcp 6 431996 ESTABLISHED src = 172 . 20 . 100 . 120 dst = 172 . 20 . 100 . 209 sport = 17041 dport = 22 src = 172 . 20 . 100 . 209 dst = 172 . 20 . 100 . 120 sport = 22 dport = 17041 [ ASSURED ] mark = 0 secctx =system_u:object_r:unlabeled_t:s0 zone = 0 use = 2 「172.20.100.120」からの接続が、conntrackエントリにのってESTABLISHされているこがわかります（環境はCentOS8です）。 次にrawテーブルに設定を入れて確認してみます。 [ root@localhost ~ ] # iptables -t raw -I PREROUTING -p tcp --dport 22 -j NOTRACK [ root@localhost ~ ] # cat /proc/net/nf_conntrack | grep 172 . 20 . 100 . 120 ipv4 2 tcp 6 296 ESTABLISHED src = 172 . 20 . 100 . 209 dst = 172 . 20 . 100 . 120 sport = 22 dport = 17045 [ UNREPLIED ] src = 172 . 20 . 100 . 120 dst = 172 . 20 . 100 . 209 sport = 17045 dport = 22 mark = 0 secctx =system_u:object_r:unlabeled_t:s0 zone = 0 use = 2 ESTABLISHEDですが、ステータスが「UNREPLIED」になっています。 conntrack-toolsで確認していても「UNREPLIED」でエントリされたものは数分後DESTROYされました。 特定の通信を ファイアウォール で処理せず、他の機器で処理させるとき等に使うようです。 conntrackエントリについて サーバを運用していると「通信できなくなった」とか「たまに通信できなくなる」といったことが発生することがまれに？あると思います。 そんな時、conntrackにエントリされた通信の状態を見ると調査が捗るかもしれません。（「-j」でログを出すのも有効です） ちなみに、firewalldを起動していなくても iptables コマンドで設定をいれてやれば、モジュールは有効化されます。 [ root@localhost ~ ] # systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded ( /usr/lib/systemd/system/firewalld.service ; disabled ; vendor preset: enabled ) Active: inactive ( dead ) Docs: man:firewalld ( 1 ) [ root@localhost ~ ] # lsmod | grep conntrack xt_conntrack 16384 0 nf_conntrack_netlink 49152 0 nf_conntrack_ipv4 16384 2 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_conntrack 155648 7 xt_conntrack,nf_conntrack_ipv4,nf_nat,ipt_MASQUERADE,nf_nat_ipv4,nf_conntrack_netlink,xt_CT nfnetlink 16384 4 nft_compat,nf_conntrack_netlink,nf_tables libcrc32c 16384 3 nf_conntrack,nf_nat,xfs CentOS8のconntrackエントリの見方については、procの「/proc/net/nf_conntrack」でも確認できますが、onntrack-toolsをインストールすればリアルタイムでも確認できるので便利です。 以前、 tcp の最初のSYNパケットがNEWとして判定されず、INVALIDとして判定される事象が発生しました。 その時もconntrackのエントリを確認して調査することで、比較的早く原因が判明しました。 普段あまりみない部分かとおもいますが、見方を知っておくと良いかもしれません。 ※ちなみにその時は送信元IPとポート、 送信先 IPとポートが同じである過去のセッションが残っていたためINVALIDになっていました。 iptables まとめ iptables をがっつり ファイアウォール として使っているというケースは少ないと思いますが、メンテナンス時に一時的に使用したりするなど使用頻度はそこそこ高いのではないでしょうか。 インフラエンジニアをやっていると「通信できない」みたいな場面に遭遇することはよくあると思います。 基本的に tcpdump 等を使って低レイヤから調査すると思いますが、パケットはきてるっぽいけどなんか通信できない、みたいな場面で iptables やconntrackエントリ周りのことを頭に入れておくと多少幸せになれるかもしれませんので何かの役に立てば幸いです。 最後までお読みいただき有難うございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 ラク スでは、CMでお馴染みとなってきました 楽楽精算 をはじめ、数多くのプロダクトを開発及びご提供させていただいております。 今回はプロダクト開発に携わる「 ラク スのテッ クリード 」の皆様に、 チームでの役割とは？ テッ クリード /リードエンジニアの魅力とは？ 好きな技術、おすすめの技術書とは？ 今後挑戦したいことは？ などなど、ざっくばらんにインタビューさせていただきました！ 今後、テッ クリード /リードエンジニアを目指している方の一助となれば幸いです。 本記事では、 楽楽販売 ・ 楽楽労務 ・ MailDealer の開発組織から3名を紹介したいと思います！ 第ニ開発部 楽楽販売開発課 K.Mさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第二開発部 楽楽労務開発課 N.Oさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第四開発部 メールディーラー・チャットディーラー開発課 K.Yさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 一緒に働きませんか？ 終わりに 開発組織の前編及び、横断部署・インフラ組織につきましては以下ブログをご確認ください！ ● 【インタビュー】 ラク スのテッ クリード /リードエンジニア ～横断部署・インフラ組織編～ tech-blog.rakus.co.jp ● 【インタビュー】 ラク スのテッ クリード /リードエンジニア ～開発組織 前編～ tech-blog.rakus.co.jp 第ニ開発部 楽楽販売開発課 K.Mさん 第ニ開発部 楽楽販売開発課 K.Mさん Q. まずは自己紹介をお願いします 大学では 情報工学 を学び、アルバイトでWeb開発エンジニアをしていました。 中小企業で スマートフォン や VR 案件、VOD等のサーバサイドまで幅広く開発経験積ませて頂き、大手企業で SIer を経験した後に ラク スに入社しました。 今はサーバサイドをメインとしています。 Q. チームでの担当範囲・役割を教えてください 他の方に比べると私は ラク スに来て日が浅いので楽楽販売の開発チームにおいてテッ クリード の役割とは？で答えさせて頂きます。 役割は「開発リーダー」という認識で間違いないですが、リーダーも開発工程全般を担当していますね。 他には他部署からの要望や質問に対して、技術的な回答を適切にわかりやすく伝える窓口となったり、豊富な知識・経験を活かして他の方のサポートに入る事などがあります。　 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 色々ありますが…あえて今回取り上げたいのは柔軟な対応を求められる事です。 ラク スでは毎月多くの人が入社されてきます。 そのため様々な会社で色々な課題解決をしてきた方々が集まってきますし、現在 ラク スが抱えている課題以外にも、まだ表面化していなかった課題や改善点が見つかる事もしばしばあります。 そういった課題を「見つける事」「解決する事」を先頭に立って解決していくのは困難な事もありますが、非常にやりがいがあります。 「常にリーダとして今どうあるべきか？」「何をするべきか？」を考えて動ける、それを求められる現場だなと感じています。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　 Ruby , Python ( PHP じゃないのか！って言われそうですが!汗） ◆情報収集方法 　Web記事（note、 はてなブログ など） Q. おすすめの技術書は何ですか？ 正直お勧めの技術書はありません。 雑誌や記事で最新を知り、肉付けしたい知識の気になる本を読めば良いと思います。 雑誌は 『 WEB+DB PRESS 』がおすすめです。 『 WEB+DB PRESS 』 技術者としての哲学は雑誌には載らない事が多いため、古い本ですが１冊だけ挙げると、『達人 プログラマー 』が良いと思います。 『達人 プログラマー 』 Q. 今後、挑戦したいことはありますか？ 担当の枠を超えているかもしれませんが、部課の垣根を超えた情報の共有、技術交流が盛んな会社作りです。 せっかく優秀な技術者が１社に集まっても部課の垣根を超えないなら５０名以下の中小企業の方が一致団結してより良い物が作れると私は考えています。 インフラだからとかCSだからとか言わずに、知識を幅広く持ち「ニーズ」「費用対効果」色々な側面から物を見て、ベストな提案をみんなで考えていく体制を整えたいです。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください おそらくこれは ラク ス社員ほぼ全員同一意見かと思いますが、「 ラク スの行動指針」が正しくかなと思います。 入社希望の方は是非会社のHPで読んでほしいです。 とは言え私個人の意見に置き換えるなら、リードエンジニア/テッ クリード なんて担当が存在していますが、結局のところ他部署や上下関係に捕らわれずにどんどん意見をぶつけて切磋琢磨していくような人と私は仕事がしたいです。 第二開発部 楽楽 労務 開発課 N.Oさん 第二開発部 楽楽 労務 開発課 N.Oさん Q. まずは自己紹介をお願いします 2013年に ラク スに入社し、いくつかのプロダクト開発に携わった後、現在は楽楽 労務 の開発にサービス立ち上げ初期から関わっているバックエンドエンジニアです。 新米テッ クリード として、担当プロダクトにとらわれない改善施策を推進できないか奮闘中。 Q. チームでの担当範囲・役割を教えてください 仕様策定から実装完了までを幅広くカバーし、重要な意思決定や方針策定を通してチーム開発を支えるイメージでしょうか。 楽楽 労務 では特に次の2つの役割が大きいと感じます。 　 ● ビジネスサイドと協力してプロダクトの優先順位付けや仕様判断をする ● アーキテクチャ や技術選定など内部設計上の技術判断をする 　 社内の他プロダクトに目を向けて情報共有したり、改善提案したりといったことも重要な役割となっています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください プロダクト開発にどっぷり関われることかなと思います。 ラク スではエンジニアの兼任がほとんどないため、自分の担当プロダクトにじっくり取り組むことができ、どのエンジニアも担当プロダクト愛にあふれていると感じます。 長期的な視点で難しい技術選定をしたり、ときには短期的な視点で泥臭い意思決定をしたりと、初めから終わりまで自分たちで責任をもってプロダクトを育てていけるのが、腕の見せ所でもあり、一番の魅力でもあると思います。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　特定技術ではないですが、 リファクタリング や自動テストなどコードを整頓していくのは好きです。 　手動作業を自動化できないか考えるのも、 ピタゴラスイッチ みたいで好きですね。 　そういう意味では、既存の仕組みの カイゼン は好きなのかもしれません。 　長い付き合いの Java が最近悪く言われがちなのはちょっと寂しいです。 ◆情報収集方法 　書籍 Q. おすすめの技術書は何ですか？ ただの プログラマ ではなく、よい プログラマ になることを意識させてくれた1冊 『達人 プログラマー 』 テストに支えられながらコードを書く気持ちよさを教えてくれた1冊 『 テスト駆動開発 』 現場で オブジェクト指向設計 と向き合い続けたエンジニアのこだわりを感じた1冊 『現場で役立つシステム設計の原則』 Q. 今後、挑戦したいことはありますか？ toB 向けのプロダクトということもあり、2〜3ヶ月に1回リリースするという開発スタイルになっていますが、もう少し短い間隔で継続的にリリースし続けられる、小回りのきく開発チーム体制やデプロイプロセスの自動化を進めていきたいですね。 また、 労務 領域のプロダクトは満たすべき法要件などもあるので、こういった機能を人手に頼らず品質担保できる仕組みづくりも考えていきたいと思っています。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 1つのプロダクトに腰を据えてチーム開発を楽しみたい人にオススメです。 様々なフェーズのプロダクトがあるため、必ずしも最新技術や最新ツールばかりを使えるわけではありませんが、そこも引っくるめてプロダクトごとの課題と長く深く向き合える環境だと思います。 また、そういった中でも一緒に何か少しずつ +1 していけるような人とチーム開発したいですね。 第四開発部 メールディーラー・チャットディーラー開発課 K.Yさん 第四開発部 メールディーラー・チャットディーラー開発課 K.Yさん Q. まずは自己紹介をお願いします 2011年に ラク スに中途入社。 現在は自社サービス「メールディーラー」の開発チームに所属。 要件定義からリリース作業、チームマネジメント、海外出張までこなす何でも屋。 Q. チームでの担当範囲・役割を教えてください 通常の開発業務にくわえ、大規模プロジェクトの設計・設計支援、レガシーサービスの改善、 開発プロセス の改善などを担当しています。 技術面やコスト面で難しい案件を、実行可能なタスクに細分化、優先度付して、開発チームをゴールに導くことが僕の重要な役割の一つだと考えています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 市場シェアの高いサービスを、 裁量権 をもって開発ができる点が魅力だと思います。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　 リファクタリング 、自動テスト ◆情報収集方法 　書籍 Q. おすすめの技術書は何ですか？ 『レガシーコード改善ガイド』 『 リファクタリング 』 『 アジャイル サムライ』 Q. 今後、挑戦したいことはありますか？ 私が担当するサービスは、リリース後２1年になるレガシーサービスです。 このサービスをこの先も開発速度を落とさずに成長させ続けるために、リアーキテクト、 リファクタリング に取り組んでいます。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください チームプレイの大切さを心得ている人ですかねぇ。 会社が成長していく中で、続々と新しいメンバーも増え続けています。 開発メンバーが増えると、チーム力や、チーム間のコラボレーションが今まで以上に重要になってくると感じていますし、そういう人と一緒にプロダクトを盛り上げていきたいです。 一緒に働きませんか？ 今回ご紹介させていただいた3名が所属する組織では、積極的にエンジニアを募集しております。 ラク スでテッ クリード /リードエンジニアとして働きたい方 ご紹介したテッ クリード /リードエンジニアと一緒に働きたい方 などなど、少しでもご興味ありましたらまずは以下求人をご確認ください！ 開発拠点 職種 大阪 エンジニアリングマネージャー（大阪） | 株式会社ラクス Webアプリケーションエンジニア／Java,PHP（大阪） | 株式会社ラクス ブリッジエンジニア/大阪 | 株式会社ラクス プロジェクトマネージャー（大阪） | 株式会社ラクス 終わりに ラク スの開発組織に所属するテッ クリード /リードエンジニアのインタビュー後編はいかがでしたでしょうか？ 是非他記事もご確認いただき、社内の雰囲気をご理解いただけますと幸いです！ そして、 ラク スに興味を持っていただき、是非一緒に働けることをお待ちしております。 ◆ その他インタビュー記事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは！ 技術広報の yayawowo です。 ラク スでは、CMでお馴染みとなってきました 楽楽精算 をはじめ、数多くのプロダクトを開発及びご提供させていただいております。 今回はプロダクト開発に携わる「 ラク スのテッ クリード 」の皆様に、 チームでの役割とは？ テッ クリード /リードエンジニアの魅力とは？ 好きな技術、おすすめの技術書とは？ 今後挑戦したいことは？ などなど、ざっくばらんにインタビューさせていただきました！ 今後、テッ クリード /リードエンジニアを目指している方の一助となれば幸いです。 本記事では、 楽楽精算 ・ 楽楽明細 ・ 楽楽勤怠 の開発組織から4名を紹介したいと思います！ 第三開発部 楽楽精算開発2課 A.Sさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第三開発部 楽楽明細開発課 E.Mさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第三開発部 楽楽勤怠開発課 Y.Kさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第三開発部 楽楽勤怠開発課 Y.Yさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 一緒に働きませんか？ 終わりに 最後までお読みいただきありがとうございました！ 開発組織の後編及び、横断部署・インフラ組織につきましては以下ブログをご確認ください！ ●【インタビュー】 ラク スのテッ クリード /リードエンジニア ～横断部署・インフラ組織編～ tech-blog.rakus.co.jp ● 【インタビュー】 ラク スのテッ クリード /リードエンジニア ～開発組織 後編～ tech-blog.rakus.co.jp 第三開発部 楽楽精算開発2課 A.Sさん Q. まずは自己紹介をお願いします 独学でプログラミングを学びエンジニアに転身。 ネイティブ アプリ開発 を中心に BtoB、BtoC の様々なプロダクト開発を経験する。 2018年以降、 SaaS 開発者に転身し、フロントエンド開発、バックエンド開発、チームマネージメントを幅広い業務分野を担当する。 2021年 ラク ス入社、現在は Android 開発中心にモバイルチームを担当している。 Q. チームでの担当範囲・役割を教えてください 上流の仕様策定、技術検証、実装レビュー、プロジェクトマネージメント、メンバー育成などチーム全体の様々な業務の中心として役割を担わせて頂いております。 ラク スとしてのモバイルアーキテクト、テスト方針など今後の開発の軸になる部分の検討なども行なっています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 自分の特性やチャレンジしたいことに対して選択が多く用意されていることが魅力の一つです。 また、自分でプロダクトの様々な決定事項について裁量を持たせてくれるため、やり甲斐があることも魅力だと思います。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　新しい技術（自分やプロダクトにとって習得が必要な技術）は何でも好きです。 ◆情報収集方法 　developers guideなどの一次情報。 Q. おすすめの技術書は何ですか？ 誰にもオススメという点では・・・ 『リーダブルコード』です。 『リーダブルコード』 技術書ではないが誰にでもMUSTで読んで欲しいです。 『ザ・ゴール』 『peaks（ クラウドファンディング ）の書籍全般』 peaks.cc Q. 今後、挑戦したいことはありますか？ ● モバイル領域で ラク スの 知名度 を上げるため、外部発信を積極的にして行きたい ● チームメンバーのモバイル開発力の向上 ● 楽楽精算チーム全体の 固定観念 払拭 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 前向きに仕事に取り組みたい方、プロダクトと共に成長して行きたい方は「 ラク ス」向いていると思います。 また、RLPに共感できる人、誠意のある人、結果にこだわる人、自分やチームの成長に貪欲な人、行動力がある人とは一緒に働きたいです。 第三開発部 楽楽明細開発課 E.Mさん 第三開発部 楽楽明細開発課 E.Mさん Q. まずは自己紹介をお願いします 前職の2社で主に大企業向けシステムの受託開発でリーダーやサーバ管理を経験した後、2014年に ラク スに入社しました。 （気がつけば入社から8年ですっかり古株になってました） 入社以来ずっと楽楽明細を担当しています。 Q. チームでの担当範囲・役割を教えてください チーム内ではチーム開発を技術面で支えることが主な仕事です。 技術サポートや新しく取り入れる技術要素の選定、インフラチームと協力してサービスを安定稼働させるSRE的な仕事をしています。 テッ クリード としてはチームを跨いだ情報発信や勉強会の主催、課題解決のサポートなども行っています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 1つのサービスに長く関わることができるので、長期的な視点で改善を行いチームやプロダクトが良くなっていることを実感することが出来るのが魅力だと思います。 また、しっかりしたリーダがいることと技術 スペシャ リストの キャリアパス があるため、自身は技術面にフォーカスすることが出来ています。 Q. 好きな技術、技術知識の情報収集方法を教えてください 性格的にその時々で興味が移っていくので特にこれというものはなく、 バックエンドもフロントエンドもインフラも何でも好きです。 強いて言えばOSやネットワーク回りなど低レイヤーなものが比較的好きかもしれません。 情報収集方法は、「書籍」です。 Q. おすすめの技術書は何ですか？ 『ピープルウエア』 Q. 今後、挑戦したいことはありますか？ 今後お客様が増えても安定してシステムが使えるように、多数の同時アクセスや大量データに耐えられる柔軟にスケールできるサービス基盤作りに挑戦したいです。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 社員にはロジカルに物事をとらえて、誠意を持って人と接している人が多いように思います。 個人的にはポジティブで会社・部署・チームにオーナー意識を持てる人と仕事がしたいと思っていて、自分もそうでありたいと思っています。 第三開発部 楽楽勤怠開発課 Y.Kさん 第三開発部 楽楽勤怠開発課 Y.Kさん Q. まずは自己紹介をお願いします 2020年7月入社です。 前職はスタートアップで、 機械学習 系の ASP サービス（主にレコメンド）開発に従事していました。 担当範囲はサーバーサイドのアプリケーションだけでなく、インフラの構築や運用も一通りやっていました。 Q. チームでの担当範囲・役割を教えてください 楽楽勤怠では主に打刻機能の開発を担当しています。 他には アーキテクチャ 全体の見直しや改善、新技術の導入なども行っています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください アーキテクチャ の設計や技術選定など、根本からプロダクトに関われる点ですね。 私の場合、打刻機能のマイクロサービス化という大きな仕事に臨むことになりましたが、入社後2週間程度にも関わらず アーキテクチャ の設計から実装、検証まで一貫して任せてもらえました。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　 Golang 、Docker、Redisなど 　サーバーサイドの話題だったらだいたい食いつきます。 　特にNoSQLはよく食いつくと思います。 ◆情報収集方法 　 SNS （ Twitter 、 Instagram など） Q. おすすめの技術書は何ですか？ 特に無いです。 気になったものは片っ端から読むだけですね。 Q. 今後、挑戦したいことはありますか？ 勤怠計算などを非同期で行えて、なおかつ容易にスケールアウトできる アーキテクチャ を構築・移行していきたいと思っています。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 技術的な事柄に強い関心があり、チャレンジ精神がある人！ 第三開発部 楽楽勤怠開発課 Y.Yさん 第三開発部 楽楽勤怠開発課 Y.Yさん Q. まずは自己紹介をお願いします 前職の SIer では AWS ,Azureを使った Webサービス を開発したり、 Kubernetes 基盤を構築したりしていました。 ラク スでは楽楽勤怠の開発とCI/CD周りを担当しています。 Q. チームでの担当範囲・役割を教えてください 楽楽勤怠の勤怠計算におけるチームリーダを担当しています。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください ラク スのサービスはビジネスサイドの方々のおかげで利用者が増加していくサービスが多いので、サービス成長にあわせて技術的な問題を任せて貰えてことが魅力ですね。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　特定するのであれば Kubernetes , Observabilityとかなんですが、要素技術となるものを好んでいますね。 ◆情報収集方法 　 SNS （ Twitter 、 Instagram など） Q. おすすめの技術書は何ですか？ 『データ指向アプリケーションデザイン』 『SRE サイトリライアビリティエンジニアリング』 Q. 今後、挑戦したいことはありますか？ 現状の アーキテクチャ だと利用者が増加した場合に ボトルネック になる箇所が多々あるので、そこの解決をやれればと思っております。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 自ら問題を見つけてチャレンジできる人があっているのかと思っています。 一緒に働きませんか？ 今回ご紹介させていただいた4名が所属する組織では、積極的にエンジニアを募集しております。 ラク スでテッ クリード /リードエンジニアとして働きたい方 ご紹介したテッ クリード /リードエンジニアと一緒に働きたい方 などなど、少しでもご興味ありましたらまずは以下求人をご確認ください！ 開発拠点 職種 東京 エンジニアリングマネージャー（東京） | 株式会社ラクス Webアプリケーションエンジニア／Java（東京） | 株式会社ラクス フロントエンドエンジニア／マネージャー（東京） | 株式会社ラクス フロントエンドエンジニア（東京） | 株式会社ラクス Androidエンジニア | 株式会社ラクス オフショア開発マネージャー／東京 | 株式会社ラクス ブリッジエンジニア/東京 | 株式会社ラクス QAエンジニア | 株式会社ラクス 開発サポート（東京） | 株式会社ラクス プロダクトマネージャー（東京） | 株式会社ラクス プロジェクトマネージャー(東京） | 株式会社ラクス プロダクトサポートエンジニア（東京） | 株式会社ラクス 終わりに ラク スの開発組織に所属するテッ クリード /リードエンジニアのインタビュー前編はいかがでしたでしょうか？ まだまだ別の部署にもテッ クリード /リードエンジニアがおりますので、是非他記事もご確認いただき、社内の雰囲気をご理解いただけますと幸いです！ そして、 ラク スに興味を持っていただき、是非一緒に働けることをお待ちしております。 ◆ その他インタビュー記事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは！ 技術広報の yayawowo です。 ラク スでは、CMでお馴染みとなってきました 楽楽精算 をはじめ、数多くのプロダクトを開発及びご提供させていただいております。 今回はプロダクト開発に携わる「 ラク スのテッ クリード 」の皆様に、 チームでの役割とは？ テッ クリード /リードエンジニアの魅力とは？ 好きな技術、おすすめの技術書とは？ 今後挑戦したいことは？ などなど、ざっくばらんにインタビューさせていただきました！ 今後、テッ クリード /リードエンジニアを目指している方の一助となれば幸いです。 では早速ですが、本記事では横断部署・インフラ組織から4名を紹介したいと思います！ 開発組織につきましては以下ブログをご確認ください！ ● 【インタビュー】 ラク スのテッ クリード /リードエンジニア ～開発組織 前編～ tech-blog.rakus.co.jp ● 【インタビュー】 ラク スのテッ クリード /リードエンジニア ～開発組織 後編～ tech-blog.rakus.co.jp 第一開発部 開発管理チーム R.Oさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 第一開発部 技術推進課 I.Sさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください インフラ開発部 東京インフラ開発3課 K.Aさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください インフラ開発部 大阪インフラ開発課 K.Uさん Q. まずは自己紹介をお願いします Q. チームでの担当範囲・役割を教えてください Q. テックリード/リードエンジニアとしての魅力を教えてください Q. 好きな技術、技術知識の情報収集方法を教えてください Q. おすすめの技術書は何ですか？ Q. 今後、挑戦したいことはありますか？ Q. ラクスに向いている人・一緒に仕事をしたいと思う人を教えてください 一緒に働きませんか？ 終わりに 第一開発部 開発管理チーム R.Oさん Q. まずは自己紹介をお願いします 2005年に入社。 楽楽販売の開発を経て横断部署に異動。 各種方針やプロセスの整備など開発サポートが主な業務となります。 Q. チームでの担当範囲・役割を教えてください 開発全体のセキュリティ関連の方針や運用の整備を担当することが多いです。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 自身の業務がリードエンジニア・テッ クリード とはスコープが違う気がするので何とも言えませんが、規模や成長度合いの違う様々なサービスに対しどう品質基準を置きどう運用していくのかなどやりごたえのある仕事かと思います。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　仮想化・コンテナ関連 ◆情報収集方法 　会社・仕事 Q. おすすめの技術書は何ですか？ 『 ライト、ついてますか 』 『体系的に学ぶ 安全なWebアプリケーションの作り方』 Q. 今後、挑戦したいことはありますか？ 今は特定の 脆弱性 診断のツールを使っているが、各チームのスタイルに合わせたツールを選定できるようにしたいです。 また、そのための基準作りやチェック方法を確立していきたいと思っています。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 今は、特定の技術に精通している方が向いていると思います。 会社が大きくなり、メンバそれぞれの前提や知識がかなり異なるようになってきたので、情報伝達時にくどくなってもしっかり説明してくれる方が一緒に仕事しやすいです。 第一開発部 技術推進課 I.Sさん 第一開発部 技術推進課 I.Sさん Q. まずは自己紹介をお願いします 大手独立系 SIer で主にプロジェクトマネジメントを経験し、小規模 ベンチャー を経て、2013年に ラク スに入社しました。 楽楽明細のサービスイン・運用開発、楽楽 労務 の アーキテクチャ 選定・基礎設計を担当し、その後は開発チーム横断の先行技術検証を主導しています。 Q. チームでの担当範囲・役割を教えてください 弊社ではこの先利用し得る技術要素の候補を並べた「技術ロードマップ」というものを制定していますが、これの策定および各技術要素の先行検証の主導が主な役割です。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 「リードエンジニア・テッ クリード として」ではなく、会社として年次とかあまり関係なく思ったこと発言すれば何かしら反応があったり、話が進んだりすることが多いのが魅力です。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　主にアプリケーション作成に関わるもの全般 　 低レイヤーな部分や、インフラ部分、 開発プロセス などについてもカバーはしていますが、解決しようとしている業務要件と実現方法を考えるほうが好きですね。 ◆情報収集方法 　 SNS （ Twitter 、 Instagram など）） Q. おすすめの技術書は何ですか？ 『 ライト、ついてますか 』 『 モノリス からマイクロサービスへ』 『熊とワルツを』 『ゆとりの法則』 好きな本はだいぶ絶版になっているので、出版中の本からだとこの辺りがおすすめです。 Q. 今後、挑戦したいことはありますか？ 事業は順調ですが、エンジニアブランドとしてはまだまだ弱いと思うのでそのあたりを強化していければと思っています。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください ビジネス的な思考を求められる組織なので、自分が興味を持つ技術領域とビジネス的な選択との兼ね合いをうまいこと見つけられる人だと挑戦自体はしやすいのかな、と思います。 あとは、人間的にちゃんとしている人で構成されることで余計な考慮をせずに済んでいるところがあるので、そういった人に来てもらいたいと思っています。 インフラ開発部 東京インフラ開発3課 K.Aさん インフラ開発部 東京インフラ開発3課 K.Aさん Q. まずは自己紹介をお願いします 2012年 ラク ス中途入社。 大阪インフラとして入社しいつのまにか東京へ転勤、両拠点で複数のシステムを渡り歩き、現在は主に楽楽販売・楽楽明細のインフラを担当をしています。 Q. チームでの担当範囲・役割を教えてください 担当範囲は結構広いです。 世の中の新しい技術やトレンドの追従、それらを踏まえたシステム全体の設計といったアーキテクトとしての側面から、時には詳細設定一つ一つまでレビューし口出しもします。 プロジェクトリーダーとしての側面もあり、他部署や社外ベンダーとのコミュニケーションやスケジュール管理、現場指示なども行います。 Q. テッ クリード /リードエンジニアとしての魅力を教えてください 任せてもらえる範囲が広いです。 自分の進めたいように進めさせてくれます。 もちろん自由にやっていくばかりではなく成果を出していく必要はありますが、やりがいがあります。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　ネットワーク関連 ◆情報収集方法 　Web記事（note、 はてなブログ など） Q. おすすめの技術書は何ですか？ web記事を大量に漁るタイプなので書籍ではありませんが、「ネットワークエンジニアとして」というページには大変お世話になっております。 神様が記載されたのでしょうか。 www.infraexpert.com Q. 今後、挑戦したいことはありますか？ 既に目の前に多くのプロジェクトが見えており、やることが尽きないです。 具体的な説明は内部情報でもあり難しいですが、より多くのお客様にサービスを安定して提供できるように、レガシーに甘えず大きな構成変更を実施していきます。 それを成功させることが当面の挑戦です。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 相談しやすくコミュニケーションが苦痛にならない、会社に来ることが苦痛にならないチームを目指しています。 自分の意見を積極的に言うことは大切ですが、熱くなりすぎず相手を尊重して意見交換をできる方と一緒にお仕事が出来たら全員ハッピーかなと思います。 インフラ開発部 大阪インフラ開発課 K.Uさん Q. まずは自己紹介をお願いします 前職、前々職では ホスティング サービス会社のサーバサイドエンジニアとして勤務しており、 ホスティング 以外の分野に環境を変えて新たな挑戦をしてみたいと考え2014年に入社しました。 Q. チームでの担当範囲・役割を教えてください 大阪インフラ開発課の中で技術横断チームに属しており、役割として大阪インフラ課を横断して高度な技術で問題を解決する役割のチームとなっています。 主な業務として以下となっています。 　 ● 各商材で発生する高難易度な問題に対する、原因分析や解決策の策定 ● 部、課全体で取り組むべき共通技術の習得や教育・環境構築。またそのフォローアップ。 ● 要件に応じた製品選定や機能・費用比較や基本設計等の上流工程 Q. テッ クリード /リードエンジニアとしての魅力を教えてください マネージャのように 裁量権 が与えられているわけではないが、技術選定や取り組みなどの意思決定に対するウエイトが高い。 責任が伴う反面、浅く広くではなく深く学ぶ必要がある為、業務をこなすほど自身のスキルがあがっていくことを感じると思います。 Q. 好きな技術、技術知識の情報収集方法を教えてください ◆好きな技術 　ansible、自動化、 Linux 関連技術 ◆情報収集方法 　Web記事（note、 はてなブログ など） Q. おすすめの技術書は何ですか？ 『 Linux カーネル 2.6解読室』 『リーダブルコード』 『Infrastructure as Code』 Q. 今後、挑戦したいことはありますか？ オペレーション業務を極力省力化し、属人的な知識に頼らない安定的なインフラの運用。 またそれを実現する為の省力化開発業務（いわゆる自動化・半自動化、標準化、汎用化）を行う部隊と、広範囲に渡る技術に対して高度的な知識を有した技術者集団の構築を目指したい。 Q. ラク スに向いている人・一緒に仕事をしたいと思う人を教えてください 提供しているプロダクトが多い為、常に同じ商材に関わって知識を深めていくもよし、多くのプロダクトに関わって幅広く技術を身に着けることもできるので得意分野を伸ばしたい人や総合力を上げたいと思っている人には良い会社だと思います。 一緒に働きませんか？ 今回ご紹介させていただいた4名が所属する組織では、積極的にエンジニアを募集しております。 ラク スでテッ クリード /リードエンジニアとして働きたい方 ご紹介したテッ クリード /リードエンジニアと一緒に働きたい方 などなど、少しでもご興味ありましたらまずは以下求人をご確認ください！ 開発拠点 職種 東京 PMO/品質管理（東京） | 株式会社ラクス インフラエンジニア[東京/楽楽明細] | 株式会社ラクス インフラエンジニア[東京/楽楽労務] | 株式会社ラクス SREエンジニア[東京/インフラ] | 株式会社ラクス アーキテクト・テックリード[東京/インフラ] | 株式会社ラクス 大阪 【技術推進】アーキテクト／スペシャリスト（大阪） | 株式会社ラクス インフラエンジニア／マネージャー・管理職（大阪） | 株式会社ラクス インフラエンジニア（大阪） | 株式会社ラクス ※2022/2/22時点での情報です。 終わりに ラク スの横断部署・インフラ組織に所属するテッ クリード /リードエンジニアはいかがでしたでしょうか？ まだまだ別の部署にもテッ クリード /リードエンジニアがおりますので、是非他記事もご確認いただき、社内の雰囲気をご理解いただけますと幸いです！ そして、 ラク スに興味を持っていただき、是非一緒に働けることをお待ちしております。 ◆ その他インタビュー記事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは。cappy_potterです。 MailDealer と ChatDeaeler という弊社サービスのインフラ運用チームのリーダを担当しています。 現状、これら2サービスで稼働しているサーバの数は、合計で1,000台近くありますが、 これだけサーバがあると、様々な障害も発生します。 中でも、仮想基盤機器やネットワーク機器で障害が発生した場合は、影響範囲が大きくなりやすいです。 主にそういったものに対し、 「どうすればチームとして迅速に対応できるようになるか？」 ということを考え、実践したことについて紹介したいと思います。 はじめに 過去発生した障害について 周知に時間がかかる要因 各要因への対策 要因①：各自バラバラに対応していて、ムダが生じている 要因②：周知を行う際の目標時間を定めていない 要因③：周知文に記載する内容を都度考えている 要因④：影響範囲特定に必要なアクションが不明瞭 障害対応リハーサルについて リハーサルの流れ その後について 今後の改善予定 過去発生した障害について 過去に発生した、『複数サーバに影響があった障害』について分析した結果、 「 障害発生時、関係者への周知に時間がかかっている 」という課題が見えてきました。 【障害例】 障害概要 影響範囲 原因 発生時刻 復旧時刻 周知時刻 仮想基盤機器ダウン 仮想サーバ32台で再起動発生 機器故障 19:41 19:47 20:23 インターネット回線障害 約800台のサーバに外部からアクセス不可 他ユーザによる回線圧迫 6:21 6:24 7:54 DoS / DDoS攻撃 不明 外部からの攻撃 15:47 16:03 不明 ※サービスは数分～十数分で復旧しているのに、周知に数十分かかっている また、関係者への周知（情報共有）に時間がかかると、以下のような問題が発生します。 　・顧客からの問合せに対し、サポートが何も回答することができない 　・上層部が何かしらの判断を行うにも、状況がわからないと判断のしようがない 　・サービス復旧、事後対応に必要な他部署の協力を得にくくなる（遅くなる） 周知に時間がかかる要因 主な要因として、以下のようなものが挙げられます。 　・各自バラバラに対応していて、ムダが生じている 　・第一報までの目標時間を定めていない 　・周知文に記載する内容を都度考えている 　・影響範囲特定に必要なアクションが不明瞭 すなわち、「 障害発生時における対応方針が決まっていない 」ということが 周知に時間を要している原因であるといえます。 そのため今回、障害発生時の対応方針として、「 時間を意識して、チームとして効率的に動く 」 という方針を定め、それぞれの要因に対する対策を考えました。 各要因への対策 要因①：各自バラバラに対応していて、ムダが生じている 　⇒対策①：役割分担表を作成し、障害時には、まず、誰が何をするのか決めて、かぶらないようにする ■資料の一部抜粋（イメージ） 要因②：周知を行う際の目標時間を定めていない 　⇒対策②：第一報、第二報以降の目標時間を定め、各自がそれに向けて動く アラート認知からの経過時間 目標値 備考 第一報までの時間 15分以内 障害発生時刻・復旧時刻（復旧している場合）・サービス影響を周知 影響範囲特定までの時間 30分以内 単独サーバ障害は除く サービス復旧までの時間 30分以内 要因③：周知文に記載する内容を都度考えている 　⇒対策③：周知文のフォーマットを用意しておき、必要事項を入力するだけで良いようにしておく ■資料の一部抜粋（イメージ） 要因④：影響範囲特定に必要なアクションが不明瞭 　⇒対策④：影響範があったサーバの特定方法を定義しておき、迷わないようにする 弊社の環境では、監視用のサーバが複数あり、それぞれ監視している範囲が異なりますが、サービスに影響が あったかどうかの判別については、原則として、 遠隔監視用サーバでアラート検知したものとする、と定めました。 また、一覧の出力方法も手順としてまとめました。 障害対応リハーサルについて 前項までで、障害発生時における周知時間を短縮化するための対策を行いましたが、これだけではまだ不十分です。 すなわち、各自がこれらの対策内容を「 頭で理解するだけでなく、体で覚えておかないと 」 実際に障害が起こったときに、何をしてよいかわからず、スムーズに動けないことが想定されるからです。 そのためには、障害が発生したと仮定した「障害対応リハーサル」を行い、各自に手を動かして もらうことにより、何をすればよいかを体得してもらうことにしました。 【リハーサルパターン】 影響範囲 障害箇所 障害内容 （例） 単体サーバ サーバ本体 サーバがディスクフルになった 複数サーバ スイッチ スイッチが故障した 複数サーバ Firewall Firewall が故障した 複数サーバ 仮想基盤 仮想基盤用機器がダウンした ※実際に障害を起こすことが難しいものについては、該当機器に障害が発生した場合に検知すると思われる 　アラート一覧を事前に用意しておき、「こんなアラートを検知したとしたらどう対応するか？」 という形で 　実施しました。 リハーサルの流れ リハーサルについては、前項に記載したリハーサルパターンの障害が起こったと仮定して 下図の流れに沿って、メンバ数名で対応するということを何回か繰り返しました。 その後について リハーサル実施後、しばらくして土曜日の夜22時過ぎに、仮想基盤を構成するノードの1台が ダウンするという障害が発生しました。 このとき、アラート検知から関係者への情報共有にかかった時間は「 22分 」でしたが、以前同様の障害が 起こったときには、「 42分 」の時間がかかっていましたので、 およそ半分に短縮 されています。 土曜日の夜という “業務時間外” に発生した障害であるということを考えると、及第点ではないかと思います。 今後の改善予定 今後、さらに周知時間を短縮するおよび、障害からのサービス復旧を早めるための取り組みとして、 以下のようなことを行う予定です。 ●各機器への疎通・ステータス確認、サーバの正常性確認の自動化 　　→ jenkinsなどにあらかじめ Ping の実行先 IPアドレス や HTTPS ・ SMTP のポート接続先アドレスを 　　　登録しておき、ワンクリックで確認できるようにする。 ●アラート検知を契機とした自動復旧の仕組み作り 　　→ Zabbixでのアラート検知時に、自動的に処理が実行されるようにする。 　　　（例）サービス停止検知時、起動コマンドを自動発行する 以上、最後までお読みいただきありがとうございました。 　 　 なお、以下資料にも内容をまとめております。 是非ご参考ください。 speakerdeck.com ◆ 関連ブログのご案内 本内容は、「 【Meetup】大規模SaaSを支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE 」でも発表させていただきました。 他発表については、以下ブログにまとめておりますので是非ご確認ください。 tech-blog.rakus.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

背景 スコープ Tailwind CSSとは？ コンポーネント指向とは？ Tailwind CSSのメリット class名を考える必要がない デザインシステムの最低保証 ドキュメント、チートシートの豊富さ Tailwind CSSのデメリット classに多くのコードを書く必要があり、可読性が落ちやすい CSSの理解度がある程度必要 デザインを100%再現したい場合に強味を生かしづらい 他ライブラリやフレームワークとの比較 Bootstrapとの比較 Material UI/Vuetify等のUIライブラリとの比較 インライン記述との比較 まとめ 所感 参考 背景 こんにちは。mtaaaです。 社内のフロントエンド勉強会で Tailwind CSS について発表を行ったまとめとして、ブログに残したいと思います。 スコープ Tailwind CSS とは？ なぜTailwind CSS に注目が集まっているのか(メリット、デメリット) 他 フレームワーク やライブラリとの比較 ※Tailwind CSS の導入や記法については多くのドキュメントや記事が公開されており、難易度もそれほど高くはないためスコープ外としました。 Tailwind CSS とは？ ユーティリティファーストの考え方を持った CSS フレームワーク ユーティリティファーストという考え方 あらかじめ用意されたclassをhtmlに当てるだけでstyleを適用させていく手法 従来であれば全く同じstyleを当てたい箇所で書くコードが2度手間になってしまう問題がありましたが、React, Vue等 フレームワーク の コンポーネント 指向がこの問題を解消してくれるため、セットで採用されることが多い 簡単なコードだと < span class = "sample" > label </ span > < style > .sample { font-size : 0.75rem ; line-height : 1rem ; font-weight : 600 ; display : inline-block ; padding-top : 0.25rem ; padding-bottom : 0.25rem ; padding-left : 0.5rem ; padding-right : 0.5rem ; text-transform : uppercase ; border-radius : 0.25rem ; color : rgb( 219 , 39 , 119 ) ; background-color : rgb( 251 , 207 , 232 ) ; margin-right : 0.25rem ; } : last-child .sample { margin-right : 0 ; } を以下のように書けます < span class = " text-xs font-semibold inline-block py-1 px-2 uppercase rounded text-pink-600 bg-pink-200 last:mr-0 mr-1 " > label </ span > コンポーネント 指向とは？ ページの コンポーネント (部品)単位で実装を行い、その組み合わせでアプリケーションを作成する 複数回利用する コンポーネント がある場合に使い回しができ、効率的に開発できる 現代フロントエンドで採用されているReact, Vue, Angular等の フレームワーク は コンポーネント 指向に乗っ取っている Tailwind CSS のメリット class名を考える必要がない デザインシステムの最低保証 ドキュメント、 チートシート の豊富さ class名を考える必要がない hoge-wrapper や huga-content のような 命名 を毎度しなくて済み、開発効率を上げられる css の記述もなくなるため単純にコード量を減らせる →htmlのソースだけ見れば内容を把握できる デザインシステムの最低保証 各種サイズや文字色といったカスタマイズについてTailwindで用意しているため、デザインを揃えやすい ex) .h-5 (= height: 20px ), .border-red-300 (= border-color: rgb(252, 165, 165) ) →チーム開発において実装者の違いによる、微妙なずれが発生しづらくなる font-size: 29px のような細かい指定を毎度しなくて済むのでデザインを揃えやすい →自前で細かいカスタムして用意することも可能 ドキュメント、 チートシート の豊富さ 2020から2021年にかけて多くの開発者に使われるようになり、 チートシート は勿論、Tailwindの組み合わせを部品単位で公開している場所も多い →キャッチアップのコストを軽くできる Tailwind CSS のデメリット classに多くのコードを書く必要があり、可読性が落ちやすい css の理解度がある程度必要 デザインを100%再現したいケースで強味を生かしづらい classに多くのコードを書く必要があり、可読性が落ちやすい HTMLにstyleの情報を詰め込むため必然的に情報量が増え、そこだけ見ると可読性が落ちやすい →Prettierで縛ることで対策できる < span class = "bg-pink-200 font-semibold inline-block py-1 uppercase px-2 rounded text-pink-600 last:mr-0 mr-1 text-xs" > label </ span > は以下のようにまとめられます(classを縦並べ、似たstyleを集める) < span class = " text-xs font-semibold inline-block py-1 px-2 uppercase rounded text-pink-600 bg-pink-200 last:mr-0 mr-1 " > label </ span > HTMLと CSS が分かれている場合は、コード理解のために両ソースを行き来する必要があり時間がかかってしまうデメリットがある CSS の理解度がある程度必要 UIライブラリのようにそのまま部品を配置するわけではなく、記法としては CSS のインライン記述の短縮系に近いため、最低限 CSS の知識が必要になる →公開されているパーツを流用することである程度楽はできる デザインを100%再現したい場合に強味を生かしづらい 「ここの余白は13pxで、ここの高さは211pxで。。。」のように厳密に再現したい場合にカスタマイズが必要になる場面が増える →フロントエンドとしてはここである程度統一させていくかをデザイナー(あるいは決まったデザインから)とすり合わせていきたい 他ライブラリや フレームワーク との比較 Bootstrapとの比較 Material UI/Vuetify等のUIライブラリ インラインで直接記述 Bootstrapとの比較 一番話題に上がる比較 BootstrapはUI コンポーネント ライブラリ(パーツ単位)なのに対してTailwind CSS はstyle単位 →用意されているパーツを利用するだけでなく、カスタマイズ性も高い パーツはBootstrapを利用しつつ、レイアウトはTailwindで整える、のような併用も可能 Bootstrapをメインで利用するより CSS の知識が必要になる Material UI/Vuetify等のUIライブラリとの比較 上記のReactやVueのUIライブラリはBootstrapと同じくパーツ単位での提供のため、style単位で指定するTailwindとは異なる →細かいカスタマイズの可否が異なる UIライブラリのパーツを使いつつ、レイアウトはTailwind、ということは同様に可能 インライン記述との比較 記法としてはかなり近い Tailwindではhoverやfocusなど疑似クラスを扱えたり、レスポンシブ対応できたりする デザインシステムがあるため、実質無限の選択肢から指定する必要がない 【インライン記述】 < span style = " font-size: 0.75rem; line-height: 1rem; font-weight: 600; display: inline-block; padding-top: 0.25rem; padding-bottom: 0.25rem; padding-left: 0.5rem; padding-right: 0.5rem; text-transform: uppercase; border-radius: 0.25rem; color: rgb(219, 39, 119); background-color: rgb(251, 207, 232); margin-right: 0.25rem; " class = "sample" > label </ span > < style > /* 疑似要素についてはstyleに別途書く必要がある */ : last-child .sample { margin-right : 0 ; } </ style > 【Tailwind CSS 】 <!-- 疑似要素についてもhtmlで完結できる --> < span class = " text-xs font-semibold inline-block py-1 px-2 uppercase rounded text-pink-600 bg-pink-200 last:mr-0 mr-1 " > label </ span > まとめ ユーティリティファーストでstyleについてHTMLで完結できる、class名を考える必要がない →従来の CSS 設計と完全に異なる React/Vueといったフロントエンド フレームワーク と相性がいい デザインシステムが用意されつつも、カスタムも用意 →開発効率を上げられる 所感 記法については慣れの部分があるため正直違和感がありましたが、そこをクリアすれば 作業効率を上げられる UIライブラリほど引っ張られずに済む 最悪プレーンな CSS に戻せる など恩恵が大きいためReact/Vue等の フレームワーク を利用する場合、個人的には採用したい技術だと感じました。 参考 色々書き比べた結果Tailwind CSSにしたという話 TailwindCSS入門 ~ Utility First + デザインシステムの構築 ~ Tailwind CSSを導入した一年を振り返りながら、今後の展開について考えてみた。 ユーティリティーファーストとTailwind CSSのススメ Tailwind CSS の推しポイントを語りたい 全米が待ち望んでいた超便利なTailwind CSSツールリスト エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は2022年2月8日(火)に ラク スとして初めて開催したテックカンファレンス 「RAKUS Tech Conference 2022」の発表内容を当日利用した発表資料 と合わせて、ご紹介させていただきます。 ◆ 関連記事 現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術情報してきた、 ラク スMeetupの発表実績をまとめている記事です。 tech-blog.rakus.co.jp なお、本イベントの アーカイブ 動画を見たい！という方は 以下フォームより「 ラク スDevelopers」にご登録いただけますと、 後日 アーカイブ 動画をお送りさせていただきます！ ➡ 申込は終了しました！ forms.gle イベント概要 開催概要 発表の紹介 ラクスのエンジニア組織について 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから トラブルゼロで乗り切ったTypeScript移行 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 進化を止めない、"レガシー"との向き合い方 SaaS マルチヒットメーカーラクスのインフラ戦略 クロージングトーク おわりに イベント概要 RAKUS Tech Conference2022 は ラク スが初めて開催するオンラインテックカンファレンス です！ ラク ス開発組織は「顧客をカスタマーサクセスに導く圧倒的に使いやすい SaaS を創る」というミッションを掲げ、 お客さまに必要とされる高品質な SaaS を生み出すべく開発に取組んでおります。 開催概要 日時　：2022/2/8(火) 14:00-18:00 会場　：オンライン 参加費：無料 主催　： 株式会社ラクス Twitter ハッシュタグ ： #RAKUSTechCon contents.rakus.co.jp 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ ラク スのエンジニア組織について 登壇：公手 真之 [ 執行役員 開発本部長 兼 第一開発部長] オープニングでは、 ラク ス開発本部長の公手より、 以下内容を紹介させていただきました！ ラク スについて エンジニア組織について ラク ス開発本部のこれからのチャレンジについて 200名→500名強の組織へ ラク スの開発組織は、 「日本を代表する SaaS エンジニア集団となる」 をビジョンとして掲げています。 完成された組織ではなく、むしろ遅れている部分が沢山あるということを踏まえていただきながら、各々のセッションをご確認いただけますと幸いです！ speakerdeck.com 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから 登壇：間澤 創 [開発本部 第三開発部長] 　　　森山 純 [開発本部 第三開発部 楽楽精算開発2課長] 　　　稲垣 剛之 [開発本部 第三開発部 楽楽精算開発3課長] 年間売上高55億円を超える SaaS である 楽楽精算 のエンジニア組織がどのような成り立ちをしてきたのか、またその今後を楽楽精算の開発に携わる間澤、森山、稲垣よりご紹介させていただきました。 楽楽精算を立ち上げたエンジニア中心の組織から脱却し、オフショア開発、モバイル開発、 プロダクトマネジメント 、QAなど様々な組織を再構成しながら、徐々に大規模な開発組織となっていきました。 さらに、今後どのようにして開発力や組織を強化していくことになるのかを是非ご確認ください！ speakerdeck.com 【求人情報】楽楽精算 ・ エンジニアリングマネージャー ・ Webアプリケーションエンジニア／Java ・ Androidエンジニア ・ オフショア開発マネージャー ・ ブリッジエンジニア ・ プロジェクトマネージャー ・ プロダクトマネージャー ・ プロダクトサポートエンジニア ・ QAエンジニア ※2022/2/16時点での情報です。 トラブルゼロで乗り切ったTypeScript移行 登壇：三田 英一 [開発本部 第三開発部 楽楽明細開発課] 楽楽明細 の開発に携わるテッ クリード の三田より、 8年ほど運用しているjQueyで実装されたサービスをTypeScriptに移行した事例を紹介しました。 発表ポイントは以下の通りです。 機能開発を止めずに安全かつ低コストで移行するノウハウ 移行するメリット／デメリット うまくいったこと／苦労したこと speakerdeck.com 発表時に話しきれなかった内容は、以下のQiitaにて別途まとめております！ 合わせてご確認ください。 qiita.com 【求人情報】楽楽明細 ・ エンジニアリングマネージャー ・ Webアプリケーションエンジニア／Java ・ オフショア開発マネージャー ・ ブリッジエンジニア ・ プロジェクトマネージャー ・ プロダクトマネージャー ・ プロダクトサポートエンジニア ・ QAエンジニア ・ フロントエンドエンジニア／マネージャー ・ フロントエンドエンジニア ※2022/2/16時点での情報です。 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 登壇：頓花 貴俊 [開発本部 第ニ開発部 楽楽販売開発課] 続いて、 楽楽販売 の開発に携わる頓花より、 リリースから10年以上経つサービスがPHP8へのバージョンアップで起きた課題・解決法について紹介しました。 ご紹介した具体的な課題と対応策は、以下の通りです。 影響範囲の調査と対応範囲の検討 後方互換 性の無い変更に対する対応 静的チェックが難しい変更点 サービスの品質担保について など speakerdeck.com 【求人情報】楽楽販売 ・ Webアプリケーションエンジニア／Java,PHP ・ プロジェクトマネージャー ※2022/2/16時点での情報です。 進化を止めない、"レガシー"との向き合い方 登壇：矢成 行雄 [開発本部 第四開発部長] 私たち ラク スでは多くの SaaS プロダクトを開発・運営しています。 中にはリリース以来20年を超える歴史を持つようなサービスもあります。 ともすれば、"レガシー"の一言で片づけられてしまいかねないプロダクトであっても、 ラク スでは決して進化を止めることはありません。 EOLや新 フレームワーク など新技術要素との向き合い方 モダンな開発スタイルとのハイブリッドなアプローチ 中核となる技術（＝ PHP ）にかける ブランディング 戦略 など、私たちがどのように"レガシー"と向き合ってきたかを MailDealer 、 ChatDealer 、 配配メール 、 Curumeru の開発部長である矢成がお話しました。 speakerdeck.com 【求人情報】MailDealer/ChatDealer/配配メール/Curumeru ◆大阪 ・ Webアプリケーションエンジニア／Java,PHP ・ プロジェクトマネージャー ・ ブリッジエンジニア ◆東京 ・ フロントエンドエンジニア／マネージャー ・ フロントエンドエンジニア ※2022/2/16時点での情報です。 SaaS マルチヒット メーカー ラク スのインフラ戦略 登壇：金本 宏司 [開発本部 インフラ開発部 副部長] ラク スでは9割以上のシステムをオンプレミスで構築し運用しています。 何故オンプレなのか Saas 企業のインフラで考慮すべきポイント IT市場の変化に伴いオンプレでの kubernetes 環境構築も視野に入れた今後のインフラ戦略 について話しました。 speakerdeck.com 【求人情報】インフラ開発課 ◆東京 ・ インフラエンジニア／マネージャー ・ インフラエンジニア ・ AWSエンジニア ・ アーキテクト・テックリード ・ SREエンジニア ◆大阪 ・ インフラエンジニア／マネージャー・管理職 ・ インフラエンジニア ※2022/2/16時点での情報です。 クロージング トーク 登壇：公手 真之 [ 執行役員 開発本部長 兼 第一開発部長] 　　　間澤 創 [開発本部 第三開発部長] 　　　矢成 行雄 [開発本部 第四開発部長] 　　　金本 宏司 [開発本部 インフラ開発部 副部長] 最後のクロージング トーク では、公手、間澤、矢成、金本を交えながら 「RAKUS Tech Conference 2022」の振り返り ミッション/ビジョン/バリューの目的・背景 ラク スのエンジニアカルチャー 各部門の雰囲気 など、生の声で発信させていただきました！ こちらについては発表資料がないため、 アーカイブ 動画の公開 までお待ちいただければと思います。 おわりに 「RAKUS Tech Conference 2022」はいかがでしたでしょうか？ 開催時間が日中にも関わらず、多くの方にご参加いただきました。 改めて、お礼申し上げます。 RAKUS Tech Conference 2023も開催する予定でおりますので、今回参加できなかった方は次回是非ご参加ください！我々 ラク ス開発部もエンジニアの皆様、 SaaS 開発に携わる方の一助となるような技術発信ができるよう、日頃から精進したいと思います！！ 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 Web制作をする際に、 ・このテキスト強調したいな… ・この見出しをおしゃれにできないかな？ と思うことはないでしょうか。 そこで今回は、 CSS で下線を引く方法に加え、太さや色付け、点線にする方法を解説したいと思います！ HTMLと CSS のコード例も記述しておりますので、是非ご参考ください。 CSSで下線を引く方法 ① text-decoration text-decorationのコード・実行結果例 ② border-bottom border-bottomのコード・実行結果例 ③ background backgroundのコード・実行結果例 まとめ ◆ CSS 関連のブログ ・ CSS（スタイルシート）の書き方【初心者向け】 ・ 【CSS実装予定】カスケードレイヤー「@layer」について CSS で下線を引く方法 早速、 CSS で下線を引く方法を解説します。 方法は大きく3つあり、使いたい線の種類や用途によって、 CSS のプロパティが異なります。 最適なものをご選択の上、ご活用ください！ ① text-decoration まずは、 CSS で一般的な下線を引きたい時に便利な text-decoration の使い方です。 text-decoration は、「線の位置」・「線の種類」・「線の色」を指定することができます。 text-decoration: 線の位置 線の種類 線の色 では、 CSS で下線を引くためにはどのように指定すればよいのでしょうか？ 以下の表を参考にしつつ、「線の位置」「線の種類」を指定してみましょう。 「線の色」はお好みの色でお願いします。 指定内容 指定方法 説明 線の位置 none 線なし line-through 取り消し線 overline 上線 underline 下線 線の種類 solid 一重線 double 二重線 dotted 点線 dashed 破線 wavy 波線 text-decorationのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > text-decoration 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > text-decorationの使い方 </ h2 > < p class = "text-decoration1" > 一重線の下線（赤） </ p > < p class = "text-decoration2" > 二重線の下線（青） </ p > < p class = "text-decoration3" > 点線の下線（緑） </ p > < p class = "text-decoration4" > 破線の下線（橙） </ p > < p class = "text-decoration5" > 波線の下線（紫） </ p > </ body > </ html > ◆ コード例（ CSS ） /* 一重線の下線 */ .text-decoration1 { text-decoration : underline solid red } /* 二重線の下線 */ .text-decoration2 { text-decoration : underline double blue } /* 点線の下線 */ .text-decoration3 { text-decoration : underline dotted green } /* 破線の下線 */ .text-decoration4 { text-decoration : underline dashed orange } /* 波線の下線 */ .text-decoration5 { text-decoration : underline wavy purple } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . text-decoration では、「線の位置」・「線の種類」・「線の色」を指定することで簡単に CSS で下線が引けることが分かりました！ ② border-bottom 続いて、 border-bottom の使い方です。 border-bottom は、「線の種類」・「線の太さ」・「線の色」を指定することができます。 border-bottom: 線の種類 線の太さ 線の色 text-decoration との違いとしては、 「線の太さ」 が指定できるところです。 「線の種類」は、以下の表を参考にし、実際にコード例と実行結果を見てみましょう。 指定内容 指定方法 説明 線の種類 solid 一重線 double 二重線 dotted 点線 dashed 破線 border-bottomのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > border-bottom 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > border-bottomの使い方 </ h2 > < p >< spna class = "border-bottom1" > 2pxの一重下線（赤） </ span ></ p > < p >< spna class = "border-bottom2" > 4pxの二重下線（青） </ span ></ p > < p >< spna class = "border-bottom3" > 6pxの点線下線（緑） </ span ></ p > < p >< spna class = "border-bottom4" > 8pxの破線下線（橙） </ span ></ p > </ body > </ html > ◆ コード例（ CSS ） /* 一重線の下線 */ .border-bottom1 { border-bottom : solid 2px red } /* 二重線の下線 */ .border-bottom2 { border-bottom : double 4px blue } /* 点線の下線 */ .border-bottom3 { border-bottom : dotted 6px green } /* 破線の下線 */ .border-bottom4 { border-bottom : dashed 8px orange } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . 太さを変えたい場合は、 border-bottom を使うと便利です！ ③ background 最後は、 background の使い方です。 CSS に詳しい方はご存知かと思いますが、こちらは背景関連のプロパティを指定するものです。 background を活用することで、まるで 蛍光ペン で引いたような線を CSS で引くことができます。 その際、 linear-gradient の指定が必要ですので注意ください！ background: linear-gradient(transparent 蛍光ペンを引かない線の幅, 線の色 0%); コード例を見た方が分かりやすいかと思いますので、さっそく… backgroundのコード・実行結果例 ◆ コード例（HTML） < html lang = “ja” > < head > < meta charset = “UFT-8” > < title > background 使い方 </ title > < link rel = "stylesheet" href = "style.css" > </ head > < body > < h2 > backgroundの使い方 </ h2 > < p >< spna class = "background1" > 蛍光ペン幅20%の下線（赤） </ span ></ p > < p >< spna class = "background2" > 蛍光ペン幅40%の下線（青） </ span ></ p < p>< spna class = "background3" > 蛍光ペン幅60%の下線（緑） </ span ></ p > < p >< spna class = "background4" > 蛍光ペン幅80%の下線（橙） </ span ></ p > </ body > </ html > ◆ コード例（ CSS ） /* 蛍光ペン幅20%の下線 */ .background1 { background : linear-gradient( transparent 80% , red 0% ) ; } /* 蛍光ペン幅40%の下線 */ .background2 { background : linear-gradient( transparent 60% , blue 0% ) ; } /* 蛍光ペン幅60%の下線 */ .background3 { background : linear-gradient( transparent 40% , green 0% ) ; } /* 蛍光ペン幅80%の下線 */ .background4 { background : linear-gradient( transparent 20% , orange 0% ) ; } ◆ 実行結果 See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . 　 transparent では、「 蛍光ペン を引かない線の幅」を指定する必要があります。 また、「 蛍光ペン を引かない線の幅」は、【100% -「 蛍光ペン を引きたい幅」】で簡単に求めることができますよ！ 「線の色」は、HTMLカラーコードでも指定することができます。 是非、 CSS で自分好みのおしゃれな下線を作ってみてください！ See the Pen Untitled by yasuko ( @yayafu_ ) on CodePen . まとめ CSS で下線（アウトライン）を引く方法はいかがでしたでしょうか？ CSS のプロパティは大きく分けて3つあるため、用途に応じてプロパティをお使いください！ 改めまして本ブログが、 CSS を使う方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに こんにちは、 @rs_tukki です。 12月に ラク スのAdvent Calenderで Cordovaについての記事 を寄稿しましたが、今回もCordovaについての話をさせていただきます。 はじめに Cordovaとは？ Cordova Pluginを自分で作ってみる Cordovaプロジェクトの作成 Pluginの定義(plugin.xml / package.json) ネイティブコードの実装(CheckIsDebugPlugin.java) ネイティブコードを呼び出す(checkIsDebugPlugin.js) 動作確認 おわりに 参考 Cordovaとは？ さて、まずはCordovaについて軽く触れておきます。 Cordova(Apache Cordova) とは、 オープンソース の開発 フレームワーク です。 平たく言えば Spring Framework 等と似たようなものです。 Cordovaの特徴は、同じ ソースコード で、 Android 、 iOS 、ブラウザの3つのプラットフォーム向けにアプリのビルドができることです。 いわゆる「 クロスプラットフォーム 」というやつです。 また、基本的にHTML/ CSS / Javascript で動作するため、バックエンドの知識に明るくないエンジニアでも単純なアプリケーションの開発であればできてしまうのもメリットです。 Cordova Pluginを自分で作ってみる 先ほど「(Cordovaは)基本的にHTML/ CSS / Javascript で動作する」と書きました。 基本的に、というのは文字通り基本的な動作しか実現できないという意味で、 Android や iOS 特有の機能、例えばカメラなんかにアクセスすることはそのままではできません。 そこでどうするかというと、 JavaScript から Java やSwiftのコードを呼び出して使えるようにするわけです。 こういったネイティブ特有の機能を呼び出すためのコード群を「Cordova Plugin」といいます。 Cordova自体はかなり成熟した フレームワーク ですから、主要なネイティブ機能は Apache 公式が プラグイン を整備していたりしますし、 Github を漁ってみればそれこそCordovaユーザが独自に開発した プラグイン が山のように見つかります。 ただし、そういった第 三者 の作成した プラグイン はあまりメンテナンスされていないものが多く、最終更新が3年前、4年前といったものもザラです。 使いたい機能のためのCordova プラグイン を見つけた！と思ったらろくにアップデートもされておらずエラーになって使用できない……というのはよくある話。 そのような プラグイン はフォークして自分でメンテナンスしてもいいですが、折角なので0から自分で プラグイン を作成するやり方を学んでみましょう。 Cordovaプロジェクトの作成 Cordova Pluginを作成する前に、まずは土台となるCordovaプロジェクトを作成します。 npm installでCordovaをインストールしたら、 cordova create [プロジェクト名] でテンプレートを作成してくれます。便利。 $ sudo npm install -g cordova Password: + cordova@ 11 . 0 . 0 added 129 packages from 59 contributors, removed 36 packages, updated 125 packages and moved 2 packages in 15 .838s $ cordova create testApp Creating a new cordova project. $ Cordovaプロジェクトの作成直後は、以下のようなツリー構造になっています。 $ tree . ├── config.xml ├── package.json └── www ├── css │   └── index.css ├── img │   └── logo.png ├── index.html └── js └── index.js 4 directories, 6 files www ディレクト リがCordovaで画面表示や画面遷移を実現するための核となる部分です。 これだけでも最低限アプリは動くようになっていますが、今回は Android 向けのCordova プラグイン を実装して、 「今開いているアプリがdebugビルドかどうか」を判定できるようにしてみましょう。 先に結論から言ってしまうと、 プラグイン の実装後は以下のようなツリー構造になります。 $ tree . ├── config.xml ├── package.json ├── plugin │   └── cordova-plugin-checkIsDebug │   ├── package.json │   ├── plugin.xml │   ├── src │   │   └── android │   │      └── CheckIsDebugPlugin.java │   └── www │   └── checkIsDebugPlugin.js └── www ├── css │   └── index.css ├── img │   └── logo.png ├── index.html └── js └── index.js 10 directories, 11 files Pluginの定義(plugin. xml / package. json ) まずは、Cordova プラグイン を利用するために必要な設定を記載していきます。 まずはファイル全体をぺたり。 <? xml version = "1.0" encoding = "UTF-8" ?> <plugin xmlns = "http://apache.org/cordova/ns/plugins/1.0" id = "cordova-plugin-check-is-debug" version = "1.0.0" > <name> Check is Debug Plugin </name> <description> check whether cordova app is debugMode </description> <author> rs_tukki </author> <license> MIT License </license> <engines> <engine name = "cordova" version = ">=7.0.0" /> </engines> <js-module src = "www/checkIsDebugPlugin.js" name = "pluginBridging" > <clobbers target = "checkIsDebug" /> </js-module> <platform name = "android" > <config-file target = "res/xml/config.xml" parent = "/*" > <feature name = "CheckIsDebug" > <param name = "android-package" value = "com.rs.tukki.testapp.plugin.checkisdebug.CheckIsDebugPlugin" /> </feature> </config-file> <source-file src = "src/android/CheckIsDebugPlugin.java" target-dir = "com/rs/tukki/testapp/plugin/checkisdebug/" /> </platform> </plugin> Plugin. xml ではこの プラグイン の名前やバージョン、どのようにその プラグイン を呼び出すかといった情報を定義しています。 特に重要なのは <engines> 、 <js-module> 、 <platform> の各ディレクティブです。 では一つづつ解説していきます。 <engines> <engine name = "cordova" version = ">=7.0.0" /> </engines> <engines> ディレクティブでは、この プラグイン を使用するのに要求されるCordovaのバージョンを指定できます。 省略しても問題ない項目ではありますが、あまりにも古いCordovaを使用していると使えないケースもありますので、ひとまず7.0辺りを指定しておくとよいでしょう。 <js-module src = "www/checkIsDebugPlugin.js" name = "pluginBridging" > <clobbers target = "checkIsDebug" /> </js-module> <js-module> ディレクティブでは、Plugin内で外部から参照させるためのjsファイルを指定できます。 今回のPluginではCordovaプロジェクト本体とネイティブコードの橋渡しとして、 www/ ディレクト リ内に checkIsDebugPlugin.js を追加していますので、これを src 属性に指定します。 name 属性は開発者が参照することはないので、任意の名前をつければOKです。 重要なのは内部の colobbers 要素で、ここの target 属性で指定した値を使ってCordovaプロジェクトから関数として呼び出すことになります。 <platform name = "android" > <config-file target = "res/xml/config.xml" parent = "/*" > <feature name = "CheckIsDebug" > <param name = "android-package" value = "com.rs.tukki.testapp.plugin.checkisdebug.CheckIsDebugPlugin" /> </feature> </config-file> <source-file src = "src/android/CheckIsDebugPlugin.java" target-dir = "com/rs/tukki/testapp/plugin/checkisdebug/" /> </platform> <platform> では、各プラットフォームごとにどのような設定やネイティブコードが必要かを定義しています。 今回は Android に絞って解説します。 最初の <config-file> ディレクティブでは、「この プラグイン はこのような形でこのクラスを呼び出します」という情報を config.xml に追記するための設定を行なっています。 <feature> 要素の name 属性が特に重要で、この値は cordova.exec というネイティブコードを呼び出すための関数で第三引数に指定する必要があります。(後述) <param> 要素の value 属性には呼び出す対象となるクラスをパッケージ名を含めて記載してください。 <source-file> 要素には、 Android 向けにプロジェクトを構築する際、ネイティブコードをプロジェクトに含めるために追加する必要がある項目です。 この記載がないとプロジェクト内にネイティブコードが含まれず、当然呼び出しに失敗します。 src 属性はこの plugin.xml からの 相対パス で java ファイルを指定します。 target-dir 属性は構築されたプロジェクトでのファイルの配置先の指定に使います。 ここまで記載できればネイティブコードを呼び出す最低限のPlugin. xml としてはOKです。 (実際はネイティブコードを一切呼び出さないCordova プラグイン もあったりしますが...それはまた次の機会に) 続いてpackage. json を作成します。 ここでは依存性の注入や最初に呼ばれる スクリプト の設定などが行えます...が、 プラグイン を OSS として公開する必要がなく、最低限の実装だけ行いたい場合は必須の2項目だけ記載しておけばよいでしょう。 { " version ": " 1.0.0 ", " name ": " cordova-plugin-check-is-debug " } そのほかの設定項目は以下を参考にしてみてください。 qiita.com ネイティブコードの実装(CheckIsDebugPlugin. java ) さて、次は プラグイン の本体となる Java クラスを実装していきます。 Java でCordova プラグイン を実装する場合、 CordovaPlugin クラスを継承したクラスを作成し、 executeメソッドをOverrideして処理を記載していきます。 今回はdebugビルドかどうかを取得したいので、 java コード上で判定処理を組み込み、返却用の JSON オブジェクトに格納します。 package com.rs.tukki.testapp.plugin.checkisdebug; import org.apache.cordova.CordovaPlugin; import org.apache.cordova.CallbackContext; import org.json.JSONArray; import org.json.JSONException; import org.json.JSONObject; import io.cordova.hellocordova.BuildConfig; public class CheckIsDebugPlugin extends CordovaPlugin { @Override public boolean execute(String action, JSONArray args, CallbackContext callbackContext) throws JSONException { JSONObject result = new JSONObject(); if (BuildConfig.DEBUG) { result.put( "isDebug" , true ); } else { result.put( "isDebug" , false ); } callbackContext.success(result); return true ; } } 最終的に、executeはbool値を戻り値として返します。 trueなら成功時のcallbackが、falseなら失敗時のcallbackが呼ばれます。 この前に、callbackContextのsuccessメソッドもしくはerrorメソッドにパラメータを格納しておけば、callback内でその値を参照することができます。 ネイティブコードを呼び出す(checkIsDebugPlugin.js) さて、次はこのネイティブコードをフロント側から呼び出せるようにします。 ネイティブコードは直接Cordovaプロジェクト側から呼び出す方法もなくはないですが、基本的には一旦 プラグイン 内のjsコードを挟むことになります。 const CheckIsDebugPlugin = function () { } ; CheckIsDebugPlugin.prototype.isDebug = function (success, fail) { cordova.exec(success, fail, "CheckIsDebug" , "isDebug" , [] ); } ; const checkIsDebug = new CheckIsDebugPlugin(); module.exports = checkIsDebug; cordova.exec はネイティブコードを呼び出すためのメソッドです。 第一引数と第二引数はそれぞれ成功時、失敗時のコールバック、 第三引数は plugin.xml の feature 要素で指定した値、 第四引数はネイティブコード内で処理を判別するための文字列、 第五引数は任意のパラメータを取ります。 この関数をexportsすることで、 Plugin.xml の clobbers 要素で指定したtarget名で呼び出すことができます。 すなわち、実際に呼び出す際は以下のような形になります。 成功した場合のコールバック処理でははdebugビルドかどうかを表示するようにしておきましょう。 window .checkIsDebug.isDebug(result => { console.log(result.isDebug); document .getElementById( "isDebug" ).textContent = "debugMode is " + result.isDebug; } , err => { console.log(err); document .getElementById( "isDebug" ).textContent = "error!:" + err; } ); 動作確認 さて、これでPluginを導入したCordovaアプリのサンプルが作成できましたので、 早速実機で動作確認をしてみましょう。 アプリの動作確認は、以下の順序で行います。 なお、 Android でビルドを行う場合は SDKにパスを通す 必要があるので忘れずに行っておきましょう。 cordova plugin add [フォルダパス] で作成したCordova Pluginを登録する cordova platform add [プラットフォーム名] で各プラットフォーム向けにビルドの準備をする cordova run [プラットフォーム名] でアプリをビルドし、実行する release向けにビルドを行う場合はもう少し詳細に設定が必要ですが、debug版での動作確認はひとまずこれだけできれば十分です。 $ cordova plugin add plugin/cordova-plugin-check-is-debug Installing " cordova-plugin-check-is-debug " for android Adding cordova-plugin-check-is-debug to package.json $ cordova platform add android Using cordova-fetch for cordova-android@^ 9 . 0 . 0 Adding android project... Creating Cordova project for the Android platform: Path: platforms/android Package: io.cordova.hellocordova Name: HelloCordova Activity: MainActivity Android target: android-29 Subproject Path: CordovaLib Subproject Path: app Android project created with cordova-android@ 9 . 1 . 0 Discovered plugin " cordova-plugin-whitelist " . Adding it to the project Installing " cordova-plugin-whitelist " for android Adding cordova-plugin-whitelist to package.json $ cordova run android Checking Java JDK and Android SDK versions ANDROID_SDK_ROOT =/Users/your_name/Library/Android/SDK ( recommended setting ) ANDROID_HOME =/Users/your_name/Library/Android/SDK ( DEPRECATED ) Using Android SDK: /Users/your_name/Library/Android/SDK Starting a Gradle Daemon ( subsequent builds will be faster ) Deprecated Gradle features were used in this build, making it incompatible with Gradle 8 . 0 . You can use ' --warning-mode all ' to show the individual deprecation warnings and determine if they come from your own scripts or plugins. See https://docs.gradle.org/ 7 . 3 /userguide/command_line_interface.html #sec:command_line_warnings BUILD SUCCESSFUL in 7s 1 actionable task: 1 executed Subproject Path: CordovaLib Subproject Path: app Downloading https://services.gradle.org/distributions/gradle -6 .5-all.zip ............. 10 %.............. 20 %.............. 30 %.............. 40 %.............. 50 %.............. 60 %.............. 70 %.............. 80 %.............. 90 %.............. 100 % Starting a Gradle Daemon ( subsequent builds will be faster ) Deprecated Gradle features were used in this build, making it incompatible with Gradle 7 . 0 . Use ' --warning-mode all ' to show the individual deprecation warnings. See https://docs.gradle.org/ 6 . 5 /userguide/command_line_interface.html #sec:command_line_warnings BUILD SUCCESSFUL in 1m 57s 40 actionable tasks: 40 executed Built the following apk ( s ) : /Users/your_name/workspace/testApp/platforms/android/app/build/outputs/apk/debug/app-debug.apk Checking Java JDK and Android SDK versions ANDROID_SDK_ROOT =/Users/your_name/Library/Android/SDK ( recommended setting ) ANDROID_HOME =/Users/your_name/Library/Android/SDK ( DEPRECATED ) Using Android SDK: /Users/your_name/Library/Android/SDK Deploying to device 0B161FDD4001VQ Using apk: /Users/your_name/workspace/testApp/platforms/android/app/build/outputs/apk/debug/app-debug.apk Package name: io.cordova.hellocordova INSTALL SUCCESS LAUNCH SUCCESS コマンドを実行してアプリを起動すると、 デフォルトのTOPページに新しく追加した DEBUGMODE IS TRUE の文字が確認できるかと思います。 おわりに 今回は、Cordovaプロジェクトの新規作成から、 Android 向けのCordova プラグイン を作成して動作確認するところまでを実装してみました。( iOS はまた機会があれば……) 仕組みさえ理解してしまえばKotlinやSwiftのネイティブアプリと遜色ないアプリを作れますし、なによりフロントエンドの知識で画面制御を実現できるのが圧倒的に便利ですので、まず何かアプリを作ってみたい！という方はCordovaを試してみてはいかがでしょうか。 参考 Apache Cordova Cordovaを使って、Androidの実機実行するまで - Qiita MacでCordovaのインストール・実行・ビルドまで (iOS, Android, Web) | 株式会社TKS2 Cordova PluginのJavaScript部分の実装 - Qiita package.jsonの中身を理解する - Qiita BuildConfig クラスでアプリの動作を切り替える | まくまくAndroidノート Cordova Pluginの基本事項 - Qiita Cordovaプラグインを開発してみよう！ – モナカプレス エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

勤怠開発課のy_konnoです。 暇があるとNoSQLを漁りだす癖があるんですが、今回はRethinkDBが気になったので試してみたので書いてみようと思います。 NoSQLとは RethinkDBとは セットアップ 基本的な使い方 接続 DB作成・テーブル作成 INSERT UPDATE SELECT DELETE Change Feeds いじってみた感想 NoSQLとは まず先にNoSQLについて軽く触れておきましょう。 NoSQLとはデータを関係テーブルとは異なる何らかの方法で保存するタイプのデータベースです。 キーバリュー、ドキュメント、グラフなどがNoSQLでよく用いられます。 NoSQLは特定のデータモデルに特化した設計がなされています。 このためNoSQLを用いるとより柔軟なデータ設計ができたり、パフォーマンスを高めることが容易になったり、簡単にスケールアウトする構成をとれたりします。 代表的なNoSQLプロダクトは以下のとおりです。 NoSQLプロダクト例 キーバリュー：Redis ドキュメント：MongoDB グラフ：Neo4j RethinkDBとは RethinkDBはNoSQLの一つで オープンソース のドキュメント指向データベースです。 当初RethinkDB社が開発やサポートを行っていたようですが、紆余曲折を経て現在は Linux Foundationに寄贈され、開発が継続されているようです。 データの操作はRethinkDB query language(ReQL)によって行います。 複数のReQLをチェーンしたり、遅延実行することが可能です。 大きな特徴の一つとして、更新結果をリアルタイムでPUSHする機構があります。 これにより変更をポーリングすること無く連続的に取得する事が可能となっています。 その他にも クラスタリング やMap Reduceなどの大規模向けの機能や、テーブルのJOIN、複数の2次インデックスのサポートなど非常に多岐にわたる機能が提供されています。 公式のクライアントは JavaScript 、 Python 、 Ruby 、 Java の4つが用意されています。 他の処理系であってもコミュティによる開発が行われています。 セットアップ サーバーは Windows 、 Mac 、 Linux いずれの環境にも対応していますが、公式のDockerイメージが用意されているのでそちらを利用します。 本稿執筆時点でのバージョンは2.4.1を利用しています。 https://hub.docker.com/_/rethinkdb docker pull rethinkdb Pullが完了したら起動します。 RethinkDBにおける通信のポートは28015なので割当てます。 また、Webの管理コンソールも同梱されているのでついでに利用できるようにしておきます。 そちらのポートは8080です。 docker run -d -p 8080:8080 -p 28015:28015 --name rethink1 rethinkdb RethinkDBのWeb管理コンソールはブラウザから localhost :8080でアクセスできます。 テーブルの確認・作成・削除やドキュメントの確認などの操作を行えます。 ひとまず、これでRethinkDBの利用準備が整いました。 基本的な使い方 まずは、RethinkDBの基本的な使い方を見てみます。 ここでは一通り CRUD をしてみようと思います。 クライアントは Java です（ JDK は11想定）依存関係の追加方法はそれぞれ以下になります。 ・Gradle dependencies { implementation 'com.rethinkdb:rethinkdb-driver:2.4.4' } ・ Maven <dependencies> <dependency> <groupId> com.rethinkdb </groupId> <artifactId> rethinkdb-driver </artifactId> <version> 2.4.4 </version> </dependency> </dependencies> 接続 まずはRethinkDBへのコネクションを生成します。 RethinkDB r = RethinkDB.r; Connection connection = r.connection() .hostname( "localhost" ) .port( 28015 ) .connect(); これだけです。 RethinkDBの インスタンス の生成時の名称（ r ）に若干ぞわぞわしますが、それ以外は至ってわかりやすいかと思います。 なお、コネクションの取得時に タイムアウト や認証系の情報も設定できます。 以降は、このコネクションを使ってINSERTやSELECTなどの操作を行っていきます。 DB作成・テーブル作成 RethinkDBでは、一般的な RDB のようにデータベースとテーブルがあります。Dockerのコンテナ作成時に、デフォルトで test というデータベースを作成してくれるようです。 仮に test データベースが無い場合は、以下で生成できます。 r.dbCreate( "test" ).run(connection); 今回は用意された test データベース上に、 sales というテーブルを作成してみます。 r.db( "test" ) .tableCreate( "sales" ) .run(connection); DB コマンドで test データベースを選択し、そこに tableCreate コマンドで sales を指定、あとは run コマンドでRethinkDBサーバーへコマンドを送信するという流れです。 すでに sales テーブルが存在する場合は、 ReqlOpFailedError 例外が発生します。 なお、 CREATE IF NOT EXISTS のような便利機能はないので、同等のことをやる場合は tableList コマンドでテーブルをリストアップし、存在しなければ tableCreate を実行するという手順を踏む必要があります。 INSERT テーブルができたので、データを追加してみます。 一気に3件のデータを入れてみます。 List<Object> insertData = r.array(r.hashMap( "name" , "apple" ) .with( "price" , 100 ) .with( "quantity" , 5 ) .with( "payment" , "cash" ), r.hashMap( "name" , "banana" ) .with( "price" , 200 ) .with( "quantity" , 3 ) .with( "payment" , "cash" ), r.hashMap( "name" , "melon" ) .with( "price" , 5000 ) .with( "quantity" , 1 ) .with( "payment" , "credit" ) ); r.table( "sales" ) .insert(insertData) .run(connection); 実行後、Web管理コンソールで確認すると以下のようなデータが入っています。 id name payment price quantity 29f94218-1ef9-4c3b-9dfb-1f92a231b9e8 apple cash 100 5 1fbf055e-48ba-4061-9001-98ecf8053c1f banana cash 200 3 d94a7dba-4d33-482b-ae0d-2164557469b3 melon credit 5000 1 INSERT時にはidを指定していませんが、これはPKをテーブル作成時に指定しなかったために作成されているデフォルトのカラムになります。 値はUUIDが自動的に挿入されるので、上記の値は一例です。 UPDATE 次にUPDATEをしてみます。 先程INSERTしたmelonのドキュメントを変更してみます。 r.table( "sales" ) .get( "9769473a-eeb5-4b7f-b877-218cb6942796" ) .update( r.hashMap( "price" , 10000 ) .with( "quantity" , 10 ) ) .run(connection); 特定のドキュメントだけを更新するにはまず、 get で対象のIDを指定してUPDATEする対象を制限する必要があります。 あとはUPDATEしたい項目だけ、新しい値を指定すればOKです。 get をしない場合は、テーブル内のすべてのドキュメントを一括で更新する挙動になります。 また、ID指定ではなく特定の条件でUPDATEする場合は以下のように filter を使います。 r.table( "sales" ) .get( "9769473a-eeb5-4b7f-b877-218cb6942796" ) .update( r.hashMap( "price" , 10000 ) .with( "quantity" , 10 ) ) .run(connection); SELECT 次にSELECTをしてみます。 UPDATEと同じく、全件取得か特定のドキュメントを取得するかで若干処理が変わります。 まずは全件取得をしてみます。こちらは非常にシンプルです。 ・全件取得 Result<Object> selectAllResults = r.table( "sales" ).run(connection); selectAllResults.forEach(e -> /* Do something. */ ); 単純にテーブルを指定して run するだけです。 戻り値の Result<Object> を回せば、各ドキュメント内容を個別に処理できます。 もちろん、Streamにも対応しています。 次は、特定の項目だけフィルタして取得してみます。 ・特定の項目だけ取得 Result<Object> selectFilteredResult = r.table( "sales" ) .filter(e -> e.g( "payment" ).eq( "cash" )) .run(connection); selectFilteredResult.forEach(e -> /* Do something. */ ); filter に条件を指定します。 ここでいう filter は Java のStreamのものではなく、ReQL独自のものです。 上記の例では、 payment が cash に合致するものだけを取得するようにしています。 取得後の イテレーション も全件取得と同じです。 なお、UPDATEのときのように、GETでPKを指定してドキュメントを取得することも可能です。 DELETE 最後にDELETEをしてみます。まずは簡単な全件削除から。 ・全件削除 r.table( "sales" ).delete().run(connection); テーブルを指定して、 delete を呼ぶだけという非常に簡素で直感的な作りです。 挙動としてはTRUNCATEみたいなものですね。 次に条件にマッチしたドキュメントだけ削除してみます。 ・特定の項目だけ削除 r.table( "sales" ) .filter(e -> e.g( "price" ).gt( 200 )) .delete() .run(connection); やはりここでも、 filter を使って条件を指定します。 上記では price が200超のものだけが削除されます。 Change Feeds さて、ここまで基本的な操作をみてきましたが、やりたいのはそんなことじゃなくて、リアルタイム機能の中核であるChangeFeedsです。 Change Feedsは、RethinkDBにおけるリアルタイム機能の中核をなすものです。 テーブルやドキュメント、あるいは特定のクエリの結果などの変更を、その都度クライアントが受け取ることができます。 ほぼすべてのReQLクエリがChange Feedsの処理対象にできるようです。 早速、変更を受け取る側のコードを組んでみましょう。 ・Change Feeds（サブスクライブ側） Result<Object> changeFeeds = r.table( "sales" ).changes().run(connection); for (Object change : changeFeeds) { // Do something with change feeds. } そう、たったこれだけです。 あとはループの中でやりたいことを記述すれば終わりなのです。 上記の例では、 sales テーブルに何らかの変更が入る都度ループ内の処理が実行されます。 このループ部分はそのままだと永久に終わらないので、ループの後かつ外に記述した処理はそのままでは実行されません。 この手の機能を使う場合、通常は稼働する限り変更を受け取って処理しようとするのでそれで問題はありませんが、任意のタイミングで止めたいようなケースでは何らかの方法でループを抜け出すように手を加える必要があります。 いじってみた感想 ここまで、RethinkDBの基本的な使い方とChangeFeedsについてみてきました。 ReQLは癖がなく記述しやすい印象を受けました。 あと、ChangeFeedsによる変更の受け取りが極めて楽なことには驚きました。 NoSQLは数も多くそれぞれ得手不得手が分かれるので、うまいことハマる ユースケース があったら採用してみたいところですね。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、技術広報の yayawowo です。 株式会社 ラク スは、継続して技術イベントを開催し日々の業務で培った技術コンテンツの発信を行っております。 有難いことに、 connpass 上で開催しているイベント参加者は、延べ年間1万人を超えており、多くのエンジニア/デザイナーの皆様からも反響をいただいております。 そして・・・今回ついに！ その集大成として2/8(火)に 「 RAKUS Tech Conference2022 」 を開催させていただきます！ ◆こんな方にオススメ！ ・ ラク スの開発における挑戦や現状の課題、今後のビジョンを知りたい方 ・ ラク スの開発組織戦略/インフラ戦略を知りたい方 ・ 新技術を取り入れたい方（フロンエンド分離,React.js,TypeScript,GraphQL) ・ レガシーシステム のバージョンアップ対応をされる方（PHP8,Laravel） ・ モダンな開発スタイルとハイブリッドなアプローチ方法に興味がある方 ・ オンプレ環境における Kubernetes 導入の難しさを知りたい方 などなど 本ブログでは、 RAKUS Tech Conference2022 の見どころだけでなく、 現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術情報してきた、 ラク スMeetupの発表実績をまとめさせていただきました！ 是非ご確認ください！ RAKUS Tech Conference 2022 RAKUS Tech Conference 2022の見どころ 開催概要 タイムテーブル 参加申込方法・申込特典 参加申込はこちら 申込特典のご案内 活動実績 2018年度 2019年度 2020年度 2021年度 2021年度最後のラクスMeetup 最前線エンジニア達が語るSaaS開発の裏話／API連携、自動化、インフラ さいごに RAKUS Tech Conference 2022 RAKUS Tech Conference2022 は ラク スが初めて開催するオンラインテックカンファレンス です！ ラク ス開発組織は「顧客をカスタマーサクセスに導く圧倒的に使いやすい SaaS を創る」というミッションを掲げ、 お客さまに必要とされる高品質な SaaS を生み出すべく開発に取組んでおります。 contents.rakus.co.jp RAKUS Tech Conference 2022の見どころ ラク スは「ITサービスで企業の成長を継続的に支援します」をミッションに掲げ、 メール共有・管理システムのメールディーラーや、経費精算システムの楽楽精算など、 延べ70,000社を超えるお客様に自社開発した クラウド サービスを提供しています。 今回の「 RAKUS Tech Conference2022 」では、開発本部の開発マネージャーやテッ クリード が、 日々の業務で培った技術コンテンツの発信を多数予定しております。 大規模 SaaS に携わる業務の中での課題や教訓が、 SaaS 開発に携わる方の一助となれば幸いです！ 開催概要 日時　：2022/2/8(火) 14:00-18:00 会場　：オンライン 参加費：無料 主催　： 株式会社ラクス Twitter ハッシュタグ ： #RAKUSTechCon タイムテーブル 発表内容の詳細につきましては、 イベント公式ページ も合わせてご確認ください。 開始時間 タイトル 登壇者 14:00 オープニング 執行役員 開発本部長 公手 真之 14:30 楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから 第三開発部長 間澤 創 楽楽精算開発2課 マネージャー 森山 純 楽楽精算開発3課 マネージャー 稲垣 剛之 15:00 トラブルゼロで乗り切ったTypeScript移行 楽楽明細開発課 テッ クリード 三田 英一 15:30 息の長いサービスのPHP8バージョンアップで見えた課題と解決法 楽楽販売開発課 エンジニア 頓花 貴俊 16:00 進化を止めない、"レガシー"との向き合い方 第四開発部長 矢成 行雄 16:30 SaaS マルチヒット メーカー ラク スのインフラ戦略 インフラ開発部 副部長 金本 宏司 17:00 クロージング 執行役員 開発本部長 公手 真之 ※発表内容、タイムテーブルなどは変更となる場合がございますのでご了承ください 参加申込方法・申込特典 参加申込はこちら イベントへの申し込みは、以下3つのいずれか経由でお申込みください！ RAKUS Tech Conference 2022 公式サイト 申込フォーム RAKUS Tech Conference 2022 connpass 申込フォーム RAKUS Tech Conference 2022 TECHPLAY 申込フォーム 申込特典のご案内 RAKUS Tech Conference 2022のイベント アーカイブ 動画を後日配信させていただきます！ 当日参加できない方も対象です。 活動実績 株式会社 ラク スでは、現場最前線のエンジニア達から普段の活動や開発・運用で得た知見などの技術発信の場として ラク スMeetup を開催してきました。 2018年～2021年までの実績をまとめましたので、見逃してしまった方は必見です！ また、当日の雰囲気を楽しんでいただくためのコンテンツとして、公式 Youtube チャンネルにて アーカイブ 動画を公開しております。合わせてご確認ください。 2018年度 ◆ Rakus Meetup Tokyo #1 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #1 tech-blog.rakus.co.jp 2019年度 ◆ Rakus Meetup Tokyo #2 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #2 tech-blog.rakus.co.jp ◆ Rakus Meetup Tokyo #3 tech-blog.rakus.co.jp ◆ Rakus Meetup Osaka #3 tech-blog.rakus.co.jp 2020年度 ◆ SaaS を支える品質担保術/レガシーコード、 アーキテクチャ 、EOL tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS を支える開発原則/DDD、 心理的 安全性、Twelve-Factor tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS 開発リーダーが実践する開発速度向上プ ラク ティス/海外拠点、 スクラム 、時間管理 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ 大規模 SaaS 、レガシーを吹き飛ばすPHPer実践テクニック / 自動化、機械化、静的解析 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS 新規プロダクトの技術 / フロントエンド、RESTful、 AWS サービス、テスト自動化 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ 持続可能な大規模 SaaS 企業の開発戦略/IaC、技術的負債、オブジェクトストレージ、デリバリー tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ SaaS プロダクトのフロントエンド／Vue.js、React、TypeScript、E2Eテスト tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ PM・ リファクタリング 戦略 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be ◆ PdM・インフラ戦略 tech-blog.rakus.co.jp 【 Youtube 】 youtu.be 2021年度 ◆ 10年以上続く SaaS プロダクトの開発戦略／オール仮想化、E2Eテスト、 リファクタリング tech-blog.rakus.co.jp ◆ SaaS 新規プロダクト開発のプ ラク ティス／ アーキテクチャ 、 AWS 、技術選定、技術的負債 tech-blog.rakus.co.jp ◆ SaaS を支える開発戦略・マネジメント／GraphQL、Flutter、大規模チーム開発、 スクラム tech-blog.rakus.co.jp ◆ 大規模 SaaS のフロントエンド開発／レガシー改善、Vue.js、マルチブラウザ対応 tech-blog.rakus.co.jp ◆ 急成長 SaaS の生産性向上戦略／オフショア、SRE、属人化対策 tech-blog.rakus.co.jp ◆ 大規模 SaaS を支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE tech-blog.rakus.co.jp 2021年度最後の ラク スMeetup 最前線エンジニア達が語る SaaS 開発の裏話／ API 連携、自動化、インフラ rakus.connpass.com 3月開催の ラク スMeetupは、新卒ルーキーから主力となったメンバーたちが『最前線の現場とキャリア』について語ります。 内容 登壇者 インフラエンジニアとしての成長記 大阪インフラ開発課／前川 侑輝 右も左も分からない1年目が上流工程を理解するまでの話 楽楽精算開発2課／永田 光一 入社して3年間で『Rundeck』を使って自動化した「面倒」な作業たち 東京インフラ開発3課／金森 聖人 入社してから1～4年目までに経験した課題や教訓を発信し、大規模 SaaS の開発に携わりたい方や、 ラク スの技術領域ご興味をお持ちの学生・若手エンジニアの一助となれば幸いです。 たくさんのご参加をお待ちしています！ さいごに ラク スの技術イベントはいかがでしたでしょうか？ 今回冒頭でお伝えした「RAKUS Tech Conference 2022」は ラク スMeetupとは異なり、 あまり表にでてこない開発本部長や、東京・大阪の開発/インフラのTOP、テッ クリード から若手までが登壇する大型イベントとなります。 大注目のイベントとなりますので、申込だけでもよろしくお願いいたします！ 申し込みはこちら 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

本稿では、 ベトナム とのオフショア開発において利用できるよう、"リーダブルコード" の内容をもとに筆者が解釈したものを、社内用資料として日本語と ベトナム語 の両方で解説したものです。 *1 この記事を日本チームと ベトナム チームのメンバに読んでもらうことで、"リーダブルコード" の知識がチーム間の共通認識となり、プログラムコードの品質が向上することを目的としています。 全2回を予定しており、第1回である本稿は、「表面上の改善」について解説します。 Trong bài post này, tôi sẽ tóm tắt nội dung của "Readable code" và giải thích bằng cả tiếng Nhật và tiếng Việt, để có thể sử dụng trong việc phát triển Offshore với Việt Nam. Khi team Nhật Bản và team Việt Nam đọc bài viết này, sẽ có cách hiểu chung về kiến ​​thức "Readable code" giữa các team và hướng tới mục đích là để nâng cao chất lượng program. Dự định tổng cộng là có 3 chương, và bài post này là Chương 1, giải thích về "Cải thiện về mặt hình thức". 記事一覧 第1回 表面的な改善 / Cải thiện về mặt hình thức 第2回 ループとロジックの単純化 / Đơn giản hóa Loops and Logic INDEX はじめに / Lời nói đầu コード品質の問題点 / Điểm vấn đề về chất lượng code コード品質向上を目指して / Hướng tới mục đích nâng cao chất lượng code この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Dưới dạng là ngôn ngữ chung trong team ベトナムでの学習資料として / Dưới dạng tài liệu học ở Việt Nam リーダブルコードについて / Về readable code 1. "見た目" を整えるテクニック / 1. Techniques điều chỉnh "giao diện" 1-1. Consistent Line Breaks and Indents 1-2. Grouping of Code 1-3. Meaningful Order 2. 命名のテクニック / 2. Naming technique 2-1. Not Use Too Generic Names 2-2. Specific Words 2-3. Attaching Information to a Name 2-4. Not Use Abbreviations 2-5. Choice Easy Word 3. コメントのテクニック / 3. Technique về comment 3-1. Comments at Correct Situation 3-2. Recording Your Thoughts 3-3. Add Comment on Constants 3-4. Avoid Ambiguous Pronouns 3-5. Write Examples 3-6. Named Arguments 3-7. Use PHPDoc おわりに / Lời kết ベトナム メンバと理解する「 PHP リーダブルコード」 〜第1回 表面的な改善〜 「 PHP Readable code」hiểu được cùng với member Việt Nam 〜Chương 1 Cải thiện về hình thức〜 はじめに / Lời nói đầu 私 Y-Kanoh は、ここ3年ほど ベトナム にある ラク スの子会社 RAKUS Vietnam とのオフショア開発に携わっています。 私が所属しているチームでは、国内での開発ももちろん行いますが、要件が固まった後の設計から実装、テストまで ベトナム のチームへ依頼することが多く、サービス開発にとって欠かせない存在です。 また、我々のチームでは、オフショア開発でよく言われれる言語や文化の違いによる認識齟齬や、大きな品質低下は少なく、むしろ一部のメンバは日本のメンバよりシステムの理解が深い場合もあるほどです。 しかしながら、この数年でいくつか課題も見えてきました。 その一つが「コード品質」です。 Tôi là Y-Kanoh đã tham gia vào Offshore development với Việt Nam tại Rakus trong khoảng 3 năm qua. RAKUS Vietnam Tất nhiên là tôi cũng phát triển trong nước (tại Nhật) với team mà tôi đang trực thuộc, nhưng chúng tôi thường nhờ Team Việt Nam từ phase thiết kế sau khi đã xác định yêu cầu đến implement và test, và việc phát triển ở Việt Nam đối với phát triển service là sự tồn tại không thể thiếu. Ngo ài ra, trong team của chúng tôi, có rất ít mâu thuẫn về cách hiểu hay sự suy giảm chất lượng lớn bởi sự khác biệt về ngôn ngữ và văn hóa mà thường được cho là vì Offshore development, ngược lại còn có một số member có thể hiểu sâu về hệ thống hơn các member Nhật Bản ... Tuy nhiên, trong vài năm gần đây, chúng tôi cũng nhìn thấy một vài vấn đề. Một trong số đó là "chất lượng code". コード品質の問題点 / Điểm vấn đề về chất lượng code ラク スの ベトナム メンバは品質に関する意識がとても高く、バグを含まないコードを作成していただけてはいるのですが、コードの "保守性" については日本との認識の違いを感じる場面があります。 これは、大きく以下の2点に問題があると考えています。 Các member Việt Nam của Rakus có ý thức rất cao về chất lượng, và đã có thể tạo ra code không có bug, nhưng về "tính bảo trì" của code, đôi khi tôi cảm thấy có sự khác biệt trong cách hiểu với Nhật Bản. Tôi nghĩ rằng điều này có 2 vấn đề chính sau đây. 一つ目は、 日本からフィードバックがしづらい という点です。 弊社では、 ベトナム チームとのコミュニケーションを通訳の方を介することで行っています。通訳の方々にはいつもスピーディに翻訳をしていただいていますが、日本からコードの修正を依頼する場合、【修正を依頼 → 翻訳作業 → ベトナム メンバによる修正 → 翻訳作業 → 修正結果を日本へ提出】 と、時間的なコストがかかってしまうため、修正依頼を躊躇してしまうことあります。（スケジュールに余裕がないときは特に...） 仕様通りにコードは動いているのでバグは生じていませんが、フィードバックを行わなければ、 ベトナム メンバにどのようなコードが保守性が高く、読みやすいのかを伝える機会が減ってしまいます。 また、日本での実装時にはベテランの開発者が画面を指し示し、時には実装者の隣でコードを書きながら「良いコードとはなにか」を伝えることができますが、遠隔地である ベトナム のメンバとはそれができません。同じオフィスで働いていれば、こまめに声かけをして悩んでいる部分にアド バイス を出しながら実装を進めることができますが、 ベトナム での開発時は、遠隔地ゆえに詳しい状況がわからず、コードの実装やテストが終わって日本へ成果物が送られてきた時には、すでに良くない書き方で全てのコードが出来上がった状態であり、修正を依頼するには遅すぎる状態になってしまいます。 Đầu tiên là rất khó để đưa ra Feedback từ phía Nhật . Tại công ty chúng tôi, việc giao tiếp với team Việt Nam được thực hiện thông qua phiên dịch viên. Phiên dịch viên luôn dịch nhanh chóng cho chúng tôi, nhưng khi có yêu cầu chỉnh sửa từ phía Nhật, nếu [Yêu cầu chỉnh sửa → Thực hiện dịch → Member Việt Nam chỉnh sửa → Thực hiện dịch → Gửi kết quả chỉnh sửa cho phía Nhật], thì sẽ làm tốn cost về mặt thời gian, vì vậy đôi khi bị ngại yêu cầu chỉnh sửa. (Đặc biệt là khi schedule không cho phép...) Vì code vẫn đang hoạt động đúng theo specification nên không xảy ra bug, nhưng mà nếu không thực hiện feedback, sẽ làm giảm cơ hội nói cho member Việt Nam biết code như thế nào là có tính bảo trì cao và dễ đọc. Ngo ài ra, khi implement ở phía Nhật, các developer kỳ cựu có thể vừa chỉ vào màn hình và đôi khi ở bên cạnh implementer, vừa viết code vừa chỉ cho biết “thế nào là good code”, nhưng đối với member Việt Nam nơi xa xôi, thì không thể làm điều đó. Nếu làm cùng văn phòng, có thể thường xuyên gọi nhau, vừa đưa ra advice cho phần đang lo lắng, vừa tiến hành implement, nhưng khi phát triển ở Việt Nam, thì không biết tình hình chi tiết vì xa xôi, khi implement hay test code xong và thành phẩm được gửi cho phía Nhật, thì sẽ ở trạng thái tất cả các code đã được hoàn thành theo cách viết không tốt và sẽ quá muộn để yêu cầu chỉnh sửa. 二つ目の理由は、 ベトナム における学習のしづらさ です。 以前、私が ベトナム に行った時、現地のメンバは学習に英語の書籍を使っていると聞きました。 ベトナム では日本のように技術書が翻訳されて販売されていることがまだ少なく、開発者の スキルアップ のためには英語での学習が必須だそうです。 私は英語が全く読めないので、私が英語でのみの学習をしなければいけない状態になったとしたら、スキルの上達はほぼ見込めなくなると思います 笑 ベトナム のメンバは少なくとも私より英語が得意ですが、やはり母国語でない言語での学習は負荷が高いのではないのでしょうか。 Lý do thứ hai là khó khăn trong việc học ở Việt Nam . Trước đây, khi tôi sang Việt Nam, tôi có nghe nói rằng các member ở đây sử dụng sách tiếng Anh để học. Ở Việt Nam, sách kỹ thuật mà được dịch và bán như ở Nhật Bản vẫn rất ít, để nâng cao kỹ năng của các developer dường như là bắt buộc phải học bằng tiếng Anh. Tôi thì hoàn toàn không thể đọc tiếng Anh, vì vậy nếu tôi chỉ học bằng tiếng Anh, thì tôi nghĩ là gần như không thể mong đợi nâng cao được kỹ năng của mình ( lol ) Các Member Việt Nam ít nhất cũng giỏi tiếng Anh hơn tôi, nhưng việc học bằng ngôn ngữ không phải tiếng mẹ đẻ có thể là một gánh nặng không phải sao. コード品質向上を目指して / Hướng tới mục đích nâng cao chất lượng code これらの問題を解決するために、日本からのフィードバックがやりやすくなり、かつ ベトナム メンバが簡単に習得できるよう、有名な書籍「リーダブルコード」の内容をまとめ、 ベトナム語 に翻訳し、 ベトナム チームに共有することにしました。 せっかくまとめるのであれば、ブログで公開することで他のオフショア開発を行なっているチームにも活用してもらえるかもしれないとの思いから、本記事を書くにいたります。 また、 ラク スのブログで公開するにあたり、サンプルコードは我々の強みでもある PHP で記載することにしました！ 翻訳した文章も載せると、ブログの本文がかなりの文字量になってしまいます。そのため書籍の内容を3回に分けて解説します。 Để phía Nhật dễ feedback hơn và các member Việt Nam có thể học một cách dễ dàng, chúng tôi đã tổng hợp nội dung của cuốn sách nổi tiếng “Readable Code”, dịch sang tiếng Việt và chia sẻ cho team Việt Nam. Nếu đã cất công tổng hợp, thì tôi sẽ viết bài này và xuất bản trên blog, vì tôi nghĩ rằng các team đang phát triển offshore khác cũng có thể sử dụng được. Ngo ài ra, tôi đã quyết định là khi xuất bản trên blog của Rakus, sẽ viết sample code bằng PHP là thế mạnh của chúng tôi! Nếu post cả văn bản đã dịch, thì văn bản của blog sẽ có một lượng ký tự khá lớn. Vì vậy, tôi sẽ chia nội dung của cuốn sách làm 3 phần để giải thích. この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Dưới dạng là ngôn ngữ chung trong team 各テクニックを日本語と ベトナム語 の両方で記述しています 各テクニックには、英語での名称をつけています 日本も ベトナム も使える英語のテクニック名があることで、フィードバック時に指し示しやすくなります 英語名は原著をもとに、簡易な単語を利用しています フィードバックや議論時に、この記事のリンクを貼るとさらに伝わりやすくなります Mô tả từng technique bằng cả tiếng Nhật và tiếng Việt Từng technique sẽ có đặt tên bằng tiếng Anh Khi có technique name tiếng Anh mà phía Nhật và Việt Nam đều có thể sử dụng, thì sẽ dễ dàng chỉ ra hơn khi feedback Tên tiếng anh sẽ dựa trên bản gốc và sử dụng từ đơn giản Khi feedback hoặc thảo luận, nếu gắn link của bài viết này thì sẽ dễ truyền đạt hơn Sample 1： [Japanese] ここの関数名は分かりづらいです。「2-2. Specific Words」を意識しましょう [Vietnamese] Tên hàm ở đây bị khó hiểu. Hãy lưu ý「2-2. Specific Words」 https://tech-blog.rakus.co.jp/entry/20220201/ReadableCodeWithVietnam01#2-2-Specific-Words Sample 2： [Japanese] この定数は何を示しているのかコメントを残して欲しいです。 詳しくはこちらの「3-3. Add Comment on Constants」を参照してください。 [Vietnamese] Tôi muốn là để lại comment rằng constant này chỉ điều gì. Về nội dung chi tiết thì hãy tham khảo「3-3. Add Comment on Constants」ở đây https://tech-blog.rakus.co.jp/entry/20220201/ReadableCodeWithVietnam01#3-3-Add-Comment-on-Constants ベトナム での学習資料として / Dưới dạng tài liệu học ở Việt Nam ベトナム語 に翻訳しているため、 ベトナム の方でも読みやすいはずです プロジェクトに参画した ベトナム メンバの学習資料として利用できます Vì có dịch sang tiếng Việt nên chắc là đối với người Việt cũng sẽ dễ đọc Có thể sử dụng làm tài liệu học cho member Việt Nam tham gia vào project リーダブルコードについて / Về readable code www.oreilly.co.jp The Art of Readable Code リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック 有名なより良いコードを書くためのテクニックがまとめられた書籍です。上記の通り、日本語の翻訳本があります。 この記事では、この"リーダブルコード"の内容を、解釈して ベトナム語 に翻訳しています。 Readable Code là Technique đơn giản và mang tính thực tiễn để viết code tốt hơn Đây là cuốn sách nổi tiếng và tổng hợp technique để viết code tốt hơn. Như đã nói ở trên là có bản dịch tiếng Nhật. Trong bài viết này, tôi sẽ tổng hợp, điều chỉnh nội dung “readable code” này và dịch sang tiếng Việt. それでは、さっそくいきましょう！！ Vậy thì, cùng bắt đầu ngay thôi nào！！ 1. "見た目" を整えるテクニック / 1. Techniques điều chỉnh "giao diện" コードは"動けばいい"ものではありません。 コードを作成したのちに、保守運用を行うのは私たちです。そのためには、できるだけ他の編集者や未来の自分が読みやすいコードであることに気を配るべきです。 Code không phải "chỉ cần hoạt động là được". Sau khi viết code, chúng ta cần vận hành và bảo trì nó. Để làm được điều đó, cần phải lưu ý rằng phải là code càng dễ đọc càng tốt cho developer khác cũng như cho chính mình trong tương lai. 例えば、プログラムコードではなく、雑誌を想像してください。 雑誌では、読み手が読みやすく、重要なことはすぐ目に着くよう、余白や配置、情報のグルーピングに気を使って紙面が設計されています。 Ví dụ, hãy tưởng tượng là một tạp chí, chứ không phải program code. Trong tạp chí, trang giấy được thiết kế với sự chú ý đến margin, bố trí và grouping thông tin để người đọc dễ đọc và những điều quan trọng sẽ được chú ý ngay lập tức. プログラムコードも同じで、次の開発者が誤解なくスピーディに修正が行えるよう、レイアウトには気を配るべきです。 まずはこの「コードの見た目」を整えるためのテクニックを紹介します。 Program code cũng vậy, cần phải chú ý bố cục để các developer tiếp theo không bị hiểu nhầm và có thể chỉnh sửa nhanh chóng. Trước hết, tôi sẽ giới thiệu technique để điều chỉnh "giao diện của code" này. 1-1. Consistent Line Breaks and Indents 統一された改行とインデント Ngắt dòng và thụt lề đã được thống nhất #見た目 #インデント #改行 #統一感 #HìnhThức #Indent #NgắtDòng #CảmGiácThốngNhất 以下のように、インデントがあっていないコードは読みづらくなってしまいます。 見やすくチームで決められたインデントをつけましょう。 Code không có thụt đầu dòng sẽ khó đọc, như dưới đây. Hãy thụt đầu dòng đã được quyết định theo nhóm cho dễ nhìn. ❌ Bad Code <?php class Task { public $ taskName ; public $ status ; private $ user ; private $ deadline ; public function __constractor ( $ name , $ user ) { $ this -> taskName = $ name ; $ this -> user = $ user ; } } 同じように、改行位置も周りと合わせなければ読みづらくなってしまいます。 以下の場合、 toManagerMail のみ改行位置がおかしいので、同じ インスタンス が作成されていることに気づきにくくなっています。 Tương tự, nếu vị trí ngắt dòng cũng không phù hợp với xung quanh, thì sẽ rất khó đọc. Trong trường hợp sau đây, chỉ có toManagerMail có vị trí ngắt dòng bị kỳ cục, vì vậy rất khó để nhận thấy rằng instance tương tự đã được tạo. ❌ Bad Code <?php $ toUserMail = new createMailObject ( $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; $ toCustomerMail = new createMailObject ( $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; $ toManagerMail = new createMailObject ( // Tại sao chỉ có ngắt dòng ở đây?? なぜここだけ改行されてる?? $ subject , $ toAddress , $ fromAddress , $ header , $ body , $ attach ) ; 1-2. Grouping of Code コードのグループ化 Code grouping #見た目 #HìnhThức コードを読む時、コードが意味のある「グループ」にわかれていると読みやすいです。 文章や報告書を作成する時、内容によって段落を分けたり改行を入れたりすることと一緒です。 Khi đọc code, sẽ dễ đọc hơn nếu code được chia thành các "group" có ý nghĩa. Nó cũng giống như việc khi tạo một câu văn hay báo cáo, phải tách đoạn văn và ngắt dòng tùy theo nội dung. ❌ Bad Code <?php function suggestNeverUseRecipes ( $ userId ) { // Lấy recipe (công thức) mà user đã từng tạo và so sánh với recipe đã đăng ký // Sau đó, hiển thị recipe mà chưa từng làm // ユーザが作ったことがあるレシピを取得し、登録されているレシピと比べる // その後、まだ作ったことないレシピを表示する $ user = new User ( $ userId ) ; $ recipeList = $ user -> getMadeRecipeList () ; $ recipeBook = new RecipeBook () ; $ allRecipeList = $ recipeBook -> getAllRecipeList () ; $ suggestRecipeList = array_diff_key ( $ allRecipeList , $ recipeList ) ; $ display [ "user" ] = $ user ; $ display [ "suggestRecipeList" ] = $ suggestRecipeList ; return render ( "sugestRecipe.html" , $ display ) ; } ✅ Good Code <?php function suggestNeverUseRecipes ( $ userId ) { // Lấy recipe mà user đã từng tạo // ユーザが作ったことがあるレシピを取得 $ user = new User ( $ userId ) ; $ recipeList = $ user -> getMadeRecipeList () ; // Lấy tất cả các recipe // 全てのレシピを取得 $ recipeBook = new RecipeBook () ; $ allRecipeList = $ recipeBook -> getAllRecipeList () ; $ suggestRecipeList = array_diff_key ( $ allRecipeList , $ recipeList ) ; // Xử lý hiển thị màn hình // 画面表示処理 $ display [ "user" ] = $ user ; $ display [ "suggestRecipeList" ] = $ suggestRecipeList ; return render ( "sugestRecipe.html" , $ display ) ; } 書いてあるコードが一緒ですが、グルーピングをすることで理解しやすくなりました。 また、グループごとにコメントを入れると、さらにわかりやすくなります。 Code được viết là giống nhau, nhưng nó sẽ trở nên dễ hiểu hơn khi grouping lại. Ngo ài ra, nếu thêm comment cho từng group thì sẽ dễ hiểu hơn nữa. 1-3. Meaningful Order 意味のある順番を選ぶ Chọn thứ tự có ý nghĩa #見た目 #順番 #HìnhThức `#ThứTự ロジックに影響を与えなくても、コードを記載する順番は揃えた方がいいでしょう。 いくつかのデータを同じ処理で処理する場合、場所によって順番が違うと、理解の妨げになります。 以下の例では、 $mailaddress がどこにあるのか不思議に思った時点で、脳のリソースが余計なことに使われてしまっています。 Ngay cả khi không ảnh hưởng đến logic, cũng nên canh chỉnh thứ tự mô tả code sẽ tốt hơn không phải sao? Khi xử lý một số dữ liệu trong cùng một xử lý, nếu thứ tự khác nhau tùy vào vị trí, thì sẽ rất khó hiểu. Trong ví dụ dưới đây, khi phải thắc mắc, suy nghĩ xem $mailaddress nằm ở đâu, thì bạn đang sử dụng chất xám lãng phí. ❌ Bad Code <?php $ userName = $ request -> ( "userName" ) ; $ mailaddress = $ request -> ( "mailaddress" ) ; $ phonNumber = $ request -> ( "phonNumber" ) ; $ zip = $ request -> ( "zip" ) ; $ location = $ request -> ( "location" ) ; : : : if ( $ userName === "" ) { $ errorMessage [] = USER_NAME_EMPTY_ERROR; } if ( $ phonNumber === "" ) { // Ủa? $mailaddress đâu? あれ? $mailaddress は? $ errorMessage [] = PHONE_NUMBER_EMPTY_ERROR; } if ( $ zip === "" ) { $ errorMessage [] = ZIP_EMPTY_ERROR; } if ( $ location === "" ) { $ errorMessage [] = LOCATION_EMPTY_ERROR; } if ( $ mailaddress === "" ) { // Thì ra là ở chỗ này !! こんなところにあった!! $ errorMessage [] = MAILADDRESS_EMPTY_ERROR; } 2. 命名 のテクニック / 2. Naming technique 変数や関数、クラスなど、コード内に記載される "名前" は、"短いコメント" と考えるべきです。 しかし、名前をつけた本人は「わかりやすい」と思っている名前でも、他の人にとってはわかりづらい場合も多いのではないでしょうか。 そのため、常に他者にとって理解の助けになる名前になっているかを考えて名前をつける必要があります。 "Tên" được ghi trong code, chẳng hạn như biến, hàm và class, nên được coi là "comment ngắn". Tuy nhiên, cho dù nó là cái tên mà người đặt tên cho rằng nó "dễ hiểu" thì cũng có khi khó hiểu đối với người khác không phải sao? Vì vậy, cần phải luôn xem xét đặt tên xem liệu cái tên đó có giúp người khác hiểu được hay không. 2-1. Not Use Too Generic Names 一般的すぎる単語を使わない Không sử dụng từ ngữ quá chung chung #命名 #英語 #Naming #English 前述した通り、変数名/関数名は、ある種のコメントです。 いい名前がついていた場合、そのコードを読む人のヒントになります。 コードを書くときに 命名 を考えない場合、次回そのコードを読む人はヒントなしでコードを解読する羽目になります。 わざわざチームメンバや未来の自分にハードモードのステージを用意する必要はありません。 Như đã đề cập trước đó, tên biến/hàm là một loại comment. Nếu gắn một cái tên hay, thì nó sẽ là hint (gợi ý) cho người đọc code đó. Nếu không xem xét đến việc đặt tên khi viết code, người tiếp theo đọc code sẽ rơi vào tình thế đọc code mà không có gợi ý nào. Không cần phải mất công chuẩn bị một cái gì đó quá khó cho các member trong team hoặc chính mình trong tương lai. 以下のような単語は、 命名 をサボったようなものです。 あまりに抽象的で、なにをするための変数名、もしくは関数名なのかわかりません。 このような名前を使いそうになったら、もっと目的に適した具体的な名前があるはずなので、名前をしっかり考えましょう。 もし、どうしても使いたい場合は、スコープが短く、誰が見ても用途が明らかな場合にのみ使用するようにするべきです。 Những từ ngữ như sau đây giống như là lười biếng, tránh né đặt tên. Nó quá trừu tượng nên không biết tên biến hoặc hàm dùng để làm gì. Nếu có vẻ như bạn đang sử dụng một cái tên như vậy, thì chắc là cần có một cái tên cụ thể hơn cho mục đích đó, vì vậy hãy xem xét tên thật kỹ. Nếu thực sự muốn sử dụng nó, thì chỉ nên sử dụng khi phạm vi ngắn và dù ai xem cũng hiểu rõ được công dụng. ❌ Bad Code <?php $ tmp // ... mang tính tạm thời, là cái gì? // 一時的な...なに？？ $ myForm // Bằng với là không có thông tin “my form” // "私のフォーム" 情報が無いに等しい $ retval // Không có thông tin nào ngoài “Giá trị trả về”. Không cần đặt tên biến cũng biết // "戻り値"以外の情報がない。変数名にしなくてもわかる $ i , $ j , $ k // Loop iterator. Chắc là có một cái tên hay hơn // ループのイテレータ。もっといい名前があるはず $ result // Là kết quả của cái gì. Tôi muốn thêm một vài từ // なにかの結果。もう一言欲しい。 2-2. Specific Words 明確な単語を選ぶ Chọn từ rõ ràng #命名 #Naming 以下のような名前は簡単に思いつくので使いやすいですが、いまいち情報不足です。 Ví dụ như cái tên dưới đây vì rất dễ nghĩ ra trong đầu nên dễ sử dụng, nhưng mà không đủ thông tin lắm. ❌ Bad Code <?php function getPage (){ ... } function setLog (){ ... } function checkMailAddress (){ ... } get や set は、明確に何を行うかがわかりづらくなります。 アクセサ（ getter や setter ）のように、特にルールがなく、もっと処理内容を表現できる単語がある場合は使用を避けるべきでしょう。 get và set khi ến bạn khó biết rõ là thực hiện cái gì. Nên tránh sử dụng nó khi không có rule nhất định, và khi có những từ có thể diễn đạt rõ nội dung xử lý hơn, chẳng hạn như Accessor（ getter và setter ） load や fetch ような単語に置き換えてはどうでしょうか。単にget（取得する）だけではなく、どのように取得するのかが伝わりやすくなる単語です。 また、 get や set は、「何か簡単な、負荷のかからない処理」であるイメージがあると思います。 一方で load と聞くと、何か時間のかかる処理に聞こえませんか？ 命名 をするときには、その名前を見た他の開発者がどういう処理を想像するかを考えることも重要です。 （ get って書いてあるから軽い気持ちで使っていたけど、すごく処理に時間がかかる処理だった！なんて事故を減らしましょう。） Nếu thay thế thành từ như là load hay là fetch thì bạn thấy sao? Không chỉ đơn giản là get (lấy), mà là từ “lấy như thế nào” thì sẽ dễ hiểu hơn. Ngo ài ra, tôi nghĩ là get và set làm cho có hình dung là”một xử lý gì đó đơn giản và nhẹ nhàng”. Mặt khác, khi nghe từ load , thì nghe có vẻ như là xử lý gì đó tốn thời gian không phải sao? Khi đặt tên, “việc mà xem xét làm sao cho các developer khác khi nhìn vào tên đó sẽ tưởng tượng ra xử lý như thế nào” cũng quan trọng. (Vì viết là get sẽ sử dụng với cảm giác nhẹ nhàng, nhưng nó là xử lý mất rất nhiều thời gian để xử lý！Nên hãy giảm thiểu sự cố.) ✅ Good Code <?php function downLoadPage (){ ... } function registerLog (){ ... } function isValidMailAddress (){ ... } 明確に意図が伝わらない例として、たとえば以下のような関数があったとします。 この関数は、 filter の意味が曖昧なので、2つの意味で解釈できてしまいます。 Lấy ví dụ về việc ý định không được truyền đạt rõ ràng, tôi giả sử là có hàm sau đây. Hàm này có thể hiểu theo hai cách vì ý nghĩa của filter bị mơ hồ. ❌ Bad Code <?php function filterMailBySendDate ( $ date ){ ... } 解釈1：メール送信日が $date のメールを取得する 解釈2：メール送信日が $date のメールを除く 解釈1の場合、 select を使った方がいいかもしれません。 また、解釈2の場合は、 exclude を使うことで明確になります。 Cách hiểu 1：Lấy mail có ngày gửi mail là $date Cách hiểu 2：Loại trừ mail có ngày gửi mail là $date Nếu là cách hiểu 1 thì có lẽ là nên sử dụng select Ngo ài ra, nếu là cách hiểu 2, thì sử dụng exclude sẽ rõ ràng hơn. ✅ Good Code <?php function selectMailBySendDate ( $ date ){ ... } function excludeMailBySendDate ( $ date ){ ... } 以下にもう少し意味が伝わりやすくなる単語の例をあげました。 もし、置き換えられる言葉があるのであれば、積極的に置き換えましょう。 Tôi đã nêu ra một số ví dụ về các từ giúp truyền đạt ý nghĩa dễ dàng hơn một chút ở dưới đây. Nếu có từ nào có thể thay thế, thì hãy tích cực thay thế nhé! 曖昧な単語 / Từ mơ hồ 明確な単語 / Từ rõ ràng get, set load, fetch, register, add, store send deliver, dispatch, announce, distribute, route find search, extract, locate, recover start launch, create, begin, open make create, set up, build, generate, compose, add, new check isValid, enable, isEmpty, isSaved, exist filter select, exclude 2-3. Attaching Information to a Name 名前への情報追加 Thêm thông tin vào tên #命名 #Naming 変数名には、できるだけ具体的な名前をつけることで、どのような意図で変数を使うかがわかりやすくなります。 それに加えて、なにか"絶対に伝えないといけない情報"があるのであれば、変数名に付け加えることで事故が少なくなります。 Khi đặt tên cho biến cụ thể hết mức có thể, thì sẽ dễ hiểu bạn định sử dụng biến để làm gì. Thêm vào đó, nếu có "thông tin bắt buộc phải truyền tải" nào đó, thì thêm nó vào tên biến sẽ giảm thiểu được sự cố. 🤷‍♂️ NOT Good Code <?php // Không tệ, nhưng nếu có thể bổ sung thêm thông tin thì nên mô tả // 悪くはないが、もう少し情報を付け加えられるのであれば記載するべき $ password $ comment $ fileSize $ delay $ length $ html ✅ Good Code <?php $ plaintextPassword // Hiểu được rằng nó không được encrypte // 暗号化されていないことがわかる $ escapedComment // Hiểu được rằng nó đã được escape // エスケープされていることがわかる $ fileSizeMb // Hiểu được rằng nó là đơn vị MB // MB単位であることがわかる $ delaySec // Hiểu được rằng nó là đơn vị giây // 秒単位であることがわかる $ widthLength // Hiểu được rằng nó là độ dài chiều ngang // 横の長さであることがわかる $ htmlTextUtf8 // Hiểu được rằng nó là UTF-8 // UTF-8になっていることがわかる $fileSizeMb のように、単位を変数に含めるテクニックはぜひやりたいところです。 コードを遡って、この変数に入っている数値の単位がなんなのか、探すのに時間がかかってイライラしたことはありません？？ Tôi muốn nhất định phải thực hiện một technique bao gồm đơn vị trong biến, chẳng hạn như $ fileSizeMb . Bạn đã bao giờ cảm thấy bực bội vì “mất thời gian quay ngược lại code và tìm đơn vị của giá trị số trong biến này là gì” chưa ?? 2-4. Not Use Abbreviations 略語を使わない Không sử dụng chữ viết tắt #省略 #GiảnLược 具体的に、そしてわかりやすく名前を決めようとすると、どうしても長い名前になってしまいます。 しかし、名前を短くするために、意図が伝わらなくなってしまっては意味がありません。 短い名前の方が見やすくていいかもしれませんが、他の人に伝わる名前にすることを優先して考えましょう。 Nếu bạn định là quyết định một cái tên cụ thể và dễ hiểu, tự nhiên thành ra một cái tên dài. Tuy nhiên, vì rút ngắn tên mà không được truyền đạt được ý đồ thì sẽ không có ý nghĩa gì. Tên ngắn có thể dễ đọc hơn, nhưng hãy ưu tiên cái tên có thể truyền đạt cho người khác. また、同じ理由で無理な略語も避けるべきです。 賛否両論あると思いますが、一般的な開発者なら理解できる uid や dao 、 str 、 env のような単語であればまだ利用しても問題ないかもしれません。 ただし、チームに参画したばかりの開発者が読んでわからないような システム独自の略語 は避けるべきです。 たとえば、以下のような名前です。 Ngo ài ra, vì lý do tương tự, bạn cũng nên tránh những từ viết tắt không hợp lý. Tôi nghĩ là sẽ có 2 luồng ý kiến, nhưng có lẽ vẫn ổn khi sử dụng những từ như uid , dao , str , và env mà một developer bình thường có thể hiểu được. Tuy nhiên, bạn nên tránh các từ viết tắt của riêng hệ thống mà các developer mới join vào team đọc vào sẽ không hiểu được. Ví dụ, như là tên sau đây. ❌ Bad Code <?php $ mBox // Viết tắt của MailBox. Mới nhìn lần đầu sẽ không biết “m” là gì // MailBox の略。初見で"m"が何かわからない $ cUrl // Viết tắt của ClickedUrl // ClickedUrl の略 $ BEManager // Viết tắt của BackEndManage // BackEndManage の略 どこまでの略語が許されて、どこからが許されないかの線引きは難しいと思います。 そのため、私は基本的に「迷ったら略語は利用しない」方針で名前を決めるべきだと考えています。 また、「変数名が長くて入力しづらい」と思うのであれば、略語を使う前に IDE の補完入力を覚えましょう。 Tôi nghĩ rất khó để vạch ra ranh giới giữa việc “được viết tắt đến đâu” và “chỗ nào là không được viết tắt”. Vì vậy, về cơ bản tôi nghĩ rằng nên quyết định tên theo phương châm "nếu phân vân thì không sử dụng chữ viết tắt". Ngo ài ra, nếu bạn nghĩ "tên biến dài và khó nhập", hãy nhớ việc IDE completion input (nhập hoàn thành của IDE ) trước khi sử dụng các từ viết tắt. 2-5. Choice Easy Word 簡単な単語を使う Sử dụng các từ đơn giản #命名 #英語 #単語 #Naming #English #Word ここまで、具体的で明確な単語を使うことを述べてきました。 しかし、いくら具体的でも、難しすぎて意味が通じない単語を選んでは意味がありません。 線引きは難しいですが、必要以上に難しい単語を選ばないようにしましょう。 Đến đây, tôi đã mô tả xong việc sử dụng từ một cách rõ ràng và cụ thể. Tuy nhiên, cho dù cụ thể đến đâu, thì nếu chọn 1 từ quá khó không diễn đạt được ý nghĩa thì cũng không có ý nghĩa gì. Rất khó để phân định ranh giới rõ ràng, nhưng hãy cố gắng không chọn những từ khó hơn mức cần thiết. ❌ Bad Code <?php $ investigateRecipe $ manufactureBook ✅ Good Code <?php $ searchRecipe $ createBook 3. コメントのテクニック / 3. Technique về comment コメントは、そのコードを作成した人が残すことができる未来の開発者へのヒントです。 将来そのコードを修正する他者や自分のため、価値のある情報を記載しましょう！！ Comment là hint mà người viết code đó có thể để lại dành cho developer trong tương lai. Vì người khác hoặc chính mình sẽ chỉnh sửa code trong tương lai, hãy mô tả thông tin có giá trị !! 3-1. Comments at Correct Situation 正しい状況でコメントを使う Sử dụng comment với tình huống đúng #コメント #コメント内容 #Comment #NộiDungComment コメントの目的は、" 書き手の意図を読み手に伝えること " です。 そのため、以下のようなコメントは不要です。なぜなら、コードを読めば すぐに 伝わるからです。 Mục đích của comment là " để truyền tải mục đích của người viết đến người đọc ". Vì vậy, những comment như sau đây là không cần thiết. Bởi vì, nếu đọc code, thì sẽ hiểu ngay lập tức . ❌ Bad Code <?php // Lấy thông tin account // アカウント情報を取得する $ account = new Account ( $ id ) ; // Setting user name cho account // アカウントにユーザ名を設定する $ account -> setUserName ( $ name ) ; // Xóa thông tin account // アカウント情報を削除する unset ( $ account ) ; 以下のように、短いコードでも読んですぐにわからないようなコードであれば、コメントをつけるべきです。 Nếu là code ngắn mà đọc vào không hiểu ngay lập tức được như dưới đây, thì nên thêm comment ✅ Good Code <?php // Biểu thức chính quy để kiểm tra xem số điện thoại có dấu gạch nối hay không // ハイフン付きの電話番号であるかを確認する正規表現 $ phoneNumberReg = "/^[0-9]{2,4}-[0-9]{2,4}-[0-9]{3,4}$/" ; 3-2. Recording Your Thoughts 考えを記録する Ghi lại suy nghĩ #コメント #コメント内容 #Comment #NộiDungComment コードには処理内容を記述することはできますが、コードを書いていたときにあなたが考えていたことまでは記述できません。 そのコードを書いていたときに考えていた内容こそ、コメントに記載して後世に残すべきでしょう。 たとえば、以下のような内容です。 Bạn có thể mô tả nội dung xử lý cho code, nhưng khi viết code bạn không thể viết hết những gì bạn đang suy nghĩ. Những gì bạn đã nghĩ khi viết code nên được đưa vào comment và để lại cho thế hệ sau. Ví dụ, nội dung như sau. ✅ Good Code 注釈としてのコメント / Comment như một chú thích <?php // Xử lý này có tốc độ xử lý nhanh hơn mô tả trong loop // この処理はループで記述するより処理速度が速い また、コードを記載しているうちに、そのコードを触るときに注意すべき点があれば、コメントに記載することで他の開発者が罠を踏むことはなくなります。 Ngo ài ra, trong lúc viết code, nếu có điều gì cần phải lưu ý khi đụng vào code đó, thì bạn có thể viết nó trong comment để các developer khác không bị mắc bẫy. ✅ Good Code 罠の警告 / Cảnh báo bẫy <?php // Xử lý này có sai sót và không nên chỉ định mảng có chứa NULL trong phần tử làm đối số. Tại vì …. // この処理には欠陥があり、要素にNULLを含む配列を引数に指定するべきではない。なぜなら... // Lưu ý rằng xử lý sẽ mất thời gian nếu Nest của tag HTML bị sâu. // HTMLタグのネストが深いと処理に時間がかかってしまうので注意 コードを理解するときに、全体像がわかっていると理解が速くなります。 そのため、コードの最初に以下のような全体像を把握できるコメントを書くべきです。 Khi hiểu code, nếu hiểu được bức tranh tổng thể thì sẽ hiểu nhanh hơn. Do đó, bạn nên viết comment ở đầu đoạn code để có thể nắm được bức tranh tổng thể như dưới đây. ✅ Good Code 全体像の共有 / Share về bức tranh tổng thể <?php // Class này là class trao đổi với service liên kết bên ngoài. // このクラスは外部連携サービスとのやりとりを行うクラスです。 // Class này là code xử lý DB từ business logic. Không được phép gọi từ application. // このクラスはビジネスロジックからDBを扱うコードです。アプリケーションから呼んではいけません // Tạo mảng mà chỉ bao gồm user cần hiển thị // 表示すべきユーザのみが含まれる配列を作成する 3-3. Add Comment on Constants 定数にコメントをつける Thêm comment vào constant #コメント #コメント内容 #定数 #Comment #NộiDungComment #HằngSố いわゆる”マジックナンバ”は良くありません。なぜなら、その数値がなんのための数値かわからないからです。 Nói nôm na là “magic number” không được tốt lắm. Lý do là vì không biết được giá trị số đó là giá trị để làm gì. ❌ Bad Code <?php if ( $ fileSizeMb < 20 ) { // "20" là số gì? "20" ってなんの数字？ return FILE_SIZE_ERROR; } しかし、このマジックナンバを定数にしたところで、あまり解決になっていません。 Tuy nhiên, khi set magic number này thành constant, thì nó vẫn chưa được giải quyết nhiều. ❌ Bad Code <?php const FILE_MAX_SIZE_MB = 20 ; if ( $ fileSizeMb < FILE_MAX_SIZE_MB ) { return FILE_SIZE_ERROR; } たしかに、定数名( FILE_MAX_SIZE_MB )から"ファイルの最大サイズ"であることはわかりますが、なぜファイルの最大サイズが20MBなのかはわかりません。 仕様上決まっているのかもしれませんし、もしかしたらこのシステムではそれ以上のファイルを処理すると問題が発生するのかもしれません。 このような場合、マジックナンバを定数にするだけで満足せず、コメントを残すべきです。 Chắc chắn là có thể biết từ constant name ( FILE_MAX_SIZE_MB ) rằng đó là" size tối đa của file", nhưng không biết được size tối đa của file là 20MB. Có lẽ là đã quyết định trên specification, hoặc có thể sẽ xảy ra vấn đề khi xử lý file lớn hơn trong hệ thống này. Trong những trường hợp như vậy, bạn không nên hài lòng với việc chỉ set magic number thành constant mà nên để lại comment. ✅ Good Code <?php // Size tối đa của file // Nếu đăng ký file lớn hơn, thì sẽ không thể đính kèm vào mail thông báo để gửi cho user. // ファイルの最大サイズ。 // これ以上のファイルを登録すると、ユーザへ送信する通知メールに添付できなくなってしまう。 const FILE_MAX_SIZE_MB = 20 ; if ( $ fileSizeMb < FILE_MAX_SIZE_MB ) { return FILE_SIZE_ERROR; } 3-4. Avoid Ambiguous Pronouns 曖昧な代名詞を避ける Tránh các đại từ không rõ ràng #コメント #コメント内容 #Comment #NộiDungComment 代名詞を使うと、意図を正確伝えづらくなります。 とくに我々は母国語が違うので、代名詞が何を指し示しているのか勘違いして理解することが他の開発現場よりとても多いでしょう。 そのため、代名詞はできるだけ使わず、直接的な表現を心がけましょう。 Nếu sử dụng đại từ thay thế sẽ khi ến bạn khó truyền đạt ý định chính xác. Đặc biệt là vì chúng ta có ngôn ngữ mẹ đẻ khác nhau, nên sẽ có rất nhiều khả năng hiểu sai là “đại từ thay thế đang chỉ cái gì” hơn so với các nơi phát triển khác. Do đó, hãy cố gắng sử dụng cách diễn đạt trực tiếp mà không sử dụng đại từ thay thế càng nhiều càng tốt. 日本のメンバは高校での英語の授業を思い出してください。 よくある「Q.下線部Aの"it"が指し示していることはなんですか？」という問題です。 わざわざ高校英語で出てくる読解問題をコメントに含める必要はありませんよね？？ Các member phía Nhật hãy nhớ lại các buổi học tiếng Anh ở trường trung học. Là vấn đề thường gặp như là "Q."it" trong chỗ A được gạch dưới đang chỉ đến điều gì?". Không cần phải đưa các bài tập đọc hiểu xuất hiện trong tiếng Anh cấp 3 vào phần comment nhỉ ??? ❌ Bad Code <?php // Cho data vào Cache. Trước đó, sẽ xác nhận size đó // データをキャッシュに入れる。その前にそのサイズを確認する ✅ Good Code <?php // Cho data vào Cache. Trước đó, sẽ xác nhận size của data // データをキャッシュに入れる。その前にデータのサイズを確認する ✅ More Good Code <?php // Sau khi xác nhận size của data thì cho data vào Cache // データのサイズを確認してから、データをキャッシュに入れる 余談ですが、私は普段の作業指示書作成時にも代名詞や指示語を使わないようにしています。 ただでさえたくさんの翻訳を依頼している翻訳チームのメンバを、これ以上困らせるわけにいかないので。。。 Tôi xin nói ngo ài lề một chút là, cả khi tạo tài liệu chỉ thị công việc bình thường, tôi cũng cố gắng không sử dụng đại từ thay thế hoặc từ chỉ thị. Vì đã yêu cầu dịch rất nhiều rồi nên không thể làm cho các member của team phiên dịch khó khăn (khó dịch) hơn .... 3-5. Write Examples 入出力の具体例を使う Sử dụng ví dụ cụ thể của in/output #コメント #コメント内容 #Comment #NộiDungComment 無理に言葉を使って説明するより、具体例を書いた方がわかりやすいこともあります。 ましてや我々は母国語が違います。言葉で語らずコードで語った方がわかりやすい時もあります。 Đôi khi , việc viết ra một ví dụ cụ thể sẽ dễ hiểu hơn là cưỡng ép giải thích nó bằng lời. Hơn nữa, chúng ta có ngôn ngữ mẹ đẻ khác nhau. Đôi khi sẽ dễ hiểu hơn nếu nói bằng code thay vì bằng lời. ✅ Good Code <?php /* * Xóa các ký tự có trong $char ở đầu và cuối $targetStr * Sample: trimEachStr("abcabcba", "ab") trả về “cabc” * * $targetStr の先頭や末尾にある $char に含まれる文字を取り除く * Sample: trimEachStr("abcabcba", "ab") は "cabc" を返す * **/ function trimEachStr ( $ targetStr , $ char ) { ... } 3-6. Named Arguments 名前付き引数 Đối số có kèm tên #PHP #コメント #Comment PHP には PHP 8.0 の新機能として 名前付き引数 が採用されました!! 名前付き引数は、引数の位置を指定して引数のデフォルト値の利便性を高めるだけでなく、関数呼び出し元でのコメントとして使うことができます。 PHP đã áp dụng Đối số có kèm tên như một tính năng mới của PHP 8.0 !! Đối số có kèm tên không chỉ có thể chỉ định vị trí đối số và nâng cao tính tiện lợi của giá trị mặc định của đối số, mà còn có thể sử dụng làm comment ở nơi gọi hàm. ❌ Bad Code <?php connect ( 10 , false ) ; // Không hiểu ý nghĩa của 10 và false // 10 と false の意味がわからない : : : // connect の定義元を確認して、やっと 10 と false の意味がわかる // Xác nhận nguồn định nghĩa connect, cuối cùng cũng hiểu ý nghĩa của 10 và false function connect ( $ timeOutSec , $ useEncryption ) { ... } ✅ Good Code <?php // Ngay cả khi không xác nhận nguồn định nghĩa connect cũng hiểu được ý nghĩa // connect の定義元を確認しなくても意味がわかる connect ( timeOutSec : 10 , useEncryption : false ) ; : : : function connect ( $ timeOutSec , $ useEncryption ) { ... } 3-7. Use PHPDoc PHPDocを利用する Sử dụng PHPDoc #コメント #PHPDoc #PHP #Comment PHP は、変数の中にintegerもbooleanも、arrayもすべて入れることができてしまうため、期待していない型が変数に入ってしまうことも多々あります。 意図しない値が変数に含まれてしまう可能性を減らすためには、 IDE とPHPDocを利用します。 PhpStormを使っている場合、関数の引数に、PHPDocで記載されている型と違う値が含まれていると警告を表示してくるなど、PHPDocを使って型指定のサポートを行う機能がたくさん含まれています。 そのため、PHPDocは正確に、漏れなく記載しましょう。 また、近年の PHP では引数や戻り値の型を指定できるようになっています。できるだけ型を指定して、その後の修正によって意図しない値が利用されるリスクを減らしましょう。 Vì PHP có thể đặt tất cả các integer, cả boolean, cả array trong các biến, nên thường xảy ra trường hợp “kiểu không mong muốn” được đưa vào các biến. Sử dụng IDE và PHPDoc để giảm nguy cơ các giá trị không mong muốn được bao gồm trong biến. Khi sử dụng PhpStorm, có rất nhiều chức năng sử dụng PHPDoc để support chỉ định kiểu, chẳng hạn như hiển thị cảnh báo nếu đối số của hàm chứa giá trị khác với kiểu được mô tả trong PHPDoc. Do đó, PHPDoc nên được viết chính xác và không thiếu sót. Ngo ài ra, trong những năm gần đây PHP đã có thể chỉ định đối số và kiểu giá trị trả về. Để giảm nguy cơ sử dụng các giá trị không mong muốn, hãy chỉ định kiểu đối số và kiểu giá trị trả về. おわりに / Lời kết コメントや 命名 にここまでこだわって何になるんだ。と思うかもしれませんが、こうした工夫が仕様変更や追加開発に強い"保守性が高いサービス"を作り出します。 仕様変更や追加開発が行いやすいということは、我々自身が楽しんで開発を行うことにつながります。 特にこの記事で取り上げた内容は、今すぐにでも実践できる内容ばかりですので、サービスの発展のためにも、我々自身が楽しくコーディングをするためにも、ぜひ積極的に実践しましょう!! Có lẽ bạn sẽ nghĩ việc quá để ý chi tiết về comment và naming thì sẽ được gì, nhưng việc đầu tư công phu như vậy sẽ tạo ra một "service có tính bảo trì cao " để dễ thay đổi specification và phát triển bổ sung. Khi dễ thực hiện thay đổi specification và phát triển bổ sung sẽ dẫn đến việc chúng ta thích thú thực hiện phát triển hơn. Đặc biệt là nội dung được đề cập trong bài viết này đều là nội dung có thể thực hành ngay lập tức, vì vậy chúng ta hãy tích cực thực hành để phát triển service và để chúng ta coding một cách thích thú !! さて、次回は「ループとロジックの単 純化 」についてまとめます!! Và sau đây, lần tiếp theo tôi sẽ tóm tắt về "Đơn giản hóa Loop and Logic" !! ◆ ラク スのオフショア開発に関連する記事も、是非ご参考ください！ tech-blog.rakus.co.jp career-recruit.rakus.co.jp RAKUS Vietnam Co.,Ltd Rakus Việt Nam đang tích cực tuy ển dụng kỹ sư ( Java , PHP ) và member QA. Bạn có muốn cùng tạo ra những sản phẩm SaaS với chất lượng như blog này không? Nếu bạn quan tâm, hãy ứng tuy ển nhé. ラク ス ベトナム では、エンジニア( Java , PHP )やQAメンバの採用を積極的に行っています。 このブログのような品質を意識した自社 SaaS プロダクトを一緒に作りませんか？ ご興味ありましたら、是非応募をお願いします。 www.rakus.com.vn エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 原版の翻訳や要約ではありませんのでご注意ください。

Y-Kanoh です。普段は PHP による開発を行っています。 先日、株式会社 ラク スは PHP の繁栄と継続的な開発を支援するため、 The PHP Foundation へ寄付を行いました。 The PHP Foundation について The PHP Foundation は、 PHP の長期的な存続と繁栄を目的とした 非営利団体 です。 PHP のトップコントリビュータである Nikita Popov 氏が活動の中心を PHP から他へ移すことに起因して、 PHP の開発者を金銭的に支援するために、 PHP を扱ういくつかの団体によって設立されました。 blog.jetbrains.com 詳しくは インフィニットループ 様の記事をご覧いただければと思います。 The PHP Foundation がどのような経緯で設立されたのか、 また現在の PHP がどのような状況におかれているかなどがとてもよくわかるかと思います。 www.infiniteloop.co.jp 我々も、改めて確認すると近年の PHP コミュニティにて話題になった新機能のほとんどは Nikita Popov 氏によって提案されていることに気づかされ、 同氏が PHP にもたらしたものの大きさを改めて実感するとともに、 PHP のような OSS がどうやって成り立っているかを再認識することができました。 ラク スにとっての PHP とは PHP が ラク スにもたらしている利益は計り知れません。 我々が提供しているサービスのうち、主に以下のサービスでは PHP が利用されてます。 中には20年近く PHP で開発が続いているサービスもあり、 その間、 PHP 開発者によるセキュリティリスクを減らすための 脆弱性 対応や、 サービス強化に有用な PHP の新機能などを取り入れることで、サービスの開発と運用を続けることができました。 このように、今日までこれらのサービスが継続的に利益を生み出せていることは PHP によるところが大きく、 サービスを開発する我々の業務は PHP の発展と継続に依存している状態です。 ラク スの主な PHP サービス 参考： SaaSプロダクト別の技術スタックを一挙公開！ このような PHP による利益享受の還元を PHP に関するコミュニティへの貢献という形で行うことができないかと考え、 ラク スでは数年前から PHP に関係するコミュニティ/イベントへの参加や協賛を行い始めました。 社内では PHP コミュニティを盛り上げようとの思いから、聴衆としての参加だけでなく、 登壇者としての参加や以下のようなイベント後のアウトプットも積極的に行うことを推奨することにしています。 PHP カンファレンス 2021【参加レポート】 PHPカンファレンス沖縄2021【参加レポート】 オンラインでも大盛況！PHPerKaigi2021参加レポート ラクスのPHPエンジニア12人によるPHPカンファレンス2020参加レポート また、他団体の支援という形だけでなく我々自身の手で PHP を盛り上げるために、 Web× PHP TechCafe というコミュニティの運営も始めました。 Web× PHP TechCafe では、あえて対象者を「初級エンジニア ～ シニアエンジニア」に固定し、 あくまで新しく PHP を扱い始めた開発者が PHPer として成長するための場としてのコミュニティを維持することで、 参加した PHPer がもっと大きなコミュニティに参加できるようになるための足掛かりとなり、 PHP コミュニティ全体の活性化に貢献することを目的としています。 Web× PHP TechCafe が支える領域 connpass.com 私自身も Web× PHP TechCafe の運営をさせていただいている一方で、まだまだ開発者としての経験は浅く、 まさに Web× PHP TechCafe が対象とする「初級エンジニア ～ シニアエンジニア」に当てはまります。 そのため、このコミュニティで自身の知識を増やしつつ、 微力ながら PHP の発展に貢献し、多くの PHPer と楽しく技術の話をしながら仕事がしたいとの思いから、 運営を行わせていただいています。 ラク スが PHP を支援する理由 このように、日ごろから PHP の恩恵に預かり、 その還元を PHP に関するコミュニティに対して行おうとしている我々にとって、 PHP の開発自体に支援を行えることは、願ってもいない機会でした。 我々は今後もこれまでと同じように PHP を扱った開発を行い、サービスを提供して、これによる利益を得ることでしょう。 この利益は Nikita Popov 氏のような OSS 開発者によってもたらされているものであるため、 これを機にできるかぎり PHP 開発者への支援に協力しようとの結論にいたりました。 おわりに PHP の開発に対して金銭的支援を行うことについては、組織ごとに事情があるかと思いますし、 PHP を扱う世界全体のコミュニティにおいても、可能な組織が支援を行い、 新規の開発者は気軽に PHP の導入を決断できる状態が PHP の発展のためだと思います。 また、 PHP への貢献は金銭的支援だけではなく、 バグ報告やドキュメントの翻訳などを含む OSS 活動、 コミュニティでの活動などを通じても行うことができます。 もしよろしければ、我々と一緒に PHP を盛り上げていきましょう!! PHP Foundation - Open Collective エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、弊社サービスのインフラを運用している id:keijiu (ijikeman)です。 今回は、「 ラク スサービスを管理するAnsibleコードの共通テンプレートを作った話」を記載します。 [対象読者] 対象読者: Ansibleでサーバの管理を行っている人 またはこれから行いたいと考えている人 記事を読んでわかること: Ansibleの実装方法(汎用化) パラメータ(vars)の記載箇所 Ansibleの学習資料の作成 Ansibleコード規約 目次 目次 背景 1. コーディング規約策定 ■ポイント コーディング規約一部例 2. 共通処理の標準化 [カテゴリ] [共通設定]のAnsible実装例 ■ポイント [OS標準機能の設定] ■ポイント [OS標準機能の設定]: ネットワーク設定の一部 ホスト名の設定 ■ポイント 3. 各サーバの構成管理情報(パラメータ)の記載場所の固定化 具体的には？ 各パラメータの記載場所 4. マニュアル、Howto用意 一部Howtoサンプル 5. 自動Lintチェック 6. 取り組みの効果について 背景 私が入社した2018年時点では ラク スのインフラはAnsibleの導入が進んでおらず、何度か勉強会を行った状況でした。 またAnsibleはおろかChefや古くはPuppetなどの構成管理ツールの導入は行われておりませんでした。 そこで前職でChefを使って Linux サーバの提供サービス設計・開発に携わった経験から、 Ansibleの本格導入への白羽の矢が立ったということで、導入までの活動をまとめましたのでその内容を紹介 致します。 1. コーディング規約策定 ラク スでは年々社員数が大幅に増えており、インフラ開発部でも毎年のように新卒や中途社員が増えています。 後から入社しAnsibleに携わる方にもできるだけ統一した書き方でAnsibleコードを書いていただく必要がある為、 Ansibleの基本構文となる YAML のコーディング規約を策定しました。 ■ポイント ルールを単に記載するだけではわかりにくい為、記述例を挙げる 記述例によって文章よりも視覚的に理解が深まる狙いです ルールを以下の2種類に分けて記載 [MUST] ... 必ず必要 [SHOULD] ... より望ましい コーディング規約一部例 #### 拡張子 - [MUST] YAMLファイルは.ymlとする。 #### タブ/スペース/行間 - [MUST] インデントは2スペースとする。 - [MUST] 変数名の前後に空白を入れる。 - [MUST] コロン:のあとには半角スペース１つを必ず入れる。 - [MUST] ハイフン-のあとには半角スペース１つを必ず入れる。 - [MUST] debugを除く各モジュールには必ず、- name:を付けて処理内容にコメントを記述する。 #good --- - name: StdOut 'hoge' shell: {{ BIN_ECHO }} 'hoge' #bad --- -name:test shell:{{BIN_ECHO}} 'hoge' --- ### Command/Shellについて - [SHOULD] 冪等性を保証が困難となる為、できるだけansibleのモジュールで実装し、やむ負えない場合のみ使用する。書き換えはsedを使わずlineinfileモジュールを使うなど - [MUST] バックグランド実行(&)やパイプ、リダイレクト(>, >>)を利用しない場合はcommandを利用する。 #good --- - name: Exec command A command: {{ BIN_ECHO }} 'hoge' - name: Exec command B shell: {{ BIN_ECHO }} 'hoge' > /etc/fuga #bad --- - name: Exec command A shell: {{BIN_ECHO}} 'hoge' --- 2. 共通処理の標準化 次に行ったことが、共通処理の標準化になります。 Linux サーバを構築する場合に必要な処理を、大きく３つのカテゴリにわけて共 通化 しております。 [カテゴリ] [共通設定]: 無駄なサービス停止、パッケージ削除、パッケージ追加、グループ操作、ユーザ操作、 ディレクト リ操作、ファイル操作等 [OS標準機能の設定]: selinux 設定, sysctl設定、ネットワーク設定、 リポジトリ 設定等 [起動するデーモン毎の処理]: テンプレート化して各デーモン用のrole毎に複製して実装 [共通設定]のAnsible実装例 パッケージの一斉インストール処理を共 通化 しています。 ■ポイント with_itemsを定義することで、リストを使ってループ処理しています パラメータの記載箇所を分けることで、適用する影響範囲を限定することができます( 次章 にて説明します) $ roles/common/tasks/main.yml --- - name: Install Packages yum: name: "{{ item.NAME }}" state: 'installed' enablerepo: "{{ item.ENABLEREPO | default() }}" with_items: - "{{ COMMON_INSTALL_PACKAGES | default([]) }}" - "{{ COMMON_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTVARS_INSTALL_PACKAGES | default([]) }}" --- [OS標準機能の設定] ■ポイント OSの設定は設定種別が多い為、同じカテゴリの処理をまとめてsetup_*.ymlとしています main.ymlはimport_tasks:を使用し各処理をまとめたsetup_*.ymlを読み込んでいます。こうすることでosロール全体の見通しがよくなります。 $ roles/os/tasks/main.yml --- - name: Setup Network import_tasks: setup_network.yml - name: Setup Sysctl import_tasks: setup_sysctl.yml - name: Setup Selinux import_tasks: setup_selinux.yml [OS標準機能の設定]: ネットワーク設定の一部 ホスト名の設定 ■ポイント NETWORK_SETTINGS.HOSTNAMEを定義することでホスト名の構成情報を管理 ホスト単体の設定なので、host_vars/[HOSTNAME].ymlに記載するとよいでしょう もし適用ステージを分けたい場合は、inventories/[STAGE_NAME]/host_vars/[HOSTNAME].ymlに書くとよいでしょう $ host_vars/[HOSTNAME].yml --- NETWORK_SETTINGS: HOSTNAME: 'hoge.fuga.rakus.co.jp' $ roles/os/tasks/setup_network.yml --- - name: Setup Hostname hostname: name: "{{ NETWORK_SETTINGS.HOSTNAME }}" when: - NETWORK_SETTINGS.HOSTNAME is defined 上記のように、どの種類のサーバでも同じような構築ルールで実装を行うことが多いと思います。 (例えば IPv6 は基本的に無効とか) そういった処理を共通処理化することでAnsibleコードの共有が行えます。 同じ実装でも記載する人によって微妙に変数名等の 命名規則 が違ったりすることで、Ansibleコードの流用ができないなど、保守性が下がることを避けることが出来ます。 3. 各サーバの構成管理情報(パラメータ)の記載場所の固定化 Ansibleでは、構成管理情報を多くの箇所に記載することができます。 これは便利な反面、複数名によるコーディングを行う場合は管理面で煩雑となります。 例えば以下のような場面が考えられます。 複数種別のサーバを1つのAnsibleコードで管理している場合、同じパラメータ名が別々のファイルに記載されることで値が上書きされ、設定が変更されてしまう。 具体的には？ もともとのAnsibleコードに以下内容が記載されていたとします。 $ group_vars/all.yml --- GATEWAY: 192.168.0.254 上記設定があることに気が付かず、誰かが以下のような設定を追記したとすると。。。 $ group_vars/webserver.yml --- GATEWAY: 10.0.0.254 Ansibleの仕様では、ファイル同名のパラメータは優先度によって上書きされます。 この場合group_vars/webserver.ymlの方が優先度が高い為、webserverグループに属しているサーバ群の GATEWAY は書き換えられてしまいます。 この様に1人でAnsibleコードを記載している場合には問題ないかもしれませんが、 複数名ともなると共通認識を合わせコーディングする必要がある為、ルールの策定が必要です。 よって、構成管理情報の記載箇所にも共通ルールを作成しています。 各パラメータの記載場所 group_vars/ └ all.yml ... COMMON_INSTALL_PACKAGES (全ての環境) └ HOSTGROUP名.yml ... COMMON_HOSTGROUP_INSTALL_PACKAGES (特定のグループにのみ) inventories/ └ [STAGE_NAME]/ └ group_vars/ └ all.yml ... INVENTORY_INSTALL_PACKAGES (特定のステージのみ) └ HOSTGROUP名.yml ... INVENTORY_HOSTGROUP_INSTALL_PACKAGES (特定のステージのみ 且つ 特定のグループにのみ) └ host_vars/ └ HOSTNAME.yml ... INVENTORY_HOSTVARS_INSTALL_PACKAGES (特定のステージのみ 且つ 特定のホストにのみ) この様に、記載場所と 命名規則 を予め決めておくことで、互いに影響しあったり値が上書きされることを防いでいます。 以下は、 [共通設定]のAnsible実装例 で紹介したパッケージインストール共通処理でも記載されている部分です。 with_items: - "{{ COMMON_INSTALL_PACKAGES | default([]) }}" - "{{ COMMON_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTGROUP_INSTALL_PACKAGES | default([]) }}" - "{{ INVENTORY_HOSTVARS_INSTALL_PACKAGES | default([]) }}" ですので例えば、 管理しているサーバ全部に対して適用したい -> group_vars/all.ymlにCOMMON_INSTALL_PACKAGES:を定義する 管理しているWebサーバ全部に対して適用したい -> group_vars/webserver.ymlにCOMMON_HOSTGROUP_INSTALL_PACKAGESを定義 本番環境のWEBサーバにだけ適用したい -> inventories/production/group_vars/webserver.ymlにINVENTORY_HOSTGROUP_INSTALL_PACKAGESを定義 といった様に、パラメータを定義していきます。 4. マニュアル、Howto用意 前述した多くの仕様を、新しく参加してきたメンバーに理解してもらう為に勉強会を毎回開くにわけにもいきません。 とはいえ、一定のレベルになるまで学習してもらう必要がありますので、品質のばらつきが出ることを防ぐ為のHowto形式で学べるマニュアルを用意しています。 なお、テキストのみの教育プログラムではなく、理解度向上を狙い、 サンプルとAnsibleの実行画面のキャプチャ画像のアニメーションGifを使ったマニュアルを用意しました。 一部Howtoサンプル # 3. 全てのサーバに対してパッケージの一括インストール ## 3-1. コードの解説 - 必要なパラメータは"NAME"と"ENABLEREPO"が設定できる - ENABLEREPOは省略可能 - NAMEとVALUEを設定する必要がある --- 設定例: $ group_vars/all.yml --- COMMON_INSTALL_PACKAGES: - NAME: 'curl' - NAME: 'libc-client' ENABLEREPO: 'epel' HOWTO01 5. 自動Lintチェック Ansibleのコードはgitlabにて管理しています。 そのため、gitlabにコードをPushする度に、Jenkinsが連動し YAML Lint, Ansible Lintのチェックを自動で行っております。 細かな実装に関しては長くなる為、今回は割愛させていただきます。 機会がありましたら別途記事にしたいと思います。 6. 取り組みの効果について がんばったおかげ？かわかりませんが ラク スが展開するサービスのサーバを管理するAnsibleコードでは私が作ったAnsibleベースコードが使われるようになりました。 どのサービスのAnsibleコードを見ても基本的な構成が同じである為、他のサービスに関わっていた人が別のAnsibleコードを見てもパラメータの記載場所や処理の記載箇所処理内容が同じであったり、追加機能や修正箇所の移植が簡単に行えるなど運用管理が行いやすい状態となりました。 この様にコードの統一性の効果は高く、またそれによって品質の安定化にもつながる為、メリットは非常に高いです。 組織の拡大及び、管理対象範囲が増えていく毎にさらに効果が高まっていくと考えられます。 以上ありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com