［課題管理編］重い課題のまま管理してはいけない
課題管理表に、どう対処すればいいか分からない「重い課題」が載せられていたことはないだろうか。例えば高いソフトウエア品質が求められるプロジェクトにおいて、納期が迫った時点で、データ連携する外部システムのインタフェース仕様が急遽変更になり、システムの機能を大幅に改修しなければならなくなったとする。その際、「一定の品質を確保しつつ、短期間で機能を改修する」という課題が発生する。 そんな重い課題を課題管理表に載せてメンバーに任せたところで、「外部システム担当者と検討会議を開く」のようなもっともらしい解決策が書き込まれるかもしれないが、解決への道筋は示されていない。結局は解決されずに放置される可能性が高い。PMは、重い課題のまま課題管理表に載せてはいけないのだ。 ロジックツリーで課題を掘り下げる 重い課題である場合、課題管理表に記録する前に、具体的なアクション（解決策）にまで掘り下げることが大切だ。
［課題管理編］ツールを押し付けてはいけない
課題管理に向くサーバーソフトやGoogleドキュメントといったクラウドサービスなど、便利なツールを手軽に利用できる環境が整ってきた。そうしたツールを使うと、効率よく課題管理ができる。 しかし、ツールを導入しさえすればうまくいくとは限らない。特に、複数の開発現場を担当する「掛け持ちプロマネ」にとって要注意である。 掛け持ちプロマネは、それぞれのプロジェクトの管理業務に十分な時間を割けないもの。そこで「ツールでカバーしよう」と考え、課題管理のツールを現場に導入し、メンバーにツールを利用してもらって管理の効率化を図ろうとする。そして、ついメンバーにツールの利用を任せきりにしがちになる。 確かにツールは便利なものだ。だが、それを現場に押し付けてはいけない。 入力の煩わしさなどでツールが使われず このことは筆者の実体験から言える。以前に筆者が担当していたあるプロジェクトでのこと。そのプロジェクトでは
［課題管理編］問題を課題と勘違いしてはいけない
プロジェクトマネージャやリーダーにとって、課題管理はこなすのが当たり前の仕事だ。ところが現実には、この課題管理をうまく行えていないために、プロジェクトの進行に悪影響を及ぼしていることが少なくない。 課題管理がうまくいかない最たる原因は何か。そういったプロジェクトを支援することが多い筆者の経験から言えるのは、課題管理の方法（How）ではなく、管理すべき課題（What）に誤りがあるからだ。つまり、そもそも管理する「課題」の定義が正しく行われていないのだ。課題ではなく、現場で発生している事象である「問題」を管理していることがとても多い。 ここで言う課題の定義とは、「目的を達成するために解決すべき事柄」である。つまり課題管理で扱うのは、プロジェクトのメンバーが「次にどのような手を打つべきか」を検討したり実施したりできる内容になっていなければならない。 この違いを明確にするために、例を挙げよう。「仕
［変更管理編］変更の影響を軽く見てはいけない
「少し変更するだけだから…」。ユーザーや、仕様策定に携わるITエンジニアは、こういう言葉で、変更作業を担当するITエンジニアに、仕様変更の指示を出しがちだ。この言葉からは、「変更による影響は、軽いものだと思いたい」という、指示する側の気持ちが透けて見える。 しかし、変更の影響を軽く見てはいけない。システムは内部で深く関連し合っていて、1カ所の変更が多くの箇所に影響を及ぼすからだ。また、変更することで新たに作りこまれるバグが発生するといった、品質面での影響も考慮しなければならない。 そのため、たとえ影響が少ない場合であっても、その範囲が限定的であることを調査・確認したり、ドキュメント類を修正したりしなければならない。ユーザーや上級SEにとっては大したことがない変更でも、変更作業の担当者には大変な作業なのである。影響は、変更する上でかさむ作業量だけにとどまらない。 また、川が上流から下流に行く
［変更管理編］変更管理をExcelでやってはいけない
皆さんの現場では、変更管理にどのようなツールを使っているだろうか。SubversionやMicrosoft Visual SourceSafe（VSS）といったツール名をすぐに思い浮かべるかもしれない。しかしそれらは構成管理ツールであって、変更管理のためのものではない。「変更構成管理ツール」と称される製品も多く、混同しがちなので簡単に整理してみよう。 変更管理ツールは、ユーザーなどから変更依頼を受け付け、影響度や優先度を評価し、実施するかどうかを判断するためのもの。実施が決まった変更依頼には、作業指示の情報を加え、作業のステータスを管理することも含まれる。 一方の構成管理ツールは、成果物（ドキュメントやプログラムソースなど）の変更に応じてバージョン管理したり、複数のITエンジニアが同時にアクセスしてもデグレードしないように排他制御を行ったりする。つまり変更管理では変更依頼を管理するのに対し
［変更管理編］コストの話を後回しにしてはいけない
ITエンジニアとしては、スケジュールが圧迫されてコストもかさむ仕様変更はなんとか避けたい。ところが利用部門の立場で見ると、変更は正義である。仕様を変更しないよりも変更した方が、システムは良くなるからだ。それゆえ、「変更しなければ業務が大変なことになってしまう」といった、変更を求めるユーザーの説明には説得力がある。 このとき、ほとんどのITエンジニアが用いる交渉の切り札は納期だろう。コストも切り札として有効なのに、「コストの話をするのは卑怯で汚いような気がする」と感じて、コストの話を後回しにしがちである。 しかし、変更する/しないという交渉の場で、コストの話を後回しにしてはいけない。ITエンジニアにとって劣勢を挽回する最大の切り札はコストだからだ。「変更依頼をシステムに反映させるとしたら、これだけコストがかさむ」という反撃をすると、ユーザーはひるまざるを得ない。 そもそも納期は、交渉をする切
［コミュニケーション編］議事録を相手に任せてはいけない
議事録を一度も書いたことのない読者はいないだろう。おそらく誰もが新入社員時代に書き方を教わる文書で、誰もが書くのに苦労する文書である。一所懸命時間をかけて作成した議事録を上司や先輩に持って行ったら、真っ赤になって返ってきたという経験をした読者も少なくないはずだ。議事録とはビジネスに無くてはならない文書の一つで、それはシステム開発プロジェクトにおいても同様である。プロジェクト内で作成する数多くの文書の中で、議事録ほど数多く作成される文書はない。 初めてPMに抜擢された中堅社員Sさんの経験 Sさんは大手通信企業の情報システム部門で働く中堅社員である。若い頃はプログラマとして働き、数年前に社内SEとなり実績を重ねてきた。そして今回、自社のシステム再構築に当たり、初めてPMとして抜擢されたのだった。 今回のプロジェクトは開発規模が比較的大きいので、大手SIベンダーのB社と一緒に開発を行うことになっ
［外注管理編］協力企業との作業の進め方を曖昧にしてはいけない
システム開発プロジェクトで協力企業に仕事を依頼する場合、どのように作業を指示しているだろうか。契約形態が「一括請負契約」であれば、発注仕様書に基づいて、後は全て相手の会社にお願いするという方法になるだろうが、「準委任契約」「業務委託契約」「派遣契約」ではそうはいかない。一括請負契約の場合は成果物責任があるが、それ以外の契約だと成果物責任が無いので、作業の進め方を曖昧にしていると高い生産性を期待できない。 小規模システムのPMを任されたAさんの場合 Aさんはこれまで幾つかのプロジェクトにメンバーとして参画してきた。Aさんのキャリアパスを考えた会社が、そろそろステップアップをと考え、今回、小規模のシステム開発プロジェクトのPMを任せることになった。 これまでAさんが携わってきたプロジェクトはいずれも数百人月クラスの大規模プロジェクトで、開発フェーズを協力企業に一括発注することが多かった。だが、
［外注管理編］協力企業への査定をおろそかにしてはいけない
PM（プロジェクトマネジャー）の大事な仕事の一つに、協力企業の「査定」がある。この査定には通常2種類ある。一つは、協力企業から提出された見積もりの妥当性を調査・検証すること。もう一つは、協力企業の行った仕事・成果を検証し、支払った金額に見合うものであったかどうかを判断することである。 後者の査定は結果が全てを物語っているので比較的容易だが、前者の査定はこれから始まるプロジェクトに対するものなので、判断は難しくおろそかにしてしまいがちである。特に長年一緒にやってきた協力企業の見積もりとなると、そうした傾向は強くなる。 十分な信頼関係が醸成された協力企業の見積もりの場合、相手を信頼するが故に、その根拠について根掘り葉掘り問いただすことは少ないかもしれない。しかし、こうして査定をおろそかにしてしまったばかりに、痛い目に遭ったPMがいるのもまた事実である。 中堅社員Tさんの失敗 Tさんは30代も半
見えてきた危機対応での「やってはいけない」
プロジェクトで危機的な状況に直面したとき、やってはいけないことが少なからずある。日経SYSTEMS5月号（4月26日発行）の特集記事「プロジェクトの危機 その時どうする」の取材では、このように感じる指摘を、ベテランのプロジェクトマネジャー（PM）から受けることができた。 特集記事で取り上げた危機的な状況には、「震災の影響によってプロジェクトが進められない」といったものに加えて、コストオーバーや納期遅延、品質の低下というものを含む。このとき、どのように対応すればよいかを、「人が足りない」「時間がない」「タスクが山積み」といった状況ごとに紹介している。 記者はこの特集の事例取材で、コストオーバーや納期遅れ、品質の低下といった危機的状況での対応を、主に担当した。これらの危機的な状況は、PMやリーダーが「順調に進んでいる」と思っている中で、急に判明することが少なくない。このとき、プロジェクトはかな
［品質編］小さな異常を見逃してはいけない
システム開発プロジェクトにかかわらず、普段の仕事のなかで時折「ん？」と、思考が一旦止まってしまうことがある。その時によって多少変わるが、「これは何かおかしくないか？」「大丈夫かな？」と感じているのだ。 そのほとんどがちょっとした疑問であり、取り越し苦労で終わることも少なくない。しかし、そのちょっとした疑問を放置したために、後々になって取り返しのつかないことになってしまうケースが存在するのもまた事実である。 この思考が一旦止まる「ん？」というポイントは人それぞれである。全く気がつかずに通り過ぎる人も入れば、一旦立ち止まってはみたものの「大したことはない」と通り過ぎてしまう人もいる。どんなに小さな疑問であっても、「念のため手を打っておこう」と取り上げる人もいる。 そうした「ん？」が、プロジェクト運営に全く影響を及ぼさないささいなことであれば問題ないが、そうでない場合には小さいながらも「異常」と
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
