技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今年度2回目となる ラク スMeetupは、 『 SaaSプロダクト開発をリードするデザインとフロントエンド 』 でした！ テーマは『UIデザインとフロントエンド』です。 当社の現場最前線のエンジニア/デザイナーから普段の活動や開発・運用で得た知見などの技術情報をお届けしました！ なお、本イベントは以下のような方にオススメとなっております。 ◆ こんな方にオススメ！ ・UIデザインチーム、フロントエンドチームに興味がある方 ・息の長いシステムの リファクタリング を検討している方 ・ビジネスサイドへの提案を始めようとしている方 ・フロントエンド、バックエンド分離を予定している方 ・ SaaS 開発に携わるエンジニア/デザイナーの話が聞きたい 発表の紹介 プロダクトデザイン組織の新しい取り組み 既存システムのフロントエンド・バックエンド分離 7月開催！おすすめ技術イベント ラクスのエンジニア/デザイナーと話をしてみたい方へ 終わりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ イベントの詳細は以下をご確認ください。 rakus.connpass.com プロダクトデザイン組織の新しい取り組み 登壇：小野田 純也 [所属：プロダクトデザイン課／担当プロダクト： 楽楽電子保存 、 楽楽明細 、 楽楽労務 ] speakerdeck.com 1本目は、小野田さんより『プロダクトデザイン組織の新しい取り組み』をご紹介いただきました！ プロダクトデザイン課のミッションである「プロダクト開発の中心となって顧客課題を解決する優れたUXを生み出す」のもと、組織横断チームとして ラク スの様々なプロダクト開発に積極的に関わっています。 以下について、発表いただきました。 プロダクトデザイン課についての紹介（ミッション・ビジョンについても紹介） 新サービス開発における、共通UIライブラリを用いたデザイン作成とFEとの関わり（楽楽電子保存） ペルソナ設定の取り組み（ChatDealer） 改善のためのユーザーインタビュー実施（配配メール ） ◆ ラク スのデザイン情報については、以下をご確認ください！ career-recruit.rakus.co.jp 既存システムのフロントエンド・バックエンド分離 登壇：関 淳志 [所属：フロントエンド開発課／担当プロダクト： ChatDealer ] speakerdeck.com 2本目は、フロントエンド開発課の関さんによる発表です。 ChatDealerでは、Laravelを採用しております。 その中でもviewは、フロントエンドとバックエンドのコードが混在し密結合になっており、開発する上で様々な問題が出てきました。 本発表では、それらを改善するべくフロントエンドとバックエンドの ソースコード 分離を行うことを決意し、提案から実装に至るまでの過程についてお話ししました。 フロントエンド/バックエンドを分離しようと考えた経緯 ビジネスサイドへの提案 ソースコード 分離の実施 ソースコード の分離を行い、見えてきた今後の課題　 7月開催！おすすめ技術イベント ラク スでは、定期的にエンジニア/デザイナー向けの技術イベントを開催しております。 その中でも7月に開催する、技術イベントをご案内いたします。 ◆ エンジニアの勉強法ハックLT- vol.9 techplay.jp ◆ おすすめの技術書 LT会 - vol.4 techplay.jp ◆ 【 ラク スDev Team Talk 】小さく試して大きく育てるチームづくり techplay.jp ◆ 開発×テスト LT会 - vol.3 techplay.jp ◆ エンジニアリング組織あれこれLT techplay.jp ◆ 【 ラク スDev Team Talk 】急成長プロダクト組織のマネジメント強化 techplay.jp ◆ UI/UXデザイナーLT会 - vol.8 techplay.jp ◆ リファクタリング LT 〜毎日こつこつちょっとずつ〜 techplay.jp 1つでもご興味があるものがございましたら、お気軽にご参加ください！ 採用イベントも開催中！こちらも合わせてご確認ください。 ・ 7/22(金) UIデザイナーの仕事紹介／カジュアル説明会 ・ 7/26(火) フロントエンドエンジニアの仕事紹介／カジュアル説明会 ラク スのエンジニア/デザイナーと話をしてみたい方へ 当社では、一緒に働くエンジニア/デザイナーを積極的に募集しております！ 現在募集している職種は、以下の通りです。 ◆ UIデザイナー career-recruit.rakus.co.jp career-recruit.rakus.co.jp ◆ Webデザイナー career-recruit.rakus.co.jp ◆ フロントエンドエンジニア career-recruit.rakus.co.jp career-recruit.rakus.co.jp 「まだ応募する段階では…」 という方は、是非 カジュアル面談 もご検討ください！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんと話してみたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 終わりに 『 SaaS プロダクト開発をリードするデザインとフロントエンド』はいかがでしたでしょうか？ 最前線で活躍しているエンジニア/デザイナーからプロダクトデザイン組織の取り組みや、 フロントエンドとバックエンドの分離体験を発表させていただきました。 SaaS 開発に携わるエンジニア/デザイナーの皆様が、一つでもご参考になる情報がありましたら幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんなことをお話しします 参加申込方法 ◆TECH PLAY これまでの「組織・チーム作り」発表まとめ ラクスの開発組織戦略 横断チーム立ち上げ 人材育成・学習 こんにちは、技術広報のnobu_msです。 皆様のエンジニア・デザイナー組織では、チームビルディングを行っていますか？ 今回 ラク スでは、開発組織（エンジニア・デザイナー）のチーム作り事例を紹介するイベント「 ラク ス Dev Team Talk 」を開催します！ こんなことをお話しします プロダクトフェーズにあわせた組織づくり 技術 ブランディング ・コミュニティづくり 開発プロセス や プロダクトマネジメント 育成・オンボーディングの取り組み 成長・学習機会の提供 マネジメントの仕組化 業務効率化　など 参加申込方法 イベントに参加したい！という方は、TECHPLAYからお申込みをお願いします！ ◆TECH PLAY ・7/11(月)19:00～ 【 ラク スDev Team Talk 】デザインチーム 業務とマネジメントの「仕組化」をキーワードにデザイン専門組織の取り組みを紹介！ techplay.jp ・7/19(火)19:00～ 【 ラク スDev Team Talk 】小さく試して大きく育てるチームづくり 開発プロセス 、エンジニア文化、組織づくりなど、関西発のさまざまな事例を紹介！ techplay.jp ・7/25(月)19:00～ 【 ラク スDev Team Talk 】急成長プロダクト組織のマネジメント強化 導入件数年間170%成長の楽楽明細。開発体制強化・組織再編の取り組みを紹介！ techplay.jp 各回とも最前線のエンジニア リングマ ネージャー、デザインマネージャーが参加。 さまざまな現在進行形の取り組み事例をざっくばらんにご紹介します。 情報交換、質問、交流機会として是非お気軽にご参加ください！ イベントでお会いできることを楽しみにお待ちしております！ これまでの「組織・チーム作り」発表まとめ ラク スのイベントでは定期的に、エンジニアやデザイナーが組織戦略やチーム作りをテーマに発表しています！ ここではその一部をご紹介します。こちらも是非ご覧ください！ ラク スの開発組織戦略 speakerdeck.com speakerdeck.com speakerdeck.com 横断チーム立ち上げ speakerdeck.com speakerdeck.com 人材育成・学習 speakerdeck.com speakerdeck.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめまして。 顔の濃さが唯一の アイデンティティ のインフラエンジニア、m_yamaです。 ラク スに入社して1年、関わっている2つのサービスでTerraformをよく触ってるので、まとめてみました。 この記事さえ読めば、きっとあなたもTerraform中級者です。 （ちょっと盛った） （自分が中級者みたいでおこがましい） （精進します） 目次 目次 Terraformとは ざっくり理解するTerraformの全体像 Terraformの参考コード（EC2編） リソースをコード化するメリットって？ AnsibleやChef、Puppetとの違い Terraformの使い方 基本的にはこの2つ「plan」「apply」 既存リソースをTerraform管理する「import」 なにをTerraform管理しているかを確認する「state list」 Terraformの3大便利ツール 1. 既存環境を楽にTerraform管理する「Terraformer」 2. GUIでTerraformコードを生成できる「former2」 3. profile変更が楽になる「direnv」 まとめ Terraformとは Terraformは、いわゆる IaC(Infrastracture as Code) を体現するツールの一つで、インフラ環境をコード化できるスグレモノです。 たとえば、複数のEC2を同じ設定で起動する必要があったり、他人が作ったEC2のコピーを作る場合、「 そんなとこ気付かねえよ！ 」みたいな、奥底で設定された値を間違えてサーバを作り直す、なんて経験をしたことがあると思います。 (EC2のパブリックIPの自動割り当てにチェックを入れずに作成してしまい、 yum updateができずに泣く泣く作り直す、なんてことは良くあります) EC2のアクションを見ていくと、「 インスタンス の設定」や「セキュリティ」など、ひとつのEC2につき 設定ページへのリンクが32個 もありました。 全部設定する必要はないものの、全部のリソースの全ページを確認してたら日が暮れます。 Terraformでコード化していれば、コマンドぽちでポコポコ同じ設定のEC2が立ち上がるので、同じ設定が簡単に再現できます。 そのほか、 以下のようなメリット があります。 テスト環境・ステージング環境・本番環境など、どれか一つあればほかの環境の構築が簡単 試験的に設定を変更しても、すぐに元に戻せる（性能試験がしやすい） 間違えて削除してしまったリソースを、同じ設定ですぐに復元できる AWS は GUI がガラッと変更されて戸惑いやすいが、コード化されてれば関係ない ※ AWS を例に出していますが、 GCP やAzure、オンプレまでいけちゃうマルチなツールです。 ざっくり理解するTerraformの全体像 Terraformは、EC2などのリソースをコード化して、「 tfstate 」というファイルに反映することでリソースの管理をします。 ※ tfstateファイルはリソースのメタ情報など全てが記載されたファイルなので、ローカルではなく S3などに保管し、さらにバージョニングしておくと安心 です。 Terraformを実行する大まかな流れは以下の通りです。（各Terraformコマンドは後述します） EC2などのリソースをコード化する(*.tfファイルを作成する) コード化したリソースが、 すでにある場合：TerraformimportすることでTerraform管理下に置かれる(tfstateに追記する) ない場合：Terraformapplyすることでリソースを作成し、Terraform管理下に置かれる 以下、リソースを変更する場合は、コードを編集してTerraformplanで確認し、Terraformapplyで反映する（+ tfstateファイルの更新） Terraformの参考コード（EC2編） 参考までに、EC2のTerraformコードを書いてみました。 例えばこの場合、 以下のようなメリット があります。 amiを明記することでバージョンを統一でき、バージョン違いによる微妙な挙動の違いを防げる stagingなど別環境を作る際、PrivateIPの ホスト部 を統一しやすい（IPから中身がイメージしやすくなる） EC2やEBSで忘れがちなタグのNameを設定できる コード化することで、以下のように「あのサーバの設定なんだっけ、どこで設定してたっけ」のような無駄な時間がなくなり、 リソースの管理や開発の効率が高まります 。 resource "aws_instance" "test-server-01-example-co-jp" { ami = "ami-xxxxxx" availability_zone = "ap-northeast-1a" ebs_optimized = true instance_type = "t3.small" monitoring = true key_name = "key-pair-name" subnet_id = aws_subnet.id vpc_security_group_ids = [aws_security_group.test-server-sg.id] private_ip = "10.10.1.5" root_block_device { volume_type = "gp3" volume_size = 100 delete_on_termination = true tags = { Name = "test-server-01.example.co.jp" } } tags = { "Name" = "test-server-01.example.co.jp" } } リソースをコード化するメリットって？ リソースをコード化してgitなどでバージョン管理すれば、 レビューで認識齟齬がないことを確認しやすい 同一リソース・別環境の複製（test、staging環境など）が容易 コミットログから過去の変更時期や意図を確認しやすい ブラウザでの操作のように、設定変更ページを探す必要がない 一時的に手動で変更した設定の戻し忘れに気付きやすい（手動変更するなという話ですが） など、メリットがたくさんあります。 AnsibleやChef、Puppetとの違い IaCの文脈で同列に語られがちなAnsible・Chef・Puppetは、 サーバの「中」の設定をコード化するツール になります。 たとえば、OSユーザーの追加だったり失敗すると怖いsudoersとかだったり、Nginxや各種 ミドルウェア などのインストールなどがコード化できます。 Terraformは、サーバそのものや、ネットワーク、ストレージなどの サーバの「外」をコード化するツール なので、TerraformとAnsible等を上手く使い分けることで、環境構築や既存環境の改修がとても楽になります。 ※ Terraformでも、起動時のテンプレートを設定できたりしますが、Ansible等の方が柔軟性が高く使い勝手がいいです。餅は餅屋。 Terraformの使い方 公式サイト からダウンロードして、 GetStarted するだけ。 yum install(apt install)したことがあるなら一瞬です。 ※ 結構バージョンアップが早く、それによる破壊的な変更があったりするので、バージョンや更新情報に気を使う必要はあります。 よく使う、基本的なTerraformコマンドの一部を紹介します。 基本的にはこの2つ「plan」「apply」 一番使うコマンドは、きっと terraform plan だと思います。 コードを編集して、意図した変更になるかを確認するときに使います。 plan で確認した後、実際反映するのは terraform apply コマンドになります。 applyコマンドで 意図せぬ変更をしてしまうと戻せない（作り直す必要がある）場合もある ので、必ずterraform planコマンドを打って確認する必要があります。 既存リソースをTerraform管理する「import」 既存のリソースをTerraformで管理する場合に必要になるのが、 terraform import コマンドです。 たとえば、さきほど紹介したコード化したEC2が存在していて、Terraform管理されていない場合、そのままapplyコマンドを実行すると、その設定のEC2を新規作成しようとします。 importコマンドを実行することでコードとリソースが紐づき、Terraform管理できます。 $ terraform import aws_instance.test-server-01-example-co-jp i-xxxxxxxxxx(インスタンスID) なにをTerraform管理しているかを確認する「state list」 管理するリソースが増えてくると、今Terraformで何を管理しているのかを一覧で見たいタイミングも出てくると思います。 そういったときに、 terraform state list コマンドを使うことで一覧出力できます。 grep で特定のタイプのリソースに絞ったり、全体を俯瞰するときに便利です。 $ terraform state list aws_instance.test-server-01-example-co-jp aws_security_group_rule.test-server-sg aws_vpc.test-01-vpc ... ... Terraformの3大便利ツール Terraformを使い始めて1年ぐらいたち、いろいろ便利なツールも見つけたのでまとめて紹介します。 1. 既存環境を楽にTerraform管理する「Terraformer」 先ほどEC2をコード化しましたが、あれを全部手書きするのはあまり現実的ではありません。 既存リソースをコード化するなら、 Google （ GCP ）が開発する Terraformer というツールを使うのが便利です。 以下のようにコマンドを実行すると、既存リソースからコードを作成してくれるので、ほとんど自分でコードを書く必要がありません。 $ terraformer import aws --resources=ec2_instance ... # いろいろ作成される $ ls generated/aws/ec2_instance/ instance.tf outputs.tf provider.tf terraform.tfstate $ cd generated/aws/ec2_instance/ $ terraform init $ terraform plan ※ ↑のように、作成された ディレクト リに移動してTerraform planを実行すると、コード通りのEC2を作成しようとします。 先述した「terraform import」でコードとリソースを紐づけることで、既存のリソースをTerraform管理できます。 2. GUI でTerraformコードを生成できる「former2」 Terraformerは cli での操作なので、慣れない人は使いにくいかもしれません。 そういう方には、 GUI で既存リソースをコード化できる「former2」がおすすめです。 以下の画像のようにリソースを選択でき、Generateボタンを押すだけでまとめてコードを作成できます。 （作成後のコードは載せませんが、↑で書いたようなコードが自動で作成されます） former2.com ブラウザにcredentialsを登録することで、ボタンポチポチで欲しいリソースをコード化できます。 安全性が気になるところですが、 AWS 公式ブログでも以下のように紹介されています。 Former2 is designed never to send these credentials to an external server that isn’t an AWS API endpoint. 　 引用元： Accelerate infrastructure as code development with open source Former2 ブラウザにcredentialsを登録することに抵抗がある方（ほとんどの人はあると思いますが）は、docker-composeでローカルにホストする方法もあるので、検討してみる価値はあると思います。 dev.classmethod.jp 3. profile変更が楽になる「direnv」 複数サービスのTerraformを管理していると、確認のために実行した aws cli コマンドでprofileの切り替えを忘れて、別のサービスのprofileのまま実行してしまうことがあると思います。 direnvを使うことで、 ディレクト リと AWS PROFILEを紐づけられます。 これにより、 ディレクト リを移動するだけでPROFILEを切り替える ことができ、PROFILEの切り替え忘れを防げます。 github.com 実際に試してみます。 （※ 設定方法は上記の github を参照してください） たとえば、以下のように、複数サービスを管理しているとします。 works ├── serviceA │   └── .envrc └── serviceB ├── .envrc └── .envrc_prod 以下は実際に操作した画面になります。 ※ 前提: direnvを使って、各サービスの ディレクト リで.envrcを作成していること ①　serviceA ディレクト リに移動すると、serviceA/.envrcが自動で読み込まれて、 AWS_PROFILE=serviceA-test がセットされます。 ②　そこからserviceBに移動すると、serviceB/.envrcが読み込まれ、 AWS_PROFILE=serviceB-test がセットされます。 ③　また、serviceB/.envrc_prodのような本番用のPROFILEファイルを作成し、sourceで明示的に読み込めば、本番用の AWS_PROFILE=serviceB-prod に切り替わります。 基本的にはtest用PROFILE、必要なときのみ本番用PROFILEを読み込む、といった使い方ができて便利です。 （promptが設定されてると、本番系（ -prod など）のPROFILE名だと色が変わって、すぐにわかるのもありがたいです） ④　direnvで設定されていない ディレクト リに移動すると、 環境変数 がunsetされるのも安心です。 まとめ Terraformと便利ツールについてまとめてみました。 Terraformを使いこなせれば、リソースの管理がとても楽になるので、まだの方はぜひ試してみてください。 もっと体系的に学びたい、という場合は、以下の書籍がおすすめです。 実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）) | 野村 友規 | 工学 | Kindleストア | Amazon エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは。 ラク ス技術広報のLandh6です。 今回は、就職活動の上でも社員にとっても重要な、 ラク スの「福利厚生」についてご紹介します！ 昨今、 ワークライフバランス やワークスタイルを重視する傾向もあるように思います。 社員が安心して働ける環境、心身の健康、モチベーションやパフォーマンスを維持するうえでも大切な要素の一つです。 ここでは福利厚生を分類、列挙しながら、 ラク スにどのような「福利厚生」があるのか見ていこうと思います。 福利厚生とは 福利厚生は大きく分けると2種類 ラクスの福利厚生紹介 通勤関連 交通費支給 特別休暇関連 入社日に有給付与　 シックリーブ　 慶弔休暇　 ライフサポート ドリンク/スナック/ランチサポート お弁当の注文 ラクスマイル制度 マンスリーシフト タイムリーシフト制度　 家族手当 ベビーシッター補助制度 資格取得サポート 書籍購入・貸出サポート 財産形成 従業員持株会 文化・レクリエーション関連 サークル活動補助 コミュニケーションサポート 社員総会 終わりに 福利厚生とは 福利厚生とは、企業が労使関係の安定などの効果を期待して、任意あるいは法的に従業員に提供する諸施策のことです。 従業員やその家族の福祉のために、行われている取り組みを指します。 福利厚生は大きく分けると2種類 法定福利厚生 ……法律によって実施が義務付けられている福利厚生 例えば…健康保険／厚生年金／ 介護保険 ／労働保険　など ※必ず導入する必要があります。 法定外福利厚生 ……法律では義務化されておらず、企業が任意で制定している福利厚生 例えば…住宅関連／慶弔関係／医療・健康／ライフサポート　等 ※各企業が自由に設定することが可能なので、法定外福利厚生の種類は多岐にわたります。 ちなみに、福利厚生の対象者は、全ての従業員です。 （2020年4月1日に改正・施行「パートタイム・有期雇用労働法」「労働者派遣法」） ラク スの福利厚生紹介 ということで、ここでは健康保険／厚生年金／ 介護保険 ／労働保険等の「法定福利厚生」ではなく、各企業が自由に設定することができる「法定外福利厚生」をご紹介していきます！ ラク ス従業員の働きやすさを高めるため、ここ数年どんどん改正されており、今後もよりよい福利厚生にかかる制度の拡充をしていきます。 通勤関連 交通費支給 上限10万円／月 特別休暇関連 ラク スでは、完全 週休二日制 （土・日）となっており、その他祝日、年末年始休暇、夏季休暇があります。 有給休暇消化率は、80％を超えている状態です。 入社日に有給付与　 入社と同時に15日の有給休暇が付与される制度です。 シックリーブ　 本人や家族が私傷病となった場合最大、5日間の休暇を付与する制度です。 これにより、私傷病への不安のために 年次有給休暇 を一定日数残すことなく計画的な取得を促進します。 慶弔休暇　 例：結婚時7日間の休暇付与する制度です。 ライフサポート ドリンク/スナック/ランチサポート リフレッシュをしたいとき、コーヒーや紅茶など約20種類のドリンクを無料で飲むことができます。 また、低価格で購入できるスナックコーナーや、昼食の弁当注文サービスなどがあり、社員に好評です。 お弁当の注文 日替わり弁当を購入することができます。 当日の朝に注文ができるため、その日の気分でお弁当を選ぶことができます。 ※東京のみ ラク スマイル制度 子育て世代のための選択型就労制度です。 保育園の送り迎えに合わせて出勤・退勤時刻を前後にずらしたり、評価基準を時短勤務に合わせたスタイルに変更するなど、 ワークライフバランス に合わせた柔軟な働き方が実現できます。 マンスリーシフト 「1ヶ月単位」で始業時間を選択できる制度です。 始業時刻を8時から10時まで（30分単位5パターン）選択可能です。 タ イムリ ーシフト制度　 「１日単位」で始業時間を変更できる制度です。 各自の始業時刻の前後最大1時間（30分単位5パターン）で変更可能です。 家族手当 18歳未満の子どもの人数に応じて支給されます。 子1人3万円／月 子2人5万円／月 子3人6万円／月 ※役職者を除く ベビーシッター補助制度 小学校3年生までのお子様がいる社員を対象に、ベビーシッター利用時に割引が受けられる制度です。 資格取得サポート 業務上必要となる資格を取得する際には、受験費用を会社が補助します。 ※事前承認が必要です。 書籍購入・貸出サポート 業務上必要となる書籍の購入や、社内にある書籍の貸し出しをします。 ※事前承認が必要です。 財産形成 従業員持株会 持株会を通じて自社株を定期的に購入することで社員の資産形成をサポートします。 自社株購入時には奨励金を支給します。 文化・レクリエーション関連 サークル活動補助 ラク ス社員によるサークル活動がさかんに行われています。 サークル活動は、 ワークライフバランス の充実や、社員同士の信頼関係の構築に役立っています。 現在は、20を超えるサークルが各拠点で活動中です。 コミュニケーションサポート 社員同士のコミュニケーションを活性化させて業務の円滑化を図ることを目的に、懇親会費用の補助を行っています。 社員総会 会社全体の動向を知る機会として、各事業の総括や今後のビジョン、戦略などを全社員に共有する場を年に一度設けています。社長賞などの社員表彰も行われます。 終わりに いかがでしたでしょうか？ ラク スの福利厚生は、今回挙げたもの以外にも、状況に応じて随時更新されている最中です！ 少しでも興味持っていただけましたら、カジュアル面談等も実施しておりますので、ぜひ福利厚生について直接社員に聞いてみてください！ 最後までお読みいただきありがとうございました！ ◆ 関連ブログ - ラクスのSaaSプロダクト紹介【12種類まとめ】 - 【株式会社ラクス】SaaSプロダクト別の技術スタックを一挙公開！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

初めまして。QA担当のBell_Treeです。 今回は ウォーターフォール モデルについて実体験も交えて説明しようと思います。 はじめに ウォーターフォールモデルとは ウォーターフォールとアジャイルの違い アジャイル開発とは ウォーターフォールとアジャイルの違い ①スケジュール管理のしやすさ ②仕様の柔軟性 ウォーターフォール開発の実体験談 どのような流れでやっていたか 実際の経験を通して 自社サービスと請負案件の違い まとめ はじめに 本記事では ウォーターフォール モデルについて、実体験を交えて説明させていただきます。 あくまで私個人の体験になりますので、全部が全部こういったものではないということはご理解いただけますと幸いです。 ウォーターフォール モデルとは ウォーターフォール モデルについて、簡単に説明させていただきます！ ウォーターフォール の開発作業工程は以下の通りです。 1.要求定義（要求仕様） 　　↓ 2.外部設計（概要設計） 　　↓ 3.内部設計（詳細設計） 　　↓ 4.開発（プログラミング） 　　↓ 5.テスト 　　↓ 6.運用 上記のように各工程を1から順番に上から下へと流れていく様子が"滝"のようであることから、 " ウォーターフォール "と呼ばれています。 ウォーターフォール は基本的に工程を飛ばして開発を進めることはなく、各工程きっちり段階を踏んで次の工程へと進んでいきます。 仕様の考慮漏れなどイレギュラーな事態がない限りは、前の段階へ戻ることはありません。 ウォーターフォール と アジャイル の違い アジャイル 開発とは アジャイルソフトウェア開発 - Wikipedia より一部引用させていただきますと、 アジャイル ソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（ アジャイル ソフトウェア開発宣言）。 すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。 というような説明がされています。 もう少しざっくり説明すると・・・ 『ユーザーストーリー単位で仕様の調整や実装、テストの実施を柔軟に行っていく開発手法』 になります。 ウォーターフォール と アジャイル の違い ①スケジュール管理のしやすさ ◆ ウォーターフォール ウォーターフォール は、おおよその工程や納期などが決まっているので、納期に合わせてどの工程がいつまでに終わって、この工程はいつまでに始めないと！のような予定が立てやすいのが特徴です。 ◆ アジャイル 開発単位が小さく柔軟に対応できる反面、試行錯誤を繰り返して行うこともあるため、スケジュール管理が難しい部分があります。 ただし、 トレードオフ スライダーにより「品質」「予算」「納期」「スコープ」の優先順位が定まっている場合は、「スコープを調整することによりスケジュール遅延を発生させない」等、定めた指針によって関係者で擦り合わせを行うことができます。 ②仕様の柔軟性 ◆ ウォーターフォール どのような製品にしたいか？ 仕様を上流工程の段階で決め、その仕様に則って開発を進めていきます。 そのため、決められた仕様での開発となるため、柔軟性には欠けます。 ◆ アジャイル ある程度の仕様が定まっている状態でも、開発途中などに「やっぱりこっちの方がいいんじゃない？」のような意見があった場合に、より良い方に転換できる柔軟さがあります。 ただし、仕様がコロコロ変わることでドキュメントの最終着地点が曖昧になりやすい面もあります。 【イメージしてみよう】 脈絡もなく、 ウォーターフォール と アジャイル の違いをガ〇ダムのプラモデルで例えてみようと思います。 　　　　　　　　　　　 例えばですが、A君がガ〇ダムのプラモデルを買ったとします。 決められた仕様(=設計書)に沿って組み立てていけば、仕様通りの製品ができあがりますよね？ つまり、 ウォーターフォール ガ〇ダムの完成です！ 話は変わり、B君、C君、D君によるプラモデル同好会にE君より「こういうコンセプトのガ〇プラを作成して欲しい」と依頼がありました。 B君、C君、D君はコンセプトを基にどのようにしたらクライアントであるE君が満足するか話し合いました。 また、逐一E君に作業進捗を報告し、試作物を見せ、E君からは「こういうのもかっこいいけど、こういう風にしたらよりかっこいいかも！」と意見を貰ったりしました。 そうやって、試行錯誤を繰り返しE君が納得のいく物を作成しました。 「ガ〇プラは自由だ！」と言わんばかりのオリジナルガ〇プラ、 アジャイル ガ〇ダムの完成です！ ...イメージできましたでしょうか？(笑) 上記のように決められた仕様で作成するものが ウォーターフォール っぽく、よりこっちの方がかっこいいのではと仕様を変更したりできるのが アジャイル っぽいということを"仕様の柔軟性"の部分に絞ってお伝えしたかったです。 ...というのと、私がただただガ〇プラで例えられないかなと思い付きで書いた次第ですので、超個人的な解釈となります！ ◆ 関連ブログ ・ 【アジャイル開発とは】ウォーターフォールとの比較・スクラムから見えてくるもの ウォーターフォール 開発の実体験談 ここからは私が前職で実際に体験してきた ウォーターフォール での開発ってどういう感じなの？ などを記載していきたいと思います。 私は前々職で ウォーターフォール 開発を7年、前職で スクラム 開発を2年ほど経験してきました。 今回は前々職での経験を基に記載させていただきます。 どのような流れでやっていたか 主に受託業務を行っている会社に勤めていたため、大まかに下記のような流れでやっていました。 ※記憶が少し曖昧なので、本当に大まかなものとなっております。 ①営業さんから開発チームに見積もりや資料作成の依頼あり→顧客に提出 　　　　　　　　　　　　↓ ②案件受注 　　　　　　　　　　　　↓ ③顧客に納品時期確認、見積もりとも照らし合わせながら大まかな WBS を作成 　※要件定義次第では想定外の内容が飛び出してくることもあるので、 WBS のFixは④の後などに設定 　　　　　　　　　　　　↓ ④顧客と要件定義の MTG を何度か実施し、要件を固める 　　　　　　　　　　　　↓ ⑤要件定義書を基に設計書を作成 　　　　　　　　　　　　↓ ⑥設計書を基に開発( 単体テスト 含む)、テスト仕様書を作成 　　　　　　　　　　　　↓ ⑦ 結合テスト を実施→不具合が出たら修正／修正確認 　　　　　　　　　　　　↓ ⑧顧客側にて受入試験→不具合が出たら修正／修正確認 　　　　　　　　　　　　↓ ⑨顧客OKが出たら、必要なドキュメント類をまとめ納品 　　　　　　　　　　　　↓ ⑩(話があれば)運用保守 実際の経験を通して 【スケジュールについて】 スケジュールを組み、その通りにタスクをこなしていけば、基本的には平和に終われるのが ウォーターフォール の良いところです。しかし、そう簡単には上手くいかない場合もあります... 例えば、機能の実装フェーズにおいて機能の実装が難航した場合にスケジュールに遅れが発生するとします。 そうなると、 結合テスト のフェーズにツケがまわってくるので、かなりせかせかとテスト実施をしないといけないという状況がありました。 また、設計書を基に試験仕様書を作成していたのですが、確認しないといけない項目のボリュームが大きくなり、想定以上の 工数 を要することもありました。 そういった場合は、早めに増員願いをマネージャーなどに相談して対応しておりました。 学びとしては納期はきっちり意識しつつも、余裕をもったスケジュールを組み立てることが大事ですし、アラートは早めにあげられるに越したことはないと思いました。 バッファはなんぼあってもいいですからね(笑) 【要件定義段階にて】 おおよそ、要件定義前の見積もり時に顧客が実現したいことなどの資料があったのですが、要件定義を進めていくうちに新しい情報が出たり、そもそもの実現したいことの難易度が変わったりというのが割とありました。 そのため、要件定義が終わる段階で完全に要件がFixしたら再度見積もりをするのが吉です。 また、スケジュールに関しても大幅に修正が必要な場合は顧客に明確な理由を伝え、リスケすべきです。 でないと、実際に作業が始まった際に地獄がじわじわと広がっていきます...(笑) 自社サービスと請負案件の違い 一つ目は、無理のないスケジュールとなっていることです。 私は弊社の某サービスに関わっているのですが、弊社に入社して実際にリリースまでの流れに携わっての感想が「スケジュールに余裕があるから大変と感じない」というものでした。 ※私個人のタスク量からの個人の感想となります。 ※後述とはなってしまいましたが、私が現在携わっている某サービスは ウォーターフォール モデルにて開発を行っております。 また、作業内容も決まっているため、それに沿って作業を進めていけば、毎回大幅にぶれるということがありません。 二つ目は、融通が利きやすいと思います。 自社サービスですので新規バグではない既存バグが発見された場合、顧客影響が低いものであれば今回リリースするバージョンでは修正せず、後続のバージョンで修正することができるのが請負案件との違いだと思います。 基本的に上流工程での内部調整となりますので、自社内で完結できるのは自社サービスでの開発のメリットかと思います。 まとめ ここまで読んでいただきありがとうございます。 今回は私の経験も交えて、 ウォーターフォール について記述させて頂きました。 大まかに ウォーターフォール がどのようなものなのかを、イメージできるものになっていれば幸いです！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の飯野です。 ラク スでは今年4月に11名のエンジニアが新卒入社しました。 入社後2ヶ月半は講師のもとで研修を行い、研修を経た後に配属となります。（今年度の研修はオフラインでの開催となりました！） 6/28に研修の集大成となる「技術研修発表会」が行われましたので、本投稿にて紹介させていただきます。 21新卒が執筆した昨年度の研修内容もよろしければ合わせてご覧ください！ - 【2021年】ラクスの新卒エンジニアが新卒研修を振り返ってみた 目次 研修概要 成果発表会 まとめ 研修概要 研修は2022/4/13〜6/28の51日間行われました。 技術基礎研修 サーバーサイド Java Spring boot Thymeleaf フロントエンド HTML CSS JavaScript jQuery Ajax といった技術を通じてWebアプリケーションの構築方法を学習しました。 また、 Linux 、DB、コンピューター、ネットワークの基礎用語、テストの手法等もカリキュラムに組み込まれています。 実務演習 研修で学んだ内容を、個人課題を通してアウトプットしていきます。 確認テスト 毎朝の小テスト、 定期テスト で理解度のチェックを行います。 プロジェクト型研修 ECサイト の構築をチーム開発で行います。（開発期間は6/17〜6/28の8日間） チームでは「必ず一人が一つの役割を持つ」というルールのもと、全員が何かしらのリーダーを担っています。 期間内に作成する機能は以下3つに分類されています。 基本機能 全チーム必ず実装する機能 追加機能 必須ではないが余裕があれば実装してほしい機能 独自機能 他チームとの差別化を図るチーム独自の機能 そして、開発期間終了後に成果発表会として各チーム20分ずつのプレゼンを行いました。 成果発表会 Aチーム、Bチーム、Cチームの3チームに分かれグループ演習が実践されました。 Aチーム まず、Aチームからは「 ラク ラク アロハ 」と名付けた飲食店の ECサイト の発表です。 コンセプト お客様を楽にする お店側も使いやすい を掲げ「両者の要望を叶えられるようなプロダクト」を目指し開発を行いました。 独自機能 お客様視点 購入時にログイン情報からお客様情報を取得してくる（入力のコストを無くす） ショッピングカートアイコンにアイテム数を表示 お店視点 レコメンド機能 管理者機能 基本機能としては存在していなかったが、両者が使いやすいコンセプトを掲げたことで、お店視点の機能を作成 等、コンセプト通りにユーザーがより使いやすい機能が独自に実装されていました。 よかった点 開発初期にコンセプトを決定したことで指針ができ、認識を揃えて開発を進めることができた タスク管理ツールにTrelloを導入し、追加機能がすべて実装できた 1時間半に1回現状報告をする等、困ったことがあったらすぐに共有できる体制にした 反省点 HTMLのフォーマッターを統一しておらず、push時に差分が大量に出てしまった 仕様の確認不足により変更作業が増加してしまった 上記2点のにより、大量のコンフリクトと、他の人の修正に気づかず デグレ を発生させてしまった 質疑応答 「お店側の視点」というア イデア はどうやって出た？ まずお店側に使ってもらえないとお客様も使ってもらえないので、お店にも重きを置いた 最初のコンセプト決めの時点でチームで話題に上がった タスクの優先順位はどう決めた？ 基本機能＞追加機能＞独自機能の順番に進めた 簡単な機能順にタスクを並べ、上から順に実装した 技術的に攻めた箇所はどこ？ 強いて言うならデザイン モバイルでも使いやすいようにレスポンシブを取り入れたり デザインはどうやって決めた？ ユーザーにコストがかからないように 「テーマ＝アロハ」なのでテーマカラーを水色にする等、利用者が違和感を抱かないように エディタは人によって変えていた？ チームで統一していたが、フロントエンドは VSCode 、バックエンドは STS を採用した Bチーム 続いて、Bチームからは「 ラク ラク coffee 」と名付けたカフェの ECサイト の発表です。 コンセプト お客様視点：欲しい商品がすぐに見つかる ECサイト お店視点　：商品が売れやすい ECサイト を掲げ、こちらもAチームと同様に ECサイト を利用するお客様と、商品を販売するお店の双方を視点に開発が行われました。 独自機能 レビュー機能 注文履歴から商品を5段階で評価できる機能 レコメンド機能 「 協調フィルタリング 」 アルゴリズム を利用し、嗜好の類似しているユーザーに対しパーソナライズされた商品を提示 管理者側分析機能 年代別の売上グラフを表示できる等、商品毎の売上が分析できるようデータを可視化 上記の機能を実装するにあたり大量のデータが必要になり、テストデータの自動生成処理も実装するという独自性も見られました。 ふりかえり トラブルなく開発が行えた 各個人が少し上のレベルのタスクに挑戦できた クラス図の理解を丁寧に行い、基本機能の実装が早く終わった 進捗管理 ツールをうまく活かせなかった 改善点 デフォルトのデザインを使用していたので、独自性を出したい レビュー機能 を管理者分析機能にも活かしたい UX 質疑応答 協調フィルタリング は自分でコードを書いている？ Java で独自で実装している レコメンド機能の改善点はどういったところ？ データの分母が少ないとレコメンドがうまくいかない よって、お店側の商品をカテゴライズすればもっとレコメンドがうまくいくはず これまでに大量データを扱ったような経験があった？どういった経緯で アルゴリズム を利用した？ 大学院でAIを使用していた経緯がある、データを見るのが好きだったことも影響しているかも 他チームは4人だが、人数が少ないハンデはあった？ とにかく機能を実装しきるのを目標に頑張った、デザインは後回しになって手が回らなかった できるだけバグを生まないように、開発の指針を初めに決めておいたことで3人でもここまで実装できたと思う Cチーム 最後に、Cチームからはおもちゃの ECサイト の発表です。 コンセプト まず、おもちゃを購入する客層を分類し「孫を持つシニア世代」にターゲットを絞ることに。 ECサイト に馴染みのあるターゲットは既存サイトを使うはず シニア世代にとって、既存の ECサイト は機能が多く使いづらいのではないか？ 販売する側もシニア世代に向けた ECサイト を想定していないのではないか？ という仮説からシニア世代にとって使いやすく、あらゆる問題を解決に導く「 ラク ラク トイ 」を開発することに決定しました。 独自機能 LINEでのOAuth2認証 商品の絞り込み機能 性別や年齢、予算を入力することでターゲティングされた商品が表示される RESTAPIで実装し、SPAでの表示を可能に また、商品購入フローをヘッダーに表示する等、ターゲットに向け使いやすさを意識したこだわりが見られました。 まとめ コンセプトを明確にしたことで、どういった機能が必要か全員が指針を持って開発が行えた ただ、コンセプト設定に時間がかかり他チームとの進捗の差に焦って開発を急いでしまった 上記によりレビューが甘くなり、終盤に大量のバグが発生 技術だけでなく技術以外でも未熟さを痛感したチーム開発だった 質疑応答 SPAのように作るにあたって（フロントエンドとバックエンドの繋ぎこみで）苦労したことは？ フロント側でインタフェースを決めて、フロント側でとにかく頑張ったw ターゲティングが凄い、が、シニア層的には文字が小さい（笑）、文字サイズを選べたりするとよりよい 対象年齢の絞り込みは、どのように実装している？ 商品テーブルに対象年齢を持っており、インプットの範囲のデータを表示している 総評 講師より 研修期間中、全員が努力していて、積極的に学ぶ姿勢がありました。 全員が能動的で、学習意欲も高く、定期的なテストの点数も例年と比較し非常に高い結果となりました。 最後のチーム演習では、最初にコンセプトを決めそのコンセプトに沿って機能を考え、スケジュールを立てて開発を行う進め方をしていたチームが多かったです。 そのため、8日間では間に合わないと思われるような機能開発にも着手していました。それもよい経験だったと思います。 また、研修で使用していない技術もふんだんに使用していました。 講師に対してのみならず、同期に対しても気遣い、挨拶ができ、個々のレビューに対してもお礼が言えるといったような、技術だけでなくヒューマンスキルの部分も素晴らしかったです。 総じてレベルの高い形で研修を終えることができたと思います。 とは言え、今回学んだ技術はまだまだ氷山の一角なので、今後も継続した努力に期待しています。 配属先でも間違いなく活躍できると思うので、今回の研修を糧に頑張ってください。 東京開発統括部　統括部長：間澤より 皆さんお疲れ様でした。研修楽しかったですか？ 開発は楽しいものです。 開発に限らず、できないことができるようになる経験って楽しいですよね。 仕事もそうです。 ラク スは国内 SaaS のトップを走っている企業です。 たくさんの製品を扱っているのでその楽しさももちろんあるけど、責任もあります。 責任があるからこそ、刺激的な楽しみもあります。 不具合が起きたらめちゃくちゃ焦るけど、皆さんなら絶対に乗り越えられます。 チームで協力することで、楽しく利益を獲得して品質の高いサービスを作っていきましょう。 今回の研修でも、AチームとCチームはコンセプトがしっかりしていて ユーザビリティ が高いサービス、Bチームは技術に特化したりと、それぞれが強みを活かしてよいサービスを生み出しました。 皆さんの力を合わせるとよりよいものが作れるという経験が研修を通して実感できたと思います。 その楽しさを忘れずに、配属先でも頑張ってください。期待しています。 開発本部 本部長：公手より 発表とてもよかったです。 ユーザビリティ 、技術、ターゲットを絞り切る等、各チームの方向性が見られました。 特に、ビジネスはターゲットを絞るのが大事なので、新卒でそういった視野が持てているのは衝撃でした。 今日皆さんに伝えたいことは2点あります。 まず1点目。 エンジニアは積み重ねの職業、日々学習し続けるのが宿命付けられているもの、と思ってください。 業務時間だけコードを書いていれば優れたエンジニアになれるわけではありません。 ラク スのトップエンジニアも、若い頃からも、今も、常に勉強しています。 とは言え、プライベートももちろん大事なので、バランスが大事。 最初は難しいと思うけど、だんだんうまくなっていきます。ぜひ皆さんにも身につけて欲しいです。 次に、2点目。 開発はチームで行うもの。それを忘れないでいてほしいです。 今後楽しいこともたくさんあるけど、苦しいこともたくさんあると思います。 ただ、苦しいことも仲間がいれば必ず乗り切れるので、周りを頼ってチームに相談してほしいです。 管理職も若い頃は、皆さんと同じ。苦しみながらいろいろ乗り越えてきて今があります。 皆さんが今後苦しむであろうことは大体経験しているはずなので、気軽に相談してほしいです。 最後に、僕がずっと言い続けている『楽しい職場を作る』を、ぜひ皆で実現させましょう。 まとめ 新卒エンジニアの成果発表会の様子をまとめさせていただきました。 わたしも実際に発表を見学しましたが、コンセプト決め〜デザイン、実装までの工程を僅か8日間で行ったとはにわかに信じられないほどクオリティの高いWebアプリケーションとなっていました。 コンセプト、独自機能、デザイン、発表内容それぞれにチームのカラーがあり、チームが「掛け算」であることを実体験として感じられたことと思います。 今回の経験を活かし、配属先でもチーム力を活かしてぜひ活躍していってほしいです。 また、新卒で入った会社の同期は 一生物 だと思うので、お互いに切磋琢磨しながら高め合ってくれることを期待しています！ 最後までお読みいただきありがとうございました。 引き続き、 ラク スをよろしくお願いいたします！ エンジニア新卒採用サイト https://fresh-recruit.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

技術広報の yayawowo です。 昨今、ビジネスシーンで 『デザイン思考』 という言葉をよく耳にするようになったのではないでしょうか？ では、『デザイン思考』が何なのかを説明できますか？ 本記事では、 デザイン思考の基本的や5つのプロセスの説明、おすすめの書籍をご紹介 します！ 最後までお読みいただき、『デザイン思考』について詳しくなっていただければ幸いです。 デザイン思考とは なぜ必要なのか デザイン思考 5つのプロセス ① 共感（Empathize） ② 定義（Define） ③ 概念化（Ideate） ④ 試作（Prototype） ⑤ テスト（Test） メリットとは？ ユーザーが欲しい！と思える商品開発につながる 多様な意見を受け入れられる アイデア提案の習慣が身につく おすすめ書籍 終わりに ◆ ラク スのデザイン情報は以下をご確認ください！ ・ デザイナー情報サイト ・ プロダクトデザイン課 課長note ・ プロダクトデザイン note デザイン思考とは デザイン思考は、人々が持つ本当の問題を解決するための考え方 です。 英語の「Design Thinking」を日本語にしたものであり、「Design」は「設計する」という意味で用いられています。 また、見た目や使い勝手の整理、綺麗な装飾を考え出すだけでなく、利用ユーザーを想定した人間中心の考え方という意味もあります。 なぜ必要なのか ある書籍には以下のように書かれております。 「人」こそがサービスや製品、あるいはシステムの在り方・つくり方に影響を与える、非常に重要な要素となってきたからです。 　 引用元：実践 スタンフォード 式 デザイン思考 世界一クリエイティブな問題解決 できるビジネスシリーズ 　　　　第一章「なぜデザイン思考が必要なのか？」 少し昔までは、新製品が出ればすぐに売れる時代でした。 しかし、近年は時代の変化とともに便利なモノが増え、何か欲しいと思えばすぐにモノが手に入る時代です。 そのため、新製品が出ただけでは、ユーザーはすぐに購入を考えなくなりました。 皆さんはいかがでしょうか？ 私の場合、一つモノを買うだけでもネットでの価格比較や口コミを確認、実際に売り物を確認等するため、購入まで時間を要します。 これらの行動は、 自分の感性や感情にぴったりなモノ を選んでいるためだと考えております。 ユーザー視点や行動を受け止めた上でデザイン（設計）していく考え方・・・ デザイン思考は、今のビジネスに必要だと言われています。 デザイン思考 5つのプロセス デザイン思考は、まず 「ペルソナ」 設定を行います。 ペルソナとは、購入対象者やユーザーのことを指し、 年齢 性別 職業 在住場所 などを具体的に決めます。 その後、そのペルソナのビジネス問題を5つのプロセスを経て、解決していきます。 では、デザイン思考の5つのプロセスについてご説明します！ ① 共感（Empathize） まず、ペルソナが抱えている問題やニーズを探すため、ユーザーと同じ商品を触ったり、観察したりします。 これにより、実際にその商品がどう使われているのかや、使ってみての所感を理解することができます。 「① 共感」のプロセスで大事なことは、固定概念をなくすことです。 ペルソナ且つ、ユーザーに共感できるほど、しっかりと理解することが大切です！ ② 定義（Define） 「② 定義」では、「① 共感」で得られた情報を基に、ユーザーのニーズを定義します。 ニーズは、ユーザーの無意識的な行動や選択の根拠を考えながら、「本当に求めているものは何か？」を具体的に 言語化 していきましょう。 ③ 概念化（Ideate） 「③ 概念化」では、定義したユーザーが求めているニーズを解決するために、 ア イデア やアプローチ方法を話し合います。 「③ 概念化」のプロセスで大事なことは、ずばり質より量です！ 代表的な手法の一つである ブレーンストーミング を使ったりして、ア イデア を創出しましょう。 ④ 試作（Prototype） ア イデア を創出したので、次の「④ 試作」では試作品を作っていきます。 試作品であるため、時間やコストを多くかける必要はありません。 一旦形にすることで、それまで見えてこなかった問題や課題を発見しましょう！ ⑤ テスト（Test） 「④ 試作」で作成した試作品をユーザーに使ってもらうプロセスが、「⑤ テスト」になります。 試作品をユーザーに試してもらい、定義した課題が解決できるかの確認及び意見を募ります。 その意見を基に試作品のブラッシュアップを重ねることで、ユーザーの満足度が高い製品やサービスの完成を目指していきましょう！ メリットとは？ デザイン思考がもたらすメリットをご紹介します。 ユーザーが欲しい！と思える商品開発につながる 前述した通り、今の世の中は商品/サービスが数多く存在しています。 そのため、ユーザーの感性や感情にぴったりなモノを開発しなくてはなりません。 デザイン思考では、ユーザー視点の考え方を身につけるため、潜在ニーズに応えられる・・・ ユーザーが欲しい！と思える商品開発に繋げることができます。 多様な意見を受け入れられる ア イデア を創出するにあたり、多様な立場の方に意見を聞きます。 それにより、異なる立場の意見に向き合うことや、お互いの合意形成を図ること等が可能となります。 多様な意見を受け入れることで、商品開発に繋げるだけでなく、自分自身の考え方を変えるメリットがあります。 ア イデア 提案の習慣が身につく デザイン思考では、実現性を問わず幅広いア イデア を募集します。 失敗したらどうしよう…と思う心配もありません。 まずは、多くのア イデア を出すのが第一です。 不安や心配もなく、ア イデア を提案することができるので、自然と習慣化されるメリットがあります。 おすすめ書籍 『まんがでわかるデザイン思考』 「まんがでわかる」シリーズは、初学者におすすめの書籍となっております。 以下３つのプロセスについてが事例を踏まえて、分かりやすく説明してくれている1冊です！ ①. 着想： 潜在的 ニーズを見つける ②. 発案：ア イデア を創造・構築・検証する ③. 実現：市場に導入する 『実践 スタンフォード 式 デザイン思考 世界一クリエイティブな問題解決』 デザイン思考を実際に試すことができるのが、本書になります。 「チーム内で1回デザイン思考を実践してみたいな・・・」という方は、是非こちらの1冊をご参考ください！ また、著者が スタンフォード大学 d.schoolにて体験した話もあるため、デザイン思考の基本から～実践まで幅広く学ぶことができます。 『デザイン思考が世界を変える: イノベーション を導く新しい考え方』 デザイン コンサルティングファーム の先駆けである、 IDEO の代表者が著者の書籍です。 数多くの企業事例だけでなく、デザイン思考の本質を具体的に紐解いてくれる一冊です。 分量は多めですが、読む価値ありです！ 『エンジニアのためのデザイン思考入門』 新製品を世の中に生み出したいと思っているエンジニアや、マネージャー、また人材育成担当者をターゲットに書かれた書籍です。 東京工業大学 エンジニアリングデザインプロジェクトに所属する学生が、デザイン思考のエッセンスを取り入れ、モノづくりを実践し、その学びを得ていく泥臭い過程を学ぶことができる1冊です！ 終わりに デザイン思考（デザインシンキング）のまとめは、いかがでしょうか？ 最初は、クリエイティブな「デザイン」を想像した方も、デザイン思考とは何なのかを理解することが出来たのではないでしょうか。 ラク スのクリエイティブチームがアウトプットを作る上で意識づけし、取り組んでいる事例が以下の通りです。 ① 認知変容 　→アウトプットを作る前にアウトプットを見た人が、どう思い、どういう行動をして欲しいか設定します。 ② 記号として成立しているか 　 　→作成したアウトプットが記号になっているか？ 　　矢印を見たら、その方向に進むんだと理解するように、そのような気持ちや行動をとっているかを確認します。 デザイン思考は、 Apple や Google などのグローバル企業にて早くから積極的に取り入れられております。 是非、まだ取り入れていない方がおりましたら、まずはチーム内から実践してみてください！ 改めまして、本内容が前例のない課題や問題に遭遇している方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ ◆ 関連ブログ ・ 【2022年最新版】デザインマネージャーが厳選したおすすめUI/UX書籍36選！～これから始める方必見～ ・ 【2021年】 技術書好きプロエンジニア達が紹介する40選 ・ 開発メンバーが選ぶ、おすすめの技術書【2020年度】 ・ UI/UXデザイナー語る、デザイン Tips【20選】 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

皆さんこんにちは！開発エンジニアをしているnkumaです！ 最近、業務で Java 配列を見かけたのですが、久しく触っていなかったためにかなりド忘れしていました。 そのため、復習がてら Java 配列についてブログに起こしてみようと発起した次第です。 本記事では、 Java 配列の宣言・代入といった基本から、ソートや要素を増やすなどのちょっとした応用までを紹介 していきます。 Java を学び始めて、「変数、代入の意味は分かるよ！」という方向けの内容です。 「 Java 配列なんて知ってるよ！」という中級者の方も、 応用編 以降はためになると思うので、是非ご一読ください！ 構文だけでなく、具体的なコードも併せて記載していますので、すぐにでも使えるようになるかと思います。 ※大半の具体例コードは、以下の配列があることが前提です。 String[] dogs = {"ポチ太郎","ポチ次郎","ポチ三郎","ポチ四郎","ポチ五郎","ポチ六郎","ポチ七郎","ポチ八郎","ポチ九郎","ポチ十郎"}; Java 配列とは Java 配列の特徴 基本編 Java 配列の作り方 宣言・要素数の指定 代入 初期化 Java 配列の中身の使い方 要素の取得 Java 配列 ループのさせ方 応用編 配列をコピーする 要素数の増やし方 配列の全ての要素を指定した値で埋める Java 配列の一歩先へ よりたくさんの情報を扱う「多次元配列」 使い方 要素を後から継ぎ足しできる「List」 使い方 Java 配列とListの違い インデックスに名前をつけられる「Map」 使い方 Java 配列 使い方 まとめ Java 配列とは こんなケースを考えてみてください。 まず、10個の似たような変数を用意します。(①) そして、全ての変数に共通の処理をします。（②） // ①10個の似たような変数を作成 String dog1 = "ポチ太郎" ; String dog2 = "ポチ次郎" ; String dog3 = "ポチ三郎" ; String dog4 = "ポチ四郎" ; String dog5 = "ポチ五郎" ; String dog6 = "ポチ六郎" ; String dog7 = "ポチ七郎" ; String dog8 = "ポチ八郎" ; String dog9 = "ポチ九郎" ; String dog10 = "ポチ十郎" ; // ②全ての変数に共通の処理 dog1 = dog1 + "(犬)" ; dog2 = dog2 + "(犬)" ; dog3 = dog3 + "(犬)" ; dog4 = dog4 + "(犬)" ; dog5 = dog5 + "(犬)" ; dog6 = dog6 + "(犬)" ; dog7 = dog7 + "(犬)" ; dog8 = dog8 + "(犬)" ; dog9 = dog9 + "(犬)" ; dog10 = dog10 + "(犬)" ; とても面倒ですよね…10個なら面倒で済みますが、1000個とかなら到底できそうにないです。 Java 配列はそんな面倒から、ある程度解放してくれます！ // ①10個の値が入ったJava 配列を作成 String[] dogs = { "ポチ太郎" , "ポチ次郎" , "ポチ三郎" , "ポチ四郎" , "ポチ五郎" , "ポチ六郎" , "ポチ七郎" , "ポチ八郎" , "ポチ九郎" , "ポチ十郎" }; // ②Java 配列に入った全ての値に同じ処理をする for (String dog : dogs) { dog = dog + "(犬)" ; } 10個の値を一つの変数にまとめることができました！ これをループさせることで、一つ一つを手打ちで書かなくても共通処理が書けるようになりました！ かなり楽をできるようになったと思います。 10個の値を一つの変数にまとめたように、 　　　 Java 配列とは、値を複数保持できる変数のこと です！ Java 配列の特徴 Java 配列にはいくつかの特徴があります。 それに伴って、用語があるのでそれらをまず紹介します。 要素 配列の中の値のこと インデックス 要素を呼び出すために順番についている番号札、ラベルみたいなもの 0から始まることに注意！ 次に、 Java 配列の持つ主な特徴です。 要素は固定長 = 最初に決めた数以上のものは入れられない！ Java 配列には便利なメソッドがいくつもある 配列の中身を並び替えたり、他の配列にコピーしたりできる。 中身のループが簡単！ 拡張for文という、中身をループさせるのに特化した記載方法がある。 以降は、 Java 配列の基本的な使い方や応用的な使い方を紹介していきます！ 基本編 ここでは、宣言や代入といった初歩的なことを説明いたします。 「そんなの知ってるよ！」という方は、 応用編 からお読みください。 Java 配列の作り方 Java 配列の作り方から説明していきます。 宣言・要 素数 の指定 まずは、変数という受け皿を作ります。 いくつか注意することがあるので気を付けて下さい。 配列変数名には、「複数形」を使うのが一般的 要 素数 の指定は、 1から始まる普通の数字！ 後述の呼び出すときに用いる「0から始まるインデックス」とは違うので注意してください！ 構文 // Java 配列の宣言 型[] 配列変数名; // 要素数の指定 配列変数名 = new 型[要素数] 具体例コード // Java 配列の宣言 String[] dogs; // いつも通りの型に「[]」をつけるだけ、dogの集合なので「dogs」 // 要素数の指定 dogs = new String[ 10 ]; // 10個の値を入れたかったら、10を指定する 代入 次は、配列の中身を入れていきます。 配列のどこにいれるかを指定するには「インデックス」を使います。 インデックスは 0から始まる ので注意してください！ 上述の要 素数 の指定とずれることになります。（要 素数 の指定「10」⇒インデックスの最後「9」） 構文 // Java 配列の代入 配列変数名[インデックス] = 代入する値; 具体例コード System.out.println(dogs[ 0 ]); // 「ポチ太郎」と出力（0から始まるので一番初めの「ポチ太郎」） // Java 配列の代入 dogs[ 0 ] = "タマ太郎" ; System.out.println(dogs[ 1 ]); // 「タマ太郎」と出力 インデックスを指定すれば、最初から入れなければならないというルールはありません。 ちなみに、一度も代入されていないものでもデフォルト値が自動で入っています。 （Stringならnull、intなら0など型によって決まっている） int [] numbers; numbers = new int [ 100 ]; nembers[ 50 ] = 999 ; // 0~49に値は入れていないが問題なし System.out.println(numbers[ 50 ]); // 「999」が出力される System.out.println(numbers[ 10 ]); // 「0」が出力される（一度も代入してないのでデフォルト値） 初期化 Java 配列を作るには、宣言して…要 素数 を指定して…値を代入して…と面倒ですよね…。 ここで便利な記法を紹介します。 宣言と代入を同時に行う「初期化」です！ 初期化 = 宣言と代入を同時に行うこと 1文で配列を作成できる！ 要 素数 の指定をする必要がない！ 代入する値の数で、要 素数 を自動で決まるため 入れる値が決まっているならば、この方法で作るのが一般的ですね。 代入する値はいくつでも可能です。 構文 // Java 配列の初期化 型[] 配列変数名 = {代入する値①, 代入する値②, 代入する値③, ... , 代入する値㊿ }; 具体例コード // Java 配列の初期化 String[] dogs = { "ポチ太郎" , "ポチ次郎" , "ポチ三郎" , "ポチ四郎" , "ポチ五郎" , "ポチ六郎" , "ポチ七郎" , "ポチ八郎" , "ポチ九郎" , "ポチ十郎" }; Java 配列の中身の使い方 要素の取得 Java 配列の中身を取得するには、 インデックス を利用します。 インデックスは 0から始まること に注意です。 2番目に入れた値を取り出すなら「1」、10番目に入れた値を取り出すなら「9」とする必要があります。 取得の仕方がやや違うだけで、普通の変数と同じように利用することができます。 構文 配列変数名[取得したいインデックス] 具体例コード System.out.println(dogs[ 2 ]); // 「ポチ三郎」が出力される System.out.println(dogs[ 8 ]); // 「ポチ九郎」が出力される String HelloDogs = "こんにちは！" + dogs[ 5 ] + "と" + dogs[ 9 ]; System.out.println(dogs[ 8 ]); // 「こんにちは！ポチ六郎とポチ十郎」が出力される Java 配列 ループのさせ方 Java 配列の中身をループさせる代表的な方法「拡張for文」を紹介します。 拡張for文は「foreach文」とも呼ばれます。 大抵のエディタは foreach と打てば、補完機能で拡張for文が出てくると思います。 これは「配列の中身全てを順番に処理する」のに向いています。 forの条件文で型は配列に合わせた型( []を除いた型 )を、宣言する変数名は何でもいいです。 （一般的には配列変数名の単数形です） そこで宣言した変数に、順番に配列の中身が入っていきます。 その変数を利用して、for内部のループして行いたい処理を書きましょう。 配列の中身がなくなったらループは自動的に終了します！ 構文 for (型 変数名 : ループしたい配列変数名) { ループして行いたい処理 } 具体例コード for (String dog : dogs) { // 配列はString[]なので型はString dog = dog + "(犬)" // dogに「ポチ太郎、ポチ次郎...」と順番に中身が入っていく } 応用編 配列をコピーする Java 配列を「そのままコピー」するには、 コピー元配列名.clone() メソッドを使います。 対して、「部分的にコピー」したいときには System.arraycopy() メソッドです。 構文 // Java 配列を「そのままコピー」する 型[] コピー先の配列変数名 = コピー元の配列変数名.clone(); // Java 配列の「一部分をコピー」する System.arraycopy(①コピー「元」の配列変数名, ②コピー「元」のコピー開始位置, ③コピー「先」の配列変数名, ④コピー「先」のコピー開始位置, ⑤コピーの個数); 具体例コード // Java 配列を「そのままコピー」する String[] dogs2 = dogs.clone(); System.out.println(dogs[ 1 ] + " | " + dogs2[ 1 ]); //「ポチ太郎 | ポチ太郎」と出力される System.out.println(dogs[ 8 ] + " | " + dogs2[ 8 ]); // 「ポチ七郎 | ポチ七郎」と出力される // Java 配列の「一部分をコピー」する String[] dogs2 = new String[ 5 ]; System.arraycopy(dogs, 5 , dogs2, 0 , 5 ) // ①dogsの②6個目(※インデックスなので0から数える)から、⑤5個を、③dogs2の④1つ目(インデックスなので…以下略)以降にコピーする System.out.println(dogs[ 5 ] + " | " + dogs2[ 0 ]); // 「ポチ六郎 | ポチ六郎」と出力される System.out.println(dogs[ 9 ] + " | " + dogs2[ 4 ]); // 「ポチ十郎 | ポチ十郎」と出力される 要 素数 の増やし方 どうやっても、配列の要 素数 を途中で増やす方法はありません。 ですが、上述の 「部分的にコピーする System.arraycopy() メソッド」を使えば疑似的に要 素数 を増やす ことができます！ 「元々の数+増やしたい分」の要 素数 を指定した配列を新しく作成 配列をコピーする ※ 配列.length ：その配列の要 素数 を取得（10個の配列なら「10」） 具体例コード // 「元々の数+増やしたい分」の要素数を指定した配列を新しく作成 int count = dogs.length + 10 ; // dogsの要素数 + 10個 = 20個 String[] dogs2 = new String[count]; // 配列をコピーする System.arraycopy(dogs, 0 , dogs2, 0 , dogs.length); // dogsの最初から要素の数だけ、dogs2の最初以降にコピー dogs2[ 15 ] = "ポチ十六郎" ; System.out.println(dogs2[ 5 ]); // 「ポチ六郎」と出力される System.out.println(dogs2[ 15 ]); // 「ポチ十六郎」と出力される 配列の全ての要素を指定した値で埋める Java 配列を指定した値で全て埋めるには、 Arrays.fill() メソッドを利用します。 構文 // Java 配列を指定した値で全て埋める Arrays.fill(配列変数名, 埋める値); 具体例コード String[] animals = new String[ 10 ]; Arrays.fill(animals, "犬" ); System.out.println(animals[ 0 ]); // 「犬」と出力される System.out.println(animals[ 5 ]); // 「犬」と出力される Java 配列の一歩先へ ここでは、配列の派生形・類似的なものを紹介いたします。より高度で実践的です。 どれも詳しく解説するだけで1記事、2記事となってしまうもののため、簡単な説明のみとしています。 触りの部分だけでも勉強になると思うので、「へえ、こんなのがあるんだ。便利そう。」って感覚くらいでお読みください。 そして、興味を持ったなら是非調べてみてください。 よりたくさんの情報を扱う「多次元配列」 多次元配列とは、「配列の中にまた配列を入れたもの」になります。 2次元配列は「配列①の中に配列②が入っているもの」、3次元配列は「配列①の中に、配列③が入っている配列②が入っているもの」です。 2次元配列とかは縦・横のマス目で考えると分かりやすいと思います。 それでもかなり複雑になってしまうので、安易に使うことは避けましょう。 使い方 以下は、2次元配列を例に挙げています。 構文 // 2次元配列の宣言 データ型[][] 配列変数名 = new データ型[要素数①][要素数②]; // 要素数①：いくつ配列を入れるのか // 要素数②：中身の配列の要素数 // 2次元配列の代入 配列変数名[ 0 ][ 0 ] = 代入する値; 配列変数名[ 0 ][ 1 ] = 代入する値; 配列変数名[ 0 ][ 2 ] = 代入する値; 　　・・・ 配列変数名[ 1 ][ 0 ] = 代入する値; 配列変数名[ 1 ][ 1 ] = 代入する値; // 2次元配列の取得 System.out.println(配列変数名[ 0 ][ 0 ]); 要素を後から継ぎ足しできる「List」 こちらはかなり便利です！ Java 配列と同じ「値のまとまり」ですが、不便だった「後から追加できない」を解消しており、「どんどん追加することができる」という特徴があります。 ちなみに一口にListといっても、要素の取得が早いが挿入や削除が遅い ArrayList 、要素の挿入や削除は早いが取得が遅い LinkedList があります。 使い方 構文 // Listの宣言 List<型> リスト名 = new ArrayList<型>(); // Listに値を追加 リスト名.add(追加する値); // Listの値を書き換える リスト名.set(書き換えたい値のインデックス, 書き換える値); // Listの値を取得する リスト名.get(取得したいインデックス); 具体例コード // Listの宣言 List dogsList<String> = new ArrayList<String>(); // Listに値を追加 dogsList.add( "ポチ太郎" ); dogsList.add( "ポチ次郎" ); dogsList.add( "ポチ三郎" ); // Listの値を書き換える dogsList.set( 2 , "タマ三郎" ); // Listの値を取得する System.out.println(dogsList.get[ 0 ]); // 「ポチ太郎」と出力される System.out.println(dogsList.get[ 2 ]); // 「タマ三郎」と出力される Java 配列とListの違い Listの方が便利そうですが、何でもListを使えばいい訳ではありません。 Listはデータ保持の都合上、「特定のインデックスにアクセスする」場合に時間がかかってしまうなどデメリットもあります。 何も意識せず、とりあえずListを使うのではなく、使い分けを意識しましょう。 意外と Java 配列を使う時には、後から要素を追加したいことが少なかったりします。 以下は Java 配列とListの使い分けです。参考にしていただけると幸いです。 Java 配列 最初の時点で要 素数 が確定している場合 何度もピンポイントな要素にアクセスするような場合 List 要素の入れ替えが多い場合 後から追加する必要がある場合 インデックスに名前をつけられる「Map」 配列やListの要素を取得するときは、インデックスという数字を使っていました。 しかし、実際に利用しようとなるとどこに何が入っているか分かりません。 それぞれの値に数字じゃなくて、「名前が付けられたら分かりやすいのに・・・」と思う場面も多そうです。 ここで紹介するのが「Map」です。 Mapは「インデックスの代わりに名前をつける」ことができます。 インデックスの代わりにつける名前のことを「キー」と呼びます。 また、Mapは通常「HashMap」を使いますが、特徴をもった「LinkedMap」「TreeMap」というのもあります。 使い方 構文 // Mapの宣言 Map<キーの型, 値の型> マップ名 = new HashMap<キーの型, 値の型>(); // Mapの代入 マップ名.put(キー, 値); // Mapの取得 マップ名.get(キー); 具体例コード // Mapの宣言 Map<String, String> dogsMap = new HashMap<String, String>; // Mapの代入 dogsMap.put( "黒犬" , "ポチ太郎" ); dogsMap.put( "白犬" , "ポチ次郎" ); // Mapの取得 System.out.println(dogsMap.get[ "赤い犬" ]); // 「ポチ太郎」と出力される Java 配列 使い方 まとめ 業務で Java 配列を利用することは機会は多くはありません。 ListやMapの方がよく出てくるイメージがあります。 しかし、（特に初心者の方は）おろそかにするわけにはいきません。 Java 配列の考え方を基にすることで、ListやMap、それ以外のことも理解がしやすくなるからです。 また、比較的少ないとはいえ配列を使うこともあります。 ぜひ一度、上述の具体例コードを参考にしながら、ご自身で書いてみてください！ ◆ 関連ブログ ・ Java 18 インストールと新機能紹介【最新版】 ・ 【多言語対応】Spring Boot+Java - 動的に言語を切り替る方法 - ・ オブジェクト指向を学ぶためのオブジェクト指向エクササイズ ・ 【入門】Spring Bootとは～実践まで エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに はじめまして、インフラ担当のfasahikoです。 今回のブログでは、 「Ansibleを利用してZabbixサーバの設定を行う」 をテーマに書きたいと思います。 Zabbixで監視を行っている且つ、Ansibleで設定を管理したい方（かなりピンポイントですが）を対象に、 AnsibleのインストールからZabbixモジュールを利用した設定までをご紹介したいと思います。 日々の運用を楽にするために、少しでもお役に立てれば幸いです。 はじめに 導入のきっかけ Ansibleとは Ansible Zabbixモジュールとは Ansible,Zabbix-apiのインストール Ansible Zabbixモジュールでの自動化 ホスト設定 メンテナンス設定 終わりに 導入のきっかけ 今回ブログテーマのZabbixの設定自動化を導入した背景ですが、現在担当している商材では管理対象サーバが多く、 メンテナンスや構成変更時、新規サーバ構築時などにZabbixの GUI でポチポチと設定を行うことが苦痛に感じたことが発端です。 Zabbixの GUI 操作で行うと1時間かかる設定作業が、Ansibleでの自動化で数分で設定できる ので、運用をかなり楽にすることが出来たと思います。 次項から、今回のテーマであるAnsibleとZabbixモジュールについての概要を紹介します。　　　 Ansibleとは インフラ構成管理ツールとして多く利用されているためご存知の方も多いと思いますが、 Ansibleとはどのようなものなのか簡単におさらいをしておきます。 Ansibleとは Ansibleとは、システム設定やソフトウェアの導入（インストール）などを自動化、効率化する構成管理ツールの一つ。米レッドハット（ Red Hat ）社が開発・販売しており、 オープンソース ソフトウェアとしても公開されている。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 IT用語辞典 e-wordsより抜粋 Ansibleは、Playbookというファイル群（ファイルの形式は YAML ）に管理対象のサーバ構成を記載していきます。 Ansbileで管理できる設定や対象機器は多岐に渡っており、できないことはほぼないのではと思えるくらい構成管理用のモジュール（機能）が豊富に用意されています。 Ansible Zabbixモジュールとは 次に、Ansible Zabbixモジュールについてです。 AnsibleでZabbix上の設定を管理するためのモジュール群で、設定箇所毎にモジュールが開発されています。 現在、Ansible公式のモジュール一覧を参照すると以下のようなZabbixモジュールが用意されているようです。 ・zabbix_action ・zabbix_group ・zabbix_group_info ・zabbix_host ・zabbix_host_info ・zabbix_hostmacro ・zabbix_maintenance ・zabbix_map ・zabbix_proxy ・zabbix_screen ・zabbix_template 等、詳しくは Ansible公式ドキュメント に載っています。 今回は上記の中から"zabbix_host"モジュール、"zabbix_maintenance"モジュールの実装例について紹介します。 Ansible,Zabbix- api のインストール それでは、実際にAnsibleのインストールからZabbixモジュールの利用までを見ていきたいと思います。 今回はCentOS7の上にAnsibleをインストールします。 以下のコマンドを実行し、Ansible本体とZabbixモジュール利用時に必要となるzabbix- api をインストールします。 $ yum install epel-release $ yum install python-pip $ pip install ansible $ pip install zabbix-api Ansible Zabbixモジュールでの自動化 ホスト設定 Ansibleとzabbix- api のインストールが完了したので、早速Zabbixサーバ上のホスト設定をAnsibleで実行したいと思います。 まずは簡単に、以下のようなコードを作成して設定されるか実際にテストしてみます。 それぞれのパラメータについては公式に解説があります が、以下のような形でそれぞれZabbixサーバのホスト設定に登録するパラメータを記載します。 $ zabbix_host_set.yml - hosts: localhost # Ansible接続先をlocalhostに指定 tasks: - name: Create host on zabbix local_action: # zabbix_hostモジュール利用時はlocal_action: にてローカルでのタスク実行とする module: zabbix_host # 利用モジュールの指定 server_url: "http://192.168.1.10/zabbix" # ZabbixサーバのURL login_user: admin # Zabbixサーバのユーザ login_password: admin # Zabbixサーバのパスワード host_name: "test-vm01.localdomain" # 登録するホスト名 host_groups: # 登録するホストグループ - test link_templates: # ホストに割り当てる監視テンプレート - Template_OS_Linux_Monitor status: enabled # 監視の有効化・無効化の選択 state: present # ホストの設定の有無、『present』はホストを登録、『absent』であれば削除になる interfaces: # 監視対象ホストのインターフェース設定 - type: 1 main: 1 useip: 1 ip: "192.168.1.21" dns: "" port: 10050 設定したいホストの情報を上記の通りPlaybookに記載し、以下コマンドを実行します。 $ ansible-playbook zabbix_host_set.yml コマンドの実行完了後、Zabbixサーバ側を見てみると確かに追加されています。 　　 上記の通り追加はできましたが、このままだとPlaybookに登録対象の設定をベタ書きしており 複数台の登録に対応できないのでもう少しAnsibleの関数を上手く利用できる形にしたいと思います。 以下のような構成でコードを再作成しました。 |-- inventories | `-- hosts |-- roles | `-- zabbix | `-- tasks | `-- host_setting.yml |-- zabbix_host_set.yml それぞれのファイルの中身は以下の通りです。 inventories/hosts 対象はテストサーバとして2台を設定しています。 $ inventories/hosts [test_server] 192.168.1.21 # ホスト名はtest-vm01.localdomain 192.168.1.22 # ホスト名はtest-vm02.localdomain zabbix_host_set.yml 上述のテストではhostsを hosts: localhost としていましたが、 test_serverにAnsibleで接続する形 hosts: test_server に変更し、かつ gather_facts:True として test_serverのサーバ構成情報を取得・利用できるようにしています。 $ zabbix_host_set.yml --- - hosts: test_server gather_facts: True tasks: - include_role: name: zabbix tasks_from: host_setting.yml roles/zabbix/tasks/host_setting.yml 前述の通り gather_facts:True として fact変数 を利用できる形にしていたので、 可変部分のパラメータ設定（host_name,ip）はそのfact変数から取ってこれるようにしています。 （対象サーバの IPアドレス やホスト名はfact変数を利用せず、varsファイル内で変数定義をすべきなのですが、 導入時点では対象サーバ個々の構成管理は出来ていなかったため、実行時に対象サーバに接続し都度取得できるよう以下のようなコードとしました。） $ roles/zabbix/tasks/host_setting.yml --- - name: Create host on Zabbix local_action: module: zabbix_host server_url: "http://192.168.1.10/zabbix" login_user: admin login_password: admin host_name: "{{ ansible_fqdn }}" host_groups: - test link_templates: - Template_OS_Linux_Monitor status: enabled state: present interfaces: - type: 1 main: 1 useip: 1 ip: "{{ ansible_eth0.ipv4.address }}" dns: "" port: 10050 以下のコマンドで実行してみます。 $ ansible-playbook -i inventories/hosts zabbix_host_set.yml Zabbixサーバ側を確認するとホスト名や IPアドレス も誤りなく登録されています。 　　　 実際に私が利用したケースでは、Zabbix上のホスト設定の IPアドレス 部分の更新が必要となったため、 上記のようなコードで設定を一括更新しました。 御覧の通り実装はすごく簡単なため、似たような手動の運用がある場合はすぐに切り替えることをお勧めします。 メンテナンス設定 次に簡単ではありますが、メンテナンス設定時に利用するzabbix_maintenanceモジュールについて記載します。 Zabbix上のホストグループ単位でメンテナンス設定を入れる場合は必要性はあまり感じませんが、 特定のホストグループ内の数十台だけにメンテナンス設定したいといった場合 はかなり役立つと思います。 具体的には以下の形でコードを作成しました。 $ add_zabbix_maintenance.yml - hosts: localhost connection: local tasks: - name: Create maintenance Setting connection: local zabbix_maintenance: # 利用モジュールの指定 name: Maintenance for VersionUP # メンテナンスの名前 state: present # メンテナンス設定の有無、『present』は登録、『absent』であれば削除になる collect_data: yes # メンテナンスタイプの『データ収集あり』か『データ収集なし』の設定 minutes: 300 # メンテナンス期間（ここでは設定反映時点から300分間のメンテナンス設定となる） server_url: http://192.168.1.10/zabbix login_user: admin login_password: admin host_names: # メンテナンス設定を行うホスト - test-vm01.localdomain - test-vm02.localdomain メンテナンス設定対象のホスト名を最後のhost_names以下に羅列し、 以下のコマンドを実行します。 $ ansible-playbook add_zabbix_maintenance.yml 実行後、確かに意図した通りのメンテナンス設定が入っており、指定したホストもメンテナンス対象に指定されています。 ただし、実行した時間からメンテナンス設定が開始となります。 この部分についてはメンテナンスの開始・終了時間が指定できればと惜しく思ったところです。 他力本願でお恥ずかしいですが今後のモジュールのメンテナンスに期待したいと思います。 　　　 終わりに Ansible Zabbixモジュールを用いたZabbixサーバ上の設定自動化を紹介しました。 Zabbixサーバ設定を自動化するにはZabbixAPIを利用する方法も考えられますが、 API は使い慣れていないけど、Ansibleなら使っているといった方にはこのZabbixモジュールを利用する方が導入しやすいと思います。 今回は設定作業をAnsible Zabbixモジュールで自動化した形ですが、Ansible本来の目的はコードでの構成管理です。 そのため今後は、Zabbixモジュールを用いてZabbixサーバ自体の構成管理を進めていければと考えています。 以上、最後までお読み頂きましてありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

Gitの既存 リポジトリ を使って開発を始めるにあたって、皆さんまずは リポジトリ を複製しますよね？ 本投稿では、 git clone コマンドの基本的な使い方〜便利なオプションの紹介 をさせていただきます。 Gitを使い始めたばかりの方から、オプションは使用していなかった！という玄人の方まで、開発する際の参考にしていだければ幸いです。 弊社ブログのGitに関わる関連記事もぜご一読ください！ - 【超入門】初心者のためのGitとGitHubの使い方 - 【Git入門】git stashで作業を便利に退避する - 【Git入門】git commitを取り消したい、元に戻す方法まとめ 目次 目次 git cloneって？ git cloneの基本的な使い方 別名で保存したい場合 カレントディレクトリ以外に保存したい場合 git cloneのオプション紹介 クローンしたいブランチを指定する クローン時のメッセージを非表示にする originに別名を付ける 指定数のコミットのみを取得する チェックアウトを行わない まとめ 　 git clone って？ git clone とは、 既存の リポジトリ をローカル環境に複製するコマンド のことです。 リポジトリ の場所はリモートでもローカルでも構いません。 Gitでは ソースコード だけでなく、 画像 markdown 等のテキストファイル ER図、 UML 図等の画像を生成するファイル 等、開発に使用するための様々なファイルを格納することが可能です。 ER図、 UML 図等は GitHub やGitLab上で描画できるので、 ソースコード 以外でバージョン管理したいファイルも全て集約することができますね。 git clone の基本的な使い方 $ git clone [リポジトリパス] 上記コマンドにより、指定した リポジトリ をカレント ディレクト リに複製することができます。 指定がない場合は リポジトリ の名前のままでローカルに保存されます。 GitHub の リポジトリ を指定した際の使用例を以下に記します。 $ git clone https://github.com/[ユーザー名]/[リポジトリ名].git private リポジトリ の場合は、 git clone 時にパスワード認証か SSH 公開鍵の設定が必要となります。 別名で保存したい場合 ローカルに保存する際に別名を指定したい場合は、下記のように ディレクト リ名をパスの後ろに記載します。 $ git clone [リポジトリパス] [ディレクトリ名] ディレクト リ名が更新されるだけで、 リポジトリ の内容は変わりません。 カレント ディレクト リ以外に保存したい場合 指定がない場合はカレント ディレクト リに保存されますが、別 ディレクト リの指定も可能です。 $ git clone [リポジトリパス] [パス]/[ディレクトリ名] パスには 絶対パス 、 相対パス どちらでも指定可能です。 git clone のオプション紹介 git clone コマンドには様々なオプションがあります。 オプションは以下コマンドで参照可能です。 $ git help clone コマンドを実行すると、以下のような結果が出力されます。 NAME git-clone - Clone a repository into a new directory SYNOPSIS git clone [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--no-tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--filter=<filter>] [--] <repository> [<directory>] DESCRIPTION Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch --remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch. （中略） OPTIONS -l, --local When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. （後略） コマンドの使い方とオプションに関する説明が詳細に出力されます。 英語が堪能な方はこちらの公式ヘルプだけでなんとでもなりそうですね。 本投稿ではこのオプション群の中からいくつかを抜粋して紹介させていただきます。 オプション ショートオプション 用途 --branch -b クローンしたいブランチを指定する --quiet -q クローン時のメッセージを非表示にする --origin -o origin に別名を付ける --depth 指定数のコミットのみを取得する --no-checkout -n チェックアウトを行わない ※以降の例ではショートオプションをしています。 クローンしたいブランチを指定する git clone コマンドは指定がない場合 main ブランチを取得しますが、特定のブランチを指定したい場合は -b オプションを使用します。 $ git clone -b [指定したいブランチ名] [リポジトリパス] クローンされた リポジトリ で git branch コマンドを実行すると、指定したブランチ名で複製されていることが確認できます。 また、ブランチ名の代わりにタグを指定することも可能です。 クローン時のメッセージを非表示にする git clone コマンドはデフォルトで下記のような進捗状況が出力されるようになっています。 （ --progress オプションと同様の動きをします。） Cloning into 'XXXXX'... remote: Enumerating objects: XXX, done. remote: Counting objects: 100% (XX/XX), done. remote: Compressing objects: 100% (XX/XX), done. remote: Total XXX (delta X), reused XXX (delta X), pack-reused XXXX Receiving objects: 100% (XXX/XXX), XX MiB | XX MiB/s, done. Resolving deltas: 100% (XXX/XXX), done. この進捗状況を非表示にする際には -q オプションを使用します。 $ git clone -q [リポジトリパス] origin に別名を付ける リモー トリポジ トリから git clone をする場合、デフォルトの リポジトリ 名である origin がクローンされます。 #オプション無しで実行した場合 git branch -a * main remotes/origin/HEAD -> origin/main remotes/origin/feature/hogehoge -o オプションを使用することで、 origin 以外の名前を指定することができます。 （ origin とはリモー トリポジ トリのアクセス先に対してデフォルトで付く名称です。） $ git clone -o [指定したいorigin以外の名前] [リポジトリパス] 確認すると、指定した名前でクローンできていることが分かります。 #オプション有りで実行した場合（例では「target」と呼称） git branch -a * main remotes/target/HEAD -> target/main remotes/target/feat/hogehoge また、下記例のように git remote コマンドでもアクセス先を確認することができます。 $ git remote -v 指定数のコミットのみを取得する 開発が進んでくると git clone をするだけで、数分を要するような リポジトリ も出てくると思います。 特定のブランチを指定するオプションも先ほどご紹介しましたが、さらにコミット数を指定することも可能です。 過去分のコミットが不要な場合は、このオプションを使用することで軽量にクローンすることができます。 $ git clone --depth=1 [リポジトリパス] [ブランチ名] 例では「1」を指定して、最新のコミットのみを取得対象としています。 ブランチを指定しない場合は、デフォルトブランチが取得対象となります。 チェックアウトを行わない git clone をデフォルトで実行すると自動的にチェックアウトが行われますが、チェックアウトを行わないことでクローン時のサイズを抑えることができます。 $ git clone --no-checkout [リポジトリパス] チェックアウトが実行されないので、クローン後の ディレクト リには .git のみが作成されます。 $ ls -a . .. .git ちなみに、この空っぽの状態から特定の ディレクト リをチェックアウトするには、 sparse-checkout コマンドを使用します。 $ git sparse-checkout init $ git checkout Your branch is up to date with 'origin/main'. まとめ Git入門ということで、 git clone コマンドの使い方と一部オプションをご紹介しました。 git clone は開発初期に一度実行するきりで使用頻度はあまり高くないと思いますが、オプションを組み合わせることでローカルのサイズを抑えたりデフォルトでは実現できない特別な使い方が可能になるので、よろしかったら参考にしてください。 　 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、技術広報の yoneshin です。 当社が定期開催している『Meetup』 次回は2022/7/6開催 『 SaaS プロダクト開発をリードするデザインとフロントエンド』 と題して 当社 プロダクトデザイナー とフロントエンドエンジニア達が開発事例をご紹介 ！！ 参加申込方法 イベントに参加したい！という方は、TECHPLAY 又は connpass 経由からお申込みをお願いします！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com 当社取組みやメンバーへの質問、情報交換、交流機会として どなたも是非お気軽にご参加ください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の飯野です。 2022/6/22(水)に開催されましたLTイベント「 potatotips #78 iOS / Android 開発Tips共有会 」に弊社メンバーが登壇しました！ 当日の発表内容をまとめさせていただきます。 目次 目次 イベント詳細 ラクスエンジニアの登壇内容 アーキテクチャを明文化して開発に臨んだ話 終わりに イベント詳細 potatotipsは iOS / Android アプリを開発する中で見つけたTipsをLT（Lightning Talk ）形式で共有しあう会です。 とあるように「potatotips」は iOS / Android アプリに関連するTipsに特化したLTイベントとなっております。 名前が可愛いLTイベントですよね。 ネーミングセンス勉強になります。 当日のイベントページはこちらです。 potatotips.connpass.com また、当日の発表者一覧は GitHub で確認できます。 github.com ラク スエンジニアの登壇内容 アーキテクチャ を明文化して開発に臨んだ話 弊社からは楽楽精算のモバイル開発でテッ クリード を担う佐藤さんに登壇いただきました。 Android Architecture を明文化して 新規開発に臨んだ話 〜 Architecture を事前準備して臨んだ開発を振り返る 〜 speakerdeck.com 発表で伝えたいこと - 開発開始前に Architecture を明文化して良かったこと＆課題となったこと 背景 - ラク スではNative(Kotlin)版とCordova版の2つの Android アプリをリリースしている - Native版はバージョンアップを進めていたが、Cordova版ではタ イムリ ーな対応ができていなかった - CordovaがEOLになった場合はセキュリティリスクが生じる懸念がある - 市場にCordovaエンジニアが少なく、採用も難しい →心機一転Native版に作り替えることに！ チームの現状 - チームは若手が中心だったため、基本的方針としてArchitectureを定めることに Architecture選定にあたって - 若手が中心なチームだったため Android の公式Architectureである MVVM Architecture を採用することに 3層レイヤー構造による構成 - プレゼンテーションレイヤー - ドメイン レイヤー - データレイヤー - 上記3層を基本的なレイヤー構造として採用 様々な明文化 - レイヤー毎のパッケージ構成も図と共に明示 - 基本クラスのルールも明文化 開発を進めて感じたこと - チームの基本的な技術力が向上する - 開発中に基本的な アーキテクチャ の議論をすることがない - 責務によりクラスを小さく分けたためテストが書きやすい 課題に感じたこと - パッケージ構造 - 各レイヤー毎の依存性 まとめ - Architectureを明文化すると以下のような恩恵が！ - チームの基本的技術の向上→生産性の向上 - 品質の向上 当日の twitter （ #potatotips ）では、 Android 公式のArchitectureとかあるのかー Android の アーキテクチャ は、公式の ガイドライン に従うのがベターですよね…！ 公式の アーキテクチャ ガイドがあるの、やっぱいいよなあ 明文化大事 久しぶりに Android もやってみたくなってきた！最近ご無沙汰していたからな。予め公式ドキュメントを読み合わせて明文化しておくのは良いですね。 事前に アーキテクチャ を明文化するの、すごいよさそう といったご感想をいただきました！ コメントで盛り上げていただいた皆さま、ありがとうございました。 終わりに ラク スでは Android エンジニアの採用を行なっております。 career-recruit.rakus.co.jp また、引き続き外部イベントへの参加も積極的に行ってまいります。 弊社主催のイベントもたくさんご用意しておりますので、ご興味のある方はぜひご覧ください！ rakus.connpass.com techplay.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

こんにちは、技術広報の yayawowo です。 皆さん！ 2022年6月19日(日)に開催した JJUG CCC 2022 Spring に参加されましたでしょうか？ 今回は、 弊社テッ クリード が発表した内容 をまとめさせていただきましたので 当日 JJUG を視聴できなかった方、視聴したけれど改めてレポートを読みたい！という方のご参考になれば幸いです！ 目次 目次 ラクスエンジニアの登壇内容 短納期でローンチした新サービスをJavaで開発した話 協賛内容 終わりに ラク スエンジニアの登壇内容 短納期でローンチした新サービスを Java で開発した話 発表者：a1（ @eichisanden ） 　　　　 2022/06/19 10:00〜 Track D (# jjug _ccc_d) Video:40min + Live:10min speakerdeck.com 当社テッ クリード の三田さんより、 『サービス開発の理想と現実・短納期でローンチした新サービスを Java で開発した話』をテーマに登壇いただきました！ ◆ 発表内容まとめ 　 今回開発したサービス「 楽楽電子保存 」について ・電子請求発行システム「 楽楽明細 」で受け取った電子請求書等の帳票を電子保存/一元管理できる無料サービス ・2022年1月からの改正 電子帳簿保存法 の要件にも対応 開発体制 ・既存サービスを開発している2チームが開発 Java のバージョン ・Java11 or Java17 どちらにする？ ・Java17を採用 ・Java17の良かった機能について フレームワーク ・Spring Bootを採用 API クライアント ・OKHttp（Retorfit）を採用 マルチテナント構成 ・マルチテナント構成とは？ ・単一データベース/共通 スキーマ 方式を採用 セキュリティ ・認証や CSRF チェックはSpring Securityを採用 タイムゾーン 対応 ・Timezoneありきでの実装 フロントエンド ・Reactを採用 ・関連発表内容 　・参考） フロンエンド・バックエンド分離の道のり クラス設計 ・3層 アーキテクチャ ・3層 アーキテクチャ のメリット/デメリット ・オニオン アーキテクチャ を採用 ログ ・ContentCachingRequestWrapper、ContentCachingResponseWrapperを使用 当日 Twitter からは、 「検討と試行錯誤の過程が見て取れて素敵でした！」 「自分が考えていることや参考にしてる書籍もほぼ同じ！自分がこの登壇やりたかった！」 「やはり、事前に社内勉強会などで啓蒙しておくことは重要そうだなぁ。」 などのコメントをいただきました！ ありがとうございます。 また、 はてブ のテク ノロ ジー にトレンド入りもし、本発表が SaaS 開発に携わる皆様のお役に立てていることを実感することができました。 協賛内容 ラク スは、2021年11月21日開催した JJUG CCC 2021 Fall に続き、 2021年6月19日開催の JJUG CCC 2022 Springに ロゴスポンサー として協賛させていただいております！ ccc2022spring.java-users.jp 今後も Java 関連の技術や事例を積極的に発信させていただきます！ 終わりに ラク スのテッ クリード の発表はいかがでしたでしょうか？ 是非 Java 技術者や、 SaaS 開発に携わるエンジニアの皆様の一助となれば幸いです。 今後も JJUG CCC Spring/Fallに、積極的に登壇/協賛していきたいと思います！ 最後までお読みいただきありがとうございました！！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに はじめまして。ikedamasa1221です。 私は2021年の末くらいからオフショア開発業務に関わりはじめ、 今年度からブリッジSEとしてオフショア開発業務に従事することになりました。 実はこれまではずっと開発者として機能開発などに携わっており、ブリッジSE業務は初めての経験になります。 時には苦戦しつつ、時には楽しみながら、早く一人前のブリッジSEとして仕事ができるように日々頑張っています。 このように ラク スで初めてオフショア開発に従事したのですが、以前からオフショア開発なるものがあることは見聞きしており、 ネットで記事を見たり経験者に話を聞くなどしてある程度のイメージを持っていました。 しかし『百聞は一見にしかず』という言葉にある通り、イメージと違う印象を受けるような出来事がいくつもありました。 私の経験が、 オフショア開発に興味がある人 これからオフショア開発に従事する人 ブリッジSEの道に進むかどうか迷っている人 の参考になれば幸いです。 あくまで私の個人的な体験談であるため、客観性や正確性に欠く記述が多分に含まれると思いますが、どうかご了承ください。 また本記事は ブリッジSEとしてオフショア開発業務に携わる一個人 としての視点で書かれています。 事業としてオフショア開発に興味がある、またはオフショア開発事業を始めるかどうか検討されている方は、 コチラ を参考にしていただきたいです。 目次 はじめに 目次 オフショア開発とは オフショア開発に従事して感じたギャップ 話す言語の違いについて 慣習や国民性の違いについて 仕事の進め方について 品質について まとめ オフショア開発とは 本題に入る前に、簡単にオフショア開発についてまとめさせていただきます。 オフショア開発とは、 自社で行っていたシステム開発業務の全部または一部を海外の現地法人に委託すること です。 日本よりも人件費が安い海外で システム開発 を行うことにより、コスト削減などが見込めるというメリットがあります。 また日本では、近年の人口減少によって人材不足が深刻化しており、その解消のためにオフショア開発の活用が注目されているという側面もあります。 以前はオフショア開発の委託先として中国が選ばれることが多かったようですが、最近は ベトナム やフィリピンといった東南アジアの国々に人気が集まっているようです。 委託先の国選びにおいては、その国の人件費、教育水準（特にIT教育と言語教育）、国民性などの事情が考慮されることが多いとのことでした。 ラク スもオフショア開発拠点（ ラク ス ベトナム ）を2014年に新規で立ち上げており、その規模は年々拡大しています。 オフショア開発に従事して感じたギャップ それでは私が初めてオフショア開発に従事して感じた、イメージとの違いやギャップについてお話させていただきたいと思います。 読者のみなさんには、みなさん自身が抱くオフショア開発やブリッジSEの仕事のイメージを思い浮かべながら読んでいただけると嬉しいです。 話す言語の違いについて 以前のイメージ「英語すら十分に話せない自分が仕事の依頼やレビューなんてできるだろうか...？」 ↓ 実際に働いてみて「なんとかなる。でも英語は話せた方が仕事の幅は確実に広がりそう。」 オフショア開発と聞いて最初に思い浮かべるのが話す言語の問題かと思います。 私は今のところ、最低限はどうにかなると感じています。 まずオフショア開発拠点に英語を理解できる方が多く、またチャットなどの文字ベースのコミュニケーションが多いため、英語の読み書きができれば最低限の意思疎通は図ることができると感じています。 特に"書き"の部分が大変ですが、翻訳ツールなどを活用すれば難しい内容や複雑な内容も伝えることができます。 ただし、大学入試程度の読み書きはできた方が良いのではないかと思います。 というのも、翻訳ツールがこちらの意図通りに翻訳してくれない場合があり、そういった誤訳に気づくためです。 （これはツールの問題ではなく元の文章の問題であることが多いで悪しからず。） 加えて、日本語と ベトナム語 の両方を話せる人の存在にも助けられています。 オフショア開発拠点に通訳の方や日本語が話せるエンジニアがいるため、仕事を依頼するときや会議の時に通訳をお願いしています。 しかし日本語が完璧に理解できるというわけではないので、こちらも難しい言葉や独特の言い回しを避けるなど、相手が理解しやすい話し方を行うことが重要になります。 このように最低限の仕事を行うことはできているものの、英語または ベトナム語 を話せた方が仕事の幅は確実に広がると思います。 隣の席のブリッジSEが ベトナム人 の方なのですが、日々の進捗確認や実装方法の相談、成果物レビューのフィードバックを通訳を介さずビデオ通話されているのを見るとその方が確実に仕事が捗るよなぁと思います。 オフショア開発拠点に英語が話せる方も多いと聞いているので、 英会話教室 などに通って勉強しようかと少し真剣に考えはじめているところです。 慣習や国民性の違いについて 以前のイメージ「慣習や国民性の違いで諍いや行き違いが頻発してトラブルが多そう...」 ↓ 実際に働いてみて「相手に配慮することは大変だが、それが信頼関係につながる！」 日本と ベトナム では慣習や国民性が違う点もあり、その違いが原因で失敗したこともあります。 例えば、日本人は直接的な表現よりも間接的または遠回しな表現を好む傾向にあると聞いたことがあります。 ところが ベトナム の方は真逆らしく、私が「○○を参考にして欲しい（○○の通りに実装して欲しいな...）」とコメントしたら全く別の方法で実装されてしまったことが何度かありました。 これは文字通り参考例の一つとして受け取られてしまったようで、私も日本人特有といわれる 空気 の力に頼ったコミュニケーションに慣れていたことを思い知らされました。 （もちろん日本人が相手の場合でも意図が伝わり辛いコメントの仕方なのではないかと反省しています。） 私はこのような地雷を一つずつ踏み抜きながら学んでいる最中なので、ときに疎ましく感じてしまうこともあります。 一方で、私の所属するチームでは週に一回オフショア開発拠点のメンバーに感謝を伝えるという取り組みを行なっています。 これは日本人と真逆で、 ベトナム人 は自分の仕事に自信や誇りを持つ人が多いという国民性の違いに配慮した取り組みです。 この取り組みは評判が良いようで、モチベーションや 帰属意識 の向上に繋がっているという声を聞きます。 このように、相手の慣習や国民性に配慮することは一朝一夕にできないことが多くて大変です。 しかしこちらが配慮すれば仕事もうまく進むようになり、この積み重ねが信頼関係の構築につながっているように感じています。 仕事の進め方について 以前のイメージ「オフショア開発拠点から質問や問い合わせが大量に来て、対応するのがとても大変そう」 ↓ 実際に働いてみて「思ったより質問や相談が来ない！？」 実は私が体験したことの中で、最もギャップを感じたのはこの点です。 オフショア開発先のエンジニアは依頼内容に不明点などがあっても確認せずに開発を進めてしまう方が多い傾向にあるように感じています。 例えば不具合修正の場合、ブリッジSEが依頼内容を整理したドキュメントを作成し、必要があればビデオ通話で内容を説明するなどして修正を依頼します。 このとき依頼ドキュメントの内容に間違いや漏れが出てしまうことがありますが、そういった不明点を確認しないまま仕事を進めてしまう方が多い印象を受けます。 レビューのときに間違いに気付くことができますが、場合によっては手戻りが発生して 工数 が無駄になってしまいます。 この点についてオフショア開発の経験が豊富な方に聞いてみたところ 「不明点を都度確認したり、曖昧な仕様を少しずつ相談して明確化しながら開発を進める人の方が少数だ」 と教えていただいて、とても大きなカルチャーショックを受けました。 もちろん、オフショア開発拠点側から見ると距離的な問題や話す言語の違いによって気軽に質問しづらい環境であることも理由の一つだと思うので一概には言い切れません。 しかし私自身、このギャップを受け止めて仕事のやり方を変えなければ！と思いました。 例えば、下記の点に気をつけながら仕事を依頼できるように心がけています。 依頼前の準備を怠らず、なるべくブリッジSE自身が不明点を解消してから依頼ドキュメントの作成や仕事の依頼を行う 重要な内容は口頭で伝えるだけでなく資料等に記載し、文字ベースの情報を残す 定期的に声をかけるなどして質問しやすい雰囲気を作る 質問は早めに返す（返事が遅ければ質問しても意味がないと思われてしまい、質問してくれないようになってしまうため） 可能であれば中間成果物を提出してもらい、認識齟齬がないか確認しながら仕事を進める 以上のような互いの考えや癖を知ることができれば対策を立てることができ、お互いに気持ちよく仕事ができるようになると考えています。 こういった小さな違いを敏感に感じ取ることも、ブリッジSEに求められる役割の一つであると感じています。 品質について 以前のイメージ「品質が悪く可読性の低いコードばかりでレビューが大変なんじゃないだろうか...？」 ↓ 実際に働いてみて「品質はそれほど悪くないが、保守性や可読性に少々難があるように感じる。」 私のチームでは、オフショア開発先が提出した成果物のレビューは ブリッジSE→日本のエンジニア の順番で行います。 このため、ブリッジSEがありのままの状態の ソースコード をレビューすることになります。 今まで、何回かレビューする機会がありましたが、冒頭の通り品質はそこまで悪くないと感じています。 やはり日本のエンジニアと比べて仕様の理解に差があるためテスト観点の漏れなどが見つかりますが、 主要なケースは一通り網羅されているように感じています。 一方で ソースコード の保守性や可読性には少々難があるように感じています。 例えば 命名 がわかりにくい コメントがあまり書かれていない ネストが深かったり整理しきれてない分岐がある 責務分割の観点から見て適切なクラスに処理が実装されていない 等、様々な指摘が行われます。 やはり話す言語の問題、仕様理解や アーキテクチャ 理解の差、スキルセットの違いなど様々な原因があると思われますが、こういった問題への対応は日本とオフショア開発先の間に立つブリッジSEの重要な役割であると思います。 実際に私の所属するチームでは、英語に訳したレビュー観点一覧を作成したり、オフショア開発先での内部レビューを支援するために日本のエンジニアに聞いたコツやノウハウを共有するなど様々な取り組みを行っています。 こういった取り組みを通して日本とオフショア開発先のエンジニアの両方に貢献できることもブリッジSEの醍醐味ではないかと思います。 まとめ 私自身、初めての経験ということもあり毎日いろんな壁にぶつかっています。 しかしブリッジSEの仕事を経験できたことは非常に幸運だと思っています。 特に話す言語や慣習が違うからこそ、 誰かと一緒に仕事をする上で普遍的に重要なこと が学べているのではないかと考えています。 また自分と文化的な背景が異なる人と働くことということは、それだけで仕事以外でも様々な気づきを得られてなかなかに知的好奇心を刺激されます。 （私もコロナが落ち着いたら ベトナム に行ってみたくなりました。） 以上の内容が、オフショア開発やブリッジSEという仕事に興味を持つきっかけになれば幸いです。 長文になりましたが、最後まで読んでいただき本当にありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 です。 今回は、 ラク ス初開催の 『Cloud Native TechCafe』 について、ご紹介させていただきます！ テーマは、 『「 クラウド ネイティブ入門」を語る』 ！！ コンテナ化、CI/CD、 Kubernetes 等の入門内容を一緒に学びつつ、交流を深めてみませんか？ TechCafeとは 「クラウドネイティブ入門」を語るCloud Native TechCafe 開催概要 主催出演者の紹介 語り合う内容 参加申込方法 終わりに TechCafeとは エンジニアと技術が交差する、憩いの場（カフェ）として ラク スが開催しているイベントになります。 年に数回程度の頻度で開催しており、現在はオンラインで実施しています。 ラク スでは類似イベントとして、 PHP TechCafe フロントエンドTechCafe がございます。 テーマをご確認の上、ご興味ある内容でしたら是非ご参加ください！ 「 クラウド ネイティブ入門」を語るCloud Native TechCafe 開催概要 今回のテーマは「 クラウド ネイティブ入門」を語り合います。 【日　時】2022/6/22(水) 19:00～20:30 【会　場】オンライン（Zoom） 【参加費】無料 【主　催】 ラク ス ◆ こんな方におすすめ コンテナ/ Kubernetes を学びたい方 コンテナ/ Kubernetes の動向に興味、関心がある方 最新のインフラ技術トレンドをキャッチアップしたい方 他社の クラウド ネイティブ活用にご興味がある方 自社でインフラ構築を担っている方 クラウド ネイティブなインフラ領域に幅を広げてみたいエンジニアの方 などなど 申込枠としましては、 リスナー枠 をご準備しております！ リスナー枠とは？ 文字通り、聴くのみのご参加 マイク・カメラOFFでOK チャットや Twitter でのコメント参加、大歓迎 是非、コメントにて一緒に語り合いましょう！ 主催出演者の紹介 ◆ 金本 宏司 2002年～　SIにてオンラインゲームのインフラ運用などを担当 2005年～　ツタヤオンライン入社　 ECサイト 、メール配信基盤のインフラ全般を担当 2009年～　カカクコム入社　 価格.com 、 食べログ などのインフラ全般を担当 2021年7月　 ラク ス入社 現在は、インフラ開発部の部長を務める ◆ 見形 親久 受託開発の現場で様々な開発現場を経験した後、自社サービスに関わりたいと考え2016年 ラク スへ入社。 楽楽精算のアプリケーション開発、サービス運用を担当、2021年よりインフラ部門にてSREチームを担当。 現在はSREチームにて サブスクリプション 管理の基盤構築、サービス全般のDevOps推進を担当。 1981年生まれ 栃木県出身 趣味は、 スノーボード 、サウナ、呑み歩きです。 語り合う内容 当日のタイムテーブルと語り合う内容は、以下の通りです！ ◆ タイムテーブル 時間 内容 19:00 開始・ご挨拶など 19:10～ 自己紹介 19:15～ ディスカッション開始 20:20 アンケートのお願い、締めのご挨拶 20:30 終了 ◆ 語り合う内容 当日のShowNoteは以下の通りです！ hackmd.io ① クラウド ネイティブとは？ 　・各社何と言っているか？ 　・ Google が言う クラウド ネイティブ５つの原則 　・ マイクロソフト の説明詳細 　・ クラウド ネイティブにするために鍵になるのは？ 　　などなど ②情報収集方法 　・書籍 　・勉強会 　・記事 　・ メールマガジン 　などなど ③ クラウド ネイティブ関連の最新ニュース 　・気になったニュース（４～６月編） ※当日変更になる可能性がありますので、ご了承ください。 参加申込方法 イベントに参加したい！という方は、TECHPLAY 又は connpass 経由からお申込みをお願いします！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com 終わりに 「 クラウド ネイティブ入門」を語るCloud Native TechCafeの開催告知はいかがでしたでしょうか？ 今回、 ラク スとしては初めて開催する内容となっております。 皆様がお楽しみいただけるよう、コンテンツ準備を進めておりますので、是非是非ご参加ください！ 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

"リーダブルコード" ベトナム語 解説の第2回です。 ベトナム とのオフショア開発において可読性/保守性が高い開発が行えることを目的にして、 "リーダブルコード" やその他書籍、普段の経験を参照し、開発におけるテクニックをまとめました。 *1 この記事を ベトナム チームのメンバに読んでもらうことで、"リーダブルコード" の知識が日本チームと ベトナム チームの共通認識となり、コード品質が向上することを目的としています。 本稿は「ループとロジックの単 純化 」について解説します。 Đây là phần thứ 2 của loạt bài giải thích "Readable Code" bằng tiếng Việt. 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 2, giải thích về "Đơn giản hóa Loop and Logic". はじめに / Lời nói đầu この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Như là ngôn ngữ chung trong team ベトナムでの学習資料として / Được xem như là tài liệu học tập ở Việt Nam リーダブルコードについて / Về Readable Code 1. 変数の使い方に関するテクニック / Các Technique liên quan đến cách sử dụng biến 1-1. Explaining/Summary Variables 1-2. Not Use Useless Variables 1-3. Shrink the Scope of Variables アクセス修飾子を変えていい？ / Tôi có thể thay đổi access modifier không? 1-4. Specify the Type 2. 条件式に関するテクニック / 2. Các Technique liên quan đến biểu thức điều kiện 2-1. The Order of if/else Blocks 2-2. Strict Comparisons 2-3. Not Use Conditional Branch 3. ロジックの簡略化を行うテクニック / Các kỹ thuật thực hiện đơn giản hóa logic 3-1. Early Return 3-2. Minimize Nesting 4. 目的に合わせたコードにするテクニック / Techniques làm cho code đúng bản chất 4-1. Be General-Purpose Code 4-2. Simple is more important than Easy 4-3. Avoid Too Fat Code おわりに / Lời kết ベトナム メンバと理解する「 PHP リーダブルコード」 〜第2回 ループとロジックの単 純化 〜 ” PHP Readable code”hiểu được cùng với member Việt Nam 〜Chương 2 Đơn giản hóa Loops and Logic〜 はじめに / Lời nói đầu 先日はオフショア先である ベトナム のメンバ向けに、「表面的な改善」についてまとめました。 前回はコメントや 命名 などに関する内容でしたが、今回は実際に記載されているロジックに関する内容になります。 Hôm trước, tôi đã tổng hợp về "Cải thiện giao diện" của readable code, dành cho member VN là Offshore. Lần trước là về comment và naming, nhưng lần này là về logic được viết trong thực tế. これらのテクニックは、自分がコードを書く時だけでなく、既存のコードを読むときにも役に立ちます。 既存のコードがどうしてこのように記載されているのかを理解し、昔の実装者の意図を理解した上で修正を加えることで、保守性に優れたコードを維持することができます。 これらのテクニックを身につけて、保守性の高いコードを目指しましょう！！ Những kỹ thuật này không chỉ hữu ích khi bạn viết code mà còn khi bạn đọc code hiện có. Bạn có thể duy trì good code có tính bảo trì, bằng cách hiểu tại sao code hiện tại được viết như thế này, hiểu ý đồ của những người implment hồi trước và sau đó thêm chỉnh sửa. Hãy cùng trang bị những kỹ thuật này và hướng tới code có tính bảo trì cao nhé!! ◆ 関連ブログはこちら tech-blog.rakus.co.jp この記事の使い方 / Cách sử dụng bài viết này チーム内の共通言語として / Như 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] この条件の場合、これ以上処理は行われません。そのため「3-1. Early Return」にしてください。 [Vietnamese] Trường hợp là điều kiện này, các xử lý hơn nữa sẽ không được thực hiện. Do đó, hãy chọn "3-1.Early Return". https://tech-blog.rakus.co.jp/entry/ReadableCodeWithVietnam02#3-2-Early-Return Sample 2： [Japanese] この変数にはintegerしか入らないはずですので、厳密な比較を使ってください。 詳しくはこちらの「2-2. Strict Comparisons」を参照してください。 [Vietnamese] Vì các biến này chỉ chứa các số nguyên, nên hãy sử dụng các phép so sánh nghiêm ngặt. Để biết thêm chi tiết, hãy tham khảo ”2-2. Strict Comparisons” ở đây. https://tech-blog.rakus.co.jp/entry/ReadableCodeWithVietnam02#2-4-Strict-Comparisons ベトナム での学習資料として / Được xem như là tài liệu học tập ở Việt Nam ベトナム語 に翻訳しているため、 ベトナム の方でも読みやすいはずです プロジェクトに参画した ベトナム メンバの学習資料として利用できます Vì được dịch sang tiếng Việt nên có lẽ sẽ dễ đọc ngay cả với người Việt Nam Có thể sử dụng làm tài liệu học tập cho các thành viên Việt Nam đã tham gia dự án リーダブルコードについて / 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. 1. 変数の使い方に関するテクニック / Các Technique liên quan đến cách sử dụng biến 変数の使い方を変えることで、ロジックはとても読みやすく、バグが入りづらくなります。 Bằng việc thay đổi cách sử dụng các biến, thì logic sẽ trở nên rất dễ đọc và khó bị bug hơn. 1-1. Explaining/Summary Variables #変数 #命名 #可読性 #Biến #Naming #TínhDễĐọc 説明/要約変数 Các biến mô tả/ biến tóm tắt ややこしいコードを変数に入れてしまえば、そのコードが何を表しているのか変数名が説明してくれるため、すぐ理解ができるようになります。 （この時の変数名が値の説明になっていないと意味がないので注意してください。） Nếu bạn cho code dễ nhầm lẫn vào trong biến, vì tên biến sẽ giải thích là code đó đang biểu thị cái gì nên sẽ giúp ta hiểu được ngay lập tức. (Xin lưu ý rằng sẽ không có ý nghĩa gì nếu tên biến lúc này không giải thích được cho giá trị.) ❌ Bad Code <?php if ( explode ( "/" , $ url )[ LAST_KEY_NUMBER ] === "root" ) { ... } ✅ Good Code <?php $ userName = explode ( "/" , $ url )[ LAST_KEY_NUMBER ] ; if ( $ userName === "root" ) { ... } また、変数を使って処理の内容を要約してしまうことでも、読みやすさが向上します。 たとえば、以下のようにあまり大きくない処理でも、結果を変数に入れることによって何を行いたいのかが理解できるようになります。 Ngo ài ra, cũng có thể nâng cao tính dễ đọc bằng sử dụng biến để tóm tắt nội dung xử lý. Ví dụ, có thể hiểu những gì muốn làm bằng cách đặt kết quả vào một biến, ngay cả ở xử lý không quá lớn như bên dưới. ❌ Bad Code <?php if ( $ mail -> comments [ $ index ] -> userId === $ session -> userId ) { // User thì có thể edit comment. // ユーザはコメントを編集できる } ✅ Good Code <?php $ isWritableUserComment = ( $ mail -> comments [ $ index ] -> userId === $ session -> userId ) ; if ( $ isWritableUserComment ) { // User thì có thể edit comment. // ユーザはコメントを編集できる } 1-2. Not Use Useless Variables #変数 #EarlyReturn #ガード節 #Biến #GuardClause 役に立たない変数を使わない Không sử dụng các biến vô ích 前述した説明/要約変数は、特に説明せずとも伝わる処理で使う必要はありません。 例えば、以下のように変数にまとめなくてもわかるような処理には使用する必要はありません。 Đối với xử lý mà vẫn truyền đạt được ý nghĩa mà không cần bất kỳ giải thích nào thì không cần sử dụng các biến giải thích / biến tóm tắt đã nêu trên. Ví dụ ở xử lý hiểu được mà không cần tổng hợp vào biến như dưới đây thì không cần thiết phải sử dụng. ❌ Bad Code <?php $ userId = $ session -> user -> userId; $ updateUserId = $ userId ; ✅ Good Code <?php $ updateUserId = $ session -> user -> userId; // Truyền tải đầy đủ ý nghĩa 他にも、以下の $targetKey のような 中間結果 を記録するためだけに使う変数も不要なので削除しましょう。 このような中間結果を記録する変数は、コードの理解の助けにはなりません。 Ngo ài ra, biến sử dụng chỉ để ghi kết quả trung gian , như $targetKey bên dưới thì cũng không cần thiết nên hãy xóa đi. Các biến ghi lại kết quả trung gian như vậy không giúp ta hiểu được code. ❌ Bad Code <?php /** * Xóa user đã được chỉ định khỏi danh sách người gửi mail * メール送信者リストから指定されたユーザを削除する */ function removeUserFromToAddressList ( array $ addressList , int $ removedUserId ) { foreach ( $ addressList as $ key => $ address ) { if ( $ address [ "userId" ] === $ removedUserId ) { $ targetKey = $ key ; } } array_splice ( $ addressList , $ targetKey ) ; return $ addressList ; } 詳しくは後述しますが、以下のように Early Return を行うことで、 $targetKey を削除することができます。 Chi tiết sẽ được mô tả sau, nhưng bạn có thể xóa $targetKey bằng cách thực hiện Early Return như sau. ✅ Good Code <?php /** * Xóa user đã được chỉ định khỏi danh sách người gửi mail * メール送信者リストから指定されたユーザを削除する */ function removeUserFromToAddressList ( array $ addressList , int $ removedUserId ) { foreach ( $ addressList as $ key => $ address ) { if ( $ address [ "userId" ] === $ removedUserId ) { array_splice ( $ addressList , $ key ) ; return $ addressList ; // Early Return } } } 1-3. Shrink the Scope of Variables #変数 #スコープ #Biến #Scope 変数のスコープを狭くする Thu hẹp phạm vi của các biến このテクニックは非常に有効です。 このテクニックはコードの読みやすさを上げるだけでなく、度重なる変更に強くなり、バグを含みにくいコードを作ることができます。 Technique này rất hiệu quả. Kỹ thuật này không chỉ làm cho code của bạn dễ đọc hơn mà còn làm cho nó có khả năng chống lại các thay đổi lặp lại nhiều lần và làm cho code của bạn ít bug hơn. 変数のスコープを広くしてはいけません！！スコープが広く、寿命が長い変数は、以下のような問題を引き起こします。 変数の値がどこで変更されているかわからなくなる 間違って変数の値を上書きしてしまう危険がある 広い範囲でその変数の値を覚えながらコードを読まないといけなくなってしまう 影響範囲が多くなり、修正が難しくなる Không được phép mở rộng phạm vi của biến!! Biến có phạm vi rộng và tuổi thọ lâu sẽ gây ra các vấn đề như: Sẽ làm cho bạn không biết giá trị của biến đã được thay đổi ở đâu Có nguy cơ vô tình ghi đè nhầm lên giá trị của một biến Bạn vừa phải đọc code vừa nhớ giá trị của biến đó ở một phạm vi rộng. Phạm vi ảnh hưởng sẽ trở nên nhiều và làm cho việc chỉnh sửa trở nên khó khăn hơn. グローバル変数 を考えるとわかりやすいと思います。 グローバル変数 はどこでも読める一方で、どこでも書き換えることができてしまいます。 そのため、 グローバル変数 を使った処理を記述するときには、コード全体のどこで グローバル変数 の値が書き換わるかを調査してから使う必要があり、とても手間がかかります。 一方、スコープが狭い変数であれば、その変数が扱われている範囲をすぐ理解できるため、意図しない値の変更に怯えながら実装する必要はありません。 コードを読むときに考えることをできるだけ減らすためにも、その変数のスコープを狭くしましょう。 Tôi nghĩ sẽ dễ hiểu nếu bạn nghĩ về biến toàn cục (Global variables). Các biến toàn cục có thể đọc ở bất kỳ đâu, mặt khác có thể được viết lại ở bất kỳ đâu. Do đó, khi viết một xử lý đã sử dụng biến toàn cục, cần phải khảo sát xem giá trị của biến toàn cục được viết lại ở đâu trong toàn bộ đoạn code trước khi sử dụng, điều này rất mất thời gian. Mặt khác, nếu biến có phạm vi hẹp, thì bạn có thể dễ dàng hiểu được phạm vi mà biến đó đang được sử dụng do đó bạn không cần phải lo sợ trước những thay đổi ngo ài ý muốn của các giá trị. Hãy thu hẹp phạm vi của biến để giảm thiểu tối đa những suy nghĩ khi đọc code. 以下の例では、 foo() の内部で グローバル変数 $dirPath を書き換えていますが、元のコードではそれが見えません。 そのため、 グローバル変数 $dirPath が書き換えられていることに気づかず、実装者は違うファイルに書き込まれると勘違いして実装してしまいます。 Trong ví dụ sau, biến toàn cục $dirPath được viết lại bên trong foo() , nhưng bạn sẽ không thể nhìn thấy ở code gốc. Do đó, implementer sẽ không nhận thấy rằng biến toàn cục $dirPath đã được viết lại và sẽ implement với phán đoán sai rằng nó được ghi lại vào một file khác. ❌ ​Bad Code <?php global $ dirPath ; $ dirPath = "/usr/local/system/tmp" ; foo () ; $ filePath = $ dirPath . "/data.log" ; file_put_contents ( $ filePath , "user:Jonh login" ) ; // Tôi định ghi dữ liệu vào "/usr/local/system/tmp/data.log" // Trên thực tế, nó được viết vào "/tmp/data.log". // Bởi vì là đang viết lại $dirPath ở trong foo(). // // // "/usr/local/system/tmp/data.log" にテータを書き込んだつもりだが、 // 実際は "/tmp/data.log" に書き込まれてしまう。 // なぜなら、foo() 内で $dirPath を書き換えているから。 : : : function foo () { global $ dirPath ; $ dirPath = "/tmp" ; } $dirPath を グローバル変数 にせず、 foo() の引数にすることで、 $filePath が foo() で利用されていることを明確に示すことができます。 Bằng cách dùng $dirPath làm đối số của foo() mà không biến nó thành một biến toàn cục, có thể biểu thị rõ ràng việc $filePath đang được sử dụng trong foo() . ✅ Good Code <?php $ dirPath = "/usr/local/system/tmp" ; $ dirPath = foo ( $ dirPath ) ; // foo()で値が書き換えられていることがわかる/ Có thể hiểu rằng giá trị đã được viết lại ở $dirPath = foo($dirPath); // foo() $ filePath = $ dirPath . "/data.log" ; file_put_contents ( $ filePath , "user:Jonh login" ) ; : : : function foo ( $ dirPath ) { $ dirPath = "/tmp" ; return $ dirPath ; } グローバル変数 でなくても、クラス内の、メンバ変数がミニ グローバル変数 化してしまうことがあります。 以下の例の場合、 $status がミニ グローバル変数 になっており、どこで変更されているかわからない状態になってしまっています。 Ngay cả khi nó không phải là một biến toàn cục, một biến member của một class có thể trở thành một mini global variable. Trong ví dụ dưới đây, $status đang là một mini global variable và bạn sẽ không biết rằng nó đã được thay đổi ở đâu. ❌ Bad Code <?php class StatusLogic { private $ status ; private function updateStatus () { $ this -> status = "ACTIVE" ; $ this -> changeStatusToCorrect () ; return $ this -> status; } private function changeStatusToCorrect () { $ this -> status = "INACTIVE" ; // Xử lý sử dụng $status} // $status を使う処理 } } 特に問題がないのであれば、 $status をローカル変数にすることで、各変数のスコープが狭くなります。 Nếu không có vấn đề gì, việc dùng $status làm một biến cục bộ sẽ làm thu hẹp phạm vi của các biến. ✅ Good Code <?php class StatusLogic { private function updateStatus () { $ status = "ACTIVE" ; $ status = $ this -> changeStatusToCorrect ( $ status ) ; return $ status ; } private function changeStatusToCorrect ( string $ status ) { $ status = "INACTIVE" ; // Xử lý sử dụng $status // $status を使う処理 return $ status ; } } アクセス修飾子を変えていい？ / Tôi có thể thay đổi access modifier không? #アクセス修飾子 #プロパティ #スコープ #AccessModifier #Property #Scope 以下のクラスでは、メンバ変数である $userName には private アクセス修飾子が指定されています。 Ở class sau, private access modifier được chỉ định cho biến member $userName . <?php class User { /** @var int User id */ private int $ userId ; /** @var string User Name */ private string $ userName ; // ★★★★★ public function __construct ( int $ userId , string $ userName ) { $ this -> userId = $ userId ; $ this -> userName = $ userName ; } } では、あなたが上司から、「このUserクラスの インスタンス から、 ユーザ名 を取得して表示するように」と指示された場合、どのように修正しますか？？ この場合、以下のように アクセス修飾子を変更することは避けた方がいい でしょう。 Vì vậy, nếu sếp của bạn yêu cầu bạn "lấy tên user từ instance của class User này để hiển thị", bạn sẽ chỉnh sửa như thế nào ?? Trong trường hợp này, bạn nên tránh thay đổi access modifier như sau. ❌ Bad Code <?php { /** @var int User id */ private int $ userId ; /** @var string User Name */ public string $ userName ; // ❌ Thay đổi từ `private` thành `public`!! public function __construct ( int $ userId , string $ userName ) { $ this -> userId = $ userId ; $ this -> userName = $ userName ; } } // Xử lý khác // 他の処理 $ user = new User ( 1 , "Jonh" ) ; $ userName = $ user -> userName; // Vì đã đặt `public` nên có thể đọc được. print ( $ userName ) ; アクセス修飾子を private から public に変更すると、このクラスの インスタンス を使う全ての処理から変数の参照と変更ができてしまうため、変数のスコープがとても広くなってしまいます。 最初にこの User クラスを実装した人は、何かの理由があって $userName を private にしていたはずです。 安易にアクセス修飾子を変更せず、変数のスコープを広くしない修正方針を考えるべきです。 Nếu bạn thay đổi access modifier từ private thành public , thì phạm vi biến sẽ trở nên rất rộng vì có thể tham chiếu và thay đổi các biến từ tất cả các xử lý sử dụng các instance của class này. Người đã implement class user này lúc đầu chắc có lẽ đã đặt $userName thành private vì có lý do nào đó. Bạn nên suy nghĩ về phương châm fix mà không thay đổi access modifier và không mở rộng phạm vi của các biến. たとえば、以下のように getter() を作成することで、少なくとも他の処理から $userName の上書きは行われなくなります。 Ví dụ: bằng cách tạo getter() như sau, ít nhất xử lý khác sẽ không ghi đè lên $userName . ✅ Good Code <?php class User { private int $ userId ; private string $ userName ; public function __construct ( int $ userId , string $ userName ) { $ this -> userId = $ userId ; $ this -> userName = $ userName ; } public function getUserName () { return $ this -> userName; } } : : // Xử lý khác // 他の処理 $ user = new User ( 1 , "Jonh" ) ; $ userName = $ user -> getUserName () ; print ( $ userName ) ; とはいえ、場合によっては private な値を他の処理からは全く読み取って欲しくないコードもあります。 そのときは、その値を使う処理をクラス内に実装するなどの工夫が必要です。 どのような意図でそのコードが記載されているかを読み取って、適切な実装を考える ことが大切です。 Tuy nhiên, tùy trường hợp, cũng có code mà bạn không muốn đọc được tất cả các giá trị private từ xử lý khác. Trong trường hợp đó, cần phải công phu hơn chẳng hạn như implement xử lý sử dụng giá trị đó ở trong class. Điều quan trọng là phải đọc được code đó đang được mô tả với ý định như thế nào và suy nghĩ về cách implement phù hợp . 1-4. Specify the Type #型 #Type 型を指定する Chỉ định type さて、せっかく ラク スのブログで PHP で記事を書いているので、 PHP ならではの注意事項も記載しておきます。 PHP はバージョンアップするたびに、型に厳格になってきました。文字列型と数値型の足し算ができなくなったり、 count() 関数の引数に配列以外の値を指定するとエラーになるようになった仕様変更がこれにあたります。 これに伴って、変数に予期しない型の値が入っていると、思わぬエラーが生じる場合があります。 そのため、今後作成する PHP コードでは、各変数にどの型が入るかを意識し、違う型の値が入らないようにするべきでしょう。 Nhân tiện, tuy không có mô tả trong Readable code nhưng vì tôi đã viết một bài blog về PHP trên blog của Rakus, nên tôi sẽ mô tả thêm mục chú ý chỉ đối với PHP . Mỗi khi PHP được nâng cấp, nó trở nên khắt khe hơn về type. Đó là thay đổi specification như: không thể cộng string type với numeric type, hoặc xảy ra lỗi khi chỉ định một giá trị không phải là mảng làm đối số của hàm count() . Cùng với điều này, nếu thêm kiểu giá trị không mong muốn vào biến, thì sẽ có trường hợp phát sinh error không lường trước được. Do đó, trong code PHP mà bạn sẽ viết trong tương lai, bạn nên ý thức ở các biến sẽ chứa type nào và tránh đưa vào các giá trị có type khác . たとえば、以下のように $result に数値や文字列が入るようなコードは避けましょう。 Ví dụ: chúng ta nên tránh code có chứa numerical value hoặc character string ở $result như bên dưới. ❌ Bad Code <?php $ countRows = count ( $ rows ) ; if ( $ countRows > 0 ) { $ result = $ countRows ; } else { $ result = "ERROR: NO RESULT" ; } ✅ Good Code <?php $ countRows = count ( $ rows ) ; if ( $ countRows > 0 ) { $ result = $ countRows ; } else { $ result = 0 ; } 2. 条件式に関するテクニック / 2. Các Technique liên quan đến biểu thức điều kiện コード中に条件式があると考えることが増えるため読みにくくなってしまいます。 とはいえ、コードから条件式をなくすことはできませんので、できるだけわかりやすい記述をすることが大事です。 Nếu có các biểu thức điều kiện trong code thì nó khó đọc hơn vì bạn phải suy nghĩ nhiều. Tuy nhiên, biểu thức điều kiện không thể bị xóa khỏi code, vì vậy điều quan trọng là phải viết nó dễ hiểu nhất có thể. 2-1. The Order of if/else Blocks #if文 #値の比較 #CâuIf #SoSánhGiáTrị if/else 文の順番 Thứ tự của lệnh if/else 特に理由がある場合以外は、否定より肯定の条件を先に書きましょう。 否定条件が先にあると、否定条件が重要な処理に見えてしまいます。 （もちろん、否定条件の方が重要な処理であれば、否定条件をはじめに書いても問題ありません。） Trừ khi có lý do đặc biệt, còn lại hãy viết điều kiện khẳng định trước điều kiện phủ định. Nếu điều kiện phủ định có ở phía trước, thì sẽ cho rằng điều kiện phủ định là một xử lý quan trọng. (Tất nhiên, nếu điều kiện phủ định là 1 xử lý quan trọng, bạn có thể viết điều kiện phủ định ngay từ đầu mà không có bất kỳ vấn đề nào.) ❌ Bad Code <?php if ( $ aaa !== $ bbb ) { ... } else { ... } ✅ Good Code <?php if ( $ aaa === $ bbb ) { ... } else { ... } 2-2. Strict Comparisons #型 #PHP #値の比較 #Type #SoSánhGiáTrị 厳密な比較 So sánh chặt chẽ こちらは PHP ならではの注意事項です。 Đây là một số lưu ý chỉ có ở PHP . Tuy nó không được đề cập trong Readable code, nhưng tôi sẽ đề cập đến nó vì nó là một vấn đề lớn. 先ほども述べた通り、 PHP はバージョンアップするたびに、型に厳格になってきたため、変数に予期しない型の値が入っていると、思わぬエラーが生じる場合があります。 そのため、条件式でも厳格に型を指定した比較を使い、事故を減らすべきです。 Như đã đề cập trước đó, PHP đã trở nên chặt chẽ hơn về type mỗi khi nó được nâng cấp version, vì vậy nếu một biến chứa kiểu giá trị không mong đợi thì sẽ có trường hợp phát sinh error không lường trước được. Do đó, bạn cũng nên giảm thiểu các sự cố bằng cách sử dụng các phép so sánh đã được chỉ định type một cách chặt chẽ ngay cả ở biểu thức điều kiện. 以下のように、できるだけ厳格な比較を行いましょう。 Thực hiện phép so sánh nghiêm ngặt nhất có thể như bên dưới. ❌ Bad Code <?php if ( $ value == 0 ) { ... } if ( $ value != 0 ) { ... } ✅ Good Code <?php if ( $ value === 0 ) { ... } if ( $ value !== 0 ) { ... } 2-3. Not Use Conditional Branch #if文 #CâuIf 条件分岐を使わない Không sử dụng phân nhánh điều kiện. さて、ここまで条件式についてのテクニックを述べてきましたが、そもそも 条件分岐は少ない方が読みやすいコードになります 。 条件分岐はロジックを記述する上で必要不可欠ではありますが、あちこちに if 文が存在するコードはとても読みづらくなってしまいます。 Đến đây tuy tôi đã mô tả Technique về các biểu thức điều kiện, nhưng vốn dĩ phân nhánh điều kiện mà có ít nhánh thì càng dễ đọc . Mặc dù phân nhánh điều kiện cần thiết khi mô tả logic, nhưng code mà có tồn tại câu lệnh if ở chỗ này chỗ kia thì sẽ trở nên rất khó đọc. Do đó, mặc dù nó không có đề cập ở Readable code nhưng tôi sẽ đề cập đến việc giảm câu lệnh if. 条件分岐を減らすテクニックはいくつかありますが、ここでは1つだけ紹介します。 以下の例では、ユーザが画面から選択したチャットツールに、メッセージを投稿します。 ユーザは、"LINE"、"Slack"、"Zalo" のうち、いずれかのチャットへメッセージを投稿することができます。 Có một số Technique để giảm phân nhánh điều kiện, nhưng tôi chỉ giới thiệu ở đây một Technique. Ở ví dụ dưới đây,sẽ post message vào Chat tool mà user lựa chọn từ màn hình. User có thể post message lên bất kỳ Chat nào trong "LINE", "Slack" hoặc "Zalo". ❌ Bad Code <?php $ chatType = $ request -> get ( "chatType" ) ; $ postMessage = $ request -> get ( "postMessage" ) ; switch ( $ chatType ) { case CHAT_TYPE_LINE : $ lineAccount = getLineAccount () ; $ linePostResult = postMesseageToLine ( $ postMessage ) ; break ; case CHAT_TYPE_SLACK : $ slackAccount = getSlackAccount () ; $ slackPostResult = postMesseageToSlack ( $ postMessage ) ; break ; case CHAT_TYPE_ZALO : $ zaloAccount = getZALOAccount () ; $ zaroPostResult = postMesseageToZalo ( $ postMessage ) ; break ; } : : : // Phần hiển thị màn hình // 画面表示部分 switch ( $ chatType ) { case CHAT_TYPE_LINE : if ( $ linePostResult === "success" ) { displayMessage ( "Posted a message to LINE." ) ; } else { displayMessage ( "Error occurred when post a message to LINE." ) ; } break ; case CHAT_TYPE_SLACK : if ( $ linePostResult === "success" ) { displayMessage ( "Posted a message to Slack." ) ; } else { displayMessage ( "Error occurred when post a message to Slack." ) ; } break ; case CHAT_TYPE_ZALO : if ( $ linePostResult === "success" ) { displayMessage ( "Posted a message to Zalo." ) ; } else { displayMessage ( "Error occurred when post a message to Zalo." ) ; } break ; } 上記のように、各チャットの処理をswitch文（もしくはif分）で記載すると、処理が煩雑になってしまいます。 そのため、以下のように、 各チャットの処理を記載したクラスの インスタンス を用意することで、条件分岐を減らすことができます。 また、条件分岐内の処理も少なくすることができます。 Như đã đề cập ở trên, nếu mô tả xử lý các Chat bằng câu lệnh switch (hoặc if), thì xử lý sẽ trở nên phức tạp. Do đó, phân nhánh có điều kiện có thể được giảm bớt bằng cách chuẩn bị instance class có mô tả xử lý của mỗi Chat như bên dưới. Ngo ài ra, cũng có thể giảm bớt xử lý trong phân nhánh điều kiện. ✅ Good Code <?php $ chatType = $ request -> get ( "chatType" ) ; $ postMessage = $ request -> get ( "postMessage" ) ; switch ( $ chatType ) { case CHAT_TYPE_LINE : $ chat = new Line () ; break ; case CHAT_TYPE_SLACK : $ chat = new Slack () ; break ; case CHAT_TYPE_ZALO : $ chat = new Zalo () ; break ; } // Ở các class chat // có một method `post ()` để post message vào từng Chat // 各チャットのクラスには、 // それぞれのチャットへメッセージを投稿する `post()` メソッドがある $ postResult = $ chat -> post ( $ postMessage ) ; : : : // Phần hiển thị trên màn hình // 画面表示部分 if ( $ postResult === "success" ){ displayMessage ( "Posted a message to " . $ chat -> name ()) ; } else { displayMessage ( "Error occurred when post a message to " . $ chat -> name ()) ; } 3. ロジックの簡略化を行うテクニック / Các kỹ thuật thực hiện đơn giản hóa logic 難しいロジックを読み解く場合、脳にはそれだけ負荷がかかってしまいます。 できるだけロジックは簡単にし、誰でも読み解けるようにすることが重要です。 Khi đọc hiểu những logic khó, nó sẽ khi ến não bạn căng thẳng. Việc đơn giản hóa logic trong khả năng có thể, để ai đọc vào cũng có thể hiểu được là điều quan trọng. 3-1. Early Return #EarlyReturn #ガード節 #早期リターン #GuardClause #ReturnSớm 早くに return する Early Return 関数にて早くに処理を終了できる場合は、終了できる状態になったときに値を return しましょう。 もう他に処理を行う必要がないのに、開発者は return を見つけるまでその処理を読まなければいけなくなってしまいます。 Trường hợp có thể kết thúc xử lý sớm ở hàm, thì hãy return giá trị khi nó đã ở trạng thái có thể kết thúc. Mặc dù không cần thực hiện thêm các xử lý khác nhưng Developer phải đọc các xử lý đó đến khi tìm thấy return . ❌ Bad Code <?php function isValidInputedUser ( $ inputedUser ) : bool { $ result = true ; if ( $ inputedUser -> id <= 0 ) { $ result = false ; } else { ............... ............... ............... : : ............... ............... ............... } return $ result ; } 以下のように記載すれば、最後まで読まなくても、 id が0以下の場合は他になにもせず処理が終わることがすぐにわかります。 Nếu mô tả như sau, thì dù không đọc đến cuối, bạn có thể thấy ng ay rằng nếu id nhỏ hơn hoặc bằng 0, thì xử lý kết thúc mà không cần làm gì khác. ✅ Good Code <?php function isValidInputedUser ( $ inputedUser ) : bool { if ( $ inputedUser -> id <= 0 ) { return false ; } ............... ............... ............... : : ............... ............... ............... return $ result ; } また、このテクニックは、関数の内部だけでなく、ループ内でも有効です。 ループ内で処理を終了できる場合は、 break を利用しましょう。 Technique này không chỉ hữu ích ở bên trong hàm, mà còn ở bên trong loop. Trường hợp có thể kết thúc xử lý ở bên trong loop, thì hãy sử dụng break . ❌ Bad Code <?php // Lấy 1 recipe bạn chưa từng tạo // 作ったことがないレシピを1件取得する $ done = false ; foreach ( $ recipeList as $ recipe ) { if ( !$ done ) { if ( !$ recipe -> isMade ) { $ done = true ; $ suggestRecipe = $ recipe ; } } } return render ( "sugestOneRecipe.html" , $ suggestRecipe ) ; ✅ Good Code <?php // Lấy 1 recipe bạn chưa từng tạo // 作ったことがないレシピを1件取得する foreach ( $ recipeList as $ recipe ) { if ( !$ recipe -> isMade ) { $ suggestRecipe = $ recipe ; break ; // Early Return!! } } return render ( "sugestOneRecipe.html" , $ suggestRecipe ) ; 3-2. Minimize Nesting #ネスト #EarlyReturn #ガード節 #Nest #GuardClause ネストを浅くする Làm cho nest cạn đi 以下のようなコードは、とても読みにくく感じないでしょうか。 Bạn có cảm thấy code như bên dưới rất khó đọc không? ❌ Bad Code <?php if ( $ val < 1 ) { if ( $ val < 0.5 ) { if ( $ val < 0.05 ) { if ( $ val < 0.005 ) { if ( $ val < 0.0005 ) { : : 深いネストがあると、考えることが多くなるため読みにくいコードになります。できるだけネストは浅くしましょう。 個人差はあると思いますが、私は Level 3 のネストがあると解消できないかを考え、Level 4 になるとなんとしても避けようとします。 Việc có nest sâu sẽ làm cho code khó đọc vì nó khi ến bạn phải suy nghĩ rất nhiều. Hãy làm cho nest cạn nhất có thể. Tôi nghĩ rằng có những sự khác nhau với mỗi người, nhưng nếu có nest ở level 3, thì tôi suy nghĩ xem có thể loại bỏ nó được không và nếu là level 4 thì tôi sẽ cố gắng tránh nó bằng mọi cách. ネストを浅くするためには、先ほど紹介した Early Return が有効です。 以下のようにif文の条件を整理することで解消できます。 Để làm cho nest cạn thì phải ON Early Return đã tôi đã giới thiệu trên đây. Có thể xóa bằng việc điều chỉnh điều kiện của câu lệnh if như dưới đây. ❌ Bad Code <?php $ user = loadUser ( $ userId ) ; if ( $ user -> loadResult === "success" ) { if ( !$ user -> hasPermission ) { $ errorMessage = "ERROR: Permission." ; } else { $ errorMessage = "" ; } } else { $ errorMessage = "ERROR: Failed load." ; } $ display [ "user" ] = $ user ; $ display [ "errorMessage" ] = $ errorMessage ; return render ( "userInfo.html" , $ display ) ; 以下の例では、Early Return を利用することで、上記コードのネストを1 Level 減らすことができました。 Trong ví dụ dưới đây, chúng tôi có thể giảm bớt nest của code viết trên xuống 1 level bằng cách sử dụng Early Return. ✅ Good Code <?php $ user = loadUser ( $ userId ) ; $ display [ "user" ] = $ user ; if ( $ user -> loadResult !== "success" ) { $ display [ "errorMessage" ] = "ERROR: Failed load." ; return render ( "userInfo.html" , $ display ) ; } if ( !$ user -> hasPermission ) { $ display [ "errorMessage" ] = "ERROR: Permission." ; return render ( "userInfo.html" , $ display ) ; } $ display [ "errorMessage" ] = "" ; return render ( "userInfo.html" , $ display ) ; 4. 目的に合わせたコードにするテクニック / Techniques làm cho code đúng bản chất 基本的に、プログラムで行う処理は小さな問題に分割されている方が便利です。 例えば、大きな関数があり、その関数内で全ての処理を行っているとしたら、 なにか仕様変更があったときにはその関数内で行われている全ての処理をテストする必要があります。 また、大きな関数では、コードを読むときもこの関数では最終的に何がやりたいのか分かりづらくなっているでしょう。 そのため、保守性が高く読みやすいコードを書くためには、 その処理でやりたい本当の目的 を明確にして、 目的でない問題は他の処理に切り出す ことが必要です。 Về cơ bản, rất tiện lợi khi chia xử lý thực hiện trong program thành các vấn đề nhỏ. Ví dụ: nếu có một hàm lớn và đã thực hiện tất cả xử lý trong hàm đó, khi có sự thay đổi specification gì đó, thì cần phải test tất cả các xử lý được thực hiện trong hàm đó. Ngo ài ra, đối với hàm lớn, cả khi đọc code, bạn cũng bị khó biết được là cuối cùng bạn muốn làm gì trong hàm này đúng không. Do đó, để viết code có tính bảo trì cao và dễ đọc, hãy làm rõ vấn đề bản chất mà bạn muốn làm trong xử lý này , cần cắt các vấn đề không phải là bản chất sang xử lý khác . 4-1. Be General-Purpose Code 汎用コードにする Chọn code đa dụng #疎結合 #密結合 #独立したコード #責務 #外出し #LiênKếtLỏngLẻo #LiênKếtChặtChẽ #CodeĐộcLập #TráchNhiệm #OutputRaNgoài 処理を他の関数に切り出すとき、 できればその関数はアプリケーションに無関係な独立したコードになっている方がいいでしょう。 もし、そのコードがアプリケーションの仕様に依存していた場合は、 コードの内容を理解するためにアプリケーションの仕様を理解しておく必要がありますし、 アプリケーションの仕様が変更されたとき、そのコードも合わせて修正する必要があります。 また、独立したコードは、そのコードのみで実行することができるため、 テストも簡単に行うことができます。 切り出したコード自体はできるだけ他の処理と依存せず、 疎結合 な状態を保つことで、 保守性の高いコードになります。 Khi cắt xử lý sang hàm khác, nếu có thể thì hàm đó nên là code độc lập không liên quan đến application đúng không. Nếu code đó đã tồn tại trong specification của application, thì cần phải hiểu spec của application để hiểu nội dung code, và khi spec của application bị thay đổi, thì code đó cũng cần chỉnh sửa cho phù hợp. Ngo ài ra, code độc lập có thể thực thi chỉ với code đó, nên việc test cũng có thể thực hiện dễ dàng. Chính bản thân code đã cắt ra không phụ thuộc với xử lý khác hết mức có thể, và giữ trạng thái loosely coupling, nên sẽ trở thành code có tính bảo trì cao . 以下はアプリケーションへの依存性が高いコードです。 Dưới đây là code có tính phụ thuộc vào application cao . ❌ Bad Code <?php // Hiển thị recipe yêu thích của user // ユーザのお気に入りレシピを表示する $ favoriteRecipeName = getUserfavoriteRecipe () ; print "<p> { $ favoriteRecipeName } </p>" ; /** * Lấy recipe yêu thích của user * ユーザのお気に入りレシピを取得する * @return string Recipe name yêu thích / お気に入りレシピ名 */ function getUserfavoriteRecipe () : string { $ userId = $ _COOKIE [ "userId" ] ; // ★★★★★ $ user = new User ( $ userId ) ; return $ user -> favoritRecipe -> name ; } getUserfavoriteRecipe() の中に注目してください。 関数の中で cookie からユーザIDを取得しています。 しかし、これはアプリケーションのどこかで cookie にユーザIDを保存しているため実行できるのであって、 もし、 cookie にユーザIDが保存されていない場合はエラーになってしまいます。 つまり、「ユーザIDが cookie に保存されている」というアプリケーションの仕様に依存してしまっている状態です。 Hãy tập trung vào trong getUserfavoriteRecipe() . Đã lấy user ID từ cookie trong hàm. Tuy nhiên, điều này có thể thực thi vì đã lưu user ID vào cookie ở đâu đó trong application, nên nếu user ID không được lưu vào cookie thì sẽ bị lỗi Nói cách khác, là trạng thái phụ thuộc vào spec của application gọi là  "user ID được lưu trong cookie ". 処理を外出しする場合は、以下のように仕様から独立したつくりにするべきでしょう。 Khi going out xử lý, thì nên tạo độc lập từ spec như dưới đây nhỉ. ✅ Good Code <?php // Hiển thị recipe yêu thích của user // ユーザのお気に入りレシピを表示する $ userId = $ _COOKIE [ "userId" ] ; // ★★★★★ $ favoriteRecipeName = getUserfavoriteRecipe ( $ userId ) ; print "<p> { $ favoriteRecipeName } </p>" ; /** * Lấy recipe yêu thích của user * ユーザのお気に入りレシピを取得する * @param int $userId * @return string Recipe name yêu thích / お気に入りレシピ名 */ function getUserfavoriteRecipe ( int $ userId ) : string { $ user = new User ( $ userId ) ; return $ user -> favoritRecipe -> name ; } ユーザIDを関数の外で取得して引数で渡すことにより、 getUserfavoriteRecipe() は仕様から解放されました。 これで関数単体のテストも容易に作成することができます。 Do lấy user ID ở ngo ài hàm và truyền với đối số, nên getUserfavoriteRecipe() đã được giải phóng khỏi specification. Điều này làm cho có thể tạo unit test cho hàm dễ dàng. ただし、もちろんやりすぎはよくありません。 あまりに処理を分けすぎると、処理があちらこちらに飛んでしまい、処理の流れを追いづらくなります。 適切な粒度を判断して、処理を分けるようにしましょう。 Nhưng tất nhiên, làm quá mức là không tốt. Nếu chia xử lý quá nhiều, thì xử lý sẽ bay sang chỗ này chỗ kia, dẫn đến khó theo dõi luồng xử lý. Hãy phán đoán độ chi tiết phù hợp để phân chia xử lý. 4-2. Simple is more important than Easy Easy より Simple が大事 Simple quan trọng hơn Easy #SimpleMadeEasy #Simple #責務 #TráchNhiệm さて、この記事は日本語と ベトナム語 で書かれていますが、ここで少し英語の話をさせてください。 （翻訳チームのみなさん、ややこしくてすみません。。。） Bài viết này được viết bằng tiếng Nhật và tiếng Việt, nhưng chỗ này thì hãy để tôi nói bằng tiếng Anh một chút. (Xin lỗi vì team dịch vì hơi rắc rối một chút...) "Easy" と "Simple" の違いを考えたことはあるでしょうか？ 日本語では両方とも「簡単」と訳せます。（ ベトナム語 はどうでしょう？） しかし、英語でのこれらには微妙なニュアンスの違いがあります。 Bạn đã từng suy nghĩ về sự khác nhau giữa "Easy" và "Simple" đúng không? Trong tiếng Nhật thì cả 2 đều dịch là「Đơn giản」.（Tiếng Việt thì sao？） Tuy nhiên, có sự khác biệt nhỏ về sắc thái giữa các từ này trong tiếng Anh. このニュアンスの違いについて、 Clojure の作者である Rich Hickey が数年前に "Simple Made Easy" という発表をしています。 *2 *3 Về sự khác biệt sắc thái này, Rich Hickey là tác giả của Clojure đã có phát biểu gọi là "Simple Made Easy" trong vài năm trước. *4 *5 この発表によると、"Simple" の語源は ラテン語 の "simplex" であり、「1回折る」「1回編む」などの意味をもち、いずれも「単一の」という意味を含みます。 また、対義語は 「絡まった」「もつれている」といった意味を持つ "Complex" です。 Theo phát biểu này, nguồn gốc của từ "Simple" là "simplex" từ tiếng Latinh, có nghĩa là "gấp 1 lần", "đan 1 lần", v.v., tất cả đều bao hàm ý nghĩa là " của đơn nhất". Ngo ài ra, từ trái nghĩa là "Complex", có nghĩa là "vướng" hoặc "rối". 一方、"Easy" の語源は ラテン語 の "adjacens" と言われており、「近くにある」「身近な」「親しみのある」という意味をもち、 対義語は "Difficult" か "Hard" です。 Mặt khác, nguồn gốc của từ "Easy" được gọi là "adjacens" từ tiếng Latinh, có nghĩa là「Ở gần」「Gần gũi」「Thân thiện」, Từ trái nghĩa là "Difficult" hoặc "Hard". ここで大事なことは、"Easy" の「身近な / 親しみのある」という意味は、あくまで主観的、相対的な意味であり、 "Simple" の「単一の」という意味は客観的であるという点です。 Điều quan trọng ở đây là ý nghĩa "Gần gũi / Thân thiện" của từ "Easy" chỉ mang tính chủ quan và tương đối. Ý nghĩa của " của đơn nhất" trong "Simple" là điểm mang tính khách quan. たとえば、メールを送信する関数があるとします。 この関数はとても高機能で、引数に From アドレスや、To アドレスを指定できるだけでなく、 添付ファイルがある場合は添付ファイルのパスを引数に指定することで利用できるほか、 To アドレスを配列にすれば複数の To アドレスを指定でき、 さらに、テキストと HTML の本文文字列をそれぞれ引数に渡せばマルチパートメールにも送信できます。 Ví dụ: giả sử có một hàm gửi mail. Hàm này có tính năng rất cao , không chỉ có thể chỉ định From address và To address cho đối số mà còn nếu có file đính kèm, bạn còn có thể sử dụng khi chỉ định path của file đính kèm cho đối số, ngo ài ra nếu đặt To address là mảng, thì còn có thể chỉ định nhiều To address, thêm nữa, nếu truyền chuỗi body của text và HTML lần lượt cho đối số thì còn có thể gửi tới multipart mail. つまりこの関数は、あらゆるメールを "Easyに" 作成できる関数です。 Nói cách khác, hàm này là hàm có thể tạo tất cả các mail một cách "Easy" しかし、引数によってさまざまな条件があるため、この関数の中には非常に多くの if 文が含まれます。 （添付ファイルがあった場合の if 文、マルチパートメールを送る場合の if 文 etc...） Tuy nhiên, bao gồm rất nhiều câu if trong hàm này vì có các điều kiện khác nhau tùy thuộc vào đối số. (Câu if khi có file đính kèm, câu if khi gửi multipart mail, v.v.) そのため、この関数は "Complexである" とも言え、 下図の②にあたります。 Vì vậy, hàm này có thể gọi là "Complex", tương ứng với ② trong hình dưới đây. さて、この関数が存在するシステムで「 SMTP サーバを指定する」機能を実装することになったとします。 この場合、上記の "Easyな" 関数を修正することは非常に難しくなります。 なぜなら、条件分岐がたくさんあるため考慮事項が増えてしまい、テストも非常に難しくなってしまいます。 また、この関数を作成した本人は内容を理解できるかもしれませんが、 他の人が見ると条件分岐がとても多く読みづらいコードに見えてしまうことでしょう。 Bây giờ, giả sử quyết định implement chức năng "chỉ định SMTP server" trên system tồn tại hàm này. Trong trường hợp này, sẽ rất khó chỉnh sửa hàm có tính "Easy" viết trên. Lý do là vì có nhiều phân nhánh điều kiện nên mục cân nhắc tăng lên và việc test cũng trở nên rất khó khăn. Ngo ài ra, chính người tạo ra hàm này có lẽ có thể hiểu nội dung, nhưng mà nếu người khác xem , thì sẽ thấy rất nhiều nhánh điều kiện và có vẻ như là code khó đọc. この関数は、とある1場面ではとても便利で Easy かもしれませが、 Complex になっているため、拡張性がなく他の場面では Easy でなくなってしまいます。 Hàm này có thể rất tiện lợi và Easy trong 1 tình huống nào đó, nhưng mà vì nó là Complex, nên với tình huống khác không có tính mở rộng thì sẽ trở nên không Easy. この場合、Easy よりも、Simple であることを重視すべきです。 Trường hợp này, thì nên chú trọng là Simple hơn là Easy. Simple、つまり単純でわかりやすいことを心がけた場合、そのコードは拡張性に優れ、さらに他者にも読みやすくなります。 もちろん、Easy であることはいいことですが、Easy であることを求めたため、Complex になってしまっては意味がありません。 拡張性がなく、バグを生み出しやすいコードより、利用するために手間がかかるが単純でわかりやすいコードの方がずっと嬉しいです。 実装を行うときは、Easy より Simple を重視すべきです。 Simple, tức là nếu giữ suy nghĩ cố gắng để cho nó đơn giản và dễ hiểu, thì code đó sẽ có tính mở rộng, và cả người khác cũng dễ đọc hơn nữa. Tất nhiên, Easy là tốt, nhưng mà vì đã yêu cầu là Easy, nên nếu trở thành Complex thì không có ý nghĩa gì. So với code không có tính mở rộng, dễ sinh ra bug, thì dù mất thời gian công sức để sử dụng tôi vẫn thích code đơn giản dễ hiểu hơn. Khi thực hiện implement, nên chú trọng Simple hơn là Easy. 4-3. Avoid Too Fat Code 肥大化したコードを避ける Tránh code cồng kềnh #やりすぎ #仕様を減らす #LàmQuáNhiều #GiảmSpecifications コードは少なく短い方が保守性や可読性が高くなります。 これの解決方法は、不要な仕様を減らすことだけではありません。 そもそものコードを小さく関数やクラスに分割し、 他のコードから分離することで、事実上コードを短くすることができます。 他の処理から分離されていることが明確なコードは、 仕様の追加時やバグの修正時にも編集箇所が局所的になるため、修正や品質の担保が容易になります。 他の項目でも触れましたが、汎用的なコードを意識することや、処理を分離することなどを考えつつ、 コードの "重量" を意識し、できるだけ軽量なコードを書くよう心がけましょう！ Code càng ngắn thì tính bảo trì và tính dễ đọc càng cao . Giải pháp cho điều này không chỉ là giảm các spec không cần thiết. Ngay từ đầu, nếu chia code nhỏ ra thành các hàm và class, và tách khỏi code khác, thì trên thực tế có thể rút ngắn code lại. Code mà rõ ràng được việc phân tách khỏi xử lý khác thì, vì cả khi thêm spec hoặc khi chỉnh sửa bug, những chỗ edit sẽ mang tính cục bộ , nên việc chỉnh sửa và đảm bảo chất lượng sẽ đơn giản hơn. Như tôi đã đề cập trong các mục khác, hãy cùng để tâm đến việc nhận thức đến code đa dụng, vừa suy nghĩ về việc phân tách xử lý, để tâm đến "trọng lượng" của code và cố gắng viết code nó càng nhẹ càng tốt! おわりに / Lời kết 先の記事でも触れましたが、日本と ベトナム では文化だけでなく、エンジニア向けのコンテンツ量も違います。 お互いに言語も違いますし、英語を使ったとしてもお互いの母国語ではないためどこまで意図が伝わるかは不確定です。 この記事を利用することで、 ベトナム との齟齬のない開発が行えることを願います。 Như tôi đã đề cập trong bài viết trước, không chỉ văn hóa mà lượng nội dung dành cho kỹ sư cũng khác nhau giữa Japan và Việt Nam. Ngôn ngữ khác nhau, và ngay cả khi bạn sử dụng tiếng Anh, cũng không chắc chắn ý đồ sẽ được truyền đạt vì nó không phải là ngôn ngữ mẹ đẻ của cả 2. Chúng tôi hy vọng rằng khi sử dụng bài viết này, sẽ có thể phát triển mà không có sự hiểu lầm với Việt Nam. 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 ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : 原版の翻訳や要約ではありませんのでご注意ください。 *2 : https://www.infoq.com/presentations/Simple-Made-Easy/ *3 : https://speakerdeck.com/takeru0757/simple-is-not-easy *4 : https://www.infoq.com/presentations/Simple-Made-Easy/ *5 : https://speakerdeck.com/takeru0757/simple-is-not-easy

技術広報の yayawowo です。 『仕様書』 と聞き、何の仕様書を思い浮かべますでしょうか？ また、仕様書と設計書の違いを説明できるでしょうか？ 今回は、仕様書とは何なのかをはじめ、種類や作成のポイントなどを分かりやすく解説したいと思います！ システム開発 に携わる方は、是非ご参考になさってください。 仕様書とは 仕様書があると良いこと 設計書と何が違うの？ 仕様書の種類 要求仕様書 機能仕様書 技術仕様書 テスト仕様書 良い仕様書とは 要求事項漏れがない 図表を使い、丁寧に説明している 機能の振る舞いを明確にしている おすすめ書籍 ラクスの特徴 終わりに ◆ 関連ブログも合わせてご確認ください！ ・ 「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック ・ プロジェクトマネジメント とは 【まとめ】 ・ PMBOK とは【まとめ】 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ 仕様書とは 仕様書とは、 システム開発 の仕様（機能/性能/特性/満たすべき要件など）をまとめた書類のことを言います。 簡単に言えば、「こんなシステム作りますよ」を説明した書類です！ 仕様書があると良いこと 仕様書があることにより、以下を回避することが出来るといえます。 回避（例） ステークホルダー との認識違い 仕様漏れ 仕様変更による、 工数 増加 仕様変更による、スケジュール遅延 などなど 上記は一例に過ぎませんが、仕様書があることによるメリットは多くあります。 設計書と何が違うの？ システム開発 を行う中で、 設計書 もよく聞く言葉だと思います。 大きな違いは以下2点です。 ①. 仕様書の内容に対しての実現方法（開発過程）が記載されている ②. 設計書は開発側が作成するものであるため、技術的内容となる 文字だけではわかりにくいかと思いますので、 ユーザーからオムライスを作ってほしいと依頼された場合を例に説明したいと思います！ 図１．例）オムライス 仕様書（結果） オムライス 設計書（過程） オムライスを作る方法 ご飯を炊く 玉ねぎをみじん切りにする フライパンに火をつけ、サラダ油を入れる みじん切りした玉ねぎを炒める　etc… いかがでしょうか？ 少しは仕様書と設計書の違いをご理解いただければ幸いです！ 仕様書の種類 仕様書にはいくつか種類があります。 こちらでは、代表的な4つに絞って説明したいと思います！ 要求仕様書 要求仕様書とは、開発するサービスや製品が持つべき機能/特性/特徴などをまとめた書類です。 ユーザーが開発部隊に対して開発を依頼するものであり、具体的な技術要件を記載しているものではございません。 要求仕様書には、最低限必要な要素である 5W1H をまとめる必要があります。 WHEN（いつ） WHERE（どこで） WHO（だれが） WHAT（何を） WHY（なぜ） HOW（どのように） 機能仕様書 機能仕様書とは、前述した要求仕様書のニーズをどのようにしてシステムの機能で実現するかをまとめた書類です。 開発部隊の責任者であるPM（プロジェクトマネージャー）やSE（ システムエンジニア ）が、ユーザーの要望を ヒアリ ングし、作成します。 作成目的は、エンドユーザーである依頼者と、開発者である開発部隊で認識齟齬の発生を回避するためです。 機能仕様書を見ることで、 システム開発 にすぐ着手できるよう、丁寧に作成することが必要になります！ 技術仕様書 技術仕様書とは、前述した機能仕様書にまとめた機能を システム開発 でどのように実現するかをまとめた書類です。 開発部隊のSE（ システムエンジニア ）、 プログラマー が相談しながら作成します。 認識齟齬がありながらの システム開発 はとても危険です。 技術仕様書を作成し、技術的な定義や手法をはっきりさせて開発を進めることが重要になります。 テスト仕様書 テスト仕様書とは、作成した要件定義書通りにシステムが開発/機能できているか、をテストするためにまとめた書類です。 どの機能を、どのテスト技法で動作確認するかを記載しております。 主に、 結合テスト や総合テスト工程をまとめております。 テスト計画書、テスト設計書が類似書類としてありますので、こちらも少し解説します。 テスト計画書 システム開発 におけるテスト方針（目的/範囲/人員/スケジュールなど）をまとめた書類 テスト設計書 テスト仕様書と扱いは同じであり、テスト設計仕様書と呼ぶこともある ◆ 関連ブログ tech-blog.rakus.co.jp 良い仕様書とは 要求事項漏れがない 仕様書は、開発者にとって システム開発 の軸となるものです。 その仕様書に要求事項の漏れがあった場合、どうなると思いますか？ お察しの通り、開発スケジュールの遅延だけでなく、システム品質の低下やコスト増加を招くことになりかねません。 システム開発 で何をしてほしいか、を仕様書にしっかり落とし込むことが大変重要となります。 図表を使い、丁寧に説明している 仕様書を読むのは仕様書を書いた本人でなく、第 三者 になります。 誰が見ても分かりやすい資料にするには、図表を使った説明が効果的です。 しかし、ただ単に図表を使えば良いというものではありません。 想定する利用ユーザーが完成したシステムをどのように使うかを明確なストーリーや、イメージ図を使って開発者に伝える必要があります。 ワイヤーフレーム や画面遷移図、シーケンス図、開発前後の比較画像等を仕様書内に入れておくと良いかもしれません。 機能の振る舞いを明確にしている 要求事項の漏れがない仕様書も大事ですが、細部まで機能の振る舞いを明確に定義することも大変重要です。 開発納期に開発者から提供されたシステムを確認した際、 「あれ？この機能がないんだけど・・・」 このようなことが起きてしまうのは、大変危険です。 この場合、リリース延期や追加開発になることが想定されます。 仕様書には、機能の振る舞いを明確に定義することで、最終的な成果物の品質を向上させましょう。 おすすめ書籍 仕様書を初めて書く人におすすめの書籍をご紹介させていただきます！ 学習の一助となれば幸いです。 『SE一年目のための仕様書の書き方』 「仕様書とは何か？」を知りたい方におすすめです。 手戻りが発生しない、分かりやすい仕様書を書きたい方に分かりやすく解説された1冊になります！ 『速効メソッド ITエンジニアのためのビジネス文書作成術』 エンジニアだけでなく、ビジネスサイドの方にもオススメしたい書籍です。 具体的なケースやテンプレートもあり、直ぐに実践できる内容となっております。 『[入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』 「要求」とはなにか、「仕様」とはなにか、を具体的に解説してくれている一冊です。 要求仕様書作りの考え方や具体的プロセスを身につけるために、是非ご一読ください。 ラク スの特徴 上記は、当社の 開発プロセス になります。 仕様書を作成/よく活用するタイミングは、以下タイミングとなります。 要件定義 概要設計 詳細設計～実装～受入 ラク スでは中堅エンジニアはもちろんのこと、若手エンジニアでも要件定義や概要設計に関わる事が可能です。 若手エンジニアにとっては成長できる場をご準備しております！ 少しでも当社にご興味をお持ちの方がおりましたら、まずは当社が主催する技術/採用イベントにご参加ください。 ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com お待ちしております！ 終わりに 「仕様書」のまとめは、いかがでしたでしょうか？ 仕様書は システム開発 を行う中で、見返すことが多い書類になります。 作成をする際は、情報の過不足がないものを作れるように頑張ってください！ また今回初めて作る方は、書籍を読むことは大前提ですが、既存の仕様書を読み返すこともおすすめです。 先輩方の知恵を有効活用し、是非ご自身が作る仕様書を良いものにしていただけますと幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

初めに 初めまして、sakekobaです。 普段インフラのお仕事をさせて頂いておりますが、ここ数年の間に「SRE」という言葉を聞くようになったように感じます。 SREについて知りたいけど難しいな…。と思っていたので、SREについて、出来るだけ分かりやすくまとめる事にチャレンジしました。 「SRE」とは分かりやすく言うと何なのか？ SREの取り組みは、具体的に何をすればいいのか？ どういう人がSREに向いているのか？ という点について、まとめてみました。 目次 初めに 目次 「SRE」とは？ 「SRE」の「信頼性」を定義する SLI SLA SLO 省力化する 信頼性向上のための活動を行う エラーバジェット ポストモーテム ラクスのSRE課について ラクスの取り組み どういう人がSREエンジニアに向いているのか？ 「SRE」とは？ 「SRE」をざっくり言うと「新しいサービス運用の考え方、そしてその役割」です。 SREとは「サイト・リライアビリティ・エンジニアリング」の頭文字をとった言葉で、日本語では「サイト信頼性エンジニアリング」となります。 サイト（サービス）の信頼性をエンジニアリングする（意訳ですが、しっかり作りこむ）ことを目的として、 システムエンジニア リングの知見からのアプローチで、システム管理、運用をより良くします。 SREの中で謳われている「信頼性（が高い）」とは、ユーザが期待通りにサービスを使える（障害等で使えないことが無い（少ない））状態のことです。 勿論、SREが広まる前もシステムの運用者は高い信頼性維持を目指していますが、システム運用に求められるスキルは、「サーバ・NW・ ミドルウェア 等の幅広い知識を以て安定運用に寄与すること」であるため、運用者自身が手でコマンドを打つ等で運用作業を行うことが多い状態でした。 そのため、例えば下記のような問題がありました。 手作業が多いと、それだけヒューマンエラーで障害のリスクがある サービスの規模が大きくなると作業が増大し、人手や時間といったコストをかける必要があり、不具合改修、サービス向上にコストを振り分けられない サービスの「開発者」と「運用者」が完全に分かれていることで、「ユーザの為により良い改善をどんどんリリースしたい」開発と、「安定稼働の為には、システムのリリース作業は最小限にしたい」と考える運用の間に大きな壁がありリリースのスピードが遅くなる などなど… これらの問題を解消する役割が、SREです。 例えば下記があります。 SREチームが「信頼性」を定義し、皆で同じ方向を向く 手作業が多いシステム管理・運用の分野に、SREが自動化を取り入れる その他、エラー許容の定義や障害発生時の事後検証等、信頼性向上のための活動を行う SREという言葉を提唱したのは Google 社ですが、その Google 社が、下記の資料を公開しています。 sre.google また、このSREについての資料の日本語版が オライリー 社より出版されています。 www.oreilly.co.jp SREは会社・サービスの課題によって様々なアプローチで信頼性の向上に取り組みます。 このブログでは、先に上げたSREの役割の例 信頼性の定義 省力化する 信頼性向上のための活動 を少し掘り下げて記載したいと思います。 「SRE」の「信頼性」を定義する SREのエンジニアチームには、「信頼性」を定義して関わる人を同じ方向に向ける役割があります。 そもそも「信頼性が高いサービス」とは何でしょうか。 24時間常に動作していて、応答が即座に返ってきて…と、思いつくものはあるかと思いますが、具体的にするとどうでしょう。 例えば・・・ 「 ECサイト で決済だけされて購入（在庫の確保）が遅い時があった」ら買えない場合もあり、怖くて使えないかもしれませんが、「暇つぶしの無料動画サイトで読み込みが遅い時があった」としても、怖くて使えない！とまでは思わないかもしれません。 また、同じ ECサイト だとしても、「お気に入りリスト」のような付属機能の更新が一時的に使えなかったとしても、購入機能ほど困らないかもしれません。 このように、ものによって全く違う期待に応える必要があるため、SREでは具体的に数字に落とし込むことで、関わる人が同じ方向を向けるようにします。 SREではこの信頼性の定義を、SLI 、 SLA 、SLOを用いて行います。 SLI サービス・レベル・インジケーターと読みます。 サービスレベルを測るため、 定量 的な指標を定義します。 たとえば、「早くサイトが表示される」という目標だけでは、「1秒で表示されるのは遅い？早い？」のように人によってバラバラな捉え方をしてしまいます。 その為「理想的なリク エス トの 応答時間 は0.5秒」のように指標となる 定量 的な項目を定義し、後述のSLOを測るために使います。 SLA サービス・レベル・アグ リーメント と読みます。 この言葉自体はSREに特化したものではない為、SREに関わらず、この用語を耳にされたことがあるかもしれません。 サービスを使用するユーザと「合意した（対外的に約束した）」サービスの品質のことです。 この「合意」はお金を払って契約しているサービスで、契約書に明記されている場合もあり、「契約違反では？」と言えてしまうようなものです。 絶対に守るべきラインとなるため、次に挙げる「SLO」より緩く設定されていることが一般的です。 SLO サービス・レベル・オブジェクティブと読みます。 内部的に設定したサービスレベルの目標値です。 関わる人の認識を合わせるためでもあるので、高すぎても、低すぎても問題があります。 高すぎると、常に目標達成のため原因追及をする羽目になります。 低すぎると、普段は良くても「（内々にはSLOの範囲だけど）いつもより悪いとユーザからクレームが来た」等の時に対応に困る羽目になります。 SLOの考え方については、 Google のブログに具体的に書かれた記事があります。 cloud.google.com 省力化する 冒頭で上げた問題の例に、手作業に伴う問題がありました。 手作業が多いと、それだけヒューマンエラーで障害のリスクがある サービスの規模が大きくなると作業が増大し、人手や時間といったコストをかける必要があり、不具合改修、サービス向上にコストを振り分けられない このような人が手で運用作業をすることに伴い発生する課題について、SREは、自動化を推進することで解消を図ります。 省力化はSREが担う役割の中でも重要なものの一つで、 Google のSREチームでは「SREが運用作業に充てて良い時間は業務の50％まで」とし、残りは運用作業の自動化や、サービスの開発などに振り分けるよう徹底しているほどだそうです。 この自動化できるのにしていない繰り返しの手作業は「トイル」と呼ばれています。 SREはこのトイルを見つけ出し、ソフトウェアエンジニアリングの知見で解消をすることで、ヒューマンエラーの低減、サービス向上のような作業への人的リソースの振り分けを行えるようにアプローチします。 SREのトイルの考え方、見つけ方についてより知りたい場合は、下記の記事が参考になると思います。 cloud.google.com 「運用を自動化しよう」というのは「SRE」だけでなく「DevOps」という言葉で聞いたことがある方も多いかと思います。 SREとDevOpsは相反するような考え方ではありません。 SREとDevOpsは、それぞれが独立した考え方ではなく、SREはより具体化し、自動化以外の要素も持ったものと言えるかと思います。 先に紹介したSREを提唱した Google の資料でも、下記のように記載されています。 DevOpsは、さまざまな組織、管理構造、および人員に対するいくつかのコアSRE原則の一般化と見なすことができます。（※日本語訳、本文は英語） Google - Site Reliability Engineering 信頼性向上のための活動を行う 信頼性の定義や自動化だけでなく、SREはその会社・サービスが持つ運用課題を様々な方法で解決に向かわせます。 例えば、冒頭で挙げた サービスの「開発者」と「運用者」が完全に分かれていることで、「ユーザの為により良い改善をどんどんリリースしたい」開発と、「安定稼働の為には、システムのリリース作業は最小限にしたい」と考える運用の間に大きな壁がありリリースのスピードが遅くなる という問題点については、SREでは「エラーバジェット」という考え方を用いてアプローチします。 エラーバジェット SREのアプローチとして、開発と運用のバランスを取るための方法です。 エラー等を許容する値を決めておき、エラーが許容量までであれば新機能の開発やリリースを優先してもよく、 閾値 を下回る場合は新規のリリースをとめて安定した運用を優先しなくてはならない、というルールを決めた運用方法です。 前述したSLOで、サービスレベルの目標値を決めておき、そのレベルまでのサービス品質の低下を許容するという考え方です。 この値を決め、ルールを設定することで開発と運用で同じ指標を共有出来、バランスを取ることが出来るようになります。 他にも、運用には障害対応がつきものです。 SREではこの障害を「ポストモーテム」という振り返り用の記録として残し、事後検証・共有し今後に活かそうという取り組みを行うこともあります。 ポストモーテム 障害・インシデントが発生した際、その内容、原因、対応などを文章化し、そこから再発防止や、ベストプ ラク ティスを学びます。 SREが行うポストモーテムが、一般的な障害報告等と違うところは「決して非難しない」という点です。 非難を排除することで、問題が隠されてしまうことを防いだり、本質的な改善の議論にフォーカスすることが出来ます。 信頼性向上のため、多岐にわたる役割が内包されているSREですが、会社、サービスごとに取り巻く状況や解決するべき課題に差があります。 なのでSREチームが置かれていたとしても、どの会社も同じことをしているとは限りません。 一律に「この作業をする」と言い切れないところに、SREという言葉を理解する難しさがあると感じます。 ラク スのSRE課について 弊社 ラク スにも、SRE課があります。 一例として、簡単にではありますが、弊社の取り組みを紹介させていただきます。 ラク スの取り組み ラク スのSRE課では、現在各プロダクトの運用の自動化やモニタリング基盤の刷新などを進めています。 とは言え、まだ出来上がったばかりのチームで小さく始めたところです。 事例ですと、 Kubernetes を利用した環境構築や運用のデプロイパイプラインの構築、モニタリングツールの導入支援といった業務を推進しています。 将来的にはこれらのノウハウを各プロダクトへ展開していきたいと考えています。 どういう人がSREエンジニアに向いているのか？ 最後に、SREエンジニアになりたい場合、どのようなスキルや経験を積んでいるとより良いか、 ラク スのSRE課に求める人物像を聞いてみました。 目的を正しく把握して行動に移せる　というのが一番重要なことだと思います。 SREとしてのプ ラク ティスを実践するための技術的なスキルも重要ですが、 業務的にDevと Ops 双方と協業する立場ですので、目的がブレないようにしつつ、 関係者を巻き込んで改善していく行動力が特に重要だと考えています。 ※スキルは一緒に学んでいけばよい、と考えています ご興味ありましたら、以下内容をご確認ください！ career-recruit.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

初めに 皆さんこんにちは。mosyoryです。 今回は Python のPyAutoGUIを使用してマウスやキーボードを操作する方法をご紹介します。 関数で使用する引数の全ての解説は行っていないので予めご了承ください。 初めに PyAutoGUIとは PyAutoGUIのインストール マウス操作 画面のサイズの確認 マウスカーソルの移動 マウスのドラッグ クリック キーボード操作 文字の入力 特殊キーの入力 キーの同時入力 「@」「^」「:」が入力できない場合 緊急停止させたい場合 メモを作成してみる 終わりに 参考サイト 　 PyAutoGUIとは PyAutoGUIとは、マウスやキーボードを操作する GUI 自動化の Python のライブラリです。 Windows , macOS , Linux で使用することができ、Python2, 3のどちらでも動作します。 pyautogui.readthedocs.io 今回は Windows 環境でPython3を使用した例を紹介します。 PyAutoGUIのインストール PyAutoGUIは コマンドプロンプト で下記を実行するだけで簡単にインストール出来ます。 pip install pyautogui 正しくインストール出来たか確認したい場合は「pip list」を実行してください。 PyAutoGUIとそのバージョンが表示されていれば、インストールが出来ています。 > pip list Package Version ----------------- -------- PyAutoGUI 0.9.53 ※pipは Python のパッケージ管理ツールです。 　Python3.4以上なら標準で付属していますので別途インストールする必要はありません。 Python は既にインストールされている前提で進めますので、まだの方は Python 公式サイトからPython3.xのバージョンをインストールしてください。本記事ではPython3.9を使用します。 www.python.org Python のバージョンを確認したい方は、 コマンドプロンプト から「 python -V」を実行してください。 > python -V Python 3.9.1 マウス操作 まずは、 Python がPyAutoGUIを使えるようインポートしましょう。 import pyautogui 画面のサイズの確認 マウスの位置は、X/Y座標で表されます。 画面の左上を座標(0, 0)とし右に進むほどX座標、下に進むほどY座標が増加します。 画面が1920×1080の場合、右下の座標は(1919, 1079)になります。 マウス操作の際に座標を使用するため、最初に画面のサイズを確認しておくと良いでしょう。 print (pyautogui.size()) マウスカーソルの移動 カーソル移動は、moveTo()を使用します。引数に与えたX/Y座標にカーソルが移動します。 # 座標(500, 600)に移動 pyautogui.moveTo( 500 , 600 ) 座標のみを与えた場合は、 Python を実行して一瞬でカーソルが移動します。 人間が動かしている様にゆっくりと移動させたい場合は、durationで移動時間を指定しましょう。 # 3秒かけて座標(500, 600)に移動 pyautogui.moveTo( 500 , 600 , duration= 3 ) 今のマウスカーソルの位置から相対的に移動させたいときは、move()を使います。 # 2秒かけて現在のカーソルの位置から上に200移動 pyautogui.move( 0 , - 200 , duration= 2 ) マウスのドラッグ ドラッグには、dragTo(), またはdrag()を使用します。 カーソル移動で使用したmoveTo()と同様にdragTo()が指定した座標へ、drag()が現在地からの相対的なドラッグを行います。 ドラッグでは引数に座標や移動時間に加え、どのマウスボタンを押し続けるかを指定します。 ボタンはleft, middle, rightの3つです。 # 左ボタンを押しながら、2秒かけて座標(100, 300)にマウスをドラッグ pyautogui.dragTo( 100 , 300 , duration= 2 , button= "left" ) # 右ボタンを押しながら、3秒かけて右に50, 下に100の座標までマウスをドラッグ pyautogui.drag( 50 , 100 , duration= 3 , button= "right" ) 引数に秒数を指定しないとmoveTo()と同様に一瞬で移動し、ドラッグとして認識されないことがあります。 そのため、移動時間を引数に指定したうえで実行することをお勧めします。 クリック click()を使用することでクリックが出来ます。 引数にクリックをする座標、クリックするボタン、回数や間隔を指定出来ます。 何も指定しなかった場合は現在のカーソルの位置で左クリックを1回行います。 # 現在のカーソルの位置で左クリックを1回 pyautogui.click() # 座標(20, 100)で右クリックを1回 pyautogui.click( 20 , 100 , button= "right" ) # 現在のカーソルの位置で0.5秒の間隔で左クリックを3回 pyautogui.click(button= "left" , clicks= 3 , interval= 0.5 ) 座標を指定した場合、カーソルを移動させた後クリックを行います。 そのため下のコードは同じ結果となります。 # moveTo()でカーソルを移動させてクリック pyautogui.moveTo( 100 , 100 ) pyautogui.click() # click()でカーソルを移動させてクリック pyautogui.click( 100 , 100 ) キーボード操作 文字の入力 write()に文字列を与えることで入力を行います。 入力速度はとても速く50文字程度の文字列は約0.1秒で入力が終えます。 意図的に遅らせたいのであればintervalを指定することで次の文字を入力するまでの間隔を空けることができます。 write()は一文字のキーのみ入力できるため、EnterやShiftの様な特殊キーを押したい場合は次に紹介する関数を使用してください。 # 0.5秒の間隔でenterという文字列を入力 (Enterキーは押されない) pyautogui.write( "enter" , interval= 0.5 ) # 下記の文章も約0.1秒で入力が終えます pyautogui.write( "It was created using the Python module pyautogui." ) 特殊キーの入力 特殊キーを入力したい場合はpress()に、enterの様な予め決められている文字列を与える必要があります。 # Enterキーを入力 (enterという文字列は入力されない) pyautogui.press( "enter" ) 使用することができる特殊キーについては、こちらの一覧をご覧下さい。 pyautogui.readthedocs.io キーの同時入力 複数のキーを同時に入力する方法は2つあります。 1つ目は、keyDown()とkeyUp()を組み合わせる方法です。 keyDown()がキーを押してそのまま離さない動作、keyUp()が押していたキーを離す動作のイメージです。 ただkeyDown()をしても、そのキーが入力され続けるわけではないので注意してください。 # ctrlを押した状態で、aを押す。 pyautogui.keyDown( "ctrl" ) pyautogui.keyDown( "a" ) pyautogui.keyUp( "a" ) pyautogui.keyUp( "ctrl" ) 2つ目は、hotkey()を使用する方法です。 こちらは引数に指定したキーを順番に押し逆順で離していきます。 keyDown()とkeyUp()の場合だとキーの数が増えると行数が増えてしまいますが、hotkey()だと1行で書くことができます。 # shiftを押した状態でbとcを入力 pyautogui.hotkey( "shift" , "b" , "c" ) # 上の例をkeyDown(), keyUp()で書いた場合 pyautogui.keyDown( "shift" ) pyautogui.keyDown( "b" ) pyautogui.keyDown( "c" ) pyautogui.keyUp( "c" ) pyautogui.keyUp( "b" ) pyautogui.keyUp( "shift" ) 「@」「^」「:」が入力できない場合 キーボードのレイアウトによっては、特定の文字が意図したものとは違う入力がされる場合があります。 筆者は「@」「^」「:」を入力したら、Shiftも一緒に押した状態の「`」「~」「*」になってしまいました。 # 「@^:」を入力したつもりだが「`~*」が入力されている pyautogui.write( "@^:" ) 「@」「^」「:」を使用したい場合は、_pyautogui_win.pyというファイルを直接修正して回避する方法があります。 ※修正する場合は自己責任でお願い致します。 def _keyDown (key): (省略) needsShift = pyautogui.isShiftCharacter(key) # 以下3行を追加 if key == '@' : needsShift = False if key == '^' : needsShift = False if key == ':' : needsShift = False """ # OLD CODE: The new code relies on having all keys be loaded in keyboardMapping from the start. if key in keyboardMapping.keys(): (省略) if文でShiftは不要であるという処理を追加することで「@」「^」「:」が入力できるようになりました。 筆者は_pyautogui_win.pyが以下のパスにありましたが、 Python のインストール先によって異なるのでご自身の環境に合わせて探してみてください。 C:\Users\ユーザ名\AppData\Local\Programs\Python\Python39\Lib\site-packages\pyautogui\_pyautogui_win.py 緊急停止させたい場合 「何らかの理由で実行中のプログラムを停止させたいが、実行中の Python がマウスやキーボードを動かしているせいで停止ボタンを押せない」という様な時が来るかもしれません。そんな時はfail-safeモードを使用しましょう。 このモードはマウスカーソルを画面の一番左上(座標(0, 0)の場所)に移動させると起動しプログラムを停止させます。 PyAutoGUIがマウスやキーボードを操作してる最中でもマウス操作やキー入力は受け付けてくれるので、自分でマウスを画面左上まで動かしましょう。 メモを作成してみる 最後にメモ帳を開いて保存するまでの例をご紹介します。 4行目で設定しているpyautogui.PAUSEはPyAutoGUIが操作をした後の待機時間です。 これを設定しないとメモ帳の起動が完了する前に文字の入力が始まってしまうので、1秒間の待機時間を設定しています。 import pyautogui # 処理を実行するたびに1秒待機 pyautogui.PAUSE = 1.0 # 画面のサイズを取得 width, height = pyautogui.size() # スタートボタン付近にカーソルを移動しクリック pyautogui.moveTo( 5 , height- 5 , duration= 1 ) pyautogui.click() # メモ帳のアプリを検索し、エンターで起動 pyautogui.write( "memo" ) pyautogui.press( "enter" ) # 文字を入力 pyautogui.write( "It was created using the Python module pyautogui." ) # Ctrl+S で保存 pyautogui.hotkey( "ctrl" , "s" ) # ファイル名を入力し、エンターキーで保存 pyautogui.write( "Python.txt" , interval= 0.25 ) pyautogui.press( "enter" ) 終わりに Python のPyAutoGUIでマウスとキーボードを操作する方法を紹介しました。 単純な定型作業であれば、 Python に任せることでちょっとだけ楽な思いができるかもしれませんね。 今回はマウスでクリックする場所が事前に分かった状態で行っておりましたが、画像認識の機能を使うことでもう少し柔軟な操作が行えるようになります。 ご興味のある方は是非試してみてください。 参考サイト Welcome to PyAutoGUI’s documentation! — PyAutoGUI documentation Some characters are not working with German layout keyboard · Issue #46 · asweigart/pyautogui · GitHub 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。株式会社 ラク ス技術広報のlandhです。 ラク スには、現在（2022年6月時点）12種類の SaaS プロダクトが存在しています。 本記事では、当社の SaaS プロダクトを簡単にご紹介し、 SaaS プロダクトから ラク スがどのような企業なのかを読み解いていければと思います。 【目次】 ラクスのSaaSプロダクトラインナップ サービスの強み 12種類のSaaSプロダクトご紹介 楽楽精算 楽楽明細 楽楽電子保存 楽楽労務 楽楽勤怠 楽楽販売 楽テル メールディーラー チャットディーラーAI 配配メール ブラストメール ブラストエンジン ベスト・オブ・ブリード型での開発 SaaSプロダクトのマルチヒットメーカー 上場企業を5つ作れる規模のSaaSプロダクトを保有 募集ポジションについて SaaSプロダクト紹介 まとめ ラク スの SaaS プロダクトラインナップ ラク スでは、企業のさまざまな業務の効率化、付加価値化に貢献することを目指した クラウド サービス（ SaaS ）を提供しています。 SaaS プロダクトラインナップは、大きく分けると経費精算や販売管理などのバックオフィス業務と、またお客様からのお問い合わせ対応や マーケティング などのフロントオフィス業務を支援するサービスに分かれています。 その中で、バックオフィスを支援しているのは、 SaaS プロダクト名に「楽楽」と付いている、楽楽シリーズです。 直近では「楽楽 労務 」や「楽楽勤怠」をリリースしています。 フロントオフィスは、当社初の SaaS プロダクトである「メールディーラー」や「配配メール」をはじめとしたプロダクトがあります。 ラク スでは、これらの SaaS プロダクトを、約2年に1サービスのペースでリリースしており、現在、BtoBの SaaS プロダクトが12種類あります。 ※2022年5月時点 サービスの強み 画像引用元： ラクスについて | 株式会社ラクス 中途採用 ・自社で企画、開発、サポートしていて、使いやすさが常に進化 ・手厚い導入支援で、運用が軌道に乗るまでしっかりサポート ・解決できる課題が明確で、 工数 の軽減や対応品質向上などの導入効果が見えやすい ・利用者の満足度が高く、継続率が高い ・高度な IT技術 や知識がなくても導入できる　 ・初期導入コストの抑制や導入期間の短縮 ・セキュリティ対応やシステムメンテナンスの手間いらず　 　引用元　 https://www.rakus.co.jp/business/cloud/ 　 12種類の SaaS プロダクトご紹介 楽楽精算 交通費・経費精算システム ≪公式サイト≫ 　 www.rakurakuseisan.jp ≪内容≫ 　経費や交通費の申請～承認～精算を Webブラウザ 上で実現！ 経理 部門の業務も効率化 ≪実現できること≫ • どこからでも Webブラウザ で申請、承認できて、作業時間が短縮 • 交通系ICカード を「ピッ」とするだけで交通費申請可能 • 自動仕訳や会計ソフト連携で 経理 業務の時間を削減 • 「乗換案内」内蔵で、交通費を自動計算 • 国内累計導入社数No.1！ ※デロイト トーマツ ミック経済研究所「電帳法対応進む クラウド 型経費精算システム市場の実態と展望」（ミックITリポート2021年6月号: https://mic-r.co.jp/micit/ ）より 楽楽明細 電子請求書発行システム ≪公式サイト≫ 　 www.rakurakumeisai.jp ≪内容≫ 　請求書、納品書などの帳票を電子発行！印刷・封入作業をゼロにし、郵送コストも削減 ≪実現できること≫ • 請求書、支払明細書、納品書、領収書など、あらゆる帳票を電子化 • 請求データを取り込むだけで請求書を電子発行、お客様専用ページで公開 • 郵送費、印刷代、封筒代、紙代を0円にし、コスト削減 • 紙が必要な方には郵送代行も可能 楽楽電子保存 電子帳簿保存システム ≪公式サイト≫ 　 www.rakurakudenshihozon.jp ≪内容≫ 　改正電帳法に対応！「楽楽明細」で受け取った請求書を全て電子保存！ ≪実現できること≫ • 楽楽明細で受け取った請求書の保存&一元管理が可能 • メール添付で受け取った請求書などの帳票をアップロードし、管理できる機能リリースも現在検討中 楽楽 労務 従業員情報管理システム ≪公式サイト≫ 　 www.rakurakuroumu.jp ≪内容≫ 　入社時に必要な従業員情報の収集や管理・更新の手間を削減！ ≪実現できること≫ • 入社時に必要な従業員情報をWeb上で収集 • 電子契約で、 雇用契約 書などの入社書類をペーパーレス化 • 点在する従業員情報を一元管理 • マイナン バーなどの重要情報を安全に管理できる強固なセキュリティ体制 楽楽勤怠 　勤怠管理システム ≪公式サイト≫ 　 www.rakurakukintai.jp ≪内容≫ 　勤怠管理の"面倒くさい"から解放。有給・残業の管理も楽楽に！ ≪実現できること≫ • 有給休暇の付与、取得、残数の把握を一括管理 • 残業時間をタ イムリ ーに簡単確認 • スマホ 打刻で外出先から打刻可能 • CSV 出力で給与計算システムと楽楽連携 楽楽販売 販売管理業務システム ≪公式サイト≫ 　 www.rakurakuhanbai.jp ≪内容≫ 　販売管理のあらゆる業務をシステム化・自動化して効率的に！ ≪実現できること≫ • 業務フローや課題にあわせたシステムを開発不要で構築 • 既存フローを変えずにシステム化が可能 • 画面のレイアウトや処理などを担当者様自身で設定可能 • ボタン1つで複数の処理を自動実行 • フォームからの問い合わせや注文メールの取り込みを自動化 楽テル コールセンター/ヘルプデスク向け CRM システム ≪公式サイト≫ 　 www.rakutel.jp ≪内容≫ 　電話対応業務を効率化し、顧客対応品質・満足度を向上！ ≪実現できること≫ • コールセンターを管理する CTI システムとのシームレスな連携で、着信時の顧客情報ポップアップやクリックトゥコールを実現 • 対応履歴の管理や上長への引継ぎがスムーズ • 問い合わせ対応標準テンプレート搭載 • 項目や画面の細やかなカスタマイズ機能が充実 メールディーラー 問い合わせ管理システム ≪公式サイト≫ 　 www.maildealer.jp ≪内容≫ 　メールや電話、チャット、LINEからの問い合わせを一元管理。チーム内の情報共有が簡単になることで、お客様を待たせない対応を実現！ ≪実現できること≫ • 国内で一番選ばれているメール管理システム • 継続利用率99％（当社お客様アンケート調べ） • 今、誰が、どのメールを返信中か把握できる • 誤送信防止機能が充実 チャットディーラーAI 社内向けAIチャットボット ≪公式サイト≫ 　 www.chatdealer.jp ≪内容≫ 　社内問い合わせ対応を効率化するAIチャットボット。チャットボットの自動回答で、業務のムダを省き生産性の向上を実現！ ≪実現できること≫ • 忙しい担当者に代わって、チャットボットが社内問い合わせに自動回答 • 情報を活用できる形に社内のナレッジを一元管理 • 従業員側も回答にたどり着きやすくなり満足度向上 • 400種類以上の社内用テンプレートを完備 • 学習済みの賢いAIを搭載しており、最初から高い回答精度を実現 配配メール メール マーケティング サービス ≪公式サイト≫ 　 www.hai2mail.jp ≪内容≫ 　シンプルな操作と機能、手厚いサポートで、メールによる集客・販促活動を「もっと効果的に。もっと ラク に。」 ≪実現できること≫ • メール配信に特化したシンプルな操作画面でカンタンに配信 • 迷惑メール誤認を防ぐ複数の仕組みで受信ボックスへの高い到達率を維持 • 開封 /クリック計測、ABテスト配信など配信効果を改善する機能が充実 • 見込み顧客を 見える化 して、メール マーケティング の勝ちパターンを発見 ブラストメール 高速メール配信を低価格で実現 ≪公式サイト≫ 　 blastmail.jp ≪内容≫ 　"初めての人でも使いやすいこと" を追求した、シンプルで簡単なメール配信システム ≪実現できること≫ • 圧倒的な配信パフォーマンスで高速かつ確実にメールをお届け • メール配信に特化！専門知識がなくても簡単メール配信 • 直観的に操作ができるHTMLエディターを標準搭載 • 開封 率・クリックカウントなどの効果測定も可能 • 11年連続顧客導入数シェア No.1！※ ※デロイト トーマツ ミック経済研究所「 クラウド 型eメール一斉配信サービスの市場動向」2021年 ブラストエンジン システム連携特化型のメール配信システム ≪公式サイト≫ 　 blastengine.jp ≪内容≫ 　 API 連携と SMTP リレーで、システムからのメール配信を簡単かつ確実に ≪実現できること≫ • メールサーバー管理は不要！ クラウド 型のメール配信システム • 高速配信エンジン開発20年の実績で高いメール到達率を実現 • 豊富な API リファレンスを公開！無料トライアルで接続テストが可能 • 24時間365日の保守、安心のセキュリティ体制 • 専任スタッフが電話とメールで丁寧に問題解決までサポート ベスト・オブ・ブリード型での開発 ラク スは経営理念を「ITサービスで　企業の成長を　継続的に支援します。」としています。 この経営理念は SaaS プロダクトにも反映されており、ここまで13種類の SaaS をご紹介してきたプロダクトは、全てベスト・オブ・ブリード型で開発しています。 ベスト・オブ・ブリード型で提供していく理由としては、 「最適なタイミングで最適な技術を使ってプロダクトをお客様に届ける」ことを最も重視しているためです。 SaaS プロダクトの マルチヒット メーカー 画像引用元： ラクスについて | 株式会社ラクス 中途採用 ベスト・オブ・ブリード型で開発していった結果、成長性の高い SaaS プロダクトをいくつも展開できています。 例としては、上の図のように、売上シェア第1位のメールディーラー、楽楽明細、導入件数第1位の楽楽精算などが挙げられます。 上場企業を5つ作れる規模の SaaS プロダクトを 保有 それぞれ個別のマーケットにアプローチしているので、事業としてのバランスも良く、数字で見ても非常に事業が安定しています。 主な SaaS プロダクトを5つ集めるだけでも上場企業を5つ作れる規模のプロダクトを 保有 しています。 参照元 ： 3年で2.4倍の売上高 ラクスのSaaS最強決算（2/7 ページ） - ITmedia ビジネスオンライン 大規模な SaaS プロダクトへの成長要因としては、以下の2つが考えられます。 ・ SaaS 型のプロダクトを展開しているため、一度導入すると離脱が起こりにくく、導入件数は増加している為。 ・ベスト・オブ・ブリード型の開発により、複数のお客様の課題に並列で取り組むことができる。 上記に加えて、現在それぞれの SaaS プロダクトへの導入数が年率で120％～130％で推移しながら成長しており、これは SaaS 企業として成長し続ける ラク スの特徴とも言えると思います。 今後も、企業のさまざまな業務の効率化、付加価値化に貢献するためにベスト・オブ・ブリード型で提供していく予定です。 募集ポジションについて 急成長中の ラク スでは、「日本を代表する SaaS 開発エンジニア集団へ」を目指し日々精進しており、採用も積極的に行っております。 様々なフェーズの SaaS プロダクトが存在しており、現在は募集も多いため、やりたいことに合わせて多様なキャリア設計が可能です。 SaaS プロダクト紹介 まとめ 当社の SaaS プロダクトから、ざっと簡単に説明させていただきましたが、 ラク スの様々な SaaS プロダクトへの理解は深まりましたでしょうか。 少しでも SaaS 開発を関わっている方のお役に立てていれば、幸いです。 当社にご興味持っていただけた方は、技術イベント・採用イベントも行っておりますので、是非のぞいてみてください！ 最後までお読みいただきありがとうございました！ ◆ 関連ブログ - ラクスの福利厚生をご紹介！ - 【株式会社ラクス】SaaSプロダクト別の技術スタックを一挙公開！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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