勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

2018年上半期に読んだ本まとめ

2018年1月~6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2018年上半期に読んだ本

2018年1月~6月に最後まで読み終わった本はこんな感じ。
https://www.instagram.com/p/Bdeb6Vig5we/https://www.instagram.com/p/BdrVudKgI4-/https://www.instagram.com/p/BdrWNoMgJDE/https://www.instagram.com/p/BeVWQejgmM-/
https://www.instagram.com/p/BenWz5bg5My/https://www.instagram.com/p/Bet4ADFAnmq/https://www.instagram.com/p/BewKwZJAJaQ/https://www.instagram.com/p/BfSC2PmAXQ2/
https://www.instagram.com/p/BfnKpIRBKES/https://www.instagram.com/p/BfnK-GIB2mQ/https://www.instagram.com/p/BfnLRblhqDE/https://www.instagram.com/p/Bf15R98BjR1/
https://www.instagram.com/p/Bf17vbYBYaC/https://www.instagram.com/p/BgYqqhGHNiJ/https://www.instagram.com/p/Bge-B1anfZQ/https://www.instagram.com/p/Bg6BrSBAB6X/
https://www.instagram.com/p/BhB0rlMAxCD/https://www.instagram.com/p/BhEVrbegkPB/https://www.instagram.com/p/BhWeDX-AzNk/https://www.instagram.com/p/BhibfNQBsZx/
https://www.instagram.com/p/BhrK91WBqB2/https://www.instagram.com/p/Bh6Bb2Gh-6v/https://www.instagram.com/p/BiNmAYvB-Gf/https://www.instagram.com/p/BihSG_rhLh9/
https://www.instagram.com/p/BitfyDlBzVV/https://www.instagram.com/p/BjAEWPZBJaB/https://www.instagram.com/p/BjFKPZNhSXn/https://www.instagram.com/p/BjQjEW_BhCN/
https://www.instagram.com/p/BjZ4QcjBVLR/https://www.instagram.com/p/BjcX1gVhXoe/https://www.instagram.com/p/Bjhm82iBhYs/https://www.instagram.com/p/BjjrRqtB4EY/
https://www.instagram.com/p/Bjr2tADhpFZ/https://www.instagram.com/p/BjvbcYWhgkw/https://www.instagram.com/p/Bjv2wHahQsr/https://www.instagram.com/p/BjyRTdBBno4/
https://www.instagram.com/p/Bj7Ii4qh8hX/https://www.instagram.com/p/BkNL09ah6Ws/https://www.instagram.com/p/Bkc5ZRBhLZB/

  1. 進化する銀行システム 24時間365日動かすメインフレームの設計思想
  2. 騎士団長殺し :第1部 顕れるイデア編
  3. モチベーション革命 稼ぐために働きたくない世代の解体書 (NewsPicks Book)
  4. リーチ先生 (集英社文芸単行本)
  5. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
  6. アロウズ・オブ・タイム (新☆ハヤカワ・SF・シリーズ)
  7. GE 巨人の復活
  8. あなたの人生の物語
  9. 香匣は心臓を望む (Amazonから消えてしまった)
  10. 「組織が結果を出す」非常識でシンプルなしくみ
  11. まなざしのデザイン
  12. 影響力の正体 説得のカラクリを心理学があばく
  13. テスタメントシュピーゲル3 下 (角川スニーカー文庫)
  14. 金融に未来はあるか――ウォール街、シティが認めたくなかった意外な真実
  15. パケットキャプチャの教科書
  16. ZERO BUGS シリコンバレープログラマの教え
  17. 公正的戦闘規範 (ハヤカワ文庫JA)
  18. 1440分の使い方 ──成功者たちの時間管理15の秘訣
  19. 習得への情熱 チェスから武術へ――上達するための、僕の意識的学習法
  20. 飛行士たちの話
  21. 悪童日記
  22. 詳解 システム・パフォーマンス
  23. 「国境なき医師団」を見に行く
  24. 9プリンシプルズ 加速する未来で勝ち残るために (早川書房)
  25. たゆたえども沈まず (幻冬舎単行本)
  26. NATURE FIX 自然が最高の脳をつくる 最新科学でわかった創造性と幸福感の高め方
  27. 不確定世界の探偵物語 (創元SF文庫)
  28. 棋士とAI?アルファ碁から始まった未来 (岩波新書)
  29. セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方
  30. 決定版 上司の心得 (角川新書)
  31. 退屈をぶっとばせ! ―自分の世界を広げるために本気で遊ぶ (Make: Japan Books)
  32. ゲームの王国(上) (早川書房)
  33. ゲームの王国(下) (早川書房)
  34. チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ
  35. ヘネシー&パターソン コンピュータアーキテクチャ 定量的アプローチ 第5版
  36. 多動日記(一)「健康と平和」: ?欧州編? (電子版 未来文庫)
  37. 世界一やさしい「思考法」の本 「考える2人」の物語
  38. アメリカ海軍に学ぶ「最強のチーム」のつくり方
  39. 世紀の空売り 世界経済の破綻に賭けた男たち (文春文庫)

オススメビジネス書編

このシーズンは能力開発/自己啓発の名著の類の積読を頑張って消化してたのだけど、あまりアタリは無かったかなぁ。そんな中で、「世界一やさしい「思考法」の本 「考える2人」の物語」は有用度が高かった。自分というより後進指導の悩み比率が高まるお年頃なわけで、平易に伝える方法が書かれているのも良いし、人によっては丸投げても読んでくれそうなハードルの低さ。

業界分析/研究カテゴリーで言えば「GE 巨人の復活」は評判通りの良書で、いろいろと刺激があった。この類の本は訳書が多いのだけど、本書は最初から日本語で書かれた邦書である。おそらく製造業の方向けに書かれた本なので、ソフトウェア開発技術者であれば、そんなに新しい話があるわけではない。が、巨人がエクストリームな方向転換をしたこと、及びそのアプローチは非常に興味深い。

GE 巨人の復活

GE 巨人の復活

オススメ技術書編

元からソフトウェアの低レイヤ技術(OSとかコンパイラとかネットワークとか)には興味と憧れがあったのだけれども、ちょうど仕事でも近しい領域の課題があったので集中的な勉強を始めたところだったりする。というわけで、話題の技術書の類はぜんぜん手に取っていない点は反省。一方で学び始めた領域はとても面白く、今はOSの作り方などを勉強し始めてたりする。

繰り返し読んだ本は「詳解 システム・パフォーマンス」で、システム屋としてはこの本でいろいろととっかかりを手に入れた気がする。副読本(教科書)として、以前にセールで手に入れていた所謂ヘネパタ本を読んで、いろいろと知識が深まった気がする。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

ヘネシー&パターソン コンピュータアーキテクチャ 定量的アプローチ 第5版

ヘネシー&パターソン コンピュータアーキテクチャ 定量的アプローチ 第5版

あと、せっかくなので得た知識を楽しむという点で「セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方」でいろいろと刺激を得ることができた。セキュリティというテーマの競技に関するガイドなのだが、本書を読んだあと、公開されてる様々な問題を解く(プログラムを解析したり脆弱性を利用して、隠されている答えを手に入れるゲームである)にチャレンジし始めている。新しい学びがあり、なかなかに楽しい。

セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方

セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方

この半期の振り返り

年齢と職責的には、もっとマネジメントやら人心掌握術、戦国武将の話とかを読むべきような気もするのだけれども、むしろ逆に振り切ってしまったような気がする。せめて積読している「ティール組織 ― マネジメントの常識を覆す次世代型組織の出現」は読み終えたかったのだけど食指が動かないのはなぜなんだろう。

あと気になるのは視力の問題である。幸運にも目は良くてメガネもコンタクトも不要なのだけれども、疲れたり酒を飲むと、読書がつらいことがある。もしかして老・・・。

まあ、電子書籍は必要に応じて文字サイズが変えられるのでかなり助かっているのだが。

産業安全についての神話(Some myths about industrial safety)について調べた

The DevOps ハンドブック 理論・原則・実践のすべてで紹介されていた「産業安全についての神話」(補章E)が面白そうだったので調べてみた。ソフトウェア開発に限らず、工学全般の話。

The DevOps ハンドブック 理論・原則・実践のすべて

The DevOps ハンドブック 理論・原則・実践のすべて

複雑なシステムに対する数十年の研究の結果、危険への対応策はいくつかの神話に基づいていたことがわかった。

原文はおそらくこれ

なお以下私の誤読の可能性もあるので、興味があれば上記の原典論文を参照のこと。

神話1:事故やインシデントの唯一最大の原因はヒューマンエラーである

原因をヒューマンエラーと分析すること自体に誤りがある。

  • 不正行為の暗示
  • 犯人探し
  • 後付けバイアス

であり、作業環境の不備や不足の隠蔽に繋がる。よって、問題の原因をヒューマンエラーと説明すべきではない。
また、問題の行動がが通常どのような状況下で行われるのかについて検討をすべきである。

神話2:システムは、人々が与えられた手順に従っていれば安全である

全ての事象をカバーする完全な手順を構築することが不可能であること、および本来人間が持っている柔軟性を制限することが有害である場合があることから誤りである。

神話3:安全性は障壁と保護によって上がる。保護の階層を増やせば、安全性は上がる

一見すると正しく見えるが、追加的な保護が人々の行動を変化させ、結果として安全を損なう場合を考慮する必要がある。曲がりりくねった道路に夜間安全対策として反射板を追加したところ、車の走行速度が増して、事故率が増加したという話などが紹介されている。
また、保護機構の追加によってシステムそのものの複雑度が増し、それによって安全性が低下する懸念もある。

神話4:事故分析は、事故が起きた根本原因(「真実」)を明らかにすることができる

根本原因分析は簡単な手法であり魅力的だが、必ずしも原因究明できるとは限らない。特に人間が関わるシステムの問題においては、人の持つ柔軟性、弾力性を考慮すると誤った分析や、前述の「ヒューマンエラー」を根本原因としてしまう可能性がある。

神話5:事故調査は、事実に基づいて原因を論理的、合理的に究明する

手法の選択を含めて事故調査は難しいプロセスであり、かつバイアスから逃れることは出来ないため、必ずしも論理的、合理的な結論に至るわけではない。またプロセスによって原因を発見するのではなく構築してしまいがちである。

神話6:安全には常に最高の優先順位が与えられており、決して妥協はない

言うまでもなく、組織がその負担をする余裕がある限りにおいては、という話である。

「5億ドル?!を吹っ飛ばした、たった1つのバグ!」について調べた

久しぶりのブログ更新。書籍「ZERO BUGS シリコンバレープログラマの教え」を読み終えた。この本の中で紹介されている歴史的なソフトウェア障害が気になったのでいろいろ自分で調べてみたメモ。トラブル好きなもので。
https://www.instagram.com/p/Bg6BrSBAB6X/

アリアン5型ロケット爆発事故(1996年、European Space Agency)

失敗事例 > アリアン5型ロケットが制御不能で40秒後に爆発
失敗百選-アリアン5型ロケット爆発事故
アリアン5 - Wikipedia
「史上最悪のソフトウェアバグ」ワースト10を紹介(下)|WIRED.jp

ZERO BUGS日本語版の表紙のアオリ文句「5億ドル?!を吹っ飛ばした、たった1つのバグ!」のトラブル事例である。被害額は訳者の調べであり原著者は文中で言及しているわけではない。5億ドルは吹っ飛んだロケット+ペイロードの総額であり、開発費用はっと大きかったという話もあるようだ。なお書籍には実際のコードも掲載されていて興味深い。

もちろんコードに問題があったことは確かなのだけど、調べてみるとこのトラブルはプロジェクトマネジメントと品質管理の問題のように見える。トラブルのアウトラインは以下の通り。

  • 飛行コンピューターでオーバーフローが発生し、最終的にロケットが発射直後に爆発した。
  • この飛行コンピューターのコードを一世代前のロケットから引き継いでおり、新規に開発したものではない。
  • 新型ロケットでは加速度が旧型より増加しており、結果として計算処理でオーバーフローとなった。要は前提が変わっていることが見過ごされた。
  • 飛行コンピューターは稼働実績ありという理由で詳細なテストは行われなかった。

合掌(チーン)。

ちなみにWikipediaの記事ではこの失敗が

1996年6月4日に行われたアリアン5の最初の飛行は、コンピュータプログラムの異常で打ち上げ37秒後に爆発し、失敗に終わった。これは歴史上でも最も高くついたバグの1つであり、後に64ビットの浮動小数点数を16ビットの整数に変換する過程でエラーが生じたと判明した。

と書かれているのだけど、この記載(下線部)はあやしい。英語版記事を元に書かれたものだと思うけど、
Cluster (spacecraft) - Wikipedia

The failure has become known as one of the most infamous and expensive software bugs in history.[1] The failure resulted in a loss of more than US$370 million.[2]

英語版記事の情報源[1]がそもそも1996年のエッセイなのである。

被害額も記事によってまちまちなので注意したほうがよさそう。

ZERO BUGS シリコンバレープログラマの教え

ZERO BUGS シリコンバレープログラマの教え

2017年下半期に読んだ本まとめ

2017年7月~12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2017年下半期に読んだ本

2017年7月~12月に最後まで読み終わった本はこんな感じ。
https://www.instagram.com/p/BWFnDSYAIl0/https://www.instagram.com/p/BWXnZRggklk/https://www.instagram.com/p/BWXoM55gcP3/https://www.instagram.com/p/BWfPLnUgtGG/
https://www.instagram.com/p/BXaK6jLgkP1/https://www.instagram.com/p/BXym7GZg80d/https://www.instagram.com/p/BX9RqXPAyRS/https://www.instagram.com/p/BYs8UTHggEc/
https://www.instagram.com/p/BZFKUZOAsiW/https://www.instagram.com/p/BZbTQt0gvfF/https://www.instagram.com/p/BZoSMiKgaX5/https://www.instagram.com/p/BZ1BdMVgiBX/
https://www.instagram.com/p/BZ8pjzrgvIh/https://www.instagram.com/p/BaJvV_2Az7o/https://www.instagram.com/p/BaRTRAMgwmS/https://www.instagram.com/p/BaWmnVGgbvc/
https://www.instagram.com/p/BayNae7A0Te/https://www.instagram.com/p/BbPKgmxg77i/https://www.instagram.com/p/BbZgQflAbBq/https://www.instagram.com/p/BbnW4dZAWSm/
https://www.instagram.com/p/Bb5ZPo3gNV_/https://www.instagram.com/p/BcLWCnxgAh6/https://www.instagram.com/p/BchameagYm-/https://www.instagram.com/p/Bc7PNzCA0cU/
https://www.instagram.com/p/BdC7ka5ARAj/https://www.instagram.com/p/BdFBBJ8ACzD/https://www.instagram.com/p/BdRHK-Cg30V/https://www.instagram.com/p/BdWHMmogZEW/

  1. アイデア大全
  2. バナナ剥きには最適の日々
  3. ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装
  4. 宇宙創成(上)(新潮文庫)
  5. 宇宙創成(下)(新潮文庫)
  6. 1Q84 BOOK 1
  7. 1Q84 BOOK 2
  8. 1Q84 BOOK 3
  9. シャンタラム〈上〉 (新潮文庫)
  10. シャンタラム〈中〉 (新潮文庫)
  11. シャンタラム〈下〉 (新潮文庫)
  12. かくて行動経済学は生まれり (文春e-book)
  13. ビジネス・フォー・パンクス
  14. 脱出航路 (ハヤカワ文庫 NV 283)
  15. 暗幕のゲルニカ
  16. LIFE PACKING 未来を生きるためのモノと知恵
  17. アノニム (角川書店単行本)
  18. 新しい分かり方
  19. SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
  20. 最後の晩餐 (文春文庫)
  21. スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
  22. ブラックアウト 上 (角川文庫)
  23. ブラックアウト 下 (角川文庫)
  24. 計画の科学 どこでも使えるPERT・CPM (ブルーバックス)
  25. 母の記憶に (新☆ハヤカワ・SF・シリーズ)
  26. クォンタム・ファミリーズ (河出文庫)
  27. 横浜駅SF【電子特典付き】 (カドカワBOOKS)
  28. システムを「外注」するときに読む本
  29. キッズファイヤー・ドットコム
  30. 今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書
  31. バイエルの謎: 日本文化になった教則本 (新潮文庫)
  32. ライフハック大全―――人生と仕事を変える小さな習慣250

オススメ文芸書編

たまたま2017年下半期はパラレルな世界を扱う2小説を読んだ(「1Q84」「クォンタム・ファミリーズ」)のだけれども、どちらもよかった。それぞれ過去の作品のオマージュという意味でも相似形を成しているのが興味深い。「1Q84」とオーウェルの「1984」、「クォンタム・ファミリーズ」と村上春樹の「世界の終わりとハードボイルドワンダーランド」という関係。あえて一冊を選ぶなら「クォンタム・ファミリーズ」を推す。量子コンピュータについても盛り上がっていることだし(本作品は量子コンピュータにも少し関係がある)。

クォンタム・ファミリーズ (河出文庫)

クォンタム・ファミリーズ (河出文庫)

オススメビジネス書編

面白さだけで言えばルイスの「かくて行動経済学は生まれり」である。鉄板の面白さ。なお本作で興味を持った勢いで、「ファスト&スロー」まで読むのがベストだと思う。

ファスト&スロー (上)

ファスト&スロー (上)

ファスト&スロー (下)

ファスト&スロー (下)

オススメ技術書編

Googleで実際に利用されている運用、システム管理に関するベストプラクティスを紹介する論文集である、いわゆるSRE本が素晴らしかった。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

なお原著の内容は全て公開されているのだけれども、日本語で読めるというのが有難い。

この半期の振り返り

実は10月頃から仕事が非常に忙しくなってしまって、あまり読書に投じる時間が作れなかった。というわけで、かなりの本を積んでしまっている状況である。かなり、まずい。
あと、上記まとめには含んでいないのだけれどもこの半年で雑誌類の(継続的な)購読を完全にやめてしまった。ずいぶん前から新聞も取らなくなっているので、紙に印刷された文字を読む機会はずいぶんと減ったことになる。なお仕事的にもペーパーレスが進んでおり、印刷物を見る機会も減っているので、なんというか少しずつ風景が変わり始めているような気がしている。

Incident Command Systemについて調べた

Google SRE本を読み終わった。いや、これはすごい本だ。しかし非常に広範囲なプラクティスの詰め合わせ(というか論文集だ)のため、完全に消化不良である。ゆえに、同書で気になった箇所を少しずつ整理検討しているのだけれども、そのひとつがIncident Command Systemである。これはすぐに使いこなしたいプラクティスだと思っている。まぁ、仕事の規模や質次第かも。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Incident Command Systemとは何か?

14.3 インシデント管理のプロセスの構成要素
インシデント管理のスキルとプラクティスは、熱意ある個々人のエネルギーを正しい方向に向けるために存在するものです。Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • いや、知られていないよ!知らなくてごめんなさい!
  • 英語版は全文公開されているので、興味があればこちらから該当箇所が読める。Google - Site Reliability Engineering

何かと思ったら、災害(障害)発生時の対応組織をボトムアップに(ブートストラップ的に)構成する標準化されたマネジメントシステムだった。消防とか警察とか軍事関連のように見える。いろいろ調べてみたけれども、以下のWikipediaの記事が一番わかりやすい印象。

  • インシデント・コマンド・システム - Wikipedia
  • 1人の監督者(インシデント指揮者)が5-7名までのメンバーで構成される臨時組織を立ち上げて問題に対処する。指揮者の監督限界を超えた場合は組織を分割しなければならない。
  • 指揮、実行、計画、後方支援、財務・総務の5つの機能をチームで分担して実行する。

米国では、1970年代、多くの山火事が発生し、当時の現場指揮官が、

  • 一度に多くの人が、一人の監督者に報告するので処理しきれない(上がって来る報告を溜めるバッファがない)。
  • 関係機関がそれぞれ異なった組織構造になっており、組織的な対応が困難。
  • 信頼のおける情報が流れてこない。
  • 通信装置や通信手順が統一化されていない。
  • 関係機関の間で共通の計画を策定するシステムがない。
  • 指揮命令系統が不明確。
  • 関係機関が使用する用語が統一化されていない。
  • 目標が不明確。

等の多くの問題に直面したため、1979年に消防大学校(Fire Academy)が次のコンセプトの下で「ICS」を開発した。
インシデント・コマンド・システム - Wikipedia

というわけなので、ITシステムの障害対応においても上記のような対応の失敗や課題に直面したことがあれば、採用検討に値するものではないかと思っている。

情報システムの障害状況ウォッチ(2017年前半)

SEC Journal50号で2017年後半の情報システム障害状況まとめが公開されたので読んでみる記事。単なる野次馬なんだけれど、勉強になるので続けている。

過去に書いた関連記事は以下の通り。

SEC Journal最新号の入手はこちらから。

情報システムの障害状況ウォッチ(2017年前半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。なお今期は割と注意して日経コンピュータ記事を読んでいたので、前期よりは情報は充実しているつもり。また4桁数字は元ネタ記事にあるトラブルNo.である。

数が多すぎて、調べるのも一苦労。

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

おすすめ
ZERO BUGS シリコンバレープログラマの教え

ZERO BUGS シリコンバレープログラマの教え

まだ読めていない

上司・部下間のコミニュケーションのKY問題

最近コミニュケーションに関するいくつかの問題が身近にあって、いろいろと考えたことを書く記事。上司部下間のコミニュケーションの問題には階層があって、いちばん改善すべきなのは部下側ではなく上司側の問題だと思っていることについて。なお、顧客との(もしくは受発注者間の)コミュニケーションの話はまた別。
AIR!

「コミュ力」の問題はだいたい上司の問題説

あくまで主観的なものだけれども、いわゆる「コミュニケーション能力(いわるゆコミュ力)」の問題の多くは実際には上司(情報の受取り手)の問題で、部下(出し手)の問題は小さいと思っている。

最近読んだ本だと「職場の問題地図」がこの問題を非常に明快に示していた(ちなみに同書はとてもおすすめ)。

  • 3丁目 報連相できていない
    • 部下の伝えるスキルが低い
      • 報・連・相のやり方がなっていない
      • 適切なタイミングで報・連・相していない
    • 上司の受け止めるスキルが低い
    • 報連相をする場やルールがない
      • 上司が忙しすぎて、部下が話しかけるタイミングがない
      • 報・連・相のフォーマットがない

職場の問題地図 ?「で,どこから変える?」残業だらけ・休めない働き方

「部下の伝えるスキルが低い」と書かれていると部下の問題のようにも読めるけれども、適切な報告の仕方を指導教育していないという意味ではこれも職場や上司の問題である。同書でオススメしている指導フォーマットは次のようなもの。

  • 所用時間を示し相手の都合を確認する
  • まず「報」か「連」か「相」かを伝える
  • 結論を伝える
  • 論点を数で示す(ナンバリング)

「小松課長、いま5分間お時間よろしいですか? 決算早期化プロジェクトの進め方について、ご相談が2点あります。キックオフの日程と、会場についてです。まず1点目の日程について。日程は延期すべきと思います。なぜなら・・・・」
職場の問題地図 ?「で,どこから変える?」残業だらけ・休めない働き方

こういった情報の受け止め方、どういう形で吸い上げるのかという業務プロセス設計上の問題を無視して、「アイツはコミュニケーション能力が低くて、情報が上がってこないんだよな」などと言ってはいけないという話だと思っている。

部下/メンバーに空気を読ませる時点で負け

報告の仕方というテクニック的な側面もあるとは思うけれど、むしろ問題の根っこには、雑なアサインメントやプロセスの組み立てによって、部下やメンバーに「空気を読ませすぎている」ことだと考えている。もちろん問題にはグラデーションがあって、どこまでやれば正解で、どこからが不備という線引きはできないのだろうが、

  • 責任範囲が不明確
  • 裁量の範囲があいまい
  • やっていいことと、いけないことの線引きがあいまい
  • 上司や組織の意思決定が場当たり的で一貫していない
  • 過去の意思決定の精度が不明なので踏襲していいのか常に不明

などが原因となって、なにをどこまでコミニュケーションすべきか常に空気を読みながらやらなければいけない状況が発生して、非効率やコンフリクトが発生しやすくなるのではないだろうか。

ではどうするか。いろいろ考えてみたのだけれどもまずは空気を読ませないために、個々人の役割を具体的かつ明確にするのが良いかと思っている。たとえばちゃんと職務記述(Job Descriotion)を書けばいいのではないだろうかというのが現時点での個人的な結論だ。

ひょっとしたらうまく対応できている組織や現場も多いのかもしれないが、割と日本企業の多くはこういった形で個々人の職務内容を明確化しないのが一般的じゃないかと思っている。

  • マネジメント側が組織やプロジェクトへのアサイン完了した段階で思考停止しまう
  • 何をすべきかを「考えることからが仕事だ」といってしまう、組織設計不備の責任転嫁

というあたりが根っこにあるのではないだろうか。

つまり、「空気読めよ」という批判はどれも他のフレーズに言い換えることができるわけだ。「空気読め」と言って個人を批判すれば、自分の考えや意向、思っていることを明確に言葉にする必要がないので、話者のコミュニケーションの怠慢とも言えなくはない。自分を含めた“周りの意向”を非常に曖昧な「空気」という言葉で表現し、空気にそぐわない個人へ責任転嫁しているだけの話である。

なぜ「空気読め」が日本人のコミュニケーションをダメにするのか? 「空気読めない人」に対する海外の反応

ただし、これはあくまで組織内の話でである

というわけで、組織やプロジェクト内部で部下に「空気を読ませる」ことは悪手だと思っている。が、顧客や発注者に対しても同じ論法が通じるかというと、それはまた別の話だろう。「空気を読ませるようなRFPを出す発注者が悪い」と言ってはいけない(もちろん限度はある)。この場合は「空気が読める」ことは付加価値だからである。このあたりはまたどこかで考えてみるつもり。

一流の人は空気を読まない (角川oneテーマ21)

一流の人は空気を読まない (角川oneテーマ21)