スタッフブログ

ビットスターではITで「こまった」事を「企画・提案」「インフラ構築」「Webサイト制作」「システム開発」「監視・保守」などワンストップで提供し、「よかった」にできるのが強みの一つとしてあります。 全員が全ての業務を一人で行えるスーパーマンであればいいのですが、現実的ではなさそうです。 なので「チーム」でサービスを提供していく事が大事になってきます。 チームプレー次第で１＋１が５になる事もあるし、逆に０．１にしかならない事もあります。 ビットスターでは在宅勤務を通常の勤務形態として取り入れた事もあり、チャットツールやテレビ会議でコミュニケーションをとる事が当たり前になってきました。 対面でのコミュニケーションからリモートでのコミュニケーションが増えてきた今だからこそ、チームプレーってなんだろう？って今一度振り返る事があったのでそれをネタにしてみました。 チームの定義 そもそも「チーム」ってどういうことかって事ですが、似たような言葉で「グループ」があります。私は「グループ」と「チーム」を以下のように定義します。 グループは「2人以上のメンバーがいる集団」 チームは「共通目的を持った2人以上のメンバーがいる集団」 ドラえもんで言うと同じメンバーでも空き地に集まっている時は「グループ」ですが、のび太の大魔境で秘境を探検する時は「アフリカの石像を探しに行く」って共通目的を持ったので「チーム」になります。 ということでチームで活動するためには「共通目的を持つ」事が前提となります。 なので「共通目的」をチーム全体で認識しましょう。 でないとそもそも「チーム」とは呼べなくなってしまいます。 チーム特性を知ろう チームと言っても業務形態や役割などからいろんなチームがありそうです。 チームでもいくつか特性があります。 分類する要因として「環境の変化度合い」「人材の連携度合い」を軸に考えます。 代表されるスポーツに例えると以下の4つに分類されます。 ビットスターでは業務内容からサッカー型に分類されるチームがよさそうです。 ここからは文字で説明が大変になってきたので図で説明します。（急に雑に。。。） ビットスターでは確認頻度が多い業務のようです。 では、確認頻度が多い業務で効果を出すにはどうしたらいいでしょう？ それは「心理的安全性を高く」するといいようです。 心理的安全性をつくる 昔からあった考え方のようですがGoogleがこの考えを取り入れた事で最近よく聞くようになってきました。 ようは恐怖や不安を感じることなく、誰もが自由に発言・行動できる状態を「心理的安全性が高い」と言うようです。 心理的安全性が高いとメンバーの能力を最大限に発揮でき、結果として生産性向上につながるようです。 意見がいいやすい状況にもなるので、新たな考えなどが生まれやすく創造性も向上するみたいです。 意思決定 チームプレーするにあたり必ず意思決定が必要になります。意思決定には「独裁」「多数決」「合議」があります。 サッカーで監督が「〇〇！△△と交代だ！アップしとけ！」ってこれは独裁による意思決定ですね。 キャプテンが試合前に円陣を組んで「絶対勝つぞーー！」「オー！」っていう「オー！」が合議ですね。 試合後の反省会で「あの時に7番のマーク外しちゃったのが失点の原因じゃね？」「俺もそう思う」「いや、それだけじゃないよ」なんてのが多数決かな。（例えが悪い気がする） 意思決定の方法はそれぞれの特性を理解して状況によって使い分けるのがよさそうです。 「伝わる」までが仕事 もはや画像貼り付けるだけ。。。 さいごに 私はチームワークとかチームプレーってこういう事なんだ！っていう好きな言葉があります。 「～し合う」「共に」ってところがミソです。 オチ 今まで、あたかも自分で考えた事のように書いてきましたが、全て以下の本の内容です(笑) 読んだ事ある人は途中で「おや？これって。。。」ってなったと思います。 チャンチャン MRT

突然ですが、ことわざで「井の中の蛙、大海を知らず」と言うのがあります。 これはご存知の通り、井戸の中に住む蛙は、井戸の中が世の全てと思い、外にもっと大きな世界がある事を知らない、という事から知識、知見が狭い事の例え、またそれにとらわれて広い世界がある事に気づかず、得意になっている人の事を言う時に使うことわざですね。 最近は、今まで関わった事のなかった「宇宙」に関わる仕事をしており、まさに自身が「井の中の蛙、大海を知らず」と思う事が毎日のようにあるのでそれをネタにしてみました。 ちなみに今関わっている仕事とは全然関係ない話題です。 放射性廃棄物の処分方法 放射性廃棄物の処分方法に関しては、 地層処分（地面深くに埋めちゃおう） 長期管理（安全に処分する方法が見つかるまで取っておこう） 海洋底処分（深海に沈めちゃおう） 氷床処分（南極の氷の下に埋めちゃおう） 宇宙処分（ロケットに載せて太陽にポイして燃やしちゃおう） が国際機関や世界各国で検討されてるそうです。 多くの国は「地層処分」と「長期管理」の方法をとっています。「海洋底処分」はロンドン条約で禁止されており、「氷床処分」も南極条約で禁止されています。 「宇宙処分」については、技術的に難しいとされています。 条約で禁止されているのはしょうがないとして、「宇宙処分」は何がそんなに難しいのか？ 万が一、ロケット発射時に爆発したら、マジ怖い ロケット発射時に爆発する恐れがあり、万が一、爆発した場合に地球に及ぼす影響が大きすぎる。 なるほど、確かに。「もしも」を考えると恐ろしいですね。 「コロニー落とし」ぐらい怖いですね。 そもそも太陽に向かってロケットを飛ばす事が難しい 地球は太陽を中心に回っていますね。いわゆる「公転」というやつです。小学校で習いました。 なので地球から太陽に向かってまっすぐに撃っても簡単には当たらないのです。 地球から太陽に向かって仮にまっすぐに撃っても公転している遠心力で公転方向にロケットは進んでしまい、太陽から離れて行ってしまうんですね。 それでも太陽に向かうには、 公転を止める 公転と逆方向にロケットを飛ばす 必要があります。 「公転を止める」は無理っすね。なので「公転と逆方向にロケットを飛ばす」事をしなければなりません。 エスカレータで同じところに居続けるのに逆方向に歩くのと同じです。（よいこはマネしないでね） 公転は約秒速30km（時速108000km）なので、地球からはロケットを秒速30kmで発射しても宇宙から見ると止まっている状態です。さらに太陽に近づかないといけないので、さらにパワーが必要です。 地球自体も回っていますね。いわゆる「自転」てやつですね。これは利用しないわけにはいきません。ハンマー投げのように遠心力を使ってロケットを飛ばせば、宇宙から見ると自転をロケットの速度に載せる事ができます。 実際に静止衛星を飛ばすのに、より小さなエネルギーでロケットを飛ばせるように種子島宇宙センターは赤道付近に射場を設置しており、より赤道に近く、自転の遠心力に載るように東南方向にロケットを発射させます。（それだけが理由ではないですが） 一番早い「赤道」上で時速1700kmなので、 公転（時速108000km）　－　自転（時速1700km）　＝　ロケットの発射速度（時速106300km） となります。（実際にはもっといろんな事を計算しないといけないんでしょうが、ここでは考えるのをやめます） この速度で放射性廃棄物を爆発しないようにロケットを飛ばすって。。。難しいですね。 「地球から見ると」時速106300kmで進むロケットも「宇宙から見ると」時速0kmで（止まって）見えるって事ですね。 これは物理学の話ですが、話を飛躍させると「地球からの視点」と「宇宙からの視点」で全然違う物の見え方がします。 大きな視点（宇宙からの視点）で捉えれば、小さな視点（地球からの視点）では気づけなかった考え方をしなければなりません。 何事もマクロ（俯瞰）で捉えて、ミクロ（タスク）に分解して判断・行動する ってのが大事だよね。という話でした。 MRT

ストレングス・ファインダーって？ ギャラップ社が40年かけて「人間の強み」について研究して、「人間の強み」を「34の資質」に分類し、それを発見するツール（診断？）を開発しました。 診断は177問の質問に答えていくだけです。 1問20秒以内に答えないといけないので直感的に答えないといけません。 診断を受けると、才能を分類した34の資質のうち、自分はどんな資質を持っているのか上位５位を教えてくれます。 （残りの資質ももっとお金を払うと見れるようになるそうです。もちろん、私はやってません。） 自分が持っている資質を知るだけでは、宝の持ち腐れと言うか、「あ～、自分ってそうなんだぁ。」で終わりなので、その資質に投資（経験や勉強）する事で「強み」になると本には書いてありました。 その資質は、毎日の生活や人間関係の中で、意図的に使うことで初めて、誰にも真似できない素晴らしい「強み」になるのだと。 という事で本買いました。 本の最後に「アクセスコード」があるので、それを登録する事でWEBで診断を受けられます。 この「アクセスコード」は１回使うと使えなくなるので、中古で本を買うと残念な気持ちになってしまうので注意してください。 「いばらの道」を選ぶ必要はない その本の中では 自分の「強み」を活かしている人は週40時間の業務時間を楽しめるが、そうでない場合は業務時間が20時間を超えると働くほどに疲労が蓄積する と言っています。 また、 自分の「強み」を活かして仕事をしている人は、自分の「弱み」に意識を向けながら仕事をしている人と比較して 仕事に熱意を感じて楽しんでいる割合は6倍になる 人生を心から楽しんでいる割合は3倍になる という調査結果だったそうです。 強みにフォーカスするチームは、生産性を12.5%高めることができます。 とも書いてありました。 てことは、全社員（約100人として）が「強み」を活かしたチームで仕事をすると、約100時間分多くの仕事ができる事になります。 ようは効率的な業務遂行ができる組織になる、って事になります。 苦手な「弱み」を克服しようと「いばらの道」を選ぶより、得意な「強み」を活かした仕事をした方が、ストレスなく、楽しく、効率的に仕事ができるという事ですね。 いいですね～～。 という事で私の結果 私の場合のトップ５は以下の資質となりました。 1位　ポジティブ 2位　戦略性 3位　成長促進 4位　アレンジ 5位　社交性 「予想通り」の結果もあれば、「へ～、自分ってそうだったんだぁ」なんて気づきもある結果でした。 ちなみにこの本では、各資質の持っているいい事しか書いてないです。誰が診断しても何かしら持っている資質をランキング化してそのいい部分を教えてくれるので「私はこんな行動をとる方が自分を活かせるんだ！」って言うのが学べます。 ただ、「一方で」の側面も必ずある資質だとは思うので、「俺最強説」にならないように気を付けないといけないですね(笑) 本の中では、全34資質についてそれぞれ、 資質の内容 その資質が高い人の声 行動アイデア その資質が高い人との働き方 が書いてあり、自分を理解する他にも、いろんな資質も持った人との接し方の参考にもなるかなぁと思いました。 （※個人の感想です） 34の資質は全部で以下です。（強調は私の資質です） 実行力資質群影響力資質群人間関係構築力資質群戦略的思考力資質群 アレンジ活発性運命思考学習欲 回復志向競争性共感性原点思考 規律性コミュニケーション個別化収集 公平性最上志向親密性戦略性 慎重さ自我成長促進着想 信念自己確信調和性内省 責任感社交性適応性分析思考 達成欲指令性包含未来志向 目標志向 ポジティブ ぜひ、ご興味ある方は自分でも診断してみて自分の資質を自覚してみてください。 MRT

私が今までデータベースに触れてきたのは全てRDB（リレーショナルデータベース）というもので具体的にはOracle、PostgreSQL、MySQLなどを使ってきました。 簡単に言うとエクセル（表計算）でデータをまとめて、複数のシートの列と列の関係（リレーション）を紐づけて効率的にデータを管理するって感じです。 当たり前ですが表なので、行と列があります。それをSQLという言葉でデータを抽出したり、挿入したり、変更したりします。 で、NOSQLはというと、いろいろなタイプがあるらしいので、それによって特徴も違うのでしょうが、 ・リレーションがない ・トランザクション管理できない ・SQLじゃない。（No SQL！） ・スキーマ（表の定義）がない てなことがよくRDBと比較されるらしいです。 ・リレーションがない 何で？正規化したりすれば、わかりやすいじゃん！と思いましたが、速度重視なんですね。 ・トランザクション管理できない これも速度重視のため、トランザクション（データの整合性を保つための一連の処理の流れ）はアプリケーションで管理して、データベースでは管理しないようです。 ・SQLじゃない ま、NoSQLっていうぐらいですから。。。 ・スキーマ（表の定義）がない これがなかなかイメージできなかった。RDBは基本的に表なので列に要素を定義して、データの単位を行で管理します。 例えば 名前年齢性別 太郎１８男性 花子４３女性 って感じです。 この「名前」「年齢」「性別」の表定義がないってどういう事？と。 ということで触ってみます。 インストール 今回はMongoDBってやつを使ってみます。（特に理由はないです） 簡単に触ってみるだけなので、Windowsに導入してみます。 ここからインストーラ（msi形式）をダウンロードしました。 今回は mongodb-win32-x86_64-2008plus-ssl-4.0.2-signed.msi でした。 ダウンロードしたインストーラをウィザードに沿って進めるだけです。 接続 ちなみに今回は データベース：testdb コレクション：test ※コレクション・・・RDBでいう表（テーブル）みないなもんですかね？ で話を進めます。 インストールした中に（私の環境では） C:\Program Files\MongoDB\Server\4.0\bin\mongo.exe ってのがあります。どうやらこれがデータベースにアクセスするツールのようです。 このツールを立ち上げてまずはデータベースを指定します。 > use testdb switched to db testdb 「testdbに切り替えたぜ」って言われました。うまくいったようです。 データを入れてみる 今回は以下のデータを入れてみます。MongoDBはJSON形式で取り扱うようなのでデータもJSONで書いておきます。 { name:"tanaka taro", sex:"male", age:"26", school:{ name:"test university", department:"Chemistry", address:"tokyo" } } { name:"suzuki hanako", sex:"female", age:"36", work:{ name:"bitstar", department:"development", address:"hokkaido" } } 今回はわざとデータを学生と社会人のデータとしています。RDBで管理しようとすると namesexageschool:nameschool:departmentschool:addresswork:namework:departmentwork:address tanaka taromale26test universityChemistrytokyo suzuki hanakofemale36 bitstardevelopmenthokkaido となります。（今回はわざと１テーブルにまとめています。そこは突っ込みなしで） MongoDBの場合はとりあえずJSON形式で突っ込んじゃいます。 > db.test.insert({name:"tanaka taro",sex:"male",age:"26",school:{name:"test university",department:"Chemistry",address:"tokyo"}}) WriteResult({ "nInserted" : 1 }) > db.test.insert({name:"suzuki hanako",sex:"female",age:"36",work:{name:"bitstar",department:"development",address:"hokkaido"}}) WriteResult({ "nInserted" : 1 }) これだけ。 参照 今度は入れたデータを見てみます。 > db.test.find() { "_id" : ObjectId("5b8f1f4b0b4fc5eda33b87c3"), "name" : "tanaka taro", "sex" : "male", "age" : "26", "school" : { "name" : "test university", "department" : "Chemistry", "address" : "tokyo" } } { "_id" : ObjectId("5b8f1f6b0b4fc5eda33b87c4"), "name" : "suzuki hanako", "sex" : "female", "age" : "36", "work" : { "name" : "bitstar", "department" : "development", "address" : "hokkaido" } } どうやらInsert時に_idって一意のIDが割り付けられているようですね。それ以外はInsert時と同じ状態で抜き取る事が出来ました。 今度は名前（name）が「tanaka taro」のデータだけを抽出してみます。 > db.test.find({name:"tanaka taro"}) { "_id" : ObjectId("5b8f1f4b0b4fc5eda33b87c3"), "name" : "tanaka taro", "sex" : "male", "age" : "26", "school" : { "name" : "test university", "department" : "Chemistry", "address" : "tokyo" } } 簡単。 更新 次は更新です。 「suzuki hanako」さんは２歳サバ読んでいたって事で正しい年齢に直します。名前（name）が「suzuki hanako」の年齢を「38」歳にしてみます。 > db.test.update({name:"suzuki hanako"},{$set:{age:"38"}},false,true) WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 }) ちゃんと更新されたか確認してみます。 > db.test.find({name:"suzuki hanako"}) { "_id" : ObjectId("5b8f1f6b0b4fc5eda33b87c4"), "name" : "suzuki hanako", "sex" : "female", "age" : "38", "work" : { "name" : "bitstar", "department" : "development", "address" : "hokkaido" } } ちゃんと38歳になりました。 他にも 変数が使えます。 変数dataにまずデータを代入します。 > data={name:"kato jiro",sex:"male",age:"52",work:{name:"bitstar",department:"production",address:"hokkaido"}} { "name" : "kato jiro", "sex" : "male", "age" : "52", "work" : { "name" : "bitstar", "department" : "production", "address" : "hokkaido" } } その変数dataを挿入してみます。 > db.test.insert(data) WriteResult({ "nInserted" : 1 }) できたかな？確認します。 > db.test.find({name:"kato jiro"}) { "_id" : ObjectId("5b8f23590b4fc5eda33b87c5"), "name" : "kato jiro", "sex" : "male", "age" : "52", "work" : { "name" : "bitstar", "department" : "production", "address" : "hokkaido" } } いいね！ ループで回したり、検索結果（複数件）のカーソルを操作して値を取得したりもできます。 プログラムではよくやる操作ですね。 検索結果を変数cに代入。 > var c = db.test.find() 検索結果の変数cを１件ずつ取得してJSON形式で出力してみます。 > while ( c.hasNext() ) printjson( c.next() ) { "_id" : ObjectId("5b8f1f4b0b4fc5eda33b87c3"), "name" : "tanaka taro", "sex" : "male", "age" : "26", "school" : { "name" : "test university", "department" : "Chemistry", "address" : "tokyo" } } { "_id" : ObjectId("5b8f1f6b0b4fc5eda33b87c4"), "name" : "suzuki hanako", "sex" : "female", "age" : "38", "work" : { "name" : "bitstar", "department" : "development", "address" : "hokkaido" } } { "_id" : ObjectId("5b8f23590b4fc5eda33b87c5"), "name" : "kato jiro", "sex" : "male", "age" : "52", "work" : { "name" : "bitstar", "department" : "production", "address" : "hokkaido" } } こんな感じ。プログラムっぽい事いろいろできそうなので結構便利かも。 さいごに 今回は結局、触ってみるって事だったのであまりRDBにはないNOSQLの特性を活かしたうんたらかんたらには触れませんでしたが、NOSQLはそんなに難しい事はないってことだけはわかりました。お仕事の案件によってはNOSQLを使うのも悪くないなぁって思ったところで今回は終わりとします。 MRT

もう10年以上もプログラムを書いてなかったので、ブログのネタとしてせっかくなので久々にプログラムを書いてみようと思います。 で、何しようかと思ったところ、流行りのAIにでも触れてみようかと思います。 「IBM Watson」 IBMが「IBM Watson」というブランドでAIサービスをやっているので、今回はこれを使ってみます。 IBM Cloudライト・アカウントを取得する APIを無料で使うのに「IBM Cloudライト・アカウント」が必要だそうです。 ライトアカウントだと無料で、条件付きですが無期限でIBM Watsonが使えます。 ただし、無料ですから、制限があります。 ・10日間 開発なしでアプリを自動停止 ・30日間 活動なしでサービスの自動削除 ・「組織の作成」画面では、地域に「米国南部」を選択を行う必要があります。 今回は２時間ぐらい使えればいいので全然問題ありません(笑) カタログからVistual Recognitionを選択し、API KEYを手に入れる アカウントを取得したら続いてどんなAPIを使うかを選択します。 今回は、AIっぽいって事で画像認識系の何かをしようと思います。 ＜Vistual Recognition＞ 画像認識機能です。すぐに使用できるようにWatsonが既に学習をしており、画像・映像フレームに写った複数のものや、 情景を分析・認識することができます。また、機械学習によりWatsonに独自の学習をさせることもできます。 すでに、自社製品の認識・分類や、製造ラインにおける欠陥検出といった多種多様なお客様の業務で、高い精度の画像認識を 少ない画像枚数による短時間の機械学習で実現しています。 さらに、日本語・英語を含む多数の言語で認識結果を返すことができます。 とワトソンさんは言っているので、今回は「Vistual Recognition」の機能を使ってみます。 で、省略しますが、API Keyを取得し、控えておきます。 プログラムを書く 今回は顔認識のAPIを使ってみます。人間の顔が映っている画像をAPIで投げると、男性か女性かと推定年齢がわかるようです。 詳しいAPIの使い方はAPIリファレンスで調べます。 プログラム言語は今回は手っ取り早くPHP(ver.5.3)で書きます。 watson.php 1 ＜?php 2 $base_url = 'https://gateway-a.watsonplatform.net/visual-recognition/api';//APIにアクセスするエンドポイントです。 3 $api_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';//API Keyを入力します。 4 5 $method = '/v3/detect_faces';//顔認証のAPIです。 6 7 $path = "./w_img"; 8 $img = "sample.jpg"; 9 $img_path = $path . "/" . $img; 10 $cfile = "@$img_path;filename=$img;type=image/jpeg"; 11 $img_data = array("images_file" => $cfile,"classifier_id" => "default"); 12 13 $curl = curl_init(); 14 15 curl_setopt($curl, CURLOPT_URL, $base_url.$method.'?api_key='.$api_key.'&version=2018-04-07'); 16 curl_setopt($curl, CURLOPT_CUSTOMREQUEST, 'POST'); 17 curl_setopt($curl, CURLOPT_POSTFIELDS, $img_data); 18 curl_setopt($curl, CURLOPT_RETURNTRANSFER, true); 19 20 $response = curl_exec($curl); 21 22 curl_close($curl); 23 24 var_dump($response); 25 ?> 画像を置く 顔認証する画像を置き、プログラムで指定しているパスに保存します。 今回は著作権フリーのこの画像を使います。 やってみた 準備が整ったので早速実行してみます。ブラウザから先ほど作成したプログラムのURLにアクセスします。 結果は string(1250) "{ "images": [ { "faces": [ { "age": { "min": 25, "max": 28, "score": 0.93356967 }, "face_location": { "height": 406, "width": 363, "left": 839, "top": 275 }, "gender": { "gender": "MALE", "score": 0.99973804 } }, { "age": { "min": 19, "max": 21, "score": 0.9996961 }, "face_location": { "height": 450, "width": 392, "left": 337, "top": 255 }, "gender": { "gender": "FEMALE", "score": 0.999969 } } ], "image": "sample.jpg" } ], "images_processed": 1 }" となりました。 説明すると 赤枠の範囲で顔を認識し、左の枠は「19～21歳の女性」、右の枠は「25～28歳の男性」という結果のようです。 あとはアイデア次第？ ここまでは私でも２時間程度でできたので、弊社の開発部の方であればもっと早くできるでしょう。 感想としては、身近にAIを体験できるサービスができていて、試せる状況が整っているという事で、アイデアや組み合わせ次第で 面白い事ができそうと思いました。 ただ、AIの精度などは今回は検証できなかったので、シビアな要件には十分に検討が必要ですね。 なんか当初は「プログラムを久しぶりに書いてみよう」だったのに、結局25ステップしか書いてないっていう。。。 MRT

年末年始になるとお酒を飲む機会が増えますよね。そんな一コマです。 （食卓に夕飯が残ったままになっているのを見て） 妻：「昨日、帰りが遅かったし、夕飯も外で食べてきたの？」 私：「そうだよ。飲み会」 妻：「えっ？！言ってよ！夕飯作っちゃったじゃん！」 私：「え？！言ってたでしょ！？」 妻：「それは来週でしょ？」 私：「一昨日に日程が変更になったって言ったじゃん！わかったって言ってたでしょ！」 妻：「言ってないよ！」 私：「言ってたって！」 あとはその繰り返し・・・ くだらね～と思いながらも、売り言葉に買い言葉でだんだんイライラするやつです。ちゃんと伝えたし、俺悪くね～よ～！！ 待てよ。。。これって俺も悪いんじゃね？とふと思い、真面目に分析してみました。 ちなみに私個人の見解なので、突っ込みなしでお願いします。 これから話すコミュニケーションとは 「社会生活を営む人間の間で知覚・感情・思考を伝達し合う事」 と定義する事にします。大事なのは「伝達する事」ではなく、「伝達し合う事」です。 で、コミュニケーションエラーを 「コミュニケーションが妨げられる状況」 と定義する事にします。 さまざまなコミュニケーションエラーがある中で、今回は「言った言わない」問題に限定して書きます。 社内でも社外でもプライベートでも「言った言わない」問題は発生すると、はじめは小さな事だったのに大きな問題になる事が多々あります。 なんで「言った言わない」問題になるのか まず、言う側と聞く側では以下ようなことが常に起きていると思います。 １．同じものや出来事でも、人によっては見え方・聞こえ方・感じ方が違っている時がある。 　　→わかりやすいのが下の画像のように「そっぽ向いてる貴婦人」と見える人もいれば「おばあさん」に見える人もいる。 私は「そっぽ向いてる貴婦人」に見えました。 ２．同じ人が同じものや出来事を感じる場合でも、時によって違った見方をしている時がある。 　　→子供の頃ピーマン大嫌いだったのに、大人になったらピーマン好きになった。 ３．実際の通りに見ていないし、見えている通りに実際があるとは限らない。 　　→コインが消えるマジックとか、箱の中で美女に剣を刺すマジックとかがそれでしょうか。 ４．知覚には選択の原理が働いているので、実際の事に全部を気づいているわけではないし、無視され、気づいてない部分がある。 　　→脳トレとかで画面の一部がゆっくり変わっていくのに気づけないとか言うやつの事ですかね。 この４つのいずれかが欠けた状態でコミュニケーションをとり続けると「言った言わない」問題になる可能性が高くなるらしいです。 例えば・・・ 「１．同じものや出来事でも、人によっては見え方・聞こえ方・感じ方が違っている時がある。」が欠けてた場合 Aさん：「この参考サイトの感じで制作お願いします」 Bさん：「任せてください！。。。できました～。」 Aさん：「ナニコレ。。。」 参考サイト（同じもの）でも二人には感じ方が違ったようです。
「２．同じ人が同じものや出来事を感じる場合でも、時によって違った見方をしている時がある。」が欠けてた場合 Aさん：「半年前に言われてた件の発注そろそろお願いします！」 Bさん：「何も連絡なかったから他の業者に発注しちゃった」 Aさん：「そんな～。。。（あん時はAさんに必ず発注するって言ってたじゃ～んTT）」 半年間でBさんは心変わりしちゃったんですね。
コミュニケーションエラーは狭義でヒューマンエラーなので人間である以上、エラーの発生を完全に抑えることは不可能であると思います。 かといって予防・改善・対策はできます。 予防・改善・対策 １．略したり、こそあど言葉（これ、それ、あれ、どれ）など極力使わず、必ず5Ｗ1Ｈを用いて具体的に話しをする。 ２．図（視覚）や見本（触覚）、ボディランゲージなどあらゆる手段を使用し理解してもらおうと努力する。 ３．体験等を通してイメージしやすく話をする。 ４．会話後も相手の行動を観察し、正確に伝わっているか確認をする。（やりすぎ注意。キモ） ５．お互い積極的に理解を深め、疑問を疑問として残さず質問するなどして解決し、正確なコミュニケーションを取る努力をする。 一見、矛盾しているように思われるかもしれませんが、ようは伝わり合えればいいわけなので、以下も追加します。 ６．常日頃コミュニケーションを上手く取る事を心掛けて会話する機会を多く設け、多少のあいまいさがあっても問題のない雰囲気づくりをする。 いわゆる「あうんの呼吸」ってやつですね。 また、誤伝達を抑えるには「伝達文書における ４C の原則」というのが有効のようです。会話でも同じだと思います。 「４C」・・・Clear（明確）・Correct（正確）・Complete（完結）・Concise（簡潔） ● わかりやすい文章で伝える。：相手が理解できる用語。なじみ深い言葉。平易な文章。 ● 正確に表現する。：適切な表現。曖昧ではない。明瞭な言葉。 ● 完全なメッセージを伝える。：必要な情報をすべて含める。情報過多ではない。 ● 要点をまとめる。：短く簡単な文章。簡潔である。不要語を避ける。箇条書きなど。 結論 私が飲み会のある当日の昼間に 私：「念のためにもう一度確認しておくね。先週飲み会があるって言ってたやつは一昨日に日程変更あって今日になったけど、間違えて夕飯作っちゃったら申し訳ないから覚えてると思うけど、もう一度言っとくね。。。愛してるよ。」 って言えば今回のコミュニケーションエラーは発生しなかった事に。。。なる？（いちいち長げ～よ！絶対言わないな、これ） 何かを伝える時、伝える側、聞く側のお互いで、「これは当たり前でしょう」「常識」「○○だったら△△だ」という前提で コミュニケーションをとると、その前提がそもそもお互いで認識が合っていない場合があるので、とっても危険って事ですね。 MRT