技術広報の 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

はじめに 　はじめまして、 ラク スでインフラを担当しているftkenjです。 前回は 「DNSエラーってなに？」その原因と解決方法 を書かせていただきましたが、 今回は「自動化」、その中でもインフラエンジニアの視点に立って紹介させていただこうと思います。 はじめに 自動化とは？ インフラで自動化といえば・・・ 主な使用例 自動化ツールの簡単な紹介 おわりに 参考文献 自動化とは？ 　人間による作業を削減できるテク ノロ ジー を使ってタスクを実行すること。 ただし、一口に「自動化」といっても様々なものがあります。 例を並べると以下になります。 IT 自動化 ビジネスの自動化 ビジネスプロセス自動化 ロボティック・プロセス・オートメーション 産業オートメーション 人工知能 機械学習 ディープラーニング 　一番自動化でイメージしやすいのは「産業オートメーション」でしょうか。 工場などで製品の品質安定や人員の安全のためにロボットによる製作が該当します。 元々はこれがオートメーション(自動化)と呼ばれていたようですが、上記にもあるビジネスの自動化が出現したため混同しないよう「産業オートメーション」となったようです。 　自動化をすることによって生産性の向上が期待できるのはもちろんのことですが、同時に信頼性の向上も期待できます。 機械で繰り返し同じ作業を行うため、テスト時点でほぼ問題ないとなっていればほぼ同じクオリティを出すことが可能です。 (ビジネスプロセス自動化、 ロボティック・プロセス・オートメーション 、産業オートメーションが特に恩恵が大きいのではないかと思います。) インフラで自動化といえば・・・ 　やはりサーバの構成管理となります。(上記でいうと「ITの自動化」にあたります) とはいえ、サーバの構成管理といっても範囲が広いため、もう少し細分化すると以下になります。 OSや ミドルウェア の設定ファイルの一元管理 サーバ構成のコード化 冪等性の担保 　これらをツールを使用して管理と実行の自動化を行っていきます。 そうすることで属人化の防止、人為的ミスの削減、サーバの新規構築や設定変更時の作業時間短縮といったことが見込めます。 　今まで物理サーバを サーバラックへマウント から サービスが提供できる状態 までおおよそ1日はかかると思います。 それを自動化すると数時間まで短縮させることも可能になります。 特に複数のサーバを構築するとなった場合は効果は目に見えて変わりますね。 主な使用例 構成管理 ・使用ツール： Git＋Ansible 、 Git＋Terraform 、 CloudFormation 　サーバのMWやその設定ファイルの管理。 管理している側を正としておき、変更を行うときはGit側に行い常に冪等性を担保できる状態にしておきます。 AnsibleのymlファイルやtemplateなどをGitで管理していきます。 メンテナンス/リリース ・使用ツール： Git＋Ansible＋Rundeck 　Rundeckなしでもansible-playbookコマンドでも管理対象サーバに変更を反映させることはできます。 ですが、Rundeckを使用することであらかじめ作成したジョブを実行させることが可能です。 また設定した時刻に自動実行させることもできます。 (つまり夜間作業でずっと起きている必要がなくなる！) 動作確認 ・使用ツール： Git＋ Selenium 　ブラウザ操作の動作確認などを自動化することが可能。 特に同じ動作確認を複数のサーバで実施するときに一括で行うことができ、基本的に起動後は完了するまで待つだけでよくなります。 Gitは、Ansible同様に Selenium の ソースコード を管理します。 自動化ツールの簡単な紹介 インフラの自動化で使用される主なツールをざっくりと紹介します。 Git 　 分散型 バージョン管理システム 。 今となってはメジャーなツールですね。 サーバ上のファイルを直接変更すると、事前にバックアップとしてコピーを取っていなかった場合、差分の確認もできず最悪もとの正常に状態に戻せないこともあります。 またコミットのコメントも残せるので、いつ・だれが・どういう変更を行ったかを追いやすいのもポイントです。 ただし、チーム内でルールを決めておかないと想定外の変更が入っていたり、リリースするブランチを間違えたりするので注意です。 Ansible 　 Agentlessなインフラ自動化ツール 。 手動で行っていた手順をプログラム化してサーバにプッシュすることが可能です。 ansible playbookは人間が読み取れる「 YAML 形式」で記述でき、様々なモジュールや実行したコマンドの結果で処理を分岐するなどある程度複雑なことも可能です。 デフォルトでは ssh で接続を行い、対象サーバにて上記のansible playbookの処理が行われます。 対象サーバもansible上で管理することができ、タグ付けでグループごとに実行するといったことも可能です。 Ansibleイメージ図 Terraform 　 マルチ クラウド 上のコンピュータやネットワークの構築を自動化するツール 。 IaC(Infrastructure as Code)を実現するために、開発されたツールです。 AWS だけでなくAzure、 GCP と特定のプロバイダーに限定されることなくインフラ構成をコード化することが可能となっています。 こちらもAnsibleと同様にコードをGitでバージョン管理することができます。 ただあくまで、インフラ構成までを管理することができます。 それより上のレイヤーについてはAnsibleを使用することになります。 AWS CloudFormation 　 AWS リソースのモデル化およびセットアップに役立つサービス 。 Terraformと異なり AWS でのみ利用可能です。(頭に AWS とついているので当たり前ですが。。。) AWS 特化のためリソース間の依存関係等については、いい感じに吸収してくれているようですが、コード化しきるまでが大変かつサービスの一部なので無料利用枠を超えてしまうと料金が発生してしまいます。 他にどれだけ AWS のサービスを使用しているかによりますが、どっぷり AWS に浸かっているのであればTerraformよりもこちらの方が良いかもしれませんね。 Rundeck 　 Agentlessなジョブ管理ツール 。 Rundeckを実行するサーバから対象サーバへ、 ssh が可能であれば使用することができます。 ジョブネットを作成することが可能であり、もしジョブAの実行に失敗したらジョブBは実行させずに終了させるなどが可能となっています。 また、cronと同じ要領であらかじめ指定した日時にジョブをスケジュール設定させることも可能です。 失敗時に通利することもできるので、定常作業であればジョブを作りこんでおけば夜間であってもコンソール画面に張り付いて作業を行う必要がなくなります。 夜間でなくても作業日時が決まっている場合スケジュール設定していれば、万が一作業のことを忘れてしまっても安心ですね。 Rundeckのイメージ Selenium 　 Web ブラウザの操作を自動化するための フレームワーク 。 対応ブラウザは Chrome 、 Firefox 、 Internet Explorer などがあり、それぞれのドライバーを実装することで各ブラウザに備わっている自動操作ライブラリを使用することができます。 しかし、ブラウザのバージョンは自動更新されますがドライバーはされないためドライバー管理ソフトウェアを使用する、もしくは 環境変数 にてドライバーを使用している場合は、その都度ドライバーを手動インストールしてくる必要があります。 とはいえ、何度も手でページ遷移を行うよりも Selenium で自動化されている方が断然楽になります。 おわりに 　インフラの運用保守ではリリース作業などで深夜作業が多くなりがちです。 ですが、今回紹介した自動化ツールを使用することで、作業担当者が夜中ずっと起きてPCに張り付いている必要がなくなります。 　それだけでなく、手動実行する場合であっても基本的にツールを実行するだけであり、誰が実行しても同じ結果となります。 そのため特定のメンバーしか作業ができない。。。といった属人化の防止にもつながります。 といいことばかり言っていますが、自動化するにはそれなりに労力と時間がかかるので一筋縄ではいきません。。。 　既存環境を構成管理しようとすると、まずはどこまでの範囲を管理する必要があるのか、今までのリリース手順で自動化する場合、失敗したことを検知できるようエラーハンドリングを十分に行う必要があります。 エラーハンドリングが不十分な状態で自動化してしまうと、失敗したまま処理が進んでしまい取返しのつかないことになりかねないです。 そのためにも、しっかりと現状把握と自動化の準備を行ったうえで検証、動作確認、実装に望むことが大切です。 参考文献 自動化について 【初心者向け】Gitとは何なのか。基本用語やその仕組みをまとめています。 Ansible とは 5分で分かるTerraform（Infrastructure as Code） AWS CloudFormation とは ジョブスケジューラ「Rundeck」を試してみる Seleniumを理解する！初心者でも分かる歴史、特徴、基礎知識などを簡単に解説！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

皆様こんにちは。インフラエンジニアのryuhei55225です！ 前回の記事 は【Kibana 入門】という形で「Elastic Stack」(Kibana+Logstash+Elasticsearch)を Linux サーバにインストールして、簡単なデータのグラフ化を紹介させて頂きました。 こちらの記事では、MWのインストール等のサーバ構築がメインとなってしまい、具体的なElasticsearchへのデータ投入やデータ検索・グラフ化に関しては紹介することが出来ておりませんでした。 （データ検索・グラフ化に関しては、完全に省略しておりました。。） ということで・・・ 今回の記事は「Kibana 基礎」という形で、実際前回構築したサーバのElasticsearchにLogstash経由でデータを投入して、Kibanaにてデータをグラフ化をしていく流れについて、具体的に紹介 していこうと思います。 今回の流れとしては、 まず、Logstashの機能について一般的なことを紹介 その後、実際に今回やってみた内容（データのグラフ化）を紹介 していきます。 なんで、Logstashについてある程度理解されている方は、「実際にやってみた」から見て頂ければと思います。 Logstashを用いたデータの収集・加工・転送 Inputプラグイン Filterプラグイン Outputプラグイン 実際にやってみた データの準備 Logstash設定ファイルの作成 設定の反映と確認 今回作成した設定ファイルについて Inputプラグイン Filterプラグイン Outputプラグイン Kibanaを用いたGUIでのElasticsearchデータ確認 KibanaによるElasticsearchデータのグラフ化 グラフの選択 対象のデータを選択 Y軸の設定 X軸の設定 最後に Logstashを用いたデータの収集・加工・転送 Logstashは、さまざまなデータソースからのログやデータを、収集・加工・転送するためのツールです。 前回の記事では、その中の機能の一部として、 CSV ファイルからデータを収集して、Elasticsearchにデータを転送する形を紹介させて頂きましたが、実際にLogstashで出来ることはたくさんありますので、もう少しその要素（ コンポーネント ）について見ていきたいと思います。 Logstashの設定は、大きく「Input」「Filter」「Output」に分けられます。 「Input」でデータを収集して、「Filter」で加工、「Output」で転送という流れです。 それぞれの プラグイン ごとに、様々なものと連携可能ですので、ざっくり プラグイン について紹介していこうと思います。 Input プラグイン Input プラグイン で対応しているデータの取得対象は数多くあります。 全て紹介することは出来ませんので、今回は前回しようした「file」をもう少し詳細に紹介していこうと思います。 その他にも、「Elasticsearch」を指定することで、Elasticsearchのデータを取得するなんてことも出来ます。 以下サイトに対応している プラグイン の記載がありますので、詳しくはやりたいことにあった プラグイン を調べてもらえればと思います。 www.elastic.co Filter プラグイン Filter プラグイン では、実際にデータの整形を実施していきます。 こちらも様々な プラグイン が存在しますが、今回は実際にInput プラグイン で指定した CSV ファイルを整形するにあたって、よく使う プラグイン や便利な プラグイン について紹介していきます。 こちらも、以下サイトに対応している プラグイン の記載がありますので、もっと勉強したい方はこちらも参考にして頂ければと思います。 www.elastic.co Output プラグイン 最後にOutput プラグイン です。 こちらはデータの出力先となり、様々な プラグイン に対応がありますが、「Elastic Stack」を構成している場合は、ほとんどElasticsearchになるかと思います。 今回も実際に CSV ファイルからInputしたデータを、Filterで整形して、ElasticsearchにOutputする形を紹介していきます。 www.elastic.co 実際にやってみた ということで、早速サンプルデータをLogstash経由でElasticsearchに投入して、Kibanaでグラフ化していく流れを紹介していきます。 データの準備 今回用意したデータは、以下のようにtest-serv01~50のサーバのディスク容量を使用量を残容量に分けて一週間に一度計測したデータを CSV ファイルにしています。 こちらのデータをElasticsearchに投入していこうと思います。 # cat /data/server_disk_check.csv 2021/10/01 00:00:00,test-serv01,DBディスク使用量(GB),51.890850067139 2021/10/01 00:00:00,test-serv01,残DBディスク容量(GB),55.363399505615 2021/10/01 00:00:00,test-serv02,DBディスク使用量(GB),38.047119140625 2021/10/01 00:00:00,test-serv02,残DBディスク容量(GB),49.211036682129 2021/10/01 00:00:00,test-serv03,DBディスク使用量(GB),40.542625427246 2021/10/01 00:00:00,test-serv03,残DBディスク容量(GB),46.715530395508 2021/10/01 00:00:00,test-serv04,DBディスク使用量(GB),37.850318908691 ・ ・ ・ 2021/10/01 00:00:00,test-serv49,DBディスク使用量(GB),24.080196380615 2021/10/01 00:00:00,test-serv49,残DBディスク容量(GB),103.170146942139 2021/10/01 00:00:00,test-serv50,DBディスク使用量(GB),3.631404876709 2021/10/01 00:00:00,test-serv50,残DBディスク容量(GB),83.626750946045 2021/10/08 00:00:00,test-serv01,DBディスク使用量(GB),51.983116149902 2021/10/08 00:00:00,test-serv01,残DBディスク容量(GB),55.271133422852 2021/10/08 00:00:00,test-serv02,DBディスク使用量(GB),38.138965606689 2021/10/08 00:00:00,test-serv02,残DBディスク容量(GB),49.119190216064 ・ ・ ・ 2022/05/27 00:00:00,test-serv49,DBディスク使用量(GB),26.486736297607 2022/05/27 00:00:00,test-serv49,残DBディスク容量(GB),100.763607025146 2022/05/27 00:00:00,test-serv50,DBディスク使用量(GB),13.513370513916 2022/05/27 00:00:00,test-serv50,残DBディスク容量(GB),73.745048522949 Logstash設定ファイルの作成 このデータをElasticsearchに投入するための設定ファイルを以下のように記載します。 これで、 CSV ファイルのデータをそのままElasticsearchに投入可能です。 # cat /etc/logstash/conf.d/server_disk_check.conf input { file { path => "/data/server_disk_check.csv" start_position => "beginning" type => "server_disk_check" } } filter { if [type] == "server_disk_check" { csv { columns => [ "date" , "host" , "item" , "number" ] separator => "," } date { match => [ "date" , "YYYY/MM/dd HH:mm:ss" ] } mutate { convert => { "number" => "float" } } } } output { if [type] == "server_disk_check" { elasticsearch { hosts => ["localhost:9200"] index => "%{type}" } } } 設定の反映と確認 上記ファイルを作成したら、Logstashのサービスを再起動して、Elasticsearchにインデックスが作成されていることを確認します。 # systemctl start logstash.service # curl -XGET 'http://localhost:9200/_cat/indices?' yellow open server_disk_check wKGD-LlKSPqZjHJK8UMa_Q 1 1 3500 0 730.9kb 730.9kb curl でElasticsearchの情報をとってきて、「server_disk_check」のインデックスが作成されていることを確認できれば、一旦OKです。 ※ここでElasticsearchにインデックスが作成されていない場合は、「/var/log/logstash/logstash-plain.log」を確認しましょう。 　設定ファイルの書式間違い等であれば、こちらのログに何が間違えているか記載されていることが多いです。 今回作成した設定ファイルについて では、設定ファイル(/etc/logstash/conf.d/server_disk_check.conf)に話を戻して、詳しく設定内容について確認していきます。 Input プラグイン まずInputからですが、今回は CSV ファイルからのデータ取得ですので、file プラグイン を使用します。 「path」 ここで、読み取る CSV ファイルのパスを指定します。 当たり前ですが、ここで設定しないと、Logstashはどのファイルを読み取ればいいのか、判断つきません。 「start_position」 こちらは、Logstash起動時にファイルの行頭から読むのか末尾から読むのかを指定します。 今回のデータに関しては、タイムスタンプ(date)も同時に出力するので、どちらでも問題はないのですが、通常ファイルの最初からデータを作成するので、作成した順にデータの読み取るよう、「beginning」を指定します。 ※デフォルトは、「end」(末尾から読み取り)になっているようです。 「type」 Logstashで取得するデータが今回のものだけであれば、こちらの設定は不要になりますが、明示的に「type」を設定することで他のLogstashの設定と混ざらないようにします。 ここでは、分かりやすいように、ファイル名=インデックス名=「type」=「server_disk_check」とします。 ※もちろん、それぞれの名前を分けることも可能です。 Filter プラグイン 続いてfilterについて確認していきます。 流れ的にはInputした CSV ファイルからデータを取得して意図した形にデータを整形することになりますが、その前にInputで使用した「type」(server_disk_check)の条件分岐をしてあげます。 ※これを忘れると、他のインデックスに影響を与えてしまします。 「 csv 」 columnsにて カラム名 をしていきます。 見たままですが、今回は左から「タイムスタンプ、サーバ名、対象データ、値」となっておりますので、分かりやすいように 命名 していきます。 「date」 Elasticsearch で「timestamp」として使用するカラムの日時フォーマットを指定します。 CSV ファイルに記載したフォーマットをそのまま記載すればOKです。 「mutate」 CSV ファイルから取得したデータは、デフォルトで文字列として認識されて、Elasticsearchに出力されてしまいます。 そのため、数値については、convertを使用してfloat等にデータ型を変更する必要があります。 mutateについては、convert以外にも使用可能ですが、今回は省略させて頂きます。 Output プラグイン 最後にoutputです。ここは特に難しいことはしておらず、見たままかと思います。 今回は、「type」=インデックス名としたので、インデックスの指定を"%{type}"としています。 Kibanaを用いた GUI でのElasticsearchデータ確認 続いて、Elasticsearchに入れたデータを実際にKibanaで確認してグラフ化していきたいと思いますのが、 その前に、Elasticsearchにどのような形でデータが投入されているかKibanaの GUI 上で確認していこうと思います。 まずは、Kibanaに新しく作成したインデックスをElasticsearchに登録します。 メニューから、「Stack Management」→「Index patterns」と選択して、「Create index pattern」からインデックスをElasticsearchに登録していきます。 ※次の画面で出てくる「Time field」に関しては、「date」を選択してあげます。 インデックスの登録が完了しましたら、実際にどのような形でElasticsearchにデータが投入されているか確認していきます。 今回はKibanaのDiscover画面から確認していきます。 続いての画面で、 ①：今回作成したインデックスを選択 ②：対象期間を選択（今回は一年） ③：表示するカラムを選択※デフォルトだと全て表示されるため、見づらくなります を実施していくと、以下のような形で、実際にElasticsearchにデータが投入されていることが確認できます。 この時点でKibanaのFilterを駆使することで、見たいデータだけを選択することも可能ですが、 今回は「Visualize Library」からElasticsearchのデータをグラフ化する流れについて説明していきます。 KibanaによるElasticsearchデータのグラフ化 ようやくElasticsearchにデータが投入されていることが確認できましたので、ここから実際にグラフ化していきたいと思います。 グラフの選択 グラフ化に関しては、「Visualize Library」という部分から実施していきます。 上記、画面で「Create visualization」を選択して、作成するグラフを選択していきます。 今回は、単純にディスク容量の推移を確認するために、折れ線グラフを使用していきたいと思います。 以下のように、選択して最後に対象インデックスに今回作成したものを選択します。 続いて、 GUI 上からグラフの設定をしていくことで、以下のようなグラフを作成していきます。 今回は、サーバ毎のディスク使用量の推移をグラフ化していきます。 （あくまで参考ですので、自身で実施する際はこちらを参考に、色々設定をいじってみてください。） では、続いてグラフ作成の手順を紹介していきます。 対象のデータを選択 今回Elasticsearchには、「DBディスク使用量(GB)」と「残DBディスク容量(GB)」の2種類が存在しますので、 「DBディスク使用量(GB)」のみが対象になるように、フィルターしてあげます。 フィルターは画面左上の「Add filter」から以下のように設定してあげます。 Y軸の設定 画面右に表示されている設定の「data」から「Metrics」の設定をしていきます。 具体的に言うと、Y軸に何の値をとるか、です。 Aggregation 今回は、サーバ毎にデータが一つしかありませんので、設定はなんでも問題ありません。 もし、全サーバのディスク容量の合計を表示したいとかであれば、こちらを「Sum」にする必要があります。 ※その場合は、グラフの分割方法についても修正する必要があります。 Feild 今回は、実際の値（ディスク容量）を表示したいので、Elasticsearch内のカラム「number」を「Field」に選択します。 Custom label グラフのラベル（Y軸）に何を書くかです。 設定しなくてもグラフ化は可能ですが、設定しておくとグラフが見やすくなります。 X軸の設定 続いて、「Buckets」でX軸の設定をしていきます。 今回は、時系列のグラフを作成するので、X軸に日付を選択していきます。 具体的には、「X-axis」を以下のように設定します。 続いて、「Split series」でグラフの分割方法を選択していきます。 今回はサーバ毎に折れ線を分けたいと思いますので、「Sub aggregation」で「Terms」を選択して、 「Field」で分割する単位である「host.keyword」を選択します。 これで、グラフの設定は以上です。 ここまで設定すれば、初めに見せたグラフが表示されるはずです。 最後に 今回はグラフ化ということで紹介はここまでにさせて頂きますが、Kibanaでは様々なグラフが作成できますので、実際に触っていくと、「こんなこともできるのか」といった発見があるかと思います！！ サーバ毎の推移をグラフ化しましたが、その他にもディスク使用容量の全体の合計値の推移や、単位時間当たりのディスク使用容量の最大値の取得等、データさえ入っていれば、だいたいのことは出来ると覆います。 一般的な監視ツール（ Nagios 、Zabbix、etc...）でも簡単なグラフの作成は可能ですが、Kibanaに比べると対応しているグラフは少ないかと思います。 そんな時は一度Kibanaにデータを移行してあげれば、作成したグラフが簡単に取得できる、なんてこともあるかと思います。 ということで、今回の紹介は以上にさせて頂きたいと思います。 次回も書くことがあれば、「応用編」としてElasticsearchやLogstashの便利な使い方について紹介していこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、弊社サービスのインフラを運用している id:keijiu (ijikeman)です。 今回は、 「Ansible実行を1/3に高速化した話」 を記載します。 目次 目次 背景 1. 実行時間の把握 1-1. Callbackプラグイン[profile_tasks]を有効にする 1-2. CallBack Plugin有効化の確認 2. Ansibleコードチューニング 2-1. 各タスク実行時間の確認 2-2. パッケージインストール処理の見直し 2-2-1. コードの確認 2-2-2. コードの修正 2-3. 動的書き換えの見直し 2-3-1. コードの確認 2-3-2. コードの修正 3. Ansible実行環境チューニング 3-1. 並列実行数の変更 3-2. Pipelining Pipeliningの有効化 Pipelining有効化の確認 3-3. サードパーティ製 Strategy Plugin (Mitogen for Ansible) Mitogen利用時に気付いた点 Mitogenの利用方法 3-4. 上記実行環境毎の実行速度の計測比較結果 実行速度検証総括 4. 高速化の結果 背景 3年ほど前よりAnsible構成管理を推進を開始し、ようやく ラク スの各商材のAnsible化の割合が大幅に増えました。 構成管理対象サーバの増加と構成管理範囲が増えるに伴い、Ansibleの実行完了までの時間が大幅に増えていきました。 また、インフラメンバー各自がAnsibleコードを記載し、テスト実行(--check)等をする回数も増えこの「実行時間の長時間化」が問題となりました。 この問題の改善にあたり、調査・検証し、実際に実行時間を大幅に削減した内容を公開させていただきます。 1. 実行時間の把握 まずはAnsibleの全体の実行時間や各タスク毎の実行時間の把握を行い、時間がかかっている処理がどの処理なのかを把握することが重要です。 各タスクの中で時間がかかりすぎているものを把握することで、処理や環境の見直しによって改善できるものがないかを確認します。 1-1. Callback プラグイン [profile_tasks]を有効にする 各タスクの実行に掛かった実行時間を表示するために、callback プラグイン profile_tasksを有効化します。 $ /etc/ansible/ansible.cfg --- [defaults] callback_whitelist = profile_tasks --- もしくは 実行時にANSIBLE_CALLBACK_WHITELIST='profile_tasks'を設定 ANSIBLE_CALLBACK_WHITELIST='profile_tasks' ansible-playbook ... 1-2. CallBack Plugin有効化の確認 下記の様に各タスクの実行時間が表示され、実行完了後には時間がかかったタスクのTOP20までがリスト表示される様になります。 ... RUNNING HANDLER [os : Install Epel.repo] ***************************************** Sunday 05 June 2022 19:33:32 -0400 (0:00:01.327) 0:00:01.356 ********** skipping: [192.168.0.1] PLAY RECAP ********************************************************************* 192.168.0.1 : ok=34 changed=1 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0 Thursday 05 May 2022 21:09:47 -0400 (0:00:00.058) 0:00:14.804 ********** =============================================================================== os : Install Epel.repo ------------------------------------------ 1.66s os : Install python module for SELinux -------------------------- 1.12s Gathering Facts ------------------------------------------------- 1.07s 2. Ansibleコードチューニング 2-1. 各タスク実行時間の確認 では、実行時間の把握ができるようになったところで、実際のPlaybookを実行しました。 未セットアップの CentOS に対するPlaybookの実行結果は以下のようになりました。(一部伏字) 圧倒的にパッケージのインストール時間が大半でしたので、まずはパッケージインストール処理のコードを確認してみます。 すると 約６割がパッケージインストール処理 でした。 Tuesday 07 June 2022 01:14:14 -0400 (0:00:03.472) 0:05:20.110 ********** common : Install Packages --------------------------------------------- 190.71s common : Copy Scripts ------------------------------------------------- 14.21s os : Server Reboot ------------------------------------------------------- 11.57s os : Server Reboot ------------------------------------------------------- 9.78s os : Install python module ----------------------------------------------- 8.90s os : Install NetworkManager -------------------------------------------- 6.51s ... 2-2. パッケージインストール処理の見直し 2-2-1. コードの確認 実コードは記載できませんが、サンプルコードで説明すると以下の様な処理になっていました。 - set_fact: INSTALL_PACKAGES: - NAME: 'httpd' REPO: 'appstream' - NAME: 'httpd-devel' REPO: 'appstream' - NAME: 'httpd-tools' REPO: 'appstream' - NAME: 'httpd-manual' REPO: 'appstream' - name: Install Packages yum: name: "{{ item.NAME }}" state: 'installed' enablerepo: '{{ item.REPO }}' with_items: "{{ INSTALL_PACKAGES }}" 実際にこのコードを実行すると以下のようになります。 パッケージを１つずつインストールしている為、パッケージ対象が増えれば増えるほど毎回 yum moduleが呼び出され時間がかかる実装になっています。 --- 実行ログ TASK [test : Install Packages] ************************************************ Friday 06 May 2022 01:34:02 -0400 (0:00:00.024) 0:00:07.367 ************ changed: [192.168.0.1] => (item={'NAME': 'httpd', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-devel', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-tools', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-manual', 'REPO': 'appstream'}) ... 2-2-2. コードの修正 以下ansible公式 ansible.builtin.yum module – Manages packages with the yum package manager — Ansible Documentation の yum moduleのサンプルコードにもあるようにパッケージ名は配列にて渡すことができます。 - name: Install a list of packages with a list variable yum: name: "{{ packages }}" vars: packages: - httpd - httpd-tools 以下様に書き換えを行う 「パッケージ名をリスト形式に変更する」 ことで、 yum モジュールの実行回数を大幅に削減することができます。 実際にこのサンプルコードでも実行時間を約半分にすることができました。 - set_fact: INSTALL_PACKAGES: - NAME: - 'httpd' - 'httpd-devel' - 'httpd-tools' - 'httpd-manual' REPO: 'appstream' --- 実行ログ TASK [test : Install Packages] ************************************************ Friday 06 May 2022 01:36:19 -0400 (0:00:00.023) 0:00:03.246 ************ changed: [192.168.0.1] => (item={'NAME': ['httpd', 'httpd-devel', 'httpd-tools', 'httpd-manual'], 'REPO': 'appstream'}) 2-3. 動的書き換えの見直し ラク スで使っているansibleコードテンプレートでは、汎用的な処理を別のタスクファイルにして、 「include_role」や「include_tasks」で動的に読み込み書き換えることで、コードの再利用性を高める取り組みを行っております。 その為、繰り返し処理を行うと毎回コードの動的書き換えと実行が行われる為、処理時間が伸びていきます。 2-3-1. コードの確認 以下のように汎用的な処理を別のロールに集めており $ roles/libraries/tasks/copy.yml --- - name: FILE COPY copy: src: "{{ item.SRC }}" dest: "{{ item.DEST }}" owner: "{{ item.OWNER }}" group: "{{ item.GROUP }}" mode: "{{ item.MODE }}" 呼び出し元からinclude_role等で呼び出して利用しています。 $ roles/test/tasks/main.yml --- - name: Copy files include_role: name: libraries tasks_from: copy.yml with_items: - { SRC: 'test1', DEST: '/tmp/test1', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test2', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test3', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test4', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test5', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test6', OWNER: 'root', GROUP: 'root', MODE: '0644' } 実行すると、毎回copy.ymlが呼ばれる毎に処理が行われる為、毎回TASKが呼ばれます。 TASK [Copy files] ******************** Monday 06 June 2022 02:00:31 -0400 (0:00:01.356) 0:00:01.386 TASK [libraries : FILE COPY] ********* Monday 06 June 2022 02:00:31 -0400 (0:00:00.087) 0:00:01.474 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:33 -0400 (0:00:01.099) 0:00:02.573 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:33 -0400 (0:00:00.910) 0:00:03.484 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:34 -0400 (0:00:00.869) 0:00:04.354 changed: [192.168.0.1] TASK [libraries : FILE COPY] *********** Monday 06 June 2022 02:00:35 -0400 (0:00:00.889) 0:00:05.243 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********* Monday 06 June 2022 02:00:36 -0400 (0:00:00.854) 0:00:06.098 changed: [192.168.0.1] PLAY RECAP ********************************************* 192.168.0.1 : ok=7 changed=6 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Monday 06 June 2022 02:00:37 -0400 (0:00:00.830) 0:00:06.928 *********** =================================================== Gathering Facts --------------- 1.36s libraries : FILE COPY ---------- 1.10s libraries : FILE COPY ---------- 0.91s libraries : FILE COPY ---------- 0.89s libraries : FILE COPY ---------- 0.87s libraries : FILE COPY ---------- 0.85s libraries : FILE COPY ---------- 0.83s Copy files --------------------- 0.09s 2-3-2. コードの修正 動的書き換え(include_*)を使わずに静的処理に変更します。 $ roles/test/tasks/main.yml --- - name: Copy files copy: src: "{{ item.SRC }}" dest: "{{ item.DEST }}" owner: "{{ item.OWNER }}" group: "{{ item.GROUP }}" mode: "{{ item.MODE }}" with_items: - { SRC: 'test1', DEST: '/tmp/test1', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test2', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test3', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test4', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test5', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test6', OWNER: 'root', GROUP: 'root', MODE: '0644' } Ansibleを実行するとわずかですが、実行時間が短くなりました。 書き換えを行う回数が増えるほど効果は高くなりますが、変更による効果はそれほど高くない為、「コードの再利用性」とどちらがよいかはで使い分ける必要がありそうです。 TASK [test : Copy files] *********************************** Monday 06 June 2022 02:01:26 -0400 (0:00:01.413) 0:00:01.437 *********** changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test1', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test2', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test3', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test4', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test5', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test6', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) PLAY RECAP ********************************************************************* 192.168.0.1 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Monday 06 June 2022 02:01:31 -0400 (0:00:05.252) 0:00:06.689 *********** =================================================== test : Copy files --------------------5.25s Gathering Facts -------------------1.41s 3. Ansible実行環境チューニング 3-1. 並列実行数の変更 Ansibleの標準設定では並列で実行するターゲット数が"5"と設定されている為、多くのターゲットに対して実行する場合に時間がかかります。 その為、並列実行数の変更を行います。 FORKS設定はAnsibleの子プロセスを増やす設定の為、増やせば増やすほどCPUへの負荷がかかります。 各CPUの使用率を確認し、不足しているようであればCPU数を増やすことを検討してください。 $ /etc/ansible/ansible.cfg --- [defaults] forks = 5 もしくは 実行時にANSIBLE_FORKS=NUMを設定 ANSIBLE_FORKS=20 ansible-playbook ... 3-2. Pipelining ansibleのデフォルト設定の場合、各タスクを実行する度に以下の例の様にターゲット側の"~{ansible実行ユーザのホーム ディレクト リ}/.ansible/"に python プログラムの展開を行いAnsibleを実行しています。 その為、ターゲットへのデータ転送時間とこれらのファイルの書き込み等により、各タスクの実行に時間がかかります。 /home/ansible_user/.ansible/ansible-tmp-1651804170.1883245-2652826-75480101479031/ 合計 120 drwx------. 2 root root 31 5月 5 22:28 . drwx------. 3 root root 68 5月 5 22:28 .. -rw-------. 1 root root 119155 5月 5 22:28 AnsiballZ_stat.py Pipeliningの有効化 Pipeliningを有効化することで、 ssh のpipeを経由してansibleを実行することで高速化を行うことができます。 $ /etc/ansible/ansible.cfg --- [ssh_connection] pipelining = True ※設定を記載するセクションは[defaults]ではなく[ ssh _connection]であることに注意してください もしくは 実行時にANSIBLE_PIPELINING=True か ANSIBLE_PIPELINING=1を設定 ANSIBLE_PIPELINING=1 ansible-playbook ... 公式ドキュメント Ansible Configuration Settings — Ansible Documentation にもある通り、 requrettyが設定されているユーザでansibleを実行する場合は、sudo設定にて無効にする必要がある為注意が必要です。 Pipelining有効化の確認 Ansible実行時にPipeliningが有効になっているかは、-vvvオプションを付けることで確認することができます。 以下の例の様に "Pipelining is enabled" と出力されていることを確認してください。 ... Pipelining is enabled. <192.168.0.1> ESTABLISH SSH CONNECTION FOR USER: ansible_user ... 3-3. サードパーティ 製 Strategy Plugin (Mitogen for Ansible) Mitogen — Mitogen Documentation Other Toolsとして公式で紹介されているMitogen for Ansibleを使うことで、上記Pipeliningよりも実行速度の高速化を行うことができます。 Mitogenは 実行コードのRAMへのキャッシュ pipelineと同様ターゲットへの書き込み削減 従来のPreforkモデルに加えて、Thread化によるさらなる並列化・高速化 ネットワークコネクションの再利用等 によりAnsibleの実行を高速化することができます。 Mitogen利用時に気付いた点 Mitogen利用時に以下の事象が確認できましたので、利用するには事前に検証が必要です。 現行v0.2.9ではターゲットサーバ側に"/usr/bin/ python "が必要(/usr/bin/python3ではダメ) ansible 2.10以降には未対応 (2022/06/13時点でAnsible v2.10以上に対応するv0.3.xは未リリース 2022/06/13追記) ターゲットの python 環境によっては動かないコードがある include_roleは未対応 CPU使用率がPipeliningよりかなり高い メモリの使用率が高い Pipeliningとの併用はできない どなたかv2.10以降でmitogen for Ansibleが動くよというコメントをいただきましたが、公式ニュースに記載されているように v0.2.xは2.10未満 v0.3.x系は2.10以上 をサポートという風にバージョンが分かれるようです(2022/06/13追記) Release Notes — Mitogen Documentation Mitogenの利用方法 ■Ansible実行環境にMitogenを設置 $ curl -kL -o https://networkgenomics.com/try/mitogen-0.2.9.tar.gz $ tar zxvf mitogen-0.2.9.tar.gz -C /opt/ ■Strategy プラグイン としてmitogenを設定 $ ansible.cfg --- [defaults] strategy_plugins = /opt/mitogen-0.2.9/ansible_mitogen/plugins/strategy ■各playbook毎にstrategyを設定してmitogenを有効化します。(ansible.cfgで全体に適用してもよい) $ playbook.yml --- - name: Test Playbook strategy: mitogen_linear hosts: test-servers ... あるPlaybookの実行時間の差を確認したところ、以下様にかなりの差がありました。 Default状態 ... 0:00:22.399 Pipelining ... 0:00:17.744 Mitogen for Ansible ... 0:00:09.333 3-4. 上記実行環境毎の実行速度の計測比較結果 検証としてターゲットサーバ20台に対し、 ディレクト リ10個作成する処理を行いました。 それぞれの環境毎に5回実行し、一番早い時間と一番遅い時間を除く3回の平均時間を記しています。 [検証結果] AnsibleサーバCPU数 FORK数 CPU使用率 平均実行時間 コメント [Default] 1 5 20 - 40% 01:39 1 10 20 - 70% 01:05 1 20 30 - 100% 00:42 CPUが100%となる場合があり処理待ちが発生 2 5 10 - 20% 01:36 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 10 20 - 40% 01:01 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 20 15 - 80% 00:36 CPU 100%が解消され処理時間が短縮 [Pipelining] 1 5 30 - 40% 00:40 Pipeliningの効果が高いが若干CPU使用率が上昇 1 10 30 - 70% 00:28 Pipeliningの効果が高いが若干CPU使用率が上昇 1 20 30 - 100% 00:21 Pipeliningの効果が高いが若干CPU使用率が上昇 2 5 15 - 30% 00:38 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 10 20 - 40% 00:26 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 20 30 - 50% 00:17 CPU 100%が解消され処理時間が短縮 [Mitoge] 1 5 100% 00:18 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 1 10 100% 00:16 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 1 20 100% 00:16 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 2 5 25 - 50% 00:19 CPUに余裕がでたが、CPU追加効果なし 2 10 40 - 60% 00:16 CPUに余裕がでたが、CPU追加効果なし 2 20 30 - 70% 00:14 SWAPが発生 2+2GBメモリ 20 50% 00:14 メモリを追加することでSWAPが解消 実行速度検証総括 Pipelining Ansible標準機能として実装されている為、手軽に利用が可能で効果が高い為、標準で利用できるようにしておくとよい。 Ansible実行側のCPU使用率の上昇が若干見られるが、実行環境の大幅な見直しは必要ない。 並列実行数(ANSIBL_FORKS) 並列実行数を上げて実行する場合はAnsible実行側のCPU使用率を確認して引き上げる必要がある。 Mitogen for Ansible CPUの使用率が高い為、CPUの割り当て数に注意が必要。 並列実行数を増やすAnsible実行サーバのメモリ使用量が上がる為、メモリの割り当てに注意が必要。 初期導入作業が必要だが、Pipelineよりも効果が高い。 4. 高速化の結果 最終的に Mitogen Plugin及び上記コードの改修等を進め 以下の様に 1/3に高速化することができました！！ ■改修前 Tuesday 07 June 2022 01:14:14 -0400 (0:00:03.472) 0:05:20.110 ********** ■改修後 Tuesday 07 June 2022 01:04:01 -0400 (0:00:02.327) 0:01:34.366 ********** 終わり エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに はじめまして。knng1です。 本記事では、AnsibleのRoleの使用方法についてまとめていきたいと思います。 Ansibleを実務で使用する場合、基本的にはRole化されているところが多いと思いますので、 これからAnsibleを触る方 最近Ansibleの勉強を始めた方 の参考になれば幸いです。 はじめに １．Ansible とは ２．Ansible 使用例 ディレクトリ sample.yml 実行ログ ３．Roleについて ディレクトリ sample-role.yml roles/yum/tasks/main.yml roles/template/tasks/main.yml roles/template/handlers/main.yml 実行ログ ４．その他の機能について defaults （roles/<Role名>/defaults/main.yml） サンプル vars （roles/<Role名>/vars/main.yml） files （roles/<Role名>/files/main.yml） meta （roles/<Role名>/meta/main.yml） ５．Ansible Role おまけ ansible-galaxy init １．Ansible とは Ansibleは RedHat 社が開発する OSS の構成管理ツールです。 あらかじめ記述したPlaybookファイル通りにソフトウェアのインストールや設定を自動で行うことができます。 管理対象機器には SSH プロトコル を使用するため、エージェントレスでの導入が可能です。 新規に構築するシステムはもちろん、すでに数十台、数百台を管理しているようなシステムでも容易に導入ができます。 詳細はAnsibleを説明している 公式ドキュメント をご参照ください。 ２．Ansible 使用例 今回は apache のインストール、confファイルの配布、サービスの再起動を行う簡単なPlaybookを作成しました。 ※Playbookの詳細については こちら ディレクト リ ├── ansible.cfg ├── sample.yml ├── templates │ └── httpd.conf.j2 └── test-hosts sample.yml [root@AnsibleServer ansible]# cat sample.yml --- - hosts: test-server gather_facts: false tasks: - name: install apache yum: name: httpd state: installed - name: setup apache template: src: httpd.conf.j2 dest: /etc/httpd/conf/httpd.conf - name: restart apache service: name: httpd state: restarted enabled: yes 実行ログ Playbookを実行すると下記のようなログが出力されます。 changedが表示されていれば、taskの実行によってターゲットのサーバに変更が加えられたことを示しています。 [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [install apache] *********************************************************************************************************************************************************************************************** changed: [test-server] TASK [setup apache] ************************************************************************************************************************************************************************************************* changed: [test-server] TASK [restart apache] *********************************************************************************************************************************************************************************************** changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ３．Roleについて AnsibleのRoleは処理毎にグループ化して分割する機能です。 roles アトリビュート で対象のグループ(Role)を呼び出すと「roles/<Role名>/tasks/main.yml」が読み込まれます。 ※「main.yml」以外の名前ではincludeやimportをしないと読み込んでもらえないのでご注意ください。 また、rolesを使用している場合、handlersを使用することができます。 handlersは「roles/<role名>/tasks/main.yml」内の対象のタスクがchangedステータスで終了した場合に実行される処理です。 ここで実行したい処理は「roles/<role名>/handlers/main.yml」に記述し、tasks配下のmain.ymlで「notify: <タスク名>」を記述して呼び出します。 コンフィグファイルの配布等、サーバに変更が加わった場合のみサービスを再起動したい場合にとても有用な機能です。 サンプルPlaybookをrole化して分割すると、以下のような感じになります。 ディレクト リ ├── roles │ ├── template │ │ ├── handlers │ │ │ └── main.yml │ │ ├── tasks │ │ │ └── main.yml │ │ └── templates │ │ └── httpd.conf.j2 │ └── yum │ └── tasks │ └── main.yml ├── sample-role.yml └── test-hosts sample-role.yml - hosts: test-server gather_facts: false roles: - yum - template roles/ yum /tasks/main.yml --- - name: install apache yum: name: httpd state: installed roles/template/tasks/main.yml --- - name: setup apache template: src: httpd.conf.j2 dest: /etc/httpd/conf/httpd.conf notify: restart apache roles/template/handlers/main.yml --- - name: restart apache service: name: httpd state: restarted enabled: yes 実行ログ [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample-role.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [yum : install apache] ***************************************************************************************************************************************************************************************** changed: [test-server] TASK [template : setup apache] ************************************************************************************************************************************************************************************** changed: [test-server] RUNNING HANDLER [template : restart apache] ************************************************************************************************************************************************************************* changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ４．その他の機能について AnsibleのRoleには前述した「tasks」、「handlers」、「templates」以外にもいろいろな機能があります。 便利に使用できるものが多いので、簡単に説明させていただきます。 defaults （roles/<Role名>/defaults/main.yml） 対象のAnsibleのRoleは、デフォルト変数を定義する機能です。 その他の変数ファイルで定義された場合、ここで定義された変数は上書きされます。 記述方法はその他変数ファイルと同様です。 サンプル --- ansible_user: root package: - { state: installed , name: httpd } - { state: installed , name: tomcat } vars （roles/<Role名>/vars/main.yml） その名の通り、変数を定義する機能です。 ここで定義する変数は最後に読み込まれるため、「defaults」はもちろん「group_vars」や「host_vars」の変数も上書きます。 デフォルト変数はともかく、変数ファイルが複数個所にまたがって配置されると管理が煩雑になるため、 個人的には特別な理由がない限りは「group_vars」や「host_vars」を使用した方が管理しやすいと思います。 files （roles/<Role名>/files/main.yml） Copyモジュールを使用する際にファイルを格納する ディレクト リです。 ここに格納されたファイルはファイル名のみで呼び出し可能です。 meta （roles/<Role名>/meta/main.yml） Ansibleの各Roleの依存関係を定義するファイルです。 「 yum 」のmeta/main.ymlで「template」を指定した場合、下記のように「template」⇒「 yum 」の順に実行されてしまいますので注意が必要です。 [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample-role.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [template : setup apache] ************************************************************************************************************************************************************************************** changed: [test-server] TASK [yum : install apache] ***************************************************************************************************************************************************************************************** changed: [test-server] RUNNING HANDLER [template : restart apache] ************************************************************************************************************************************************************************* changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ５．Ansible Role おまけ ansible-galaxy init AnsibleのRoleの各 ディレクト リは「ansible-galaxy init <Role名>」で簡単に生成できます。 新規でAnsibleのRoleを作成する際に利用してみてください。 [root@AnsibleServer ansible]# ansible-galaxy init roles/test - Role roles/test was created successfully [root@AnsibleServer ansible]# [root@AnsibleServer ansible]# ll roles/test total 4 drwxr-xr-x 1 root root 512 May 29 11:42 defaults drwxr-xr-x 1 root root 512 May 29 11:42 files drwxr-xr-x 1 root root 512 May 29 11:42 handlers drwxr-xr-x 1 root root 512 May 29 11:42 meta -rw-r--r-- 1 root root 1328 May 29 11:42 README.md drwxr-xr-x 1 root root 512 May 29 11:42 tasks drwxr-xr-x 1 root root 512 May 29 11:42 templates drwxr-xr-x 1 root root 512 May 29 11:42 tests drwxr-xr-x 1 root root 512 May 29 11:42 vars エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに JUnitとSpockについて ライフサイクルの定義 テストクラス データドリブンテスト まとめ はじめに こんにちは、ryrkssです。 今回は、今のプロジェクトのテスト フレームワーク に JUnit と Spock が使われているので、 簡単なテストコードでどう書き方が違うのか比較してみようと思います。 また、それぞれ各テストで出てくる アノテーション や検証メソッドについての説明は割愛します。 本記事で使う JUnit は JUnit5 です。 以後 JUnit が多発しますが全て JUnit5 として捉えていただければ幸いです。 JUnit とSpockについて みなさんご存知の方は多いと思いますが「知らないよ」という方に向けてちょっとだけまとめます。 JUnit Java のテスト フレームワーク といえば真っ先に思い浮かぶ有名なテスト フレームワーク です。 Java エンジニアであれば全ての人が通る道ではないでしょうか。 Spock Groovy で動作する Java のテスト フレームワーク です。 Java とは違う言語で書くので「違う言語覚えないといけないのか」と思う人もいるかもしれませんが、 Java とほぼ同じ感覚でコーディングできます。 何よりデータドリブンテストが JUnit と比べて非常に書きやすく可読性も高いです。 あとは、MockAPIが標準で入っていることも嬉しい人には嬉しいと思います。 ※私は使い慣れている Mokito を使っちゃってますが。 JUnit と Spock は共存できるので、是非どちらも試してみてください。 それでは、 JUnit と Spock のテストコードの書き方を比べてみます。 ライフサイクルの定義 良く使いますが JUnit は アノテーション 、 Spock はメソッド名で定義します。 JUnit アノテーション で実行タイミングを表現します。 // 各テストメソッドが実行される前に都度実行 @BeforeEach void init() {} // 各テストメソッドが実行された後に都度実行 @AfterEach void cleanup() {} // テストクラスが実行される前に1度だけ実行 @BeforeAll static void initAll() {} // テストクラスが実行された後に1度だけ実行 @AfterAll static void cleanupAll() {} Spock メソッド名で実行タイミングを表現します。 // 各テストメソッドが実行される前に都度実行 def setup() {} // 各テストメソッドが実行された後に都度実行 def cleanup() {} // テストクラスが実行される前に1度だけ実行 def setupSpec() {} // テストクラスが実行された後に1度だけ実行 def cleanupSpec() {} Spock のメソッド名だけで判別してくれるのは、コードがスッキリして良いですよね。 JUnit はお馴染みの アノテーション 定義です。 見慣れすぎて何も思わないです。 テストクラス JUnit @Test @DisplayName( "文字列結合" ) void combineStringsTest() { var expected = "テスト" ; var actual = sut.combineStrings( "テ" , "ス" , "ト" ); assertEquals(expected, actual); } Spock def "文字列結合" () { setup : def expected = "テスト" when : def actual = sut.combineStrings( "テ" , "ス" , "ト" ) then : actual == expected } 単純なテストを書きましたが、結構違いますね。 JUnit と Spock で目に付く違いは、ブロックの定義です。 JUnit はコードを記述しているだけですが、 Spock には setup: や when: など 記載しているもの以外にもそれぞれのフェーズに応じたブロックがあります。 単なる分かりやすくするためだけのものではないので、ちゃんと状況に応じた使い分けをしましょう。 また、こう見ると JUnit は アノテーション @Test を毎回つけなければならないのが冗長に感じます。 検証メソッドについても JUnit はメソッドを使用する必要がありますが、 Spock は等価 演算子 を使うだけで事足ります。 こちらは比較的万能で配列やリスト、数値なども等価 演算子 で検証できます。 データドリブンテスト こちらもよく使います。 同じようなテストを1つ1つメソッドで分けるのは、テストケースが見えにくく可読性が落ちてしまいますよね。 JUnit は ParameterizedTest で検索すると出てくると思いますが、 渡している値と想定結果の関係性が分かりにくく、同時に書きにくいと感じてしまいました。 その反面 Spock は非常に書きやすく、見やすいので実装している時にパターンを洗い出しやすいです。 またレビュー時もテストケースを考えずとも頭に入ってくる感覚で個人的には中毒になるレベルです。 百聞は一見に如かずということで、早速比較してみたいと思います。 JUnit 例として、3種類の書き方を記載します。 まだパラメータが少ない且つ、型を同一にしているので幾分見え方がましですが、 ②、③についてはパラメータ数が多くなる、色々な型が混じるとなると 本当に何のテストをしているのか分からなくなってきますね…。 /* ① 単一パラメータのみを定義する書き方 引数で定義した型に暗黙的に変換される(サポートされている型は要確認) */ @ParameterizedTest @ValueSource(strings = { " テスト " , " テスト" , "テスト " }) void trimTest1(String target) { var expected = "テスト" ; var actual = sut.trim(target); assertEquals(expected, actual); } /* ② csv形式でパラメータを定義できる書き方 デリミタを変更したり外部ファイルを指定することもできる 例は文字列だけだが他の型も定義できて、引数で定義したそれぞれの型に暗黙的に変換される */ @ParameterizedTest @CsvSource ({ " テスト , テスト" , " テスト, テスト" , "テスト , テスト" , }) void trimTest2(String target, String expected) { var actual = sut.trim(target); assertEquals(expected, actual); } /* ③ 別メソッドにパラメータを定義できる書き方 メソッドで引数を定義するので独自の型をパラメータで与えることができたり、 ただのメソッドなので最終的に返り値の形にしてあげれば何でもできるイメージ */ @ParameterizedTest @MethodSource( "trimArguments" ) void trimTest3(String target, String expected) { var actual = sut.trim(target); assertEquals(expected, actual); } static Stream<Arguments> trimArguments() { return Stream.of( Arguments.of( " テスト " , "テスト" ), Arguments.of( " テスト" , "テスト" ), Arguments.of( "テスト " , "テスト" ), Arguments.of( null , "" ) ) } Spock 例として2種類ありますが、どちらもメソッドに @Unroll をつけて、 where: にパラメータを定義していくだけとなります。 また、文字列だけを扱うテストになってますが、勿論他の型が混じっても問題ありません。 簡単なものしか記載していませんが、 where は色々な使い方ができるようなので興味のある方は調べてみてください。 /* ①データテーブルを使用した書き方 1行目がテスト内の変数にマッピングされ、2行目以降がその変数に入れるデータパターン || をつけることで検証用のデータと想定結果を視覚的に分かりやすくできる */ @Unroll( "文字列前後空白除去 #title" ) def "trimTest1" () { when : def actual = sut.trim(target) then : actual == expected where : title | target || expected "前後空白" | " テスト " || "テスト" "前空白" | " テスト" || "テスト" "後空白" | "テスト " || "テスト" "null" | null || "" } /* ②データパイプを使用した書き方 左シフト演算子で変数とデータ部を接続 */ @Unroll( "文字列前後空白除去 #title" ) def "trimTest2" () { when : def actual = sut.trim(target) then : actual == expected where : [title, target, expected] << [ [ "前後空白" , " テスト " , "テスト" ], [ "前空白" , " テスト" , "テスト" ], [ "後空白" , "テスト " , "テスト" ], [ "null" , null , "" ] ] } まとめ いかがでしたでしょうか？ 簡単な例しか出せておらずイメージがつきにくいかもしれませんが、 テストの可読性・書きやすさだけでいうと JUnit よりも Spock の方が印象として良いのかなと私は感じました。 現在のチームでも新しく作るテストクラスは大体 Spock で作ってたりしてます。 ただし、 JUnit にしかできないこともあります。 例えば、 JUnit のネスト( @Nested )を使ってテストをまとめることが Spock ではできません。 テストも色々な書き方があって奥が深いですね〜 テストの実装はベストプ ラク ティスをあまり深く考えてこなかったのですが、 しっかりと可読性や何が最良なコーディングかを考えていかなくてはいけないな、と感じております。 全体を通してかなり Spock よりの記事になってしまいましたが、 結論 JUnit も Spock もどちらも使いやすいです。 最後に...冒頭でも書かせていただきましたが JUnit と Spock は共存できるので 是非実際にそれぞれでテストを書いてみてください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに Gather.Townとは？ 導入しようと思ったきっかけ オフィスの作り方 どう使ったか まとめ・感想 はじめに こんにちは。新卒3年目hy094です。 最近はスパイのアニメにハマっています。ファミリーのやつです。 今回は Gather.Town を導入したらリモートワーク中の開発速度が向上した話をしたいと思います。 Zoomが2人の通話でも制限時間が40分になってしまい、代替ツールを探している方もいるかと思いますので、少しでも判断材料になれば嬉しいです。 Gather.Townとは？ 一言で言うと "Pokemon x Zoom thing" ( Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. ) です。 ポケモン とZoomを掛け合わせたかのようなツールで、ゲーム好きの人には親しみやすくかつZoomに近い使い心地で利用できます。(使い方によってはZoomを上回る利便性すら秘めていると思います。） 表題では「リモートオフィス」と表現しましたが、これは私たちの使い方がリモートオフィスに近かったためです。Gather.Townはオフィスに限らず様々な用途に活用できます。 一例として、社内サークルでの活用事例です。 Gather.Townで社内サークル活動の一部をオンライン化しました - Qiita 導入しようと思ったきっかけ 弊社は基本オフィスワークで、緊急事態宣言やまんえん防止等重点措置などが発令されている場合のみ完全リモートワークになる運用でした。 （ここしばらくは落ち着いており出社していますが、現在もおそらく同様です） 皆さんもご存知の通り、発令したり解除したりが繰り返されていたため、私たちも出社とリモートを繰り返していました。 そこで出社した際にリモートの仕事がどうだったか新卒入社の後輩に聞いたところ、 「気軽に相談しにくい」 といった声がありました。 出社時は隣にちょっと声をかけるだけのところを、チャットで連絡→返信待つ→ZoomURLを共有→入室待つ→相談といった流れで、実装で少し詰まったところを聞くだけで15分〜30分かかるといった状態です。 そこで丁度上記の社内サークルでの導入事例を見て、同じ空間にいれば声をかけやすいのでは？と導入してみることにしてみたのです。 オフィスの作り方 導入方法については再掲になりますが、弊社の昨年の アドベントカレンダー に記載があるのでそちらを参照してください。 Gather.Townで社内サークル活動の一部をオンライン化しました - Qiita ここでは、オフィスの作成方法だけお伝えします。 基本は上記の記事の通りで大丈夫なんですが、「Explore social experiences」でそのままテンプレートが選べなくなっていたので、テンプレートまでの道のりも示しておきます。 一番左の「Set up an office or team social」を選択 左の「Remote Office」を選択 オフィスを改造したり増築する予定がない方はこのまま「Confirm Selection」を押してください。 ※「Confirm Selection」で作成されるspaceに床や壁を追加しようとすると、デフォルトでついている背景など全て消え去ってしまうためです。（一度space作り直しました） ※まだ壁と床の追加はベータ版のようなので、いずれ編集できるようになるかもしれません 壁や床を編集しようとすると以下のような警告が出て・・・ Yesを押すと真っ白になってしまいます！ 「Confirm Selection」がある画面の左下に「See other space」というボタンがあるので、それを選択するとテンプレート選択画面に飛べます。 あとは先程の記事の通り作成していただければ問題なく部屋の改築が可能です。 どう使ったか オフィスとしてGather.Townの特性を最大限活かすための使い方はズバリ 「常時ログインし座っておくこと」 です。 他の作業をやっている時も裏で起動しておき、キャ ラク ターを机の前(椅子の上)に置いておきます。 見た目で「出社してる感」があるのはもちろん、通知機能(ログイン中でGather.Townが非アクティブな人に通知を送ることができる)などを使うことで、オフィスでは普通にやっている「すみません、今お時間いいですか？」をリモートで実現することができました。 実際の作業中の風景↓ （ちなみに、後ろ向いてますが青いのが僕です。 ポケモン のアクア団をイメージしました。） また、逆にチャットで悩んでる雰囲気の人を見つけ、教える側の人が突撃することも容易になりました。 相談がしやすくなったことで一人で悩む時間が格段に減り、結果的に開発がスムーズに進むようになりました。 ただ、一つ大きな問題があり・・・ Gather.Townはそこそこ重く、それを常時起動とするとそれなりにメモリを喰ってしまうことです。 導入の際はマシンスペックやコミュニケーションへの課題感と相談していただければと思います。 まとめ・感想 まず、導入して本当によかったです。 オフィスワークと遜色ないレベルでコミュニケーションが取りやすくなり、開発もスムーズに進むので導入前に比べて楽しく開発できました。 また、Gather.Townの導入は当時2年目の私が提案し、導入に至っています。 若手も色々と提案でき、それをやってみることができる環境は個人的にはとても嬉しいです。 Gather.Townには他にもたくさんメリット／デメリットがありましたが、そちらは別途「 ラクス フロントエンドチーム｜note 」の方にまとめました！ 是非ご確認ください。 note.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