この記事は アーキテクチャテスト Advent Calendar 2020 - Qiita の 25 日目のエントリです。 qiita.com こんにちわ。株式会社 ラク スで「楽楽 労務 」を開発している @kawanamiyuu です。遅くなりましたが、先月開催された JJUG CCC 2020 Fall の登壇レポートです。 イベント概要 プロポーザル 登壇資料 登壇に対する反応 登壇を終えて イベント概要 日時 2020 年 11 月 7 日 (土) 開催形式 オンライン（事前録画放送＋リアルタイムQ&A） 公式サイト https://ccc2020fall.java-users.jp/ タイムテーブル https://confengine.com/jjug-ccc-2020-fall/schedule タイムライン #jjug_ccc since:2020-11-07_00:00:00_JST until:2020-11-08_00:00:00_JST - Twitter Search 発表動画リスト 2020-11-07 JJUG CCC 2020 Fall - YouTube プロポーザル jjug-ccc-2020-fall - マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト | ConfEngine - Conference Platform マイクロサービス アーキテクチャ にチャレンジしたい！しかし、プロダクト立ち上げ時においては、 業務 ドメイン に対する知識の少なさから、適切な粒度のサービス分割が難しい そもそも売れるか分からない、仮説検証を高速にまわしていかなければいけない段階で、MSAで開発・運用するオーバーヘッドが大きい 手段が目的化している感 といった理由から、モノリシックなアプリケーションとして開発を開始するケースは少なくないと思います。一方で、あとから分割すればよいと開発を始めた モノリス で、いざ分割を検討する段階でアプリケーション内の依存関係が複雑に絡み合い、分割したくとも解きほぐすのが困難になってしまっているケースも少なくないはずです。 モノリス で適切なモジュール分割を実現するために ドメイン 駆動設計や、具体的な設計パターンとしてクリーン アーキテクチャ やレイヤード アーキテクチャ などの方法をとることが多い最近のソフトウェア開発において、モノリシックなアプリケーションを構成するレイヤーや ドメイン 、各パッケージ・クラスの依存関係をいかに適切に維持し続け、将来 アーキテクチャ を発展させる可能性を残すか。 この発表ではその１つの有力な方法としての「 アーキテクチャ テスト」についてお話します。 登壇資料 speakerdeck.com 登壇資料のサマリー 登壇に対する反応 (jjug_ccc_b OR archunit) since:2020-11-07_17:00:00_JST until:2020-11-07_18:00:00_JST - Twitter Search 依存関係を適切に設計したいだけ いい言葉だ #jjug_ccc #jjug_ccc_b — Kei Kondoh (@kei_kondoh) 2020年11月7日 私のところは今は人数が少ないので アーキテクチャ に対するレビューもできるし直してももらえるけど人が増えてきたりすると アーキテクチャ の維持って厳しいよなー #jjug_ccc_b — uuuu.kt (@yushi_koga) 2020年11月7日 ここでも ArchUnit ！ #jjug_ccc #jjug_ccc_b — YujiSoftware ☕ (@YujiSoftware) 2020年11月7日 派手さはないけど落ち着いた議論でいいっすな #jjug_ccc #jjug_ccc_b — kabao (@kabao) 2020年11月7日 「ソフトウェアが「ソフト」であるための選択肢を残す」 いいメッセージ！ #jjug_ccc #jjug_ccc_b https://t.co/O7zYARquNL — YujiSoftware ☕ (@YujiSoftware) 2020年11月7日 ハンズオン モデラー がいないと アーキテクチャ の維持は難しいっていう印象があったけど、 アーキテクチャ テストがあれば、少しはそれがマシになりそう #jjug_ccc_b — uuuu.kt (@yushi_koga) 2020年11月7日 今日は arch unit のことを初めて知った。たしかに正しくない依存の記述を、コードレビューで目で見るのは大変なので、自動テストの中でテストできるのは便利＆品質の維持に繋がりますね #jjug_ccc #jjug_ccc_b — Yuusuke Masaki (@makky55makky55) 2020年11月7日 ArchUnit、使ってみたい #jjug_ccc #jjug_ccc_b — lethe2211 / Shuhei Shogen (@lethe2211) 2020年11月7日 登壇を終えて まず今回、当日参加された方、タイムテーブルをご覧になった方はお気づきになったかと思いますが、まさかの アーキテクチャ テストネタかぶり でした！ （もう一つの発表は こちら ） アーキテクチャ テストをテーマにした登壇は、過去に 2 回（ ArchUnit で Java アプリケーションのアーキテクチャを CI する - JJUG CCC 2019 Spring 、 ドメイン駆動設計を支えるアーキテクチャテスト - Object-Oriented Conference 2020 ）行っていて、今回はそれらの内容も整理しながら、「マイクロサービス アーキテクチャ をあきらめないための、 モノリス で始める アーキテクチャ テスト」という主題で登壇内容をまとめました。 私のこれまでのカンファレンス規模のイベント登壇経験としては、最長でも 20 分枠の発表だったため、今回初めて 40 分という枠を満足させるボリュームと質の発表内容を作り上げることできるか不安でした。しかし、資料を作り始めてみると なんだかんだで なんとか、30 分程度の発表に仕上がりました。資料としては 100 ページを超えていたため、もしかすると時間が足りないかも？と一時は思いましたが、事前録画方式だったので淡々としゃべってしまい余裕で時間枠内に収まりました。コロナ禍で無聴衆（オンライン）での発表は何度か経験していますが、目の前に聴衆がいないと、発表中の間のとり方が難しいです。 さて、今回で アーキテクチャ テスト 3 部作 (?) の完結編として、いったん今時点で私が アーキテクチャ というものに対して考えていることは 言語化 できました。今後も アーキテクチャ テストを実際のプロダクト開発の中で実践的に取り組んでいきたいと思っているのと、この手の話は、 プログラミング言語 に関係なく通じるもので 他の言語でのアーキテクチャテスト も試してみて、別の言語コミュニティでも アーキテクチャ テストを布教していきたいと思っています。 それでは、また。 今回はオンラインかつ事前録画だったからかなりましだったけど、登壇する当日までは一定のマインドシェアを持って行かれるので登壇終わったらしばらく何も考えずゆっくりしたいと思うんだけど、終わったら終わったで何か物足りなくて次の機会を探してしまう現象に名前付けたい。（文字数まであとちょっ — ゆう (@kawanamiyuu) 2020年11月7日

こんにちは。新卒の id:w1p と申します。 今回業務でTypeScriptを導入するということで、いい機会なのでTypeScriptについていろいろ調べました。 目次 環境構築 TypeScriptの基本的な文法 型アノテーションの書き方 基本の型 number型 bigint型 string型 boolean型 symbol型 null型 undefined型 型エイリアスで型に別名をつける リテラル型 複合型 object型 array型 tuple型 enum 数値型enumの注意点 class Union型 Intersection型 その他の型 Function型 Index Signitures 特殊な型 any unknown void never インターフェースと型エイリアス インターフェース 2つの違い 宣言のマージ プリミティブ型とUnion型 その他 ジェネリクス ジェネリクスを導入できる場所 関数型 型エイリアス インターフェース tsconfig.json 型を操作する 型のキーワード typeof keyof Lookup Types in extends infer Utility Types Partial / Required / Readonly Pick<T, K> Record<K, T> Exclude<T, ExcludedUnion> Union Distribution Extract<T, Union> Omit<Type, Keys> NonNullable Parameters ConstructorParameters ReturnType InstanceType ThisParameterType OmitThisParameter ThisType Uppercase / Lowercase Capitalize / Uncapitalize まとめ 参考 環境構築 Microsoft 公式がブラウザ上で実行できる サンドボックス を提供しており、これを使用すると手軽にTypeScriptを試すことができます。 TypeScriptから JavaScript への変換結果や、型定義ファイル生成の結果まで見れます。 この記事で出てくるサンプルコードはすべてTS Playground v4.1.2上で行っています。 Playground Link Visual Studio Code や Intellij IDEAなど手元のエディタで書いてローカルで実行したい場合には以下の手順を踏む必要があります。 npm or yarnがインストールされていることが前提です。 Step1. TypeScriptをインストールする $ mkdir ts && cd ts $ npm init -y # yarn init -y $ npm i -D typescript # yarn add -D typescript Step2. .ts拡張子のファイルを作成する $ echo ' console.log("Hello, TypeScript!"); ' > ./hello.ts Step3. TypeScriptを実行する ここでは手軽にTypeScriptを実行する方法として、 tsc を使用する方法と、 ts-node というパッケージを使用する方法を紹介します。 tsc を使用する場合 tsc はTypeScriptを JavaScript へトランスパイルするための公式ツールです。 tsc の挙動は tsc 実行時にオプションとして渡したり、 tsconfig.json というファイルで変更することができます。 hello.ts のあるフォルダで以下を実行します。 $ npx tsc ./hello.ts # yarn run tsc ./hello.ts tsc はトランスパイルした結果を指定された ディレクト リに出力します。 今回は特に指定していませんのでカレント ディレクト リに出力されます。 あとは通常のjsファイルと同様に実行できます。 $ node hello.js Hello, TypeScript! ts-nodeを使用する場合 ts-node を使用すると、 tsc → node という2度手間を省略できます。 $ npm i -D ts-node # yarn add -D ts-node 実行は以下のように行えます。 $ npx ts-node ./hello.ts # yarn run ts-node ./hello.ts TypeScriptの基本的な文法 ここまではどのようにTypeScriptファイルを実行するのかについて見てきました。 ここからは基本的なTypescriptの文法について見ていきます。 型 アノテーション の書き方 型 アノテーション とは、変数や関数の戻り値などの型が何であるかを明示的に指定することです。 基本的には : type の形式で書くことができます。 // 変数nの型をnumberに let n: number = 123 n = 'string' // Type 'string' is not assignable to type 'number'. // argをstring, fの戻り値はvoidに function f ( arg: string ) : void { /* */ } f ( 123 ) // Argument of type 'number' is not assignable to parameter of type 'string'. TypeScriptは 型推論 (型をコンテクストから推論すること)により、全ての場所に型 アノテーション を必要としない仕組みになっています。 // nはnumber型と推論される let n = 123 // tはboolean型と推論される let t = true ; 基本の型 早速ですが、TypeScriptの核となる型についてみていきます。 ここで紹介する型はプリミティブ型と呼ばれる基本的な型です。 number型 number型は実数に加え、無限を表す Infinity , 非数を表す NaN が含まれます。 const n1: number = 123 ; const n2: number = -0 . 1 ; const n3: number = Infinity ; const n4: number = NaN ; bigint型 ES2020で導入されたbigint型は Number.MAX_SAFE_INTEGER(2^53 - 1) よりも大きな整数を扱うことができます。 精度が落ちる可能性があるためnumber型変数へ直接代入することはできず、明示的な変換が必要になります。 let big = 123n ; let num = 123 ; num = big ; // Type 'bigint' is not assignable to type 'number'. big = num ; // Type 'number' is not assignable to type 'bigint'. num = Number ( big ); big = BigInt ( num ); string型 文字列全般をとりうる型です。 const s1: string = "Hello, World!" ; const s2: string = s1.slice ( 0 , 5 ); boolean型 true と false の2つの値をとり得る型です。 let b: boolean ; b = true ; b = false ; b = !!1 ; b = 1 ; // Type 'number' is not assignable to type 'boolean'. symbol型 ES2015から取り入れられた、一意の値を生成するための仕組みです。 const s1: unique symbol = Symbol ( 'abc' ); // typeof s1 let s2 = Symbol ( 'abc' ); // symbol let s3 = Symbol . for( 'abc' ); // symbol const s4 = Symbol . for( 'abc' ) // symbol console .log ( s1 === s2 ); // false console .log ( s2 === s3 ); // false console .log ( s3 === s4 ); // true null型 nullもしくはany型のみを受け付ける型です。 const n1: null = null ; const n2: null = 123 as any ; const n3: null = undefined ; // Type 'undefined' is not assignable to type 'null'. const n4: null = 123 as unknown ; // Type 'unknown' is not assignable to type 'null'. undefined型 undefinedとany型のみを受け付けます。 const u1: undefined = undefined ; const u2: undefined = 123 as any ; const u3: undefined = null ; // Type 'null' is not assignable to type 'undefined'. const u4: undefined = 123 as unknown ; // // Type 'unknown' is not assignable to type 'null'. 型 エイリアス で型に別名をつける 型 エイリアス と呼ばれる機能により、任意の型に別名をつけることができます。 型 エイリアス は type キーワードで作成できます。 type ID = number ; type Name = string ; type Cond = boolean ; リテラル 型 TypeScriptの面白い特徴として リテラル 型があります。 リテラル 型とは、プリミティブ型に含まれる一部の値のみをとりうるような型です。 const で変数を定義する際に、TypeScriptはその値はもう変化しないだろうと考え リテラル 型で推論します。 // numberのリテラル型 let num1 = 123 ; // number型 const num2 = 123 ; // 123型 // stringのリテラル型 let str1 = "abc" ; // string型 const str2 = "abc" ; // "abc"型 // booleanのリテラル型 let bool1 = true ; // boolean型 const bool2 = false ; // false型 後述するUnion型とよく組み合わせて使われます。 // 許容するHTTPメソッドの一覧 type AllowedHttpMethods = "GET" | "HEAD" | "POST" | "PUT" ; let method: AllowedHttpMethods = "GET" ; // OK method = "PUT" ; // OK method = "DELETE" ; // Type '"DELETE"' is not assignable to type 'AllowedHttpMethods'. 複合型 object型 プリミティブ型以外の値をとりうる型です。 オブジェクトの構造を指定することはできません。 const o1: object = { a: 123 , b: "abc" } ; const o2: object = {} const o3: object = 123 ; // Type 'number' is not assignable to type 'object'. const o4: object = null ; // Type 'null' is not assignable to type 'object'. array型 配列を表す型です。 型 アノテーション の方法として T[] と Array<T> の2パターンありますが、前者の方が多く使われています。 const arr1: number [] = [ 1 , 2 , 3 ] ; const arr2: Array < string > = [ "a" , "b" , "c" ] ; tuple型 TypeScriptではタプル型を宣言できます。 タプルは複数の要素からなる組み合わせのような型です。 配列と違うのは、異なる型の要素が共存できる点です。 const tup1: [ number , string ] = [ 1 , "str" ] ; const tup2: [ number , number , number ] = [ 1 , 2 , 3 ] ; const arr: number [] = tup2 ; // number型の要素しかないため配列に割り当て可能 enum tuple同様、TypeScriptは独自に enum を使用できます。 enum は プログラマ が事前に定義した特定の値のみをとりうるような型です。 enum Suits { Diamonds , Clubs , Hearts , Spades } console .log ( Suits.Diamonds === 0 ) // true それぞれの列挙子には値を割り当てることができます。 上の Suits には値を割り当てていませんが、そのような場合TypeScriptは0から数値を割り当てます。 数値型 enum の注意点 「TypeScriptの Enum は使わない方が良い」という意見を聞いたことがある方もいらっしゃるかと思いますが、 1番の問題としては数値型の enum にはすべての数値を割り当てることができてしまう点かと思います。 const suit: Suits = 10000 ; // OK これを回避するためには文字列型の enum を使用するか、もしくはUnion型を使用する方法があります。 enum Suits { Diamonds = "Diamonds" , Clubs = "Clubs" , Hearts = "Hearts" , Spades = "Spades" } const suit: Suits = Suits.Diamonds ; type Suits = "Diamonds" | "Clubs" | "Hearts" | "Spades" ; const suit: Suits = "Diamonds" ; class ES2015から導入されたclass宣言はもちろんTypeScriptでも利用できます。 class Animal { // TypeScriptではprivate / protected / publicが使用できる private species?: string ; constructor( species: string ) { this .species = species ; } } const animal = new Animal ( 'dog' ); animal.species = 'cat' ; // Property 'species' is private and only accessible within class 'Animal'. speciesフィールドはprivateなため、クラス外部から触ることはできずエラーになっています。 Union型 TypeScriptの大きな特徴としてよく挙げられるのがこのUnion型です。型同士を | でつなぐことで作成できます。 Unionの名前通り、Union型は構成する型がとる値それぞれの和集合になります。 type StrOrNum = string | number ; let val: StrOrNum = "str" ; val = 123 ; val = true ; // Type 'boolean' is not assignable to type 'string | number'. この例の StrOrNum はstringがとりうる値とnumber型がとりうる値の両方をとります。 Intersection型 Intersection型はそれぞれの型いずれにも割り当てられる型を作り出します。 Union型を和集合とみるなら、Intersection型は積集合を作り出すイメージです。 type StrOrNum = string | number ; type BoolOrNum = boolean | number ; type I = StrOrNum & BoolOrNum ; let val: I = 123 ; // valはnumber型になる val = 'str' ; // Type 'string' is not assignable to type 'number'. val = true ; // Type 'boolean' is not assignable to type 'number'. その他の型 Function型 Function型は全ての関数を受け付ける型です。 引数の型や数、戻り値の型などは指定できないため、object型と同じく使用頻度は高くありません。 let fun: Function = ( arg: string ) => console .log ( `Hello, ${ arg } !!` ); fun ( 'TypeScript' ); // "Hello, TypeScript!!" fun () // "Hello, undefined!!" let fun2: ( arg: string ) => void = ( arg: string ) => console .log ( `Hello, ${ arg } !!` ); fun2 (); // Expected 1 arguments, but got 0. fun は arg という引数が必要ですが、 Function 型で宣言しているためにTypeScriptは警告を出しません。 基本的には上の例で使用した (arg: type) => returnType という形式で アノテーション します。 Index Signitures キーの型、値の型を指定してプロパティの個数は指定しないようなオブジェクトも定義できます。 type T = { [ key: number ] : string } const t: T = { 1 : 'one' , 2 : 'two' , 3 : 'three' } ; // このコードはエラーにならないので注意 console .log ( t [ 0 ] .length ); // Cannot read property 'length' of undefined 特殊な型 any anyは何でもありの型です。どのような型でも受け付け、どのような型にも割り当てられます。 let any : any ; any = 123 ; any = { a: 123 , b: 'string' } ; any = null ; any = 123 as unknown ; const s: undefined = any ; any型は実際の値がどのような型か全くわからないため、TypeScriptのメリットを享受しづらくなってしまいます。 プロジェクトを JavaScript からTypeScriptに置き換える際に、とりあえずanyとして型をつけておくのは便利ですが、 できるなら使用は避けるべきです。 型が実行時までわからないような場合には、unknown型の使用をまずは検討しましょう。 unknown TypeScript 3.0から導入されました。 unknown型の変数はどのような値も代入可能な点でanyと同様ですが、変数を利用するときには その変数の値の型が実際は何であるかが判明するまで利用することができません。 let unknown : unknown ; unknown = 123 ; unknown = { a: 123 , b: 'string' } ; // 比較は可能 if ( !! unknown ) { console .log ( 'truthy' ); } unknown = 'Hello unknown' ; if (typeof unknown === 'string' ) { console .log ( unknown .substring ( 0 , 5 )); } 上の例では typeof 演算子 を使用し、変数 unknown の実際の型が何であるかをチェックしてから String.substring メソッドを使用しています。 型をチェックしなければ変数を使用できないという面で any 型の変数よりも安全です。 void return文で値を返さない関数の戻り値はvoid型として推論されます。 function f () {} type R = typeof f ; // () => void // undefinedはvoid型に代入可能 let r = f (); r = undefined ; never never型はとりうる値が一つもない型です。 never型の変数にはanyすら代入できません。 let never : never ; never = {} ; // Type '{}' is not assignable to type 'never'. never = 123 as any ; // Type 'any' is not assignable to type 'never'. とりうる値が一つもないため、never型とその他の型のUnion型においてnever型は無視されます。 type T = string | number | never ; // Tは string | number 型 使い所としては、実行したら2度と呼び出し元の関数に処理が戻らないような関数の戻り値があります。 以下はNodeの Process.exit 関数の型です。 NodeJS.Process.exit ( code?: number | undefined ) : never exitを呼び出した時点で指定された ステータスコード でプロセスを終了するため、呼び出し元に処理が戻ることはありません。 その他、後述するConditional Typesにおいても使用されています。 インターフェースと型 エイリアス インターフェース TypeScriptにはインターフェースという仕組みがあり、オブジェクトの構造を指定することができます。 interface User { name: string , id: number , registeredDate: Date } const user: User = { name: 'Guest' , id: 0 , registeredDate: new Date ( '1900-01-01' ) } Classに実装することもできます。 class UserClass implements User { constructor( public name: string , public id: number , public registeredDate: Date ) { } } 型 エイリアス もしくは他のインターフェースを継承できます。 type Animal = { name: string , age: number } interface Cat extends Animal { mew () : void } const tama: Cat = { name: 'tama' , age: 2 , mew () { console .log ( "mew" ) } } 2つの違い TypeScriptには型 エイリアス とインターフェースが存在し、共にオブジェクトの構造を定義することができます。 この2つは何が違うのでしょうか？ 宣言のマージ インターフェースは同名のインターフェースを重複して宣言できます。 その場合はインターフェースの定義をTypeScriptが自動的にマージします。 interface User { id: number } interface User { // 同一のプロパティは同じ型でなければならない // id: string, name: string , } const user: User = { id: 0 , name: "Guest" } ; 外部ライブラリの型を拡張したい場合インターフェースで宣言されていれば、 同名のインターフェースを再度宣言するだけで拡張が可能です。 対して、同名の型 エイリアス はエラーになります。 // Duplicate identifier 'User'. type User = { id: number } type User = { name: string } プリミティブ型とUnion型 インターフェースでは型 エイリアス で表現できる以下のような型を表現できません。 // プリミティブ型 type ID = number ; // Union型 type NumOrStr = number | string ; その他 インデックス シグネチャ を型のプロパティとして持つ際に違いがあるようです。 assignabiltity between interfaces and types · Issue #14736 · microsoft/TypeScript · GitHub ジェネリクス ジェネリクス はTypeScriptに限らず様々な言語で導入されている、型を抽象化するための仕組みです。 配列のそれぞれの要素に関数を適用する map 関数は ジェネリクス を使用して以下のように定義できます。 // <T>によって型変数Tを導入できる function map < T >( arr: T [] , f: ( element: T ) => T ) : T [] { const result = [] ; for ( const e of arr ) { result.push ( f ( e )) } return result ; } console .log ( map ( [ 1 , 2 , 3 ] , elm => elm * 2 )) ジェネリクス を導入できる場所 関数型 上のmap型のような書き方も可能ですが、アロー関数でももちろん ジェネリクス を使用できます。 const map = < T >( arr: T [] , f: ( e: T ) => T ) : T [] => { /* ... */ } 型 エイリアス type F < T , R > = ( arg: T ) => R ; const f: F < number , string > = arg => arg.toString (); インターフェース interface F < T , R > { ( arg: T ) : R ; } const f: F < number , string > = arg => arg.toString (); tsconfig. json tsconfig.json はTypeScript コンパイラ の挙動を指定するための設定ファイルです。 以下のコマンドを実行するとカレント ディレクト リ上にデフォルトの tsconfig.json が作成されます。 $ tsc -- init tsconfigで設定可能なオプションの一覧は以下で確認できます。 TypeScript: TSConfig Reference - Docs on every TSConfig option 型を操作する 型のキーワード ここではTypeScriptの型にまつわるキーワードについて紹介します。 typeof typeof val でvalの値の型を取得できます。 const n = 123 ; const s = 'str' ; const o = { n , s } ; const u = undefined ; // T1 = 123 type T1 = typeof n ; // T2 = "str" type T2 = typeof s ; // T3 = {s: string, n: number} type T3 = typeof o ; // T4 = undefined type T4 = typeof u ; keyof keyof は keyof Type とすることで、 Type が持つプロパティをUnion型として得ることができる 演算子 です。 type User = { id: number ; name: string ; age: number ; } // type UserKey = "id" | "name" | "age" type UserKey = keyof User ; Lookup Types Lookup Typesは特別なキーワードがあるわけではありませんが、 keyof と組み合わせて使われることが 多いためここで紹介します。 ある型TのプロパティKの型を T[K] として参照できる機能です。 type User = { id: number ; name: string ; age: number ; } // type UserIdType = number type UserIdType = User [ 'id' ] ; in for..in 構文でも使用されるinですが、TypeScriptでは Mapped Types と呼ばれる構文のためのキーワードとしても用いられます。 // type U = {A: any, B: any, C: any} type U = { [ K in "A" | "B" | "C" ] : any } inの後ろにある要素(Union型の場合には1つずつ取り出すイメージ)をキーとしたプロパティを作成します。 extends classやinterface,typeなどを継承する際に用いられる extends キーワードですが、 Conditional Types と呼ばれる機能でも使用されています。 // T1 = true type T1 = number extends number | string ? true : false ; // T2 = false type T2 = number extends null ? true : false ; T extends U ? X : Y となっている箇所が Conditional Types です。TypeScript 2.8から導入されました。 TがUに割り当て可能であればX、割り当て不可であればYを返します。 上の例では number 型は number | string 型にもちろん割り当てられますので、T1は true 型になります。 しかし null 型には割り当てられませんので、T2は false 型になります。 infer inferは推論した型を型変数として使用するための仕組みです。Conditional Types内で使用できます。 例としてこの後紹介するUtility Typesから ReturnType という型を見てみます。 type ReturnType < T extends ( ...args: any ) => any > = T extends ( ...args: any ) => infer R ? R : any ; ジェネリクス T extends (...args: any) => any の部分はTに割り当てられる型を関数型に制限しています。 右辺の T extends (...args: any) => infer R はTが関数型かどうかをextendsで判定するとともに、 関数の戻り値の型を R という新たな型変数にバインドしています。 当然Tが関数型でない場合にはRに値がバインドされないので、Rが使用できるのはTが関数型の場合のみです。 その他の場合にはany型になります。 Utility Types 最後にTypeScript組み込みの、いくつかの便利な型について紹介します。 上のkeyofやextendsなどの使用例が盛り沢山です。 Partial / Required / Readonly この3つは似たような定義なのでまとめて紹介します。 type Partial < T > = { [ P in keyof T ] ?: T [ P ] ; } ; type Required < T > = { [ P in keyof T ] -?: T [ P ] ; } ; type Readonly < T > = { readonly [ P in keyof T ] : T [ P ] ; } ; Partialはオブジェクトのプロパティを省略可能( key?: value の構文)にします。 Mapped Type を用いて T のプロパティを列挙して、プロパティに ? をつけることで全てのプロパティを省略可能にしています。 T[P] の箇所は Lookup Types で、各プロパティの値の型を参照しています。 Requiredは全てのプロパティを省略不可に、Readonlyは変更不可にする型です。 補足: readonlyについて readonly はプロパティを変更不可にするキーワードです。 type U = { a: string , b: number } type T = Readonly < U > const t: T = { a: "str" , b: 123 , } t.a = "modified" ; // Attempt to assign to const or readonly variable readonly も ? と同様に -readonly とすることで、各プロパティから readonly を取り除くことができます。 Pick<T, K> Pickはオブジェクトの型から指定したプロパティのみを持つオブジェクトを作る型です。 type Pick < T , K extends keyof T > = { [ P in K ] : T [ P ] ; } // T = { a: string, b: number } type T = Pick < { a: string , b: number , c: boolean } , "a" | "b" > K extends keyof T の部分は、Kが指定できるプロパティをTが持つプロパティのみに制限しています。 Record<K, T> Recordは2つの型K, Tを受け取り、Kの各プロパティに対してTを値としたオブジェクトの型を作る型です。 type Record < K extends keyof any , T > = { [ P in K ] : T ; } ; keyof any は確認してみるとわかりますが、 string | number | symbol というUnion型です。 type K = string | number | symbol つまり K extends keyof any はキーとする型Tを、キーとして指定できる型に制約しているということになります。 Exclude<T, ExcludedUnion> Excludeは型TからExcludedUnionの各要素を除いたものを作る型です。 type Exclude < T , U > = T extends U ? never : T ; // type E = 123 | "str" type E = Exclude < 123 | "str" | (() => any ), Function > 123 | "str" | (() => any) というUnion型から、Function型に割り当て可能な型のみを取り除いています。 never 型を返却する理由は、先の方でも述べましたが、以下のようにUnion型における never はないものとして扱えるためです。 // U1 = string | number type U1 = string | number | never ; // U2 = void type U2 = null | void | never ; Union Distribution 上の例のように、 T extends U のT が型変数かつUnion型の場合、TypeScriptは Union Distribution という特殊な挙動になります。 type Exclude < T , U > = T extends U ? never : T ; // type E = 123 | "str" type E1 = Exclude < 123 | "str" | (() => any ), Function > // E1はこんな感じに分配されるイメージ type E2 = 123 extends Function ? never : 123 | "str" extends Function ? never : "str" | (() => any ) extends Function ? never : (() => any ); 参考: TypeScript: Documentation - Advanced Types#Distributive conditional types Extract<T, Union> Excludeの逆です。 type Extract < T , Union > = T extends Union ? T : never ; Omit<Type, Keys> TypeScript 3.5から導入されました。 Pickとは対照的に、プロパティをKeysとしてUnion型で指定しTypeから取り除きます。 type Omit < T , K extends keyof any > = Pick < T , Exclude <keyof T , K >>; // T = { c: boolean } type T = Omit < { a: string , b: number , c: boolean } , "a" | "b" > 既出のUtility TypesであるPickとExcludeを使用しています。 ExcludeでTのプロパティからKを除き、残ったプロパティのみの型をPickで作成しています。 NonNullable 型Tを受け取り、名前通りnullはもちろん、undefinedもTから取り除きます。 type NonNullable < T > = T extends null | undefined ? never : T ; // U = string | (() => any) type U = NonNullable < string | null | undefined | (() => any )> Parameters 関数型を受け取り、引数の型をタプル型として返却します。 type Parameters < T extends ( ...args: any ) => any > = T extends ( ...args: infer Arg ) => any ? Arg : never ; // P1 = [a: number, b: string] type P1 = Parameters <( a: number , b: string ) => void > // P2 = type P2 = [a: { b: number, c: boolean }] type P2 = Parameters <( a: { b: number , c: boolean } ) => string > // P3 = unknown[] type P3 = Parameters < any > infer を使用して引数の型を推論し、結果をArgという新たな型変数にバインドしています。 ConstructorParameters Parameterのコンスト ラク タ版です。 type ConstructorParameters < T extends new ( ...args: any ) => any > = T extends new ( ...args: infer Arg ) => any ? Arg : never ; class A { constructor( private id: number , private name: string , ) {} } // U = [id: number, name: string] type U = ConstructorParameters <typeof A > T extends new (...args: any) => any でTの取りうる型をコンスト ラク タに制限しています。 ReturnType Parametersの戻り値版です。 type ReturnType < T extends ( ...args: any ) => any > = T extends ( ...args: any ) => infer R ? R : any ; // U1 = void type U1 = ReturnType <() => void > function f () { return Math .random () < 0.5 ? "OK" : "NG" } // U2 = "OK" | "NG" type U2 = ReturnType <typeof f > infer で今度は戻り値の型を推論しています。 InstanceType constructorの戻り値の型を取得します。 ReturnTypeのコンスト ラク タ版です。 type InstanceType < T extends new ( ...args: any ) => any > = T extends new ( ...args: any ) => infer Class ? Class : any ; class C { constructor( private name: string = "Guest" , private id: number = 0 ) {} } // U1 = C type U1 = InstanceType <typeof C > // U2 = any type U2 = InstanceType < any > ThisParameterType Tが関数型で this をパラメータとして持つ場合にその型を返却します。 type ThisParameterType < T > = T extends ( this : infer This , ...args: any ) => any ? This : unknown ; function f1 ( this : number ) {} function f2 ( arg: number ) {} // F1 = number type F1 = ThisParameterType <typeof f1 > // F2 = unknown type F2 = ThisParameterType <typeof f2 > this パラメータは必ず引数の先頭である必要があるため、それを利用してthisの型を推論しています。 OmitThisParameter 関数型Tを受け取り、Tが this パラメータを含んでいればそれを除いた関数型を返します。 type OmitThisParameter < T > = unknown extends ThisParameterType < T > ? T : T extends ( ...args: infer A ) => infer R ? ( ...args: A ) => R : T ; // F1 = (a: string) => any type F1 = OmitThisParameter <( this : number , a: string ) => any > // F2 = 123 type F2 = OmitThisParameter < 123 > unknown extends ThisParameterType<T> でTがthisパラメータを含むかどうか確認しています。 thisは可変長引数のパラメータに含まれないようなので、関数型であれば可変長引数の型を推論して返します。 ThisType この型を利用するためには --noImplicitThis を有効にする必要があります。 公式の例を引用して説明します。 TypeScript: Documentation - Utility Types#ThisType type ObjectDescriptor < D , M > = { data?: D ; methods?: M & ThisType < D & M >; // Type of 'this' in methods is D & M } ; function makeObject < D , M >( desc: ObjectDescriptor < D , M >) : D & M { let data: object = desc.data || {} ; let methods: object = desc.methods || {} ; return { ...data , ...methods } as D & M ; } let obj = makeObject ( { data: { x: 0 , y: 0 } , methods: { moveBy ( dx: number , dy: number ) { this .x += dx ; // Strongly typed this this .y += dy ; // Strongly typed this } , } , } ); obj.x = 10 ; obj.y = 20 ; obj.moveBy ( 5 , 5 ); ObjectDescriptor 内の methods?: M & ThisType<D & M> は、methods内で使用される this の型をobjの型である D & M 型に アノテーション します。 D & M 型はdataの型とmethodsの型の交差型なので、今回は以下のような型になります。 { x: number ; y: number ; moveBy ( dx: number , dy: number ) : void ; } makeObjectの引数が ObjectDescriptor 型なので、method内の this が上のような型に推論されるため this.x の形式でxにアクセスできる、ということだと思われます。 ちなみにThisTypeで アノテーション しない場合には関数内のthisは以下の型になりますので、TypeScriptはエラーを出します。 moveBy ( dx: number , dy: number ) { // Property 'x' does not exist on type '{ moveBy(dx: number, dy: number): void; }' this .x += dx ; // Property 'y' does not exist on type '{ moveBy(dx: number, dy: number): void; }' this .y += dy ; } Uppercase / Lowercase ここから紹介する4つの型はTypeScript 4.1から導入された新しめの型です。せっかくですので紹介します。 いずれも文字列型を操作できます。 // U1 = "FOO" type U1 = Uppercase < "foo" >; // U2 = "bar" type U2 = Lowercase < "BAR" > Capitalize / Uncapitalize // C1 = "Foo" type C1 = Capitalize < "foo" >; // C2 = "bar" type C2 = Uncapitalize < "Bar" > これらは単体で使うというよりかは、同じく4.1から導入された仕組みである Template literal types の補助として使われるのではと思います。 Template literal types の説明は流石に入門記事の範囲外のため割愛します。詳しく知りたい方はこちらをご覧ください。 TypeScript: Documentation - Template Literal Types まとめ 入門記事ということで長めになってしまいましたが、これをきっかけに少しでもTypeScriptに興味を持っていただけたなら嬉しい限りです。 紹介していないTypeScriptの機能もまだまだあるようですので、また機会があれば書かせていただきたいと思います。 参考 O'Reilly Japan - プログラミングTypeScript 実践TypeScript | マイナビブックス TypeScript: Handbook - The TypeScript Handbook TypeScript: TSConfig Reference - Docs on every TSConfig option TypeScript: Documentation - Utility Types TypeScript Ninja TypeScriptの型入門 - Qiita TypeScriptの型初級 - Qiita さようなら、TypeScript enum | Kabuku Developers Blog TypeScriptのenumを使わないほうがいい理由を、Tree-shakingの観点で紹介します - LINE ENGINEERING TypeScriptのInterfaceとTypeの比較 - Qiita TypeScriptにヤバい機能が入りそうなのでひとしきり遊んでみる｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社 TypeScript: Interfaces vs Types - Stack Overflow assignabiltity between interfaces and types · Issue #14736 · microsoft/TypeScript · GitHub エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは、Engawaです。 ここ最近業務でReactについて触れる機会があり、Reactの学習を行ったので、 環境構築からreact-router-domを使用した簡単なSPAの作成方法についてザックリ紹介していこうと思います。 はじめに Reactとは 環境構築 起動 SPAの作成 react-router-domのインストール サンプルコード 実行 おわりに 参考資料 Reactとは React は FaceBook 社が開発した、UIを作るための JavaScript 用ライブラリです。 アプリに特化したReactNativeもあります。 そちらについては こちら で紹介していますのでご覧いただけれと思います。 環境構築 私が学習をした際の環境は以下になります。 node： v10.19.0 OS ： macOS Catalina 使用したエディタ： VSCode こちらで記載する環境構築方法は macOS のみになります。 windowsでnodeをインストールする時はこちらを参考にしてください。 次の５つのコマンドを順番にターミナルで実行してください。 Homebrewのインストール (nodeをインストールする際に使用します) /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" nodeのインストール brew install node nのインストール npm -g i n nodeのバージョン確認 node -v 上記コマンドを実行してバージョンが表示されていればnodeのインストールは完了です。 $ node -v vバージョン 続いてファイル等の作成を行います。 が、1から設定ファイル等の作成は面倒なのでcreate-react-appを使用します。 create-reeact-appは環境構築ツールで一度インストールしてしまえば、コマンド1つでReactに必要な環境を構築することができます。 まずは下記コマンドでcreate-react-appをインストールします。 npm install create-react-app インストールが完了したらプロジェクトを作成したいフォルダ上で、下記コマンドでcreate-react-appを実行してReactプロジェクトを作成します。 create-react-app 作成したいプロジェクト名 上記コマンド実行後、プロジェクトフォルダの中に以下のフォルダおよびファイルが作成されていたら作成完了です。 プロジェクト名 ├── node_modules/ ├── package. json ├── public/ ├── README.md ├── src/ └── yarn.lock 起動 作成したプロジェクトフォルダに移動して、 cd プロジェクト名 下記コマンドで起動します。 npm install ↓ npm start 実行後下記画面が表示されれば問題なく起動できています。 SPAの作成 react-router-domのインストール Reactで画面遷移させるため、react-router-domを使用します。 プロジェクト名のフォルダ直下で下記コマンドを実行してreact-router-domをインストールしてください。 npm install react-router-dom package. json にreact-router-domのライブラリが追加されていたらインストール完了です。 サンプルコード src/index.js <BrowserRouter> でrouterの導入を行います。 react-router関連の処理はすべて <BrowserRouter> 内で使用しなくてはいけないかつ、1プロジェクトにつき1つしか使用できないため、 <BrowserRouter> は上位層で使用することになります。 import React from 'react' ; import ReactDOM from 'react-dom' ; import { BrowserRouter } from 'react-router-dom' ; import './index.css' ; import App from './App' ; import reportWebVitals from './reportWebVitals' ; ReactDOM.render( <BrowserRouter> <App /> </BrowserRouter>, document .getElementById( 'root' ) ); reportWebVitals(); src/App.js <Route> にはルーティング先のURLと コンポーネント の切り替えを行います。 今回はroutes.jsにパスを記載して、routesからそれぞれの値を呼び出し、 <Switch> でURLが一致した時に コンポーネント を表示させます。 import React from 'react' ; import { Route, Switch, withRouter } from 'react-router-dom' ; import routes from './routes' ; const App = () => { return ( <Switch> { routes.map((route, idx) => ( <Route path= { route.path } exact= { route.exact } component= { route.component } key= { idx } /> )) } </Switch> ); } ; export default withRouter(App); src/routes.js(新規で作成) import One from './page/one' ; import Two from './page/two' ; const routes = [ { path: '/' , component: One, exact : true } , { path: '/two' , component: Two, } , ] ; export default routes; src/page/one.js(新規で作成) 画面遷移をするために <link> を使用しています。 やっていることはaタグと同じで、to属性でリンク先のURLを指定しています。 import React from 'react' ; import { Link } from 'react-router-dom' ; import Two from './two' ; class One extends React.Component { render() { return ( <div> test_one<br/> <Link to= '/two' >twoへ</Link> </div> ) } } export default One; src/page/two.js(新規で作成) import React from 'react' ; import { Link } from 'react-router-dom' ; import One from './one' ; class Two extends React.Component { render() { return ( <div> test_two<br/> <Link to= '/' >oneへ</Link> </div> ) } } export default Two; 実行 実行するとこんな感じで画面遷移することができます。 おわりに 今回はReactの触りについて学習を行ったので、環境構築から簡単な画面遷移のやり方について紹介させていただきました。 何かしら学習を行う際は大体環境構築あたりで躓いて投げ出すことが多いので、今回みたいにcreate-reeact-appを実行するだけで簡単に環境構築ができるのは大変助かりました。 参考資料 https://qiita.com/ShinKano/items/541050c36e08e78a5176 https://dezanari.com/react-react-router/ https://code-ship-blog.wemotion.co.jp/technology/react-js%E3%81%A7%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%92%E5%AE%9F%E8%A3%85%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AEreact-router%E3%81%AE%E7%B4%B9%E4%BB%8B/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 初めましてこんにちは！matsutairaです！ 今回は、普段何気なく利用している DNS サーバーというものにフォーカスし、実際にWebサーバー・ DNS サーバーの構築を通して DNS サーバーとは何なのかをざっくり学べる内容となっております。「 DNS サーバーってどんなもの？」「自分で DNS サーバーを構築してみたい！」という方々の力になれればと思います。 今回は初めて触る方向けの内容になっていますので、「 DNS サーバーの構築方法だけ知りたい！」という方は目次からジャンプしていただければと思います。 手順の大まかな流れとしては、「 ドメイン 取得」 → 「各種サーバー構築」 → 「動作確認」です。 ドメイン の取得は通常それなりのコストがかかりますが、お名前ドットコムであれば初回1年間は1円で利用することができる「.work」 ドメイン があるため、最小限のコストに抑えることができます。また、 ドメイン の取得は個人・法人問わず、ホームページやメールアドレス、個人ブログで利用することができ、世界に一つだけのオリジナルであるという証明にもなります。 各種サーバーの構築は今回 AWS を利用して作成していきます。 AWS を利用するメリットとしては、初回1年間のみ無料で試すことができ、今回利用する範囲内であれば1年間無料で利用できます。（BDやRoute53を利用する場合は別途料金がかかります）また、 AWS 上でサーバーを一括管理できることや グローバルIPアドレス の取得が容易であること、 GUI での操作が可能であることもメリットになります。 通常お金のかかる ドメイン の取得と AWS の利用ですが、今回は合計1円のみで DNS サーバーについて学ぶことができるため、初めての方でも取り組みやすい内容になっているかと思います。 目次 はじめに DNSサーバーとは 環境準備 ドメイン取得 AWS登録 インスタンス作成 ネットワーク設定 Webサーバー構築 Apacheのインストール HTMLの作成と配置 セキュリティグループの変更(Webサーバー) DNSサーバー構築 プライマリDNSサーバーの構築 セカンダリDNSサーバーの構築 セキュリティグループの変更(DNSサーバー) DNSサーバー登録 動作確認 おわりに DNS サーバーとは DNS （ D omain N ame S ystem）とは、 ドメイン 名や完全修飾 ドメイン 名（ FQDN ）に対応する IPアドレス の情報を管理・運用するシステムです。 簡単に言えば、例えば ドメイン 名「 google .com」を「172.217.175.14」という IPアドレス に変換してくれるシステムです。 もう少し詳しく言うと、インターネット上でコンピュータ同士が通信を行うためには IPアドレス と呼ばれるインターネット上の住所のようなものを使って通信します。 しかし私たち人間が IPアドレス 「172.217.175.14」を見ただけでは、それが「 google .com」のサーバーだとはわかりません。 同様にコンピュータが ドメイン 名「 google .com」を見ても、コンピュータは IPアドレス でしか読み取ることができないため、人間とコンピュータにわかるようにするための相互変換が必要になり、 DNS というシステムが使用されています。 DNS サーバーはその機能を実装しているサーバーということになります。 例えば、検索バーに「 google .com」と入力します。先ほども説明したようにコンピュータには「 google .com」という文字列からサーバーの住所はわかりませんが、 DNS サーバーに「 google .comの IPアドレス （住所）を教えて下さい」と問い合わせを行うことで DNS サーバーは「 google .comの IPアドレス （住所）は172.217.175.14ですよ」とコンピュータに教えてくれます。これによりコンピュータは受け取った IPアドレス にアクセスすることで google .comのページが表示されるということになります。 簡単に DNS サーバーの動きを説明しましたが、 DNS サーバーは世界中にある無数の DNS サーバーが階層構造になって存在しています。そのため、一口に「 google .comの IPアドレス は何？」と言っても、「ルート DNS サーバー」→「.comを管理している DNS サーバー」→「 google .comのIPを管理している DNS サーバー」を経由して IPアドレス をコンピュータに教えてくれます。この動作は世界中にある無数の DNS サーバーが連携し一瞬で完了するため、私たちは普段意識することはありません。また、 DNS サーバーにはキャッシュ DNS サーバーと権威 DNS サーバーというものが存在しています。キャッシュ DNS サーバーは、自身で ドメイン 名と IPアドレス の情報を管理しているわけではなく、他の DNS サーバーに問い合わせを行ったり、自身で保持しているキャッシュから IPアドレス などを返したりする DNS サーバーです。逆に権威 DNS サーバーは、自身で ドメイン 名と IPアドレス の情報を管理している DNS サーバーになります。今回は、自身で ドメイン 名と IPアドレス の情報を管理するので、権威 DNS サーバーを構築します。 今回の名前解決の流れは以下のようになります。 クライアントはブラウザで「 http://web-test.dns-server-test.work 」と入力すると、Webサーバーの IPアドレス を得るためにキャッシュ DNS サーバーに問い合わせを行います。 キャッシュ DNS サーバーは、「 http://web-test.dns-server-test.work 」の IPアドレス を保持している場合はその IPアドレス をクライアントに返し、保持していない場合はルート DNS サーバーに問い合わせを行います。 ルート DNS サーバーには、「 http://web-test.dns-server-test.work 」の IPアドレス の情報はありませんが、「.work」を管理している DNS サーバーの IPアドレス を保持しているため、その IPアドレス を返します。 3で受け取った DNS サーバーの IPアドレス を元に、「.work」を管理している DNS サーバーに「 http://web-test.dns-server-test.work 」の IPアドレス を問い合わせます。 「.work」を管理している DNS サーバーには、「 http://web-test.dns-server-test.work 」の IPアドレス の情報はありませんが、「 dns -server-test.work」を管理している DNS サーバーの IPアドレス を保持しているため、その IPアドレス を返します。 5で受け取った DNS サーバーの IPアドレス を元に、「 dns -server-test.work」を管理している DNS サーバーに「 http://web-test.dns-server-test.work 」の IPアドレス を問い合わせます。 「 dns -server-test.work」を管理している DNS サーバーには、「 http://web-test.dns-server-test.work 」の IPアドレス 情報が記載されているため、その IPアドレス を返します。 受け取った「 http://web-test.dns-server-test.work 」の IPアドレス をクライアントに返します。 クライアントは「 http://web-test.dns-server-test.work 」の IPアドレス を元にWebサーバーにアクセスします。 WebサーバーのHTMLからブラウザ上にWebページが表示されます。 DNS サーバーには、 ドメイン 名と IPアドレス を紐づける情報が無数に蓄積されています。しかし、 DNS サーバーがダウンしてしまった場合、 ドメイン 名と IPアドレス の紐づけができなくなるため、 Webサービス にアクセスできなくなったり、メールを送信することができなくなってしまいます。そのため、 DNS サーバーは障害がいつ発生しても問題ないように2つ以上のサーバー群で構成されています。今回はプライマリ DNS サーバーと セカンダリ DNS サーバーの2つを構築し、片方の DNS サーバーで障害が発生しても問題ないことも確かめたいと思います。 目次へ 環境準備 実際に DNS サーバーを構築するための準備を行っていきます。 ※今回は AWS 上で作成したWebサーバーと DNS サーバーに SSH 接続するため、RLoginという SSH クライアントをインストールしておきます。 ※すでにターミナルソフトがインストールされている方はそちらを利用してください。 http://nanno.dip.jp/softlib/man/rlogin/#INSTALL nanno.dip.jp ドメイン 取得 まず、 ドメイン の取得です。今回は初回1年のみ1円/年で取得できる「.work」 ドメイン を取得します。 ※今回は dns -server-test.work ドメイン を取得しました（取得する場合は） www.onamae.com ※お名前ドットコムは1年後に ドメイン が自動更新される設定になっているため、自動更新を解除しておきましょう。 ※お名前ドットコムからは頻繁にメールが届くため、メールの配信設定を変更することをお勧めします。 AWS 登録 次に AWS （ Amazon Web Service）を利用するためアカウント登録を行います。 aws.amazon.com インスタンス 作成 AWS が利用可能になったら次は インスタンス を作成していきます。 インスタンス とは、 AWS クラウド 上にあるOSを載せた仮想サーバーのことです。 インスタンス を作成することでサーバーの環境構築を行うことができます。 以下のリンクを参考に インスタンス を作成します。 aws.amazon.com インスタンス の仕様は以下のように設定します。 AMI( Amazon マシンイメージ)：CentOS8 minimal インスタンス タイプ　　　　：t2.micro セキュリティグループ　　　：Webサーバー・・・ SSH (マイIP)、HTTP(80番ポート) 　　　　　　　　　　　　　： DNS サーバー・・・ SSH (マイIP)、 DNS ( UDP )、 DNS ( TCP ) Nameタグ　　　　　　　　 ：Webサーバー・・・web-test 　　　　　　　　　　　　　：プライマリ DNS サーバー・・・dns1-test 　　　　　　　　　　　　　： セカンダリ DNS サーバー・・・dns2-test Webサーバー・プライマリ DNS サーバー・ セカンダリ DNS サーバーの3つ分、 インスタンス を作成します。 ネットワーク設定 次にネットワークの設定を行っていきます。 AWS ではEIP（Elastic IP）というものが設定でき、今回作成したサーバーに固定の IPアドレス を付けることができます。 以下の リンクを参考にEIPを設定します。 docs.aws.amazon.com 今回使用するWebサーバー・プライマリ DNS サーバー・ セカンダリ DNS サーバーの3つにそれぞれ割り当てます。 EIPが重複せずに設定されていれば完了です。 目次へ Webサーバー構築 DNS サーバーの構築に入る前に、Webサーバーを作成します。 初めにWebサーバーに SSH 接続します。 今回はログインユーザ名を「 centos 」とする必要があるため注意してください。（rootユーザではログインできません） また、 インスタンス 作成時に作成したキーペアを登録します。（登録しない場合 SSH できません） SSH 接続後は、rootに切り替えてコマンドを実行していきます。 （デフォルトではrootユーザでログインできないため） ※以降サーバー内でコマンドを実行するときは必ずrootユーザに変更してから行う # sudo su - SSH 接続後は、 ミドルウェア アップデートをして 脆弱性 の排除を行います。 # dnf check-update # dnf upgrade ミドルウェア アップデートが完了したら再度確認を行い、最新の状態であることを確認します。 アップデート対象が表示されなければ完了です。 # dnf check-update Apache のインストール 次に、 Apache をインストールします。 # dnf install httpd インストールが完了したら、 Apache のバージョンを確認しておきます。 # httpd -v Server version: Apache/2.4.37 (centos) Server built: Nov 4 2020 03:20:37 Apache を 自動起動 する設定に変更しておきます。 enabledになっていれば 自動起動 される設定になったということになります。 # systemctl enable httpd.service Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service. # systemctl list-unit-files | grep httpd.service httpd.service enabled Apache を起動してステータスを確認します。 「Active: active (running)」となっていれば起動状態です。 # systemctl start httpd.service # systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) ～省略～ 無事 Apache が起動しましたので、次はHTMLの作成と配置です。 HTMLの作成と配置 クライアントからのアクセスでファイル名を指定しなかった場合（ http://example.com/index.html ← この最後のファイルを指定しない場合）、/etc/ httpd /conf/ httpd .confファイル内のDirectoryIndexディレクティブからindex.htmlがデフォルトで表示されるようになっています。 ～省略～ <IfModule dir_module > DirectoryIndex index.html </IfModule> ～省略～ このようにデフォルトではindex.htmlが指定されており、 http://www.dns-server-test/ にアクセスされると、index.htmlが存在すればそのHTMLが、存在しなければ Apache のテストページが表示されます。 そのため、今回は編集する箇所を少なくしたいという意味も込めて、index.htmlファイルを作成していきます。 まず、HTMLファイルの配置場所ですが、以下のコマンドを使用することで確認することができます。 # grep "^DocumentRoot" /etc/httpd/conf/httpd.conf DocumentRoot "/var/www/html" これによりHTMLファイルは「/var/www/html」の下に配置すればよいということがわかります。 次に、HTMLの作成です。以下のコマンドでHTMLを作成します。 # vi /var/www/html/index.html 簡易的ですが、記述するHTMLを記載します。 <!DOCTYPE html> < html lang = "ja" > < head > < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1" > < meta name = "description" content = "" > < meta http-equiv = "X-UA-Compatible" content = "IE=edge" > < title > DNS TEST </ title > </ head > < body > < h1 > Successful Access! </ h1 > </ body > </ html > HTMLの作成と配置が完了しました。 セキュリティグループの変更(Webサーバー) これにてWebサーバーの構築は完了しましたので、構築できているか確認するためにアクセスします。 Webサーバーにアクセスするためには、セキュリティグループを変更して80番ポートを解放する必要があります。 以下のように設定を追加します。 タイプ：HTTP ソース：カスタム、0.0.0.0/0 一度動作確認のため、 IPアドレス でアクセスしてみます。 成功しました。 目次へ DNS サーバー構築 前置きが長くなりましたが、いよいよ本題のプライマリ DNS サーバーと セカンダリ DNS サーバーの構築に入ります。 プライマリ DNS サーバーの構築 それでは実際に構築していきます。 まず、 AWS 上で作成したサーバーを DNS サーバーとして動作させるための設定ファイル等が入った ミドルウェア をインストールする必要があります。 今回インストールするものは、「bind」「bind- chroot 」「bind-utils」の3種類です。 bind ・・・・・・BIND9本体で各種設定ファイル等が入っているもの bind- chroot ・・・ chroot 化させるためのもの bind-utils・・・・nslookupやdigコマンドを使用するためのもの（named-checkzoneコマンドも使用できるようにするため） Step1～9で DNS サーバーの構築を行います。 Step1 Webサーバー構築時と同様にプライマリ DNS サーバー（dns1）に SSH 接続します。 ※接続方法はWebサーバーで解説していますのでそちらを参照 ※「# sudo su -」でrootユーザに変更してから実施 Step2 Webサーバー構築時と同様に ミドルウェア アップデートを行います。 # dnf check-update # dnf upgrade Step3 以下のコマンドを入力し、BIND関連の ミドルウェア をインストールします。 # dnf install bind bind-chroot bind-utils Step4 BINDのバージョンがBIND9系であることを確認します。 # named -v BIND 9.11.20-RedHat-9.11.20-5.el8 (Extended Support Version) <id:f3d1d66> Step5 namedではなくnamed- chroot というサービスを起動して利用するため、namedのステータスと設定を確認します。 ※ chroot については後述します。 # systemctl list-unit-files | grep ^named.service named.service disabled # systemctl status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: inactive (dead) namedが 自動起動 しない設定であることと停止していれば問題ありません。 自動起動 する設定や起動している場合には、以下のコマンドで停止させましょう。 # systemctl disable named.service # systemctl stop named.service Step6 named- chroot を 自動起動 する設定にして起動させます。先ほど説明を後回しにした chroot ですが、ルート ディレクト リを変更するというもので、namedを chroot 化させると/var/named/ chroot 以下に関連するファイルがマウントされ、 chroot より上位の ディレクト リにはアクセスをできなくなります。これによりアクセス可能な範囲が制限されセキュリティ対策となります。 # systemctl enable named-chroot.service Created symlink /etc/systemd/system/multi-user.target.wants/named-chroot.service → /usr/lib/systemd/system/named-chroot.service. # systemctl start named-chroot.service # systemctl status named-chroot.service ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: active (running) ～省略～ Step7 named.confファイルを編集して DNS サーバーの基本設定を行います。 ※ chroot 化しているため、/etc/named.confではなく/var/named/ chroot /etc/named.confを編集することに注意 # vi /var/named/chroot/etc/named.conf デフォルトのnamed.confファイルは以下になります。 // // named.conf // // // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a localhost DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; secroots-file "/var/named/data/named.secroots"; recursing-file "/var/named/data/named.recursing"; allow-query { localhost; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion yes; dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config" ; }; logging { channel default_debug { file "data/named.run" ; severity dynamic; }; }; zone " . " IN { type hint ; file "named.ca" ; }; include "/etc/named.rfc1912.zones" ; include "/etc/named.root.key" ; 今回編集するのは、options ステートメント とzone ステートメント です。以下のように変更します。 options { // 1. BINDのバージョンを隠蔽 version "unknown" ; // 2. ホスト名 hostname "dns1.dns-server-test.work."; // 3. 53番ポートでの受付をすべて許可 listen-on port 53 { any; }; // 4. ipv6を使用しない listen-on-v6 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; secroots-file "/var/named/data/named.secroots"; recursing-file "/var/named/data/named.recursing"; // 5. すべてのクエリーを受け付ける allow-query { any; }; // 6. リゾルバとして動作しないように設定 recursion no; allow-recursion { none; }; allow-query-cache { none; }; dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config" ; }; logging { channel default_debug { file "data/named.run" ; severity dynamic; }; }; // 7. ルートDNSサーバーのゾーン情報は今回必要ないのでコメントアウト /* zone "." IN { type hint; file "named.ca"; }; */ // 8. ゾーンファイルdns-server-test.workの設定 zone " dns-server-test.work " IN { // プライマリDNSサーバーであることを指定 type master ; // ゾーンファイルのファイル名を指定 file "dns-server-test.work" ; // ゾーンファイルの変更を通知する notify yes ; // ゾーンファイルの変更を通知する先を指定（セカンダリDNSサーバーのプライベートIPアドレスを指定） also-notify { xxx.xxx.xxx.xxx; }; // ゾーン転送先を指定（セカンダリDNSサーバーのプライベートIPアドレスを指定） allow-transfer { xxx.xxx.xxx.xxx; }; }; include "/etc/named.rfc1912.zones" ; include "/etc/named.root.key" ; BINDのバージョンを隠蔽 nslookupコマンド等でBINDのバージョンを表示されないようにします。バージョンが知られてしまうと、そのバージョンでの 脆弱性 を突いて攻撃される可能性があるためです。今回は入力をunknownしているため、unknownと表示されることになります。 ホスト名 DNS サーバーのホスト名を記述します。プライマリ DNS サーバーのnamed.confファイルを編集しているので、「dns1-test. dns -server-test.work」となります。 53番ポートでの受付をすべて許可 DNS サーバーは53番ポートを使用するため許可する設定にします。 IPv6 を使用しない 今回は IPv4 のみ使用するため使用しないことを明示的に記述しています。（記述しない場合も使用しない設定になります） すべてのクエリーを受け付ける どこからでも名前解決の問い合わせを受け付ける設定にします。 リ ゾル バとして動作しないように設定 recursionは 再帰 問い合わせを行う設定です。今回は権威 DNS サーバーを構築するため、設定をnoにします。 ルート DNS サーバーのゾーン情報は今回必要ないので コメントアウト キャッシュ DNS サーバーとして動作させないため コメントアウト します。 ゾーンファイル dns -server-test.workの設定 DNS サーバーがプライマリなのか セカンダリ なのかの指定や、ゾーンファイルの名前を指定、ゾーン転送先を指定等をします。 編集が完了したら記述が正しくできているかチェックを行います。 ※正しく記述できている場合には何も表示されません # named-checkconf /var/named/chroot/etc/named.conf Step8 named.confファイルの編集が終わったら次はゾーンファイルの作成です。簡単に言うとゾーンファイルは ドメイン 名と IPアドレス の対応表を記載していくファイルになります。 /var/named/ chroot /var/named以下に作成します。 # vi /var/named/chroot/var/named/dns-server-test.work ゾーンファイルの記述は以下のようになります。 $TTL 30 0 @ IN SOA dns1-test.dns-server-test.work. xxxxxxxxxx.gmail.com. ( 2020122000 ; Serial（シリアル ） 3600 ; Refresh（転送間隔 ） 900 ; Retry（再試行猶予時間 ） 21600 ; Expire（有効時間 ） 60 ; Minimum TTL（ネガティブキャッシュTTL ） ) ; DNSサーバ ー IN NS dns1-test.dns-server-test.work . IN NS dns2-test.dns-server-test.work . dns1-test IN A xxx.xxx.xxx.xx x dns2-test IN A xxx.xxx.xxx.xx x ; Webサーバ ー web-test IN A xxx.xxx.xxx.xx x ゾーンファイル内では「 ; 」はコメントとして扱われます。以下に各記述の内容を記載します。 TTL DNS サーバーがレコード情報をキャッシュする時間で、この場合最大5分間ローカルにキャッシュを保持します。 ＠ IN SOA ～ SOA レコートといい、＠ IN SOA {MNAME} {RNAME}で記述します。 MNAMEは、 DNS サーバーの名前を記述します。 RNAMEは、この ドメイン の管理者のメールアドレスを記述します。＠マークは「 . 」に置き換えて記述する必要があります。 Serial ゾーンファイルのバージョンを表し、YYYYMMDDnn形式で記述します。この場合であれば「2020年12月 20日 1回目の変更」ということになります。※変更回数は0回からカウントします。 例えば同じ日に2回目の変更をした場合はシリアルを変更して「2020122001」となります。 Refresh ゾーンの情報をリフレッシュするまでの時間です。 セカンダリ DNS サーバーはゾーン転送をした後、この時間が経過すると、ゾーンの更新がされたかを問い合わせ、必要に応じて再度データを入手しようとします。 Retry Refreshでゾーンの情報が更新できなかった場合に、指定された時間後に再度リフレッシュを試みます。 Expire ゾーン情報のリフレッシュができない状態が続いた場合に、 セカンダリ DNS サーバーが所持しているデータをどのくらいの時間利用するか記述します。 Minimum TTL ネガティブキャッシュと言われ、名前解決ができなかったという情報を保持する時間を記述します。 IN NS ～ NSレコードといい、 DNS サーバーを記述します。今回の場合はプライマリ DNS サーバーと セカンダリ DNS サーバーを指定します。 最後に「 . 」を付けます。 ～ IN A ～ Aレコードといい、ホスト名に対応する IPアドレス を記述します。 ゾーンファイルの編集が終わったら パーミッション と所有権を変更します。 # chmod 750 /var/named/chroot/var/named/dns-server-test.work # chown root:named /var/named/chroot/var/named/dns-server-test.work # ll /var/named/chroot/var/named/dns-server-test.work -rwxr-x---. 1 root named 570 Dec 20 14:01 /var/named/chroot/var/named/dns-server-test.work ゾーンファイルもnamed.confと同様、記述が正しいかチェックします。「OK」と表示されれば問題ありません。 ※構文が正しいかのみのチェックであるため、 IPアドレス が正しいかどうか等は判定されません # named-checkzone dns-server-test.work /var/named/chroot/var/named/dns-server-test.work zone dns-server-test.work/IN: loaded serial 2020122000 OK Step9 最後に設定を反映させます。rndcコマンドを使用することで、 DNS サーバーを再起動させることなくゾーンファイルを反映させることができます。 # rndc reload server reload successful プライマリ DNS サーバーの構築は完了です。 目次へ セカンダリ DNS サーバーの構築 プライマリ DNS サーバーの構築が終わったら次は セカンダリ DNS サーバーの構築です。構築はプライマリ DNS サーバーとほぼ同様です。 セカンダリ DNS サーバーに SSH 接続し、プライマリ DNS サーバーで行った Step2～6 までを行います。 Step7はプライマリ DNS サーバーと セカンダリ DNS サーバーでは変更箇所があるため、変更箇所を以下に記述します。named.confファイルを編集します。 # vi /var/named/chroot/etc/named.conf options { // BINDのバージョンを隠蔽 version "unknown" ; // ホスト名 hostname "dns2.dns-server-test.work."; // 53番ポートでの受付をすべて許可 listen-on port 53 { any; }; // ipv6を使用しない listen-on-v6 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; secroots-file "/var/named/data/named.secroots"; recursing-file "/var/named/data/named.recursing"; // すべてのクエリーを受け付ける allow-query { any; }; // リゾルバとして動作しないように設定 recursion no; allow-recursion { none; }; allow-query-cache { none; }; dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config" ; // 1. セカンダリDNSサーバーからは通知を送信しない notify no; // 2. セカンダリDNSサーバーからはゾーン転送しない allow-transfer { none; }; }; logging { channel default_debug { file "data/named.run" ; severity dynamic; }; }; // ルートDNSサーバーのゾーン情報は今回必要ないのでコメントアウト /* zone "." IN { type hint; file "named.ca"; }; */ // 3. ゾーンファイルdns-server-test.workの設定 zone " dns-server-test.work " IN { // セカンダリDNSサーバーであることを指定 type slave ; // ゾーン転送されたファイルをバイナリ形式からテキスト形式に変換する設定 masterfile-format text; // ゾーンファイルのファイル名を指定 file "slaves/dns-server-test.work" ; // マスターDNSサーバーを指定（マスターDNSサーバーのプライベートIPアドレスを指定） masters { xxx.xxx.xxx.xxx; }; }; include "/etc/named.rfc1912.zones" ; include "/etc/named.root.key" ; セカンダリ DNS サーバーからは通知を送信しない プライマリ DNS サーバーからは通知を送信しますが、 セカンダリ DNS サーバーはバックアップのような存在であるため、通知の必要がありません。 セカンダリ DNS サーバーからはゾーン転送しない プライマリ DNS サーバーからはゾーン転送を行いますが、 セカンダリ DNS サーバーはゾーン転送を受ける側なので必要がありません。 ゾーンファイル dns -server-test.workの設定 DNS サーバーがプライマリなのか セカンダリ なのかの指定や、ゾーンファイルの名前を指定、ゾーン転送先を指定等をします。 セカンダリ DNS サーバーはゾーン転送によりゾーンファイルがプライマリ DNS サーバーから転送されてくるため、Step8は行いません。 Step9を行います。 # rndc reload server reload successful 最後にStep10として、ゾーン転送されているか確認します。 ※最初のゾーン転送が行われるまでは若干時間がかかる可能性があるため、次の「セキュリティグループの変更」や「 DNS サーバー登録」を行ってから再度確認してください。 # ll /var/named/chroot/var/named/slaves/ total 4 -rw-r--r--. 1 named named 473 Dec 20 15:20 dns-server-test.work セキュリティグループの変更( DNS サーバー) Webサーバーのセキュリティグループ変更と同様に DNS サーバーのセキュリティグループを以下のように変更します。 DNS サーバーは53番ポートで通信を行うため、 DNS ( UDP )と DNS ( TCP )を解放する必要があります。 DNS サーバーのセキュリティグループ変更は完了です。 目次へ DNS サーバー登録 先ほど構築した DNS サーバーですが、構築しただけでは DNS サーバーとしての役割、つまり名前解決を行うことはできません。 DNSサーバーとは の部分でも触れましたが、 DNS サーバーは階層構造になっているため、今回構築した DNS サーバーの一つ上の DNS サーバーに、構築した DNS サーバーの IPアドレス を登録する必要があります。 つまり今回の場合であれば「.work ドメイン を管理している DNS サーバー（お名前ドットコム）に、今回構築した DNS サーバーの IPアドレス を登録する」ということになります。 まずはお名前ドットコムにアクセスします。 画面右上の「お名前ドットコム navi ログイン」をクリックしてログイン画面に移ります。 ドメイン 取得時にお名前IDが発行されているのでそちらとパスワードを入力しログインします。 ログインが完了したら、画面上部の DNS タブにカーソルを合わせ、「 ドメイン の DNS 設定」をクリックします。 取得した ドメイン にチェックを入れ「次へ」をクリックします。 画面下部にある「ネームサーバー名としてホスト登録を行う」の「設定する」をクリックします。 作成にチェックを入れ「入力画面に進む」をクリックします。 ホスト名「dns1」とdns1の IPアドレス を入力し、「確認画面へ進む」をクリックします。 ※dns2も同様にホスト名と IPアドレス を登録します。（ DNS サーバーを2つ登録しないと後の画面でエラーになります。） ホスト名の登録が完了したら次は、 DNS サーバーの変更を行います。 画面左のメニューバーから「ネームサーバーの変更」をクリックします。 ドメイン の選択で ドメイン 名にチェックを入れます。ネームサーバーの選択でその他を選択し、構築した DNS サーバーの FQDN を入力します。 今回であれば「dns1. dns -server-test.work」「dns2. dns -server-test.work」を入力します。（ここで2つ登録できないとエラーになります。） エラー時参考： 【ドメイン】ネームサーバーの変更ができません。｜ヘルプサポート | ドメイン取るならお名前.com 「確認」をクリックすれば DNS サーバーの変更は完了です。 ※場合によっては、反映に時間がかかる可能性があります。 目次へ 動作確認 最後に DNS サーバーが正常に動作しているか確認します。 URL入力欄に FQDN を入力します。 成功です。 次は、 コマンドプロンプト から確認してみます。 > nslookup web-test.dns-server-test.work サーバー: ~~~~~~~~ Address: xxx.xxx.xxx.xxx　←自分のIPアドレス 権限のない回答: 名前: web-test.dns-server-test.work Address: xxx.xxx.xxx.xxx　←WebサーバーのIPアドレス Webサーバーの IPアドレス が返ってきていれば成功です。 次は DNS サーバーを直接指定して名前解決ができるか確認します。 まずは、プライマリ DNS サーバーからです。（yyy.~はプライマリ DNS サーバーの IPアドレス を指定） > nslookup web-test.dns-server-test.work yyy.yyy.yyy.yyy サーバー: UnKnown Address: xxx.xxx.xxx.xxx　←自分のIPアドレス 権限のない回答: 名前: web-test.dns-server-test.work Address: xxx.xxx.xxx.xxx　←WebサーバーのIPアドレス 次に、 セカンダリ DNS サーバーです。（zzz.~は セカンダリ DNS サーバーの IPアドレス を指定） > nslookup web-test.dns-server-test.work zzz.zzz.zzz.zzz サーバー: UnKnown Address: xxx.xxx.xxx.xxx　←自分のIPアドレス 権限のない回答: 名前: web-test.dns-server-test.work Address: xxx.xxx.xxx.xxx　←WebサーバーのIPアドレス どちらもWebサーバーの IPアドレス が返ってきていれば成功です。 最後にプライマリ DNS サーバーが停止している状態で確認します。 AWS マネジメントコンソール画面からプライマリ DNS サーバーを停止させておきます。 正常に停止したことを確認したら、次は コマンドプロンプト でコマンドを実行します。 PC内にゾーン情報が残っている可能性があるため、キャッシュを削除します。 > ipconfig /flushdns Windows IP 構成 DNS リゾルバー キャッシュは正常にフラッシュされました。 nslookupコマンドでも確認しておきます。 サーバー: ~~~~~~~~ Address: xxx.xxx.xxx.xxx　←自分のIPアドレス DNS request timed out. timeout was 2 seconds. 権限のない回答: 名前: web-test.dns-server-test.work Address: xxx.xxx.xxx.xxx　←WebサーバーのIPアドレス Webサーバーの IPアドレス が返ってきていれば準備完了です。 キャッシュを削除する以外にも、 Google Public DNS （8.8.8.8）を指定してコマンドを打つことでも確認することができます。 URL入力欄に FQDN を入力します。 成功です。 これにより、プライマリ DNS サーバーが何等かの不具合により停止したとしても、 セカンダリ DNS サーバーが稼働しているためWebページにアクセスすることが可能になっていることがわかります。 目次へ おわりに 長くなってしまいましたが、難しい手順などもなく簡単に DNS サーバーを構築できたのではないでしょうか。普段意識することの無い DNS サーバーについて少しでも知ることができていれば幸いです。 今回学んだことを応用すると、例えば「 DNS サーバーがダウンし目的のWebページにアクセスできないとなった場合（ DNS サーバーが応答していません等）、 Windows や Mac の参照先 DNS サーバー（ Google Public DNS ：8.8.8.8 や OpenDNS：208.67.222.222 等）を変更し、その DNS サーバーを経由させ名前解決を正常に行えるようにすればWebページにアクセスできるようになる」ということが理解できるかと思います。このように、 DNS サーバーについて理解を深めることで、Webサーバーがダウンしてアクセスできないのか、 DNS サーバーがダウンしてアクセスできないのか等の原因の切り分けにも利用できるかと思います。 冒頭で一瞬出ましたが、 AWS にはRoute53という DNS サーバーを簡単に構築することができるサービスがあるので、気になる方は是非調べてみてください。 今回は触れませんでしたが、 DNS サーバーの逆引き設定についても機会があれば紹介したいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スでは有り難いことにサービスが順調に成長しています。今後の成長に対応できるようにするために、継続的な検討課題としてより拡大可能な アーキテクチャ の検討を行っています。 拡大成長可能な ウェブアプリケーション （のバックエンド） アーキテクチャ としてすぐに挙がるのが「 マイクロサービス アーキテクチャ 」だと思いますが、マイクロサービス アーキテクチャ が一般的に議論されるようになったのが2015年頃からだったと思います。それ以来いろいろと考え続け、従来のモノリシック アーキテクチャ 群との間にある アーキテクチャ とイメージがつながってきたのでまとめてみたいと思います。 この記事でそれぞれのバックエンド アーキテクチャ を俯瞰的に比較することで、 ウェブアプリケーション 開発時のヒントになると思います。 各アーキテクチャについて モノリシックアーキテクチャ マイクロサービスアーキテクチャ ミニサービスアーキテクチャ モジュラーモノリス 各アーキテクチャの使い分け マイクロサービスに必要なもの BtoB, BtoCの観点から まとめ 追記 各 アーキテクチャ について 今回比較する各 アーキテクチャ はどれも ウェブアプリケーション のバックエンド アーキテクチャ になります。 昔ながらのモノリシック アーキテクチャ が無秩序でつぎはぎだらけなメンテナンスしにくい ソースコード に陥りやすいという課題感は 1997 年に発表され、 1999 年に Big Ball of Mud という論文で広く認知されるようになりました（参考： 大きな泥だんご - Wikipedia ）。 www.laputan.org それから15年後の 2014 年に ThoughtWorks 社の James Lewis 氏と Martin Fowler 氏が自社ブログにて『 マイクロサービス 』を発表しました。 誤解を恐れず言うのであれば発表された「マイクロサービス」の定義内容はコンセプチュアルな内容、言い換えるのであれば「 実用可能ではあるが想定が極端な アーキテクチャ コンセプト 」であったと思います。 martinfowler.com 2014年に発表されてからの数年間、 ITアーキテクト の皆さんはどうやったらプロダクトコードに落とし込むことができるのか理解と解釈を進めたと思います。 そのうち、マイクロサービス アーキテクチャ で想定されてる規模とマッチする ウェブアプリケーション に対してはマイクロサービスが適用され始めましたが、マッチする ウェブアプリケーション の範囲は ITアーキテクト たちが考えていたほど広くはありませんでした。 とはいえマイクロサービス アーキテクチャ のコンセプトは長年求められているものでした。なんとかそのコンセプトを適用することができないかと模索した結果、現実的なアプローチとして 2017 年に Cloud Elements 社の Ross Garrett 氏が自社ブログにて『 ミニサービス：実用的なマイクロサービスアーキテクチャ 』という投稿を公開しています（詳細は更にリンクされているTechTargetの記事）。 これはマイクロサービス アーキテクチャ ほど細かく分割はせずに、利用する技術要素も既存技術でまかなう考え方で、モノリシック アーキテクチャ とマイクロサービス アーキテクチャ の間にある落とし所を探す アーキテクチャ の一つとなりました。 https://blog.cloud-elements.com/pragmatic-microservices-architecture blog.cloud-elements.com といっても、ミニサービス アーキテクチャ も 複数サービスを開発・運用していく という部分では変わりなく、それよりも更に小規模であったり動的なスケールが必要ない ウェブアプリケーション にとっては導入によるデメリットが大きく、積極的に適用出来るわけではありませんでした。 モノリシック アーキテクチャ とミニサービス アーキテクチャ の間に位置づけられる アーキテクチャ として、 2018 年に Root Insurance 社の Dan Manges 氏が自身のブログで『 Railsのアーキテクチャ：モジュラーモノリス 』としてモジュラー モノリス アーキテクチャ を発表しました （2025.5.2追記）モジュラー モノリス の初出はDevNexus2016で基調講演として発表されたSimon Brownによる『 Modular monolith 』のようです 。 これはモノリシック アーキテクチャ をベースに、サービスに分割するのではなくモジュール（ Rails なのでgem）に分割していき、最終的には単一の ウェブアプリケーション としてデプロイする アーキテクチャ でした。 medium.com ここまでをまとめると アーキテクチャ が生まれた順序は以下のようになります。 各 アーキテクチャ 間の関係は以下のようになります。 それぞれの アーキテクチャ についてもう少し詳細に見ていきたいと思います。 モノリシック アーキテクチャ デプロイメントラインが1つで、バックエンドサービスが1つの アーキテクチャ 。 デプロイメントラインが1つであることは利点で『 マイクロサービス 』でも立ち上げ時などの速度を重視するタイミングではモノリシックで構築することが推奨されています。 反面、アップデートを重ね規模が大きくなると開発コストが増大するとされていますし、感覚値としてもその通りであるという印象があります。 特に成功したサービスほど急速にアップデートが行われることを考えると、成功した場合にはどこかでリアーキテクトを考える必要があると言えます。ただ……開発エンジニアの想定（というか渇望）よりはモノリシックのままで対応できる範囲は広く、それが判断を難しくしている原因とも思います。 マイクロサービス アーキテクチャ 2014年に提唱されて以来、ノウハウがまとまった書籍が揃ってきました。 まずはサム・ニューマン著『マイクロサービス アーキテクチャ 』を読みましょう。 概要についてはこの本で網羅的に抑えることが出来ます。ちなみに原著の方では第2版がO'reilly Learning Centerで先行リリースされています " Building Microservices, 2nd Edition "。 ※追記 ：2022/12/2に第2版の翻訳版が発刊されました 「マイクロサービス アーキテクチャ 」の流行もやや落ち着き、冷静な議論が出来るタイミングが来ていると感じていますが、忘れてはいけないのは提唱者ら自らが「『マイクロサービス アーキテクチャ から始めるべきではない』というのは合理的な議論である。 モノリス から始めて、モジュール構造を保って、 モノリス であることに問題が生じたらマイクロサービスに分割する」と語っていることを忘れてはいけません。 One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. " Are Microservices the Future? - Microservices " モノリス からマイクロサービスへの移行パターンについても翻訳本はまだ出ていませんが、"Building Microservices"と同じ著者で" Monolith to Microservies "という本が2019年に出版されています。 と、思ったら2020年12月26日に翻訳本が発刊されるようです！ うれしい！！ ミニサービス アーキテクチャ マイクロサービス アーキテクチャ は破壊的すぎるとしてミニサービス アーキテクチャ が提唱されています。大きな違いとしては以下があります。 サービス分割単位は機能単位ではなく ドメイン 単位 データストアは必ずしもサービスごとではなく、共有データストアでもOK サービス間通信はpub/subではなく、httpでもOK 調査会社のガートナー社では以下のように図解しています。 出典元： Gartner また私が以前にMicroservices Meetupで発表した資料へのリンクも置いておきます。 モジュラー モノリス マイクロサービス、ミニサービス、とサービスを分割――すなわちデプロイメントラインを複数にする――というアプローチを前提においていましたが、デプロイメントラインが複数になるということは 複数の Webサービス を開発・運用する ということになります。このコストは無視できません（なんせより大きな成功につながる かもしれない 別の Webサービス を展開するのと同等のコストです）。 この問題について1つのデプロイメントラインを維持しつつ、サービス分割をモジュール分割とすることで解決しようとしたアプローチがモジュラー モノリス になります。 2019年に Shopifyが実際に移行した取り組み で話題になりました。Shopifyでは分割後のモジュールとの依存を管理するために Wedge というツールを開発してプロジェクトを進めていたようです（このツールも OSS として公開したいとのこと）。 （2021.1.6追記） Wedge は Packwerk として公開済みとコメントにて教えていただきました。 takahashimさん、ありがとうございます。 shopify.engineering 翻訳記事も見つけました。 qiita.com モジュラー モノリス においてデータストアはどのように扱うのか、という点においてはミニサービスアキテクチャのように共有データストアを利用するケースもあれば、モジュール単位でデータストアを持つ方法も試されているようです。このあたりの話は Mnolith to Microservices(モノリスからマイクロサービスへ) の第1章「必要十分なマイクロサービス」の「 モノリス の課題」や、第4章「データベースを分割する」が参考になると思います。 モジュラー モノリス については弊社の先行技術検証の取り組みである「技術推進プロジェクト」の成果として別途記事にもしているのでご参照ください。 tech-blog.rakus.co.jp 各 アーキテクチャ の使い分け マイクロサービスに必要なもの これまでそれなりの時間をかけて検証を重ねてきましたが、マイクロサービス アーキテクチャ を採用するのは相当にハードルが高いと感じました。 最初に必要となる適切に構成された コンポーネント 群についてはサービス分割を念頭に起きながらサービスの開発・運用を一定期間続けることできれば、 ドメイン 知識の蓄積によりなんとか「適切な構成」を見出すことは出来るかもしれません（「サービス分割を念頭におく」ことが相当に難しいことはともかく）。 スキルレベルの高いエンジニアチーム、具体的には分散システムの開発・運用を実現するためのツール群や設計思想などに精通したエンジニアチームとなりますが、これも一朝一夕では厳しくとも時間をかければなんとか実現出来ると思います。 ただ、それらを揃える労力を「マイクロサービス アーキテクチャ 」を実現するコストとして投入するかというと悩ましいところです。 BtoB, BtoCの観点から ラク スはBtoBでのビジネス展開をしているわけですが、BtoBサービスにおいてはマイクロサービス アーキテクチャ の必要性はそこまで高くないと判断しています。 マイクロサービス アーキテクチャ の旨味である「オートスケールと組み合わせての予想しない負荷への自動対応」だとか「日に何十回もの小刻みな本番環境へのリリース」といったBtoCで求められることは特定多数がユーザーであるBtoBではあまり求められていないです 1 。 とはいえサービスが大きくなったときにモノリシック アーキテクチャ のままであることにもつらさがあるため、 モノリス とマイクロサービスの間のどこかを目指すことになると考えています。 直近では モノリス の状態で、問題が出始めたら"Monolith to Microservices"でも「多くの組織にとって、モジュラー モノリス は優れた選択肢である」と書かれているようにモジュラー モノリス を目指していくことになるのではないかと考えています。 コンテナ オーケストレーション だとか、分散ロギングなどの運用ノウハウが十分に貯まったころに、次いでミニサービス アーキテクチャ が選択肢に入ってくるとイメージしています。 まとめ さて、この数年間で比較されてきた モノリシック アーキテクチャ モジュラー モノリス ミニサービス アーキテクチャ マイクロサービス アーキテクチャ の4つを俯瞰して見渡してみました。 アーキテクチャ 検討の参考になればと思います。 なお、現時点では 2 先述の通り「モジュラー モノリス 」が一番現実解に近いかな……と検証を行っていますが、モノリシック アーキテクチャ に比べるとモジュールとして分離するコストが上乗せされる分高くなります。どの程度の規模で分離しはじめるべきなのか、見極めラインは今後も探っていきたいと思います。 追記 [2020.12.21追記] 今年翻訳本が発刊されたクリス・リチャードソン著『マイクロサービスパターン』もおすすめです。サービス分割に関する部分など、マイクロサービスに限らずミニサービスやモジュラー モノリス にも役に立つ内容が掲載されています。ちなみに元ネタはこの本の著者が運営するウェブサイト Microservices.io です。 microservices.io [2021.1.6追記] コメントにて takahashim さんから「 Wedge は Packwerk として公開済み」と教えていただきました。2020年9月に公開されていたようです。名前が変わっているとは盲点でした。 shopify.engineering エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 契約しないと利用することが出来ないことと、契約からサービス利用開始までに一定期間があるため直近の負荷予測ができるからオートスケールはいらない。またアナウンスなしでの機能追加なども現状では考えにくく、日に何度もアナウンスされても利用者も困る。 ↩ 2年前はモジュラー モノリス の発想がなかったこともあり、ミニサービスが現実解かと思っていました。しかしデプロイメントラインが複数になるコストは無視できないものでした。 ↩

はじめに 株式会社 ラク ス 配配メール開発課の PHP エンジニア Jazumaです。 2020年12月12日(土)に PHPカンファレンス が開催されました。 phpcon.php.gr.jp 例年では「 大田区産業プラザ PiO」で開催予定でしたが、今年は 新型コロナウイルス の影響でオンライン開催となりました。個人的にはオンライン開催である分、地方のエンジニアでも気軽に参加することができたのは良かったのではないかと思います。 ラク スは PHPカンファレンス にスポンサーとして参加 させていただいている他、社内からLT枠で2名が登壇しました。 今回は PHPカンファレンス に参加した社内の PHP エンジニアがイベントをレポートしましたので、ご紹介したいと思います。 各セッションのスライドについては以下にまとめましたので、ご活用いただければ幸いです。 No タイトル 1 SPAのAPI開発の「やりづらさ」をDDDとオブジェクト指向の発想で解決する 2 PHPの今とこれから2020 3 PHP WEBアプリケーション設計入門――10年先を見据えて作る 4 レガシープロジェクトで、メタプログラミングを使ったPHPStan静的解析レベル上げ 5 長期運用を目指す『Shadowverse』におけるリファクタ事例の紹介 〜テストの導入とメンバーへの普及法〜 6 PHP on Kubernetes 7 Webサービスをセキュアに保つために必要な視点 8 Composer 2.0 って何？どう変わるの？読んでみました！ 9 今こそ理解する、PHPの日時時計 10 PHP8時代のWebアプリケーションフレームワークの話をしよう 11 ウェブセキュリティのありがちな誤解を解説する 12 PHPで作るオンラインカンファレンス向け録画システム 13 静的解析ではじめる負債コード解消 14 レガシーシステムに自動テストを導入する第一歩 SPAの API 開発の「やりづらさ」をDDDと オブジェクト指向 の発想で解決する report by mrym_618 tech.quartetcom.co.jp 現代のSPAでの API 開発には様々な問題があり、その問題に対してどのような解決策があるかについてのセッションでした。 このセッションで話されていた、問題と解決策は以下の通りです。 ロジックの重複 問題：フロントエンドとバックエンドで同じロジックが現れる 解決策：バックエンド側で隠蔽する トランザクション できない 問題：サーバ側の状態が変化することを止められない 解決策：バックエンド側でロジックの隠蔽を行い、 トランザクション はサーバ内で行う この API 、他にどこで使われていたっけ?!問題 問題： API を使い回した結果、その API を削除したくても他に影響が出そうで削除できない 解決策： API もSRP（単一責任の原則）にし、フロントエンドから見て別であれば別の API にする n+1 問題：n+1回のリク エス トを発行してしまう 解決策：n+1を解決できるレイヤー（ SQL ）に任せる 全ての解決策に共通していることから、バックエンド側に任せられることは任せてしまい、フロントエンド側はフロントエンドのことに集中する。 そして、それぞれが連携し合って開発していくことが大切であると改めて感じる発表でした。 PHP の今とこれから2020 report by richardwagner カンファレンス冒頭を飾ったのは、 PHP がリリースされてからの25年間を俯瞰しつつ、最新のPHP8の新機能にも触れた廣川類さんの基調講演でした。 PHPの今とこれから2020 from Rui Hirokawa www.slideshare.net 前半パートは具体的な数値にふれながら、 PHP が果たしてきた性能向上と規模拡大の実例が紹介されました。 PHP4の時代からこの20年で、実に50倍の性能向上を実現 cファイルベースの総ステップ数は、Python3の40万行、Ruby2の80万行を、PHP8の120万行が大きく凌駕 後半パートではPHP8の変更/改善点と、新機能 JIT における性能向上がわかりやすくまとめられていました。 機械学習 やAIが PHP で書かれるようになる（かも）という将来は、私たちPHPerにとっても心躍る話でした。 PHP WEBアプリケーション設計入門――10年先を見据えて作る report by soachr speakerdeck.com 10年先でも使える設計についてどうあるべきか、という内容で濃い1時間のセッションでした。 冒頭に10年たったら フレームワーク ・技術が変わる というところについて実例を交えて説明されていました。 弊社も10年超えのサービスがありがたいことにいくつもあるのですが、同じように技術が変わって”レガシー”になっておりとても共感する箇所が多かったです。 「10年先を予見するのは難しいので、10年間の変化に対応しうる設計にしておく」というスタンスでお話が展開されており、 設計時に考慮する点としておっしゃっていた以下が開発言語に関わらない考えだと思い、今後の設計フェーズで意識したいと思います。 フレームワーク などの特定技術から一定の距離を保っていく 広く長く使われることを開発当時から意識する レガシープロジェクトで、 メタプログラミング を使ったPHPStan静的解析レベル上げ report by takaram speakerdeck.com 弁護士ドットコムさんで、静的解析ツールPHPStanを導入した際のお話でした。以前こちらのnoteを読み興味を持っていたため、楽しみにしていたセッションのひとつでした。 note.com すでに規模が大きくなっているプロジェクトに途中から静的解析を導入すると、既存コードで大量にエラーが出てその対応に時間が取られる、というような話も聞きます。 その点とても上手く対応されていて、導入時にはLevel 0という最も緩いチェックのみを行い、対象ファイルも無理に全ファイルを対象にはしなかったそうです。 スモールスタートで導入した後、徐々に対象ファイルの拡大・チェックレベル上げを行うために、 メタプログラミング を使って 機械的 にコードの修正を実施していったということでした。 私が担当しているプロダクトもPHPStanのような静的解析ツールは未導入で、プロジェクトの規模や技術負債の状況も今回のお話によく似ていると感じました。そのため、静的解析導入の成功事例を聞けたことはとても勇気づけられるものでした。 ちなみに、このセッションとは別にCIでの静的解析についてのセッションもあり、そちらもとても面白かったです。 speakerdeck.com 長期運用を目指す『Shadowverse』におけるリファクタ事例の紹介 〜テストの導入とメンバーへの普及法〜 report by YS https://fortee.jp/phpcon-2020/proposal/ab40d17d-37e7-42af-8a88-188a61c6745b スライドは後日、ブログにアップ予定とのこと Cygames Engineers' Blog tech.cygames.co.jp ソーシャルゲーム 「Shadowverse」を5年間アップデートしてきたことにより「コードの可読性低下」「コードの属人化」等の課題が発生し、 現状だと長期運用が厳しい状態になり安定した リファクタリング を進めるために テスト導入チームを立ち上げ、テストコード等を導入し改善を行ったという内容について語ってくださいました。 テストコード等の施策を取り入れた後、 リファクタリング を行ったことにより、 リファクタリング 後の不具合は、 デバッグ 時に1件のみ発生という素晴らしい成果を得たそうです。 メンバーへの普及方法は、「環境導入」「テスト作成」「自動テスト実行」各作業でのハードルを下げることが重要で、次の様な施策を上げてくださっておりました。 ・「環境導入」のハードル 　手順書やツールの充実 ・「テスト作成」のハードル 　テストコードのレビュー等による学習機会の提供 ・「自動テスト実行」のハードル 　CIツールによる自動テスト実行と結果の通知等 システムの改修を安定して進めるためには、こちらのセッションで上げてくださった取り組みは とても重要な物であると認識しているため、今後の開発で参考にさせていただきます。 徳丸皆伝を狙いませんか？徳丸実務試験とPHP8上級試験の解説 report by kuwa_38 ( track2 2:25ほどから) セッション概要： 吉政さんからPHP8上級試験と徳丸実務試験の概要説明、それから特典（ PHP マグ カップ と PHP 本、徳丸本）が紹介されました。 その後、徳丸さんから徳丸実務試験の例題3問とその解説が行われました。 例題の概要： 1問目：特定サイトから利用するウェブ API のテスト中にCORSのエラーがでた。どう解消すべきか（4択から1つ選択） 2問目：提示された PHP の スクリプト のうち発生する 脆弱性 を全て示せ （4択から複数回答） 3問目： XSS脆弱性 のある JSONP による API の PHP ソースコード が提示され、対策として不適切なものを1つ選択（4択から1つ選択） 視聴後の所感： 私の視聴した動機が「どんな問題が出題されるか」だったこともあり、特に例題とその解説はとても興味深かったです。また、図解や選択肢1つ1つの解説もありとても分かりやすかったと思います。 問題と解説自体は10分強なので、セキュリティに興味や関わりがある方は、ぜひ アーカイブ をご覧頂ければと思います。 PHP on Kubernetes report by Jazuma chatwork所属Kouta Ozakiさん(@k_kinzal)のセッションのレポートです。 ※このレポートで使用している画像は全てOzakiさんの発表資料 の引用です。また、資料の利用にあたってはご本人の許可を得ています。 speakerdeck.com セッション内容まとめ・感想 k8s で PHP は普通に動く PHP が他の技術と比べて特段 k8s との相性が悪いということはなく、正しく導入すれば特に問題なく稼働するようです。 k8s の学習コストは高い VM やServerlessと比較して k8s の学習コストは高いようです。そのため何のために k8s を導入するのか決めずに無計画に取り入れようとしても意味がなく、逆に 工数 をとられるだけの結果になります。他の技術と同様に k8s はあらゆる問題を立ちどころに解決する 銀の弾丸 ではないようですね。 PHP アプリケーションのコンテナ化 PHP アプリのコンテナ化にあたってはアプリの設定をどのようにコンテナに反映させるのかが問題になります。 開発環境としての k8s k8s の開発環境としてのパフォーマンスを Vagrant やdocker-composeと比較すると上記のようになるようです。 個人的には開発環境として使うのであればどれも大差はないように思いました。 k8s の学習コストをどのように支払うのか 私がOzakiさんに「chatworkさんでは k8s を使うにあたってスイッチングコストや学習コストをどのように賄ったのか」と質問したところ以下のようにお答えいただきました。 全社的に k8s の導入に前向きだった SREチーム3名が尽力した 開発チームも巻き込んで何とかした このことから k8s を導入するには次のような要素が重要だと思いました。 新技術導入に前向きな姿勢 コンテナや クラウド に精通したSREチーム 開発チームと運用チームとの連携・協力 特に開発と運用の協力についてはあらゆる企業・チームが重視すべき要素のように思います。 Webサービス をセキュアに保つために必要な視点 report by tsudachantan fortee.jp speakerdeck.com Webサービス をセキュアに保つための観点、具体的な思考法、攻撃事例、対策のための指針についての話でした。 セキュリティを学び始めたばかりの初心者にもわかりやすい内容でした。 セキュリティ初心者にもとてもわかりやすい。視点の話。 #phpcon #phpcon2020 #track3 — さりー@Webエンジニア (@Sally_42) December 12, 2020 セキュアな状態とは何か、それはユーザが安心安全だと感じる状態である。では安心安全な状態とは？逆に、安心安全でない状態とは何か？ と順を追って 言語化 されていてとてもわかりやすかったです。 ユーザだけでなく、開発現場のITエンジニアに置き換えても頷けるような汎用性のある内容でした。 30分で再認証させるのは安全性を高めるけど、 ユーザーの利便性をかなり下げる気がする。 #phpcon #phpcon2020 #track3 — Fumito Mizuno 📕 #のベルズ (@ounziw) December 12, 2020 具体例を示しての掘り下げも行われ、セキュリティとユーザの利便性との兼ね合いについても触れられていました。 ユーザフレンドリーと一口に言っても、ユーザにとって「セキュアで優しい」とユーザにとって「使いやすくて優しい」を両立させることの難しさを感じました。 個人的に、セキュリティ負債の解消としてユーザの リテラシー の平均を議論するという話が、今まで無かった視点だったので興味深かったです。 フレームワーク や攻撃事例も紹介され、濃い内容の1時間でした。当日のスライドも公開されているので、ぜひご覧ください。 Composer 2.0 って何？どう変わるの？読んでみました！ report by MasaKu speakerdeck.com v2 の新機能についてのお話と v1 からどのような部分が変わったのかというお話。 CakePHP のプロジェクト作成を v1 と v2 で比較して実演してくださったが、結果 v2 の場合、約半分以下の時間でプロジェクト作成が完了していたのが印象的でした。 また、メモリ使用量も劇的に削減されておりました。 メモリ削減の理由 v1 の場合は、composerの依存関係を解決する際に、packagist からパッケージの一覧を取得してメモリ上に配置する ファイルには ハッシュ値 を記録しておき、再度、composer を実行した場合は、 ハッシュ値 をもとに古くなっている場合は再取得するという流れになっている 一方、v2の場合はパッケージのリストを取得するという処理は行っていない packages, json に定義されたmetadata-url というフィールドから対象の メタデータ を取得する。 そのため、余計な処理が走らないようになっている。 この仕組みを lazy provider といって、先にリストをすべて読みこまなくても良くなったため高速化およびメモリの削減が実現できた模様。 その他にもissue や過去のリリース情報を見ると勉強になることがあるため、興味がある人はぜひ見たほうがよいとのことでした。 今まで当たり前に行っていたことを根本的に見直すことで、劇的に改善できることを体現した勇気づけられる発表だと思いました！ 今こそ理解する、 PHP の日時時計 report by nr_1228 speakerdeck.com 基本的な日付関数の説明を踏まえ、DateTimeクラスとDateTimeImmutableクラスの比較など、 PHP の日付計算はどうするのがベストなのかというお話でした。 日付を取り扱うにあたってのトラップなども紹介されており、 自分がハマったことのあるトラップに関しては画面の前で大きく頷いてしまいました。 日時計 算のコードは頻繁に書くわけではないので、忘れたころにやってくることが多いです。 故にまとめる時間をなかなか取れずにいたので、今回のセッションを聞くことで考える時間を纏って取ることができてとても良かったです。 日付に関して調べたことがあるという人はぜひ アーカイブ を視聴してみてください。 PHP8時代のWebアプリケーション フレームワーク の話をしよう report by Y-Kanoh HTTPリク エス トを入力とし、HTTPレスポンスを返す仕組みである、Webフレームワークの内部の作りに、PHP8の新機能がどう利用できるかを解説したセッションでした。 Constructor Property Promotion や、Attributes など、PHP8では フレームワーク の内部で活用できそうな機能が増えて、Webアプロケーションを考えるための下地がさらに整ったと言えますので、今後はこれらの機能を用いた フレームワーク が増えることでしょう。 また、最近ではデプロイ先の選択肢も増えているため、これらの新しく開発される フレームワーク には、これらの環境へのデプロイを簡易にしてくれる機能が期待されます。 近年のフロントエンドとバックエンドを切り離す動きから、 フレームワーク にはシステムのつなぎ目をうまく作る、 API ファーストな考え方が求められており、 API 仕様から仕組みを決めてしまう方法や、サーバサイドもJS/TSで書いてしまう方法、フロントエンドもバックエンドと同じ言語で書いてしまう方法など、 システム間をスムーズにつなぐための方法も紹介されていました。 speakerdeck.com PHP8の目玉機能の一つである Attributes は、 フレームワーク やライブラリの開発に向けた機能だと考えられるため、今後どのように活用され、我々が利用することになるのかは気になるところです。 また、Webを取り巻く環境の変化やトレンドも、今後どのように フレームワーク を変えていくのか、これから開発される フレームワーク に期待が持てる発表でした。 ウェブセキュリティのありがちな誤解を解説する report by richardwagner ウェブセキュリティに関してともすれば誤解されがちな10のポイントに関する、具体的な例が満載の非常に役に立つ基調講演でした。 ウェブセキュリティのありがちな誤解を解説する from Hiroshi Tokumaru www2.slideshare.net Cookie についての誤解はエンジニアならぜひとも押さえておきたい内容でしたが、 それに加えてクレジットカードをサイト保存せず都度入力することのリスクや、 Google 検索上位サイトへの盲目的信頼への警鐘など、 エンジニアに限らず一般の方々にもぜひ参考にしていただきたい内容が目白押しでした。 個人的にも、非エンジニアの家族や友人にも紹介しようと思ったスライドでした。 そして書籍でいつもお世話になっている徳丸浩さんの、落ち着いた大学講義のような語り口はとても聞きやすく、あっという間の1時間でした。 PHP で作るオンラインカンファレンス向け録画システム report by id:radiocat speakerdeck.com 今回の PHPカンファレンス はTrack1だけが ライブ配信 でそれ以外は録画配信となっていますが、この録画配信システムは PHP （CakePHP3）で構築されいるとのことです。もともとはiOSDC Japan 2020で構築した仕組みを今回も取り入れているようです。iOSDCでのエピソードは Podcast の PHP の現場でも話されていました。 php-genba.shin1x1.com 録画はZoomと Youtube Liveの API を使って全て自動化 動画編集は様々なツールやサービスを組み合わせて PHP のコードで腕力解決 「すごいシステムを作るのに必ずしもすごいことをする必要はない」と仰っていたのが印象的でした。 API の仕様をしっかり把握してそれを駆使する。それ以外は必要な環境＋ PHP の腕力で地道に実現する。いずれもエンジニアリングの本質だと再認識したセッションです。 PHPカンファレンス 大LT大会 report by id:radiocat 大LT大会では16名の登壇者が次々とライトニング トーク されました。ここでは弊社から登壇した2名のスライドをご紹介させてください。 静的解析ではじめる負債コード解消 speakerdeck.com PhpStormのInspectionを使って負債コードを特定する方法をご紹介しました。Inspectionを使いながら開発を進めることで、 プログラマ は自分が担当している開発の範囲で負債コードを検知して少しずつ技術的負債を減らしていくことができています。 レガシーシステム に自動テストを導入する第一歩 speakerdeck.com 10年以上前にサービス開始したレガシープロダクトに PHPUnit を使った テスト駆動開発 を導入した話です。従来から存在する機能を API 化するタイミングで、まず既存機能のテストを作成してから API 化することで仕様変更に強い テスト駆動開発 の効果を実感することができました。 おわりに PHPカンファレンス では PHP の基礎から最新技術の導入事例まで幅広いテーマが扱われていました。 皆さんも今回紹介したイベントレポートやセッションの内容をぜひご自身のお仕事に取り入れてみてはいかがでしょうか。 弊社はオンラインで勉強会を開催しています。 PHP がテーマの勉強会もありますのでぜひご参加ください。 rakus.connpass.com 直近で開催されたLaravel/PHP8/Dockerをテーマとした勉強会にはのべ200人近くの方にご参加いただきました。 rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 皆さん、こんにちは。技術広報のitoken1013です。 今回は先日12/12(土)に開催の Developers Boost 2020 （デブスト）に参加してまいりましたので、当日の様子をお伝えできればと思います！ 今回は ラク スも協賛の機会をいただき、ゴールドスポンサーとしてイベントに参加させていただいておりました！ event.shoeisha.jp イベントの概要 30歳以下限定の若手エンジニアが登壇する人気イベントとして、毎年開催されていますデブスト。 今年のテーマは 『Share your ENGINE～ひとりじゃない～』 でした。 新型コロナウイルス の影響によって変化を余儀なくされた市場下において、エンジニアとしてのキャリアや スキルアップ をどう広げていくかを募るイベントテーマでした。 今年の大きな特徴として、初のオンライン形式での開催となりました。 セッションには計17名の登壇者が参加の上、会場もしくはZoom配信の形式で専用プラットフォームから配信をいただく形式でした。セッション終了後にはEventInというオンラインイベントツール上で質疑応答が行われ、オフラインと遜色ない距離感で登壇者と参加者が会話できる空間が醸成されていたと感じています。 Twitter でも #devboost 上から当日の賑やかな様子を感じ取ることができます。 従来のオフラインイベントと異なり、参加者の様子が見えない点は登壇者の方には不便だったかもしれません。ただ登壇者の皆様はその影響を感じさせず、どなたもスムーズに進行されていた点は流石だなと思いました。 若きとても優秀な登壇者の皆様、お疲れ様でした！ ちなみにこの記事を書いている私はとっくに30歳以上なのですが、スポンサー特典として頂戴しましたチケットで皆様のご活躍を拝見しつつ、EventInのスポンサーブースで ラク スの紹介をさせていただきました。 セッションのご紹介 それではここからセッションのご紹介です。 個人的に特に印象に残りましたセッションを抜粋して紹介させていただきます。 古の大企業向け パッケージソフト の クラウド 移行にJoinして見えた面白さ リリースから24年の歴史を持つCOMPANYの クラウド 移行に関わったエピソードと共に、SREチーム所属の増井さんのキャリア展望を語っていただきました。 1100社が利用中の巨大サービスを AWS 移行ということで大きな挑戦でしたが、ご自身のキャリアを広げる挑戦の舞台として活用されていた点は非常にポジティブに映りました。 またSlackを活用した新しいサービスのインプット方法は私も非常に参考になりました。 世間では一見ネガティブな意味で捉えられがちなレガシーサービスとの関わりについても「オンプレ → クラウド 移行は エンタープライズ 領域で多数あり、これから求められる知識を先取りできる」とポジティブに転換できており、歴史の深さでは負けていない ラク スでも増井さんの思考はとても参考になる貴重なお話だったと感じています。 コミュニティ活動で差別化をめざすエンジニアとしての一手 t.co 弊社エンジニアとしてコミュニティ運営で主導的な役割を果たす加納の登壇です。 他の方のセッションとの違いとして、リアルタイムにアンケートを募る インタラクティブ なセッションを実施しました。 先ほどの発表で行っていたアンケートの結果です。 協力していただいた方、ありがとうございました！ https://t.co/bV0gKh7WJj #devboost pic.twitter.com/3ynQkwUfMt — Y-Kanoh (@YKanoh65) 2020年12月12日 コミュニティ活動には自身・組織・キャリアの3側面におけるメリットが存在し、技術面以外のキャリアの差別化としてコミュニティの運営は大いに役立ちます。 コミュニティ活動で得られる学びと喜びを、これまで運営を体現してきた加納の資料から知っていただければと思います。 技術が好きで好きで好きでたまらないエンジニアが「取締役」になって思う、マネジメント キャリアパス 新卒でいきなりPMを任された小笠原さんより、 CDO （Chief Development Officer）になるまでの6年間におけるキャリアの中でのマネジメント論を語っていただきました。 最初は失敗だらけだったマネジメントも周囲の方の助けを借りながら、エンジニア、PdM、VPoEとキャリアを積むうちに徐々に時間の使い方を上達していったお話でした。 これまで非常に高いハードルで苦しいシーンも経験してきたのではと思うのですが、それでも同じ世代のエンジニアに対して「経営/マネジメント視点は最強装備、マネジメントは武器になる。興味があれば手を挙げてみよう。」と投げかける姿は印象的でした。 20代に関わらず、マネジメントで成長したい全ての世代に聞いていただきたい内容でした。 アウトプット駆動キャリア 学びをアウトプットすることの価値とその方法論について、ご自身も出版やコミュニティ運営に携わる土田さんにお話いただきました。 「アウトプット駆動」という言葉自体は耳慣れた方もいらっしゃるのでは思いますが、周囲と差別化するための具体的な方法については、深くご存知ではない方が多いのではと思います。 土田さんは「キャリアはアウトプットの積み重ね」と述べつつ、以下の3点からアウトプットのテーマを見つける方法を教えて下さいました。 自分の興味関心 世界のトレンド 日本の現状 一見ハードルの高いアウトプットについても、気になるニュースを リツイート するところからなど、スモールスタートをとることを薦めています。 今回のセッションに感化され、さっそくアウトプットを開始する方が増えたのではないかと思います。 職能横断型 スクラム 体制になってからのチーム改善活動 speakerdeck.com これまでバックエンド、フロンエンド、デザイナーなどの職能単位のチーム体制から、職能横断型のプロジェクト単位のチームへ転換した際に起こった課題と施策エピソードを語っていただきました。 タックマンモデルにおける形成期と混乱期ではそれまでの暗黙的なルールや慣習が通用しなくなり、どうすればより生産性が上がるかの試行錯誤が必要となります。登壇者の藤井さんが所属するストアーズ・ドット・ジェーピー様では直面した3つの課題に対し、施策を打ち出していきました。 どの課題も特に自社サービス開発の企業であれば、直面する可能性があるものではないかと感じています。また課題を「課題である」と認識するにもメンバーによってバラつきがあり、藤井さんが仰る通り、泥臭くても課題を出し続けるための場作りが重要だなと感じました。 組織運営をする上で非常に参考となるセッションでした。 Hello, World! 外 国語学 部英語学科系エンジニア 爆誕 までの軌跡 文系エンジニアが描くべき キャリアパス として、「掛け算式キャリア形成」を語っていただきました。 スタート時点で文系エンジニアは技術スキルが劣るものの、最初に訪れる技術の壁を乗り越えた先には能力的にバランスのいい人材となる。そして技術以外の得意領域と掛け合わせることで、レアな人材になる可能性を秘めているとのことでした。 登壇者の関本さんも未経験からスタートし数々の傷を負ってきましたが（面白かったです）、現在は英語とコミュニケーション能力を組み合わせたテッ クリード を目指しているとのことです。現在進行形で苦しんでいる日本中の文系エンジニアの方に勇気を与えるセッションだったと思います。 関本さんならきっと優秀なテッ クリード になれると思います！ 凡人エンジニアの 生存戦略 t.co 1～2年目頃の若手エンジニアなら誰しもが思ったことのある将来への不安に冷静に向き合い、髙市さんがどのように成長していかれたのかを語っていただきました。 世間で注目を集めるような「楽しくて仕方がない、いつまでもやっていられる」というエンジニアとは距離感を感じて働かれていた髙市さんですが、 まつもとゆきひろ さんの勉強会で学んだエピソードや人間の特性を把握した上での取り組みにより、精神的な安定と自信を得ていきました。 中でも個人的には「個人で定期的なふりかえりを行う」が効果的な取り組みなのかなと感じています。 ただ漠然と不安を感じながら働くのではなく、意識的にアクションを打っていけば自然と解消できるんだなと学ばせていただきました。今回のデブストのイベントテーマである「ひとりじゃない」を感じさせていただける良い内容だったと思います。 不確定要素が強い時代の 生存戦略 ― U30が「好きなコト」で突き抜けるためには!? t.co ラストは Microsoft MVP でいらっしゃる堀尾さんによる、「好きなコト」で圧倒的に成長していくための戦略です。 堀尾さんがMixed Realityという分野を見つけ、どのようにMixed Realityにおける スペシャ リストになったかが語られています。 不確定要素が非常に多い現代だからこそ、自分がありたい姿（Being）の 言語化 とアウトプットはキャリアを突き詰める上で非常に重要だと感じました。 非常に熱い内容で、終盤の疲れを吹き飛ばしてくれる内容でした！ おわりに 登壇された若手エンジニアの方々、あらためて今回はお疲れ様でした。 お恥ずかしながら私は今回が初のデブスト参加だったのですが、熱のこもった登壇を拝見させていただき、若手エンジニアにとって貴重な価値あるイベントと感じることができました。 また、このような場に立つ方であっても若い頃の自分と同じ悩みを抱えている方もいらっしゃり、イベントテーマである「ひとりじゃない」という共感を生むシーンも多かったのではないかと思います。 今回は初のオンライン開催にも関わらず、柔軟な開催形式によって無事にイベントが成功したと言えるのではと思います。 来年度がどのような形で開催されるかはまだ分かりませんが、オフライン・オンラインの両方を取り入れることによって日本全国から参加可能な大型カンファレンスに…ということも十分可能かとイメージしています。 ますます進化するデブストの今後にとても期待しています！

はじめに こんにちは ラク ス開発エンジニアのhyoshです。 激動の2020年も残りわずかとなる中、皆様はいかがお過ごしでしょうか。 今回は私が自作の Chrome 拡張機能 を用いて業務を効率化した方法についてご紹介させていただきます。 同じような課題に悩んでいる方のお力となれば幸いです。 はじめに 起きていた問題 どうやって解消したか Chrome拡張機能とは？ 環境構築 必要知識 サンプル manifestファイルを作成する その他ファイルを作成する ブラウザに取り込む おわりに 起きていた問題 まだ私が他社に所属していた時の話ですが、エンジニアが本番作業を行う際にはWEBフォームから申請を行い、承認をもらってから行うというルールとなっていました。 ただこの申請において入力ミスが非常に多く、それに伴う差し戻しの煩雑さが日々ボディブローのように業務を侵食していました。 どうやって解消したか そもそも入力者自身が気づけないのが問題で、このページに入力チェックがあれば防げるんだけどなぁ…と思っていた時に行き着いたのが Chrome 拡張機能 でした。 そして結果的にチームオリジナルの入力チェックを行う 拡張機能 を自作した事で入力者によるミスをほぼゼロにすることができました。 Chrome 拡張機能 とは？ Chrome 拡張機能 とは Chrome 内で利用できるアドオンであり、 ウェブストア からブラウザに追加する事で誰でも利用ができます。 非常に種類が豊富なので利用している方も多いかと思いますが、実は 簡単に自作 する事もできます。 以降は具体的な実装方法に関してご説明させていただきます。 環境構築 開発に必要な物は以下2つだけ。 Google Chrome お好みのエディタ つまり目の前のPCに Chrome さえ入っていればすぐに開発を始められます。この敷居の低さも魅力ですね。 必要知識 Chrome 拡張機能 の実体は JavaScript 、HTML、 CSS といった要素です。なのでこの辺りの基本知識があれば開発は可能です。 サンプル ここからは実際に作って動かすまでをやってみたいと思います。 公式ページにもちゃんとした チュートリアル があるのですが、ここではより簡単なDOM操作を行うだけの 拡張機能 を作ってみたいと思います。 もしこの記事で興味が湧きましたら、ぜひ下記 チュートリアル もお試しください。 developer.chrome.com manifestファイルを作成する manifest. json は 拡張機能 に関する定義を管理する心臓部となるファイルであり、必ず用意する必要があります。 { " name ": " オリジナル入力チェック ", " version ": " 1.0 ", " description ": " 必須チェックを追加する。 ", " content_scripts ": [ { " matches ": [ " http://*/tutrial/testhtml/ " ] , " js ": [ " jquery-3.5.1.min.js ", " content.js " ] } ] , " icons ": { " 48 ": " icon.png " } , " manifest_version ": 2 } name 拡張機能 の名前です。特に機能に影響はないので任意で構いません。 拡張機能 の管理画面や公開する場合はストアの機能名として使われます。 version 機能のバージョンです。公開する場合は自動更新に関わるので重要ですが、内部利用であれば任意で構いません。 manifest_version manifestファイル自体のバージョンですが現時点で「2」固定です。 ※ここまでが必須の項目で後は用途に応じて足していきます。 description 機能の説明です。 拡張機能 の管理画面や公開する場合はストアでの説明として使われます。 content_scripts js 今回のようにDOM操作を行う場合、使用するjsファイルを記載します。複数記載可能です。 matches スクリプト を適用させたいURLを記載します。複数記載可能で ワイルドカード も使用可能です。例えば全ページに適用させたい場合は「 http://* 」とします。 icons 拡張機能 のアイコンとなる画像を指定します。サイズ別で16、48、128が指定できストアやファビコンなど異なる用途で使われますが、今回は48だけで十分です。 以上、今回必要なmanifestファイルの構造に関してご説明させていただきましたが、他項目の解説は公式サイトが詳しいのでご参照ください。 developer.chrome.com その他ファイルを作成する manifest. json で定義した JavaScript を作成します。今回はボタン押下時に名前が空欄の場合にアラートを出し、背景色を変えるようにします。 $( function () { console.log( "コンテントスクリプト開始" ); $( "#btn" ).on( "click" , function () { const name = $( "#name" ).text(); if (name == "" ) { alert ( "名前を入力してください" ); $( "#name" ).attr( "style" , "background-color: #FFAAFF;" ); } } ); } ); また 拡張機能 ではないですが入力チェックしたい仮想ページとして以下を用意しています。 <!DOCTYPE html> < html > < head > < meta charset = "utf-8" /> < meta http-equiv = "X-UA-Compatible" content = "IE=edge" /> < title > Page Title </ title > < meta name = "viewport" content = "width=device-width, initial-scale=1" /> < style > ul { list-style : none ; padding : 0 ; margin : 0 ; } li + li { margin-top : 1em ; } label { display : inline-block ; width : 90px ; text-align : right ; } .button { padding-left : 90px ; } button { margin-left : 0.5em ; } </ style > </ head > < body > < ul > < li > < div > 入力チェックを足してみる </ div > </ li > < li > < label for = "name" > 名前: </ label > < input type = "text" id = "name" name = "user_name" /> </ li > < li > < label for = "addr" > 住所: </ label > < input type = "text" id = "addr" name = "user_addr" /> </ li > < li class = "button" > < button id = "btn" type = "submit" > 送信 </ button > </ li > </ ul > </ body > </ html > これで必要な準備は全て終わりました。フォルダ構成としては以下のような状態となり、これが一つの 拡張機能 の単位となります。 sample ├─manifest.json ├─content.js ├─jquery-3.5.1.min.js └─icon.png ブラウザに取り込む いよいよ作成した 拡張機能 をブラウザに取り込みます。といってもこれも非常に簡単です。 chrome ://extensions/を開き（ ツールバー のアイコンでも開けます）右上の デベロッパ ーモードをオンにします。 「パッケージ化されていない 拡張機能 を読み込む」を選択し作成した 拡張機能 のフォルダを指定します。 これで作成した 拡張機能 が取り込まれました。 試しに仮想ページを開いてみるとURLがマッチしたため 拡張機能 が活性化し（ ツールバー のアイコンに色がつく）、期待通りの動作をする事が確認できるかと思います。 ちなみに本体が JavaScript なのでブラウザの デベロッパ ーツールで デバッグ もできますし、何かしら修正した場合は再度取り込まなくても管理画面の更新ボタンから更新ができます。 また配布に関しては公開する場合は審査等が必要になりますが、組織内で使う場合はフォルダを各自で取り込む事で実現可能です。 おわりに 今回は Chrome 拡張機能 でも最もシンプルな特定ページのDOMを操作する方法をご説明させていただきました。 基礎的な内容にはなりますが私が行ったようにこれだけでも業務効率化に繋げる事も可能ですし、今回は割愛しましたが公式 チュートリアル にあるようなバックグラウンド処理や外部通信を活用する事でより幅広い用途に応用する事が可能です。 繰り返しにはなってしまいますがお手軽に始められるのが何より魅力なので、ブラウザベースでの課題が生じた際には選択肢としてぜひご検討いただければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは、株式会社 ラク スで先行技術検証を行っている技術推進課のt_okkanです。 技術推進課では、新サービス立ち上げ時の開発速度アップを目的に、現在 ラク スでは採用されていない新しい技術の検証を行う、技術推進プロジェクトがあります。 今回はその技術推進プロジェクトで、モバイル クロスプラットフォーム について検証を行いましたので、その結果の報告を行います。 なお、別テーマの取り組みや、過去の取り組みに関しては、こちらからご覧ください。 tech-blog.rakus.co.jp モバイルクロスプラットフォーム 検証の目的 検証で使用したツール 省力化の定義 検証方法 検証結果 実装できなかった機能 NFC WebView クロスプラットフォームは開発を省力化できるか ライブラリについて 各フレームワークの所感 Ionic Framework 長所 短所 React Native 長所 短所 Flutter 長所 短所 フレームワークの選定基準 機能数 WebView スキル まとめ 参考 書籍 ブログ記事 公式ドキュメント モバイル クロスプラットフォーム 従来のモバイル アプリ開発 では、 iOS はSwiftやObjectiveCで、 Android は Java やKotlinで、各OSごとに別々の プログラミング言語 を用いて開発する必要がありました。 しかし、各OSごとに開発・テストするコストや、学習コストが高いことから、1つの ソースコード で異なるOS上でも同じ仕様、機能のアプリケーションを開発できるモバイル クロスプラットフォーム が開発されるようになりました。 現在、さまざまなモバイル クロスプラットフォーム の フレームワーク が存在しますが、大きく分けて3つに分類できます。 ハイブリット型 WebView上で動作し、HTML、 CSS 、 JavaScript で実装できる。Cordova、Ionic Framework、 Monaca など。 ネイティブ型 OSの描画エンジンを利用してUIを表示する。Xamarin、React Nativeなど。 独自レンダラー型 各OS上で動作する独自の レンダリング エンジンを利用してアプリを実行する。Flutter、Unityなど。 検証の目的 現在 ラクスのサービス の主軸は、ブラウザ上で動作する Webサービス です。 今後、既存のサービスのモバイルアプリへの移行や、新規サービスでのモバイル アプリ開発 があった場合、モバイル アプリ開発 にかかる 工数 を削減し開発の省力化を実現していきたいと思っています。 そのため、低コストでモバイル開発できる手法として、モバイル クロスプラットフォーム での開発を検討する必要があります。 そこで、本検証では クロスプラットフォーム でのモバイル開発がネイティブでのモバイル開発に比べ開発を省力化できるか、また省力化できる場合はどのツールを検討すべきかを示します。 Webサービス を主軸に置く企業の開発者の方にとって、 クロスプラットフォーム での開発を導入する上でのヒントになればと思います。 検証で使用したツール 本検証では、モバイル クロスプラットフォーム の各分類から フレームワーク を1つずつ選択し検証を行います。選択した フレームワーク はIonic Framework、React Native、Flutterになります。 Ionic Framework WebView上でWebアプリ（Angular、React、Vue）を実行する フレームワーク 。UI コンポーネント を提供し、ネイティブへのアクセスはCordovaやIonic社が開発しているCapacitorを利用して JavaScript とブリッジしている。 React Native JavaScriptEngine上でReactが実行される、ネイティブ型の フレームワーク 。Brideという機能を利用して、 JavaScript のコードから各OSに対応したUIやネイティブ API の実行を行っている。 Flutter Google が2018年にリリースした、独自レンダラ型の フレームワーク 。 Dart という プログラミング言語 で実装でき、各OS上で動作する Dart VM が画面の描画を行う。豊富なUIウィジェットが提供されており、ネイティブ機能へのアクセスは Dart のコードをネイティブコードに コンパイル して実行する。 省力化の定義 「 Webサービス 開発企業がモバイル開発を行う場合」という前提で、「省力化」の定義を立てました。 ※ネイティブ： iOS と Android のこと。開発言語はSwiftとKotlin ネイティブと同じ開発環境が整っていること ネイティブより学習コストが低い ネイティブより実装時間、コード量を削減できる ネイティブと同じ機能を実装できる クロスプラットフォーム での開発が上記の省力化の定義を満たせるのかを検証していきます。 検証方法 ネイティブ言語（Swift + Kotlin）と クロスプラットフォーム の各 フレームワーク （Ionic Framework + React Native + Flutter）で、同一の機能のサンプルアプリを実装し、その実装結果を比較しました。 以下のような実装した機能と比較した観点で比較し、省力化の定義を満たせているかを考察しました。 実装した機能 ローカルデータベース セキュアストレージ NFC カメラ Push通知 WebView 比較観点 比較観点 詳細 評価指標 比較対象 開発環境 エディター ◯：ネイティブと同等 △：ネイティブより劣っている ✖️：環境が提供されていない iOS ： Xcode Android ： Android Studio デバッグ ツール デザインツール ライブラリ評価機構 学習コスト プログラミング言語 ◯：ネイティブ1言語より低い △：ネイティブ1言語と同等 ✖️：ネイティブ1言語より高い iOS ：Swift Android ：Kotlin ライフサイクル 機能実装 実装時間 ◯：ネイティブより低い △：ネイティブと同等 ✖️：ネイティブより高い ネイティブの実装時間・コード量 コード量 機能実現 ◯：同じ機能を実装できる △：一部実装できない ✖️：全く実装できない iOS ：Swift Android ：Kotlin 検証結果 サンプルサプリを実装し、比較した結果は以下の通りです。 ※FE経験：Angular、React、Vueの経験があるフロントエンド経験者 ※BE経験： Java などの オブジェクト指向 プログラミングの経験のあるバックエンド経験者 ※実装時間・コード量に関しては本検証での数字です ※コード量は実装した行数と単語数から算出しました 比較観点 Ionic Framework React Native Flutter エディター ◯ Visual Studio Code ◯ Visual Studio Code ◯ Visual Studio Code Android Studio デバッグ ツール △ ブラウザDev Tools ◯ React Native DevTools ◯ Flutter Dev Tools デザインツール △ ブラウザDev Tools Hot reload △ ブラウザDev Tools Hot reload ライブラリ評価機構 ✖️ △ React Native Directory ◯ pub.dev プログラミング言語 学習コスト FE経験：◯ BE経験：△ TypeScript、 JavaScript 、Angular、React、Vue FE経験：◯ BE経験：△ TypeScript、 JavaScript 、React FE経験：△ BE経験：◯ Dart ライフサイクル学習コスト FE経験：◯ BE経験：△ Angular、React、Vue FE経験：◯ BE経験：△ React FE経験：△ BE経験：△ Flutter 実装時間 ◯ -46% ◯ -46% ◯ -67% コード量 ◯ -30% ◯ -25% ◯ -45% 機能実現 △ NFC 、WebView △ NFC ◯ 実装できなかった機能 NFC Ionic FrameworkとReact Nativeで、 iOS でType-Fの ICカード を読み込むことができなかった。 今回 Icoca を ICカード で使用し読み込みを実装したが、使用したライブラリがNDEFフォーマット以外のフォーマットに対応していなかったため、実装することができなかった。 Suica や Icoca などの Felica Standardのフォーマットに対応したライブラリを調査したが、見つけることができませんでした。 WebView Ionic Frameworkで、WebViewを実装することができなかった。Ionic Frameworkはアプリ起動時に作成されるWebView上で実行されているため、Ionic Frameworkから起動されているWebView以外のWebViewを作成することができません。 Ionic Framework上にOS内蔵ブラウザを表示してWebページを描画できますが、WebViewと比べると機能が限られます。 クロスプラットフォーム は開発を省力化できるか 本検証では、 クロスプラットフォーム はモバイル開発を省力化できる 、と結論しました。 理由としては以下の点が挙げられます。 実装時間、コード量を削減できる 学習コストは1つのネイティブ言語を学習するコストより低い 開発環境は同等、または劣っているものの代替手段がある 一部実装できない機能があるものの、ネイティブと同じ機能を実装できる また検証の結果から、 クロスプラットフォーム を導入する際はまずFlutterを検討すること 、としました。 Flutterが最も欠点が少なく汎用的であることから、まずはFlutterの検討を進めることをオススメします。 Dart の学習コストが、Ionic FramewrokやReact Nativeが Web標準 技術を使用できることと比較するとやや高いものの、元々は JavaScript の代替言語として開発された経緯もあり、実装しやすく高機能な プログラミング言語 です。また、以下で説明するようにライブラリの充実度でも、他の フレームワーク よりも優位であることがわかります。 ライブラリについて クロスプラットフォーム でネイティブの機能を利用する場合は、基本的には各 フレームワーク で提供されているライブラリを利用します。 そのため、ライブラリの質が実装や運用のコストに直結すると考えました。 そこで各プラットフォームでライブラリがどのように管理されているのか、調査・比較しました。 Ionic Framework React Native Flutter ライブラリ評価機構 なし React Native Directory pud.dev 評価方法 なし Directory Score pub points 実装で使用したライブラリ数 25 29 11 Ionic Framework ライブラリの評価機構が提供されていない。ライブラリの評価基準としては、公式・コミュニティ・ サードパーティ であるか、ドキュメントが充実しているか、を自身で調査する必要がある。 React Native React Native Directoryで管理されており、Directory Scoreで評価されている。評価方法は GitHub のfork、star、download数 React Native Directoryからの推奨 最終更新日が30日以内 180日以内に更新されているか open状態のissueが75個以内 である。 リポジトリ の評価が主な評価指標となっている。 Flutter pub.devで管理されており、pub pointsで評価されている。評価方法は、 Dart の規約にしたがっていること 依存関係を明記しており、全てのURLが HTTPS を利用していること OSI 認証ライセンスを使用していて、LICENSEファイルを提供している CHANGELOG ファイルを提供している ドキュメントを提供していること サンプルコードを提供している Publicな API のうち、20%以上のドキュメントを公開している Dart の静的解析に合格している 最新の実行環境で動作すること 最新のStableの Dart とFlutterのバージョンで動作すること である。ドキュメントの充実度、コードの動作保証などで評価を行っている。 上記の結果の通り、Flutterではpub pointsの値が高いほどライブラリが充実しており実装コストが低かったです。また、コード解析や最新版の実行環境での動作確認など、アプリの運用面でも助けになる情報が多い印象です。 React Nativeでは評価機構の仕組みはあるものの、Flutterと比べるとライブラリの人気度で評価されていると感じました。また、Ionic Frameworkは評価機構が存在しません。両方の フレームワーク に共通していることですが、実装してみてもライブラリによってはドキュメントが不足しており、ライブラリのコードを自身で解析して実装する必要もありました。また、実現したい機能をそのライブラリで実装できるかが判断できず、実際にコードを動かしてみて確認する必要があるものもありました。 また、今回の検証で使用したライブラリ数はFlutterが最も少なく、少ないライブラリ数で実装できることも挙げられます。Flutterが高機能であるため、React NativeやIonic Frameworkではライブラリが必要な機能（ ルーター など）をライブラリなしで使用できます。 上記の面でもFlutterが クロスプラットフォーム の中では最も優位であるという結論に至りました。これ以外でも、UIウィジェット数なども影響しています。 各 フレームワーク の所感 Ionic Framework 長所 まずは、 開発速度が速い ことが挙げられます。検証結果でも最も早くサンプルアプリを実装することができました。Webの技術を流用できることがその理由であると考えられます。またHTML、 CSS 、 JavaScript で画面を構築できるため、 クロスプラットフォーム の中では最も UIの自由度が高い と思いです。またIonic FrameworkはPWAにも対応しており、同じコードをモバイルと PWAにビルドしデプロイ できます。 短所 まずは、ライブラリの評価機構がないことが挙げられます。ライブラリのドキュメントが不足していて、実際に実装しないと実現できる機能を把握できないケースが多々ありました。他の フレームワーク にはライブラリの評価機構があることから、ここは明確な短所であると言えます。 機能面ではWebViewを実装することができないことが挙げられます。仕組み上すでにWebView上で実行されているため、新たにWebViewを実装することができません。 クロスプラットフォーム でWebViewを利用する場合は、React NativeかFlutterを利用してください。 React Native 長所 まずは、各OSに準拠した ネイティブのUIを描画できる ことが挙げれらます。 iOS ではHuman Interface Guidelines仕組み上WebViewをで、 Android では Material Design で表示されます。OSのUIでアプリを表示したい場合はReactNativeが有効になります。 また Reactの知識やエコシステムを利用できる ことも挙げられます。ライブラリに関してはDOM操作を必要とするもの以外は基本的に、Reactのライブラリを流用できます。そのため、すでにWebアプリがReactで実装されている場合はコードを移植することもできます。 短所 まずはBridge機能によるパフォーマンスの低下が挙げられます。頻繁にネイティブ機能を利用する場合や、大量データを表示する場合、Bridge機能に負荷がかかりパフォーマンスが低下する可能性があります。開発元のReact Native Communityもこの問題を認識しており、今後Bridge機能を廃止する アーキテクチャ 変更を予定しています。 また、いまだメジャーリリースがないことも不安要素として挙げられます。 Flutter 長所 まずはネイティブ同等に 開発環境が整っている ことが挙げられます。Dev Toolsがかなり優秀でさらにHot reload機能もあることから、他の フレームワーク と比べて開発環境が圧倒的に整っています。また ライブラリ評価機構が整っている ことが挙げられます。pub pointsが高いライブラリを利用すると、 API リファレンスが整っており実装がしやすいです。また不具合時の調査も他の フレームワーク と比べて、行いやすいと思います。 Dart VM がUIの描画行っており、Bridge機能を利用しないため パフォーマンスが良好 であることも挙げられます。開発元が Google で開発に力を入れていることから、将来性にも期待できます。 短所 欠点はあまりないのですが、 Dart の学習コストがかかることが挙げられます。他の フレームワーク がWeb技術を使用できること比べると、学習コストが高くなります。ただ Dart は オブジェクト指向 の プログラミング言語 であり、 JavaScript の機能も多数取り入れているため、そこまで学習コストは高くないかと思います。 また、OSの標準UIで画面を描画する場合に実装コストが高くなることが挙げられます。FlutterはデフォルトでMaterial Desginで画面が描画されます。 iOS はHumanInterfaceGuidelinesで表示したい場合は、実行されているプラットフォームによって表示する ウィジェット を切り替える必要があるため実装コストが高くなります。この場合はReact Nativeを利用した方が有効かと思います。 フレームワーク の選定基準 機能数 機能数が多いもしくは不確定の場合はFlutterを利用してください。Flutter自体の機能とUIウィジェット数が他の フレームワーク よりも多く、パフォーマンスも安定しています。React NativeやIonic Frameworkは機能数が多い場合、 JavaScript のBridgeに負荷がかかりパフォーマンスが悪くなる可能性があります。 機能数が少なく、特定の機能しか実装しない場合は、Ionic FrameworkかReact Nativeを選択して下さい。 Web標準 機能を利用できるため開発コストを低く抑えることができます。 WebView Webサービス 企業では、既にリリースされているWebアプリをWebViewを利用してモバイルアプリで表示したい、という要件が出てくると思います。WebViewを利用する場合は、FlutterかReact Nativeを利用してください。Ionic Frameworkは仕組み上、WebViewを実装することができません。FlutterかReact Nativeかを選択する場合は、基本Flutterを選択してください。 スキル Angular、React、Vueなどの JavaScript フレームワーク の経験がある場合は、Ionic FrameworkかReact Nativeを選択してください。SPAの知識を流用でき、開発速度は一番速いです。しかし、Ionic FrameworkやReact Nativeには実装できない機能やライブラリが提供されていない機能がありますので、導入する前に調査をする必要があります。 Java などのバックエンドでの開発の経験がある場合は、Flutterを選択してください。 オブジェクト指向 で実装できるので学習コストは低いかと思います。 まとめ 本検証でのまとめです。 モバイル クロスプラットフォーム はモバイル開発を省力化できるかを検証しました。 検証方法としては、ネイティブとモバイル クロスプラットフォーム のツールで、同じ機能のサンプルアプリを実装し、その実装結果を比較し考察しました。 結論は以下のようになりました。 モバイル クロスプラットフォーム は ラク スにおいてモバイル開発を省力化できる 実装時間・コード量を削減でき、開発環境が整っており、機能を実装できる ツールによっては実装できない機能があるので把握すること フレームワーク の選定は、まずはFlutterを検討する 実装する機能数やスキルセットから、 フレームワーク の選定を行う 「開発環境」「UI」「ライブラリ」などでFlutterが最も欠点が少なく汎用的であることがわかりました。そのため、モバイル クロスプラットフォーム を検討する際は、まずFlutterの導入を考えてください。 参考 書籍 基礎から学ぶFlutter (C&R研究所, 2020) React Native ~JavaScriptによるiOS/Androidアプリ開発の実践 ( 技術評論社 , 2020) Ionicで作るモバイルアプリ制作入門 (C&R研究所, 2019) ブログ記事 React Nativeの Re-architecture について。 (投稿日：2020/02/27) Flutter vs Native vs React-Native: Examinig performance (投稿日：2020/05/11) 公式ドキュメント Flutter React Native Ionic Framework React Native Directory Score pub.dev Package scores & pub points エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは。開発エンジニアの amdaba_sk（ ペンネ ーム未定）です。 前回は「 機械学習をコモディティ化する AutoML ツールの評価 」、だいぶ間が空きましたが前々回は「 機械学習のライブラリ・プラットフォームをいくつか試した所感まとめ 」と、続けて 機械学習 をテーマとした記事を書きました。 これらの記事では 機械学習 モデルを作るまでのことしか言及していませんが、 機械学習 モデルは作ってそれで終わりのものでもありません。使ってなんぼのものなんです。かみせんプロジェクトとしての調査範囲からは外れますが、せっかくモデルを作ったならそれを使ったアプリも簡単なものでいいので作ってみたい。そう思うのは開発者として自然な感情ではないでしょうか。 というわけで今回は、「 機械学習 モデルを組み込んだ Web アプリを Python 初心者が作ってみた」という個人的な興味からやってみた系記事でございます。 なお後に述べるようにアプリの実装言語は Python を採用しますが、私はかみせんプロジェクトで初めて Python を触ったばかりの初心者です。 Python らしくないコードを書いている可能性もありますので、その点ご了承ください。 また「かみせんってなんやねん」と思われた方は ↓ のリンクからかみせんカテゴリの記事をご覧ください。 tech-blog.rakus.co.jp もくじ もくじ どんなアプリを作る？ どんな分類をするのか？ どうやってアプリを作る？ 機械学習フレームワークは何にする？ 実装言語と Web アプリのフレームワークは何にする？ プロジェクト構成はどんな感じにする？ 機械学習モデルはどう作る？ Web アプリ本体はどう作る？ 動かしてみる① 仕様をちょっと変えてみる 動かしてみる② まとめ 参考 どんなアプリを作る？ なるべくシンプルなものがよいですね。あまり時間はかけたくないので。 過去 2 記事で主に取り扱った 機械学習 のタスクは、分類でした。ということは、ユーザーが送信したデータを 機械学習 モデルで分類し、その結果を提示するだけというのが簡単で良さそうです。また画面を作るのは面倒なので JSON API ということにしましょう。 分類するデータの形式は、またもや過去 2 記事を見ると、ひとつはテキスト、ひとつはテーブルを使っています。テー ブルデー タだと複数のフィールドを埋めてやらないといけないので、作った後お試しで使ってみる時にめんどくさそうですね。テキストにしましょう。 結局「 機械学習のライブラリ・プラットフォームをいくつか試した所感まとめ 」の冒頭で構想したものと似たようなアプリになりました。 分類したいテキストを含む JSON を受け付ける 送られてきたテキストが既存のカテゴリのどれに相当するかを推測する 分類の結果を JSON に入れて返す どんな分類をするのか？ テキストを何のカテゴリに分類してくれるのかもここで考えておきましょう。要するにどんな学習データを使うのかという話ですが、今回は livedoor ニュース コーパス を使わせていただくことにします。 livedoor ニュース コーパス は「 livedoor ニュース」のうち、 クリエイティブ・コモンズ ライセンスが適用されるニュース記事を集めたもので、株式会社ロンウイットさんによって配布されています。 ここ からダウンロードすることができます。 ニュース コーパス には以下の 9 カテゴリのニュース記事が格納されています。 トピックニュース Sports Watch IT ライフハック 家電チャンネル MOVIE ENTER 独女通信 エス マックス livedoor HOMME Peachy これを学習することで、与えられたテキストが 9 カテゴリのうちどれに当てはまりそうかを推測することが出来るでしょう。 どうやってアプリを作る？ 機械学習 フレームワーク は何にする？ 機械学習 モデルを作る際の フレームワーク はなんだかんだ言って scikit-learn が使いやすいです。今回の主目的は 機械学習 モデルを作る部分ではないので、ここにあまり力を入れません。凝ったことは考えず、scikit-learn を使うことにします。 実装言語と Web アプリの フレームワーク は何にする？ 機械学習 モデルが Python の フレームワーク で作られるとなると、それを使うアプリの方も実装言語は Python を使うのがやりやすいです。本記事の冒頭でも述べたように Python で Web アプリなんて作ったことはありませんが、まあ、簡単なものを試作するくらいなら何とかなるでしょう。 Python で Web アプリの フレームワーク といえば、少し調べると以下の二つが代表的なようです。 Django : フルスタ ックな Web アプリ フレームワーク Flask : マイクロな Web アプリ フレームワーク 今回の用途では Flask の方が手軽で良さそうです。が、ここではそのどちらでもなく、 FastAPI を選択します。 Web アプリの フレームワーク を調べていた際に「 Python 製 Web フレームワークを Flask から FastAPI に変えた話 」という記事を見つけました。それによれば、 しかし、どちらの フレームワーク を使う場合でも下記のような機能を使おうとすると プラグイン や サードパーティ の助けを借りる必要があります。 OpenAPI JSON Schema GraphQL WebSocket タイプヒントを使ったバリデーション 非同期処理 CORS の設定 リバースプロキシとの連携サポート Django も Flask も近年登場したサーバサイドの技術や Python 3 の新機能に対するネイティブサポートがちょっと弱いです。 とのことなのです。 Django も Flask についても私自身はあまり詳しく調査していませんが、この記事を信ずるのであればどちらを選んでも プラグイン の選定作業が加わることになってあまり楽できそうにないです。特に JSON API を作ろうとしているため、やっぱり OpenAPI や JSON Schema は入れたいです。 また FastAPI のドキュメントを見ていると、なんだかこれで作れそうな気がしてきました。それに タイプヒントを使ったバリデーション も、とっても好みです。 というわけで Web アプリの フレームワーク は FastAPI を使うことにします。 プロジェクト構成はどんな感じにする？ 今回の Web アプリのプロジェクト構成は下のようなものにしました。これは初めに完全に決めたというよりも、作りながら試して結果こうなったという感じです。 my_ml_app ├── Pipfile ├── Pipfile.lock ├── text ... 学習データ置き場 ├── models ... 機械学習モデル置き場 ├── tokenizer.py ... 学習・アプリ共通依存モジュール ├── training.py ... 学習スクリプト └── my_ml_app.py ... Web アプリ本体スクリプト 「 ゼロから学ぶ Python 」というオンライン学習サイトによれば、「 The Hitchhiker’s Guide to Python 」というサイトで解説されている推奨構成に従うのがよいらしいです。今回の構成はあまり推奨構成に則っていないかもしれませんが、参考にはさせていただきました。 「 Cookiecutter 」等を使うことでテンプレートから ディレクト リ構成などひな型は作れるのですが、どのテンプレートがいいのかよくわからず結局上の構成は手で作っています。 機械学習 モデルはどう作る？ 機械学習 モデルの作成 スクリプト は training.py です。 詳細な内容は今回の主眼ではないので省略しますが、Web アプリで使うために出来上がったモデルを シリアライズ してファイルに保存しておく必要があります 1 。 モデル作成の概略は以下の通りです。 形態素解析 器： Janome ベクトル化方式： Tf-Idf 分類 アルゴリズム ： 単純 ベイズ 分類器 学習の際デー タセット を分割し、一部を性能測定に使っています。結果は以下の通りでした。モデルの性能は今回重要ではないのですが、まあ、そこそこなモデルになっているのではないでしょうか。 precision recall f1-score support dokujo-tsushin 0.68 0.91 0.78 218 it-life-hack 0.92 0.89 0.90 218 kaden-channel 0.89 0.93 0.91 216 livedoor-homme 1.00 0.25 0.40 128 movie-enter 0.84 0.97 0.90 218 peachy 0.80 0.71 0.75 210 smax 0.86 1.00 0.93 217 sports-watch 0.89 1.00 0.94 225 topic-news 0.98 0.74 0.84 192 accuracy 0.85 1842 macro avg 0.87 0.82 0.82 1842 weighted avg 0.87 0.85 0.84 1842 Web アプリ本体はどう作る？ Web アプリ本体の スクリプト は my_ml_app.py です。とりあえず全文を見てみましょう。 from enum import Enum from fastapi import FastAPI from pydantic import BaseModel, Field import joblib from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.naive_bayes import MultinomialNB class CategoryName ( str , Enum): topic_news = 'topic-news' # トピックニュース sports_watch = 'sports-watch' # Sports Watch it_life_hack = 'it-life-hack' # ITライフハック kaden_channel = 'kaden-channel' # 家電チャンネル movie_enter = 'movie-enter' # MOVIE ENTER dokujo_tsushin = 'dokujo-tsushin' # 独女通信 smax = 'smax' # エスマックス livedoor_homme = 'livedoor-homme' # livedoor HOMME peachy = 'peachy' # Peachy class MyClassifier (): clf: MultinomialNB vec: TfidfVectorizer def __init__ ( self, classifier: MultinomialNB, vectrizer: TfidfVectorizer ): self.clf = classifier self.vec = vectrizer def classify (self, targetText: str ): v = self.vec.transform([targetText]) return self.clf.predict(v)[ 0 ] class ClassifyRequest (BaseModel): text: str = Field(..., max_length= 10000 ) app = FastAPI() my_classifier = MyClassifier( joblib.load( 'models/livedoor_tfidf_mnb.model' ), joblib.load( 'models/livedoor_tfidf.model' ) ) @ app.post ( '/classify' , response_model=CategoryName) async def classify (req: ClassifyRequest): return my_classifier.classify(req.text) 実にシンプルですね。シンプル過ぎて if も for も使う余地がありませんでした。 動かしてみる① Python 3 が使える環境にプロジェクトをデプロイ 2 し、プロジェクトの ディレクト リに移動。その後起動コマンドを実行します。 # pipenv run uvicorn my_ml_app:app --port 80 --host 0.0.0.0 --reload INFO: Uvicorn running on http://0.0.0.0:80 (Press CTRL+C to quit) INFO: Started reloader process [521] using statreload INFO: Started server process [528] INFO: Waiting for application startup. INFO: Application startup complete. サーバーが起動しました！ FastAPI は SwaggerUI をホストしていますので、そこから API を動かしてみましょう。 SwaggerUI にアクセスしたところ 「Try it out」で本記事の冒頭部分を分類してみます。 { " text ": " 機械学習モデルを組み込んだ Web アプリを Python 初心者が作ってみた \n こんにちは。開発エンジニアの amdaba_sk（ペンネーム未定）です。 \n 前回は「機械学習をコモディティ化する AutoML ツールの評価」、だいぶ間が空きましたが前々回は「機械学習のライブラリ・プラットフォームをいくつか試した所感まとめ」と、続けて機械学習をテーマとした記事を書きました。 \n これらの記事では機械学習モデルを作るまでのことしか言及していませんが、機械学習モデルは作ってそれで終わりのものでもありません。使ってなんぼのものなんです。かみせんプロジェクトとしての調査範囲からは外れますが、せっかくモデルを作ったならそれを使ったアプリも簡単なものでいいので作ってみたい。そう思うのは開発者として自然な感情ではないでしょうか。 \n というわけで今回は、「機械学習モデルを組み込んだ Web アプリを Python 初心者が作ってみた」という個人的な興味からやってみた系記事でございます。 " } これを送信すると、結果が以下のように返ってきます。 " it - life - hack " どうやら本記事は「IT ライフハック 」に入ってそうな記事だそうです。 仕様をちょっと変えてみる ところで、送信したテキストがどのカテゴリに相当するのかをひとつだけ返してくるだけでは、そっけなく感じますね。 実際出来上がったものを見ると、欲ができてます。以下のようにちょっと仕様を変えてみましょうか。 どのカテゴリにどの程度の確率で分類されるのかのリストを返す その際、分類される確率の高い順にカテゴリを並べる この仕様変更は幸い Web アプリ側だけで対応できます。 my_ml_app.py を以下のように修正しましょう。 @@ -1,4 +1,5 @@ from enum import Enum +from typing import List from fastapi import FastAPI from pydantic import BaseModel, Field @@ -30,17 +31,30 @@ def classify(self, targetText: str): v = self.vec.transform([targetText]) - return self.clf.predict(v)[0] + result_proba = self.clf.predict_proba(v)[0] # <1> + order = (-result_proba).argsort() # <2>, <3> + ordered_cats = self.clf.classes_[order] # <4> + ordered_probas = result_proba[order] # <4> + return [ + { + 'category': cat, + 'probability': proba + } for cat, proba in zip(ordered_cats, ordered_probas) # <5> + ] # <6> class ClassifyRequest(BaseModel): text: str = Field(..., max_length=10000) +class ClassifyResponse(BaseModel): + category: CategoryName + probability: float + app = FastAPI() my_classifier = MyClassifier( joblib.load('models/livedoor_tfidf_mnb.model'), joblib.load('models/livedoor_tfidf.model') ) -@app.post('/classify', response_model=CategoryName) +@app.post('/classify', response_model=List[ClassifyResponse]) async def classify(req: ClassifyRequest): return my_classifier.classify(req.text) やることが増えたので少しコードも複雑になりました。ポイントを説明します。 推論実行のメソッドを predict から predict_proba に変更したことで、カテゴリ毎の確率を得ることが出来ます。並び順は分類器の classes_ 属性と一致しています。 predict_proba から返された配列に対して負符号を付けることで、要素の正負をすべて反転しています。これは次のステップで降順ソートにするためです。 要素の正負を反転した結果に対して numpy.argsort を行えば、値の大小に従ってソートした時の配列インデックスの変化を返してくれます。 Python ではリストや配列に対して [] にインデックスのリストを入れると、各インデックスに対応する値を指定した順序で返してくれます。ここでは 3 で得たインデックスのリストを使って、カテゴリのリスト（ self.clf.classes_ ）とカテゴリ毎の確率（ result_proba ）を並べ替えています。 zip 関数を使ってカテゴリと対応する確率をペアにしています。これで別々のリストになっていたものが一つにまとまって扱いやすくなりました。 return 以降はリスト内包表記と言われる構文です。5 で作成したリストのそれぞれの要素を、dict に詰め替えて新しいリストを作っています。この部分は for 文を使って下のように書くこともできます。 ret = [] for cat, proba in zip (ordered_cats, ordered_probas): ret.append({ 'category' : cat, 'probability' : proba }) return ret リスト内包表記と for 文、どっちが読みやすいかは人によるでしょう。私自身は、リスト内包表記は文ではなく式であるという点でリスト内包表記の方が好みです。また実行速度はリスト内包表記の方が若干速いらしいですね（ Pythonのリスト内包の速度 ）。 動かしてみる② サーバーを再起動して、SwaggerUI の画面を再度開きます。先ほどと同様にして「Try it out」で本記事の冒頭部分を分類してみましょう。結果は以下のようになりました。 [ { " category ": " it-life-hack ", " probability ": 0.3086756411902118 } , { " category ": " smax ", " probability ": 0.15842430053076112 } , { " category ": " dokujo-tsushin ", " probability ": 0.13005882520629944 } , { " category ": " kaden-channel ", " probability ": 0.1221002790185913 } , { " category ": " peachy ", " probability ": 0.11371989611168741 } , { " category ": " movie-enter ", " probability ": 0.04808770370861974 } , { " category ": " sports-watch ", " probability ": 0.04605206014172084 } , { " category ": " topic-news ", " probability ": 0.03650002186757273 } , { " category ": " livedoor-homme ", " probability ": 0.036381272224538394 } ] どうやら本記事は、9 カテゴリ内では「IT ライフハック 」に入ってそうではあるけれども、確率は 3 割程度でそんなに高くないようです。仕様変更によってより詳しい結果を知ることができるようになりました。 まとめ 以上、 機械学習 モデルを組み込んだ Web アプリを Python 初心者が作ってみました。意図してシンプルな仕様にしたこともあり、また フレームワーク の助けもありとっても簡単に動くものが作れました。 今回は 機械学習 モデルを組み込んだ Web アプリ を作りましたが、 機械学習 モデルを使わない場合も基本的な作り方はあまり変わらないのではないかと思います。これを読んでくださった方が Python で Web アプリを作る時、何かの参考になれば幸いです。 参考 livedoor ニュース コーパス - https://www.rondhuit.com/download.html scikit-learn - https://scikit-learn.org/stable/index.html Django - https://djangoproject.jp Flask - https://flask.palletsprojects.com/en/1.1.x/ FastAPI - https://fastapi.tiangolo.com/ja/ Python 製 Web フレームワーク を Flask から FastAPI に変えた話 - https://note.com/navitime_tech/n/nc0381517d067 ゼロから学ぶ Python - https://rinatz.github.io/python-book/ The Hitchhiker’s Guide to Python - https://docs.python-guide.org/ Cookiecutter - https://cookiecutter.readthedocs.io/en/1.7.2/ Python のリスト内包の速度 - https://qiita.com/intermezzo-fr/items/43f90e07e4cebe63aeb6 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 実は今回大ハマりして一番苦労したのはこの部分だったりするのですが、話が逸れるので割愛します。 ↩ 今回はWSL2+Dockerでやっています。 ↩

はじめに みなさんこんにちはa_renrenです。 今年は、 新型コロナウイルス によって以前より家にいる時間が増え、何か家でできる趣味を探している方が増えているのではないしょうか。 今回は、そのような方におすすめのラズパイについてご紹介していきたいと思います。また、これからラズパイの購入を考えいる方やラズパイは聞いたことがあるけどどんなことができるかあまり知らない方も是非読んでみてください。最後に簡単にラズパイとLINEを連携する方法を載せています。少しでもラズパイに興味を持っていただけたら幸いです。 はじめに ラズパイとは ラズパイの種類 Raspberry Pi4 model B Raspberry Pi Zero ラズパイでできること カメラとして活用 プログラミング学習 センサーと連携 実際に触ってみた ラズパイ購入 セットアップ LINE Notify設定 メッセージの送信 終わりに 参考 ラズパイとは ラズパイとは正式名称を Raspberry PI ( ラズベリー パイ)といい、イギリスの ラズベリー 財団によって開発された シングルボードコンピュータ です。 シングルボードコンピュータ とはむき出しの一枚のプリント基板の上に、電子部品と最低限の入出力装置を付けただけのとてもシンプルなコンピュータです。 もともとは子供向けの安価な教育コンピュータとして開発されましたが、今では、コンピュータやプログラミングの学習のみならず電子工作やロボット、産業向けに利用されるようになってきました。 ラズパイの種類 初めてのラズパイが発売されてから10年近くの年月が経ち、ラズパイの種類もどんどんと増えてきました。 今では大きく分けて5種類のラズパイが発売されています。 ここでは、一番性能が高い最新のモデルと一番安いモデルを紹介します。 Raspberry Pi4 model B 国内で2019年11月末に発売された最新モデルです。 従来のモデルとの大きな違いは メモリの選択が可能(2GB、4GB、8GB) CPUのクロック数が1.2GHzから1.5GHzとなり、より高速化 microHDMIを2つ搭載 などがあげられ、全体的にコンピュータとしての性能が高まりました。 メモリの選択が可能になり、本格的なサーバの運用などに対応することが可能となったことでラズパイでできる選択肢の幅が広がりました。 従来のモデルとの互換性が低かったり、消費電力が増えたりなどのデメリットがいくつかあるようですが、 これからラズパイを購入しようとしている人はこのモデルを買えば問題はないと思います。 メモリに関しては、値が高ければ性能も高くなりますが値段も高くなるため、お財布と相談しながら決めましょう。 ちなみに私は4GBのメモリを搭載しているものを購入しました。 www.raspberrypi.org Raspberry Pi Zero 全モデルの中で一番安価なモデルで600円程度で買うことができます。 より多くの人にラズパイを体験してもらうことを目的として作られたモデルです。 ほかのモデルと比べると性能は劣りますが、あまりお金をかけずに楽しみたいという人におすすめです。 www.raspberrypi.org 最近だと、ラズパイとキーボードが一体化した Raspberry Pi 400というものが登場しました。 日本では2021年以降に発売予定のため、気になる方はぜひ買ってみてください。 www.raspberrypi.org ラズパイでできること ラズパイでは、デスクトップPCで行うインターネットの閲覧、ゲームのプレイから電子工作など多くのことを行うことができます。 皆さんの発想次第で様々な使い方ができます。 今回はラズパイでできる様々なことの中からいくつかおすすめを紹介いたします。 カメラとして活用 ラズパイにはカメラが搭載されていませんが、別途カメラモジュールを購入することでカメラとして機能させることができます。 一口にカメラと言っても、設定を行えば監視カメラやセンサーカメラ、チャットに決まった時間に自動で撮れた写真が送られてくるような定点カメラなど様々な使い方ができます。 追加で費用がかかりますが、汎用性が高く、設定が難しくないため初心者にもおすすめです。 nn-hokuson.hatenablog.com プログラミング学習 もともと学習目的で作られているため、 Python やScratchが標準でインストールされおり、初心者が躓きやすい導入部分がなく手軽に始めることが可能です。 また、 Linux の学習をこれから始めようとしている方にもおすすめです。 Linux のコマンドなど Linux を学習しようとお手元のパソコンに Linux をインストールする必要がありますが、何かしらトラブルがあった場合に一人で解決することが難しいことが多く途中で断念してしまう人は少なくないと思います。 ラズパイではOSを選択することができ、その中に Debian という Linuxディストリビューション が元となったRaspbianというOSがあります。 RaspbianをOSとして選択してラズパイを使用することで、簡単に Linux の学習を始めることができます。 センサーと連携 ラズパイには様々なセンサーモジュールが用意されています。 いくつかセンサーをご紹介します。 水温センサー 湿度センサー 人感(モーション)センサー ガスセンサー 光センサー 赤外線センサー タッチセンサー サウンド センサー 他にも様々なセンサーが用意されています。 水温センサーとラズパイを掛け合わせることで自宅の水槽の水温の管理、人感センサーと掛け合わせると、人感センサーが働いた時だけライトの点灯や防犯カメラの起動、ディスプレイの起動などを行うことができます。 また、これらのセンサーがまとまっているキットも発売されているため、色々試してみたい方にはおすすめです。 https://www.amazon.co.jp/gp/product/B0716B778T/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=B0716B778T&linkCode=as2&tag=osusume8net01-22&linkId=93e83ae8d992e07a1ec4d0db9283a2ff www.amazon.co.jp 実際に触ってみた 今回は、ラズパイとLINEを連携してメッセージを送れるようにしてみます。 ラズパイ購入 私は、付属品がセットになっているこちらのスターターキットを Amazon で購入しました。 www.amazon.co.jp これから始める際に必要な HDMI ケーブルや microSD カードなどの部品がそろっているため、簡単に始めることができます。 また、本来であれば microSD カードにラズパイ用のOSを書き込んでおく必要がありますが、このスターターキットには、すでにRaspbianなどのOSが書き込まれた microSD カードが付属しているため、面倒な手間が省けます。 しかし、このスターターセットだけでは、ラズパイを操作することはできません。スターターセットに加え以下のものが必要となります。 キーボード マウス ディスプレイ 一応ディスプレイがなくともテレビなどで代用することができます。 今回購入したスターターキットの中身はこのような感じでした。 ラズパイ本体(4GB RAM) microSD カード(32GB) スイッチ付き電源アダプタ HDMI ケーブル×2 冷却ファン×2 ケース ヒートシンク ×3(取付済み) MicroSD カードリーダー 取り扱い説明書 ケースに取り付けるとこんな感じです。 ケースの上部に冷却ファンを取り付けることができ、本体に電源を入れるとファンが回り始めます。 ケースの取り付け方は説明書がありましたが、あまり詳しく書かれていないのとケースが堅かったため、取り付けに少し苦労しました。 このケースは、3つに分解することができるので、全部分解してから取り付けることをおすすめします。 セットアップ ラズパイの組み立てが終われば次は、モニターなどを接続してOSのインストールを開始します。 付属の microSD カードを差し込めば簡単にOSのインストールを行うことができます。 今回はRaspbianを選択しました。 こちらの画面で言語の設定と wifi の設定が可能となっています。 左上のインストールをクリックするとインストールが開始します。 インストールが完了するとパスワードなどの各種初期設定が開始されます。 こちらの設定は後でも行うことができますのでスキップしていただいても大丈夫です。 初期設定が終わるとこちらの画面が出てくるかと思います。 ひとまずセットアップはこれで終了です。 LINE Notify設定 一通り設定が終われば実際にLINEと連携してみましょう。 まずは、LINE Notifyにログインして トーク ンを発行します。 LINE Notifyは、 Webサービス やアプリなどに来た通知を簡単にLINEに送信することができるサービスです。 以下からログインすることができます。 LINE Notify ログインできたら、右上に名前が表示されるので、そちらをクリックし、マイページを選択してください。 下にスクロールするとアクセス トーク ンの発行があるので「 トーク ンを発行する」から トーク ンを発行します。 トーク ン名と通知を送る相手を選択します。 通知はグループにも送ることができます。 今回は、 トーク ン名を「ラズパイ」にして、送信相手は自分のアカウントを選択します。 選択後、「発行する」をクリックしてください。 すると トーク ンが発行されるのでそれをどこかにメモしておいてください。 以上で トーク ンの発行は終わりです。 メッセージの送信 次は、ラズパイの操作に入ります。 以下のコマンドをホーム画面の左上にあるLXTerminalで実行することでLINEにメッセージが送れます。 送るメッセージはmessage=の右側で指定することができます。 今回は、Helloというメッセージを送信してみます。 $ curl https://notify-api.line.me/api/notify -X POST -H "Authorization: Bearer XXXXXXXX" -F "message=Hello" XXXXXXXXの箇所を先ほど発行した トーク ンに書き換えてください。 実行後以下のステータスが返ってくると成功です。 {"status":200,"message":"ok"} 実際にLINEで確認してみましょう。 先ほどのmessageで指定したHelloというメッセージが送られてきているのが確認できます。 以上でLINEとの連携の設定は終わりになります。 終わりに 今回は、ラズパイの基本的な情報からできることまで簡単に紹介しました。 後半では簡単にラズパイとLINEを連携させてメッセージを送れるようにしましたが、ただコマンドを打ってメッセージを送るだけだとあまり実用性がありません。ここからさらに発展させると、カメラモジュールを組み合わせて、お留守番しているペットの写真を定期的にLINEに送信したり、赤外線センサーを組み合わせて郵便物の受け取りを通知させたりと様々な使い方ができるかと思います。 ここから先は皆さんの発想力でラズパイを自分色に変えてみてください！ 参考 Raspberry Pi Documentation Raspberry Pi センサーでいろいろ作れる！おすすめ10選 - オススメPCドットコム ラズパイのモデルを比較 | M5Stack沼人の日記 Raspberry Pi（ラズパイ）からLINEにメッセージを通知する（コマンド編） | STONE-BOOKs エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに 初めまして。配配メール開発課 Jazumaです。 今回は PHP の フレームワーク Laravelの環境構築～基本機能の動作確認を行います。 Linux 環境での作業を前提としていますので Windows や Mac ではこの記事の手順でLaravelの環境構築をすることができません。予めご了承ください。 はじめに Laravelとは Laravelのメリット 動作環境 Laravelの環境構築 PHPのインストール Laravelのインストールや動作に必要なモジュールのインストール Composerをインストールする Laravelのインストール・プロジェクトの作成 Laravelの基本機能確認 ビルトインサーバの起動 ルーティングの設定 コントローラの作成 Viewファイルの作成 終わりに Laravelとは Laravelは2011年にリリースされた オープンソース の PHP フレームワーク であり、認証・データベースへのアクセス・入力値のチェックなどWeb開発に必要な機能が一通り備わっています。 Laravelの特徴として、 MVC モデルが採用されているということが挙げられます。 MVC モデルとはアプリケーション開発によくある処理をModel、View、Cotrollerの3つに分類して実装する手法です。 Model、View、Controllerはそれぞれ次のような機能を持ちます。 M: Model... データ処理をする。 取得したデータをControllerに渡す機能も持つ。 V: View... ユーザに表示する画面。Controllerにリク エス トを送ったり、Controllerが送ったレスポンスを画面に表示する。 C: Controller... Viewからリク エス トを受け取る。また、Modelから受け取った処理の結果をViewに対してレスポンスとして渡す機能を持つ。 MVC モデルは機能ごとにクラスが明確に分かれているため保守性の高いプログラムを簡単に書くことができるというメリットがあり、Laravelも例外ではありません。 Laravelのメリット Web開発をするにあたって、Laravelには以下のようなメリットがあります。 学習コストが比較的低い 前述の通りLaravelは MVC モデルに準拠しているため、どのファイルにどのような処理を書けばよいのか非常にわかりやすく、文法も単純なものが多いです。 そのため初心者でもWebアプリを効率的に開発することができます。 Webアプリに必要な機能を簡単に実装できる Laravelでは認証・エラー処理などのWebアプリケーションに不可欠な機能を簡単に実装することができます。例えば、「ユーザがリク エス トしたページが存在しない場合に404エラーページを返す」という処理は404.blade. php というViewファイルを作成するだけで実装できてしまいます。 フレームワーク が裏側でよしなにやってくれるというわけですね。この他にもコマンドを実行するだけで認証機能の実装に必要なControllerやViewファイルが作成されるなど、Web開発をスムーズに進めることができます。 コマンドが豊富 LaravelにはArtisanという コマンドライン ツールがデフォルトで備わっており コマンドライン からControllerやModelを作成したり、データベースを操作したりすることができます。 artisanコマンドの一例を以下に示します。(これらはほんの一部分にすぎません。 artisanコマンドの一覧が見たい時は php artisan listを実行します。) php artisan serve # ビルトインサーバを起動する php artisan make:model[controller] [ModelやController名] # Model[Controller]を作成する php artisan tinker #コマンドライン上でLaravelのプログラムを実行するモードを起動 動作環境 私は以下の環境で作業を行っています。 ホストOS: Windows10 Home ゲストOS: WSL2 Ubuntu20.04 PHP 7.4 Laravel 8.16 VSCode ver1.51 Laravelの環境構築 まずは以下の手順でLaravelの環境構築を行います。 PHP のインストール Laravelは PHP の フレームワーク ですので使う前に PHP をインストールする必要があります。 既に PHP がインストール済みの場合はこの手順は省略しても問題ありません。 以下のコマンドで PHP をインストールします。 #add-apt-repository コマンドをインストール $ sudo apt-get install software-properties-common \ # PHPをインストールするするためのppa:ondrej/phpリポジトリを追加 add-apt-repository ppa:ondrej/php \ # パッケージを最新化 sudo apt update \ # PHPをインストール apt-get install php7.4 php -vコマンドを実行してバージョンが表示されていれば正確にインストールされています。 PHP 7.4.7 (cli) (built: Jun 12 2020 07:44:38) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.7, Copyright (c), by Zend Technologies Laravelのインストールや動作に必要なモジュールのインストール Laravelの 公式Webサイト では、Laravelを使うために以下のような PHP のモジュールが必要になると書かれています。 BCMath PHP Extension Ctype PHP Extension Fileinfo PHP extension JSON PHP Extension Mbstring PHP Extension OpenSSL PHP Extension PDO PHP Extension Tokenizer PHP Extension XML PHP Extension ZIP PHP Extension 初期状態ではBCMath, Mbstring, XML がインストールされていません。また、後述するComposerでLaravelの インストーラ コマンドを実行するにあたってzip 拡張機能 が必要になるので合わせてインストールします。 $ sudo apt-get php7.4-bcmath php7.4-mbstring php7.4-xml php7.4-zip このとき、各種モジュールのバージョンは必ず php 本体のバージョンと揃えるようにしてください。(モジュールのバージョンを指定しないことが原因でエラーがよく発生します) モジュールがインストールできたら php -mコマンドで正しくパッケージがインストールできているか確認します。 $ php -m [PHP Modules] bcmath ctype fileinfo json mbstring openssl PDO tokenizer xml zip (見やすくするために必要なモジュールのみを記載しています。) Composerをインストールする Composerとは PHP で開発するのに必要なパッケージやライブラリの依存関係を解決してくれるツールです。例えばLaravelでの開発にパッケージAが必要でパッケージAの導入にはパッケージBが必要でパッケージBを使うにはパッケージCが...というようなことになった場合、Composerがないとそれらを1つ1つインストールしなければなりません。このようなやり方ではインストール漏れやパッケージ毎のバージョン違いでエラーが発生しやすいです。 それに対して、Composerを導入していればパッケージAをインストールするとそれを使うのに必要なパッケージBやCを自動でインストールしてくれる上、バージョン管理も勝手にやってくれます。このような利点からComposerは PHP の各種 フレームワーク で開発する場合ほぼ必ず導入されており、LaravelでもComposerが活用されています。 以下のコマンドでComposerをインストールします。 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1e613307e16318854d24ae64f26d17af3ef0bf7cfb710ca74755a') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php composer-setup.php php -r "unlink('composer-setup.php');" カレント ディレクト リにComposerがインストールされますが、のちの手順を簡略化するためにパスの通っている ディレクト リに移動させます。 sudo mv composer.phar /usr/local/bin/composer Laravelのインストール・プロジェクトの作成 Composerの配置が完了したら以下のコマンドでLaravelの インストーラ をダウンロードします。 $ composer global require "laravel/installer" Laravel インストーラ のダウンロードが終わり次第、.bashrcを編集してComposerのvendor/bin ディレクト リにパスを通します。 $ vim ~/.bashrc export PATH="$PATH:$HOME/.config/composer/vendor/bin" パスを通せたら、Laravelのプロジェクトを作成するための ディレクト リを作り、その ディレクト リに移動してLaravel new コマンドを実行します。 $ mkdir Laravel_app $ cd Laravel_app $ Laravel new sample_app . . - Installing ralouphie/getallheaders (3.0.3): Downloading (100%) - Installing guzzlehttp/psr7 (1.7.0): Downloading (100%) - Installing guzzlehttp/promises (1.4.0): Downloading (100%) - Installing guzzlehttp/guzzle (7.2.0): Downloading (100%) - Installing dnoegel/php-xdg-base-dir (v0.1.1): Downloading (100%) - Installing nikic/php-parser (v4.10.2): Downloading (100%) - Installing psy/psysh (v0.10.4): Downloading (100%) - Installing laravel/tinker (v2.5.0): Downloading (100%) . . . Package manifest generated successfully. 72 packages you are using are looking for funding. Use the `composer fund` command to find out more! > @php artisan key:generate --ansi Application key set successfully. Application ready! Build something amazing. Laravel newコマンドでアプリケーションの開発に必要なパッケージが自動でインストールされていきます。 これでLaravelの開発をする準備ができました。 「Application ready! Build something amazing.」というメッセージが表示されたらLaravel_app ディレクト リで以下のコマンドを実行してLaravelのバージョンを確認してみましょう。 $ php artisan -v Laravel Framework 8.16.1 Laravelの環境構築が無事完了しました。ここから先ではいよいよLaravelの機能を使っていきます。 Laravelの基本機能確認 ビルトインサーバの起動 LaravelではWebサーバを構築しなくても備え付けのサーバ(ビルトインサーバ)によってWebアプリケーションの動作確認をすることができます。(ビルトインサーバはセキュリティや機能面で実用には堪えません。あくまでも開発中の動作確認に使うくらいの使用感です) 以下のコマンドを実行してLaravelのビルトインサーバを起動します。 $ php artisan serve Starting Laravel development server: http://127.0.0.1:8000 [Mon Nov 30 20:47:59 2020] PHP 7.4.12 Development Server (http://127.0.0.1:8000) started ブラウザの検索窓に localhost:8000 と入力してアクセスします。 上の画像のようにLaravelの起動画面が表示されれば成功です。 ルーティングの設定 ルーティングとは「このURLを呼び出したらこのコントローラを呼び出す」というようにURLとコントローラの対応付けをすることです。Laravelでは routes/web.php でルーティングを設定します。 web.php はデフォルトでは以下のようになっています。(コメント部分は省略) <?php use Illuminate\Support\Facades\Route; Route :: get ( '/' , function () { return view ( 'welcome' ) ; }) ; 上記のルーティングの内容を簡単にまとめると、「第一引数のURLがgetメソッドで呼ばれたときに第二引数内の関数を実行する」というものです。ここでは '/'、つまりホーム画面( localhost :8000)にアクセスしたときに welcome.blade.php という名前のViewファイルを返す処理になっています。 先ほどビルトインサーバを起動した際にこのルーティングが呼び出されたというわけですね。 続いて実際にルーティングを定義してみましょう。 web.php を以下のように編集します。 <?php use Illuminate\Support\Facades\Route; Route :: get ( '/' , function () { return view ( 'welcome' ) ; }) ; //追記部分 Route :: get ( '/hello' , function () { return 'hello' ; }) ; 新しく追加したルーティングは、'/hello'というURLをgetメソッドで呼び出すと'hello'という文字列を画面に表示するという内容です。Viewファイルではなく単に文字列を返すのは実用的ではありませんが今回は動作確認のためにこのような処理になっています。 それでは実際に localhost:8000/hello にアクセスしてみます。 上の画像のようにhelloと表示されていれば成功です。 コントローラの作成 続いてコントローラを作成します。 コマンドライン から以下のコマンドを実行します。 $ php artisan make:controller HelloController Controller created successfully. コマンドライン に上のようなメッセージが表示されていれば成功です。Laravelが自動でコントロー ラク ラスのファイルを作成してくれます。 Laravelではコントロー ラク ラスは app/Http 直下にControllerクラスのファイルが作成されます。 app/Http ディレクト リ直下に HelloController.php というファイルが作成されていることを確認しましょう。 無事作成されていますね。 続いて HelloController.php を以下のように変更します。 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; class HelloController extends Controller { //新規追加のメソッド public function index () { return "hello, world" ; } } 詳細は後述します。 さらに、 web.php の内容を変更します。 <?php use Illuminate\Support\Facades\Route; Route :: get ( '/' , function () { return view ( 'welcome' ) ; }) ; //変更箇所 Route :: get ( '/hello' , 'App\Http\Controllers\HelloController@index' ) ; ルーティングの内容を「'/hello'がgetメソッドで呼び出されたら HelloControllerのindexメソッドを呼び出す 」というように変えています。 HelloController.php のindexメソッドはhello, worldという文字列を返すという処理を行うので、先ほどと同じように localhost:8000/hello にアクセスしてhello, worldと表示されていればokです。 Viewファイルの作成 Controllerの次はViewを触っていきます。 resources/views ディレクト リの下に hello.blade.php というファイルを作成し、次のような内容にします。 <!DOCTYPE html> < html lang = "en" > < head > < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < title > Document </ title > </ head > < body > {{$message}} </ body > </ html > 次にコントロー ラク ラスに手を加えます。冒頭で書いたようにLaravelはControllerからViewファイルを呼び出すという処理の流れになっていますので、コントローラ側でViewファイルを呼び出す処理を実装しなければなりません。indexメソッドを次のように書き変えてください。 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; class HelloController extends Controller { public function index () { //変更箇所 $ message = "Hello Laravel!!" ; return view ( 'hello' , [ 'message' => $ message ]) ; } } 変数 $message にHello, Laravel!!という文字列を代入しています。これはLaravel固有の記法というわけではなく、 PHP そのものの文法です。 return文ではviewメソッドを返しており、第一引数で hello.blade.php を返すようにしています。 少し複雑なのが第二引数の ['message' => $message] という部分です。 これはViewファイルに配列でパラメータを渡すための引数で、ここではmessageというパラメータに上で宣言した変数 $message の値をセットしています。 つまり先ほどお見せした hello.blade.php 内の$messageというパラメータにはHello, Laravel!!という文字列がセットされているというわけですね。(Viewファイルの$messageはあくまでもパラメータであり、 HelloController.php で宣言した変数 $message そのものではありません。) それでは localhost:8000/hello にアクセスしてみましょう。 上の画像のようにHello, Laravel!!と表示されているでしょうか? 最後にViewファイルの文法について簡単に解説したいと思います。 < body > {{$message}} </ body > $message を囲んでいる二重括弧 {{ }} にはどのような意味があるのでしょうか。大きく分けて2つの機能があります。1つはパラメータにセットされている値を展開するという機能です。この二重括弧をつけていないとHello, Laravel!!という文字列ではなく、$messageという文字列がそのまま出力されてしまいます。 もう1つはセキュリティ対策の機能です。{{ }} で囲まれたパラメータは単にその値が展開されるだけではなく、内部的には htmlentities() 関数に渡されて値が表示されます。これにより、「<」や 「&」 などの特殊な意味を持つ文字が エス ケープされて単なる文字として出力されます。 特殊文字 が自動で エス ケープされるため、 XSS 攻撃(悪意を持ったユーザが javascript やhtmlタグを入力して他のユーザのブラウザで実行させる攻撃)を大きな手間をかけることなく防ぐことができます。( XSS の詳細は こちら ) 基本的な文法に沿って実装すれば意識せずともセキュリティ対策ができているというのもLaravelの大きな魅力です。 終わりに Laravelを使うと簡単かつ安全にWebアプリケーションを開発することができるということを体感していただけたのではないでしょうか。 今回は紹介することができませんでしたがこの他にも認証機能の実装や、データベースの操作も非常にスムーズに行うことができます。 まだまだLaravelには便利な機能がありますので、また機会がありましたらご紹介したいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは ラク スの iketomo です。 ここ最近はとても寒くなってきました。洋服や家住まいを冬仕様に変更しようとしている今日この頃です。 今回は ガントチャート やエクセル( Excel )や他の ガントチャート のおすすめツールについて紹介させていただきます。 皆様もプロジェクトの スケジュール や タスク管理 には頭を悩ませることも多いかと思います。 是非この記事からガントーチャートの使い方を知っていただきプロジェクトで活用いただければと思います！ ガントチャートとは ガントチャートとWBSとの違い ガントチャートのメリット 進捗の可視化 タスクの洗い出し 無理のない担当者アサイン ガントチャートを作成・使用する際の注意点 作業順序に誤りがないか タスクやリソースの重複がないか 情報が最新化されているか ツール紹介 エクセル（Excel） ・セルを塗潰し方式 ・関数編 Redmine Brabio おわりに ガントチャート とは ガントチャート はヘンリー・ガントさん工場の進捗を確認するためにおよそ100年前に生み出した工程管理の手法になります。 ガントチャート は主に スケジュール や タスク を管理するための表になります。 横棒グラフなどで可視化し プロジェクト全体の計画を 見える化 することでプロジェクトの進捗遅れや重要なタスクなどを視覚的に把握することができ、チームでスケジュールの進捗を共有をしながら進める際にエクセルなどで ガントチャート が使われることは一般的になっています。 ガントチャート と WBS との違い WBS はWork Breakdown Structureの略でタスクをある一定の基準で細分化したタスク一覧表になります。 開始日、終了日、 工数 や進捗を記入することで 全体の 工数 の見積もり や 全体進捗状況（何パーセント完了しているか） を把握することができます。 WBS でもスケジュール進捗を確認することができますが時間軸の概念がないので スケジュールの進捗の把握しやすさという点では ガントチャート の方が優れています。 WBS はタスクの洗い出し、 ガントチャート がスケジュールを可視化したものという関係になります。 ガントチャート の元となるタスクを洗い出す際に WBS を作成する必要があるので、 WBS の延長線上に ガントチャート があると考えてよいでしょう。 WBS と ガントチャート の違い ガントチャート のメリット 進捗の可視化 なんといっても ガントチャート を使う一番のメリット・おすすめ所はスケジュール・進捗の 見える化 になります。 「誰が」「いつ」「何をするのか」を視覚的に把握することができます。 スケジュールの遅れているのか？前倒しで進んでいるのかを自分や他のメンバーも含めメンバー全員に情報共有ができるので スケジュール遅れのトラブルにも即座に対応することができます。 タスクの洗い出し 上記でも述べましたがタスクを洗い出す段階で、 ガントチャート を作成する段階で WBS またはそれに近いものを作成することになります。 タスク漏れが発生してプロジェクトの終盤に追加が作業が発生したというような事態を招かないために 階層構造によりタスクを落とし込み、タスク漏れが発生しないようにすることが重要です。 この作業もエクセル( Excel )で行うことが多いでしょうか。 無理のない担当者 アサイ ン タスクに担当者を アサイ ンしていく段階で否が応でもリソース管理が意識できます。 個人に焦点を充てれば、タスクの重なりもすぐに気付くことができるので ガントチャート ではある期間にリソースが集中してしまうことを防ぐことができます。 ガントチャート を作成・使用する際の注意点 作業順序に誤りがないか あるタスクは前工程の作業が完了していないと進めれられない事があります。 ただ単に担当者と日程を割り振るだけではなく、タスクの依存関係を考慮して担当者と日程を アサイ ンしましょう。 タスクやリソースの重複がないか このタスクは誰誰さんしかできない。などとどうしてもプロジェクトの中心メンバーに大事なタスクが集中しがちです。 ですが、1人は同時に複数のタスクをするにも限界があり、進捗遅れの原因になります。 なるべく同時期に1人に複数のタスクが アサイ ンされないようスケジュールを組んでいきましょう。 情報が最新化されているか プロジェクトでは予期せぬトラブルはつきものです。 タスクの抜けがあった、進捗が遅れた等、様々な要因によってスケジュールは変更が必要とされます。 そういった変更を ガントチャート に反映しないと、 ガントチャート 自体が形骸化してしまい、全体進捗を把握するという ガントチャート の旨味が消えてしまいます。 ツール紹介 ガントチャート を実際に使うときの代表的な3ツールを紹介させていただきます。 エクセル（ Excel ） まずは皆さんの使いなれているエクセル（ Excel ）です。 ガントチャート を作るうえでエクセル（ Excel ）の良いところはすべてにおいて万能なところです。 ・任意で管理項目を増やしたい ・タスクが増えてきたので別途切り出したい ・担当者別に見たい ・完了したタスクは非表示にする ・一度作ったタスクをコピペして新しいタスクを作成する 等といったことが エクセル（ Excel ）では容易できます。 初めて ガントチャート を使い始める人にはまずエクセル（ Excel ）をお勧めします。 逆にエクセル（ Excel ）の悪いところは ・タスク アサイ ン時に通知することができない。 ・スケジュール全体を変更する際にの手間が多い。 等と言ったことが挙げられます。 ここでエクセル（ Excel ）での ガントチャート の作り方を2つ紹介させていただきます。 ・セルを塗潰し方式 担当者のスケジュール アサイ ン部分の日程をエクセル（ Excel ）のセルに塗りつぶしていく形式です。 エクセル（ Excel ）を利用した原始的な方法ではありますが簡易に作ることができ、このフォーマットを流用されるケースが多いです。 担当者ごとに色を変えることで、見た目で担当者を判断することができます。 またエクセル（ Excel ）のフィルターを利用すれば、各担当者にフォーカスして個人スケジュールを把握することもできます。 デメリットはスケジュールの変更にともないエクセル（ Excel ）のセルをペタペタと切り貼りする 工数 が多いことになります。 エクセル（ Excel ）セルを塗潰し方式 ・関数編 エクセル（ Excel ）関数で ガントチャート に対応する方法を紹介させていただきます。 ベースの表は先ほど紹介させていただいたエクセル（ Excel ）のセルを塗潰し方式と変わりありません。 セルを塗りつぶしていた部分をエクセル（ Excel ）のIF関数を利用して自動的に表示する方法になります。 「日付」開始日」「終了日」の3つのセルを利用して、該当のタスクのスケジュールに該当する日かを判定して「■」を表示しています。 エクセルの式は右記の通りです =IF(AND($E5<=K$2,K$2<=$F5),"■","") 「日付」K2のセルのと、「開始日」E5のセルと「終了日」F5のセルをIF関数で比較して ・開始日と終了日の間にあれば「日付」K5のセルに「■」を表示 ・開始日と終了日の間になければ「日付」K5のセルは空白 と判断しています。 簡単なエクセル（ Excel ）関数なので皆様も使ってみたり、アレンジしてみてください。 見た目をもっと良くしようと思うなら、条件付き書式を利用することでセルの色を変えることもできます。 エクセル( Excel ) IF関数 Redmine Redmine で簡易に ガントチャート を使用することができます。 ・チケットがそのまま ガントチャート になり、改めて ガントチャート を作る手間が必要がない。 ・チケットと完全連携できる ・担当者 アサイ ンやチケットの変更があった時にメール通知することができる といった事が最大のメリットになるでしょう。 Redmine をプロジェクト管理・タスク管理に使用している方も多いと思います。 その時にあまり手間をかけずに ガントチャート を使ってみたいという方にお勧めです。 あくまで簡易なので、いろいろな不都合はあります。 ・担当者ごとのスケジュールを見るのが手間 ・タスク登録が手間 ・完了したタスクを非表示にできないので縦に長くなる ・見た目が質素 などなど redmine.jp Brabio Brabioは ガントチャート の作成・更新の手間をなるべく効率化するための クラウド のツールになります。 5人まではフリーで使用できるのでぜひお試しで使ってみてください。 「 ガントチャート 作るならエクセルの10倍速い」の謳い文句の通りドラッグでタスク登録や コピー機 能など、タスク登録や変更をアシストしてくれるUIがとても充実しています。 工数 管理ができないことが玉に瑕ですが、Web上での登録の煩わしさはかなり軽減されています。 といっても、エクセルのUIの簡易さ、拡張性の高さに比べれば見劣りするところもあります。 ただBrabioはエクセル出力する事もできるので、 ガントチャート の大枠をBrabioで作成し エクセルでダウンロードしてあとはエクセル管理に切り替えるということも可能です。 Brabio brabio.jp おわりに 最後に ガントチャート の書き方で参考になる書籍をご紹介。 www.amazon.co.jp www.amazon.co.jp この記事は ラクス Advent Calendar 2020 - Qiita の2日目に参加しています。 よければ是非 ラクス Advent Calendar 2020 - Qiita も覗いてみてください。 今回は ガントチャート について説明させていただきました。 プロジェクト管理とは切っても切り離せないスケジュール管理をガントーチャートを使って プロジェクトメンバーと一緒に、抜け漏れなく、効率良く対応していきましょう。 本記事の内容が多くのプロジェクトのお役に立てますと嬉しいです。 それでは！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。11/17～18に開催された Agile Japan 2020で登壇の機会を頂きましたのでレポートします。 Agile Japanとは スポンサーとしても参加 イベントの風景 変わる勇気・変えない勇気 登壇の現場 セッション紹介：「中小企業のエンジニアチームを”楽”にする」を目指す組織マネジメントの変わる勇気と変えない勇気 なぜアジャイル？なぜビジョン？ チームにアジャイルを取り入れてカイゼン文化を生み出す ビジョンを生み出してヤクの毛刈りから脱出 ビジョンづくりを継続して自己目的化から脱出 私たちの「変わる勇気と変えない勇気」 Agile Japanとは 今年で12年目となる日本最大規模の アジャイル のイベントです。今年は5月に東京で開催される予定でしたが、コロナの影響でいったん中止となったあと、改めてオンライン方式でこの11月に開催されることになりました。 2020.agilejapan.jp スポンサーとしても参加 弊社はスポンサーとしても参加させて頂いており、公式サイトのセッションスケジュールのページにはしっかりと弊社のバナーが表示されていました。ありがとうございます。 セッションスケジュールのページに表示されている弊社のバナー 実は昨年もスポンサーとして参加させて頂き、ブログ記事を投稿しています。 tech-blog.rakus.co.jp イベントの風景 今回のイベントは eventhub というプラットフォーム上で配信されました。セッション動画が2トラック並行で ライブ配信 され、画面右ではslidoで質疑応答が行えるようになっていました。 Agile Japan 2020 オンライン会場 同じ画面上でセッションスケジュールや運営からのお知らせを確認したり、参加者同士の情報交換のためのメッセージ機能もありました。他にもスポンサーの出店ブースで資料をダウンロードしたり、参加者のスケジュールを押さえて個別ミーティングを行う機能もあり、リアルイベントの会場で行っていたことがそのままオンライン会場で再現されていました。オンラインイベントの進化を感じます。 変わる勇気・変えない勇気 今年のイベントテーマは「変わる勇気・変えない勇気」でした。公式サイトのメッセージには、 アジャイル の広まりや日本経済の状況などを踏まえ、今までの仕組みや習慣を見つめ直して未来へ向けてチャレンジする時が来たと言えますが、すぐに変えられない部分も多くあり、変わる部分と変えない部分を勇気を持って見極めていきましょうと書かれています。 このテーマを踏まえて弊社からもセッション公募に応募させて頂き、登壇の機会を頂きました。 登壇の現場 イベントは平日の昼間に開催ということで、オフィスの会議室からオンライン登壇させて頂きました。大阪のオフィスからでも手軽に参加できる点はオンラインイベントならではです。 オフィスの会議室からオンライン登壇 セッション紹介：「中小企業のエンジニアチームを”楽”にする」を目指す組織マネジメントの変わる勇気と変えない勇気 ここからは登壇させて頂いたセッション内容をご紹介します。 なぜ アジャイル ？なぜビジョン？ 今回は「ビジョン」という言葉に焦点を当てて、 アジャイル とビジョンについてお話ししました。 Agile Japan 2018のテーマは「Why Agile 」でした。「なぜ アジャイル に取り組むのか？」ということが語られる背景として、 アジャイル を取り入れること自体を目的にすることの危険性がよく叫ばれています。また、ヤクの毛を刈るように アジャイル に取り組むことだけを続けてしまい、組織が本来目指すべき大きな目標を見失ってしまうこともあります。 この発表では、私たちのチームがWhyと向き合って アジャイル を取り入れ、ビジョンを生み出すことで、ヤクの毛刈りや自己目的化から脱出してきた事例をお伝えしました。 チームに アジャイル を取り入れて カイゼン 文化を生み出す 2019年に現在のチーム体制がスタートし、チームの立ち上げを図る中で最初に目指したのが アジャイル を取り入れながら カイゼン 文化を生み出すことでした。 まずは PDCAサイクル を習慣化するために、1週間単位の計画をしっかり立てて、その後ふりかえりを導入しました。そして、スケジュールマネジメントを強化するためにスプリント制度を導入し、チームのパフォーマンスを最大化するためにサブチーム体制へ移行しました。 アジャイル の要素を少しずつ取り入れて カイゼン 文化を定着させ、チームの成長を実感することができました。しかし一方で、 カイゼン に終わりがなく、 スクラム も未定着でした。 スクラム の要素であるスプリント制度を導入してはいますが、この時点ではまだ反復開発と呼んでおり、 スクラム の要素をすべて取り入れることはできていませんでした。 カイゼン には終わりがなく、いつ スクラム になるのかも見えていない、まさにヤクの毛刈り状態です。「みんなで アジャイル 」には「 アジャイル の旅を成功させる第一歩は、そもそもなぜ仕事のやり方を変えたいのかを理解することだ。」と書かれています。私たちはなぜ アジャイル を取り入れて カイゼン 文化を生み出した先で何を実現したいのか？と考えることにしました。つまり、チームのビジョンを生み出すということです。 ビジョンを生み出してヤクの毛刈りから脱出 書籍「ザ・ビジョン」によると、以下のようにビジョンを生み出す3つの基本要素が紹介されています。 有意義な目的 明確な価値観 未来のイメージ 弊社は「中小企業を楽にする」という理念を掲げています。限られたリソース、規制やルールのしがらみに縛られることも多いのが中小企業です。私たち自身もその環境に身を置いています。まず、中小企業のエンジニアチームである私たちがこれまでに取り組んできた「 アジャイル を土台にした カイゼン 文化」を継続して、チームの一人ひとりが成長することが、有意義な目的であり、明確な価値観であると考えました。 そして、私たちの有意義な目的と明確な価値観を具体化していく取り組みをそのままモデルにすることを未来のイメージと捉えました。これらを踏まえて定義したのが「中小企業のエンジニアチームを”楽”にするモデルをつくる」というビジョンです。 そして、ビジョンに向けて段階的に アジャイル を取り入れていくロードマップを作成しました。まずはチームビルディングを行って、アウトプットを安定化します。次に、パフォーマンスアップを目指して、リリース速度を上げ、プロダクトアウトカムを強化します。そして、変革・再ビルディングのためにチームをスケールアップさせ、最後にこれらの取り組みをモデル化するというロードマップです。 アジャイル を土台にしてビジョンを生み出したことで、この先にどうありたいのか？を明確にすることができ、チームの実態をふまえて今後どのように成長していくかのイメージが持てるようになりました。一方で、具体的なアクションは決まっていないので、チームの全員が完全に腹落ちしているわけでもない課題がありました。 実際にその課題がすぐ表面化しました。ロードマップの2つめのステージである「リリース速度アップ」は実態にあっていないことがわかりました。 アジャイル を取り入れることが目的となってしまい、実態と合わない目標になっていたのです。つまり、自己目的化に陥っていました。 前出の書籍「ザ・ビジョン」には「ビジョンづくりは現在進行系のプロセスであり、たえずそれについて話し合っていく必要がある。」と書かれています。ビジョンを実現するためには、何がいちばん大切なのかを思い出させて、みんながビジョンを見失わないように助け、可能な限り障害を取り除いて、ビジョンづくりを継続する必要があるのです。 ビジョンづくりを継続して自己目的化から脱出 ビジョンはつくっただけではなく、継続的につくり続ける必要があることに気づいた私たちは早速ロードマップを見直しました。実態に沿っていない「リリース速度アップ」への取り組みをいったん保留し、まずプロダクトアウトカム強化に取り組むことにしました。事業部門との連携を強化し、「 プロダクトマネジメント 体制」を構築しました。これまで取り入れてきた アジャイル を継続しながら、プロダクトにフォーカスしていく体制を目指しています。 サブチーム体制も実態に合わせて見直しました。開発力が安定してきたので、オフショアチームの支援を開発リード側のサブチームに移し、よりプロダクト開発に注力する体制にしました。また、オペレーションリード側はチームの成長を目指してDevOpsなどの新たなテーマに取り組む体制にしています。 チームがビジョンを見失わないように様々な取り組みを行っています。半期ごとのチーム目標設定の際には、必ずビジョンとそれに向けた現状をおさらいしています。1on1ではフラットな相談だけでなく、チームのビジョンと個人の成長目標のすり合わせを行っています。ビジョンに向けて ドラッカー 風エクサイズを行ってチーム内の価値観のすり合わせも行いました。中堅メンバー中心にロードマップの次の戦略を考えるチーム戦略会議も行っています。 また、ビジョンを浸透させるためにビジョンに向けたアウトプットも行っています。自社で開催しているイベントやエンジニアブログで、ビジョンへ向けた取り組み事例を紹介しています。今回の アジャイル ジャパンのようなイベントでの発信もビジョンを浸透させるアウトプットのひとつです。 アウトプットすることで、自分たち自身のビジョンに対する認識を定着することにつながります。ただ、イベントへの参加やブログの発信などは、採用や ブランディング など会社としての別の目的もあります。それらとチームのビジョンをすり合わせながら、積極的に関わりを持つことが、チームのビションづくりを継続させます。1つひとつは小さいアウトプットでも、モデルをつくるという自分たちのビジョンに向けた意思表示を継続することで、小さく試して育てていくことにつながると考えています。 私たちの「変わる勇気と変えない勇気」 最後に、私たちの「変わる勇気と変えない勇気」についてまとめます。変わる勇気とは、 アジャイル を土台にしたチームのスタイルです。変えない勇気とは、ビジョンに向かう姿勢です。 アジャイル を土台にしたチームのスタイルは、 カイゼン を続けたり、アクションを見直し続けるために、常に変わる勇気が必要です。ビジョンに向かっていく姿勢は、 スクラム への適応をチームの目標にせずにビジョンづくりを継続し、ビジョンに向けたチームの取り組みをアウトプットし続けるという、姿勢を変えない勇気が必要です。2つの勇気を継続することで、チームの現状は少しずつ スクラム にも近づいています。 ビジョンに向かっていく姿勢を変えない勇気をもつことで、 アジャイル を土台にして常に変わっていく勇気を生み出すのです。 以上のように、 アジャイル とビジョンはチームの継続的な成長につながると考えています。そのために私たちが取り組んでいるのが、 カイゼン 文化を生み出して、ビジョンを生み出し、継続していくという、3つのステップです。この内容が中小企業のエンジニアチームの皆さんの継続的な成長のお役に立てれば幸いです。 継続的な成長のために仲間を募集しています 私たちのチームでは スクラム マスターを募集しています。スライドでもご紹介した「ビジョンづくりを実現するリーダーシップ」を発揮して、私たちのチームで一緒に働いてみませんか？ もちろん、 スクラム マスター以外の様々な職種も募集中です。よろしければぜひご連絡ください。 career-recruit.rakus.co.jp

はじめに itoken1013です、こんにちは。今年も寒い冬がやってきましたね！ 今回はプロジェクトマネジメントに携わる方であれば一度は聞いたことがある PMBOK について、 知識エリアとプロセス群 を中心に紹介していきたいと思います。 知識エリアとプロセス群への理解はプロジェクトマネージャー以外にも、プロジェクトに関わる全てのポジションの方に得られる知見があります。 ぜひこの記事からご担当のプロジェクトで活かせる PMBOK 知識をゲットいただければと思います！ はじめに PMBOKとは？ まず、プロジェクトとは？ 次に、プロジェクトマネジメントとは？ それでは、PMBOKとは？ PMBOKの重要性 PMPとは？ PMBOKの知識エリアとプロセス 知識エリアとプロセスの関係性 プロセス群、プロセス プロセス群 プロセス 10の知識エリア プロジェクト統合マネジメント プロジェクト・スコープ・マネジメント プロジェクト・タイム・マネジメント プロジェクト・コスト・マネジメント プロジェクト・品質・マネジメント プロジェクト・資源・マネジメント プロジェクト・コミュニケーション・マネジメント プロジェクト・リスク・マネジメント プロジェクト・調達・マネジメント プロジェクト・ステークホルダー・マネジメント PMBOKを活用していく際の注意点 おわりに PMBOK とは？ まず、プロジェクトとは？ PMBOK の知識エリアとプロセスを説明する前に、まず私たちが普段当たり前のように発している「プロジェクト」とは何でしょうか？ PMBOK においてプロジェクトとは、以下の特徴を持つ活動を示しています。 開始・終了時期が決まっており、明確な実施期間がある。（ 有期性 ） 過去に行った取り組みと比べて手順、作業の内容、担当者などが異なる 独自性 を持つ。 PMBOK が指すプロジェクトの対義語として「定常業務」が挙げられますが、定常業務は期間の定めがなく、また既存のやり方に従うことで目的を達成できる活動となります。 一方でプロジェクトと定常業務の共通点としては QCD（Quality：品質、Cost：コスト、Delivery：納期）の制約が存在する点 、そして 人が業務に取り組む点 、という2つの側面があります。 次に、プロジェクトマネジメントとは？ 上記で述べた 有機 性、独自性、限られたQCDの制約がある状況下で、 プロジェクト目標の達成に向けた一連のコン トロール がプロジェクトマネジメントです。 これらの複数の制約を抱えながら目標を達成する過程では通常、何らかの課題が生まれます。 プロジェクト立ち上げ時には分からない不確定要素や想定外のトラブルが発生することも珍しくなく、一筋縄では達成できないプロジェクトをうまくコン トロール する必要があります。 これらのコン トロール を担うポジションがプロジェクトマネージャーです。 プロジェクトマネージャーがコン トロール すべき要素はプロジェクトメンバーだけでなく、スコープやリスクや品質など多岐に渡ります。 また一言でコン トロール といっても作業には計画や実行など、フェーズによって求められる内容は変わります。 それでは、 PMBOK とは？ ここまでお伝えした プロジェクトマネジメントで必要とされる知識や手法を体系的に整理し、標準化した フレームワーク が PMBOK （Project Management Body of Knowledge、ピンボック）です。 米国のPMI（Project Management Institute、プロジェクトマネジメント協会）という 非営利団体 によって制定された世界共通のプロジェクトマネジメントの標準 フレームワーク になります。 1987年に初版が制定され、2020年現在では第6版が発行されています。 PMBOK の重要性 プロジェクトには独自性があるため、 PMBOK さえ理解しておけば万事OK！という状態になることはありません。 ただ過去のプロジェクトで蓄積されたナレッジが体系化されていることにより、 PMBOK は困ったときのガイド役として大いに役立つでしょう。 特にこれからお伝えする10の知識エリアとプロセスを知っていると知らないでは、プロジェクトの課題に直面した時の対応力に違いが出てきます。 また個人的な経験から PMBOK の知識エリアとプロセスの考え方は、プロジェクトマネージャー以外の方にも自身の状況を俯瞰し、担当業務をセルフマネジメントする際の参考となると感じています。 このようにプロジェクトマネジメントの ナレッジを世界標準で体系化している点、また細やかに10のプロセスをコン トロール 対象としている点 が PMBOK の重要な存在意義といえるでしょう。 PMP とは？ PMBOK を理解することの重要性をお伝えしてきましたが、ここで PMBOK に関連する資格である PMP （Project Management Professional）について紹介したいと思います。 PMP は PMBOK と同様、PMIによって運営されており、知識エリアとプロセスをはじめとした プロジェクトマネジメントの知識とスキル 保有 を認定する資格 となります。 正確な合格率が公開されているわけではありませんが、受験から資格更新までの内容を読んでいただくと、簡単に取得・維持できるものではないことが分かっていただけるはずです。 資格試験の出題内容としてはPMIが発行している PMBOK ガイドがベースとなっており、後述する立ち上げ・計画・実行・ 終結 ・監視、コン トロール の5プロセス群に関する問題が出題されます。 出題割合は以下となります。 出題範囲 割合 立ち上げ 13% 計画 24% 実行 31% 終結 25% 監視・コン トロール 7% ※ただし PMI公式ページ では21年以降、出題範囲がプロセスをベースとしたものではなく、人・プロセス・ビジネス環境に基づく内容へ変更されることが 掲示 されています。 出題範囲 割合 人 42% プロセス 50% ビジネス環境 8% PMP の受験には前提条件があり、一定期間のプロジェクトマネジメント経験とPMIの認定研修の受講を求められます。 要件 大卒 高卒 36カ月のプロジェクトマネジメント経験を含む 4500時間（2年弱）のプロジェクトを指揮・監督する立場での実務経験 〇 60か月のプロジェクトマネジメント経験を含む 7500時間（3年強）のプロジェクトを指揮・監督する立場での実務経験 〇 35時間のプロジェクトマネジメント研修 〇 〇 また資格を取得後も、3年以内の更新が求められます。 上記の通り、高難易度の資格ではありますが、対外的に高いプロジェクトマネジ メントス キルを証明することができるでしょう。 そしてより PMBOK の知識エリアとプロセスへの理解が深まることと思います。 受験資格のある方は、ぜひトライしてみていただければと思います。 PMBOK の知識エリアとプロセス 知識エリアとプロセスの関係性 さて、ここから本題である PMBOK の知識エリアとプロセスの説明に入っていきます。 詳細は後述していきますが、まず PMBOK の知識エリア、プロセス群、プロセスの関係性を以下に示します。 縦軸が知識エリア、横軸がプロセス群、各セルの要素がプロセスです。 以降の説明の位置づけが分からなくなった際には、こちらのマトリクスに立ち返ってみてください。 立ち上げ 計画 実行 監視・コン トロール 終結 プロジェクト 統合 マネジメント プロジェクト憲章作成 プロジェクトマネジメント計画書作成 ・プロジェクト作業の指揮・マネジメント ・プロジェクト知識のマネジメント ・プロジェクト作業の監視・コン トロール ・統合変更管理 プロジェクト・フェーズの 終結 プロジェクト スコープ マネジメント ・スコープ・マネジメント計画 ・要求事項収集 ・スコープ定義 ・ WBS 作成 ・スコープ妥当性確認 ・スコープ・コン トロール プロジェクト タイム マネジメント ・スケジュール・マネジメント計画 ・アクティビティ定義 ・アクティビティ順序設定 ・アクティビティ資源見積り ・アクティビティ所要期間見積り ・スケジュール作成 スケジュール・コン トロール プロジェクト コスト マネジメント ・コスト・マネジメント計画 ・コスト見積り ・予算設定 コスト・コン トロール プロジェクト 品質 マネジメント 品質マネジメント計画 品質保証 品質コン トロール プロジェクト 資源 マネジメント ・資源マネジメント計画 ・アクティビティ資源の見積り ・資源の獲得 ・プロジェクト・チーム育成 ・プロジェクト・チーム・マネジメント 資源のコン トロール プロジェクト コミュニケーション マネジメント コミュニケーション・マネジメント計画 コミュニケーション・マネジメント コミュニケーション・コン トロール プロジェクト リスク マネジメント ・リスク・マネジメント計画 ・リスク特定 ・定性的リスク分析 ・ 定量 的リスク分析 ・リスク対応計画 リスク対応策の実行 リスクコン トロール プロジェクト 調達 マネジメント 調達マネジメント計画 調達実行 調達コン トロール プロジェクト ステークホルダー マネジメント ステークホルダー 特定 ステークホルダー ・マネジメント計画 ステークホルダー ・エンゲージメント・マネジメント ステークホルダー ・エンゲージメント・コン トロール プロセス群、プロセス プロセス群 まずはプロセス群（上記マトリクスの横軸）です。 ※正式にはプロジェクトマネジメント・プロセス群と呼びます。 PMBOK にはプロジェクトのライフサイクルと作業の位置づけによって、以下の5つのプロセス群を定義しています。 後述する知識エリアとのかけ合わせによって、どのプロセス群でどんな知識や作業が要求されるのかを考えることができます。 立ち上げ プロジェクトを定義した上で、 ステークホルダー から認可を得ます。 計画 プロジェクト目標を達成するための計画を作成します。 実行 計画に従ってリソースを調達し、プロジェクト作業を実行します。 監視・コン トロール 計画と実態の差異を継続的にチェックし、差異がある場合には解消を図ります。 終結 プロジェクトの成果物を受け入れ、プロジェクトを公式に終了します。 プロジェクトを通して得られたノウハウを、次回のプロジェクトに向けて蓄積します。 プロセス 上記のプロセス群には、円滑なプロジェクトマネジメントのために実行すべきアクティビティとして「プロジェクトマネジメント・プロセス」が定義されています。 20年時点の最新である PMBOK 第6版においては、プロセスは全49種類です。 例えばプロジェクト・スコープ・マネジメント知識エリアに属する「スコープ定義」プロセスであれば、プロジェクトで作成する成果物や品質基準を取り纏め、スコープ記述書に定義します。 全てのプロセスの詳細は今回は説明外とさせていただきますが、上記マトリクスの通り、上記の知識エリアとプロセス群のどこかに属する形となります。 ただし全てのプロセスを必ず実行しなければいけないわけではなく、マネジメント対象となるプロジェクトの特性に応じて必要なプロセスを取捨選択する視点が必要です。 10の知識エリア 次は知識エリア（上記マトリクスの縦軸）に関する説明です。 PMBOK ではプロジェクトマネジメントを行う上で必要となる要素を、10種類の知識エリアにまとめています。 10種類の内訳はQCD（Quality：品質、Cost：コスト、Delivery：納期）の3点に加え、目標達成に至るまでの6種類のコン トロール 対象、そしてプロジェクト全体を統合的に管理する「統合管理」となります。 ここから10種類の知識エリアと合わせ、それぞれに対応するプロセスを紹介していきます。 プロジェクト統合マネジメント 以降9種類の知識エリアで定義された各プロセスを統合する知識エリアです。 プロセスはプロジェクトマネジメント全体の枠組みに関わるものであり、全てのプロセス群で定義されています。 プロセス群 プロセス 立ち上げ プロジェクト憲章作成 計画 プロジェクトマネジメント計画書作成 実行 ・プロジェクト作業の指揮・マネジメント ・プロジェクト知識のマネジメント 監視・コン トロール ・プロジェクト作業の監視・コン トロール ・統合変更管理 終結 プロジェクト・フェーズの 終結 プロジェクト・スコープ・マネジメント プロジェクトで必要な作業内容、作業範囲を明確にするための知識エリアです。 プロダクト・スコープ（成果物の性質、機能）とプロジェクト・スコープ（必要な作業）の2観点におけるプロセスが定義されています。 プロセス群 プロセス 計画 ・スコープ・マネジメント計画 ・要求事項収集 ・スコープ定義 ・ WBS 作成 監視・コン トロール ・スコープ妥当性確認 ・スコープ・コン トロール プロジェクト・タイム・マネジメント プロジェクトをスケジュール内に完了させるための計画やコン トロール などのプロセスを定義した知識エリアです。 プロセス群 プロセス 計画 ・スケジュール・マネジメント計画 ・アクティビティ定義 ・アクティビティ順序設定 ・アクティビティ資源見積り ・アクティビティ所要期間見積り ・スケジュール作成 監視・コン トロール スケジュール・コン トロール プロジェクト・コスト・マネジメント プロジェクトにかかるコストを計画し、予算内でプロジェクトを完了させるための知識エリアです。 4つのプロセスが定義されています。 プロセス群 プロセス 計画 ・コスト・マネジメント計画 ・コスト見積り ・予算設定 監視・コン トロール コスト・コン トロール プロジェクト・品質・マネジメント プロジェクトの成果物とその作成プロセスの品質をマネジメントするための知識エリアです。 品質要求を定める、要求を実現するための方法を定める、等の3つのプロセスが定義されています。 プロセス群 プロセス 計画 品質マネジメント計画 実行 品質保証 監視・コン トロール 品質コン トロール プロジェクト・資源・マネジメント プロジェクトを円滑に遂行するために、ヒトやモノの資源を適材適所に配置してマネジメントするための知識エリアです。 PMBOK 第6版より知識エリアの名称が「人的資源」から「資源」へと変更されました。 プロセス群 プロセス 計画 ・資源マネジメント計画 ・アクティビティ資源の見積り 実行 ・資源の獲得 ・プロジェクト・チーム育成 ・プロジェクト・チーム・マネジメント 監視・コン トロール 資源のコン トロール プロジェクト・コミュニケーション・マネジメント この知識エリアではメンバー、クライアント、その他 ステークホルダー 間のコミュニケーションを円滑に行い、縦横の情報連携をマネジメントするためのプロセスが定められています。 プロジェクトで発生する情報の収集、共有などのチャネルを作成し、 ステークホルダー 間のコミュニケーション上の問題点を解消するための知識エリアです。 プロセス群 プロセス 計画 コミュニケーション・マネジメント計画 実行 コミュニケーション・マネジメント 監視・コン トロール コミュニケーション・コン トロール プロジェクト・リスク・マネジメント 発生するとプロジェクト進行に影響を及ぼす不確実性を特定し、必要な対応策（回避・転嫁・軽減・受容）を講じるための知識エリアです。 リスクにはポジティブな好機・ネガティブな脅威の両方が考えられますが、出来る限り脅威を排除しつつ、好機を最大化することが求められます。 プロセス群 プロセス 計画 ・リスク・マネジメント計画 ・リスク特定 ・定性的リスク分析 ・ 定量 的リスク分析 ・リスク対応計画 実行 リスク対応策の実行 監視・コン トロール リスクコン トロール プロジェクト・調達・マネジメント プロジェクトの成果物を内製ではなく、外部に依頼や調達をして作成する際のマネジメントを行うためのプロセスを定義している知識エリアです。 3種類のプロセスの中で取り扱うのは発注先の選定、 RFP （Request for Proposal）の作成、 進捗管理 など、内容は多岐に渡ります。 プロセス群 プロセス 計画 調達マネジメント計画 実行 調達実行 監視・コン トロール 調達コン トロール プロジェクト・ ステークホルダー ・マネジメント プロジェクトの ステークホルダー （利害関係者）との関係構築を行い、プロジェクト目標の達成に向けてポジティブな効果を促進するためのマネジメントを定めた知識エリアです。 第5版から新たに追加されました。 ステークホルダー を特定し、各人の期待値を調整するためのプロセスが定められています。 プロセス群 プロセス 立ち上げ ステークホルダー 特定 計画 ステークホルダー ・マネジメント計画 実行 ステークホルダー ・エンゲージメント・マネジメント 監視・コン トロール ステークホルダー ・エンゲージメント・コン トロール PMBOK を活用していく際の注意点 ここまで紹介しました PMBOK の5つのプロセス群と10の知識エリアを理解することで、経験の浅いプロジェクトマネージャーでも「基本の型」をもってプロジェクトマネジメントを行うことが可能となるでしょう。 企業でも PMBOK をベースとした教育を行うことで、一定の知識を備えたマネジメント人材を輩出できるはずです。 しかしながら冒頭でもお伝えした通り、プロジェクトとは過去の事例にはない独自性を備えた取り組みです。 プロジェクトの性質や外部環境の変化によって、 PMBOK の知識だけでは対応しきれないイレギュラーな事態が発生することは考えられます。 基本の型を超えたより応用的な対応力が求められることもあるでしょう。 あらゆる事態に 臨機応変 に対応するには PMBOK のみならず、場数を踏んで経験することでしか得られない判断力や、個人の 人間力 が必要であることは念頭に置いておくべきと考えます。 おわりに 今回は知識エリアとプロセスの紹介を中心に、 PMBOK の基礎知識を説明してまいりました！ PMBOK の体系化されたプロジェクトマネジメントの知識は、プロジェクトの規模に関わらず恩恵を感じられるシーンがあるはずです。 本記事の内容が多くのプロジェクトのお役に立てますと嬉しいです。 それでは！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

技術広報の syoneshin です。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』 とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ　ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Java』 『内部構造から学ぶPostgreSQL 設計・運用計画の鉄則』 『リファクタリング―既存のコードを安全に改善する―』 『現場で役立つシステム設計の原則』 『レガシーコード改善ガイド：保守開発のためのリファクタリング (Object Oriented SELECTION)』 『3分間HTTP&メールプロトコル基礎講座』 まとめ おすすめの技術書ランキング 以下は当社の開発組織メンバーが選んだ「おすすめの技術書ランキング」です。 調査概要 調査手法:任意アンケート( ヒアリ ングシート)※複数回答可 調査対象:当社開発組織メンバー(テッ クリード ・開発マネージャー含む) 調査項目:2020年10月以前に出版された技術書 有効回答数:66名 ランキング内容:得票数6票以上の技術書 Rank 書籍名 得票数 1 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 12 2 マスタリング TCP/IP 入門編 11 3 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性 が生まれる原理と対策の実践 10 4 達人 プログラマー 職人から名匠への道 8 4 Webを支える技術 8 4 SQL アンチパターン 8 4 Java 言語で学ぶ デザインパターン 入門 8 8 はじめて学ぶ　ソフトウェアのテスト技法 7 8 UNIX という考え方―その設計思想と哲学 7 8 Effective Java 7 8 内部構造から学ぶ PostgreSQL 設計・運用計画の鉄則 7 12 リファクタリング ―既存のコードを安全に改善する― 6 12 現場で役立つシステム設計の原則 6 12 レガシーコード改善ガイド：保守開発のための リファクタリング (Object Oriented SELECTION) 6 12 3分間HTTP&メール プロトコル 基礎講座 6 当社で得票数1位の技術書は 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 世間一般的にも名著としてよく取り上げられる技術書 当社でも若手からテッ クリード まで幅広い支持 以下はおすすめコメント プログラムを書く上で知っておくと良い心構えを知ることができるおすすめの１冊です。もっと早く知りたかったと思うことが多々書いてありました。 お作法や書く時に気をつけることは1年目に読んでとても参考になった技術書です。 プログラムの基本的な考え方を知ることができ、おすすめです。 多くの プログラマー が読んだ技術書ということもあり、共通認識として読んでおくといいかもしれません。 etc 次いで、得票数2位の技術書は 『マスタリング TCP/IP 入門編』 こちらも若手必読の古典 こちらも幅広い支持 以下はおすすめコメント プロトコル 、インターネット、ネットワークについての理解が深まるおすすめの1冊。 ネットワークに関する基本知識はこれで身につく。 おすすめです。 ネットワークの基礎がやさしくまとめられている。 etc 得票数3位の技術書は 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性 が生まれる原理と対策の実践』 こちらも若手必読の技術書 こちらも幅広い支持 以下はおすすめコメント Webアプリケーションのセキュリティに関する内容が詰まったおすすめの１冊。Webエンジニアならこの技術書を一度は読んでおきたい。 Webアプリケーションのセキュリティの基本が詰まった内容。基本的なセキュリティの知識はつけることができる。 etc 次いで得票数が同率4位の技術書4冊 『達人 プログラマー 職人から名匠への道』 主にテッ クリード 達が支持 おすすめコメント 著名なエンジニアが言っていること、やっていることが全てこの本に書かれていると感じました。理想のエンジニアに近づくためのマインドとふるまい方を教えてくれる本と言えます。 プログラムのお作法だけでなく、エンジニアとしてのマインド、のみならず、ビジネスマンとして重視すべき考え方などが広範囲にまとめられている 若手の方だけでなく、ベテランの方も初めて読む（ないし読み返す）と共感して自分の仕事や開発の仕方を再整理することができるとおもいます 仕様書やテスト項目書の書き方は教わるが、どうすればよい プログラマ になれるのかは分からなかった時 自分の会社の中ではなく、世界の「よい プログラマ 像」とそこに近づくためのヒントを教えてくれた。 etc 『Webを支える技術』 おすすめコメント Webアプリケーション開発に必要な基礎知識が一通り含まれている。 Web技術の進歩によって日常生活を大きく影響を与ええてきた歴史に触れることができました。 etc 『 SQL アンチパターン 』 おすすめコメント 読んだ当時は純粋な読み物として楽しんでいましたが、自分が実施したテーブル設計を後から見返すと SQL アンチパターン に影響されている部分が大きいと感じています。 DB設計における実践的かつ幅広いトピックが網羅されている必読の技術書。 etc 『 Java 言語で学ぶ デザインパターン 入門』 おすすめコメント 概念に名前を付けることのパワーを知ったおすすめの１冊。インターフェースで抽象化して 疎結合 にする意義や パターン名を知っていることで他者や フレームワーク のコードをすんなり理解できることを教えてくれた。 著者の“読者に理解させる”文章術がすごい。 有名な技術書だけあってとても丁寧にわかりやすく書かれている。 デザインパターン に初めて触れて「こんな考え方もあるんだ」と知るのに最適。 デザインパターン について知ることができます。古い技術書で書き方がやや古いところも多いですが役に立つかと思います。 etc 次いで得票数同率8位の技術書4冊は 『はじめて学ぶ　ソフトウェアのテスト技法』 おすすめコメント 自分がテスト書く時、すでにあるテストがどういう観点で書かれているかを把握するの役立ちました。スタンダードなパターンが網羅されていますし、初心者にも読みやすかったです。 始めは観点がわからないと思うので、テスト観点を体系的に学べるのがよさげです。 etc 『 UNIX という考え方―その設計思想と哲学』 おすすめコメント UNIX がなぜ優れているかを改めて整理したうえで、良いソフトウェアはどのような構造であるべきかを考えるきっかけになります。 「Small is beautiful.」「Make each program do one thing well.」は常時心に留めておきたい考え方。 小さく作ることがなぜ大切なのかを学ぶことができた。本を読みながらずっと心に響いていたのを記憶しています。 etc 『Effective Java 』 おすすめコメント 定番。第3版ではStreamや ラムダ式 など新しい機能への言及が追加。 Java エンジニアは必読の技術書。 Java の正しい理解と、簡潔で明瞭で正確なソフトウェアの設計に役立ちます。 etc 『内部構造から学ぶ PostgreSQL 設計・運用計画の鉄則』 おすすめコメント 実務で応用できる情報が項目毎に章立てされており、実際の業務で運用トラブルが発生した際に役にたった 高負荷時の原因箇所特定時の仮説の種がこの書籍から得られた。 PostgreSQL の全体像や仕組みから、運用に関する機能も記載されている。一回では理解できず、今もできていないこともあるので何度も読み返して理解したい。 データベースの基礎知識がある状態で読むと、 PostgreSQL の特徴などがよく理解できると思います。運用トラブル発生時は避けて通れない独特の仕様や用語などについても解説されており、関連知識を深めていく上でもよいインプットになると思いました。 etc 次いで得票数同率12位の4冊は 『 リファクタリング ―既存のコードを安全に改善する―』 おすすめコメント リファクタリング の仕方だけでなく、可読性や変更しやすいコードを書く方針を学べるよい本だと思います。 作って終わりではないことを知ったおすすめの１冊。洗練されたコードは一発で生まれるのではなく コードの内部品質を継続的に改善することで生まれると教えてくれた。 具体的なサンプルコードとともに、いろいろな リファクタリング の型を知ることができる。 安全に リファクタリング するための具体的なテクニックや心構えについて記載されており、コアロジックを大改修する際にめちゃくちゃ参考にさせてもらいました。 etc 『現場で役立つシステム設計の原則』 おすすめコメント オブジェクト指向 っぽい設計や書き方を、手続き型と対比してのメリットと実例が合わせて書かれている。 VOやEntityなどDDDのエッセンスも含まれている。 現場で設計し続けたエンジニアのこだわりを感じたおすすめの１冊。型を第一にシステム設計するとはどういうことかを教えてくれた。 著者の振り切った主張には、経験のあるエンジニアであれば必ず賛成できるものと反対したくなるものがあり その考察がシステム設計に対する自身の考えを一歩前進させるきっかけになった。 etc 『レガシーコード改善ガイド：保守開発のための リファクタリング (Object Oriented SELECTION)』 おすすめコメント レガシーコードに立ち向かっていくための手法が色々記載されている。 構造が複雑で理解できないようなコードに対する分析手法・対処方法が学べる。 etc 『3分間HTTP&メール プロトコル 基礎講座』 おすすめコメント 担当プロダクトでは課題図書に選定されていますが、個人的に一番勉強になった書籍。Web上ではどういったやり取りがされているのか、などは新人にはイメージしづらい領域かと思いますが、比較的わかりやすくまとまっていると思いました。図解が多いのもポイント。 登場人物2人の対話形式なので、理解しやすい。 2010年刊なので、HTTP/2などの新しい技術の説明はないが、 プロトコル の基礎を学ぶには十分。 etc その他にも 『基礎から学ぶ Vue.js』 『暗号技術入門 第3版　秘密の国のアリス』 『 テスト駆動開発 』 『エリック・ エヴァ ンスの ドメイン 駆動設計 (IT Architects’Archive ソフトウェア開発の実践)』 『マイクロサービス アーキテクチャ 』 の技術書が、一定の得票数を獲得しました。 まとめ 以上、いかがだったでしょうか。 今回ご紹介しきれなかった技術書は 次回の「番外編」でご紹介しようと思います。 当社開発組織では 業務に必要な技術書の購入と読書会の企画など 技術書に学ぶ機会の支援をしております。 社内読書会の様子 tech-blog.rakus.co.jp tech-blog.rakus.co.jp また学びを発信する機会として Meetupなど技術イベントを積極的に企画し メンバーが自己研鑽しやすい環境整備に力を入れ取り組んでおります。 当社の活動に少しでもご興味をお持ちいただけましたら、イベントにも是非ご参加ください。 主催イベント rakus.connpass.com 本記事でご紹介した おすすめの技術書 が皆さまの情報探索の一助となれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle

はじめに こんにちは。最近お気に入りのお店が閉店してしまい、悲しみに暮れています。 楽楽勤怠バックエンドチームの mako _makokです。 バックエンドチーム所属ではありますが、諸事情で数ヶ月間フロントエンドヘルプとしてTypeScriptでフロントエンドの開発を行っていました。 今ではある程度にTypeScriptを書けるようになったものの、ヘルプ当初は実務として初めてのTypeScriptを用いた大規模フロントエンド開発だったので、早期にキャッチアップする必要がありました。 今回は私がTypeScriptに入門する上で注意すべき点と実際に学習に使用したおすすめの学習教材を紹介したいと思います。 はじめに TypeScriptとは 型の恩恵 1. undefinedが激減してメンテナンスが容易になる 2. 補完を使ってサクサク書ける 3. 型がドキュメントになる 型システムを学習する上での注意点 JavaScript, TypeScriptの学習媒体について JavaScript入門したい方におすすめ JavaScript Primer TypeScript Playground 1. TypeScript Deep Dive 2. 実践TypeScript 3. プログラミング TypeScript 4. Type Challenge 最後に TypeScriptとは TypeScriptとは、動的型付け言語である JavaScript に静的型付けの概念と、一部独自の構文を取り入れた世界的に人気のある プログラミング言語 です。 *1 JavaScript のスーパーセットなので、 ECMAScript 最新仕様や JavaScript の記法がそのまま使えます。 TypeScriptで特徴的なのは型の表現力の高さです。値や数値そのものを型として扱ったり、既存の型から新しい型を作成したりなどができます。以下は型と型を合体できる Union Type という機能の一例です。 type Juice = 'Orange' | 'Apple' | 'Grape' const juice: Juice = 'Cake' // 'Orange', 'Apple', 'Grape'という文字列しか受け付けない type Coffee = 'Cappuccino' | 'American' // Juice型とCoffee型をくっつけてDrink型を生成する type Drink = Juice | Coffee // => 'Orange' | 'Apple' | 'Grape' | 'Cappuccino' | 'American' これ以外にもTypeScriptには多彩な型に関する機能や組み込み型があり、型を柔軟に操作することができます。 型の恩恵 型が柔軟なのは分かったけど、そもそも型をつけてなんのメリットがあるんだという話です。 これについては人によって様々な意見があると思いますが、個人的には以下の3点がメリットと考えています。 JavaScript においてはundefinedが激減してメンテナンスが容易になる 補完を使ってサクサク書ける 型がドキュメントになる 1. undefinedが激減してメンテナンスが容易になる 複数人で開発している以上、自分の知らないところでいつの間にかプロパティが増減しているなんてことは日常茶飯事です。依存関係があるオブジェクトをいじっていたらいつの間にかundefinedになってしまうこともよくあります。 一方で、型があれば、オブジェクトの構造は一発でわかります。 2. 補完を使ってサクサク書ける オブジェクトの構造が事前に分かっているということは、 IDE の補完が効きます。 これはつまり、numberを parseInt() しようとする無意味なコードを生み出さないことにも役立ちますし、存在しないプロパティにアクセスしようものなら コンパイル エラーとして怒ってくれます。 3. 型がドキュメントになる 型はドキュメントになります。 例えば、オブジェクト構造はuserと一緒だけど、申請画面のコードなので申請者を表すapplicantという変数を使用したとします。 型がなければapplicantってどんなオブジェクト構造なんだろうと辿るところから始まりますが、型があった場合は const user: User = { ... } const applicant: User = { ... } となり、変数名は違うけどどちらも同じUserオブジェクトなんだなと一発でわかります。 これを JavaScript で表現しようとすると、変数名を工夫するかコメントを書く必要がありますが、上記の型があるコードは短い記述で表現できます。 型システムを学習する上での注意点 TypeScriptには様々な機能がありますが、知らないまま使ってしまうと危険な機能がいくつかあります。 入門レベルのうちにVueやReactなどのライブラリを用いた開発を行っていると、以下のような問題に突き当たることになることがあるのではないかなと思います。(私はよくありました・・・) なんか型が原因でエラーを吐いているけどエラーが長くて何を直せばいいかわからない ライブラリの型を使ったらよくわからないけどエラーになってとりあえず any を使っちゃう 例えば1のような場合、 コンパイル エラーを解消するのは簡単にできます。 TypeScriptにはどのような値も許容するという any 型と、型を上書き(キャスト)する 型 アサーション という機能があります。 以下は良い例 *2 で、HTTP通信を行い、取得したデータを型 アサーション でキャストしています。 REST API による外部との通信のため、アプリケーションに型を伝えられずレスポンスの型としては any となってしまいますが、User型のオブジェクトだということが分かっている、という前提で使用しているためです。 function getUser ( id: string ) : User { // data はany型 const { data } = get( `https://example.com/user/ ${ id } ` ) // `as 型名`で型アサーション return data as User } 上記のような使用方法はとても有効的なのですが、以下のような使い方もできてしまいます。 const department: Department = getDepartment ( '1' ) const user: User = department as any as User Department 型のオブジェクトを取得し、 any 型に変換した後 User 型に変換しています。 これは コンパイル エラーにはなりません。 Department => any と、 any => User に互換性があるからです。 any はどのような値も許容するため、全ての型に互換性があります。 これは簡単な例ですが、ライブラリを扱い始めると複雑な型が出現し、「解決に時間かかりそうだしとりあえず any に アサーション してみるか・・・ｵｯなんか動いたしこれでいいか！」となるかもしれません。 これは当たり前ですが、実行時エラーの温床になっていくだけです。なんか動いているのは JavaScript のエンジンが賢いだけで、そのうちどこかで崩壊してしまうかもしれません。 TypeScriptに限った話ではありませんが、知らずに使用すると危険なコードを書いてしまう可能性があります。 後述する学習媒体では、このような機能を正しく知り、効果的に使用する方法を学ぶことができます。 JavaScript , TypeScriptの学習媒体について では具体的にどうやってTypeScript, JavaScript に入門していくかです。 TypeScriptはとても人気な言語で、資料もたくさんあります。 JavaScript はとても歴史が長いので、古くなってしまった資料なども多くあります。 実際私も資料探しにはかなり苦戦しました。資料が多く、これから入門する方からすればどれがいいかわからないのかは当たり前です。 様々な 有識者 の方にご教授いただき、私が JavaScript , TypeScriptに入門し、学習していく中で特に参考になったwebサイトや書籍を紹介します。 JavaScript 入門したい方におすすめ JavaScript Primer jsprimer.net これから JavaScript に入門したい、または JavaScript を雰囲気で書いているという方におすすめのwebサイトです。 JavaScript を体系的に、かつ実践的な使用方法を学ぶことができます。 これ1つで JavaScript の基本はマスターできます。 JavaScript の書籍をいくつか読みましたが、 JavaScript Primerは本当に必要なことだけを抽出し、実際の業務で役立つTipsなどが豊富です。 例えば、変数と宣言の項で var の使用は避けるべきということが書いてあったりします。普段 JavaScript を書いている方からすると当たり前かもしれませんが、入門者的には エビデンス 付きで説明してくれている教材はありがたく、とても貴重です。 もちろん非同期処理についても深く触れられており、 Promise や async/await への理解にとても役立ちました。 私も実務では MDN と併せてバイブルにしていました。 応用編ではVanilla JSでアプリケーションを構築する話で、 コンポーネント の実装まで行っていますが、TypeScriptの学習という点においてはあまり関係が無いので進めるかどうかは好みです。 ちなみに、書籍版もありますので、紙で読みたいという方はこちらもどうぞ。 https://www.amazon.co.jp/dp/4048930737/ www.amazon.co.jp TypeScript Playground www.typescriptlang.org JavaScript Primerで JavaScript の基本はマスターできたと思うので、次はTypeScriptに入門していきましょう。 言語の勉強をするためにはやはり自分の手で書くのが一番です。書くためには実行環境を用意しなければなりませんが、そんなときは TypeScript Playground を利用することで、即座に実行環境を用意することができます。 このPlaygroundの良いところは、TypeScriptの コンパイル 結果などを右のペインに表示してくれることです。 TypeScriptが コンパイル された結果どのような JavaScript が出力されるのか確認することができます。 enum など、 JavaScript にない機能がどのように コンパイル されるかを見るだけでもとても勉強になります。 ※ 以降のタイトルにナンバリングしていますが、番号の順に読んでいくのが良いのではないかと筆者は勝手に思っています。 1. TypeScript Deep Dive typescript-jp.gitbook.io 鉄板のWebサイトです。TypeScript commiterの方が書いてくださっているドキュメントで、有志の方たちによって日本語化もされています。 基本的にTypeScriptへの入門向けの解説が多いため、とても分かりやすく、基本的な使い方はここで学べるようになっています。 また、テストツールや周辺ライブラリへの簡単な解説などもあるので、発展的な内容や実務で使う際への足がかりになります。 TypeScriptに入門する上では欠かせないwebサイトです。 2. 実践TypeScript www.amazon.co.jp TypeScript Deep Dive を学習したあなたはTypeScriptの入門レベルを既に超えています。 次の一歩に踏み出すためには実践TypeScriptがおすすめです。 実践TypeScriptでは、実際にTypeScriptとVueやReactなどのライブラリを使用してアプリケーションのコードを書く際に非常に参考になる一冊です。 導入編と実践編の2章構成で、TypeScript Deep Diveを学習された方なら導入編の方の最初の方はサクサク進めることができるんじゃないかと思います。導入編の後半では、 Conditional Type や Mapped Type といった難易度の高い型 組み込み型の使用方法 の項目があります。TypeScript固有の書き方なので少しとっつきにくいですが、これらは型の操作やライブラリの型を読む上では欠かせないので、しっかりキャッチアップしたいです。 実践編になるとVueとReact、ユニバーサ ルフレ ームワークであるNuxt, NextへのTypeScriptの導入方法、それぞれの フレームワーク においてTypeScriptで良いコードを書くためのノウハウが書かれています。 サンプルコードが非常に豊富で、Vueの章なんかでは結構困りがちなVuexの型付けを筆者の方がほぼイチから書いているサンプルなどがあり、非常に参考になります。 3. プログラミング TypeScript https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0TypeScript-%E2%80%95%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8BJavaScript%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E9%96%8B%E7%99%BA-Boris-Cherny/dp/4873119049 www.amazon.co.jp TypeScriptの言語仕様が体系的にまとまった一冊です。 最初はプリミティブ型のような簡単な項目から、前項でも少し出てきた Conditional Type や Mapped Type のより詳細を知ることができます。最後半になるとASTの API (TypeScriptのコードを解析する仕組み)まであります。 ASTはアプリケーションのコードを書く上では必要ないと思いますが、興味がある方は更に学習を深めてみてはいかがでしょうか。 実践TypeScriptと比較して、こちらは言語仕様がかなり詳しく書かれています。 また、こちらにも現場で役に立つTipsや デザインパターン が載っているため、実践TypeScriptと併せて読むのがおすすめです。 4. Type Challenge github.com Type Challenge では、型の実装にチャレンジすることができます。 ここまで学ばれた方はおそらくアプリケーションのコードを書くのに不自由ないレベルの知識は得られたのではないでしょうか。アプリケーションのコードでは自分で複雑な型を自作するというのは結構稀ではありますが、0では無いのでしっかり書けるようになりたいところです。 ここまで学習された方はおそらく、 Mapped Type や Conditional Type のような独自の記法でもなんとなく読めるし、ライブラリの型も結構イケる！くらいのレベル感だと思っています。ですが、実際書けるかどうかはあまり自信がありません。私もそうでした。 そんなあなたは Type Challenge に挑戦してみましょう。 まず、READMEの Challenges から取り組む問題を選択します。 Take The Challenge のラベルを押すとPlaygroundが開くので、問題で指定されている要件の型を作成しましょう。 テストケースも用意されているので、解答のチェックも簡単です。 問題をとき終わったらIssueを見てみましょう。他の方の解答を見ることができます。自信がある解答を作ることができた！という場合は自分の解答をIssueに投げてみましょう。後半の複雑な型の解法は自分が全く思いつかなかったものもあったりするのでとても面白いと思います。 最後に いかがでしたでしょうか。おそらくここまでやり込めば、TypeScriptの言語仕様はかなりキャッチアップできたのでは無いかと思います。その後はVueやReactのようなライブラリを学んだり、webpackなどの周辺ツールについて学ぶのも良いと思います。 私自身、TypeScriptどころか JavaScript 入門者でしたが、これらの書籍やwebサイトのおかげでTypeScriptへ入門し、業務で開発を行うことができました。この記事がTypeScript入門への足がかりになっていれば幸いです。また、学習する中でフロントエンドへの興味がより強くなったので、今後は各種ライブラリの学習や、 OSS へのコミットを目指してやっていこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 : Stack Overflowの開発者の中で愛されている言語ランキング などでも2位を獲得しています。 *2 : 本来はキーのチェックやエラーのチェックを行う必要がありますが簡略化のため省略しています

こんにちは、株式会社 ラク スで先行技術検証や、ビジネス部門に技術情報を提供する取り組みを行っている技術推進課に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 改め 「技術推進プロジェクト」 というプロジェクトがあります。 2020年度は通年で「無停止リリース」について取り組んでいるので、途中ではありますが紹介したいと思います。 今までの記事はかみせんカテゴリからどうぞ。 tech-blog.rakus.co.jp 今回の目標 「無停止リリース」の定義 考慮するポイント セッション管理 リリース中のログインセッション維持 古いバージョンのログインユーザーのみ強制ログアウト可能 アプリケーション構成 リリース中の処理トランザクションの正常終了 リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない DB運用 どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること まとめ 今後の計画 今回の目標 弊社のサービスはBtoBのサービスであることもあり、多くのユーザーが営業時間外となる夜間に計画停止を行ってのリリースを行っていました。 しかし今後サービス規模の増大にともない、極力停止しないリリースが求められることや、エンジニアの夜間作業を避けるために、リリース時も極力サービスを止めない構成を模索します。 「無停止リリース」の定義 完全な無停止を目指すと大規模な分散システムにするなどコスト面で厳しい構成になると考えられたので、あくまで「ユーザーの利便性を極力損なわずにサービスを提供し続ける」という方針で検討しました。 具体的には以下のような要件を挙げています。 ユーザビリティ の確保 ログインセッションが切られることなくログイン状態を維持できる 操作内容が「なかったこと」にならないようにする システム的な完全無停止は目的にしない 内部的な停止は局所化極小化を目指す 影響がでる部分についてUI側でフォロー可能な構成を目指す プログレスバー を出せるようにする 処理完了ではなく処理受付としてレスポンスを返す など 考慮するポイント 「 ユーザビリティ を低下させない」要件をもう少し噛み砕くと以下のような要素にまとめられると考えました。 セッション管理 リリース中もログインセッションが切断されない 古いバージョンのログインユーザーのみ強制ログアウト可能 アプリケーション構成 リリース中も処理 トランザクション が正常終了する リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない DB運用 どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること セッション管理 セッション管理において リリース中もログインセッションが切断されない 一定期間経過後に古いバージョンのログインユーザーのみ強制ログアウト可能 という要件を満たす方法を考えました。 リリース中のログインセッション維持 まず「リリース中にログインセッションが切断されない」ということを逆に考えると、なぜリリース作業においてログインセッションが途切れるのかという話になります。 もっともシンプルなログインセッションの保持方法は アプリケーションサーバ ーに保持させることですが、この場合は保持している アプリケーションサーバ ーを再起動してしまうとログインセッションが失われます。 そこでログインセッションの保持を アプリケーションサーバ ーの外に出す必要があります。データベースサーバーに保持することで アプリケーションサーバ ーの再起動の影響を受けない データベースサーバーの再起動でも（正副サーバーのデータを同期しているので）消失しない とリリース中のログインセッション維持は実現できそうです。 ただ実現は出来るものの、ログインセッションの破棄処理をアプリケーションに実装する必要が生まれたり、頻繁なデータベースアクセスが発生してしまうという課題が生まれます。 これらを解決するためにRedisをセッションサーバーとして採用することを検討しました。 クラウド ネイティブな構成では（ AWS だとElastiCacheを利用して）比較的よく採用される構成だと思います。 Redisを採用するモチベーションとしては以下の点が挙げられます。 インメモリデータベースなので小さなデータを頻繁にアクセスする用途に最適 key- value 型のDBだけどログインセッションの維持に使うなら十分 レコードに TTL : Time To Live(有効期限)を設定することで自動破棄ができる TTL は更新も可能なので「最終アクセスから n 秒」という指定が容易 DBで保持したときのように 冗長化 も可能 古いバージョンのログインユーザーのみ強制ログアウト可能 バージョンが混在しても利用可能にはするものの、いつまでも古いバージョンからのアクセスを有効にし続けるわけにもいきません。いずれは古いバージョンのログインセッションを破棄する必要があります。ただしこのときも新しいログインセッションには影響を出したくありません。 これを実現するために「ログイン処理をどのバージョンで行ったか」を記録することで実現できると考えました。セッションデータにアプリケーションバージョンのデータを残すのです。 " (token_id) ": { " user_id ": xxxxxxxxx , " app_ver ": 1.0 } のようなイメージです。 これによりセッションサーバーから { "app_ver": 1.0 } のログインセッションを削除するなどして、指定したバージョンでログインセッションを維持しているユーザーのみを強制ログアウト可能にします。 アプリケーション構成 アプリケーション構成において リリース中も処理 トランザクション が正常終了する リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない という要件を満たす方法を考えました。 リリース中の処理 トランザクション の正常終了 こちらは言い換えると処理中 トランザクション の完了を待ってからリリース処理をしてあげればいいわけなので、リク エス ト振り分けを止めて待ってあげればいいです。 HTTP Proxyで振り分け制御をするわけですが、リリースの開始判断は人間がやるとしても振り分け制御自体は自動でやりたいです。実現するための機能としては振り分け先ノードのステータスを判断するActive Health Checkと、リク エス トが完了するまで切断しないDraining Modeを使ってあげれば実現できます。 当初この部分に nginx を利用しようとしていましたが、Active Health CheckとDraining Modeがnginx+（有償版）でないと使えないということがわかりました。システム構成的にコストが見合わなかった 1 ので、別のソリューションを探すことにしました。そこで Apache を確認してみると無償版でも利用できるということだったので、 Apache を採用しています。 なお Apache はnginxの普及以降「重い」という印象がありましたが、 Apache 2.4系を評価し直してみると既に改善されているようだったことも今回の採用につながっています。 リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される API バージョンを複数サポートするという話ですが、試行錯誤した結果サンプル実装では以下のような ソースコード の構成にしています。 / |--app.py # Webアプリ本体。`v1/api.py`を読み込み |--README.md |--requirements.txt |--v1/ # APIバージョン:1 のソースコードディレクトリ | | # v3 を作るときに削除される想定 | |--__init__.py | |--api.py # エンドポイントを定義 | |--assets.py # 実処理モジュール | |--auth.py # 実処理モジュール | |--users.py # 実処理モジュール |--v2/ # APIバージョン:2 を作るときは v1 をコピーして改修 ウェブアプリケーション フレームワーク に用意されている、パスを指定して ルーター モジュールを読み込む機能（Path Groupとか呼ばれる機能。FlaskだとBlueprint）でバージョンごとのモジュールを読み込みます。 # app.py #... # バージョンごとのAPI読込 from v1.api import api as api_v1 app.register_blueprint(api_v1, url_prefix= '/api/v1' ) # ... # v1/api.py from flask import Flask, Blueprint, jsonify # 実処理モジュールの読み込み from . import auth from . import users from . import assets api = Blueprint( 'api' , __name__) # エンドポイントの定義 @ api.route ( '/signup' , methods=[ 'POST' ]) def post_signup (): return auth.post_signup() # ... API バージョンが変わる際にはまるごとコピーして別バージョンとして読み込む形になるので重複コードが発生しますが、今回は2バージョン（最新と1世代前）までしかサポートしない想定だったので許容しています。無理に重複コードをなくすことよりも、2世代前のサポートが外しにくくなることを避けることを優先しました。 入力パラメータの過不足がある場合に異常な更新が行われない 無停止でアップデートを行うと、 API リク エス トに必要なパラメータが異なったバージョンのアプリケーションにWebクライアントが接続されるケースが出てきます。この場合にも不正なデータ更新は行われないようにしなければなりません。 必須パラメータが不足するような組み合わせであればエラーになるため、データの更新は行われません。エラー後に最新バージョンの取得と再ログインを促せれば操作を続けられます。 エラーも発生させたくない場合があると思いますが、その場合は API バージョンを変えて2バージョン受け付けられる状態にすることになります。このとき2バージョンの差異をアプリケーションとDBで吸収しなければなりませんが、どんな場合に吸収できて、どんな場合に吸収できないのかは今後検証していきたいと思います。 DB運用 DB運用について どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること 再起動中やフェールオーバー中もアクセスできること ブロックすることなく DDL 操作を行えること という要件を満たす方法を検討しました。 どのタイミングでもクエリが消失せずに整合性が保たれること こちらに関しては新たなクエリリク エス トだけを止めて処理中のクエリが完了するまでリリース担当エンジニアが見て判断する方針にしました。 現状の運用だと、リリースの際に完全に 無人 であることは考えにくく 機械的 に検知する必要性を感じなかったためにこの方針にしています。 新たなクエリリク エス トの停止についてはDBプロキシである MariaDB MaxScale（以下、MaxScale）を利用して振り分け処理を行う設計にしています。 MaxScaleにはフェールオーバー時にもアプリケーション側からの再試行を伴わずに、 トランザクション を喪失しないよう遅延、再試行を行う機能があります。 どのタイミングでもDBにアクセスできること こちらは想定している条件下では「書き込み」に関しては短時間の停止を避けられませんでしたが、片系が再起動中などでフェールオーバーが発生している場合などでも「読み込み」は常時可能になるよう設計を進めています。 MaxScaleによって参照クエリと更新クエリの分離、DBサーバーノードの管理・ 冗長化 を行います。 冗長化 されたDBサーバー クラスタ を構成することで、無停止で実行できない SQL 操作や DBMS 自体のアップデートがあった場合にもローリングアップデートで実行し、ダウンタイムを極力短縮する予定です。 この際「書き込み」はマスタのフェールオーバー中だけ実行できなくなりますが、「読み込み」は停止することなく常に実行できる見込みです。 また、DBに関しては DDL でどこまでロックされるかもシステム全体のアクセス可否に影響してきます。 MariaDB や MySQL は同じ OSS -DBである PostgreSQL と比較してオンライン DDL の対応で先行しています。 PostgreSQL ではカラム追加などのテーブル定義の変更操作は DML を（SELECTでさえ）阻害してしまいますが、 MariaDB / MySQL は多くの操作がオンライン DDL に対応しているため、テーブル定義の変更を伴う場合でもアクセスできることが期待できます。ただし、この手の機能は往々にして運用上の制約がつきものなので引き続き実際に動作させて検証していきたいと思います。 まとめ セッションサーバーにRedisを採用して外部化 HTTPプロキシに Apache を採用 アプリケーションは最大2バージョンに対応 DBMS は MariaDB を採用し、MaxScaleで クラスタ 化 MariaDB のオンライン DDL を活用 今後の計画 ここまでのお話はそれぞれの要素のカタログスペックを元にした設計です。これらが実際に期待した通りの挙動を実現してくれるのかどうかについては今年度後半で検証を進めていきたいと思います（検証結果も2021年3月ごろにブログで共有予定です）。 環境の構築 テスト項目、テスト方法の検討 本当に無停止でリリースできるか検証 （余力があれば） PostgreSQL の場合にどこまでできるか検証 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com 1ノード年間10万円。ノード数が多くなりがちなので厳しい料金体系でした。 ↩

はじめに こんにちは、tuq376sです。 今回は vim について紹介していきたいと思います。 vim というとあまり馴染みのない方には、他のエディタを使うよりも複雑で難しいという印象があるかもしれません。 しかし、あれもこれも覚えなければ基本的な使い方さえできないというわけでもないのです。 ということで、本記事では vim のインストールからファイルの基本操作までを取り扱っていきます。 はじめに インストール手順 vimインストーラーの入手とインストール 環境変数の登録 まずはここから、入力と保存 vimのモード カーソル移動と入力・保存 ファイル編集の基本操作 コピー&ペースト 取り消し&やり直し おわりに インストール手順 とにもかくにもインストールから。 今回は例として Windows にインストールする手順で行っていきます。 vim インストーラ ーの入手とインストール まずは vimの公式サイト へアクセスします。 左側のメニュー欄にダウンロードがあるので、そこから配布ページへ。 対象のOSを選べるので Windows を選択して、 インストーラ ーをダウンロードします。 ダウンロードが完了したら インストーラ ーを起動して、オプションの選択などは全てデフォルトの状態でインストールします。 完了すると、デスクトップにショートカットが作成されます。 ここから起動できるのは gvim と呼ばれる GUI で動く vim です。本記事では コマンドプロンプト から CUI の vim を使用していきますが、コマンドや操作の仕方は CUI で動く vim と変わりないようなので好みの方を利用すると良いと思います。 環境変数 の登録 vim を CUI で利用する場合は忘れずに 環境変数 も設定しておきましょう。 「コン トロール パネル > システムとセキュリティ > システム 」から、システムの詳細設定を選んで、 「 環境変数 」を選択、開いた画面の「システム 環境変数 」からPathを選択した状態で「編集」を押します。 環境変数 名の設定が開いたら「新規」を選んで、 vim .exeの場所を登録します。 デフォルトなら C:\Program Files (x86)\Vim\vim82 (82はバージョン名)にあるはずです。 環境変数 が登録できたら、 コマンドプロンプト を立ち上げて vim と入力してみましょう。 以下のような画面が立ち上がればセットアップ完了です！ まずはここから、入力と保存 では実際に vim を使っていきましょう。 vim は立ち上げただけの状態で文字の入力ができません。これは、 vim は起動された時は ノーマルモード だからです。 入力を行うには挿入モードに切り替える必要があります。 まずはこのモードからざっくりと説明していきます。 vim のモード vim にはいくつかのモードが存在し、モードによって操作できることが変わります。 よく使うものは以下の4つです。 ノーマルモード vim を起動したときの状態であり、全ての中心にあるモードです。 各モードに移動するには ノーマルモード を経由します。操作している間に意図しないモードになってしまったときは Esc を押すことでここに戻ることができます。 カーソルの移動、コピーやペーストなどができます。 挿入モード 文字を入力するためのモードです。このモードにいる間は各キーは文字入力として扱われます。 ノーマルモード から i , a などで切り替えることができ、どのキーで切り替えるかで入力位置が変わります。 コマンドモード ファイルの保存、 vim の終了などいろいろな操作を行うためのモードです。 ノーマルモード から : で切り替えます。コマンドを内容を入力したら Enter で実行します。 ビジュアルモード 主に範囲選択に関するモードで、範囲を選択したり、選択した範囲のコピーなどができます。 ノーマルモード から v などで切り替えることができます。慣れてきたら活用したいモードです。 初めはあまりピンとこないと思いますので、ひとまずはこんなモードがあるという認識だけで構いません。 カーソル移動と入力・保存 モードについて雰囲気がわかったところで、ようやくファイルの編集です。 まずは文字を入力するため、挿入モードに切り替えましょう。挿入モードに切り替えるキーは数ありますが、以下の3つを覚えれば困ることはありません。 挿入モードに切り替えたときの動作 キー カーソルの位置から文字を入力できる i カーソルの右側から文字を入力できる a カーソルの行末で改行した状態から文字を入力できる o これらのキーを入力すると挿入モードに切り替わり、 i , a , o も文字入力として認識するようになります。 しかし、挿入モードの間は入力位置を移動することができません。 入力位置を切り替えるためには一度 Esc を押して ノーマルモード に戻る必要があります。 ノーマルモード では、以下のキーでカーソルを移動できます。 移動先 キー ← h → l ↑ k ↓ j n行目 :n (10行目なら :10 ) 行頭 ^ 行末 $ n行目に移動する方法は厳密には コマンドモードで移動したい行数を入力する という動作になりますが、ここはあまり明確に意識することも少ないと思いますので、以降コマンドモードの入力は 先頭にコロンが付いているノーマルモードでの入力 として扱っていきます。 これで、任意の位置にカーソルを移動して文字の入力ができるようになりました。 次はファイルの保存と vim の終了方法です。以下の入力で行えます。 操作内容 キー 保存する :w vim を終了する :q 保存して vim を終了する :wq または ZZ 名前を付けて保存する :w ファイル名 ファイル編集の基本操作 ここまでできれば、ファイルの編集という最低限の機能は問題なく行えると思います。 けれどただ文字を入力できるだけではエディタとしては物足りないもの。どんなエディタにもあるような機能はもちろん vim にも備わっているので、こちらも紹介していきます。 コピー&ペースト 編集に必須機能その１、コピーとペースト。 vim ではこれを行う機能を「ヤンク」「プット」とそれぞれ呼びます。 まずは ノーマルモード だけで行える方法から見ていきます。 操作内容 キー n行をヤンクする nyy (10行コピーする場合は 10yy ) n行を削除する ndd (10行削除する場合は 10dd ) ヤンクしたものをプットする p ヤンクと削除は対象の行数を指定するようになっていますが、1行の場合は数字を省略して yy , dd とすることができます。 また、 dd については削除というよりは切り取りに近く、 yy したものと同様に p で貼り付けることができます。 しかしこれでは行単位でしか操作ができません。他のエディタならマウスを使って任意の範囲をコピーするところですが、 vim ではこれをビジュアルモードを使って行います。 ビジュアルモードは挿入モードと同じく、切り替えるキーによって動作が異なります。 ビジュアルモードに切り替えたときの動作 キー カーソル位置から範囲選択を行える v カーソル位置から矩形選択を行える Ctrl-v カーソル行から行選択を行える V ビジュアルモードでは ノーマルモード と同じカーソル移動を行えます。 v なら移動した位置までの文字を、 Ctrl-v なら移動した位置を対角に持つ短形範囲を、 V なら移動した位置までの行範囲をといった具合に範囲が選択されます。 選択した範囲に対して行える主な操作は以下です。 操作内容 キー 選択範囲をヤンクして ノーマルモード に移行する y 選択範囲を削除して ノーマルモード に移行する d 選択範囲を削除して挿入モードに移行する c 各入力はそれぞれモードを移行するようになっています。 c ならば挿入モードに移行し、任意の入力を行った後は通常の挿入モードと同じく Esc で ノーマルモード に戻ることができます。 これで、行単位でなくともヤンクとプットが行えるようになりました。 取り消し&やり直し 本記事最後となるのは、編集に必須機能その２、操作の取り消しとやり直しについてです。 それぞれの操作は以下のようになります。 操作内容 キー 操作を取り消す u もう一度操作する(取り消した操作を再度行う) Ctrl-r vim では複数の操作を戻ることができるため uu と入力することで2つ前の操作まで戻ることができます。 ところが vim の元で基本的な操作が同じエディタのviでは、戻ることのできる操作は1つのみです。viを使う際は uu と入力すると「操作を取り消す→取り消した操作を再度行う」という動作になるので注意が必要です。 おわりに 今回はインストールからということもあって、本当に基本的な操作だけを列挙する形になりました。 vim はもっと便利でバリエーション豊富なコマンドや操作、カスタマイズできる部分もたくさんあって、それゆえに推している方というのは多いのだと思います。 しかし自分の記憶を思い起こしてみると、使い始めてしばらくは「iで文字を入力してZZで保存して閉じる」くらいしか覚えられなかったというのもあって、本記事では「最低限のファイル編集に困らない程度」を目指すことにしました。 またいつか、今度はもう少し便利な使い方の紹介もしてみたいなと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに はじめまして、tsudachantanです。 現在、様々なサイトで広く使われている SVG ファイル。 CSS とともに SVG が必須になるともいわれ、デザイナーやフロントエンジニアの方にはお馴染みかもしれません。 今回は改めて、具体的にどのようなフォーマットのファイルなのか、特徴と変換方法について紹介していきます！ 目次 はじめに SVGファイルが普及しているワケ SVGファイルとは？ JPEG、PNG画像形式との違い メリット 拡張性・汎用性が高い！ フィルター、アニメーション表現が可能 デメリット SVGファイルの作成方法 PNGをSVGに変換してみよう SVGファイルをPNGに変換する方法 おわりに 　 SVG ファイルが普及しているワケ Webブラウザ 最大手の IE は長らく SVG に対応しておらず、 サポートされているブラウザが少ないことから普及しませんでした。 しかし現在、 IE9 をはじめ対応するブラウザが増えたことにより多くのホームページが活用しています。 また、近年はレスポンシブデザインと フラットデザイン が主流となっており、それらと相性のいい SVG ファイルの需要は高まっています。 SVG ファイルとは？ SVG （Scalable Vector Graphics)は画像フォーマットの一種です。 SVG ファイルはその名( Vector )の通り、ベクタ形式のデータです。 画像ファイルである SVG ですが、 XML に準拠しており、 テキストエディタ で編集することも可能です。 JPEG 、 PNG 画像形式との違い 画像ファイルとしてよく用いられる JPEG 、 PNG ですが、これらはラスタ形式の画像ファイルです。 ラスタ形式は点（pixel）で画像を表現しています。 こちらの PNG 画像をご覧ください。 PNG 画像 どんどん拡大していくと…… 拡大した PNG ギザギザとドットのようなものが見えてきますね。 画質を上げるためには点の数、つまり解像度を上げていく必要があり、データの容量も大きくなります。 編集を重ねると画像が劣化しやすく、ファイルサイズも大きくなりがちです。 一方、 SVG ファイルはベクタ形式の画像ファイルです。 ベクタ形式とは、画像や文字などの2次元情報を数値化して記録しており、ブラウザがその場で描画してくれます。 解像度を気にすることも、拡大縮小でデータが劣化することもありません。 主に、アイコンや地図、平面的なイラストなどを作成するときにはベクタ形式が採用されています。 メリット 拡張性・汎用性が高い！ Scalableの文字通り、伸縮可能性に優れた SVG は、後から色・サイズ・文字の変更が容易です。 レスポンシブなサイトを構築する際に、 PNG などのラスタ形式だとデ バイス 毎に複数のバージョンを作成する必要がありますが、 ベクタ形式の SVG を使えば1つのファイルで対応できます。 また、 SVG は Retinaディスプレイ *1 にも対応しています。 これにより、Webページのレスポンス向上も期待できるでしょう。 拡大縮小による画像の劣化もないため、レスポンシブデザインとの相性も良い画像ファイルです。 フィルター、アニメーション表現が可能 SVG ファイルは、 CSS や JavaScript 、動画作成ソフトなどを使ってアニメーションを表示することができます。 今までアニメーションといえばGIFを photoshop や Flash で作るのが一般的でしたが SVG はGIFでは扱えない透過も利用できます。 （参考） ics.media www.e-webseisaku.com デメリット とはいえ SVG ファイルも万能ではありません。 SVG ファイルは写真のような複雑な陰影を表現する画像には不向きです。 風景などの画像を数値として扱うためには、膨大な量の計算が必要になるからです。 また、現在はほとんどのブラウザで対応していますが、まれに未対応のブラウザも存在します。 SVG ファイルの作成方法 SVG ファイルの作成方法は、 ベクター 画像を作成できるツールを利用することです。 一般的には Adobe Illustrator や Adobe Photoshop といった画像編集ソフトを利用します。 illustrator などを使って、 SVG にしたいベクタ形式のファイルを開いて、拡張子を. svg にして保存します。 もちろん、 テキストエディタ で作成することも可能です。 PNG を SVG に変換してみよう 元データがベクタ形式でない場合も、 SVG に変換することは可能です。 ブラウザ上で完結する変換ツールを使って変換してみましょう。 検索するといろいろ出てくるのですが、今回は　 Online Image Vectorizer 　を使用していきます。 www.vectorizer.io 対応しているフォーマットは PNG 、 BMP 、 JPEG です。 また、 SVG だけでなくEPS、DXFといった ベクター 形式に変換することも可能です。 時間当たりの変換できるファイル数に制限がありますが、基本的に無料で使えます。 使い方はいたってシンプルで、変換したいファイルをアップロードするだけで SVG ファイルに変換してくれます。 vectorizer 左が変換前の PNG ファイルで、右が変換後の SVG ファイルです。 vectorizer-拡大 拡大してみると、ラスタ形式の PNG ファイルはギザギザしていますね。 無事、 ベクター 形式に変換されていることがわかります。 サイズは 7KB→2KB になりました！ SVG ファイルの中身 変換された SVG ファイルの中身はこんな感じ。 ちなみに、先述したように SVG が苦手とする写真のような複雑な描画の PNG ファイルを変換すると…… vectorizer-写真 左が変換前の PNG ファイル、右が変換後の SVG ファイルです。 ぱっと見た感じ悪くないですが、 179 KB→542KB と、かなりサイズが大きくなっていしまいました…。 vectorizer-写真-拡大 こちらも拡大するとこんな感じ。 変換した SVG ファイルのほうは、いくら拡大してもギザギザになることはありません。 ただ、複雑な色の濃淡を数式で表現するとなると、やはりデータ量が膨大になってしまいます。 SVG ファイルを PNG に変換する方法 SVG ファイルを PNG に変換したいときはこちら SVG to PNG – SVGファイルをネット上でPNGに変換する svgtopng.com 使い方は簡単、 PNG に変換したい SVG ファイルをアップロードするだけです。 一度に20個まで変換でき、まとめてZIPでダウンロードすることも可能です。 おわりに 様々な種類がある画像フォーマットの中から、 SVG の特徴を簡単に紹介させていただきました。 適切な画像フォーマットを選択できるよう、ぜひ本記事を参考に変換してみてください。 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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 *1 : Apple 製品の高画素密度ディスプレイ