 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| プロジェクト成功の定義は「ユーザが納得する」こと | ||||||||||||
|
プロジェクト管理は難しいものです。大規模には大規模なりの、小規模には小規模なりの困難があります。ウォーターフォールでもアジャイルでも難しいことには変わりがありません。しかし、どんなプロジェクトにも成功はあります。 成功の定義として筆者が最重要視するのは、ユーザが納得することです。この連載では、ユーザに納得してもらえるプロジェクト管理の実際を、現場で使える管理ツールとあわせて紹介します。 |
||||||||||||
| ユーザ企業と開発ベンダー間のギャップ | ||||||||||||
|
大手小売業C社のシステム部門に勤める結佐（ゆうさ：34歳）氏は、これまで大手システムインテグレータで流通業界のSE経験を積んできたが、小売業の奥深さに引き込まれ、3年前にC社に転職した。 そこでは現行システムの保守にはじまり、レガシー更新プロジェクトのサブリーダーを務めていた。そしてこの春、ようやくある新規サービス立ち上げのシステム側プロジェクトリーダーにアサインされ、やる気に満ちているところである。 このプロジェクトを支える開発ベンダーR社のプロジェクトマネージャは、R社内でもエースと呼ばれている弁田（べんた：31歳）氏だ。結佐氏と弁田氏はこれまでのプロジェクトでも一緒に苦労した経験があり、お互いに信頼できそうだという感触を持っている。 今回の開発では新規サービスであること、基盤チームにR社パートナーのS社が初めて関わることから、これまで以上に困難が予想された。そしてその分、気合いも入っている。  図1：C社の新プロジェクト体制図（システム部門のみ） （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| プレキックオフでの会話 その1 | ||||||||||||
|
2人は新プロジェクトをはじめるに当たり、これまでの経験の振り返りと今後のプロジェクト運営の方針についてプレキックオフ（という名だが、実態は飲み屋での会議）を行うことにした。話をはじめたのは、弁田氏である。 弁田「これまで、それなりの数のプロジェクトをこなしては来たんですが、いつも最初はのんびり、最後は死にものぐるいになってなんとか間に合わせる、というケースが多かったですよ。PMBOKや自社の方法論も、それだけでは現場になじみませんし。ただ、前回のプロジェクトは、少しうまくいった気もしています。それがなぜなのかはまだはっきりしないのですが……」 結佐「そうですね……そんな感覚は私も持っています。これまでのやり方だと、提案書にはいいことが書いてあるのですが、いざキックオフをすませて作業を開始すると、何をしてくれるのかわからないまま1ヶ月が過ぎて……なんとなく要件定義書ができて、見積もりが変わりましたといわれ、なんとか決裁を通したのもつかの間、開発がはじまると今度は遅れるといわれ、ハードネゴの末かなりの機能を削ってなんとかサービスイン、というのが少なくない。弁田氏には耳の痛い話かも知れないですが、我々としては、この手の話は永遠に解決しないんじゃないかと思いつつ、なんとか解決したいわけですよ」 弁田「はは……いや、笑い事じゃないですよね。ただ、我々の側もいい加減にやっている訳じゃないことはわかってほしいです。最初はまだ要求もよくわからない話に、なんとか受注するために多少脚色して、様々な提案をしなければならない。受注したらしたで今度は何でもやってくれると期待され、いざ要件定義してみると、話が違う、という位に要件がたくさんでてくる。なんとかとりまとめて開発する間も、機能が増えた、画面が変わった、が絶えることがない。1つ1つは簡単でも、全部あげるとすごい量です。これをなんとか優先度順に落としながら動くシステムにしなければならない。我々もプロなので、意地でもサービスインには間に合わせるんです」 結佐「私も同業だった頃を思い出しますよ。熱気のこもった部屋でテスト項目のレビュー、寒いサーバルームでパフォーマンス計測……つらいですよね。けど、ユーザの立場になってわかったこともたくさんあるんです」 結佐氏は少し熱くなってきたようだ。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
