読書録

分類 (*1) /書籍名 ページ数
ソフトウェア工学 (*2) 4777
『実践ドメイン駆動設計』 618
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 544(大型本)
『増補改訂版 Java言語で学ぶデザインパターン入門』 528
ユースケース駆動開発実践ガイド』 514
『エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド』 450
『実践テスト駆動開発 400
アンチパターン―ソフトウェア危篤患者の救出』 394
『新装版 達人プログラマー 職人から名匠への道』 383
『ソフトウェア品質知識体系ガイド (第3版)』 381
『ビヨンドソフトウェアアーキテクチャ』 368
『Team Geek ――Googleのギークたちはいかにしてチームを作るのか』 228
Web 2862
『Ruby on Rails チュートリアル』 829 (*3)
『パーフェクト Ruby on Rails 【増補改訂版】』 528
『Webを支える技術 ―― HTTP,URI,HTML,そしてREST』 400
『Webフロントエンド ハイパフォーマンス チューニング』 337
『フロントエンド開発入門: プロフェッショナルな開発ツールと設計・実装』 285
『入門React: コンポーネントベースのWebフロントエンド開発』 259
『Web API: The Good Parts』 224
データ構造とアルゴリズム 2379
『世界で闘うプログラミング力を鍛える本 コーディング面接189問とその解法』 772
数学ガール/乱択アルゴリズム 485
『問題解決力を鍛える!アルゴリズムとデータ構造』 461
数学ガール/ポアンカレ予想 421
Pythonによるプログラミング入門 東京大学教養学部テキスト: アルゴリズム情報科学の基礎を学ぶ』 240
プログラミング (*4) 1628
『プログラミングRust』 608
『Kotlinイン・アクション』 468
『メタプログラミングRuby 第2版』 292
『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』 260
システム・アーキテクチャ (*5) 1530
『コンピュータネットワーク 第5版』 1114
『コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方』 416
DB, SQL 660
『データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理』 660
Linux 440
『新しいLinuxの教科書』 440
エディタ 428
『実践Vim 思考のスピードで編集しよう』 428
コンテナ 384
『Kubernetesで実践するクラウドネイティブDevOps』 384
機械学習 320
『ゼロから作るDeep LearningPythonで学ぶディープラーニングの理論と実装』 320
セキュリティ 256
『サイバーセキュリティプログラミング』 256
クラウド基盤 216
Amazon Web Services 基礎からのネットワーク&サーバー構築』 216
業務改善 1480
『独学大全 絶対に「学ぶこと」をあきらめたくない人のための55の技法』 788
『問題解決の全体観』 上下巻 420
『エンジニアの知的生産術』 272
会計 752
『新・現代会計入門 第4版』 752
ソフトウェアビジネス 284
ハッカーと画家 コンピュータ時代の創造者たち』 284


  • (*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)
  • 文章の分析の例

練習問題のポイント

  • 二分探索は、不等号のときも限界値を探索できる ← 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乗法
    • ペナルティの和が最小となる係数を求める
      • 説明変数X(x1,...,xn)の各変数について微分した値が0となるような係数a0,...,anを求める
    • 連立1次方程式の求解アルゴリズム
      • 前進消去
      • 後退代入
      • モデル化
  • 数値誤差が生じるパターン
    • 浮動小数点数の計算
    • ピボット選択で誤差を回避
      • 誤差のない行と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.高度な検索:ゲノムを解析する

  • 高度な検索・動的計画法(DP)について
  • 手順
    • ①問題の解がどのような性質を満たすかを漸化式で記述
    • ②漸化式を再帰関数で実現
    • ③無駄な計算を避けるよう、過去の計算結果を記憶
  • 2次元のDP

練習問題のポイント

  • 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.データを分類する

  • データの分類・クラスタリングについて
  • 要素を表すベクトル
  • 要素間の距離を定めるd(X, Y)の存在
  • グループ数の設定
    • 各グループの分散がペナルティとなる
  • k-means法
    • 浮動小数点数は、等しさを求めず不等式で判定
    • 手順
      • ①各グループに対し、そのグループの重心を計算
      • ②各要素を最も近い重心に割り当て、新しいグループ分けを求める
    • 初期値依存性→モンテカルロ法の一種として実行、初期値を乱数を用いて決定
    • NP困難:NP困難な問題の正解を現実的な時間内で求めるアルゴリズムは存在しないと予想されている
  • プログラムの性質・コンピュータの限界

『退屈なことは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']
  • メソッド
    • index()
    • spam.append('A')
    • spam.insert(1,'A')
    • spam.remove('A')
      • 最初の値だけ消す
    • spam.sort(reverse=True)
      • ASCIIコード順。大文字の後に小文字。
    • spam.sort(key=str.lower)
      • 通常のアルファベット順ですべて小文字としてソート
  • 字下げルールの例外
    • リストの閉じ角括弧
    • \
  • リスト風のデータ型: 文字列とタプル
    • リストはミュータブルだが文字列はイミュータブル
      • 文字列の変更は、スライスと連結を使って元の文字列の一部から新しい文字列の生成が必要
    • タプルもイミュータブル
      • eggs = ('hello', 42, 0.5)
      • 順序づけられた値の並びを変更不可にしたいとき
      • コードが若干高速になる
    • list(), tuple()
  • 参照
    • リスト、辞書型は参照をコピーする
    • copy.copy()
      • 異なるリストを作る
      • cheese = list(spam)でも同じ
    • copy.deepcopy()
      • リストを含むリストをコピーする
  • 問題
    • int('3'*2)は33
    • 要素1つのタプル: (42,)のようにカンマが必要
  • 演習
    • カンマ付け
      • ', '.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))も同じ
  • データ構造で実世界の物体をモデル化する
    • 代数的記法
    • リストや辞書が有用
    • 三目並べ
      • 各マスにキーを振る
      • データ構造を作り、それを解釈して表示するコードを書くことで、モデル化したプログラムを書くことができる
  • 問題
    • 'cat' in spamと'cat in spam.keys()は同じ
      • in演算子はkeyに含まれるか調べる

Ch06 文字列操作

  • 文字列の操作
    • 文字列リテラル
      • ダブルクォート
        • 文字列にシングルクォートを含められる
      • エスケープ
        • \
        • ', ", t(タブ), n(改行), \
      • raw文字列
        • r''
        • エスケープを無視
      • 3連クォートによる複数行文字列
      • 複数行コメント
        • """ """
    • 文字列のインデックスとスライス
    • 文字列に対するinとnot in演算子
      • 大文字と小文字を区別して正確に調べる
  • 便利な文字列メソッド
    • upper(), lower(), isupper(), islower()
      • 新しい文字列を返す
    • isX
      • isalpha(), isalnum(), isdecimal(), isspace()(スペース、タブ、改行のみ), istitle()(大文字から始まって残りすべて小文字の英単語のみ)
      • validationに使える
    • startswith(), endswith()
    • join(), split()
      • ', '..join(['a', 'b', 'c'])
      • 'My name is Simon'.split(' ')
        • デフォルトではスペースやタブ改行などの空白文字で分割
        • 複数行の文字列の分割に使われる
    • rjust(), ljust(), center()
      • 'Hello'.rjust(10, '*')
        • 10文字の中で'Hello'を右揃え
        • 第2引数は埋める文字
      • 表形式のデータを正しくスペースを空けて表示するときに特に便利
    • strip(), rstrip(), lstrip()で空白文字を除去
    • pyperclip moduleで文字列をコピペ
  • プロジェクト: パスワードロッカー
    • プログラムの設計とデータ構造
      • 辞書でアカウント名とパスワードを関連付け
    • コマンドライン引数を扱う
      • sys.argv
    • 正しいパスワードをコピーする
  • プロジェクト: Wikiで箇条書きのマークアップ

Part 2 処理の自動化

Ch07 正規表現によるパターンマッチング

  • 正規表現を用いないテキストパターン検索
  • 正規表現を用いてテキストパターンを検索
    • Regex objectを生成
      • import re
      • re.compile()に正規表現パターンを表す文字列を渡すと、Regexパターンオブジェクトが返ってくる
    • Regex objectとマッチ
      • mo = obj.search('abc')
      • Match objectかNoneを返す
      • group()でマッチしたテキストを返す
  • 正規表現によるパターンマッチの続き
    • 丸括弧を使ったグルーピング
      • group(1)など整数を渡すとマッチした文字列の異なる部分を取得できる
        • 何も渡さないか0を渡せばマッチした文字列全体を返す
      • groups()で、すべてのグループを一度に取得する(タプルを返す)
    • 縦線を使って複数のグループとマッチ
      • グループを分けることで部分的にORでマッチできるようになる
    • 疑問符を用いた任意のマッチ
      • 0回または1回
    • アスタリスクを用いた0回以上のマッチ
    • プラスを用いた1回以上のマッチ
    • 波括弧を用いて繰り返し回数を指定
      • (Ha){3,5}
        • HaHaHa, HaHaHaHa, HaHaHaHaHa
      • {3,}, {,5}もあり
  • 貪欲マッチと非貪欲マッチ
    • ?をつけないと最も長いもの(貪欲)、つけると最も短いもの(非貪欲)にマッチする
  • findall()
    • 見つかったすべての文字列を(グループに対応したタプルの)リストで返す
  • 文字集合
    • \d: 0~9の数字
    • \w: 文字、数字、下線
    • \s: スペース、タブ、改行
    • それぞれ大文字はそれら以外を表す
  • 独自に文字集合を定義
    • [0-5], [aeiouAEIOU], [a-zA-Z0-9]など
    • 角括弧の中は正規表現の記号は解釈されない→エスケープ不要
    • ^をつけると補集合になる
  • キャレット(^)とドル記号
    • 先頭、末尾にマッチ
    • 全体の指定にも使える
  • ワイルドカード文字
    • ドット
    • ドットとアスタリスクであらゆる文字列をマッチ
      • 非貪欲なら/*?
    • ドット文字を改行とマッチさせる
      • 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
  • 演習
    • 強いパスワードの検出
      • 複数の正規表現でチェックして、すべて通ればOKとすればよい
    • 正規表現を使ったstrip()

Ch08 ファイルの読み書き

  • ファイルとファイルパス
    • os.path.join()で文字列をパスのフォーマットで結合する
    • os.getcwd(), os.chdir()
    • os.makedirs()
  • os.pathモジュール
    • import os
    • 絶対パス相対パスの操作
      • os.path.abspath(path)
      • os.path.isabs(path)
      • os.path.relpath(path, start)
      • os.path.dirname(path)
        • 最後のパス区切り記号より前を返す
      • os.path.basename(path)
        • 最後のパス区切り記号より後ろを返す
      • os.path.split(path)は上の2つをタプルで返す
      • '/usr/bin'.sprit(os.sep)でパスを個々の要素に分割したリストになる
    • ファイルサイズとフォルダ内容を調べる
      • os.path.getsize(path)
        • バイト単位
      • os.listdir(path)
        • ファイル名とフォルダ名のリスト
    • パスを検査する
      • os.path.exists(path)
      • os.path.isfile(path)
      • os.path.isdir(path)
  • ファイルの読み書きの方法
    • open()でファイルを開く
      • 読み込みモードで開く
        • 'r'で明示
      • Fileオブジェクトを返す
    • ファイルの内容を読み込む
      • read()
      • readlines()
        • 行ごとのリスト
    • ファイルを書き込む
      • 'w'
        • 上書きして最初から書き直す
      • 'a'
        • 追記
      • open()の第1引数に渡したファイルがなければ、新しい空のファイルを作る
      • close()
      • write()
        • 改行も自分で追加する必要がある
  • 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
    • 最も重視
      • 自分のコレクションから音楽を見つけ再生できるようにすること
      • → 機能は最小限,非常にシンプルなUIと情報構造になっていた
    • iTunesは複雑化
    • → 非統一,不明瞭
    • → ユーザは情報エコシステムの消費者であり,かつオーガナイザになっていった
    • Appleと,自分の個人的な音楽コレクションのためのオリジナル構造スキームによって,システムに組み込まれた情報構造に対処が必要になってしまった
  • information_architectureが取り組む課題
  • 情報オーバーロード
    • トフラー,情報生産の速度と変化の度合up
      • → 情報のS/N(Signal/Noise)比が小さくなり対処が必要
    • internet → 大量の情報が世界のだれとでも共有可能に
    • internet,とくにwwwは概念化された双方向のinteractive media
    • Webでの公開は速く,安く,効率的
    • 情報技術の進歩 → 入手可能な情報量が増える → 過剰な情報が,情報を整理・発見・よりよく利用するための新たな技術を生んでいる
    • → 初期のWebの成功がオンラインでの情報発見を支えるために創業された企業のものとなった
  • 情報にアクセスするより多くの方法
    • 電子機器の小型化 + ワイヤレス通信
    • → 情報をやり取りする方法を変える
    • ユーザのアクセス方法の増加
      • ユーザの利用に関する情報を収集して,このメタデータにもどついた追加機能を提供
    • 情報の脱物質化の次の論理的ステップ
      • 周囲へと浸透させ,世界との個人的なやり取りに絶えず存在する機能とすること
      • モノのinternet
      • 物質と情報のスペースをあいまいにする
    • かつてないほど多くの情報処理必要+多様な物理的,心理的コンテキストのなかで情報処理を行っている
    • ユーザにどのように情報にアクセスしてもらうかを考える必要
      • ↑ 各コンテキストで期待するものが違う
    • ユーザが情報にどこでどのようにアクセスするかにかかわらず,一貫した分かりやすい体験を求めている
    • : 多様なコンテキストにおいて多岐にわたる複数のデバイスで,情報を見つける必要がある
    • 製品やサービスをデザインした人々の助けが必要
  • information_architecture入門
    • 混乱の理由の1つ: applicationのほとんどが特定の問題を解決するためにデザインされているが,時が経つにつれ当初の問題解決の枠からはみ出し,より多くの機能を持つようになる傾向
    • → 明確さと単純さが失われる
    • ツールからエコシステムに代わる
    • 必要なのは,情報が簡単に見つかる,分かりやすい構成を作るための,体系化された包括的で全体的なアプローチ
      • ユーザが情報へのアクセスに用いるコンテキスト,チャンネル,メディアにとらわれないもの
      • 製品開発の溝から抜け出し,広い視点からものごとを見て,情報をより簡単に見つけ,理解できるようにするには,すべてをどう結び付ければいいのか理解する必要
        • information_architectureは,チームや個人がこの視点を得るためのレンズとして使える
    • 情報で作られた場所
      • 製品やサービスのやり取りに,言葉を利用していることを認識するのが大切
        • ラベル,メニュー,説明,ビジュアル要素,コンテンツ,それぞれの相互関係が体験を差別化し,理解を促進する環境を作り出す
        • 言葉の違いが,特定のタスクを満たすために訪れるべき場所の発見に役立つ
        • 言葉は伝える情報の枠組みを作り,既知のコンセプトとのつながりを理解させてくれる
        • 特定の言葉やイメージを選んで,その環境で何ができ何ができないかを判断する
    • チャンネルを超えた首尾一貫性
      • information_architectureは異なるチャンネルのニーズによっていくつもの方法で説明できる意味構造を定義するように求める
      • 普及するinformation_architectureの重要な要素: 整合性
        • 複数チャンネルとコンテキストにおいて,体験は一貫しているべき
        • 各チャンネルの機能や制限は異なるが,各チャンネルで用いられる意味構造は,なじみのある首尾一貫したものであるべき
          • 実際の実装から抽出
    • system_thinking
      • 個々のアーティファクトが内部で機能する体系的意味論の定義に取り組む
      • information_architectureは,高レベルの抽象モデル+数多くの低レベルのアーティファクト制作を求められる
      • 効率的な情報環境: 構造的一貫性(高レベルの不変性)と柔軟性(低レベルの柔軟性)とをうまく両立させるもの
      • 何をデザインしているのか理解する必要
  • まとめ
    • 情報は歴史的に非物質化される性質を持ち,入れものとの1対1の関係から,入れものから完全に切り離された状態になっている
    • このことから,情報がかつてないほど豊富になり,その情報とやり取りする方法がかつてないほど多くなっている
    • information_architectureは,情報を見つけやすく,分かりやすいものにすることに焦点を絞っている
    • 製品とサービスは情報でできた場所として認識され,そのエコシステムとしての機能は,最大効果を得られるようデザインされる
    • 抽象レベル+各レベルで定義

Ch02 information_architectureの定義

  • 定義
    • 定義
      • 1.共有する情報環境の構造デザイン
      • 2.デジタル,物理的,クロスチャンネル,エコシステム内の組織化,ラベリング,検索,ナビゲーションシステムの統合
      • 3.使いやすさ,見つけやすさ,分かりやすさをサポートする,情報製品と体験を形成するアートとサイエンス
      • 4.デジタルランドスケープのデザインとアーキテクチャに基本原則をもたせることに焦点を当てた,新たな規律と実践事例のcommunity
    • 現れる言葉と実際の意味との関係には注意が必要
    • 定義は不完全で制限されたもの
    • 情報
      • データや知識の管理とinformation_architectureとを区別するために,情報という用語を使う
        • データ: 事実と数字が関わる
        • 情報: ありとあらゆる形や大きさ
    • 構造化,組織化,ラベリング
      • 構造化: 製品やサービス内の情報「アトム(原子)」に対して適切な粒度レベルを決定し,それぞれをどのように関連付けるかを決定することが必要
      • 組織化: これらの要素を意味があってほかと区別できるカテゴリーにグルーピングし,ユーザが現在いる環境とそこで見ているものを理解できる正しいコンテキストを創造すること
      • ラベリング: そのカテゴリーおよびそのカテゴリーへのナビゲーション構造要素をなんと呼ぶかの答えを見出すこと
    • 見つけることと管理すること
      • findabilityは,ユーザビリティ全体の成功要因として欠かせない
        • 閲覧,検索,質問を組み合わせてもユーザのほしいものを見つけられなければ,そのシステムは失敗
      • ユーザ指向のデザインだけでは十分でない
      • 情報を管理する組織と人も重要
      • information_architectureはユーザのニーズとビジネス目標とのバランスを取る必要
        • 効果的なcontents_management,明確なポリシーと手順が必須
    • アートとサイエンス
      • usability_engineeringやエスノグラフィー(民族誌学)のような学問分野は,ユーザニーズと情報探索行動の分析に科学的手法の厳密さを適用するうえで役立っている
        • どのように使われるかのパターンを徐々に学べるようになってきたし,Webサイトをますます改善できるようになった
      • しかし,information_architectureの業務を数字に換算はできない
        • → 経験や直感,創造性に頼らざるを得ない
        • → 予期される失敗を進んで冒す: アート
  • 見えないからと言って存在しないわけではない
    • チェスの情報構造について
  • ものすごくいいinformation_architectureへの道
    • 効果的なinformation_architectureの設計を実践するためのモデルの基盤
      • ユーザ,コンテンツ,コンテキスト
    • モデルの根底: 孤立してしまっては役に立つinformation_architectureを作り上げることはできないという認識
    • 情報環境は,存在している情報システムやより広い環境の力により,動的で生体のような性質を持つ
      • 情報の豊かな流れ,煩雑さ,間違い,試行錯誤,適者生存
    • 情報エコロジーの概念: ユーザ,コンテンツ,コンテキストから成る
      • 情報環境に存在する複雑な依存関係を扱うために使われる
      • ベン図で3つの相互依存性を表す
      • → プロジェクトの背後にあるビジネスゴール,そして設計と実装に有効な情報源の理解が必要
        • 今日存在しているコンテンツの性質と量を認識し,この先1年でそれがどう変化するかも認識する必要
        • 主な顧客のニーズと情報探索行動についても学ぶ必要
      • 3つの分野すべてから情報を得て,3つの分野すべてを標的にする
        • ユーザの考え方,デモグラフィック,心理,タスクと情報ニーズ,情報探索行動などには,かなりのばらつきがある
        • コンテンツも,質,流通,権限,人気,戦略価値,コストなどによってさまざま
        • 組織的コンテキストも,使命,ビジョン,目標,組織的政策,組織的文化,集中化や自主性の程度によって異なる
      • 3つの円は難しい問題の解決にも役立つ
        • problems
          • 知っておくべき調査方法や評価方法とは何か
          • information_architectureをデザインするチームに加えるべきなのはどのような人々か
          • その分野と実践方法に遅れを取らないようにするには,どんな本やブログを読むべきか
          • 新たな可能性を提案するinformation_architecture戦略を始めるべきなのは何か
        • これらの問題への回答は,ユーザ,コンテンツ,コンテキストの3つのエリアとのバランスを取るところから始まる
      • 情報エコロジーはすべて独特なもの
      • 特定のプロジェクトにおいてそれに独自のニーズやチャンスが何かを学ぶ際には,このモデルが非常に役立つツールとなる
      • 完全に独自性を持つ情報エコロジーを発生させる
    • コンテキスト
      • 理解と団結が重要
    • コンテンツ
      • 人々がシステム上で使用したり見つけたりするもの,技術用語でいう材料
      • 所有権
      • フォーマット
      • 構造
      • メタデータ
      • ボリューム
      • ダイナミズム
    • ユーザ
      • 何を求めているか
  • まとめ
    • information_architectureを定義する方法は1つ以上あっても問題ない
    • information_architectureは簡単には説明できないもの
      • かなり抽象的で,製品やサービスの表面化,意味構造の深い部分にあるが,それも問題ない
    • 効果的なinformation_architecture設計を実践するためのモデルには,ユーザ,コンテキスト,コンテンツの3つがある
    • 変化するもののミックスは,情報環境ごとに異なるだけでなく,同じ環境において時間とともに変化する

Ch03 見つけやすさのデザイン

  • 内容
    • 情報を探すためのさまざまなモデル
    • 人々の情報探索行動
    • こうした行動について学ぶ方法
  • information_architectureは,人々がサイトを訪問したり,アプリを使用する理由から始まっている
  • ニーズの違いが異なる情報探索行動へとつながる
    • ユーザの優先度が高い行動がどれかを決める
    • アーキテクチャ設計の上で,どこに努力とリソースを注ぎ込めばよいのか決定しやすくなる
  • 「シンプル過ぎる」情報モデル
    • ユーザ自身が何を求めているのか知っているときは〇
    • それ以外では×
  • 情報ニーズ
    • ユーザが本来求めているのは,決断を下すための知識や手助けとなる考え
    • 魚採りの比喩
      • 既知情報探索
      • 探求探索
      • 全数探索
      • 再探索
  • 情報探索行動
    • 情報探索行動の基礎単位: 検索,探索,ブラウジング
    • 統合と反復
    • ベリー摘みモデル
      • 自分が本当に必要なのは何か,そのシステムからそのような情報を得られるのか,をより詳しく知るにつれて,情報のニーズを変更していく
      • 検索→ブラウズ→検索と進んでいける方法の例: Amazon
    • 真珠を育てるようなアプローチ
      • 関連ページなど
      • 2 step model
        • 「ほしい情報を見つけるにはどこへ行けばいいのか」をまず知りたい
        • 見つけたサブサイト内で情報検索
  • 情報ニーズと情報探索行動について学ぶ
    • 検索アナリティクス
      • 検索パフォーマンス,メタデータ,ナビゲーション,コンテンツでの問題を診断するうえで,自分のサイト上で最も一般的な検索クエリをレビューすること
      • ユーザが何を求めているかが分かる
    • contextual_inquiry
      • 検索アナリティクスを補完
      • ユーザが自然な状態で情報どのように相互作用するかを観察し,その文脈において,ユーザがなぜそのような行動をとっているかを質問できる
    • 情報アーキテクトとしても目標: 最善を尽くしてユーザの主要情報ニーズと情報探索行動の典型を知ること
    • ユーザがシステムに何を求めているかの理解が,どのアーキテクチャ要素を構築すべきかを決定,優先順位をつけるのに役立ち,ひいては作業を大幅に単純化する結果へとつながる
    • 良質のユーザデータから,設計にしばしば影響を与える要素間のバランスを取るのにも役立つ
  • まとめ
    • information_architectureは製品やサービスを利用するユーザと,利用する理由から始まる
      • ユーザには情報ニーズがある
    • ユーザが情報を求めるとき,何が起こるかというモデルがいくつかある
    • シンプルすぎるモデルには問題がある
      • ユーザに情報ニーズがあるとき,実際にはシンプルにことが運ばない
    • 情報ニーズは魚釣りに似ている
      • ユーザが自分で求めているものを明確に知っている場合もあるが,ほとんどの場合は流し網を使っている
    • ユーザはさまざまな情報探索行動によって情報ニーズを満たす
    • こうした行動を学ぶのにさまざまな調査方法がある

Ch04 理解のためのデザイン

  • 内容
    • ユーザは自分がいる場所とそこで何ができるかをどのように感じ取るのか
    • 物理的な世界における場の創造と情報環境における場の創造
    • 情報環境をより理解しやすくするための基本的な組織化原理
  • 物事の理解: 何かほかのものとの関係性による
  • information_architectureを設計するとき,「情報の受け取り方と理解の仕方を変える」という,新たなタイプの場の創造に取り組んでいる
    • 建物の建築士と同じように,情報アーキテクトも人が理解でき,利用できる環境を創造し,その環境が時間の経過に伴って成長し,ユーザや組織のニーズに合致していくようにしたいと考える
  • 情報を受け取る文脈を整え,構造によって原則が理解しやすくなる方法を見る
  • 場所の感覚
    • 場所の認識,プレイスメイキング衝動を,情報環境でも用いる
  • 現実世界のアーキテクチャ
    • 利用可能で,ほかのタイプの建物とは異なっているという共通点を持つ必要
  • 情報から成り立つ場所
    • UIの要素から,銀行のWebサイトと病院のWebサイトの違いが分かる
    • 建築は社会的な機能を効率よく果たし,伝えるための物理的な環境を生み出すことを目的としている
    • information_architectureもまた,情報環境において同じことを目的としている
    • 現実の建築では物質の定義を行うのに対し,information_architectureではナビゲーションラベル,セクションの見出し,キーワードなどの語義を定義し,設計の指針,ゴール,ガイドラインなど,未来の場所の感覚を把握するためのものを定める
      • 静謐な人里離れた場所なのか,それとも楽しい交流するためのスペースなのかなど
  • 組織化の指針
    • 情報環境は多種多様な方法で表現できる
    • information_architectureが作り出す意味的構造は,ほかの設計分野の製品よりも抽象的
    • architectureの異なるインスタンスに統一性を持たせるには,同じ言語を使用し,構成する言語要素間の特定の関係や秩序を作る
  • 構造と秩序
    • information_architectureの階層と要素の秩序は,完成したWebサイトに場所の意味と感覚を注入する
      • 同じ業界のほかのサイトやサービスとの差別化となる重要な部分
    • information_architectureの意味構造にも,サイト全体の中の個々の要素の相対的な重要性を示す階層がある
      • 秩序が概念的な境界線を定義し,サイトの形式を認識するうえで大きな役割を果たす
    • rhythm, pattern
      • ユーザの情報の受け取り方が変わる
  • 類型学
    • 建築における~~式
    • どのような性質のビジネスがWebサイトを運営しているかのヒントになる
    • ユーザが環境を理解し,ナビゲートしやすい
    • 標準的な構造を持つことこそが,競合他社のWebサイトとの差別化を容易にする
  • モジュール性と拡張性
    • 基礎部分の情報構造は比較的同じ状態を維持する
    • 時間変化の速度が異なる層で構成
      • 意味構造は比較的安定
      • information_architectureは比較的寿命の長い,意味構造の定義に主に焦点を当てている
    • デジタル情報環境のダイナミズムを考えると,情報環境アーキテクチャの適応性と拡張性は,実際の建物の場合よりも重要
      • 柔軟すぎてもあいまいさにつながり,communicationが不明確になりがち
      • 柔軟ともろさの中間あたりが理想的
        • 変化に対応しつつも,目的やアフォーダンス(身の回りに存在している意味ある情報)は明確にはっきりしているといえる
    • 変化の速度が異なる部分を見つけ出し,それらを全体に関連付けながらここに切り離すのも,バランスを取るための1つの方法
  • 地球上で一番幸せな場所
    • ユーザ,組織,社会間でバランスが取れると,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の組織化
      • 組織化システムは,サイトの情報をさまざまな方法で表示する
      • ナビゲーションシステムは,メインのナビゲーションバーがある場合のドロップダウンメニューでそれぞれの組織へ進めるようにするなど,コンテンツ内をユーザが動き回れるようにする
      • 検索システムは,ユーザがコンテンツを検索できるようにする
      • ラベリングシステムは,カテゴリやオプション,リンクを,ユーザが理解できる言葉で(できれば)説明する
  • トップダウン型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)
        • 検索クエリと手作業で組み合わされた,おすすめの検索結果
  • まとめ
    • information_architectureを他人に説明しなければならないかも知れないので相手が視覚化できるようにすることが重要
    • information_architectureはトップダウン型,ボトムアップ型で視覚化可能
    • information_architectureを分類する方法はさまざまだが,本書では組織化システム,ラベリングシステム,ナビゲーションシステム,検索システムの4つのカテゴリで見ていく

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やハイパーテキストを使ったアプローチも可能
          • 手始めとしては階層構造は適しているが,組織体系のほんの一部に過ぎない
    • データベース型モデル: ボトムアップアプローチ
      • DB: 検索と情報収集の簡便化とスピードアップを目的としてアレンジしたデータの集合体
      • メタデータが,information_architectureとDBスキーマとを結ぶ主要なキーとなる
        • メタデータの利用によって,不均一で構造化されていないWebサイトおよびイントラネットに対して,RDBの構造と威力を適用できるようになる
        • ドキュメントやそのほかの情報オブジェクトにメタデータを使ってタグ付け
      • メタデータのエレメンツ間の関係は非常に複雑になる可能性がある
      • 情報アーキテクトが理解しておくべきこと: メタデータや制限語彙,DB構造は,以下の事項を可能にするためにどう利用できるか
        • 自動生成されるアルファベット順のインデックス
        • 関連する「参照(see also)リンク」を動的に表現すること
        • フィールド検索
        • 検索結果の高度フィルタリングとソーティング
      • 比較的均質なサブサイトに適用すると,特に効果的
        • 製品カタログや社員住所録など
    • ハイパーテキスト
      • 情報を構造化するための高度で非リニアな方法
      • 要素タイプ
        • リンクされる情報のチャンクや項目
        • チャンク間のリンク
      • 上の要素が,情報のかたまりを結合するハイパーメディア型を形成する
      • ハイパーテキストチャンクは,階層型,非階層型,あるいはその両方を使って結合できる
      • コンテンツチャンクはWebのゆるやかなつながりでリンク
      • 高い柔軟性を獲得できるが,場合によってはより複雑になり,ユーザに混乱をもたらす可能性もある
      • → 主要な組織構造には不向き
        • 階層モデルやDBモデルを補う形で使うのが〇
      • 項目や階層内のエリア間を創造的に関連付けるには,ハイパーテキストが便利
  • 社会的分類
    • ユーザが作成するコンテンツタグによる社会的分類が,共有される情報環境において情報組織化の重要なツールとして浮上している
    • 共同作業による分類,モブインデクシング(不特定多数の人々によるタグ付け),民族的な分類などを含むフリータギングはシンプルだが強力なツール
    • 自由形式のタグ構造: フォークソノミー
    • 自由形式のタグは,特定の状況では役に立たないが,情報アーキテクトにとって重要なツール
  • 結合力のある組織化システムの作成
    • 「データを情報へと変化させる第一歩は,その組織構造を調査すること」
    • コンテンツのかたまりを小さな領域に集約すると,高度な機能を提供する組織化システムの可能性を追求できる
    • 全体像を見落とさないようにすることも重要
    • どの組織体系を適用するか検討する際,正確な情報の組織体系とあいまいな情報の組織体系の違いを考える
      • できる限り両方の体系を利用する
    • Web上で情報を組織化する難しさ
      • 同じ情報にアクセスする方法を複数提供して対処する
    • 大規模なシステムでは一般に複数の構造が必要
      • トップレベルは,情報環境の傘となるようなアーキテクチャであり,ほとんどの場合,階層型が〇
      • サブサイトにできそうな情報群は,DB型モデルがとても〇
      • それほど構造化されていない情報や,コンテンツ項目間の創造的な関係や,作者が提供するハイパーテキスト型か,ユーザ貢献型のタグ付けで処理する
    • いくつもの組織構造を組み合わせることで,結合力のある組織化システムが作成できる
  • まとめ
    • 世界をどう理解するのかは,世界をどう分類するかによって決まる
    • 分類は簡単ではない.あいまい,不均一,考え方の相違,政治的な圧力などの問題に対処しなければならない
    • 正確な組織体系またはあいまいな組織体系を使って組織化できる
    • 正確な組織体系にはアルファベット順,時系列,地理的分類がある
    • あいまいな組織体系にはトピック,タスク,顧客,メタファー,ハイブリッド型がある
    • 組織体系の構造はまた,情報環境の設計においても重要な役割を果たす
    • 社会的分類は,共有デジタル環境における情報の組織化のための重要なツールとして浮上してきた

Ch07 ラベリングシステム

  • 内容
    • ラベリングシステムとは何か,重要な理由
    • よくあるラベルのタイプ
    • ラベルを開発するためのガイドライン
    • ラベリングシステムを作成するためのヒント
  • ラベリング: 表現形態の1つ
    • ラベルを使って情報環境内の情報のまとまりを表せる
    • 情報をあれこれ目立つようにに表示する代わりにラベルを使えば,ユーザはすんなりと理解でき,何ができるかどうするか決められる
    • ラベルの目的: 情報を効果的に伝えること
      • → ページの物理的スペースもユーザの認識領域も無駄遣いすることなく,情報を伝える
  • ラベルは,複数のシステムとコンテキストにまたがる組織とナビゲーションシステムを最も明確にユーザに示す方法
  • なぜラベリングに注意を払う必要があるのか
    • 多くの場合,情報環境は,システムの所有者と作者のメッセージをユーザにゆっくり翻訳して伝え,また元に戻す仲介メディア
      • → メッセージがあいまいになるため,ラベルが必要
    • 相手と直接向き合えないという欠点を最小限に抑えるために,ラベルを作る
    • 新しい概念についてユーザに教えるのは,ラベルの役割
    • うまくいったラベルは邪魔にならない(失敗したラベルは目立つ)
    • 予測でき紛らわしくないラベルが〇
    • ラベルのチェック
      • 内容を描写していないうえにほかとの区別がつかないラベル
        • 内容が不明,脈絡がない
      • ラベルに専門用語が使われており,ユーザ中心のラベルになっていない
      • ラベルのせいでお金が無駄になる
      • ラベルのせいで悪印象を与えている
        • 貧弱なラベルは×
    • ラベルはほかの要素と同じくらい重要な要素
  • さまざまなラベル
    • テキストによるラベル
      • コンテキストリンク,ヘッダ,ナビゲーションシステム選択,インデックス用語
    • アイコンによるラベル
    • コンテキストリンクとしてのラベル
      • ドキュメントまたは情報チャンクの本文内にあるハイパーリンクテキストを説明しているラベル
      • 周囲のテキストという説明的なコンテキスト内に生じる
      • 作成が簡単で,Webの成功を促すエキサイティングな相互連結性の基礎
      • 簡単に作成できるからこそ問題も起きる
      • → コンテキストをうまく作り上げることで,ラベルの意味が周囲のテキストから引き出される
      • ラベルの持つ多様性は,より多くのラベルの組み合わせやラベリングシステムからコンテキストを引き出し,ひいては意味を引き出している
      • しかし,リンクラベルではシステム的な一貫性は期待できない
      • コンテキストリンクを作成しラベリングする前に,「ユーザはどのような情報につながると予測しているだろうか」と問いかけることで,情報アーキテクトはコンテキストリンクラベルの具象性を確認できる
      • ほとんどの場合,コンテキストリンクは情報アーキテクトの力が及ばないことも知る
  • ヘッダとしてのラベル
    • ヘッダ: それに続く情報チャンクを描写
      • コンテンツ内の階層を築くために使われる
      • サイトのサブサイトを決めたり,カテゴリとサブカテゴリとを区別する役目を持つ
    • 親子関係や兄弟関係といったヘッダ間の階層関係は,視覚的要素の組み合わせを一貫して使うことで築ける
    • 階層関係を目立たせることにあまり厳密にならないようにする
      • 読まなくても視覚的に区別できればヘッダは不要
    • ラベリングをプロセスに入れる際には一貫性の維持が特に重要
      • ヘッダラベルははっきり目に見えていて,先へ進む順序を伝える必要がある
        • → 番号を使うのが一般的
        • 一貫性を持った行動としてラベルを述べる,つまり動詞を使用するという方法も先へ進む手順をまとめるときに役立つ
          • ラベルは「どこから始まるか」「次はどこへ行くのか」「先へ進むときに各ステップでどんな行動を取ることになるのか」を伝える必要
    • ヘッダラベルは階層的,順番的,または複合的かもしれないが,コンテキストリンクラベルよりもシステム的に設計されるべきもの
  • ナビゲーションシステム中のラベル
    • オプション数の少ないナビゲーションシステムラベルは,ほかのどのタイプのラベルよりも一貫して適用されることが要求される
    • ナビゲーションシステムはサイトに繰り返し登場 → ナビゲーションラベリングの問題は拡大される
    • ページ配置と見た目が一貫した場所で「合理的に」振る舞うために,ユーザはナビゲーションシステムに頼る
      • ラベルは常に同じである必要
      • ↑ 親近感を養うためには,ラベルを効果的に適用することが欠かせない → ページごとにラベルが違っては困る
      • 色も配置も一貫していればさらに効果的
    • 基準はないが,多くの場合ナビゲーションシステム用に共通する用語がある
      • 各カテゴリに対して1つの用語を選択し,それを一貫して適用するのが〇
        • メイン,メインページ,ホームのなかから1つ選ぶなど
    • インデックス用語としてのラベル
      • キーワード,タグ,説明を含んだメタデータ,用語体系,制限語彙,シソーラスなどと呼ばれ,あらゆる形式のコンテンツを記述するために用いられるもの
      • コンテンツの意味を描写することで,単にコンテンツの全テキストを検索するよりも精密な検索が可能になる
      • 人がコンテンツの意味を確認して表現したもの → 単純に検索エンジンで全テキストからクエリと合うものを探すより,インデックス用語を検索した方が効果的
      • ブラウジングも容易になる
      • サイト本来の組織化システムの代替物となり,ユーザにとって非常に便利
        • 組織化システムからもインデックス用語からもアクセスできる
      • サイトインデックスやリストの形を取ったインデックス用語は,組織のサイロ間にある縦の境界線を横断する手段として有効
      • インデックス用語がまったく見えない場合もある
        • CMSやDBの中のドキュメントを表現する際に使うレコードは,インデックス用語のフィールドを含んでいるが,ほとんど見ることができない
        • HTMLドキュメントのmeta, titleタグの中に埋め込みメタデータとして隠れていることもある
        • Web検索エンジンにおいては,インデックス用語を使ってメインページを説明した方が効果的にページやサイトをユーザに知らせられる
      • 各ページを目立たせようとするのはかなり困難な作業
        • 制限語彙やシソーラスからインデックス用語を選んで利用するなど,よりシステム的なアプローチでラベリングする方が効果的
        • → 目的: より詳細な範囲を一貫性のある予測可能な方法で記述すること
    • アイコンラベリング
      • アイコンはナビゲーションシステムのラベルとして使われることが最も多い
        • 特にモバイルアプリのように,画面のスペースに制限がある場合など
      • 問題: テキストラベルよりも言葉が限られている点
      • → 小規模な組織のシステムラベルやナビゲーションシステムなど,オプションが少ない用途がほとんど
      • 情報環境に優美さが生まれるので,システムのユーザビリティを阻害しないのなら,使わない手はない
      • 繰り返し利用してもらえるなら,アイコンによる言語がユーザの心に確立される
        • → アイコン言語は具体的かつ視覚的にも認識しやすい伝達システムとして非常に有効
      • ユーザが繰り返し使ってくれる場合以外は,選択肢が限られたシステムにおいてのみアイコンラベルを使い,機能を説明する前に使用しないことが推奨
  • ラベルの設計
    • 効果的なラベルの設計はinformation_architecture最大の難関
      • 言語自体があいまいなので,完璧なラベルという自身は持てない
      • 類義語や同音異義語についても考えなければならないし,コンテキストが違えば用語の意味の理解にも影響する
      • 多言語対応
      • ラベリングは科学よりアート
    • 一般的なガイドライン
      • ユーザ,コンテンツ,コンテキストの変化のしやすさが,ラベルをあいまいな世界に導く
      • 可能な限り視野は狭くする
        • 全サイトをカバーしているグローバルナビゲーションシステム以外は,全システムのコンテンツを扱うラベルは使わないようにする
      • 一貫性のあるラベルではなく,一貫性のあるラベリングシステムを発展させる
        • 一貫性は予測可能であることを意味し,予測可能なシステムは覚えるのが容易 → 一貫性が重要
        • 一貫性に影響を及ぼす問題
          • スタイル
          • 表示
          • 構文法
          • 粒度
          • 総合性
          • 顧客
    • ラベリングシステムの情報源
      • 既存のラベリングシステム
        • サイトに現在あるラベル,比較できるサイト,競合他社のサイトのラベルなど
      • 現在のシステム
        • 手作業や自動的な方法でラベルを収集する
        • 集めたラベルを整理し,各ラベルとドキュメントが表す概要も含めて簡単な表にすると〇
        • 表にして改善点を探す
      • 比較サイトと競合サイト
      • 制限語彙とシソーラス
        • 図書館学の専門家,つまり主題の専門性のバックグラウンドを持つ人々により作成されたもので,的確な表現と一貫性が保証されている
        • 特定の顧客が特定の種類のコンテンツにアクセスしやすくなるように,狭い範囲で語彙を探す
    • 新しいラベリングシステムの作成
      • 最も重要な情報源: コンテンツ(と,その作者の可能性もあり)とシステムのユーザ
      • コンテンツ分析
        • 時間のかかるつらい作業
        • 既に存在している「コンテンツの見本」に集中してスピードアップが必要
          • コンテンツの見本: タイトル,要約,抄録
        • 自動抽出ツールを使えば,作業の8割までは完了する
          • 高額で学習コストもかかる
      • コンテンツ著作者
        • 著作者に提案を依頼する
        • 再集計ではない
      • ユーザの代表者とテーマ内容の専門家
        • ライブラリアンと想定ユーザを決めて作業
          • ユーザがシステムに何を求めているか
        • まず少数のグループ化から初めて,それをもとにしてサイト全体のインデックスをサポートするラベル作りに発展させた例
      • ユーザ(直接的)
        • 入手しづらいが得られれば最も有用
      • カードソート
        • オープンカードソート
          • 既存のコンテンツに対するラベルを被験者に与える
          • 被験者はそれを群和気氏,独自のカテゴリとする
        • クローズドカードソート
          • 被験者に既存のカテゴリを与えて,そのカテゴリ内にコンテンツを並べ替えてもらう
          • ナビゲーションのラベルなど,少数のラベルにより適している
        • カードソートは非常に有益だが,被験者は実際の製品のコンテキストに即してラベルを提示しているわけではないことを認識必要
      • フリーリスティング
        • カードソートよりさらに低コスト
        • 1つの項目を選び,被験者にその項目を説明する言葉について意見を出し合ってもらう
        • どんな人に何人に頼むのか,被験者について考える必要
        • コンテンツのサブセットの選択
        • 利用パターンと頻度を見る
          • 個々のアイテムにどのようにラベルをつけるかの間を与えてくれると同時に,ユーザが用いる言語についても示してくれる
        • ラベリングシステムを開発するうえで,どのような傾向,スタイルにすればよいかのヒントを与えてくれる
      • ユーザ(間接的)
        • 検索クエリやタグの分析
        • → ユーザのニーズに関するデータという価値ある情報を生み出している
      • 検索ログ分析
        • 検索クエリの分析は,サイトのユーザが一般的に使用しているラベルを理解するのに最適な方法
        • Google AdWordsを使って,ユーザがどんな用語を検索しているかをチェックして,検索用語を得る方法もある
    • 微調整
      • まずリストをアルファベット順にソートする
      • 重複を削除
      • 用語の用法,句読点,大文字小文字の用法などの観点から,リストをチェックする
        • 一貫性のなさを解決し,句読点やスタイルのルールを確立するよいタイミング
      • どの用語をラベリングシステムに含めるのかは,システムがどれだけ幅広いのか,どれだけの規模かという状況のもとに決断する必要
        • まずラベリングシステムに明らかなギャップがあるかどうか判断
        • 最終的に要素として入れる必要のありそうなラベルが網羅されているか
      • 将来サイトでカバーされると予想できるトピックについても考える
        • 仮のラベルがラベリングシステムに及ぼす影響は驚くほど大きい
      • サイト独自のコンテンツと特定のユーザのニーズを満たすには,ターゲットを絞り,範囲を限定し,手元にあるビジネス目標に狙いを定めたうえで,正しく定めた範囲内で包括的なものになるようにすべき
        • バランスの問題
      • 取り掛かろうとしているラベリングシステムは,その後すぐに調整と改善の必要性が生じる
        • ラベルは,ユーザとコンテンツという,2つの絶え間なく変化し続ける対象の関係を描写しているため
        • → ユーザテストを実施する容易を司,検索ログを定期的に分析し,必要に応じてラベリングシステムを調整するようにする
  • まとめ
    • 我々は常にラベリングしている
    • ラベリングは,複数のシステムとコンテキストにまたがる組織のスキームを最も明確にユーザに示す方法
    • システムのユーザと同じ言語を用いるラベルを設計しつつ,コンテンツを反映するようにしなければならない
    • テキストラベルは仕事中に目にする最も一般的なラベルのタイプ
      • コンテキストリンク,ヘッダ,ナビゲーションシステムオプション,インデックス用語がこれに含まれる
    • アイコンラベルはそれほど一般的ではないが,スクリーン面積が小さい端末では広く採用されている.多くの情報環境において,こうした端末が重要になっている
    • ラベルの設計は,information_architectureにおける最も難しい一面
    • 既存の情報環境や検索ログ分析などさまざまな情報源があり,ラベリングを選択するうえで役立つ

Ch08 ナビゲーションシステム

  • 内容
    • Webナビゲーションにおけるコンテキストと柔軟性のバランス
    • グローバル,ローカル,コンテキストナビゲーションの統合
    • サイトマップ,インデックス,ガイド,ウィザード,コンフィギュレータなどの補助的なナビゲーションツール
    • パーソナリゼーション,視覚か,タグクラウド,コラボレーティブフィルタリング,ソーシャルナビゲーション
  • コンテキストを提供し,より柔軟性を高めようとする場合は,お互いを補足し合うようなナビゲーションツールが必要になる
  • 「構造化と組織化」は部屋を建築士,「ナビゲーション設計」はドアや窓を取り付けるようなもの
  • 構造化,組織化,ブラウジング,検索システムのすべてが,効果的なナビゲーションに貢献している
  • ナビゲーションの表層,つまりユーザが操作を行う部分が,非常に速く変化している
    • さまざまな計上の端末の拡散により,設計者や開発者はバラバラ場スクリーンサイズや操作のメカニズムに対応するため,多様な戦略を考案せざるを得ない状況になっている
      • 「レスポンシブ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サイトのコンテンツと機能を紹介する場合に便利
      • 直線的なナビゲーションの提供が一般的
      • Webサイトの各領域で何がみられるのかを文章で説明しながら,主なページのスクリーンショットを盛り込むと〇
      • ガイド設計の基本的原則
        • ガイドは短く
        • どこかの段階で,ユーザがガイドを終えられるようにする
        • ナビゲーション(戻る,ホーム,進む,スワイプのジェスチャー)は各ページで同じ位置とし,ユーザが簡単にガイドの前後へ進めるようにする
        • ガイドは疑問に答えることを目的に越渓する
        • スクリーンショットははっきりした見やすい画像西,重要な機能については拡大する
        • ガイドツアーのページ数が2~3ページ以上になる場合は目次が必要になることもある
      • ガイドはメインの機能ではない
    • コンフィギュレータ
      • 製品を構成したり,別途注意が必要な複雑な決定木をナビゲートする際に役立つ
      • 洗練されたコンフィギュレータでは,ユーザの複雑な意思決定プロセスを詳しく考察できる
      • 直線的にプロセスを進んだり,ステップを飛び越えたり戻ったりできる
      • サイトのグローバルナビゲーションが常に表示されているので,次に進むべきステップが分かる
      • 選択が構成プロセスにどれほど影響を与えるかをはっきり理解してもらうために,さまざまなオプションがあると理解させるヒントを提供する
    • 検索
      • 補足型ナビゲーションの中心
      • 自分の入れたキーワードで情報を探せるという理由から,ユーザに好まれる
      • かなり詳細なレベルで結果を得られる
      • 言葉の性質があいまいなため,たいていの検索体験には大きな問題が発生している
        • 同じものを指していても,ユーザ,著者,情報アーキテクトと,それぞれが使う単語が異なる
      • → Ch09
  • 高度なナビゲーションアプローチ
    • パーソナリゼーションとカスタマイゼーション
      • パーソナリゼーションは提供側がユーザの望みを推測し、カスタマイゼーションはユーザが望みを提供側に伝える
      • あくまでも既存のナビゲーションシステムの改善または補足に過ぎない
      • 現実的な役割
        • 一般的に重要ではあるが限られた役目を果たす
        • 構造化と組織化の基盤がしっかりしている必要がある
        • うまく生かすのは非常に困難
        • 計量した数値を収集しユーザ行動を分析するのがさらに困難になる
      • 効果的なパーソナリゼーションに必要な情報をユーザは提供しない
        • Amazonで持っている本が表示される例
        • 全ユーザの経験の操作は×
      • カスタマイゼーションの問題
        • 大部分の人々はカスタマイズに時間を費やしたくないと考えていて、本当に重要な数少ないサイトでしかそういう作業をしない
        • ユーザ自身でさえ、明日自分が何をしたいのか分からないこともある
    • 視覚化
      • メタファーとして物理的な場を表示したり、ページ間の関係を示したりするのはそれほど有用ではなかった
      • 選択が必要な要素の結果がどのように見えるかをユーザが知っている場合は、視覚化が最も有効
    • ソーシャルナビゲーション
      • 巨大なソーシャルネットワークの興隆により、ソーシャルナビゲーションは情報を構築するための重要な手段となっている
      • ほかのユーザの行動を観察することで、ユーザは利益を得ることができるという前提にもとづいて築き上げられたもの
        • トラフィックの量やユーザ主導の投票システムの実装によって、人気のあるコンテンツを見つける手助けをする
      • ネットワークでつながった人々や端末が増えるのに従って、生成されるソーシャルナビゲーションシステムは劇的に複雑になり、洗練され、そして便利になる
        • 組織は個々のユーザのニーズに合った情報環境のナビゲーション構造を構築する新たな方法を見つける
        • 特定のユーザのソーシャルグループの好みにあまりにもぴったり一致したシステムは、ほかのものの見方を軽視しがち
      • プレイスメイキングにおいては、グローバルナビゲーション構造が重要な役割を果たす
        • Webサイトを訪れるとき、ユーザは共通する、変化のない構造をある程度共有する必要がある
        • → バランスが重要
  • まとめ
    • 進路を定め、現在地を把握し、帰り道を見つけるためにナビゲーションシステムを使う。
      • ナビゲーションは前後の感覚を提供し、新しい場所も安心して探検できるようにしてくれる
    • ナビゲーションの表層、つまりユーザが操作を行う部分は、非常に速く変化している
    • ナビゲーションシステムにはさまざまなタイプがある
      • グローバルナビゲーションシステム、ローカルナビゲーションシステム、コンテキストナビゲーションシステムの3つが一般的
    • ブラウザなどの情報環境を探検するためのツールは、独自のナビゲーションメカニズムを提供する
    • ユーザがシステム内で現在位置の把握を可能にするコンテキストの構築は、ナビゲーションシステムの重要な機能
    • グローバルナビゲーションシステムは、情報環境においてすべてのページまたはスクリーンに表示されるもの
    • ローカルナビゲーションシステムはグローバルナビゲーションシステムを補足するもので、これによってユーザは現在いるところを探検できる
    • コンテキストナビゲーションシステムは環境内で表示されるコンテンツのコンテキスト内にある
      • 項目間に定めた関係を発掘することで、ユーザの関連学習をサポートする
    • サイトマップ、インデックス、ガイドなど、利用できる補足型ナビゲーションシステムにもさまざまな種類がある

Ch09 検索システム

  • 内容
    • サイトに検索システムが必要かどうか判断する
    • 検索システムの基本解剖学
    • 検索しやすくするものとは
    • 検索アルゴリズムの基本的理解
    • 検索結果を表示するには
    • 検索interface設計
    • もっと学ぶには
  • サイトに検索は必要なのか
    • サイトにはコンテンツが十分にあるか
      • ユーザがサイトにどんな情報を求めてやってくるのかが重要
        • 求める情報がはっきりしているほど、検索機能の価値も上がる
    • より有益なナビゲーションシステムに集中しているか
    • サイトの検索システムを最適化する時間とノウハウはあるか
    • 検索よりもよい代替案があるか
      • 技術的な制約がある場合など
    • ユーザは検索を嫌がらないか
    • 以上が注意や脅威、以下が実装のタイミング
    • 情報が多すぎてブラウズしきれないとき、検索が役に立つ
      • 大きな書店のようなイメージ
    • 検索は断片化したサイトの役に立つ
      • 最優先にすべきことは、組織横断的なコンテンツに対して、可能な限り全文テキストによるインデックス化を行う検索エンジンを設定すること
    • 検索は学習ツールである
    • ユーザが望むから検索はそこにある
      • 探したいものが分かっておらず、ブラウジングで十分かもしれない場合も、とにかく検索してみるユーザ
      • あって当然という期待
    • 検索はダイナミズムを制御する
      • 動的なコンテンツ → 検索システムを構築
      • 検索エンジンが自動的にコンテンツにインデックスをつける
  • 検索システムの解剖学
    • 「ユーザに最適な」検索エンジンの選択が重要
    • 水面下でのさまざまな処理
      • インデックス化とスパイダー化のためのツール
      • クエリをソフトウェアが理解できる言葉にし、結果をランク付けするためのアルゴリズム
      • クエリを入力するためのinterface
      • 検索結果を表示するためのinterface
      • クエリ言語の多様さ
      • クエリを向上させるクエリビルダー
  • 何をインデックスするかを選ぶ
    • 検索領域を作り、きちんと比較できるものが表示されるようにする
    • ドキュメントやレコードの構造における要素の選択
    • ふさわしいものを最初に検索し、そこで役立つ結果が得られない場合に、サイト全体を検索できるようにする
      • まずは製品を検索し、見つからなければサイト全体を検索するなど
    • 検索領域の決定
      • ニーズに合わないコンテンツを除外
      • サイトの組織化体系を選択する際に下した決断が、検索領域の選択の際にも役立つ(Ch06で開設した項目)
        • コンテンツの種類
        • 顧客
        • 役割
        • 主題/topic
        • 地理
        • 時系列
        • 著者
        • 部門/business unit
      • ブラウジングシステムと同じく、検索領域も大きなコンテンツを細かくし、ユーザにサイトとコンテンツの見方を複数提供する
      • 一方で、検索領域によって設定がさらに複雑になり、検索領域を使ってもらえないこともある
      • ナビゲーション vs 目的ページ
        • サイトを検索する際、ユーザは目的ページを探している
        • 検索結果を得るプロセスの途上にナビゲーションページがあると煩雑になり、検索結果が分かりづらくなる
        • ナビゲーション vs 目的ページというアプローチの問題点
          • 本質的に厳密な組織構造の体系であり、ページの役割をナビゲーションか目的かに限定してしまう点
      • 特定のユーザ層のためのインデクシング
        • サイトのアーキテクチャにユーザ中心の組織構造の体系を採用しようと決めているなら、ユーザ層ごとに分けた検索領域の作成が〇
        • インデックス動詞の重複が少なければ検索のパフォーマンス〇
      • 主題によるインデクシング
      • 最近のコンテンツをインデクシング
    • インデックスをつけつコンテンツの要素を選択する
      • ドキュメントの構造を開発・利用する
        • コンテンツ要素がより正確な検索を可能にする
        • コンテンツ要素が検索結果のフォーマットにも意味を持たせる
        • → 検索結果をさらに柔軟に設計できるようになる
      • パラドックス
        • 最初の検索で高性能な検索機能を求めることはほとんどない
        • ユーザが価値があると思っているほかの検索interfaceを研究し、それと同様の機能を提供するかどうか決めるのが〇
  • 検索アルゴリズム
    • information retrievalに関する標準テキストで詳細は求められる
    • 本質的にはツールであり、特定のアルゴリズムが特定の問題解決に役立つ
      • 全ユーザの情報ニーズを満たせる検索アルゴリズムは1つとしてない
    • 検索エンジンの心臓部
    • パターンマッチアルゴリズム
      • 再現率と適合率
        • 再現率 = 検索された適切なドキュメント数/適切なドキュメントの総数
          • 高めると、良い結果とともに不適切な結果も大量についてきてしまう
        • 適合率 = 検索された適切なドキュメント数/検索で表示されたドキュメントの総数
          • 十分な検索結果が得られればほかの関連情報は要らない場合
          • 精度の高さが望まれる
        • 反比例の関係
          • バランスが大事
            • ユーザのニーズによる
        • ステミング機能
          • 同じ語幹を持つ単語を含めて検索
          • 再現率が高まる
          • 適合率は低くなる
        • コンテンツがどれだけ構造化されているのかの考慮
          • 構造の一部のみ見れば良い場合の方が精度〇
    • ほかのアプローチ
      • ドキュメントをクエリの等価物に変換するアルゴリズム
        • 意味の豊富な用語だけが残り、それらの用語がクエリに変換され、類似した検索結果を収集する
      • 類似したメタデータでインデックスづけされた検索結果を表示する
        • 協働的フィルタリングや引用検索のようなアプローチ → 1件の適切なドキュメントから結果をさらに広げていける
      • これらのアルゴリズムの主な目的は、最高のドキュメントを割り出して、検索結果として表示すること
        • 最高は主観であり、ユーザが検索で何を求めているのか把握が必要
        • ユーザの情報ニーズを表現する検索アルゴリズムを持った検索ツールを手に入れる
  • クエリビルダ
    • クエリのパフォーマンスを強化
    • スペルチェッカー
    • 音韻ツール
      • 名前検索などに〇
    • ステミングツール
    • 自然言語処理ツール
      • クエリの結合関係を調査
      • how toなのかwho isなのかといった知識を活かして検索の幅を狭める
    • 制限語彙とシソーラス
      • 自動的に同義語をクエリに含め、クエリの語義的な性質を拡大する
    • サイトのユーザの情報ニーズに合わせてツールを選択する
  • 検索結果の表示
    • どのコンテンツ要素を表示するか
      • 探し物が分かっている人には少なく情報を表示
        • 象徴的コンテンツ要素、つまりタイトルや著作者などのみを表示して、求める結果を素早く区別できるようにする
      • 何を探したいか分かっていない人にはより多く情報を表示する
        • 記述的コンテンツ要素、つまりページの要約やキーワードなどを表示すれば役に立つ
        • 何を表示するかユーザに選んでもらう方法もある
      • ほとんどのユーザが見るのは結果のうち最初の画面だけ
      • 検索結果についてどのコンテンツを表示するかは、各ドキュメントでどのコンテンツ要素が使えるか(どのように構造化されているかなど)にも、またコンテンツがどのように使われるかにも依存する
      • 特に引き出すような構造がない場合や、検索エンジンが全テキスト検索をする場合は、ドキュメントのテキストからコンテキストの一部をそのまま表示するのも〇
        • 検索用語を太字で強調など
  • ドキュメントをいくつ表示するか
    • ユーザのニーズに合わせて選べるようにさまざまな設定方法を提供する一方で、少ない結果を示すことで単純化し使い勝手を調整していくと、信頼できる検索結果となる
    • ドキュメント1つ1つに対して少量の情報なら、得られる結果が多いほうがよいこともある
    • 検索で得られたドキュメントの総数は必ずユーザに知らせる
    • 検索ナビゲーションシステムの提供も考慮
    • 検索ボックスでクエリを繰り返せるようにする
    • 検索結果を一覧表示する
      • どのような順番でユーザは情報がほしいのか、検索結果をどう使いたいかによって、並べ方が変わる
      • 並び替え
        • タスクを遂行する際に役立つコンテンツ要素で並び替えが現実的
      • ランク付け
        • 情報の理解や何かを学ぶ必要がある場合はランク付けの方が役だつ
        • 一般的には、ドキュメントの関連性を高いものから順に示すために使われる
          • 関連性は相対的なもので、ランク付けするアプローチも厳選が必要
      • アルファベット順の並び替え
        • 一般的な目的、とくに名前の並び替えには〇
      • 時系列の並び替え
        • 時間が問題、歴史的なデータを提示する場合に役立つ
      • 関連性でのランキング
        • 条件
          • 獲得したドキュメント内に何回クエリ用語が出てくるか
          • そのドキュメントにどれだけの頻度でクエリ用語が出てくるか
          • クエリ用語がどれだけ接近して出てくるか
          • どこにクエリ用語が出てくるか
            • タイトルにある方が本文より〇など
          • クエリ用語が出てくるドキュメントの人気度
        • ドキュメントの内容が雑多なほど、関連性のランキングには注意が必要
        • 人によるインデクシングでも関連性を確立できる
          • キーワードと説明文の領域で検索して、日との判断した価値を利用
        • 専門技術と時間とにかなりの投資が必要なので、best betのアプローチは実装コストが高くつく
          • → サイトの全ユーザクエリの開発には適さない
        • recomendationは、最も一般的なクエリに使われるのが一般的で、自動的に出てくる検索結果との組み合わせによって使われるのがほとんど
      • 人気度によるランキング
        • Google評判の源
        • 検索で得られたドキュメントに対していくつリンクが存在するのかを分析することで、ランク付けされる
        • リンクの品質も区別
        • 小さなサイトやリンクの貼られていない個別のサイトの集まりは、必ずしも人気度を利用できるとは限らない
        • 関連性には、そのほかにも多くの基準がある
      • ユーザまたは専門家の評価によるランキング
        • ドキュメントとともにユーザ評価を表示すると役立つ
      • 広告型検索サービス(Pay For Placement)によるランキング
    • 結果のグルーピング
      • 一覧にする方法はどれも完ぺきではない
      • → 混合させるアプローチの方が上手くいくが、高度なレベルでツールに関わると、検索エンジンを制作する作業が必要になる
      • 代わりに、得られた結果を何らかの一般的な観点によってクラスタリングする方法がうまく機能する
        • 検索結果がカテゴリ別にクラスタリングされていると、一覧を評価の順番で並べたサイト同様にパフォーマンスが向上するという結果
      • トピックやユーザ、言語、製品群などのメタデータを使って手作業で分類するのが効果的
        • ただし手作業はコストがかなりかかる
      • 図9-21: クエリをコンテキスト化
        • 興味にあうカテゴリを選択 → 結果が大きく減る
        • 検索の進行中に検索領域を作り出しているようなもの
    • 検索結果を出力する
      • コンテキスト分析とタスク分析のテクニックえ、ユーザが検索結果で何をしたいのか分かる
      • 行動喚起(Call To Action)
        • 個々の検索結果にCall To Actionボタンやリンクを含めるのが〇
        • 例: アプリのインストール
      • 結果のサブセットを選択する
        • ショッピングカート機能など
      • 検索の保存
        • 定期的に動的に生成されるコンテンツのクロールなどには非常に便利
  • 検索interfaceの設計
    • ユーザと検索テクノロジの機能には幅広いバリエーション → 検索interfaceを設計する「正しい方法」は出てこない
    • バリエーションの例
      • ユーザの検索経験のレベルと動機付け
      • ユーザの求める情報のタイプ
      • 検索される情報のタイプ
      • 検索される情報の量
    • ユーザのニーズの推測が重要
    • 検索がうまくいくかどうかは、主に検索エンジンとそのinterface、コンテンツがどのようにタグされ、インデックス化されているかにかかってくる
    • → 検索interfaceはできるだけシンプルが〇
      • シンプルな検索ボックスと「検索(Search)」というボタンだけユーザに提示する
    • ボックス
      • 検索システムを設計する際はテストを行うのが〇 ← ユーザは動作を仮定して考えるため
      • ユーザが検索をやり直す必要を感じたときに、方法を伝えるようにする
      • 本当に複数のフィールドが必要なとき以外は、検索ボックスは1つにしておくのが〇
        • 複数必要な場合は分かりやすいラベルが必要
      • 無味乾燥な小さい検索ボックスの背景には、数多くの仮定がある
      • 設計においては、ユーザの持つ仮定を判断して、そのうえでデフォルト設定を決めるようにする
    • オートコンプリートとオートサジェスト
      • ユーザが最初に入力したいくつかの文字に遭いそうな結果の一覧が、検索ボックスのそばに表示される
        • 検索インデックス、制限語彙、手作業で作成された一致リスト、またはこれらのすべてから選り抜かれたもの
        • 表示はシンプルで直接的なテキストの一覧から、高度にカスタマイズされたレイアウトのポップオーバーまでさまざま
      • 非常に有効なテクニック
        • 一部、または不完全な情報をもとに、ユーザが合っているかもしれない情報を見つける手助けになるため
        • ユーザは検索ボックスからシステムを探っていけるので、検索をより賢くしていける
    • 高度な検索
      • 探している情報の構造を理解しているユーザには、柔軟性とパワーを与える
      • ほとんどのユーザが高度検索ページを訪れる必要がないよう、検索システムを設計するという目標を持つ方がよい
    • 検索のやり直しのサポート
      • 検索結果ページで検索を繰り返す
        • 最初の検索で検索ボックスに入力した文字を表示すると便利
      • 検索結果がどこから引き出されたかを説明する
        • どのコンテンツが検索されたのかをはっきりさせる
          • → 検索の幅を広げたり狭めたりするときに役立つ
      • ユーザが行ったことを説明する
        • クエリの言い換え
        • どんなコンテンツが検索されたか説明
        • 可能性のあるフィルタを説明
        • スペースを使うことで自動的に適用される「AND検索」のように、暗に示されたブール演算子やほかの演算子を示す
        • 並び替えの順序など、その他の現在設定を示す
        • 検索結果の数の提示
      • 検索とブラウジングの統合(この2つが一緒になることで「発見」になる)
        • 検索とブラウジングをつなぐ機会を探して、ユーザが簡単に前後に進めるようにする
    • ユーザがつまづいてしまったとき
      • 検索結果が多すぎる → 検索結果を狭める方法を提示が〇
        • 現在の検索結果内で検索しなおすなど
      • 検索結果が0 → 「行き止まりがない」ポリシーを採用する
        • ユーザには常にほかの選択肢が用意されているようにする
        • これらの基準をすべて満たす検索システムはほぼ見たことがないレベル
  • もっと知るためには
    • 書籍
    • Searchtool.com
    • Search Engine Watch
  • まとめ
    • 検索は情報を見つける重要なメカニズム
      • サイトが必ずしも検索システムを必要としているというわけではない
    • 検索ボックスに言葉を入力するだけの検索はシンプルに見えるが、背後ではたくさんのことが起きている
    • 情報システムにおいて何をインデックス化するかの選択は、検索システムを構成するうえで重要なステップ
    • 検索アルゴリズムは多種多様
    • 検索結果をユーザに表示する方法も多種多様
    • 何を探すか、何を検索するか、結果をどのように表示するかという、これらのすべての要因が検索interfaceで一体となっている

Ch10 シソーラス・制限語彙・メタデータ

  • 内容
    • メタデータと制限語彙の定義
    • 同義語の輪、典拠ファイル、分類体系、シソーラスについて
    • 階層、等価、連想関係
    • ファセット分類法とガイド付きナビゲーション
  • Webサイトのようなインタラクティブな情報環境は、システムが複雑に依存しながらつながりあった集合体
  • ページ上の1つのリンクはサイトの構造の一部であり、組織化、ラベリング、ナビゲーション、検索システムの一部でもある
  • これらがどのように関わり合っているかを考える必要がある
  • システム間のネットワーク関係を見る際に、メタデータと制限語彙はすばらしいレンズを提供する
    • メタデータで動いている大規模なWebサイトでは、制限語彙が、システムを1つにつなぎ合わせるのりの役目を果たすようになってきた
    • バックエンドのシソーラスは、フロントエンドでのユーザエクスペリエンスをシームレスで満足のいくものにしている
  • さらに、シソーラスのデザインを行うことは、過去と現在との間に存在する溝を乗り越える助けとなる
  • メタデータ
    • Wikipediaからの引用
        • データの作成方法
        • データの目的
        • データ作成の日次
        • データのクリエイタまたは作者
        • データが作成されたコンピュータネットワークのロケーション
        • 使用された標準
    • メタデータタグが使われるのは、ほかのコンテンツオブジェクトを描写するため
    • コンテンツのナビゲーションと検索を向上させる目的
        • HTMLのmetaタグにおけるkeywords属性
    • 今日では、多くの企業はもっと洗練されたやり方でメタデータを使っている
    • メタデータで動く動的なサイトは、分散型オーサリングとパワフルなナビゲーションをサポートするが、こうしたサイトの作成の手段としてコンテンツマネジメントソフトウェアと制限語彙が使われる
    • メタデータ駆動型モデルを見ると、Webサイトの作られ方と管理のされ方が大きく変化したことがわかる
      • 分類学のどこにこのドキュメントを入れるか?」から、「このドキュメントをどう表現するか?」と質問できるようになった
        • あとはソフトウェアと語彙システムが面倒を見てくれる
  • 制限語彙
    • 語彙の制限は形も大きさも様々
    • 最もあいまいなところでは、制限語彙は自然言語の中で定義された部分集合
    • 簡単に言うと、制限語彙は同義語の輪の中にある適当な言葉のリスト
      • 典拠ファイルのフォーム内の同意義用語のリスト
    • 用語と用語の間に階層的な関係を定義すれば分類体系ができあがる
    • 概念間の関連関係(see also, see related など)を規範にすればシソーラスに取り組み始めることになる
    • 制限語彙のタイプ: 図10-1
      • ↓ 単純→複雑
      • 同義語の輪→典拠ファイル→分類体系→シソーラス
    • 同義語の輪
      • 検索を目的としたときに、同義の言葉であると定義された単語をつなげて1つのセットにする
      • 適合率と再現率の問題
      • 同義語の輪は再現率を劇的に高める
        • 一方で適合率は下がる
      • → interfaceデザインをよくし、ユーザの目標をうまく理解すれば、2つのバランスを取ることができる
        • 検索結果の1番上には正確にキーワードとマッチした結果を並べる
        • 一番最初の検索では同義語の輪を無視し、結果がほとんど不足しているときに、「関連する単語を含めて検索してください」と表示するオプションを加えるなど
      • 制限語彙の単純かつ便利な形式
      • 今日の多くの巨大な情報環境において、欠かせない基本的な機能
    • 典拠ファイル
      • 厳密な定義としては、優先語、すなわち条件に合う価値を一覧にしたもの
        • バリエーションや同義語は含まれない
      • 図書館や政府機関で広く使用され、制限範囲内のエンティティに適切な名前をつけることを目的としている
      • 言い換えると、典拠ファイルは好ましいと定義された、または条件に合った価値がある用語を含んでいる同義語の輪
      • オンライン環境で典拠ファイルを使うことと、その価値に関する問題
        • バックエンドでの理由として、典拠ファイルがあれば、コンテンツの著作者とインデックス供給者は承認された用語を効率的かつ一貫性を持って使える
          • 制限語彙管理の点から見れば、優先語があるおかげで類義語の追加、削除、変形を効率よく行え、同義語の中からどれを使えば良いか判定できる
        • ユーザにとっては、教育的な面で役立つ
          • スペルミス、業界用語の説明、ブランド名の認識など
          • コンテキストが非常に異なる場合に、このような「レッスン」が役立つ
            • クライアントが使った言葉を理解して、それを企業や業界で使われている用語に翻訳してクライアントに返す
          • ユーザが検索からブラウジングに移る際にも優先語は重要
            • 分類体系、ナビゲーションバー、インデックスの設計において、優先語を使える
      • ポインタの使用: 用語のローテーション
      • 調査と判断の上で、有効なインデックスのみ作成する
    • 分類体系
      • 優先語を階層として変化させること
      • これらの階層が「異なる形式をとれるし、複数の目的を果たせる」という認識が重要
        • フロントエンドのブラウズ可能な階層。可視性があり、UIを統合している
        • 著者やインデクサーによって使われるバックエンドツール。ドキュメントの組織化とタグ付けを目的とする
      • e.g. Netflix
        • マイクロタグ
      • 分類体系は一度きりの閲覧やインスタンスに縛られていない
        • あらゆる方向から、バックエンドにもフロントエンドにも利用できる
    • シソーラス
      • 辞書の定義: 類義語と関連する概念の言葉のグループを一覧にした本
      • ナビゲーションや検索を改善するために情報環境の中で統合化されたもの
        • 語義に関する概念のネットワーク
        • 単語とその類義語、同音異義語、反意語、意味が広い用語や狭い用語、関連用語などと結びついている
      • オンラインDBの形となっていて、デジタル製品やサービスのUIと緊密に結合している
      • 類義語を管理して、言葉のあいまいさを減らし、ほしいものを見つけられるようにする
      • 定義
        • 検索向上のために同義性、階層性、関連性を明らかにした制限語彙のこと
        • これら3つの語義関係を基本にしながら、単純な制限語彙の構造物の上に成り立っている
  • 技術専門用語
    • 優先語(PT: Preferred Term)
      • a.k.a. acceepted term, acceptable value, subject headings, descriptor
      • すべての関係は優先語に関して定義されている
    • 変形語(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)
      • 本来、優先語を定義する種類のものではない
      • できる限り言葉のあいまいさを除外して限定した意味を伝えることを目的として用いられる
    • 優先語が語義の世界の中心
  • 作動中のシソーラス
    • PudMedの例
      • 論文のメタデータレコードを検索
        • 要件と件名標目の組み合わせ
      • MeSH: Medical Subject Headings. 米国立医学図書館が定める生命科学の用語集
      • MeSH browser: MeSHの構造と語彙をナビゲーションするためのinterface
    • Amazonの例
      • ライブリンク
      • 階層的分類体系と件名標目を手段として、検索とブラウズに強力な選択肢を提供
    • 素晴らしい能力と柔軟性
      • 時間をかけてUIを形成し、精度を高めていける
  • シソーラスのタイプ
    • 古典的シソーラス
      • インデクシングと検索をする間際に使われる
      • インデクサーはドキュメントレベルのインデクシングを行うときに、様々な用語を優先語に対応させるためにシソーラスを利用する
      • 検索者は検索のために利用
      • クエリ単語はシソーラスの豊富な語彙にマッチし、これにより同義語管理や階層的ブラウジング、関連リンクが可能になる
      • 完成された形であり、完全に統合されたシソーラスで、この章の大部分で言及してきたシソーラスのこと
    • インデクシングシソーラス
      • 古典的シソーラスの構築は必須ではないし、必ずしもできることでもない
      • シナリオ: 制限語彙を開発し、ドキュメントをインデクシングできるけれども、検索体験に対して同義語の管理能力を自分では構築できない
      • どんな場合でも制限語彙のインデクシングはできるが、検索とユーザが使う様々な用語を優先語に対応させることはできない
        • 深刻な弱点だが、何もないよりはインデクシングシソーラスがある方がよい理由がある
          • インデクシングシソーラスが一貫性と効率性を高め、インデクシングプロセスを構築する
            • インデクサーは優先語とインデックスガイドラインの理解を共有し、統合されたユニットとして働ける
          • 優先語のインデックスがブラウズ可能になる
            • あるテーマや製品に関するすべてのドキュメントを1回のアクセスで見つけられる
      • インデックスに一貫性を持たせると、サイトを頻繁に訪れる人々にとって情報システムはかなり価値がある
      • 古典的シソーラスへのステップになる
        • ブラウズ可能なインデックスに初期レベルの語彙を追加することに始まり、うまくいけば検索機能を取り入れられる
    • 検索シソーラス
      • 古典的シソーラスが非実用的なケース: コンテンツ側にドキュメントレベルのインデクシングを妨げる要因がある場合
        • 三者のコンテンツを扱っていたり、毎日変わるニュースを扱うケース、または単にコンテンツがあり過ぎて手作業でインデクシングを行うと天文学的なコストがかかるケースなど
      • 検索の時点では制限語彙を手段としているが、インデクシングの段階では利用していない
      • ユーザに検索のためのオプションを提供
      • ブラウジングにかなりの柔軟性をもたらす
        • 類義関係や階層関係、同義関係をナビゲートさせられる
        • 莫大な量のコンテンツをナビゲートし、アクセスする新しい方法を提供できる
      • merit: 開発費と維持費がコンテンツのボリュームに依存しない
        • 一方で、同義語と関連語に関しては質が要求される
  • シソーラス標準
    • 多くの国内・国際標準
      • ISO 2788, BS 5723m AFNOR NFZ 47-100, DIN 1463, ANSI/NISO Z39.19
      • 単一言語圏におけるシソーラスの構築を網羅
    • シソーラスが伝統的な形式から解き放たれ、ネットワーク情報環境に埋め込まれた新しいパラダイムへと移行する真っ只中にある
      • 対象のユーザが異なる
    • 標準を守るメリット
      • ガイドラインを定めた考え方と知性が存在する
      • シソーラス管理ソフトウェアの大部分は、ANSI/NISOシソーラス標準に従った設計である
        • 技術統合の観点から見て、標準を守ることが役立つ可能性がある
      • 標準に従うことでDB間の互換性のチャンスが増える
    • 対処方法
      • ガイドラインを読み、納得できる部分は標準に従う
      • 必要に応じて標準から外れてもいいように準備する
      • → 規則を破る機会があるからこそ、情報アーキテクトの人生は楽しくて刺激に満ちている
  • 語義の関係
    • 等価
      • 優先語と変形語をつなぐ
      • 類義語よりも幅広い用語
      • 目標: 検索目的の等価として、用語をグループ分け
        • ユーザに見つけてほしいと思うコンテンツに導く漏斗役となる収録語意を作り上げる
    • 階層性
      • 情報空間を分割してカテゴリとサブカテゴリにする
      • 概念の広さや狭さ、いわゆる親子関係で情報を分ける
      • sub type
        • Generic(一般化)
        • Whole-part(全体-部分)
        • Instance
      • 様々な方法があり簡単ではない
        • 主題別、製品カテゴリ別、地理別など
        • 多面体シソーラスは一般的なニーズである複数の階層へのニーズをサポート
        • 粒度や何階層を開発するかなど、注意しなければならない問題もある
      • カードソーティングメソドロジー → Ch11
    • 連想
      • 同意義または階層関係内では捉えられない語義のつながりを強くほのめかすもの
      • かなり主観的なプロセス
      • sub type
        • 研究領域と研究主題
        • プロセスとその手段
        • 概念とその構成要素
        • 行動と行動結果
        • 因果的依存につながる概念
      • オンラインコマースでは、顧客と関連商品・サービスを結ぶよい手段となる
        • クロスセル
        • UEとビジネス目標の両方の向上につながる
  • 優先語
    • terminology(用語学)は欠かせない
    • 用語形
      • 基本は標準に従う
      • 標準がカバーしている問題
        • 文法的語形
          • 標準では名詞の使用が奨励されているが、動詞や形容詞を使った方が良い理由も多く存在する
        • スペル
          • 一貫性が重要
        • 単数形と複数形
          • 加算名詞は複数形の使用が〇
          • 一貫性が重要
        • 略語と頭字語
          • 一般的な用法がデフォルト
    • 用語選択
      • 文語的な正当さとユーザにとっての正当さのバランスを解決するのに必要なのは、目標がなんであるかと、Webサイトにシソーラスがどう組み込まれているかを再確認すること
      • 業界用語をユーザに教えるために優先語を使いたいか、入力語彙として優先語を頼りにしているか
    • 用語の定義
      • 挿入用語限定子(Parenthetical term qualifier)は同綴異義語を管理する方法を提供している
        • e.g. Cell
      • スコープノートも、意味をより限定するほかの方法を提供している
        • 1つの概念に限定した意味を伝えるためのもの
        • インデクサーが適切な優先語を選択するのに役立つ
        • 検索の手段か結果として表示されて、ユーザの役に立つこともある
    • 用語の限定性
      • コンテンツのボリュームが増すにしたがって、精度の高い複合語を使う必要性が増す
  • 平行階層
    • 大規模になれば避けられない
    • 精度を高めるための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: すばらしい能力と柔軟性
      • 基礎をなす記述的なメタデータと適切な構造のおかげで、ナビゲーションの選択肢を何百通りも試せる
      • ガイド付きナビゲーション: 発見しやすさと利益性が明確に直結している通販サイトですぐに採用された
  • 展望
    • メタデータ、制限語、制限語彙、シソーラスは主要なWebサイトやイントラネットを構築するためのブロックとなる
    • 単一分類法のソリューションは柔軟なファセットアプローチに影を潜めることになる
  • まとめ
    • シソーラス、制限語彙、メタデータは、フロントエンドのエクスペリエンスをシームレスでかつ満足できるものにするため、情報環境のバックエンドで運用される
    • メタデータタグは、ドキュメント、ページ、画像、ソフトウェア、ビデオ、オーディオの各ファイル、またその他のコンテンツオブジェクトを説明し、効率よくナビゲーション、検索できるようにするために用いられる
    • 制限語彙は自然言語のサブセットであり、同義語の輪、典拠ファイル、分類体系、シソーラスが含まれる
    • これらのシステムによって言語を構造化、マップ化できるため、利用者はより簡単に情報が探せるようになる
    • ファセット分類と平行階層によって情報を複数の方法で提示できるので、利用者は自分が探しているものを自分の方法で見つけられる

Part 3 information_architectureの仕上げ

  • information_architectureを作り上げるためのプロセスとメソッドを追求していく

Ch11 調査

  • 内容
    • information_architectureの開発プロセスへの統合
    • 人、コンテキスト、コンテンツを学ぶ方法と理由
    • ステークホルダーへのインタビュー、実践的評価、ユーザテスト、カードソーティングを含む調査方法
    • 開発プロセス: 調査→戦略→設計→実装→保守
    • 調査
      • 現在ある背景の情報をよく検討し、戦略チームとミーティングを行うことから
      • 目的: 目標とビジネス上のコンテキスト、既存のinformation_architecture、コンテンツ、対象としている顧客をよく理解すること
      • その後、情報の生態環境を探求するために、様々な手法を用いて一連の調査、検討を行っていく
    • 戦略
      • トップダウンの観点では、1番上から2レベルか3レベル分のサイトとナビゲーションの構造を定義する
      • ボトムアップの観点では、ふさわしいドキュメントタイプと大まかなメタデータスキームが提案される
      • 導入までプロジェクトを導く方向性の見通しが確立でき、information_architectureに高いレベルの枠組みが提供される
    • 設計
    • 実装
    • 保守
      • サイトのinformation_architectureを継続的に評価し、改善する
      • 新しいドキュメントに対するタグ付けや古いドキュメントの削除といった日常的タスク
      • サイトの利用状況やユーザからのフィードバックのモニタリング
      • 調整を通じてサイトを改善する機会を明らかにする
  • 調査フレームワーク
    • 適切な質問を選ぶための幅広い環境の概念的なフレームワークが必要
      • コンテキスト、コンテンツ、ユーザのベン図でバランスを取る
  • コンテキスト
    • ビジネスのコンテキストを調査することから始めるのが〇
      • プロジェクトは、目標を明確に理解し、政治的環境を正しく認識するところから始めるべき
    • 必要なものの入手
      • プロジェクトにサポートを受けるためのプレゼンテーションと説得
    • 背景調査
      • 適切な人に適切な聞き方で適切なタイミングで質問する
      • サイトの使命、ビジョン、目標、期待される顧客、コンテンツに関するものならどんなドキュメントでもよいので手を付ける
      • マネジメント構造と企業文化の鳥瞰図を得られるようなドキュメントも見つける
      • 特に組織図は、組織に対するユーザのメンタルモデルがどうなっているかという重要な要素を表している
        • インタビューやテストを行う際に、どの出資者、ユーザグループに依頼すればよいかを決めるのに役立つ
      • NOTE: ビジョンと実際のサイトとの比較の意義
    • 導入のプレゼンテーション
      • ステークホルダーに、information_architectureの重要性や、サイトを構成するほかの要素や組織とinformation_architectureの関係、主なマイルストーンと成果物について理解してもらうことが望ましい
      • → 今後起こりうる危険を察知、チーム間に生産的な関係
    • 調査ミーティング
      • 戦略チームミーティング
        • 難しいけれど必要な質問を質問しやすいと感じられるのは、顔をあわせた実際の会話の中でのみ
        • 小規模で、自由な雰囲気で行うことが大切
        • 議題
          • システムの目標
          • 期待されている顧客
          • 計画しているコンテンツと機能
          • アクセスのためのチャンネル
          • 誰が作業にかかわるか
          • いつ結果が必要か
          • 予期している障害は何か
      • コンテンツマネジメントミーティング
        • コンテンツの発信者とマネージャと議論する
        • 議題一覧
          • コンテンツを発信するにあたっての公式なポリシーと非公式なポリシーは何か
          • オーサリングとパブリッシングを扱うCMSはあるか
          • それらのシステムにはコンテンツを管理するための制限語彙や属性があるか
          • コンテンツはどのようにシステムに入れられるのか、誰が行うのか
          • どのような技術を利用しているか
          • 各発信者が扱うコンテンツは何か
          • コンテンツの目的は何か
          • など
      • 情報技術ミーティング

『コンピュータネットワーク 第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
      • この自由度は未決着
    • 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

  • 目的
    • 経路選択アルゴリズムと、アルゴリズムが使うデータ構造の設計が、network_layerの設計で重要
      • routing_algorithm
        • VPNでのsession routing by VC
      • forwardingとroutingの区別
      • algorithmが満たす性質: 正確性、単純性、対故障性、安定性、公平性、効率性
      • non adaptive algorithm: static routing or adaptive algorithm: dynamic routing
  • 内容
    • 最適化原理
      • 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)
      • ルータの故障の損失の最小化が重要
    • 階層化routing
      • ルータをリージョンに分割
      • 代償: 経路長が増大
      • N個のルータのネットワークにはlnNのレベルが〇 → 各ルータは合計elnN個のエントリを持つ
    • broadcast_routing
      • multidestination routing
      • flooding〇
      • reverse path forwarding◎
        • 送信元への経路が最短のときだけすべてのLinkに送信
        • 容易な実装と効率〇
      • spanning treeの使用
    • multicast routing
      • groupの生成と破棄が必要。ルータがどのグループのメンバか特定
        • routing以外のタスク
      • 密なグループと疎のグループの2パターン
      • spanning treeの枝刈り
        • MOSPF(Multicast OSPF) @Link State Protocol
        • DVMRP(Distance Vector Multicast Routing Protocol)
          • 再帰的に枝刈りメッセージを返送
      • Core-based trees
        • → treeの共有で、storage, message送信、計算量の大幅削減
        • PIM(Protocol Independent Multicast)の一部
    • any cast routing
      • グループ内で最も近いメンバにパケットを送信
      • DNSで利用
    • mobile hostに対するルーティング
      • home location or network_layerよりも上の層の可動性 e.g. skype
        • home agent
        • care-of(気付) addressの取得 @移動先のネットワーク利用前
        • tunneling: 重要。home agentが新しいヘッダでカプセル化 → 気付アドレスに送信
        • triangle routing
        • → 大規模なnetwork中で多くのルータの経路の再計算を回避
    • ad hoc networkにおけるrouting
      • MANET(Mobile Ad hoc NETwork)
      • AODV(Ad hoc Ondemand Distance Vector)
        • 経路の探索と維持

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
      • leaky bucketとtoken bucket
      • admission controlとtraffic aware routingの組み合わせ
    • trafficの抑制
      • 輻輳回避
      • dnew = αdold + (1-α)s
        • α: EWMA(Exponentially Weighted Moving Average)
          • 過去の履歴を保持する期間 → 変動を平滑化
      • choke packet: 送信者へ返送
      • 明示的な輻輳通知(ECN: Explicit Congestion Notification)
        • 返送ではなく受信者に通知 → 送信者に返す
      • hopごとのchoke packet
    • 負荷遮断
      • wine(古が〇)とmilk(新が〇)のポリシー
      • packetの重要性による判断
      • ランダム初期検知
        • RED(Random Early Detection): ルータで早めにパケットロスを発生
          • packet lossを検知 → transport_layerで送信速度を下げる
          • ECNの方が望ましい

5.4 QoS

  • 目的
    • over provisioning
    • スループットのminとレイテンシのmaxを保証する必要
    • 低コストでの実現
    • QoSのための4つの課題
      • アプリケーションがネットワークに何を求めているか
      • ネットワークに流入するトラフィックをどのように制限するか
      • 性能保証のために、ルータのリソースをどのように予約するか
      • ネットワークが追加のトラフィックを安全に受け入れられるか
    • → IntServ(Integrated Service)とDiffServ(Differentiated Service、差別化サービス)を見る
  • 内容
    • アプリケーションの要件
      • フローに要求されるQoS
        • jitter: 遅延やパケット到着時間の変化(標準偏差)
      • QoSの種類
    • traffic shaping
      • バースト性とデータフローの平均レートを制限
      • 多様なトラフィックに対して、ネットワークのトラフィックパターンを単純かつ利用しやすい形式で記述する
      • ユーザとネットワークがフローのトラフィックパターンを合意
        • SLA: e.g. ある顧客のすべてのトラフィックなど、多数のフローと長い期間を対象にしたネットワークの取り決め
        • traffic policing ↓
      • → 音声や動画など、サービス品質に対する要求が高いリアルタイムデータの転送では極めて重要
      • leaky bucketとtoken bucketトラフィックに特徴を持たせる
        • packetのshaping(@host OS), policing(@provider network interfaceのhardware)に使える
        • leaky bucket algorithm
        • token bucket algorithm
        • B + RS = MS → 許容可能なバースト継続時間を求める
        • token bucket algorithmにて、2つ目のtoken bucketを置き、R(tokenのたまる速度)を大幅に大きくする
        • QoSの実現
    • packet scheduling algorithm
      • ルータのリソースの割り当て
        • リソース: 帯域幅、バッファスペース、CPUサイクル
      • FIFOQoSは低い
      • RED
      • fair queueing
        • ≒ バイト単位のラウンドロビン
        • 必ずパケット単位の送信
        • 欠点: 全ホストが同一の優先度
          • → WFQ(Weighted FQ)
            • Fi = max(Ai, Fi-1) + Li/W
            • deficit(不足) round robin: packetごとにO(1)で済む
      • time stamp順のアルゴリズム
    • 許諾制御
      • 厳密な保証。フローごとに互いに独立
      • QoS routing
      • flow spec: flowのparameterの集合
    • 統合サービス: IntServ
      • a.c.a. flow-based algorithm → streaming multimediaのためのアーキテクチャ
      • RSVP(Resource reSerVation Protocol)
        • 複数送信者が複数受信グループにデータを送る
        • 受信者は自由にチャンネルを変えられ、同時に輻輳を排除
        • 帯域の予約が送信元の選択から分離
    • 差別化サービス: DiffServ
      • class-basedのサービス品質: 単純 to IntServ
      • 管理ドメイン(ISPや地域の電話会社)を形成するルータの集合で形成
        • 対応する転送規則を備えたサービスクラスの集合を定義 by 管理者
        • PHB(Per Hop Behavior)
      • 優先転送(EF: Expedited Forwarding): 最も単純なクラス
      • 帯域保証転送(AF* Assured Forwarding)

『 ソフトウェア品質知識体系ガイド(第3版)』学習メモ

第3版出版によせて

  • ソフトウェアシステムは、あらゆる社会活動の基盤であるとともに、新たな価値創造の基盤
    • 成功の鍵は品質
      • 過去の失敗や成功の経験から学び続ける
      • → 品質管理の本質をあらためて尋ねること
      • → 不確実な時代に必要な知見を新たに探ること
  • SQuBOK(Software Quality Body Of Knowledge)
    • 品質にまつわる経験や知見を体系化し、その体系へと容易にアクセス可能とするガイド
  • 第3版の改訂の要点
    • 引き続き重要なsoftware_qualityの知識体系の再整理
      • 国際規格の改訂の判定、セキュリティに代表される専門性の高い品質の知識拡充
    • 不確実な時代に不可欠なデータ駆動および価値共創における価値共創にソフトウェアの品質の考え方を取り込んだ
      • データとデジタル技術を通じたDXを進めるうえでデータ駆動および価値共創のパラダイムが根幹にあり、リスクを押さえつつその真価を最大限に発揮させるために必要な品質のマインドと技術の変革を整理
  • データ駆動は、データに基づき知的なサービスを適応的に提供しビジネスや社会上の価値を創造し続ける
    • 従来のような明確な正解に基づく計画的な品質保証よりも、目標に対し仮説的に組み上げてモニタリングし、変化に応じ改善し続ける仮説検証および探索的な品質の組み入れが重要性を増す
    • データやその源泉の規模および多様性に王子、セキュリティやプライバシー、相互運用性がより重要になる
  • 価値共創 → 能動的にあらゆる時点でモニタリングおよびフィードバックし続けるという品質の組み入れが重要

はじめに

  • SQuBOKのねらい
    • software_qualityに関する暗黙知形式知
    • 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やプロジェクトの技術レベル、プロセス、開発環境などのプロジェクト特性を考慮し、適用する技術の効果が出るように工夫が必要
      • セキュリティインシデントのようなリスクを低減させつつ、つながることによる便益を最大限にするといった要求の実現が求められている
    • 結果として得られる顧客満足
      • 顧客の予想を超えた価値の提供が重要
      • 使う人や社会の認識の変化に追従して品質要求も変わっていく
      • モノの提供によりコトをつくりだす「コトづくり」において、その本質はQOLの向上に寄与する生活イノベーション
        • 個々の生活者のライフスタイルに応じた、非物質的で精神的な豊かさを作り出すことがコトづくり
        • コトづくり: モノづくりに参加する人たち遠因に夢やロマンある目標や将来像を明示し、その実現のためにみなが奮い立ち、情熱を持って、力を合わせて働きたくなるような仕組みや仕掛け、システムを組み込むことでもある
        • → 提供側の満足も引き出す
    • ICTの進展に伴ってIoTやAIの適用が拡大するにつれ、品質に対する要求はますます多様な広がりと深さを増す
      • IoTでは、セキュリティ、セーフティ、信頼性に加えて、プライバシーやレジリエンス(跳ね返る→前の位置に戻る、中止する)などが重要な特性
      • AI では、AIの予測精度だけでなく、利用目的に応じて、公平性、説明可能性、プライバシー、信頼性、セキュリティ、セーフティなどさまざまな特性が求められる
    • → 幅広い要求を説明する用語として、Trustworthinessが使われるようになった
  • 企業と品質のソフトウェア
    • 企業の視点からの品質の意味
    • どのような経営環境の変化にも的確に対応し、顧客からの高い評価を受け続けることで、持続的な経営ができる
    • 経営の要素として、ヒト、モノ、カネ、情報
      • DXにより企業の経営スタイルやビジネスモデルは変革期にある
    • ソフトウェアシステムは社会基盤として極めて重要な位置づけとなった
    • 社会生活を支えるうえで求められる品質は多岐にわたり、継続的な維持と時代に合わせた変革が必要
    • サービスの価値が利用体験の中で便益を享受したものが独自に見出すものであることから、企業と顧客の価値共創が品質の要となる
    • このように、ソフトウェアの位置づけの変遷、価値の認知や送出スピードの変化を的確に把握して、製品やサービスの品質を考えることが肝要
  • software_qualityに関する用語
    • 序章のError, Fault, Failureの部分
    • 機能性欠陥は、障害の定義に該当し、故障を引き起こす
    • 発展性欠陥は、コードの読みやすさや構造などに起因し、コーディングルールなどの組織標準との乖離(anomaly)に相当する
      • 保守工数の増大や機能性欠陥の誘発へとつながるものの、必ずしも故障を引き起こさない
      • 開発途中の障害には発展性欠陥も含める
  • S-KA: 品質の定義(品質の考え方の変遷)
    • 製品の物質的性質や仕様適合を重要視する考え方から、提供された製品に対する顧客の心理的な受け止め方や顧客満足を重要視する考え方へと変化している
      • 経済学の「効用」など
    • T: 海外の品質の定義
      • 「品質は誰かにとっての価値である」など
    • T: 日本の品質の定義
      • 魅力的品質一元的品質、当たり前品質
      • ニーズにかかわる対象の特徴の全体像という考え
        • 品質は、製品やサービスの提供側ではなく顧客の価値基準で決まる
    • T: 品質とdependabilityの定義
      • dependability: 広い意味の品質に関わる概念
        • 特に時間軸上の品質問題を意識しており、時間の経過に伴う使用状況の変化や、利用に伴うシステムの経年劣化や摩耗部品の交換修理といった概念と関係する
        • 保全性はdependabilityの重要な構成要素
  • 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の一部」と定義
        • 活動内容について、信頼感を付与するために証拠をもって示すよう要求
      • 国や地域によって意味が異なる
        • 日本では、顧客満足のための活動を総称する意味で使うことが多く、活動内容の実証を必ずしも重視していない
          • 顧客が満足したという結果をもって、品質保証活動の成果を測るような考え方
          • → かなり広い意味を持っている
          • 顧客が安心、満足、長く使用できることを目的として品質保証が実施されるようになった
            • 品質保証書つきでないと売れない時代
        • 欧米では、契約社会という文化的背景から、品質保証していることの「実証」を重要視して発展してきた
        • ISO 9000と日本流どちらの解釈でも、品質保証を顧客満足を目的とした活動と位置づける点は同じ
      • 方法は、プロセスのアウトプットであるプロダクトの品質を直接確認する方法と、プロセスの実行状況を監視することで品質が確実に作りこまれていることを確認する方法がある
        • これらを、要求品質レベルに応じて組み合わせて実施することが大切であり、どちらかに偏っては不十分
        • 不適合品の生成を減らす必要もあるし、不適合品を検出する必要もある
        • プロダクトとプロセスの両面から品質を確認することが肝要
        • そのほか、V&Vや測定などの品質保証のための重要な手法も、要求品質レベルに合わせて実施する
    • S-KA: 改善の考え方
      • 改善: 市場や事業環境の変化へ効果的に対応する自己変革のメカニズム
      • 目的を効率よく達成するためのすべての活動がマネジメント
        • 改善はそのための武器
      • 目的に対して、より効率よく達成するための方法を模索し、不備を明確にして自己を変えていく、論理的かつ体系的は修正が改善
        • 基盤となる標準が必要
        • → 組織の経験やノウハウを標準として整理し、その標準を出発点として不備を明確化し、修正する
      • ISO 9000では、改善を「パフォーマンスを向上するための活動」、継続的改善を「パフォーマンスを向上するために繰り返し行われる活動」、革新を「価値を実現するまたは再配分する、新しいまたは変更された対象」と定義して区別している
        • 本来の改善は、それぞれの意味を含む
      • 急激な社会変化に対応するためには、抜本的な改善や革新を含めた「改善」が必要
      • T: PDCA
        • 計画では、目的、目標、狙いを明確にし、目的達成のための手段や方法を決定する。そして管理項目を決め目標値を設定する
        • 実施では、管理項目のデータを取りながら計画を遂行する
        • 確認では、目標達成にかかわる進捗や対応状況を、データをもとにして論理的に判断する
        • 処置では、目的あるいは目標と実施の結果に差があるかを見て、その差に応じて対処し、次の計画に結びつける
        • OODA
          • 指揮官のあるべき意思決定プロセスを理論化したもの
          • スピードと柔軟性を重視し、ループを高速で回して意思決定を繰り返す
          • 計画の代わりに観察から始まるので、状況に応じて臨機応変に意思決定できる
      • T: 改善(KAIZEN)
        • 現状の不備を明確にして、その不備を論理的かつ体系的に修正する活動
        • 目的: 品質、コスト、納期の向上を含む総合的なsoftware_qualityを達成すること
        • 全員参加かつ継続的な活動
        • すべての人がプロセスオーナーの意識
          • 責任感と自負心の向上を促す
          • → 組織全体で自律的に不備を修正
          • ↑ 常に変化する事業環境や市場に対応するための重要な施策
        • ソフトウェアでは細かいミスにより致命的な結果を招くことがあるので、改善(KAIZEN)は重要
          • 常に新しい技術やサービスが生み出される市場でもある
        • ツールとして、QC_circle活動
        • TQM(Total_Quality_Management)の中核
  • 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をソフトウェアの開発プロセスに提供することで、セキュリティ上の脅威に対して有効かつ整合の取れたセキュリティ機能を実装し、要求に応じた脆弱性への対応レベルを満たすための保証を実現する
          • 実現した保証の度合が国際的な水準を満たしているかどうかを明らかにする
        • 方法
          • 開発するソフトウェアのセキュリティ評価にCC/CEMを適用する一般的な方法
            • そのソフトウェアに適用すべきPP(Protection_Profile)の有無を確認の上、保証のレベルと評価対象の範囲を特定
            • CCを参照し、保護資産、脅威、セキュリティ目標、セキュリティ機能要件、セキュリティ保証要件、および要件の実現方法を定義するST(Security_Target)を作成する
            • ソフトウェア開発において、STに従ってセキュリティ機能を実装するとともにCC/CEMを参考として実装の各プロセスである開発、ガイダンス、ライフサイクルサポート、テストおよび脆弱性への対応に係る保証手段がSTで定義したレベルを満たすことを保証するエビデンスを作成する
            • ITセキュリティ評価認証制度を利用する場合、認証申請手続きとしてST を認証機関に提出後、第三者評価機関による評価を受け、評価結果について認証機関の確認を経て、そのソフトウェア製品に対する認証書を取得する
        • 効果
          • ソフトウェア開発において、セキュリティ要件を英利子、具備すべきセキュリティ機能と実施する保証手段の妥当性を国際基準に基づき自己評価するために役立つ
          • ITセキュリティ評価制度の評価及び認証プロセスを通して、セキュリティ機能と保証手段がセキュリティ要件を満たしているかどうかを明らかにできる
          • STおよびこれにもとづく保証がCC/CEMを満たし、要件に対して顕在化する脆弱性が存在しないことが本評価および認証プロセスで確認された場合、対象製品のCC 認証を取得でき、CC認証製品であることが求められる調達に参加できる
          • STおよび評価結果は、製品の購入を検討する利用者が、その製品が利用者の使用用途に対して十分なセキュリティ機能性を具備しているか、仕様に当たって残存するセキュリティリスクを許容できるかを決定するために役立つ
        • 留意点
          • CC/CEMは随時更新されるため、評価を受ける場合に有効なバージョンを確認する必要がある
      • T: ISMS(Information_Security_Management_System)
        • その組織が自身の情報セキュリティを確保し維持するために、継続的に運用する枠組みのこと
        • 範囲: 組織全体にわたってセキュリティ管理体制を構築し、監査することと、リスクマネジメントを実施すること
        • JIPDECが日本国内におけるISMSの適合性評価制度の確立と普及推進を実施している
        • 目的
        • 方法
          • 参考規格が記載されている
        • 効果
          • ISMSを構築し運用することで、その組織は一定のセキュリティ管理レベルを維持できる
          • 認証を受けた場合、取引先などに対し、情報セキュリティについて一定レベルの管理ができていることを示せる
        • 留意点
          • メリットとデメリットの整理が必要
  • 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)
        • 自動車業界の標準として要件抽出、システム要件分析、システムアーキテクチャ設計などのシステムエンジニアリングプロセス群や、ソフトウェア要件分析、ソフトウェアアーキテクチャ設計などのソフトウェアエンジニアリングプロセス群などが定義されている
        • 目的
          • 車載システムの開発プロセス定量的に測定し、プロセスアセスメントやプロセス監査を見える化し評価することで、プロセス改善につなげる
        • 方法
          • PRM、測定の枠組み、PAMを用いてアセスメントを行い、プロセスの能力レベルを判定する
        • 効果
          • 車載システム開発のプロセスに対して、客観的証拠に基づくアセスメント結果を提供できる
        • 留意点
          • ほかのプロセス評価モデルでのアセスメントと同じ
      • 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と連携して、テストプロセスを段階的に構築する
        • 方法
          • CMMIと同様に5段階の水準とそのゴールで構成されている
          • 各水準は以下で構成されており、アセスメントをサポートするためのTMM-AM(TMM Assessment Model)を持つ
            • 成熟度ゴールのセット
            • 成熟度ゴールを支援するサブゴール
            • アクティビティとタスクとレスポンジビリティ
        • 効果
          • CMMIのようにトップダウンアプローチによる段階的なプロセス改善をするため、組織的、かつ、体系的にテストプロセスを改善できる
        • 留意点
          • CMMI同様、自組織のプロセスに当てはめて解釈したうえで、段階的に改善活動を行うと〇
          • そのための専任者や専任グループを確保し、改善を先導すると効率的
          • TMMiの推進はCMMIの導入が前提となっており、日本での適用報告例が限られている
    • 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
        • 継続的・組織的なソフトウェアプロセス改善のライフサイクルモデル
        • 多人数かつ多様な役割を持つステークホルダーが係る複雑なソフトウェアプロセス改善のための、具体的で段階的な指針を与える参照モデル
        • 目的
          • 新しい開発技術、プロセス、技法の導入といったプロセス改善を効率的に実施するための、体系的なフレームワークを提供
        • 方法
          • Initiating
            • 現在の開発スタイルを変えるべき理由を示す
            • 何を対象に改善するか決定
            • 改善活動のスポンサーを確保し、人材などの改善活動のインフラを手配する
          • Diagnosing
            • 現在の状態と目標の状態のギャップ分析
              • CMMIのモデルを参考にする
            • 分析結果から、目標達成に向けて取り組むべき作業項目を示す
          • Establishing
            • 作業項目の優先順位を決め、その実施方法を検討し、詳細な作業計画を検討
          • Acting
            • 具体的な改善案を提案し、まずパイロット環境で試行
              • この結果から改善案を改良し、実環境に適用
          • Learning
            • 改善結果を分析して評価し、今後実施すべき作業項目を整理する
        • 効果
          • PDCAに比べて手順が詳細に示されているため、プロセス改善を進めるうえでのロードマップが得られる
          • プロセス改善を計画する際のフレームワークとして利用できる
      • T: PSP(Personal Software Process), TSP(Team Software Process)
        • 目的
          • 技術者個人、およびチームのQCDにかかわる見積もり精度、生産性、成果物の質を向上
        • 方法
          • PSPに従い、各技術者が、開発規模、工数、技法、検出障害数などを自分自身で見積もる
            • 完了後に見積もりと実績を比較して、自己改善を図る
          • TSPで述べられているチームにおける各自の役割を理解してチームでプロジェクトを実施
        • 効果
          • PSPによって個人の能力向上を追求する技術者が自己改善できる
          • 生産性および品質が向上し、技術者の式が向上するなどの効果
          • TSPによって、チーム開発経験のない技術者に、ポイントを知らせる
        • 留意点
          • データ収集時間
          • 収集データの扱い
      • T: 企業などで考案された改善技法
        • ソフトウェアプロセス改善は当初、QCサークルの適用やTQC、TQMなどの品質管理手法をそのまま取り込み、問題解決型のアプローチで改善するのが主流だったが、その後ソフトウェアプロセス評価モデルによる評価結果を活用した改善にシフトした
  • KA: 検査のマネジメント
    • 検査活動の主眼は、製品を顧客に提供してよいかどうかの合否判定にある
    • 検査部門、または品質保証部門と呼ばれる組織での実施が多い
    • 顧客の立場に立ち客観的な視点で検査を行う必要がある
    • 開発の途中段階から品質把握に努め、適宜、開発部門に品質向上策を推進させる必要がある
      • 品質上の問題を後工程に持ち越さないための工夫が必要
    • 検査計画
      • 方針、体制、方法、検査環境および日程などの基本的な計画を明確にし、検査計画書を作成する
        • ドキュメントの検査や製品の検査内容を盛り込む
        • 過去の検査実績を十分把握して計画に反映する
      • 関係部署とのレビューを行いステークホルダーに事前に明示
      • 計画との照合、フィードバック
    • ドキュメントの検査
      • レビュー結果が設計書に確実に反映されていることの確認も必要
      • ユーザマニュアルは、設計書と矛盾がないか、ユーザが理解しやすく読みやすい文章になっているか検査
    • 中間品質監査
      • 各開発工程の完了時に、次工程に向けてドキュメントなどの中間成果物や製品の品質が確保されているかの確認のために各工程の品質把握をする
      • ドキュメントレビューの結果評価による設計工程完了監査、テストでの摘出障害件数や摘出傾向の妥当性評価によるテスト工程完了監査
    • 製品検査
      • 検査部門自らが、テスト項目の設計、テストツール、テストプログラム、テストデータなどのテストジョブの作成、テスト環境の構築を行い、製品検査を実施する
      • ユーザの視点で、ユーザが製品に仕様する環境と同等の環境において実際に製品を動作させ、検証や妥当性確認を行う
      • 開発部門のテスト結果も確認して、最終的な合否を判定
    • 出荷後の活動
      • 合格と判断して出荷した製品品質に対して責任を持つ
      • 問題が生じた場合、同様の問題を起こさないよう、開発プロセスや自らの検査プロセスへフィードバックする
      • 製品品質の責任部署として、出荷後問題のとりまとめや対応を行う場合もある
  • KA: 監査のマネジメント
    • 監査: 管理対象となる活動が、組織によって選択された基準をどの程度遵守しているかを、収集した証拠をもとに、客観的、体系的に評価する活動
    • 監査の基準の前提として、その組織ですでに確立している組織規範を用いることもあれば、将来に向けて確立と定着を図る目的で、品質マネジメント規格などをもとに新しく定めた組織規範を用いる場合もある
    • 組織方針、品質規格、規準などを明示的に文書化したものを用いるのが一般的だが、多くはその組織がこれまで培ってきた知識、経験をもとにした「あるべき姿」を整理した「組織固有の考え方」を含んでいる
    • 目的
      • 監査活動による組織プロセスの改善
      • 組織内での適切な組織規範の遵守を担保することによる信頼の付与
      • プロセス遵守状況の経営者によるレビューの実施
    • 一般的な活動サイクル
      • 監査計画の立案、監査の実施、監査の記録、監査のモニタリングとレビュー
    • T: 購買先プロセス監査
      • 購入者が購買先に対して、作業プロセスが適正なものか、標準に対する遵守状況はどの程度かを確認し、必要に応じて作業プロセスの是正および改善勧告を行うこと
      • 第二者監査
    • T: ソフトウェア開発における監査
      • プロセスに焦点を当てて実施するプロセス監査および製品に焦点を当てて実施するプロダクト監査
  • KA: 教育および育成のマネジメント
    • 人材育成計画の立案と、それに従った教育および育成カリキュラムの整備、各個人の専門性の育成を管理するキャリア管理に分かれ、企業全体として取り組むべきマネジメント
    • 人材に必要なスキルおよび知識
      • ITスキル
        • スキルの見える化 → 目標が明確化、人事考課や報酬制度と結びつければ動機付け、個人としても主体的にスキルやキャリアを伸ばすためのツールとなる
      • ソフトウェア品質管理、品質保証の知識およびスキル
        • 特にソフトウェアの品質保証、品質管理に携わる人材は、企業文化の継承者の側面があることに注意が必要
        • 各企業でキャリアパスを独自に整備する必要
        • 人材情報システムでキャリア情報やスキル情報の管理・活用が求められる
    • 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)法
        • 上の技法と併せてリスク区分を用いる
          • 区分により、発見と識別の漏れがないことを期待できる
          • 内的/外的などの区分は最も簡単なもの
          • PMBOKでは、RBS(Risk Breakdown Structure)を例示している
      • 効果
        • リスクをもれなく識別
      • 留意点
        • 対象とする分野に合わせた最適な技法を組み合わせるのが〇
        • ステークホルダーの多様な知識や経験を持ちより、漏れを極力なくす
        • 外部環境の変化に応じてリスクが有効なのか、新たなリスクが識別されないかなど考慮して更新する
    • S-KA: リスク分析と算定
      • 発生原因であるリスク因子や、因子とその結果における因果関係を分析し、リスクの発生度合いや影響度合いを明らかにすること
      • 定性的な分析と定量的な分析
        • 定性的 → リスク対応への優先度設定
        • 定量的 → 影響を具体的な数値に
      • 目的
        • 識別したリスクの発生の確率や、それが与える影響を明らかにする
      • 方法
        • 定性的リスク分析では、リスクの発生確率と影響度からなるマトリクスに、識別したリスクを記入し評価することにより、リスク対応への優先順位を決定する
        • 定量的なリスク分析では、リスクの発生する確率分布にしたがってシミュレーションを実施し、decision_treeやリスクグラフを用いることでコストやスケジュールに対する影響を数値化する
          • 感度分析、インフルエンスダイアグラムなどの方法もある
        • リスク分析時にリスクの影響度を明らかにする技法としては、リスクマトリクス法やR-Map(Risk-Map)法などの技法やモンテカルロ法を用いたシミュレーション技法がある
      • 効果
        • 最適なリスク対応の戦略および方法に関する意思決定ができる
      • 留意点
        • すべてのリスクを定性的な尺度、定量的な尺度の一方で一律に評価できない
          • ステークホルダーは、各リスクの定性的な尺度と定量的な尺度のどちらを用いれば効果的に評価できるのか検討が必要
        • リスク識別と同じく、ステークホルダーの知見や経験を用いる必要がある
          • リスク分析によりリスク対応の優先順位や対処方法が決まってくることから、関係者間におけるリスク情報の共有に留意
    • 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つで構成されている
      • 目的
        • プロジェクトマネジメントに関する優れた実務慣行などを特定する
        • プロジェクトマネジメントの標準用語集とし、遂行上で関係者間の共通の理解の獲得に役立てる
      • 方法
        • 個々の実情に併せて以下の面からPMBOKの内容を適宜活用する
          • 自プロジェクトでマネジメントすべき側面とその実施内容及び作業項目を参考にする
          • 各プロセスの入出力項目を参考にする
          • 各プロセスで必要となるツールや技法などは、PMBOKで推奨しているものから選んで適用する 0 プロジェクトでのマネジメント実施経過や結果を逐次記録し、その分析結果を今後の組織のプロジェクトマネジメントに向けた知識として蓄積
      • 効果
        • 漏れのない計画を立ててこれに沿って管理を行うことで、適切で効率的なプロジェクトマネジメントができる
        • プロジェクトメンバー間はもとより、ユーザや関連組織とのコミュニケーションを円滑にできる
        • PMBOKという業界標準の知識体系に基づいてプロジェクトマネジメントが行える専門職の育成がでk理宇
      • 留意点
        • 明確なゴールの定義が難しい価値創造型プロジェクトにおいては、明確な計画策定やリスク洗い出しが困難となるため、状況に応じた高度な対応が必要になる
        • 理想的なスキルセット
          • テクニカル・プロジェクトマネジメント
          • リーダーシップ
          • 戦略的およびビジネスのマネジメント
    • S-KA: プロジェクトマネジメントに関する規格

プロジェクトレベル(個別)のsoftware_quality_management

  • KA: 品質計画のマネジメント
    • 効果的かつ適切な品質計画のマネジメント
    • 以下の事項を実施
      • 1.製品およびサービスに関する要求事項の明確化
      • 2.プロセス、製品およびサービスの合否判定に関する基準の設定
      • 3.製品およびサービスの要求事項への適合を達成するために必要な資源の明確化
      • 4.2の基準に従ったプロセスの管理の実施
      • 5.次の目的のために必要な程度の、文書化した情報の明確化、維持および保持
        • プロセスが計画通りに実施されたという確信を持つ
        • 製品およびサービスの要求事項への適合を実証
    • 品質計画書: 特定の製品やプロジェクト、契約に適用される品質マネジメントシステムの、プロセスおよび資源を規定する文書
    • コスト面から、早い段階でレビューやテストによって設計やソースコードを確認するように計画する
    • 要求品質を確保するために工数をかけ、あるいはスキルのある人を入れるなどして必要十分なコストをかける計画にすることも必要
    • 競争力のある目標を設定するためには、ベンチマーキングにより世の中の水準や別組織との比較をすることも必要
    • T: 品質計画書
      • プロセス、製品、プロジェクトまたは契約の要求事項を、製品実現を支援する作業方法および慣行に関連付ける手段
      • プロジェクト計画書の一部、レビュー計画書、テスト計画書など複数の計画書で構成されることが多い
      • 目的
        • 要求される品質の目標を設定し、それを達成するためのプロセスを定めることで、顧客満足の向上を目指す
        • 文書化することで、計画を関係者と合意
      • 方法
        • 製品に対する品質目標と要求事項
        • プロジェクトで必要とするプロセスや資源
          • アーキテクチャ、基準や規約、資源の明確化
          • 開発プロセスには、監視および測定する品質指標など、品質管理の対象が何であり、目標の達成状況をどのように評価するかというプロセスを含めると〇
        • 品質マネジメントの計画
          • 目標達成のためのレビュー/テスト/検査/監査 計画や、それらの合否判定基準を含める
          • 必要なコストとのバランスを考慮して、適切な品質目標を設定
        • 必要な記録
          • 満たしていることの実証のための必要な記録の明確化
        • 潜在的な品質不良のリスクと緩和策
          • 緩和できる程度もまた品質の一種
      • 効果
        • 品質目標を明確にして、その管理対象や達成状況の評価プロセスを定めることで、提供するソフトウェアの品質を保証し、さらにプロセスの改善に結びつけられる
        • 文書として明示することで、関係者とプロセスや目標を共有できる
      • 留意点
        • 用いるレビュー技法やテストツール、基準とするメトリクス、進捗や実行結果の管理プロセスも計画に含めると、品質目標の達成度評価やプロセスの改善を実現しやすくなる
        • 品質計画書は組織によって呼称や範囲が様々
    • T: 費用便益分析
      • 目的
        • 有形/無形の費用と便益を分析し、いずれかの考慮に偏らない、トレードオフを考慮した品質計画策定を支援できる
      • 方法
        • プロジェクトとそれらに関連するすべての費用と便益を計算して、プロジェクトの成果物を生み出す費用がプロジェクトの実行によって生み出される効果より小さいか大きいかで、プロジェクトを評価
        • 効果-費用の値が大きいプロジェクトを優先
      • 効果
        • 定量的把握
        • プロジェクト間比較
      • 留意点
        • 分析内容の確認が必要
          • 前提条件、データ、対象外の要因、技術進歩によるシステムの価値の変化
        • ほかの側面もあるので、ほかの評価技法などと組み合わせて総合的に判断が〇
    • T: ベンチマーキング
      • 種類
        • 自組織内を比較対象とするインターナルベンチマーキング
        • 競合組織を比較対象とするコンペティティブベンチマーキング
        • 業種に関係なく類似の組織機能を比較対象とするファンクショナルベンチマーキング
        • 業種に関係なくビジネスプロセスを比較対象とするプロセスベンチマーキング
      • 目的
        • ベストプラクティスと自らの業務を比較して、結果を導入することで、自組織の業務を改善・改革
      • 方法
        • ベンチマーキングを行うプロセスの決定
        • 信頼のおける比較対象とその情報源を選択
        • 比較対象と自組織のプロセスパフォーマンスを比較し、ギャップを分析して、改善のための検討を行い、指標を決定する
        • 設定した指標をもとに目標値を定めて、自組織の改善計画を立案し実行する
      • 効果
        • ベストプラクティスに基づいて自組織の目標を設定することで、業務改善・改革につながる
        • プロセスパフォーマンスが向上することで、収益などの経営指標の改善が期待できる
      • 留意点
        • 単なる比較分析はベンチマーキングではない
        • ベストプラクティスと自組織の実施方法とのギャップを分析し、プロセスを見直し、その効果を確認して改善や革新に結びつけるまでがベンチマーキング(行動を伴う必要)
  • KA: 要求分析のマネジメント
    • 要求分析の計画
      • 要求抽出
        • 発生源
        • 見落としがないように適切な抽出方法を決定し、要求を文書化し、発生源への再確認などを通じて間違いや漏れがないように留意する
      • 要求分析
        • 異なるステークホルダーから抽出された要求間の競合を解決し、システムの境界、システムとハードウェアや人などとのinterfaceを定め、システム要求からソフトウェア要求へと詳細化すること
        • 要求間の優先順位を明確化し、ユーザと合意する
        • 優先順位付け
          • 企業目標やビジネス戦略に合わせたKPIやBSCを用いることもある
        • 予算や期間の制約によっては実現しないと決める要求もあり、要求のマネジメントを始める時期でもある
      • 要求仕様化
        • ソフトウェア要求を抽出および分析した結果をステークホルダーに伝えて共有するとともに、以降の要求の妥当性確認と評価や要求事項のマネジメントのために文書化すること
        • 要求を文書にすることは、要求分析を成功させるうえで基本的な前提条件であり、文書の品質はプロダクトの品質に大きく影響する
    • 要求の妥当性確認と評価
      • 妥当性確認
        • 仕様書として文書化された要求が、もともとの要求の発生源としてのステークホルダーなどが真に求めるシステムを定義していることを確認すること
        • レビューやプロトタイピング、受入テストの検討などを通じて行われ、要求文書の誤りや間違った仮定などを見出す
      • 評価
        • 要求の明確さとリスクの抽出状況、要求間の整合性、記述の一貫性、明瞭性などを確認すること
        • レビューをなどを通じて実施(妥当性確認と同じく)
      • 要求分析の初期段階でテスト計画とテストケースを作成し、妥当性を確認することが有効
        • ↑ テストは遅い段階のアクティビティになりがちなため
  • KA: 設計のマネジメント
    • 設計: 指定された要求を満足するために、アーキテクチャ、システム要素、interface、データを定義するプロセス
    • ソフトウェア設計のアクティビティを規定した計画を定め、要求されている品質特性と顧客ニーズを満たす設計結果を得るための設計方針を決定し、設計結果が要求仕様および品質を満足しているか評価すること
    • 設計の計画
      • 設計のプロセスや方針、用いる技法、評価方法の決定
      • 開発プロセスと保守プロセスの局面で発生する
      • 以下について具体的な内容を策定
        • 品質計画書の内容に従って、設計における品質の作りこみを可能とする具体的な設計プロセスを規定し、各プロセスに対する入出力成果物の規定や成果物の記述方法を定める
        • 設計方針と設計技法の決定、設計技法の選択に対する具体的な実施方法やトレードオフとなった場合の判断基準の規定
        • 設計の評価に関して、設計成果物のレビュー、テスト、検査の実施時期や実施方法について計画
        • 設計の計画をタテル時点では、リスクの評価方法を規定したうえで、許容可能なリスクを選択・文書化し、ステークホルダー間で合意
      • 保守プロセスでの設計では、以下に留意し、上記の設計計画の各内容に反映する
        • テスト工程に向け、修正部分と非修正部分に着目し、それぞれ区別/結合して、テストやテスト結果を評価するための基準を設定
        • 新しい要求事項や修正された要求事項が、既存の要求に与える影響を評価
        • 品質改善のための重要の活動としてのリファクタリングなどの設計や実装の見直しを、いつどのように実施して結果をどう評価するかも設計計画の中で明確にする
    • 設計方針の決定
      • 設計上の技法や方法の選択を根本的に左右する基本戦略を、関係者全員が共有できるように定めておくこと
      • ソフトウェア構造に一貫性を持たせる一般的な設計方針
        • 分割と統治、段階的詳細化など
      • 設計技法の選択における考慮点
        • ソフトウェア特性(リアルタイム性やuiなど)
        • 品質特性
        • プロジェクト目標、品質目標との整合
        • 設計方針との整合
        • 設計技法の完成度、普及度
        • 開発環境の整備状況
        • 要員の確保と要員教育の教材の充実度
      • 技法
    • 設計の評価
      • 設計成果物のレビュー、テストを実施し、設計結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
      • 評価方法は、選択した設計技法や設計成果物の記法により決定
      • 評価基準の考慮点
        • 要求事項への追跡可能性
        • 外部一貫性
        • 内部一貫性
        • 利用した設計方法や作業標準の適切さ
        • 実現可能性
      • 品質目標の達成度合いは、策定した品質評価計画により評価
  • KA: 実装のマネジメント
    • 実装の計画
      • 品質要求を含む各種の要求を実現するために計画を作成すること
      • 選択する実装方法と品質要求を含む各種要求の組み合わせによって、設定すべきメトリクスや、実装前提条件、実装作業の範囲や実施順序を決定する
      • 実装計画では、実装方法に従い、WBS、品質を含むメトリクスの目標値と計画値、コンポーネントを作成して統合する順序、品質管理手順、その他を定める
    • 実装方針の決定
      • 実装方針の決定とは、実装に際して、品質要求を含む各種の要求を満たすために必要な実装ルールを設定すること
      • 考慮項目
        • 採用する言語と再利用部品の利用
          • 言語の選択は重要
            • 言語を効果的に活用するにはトレーニングとスキルが必要
          • WindowsUnixのテキストベースの構成ファイルや、プログラム・ジェネレータのメニュー式選択リストなどの利用を検討
          • 特定アプリケーション向け再利用部品の統合セットや、アプリケーションを作り上げるための各種設定について検討する
        • コーディング規約とガイド
          • 各条件から、プロジェクトに最適な規約とガイドを設定
        • 標準の利用
          • 外部標準(OMG(Object Management Group)やISOのような国際組織が規定)のソフトウェアおよびハードウェアのinterface仕様、実装言語、実装ツール、interfaceなどの利用を検討する
          • 併せて内部標準(企業単位、部門単位、プロジェクト単位などの標準)の利用を検討
          • 標準により、プロジェクト運営の負荷軽減
            • 検証の組込などへの効果も期待できる
    • 実装の評価
      • 実装成果物のレビュー、テストを実施し、実装結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
      • 基準
        • システム要求事項とシステム設計への追跡可能性
        • システム要求事項との外部一貫性
        • 内部一貫性
        • テスト可能性
        • ソフトウェア設計の実現可能性
        • 運用と保守の実現可能性
      • ウォークスルーによるコードレビューが代表的
        • 要求仕様が正しくコーディングされていることを評価
        • 規約の遵守性も評価
      • テストでは、ホワイトボックステストによるモジュールテストが代表的で、命令や分岐が正しく動作することを評価する
        • 命令や分岐の網羅性が評価基準
      • モジュールを統合してテストするときは、仕様に基づくテスト(ブラックボックステストなど)により、統合したモジュールが要求仕様どおり動作することを評価する
  • KA: レビューのマネジメント
    • レビュー: ソフトウェア開発工程全般における評価と確認作業
      • 関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性などを評価し確認する
    • デザインレビュー: 設計審査。品質保証のための合否判定の1手段
    • レビュー計画
      • 開催時期、対象成果物、レビューア、観点、適用する方法とリーディング技法、完了判断基準などのレビュー計画を、プロジェクト計画策定時に明確にする
      • 対象はソフトウェアに関する直接的な成果物だけでなく、設計方針やテスト戦略などの成果物も含める
      • 方法は、最も形式的で公式なインスペクションから、その逆のアドホックレビューまでさまざま
        • 形式的なら、側面や観点に基づいた障害検出の属人性が低減されて管理しやすくなるが、手間やリソースがかかるので、目的に応じて選択する
    • レビュー実施
      • 対象成果物が、当該プロセスのインプットの要求事項を満たすことを確認する
        • 前のプロセ腕示された要求を網羅した記述内容であることを確認
      • 曖昧性がないこと、内容や構造に矛盾、誤り、漏れがないことも確認
      • 人や組織ではなく成果物をレビューすることや、問題を指摘事項として挙げるものの解決はしなくてもよい場合があることなどを、ガイドラインとして作成しておく
    • レビューの記録
      • レビュー報告書の発行
      • → 品質記録としての意味
        • 品質保証活動の一環としてのレビューが確実に実施されたことの証拠となる
        • この記録をもとに追跡して完結したことをフォローする
      • 記録は、内容と手順をプロジェクト計画策定時に立案し、プロジェクトメンバに徹底しておく
    • レビュー実施状況のマネジメント
      • プロジェクト実行段階において、レビューが計画通りに行われていることを追跡し、指摘結果の反映確認を確実に行う
  • KA: テストのマネジメント
    • 対象のプロダクトやサービスが、プロジェクトで定義した品質を達成するために実施される、テストの活動のマネジメント
    • テストの実行で、テスト対象がプロジェクトで定義した品質レベルに達しているかを確認する
    • テストの対象に残存する欠陥がテストとデバッグにより除去されることで、テスト対象が持つ品質リスクを下げる
    • テストは、設計とは違う視点から設計を洗練させ、開発プロセス全体の品質向上にも貢献
    • 適切なテストは、十分な品質レベルにあり、残存リスクも許容レベルにあると判断された製品やサービスを市場にリリースするうえで必要であり、そのテストが適切に行われることについてのマネジメントも必要となる
    • テストは欠陥があることは示せるが、欠陥がないことは示せないという限界がある
      • テストの十分制覇、網羅性やテストの実施量、欠陥の傾向やそれらの管理グラフなどから総合的に判断する
      • 品質レベルについても、上記のようなテストに関するメトリクスや残存するプロダクトリスクなど、テストマネジメントの実施の上で得られるすべてのデータを利用して総合的に判断する必要がある
    • テスト活動に関与する組織の在り方も、テストマネジメントの成否を左右する
      • 一般的に、開発組織から独立したテスト組織によってテストを実施するとテストの効果は向上するが、開発スピードを損なうことがある
      • → 独立の度合いは、技術、管理、財務の観点から検討してテスト組織の位置づけを決める必要がある
        • 独立強
          • 技術面では、異なる視点でのテストができるため、効果up
          • 管理面では、テスト組織に出荷権限を与えることで厳格な品質保証活動が可能になる
          • 財務面では、テスト組織でのリソースの融通がしやすくなる
      • テスト組織のメンバは、各テストレベルにおけるテストタイプを考慮し、性能や使用性などのテストのスペシャリストを含めて構成が〇
      • 一般的にアジャイル開発では、開発担当やテスト担当が1つのチームで一体となって開発することが多く、単独のテスト組織は存在しない場合がある
    • テストに関する標準や規格への適合が重要になってきている
    • プロジェクトマネジメントの1要素でもあるので、ステークホルダーとの調整が不可欠
      • 用語の統一も重要
      • → ISTQBが発行しているGlossaryが使える
    • S-KA: テストプロセス
      • テストアクティビティを具体化するときは、ソフトウェア開発ライフサイクルの諸活動やさまざまなステークホルダーの存在を識別したうえで、ソフトウェア開発のプロセスと連携したテストプロセスの形成が必要
      • 目的
        • ソフトウェア開発のプロセスと連携した、効果的なテストプロセスを形成する
      • 方法
        • ソフトウェア開発のプロセスに対応付けたテストのプロセスモデルであるV字モデルやW字モデルを参考にテストプロセスを策定
        • V字モデル
          • ウォーターフォールモデルにおける各工程に対応するテストレベルを示すためのモデル
          • V字の左側を品質を作りこむ過程、右側を品質を確認する工程と呼ぶこともある
        • W字モデル
          • 開発プロセスの早期段階からテストプロセスを開始することを表現するために考案された
          • 開発プロセスのV字とテストプロセスのV字が並行して進む様子
          • 上流工程でテストの計画や設計を行うことで、開発工程の成果物のレビューが行われ、さらにテスト容易性などの観点から評価とフィードバックが行われる
      • 効果
        • ソフトウェア開発プロセスと対応付けたテストプロセスを策定することで、各テスト工程の設計の元になる情報やテスト対象範囲を明らかにできる
        • W字モデルの導入により、上流工程からの品質の作りこみ、開発とテスト準備作業の並行性向上(ひいては短納期開発)、テストエンジニアの知見の活用、テストしやすいソフトウェア開発の促進が期待できる
      • 留意点
        • 開発プロジェクトが採用するプロセスモデルによってテストレベルの数が決まる(固定的ではない)
        • W字モデルにおいて、テストの計画や設計の作業を通じて、上流工程で要求や設計の問題点を検出してフィードバックするには、相応の技術力が必要
          • 経験の浅いテスターが上流工程で単にテストケースを作成するだけではW字モデルの効果は得られない
    • S-KA: テストの構造
      • 目的
        • テストの構造を明確にすることで、テストのマネジメントを容易にする
      • 方法
        • テストレベル
          • 単体テスト
            • モジュールやクラスなど独立してテスト可能な部分のテスト
          • 統合テスト
            • モジュールやクラス間のinterfaceのテスト
          • システムテスト
            • 機能の組み合わせに着目したテスト、パフォーマンスなどの非機能要件に対するテスト、ビジネスプロセス、ユースケースなどに対するテストを実施
          • 受入テスト
            • 顧客やユーザにより、システムの全体や一部、また非機能要件に対するテストを実施
            • UAT, 運用受入テスト、αテスト、ベータテストなど
        • テストタイプ
      • 効果
        • テストの構造を決めることで、対象や範囲を整理して、目的に沿ったテストを設計でき、段階的、体系的にテストを進められる
      • 留意点
        • テストレベルの種類や数は、プロジェクトが採用するプロセスモデルや開発スケジュールなど、そのプロジェクトの特徴に応じて設定する
        • テストタイプは具体的なテストケースを示すものではないので、テストタイプの主旨に沿ってテストの詳細の設計が必要
    • S-KA: テストの計画と遂行
      • 目的
        • プロジェクトにおけるテストの目的やプロセス、ゴールとそれに至る手段、リスク、テスト環境を明確にして実現可能な実施計画を作成し、テストを遂行する
      • 方法
        • 開発プロジェクト発足後、プロジェクト計画策定とほぼ同時期に、開発ライフサイクル全体を包括するものとしてテスト計画を策定する
        • 策定時は、プロジェクト計画で策定された目的、戦略と戦術、スケジュールや耐性、環境、リスクとその対策などを勘案し、最終的に全体計画となるマスターテスト計画書、テストレベルに応じた個別のテスト計画書などに記述する
        • 検討事項
          • テスト全般の内容と工数の見積もり
            • 範囲、内容、方法、体制、要員、スケジュールの定義
            • 工数見積もりは、過去や類似のプロジェクトの実績値を参考にする方法や、作業の実行者やエキスパートによる見積もりをベースにする方法がある
          • テストにかかわるリスク
            • 識別し、予防策、回避策、発生時の対策を決定
            • 適切なテスト技法やテスト対象、優先順位を決定して実施することでプロダクトのリスクに対処
            • リスクベースドテストでリスクの発生を最小限に抑える
            • リソースについてのリスク分析、マネジメントも実施
          • テスト環境
            • テストレベルに応じた機器やソフトウェアの選定と調達
            • 限界値/異常値テストが実施可能なテスト環境
            • 場所や電源など物理的リソースの確保
        • テストの遂行では、計画通りに進捗しているか品質なども含めて計画にフィードバック
          • 状況や結果に関する情報
            • テストの消化状況
            • 障害情報
            • 要求、仕様やコードに対する確認の網羅性
      • 効果
        • 実施すべき作業とスケジュール、ゴールが明確になることでテストを円滑に実施、管理できる
        • テストプロセスの進行状況の把握やテスト終了の判断、品質問題の早期発見ができる
      • 留意点
        • フィードバック要
        • リスクの定期的再評価
        • 必要な情報のみ収集、容易な収集方法
    • S-KA: テストに関する標準
      • 目的
        • 組織、テスト対象、テスト実施形態にかかわらず適用できる規格を用いてテストに関する作業を標準化する
      • 方法
        • テストに関する規格
          • 2013年にISO/IEC/IEEE 29119シリーズの発行が開始されている
          • テストに関する規格以外でもソフトウェアに対する要求事項が規定され、その中にテストへの要求事項が含まれているものもある
        • テスト技術者資格認定
          • ISTQB
            • スキルの度合い
              • Foundation, Advanced, Expert
            • テスト技術分野
              • Core, Agile, Specialist
      • 効果
        • 公的・実質的な規格により作業が一定水準で標準化できる
        • 技術者はグローバルな統一基準にもとづいて段階的にテスト技術を習得でき、開発組織は体系的に技術者を育成できる
      • 留意点
        • 規格の適用にあたっては、開発方法、プロセス、プロジェクトの特性に合わせてテーラリング
        • プロジェクトが準拠する規格によりテストへの要求事項は変わる
        • ISTQBで実施されている試験でも、JSTQBでは実施されていないものがある
  • KA: 品質分析と評価のマネジメント
    • 実行過程、実行結果や成果物に関するデータを収集、分析し評価すること
    • 留意点
      • プロダクト品質とプロセス品質の両面から評価
      • 障害件数のみでなく品質特性やプロセスの特性にも着目し、さまざまな観点で評価
      • データの分析と評価結果の使用方法を明確にする
        • 具体的なアクションやフィードバック、改善に結びつくデータ収集や分析、評価となるようにする
      • 対象範囲を明確にし、偏りや抜けのないデータとする
      • 分析と評価はCh03の技法を使う
      • 定量的に行い客観性を保持
      • 技法や評価観点を使うときは、自環境を考慮してカスタマイズ
        • 技法や観点の背景の理解が必要
    • S-KA: プロダクト品質とプロセス品質の分析と評価
      • 目的
        • プロダクト品質の分析と評価 → ユーザの視点でさまざまな側面から評価する
        • プロセス品質の分析と評価 → 開発プロセスの妥当性と一貫性の確認
  • KA: リリース可否判定
    • リリース: プロセスを次の段階またはプロセスに進めることを認めることを意味する
    • 目的
      • 実施時期に応じた目的
    • 方法
      • 判定責任者を設けて権限を明確にしておく
      • ステークホルダーやその他の関係者を含めた版tネイの体制も明確にする
  • KA: 運用および保守のマネジメント
    • S-KA: ITIL
      • 目的
        • ITサービスの提供と管理のベストプラクティスを提供する
      • 方法
        • ITサービス提供者が、自己のサービス提供と管理の仕組みをITILのベストプラクティスに照らして見直して改善を進める
        • 運用および保守のマネジメントとして、特にサービスの品質に関連の深いマネジメントプラクティス
          • 可用性管理
          • キャパシティとパフォーマンス管理
          • インシデント管理
          • 問題管理
          • リリース管理
          • サービス継続性管理
      • 効果
        • ITサービスを継続的に改善しつつ、効果的かつ効率的に提供できる運用管理を実現できる
      • 留意点
        • 改善のための手段から認証のための手段に転化しないよう、上位管理者のリーダーシップと資源確保に留意する
    • S-KA: SLAとSLM
      • 目的
        • SLAにより、サービスの内容を厳格に定義し、サービスの品質水準をメトリクスと基準値によって明示的、定量的に定義し、あいまいさを排除する
        • SLMを通じて、サービス提供者がSLAを達成する
      • 方法
        • サービス品質のカテゴリごとにメトリクスと基準値を設定して定義し、SLAに組み込む
        • SLMではPDCAサイクルを回す
        • SLMの主要な活動
          • サービスと目標のサービスレベルについて顧客と共通認識を持つ
          • 測定基準の収集、分析、保存、報告を通じて、組織が所定のサービスレベルを満たしていることを確実にする
          • サービスのレビューを実施して、現在の一連のサービスが組織と顧客のニーズを継続的に満たしていることを確認する
          • 所定のサービスレベルとパフォーマンスの比較など、サービスに関する課題を補足して報告する
      • 効果
        • SLAにより契約したサービスの内容と品質水準に関する認識の相違や誤解を防止できる
          • 文書化されていないとき期待水準が拡大してしまうが、これを制御できる
        • SLMによりサービス提供者がSLAを安定的に達成
      • 留意点
        • SLAは単なる運用上の測定基準ではなく、所定の成果に関連が必要
          • 顧客満足度や主要な事業成果などの測定基準をバランスよく組み合わせて実現する
        • SLMでは、SLAに合意したサービスの内容と品質を正しく表す、客観的で自動計測可能なメトリクスと基準値を用いると〇
    • 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: プロセスメトリクス
  • KA: モデル化の技法
    • S-KA: 離散系のモデル化技法
      • T: UML
      • T: SysML(Systems Modeling Language)
    • S-KA: 連続系のモデル化技法
    • S-KA: DSL
  • KA: 形式手法
    • 数理論理学に基づいて、仕様記述や検証を行うアプローチの総称
    • S-KA: 形式仕様記述の技法
    • S-KA: 形式検証の技法

工程に個別なソフトウェア品質技術

  • KA: 要求分析の技法
    • S-KA: 要求抽出
    • S-KA: 要求分析
      • T: 機能要求分析
      • T: 非機能要求分析
      • T: 品質機能展開
      • T: 要求可変性分析
    • S-KA: 要求仕様化
      • T: ソフトウェア要求仕様
      • T: USDM
    • S-KA: 要求の妥当性確認と評価
  • KA: 設計の技法
  • KA: 実装の技法
  • KA: レビューの技法
    • S-KA: レビュー方法
    • S-KA: 仕様やコードに基づいた技法
    • S-KA: フォールトに基づいた技法
    • S-KA: リーディング技法
  • KA: テストの技法
    • S-KA: テスト設計技法
      • T: 仕様に基づいた技法
      • T: コードに基づいた技法
      • T: 経験と直感に基づいた技法
      • T: フォールトに基づいた技法
      • T: リスクに基づいた技法
      • T: 利用に基づいた技法
      • T: 組み合わせの技法
      • T: コード解析技法
    • S-KA: テスト自動化技法
  • KA: 品質分析と評価の技法
    • 目的: 解析、見える化、予測、フィードバックと根本原因分析により、結果として製品の品質を高めること
    • S-KA: 信頼性予測に関する技法
      • T: ソフトウェア信頼性モデル
      • T: Fault-Prone分析
        • Fault-Proneモジュール判別モデルと呼ばれる数学的モデルを使う
    • S-KA: 品質進捗管理に関する技法
      • T: 工数・成果モデル
        • 工数指標と発見障害などの成果を組み合わせたマトリクスを作成し、座標位置によりプロセス品質を把握する技法
      • T: Rayleighモデル
        • ソフトウェア開発プロセスのすべてにおける障害率を表したモデル
        • m=2のWeibull曲線の特別な場合
        • 目的: 出荷後の障害率を見積もるなどできる
      • T: PTR(Problem Tracking Report)サブモデル
      • T: その他の品質進捗管理に関する技法
    • S-KA: 障害分析に関する技法
      • T: ODC(Orthogonal Defect Classfication, 直交欠陥分類)
        • 目的: 今後予測される障害の顕在化を抑制
        • 効果: 障害管理に工夫を加えることで、プロジェクト進捗の健全性、開発プロセスの実施内容の十分性の全容が把握でき、早期に異変の察知と改善策の実施が可能になる
      • T: バグ分析
    • S-KA: データ解析と表現に関する技法
      • 収集したデータや分析結果を分かりやすく表現することで、論理的思考や数値的分析を必要とする作業や問題解決などに用いる技法
      • T: QC7つ道具
      • T: 新QC7つ道具
      • T: その他の統計技法
  • KA: 運用と保守の技法
    • S-KA: 運用の技法
      • T: ソフトウェア若化(software rejuvenation)
        • 経年劣化の未然防止
    • S-KA: 保守の種類と技法
      • T: 保守の種類
        • 是正、予防、適応、完全化
      • T: 保守の技法
        • 理解と解析、拡張と変更

Ch04 専門的なソフトウェア品質の概念と技術

  • KA: ユーザビリティ
  • KA: セーフティ
    • S-KA: セーフティの品質の概念
      • 本質安全
        • ハザードを取り除く性質
      • 機能安全
        • ハザードにより危害に至らない性質や危害を回避できる性質
      • リスク評価
      • セーフティを最優先する組織文化
    • S-KA: セーフティの技法
      • T: セーフティ実現のためのリスク低減技法
      • T: セーフティ・クリティカルシステムのテスト
    • S-KA: セーフティ・クリティカル・ライフサイクルモデル
      • 安全性解析
      • 開発
      • 安全妥当性確認
      • T: 電気・電子・プログラマブル電子安全間連携の機能安全
      • T: 自動車-機能安全
      • T: 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス
  • 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における品質
    • S-KA: AIにおける品質の概念
      • 訓練データとテストデータの品質
      • モデルの品質
      • 機械学習を用いたシステムの品質
    • S-KA: AIシステムの品質マネジメント
      • PoC(Proof of Concept)という試験的で探索的なプロセス
    • S-KA: AIシステムの品質技術
      • モデルの性能指標以外の品質技術については、2020年時点では発展途上で、アプリケーションへの依存度が高い
      • T: 疑似オラク
      • T: メタモルフィックテスティング
      • T: 頑健性検査
      • T: ニューロンカバレッジ
      • T: 説明生成
  • KA: IoTシステムにおける品質
    • IoTは、従来のシステムが扱っていたサイバー世界にとどまらず、モノやヒトなどの物理世界とともに密に連携するシステムインフラ
    • 類似語: CPS(Cyber-Physical-System)
    • S-KA: IoTシステムにおける品質の概念
      • T: IoTセキュリティ
        • エッジに含まれるセンサーとデバイスのセキュリティが、IoTセキュリティを特徴づける
      • T: IoTプライバシー
    • S-KA: IoTシステムの品質マネジメント
      • 表5.2.1: IoTシステムの運用と保守におけるリスクと注意点
    • S-KA: IoTシステムの品質技術
      • T: IoTセキュリティ技術
        • 表5.2.2: IoTセキュリティベストプラクティス
          • バイス、ネットワーク、IoTシステム全体
      • T: IoTプライバシー保護技術
  • KA: アジャイル開発とDevOpsにおける品質
    • S-KA: アジャイル開発とDevOpsに置ける品質の概念
      • T: アジャイル開発の品質
        • 設計と同時にテスト
        • 自動化
        • 変更容易性
        • 開発チームの自律性を尊重
      • T: DevOpsの品質
        • 表5.3.1: DevOpsにおける品質特性と意味
    • S-KA: アジャイル開発とDevOpsの品質マネジメント
      • T: 伝統的なQA(Quality Assurance)からAQ(アジャイルクオリティ)へ転換
        • 表5.3.2 QA to AQ 主要パターン
      • T: アジャイルスキル体系
        • ITSS+やSFIA(7)から、必要なスキルが分かる
      • T: コミュニケーション管理
    • S-KA: アジャイル開発とDevOpsの品質技術
      • T: アジャイルメトリクス
      • T: 品質ダッシュボード
      • T: アジャイル開発とDevOpsのツールと自動化
        • 表5.3.3: アジャイル開発とDevOpsを支えるツールを形成する要素
          • 抽象化、自動化、共通化、CI、モニタリング
      • T: プルリクエスト駆動開発
      • T: CI
        • → さらに発展ならCD
          • 本番ソフトウェアの作成や本番システムへのデプロイも対象になる
      • T: アジャイルテスト
        • 顧客価値を継続的に向上させることを念頭に置いたテスト技法
      • T: 継続的テスト
      • T: シフトレフトテスト
        • 開発の早い段階から
      • T: シフトライトテスト
        • 本番環境に入った後に実施するテスト
      • T: カオスエンジニアリング
        • 本番環境で、将来の可能性あるイベントに対処できるかどうか確認できる
      • T: カナリアテスト
  • KA: クラウドサービスにおける品質
    • クラウドサービスプロバイダ、クラウドサービスカスタマー
      • クラウドサービスカスタマーは、サービスプロバイダとエンドユーザを含む
    • S-KA: クラウドサービスにおける品質の概念
      • クラウドサービスの機能面は、クラウドサービスプロバイダから提供される文書を用いて機能適合性を確認する必要
      • 非機能面は、提供されるSLAを確認
      • セキュリティも重要な確認事項
      • T: クラウドサービスの機能適合性と互換性
      • T: クラウドサービスのSLA
        • SLO
        • SQO
      • T: クラウドサービスのセキュリティ
    • S-KA: クラウドサービスの品質マネジメント
    • S-KA: クラウドサービスの品質技術
      • クラウドネイティブ: クラウド上での利用を前提として設計されたシステムやサービス
      • マイクロサービスを利用したシステムは複雑になりがち
        • → 本番環境で実験するカオスエンジニアリングで、従来の手法で発見困難な障害を検出する
      • T: 仮想化
        • 計算機、ストレージ、ネットワーク
        • 仮想化の利点を考慮した設計のソフトウェアでないと効果は限定的
      • T: マイクロサービス
        • 協調して動作する小規模で自律的なサービス
        • 目的
          • スケーラビリティを確保した迅速な機能追加や修正の能力などを持ったサービスを提供
        • 方法
          • 大きなサービスを、業務やデータの塊で互いに疎結合な複数のサービスに分割し、各マイクロサービスを小さな1つの役割に専念させる
          • マイクロサービス間のやりとりは、REST、GraphQL、gRPCなどの軽量なinterfaceであるWeb APIを公開し、それらのみでアクセスするよう構成
          • マイクロサービスごとにアジャイル開発チームを編成する
        • 留意点
          • 小さく複雑でなく改修頻度が低いシステムは、マイクロサービスに分割するデメリットの方が大きい
          • Kubernetesなどの使用
      • T: クラウドデザインパターン
  • KA: OSS利活用における品質
    • S-KA: OSS利活用における品質の概念
      • 将来性を見据えた選択と、利活用の前のOSSの品質評価が必要
    • S-KA: OSS利活用の品質マネジメント
      • OSS管理
        • 公開されているOSSの障害情報を収集し、OSSの選択や障害対応を効率的に実現するマネジメント
        • 障害情報の自動収集
        • プログラムの特徴量や、ソフトウェアの開発履歴が記録される構成管理システムの変更ログなどを用いて、潜在欠陥が混入しているモジュールを特定する手法など
        • OSSとして公開されるライブラリの脆弱性を多数記録するDB(Snyk)などを利用する
    • S-KA: OSS利活用の品質技術
      • OSS健全性評価メトリクス
        • OSSに関与する組織の健全性と持続可能性を評価する
        • マイニングソフトウェアリポジトリ分野の学術会議や産業界において指標が提案されている
        • CHAOSS
          • Dicersity-Inclusion
          • Growth-Maturity-Decline
          • Risk
            • 人的要因、ライセンス、脆弱性の観点
          • Value

『サイバーセキュリティプログラミング』学習メモ

Ch01 Python環境のセットアップ

  • pipのインストール
    • これを参照
    • aptだとpython3の方のpip3しか入れられなかった
  • github3.py
    • python -m pip install github3.py==1.0.0
    • バージョンを指定しないとSyntaxError(最新版はPython 2.7は対象じゃないらしい)
  • Wing IDE
    • ダウンロードしてdpkg -i (ファイル名)
    • Stack Data
    • Debug Probe
      • personalにはない?

Ch02 通信programの作成: 基礎

  • ネットワークを介して攻撃を行うためのツールが,target companyにはない
    • 一方,Pythonがインストールされていることはよくある
    • Pythonを足がかりにする
  • Pythonによる通信programについて
    • Pythonでserver client communicationを行うthird_partyのツールはたくさんあるが,そのすべての核となっているのがsocket library
    • socket library: TCP, UDPで通信するclient, serverのprogramを素早く書いたり,raw socketを利用したり,その他さまざまな通信programを作成したりするうえで,必要不可欠なもの
      • このモジュールを使えば,target terminalへの侵入やメンテナンスなど,必要なことはすべて実現できる
  • TCP_client
    • penetration_testでは,サービスの検査やゴミデータの送信,fuzzingやその他のさまざまなことを行うためのTCP_clientを手早く作ることがたびたび必要になる
      • 制約によっては,コピペやネット接続すらできないこともある
    • 重要な仮定
      • このスクリプトを使った接続は常に成功する
      • 接続先のサーバが常にデータを先に送ると想定している
      • 接続先のサーバはいつでもうぐさまデータを返信してくる
  • UDP_client
    • TCP_clientとほとんど変わらない
      • socket type がSOCK_DGRAM
      • sendtoのみ(connect()は不要)
  • TCP_server
    • 簡単なコードだが,Netcatの自作やTCP proxyの作成を行う以降の節で拡張していくことになる,便利なコード
  • Netcatの置き換え
    • Netcatは攻撃者にとって非常に便利なツール
    • Web applcationに対する攻撃で侵入したときは,侵入に成功した後の接続経路を確保したいと考える
    • subprocess library
      • process generateで役立つinterface
      • processを立ち上げたり子processとやりとりしたりするのに利用される
      • このコードでは,渡したコマンドをそのままローカルのOSに渡して実行させている
        • 実行結果はサーバに接続してきているクライアントに送信する
        • 例外処理では,一般的なエラーを補足し,コマンド実行が失敗したことを伝えるメッセージをクライアントに送るようにしている
    • ファイルのアップロード,コマンド実行,コマンドシェルの実行を行う処理を実装
    • 試してみる
      • サーバとして動作するスクリプトUnixホスト上で動作しているため,SSHでログインしているときやUnixホストのローカルで作業をしているときにコマンドを実行しているかのような出力になっている
      • 技術的にはまったく高度ではないが,Pythonで複数のclientやserverのソケットを一度にハックして悪さしようとするときの基本的なやり方
  • TCP_proxyの構築
    • toolboxにTCP_proxyを入れておくべき理由
      • あるホストから別のホストにデータを転送したり,ネットワークを利用するソフトウェアの検査をしたりといった作業に必要になる
    • 詳細がわからないプロトコルを解き明かしたり,applcationに送る通信データを改変したり,ファジングテストのためのデータを作ったりといった,様々な場面で使える簡単なPythonのproxy script
    • proxy_handler()
      • response_handler()の中で,パケットの書き換え,ファジングテストの実施,認証における問題のテストなど,リモートから受信したパケットに対してやりたいことをなんでも実施できる
        • request_handler()も同様
        • 認証情報が平文でやりとりされるapplcationの通信で,一般ユーザの情報の代わりに管理者の情報を送ることで権限昇格を試みるときなどに便利
    • hexdump()
      • 16進数表記およびASCIIの表示可能文字で画面に出力する関数を作る
      • 詳細がよくわからないプロトコルを解き明かす場合や,平文でやりとりされるプロトコルにおいてユーザの認証情報を取得する場合など,多くの場面で役立つ
    • 試してみる
      • 内容と返還後の文字列が表示される
  • Paramikoを用いたSSH通信programの作成
    • 検知から逃れるために通信の暗号化が〇
    • ParamikoというPyCryptoを使ったlibraryを使えば,SSH2 protocolを簡単に扱える
    • 実装
    • SSHサーバに接続して複数のコマンドを実行させたり,複数のSSHサーバに接続してコマンドを実行させたりできる
    • Windowsには誰でもすぐに使えるSSHサーバは備えられていないので,独自に作ったSSHサーバからSSHクライアントにコマンドを送るようにする必要がある
    • 試してみる
      • コマンドがSSHサーバに送られ実行され,結果をサーバ上で表示
  • SSH_tunneling
    • 目的: SSH clientで入力されたコマンドを遠隔地のSSH server上で動かすこと
    • SSH_tunnelingを使う場合,送信データはまとめられてSSHで送信され,SSHサーバ上でその中身が取り出され,サーバの処理に引き渡される
    • 状況
      • internetを介してアクセスできるSSH_serverがあり,そのSSH_serverと同じネットワーク内にあるWebサーバにアクセスしたい
      • Webサーバに直接アクセスはできないが,SSH_serverからはアクセスできる
      • SSH_serverには使いたいツールがインストールされていない
    • → 手段1: SSH_forward_tunneling
      • ssh -L 8008:web:80 justin@sshserverというコマンドを実行すると,justinというユーザでSSH_serverに接続し,ローカルシステムの8008番ポートの準備が行われる
    • 多くのWindowsシステムではSSH_serverが動作していないが,そのような状況でも,SSH_tunnelingを逆向きに設定することで解決できる
    • → 手段2: SSH_reverse_tunneling
      • reverse_forward_tunnel()
        • transport()
          • 暗号化された接続の作成や設定
        • channel
          • 暗号化されたセッションを通じてデータの送受信を行うためのソケットのようなもの
    • 試してみる
      • Windowsの環境からSSH_serverとの接続を確立し,そのサーバの8080ポートを待機状態にする
        • 8080ポートへの通信はWebサーバの80番ポートに転送される
        • Linuxでブラウザからhttp://127.0.0.1:8080にアクセスすると,SSH_tunnelを通じてWeb_serverに接続することになる
    • SSHSSH_tunnelingを理解し,利用するのは重要
      • 使いどきや使い方の把握
    • Paramikoを使えば既存のPythonツールにSSHの機能を追加できる
  • まとめ
    • とても単純だが非常に役立つツールの作成
    • 目標: penetration_testを行うときや攻撃が成功した後の活動を行うとき,バグ探しのときなどに使うツールを作成するのに十分な,Pythonのネットワークプログラミング技術を身につけること

Ch03 network: raw_socketと盗聴

  • network_sniffer: target machineが送受信するパケットの観測を可能にするため,攻撃の前後でよく利用される
  • network通信を観測したりでコードしたりするスニッファーを即席で作る方法を知る
    • 手軽で成熟したツールに関して深い理解
    • Pythonの新しいテクニックの学習
    • 低レイヤーのネットワークの動きを理解
  • 生のIPヘッダやICMPヘッダのような低レベルのネットワーク情報にアクセスするには,raw socketを使う
  • UDPを用いたホスト発見ツールの作成
    • target networkで動作中のホストを発見するUDPベースのスニッファーの作成
    • 攻撃者は事前調査を行ったり,攻撃対象を絞り込んだりするために,ネットワーク上に潜むすべての標的を見つけようとする
    • 特定のIPアドレスでホストが稼働しているか判断するために,UDP portにパケットが届いた時の処理方法を利用する
      • 一般的には,UDPデータグラムをホスト上の閉じたポートに送ると,当該ポートに到達できないことを示すICMPメッセージが返信される
      • UDPデータグラムに対する応答を受信できなければ,ホストは存在しない
      • ICMPメッセージを受信できる → ホストが稼働していることを意味
    • UDPを選ぶ理由: overheadなし
    • scannerで,発見したすべてのホストに対してNmapによる完全なポートスキャンを開始させるような処理の追加もできる
  • WindowsLinuxにおけるパケット盗聴
    • 試してみる
      • pingを実行したときのrequestをキャプチャ
  • IP_layerのデコード
    • ctypes構造体の定義
    • protocolとIPアドレスを読みやすい形式に変換
    • 試してみる
      • IPヘッダがデコードされる
  • ICMPのデコード
    • type=3: 宛先到達不可能クラス
    • code=3: ポート到達不可能エラーが発生
    • 元のデータグラムの先頭8バイトがICMPメッセージに含まれるため,照合できる
    • netaddr libraryを使うコードを追加し,ホスト発見用のスキャンをサブネット全体に対して実施できるようにする
      • netaddr module
        • subnet maskを入力として受付,適切に処理
        • subnet, addressをとても簡単に処理できるようになる
    • 試してみる
      • 対象のサブネット内をスキャンできる

Ch04 Scapyによるネットワークの掌握

  • e_mailの平文の認証情報の窃取,同一ネットワーク内の通信を傍受するための標的マシンに対するARPポイズニングの体験
  • Scapyのpcap処理を拡張してHTTP通信から画像を切り出し,その画像に人が含まれているかを判断するために顔検出を行うデモを実施
  • e_mailの認証情報の窃取
    • Scapyのinterfaceを使って,パケットを傍受しその内容を詳細に分析する方法を見る
    • SMTP, POP3, IMAPの認証情報を窃取する簡単なスニッファーの構築
      • あらゆるprotocolに適用できる
    • ARP_poisoningによる中間者攻撃(MITM)を組み合わせて,ネットワーク上のほかのマシンから容易に認証情報が窃取可能なことを示す
    • sniff()
      • 傍受用の関数
      • store=0: Scapyはメモリ上にパケットを保持しないようになる
        • 長時間スニッファーを動作させておくならこれを使う
    • 試してみる
      • メールクライアントが平文の認証情報を送っていることが分かる
  • Scapyを使ったARP_cache_poisoning
    • ARP_cache_poisoning: ハッキング用ツールキットに含まれるものの中で最も古い技術の1つだが,いまだに最も効果的な技術の一つでもある
    • target machineには自分のマシンをゲートウェイと思わせ,ゲートウェイにも自分のマシンを通す必要があると思わせる
    • network上のすべてのコンピュータが持っているARP_cacheを,攻撃用に用意したエントリーで汚染する
    • ipconfigでARP_cacheを確認
      • ゲートウェイのIP_addressと,関連付けられたARP_cacheのエントリーが持っているMAC_addressを確認
    • 試してみる
      • scriptを動かす前に,ローカルホストのマシンを,ゲートウェイと標的のIP_addressの両方に対してパケットの転送が可能な状態にする必要がある
      • ARP_cacheが汚染される(ゲートウェイMAC_addressが攻撃者のMAC_addressと同じになっている)
  • 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への侵入につながる
    • インストールすればファイルやディレクトリの構成がすべてわかるので,特定のターゲット専用のスキャナーを作成できる
    • thread safeなPythonのQueueオブジェクトを使って,多数のスレッドを起動して複数のアイテムを処理 → 素早くスキャナーを実行
    • 試してみる
      • ファイルを取得できる
  • ディレクトリとファイルの総当たり攻撃
    • Web_server上のアクセス可能なファイルを全て知るのは難しい
      • → 通常は,Burp Suiteにも含まれるスパイダーを使い,ターゲットとなるWeb_siteをクロールし,可能な限り情報を集めることになる
      • → 設定ファイルや消し忘れの開発途中のファイル,デバッグ用のスクリプトやセキュリティに関係するその他のファイルなどを見つけ,重要な情報やソフトウェア開発者が意図せず稼働している機能を把握できる
      • 総当たり攻撃ツールを使ってよくあるファイル名やディレクトリ名をしらみつぶしに探すしかない
    • 実装
      • 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に対する総当たり攻撃
      • パスワード入力の前にログインフォームからログイントークンを取得する
      • urllib2でCookieを使えるようにすることが↑と合わせて必要
      • ログインフォームのパース
        • HTMLParser libraryを使って行う
      • 総当たり攻撃に必要ないくつかの情報(例)
        • 宛先のパスに対してPOSTリクエストを送ること
        • すべての項目に入力する必要がある
        • hidden fieldでname attributeに長くてランダムな文字列が設定されている
          • ランダムな文字列はCookieに格納されたうえでセッション管理に使われている
      • → 手順
        • ログイン画面を取得し,Cookieをすべて受け入れる
        • HTMLからフォームの要素を取り出す
        • ユーザ名やパスワードを辞書から推測し設定する
        • すべてのフォームのフィールドを設定し,CookieとともにPOSTリクエストとして送信する
        • Web_applicationにログインできたかどうか確認する
      • 実際のターゲットで試しながらツールを作るべきではない
    • 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の検査を行うためのさまざまなツールを持っている
      • 基本的には,すべてのリクエストをプロキシでとらえ,興味深いリクエストを見つけたときは,ほかのツールにそれを渡す
        • Web通信を再現してくれるBurp Repeaterにリクエストを渡して,手動で面白そうな部分を編集するなど
        • query parameterを使った攻撃の自動化
          • requestをBurp Intruderに渡せばHTTP通信の中で変更したいであろう場所を自動的に把握してくれる
            • → エラーメッセージを表示させたり脆弱性を見つけたりするための様々な攻撃に使える
    • まず,BurpのAPIドキュメントを読んで,どのBurpクラスが拡張機能を作成するために必要なのかを探る
      • ExtenderタブのAPIsタブをクリックするとドキュメントを表示
    • Pythonコードの実装
      • IIntruderPayloadGeneratorクラスを追加
      • 3つの関数を含む基底クラスを実装
    • 単純なSQLインジェクションのテスト,クロスサイトスクリプティングのテスト,オリジナルのペイロードからランダムに塊を取り出してランダムな回数分繰り返したものを追加するテスト,という3つのうち1つをランダムで選び出して実行するシンプルなファジングツールを作成
    • 試してみる
      • query parameterがハイライトされる
      • 警告から,SQLインジェクション脆弱性が表示される
      • Web_applicationのエラーを誘発したり,アプリケーションのパスを開示したり,ほかのスキャナーができないようなさまざまなことができる
      • 大事なのは,Intruderによる攻撃で使う拡張機能の操作方法を学ぶこと
  • BurpでBingを使う
    • Bing APIを使ってプログラムでクエリ―を送信し,結果を解析する
      • 発見したターゲットを自動的に追加
    • 実装
      • BingのAPIキーを設定
      • BurpのHTTP APIを使うときは,送信する前に完全なHTTP リクエストの文字列の作成が必要
      • Jython APIPythonの組み合わせで,特定のターゲットを攻撃する際の詳細な事前調査を,Burpの拡張機能で実現
    • 試してみる
      • GetリクエストからBingに送って,自動的に新たなホストがターゲットに追加
  • Web_siteのコンテンツをパスワード作成に利用する
    • セキュリティはしばしばユーザのパスワードに帰結する
    • onlineでのパスワード攻撃の肝は,適切な単語リストの入手
    • 実装
      • BurpのUIにコンテキストメニューを追加する
      • 独自の単語リストをセットに保存し,同じ単語を導入しないようにする
      • BurpからHTTPのトラフィックを選択し単語リストに追加
      • mangle()で,ベースとなる単語を切り出して,一般的なパスワード生成戦略をもとに単語を作成する
    • 試してみる
      • 単語リストの作成と表示

Ch07 GitHubを通じた指令の送受信

  • トロイの木馬の堅牢なフレームワークを作るときに最も困難なことの1つは,設置したトロイの木馬の制御やアップデート,データの受信を非同期的に行うこと
  • remoteのトロイの木馬にコードを送信するための普遍的な方法を持つことが重要
    • トロイの木馬ごとに異なる作業をさせる
    • ターゲットのOSにあったコードを追加
  • GitHubを使って,設置したトロイの木馬の設定情報や窃取したデータだけでなく,タスクを実行するために必要なモジュールを保存するようにする
  • Pythonがライブラリをインポートする仕組みをハックすれば,設置したトロイの木馬が,新たに作成したモジュールと必要なライブラリをリポジトリから自動的に取得してくるようにできる
  • GitHubとの通信はSSLで暗号化されており,GitHubがブロックされていることも非常に少ない
  • GitHubのアカウントを設定する
  • moduleの作成
    • 開発する各モジュールは,複数の引数を渡せるようにしたrun関数で実行されるようにするべき
      • → 各モジュールを同じ方法でロードでき,かつ設定ファイルをカスタマイズしてモジュールに引数を渡すようにもできる
    • ローカル環境のトロイの木馬で新たなモジュールを有効にすることで,モジュールが正常に動作するか確認
  • トロイの木馬の設定
    • さまざまな捜査をしつつ長期間にわたってトロイの木馬に仕事をさせるためには,どのような操作を実行するか,どのモジュールがその操作に必要なのかを指示する仕組みが必要
    • ↑ 設定ファイルで操作を制御し,必要ならタスクを与えないことでトロイの木馬を眠らせておくこともできる
    • モジュールの実装の際,実行時間,実行回数,引数などのオプションを追加できると便利
    • トロイの木馬にインポートして実行してほしいモジュールの辞書のリストを渡す
  • GitHubから指令を受信するトロイの木馬の作成
    • GitHubへの接続と認証,APIの操作を行うコードの作成
    • 実際のシナリオでは,認証のやり取りは可能な限り隠すべき
    • 発見されてもデータを削除されないように,トロイの木馬がアクセスするリポジトリにアクセス制限をかけることも一考
  • Pythonのインポート機能をハックする
    • トロイの木馬が必要なlibraryをすべて読み込んでくれるようにする
    • ランダムな時間スリープしてパターン解析によって発見されることを防ぐ
    • ほかの処理を行ってトロイの木馬が何をしているのか隠すのも〇
    • 試してみる
      • 実行結果がGitHubにpushされている → 取得すれば見られる
  • 改善,拡張
    • モジュールや設定,取得したデータをすべて暗号化
    • updateなどの自動か

Ch08 Windowsトロイの木馬がよく悪用するテクニック

  • ウイルス対策ソフトやエンドユーザ自身によって検出される可能性との戦い
  • トロイの木馬を設置した後の標的マシンを注意深くモデル化し,トロイの木馬を本当に標的にマシンに対して送りつける前に,実験環境内でそれらのモジュールをテストする
  • 趣味と実益のためのキーロガー
    • キーロガー: 最も古い物の1つだが,さまざまな隠蔽方法とともにいまだに使われている
      • 認証情報や会話の内容といった機密情報の窃取に非常に効果的
    • pyHookによりキー入力のイベントを容易にトラップできる
      • ネイティブWindows APIであるSetWindowsHookExを活用している
        • 特定のWindowsイベントが発生した際に呼び出されるユーザ定義の関数を設定できる
        • → キー入力のイベントに対してフックを設定
      • どのプロセスに対してキー入力が行われているか正確に知ることで,ユーザ名,パスワード,およびその他の有用な情報がいつ入力されたかも割り出せる
      • pyHookは,キーロガーの中核となるロジックは我々に任せつつ,低レベルプログラミングの部分の面倒を見てくれる
    • イベントに対して別のフックが存在していた場合,コールバック関数は真を返すことで,次のフックにもイベントを処理させることができる
  • 試してみる
    • どのウィンドウで何を入力したか分かる
  • screenshotの撮影
    • パケットキャプチャやキーロガーでは手に入らない,デスクトップの画像やビデオの撮影,その他の機密データの入手に役立つことがある
    • WindowsのGraphics Device Interface(GDI)を使用する
  • Python流のシェルコードの実装
    • ctypesモジュールをスカってメモリ上のバッファをさす関数ポインタを作成して,その関数を呼び出す
    • ここでは,urllib2を使ってWeb_serverからBase64形式でシェルコードを受け取って実行できるようにする
    • ctypesのcastでバッファを関数ポインタに型変換し,シェルコードを通常のPythonの関数と同じように呼び出せる
    • 試してみる
      • カレントディレクトリをWebルートディレクトリとして扱うために,SimpleHTTPServerモジュールを使う
        • → Webのリクエストに対して任意のファイルを提供できる
      • Webサーバからスクリプトがシェルコードを受け取る
  • sandbox検知
    • 最近のウイルス技術ソフトは,疑わしいファイルの振る舞いのチェックに,ある種のサンドボックス技術を取り入れている
      • いくつかの指標を使って,サンドボックス上で動いているかどうかを判断する
    • 今回は,標的マシン上で,キー入力やマウスのクリックといった,利用者の入力が最近あったかを監視する方法を実践
      • パソコンを起動してからの経過時間と利用者が最後にパソコンに入力した時間を確認
      • → この方法は,利用者が使用中かどうかで活動を変更する方法にも活用できる
    • ctypes libraryで実装
    • 一般的な利用ではない発生の仕方の場合もサンドボックスと分かるようにする

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()によって,ページのコンテンツがすべて読み込まれてから,ページを編集したりパースしたりするようにしている
    • サーバの作成
      • 窃取した認証情報を集める
    • 試してみる
      • 最初のテスト
        • いろいろなサイトを閲覧して,利用者に見られるべきでない変な挙動を目にすることがないか確認する
        • FacebookまたはGmailにアクセスし,ログインする
      • 利用者の認証情報を入手できる
  • IEのCOM_automationを使用した情報の盗み出し
    • 標的ネットワークに侵入することは戦いの一部でしかない
    • 一般的な目的: データファイルの窃取
    • セキュリティ対策によっては,通信をするプロセスや通信先を確認して,遮断などの措置を行うことがある
      • iexplore.exeは通常信頼されていてホワイトリストに入っているため,情報を外部のネットワークへ盗み出す手口としてIEのCOM_automationを使用するのは非常に優れている
    • ローカルのファイルシステム上からWord文書ファイルを検出するPythonスクリプトの作成
      • 検出したら公開鍵暗号を使ってそのファイルを暗号化し,tumblr.comにあるブログに投稿することを自動化する
        • Tumblrのように一般的に信頼できると認知されているサイトを使うことで,ファイアウォールやプロキシなどが持つブラックリストによるIP_addressのWeb_serverへの情報送信のブロックも回避できる
    • 実装
      • encrypt_string(plain_text)
      • encrypt_post(filename)
      • login_to_tumblr(ie)
        • 正確なタイミングの計測,DOMとの対話,必要なHTML要素を明らかにする必要
      • post_to_tumblr(ie, title, post)
      • exfiltrate(document_path) exfiltrate: こっそり抜け出す
        • Tumblrに保存したい文書ファイルを発見するたびに呼び出される
        • Windowの表示・非表示を指定できる
      • RSA暗号用の鍵の生成スクリプト
      • Tumblrに投稿された暗号化データをペーストして平文に復号するスクリプト
    • 試してみる
      • ファイル名が窃取される
      • オリジナルのファイルサイズを暗号化して記載するのも〇

Ch10 Windowsにおける権限昇格

  • 必須要素のインストール
  • process監視ツールの作成
    • WMIを使用したプロセス監視
      • WMIのAPI群は,システム上での特定のイベントの発生を監視し,そのイベントが発生した際にコールバックを受け取る方法をプログラマーに提供する
    • 試してみる
      • あらゆるプロセス,スケジュール化されたタスク,さまざまなソフトウェアの自動アップデートなどが実行されていることを確認できる
  • Windowsにおけるトークンと権限
    • Windowsにおけるトークン: プロセスまたはスレッドのセキュリティコンテキストを記述するオブジェクト
    • 一般ユーザの権限で動作しているプロセスが誤った権限を持って動作していることを確認できれば,SYSTEM権限またはカーネルレベルでコードを実行する足がかりになる
    • 注目すべき権限
      • SeBackupPrivilege
      • SeDebugPrivilege
      • SeLoadDriver
    • 監視しているプロセスに与えられた権限を自動的に取得するPythonスクリプトの作成
  • 競合状態に勝つ
    • 多くの商用ソフトウェアが,一時フォルダ内にファイルをコピーし,実行したうえでそのファイルを削除する,という動作を行っている
    • ソフトウェアやタスクスケジューラがファイルを作成する際,プロセスがそれを実行する前にそのファイルに攻撃コードを書き込み,そのうえでプロセスに実行させて最後に削除する
    • 実現のカギ: 特定のディレクトリを監視して,ファイルやサブディレクトリの変更を検出するReadDirectoryChangesWという便利なWindows API
      • 潜在的な権限の昇格以外に対しても〇
    • 試してみる
      • ファイルの作成→実行→削除を検出できる
  • code_injection
    • 実装
      • マーカーを使って,無限ループを回避
      • 監視スクリプトのメイン処理にコードインジェクションの呼び出しを追加する
    • 試してみる
      • SYSTEM権限でリスナーを起動する
      • SYSTEM権限を奪取
  • 特定の環境下においてローカルのアカウントやアプリケーションへの攻撃に使用する,独自ツールにも換えられる
  • いったんネットワーク内部に侵入できれば,WMIだけでもローカルネットワークの調査データのよい供給源となり,そのデータをさらなる攻撃に利用できる
  • 権限昇格はあらゆるトロイの木馬にとって必要不可欠な要素

Ch11 forensic attackへの転用と自動化

  • forensic: 侵入された後に,またはインシデントが起こったかどうか判断するために必要とされるもの
    • メモリに含まれる暗号化の鍵谷その他の情報を得るために,汚染されたマシンのRAMのスナップショットが求められる
  • VolatilityというPythonで書かれたforensic frameworkがある
  • install
  • profile
    • profilerにより,メモリダンプから情報を引き出すために必要なシグネチャやオフセットをどのように適用するかを決定する
    • imageinfoというpluginで,そのときのターゲットに対してどのprofileを使うべきか判断してくれる
  • password_hashを手に入れる
    • targetのハードウェアにアクセスすることさえできれば,仮想マシンから情報収集できる
    • Volatilityはpassword_hashの復元処理を非常に容易にする
      • 最初にpassword_hashを取得できそうなメモリ上の場所を見つけ,それからハッシュを実際に取得するために必要なプラグインの操作方法を見る
      • これらの処理を一括で行うスクリプトを作る
    • WindowsはローカルパスワードをSAMレジストリハイブにハッシュの形で保存しており,同時にWindowsのブートキーをシステムレジストリハイブに保存している
      • memory imageからハッシュを取り出すにはこれらのハイブが必要
      • hivelist plugin: 2つのハイブがメモリ内のどこにあるかVolatilityが見つけられるようにする
      • → 情報をhashdump pluginに渡して,実際にハッシュの解析を行う
  • 直接的なコードインジェクション
    • Immunity Debugger
      • reverse engineering
      • Pycommandを使って,exeのすべての関数を見つけて,一度だけ有効なブレークポイントを設置する
    • 複数のステップ
      • memoryをスキャン
      • exeのプロセスを見つけてシェルコードを挿入する場所を決定
      • その場所のRAMイメージの物理アドレスを割り出す
      • 指定の操作に割り当てられている関数のアドレスにジャンプ命令を挿入し,シェルコードにジャンプさせてそれを実行する
    • 実装
      • メモリ上の各ページを調べるとき,まずページの物理的なオフセットを見つける
      • そしてRAMイメージを開き,そのページが存在する場所のオフセットを調べ,メモリ上のページ全体に読み込む
      • シェルコードを同じサイズのNULLバイトの塊を探す
        • ここがRAMイメージ内でシェルコードを書き込む場所
      • 挿入したら,シェルコードをアドレスを取得しx86のバイナリコードを作成する
      • 操作のオフセットを計算し,トランポリンを仕掛ける
    • 試してみる
      • ある操作に対して処理を埋め込める
      • この技術を利用して,kernel objectを操作しrootkitのようなまねをさせることもできる
      • これらの技術は,メモリのフォレンジックに親しむための方法であり,また物理的にマシンにアクセスできる場合や,複数の仮想マシンをホストしているサーバに侵入した際にも使える

Appendix A reverse engineering用framework miasm

  • miasm
    • 用途: バイナリプログラムの解析,編集,生成
    • 機能
      • 実行ファイルの解析,編集,生成
      • プログラムコードのアセンブル,逆アセンブル
      • プログラムコードのエミュレーション
    • x86以外にもさまざまなCPUアーキテクチャに対応している
    • symbolic実行と呼ばれる先進的なソフトウェア解析機能が盛り込まれている点も特徴
  • setup
  • x86_64 assemble
    • データ領域から実行権限が排除されているため,Ch08よりコードの追加が必要
    • assemble_text()でネイティブコードを生成し,execute_native_code()で実行
    • miasmによるエミュレーション
      • サンプルコードがDockerイメージ内にあり,それをもとに作る
      • 柔軟に命令ごとに解釈を変え,処理を追加したり挙動を変更したりできる
      • → 特定の機械語命令が呼ばれた回数を数えるprofilerを作成
      • メモリアクセスの頻度の計測や,関数呼び出しの深さを調べたりと応用できる
  • symbolic実行
    • symbolic実行: レジスタやメモリ内容を具体的な値ではなくシンボルとしてエミュレーションする仕組み
      • たとえば,ある実行パスに到達するための入力値の条件を自動的に求められるなど
  • miasmはリバースエンジニアリングに必要になるさまざまな機能を持っている

Appendix B さまざまなサンドボックス検知

  • サンドボックスによるフックの検知,フックの回避,C言語で書かれた仮想マシン検知プログラムをモジュールとして呼び出す方法
  • マルウェアを解析するサンドボックスでは,解析対象の挙動を把握するため,マルウェアが呼び出すライブラリ関数をフック氏,呼び出された関数名やその関数に渡された引数を取得する
    • フックの実装には,解析対象のプログラムやライブラリを書き換える方法と,ランタイム環境側に手を加える方法がある
    • → 書き換えられた痕跡を見つけることで,前者で実装されたサンドボックスを検知する
    • 仮想マシンを見つけることで,後者の方法で実装されたサンドボックスを間接的に検知する方法もある
  • 簡易サンドボックスの準備
    • ソフトフック
      • 特定のAPI呼び出しをモニタリングする簡易的なサンドボックスを実装する
      • target processにアタッチしINT3に対するブレークポイントハンドラを実装して実行フローを横取りするもの
      • → 具体的にはフック対象の命令をINT3命令に置き換えることで,実行された際,ブレークポイント例外を発生させ,あらかじめブレークポイントハンドラに登録しておいた処理を実行させる
    • 簡易サンドボックス pydbg_sbx.py
      • PyDbgを使い,解析対象が呼び出すAPIをソフトフックにより監視する簡易サンドボックスを実装
    • 実行
      • 引数を伴って関数を呼び出したことがモニタリングできる
  • ソフトフックの痕跡を見つける
    • APIの先頭アドレスにセットされたINT3命令の有無をチェックすることでフックを検出する
    • ハードフックも,jmp命令などの分岐命令がAPIの先頭にあるかをチェックすることで,検知できる
  • サンドボックスを回避する
    • sliding_call
      • APIの先頭アドレスから数命令ずらしてAPIを呼び出す手法
      • Windowsではホットパッチという仕組みがあり,APIの先頭2バイトはホットパッチ用のコードが置かれていることが多い
      • APIの処理に直接影響がないので,実行を飛ばしても基本的に動作に影響しない
    • フックを回避してAPIを呼び出す
    • ハードフックでも.jmp命令のためのバイト分だけずらしてコールすればよい
  • runtime環境の特徴を見つける
    • サンドボックスの中には,解析対象が動作するランタイム環境側(OS,仮想マシンなど)に手を加えてフックを実現しているものも存在する
      • 自身が動作している環境の特徴を見つけることで,間接的にサンドボックスを検知できる
    • 低レイヤへのアクセス → PythonよりC
    • 仮想マシンの検知
      • VMWareで動作するゲストOSは,ホストOS側とやりとりするための通信チャネルが用意されている
        • IN命令の例外の有無を利用して,自身がVMWare上で動作しているか判断できる
    • PythonからC言語で書かれたコードを呼び出す
      • 以下の3つを準備
        • Python用ラッパー関数
        • モジュールのメソッドテーブル
          • メソッド名と実装の対応関係を保持
        • モジュールの初期化関数
    • 実行
  • その他のサンドボックス検知方法
    • debugされているかをWindows APIで確認
    • 特定のプロセス,ファイル,レジストリの有無で確認
    • IP_addressのレンジからクラウド環境で実行されているかなどをもとにして一般的なユーザのデスクトップ環境ではないことを判断し,それに基づいてサンドボックスを検知することもある

『エンジニアの知的生産術』学習メモ

はじめに

  • intellectual_productionとは
    • 知識を用いて価値を生み出す
  • programmingの学び方
    • →↓ x軸 具体: 情報収集,体験
    • ↓ y軸 抽象: 抽象化,モデル化,パターンの発見
    • ↑← z軸 応用: 実践,検証
  • ↑ (y軸は積み上げより掘り下げのイメージ)
    • ちゃんと広い穴を開けておかないと奥が見えない的な
    • xもzも穴のメタファーで回収してた感じはある(そもそもそんな言語化してたわけではないが)

Ch01 新しいことを学ぶには

  • cycleを回す原動力: やる気
    • 学びを分類
    • 逆風が強い → 強いやる気が必要
      • やる気の出るthemeを見つける
    • やる気の維持
      • goalは近くに明確に
        • SMART criteria
    • MOOCでの学び
    • 参考書の探し方
      • 大学の講義の参考図書になっている
      • 正誤表が充実している
      • 改訂されている,ロングセラーである
  • 情報収集の3つのポイント
    • 知りたいところから
    • 知りたいところから学ぶための前提条件
      • 目標を明確にする
        • 現実とのgapを表現する
        • なぜ予想と違うのか
      • 目標が達成可能
      • 大まかに全体像を把握
    • 大雑把に
      • 情報技術の進化により,まだ誰も経験していないことへの価値が上がる
      • ソースコードを段階的に読む
        • 内部構造を解説したdocument
        • directory構造
        • file構成
        • 略語を調査
        • data structure
        • 関数同士の呼び出し関係を把握
        • 関数
      • 民法の地図
        • 地図のように考えるというのは昔思ったことある
    • 片っ端から
      • 写経
      • 数学
        • 正確な積み上げが必要な場合
        • できるだけ効率化しながら,必要な部分を前から積み上げていく
      • 時間を区切る
        • 一定時間で評価する
      • 写経は補助輪
      • 写経しなければ分からないくらいであれば,新しい分野にチャレンジしていることが分かる
  • 抽象とは何か
    • 集めた情報からpatternを発見したり抽象化したりして,モデルが作られていくprocessを学ぶ
    • abstract
    • model
      • すべてのmodelは間違っている
      • modelの価値: 現実との一致度ではなく,modelの操作が現実を操作することに比べてどれくらい低コストになるか
    • module
      • 物理的なものづくりと違い,局在しない
      • 相互作用の制限
      • 重要でない部分を隠す=重要な部分を抜き出す
    • MVC
    • patternの発見
      • 具体的な事例を集めて,規則性や共通の特徴.繰り返し現れるものを見つける
      • グラフでの表現など
    • design_pattern
      • もともとは建築の分野から
    • patternの命名
      • 人間の知能を増強する方法
        • 人工物
        • 言語
          • 世界のmodeling
          • 生み出されつつある言語/制度化された言語
        • 方法論
        • 教育
    • なぜ抽象化が必要か
      • 問題間違えたときに答え読みながら考えることと同じ
        • 抽象化・一般化・汎用化された知識の獲得
      • patternの発見による一般化
      • 新しい知識を生み出すことと,哲学用語としての「帰納」の関係 → ポアンカレの『科学と仮説』 ← 読みたい
  • どうやって抽象化するか
    • 比較して学ぶ
      • 同じと違うの間に注目
        • 交換可能になっている部分に注目する
      • たとえ話
        • 伝えようとしている抽象的な概念と,それに似ている具体的なものとを,比較させて理解を促すtechnique
        • どこの部分が同じかが重要
      • 違いに注目
        • 違いに注目,一見矛盾していると見えるものについて考えてみる
        • 弁証法
        • 対立と対立の解消を繰り返す
    • 歴史から学ぶ
      • 今と昔の比較
      • 現在進行中のできごとについて,次に何が起こるか予測
      • 変更前と後でどう変わったか,なぜ変わったか
      • 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
        • featureのpriority
          • value, cost
          • new knowledge, risk
          • value, riskが高いfeatureから実装し,次にvalueが高くてriskが低いfeatureを実装し,最後にvalueが低くriskも低いfeatureを実装する
            • valueが低くriskが高いものは実装しない
    • 重要事項を優先する
      • ③緊急だが重要でないものにNoといい,②緊急でないが重要なものに取り組む
      • 主体性が必要 ← ③は働きかけがあるが②は働きかけがないため
      • 境界が不明瞭
        • 通知は緊急ではない
          • まずは記録して自分のペースで実施する
      • 価値観はボトムアップ言語化する
        • 現在の行動 → 現在のproject → 注意を向けるべき分野・責任を負っていること → 1~2年後の目標 → 3~5年後の構想 → 人生の目的・価値観
        • GTDではまず現在の行動に集中して,そこから注意を向けるべき分野などを見つけていく
          • 注意を向ける分野が言語化されれば,下のprojectやactionにも影響を与え始める
      • 7つの習慣
        • 私的成功を支えるもの
          • 主体的である
          • 終わりを思い描くことから始める
          • 最優先事項を優先する
        • 公的成功を支えるもの
          • Win-Winを考える
          • 理解してから理解される
          • 相乗効果を発揮する
        • 刀を研ぐ
    • 優先順位を今決めようとしなくてよい
      • 順位をつけることが本質的に難しい
      • 日々の行動を行う中で,徐々に自分の価値観や人生の目的が明確になると考えました
        • 価値観などの軸が明確になると,その軸と照合して,各タスクの重要度が分かるようになる
        • これにより優先順位ができるようになる
      • 自分がどういうタスクが好きなのか,どうなるとうれしいのかを日々観察していくことで,事後的に優先順位づけができるようになる
  • 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つのことに集中する
  • まとめ
    • やる気が出ない状態をどうやって解決するかについて
    • 1つに絞る
    • タスクを小さくする
    • 計測する

Ch03 記憶を鍛えるには

  • 記憶の仕組み
    • カンデルという人の本より
    • 海馬
    • 記憶には2種類ある
      • 非陳述記憶
      • 抽象化
  • 記憶と筋肉の共通点
    • 信号を伝えるシナプス
      • シナプス後細胞の電位が変化する
      • 複数の細胞から短い時間の間に立て続けに信号が届くと,電位が大きくなる
        • 発火という
        • 先の細胞に信号を伝えられる
    • シナプスの長期補強
      • シナプス後細胞が発火すると,表面の受容体が増える
        • それ以降より少ない刺激でシナプス後細胞が発火するようになる: Long-term potentiation, LTP, 長期補強
          • 1回では2時間程度で元に戻る
          • 短い間隔で4回刺激すると,長期補強が28時間程度持続するようになる
          • 短いほうが前期長期補強,長いほうが後期長期補強
          • 後期長期補強では,受容体を作る量自体が増える ←→ 前期長期補強はあらかじめ作って細胞の中にためてあった受容体が細胞膜に設置される ← 受容体のストックが減るので長続きしない
            • 作る量が増えて長続き
    • まず消えやすい方法で作り,徐々に長持ちする方法に変える
      • 学習を繰り返すとシナプス自体も増える
      • まずは海馬に保管され,時間をかけて大脳皮質などに移動していく
      • 記憶は段階的に作られ,繰り返すことで徐々に長持ちする方法で保存されていく
      • 記憶の作成は,ファイルの保存というより筋肉のトレーニングに近い
  • 繰り返し使うことによって強くなる
    • 記憶をinputする銘記のフェーズと,記憶をoutputする想起のフェーズ
      • 両方必要
    • 繰り返し似た情報が入ってくると反応が鈍くなる性質
    • outputに対して報酬が得られるとなおよい
    • column: 海馬では時間が10倍に圧縮される
      • 具体的な記憶から抽象的な情報を作り出すプロセス
      • 遅く読みすぎると理解できなくなるのもこれ
  • outputが記憶を鍛える
    • testは記憶の手段
    • テストをしてからさらに学ぶ
    • 自信はないが成績は高い
      • 主観的な気持ちと客観的なテスト結果が逆になる
    • Adoptive_Boosting
      • 弱識別器を集めて,もっと正解率の高い識別器を作る方法
      • 間違えた問題を重視することが重要
      • 繰り返し学習で弱識別器を集めて集計して答えを出すことで正解できるようになる
    • テストの高速サイクル
  • 知識を長持ちさせる間隔反復法
    • 忘れてから復習する
      • テストまでの感覚が1日以上のときには,テストまでの感覚の1/10程度の時期に復習するのが良い
        • ただし,ピークの後はそれほど悪くならないので,後であればOK
    • ライトナーシステム
      • 間違えたものは短期,正解したものは長期で復習
      • SuperMemo
    • 問題のやさしさ
      • SuperMemoの学習感覚決定algorithmは,SM-2 algorithmと呼ばれた
      • そのなかにやさしさ係数がある
    • 知識を構造化する20のルール
      • 最小情報原則
        • 問題はできるだけシンプルに
          • 半端な結果が出ない
      • 順序の定まらない集合を覚えようとしない
      • 複数のものの並びを覚えようとしない
      • 穴埋め問題は覚えやすく効率的
    • Anki
      • 学習フェーズと復習フェーズ
      • 隙間時間で細切れに学習する場合に〇
    • 難易度の自動調節
      • 適度なチャレンジのときのみ,高い集中力を発揮するフロー状態になる
        • そうでないときは,不安か退屈が勝ってしまう
      • 間隔反復法では,難しい場合に対処できない
        • → 自動保留
        • 保留の解除は,干渉を見つけて取り除くようにする
    • column: 知識を構造化する残り15のルール
    • 教材は自分で作る
      • 作る過程で理解が深まる
        • 覚える前にまず理解
        • 認知的に高度な作業をした方が記憶にとどまる
      • 個人的な情報を利用できる
        • 自分の記憶・体験・感情と関連付ける
      • 著作権と私的使用のための複製
  • まとめ
    • 記憶について
    • 海馬が長期記憶にも使われている
    • 繰り返しが必要
    • 単に繰り返すよりtestが〇
      • 主観的な自信はなくなるが,客観的な成果は高くなる
    • テストの繰り返し間隔や難易度を自動調整するしくみが実現されてきている

Ch04 効率的に読むには

  • 読むとは何か?
    • 本を読むことの目的
      • 娯楽はスコープ外
      • 情報を得ることが目的か?
      • 情報伝達の歴史
      • 一次元の情報を脳内で組み立てる
      • 本の内容だけが組み立てる材料ではない
        • 自分の脳内のモデルと合わせて理解を構築する
      • 見つけると組み立てるのグラデーション
        • 味見するだけでよいか,よく噛んで消化する必要があるか,丸のみするか
    • 読むの種類と速度
  • 自分の普段の読む速度は?
    • 読む速度のピラミッド
      • 声に出して読む速度
        • 1冊15時間
      • 視覚の限界速度
        • 1冊30秒
    • 頭の理解速度がボトルネック
      • 組み立てる時間
    • 速読の苦しみ
      • 理解速度がボトルネックなら,入力速度が上がっても意味がない
        • 主観的には頑張って速読したけど,理解にはなっていないとなって苦しくなる
      • 続けられるペースを把握する
        • 自分の認知能力ではこの速度が限界だという現実を認める
        • 長く続けることで徐々に体力がつき,ペースが上がっていく
    • 読まない
      • 読まずに知識を手に入れる
        • 読む前に知識を取得する
  • 1ページ2秒以下の見つける読み方
    • 準備の大事さ,段階的詳細化,繰り返し読むこと
    • Whole Mind System
      • 準備
        • 目的の明確化とリラックス
      • preview
        • 5 min 程度
        • 大雑把に全体像を把握
        • 調査
        • keyword探し
          • 20 pageごとに開いて目についたkeywordをメモする
        • 読むべきか,目的を修正すべきか考える
      • photo reading
        • 目のフォーカスをぼかして,ページ全体を眺める
        • 見開きを1~2秒で読む
        • 賛否が分かれるところ
        • 効果ないこともある
      • 質問を作る
        • 目的を具体化していくための情報を集めて,事後的に目的を詳細化する
      • 熟成させる
        • 少なくとも10~20分,可能なら一晩時間を置く
      • 答えを探す
      • mind mapを作る
      • 高速reading
        • 通読
      • 5日間トレーニン
    • focus reading
      • 仕入れ→加工→販売
      • 本の著者の力読み手の経験値読み手のビジネス力
      • 速度を計測しコントロールする
        • 得たい理解度に合わせて速度をコントロール
    • 見出しなどへの注目
      • 先行オーガナイザ
      • 本文より見出しの方が書く上でコストがかかっている
      • title, sub titleは商業上の理由が大きいので,参考にしない
      • 図は注目に値する
        • cost 大
      • 箇条書きも〇
      • 脚注とコラムは最初は読まない
    • column: 時間軸方向の読み方
      • 同じ著者が似たテーマを繰り返し書いているときなど
      • 何が一時の思い付きなのか分かる
  • 1ページ3分以上の組み立てる読み方
    • 哲学書の読み方
      • 開いている本
        • 著者が自分の意見を言っていない本
        • 読者が自分で考える本
      • 閉じている本
        • 著者が自分の結論を持っており,そこへ向けて論を進める本
      • 外部参照が必要な本
        • 前提知識
      • 登山型の本
        • 概念積み上げ
        • 手順をおろそかにすると後で困る
      • ハイキング型の本
        • 色々な概念を次々と
        • 山の頂上に到達するのが目的ではなく,景色を楽しむことが主眼
    • 1冊に40時間かけて読む
      • 予備調査と選書に3時間
      • 通読に4時間
      • 詳細読みに10時間
      • +方法論自体の習熟コスト
      • 棚を見る
        • 本を選ぶ方法
        • 分野の棚の本を全部見る(気になるものがあれば目次も見る)
        • ↑を繰り返す(可能なら複数の書店で)
        • 分野の全体像をスケッチしてみる
        • 易しい本ではなく,自分の興味のある本を選ぶべき
          • motivation維持のため
      • 読書ノートに書きながら読む
        • 読みたいときに読みたいところから読む
        • 全体の分量を1章10ページなどと先に決め,章の小見出しを先に記入していく
        • わからないことは何でも記録する
        • 何度も出現する単語を記録する
        • 概念の間の関係や理由と結論の関係などを矢印でつなぐ
      • わからないことを解消するために読む
        • わからないの理由
          • 用語の理解が不十分
          • 論理の筋道の理解が不十分
          • 問題意識の理解が不十分
          • 図解する必要がある
    • 数学書の読み方
      • 1回のゼミの準備に50時間かかるのは不思議ではない
      • 数学所は登山型の本が多い
      • ここは絶対大丈夫というのを少しずつでも増やしていく感じ
      • 全体像を理解することと,定義を理解することの違い
      • 厳密な議論が必要
      • わかるの定義
        • なぜそうなのかという質問に答えられること
      • わかることは必要か
  • 読むというタスクの設計
    • 理解は不確実タスク
      • 挑戦の量で測る
        • 冊数や時間など
    • 読書は手段,目的は別
      • 大雑把な地図の入手
      • 結合を起こす
      • 思考の道具を手に入れる
        • 経験によって得た名前のついていない概念や考え方に,本を読むことで名前が付くことがある
        • 概念の名前が分かれば,概念の検索ができ,関連知識を入手しやすくなる
        • 言葉を手に入れて,言葉によって思考ができるようになる
    • 復習のための教材を作る
      • 読書の目的として,復習のための教材を作ることとするのがおすすめ
        • 記憶を定着させるためには間隔を空けて繰り返すことが大事
        • 繰り返しのために重要
      • leverege_memo(lever: 梃子)を作る
        • 書籍の中で重要な部分を抜き出し,濃縮してleverege_memoを作る
        • problem
          • 文脈から切り離されてしまう
          • 量が増える一方である
      • incremental reading
        • 問題反復法のシステムを流用
        • 明示的に捨てる決心をする必要がない
          • 必要になったら検索して見つけれられる
        • 繰り返し提示されて抜き書きを作っていくことで,価値のあると感じる情報の抜き書きが徐々に増える
        • 複数の情報源からの情報が混ざってランダムな順番で提示されることで,知識との結合が促進
        • 発展途上
          • これ以上編集不要なものの扱い
      • 人に教える
  • まとめ
    • 知識が入ってくるプロセスについて
    • 特に文章を読むことにフォーカスし,情報を見つけることと,理解を組み立てることのグラデーションを見た
    • 語られなかったが有益なプロセス: 会話,実験
      • 実験: 新しく知識を作り出す効果

Ch05 考えをまとめるには

  • 情報の整理とアイデアを生み出すことは,連続的なグラデーション
  • 情報が多すぎる?少なすぎる?
    • 書き出し法で情報量を確認
      • 5分間,言及するとよさそうな情報を思いつく限り書き出してみる
      • KJ法のために,書いたものを容易に移動できることが必要
      • 質を求めてはいけない
      • 実践してみる
      • 100枚を目標にする
        • merit
          • 進捗が明確に計測できる
          • 中断が容易
      • 重複は気にしない
        • 重複は重要度の指標として重要
  • 多すぎる情報をどうまとめるか
    • 並べて一貫性を高める
      • 視線の移動だけで脳に戻すことができるようになる
      • 中心は作業領域としてゆとりをもたせる
      • column: 書き出し法の実例
    • 並べる過程で思い出したらすぐ記録
    • 関係のありそうなものを近くに移動
      • 川喜田二郎の『発想法』から → イニシャルよりKJ法
      • KJ法の流れ
        • 探検
          • KJ法の前の情報収集
            • 内部探検,外部探検(フィールドワークなど)
        • 繰り返し実行
          • labeling
          • grouping
            • ラベル拡げ
              • 並べて一覧化
            • ラベル集め
              • 関係のありそうなものを近くに移動
            • 表札作り
          • A型図解化
            • 空間的に配置
          • B型文章化
            • 文章化
        • 断片の集合から図解へ,図解から文章へとフォーマットを変えていくことで,視点を変え,見落としに気づく
    • column: ふせんのサイズ: 50mm×38mm
    • groupingには発想の転換が必要
      • groupingは客観的ではない
        • 客観的に正しいというものはないという話
      • groupingは階層的分類ではない
      • 既存の分類基準を使うデメリット
        • KJ法によって得られる構造が,既存の構造と同じものになってしまう
          • KJ法の意味がない
      • column: frameworkによる効率化
        • 変化が不要な状況でのみframeworkは有用
      • 事前に分類基準を作るデメリット
        • 全体像を把握できていない状態で事前に作った分類基準は,高い確率で間違っている
        • 盲点に気づき,既存の思い込みの枠を壊すことが重要
          • 既存の枠を手放すこと自体が難しいので,そもそも持たないことが大事
        • 具体的な情報が主体で,どう構造化するかという主観的な解釈は,具体的な情報に従属する
      • 分類で負担を減らすメリット
    • 関係とは何か
      • 類似だけが関係ではない
      • NM法は対立関係に着目する
        • 対立の解消に役立つかもしれない仮説を立てることを目指す
      • 話題がつながる関係
        • KJ法のgroupをプレゼンテーションのスライドにたとえる
        • 話がつながるのが良いgrouping
        • つなぐstoryを考えることで新しい情報が生み出されることもある
    • 束ねて表札をつけ,圧縮していく
      • 表札作りのメリット・デメリット
        • merit
          • 見かけの枚数の削減
        • demerit
          • 束ねたものの中身を見るのに手間
      • 表札を作れるgroupが良いgroup
        • groupingの段階で分類をしないことが必要
      • ふせんが膨大なときの表札作り
        • まず具体的な情報を用意し,それを集め,その上に表札を置いていく
      • 「考えがまとまらない」と「部屋が片付かない」
        • 情報デザイン: 情報を,人が効率的かつ効果的に使えるような形で準備する技法
        • 片づけのテクニック
          • 収納場所に先に分類ラベルを貼らない
      • column: 表札とふせんの色
        • 一度に書き出した内容が同じ色である確率が高くなるという点がメリットになる
      • column: 知識の整合性
        • 正しさの保証: より多くのものと整合していること
          • 応用範囲が広いため
        • KJ法にて,関係がありそうと感じたものをgroupingし,それに表札をつける
          • → 整合しそうな知識を組み合わせ,なぜ整合するのか言語化していく作業がある
          • これを繰り返すことで,知識間の整合性が増していき,知識のネットワークが構築される
    • 束ねたふせんをまた広げる
      • 関係がある者が近い位置になるように空間的配置され,囲みや矢印が加筆された図解ができる
    • 文章化してoutput
      • format変換作業が有益
        • あいまいなつながりに気づける
  • 社会人向けチューニング
    • stepの省略
      • 表札作りや図解化は省略する
    • 中断可能な設計
    • A4書類の整理法
      • 押し出しファイリング
      • クリアファイル整理法
        • 探したいものの番号はデータの中で検索
  • 繰り返していくことが大事
    • KJ法は認知的に高度な処理であり,それを繰り返すことで,効率よく記憶を作ることができる
    • KJ法を繰り返す
      • よく耕された畑のようになる
      • よく整理された文房具棚
    • 繰り返しのtrigger
      • 言及されたときに,再度読み返してみて,少し再構成したいというときに,再度KJ法を使う
    • incrementalな改善
      • 締め切りがある場合にはフィットしないこともあるが,長期的に自分を鍛えるためには使える
    • 過去の出力を再度grouping
      • 基本は再度書き出し法から実施する
      • 電子化が必要
    • 電子化
      • 画面サイズは140cm×80cmくらいあればできそう
      • 共同編集は不要
  • まとめ
    • 考えがまとまらないという悩みの解決のために,まず書き出して十分な情報があるか確認し,それから書き出したものを机の上で物理的にまとめていく方法を見た
    • 知的生産の重要なプロセス
      • 書き出してから考える
      • 描いたものをボトムアップでgrouping
      • グループをうまく要約した表札をつける
    • 特にボトムアップにgroupingが重要な原理原則を強調

Ch06 アイデアを思いつくには

  • 「ideaを思いつく」はあいまいで大きなタスク
    • 分解して,計測や管理可能なフェーズとする
    • ideaを思いつく3フェーズ
      • 耕すフェーズ
        • 情報を集め,かき混ぜ,つながりを見出そうとするフェーズ
      • 芽生えるフェーズ
        • 管理できない
        • 情報を寝かせて,ideaが芽生えるのを待つ
        • 締め切りがあれば,time limitまでに芽生えたもので残りのフェーズを進める
      • 育てるフェーズ
        • 生まれたideaを磨き上げていくフェーズ
        • 有用かどうか実験によって検証し,修正していく
    • 先人の発想法
      • Youngのideaの作り方
        • ①資料集め
        • ②資料の加工
        • ③努力の放棄
        • ④ideaの誕生
        • ⑤ideaのcheck
        • ①と②はまとめて耕すフェーズ
        • ③と④は芽生えるフェーズ
          • 芽生えさせるのではない
        • ⑤が育てるフェーズ
      • 川喜田二郎の発想法
        • W型問題解決モデル
        • 実験科学の前に野外科学が必要
        • 野外科学
          • 問題提起,探検,観察,発想,仮説の採択
          • 探検学やKJ法を使用
          • 観察で情報収集,発想でKJ法を使ってまとめて仮説を思いつく
        • 実験科学
          • 推論,実験計画,観察,検証
      • Scharmerの変化のパターン
        • U理論
        • U曲線モデル
          • level 1(4つの意識状態: level)
            • Downloading
              • 思い込みにとらわれて外界を観察していない状態
            • Performing
              • ideaが既存のシステムに組み込まれ,機能している状態
          • Voice of Judgement
          • level 2
            • Seeing
              • 外界を観察しているが,自分の既存の枠にしがみついて,他者の視点から情報を感じ取れていない状態
            • Prototyping
              • prototypeが作られた状態
          • Voice of Cynicism
          • level 3
            • Sensing
              • 他者の視点から情報を感じ取り,自分の既存の枠が壊れたが,「自分」を手放していない状態
            • Crystallizing
              • ideaが結晶化された状態
          • Voice of Fear
          • level 4
            • Presensing
              • 「自分」を手放し,未来の変化の可能性を見ている状態
      • 芽生えは管理できない
        • 運しだい
        • 芽生えなかった時のリスクの管理
        • 耕すことに時間を使う
        • 育てる時間を確保する
        • 管理できるところは管理し,できないものは管理しないのが,いいアイデアを生むための最大限の努力
  • まずは情報を収集する
    • 自分の中の探検
      • 特殊資料 ←→ 一般的資料
        • 今解決したい問題について特化した資料
        • 自分の身近な問題の解決には,主観的な考えも確認する必要
    • 言語化を促す方法
      • 自分の中から情報を引き出すために
      • 質問によるtrigger
        • framework
          • 質問の束
          • merit
            • 盲点を埋めることに有益
          • demerit
            • framework自体が既存の固定化した思考の枠
          • 枠に収まらない情報こそ生産において重要なこともある
          • 適切なタイミングで少しだけ使えば有効だが,乱用し継続的に使い続けると有害になる
          • 探索と利用のバランスが重要
      • 創造は主観的
        • 客観的に説明できることを制約条件としてしまうと,すでにあるものから遠からぬものとなってしまう
        • 耕し,芽生えを待つフェーズでは主観的に考える必要がある
    • 身体感覚
      • ファインマン,科学とは何か
      • 抽象概念を身体感覚に近づける必要
      • 絵に描いてみる
    • たとえ話,メタファー,アナロジー
      • 抽象概念が現実に形を持たないため
      • 遠い分野のアナロジーが使われたときに,製品の新規性が高まるという調査
      • NM法とアナロジー
        • 課題からkeywordを選ぶ
        • keywordを別の空間(メタファーの空間)に対応付ける(アナロジー
        • メタファーの空間で連想する
        • 連想したものを課題の空間に引き戻す
        • e.g. vector複素数の対応付け
      • Clean Language, Symbolic Modelling
        • 相手からメタファーを引き出すことを目的とした方法論
        • 前提を含まない質問
          • どんな種類?ほかには?どこにある?どのあたりにある?何のよう?
        • → symbolの生成
        • symbolの時間軸上での変化やsymbolの間の関係を明確化していくことでsymbolを使って作られたモデルができる
        • symbolの時間軸上での変化を明らかにする質問
          • それから何が起こる?
          • 次に何が起こる?
          • そのすぐ前には何が起きる?
          • それはどこから来る?
        • symbolの関係を明らかにしていく質問
          • XとYはどういう関係?
          • XとYは同じ?違う?
          • XとYの間には何がある?
          • (Xが出来事のとき)Xが起きたとき,Yには何が起こる?
    • まだ言葉になっていないもの
      • 暗黙知: 解決に近づいている感覚
        • 独創的な発見がいかにして起こるのかの考察が背景
        • 効率よく新しいものを生み出すために,暗黙知が役立っているという考え
          • 人間は問題の解決に近づいているか近づいていないか感じることができる
        • column: 2種類の暗黙知
          • tacit knowing/ tacit knowledge
      • 違和感は重要な兆候
        • 違和感: 問題の解決から遠ざかっている感覚
      • Thinking At the Edge: まだ言葉にならないところ
        • 違和感に注目して言語化を進めていく
        • フェルトセンス: まだうまく言葉にできていない,しかし重要だと感じる,身体的な感覚
      • 辞書との照合
      • 公共の言葉と私的な言葉
        • 公共の言葉にするために辞書
      • KJ法も違和感に注目
        • 分類をしてはいけない理由
        • ここに並べた理由は何かという問いに既存の分類を答えてしまうと,言語化されていないものを言語化する効果を発揮できない
        • これがKJ法の一番重要な部分
    • 言語化のまとめ
      • 情報を収集する方法の一環として,自分や他人の中にすでに存在する情報をどうやって取り出すのかについて重点をおいて解説
      • 身体感覚や経験,違和感に注目することが大事
        • まだ言葉になっていない
        • まず自分の中から私的な言語でもいいので取り出す
        • そのあとに人に伝わる形に改善すればよい
        • 言語から身体感覚が外れている場合は,取り戻す
      • 自分の中のまだ言語化されていないものと,きちんとつながった言語化されたものを作ることが目的
  • 磨き上げる
    • 最小限の実現可能な製品(Minimum Viable Product: MVP)
      • 構築・計測・学習のループを回してすばやく学習することが大事
      • 誰が顧客かわからなければ何が品質かもわからない
      • 何を検証すべきかは目的によって異なる
    • U曲線を登る
      • Crystallizing
        • 漠然と思っていたことや不完全なideaが,書き出したり加工したり人に話したりすることで徐々に明確な形になっていく
      • Prototyping
        • 早い段階で問題に気づく
      • Performing
        • できあがったものを,より上位のシステムに埋め込みつつある状態
      • サイクルを回して何度も登る
    • 他人の視点が大事
    • 誰からでも学ぶことができる
      • それぞれ分野が異なる
      • 相手がどう感じているのかの言語化を促し,それを吸収する
    • time machineを作れ
      • 相手の私的な言語を,質問を通じて理解する
    • column: 知識の分布図
      • 知識分野は独立しておらず,固定的でもない
      • → 滑らかにつながった,閉じた円環でないものを使って表す
    • 再び耕す
      • 十分に他人の視点からの情報収集ができた後
      • 1つは,改善
      • もう1つは,idea自体を作り直すapproach
    • column: 書籍とは双方向のcommunicationができない
      • KJ法で対応する
        • 著者エミュレータの作成
          • 本に書かれていない質問に答えられるかどうかで検証 モデル化
  • まとめ
    • ideaが生み出されるprocess, 知的生産の「生産」に直結する部分を掘り下げ
    • 学ぶことは,自分の外のものを自分の中に取り込むこと
    • ideaを生み出すことは,自分の中のものを外に出すこと
    • 学びとideaの創造は,逆向きのことではなく,ほぼ同じこと
      • 耕すフェーズは情報収集,育てるフェーズは検証と密に関連
      • ideaが芽生える瞬間に起きることは,新しい結合であり,異なる者の間の関連の発見であり,パターンの発見であり,モデル化であり,抽象化
    • まだ言語化されていないものを言語化する方法について掘り下げ
      • 最初から客観的であろうとしたり正しくあろうとしたりする気持ちは,新しいものを生み出すことの障害になる
      • まずは主観的な違和感や身体感覚,個人的なメタファーを駆使して,誰も見たことのないものを手繰り寄せる
        • 磨き上げるのはそのあと
    • KJ法は,仮説を生み出す知的生産の方法でもある
      • 客観的に分類するのではなく主観的に結合を見出していくことが,新しいものを生み出すために必要
      • KJ法は,情報を耕し,芽生えやすい環境を整える,有用な手法
    • 磨き上げる手法
      • MVP
      • 小さく実験して,徐々に改善

Ch07 何を学ぶかを決めるには

  • 何を学ぶのが正しいか?
    • 数学の正しさ
      • 公理が正しいと仮定したときに,公理の組み合わせによって論理的に導かれたもの
    • 科学と数学の正しさの違い
      • 科学では,何度も実験して確認されたことは正しい
      • 数学では,何度も実験して確認しても,それが正しいことは保証されない
      • 科学では,実験で否定されていない主張は仮に正しいものとする
        • 主張を支持する結果が観測されればされるほど,その主張は信頼性が高まる
    • 意思決定の正しさ
      • 繰り返す科学実験と一回性の意思決定
        • 意思決定に繰り返しは使えないことも多い
      • 事後的に決まる有用性
        • 有用性が1つの基準だが,事前には決まらない
      • 過去を振り返って点をつなぐ
        • 将来何らかの形で点がつながると信じて行動するしかない
        • 何が有用かは事後的にしか分からない
        • 何を学びたいかの答えを外に見つけても見つからない
  • 自分経営戦略
    • 経営戦略のアナロジー
    • 学びたい対象を探す探索戦略
      • 自分の内面の「熱意が湧いてくるかどうか」に着目した戦略
      • 何かを学ぶことで学ぶ力が培われ,別の分野の学びの効率も高められる
      • column: 選択肢の数が意思決定の質にもたらす影響
        • 二択より三択の方が16.7倍も良い結果
      • 探索範囲を広くする
        • 目についたもの,少しでも興味の湧いたものを片っ端から学んでみる
        • 特に大学生向け
        • 盲点の発見に他人の視点
        • 違和感があったら無理に続けなくてもいい
    • 知識を利用して拡大再生産戦略
      • 自分の外側に注目
      • ポジショニング学派: 自分が置かれている状況をポジションにたとえて,周囲の状況を分析し有利な場所を占めようとする戦略
      • 社会人は,まず「今やっている仕事の効率化」を学び,時間の余裕を作り,その余裕を新たな学びに投資する
      • ↑ 知識の拡大再生産戦略
        • 拡大再生産: 企業が利益を上げたときに,その利益を生産設備などに投資し,その設備を使ってさらに利益を上げる
      • 知識を使って時間を得て,その時間を知識獲得に投資する
      • 知識を使ってお金を得て,そのお金を知識獲得に投資する
      • 知識を使って立場を得て,その立場を使って知識獲得をする
    • 卓越を目指す差別化戦略
      • 他人からの知識の獲得はコストが安い
        • Vanhoucke @Google
          • 何かに詰まったとき,まず自分で15分解決を試みる.15分経ったらほかの人に助けを求める
      • 他人から得た知識は価値が低い
        • 立場から選択肢が生まれ,生産のための取捨選択ができるようになる
        • → 他者の部分集合になるのは損
      • 卓越性の追求
        • 知識を価値につなげていくには,その知識分野に最も詳しい人になる
        • まず最優先で卓越し,それによって成長の機会を得る
        • 差別化戦略
    • かけ合わせによる差別化戦略
      • ある領域で1番でなくても,ほかの領域とかけ合わせて1番になればOK
      • ふたこぶの知識
        • communication〇
        • T(またはπ)型人材
      • 連続スペシャリスト
        • 1つ目の専門性によって卓越の立場を作り,その立場から収穫を得て,それを2つ目の専門性の獲得に投資する
        • 拡大再生産戦略と卓越を目指す戦略の融合
      • 新入社員の戦略案
        • 会社で得る知識Xとは異なる,新しい分野Yを見つける
        • → その分野で卓越
    • 組織の境界をまたぐ知識の貿易商戦略
      • 知識の流れの滞り
        • この流れの円滑化はしばしば経済的な価値を伴う
        • → 複数の組織をまたぎ,組織間の情報流通を起こすことで価値を生む戦略が成立
      • 知識とその需要が自分に集中するようになる
      • 知識は複製できるので,知識が自分の中を流れるようにすると,知識の複製が自分の中に蓄積され,自分の価値を徐々に高めていく
      • いくつかの方法
        • 積極的に外部の情報源に触れる方法や,社内で学んだことを社外に伝える方法,複数の組織に所属する方法など
      • 相互に教え合って相互に得をする形が〇
        • outputのみの状況にならずに済む
  • 知識を創造する
    • 外の知識を取り込んでも,差別化につながりにくい
    • 実際の応用の現場で必要に応じて生み出された知識は,流通しておらず,現場の状況にフィットした価値の高い知識
      • → 新しい知識を生み出す力が,価値の源泉