ITコンサルタント 市井賢児のメモ

　有料自習室ナビ。

　都道府県別で整理された有料の自習室のリンク集です。
　環境投資を「持たない」方向にする、家に帰ると子供がいてどうにもならない、などの方に。

　勉強する時には、本探しが１つの重要な作業になりますが、これがなかなか大変です。
　キーワードをタイトルに持っているかが最初のポイントですが、そのキーワードも学習を始めたばかりやあるレベルで停滞した状態だと「自分が今知っている範囲」がボトルネックとなってしまい、新たな出会いの機会を失いがちです。
　そんな時に役立ちそうなのが；

　想 - IMAGINE Book Search

　自由記入のテキストボックスに文章を入れ、そこから連想される情報を複数サイトにわたって横断的にサーチしてくれるサービスです。

　長い文章を入れた時に本領を発揮して欲しいところですが、文脈までは押さえきれないらしく「拾ってしまった」感のある結果が出ることもしばしば。
　例えばこれの直前のエントリをまるごと入れて検索すると、Wikipedia の Copland の項もリストアップされます。
　たとえ話に出した Apple の 90年代における１つのキーワードではあるのですが…

　でもそういった「文章には現われていないけれど連想検索で拾えるキーワード」が出てくるのは、使いようによっては非常に強力な勉強ツールになりますね。
　「Apple 社は90年代後半の危機的状況の中」という一文から Copland という具体的なテクノロジーの名前を拾ってくるのは素晴らしい。
　見る側の都合によってはノイズですが、これなら一旦耳をすます価値のあるノイズだと思います。

　また、これの検索に使われている本の検索/紹介サービスとして
　　Webcast Plus
　　新書マップ
　も読書の幅を拡げるのに役立ちそうです。

　議論メモ。
　業務の多角化は私たちの世代の感覚だと「古い物」のイメージがありますね。70年代以前の感覚というか。
　また選択と集中こそ基礎的な戦略であり、それと真っ向から反する多角化は稚拙な考え方との見方すらあります。

　ですが落ち着いて考えると、多角化と集中化は相互に補完しあう関係であり、状況の変化に合わせて入れ替わる相（フェーズ）であるとの見方が適切だとわかります。

　まず状況が厳しい中では、キャッシュフローを生んでくれる箇所を選び、そこにリソースを集中すべきです。
　リソースを効率的に使わないことには、厳しい状況で生き残っていくことが難しいからです。
　これは今、一般的に言われていることですね。

　ですが、その厳しい状況を乗り切って落ち着いてもなお、その集中状態を維持したり、さらに集約化を進めるべきでしょうか？
　答えは必ずしもイエスではありません。
　あまりに集中しすぎると、外的要因や偶発的要因でその集中先の将来性が失われた時、方向転換することすら難しくなってしまうからです。

　ある程度余裕が出てきたら、集中していたのとは違う場所に種を撒き、新たな芽を育てることにも力を割くべきです。
　この芽が花咲けばリスクの分散にもなりますし、新たなイノベーションが生まれるのもこういう場であることが多いはずです。
　Apple 社は90年代後半の危機的状況の中、Apple 社のアイデンティティに集中して iMac を産み成功し、体力が回復してから OS の Unix 化や iPod、iPhone の開発などイノベイティブな事業を広げていきました。
　そしてその相乗効果（シナジーは多角化とセットで語られがちな「バズワード」ですね）か、最近は Mac の売れ行きも好調だそうです。

　ですから必ずしも選択と集中が正しいわけではなく、自社や業界の状況に合わせて多角化とどちらの相にいるべきか、と考える方が妥当です。
　そもそも、選択と集中が効果を生むには、事前に有望な選択肢が存在することが前提ですからね。
　そしてその選択肢を意識的に増やすフェーズを担うのが多角化の時代ともいえます。

　良エントリにつきメモ。
タイム・コンサルタントの日誌から：
プロジェクト・マネジメントは組織としての能力である

実際は、プロジェクト・マネジメントの能力は、マネージャー個人だけの能力ではなくて、組織としての能力である。この点が理解されないので、議論がいつも空回りしてしまうのだ。プロジェクト・マネジメント能力には、上位構造・中位構造・下部構造の三階層がある。そしてこれらはピラミッド状になっている。

　プロジェクトマネージャのスキルは上位構造にあり、それだけではプロジェクトをうまく回すことはできない。
　プロジェクト・マネジメントは個人としての能力ではない。

　上位構造が機能するためには中位構造が必要。
　それは過去のデータ（おそらく進行中のプロジェクトの成果実績と、プロジェクトに投入しているリソースやツールの過去プロジェクトにおける実績の２つだと思われます）、ツール、業務手順と WBS。

　さらに中位構造が機能するためには下位構造が必要。
　組織体制や権限がそれに当たり、そもそも適切に実績を報告する文化であったり標準化を目指し標準を守る、せめて守ろうとしブレがあったら報告・相談がある組織でなければデータもツールも信用できない。
　またそもそも論だけれど、プロジェクトマネージャは勿論、各リーダーやメンバーにも適切な権限が与えられ、権限に基づいた働きかけに応えられる組織でなければ何も機能しない。



　…当たり前な話ではありますが、プロジェクトマネジメントというと PMBOK の 9 つの知識エリアを語って満足してしまいがちな自分には良い指摘でした。
　「課題管理をしっかりしよう」と言った時に、「しっかり」の中身は組織文化まで含めて議論しなければならず、では組織文化を（プロジェクトという期限の決まった中で意味のある時期までに、意味のあるレベルまで）変えていくには…と考えると、まるで別の地平が見えてきます。

　前回のエントリではファクトにこだわる事が重要だと述べましたが、それを実践するにあたっての注意点を。
続きを読む

　コンサルタントの仕事の基本の基本は、ファクトとロジックです。
　今回はそのうちの１つ、ファクトについて。

　なぜファクトが重要か？
　それがクライアントと、あるいは他のステークホルダーと渡り合う際の最も強力かつ確実な武器になるからです。
続きを読む

　実際そうなんですけど（著者はIBCSの方なので）、最近の学習法本の中ではコンサルタント向けな印象の本でした。
　何がそう感じさせるかというと、学びによる成果へのこだわり。

続きを読む