一生懸命やっても、赤字続き…。
コストオーバーの常連で、会社の中でも立場が弱い…。
そんなビジネスマンは、こちらへどうぞ！
こんにちは！コンじゃぶろーです！
プロジェクトを成功に導くためには、細かい計画と徹底した管理が不可欠だとよく言われます。しかし、実は細かすぎる計画が、思わぬ落とし穴となることがあります。それは、細かすぎる計画が逆にコスト増加を招く可能性があるという事実です。
細かい計画によって、予期せぬ事態への対応やリスクの管理が容易になると一般には考えられがちです。しかし、実際には細かすぎる計画がプロジェクトの柔軟性を奪い、結果的にコスト増加や納期遅延を引き起こす原因となり得るのです。
細かく設定しすぎたプロジェクト計画は、変更が必要になった場合に高いコストを要することがあります。細かいスケジュールや仕様が固定されてしまうと、予期せぬ変更や要求の調整が難しくなり、プロジェクト全体の再計画が必要になることもあります。これは、追加の作業時間やリソースの投入を必要とし、結果としてコストが増加します。
そこで、プロジェクトを成功に導くためには、計画に柔軟性を持たせ、変更に迅速に対応できるようにすることが重要です。また、プロジェクトの目標や成果物を明確にし、チーム全員がそのビジョンを共有することも、成功への鍵となります。
細かすぎる計画によるコスト増加のリスクを理解し、柔軟性と効率性を兼ね備えた計画を立てることが、コストを抑え、目標達成へと導く鍵です。プロジェクト管理においては、未来への洞察と柔軟な対応が求められるため、常にプロジェクト全体の最適なパフォーマンスを目指しましょう。そして、その挑戦を乗り越え、目標を達成できることを心から願っています。
本日の記事、重要なポイント
- コストが増える原因
- 誠実に対応する
はじめに：シンプル思考でコスト削減
見積もりをする時に注意しなければいけないことは、技術の足りない仕事は積極的に受けないということです。
余裕がある場合は、勉強という意味を込めて、やったことのない仕事を受けるのはいいと思います。しかし、あまりにもやったことのないことをすると、「誠実さ」に欠ける行為となるのでお勧めしません。
技術がない状況で見積もると、調査しながらになりますし、「不安」が膨らめば膨らむほど「コスト」が大きく膨らんでいきます。
結果的に、技術力のない状態で作った「質」の低いものをクライアントへ納品することになります。
誠実さの欠ける仕事になってしまうということです。
コストが増える原因に関して、僕の経験を踏まえて丁寧に解説したいと思います。
コストオーバーの罠：考えすぎると失敗する理由
コストが増える要因は、さまざまだと思います。
システム開発の案件で、開発するのに時間がかかるのは、技術力が低い場合がほとんどです。
作ったことがない状態で、見積もりをすると、見積もり作業の内容は、ほとんど技術調査となります。もし、ここで開発経験や技術があった場合、社内実績をもとに見積もりをすれば良いですが、それがない場合がほとんどなので悲惨な状況になります。
技術を調査する度に、不安要素が見つかる。不安要素を全て解消できるほど調査に時間が取れないので、「不安」を解消する為の「調査工数」が増えます。
不安が、そのまま必要な工数として上乗せされてしまうわけです。
細かな計画の落とし穴
分からない作業が出てきた場合、そのほとんどは、複数の作業が複合した状態であるので、見積もり担当者は、細かく分解していきます。
そうして細かく分解するのにも時間がかかりますし、分解したところで、技術力が追いついていないと「分からないもの」が増えていくことになります。
- 新しい問題が出てくる度に、調査範囲が広がる：調査工数が膨らむ
- よく分からない作業があると、予備工数を設ける：１つの作業に、３０分や１時間の調査工数を設定する
- 作業が細かくなり、量が増えてくる：全体像が把握できなくなり、問題に気づかなくなる
- 仕事が欲しくて「調査費用」を削った状態で請けてしまう。
技術力が無い状態で、知らない技術の「見積もり」をすると、作業は驚くほど細分化していきます。そして、「不安」が増していきます。不安が増すと、それに少しずつ「調査費用」を足すことでコストが増えてしまいます。
例えば、１００個の作業があったとして、それに１時間ずつ「調査費用」を付加すると、それだけで１００時間増えます。
しかも、何かトラブルが起きた時、リカバリー工数も必要になります。大抵の場合、かなり「不安」が高いと、エンジニアが怯えきって工数をかなり引き上げにかかります。
そうなった時は、仕事を受けないようにした方が、結果的には良いかもしれません。
どうしても仕事を請けたいという思いから、調査費用を全カットして請けるというパターンもあると思います。そうなると、「見積もった人」と「開発する人」の間で人間関係が壊れることもありますので注意しなければいけません。
見積もりから調査費用をカットされたことに、現場が納得がいかない状態で開発を進めると、非常にまずいことになります。問題なく開発が進むと、現場は都合が悪くなる為、「うまくいかない結果」へと、進もうとするからです。
開発会社の真の目的
開発会社は、技術力を強化する仕組みを作っておかなければいけません。なぜなら、技術力が低いと以下のような問題になるからです。
- 見積もりに時間がかかる：見積もり工数が、開発費用を圧迫する。
- 見積もり精度が甘くて費用が高い：クライアントの期待値が上がる（要望が増える）。
- 品質が悪いからトラブルが起きやすい：納期遅れにつながる。
- 次の仕事を受ける為に、同時並行で見積もりする：見積もりの精度が悪くなる。
デスマーチというやつです。
このデスマーチに陥った組織は、仕事を受けるのをやめてでも技術力を向上させる方法を考えた方が良いです。企業は、クライアントを喜ばせるために存在しているので、受けたところでクライアントに被害をもたらすからです。
開発会社は、技術だけを調査し続ける人間が必要です。しかし、上記のようなデスマーチに陥ってしまった場合、技術調査専門のスタッフも、トラブルの「火消し」に加わらざるを得ない状況になります。
技術力の強化する所の話ではなくなります。
- エンジニアの不安が積もると、開発コストが膨らむ
- 開発コストがらみで、人間関係にヒビが入ることもある
- 技術力がないと、開発会社として機能しない
成功への道：誠実な顧客対応
技術力が必要なわけですが、技術力のみを鍛える専門のスタッフなんて用意することなんて簡単にはできません。かといって、仕事を受けずに生産ラインを技術研究に割り振るという判断も、なかなかできないと思います。
技術力が無い場合でも、コストを上げずに請ける方法があります。
それは、仕事を請ける時に、誠実に対応することです。
技術力が無いことによって「コストが高い」＋「質が悪い」ものを、「質が良い」ものだと思わせてしまうから問題なわけなので、その辺りを解消すれば良いです。
また、開発会社だけではなくて、クライアント側も「不誠実」な形になってしまっているケースもあります。
「質が高いもの」を、安く発注する為に「質が低いもの」として内容を細かく伝えていなかったり、特に根拠の無い値下げ交渉をするケースもあります。
商売の基本は、安く買って高く売ることなので、そこを重視してしまうクライアントもあると思います。
しかし、目先の利益に囚われていると「良い開発会社」が逃げていくことになり、毎回「質の悪い開発会社」しか仕事を請けてもらえず、結果的に損することになります。
良い物を作るには、お互い誠実に対応する必要があると思います。最低限以下のことを守るべきです。
- 前提条件を明確にする
- 不明な技術・完成がイメージできない部分を明確にする
- 検収期日・検収条件を明確にする
明確な前提条件の設定
前提条件とは、開発要件と言ったりもします。見積もりの根拠となる条件です。どういったものを作るのかを明確にしたものです。
クライアント側から提示される、提案書・事業計画書・要件表等、呼び名は様々ですが、案件の内容やボリュームがわかる資料をもとに、開発会社は見積もりを行います。
１枚の紙切れである場合もありますし、開発会社側から提案した提案書の場合もあります。
よく起きるトラブルは、「対応の抜け漏れ」です。
最悪の場合、納品間際に、開発会社側やクライアント側からこの「対応の抜け漏れ」が出てくると、その時点でアウトです。言った言わないの争いが起こり、手の施しようのない修羅場に発展します。
契約まえに、「何を作るか？」を明確にして、契約書に紐づけておくのが良いです。まれに、クライアント側が「要件」を隠して発注する場合がありますが、契約書とセットの資料があれば、こういうトラブルも防ぐことができます。
ここでの対策は、誰が見ても誤解がないような資料を用意して契約書に紐付けておくということです。
技術的な不明点の解消
何か新しいものを作ろうとしている場合は、それを開発会社もクライアントも共有しておいた方が良いです。
大抵の場合、開発会社とクライアントは、ここを共有しません。なぜなら、開発会社は多少無理してでも契約を勝ち取りたいからです。
しかし、そこを共有せずに仕事を請けるのは、トラブルのタネになりますし、とても不誠実です。
開発会社は、必要以上のリスクを背負うことになりますし、クライアント側は騙された形になり、トラブルに発展しやすくなる為、共有した方が良いです。
どうしても技術的に不明瞭な場合は、１ヶ月の調査期間として１人／１ヶ月分のエンジニア費用をもらい「調査案件」として請けるなどして、不明技術は取り払っておいた方が良いです。
こういう相談ができない会社とは、お互いあまり近づかない方が良いと思います。
スムーズなプロジェクト完了への道
最初の条件と同じくらい大切なのが、検収条件です。
これは、お金を支払う条件になります。いつまでに条件を満たす物ができていたらお金をいくら支払うのかを明確にするだけなので、比較的簡単に対応可能です。
ただ、トラブルになるケースは、条件を定めていないパターンです。
こちらも、誰が見ても誤解が生じない条件を設定し、契約書と紐づけておくのが良いです。
契約終結前に案件内容をミーティングする
前提条件、不安要素、検収条件、これらを明確にしていれば、早々トラブルになることはないのですが、必ずこれらの資料をまとめて、ミーティングをするのが良いと思います。
プロジェクトを開始する前であれば、言い安いことでも、案件終了間際には言いづらくなります。する前に、ミーティングをしてお互いの説明不足が起きないようにしましょう。
トラブルが起きるケースは、「契約後」にミーティングをして知らない仕様が出てくるパターンです。会社間のことですので、契約を交わした後で契約書を書き換えるのは大変なので、事前にやった方が良いです。
シンプルに考える：コスト削減の実例
全くやったことがない人であれば、さっぱり分からないかもしれませんが、そこまで難しい内容では無い為、簡単な仕事でイメージしてみるとわかると思います。
例えば、twitterのアイコンを作る仕事の場合。このようになります。
- 前提条件：twitter用のアニメーションアイコン（400X400）作成
- 不明な技術：特になし
- 検収期日・検収条件：２週間後、アイコンにOKを出したら
こんな感じになるとイメージできると思います。
「２」の技術に関しては、twitterアイコンの仕事であれば、複雑なものはありませんが、「アニメーションアイコンを設定する」といった条件が追加されたら、当てはまると思います。（現在、twitterにアニメーションアイコンは設定できないようなので、これは対応不可能な案件になります。）
あと、「３」の条件だと、「OK出さなかったらお金がもらえない」ということになりますので、「１週間後に提出するラフは２回まで修正要望対応します。２週間後までに要望が対応できたらOKとする」と言った具合に、明確にすれば問題ないと思います。
- 誠実で無い対応が抱えるリスクを考える
- 前提条件、不安要素、検収条件を明確にする
結論：トラブルは避けられる
どんなに注意していてもトラブルは起きる物です。
なので、トラブルを恐れるあまり、慎重になりすぎるのも良くないと思います。
そうなった場合に、お互い誠実に話し合いをすれば、大きなトラブルにはなりません。しかし、ここで「コスト」を意識するあまり報告が遅れてしまったり、不誠実に対応すると大きな被害が生まれてしまいます。
コストを考えるあまり、よりコストの高い選択をしてしまう。
僕も、たくさん案件をこなす上で、そういった失敗を何度も繰り返してしまった経験があります。知識では知っていても、当事者になると見えなくなることもあります。
開発会社は、とにかく「コスト」に目が行きがちです。社会全体が、そういう仕組みになっている所に問題があり、多くの担当者が今日もジレンマに苦しんでいると思います。
コストよりも、顧客満足度を高める動きをする。シンプルにいえば、技術力を高める事に集中できる仕組みを考えないといけません。そうしないと、いつまでも開発現場のデスマーチは鳴り止みません。
泥沼は泥沼を呼びます。どこかで、変えていかないといけないといけません。
以上、さしあたり、今思う事でした。
ここまで読んでいただけてありがとうございます。
皆様の良い人生の一助になれば。
コメント