MBQ マネジメント・バイ・クエスチョン

「質問によるマネジメント」MBQに関するまとめ

紹介してくださった id:sugilog ++

本書のコンセプト

• 自立促進型のチームをつくる
• 質問によってマネジメントを促す

マネジメント

• 本来の意味
  • ヒト・モノ・カネ・情報といった経営資源をうまく組み合わせて成果を上げる事

プレイングマネージャー

• 多くの課題を抱えている
  • 自身の成果を出しつつ、チームとしての成果を出さなければいけない
  • 悪循環を招きやすい
    1. フォローが大変
    2. 自分でやるようになる
    3. 部下が育たない
    4. ますます自分でやるようになる
    5. ますます部下が育たない
• 目指す姿
  • 自身はハイパフォーマー、チームは自立型
    • 自身がハイパフォーマーである必要性？ => 口だけ上司になってはいけない。実務能力がないと尊敬されない上司になりがち。すると人間関係が円滑にいかなくなる

MBQ

コンセプト

• Management By Question
• 質問を使ったマネジメント
• 上司と部下の"関わり方"を変えるもの
• ロジカルシンキングに基づくもの
• "短期的"な"組織"の"成果"を重視

質問の効用

• 収集
  • 事実・情報・知識を得る
• 主張
  • 意図・指示・決定・命令を伝える
• 考察
  • 価値観・行動・思考・意見・見解を考えさせる

効果的な質問をするための原則

原則1:具体的に質問する

• 焦点を絞って、具体的に質問する
• マネジメントを行う場合、上司が手綱を握る

原則2:予定調和でない質問をする

• 答えを誘導しない

原則3:筋の通った質問をする

• 流れを意識する
  • ロジカルで筋が通ったもの

技法

MBQにおける３つの質問フロー

1. 口火を切る問い
   • 問題を把握し、解決の端緒を見つける
2. 革新に迫る問い
   • 問題の本質や解決の方向性を導き出す
3. 出口に導く問い
   • 解決や実現に向けて一歩踏み出す

問いの５分類

• 以下５種類がある
  1. 事実・経験を問う
     • xxについて、どんな事を知っているか？いま何をしているか？
     • xxの経験は無いか？どんな経験を持っているか？
     • ここでのポイントは4W1H。本当の事実なのか？を明確にする
  2. 印象・感情を問う
     • どのように感じたか？いまどう思っているか？
     • 一番印象に残ったのは何か？どんなイメージを受けているか？
  3. 思考・考察を問う
     • 意見を一言でまとめるとどうなるか？なぜそう思うのか？
     • その狙いは何か？どういう意図があるか？
  4. 価値・原理を問う
     • 大切にするものは何か？xxで本当に良いか
     • これから何が学べるか？本当にその原理が働いているか？
  5. 行動・決定を問う
     • 明日から何をするか？どのように活かすか？
     • 本当に取り組むか？決定事項は何か？
• 上記は答えやすさの順に並んでいる
• ステップを意識して質問する事が大事

心がけ

• 人は変えられない
  • 各人の世界観を最大限に尊重する
  • 抱える問題の解決に向けて合理的な智慧を出す
• 答えを押し付けない
• タイミングを捉える
  • 相手が受け入れる心を持ったタイミングを狙う
  • 観察力が重要になる
• 待つことも大事
  • 「啐啄同時」の精神

シーン毎の活用

シーン

• ６つが想定される
  1. チェック
  2. 問題解決
  3. 軌道修正
  4. 相談・助言
  5. 連絡・報告
  6. フォロー

シーン1:チェック

• 生煮え提案を持ってきた部下に対するMBQ

  1. 目的を捉える
     • 目的は何？
  2. 代替案を捉える
     • 他に手段は無い？
  3. 損得を比較する
     • メリット・デメリットは何？

• 手段が目的化した部下に対するMBQ その１

  1. 状況を把握する
     • 今、何の仕事をしているのか
  2. 目的を捉える
     • なんのためにその仕事をしているのか
  3. 代替案を考える
     • 他に方法は無いのか？

• 手段が目的化した部下に対するMBQ その2

  1. 目的を捉える
     • その仕事はどんな効果を生んでいるのか
  2. 重要度を考える
     • 止めたとしたらどんなまずいことがあるのか
  3. 代替案を考える
     • まずいことは他の方法で対処できないのか

シーン2:問題解決

• 部下の問題を解決したい時のMBQ その1

  1. 問題を把握する
     • 何が起きたのか
     • 5W1Hを明確にするように質問
  2. 原因を探索する
     • なぜ起きたのか
     • 「なぜ」を掘り下げる
  3. 解決策を立案する
     • どうするのがベストなのか

• 部下の問題を解決したい時のMBQ その2

  1. 目標を共有する
     • うまくいけばどのような良いことがあるか
  2. 経験を把握する
     • 今までにどんな取り組みをしてきたか
  3. 追加策を考える
     • さらにこれから何が出来るか

シーン3:軌道修正

• 期待はずれの行動を軌道修正するときのMBQ
  1. 自分を評価する
     • 自分なりに頑張っていると思う？
  2. 使命を明確にする
     • あなたの仕事は誰の何に役に立つのか？
     • 何を目指して頑張っているのか？
  3. 行動を見直す
     • 周りはあなたをどう見ていると思うか？
     • 今の活動があなたの目標に役立つか？

シーン4:相談・助言

• 部下が判断を迷っている時のMBQ

  1. 選択肢を挙げる
     • どんな選択肢が考えられるか?
  2. 相互に比較する
     • それおれのメリットとデメリットは？
  3. 選択基準を考える
     • 何を大切にして選ぶのか

• 一歩踏み出せない時のMBQ

  1. 問題の明確化
     • 本当に困っていることは何か？
  2. 判断を促す
     • 貴方自身はどう考えるのか？
  3. 自信を高める
     • 何を悩むことがあるのか

• 愚痴を溢している時のMBQ

  1. 意思を確認する
     • 本当はどうしたいのか
  2. 実行計画を考える
     • そのために何をすればよいのか
  3. 支援を検討する
     • 何か手伝えることは無いか

シーン5:連絡・報告

• 要領を得ない発言をするときのMBQ

  1. いま何についてはなしているのか？
     • 論点を絞り込む
  2. 言いたいことを一言で言えば
     • 結論を明確にする
  3. 根拠を提示する
     • なぜ、そう考えるのか

• 仕事の要領が悪い時のMBQ

  1. 目標の明確化
     • 今回のゴールは何か？
  2. 道筋を検討する
     • どんなやり方で達成するか？
  3. 通過点を設定する
     • 最初のチェックポイントは？

• 頭の中が整理できていない時のMBQ

  1. 課題の大きさをつかむ
     • やるべきことはどの位あるのか
  2. 重要度を考える
     • 今やらなければいけないことは何か
  3. だいたい可能性を考える
     • あなたしかできないことは何か

シーン6:フォロー

• 仕事がうまく行かなかった時のMBQ

  1. 出来事を特定する
     • 何が起こったのか？
  2. 学習を概念化
     • そこから何を学んだのか？
  3. 行動に結びつける
     • 次はどうすればよいか

• 仕事がうまくいった時のMBQ

  1. 達成感を確認する
     • いま、どんな気持ちか？
  2. 学習を概念化
     • どこが良かったと思うか？
  3. 行動に結びつける
     • 次は何を目指すか？

• 状況を把握する

  • 仕事は予定通りに進んでいる？
• 課題を共有する
  • どんな問題を抱えている？
• 問題に対処する
  • 上司が出来ることは無い？

部下のタイプ別

ミニマム人間

• 考えもせず、すぐ諦める部下に対するMBQ
  1. 原因を明確にする
     • xxがないことが本当に問題なのか？
  2. 優先順位をつける
     • 君しかできなくて、直ぐにやらないと行けないことはなにか
  3. 資源を探す
     • 私や他の人が手伝えることは無いか

雄弁な批評家

• 理屈ばかりで行動が伴わない部下に対するMBQ
  1. 観念を疑う
     • やらずになぜ分かるのか？
  2. 仮設を立てる
     • 仮に何かやるとしたらどんな手があるか？
  3. 着手点を探す
     • 最初の一歩はどこから始めるか？

お荷物社員

• やる気がなくお荷物化した部下に対するMBQ
  1. 過去を振り返る
     • これで終わって良いの？
  2. 未来を夢見る
     • あながたが本当にやりたかったことは何？
  3. 現在を考える
     • あとひとつだけするとしたら何？

組織

• 何かを変えたい時のMBQ
  1. 目標を考える
     • 何を変えたいのか？
  2. 目的を考える
     • それによって何を実現したいのか？
  3. 行動を考える
     • そのために自身はどう変わるのか

ＭＢＱマネジメント・バイ・クエスチョン

書籍『限界を突破する5つのセオリー』まとめ

• 偉人たちが意識的・無意識的に実践していた考え方・行動をまとめた本
• 成長の方法論を確立できていない人にお勧めだと思います

限界を突破する5つのセオリー: 人生の大逆転を生むスマート思考術

• 以下、書籍にある「５つのセオリー」のまとめです

深く理解する

エッセンス

• 複雑な問題に対して、簡単な概念を深く理解することから始める
• 邪魔な要素はどけ、重要な部分を明らかにする
• 知っている事、知らないことをを明らかにする
• かけているものを見つけたら、空白部を埋めるようにする
• 確固たる理解力は成功を築く土台になる

詳細

• 学ぶとは、様々な概念の意味を理解して、それらを結びつけること
• 「理解の基準」をさらに高いところに設定する
• 基礎となるコンセプトやシンプルな礼について、スキルと知識を磨く努力をする
  • トランペットの例::教師と生徒での違い
• 複雑な問題に取り組む際には、簡単な問題にチャレンジしステップアップしていく
• 本質を明らかにする
  • あらゆる紛らわしい部分を見極め、無視し、本質的な部分を抜き出す
  • 抜き出した部分を分析し、そこから得られた洞察を全体に適用する
• 知っていること、知らないことに率直に向き合う
  • 実際に知っていることと、知らないことの接点こそ、学ぶことが進化を発揮し、自分を高められる場所
• 根拠を大事にする
  • 一般的に信じられていることが正しいとは限らない
  • 自分がどうやって知ったのかを確認し、何に基づいて理解しているかを自問する
  • 反対の意見を考えてみる
• 欠けているものを見つける
  • 知識や理解が欠けている空白部を見つけ、認め、埋める
  • 「見えないもの」に気づくには、修飾語を加えてみる
    • "白黒"写真

エキササイズ

• 基本をマスターする
  • 向上させたいスキル、分野をひとつ選ぶ
  • 五分間で、スキルや分野の基礎をなしている要素を具体的に書きだす
  • リストにあがった項目を一つ選び、30分かけて、その習熟度を高める
• 「自分にはどれだけわかっているか」と問う
  • 既に知っていると思っている分野や、マスターしていると思っている分野に対して
    • 何にも頼らずに、その分野の概念を詳しく書き出す
    • 理路整然に、正確に、包括的に書けているか？
    • 欠けている知識は無いか？主な例を思いつくか？知識の断片を結びつけて全体像を掴めるか？
  • 外部の情報と照らし合わせる
• 本質的なものを明らかにする
  • 理解したい分野において、本質的な要素がひとつ姿を表すまで邪魔なものをどける

間違ってみる

エッセンス

• 成功するために失敗する
• 理解不足の箇所や予期していなかったチャンスを与えてくれる
• 創造力をかきたててくれる

詳細

• 偶然の失敗を歓迎する
  • 失敗を、洞察をもたらし方向性を指し示してくれる優れた情報源にする
  • 「この試みは失敗だ。なぜかと言うと」と自分に問う。そして、その過ちを正す方法を探す
• 間違いに対する反応
  • 間違いにカラ、さらに良い試みを導き出す
  • その間違いが正しい答えになるような別の問題が無いかを考えてみる
• わざと失敗する
  • 極端に考えてみる
  • 洞察やインスピレーションを得ることが出来る

エキササイズ

• 空白の時間(悩んでるフリみたいなの)をやめる
  • 問題や課題をあげる
  • 思っていることをどんどん書きだしてみる

問う

エッセンス

• 理解していることをさらに明確にして、それをもっと深めるために常に問いを抱く

詳細

• 答えが問いを導く
  • 「もしこうしたらどうなる」という問いを行う
• バイアスの克服
  • 「自分は本当に理解しているのか？」
• 他の面から眺めてみる
  • 「問題を異なる視点から見るとどうなるか？」
    • 数学問題::数値的、図式的、代数的、物理的
    • 社会問題::経済、グローバル、地域、歴史
    • 進化論的::何が変化を生じさせているのか、将来どのような変化を引き起こすか
    • 他の分野同士を結びつけるのも有効
• 問う習慣
  • 何をしている時でも、常に質問を考えるようにすう
• 正しい問い
  • 行動を導くもの。曖昧なものではない
    • 「どうやったら成功出来るか？」 => 成功は定義づけられているか？
  • 理解を明確なものにし、重要な点に注意を向けてくれる
    • 「どうやったら試験でA評価がとれるか？」 => Not good
    • 「この教材によりよく取り組めるようにするにはどうすれば良いだろうか」
  • 効果的な問いは、本当の問題を明らかにする
    • 「アフリカ系アメリカ人の数学の成績はなぜ標準以下なのか？」 => Not good
    • 誤った「人種」という変数に意識を向けてしまっている

思考の流れを追う

エッセンス

• 過去を振り返り、思考の原点を探る
• 将来を見て、思考の行方を見極める

詳細

• 「過去」から「現在」への流れを意識する
  • 今まで学んだトピックにおいて、「何が」が「どんな戦略で」新しい概念に発展しているかを理解する
  • 突拍子もないように見えるアイディアも、積み重なっているものに対して少しのアイディアを加えているものである
• 「現在」から「未来」の流れを意識する
  • 今学んでいることを元に、次に起こることを予測してみる
  • 古いアイディアから新しいアイディアを考えてみる
    • 発展、応用させられないか？
• 最良のものでも、さらによく出来る
  • 新参者は今までの歴史や苦労を知らず、０から物事を見る。しかしそれが発展の呼び水となる
• 正しい夢
  • 頂上と思えた場所に身を置き、そこから一歩一歩を次々に踏み出してさらなる高みを目指す自分の姿

変化する

エッセンス

• どんな状況にいようとも、向上し、成長する事が可能

詳細

• エキスパートのやり方
  • もっと熟練した人ならどうやるだろうか
  • エキスパートなら、どのような知識や理解や以前の経験などを作業に盛り込むだろうか
  • 作業をもっと簡単なものにしてくれる知識やスキルや戦略はなんだろう

mongodbまとめ

(随時更新)

基礎

特徴

• スキーマレス
• BSON形式での保存
• カーソルを介して操作を行う
• インデックス機能を有し、RDBMSと同じ機能を持つ
  • ドキュメント内のどの属性にもINDEXを生成可能
  • Unique/複合 Indexも生成可能
• Replication可能
• Auto-Sharding
  • 指定したShard Keyで水平分割
  • mongosを解することで、ClientはShardの詳細を意識する必要が無くなる
  • mongocがShard情報を保持
• 得意
  • 複雑なデータ構造
  • メンテナンス性
    • 動的データ構造の変更が可能
  • 耐障害性、スケーラビリティが高い
• 不得意
  • 信頼性の高い部分(MySQLなどのDBMSには劣る)
  • オンラインバックアップ

用語

• MongDBは0個以上のデータベースを持つことが出来る
• DBには0以上のコレクションを持つことが出来る。コレクションはテーブルと同義
• コレクションには0個以上のドキュメントを持つことが出来る。行と同義
• ドキュメントには1つ以上のフィールドを持つことが出来る。列と同義

操作

• mongoシェルにおいてjsを実行できる

演算子

演算子	意味
$lt	未満
$lte	以下
$gt	より大きい
$gte	以上
$ne	非等価

データ挿入

db.unicorns.insert({name: 'Aurora', gender: 'f', weight: 450})

データ確認

基本

db.unicorns.find() 

条件付き

db.unicorns.find({gender: 'm', weight: {$gt: 700}})

orで検索

db.unicorns.find({gender: 'f', $or: [{loves: 'apple'},
                                     {loves: 'orange'},
                                    {weight: {$lt: 500}}]})

任意のフィールドのみ(idはかえってくる)

db.unicorns.find(null, {name: 1})

昇降順

//重い順
db.unicorns.find().sort({weight: -1})
//ユニコーンの名前と vampires の多い順
db.unicorns.find().sort({name: 1, vampires: -1})

データ削除

//条件付けしていないので、全てのドキュメントが消える
db.unicorns.remove() 

更新

//$set演算子を利用する
db.unicorns.update({name: 'Roooooodles'}, {$set: {weight: 590}})

//$incを使うと値の増減が可能
db.unicorns.update({name: 'Roooooodles'}, {$inc: {weight: -2}})

//upsertは、updateを試みて対象が存在しなければinsert
db.unicorns.update({page: 'unicorns'}, {$inc: {hits: 1}}, true);

//デフォルトでは最初にヒットしたドキュメントの更新しか行わないので、4番目の引数をtrueにする
db.unicorns.update({name: 'Roooooodles'}, {$set: {weight: 590}}, false, true)

レプリケーション

運用事例

Ameba pico

• http://www.slideshare.net/matsukaz/awsmongodb
• mongocとmongodは別サーバ
• ジャーナリングを有効化
  • 障害時のデータロストのリスク低減
  • パフォーマンスは低下
• oplogsizeは10GB
  • 障害発生から復旧作業にとりかかるまでの予定時間から算出
• Indexはあらじめ生成しておく事が重要
  • 生成中は全てのオペレーションがブロックされる
• コネクションプーリングのチューニング
  • connectionsPerHost : コネクション数
  • threadsAllowedToBlockForConnectionMultiplier : 1コネクション辺りの接続待ち数
• Shard
  • db.printShardingStatus()でShard間のchunkの偏りを定期的にチェック
• Collection
  • 新規追加時は負荷に気をつける。Primary Shardｎデータが偏り急激に負荷がかかる可能性があるため
• バックアップ
  • オンラインでの実施は難しい
  • メンテを設ける
  • SECONDARY Backupを検討中
• 障害事例
  • moveChunkしたら他のmongosからデータが見えなくなった。
    • Shard情報がうまく伝わらない事があるらしい。mongosを再起動させれば復旧？
  • 数値の型変換エラー
    • アプリからのデータストアはinteger、コンソールからはdoubleとなり型変換エラー
    • NumberIntを利用
  • mongoimportの不具合
    • データが減ったらしい
    • 件数をしっかり確認しながら使ったほうが良いらし
  • movePrimary
    • Shard情報が更新されないまま別Shardにデータが移ってしまった
    • Documentでも警告中との事

参考

• mongodbの薄い本
• Web

書籍『なぜ危機に気付けなかったのか』まとめ

はじめに

• 問題解決の前提として問題発見があり、その能力を身につけなければいけない
• 問題・課題に気づかず事が手遅れな脅威にしてはいけない
• 問題を包容力をもって受け入れる
• 小さな問題を、もっと大きなものに関連付ける。潜在的な問題の表面化ではないのか？と
• 問題が隠れる原因
  1. 恐れの文化
  2. 組織構造の複雑化
  3. 情報のフィルタリング
  4. 問題発見のための教育不足
     • トリガーがリストにまとまっている事は重要
• 問題の発見は、絶え間ない改善のプロセスの結果
• 以下、問題発見に必要な７つの能力について

7つのスキル

1. 情報のフィルターを避ける

「ワインと違って、悪いニュースは時が経つにつれてよくなるような事はない」

• 情報のフィルタリングによって、異変検知が出来なかったり重大な事故を招くことがある
• フィルター発生の原因
  1. 効率性への配慮
  2. 大勢順応への圧力
  3. 確証バイアス
  4. 利己的な低減
• フィルターを避けるための５つの手法
  1. 自分の耳で聞く
  2. 様々な意見を探して聞く
  3. 若い人の話を聞く
  4. 周辺まで脚を延ばす
  5. 利害関係のない人の話を聞く

2. 人類学者のように観察する

「注意深く見ているだけでおおくの事が学べる」

• 発言と行動の間にギャップが生まれる要因
  1. 誘導尋問
  2. 集団力学
  3. 無意識
• 観察力を磨く
  • 人や業務プロセス、説部を注意深くかつ体系的に観察している
• 効果的な観察を行うための原則
  • 観察を始める前に先入観を払拭する
  • 異なる状況のもとで、さまざまな視点からの観察結果を広く集める
  • 判断力を活かして情報提供者を探す
  • 重要な会話の引用を含めて忠実にメモを取り、重要な物証を収集する
  • 積極的に聞き耳を立てる
  • 驚くべき、あるいは従来信じていたことと矛盾する観察結果を体系的に追跡し続ける

3. パターンを探し、見分ける

「理解するということはパターンを察知することだ」

• 人はいつも類推によって意思決定をしている
  • だがその類推が正しいとは限らない
  • 類似性の過大評価と相違点の無視に対して注意を払う必要がある
• 類推力を高める
  • 以下の質問を投げる
  • この状況における事実は何か
  • 曖昧、不明瞭なことは何か
  • 明瞭な想定と、暗黙の想定から考えられることは何か
  • 事実と想定を混同していないか
  • 偏見のない考え方を持った外部の人は、自分の想定をどのように評価するだろうか
  • 重要な想定が間違っている事がわかれば、自分の結論は変わるだろうか
  • 重要な想定の正しさまたは間違いを立証するために、データを収集したり、簡単な実験をしたり、あるいは一定の分析をしたりすうることが出来るだろうか

4. バラバラの点を線でつなぐ

「想像力とは一見つながりのないもの同士を結びつける力である」

• すべての複雑な組織は細分化の必要性と統合化の必要性とのバランスを取らなければならない
  • 細分化
    • その組織のミッションにおける特定の局面に専念して専門特化するチームを編成することによって業務を遂行する手法
    • 専門化した組織は往々にして独自性を高め、そこで働く人は全体として組織よりも所属組織に帰属性を持つようになることがある
• 情報共有の阻害を阻止しなければいけない
  • 阻害の要因
    • 「知識は権力なり」
    • 情報の信頼性を求められる
• リーダーが情報共有促進をさせる方法
  • 「意思決定の内容にまで立ち入ることなく、チーム内での討議を円滑にするために指示や命令を出す」事が重要
    1. 少数人が議論を牛耳ることがないようにする
    2. 新しい意見が出た時に、その意味を明らかにするための質問をする。他の人がそれを要点を理解しているかを確認する
    3. 様々な視点での意見を求める
  • 不明瞭な点が残っている分野にスポットライトを当てる時間をとる
    1. 優れた意思決定をするために他に知っておくべきことがないか
    2. さらに追加情報を収集して検証しなければならないような想定をしただろうか
    3. その情報はどこで見つけることが出来るか
    4. 追加データがあればチーム内の意見の相違を解消することが出来るだろうか
    5. そのデータに誰がアクセスできるか
• 組織における情報共有の促進
  • 配置転換による相互理解
  • wikiシステム

5. 価値のある失敗を奨励する

• 問題を見つけるために、失敗に関する発想を変える
  • リスクを取る行動や失敗を容認する文化形成が、組織が直面する問題や脅威を明るみに出すことに役立つ理由
    • 問題が明るみに出やすくなる
    • 問題発見のペースが速まる
    • 失敗をした本人の配置換え発生が無くなることで、組織としての経験を積むことが出来る
• 「防止する」への意識
  • 火種の発見を優先する
• 「統合的思考能力」を育てる
  • 「相反する、調和しないアイディアを合成する能力を磨く」
  • 以下への取り組みが重要
    1. 「さほど明らかではないが、関連性がありそうな要因」を広い範囲で、積極的に探す
    2. 複合的な原因によって、結果が生じていることを認識している。状況、組織を個々の部分に切り離さず、体系的に考える
    3. 「根本的な帰属の誤り」に注意する
• 容認の可不可の判断軸
  • 失敗の前
    • 計画段階のプロセスはどのようなものだったか。
      • 複数の選択肢の検討を怠っていなかったか。反対意見を押さえつけていなかったか。情報の集め方が偏っていなかったか
      • 明確な目標を立てて、実行に携わる全員に周知させたか
      • 複数の目標がある場合、優先順位をはっきりしていたか
      • マイルストーンを設置し、適切に管理できる体制が整っていたか
    • 事前検証を行なっていたか
      • 適切なリスクとコストで実施していたか
      • 期待通りの結果を出すためのテストになっていなかったか
    • 事前調査
      • 過去の成功・失敗から学ぼうとしたか
  • 活動の最中
    • 組織の価値観、原則に則っているか
    • 責任者が進捗状況を計画的に測定していたか
    • 損失が発生する場合、最小に留めることをしていたか。サンクコスト発生していなかったか
  • 失敗の後
    • 責任者は、最終的な意思決定をしたことを潔く認めているか
    • 「活動の反省会」を実施しているか。この際、公正な立場の人を積極的に招くこと
    • ただでは転ばない意識を持っているか。次へ生かしたり、何かしらの形で財産を取り戻そうとしているか

6. 話し方と聞き方を訓練する

• 航空輸送における自己の主な原因は「人と人とのコミュニケーション、チームワーク、意思決定およびリーダーシップの不足」
• 上記解消への取り組みがCRM(クルーリソースマネジメント)
• 引き継ぎ
  • 対面でコミュニケーションする
  • 先立って、情報を書面で伝えておく
  • ブリーフィングをできるだけ簡潔にして、その間に邪魔が入らないようにする
  • 代表者だけでなく、全員が出席して引き継ぎを行う
• 率直で効果的な話し方
• 聞き方
  • 聞き手のことを知る
  • これまでの経緯を理解する
  • 支持者を探し、同盟を組む
  • 腹心やゲートキーパーを通じて働きかける
  • まず考え方を変えさせることに焦点を絞る
  • 解決の選択肢を提示する

7. 行動を振り返り、反省のプロになる

「鏡をよく見ることだ。そして、一時的な優性を本質的優越性または優越性永続の兆候と同一視する誘惑に負けてはいけない」

• 教訓を学ぶ際の振り返り
  • 我々は何をすることを目指したのか
  • 実際には何が起きたのか
  • なぜそれが起きたのか
  • 次回はどのようにすればいいのか
• 成果につながらない分析
  • 一般的な分析をしすぎている
• デリベイトプラクティス
  • 計画的に熟慮された訓練
  • 特定の上達目標を設定し、すぐにフィードバックが得られるような仕組みを整える
  • うまく実行できないことに焦点を絞る
• 成功、失敗、どちらも振り返る

優れた問題発見者の心構え

• 相当レベルの知的好奇心を持つ
  • 常に積極的に質問する
  • 知っていることでも知らないことでもさらに詳しく学ぼうとする
• システム思考
  • 小さな問題を組織の広範なシステムの問題の指標として役立てる
• 健全な偏執狂
  • 心配症でいる
• 全ての事象を改善のきっかけとして捉える

なぜ危機に気づけなかったのか ― 組織を救うリーダーの問題発見力

「論点思考(内田和成さん)」のまとめ

論点思考

• 論点とは
  • 本当に解くべき問題
• 論点指向とは
  • 論点を導き出すために用いる思考

論点を導き出すステップ

• 以下に示すステップを用い、論点を導き出していく
• ただし、各ステップをいったりきたりしながら修正を繰り返し、設定する

論点候補を拾い出す

• 「事象」に対して、何が「論点」なのかを検討するステップ
• 「事象」と「論点」 は別物である
• 論点を導き出すために意識すべきことは以下
  • 論点は動く
    • 人によって異なる
      • 誰の論点を解こうとしているのか？
      • 相手の発言の真意、意図、バックグランドを考える
    • 環境とともに変化する
    • 論点は進化する
      • 論点を探るうちに、より本質的問題に当たる事がある

論点を絞り込む

• 拾い出した論点候補に対して、絞り込んでいくステップ
• あたりをつける
  • 白黒つけられそうなところからアプローチする
  • 依頼者の関心の低い分野を探る
    • 依頼者に見えていない部分があるため
  • 「なぜ」を繰り返す
    • つぶせないところ、引っかかるところが出る
• 実現可能性を意識
  • 解けない問題、解いても成果の上がらない問題には取り組まない
  • 3つのポイント
    1. 解決できるか、できないか
    2. 解決できるとして、容易か否か
    3. 解決した時の効果はどうか

全体像で確認、論点を確定する

• 最終的に論点を決定していくステップ
• プロービングの実施
  • 関係者への質問を行い、反応を伺う
  • 論点を確定していくための3つのアプローチ
    1. 質問して相手の話を聞く
    2. 仮設をぶつけて反応を見る
    3. 現場を見る
• 自分の考えの「引き出し」を参照する
  1. アナロジー、他社事例
  2. 顧客視点
  3. マクロ視点(鳥の目)、ミクロ視点(虫の目)
  4. 過去の経験
• 論点を構造化する
  • 方法は様々
    • キーワードを書き並べ、論点として成立しているかを考える
    • 論点を書き並べ、関係性を図示する
  • 上位概念の論点を捉える
  • あたりをつけながら実施
    • 大論点=>中論点=>小論点のツリー上に構造化した際、虫食い部分が出てくる。その場合そこが何なのかを考えたりしてみる

論点思考を鍛える

• 常に「本当の問題は何か？」を問い続ける
• 「視野」「視座」「視点」を意識
  • 周囲を見る
  • 顧客の立場で考える
  • ポジションを上げたところから見てみる
  • 逆張りの発想
  • 業界最下位だったらどうするか
  • 現場目線で考える
  • 両極端に振って考える
  • 夢を見る人になる
  • 自然界の事象当てはめてみる
  • 日常生活からの発想
  • アナロジーからの発想
  • 顧客視点で考える

論点思考

リーダブルコード

リーダブルコードを読んだまとめ

名前に情報を詰め込む

• 明確な単語を選ぶ
  • 類語辞典等おすすめ
• 汎用的な名前は避ける(明確な目的がある場合は除く)
• 物事の詳細を説明する
• 大切な情報を追加する

誤解されない名前

• 「他の意味と間違えられることは無いか」を自問自答
• 具体的ノウハウ
  • 限界値 : mitとmax
  • 範囲指定 : firstとlast ( first <= n <= last の意味合いで使う)
  • 包含/排他的範囲 : beginとend( begin <= n < end の意味合いで使う)
  • ブール値 : prefixにis/has/can/shouldをつけるとわかりやすい。disable_sslのような否定形は避ける
• 関数のユーザの期待を知る
  • get : メンバーの値を返すだけの「軽量アクセサ」
  • size : O(1)の計算量で済むもの

美しさ

• 一貫性と意味を持ってコードを整形する
• 複数のコードブロクで同じような事をしていたらシルエットも同じようなものにする
• コードの列を整列すれば、概要が把握しやすくなる
• 常に意味のある順番を選んでそれを守る
• 空行を使って、大きなブロックを論理的な段落に分ける

コメントすべき事を知る

• コメントの目的は書き手の意図を読み手に知らせること
• コメントすべきでは無いこと
  • コードを読めばすぐわかること
  • ひどいコードを補う補助的なコメント。コードを直そう
• コメントすると良いこと
  • なぜコードがそのやり方を選択しているのか
  • コードの結果。TODO:やXXXを使う
  • 定数の値にまつわる背景
  • ファイルやクラスの全体像
  • コードブロックの概要

コメントは正確で簡潔に

• 多くの意味が込められた言葉や表現を使って、コメントを完結に保つ
• 「それ」や「これ」といった代名詞を避ける
• 関数の動作を正確に説明する
• コメントに含める入出力の実例を慎重に選ぶ
• コードの意図は詳細レベルではなく高レベルで記述

制御フローを読みやすくする

• 比較を書くときは、左に変化する値、右に安定した値を配置する
• if/elseブロックは、先に肯定的・単純・目立つものを処理する
• ネストを避ける。直線的なコードを意識する
• 早めに値を返してあげるとコードをクリーンに保てる
  • ループ内部ではcontinueを使うと似たようなことを実現出来る

巨大な式を分割する

• 説明変数。username = line.split(':')[0].strip() if username == "root":のようなもの
• 要約変数。final boolean user_own_document = (request.user.id == document.owner_id)
• ドモルガンの法則を使う

変数と読みやすさ

• 邪魔な変数を削除する
  • 役に立たない一時変数は使わない
  • 中間結果を保持するための変数を使わなくて良い方法を探す。(その場で処理してしまう)
• 変数のスコープを出来るだけ小さくする
• 一度だけ書き込む変数を使う。変数を操作する場所が増えると、現在地の判断が難しくなる

無関係の下位問題を抽出する

• フロー
  1. 関数やコードブロックを見て「このコードの高レベルの目標は何か」と自問する
  2. コードの各行に対して「高レベルの目標に直接的に効果があるか？あるいは、無関係な下位問題を解決しているか？」を自問する
  3. 無関係の下位問題を解決しているコードが多ければ、それらを別関数にする

一度に一つの事を行う

• コードはタスクを一つづつ実施する
  1. 行なっているタスクを列挙する
  2. タスクを分割する

コードに思いを込める

• 簡単な言葉で説明する

短いコードを書く

• できるだけコードを書かない
• そのプロダクトにその機能が本当に必要かを考える
• その問題を解決できるような要求を考える
• ライブラリに慣れ親しんでおく

テストと読みやすさ

• 容易に追加、変更できるようテストを読みやすくする
• 大切でない詳細はユーザから隠す。大切な詳細は目立つようにする
• 入力値は、コードを完全かつ最も単純にテストするものでなければならない
• 一度に全てをテストしない。分割する
• テストの容易性について
  • 低い
    • グローバル変数を使っている
    • 多くの外部コンポーネントに依存している
    • コードが非決定的な動作をする
  • 高い
    • クラスが小さいor内部状態を持たない
    • クラスや関数がひとつの事をしている
    • クラスが他のクラスにまり依存していない。疎結合かされている
    • 関数は単純でインターフェースが明確である

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)