2020年9月7日月曜日

コンペ提案 〈勝ち抜き〉


RFPとか競争入札の提案活動のお話です。私はベンチャーが性にあっているので、だいたいチャレンジャーサイドでした。競合は大手、有名どころばかり、そんな不利な立場からの勝ち抜き、仕事の醍醐味です。


この8月(2020年)まるまる、某AIコンペに費やしました。夏を制する者は受験を制す、と言いますが8月までに下期の案件が決まるのでシステムの仕事でも8月は重要です。
RFP対応とかコンペはこれまでもこなしてきていますが、これだけどっぷりというのは初めての経験です。

コンペは最後にだいたい2社の争いになります。チャンピオンサイド(大手有名どころ、既存ベンダー)対チャレンジャー(ベンチャー、新顔)になることが多いです。チャレンジャーがコストに勝るからで、大手の似たような提案は途中で絞り込まれることが多いです。コンペは、コンペをして発注先を決めたという手続き自体に意味があることも多く、はじめから当て馬というケースも多々あります。そうでなくともチャレンジャーサイドは負けること多く、光る技術、製品があっても、トータルで大手企業の求める品質基準についていけず、落とされます。会社の名前が品質を表すものではありませんが、名前で選ばれるのが現実です。
勝率は高くはありませんが、チャレンジャーが勝ち抜ける例があるのも事実です。なぜか?と問うよりも、実力勝負、興味ありませんか? ” ここがロドスだ、ここで飛べ! ” 

高校受験とか大学受験はみんな実力勝負でしよね。仕事でもその道何十年という経験を積んだ以上、自分の力で勝負したくありませんか?そんな機会を多く経験してきた私は幸せなのだと思います。システム大手では専門分野毎に、アプリ、基盤、プロジェクト管理・・と分担します。そもそも組織、部署が分かれていますから、担当分野以外のことに手を出せないようになっています。チャレンジャーサイドに分があるとしたら、一人の意思の全体設計で大手ではできないようなQCDを実現することにあります。顧客が見落としている大事なポイントがあれば、勝算は上がります。チャレンジャーの描くストーリーが評価基準になるからです。競合関係にない相手の場合、能力として自分より下の人間よりも上の人間を選ぶ傾向があります。 ”何でもやります” という提案よりも、 ”こうしなさい” という提案が選ばれます。名前で有名どころを選ぶのも同じ理由です。チャレンジャーはストーリーでそれ以上のことします。提案担当ができることと言えばそれくらいです。

競争ですから、案件の中身、要求仕様もさることながら、案件の状況を知ることが大切です。見極めの一番のポイントは、なぜ依頼をしたかの理由、経緯そして今後の段取りです。段取りがあいまいな相手に付き合う必要はありません。相手を立てれば案件が取れる訳でも、事業や自分が成長する訳でもありません。発注者に思い違いがないようこちらの出来ること、立場を知ってもらうことが大事です。コンピュータは人間ほど利口ではないし、簡単ではないし、開発には時間もお金かかるということです。私は最初にはっきりそれを言います。勝算のない案件に時間を使うことよりも実需に合わせた製品コア機能の拡充に時間を使うべきです。

ところで初めから勝算のない当て馬案件、見分けは簡単なのですが営業の立場だとなかなか捨てられません。ノルマがあるからですが、結局期末に悲しい結果を迎えます。当て馬ばかりというのは、営業の問題ではなくて製品、事業が当て馬レベルでしかないということです。そういう会社からは早く離れた方がいいです。ITの場合、営業で製品の不足を補うことは難しいです。いい仕事をするためには、いい環境に身を置きましょう。自己中心的、わがままでいいと思います。会社や上司も、みなさんの先のキャリアを考えている訳ではありません。その時々で役に立つ人間が欲しいだけです。自分のキャリアは自分で作る、そういう心構えがなければ、意思の通った全体設計なんてできないと思いますが、いかがでしょう。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

2020年9月6日日曜日

システム開発と原価計算 プロジェクト管理に実際原価がそぐわない?


製造業の原価計算システムを設計開発することもあります。前工程から実際原価を算出し後工程に反映していきます(転がし計算)。これを連結ベースで計算することもあります。そんな高度なことしつつも、灯台下暗しで、システム開発会社で実際原価計算をしているところは滅多に見かけません(私が知るのは過去1社だけです)。


エンジニアはだいたい固定給なので実際原価把握が容易なのに、なぜでしょう?どうも原因はプロジェクト管理にあるようです。プロジェクト管理と原価計算はもちろん別物ですが、一緒にやろうとすると実績原価(標準時間単価×実績時間)でプロジェクト管理して、原価差異を足し引きして財務上の原価を
出しますが、実際原価に戻ってきます(当たり前ですが)。標準原価法を使ったところでプロジェクトを推進するプラスアルファは何もありません。予定原価と実際原価がほぼ一致する業種ならいざ知らず、試験や移行の工数を漏らすレベルで標準原価法を使う意味はありません。プロジェクト計画のリアリティチェックをするだけなのですが、できていないですね・・
EVM(Earned Value Management)という進捗管理法があります。これは予定原価が信頼できる前提ですから、システムの世界ではダブルクエスチョンものです。そもそも信頼できる予定原価計算ができていればプロジェクトは成功を約束されたようなものです。すべて見通している訳ですから。形式的なプロジェクト管理も必要ないでしょう。待っていればQCDいずれも満足のいく結果が得られるます。前にも書きましたが見積、工数計算はシステム設計でも高い習熟度が求められる能力です(システム開発〈見積・工数計算〉)。 要は経験、能力が未達ということで、人材不足なのでしょう。新しい言葉、言語、開発フレームワーク、資源管理・・が出ては消え、出ては消えを繰り返して、本質に切り込めず、周りをまわっているだけのような印象です。予定原価に信頼性がない以上、システム開発の原価計算は実際原価で十分だと思います。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)