銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

【技術書まとめ21】達人に学ぶ SQL徹底指南書

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第21弾です。

今回は、達人に学ぶ SQL徹底指南書 を読みました。

SQL正しい書き方・考え方について丁寧に解説している本です。

特にSQLのパフォーマンスチューニングのところは、すぐに仕事で実践できる具体的な内容で、それ以外のところも知らなかったことが多くとても勉強になったので、SQLに自信がない方は是非ご覧ください。

このまとめには概要だけを書くことでポイントを覚え、実際に使う際に本書の該当箇所にすぐたどり着けるようにしています。

f:id:ysk_pro:20190302170027p:plain

第1部 魔法のSQL

CASE式のススメ

  • CASE式を活用するとSQLでできることの幅がぐっと広がり、書き方もスマートになる
  • CASE式には、単純CASE式と検索CASE式がある。検索CASE式の方ができることが多いので、検索CASE式を用いることが多い
  • CASE式を使い、SELECT句で条件分岐させるとスッキリかけることがある
  • CASE式は、明示的なELSE句がない場合、デフォルトでELSE NULLと見なすという仕様があるので注意が必要
  • DECODE関数などと比べた時にCASE文の大きな利点は、式を評価できる点。つまり、CASE文の中でBETWEEN、LIKE、<、IN、EXISTSなどの便利な述語群を使用できる
  • CASE式は実行時に評価されて1つの値に定まるので、列名や定数をかける場所には常に書くことができる
  • CASE式を駆使することで複数のSQL文を1つにまとめられ、可読性もパフォーマンスも向上する

 

必ずわかるウィンドウ関数

  • ウィンドウ関数のウィンドウとは、範囲という意味である
  • ウィンドウ関数は移動平均を求める場合などによく利用される
  • ウィンドウ関数は以下の操作を1つの関数に詰め込んでいる
    • PARTITION BY句によるレコード集合のカット
    • ORDER BY句によるレコードの順位付け
    • フレーム句によるカレントレコードを中心としたサブセットの定義
  • SQLの内部動作を知るには、「実行計画(execution plan)」を調べればよい。実行計画とは、DBMSSQL文を実行する際に、どのようなアクセス経路でデータを取得し、どのような計算を行うことが最も効率的かを判断するために作るものである

 

自己結合の使い方

  • 同一のテーブルを対象に行う結合を自己結合(self join)と呼ぶ
  • 自己結合は基本的に非等値結合と組み合わせて使われる
  • 自己結合は異なるテーブルを結合していると考えると理解しやすい

 

3値論理とNULL

  • 普通のプログラミング言語の真理値型(BOOLEAN型)とSQLの真理値型の違いは、普通の言語はtrue、falseという2つの値を持つのに対し、SQLはそれに加えてunknownという第三の値を持つことである。2つの真理値だけを持つ通常の論理体系が2値論理と呼ばれるのに対し、SQLの論理体系は3値論理と呼ばれて区別される
  • NULLに比較述語(=や > など)を適用した結果は常にunknownになってしまうのは、NULLが値でも変数でもないためである。NULLは、そこに値がないことを示すただの視覚的マーク、目印に過ぎないのに対し、比較述語を適用できるのは値だけなので、NULLに比較述語を適用してもunknownとなってしまう
  • 3つの真理値の間には次のような優先順位があり、強い方が弱い方をのみ込む
    • ANDの場合:false > unknown > true(例:false AND unknown -> false)
    • ORの場合:true > unknown > false
  • unknownが論理演算に紛れ込むと、SQLが直感に反する動作をしてしまう。これに対処するには、段階的なステップに分けてSQLの動作を追うことが有効

 

EXISTS述語の使い方

  • EXISTSは、SQLにおいて量化を表現する重要な述語である。述語とは、戻り値が真理値(true、false、unknown)となる関数のこと
  • EXISTS以外の述語(=や>など)は1行を入力とするのに対し、EXISTSは行の集合を入力とする
  • 「全ての行について〜」という全称量化の表現を、「〜でない行が1つも存在しない」という二重否定分に変換し、NOT EXISTSを使う方法がよく使われる

 

HAVING句の力

  • 現在の標準SQLでは、HAVING句を単独で使うことができる
  • WHERE句が集合の要素の性質を調べる道具であるのに対し、HAVING句は集合自身の性質を調べる道具である
  • SQLで検索条件を設定するときは、検索対象となる実体が集合なのか集合の要素なのかを見極めることが基本である
    • 実体1つにつき1行が対応している → 要素なのでWHERE句を使う
    • 実体1つにつき複数行が対応している → 集合なのでHAVING句を使う

 

ウィンドウ関数で行間比較を行う

  • ウィンドウ関数を用いれば行間比較(異なる行の間で列同士を比較)することが簡単にできる。相関サブクエリでも同じことはできるが、パフォーマンス面、可読性の面でウィンドウ関数の方が優れている
  • ウィンドウ関数は、サブクエリを使っているが、相関サブクエリではない。そのため、サブクエリ単体でも実行できるので、可読性が高く動作を理解しやすい。サブクエリ内部だけで実行することで、デバッグも容易に行うことができる

 

SQLで集合演算

  • 集合演算子は重複排除のために暗黙のソートが発生するので、ALLオプションをつけるとソートが行われなくなりパフォーマンスが向上する。よって、重複を気にしなくていい場合、または重複が発生しないことが確実な場合はにはALLオプションをつけるとよい
  • UNIONとINTERSECTは冪等性を持つ

 

SQLを速くするぞ

  • SQLパフォーマンスチューニング
    • 効率の良い検索を利用する
      • サブクエリを引数に取る場合、INよりもEXISTSや結合を使う
    • ソートを回避する
      • ソートが発生する代表的な演算は次の通り
        • GROUP BY句
        • ORDER BY句
        • 集約関数(SUM、COUNT、AVG、MAX、MIN)
        • DISTINCT
        • 集合演算子(UNION、INTERSECT、EXCEPT)
        • ウィンドウ関数(RANK、ROW_NUMBER等)
      • ソートがメモリ上で行われてる間はまだいいが、それでは足りずにストレージを使ったソートが行われるとパフォーマンスが大きく低下する
      • 集合演算子のALLオプションをうまく使う:重複を気にしなくてよい場合、重複が発生しないことが明らかな場合は、ソートが発生しないALLオプションをつけて使う
      • DISTINCTをEXISTSで代用する:2つのテーブルを結合した結果を一意にするためにDISTINCTを使っているケースでは、EXISTSで代用することでソートを回避することができる
    • 極値関数(MAX/MIN)でインデックスを使う
    • WHERE句でかける条件はHAVING句には書かない:GROUP BY句による集約はソートなどを行うので事前に行数を絞り込んだ方がよく、うまくいけばWHERE句でインデックスが利用できるため
    • GROUP BY句とORDER BY句でインデックスを使う
    • インデックスが使われない書き方
      • 索引列に加工を行なっている
      • インデックス列にNULLが存在する
      • 否定形を使っている
      • ORを使っている
      • 後方一致、または中間一致のLIKE述語を用いている
      • 暗黙の型変換を行なっている
    • 中間テーブルを減らす:中間テーブルの問題点は、データを展開するためにメモリを消費することや、元テーブルに存在したインデックスを使うのが難しくなることである
      • 中間テーブルを使うのではなく、HAVING句を活用する
      • IN述語で複数のキーを利用する場合は、一箇所にまとめる
      • 集約よりも結合を先に行う
    • レコード数を絞れる条件は早い段階で記述する
  • SQLにおいて、最大のボトルネックになるのはストレージへのアクセスである。ソートを減らすのも、インデックスを利用するのも、中間テーブルを省略するのも、すべてストレージへのアクセスを減らすことを目的にしている
  • SQLの実行順序は、FROM → WHERE → GROUP BY → HAVING → SELECT (→ ORDER BY)である(ORDER BYは正確にはSQLの一部ではないのでカッコとしている)。複雑なSQLを書くときは、いきなりSELECT句から書くより、実行順序に沿ってFROM句から書いた方が自然にロジックを追える
 

第2部 リレーショナルデータベースの世界

  • 2000年代に、RDBの欠点であるパフォーマンスのスケーラビリティや非構造化データの扱いといった問題がクローズアップされるようになり、それに対する解決策としてNoSQLが登場してきた
  • NoSQLには明確な定義はなく、RDBとは異なるアーキテクチャやデータモデルに基づくデータベースという程度のゆるい定義である
  • NoSQLの一つに、KVS(Key-Value Store)がある。KVSは、キーとそれによって一意に決まる値という非常にシンプルな構造しか持たない。Redisやmemcachedなどの製品がKVSの機能を備えている
  • NoSQLには、ドキュメント指向型DBと呼ばれるタイプもある。JSONXMLのような自由度の高いドキュメントを、RDBのテーブルに変換することなくネイティブに扱う機能を持つ。製品としては、MongoDB、CouchDBなどが該当する
  • NULLについては、まず以下のようにデフォルト値を入れられないか検討し、どうしようもない場合のみNULLを許可するのがよい
    • フラグなどのコードの場合、未コード化用のコードを割り振る
    • 名前の場合、名前が不明用の値を決めて用いる
    • 数値の場合、0で代替する
    • 日付の場合、0000-01-01や9999-12-31のように最大値・最小値で代替する
 

おわりに

ここまで読んでいただきありがとうございます。 

具体例が多くとても分かりやすかったので、気になる方は是非本書をご覧ください。

次は Effective Ruby を読む予定です。

来週も頑張ります!

【技術書まとめ20】達人に学ぶDB設計 徹底指南書

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第20弾です。

 

今回は、達人に学ぶDB設計 徹底指南書 を読みました。

DB設計の基礎知識やポイントを丁寧に解説している本です。

 

中でも、インデックスを作成するかどうかの指針が書かれているところは、実務で悩んだことがあったのでとても参考になりました。

一からアプリケーションを作る時以外でも、テーブルやカラム追加の際に為になる知識も多かったので、DB設計に自信がない方は是非読んでみて欲しいです。 

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

 

f:id:ysk_pro:20190209145325p:plain

第1章 データベースを制する者はシステムを制す

  • データとは、ある形式(フォーマット)に揃えられた事実のこと。情報とは、データをある文脈・観点に従って集約・加工されたものである
  • データベース設計が重要な理由
    • システムの大半のデータはデータベース内に保持されるため
    • データ設計がシステムの品質を最も大きく左右するため。どのようなプログラムが必要になるかは、どのようなデータをどういうフォーマットで保持するかに左右される
  • データベースの設計は、3層スキーマモデルという3つのレベルに分けて行う
    • 外部スキーマ:ユーザーから見たデータベースで、テーブルやビューのこと(画面やデータ)
    • 概念スキーマ:開発者から見たデータベースで、テーブル定義のこと(データの要素やデータ同士の関係)
    • 内部スキーマDBMSから見たデータベースで、データの物理的配置のこと(テーブルやインデックスの物理的定義)
 

第2章 論理設計と物理設計

  • 概念スキーマを定義する設計を論理設計と呼び、論理というのは物理層の制約にとらわれないという意味である
  • 論理設計は次の4つのステップからなる
    • エンティティ(現実世界に存在するデータの集合体)の抽出:エンティティをテーブルとする
    • エンティティの定義:テーブルにどのようなカラムを持つか定義する
    • 正規化
    • ER図の作成
  • 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決める工程が物理設計である
  • 物理設計には、大きく分類して次の5つのタスクが含まれる
    • テーブル定義
    • インデックス定義
    • ハードウェアのサイジング
    • ストレージの冗長構成決定
    • ファイルの物理配置決定
 

第3章 論理設計と正規化 〜なぜテーブルは分割する必要があるのか?

  • テーブル名は必ず複数形で書ける。そうでなければそのテーブルにはどこかに間違いがある
  • 主キーは、テーブルに必ず一つだけ存在する。主キーとは、その値を指定すれば必ず1行のレコードを特定できる列の組み合わせ。主キーがテーブルに存在しなければならないので、重複行は存在し得ない
  • 外部キーは、2つのテーブル間の列同士で設定するもので、参照整合性制約を課すことが役割である
  • NULLはSQL上で扱う際にいろいろな問題を引き起こすので、可能な限りデータはNULLにしないというのがデータベース設計における大方針。可能な限りNOT NULL制約を付加する
  • 正規形とは、データベースで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式。正規形のレベルは第5まであるが、通常は第3正規形までで十分である
    • 第1正規形は、一つのセルの中には一つの値しか含まないというもの
    • 第2正規形は、テーブル内で部分関数従属(主キーの一部の列に対して従属する列の関係)を解消し、完全関数従属のみのテーブルを作ることである。第2正規化は、異なるレベルのエンティティをテーブルとして分離する作業と言い換えることもできる
    • 第3正規化は、テーブル内での推移的関数従属(段階的な従属関係)を解消すること
  • 正規形はいつでも非正規形に戻すことができる。つまり、高次の正規形は低次の正規形を含んでいる
  • 正規化の欠点は、テーブルの数が増えるためにSQLで結合を多用することになり、パフォーマンスが悪化すること
 

第4章 ER図 〜複数のテーブルの関係を表現する

  • 多数のテーブルを管理するために、それぞれのテーブルがどういう意味を持っていて、テーブル同士が互いにどういう関係にあるのかを明示するために作る図をER図(Entity-Relationship Diagram)と呼ぶ
  • ER図を描くときに最初に着目するポイントは、あるテーブルの主キーが、他のテーブルに列として含まれているかどうかである
 

第5章 論理設計とパフォーマンス 〜正規化の欠点と非正規化

  • 正規化がパフォーマンス問題を引き起こす原因は、正規化するとSQL文の中で結合(join)が必要になることである。結合はSQLの処理の中でもコストが高く、多用するとSQLの速度が低下する
  • 正規化と検索SQLのパフォーマンスは強いトレードオフの関係にあるが、パフォーマンスを重視して非正規化することは最後の手段として考えるべきである
 

第6章 データベースとパフォーマンス

  • データベースのパフォーマンスを決める主な要因は、ディスクI/Oの分散(RAID)、SQLにおける結合(正規化)、そしてインデックスと統計情報である
  • インデックスを使うかどうかは、DBMSが自動的に判断する。したがって、インデックスを使う場合は単純にデータベース側にインデックスを作成すればよく、アプリケーションプログラムの変更の必要はない
  • 最もよく使われるB-treeインデックスは、木構造でデータを保持する。最下層のリーフと呼ばれるノードだけが、実データに対するポインタを保持しており、データベースは最上位のノードから順にノードをたどって、リーフから実データを見つける
  • B-treeは、等号による検索のみならず、不等号やBETWEENといった範囲検索の条件に対しても高速化を可能とする。反対に、否定条件はB-treeが効果を持たない
  • ソートはかなりコストの高い演算であり、極力大きなソートを避けることがパフォーマンス上望ましい。COUNT、SUM、MAX、UNIONなどの処理でも暗黙にDBMS内部でソートが行われている。B-treeインデックスは、構築時にキー値をソートして保持するため、B-treeインデックスが存在する列をソートのキーとして指定した場合は、ソート処理をスキップすることが可能でパフォーマンスが向上する
  • B-treeインデックスを作る指針
    • 大規模なテーブル:レコード数が1万件以下の場合はほぼ効果はない
    • カーディナリティの高い列:カーディナリティとは、特定の列の値がどのくらいの種類の多さを持つかという概念。例えば性別で、男性・女性・不詳が入る場合、カーディナリティは3となる。特定のキー値を指定した時に、全体のレコード数の5%程度に絞り込めるだけのカーディナリティがあることが目安となる
    • SQL文でWHERE句の選択条件、または結合条件に使用されている列に作成する
  • インデックスが利用できていないパターン
    • インデックス列に演算を行なっている:インデックスを作成した列はSQLでそのまま用いるのが原則
    • 索引列に対してSUBSTRなどのSQL関数を適用している
    • IS NULL述語を使っている:B-treeインデックスは一般的にNULLについてはデータの値と見なさず、保持していない
    • 否定形を用いている
    • ORを用いている:INで書き換えることでインデックスを用いることは可能
    • 後方一致、または中間一致のLIKE述語を用いている:LIKE述語を使うときは、前方一致検索の場合のみインデックスが使用される
    • 暗黙の型変換を行なっている:列とデータ型の異なる値を条件に指定した場合、DBMSは内部的に暗黙の型変換を行うが、その場合はインデックスは使用されなくなる
  • DBMSの主キー制約や一意制約を作成する際には、内部的にはB-treeインデックスを作成しているので、インデックスの作成は不要である
  • インデックスは一般的にテーブルとは独立のオブジェクトとしてDBMS内部に保持される。そのため、インデックスが作成されている対象の列の値が変更されると、インデックス内に保持している値も変更しなければならず、インデックスは更新性能を劣化させてしまう
  • インデックスは、テーブルのデータが更新されていくと、長期的には構造が崩れて性能が劣化してしまう。そのため、運用において定期的なメンテナンスを行うべきである。具体的には、インデックスの再構築を行うことが性能を維持するためには望ましい
  • 統計情報とは、テーブルやインデックスなどのデータについてのデータ、すなわちメタデータである。DBMSはこのメタデータを頼りにSQLのアクセスパスを決定している
  • DBMSSQLを受け取ると、まずパーサに渡される。パーサはSQL文が適法な構文であるかをチェックする役割を持つ。パーサによるチェックが済むと、SQLオプティマイザに送られる。オプティマイザはSQLの実行計画を決めるDBMSの頭脳である。オプティマイザが実行計画を立てる際に必要なのが統計情報で、統計情報はカタログマネージャから受け取る。統計情報を受け取ると、オプティマイザは最短の経路を選択し、SQLを手続きに変換する。このとき得られた手続きの手順が実行計画で、これにしたがって実データであるテーブルにアクセスを行う
  • 統計情報はデータが大きく更新された後は、なるべく早く収集すべきである。統計情報を収集するのは、それなりにリソースを消費する処理であるので、基本的にはシステムの使用者が少ない夜間帯に実施する。また、統計情報の収集はDBMSによっては、デフォルトの設定で定期的に実施されていることもある
 

第7章 論理設計のバッドノウハウ

  • データベースには、意味的に分割できる限りなるべく分割して保持するのが基本方針。分割したものを後で結合するのは簡単にできるのに対し、結合された状態のものを後から分割するのは比較的難しいためである
  • バッドノウハウがよくないのは、システムの品質を左右する上、後から変更するのが容易ではないためである
 

第8章 論理設計のグレーノウハウ

  • 子1、子2、子3のようなカラムを持つ列持ちテーブルは、NULLを使わざるを得なくなるので、極力使うべきではない。基本的には行持ちテーブルを使うべきである
 

第9章 一歩進んだ論理設計 〜SQL木構造を扱う

  • リレーショナルデータベースでは、木(tree)構造を表現するのが苦手である
  • 木構造を表現する方法には、伝統的な隣接リストモデルや、近年できた入れ子集合モデル、入れ子区間モデル、経路列挙モデルがあり、それぞれにメリットデメリットがある

 

おわりに

ここまで読んでいただきありがとうございます。 

具体例も多くとても分かりやすかったので気になる方は是非本書をご覧ください。

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

 

次は同じシリーズのSQLの本を読むつもりです。

来週も頑張ります!

 

 

【技術書まとめ19】アジャイルな見積もりと計画づくり

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第19弾です。

 

今回は アジャイルな見積もりと計画づくり を読みました。

アジャイル開発について詳しく解説をしている名著です。

 

アジャイルについて全く知識・経験がなかったですが考え方がとても合理的で面白かったです。

この記事を読めばアジャイルについての概要がつかめると思うので、興味ある方は是非読んでみてください。

今回は学ぶことが多かったので少し長めです。

f:id:ysk_pro:20190126103827p:plain

まえがき

  • アジャイル開発者の主張は次の通り。「私たちは今ここで分かっていることを元に計画を立てる。顧客にとって一番大切な目標を達成するために私たちは計画を変更する。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させる。私たちから顧客への願いは、ビジネスの変化へ柔軟に適応することと当初の計画を死守するとことは矛盾した要求だと、きちんと理解してほしいということである」
  • 多くのプロジェクトマネジメント手法は「計画ー計画ー計画ー実行」であるのに対し、アジャイル手法は「計画ー実行ー適応」の繰り返しである。プロジェクトの不確実性が多ければ多いほど、成功するためにはアジャイル手法が必要となる
  • プロダクトマネージャやプロジェクトマネージャに、専門的スキルを持つ人の仕事の進め方と仕事内容を決定する権限を与えてしまうのは、ビジネス的自殺といってもよい
  • アジャイルな見積もりと計画づくりの手法が従来型の手法よりも効果的な理由は、価値を提供することとビジネスとプロジェクトチームの間に信頼関係を築くことに注力しているためである。どんなことにも透明性を保ち、いかなる変更でもビジネス側に伝えることで、ビジネス側も素早く適応し、最善の判断を下すことができる
 

第1部 問題とゴール

1章 計画の目的

  • プロジェクトが進むにつれて見積もりは正確になる。「不確実性コーン」によれば、初期のプロジェクト定義の段階では見積もりには60%から160%に及ぶ誤差が生じる
  • よい計画とは、ステークホルダーが信頼できる計画である。信頼できるとは、その計画を基にして意思決定できるということである
  • アジャイルな計画づくりを定義すると以下のようになる
    • 計画よりも計画づくりを重視する
    • 変化を促進する
    • 計画そのものは容易に変更できる
    • プロジェクト全体にわたって繰り返される
 

2章 なぜ計画づくりに失敗するのか

  • 仕事の量は、完成のために与えられている時間をすべて満たすまで膨張する。これはパーキンソンの法則と呼ばれており、私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう
  • マルチタスク化は生産性に甚大な悪影響を与え、遅れを助長する。個人が3つ以上の作業を並行して進めると、価値を生み出す作業に使える時間が大幅に減少することが分かっている
  • 不確実性に対処する最善の方法は、繰り返すことである。プロダクトがどうあるべきかという不確実性を低減させるには、短いイテレーションで作業するとよい
 

3章 アジャイル手法

  • アジャイルチームの基本的な仕事の進め方
    • 1つのチームとして働く:すべてのプロジェクト参加者が、共通のゴールを持った1つのチームに参加している意識を持つ
    • ビジネス上の優先度を重視する
    • 検査と適応
  • プロジェクトというものは新たな機能と知識を生み出し続ける活動であり、単に決められた手順を実行するだけではない
  • アジャイルチームは3つのレベルで計画づくりをする
    • リリースプランニング:リリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる
    • 今日のプランニング:日々のスタンドアップミーティングでメンバーがその日に何をするか決めた1日単位の計画
  • プロダクトオーナーの満足条件を理解せずに、リリースプランニングとイテレーションプランニングはできない
 

第2部 規模を見積もる

4章 ストーリーポイントによる規模の見積もり

  • ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさを表す単位である。ストーリーポイントを使った見積もりでは、ひとまとまりの仕事に対してポイントをつける。ポイントの数値そのものは重要ではなく、他の作業との相対値が重要である
  • ストーリーポイントによる見積もりの始め方には2種類ある。これから取り組むストーリーの中で最も小さいと思えるものを基準としてそれを1ポイントとする方法と、中くらいと思えるストーリーを決めて、それに見積もりで使う数値範囲の中央に近い値をつける方法である
  • ベロシティとは、チームの進む速度を表す単位である。ベロシティの値は、チームが1回のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値である。チームが前回のイテレーションで10ストーリーポイント分の作業を完了させたのであれば、次のイテレーションでも10ストーリーポイント分の作業をこなせると予測できる
  • 必要なすべてのフィーチャのストーリーポイントの見積もりを合計すれば、プロジェクト全体の規模を見積もれる。また、チームのベロシティがわかれば、規模をベロシティで割ると必要なイテレーションの回数が見積もることができる。イテレーション数とは期間なので、カレンダーに当てはめればそれがスケジュールとなる
  • アジャイルな見積もりでは「規模を見積もり、期間は導出する」
  • プロジェクトが進捗するということはユーザーストーリーをこなしていくことなので、数イテレーションも実施すればチームのベロシティがわかってくる。ポイントによる見積もりの素晴らしい点は、ベロシティを適用することで計画時の見積もりミスが自動的に補正されることである
 

5章 理想日による見積もり

  • ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もる方が簡単である。現実日による見積もりでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積もりなら、ストーリーに必要な時間だけを検討すればよい
 

6章 見積もりの技法

  • わずかな時間で考えた見積もりと、長時間悩んだ末に出した見積もりがほとんど同じになるのはよくあることである。ある程度以上の労力を費やしても、見積もりの正確さには寄与しない
  • 見積もりはチーム全体で出した方がよいアジャイルプロジェクトでは誰がどの作業をするのか事前に分からないことが多く、作業を担当するメンバー以外の意見も参考にした方が良いため
  • 人は10倍以内のものならうまく見積もれるという研究結果がある。見積もりのスケールには「1, 2, 3, 5, 8」というフィボナッチ数列をよく用いる
  • プランニングポーカーは、専門家の意見、対比、分割の全てを組み合わせ、楽しみながら迅速かつ信頼できる見積もりを出すことができる。プランニングポーカーの参加者はチームの開発者全員である
    • まず最初に、全員に一組のカードを配り、そこにはチームで使用できる見積もりポイントが1枚につき1つずつ書かれている
    • 進行役となる人が、見積もり対象のユーザーストーリーやテーマを1つずつ読み上げ、見積もり担当者からの質問にはプロダクトオーナーが回答する
    • 見積もり担当者は、自分がこうだと思う見積もりポイントのカードを選ぶ。選んだカードは全員が選択し終えるまで人には見せないようにし、全員の見積もりが決定したら一斉にカードをオープンする
    • 人によって見積もりが大きく異なることは、見識の相違から学ぶチャンスである。高い見積もりを出した参加者と低い見積もりを出した参加者に、見積もりの根拠を説明してもらう。この時、見積もった人を非難しているように見えないよう留意する
    • 議論を終えたら、見積もり担当者はそれぞれ再び見積もりポイントカードを選んで、一斉にオープンする
    • 多くの場合、見積もりは第2ラウンドで収束するが、収束しなければここまでの手順を繰り返す。ゴールは、全員が合意することにある
  • プランニングポーカーがうまくいく理由
    • 複数の専門家の見解をまとめた見積もりを実現するため
    • 活発な対話を引き出すため。見積もりについて説明を求めると、情報の不足を補ったよりよい見積もりとなる
    • 個人の見積もりを平均した方がよりよい結果を残す傾向があるという研究結果があるため
    • 楽しいため
 

7章 再見積もり

  • 再見積もりが必要となるのは、ストーリーの相対的な規模に変化があったとチームが判断した時(例えば、あるシナリオだけがより時間を要すことがわかった場合など)である。あるストーリーが想定よりも長く時間を要したというだけでは再見積もりはしない
 

8章 ストーリーポイントと理想日

  • ストーリーポイントは純粋な大きさのみを測定する値だが、理想日はそうではない。開発者のスキルが変化すれば理想日の見積もりも変化してしまうが、ストーリーポイントではこうしたことは起きない
  • 理想日は人によって異なってしまうが、ストーリーポイントは人によって異なることはない
 

第3部 価値のための計画づくり

9章 テーマの優先順位づけ

  • 新しいフィーチャの優先順位づけに必要な4つの要素
    • フィーチャの金銭価値
    • フィーチャの開発(サポートも含む)にかかるコスト
    • フィーチャの開発を通じて学べる知識の量とその意義
    • フィーチャの開発によって低減できるリスク
  • 4つの要素を総合して優先順位をつけるとき、第一に考えるのはフィーチャの価値とそのフィーチャを開発するのにかかるコストである。コストに対して最も高い価値を持つテーマが、最初に着手すべきテーマとなる。さらに、他の優先順位づけの要素を検討してテーマの優先順位を上下する
 

10章 金銭価値による優先順位づけ

  • 財務的に分析することは優先順位づけに役立つ。利益と業務改善の効果を予想するのは2年先までが一般的である
  • キャッシュフローの評価には、正味現在価値、内部収益率、回収期間、割引回収期間の4つの指標を利用する
 

11章 「望ましさ」による優先順位づけ

  • 顧客満足度の狩野モデル
    • 当たり前、または必須のフィーチャ:フィーチャをどれだけ幅広く用意して、品質に磨きをかけても、当たり前のフィーチャであれば顧客満足度にほとんど影響を与えない
    • 線形、一元的なフィーチャ:あればあるほどよいもの。線形、一元的というのは、フィーチャの量に比例して顧客満足度が線形に高まることに由来する
    • 魅力的な、わくわくするフィーチャ:大きな満足をもたらしたり、わくわくする気持ちになったりするもの。このフィーチャは無いからといって顧客満足度が悪くなることはない。ユーザーは体験してみるまで、そうしたフィーチャが必要だということに気づかない
  • 当たり前のフィーチャを備えたら、線形のフィーチャをできるだけ多く完成させることを重視する。魅力的なフィーチャはこれらの機能を実装した後に、時間の許す範囲で対応する
  • ユーザーからアンケートを取ることで、フィーチャを簡単にカテゴリに分類することができる
 

12章 ユーザーストーリーの分割

  • 1つの大きなストーリーを見積もるよりも、分割して見積もった方が正確な見積もりになる
  • ユーザーストーリーを分割するタイミング
  • 大きなストーリーは、ストーリーで行う操作に沿って分割する。よくあるのは、CRUD操作を境界として分割することである
  • チームのイテレーション期間が2週間であれば、2日から5日で完了できる大きさにストーリーを分割するのが適切な大きさである
 

第4部 スケジュールを立てる

13章 リリース計画づくりの基本

  • 一般的には、3ヶ月から6ヶ月の周期でリリースを繰り返すことが多い
  • リリース計画は定期的な見直しと更新が必須である。多くのプロジェクトがイテレーション終了時点でリリース計画を見直すようにルールを定めている
 

14章 イテレーション計画づくり

  • イテレーションプランニングではタスクの担当者は決めない。タスクの担当者を決めるのは、イテレーションが始まってからである。また、一度に担当するタスクは1つであり、新しいタスクに着手するのは、前に担当したタスクを完了させてからである。イテレーションが始まる前に、全てのタスクの担当者を決めてしまうと、イテレーションのゴールに向かってチーム全員が一丸となって取り組むという参加意欲に水を差してしまう
  • アジャイルな計画づくりは二段階に分かれている。第一段階はリリース計画であり、この段階の計画は荒削りで全体的に不確定な部分が残っている。第二段階がイテレーション計画である。イテレーション計画は新しいイテレーションを始めるタイミングで実施するので、プロジェクトの中でチームが得た新しい知識を使ってリリース計画よりも詳細な計画を立てられる
  • リリース計画が3ヶ月から6ヶ月の期間を対象とするのに対し、イテレーション計画は1回のイテレーションだけを対象とする。リリース計画で扱う比較的大きなユーザーストーリーを、イテレーション計画ではタスクに分解する。ストーリーを分解したタスクは完了までの理想時間を単位として見積もる
  • イテレーション計画には、ユーザーストーリーをプロダクトに統合して動作させるために必要な全てのタスクを含めるべきである
  • タスクのサイズは、開発者が平均して1営業日に1つ完了できるくらいの大きさが適切である
 

15章 イテレーションの長さを決める

  • ほとんどのアジャイルチームは2週間から4週間のイテレーションを採用しているイテレーションの長さは、以下の要素を考慮して決めるのが良い
    • リリースまでの期間
    • 不確定要素の高さ
    • フィードバックの得やすさ
    • 優先順位が安定している期間
    • 外部からのフィードバックの必要性
    • イテレーションのオーバーヘッド
    • 切迫感を感じ始めるまでの時間
 

16章 ベロシティの見積もり

  • ベロシティの見積もり方法としての選択肢で望ましい順に以下がある
    • ベロシティの見積もりを出す前にイテレーションを1回でも実施できるなら迷わずそうする。実績値にまさる見積もりはない
    • 同じメンバーが携わった、今回のプロジェクトに関係のあるプロジェクトでの実績値を使う
  • どのやり方で見積もったにせよ、ベロシティの実績値を使えるようになったら、すぐそちらに切り替える
 

17章 不確実性に備えるバッファの計画

  • バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。
    • フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファである。時間が足りなくなったときは、フィーチャバッファにあるフィーチャを削ることでスケジュールを守る
    • スケジュールバッファは、スケジュールに適用するバッファである
 

18章 複数チーム編成プロジェクトの計画づくり

  • アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。チーム間で共有できる見積もり基準の確立、ユーザーストーリーの早い段階での詳細化などが必要となる
 

第5部 トラッキングと情報共有

19章 リリース計画のモニタリング

  • リリースバーンダウンチャートは、各イテレーションの開始時点でプロジェクト全体としてストーリーポイントがどれだけ残っているか把握するためのもので、プロジェクトの完了見込みがいつになるかを教えてくれる非常に強力なツールである
 

20章 イテレーション計画のモニタリング

  • タスクボードは、どのタスクが作業中で、どのタスクがサインアップ待ちなのかが一目でわかるツールである。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて対応するタスクカードをチームメンバーが順番に右側の列に動かしていく
 

21章 計画とコミュニケーション

  • 見積もりと計画のコミュニケーションは、正直で頻繁な、双方向のものであるべきである。これはアジャイルな計画とは頻繁に更新されるものであり、フィードバックと新しい知識を繰り返し反映させることで洗練させていくためである
 

第6部 なぜアジャイルな計画づくりがうまくいくのか

  • アジャイルな見積もりと計画づくりのための12のガイドライン
    • 1. チーム全体を巻き込む:見積もりはチーム全体で出すなどチーム全体の参加とコミットメントを引き出す
    • 2. 複数レベルの計画を立てる:リリース計画、イテレーション計画、今日の計画それぞれに狙いがある
    • 3. 大きさの見積もりと期間の見積もりを区別するために別々の見積もり単位を使う:作業の大きさにはストーリーポイント、期間にはベロシティを使うとよい
    • 4. 不確実性はフィーチャか日付のいずれかで表現する
    • 5. 頻繁に計画を見直す:新しいイテレーションを始めるタイミングは、現在のリリース計画を見直すいい機会である
    • 6. 進捗をトラッキングして情報を共有する:プロジェクトの進捗をあらわす手段には、バーンダウンチャートなどの一目でわかるグラフを使うのがベスト
    • 7. 学習することの大切さを受け入れる:新しく得た知識があれば、必ずそれを計画にも反映する
    • 8. フィーチャは適切な大きさで計画する:数イテレーション以内の近い将来に開発予定の機能は、比較的小さなユーザーストーリーに分割する。ユーザーストーリーのサイズは1、2日から10日位までの大きさが一般的である
    • 9. フィーチャを優先順位づけする:フィーチャの価値とコストだけでなく、フィーチャから得られる知識と、フィーチャを開発することで軽減できるリスクも考慮に入れる
    • 10. 現実に即した見積もりと計画を立てる
    • 11. ゆとりを残す:メンバー全員の時間を100%使い切るような計画を立てない
    • 12. 複数チームの連携には「移動する先読み範囲」を使う:チーム間で依存関係が生じるフィーチャについては、ある程度先を見越して、あらかじめ実装するイテレーションを決めておく
 

おわりに

ここまで読んでいただきありがとうございます。
アジャイルの合理的な考え方に共感し、是非一度やってみたいなーという気持ちになりました。
本書では具体例を多く取り入れながら一つ一つ詳しく解説してくれているので、アジャイルに興味を持った方は是非読んでみてください。

次はデータベース設計についての本を読むつもりです。

来週も頑張ります!

エンジニアがMac購入後にやっておきたい設定・環境構築・便利なツールまとめ

注文していたMacBook Airが昨日届きました。

同時にMacBook Air注文して、先に届いていた妻が参考にしたURLをまとめてくれており、設定・環境構築がすぐ終わりました

そんなツイートをしたところ、参考にしたURLを教えて欲しいと2人の方からリプをいただいたので簡単にまとめてみます。

せっかくなので僕が使っている便利なツールも紹介しています。

初めてMacを購入した方、MacからMacへ買い替えた方の設定・環境構築の参考になれば嬉しいです。

ちなみに、僕はRuby on Railsを使って開発をしていて、使用しているエディタはVimです。(Vim大好き!)

Macのバージョン:macOS Mojave 10.14.1 

f:id:ysk_pro:20190101115249p:plain

1. 必要なアプリのインストール(デスクトップアプリ)

まず必要なデスクトップアプリをApp Storeかインストールします。

  • Google Chrome : インストールするだけで同期してくれるので楽々
  • slack
  • LINE

 

2. 必要なソフトのインストール

 

3. 基本的なPCの設定

 

4. 開発環境構築

  • iTerm2導入(標準のターミナルアプリよりもずっと使い勝手がいいです)
    • Hotkey設定(僕はcontrolキーを2度押しでiTerm2が立ち上がるようにしています)
    • カラーテーマ設定(僕は目に優しいJapanesqueを使っています)

 

おわりに

みなさんが知っているものばかりだったでしょうか。

「こんな便利なツールあるよ!」など教えていただけるととても嬉しいです!

 

2018年に僕がエンジニアになって作ってきた個人開発webサービス 12個や書いてきたnoteなどをこちら↓の記事で紹介しているので、合わせてご覧いただけると嬉しいです!

また、使っているキーボードや椅子などの物理的な環境についてはこちら↓の記事に書いているのでご興味あればご覧ください!

エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り

もうすぐ2018年おわりますねー!

ということで、2018年にやったことを書き出して、KPTで振り返りをしてみました!

あー、楽しい1年だった。 

KPTというのは僕の会社で使っている振り返りのフレームワークです)

f:id:ysk_pro:20181231220832p:plain

(↑の画像は今まで作ったサービスの画像を適当にくっつけてみました。めっちゃごちゃごちゃしてる 笑)

1. 2018年にやったこと

  • ブログ 41記事
  • note 3記事
  • LT・登壇 4回
  • エンジニアのコミュニティに 3つ参加(もくもく会などは多数参加)

 

2. KPT

2-1. Keep(良かったこと / 今後も続けること)

  • インプット→アウトプットの習慣が作れたこと(学んだことをブログ・Twitter等でアウトプット)
  • 学習する習慣が作れたこと(技術書・個人開発での新技術等をほぼ毎日学習できた)

 

2-2. Problem(悪かったこと / 今後はやめること)

  • 勉強会などにあまり行けなかった(もっと人脈を広げたかった)

 

2-3. Try(次に挑戦すること)

  • 勉強会などに月1回以上参加する

※ 一応3つとも定量化したので、月1回以上は振り返って絶対達成するようにしたい

 

3. おまけ(1. の詳細)

ここからは長いのでご興味ある方はご覧ください。

作ってきたサービスnote技術チュートリアルLTを簡単に全て紹介していきます。

3-1. 2018年にリリースしたサービス

3-1-1. Jobmiru

渾身の処女作です...!

このサービスのおかげでDEMODAYというオリジナルサービスを発表するイベントに登壇できたり、エンジニアへ転職することができました。

最も思い入れのあるサービスです。

業種特化などして何とか使われるサービスに育てていきたい。

このサービスに込めた想いなどはこちらのブログに書いています。


3-1-2. Powertweet

 

3-1-3. BigTweet"1"(後に "2"を開発します) 

 

3-1-4. アイデアtweet


3-1-5. 今日雨降るよちゃん(LINE bot

僕が一番気に入ってるLINE botです。

開発のきっかけなどをこちらの記事に書いています。


3-1-6. お買い物メモ君(LINE bot

こちらのサービスについてはこの記事に書いています。


3-1-7. Tweet Searcher(LINE bot

自分で毎日使っているLINE botの一つです。便利!

 

3-1-8. BigTweet"2"

 

3-1-9. Blog Reader(LINE bot

 

3-1-10. いちにちをシェア


3-1-11. いちねんをシェア


3-1-12.  いちねんのさいてん

いちにちをシェア、いちねんをシェア、いちねんのさいてんについてはこちらのブログに書いています。


3-2. note

3-2-1. 僕はなぜ銀行を辞めたのか、なぜITエンジニアになったのか (+ 実際の転職活動について)


3-2-2. プログラミング歴6ヶ月の僕が自社サービスRailsエンジニアになりました!〜実際の転職活動について〜


3-2-3. 【資格試験勉強法】大量の資格を取得する銀行員時代に身につけた、そこそこの資格に「1ヶ月」で合格してきた超実践的勉強法


3-3. 技術チュートリアル

3-3-1. 【Big TweetチュートリアルRuby on Railsで簡単なサービスを作ってみよう!(初学者向け)


 3-3-2. LINE botチュートリアル【初学者向け】 〜Ruby on Railsでアイデアtweetを作ってみよう〜

 

3-3-3. 「今日雨降るよちゃん」を作ってみよう!【初学者向け】〜Ruby on RailsによるLINE botチュートリアル②〜 


3-3-4. 【初学者向け】Ruby on RailsでのLINE botチュートリアル第3弾〜Amazon API楽天APIを使ってお買い物Botを作ってみよう〜


3-3-5. 【BigTweetチュートリアル2】Ruby on Rails / JavaScriptで簡単なサービスを作ってみよう!(初学者向け)


3-4. LT・登壇

3-4-1. DEMODAY


3-4-2. 勉強会でのLT

 

3-4-3. DIVE INTO CODE(プログラミングスクール)のイベント


3-4-4. Ebisu.rb


4. おわりに 

ここまで読んでいただきありがとうございます。

こうまとめるとなんか色々やってきたなーという感じがします。

 

色々とやってこれたのは週末一緒に勉強 / 開発に付き合ってくれる妻(妻もエンジニアです!)のおかげであり、本当に感謝してもしきれないです。

 

エンジニアになってまだ半年、ここからさらに加速していきますー! 

【技術書まとめ18】Web API The Good Parts

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第18弾です。

今回は Web API The Good Parts を読みました。

Web APIの設計、開発、運用について解説しており、Web APIの開発者は必読と言われている本です。

今後のAPI開発で活かせそうなところ満載の良書でした。

Web API: The Good Parts

Web API: The Good Parts

 

f:id:ysk_pro:20181230095506p:plain

1章 Web APIとは何か

  • Web APIとは、あるURIにアクセスすることで、サーバ側の情報を書き換えたり、サーバ側に置かれた情報を取得したりすることができるwebシステムで、プログラムからアクセスしてそのデータを機械的に利用するためのものである。機械的にと言うのは、ブラウザを使って人間が直接アクセスすることを目的としたURIではないことを意味している
  • 新しいシステム、サービスを公開する力を持った開発者にAPIを公開することで、彼らがサービスに付加価値を与えてくれ、コアとなる自分たちのサービスがより発展する可能性がある
  • サービスにある機能を追加したいと思った時、デファクトとなっているサービスがすでに存在し、APIを公開している場合にはそこに繋いだ方が有利であることが多い。APIを用意することで様々なサービスと共存共栄することができるようになる
  • スマートフォンのアプリケーションがサーバと通信する必要がある場合、Web APIが利用されるのが最も一般的である
  • 設計の美しいWeb APIは変更しやすいモバイルアプリケーションの場合、アプリケーションのアップデートのタイミングはユーザー次第であり、バージョンアップをしたとしても古いバージョンを使うユーザーは存在し続けてしまうAPIの仕様を急に変化させるとそうした古いバージョンのアプリケーションは動かなくなってしまうので、APIの変更をいかに利用者に影響なく行うかは重要である
 

2章 エンドポイント設計とリクエストの形式

  • Web APIにおけるエンドポイントとはAPIにアクセスするためのURIのことであり、一般的なwebページのURIの設計の考え方がそのまま適用できる
  • 良いURI設計の原則は、覚えやすく、どんな機能を持つURIなのかが一目でわかることである
  • URIに大文字は使わず、すべて小文字を使うべき。HTTPにおいてURIは、スキーマとホスト名を除いて大文字と小文字は区別されるため、大文字を使うと別のURIとなってしまう
  • HTTPメソッドのPUTとPOSTの使い分け:どちらもサーバ側の情報を変更するためのメソッドであるが、Web APIではデータを修正する場合にPUTを用い、新しいリソースを生成する場合はPOSTを用いるのが一般的である
  • データの集合と個々のデータをエンドポイントとして表現し、それに対する操作をHTTPメソッドで表す考え方は、Web API設計の基本であり、多くのAPIがこれに沿った設計となっている
  • エンドポイントには複数形の名詞を用いるのが基本である。また、エンドポイント内で単語を2つ以上繋げる必要がある場合はハイフンを利用することが多い
  • クエリパラメータとパスの使い分け:一意なリソースを表すのに必要な情報はパスに入れた方が良く、省略可能な情報はクエリパラメータに入れる方が良い
  • ホスト名とエンドポイントの共通部分は「api.example.com」が主流であり、わかりやすさ、簡素さの観点から適切であると言える
  • 「1スクリーン1API、1セーブ1APIコール」という言葉があり、何度もAPIへのアクセスを繰り返すことは、速度の問題だけでなく、データの一部だけが表示されてしまう状態や、保存の際に一部のデータだけが保存されて整合性が保たれなくなってしまうといった問題を引き起こす可能性もあるので極力避けるべきである
  • 良い設計を見極めるには様々なAPIの実際の設計を調べ、比較してみることも重要である
 

3章 レスポンスデータの設計

  • JSONXMLよりも広まった理由は、JSONの方がシンプルで同じデータを表すのにサイズが小さくて済むこと、webの世界においてクライアントのデフォルト言語であるJavaScriptとの相性がとても良いことがあげられる
  • JSONPを使うと、JSONをscript要素を使ってJavaScriptとして読み込み、ドメインを超えたアクセスが可能となる。JSONPに対応しているAPIは多く存在するが、必要がないのであればセキュリティの観点からはなるべく対応しない方がよいとされている
  • クエリパラメータを使って、レスポンスの内容をユーザーが選択できるようにすることも有用である
  • レスポンスデータをフラットにするか階層化させるかについてGoogleJSON Style Guideでは「なるべくフラットにした方がいいが、階層構造を持った方がわかりやすい場合もある」とされており、それに従うのが良い
  • レスポンスで配列を返したい場合に、配列をそのまま返すことも、オブジェクトに包むこともできるが、セキュリティの観点からオブジェクトに包んだ方がベターである。トップレベルが配列であるJSONは、JSONインジェクションという脆弱性に対するリスクが大きくなる
  • 各データ項目(JSONのキー)の名前のつけ方のポイント
    • 多くのAPIで同じ意味に利用されている一般的な単語を用いる
    • なるべく少ない単語数で表現する
    • 複数の単語を連結する場合、連結方法はAPI全体を通して統一する:JSONではキャメルケースを使うのがよいとされているが、スネークケースなどを使っているAPIも多数存在する
    • 変な省略形は極力利用しない
    • 単数形/複数形に気をつける:そのキーで返るデータが複数なのか単数なのかで使い分ける(データを配列で返すときは複数形に、それ以外は単数形にする)
  • サーバがエラーを返す際に真っ先に行うべきことは、適切なステータスコードを使うことである。エラーの詳細を返す方法は、HTTPのレスポンスヘッダに入れて返す方法と、レスポンスボディで返す方法があるが、多くのAPIはレスポンスボディにエラーメッセージを格納する方法をとっている
 

4章 HTTPの仕様を最大限利用する

  • HTTPのキャッシュの仕組みをAPIでも利用する。HTTPのキャッシュは、2つのタイプがある
    • Expiration Model(期限切れモデル):あらかじめレスポンスデータに保存期限を決めておき、期限が切れたら再度アクセスをして取得を行うもの
    • Validation Model(検証モデル):今保持しているキャッシュが最新であるかを問い合わせて、データが更新されていた場合にのみ取得を行うもの
  • Content-Typeヘッダを使ってメディアタイプを指定するのは非常に重要であり、すべてのAPIは適切なメディアタイプをクライアントに返すべきである。クライアントの多くは、Content-Typeの値を使ってデータ形式を判断しており、その指定を間違えるとクライアントが正しくデータを読み出すことができないケースが出てくるためである
  • 独自のHTTPヘッダを定義して利用することも可能である
 

5章 設計変更しやすいWeb APIを作る

  • 一度公開したWeb APIの仕様を変更する場合は、新しいAPIを別のエンドポイント、あるいは別のパラメータをつけたURIなど、何らかの新しいアクセス形式で公開するのが良い。つまり、古い形式でアクセスしてきているクライアントに対してはそれまでと変わらないデータを送り、新しい形式でのアクセスには新しい形式のデータを返すといった複数のバージョンのAPIを提供するということである
  • APIのバージョンを表す方法は、URIのパスに”/v2/“のようにバージョンを埋め込む方法が最も一般的である
  • バージョニングのルールとして広く知られている手法にセマンティックバージョニングがある。Rubyなどでも基本的な考え方が導入されている。”1.2.3”という表記でそれぞれの数値はメジャー、マイナー、パッチと呼ばれ、以下のルールが適用される。(APIURIのバスにはメジャーバージョンのみを含める場合が多い)
    • メジャーバージョン:後方互換性のない変更が行われた際に増える
    • マイナーバージョン:後方互換性のある機能変更、あるいは特定の機能が今後廃止されることが決まった場合に増える
    • パッチバージョン:ソフトウェアのAPIに変更がないバグ修正などを行ったときに増える
  • 自社のアプリ向けAPIなどの場合には、あらかじめAPIの提供が終了した際の仕組みをクライアント側にも組み込んでおくべきである。一番簡単なのは強制アップデートで、アプリケーションを立ち上げた際に、現在のバージョンと最低限サポートされるクライアントのバージョンを比較し、サポートの切れたバージョンを使っていた場合は「サービスを使い続けるにはアップデート」してくださいと表示して、AppStoreなどを開くことである
 

6章 堅牢なWeb APIを作る

  • 本来アクセスできないはずの情報はサーバ側できちんとチェックをし、アクセスを禁止しておくべきである
  • パラメータなどを修正してリクエストを送ってくる場合もあるので、クライアントから送られてきた情報を信頼せず、サーバ側でも整合性をきちんとチェックする必要がある
  • 同じリクエストを再度送信される場合もあるので、そのような場合を想定したサーバ側でのチェックが必要となる
  • 一度に大量のアクセスをされてしまう問題を解決するための最も現実的な方法は、ユーザーごとのアクセス数を制限することである。つまり単位時間あたりの最大アクセス回数(レートリミット)を決め、それ以上のアクセスがあった場合にエラーを返すようにする
  • XSSXSRFなど通常のwebと同様のセキュリティだけでなく、JSONハイジャック(APIからJSONで送られてくる情報を悪意ある第三者が盗み取ること)などAPI特有の脆弱性に気を配る必要がある
  • セキュリティ強化につながるHTTPヘッダをきちんとつけるべきである
 

おわりに

ここまで読んでいただきありがとうございます。

Web APIの開発に関わっていて本書をまだ読んでいない方は是非読んでみることをおすすめします!

Web API: The Good Parts

Web API: The Good Parts

 

やっぱり年末年始は読書が捗りますね。

来週も頑張ります!

【年末年始に読みたい!】2018年に読んでよかった本5選

2018年も終わりますね。

個人的に2018年は、人生で一番かもしれないくらい激動の1年でした。(そんな1年のことは別の記事に書きたいと思っています。)

銀行員からエンジニアになったこともあり、今年は技術書を多く読みました。

(合計28冊の本を読んで、内18冊が技術書でした。)

その中で特に良かったなーと思う5冊を紹介します。

年末年始はTVを見るのもいいですが、ゆっくり読書して過ごすのも素晴らしいですよ

f:id:ysk_pro:20181228074105p:plain

1. チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 2018年で一番衝撃を受けた本です。

チーミング」という概念をもとに、学習する強い組織の作り方について書かれた本です。

最近よく耳にする心理的安全性」についてもこの本の中で詳しく解説されています。

マネジメントに関わる人は必読そうでない人も読んでおいて絶対に損ではない本だと思います。

リーダーが、管理ではなくエンパワーメントをするようになったら、適切な答えを与えるのではなく適切な質問をするようになったら、そして規則の遵守を主張するのではなく柔軟性に着目するようになったら、メンバーはもっと高いレベルで仕事を行えるようになる

心理的安全とは、関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。簡単なことに思えるが、同僚が見ているところで支援を求めたり失敗を許したりできるというのは思いのほか難しい場合がある。しかし、チーミングによって様々な意見の違いを超えて協働できるようになると、率直に会話したり失敗を隠さず話したり出来るようになる

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

2. お金2.0 新しい経済のルールと生き方

 「お金」というよりも「経済システム」の作り方について書かれており、僕が新しいwebサービスを作る際の考え方に大きな影響を与えてくれた本です。

この本はブログにまとめていないので、一部を引用にて紹介します。

 持続的かつ自動的に発展していくような「経済システム」にはどんな要素があるかを調べていった結果、5つほど共通点があることに気がつきました。 ①インセンティブ、②リアルタイム、③不確実性、④ヒエラルキー、⑤コミュニケーション、の5つです。

実際に社会で広く普及した経済システムは例外なくヒエラルキーが可視化されていて、明確な指標の役割を担います。  世の中には、偏差値、年収、売上、価格、順位のような数字として把握できるものから、身分や肩書きのような分類に至るまで、階層や序列に溢れています。

「世界を変える」とは、前時代に塗り固められた社会の共同幻想を壊して、そこに新しい幻想を上書きする行為に他なりません。国家、通貨、宗教、偏差値、学歴、経歴、年収、資産、倫理、権利など、私たちの精神や行動を縛る概念のほぼ全てが人工的に作られた幻想ですが、これらの効力が薄れ、時にはまた別の幻想が誕生し、人々の新たな価値判断の基準になっていきます。

これからは価値という観点から、自分なりの独自の枠組みを作れるかどうかの競争になります。枠組みの中の競争ではなく、枠組みそのものを作る競争です。そのためには自分の興味や情熱と向きあい、自らの価値に気づき、それを育てていく。そしてその価値を軸に自分なりの経済圏を作っていきます。

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

 

  

3. 漫画 君たちはどう生きるか

おいおい、オススメの本と言いながら漫画じゃねーか、と思った方もいると思います。

そうです、漫画です。

漫画なのでサクッと読めるのですが、学ぶこと・感じることがとても多かったです。

ベストセラーにもなっていたのでお読みになった方も多いかと思います。

少し長いですが、一部を引用にて紹介します。

悲しいことや、辛いことや、苦しいことに出会うおかげで、僕たちは本来人間がどういうものであるか、ということを知る。身体の痛みは、正常でないことを僕たちに知らせてくれるなくてはないのと同じように、心に感じる苦しみやつらさは、人間が人間として正常な状態にいないこと僕たちに知らせてくれるものであり。僕たちはその苦痛のおかげで、人間が本来どういうものであるべきかということを、心にとらえることができる。人間は、お互いに愛し合い、好意をつくしあって生きてゆくべきであり、誰だって自分の才能を伸ばし、その才能に応じて働いてゆけるのが本当なのに、そうでない場合があるから、人間はそれを苦しいと感じるのだ。僕たちは、自分の苦しみや悲しみから、いつでも、こういう知識をくみ出してこなければいけない。僕たちが、悔恨の思いに打たれるのは、自分はそうでなく行動することもできたのに、と考えるから。それだけの能力が自分にはあったのに、と考えるから。人間である限り、過ちは誰にだってある。そして、僕たちに苦しい思いをさせる。しかし、この苦しい思いの中から、いつも新たな自信をくみ出していこう。正しい道に従って歩いてゆく力があるから、こんな苦しむのだと。僕たちは自分で自分を決定する力を持っている。だから、誤りから立ち直ることも出来るのだ。

漫画 君たちはどう生きるか

漫画 君たちはどう生きるか

 

 

4. Webを支える技術

ここから2冊は技術書です。

エンジニア界隈では超有名なので説明するまでもないかもしれませんが、こちらはHTTP、URI、HTML、RESTなどのWebの基礎となる技術を解説している本です。

エンジニアとして働くにあたってWebの基礎知識は、知っていることが前提となる必須の知識であり、僕はこの本を通算4周読んでいます。

Webの基礎知識の概要を掴みたい方は必読だと思います。

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

5. 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

Webアプリケーションの脆弱性に関する名著です。

最近の話題に対応するべく第2版が2018/6に発売されました。

言うまでもないですがセキュリティはwebサービスを運営するにあたって超重要事項であり、僕の会社でこの本は勉強会の題材になりました

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

番外編 マンガ キングダム

今アツいマンガはやっぱりキングダムではないでしょうか。

もしまだ読んでいない方がいれば正月に一気読みしちゃいましょう!

(まだ読んでいない人はこれからこのマンガが読めると思うとうらやましい 笑)

  

おわりに

今年はエンジニアになったばかりということもあって、ベテランのエンジニアの方に聞いたおすすめの本を読むのが中心で、素晴らしい本にたくさん出会うことができました。

業務、書籍などから少しずつ知識がついてきたと感じているので、来年は自分に必要な本を自分で選んでいくことも行い、エンジニアとして知識の幅をどんどん広げていきたいと思っています。

来年も素晴らしい本、人生の幅を広げてくれるような本に出会えるのが楽しみです。

是非みなさんのおすすめの本も教えてください!