何の問題もなくプロジェクトが成功することはないといっても過言ではない。ここでは、実際にプロセス改善に成功した事例を取り上げ、そこから見えるプロセス改善のポイントを読み解いていく。
プロジェクトマネジャーに贈るプロセス改善事例 第1回
いざ顧客の環境にシステムを配置したところ障害報告や問い合わせが殺到し、結局サービスインに間に合わなかったということはないだろうか？ X社では、自社の失敗経験を生かしてその問題を解決した。
プロジェクトマネジャーに贈るプロセス改善事例 第2回
プロジェクトの開始直前、予定していたエンジニアがアサインできない事態に遭遇した経験はないだろうか。今回は、実態に合わないプロジェクト計画が原因でプロジェクトの失敗を招いたY社の改善事例を紹介する。
プロジェクトマネジャーに贈るプロセス改善事例 第3回
プロジェクトでツール導入やその検討をした経験があるだろう。その有用性は理解できるが、業務の妨げになると疎まれることもある。今回はツールを効果的に導入し、構成管理上の問題を解決した事例を紹介する。
プロジェクトマネジャーに贈るプロセス改善事例 第4回
見積もった計画の通りにプロジェクトを遂行することは難しいが、その精度が低いとプロジェクトの失敗や顧客の信頼失墜に直接つながってしまう。今回は顧客と協力して見積もりプロセスを改善した事例を紹介する。
プロジェクトマネジャーに贈るプロセス改善事例 第5回
開発プロセスや成果物の標準化、そのドキュメント作成に関わった経験があるだろう。しかし、それらは今どうなっているのか？ 書棚の奥でホコリまみれになり、その存在自体が忘れ去られていたりしないだろうか。
プロジェクトマネジャーに贈るプロセス改善事例 第6回
オフショア開発は言語や文化の違いによって成功しにくいといわれる。しかし、本当に原因はそれだけなのか？ 全社レベルでのオフショア開発の推進を目指し原因を調査したX社は、別の理由があることを突き止めた。
まずは受け入れテストの見直しから
「ベンダー任せのシステム開発からの脱却」は難しい。だが、情報システム部門の組織力を段階的に向上させることで、その実現が可能になる。H社が実施した改善策は、まず「受け入れテスト」の主導権を握ることだった。
開発側とユーザー側の慣れを排除する
システムの保守開発は、対象システムが移行または廃棄されるまで連鎖して続く。開発側とユーザー側の双方が慣れてしまいがちな保守開発を“やっつけ”にしないためには、一体どうすればよいのだろうか？
現役プロジェクトマネジャー連載コラム
システム開発の現場は今、どのような状況なのか？ 本連載コラムでは、現役のプロジェクトマネジャーが、日々の管理業務を通して気付いたことや感じたことを「Twitter」のように“つぶやいて”いく。
ITmediaはアイティメディア株式会社の登録商標です。
