Gartnerのハイプサイクルから見るIT新技術のトレンド～ビッグデータの流行りは終わった～
どうもkoheiです。
秋も深まってきました。
先週、IT調査会社のgartner japanが日本におけるテクノロジのハイプサイクル2018年が発表されました。
今回はこの記事を基に、IT業界の流行りについてみていきたいと思います。
ハイプ・サイクルって？
wikipediaにのってました。
ハイプ・サイクル（英語: hype cycle、ハイプ曲線）は、特定の技術の成熟度、採用度、社会への適用度を示す図である。ガートナー社がこの用語を造り出した[1]。
あんまり聞いたことないなって思ってましたが、それもそのはず、ガートナーが生み出した言葉でした。
ハイプサイクルは次の5角段階から構成されるそうです。
黎明期（技術の引き金、Innovation Trigger）
流行期（過剰期待の頂、Peak of Inflated Expectations）
幻滅期（幻滅のくぼ地、Trough of Disillusionment）
回復期（啓蒙の坂、Slope of Enlightenment）
安定期（生産性の台地、Plateau of Productivity）
このハイプサイクルを通すことで、世間的に期待の集まっている新技術をピックアップしたり、幻滅期に入り世間的にしぼんでいく技術がどれなのかを確認することができます。
「うちの会社で最近○○について導入を検討してみたけど、もう幻滅期やんけ！トレンド遅れてる！」
とか、
「お、最近聞いたあの会社、これから期待できる技術もってるな。もう少し話聞いてみるか」
とかいう判断基準になるわけですね。
もともとガートナーがこれを作り出したのも企業が最新技術を取り入れるべきか否かの判断材料の一つとして利用するためだと言われています。
ただ一点注意ですが、もちろん幻滅期に入ったら技術的にオワコンというわけではないです。幻滅期、回復期のものこそ、技術的に安定しつつあるものという捉え方もできます。まあ、そもそもガートナーが勝手に決めてることなので一つの参考情報程度です。
ただ調査を仕事にしているだけあって、それなりによく調べられてるんじゃないかなぁと思います。
ではさっそく、ハイプサイクルについてみてみましょう。
ガートナー社のニュースリリースより、ハイプサイクルの図を引用しています。
ビッグデータで盛り上がる時代は終わった
さて、このハイプサイクルですが、最初に目をつくのはやはり「ビッグデータ」が「安定期に入る前に陳腐化」とされている点です。
ここでいう「陳腐化」というのは、技術的に陳腐化していくというより、世間や企業の期待や関心の高さを示しています。
確かに、最近ニュースとかでも「ビッグデータ」って聞かなくなりましたね。単なる「データ」とかいう方が多い気がします。
おそらく、いわゆる「ビッグデータ」が当たり前になってそのデータを使って何をすべきか？という点に関心が向いているからだと思います。
そのほか、「人工知能」や「ブロックチェーン」についても、期待のピークを越え「幻滅期」に入ろうとしており、バズワード的な流行りから、具体的な利用検討にシフトしている様子も伺えます。
次に期待されるテクノロジー
細かいものがいろいろありますが、個人的な気になるポイントをピックアップ
1. IoTプラットフォーム/IoTセキュリティ
幻滅期に入っているIoTとは別に、これから期待として高まっているのがIoTプラットフォーム＆セキュリティです。これはIoTが広まるときから懸念されていたポイントで、あらゆるモノがネットワークとつながった先に、それをどう制御して活用すべきか？かつ安全に扱うべきか？という課題が高まっているという事実を示しています。
IoTプラットフォームについては、IT業界だけでなく製造業からも開発提供する企業が出ており、今後競争がさらに激化していくことが予想されます。
2. 市民データサイエンス
これぱっと何かわからなかったんですが、、、調べてみました。
そこで見つけたのが、やはりGartnerの記事
Gartner defines a citizen data scientist as a person who creates or generates models that use advanced diagnostic analytics or predictive and prescriptive capabilities, but whose primary job function is outside the field of statistics and analytics.
これによると、市民データサイエンティストは、本業データサイエンティストじゃないけど、データ分析スキルを持つ人のことをいいます。
つまり、専門家でなくても一般的な人々がデータ活用ができるような環境が実現されることを言っているんですね。「データの民主化」と呼ばれるキーワードもあるように、誰もがデータを活用していく時代になっていく…ということですね。
3. AIOps
AIOpsの正式名称はAlgorithmic IT OperastionsともArtificial Intelligence for IT Operationsともいわれてます。これもGartnerが生み出した言葉のようです。
ちょっと前までのDevOps(開発と運用を一体化してソフトウェア開発を行う)に近いように感じますが、もう少しIT運用目線が濃くなっているように思います。
AIOpsの目指すものは、データに基づいてAIを使って人手を最小限にしたIT運用を実現することです。
例えば、自動的にリソースを監視してシステムの異常検知を行ったり、その結果に基づいて故障回復処理を自動的に行ったり、あるいは測定値に基づいてリソース制御を行ったり・・・というのを一元的に実現することが想定されます。
こうして例を挙げてみると、一つ一つは今までの自動化技術に思えますが、さらに踏み込んで人間の判断を機械に任せる部分にも入り込もうとしているんじゃないかなぁと思います。
AIOpsを実現するソリューションを提供する企業もいくつか出てきているようです。
OpsRamp
SaaSベースのIT運用管理プラットフォーム。AWS, Azure, GCPといったマルチクラウドに対応して、アラートやイベントの推論もAIを使って実現しているそうです。
Moogsott
機械学習をベースとしたSaaSソフトで、企業向けにマネジメントソリューションを提供しています。CiscoやYahooでも利用実績があるとか
まとめ
さて、今回はGartnerのハイプサイクルを基に、IT技術の期待やトレンドを追ってみました。まだまだ知らない技術もたくさんありますが、引き続き、特に新技術については、まだまだトレンドを追っていく必要がありそうです。
ではでは
One life, One password その１
どうもhaseです。
今年日本国内進出を果たしたOPPOが、先日フラッグシップモデルFind Xの発売を発表しました。このスマホ、面白いのがインカメがスマホ前面になく、顔認証・撮影等するときにシュッと上部から飛び出してくるんです。それによって驚異の画面占有率93.8%(iPhone Xs Maxで84.4%)という、真の全画面スマホを実現しています。
早速ベンチマークブーストの話も出てきちゃってますし、こういうギミック系が定着するイメージもあまりないんですが、単純に面白いなあ、と。発売は11月上旬以降で、価格は税抜11万1880円とのこと。皆さんいかがでしょうか。持っていれば合コンのネタくらいにはなるかもしれません。
さて、前振りが長くなってしまいました…。
長かった割にまさかの1ミリも関係ないんですが(笑)、今日は認証の話をします。
SSO
どんどん増えるウェブサービス、社内システム。
あれ、このサイトのパスワードなんだっけ…って思ったこと１度や２度じゃないですよね。だからパスワードは紙にメモってる！とかデスクトップにメモって保存してる！って人いるんじゃないでしょうか。それ、だいぶ危険です。
一つのID/PWで全てのサービスに安全にログインできたら…。
これを実現するのがSSO（= Single Sign On）です。
今日はこのSSOの概要・メリット/デメリットについて述べていきたいと思います。
SSOとは？
繰り返しになりますが、一つのIDとパスワードを入力して、複数のWebサービスやアプリケーションにログインする仕組みです。入力や管理の手間を省き、セキュリティを強化することができます。
最近何かのサイトにユーザ登録する際に、Facebookでログイン、とか出てきませんか？あれです。
あとは社内にSSOを導入している企業であれば、社給パソコンにログインするIDで社内の勤怠管理システムだとか、発注システムなんかにも入れるんじゃないでしょうか。
これらがSSOと呼ばれる仕組みです。
SSOのメリット/デメリット
- メリット
何と言っても一つのID/PWでログインできるというところに尽きますが、それによる副次効果もたくさんあります。
まず、セキュリティ面。
IPAによる不正アクセス調査によると、不正アクセスの手口として最も多いのが利用権者のパスワードの設定・管理の甘さにつけ込んだもの（35.3%）です。
2015年不正アクセス統計・パスワードの不備が大きな原因に｜大塚商会
例えば、上記のように紙にメモしておいたり、デスクトップに保存しておく人結構いるかと思いますが、メモをなくしたり、机の上に開いていたり、デスクトップにロックをかけずに席を立てば、簡単にパスワードが流出します。でもID/PWが一つだったら？さすがの僕でも覚えられます。例えばパソコンのログインパスワードをメモってる人ってあまりいないですよね。それを他のサービスにも使えれば、メモっておく必要はないです。
また、複数のパスワードを設定しようとすると、結局同じパスワードを設定していたり、覚えやすいものを使ったりしませんか？これはブルートフォース攻撃（総当たり攻撃）による侵入を容易にします。それぞれのサイトにパスワードを設定する場合、パスワードが一つバレても他は大丈夫と思われがちですが、 使い回しやちょっと数字を変えただけだと簡単に侵入できてしまいます。
また、認証情報を管理する側からもメリットがあります。一元管理されていることによって、そこだけ本気で守ればいいですし、ユーザの新規登録/削除、パスワードの再設定作業なども楽チンです。 - デメリット
便利さの裏返しですが、パスワードが一つばれると、全てのサービスに入られてしまいます。また、統合認証基盤が落ちてしまうと、どのサービスにも入れなくなってしまいます。ユーザに対するセキュリティ教育や、パスワードの定期的な変更、統合認証基盤の冗長化などで対応していく必要があります。
SSOの大きな二つの流れ
SSOを実現する仕組みはいくつかありますが、個人的には大きく２つの流れがあると思っています。
- BtoB系
これは企業内の業務システムにおいて発達してきたSSOです。先ほどの例でいうと、社給パソコンへのログインID/PWで、勤怠管理等社内システムへのログインを可能にするタイプです。
基本的にはオンプレ想定の方式が多いですが、SAMLという標準プロトコルを使用すると、クラウドサービスなどとのSSOも実現可能です。 - BtoC系
こちらはFacebookでログイン、のタイプです。ソーシャルログインとも呼ばれます。Twitter社のブレイン・クック氏をはじめとした開発者が集って開発したOAuthなんかが有名ですが、初めからウェブサービス同士を連携させるという思想のもとに設計されてます。OAuthは正確には認証はしていないのですが、SSOと言って問題ないでしょう。
それぞれの具体的な仕組みについては、次回以降説明していきたいなと思ってます。
まとめ
複数のウェブサービスを利用するのが当たり前になっている現在、SSOはとても便利な仕組みだと思います。最近は冒頭のFindXのように（無理やり繋げました）顔認証などの生体認証が流行りですが、オンラインに生体情報を載せるのは僕はまだちょっと抵抗がある。生体情報って流出しても変えられませんしね。
ビル・ゲイツは2004年に"The password is dead"と宣言したそうですが、14年経った今でもバリバリの現役です。パスワードは完璧ではないですが、やっぱり使いやすいですからね。この傾向はまだしばらくは続くでしょう。SSOを利用して、もっと便利に安全にサービスを利用する仕組みが整えばいいなと思います。
では今回はこの辺で。
論理を武器にしよう〜ロジカルシンキング実践
どうも、ITコンサルタントのShoheiです。
Googleのスマホ、Pixel 3が最近すごく気になっています。
さて、今日は前回の続編として、ロジカルシンキングの実践編に入っていきましょう。
これまでのおさらい
前回記事では、ビジネスにおけるメッセージについてお話ししました。
"課題"・"答え"・"相手に期待する反応"からコミュニケーションがなり、さらに答えは"結論"・"根拠"・("方法)")からなることを説明しました。
何故あなたのメッセージは響かないのか (ロジカルシンキング/ビジネスコミュニケーション) - IT社員3人組によるリレーブログ
また、いくつか前の記事では、MECEについて解説をしています。
重複なく、漏れなく、ずれなく、を実現するためのアプローチ手法ですね。
本質理解とMECEアプローチ (ロジカルシンキング入門) - IT社員3人組によるリレーブログ
今回のお話
今回は、"課題"に対する"答え"を論理的に導くための手法について説明します。
なお、前回同様ですがここでの解説は以下の本から得た知識を元に記載しています。
当たり前ですがこの本で書かれていること全てを書くことはできませんし、すっ飛ばしている部分も多くあります。
ここでの話はロジカルシンキングを考える上でのとっかかりとして利用し、より詳細な理解には、この本や他の本をご自身で読んで理解し、練習を重ねることをお勧めします。
論理の基本構造
まずは、論理構造の基本について説明します。以下をご覧ください。(図は本を元に作成)
いきなりなんのことだ?という状態かと思いますので、上から説明しつつ、ポイントをあげていきます。
ポイント①
まずは課題に対応した結論を書きます。一番上の矢印のことですね。
「修学旅行でどこにいくべきか」という課題に対して、「京都にいくべきです」と答えること。「修学旅行は怪我等に備え保険に入っていることが重要である」という見当違いのものではアウトです。
ポイント②
答えである「京都にいくべきです」に対して、"Why So?(なんでそうなん)"と聞かれた時の答え要素が、下矢印の先、A,B,Cに記載されています。具体例は後ほどだしますが、その理由だったり、考察に用いた要素がABCに記載されます。
逆にABCから答えに戻る上矢印は、"So What(だからなんやねん)"という関係になっている必要があります。
ポイント③
"Why so?"で展開される要素たち(ここだとABC)は、MECEの関係にしてやりましょう。
これも後ほど具体例で解説します。
補足
- Aをさらに掘り下げる場合、Aに対してもう一度Why Soを考え、a-1,a-2,a-3を出します。答えをレベル1、ABCをレベル2とすると、a-1...はレベル3と呼ばれます(レベルは、難易度ではなく、階層を示すレベルです)
- ABCと記載していますが、要素は3つでなくてもいいです。
- 階層数に決まりはありません
論理パターン
基本の論理構造は上述の通りです。実際には、論理は二つのパターンに分けられます。
読者は「この基本構造で、本当にすべてのケースに対応できるのか？」と考えるかもしれない。答えはイエス。ただし、実際に論理構成する時には、２つの論理の基本パターンがあり、それを使い分けたり、組み合わせたりする。基本パターンは、「並列型」「解説型」の２つだ。
以下、一つずつ解説していきましょう。
並列型論理パターン
これは、先ほどの図の通りです。(図は本を元に作成)
やり方としては、課題が与えられて、MECEアプローチでABCを考え、結論を導き出す、といったところです。
例を書きましょう(課題・結論・考察要素は全て本を参照して作成。簡易化のため少しだけ言葉を簡易にかえています)。
MECEの4Cフレームワークを使って、４つの観点から不良品問題による影響を分析しています。その結果、記載の結論に至っています。
4Cで事態を多面的に考察していくあたり、The MECEて感じですね。
この例では難しいですが、他のフレームワークとして、4P(Product/Price/Place/Promotion)や、都市部/地方、質/量、事実/判断なども、有名なMECEフレームワークです。
解説型論理パターン
続いて、解説型。以下をご覧ください。(図は本を元に作成)
え、事実・判断基準・判断内容、これMECEなの？って僕も思ってましたが、上に記載したように、「事実/判断」はMECEアプローチになります。客観的事実とそれ以外、という排他的分け方ですね。判断基準も含めちゃうのは厳密なMECEかというとちょっと怪しいですが。
事実から判断を導く、という流れがあるので、この場合は矢印がついてフローっぽくなっています。
例をあげましょう(課題と、事実から判断に向けた考察の進め方部分は本と同じやり方を使っています)
プレゼン等のときにこの図を話すかどうかは別問題ですが、思考のプロセスの中でこういう構造を思い浮かべると、なかなかクールに考察できますね。
まとめ
超ざっくりですが、論理の型について説明しました。
個人的には、本でこの理論を知った時は目から鱗で面白かったです(特に解説型)。
より詳細に理解を深めたい方は以下の本をお勧めします。
【AWS入門】例題で実践学習！！
どうも、Keiです。
突然ですが、皆さんはAmazonを使っていますか？
使っていますよね？
毎日荷物が届いているって人もいると思います。
今日はそんなAmazonのサービスの中でも近年ありえないスピードで成長しているAmazon Web Service（AWS）について学習していきましょう。
AWSはご存知の方が多いかと思いますが、Amazonが提供しているクラウドサービスです。
2017年と比較した2018年の売上高は脅威の48%増だそうです。
また、少しデータは古いですがAWSで提供しているサービス数も毎年恐ろしい勢いで増加を続けています。
また、去年のガートナーのクラウドインフラストラクチャーの評価ではMicrosoftのAzureとGoogleのGCPを大きく離し、リーダーのポジションを獲得しています。
さて、このように快進撃を続けるAWSですが、皆さんの企業でも既に利用しているかと思います。
一方で、まだ利用していないという方も今後社内のITインフラをAWSに移行する機会があるかと思います。そんな時にAWSの知識は是非知っておいて損はない知識かと思います。
操作も、環境構成だけであればブラウザでポチポチ作るだけだし。
環境を作ってみよう！
今回は下のような基本的な環境を構築するときに、AWSでどう実現するかについて話をしたいと思います。
やはり、こういう技術的な話は本だけ読んでいても良くわからない部分があるので実際に手を動かしてみるのが非常に大事だと思います。
作成インフラ要件
今回は例題みたいな形で下のような環境を作ることを考えましょう。
細かい話はたくさんあるかと思いますが、まずはざっくりで！
【サーバ要件】
- EC2インスタンス x 3（Not dedicated）
- 各EC2インスタンスはAZ冗長
- 2台はWebサーバでELBで50:50にローバラ
- 残りの1台は基盤サーバとし、RDSとしてAmazon Auroraを配置
- EC2のストレージはEBS（ローバラ時IOPS 10,000未満を想定）
【ネットワーク要件】
- VPC[10.0.0.0/16]配下に/24の3つのサブネットを作成
- 3つのサブネットの内、2つをウェブサーバに使用し、インターネットからのアクセスOK
- 基盤サーバはプライベートネットワークとするが、バッチのDL等のために内側からのみインターネットにアクセスOKとする
【ストレージ】
- 各EBSのスナップショットを5分に1回S3ストレージで取得
【セキュリティ】
- S3へのEC2からのアクセスはIAMロールで行う
- ELBへの外部からのアクセスはHTTP/HTTPSのみとし、セキュリティグループにより実現する
AWSのサービスで実現すると
下記のような構成が考えられるかと思います。
簡単に各コンポーネントについて説明したいと思います。
EC2
皆さんもよくご存知の仮想サーバです。
今回は AZは3つ用意し、分散冗長させています。AMIやら細かい設定は今回は省略します。
EBS
EC2にアタッチできるブロックストレージ（従来からのHDDやSDDのようにディレクトリ構造のストレージ）はEBSとインスタンスストアがありますが、今回は不揮発性のEBSを使います。
基盤サーバのRDSとしてEC2にアタッチします。
ELB
ロードバランシングには各EC2をアタッチします。
S3バケット
オブジェクストレージとして、各EBSのスナップショット（バックアップ）を保存します。
各VPCやルートテーブルについても、ネットワーク要件に合わせて作成できているかと思います。
また、セキュリティグループやIAMユーザ/ロールについても図には起こしていませんが、適切に設定する必要があります。
次回はこれらの設定を含めてAWSのダッシュボード上でどのように入力していくかについて紹介したいと思います。
今回は、まずAWSのサービスを使ってどのように要件を具体化するかについて説明していきました。
それではまた！
データ分析を効率的に進めるためのプロセスとは～EDAを意識した分析～
どうもKoheiです。
最近のHUNTER×HUNTER、いつにもましてルールが多すぎて難しくないですか
さて、以前の記事で、データサイエンティストの仕事のプロセスについては下記のとおりになっていると書きました。
- 要件のヒアリング
- 必要なデータの収集
- 分析の準備
- データ分析
- 結果のアウトプット
今回はこのうち、4のデータ分析のプロセスについて、もう少し詳細に書きたいと思います。
過去の記事はこちらで
どんな分析をすべきか？
さて、分析してほしいデータを手に入れたあなた
まずは何をしましょうか？
そのままデータを読み込んでみようと思いましたが、データが大きすぎてすべては読み込めません。。。適当に数件ピックアップしてみてみます。
中には、数十以上のカラムで構成され、様々な数値や項目が入っています。
んーとりあえず、これを集計してみるか？
何をキーに集計してみようか…？データをもらった人にもう一度聞いてみるか…？
など、意外といろんな選択肢が出てきます。
「データを分析する」という言葉が示す範囲は非常に広いです。
こうした中、あらゆる問題を解決する
最強の方法！というものはなく、
具体的に分析する方法や手順はいくつかありますが、
自分が体験的にもこうした方がいいなぁ、と思ったものを紹介します。
データ分析のプロセス
このプロセスは下記の文献*1を基にしていています。
*1 "Doing Data Science", Cathy O'Neil and Rachel Schutt, 2013
分析する前のそのままのデータ（raw data）をまずデータ加工（Data processing）し分析するのに扱いやすいデータ（Clean Data）にします。
イメージはテキストでベタ書きされてるものをきちっと表形式に直すようなイメージです。
そこからそのまま可視化（visualization）して、レポートとしてすぐに利用するケースもあれば、合計、最大、平均値などさまざまな尺度からデータを探索的に調査し（Exploratory data anaylsis）、機械学習、統計モデル生成（machine learning/Algotichms）から予測や分類などを評価、AIとして利用するアウトプットも想定されます。
ここで注目すべきは探索的データ分析から再びデータ加工へ戻っているフローもあることです。データを探索的に繰り返し調査していくことで、データの本質を把握し、より効果的な統計モデルの生成などに繋げることができます。
さて、この「探索的データ分析」についてもう少し掘り下げたいと思います。
EDA(探索的データ分析)
探索的データ分析（よく先頭のキーワードをとってEDAと訳されます）は、1977年（！）にJohn W. Tukeyさんによって提唱されていた方法です。
簡単に言えば、「予想した仮説だけじゃなくて、データをいろんな側面で見てみようよ」っていう考え方です。
データが膨大な量になる今、全量を把握することはほぼ不可能で、データの担当者がなんとなくこうだろうと思っていても、実際データを見てみると別の意外な発見があった・・・なんてことも珍しくありません。
EDAを通じて、どんな変数が特徴を持つのか、外れ値や異常値の有無、適切なモデル・可視化方法の評価を進めます。EDAの具体的なアプローチは下記のとおりです。
1. 基本的な統計量の把握
- 平均、分散、最大値、最小値、中央値、四分位数などの算出
- 箱ひげ図などによる可視化
2. 単純データの可視化
- 各説明変数と目的変数の関係性の可視化
- 散布図、ヒストグラフなどでデータ全体の分布を把握
- 変数同士の相関関係の把握
- 外れ値、異常値の把握
3. 変数変換後のデータ可視化
- 主成分分析(PCA)などによる多次元データの次元削減。
- 対数変換、逆数などの変数の見せ方を変える
こうした方法を重ねて、データの本質を見抜いていきます。
EDAの際の注意点としては、EDAの時点ではまだ外れ値や欠損値が混在している可能性があるため、そうした外れ値に影響を受けにくい頑健な方法をとる必要があります。
平均値などは特に、一個のとびぬけた値に影響を受けやすいので扱いは気を付ける必要があります。
まとめ
さて、今回はデータ分析のプロセスについて書きました。
このEDAのアプローチは、データ分析コンテストのkaggleでもよく見られる方法です。
分析目的は様々ですが、実際にに上記のようなプロセスを意識して進めてみると効果的で効率的な分析が進められるケースが多々あると思いますので、ぜひ意識してみてはいかがでしょうか
ではでは
何故あなたのメッセージは響かないのか (ロジカルシンキング/ビジネスコミュニケーション)
新型Macbook Air、出るんですかね。僕は今だに2011年ぐらいに購入したMacを使ってるので、発売したら即ポチ予定です。
どうも、ITコンサルタントのShoheiです。
今日は、ビジネスにおけるメッセージについて書いていきましょう。
次回以降、このメッセージに説得力を持たせるためのロジカルシンキングについて解説していきます。
就活のグループディスカッションの思い出
ロジカルシンキングといえばですが、就活生の中に、グループディスカッションにはロジカルシンキングが必要だ、みたいな教えを受けた人もいると思います。
グループディスカッションは就活生時代僕も一度受けましたが、就活LOVEみたいなしょうもない学生と受けるのは、まぁヘドがでますね。
確かそのときのお題が「ストローの売上高を増やすにはどうしたらいいか」といったタイプだったのですが、以下のような状況になったと思います。
その後、「ストローとは、穴が空いている筒状のもので、液体などを吸うためのもの」みたいな感じで定義づけがされていきましたが、果たしてこのくだりは必要だったか、疑問を抱きました。
なんのためにやったんだろう
きっと奴らの中では就活の教科書か何かに「まず定義づけから始めよ」みたいなのが記載あってやったんだと思いますが、本来の目的は以下でしょうね。
課題を明確化し、前提条件を揃えること。
考えるべき課題に対してずれがあると、その後のディスカッションも思わぬ方向にいってしまいます。
さすがにストローの存在に対する認識のずれはないと思いますが、例えばお題が「みんなに好かれる番組を作りなさい」のようなものだと、以下のように認識がずれる可能性があるので、定義づけをする必要があります。
上記例だと、みんなと番組という言葉に認識ずれが起きてますよね。だからその曖昧な言葉をまず定義してやらないと、答えるべき課題が明確にならないのです。
課題については以下で解説していきますが、普通ビジネスでグループディスカッションの場を設ける上での課題は明確にされているべきものですが、就活だとあえて曖昧に出してきたりします。
それを曖昧のまま好き勝手進めるのではなく、一度立ち止まって、みんなの認識を合わせる能力をみられているんでしょうね。
ビジネスにおけるコミュニケーションについて考えて見ましょう
さて、グループディスカッションの思い出は置いておいて、ここからはもう少し広義に、ビジネスにおけるコミュニケーションについて考えていきましょう。
なおここで話す内容は、基本的に最後に紹介する書籍の内容から学んだことをベースにお話ししていきます。
メッセージとは何か
ビジネスにおけるメッセージ(報告など)は、以下の三要素からなります。
- 課題
- 相手に期待する反応
- 答え
一つずつ見ていきましょう。
課題
相手から課されている題目です。テーマです。
以下のようなものがあげられます。
- 当社は、●●の不良品発生に対してどのように対処すべきか。
- 当社は、IT運用をアウトソーシングすべきであるか。
- 当社は、ハードウェア分野のみならず、クラウド分野にも事業を展開すべきか。
- 当社は、富裕層をターゲットとしたダイエット事業をどのように進めていくべきか。
- 修学旅行の行き先はどこにすべきだろうか。
重要なのは決して「●●について」などといった何について考えるべきかが曖昧な表現になっていないこと。
相手に期待する反応
個人的に非常に重要だと思っているのは、この項目。
会議や文書、プレゼンのとき、伝える相手に以下のどの反応を期待するか。
- 相手に理解してもらう
- 相手に意見やフィードバックをもらう
- 相手に行動してもらう
- (相手に自分の入社適正を評価してもらう)
行動してもらうことが本来求めるべき反応なのに、理解をさせて終わり、では目的を果たせません。
答え
答えの三要素は以下です。
- 結論(課題に対する、伝えての答えの核となるもの)
- 根拠(どうしてその結論に至ったかという理由。事実と判断の2つがある)
- 方法 (結論がアクションの場合、具体的なやり方を提示するもの)
これらは当たり前の要素ですが、後述するように正しい答えを出せていない人も一定数います。
何故あなたのメッセージは伝わらないのか
さて本題。ビジネスにおけるメッセージとは、この三要素があって初めて成立します。
また、課題と期待する反応に、答えがマッチして初めて意味をなします。
以下のように答えが噛み合っていないのと、会話にすらなっていないのです。
上記の場合、自分の調査プロセスの中で課題がきっとすり替わってしまっていますね。アウトソーシングに関する市場調査に没頭する間に、市場調査に対する結果を出せ、が課題であるとすり替わってしまったのでしょう。
他にも、就活の面談など、自分の中であれこれ用意してきた場合、答えが噛み合わなくなるケースが多く見られます。以下例をみてみましょう。
就活生の面談やそのサポートを何人もしてきましたが、このケースがあまりにも多すぎる。いつも「面接官と会話しろ。まず一文で質問に答えろ」と指導してきましたが、言葉をかえると課題と答えをマッチさせろ、ということになります。
まとめ
今日はロジカルシンキングを考える前提部分である、メッセージについて整理しました。
次回以降、相手を説得するロジカルシンキングについて紹介していきます。(次回と言っていないのは、また思いつきで他のこと書くかもしれないので)。
それでは！
参考書籍紹介
【社会人必見】財務諸表で企業戦略を読み解く
どうも、Keiです。
肌寒かったり暑かったり微妙な気候が続きますね。
今日は最近読んで面白かった本について書きたいと思います。
みなさん、突然ですが「財務」についてどれだけご存知ですか？
ちなみに、ぼくはほとんど何も知りませんでした。
なんか会社に財務部とかあるけど、地味そうな部課だな～なんて思っていました。
しかし、
商学部の方や、簿記なんかの資格を持っている方は良くご存じだと思いますが、財務は会社の経営を語る上では必要不可欠なものです。
浅はかな認識だった自分が恥ずかしいです。
そんな僕の認識を変えてくれた本がこちらの
「儲かる会社」の財務諸表 48の実例で身につく経営力・会計力
です。
「儲かる会社」の財務諸表 48の実例で身につく経営力・会計力 (光文社新書)
- 作者: 山根節
- 出版社/メーカー: 光文社
- 発売日: 2015/09/16
- メディア: 新書
- この商品を含むブログ (5件) を見る
著者の山根節という方は、早稲田大学経済学部を卒業後、現在でいうデロイト・トーマツグループの1つである監査法人に入社しています。
その後、独立を経て現在は早稲田大学のビジネススクールの教授を務めているようです。
また、カーオブザイヤーの理事も務めるという非常に影響力の高い方です。
この人が著書の中で言っている、海図の読めない航海士がいないように、財務諸表が読めない経営者もナンセンスであるが個人的には気になって今回読んでみました。
財務諸表について
この本のキーワードは当たり前ですが財務諸表です。
ご存知かと思いますが、財務諸表は主に以下の2つを意味します。
CFSをカッコ書きしているのは、CFSはPLとBSから導き出される便利ツールみたいなもので、著者は基本の構成要素としては入れていないからです。
PLは、Profit & Loss Statementの略で、
最も簡略化して説明すると、「費用」、「売上」、「利益」の関係性を表したものです。
つまり、ある会社の「利益」が「売上」と「費用」からどれくらい出ているかという利益率がわかるわけです。
非常にシンプルな情報ですが、同業他社など同じような商材を扱う企業間でコスト構造がいかに洗練されているかが如実に出る部分です。
特に、Appleに代表される企業は利益率が規格外に高く、対して日本の企業はこの利益率が低い傾向があるようです。
次にBSはBalance Sheetの略で、
原資（資本と負債）と投資（資産）の関係を可視化したものです。
これは最もシンプルにカテゴライズしたもので、さらに細分化された記述されます。
例えば、資産は固定資産、流動資産に分けられ、それぞれさらに・・・という感じで。
面白いことに、このPLとBSが同じような商材を扱っている企業によって全く異なる場合があり、そこにそれぞれの企業の戦略が出るのです。
また、時系列にPL/BSを並べると企業の戦略の流れや戦略方針の違いが伺えます。
この著書では、PL/BSの説明を初歩から教えてくれると同時に
実際の企業、例えば日本一の経常利益を誇るトヨタのPL/BSの分析や同業他社でトヨとはまるで違う経営戦略をとってきたホンダとの比較など、実際のPL/BSを紹介しながら、説明があるので非常に理解が進みます。
著者が本の中で言っていることですが、
「〇〇時間でわかる財務」みたいな財務単語の理解には何の意味もなく、どれだけ多くのPL/BSを読んで、実際の企業の性質と比較することで財務諸表に企業の性質が出ているかを感じれるようになるかが大事、だそうです。
残念ながら、まだ僕はその域には到底達していないですが
クライアント向かいの方は、取引先の決算後にはPL/BSを必ず見て話しが通じるようになる必要があるな、と感じさせられた本でした。
気になる方は是非読んでみて下さい。
それでは、今日はこのへんで。
