Information Technology Tips

MySQLのSQL_CALC_FOUND_ROWSを使用する際の無駄なメモリ消費に注意 ページング機能の実装などのために、ヒットした全件数を取得する必要のある場合があるかと思います。 その場合、下記のようにSQL_CALC_FOUND_ROWSを使うと、検索結果に加えて、そのクエリの全ヒット件数が取得できます。 SELECT SQL_CALC_FOUND_ROWS table.column1, table.column2 ...(途中省略)... FROM table WHERE (条件) しかし、SQL_CALC_FOUND_ROWSを使うと、「絞り込んだ結果にヒットする全べての行の結果のセットを作成する」という大きな欠点があります。 これは、LIMIT, OFFSETを指定していても実行されてしまうので、 SELECTで指定するカラム数やデータ量が多い SELECTの結果返ってくる行数が多い 場合、無駄に領域(≒メモリ)を消費してしまうので注意が必要です。 例えば、100万行検索対象としてヒットするクエリの場合、仮にLIMIT 20と指定して最初の20行を取得するようにクエリを書いても、その100万行分の結果セットが作成されてしまうということになります。 対応策 根本的な対応策としては、SQL_CALC_FOUND_ROWSを使わない(結果行数の取得はCOUNTを用いた別クエリで取得する、結果行数をあらかじめサマリーテーブルに保持しておく)ことですが、 SQL_CALC_FOUND_ROWSをどうしても使う必要がある場合は、 SELECT SQL_CALC_FOUND_ROWS primary_id のように最低限のカラムを指定して結果行セットを取得 (LIMIT OFFSET指定前提) 取得したprimary_idを使って必要なデータを取得 して、SQL_CALC_FOUND_ROWSで使用する領域をできるだけ減らすことで、対応するしかないと思います。 世の中ではLIMIT, OFFSETは使わない方がよいとよく書かれていますが、 SQL_CALC_FOUND_ROWSは、書いてしまえばどんなときも検索にヒットする全結果行セットを作成するので、同じくらい使用する際には注意が必要です。

SELECTの結果をUNIONして ORDER BY する際には下記の点に注意する必要があります。 無駄なメモリ消費 ソートにINDEXが利かない (≒CPU負荷増大) 対応策 可能であればPush-down Condition (各サブクエリ内でORDER BY, LIMIT, OFFSETを適用してからUNION, ORDER BYを実行する)を利用することで、 パフォーマンスを改善できる場合があります。 下記に例を示します。 もともとのクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) UNION ALL SELECT tableB.column1, tableB.column2 FROM tableB WHERE (条件) ) AS tmp ORDER BY tmp.column1, tmp.column2 LIMIT 100, 20 Push-down Conditionを用いて書き直したクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) ORDER BY tableA.column1, tableA.column2 LIMIT 30 # ただしこのPush-down Conditionの手法も下記の場合は、効果が半減しますので注意が必要です。 OFFSETの値が大きい場合は、結局全結果セットUNIONと変わらない サブクエリ内のソートで、INDEXが効かない場合

今回は、筆者が気をつけている、MySQLのクエリチューニングの基本的な考え方について、紹介しようと思います。 基本的な指針としては、下記を守ることが重要です。 MySQLがクエリの実行で使用する領域(≒メモリ使用量)を減らす。 クエリ対象の行を減らす (INDEX, サマリーテーブルを駆使)。 上記の基本的な指針に基づいて、クエリを組み立てる際は以下の点を考慮するとよいと思います。 SELECTで指定する行は少なくする。 JOINするテーブルの数は減らす。 TEXTや大きいサイズのVARACHARでのORDER BYは極力避ける。SUBSTRなどを使ってカラムの一部データのみを使うことも考慮。 EXPLAINを実行した際に Extra: Using where; Using temporary; Using filesort と表示される場合は要チェック。 確認部分: 巨大なTemporaryテーブルが作成されないように注意。 対策: 「ソート部分でINDEXを使えないか」「サマリーテーブルを使って余計なJOINを減らしソート対象の行数を減らせないか」を検討。 INDEXを効かせる。 テーブル設計段階でどのカラムにINDEXを張るかをしっかり検討 (当たり前ですが。) 特にソートの必要がある場合は、できるだけINDEXやPRIMARY KEYを利用できるようにクエリやテーブルを設計。 基本MySQLのクエリオプティマイザに従うべきですが、あえて特定のINDEXを効かせる/効かせない場合は FORCE INDEX STRAIGHT_JOIN の利用も検討。ただし、クエリの実行プランはデータによっても変わるので、基本、FORCE INDEXやSTRAIGHT_JOINは使うべきではないと筆者は考えています。 想定される状況が限定的 解決しようとしているクエリの問題が明確 性能改善度合いが大きい ときのみ、FORCE INDEXやSTRAIGHT_JOINは使用すべきかと思います。また強制したクエリの実行プランが最悪の実行プランになった場合も想定することをお勧めします。 複雑なネストクエリは避ける。 確認部分: Temporaryテーブル(INDEXが効かない！)が作成される可能性が高い上、メモリも大量に...

下記の順序で環境を更新していったときに、問題が起こったのでメモしておきます。 Spring 3 + Java 7: もともとの環境。 Spring 3 + Java 8 (Java 8のラムダ機能などのJava 8からの新機能は未使用): 問題なく動作。 Spring 3 + Java 8 (Java 8のラムダ機能などのJava 8からの新機能を使用): 起動時に下記のExceptionが発生 org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: URL ...(途中省略)... java.lang.ArrayIndexOutOfBoundsException: xxx Googleで調べたところJava 8から導入された新機能を使う場合は、Spring 4に更新しないといけないようです。 Mavenとかは、使っていなかったので、Spring Frameworkから提供されているspring-xxx系のjarすべてをバージョン3.X系からバージョン4.X系のものに手動で置き換えました。 (Spring Frameworkはバージョン5.X系ももう出ているのですね。既に置いていかれているorz...) 無事にアプリケーションが起動するようになりました！ ただ普通は、こんな乱暴にjarを入れ替えることは難しいので、アップデートはもっと慎重にやるべきでしょうね。

Google App Engine(GAE)から外部のネットワークへ接続する際の注意 Google App Engine(GAE)の開発環境の移行の際にJava 7からJava 8へ移行しました。 その際、GAEから、java.net.URL.openConnectionを使って普通に外部ネットワークのAPIを呼び出そうとすると下記のエラーが発生するようになってしまいました。 java.net.UnknownHostException: ホスト名 いろいろ調べていくと、下記のページにたどり着きました。 https://cloud.google.com/appengine/docs/standard/java/issue-requests 上記の表を間単に日本語訳すると URLのフェッチ方法 Java 7 Java 8 UrlFetch API Calls com.google.appengine.urlfetch.*以下のクラスを使う。無料で使用できる部分あり。 com.google.appengine.urlfetch.*以下のクラスを使う。無料で使用できる部分あり。 Javaネイティブのjava.net.URL.openConnectionなどを使う方法 無料ユーザも制限なく利用可能。 無料ユーザは、利用不可。 java.net.UnknownHostException、java.net.SocketTimeoutException、java.io.IOException とかが投げられる。 まとめると、 GAEで外部ネットワークへアクセスする方法には「GAEが提供するUrlFetch API Calls」「Javaネイティブのjava.net.URL.openConnection」の2つ方法がある。 Java 7では、「GAEが提供するUrlFetch API Calls」「Javaネイティブのjava.net.URL.openConnection」は無料でどちらの方法も利用可能。 Java 8で無料で利用できるのは「GAEが提供するUrlFetch API Calls」のみ。 Java 8で「Javaネイティブのjava.net.URL.openConnectionの方法」は課金ユーザーのみ利...

Google Plugins for EclipseからCloud Tools for Eclipseの移行 長らくEclipse Luna (4.4) + Google Plugin for Eclipseで開発を続けてきたのですが、Google App Engineの開発ページを覗いたら下記のようなメッセージが出ていてびっくり。 The Google Plugin for Eclipse is deprecated and will be removed in January 2018. Migrate to Cloud Tools for Eclipse and/or the GWT Eclipse Plugin as soon as possible to avoid disruption. Google Plugin for Eclipseは、2018年の1月でサポート打ち切りで、Cloud Tools for Eclipseに移行しなさいとのこと。 せっかくなので最新のeclipseを使って下記の設定で開発環境を再構築することにしました。 移行方法 最新のJDK 8 を http://www.oracle.com/technetwork/java/javase/downloads/index.html からダウンロードしてインストール。JDKをダウンロード Java 9 も試そうかとも思ったのですが、2017年9月現在Google App Engine側はまだJava 8までしかサポートしていないので、 Eclipseを  http://www.eclipse.org/downloads/eclipse-packages/  からダウンロード。私は、Eclipse IDE for Java Developersをダウンロードしました。 EclipseでGoogle App Engineの開発を行うための設定を https://cloud.google.com/eclipse/docs/quickstart  を読んで実施。 Google Cloud SDKをダウンロード Google Cloud Tools for Eclipse をEclipse Marketplace.を通してインス...

今回紹介する本は、ジェラルド・M・ワインバーグの「 コンサルタントの秘密―技術アドバイスの人間学 」です。 原著は「 The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully 」です。私なりに訳してみると「コンサルティングの秘密: 上手なアドバイスの与え方ともらい方」になるでしょうか。邦訳の題名は原題の内容をしっかり捉えていて上手いと思います。 原著が刊行されたのは1986年で、この記事を書いている時点で30年以上も前になりますが、本書の内容は今でも通用するアドバイスばかりです。本書の内容は、誇張でなく、今から30年後でもまだ通用する気がします。 この本の中ではワインバーグが名づけた「～の法則」とか「～の原理」が大量に登場します。どれもユーモアに富んでいて思わずクスッと笑ってしまうものばかりです。 ほんの一例ですが、こんな感じです。 逆転ワインバーグの法則 レッテルの法則 三本指の法則 ポテトチップの原理 オレンジジュース・テスト などなど。巻末にはご丁寧に法則集索引までついています。内容はぜひ本書を読んでご確認ください。 エッセイでもなく、教科書のように型にはまった方法論を押し付けるでもなく、それでいて学ぶところが多い不思議な本です。ユーモアに富んでいて、肩の力を抜いて読める本ですが、ワインバーグの長年の経験から得られた深い洞察の詰まったすばらしい本です。 本のタイトルには「コンサルタント」「技術アドバイス」といったキーワードが並んでいますが、これらのキーワードと直接の関係ない人にもお勧めできます。

ジェラルド・M・ワインバーグは、自身のコンピューター業界を中心としたコンサルタント業の経験をもとに、人間やシステムの性質を本質的に捉えた数多くの書籍を発表しています。 今回紹介するのは、その中の「 プログラミングの心理学 25周年記念版 」になります。 25周年は、英語ではSilver anniversaryと表現されるようで、原題は「 The Psychology of Computer Programming: Silver Anniversary Edition 」となっています。 本書題名中の25周年というのは、原著の「The Psychology of Computer Programming」の初版が発行された1971年から25年後、つまり1998年に発行された英語版のことをさして、25周年といっています。この英語版の「 The Psychology of Computer Programming: Silver Anniversary Edition 」は、一度2005年に邦訳されて2005年に「 プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版 」として刊行されています。今回紹介するのは、2005年に刊行された邦訳版の装丁を変えて2011年に再発刊されたものになります。ですので、おおもとの原著からは、40年経っていることになります。 本書では、1971年当時の初版の構成をそのままに、そのあとに25年後のワインバーグの振り返りが追記されるという形式をとっています。 この書評を書いている時点で、40年以上も前 (25周年を記念して加筆された部分は20年前)の内容で役に立つのと思う方も多いと思いますが、それがどうして、世の中あまり変わっていないのか、今でも十分に通用する示唆に富んだエピソードが多く紹介されています。 とはいえ12章「プログラミング言語の設計原則」で出てくる言語の話題はCOBOLとかFORTRANなので、「その言語なに？おいしいの？」「古臭い話だ！」と思う人が多いと思います。それでもよく掘り下げて読んでみると、普遍的な話題を扱っていることに気づかされると思います。これは、本書が「心理学」という言葉を使っているとおり、いつまでたっても変わらない、人間の根本的な性質を軸に書かれているからだと思い...

今回紹介するのは、「 世界一わかりやすいプロジェクトマネジメント 第4版 」です。 本書は「IDIOT'S GUIDE」シリーズの中の一冊になります。 英語の最新版は2014年刊行の第6版「 Project Management, Sixth Edition (Idiot's Guides)  」のようです。   本書では、プロジェクトマネジメントにかかわる基礎的な手法や用語が細かく解説されています。たとえば、 PDCAサイクル ガント・チャート (gantt chart) クリティカル・パス (critical path) WBS (Work Breakdown Structure) 振り返り スコープ・クリープ (scope creep) などです。本書は邦訳された書籍なので、日本語のプロジェクトマネジメント用語が英語ではどういうものになるのかも参考になると思います。 個人的には解説の途中途中で、数行さしこまれている「ときは金なり」「現場の声」「ご用心」「賢者の言葉」の項が読んでいて、面白かったです。 本書は、教科書的な書き方で書かれているので、面白みはないですが、プロジェクトマネジメントで発生する作業について網羅的に書かれているので、プロジェクトマネジメントに初めて取り組む人にとっては、よいスタート地点になると思います。より実践的なものを求める方は、「 アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 」の方がお勧めです。

今日紹介する本は「 ハーバード流マネジメント講座 90日で成果を出すリーダー 」です。 こちらの書籍は、新しいポジションに移ったリーダーがいかにして成果を出すかということに徹底的に重点を置いて書かれています。 原題は「 The First 90 Days: Proven Strategies For Getting Up to Speed Faster and Smarter 」です。直訳すると「最初の90日: より速く賢く成果を出すための確実な方法」とにでもなるでしょうか。   どうしても人間は自分の今までの成功体験の延長で、次の新しいポジションの仕事に臨むことが多いですが、本書では新しいポジションに移行する前に、 自分の強みと弱みの評価 新しいポジションへの移行のリスク評価 新しい上司や部下との関係 新しい組織での文化の分析 など、を綿密に準備しておく必要があると述べています。そしてその準備を90日間でやり遂げる必要があると述べています。 私は本書で述べられているSTARSモデル (Start-up: 立ち上げ、Turnaround: 建て直し、Accelerated growth、Realignment: 軌道修正、Sustaining success: 成功の持続)については、無理やりSTARSというごろのいい名前をつけるとために分類した感があって、いまいち役に立つ気がしませんでした(失礼！)が、本書に書かれている内容自体は、どれも納得のいくものが非常に多かったです。組織内での自分の振る舞いの仕方について不安に感じたときに、折に触れて、本書を読み直しています。 私も実際、新しい職場に入ったときに、周囲から「こいつは何ができるんだ？」みたいな目で見られ、不安になったことをよく覚えています。 私自身も、本書で言及されているとおり、小さな成果をコツコツ積み重ねていくにつれ、「周囲からも信頼され始めているな」という実感を持って落ち着いて仕事に取り組むことができるようになり、さらに大きな成果を出せるようになるという、好循環を経験したことがあります。 本書で、特に私自身ができていないと思った部分は「上司」との関連性の部分です。 本書では様々な視点から、成果を上げるために、上司とどのようなコミュニケーションのと...

今日、紹介する書籍はジェフリー・フェファーの『 「権力」を握る人の法則 』です。 原題は「 Power: Why Some People Have It—and Others Don't  」です。 直訳すると「権力: なぜ持てる人と持てない人がいるのか」でしょうか。 邦訳版の題名が日本語としても本質を掴んでいて、直訳よりもいい題名だと思います。 結論からいいますと、この本はお勧めです！ もともと2011年にハードカバーで出版されたものが、2014年に文庫化されました。 文庫版は、お求め安く1000円もしないので手軽に購入できると思います。 他のフェファーの書籍は文庫化されていませんので、フェファーの書籍を読みたい方はこの『 「権力」を握る人の法則 』から読み始められるのがいいと思います。 私もこの書籍を読んで始めてフェファーの他の著作を読むようになりました。 確かに私が今まで所属した組織で上層部にいる人を眺めると、この書籍に書かれているとおりのことを実行している人ばかりなので、本書の内容を実践すれば、間違いなく組織内での闘争には負けないと思います。たとえば、 出る杭になれ 愛されるより恐れられよ 実績と昇進は関係ない！ 上司を気分よくさせる 権力者らしい話かた(を心がけよ) 悪評にも利点がある などなどです。詳しい話は本書を読んでもらうのが一番です。 とはいえ、何が一番難しいかというと、やはり本書に書かれていることを実践することなのですが。 なぜここまでして権力を握るべきなのかという理由について、フェファーは、疫学研究者のマイケル・マーモットの研究結果を持ち出して、次のように述べています。 ヒエラルキーの底辺にいる人は、頂点にいる人と比べ、死亡率が四倍も高いことが判明している。 ... 自分の状況を自分でどうにかできる方が心身の健康によいのであり、「社会的環境から成人の死亡率を予測することは可能だ」とマーモットは結論づけている。 (335ページ) 私も、本書を読むまでは「上に行こうとしてあくせくするのはみっともない」とずっと思っていましたが、本書を読んでからは、その考えがいかに「現実から目を背けた、組織内での自らの可能性をつぶす考え」だったと痛感させられました。 実践するかどうかは...

今日紹介する書籍は、「 チームが機能するとはどういうことか―「学習力」と「実行力」を高める実践アプローチ 」です。 本書はタイトルどおり、チーミングでも特に「学習」という部分に特に重点を置いて書かれています。 原著は「 Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy 」になります。直訳すると「チーミング: 知識経済の中で、いかにして組織は学習し、イノベーティブになり、競争するか」にでもなるでしょうか。 この書籍については直訳より、邦訳版の題名の方が断然よいと思います。私が本書の内容を読んだ限りでも、邦訳版の題名は、本書の内容をよく表していると思います。 予断ですが、Innovationの訳は日本語では、カタカナ英語のイノベーションが一般的になっているとは思いますが、何かもっとピッタリ来る日本語はないのでしょうか。 本書はリーダーがトップダウンの決定を下すのではなく、チームメンバーそれぞれが自身の専門性や得意分野を生かし、意見の対立を乗り越えて、チーム全体で学習しながらチーム全体のパフォーマンスを上げるためには、どうすればよいかについて実例を交えながら詳細に述べられています。 こういったチーミングやマネジメントの話は、掘り下げていくと、人間の内面に深く根ざした部分にたどり着き心理学の研究結果が大いに役に立つものですが、本書もその例に漏れず、心理学分野の研究結果も交えなながら、効果的なチーミング手法について解説がなされています。例えば、人間は今まで自分が経験してきたものによって、現在の状況の認識が左右されているという観点(=フレーミング)から、革新的なプロジェクトを成功させるためには、どのような「フレーミング」が適切かを解き明かし、またリーダーはどのようにしてチームに適切なフレームを導入することができるかについて解説しています。 多くの書籍で「失敗」から学ぶことの重要性について語られていますが、本書では「失敗」を罰せられない環境づくりがなければ、「失敗」から学ぶことは難しいと指摘しています。本書では、失敗を「防ぐことのできる失敗」「複雑な失敗」「知的な失敗」に分類し、「防ぐことのできる失敗」は根本原因の究明を行い、「複雑な...

今日紹介させていただくのは、リチャード・P・ルメルトの「 良い戦略、悪い戦略 」です。 私は本書を読んで、リチャード・P・ルメルトの他の書籍を読んでみたいと思ったのですが、どうも2017年現在ではこの一冊ぐらいしか一般向けの書籍はないようです。残念。 定番の原著の紹介ですが、原著の題名は「 Good Strategy / Bad Strategy: The Difference and Why It Matters 」です。この書籍については邦訳版の題名は、ほぼ直訳になっています。 副題もつけて訳せば「よい戦略、悪い戦略: その違いとなぜその違いが大事なのか」になるでしょうか。 私は、著者の意見に共感する部分が多く、時間を置いては読み直して、読み直すたびに著者の「よい戦略」の立て方を頭の中に入れなおし、「悪い戦略」に自分が陥っていないか確認しています。本書では、まず「よい戦略」の実例を挙げ、その後「悪い戦略」を徹底的に(!)こき下ろしてその特徴を解き明かし、それ以降は「閾値効果」「テコ入れ効果」「おもしろみのある競争優位」など数多のキーワードを使って筆者独自の視点で「よい戦略」の特徴を丁寧に説明しています。 本書は共感する部分が多く、全部紹介したくなってしまうのですが、「よい戦略」については、是非本書を読んでもらうとして、特に私が強く共感した戦略とリソースの部分を紹介します。筆者は戦略とリソースの関係をこう述べています。 後世に賞賛され研究されるような優れた戦略は、乏しいリソースから始まっている。 ... その希少なリソースを巧みにコーディネートするところに戦略の妙味がある。 ... あまりに有利な地位を占め、さしたる努力もなしに利益があがるようになると、ぬくぬくとぬるま湯につかって楽をしたくなるのが人情である。 成功は怠惰とうぬぼれを招き、ひいては衰退や低迷につながる。 (184～185ページから抜粋) 私もかなり限られたリソース環境でプロジェクトを運営したのですが、本書で述べられている通り、その方が「本当に必要なものだけを実施しよう」「いかにして自らの強みを生かそうか」と必死に考えるようになり、結果的によい戦略かどうかは分かりませんが、非常に意味のあるとがった戦略を立てることができたと思っています。 このリソース...

今日、紹介する書籍はマイケル・A・ロベルトの「 なぜ危機に気づけなかったのか ― 組織を救うリーダーの問題発見力 」です。 マイケル・A・ロベルトの書籍としては、「 決断の本質 プロセス志向の意思決定マネジメント (ウォートン経営戦略シリーズ)  」の方が有名かも知れませんが、今日紹介する書籍も負けず劣らずよい本です。 原著の題名は「 Know What You Don't Know: How Great Leaders Prevent Problems Before They Happen 」です。直訳すると「知らないことを知る: いかにして偉大なリーダーは問題が起こる前にそれを防ぐのか」になると思います。直訳でもそんなに悪い題名のような気もしませんし、なぜ原著の題名とそこまで変える必要があるのか、私には正直よく分かりません。表紙の画像も氷山の写っている英語版の方が好きです(汗)。 本書では、題名どおり危機や問題が実際に起こる前にいかにして防ぐのかについて、詳細に述べられています。特にリーダーの立場にたつ人が、どのように振舞えば、危機の兆候をうまく捕らえやすくなるかについて、人間の心理学的見地も踏まえ、丁寧に解説されています。 本書では、組織の上に行けば行くほど、情報の「フィルタリング」が強まり現場の声が聞こえなくなり、危機の兆候を見逃す可能性があると指摘しています。情報がリーダーのもとに届かないのは、リーダーだけの問題だけはなく、周囲にいる部下が良かれと思って、情報にフィルタリングをかけてリーダーに伝えてしまうということも原因であると指摘しています。本書ではそのようなフィルタリングをする役割を演じてしまっている人を「ゲートキーパー」と呼んでいます。このようなフィルタリングを防ぐために常に最前線で働いている現場の人や、自社の製品を使っている顧客の意見・苦情を「自分の耳で聞く」ことが大事だと述べられています。 危機を見つけるのが難しい理由は、その兆候が見過ごされやすく、関連性が全く見えないことにあります。そのため、筆者らはリーダーは「人類学者になり」何が起きているかを上手に観察し、「パターンを探し」、一見つながりが見えない「点を結びつける」能力が必要だと述べています。特に「点を結びつける」の部分では、9・11のアメリカ同時多...

今日紹介する本は、ジェフリー・フェファーの「 影響力のマネジメント (リーダーのための「実行の科学」) 」です。この本は、私にとってジェフリー・フェファーの著作の中で、最も実際の仕事の中で役に立った本です。 原著の題名は「 Managing With Power: Politics and Influence in Organizations 」になります。直訳すると「パワーを用いたマネジメント: 組織における政治と影響力」とでもなるでしょうか。 本書は題名どおり、組織内での「パワー」「影響力」ということに徹底的に注力して書かれています。 例えば、「パワー」を使っていかに敵対勢力を一掃するか、どうやって自分を強い立場に置いて「パワー」を維持するか、そして、どういう行動により「パワー」を失うのかなどについて、実際に歴史上起きた例を交えながら、事細かに述べられています。アメリカ大統領のリンドン・ジョンソン、ニューヨークの公共事業担当者ロバート・モーゼス、Appleのスティーブ・ジョブズ、日産の川又(私は本書を読むまで知りませんでした)まで、幅広い事例が上げられていますが、この事例の幅広さからも本書がいかに本気で書かれているか伝わると思います。 本書の中のほんの一部ですが、「パワーの源泉としての個人特性」の部分で述べられているコンフリクトの部分が、本書の雰囲気をよく表していると思いますので、引用します。 「うまくやっていくためには、仲良くやっていかなければ」という格言は、子どものころからしばしば聞かされるものだ。 ... コンフリクトから逃げてばかりだと、自分の思いを通せることはまずないだろう。 ... 一緒に仕事をしている仲間内ではたしかに好かれる要素だろうが、パーソナリティが穏やかだからと好かれている者が必ずしも最も有力だとか、物事を遂行できるなどということは実際にはないと考えてよい。 (186ページ) フェファーはこの後の文章で、多くの人々はコンフリクトを嫌うので、好戦的で厄介な存在になることもパワーを獲得する上で重要な要素だとも述べています。 上記のような内容を読んで、げんなりして読むのをためらう方もいるかも知れません。正直、私も本書を読んで「こんなことばかりだから、組織には居たくない。」と思ってしまいました。しかし、フ...

今日紹介する本は「 アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法― 」です。 本書は、著者スコット・バークン(Scott Berkun)が、マイクロソフトに長年プロジェクトマネージャーとして勤務し経験してきたことを、一般化してまとめたものになります。 著者の実体験をふんだんに取り入れて書かれていますので、実感がこもっているところがよいろ思います。 クリティカル分析の仕方やガントチャートの組み方といったプロジェクトマネジメントの技術的手法そのものではなく、プロジェクトマネージャーの心構え、コミュニケーションのとり方、よいアイデアの生み出し方といった、より実践的なスキルについて書かれた本になります。 原著の題名は日本語のカタカナ英訳と同一で「 The Art Of Project Management (Theory in Practice (O'Reilly)) 」です。邦訳の題名には著者の経歴を踏まえて「Microsoft」を入れたのだと思います。  原著の方は新版が発行されていました。ぜひ機会があれば読んでみたいと思います。 「 Making Things Happen: Mastering Project Management (Theory in Practice (O'Reilly)) 」   本書は、優先順位付けの大切さ、ものごとを成し遂げるためには「ノー」といえるようにならなければならない、社内政治から逃げてはいけない、など、私に初めてプロジェクトマネジメントとはどういうものかを教えてくれた思い出深い書籍です。 特に当時の私は社内政治という言葉を毛嫌いしていました。本書の著者の言葉をかりていうならば、 政治力(名詞): 邪悪で、弱虫で、自己中心的な人々が利用しようとするもの (399ページ) と認識していました。この章で著者(Berkun)の上司がある行動をとったことにより、著者は「政治」に対する認識を大きく改めます(上司がどんな行動をとったかは是非、本書を読んでみてください)。私は、この部分を読んで「政治」に対する自身の認識の未熟さと傲慢さを痛感し、社内政治もしなければ、物事は成し遂げられないと強く思うようになりました。 著者は、本書で様々な視点から、どのよう...

今日紹介する本は「 ソフトウェアの世界でキャリアを築く Making it Big in Software  」です。ソフトウェア業界に特に重点をおいて、いかにして自分の望むキャリアを築いていくかについて述べられています。   原著は「 Making it Big in Software: Get the Job. Work the Org. Become Great. 」です。   原著の題名を直訳すると「ソフトウェア業界で成功する: 仕事を得る。組織で働く。偉大になる。」でしょうか。 本書では、ソフトウェア業界の錚々たる著名人のインタビューが採録されています。 所属は、本書の執筆時点のものなので変わっている方もいるかも知れませんが、彼らの功績を示すには十分でしょう。 Jon Bentley (『珠玉のプログラミング著者』) Marissa Mayer (Google副社長、Google初期メンバーの20人目、元Yahoo CEO) Bjarne Stroustrup (C++の考案者 ) Richard Stallman (フリーソフトウェア運動の創始者) Ray Tomlinson (電子メールシステムの発明者) Peter Norvig (2002～2005年の間のGoogleの検索サービスの総責任者) John Schwarz (IBM, Symantec社の要職を歴任、 Business Objects社 CEO) Linus Torvalds (Linuxの生みの親) Mark Russinovich (Windowsのグル、Microsoftテクニカルフェロー) David Vaskevitch (Microsoft社 CTO) Grady Booch (UMLを生み出した一人) Tom Malloy (Adobe社チーフソフトウェアアーキテクト) James Gosling (Javaの考案者) Robert Kahn (インターネットの共同発明者) Steeve Wozniak (Appleコンピューターの発明者・Apple社の共同創設者) Marc Benioff (Salesfoce.com社CEO) Diane Greene (VMWare社の共同創業者、元...

今回紹介するのは、「 イノベーションのジレンマ 」で有名なクレイトン・M・クリステンセンの本です。クリステンセンの「イノベーションの～」シリーズは以下、山のように邦訳されています。 「 イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき 」 「 イノベーションへの解 利益ある成長に向けて 」 「 イノベーションの最終解 」 「 イノベーションのDNA 破壊的イノベータの5つのスキル 」 今回紹介する「 イノベーション・オブ・ライフ - ハーバード・ビジネススクールを巣立つ君たちへ 」は、クリステンセンの研究業績そのもとというより、彼の経営研究「理論」として人生に当てはめて講義したような本になっています。(理論を強調したのにはちゃんと理由があります。本書を是非読んで下さい！)。 また例のごとく原著の紹介ですが、原著の題名は「How Will You Measure Your Life?」で、題名のどこにも「イノベーション」という単語は入っていません。「クリステンセン=イノベーション」で売る戦略なのでしょう。出版社も商売が上手いですね。 原著の題名を直訳すると「どうやって人生を計る？」になると思います。 この本は、特に何とはなしに立ち寄った古本屋で偶然見つけました。その時点でクリステンセンの「イノベーションの～」シリーズがかなりの冊数購入しており、正直そこまで特期待はしていませんでした。しかしこの本は読み進むうちに、色々身につまされる話が書かれていて、自分自身の人生への今まで、現在、将来への見方が大きく変わりました。 本書は、経営や事業戦略の失敗事例を出し、クリステンセンの経営学の知見からその失敗を説明し、そして人生に当てはめて指針を示す、という流れで書かれている部分が多いです。例えば、イリジウム・サテライト・ネットワークの失敗例から、一般的な企業投資の理論「よい資本と悪い資本の理論」を説明し、そこから家族や友人の大切さを説くという流れです。特に「よい資本と悪い資本の理論」の部分は、私がハッとさせられたので引用します。 人生でも気をつけていないと、簡単に悪い金の手法に陥ってしまう。自分が打ち込んでいて楽しいと感じる仕事であれば、困難なほどやる気が出るという人は多い。 プレッシャー下でも立派な仕事ができることを証明したい...