この本を読みました。
posted with ヨメレバ
ベイカレント・コンサルティング 翔泳社 2016-07-21
自分もエンジニアのひとりとして、ああそうだなあ、と思うところも多く、なかなか面白かったです。全ての項目に対応していくのは大変ですが、まずはひとつでも２つでも気づきがあれば、少しずつでも日常に組み込んでいくことが重要だと思います。
以下、自分用メモです。メモだけじゃ分からないと思いますが、本の中には会話例やそれぞれの説明が豊富にありますので、ぜひ読んでみることをオススメします。
（１） Google に答えを求めるな
[エンジニアの傾向]
調査偏重
技術偏重
フレームワーク依存
追従主義への埋没
[ビジネスリーダーが行っていること]
課題や目標の確認
他人のブレインの活用
仮説からの剥離を怖れない
問題解決の主導
[思考転換]
すぐに調査するのではなく、本質的な課題や目標の特定から始める
自身の技術的知識に走らず、他人の頭脳も活用することを考える
既成概念に縛られず、仮説の変更も怖れない
他人の事例に頼らず、自分たちの問題解決を信じる
[問題解決の７ステップ]
１，課題の抽出
本日的な課題の特定。あるべき姿をイメージする。現状の事実を真摯に認識する。このギャップを文章化する。
２，現状理解・課題の分解
抽出した課題をツリー型に構造化、分解していく。
３，課題の絞込
分解した問いのなかで、大勢に影響を与えない要素を捨てる。
４，仮説構築と検証作業設計
仮説を検証するためのアクションアイテムを洗い出す。
５，重要分析
仮説を検証する。
６，打ちて、戦略の立案、評価、選択
７、実施にむけてのコミュニケーション
（２）右脳を叩き起こせ
[エンジニアの傾向]
事柄の単なる羅列
対処療法的な対策
後手後手の対応
[ビジネスリーダーが行っていること]
表面的な事象にとらわれない
ストーリーテリングで相手を引き込む
課題構造をイメージで共有
[思考転換]
表層的な発見をすぐに伝えるのではなく、慎重に体系化・構造化した上で伝える。
目の前のデバッグに終始せず、語るべき大きなストーリーを話す
図表等を駆使して課題イメージを共有し、解決に向けていち早くスタートをきる
聞いたことや話したいことを、まず視覚的に紙に書いてみる。
この資料を通して、どんなメッセージを伝えるべきか考える。
（３）仮説で語りきれ、非難を恐れるな
[エンジニアの傾向]
顧客の声より調査を優先
網羅性の盲信：抜け・漏れをとても嫌う。網羅的である＝正解では必ずしもない。
受け身のコミュニケーション
技術偏重の意見
[ビジネスリーダーが行っていること]
相手目線での会話
仮説にもとづく展開
提案型コミュニケーション
ビジョンを示す
[思考転換]
情報不足を怖れず、仮説を相手にぶつけてみることで、より早く方向性の合意をえる。
急いで答えをそろえることよりも、まずは相手の悩みをしっかり理解する。
提案＝自分の仕事増加、と逃げずに、常に相手と自分に提案をし続ける。
技術の世界に閉じこもらずに、マネジメントがめざす世界を語ってみる。
調査を優先し、曖昧なことは話さないという慣習もマイナスになることがある。
技術の優秀性にとらわれてしまう。
顧客からの発信をただ待ってしまう。クライアントの将来を考えて新たなビジョンを提示する必要。
まず、与えられた情報で仮説を立ててみるクセをつける。足りない情報は、現状はXXを前提とする、と仮置きする。
[仮説志向]
常に仮説が頭にあり、新しい情報が入る度に仮説が再構築される。
（４）プロセス志向から抜け出せ
[エンジニアの傾向]
過去へのとらわれ
プロセス偏重主義
過剰な過程管理
リスク恐怖症
[ビジネスリーダーが行っていること]
ゼロベース志向
アウトプット志向
高インパクトの提案
トライアンドエラーの実践
[思考転換]
過去の成功や失敗ではなく、あるべき姿から考える。
方法論ではなく、最終成果物にまず目を向ける。
技術的な既成概念にとらわれず、ビジネス的インパクトを追求してみる。
走りながら考えてみる。考えすぎて動かないくらいなら、まず失敗する覚悟で挑戦してみる。
（５）不正確への恐怖に打ち勝て
[エンジニアの傾向]
正確性への盲信
技術的リスクの提示にとどまる
必要以上に詳細な報告
不安によるさらなる詳細化
[ビジネスリーダーが行っていること]
前向きな回答
進め方を含めた提示
実現に向けたプラン提案
推進のためのひと押し
[思考転換]
リスクではなく目的志向で、やる意義、を語り、その上で進め方やリスクをマネジメントする。
技術観点の懸念事項提示にとどまらず、進め方を提示した上での検討事項として整理する。
性格なリスク報告ではなく、クイックなフィージビリティ評価のやり方を考え、プランニング等のビジネス視点での検討の時間をさく
ベンダとしてではなく、ビジネスパートナーとしてクライアントの意思決定をサポートするために検討に注力する。
（６）変更アレルギーを治療せよ
[エンジニアの傾向]
計画変更を嫌がる
見積もり至上主義
指示待ちの姿勢
後手後手の対応
[ビジネスリーダーが行っていること]
ビジネス観点での課題把握
評価観点の確認
提案型の姿勢
顧客のアクションを促す
[思考転換]
技術層での課題解決に固執せずに、ビジネス観点での課題把握からスタートする。
積み上げでのコスト妥当性ではなく、収益面から妥当なコストを検討する。
開発屋として指示される状況から、協働するビジネスパートナーとして検討をリード。
マネジメントのブレインとして動き、相手のアクションを促す。
（７）パソコンを閉じろ、クライアントに会いに行け
[エンジニアの傾向]
デスクトップ調査の盲信
技術シーズのみによる提案
自分中心のペース配分：データを集めるー＞分析ー＞アポ取るー＞クライアントに会うでは遅い。
[ビジネスリーダーが行っていること]
顧客からの情報収集を優先
リアルタイムな問題解決
人間力の重視
[思考転換]
まず相手に会って話すことから、全てを始める。
自分の技術でできることではなく、相手にとってなすべきことを考える。
業務意外の側面からも信頼関係の構築に務める。
（８）自分の事を話すな
[エンジニアの傾向]
カタログ至上主義：顧客のほうを向いた姿勢ではない。
調査項目の羅列
IT領域のみに閉じた選定評価
自分の価値観のみでの打ちての判断
[ビジネスリーダーが行っていること]
オーダーメイド主義
まず結論から述べる
幅広い観点からの評価
顧客第一主義
[思考転換]
自社や自分の説明をやめて、相手の声に耳を傾ける。
結論から話すクセをつける。
技術・ITに閉じずに、事業目線で解決策を考えてみる。
なぜ自分・自社が支援すべきなのか、を常に考える。
目標のない提案には意味がない。
わかりました、という返事と一緒に、より良い提案をするために相手を知るための質問をしてみる。
（９）守りから攻めへと転じよ
[エンジニアの傾向]
否定からのスタート
独善的な判断
マイナス要素を優先
[ビジネスリーダーが行っていること]
肯定からのスタート
客観的事実にもとづいた示唆
プラス要素を優先
[思考転換]
相手の提案にたいして、できます。ただし。。。という表現を意識する。
客観的な事実を並べるだけではなく、そこから導かれる示唆も一緒に伝える。
リスクはその軽減策と一緒に考え、先のアクションにつなげる。
（１０）自分の母親にもわかる言葉で話せ
[エンジニアの傾向]
横文字や専門用語の乱用
話しに一貫性がない
[ビジネスリーダーが行っていること]
適切な言葉の選択
整理された説明
[思考転換]
誰にでも理解できる言葉を使いこなす
重要度にもとづき、説明を構造化する
