- このページのURLは http://bit.ly/31ST1wX です。
- このページの共有チャット参加方法
- 画面左上の「Start TogetherJS」をクリック
- 「I'm ready!」ボタンをクリック
- 共有チャットURLここをクリック
情報アーキテクチャ -情報の設計と実装-
講義の説明
はじめに
- 「情報アーキテクチャ」を学ぶことで、情報をどのように扱えばより有意義(高価値)になるのか、根拠を持って考えることができるようになります。
- 情報アーキテクチャ（IA:インフォメーションアーキテクチャ）は「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術
- 主にウェブサイトやアプリケーション、ソフトウェアなどのデジタル製品において重要な役割を果たします。
- 図書館や博物館などの物理的な空間にも適用されることがあります。
- 本講義では情報アーキテクチャに関するプラクティスを紹介しています。
- プラクティスとは「効率の良い手法や方法論」のことを言います。
- プラクティスは知識として覚えただけでは上手く使用することはできません。実践して失敗して再挑戦して、というプロセスを繰り返すことで体得できます。
- ですので、本講義では実習を通して学んでもらう構成になっています。
- 前提知識はあまり必要ありませんので、肩の力を抜いて気楽に自由に発想しながら受講してください。
目的
- 情報アーキテクチャについて説明できるようになる
- ペルソナの視点で情報を整理・分類できるようになる
- 情報アーキテクチャを企画・設計・開発に適用できるようになる
- 情報の設計とシステムの設計を分離して開発を進められるようになる
- プレゼンテーションと機能を分離して開発を進められるようになる
やること
- 情報アーキテクチャの手法を座学で学ぶ
- 情報アーキテクチャの手法を実際に試す
- 開発のテーマを決定し、テーマに沿った情報を洗い出す
- 開発テーマは情報処理を伴えば何でも良い
- 例)
- 家計簿システム
- レシピを類推するサービス
- オークションシステム
- 洗い出した情報を整理・分類し、設計を行う
- 設計を元に実装を行う
- 開発のテーマを決定し、テーマに沿った情報を洗い出す
心がけて欲しいこと
- 知識体系や方法論を理解し、演習で体得する
- 演習における気づきを共有する
- PDCAを小さく沢山繰り返す
- Plan（計画）→ Do（実行）→ Check（評価）→ Action（改善）
スケジュール(講義数が4コマの場合)
スケジュール(講義数が15コマの場合)
知識体系「情報アーキテクチャ」の位置づけ
- 情報アーキテクチャ（IA:インフォメーションアーキテクチャ）は「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術
- Webサイト設計から生まれた概念
- UXの1要素
- 簡単に言うと「情報をよりよく整理するための知識体系」
- 情報産業における「価値」はハードウェアから徐々にソフトウェアやサービスに移行し、扱う情報量は増加傾向にある。そのため、情報を適切にまとめる「情報アーキテクチャ」の重要度が増している。
(参考)
図の解説
- 「User Needs(要求・要望・要件)」と「Site Objectives(目標・目的)」が目に見えない情報
- お客様やユーザが持っている情報・手法
- 「Visual Design(視覚的なデザイン)」が目に見える情報
- お客様やユーザが持っていない情報・手法
- 「Information Architecture」は「目に見えない情報」と「目に見える情報」を繋げる
- お客様やユーザが漠然と持っていた情報を整理し可視化した情報
情報とは
(実習)点とは何でしょう?
- (Wikipedia点（てん）とは、空間における正確な位置を定義するために使われる概念である。一切の体積、面積、長さをもたない。数学では概して(特に位相幾何学)、どの空間形態も基本的要素
として点から成るとされる。点は幾何学、物理学、ベクトル・グラフィックスにおいて基本的用語として使われる。 - 点はどこにありますか? 触ることができますか?
- 無定義術語について「ヒルベルトは，幾何学では点や直線はどんなものであるかは問題でなく，これらに対する“結ぶ”“交わる”などの操作に関する命題間の論理的依存関係だけが問題であるという見解に到達した。このようなわけで，ヒルベルトにあっては，点や直線は定義の与えられない無定義術語となり，それらは公理系の相互的関連によって初めて意味をもつものとなった。したがって，公理も自明の真理としての意味はなく，単に理論展開のための仮定にすぎなくなった。」
(実習)情報とは何でしょう?
- 情報はどこにありますか? 触ることができますか?
- Wikipedia
- あるものごとの内容や事情についての知らせのこと
- 文字・数字などの記号やシンボルの媒体によって伝達され、受け手において、状況に対する知識をもたらしたり、適切な判断を助けたりするもののこと
- 生体が働くために用いられている指令や信号のこと
- （情報科学での用法）価値判断を除いて、量的な存在としてとらえたそれ
- 情報アーキテクチャにおける「情報」の考え方
- データに「価値」を与えたものを「情報」という
- (例1)
- データ: 温度センサーで集めた1年分の温度
- 情報: 1年分の温度をグラフにし、暑い時期や寒い時期を見えるようにしたもの
- (例2)
- データ: 学生名簿一覧 (これそのものに価値があり、情報となることもある)
- 情報: 成績順にソートされた学生名簿一覧
(補足) 「暗黙知」と「形式知」と情報
- 「それが情報である」と「定義」すれば全て「情報」になりうる
- つまり、情報とはどう定義するかで具体的なものになる
- SECIモデル
- 「暗黙知」として存在していたものに名前を付けたりカテゴリ分けをすると「情報」になる
- 以下は「お姉さん」でもあるし「お婆さん」でもある。そして、お姉さんとお婆さんに見えるトリックアートでもある。(Wikipedia - 妻と義母)
- 「情報は定義するもの?」
まとめ
- 「情報」そのものは抽象的な言葉で実態が無い
- 実態が無いということは、全てに当てはまる
- 「それが情報である」と「定義」すれば全て「情報」になりうる
- つまり、情報とはどう定義するかで具体的なものになる
- 本講義では「誰に価値を提供する情報なのか」を最重要視して考える
- なぜなら、工学的な視点では「価値が認められる情報」に意味があるため
- お客様は誰なのか?
- その情報に価値を見出す人は誰なのか?
(演習)
- 開発テーマで登場する情報を全て洗い出して列挙する
- ブレインストーミング
- 清書
- (成果物)
- 「情報定義書」
アーキテクチャとは
- 訳:建設、建物
- ソフトウエアアーキテクチャ
- ソフトウエアの構造や設計を指す
- ソフトウエア設計思想
情報アーキテクチャとは
本講義での定義
- 情報
- 本講義では「誰に価値を提供する情報なのか」を最重要視して考える
- アーキテクチャ
- ソフトウエアの構造や設計
- 情報アーキテクチャ
- 誰に価値を提供するのかを決定し、それをソフトウエアの構造や設計として落とし込む手法
一般的定義
- Webサイト全体の設計という意味合いが強い
- IAという言葉はWebデザインの世界から出てきた
- Information Architecture
- 情報の整理の仕方のこと
- Information Architect
- 情報の整理をする役割(職種)のこと
- なぜ情報アーキテクチャや Information Architect が必要なのか?
- 新しい概念や役割ではない
- これまでもあったが、重要度が増したために名前が付けられた
- 名前が付けられたことにより認識されやすく、価値を見出せるようになった
情報アーキテクチャ活用の具体例
- Microsoft - 情報アーキテクチャ モデルと例
- 「ナビゲーション設計」に情報アーキテクチャを適用している
Information Architect
- リチャード・ソウル・ワーマン著「Information Architects」
- データの持っているパターンを整理し、複雑なものを明快にする人
- 人が知識への経路を見つけるための情報の構造や経路をつくる人
- 時代の要請により21世紀に新しく生まれつつある、明快さ、理解、情報の組織化を専門とした職業
情報が持つ特性
情報の「価値」
- 誰の価値?
- 誰に対しての価値なのかが決まらなければ、情報の価値を定義することができない
- 例) テニスに関する情報は、テニス好きには価値があるが、テニス嫌いには価値がない
- 誰に対して価値を提供するのかを想定し、描き出した象徴的な人物像のことを「ペルソナ」という
- 誰に対しての価値なのかが決まらなければ、情報の価値を定義することができない
- 何を提供する価値?
- モノ
- 便宜
- 安全
- 時間
- 体験
情報の可視性
- 見える情報
- 例) 綺麗な包装
- 例) Visual Design
- 見えない情報
- 例) 良い音
- 例) User Needs
情報の「可視化」
- SECIモデル
- 暗黙知と形式知
- 「知識とは暗黙知と形式知を絶え間なく変換・移転することである」野中郁次郎教授「SECIモデル」
情報の「多義性」
- 情報の多義性
- 情報は定義する人、定義する方向、定義する局面などにより定義が異なる
- どの定義が真に正しいということは言えず、情報は多義性を持つということ
- ペルソナを定義すれば「そのペルソナにとっての情報」を定義することができる
- こうもり問題
- こうもりは獣なのか鳥なのか
(演習1)
(演習2)
- ペルソナを定義する
- 開発が終わってリリースした際、どんな人がそれを利用するのか定義する。
- (誰に対して価値を提供するのかを想定し、描き出した象徴的な人物像のことを「ペルソナ」という)
- (サンプル)
- 「ペルソナのプロフィール」
整理と分類の違い
- 整理
- 必要な情報を残し、不要な情報を捨てる
- 分類
- 情報をカテゴリ分けする
(演習)
- 高度に文明が発達した地球外生命体が地球にやってきて、地球人の話を聞いているうちに、またたくまに地球の言葉が話せるようになった。地球外生命体がどのように地球の言葉を理解したか推測せよ。
事例から見る情報アーキテクチャの有効性・可能性
- 甲骨文字における「情報の整理と分類」
- 甲骨に描かれている文字を整理し分類することで、性質が見えてきた
- 性質が見えたことで、描かれていたそれぞれの文字の意味が分かった
- 整理・分類することで、それそのものの意味が分かった
- これはSECIモデルの「暗黙知と形式知の反復」により知識が定義できたということ
- まとめ
- 「価値ある情報の定義」を1回の作業で完遂することは非常に難しい
- 「情報の定義」→「情報の価値の確認」→「情報の再定義」→「情報の価値の確認」これを繰り返すことで、「価値ある情報の定義」を完遂することができる
- また、上記のサイクルを繰り返すことにより「価値ある情報を定義するスキル」は養成される
情報分類の手法
- LATCH法
- リチャード・ソール・ワーマンにより考案された情報整理の手法。情報を分類(構造化)する際の視点は以下の5つしかないとしている。
- 分類の視点
- Location:位置による分類
- Alphabet:アルファベットによる分類
- Time:時間による分類
- Category:分野による分類
- Hierarchy:重要度・序列による分類
- LATCHの例
- Webサイト
- サイトマップ(Location)
- 製品一覧(Alphabet)
- アーカイブ(Time)
- タイムライン(Time)
- メニュー(Category)
- 製品一覧(Category)
- ランキング(Hierarchy)
- タグクラウド(Hierarchy)
- テレビ番組
- 新聞のテレビ番組欄(Time)
- テレビ番組紹介(Category)
- 観光
- 地図(Location)
- 名所(Location)
- 宿一覧(Alphabet)
- イベント(Time)
- 観光目的(Category)
- Webサイト
- 上記の分類の視点が「見出し」になる
- 「見出し」とは?
- 意味
- 項目
- Headline
- 要約(要となる約束)
- 要 : 最も大切な部分、必要、まとめ
- 約 : ひもで結ぶ、共通のもの、かいつまむ、あらまし
- 要点(要となるポイント)
- 本質的意味
- 情報を抽象的に捉えた際の情報
- 例
- 情報「獣」と情報「鳥」を抽象的に捉えると情報「動物」が定義できる
- 例
- 情報を抽象的に捉えた際の情報
- 意味
- (チャレンジング演習)
- まったく新しい「見出し」を1つ考案する(開発テーマ以外でも良い)
情報分類の手法(見出しを定義する)
- カードソーティング
- カードに情報を記述し、分類する方法
- 実際にその情報を扱う人(お客様など)に分類してもらうことで価値ある分類になる
- 2つの手法
- オープン・カードソーティング
- 見出しを決めず、カード(情報)をグルーピングする
- グルーピングに名前を付けることで「見出し」を決める
- 「見出しを定義する」(見える情報から見えない情報を導き出す)
- クローズド・カードソーティング
- あらかじめ見出しを決めて、カード(情報)がどの見出しに属するかを決める
- 「情報が所属する見出しを決定する」
- オープン・カードソーティング
- データマイニング
- アクセスログなどの情報が得られる場合、コンピュータの計算力を利用し、情報からパターンや傾向を抽出する。
- 扱う情報によりテキストマイニングやウェブマイニングとも呼ばれる。
- QC7つ道具・新QC7つ道具
- 日本の製造業で品質管理に利用された手法
- グラフや散布図を利用しデータを分析する
情報整理と情報分類の課題
- 課題
- 情報の重要度(重み付け)
- こうもり問題
- 課題に対する解決方法
- 情報の重要度(重み付け) -> 的確なペルソナを定義する
- こうもり問題 -> 要件を定義する
情報整理と情報分類に必要な知識
- ドメイン(業務)知識
- 情報を適切に整理・分類するため、開発テーマに関する知識が必要
- 例1) 家計簿システムの開発であれば「購買行動」や「帳簿」に関する知識
- 例2) レシピを類推するシステムの開発であれば「類推アルゴリズム」や「料理」に関する知識
- 例3) 地図システムの開発であれば「地図」や「GPS」に関する知識
- 専門家へのヒアリング、市場調査、書籍を通して知識の習得を行う
- これらの知識は「業務知識」と呼ばれ、一般的に習得に10年はかかると言われている
- 情報を適切に整理・分類するため、開発テーマに関する知識が必要
関係する分野
関係する分野(各分野のノウハウや方法論を活用することでよりよい情報処理システムが構築できるかもしれない)
(演習)
- 「情報定義書」について、
- ペルソナを定義する
- 開発テーマに関する市場調査を行う
- googleやwikipediaを活用する
- 「情報定義書」を整理し分類する
- 情報整理の実施
- 情報分類の実施
- (注意点)
- 「情報」を整理し分類すること
- 「機能」ではないことに注意
- PDCAの手順を踏むこと
- 「情報」を整理し分類すること
- (成果物)
- 「ペルソナのプロフィール」
- 「整理分類済み情報定義書」
モデルとは
- 訳:模型,作る,形に表わす,模範,モデル,型
- モデリング
- 分類
- 名前付け
- パターン
- 単純化
- 何かしらの対象物を見本（モデル）に、そのものの動作や行動を見て、同じような動作や行動をする
- なぜモデリングするのか?
- 情報を普遍的(共通的)に利用可能にするため
- コンピュータシステム上で扱えるようにするため
情報モデルとは
- ペルソナが価値を見出す情報を、コンピュータシステムで処理可能な形に構造化したもの
- 情報の属性（データ項目）、情報間の関係、情報の制約条件を定義したもの
- 要件（ペルソナの視点）と実装（システムの視点）を繋ぐ橋渡し役
情報モデルの定義に必要なスキル
- オブジェクト指向分析設計
- 情報モデルをソフトウェアとして実装する際の適切な粒度を見極める必要がある
- (参考)
- データベース設計
- 情報モデルを永続化（データの保存）する際の適切な粒度を見極める必要がある
- (参考)
情報モデルの状態遷移
情報モデルの状態遷移を定義すると、情報処理システムが持つべき機能とプレゼンテーションが抽出できる
- 情報処理システム上で情報モデルがどのような状態遷移をするのかを定義する
- 状態遷移を定義することで、必要な情報処理(機能)と情報表現(プレゼンテーション)が抽出できる
- 情報モデルの状態遷移(CRUD: Create Read Update Delete)
- 情報モデルの状態遷移(具体例)
- 上記の情報モデルの状態遷移により、以下の情報処理(機能)と情報表現(プレゼンテーション)が抽出される
- 情報処理(機能)
- 新規入力
- 1件表示
- 一覧表示
- 更新
- 削除
- 情報表現(プレゼンテーション)
- 新規入力のプレゼンテーション
- 1件表示のプレゼンテーション
- 一覧表示のプレゼンテーション
- 更新のプレゼンテーション
- 削除のプレゼンテーション
- 情報処理(機能)
情報モデルと情報モデルの状態遷移の役割
- 機能とプレゼンテーションを抽出する
- 要件(ペルソナ・ユーザ・お客様が理解できる)と実装(ペルソナ・ユーザ・お客様が理解できない)を繋ぐ
- 要件と実装の連動
- 要件が変わった
- 情報モデルを変更
- 情報モデルの実装を変更
- 実装と要件の連動
- 実装が変わった
- 情報モデルを変更
- 情報モデルの要件を変更
- 要件と実装の連動
(演習)
- 「整理済み情報定義書」について以下の作業を行う
- 情報モデルを抽出する
- 情報モデルの状態遷移を定義する
- お客様視点のレビューを実施し「情報モデル」と「情報モデルの状態遷移」の確からしさを確認する
- レビュー結果を受けて、情報モデルを再抽出する
- レビュー結果を受けて、情報モデルの状態遷移を再定義する
- 情報モデルの状態遷移から機能を抽出する
- 情報モデルの状態遷移からプレゼンテーションを抽出する
- (推奨ツール)
- draw.io
- draw.io is free online diagram software for making flowcharts, process diagrams, org charts, UML, ER and network diagrams.
- draw.io
- (古い推奨ツール)
- astah
- UML 2.xに準拠した無償のUMLモデリングツール
- astah
- (成果物)
- 「情報モデル一覧」
- 「情報モデルの状態遷移図」
- 「機能一覧」
- 「プレゼンテーション一覧」
開発とは
- 有用なものを生み出すこと
- システム化すること
開発モデルとは
- 開発を普遍的(共通的)に実施可能にするための手法をまとめたもの
- 開発モデルの例
- ウォーターフォール開発モデル
- V字開発モデル
- アジャイルモデル
- スパイラル開発モデル
- ラピッドアプリケーション開発(RAD)モデル
- インクリメンタルモデル
- プロトタイピングモデル
開発の工程
要件とは
- 要件とは要望・要求に対し実現性を加味し開発を実施すると合意したもの
- 要件の種類
- 機能要件
- 情報処理システムが持つ機能の要件
- 非機能要件
- 情報処理システムが持つ機能以外の要件
- パフォーマンス
- 保守性、運用性など
- (参考)エンタプライズ系事業/非機能要求グレード
- 情報処理システムが持つ機能以外の要件
- 機能要件
仕様とは
- 仕様とは要件の詳細のこと
設計とは
- 設計とは仕様をどう実装するか定義すること
- 永続化とは
- データ構造とは
- 配列、連想配列
- 木
実装とは
- 実装とは設計した内容を実際に動作させること
- プログラミング言語
- 構文解析と構文木
- プログラミング言語の表現力
- 層
- プレゼンテーション層
- ロジック層
テストとは
- テストとは要件・仕様・設計通りに実装されているか確かめること
- 情報の対称性
(演習)
- これまでの成果物を元に、想定される「非機能要件」を定義する
- (成果物)
- 「非機能要件一覧書」
- ユーザ: 利用者
- インタフェース: コンピュータシステムの入出力仕様
- ユーザインタフェース: 利用者とコンピュータシステムの入出力仕様
(演習) 良いユーザインタフェース
- 良いユーザインタフェースとはどういうものか考察せよ。
ユーザインタフェースの種類
- CUI(Character User Interface)
- CLI(Command Line Interface)
- GUI(Graphical User Interface)
クライアントサーバ型
- クライアントサーバ型
Webブラウザ
- HTML5
- DOM(Document Object Model)
- HTMLドキュメントをオブジェクトとして扱い、JavaScript等から操作できる
- JavaScript
- JSON(JavaScript Object Notation)
- データ記述言語
- JavaScriptのオブジェクトなどのデータをテキストで記述できる
- JSON(JavaScript Object Notation)
- Adobe Flash
- Microsoft Silverlight
- Javaアプレット
- Ajax
スマートデバイス
- スマートフォン
- タブレット
ユーザインタフェースの設計
- マルチプラットフォーム
- Universal
- PC、スマートフォン、タブレット型端末などの複数のデバイスに対応する（マルチデバイス対応の）アプリケーションのこと
- Universalアプリケーションをサポートするツール
- PhoneGap
- Cordova
- Monaca
- UX
- ペルソナ(具体的なユーザー像)
- カスタマージャーニーマップ(顧客の行動分析)
- ワイヤーフレーム(Webサイトの設計図)
購買行動
(演習) 保守期間と情報処理システム
- 我々は様々なテクノロジ、デバイスが登場する時代の中にいる。
- この度、マルチデバイス対応の情報処理システムを開発することとなった。
- 1年間保守する情報処理システムはどうあるべきか考えよ
- 5年間保守する情報処理システムはどうあるべきか考えよ
- 10年以上保守する情報処理システムはどうあるべきか考えよ
UNIX
- 設計思想
- 業務プロセスに着目し設計を進める
- 業務固有の設計になりがちであり、他業務間で設計を共有し辛いことが多い
- また、データの一貫性(Consistency)の管理が疎かになりがちであった
- 業務データの構造や流れに着目し設計を進める
- データの一貫性(Consistency)を保ちやすい
- 実装に依存しない形でモデル設計(ドメインモデル設計)を行い、モデルから実装を生成・自動生成すソフトウエア設計思想る
- MDAの実装としてCASEツールやソフトウエア自動生成ツールが存在している
- システムを複数のサービスの集合として設計するソフトウエア設計思想
- サービス間はWebサービスなどの標準化された通信インタフェースで協調する
- リソースとは
- システム内で識別子を割り振ることが妥当な粒度の情報モデルのこと
- リソースはプレゼンテーションとは独立して設計するため、リソースはそのままでHTMLやCSVやXMLなど様々な表現を持ってもリソースは影響を受けない
- リソース指向アーキテクチャとは
- リソースを中心に設計をするソフトウエア設計思想
- オブジェクトとは
- データと手続きを抽象化したもの
- オブジェクトを用いてソフトウエアを分析し設計する思想
- UML
- デザインパターンとは
- カタログ化
- デザインパターンの例
- GoF
- ジェネレーションギャップパターン
- ジェネレーションギャップパターンとソフトウエア自動生成
3層アーキテクチャ
- データ層
- プレゼンテーション層
- ロジック層(ビジネスロジック層、ドメイン層とも言う)
- ModelとViewとControllerに分けて設計する手法
- Webアプリケーション界隈でMVCの利用が目立っているが、本来アプリケーション全般の設計に利用できるし、利用されてきた
- Model
- View
- Controller
- コラム
- AppleとNeXTSTEPとMVC
- ModelとViewとViewModelに分けて設計する手法
- アプリケーション全般の設計に利用できる
- Modelが持っている情報は何かしらの加工がされてViewで表示される。ViewModelがModelとViewの歪みを埋めるように設計する。
- Model
- View
- ViewModel
- コラム
- MicrosoftとMVVM
- ドメインとは
- ドメインとは業務や事業領域のことを指す
- ドメインは「ペルソナ(又はユーザ)が定義する情報」と考えることができる
- ドメイン駆動設計とは
- 多層アーキテクチャの設計をする際に「ペルソナが定義する情報」を「ドメイン層」に集約する
- ドメイン層に情報モデルと情報モデルの状態遷移を集約する
- 情報モデルや情報モデルの状態遷移を保持するための具体的な永続化の方法についてはドメイン層では扱わない
- ドメイン層にはペルソナ(又はユーザ)の関心事のみ記述する
- ドメイン駆動設計ではドメイン層をどのように設計すべきかの指針まで言及している
- ドメイン層に情報モデルと情報モデルの状態遷移を集約する
- 「ペルソナが定義する情報」の確からしさを確認しやすくするために「ユビキタス言語」を定義する
- 「ユビキタス言語」とはユーザや開発者が共通認識の元に利用する言葉
- 扱う情報モデルと情報モデルの状態遷移をユビキタス言語と合致するように命名・整理する
- 情報モデルと情報モデルの状態遷移をドメイン駆動設計では「ドメインモデル」と呼ぶ
- そうすることで、ペルソナと開発者側の情報定義を一致させる
- 情報定義が一致していれば価値の乖離がない
- 情報定義が一致していればコミュニケーションが取りやすい
- 多層アーキテクチャの設計をする際に「ペルソナが定義する情報」を「ドメイン層」に集約する
(演習)
- 「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」について情報アーキテクチャの手法(情報の整理と分類)を利用し、それぞれの違いについて考察せよ。
- Atomicity 原子性
- Consistency 一貫性
- Isolation 独立性
- Durability 永続性
情報と永続化
- 情報と永続化
永続化の方法
- ファイル
- データベース
- RDB
- 実装
- Oracle
- Microsoft SQL Server
- PostgreSQL
- MySQL
- 組み込み
- 正規化
- 正規化と情報アーキテクチャの違い
- 実装
- Key-Valueストア
- RDBはスケールアウトが難しいが、Key-Valueストアはスケールアウトがしやすい
- 実装
- Google BigTable
- Amazon DynamoDB
- Hadoop
- MongoDB
- RDB
- インピーダンス・ミスマッチ
- オブジェクト指向設計とRDB設計とのデータ構造の違いのことをインピーダンス・ミスマッチと言う
- O/Rマッピングという仕組みで違いを埋めるのが一般的
(演習)
- RDBの正規化と情報アーキテクチャの違いを考察する
- 開発手法とは
- コラム「開発手法」
- ウォーターフォール開発
- 反復型開発
- インクリメンタル開発
- イテレーション開発
- アジャイルソフトウェア開発
- XP
- Scrum
- バージョン管理システム
- WIP PR(Work In Progress Pull Request)
- Git-flow
- コラム「バージョン管理システム」
- (演習)
- なぜ開発手法が複数あるのか考察せよ。
実装の進め方
- 各単元の成果物をもとに実装を行う
実装例1
- apiaryでRESTfulAPIを作成し、JavaScriptからRESTfulAPIを呼び出す
- apiary にAPIのモックを作成する
- サンプルプログラムを参考に、apiaryのAPIモックにアクセスするように改修する
実装例3
- apiary にAPIのモックを作成する
- Anglar.jsやReact.jsやAuleria.jsなどをインストールし、apiaryのAPIモックにアクセスするプログラムを作成する
実装例4
- Monaca のサンプルプログラムを参考に、開発テーマに沿うよう改修を加える
- 発表に含めるもの
- チームの役割分担実績
- 開発したソフトウェアの構成
- 開発ツール
- フレームワーク
- 開発成果のデモ
- KPT(Keep Problem Try)
- その他、アピールポイントなど