• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

脱出! 暗闇プロジェクト

  • 計画策定時に上司の「おもり」にかかる工数をバッファーに組み込む

     IT企業に勤める若手のW氏は、あるプロジェクトで顧客の担当者であるY氏と親しくなった。仕事の受注者と発注者という関係であり、立場の違いから時に激論を交わすこともあった。しかし、年齢が近いこともあり、「互いに協力して、プロジェクトを成功に導いていこう」との意識を共有しつつ、強い信頼関係が結ばれている…(2016/5/13)

  • 上司の誤った判断は「正解ではない道」、あえて従うのも手

     パッケージソフトベンダーQ社でマネジャーを務めるL氏は、つい最近までSEとして開発に携わっており、製品の中身に詳しい。現在の仕事は半分営業のようなものだ。全国のユーザーを回って、個別の要望を確認・対応したり、オプションやバージョンアップを勧めたりしている。そんななか、遠方のユーザーがカスタマイズ対…(2016/5/12)

  • 正直に報告するのはかえって危険、トラブルの悪化を招く

     ソフトウエア事業部門の事業部長に昇進したばかりのF氏。初のマネジャー職に、やる気満々である。同時に強いプレッシャーを感じていた。社長から「何か新しい飯のタネを育ててくれ」と言われていたからだ。F氏は新しいことに挑戦するよりも、定められたレールの上をきっちり走って堅実に実績を上げる方が得意だった。(2016/5/11)

  • 会社で最重要のルールはどこにも書いていない、でも知らないと反感買う

     IT企業N社のトップが掲げるスローガンは「顧客満足第一」。通常は、現場のマネジャーが真に受けて実際に行動するケースは少ない。顧客満足第一を徹底して実践すると大赤字になり、上から雷が落ちるのが分かりきっているからだ。ところが真面目な若手マネジャーのD氏は、このスローガンを忠実に実践しようと努めた。(2016/5/10)

  • エンジニアの常識はマネジャーには「非常識」、意識を変えないと地雷踏む

     この連載では、先が見えないプロジェクトを「暗闇プロジェクト」と呼び、この種のプロジェクトを担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。顧客以上に厄介で面倒なのは、社内関係者のコントロールだ。今回からしばらく、マネジャーが知っておくべき社内コントロールの心得を紹介する。(2016/5/9)

  • プロマネが学ぶべきは「自分のやり方」

     G社のプロジェクトには、よく言えば「個性派ぞろい」のメンバーが集まっていた。別のプロジェクトでは「問題児」とされていた人たちだ。いくら人が足りないとはいえ、通常は問題児ばかりのメンバー構成は避けるものである。しかし、G社の経営層は「当たればもうけもの」くらいに考えて、プロジェクトにゴーサインを出し…(2016/1/21)

  • 時に相手をだましてもいいが、だまされるな

     だますな、だまされるな。これは日本の総合商社における古くからの教訓だという。商売を続けるうえで、人から信用されることは非常に重要である。一方で、信用されてもだまされているばかりでは商売が続かない、ということだ。プロジェクトマネジメントではどうか。イカサマの例を四つ挙げてみよう。(2016/1/20)

  • ジャイアン、スネ夫、のび太---誰を目指すべき?

     社内の雰囲気が「緩んでいる」と感じた某IT企業の部長。外部からコワモテのマネジャーA氏を連れてきた。周囲はA氏に対して「とにかく怖い」との印象を抱いた。怒鳴り散らすからだけではない。頭の回転の速さや仕事の知識の豊富さで、社内にかなう者がいなかったからだ。社内はこれまでにない緊張感に包まれた。(2016/1/19)

  • ぶっちぎりの勝利は自己満足の妄想

     「今日の午後4時までに見積もりが欲しい」。あるベンダーは顧客企業P社からこんな要求を受けた。時刻は午後3時。猶予は1時間しかない。ベンダーはP社に半年以上通い詰めて、営業活動を進めていた。受注に向けて、周辺のキーパーソンも固めつつあった。急な見積もりの要求を受けたのは、そんな矢先だ。(2016/1/14)

  • 成功したやり方を、次のプロジェクトであえて捨てる

     ある顧客向けプロジェクト。顧客側の窓口はC課長とD係長が担当していた。システム開発を請け負ったベンダーが顧客と打ち合わせる際は、主にC課長の反応を気にしながら進めた。このC課長、とにかく細かい点にこだわる。ベンダーが準備した資料に対し、必ずと言っていいほど「~の場合はどうするのか」と指摘した。(2016/1/13)

  • 方法論は正しくなくてよい、大切なのは「使えるかどうか」

     ユーザー企業A社のシステム構築プロジェクト。ベンダーが納品する成果物全てに、対し、事実に基づくエビデンスを求めた。結論の根拠となる出典は何か。根拠がオリジナルのものであれば、どんな実績があり、正しいことをどう証明するか。A社はこれらを常に要求した。(2016/1/12)

  • メンバーさえ揃えば、プロジェクトはもう折り返し地点

     あるプロジェクトでプロジェクトマネジャーとしてA氏とB氏の2人を配置した。「ダブルPM」の体制である。A氏は数々の資格を持ち、肩書きや経歴も申し分ない。文書や資料の品質も頭抜けている。これに対し、B氏は無資格で、肩書や学歴にも特筆すべき点はない。文書や資料を作成するのもあまり得意ではない。(2015/12/10)

  • 「共有する」「合意する」「徹底する」は禁句

     「体制」「会議体」といった名詞からは、動きや変化は感じられない。「計画」にも固定化したイメージしかなく、変化するという意味合いは含まれていないように感じられる。だからこそ「計画は修正されるべき」といった言い方になる。だが実際のところ、イメージ通りに動きや変化がないかというとその逆である。(2015/12/9)

  • 生き残るのは「賢いハチ」でなく「愚かなハエ」

     口が開いた瓶を横にして、ハチとハエを入れる。底の部分に光を当てると、賢いハチは光が当たって明るい瓶の底を目指す。普通、明るい方には出口があるからだ。一方、愚かなハエはただひたすら動き回る。あちこち瓶の壁にぶつかりながら、(ハエは自覚していないだろうが)様々な試行錯誤を繰り返していく。(2015/12/8)

  • 「曖昧さ」はプロジェクトを前に進める重要な方便

     一般に、システム開発での曖昧さは「トラブルを引き起こす主要な原因であり、何が何でも排除すべき存在」である。大昔から、この問題に対する数多くの手法や技法が開発されてきた。 問題は、曖昧さを無くそうとして理想にのっとりプロジェクトを進めようとすると、一向に前に進まなくなってしまうことだ。(2015/12/7)

  • 役立つのは「高い専門家」よりも「安い素人」

     暗闇プロジェクトでは「次」を予想するのが非常に難しい。吹雪におけるホワイトアウト状態と言ったら言い過ぎだろうか。当然、計画通りに進むことはない。シナリオプランニングにおけるシナリオを設定できるのであれば、「暗闇」としては相当に見通しがよいことになる。(2015/10/29)

  • 参考書を手当たり次第に手に取り、無視する

     ユーザー企業S社の大規模プロジェクト。運営組織は多くの専門チームで構成していており、その一つに計画の作成・更新の専門チームがあった。計画チームの役割は計画の作成・更新だけ。計画を作成するまでは大変だが、一旦作成したら後は暇になるだろうと考えていたが、実際は違った。(2015/10/28)

  • 品質、納期、費用、機能のどれかをバッサリ切る

     暗闇プロジェクトが、自社の実験的なパイロットプロジェクトとして始まるとは限らない。顧客相手の通常の契約形態のプロジェクトが「暗闇」である場合もある。開発を請け負うシステムインテグレータにとって、契約の内容次第では非常にリスクが大きいプロジェクトとなる。(2015/10/27)

  • プロジェクトが支離滅裂? そんなことは当たり前

     この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回からしばらく、プロジェクトの最初期の段階である準備・構想段階での心得を見ていく。「どうせダメに決まってる」と言われているプロジェクトをうまく立ち上げるセオリーを見ていく。(2015/10/26)

  • 「理屈」の人でも意思決定の99%は「感情」で行う

     この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前回は、プロジェクトを進める際に顧客のコンセンサスを取っていく際に役立つセオリーを紹介した。今回はその続きである。顧客との合意を取り付けるのがいかに難しいか、実感していただきたい。(2015/9/10)

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

設計/開発

サーバー/ストレージ

ネットワーク/通信サービス

セキュリティ

もっと見る