Slide 1
Slide 1 text
Webアプリケーション開発基礎
2025年度エンジニア内定者研修
Slide 2
Slide 2 text
Copyright © 2015 every, Inc. All rights reserved. 2
● 講義の目的とゴール
● Webアプリケーションの構成要素
○ 前置き
○ ブラウザが表示する HTMLはどこから取得できるのか
○ 外部データソースを利用した動的なレンダリング
● バックエンドとフロントエンド
○ バックエンド
○ フロントエンド
● 開発で必要な知識
○ アーキテクチャ
○ テスト
○ CI/CD
目次
Slide 3
Slide 3 text
講義の目的とゴール
Slide 4
Slide 4 text
4
Copyright © 2015 every, Inc. All rights reserved.
● Webサイト（Webアプリケーション）がどのようにしてユーザーに届けられているのかを知る
● Webアプリケーションの基本的な考え方を知る
● フロントエンドとバックエンドについて理解する
● チーム開発に必要な知識を知る
講義の目的とゴール
前置き
Slide 5
Slide 5 text
Webアプリケーションの構成要素
Slide 6
Slide 6 text
前置き
Slide 7
Slide 7 text
Copyright © 2015 every, Inc. All rights reserved. 7
「Webサイト」と「Webアプリケーション」の違いとは？🧐
【Webサイト】
【Webアプリケーション】
Webアプリケーションとは？
前置き
クライアント
（ブラウザ）
クライアント
（ブラウザ）
サーバ
サーバ
レスポンス
（HTML）
レスポンス
（結果）
リクエスト
（操作）
Slide 8
Slide 8 text
Copyright © 2015 every, Inc. All rights reserved. 8
Webページを構成する三大要素
前置き
Webページの「骨格」
見出し・段落・リストリン
クなどページの
構造を定義する役割
Webページの「見た目」
文字の色や大きさ・
レイアウト・背景色など
を装飾する役割
Webページの「動き・機能」
操作に応じた表示変更や
サーバーと通信するなど
ページに動きを与える役割
Slide 9
Slide 9 text
Copyright © 2015 every, Inc. All rights reserved. 9
HTML（HyperText Markup Language）：ハイパーテキスト を記述するためのマークアップ言語
→ 複数のテキストなどを相互に関連付けたシステム
HTMLとは？
前置き
Slide 10
Slide 10 text
Copyright © 2015 every, Inc. All rights reserved. 10
HTMLの基本構造
HTMLの基本的な構造
前置き
DOCTYPE宣言
html要素
head要素
body要素
HTMLの種類を宣言
HTMLの最上位要素
メタ情報（タイトル等）
本文を記述
HTML
見出し
Slide 11
Slide 11 text
Copyright © 2015 every, Inc. All rights reserved. 11
HTMLの基本構造
ブラウザが HTMLをどのように理解するか
前置き
DOCTYPE宣言
html要素
head要素
body要素
HTMLの種類を宣言
HTMLの最上位要素
メタ情報（タイトル等）
本文を記述
HTML
見出し
DOMツリーとして理解 （Document Object Model） ブラウザが変換Slide 12
Slide 12 text
Copyright © 2015 every, Inc. All rights reserved. 12
CSS（Cascading Style Sheets）：DOMツリーの各要素に対して色・サイズなどのスタイルを適用
CSSとは？
前置き
基本ルール
セレクター｛ プロパティ：値；｝
（どこの） （何を） （どうする）
CSSOMツリーとして理解
Slide 13
Slide 13 text
Copyright © 2015 every, Inc. All rights reserved. 13
JavaScript：クリックや入力をきっかけにDOMツリーを直接変更 （操作）することが可能
JavaScriptとは？
Webページの成り立ち
Slide 14
Slide 14 text
Copyright © 2015 every, Inc. All rights reserved. 14
DOMツリーとCSSOMツリーからレンダリングツリーを形成（各表示要素の計算に使用）
ブラウザの表示の仕組み：レンダリングツリーの構築
Webページの成り立ち
DOMツリー
CSSOMツリー
レンダリングツリー
画面に表示されない要素は含まれない（ ex. meta, head）
Slide 15
Slide 15 text
Copyright © 2015 every, Inc. All rights reserved. 15
レンダリングツリーの各ノードの位置と大きさを計算
ex. 「見出しを画面上部に配置して、その下に本文を置く」といった座標とサイズの計算をする
ブラウザの表示の仕組み：レイアウト
Webページの成り立ち
レンダリングツリー
Slide 16
Slide 16 text
Copyright © 2015 every, Inc. All rights reserved. 16
● レイアウトで決まった情報を元にピクセルを塗る処理を行う（文字色・背景色などを描画）
● その後、レイヤー合成をされて最終的に画面に表示される
ブラウザの表示の仕組み：ペイント
Webページの成り立ち
Slide 17
Slide 17 text
ブラウザが表示するHTMLはどこから取得できるのか
Slide 18
Slide 18 text
Copyright © 2015 every, Inc. All rights reserved. 18
Webサイトを訪問すると、ブラウザが HTML を元にページを描画する
しかし、肝心の HTML のソースは手元にはない・・・
＝＞ 「どこか」 から HTML をブラウザまで届ける必要がある 🧐
ブラウザが表示する HTMLはどこから取得できるのか
ブラウザで https://delishkitchen.tv/ にアクセスすると、以下の画面がブラウザで表示される
Slide 19
Slide 19 text
Copyright © 2015 every, Inc. All rights reserved. 19
ブラウザが表示する HTMLはどこから取得できるのか
「サーバー」が HTML をブラウザに渡す
ブラウザ（クライアント）は、 HTML を取得するためのリクエストを送信する
→サーバーがクライアントからのリクエストを受け取って、レスポンス (HTML)をブラウザに返す
（クライアント／サーバーシステムの一種）
第2章で登場したHTTPを用いて通信
GET “https://example.com/”
ステータスコード：200, OK
Slide 20
Slide 20 text
Copyright © 2015 every, Inc. All rights reserved. 20
サーバーが HTML を返す方法①
リクエストを受け取るたびに静的 HTML を返す
ブラウザが表示する HTMLはどこから取得できるのか 〜静的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
Slide 21
Slide 21 text
Copyright © 2015 every, Inc. All rights reserved. 21
サーバーが HTML を返す方法①
リクエストを受け取るたびに静的 HTML を返す
ブラウザが表示する HTMLはどこから取得できるのか 〜静的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
HTML
画面描画
Slide 22
Slide 22 text
Copyright © 2015 every, Inc. All rights reserved. 22
サーバーが HTML を返す方法①
リクエストを受け取るたびに静的 HTML を返す
ブラウザが表示する HTMLはどこから取得できるのか 〜静的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「材料から探す | 豚肉」をクリック
GET https://delishkitchen.tv/categories/458
HTML
画面描画
Slide 23
Slide 23 text
Copyright © 2015 every, Inc. All rights reserved. 23
サーバーが HTML を返す方法①
リクエストを受け取るたびに静的 HTML を返す
ブラウザが表示する HTMLはどこから取得できるのか 〜静的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「豚肉のレシピ」ページへ遷移
GET https://delishkitchen.tv/categories/458
静的HTML①
静的HTML②
画面描画
画面描画
Slide 24
Slide 24 text
Copyright © 2015 every, Inc. All rights reserved. 24
サーバーが HTML を返す方法①
リクエストを受け取るたびに静的 HTML を返す
ブラウザが表示する HTMLはどこから取得できるのか 〜静的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「豚肉のレシピ」ページへ遷移
GET https://delishkitchen.tv/categories/458
静的HTML①
静的HTML②
画面描画
画面描画
HTML はページ
ごとに異なる
Slide 25
Slide 25 text
外部データソースを利用した動的なレンダリング
Slide 26
Slide 26 text
Copyright © 2015 every, Inc. All rights reserved. 26
外部データソースを利用した動的なレンダリング 〜動的サイト〜
サーバーが静的な HTML を返す方式は、自由度が低くなってしまう
Slide 27
Slide 27 text
Copyright © 2015 every, Inc. All rights reserved. 27
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
DB
外部データソー
ス
Slide 28
Slide 28 text
Copyright © 2015 every, Inc. All rights reserved. 28
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
DB
外部データソー
ス
SELECT
おすすめレシピ動画
結果
Slide 29
Slide 29 text
Copyright © 2015 every, Inc. All rights reserved. 29
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
HTML
画面描画
DB
外部データソー
ス
埋め込み
SELECT
おすすめレシピ動画
結果
Slide 30
Slide 30 text
Copyright © 2015 every, Inc. All rights reserved. 30
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「豚肉のレシピ」ページへ遷移
GET https://delishkitchen.tv/categories/458
画面描画
DB
外部データソー
ス
SELECT
おすすめレシピ動画
結果
HTML
埋め込み
Slide 31
Slide 31 text
Copyright © 2015 every, Inc. All rights reserved. 31
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「豚肉のレシピ」ページへ遷移
GET https://delishkitchen.tv/categories/458
画面描画
DB
外部データソー
ス
SELECT
おすすめレシピ動画
SELECT
豚肉レシピ動画
結果
結果
HTML
埋め込み
Slide 32
Slide 32 text
Copyright © 2015 every, Inc. All rights reserved. 32
サーバーが HTML を返す方法②
リクエストを受け取るたびに動的にレンダリングした HTML を返す
外部データソースを利用した動的なレンダリング 〜動的サイト〜
イメージ
※実際のDK webの構成とは異なる部分があります ブラウザ サーバー
GET https://delishkitchen.tv/
「豚肉のレシピ」ページへ遷移
GET https://delishkitchen.tv/categories/458
HTML
画面描画
画面描画
DB
外部データソー
ス
埋め込み
SELECT
おすすめレシピ動画
SELECT
豚肉レシピ動画
結果
結果
HTML
埋め込み
Slide 33
Slide 33 text
バックエンドとフロントエンド
Slide 34
Slide 34 text
Copyright © 2015 every, Inc. All rights reserved. 34
多くのWebアプリケーションはだいたい次のような構成になっている
● ブラウザ
● Webサーバー
● APIサーバー
● データベース
主な登場人物
バックエンドとフロントエンド
ブラウザ Webサーバー APIサーバー データベース
Slide 35
Slide 35 text
Copyright © 2015 every, Inc. All rights reserved. 35
多くのWebアプリケーションはだいたい次のような構成になっている
● ブラウザ
● Webサーバー
● APIサーバー
● データベース
主な登場人物
バックエンドとフロントエンド
ブラウザ Webサーバー APIサーバー データベース
フロントエンド バックエンド
Slide 36
Slide 36 text
Copyright © 2015 every, Inc. All rights reserved. 36
フロントエンド
● 見た目の部分
● UI/UX
バックエンド
● 必要なデータの保存、整形、返却
それぞれの役割
バックエンドとフロントエンド
ブラウザ Webサーバー APIサーバー データベース
フロントエンド バックエンド
Slide 37
Slide 37 text
Copyright © 2015 every, Inc. All rights reserved. 37
● 責務が違う
○ フロントエンド：見た目に集中
○ バックエンド：データの処理に集中
● 柔軟性
○ 元々Pythonで書かれていたAPIサーバーをGoで書き換える、でもWebサーバーはそのまま
○ Web用に作られていたAPIサーバーをモバイルでも使えるようにする
この辺りは「アーキテクチャ」の説明でより詳しく説明します
なぜ分けるのか？
バックエンドとフロントエンド
ブラウザ Webサーバー APIサーバー データベース
フロントエンド バックエンド
Slide 38
Slide 38 text
フロントエンド
Slide 39
Slide 39 text
Copyright © 2015 every, Inc. All rights reserved. 39
● MPA, SPA
● SSR, CSR
● 使われている言語、フレームワーク
● DOM
● 非同期処理
● APIとの通信
目次
フロントエンド
Slide 40
Slide 40 text
MPAとSPA
Slide 41
Slide 41 text
Copyright © 2015 every, Inc. All rights reserved. 41
● 複数のページからなる
● ページ遷移のたびにサーバーへリクエストを送る
● サーバーは完成したHTMLをレンダリングして返す
● 2000年代前半以前のWebアプリケーションでよく見られた
MPA(Multiple Page Application)
フロントエンド
ブラウザ サーバー
①ページ訪問
レンダリング
された
HTML
HTML
②リンククリック
Slide 42
Slide 42 text
Copyright © 2015 every, Inc. All rights reserved. 42
メリット
● 初回ロードが軽い
● SEOに強い
デメリット
● ページ遷移のたびにフルリロードを行う → UXが良くない
● CSSやJavaScriptなどの共通リソースを毎回読み込む必要があり、
パフォーマンス面でオーバーヘッドが生じる
MPAのメリデメ
フロントエンド
Slide 43
Slide 43 text
Copyright © 2015 every, Inc. All rights reserved. 43
● JavaScriptを使って動的に更新
● ルーティングはブラウザ側で行われる
● History API
○ ブラウザのセッション履歴を管理する Web API (Web APIについては後述)
○ リロードせずとも、ブラウザの「戻る」「進む」ボタンが使える
● レンダリングもJavaScriptで動的に行う
● 2010年代前半
SPA(Single Page Application)
フロントエンド
ブラウザ サーバー
空のHTML
+
JavaScriptファイル
HTML
レンダリング
①ページ訪問
Slide 44
Slide 44 text
Copyright © 2015 every, Inc. All rights reserved. 44
メリット
● ページ遷移が高速
●
● バックエンドとフロントエンドが分けやすい（UIとリソースの分離）
デメリット
● SEOに弱い
● 初回ロードが重くなりやすい
● JavaScriptがクライアント側で肥大化しがち→パフォーマンスの悪化
SPAのメリデメ
フロントエンド
Slide 45
Slide 45 text
Copyright © 2015 every, Inc. All rights reserved. 45
CSR (Server Side Rendering)
● HTMLとJavaScriptがブラウザに送られてレンダリング
● 典型的なSPAはこっち
SSR (Client Side Rendering)
● サーバーでレンダリング済みのHTMLを返す
● 典型的なMPAはこっち
SPAも初期表示だけ SSRを採用すれば、デメリットを補える！
最近のフレームワークは大体CSR, SSRどちらにも対応している
CSRとSSR
フロントエンド
ブラウザ サーバー
①ページ訪問
レンダリン
グされた
HTML
HTML
②リンククリック
ブラウザ サーバー
空のHTML
+
JavaScriptファイル
HTML
レンダリング
①ページ訪問
Slide 46
Slide 46 text
使われている言語・ライブラリ・フレームワークなど
Slide 47
Slide 47 text
Copyright © 2015 every, Inc. All rights reserved. 47
言語
● HTML
● CSS
● JavaScript
● TypeScript (JavaScriptに型システムを入れたもの)
ライブラリ
● React
● Vue
フレームワーク（どちらもSSRに対応）
● Nextjs
● Nuxtjs
主な言語・ライブラリ・フレームワーク
フロントエンド
Slide 48
Slide 48 text
Copyright © 2015 every, Inc. All rights reserved. 48
● JavaScriptのランタイム環境
● Google Chromeと同じV8エンジンを採用
● JavaScriptをサーバーサイドで実行可能
● fsモジュールなどでファイルの読み書きもできる（サーバーならでは）
npm
● Node.jsのパッケージ管理ツール
ランタイム環境は他にもBunやDeno、パッケージ管理ツールはyarnやpnpmなど色々ある
Node.js
フロントエンド
Slide 49
Slide 49 text
DOM
Slide 50
Slide 50 text
Copyright © 2015 every, Inc. All rights reserved. 50
DOMとは
フロントエンド
● DOM (Document Object Model)
○ HTMLやXMLドキュメントの構造、操作を定義したもの
● DOMツリー
○ DOMから作られる木構造のオブジェクト
JavaScriptはこのDOMを操作して画面の更新を行う
Slide 51
Slide 51 text
Copyright © 2015 every, Inc. All rights reserved. 51
● 実際のDOMの軽量コピーをメモリ上に持つ仕組み
● VueやReactなどで用いられる
● 差分を計算し最小限の変更のみを実際のDOMに適用、同期する
→ JavaScriptとDOMの中間レイヤーとして仮想DOMを挟むことで、実DOMを効率的に操作できる！
仮想DOM
フロントエンド
メモリ上で差
分を計算
実際のDOM
に反映
Slide 52
Slide 52 text
Copyright © 2015 every, Inc. All rights reserved. 52
● jQuery時代
○ .addClass()や.append()など、命令的にDOMを直接いじる
○ 「こうして、ああして」の処理を書いていくので、状態が追いづらい
● ReactやVueなど、宣言的なフレームワークの登場
○ 「今の状態はこう」と宣言的に UIを記述できる
○ 宣言したものを全て再描画していたらコストが高すぎる
→差分の計算の必要性が高まり、仮想 DOMが導入された
仮想DOMが出てきた背景
フロントエンド
Slide 53
Slide 53 text
JavaScriptの非同期処理
Slide 54
Slide 54 text
Copyright © 2015 every, Inc. All rights reserved. 54
↔ 同期処理 : 複数のタスクを実行する際に順に実行される
ファイル操作やAPIリクエストのような重いタスクを実行する際に、処理をバックグラウンドに移すことでタスクの
処理を止めることなく別のタスクを実行できる
→ JavaScriptエンジンはシングルスレッド
これのみでは非同期処理は実現できないので他の仕組みを利用している！
非同期処理とは
フロントエンド
Slide 55
Slide 55 text
Copyright © 2015 every, Inc. All rights reserved. 55
ブラウザでの非同期処理
Web APIを用いることで非同期処理を実現している
Web APIの例
● fetch api
● storage api
● DOM
ブラウザは複数のスレッドを持っており、メインスレッドとブラウザのスレッドに分けられる
1. メインスレッドから非同期処理を呼び出す
2. Web APIが呼び出される
3. Web APIがブラウザのスレッドで実行される
4. 完了後コールバックがタスクキューに追加される
5. メインスレッドが空くとコールバックがメインに移動し実行される
フロントエンド
メインスレッド
（コールスタック）
Web API
タスクキュー
非同期処理
イベント
ループ
監視
非同期処理 コールバック
1
2
3
コールバック
コールバック
コールバック
4
5
Slide 56
Slide 56 text
Copyright © 2015 every, Inc. All rights reserved. 56
● 再読み込みをせずに画面の状態を変えられる
● 例：Google Mapの移動
● 今まで散々上のことについて喋ってきたが、当時はすごいことだった
参考：
Ajax (Asynchronous JavaScript and XML)
● JavaScriptを使った非同期処理の技術
● 現在はあまり使われていない
● XMLHttpRequestを使ったHTTP通信
● 初期のGoogle Mapに使われた
● 直接DOM変更を行う
非同期処理は何が偉いのか？
フロントエンド
Slide 57
Slide 57 text
APIとの通信
Slide 58
Slide 58 text
Copyright © 2015 every, Inc. All rights reserved. 58
動的コンテンツや負荷の高い処理、外部システムの利用などF/Eで完結できないことが多い
● レシピデータやユーザーデータなどの動的なコンテンツはDBに保存されている
● 画像の加工やDBから取得したデータの操作など負荷の高い処理はB/Eが行う
● 認証認可などの複雑な処理は自作したくない
APIとの通信
フロントエンド
Slide 59
Slide 59 text
Copyright © 2015 every, Inc. All rights reserved. 59
動的コンテンツや負荷の高い処理、外部システムの利用などF/Eで完結できないことが多い
● レシピデータやユーザーデータなどの動的なコンテンツはDBに保存されている
● 画像の加工やDBから取得したデータの操作など負荷の高い処理はB/Eが行う
● 認証認可などの複雑な処理は自作したくない
→ APIを呼び出すことで上記の問題を解決する !
APIとの通信
フロントエンド
Slide 60
Slide 60 text
Copyright © 2015 every, Inc. All rights reserved. 60
API通信フロー
リクエストの作成・送信
● url, method, parameterなどを指定してリクエストを送信する
レスポンスの受信
● status codeやbody(jsonなど)を受け取る
データの利用
● レスポンスを元に状態やDOMの更新を行う
これらの処理はfetchやaxiosなどの非同期通信 を用いる
フロントエンド
Slide 61
Slide 61 text
バックエンド
Slide 62
Slide 62 text
Copyright © 2015 every, Inc. All rights reserved. 62
● データの処理
● ビジネスロジック
● API
● 認証・認可
● 使われている言語、フレームワーク
目次
バックエンド
Slide 63
Slide 63 text
データの処理
Slide 64
Slide 64 text
Copyright © 2015 every, Inc. All rights reserved. 64
● 外部ソースからデータを取得しフロントエンドに返す
● フロントエンドから来たデータを外部ソースに永続化したり送ったりする
基本的にはこの2つだけ
基本的な役割
バックエンド
バックエンド
サーバー
外部
データソース
サーバー
クライアント
外部データソースから見るとバックエンドサーバーがクライアント
Slide 65
Slide 65 text
Copyright © 2015 every, Inc. All rights reserved. 65
● データベース
○ RDB
■ MySQL
■ PostgreSQL
○ NoSQL
■ DynamoDB
■ MongoDB
● キャッシュ
○ オンメモリキャッシュ
○ リモートキャッシュ
■ Redis
■ Amazon ElastiCache
● 外部API
○ 認証や課金用のAPI
○ 企業が提供するAPI
● クラウドストレージ
○ Amazon S3
○ Google Cloud Storage
外部ソースの例
バックエンド
Slide 66
Slide 66 text
ビジネスロジック
Slide 67
Slide 67 text
Copyright © 2015 every, Inc. All rights reserved. 67
● 外部からデータを取得しフロントエンドに返す
● フロントエンドから来たデータを外部に永続化したり送ったりする
基本的にはこの2つだけ
基本的な役割
バックエンド
バックエンド
サーバー
外部
データソース
サーバー
クライアント
外部データソースから見るとバックエンドサーバーがクライアント
Slide 68
Slide 68 text
Copyright © 2015 every, Inc. All rights reserved. 68
● 外部からデータを取得し（整形して）フロントエンドに返す
● フロントエンドから来たデータを（整形して）外部に永続化したり送ったりする
基本的にはこの2つだけ
基本的な役割
バックエンド
バックエンド
サーバー
外部
データソース
サーバー
クライアント
外部データソースから見るとバックエンドサーバーがクライアント
Slide 69
Slide 69 text
Copyright © 2015 every, Inc. All rights reserved. 69
（雑に言うと）アプリケーション特有の整形、バックエンドサーバーの中核の役割
● ECサイト：注文金額が5000円以上なら送料を無料にする
● SNS：フォローしていない人の投稿は表示しない
● 予約サイト：前日になったらキャンセルできない
など。これはフロントエンドに書かない
レスポンスのための整形
● 日付のフォーマット
● DBには1がiOS、2がAndroidとして保存されているのを、stringに変換する
などはビジネスロジックではない
が、少なくとも後者はバックエンドサーバーで実装すべきこと
ビジネスロジック
バックエンド
Slide 70
Slide 70 text
API
Slide 71
Slide 71 text
Copyright © 2015 every, Inc. All rights reserved. 71
● プログラムにとってのインターフェース
● Webアプリケーションで使われるほとんどのAPIは以下のどちらかの形式のデータを返す
○ JSON
○ XML
API (Application Programming Interface)
バックエンド
Slide 72
Slide 72 text
Copyright © 2015 every, Inc. All rights reserved. 72
ヘッダ
● Content-Type：レスポンスの種類
● Authorization：認証情報
● Cache-Control, Expires：キャッシュに関する情報
● Last Modified：最後に更新された日時
リクエスト種類
● GET：取得
● POST：作成
● PUT：（全体）更新
● PATCH：（一部）更新
● DELETE：削除
HTTPリクエスト
バックエンド
Slide 73
Slide 73 text
Copyright © 2015 every, Inc. All rights reserved. 73
● よく使われるAPIの設計手法
● 次の6つの条件を満たす
○ クライアント／サーバー (Client-Server)
○ ステートレス (Stateless)
○ キャッシュ (Cache)
○ 統一インターフェース (Uniform Interface)
○ 階層システム (Layered System)
○ オンデマンドのコード (Code-On-Demand)
例：
/users/1 → ユーザー情報
/users/1/orders → 注文履歴
REST API
バックエンド
Slide 74
Slide 74 text
Copyright © 2015 every, Inc. All rights reserved. 74
● 比較的新しい設計手法
● Facebookが開発したOSS
● 必要なデータをクエリで指定できる
● 一度に複数のデータを取得できる
例：
query { user(id:1){ name, orders } } → クエリで複数のデータを取得
GraphQL
バックエンド
Slide 75
Slide 75 text
認証・認可
Slide 76
Slide 76 text
Copyright © 2015 every, Inc. All rights reserved. 76
● 認証（Authentication）
○ ユーザーが本人であることを証明する仕組み
● 認可（Authorization）
○ ユーザーに対して、アクセスできるリソースや操作を制御する仕組み
似てるけど別物
例：特定のCIDRからだけアクセスを許可する（認証はしてないけど認可はしている）
認証・認可
バックエンド
Slide 77
Slide 77 text
Copyright © 2015 every, Inc. All rights reserved. 77
● 認可のための仕組み
● アクセストークンを使って、自分の認証情報を第三者のアプリケーションに渡すことなく、捜査の許可をす
る
● 代表的なフローはAuthorization Code Flow (複雑なので各自調べてください)
例：あるアプリがGoogleカレンダーに予定を書き込みたいとき、ユーザーがGoogleログインして承認すると、ア
クセストークンを使ってカレンダーへの書き込みを行う
OAuth2.0
バックエンド
Slide 78
Slide 78 text
Copyright © 2015 every, Inc. All rights reserved. 78
● OAuthの拡張仕様
● アクセストークンに加えてIDトークン(JWT)も渡すことで、認可と同時に認証も行う
例：SSO（シングルサインオン）
OpenID Connect
バックエンド
Slide 79
Slide 79 text
アーキテクチャ
Slide 80
Slide 80 text
Copyright © 2015 every, Inc. All rights reserved. 80
アーキテクチャとは
アーキテクチャとは
→システムを構築するための設計思想や構造
Slide 81
Slide 81 text
Copyright © 2015 every, Inc. All rights reserved. 81
アーキテクチャの目的
アーキテクチャの目的
● システム構造の明確化
● システムの保守性、拡張性の向上
● 再利用性の向上
Slide 82
Slide 82 text
Copyright © 2015 every, Inc. All rights reserved. 82
システム構造の明確化
アーキテクチャの目的
システム全体の見通しを良くし、開発者間で共通の理解を持つことができる
→ システム全体を把握せずとも、特定の部分を効率的に開発したり修正したりすることができる
Slide 83
Slide 83 text
Copyright © 2015 every, Inc. All rights reserved. 83
システム構造の明確化
アーキテクチャの目的
例. MVCを用いた場合
● Model : ビジネスロジックを管理する。データベースや外部APIからデータ取得・保存を行う
● View : ユーザーに情報を表示する部分。画面のレイアウトなどのインターフェースを提供する
● Controller : ユーザー入力を受け取り、ModelやViewに伝える。
View
Controller
Model
Slide 84
Slide 84 text
Copyright © 2015 every, Inc. All rights reserved. 84
システム構造の明確化
アーキテクチャの目的
Q. 「入力フォームの位置を変えてほしい」どこを修正すれば良い？
A. View
→ ModelやControllerなどでどのような実装がされているか完全に把握する必要がない！
View
Controller
Model
Slide 85
Slide 85 text
Copyright © 2015 every, Inc. All rights reserved. 85
保守性・拡張性の向上
保守性 : システムの修正や更新する際の容易さ
拡張性 : システムに新しい機能を追加する際の容易さ
アーキテクチャの目的
Slide 86
Slide 86 text
Copyright © 2015 every, Inc. All rights reserved. 86
保守性・拡張性の向上
保守性 : システムの修正や更新する際の容易さ
● コードの分割やテスト可能な設計を行うことで向上する
○ 責務を明確にし最小限にすること(SRP Single Responsibility Principle)
○ 重複したコードを減らす(DRY Don’t Repeat Yourself)
アーキテクチャの目的
Slide 87
Slide 87 text
Copyright © 2015 every, Inc. All rights reserved. 87
保守性・拡張性の向上
アーキテクチャの目的
拡張性 : システムに新しい機能を追加する際の容易さ
● 設計の柔軟性が高く、変化に対応しやすいことが求められる
○ オープン・クローズドの原則(OCP)に基づいた設計
○ 将来の変更を想定した構造化
■ インターフェースの汎用化
■ 例 REST APIなど
Slide 88
Slide 88 text
Copyright © 2015 every, Inc. All rights reserved. 88
再利用性の向上
アーキテクチャの目的
開発したコンポーネントやモジュールを他のプロジェクトや機能で再利用できる
● コスト削減 : 開発やテストの手間を軽減
● 一貫性: 同じロジックを利用することでエラーやバグの可能性の減少
Slide 89
Slide 89 text
Copyright © 2015 every, Inc. All rights reserved. 89
再利用性の向上
アーキテクチャの目的
例：UIコンポーネントのモジュール化
● ボタンやモーダル、フォームなどを再利用可能なコンポーネントとして設計
Slide 90
Slide 90 text
アーキテクチャの種類
Slide 91
Slide 91 text
B/E
Slide 92
Slide 92 text
Copyright © 2015 every, Inc. All rights reserved. 92
アーキテクチャの分類
B/E
層ベースのアーキテクチャ
Layered Architecture
Clean Architecture
Hexagonal Achitecture
ドメイン中心アーキテクチャ
DDD
分散システムアーキテクチャ
Microservice Architecture
Event-Driven Architecture
Slide 93
Slide 93 text
Copyright © 2015 every, Inc. All rights reserved. 93
Layered Architecture
B/E - 層ベースのアーキテクチャ
● 役割ごとに層として分離
● 層ごとに依存関係が明確に
● 小~中規模のシステムで利用される
上の層は下の層に依存し、下の層は上を知らない
Slide 94
Slide 94 text
Copyright © 2015 every, Inc. All rights reserved. 94
Layered Architecture: クイズ1
B/E - 層ベースのアーキテクチャ
シナリオ：レシピデータをMySQLに保存する
問題：「ライブラリを使用してSQL INSERT文を実行する」処理はどの層に実装すべきですか？
A. User Interface層（フォーム送信処理の一部として）
B. Business Logic層（レシピ作成ロジックとして）
C. Data層（データアクセス抽象化として）
D. Infrastructure層（SQL実行の技術的実装として）
Slide 95
Slide 95 text
Copyright © 2015 every, Inc. All rights reserved. 95
Layered Architecture: クイズ2
B/E - 層ベースのアーキテクチャ
シナリオ：レシピ検索結果を返す実装を行うが、以下のルールを適用させたい
● ユーザーがプレミアム会員の場合、お気に入りレシピを上位3件に表示
● 通常会員の場合、お気に入りレシピに「★」マークを付けるだけ
● 残りは人気順でソート
問題：この「お気に入りレシピの表示順制御」ロジックはどの層に実装すべきですか？
A. User Interface層（画面表示のレイアウト制御として）
B. Business Logic層（ビジネスルールの実装として）
C. Data層（データ取得時のソート処理として）
D. Infrastructure層（キャッシュシステムの一部として）
Slide 96
Slide 96 text
Copyright © 2015 every, Inc. All rights reserved. 96
Clean Architecture
B/E - 層ベースのアーキテクチャ
● Entities(ビジネスロジック)を中心に設計
● それぞれの層の依存関係を外→内に明確化
● フレームワークやインフラ(DB等)に依存しない状態
にすることで変更や拡張に強い
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Slide 97
Slide 97 text
Copyright © 2015 every, Inc. All rights reserved. 97
DDD
B/E - ドメイン中心アーキテクチャ
● ドメイン駆動設計(Domain-Driven Design)
● ドメインモデルに重点を置き、ビジネスロジックを
中心に設計
● 複雑なビジネスロジックに対して効果的
Slide 98
Slide 98 text
Copyright © 2015 every, Inc. All rights reserved. 98
Microservice Architecture
B/E - 分散システムアーキテクチャ
A B
C D A
B C
D
User Interface User Interface
● アプリケーションを、独自の責任範囲を持つ独立した小さな部分に分割
○ 例. 全社共有の認証機能を認証サービスとして独立させる
● 大規模システムやスケーラブルなシステムで利用
● 各サービスの管理コストが増加してしまうデメリットもある
従来の設計 マイクロサービスアーキテクチャ
Slide 99
Slide 99 text
F/E
Slide 100
Slide 100 text
Copyright © 2015 every, Inc. All rights reserved. 100
アーキテクチャの分類
F/E
コンポーネント中心アーキテクチャ
Atomic Design
機能中心アーキテクチャ
Feature-Based Architecture
層ベースのアーキテクチャ
Layered Architecture
Slide 101
Slide 101 text
Copyright © 2015 every, Inc. All rights reserved. 101
Atomic Design
F/E
● UIコンポーネントを右図のように分割
● それぞれのコンポーネントの組み合わせで上位
のコンポーネントを表現
● スタイルの共通化や再利用性が向上
https://atomicdesign.bradfrost.com/
Slide 102
Slide 102 text
Copyright © 2015 every, Inc. All rights reserved. 102
Atomic Design
F/E
Organisms
Molecules
Atoms
Slide 103
Slide 103 text
テスト
Slide 104
Slide 104 text
Copyright © 2015 every, Inc. All rights reserved. 104
テスト(test)とは？
テスト(test)の本質は「（実力・性能を測る）検査」をすること
テスト
https://ejje.weblio.jp/content/test#goog_rewarded
Slide 105
Slide 105 text
Copyright © 2015 every, Inc. All rights reserved. 105
ソフトウェアエンジニアリングにおけるテスト (test)とは？
テスト
ソフトウェアテストは、欠陥を発見し 、
ソフトウェアアーティファクトの品質を評価する ための一連の活動
テストでは指定されている要件をシステムが満たすかどうか の確認（検証）に加えて、
ユーザーやその他のステークホルダーのニーズを
運用環境でシステムが満たしていること （妥当性）を確認
JSTQB テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 | 1.1 テストとは何か？ より抜粋
Slide 106
Slide 106 text
Copyright © 2015 every, Inc. All rights reserved. 106
● 静的テスト （プログラムの実行を伴わないテスト）
○ 静的解析
■ タイプミスや型エラーがないかなどを確認する
■ コードレビュー
■ etc.
● 動的テスト （プログラムの実行を伴うテスト）
○ ユニットテスト
○ 結合テスト
○ システムテスト
○ E2Eテスト
○ 受け入れテスト
テストのスコープ
良いコードを書くために
Slide 107
Slide 107 text
Copyright © 2015 every, Inc. All rights reserved. 107
● ブラックボックステスト
○ 仕様に基づく手法。内部構造は気にせず振る舞いをテストする。
○ 利用者視点のテスト
■ 境界値分析
■ 同値分割法
■ etc.
● ホワイトボックステスト
○ 構造に基づく手法。内部構造や処理を流れをテストする。
○ 作成者視点のテスト
■ ステートメントテスト
■ ブランチテスト
■ etc.
テスト手法
良いコードを書くために
Slide 108
Slide 108 text
Copyright © 2015 every, Inc. All rights reserved. 108
テストが無いとどうなるか？
テスト
● プロダクトに混入したバグに気づけない
● 仕様・要件を十分に満たしていないことに気づけない
● etc.
● ユーザーからの不満を買ってしまう
● プロダクト・企業への不信感を募らせてしまう
● etc.
Slide 109
Slide 109 text
Copyright © 2015 every, Inc. All rights reserved. 109
テストが無いとどうなるか？ case.1
テスト
b = 0 のとき、ゼロ除算でランタイムエラー
Slide 110
Slide 110 text
Copyright © 2015 every, Inc. All rights reserved. 110
テストが無いとどうなるか？ case.1
テスト
仕様：税額は「円未満切り捨て」
実装：四捨五入（math.Round）しており、1円多く請求するケースがある
（107 x 1.08 = 115.56 → 115円が実際は正しいが、上記コードでは
116円になり多く請求してしまう）
Slide 111
Slide 111 text
Copyright © 2015 every, Inc. All rights reserved. 111
テストが無いとどうなるか？ case.2
テスト
User オブジェクトのプロパティconcern が
初期化されていない
→ panic になる
Slide 112
Slide 112 text
Copyright © 2015 every, Inc. All rights reserved. 112
テストは大事！
テスト
● 自分のミスを防ぐため
● プログラムの振る舞いを明確にするため
● バグを早期発見するため
● etc.
Slide 113
Slide 113 text
CI/CD
Slide 114
Slide 114 text
Copyright © 2015 every, Inc. All rights reserved. 114
● CI (Continuous Integration, 継続的インテグレーション)
● CD (Continuous Delivery/Deploy, 継続的デリバリー／デプロイ)
CI/CDとは？
CI/CD
https://circleci.com/ja/blog/what-is-ci-cd/
Slide 115
Slide 115 text
Copyright © 2015 every, Inc. All rights reserved. 115
● CI (Continuous Integration, 継続的インテグレーション)
○ 自動で作業成果物をテストしてリポジトリに共有する
○ 開発者のコード作成に関与する
● CD (Continuous Deploy, 継続的デプロイ)
○ 自動で作業成果物を運用システムに反映させる
○ 完成したコードに関与する
CI/CDの目的・意義
CI/CD
Slide 116
Slide 116 text
Copyright © 2015 every, Inc. All rights reserved. 116
CI/CDのメリット
CI/CD
● コードの共有・テスト／デプロイを自動化できる
● 開発サイクルを高速化できる
● コード品質を一定に保つことができる
Slide 117
Slide 117 text
Copyright © 2015 every, Inc. All rights reserved. 117
開発 → CI → レビュー → マージ → ビルド・デプロイ
CI/CDフロー
CI/CD
https://circleci.com/ja/blog/what-is-ci-cd/
Slide 118
Slide 118 text
Copyright © 2015 every, Inc. All rights reserved. 118
● lint
○ ソースコードの静的解析
● format
○ ソースコードのフォーマッティング
● test
○ ソースコードのテスト
CIで使っている解析ツール例
CI/CD
Slide 119
Slide 119 text
Copyright © 2015 every, Inc. All rights reserved. 119
CIのユースケース〜 lint/format/test〜
CI/CD
commit/push
pre commit/push
lint/format
test
Slide 120
Slide 120 text
Copyright © 2015 every, Inc. All rights reserved. 120
● デプロイ
○ EC2のデプロイ
○ ECSサービス／タスクのデプロイ
○ Lambda Functions のデプロイ
○ フロントエンドのビルド成果物を S3 にプッシュする
○ etc.
CDのユースケース
CI/CD
Slide 121
Slide 121 text
Copyright © 2015 every, Inc. All rights reserved. 121
CDのユースケース〜ビルド成果物を S3にプッシュ〜
CI/CD
push
pre commit/push
lint/format
test
next build
aws s3 sync
Slide 122
Slide 122 text
Copyright © 2015 every, Inc. All rights reserved. 122
● エブリーで利用されているもの
○ GitHub Actions
○ Circle CI
○ CodeBuild(AWSのCI/CD自動化サービス)
● その他
○ Jenkins
○ etc.
CI/CDツールの紹介
CI/CD
Slide 123
Slide 123 text
Copyright © 2015 every, Inc. All rights reserved. 123
● 開発者向けのウェブ技術 | MDN
● レンダリングの仕組み | Vue.js
● TypeScript誕生の背景 | TypeScript入門『サバイバルTypeScript』
● Actions | GitHub
● AWS CodeBuild（継続的スケーリングによるコードのビルドとテスト） | AWS
● Jenkins
● Clean Coder Blog
● Atomic Design by Brad Frost
● CI/CD とは？開発に欠かせない理由と必要性を解説
● AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS
● Dissecting layered architecture - DEV Community
● マイクロサービス アーキテクチャとは | Google Cloud
● マイクロサービスとは？ そのメリットを簡単に解説（初心者・非エンジニア向け） - NCDC株式会社
参考・引用