以前は次のようにやっていたようですが、いつの間にかかわったようです。

Mac OS X で DNS のキャッシュをクリアする。

lookupdはすでに存在しません。そのかわりdscacheutilが使われるようになっています。
これはmac上の様々なキャッシュを統一的に扱うようにしているようです。

次のようにするとdnsキャッシュの中身が見れます。

dscacheutil -cachedump -entries host

で、クリアするときはこんな感じ

dscacheutil -flushcache

なるほどなるほど。

大企業向けの情報管理ソリューションについてたまたま考える機会があったのでちょっと思ったことをば。
じつはクローズアップ現代自体は見るの忘れてた。誰か録画あったら頂戴。 

NHKクローズアップ現代「新情報革命“クラウド”の衝撃」を見て

番組中でもあったかもしれないですが、個人的に思うポイントは

• 巨大なコンピュータリソースが比較的安価に手に入る（インフラ）
• クラウドコンピューティングなどによるSaaSやPaaSは囲い込み力が強い（サービス）

の2点でしょうか。ほかにも瑣末なことがたくさんあったんですがあんまし肝心ではなかったので忘れました。しかし、主にはインフラ面とサービス面の２つから切ることができるでしょう。

巨大なコンピュータリソースが比較的安価に手に入る（インフラ）

本当に安いのかというと実はそうでもないです。たぶんフル稼働したとしたら専用サーバのほうが安いんでないかな。
どちらかというと、「使った分払う」形になったと表現するほうがいいかもしれません。Amazon EC2などは使った時間とスペックで課金されるのでわかりやすいですね。 
あれもひとつの金額設定のきり方であって、ほかにもいろんな切り口が考えられそうです。

ほとんどの人にはコンピュータリソースを恒常的に確保するニーズはないわけです。一日数時間集中的に計算できればいいとかそういう人ばかりでしょう。
一般的なユーザから見るとアイドル時間の無駄なコストを持たなくてよくなった分安くなったと感じられるということです。

これによる効用ですが、グーグルが何年も前から言っているこの問いに収束する気がします。

「さてここにＰＣ2000台分の計算資源があります。この資源を生かした何かをしてください」

実はこの問いに答えられる人は、それほど多くはないようです。しかし、これだけのリソースをわれわれ一般人が使えるようになった今、必要な発想はまさにここです。
例えば毎日ブログの記事を解析するサービスを考えて見ましょう。解析には残念ながら3日かかります。これだと毎日リリースすることができないためサービスが成り立ちません。
しかしクラウドからコンピューティングリソースを借りることで72時間かかっていた解析が24時間で終わる・・！
こうすると従来不可能だった分析・解析を提供するサービスができるようになるわけです。

他にもたくさんのケースが考えられます。従来経済の分析をすることは計算資源の面を見てもなかなか難しかったように思います。 
少なくともいろいろ数値を入れて、「分析！」ってはじめた瞬間から結果が出てくるのが一時間後だったとしましょう。
これが例えば2秒まで縮まったらどうでしょうか？ 
従来計算資源の問題でぜんぜん直感的でなかった分析が、直感的にできるようになるとは考えられないでしょうか？

むかしアシスタントを何人も並べて数値の計算をしていたという話を、この間野村や大和総研の方からうかがう機会があったのですが、それがいまやＰＣのエクセル上でできるようになっているわけです。
その時間の短縮具合といったら・・・・・それと同じことが今もう一度おきるかもしれないわけです。

クラウドコンピューティングなどによるSaaSやPaaSは囲い込み力が強い（サービス） 

どうやら、salesforceなどの話が出ていたようですが、これはインフラのクラウドとは分けて考えるべきでしょう。最近のsalesforceはよく知らないのですが、すくなくとも一年半くらい前に見た限りではそれほど強固なインフラが必要な感じはしませんでした。（もちろんインフラとしてクラウドかするメリットはあるんでしょうが、直接salesforceのサービスには影響しないでしょう）

サービス面でのクラウドを考えるときに欠かせないのは、その「囲い込み力」です。

たとえばMS Officeのことを考えてみてください。どうしてMS Officeを使っているんですか？情報システム化の概念から考えると大体こんな理由かと思います。

• ファイル形式や機能で同一のものが使えないと仕事がしにくい
• 操作方法などソフトウェアに関するノウハウやコツの共有のため（システム更新すると教育コストがかかる
• 過去の資産があるため

他にもたくさんありそうですが。これがクラウドになるとどうなるかについて考えてみましょう。

まずクラウドになるとファイルという概念がなくなります。もちろん帳票処理などのためにＣＳＶやエクセルという形でダウンロード可能でしょうが、一括でのバックアップ機能として使いやすいかというとそれはまた別問題です。

またデータとしての実態が希薄になっていくことが考えられます。 
どれが入力したデータで、どれが加工したデータなのかは使えば使うほどわからなくなってきます。すると、どれをバックアップするべきなのかがわからなくなってきます。
最終的には、将来的にシステムを移行しようとしたときに、こうしたデータの互換性が障害になる可能性も考えられます。ここが囲い込み力。

つぎに操作方法に関するやノウハウ・コツによるもの。どこぞの金融系会社は新人に死ぬほどエクセルのショートカットキーを教えるようですが、システムが変わるとこれが無駄になります。
これはクラウド化とか関係ないのですが、いま世の中の風潮として情報システムをクラウドに入れ替えようという風潮があるのは事実なので、この点は乗り越えそうです。
しかし、将来再び情報システムを乗り換えることを考えたときにこれが、再びネックになります。
そのときに情報システムを入れ替えようとするなら、クラウド以上に便利な機能を提供しなくてはなりません。
また先ほど話題にした、互換性の問題も手伝って、より囲い込まれることが予想されます。

また、データが大量になってくると当然過去の資産の問題が出てきます。
今までであれば、ソフトが変わってもエクセルが読めればいい、例えば、オープンオフィス使ってもエクセルが読めればいいという感じだったわけですが、クラウド化した瞬間データそのものがプラットフォームに帰属するようになります。
例えばsalesforceで使っていたデータを他のサービス、例えばbeyond_salesforceに移行することを考えて見ましょう。
もちろんsalesforceはデータのダウンロード機能や移行方法を提供すると予想されますが、書き出したデータがそのままbeyond_salesforceに読み込めるかどうかは疑問です。

サービスのクラウド化は、従来の方法論（アプリケーション）だけ依存していた状態から、データそのものを依存するようになる可能性を秘めています。
こういったいみで、囲い込み力が従来の製品に比べて高くなる可能性を持っています。

サービスのクラウド化の鍵は標準化

そういった意味ではデータの標準化が鍵を持っているように思います。世の中はなんでも標準化する時代ではありますが、それでも独自拡張がなされ「われこそが標準」というのが常であり今までの歴史でもあります。

いまさら出はありますが、VHSにしてもBetaにしても、ＭＳOfficeにしても、データ形式としてなにが標準なのかという点は常に重要です。
それが、クラウド化してファイルというデータのエンティティが希薄になったときどういう表現が標準になるかというのは重要であるように感じます。

まとめ

まとめるとクラウドはビジネスチャンスです。羊が退去して移動していて、その移動先にどれだけ大きな囲いを先に立てられるかという戦いといっていい気がします。

ビジネス的には結局よく考えてみると従来からよくある話なので面白みはないですが、インフラ面だけ考えればあたらしいサービスを提供する可能性があるので作る人にとっては楽しい話だと思います。

「計画力」を強くする (ブルーバックス 1552)

あなたの計画はなぜ挫折するのか？

計画を立てることの意義からはじまり、なぜ計画が失敗するのか、どうやって計画を実行したらいいのか、マネジメントに求められる能力とは、どうやって実行するべきなのか、そういうことが載っている本です。

個人的に面白いと感じたところは、日本人は目の前の問題に対処するのに対して、欧米人は目的思考で終わりや目的を決めてから行動をするという差から、日本人が計画を立てるのが苦手らしいことを言っているところです。
なるほど。自分のみを振り返ってもそういうことを思います。

日本人の「とりあえず○○する」という発想。大学受験、就職活動を通して何度も聞いてきました。
コンピュータに詳しくなりたいから「とりあえず」プログラムを書いてみる。「とりあえず」パソコンを組み立ててみる。目の前の問題をクリアするためにたくさんの「とりあえず」をやっていたりしませんか？
それは悪いことではないかもしれません。しかし、その「とりあえず」が終わった後はどうなるのでしょうか？あまりにも近視眼的になっていないでしょうか？
自分はどういう人間になりたいのか？どういう仕事をしたいのか？そういうビッグピクチャーが欠けやすいのは確かにありそうな気がします。

もちろん目標に変更はあるでしょう。しかし、当面の目標があるからこそそこへの近道について考えられるわけです。
むだな「とりあえず」をやらなくてもすむようになります。余った時間をまた新しい計画や趣味に使ってもいいでしょう。
逆にリソースがなさ過ぎることに早めに気づくことで、危うく失敗するところだったことに気づけるかもしれません。

この本は具体的な手法についてはあまり触れず、こういった計画することの有益性についてよく述べてあります。
いつも「○○がしたいのに・・！」と思ってる方は買ってみてはいかがでしょう？

理科離れについて

理科離れなんだろうか？ということをよく考える。自分は大学に行きながら実は「学生の勉強離れ」を感じることが時々ある。「数学とか理科ができて何の意味があるの？」というタイプの人間は、実は文系理系関係なく存在して、どっちにしても勉強していないのであって理科離れが深刻化しているわけではないように思う。

さらに、「数学と理科ができて何の意味があるの？」は、即そのまま「歴史や心理がわかってなんになるの？」につながる。一見社会に役立ちそうな法学部や経済学部であってもあまり生活に役立つようには思えない。判例をたくさん知っていたところでなんになるというのだろうか？
実は理科離れの「なんの役に立つの？」という問題ではないのである。それどころではない。理系文系関係なく「勉強して何の意味があるの？」というレベルにすでに達しているのではないかと思う。

少なくとも自分の経験している範囲について思うことをいえば、高校・大学は実際に役立つことなんかひとつも教えていない。抽象的な議論だけを教えて、いいとこ見れたとしても研究の世界までである。それが現実にどう応用されているかまで教えてくれることはレアである。
現実への応用は個々人のイマジネーションに任せているわけである。
もちろん、工学部であれば卒業論文を書くにあたって、それがどういうふうに社会的意義があるのかという点を書かされるので全くそこに対する想像力がないわけでもないが、逆に言うとそこまで全くそんなことを考えるチャンスはない。

言い方が悪かった気がするので、言い直すと「実際に役立つようには教えていない」

そのくらい脳みそ使えよとか思わないことはないけども、インストールされていないソフトは使えないのである。誰かがインストールしなくてはいけない。
自分がこんなこと思うのも、割と偶然ＩＴ関連で仕事をしているなかで、ちょっとした数学や統計的手法が使えた体験があるので思うのであって、ほとんどの人はそんなことには気づかないのではないだろうか？
少なくとも実際の応用までたどり着いてるのはオタクと思われてる人たちしか知らない。これは非常にハードルが高い。

個人的には、こうして根本的に勉強離れが起きていて、それが理系だと「理科離れ」、文系だと「後継者不足？」とかになっているんではないだろうかと思うことがある。

ちょっと角度を変えて考えてみよう。

理系は果たして儲からないのだろうか？こっからはどっかの教授から聞いた話であるので、真贋のほどはよくわからないが。

実は証券うったりかったりして儲けている人にはものすごく偏りがあり、平均ではなく中央値をとると技術職のほうが実は給料が高い。 
しっかり勉強していればという前提はつくかもしれないが、じつは積み上げられたものが全否定される可能性は技術職のほうが小さい。
最近人気だった外資コンサルにしても、ＭＢＡなしではそれほどたいした話ではない。
ここで「お金じゃなくて経験なんだ」という話が出てきたりするが、そんなの技術職でも同じことが言える。国際学会いって発表して交流するのと、外資コンサルいって大企業の偉い人と交渉するのはベクトルの方向の差こそあれ、長さに差があるようには思えない。
こう考えると金銭的面をとってもそれほど理系職が不利であるようにも思えない。 

これは聞いた話なので実はよくわからんのだけど、これが本当だとするなら実際の差はそれほどない気がする。むしろ文系職は今まで積み上げてきたものを全部捨てて一から覚えなおしたりするわけである。よほどそっちのほうが大変じゃなかろうか？それともいままで何も積み上げてこなかったということなのか？

しかし、理系離れというのは事実として起こっているらしい。ひとつには理系のオタクなイメージがありそうではある。けど実際は勉強するという行為自体がなくなってきてるんじゃないかなと感じる。逆に言ってみるとオタクじゃないと勉強とかやってられん状態なのではないだろうか？

結局結論はよくわからんのだけど、個人的に思うのは「勉強なんてくだらない」という風に思ってる人がたくさんいるのではないかというところである。これは理系離れという枠を超えて深刻なのではないだろうか？

しかし、実際は「勉強なんかどうでもいいや」なんてことないんだけど、まぁそれはまた別の話。参考にこれくっつけておこうかな・・・・

知っておきたかったこと　Paul Graham, January 2005

「すぐやる！」技術

自分に足りない要素は多々あれど、そのうちのひとつが「すぐやる技術」である気がしていたので買ってみた。

たいがいやりたいことやってるつもりではあるんだけども、それでもチャンスを逃したと思うことは多いし、他人を見てて「あぁとりあえずやってみりゃよかったのかぁ」とか思うことが少なくはない。

特に感銘を受けたのは、一章「相手の懐に飛び込む」だろうか。
自分は割りと今まで周りがちやほやしてくれることが多く、ほっといても人が寄ってくるし、なんだかんだ仕事もふってきたりするし、なんとなく有名人がゴロゴロっと周りにいたりもするし、色んなイベントなども紹介してもらえたりとかしていた。
なんというか、受身で結構何事も何とか回ってしまう不思議空間が出来上がっていた。
むしろ、「自分から働きかけるのなんてかっこ悪い」とさえ思っている節すらあった。けどそれは単純に「こっちから話しかけて無視されたらどうしよう」という恐怖の裏返しでもあったのかなと思う。「こんなこといってdisられたらどうしようとか。」
けど、それでも周りは「自主的にやってる」と評価していてくれたので、そう思ってはいたんだよね。

しかし、事実はそうでもなかったわけです。
なんだかんだで一生懸命仕事やったり勉強したりしていたわけですが、それもやりつくすとこうなりました。「こっからどうしようかね・・・？」

何はともあれ、起業っぽいことをしてみたくて仕事としてのＩＴを覚え、仕様書書きからテストの仕方まで荒くではあるけど勉強し、なんやかんや仕事をし、プログラミングもある程度はできるようになり、けどじゃぁこっからどうしようか？
急に選択肢が出てしまったときに「ウッ・・・」と立ち止まってしまったわけですね。
ここ長いのではしょりますが、要は自分から何かを働きかけていたわけではないという結論になったわけです。

ポイントは、用意された組織の中で誰かに誘われるままいき、そこで自己満足したり威張り散らすのは簡単なわけです。物凄く。 
そうではなくて組織の外に、まったく知らない人にどうアプローチしていくか。重要なのは結局ここであり、それは自分自身のモチベーションに基づいていることが重要です。 

そんなことをここ１，２年思いながら生きてるわけですが、そのための入門本としてはお勧めです。
分量があまりないのですぐ読めるし、馬鹿みたいに簡単なことしかことしか書いてないのですっと理解することができる。
筆者の体験も絡めて書いてあるので勇気ある第一歩を踏み出すためにはいいかもしれません。

なにかひとついい具合に回ると、ついつい安定志向に走ってしまいがちな人にはいいと思います。

某女史からリンク申請が来て「おー、そういえばmixiやってたんだっけかな」とか思い出したので、復活してみた。

何でやめたのかというと、しばらくネットからは引きこもろうという趣旨で半年～一年くらいはtwitterのみでやってたんですが、mixiでないにしてもfacebookとかlinkedinとかからバラバラとリンク申請来るのを見て「あぁやっぱしSNSっていいコミュニケーション手段になってんだなぁ」と感じました。

あんまみない気もしますが、近況報告見たいのは書きます。

たぶん本名で探すと出てくるので、思い出した人はリンク申請をば。

初心者がどうやってプログラミング言語を学ぶべきか。というのが、話題になっている。一方で最近はＡＰＩなどを駆使した軽量のwebを個人で作ることがブームになりつつある。
これを見て思ったのは、「じつは初心者がプログラミングを学ぶのは、こういうものをつくったりまねたりすればいいんじゃないかな？」ということである。 

ここ数年ＬＬ（Lightwieght Language）というものがはやっている。たとえばperlやruby, phpなどのスクリプト言語を指して用いられることが多く、修正などが容易な言語を指して用いられる言語である。 ここから文字って、Lightweight Software/Serviceという考え方を持ってみるのはどうだろうと考えた。

考え方としてはこうだ。

エンタープライズ向けに提供することは無理。ユーザからお金をもらうことも・・・・ちょっと難しいかも。けど、プログラミングを勉強する一環として、めんどくさい部分は全部ＡＰＩまかせにし、自分の考えを実現する。

よくよく考えてみると、自分がプログラミングを学んだひとつの方法として、他人のプログラムを見てコピペしたりまねをするというのがあった。
「これが作りたい！」と思うと、オープンソースのソフトを持ってきたりしてまねをするわけである。車輪の再発明がかっこ悪いという批判はあるものの、現代はソフトウェアの歴史なんてしらないし、世の中にあるソフトウェアを網羅的に把握してたりする人のほうが少ない時代である。

批判する人も出てくるだろうが、今回のえがちゃん騒動を見てて思ったのは、批判しない人のほうが多いしそっちのほうが一般的であるという事実である。
あれがすごいことなのかといわれると、ソフトウェア的な価値はほとんど０である。ただそれは、売り物にはならないとかいうレベルの話であって、いちいち趣味に対してセキュリティホールがどうのこうの言うのは、親切心でないとしたら、余計なお世話だろう。（俺は個人的にあの人は嫌いだが）

実はこのLightweight Software/Serveceと呼べるようなものは割と簡単にまねすることができる。ほとんどのものはＡＰＩたたいて、単純な四則演算してるだけだからである。
また、たいていの場合は、いろんなところを右クリックしてＵＲＬを調べたり、htmlのソースを見てみたりするとプログラムそのものが見れてしまう。
先にあげたamachangのものであれば、親切に画面の一番下に利用しているＡＰＩが書いてある。もうこれで材料はそろった。あとは、試行錯誤して何とか真似をすればいい。（と、言ってるほど楽でもないんだろうが）

ひとつ思うのは、プログラミング初学者のためにLightweight Software/Serviceのソースを公開してみてはどうだろうかということ。 
おそらくソースコード自体も高々数百行程度だろう。読むのもそれほど苦ではない。
最近ではgit hubやcodereposというような、自分のソースコードを公開するための仕組みも提供されている。
利用にはgitなどの利用方法がわかっていないといけないが、自分でwebで公開する手間に比べたら幾分らくだと思う。 

こういったものをプログラミング初学者のために、また自分が学ぶためにやってみるというのはどうだろうか？

この本は、ペン入力コンピュータに関するスタートアップＧＯ社の企業から潰れるまでの物語を書いた本です。

今のコンピュータ業界の有名どころのマイクロソフト・アップル・ＩＢＭとの競争、ペンコンピューティングに沸いていた当時の様子など、今のＰＣ業界にもつながる舞台裏での戦いが物語風に書かれています。

物語は、ＧＯ創業者であり著者であるジェリー・カプランの視点からかかれています。リアルな投資家とのやり取り、嫌がらせとしか思えない他社の類似商品の開発など、かなり楽しめます。

起業とか興味ない人にもお勧め。

技術者だからといって、モノが作れればいいんだろうか？そういうものでもないでしょう。

一つの考え方として、技術者は自分のたち位置や技術の位置づけについて、文脈に照らして考える能力が必要だということを言ってみようかと思います。

今回のえがちゃん騒動に思うこと：微妙に世間のことがわかっていない

別に世間知らずだとかいう訳ではないです。
単純にいうと、車輪の再発見のオンパレードをしているという話。しかもかなり劣化版の車輪。
けど、これはえがちゃんに限った話ではなく、このブログもそうだとは思うし、よのなかの多くのブログはそうでしょう。

たとえば、「情報商材はすばらしいビジネスモデルだ！」というエントリー。自分からみるともう何年も前からいわれてることで、それこそ起業しようとか少しでも考えたことある人や、実際に受託開発とかやってるひとなら簡単に思いいたるところです。
例えば自分なら、「で、それから？」と思う訳ですが、そこがない。

他にも例があります。iPhoneでブロック崩しのようなゲームをアルバイトで作ってた人がいたのですが、私が「それだったらこんなゲームがあるけど？」と言って教えてあげたことがありました。
私が教えたゲームはべつに特別探したりしたわけではなく、人気のアプリにランクインしているようなものでした。
ここでのポイントは、車輪の再発がだめだというわけではなく、「その人が自分のアイディアを思いついたとき全く下調べをしていなかった」というところに個人的に問題を感じています。

周りをよく見る癖を付けると、叩かれにくくなる

がんばって調べたりする必要はないと思いますが、常日頃から友達にアイディアを話したり、面白いニュースがあったらなんとなく交換したり。
そういうのが重要であると思います。

よく「アイディアをパクられたくない」という人がいますが、さわりだけ話してパクられるようなアイディアは、結局リリース後すぐにパクられますし、たいていの場合その程度のアイディアは誰かが考えています。
どうしても心配なら信用できる何人かには相談するくらいのことをするのがおすすめです。

こうやってよく周りを見回しておくと、「それ○○のパクリじゃん」と不意打ちされることもなくなりますし、作る前にそういうのが見つかれば、もっと違うアイディアに時間を割いたり、よりおもしろいアイディアにブラッシュアップできると考えることはできないでしょうか？

別に特別な作業をする必要はありません。なんか酒でも飲みながらアイディアを総disしてもらえばいいだけです。

切り口を買えることも重要

切り口、いいかえれば、文脈を入れ替えて考えるのも結構有効だと思います。
エンジニアの人は普通にやってるのに、なんでビジネスの人はやらないんだろうか・・・？エンジニアリングとビジネスの文脈がかわるだけで全く違う者が見えてきます。

無難な例がないのであれですが、例えば最近はやってるビジネス書をたくさん書いている勝間和代さんとかの本はいい例かも知れません。
なんだかんだ言っても、ネット通ばかりがつかっているgoogle。それをつかってビジネスを効率化する方法を本で書いたりしていますよね。
これもビジネスという領域で、自分の周囲をよく観察しているから出たアイディアと言えるのではないでしょうか？

広い視野を持つこと。高く登ること。

結局はこういうことだと思います。かたい言い方をすれば市場をよく調べるとか、よく先行研究を調べるとか、そういうことです。
そして自分のアイディアや自分という存在が、どういうところにいるのかを知る。
これって以外とできていそうでなかなかできない。

結局、同じ地平にたたないと他人と同じ視点にたつことがでいません。周りの人がぎゃーぎゃーいっててなんか敵だらけな気分がしてくることもあるかと思います。
そういうときというのは自分が高みにいるか、相手が高みにいるかのどっちかです。
どっちがどっちなのかはケースバイケースだとは思いますが、自信がなければ巧者だと思っておくのが無難でしょう。

そういうときは実際やってみるしかありません。正直な話やってみないとわからないことというのは世の中たくさんあります。
そういう気づきを繰り返すと、自然と高く登っていくことができるんではないでしょうか？

すると、よりいい眺めの場所で、同じたち位置の仲間と、より広い視野を持って話をできるようになるんだと思います。

再び、自分のたち位置を確認しましょう

自分がいったい世間でどういうたち位置にいるのかを確認することは重要です。
いくら正確な地図があったところで、自分の居場所を勘違いしていたらよけいに迷うだけです。

ようは何が言いたかったかというと、ちょっとだけでいいから顔を上げて周りを見てみるといいことがあると思うよというのと、高く登ることをやめてはいけないんじゃないかねということでした。

補足：

なんか「車輪の再発明したっていいじゃないか！」という突込みが多いようです。別に悪いとはいってません。
けど、全部作りきる労力を払う前に、ちょっと周りを見渡して車輪の再発明以上のことができるようになるんだったら、それはいいことなんじゃないかなといっている感じです。
まったく同じものを作ったとしても、売る人次第で売れたりする可能性はあります。しかし逆を言えば何らかの差（この場合はセールスマンが違うとか？）がそこにあるからそういうことが可能なわけです。

相手の納得をつくるプレゼンテーションの戦い方。

あの大手広告代理店である博報堂のエグゼクティブクリエイティブディレクターの小沢正光さんがかいたプレゼンテーションに関する本。

いま大変プレゼンテーションについて悩んでいて、本屋で平積みしてあったので買いました。

基本的なスタンスとしては、プレゼンテーションは相手を「説得するもの」ではなく、あいてに選んでもらうものというスタンスを取っています。
相手の困ってることに対して解決策を提供するためにプレゼンテーションをしているのであって、こっちの価値観を押し付けにいってるわけではないという感じでしょうか。

内容は具体的なテクニックというよりは、どちらかというとプレゼンに望むにあたっての心構えや考え方を中心に展開されています。
派手なエフェクトとか演出などを期待している人には向かない本かもしれないです。

個人的には、相手（決裁者）のことをよく知るという当然ではあるけど忘れがちであることを改めて指摘されたところが大変印象深かったです。

著者の体験談や経験を元に話が書かれているため、そのあとをトレースすることでいろいろな知恵を学ぶことができると思います。

とりあえずプレゼンテーションに望むための概論を把握するためにお勧めの一冊。