Comments
Description
Transcript
マネジメントの教科書
ITC大阪城 2014年度 テーマ研究調査活動 「マネジメントの教科書」 テキスト作成報告書 2015年1月28日 [email protected] http://www.itc-osakajo.jp/ i はじめに 本 WG は、\アメリカの「管理職の基本」を学ぶ マネジメントの教科書―成果を生 み出す人間関係のスキル"[1] の書籍をテキストとして使用するプレゼンテーション用 Powerpoint を作成するものである。 ただし、本報告書においては、著作権の関係からプレゼンテーション用のテキストは割 愛してあることを最初にお断りしておく。 本報告書の構成は、以下の通りである。 第1章 WG 活動について WG 活動・目的・経緯などを説明。 第2章 作成したケーススタディ・事例 書籍の事例ではなく、WG で作成した事例を掲載。 第3章 本活動における考察 本活動における書籍のプレゼンテーション資料作成の考察 本報告書については、報告会を開催し、IT コーディネータとの情報共有を図る。 最後に、本テーマ研究・調査活動を承認していただいた特定非営利活動法人 IT コー ディネータ協会に感謝する。 2015 年 1 月 28 日 ITC 大阪城 新保 康夫 ii ■アメリカの「管理職の基本」を学ぶ マネジメントの教科書の説明がない理由 この書籍は、以下の章構成で書かれている。 第1部 マネジメントの基礎的スキルを学ぶ 第1章 マネジメント入門 第2章 部下の業績管理 第3章 人材マネジメント 第4章 プロジェクトマネジメント 第2部 マネジメントスキルのステップアップ手法 第5章 戦略思考 第6章 リーダーシップ 章タイトルからもわかるように、各章単位がこの書籍の 1 冊のボリュームで入門や基本知 識という項目で書かれているものばかりである。言い換えれば、この書籍は、基本のみ、 要約、または、エッセンスをうまくまとめられて書かれている書籍なのである。 このため、この書籍を説明するのには、書籍をそのまま引用する箇所が多く、引用の範 囲をこえることとなり、その箇所を書かなければ適切な説明とならないことから、本 WG では説明を割愛すると判断した。 また、本 WG は、そもそもプレゼンテーション資料の策定を主要活動とし、この書籍 の説明を活動とはしていない。 iii 目次 第1章 WG 活動について 1 1.1 WG 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 WG 活動経緯 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 成果物 2 第2章 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 作成したケーススタディ・事例 5 2.1 第 1 章 マネジメント入門のケーススタディ・事例 . . . . . . . . . . . . 5 2.2 第 4 章 プロジェクトマネジメントのケーススタディ・事例 . . . . . . . 7 2.3 第 5 章 戦略思考のケーススタディ・事例 . . . . . . . . . . . . . . . . . 12 2.4 ケーススタディ・事例－中小規模の IT 企業 15 第3章 . . . . . . . . . . . . . . . 本活動における考察 21 3.1 書籍のプレゼンテーション資料作成について . . . . . . . . . . . . . . . 21 3.2 アメリカの「管理職の基本」を学ぶ マネジメントの教科書の評価 . . . . 22 参考文献 25 1 第1章 WG 活動について 1.1 WG 概要 背景・課題認識 企業における中間管理職に対しての研修が依頼される場合がある。そのような中、\ア メリカの「管理職の基本」を学ぶマネジメントの教科書"[1] が出版されている。 この書籍は、A5 サイズの 200 ページで、管理職向けのマネジメントについて基本的な スキルがテキストとして書かれている。そのため、研修用のテキストとして利用するに は、丁度良いものとなっている。 当然、この書籍の内容で研修することは、依頼される研修案件に十分対応可能と考え る。しかしながら、プレゼンテーション用の講師資料は自前での作成となる。 このため、講師用資料を作成することにより、IT コーディネータが新しいソリューショ ンとしてビジネスを展開できるようにする。*1 目的・ねらい 本 WG では、\アメリカの「管理職の基本」を学ぶ マネジメントの教科書"[1] の講師用 プレゼンテーション資料を策定することを目的とする。 さらに、策定を通じて、WG メンバーのスキルを向上させることもねらいとする。 具体的な目標としては、以下のとおりである。 1. \アメリカの「管理職の基本」を学ぶ マネジメントの教科書" のプレゼンテーショ ン資料を Powerpoint で作成する。 2. 作成の過程において、自身の過去の経験を活かし、中間管理職向けのマネジメント *1 今後、ＩＴＣ大阪城主催の有償研修を実施する計画である。 2 研修が行えるようにする。 3. 書籍のテンプレートを研修等に活用できるように作成する。 4. 自らの経験からの事例を作成する。 取り組みのポイント 以下の事項を取り組みのポイントとする。 1. プレゼンテーションとして使えるものを成果物とする。 2. テンプレートは、ワードやエクセルなどで作成し、使えるものとする。 3. ミーティングで必要箇所や事例を検討し、メーリングリストで作成物をブラシュ アップする。 1.2 WG 活動経緯 以下の経緯で WG 活動を実施した。 2014 年 7 月 WG メンバー募集 2014 年 8 月 書籍の読む 2014 年 9 月 第 1 回 WG 会議 第 1 章・第 2 章の検討 2014 年 10 月 第 2 回 WG 会議 第 3 章・第 4 章の検討 2014 年 11 月 第 3 回 WG 会議 第 5 章・第 6 章の検討 2014 年 12 月 第 4 回 WG 会議 演習課題の検討 各自、事例等の作成 (～2015 年 1 月中旬) 2015 年 1 月 第 5 回 WG 会議 最終成果物の確認 1.3 成果物 以下の成果物が作成された。 3 ² 講師用プレゼンテーション (Powerpoint) ² テンプレート (21 種類、Word 他) ² 演習課題 (Word) ² 研修案内チラシ見本 ² 本報告書 5 第2章 作成したケーススタディ・事例 書籍の事例・考察はアメリカの事例であるため、掲載できる事例・考察があるところは、 事例・考察を作成することにした。 ただし、本報告書は、事例・考察が列挙のみとなっている。なお、事例・考察に関して は、不適切な箇所があってもできるだけオリジナルを掲載することにした。このため、本 章は、文章や文言が不適切なところがあるのと体裁がそろっていないことを断っておく。 2.1 第 1 章 マネジメント入門のケーススタディ・事例 本節のケーススタディは、マネジメントの基本と中小企業における位置づけについてひ とつの考え方としての考察を掲載している。 Case Study マネージャーの 8 つの役割 IT コーディネータがクライアントとしている中小企業、なかでも IT 企業にマネー ジャーは必要であろうか。現在の IT 企業は、顧客全面依存型と自主独立型に大別される。 顧客全面依存型は、顧客が要請するシステム要件を IT で実現すべく、日夜なみだぐま しい努力をしているが、経営は顧客からの作業対価であり、顧客に与えた成果ではない。 努力は費やした人月で評価され、成果物が評価されることはない。 自主独立型は自主開発または仕入れたソフトウェアやサービスで実現できる成果を顧客 に売り込み、顧客は成果で対価を評価する。こちらのほうが一般企業の活動に近いすがた である。 マネージャーの役割は、顧客全面依存型ではディレクターのみが必要で、あとの役割は その補助的役割である。自主独立型では 8 つの役割がともに必要とである。中小企業であ るからすべての役割を 1 人で果たすこともある。 6 Case Study フラット型組織におけるマネージャーのあり方 中小 IT 企業は本来的にフラット型である。IT の作業は指示されて行うものでなく、作 業者自身が作業のすべてのプロセスを計画し、実施しないとうまくゆかないという特性が あるからである。ひとりの作業範囲を超える成果物を構築する場合は、その成果物は個々 の作業者の個々の成果物の組み合わせであるから、組み合わせという作業を行う作業者が 必要になってくるが、組み合わせという作業でさえ、フラット型組織のひとつの要素とい える。 顧客全面依存型企業であろうと、自主独立型企業であろうと、これらの作業形態が変わ るものではない。これは、IT という商品が、見てわかるものでなく、実際に手に取って、 使ってみてからでないとわからないという特性を持っているからである。見ただけでわか る IT 商品を発明することは、業界の永遠の課題である。 このような特性を持つ商品を取り扱う組織は、どうしてもフラット型にならざるを得な いわけで、マネージャーのあり方も教科書どおりである。 Case Study コミュニケーションスキルを磨く IT という目に見えない商品をビジネスで扱うとき、最終的には手に取って使ってみな ければ対価の評価ができないが、それでも商談の入り口では説明のみによる顧客へのアッ ピールが必要である。 この段階での説明を IT 業界ではプレゼンテーション (プレゼン) という。プレゼンがス テークホルダーを納得させられれば、手に取って使ってみるというプロセスなしに商談が 成立する。そして多くの企業が失敗しているのは外資系の ERP ソフトの導入である。な にしろそのプレゼンたるや、経営トップすなわち対価の支払い責任者を言葉のみで見事に その気にさせてしまうのであるから恐れ入るしかない。 プレゼンもコミュニケーションスキルが肝心であり、教科書であげている基本や心得は 必須条件である。ただし、質問スタイルの使い分け、より良いコミュニケーションのため の 3 要素は、次の目的別コミュニケーショの円滑化の心得であろう。 Case Study 目的別コミュニケーション 教科書ではメールや会議といったコミュニケーションが必要な場面のことを目的別と分 類しているが、それは IT 商品という目に見えない商品のビジネスにとっては手段であっ て目的ではない。 IT 商品のビジネスのプロセスでは、売り込み、要件の合意、合意にもとづく調達、導 7 入、評価とメンテナンスというプロセスがある。それぞれのコミュニケーションの場面 は、プレゼンテーション、フィットアンドギャップ、プロセスマネジメント (プロマネ)、 リスクコントロールなどのコミュニケーションスキルが要求される。これが IT 商品とい う目に見えない商品のビジネスを行ううえでの目的別コミュニケーションである。 これらのコミュニケーションスキルはどれひとつをとっても容易に修得できるものでな く、IT 商品を扱うビジネスマンがそれぞれの分野に特化して行く必然性を物語っている。 このことは、前述のマネージャーのあり方とは切り口が異なる問題である。 2.2 第 4 章 プロジェクトマネジメントのケーススタディ・ 事例 本節のケーススタディは、事例を掲載している。 Case Study 時間、コスト、スコープは、必ずしも制約条件ではないとする 捉え方もある 時間、コスト、スコープは、必ずしも制約条件ではないとすケーススタディとして、あ る「阪神・淡路大震災」後のシステム復旧プロジェクトの事例を掲載している。 8 図 2.1 「阪神・淡路大震災」後のシステム復旧プロジェクト 9 Case Study プロジェクト憲章 プロジェクト憲章の事例を自分たちの事例を掲載する。 図 2.2 プロジェクト憲章 10 WBS 例*1 [2] WBS の例があると理解しやすいと考え、共通フレーム 2013 の要件定義プロセスの箇 所を例として WBS とした。 2.2 要件定義プロセス 2.2.1 プロセス開始の準備 2.2.1.1 要件定義作業の組立て 2.2.1.2 必要なプロセスの組込み 2.2.1.3 要件合意及び承認ルールの決定 2.2.1.4 要件定義環境の準備 2.2.1.5 要件定義プロセス実施計画の作成 2.2.2 利害関係者の識別 2.2.2.1 利害関係者の識別 2.2.3 要件の識別 2.2.3.1 要件の抽出 2.2.3.2 制約条件の定義 2.2.3.3 代表的活動順序の定義 2.2.3.4 利用者とシステム間の相互作用の識別 2.2.3.5 システムの使用が周辺に及ぼす影響への対処 2.2.4 要件の評価 2.2.4.1 導出要件分析 2.2.5 要件の合意 *1 共通フレーム 2013 から引用。 11 ガントチャート例*2 ガントチャート例の言葉がシステム開発の標準的な言葉とはしにくいため、共通フレー ム 2013 の用語にした例を掲載する。 図 2.3 ガントチャート例 *2 WBS は、共通フレーム 2013 を引用。 12 2.3 第 5 章 戦略思考のケーススタディ・事例 本節では、第 5 章で説明があるが、具体的な例がないため、例が必要と追加する。 Case Study SWOT 分析 SWOT 分析の具体的な例として、不動産賃貸業・電気工事業の SWOT 分析の例を追 加する。 13 図 2.4 不動産賃貸業・電気工事業の例 14 ビジョンの戦略的な分析 「顧客のニーズ、ウォンツ、期待を知る」 「顧客のニーズ、ウォンツ、期待を知る」ための事例として、顧客インサイトによるフ レームワーク [3] を活用した例を追加する。 図 2.5 顧客視点で、ニーズなどを分析するフレームワーク例 15 Case Study IP マトリックス IP マトリックスの具体的例がないため、事例を追加する。 図 2.6 BtoB 卸売業の場合 2.4 ケーススタディ・事例－中小規模の IT 企業 本節では、プロジェクトマネジメントのケーススタディのひとつとしてある中小規模の IT 企業をとりあげる。*3 IT 企業が、大手ベンダーの下請けとしてシステム開発の一部を受注し遂行した経験か ら、システム開発のプロジェクトマネジメントはどうかるべきか、あるいはなぜ教科書 (テキスト) どおりにできないかとういことを、プロジェクトマネージャーの立場で考え る。プロジェクトの概要は次のとおりである。 ■プロジェクトの概要 A 社は製造業で、資本金 3 億円、売上 508 億円 (2013 年度実績) である。特定の製造品 目では、持ち前の製造実績と技術により、自社ブランドで長年トップシェアを維持してき ている。 *3 本節は、渡辺 武久氏によるケーススタディである。 16 IT の導入にも積極的で、メインフレーム全盛の 1990 年代に、将来のパーソナルコン ピューティング時代を見越して、電子メールシステム、営業支援システム等、いまではあ たりまえのシステムをメインフレーム実現したことで業界の注目をあびた。 しかし、その後の ICT の進展はすさまじく、A 社の最先端システムはたちまち化石と なってしまった。つまり、システムの完成度が高く、自社のやりかたがすべて実現できて いるため、時代の急変を取り入れる必要がないという判断から、逆に時代の波に取り残さ れてしまったのである。このような状況を危惧したシステム部長はシステムの全面刷新を 決意し、メインフレームの老朽化対策も兼ねて、オープン系のシステムに全面的に切り替 えた。 新システムは 5 社のベンダーから提案を受け、ERP をはじめとする各種パッケージの 採用も検討したが、最終的には、あるべき姿の検討に早い時期からパートナーとして加 わった最大手ベンダーが「手作り」でシステムを構築することになった。手作りのシステ ムは開発期間や品質において問題が出やすい開発形態であることは重々承知していたが、 最大手にまかせておけば大丈夫との経営陣も含めた安心感から踏みきった。 しかし、油断大敵、システム開発の常識は大手であろうと中小であろうと情け容赦なく ふりかかってくるものである。予想どおり、最終的には納期問題、品質問題、コスト問題 で大トラブルに至ってしまい、結論としてその最大手ベンダーは、自社が開発したシステ ムにもかかわらずメンテナンスから撤退してしまった。 その後、メンテナンスを代替するベンダーがあったこと、自社にそれなりの要員をかか えていたことから、いまでも何とか運用を続けている。 教科書では、プロジェクトマネジメントのスタンダードとして PMBOK を紹介してい る。教科書で「こうすべきである」と述べているのはすべて PMBOK を拠りどころにし ているようである。 現場で苦労しているプロジェクトマネージャー (プロマネ) に言わせれば、 「PMBVOK どおりにプロジェクトが進行できれば何の苦労もない。それができないときにどうするか がプロマネのプロマネたる所以である」ということになる。以降、このような視点から上 記事例をもとに教科書の各項目についてコメントしてゆく。 プロジェクトの 3 つの制約条件 IT システムの開発において、欠かせない制約条件があれば何の苦労もない。それを理 由に他の制約条件をプロマネの意図に従って動かせばいいからである。 しかし、システム開発においては教科書でいう時間にしろ、コストにしろ、スコープに しろ、すべて変動要素なのである。上記事例では、現実的には顧客企業がベンダーと約束 した予算が最も強い制約条件であるはずだが、ベンダーは開発途中の要件変更を顧客に予 17 算の追加が可能かどうかの見極めをしないまま突っ走ってしまい、あとで揉めることに なってしまっている。 スコープについてはベンダーが顧客の企業風土や体質を見越して、かなり膨大なドキュ メントを作成し、目に見えるスコープとするよう努力した。しかし、日本語はむずかし い。ドキュメントの解釈次第でどうにでもなる。顧客はそれがどのレベルで同意されたス コープなのかが曖昧で、結局ドキュメントに記載されたスコープは固定化されなかった。 スコープの流動化、予算の流動化は時間の流動化につながる。この事例は納期、コスト、 スコープのいずれの制約条件もプロマネが管理できなかった、世の中によくある事例で ある。 プロジェクトのライフサイクル プロジェクトのライフサイクル (フェーズ) をきっちり定義し、それに沿った活動と評 価によりプロジェクトをすすめることができれば、プロジェクトに何の問題も起こらな い。事例のプロジェクトも大手ベンダーが手掛けているわけなので、ライフサイクルの定 義、計画は綿密に行われた。実施についてもベンダーなりに評価基準を定め、ベンダー内 の評価を基準通りに行い、顧客への状況報告もしっかり行われた。なのに、なぜトラブル になったのか。 顧客の立場とベンダーの立場で見解は異なる。事例のなかで述べたように、顧客は「最 大手のベンダーだから、多少問題があっても何とかしてくれるだろう、悪い報告は聞きた くない」、ベンダーにしてみれば、 「多少の問題は顧客に押し付けて力で解決すればよい」 という、言ってみればどちらも「甘えの意識」で最終フェーズまでいってしまった。最終 フェーズでふたをあけてみるととんでもない事態となっていたということである。システ ム開発の進捗状況が第三者で評価できにくいという特性を持っていることも影響してい る。「システム開発の見える化」がＩＴ業界の永遠の課題といわれて久しいが、まだ決定 打はない。 プロジェクト憲章で全体を捉える プロジェクトの参加者全員の意識統一のためにプロジェクト憲章を作成しなければなら ないとは、前述の PMBOK の第一歩である。しかし、人間の意識統一ほどむずかしいこ とはない。プロジェクト憲章でプロジェクトの参加者を縛ることはできない。プロジェク ト憲章による意識統一はプロジェクトのトップレベルだけでよい。 プロマネのみが意識しているだけでも十分かもしれない。というより、プロマネはプロ ジェクト憲章を行動基準としなければならない。従って、プロジェクト憲章の作成は必須 18 である。プロジェクトメンバーは、プロマネのプロジェクト憲章に従った行動を見てプロ ジェクト憲章を意識するようになる。 プロジェクトのスコープを明確にする システム開発プロジェクトでスコープが不明確であることはありえない。 なぜかといえば、システムは最終的にプログラム言語でプログラムを記述しなければな らず、スコープが不明確であるとプログラムが書けないからである。ただし、スコープの 定義が「業務的にこのようなことをしたい」という程度の日本語で表わされ、それをス コープというなら、プロジェクとはまだ立ち上がり段階であり、プロマネの出る幕はな い。プログラムで記述する要件が「プログラム仕様書」なるドキュメントで記述されて初 めてプロマネの出番となる。 教科書では必ずしもシステム開発プロジェクトのみを想定しているわけではないので、 世間一般でプロジェクトといわれる組織体ではスコープが不明確でもすすめられるのかも しれない。 WBS を用いて作業を分解する 教科書で言っている「作業」とは何だろうか。 教科書では「WBS はプロジェクトの目標を達成するために必要な作業の概要を示すも のです。つまり、プロジェクトの作業や成果物を含む、そのプロジェクトで実施する必要 のある全作業を表しています」と言っている。 システム開発プロジェクトでどこまで作業を WBS というものに落とし込めるか、落と し込む必要があるか、たとえ WBS を作成したとしても、前述のプロジェクト憲章のごと く、すべてのプロジェクト要員が作業をするときにそれに従うことはまれであろう。この ケースで想定しているシステム開発プロジェクト程度であれば、プロジェクト憲章のごと く、プロマネがプロジェクト要員の作業の標準として参考にするというような使い方にな ろう。そのような使い方しかしない WBS を、工数をかけて作成することは無駄ともいえ る。システム開発企業ではそれにかわる自分に合った手法を持っているのが常識である。 スケジュールを組む 教科書では WBS を作成し、WBS の中身 (アクティビティ) が特定され、それに費やす 日数の予測ができてはじめてスケジュールを組むことができると解説している。 そのようなあらかじめ想定可能なシステム開発プロジェクトは存在しないというのが、 業界の影の声の主流であろう。たいていは、納期から逆算してのスケジュールとなって 19 いる。 教科書の言うように「作業間の依存性 (強制依存、任意依存、外部依存) があるから、や みくもに逆算スケジュールが組めるものでもないが、どこがクリティカルパスになるか は、スケジュールを策定する段階では不明確なことがほとんどであり、プロジェクト途中 での調整を行いつつ最終的に納期に間に合わせるやりかたが現実的である。 リスクのないプロジェクトはない システム開発プロジェクトこそ 100% リスクのないプロジェクトはない。リスクをどう コントロールして、プロジェクトをゴールさせるか。プロマネの出番である。 プロジェクトの実行 教科書では、「プロジェクトマネージャーは成功に向けて、現在の正確な情報をつかん で理論武装しておきます」と言っている。 ケースの冒頭で述べたように、現在の正確な情報がつかめればシステム開発プロジェク トの実行リスクはなくなる。 システム開発は、成果物の完成度が目見見えず、プロジェクトメンバーの報告のみに依 存せざるを得ない特性がある。メンバーの報告の裏の裏まで読めるプロマネでないと、プ ロジェクトのリスクコントロールは難しい。顕在化したリスクをもぐらたたきして何とか 完成に持って行くとういところが現実的なすがたである。 頻出する変更をコントロールする方法 システム開発の最大のリスクである。教科書で教える方法論をすればするほど、システ ム開発プロジェクトは泥沼に入ってゆく。 システム開発には変更はあってはならない。プロマネは変更を阻止することに最大限の 努力を傾けなければならない。変更を余儀なくされるなら、プロマネは「変更だけを別プ ロジェクトとして立ち上げる」くらいの心構えを持たねばならない。 このケーススタディの事例は、ベンダーが「この顧客なら変更をコントロール出来るレ ベルだ」と、顧客体質を甘く見たための大トラブルである。この顧客はシステムの使用者 たるエンドユーザ (特に営業) の発言力が強く、自分の業務のやりかたを変えたなら、即 時、システムも変えなくてはならない。このために会社規模に不相応にシステム部の要員 をかかえているのである。 20 経験と教訓を活かすための終結プロセス 冒頭の制約条件がすべて絶対であれば、プロジェクトの終結プロセスは存在する。 しかし、システム開発に終わりはない。システムの運用段階に至っても、システムの変 更要求は常に存在する。とりあえずの終結は顧客とベンダーの合意のもとで予算が計画通 り無事消費され、対価がベンダーに支払われた段階であろうが、その時点からすでに次の システム開発プロジェクトが始まるのである。 このケースでプロジェクトのその後について述べているが、そのことが、まさにシステ ム開発に終わりがないことを物語っている。 願わくば、すべてのシステム開発プロジェクトが終結を迎えられようにしたいのであ るが。 21 第3章 本活動における考察 3.1 書籍のプレゼンテーション資料作成について 世の中には、良い書籍が多く存在する。研修用のテキストに利用しても良い書籍も多 い。これらの書籍のプレゼンテーション資料があれば、IT コーディネータのビジネス機 会も広がると考える。 しかしながら、書籍のプレゼンテーション資料が容易に見つかるわけでなく、自ら作成 するしか手段がないのではないだろうか。 今回、WG として書籍のプレゼンテーション資料を作成したことにより、次のことが言 えるのではないだろうか。 ² 個々の作業が分担でき、半年の期間で作成できたことで、期間や負担が少なく作成 できる。 ² 事例は過去の経験が必要となるため、複数のメンバーが必要である。。 ² 4～5 名のメンバーであったため、意見が拡散することが少なかった。人数的には、 4 名前後の人数がまとまりやすい。 さらに、結果として、WG 活動において、メンバー同士でいろいろと意見交換や事例説明 を行った結果、書籍についての内容を深く理解できるようになったともいえる。 一方、考慮しないといけない点も見えてきた。 ² 今回のメンバー構成は、IT ベンダ系中心であったが、対象とした書籍では特に問 題はなかったが、取り上げる書籍によっては幅広い業種からの人材が必要かもしれ ない。 ² プレゼンテーション資料であるため、著作権上の問題があり、非公開形式をとらざ る得ない。 22 このような書籍のプレゼンテーション資料作成については、非公開形式であるが、プール できる仕組みがあれば良いであろう。ただし、単に、ID とパスワードでログインできるか らというだけでは、全く不十分である。著作権の壁をきちんと対応していく必要がある。 しかし、これを解決するのは、届出組織単位ではないであろうと考える。 プレゼンテーション資料提供だけで良いのか IT コーディネータに、最早、単に、内容を公開するだけの時代ではないだろう。 内容によっては、成果を正しく受け止める研修が必要ではないだろうか。 今回のプレゼンテーション資料についていえば、資料そのものの説明より、どのように 修整して利用するか、著作権上の問題をどのようにクリアするかなどを理解できたと想 定できる IT コーディネータにしか提供すれば良いのだが、そのこと自体は簡単な事では ない。 思いつく方法としては、研修を開催して、受講した IT コーディネータに提供するとい う方法である。ITC 大阪城としては、この方法が、現状では妥当ではないかと考える。 書籍のプレゼンテーション資料作成は無意味か 書籍のプレゼンテーション資料作成は無意味なのか。決して、そうではない。むしろ、 多くの IT コーディネータが、数人で集まって、多くの書籍のプレゼンテーション資料を 作成して欲しい。 ただし、非公開となるので、この辺をどう流通させるかであろう。例えは、書籍のタイ トル一覧が掲示されており、そこをクリックするとどような種類のものがあり、どこに問 合せできるかが書かれているものである。 3.2 アメリカの「管理職の基本」を学ぶ マネジメントの教科 書の評価 この書籍は、管理職のマネジメントの基本としては、やはり「基本」の内容である。こ のため、過度の期待を持ってはいけないし、高度なマネジメント向けに利用しても役不足 といえる。 しかし、「基本」を手軽に知るためには、丁度良いのではないかと考える。 以下、簡単に、各章について述べる。 第 1 章は、マネジメント入門で、まさしく、基本なので、一般的なレベルでいえば、 「そ の通りでしょう。」と考える。ただし、中小企業のレベルでは、企業によりマネジメント 23 のレベルが異なるので、合わせる必要がある。 第 2 章は、部下の業績管理であるが、人事担当者の範囲まで含まれると考える。 第 3 章は、人材マネジメントであるが、どちらかというと人事担当者向けではないかと 考える。しかし、部分的には、必要と考える。 第 4 章は、プロジェクトマネジメントであり、PMBOK ベースである。PMBOK を 知っていればわかりやすい。IT ベンダ系の人は、説明しやすいと考える。 第 5 章は、戦略思考であるが、以外とページ数が少ない。SWOT 分析などの手法解説 はされているが、例が少ない。今回、どんなものかわかるように、事例を追加した。 第 6 章は、リーダーシップについてだが、チェックシートによる自身の評価と問題社員 への対応等について書かれている。チェックシートで自身の評価をしてみるのであれば良 いであろう。また、問題社員への対応は、研修では受講生が興味を持つところではないか と考える。 全体としての評価は、経験の浅い管理職向けの研修テキストとしては、この書籍は利用 できると考える。ただし、研修する場合は、企業のレベルにあわせて、必要な箇所だけ行 うと良いであろう。 また、書籍だけの座学だけでは少し物足りないので、演習課題を過去の経験から作成さ れて、実施される方がよいと考える。 最後に、IT コーディネータがこの書籍を読んでおいても、決して損はしないであろう。 顧客の経営者や人事責任者から何かよいのはないかと尋ねられたとき、この書籍を紹介 し、研修を提案することも考えられるとよい。 25 参考文献 [1] エドワード・T・ライリー (著)、 渡部 典子 (翻訳)、\アメリカの「管理職の基本」を 学ぶ マネジメントの教科書―成果を生み出す人間関係のスキル"、ダイヤモンド社、 2013。 [2] 独立行政法人情報処理推進機構 (著、編集)\SECBOOKS 共通フレーム 2013"、 独立 行政法人情報処理推進機構、2013。 [3] アレックス・オスターワルダー (著)、イヴ・ピニュール (著)、小山 龍介 (翻訳)、\ビ ジネスモデル・ジェネレーション ビジネスモデル設計書"、翔泳社、2012。 26 タイトル 「マネジメントの教科書」テキスト作成 報告書 発行日 2015 年 1 月 28 日 初版発行 著者 ITC 大阪城 2014 年度 WG 新保 康夫 渡辺 竹久 脇阪 公昭 山中 美智子 岡田 誠司 Copyright ITC Osakajo。 取扱注意 講師用プレゼンテーション資料 ダイジェスト版 ※本資料の取扱には注意をお願いします。 27 28 アメリカの「管理職の基本」を学ぶ マネジメントの教科書 ＩＴＣ大阪城 目次 2015/01/28 • 第1部 マネジメントの基礎的スキルを学ぶ • 第1章 マネジメント入門 • 第2章 部下の業績管理 • 第3章 人材マネジメント • 第4章 プロジェクトマネジメント • 第2部 マネジメントスキルのステップアップ手法 • 第5章 戦略思考 • 第6章 リーダーシップ アメリカの「管理職の基本」を学ぶマネジメントの教科書 29 2 怠ってはならないマネジャーの日々の鍛錬 Essential Management Skills 第1部 マネジメントの基礎的スキルを学ぶ 第1章 マネジメント入門 2015/01/28 1. マネジャーの８つの役割 2. フラット型組織におけるマネジャーのあり方 意思決定のフラット化 意欲を引き出す環境づくり 3. コミュニケーションスキルを磨く ビジネスコミュニケーションの基本 円滑なコミュニケーションのための心得 ４種類の質問を使い分ける より良いコミュニケーションのための３要素 4. 目的別コミュニケーション 回答が難しいメールにどう対処するのか 会議の不満を解消する 会議を効果的にする4つのステップ アメリカの「管理職の基本」を学ぶマネジメントの教科書 30 4 第2章 部下の業績管理 1. 2. 3. 4. 2015/01/28 業績管理は部下と共に行う 目標設定のルールはSMART マネジメントを効率的に行うためのツール モチベーションを引き出す ハーズバーグの２要因理論 職場の不満に対処する モチベーションの源泉を見つける 成長と発展のために権限を委譲する 権限委譲は何故必要なのか 権限委譲の５ステップ 権限委譲してはいけない業務もある 業績を押し上げるコーチング コーチングが必要な場面 コーチングのプロセス アメリカの「管理職の基本」を学ぶマネジメントの教科書 5 第3章 人材マネジメント 2015/01/28 1. 変化に対する恐れを理解する 2. 採用に伴う６の課題 適任者の確保 景気変動 スキルレベルの変化 ロイヤルティとコミットメント アウトソーシング 社内人材の期待 3. 採用活動計画を立てる 効率的な採用活動のガイドライン アメリカの「管理職の基本」を学ぶマネジメントの教科書 31 6 第3章 人材マネジメント 4. 面接の基本 どんな仕事にも共通する一般的なコンピテンシー 職務特有のコンピテンシー 質問スタイルを活用してコンピテンシーを探る 面接用フォーマットの外せないポイント 傾聴スキルを磨く 5. 選定から採用までのガイドライン 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 7 第4章 プロジェクトマネジメント 2015/01/28 1. プロジェクトの３制約条件 『A Guide to the Project Management Body of Knowledge』 の第4版(通称ＰＭＢＯＫガイド)の定義 2. プロジェクトのライフサイクル プロジェクトとオペレーションはどう違うのか 3. プロジェクト憲章で全体像を捉える ステークホルダーを整理する 4. プロジェクトのスコープを明確にする 5. WBSを用いて作業を分解する 正確な予測のためのチェックポイント アメリカの「管理職の基本」を学ぶマネジメントの教科書 32 8 第4章 プロジェクトマネジメント 6. スケジュールを組む スケジュールを共有する 7. リスクのないプロジェクトはない 8. プロジェクトの実行 進捗状況を把握して管理する 9. 頻出する変更をコントロールする方法 10. 経験と教訓を活かすための終結プロセス 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 9 第1部のまとめ • 自己評価 • 生産性がすぐに高まりそうな行動を特定 • 実行する際の優先順位を決める • チームメンバーとー緒に • プロジェクトを成功させた要因を調べる 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 33 10 戦略思考とリーダーシップを発揮する Senior Management Skills 第2部 マネジメントスキルの ステップアップ手法 第5章 戦略思考 2015/01/28 1. 戦略思考は何故必要なのか 2. 戦略的な枠組みを指針とする 戦略的な枠組みの要素 3. 明確なミッションと心を動かすビジョンが変化を起こす SWOT分析を使いこなす 4. ビジョンの戦略的な分析 顧客のニーズ、ウォンツ、期待を知る 重要度と成果の２軸で優先度を測る 5. ビジョンを実現させるコミュニケーション力 アメリカの「管理職の基本」を学ぶマネジメントの教科書 34 12 第6章 リーダーシップ 1. リーダーシップの自己評価 2. リーダーにふさわしい振る舞い 情報の共有 強みを発揮する 意見を求めてアイデアを歓迎する ニーズを承認して対応する 約束を守る 3. リーダーとしての成功を測定する 4. 個人のリーダーシップスタイルを活かす MBTIで自己洞察を深める リーダーシップイメージを高める 5. 権力と影響力を持つ 影響力を行使するための方法 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 13 第6章 リーダーシップ 2015/01/28 6. 賢明な社内政治 政治ゲームに勝つための40の法則 7. 問題社員をやる気にさせる 問題社員の感情をマネジメントする アメリカの「管理職の基本」を学ぶマネジメントの教科書 35 14 第２部のまとめ 戦略的な枠組みを開発 ＳＷＯＴ分析を使う 優先順位を明らかに 自己評価 事実と励ましの言葉を、明快なコミュニケーション 世代的な違いに注意 自分のリーダーシップスタイルを活用 ボディーラングージを効果的に 賢明な社内政治のルールを使えるように モチベーションはリーダーシップの一部である 自分の影響力に留意 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 15 本プレゼンテーション利用の注意 本プレゼンテーションを利用する場合は、テキストとして以下の書籍を講師と受 講生の分を購入し、配布することを条件にします。 エドワード・T・ライリー(著)、渡部典子(翻訳)、“アメリカの「管理職の基本」を学 ぶマネジメントの教科書―成果を生み出す人間関係のスキル”、ダイヤモンド社、 2013。 本資料をテキストとして印刷して利用することは禁止します。 本資料の利用は、上記の書籍をテキストとして講習する場合に投影用のみとし ます。 本資料の一部もしくは全部を複写、引用しないこと。 第三者への提供をしないこと 本Powerpointは、上記の研修を行うＩＴコーディネータ講師のみに配布する。 配布を希望するＩＴコーディネータは、[email protected]宛に 件名 「マネジメント教科書のプレゼンテーション資料希望」 本文に、ご本人であるＩＴコーディネータの氏名、ＩＴＣ認定番号、メールアドレスと 研修に関する情報として研修開催日、研修地、主催者、受講人数をお知らせ下 さい。 お知らせいただいたメールアドレスにPowerpointをお送りいたします。 2015/01/28 アメリカの「管理職の基本」を学ぶマネジメントの教科書 36 16