読書録
- (*1) 情報処理学会 取扱い分野一覧より一部引用
- (*2) 要求工学、設計技法、アーキテクチャ、保守/進化、形式手法、開発管理、メトリクスと計測、検査/検証、品質/信頼性、開発環境、標準化、部品化/再利用、人的要因、ソフトウェア工学教育、ソフトウェアプロセス、ソフトウェア開発の知能化/自動化
- (*3) Rails 6対応版のPDF換算のページ数
- (*4) プログラミング言語の基本概念、設計原理、実装技術、・プログラミング方法論、プログラミング環境、・その他、プログラミングに関する面白い話題
- (*5) 組込みから高性能まで、幅広いコンピュータシステムのアーキテクチャを対象とし、以下の分野を含む。プロセッサ・メモリ・I/O・ネットワークのアーキテクチャ、並列分散システムのアーキテクチャ、コンピュータシステムの高性能化・省電力化・高信頼化、設計手法、コード最適化、新しいコンピュータシステム、コンピュータシステムの応用。
『Pythonによるプログラミング入門 東京大学教養学部テキスト: アルゴリズムと情報科学の基礎を学ぶ』学習メモ(2020年4月に書いていたもの)
構成
1.はじめに
2.まずは使ってみる
3.プログラムを作ろう
4.データ処理の基本:成績の集計
5.ライフゲーム
6.放物運動のシミュレーション
幕間 テストとデバッグの基本
7.p値の計算
8.大規模データの検索
9.データからの情報抽出:回帰分析
10.拡散のシミュレーション
11.高度な検索:ゲノムを解析する
12.データを分類する
1.はじめに
- 情報科学における基礎的な問題の軽減のため、プログラミングにあたっては以下のアプローチを取る必要がある。
- プログラムの正しさを確認する。不正確度を検証する。
- プログラムが現実的な時間で扱えるデータの規模を確認する。
2.まずは使ってみる
- プログラミングを始める
- Python開発環境の扱い方。
- 計算
- 整数と小数
- 誤差
- 指数表記(eを使った表記)
- 変数の導入、変数での表現
- プログラムの書き方
3.プログラムを作ろう
- プログラム作成にあたって
- 関数
- ライブラリ
- 組み込みライブラリ
- 値を返さない関数:結果がNoneとなる
4.データ処理の基本:成績の集計
- データ処理の基本・電子データでの表現について
- 配列
- len()
- 繰り返し
- range()
- 分岐
- プログラムの検証
- 正しさ
- テスト
- 可視化
- 時間
- 見積る
- 正しさ
- for文・繰り返しについて
- iteratorの仕組み
- オブジェクトについて
- 誤差
- 平均
- 分散
- 最大値
- 配列の任意の要素を初期値として比較を繰り返す
- 処理の分離・疎結合
- 配列の次元
- 文字列
- 型
練習問題でのポイント
- 多次元配列
range()の扱い
def ex4_8(l): if l[0] > l[1]: subMax = l[1] max = l[0] else: subMax = l[0] max = l[1] for i in range(2, len(l)): if max < l[i]: subMax = max max = l[i] elif subMax < l[i]: subMax = l[i] return subMax def ex4_9(scores): max = scores[0][0] for i in range(len(scores)): if max < scores[i][0]: max = scores[i][0] return max
文字列の配列も多次元配列として扱う
def ex4_10(strs, char): cnt = 0 for x in strs: for i in range(len(x)): if x[i] == char: cnt += 1 return cnt
5.ライフゲーム
- プログラミング(変数・関数・配列・for文・if文)の理解を深めるため、ライフゲームを例に見ていく
- モジュール化:シミュレーション処理の、部品への適切な分解。
- →拡張性・保守性
- 例:全体の表現 + 個別の処理 + シミュレーション(1ステップ(一まとまりの処理)の複数回実行)
- 可視化
- 配列の操作
スライス
> a = [8, 6, 2, 5, 4, 1] > a[0 : 4] [8, 6, 2, 5]
スライス@負数
- インデックスに負数を指定したとき、末尾の要素を-1とする相対インデックスとして解釈する
内包表記
> [i for i in range(0, 7) if i % 2 == 0] [0, 2, 4, 6]
append()
- 参照型
- 明示コピー
- ディープコピー、シャローコピー
練習問題でのポイント
座標
def ex5_5(img, y1, x1, y2, x2, color): # x1 < x2, y1 < y2を仮定 for y in range(y1, y2 + 1): for x in range(x1, x2 + 1): if (0 <= y < len(img) and 0 <= x < len(img[y])): img[y][x] = color
幾何の復習
def ex5_6(img, y1, x1, y2, x2, color): if x2 - x1 > y2 - y1: for x in range(x1, x2 + 1): y = round((y2 - y1) / (x2 - x1) * (x - x1) + y1) if (0 <= y < len(img) and 0 <= x < len(img[y])): img[y][x] = color else: for y in range(y1, y2 + 1): x = round((x2 - x1) / (y2 - y1) * (y - y1) + x1) if (0 <= y < len(img) and 0 <= x < len(img[y])): img[y][x] = color
同時変化:コピーが必要
def step(room): m = len(room) n = len(room[0]) nextRoom = ita.array.make2d(m, n) for k in range(2): for i in range(m): for j in range(n): if room[i][j] == 1 and not i == j == 0: if k == 0: if j != 0 and room[i][j - 1] == 0: nextRoom[i][j - 1] = 1 else: # 変わらないパターンを忘れない nextRoom[i][j] = 1 else: if i != 0 and room[i - 1][j] == 0: nextRoom[i - 1][j] = 1 else: nextRoom[i][j] = 1 room = nextRoom nextRoom = ita.array.make2d(m, n) return room def ex5_7(room, n): for i in range(n): room = step(room) return room
6.放物運動のシミュレーション
- 連立微分方程式で表現する現象のモデル化・シミュレーション
- 差分化:「微分している変数のごく小さな変化」で表現する(「微分している変数のごく小さな変化」に関する方程式で近似する)。
Δtによる近似で、x(t + Δt) = (x(t)の式)の形で表現する。
微分方程式をもとに、(t + Δt)とtについての漸化式を導出する。def population_step(x, a, b, stride): return a * x * stride - b * (x ** 2) * stride + x def ex6_4(init, a, b, stride, n): populationSteps = ita.array.make1d(n) population = init for i in range(0, n): population = population_step(population, a, b, stride) populationSteps[i] = population return populationSteps
定積分の差分化
- 関数のコードでの表現
while条件
def integral_step(g, f, stride): return g + f * stride def ex6_5(f, stride, a, b): x = a g = 0 integral = 0 while x < b - stride * 0.1: g = integral_step(g, f(x), stride) x += stride integral += g return g def square(x): # f引数とする関数 return x * x
シミュレーションのプログラム・モデル化に必要な処理・表現
- 可視化による正しさの検証
- モジュール化による柔軟なモデル
- OOD
- 繰り返しのbreak
練習問題でのポイント
配列操作
逆順イテレーション
def ex6_2(n, m): for i in reversed(range(1, min(n, m))): if n % i == 0 and m % i ==0: return i
計算量
def ex6_3(n): i = 0 while 2 ** i < n: i += 1 return i
微分方程式をもとに、(t + Δt)とtについての漸化式を導出→ex6_4()
- 定積分の差分化・while条件→ex6_5()
幕間 テストとデバッグの基本
- コーナーケース
- デバッグ手順
- バグ範囲を狭める
- 可読性
7.p値の計算
- p値:probability値
- p値の利用の制限・p値の不適切な利用
- p値を計算するプログラム
- 組み合わせの計算
- 漸化式と再帰関数
- 漸化式を解く
- 同じ形
- アルゴリズム:問題に対する解凍を正しく求める手順
- 問題の解法を、計算量で比較する
- 漸近計算量の算出
- O記法
- 漸近計算量の算出
- 再帰モデル
- 問題の解法を、計算量で比較する
- 乱数シミュレーション
- 乱数を処理する1ステップとステップを用いたシミュレートにより、p値の近似値を導出する
- モンテカルロ法→複雑な形状でも内外が分かれば面積を導出できる
- 疑似乱数の性質
- 疑似乱数プログラム(二項分布)の検証
- 実行速度と精度のトレードオフ
- 疑似乱数プログラム(二項分布)の検証
練習問題でのポイント
計算量
再帰関数は漸化式で計算量を表す。
def ex7_3(n): if n == 0: return 0 elif n > 0: return ex7_3(n - 1) + n
実行時間で検証する
import time t1 = time.time() ex7_3(1000) t2 = time.time() print((t2 - t1) * 1000) %%timeit ex7_3(1000)
-
def ex8_5(n): line = ita.array.make1d(3 ** n) cantor_main(line, 0, 3 ** n) return line def cantor_main(line, i, m): if m == 1: line[i] = 1 else: cantor_main(line, i, m // 3) cantor_main(line, i + m * 2 // 3, m // 3)
-
def ex8_6(n): image = ita.array.make2d(3 ** n, 3 ** n) vicsek_main(image, 0, 0, 3 ** n) return image def vicsek_main(image, x, y, size): if size == 1: image[x][y] = 1 else: m = size // 3 vicsek_main(image, x + m, y, m) vicsek_main(image, x, y + m, m) vicsek_main(image, x + m, y + m, m) vicsek_main(image, x + 2 * m, y + m, m) vicsek_main(image, x + m, y + 2 * m, m)
メモ化による計算量の削減
def ex8_7(n): nums = ita.array.make1d(n) nums[0] = 1 nums[1] = 1 for i in range(2, n): nums[i] = nums[i - 1] + nums[i - 2] return nums[n - 1]
-
randrange(1,7)で1から6を表す
import random def sumDicesNums(): sum = 0 for i in range(5): sum += random.randrange(1, 7) return sum def ex8_8(step): under20 = 0 for i in range(step): if sumDicesNums() <= 20: under20 += 1 return under20 / step
積分:y <= f(x)となった回数にxの範囲を掛けることで求められる
import random import math def ex8_9(step): cnt = 0 for i in range(step): x = random.random() * math.pi / 2 y = random.random() if y <= math.sin(x): cnt += 1 return cnt / step * math.pi / 2
random()で確率を表す
import random def isAWinMatch(): winA = 0 for i in range(7): if random.random() <= 0.55: winA += 1 return winA >= 4 def ex8_10(step): cnt = 0 for i in range(step): if isAWinMatch(): cnt += 1 return cnt / step
8.大規模データの検索
- 大規模データの検索・集約
- 線形探索
- 二分探索
- start,endを操作する
- 同じデータに何度も検索を行う場合や、既に整列済みのデータに対してのみ有効
- ヒストグラム(分類)の計算
- 併合整列法
- 分割統治法に基づく
- 分割統治法:大きなデータはとりあえず小さなデータに分けて処理をし、後でその結果を併合する
- 再帰における注意点
- 小さい入力の結果から大きい入力の結果が得られること
- 十分小さな入力の結果がわかっていること
- 計算量
- n = 2 ** kとなるk回の分割で終わるため、O(nlogn)
- 分割統治法に基づく
- 時間計算量と空間計算量(メモリ使用量)
- データ構造
- 集合(set)
- 1集合に重複要素不可
- 辞書(dict)
- 集合(set)
- 文章の分析の例
練習問題のポイント
二分探索は、不等号のときも限界値を探索できる ← start = endでwhileを抜ける
def searchStartIdx(data, a): start = 0 end = len(data) while start != end: center = (start + end) // 2 if data[center] < a: start = center + 1 else: end = center return start def searchLastIdx(data, b): start = 0 end = len(data) while start != end: center = (start + end) // 2 if data[center] > b: end = center else: start = center + 1 return end def ex9_2(data, a, b): return searchLastIdx(data, b) - searchStartIdx(data, a)
併合:インデックスを保持
併合整列・分割統治:未整列のデータの探索の繰り返しを、logn回に抑え込むdef mergeByK(data1, data2, k): mergedList = ita.array.make1d(min(k, len(data1) + len(data2))) idx1 = 0 idx2 = 0 for i in range(min(k, len(mergedList))): if (idx2 >= len(data2) or (idx1 < len(data1) and data1[idx1] <= data2[idx2])): mergedList[i] = data1[idx1] idx1 += 1 else: mergedList[i] = data2[idx2] idx2 += 1 return mergedList def ex9_5(data, k): n = len(data) if n <= 1: return data else: data1 = ex9_5(data[0 : n // 2], k) data2 = ex9_5(data[n // 2 : n], k) return mergeByK(data1, data2, k)
重複する要素を除いた併合
- 併合結果と同じ性質を併合元データは持つ
併合で重複を排除するインデックス操作をすることで、いずれの併合元内でもユニークな要素のみ持つ状態となる
def merge(data1, data2): mergedList = [] idx1 = 0 idx2 = 0 l1 = len(data1) l2 = len(data2) while idx1 < l1 or idx2 < l2: if (idx2 >= l2 or (idx1 < l1 and data1[idx1] < data2[idx2])): elem = data1[idx1] mergedList.append(elem) idx1 += 1 elif idx1 >= l1 or data1[idx1] > data2[idx2]: elem = data2[idx2] mergedList.append(elem) idx2 += 1 else: elem = data1[idx1] mergedList.append(elem) idx1 += 1 idx2 += 1 return mergedList def ex9_6(data): n = len(data) if n <= 1: return data else: data1 = ex9_6(data[0 : n // 2]) data2 = ex9_6(data[n // 2 : n]) return merge(data1, data2)
9.データからの情報抽出:回帰分析
- 巨大なデータの集約→要約が重要となっている。
- 回帰分析
- 最小2乗法
- 数値誤差が生じるパターン
- 浮動小数点数の計算
- ピボット選択で誤差を回避
- 誤差のない行とswap
練習問題のポイント
-
> 0.1 + 0.1 + 0.1 0.30000000000000004 > print(0.10000000000000001) 0.1 > a = 0.5 > b = -0.9999999 > c = 0.4999999 > b ** 2 0.9999998000000101 > - 4 * a * c -0.9999998 > b ** 2 - 4 * a * c 1.0103029524088925e-14 def average(scores): #scores中の成績の平均を求める return total(scores) / len(scores) def total(scores): #scores中の成績の総和を求める s = 0 for x in scores: s = s + x return s def variance2(scores): #scores中の成績の分散を求める s = 0 for i in range(0, len(scores)): s = s + scores[i] ** 2 return s / len(scores) - average(scores) ** 2 > x = 10 ** 5 > variance2([x + 0.1, x - 0.1, x + 0.1, x - 0.1]) 0.009998321533203125 > x = 10 ** 7 > variance2([x + 0.1, x - 0.1, x + 0.1, x - 0.1]) 0.0
10.拡散のシミュレーション
- 言葉の定義の確認
- 差分化 + 初期値 + 境界条件:シミュレーションの設定
- 1次元配列の可視化
- アニメーションのために、各時間ステップでの結果を格納した配列を作成
- 安定/不安定
- シミュレーションが安定するための条件
- k次式のテイラー展開による誤差の評価
- 前進差分→中心差分で誤差を小さくする
- 誤差のあるプログラム・処理のテスト
練習問題のポイント
差分化による微分の導出
差分化の式をそのまま返す
def ex11_1(func, dx, x): return (func(x + dx) - func(x)) / dx def square(x): return x * x > ex11_1(square, 0.001, 0) 0.001 > ex11_1(square, 0.001, 3) 6.000999999999479
前進差分誤差 ≒ 後退差分誤差
2階微分方程式のシミュレーション
import math def ex11_3(th, l, dt, step): g = 9.8 pastTh = th curTh = th thList = ita.array.make1d(step) for i in range(step): nextTh = 2 * curTh - pastTh - g / l * math.sin(curTh) * dt ** 2 pastTh = curTh curTh = nextTh thList[i] = curTh return thList
11.高度な検索:ゲノムを解析する
練習問題のポイント
2次元のDP
- 2変数漸化式は、2変数ともループが必要
配列生成時の初期値の設定
import ita def isSumM(isSumMList, curNum, i, m): if i == 0: if m == 0 or curNum == m: return True else: return False elif i < 0: return False else: if m >= curNum: return isSumMList[i - 1][m] or isSumMList[i - 1][m - curNum] else: return isSumMList[i - 1][m] def ex12_1(data): n = len(data) m = 100 isSumMList = ita.array.make2d(n, m, value = False) for i in range(n): for j in range(m): isSumMList[i][j] = isSumM(isSumMList, data[i], i, j) return isSumMList[n - 1][m - 1]
3項間漸化式
def ex12_2(points, days): n = min(len(points), days) pointsList = ita.array.make1d(n) pointsList[0] = points[0] pointsList[1] = max(pointsList[0], points[1]) for i in range(2, n): pointsList[i] = max(pointsList[i - 1], pointsList[i - 2] + points[i]) return pointsList[n - 1]
全ての項が関わる漸化式( C(i) = (0 <= j <= i - 1 について、(C(j) + cost(j, i)) の最小))
- 各項ごとに、対象の項まで繰り返す
最後の繰り返しの結果が答となる
def ex12_3(cost, n): costList = ita.array.make1d(n + 1) costList[0] = cost(0, n) for i in range(n + 1): minC = cost(0, i) for j in range(i): minC = min(minC, costList[j] + cost(j, i)) costList[i] = minC return costList[n]
確率漸化式でのDP
def ex12_4(p, q, t, a): probList = ita.array.make2d(t + 1, 11) probList[0][5] = 1 for i in range(1, t + 1): for j in range(11): if 0 <= j <= 1: probList[i][j] = q * probList[i - 1][j + 1] elif 2 <= j <= 8: probList[i][j] = p * probList[i - 1][j - 1] + q * probList[i - 1][j + 1] else: probList[i][j] = p * probList[i - 1][j - 1] return probList[t][a]
12.データを分類する
『退屈なことはPythonにやらせよう』学習メモ(前半のみ)
まえがき
- プログラミングは創造的な活動
- レゴブロック
- どんな外観の城を作りたいか基本構想を抱き、手持ちのブロックを確認する
- 作業
- 最後におめかしすることもある
- プログラミングがほかと異なるのは、必要な材料がすべてコンピュータの中にあること
Ch01 Python入門
- snake case
- input()
- print()
- len()
- str()
- int()
- float()
- 式は値と演算子で構成され、ひとつの値になるまで評価する。
- 式は評価してひとつの値となる。文は値にならない。
Ch02 フロー制御
- Boolean
- True, False
- 比較演算子
- ==, !=, <, >, <=, >=
- ブール演算子
- and, or, not
- フロー制御の構成要素
- 条件式
- コードのブロック
- プログラム実行
- フロー制御文
- すべてコロン(:)で終わり、次のブロックが続く
- ブロックが続かなければコロンはない
- if
- else
- elif
- while
- break
- Ctrl+Cで無限ループを抜ける
- True, Falseとみなされる値
- 0, 0.0, ''は条件式として用いるとFalseとみなされ、ほかの値ならTrueになる
- for, range()
- range(5)
- range(0, 10, 2)
- range(5, -1, -1)
- すべてコロン(:)で終わり、次のブロックが続く
- モジュールのインポート
- import random, sys, os, math
- from random import randint
- sys.exit()
Ch03 関数
- def hello():
- return value
- None
- Pythonはreturn文のない関数定義には末尾にreturn Noneを追加する
- NoneType
- print('Hello', end='')
- 文字列の末尾をendで指定
- print('cats', 'dogs', sep=',')
- global eggs
- グローバル変数を指定
- ローカル関数にローカル変数への代入分があれば、その変数はローカル変数として扱われる
- グローバル変数が同じ名前であったとしても、同じスコープで参照するよりあとにローカル変数を定義している場合は、エラーになる
- try:
- except ZeroDivisionError:
- 関数は、コードを論理的なグループに分割する基本的な手段
Ch04 リスト
- リスト
- list = [1,2,3,4]
- list[-1]は4
- list[0:3]は[1,2,3]
- len(list)は4
- [1,2,3]+['A','B','C']もできる
- ['X','Y']*2は['X','Y','X','Y']
- del list[2]
- list = で初期化して、list = list + [value]でリストに追加していける
- 2 in [1,2,3]
- 累積代入演算子
- bacon = ['A']
- bacon *= 3は['A','A','A']
- メソッド
- 字下げルールの例外
- リストの閉じ角括弧
- \
- リスト風のデータ型: 文字列とタプル
- リストはミュータブルだが文字列はイミュータブル
- 文字列の変更は、スライスと連結を使って元の文字列の一部から新しい文字列の生成が必要
- タプルもイミュータブル
- eggs = ('hello', 42, 0.5)
- 順序づけられた値の並びを変更不可にしたいとき
- コードが若干高速になる
- list(), tuple()
- リストはミュータブルだが文字列はイミュータブル
- 参照
- リスト、辞書型は参照をコピーする
- copy.copy()
- 異なるリストを作る
- cheese = list(spam)でも同じ
- copy.deepcopy()
- リストを含むリストをコピーする
- 問題
- int('3'*2)は33
- 要素1つのタプル: (42,)のようにカンマが必要
- 演習
- カンマ付け
- ', '.join(lst[:-1])
- 文字列でリストを結合できる
- ', '.join(lst[:-1])
- グリッド
- for y in range(len(grid[0]))
- カンマ付け
Ch05 辞書とデータ構造
- 辞書型
- my_cat = {'size': 'fat', 'color': 'gray', 'disposition', 'loud'}
- 順序が不定
- K-Vが同じなら別の順序で辞書を作っていても同じものになる
- keys()→dict_keys
- values()→dict_values
- items()→dict_items
- K-Vのタプルを返す
- for k, v in spam.items()
- get()
- キーと、キーがないときに使う値も引数に取る
- setdefault(key, defaultvalue)
- キーがないときだけ登録する
- キーが確実に存在するようにするための便利な方法
- count.setdefault(character, 0)
- count[character] = count[character] + 1
- 整形表示
- pprintモジュール
- pprint.pprint(list)
- リストや辞書が入れ子になっているときに特に便利
- print(pprint.pformat(list))も同じ
- データ構造で実世界の物体をモデル化する
- 代数的記法
- リストや辞書が有用
- 三目並べ
- 各マスにキーを振る
- データ構造を作り、それを解釈して表示するコードを書くことで、モデル化したプログラムを書くことができる
- 問題
Ch06 文字列操作
- 文字列の操作
- 便利な文字列メソッド
- upper(), lower(), isupper(), islower()
- 新しい文字列を返す
- isX
- isalpha(), isalnum(), isdecimal(), isspace()(スペース、タブ、改行のみ), istitle()(大文字から始まって残りすべて小文字の英単語のみ)
- validationに使える
- startswith(), endswith()
- join(), split()
- ', '..join(['a', 'b', 'c'])
- 'My name is Simon'.split(' ')
- デフォルトではスペースやタブ改行などの空白文字で分割
- 複数行の文字列の分割に使われる
- spam.split('\n')
- rjust(), ljust(), center()
- 'Hello'.rjust(10, '*')
- 10文字の中で'Hello'を右揃え
- 第2引数は埋める文字
- 表形式のデータを正しくスペースを空けて表示するときに特に便利
- 'Hello'.rjust(10, '*')
- strip(), rstrip(), lstrip()で空白文字を除去
- pyperclip moduleで文字列をコピペ
- コンピュータのクリップボードとテキストを授受
- upper(), lower(), isupper(), islower()
- プロジェクト: パスワードロッカー
- プログラムの設計とデータ構造
- 辞書でアカウント名とパスワードを関連付け
- コマンドライン引数を扱う
- sys.argv
- 正しいパスワードをコピーする
- プログラムの設計とデータ構造
- プロジェクト: Wikiで箇条書きのマークアップ
- クリップボードからコピー
- 行を分割して「*」を追加
- 変更した行を結合
Part 2 処理の自動化
Ch07 正規表現によるパターンマッチング
- 正規表現を用いないテキストパターン検索
- 正規表現を用いてテキストパターンを検索
- 正規表現によるパターンマッチの続き
- 丸括弧を使ったグルーピング
- group(1)など整数を渡すとマッチした文字列の異なる部分を取得できる
- 何も渡さないか0を渡せばマッチした文字列全体を返す
- groups()で、すべてのグループを一度に取得する(タプルを返す)
- group(1)など整数を渡すとマッチした文字列の異なる部分を取得できる
- 縦線を使って複数のグループとマッチ
- グループを分けることで部分的にORでマッチできるようになる
- 疑問符を用いた任意のマッチ
- 0回または1回
- アスタリスクを用いた0回以上のマッチ
- プラスを用いた1回以上のマッチ
- 波括弧を用いて繰り返し回数を指定
- (Ha){3,5}
- HaHaHa, HaHaHaHa, HaHaHaHaHa
- {3,}, {,5}もあり
- (Ha){3,5}
- 丸括弧を使ったグルーピング
- 貪欲マッチと非貪欲マッチ
- ?をつけないと最も長いもの(貪欲)、つけると最も短いもの(非貪欲)にマッチする
- findall()
- 見つかったすべての文字列を(グループに対応したタプルの)リストで返す
- 文字集合
- \d: 0~9の数字
- \w: 文字、数字、下線
- \s: スペース、タブ、改行
- それぞれ大文字はそれら以外を表す
- 独自に文字集合を定義
- キャレット(^)とドル記号
- 先頭、末尾にマッチ
- 全体の指定にも使える
- ワイルドカード文字
- ドット
- ドットとアスタリスクであらゆる文字列をマッチ
- 非貪欲なら/*?
- ドット文字を改行とマッチさせる
- re.DOTALLをre.compile()の第2引数として渡す
- 大文字・小文字を無視したマッチ
- re.IGNORECASE, re.Iを渡す
- sub()で文字列を置換
- 置き換える文字列と検索置換対象の文字列を渡す
- マッチ部分を使うときは\1, \2のようにグループの番号を使う
- ()を使うことで使いたい部分のグループを作る
- 複雑な正規表現の管理
- re.VERBOSEを渡すことで、正規表現中の空白やコメントを無視 → 複雑な表現にコメントをつけられる
- re.IGNORECASEとre.DOTALLとre.VERBOSEを組み合わせる
- |を使う
- プロジェクト
- 新しいプロジェクトに取り組むときは、まずは全体像から
- 入力、処理、出力
- テキスト検索でできること
- 電話番号、アドレス、URL、日付フォーマットの置換、センシティブ情報の削除、誤記の発見
- 新しいプロジェクトに取り組むときは、まずは全体像から
- 問題
- 3桁ごとにカンマがある数字にマッチ: ^\d{1,3}(,\d{3})*$など
- 任意の繰り返しはグループにしてアスタリスクをつければよい
- 大文字で始まり小文字が続く1単語、スペース、特定の文字列: [A-Z][a-z]*\sNakamoto
- 3桁ごとにカンマがある数字にマッチ: ^\d{1,3}(,\d{3})*$など
- 演習
Ch08 ファイルの読み書き
- ファイルとファイルパス
- os.path.join()で文字列をパスのフォーマットで結合する
- os.getcwd(), os.chdir()
- os.makedirs()
- os.pathモジュール
- ファイルの読み書きの方法
- open()でファイルを開く
- 読み込みモードで開く
- 'r'で明示
- Fileオブジェクトを返す
- 読み込みモードで開く
- ファイルの内容を読み込む
- read()
- readlines()
- 行ごとのリスト
- ファイルを書き込む
- 'w'
- 上書きして最初から書き直す
- 'a'
- 追記
- open()の第1引数に渡したファイルがなければ、新しい空のファイルを作る
- close()
- write()
- 改行も自分で追加する必要がある
- 'w'
- open()でファイルを開く
- shelveモジュールで変数を保存する
- シェルフの値を辞書のように変更できる
- open(), close()
- keys(), values()
- リスト風オブジェクトを返す
- リストが必要ならlist()に渡す必要
- pprint.pformat()を使って変数を保存する
- データ構造の文字列化
- 基本はshelveモジュールの方が便利
- .pyファイルに保存すれば、テキストエディタで読んだり修正できるというメリットはある
- プロジェクト: ランダムな問題集ファイルを作成
- プロジェクト: マルチクリップボード
『情報アーキテクチャ 第4版』学習メモ(作成中)
はじめに
- information_architecture: 情報の供給過剰によって,探しているものを見つけたり,見つけたとしてもその意味を理解するのが,非常に難しくなっている.この問題の軽減を手助けする実践分野
- 情報への双方向アクセスが重要になっている
- 意味構造を告げる設計原則が,Webを越えて幅広く適用できる
- デジタル製品とサービスに,場所や時間に関係なく,一貫性と統一性,そして分かりやすさをもたらすのに,どんな状況でも利用できるようにするための原則
Part 1 information_architecture入門
- ありとあらゆる場所に膨大な情報 → 見つけるためのノイズはねのけ難しい,見つけても理解が難しい
- information_architecture: 情報を見つけやすく,理解しやすくすることにフォーカスしたデザイン規律
- 2つの重要な視点
- 情報製品とサービスは,情報でできた場所として捉えられている
- 情報環境は見つけやすく,理解しやすいように組織化できる
Ch01 information_architectureが取り組む課題
- points
- 情報を入れものから自由にする方法
- 情報オーバーロードとコンテキスト拡散の課題
- これらの課題をinformation_architectureで解決するには
- 歴史の大部分でやり取りしてきた情報
- 入れものと1対1の関係
- 整理する正しい方法を決める必要
- → 非物質化
- Rip, Mix, Burn
- hello, iTunes
- information_architectureが取り組む課題
- 情報オーバーロード
- トフラー,情報生産の速度と変化の度合up
- → 情報のS/N(Signal/Noise)比が小さくなり対処が必要
- internet → 大量の情報が世界のだれとでも共有可能に
- internet,とくにwwwは概念化された双方向のinteractive media
- Webでの公開は速く,安く,効率的
- 情報技術の進歩 → 入手可能な情報量が増える → 過剰な情報が,情報を整理・発見・よりよく利用するための新たな技術を生んでいる
- → 初期のWebの成功がオンラインでの情報発見を支えるために創業された企業のものとなった
- トフラー,情報生産の速度と変化の度合up
- 情報にアクセスするより多くの方法
- 電子機器の小型化 + ワイヤレス通信
- → 情報をやり取りする方法を変える
- ユーザのアクセス方法の増加
- ユーザの利用に関する情報を収集して,このメタデータにもどついた追加機能を提供
- 情報の脱物質化の次の論理的ステップ
- 周囲へと浸透させ,世界との個人的なやり取りに絶えず存在する機能とすること
- モノのinternet
- 物質と情報のスペースをあいまいにする
- かつてないほど多くの情報処理必要+多様な物理的,心理的コンテキストのなかで情報処理を行っている
- ユーザにどのように情報にアクセスしてもらうかを考える必要
- ↑ 各コンテキストで期待するものが違う
- ユーザが情報にどこでどのようにアクセスするかにかかわらず,一貫した分かりやすい体験を求めている
- : 多様なコンテキストにおいて多岐にわたる複数のデバイスで,情報を見つける必要がある
- 製品やサービスをデザインした人々の助けが必要
- information_architecture入門
- 混乱の理由の1つ: applicationのほとんどが特定の問題を解決するためにデザインされているが,時が経つにつれ当初の問題解決の枠からはみ出し,より多くの機能を持つようになる傾向
- → 明確さと単純さが失われる
- ツールからエコシステムに代わる
- 必要なのは,情報が簡単に見つかる,分かりやすい構成を作るための,体系化された包括的で全体的なアプローチ
- ユーザが情報へのアクセスに用いるコンテキスト,チャンネル,メディアにとらわれないもの
- 製品開発の溝から抜け出し,広い視点からものごとを見て,情報をより簡単に見つけ,理解できるようにするには,すべてをどう結び付ければいいのか理解する必要
- information_architectureは,チームや個人がこの視点を得るためのレンズとして使える
- 情報で作られた場所
- 製品やサービスのやり取りに,言葉を利用していることを認識するのが大切
- ラベル,メニュー,説明,ビジュアル要素,コンテンツ,それぞれの相互関係が体験を差別化し,理解を促進する環境を作り出す
- 言葉の違いが,特定のタスクを満たすために訪れるべき場所の発見に役立つ
- 言葉は伝える情報の枠組みを作り,既知のコンセプトとのつながりを理解させてくれる
- 特定の言葉やイメージを選んで,その環境で何ができ何ができないかを判断する
- 製品やサービスのやり取りに,言葉を利用していることを認識するのが大切
- チャンネルを超えた首尾一貫性
- information_architectureは異なるチャンネルのニーズによっていくつもの方法で説明できる意味構造を定義するように求める
- 普及するinformation_architectureの重要な要素: 整合性
- 複数チャンネルとコンテキストにおいて,体験は一貫しているべき
- 各チャンネルの機能や制限は異なるが,各チャンネルで用いられる意味構造は,なじみのある首尾一貫したものであるべき
- 実際の実装から抽出
- system_thinking
- まとめ
- 情報は歴史的に非物質化される性質を持ち,入れものとの1対1の関係から,入れものから完全に切り離された状態になっている
- このことから,情報がかつてないほど豊富になり,その情報とやり取りする方法がかつてないほど多くなっている
- information_architectureは,情報を見つけやすく,分かりやすいものにすることに焦点を絞っている
- 製品とサービスは情報でできた場所として認識され,そのエコシステムとしての機能は,最大効果を得られるようデザインされる
- 抽象レベル+各レベルで定義
Ch02 information_architectureの定義
- 定義
- 定義
- 現れる言葉と実際の意味との関係には注意が必要
- 定義は不完全で制限されたもの
- 情報
- データや知識の管理とinformation_architectureとを区別するために,情報という用語を使う
- データ: 事実と数字が関わる
- 情報: ありとあらゆる形や大きさ
- データや知識の管理とinformation_architectureとを区別するために,情報という用語を使う
- 構造化,組織化,ラベリング
- 構造化: 製品やサービス内の情報「アトム(原子)」に対して適切な粒度レベルを決定し,それぞれをどのように関連付けるかを決定することが必要
- 組織化: これらの要素を意味があってほかと区別できるカテゴリーにグルーピングし,ユーザが現在いる環境とそこで見ているものを理解できる正しいコンテキストを創造すること
- ラベリング: そのカテゴリーおよびそのカテゴリーへのナビゲーション構造要素をなんと呼ぶかの答えを見出すこと
- 見つけることと管理すること
- findabilityは,ユーザビリティ全体の成功要因として欠かせない
- 閲覧,検索,質問を組み合わせてもユーザのほしいものを見つけられなければ,そのシステムは失敗
- ユーザ指向のデザインだけでは十分でない
- 情報を管理する組織と人も重要
- information_architectureはユーザのニーズとビジネス目標とのバランスを取る必要
- 効果的なcontents_management,明確なポリシーと手順が必須
- findabilityは,ユーザビリティ全体の成功要因として欠かせない
- アートとサイエンス
- 見えないからと言って存在しないわけではない
- チェスの情報構造について
- ものすごくいいinformation_architectureへの道
- 効果的なinformation_architectureの設計を実践するためのモデルの基盤
- ユーザ,コンテンツ,コンテキスト
- モデルの根底: 孤立してしまっては役に立つinformation_architectureを作り上げることはできないという認識
- 情報環境は,存在している情報システムやより広い環境の力により,動的で生体のような性質を持つ
- 情報の豊かな流れ,煩雑さ,間違い,試行錯誤,適者生存
- 情報エコロジーの概念: ユーザ,コンテンツ,コンテキストから成る
- 情報環境に存在する複雑な依存関係を扱うために使われる
- ベン図で3つの相互依存性を表す
- → プロジェクトの背後にあるビジネスゴール,そして設計と実装に有効な情報源の理解が必要
- 今日存在しているコンテンツの性質と量を認識し,この先1年でそれがどう変化するかも認識する必要
- 主な顧客のニーズと情報探索行動についても学ぶ必要
- 3つの分野すべてから情報を得て,3つの分野すべてを標的にする
- ユーザの考え方,デモグラフィック,心理,タスクと情報ニーズ,情報探索行動などには,かなりのばらつきがある
- コンテンツも,質,流通,権限,人気,戦略価値,コストなどによってさまざま
- 組織的コンテキストも,使命,ビジョン,目標,組織的政策,組織的文化,集中化や自主性の程度によって異なる
- 3つの円は難しい問題の解決にも役立つ
- problems
- 知っておくべき調査方法や評価方法とは何か
- information_architectureをデザインするチームに加えるべきなのはどのような人々か
- その分野と実践方法に遅れを取らないようにするには,どんな本やブログを読むべきか
- 新たな可能性を提案するinformation_architecture戦略を始めるべきなのは何か
- これらの問題への回答は,ユーザ,コンテンツ,コンテキストの3つのエリアとのバランスを取るところから始まる
- problems
- 情報エコロジーはすべて独特なもの
- 特定のプロジェクトにおいてそれに独自のニーズやチャンスが何かを学ぶ際には,このモデルが非常に役立つツールとなる
- 完全に独自性を持つ情報エコロジーを発生させる
- コンテキスト
- 理解と団結が重要
- コンテンツ
- 人々がシステム上で使用したり見つけたりするもの,技術用語でいう材料
- 所有権
- フォーマット
- 構造
- メタデータ
- ボリューム
- ダイナミズム
- ユーザ
- 何を求めているか
- 効果的なinformation_architectureの設計を実践するためのモデルの基盤
- まとめ
- information_architectureを定義する方法は1つ以上あっても問題ない
- information_architectureは簡単には説明できないもの
- かなり抽象的で,製品やサービスの表面化,意味構造の深い部分にあるが,それも問題ない
- 効果的なinformation_architecture設計を実践するためのモデルには,ユーザ,コンテキスト,コンテンツの3つがある
- 変化するもののミックスは,情報環境ごとに異なるだけでなく,同じ環境において時間とともに変化する
Ch03 見つけやすさのデザイン
- 内容
- 情報を探すためのさまざまなモデル
- 人々の情報探索行動
- こうした行動について学ぶ方法
- information_architectureは,人々がサイトを訪問したり,アプリを使用する理由から始まっている
- ニーズの違いが異なる情報探索行動へとつながる
- ユーザの優先度が高い行動がどれかを決める
- アーキテクチャ設計の上で,どこに努力とリソースを注ぎ込めばよいのか決定しやすくなる
- 「シンプル過ぎる」情報モデル
- ユーザ自身が何を求めているのか知っているときは〇
- それ以外では×
- 情報ニーズ
- ユーザが本来求めているのは,決断を下すための知識や手助けとなる考え
- 魚採りの比喩
- 既知情報探索
- 探求探索
- 全数探索
- 再探索
- 情報探索行動
- 情報ニーズと情報探索行動について学ぶ
- 検索アナリティクス
- 検索パフォーマンス,メタデータ,ナビゲーション,コンテンツでの問題を診断するうえで,自分のサイト上で最も一般的な検索クエリをレビューすること
- ユーザが何を求めているかが分かる
- contextual_inquiry
- 検索アナリティクスを補完
- ユーザが自然な状態で情報どのように相互作用するかを観察し,その文脈において,ユーザがなぜそのような行動をとっているかを質問できる
- 情報アーキテクトとしても目標: 最善を尽くしてユーザの主要情報ニーズと情報探索行動の典型を知ること
- ユーザがシステムに何を求めているかの理解が,どのアーキテクチャ要素を構築すべきかを決定,優先順位をつけるのに役立ち,ひいては作業を大幅に単純化する結果へとつながる
- 良質のユーザデータから,設計にしばしば影響を与える要素間のバランスを取るのにも役立つ
- 検索アナリティクス
- まとめ
- information_architectureは製品やサービスを利用するユーザと,利用する理由から始まる
- ユーザには情報ニーズがある
- ユーザが情報を求めるとき,何が起こるかというモデルがいくつかある
- シンプルすぎるモデルには問題がある
- ユーザに情報ニーズがあるとき,実際にはシンプルにことが運ばない
- 情報ニーズは魚釣りに似ている
- ユーザが自分で求めているものを明確に知っている場合もあるが,ほとんどの場合は流し網を使っている
- ユーザはさまざまな情報探索行動によって情報ニーズを満たす
- こうした行動を学ぶのにさまざまな調査方法がある
- information_architectureは製品やサービスを利用するユーザと,利用する理由から始まる
Ch04 理解のためのデザイン
- 内容
- ユーザは自分がいる場所とそこで何ができるかをどのように感じ取るのか
- 物理的な世界における場の創造と情報環境における場の創造
- 情報環境をより理解しやすくするための基本的な組織化原理
- 物事の理解: 何かほかのものとの関係性による
- information_architectureを設計するとき,「情報の受け取り方と理解の仕方を変える」という,新たなタイプの場の創造に取り組んでいる
- 建物の建築士と同じように,情報アーキテクトも人が理解でき,利用できる環境を創造し,その環境が時間の経過に伴って成長し,ユーザや組織のニーズに合致していくようにしたいと考える
- 情報を受け取る文脈を整え,構造によって原則が理解しやすくなる方法を見る
- 場所の感覚
- 場所の認識,プレイスメイキング衝動を,情報環境でも用いる
- 現実世界のアーキテクチャ
- 利用可能で,ほかのタイプの建物とは異なっているという共通点を持つ必要
- 情報から成り立つ場所
- UIの要素から,銀行のWebサイトと病院のWebサイトの違いが分かる
- 建築は社会的な機能を効率よく果たし,伝えるための物理的な環境を生み出すことを目的としている
- information_architectureもまた,情報環境において同じことを目的としている
- 現実の建築では物質の定義を行うのに対し,information_architectureではナビゲーションラベル,セクションの見出し,キーワードなどの語義を定義し,設計の指針,ゴール,ガイドラインなど,未来の場所の感覚を把握するためのものを定める
- 静謐な人里離れた場所なのか,それとも楽しい交流するためのスペースなのかなど
- 組織化の指針
- 情報環境は多種多様な方法で表現できる
- information_architectureが作り出す意味的構造は,ほかの設計分野の製品よりも抽象的
- architectureの異なるインスタンスに統一性を持たせるには,同じ言語を使用し,構成する言語要素間の特定の関係や秩序を作る
- 構造と秩序
- information_architectureの階層と要素の秩序は,完成したWebサイトに場所の意味と感覚を注入する
- 同じ業界のほかのサイトやサービスとの差別化となる重要な部分
- information_architectureの意味構造にも,サイト全体の中の個々の要素の相対的な重要性を示す階層がある
- 秩序が概念的な境界線を定義し,サイトの形式を認識するうえで大きな役割を果たす
- rhythm, pattern
- ユーザの情報の受け取り方が変わる
- information_architectureの階層と要素の秩序は,完成したWebサイトに場所の意味と感覚を注入する
- 類型学
- 建築における~~式
- どのような性質のビジネスがWebサイトを運営しているかのヒントになる
- ユーザが環境を理解し,ナビゲートしやすい
- 標準的な構造を持つことこそが,競合他社のWebサイトとの差別化を容易にする
- モジュール性と拡張性
- 基礎部分の情報構造は比較的同じ状態を維持する
- 時間変化の速度が異なる層で構成
- 意味構造は比較的安定
- information_architectureは比較的寿命の長い,意味構造の定義に主に焦点を当てている
- デジタル情報環境のダイナミズムを考えると,情報環境アーキテクチャの適応性と拡張性は,実際の建物の場合よりも重要
- 柔軟すぎてもあいまいさにつながり,communicationが不明確になりがち
- 柔軟ともろさの中間あたりが理想的
- 変化に対応しつつも,目的やアフォーダンス(身の回りに存在している意味ある情報)は明確にはっきりしているといえる
- 変化の速度が異なる部分を見つけ出し,それらを全体に関連付けながらここに切り離すのも,バランスを取るための1つの方法
- e.g. Google
- 地球上で一番幸せな場所
- ユーザ,組織,社会間でバランスが取れると,Webサイトから物理的な環境のthe wayfinding systemsにいたる,組織全体の製品とサービスに一貫性が生まれ,理解しやすくなる
- 入念に設計された組織化構造は,ユーザが新しい見慣れない環境を理解するのに役立つ
- 意味構造が場所そのもののコンテキストの設定だけでなく,ユーザにまで広げられるケース
- 買い手/売り手など
- information_architectureは各チャンネルの現在のユーザの特定の情報ニーズに応える必要
- チャンネル間の一貫性の上に来る
- まとめ
- 情報環境の構造はものをどのように見つけるかよりも大きな影響を与える.理解の仕方も変える
- 取引,学習,そしてほかの人々とつながるなど,さまざまな活動においてユーザは情報環境を場所として体験している
- 情報環境を設計する際,物理的な環境の設計から学べる
- 組織化原理の中には,物理的な環境から情報環境に取り入れられたものがある
- 構造と秩序,rhythm,類型学,モジュール性と拡張性など
- 情報環境を収める背景を理解することは,情報環境にある情報をどのように見つけるかに影響を与える
- その逆も然り
- 環境の組織化構造は,そこで何ができるかを人々に理解させるうえで重要な要因となる
- かつ,人々がその環境に加わった時に見つけたい,生み出したいと願う情報にも影響を与える
Part 2 information_architectureの基本原則
- information_architectureの構成要素を見る
- 組織化システム,ラベリングシステム,ナビゲーションシステム,検索システム
- 目に見えないシステムが情報環境の形成を背後で手助け
Ch05 information_architectureの解剖学
- 内容
- information_architectureの視覚化
- 抽象的な領域なので,実際に見るか経験しないと本当に理解はできない
- information_architectureの組織化
- 組織化システムは,サイトの情報をさまざまな方法で表示する
- ナビゲーションシステムは,メインのナビゲーションバーがある場合のドロップダウンメニューでそれぞれの組織へ進めるようにするなど,コンテンツ内をユーザが動き回れるようにする
- 検索システムは,ユーザがコンテンツを検索できるようにする
- ラベリングシステムは,カテゴリやオプション,リンクを,ユーザが理解できる言葉で(できれば)説明する
- トップダウン型information_architecture
- ボトムアップ型information_architecture
- 見えないinformation_architecture
- 検索システムを人間が背後で操作している
- information_architectureの構成要素
- 組織化システム
- いかに情報を分類するか
- ラベリングシステム
- いかに情報を表現するか
- ナビゲーションシステム
- いかにブラウズしたり情報間を移動したりするか
- 検索システム
- いかに情報を検索するか
- ラベリングシステムと組織化システムの区別は困難
- 以下は,もう1つの分類方法
- ブラウジングサポート手段
- あらかじめ決めた道筋をユーザに提供し,ユーザが情報環境をナビゲートする手助けをする
- 組織化システム
- 分類,階層
- general_navigation_system
- 第一次的ナビゲーションシステム
- ユーザが自分は情報環境内のどこにいるのか,どこへ行けるのかを理解するのに役立つ
- local_navigation_system
- 第一次的ナビゲーションシステム
- ユーザが自分は部分的情報環境内のどこにいるのか,どこへ行けるのかを理解するのに役立つ
- サイトマップ/目次
- 主要なコンテンツの領域と,サイト内に存在するサブサイトへのリンクと全体像の要約
- たいていアウトラインの形をとる
- インデックス
- 環境のコンテンツへのリンクをアルファベット順に一覧にしたもの
- ガイド
- 専門的に補う
- ウォークスルーとウィザード
- 段階を追ってユーザを導く,補足的なナビゲーションシステム
- コンテキスト的ナビゲーションシステム
- 一貫してコンテンツに関連したリンクを示す
- テキスト内に埋め込まれていることが多い
- 一般的には,情報環境内の非常に専門的なコンテンツへとつながっている
- 検索サポート手段
- ユーザ定義クエリを入力できるようにし,そのクエリにマッチする結果をカスタマイズしたものを自動的にユーザに提示する
- 動的に自動化
- search_interface
- query_language
- query_builder
- search_algorithm
- search_zone
- search_result
- コンテンツとタスク
- 目に見えない要素
- ほかの要素にフィードしていることが多い
- 検索クエリを強化するために使われるシソーラス
- 制限語彙
- 特定の範囲を指す優先用語をあらかじめ決めたもの
- 変形用語を含む
- search_algorithm
- 関連性によってランク付け
- 一番のおすすめ(Best bets)
- 検索クエリと手作業で組み合わされた,おすすめの検索結果
- ほかの要素にフィードしていることが多い
- 組織化システム
- まとめ
Ch06 組織化システム
- 内容
- 情報の組織化を難しくしている,主観性や政治およびそのほかの理由について
- 厳密であいまいな組織化スキーム
- 階層,hypertext,relational_database構造
- タグ付けとソーシャル分類
- 情報の組織化
- ものごとを理解する基礎である,分類システムが表れる
- 理解を助け,説明および管理をしやすくする
- 分類システムは,社会的,政治的な考え方や目的を反映している
- どのように情報を組織化し,ラベル付け,関連付けるかによって,人々がどう受け取るかが変わる
- 情報アーキテクトは,人々が求めている正しい答えを提供し,その答えを分かりやすくするために,情報を組織化する
- カジュアルブラウジングや直接検索の手段の提供も必要
- ユーザが理解しやすいように情報を組織化してラベリングする
- デジタルメディアによって,情報アーキテクトは非常に柔軟性の高い環境を組織化できるようになった
- 情報の組織化の課題
- 今や誰もがライブラリアンとなっている
- internetがユーザに情報発信の自由を提供
- コンテンツは指数関数的な勢いで成長し,コンテンツの組織構造の革新が必要となっている
- あいまいさ
- 不均一性
- 無関係なパーツまたは異なるパーツから構成されたオブジェクト,またはオブジェクトの集合を指す
- ありとあらゆる情報を広範かつ詳細にカタログ分類する必要
- コンテンツに単一の構造化された組織化システムを使用するのは困難
- 粒度や形式が異なるコンテンツは,それぞれ異なる方法で処理するべき
- 考え方の違い
- ラベリングシステムや組織化システムは作成者の考え方を大きく反映している
- 使いやすい組織化システムを設計するには,自分のメンタルモデルでコンテンツのラベリングや組織化をすべきではない
- さまざまなユーザ調査や分析手法を使い,現実を洞察する
- ユーザリサーチやユーザテストを通じて対象ユーザ層を理解しようと努め,ナビゲーションの通り道を複数用意することにより,先行きの見通しの重要性を認識できるようになる
- 社内の政治的関係
- 避けられないが制御は必要
- 今や誰もがライブラリアンとなっている
- 情報環境の組織化
- 組織化システムは,組織体系と組織構造から構成
- 組織体系
- コンテンツ項目が共有する特性とこれらの項目の論理的なグループ化を定義する
- 組織構造
- コンテンツ項目とグループの関係を定義する
- 組織体系
- 組織化は,ナビゲーション,ラベル,インデクシングとも深くかかわっている
- 密接に関連しているが,組織化システムの設計を分離することは可能であり有用
- ↑ ナビゲーションやラベリングシステムの基礎として活用できる
- 情報の分類だけを目標にすれば,実装上の詳細を気にせずに(ナビゲーションユーザインタフェースの設計など)よりよい製品の設計ができる
- 組織化システムは,組織体系と組織構造から構成
- 情報の組織体系
- 正確(客観的)な組織体系
- 情報を細かく定義された排他的なセクションに分ける
- 既知項目探索
- 設計と保守が比較的簡単
- 使いやすくもある
- アルファベット順
- ほかの組織体系の傘の役割
- 時系列
- ほかの組織体系の補完も必要
- 地理的
- 場所が情報の重要な特性となるとき
- 天気やニュースなど
- あいまい(主観的)な組織体系
- 設計や保守が困難
- 使うのも難しい
- 実際にはこの種の組織体系の方が重要であり,便利なことが多い
- 自分が何を探しているのか,探している本人が分からないことが多いため
- 情報検索には反復が多く,対話式に行われることが多い
- 検索の最初に何を見るかによって,何を検索するのか,あるいは最終的に何を検出するのかが変わってくる
- 連合学習が情報検索プロセスに関わる
- 連想のネットワークに対して検索を繰り返しながら意味空間を形成
- 優れた設計のシステムでは,ユーザは検索の過程で学習する
- → 項目を知的効果のある方法で分類することで,偶然性による情報検索をサポート
- ユーザ以外の誰かの知的判断にもとづいて,項目のグループ化
- 関連する項目のグループ化は,連合学習のプロセスをサポートし,ユーザは新しい関連付けを行って,よりよい結果を得ることができる
- → 高い価値をユーザに提供
- 成功の鍵
- 体系の質
- 体系内の個別項目の配置
- → 厳密なユーザテストが必要
- 新規項目を分類したり,産業界の変化を反映して組織体系を変更したりする必要がある
- トピック組織体系
- 情報を主題やトピックごとに組織化
- 最も有効で,非常に厄介
- 文化的構造 → 時の経過によって変化する
- 範囲を幅広く定義することが重要
- ユーザがシステムの範囲内で見つけようと期待しているコンテンツの全体を設計する
- タスク
- プロセス,機能,またはタスクの集合でコンテンツとアプリケーションがまとめられる
- ユーザが実行しようとしている優先度の高いタスクが少数しかない場合には適している
- Webにおいては,顧客とのinteractionが中心であるWebサイトで最もよく見られる
- 顧客
- 製品やサービスのユーザ層が複数存在することがはっきりしている場合
- 各ユーザ層別にコンテンツをカスタマイズする必要がある場合に〇
- personalization関連のあらゆる期待や危険がもたらされる
- 求めているものとユーザの特性がマッチしない場合もある
- メタファー
- ユーザの理解を促す
- ユーザはコンテンツ処理と模索を直感的に理解できる
- メタファー駆動型の情報の組織体系をどう処理するか模索する過程で,Webサイトの設計,組織化,機能について斬新なアイデアが浮かぶことがある
- ユーザになじみのあるものである必要
- 重荷となったり制限となることもある
- 一貫性に合わないケース
- ハイブリッド
- ナビゲーションの表層において有用
- 多くのWebサイトは,メインページ上とグローバルナビゲーション内でトピックとタスクをうまく組み合わせている
- ↑ 組織構造もユーザも,コンテンツの発見とキータスクの遂行が優先順位の1番上にあると認識しているという現実を反映
- 浅いハイブリッド型の組織体系は〇,深いのは×
- 深いハイブリッドを避けるために,複数の体系を1ページで提供するときは,各体系の整合性を維持するよう,設計者に呼びかける
- 同一ページ上でも体系ごとに提示されていれば,ユーザのメンタルモデルをサポートする機能を失わずに済む
- ナビゲーションの表層において有用
- 正確(客観的)な組織体系
- 組織構造
- 情報環境を設計するうえで非常に重要な役割
- 情報構造は,ユーザがナビゲーションするための主な方法を定義する
- 以下の3つの方を総合的に使用するのが〇
- 階層型: トップダウン型のアプローチ
- 優れた設計の階層構造は,多くの場合,優れたinformation_architectureの基礎となっている
- 階層構造は後半に用いられるので,ユーザは階層的な組織化モデルを使用しているWebサイトを容易にかつ瞬時に理解できる
- → 情報環境の構造を感覚的に理解し,構造内の現在位置の認識ができる
- → ユーザが使いやすいコンテキストを提供できる
- information_architectureの出発点として非常に適している
- トップダウン型のアプローチを利用することで,詳細なコンテンツのインベントリ化プロセス(データの一覧化を行うこと)を回避でき,即座に情報環境の全体を把握できる
- 主なコンテンツエリアを識別子,そのコンテンツへのアクセスを提供する組織体系を検討できる
- 階層の設計
- Webの階層を設計するときのいくつかの基本ルール
- 階層カテゴリは相互排他的にする
- とらわれすぎる必要はない
- 1つの組織体系では,排他性と包含性のバランスをとるようにする @あいまいな情報の組織体系のみ
- あいまいな項目は複数のカテゴリに含める
- クロスリストされている項目が多すぎると,階層そのものの価値が失われる
- 階層の幅と深さのバランス
- 幅: 階層の各レベルのオプション数
- 深さ: 階層内のレベル数
- 広さについて考えるとき,人が目でざっと見られる能力と認識の限度にも配慮する
- おすすめ
- 過剰なオプションはユーザを圧倒してしまう危険性があると認識する
- ページレベルで情報をグループ分けし,構造化する
- ページ内でアイテムをグループ分け
- ユーザテストを実施して設計を厳密に調査する
- 広さと幅の中庸が〇
- 深さについては,2か3レベル以上クリックが必要だと,ユーザは諦めて去ってしまう可能性がある
- 今後拡張が予想される新しい情報環境では,「狭く深く」ではなく,「広く浅く」を考慮すべき
- コンテンツの追加に大幅な再構築は不要
- 項目の追加はメインページに対して行うよりも,2番目のレベルの階層に対して行う方が若干容易
- メインページまたはスクリーンが,ユーザにとって最も明白で重要なナビゲーションインタフェースであり,システムにおいて何ができるかを理解する助けとなる
- メインページは最も目につくうえに重要 → 企業はメインページのグラフィックデザインとレイアウトに時間とコストを費やす傾向
- 階層カテゴリは相互排他的にする
- 組織体系を設計する際は,階層モデルの罠にはまらないことも大切
- 特定のコンテンツエリアでは,DBやハイパーテキストを使ったアプローチも可能
- 手始めとしては階層構造は適しているが,組織体系のほんの一部に過ぎない
- Webの階層を設計するときのいくつかの基本ルール
- データベース型モデル: ボトムアップアプローチ
- DB: 検索と情報収集の簡便化とスピードアップを目的としてアレンジしたデータの集合体
- メタデータが,information_architectureとDBスキーマとを結ぶ主要なキーとなる
- メタデータのエレメンツ間の関係は非常に複雑になる可能性がある
- 情報アーキテクトが理解しておくべきこと: メタデータや制限語彙,DB構造は,以下の事項を可能にするためにどう利用できるか
- 自動生成されるアルファベット順のインデックス
- 関連する「参照(see also)リンク」を動的に表現すること
- フィールド検索
- 検索結果の高度フィルタリングとソーティング
- 比較的均質なサブサイトに適用すると,特に効果的
- 製品カタログや社員住所録など
- ハイパーテキスト型
- 社会的分類
- 結合力のある組織化システムの作成
- 「データを情報へと変化させる第一歩は,その組織構造を調査すること」
- コンテンツのかたまりを小さな領域に集約すると,高度な機能を提供する組織化システムの可能性を追求できる
- 全体像を見落とさないようにすることも重要
- どの組織体系を適用するか検討する際,正確な情報の組織体系とあいまいな情報の組織体系の違いを考える
- できる限り両方の体系を利用する
- Web上で情報を組織化する難しさ
- 同じ情報にアクセスする方法を複数提供して対処する
- 大規模なシステムでは一般に複数の構造が必要
- いくつもの組織構造を組み合わせることで,結合力のある組織化システムが作成できる
- まとめ
- 世界をどう理解するのかは,世界をどう分類するかによって決まる
- 分類は簡単ではない.あいまい,不均一,考え方の相違,政治的な圧力などの問題に対処しなければならない
- 正確な組織体系またはあいまいな組織体系を使って組織化できる
- 正確な組織体系にはアルファベット順,時系列,地理的分類がある
- あいまいな組織体系にはトピック,タスク,顧客,メタファー,ハイブリッド型がある
- 組織体系の構造はまた,情報環境の設計においても重要な役割を果たす
- 社会的分類は,共有デジタル環境における情報の組織化のための重要なツールとして浮上してきた
Ch07 ラベリングシステム
- 内容
- ラベリングシステムとは何か,重要な理由
- よくあるラベルのタイプ
- ラベルを開発するためのガイドライン
- ラベリングシステムを作成するためのヒント
- ラベリング: 表現形態の1つ
- ラベルを使って情報環境内の情報のまとまりを表せる
- 情報をあれこれ目立つようにに表示する代わりにラベルを使えば,ユーザはすんなりと理解でき,何ができるかどうするか決められる
- ラベルの目的: 情報を効果的に伝えること
- → ページの物理的スペースもユーザの認識領域も無駄遣いすることなく,情報を伝える
- ラベルは,複数のシステムとコンテキストにまたがる組織とナビゲーションシステムを最も明確にユーザに示す方法
- なぜラベリングに注意を払う必要があるのか
- 多くの場合,情報環境は,システムの所有者と作者のメッセージをユーザにゆっくり翻訳して伝え,また元に戻す仲介メディア
- → メッセージがあいまいになるため,ラベルが必要
- 相手と直接向き合えないという欠点を最小限に抑えるために,ラベルを作る
- 新しい概念についてユーザに教えるのは,ラベルの役割
- うまくいったラベルは邪魔にならない(失敗したラベルは目立つ)
- 予測でき紛らわしくないラベルが〇
- ラベルのチェック
- 内容を描写していないうえにほかとの区別がつかないラベル
- 内容が不明,脈絡がない
- ラベルに専門用語が使われており,ユーザ中心のラベルになっていない
- ラベルのせいでお金が無駄になる
- ラベルのせいで悪印象を与えている
- 貧弱なラベルは×
- 内容を描写していないうえにほかとの区別がつかないラベル
- ラベルはほかの要素と同じくらい重要な要素
- 多くの場合,情報環境は,システムの所有者と作者のメッセージをユーザにゆっくり翻訳して伝え,また元に戻す仲介メディア
- さまざまなラベル
- テキストによるラベル
- コンテキストリンク,ヘッダ,ナビゲーションシステム選択,インデックス用語
- アイコンによるラベル
- コンテキストリンクとしてのラベル
- ドキュメントまたは情報チャンクの本文内にあるハイパーリンクテキストを説明しているラベル
- 周囲のテキストという説明的なコンテキスト内に生じる
- 作成が簡単で,Webの成功を促すエキサイティングな相互連結性の基礎
- 簡単に作成できるからこそ問題も起きる
- ハイパーテキストでのつながりは,個人的でそれぞれ異なる種類
- → コンテキストをうまく作り上げることで,ラベルの意味が周囲のテキストから引き出される
- ラベルの持つ多様性は,より多くのラベルの組み合わせやラベリングシステムからコンテキストを引き出し,ひいては意味を引き出している
- しかし,リンクラベルではシステム的な一貫性は期待できない
- コンテキストリンクを作成しラベリングする前に,「ユーザはどのような情報につながると予測しているだろうか」と問いかけることで,情報アーキテクトはコンテキストリンクラベルの具象性を確認できる
- ほとんどの場合,コンテキストリンクは情報アーキテクトの力が及ばないことも知る
- テキストによるラベル
- ヘッダとしてのラベル
- ヘッダ: それに続く情報チャンクを描写
- コンテンツ内の階層を築くために使われる
- サイトのサブサイトを決めたり,カテゴリとサブカテゴリとを区別する役目を持つ
- 親子関係や兄弟関係といったヘッダ間の階層関係は,視覚的要素の組み合わせを一貫して使うことで築ける
- 階層関係を目立たせることにあまり厳密にならないようにする
- 読まなくても視覚的に区別できればヘッダは不要
- ラベリングをプロセスに入れる際には一貫性の維持が特に重要
- ヘッダラベルははっきり目に見えていて,先へ進む順序を伝える必要がある
- → 番号を使うのが一般的
- 一貫性を持った行動としてラベルを述べる,つまり動詞を使用するという方法も先へ進む手順をまとめるときに役立つ
- ラベルは「どこから始まるか」「次はどこへ行くのか」「先へ進むときに各ステップでどんな行動を取ることになるのか」を伝える必要
- ヘッダラベルははっきり目に見えていて,先へ進む順序を伝える必要がある
- ヘッダラベルは階層的,順番的,または複合的かもしれないが,コンテキストリンクラベルよりもシステム的に設計されるべきもの
- ヘッダ: それに続く情報チャンクを描写
- ナビゲーションシステム中のラベル
- オプション数の少ないナビゲーションシステムラベルは,ほかのどのタイプのラベルよりも一貫して適用されることが要求される
- ナビゲーションシステムはサイトに繰り返し登場 → ナビゲーションラベリングの問題は拡大される
- ページ配置と見た目が一貫した場所で「合理的に」振る舞うために,ユーザはナビゲーションシステムに頼る
- ラベルは常に同じである必要
- ↑ 親近感を養うためには,ラベルを効果的に適用することが欠かせない → ページごとにラベルが違っては困る
- 色も配置も一貫していればさらに効果的
- 基準はないが,多くの場合ナビゲーションシステム用に共通する用語がある
- 各カテゴリに対して1つの用語を選択し,それを一貫して適用するのが〇
- メイン,メインページ,ホームのなかから1つ選ぶなど
- 各カテゴリに対して1つの用語を選択し,それを一貫して適用するのが〇
- インデックス用語としてのラベル
- キーワード,タグ,説明を含んだメタデータ,用語体系,制限語彙,シソーラスなどと呼ばれ,あらゆる形式のコンテンツを記述するために用いられるもの
- コンテンツの意味を描写することで,単にコンテンツの全テキストを検索するよりも精密な検索が可能になる
- 人がコンテンツの意味を確認して表現したもの → 単純に検索エンジンで全テキストからクエリと合うものを探すより,インデックス用語を検索した方が効果的
- ブラウジングも容易になる
- サイト本来の組織化システムの代替物となり,ユーザにとって非常に便利
- 組織化システムからもインデックス用語からもアクセスできる
- サイトインデックスやリストの形を取ったインデックス用語は,組織のサイロ間にある縦の境界線を横断する手段として有効
- インデックス用語がまったく見えない場合もある
- 各ページを目立たせようとするのはかなり困難な作業
- 制限語彙やシソーラスからインデックス用語を選んで利用するなど,よりシステム的なアプローチでラベリングする方が効果的
- → 目的: より詳細な範囲を一貫性のある予測可能な方法で記述すること
- アイコンラベリング
- アイコンはナビゲーションシステムのラベルとして使われることが最も多い
- 特にモバイルアプリのように,画面のスペースに制限がある場合など
- 問題: テキストラベルよりも言葉が限られている点
- → 小規模な組織のシステムラベルやナビゲーションシステムなど,オプションが少ない用途がほとんど
- 情報環境に優美さが生まれるので,システムのユーザビリティを阻害しないのなら,使わない手はない
- 繰り返し利用してもらえるなら,アイコンによる言語がユーザの心に確立される
- → アイコン言語は具体的かつ視覚的にも認識しやすい伝達システムとして非常に有効
- ユーザが繰り返し使ってくれる場合以外は,選択肢が限られたシステムにおいてのみアイコンラベルを使い,機能を説明する前に使用しないことが推奨
- アイコンはナビゲーションシステムのラベルとして使われることが最も多い
- ラベルの設計
- 効果的なラベルの設計はinformation_architecture最大の難関
- 言語自体があいまいなので,完璧なラベルという自身は持てない
- 類義語や同音異義語についても考えなければならないし,コンテキストが違えば用語の意味の理解にも影響する
- 多言語対応
- ラベリングは科学よりアート
- 一般的なガイドライン
- ユーザ,コンテンツ,コンテキストの変化のしやすさが,ラベルをあいまいな世界に導く
- 可能な限り視野は狭くする
- 全サイトをカバーしているグローバルナビゲーションシステム以外は,全システムのコンテンツを扱うラベルは使わないようにする
- 一貫性のあるラベルではなく,一貫性のあるラベリングシステムを発展させる
- 一貫性は予測可能であることを意味し,予測可能なシステムは覚えるのが容易 → 一貫性が重要
- 一貫性に影響を及ぼす問題
- スタイル
- 表示
- 構文法
- 粒度
- 総合性
- 顧客
- ラベリングシステムの情報源
- 新しいラベリングシステムの作成
- 最も重要な情報源: コンテンツ(と,その作者の可能性もあり)とシステムのユーザ
- コンテンツ分析
- 時間のかかるつらい作業
- 既に存在している「コンテンツの見本」に集中してスピードアップが必要
- コンテンツの見本: タイトル,要約,抄録
- 自動抽出ツールを使えば,作業の8割までは完了する
- 高額で学習コストもかかる
- コンテンツ著作者
- 著作者に提案を依頼する
- 再集計ではない
- ユーザの代表者とテーマ内容の専門家
- ライブラリアンと想定ユーザを決めて作業
- ユーザがシステムに何を求めているか
- まず少数のグループ化から初めて,それをもとにしてサイト全体のインデックスをサポートするラベル作りに発展させた例
- ライブラリアンと想定ユーザを決めて作業
- ユーザ(直接的)
- 入手しづらいが得られれば最も有用
- カードソート
- オープンカードソート
- 既存のコンテンツに対するラベルを被験者に与える
- 被験者はそれを群和気氏,独自のカテゴリとする
- クローズドカードソート
- 被験者に既存のカテゴリを与えて,そのカテゴリ内にコンテンツを並べ替えてもらう
- ナビゲーションのラベルなど,少数のラベルにより適している
- カードソートは非常に有益だが,被験者は実際の製品のコンテキストに即してラベルを提示しているわけではないことを認識必要
- オープンカードソート
- フリーリスティング
- カードソートよりさらに低コスト
- 1つの項目を選び,被験者にその項目を説明する言葉について意見を出し合ってもらう
- どんな人に何人に頼むのか,被験者について考える必要
- コンテンツのサブセットの選択
- 利用パターンと頻度を見る
- 個々のアイテムにどのようにラベルをつけるかの間を与えてくれると同時に,ユーザが用いる言語についても示してくれる
- ラベリングシステムを開発するうえで,どのような傾向,スタイルにすればよいかのヒントを与えてくれる
- ユーザ(間接的)
- 検索クエリやタグの分析
- → ユーザのニーズに関するデータという価値ある情報を生み出している
- 検索ログ分析
- 微調整
- まずリストをアルファベット順にソートする
- 重複を削除
- 用語の用法,句読点,大文字小文字の用法などの観点から,リストをチェックする
- 一貫性のなさを解決し,句読点やスタイルのルールを確立するよいタイミング
- どの用語をラベリングシステムに含めるのかは,システムがどれだけ幅広いのか,どれだけの規模かという状況のもとに決断する必要
- まずラベリングシステムに明らかなギャップがあるかどうか判断
- 最終的に要素として入れる必要のありそうなラベルが網羅されているか
- 将来サイトでカバーされると予想できるトピックについても考える
- 仮のラベルがラベリングシステムに及ぼす影響は驚くほど大きい
- サイト独自のコンテンツと特定のユーザのニーズを満たすには,ターゲットを絞り,範囲を限定し,手元にあるビジネス目標に狙いを定めたうえで,正しく定めた範囲内で包括的なものになるようにすべき
- バランスの問題
- 取り掛かろうとしているラベリングシステムは,その後すぐに調整と改善の必要性が生じる
- ラベルは,ユーザとコンテンツという,2つの絶え間なく変化し続ける対象の関係を描写しているため
- → ユーザテストを実施する容易を司,検索ログを定期的に分析し,必要に応じてラベリングシステムを調整するようにする
- 効果的なラベルの設計はinformation_architecture最大の難関
- まとめ
- 我々は常にラベリングしている
- ラベリングは,複数のシステムとコンテキストにまたがる組織のスキームを最も明確にユーザに示す方法
- システムのユーザと同じ言語を用いるラベルを設計しつつ,コンテンツを反映するようにしなければならない
- テキストラベルは仕事中に目にする最も一般的なラベルのタイプ
- コンテキストリンク,ヘッダ,ナビゲーションシステムオプション,インデックス用語がこれに含まれる
- アイコンラベルはそれほど一般的ではないが,スクリーン面積が小さい端末では広く採用されている.多くの情報環境において,こうした端末が重要になっている
- ラベルの設計は,information_architectureにおける最も難しい一面
- 既存の情報環境や検索ログ分析などさまざまな情報源があり,ラベリングを選択するうえで役立つ
Ch08 ナビゲーションシステム
- 内容
- コンテキストを提供し,より柔軟性を高めようとする場合は,お互いを補足し合うようなナビゲーションツールが必要になる
- 「構造化と組織化」は部屋を建築士,「ナビゲーション設計」はドアや窓を取り付けるようなもの
- 構造化,組織化,ブラウジング,検索システムのすべてが,効果的なナビゲーションに貢献している
- ナビゲーションの表層,つまりユーザが操作を行う部分が,非常に速く変化している
- さまざまな計上の端末の拡散により,設計者や開発者はバラバラ場スクリーンサイズや操作のメカニズムに対応するため,多様な戦略を考案せざるを得ない状況になっている
- 「レスポンシブWebデザイン」戦略はそれだけで大きなテーマなので扱っていない
- さまざまな計上の端末の拡散により,設計者や開発者はバラバラ場スクリーンサイズや操作のメカニズムに対応するため,多様な戦略を考案せざるを得ない状況になっている
- ナビゲーションシステムのタイプ
- ナビゲーションシステムはいくつかの基本的な要素,またはサブシステムで形成されている
- まずグローバルナビゲーションシステム,ローカルナビゲーションシステム,コンテキストナビゲーションシステムがあり,これらはサイトのページやアプリのスクリーン内に統合されている
- ユーザが「どこにいるのか」「どこへ行けるのか」を理解できるようにしている
- 図8-1: グローバル,ローカル,コンテキストの埋め込み型ナビゲーションシステムのレイアウト
- これだけでは不十分
- 図8-2: 補足型ナビゲーションシステム
- サイトマップ,インデックス,ガイド
- 同じ情報に対して異なるアクセス方法を提供する点で検索に似ている
- ナビゲーションシステムはいくつかの基本的な要素,またはサブシステムで形成されている
- あいまいな問題
- ナビゲーションシステムは,分野横断的なあいまいな領域に深く踏み込む
- エクスペリエンスデザインという傘の下に分類されるもの
- さまざまな分野が互いに協力するのが理想
- ナビゲーションシステムは,分野横断的なあいまいな領域に深く踏み込む
- ブラウザナビゲーション機能
- ナビゲーションシステムを設計する際は,システム環境について考慮が重要
- ナビゲーションはユーザがサイトとインタラクションするさいに重要
- 新しいナビゲーションスキームは検討要
- 場所を明確にする
- ここが何のサイトであり,何を見つけ,何ができるのかなど,コンテキストを明確にすることで,情報はより理解しやすくなる
- 言葉で存在位置を明確にし,サイトを見て回るはっきりした道筋を示すのは,ナビゲーションシステムが果たす大切な役割の1つ
- どのナビゲーションシステムでも,次にどこへ進むか決めるには現在地を知る必要がある
- 全体像から見た情報提供が特に重要
- 一見しただけでその内容を大まかに把握できるようなサイトを作るための,基本的な経験則
- 自分がどこのサイトまたはアプリにいるのか常に知らせる
- 組織名やロゴ,画像でのidentityをサイトの全ページに拡張すれば簡単に達成できる
- 自分がどこのサイトまたはアプリにいるのか常に知らせる
- 情報の階層構造を明確に,一貫性を持って示す,かつユーザの現在地を示す
- 組織体系のメンタルモデルを作りやすくなる
- ナビゲーションストレステスト
- 1.トップページを無視して直接サイトの中に進む
- 2.適当に入ったそれぞれのページに対して,自分がどこにいるか,サイトのほかの部分との関係を把握できるか,今いる主なセクションはどこか,親となるページはどこか
- 3.今いるページが次にどこへつながるのか予測できるか,リンクは何についてのリンクか十分に説明しているか,やりたいことがあるときに,似ているためにどれを選んでいいか分からないリンクがないか
- ここが何のサイトであり,何を見つけ,何ができるのかなど,コンテキストを明確にすることで,情報はより理解しやすくなる
- 柔軟性の向上
- ナビゲーションの観点では,階層化には制約がある
- → ハイパーテキスト機能はこの制約を取り除いた
- → 柔軟性という利点と混乱というリスクのバランスを取る
- 水平および垂直方向のナビゲーションサポートが必要
- サポートが多すぎると,階層構造が分かりにくくなってユーザを困らせる
- 階層構造を補強するのに十分なコンテキストと柔軟性を提供することが大切
- 埋め込み型ナビゲーションシステム
- 図8-1の3つの主要な埋め込みナビゲーションシステムの性質と,それらが一体になったときにコンテキストと柔軟性をどう提供できるかの理解が,成功するWebサイトの設計には欠かせない
- グローバルナビゲーションシステム
- サイトの全ページに表示される
- ユーザがサイト階層内のどこにいても,重要な領域や機能に直接アクセスできる
- 組織のロゴでホームページにリンク
- 検索機能へのリンク
- サイトの構造を強化し,コンテキスト的なヒントを提供することもある
- 絶えず発展している
- メガメニュー
- 従来のドロップダウンメニューの用に表示される,大きなメニュー画面
- ファットフッタ
- 要約されたサイトマップ
- サイトにおいて唯一の首尾一貫したナビゲーション要素であることが多いため,利便性という点で大きな影響力を持っている
- → ユーザ中心の設計となるよう,徹底して繰り返しテスト要
- ローカルナビゲーションシステム
- グローバルナビゲーションシステムが複数または1つのローカルナビゲーションシステムによって補足され,ユーザが現在いる領域を探索できるようにしている
- ローカルナビゲーションシステムとそこからアクセスできるコンテンツは大幅に異なることが多い → ローカルエリアはサブサイト(サイト内のサイト)と呼ばれる
- サブサイトが存在する理由
- 特定の領域のコンテンツと機能が,ユニークなナビゲーションを持つメリットがある場合
- 大規模な組織は分散化が進んでおり,コンテンツの領域が異なればその責任者のグループも異なるため,各グループが違ったやり方でナビゲーションを扱うことに決めている場合
- 単に設計チームが複数いて同じ方向性が選べなかっただけというのは望ましくないがよく見られるケース
- コンテキストナビゲーション
- グローバルナビゲーション,ローカルナビゲーションという構造化されたカテゴリが適さない関係のとき
- See alsoなど
- 関連学習をサポート
- 項目間に定めた関係を発掘することでユーザが学習していく
- ユーザと組織のためになる網の目のような組織を作れる
- アーキテクチャ側というよりも編集側のものと定義される
- このようなコンテキストリンクがコンテンツにとって非常に重要な場合は問題がある
- ユーザがページをすばやく読むため,隠れたリンクは見落とされたり無視される傾向にある
- → ページのどこか特定の位置にコンテキストナビゲーションリンクの欄を設けたり,見てわかるようにまとめられるシステムを設計する
- 適度な使用が〇
- 若干の柔軟性と補足的な役割を果たすようにする
- コンテキストリンクの性質と重要度により,各ページにこの方法を使うべきかが決まる
- コンテキストナビゲーションシステムを設計するときは,サイトのすべてのページがメインページ,または独自の目的を持ったポータルであると考える
- ユーザがいったん特定の製品やドキュメントを認識すると,サイトのほかの部分は背景に溶け込んでしまう
- このページがインタフェースとなる
- ユーザがいったん特定の製品やドキュメントを認識すると,サイトのほかの部分は背景に溶け込んでしまう
- コンテキストナビゲーションはクロスセルやアップセル,ブランド構築のチャンスであり,顧客に価値を提供する
- グローバルナビゲーション,ローカルナビゲーションという構造化されたカテゴリが適さない関係のとき
- 埋め込み型ナビゲーションの実装
- 柔軟に動ける性質と過剰なオプション機能でユーザを圧倒してしまう危険性とのバランスを取る
- 成功の鍵: 「ほとんどのWebサイトではグローバル,ローカル,コンテキストのナビゲーション要素が共存していて,コンテンツによるアプリも共存している」と認識すること
- これらの要素を効果的に統合すれば,お互いを補完できる
- 単独で設計は×
- 画面上のかなりのスペースが占領されてしまうため
- ナビゲーションバーによってグローバル,ローカル,コンテキストのナビゲーションをサポート
- 実装方法は,インタラクションデザインやテクニカルパフォーマンスの分野が決定を下す
- 画像/テキスト
- デスクトップブラウザが対象なら明確で実装しやすくアクセスしやすいテキストが〇
- モバイルアプリなどスペースが限定ならナビゲーションオプションをアイコンで示す方が〇
- ナビゲーションバーがページのどこに属するか
- → 図8-15
- デスクトップブラウザが対象なら,グローバルナビゲーションをページの一番上のどこかに配置し,ローカルナビゲーションバーをメインコンテンツと並べて配置
- モバイルWebページでは,ナビゲーションバーをコンテンツの左側か右側に見えないように隠しておくことが多い
- メニューボタンで表示
- 親指が簡単に届く,スクリーン株にナビゲーションバーを配置
- 設計するメディアのルールと制限の認識が必要
- 標準から外れるときはリリース前にユーザテスト
- 補足型ナビゲーションシステム
- サイトマップ,インデックス,ガイド
- 基本的なWebサイト階層外にあり,コンテンツの発見とタスクの遂行を補足する
- 検索も補足型ナビゲーションに属する
- 大規模なWebサイトでユーザビリティとファインダビリティを保証するために欠かせない要素
- 重要性に見合うだけの注目や扱いを受けていない
- ユーザの非常時に支援できる
- サイトマップ
- 上層における2~3番目までの情報階層が提示
- → システム内のコンテンツを一望し,セグメント化されたコンテンツにランダムにアクセスできる
- 画像またはテキストのリンクを利用して,ユーザが直接サイト内のページにアクセスできるようにしている
- 本来サイトマップは階層化構造の大規模なサイトで利用される
- アーキテクチャがそれほどしっかりとした階層になっていない場合は,インデックスやその他の視覚的な表現の方が〇
- 採用するかどうか決定するときは,Webサイトの規模を考慮する
- サイトマップの設計はユーザビリティに強く影響する
- 原則
- 情報階層を強化し,コンテンツの構造にユーザが徐々になじめるようにする
- 自分のほしいものが分かっているユーザがサイトのコンテンツにすばやく,直接アクセスできるようにする
- 過剰な情報でユーザを圧倒しないようにする.目標はユーザを助けることであり怖がらせることではない
- SEOの観点からも有用
- → マップは検索エンジンに配置して,Webサイト全体から重要なページへと直接アクセスできるようにしている
- サイトインデックス
- 階層はなく比較的平坦
- 探し物の名前がすでに分かっている人に対して上手く働く
- 大規模で複雑なWebサイトでは,多くの場合サイトマップとサイトインデックス(とそのための検索能力)の両方が要求される
- サイトマップは階層を強化し,探求を促進
- サイトインデックスは階層を無視して既知項目の発見を容易にする
- どの程度詳細なインデックスを作成するかという問題
- Webページ/ページの各段落や概念/複数のWebページをまとめてインデックスをつけるかなど
- まずユーザがどのような用語を探そうとするのかを把握する
- 検索ログを分析し,ユーザ調査を行う
- 2つの作成方法
- 小規模なWebサイトでは,コンテンツについての知識を利用してどのリンクを含めるのか決め,単純に手作業でインデックスを作成する
- 1ステップ
- 2ステップで用語のローテーションと参照(see also)という特徴のもの
- 最適の結果をアルファベット順のリストで表示
- コンテンツ管理が分散している大規模なサイトでは,ドキュメントレベルで制限語彙インデクシングを利用し,サイトインデックスを自動的に作成するのが〇
- 制限語彙用語は複数のドキュメントに適用できるものが多いため,2段階のプロセスが必要
- まずユーザがインデックスから用語を選択し,次にその用語を用いてインデックス化されたドキュメントの一覧から選択する
- 制限語彙用語は複数のドキュメントに適用できるものが多いため,2段階のプロセスが必要
- 小規模なWebサイトでは,コンテンツについての知識を利用してどのリンクを含めるのか決め,単純に手作業でインデックスを作成する
- 用語のローテーション
- 順列
- 用語を入れ替えたインデックスでは,語句内の言葉の位置がローテーション表示され,そのフレーズをアルファベット順のインデックスの2つの場所からひけるようになっている
- 単語の順番を入れ替えた用語によって,様々な方法で情報を検索できるようになる
- 順番を入れ替えるべき用語はきちんと選ぶ必要
- ガイド
- コンフィギュレータ
- 製品を構成したり,別途注意が必要な複雑な決定木をナビゲートする際に役立つ
- 洗練されたコンフィギュレータでは,ユーザの複雑な意思決定プロセスを詳しく考察できる
- 直線的にプロセスを進んだり,ステップを飛び越えたり戻ったりできる
- サイトのグローバルナビゲーションが常に表示されているので,次に進むべきステップが分かる
- 選択が構成プロセスにどれほど影響を与えるかをはっきり理解してもらうために,さまざまなオプションがあると理解させるヒントを提供する
- 検索
- 補足型ナビゲーションの中心
- 自分の入れたキーワードで情報を探せるという理由から,ユーザに好まれる
- かなり詳細なレベルで結果を得られる
- 言葉の性質があいまいなため,たいていの検索体験には大きな問題が発生している
- 同じものを指していても,ユーザ,著者,情報アーキテクトと,それぞれが使う単語が異なる
- → Ch09
- 高度なナビゲーションアプローチ
- パーソナリゼーションとカスタマイゼーション
- パーソナリゼーションは提供側がユーザの望みを推測し、カスタマイゼーションはユーザが望みを提供側に伝える
- あくまでも既存のナビゲーションシステムの改善または補足に過ぎない
- 現実的な役割
- 一般的に重要ではあるが限られた役目を果たす
- 構造化と組織化の基盤がしっかりしている必要がある
- うまく生かすのは非常に困難
- 計量した数値を収集しユーザ行動を分析するのがさらに困難になる
- 効果的なパーソナリゼーションに必要な情報をユーザは提供しない
- Amazonで持っている本が表示される例
- 全ユーザの経験の操作は×
- カスタマイゼーションの問題
- 大部分の人々はカスタマイズに時間を費やしたくないと考えていて、本当に重要な数少ないサイトでしかそういう作業をしない
- ユーザ自身でさえ、明日自分が何をしたいのか分からないこともある
- 視覚化
- メタファーとして物理的な場を表示したり、ページ間の関係を示したりするのはそれほど有用ではなかった
- 選択が必要な要素の結果がどのように見えるかをユーザが知っている場合は、視覚化が最も有効
- ソーシャルナビゲーション
- 巨大なソーシャルネットワークの興隆により、ソーシャルナビゲーションは情報を構築するための重要な手段となっている
- ほかのユーザの行動を観察することで、ユーザは利益を得ることができるという前提にもとづいて築き上げられたもの
- 例
- トラフィックの量やユーザ主導の投票システムの実装によって、人気のあるコンテンツを見つける手助けをする
- ネットワークでつながった人々や端末が増えるのに従って、生成されるソーシャルナビゲーションシステムは劇的に複雑になり、洗練され、そして便利になる
- 組織は個々のユーザのニーズに合った情報環境のナビゲーション構造を構築する新たな方法を見つける
- 特定のユーザのソーシャルグループの好みにあまりにもぴったり一致したシステムは、ほかのものの見方を軽視しがち
- プレイスメイキングにおいては、グローバルナビゲーション構造が重要な役割を果たす
- Webサイトを訪れるとき、ユーザは共通する、変化のない構造をある程度共有する必要がある
- → バランスが重要
- パーソナリゼーションとカスタマイゼーション
- まとめ
- 進路を定め、現在地を把握し、帰り道を見つけるためにナビゲーションシステムを使う。
- ナビゲーションは前後の感覚を提供し、新しい場所も安心して探検できるようにしてくれる
- ナビゲーションの表層、つまりユーザが操作を行う部分は、非常に速く変化している
- ナビゲーションシステムにはさまざまなタイプがある
- グローバルナビゲーションシステム、ローカルナビゲーションシステム、コンテキストナビゲーションシステムの3つが一般的
- ブラウザなどの情報環境を探検するためのツールは、独自のナビゲーションメカニズムを提供する
- ユーザがシステム内で現在位置の把握を可能にするコンテキストの構築は、ナビゲーションシステムの重要な機能
- グローバルナビゲーションシステムは、情報環境においてすべてのページまたはスクリーンに表示されるもの
- ローカルナビゲーションシステムはグローバルナビゲーションシステムを補足するもので、これによってユーザは現在いるところを探検できる
- コンテキストナビゲーションシステムは環境内で表示されるコンテンツのコンテキスト内にある
- 項目間に定めた関係を発掘することで、ユーザの関連学習をサポートする
- サイトマップ、インデックス、ガイドなど、利用できる補足型ナビゲーションシステムにもさまざまな種類がある
- 進路を定め、現在地を把握し、帰り道を見つけるためにナビゲーションシステムを使う。
Ch09 検索システム
- 内容
- サイトに検索システムが必要かどうか判断する
- 検索システムの基本解剖学
- 検索しやすくするものとは
- 検索アルゴリズムの基本的理解
- 検索結果を表示するには
- 検索interface設計
- もっと学ぶには
- サイトに検索は必要なのか
- サイトにはコンテンツが十分にあるか
- ユーザがサイトにどんな情報を求めてやってくるのかが重要
- 求める情報がはっきりしているほど、検索機能の価値も上がる
- ユーザがサイトにどんな情報を求めてやってくるのかが重要
- より有益なナビゲーションシステムに集中しているか
- サイトの検索システムを最適化する時間とノウハウはあるか
- 検索よりもよい代替案があるか
- 技術的な制約がある場合など
- ユーザは検索を嫌がらないか
- 以上が注意や脅威、以下が実装のタイミング
- 情報が多すぎてブラウズしきれないとき、検索が役に立つ
- 大きな書店のようなイメージ
- 検索は断片化したサイトの役に立つ
- 最優先にすべきことは、組織横断的なコンテンツに対して、可能な限り全文テキストによるインデックス化を行う検索エンジンを設定すること
- 検索は学習ツールである
- ユーザが望むから検索はそこにある
- 探したいものが分かっておらず、ブラウジングで十分かもしれない場合も、とにかく検索してみるユーザ
- あって当然という期待
- 検索はダイナミズムを制御する
- 動的なコンテンツ → 検索システムを構築
- 検索エンジンが自動的にコンテンツにインデックスをつける
- サイトにはコンテンツが十分にあるか
- 検索システムの解剖学
- 何をインデックスするかを選ぶ
- 検索領域を作り、きちんと比較できるものが表示されるようにする
- ドキュメントやレコードの構造における要素の選択
- ふさわしいものを最初に検索し、そこで役立つ結果が得られない場合に、サイト全体を検索できるようにする
- まずは製品を検索し、見つからなければサイト全体を検索するなど
- 検索領域の決定
- ニーズに合わないコンテンツを除外
- サイトの組織化体系を選択する際に下した決断が、検索領域の選択の際にも役立つ(Ch06で開設した項目)
- コンテンツの種類
- 顧客
- 役割
- 主題/topic
- 地理
- 時系列
- 著者
- 部門/business unit
- ブラウジングシステムと同じく、検索領域も大きなコンテンツを細かくし、ユーザにサイトとコンテンツの見方を複数提供する
- 一方で、検索領域によって設定がさらに複雑になり、検索領域を使ってもらえないこともある
- ナビゲーション vs 目的ページ
- サイトを検索する際、ユーザは目的ページを探している
- 検索結果を得るプロセスの途上にナビゲーションページがあると煩雑になり、検索結果が分かりづらくなる
- ナビゲーション vs 目的ページというアプローチの問題点
- 本質的に厳密な組織構造の体系であり、ページの役割をナビゲーションか目的かに限定してしまう点
- 特定のユーザ層のためのインデクシング
- サイトのアーキテクチャにユーザ中心の組織構造の体系を採用しようと決めているなら、ユーザ層ごとに分けた検索領域の作成が〇
- インデックス動詞の重複が少なければ検索のパフォーマンス〇
- 主題によるインデクシング
- 最近のコンテンツをインデクシング
- インデックスをつけつコンテンツの要素を選択する
- ドキュメントの構造を開発・利用する
- コンテンツ要素がより正確な検索を可能にする
- コンテンツ要素が検索結果のフォーマットにも意味を持たせる
- → 検索結果をさらに柔軟に設計できるようになる
- パラドックス
- 最初の検索で高性能な検索機能を求めることはほとんどない
- ユーザが価値があると思っているほかの検索interfaceを研究し、それと同様の機能を提供するかどうか決めるのが〇
- ドキュメントの構造を開発・利用する
- 検索アルゴリズム
- information retrievalに関する標準テキストで詳細は求められる
- 本質的にはツールであり、特定のアルゴリズムが特定の問題解決に役立つ
- 全ユーザの情報ニーズを満たせる検索アルゴリズムは1つとしてない
- 検索エンジンの心臓部
- パターンマッチアルゴリズム
- 再現率と適合率
- 再現率 = 検索された適切なドキュメント数/適切なドキュメントの総数
- 高めると、良い結果とともに不適切な結果も大量についてきてしまう
- 適合率 = 検索された適切なドキュメント数/検索で表示されたドキュメントの総数
- 十分な検索結果が得られればほかの関連情報は要らない場合
- 精度の高さが望まれる
- 反比例の関係
- バランスが大事
- ユーザのニーズによる
- バランスが大事
- ステミング機能
- 同じ語幹を持つ単語を含めて検索
- 再現率が高まる
- 適合率は低くなる
- コンテンツがどれだけ構造化されているのかの考慮
- 構造の一部のみ見れば良い場合の方が精度〇
- 再現率 = 検索された適切なドキュメント数/適切なドキュメントの総数
- 再現率と適合率
- ほかのアプローチ
- クエリビルダ
- 検索結果の表示
- どのコンテンツ要素を表示するか
- 探し物が分かっている人には少なく情報を表示
- 象徴的コンテンツ要素、つまりタイトルや著作者などのみを表示して、求める結果を素早く区別できるようにする
- 何を探したいか分かっていない人にはより多く情報を表示する
- 記述的コンテンツ要素、つまりページの要約やキーワードなどを表示すれば役に立つ
- 何を表示するかユーザに選んでもらう方法もある
- ほとんどのユーザが見るのは結果のうち最初の画面だけ
- 検索結果についてどのコンテンツを表示するかは、各ドキュメントでどのコンテンツ要素が使えるか(どのように構造化されているかなど)にも、またコンテンツがどのように使われるかにも依存する
- 特に引き出すような構造がない場合や、検索エンジンが全テキスト検索をする場合は、ドキュメントのテキストからコンテキストの一部をそのまま表示するのも〇
- 検索用語を太字で強調など
- 探し物が分かっている人には少なく情報を表示
- どのコンテンツ要素を表示するか
- ドキュメントをいくつ表示するか
- ユーザのニーズに合わせて選べるようにさまざまな設定方法を提供する一方で、少ない結果を示すことで単純化し使い勝手を調整していくと、信頼できる検索結果となる
- ドキュメント1つ1つに対して少量の情報なら、得られる結果が多いほうがよいこともある
- 検索で得られたドキュメントの総数は必ずユーザに知らせる
- 検索ナビゲーションシステムの提供も考慮
- 検索ボックスでクエリを繰り返せるようにする
- 検索結果を一覧表示する
- どのような順番でユーザは情報がほしいのか、検索結果をどう使いたいかによって、並べ方が変わる
- 並び替え
- タスクを遂行する際に役立つコンテンツ要素で並び替えが現実的
- ランク付け
- 情報の理解や何かを学ぶ必要がある場合はランク付けの方が役だつ
- 一般的には、ドキュメントの関連性を高いものから順に示すために使われる
- 関連性は相対的なもので、ランク付けするアプローチも厳選が必要
- アルファベット順の並び替え
- 一般的な目的、とくに名前の並び替えには〇
- 時系列の並び替え
- 時間が問題、歴史的なデータを提示する場合に役立つ
- 関連性でのランキング
- 条件
- 獲得したドキュメント内に何回クエリ用語が出てくるか
- そのドキュメントにどれだけの頻度でクエリ用語が出てくるか
- クエリ用語がどれだけ接近して出てくるか
- どこにクエリ用語が出てくるか
- タイトルにある方が本文より〇など
- クエリ用語が出てくるドキュメントの人気度
- ドキュメントの内容が雑多なほど、関連性のランキングには注意が必要
- 人によるインデクシングでも関連性を確立できる
- キーワードと説明文の領域で検索して、日との判断した価値を利用
- 専門技術と時間とにかなりの投資が必要なので、best betのアプローチは実装コストが高くつく
- → サイトの全ユーザクエリの開発には適さない
- recomendationは、最も一般的なクエリに使われるのが一般的で、自動的に出てくる検索結果との組み合わせによって使われるのがほとんど
- 条件
- 人気度によるランキング
- ユーザまたは専門家の評価によるランキング
- ドキュメントとともにユーザ評価を表示すると役立つ
- 広告型検索サービス(Pay For Placement)によるランキング
- 結果のグルーピング
- 一覧にする方法はどれも完ぺきではない
- → 混合させるアプローチの方が上手くいくが、高度なレベルでツールに関わると、検索エンジンを制作する作業が必要になる
- 代わりに、得られた結果を何らかの一般的な観点によってクラスタリングする方法がうまく機能する
- 検索結果がカテゴリ別にクラスタリングされていると、一覧を評価の順番で並べたサイト同様にパフォーマンスが向上するという結果
- トピックやユーザ、言語、製品群などのメタデータを使って手作業で分類するのが効果的
- ただし手作業はコストがかなりかかる
- 図9-21: クエリをコンテキスト化
- 興味にあうカテゴリを選択 → 結果が大きく減る
- 検索の進行中に検索領域を作り出しているようなもの
- 検索結果を出力する
- コンテキスト分析とタスク分析のテクニックえ、ユーザが検索結果で何をしたいのか分かる
- 行動喚起(Call To Action)
- 個々の検索結果にCall To Actionボタンやリンクを含めるのが〇
- 例: アプリのインストール
- 結果のサブセットを選択する
- ショッピングカート機能など
- 検索の保存
- 定期的に動的に生成されるコンテンツのクロールなどには非常に便利
- 検索interfaceの設計
- ユーザと検索テクノロジの機能には幅広いバリエーション → 検索interfaceを設計する「正しい方法」は出てこない
- バリエーションの例
- ユーザの検索経験のレベルと動機付け
- ユーザの求める情報のタイプ
- 検索される情報のタイプ
- 検索される情報の量
- ユーザのニーズの推測が重要
- 検索がうまくいくかどうかは、主に検索エンジンとそのinterface、コンテンツがどのようにタグされ、インデックス化されているかにかかってくる
- → 検索interfaceはできるだけシンプルが〇
- シンプルな検索ボックスと「検索(Search)」というボタンだけユーザに提示する
- ボックス
- 検索システムを設計する際はテストを行うのが〇 ← ユーザは動作を仮定して考えるため
- ユーザが検索をやり直す必要を感じたときに、方法を伝えるようにする
- 本当に複数のフィールドが必要なとき以外は、検索ボックスは1つにしておくのが〇
- 複数必要な場合は分かりやすいラベルが必要
- 無味乾燥な小さい検索ボックスの背景には、数多くの仮定がある
- 設計においては、ユーザの持つ仮定を判断して、そのうえでデフォルト設定を決めるようにする
- オートコンプリートとオートサジェスト
- ユーザが最初に入力したいくつかの文字に遭いそうな結果の一覧が、検索ボックスのそばに表示される
- 検索インデックス、制限語彙、手作業で作成された一致リスト、またはこれらのすべてから選り抜かれたもの
- 表示はシンプルで直接的なテキストの一覧から、高度にカスタマイズされたレイアウトのポップオーバーまでさまざま
- 非常に有効なテクニック
- 一部、または不完全な情報をもとに、ユーザが合っているかもしれない情報を見つける手助けになるため
- ユーザは検索ボックスからシステムを探っていけるので、検索をより賢くしていける
- ユーザが最初に入力したいくつかの文字に遭いそうな結果の一覧が、検索ボックスのそばに表示される
- 高度な検索
- 探している情報の構造を理解しているユーザには、柔軟性とパワーを与える
- ほとんどのユーザが高度検索ページを訪れる必要がないよう、検索システムを設計するという目標を持つ方がよい
- 検索のやり直しのサポート
- ユーザがつまづいてしまったとき
- もっと知るためには
- 書籍
- Searchtool.com
- Search Engine Watch
- まとめ
Ch10 シソーラス・制限語彙・メタデータ
- 内容
- Webサイトのようなインタラクティブな情報環境は、システムが複雑に依存しながらつながりあった集合体
- ページ上の1つのリンクはサイトの構造の一部であり、組織化、ラベリング、ナビゲーション、検索システムの一部でもある
- これらがどのように関わり合っているかを考える必要がある
- システム間のネットワーク関係を見る際に、メタデータと制限語彙はすばらしいレンズを提供する
- さらに、シソーラスのデザインを行うことは、過去と現在との間に存在する溝を乗り越える助けとなる
- メタデータ
- Wikipediaからの引用
- 例
- データの作成方法
- データの目的
- データ作成の日次
- データのクリエイタまたは作者
- データが作成されたコンピュータネットワークのロケーション
- 使用された標準
- 例
- メタデータタグが使われるのは、ほかのコンテンツオブジェクトを描写するため
- コンテンツのナビゲーションと検索を向上させる目的
- 例
- HTMLのmetaタグにおけるkeywords属性
- 例
- 今日では、多くの企業はもっと洗練されたやり方でメタデータを使っている
- メタデータで動く動的なサイトは、分散型オーサリングとパワフルなナビゲーションをサポートするが、こうしたサイトの作成の手段としてコンテンツマネジメントソフトウェアと制限語彙が使われる
- メタデータ駆動型モデルを見ると、Webサイトの作られ方と管理のされ方が大きく変化したことがわかる
- 「分類学のどこにこのドキュメントを入れるか?」から、「このドキュメントをどう表現するか?」と質問できるようになった
- あとはソフトウェアと語彙システムが面倒を見てくれる
- 「分類学のどこにこのドキュメントを入れるか?」から、「このドキュメントをどう表現するか?」と質問できるようになった
- Wikipediaからの引用
- 制限語彙
- 語彙の制限は形も大きさも様々
- 最もあいまいなところでは、制限語彙は自然言語の中で定義された部分集合
- 簡単に言うと、制限語彙は同義語の輪の中にある適当な言葉のリスト
- 典拠ファイルのフォーム内の同意義用語のリスト
- 用語と用語の間に階層的な関係を定義すれば分類体系ができあがる
- 概念間の関連関係(see also, see related など)を規範にすればシソーラスに取り組み始めることになる
- 制限語彙のタイプ: 図10-1
- ↓ 単純→複雑
- 同義語の輪→典拠ファイル→分類体系→シソーラス
- 同義語の輪
- 検索を目的としたときに、同義の言葉であると定義された単語をつなげて1つのセットにする
- 適合率と再現率の問題
- 同義語の輪は再現率を劇的に高める
- 一方で適合率は下がる
- → interfaceデザインをよくし、ユーザの目標をうまく理解すれば、2つのバランスを取ることができる
- 検索結果の1番上には正確にキーワードとマッチした結果を並べる
- 一番最初の検索では同義語の輪を無視し、結果がほとんど不足しているときに、「関連する単語を含めて検索してください」と表示するオプションを加えるなど
- 制限語彙の単純かつ便利な形式
- 今日の多くの巨大な情報環境において、欠かせない基本的な機能
- 典拠ファイル
- 厳密な定義としては、優先語、すなわち条件に合う価値を一覧にしたもの
- バリエーションや同義語は含まれない
- 図書館や政府機関で広く使用され、制限範囲内のエンティティに適切な名前をつけることを目的としている
- 言い換えると、典拠ファイルは好ましいと定義された、または条件に合った価値がある用語を含んでいる同義語の輪
- オンライン環境で典拠ファイルを使うことと、その価値に関する問題
- バックエンドでの理由として、典拠ファイルがあれば、コンテンツの著作者とインデックス供給者は承認された用語を効率的かつ一貫性を持って使える
- 制限語彙管理の点から見れば、優先語があるおかげで類義語の追加、削除、変形を効率よく行え、同義語の中からどれを使えば良いか判定できる
- ユーザにとっては、教育的な面で役立つ
- スペルミス、業界用語の説明、ブランド名の認識など
- コンテキストが非常に異なる場合に、このような「レッスン」が役立つ
- クライアントが使った言葉を理解して、それを企業や業界で使われている用語に翻訳してクライアントに返す
- ユーザが検索からブラウジングに移る際にも優先語は重要
- 分類体系、ナビゲーションバー、インデックスの設計において、優先語を使える
- バックエンドでの理由として、典拠ファイルがあれば、コンテンツの著作者とインデックス供給者は承認された用語を効率的かつ一貫性を持って使える
- ポインタの使用: 用語のローテーション
- 調査と判断の上で、有効なインデックスのみ作成する
- 厳密な定義としては、優先語、すなわち条件に合う価値を一覧にしたもの
- 分類体系
- シソーラス
- 辞書の定義: 類義語と関連する概念の言葉のグループを一覧にした本
- ナビゲーションや検索を改善するために情報環境の中で統合化されたもの
- 語義に関する概念のネットワーク
- 単語とその類義語、同音異義語、反意語、意味が広い用語や狭い用語、関連用語などと結びついている
- オンラインDBの形となっていて、デジタル製品やサービスのUIと緊密に結合している
- 類義語を管理して、言葉のあいまいさを減らし、ほしいものを見つけられるようにする
- 定義
- 検索向上のために同義性、階層性、関連性を明らかにした制限語彙のこと
- これら3つの語義関係を基本にしながら、単純な制限語彙の構造物の上に成り立っている
- 技術専門用語
- 優先語(PT: Preferred Term)
- 変形語(VT: Variant Term)
- a.k.a. entry terms, non-preferred term
- 優先語に相当する言葉、または漠然とした意味での同義語と定義されている
- 広義語(BT: Broader Term)
- 優先語の親
- 狭義語(NT: Narrower Term)
- 優先語の子
- 同義語(RT: Related Term)
- 結合関係で優先語につながる
- See also
- 使用(U: Use)
- 変形語 Use 優先語
- 変形語 See 優先語 と同じ
- 優先関係(UF: Used For)
- 優先語 UF 変形語 の相互関係を示す
- 優先語に対する変化形の全リストの表示のために使われる
- スコープノート(SN: Scope Note)
- 本来、優先語を定義する種類のものではない
- できる限り言葉のあいまいさを除外して限定した意味を伝えることを目的として用いられる
- 優先語が語義の世界の中心
- 作動中のシソーラス
- シソーラスのタイプ
- 古典的シソーラス
- インデクシングシソーラス
- 検索シソーラス
- シソーラス標準
- 語義の関係
- 等価
- 優先語と変形語をつなぐ
- 類義語よりも幅広い用語
- 目標: 検索目的の等価として、用語をグループ分け
- ユーザに見つけてほしいと思うコンテンツに導く漏斗役となる収録語意を作り上げる
- 階層性
- 連想
- 同意義または階層関係内では捉えられない語義のつながりを強くほのめかすもの
- かなり主観的なプロセス
- sub type
- 研究領域と研究主題
- プロセスとその手段
- 概念とその構成要素
- 行動と行動結果
- 因果的依存につながる概念
- オンラインコマースでは、顧客と関連商品・サービスを結ぶよい手段となる
- クロスセル
- UEとビジネス目標の両方の向上につながる
- 等価
- 優先語
- terminology(用語学)は欠かせない
- 用語形
- 基本は標準に従う
- 標準がカバーしている問題
- 文法的語形
- 標準では名詞の使用が奨励されているが、動詞や形容詞を使った方が良い理由も多く存在する
- スペル
- 一貫性が重要
- 単数形と複数形
- 加算名詞は複数形の使用が〇
- 一貫性が重要
- 略語と頭字語
- 一般的な用法がデフォルト
- 文法的語形
- 用語選択
- 文語的な正当さとユーザにとっての正当さのバランスを解決するのに必要なのは、目標がなんであるかと、Webサイトにシソーラスがどう組み込まれているかを再確認すること
- 業界用語をユーザに教えるために優先語を使いたいか、入力語彙として優先語を頼りにしているか
- 用語の定義
- 挿入用語限定子(Parenthetical term qualifier)は同綴異義語を管理する方法を提供している
- e.g. Cell
- スコープノートも、意味をより限定するほかの方法を提供している
- 1つの概念に限定した意味を伝えるためのもの
- インデクサーが適切な優先語を選択するのに役立つ
- 検索の手段か結果として表示されて、ユーザの役に立つこともある
- 挿入用語限定子(Parenthetical term qualifier)は同綴異義語を管理する方法を提供している
- 用語の限定性
- コンテンツのボリュームが増すにしたがって、精度の高い複合語を使う必要性が増す
- 平行階層
- 大規模になれば避けられない
- 精度を高めるためのpre-coordination(複合用語を使って予め調整すること)を高レベルで行う必要が生じる
- クロスリスト
- e.g. Wikipedia
- ファセット分類
- ドキュメントとオブジェクトには多面性がある、つまりファセットがあるという概念の元にシステムを構築
- 旧式のモデルの問い: 「これはどこへ置けばいいか」
- ファセットアプローチの問い: 「どうこれを記述できるか」
- ランガナータンのファセット
- Personality, Matter, Energy, Space, Time
- ビジネスで一般的なファセット
- Topic, Product, Document type, Audience, Geography, Price
- フィールドを持つDBの構造を、Web上でより同質のドキュメントとアプリケーションの混合物に適用すること
- フリーサイズ型アプローチよりも、コンテンツの異なる面に注目した複数の分類学の概念に取り組んでいる
- e.g. Wine.com
- interface内でいつどのようにファセットを手段とするかについて決定
- merit: すばらしい能力と柔軟性
- 基礎をなす記述的なメタデータと適切な構造のおかげで、ナビゲーションの選択肢を何百通りも試せる
- ガイド付きナビゲーション: 発見しやすさと利益性が明確に直結している通販サイトですぐに採用された
- 展望
- まとめ
- シソーラス、制限語彙、メタデータは、フロントエンドのエクスペリエンスをシームレスでかつ満足できるものにするため、情報環境のバックエンドで運用される
- メタデータタグは、ドキュメント、ページ、画像、ソフトウェア、ビデオ、オーディオの各ファイル、またその他のコンテンツオブジェクトを説明し、効率よくナビゲーション、検索できるようにするために用いられる
- 制限語彙は自然言語のサブセットであり、同義語の輪、典拠ファイル、分類体系、シソーラスが含まれる
- これらのシステムによって言語を構造化、マップ化できるため、利用者はより簡単に情報が探せるようになる
- ファセット分類と平行階層によって情報を複数の方法で提示できるので、利用者は自分が探しているものを自分の方法で見つけられる
Part 3 information_architectureの仕上げ
- information_architectureを作り上げるためのプロセスとメソッドを追求していく
Ch11 調査
- 内容
- information_architectureの開発プロセスへの統合
- 人、コンテキスト、コンテンツを学ぶ方法と理由
- ステークホルダーへのインタビュー、実践的評価、ユーザテスト、カードソーティングを含む調査方法
- 開発プロセス: 調査→戦略→設計→実装→保守
- 調査
- 現在ある背景の情報をよく検討し、戦略チームとミーティングを行うことから
- 目的: 目標とビジネス上のコンテキスト、既存のinformation_architecture、コンテンツ、対象としている顧客をよく理解すること
- その後、情報の生態環境を探求するために、様々な手法を用いて一連の調査、検討を行っていく
- 戦略
- 設計
- 実装
- 保守
- サイトのinformation_architectureを継続的に評価し、改善する
- 新しいドキュメントに対するタグ付けや古いドキュメントの削除といった日常的タスク
- サイトの利用状況やユーザからのフィードバックのモニタリング
- 調整を通じてサイトを改善する機会を明らかにする
- 調査フレームワーク
- 適切な質問を選ぶための幅広い環境の概念的なフレームワークが必要
- コンテキスト、コンテンツ、ユーザのベン図でバランスを取る
- 適切な質問を選ぶための幅広い環境の概念的なフレームワークが必要
- コンテキスト
- ビジネスのコンテキストを調査することから始めるのが〇
- プロジェクトは、目標を明確に理解し、政治的環境を正しく認識するところから始めるべき
- 必要なものの入手
- プロジェクトにサポートを受けるためのプレゼンテーションと説得
- 背景調査
- 適切な人に適切な聞き方で適切なタイミングで質問する
- サイトの使命、ビジョン、目標、期待される顧客、コンテンツに関するものならどんなドキュメントでもよいので手を付ける
- マネジメント構造と企業文化の鳥瞰図を得られるようなドキュメントも見つける
- 特に組織図は、組織に対するユーザのメンタルモデルがどうなっているかという重要な要素を表している
- インタビューやテストを行う際に、どの出資者、ユーザグループに依頼すればよいかを決めるのに役立つ
- NOTE: ビジョンと実際のサイトとの比較の意義
- 導入のプレゼンテーション
- 調査ミーティング
- 戦略チームミーティング
- 難しいけれど必要な質問を質問しやすいと感じられるのは、顔をあわせた実際の会話の中でのみ
- 小規模で、自由な雰囲気で行うことが大切
- 議題
- システムの目標
- 期待されている顧客
- 計画しているコンテンツと機能
- アクセスのためのチャンネル
- 誰が作業にかかわるか
- いつ結果が必要か
- 予期している障害は何か
- コンテンツマネジメントミーティング
- 情報技術ミーティング
- 戦略チームミーティング
- ビジネスのコンテキストを調査することから始めるのが〇
『コンピュータネットワーク 第5版』5.1-5.4 学習メモ
(ノートから一部書き起こしたものです)
Ch05 network_layer
目的
- network_layer: パケットを送信元から宛先に届ける役割
- data_link_layerは、一端から他端にフレームを送るのみ
- → network_layerがe2eの転送の最下層
- 送信元と宛先が異なったnetworkにいるときの対応
5.1 network_layerの設計課題
- 目的
- network_layerの設計課題を見る
- transport_layerのサービスやnetwork内部の設計課題も含む
- 内容
- 蓄積転送方式のパケット交換
- transport_layerに提供するサービス
- e2e argument → connection less型のnetwork_service
- internet
- hostがエラー制御やフロー制御をする
- 通信事業者 → connection型サービス
- IP vs MPLS(Multiple Protocol Label Switching), VLAN
- connection less vs connection
- この自由度は未決着
- e2e argument → connection less型のnetwork_service
- connection less型サービスの実装
- データグラム: 電報と類似したパケットの振る舞い
- datagram network
- ↑→ connection型 → VC(Virtual Circuit) network
- routing algorithm
- IPが代表例
- データグラム: 電報と類似したパケットの振る舞い
- connection型サービスの実装
- label switching: connectionの識別子の出力を変えて、重複回避
- e.g. MPLS @ISP
- network内でのVCとDatagramの比較
- VPNのように長期利用ではVCがとても有効
5.2 routing algorithm
- 目的
- 内容
- 最適化原理
- sink treeの発見
- DAG
- 最短経路routing
- ルータを頂点、間の通信戦を辺として、networkを表すグラフを構築
- flooding
- broadcastには効果的
- ロバスト性とても高い
- 性能評価の尺度。floodingは常に最適
- 距離ベクトルルーティング
- dynamic routing_algorithm
- routing tableのエントリを保持
- 無限カウント問題
- link_state_routing ← 距離ベクトルルーティング
- 5 steps
- 隣接ルータに関する情報収集
- 指名ルータをルータNの役割とする
- link costの設定
- link state packetの構築
- link state packetの分配
- 新しい経路の計算
- 隣接ルータに関する情報収集
- e.g. (旧)多くのISPがIS-IS(Intermediate System-IS) Link State Protocolを使っている
- e.g. (新)OSPF(Open Shortest Path First)
- ルータの故障の損失の最小化が重要
- 5 steps
- 階層化routing
- ルータをリージョンに分割
- 代償: 経路長が増大
- N個のルータのネットワークにはlnNのレベルが〇 → 各ルータは合計elnN個のエントリを持つ
- broadcast_routing
- multidestination routing
- flooding〇
- reverse path forwarding◎
- 送信元への経路が最短のときだけすべてのLinkに送信
- 容易な実装と効率〇
- spanning treeの使用
- multicast routing
- any cast routing
- グループ内で最も近いメンバにパケットを送信
- DNSで利用
- mobile hostに対するルーティング
- ad hoc networkにおけるrouting
- 最適化原理
5.3 輻輳制御アルゴリズム
- 目的
- congestion collapseの回避
- good put: 送信速度
- 帯域、リンクの送信速度のほかに、ルータのパケット処理速度も輻輳の原因になる
- congestion_control: 大域的問題、全ルータとホストが関係
- flow_control: 特定の送受信者間の問題
- 対応
- congestion_control手法
- 緊急対策
- provisioning(予防的)
- traffic aware routing
- admission control(流入制御)
- load shedding(負荷遮断)
- 緊急対策
- traffic aware routing
- routingが極めて不安定
- → 流入量が緩やかに変化。routing protocolの外側から調整する: traffic engineering
- admission control
- trafficの抑制
- 負荷遮断
- wine(古が〇)とmilk(新が〇)のポリシー
- packetの重要性による判断
- ランダム初期検知
- RED(Random Early Detection): ルータで早めにパケットロスを発生
- packet lossを検知 → transport_layerで送信速度を下げる
- ECNの方が望ましい
- RED(Random Early Detection): ルータで早めにパケットロスを発生
- congestion_control手法
5.4 QoS
- 目的
- 内容
- アプリケーションの要件
- traffic shaping
- packet scheduling algorithm
- 許諾制御
- 厳密な保証。フローごとに互いに独立
- QoS routing
- flow spec: flowのparameterの集合
- 統合サービス: IntServ
- 差別化サービス: DiffServ
『 ソフトウェア品質知識体系ガイド(第3版)』学習メモ
第3版出版によせて
- ソフトウェアシステムは、あらゆる社会活動の基盤であるとともに、新たな価値創造の基盤
- 成功の鍵は品質
- 過去の失敗や成功の経験から学び続ける
- → 品質管理の本質をあらためて尋ねること
- → 不確実な時代に必要な知見を新たに探ること
- 成功の鍵は品質
- SQuBOK(Software Quality Body Of Knowledge)
- 品質にまつわる経験や知見を体系化し、その体系へと容易にアクセス可能とするガイド
- 第3版の改訂の要点
- 引き続き重要なsoftware_qualityの知識体系の再整理
- 国際規格の改訂の判定、セキュリティに代表される専門性の高い品質の知識拡充
- 不確実な時代に不可欠なデータ駆動および価値共創における価値共創にソフトウェアの品質の考え方を取り込んだ
- データとデジタル技術を通じたDXを進めるうえでデータ駆動および価値共創のパラダイムが根幹にあり、リスクを押さえつつその真価を最大限に発揮させるために必要な品質のマインドと技術の変革を整理
- 引き続き重要なsoftware_qualityの知識体系の再整理
- データ駆動は、データに基づき知的なサービスを適応的に提供しビジネスや社会上の価値を創造し続ける
- 従来のような明確な正解に基づく計画的な品質保証よりも、目標に対し仮説的に組み上げてモニタリングし、変化に応じ改善し続ける仮説検証および探索的な品質の組み入れが重要性を増す
- データやその源泉の規模および多様性に王子、セキュリティやプライバシー、相互運用性がより重要になる
- 価値共創 → 能動的にあらゆる時点でモニタリングおよびフィードバックし続けるという品質の組み入れが重要
はじめに
序章 SQuBOKガイド 概略
- 知識領域を5つのカテゴリに大別
- software_qualityの基本概念
- software_quality_management
- software_quality技術
- 専門的なsoftware_qualityの概念と技術
- software_qualityの応用領域
- 構成
- サブカテゴリ、知識領域、副知識領域を各カテゴリで見る
- Error(誤り、誤差), Fault(障害), Failure(故障)の区別
- Error: 計算、観測もしくは測定された値または状態と、真の、指定されたもしくは理論的に正しい値または状態との間の相違
- Fault: 要求された機能を遂行する機能単位の能力の、縮退または喪失を引き起こす、異常な状態
- ソフトウェアバグなど
- Failure: 要求された機能を遂行する、機能単位の能力がなくなること
- ソフトウェアが意図したとおりに動かない現象
- 意図しない結果を引き起こす人間の行為はmistake, human_errorとして別に定義
- メトリクスに関する擁護
- measure, measurement_methodがmetricに代えて使用されているが、これまでの論に合わせて測定量や測定方法を区別したりISO/IEC 25000シリーズに言及するとき以外は、「メトリクス」を用いる
Ch01 software_qualityの基本概念
KA: 品質の概念
- 品質の定義
- software_qualityの代表的な定義: 明示された状況下で使用するとき、明示的ニーズまたは暗黙のニーズを満たすためのソフトウェア製品の能力
- 品質の本質の理解のためには、顧客の要求把握、要求の実現、結果として得られる顧客満足という3つの要素から考える
- 顧客の要求
- 明示的要求や規制要求事項だけでなく、明示されない常識的な要求や潜在的なニーズや期待などを含む
- 時間の要素も考える
- 要求の取捨選択やバランスが重要
- 要求の実現
- 多くの技術の中から適切な技術を選ぶ
- 技術利用の場面では、プロジェクトに与えられたQCDやプロジェクトの技術レベル、プロセス、開発環境などのプロジェクト特性を考慮し、適用する技術の効果が出るように工夫が必要
- セキュリティインシデントのようなリスクを低減させつつ、つながることによる便益を最大限にするといった要求の実現が求められている
- 結果として得られる顧客満足
- ICTの進展に伴ってIoTやAIの適用が拡大するにつれ、品質に対する要求はますます多様な広がりと深さを増す
- IoTでは、セキュリティ、セーフティ、信頼性に加えて、プライバシーやレジリエンス(跳ね返る→前の位置に戻る、中止する)などが重要な特性
- AI では、AIの予測精度だけでなく、利用目的に応じて、公平性、説明可能性、プライバシー、信頼性、セキュリティ、セーフティなどさまざまな特性が求められる
- → 幅広い要求を説明する用語として、Trustworthinessが使われるようになった
- 企業と品質のソフトウェア
- 企業の視点からの品質の意味
- どのような経営環境の変化にも的確に対応し、顧客からの高い評価を受け続けることで、持続的な経営ができる
- 経営の要素として、ヒト、モノ、カネ、情報
- DXにより企業の経営スタイルやビジネスモデルは変革期にある
- ソフトウェアシステムは社会基盤として極めて重要な位置づけとなった
- 社会生活を支えるうえで求められる品質は多岐にわたり、継続的な維持と時代に合わせた変革が必要
- サービスの価値が利用体験の中で便益を享受したものが独自に見出すものであることから、企業と顧客の価値共創が品質の要となる
- このように、ソフトウェアの位置づけの変遷、価値の認知や送出スピードの変化を的確に把握して、製品やサービスの品質を考えることが肝要
- software_qualityに関する用語
- 序章のError, Fault, Failureの部分
- 機能性欠陥は、障害の定義に該当し、故障を引き起こす
- 発展性欠陥は、コードの読みやすさや構造などに起因し、コーディングルールなどの組織標準との乖離(anomaly)に相当する
- 保守工数の増大や機能性欠陥の誘発へとつながるものの、必ずしも故障を引き起こさない
- 開発途中の障害には発展性欠陥も含める
- S-KA: 品質の定義(品質の考え方の変遷)
- S-KA: software_qualityモデル
- ソフトウェアの品質を階層構造のモデルで表現したもの
- 誤りの有無のみで評価されるのではなく、ユーザのニーズを満たすために様々な視点のsoftware_quality特性から評価が必要
- T: システムおよびソフトウェア製品の品質モデル(ISO/IEC 25000シリーズ)
- システムおよびソフトウェア製品の品質要求と評価に関して規定している国際規格
- SQuaREシリーズと呼ぶ
- 利用時の品質モデル
- 利用者が実際に把握できる品質特性からなるモデル
- 有効性、効率性、満足性、リスク回避性、利用状況網羅性
- 製品品質モデル
- 機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性
- データ品質モデル特性
- 正確性、完全性、一貫性、信憑性、最新性、アクセシビリティ、標準的合成、機密性、効率性、精度、追跡可能性、理解性、可用性、移植性、回復性
- 25000 シリーズの構成
- 品質管理部門
- 共通するモデル、用語の定義
- 品質モデル部門
- 品質測定部門
- 品質要求部門
- 品質評価部門
- SQuaRE拡張部門
- 品質管理部門
- T: その他の品質モデル
- ソフトウェアの品質を階層構造のモデルで表現したもの
- KA: software_qualityの概念
- software_quality: 品質に関する「組織を指揮し、管理するための調整された活動」
- 主眼: 顧客の要求事項を満たすことおよび顧客の期待を超える努力をすること
- 急激なビジネス環境の変化に対応するために、組織の状況に応じて動的に適応できる能力が重要
- → 制御や統制というより、環境変化へ柔軟かつ臨機応変に適応しながら目的を達成していく活動といった意味に拡大解釈されるようになった
- 品質は、意図した機能やパフォーマンスだけでなく、顧客によって認識された価値および顧客に対する便益も含まれる
- ISO 9000では、software_qualityは全体を包括する用語
- 品質計画において、品質要求事項を満足するための基準などの計画を策定する
- → この計画にしたがって基準と照合し、基準を満足した製品とすることが品質管理
- 品質保証は、品質を確認する活動の実施状況を、証拠をもって示す活動
- 新製品開発重点主義
- 品質は設計と工程で作りこむ
- 要因系に焦点を当てるsoftware_qualityは日本で発達してきた方法であり、製品とサービスを作り出すプロセス重視のマネジメント
- 原因を排除することで、初めから品質の良いものを作り出すプロセスづくりを基本とする
- → プロセス実施状況を計測して分析し、プロセスを改善する
- S-KA: 品質保証の考え方
- ISO 9000では、品質保証を「品質要求事項が満たされるという確信を与えることに焦点を合わせたsoftware_qualityの一部」と定義
- 活動内容について、信頼感を付与するために証拠をもって示すよう要求
- 国や地域によって意味が異なる
- 方法は、プロセスのアウトプットであるプロダクトの品質を直接確認する方法と、プロセスの実行状況を監視することで品質が確実に作りこまれていることを確認する方法がある
- これらを、要求品質レベルに応じて組み合わせて実施することが大切であり、どちらかに偏っては不十分
- 不適合品の生成を減らす必要もあるし、不適合品を検出する必要もある
- → プロダクトとプロセスの両面から品質を確認することが肝要
- そのほか、V&Vや測定などの品質保証のための重要な手法も、要求品質レベルに合わせて実施する
- ISO 9000では、品質保証を「品質要求事項が満たされるという確信を与えることに焦点を合わせたsoftware_qualityの一部」と定義
- S-KA: 改善の考え方
- 改善: 市場や事業環境の変化へ効果的に対応する自己変革のメカニズム
- 目的を効率よく達成するためのすべての活動がマネジメント
- 改善はそのための武器
- 目的に対して、より効率よく達成するための方法を模索し、不備を明確にして自己を変えていく、論理的かつ体系的は修正が改善
- 基盤となる標準が必要
- → 組織の経験やノウハウを標準として整理し、その標準を出発点として不備を明確化し、修正する
- ISO 9000では、改善を「パフォーマンスを向上するための活動」、継続的改善を「パフォーマンスを向上するために繰り返し行われる活動」、革新を「価値を実現するまたは再配分する、新しいまたは変更された対象」と定義して区別している
- 本来の改善は、それぞれの意味を含む
- 急激な社会変化に対応するためには、抜本的な改善や革新を含めた「改善」が必要
- T: PDCA
- 計画では、目的、目標、狙いを明確にし、目的達成のための手段や方法を決定する。そして管理項目を決め目標値を設定する
- 実施では、管理項目のデータを取りながら計画を遂行する
- 確認では、目標達成にかかわる進捗や対応状況を、データをもとにして論理的に判断する
- 処置では、目的あるいは目標と実施の結果に差があるかを見て、その差に応じて対処し、次の計画に結びつける
- OODA
- 指揮官のあるべき意思決定プロセスを理論化したもの
- スピードと柔軟性を重視し、ループを高速で回して意思決定を繰り返す
- 計画の代わりに観察から始まるので、状況に応じて臨機応変に意思決定できる
- T: 改善(KAIZEN)
- 現状の不備を明確にして、その不備を論理的かつ体系的に修正する活動
- 目的: 品質、コスト、納期の向上を含む総合的なsoftware_qualityを達成すること
- 全員参加かつ継続的な活動
- すべての人がプロセスオーナーの意識
- 責任感と自負心の向上を促す
- → 組織全体で自律的に不備を修正
- ↑ 常に変化する事業環境や市場に対応するための重要な施策
- ソフトウェアでは細かいミスにより致命的な結果を招くことがあるので、改善(KAIZEN)は重要
- 常に新しい技術やサービスが生み出される市場でもある
- ツールとして、QC_circle活動
- TQM(Total_Quality_Management)の中核
- software_quality: 品質に関する「組織を指揮し、管理するための調整された活動」
- KA: ソフトウェアのsoftware_qualityの特徴
- 物理的実体を持たない論理の集合体なので、開発の工程はハードウェアの設計工程に近い
- 物理化学法則や空間的干渉がないという点で、自由度が高い
- → 構成要素の組み合わせが膨大になり、論理無住などの誤りを作りこみやすい
- 技術の変化が速いので、再利用部品の開発は難易度が高くなっている
- 論理の集合体であるソフトウェアは、外部仕様である働きとその働きを実現する内部仕様との2つを関連付けることが難しい
- → ソフトウェアを変更する際の難しさの本質
- 測定すべき物理特性がほとんど存在しないため、何らかの特性を定義しながら設計する必要がある
- 生産工程がないうえに測定が難しいので、ソフトウェアのテスト工程はハードウェアの検査工程とは異なる位置づけになる
- → ソフトウェアのテストはハードウェアのDR(設計レビュー)に対応し、非常に高いスキルが要求される
- 物理的実体がない → 劣化しない
- ソフトウェアの障害はすべて系統故障 → 同一の条件下では必ず障害が発生してしまう
- → 故障率やMTBFなどの信頼性指標では単純にソフトウェアの信頼性を表せない
- ソフトウェアの障害の体系化のためには、障害の原因調査、影響評価を行い、ソフトウェア故障モードを抽出する取り組みが必要
- 自然言語の使用
- 開発そのものが難しいだけでなく、開発のゴールを記述する仕様の信頼性も低くなりがち
- ソフトウェアの開発は人間の知的作業による
- 人間の知的作業の質は、モチベーションが大きく関係する
- → やりがいを感じ、快適と感じられる環境が必要
- チームワークやリーダーシップ、それらを支えるコミュニケーションも重視
- これらの特徴を十分理解したうえで、ソフトウェアのsoftware_qualityを実施する必要がある
- まず、定石やデザインパターンなどを用いて設計の自由度を抑制し、品質向上に寄与する指標を検討するといったソフトウェアエンジニアリングの充実が必要
- 仕様のレビューや管理も重要
- 次に、障害を分析することで、故障モードのようなソフトウェア開発の悪さの知識を抽出し、体系化したうえで蓄積が必要
- モチベーションとチームワーク
- 例: アジャイル
- 開発の難しさの本質は変わらないが、細かい単位の開発は、ソフトウェアの仕様のあいまいさやそれに伴う信頼性の低下を緩和する可能性がある
- S-KA: プロダクト品質とプロセス品質
- ソフトウェア製品のライフサイクルにおける品質を、製品そのものおよび過程の2つの側面から捉えた品質
- 図1.3.1: ライフサイクルでの品質
- ソフトウェア製品の品質を、内部特徴、外部特徴、利用時の品質の3つに分類し、それぞれが影響と依存の関係にあるとしている
- 一般的な製品の品質管理では、プロセス品質をプロセス能力や工程能力もしくは工程性能を呼ぶことがある
- プロセスの品質をアウトプットのばらつきとして捉え、このばらつきを収束させることでプロセスの安定した結果を保証できると考えているため
- プロセスのばらつきとして管理する対象は、プロセスの成果物の障害だけでなく、コストや納期なども対象になる
- ばらつきを収束させる活動として、プロセスの改善活動が行われる
- 初期の段階でばらつきの少ない状態を得ることを目的として品質工学の手法が適用されることもある
- 仕様の間違いやプログラムの誤り(一般的な障害)は、プロダクト品質のばらつきとして品質管理手法で制御可能
- ソフトウェアの仕様や機能の品質は、上流工程の規格や設計で作りこむ必要がある
- S-KA: 品質作りこみ技術の考え方
- 成果物を作成する過程で品質を確保するための作業を施し、後に続く工程に障害を流さないようにするという考え方に基づく技術
- 主に作成後のソフトウェアの評価を目的とするテストとは考え方が異なる
- 要求分析や設計の工程では、対象をモデル化してシミュレーションや形式手法による検証を実施することにより、要素間の干渉や矛盾を明らかにし、実現可能性を評価できる
- モデル化: 認知したい構造、振る舞い、現象などについて、別の効率的な形式や方法による表現を用いること
- 複雑さ、不可逆性を回避するよう単純化し、もとの現象などを扱いやすくすることが多い
- たいていは抽象化を伴う
- モデル化: 認知したい構造、振る舞い、現象などについて、別の効率的な形式や方法による表現を用いること
- モデルを用いたシミュレーションは、実装前にシステムの振る舞いを確認できるという点で、開発中に品質を作りこむ方法
- 数理的な理論に基づき厳密なモデルを作成できれば、形式仕様記述やモデル検査を提供する各種の形式手法を用いて、論理的な不整合の検出や動作の妥当性の検証が可能になる
- ソフトウェアパターンの適用もまた、開発中に品質の作りこみを期待できる方法
- ソフトウェアパターン: ソフトウェア開発の工程や領域の特定文脈上で繰り返される問題と、それに対して繰り返し適用されてきた熟練者による解決策をまとめて名づけ抽象化したもの
- 繰り返し利用されてきた解決策の思考過程と成果を再利用することにより生産性や品質の向上を期待できると同時に、適用対象の構造を一貫させ、利害関係者間のコミュニケーションや理解を促進する
- S-KA: システムおよびソフトウェアの測定と評価の考え方
- システムおよびソフトウェアの測定は、「測定量の値を決定するという目的を持った操作の集合」と定義されている
- 測定を本格的、体系的に導入する際は、多くの工数が必要になる
- 測定の妥当性や必要性を真の目的に照らして絶えず見直し続け、形骸化させないよう留意する
- システムおよびソフトウェアの評価は、「ある"もの"が、規定要求事項をどれだけ満たすことができるかの程度を示すための体系的な審査」と定義されている
- ソフトウェア製品の品質を向上させるためには、製品の品質上の属性の測定だけでなく、測定結果を活用した品質評価が不可欠
- 評価結果のよしあしの判断根拠となる要求事項があらかじめ明確化されていること、および、評価プロセスが確立されていることが必要
- 要求事項は、汎用の品質モデルを用いることで、品質特性と品質副特性を網羅的に定義できる
- 評価プロセスの共通的な枠組みは、「最初に評価要求を確立し、次に評価を仕様化し、設計し、そして実行する」プロセスとして定義されている
- S-KA: V&V(Verification & Validation, 検証と妥当性確認)
- Verification: 仕様適合性を確認
- Validation: ニーズ充足性を確認
- merit
- リスクが高い問題の早期発見
- システム要求に対する成果物の評価
- 品質と開発進捗状況に関する情報の継続的な共有
- システムのできばえが順次見えることによるユーザとの早期調整
- Independent V&Vもある
Ch02 software_quality_management
- 品質管理のためのアクティビティについて
- 品質は経営層から現場に至るすべてのレイヤの体系化されたアクティビティにより追求すべきものであり、品質管理に関するアクティビティは多岐にわたる
組織レベルのsoftware_quality_management
- KA: software_quality_management_systemの構築と運用
- quality_management_systemと改善アプローチ
- 主眼: 顧客の要求事項を満たすこと、および顧客の期待を超える努力をすること
- quality_management_systemは、quality_management活動のパフォーマンスを計画し、実行し、監視し、改善するための枠組みを提供する
- 有効性の改善には、プロセスアプローチが推奨される
- 相互に関連するプロセスで構成されるため、システムによって結果がどのように生み出されるかを理解することで、組織はシステムやそのパフォーマンスを最適化できる
- 急激なビジネス環境の変化 → quality_management_systemを動的なシステムとして捉えるようになった
- この場合も、計画の実施をquality_management_systemのパフォーマンスの両方を定期的に監視および評価することが重要
- quality_management_systemの特徴と対応
- ソフトウェアは、開発過程を見える化しにくく状況や状態を把握しづらい、論理の塊
- チームワークなどの人間的要素が強く品質へ影響するといった特徴
- → 見えにくい対象を把握し、論理の塊を技術面から整理して取り扱い可能にするとともに、開発者のチームワークやモチベーションを向上させる仕組みを持ったquality_management_systemを構築することがポイント
- 2つの責務
- 品質
- プロセス
- この2つの責務を明確にした組織形態がソフトウェアには必要
- 製品の品質に対する責務だけでは、プロセスを大きく変えるような革新的な技術を導入する機会を持ちにくい
- 両方の責務を持つという動機付けを持った組織が、quality_management_systemを推進することが重要
- 組織的かつ継続的にquality_management_systemを改善するには、障害の顕在化を契機として改善のサイクルを実行する活動が取り込みやすく効果的
- 真の原因を分析することで、その障害が二度と作りこまれないようにプロセスを改善する
- サービスも提供している場合はサービスも対象とする
- サービスの品質は、モノの品質との違いから考えるのではなく、サービスを中心において、その提供者と受容者が共創しながらサービスやモノの価値を作っていく
- SLAやDevOpsとも関係が不快
- サービスの品質は、モノの品質との違いから考えるのではなく、サービスを中心において、その提供者と受容者が共創しながらサービスやモノの価値を作っていく
- S-KA: quality_management_system
- quality_managementには、品質方針および品質目標の設定、ならびに品質計画、品質保証、品質管理および品質改善を通じて、これらの品質目標を達成するためのプロセスが含まれている
- 目指すべき品質目標は、トップマネジメントによる品質に関する方向付けのもと設定される
- 日本のTQCおよびTQMの発展の中で培われたquality_managementの考え方: お客様が安心して使っていただけるような製品を提供するためのすべての活動
- 徹底した顧客満足の追求や品質を中核とした全員参加での改善が基本
- 不十分でもとにかく動き出して全員が今より高いところを目指してプロセスそのものを動的に改善しながら進めるという、日本独特の考え方
- 欧米は、プロセスを定義してそのとおりに実行しているかどうかを確認する
- QC_circle、統計的技法などの道具を試用し、組織全体がシステムとして機能しているかのような日本型のマネジメントシステムのメリットは、全員が同じ目的に向かって活動するために効率的で無駄のない組織運営ができる点
- T: quality_management_systemに関する規格(ISO 9000 series)
- 目的
- 経済活動のグローバル化が世界的に進む中、スムーズな商取引のためにquality_management_systemへの要求事項の標準化が求められた
- quality_management_systemの認証制度により急速に普及
- 方法
- quality_management_systemの認証制度の基準規格はISO 9001
- 効果
- 認証により、自組織のquality_management_systemが世界に通用するものであることを証明するとともに、継続的な審査によりそれを維持できる
- 留意点
- 認証があっても品質に問題がないとは限らない
- コストに見合う改善効果が得られるとは限らない
- ISO 9001の要求事項への適合にとどまらず、製品およびサービスレベルの改善や顧客満足の向上を意識した改善活動をするとよい
- 目的
- T: TQM(Total_Quality_Management)
- 企業及び組織の経営の「質」の向上に貢献する経営科学および管理技術
- 「質」: 経営プロセス(Value_Chain)とそのプロセスに関わる広義のリソース(経営資源)の質
- QC, TQCに続く第3世代の品質管理
- 世代ごとに、製品そのもの → プロセス → 総合「質」が管理対象
- 持続可能な成長をもたらすための方法論として、TQCの強みを継承して生まれたのがTQM
- 目的
- 企業や組織が「尊敬される存在」「ステークホルダーと感動を共有できる関係」を目指し、「称賛される競争力(技術力、対応力、活力)」の向上を図る
- 方法
- 構成要素
- フィロソフィー、コア・マネジメントシステム、手法、運用技術
- これらの適用により、経営プロセスや経営リソースの質的向上を目指す
- 手法には、科学的問題解決法、QC7つ道具、新QC7つ道具など、ソフトウェア組織でもなじみ深い手法が含まれる
- 構成要素
- 効果
- 企業の競争力向上による収益力の増大を実現するとともに、重要な経営課題をいち早く察知し、解決することに貢献する
- 留意点
- TQMは、プロセスとして定義可能であり、結果を左右する要因を制御できるような領域に適用可能
- 政治的要因や文化的要因、情緒的要因などが大きくかかわるような領域では効果を発揮しにくい
- T: quality_management_system-持続的成功の指針
- 成熟した経済社会環境にある企業が、経営環境の変化に的確に対応し、顧客からの高い評価を受け続けることによって、財務的にも持続的に成功するような経営スタイルを実現するための指針を示す規格
- 目的
- 成熟した経済社会環境にある企業が、持続的成長を実現するための指針を与える
- 方法
- 品質という観点から事業運営を見直し、事業運営とは競争環境における顧客価値提供マネジメントであるとの視点に立ち、製品およびサービスを通して顧客にどのような価値を提供すべきか、その価値提供において組織が持つべき能力は何か、その能力はquality_management_systemのどの要素に実装されるべきかを考察する
- → 事業環境変化によって組織が持つべき能力がどう変わるかを認識し、革新していく
- 効果
- 企業が高い顧客価値を創造し続け、競争優位を確保し、持続的成功を実現できる
- 留意点
- 第1版での「質」とした(「品質」としなかった)理由について
- S-KA: security_management
- セキュリティ、すなわち守るべき資産の価値が損なわれる脅威を回避、もしくは軽減することを、組織全体を対象としてマネジメントすること
- T: common_criteria(CC)
- ソフトウェア、ファームウェアまたはハードウェアとして実装されたIT製品のセキュリティ評価のための共通基準
- 構成
- 一般的な概念とモデル、機能性に関する共通要件、保証手段に関する共通要件
- 評価プロセスにおいてCCのための共通評価方法(CEM)を使うことで、広範な対象者が国際的に共通の枠組みに基づいて評価結果を比較及び参照可能となっている
- CC/CEMと表記
- 主要各国のIT製品のセキュリティ評価認証制度に適用され、主に政府機関で調達要件として活用される
- 目的
- 方法
- 開発するソフトウェアのセキュリティ評価にCC/CEMを適用する一般的な方法
- そのソフトウェアに適用すべきPP(Protection_Profile)の有無を確認の上、保証のレベルと評価対象の範囲を特定
- CCを参照し、保護資産、脅威、セキュリティ目標、セキュリティ機能要件、セキュリティ保証要件、および要件の実現方法を定義するST(Security_Target)を作成する
- ソフトウェア開発において、STに従ってセキュリティ機能を実装するとともにCC/CEMを参考として実装の各プロセスである開発、ガイダンス、ライフサイクルサポート、テストおよび脆弱性への対応に係る保証手段がSTで定義したレベルを満たすことを保証するエビデンスを作成する
- ITセキュリティ評価認証制度を利用する場合、認証申請手続きとしてST を認証機関に提出後、第三者評価機関による評価を受け、評価結果について認証機関の確認を経て、そのソフトウェア製品に対する認証書を取得する
- 開発するソフトウェアのセキュリティ評価にCC/CEMを適用する一般的な方法
- 効果
- ソフトウェア開発において、セキュリティ要件を英利子、具備すべきセキュリティ機能と実施する保証手段の妥当性を国際基準に基づき自己評価するために役立つ
- ITセキュリティ評価制度の評価及び認証プロセスを通して、セキュリティ機能と保証手段がセキュリティ要件を満たしているかどうかを明らかにできる
- STおよびこれにもとづく保証がCC/CEMを満たし、要件に対して顕在化する脆弱性が存在しないことが本評価および認証プロセスで確認された場合、対象製品のCC 認証を取得でき、CC認証製品であることが求められる調達に参加できる
- STおよび評価結果は、製品の購入を検討する利用者が、その製品が利用者の使用用途に対して十分なセキュリティ機能性を具備しているか、仕様に当たって残存するセキュリティリスクを許容できるかを決定するために役立つ
- 留意点
- CC/CEMは随時更新されるため、評価を受ける場合に有効なバージョンを確認する必要がある
- T: ISMS(Information_Security_Management_System)
- その組織が自身の情報セキュリティを確保し維持するために、継続的に運用する枠組みのこと
- 範囲: 組織全体にわたってセキュリティ管理体制を構築し、監査することと、リスクマネジメントを実施すること
- JIPDECが日本国内におけるISMSの適合性評価制度の確立と普及推進を実施している
- 目的
- 企業や組織が、セキュリティポリシーにもどついたセキュリティレベルの設定やリスクアセスメントの実施などを継続的に運用することで、自身の情報セキュリティを確保し維持する
- 方法
- 参考規格が記載されている
- 効果
- ISMSを構築し運用することで、その組織は一定のセキュリティ管理レベルを維持できる
- 認証を受けた場合、取引先などに対し、情報セキュリティについて一定レベルの管理ができていることを示せる
- 留意点
- メリットとデメリットの整理が必要
- quality_management_systemと改善アプローチ
- KA: lifecycle_process_management
- ソフトウェアやシステムの構想から廃棄までの活動に対するマネジメント
- 主たる目的: ライフサイクルモデルを使うことで、発注者、ベンダー、サブコントラクターなど、すべての関係者が共通の言語を使え正確に意思の疎通を図れるようにすること
- プロセスをアセスメントして改善する国際標準ISO/IEC 33002におけるプロセス参照モデルとして活用することなども想定
- 安全性を重視するソフトウェアの品質の確保には、ソフトウェア自体の機能的要因だけでなく、その開発過程に係る要因を考慮する必要があるとの認識から、safety_critical_lifecycle_modelが提案されるようになった
- ライフサイクルモデルにおけるプロセスモデルとは、ライフサイクルモデルが定義する活動のうち、開発部分をモデル化したもの
- プロセスモデルは、さまざまな開発方法論で定義する開発作業をプロセスとして構成し、開発工程と手順を抽象化してモデル化している
- 開発の内容や特性に応じてモデルの選定が必要
- S-KA: ライフサイクルモデル
- ソフトウェアおよびシステムの構想から廃棄までの活動を、特定の開発方法論およびベンダに依存しない「共通の言語」として制定したもの
- 多様なニーズに対して製品やサービスの統合が困難になったという問題の克服が必要になったため生まれた
- 方法
- ソフトウェアおよびシステムの企画、要求定義から廃棄、処分までのライフサイクルにわたるプロセスを包括的に規定
- 使用者は目的に応じて、組織、プロジェクト、業務に合わせて部分集合を選択したりテーラリングしたりする
- 効果
- 当事者間で開発手順、工程、作業内容、用語などが異なることから生じうるコストや品質面の混乱の防止
- 留意点
- 深い解釈や実際の行動面まで整合させると〇
- S-KA: プロセスモデル
- KA: ソフトウェアプロセス評価と改善
- ソフトウェアプロセスをプロセスアセスメントモデルに照らして評価し、それを継続的に改善する活動のこと
- 求める結果を獲得するためにソフトウェアプロセスを意図的に変更・改善する
- プロセスを系統的、継続的に改善するためには、プロセスに関する定量的なメトリクスを定義したうえで収集、分析し、評価することが必要
- 改善の対象は、ソフトウェア開発の技術やツールなどを含めた一連の工程、プロセス
- 包括的なプロセスモデルとしては、CMMI(Capability_Maturity_Model_Integration)など
- ISO/IEC 33000シリーズなど特定の産業や分野によらない汎用的なモデルがある一方で、Automotive SPICEやTMMiなど特定の業界及び分野に特化したプロセスモデルも提案されている
- プロセスモデル適合の目的化やトップダウン偏重による形骸化の回避のため、問題解決型アプローチも提案されている
- 特徴を十分に理解したうえでのプロセスモデルの活用、そしてそのプロセスがエンジニアのスキルやモチベーションにどのような影響があるかといった人的配慮を含めた本質的なプロセス改善のあり方について、引き続き検討が必要
- S-KA: software_process_evaluation_model
- ソフトウェアプロセスの改善を目的として作成されたプロセスモデル
- T: CMMI
- 顧客やエンドユーザのニーズを満たすための高品質な製品とサービスを開発する活動に対して、包括的で統合された一連の指針を提供するモデル
- 「システムや成果物の品質は、それを開発し保守するために用いられるプロセスの品質によって大きく影響される」というプロセス管理の前提にもとづいて開発された
- → 事業者が主要な事業プロセスの実績を改善することを可能にする、統合されたベストプラクティスの集合
- 単なるプロセス改善モデルから、ビジネス上のパフォーマンスを向上するためのモデルという位置づけに変わってきている
- 組織におけるプロセス改善に焦点
- 場当たり的で未成熟なプロセスから、改善された品質と有効性を伴った秩序ある成熟したプロセスへの深化の改善経路を、プラクティス領域により示す
- 成熟度レベル
- プロセス領域の集合に1つ1つ順番に取り組むことにより、関連するプロセスの集合を組織が改善するアプローチ
- 能力度レベル
- 組織が選択したプロセスを1つ1つ改善するアプローチ
- 今後、セーフティやセキュリティ管理、人材管理のプラクティスが追加される予定
- Method_Definition_Document(MDD)
- ベンチマーク、持続型、対応計画再評定、評価型
- 目的
- 製品の開発と保守、サービス提供、調達に関するプロセスの成熟度レベルおよび能力度レベルを、内部プロセス改善および外部向け成熟度および能力判定のために示す
- 方法
- MDDに定義された評定方法により、CMMIの選択した関連要素群と表現に照らして評定する
- 効果
- 客観的証拠に基づいた評定結果を提供できる
- 留意点
- 成熟度レベルや能力レベルの達成が、手段から目的に転化し、実際のプロセス改善に結びつかない場合がある
- → 真の目的を理解した上位管理者のリーダーシップのもと、現場の改善を推進するための資源の確保が〇
- T: プロセスアセスメントに関する規格(ISO/IEC 33000シリーズ)
- 目的
- 製品の開発と保守、サービス提供に関連するプロセスの能力レベルを、次の目的のために評価
- プロセス改善のために自己のプロセスの状態を理解する
- 特定の要求事項に対する自己のプロセスの適切性を判定する
- 契約相手のプロセスの適切性を判定する
- 製品の開発と保守、サービス提供に関連するプロセスの能力レベルを、次の目的のために評価
- 方法
- PRM(Process_Reference_Model)、測定の枠組み、PAM(Process_Assessment_Model)によりアセスメントを行い、プロセスの能力レベルを判定する
- 効果
- 目的に対して客観的証拠に基づいたアセスメント結果を提供できる
- 留意点
- 能力レベルの達成が、手段から目的に転化することがある
- → 真の目的を理解した上位管理者のリーダーシップのもと、現場の改善を推進するための資源の確保、さらに実務層が当事者意識を持ち取り組む環境の構築が〇
- 目的
- T: Automotive SPICE(Software Process Improvement and Capability dEtermination)
- T: TMMi(Testing Maturity Model Integration)
- テストプロセスを段階的に改善していくための技法
- CMMIと親和性が高く、テストプロセス部分を補完するモデル
- このほかに、TPI(Test Process Improvement)もある
- TMap(Test Management approach for structure testing)という構造化されたテストプロセスの方法論をベースにしている
- TPI NEXT
- BDTPI(Business Driven Test Process Improvement)を基本モデルとして利用したもの
- 目的
- 方法
- CMMIと同様に5段階の水準とそのゴールで構成されている
- 各水準は以下で構成されており、アセスメントをサポートするためのTMM-AM(TMM Assessment Model)を持つ
- 成熟度ゴールのセット
- 成熟度ゴールを支援するサブゴール
- アクティビティとタスクとレスポンジビリティ
- 効果
- 留意点
- S-KA: ソフトウェアプロセス改善技法
- 品質の良いソフトウェアを開発するために必要な、さまざまな作業のフレームワーク改善を目的とした技法
- T: Six_Sigma
- アメリカにおける品質革命運動の中心的な経営革新技法
- 標準偏差(σ)の6倍という意味
- 品質特性が正規分布に従っているとき、規格幅が±6σ分あると、特性地の分布の平均が1.5σずれていても、不良率は片側4.5σ外の確率3.4ppmに抑えられる、すなわちミスを無視できるレベルまで下げるための方法論
- DMAIC(Define, Measurement, Analysis, Improvement, Control)を繰り返すことで、6σのミス発生確率を達成する
- 目的
- 企業活動で発生するミスの確率を100万分の3.4以下にすることで、顧客満足度を向上し、よりよく、より早く、よりローコストを実現するとともに、競争優位獲得のための企業文化を構築
- 方法
- MAICまたはDMAICと呼ばれるシックスシグマ達成プロセスを繰り返し、6σのミス発生率を達成する
- 効果
- 全社最適化の発想により、事業目標を論理的にブレークダウンして実行する枠組みを持つ
- T: IDEAL
- T: PSP(Personal Software Process), TSP(Team Software Process)
- T: 企業などで考案された改善技法
- KA: 検査のマネジメント
- 検査活動の主眼は、製品を顧客に提供してよいかどうかの合否判定にある
- 検査部門、または品質保証部門と呼ばれる組織での実施が多い
- 顧客の立場に立ち客観的な視点で検査を行う必要がある
- 開発の途中段階から品質把握に努め、適宜、開発部門に品質向上策を推進させる必要がある
- 品質上の問題を後工程に持ち越さないための工夫が必要
- 検査計画
- 方針、体制、方法、検査環境および日程などの基本的な計画を明確にし、検査計画書を作成する
- ドキュメントの検査や製品の検査内容を盛り込む
- 過去の検査実績を十分把握して計画に反映する
- 関係部署とのレビューを行いステークホルダーに事前に明示
- 計画との照合、フィードバック
- 方針、体制、方法、検査環境および日程などの基本的な計画を明確にし、検査計画書を作成する
- ドキュメントの検査
- レビュー結果が設計書に確実に反映されていることの確認も必要
- ユーザマニュアルは、設計書と矛盾がないか、ユーザが理解しやすく読みやすい文章になっているか検査
- 中間品質監査
- 各開発工程の完了時に、次工程に向けてドキュメントなどの中間成果物や製品の品質が確保されているかの確認のために各工程の品質把握をする
- ドキュメントレビューの結果評価による設計工程完了監査、テストでの摘出障害件数や摘出傾向の妥当性評価によるテスト工程完了監査
- 製品検査
- 検査部門自らが、テスト項目の設計、テストツール、テストプログラム、テストデータなどのテストジョブの作成、テスト環境の構築を行い、製品検査を実施する
- ユーザの視点で、ユーザが製品に仕様する環境と同等の環境において実際に製品を動作させ、検証や妥当性確認を行う
- 開発部門のテスト結果も確認して、最終的な合否を判定
- 出荷後の活動
- 合格と判断して出荷した製品品質に対して責任を持つ
- 問題が生じた場合、同様の問題を起こさないよう、開発プロセスや自らの検査プロセスへフィードバックする
- 製品品質の責任部署として、出荷後問題のとりまとめや対応を行う場合もある
- KA: 監査のマネジメント
- 監査: 管理対象となる活動が、組織によって選択された基準をどの程度遵守しているかを、収集した証拠をもとに、客観的、体系的に評価する活動
- 監査の基準の前提として、その組織ですでに確立している組織規範を用いることもあれば、将来に向けて確立と定着を図る目的で、品質マネジメント規格などをもとに新しく定めた組織規範を用いる場合もある
- 組織方針、品質規格、規準などを明示的に文書化したものを用いるのが一般的だが、多くはその組織がこれまで培ってきた知識、経験をもとにした「あるべき姿」を整理した「組織固有の考え方」を含んでいる
- 目的
- 監査活動による組織プロセスの改善
- 組織内での適切な組織規範の遵守を担保することによる信頼の付与
- プロセス遵守状況の経営者によるレビューの実施
- 一般的な活動サイクル
- 監査計画の立案、監査の実施、監査の記録、監査のモニタリングとレビュー
- T: 購買先プロセス監査
- 購入者が購買先に対して、作業プロセスが適正なものか、標準に対する遵守状況はどの程度かを確認し、必要に応じて作業プロセスの是正および改善勧告を行うこと
- 第二者監査
- T: ソフトウェア開発における監査
- プロセスに焦点を当てて実施するプロセス監査および製品に焦点を当てて実施するプロダクト監査
- KA: 教育および育成のマネジメント
- 人材育成計画の立案と、それに従った教育および育成カリキュラムの整備、各個人の専門性の育成を管理するキャリア管理に分かれ、企業全体として取り組むべきマネジメント
- 人材に必要なスキルおよび知識
- S-KA: スキル標準
- S-KA: 開発現場における教育および育成のマネジメント
- チームビルディングについて
- キャリア開発計画: 目標となる職務を目指したキャリアパスにそって、経験すべき職務や開発すべき能力をまとめた計画
- キャリアは個人の生涯にわたって継続するもので、その人の仕事に対する自己イメージを反映したものであり、個人の人間的成長や自己実現の軌跡でもある
- 職務経歴の中で、経験すべき職務、開発すべき能力を自律的に計画して、職務移動の節目にキャリアを意識しながら職務を選択することが個人に求められる
- 目的
- 仕事に意欲を持って働き、個人およびチームの職務能力を向上する
- 方法
- キャリア開発計画では、目標となる職務を設定して、それを実現するための計画を立案する
- 品質に関する向上意欲を高めるための動機付け
- 具体例
- 高品質な製品およびサービスはコストカットでき利益を生み、顧客の信頼も得られ、経営的に貢献度が高いことを伝える
- 障害を隠蔽せずに報告することを妨げない組織文化を作る
- 品質目標達成の表彰制度などを設ける
- 具体例
- チームビルディングを進めるうえで、たとえば、アジャイル開発で実施されているスプリントの振り返りは成長の機会となり、チーム学習やチーム改善の活動となる
- 効果
- 人的資源のパフォーマンス向上
- 留意点
- 労務管理が必要
- KA: 法的権利および法的責任のマネジメント
プロジェクトレベル(共通)のsoftware_quality_management
- KA: 意思決定のマネジメント
- ビジネス上の判断もできる必要
- KA: 調達のマネジメント
- QCDを満足させるために必要となる既製の製品やサービス、技術者などの人的資源を外部から調達し、そのコスト、品質をマネジメントすること
- 背景: 市場や顧客の要請
- S-KA: 請負契約による外部委託
- 方法
- 委託先のソフトウェア開発プロセスの確認
- 委託先への要求仕様の提示
- 委託先が海外企業である場合
- 方法
- KA: リスクマネジメント
- 定義
- リスクについて、組織を指揮統制するための調整された活動
- 技術、コストまたはスケジュールに関する潜在的危険度を含んだプロジェクトの対象領域の管理
- リスクの定義
- 目的に対する不確かさの影響
- 起こり得る事象、結果、またはこれらの組み合わせについて述べることで、その特徴を記述する
- ある事象(周辺状況の変化も含む)の結果とその発生の起こりやすさとの組み合わせで表現
- 発生が不確実な事象または状態であり、もし発生した場合、1つ以上のプロジェクト目標にプラスまたはマイナスの影響を及ぼすもの
- 危害の発生確率およびその危害の度合の組み合わせ
- 継続的にリスクを識別する技法が必要
- リスクの発生可能性や発生後の影響を考慮して優先度の決定が必要
- ステークホルダーの参画方法やリスクを判断する規準などを予め明らかにする必要
- ↑ 立場によって捉えるべきリスクが異なるため
- S-KA: リスクマネジメントプロセス
- 定義
- 方針、手順および方策を、コミュニケーションおよび協議、状況の確定、ならびにリスクのアセスメント、対応、モニタリング、レビュー、記録作成および報告の活動に体系的に適用すること
- リスクを継続的に識別子、分析し、取り扱い、監視することを目的とする
- リスクマネジメントシステム: リスクマネジメントプロセスそのものを維持する枠組みと、実際のリスク分析を行うリスクマネジメントプロセスの実施に分けられる
- 目的
- プロジェクト成功の可能性を高めるために、リスクの発生確率と影響度を減少させる
- 方法
- アクティビティ
- リスクマネジメントの計画および実行
- プロジェクトリスク台帳の管理
- リスク分析の実施
- リスク監視の実施
- リスク対応の実施
- リスクマネジメントプロセスの評価
- これらのアクティビティを実際に運用するために必要となる計画書やリスク台帳、および運用主体となる組織などからなるリスクマネジメントシステムを整備する
- アクティビティ
- 効果
- 組織の事情に応じた、動的で、繰り返し行われ、変化に対応できるリスクマネジメントができる
- 留意点
- リスクマネジメントは、組織の主要な活動およびプロセスから切離された単独の活動ではなく、適用する組織の既存のプロセスを考慮しながら適用すると〇
- 定義
- S-KA: リスク識別および特定
- 目的
- 対象となるシステムやプロジェクトのリスクをもれなく識別する
- 方法
- データを収集し、当該システムやプロジェクトに関する専門家の意見を考慮しリスクをもれなく識別する
- データ収集方法
- チェックリスト
- ブレーンストーミング
- ブレーンライティング
- 実務家や専門家へのインタビュー
- 根本原因分析
- 前提条件と制約条件の分析
- SWOT分析
- 文書分析
- 特定の分野での技法
- FMEA(Failure Mode and Effects Analysis)法
- FTA(Fault Tree Analysis)法
- HAZOP(Hazard and Operability Studies)法
- AFD(Anticipatory Failure Determination)法
- HHM(Hierarchical Holographic Modeling)法
- 上の技法と併せてリスク区分を用いる
- 効果
- リスクをもれなく識別
- 留意点
- 対象とする分野に合わせた最適な技法を組み合わせるのが〇
- ステークホルダーの多様な知識や経験を持ちより、漏れを極力なくす
- 外部環境の変化に応じてリスクが有効なのか、新たなリスクが識別されないかなど考慮して更新する
- 目的
- S-KA: リスク分析と算定
- S-KA: リスク評価および対応
- リスク評価
- リスク分析の結果をリスク基準と比較
- ステークホルダーが優先順位を決定
- リスク対応
- 軽減、排除、予防、低減
- 目的
- リスク分析の成果に基づき、どのリスクへの対応が必要か、対応の優先順位をどうするかについて意思決定を支援
- 方法
- 代替案分析: 作業を完成する複数の方法を比較し、最適な方法を決める
- 費用便益分析
- 効果
- リスクに対し、優先順位に基づいた対応を行える
- 留意点
- 優先順位が高いリスクについては、すべてに対応
- 著しい困難が伴う、または費用がかかる場合は、すぐに対応しようとせず、定期的に外套のリスクが解消していないか、あるいは新たな対応が行えるようになっているか監視する
- リスク評価
- 定義
- KA: 構成管理
- ライフサイクルを通じてソフトウェア作業成果物(ドキュメントやソースコードなど)、およびそれ以外のシステムを構成する要素(OSやフレームワーク、DB、開発環境、ハードウェアなど)を識別し、その組み合わせの結果と変化を管理し、特定の時点における構成の再現および追跡を可能とすること
- システムやソフトウェアライフサイクルの全般にわたり、構成要素の機能や特性を特定可能にし、それらに対する変更を管理および検証し、その状況を記録する活動
- → 要素間やその変化が追跡可能になる
- 目的に対して正しいソフトウェア成果物の構成が得られるため、取り出しミスや認識の不一致など品質に負の影響を与えかねない損失や手戻りを防止できる
- 活動内容
- 構成要素の識別とベースラインの設定
- 構成を制御するための変更管理
- 構成要素への変更履歴を管理するバージョン管理
- 品目の完全性、一貫性および正確性を保証するための構成評価
- 複数の構成要素間の関係を管理するinterface管理
- 正しい構成要素の組み合わせを配布するためのビルド・リリース管理
- 広義では、変更管理プロセスも構成管理プロセスに含まれる
- 変更管理プロセスとバージョン管理を統一する方式が〇
- ツールを用いて変更管理プロセスとバージョン管理を統一する方式を取り入れることで、ソースコードに触れられないステークホルダーでも、バグやタスクの情報からソフトウェア開発の進捗状況や品質情報を得られるようになる
- 識別粒度の違いも吸収できる
- S-KA: 変更管理
- 構成管理下の構成要素を変更するためのアクティビティ
- 目的
- 提案された変更要求を深く吟味し、確実にシステムへ反映する
- 方法
- 変更管理の一般的な管理手順
- 変更要求を受け取り、評価を実施
- 変更管理委員会が変更を行うことを決定し、リソースを確保し、修正担当者に割り当て
- 修正担当者が変更を実施し、検証する
- 検証が終わり、修正済みの作業成果物をリリース
- 開発の責任者は、上記のような変更管理プロセスを定義し、変更管理ポリシーを定義する
- 開発者全員に周知徹底
- 変更管理委員会は、構成管理委員会またはCCB(Change Control Board)と呼ばれ、提案された変更要求と新しく提案された機能のどれを受け入れるかを決定する人々の集合
- 実際には設計部署の管理者、リーダークラスで構成されることが多い
- CCBは一度決定したベースラインの成果物に対して、変更を受け入れることの便益と影響を精査する
- 便益: 顧客満足度の向上や競争力の優位
- 影響: コスト、リリースの遅れ、品質劣化
- 変更管理の一般的な管理手順
- 効果
- 決められたプロセスを経ることで、変更要求の内容や影響をステークホルダー間で共有でき、提案された変更要求を正しく確実に反映できる
- 留意点
- 影響分析が重要
- 知見のある開発者に影響分析を指示
- 要領
- 変更要求と既存の要求との矛盾
- 変更を行うことのリスク、技術的な懸念、副作用、スキル面の妥当性
- 変更による品質要求への悪影響
- 現在進行中のプロジェクト計画に与える影響、開発環境に与える影響
- 既存資産(設計、ソース、テストケースなど)に与える影響
- 影響分析の結果を参考に、変更依頼の承認/却下の判断
- 影響分析が重要
- S-KA: バージョン管理
- ベースラインからの変更内容を把握可能にする管理
- ライフサイクルにおけるソフトウェア要素の変更履歴を管理し、任意の変更が反映されたバージョンを一意に識別
- 目的
- 特定の時点でのソフトウェアを復元できるように、ソフトウェアのバージョンを適切に管理する
- 方法
- バージョン管理ツールの使用
- 効果
- バージョン管理を適切に行うことで、必要なときに必要なバージョンを復元できる
- 特に、障害や故障時における現象を再現し、原因調査などを行う際に重要
- バージョン管理を適切に行うことで、必要なときに必要なバージョンを復元できる
- 留意点
- 各粒度でバージョン管理が必要
- 構成管理におけるほかのアクティビティと密接な関係
- ブランチの管理が必要な場合もある
- 各粒度でバージョン管理が必要
- ベースラインからの変更内容を把握可能にする管理
- S-KA: 不具合管理
- 目的
- 不具合によって発生する構成要素への変更と併せて、不具合の解決がなされたことを管理
- スムーズな不具合解決を目指す
- 方法
- 一般的な手順
- 不具合が発見された場合、報告された内容に基づき、その現象の再現と原因の調査を実施する
- 現象の再現は、不具合が発見されたソフトウェアのバージョンにて、現象を再現する環境を構築し調査を実施する
- 調査の結果、構成要素への変更が必要と判断された場合は、変更作業を行う
- 変更管理やバージョン管理も併せて実施
- 不具合が発見された場合、報告された内容に基づき、その現象の再現と原因の調査を実施する
- 個々の不具合の作業ステータスの管理が必要
- 発見から対処完了、優先度など
- 一般的な手順
- 効果
- 例えばテスト期間中の不具合解決の促進が可能
- 不具合管理を通じて収集した不具合情報を分析することで、プロセスや製品の改善すべき情報を得られる
- 留意点
- 不具合が多く発生する期間では、情報の収集について工夫が必要
- 例えば構成管理と結びつけた厳格な不具合管理など
- 不具合が多く発生する期間では、情報の収集について工夫が必要
- 目的
- S-KA: トレーサビリティ管理
- 目的
- 主に変更要求が発生した際の影響調査、および変更対象の特定を容易にするため、要求事項と、プログラムやモジュールなどのソフトウェア品目を追跡可能な状態に管理する
- 方法
- 管理する側の視点と管理する情報を考慮することで、いくつかの異なるアプローチ
- 要求のトレーサビリティ管理
- 獲得、分析、仕様化した要求の構造がどのように設計、構築に展開されていくかを管理する
- 成果物のトレーサビリティ管理
- 要求定義、方式設計、詳細設計、構築、テストの各アクティビティにおける成果物がどのようにつながっているかを管理する
- 製品のトレーサビリティ管理
- ソフトウェアの構成要素がソフトウェア製品にどのように組み込まれているかを管理する
- 要求のトレーサビリティ管理
- 管理する側の視点と管理する情報を考慮することで、いくつかの異なるアプローチ
- 効果
- いずれのアプローチも変更要求が発生した際に効力を発揮
- 例えば、変更要求が提案された場合の影響分析において、その変更がどの機能、ソフトウェア品目に影響するのか、テストがどれくらい必要か、などについて容易に調査可能になる
- いずれのアプローチも変更要求が発生した際に効力を発揮
- 留意点
- いずれのアプローチも、ソフトウェア・トレーサビリティをどのように管理するかというテーマに対処するもの
- 開発現場においては、現状の課題に対応したトレーサビリティ管理が求められる
- 目的
- KA: プロジェクトマネジメント
- 品質やコスト、納期などの制約の下で個々のプロジェクトの目標を達成するための計画立案や実行管理を行うこと
- ますます複雑かつ大規模化している情報システムの分野でも、あらゆるシステムの構築にプロジェクトマネジメントが欠かせない
- S-KA: PMBOK(プロジェクトマネジメント知識体系)
- よい実務慣行と一般的に認められているプロジェクトマネジメントの実施方法の集大成
- 10の知識エリア
- プロジェクト統合マネジメント
- プロジェクトスコープマネジメント
- プロジェクトスケジュールマネジメント
- プロジェクトコストマネジメント
- プロジェクト品質マネジメント
- プロジェクト資源マネジメント
- プロジェクトコミュニケーションマネジメント
- プロジェクトリスクマネジメント
- プロジェクト調達マネジメント
- プロジェクトステークホルダーマネジメント
- PDCAサイクルをプロジェクトマネジメントプロセスの基本としている
- 各プロセスはインプット、ツールと技法、アウトプットの3つで構成されている
- 目的
- プロジェクトマネジメントに関する優れた実務慣行などを特定する
- プロジェクトマネジメントの標準用語集とし、遂行上で関係者間の共通の理解の獲得に役立てる
- 方法
- 効果
- 留意点
- 明確なゴールの定義が難しい価値創造型プロジェクトにおいては、明確な計画策定やリスク洗い出しが困難となるため、状況に応じた高度な対応が必要になる
- 理想的なスキルセット
- テクニカル・プロジェクトマネジメント
- リーダーシップ
- 戦略的およびビジネスのマネジメント
- S-KA: プロジェクトマネジメントに関する規格
プロジェクトレベル(個別)のsoftware_quality_management
- KA: 品質計画のマネジメント
- 効果的かつ適切な品質計画のマネジメント
- 以下の事項を実施
- 1.製品およびサービスに関する要求事項の明確化
- 2.プロセス、製品およびサービスの合否判定に関する基準の設定
- 3.製品およびサービスの要求事項への適合を達成するために必要な資源の明確化
- 4.2の基準に従ったプロセスの管理の実施
- 5.次の目的のために必要な程度の、文書化した情報の明確化、維持および保持
- プロセスが計画通りに実施されたという確信を持つ
- 製品およびサービスの要求事項への適合を実証
- 品質計画書: 特定の製品やプロジェクト、契約に適用される品質マネジメントシステムの、プロセスおよび資源を規定する文書
- コスト面から、早い段階でレビューやテストによって設計やソースコードを確認するように計画する
- 要求品質を確保するために工数をかけ、あるいはスキルのある人を入れるなどして必要十分なコストをかける計画にすることも必要
- 競争力のある目標を設定するためには、ベンチマーキングにより世の中の水準や別組織との比較をすることも必要
- T: 品質計画書
- プロセス、製品、プロジェクトまたは契約の要求事項を、製品実現を支援する作業方法および慣行に関連付ける手段
- プロジェクト計画書の一部、レビュー計画書、テスト計画書など複数の計画書で構成されることが多い
- 目的
- 要求される品質の目標を設定し、それを達成するためのプロセスを定めることで、顧客満足の向上を目指す
- 文書化することで、計画を関係者と合意
- 方法
- 効果
- 品質目標を明確にして、その管理対象や達成状況の評価プロセスを定めることで、提供するソフトウェアの品質を保証し、さらにプロセスの改善に結びつけられる
- 文書として明示することで、関係者とプロセスや目標を共有できる
- 留意点
- 用いるレビュー技法やテストツール、基準とするメトリクス、進捗や実行結果の管理プロセスも計画に含めると、品質目標の達成度評価やプロセスの改善を実現しやすくなる
- 品質計画書は組織によって呼称や範囲が様々
- T: 費用便益分析
- T: ベンチマーキング
- 種類
- 自組織内を比較対象とするインターナルベンチマーキング
- 競合組織を比較対象とするコンペティティブベンチマーキング
- 業種に関係なく類似の組織機能を比較対象とするファンクショナルベンチマーキング
- 業種に関係なくビジネスプロセスを比較対象とするプロセスベンチマーキング
- 目的
- ベストプラクティスと自らの業務を比較して、結果を導入することで、自組織の業務を改善・改革
- 方法
- ベンチマーキングを行うプロセスの決定
- 信頼のおける比較対象とその情報源を選択
- 比較対象と自組織のプロセスパフォーマンスを比較し、ギャップを分析して、改善のための検討を行い、指標を決定する
- 設定した指標をもとに目標値を定めて、自組織の改善計画を立案し実行する
- 効果
- ベストプラクティスに基づいて自組織の目標を設定することで、業務改善・改革につながる
- プロセスパフォーマンスが向上することで、収益などの経営指標の改善が期待できる
- 留意点
- 単なる比較分析はベンチマーキングではない
- ベストプラクティスと自組織の実施方法とのギャップを分析し、プロセスを見直し、その効果を確認して改善や革新に結びつけるまでがベンチマーキング(行動を伴う必要)
- 種類
- KA: 要求分析のマネジメント
- 要求分析の計画
- 要求抽出
- 要求分析
- 異なるステークホルダーから抽出された要求間の競合を解決し、システムの境界、システムとハードウェアや人などとのinterfaceを定め、システム要求からソフトウェア要求へと詳細化すること
- 要求間の優先順位を明確化し、ユーザと合意する
- 優先順位付け
- 企業目標やビジネス戦略に合わせたKPIやBSCを用いることもある
- 予算や期間の制約によっては実現しないと決める要求もあり、要求のマネジメントを始める時期でもある
- 要求仕様化
- 要求の妥当性確認と評価
- 妥当性確認
- 仕様書として文書化された要求が、もともとの要求の発生源としてのステークホルダーなどが真に求めるシステムを定義していることを確認すること
- レビューやプロトタイピング、受入テストの検討などを通じて行われ、要求文書の誤りや間違った仮定などを見出す
- 評価
- 要求の明確さとリスクの抽出状況、要求間の整合性、記述の一貫性、明瞭性などを確認すること
- レビューをなどを通じて実施(妥当性確認と同じく)
- 要求分析の初期段階でテスト計画とテストケースを作成し、妥当性を確認することが有効
- ↑ テストは遅い段階のアクティビティになりがちなため
- 妥当性確認
- 要求分析の計画
- KA: 設計のマネジメント
- 設計: 指定された要求を満足するために、アーキテクチャ、システム要素、interface、データを定義するプロセス
- ソフトウェア設計のアクティビティを規定した計画を定め、要求されている品質特性と顧客ニーズを満たす設計結果を得るための設計方針を決定し、設計結果が要求仕様および品質を満足しているか評価すること
- 設計の計画
- 設計方針の決定
- 設計上の技法や方法の選択を根本的に左右する基本戦略を、関係者全員が共有できるように定めておくこと
- ソフトウェア構造に一貫性を持たせる一般的な設計方針
- 分割と統治、段階的詳細化など
- 設計技法の選択における考慮点
- ソフトウェア特性(リアルタイム性やuiなど)
- 品質特性
- プロジェクト目標、品質目標との整合
- 設計方針との整合
- 設計技法の完成度、普及度
- 開発環境の整備状況
- 要員の確保と要員教育の教材の充実度
- 技法
- 構造化設計、オブジェクト指向設計、データ構造中心設計、コンポーネントベース設計、サービス指向設計
- 設計の評価
- 設計成果物のレビュー、テストを実施し、設計結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
- 評価方法は、選択した設計技法や設計成果物の記法により決定
- 評価基準の考慮点
- 要求事項への追跡可能性
- 外部一貫性
- 内部一貫性
- 利用した設計方法や作業標準の適切さ
- 実現可能性
- 品質目標の達成度合いは、策定した品質評価計画により評価
- KA: 実装のマネジメント
- 実装の計画
- 実装方針の決定
- 実装方針の決定とは、実装に際して、品質要求を含む各種の要求を満たすために必要な実装ルールを設定すること
- 考慮項目
- 採用する言語と再利用部品の利用
- コーディング規約とガイド
- 各条件から、プロジェクトに最適な規約とガイドを設定
- 標準の利用
- 外部標準(OMG(Object Management Group)やISOのような国際組織が規定)のソフトウェアおよびハードウェアのinterface仕様、実装言語、実装ツール、interfaceなどの利用を検討する
- 併せて内部標準(企業単位、部門単位、プロジェクト単位などの標準)の利用を検討
- 標準により、プロジェクト運営の負荷軽減
- 検証の組込などへの効果も期待できる
- 実装の評価
- 実装成果物のレビュー、テストを実施し、実装結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
- 基準
- システム要求事項とシステム設計への追跡可能性
- システム要求事項との外部一貫性
- 内部一貫性
- テスト可能性
- ソフトウェア設計の実現可能性
- 運用と保守の実現可能性
- ウォークスルーによるコードレビューが代表的
- 要求仕様が正しくコーディングされていることを評価
- 規約の遵守性も評価
- テストでは、ホワイトボックステストによるモジュールテストが代表的で、命令や分岐が正しく動作することを評価する
- 命令や分岐の網羅性が評価基準
- モジュールを統合してテストするときは、仕様に基づくテスト(ブラックボックステストなど)により、統合したモジュールが要求仕様どおり動作することを評価する
- KA: レビューのマネジメント
- レビュー: ソフトウェア開発工程全般における評価と確認作業
- 関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性などを評価し確認する
- デザインレビュー: 設計審査。品質保証のための合否判定の1手段
- レビュー計画
- 開催時期、対象成果物、レビューア、観点、適用する方法とリーディング技法、完了判断基準などのレビュー計画を、プロジェクト計画策定時に明確にする
- 対象はソフトウェアに関する直接的な成果物だけでなく、設計方針やテスト戦略などの成果物も含める
- 方法は、最も形式的で公式なインスペクションから、その逆のアドホックレビューまでさまざま
- 形式的なら、側面や観点に基づいた障害検出の属人性が低減されて管理しやすくなるが、手間やリソースがかかるので、目的に応じて選択する
- レビュー実施
- 対象成果物が、当該プロセスのインプットの要求事項を満たすことを確認する
- 前のプロセ腕示された要求を網羅した記述内容であることを確認
- 曖昧性がないこと、内容や構造に矛盾、誤り、漏れがないことも確認
- 人や組織ではなく成果物をレビューすることや、問題を指摘事項として挙げるものの解決はしなくてもよい場合があることなどを、ガイドラインとして作成しておく
- 対象成果物が、当該プロセスのインプットの要求事項を満たすことを確認する
- レビューの記録
- レビュー報告書の発行
- → 品質記録としての意味
- 品質保証活動の一環としてのレビューが確実に実施されたことの証拠となる
- この記録をもとに追跡して完結したことをフォローする
- 記録は、内容と手順をプロジェクト計画策定時に立案し、プロジェクトメンバに徹底しておく
- レビュー実施状況のマネジメント
- プロジェクト実行段階において、レビューが計画通りに行われていることを追跡し、指摘結果の反映確認を確実に行う
- レビュー: ソフトウェア開発工程全般における評価と確認作業
- KA: テストのマネジメント
- 対象のプロダクトやサービスが、プロジェクトで定義した品質を達成するために実施される、テストの活動のマネジメント
- テストの実行で、テスト対象がプロジェクトで定義した品質レベルに達しているかを確認する
- テストの対象に残存する欠陥がテストとデバッグにより除去されることで、テスト対象が持つ品質リスクを下げる
- テストは、設計とは違う視点から設計を洗練させ、開発プロセス全体の品質向上にも貢献
- 適切なテストは、十分な品質レベルにあり、残存リスクも許容レベルにあると判断された製品やサービスを市場にリリースするうえで必要であり、そのテストが適切に行われることについてのマネジメントも必要となる
- テストは欠陥があることは示せるが、欠陥がないことは示せないという限界がある
- テストの十分制覇、網羅性やテストの実施量、欠陥の傾向やそれらの管理グラフなどから総合的に判断する
- 品質レベルについても、上記のようなテストに関するメトリクスや残存するプロダクトリスクなど、テストマネジメントの実施の上で得られるすべてのデータを利用して総合的に判断する必要がある
- テスト活動に関与する組織の在り方も、テストマネジメントの成否を左右する
- 一般的に、開発組織から独立したテスト組織によってテストを実施するとテストの効果は向上するが、開発スピードを損なうことがある
- → 独立の度合いは、技術、管理、財務の観点から検討してテスト組織の位置づけを決める必要がある
- 独立強
- 技術面では、異なる視点でのテストができるため、効果up
- 管理面では、テスト組織に出荷権限を与えることで厳格な品質保証活動が可能になる
- 財務面では、テスト組織でのリソースの融通がしやすくなる
- 独立強
- テスト組織のメンバは、各テストレベルにおけるテストタイプを考慮し、性能や使用性などのテストのスペシャリストを含めて構成が〇
- 一般的にアジャイル開発では、開発担当やテスト担当が1つのチームで一体となって開発することが多く、単独のテスト組織は存在しない場合がある
- テストに関する標準や規格への適合が重要になってきている
- プロジェクトマネジメントの1要素でもあるので、ステークホルダーとの調整が不可欠
- 用語の統一も重要
- → ISTQBが発行しているGlossaryが使える
- S-KA: テストプロセス
- テストアクティビティを具体化するときは、ソフトウェア開発ライフサイクルの諸活動やさまざまなステークホルダーの存在を識別したうえで、ソフトウェア開発のプロセスと連携したテストプロセスの形成が必要
- 目的
- ソフトウェア開発のプロセスと連携した、効果的なテストプロセスを形成する
- 方法
- 効果
- ソフトウェア開発プロセスと対応付けたテストプロセスを策定することで、各テスト工程の設計の元になる情報やテスト対象範囲を明らかにできる
- W字モデルの導入により、上流工程からの品質の作りこみ、開発とテスト準備作業の並行性向上(ひいては短納期開発)、テストエンジニアの知見の活用、テストしやすいソフトウェア開発の促進が期待できる
- 留意点
- 開発プロジェクトが採用するプロセスモデルによってテストレベルの数が決まる(固定的ではない)
- W字モデルにおいて、テストの計画や設計の作業を通じて、上流工程で要求や設計の問題点を検出してフィードバックするには、相応の技術力が必要
- 経験の浅いテスターが上流工程で単にテストケースを作成するだけではW字モデルの効果は得られない
- S-KA: テストの構造
- 目的
- テストの構造を明確にすることで、テストのマネジメントを容易にする
- 方法
- テストレベル
- テストタイプ
- 機能品質特性の評価
- 非機能品質特性の評価
- 信頼性、パフォーマンス、セキュリティ、互換性、ユーザビリティ
- 構造やアーキテクチャの評価
- 構造テスト、ホワイトボックステストなど
- 変更の影響の評価
- 修正確認テスト、リグレッションテストなど
- 効果
- テストの構造を決めることで、対象や範囲を整理して、目的に沿ったテストを設計でき、段階的、体系的にテストを進められる
- 留意点
- テストレベルの種類や数は、プロジェクトが採用するプロセスモデルや開発スケジュールなど、そのプロジェクトの特徴に応じて設定する
- テストタイプは具体的なテストケースを示すものではないので、テストタイプの主旨に沿ってテストの詳細の設計が必要
- 目的
- S-KA: テストの計画と遂行
- 目的
- プロジェクトにおけるテストの目的やプロセス、ゴールとそれに至る手段、リスク、テスト環境を明確にして実現可能な実施計画を作成し、テストを遂行する
- 方法
- 開発プロジェクト発足後、プロジェクト計画策定とほぼ同時期に、開発ライフサイクル全体を包括するものとしてテスト計画を策定する
- 策定時は、プロジェクト計画で策定された目的、戦略と戦術、スケジュールや耐性、環境、リスクとその対策などを勘案し、最終的に全体計画となるマスターテスト計画書、テストレベルに応じた個別のテスト計画書などに記述する
- 検討事項
- テスト全般の内容と工数の見積もり
- 範囲、内容、方法、体制、要員、スケジュールの定義
- 工数見積もりは、過去や類似のプロジェクトの実績値を参考にする方法や、作業の実行者やエキスパートによる見積もりをベースにする方法がある
- テストにかかわるリスク
- 識別し、予防策、回避策、発生時の対策を決定
- 適切なテスト技法やテスト対象、優先順位を決定して実施することでプロダクトのリスクに対処
- リスクベースドテストでリスクの発生を最小限に抑える
- リソースについてのリスク分析、マネジメントも実施
- テスト環境
- テストレベルに応じた機器やソフトウェアの選定と調達
- 限界値/異常値テストが実施可能なテスト環境
- 場所や電源など物理的リソースの確保
- テスト全般の内容と工数の見積もり
- テストの遂行では、計画通りに進捗しているか品質なども含めて計画にフィードバック
- 状況や結果に関する情報
- テストの消化状況
- 障害情報
- 要求、仕様やコードに対する確認の網羅性
- 状況や結果に関する情報
- 効果
- 実施すべき作業とスケジュール、ゴールが明確になることでテストを円滑に実施、管理できる
- テストプロセスの進行状況の把握やテスト終了の判断、品質問題の早期発見ができる
- 留意点
- フィードバック要
- リスクの定期的再評価
- 必要な情報のみ収集、容易な収集方法
- 目的
- S-KA: テストに関する標準
- 目的
- 組織、テスト対象、テスト実施形態にかかわらず適用できる規格を用いてテストに関する作業を標準化する
- 方法
- 効果
- 公的・実質的な規格により作業が一定水準で標準化できる
- 技術者はグローバルな統一基準にもとづいて段階的にテスト技術を習得でき、開発組織は体系的に技術者を育成できる
- 留意点
- 規格の適用にあたっては、開発方法、プロセス、プロジェクトの特性に合わせてテーラリング
- プロジェクトが準拠する規格によりテストへの要求事項は変わる
- ISTQBで実施されている試験でも、JSTQBでは実施されていないものがある
- 目的
- KA: 品質分析と評価のマネジメント
- 実行過程、実行結果や成果物に関するデータを収集、分析し評価すること
- 留意点
- プロダクト品質とプロセス品質の両面から評価
- 障害件数のみでなく品質特性やプロセスの特性にも着目し、さまざまな観点で評価
- データの分析と評価結果の使用方法を明確にする
- 具体的なアクションやフィードバック、改善に結びつくデータ収集や分析、評価となるようにする
- 対象範囲を明確にし、偏りや抜けのないデータとする
- 分析と評価はCh03の技法を使う
- 定量的に行い客観性を保持
- 技法や評価観点を使うときは、自環境を考慮してカスタマイズ
- 技法や観点の背景の理解が必要
- S-KA: プロダクト品質とプロセス品質の分析と評価
- 目的
- プロダクト品質の分析と評価 → ユーザの視点でさまざまな側面から評価する
- プロセス品質の分析と評価 → 開発プロセスの妥当性と一貫性の確認
- 目的
- KA: リリース可否判定
- リリース: プロセスを次の段階またはプロセスに進めることを認めることを意味する
- 目的
- 実施時期に応じた目的
- 方法
- 判定責任者を設けて権限を明確にしておく
- ステークホルダーやその他の関係者を含めた版tネイの体制も明確にする
- KA: 運用および保守のマネジメント
- S-KA: ITIL
- S-KA: SLAとSLM
- 目的
- 方法
- 効果
- 留意点
- S-KA: サービスマネジメントに関する規格
- SMS(Service Management System)
- ITサービスの提供者に対する要求事項の規定
- S-KA: 保守に関する規格
- 保守プロセスの実行計画立案、実行とコントロール、レビューと評価、終了に対するガイド
- 分類
- 是正保守、予防保守、適応保守、完全化保守
(以下は、業務などで課題を見つけたときに通読するようにし、今は構成・概観だけ確認する。)
Ch03 ソフトウェア品質技術
- 品質の作りこみや確認のための技術について
工程に共通なソフトウェア品質技術
- KA: メトリクス
- S-KA: 測定理論
- T: 測定に関する用語
- T: 測定プロセス
- T: GQM(Foal-Question-Metric)
- S-KA: プロダクトメトリクス
- T: 製品品質メトリクス
- T: 利用時の品質メトリクス
- T: 複雑殿メトリクス
- T: LOC(Lines of Code)
- T: ファンクションポイント
- S-KA: プロセスメトリクス
- S-KA: 測定理論
- KA: モデル化の技法
- KA: 形式手法
- 数理論理学に基づいて、仕様記述や検証を行うアプローチの総称
- S-KA: 形式仕様記述の技法
- S-KA: 形式検証の技法
工程に個別なソフトウェア品質技術
- KA: 要求分析の技法
- S-KA: 要求抽出
- T: ステークホルダー識別
- T: 要求開発
- S-KA: 要求分析
- T: 機能要求分析
- T: 非機能要求分析
- T: 品質機能展開
- T: 要求可変性分析
- S-KA: 要求仕様化
- T: ソフトウェア要求仕様
- T: USDM
- S-KA: 要求の妥当性確認と評価
- S-KA: 要求抽出
- KA: 設計の技法
- S-KA: 方式設計の技法
- ソフトウェアアーキテクチャ設計の技法と同義
- T: 部品化の技法
- T: アーキテクチャパターン
- T: 品質に基づくアーキテクチャ設計と評価技法
- T: DSM(依存構造マトリクス, Dependency/Design Structure Matrix)
- T: フレームワーク
- S-KA: 詳細設計の技法
- T: TDD
- T: デザインパターン
- T: 設計原則
- S-KA: 方式設計の技法
- KA: 実装の技法
- T: コーディング規約とガイド
- T: リファクタリング
- T: 契約による設計
- KA: レビューの技法
- S-KA: レビュー方法
- S-KA: 仕様やコードに基づいた技法
- S-KA: フォールトに基づいた技法
- S-KA: リーディング技法
- KA: テストの技法
- S-KA: テスト設計技法
- T: 仕様に基づいた技法
- T: コードに基づいた技法
- T: 経験と直感に基づいた技法
- T: フォールトに基づいた技法
- T: リスクに基づいた技法
- T: 利用に基づいた技法
- T: 組み合わせの技法
- T: コード解析技法
- S-KA: テスト自動化技法
- S-KA: テスト設計技法
- KA: 品質分析と評価の技法
- KA: 運用と保守の技法
- S-KA: 運用の技法
- T: ソフトウェア若化(software rejuvenation)
- 経年劣化の未然防止
- T: ソフトウェア若化(software rejuvenation)
- S-KA: 保守の種類と技法
- T: 保守の種類
- 是正、予防、適応、完全化
- T: 保守の技法
- 理解と解析、拡張と変更
- T: 保守の種類
- S-KA: 運用の技法
Ch04 専門的なソフトウェア品質の概念と技術
- KA: ユーザビリティ
- KA: セーフティ
- S-KA: セーフティの品質の概念
- 本質安全
- ハザードを取り除く性質
- 機能安全
- ハザードにより危害に至らない性質や危害を回避できる性質
- リスク評価
- セーフティを最優先する組織文化
- 本質安全
- S-KA: セーフティの技法
- T: セーフティ実現のためのリスク低減技法
- T: セーフティ・クリティカルシステムのテスト
- S-KA: セーフティ・クリティカル・ライフサイクルモデル
- 安全性解析
- 開発
- 安全妥当性確認
- T: 電気・電子・プログラマブル電子安全間連携の機能安全
- T: 自動車-機能安全
- T: 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス
- S-KA: セーフティの品質の概念
- KA: セキュリティ
- セーフティとの違いは、「攻撃者」を想定しているかどうか
- S-KA: セキュリティの品質の概念
- 機密性、完全性、可用性
- 真正性、責任追跡性、否認防止、信頼性、インテグリティ
- T: 情報セキュリティの定義
- 近年は、サイバーセキュリティの用語が多用されるようになっている
- S-KA: セキュリティの技法
- T: セキュリティ要求分析
- T: セキュリティ設計
- T: セキュリティパターン
- T: セキュアコーディング
- T: セキュリティテスト
- T: 脆弱性管理
- KA: プライバシー
- S-KA: プライバシーの品質の概念
- S-KA: プライバシーの技法
- T: プライバシー影響評価(PIA: Privacy Impact Assessment)
- T: プライバシー保護技術(Privacy Enhancing Technologies)
Ch05 ソフトウェア品質の応用領域
- KA: AIにおける品質
- KA: IoTシステムにおける品質
- KA: アジャイル開発とDevOpsにおける品質
- S-KA: アジャイル開発とDevOpsに置ける品質の概念
- T: アジャイル開発の品質
- 設計と同時にテスト
- 自動化
- 変更容易性
- 開発チームの自律性を尊重
- T: DevOpsの品質
- 表5.3.1: DevOpsにおける品質特性と意味
- T: アジャイル開発の品質
- S-KA: アジャイル開発とDevOpsの品質マネジメント
- S-KA: アジャイル開発とDevOpsの品質技術
- S-KA: アジャイル開発とDevOpsに置ける品質の概念
- KA: クラウドサービスにおける品質
- クラウドサービスプロバイダ、クラウドサービスカスタマー
- クラウドサービスカスタマーは、サービスプロバイダとエンドユーザを含む
- S-KA: クラウドサービスにおける品質の概念
- S-KA: クラウドサービスの品質マネジメント
- T: クラウドサービスのリスクマネジメント
- S-KA: クラウドサービスの品質技術
- クラウドネイティブ: クラウド上での利用を前提として設計されたシステムやサービス
- マイクロサービスを利用したシステムは複雑になりがち
- → 本番環境で実験するカオスエンジニアリングで、従来の手法で発見困難な障害を検出する
- T: 仮想化
- 計算機、ストレージ、ネットワーク
- 仮想化の利点を考慮した設計のソフトウェアでないと効果は限定的
- T: マイクロサービス
- 協調して動作する小規模で自律的なサービス
- 目的
- スケーラビリティを確保した迅速な機能追加や修正の能力などを持ったサービスを提供
- 方法
- 留意点
- 小さく複雑でなく改修頻度が低いシステムは、マイクロサービスに分割するデメリットの方が大きい
- Kubernetesなどの使用
- T: クラウドデザインパターン
- クラウドサービスプロバイダ、クラウドサービスカスタマー
- KA: OSS利活用における品質
『サイバーセキュリティプログラミング』学習メモ
Ch01 Python環境のセットアップ
- pipのインストール
- これを参照
- aptだとpython3の方のpip3しか入れられなかった
- github3.py
- Wing IDE
- ダウンロードしてdpkg -i (ファイル名)
- Stack Data
- Debug Probe
- personalにはない?
Ch02 通信programの作成: 基礎
- ネットワークを介して攻撃を行うためのツールが,target companyにはない
- Pythonによる通信programについて
- TCP_client
- UDP_client
- TCP_clientとほとんど変わらない
- socket type がSOCK_DGRAM
- sendtoのみ(connect()は不要)
- TCP_clientとほとんど変わらない
- TCP_server
- 簡単なコードだが,Netcatの自作やTCP proxyの作成を行う以降の節で拡張していくことになる,便利なコード
- Netcatの置き換え
- Netcatは攻撃者にとって非常に便利なツール
- Web applcationに対する攻撃で侵入したときは,侵入に成功した後の接続経路を確保したいと考える
- subprocess library
- process generateで役立つinterface
- processを立ち上げたり子processとやりとりしたりするのに利用される
- このコードでは,渡したコマンドをそのままローカルのOSに渡して実行させている
- 実行結果はサーバに接続してきているクライアントに送信する
- 例外処理では,一般的なエラーを補足し,コマンド実行が失敗したことを伝えるメッセージをクライアントに送るようにしている
- ファイルのアップロード,コマンド実行,コマンドシェルの実行を行う処理を実装
- 試してみる
- TCP_proxyの構築
- toolboxにTCP_proxyを入れておくべき理由
- あるホストから別のホストにデータを転送したり,ネットワークを利用するソフトウェアの検査をしたりといった作業に必要になる
- 詳細がわからないプロトコルを解き明かしたり,applcationに送る通信データを改変したり,ファジングテストのためのデータを作ったりといった,様々な場面で使える簡単なPythonのproxy script
- proxy_handler()
- response_handler()の中で,パケットの書き換え,ファジングテストの実施,認証における問題のテストなど,リモートから受信したパケットに対してやりたいことをなんでも実施できる
- request_handler()も同様
- 認証情報が平文でやりとりされるapplcationの通信で,一般ユーザの情報の代わりに管理者の情報を送ることで権限昇格を試みるときなどに便利
- response_handler()の中で,パケットの書き換え,ファジングテストの実施,認証における問題のテストなど,リモートから受信したパケットに対してやりたいことをなんでも実施できる
- hexdump()
- 試してみる
- 内容と返還後の文字列が表示される
- toolboxにTCP_proxyを入れておくべき理由
- Paramikoを用いたSSH通信programの作成
- SSH_tunneling
- 目的: SSH clientで入力されたコマンドを遠隔地のSSH server上で動かすこと
- SSH_tunnelingを使う場合,送信データはまとめられてSSHで送信され,SSHサーバ上でその中身が取り出され,サーバの処理に引き渡される
- 状況
- → 手段1: SSH_forward_tunneling
- 多くのWindowsシステムではSSH_serverが動作していないが,そのような状況でも,SSH_tunnelingを逆向きに設定することで解決できる
- → 手段2: SSH_reverse_tunneling
- reverse_forward_tunnel()
- transport()
- 暗号化された接続の作成や設定
- channel
- 暗号化されたセッションを通じてデータの送受信を行うためのソケットのようなもの
- transport()
- reverse_forward_tunnel()
- 試してみる
- Windowsの環境からSSH_serverとの接続を確立し,そのサーバの8080ポートを待機状態にする
- 8080ポートへの通信はWebサーバの80番ポートに転送される
- → Linuxでブラウザからhttp://127.0.0.1:8080にアクセスすると,SSH_tunnelを通じてWeb_serverに接続することになる
- Windowsの環境からSSH_serverとの接続を確立し,そのサーバの8080ポートを待機状態にする
- SSHとSSH_tunnelingを理解し,利用するのは重要
- 使いどきや使い方の把握
- Paramikoを使えば既存のPythonツールにSSHの機能を追加できる
- まとめ
- とても単純だが非常に役立つツールの作成
- 目標: penetration_testを行うときや攻撃が成功した後の活動を行うとき,バグ探しのときなどに使うツールを作成するのに十分な,Pythonのネットワークプログラミング技術を身につけること
Ch03 network: raw_socketと盗聴
- network_sniffer: target machineが送受信するパケットの観測を可能にするため,攻撃の前後でよく利用される
- network通信を観測したりでコードしたりするスニッファーを即席で作る方法を知る
- 手軽で成熟したツールに関して深い理解
- Pythonの新しいテクニックの学習
- 低レイヤーのネットワークの動きを理解
- 生のIPヘッダやICMPヘッダのような低レベルのネットワーク情報にアクセスするには,raw socketを使う
- UDPを用いたホスト発見ツールの作成
- WindowsとLinuxにおけるパケット盗聴
- 試してみる
- pingを実行したときのrequestをキャプチャ
- 試してみる
- IP_layerのデコード
- ctypes構造体の定義
- protocolとIPアドレスを読みやすい形式に変換
- 試してみる
- IPヘッダがデコードされる
- ICMPのデコード
- type=3: 宛先到達不可能クラス
- code=3: ポート到達不可能エラーが発生
- 元のデータグラムの先頭8バイトがICMPメッセージに含まれるため,照合できる
- netaddr libraryを使うコードを追加し,ホスト発見用のスキャンをサブネット全体に対して実施できるようにする
- netaddr module
- subnet maskを入力として受付,適切に処理
- subnet, addressをとても簡単に処理できるようになる
- netaddr module
- 試してみる
- 対象のサブネット内をスキャンできる
Ch04 Scapyによるネットワークの掌握
- e_mailの平文の認証情報の窃取,同一ネットワーク内の通信を傍受するための標的マシンに対するARPポイズニングの体験
- Scapyのpcap処理を拡張してHTTP通信から画像を切り出し,その画像に人が含まれているかを判断するために顔検出を行うデモを実施
- e_mailの認証情報の窃取
- Scapyを使ったARP_cache_poisoning
- pcap fileの処理
- キャプチャーされたネットワーク通信に基づいたファジング用のテストケースの生成や,以前にキャプチャーした通信を再生するような単純な作業に,PythonやScapyを使ってさまざまな観点でpcapを分析する
- HTTP通信からの画像ファイルの切り出し
- pcapの解析
- 画像の判定と出力
- 試してみる
- target画見ている内容の種類の確認や,ソーシャルエンジニアリングを用いた面白いアプローチの八景に役立つ
- Web_crawlingや解析の処理と連携することもできる
Ch05 Web_serverへの攻撃
- Web_applicationの解析は,攻撃者にとってもペネトレーションテストをする者にとっても非常に重要
- 最も攻撃にさらされ,侵入に最もよく使われている
- Pythonを使ったWeb_serverとのやりとりについて,事前調査と総当たり攻撃のツールを作成しつつ見ていく
- 総当たり攻撃や調査ツールの作成,テキスト量の多いサイトでの検索において,HTMLのパースがいかに大事か分かる
- Webのソケットライブラリ: urllib2
- Requestクラスを使って捜査する
- open_sourceのWeb_applicationのインストール
- ディレクトリとファイルの総当たり攻撃
- Web_server上のアクセス可能なファイルを全て知るのは難しい
- 実装
- DirBuster project, SVNDiggerのような一般的な総当たり攻撃用の辞書
- threadを作ってファイルを探索する
- network接続が切断した場合やターゲットのサイトがダウンした場合に備えて,途中から再開できる機能も作っておく
- リクエストを作る際に使う拡張子のリスト
- status_codeが404の場合以外もURLを表示する → File not found以外のstatus_codeが攻撃の助けになる可能性があるため
- 試してみる
- OWASP(Open Web Application Security Project)は,ツールのテスト用にオンラインやオフラインで脆弱なWeb_applicationのリストを公開している
- target Web_serverから興味深い情報を取得
- Web_applicationをターゲットとする場合,総当たり攻撃による情報収集がなにより重要
- HTML_formの認証を総当たり攻撃で破る
- CAPTCHAやトークンの使用など,Webシステムの総当たり攻撃対策は日に日に一般的になってきている
- Joomlaに対する総当たり攻撃
- HTMLParserクラスの使い方の基礎を押さえれば,将来攻撃するであろうWeb_applicationについての情報収集に応用できる
- 最初に,結果の一覧を保存する辞書を作る
- パースして,タグを見つける度にhandle
- 特にinputタグが重要で,見つかった時はメインの処理を行う
- name, value属性が見つかった時はtag_resultsという辞書に保存
- パースが終わったら,総当たり攻撃のクラスでユーザ名とパスワードのフィールドの値を置き換える
- HTMLParserの基礎
- handle_starttag
- handle_endtag
- handle_data
- フォームのパースやリンクの収集,データの解析のためのテキストの取得,ページ内の画像の検索など,さまざまなことができるようになる
- 試してみる
- ターゲットのJoomlaに対してログインできる
Ch06 Burp Proxyの拡張
- Burp Suite: スパイダーやプロキシによる通信の閲覧など,攻撃を支援するツール
- Extensionsを使って,攻撃や詳細な事前調査を行うための便利なツールをBurpに追加する
- セットアップ
- Burpを使ったファジング
- HTTP通信に隠されたバイナリプロトコルや,複雑なJSONリクエストを扱う場合,典型的なWeb_applicationのバグを検査できるということは非常に重要
- ペイロードを自由に操作できるお手製のファジングツールでリクエスト本体をいじりつつ,認証のためのCookieなどの基本的なHTTP通信の確立はBurpに任せられるようにすると便利
- BurpはWeb_applicationの検査を行うためのさまざまなツールを持っている
- まず,BurpのAPIドキュメントを読んで,どのBurpクラスが拡張機能を作成するために必要なのかを探る
- ExtenderタブのAPIsタブをクリックするとドキュメントを表示
- Pythonコードの実装
- IIntruderPayloadGeneratorクラスを追加
- 3つの関数を含む基底クラスを実装
- 単純なSQLインジェクションのテスト,クロスサイトスクリプティングのテスト,オリジナルのペイロードからランダムに塊を取り出してランダムな回数分繰り返したものを追加するテスト,という3つのうち1つをランダムで選び出して実行するシンプルなファジングツールを作成
- 試してみる
- query parameterがハイライトされる
- 警告から,SQLインジェクションの脆弱性が表示される
- Web_applicationのエラーを誘発したり,アプリケーションのパスを開示したり,ほかのスキャナーができないようなさまざまなことができる
- 大事なのは,Intruderによる攻撃で使う拡張機能の操作方法を学ぶこと
- BurpでBingを使う
- Web_siteのコンテンツをパスワード作成に利用する
- セキュリティはしばしばユーザのパスワードに帰結する
- onlineでのパスワード攻撃の肝は,適切な単語リストの入手
- 実装
- BurpのUIにコンテキストメニューを追加する
- 独自の単語リストをセットに保存し,同じ単語を導入しないようにする
- BurpからHTTPのトラフィックを選択し単語リストに追加
- mangle()で,ベースとなる単語を切り出して,一般的なパスワード生成戦略をもとに単語を作成する
- 試してみる
- 単語リストの作成と表示
Ch07 GitHubを通じた指令の送受信
- トロイの木馬の堅牢なフレームワークを作るときに最も困難なことの1つは,設置したトロイの木馬の制御やアップデート,データの受信を非同期的に行うこと
- remoteのトロイの木馬にコードを送信するための普遍的な方法を持つことが重要
- トロイの木馬ごとに異なる作業をさせる
- ターゲットのOSにあったコードを追加
- GitHubを使って,設置したトロイの木馬の設定情報や窃取したデータだけでなく,タスクを実行するために必要なモジュールを保存するようにする
- Pythonがライブラリをインポートする仕組みをハックすれば,設置したトロイの木馬が,新たに作成したモジュールと必要なライブラリをリポジトリから自動的に取得してくるようにできる
- GitHubとの通信はSSLで暗号化されており,GitHubがブロックされていることも非常に少ない
- GitHubのアカウントを設定する
- moduleの作成
- 開発する各モジュールは,複数の引数を渡せるようにしたrun関数で実行されるようにするべき
- → 各モジュールを同じ方法でロードでき,かつ設定ファイルをカスタマイズしてモジュールに引数を渡すようにもできる
- ローカル環境のトロイの木馬で新たなモジュールを有効にすることで,モジュールが正常に動作するか確認
- 開発する各モジュールは,複数の引数を渡せるようにしたrun関数で実行されるようにするべき
- トロイの木馬の設定
- GitHubから指令を受信するトロイの木馬の作成
- Pythonのインポート機能をハックする
- 改善,拡張
- モジュールや設定,取得したデータをすべて暗号化
- updateなどの自動か
Ch08 Windowsでトロイの木馬がよく悪用するテクニック
- ウイルス対策ソフトやエンドユーザ自身によって検出される可能性との戦い
- トロイの木馬を設置した後の標的マシンを注意深くモデル化し,トロイの木馬を本当に標的にマシンに対して送りつける前に,実験環境内でそれらのモジュールをテストする
- 趣味と実益のためのキーロガー
- キーロガー: 最も古い物の1つだが,さまざまな隠蔽方法とともにいまだに使われている
- 認証情報や会話の内容といった機密情報の窃取に非常に効果的
- pyHookによりキー入力のイベントを容易にトラップできる
- イベントに対して別のフックが存在していた場合,コールバック関数は真を返すことで,次のフックにもイベントを処理させることができる
- キーロガー: 最も古い物の1つだが,さまざまな隠蔽方法とともにいまだに使われている
- 試してみる
- どのウィンドウで何を入力したか分かる
- screenshotの撮影
- Python流のシェルコードの実装
- sandbox検知
Ch09 Internet Explorerで楽しもう
- applcationにIEのCOMオブジェクトを埋め込める
- → ネイティブのIEオートメーションオブジェクトを利用して,ある種のMan_in_the_Browserタイプの攻撃を行い,利用者がWebサイトとやり取りする際に認証情報を窃取する
- → 拡張して,複数の標的Webサイトに関しても実現可能にする
- 最後にIEを使用して標的マシンからデータを窃取する
- 窃取データの保護には公開鍵暗号を使用し,我々しか復号できないようにする
- (ある種の)Man_in_the_Browser
- MITMが通信に介在するのに対して,MITBはブラウザそのものに寄生することで認証情報や機密情報を窃取する
- この種のマルウェアのほとんどが(典型的にはBrowser Helper Objectのような形で)ブラウザに寄生するか,あるいはコードをインジェクションすることで,ブラウザのプロセスそのものを操作する
- IE用にネイティブCOM interfaceを使用することで,SNSサイトや電子メールサービス用の認証情報をあらゆるIEのセッションから窃取する
- ロジックの拡張もできる
- 利用者のパスワードの変更,ログイン時のやり取りに介在,キーロガーモジュールを併用して,再認証を強制的に発生させてキー入力を取得するなど
- ロジックの拡張もできる
- 実装
- 目的のサイトの認証情報を窃取するための中心となるループ処理
- すべての動作中のIEオブジェクトを繰り返しチェックすることから始める
- ログアウトさせる
- ログインフォームを改ざん
- 認証情報の送り先WebサーバへのアクセスURLの末尾が標的サイトになっている
- これにより,用意しておいたWebサーバのログなどを通じて,認証情報の窃取に成功した標的サイトが何かを明らかにできる
- wait_for_browser()によって,ページのコンテンツがすべて読み込まれてから,ページを編集したりパースしたりするようにしている
- 目的のサイトの認証情報を窃取するための中心となるループ処理
- サーバの作成
- 窃取した認証情報を集める
- 試してみる
- IEのCOM_automationを使用した情報の盗み出し
Ch10 Windowsにおける権限昇格
- 必須要素のインストール
- process監視ツールの作成
- Windowsにおけるトークンと権限
- 競合状態に勝つ
- code_injection
- 実装
- マーカーを使って,無限ループを回避
- 監視スクリプトのメイン処理にコードインジェクションの呼び出しを追加する
- 試してみる
- SYSTEM権限でリスナーを起動する
- SYSTEM権限を奪取
- 実装
- 特定の環境下においてローカルのアカウントやアプリケーションへの攻撃に使用する,独自ツールにも換えられる
- いったんネットワーク内部に侵入できれば,WMIだけでもローカルネットワークの調査データのよい供給源となり,そのデータをさらなる攻撃に利用できる
- 権限昇格はあらゆるトロイの木馬にとって必要不可欠な要素
Ch11 forensic attackへの転用と自動化
- forensic: 侵入された後に,またはインシデントが起こったかどうか判断するために必要とされるもの
- メモリに含まれる暗号化の鍵谷その他の情報を得るために,汚染されたマシンのRAMのスナップショットが求められる
- VolatilityというPythonで書かれたforensic frameworkがある
- install
- profile
- profilerにより,メモリダンプから情報を引き出すために必要なシグネチャやオフセットをどのように適用するかを決定する
- imageinfoというpluginで,そのときのターゲットに対してどのprofileを使うべきか判断してくれる
- password_hashを手に入れる
- 直接的なコードインジェクション
- Immunity Debugger
- reverse engineering
- Pycommandを使って,exeのすべての関数を見つけて,一度だけ有効なブレークポイントを設置する
- 複数のステップ
- memoryをスキャン
- exeのプロセスを見つけてシェルコードを挿入する場所を決定
- その場所のRAMイメージの物理アドレスを割り出す
- 指定の操作に割り当てられている関数のアドレスにジャンプ命令を挿入し,シェルコードにジャンプさせてそれを実行する
- 実装
- メモリ上の各ページを調べるとき,まずページの物理的なオフセットを見つける
- そしてRAMイメージを開き,そのページが存在する場所のオフセットを調べ,メモリ上のページ全体に読み込む
- シェルコードを同じサイズのNULLバイトの塊を探す
- ここがRAMイメージ内でシェルコードを書き込む場所
- 挿入したら,シェルコードをアドレスを取得しx86のバイナリコードを作成する
- 操作のオフセットを計算し,トランポリンを仕掛ける
- 試してみる
- Immunity Debugger
Appendix A reverse engineering用framework miasm
- miasm
- setup
- x86_64 assemble
- データ領域から実行権限が排除されているため,Ch08よりコードの追加が必要
- assemble_text()でネイティブコードを生成し,execute_native_code()で実行
- miasmによるエミュレーション
- サンプルコードがDockerイメージ内にあり,それをもとに作る
- 柔軟に命令ごとに解釈を変え,処理を追加したり挙動を変更したりできる
- → 特定の機械語命令が呼ばれた回数を数えるprofilerを作成
- メモリアクセスの頻度の計測や,関数呼び出しの深さを調べたりと応用できる
- symbolic実行
- symbolic実行: レジスタやメモリ内容を具体的な値ではなくシンボルとしてエミュレーションする仕組み
- たとえば,ある実行パスに到達するための入力値の条件を自動的に求められるなど
- symbolic実行: レジスタやメモリ内容を具体的な値ではなくシンボルとしてエミュレーションする仕組み
- miasmはリバースエンジニアリングに必要になるさまざまな機能を持っている
Appendix B さまざまなサンドボックス検知
- サンドボックスによるフックの検知,フックの回避,C言語で書かれた仮想マシン検知プログラムをモジュールとして呼び出す方法
- マルウェアを解析するサンドボックスでは,解析対象の挙動を把握するため,マルウェアが呼び出すライブラリ関数をフック氏,呼び出された関数名やその関数に渡された引数を取得する
- 簡易サンドボックスの準備
- ソフトフックの痕跡を見つける
- サンドボックスを回避する
- runtime環境の特徴を見つける
- その他のサンドボックス検知方法
『エンジニアの知的生産術』学習メモ
はじめに
- intellectual_productionとは
- 知識を用いて価値を生み出す
- programmingの学び方
- →↓ x軸 具体: 情報収集,体験
- ↓ y軸 抽象: 抽象化,モデル化,パターンの発見
- ↑← z軸 応用: 実践,検証
- ↑ (y軸は積み上げより掘り下げのイメージ)
- ちゃんと広い穴を開けておかないと奥が見えない的な
- xもzも穴のメタファーで回収してた感じはある(そもそもそんな言語化してたわけではないが)
Ch01 新しいことを学ぶには
- cycleを回す原動力: やる気
- 学びを分類
- 逆風が強い → 強いやる気が必要
- やる気の出るthemeを見つける
- やる気の維持
- goalは近くに明確に
- SMART criteria
- goalは近くに明確に
- MOOCでの学び
- 参考書の探し方
- 大学の講義の参考図書になっている
- 正誤表が充実している
- 改訂されている,ロングセラーである
- 情報収集の3つのポイント
- 知りたいところから
- 遅延評価
- YAGNI
- 知りたいところから学ぶための前提条件
- 目標を明確にする
- 現実とのgapを表現する
- なぜ予想と違うのか
- 目標が達成可能
- 大まかに全体像を把握
- 目標を明確にする
- 大雑把に
- 片っ端から
- 写経
- 数学
- 正確な積み上げが必要な場合
- できるだけ効率化しながら,必要な部分を前から積み上げていく
- 時間を区切る
- 一定時間で評価する
- 写経は補助輪
- 写経しなければ分からないくらいであれば,新しい分野にチャレンジしていることが分かる
- 知りたいところから
- 抽象とは何か
- 集めた情報からpatternを発見したり抽象化したりして,モデルが作られていくprocessを学ぶ
- abstract
- model
- すべてのmodelは間違っている
- modelの価値: 現実との一致度ではなく,modelの操作が現実を操作することに比べてどれくらい低コストになるか
- module
- 物理的なものづくりと違い,局在しない
- 相互作用の制限
- 重要でない部分を隠す=重要な部分を抜き出す
- MVC
- patternの発見
- 具体的な事例を集めて,規則性や共通の特徴.繰り返し現れるものを見つける
- グラフでの表現など
- design_pattern
- もともとは建築の分野から
- patternの命名
- 人間の知能を増強する方法
- 人工物
- 言語
- 世界のmodeling
- 生み出されつつある言語/制度化された言語
- 方法論
- 教育
- 人間の知能を増強する方法
- なぜ抽象化が必要か
- どうやって抽象化するか
- 比較して学ぶ
- 歴史から学ぶ
- 今と昔の比較
- 現在進行中のできごとについて,次に何が起こるか予測
- 変更前と後でどう変わったか,なぜ変わったか
- source_codeにはhowしかない
- pattern本から学ぶ
- 自分の言葉で説明できるか
- 自分の経験に基づいた具体例を挙げられるか
- 自分の目的を達成するためにその知識を使えるか
- 検証
- 作って検証
- programmingはほかの分野より学びのcycleが速くなる
- 解説を作ることも〇
- 試験で検証
- 変化が少ない分野,良い教科書が整備されている分野で〇
- 検証の難しい分野
- 繰り返し実験しやすく,実験結果に影響する環境要因をコントロールしやすい分野が検証しやすい
- 科学,工学など
- 繰り返し実験しやすく,実験結果に影響する環境要因をコントロールしやすい分野が検証しやすい
- 作って検証
- まとめ
- 情報収集・モデル化・検証という学びのサイクルについて
- アインシュタインの図式
- →↓ 直接経験E(dataなど)
- ↓ 公理(直感によって生まれる.パターンの発見.論理的に導かれたものではない)
- ↓ 公理から具体的な主張が論理的に導かれる
- ↑← 経験を通じた検証
- whyは,comment, commit log, mailing listなどに書かれている
Ch02 やる気を出すには
- Getting Things Done(GTD)
- まず気になることをすべて集めるだけ
- ToDoと違って判断しない
- 集めると考えるの複数タスクを一緒にしないようにする
- 処理
- これは何か?行動を起こす必要があるか?を問う
- 必要あり → どういう結果を求めているか?: ゴールの明確化
- 次に取るべき具体的な行動
- 行動を起こす必要のないものを,ゴミ・資料・保留の3つに分類する
- 具体的な行動が複数 → projectにする
- 具体的な行動が2分以内 → 今すぐやる
- 具体的な行動をやるのが自分でない → 他人に任せて連絡待ちリストに入れる
- 具体的な行動をやるのが特定の日時 → カレンダーに書く
- どれにも当てはまらない → 次に取るべき行動のリストに入る
- 上から1度に1件ずつ処理していく
- 完了までに時間がかかるのが難点
- 部屋の片づけと似ている
- まず基地を作る
- 領域を区切る
- 片付いている領域を作る
- 今日やることの整理に集中する
- 緊急性分解理論
- 質,量,納期,方法,代替,お金で解決,どうしようもないならやめる
- まず気になることをすべて集めるだけ
- 優先順位づけはそれ自体が難しいタスク ← 感覚的にわかるところが言語化されている
- sortの計算量
- 1次元でないと大小比較ができない
- 単純に十分な方法論がないうえに,タスクごとの重要度が依存し合っていることもある
- 不確定要素がある場合の大小関係
- 悲観的な勘違い
- → 探索と利用のトレードオフ
- 過去の経験からベストと思う行動ばかり → 探索不足
- 未経験の行動ばかり → 過去の経験が活かせない
- → 不確かなときは楽観的に
- 気づきのチャンスがない分,悲観的な勘違いは影響が大きい
- 不確かであることをポジティブに評価する項を足してから選択肢を比較
- 楽観主義が後悔を最小化する
- UCB: Upper Confidence Bound
- 信頼区間の大きいほうの境界
- 平均で判断するのではなく,ベストで判断する
- ↑ 悲観的な勘違いで損失が確定するより,楽観的な勘違いでfeedbackを獲得しながらベストに近づける方が良いというようなこと
- risk, value, priority
- 重要事項を優先する
- 優先順位を今決めようとしなくてよい
- 順位をつけることが本質的に難しい
- 日々の行動を行う中で,徐々に自分の価値観や人生の目的が明確になると考えました
- 価値観などの軸が明確になると,その軸と照合して,各タスクの重要度が分かるようになる
- これにより優先順位ができるようになる
- 自分がどういうタスクが好きなのか,どうなるとうれしいのかを日々観察していくことで,事後的に優先順位づけができるようになる
- 1つのタスクのやる気を出す
- タスクが大きすぎる
- timebox
- 終了条件が明確でないものは時間で切るのがフィットする
- 集中力の限界
- 逃避を避けるために,時間を区切って,見えるところにゴールを設定するのが有用
- pomodoro technique
- 1 pomodoro: 25 min
- 今日1日分のタスクリストを作る
- タスクの大きさをpomodoroの個数で見積もる
- もし自分または他人による割り込みが発生したらそれを記録する
- 1 pomodoro集中した状態を継続出来たら,立ち上がって数歩歩くなどして視点を切り替える
- 連続的なものとして捉えられがちな時間を,pomodoroの個数としてタスクの大きさを見積もる
- 見積もり能力を鍛える
- 1日にできるのは4~8 pomodoro程度
- 分単位で見積もるタスクシュート時間術
- 計測の重要性
- 不要なタスクにpomodoroを与えない
- column: PDCA_cycle
- 重要なのはcycleを回して徐々に改善していく考え方
- OODAもある
- 計測し,退け,まとめる
- Drucker
- 仕事より計画よりまずは計測
- programを高速化したくなったときは,まずはどこが遅いのかを詳細に計測するべき
- 1 pomodoroの間はタスクの変更をせずに1つのことに集中する
- Drucker
- まとめ
- やる気が出ない状態をどうやって解決するかについて
- 1つに絞る
- タスクを小さくする
- 計測する
Ch03 記憶を鍛えるには
- 記憶の仕組み
- カンデルという人の本より
- 海馬
- 記憶には2種類ある
- 非陳述記憶
- 抽象化
- 記憶と筋肉の共通点
- 繰り返し使うことによって強くなる
- 記憶をinputする銘記のフェーズと,記憶をoutputする想起のフェーズ
- 両方必要
- 繰り返し似た情報が入ってくると反応が鈍くなる性質
- outputに対して報酬が得られるとなおよい
- column: 海馬では時間が10倍に圧縮される
- 具体的な記憶から抽象的な情報を作り出すプロセス
- 遅く読みすぎると理解できなくなるのもこれ
- 記憶をinputする銘記のフェーズと,記憶をoutputする想起のフェーズ
- outputが記憶を鍛える
- testは記憶の手段
- テストをしてからさらに学ぶ
- 自信はないが成績は高い
- 主観的な気持ちと客観的なテスト結果が逆になる
- Adoptive_Boosting
- 弱識別器を集めて,もっと正解率の高い識別器を作る方法
- 間違えた問題を重視することが重要
- 繰り返し学習で弱識別器を集めて集計して答えを出すことで正解できるようになる
- テストの高速サイクル
- 知識を長持ちさせる間隔反復法
- 忘れてから復習する
- テストまでの感覚が1日以上のときには,テストまでの感覚の1/10程度の時期に復習するのが良い
- ただし,ピークの後はそれほど悪くならないので,後であればOK
- テストまでの感覚が1日以上のときには,テストまでの感覚の1/10程度の時期に復習するのが良い
- ライトナーシステム
- 間違えたものは短期,正解したものは長期で復習
- SuperMemo
- 問題のやさしさ
- SuperMemoの学習感覚決定algorithmは,SM-2 algorithmと呼ばれた
- そのなかにやさしさ係数がある
- 知識を構造化する20のルール
- 最小情報原則
- 問題はできるだけシンプルに
- 半端な結果が出ない
- 問題はできるだけシンプルに
- 順序の定まらない集合を覚えようとしない
- 複数のものの並びを覚えようとしない
- 穴埋め問題は覚えやすく効率的
- 最小情報原則
- Anki
- 学習フェーズと復習フェーズ
- 隙間時間で細切れに学習する場合に〇
- 難易度の自動調節
- 適度なチャレンジのときのみ,高い集中力を発揮するフロー状態になる
- そうでないときは,不安か退屈が勝ってしまう
- 間隔反復法では,難しい場合に対処できない
- → 自動保留
- 保留の解除は,干渉を見つけて取り除くようにする
- 適度なチャレンジのときのみ,高い集中力を発揮するフロー状態になる
- column: 知識を構造化する残り15のルール
- 教材は自分で作る
- 作る過程で理解が深まる
- 覚える前にまず理解
- 認知的に高度な作業をした方が記憶にとどまる
- 個人的な情報を利用できる
- 自分の記憶・体験・感情と関連付ける
- 著作権と私的使用のための複製
- 作る過程で理解が深まる
- 忘れてから復習する
- まとめ
- 記憶について
- 海馬が長期記憶にも使われている
- 繰り返しが必要
- 単に繰り返すよりtestが〇
- 主観的な自信はなくなるが,客観的な成果は高くなる
- テストの繰り返し間隔や難易度を自動調整するしくみが実現されてきている
Ch04 効率的に読むには
- 読むとは何か?
- 本を読むことの目的
- 娯楽はスコープ外
- 情報を得ることが目的か?
- 情報伝達の歴史
- 一次元の情報を脳内で組み立てる
- 本の内容だけが組み立てる材料ではない
- 自分の脳内のモデルと合わせて理解を構築する
- 見つけると組み立てるのグラデーション
- 味見するだけでよいか,よく噛んで消化する必要があるか,丸のみするか
- 読むの種類と速度
- 本を読むことの目的
- 自分の普段の読む速度は?
- 1ページ2秒以下の見つける読み方
- 準備の大事さ,段階的詳細化,繰り返し読むこと
- Whole Mind System
- focus reading
- 見出しなどへの注目
- 先行オーガナイザ
- 本文より見出しの方が書く上でコストがかかっている
- title, sub titleは商業上の理由が大きいので,参考にしない
- 図は注目に値する
- cost 大
- 箇条書きも〇
- 脚注とコラムは最初は読まない
- column: 時間軸方向の読み方
- 同じ著者が似たテーマを繰り返し書いているときなど
- 何が一時の思い付きなのか分かる
- 1ページ3分以上の組み立てる読み方
- 哲学書の読み方
- 開いている本
- 著者が自分の意見を言っていない本
- 読者が自分で考える本
- 閉じている本
- 著者が自分の結論を持っており,そこへ向けて論を進める本
- 外部参照が必要な本
- 前提知識
- 登山型の本
- 概念積み上げ
- 手順をおろそかにすると後で困る
- ハイキング型の本
- 色々な概念を次々と
- 山の頂上に到達するのが目的ではなく,景色を楽しむことが主眼
- 開いている本
- 1冊に40時間かけて読む
- 予備調査と選書に3時間
- 通読に4時間
- 詳細読みに10時間
- +方法論自体の習熟コスト
- 棚を見る
- 本を選ぶ方法
- 分野の棚の本を全部見る(気になるものがあれば目次も見る)
- ↑を繰り返す(可能なら複数の書店で)
- 分野の全体像をスケッチしてみる
- 易しい本ではなく,自分の興味のある本を選ぶべき
- motivation維持のため
- 読書ノートに書きながら読む
- 読みたいときに読みたいところから読む
- 全体の分量を1章10ページなどと先に決め,章の小見出しを先に記入していく
- わからないことは何でも記録する
- 何度も出現する単語を記録する
- 概念の間の関係や理由と結論の関係などを矢印でつなぐ
- わからないことを解消するために読む
- わからないの理由
- 用語の理解が不十分
- 論理の筋道の理解が不十分
- 問題意識の理解が不十分
- 図解する必要がある
- わからないの理由
- 数学書の読み方
- 1回のゼミの準備に50時間かかるのは不思議ではない
- 数学所は登山型の本が多い
- ここは絶対大丈夫というのを少しずつでも増やしていく感じ
- 全体像を理解することと,定義を理解することの違い
- 厳密な議論が必要
- わかるの定義
- なぜそうなのかという質問に答えられること
- わかることは必要か
- 哲学書の読み方
- 読むというタスクの設計
- 理解は不確実タスク
- 挑戦の量で測る
- 冊数や時間など
- 挑戦の量で測る
- 読書は手段,目的は別
- 大雑把な地図の入手
- 結合を起こす
- syntopic reading
- 外山滋比古
- 修辞的残像
- 思考の道具を手に入れる
- 経験によって得た名前のついていない概念や考え方に,本を読むことで名前が付くことがある
- 概念の名前が分かれば,概念の検索ができ,関連知識を入手しやすくなる
- 言葉を手に入れて,言葉によって思考ができるようになる
- 復習のための教材を作る
- 読書の目的として,復習のための教材を作ることとするのがおすすめ
- 記憶を定着させるためには間隔を空けて繰り返すことが大事
- 繰り返しのために重要
- leverege_memo(lever: 梃子)を作る
- 書籍の中で重要な部分を抜き出し,濃縮してleverege_memoを作る
- problem
- 文脈から切り離されてしまう
- 量が増える一方である
- incremental reading
- 問題反復法のシステムを流用
- 明示的に捨てる決心をする必要がない
- 必要になったら検索して見つけれられる
- 繰り返し提示されて抜き書きを作っていくことで,価値のあると感じる情報の抜き書きが徐々に増える
- 複数の情報源からの情報が混ざってランダムな順番で提示されることで,知識との結合が促進
- 発展途上
- これ以上編集不要なものの扱い
- 人に教える
- 読書の目的として,復習のための教材を作ることとするのがおすすめ
- 理解は不確実タスク
- まとめ
- 知識が入ってくるプロセスについて
- 特に文章を読むことにフォーカスし,情報を見つけることと,理解を組み立てることのグラデーションを見た
- 語られなかったが有益なプロセス: 会話,実験
- 実験: 新しく知識を作り出す効果
Ch05 考えをまとめるには
- 情報の整理とアイデアを生み出すことは,連続的なグラデーション
- 情報が多すぎる?少なすぎる?
- 書き出し法で情報量を確認
- 5分間,言及するとよさそうな情報を思いつく限り書き出してみる
- KJ法のために,書いたものを容易に移動できることが必要
- 質を求めてはいけない
- 実践してみる
- 100枚を目標にする
- merit
- 進捗が明確に計測できる
- 中断が容易
- merit
- 重複は気にしない
- 重複は重要度の指標として重要
- 書き出し法で情報量を確認
- 多すぎる情報をどうまとめるか
- 並べて一貫性を高める
- 視線の移動だけで脳に戻すことができるようになる
- 中心は作業領域としてゆとりをもたせる
- column: 書き出し法の実例
- 並べる過程で思い出したらすぐ記録
- 関係のありそうなものを近くに移動
- column: ふせんのサイズ: 50mm×38mm
- groupingには発想の転換が必要
- groupingは客観的ではない
- 客観的に正しいというものはないという話
- groupingは階層的分類ではない
- 既存の分類基準を使うデメリット
- column: frameworkによる効率化
- 変化が不要な状況でのみframeworkは有用
- 事前に分類基準を作るデメリット
- 全体像を把握できていない状態で事前に作った分類基準は,高い確率で間違っている
- 盲点に気づき,既存の思い込みの枠を壊すことが重要
- 既存の枠を手放すこと自体が難しいので,そもそも持たないことが大事
- 具体的な情報が主体で,どう構造化するかという主観的な解釈は,具体的な情報に従属する
- 分類で負担を減らすメリット
- ボトムアップにgrouping
- groupingは客観的ではない
- 関係とは何か
- 類似だけが関係ではない
- NM法は対立関係に着目する
- 対立の解消に役立つかもしれない仮説を立てることを目指す
- 話題がつながる関係
- KJ法のgroupをプレゼンテーションのスライドにたとえる
- 話がつながるのが良いgrouping
- つなぐstoryを考えることで新しい情報が生み出されることもある
- 束ねて表札をつけ,圧縮していく
- 表札作りのメリット・デメリット
- merit
- 見かけの枚数の削減
- demerit
- 束ねたものの中身を見るのに手間
- merit
- 表札を作れるgroupが良いgroup
- groupingの段階で分類をしないことが必要
- ふせんが膨大なときの表札作り
- まず具体的な情報を用意し,それを集め,その上に表札を置いていく
- 「考えがまとまらない」と「部屋が片付かない」
- 情報デザイン: 情報を,人が効率的かつ効果的に使えるような形で準備する技法
- 片づけのテクニック
- 収納場所に先に分類ラベルを貼らない
- column: 表札とふせんの色
- 一度に書き出した内容が同じ色である確率が高くなるという点がメリットになる
- column: 知識の整合性
- 表札作りのメリット・デメリット
- 束ねたふせんをまた広げる
- 関係がある者が近い位置になるように空間的配置され,囲みや矢印が加筆された図解ができる
- 文章化してoutput
- format変換作業が有益
- あいまいなつながりに気づける
- format変換作業が有益
- 並べて一貫性を高める
- 社会人向けチューニング
- stepの省略
- 表札作りや図解化は省略する
- 中断可能な設計
- A4書類の整理法
- 押し出しファイリング
- クリアファイル整理法
- 探したいものの番号はデータの中で検索
- stepの省略
- 繰り返していくことが大事
- まとめ
Ch06 アイデアを思いつくには
- 「ideaを思いつく」はあいまいで大きなタスク
- 分解して,計測や管理可能なフェーズとする
- ideaを思いつく3フェーズ
- 耕すフェーズ
- 情報を集め,かき混ぜ,つながりを見出そうとするフェーズ
- 芽生えるフェーズ
- 管理できない
- 情報を寝かせて,ideaが芽生えるのを待つ
- 締め切りがあれば,time limitまでに芽生えたもので残りのフェーズを進める
- 育てるフェーズ
- 生まれたideaを磨き上げていくフェーズ
- 有用かどうか実験によって検証し,修正していく
- 耕すフェーズ
- 先人の発想法
- Youngのideaの作り方
- ①資料集め
- ②資料の加工
- ③努力の放棄
- ④ideaの誕生
- ⑤ideaのcheck
- ①と②はまとめて耕すフェーズ
- ③と④は芽生えるフェーズ
- 芽生えさせるのではない
- ⑤が育てるフェーズ
- 川喜田二郎の発想法
- Scharmerの変化のパターン
- U理論
- U曲線モデル
- level 1(4つの意識状態: level)
- Downloading
- 思い込みにとらわれて外界を観察していない状態
- Performing
- ideaが既存のシステムに組み込まれ,機能している状態
- Downloading
- Voice of Judgement
- level 2
- Seeing
- 外界を観察しているが,自分の既存の枠にしがみついて,他者の視点から情報を感じ取れていない状態
- Prototyping
- prototypeが作られた状態
- Seeing
- Voice of Cynicism
- level 3
- Sensing
- 他者の視点から情報を感じ取り,自分の既存の枠が壊れたが,「自分」を手放していない状態
- Crystallizing
- ideaが結晶化された状態
- Sensing
- Voice of Fear
- level 4
- Presensing
- 「自分」を手放し,未来の変化の可能性を見ている状態
- Presensing
- level 1(4つの意識状態: level)
- 芽生えは管理できない
- 運しだい
- 芽生えなかった時のリスクの管理
- 耕すことに時間を使う
- 育てる時間を確保する
- 管理できるところは管理し,できないものは管理しないのが,いいアイデアを生むための最大限の努力
- Youngのideaの作り方
- まずは情報を収集する
- 自分の中の探検
- 特殊資料 ←→ 一般的資料
- 今解決したい問題について特化した資料
- 自分の身近な問題の解決には,主観的な考えも確認する必要
- 特殊資料 ←→ 一般的資料
- 言語化を促す方法
- 自分の中から情報を引き出すために
- 質問によるtrigger
- framework
- 質問の束
- merit
- 盲点を埋めることに有益
- demerit
- framework自体が既存の固定化した思考の枠
- 枠に収まらない情報こそ生産において重要なこともある
- 適切なタイミングで少しだけ使えば有効だが,乱用し継続的に使い続けると有害になる
- 探索と利用のバランスが重要
- framework
- 創造は主観的
- 客観的に説明できることを制約条件としてしまうと,すでにあるものから遠からぬものとなってしまう
- 耕し,芽生えを待つフェーズでは主観的に考える必要がある
- 身体感覚
- ファインマン,科学とは何か
- 抽象概念を身体感覚に近づける必要
- 絵に描いてみる
- たとえ話,メタファー,アナロジー
- 抽象概念が現実に形を持たないため
- 遠い分野のアナロジーが使われたときに,製品の新規性が高まるという調査
- NM法とアナロジー
- Clean Language, Symbolic Modelling
- 相手からメタファーを引き出すことを目的とした方法論
- 前提を含まない質問
- どんな種類?ほかには?どこにある?どのあたりにある?何のよう?
- → symbolの生成
- symbolの時間軸上での変化やsymbolの間の関係を明確化していくことでsymbolを使って作られたモデルができる
- symbolの時間軸上での変化を明らかにする質問
- それから何が起こる?
- 次に何が起こる?
- そのすぐ前には何が起きる?
- それはどこから来る?
- symbolの関係を明らかにしていく質問
- XとYはどういう関係?
- XとYは同じ?違う?
- XとYの間には何がある?
- (Xが出来事のとき)Xが起きたとき,Yには何が起こる?
- まだ言葉になっていないもの
- 言語化のまとめ
- 自分の中の探検
- 磨き上げる
- 最小限の実現可能な製品(Minimum Viable Product: MVP)
- 構築・計測・学習のループを回してすばやく学習することが大事
- 誰が顧客かわからなければ何が品質かもわからない
- 何を検証すべきかは目的によって異なる
- U曲線を登る
- Crystallizing
- 漠然と思っていたことや不完全なideaが,書き出したり加工したり人に話したりすることで徐々に明確な形になっていく
- Prototyping
- 早い段階で問題に気づく
- Performing
- できあがったものを,より上位のシステムに埋め込みつつある状態
- サイクルを回して何度も登る
- Crystallizing
- 他人の視点が大事
- 誰からでも学ぶことができる
- それぞれ分野が異なる
- 相手がどう感じているのかの言語化を促し,それを吸収する
- time machineを作れ
- 相手の私的な言語を,質問を通じて理解する
- column: 知識の分布図
- 知識分野は独立しておらず,固定的でもない
- → 滑らかにつながった,閉じた円環でないものを使って表す
- 再び耕す
- 十分に他人の視点からの情報収集ができた後
- 1つは,改善
- もう1つは,idea自体を作り直すapproach
- column: 書籍とは双方向のcommunicationができない
- 最小限の実現可能な製品(Minimum Viable Product: MVP)
- まとめ
- ideaが生み出されるprocess, 知的生産の「生産」に直結する部分を掘り下げ
- 学ぶことは,自分の外のものを自分の中に取り込むこと
- ideaを生み出すことは,自分の中のものを外に出すこと
- 学びとideaの創造は,逆向きのことではなく,ほぼ同じこと
- 耕すフェーズは情報収集,育てるフェーズは検証と密に関連
- ideaが芽生える瞬間に起きることは,新しい結合であり,異なる者の間の関連の発見であり,パターンの発見であり,モデル化であり,抽象化
- まだ言語化されていないものを言語化する方法について掘り下げ
- 最初から客観的であろうとしたり正しくあろうとしたりする気持ちは,新しいものを生み出すことの障害になる
- まずは主観的な違和感や身体感覚,個人的なメタファーを駆使して,誰も見たことのないものを手繰り寄せる
- 磨き上げるのはそのあと
- KJ法は,仮説を生み出す知的生産の方法でもある
- 客観的に分類するのではなく主観的に結合を見出していくことが,新しいものを生み出すために必要
- KJ法は,情報を耕し,芽生えやすい環境を整える,有用な手法
- 磨き上げる手法
- MVP
- 小さく実験して,徐々に改善
Ch07 何を学ぶかを決めるには
- 何を学ぶのが正しいか?
- 数学の正しさ
- 公理が正しいと仮定したときに,公理の組み合わせによって論理的に導かれたもの
- 科学と数学の正しさの違い
- 科学では,何度も実験して確認されたことは正しい
- 数学では,何度も実験して確認しても,それが正しいことは保証されない
- 科学では,実験で否定されていない主張は仮に正しいものとする
- 主張を支持する結果が観測されればされるほど,その主張は信頼性が高まる
- 意思決定の正しさ
- 繰り返す科学実験と一回性の意思決定
- 意思決定に繰り返しは使えないことも多い
- 事後的に決まる有用性
- 有用性が1つの基準だが,事前には決まらない
- 過去を振り返って点をつなぐ
- 将来何らかの形で点がつながると信じて行動するしかない
- 何が有用かは事後的にしか分からない
- 何を学びたいかの答えを外に見つけても見つからない
- 繰り返す科学実験と一回性の意思決定
- 数学の正しさ
- 自分経営戦略
- 経営戦略のアナロジー
- 学びたい対象を探す探索戦略
- 自分の内面の「熱意が湧いてくるかどうか」に着目した戦略
- 何かを学ぶことで学ぶ力が培われ,別の分野の学びの効率も高められる
- column: 選択肢の数が意思決定の質にもたらす影響
- 二択より三択の方が16.7倍も良い結果
- 探索範囲を広くする
- 目についたもの,少しでも興味の湧いたものを片っ端から学んでみる
- 特に大学生向け
- 盲点の発見に他人の視点
- 違和感があったら無理に続けなくてもいい
- 知識を利用して拡大再生産戦略
- 自分の外側に注目
- ポジショニング学派: 自分が置かれている状況をポジションにたとえて,周囲の状況を分析し有利な場所を占めようとする戦略
- 社会人は,まず「今やっている仕事の効率化」を学び,時間の余裕を作り,その余裕を新たな学びに投資する
- ↑ 知識の拡大再生産戦略
- 拡大再生産: 企業が利益を上げたときに,その利益を生産設備などに投資し,その設備を使ってさらに利益を上げる
- 知識を使って時間を得て,その時間を知識獲得に投資する
- 知識を使ってお金を得て,そのお金を知識獲得に投資する
- 知識を使って立場を得て,その立場を使って知識獲得をする
- 卓越を目指す差別化戦略
- かけ合わせによる差別化戦略
- ある領域で1番でなくても,ほかの領域とかけ合わせて1番になればOK
- ふたこぶの知識
- communication〇
- T(またはπ)型人材
- 連続スペシャリスト
- 1つ目の専門性によって卓越の立場を作り,その立場から収穫を得て,それを2つ目の専門性の獲得に投資する
- 拡大再生産戦略と卓越を目指す戦略の融合
- 新入社員の戦略案
- 会社で得る知識Xとは異なる,新しい分野Yを見つける
- → その分野で卓越
- 組織の境界をまたぐ知識の貿易商戦略
- 知識の流れの滞り
- この流れの円滑化はしばしば経済的な価値を伴う
- → 複数の組織をまたぎ,組織間の情報流通を起こすことで価値を生む戦略が成立
- 知識とその需要が自分に集中するようになる
- 知識は複製できるので,知識が自分の中を流れるようにすると,知識の複製が自分の中に蓄積され,自分の価値を徐々に高めていく
- いくつかの方法
- 積極的に外部の情報源に触れる方法や,社内で学んだことを社外に伝える方法,複数の組織に所属する方法など
- 相互に教え合って相互に得をする形が〇
- outputのみの状況にならずに済む
- 知識の流れの滞り
- 知識を創造する
- 外の知識を取り込んでも,差別化につながりにくい
- 実際の応用の現場で必要に応じて生み出された知識は,流通しておらず,現場の状況にフィットした価値の高い知識
- → 新しい知識を生み出す力が,価値の源泉