システムの発注者がシステム開発は素人、はもう通用しない。ブラック顧客は淘汰される時代になっている。
この記事を書いた社長に感動しています。
米村さんよくぞ言ってくれました！
アクシア社の米村社長とはお会いしたことはありませんが、アクシア社は「残業ゼロのIT企業」というフレーズとともに、SNSやメディアで拝見しておりました。
請負開発の仕事をしているとブラックな発注者に当たってしまうことは珍しくありません。 先の記事はそれを本当にわかりやすく分類していますね。
私自身も請負開発をトータルで7年、請負開発のプロジェクトマネージャーも5年ほど経験していますので、この記事の事例を経験しています。
請負開発の仕事をしていると仕事のほとんどが顧客のシステム開発になり、顧客の秘密をたくさん知っているわけですから、仕事の話はあまり発信出来ないかと思います。
そして「お客様が悪い」とはなかなか言えません。
「お客様が悪い」と定義してしまうと、こちらの努力も進まなくなる弊害もありますし、「お客様が悪い」と発信してしまうと、顧客の新規開拓にも大きな影響があるはずです。
そして「お客様が悪い」と言えるのは社長以外に無理だと思います。
プロジェクトマネージャはプロジェクトの収支に責任はありますが、会社全体の利益にまで責任を負えません。だから社長しか言えないんです。
米村さんは全てわかった上での、あの記事なんだと思います。
なかなかの勇気ですよね。惚れるわー！
実は顧客を開拓するより、エンジニアを採用する方が難しい
「お客様が悪い」と言える背景に顧客とベンダー側のここ何年かのパワーバランスの変化もあると思います。
ある程度の実績がある会社だと理解して頂けると思うのですが、コアとなるソリューションが育っている会社の場合、顧客を獲得するよりエンジニアを採用する方が難しいです。
「新規の案件の受注は控えております」と言った会社は少なくないはずです。
私も信頼しているベンダーさんが、リソース不足でなかなかプロジェクトの座組が出来ない、希望通りのスケジュールとならない経験は1度や2度じゃないです。
これはエンジニアの採用が簡単でしたら、すぐ解決する話かと思いますがそれが一番難しいんです。
これはDODA調べの転職求人倍率で、DODA内のデータのようですが、IT業界の転職求人倍率が突出して高いと思います。 恐らく採用コストも比例して上がっているはずですし、社員じゃなくても外部の人、派遣や特定派遣の会社を利用してリソースを確保しようとしても、やっぱり単価は上がってきています。
このような市況なら、
「顧客に媚を売ってエンジニアに無理をさせて離職率を上げてしまい、無駄に採用コストや教育コストを上げてしまうよりは、エンジニアを大事にしよう」
となるのは自然というか合理的な判断です。
発注側は現在の状況を踏まえ、合理的な付き合いをすべきです。
今だから言えますが、私も仕事を受けたくない理不尽な既存顧客の案件に対して、かなり吹っかけて、あえて失注した経験があります。
「新規の仕事を断る状況で、おまえの仕事はいらない」
そもそも請負開発のビジネスモデルって何なのか？
私は請負開発のビジネスモデルは「保守のストックビジネス」だと考えています。
ストックビジネスとは継続的に売上があがるビジネスを指します。
例えば保険の販売はストックビジネスです。
一度保険商品を売ると、解約しない限りは毎月決まった保険料が入ります。 この場合、販売努力は１回です。
ストックビジネスの反対はフロービジネスといい、例えば飲食店はフロービジネスです。
飲食店で例えばラーメン定食を１度提供したとして、また定期的にお客さんが来てくれるかは保証できませんし、もう一度ラーメン定食を提供する場合はまたラーメン定食を作らなければいけません。
これを請負開発に置き換えると
新規取引先の新規プロジェクトはフロービジネス。 初回の営業活動は大変な作業で、新規開発プロジェクトはリスクが大きい。後述します。
既存取引先の保守契約、保守案件はストックビジネス。 営業活動も不要で保守契約以外にも、ソフトウェアライセンスのフィーがあるかもしれないし、ハードウェア、ミドルウェアの販売代理店の場合はそこからのフィーもあるかもしれない。そして保守案件はリスクが小さい。
そもそも新規の取引先と新規のプロジェクトはリスクが大きいです。
大きい案件の場合は間違いなくコンペでしょうし、ソリューションや実績に自信があっても競合がいるわけですから、競合を意識した価格にどうしてもなってしまいます。
その中で大量の人をアサインし、数カ月プロジェクトを進める場合、1カ月納期がずれただけでも多くの人件費がかかりますから、収支的にはトントンでも十分だと思っています。 プロジェクトのリスクは要件定義でかなり減らせるとは思いますが、どれだけプロジェクトの数をこなしても、たくさんの問題が発生するものです。
完璧な絵が描けているプロジェクトを、私はまだ知らない。
一方で保守案件は基本的に既存システムの改善・拡張ですから
- 技術的リスクが小さい
- コミュケーションコスト・リスクが小さい
- 教育コストも小さい
- 納期が新規ほどきつくない。大量に人をアサインする必要も少ないわけで、やっぱりコミュニケーションロスも少ない。→後述するブルックスの法則で説明します。
他にもあると思いますが、リスクが小さいわけです。
だから確実に黒を出せます。
出せなかったらプロジェクトマネージャじゃないですよね。
私の昔の上司の話ですが、彼は大手の事業会社から来た、技術力とかは皆無の部長さんだったわけなんですけど、
「おまえ保守で儲けていれば良いと思うなよ！」
私にこんなアドバイスを送ったことがありました。 それは私の新規案件のプロジェクトの利益率が悪かったために出た言葉だと思いますが、決して赤は出していません。
また、新規案件の価格はどちらかと言うと営業マターが多いわけで、こちらとしては厳しいプロジェクトをいくつも納品し、保守費を積み上げて、毎月安定的なキャッシュを会社に献上しているわけなので、「は？」という受け止め方になります。
今だから言えますが、私がその会社を転職した理由のひとつに請負開発を理解していない、その部長の存在があります。 技術的なリスクをたくさん抱えるか、またはエンジニアにたくさん無理をさせてでも、理想的な利益率を出そうとは到底思えません。 だって保守案件で安定的に儲けようとしていますからね。
なんか、「昔の恨みつらみ」みたいな文章になってしまいましたが、発注者側も請負開発のビジネスモデルを理解していると、ベンダーさんをうまく使えるんじゃないかとも思います。
発注側こそ理解すべき、ブルックスの法則
ブルックスの法則は聞いたことが無いとしても、プロジェクトの人数が多ければ多いほど、ひとり頭のパフォーマンスが下がるのは感覚的に分かると思います。
主な理由としては、
- 人が増えるほどコミュニケーションコストが増大する
- タスクはそんなに分解出来ない。1画面3人日で終わる仕事を、1日で終わらせるために3人のエンジニアを投入しても1日では終わらない。
つまり、
納期がきつい→たくさんの人員が必要→ひとり頭のパフォーマンスが下がる→納期がきつい場合は特急料金が必要
と言えるわけですが、これをちゃんと理解している発注者の方が少ないかと思います。
逆に日ごろQCD（Quality、Cost、Delivery）*1に接しているプロジェクトマネージャはこの現実を理解すべきです。発注者に理解させなければいけなんです。むしろ腕の見せ所です。
じゃ発注者はどうしたら良いのか？
発注者の基本的な立ち位置は「プロデューサー」だと思っています。
プロデューサーといえば、TVのプロデューサーを思い浮かべる人も多いかと思います。
私はTV業界について詳しくはないですが、TVのプロデューサーになるためには恐らく、AD（アシスタントディレクター）、ディレクターという職種を経験しているかと思います。 最初はお弁当の手配などの下積みから始まり、番組制作に関わる多くの部分をディレクションし、最終的にプロデューサーという責任者になるわけです。
つまり彼らTVプロデューサーは制作を知っています。だからいろんなジャンルのスタッフをまとめ、演者さんには気持ちよく仕事をしてもらい、広告主に対しては視聴率について責任を持つことが出来ると思います。もちろん会社には利益で貢献していると思います。
同じ論理で言うと、システムの発注側も制作について知るべきです。
制作を知らないのに多額なシステム投資に責任が持てますか？
TVプロデューサーが、企画が悪い、演者が悪い、ディレクターが悪い、制作会社が悪い、そんな風に人のせいにして成立するとは思えません。
残念なことにITについては、それが結構まかり通っていると思います。
まずIT企業自体がそうです。
10年以上前の古い記事ですが、IT企業がIT企業に発注している例です。10年前とはいえ、日本でNo.1のSierの事件です。
IT企業の社員なのにITは素人でITを発注しているわけです。 これは事件になって明るみに出ていますが、ここまでひどくないにしろ、私も含め、似たようなケース経験している人は多いと思います。
そして、このBlogのタイトルはWebプロデューサーのノートです。
請負開発の仕事をしていた私も今はプロデューサー、発注する立場でもあります。
実際はベンダーに発注するだけでなく、自分でコードも書きますし、エンジニアを抱えてディレクションもしますし、やっぱり根っこは一制作者だと思っています。
誰も私のことを「Webプロデューサー」とは呼んでくれませんが、このBlogではその部分について深堀出来たらなと思っています。
おまけ
ちなみに先のアクシア社も、
この記事を見ると、客先常駐をやめることによって
- 採用力が高まった
- 従業員の質が上がった
とありますし、
既存顧客からのリピート受注と保守で占める割合は９割で、新規顧客からの受注は１割
のようです。利益は安定的にあげられそうですね。
あのブログで吠えることにより、採用力を上げて→優秀な人材を確保→顧客に良いサービスを提供→リピート率を上げる→安定した利益なんだと理解しました。感情的というより、むしろ合理的です。
請負開発者はもっと合理的に吠えた方がいいですね！
*1:QCDとはQuality（品質）、Cost（費用）、Delivery（納期）の略で、それぞれに相関関係があります。例えば品質を上げれば費用がかかり納期も延びます。納期を短くしたら費用がかかり、教育を怠れば品質が下がるかもしれません。このバランスを保つことはプロジェクトマネージャの大事な仕事です。
