連載
» 2007年09月25日 12時00分 UPDATE

開発チームを作ろう(5):良い顧客が良いITプロジェクトを作る (1/4)

「人」に視点を当て、普遍性を持ったプロジェクト運営プロセスを探り出す連載の第5回です。

[佐藤大輔,オープントーン]

 前回「すごい技術者はすごいマネージャになれるか?」は、優秀な技術者だったGさんが初めてのマネージャ経験で、さまざまな技術者とマネージャの役割の違い、難しさに直面する事例に触れてみました。その中でも技術者とマネージャの立場で最も大きな違いの1つである見積もりについて皆さまと検討してみました。

 前回の記事を踏まえ、見積もりの難しさを検討するうえで、以下のような質問をWeb投票を通じて読者の方々に聞きました。

 「見積もりの土台が「機能の数」だとして、次に「工数」に影響する最も大きい要素はなんですか?」

ALT 図1 見積もりの土台が「機能の数」だとして、次に「工数」に影響する最も大きい要素はなんですか? (総投票数:33)

 以上の結果を見ると、営業的事情が圧倒的な1位ですね。「予算」という枠を超えるのは難しいことです。ただ、常々業界の事情を見ながら改善すべきだと思っているのは、そういう営業的な見積もりと技術的な実際の工数は分けて管理されなければいけないということです。少なくとも社内では「本来の見積もり」で管理されないことにはプロジェクトの効率化、開発標準やプロセスの構築のしようもありません。また、費用は営業的に「まける」ことができますが「時間」はどうしようもありません。特にスケジュール(納期)を満たすためには、営業的事情は排除して見積もる必要があります。

 ちなみにアンケートの「ご意見」の中でも同じ指摘が数多くありました。

 「見積もりが実際の作業時間を意味しているのか?」

 「顧客に出す金額を意味しているのか?」

 個人的には、このことが検討されること自体に意味を感じています。先ほどの例のようか混同の結果、開発チームやマネージャが効率性について、追及をされても責任の負いようがありません。ですので、開発者に限らず、開発組織そのものから、顧客まで見積もりと予算の意味について考えていただければ非常にうれしい次第です。

 次に票数が多かったのがチームの質です。確かに通常「人月」で計算されるITシステム開発はチームの質が劣れば、どうしても人数と時間が増えために必然的に費用が増えてしまいます。

 ほかにいただいた意見は、

  • 「すべての相互関係」
  • アーキテクチャがあまりにかみ合っていない場合に大きく悪影響を与えることから「アーキテクチャ」
  • 納品物そのもの(テスト仕様書の数や粒度・回数、網羅性など)を決めるので「ミッションクリティカル性」

などが挙げられています。

 手法では、FP(ファンクションポイント)がやはり多く、一部でCOCOMOIIが用いられているようです。余談ですが、私もFPとCOCOMOIIを組み合わせて使用しています。

 皆さま貴重なご意見を誠にありがとうございました。

 さて、いままで開発チームやプロセスを「人」(ある特定の個人)を中心に分析することで、開発チーム・組織の在り方を探ってきました。その中で、前回のアンケートのご意見の最後にありました「顧客の理解」は非常に興味深い題材です。今回は「理解ある顧客」がどれほど良い影響をプロジェクトに与えるかをそこで活躍したHさんに焦点を当てて説明してみます。

       1|2|3|4 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -