良い顧客が良いITプロジェクトを作る：開発チームを作ろう（5）（4/4 ページ）

» 2007年09月25日 12時00分 公開
[佐藤大輔，オープントーン]
前のページへ 1|2|3|4 　　　　　　

リリースを前にして

　プロジェクトは6カ月目に入りました。いよいよテストという段階です。プロジェクトの終盤になるといつものように「いまさらフレームワークに改修が入っている」という言葉が「プロジェクトのアラート」として聞こえてきました。実際、ITプロジェクトでは最終段階で顧客が画面に持ち込む「ささいな要求」や「本番に移行を考えて初めて出る不具合」などが次々と出てきました。

　今回のプロジェクトの特徴は「いまさらの改修」によって発生する要件を柔軟に吸収しているということでした。つまり、絶対にぶれないフレームワークを作ったことでもなく、100％の仕様書を作ったことでもなかったのです。変化に柔軟な技術力と即応性の高い開発リソースと、それをテストして機能実装者に配布する「流れ」、つまりプロセスを用意しておいたのです。

　ここでも「ITガバナンス」は力を発揮します。顧客が自身で要件を選別し、かなり的確にビジネス上本当に必要な要件を吸収するように指示をしていたのです。

　システムの中身に最初から深くかかわっている顧客ですから、そういった選別も本当に必要なものに絞り込むことができていました。

　さらに問題点を解決するための決定もスムーズに行われなければなりません。この顧客には問題点の把握・解決策の検討・承認といった、スムーズなプロセスをITガバナンスの一部として持っていました。

ALT 図5 問題解決プロセス

　そしてHさんとそのチームは顧客の要望に常に確実に答え続けました。結果として機能だけではなく、方式やフレームワークの部分をどんどん任されていきました。

Hさんとチームが「すごかった」だけ？

　このプロジェクトの非常に評価できる点が、実質的なPMがSIベンダではなく顧客が自身で行っている点でした。多くのこういった金融の大規模プロジェクトの場合、システムの中身については主要ベンダが請け負う形にしてしまい、中身については把握していないケースをよく見ます。結果としてITガバナンスを喪失して、「最後は大ベンダのいいなり」になっている場合もあります。ところが、会社・業務・事業の最も重要な要素にシステムが挙げられるようになってからは、システムに対して人的資源を十分に配置し、非常に細かい部分まで把握しているケースを見るようになりました。

　実際私が知る範囲で一部上場のある金融企業では、実装のコードまで社員が把握できるようにしていました。この企業のユーザーシステム部門は、各ベンダの技術者の面談も自社の社員で行い、最終的な仕様書はもちろん、コードレビューや中間仕様書のレビューも自社社員で行っていました。

　結果、仕様は画面の各項目の動作ばかりか、ER構造まで把握し、使用されているデザインパターン、フレームワークも平均的な実装技術者以上に把握していました。つまるところ、私が知る顧客の中でもITガバナンスの把握では最高点を付けることができる企業でした。

　往々にして大規模な金融のプロジェクトになると、PMは事業本部長・情報担当役員などが就任することになります。しかし、結果としてPMは形骸化し、そこに付属する組織であるPMOも同じように形骸化します。結果として、プロジェクトの最上部構造は空洞化し、各ベンダのリーダーがPMの役割を果たすケースをよく見ます。

　この状態では、プロジェクトの主体企業が結果としてプロジェクトを把握していないことになります。さらに悪いことに各ベンダという存在は、前述のように、必ずしも顧客と他ベンダと利益や方向性を共有しているわけではありません。

　こうして、本来の責任者は「かじ」を喪失し、かじを喪失した船は座礁の危険が非常に高くなります。あるいは、本格的に座礁はしなくても、プロジェクトの目標を達成する最短ルートは進みにくくなります。

　こうしてITガバナンスは喪失されていきます。

良いプロジェクト

　このプロジェクトはコストやスケジュールに若干のブレは見られたものの、無事完成しました。顧客がITガバナンスを喪失していないことは上述のように、さまざまなプラスを得ました。

  • ベンダの技術者の意見を直接吸い上げることができる
  • コスト、品質、スケジュールが正しく把握できる。PMないしPMOが機能する
  • 評価が直接的なので技術者のモチベーションにも寄与する

　同時にHさんとそのチームは上述では「腐らない」と記載しましたが、

  • 高い技術力で的確にプロジェクトを支援できる。実装を行える
  • 評価が直接的なこともあり、責任を進んで取る

　といったことでプロジェクトを円滑に進めることができました。

　この事例で考えていただきたいのは、例えば、

  • 顧客企業が、システム部門のコスト削減のためにITガバナンスを喪失するほどアウトソースに頼っていないか？
  • 貢献度の高い技術者やチームを評価できるような状況にあるか？
  • その逆に貢献度の低いチームや技術者を把握できているか？ つまり信賞必罰が実行できているか？
  • コストやスケジュールは正しく把握できているか？ ベンダの説明の正当性を評価できるITスキル・ノウハウを持っているか？

　SIベンダに任せているシステムの品質やコストに疑問を持たれるのであれば、こういった視点・ポイントから自社のITガバナンスを再確認してみてはいかがでしょう？ 同時に技術者には評価と責任が表裏一体であることを理解して「プロジェクトから逃げていない」か？ を思い起こしながら、もう一度新しいプロジェクトや、いまのプロジェクトの立ち位置を見直してほしいものです。

◎ 投票：ITプロジェクト運営にユーザーとして一番大事なことは？

筆者プロフィール

▼佐藤 大輔（さとう だいすけ）



「開発チームを作ろう」バックナンバー
前のページへ 1|2|3|4 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ