ペース的には恐ろしいほどまったりとしています。

そんなまったりの自分が驚いたのは、今になって基礎の基礎というか初歩的な情報を手に入れたことです。

これまで少しずつ積み上げた結果なのか、間抜けなだけなのか。。。

その情報はプログラミングにおける処理の種類が大きく3つしかないということです。

その３つは、　順次、選択、繰返し　です。

・順次とは、アルゴリズムというようにパソコンに処理の順番を教えることです。この順次を的確に教えることで効率の良い作業をしてくれます。

・次に選択は処理の条件を教えることです。IF関数のように、この数値以上ならこの処理をするなどパソコンに選ばせます。

・最後は繰り返しで、処理を適応させるデータを網羅するまで一定の処理をさせるものになります。

この３つだけという知識が抜けていた私は学びながら、空中分解していました。本気で頭の中は宇宙散歩でした。笑

なんかよくわからんけど、高階関数って出てきた。気合でイメージ掴むしかないやん。。みたいな感じで。

ですが、この知識を入れた今ならこの高階関数も特に選択と繰返しの応用なんだなと分かるようになります。

宇宙ではなく、地面ができた気がしました！

皆さんもぜひ参考にしていただければなと。知識の入れる順番の大事さを改めて痛感しました。

*余談

誰の講義か忘れましたが、有名な大学の教授の講義でバケツにものを入れる順番を説く講義を知っているでしょうか。

大学の教授が大きな石をバケツに入れて、生徒に「このバケツは満タンか？」と問います。

そこから、小さな石、砂、水を入れてバケツを本当の意味で満タンにしていくのですが、

最後に教授が　「何が言いたいか分かるか」と問います。

皆さんは何だと思いますか。

生徒は答えます。「どんなにしんどくて限界が来た時でも、細部を見ればまだ頑張れる余地があるということです」と。

教授は答えます。「そうじゃない。この大きな石は君たちの最も重要にするものだと。人生という大きなバケツの中で君たちが本当に成し遂げたいものを先に入れないと君たちの人生に入るものの余地はなくなる」と。

この話では、人生の生き方を語っていますが、知識も相だと思います。大きな枠組みの中から基礎的な部分を学ばないと、逆に通り道をしてしまう。専門性が高く、難しいものを勉強しているとあたかも賢くなっている気になる。しかし、急がば回れのように地道な積み重ねが大事なのではないでしょうか。

そんなことを思ったプログラミング世界の宇宙旅行をしていたものの意見です。笑

顧客との商談を支配と聞いて、みなさんはどう思うだろうか。

ここで間違えるのは、営業マンが支配と言えば、攻撃的な口調になることだろう。

支配すると聞いたときに、威圧することを当てはめてしまう。

では、ここで言う支配とは何だろうか。

それは顧客の利益を求めたうえで自己主張をすることである。

自己主張に当てはまるのは、こちらの製品について、話すのは結構ですが、もちろんそちらは上司など意思決定できる方との商談を用意できますよね？といったものだ。

ここで威圧というほどの言葉遣いはしていない。しかし、こちらの立場からしてほしいことを述べている。

これが自己主張である。

この自己主張をしないとどういった危険性があるのか。

顧客からすれば、営業マンの話を聞くのも仕事のうちであり、他の企業との案件で決めるつもりでも他社のサービスについても聞いてみたいと思うのが普通だ。その考えを意図せず、営業していて話をよく聞いてもらえるから受注できると思っても商談が進まないという事態が起こりうる。

また、自己主張ができない営業マンが陥るのは商談を先に進められないことだ。自己主張ができないため、顧客の言いなりになる営業マンはお金の話などの立場が厳しくなる話を展開できない。

これらの事柄が挙げられる。

営業を支配するためにも、自己主張ができる状況を作り上げることが重要である。

営業で相手と商談するときに、十分な顧客のインサイトを知ったうえでプッシュする部分は相手が予期していない、重要と考えていなかった部分が最も良い。

理由としては大きく二つだろう。

一つは意外性を持たせることができる。

二つ目は主導権を握れるということだ。

意外性においては、相手が予期しなかった内容のため、相手に考えさせることができる。また、その内容に妥当性を見出せたなら相手にとっては、思ってもいない喜びになって帰ってくるだろう。つまり、得した気分になる。

そういった意味で意外性を持たせることは重要だ。

主導権を握るということは相手の歩調に合わすことができるというわけだ。営業で最も大事なニーズや課題を育てる部分を顧客より用意した状況で行うことができる。これによって、顧客との商談を円滑かつ深く考えることができる。営業では、顧客が主役なのだから押し売りするわけではなく、寄り添うつもりで話すのがいいだろう。

このような意味で主導権を握ることは重要だ。

関数を引数として受け取る関数のことを言います。

定義した関数を関数のまま他の関数に使えるものです。

なので、高階関数を作ってしまえば、あとは臨機応変に使いまわせばいいだけらしいのですが、

正直わかんない。笑

なので、掴んだ情報を箇条書きでも書いていきます。

高階関数にはいくつもの種類がある。

引数を何個持つかも種類によって違う。

空リストに対する対応も種類に応じて変わる。

ただ、空リストでなかった場合、再起呼び出しをし、その結果と先頭の要素で操作を行うという面では他と一緒

fold_right、sum、init

fold_rightはカラリストをinitに置き換え、：：をｆで置き換えるともいえるらしい。

補助関数は他のプログラムにまで使えるようにするのは好ましくない。

let　関数名　引数　・・・　=　式　in　式　これでinの後に続く関数を式の中でのみ使えるものとした。

これを局所的かんすうと呼ぶ。

名前の内かんすうを作るにはfunを用いる。

fold_rightは関数を2つと初期値を受け取ることができる。

再帰や補助関数なく簡潔に書ける

INFIX関数＝演算子を最初に持ってくる、PREFIX関数＝最初に関数を置くもの

初めて学ぶと自分の立ち位置が分からないために内容も進行状況も分かりません。

私が学んだのは以下の項目です。

・変数

・関数

・構造データ

・リスト

・再起関数

これらの内容を使えば、かなりのプログラムを作るようになるらしいのですが、

その点についても私は全く分かりません。

嘘つけやって思っております。

ただ、このまま続ければ、相当な力がついているはず。。

このまま継続していきます！

それは階乗。。。

皆さんお覚えでしょうか。高校の時にやったはずです。Σや　ｎ　を使って学んだそれです。

関数を使うんだから後々に出るってわかる話ですけど、忘れてました。

ちょっと苦戦しますよね。えー、4年ぶりとかに出会う階乗は驚きますよ。

これがテストとして答えよって出るので大変です。

でも、がんばります。7回も読めば、頭に入ると願って。。。

セールスにおいて、最も成績を収めるタイプの人種がいるって言ったら聞きたくないですか？

それがチャレンジャーセールスモデルというものです。書籍で出ています。

チャレンジャーセールスとは大型営業で顧客に対して、能動的に意見してしまうようなやばいやつなんすよ。「この製品でこれだけの改革をしましょう！」てきなね。

ただ、顧客の目線から見たらそれだけの知識量と意見を言える営業マンの話を聞かないわけにもいかない。その営業マンの知識が本物の場合に限り。笑　本物ちゃうかったら詐欺ですから。

顧客としてはアドバイスや知識をもらいたい。この営業マンと接してたらそれだけの価値をもらえると思ったらそりゃ一緒にいるでしょ。

このチャレンジャーセールスモデルは他の営業スキルよりできるようになるには時間がかかります。そりゃそうですやん。それだけの知識を得なあかんのやから。

でも、それだけの知識が得られた時、あなたは唯一無二の営業マンに慣れるというわけですねん！

私がプログラミングの勉強を始めて最初に思ったことだ。（今も学び中）

実際にプログラミングの内容など理解できんわーい！

心から叫ぶ毎日や。なんやこいつ、よくわからんってなる。

そんな中でも分かったこと？感じたことを書いていきまんねん。

プログラミングとは関数の使い方を駆使すること！

プログラミングで使うリストやデータなどのものがある。あるはず・・・（その段階から笑）

その中でも関数というプログラミングを使うための型がある。言うなら、数学の式よね。

この式の組み方を自分で考えなあかん。これが難しい。プログラミングは数をこなすことで覚えられるもので、（おぼえなくてもええねんけど）教科書から学んだらテストをさせられる。

そこで考えるテストがむずい

そんなこんなで手につかなくなる。

また問題なんが言語がよくわからん。頭にしっくり入ってこん文字ばかりで、イメージがわきずらい。そんなこんなで苦労しながらプログラミングも学んでいきまする。

・答え

・示唆

・仮説　　である。

その中でも仮説についてだが、いきなり仮説を説く人がいるが、それは仮設ではない。

仮説とは論点の中にあるもので、論議していない話題でいきなり「～はこうだ」と言っても論点がずれている時点で仮説ではない。

また、仮説は仮の答えであり、なんでもいいわけではない。ほぼ勘と言ってもいいが、それには生きてきた知恵、経験からくるものであるため根拠は存在する。

しかし、仮説は答えではない。勘や経験から基づくものは根拠になりうるが、相手に真意が伝わるものではない。そのため目に見える事実が必要なのだ。

では、なぜ仮説が必要なのか。それは検討の効率を上げるためだ。

仮説を用いることである程度答えを絞り込むことができる。この絞りが無ければ、条件に合うすべてのものを選ばなくてはならない。

検索で条件を多くし、比較を少なくした方が圧倒的に効率がいい。

仮説の役目とはこのようなものである。

仮説とは相手に苦労をしいることなく提案できるツールなのだ。

また、仮説のプロセスで「仮説を出すための段階」と「仮説を検証する段階」でも区別が必要だ。その時になって必要なデータが違うからである。

仮説を作るための具体的なステップは

１，論点をしっかり押さえる

２，つねに何かを問い続ける

３，多くの情報を揃える

先ほどから言うように論点なきところに仮説はない。また、WHATやHOWのようなオープンクエスチョンで間口を開いて考えるのが好ましい。情報量の多さでストック情報を持っておくことも大切だ。

このような観点から精度の高い仮説を出すことが大切だ。

参考文献：高田貴久　ロジカルプレゼンテーション（２００４，２）

では、この論点の違いはどこからきてるのか。どこに原因があるのか。どのような対策を講じるべきなのか。ここでは考えていきたい。

論点がずれる原因には４つあります。

・議論をする立場が違う

・相手の意図が理解できていない時

・具体的な判断を下せない時

・相手が分かっていることを論点にしている時

＜議論をする立場が違うとき＞<相手の意図が理解できていない時>
 

これら二つによって、論点がずれる場合、相手の意図を汲み取れないからです。

議論をする立場とはおおよそ二つあります。

意思決定をしてほしいときと単に壁役になってほしいときです。

この判断を間違えると話はかみ合いません。なぜなら、壁役になってほしい人に意見や結論を言ったところで求めていないものであるため、話が止まってしまいます。愚痴や昨日あった話はこうしたらよかったなどの意見を求めていない。ただ、聞いてほしいだけなのです。逆に意思決定や提案をしてほしいときに聞くだけの姿勢を取ると、あなたの意見を聞いているんだけどとなり、話が止まってしまいます。

このように相手が求める立場を汲み取り、それから議論を展開すべきです。

壁役の場合、議論というものではありませんが。笑

意図を汲み取るのも述べたものと同じだ。しかし、特に注意するのが話をしっかり聞くことだ。話を聞くことが提案の第一歩である。そのため聞くことを疎かにして、自分の意見だけを通そうとする人は議論とならず独りよがりのワンマンショーになってしまいます。また、相手に自分の意思を通すのも大事ですよね。なので話の結論を抽象的な言葉ではなく、具体的な行動や対策に落とし込んだ言葉にするとよいでしょう。

<具体的な判断を下せない>
相手に具体的な判断を下さない、下されないのはMECE的な横の展開が不足しているからです。横の展開とは回答のパターンの把握です。「それだけなの」と言わせないために横の展開があったわけですね。つまり、出しうる回答の不足が相手の意思判断を妨げているのです。この意思決定を促すためには「それだけなの」と言わせないだけの横の展開をする必要があります。横の展開が必要ということは、その議論になるステージに行くまでの縦の展開も必要となることになり、それだけのロジカルシンキングが必要となります。

営業で言うならば、なぜこの商品が必要なのか。クライアントの課題を明確に示し、課題の中でも営業で改善しうるものを提示しなくてはなりません。そして、なぜ弊社なのかを競合他社との比較を行いながら、目に見える資料と共に説明しなくてはいけないかもしれません。そして、この商品から得るアドバンテージについても説明し、その理由を納得してもらわなくてはなりません。このように、相手に具体的な判断を下させるポイントを抑える必要があります。この判断の材料と議論のポイントを明確にしなければ、議論が空中分解し、最初から説明しなおすか、商談自体を取り止められるかもしれません。

＜相手が分かっていることを論点にしている時＞

相手が分かっていることを論点にすると話が止まるときがあります。話の前提が違うと論点がずれるのは分かると思います。例で言うと、自分が競合他社を分析する立場にあるとします。しかし、提案する相手の頭に競合他社の図式が入っている状態では、自分の提案する話は当たり前のことで知っているよで済まされます。この相手の考えや知識を読み間違えると話の論点がずれます。この提案も話のずれから無駄な議論となる可能性もあるのです。

以上、４つの議論のずれ方についてお話ししました。皆さんもぜひ気を付けてください。