間違った見積り

前回に引き続き、「プロジェクトが遅れる理由」。

今日は「間違った見積り」についてです。

これも良く聞かれる遅延理由ですね。

「プロジェクトが走り出してみると、提案の際に出した工数や期間では全然足りないことがわかった」という感じです。

これにはいくつか理由が考えられると思います。

例えば、こんな感じです。

（1）RFPには必要最低限の機能しか書いていなかった。

（2）価格競争になったため、やむを得ず値段を下げて提案した。

（3）プロジェクトの責任を負わないエンジニアが提案を担当した。

一つずつ見ていきましょう。

まず、（1）ですが、これは提案の時よりも要件が増えているということです。

どれくらい追加されたかにもよりますが、大幅に増えてしまった場合、提案時の見積りのまま開発すれば、当然赤字になりますし、納期に間に合わせるのも難しくなります。

よって、この場合は、プロジェクトの初期で要件を再度確認して、もし追加が大量にある場合は、

･追加コストを請求する

･フェーズ分けをして、別提案とする

などの対処が必要です。

それでも、顧客から「当初の見積りでやれ」と言われたら、そのプロジェクトから降りることも考えるべきだと思われます。

難しい決断ですが、失敗することが見えているプロジェクトを続けることに意味はありませんから。

次に、（2）ですが、これは「値段を下げてまで取る決断を会社がした」ということですから、そもそも赤字覚悟のプロジェクトになります。

この場合、プロジェクトを任された時に、会社に対して「ここまで赤字になって当然ということを認識してくれ」「可能であれば、赤字分を会社から補填してくれ」という要求をする必要があると思います。それをしないと、自分やメンバが人柱になってしまいます。

そして、最後の（3）ですが、これが一番多いかもしれません。

提案時の担当エンジニアがプロジェクトに責任を持たないとどうなるか。

そのエンジニアは受注を評価されますから、当然少なく見積もった方が受注率は上がることになります。

これでは、いつまで立っても見積りは正しくなりません。

私は、提案に関わった人がプロジェクトまで責任を持ってやり遂げるべきだと思っています。少なくとも、プロジェクトマネージャが提案の最終段階で見積りを承認することが必要です。

それでも、もし見積りが間違っていたら･･･。

納期に関しては、上にも書きましたが、顧客と交渉してフェーズ分けをしてもらう、などの交渉が必要になります。

そして、工数に関して。

私は今の人月計算による工数算出は正しくないやり方だと思っています。

（ファンクションポイント法などの見積もり方はありますが、提案時に機能抽出までやるのは難しいかもしれません。）

工数算出については、また後日詳しく書きたいと思います。

なぜ要件は決まらないのか

今日は昨日に引き続き、プロジェクトが遅れる理由の一つ

「要件がなかなか決まらない」

について考えてみたいと思います。

日本のシステム構築では、いまだにウォーターフォールモデルを採用しているベンダやインテグレータが多いように思います。

そして、要件定義フェーズでは、顧客の要件を正確に定義し、プロジェクトのスコープ（責任範囲）を明確にすることが重要とされます。

しかし、要件定義は顧客からのアウトプットに左右されるため、顧客の時間が取れなかったりすると、要件がなかなか定義できず、開発に入れないという問題が出てきます。

ここで、いつも疑問に思うのは、

「要件定義が終わらない＝開発に入れない」

というのは正しいのか、ということです。

確かに、プロジェクトのスコープが明確にならないまま、開発を走らせることはリスクが高いと言えるかもしれません。

でも、そのシステムを受注する前に、提案フェーズでシステム概要は決めたんじゃなかったでしたっけ？RFPが出て、その実現方法を書いたからこそ、受注したんですよね？その概要を元に、ある程度基礎的な部分は開発を開始してもいいような気がしますが･･･。

提案書を書いた人と、プロジェクトマネージャが別人？

それは、言い訳です。

本来は、同一人物（もしくはチーム）が提案書から入るべきですが、それが難しい場合でも、きっちり情報共有すればいいはずです。

開発を始めてしまうと、細かい要件に対応できない？

基礎的な部分から始めれば十分対応できるでしょうし、そもそも細かい要件に対応可能なように設計すればよいのでは？

顧客だって、いりなり最初に「全部決めて下さい」と言われても、時間もかかるでしょう。急かされて決めても、後で落ち着いて考えたら、要件が変わるかもしれません。

そういった顧客の事情まで汲んだ形で、プロジェクトは進めるべきと考えます。

昨日と今日で、私が言いたいことはだいたいおわかりいただけたんじゃないでしょうか。スピードが要求される昨今のシステム開発には、ウォーターフォールモデルは合わないんじゃないでしょうか。

そこで、注目されているのが「アジャイル開発」です。

「アジャイル開発」のメリットについては、後日改めて書いてみたいと思います。

なぜ要件は変更されるのか

昨日の続きとして、今日は

「なぜ要件は変更（追加）されるのか」

について、考えてみたいと思います。

開発が中盤から終盤に差し掛かって、定義した要件が変更されたり、追加されたりすることで、プロジェクトが遅れることは実際によくあることです。

私も何度も経験があります。

これを一般的には

「顧客のわがまま」

と捉えることが多いように思います。

また、

「何でも安請け合いするプロジェクトマネージャに責任がある」

という意見もよく聞きます。

そして、対処方法としては、

･要件の変更（追加）は断固として断る

･どうしてもというなら、追加注文をもらって、別フェーズで開発する

というのが一般的です。

が、本当にそれでよいのでしょうか。

よく考えてみると、「変更（追加）された要件」は、

「アプリケーションの核となる部分（例:会計アプリなら会計機能自体）」

ではなく、

「ユーザインターフェース」

「応用機能」

「運用関連機能」

といった枝葉の部分であることが多いように思います。

そして、これらが変更される理由としては、

･プロジェクトは短くても数ヶ月かかるため、その間に組織やビジネスモデルが変更される

･IT部門主導でプランを作成してきたが、現場（実ユーザ）から異論が出た

･実際にできあがったソフトウェアを見ると、使い勝手が悪かった

などが考えられます。

顧客も、「わがまま」で要件を変更（追加）しているわけではないように思います。

また、「変更（追加）を断る」ことに関して。

「プロジェクトの目的」は何でしょうか。

「定義した要件を忠実に開発する」ことでしょうか？

私は違うと思います。

プロジェクトの目的は、

「実ユーザがソフトウェアを使って、効果を出すこと」

であるべきです。

納めたソフトウェアが実際に使われなければ、納期とコストを遵守しても、そのプロジェクトは失敗ではないでしょうか。

そのためには、多少の要件変更（追加）にも応えるべきだと思います。

「だったら、結局プロジェクトが遅れていいのか」

と言われるかもしれません。

そうではなく、

「要件変更（追加）に応えることができるプロジェクト管理」

は実現できないでしょうか。

これについては、また後日考察してみたいと思います。

プロジェクトが遅れる理由

プロジェクトによってもたらされる「デスマーチ」。

その最大の原因が「プロジェクトの遅延」です。

では、なぜプロジェクトは遅れるのか。

よく聞かれる理由を挙げてみましょう。

（1）要件が変更（増加）された

（2）要件がなかなか決定されなかった

（3）バグが多発した

（4）見積りが誤っていた

（5）エンジニアの質が悪い

（6）メンバが途中で離脱した

これらの理由について、明日以降、毎日1つずつ考察していきたいと思います。

他にも、思い当たる理由があれば、ぜひ教えてください。

はじめに

私は、IT業界に身を置く30代のシステムエンジニア（SE）です。

これまで、

・外資系ハードウェアベンダ

・独立系システムインテグレータ

・ベンチャー系ソフトウェアベンダ

と渡り歩いてきましたが、どこの会社でもプロジェクトの過酷さは同じです。

SEになったら最後、

十分な睡眠や楽しい休日は潔く諦め、

会社とプロジェクトに身を捧げなければならない。

ある者は恋人を失い（経験有）、

ある者は子供の記憶から消え、

ある者は過酷な業務の余り精神を病んでリハビリ生活･･･。

それでも、SEは「デスマーチ」に身を委ねなければならない。

本当に、それでいいんですか！！

SEは「知識労働者」です。

今のような「肉体労働」をしていては、良いシステムは産み出せません。

私は、SEとして、SEを若者が憧れる職業にしたい。

そのためには、プロジェクトのあり方を見直す必要があります。

このブログで、少しでもプロジェクトに構造改革をもたらし、

全てのSEに幸福な日々が訪れる手助けができることを願ってやみません。