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

  • PR

  • PR

  • PR

  • PR

脱出! 暗闇プロジェクト

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

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

  • 顧客の意思決定プロセスを「把握できた」と考えるのは大甘

     SIerのエンジニアであるS氏は、ユーザー企業Q社に半常駐状態。客先内で最も技術に詳しいこともあり、便利屋として何かと重宝されている。今回も変な割り込みが入ってきた。「そっちにITに詳しい人がいるそうだね。この件を見てほしいのだけど」との依頼があり、S氏の部署の部長は二つ返事でOKを出した。(2015/9/9)

  • 顧客満足度は自ら高める、受け身の考え方は捨てよ

     ユーザー企業大手のA社では、これまで社内の各業務部門が独自にシステムを構築するのが当たり前だった。さすがにA社内でも、このような状況を問題視するようになり、システムを企画・構築する上で標準化すべき領域については、システム部門に一括して権限を集約することになった。(2015/9/8)

  • システム要求を出すのは「会社」ではなく「個人」

     システムの目的を明確にすることは、プロジェクトの初期段階での最重要課題だ。若手プロジェクトマネジャーのB氏はプロジェクトの冒頭で、顧客企業X社に「システムの目的を教えてもらえますか」と確認した。先方の答えは「業務の効率化によって、顧客サービスの向上を図る」というものだった。(2015/9/7)

  • 「あり得ない選択肢」を数合わせで入れるのは極めて危険

     ユーザー企業R社は東日本と西日本に大規模なコールセンターを持つ。大昔からの歴史的な経緯で、それぞれ異なるベンダーの顧客管理システムを導入した。背景には複雑な政治的な問題があり、その問題を解決してシステムを統合するよりも、システムを別々に構築したほうがよいと判断した。(2015/7/16)

ITpro SPECIALPR

What’s New!

経営

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

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

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

セキュリティ

もっと見る