ホーム / Eric Anderson

Eric Anderson

Eric Anderson is a staff writer for CAI's Accelerating IT Success. He is an intern at Computer Aid Inc., pursuing his master's degree in communications at Penn State University.

September, 2015

  • 18 September

    プロジェクトマネジャーが犯す3つの大きな過ちとは?

    プロジェクトマネジャー達は、プロジェクトチームのやる気を引き 出すこと、プロジェクトの利害関係者から協力を勝ち得ること、自分たちの努力にふさわしい結果を得ることに今もなお苦心していることが分かったと、プロ ジェクトリーダーシップのコーチを務めるスザーン・マッドセン(Susanne Madsen)は述べています。マッドセンはブログの中で、通常であれば非常に知能的に高いプロであるプロジェクトマネジャーでも苦心の種となる3つの大きな過ちを挙げています。 最大の過ち プロジェクトのチームメンバーを率いるのではなく、プロジェクトのタスクを管理してしまう 焦点が重要課題ではなく緊急を要する問題点に当てられてしまう 全ての問題点の解決に対応してしまう プロジェクトマネジャーがタスクを割り当ててスケジュールを作成することに集中すれば、そのプロジェクトは多分に成功することになるでしょう。しかし、何故このプロジェクトは重要なのかだとか、実際の人たちにどんな影響を及ぼすのだろうか、などとプロジェクトマネジャーが考えめぐらしたりしていると、誰か他の人によって創り出されたビジョンをプロジェクトを通して形あるものにすることではなく、ただ単にビジョンを実行することだけになってしまいます。 プロジェクトは期限厳守で遂行されるものです。集中力が奪われて しまうような問題点が発生すると、本来焦点を当てなければならない問題点に対する注意集中が置き去りにされてしまします。プロジェクトマネジャーは、翌月 のプロジェクトを正式に戦略化しなければならない時間を確保しようするがために、イーメールされてきた緊急の問題発生を無視することに罪悪感を感じるかも 知れません。しかし、マイナーな問題点が発生する度に果敢にそれらの問題点を回避しようと努めることによって「忙しそうに見える」という悪循環に陥ってし まうと、プロジェクトを苦しめるより深い問題点に対応するための時間を確保することは何時まで経っても永遠にできないくなってしまうでしょう。 もう一つの共通の過ちは、プロジェクトマネジャーはすべての回答 を欲しがり、すべてをコントロールしたがることです。このような進め方をすると、プロジェクトマネジャーはあらゆる決定を同時にすることになってしまい、 疲労困憊してしまうことは避けることはできません。更には、このようなやり方は、プロジェクトチームの個々のメンバーが自ら問題を解決し、全体の負担を 個々が負担するという理想の姿とは裏腹に、プロジェクトマネジャーから次の指示が来るまで何もしないで立っているというように、チームメンバーから個々の 権限を奪ってしまうという逆効果を生む結果となってしまします。 原文(英語)を読むには:http://www.pmhut.com/what-are-the-3-biggest-mistakes-that-project-managers-make

  • 18 September

    問題解決戦略のいろは

    問題をうまく解決するには、実戦と集中が必要であり、それはいざという時にはかけがえのないものになり得るものです。ブルース・ハーファム(Bruce Harpham)は問題解決のための戦略の「いろは」を説明しています。新しい考え方を取り入れる心があれば、以下のことを学ぶことができるでしょう。 い-人間関係の影響を見極める 人は断固たる行動を取る前に、まず立ち止まって全体像を把握する ことを常としなければなりません。「全体像」をリスク管理に当てはめてみると、そこには人間関係が伴いますとハーファムは述べています。考慮しなければな らない重要な人間関係として、家族、同僚、組織、そして利害関係者があると列挙しています。問題が発生したとき、助けとなる最大の拠り所、そして身を最大 限に守ってくれることになるのは自分自身ではなく、自分の周りにいる人たちなのです。 ろ-警報を発する 組織に当てはめてみると、最大の力はコラボレーションから生み出 されるものであり、またこの文脈における「自身」とは個人ではなく、むしろビジネス自体のことを指しています。その意味では、周囲の助けを求めることは、 ウイルスの侵入と戦うために免疫系が助けを呼び出すことに似ています。協働することにより、障害を乗り越えることが可能となるのです。 は-カレンダーを変える 一日の全体の仕事のうち40%しか予定をたてないソーシャル・メディアの専門家クリス・ブローガン(Chris Brogan)の識見をハーファムは引用しています。「多くの人たちは自分たちの人生を[それとは逆に]生 きていると思います。」とハーファムは言い、「通常は、一日の120%を予定に入れて、いつも取り乱したように動き回り、完全にてんてこ舞いだと感じてい ます。」とも述べています。難しいように思われますが、最も重要な仕事の回りに緩衝材を入れることによって、予期しない問題が発生したときに対応できる時 間の余裕が生まれるものなのです。 原文(英語)を読むには:http://projectmanagementhacks.com/problem-solving-strategy/#sthash.RfLj2AcK.7diuAs3r.dpbs

  • 18 September

    交代エージェントとしてのプロジェクトマネージャー

    プロジェクトマネージャ(PM)は、変更の触媒です。そのため、リンダ・ボーンが、PMの変更を管理するために必要とされるさまざまな方法について説明します。 任意のPM 変更の最初のステップは、プロジェクトのスポンサーと変更マネージャーの責任を決定することです。その後、伝統的な変更管理は、新製品の開始のために、古 い製品から離れるに強い関心を培養するため、すべての利害関係者を準備する必要とする、起こります。それは、異なるスキルセットを必要とするため、2番目 のステップは、変更マネージャーではなく、PMの仕事です。 プロジェクトの活きを通じてのプロジェクトマネージャーの責任は変更マネージャーのニーズを認識し、利益を実現する機会を最大化するために、プロジェクトの作業を適応させることです。 プロジェクト変更管理プロセスは、PMが管理するための重要な「もの」です。そのプロジェクトチームのサポートの上で、PMが行う必要があります。 変更の特定:その変更は、必要とされるのか。もしくは、以前に発生したかどうか。 プロジェクトの目標に反面する効果が無いかを確認及び理解する。 変更に係る提言を準備する。 この変更を承認できる立場にいる人を見つける。(プロジェクトマネージャー、スポンサー、変更管理委員会   等) 確証と変更権限をサポートする。 承認または適切な変更をブロックすることにより、変更の結果を管理する。 変更管理と変更管理の違いは何であるか: 変更管理は、変更を管理するプロセスです。複数の変更は、単一の変更管理プロセスに沿って管理することができます。覚えておくべき重要な点は、アイデア、それがもう一方の端に出てくるときに利害関係者のニーズを満たす必要があり、プロセスの一端に入るということです。 (英語で)元の記事を読んでください。http://www.projectmanagement.com/blog/Voices-on-Project-Management/11493/

  • 18 September

    偉大なプロジェクトマネージャのトップ10の特徴

    デビッド・C・ベイカー氏 はプロジェクトマネージャー(PM)のトップ2%になり、アンディー・クローが運営する研究について、’99U’のために書き込んでいます。 860のプールのうち、クローは、最高資質のトップ10に表示されています。 自然権威:リードする彼らの傾向が深く根付いており、彼らの永遠の楽観主義は、他の人の助けれるか。 •高速優先順位付け:データであふれた今の業界では、トップのPMは一瞬で学習する必要があるものだけを学ぶために、迅速で情報を取捨選択します。 焦点と再評価: 彼らは、必要ないE-メールの削除や、ミーティング、個人的なデータの入力など、様々なプライベートで大事な企業秘密を任せれていることを知っている。 仲間と華族へ: 最終PMは、どのような利害関係者との相互作用を最大限に活用する方法、また、彼らはコミュニケーションのスタイルを受信する方法を知っています。 公然に通信する: トップPMは、任意の責任を引っ張らないでください。むしろ、彼らはスタッフとの共同作業者との通知を保つために、明確で直接的な通信経路を取ります。 通信の制御: 偉大なPMは、プロジェクトの初期段階での成果にかわるコミュニケーションの予測可能なスケジュールを持っています。 適用された経験を保持する: 彼らは深くその電荷中の分野に精通し、戦略的優位性とリーダーシップの機会にこの知識を回します。 競合/コンセンサスのマスター: 本当に素晴らしいPMは、重要な取り組みから引き下がることなく、コンセンサスと拡散の競合を構築することができる。 社交通信者: 情報ネットワークは、それらのソースでプロジェクトへの脅威に対処するために、組織内と外で栽培されています。 仕事を愛す: 最大のPMに、プロジェクト管理のキャリア、報酬と課題は、同一です。 元の記事を読んでください(英語) ): http://99u.com/articles/6946/top-10-characteristics-of-great-project-managers

  • 18 September

    モーレツ社員の結末は最悪のリーダー?

    トップに上り詰めるためには、毎日を最大限に頑張って働かなければならないと思ってはいませんか?実は、どこかの時点で息抜きすることが大事なのですと、ハーバード・ビジネス・レビュー(Harvard Business Review)のロン・フリードマン(Ron Friedman)は勧めています。息抜きをすることによって、マネジャーやリーダーとしてのキャリアを生き残ることができるのです。それは以下のような理由からきています。 エグゼクティブ・コーチであるマーシャル・ゴールドスミス(Marshall Goldsmith)は自著の中で、自らのゴールに「取り憑かれる」ようになってしまうかのように常軌を逸した優れた業績を上げる人たちのメンタリティには賛成できないと述べています。それには、勝つことにこだわり過ぎたり、付加価値を付けることにこだわり過ぎたりする変わった考え方も関与していることもその中で述べています。問題は、成功することの価値ではなく、自分のキャリアの中で更に成功を収めるには息抜きすることが必要になる場合に、息抜きをすることができないことにあるのです。 結局のところ、身体的にも精神的にもストレス過剰となり、人と人との対人関係を処理する能力が欠けてしまうことにあります。専門能力において百戦錬磨のビジネス戦士が一旦は勝ち抜いたとしても、職位が上がるにつれて、今度は人との対人関係の手腕がものを言うようになってきます。フリードマンはそのことを次のように説明しています。 私たちは組織の中にあって職位が上であればあるほど、複雑な意思決定を迫られるようになります。研究の結果次のようなことが明らかになっています。不確実な状況の中をうまく舵取りしながらリスクに対応していかなければならない場合、私たちは疲れていると判断力が極端に落ちてしまいます。判断の選択肢が多くなればなるだけ、より多くのエネルギーを体内に蓄えておく必要があります。しかし、働き過ぎや働き過ぎから来る睡眠不足により問題点を明確に捉えることができなくなり、また創造的な問題解決策を見出すことができなくなってしまうのです。 原文(英語)を読むには: https://hbr.org/2014/12/working-too-hard-makes-leading-more-difficult

  • 18 September

    突発事象管理を始めるための6つの秘訣

    突発事象管理(IM)はミステリーではありません。IT専門家であるジョーが述べているように、何故IMをするのかは、実際にそれを行うのと同じくらい重要なことなのです。それは必要性から来るものであって、単にプロトコルから来るものではないのです。ジョーは自分のブログの中でIMを始める上での正しいやり方と正しい理由について6つの秘訣を説明しています。 「聞こえがよい」と理由でIMをしてはならない。 多分既にIMを行っている。 IMをする理由を考える。 IMをプロセスとしてではなくサービスとして見る。 専門用語に注意する。 顧客の目線で捕らえる。 IMを満たすべきプロトコルとして捕らえると、このことが分かります。ITはIMを顧客に対して外部的に提供するものとして使うため、そのことが何故それほど大きな意義を有するのかを理解することがまず重要です。正式なプロセスというものがない場合でも、大抵のビジネスとそれぞれのIT部門は、パスワードをの再設定、機能停止、その他不都合なハプニング等々、不可避な事態に対応する必要が出て来るために何らかの形のIMが必要となります。 [「何故IT管理をしているのだろうか?」という質問に対する]回答が、「ITが故障したときに直すため」であるなら、その質問についてもっと時間をかけて、もっと真剣に考えてみることを勧めます。突発事象は、技術的欠陥やITサービスが利用できないことなどよりもそれ以上のことであることは明らかなことではないですか? ジョーはITをプロセスとして見るのではなくサービスとして見るように勧めています。プロセスというものは人がその背後に回り、そのプロセスを使って顧客に優れたサービスを提供するためのものです。さらには、ITには「突発事象」があってしかるべきものなのでしょうか?勿論突発事象というものはITの中で管理しているものなのですが、顧客の観点からすると、それらは問題又は故障ということになります。経験則から言えば、IT専門用語を決して顧客に押し付けることがあってはならないということです。さて、IMにすっかり夢中になってしまう前に覚えておかなければなならなことは、あなたがしたいことをするのではなく、お客様が本当に必要としていることを実行することだけということです。 原文(英語)を読むには: http://www.joetheitguy.com/2014/12/05/12-tips-for-getting-started-with-incident-management-part-1/

  • 18 September

    対人能力とあなた

    私たちは多くの場合、対人能力というものはただ単に自分の履歴書に詰め込むようなものと考えがちです。実際にはその逆が真実なのです。対人能力はビジネスの世界では俗に言う土台となるものなのです。ミッシェル・ラブロッセ(Michelle Labrosse)は、そのような人との付き合い能力を磨く方法について幾つか助言を与えています。 対人能力は重要であり、プロの組織でもその重要性を認め始めています。これらの能力の中で最も重要なのは多分、リーダーシップ、チーム作り、そして動機付けであると思われます。対人関係に長けた人というのは、他人に恐怖心を植えつけるような手段を取らなくとも信頼感を勝ち得ることができ、それぞれに一番適した役割に人々を配置することができ、また動機付けとなるような様々な奨励策を適用することのできる術を身に付けているものなのです。 上に述べたような特質というもの全てには更に、効果的なコミュニケーション、正しい意思決定をする習慣、そして人に影響を与えかつ人を説得する才覚も求められます。適切なコミュニケーションというものは、どのようなチームであってもそのチームを固く結び付けるものであり、それは影響力というものが人を動機付けさせることができる人の重要な特性であるのと同じものなのです。 一人の管理者として注意を払うべきものの大半は対人能力にあるという論点を強固にするということは、他の重要な特質の大部分に匹敵することでもあるのです。人は世界の様々な問題点、即ち会社の権力闘争や文化を認識しなければなりません。人はまた、国際的な大使のように同僚たちの間に信頼感を築き上げ、軋轢をなくすよう努めなければならない一方で、異なる意見を認め合い、また業績の悪い人たちを優秀な業績へ引き上げるために指導しなければなりません。 原文(英文)を読むには: http://www.qualitydigest.com/inside/quality-insider-column/interpersonal-skills-and-you.html

  • 18 September

    ITプロジェクトが失敗する3つの要因

    ITプロジェクトに対するビジネス要件は、「永遠に続くものを作り上げる」から「変更できるように設計する」へと目的が変わり、その結果、状況が複雑化してしまい、プロジェクトが憂慮すべき頻度で失敗する事態が生じています。パール・チュー(Pearl Zhu)はブログの中で、プロジェクトの失敗は3つの根本原因に起因するとしています: スポンサーのエゴ ロスの忌避 確率の無視 スポンサーというものは往々にして、成功する可能性を犠牲にしてでもプロジェクトが失敗しないように舵取りをしようと試みるものです。その理由はただ単にリスクを避けるという単純なものであるかも知れませんし、或いは、スポンサーが個人的利益を得る目的でプロジェクトを操作しているためのものであるかも知れません。別のシナリオとしては、プロジェクトのスポンサーが全ての必要とされる変更に喜んで関与し、監督するけれども、それは最初のうちだけというような状況です。それは、時間が経過するにつれて、スポンサーのプロジェクトに対する興味がその意気込みと後押しと共に薄れてしまうというものです。 顧客のためにプロジェクトを成功させると言うことは、言うは易し行なうは難しです。成功するための適切な物差しなくしては、プロジェクトチームは暗闇の中で火を灯すようにもなります: 必要とする要件、プロジェクトマネジャー、悪しき規範等々全てを列挙することはできますが、結局のところ、次のような3つの要因が絡み合ってプロジェクトは失敗に終わります:専門知識の欠如、停滞した又は時代遅れのIT能力、そして会社全体にわたるコミュニケーション体制が機能していないことが挙げられます。 ITプロジェクトの30%が完全に失敗すると推定されています。またプロジェクトの70%までが顧客の期待に応えることができないとも言われています。プロジェクトのリスクを適切に分析することは、失敗を防止するための第一のステップであることは勿論のことです。結局のところ、信じられないことが実際に発生してしまうことは避け得ないものであると言えるでしょう。 原文(英語)を読むには: http://futureofcio.blogspot.com/2015/01/three-aspects-of-it-project-failures.html

  • 18 September

    リスク管理: 何を、何故、及び方法

    先を見越したリスク管理をする時に来ています。それは、結果を前もってコントロールしようとすることを意味しています、とマイケル・スタンレイは書いています。最善のリスク管理であっても、ある特定の結果を保証することは不可能ですが、少なくとも起こり得るネガティブなインパクトを和らげることはできると言えるでしょう。 実際には、リスクを管理することは初心者の段階に過ぎません。プロのレベルにある専門家は、リスクを適当に数量化し想定されるインパクトを描き出すというダイナミックなシステムに基づいたリスク管理を行っています。潜在的なリスクが特定されると、チームはこれまでのデータ、過去の実績、及び直感を含む様々な要因に基づいて一つ一つのリスクに優先順位を付けていきます。スタンレイは更に次のように述べています。 …機会とリスクは通常プロジェクトの計画の段階では相対的に高いところにあります…しかし、この時点では投資は相対的に低いレベルにありますので、リスクとなる金額はまだ小さいままになっています。逆に、プロジェクトが実行段階にあるときは、未だ不明とされる事柄が判明されるに従い、リスクは漸次そのレベルが下がっていきます。同時に、プロジェクトが完了されるために必要なリソースが漸次投資されるに従って、リスクとなる金額は上昇していきます。 あなたのチームがリスクに対応するようになった時点では、3つのオプションがあります。リスクの原因を取り除くことによってリスクを排除すること、リスクが発生する可能性を低くすること、又は、リスクの可能性を受け入れ、リスクが発生した場合のリスク管理計画を準備することが挙げられます。 原文(英語)を読むには: http://www.pmhut.com/risk-management-the-what-why-and-how

  • 18 September

    ITプロジェクトを打ち切るのは最後の手段としてのみ

    それはプロジェクトマネジャーが考慮する最後の手段ですが、プロジェクトがコントロールできない状態に陥った場合は、最初に考慮されなければならないことです。メリー・シャックレット(Mary Shacklett)は何時の時点で問題となっているプロジェクトを打ち切るのかについて書いています。とは言え、関係者に打ち切りを告げる以前に、その問題のプロジェクトを生かすことのできる次善策や予防対策を考えることが必要です。 大きなプロジェクトが倒れてしまうことはよくあることです。いつのかの時点において、プロジェクトマネジャーは関係者に対して、「事態は悪くなっています。しかし、この破滅状態を救うためにできることはあります。」と勇気を持って告げなければならない時があります。思慮深いプロジェクトスポンサーであれば、状況を理解しプロジェクトマネジャーと共に事態を切り抜けようと試みるものです。 危機に陥っているプロジェクトを再起動させるための別のアプローチとしては、まずプロジェクトを前に進めることを一旦停止し、少し時間をかけてプロジェクトであるソフトウェアをバーチャル化してみることも挙げられます。バーチャル化することによって関係者に最終製品が現実的にどのようなものであるかを見てもらうことには多くの利点があります: 最終ビジネスユーザーが完成したソフトウェアの「承認テスト」を実施する時点になると、テストの後でITのところに戻って来て、「これは我々が期待していたものとは全く違うではないか!」と言うような場合は結構あるものです。そのような時点までには、相当の予想と期待が既にでき上がってしまっていますので、プロジェクトマネジャーの進退問題にもなりかねません。 現実には、ソフトウェア開発プロジェクトの実に45%が目標を達成することができていません。ソフトウェアが完成する以前に、プロジェクトのスポンサーにソフトウェアが完成した場合の姿を簡単に説明しておくだけでも、相当の時間と様々な資源を節約することが可能であることを考えてみると、このような統計は非常に破滅的なものであることがわかります。 原文(英語)を読むには: http://www.techrepublic.com/article/pull-the-plug-on-an-it-project-as-a-last-resort/