2021年1月12日火曜日

入札提案の実際(2) 工数計算と進捗報告

技術点は必要条件、価格点は十分条件と前回紹介しました。価格点に少なくないウェイトを占めるのが工数です。進捗報告の基準にもなる工数計算ですが、みなさん自信ありますか?


工数計算は設計屋の仕事です。では、プロジェクト企画、計画作りは?プロジェクトマネージャーの仕事ですね。プロジェクト計画の根幹である工数計算をプロジェクトマネージャーが検証できる能力、経験があればよいのですが、なかったとしたらどうでしょう?設計屋の計算をそのまま採用するのでしょうか?それでは品質管理の基本要素であるダブルチェックが効いていないことになります。

プロジェクトの品質管理はどれだけ正確にタスクを洗い出し、工数計算を行い、リソースとのバランスからスケジュールを立てられるかにかかっています。それがシステムの品質を決めることになります。議事録、要件定義書、設計書、プログラムなど個別成果物のレビュー、ダブルチェックも重要ですが、プロジェクト計画が妥当なものでなければ、個々の努力も水泡と化すでしょう。

品質管理プロセスは重要です。プロジェクトの最初の品質管理は、プロジェクト計画に対して行います。この時点で成否は半ば決まります。

工数計算ですが、設計者自身が複数の方法で自己検証します。積み上げ法と経験法ですね。ダブルチェックは積み上げ法の要素分解の妥当性を検証します。もちろん経験的に工数が大きく逸脱していないかも見ますが、大きな逸脱があるなら設計者自体が問題です(アサインミスです)。

プロジェクトマネージャーは自分自身で要素分解を行い要素毎の工数を見積もります。安全バッファーなどを考慮し最終的なスケジュール、工数とします。工数計算はスケジュール、進捗管理と連動しています。しっかり移行、総合試験、受け入れ検証の期間をおさえることが重要です。

工数が膨れる要因は上流工程にあります。プロジェクト計画の具体性・現実性、要件検討会の運営、要件定義から基本設計にベテランをあてられるか、にかかっています。

開発スタッフの単価、人数で、基本設計のまずさは取り返せません。はじめが肝心です。納期、品質で取り返しのつかないことにならないようにしましょう。

EVMで進捗報告を行うことがプロジェクト管理の要求要件になっている入札案件もあります。正確な工数計算とプロジェクト計画、なおさら必要ですね。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から

2021年1月7日木曜日

入札提案の実際(1) 技術点は必要条件、価格点は十分条件

入札提案の実際はどんなものなのか?開示できる範囲で紹介したいと思います。

一般競争入札では入札公告前に意見招請が行われることがある。
仕様ないし入札条件について質疑、意見発言ができる重要な場である。

入札金額と技術評価

入札は安く札入れをした提案者を落札者としますが、入札方式も種類があります。システムでは総合評価方式をとることが多いのでその紹介をします。
総合評価方式では
総合評価点=価格点+技術点として、総合評価点の最も高い提案者が落札します。
見当違いの提案者が安値で落札されても困るので、提案内容も評価するというものです。
技術点は評価表が公開されますので、それに従って加点されていきます。ただし必須要素というものがあり、これが提案書に記述されていないと失格になります。
価格点は次の式で決まります。
価格点=入札価格に対する得点配分×(1-入札価格/予定価格)
ただし、入札価格が予定価格を超過した場合は失格になります。
入札価格は開札まで明らかにされません(封筒に封かんされています)。もちろん予定価格も封かんされています。開札の時点で初めて担当者もこれらの数字を見ることになります。

提案者としては技術点は必要条件、価格点は十分条件と考えればいいと思います。
”自分たちは必要条件を満たせるシステム設計、プロジェクト運営ができるかどうか?”かつ ”想定される競合他社よりも費用対効果に見合うシステム提案ができるか?”
コンペ自体は民間案件よりも公平感があります。当て馬ということもありません(仕組み上出来ません)。なのでベンチャーがチャレンジするには格好だと思います。そもそも政府入札案件なんて案件実績としては抜群です。官報に公表されます。

基礎検討と提案書作成

入札仕様書は100ページくらいあります。A4文書で5万字くらいです。
要求仕様そのものは20ページくらいで、あとは提案要綱、情報管理規定、契約書等です。
私が作成した提案書本文は50ページくらいでした。50ページのパワーポイントではありません。A4文書として50ページです。3万字くらいです。図・表は別添形式です。
さすが国として公開される要求仕様書です。入札仕様書は曖昧さがないようにしっかりしたドキュメントになっています。プロジェクトリスクを抑えるため、要所要所で重要な要求が書かれています。入札審査は書類審査になります。プレゼンテーションはありません。


読解、論理・文章構成

なんだ20ページ、そんなものかと思われるでしょうか?これまで数億円規模のRFPを出す側も、提案する側も複数回経験してきましたが、それらに比べても入札提案はなかなかハードです。かなりのベテランでも入札仕様を頭に入れるのに1週間はかかります。それまでは1行も提案書は書けません。
ミドルレベルの設計者やPM専門屋ではそもそも頭に入りません。理解に至らず退場です。
仕様理解、提案作成の段階で提案者の能力が試されます。試されるのは、システム設計能力に加え、論理思考、文書構成力です。エンジニアが論理的に思考できるわけではありません。
要求仕様を満たし、費用とプロジェクトリスクを抑える工夫が求められます。
お金の出どころは国民の税金ですから。民間のようにプロジェクトが遅延したとか、予算オーバーしたとか、動かなかったとか言ってられないのです。それだけの高いシステム構築、プロジェクト運営能力が求められます。だからこそベンチャーにとってはどうしても欲しい勲章です。
以前にも書きましたが、設計能力、プロジェクト運営能力はタスクとスケジュールの具体性、工数計算の正確さに表れます。プロジェクトの根幹なのですが的外れな提案の多いこと。PMBOKは工数計算について何も語りません。工数計算はシステム設計者の領分だからです。論理的な思考ができるシステム設計屋でなければ適格な線表も工数計算も出来ません、もちろん経験も必要です。問題はそれらを軽視するベンダーが多いことです。なのでRFPを出す側はだめな提案を見抜かないといけません。それが入札提案書です。

入札提案書は評価表に沿って記述することになっています。基本設計に近いレベルでシステムの具体的なイメージを記述し、タスクとスケジュールを提示、このようなプロジェクト体制で期間内に実現できる、ということが合理的に伝わるように記述します。なので ”がんばります” ”がんばって作り上げます” は No です。提案時点で存在、利用可能な製品、技術を使用することが求められます。パッケージメーカにありがちな、”必要な機能を期日までに用意します” は通りません。用意できる保証も根拠もないからです。入札提案に限らず枯れた基礎技術、既存機能を絞り込んで組み合わせたシステムは成功します。工数も正確に出せますし、新しい技術にありがちな不安要素がないからです。

いかがですか? ”うちには無理だよ” でしょうか?そもそもですが、以上書いたことは納期、品質、コストを守るためには入札提案に限らず必要なことなのですが。

※入札の基礎知識についてはこちらをご覧ください。
永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から