うぃろぅ.log

140字で綴りきれない日々の徒然備忘録

【備忘録】 DB / SQL基礎

うぃろぅです。

今日はDB基礎。やっていきましょう。

今日のテーマ

DB基礎

vviilloovv.hatenablog.com

設計編を先にやってしまっているからいまさら感がすごい。まぁ何か身につくものがあるでしょう。

DBとは

データを一元管理する仕組みのこと。

変遷

台帳(紙) → ファイル(データ) → DB(データ)

フォルダ内にファイルをぶわーって並べて管理するイメージがファイル。経験はない。
年賀状の住所録をフロッピー内に保存、みたいな。被りが生じることが大いにある。

でもhoge_(日付)とかfuga_r1みたいにつけるのは…バージョン管理かそれは。

RDB

RDB(リレーショナル・データベース)はリレーショナル・モデルに基づくデータベースのことである。

トートロジー感ある。要は複数の表を関連付けて管理する、といったところ。

構成要素

表(TABLE)

RDBにおいてデータを管理する基本単位。

関連付けは「主キー」「外部キー」といったキーを参照して行う。

RDBMS

Relational
DataBase
Management
System

RDBを管理するシステムのこと。障害発生時にリカバリしたり、データの不整合を防いだりと重要な役割を担っている。

SQL

Structured
Query
Language

DBを操作するための言語。

  • DML
    Data Manipulation Language - データ操作文。selectとかdeleteとかのよく使うものがこれにあたる。
  • DDL
    Data Definition Language - データ定義文。createとかdropとかのテーブル自体の操作に使うのがこちら。
  • DCL
    Data Control Language - データ制御文。grantとかcommitとかの権限、トランザクションといったデータ外のことを制御するのがこれ。

以上の3種類がある。

基本的なデータ検索

実際に何ができるかを見ていく。

表の照会

表から必要なデータを取り出すことができる。

例として

  • 射影
    列を取り出す。
  • 選択
    行を取り出す。
  • グループ化
    読んで字のごとく。

が挙げられる。

射影

select (列名1, 列名2, ...)  
from (表名)

よく見るやつ。select *で全列取り出し。

選択

select (列名1, 列名2, ...)
from (表名)
where (検索条件式)

条件に合う行を検索して抽出する。

演算子として、

  • 比較演算子
    >とか<>とかのExcelでもよく見るアレ。
  • BETWEEN演算子
    (列名) between 値 and 値で範囲をとってこれる。
  • IN演算子
    (列名) in (値1, 値2, ...)でor検索が簡単にできる。
  • LIKE演算子
    (列名) like '文字'でパターンマッチできる。IDが1で始まって9で終わる、とかそういう調べ方。
  • NULL演算子
    (列名) is nullで空値を検索できる。

がある。between以降の演算子not指定も可能。

select *
from sample
where id not in (101, 201)

id101201以外の行を引っ張ってくる。

select *
from people
where address like '%区%'

addressという文字を含んでいる行を抽出する。

論理演算子

  • and
    条件を全て満たす
  • or
    条件をどれか満たす
  • not
    否定を表す

これらを適切に使うことで欲しいデータを的確に引っ張ってこれる。

並べ替え

order by (ソート対象列) asc / descで昇順(asc)か降順(desc)に並べ替え。

select *
from sample
order by price desc

priceで降順に並べ替え。省略した場合はデフォルトでascになる。

グループ化

集合関数

  • count (列名 / *)
    行数をカウント。
  • sum (列名)
    総和を算出。
  • avg (列名)
    平均値を算出。
  • max (列名)
    最大値を算出。
  • min (列名)
    最低値を算出。

ができる。

select count(*)
from sample

とすると対象テーブルの件数が出力される。件数を算出するだけのため、countしない場合より処理が軽い。

select (列名1, 列名2, ...)
from (表名)
(where 条件)
group by (グループ化する列名)

基本文法。

select id, sum(price), max(income)
from item
group by id
having sum(price) > 10

集合関数を使った条件を記述する場合having句を用いる。

応用

基礎とは

結合

複数の表から同時に情報を抽出し、1つにまとめる。

  • 内部結合
  • 外部結合
  • 自己結合
  • クロス結合

の4種類がある。

www.techscore.com

TECHSCORE先生に訊くのが手っ取り早いが、つらつらと書いていく。

内部結合

共通の列の値が結合条件に一致する行の取り出し。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F

この表に対して

select item_id, item_name, shelf_name, floor
from item inner join shelf
on item.shelf_id = shelf.shelf_id

を実行すると

item_id item_name shelf_name floor
001 メモ帳 紙類 1F
002 付箋 紙類 1F
003 鉛筆 筆記類 2F
004 ボールペン 筆記類 2F
005 玄翁 工具 2F

この表が得られる。同一のカラム名が存在する場合(表名).(列名)と書いてどの表のカラムなのかをはっきりさせる必要がある。

例を書くのか一番時間かかる…。

外部結合

主キーの値が一致しない値も抽出してくる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F

さっきの表を再掲。この表に対して

select item_id, item_name, shelf_name, floor
from item right outer join shelf
on item.shelf_id = shelf.shelf_id
item_id item_name shelf_name floor
001 メモ帳 紙類 1F
002 付箋 紙類 1F
003 鉛筆 筆記類 2F
004 ボールペン 筆記類 2F
005 玄翁 工具 2F
食器類 1F
日用品 2F

この表が得られる。

left outer joinとすることで左側の表を全て出力、rightでその逆。今回はshelfの一致したいものも出力するのでright outer joinとしている。full outer joinで両方の一致していない行も含めて出力される。書き方が難しい…。

ちなみにleft right full が書いてある場合outerが省略可能で、innerは左右の別がそもそもないため省略可能となっている。

select a, b from hoge join fuga on b = a; -- 内部結合
select a, b from hoge right join fuga on b = a; -- 右外部結合
select a, b from hoge left join fuga on b = a; -- 左外部結合
select a, b from hoge full join fuga on b = a; -- 完全外部結合

つまりこう書けるということ。

自己結合

同一表を結合する。

codezine.jp

例書くの疲れたわかりやすい例が載っていたため詳細はこちら参照。

重複行削除に力を発揮するみたい。
他には例えば社員ID上司IDがあり、上司ID社員IDに含まれている場合に使える。
社員表から上司表を作成すると。なるほど。

select (別名).(列名)
from (表名) as (別名1) inner join (表名) as (別名2)
on (別名1).(外部キー列) = (別名2).(外部キー列)

同一表を参照するため、asで別名を宣言することが多い。asは省略可能。

クロス結合

ある表とある表の組み合わせを求める。

select (列名1, 列名2, ...)
from (表1) cross join (表2)

特に難しいところもなく。
これを何に使うかといえば、各データの組み合わせに対してテストを実行する、ということでテストデータ作成に有用。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
  • shelf
shelf_id shelf_name floor
101 紙類 1F
102 筆記類 2F
103 食器類 1F
104 日用品 2F
105 工具 2F
select item_id, item_name, shelf_name, floor
from item cross join shelf

これをうっかり実行すると

item_id item_name shelf_name floor
001 メモ帳 紙類 1F
001 メモ帳 筆記類 2F
001 メモ帳 食器類 1F
001 メモ帳 日用品 2F
001 メモ帳 101
002 付箋 紙類 1F
002 付箋 筆記類 2F
002 付箋 食器類 1F
002 付箋 日用品 2F
002 付箋 工具 2F
003 鉛筆 紙類 1F
003 鉛筆 筆記類 2F
003 鉛筆 食器類 1F
003 鉛筆 日用品 2F
003 鉛筆 工具 2F
004 ボールペン 紙類 1F
004 ボールペン 筆記類 2F
004 ボールペン 食器類 1F
004 ボールペン 日用品 2F
004 ボールペン 工具 2F
005 玄翁 紙類 1F
005 玄翁 筆記類 2F
005 玄翁 食器類 1F
005 玄翁 日用品 2F
005 玄翁 工具 2F

こうなる。この例は実用性はないがあくまで例ということで勘弁して欲しい。

複問い合わせ

ある表を照会した結果を用いて別の表を紹介する。

where (検索条件) = (select文)と続けていく。これが何階層にもなってしまうと処理時間が大変なことになりがち。

www.atmarkit.co.jp

よくわかる解説がこちら。

データ検索以外の操作

データ追加

insertを用いる。

insert into (表名)(列名1, 列名2, ...)
values (値1, 値2, ...)

全ての列に値を設定する場合列名は省略可能。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105

おなじみのこれに対して

insert into item
values ('006', '', '105')

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 105

こうなる。かんたーん。

こちらも複問い合わせを利用可能で

insert into (追加する表名)
select (列名1, 列名2, ...)
from (検索する表名)
(where 条件)

とすれば条件に合うデータをまとめて追加できる。

データ更新

updateを用いる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 105

先ほど変更したこの表に対して

update item
set item_name = ノミ
where item_id = '006'

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 ノミ 105

こうなる。where句の条件が複数行に当てはまる場合全てに対して更新が走る。

データ削除

deleteを用いる。

  • item
item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105
006 ノミ 105

この表に対して

delete from item
where item_id = '006'

これを実行すると

item_id item_name shelf_id
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
005 玄翁 105

こうなる。こちらも複数同時に消すことが可能なため

delete from item

うっかりこれを実行すると全部消える。落ち着いてrollbackだ。

トランザクション

データベースに対する処理の基本単位。

リモートリポジトリとローカルリポジトリの関係に近い。手元の修正はリモートには反映されていないため、変更を確定するためにはcommit、変更を破棄するためにはrollbackを実行する。

表の定義

ここまでが表に対する操作、DML。ここからは表自体の作成や削除を行うDDLについて。

表作成

create tableを用いる。

先ほどのitem表を作成するのであれば

crate table item
(item_id CHAR(3) NOT NULL,  -- 固定長文字列、必須項目
item_name VARCHAR(20),  -- 可変長文字列
shelf_id INTEGER(3) NOT NULL)  -- 数値、必須項目

こんな感じ。型が適当なのは例なので許して。

大文字小文字の区別はないがなんとなく型名は大文字のイメージ。SELECTとかも大文字で書いてある場合が多いけれども。

表削除

drop table item

消すのはとても簡単。そしてテーブルの変更はrollbackできない。要注意。

RDBMSの機能

  • データの物理構造管理
  • データ定義情報管理
  • データ操作機能提供
  • 同時実行制御
  • 機密保護
  • 障害回復

概ねこんなところ。データ管理はお任せ!みたいな感じ。

データの物理構造管理

db-study.com

データの格納位置を一切気にすることなくSQLを扱える。

データ定義情報管理

  • データファイル
    ユーザーが定義した表のデータ
  • データ辞書
    データ構造、関連付け、容量等のDB自体の情報
  • ログファイル
    変更履歴。

を管理してくれる。

データ操作機能提供

SQLで操作できるよ、ということ。微妙に方言はあるが概ね似たり寄ったり。

同時実行制御

多重更新を防止するための排他制御。ロックをうまいこと掛けてくれる。

デッドロック

お互いに更新したい箇所をロックしあってしまい、ロックがとけなくなる。
片方のSQL文をエラーにすることでRDBMSデッドロックを回避させることが多い。

そもそもの更新順を設定する、1更新につき1行に限定する、といったことでデッドロックが起きないようにすることが大事。

トランザクション同時実行時の現象

  • ダーティーリード
    commitしていないデータが検索できる現象。
  • ノンリピータブルリード
    以前の問い合わせと同じデータが検索されない現象。
  • ファントムリード
    以前の問い合わせ結果に含まれないデータが検索される現象。

qiita.com

わかりやすい。Qiitaは頼りになる。

トランザクション分離レベル

(分離レベル) ダーティリード ノンリピータブルリード ファントムリード
READ UNCOMMITED
READ COMMITED ×
REPEATABLE READ × ×
SERIALIZABLE × × ×

下にいくほど同時実行性が低くなる。

機密保護

DB内へのデータアクセスを制御する機能。権限を操作して制限をかける。

障害回復

データが破損したときに元に戻す機能。

  • システム障害
  • メディア障害
  • アプリケーション障害

等様々な事情でデータは破損する。

バックアップとログファイルを組み合わせてデータを復元していくことになる。

ログファイル

2種類のログを比較して復元する。

ロールバック処理

更新前ログを使用して更新された部分を元に戻す処理。

ロールフォワード処理

更新後ログを使用し、障害発生直前の状態に回復する処理。

応用情報技術者試験を受けたときに勉強したなぁって。

まとめ

以上の知識を基に、各種ベンダーのRDBMSに関する知識を拡充していくべし。

めっちゃ書いた。先週より時間短かったのに表を作ったせいでよっぽど面倒なことに。

ではまた。

【備忘録】 DB設計 基礎編

うぃろぅです。

たまには実務的なところもやっておこうということでやっていきます。

今日のテーマ

DB設計 基礎

内容

  • ER図
  • 正規化
  • 設計タスク

大学のときにうっすらやった記憶があるようなないような。あと応用情報技術者試験とか。受かったら大体忘れるよね。

qiita.com

わかりやすい記事があった。インターネットには知見があふれている…。

DB設計の位置づけ

ウォーターフォール型の工程においての上流工程である。

抜け / 漏れがあると手戻りの幅が大きくなるため、コストが増大する。
そのため、DE設計はおざなりにせずきっちり行わねばならない。どの工程もおざなりにするな

DB設計の流れ

  • 概念設計
    エンティティ抽出、属性抽出、正規化等。
  • 論理設計
    サマリ・エンティティのの検討、非正規化等。
  • 物理設計
    テーブル設計、インデックス設計、セキュリティ設計等。

DBかするかしないかというところから検討していく。

概念設計

  • 業務 / データ分析を行う
  • DBMSには非依存

必要なデータ項目を漏れなく洗い出すことが重要。
アウトプットは概念ER図で行う。

論理設計

  • パフォーマンスを考慮

性能を意識して概念設計のデータモデルを見直す必要がある。
アウトプットは論理ER図で行う。

物理設計

  • 実際のマシンに応じて考慮する
  • 領域設計を行う

仮想化も選択肢に入れればいいんじゃないですかね…?
運用形態を考慮し、物理設計書にアウトプットする。

ER図

it-koala.com

この記事を読み込めば大体理解できる。

ERとは

Entity
Relationship

属性の関係を表す図。
「顧客」「受注」「明細」「商品」のように必要な要素をエンティティごとに分け、線で繋ぐ。

書き方にはいくつかタイプがあり、IE型やIDEF1X型等がある。

エンティティとは

業務処理の過程で処理 / 管理の対象となる情報のこと。
具体的なインスタンス(Oさん 女性 20代、Hさん 女性 30代等)を抽象化したもの(氏名 性別 年齢層)がエンティティということになる。

もの、組織、場所、出来事がエンティティになることが多い。

f:id:vviilloovv:20190524115140p:plain
エンティティの種類

種類としてはこんな感じ。大きく分けて2種類。

属性

エンティティで保存すべき情報。エンティティって書きすぎて頭おかしなるで。

  • ID
  • 氏名
  • 誕生日
  • 住所

みたいな感じ。識別キーをIDにすることが多い。

識別キー属性とは、「その情報があれば対象が一意に定まる」属性のこと。
識別キーが1つのこともあれば複数の事もある。

リレーションシップ

業務処理上必要となるエンティティ間の関係。
「何対何か」「必ず結びつくのか」「どういう関係なのか」を表す。

カーディナリティ

インスタンス同士が何対何で結びつくか。

  • 1つのキャラを1人の声優が演じる場合1対1
  • ポプ子とピピ美のCVは1対多
  • 収録スタジオと声優の出先は多対多…ちょっと苦しい

外部キー

カーディナリティの多側に1側の識別キーがコピーされて外部キーとなる。

オプショナリティ

自分側に対して相手側のエンティティが任意か必須かという性質のこと。

  • 声優が事務所に所属するのは必須ではない、みたいな。

多対多の分解

多対多は2つの1対多関係に分解できる。
交差エンティティを追加して分割する。

  • 「声優」「スタジオ」をまとめて「訪れた回数」で履歴管理するとか…ええい例がわかりにくい
  • 「商品」「倉庫」を「在庫」で仲介する、というのがわかりやすい例 「倉庫番号」と「商品番号」を外部キーとして管理する。

多対多は必ず分解して概念設計を終える。

ER図記述時の留意点

「線は直角に引く」「リソース系は同じ列に並べる」等ルールを決めて運用するといつ誰が見てもわかりやすい図となる。心がけるべし。

スーパータイプ / サブタイプ

プログラミングで言うスーパークラス / サブクラスと捉えるとわかりやすい。共通属性を抽出して継承するイメージ。

応用的な関係

木構造1対多の自己ループとなる。営業所の下に部があってその下に課があって…が例。

正規化

ext-web.edu.sgu.ac.jp

この記事がわかりやすい。

データの冗長な部分を排除し、重複なくグルーピングする手法。

データ更新 / 追加 / 変更に強いDBにするために必須。

基本的には第三正規系までで充分取り扱えるが、第四、第五…とまだ続きがあるにはある。

第一正規化

単純に複数持っているデータを分割するのみ。

商品番号 商品名
001 メモ帳
002 ボールペン

これを

商品番号 商品名
001 メモ帳
001 メモ帳
002 ボールペン

こうする。

主キーないけど例ということで。

第二正規化

複数の主キーで一意に定まるデータ、1つの主キーで定まるデータが混在しているDBを分割する。

商品番号 色番号 商品名
001 01 メモ帳
001 02 メモ帳
002 01 ボールペン
002 02 ボールペン

「商品番号」「色番号」を主キーとする。

この場合、「商品番号」「色番号」が決まれば「色」は一意に定まるが、「商品名」は「商品番号」がわかれば一意に定まる。

なのでこの表を

商品番号 商品名
001 メモ帳
002 ボールペン
商品番号 色番号
001 01
001 02
002 01
002 02

こう分割する。

第三正規化

主キー以外の部分が決まれば一意に定まるDBを分割する。

商品番号 商品名 棚番号 棚名
001 メモ帳 101 紙類
002 付箋 101 紙類
003 鉛筆 102 筆記類
004 ボールペン 102 筆記類

主キーは「商品番号」。

上記の例だと「棚番号」がわかれば「棚名」がわかる。メモ帳は筆記類じゃないかって?細けえことはいいんだよ!!

なのでこれを

商品番号 商品名 棚番号
001 メモ帳 101
002 付箋 101
003 鉛筆 102
004 ボールペン 102
棚番号 棚名
101 紙類
102 筆記類

こうする。第二正規化と第三正規化はよくわからなくなりがち。

トップダウン / ボトムアップ分析

概念設計時に情報を抽出するときの分析方法。

itmanabi.com

わかりやすかった記事を貼っておく。

要件(全体像)をもとに「これが必要になりそう」「そのためにこの情報が必要」と分析していく。考慮漏れがおきることがある。

既存のDBや資料を基にデータ分析を行う。現状分析が主となるため新しく何かを始めるにはデータが足りない。

相互補完して進めていくのがベター。

ボトムアップ分析の手順

  1. エンティティ抽出
  2. 属性抽出
  3. 識別キー決定
  4. リレーションシップ抽出
  5. 正規形確認
  6. ボトムアップモデル統合

現在使っている伝票や発注表等から「顧客」「受注」「商品」等を抽出し、それを細分化していく。

識別キー決定やリレーションシップ抽出は順番が前後することも大いにある。

トップダウン分析の手順

  1. エンティティ抽出
    「商品の注文を受け」、「発注する」なら「商品」「受注」「発注」が必要だな、みたいな。
  2. 属性抽出
    将来的に必要になるであろう要素から属性を抽出する。
  3. 識別キー決定
    要件には出てこない要素のため、一般的に「商品番号」が必要だな、とくみあげていく。
  4. リレーションシップ抽出
    「1回の注文で複数注文ができる」のであれば「受注」と「商品」が1対多だな、といったところ。
  5. 正規形確認

トップダウンはインプットに対して1つのモデルが作成されるため、統合が不要。

ER図統合

トップダウン分析によって得られたER図とボトムアップ分析によって得られたER図を統合して1つのモデルにする。MECEに。

モデル見直し

目的

検索パフォーマンス向上のため。

join hoge join fuga(以下ループ)ってすると重くなるもんね。適度に結合するのも大事。

必要な情報

  • 非機能要件
    レスポンス時間、業務の運用要件等。
  • データアクセスの頻度 / 量
    1時間当たりどれくらい、ピーク時にどれくらい等。
  • データの性質
    各エンティティのデータ件数、1対多関係の多側のカーディナリティ、データ蓄積時間等

非正規化

テーブルの結合を行う。

www.accessdbstudy.net

詳しい記事があったので詳細はこちらを参照。

リンク先にもあるが「正規化を行わない」のではなく「正規化を行ったが、様々な要素を考慮した結果、あえて正規化したモデルを結合する」という手順が大事。それなら質問されても明確に答えられる。

導出項目の取込

導出項目とは、他のテーブルや列から導き出せるデータ項目のこと。

例としては集計が挙げられる。単価と個数から金額を計算するのか、注文数が膨大になるため「金額」を属性とするのか。こちらもパフォーマンスとの兼ね合いとなる。

サマリ・エンティティ

導出項目を保存するエンティティをサマリ・エンティティと呼ぶ。

集計する項目数が非常に多い場合は集計した結果をサマリ・エンティティに保存しておき、そこを検索することで処理時間を向上させるのが狙いとなっている。

代替キーの検討

amg-solution.jp

しばしば議論に上がるナチュラルキーとサロゲートキー。どちらにもメリットがありデメリットもあるのでよく検討することが必要。

物理設計

テーブル変換

ERモデルからテーブルに変換する。

  • エンティティ → テーブル
  • 属性 → 列
  • 識別キー → 主キー
  • 外部キー → 外部キー

と置き換える。

ささにデータの型や桁数なども決める必要がある。

ドメイン定義

属性の取りうる値の範囲を管理する。

属性の一元管理を行えるため、変更に強くなる。

codezine.jp

ドメイン定義を使おう、という記事(乱暴)。

テーブル分割

パフォーマンス向上のためにテーブルを分割することがある。

  • 垂直分割
  • 水平分割

cat-p0k0pen.hateblo.jp

わかりやすい。でもこの事例にはとりかかりたくないね。ディスガイアアプリ、元気してるかな…

月ごと、頻度ごと等で分けることで検索を迅速に。インデックスもこの考え方に通じるものがあるはず。

インデックス

www.atmarkit.co.jp

ややこしい内容だがしっかり理解するべき。

実データ検索ではなくポインタ検索、がポイントになりそう。C言語みがある…ないか。
検索したいデータとそのデータが存在するポインタのオブジェクトを検索し、そのポインタを用いてデータに直接アクセスするため、大量のデータを上から順番に見ていくより早くなる、という流れ。

更新に時間がかかるようになるため、データ量とにらめっこしてパフォーマンスが向上するかを判断する必要がある。

インデックスの効果

ガイドライン

  • where句で頻繁に使用する
  • 列の値が比較的一意
  • テーブルの結合で使用する
  • 更新の少ない
  • 比較的大きなテーブル

といった列にインデックスを当てると良い。

ビュー

実データを持たない仮想表のこと。

よく使うselect文に名前をつけ、そのデータに対して条件検索を行うことでパフォーマンスが上がる。

oracle.na7.info

必要とならないデータを隠す、という点でも利点がある。

仮想表に対しても普通のテーブル同様の操作ができるため、テーブルとビューの意識をせずに取り扱える。

物理設計

物理設計の範囲

  • OS / ハードウェア / RDBMSの選定
  • DB構造の定義
  • 運用計画の定義

DB内容以外のほぼ全て、ということになる。すごく広い。

物理設計の全体像

  1. OS / RDBMSの選定
  2. テーブル / インデックス定義
  3. 資源見積もり
  4. ストレージ構成選択
  5. セキュリティ計画
  6. パフォーマンス監視計画作成
  7. バックアップ / リカバリー計画作成

という流れとなる。最初から最後まで。

OS / RDBMSの選定

どの要素を落とすか、トレードオフ要素は何になるのか、等考えることは多い。頭を抱えよ。

テーブル / インデックス定義

テーブル

  • ヒープ表
  • 索引構成表

インデックス

  • 単一型索引、コンポジット索引
  • 一意索引、非一意索引
  • ビットマップ索引

資源見積もり

  • テーブル / インデックスの見積もり
  • RDBMSシステムファイルの見積もり
    ログファイルの領域、作業用領域、ディクショナリ等も考慮

ストレージ構成選択

安全性や性能を考慮し、どこにどのデータを格納するかを検討する。

ファイルアクセス

  • テーブルデー
  • インデックスデータ
  • ディクショナリ
  • 作業用
  • ログ

といったようにアクセスを分散させるようにする。

データ格納方式

  • ファイル・システム
    頻繁にやり取りする場合パフォーマンスが低下する。
  • RAW
    ファイル・システムを使わないため読み書きの速度が速いが要領の拡張やファイルコピーが難しい。

セキュリティ計画

構成要素

  • ユーザーアカウント
  • 権限
  • ロール
    ユーザーに対する権限の付与 / 剥奪を楽にする機能。ユーザーに対して権限を1つずつ与えるのではなく、予め一定の権限が与えられたロールを付与することで権限操作が楽になる。

不正アクセス防止のため、監査機能が重要となる。

パフォーマンス監視計画作成

パフォーマンスが悪くなっている兆候が見えた時点で対応する方が当然ながら良い。

そのため、定期的にパフォーマンスをベースラインと比較して監視する機能を活用すると対応が後手に回らない。

バックアップ / リカバリー計画作成

  • バックアップ

「データは壊れるもの」である。そのため、オンラインバックアップ / オフラインバックアップを定期的に行う必要がある。

バックアップ方式により環境構築に変化があるため考慮が必要。

まとめ

今日の内容はあくまで基本。実際に手を動かす過程で得られる知見、経験を大事に知識を拡充させていくのがベスト。

めっちゃ書いた。今日の執筆時間は動画が4時間くらいあったため調べる時間と併せて3時間程度。

ではまた。

【備忘録】 モチベをマネジメントする

うぃろぅです。

今日も今日とて。

今日のテーマ

PLに求められるモチベーションマネジメントスキル

プロジェクトリーダーでなくともモチベをマネジメントする機会はあるでしょ。何かの準備をみんなでするとか。

定義

モチベーションを「働く意欲」と定義する。

理由付け、動機付けというイメージ。

観点

  • 価値観
    個々の違いを認識してアプローチすべき。
  • 使命感
    お客様に感謝されたい / 会社の目標を達成したい / プロジェクト目標を達成したい等。
  • 自信
    能力、環境が充足しているか

で成り立っているものとする。

モチベーション維持の要素

  • 目標に向かってやるべきこと
  • 個々がやりたい仕事内容
  • その仕事をできる、という気持ち

を相互理解するコミュニケーションが重要。

基本動作

全体像

コミュニケーションの基本

マネジメントの基本はコミュニケーション。

そのために大事なことが以下。

  1. 積極的傾聴
    具体的な問いかけが重要。
  2. 説明責任
  3. マナー

それぞれに対する内訳

  • 方針明確化
  • 指示明確化
  • 正しい評価
  • 体制最適化
  • 部門間調整
  • 人材育成

モチベーションの創造者 / 破壊者

  • 創造者
    「問題があったら俺が責任を取る」「困ったことを相談したらいつでも真剣に乗る」が大事。
  • 破壊者
    「明日からうまいことやってくれ」「上司の言いなりになっている姿が見える」はダメ。

相手からすると、「正当に評価されているか」はかなり重要な点。しっかりとコミュニケーションをとり、相手に評価を伝えるべき。
メールの返信は忙しくともきっちりとするべき。

「いまどきはメールのコミュニケーションも多い」とのことだがいまどきはSlack等のコミュニケーションツールなのではなかろうか。

積極的傾聴

スキルは以下。

  • うなずき
  • 鸚鵡返し
  • 言い換え
  • 引用
  • 接点の発見
  • 共感
  • 意味づけ
    相手の話から重要な点を見つけて指摘すると相手はより積極的に発言する。

説明責任

プロジェクトの内容に変更があった場合、速やかに説明をしなければならない。反応を予想して萎縮する方が良くない。

異動の話を喫煙コーナーでしかきかない。
見通しの悪い典型例。私の会社がまさにそれ

コミュニケーションのマナー

  • 成長のために叱る
    自分のイライラをぶつけるのはNG。
  • 叱る基準をしっかり持つ
    かわいい子は叱らない、はNG。むしろかわいい子に言うのが楽しいって言っていた高校時代の同期、この前飲んだら「泣き顔もかわいかった」って言っててやべえなこいつってなった。
  • 叱り方に注意する
    責めるような口調はNG。
  • TPOに配慮する
    「すぐに」「1対1で」「内容を考慮して」叱るべき。
  • 褒める時は褒める

方針の明確化

  1. ビジョンを提示
    長期的
  2. 戦略を提示
    中長期的
  3. プロジェクト方針、役割、方向性の提示
    短期的

を明確に行うことが重要。

指示の明確化

  1. 命令系統の明確化
    「どの作業が」「誰から」指示されるのかを明確にする
  2. 納得する指示

  3. 自ら考えて指示を行う
    言いなりにならない

  4. メンバーの状況を把握する
  5. 作業目的 / 背景を明確に示す
  6. 作業負担を考慮する

「お願いできませんか?」という訊き方をすると現在の状況を示しつつ引き受けてくれることが多い。譲歩の選択肢があるということが大事。

正しい評価

日々のコミュニケーションの中でこまめにフィードバックすることが重要。

「こういったことを期待しているからね」と事前に伝え、達成できているときは「すばらしい」と褒めるとモチベが維持できる。

「私だったらこうするかな」という言い方は強制力が弱いため伝えやすい。

「君らしくないな」から始めるといい、と講義では説明されていた。どうなんだろうねこれ。

私だったら「らしくないじゃん、どうしたの?」って訊かれたら「私の何がわかるんだ」となってしまう。根っこがひずんでゆがんでいるので。「ひずむ」も「ゆがむ」も同じ漢字なの面白いよね。
「私のことは私で決める」という人ほど「君らしくない」とは言われたくないんじゃないかなあ。そこはコミュニケーションの過程で見極めることなのかしら。

体制明確化

  • 実現可能性を考えた体制作り
  • 柔軟な見直し
    横並びにするとか人数を調整するとか。
  • 体制改善提案は堂々と働きかける
    交渉する姿を見せる、ということが重要。「やってくれている」感。

部門間調整

  • 壁を越えた協力支援体制の構築
    困ったときに他部門ならあっさり解決できることはいくらでもある。
  • 役割分担量定義
    仕事が役柄にではなく人につきがち。調整はしっかりと。難しいところなのだけれどね。
  • 仕組みづくり
    コミュニケーションの方法は事前に調整しておく。

人材育成

  • 現状把握
  • 育成計画策定
  • 徹底した計画実行

人は勝手には育たない。

私は会社外を見始めているので勉強しているがそうでない人のほうが多いよねという話。私が真面目に取り組んでいるかは別の話だよ!!

まとめ

今回の内容はあまり具体的ではないため、参考にしつつ掘り下げて習得していく必要がある。

2倍速で聴いたから1時間ぴったりくらい!!2500文字くらい!!会社のキーボード入力しづらい!!!

ではまた。

【備忘録】 SE向け問題解決スキル

うぃろぅです。

今日も今日とてやっていきます。日々を積み重ねていこうな。

今日のテーマ

SEに求められる問題解決スキル

定義

「問題」を、「現状あるべき姿と現状とのギャップ」と定義する。

「1秒以内にレスポンスする」が「2秒かかっている」だとこの1秒のギャップが問題点となる。

アプローチ

  • 解決
  • 予防

の2点でアプローチする。

  • 仕様が固まらない
  • スケジュールの遅延
  • 大量バグ
  • トラブル対応マニュアルがない
  • パフォーマンス低下
  • システムダウン

悪夢だなぁ。打合せするたびに仕様追加してくるような客先、大変だった…。

理想

こんなSEは良いよね、という例

  • 問題の予防ができる
  • 問題を早期発見できる
  • 問題の優先順位を明確につけられる
  • 問題に対して恒久対応ができる
  • 問題解決策の妥当性を説明できる

たしかにこうありたくはある。

解決に向けて

湧き上がる問題を分析すると根本原因が1つに定まる、ということがある。
バグ表にもよく根本原因を記載する欄がある。丁寧な分析、大事。

プロセス

暫定対応

  1. 問題発見
  2. 対応策検討
  3. 実行 / 効果確認

恒久対応

  1. 問題発見
  2. 問題分析
  3. 原因分析
  4. 解決策立案
  5. 実行 / 検証

恒久対応のプロセスについて順番に見ていく。

問題発見

  1. あるべき姿を確認する
  2. 現状把握
  3. 問題認識

「本来こうであるはず」が「こうなっている」ため、「これが問題になっている」
という論法。バグ表はこの順で書いてくれ頼む~~~~~。

問題分析

  1. 問題に関する情報を集める
    緊急性 / 影響範囲等を見極める
  2. 問題を評価する

という流れ。これで解決すべき問題を選出する。

原因分析

  1. ロジックツリーを使って問題の原因を展開する Whyツリーを使う。
  2. 根本原因を見つける
  3. 目標 / 課題を設定する

vviilloovv.hatenablog.com

これあの時やったやつだ!! という気分になっている。やるやん私。

解決策立案

  1. ロジックツリーを使って解決策を展開する
    Howツリーを使う。
  2. 解決策を見つける
  3. 解決策のアクションプランを作成する

適切な優先順位をつけ、具体的に解決策を提示するのが大事。言うのは簡単なんだけれどもね。

「いつまでに」「誰が」「何を」「どのように」やるか。5W1H

実行 / 検証

  1. 実行
  2. 検証
    監視 / コントロール

読んで字のごとく過ぎる。PDCAサイクルのDとCかしら。

思考法

仮説思考

いくつかの情報から類推して仮説を立てる。

スピードがあるため暫定対応するために使うことが多い。

精度を上げるために検証はしっかり行う必要がある。

「雲行きが怪しい」から「雨が降るかもしれない」ため「傘を持っていく」時はこの思考法をとっている。私は基本的に折りたたみ傘を持っている

フレームワーク思考

MECEを実現するために…ってこれやったな。

QCDとか5W1Hとか4Pとかに乗っかることでMECEが実現できる。
4Pに乗っかるって書いてちょっとテンションが上がるなど。昼はダメだわ。ならいつならいいんだ

ゼロベース思考

ココベース!? 違いますかそうですか。

既存の枠を取り払い、ゼロの状態から答えを模索する思考法。

型にとらわれるな! っていうあれ。でも新しい意見がほしいって言われたから考えて出すと「前例はあるの?」って訊いてくる上司もいるとかいないとか。どうしろと。

ゼロベースにするきっかけとして、オズボーンのリストを参照。
オジンオズボーンは関係ない。

jairo.co.jp

問題解決ツール

ロジックツリー

なぜなぜとかのあれ。

www.missiondrivenbrand.jp

今回も貼っておく。

  • MECEを意識する
  • 因果関係を保つ
  • 具体的な原因や解決策になるよう掘り下げる

が留意点。

マトリックス

行と列で問題を分析し、解決する。2軸評価。
PPMとかSWOT分析とか。大学のときにやったな…。あとはITストラテジストの勉強をしていると出てくる。

takuminotie.com

www.darecon.com

www.innovation.co.jp

目的を明確にして、その目的に関する情報を収集してプロットする。

2つの方法に対してメリット / デメリットを羅列していくのもマトリックス
HDD / SSD をメリットデメリットで選ぶみたいな。

パレート図

www.sk-quality.com

問題解決の優先順位を判断するために用いる図。

「問題の80%は20%の原因によって発生する」というパレートの法則に基づく。

予防に向けて

ここからは予防に向けての方法。

予防の重要性

将来的なリスクを回避 / 軽減でき、負担が減る。

問題予防プロセス

リスクマネジメントプロセス

  1. リスクの洗い出し
  2. リスクの分析 / 評価
  3. リスク対応策の立案 / 実施
  4. リスクの管理 / コントロール

解決プロセスとよく似ている。

まとめ

とにもかくにも論理的思考。順番に身に着けていこう。

ではまた。

【備忘録】 論理的思考を磨く

うぃろぅです。

e-ラーニングシリーズです。サクサク進めましょう。

今日のテーマ

ビジネスシーンにおける論理的思考力向上

定義

論理的思考を、「物事を深く・俊敏に考え、わかりやすく伝えるために、体系的に筋道を立てて考えること」と定義する。

風が吹けば桶屋が儲かる

風桶理論、なんて言いかたをすることがある。

風が吹く → 砂が舞う → 盲目の人が増える → 三味線の売上げが上がる → 三味線の製造が増える → 三味線は猫の皮を使うため猫が減る → ねずみが増える → 桶がかじられる頻度が上がる → 桶屋が儲かる

筋道は立っている。現実的かどうかはさておくとして。

ただこれでは全体像が見えてこないため、筋道を立てて考えつつ全体像を把握することも重要となってくる。

メリット

  • 自分自身の思考をチェックできる
    自分の考えの見通しを持つことで相手に正しく伝えることが可能となる。

もう何点か出てきそうではあるが。

スキル

基礎 / 土台

  • 倫理的思考 / 表現ツールの知識
  • コミュ力
  • プレゼン力

応用 / 実践

  • 問題発見力
  • 分析力
  • 情報収集力

やっぱりコミュ力は何においても必須なんだなあ。険しい。

論理的思考法

帰納法

  1. バナナの味は?

バナナは果物らしい → 果物といえばりんごやみかん → りんご、みかんは甘い → 甘いんじゃないか

みたいな。

AならばBBならばC、よってAならばC、のような感じ。大体こういう論法は人をだまくらかすために使われがち。

帰納法に用いるデータの有用性をしっかりと証明できなければ詭弁にしかならないため、注意が必要となる。

ロジックとしては複数のデータから仮説を立て、結論を導き出すというもの。それ自体は有効。

演繹法

論拠ありきの考え方。

例えば「力士は男性しかなれない」というルールがあったとする。
なんてったって土俵にも男性しか上がれないもんね。他意はない。
ここで、「Aさんは力士である」という情報を得た場合、「Aさんは男性である」と推測することができる。

こちらの思考にも限界はあり、論拠が不適切であったり、有効でなかったりした場合成り立たなくなる。

論拠の有効性
  • 一般的に認められている理論
  • 普遍的な事柄
  • 公理 / 定理
  • 業界の常識

こういった論拠がなければ危うい理論となる。

MECE

  • Mutually: 互いに
  • Exclusive: 排除的で
  • Collectively: 集めると
  • Exhaustive: すべてをつくす

漏れなく、ダブりなく考える。

MECEな例

  • 自動車を排気量別で分類する
  • 人間を年齢で分類する

数字で分けると網羅的。

MECEでない例

  • 映画をジャンルで分類
  • 自動車を車種で分類

漏れやダブりが存在する可能性がある。

留意点
  • 分類を細かくしすぎない
    100円区切りにしちゃうとか
  • 「その他」を大きくしすぎない
    「哺乳類」「爬虫類」「その他」みたいな

MECEにするために

5W1H、とか3Cとかのようにあらかじめ決めてある枠組みで考えると実現しやすい。

表現ツール

  • ロジックツリー
  • ピラミッドストラクチャー
  • イシューツリー

ロジックツリー

www.missiondrivenbrand.jp

ある物事をロジックによってツリー状に展開する。

見た目は樹形図のようになる。
なぜなぜ分析はロジックツリーの例のひとつ。
「根本原因」「直接原因」「すり抜け原因」もそれに近いような気がする。

これにより、因果関係を明確にできる。

ツリーの型
  • Whyツリー
    なぜなぜ。因果関係が正しいかに留意する必要がある。
  • Howツリー
    どうしたらどうしたら。

会社をやめるにはどうしたら → 退職願を出す までの流れを考えるみたいな。他意はないよ。

ピラミッドストラクチャー

boxil.jp

論理的主張とその理由を構造的に表現するツール。

複数のデータから論拠を導き出す、帰納法の応用といったところ。

イシューツリー

www.fw4students.com

「○○すべきか?」を構造化して考える。

ツリーが平行線になりやすいため、追加 / 修正は細かく行う必要がある。

論理的に相手を説得する

方法

  • 信頼関係構築
  • 話を聴く
  • 論理的に話す
  • 効果的な質問をする
  • 詭弁に注意する

だいたい読んだまま。

信頼関係構築

  • 心身の健康管理
  • 身だしなみ
  • 相手への配慮

言葉でのやりとりは全体の35%程度とされていて、残りの65%は言葉以外、態度や言葉遣い等に因るところが大きい。

話を聴く

これができない人がtwitterには本当に多いように見える。あえてそうしているのかもしれないけれどね。

  • 相手を尊重
  • 先入観を持たない
  • 共感しつつ反応する

話を聴くのは割とする方。「これはこの人にはあの人が話してないよな」って考えながら会話するの、頭は使うがとても楽しい。言わないと信じて秘密を共有してくれている人には全力で応えるのが義務だよね。

論理的に話す

因果関係がしっかりしていて、反応を見ながら段階的に話すのが大事。

  • 構成
    理解しやすい構成で話す。結論から話すのがよくある。
  • 表現
    あいまいな表現を避ける。あえて言い切ってしまうことも時には重要となる。

「レビューお願いします」「完璧??」「完璧です!!」とすることで相手も「よっしゃホントに完璧か見たるわ」と乗り気になってくれる。

効果的な質問をする

質問の目的

  • 自分が納得するため
  • 相手にわかってもらうため
  • 自分の伝えたい意思、意図を明確にするため
  • 自分の意図が伝わっているか確認するため

  • 拡大質問 / 特定質問
    「どの声優が好き?」「花澤香菜さんが好き?」等。

  • 否定質問 / 肯定質問
    「このイベントこないの?」「頑張ってこのイベこれない?」等。
  • 過去質問 / 未来質問
    「なぜ?」「どうしようか?」等。

詭弁に注意する

詐欺師の手法。twitterでたまに見る怪しげなサイト、楽しい。

実は人間の100%は人間なんです!!!みたいなやつ。

論理の飛躍は注意しておかないとしてしまう恐れはある。

効果的に反論する

  1. 相手の主張を理解して
  2. 妥当性を確認する

を繰り返すことでほつれている論理がないか、ごまかしている箇所がないかを精査すると良い。自分としてはフローチャートレビューをするときに割と考えることが多い。

まとめ

論理的に考え、信頼関係を大事にコミュニケーションをとろうね。ってことなんだと思う。

ではまた。

【備忘録】 伝えにくいことを伝えるスキル 実践編(のはずが雑記)

うぃろぅです。

vviilloovv.hatenablog.com

このエントリーの続き。実践編だそうです。果たして新たな学びを得られるのか。

※ 重複している内容が多かったため、中盤から「講義聴きながら適当に何か書く」企画と化しました。1時間1本勝負。よろしくお願いします。

職場におけるコミュニケーション

経験を思い出す

前回やった。

もう最近いろいろ疲れちゃって「こう言ったら嫌われそうだし面白そうだな」って発言しちゃうことが職場においてのみある。多分良くないんだよなこれ。

アサーティブ・コミュニケーション

「自分の感情を気にする」ことがやはり大事。

営業は自分の感情を気にしないことが多々あるよね。もはや営業とはそこまで良好な関係を築きたいと思っていない。週頭は考えがすさむね。良くない。

  • 相手の気持ちをきちんと聴くことも大事

「どうして~なの」という訊き方は相手を非難しているように聞こえるためNG。
会話していく中で理由付けをお互いに確認する流れにするのが大事。難しい。

内容がめっちゃ重複している

月曜の午前中に学習しているから内容が入ってこないのかと思ったが、だいたいが先週に聞いた内容だから聞き流しているっぽい。

2倍速で再生しても内容わかるってすごい。

DESC

  • Describe: 現状把握
  • Explain: 説明
  • Suggest: 提案(具体案)
  • Choose: 選択、判断

これ、自分の行動選択においても割と使えそう。

例えば転職しようか迷っている人1がいるとして、

  • D: 労働環境が悪い、土日に休めないetc.
  • E: 精神的に滅入っている、友人と遊びたいが日程が合わず辛いetc.
  • S: まず上司に相談する、転職活動のために有給を使うetc.
  • C: 条件付きで働くスパンを変える、転職するetc.

という取り組みができる、みたいな。頭働かなさすぎて笑えてきちゃう。

周囲への影響がよければ妥協して引き受ける、みたいな説明がたまにあるがそれは自分の気持ちを尊重していないのでは?

周囲の私へのイメージ

あんまり関係ないけれど、重複したことを書くことは自分としても楽しくないのでぼちぼち書いていく。

私の職場でのイメージを聞く機会があったのだけれど、その内容が以下。

  • 「月次報告書に『宴席が増える時期なのでセキュリティに十分配慮したい』とか書いてあってこっち(管理業務の人たち)で話題になったんだけど飲み会とか行く人なの!?」
  • 「(上司とのコミュニケーションが上手くいかず辞める後輩の話題の流れで)うぃろぅくんみたいに『嫌われたらそれでもいっかー』みたいな気楽っていったらアレだけどあんまり重くとらえてない人ならともかく、後輩くんは結構考えちゃうタイプの子だから大変だよね」
  • 「(報告書提出のために帰社した上司に挨拶した私に対して)あ、今俺に挨拶したの? うぃろぅのことだから挨拶しないでスッと自席に座ると思ってたからびっくりしたわ」

無論職場では本名呼びだが載せるようなものでもないため伏せた。

私はなんだと思われているのか。最後とか実践したらただの無礼。

無事こんな感じのポジションを獲得できているので維持していこうと思う。

飲み

友人となら基本的に誘われたらほぼ飲みにいっている。
バイト先の友人には「飲みあるけど来るよね? 知ってた」と言われるレベル。逆に私を何だと思っているんだ。行くけど。

今の職場の人があまり自分が得意としているタイプでない(ことが多い)ため、職場では基本的に断っている。気持ちよく酔えないし。
仕事の外でまで気を遣いたくない。ないよね??

と思っていたらバイト先の友人(小悪魔系。かわいい。既婚者)曰く

「私の言葉とか気を遣った行動で相手が気分良くなっている様を見るの、楽しくない??」

とのこと。なるほどホスト気質。接客に向いているんだと思う。飲食はもうやらないって言っていたけれど。結婚できてよかったね。

性格評価

まさにその通り過ぎて笑ってしまった。最初にやったバイトでは

「俺先輩に嫌われるの得意なんですよー(ヘラヘラ)」
「だろうね(真顔)」

という一幕があったレベル。人として問題しかねえ。

上司への挨拶

いくら私が人見知りとはいえ仕事中はちゃんと挨拶する。逆にそうでない場合ほとんどしゃべらない。ラーメン屋さんで店員さんに話しかけるのすら苦手。
昨日発言したのは「ハリガネ、ねぎ抜きでお願いします」「替え玉ハリガネで」「ごちそうさまでした」の3回のみ。こうやって人は言葉を忘れていくのだと思う。

1時間経過

2倍速で流していた講義動画終了のため今回はここまで。講義の内容はある程度理解したため問題ないよ。多分。

ではまた。


  1. 例えばだよ、例えば

【備忘録】 伝えにくいことを伝えるスキル

うぃろぅです。

私が今所属している会社、基本的に社員に投資をあまりしないのですが、どうやらそれは良くないということにようやく気付いたのかe-ラーニングをすることになりました。

で、そのe-ラーニングは動画+スライドでやっていくのですが、アウトプットする場所が報告書1の「理解したこと」スペースしかないのです。

というわけなのでこちらにアウトプットします。当然丸写しは禁止のため理解したことをぼちぼちと。

概要

アサーティブ・コミュニケーション

自己主張しつつ相手を尊重するコミュニケーション。

コミュニケーション

複数人で作り上げるイメージ。積み上げるのは難しいが、崩すのは簡単。

はじめに

  • 上司に上手く断れない
  • 萎縮してしまって質問できない
  • 恥ずかしいから飲みの場以外で人を褒めにくい
  • 言いたいことは言えるが、その後の空気が若干おかしくなる

→ 自分自身の中に葛藤が生まれている

自身の振り返り

  • 状況
    終電で帰りたかったがテストが全く進まず上司に「もうちょっと残れない?」と訊かれる。
    「帰りたい」という旨を伝えると「みんな頑張ってるんだからさ」と諭される。
  • 対応
    「そういう言い方は嫌いです」と伝え、終電で帰る。
  • 結果、気付き
    終電で帰って良かった。

アサーションとは

自分・相手を大切にする自己表現

自己表現のタイプ

  • 攻撃的
  • 非主張的
  • アサーティブ
    歩み寄りを行うタイプ

なんでひとつだけカタカナ語を使い始めるんだ…。

生まれた背景

アメリカで権利を守るために生まれた考えらしい。

コミュニケーションできない原因

  • 思い込み
    自分の考えが言外で伝わっていると思い込み、コミュニケーションを進めた結果すれ違いが生じてしまう。

ワーク

0(一致していない) ~ 4(一致している)で答える

1: 自分のすることは、誰にでも認められなければならない
2: 人は常に有能で、適正があり 、業績を上げなければならない
3: 人の行いを改めさせるには、かなりの時間とエネルギーを費やさなければならない
4: 人を傷つけるのは非常に悪いことだ
5: 危険や害がありそうなときは、深刻に心配するものだ
6: 人は誰からも好かれなくてはならない
7: どんな仕事でも、やるからには十分に、完全にやらなくてはならない
8: 人が失敗したり、愚かなことをしたとき、頭にくるのは当然だ
9: 人が間違いや悪いことをしたら、非難すべきだ
10: 危険が起こりそうなとき、心配すれば、それを避けたり、被害を軽くしたりできる
出典: 『アサーション・トレーニング』 平木典子((株)日本・精神技術研究所 2012年) P81

答えていく。

  • 自分のすることは、誰にでも認められなければならない
    0。そもそも私が普段していることが誰にでも認められる必要がないと考えているため。

  • 人は常に有能で、適正があり 、業績を上げなければならない
    0。業績を上げなければならないという強迫観念は持ち合わせていない。

  • 人の行いを改めさせるには、かなりの時間とエネルギーを費やさなければならない
    4。自分 > 環境 > 相手 の順で変化させやすいと考えているため。誰かに何かを言われたって結局自分が変わろうと思わなきゃ変わらないでしょ。

  • 人を傷つけるのは非常に悪いことだ
    4。悪いことじゃなかったらなんなの。

  • 危険や害がありそうなときは、深刻に心配するものだ
    2。質問がふわっとしすぎているけれど、例えば誰か一人の命と引き換えに誰かが救われるとして(ミスチル is God)、それが自分の大切な人であれば多分私は普通に自分の命を差し出すが、逆はしてほしくない。エゴだね。相手にとって自分が大切かどうかは良く考えてから動いた方が良いとは思うけれど、今のところそれを実感できる相手が非常に少ないからこう言えるのかもしれない。

  • 人は誰からも好かれなくてはならない
    0。むしろ苦手な人からは嫌われたいタイプ。こちらとしては無関心でありたい。

  • どんな仕事でも、やるからには十分に、完全にやらなくてはならない
    0。そんな考えでは個人開発なんてできないでしょ。

  • 人が失敗したり、愚かなことをしたとき、頭にくるのは当然だ
    0。価値観による。笑えるものは笑い飛ばして生きていこうな。

  • 人が間違いや悪いことをしたら、非難すべきだ
    0。非難するよりも原因を究明して再発防止を心がけるべきだと考えている。

  • 危険が起こりそうなとき、心配すれば、それを避けたり、被害を軽くしたりできる
    0。心配するのではなく行動しないと。

「3」「4」がついた設問をわかるようにしておく。

自分は

  • 人の行いを改めさせるには、かなりの時間とエネルギーを費やさなければならない
  • 人を傷つけるのは非常に悪いことだ

この2つ。

何がわかるか

「3」「4」をつけた項目は思い込みをしている可能性がある。

私の場合

  • 自分の思い通りにならないことを嫌う
  • 人を傷つける言動に対して、自分にも他人にも厳しくなる
  • 人と接するときに相手の様子をいつもうかがっている

という傾向があるかもしれないらしい。

これが多いと自分に負担がかかってるケースが多いかもしれないため、「自分は思い込みを持っているのかもしれない」という認識をする必要がありそう。

ビジネスにおいて必要なスキル

  • コミュニケーションテクニック
    伝わりやすい論理構成、より効果的に伝えるための手法等。
  • 考え方・心構え
    これから学習する。
  • 業務遂行のために必要なスキル・知識
    環境理解等も含む。

今回は「考え方・心構え」を中心に学ぶ。

以上で前提終了。

内容

アサーティブ・コミュニケーション

アサーティブなシーン

  • 無理なときに無理と伝える
  • 反応を恐れずに自分の考えを伝える
  • 素直に褒める
  • 自分の行動に責任を持つ

相手のことを配慮しながらも素直に表現することがポイント。

case.1

ものを片付けないことに対する言い方

ダメな例

「何で片付けないの」
→ 「…」 「そうやってすぐ黙る」

みたいな言い方をするとうまくいかない。そらそうよ。

どうすればいいか。

「雑誌を読んだら本棚に戻してくれると嬉しい」
「私は綺麗な状態だと嬉しいから、お願いできる?」

のように

  • 具体的にどうすればいいか伝える
  • 相手を責めるような言い方をしない

のが良い。動いてくれたら感謝の気持ちを伝える。

動画によると、雑誌を読むこと自体は責めないようにするとなお良いとのこと。そうね。

ビジネスシーン

  • 他の作業を抱えているが作業を依頼されたとき

急ぎの作業があるためその後で、のように条件付きで引き受けるようにする。相談大事。

メリット

  • 自分のストレス軽減
  • 自分の発言に対する周囲の根拠把握

把握してくれるといいよね…。

注意点

「感情的になる」と「感情を伝える」は別。

私怒っていないのに怒っているように見えることがあるらしい。顔か?顔なのか??

心構え

  1. 誠実
  2. 率直
  3. 対等
  4. 自己責任

の4点を意識する。

上司だから、お客様だからと萎縮する必要はない。
自分は人として対等だと考えていても上司は相手を下に見ている可能性については言及していない。こちらを人と思っていないお客様だっているよね??私は経験ある。

手順

  1. 自分と会話する
  2. 相手と会話する

という流れを意識する。

自分と会話する

  1. 自分を客観視する
  2. 自分の本音をつかむ
  3. 相手への要望を言葉にする
  4. 落としどころを描く

相手と会話する

  1. 現状を客観的に伝える
  2. 相手への要望を建設的に提案する
  3. 相手の感情を理解しようとする
  4. 相手と協力して結果を作り上げる

会話には頷きや相槌、要約やアイコンタクト等適宜コミュニケーションの基本は抑える。
言葉で書くと難易度めっちゃ高いなコミュニケーション。なんなんだ。

case.2

いつも会議に遅れてくる上司にどう伝えるべきか

ダメな例

「忙しそうですね、来月ももしかしたら遅れそうですか?」
→「そうだな、来月は何とか間に合うようにしたいな。できるかわからないけど」
「そうですね…。わかりました、よろしくお願いします」

他の人の稼動をとっていることを重要視していない上司の時点で絶対仕事できない人だぞ

なにがわかったのか。絶対この人来月も遅れるでしょこれ。

良い例

「会議の運営について改善が必要だと考えています」
「まず遅れないようにしてほしいです。遅れる場合、議題の決定権を私に委任してくださいませんか」

のような感じ。現状を伝えて解決策を提示。

case.3

定例会議での部下の報告内容が事前の打ち合わせ内容と異なっている場合

ダメな例

「報告が遅いぞ、変更があるなら定例より早めに伝えてくれ」
→「ちょっと違ったくらいなのでいいかなと思いまして」
「わかってないな、次回からは定例会議の日の朝一で最終報告に来い」

Slackのようなコミュニケーションツール使えば密に連絡できるんじゃないかなって。 あとあんまり気にするところではないと思うけれど原文では部下が「すいません」って言っていることが引っかかる。

良い例

「違っていることに関して、何か経緯があったの?」
→「あ、すいません。(理由説明)」
「なるほどね。あの場で他の人に突っ込まれたときにフォローしたいと考えてるから些細なことでも事前に知っておけたら助かる。客先から連絡できないなら定例会議当日の朝とかでもいいからさ」

自分のしたいことを伝えつつ報告を促す。

DESC法

DESC法とは、問題解決に関するコミュニケーションにおいて、伝えたい内容をあらかじめ4つの観点で整理する手法。

他人を傷つけずに自分の言いたいことを伝える「DESC法」のすすめ - ねとらぼ

調べて出てきた記事を貼っておく。

  • D=Describe(描写する)→客観的に状況や事実を述べる
  • E=Express(表現する)→自分の意見や感じていることを表現する
  • S=Specify(提案する)→相手にしてもらいたいことを、明確な言葉で提案する
  • C=Consequences (結果を伝える)→提案したことが実行されたとき、されない場合の結果を伝える

上記記事から引用。

これまでやってきたことを簡潔にまとめた、といったところ。

まとめ

  • 「心構え」を意識して、相手の立場を理解してコミュニケーションを行う
  • DESC法を理解し、効果的なコミュニケーションをとる

こんなところか。自分の感情を伝えることは積極的にはしていなかったような気がするので心がけていこうかなと。

ではまた。


  1. 当然Excel方眼紙。セル結合のオンパレードなのでまともにコピペはできないわ入力すべき箇所がわかりにくいわでさくっと入力欄を別に作ったのは当然の流れ。