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

  • PR

  • PR

  • PR

  • PR

脱出! 暗闇プロジェクト

  • 「正しい解決策だから受け入れられる」は子供の考え

     ユーザー企業A社が進めているシステム構築プロジェクトでの月例会議当日。ベンダー側でプロジェクトマネジャーを務めるN氏は、進捗遅れの説明をしなければならない。いつもは姿を見せないA社の部長も参加するそうで、N氏の上司はそわそわしている。だが当のN氏は平然としていた。(2015/7/15)

  • 安易な「問い」がプロジェクトの破綻を招く

     ユーザー企業E社でのシステム要件定義の場面。システム部門のメンバーが集まってアプリケーションやインフラの設計方針を検討している。その最中に新人がこんな質問を発した。「このインタフェースは標準に準拠すべきでしょうか?」。新人にとっては素朴な疑問である。ところが、この問いに全員が凍りついた。(2015/7/14)

  • 難しい会議でツッコミをかわす三つのセオリー

     様々なステークホルダーが一堂に会する会議を、いかにスムーズに回すか。プロジェクト運営ではこのスキルが欠かせない。特に「暗闇」の状態では、意見がまとまらないだけでなく、勝手な言動や行動を取る人が出てくるのは珍しくない。そんな状況でも会議を回すための三つのセオリーを紹介しよう。(2015/7/13)

  • ユーザーは「無知だが非常に頭が切れる」を前提に臨む

     この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回も現場マネジメントに関するセオリーを取り上げる。決定を急にひっくり返す、相手が非常に頭が切れる、旧来のレビューの進め方を適用しようとする場合にそれぞれどう対応すればよいかを見ていこう。(2015/6/25)

  • 理不尽なユーザーの態度に振り回されない三つの極意

     「我々はITの専門家ではないので」。システム導入プロジェクトで、顧客やユーザーがよく口にするフレーズである。こう言っておくことで、何かあった場合の責任を回避したいとする担当者の気持ちが表れている。ベンダーは、こうした顧客の態度を嫌がるどころか、むしろ歓迎する。(2015/6/24)

  • 多数決で仕様を決めて“炎上”、少数意見に目を向けよ

     新人プロジェクトマネジャーA氏は、「現場ユーザーへの要件ヒアリングは準備が肝心」と考え、質問項目を思いつくまま10個、20個と挙げたリストを持って現場に臨んだ。ところが、その中で使い物になった質問は3、4個しかなく、残りは前提条件が全く違っていたなどで、その場では使えなかった。(2015/6/23)

  • 予期せぬ“危機”に事前に手を打つ秘策

     この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回と次回では、暗闇プロジェクトに役立つ要件定義の進め方を紹介する。この種のプロジェクトでは要件を創作し、合意していかなければならない。今回は、要求仕様に関する二つのセオリーを紹介する。(2015/6/22)

  • パターンが見えたと思ったら危険、「再現性」の追求はNG

     原因や理由、法則性を探究したい。こうした「法則化への願望」は人間の本能とも言えるものだ。しかし要求定義の特に初期フェーズで、「きっと何らかのパターンや法則が見いだせるはず」と考えてはならない。暗闇プロジェクトでは、パターンが見えた、と思ったら危険だと捉えるべきだ。(2015/6/4)

  • 「客観的なデータ」は幻想、定量データは必要悪

     プロジェクトマネジメントでは、定量データに基づく管理が重要になる──。教科書の多くは、このように説明している。だが、暗闇プロジェクトでは、こうしたデータにこだわることがかえって足を引っ張るケースが少なくない。「数字」に振り回されずに、現場での調査結果をどのように整理・分析すればよいのか。(2015/6/3)

  • 矛盾している回答はむしろ歓迎、ダメな「武器」も時に役立つ

     ユーザー(仕様ホルダー)からシステムに対する要求を計画通りに取得・整理できている。とても望ましい状況のように思えるが、暗闇プロジェクトではリスクの兆候と捉えるべきである。「暗闇」に挑戦しているのではなく、頭の中にでき上がっているテンプレートを現場に当てはめている可能性が高いからだ。(2015/6/2)

  • 情報は「質」より「量」、ヒアリングで「なぜ」は禁句

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回と次回は、現場における要求定義の心得に焦点を当てて、六つのセオリーを紹介…(2015/6/1)

  • [ベンダー姿勢編2]意思決定に「内政干渉」する

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回に続いて、ベンダーの姿勢に関するセオリーを取り上げる。(2015/5/28)

  • [ベンダー姿勢編1]「政治的」な見積もりを受け入れる

     「暗闇プロジェクト」では、事前に詳細なプランを立てるのは困難。サイコロを振ってでも、とにかく行動を起こすことから始めたい。プロジェクトに参加するベンダーは、「政治的」に決まった見積もりをあえて受け入れ、対応していく姿勢が大切だ。(2015/5/27)

  • [ユーザー対応編2]合理性は創作してもよい

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回に続いて、ユーザー対応に関するセオリーを取り上げる。(2015/5/26)

  • [ユーザー対応編1]二者択一からは「逃げる」

     「暗闇プロジェクト」では、利用部門をはじめとするステークホルダーとの不毛なやり取りはできるだけ避けたい。相手が選んだ選択肢で二者択一を迫られたら、とりあえず即断即決を避ける。厳しい発言は割り引いて聞く姿勢も大切になる。(2015/5/25)

  • [メンバー管理編2]「完璧な報告書」は疑え

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介する。今回は前回に続いて、メンバー管理に関するセオリーを取り上げる。(2015/5/22)

  • [メンバー管理編1]情報を隠すのは逆効果

     「暗闇プロジェクト」を効率よく進めるには、教科書的なやり方とは異なるメンバーマネジメントが欠かせない。プロジェクトに関わる情報は全て共有。メンバー管理はあえて「放置プレー」で問題ない。(2015/5/21)

  • [マネジメント編2]実践しない課題管理から脱却

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介する。今回は前回に続いて、マネジメントに関するセオリーを取り上げる。(2015/5/20)

  • [マネジメント編1]モジュールは「人間関係」で分割

     この連載では、先の見えない「暗闇プロジェクト」でトラブルに陥らないための実践的なヒントやノウハウを紹介している。暗闇プロジェクトではリスクを見極め、必要なら即行動に移す姿勢が欠かせない。システムのモジュールを「人間関係」を基に分割するといった“非常識”な施策も大いに有効だ。(2014/12/19)

  • [プロジェクト運営編2]不安は解消せずにうまく付き合う

     現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回に続いて、プロジェクト運営に関するセオリーを取り上げる。(2014/12/18)

ITpro SPECIALPR

What’s New!

経営

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

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

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

セキュリティ

もっと見る