簡単なはずのプロジェクト管理が難しいのはなぜ? 前回「プロジェクト管理は『簡単なことを、確実に』」では、プロジェクトマネジメントとは次の3つを行うことだと説明しました。 成果の設定 仕事の設計 PDCAサイクルを回すを回す 実際に行うべきタスクは、下図の通りです(図1)。これも、前回お話しした通りです。 これも前回の繰り返しになりますが、プロジェクトマネジメントそのものは、簡単なことを確実に行うだけなのです。 それでは、なぜプロジェクトで問題が続発するのでしょうか? なぜ思った通りの成果が上がらないのでしょうか? 今回は、「なぜプロジェクト管理が難しいのか」を考えることで、プロジェクトの本質とは何か、そしてプロジェクトで発生した問題をどのように解決すればいいのかについてお話ししたいと思います。 プロジェクト管理が難しい本当の理由 プロジェクトマネジメントがなぜ難しいか、その理由は2つありま
賢い発注はウェブサイト制作の正しい理解から こんなクライアントは嫌だ! 制作サイドのホンネから知る“成功する制作の進め方” ユーザーを引き付ける魅力ある企業サイト、思わずため息がでるキャンペーンサイトなど、ウェブでは多くの成功事例を見ることができる。しかし、外から見ると美しく見えるプロジェクトも、紆余曲折を経て達成されることがほとんどだ。スムーズに進む案件の方が少ないといってもいい。なぜこうもスムーズに進まないのか? ネットビジネスの基本であるウェブサイトの制作は、どのように進むのか、うまく進めるためにはどうしたらよいのかを、成功例と失敗例から理解していこう。 よくある4つの悩み事――制作現場には困った問題が山積みウェブサイトはメディアとしてかなり一般的になり、制作現場のコミュニケーションはスムーズになってきた感がある。しかし、それでも日々さまざまな問題に直面することが多い。ここではまず、
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
6月29日金曜日の深夜,テレビ朝日で「朝まで生テレビ」が放送された。与野党の国会議員が出席し,国民年金に関して意見を戦わせていた。 その番組を見ていた筆者は,片山さつき衆議院議員の発言に,思わず起き上がって映し出されている画面を注視した。片山氏は「(新しい年金システムは)数カ月でできる」と発言したのだ。筆者は「どうやったら数カ月でできるのか説明してください」と画面に向かって叫びそうになった。 同時に,筆者は片山氏の「数カ月でできる発言」には何かの根拠があるのではないか,と考え始めた。国会議員,それも自由民主党広報本部副本部長兼広報局長としての発言だから,さすがにまるっきり根拠や確信のないことは言わないだろう,と考えたからだ。 テレビに映し出された片山氏の発言はそこで終わったのだが,隣席の出席者から小声で訪ねられたのだろう,小さな声で「マイクロソフトの…」という片山氏の私語が短い時間流れた。
プロジェクト開発などのスケジュール管理をExcelで簡単かつグラフィカルに作成するマイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機
「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。 この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。 以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。 新しい機能を実装することばかりする たまにバグを修正する 仕様書を書かない ドキュメンテーションを書く手伝いをしない 自動化されたテストを作成しない テスト実行を手助けしない 開発環境を最新に保たな
フリーランスのためのリソースを数多く提供しているFreelance Switchで興味深い記事が・・・。 「あなたがフリーになったときに出会う12種類のクライアント」というものです。「あぁ、こういうクライアントいるいる・・・」とうなづきまくってしまいました。 典型的なクライアントの種類とその対策は以下をどうぞ。フリーになる前に知っておきたい情報ですね。 やたらローテクなクライアント 技術がまったくわからないクライアントです。よくいますね・・・。 典型的な台詞: 「このサイト、いいじゃない!FAXで送っておいてくれる?」 対策: 説明は全て文書で行いましょう。そうでないと何度も説明する羽目に陥ります。また電話や実際に会う機会が多くなるので、その分の予算も上乗せしておきましょう。 興味がないクライアント プロジェクトにあまり興味がないクライアントです。 典型的な台詞: 「あー、まぁ、いいんじゃ
気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 | ログイン 30年余り前、石川島播磨重工業(IHI)に入社した私の初任給は6万8500円だった。その新入社員が、小学校4年生の時以来、久しぶりに使ったソロバンではじいた最初の見積もり船価は245億円。米国の総合エネルギー企業、エルパソ向けの高速型LNG(液化天然ガス)船だった。この船の技術は、IHIとブリヂストン液化ガス(現・三井液化ガス)によるオリジナルのコンセプト(基本概念)に基づいたもので、全社的な大がかりな開発プロジェクトとして進められたのだったが、その1年後、開発に失敗してしまった。 当時、IHIの技術者魂は健全だった。この失敗に懲りず、別のもっと安全で信頼性の高いLNG船のコンセプトを作って、実用化に至ったのである。失敗から10年を超える歳月
1週間(1日ではない)に4時間しか働かない会社社長が、効率的な仕事のしかたの指南をしている講演があった。3月にテキサス州でおこなわれたSouth by Southwestというメディア関係のイベントの中でおこなわれた「The 4-Hour Workweek: Secrets of Doing More with Less in a Digital World」と題する講演である。以下で講演のMP3ファイルが入手できる。 また、このほかの講演・パネル討論の音声はここで入手できる。 講演の概要は以下のとおりである。 講演者 私の名前はティム・フェリス(Tim Ferriss)。プリンストン大学で非常勤講師をし、ハイテク分野での起業にについて教えている。そして、スポーツ飲料・食品の企画・製造をおこなう会社を経営している。世界15ヶ国に製品を卸している。 起業から現在まで 私は2000年に起業し、
先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが
なかなか便利そうなツールのご紹介。 マインドマップツールはいろいろありますが、こちらの「Mindomo」は一味違います。それぞれのバブルをタスクとして扱うことができます。 » Mindomo ある意味、バブルマップとして活用することもできそうですね。バブルマップに関しては下記をご参照下さい。 » バブルマップのすすめ ~ ストレスすっきり解消型ToDo管理手法 ~ | i d e a * i d e a 使い方を下記にご紹介。 ↑ このようなインターフェイスです。 ↑ 一般的なマインドマップツールとして使えます。日本語も通りますよ。 ↑ そして、こちらがタスク管理機能のメニューです。 ↑ それぞれのバブルに期限や担当を入れることができます。 ↑ 各タスクの進行度を表すアイコンも付け加えられます。 もうすぐ新年度。今までマインドマップやバブルマップを使ったことがないという方は、この機会に一度
Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての 「それがないんだったら買わない」機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——「この1個だけ付け加えれば・・・きっとあの連中もおとなしくなってくれる」 しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私
独断と偏見で書き出してみたよ! ■意味もなしにしてはいけない6箇条 ・否定から入る 「違うよそれは????」 ・話を取る 「あ、それ、俺も。俺なんか????」「そういえば、俺さ」 ・結論付ける 「つまり????が悪い」「要するに????ってわけね」 ・相手の感情、意見を軽んじる 「それは考えすぎ」「それくらいで????」 ・言い換える 「というより、????ってことだよそれは」 ・聞き返す 「は?」「そういう自分はどう思ってんの?」 ■相手を喜ばせるための心がけ6箇条 ・相槌を打つ 「それで?」「へえ、どんな様子だった?」 ・細部を褒める 「すげー髪の毛綺麗だね」 ・同意する 「そうだよね」「なるほどね」「わかるよ」 ・謙遜は全力で否定する 「そんなことないよ。痩せてるでしょー」 ・相手の話題にもどす 「さっき言ってた????だけど、それでどうなった?」 ・訊かれた質問を相手にも返す。 「
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
こんにちはmatsudaと申します。 2月に中途でウノウへ入社した新人です。 まだウノウでの体験は少ないので、これまで勤めてきた企業でやっていた会議で、自らの失敗談から学んだ会議を円滑にすすめるための会議術をご紹介します。 頭の片隅にちょっとでも残していただけるのであれば、とてもうれしいですね。 ■時間通りに会議をはじめる当たり前のようでなかなかできないのが時間通りに集まり、会議をはじめることです。ダラダラはじまる会議ほど、ダラダラと会議をする傾向にありました。 ■必ずアジェンダを用意する会議には必ずアジェンダを用意してください。アジェンダのない会議ほどあさっての方向に話題がそれることはありません。簡単なものでいいです。必ずアジェンダを用意するクセをつけてください。 ■冒頭に会議の目的を共有する何のために集まった会議なのか?お互い確認してください。「いや、会議しろと言われたから集まっ
失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント:デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します(2月21日の記事参照)。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない
元の会社や友人たちを見ても、学者や弁護士、エンジニアなどの特殊な世界以外では(実は!そういう世界も同じなのですが)、若き日にもっとも賢かったはずの男たちは仕事人生におけるトップにたっていません。かといって頭の悪い連中が出世しているということでもありません。頭のよさでは、第二集団ぐらいにいた連中がもっとも成功を収めているようです。 もっと卑近な話ですが、私は「ブランド」の共著者である岡康道に比べてIQにして10は上だと思いますが、収入は彼のほうが10倍はあるでしょう(はいいすぎか笑) 学校で教えていると秀才君にたくさん出会います。彼らはいわば学業エリート。入社エリートにも相当程度重なります。人がうらやむ人生の前半を過ごしています。しかし彼らの今後の長い人生行路を考えると、自らの頭のよさとどう対処するのか。これからが大事なような気がします。 彼らへのエール(と自戒)をこめて書きます。 ところで
http://anond.hatelabo.jp/20070224094417 頭のよさを隠して目立たないようにする処世術なんて足枷以外の何物でもないんだよ。それに思い当たったときは愕然としたね。目立つのが嫌だったし、「頭がおよろしいことで」って言われるのが癪だったから、余計な口出しはしないように、しないように十何年も暮らしてきた。その行動は全くの無駄だった。俺はもっと傲慢に、頭のよさを安全に剥き出しにする訓練こそを積むべきだったんだ。 痛いほどわかる。こういうところを早めに悟れるかどうかが、結果を出せるかどうかの境目だと思う。頭が良くてもそれを示せない奴より、多少自信過剰な奴の方がよっぽど使える。それが現実だ。 私は旧帝大の大学院を出た。元々研究者志望だったし、それなりの努力も積み重ねてきた。優秀な奴ばかりが揃っている大学だけれど、研究室に入った頃はホープ的存在だと思われていたらしい。少
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く