導入時に安かったのでお願いしたら、途中で謎の金額が乗せられて高くなっていく。
機動力がなくなってきたので、ベンダーを変えることにしました。
よく耳にする話です。何が原因だったのでしょうか。
顧客が契約内容を完全に理解していない場合や、契約が曖昧な文言を含んでいることが原因で、追加のコストが後から請求されることがあったり、当初予定のなかった新しい機能やサービスが必要になり、それが追加の費用となることもあります。
また、サーバ保守やサブスクの契約であれば、サービスの利用量が増加すると、それに伴って費用も増加することも考えられます。
これらは、ある程度大きなシステム開発の規模で一般的に考えられる機動力が落ちる原因です。
いわゆるアジャイル開発などに適した中小のシステム開発規模では違う原因があります。
保守運用などの1人月未満の複雑さ
システム会社視点での本当のところは、そこで稼働するSEの生産単位が問題です。
さて、多くのシステム会社では、システムエンジニアは1人月と呼ばれる単位で人が動いています。
1人が1ヶ月つまり160時間、システム開発にかかる時間単位で費用を計算しています。
ですから、「月の半分だけ80時間だけ作業してよ」と言われると、会社としてはSEの従業員を半分休ませるわけにはいきません。
仕事がない時間も人を雇っておかなければならないというシステム会社の心理が、金額を前後させてしまう可能性があるのです。
たとえば、0.5人月というような1人月未満の仕事がずっと続くとなると、雇い入れているシステム会社側はその人をの他の作業を上手に割り当てる必要があります。
機械ではありませんので、0.5+0.5が必ず1となりません。
それぞれの作業の前後の準備を含めると0.5やって欲しい場合、0.1+0.5+0.1＝0.7となり、2つ目以降の仕事は0.3で当てはめる必要があります。
この他の作業とのバランスが取りづらいため、だんだんと開発の速度が落ちていく、あるいは急に金額が高くなる。といったことが発生してしまうのです。
システム開発における人月モデルの評価
これは「人月商売」「ラボ契約」と呼ばれる。いにしえのゼネコンモデルです。
システム開発のプロジェクトで、作業の費用を「一人当たりの月の労働時間」を基準として計算するビジネスモデルのことを指します。例えば、5人の開発者が1ヶ月働く場合、5人月分の費用が発生するという考え方です。
システム開発の金額の妥当性がシンプルで分かりやすいという点で、多くの企業で用いられています。どれくらいの人数がどれくらいの期間働けば良いか、というシンプルな計算で費用を見積もることができます。作業量やスコープが変わったときに、人数や期間を調整することが比較的容易になります。
また、システム会社としても確定した人数と期間に基づいて収益を予測することが容易になります。
しかし、 同じ1人月でも、経験やスキルによって生産性が大きく異なるため、品質が一定でないことが大きな問題となります。
また、システムの中身がわからない人にとって、作業が遅れているのであれば、単純に人数を増やせば作業が早く終わるという考えが生まれやすいが、実際には「ブルックスの法則」のように、人を増やすだけで効率が良くなるわけではありません。
プログラミングの速度が遅い人ほど高くなってしまうという性質があるため、支払う価値の妥当性に疑問を感じることもあります。
いわゆる製造工程と呼ばれるプログラミング部分だけを任せる場合には人月での見積りは有効です。開発の期間が過ぎれば、次の案件へと移動するため、長期的なビジネス関係の構築は難しくなります。
近年、DevOpsの流行に伴い、結果や価値を重視する契約形態（成果物ベースや価値ベースの契約）が増えてきています。これらのモデルは、クライアントと提供者の間のパートナーシップを強化し、より長期的な関係の構築を目指しています。
結論として、人月商売はその場面や状況に応じて適切な選択となることがあるが、現代の変化の激しいビジネス環境では、より柔軟で価値重視の契約形態を選択することが求められることが多いです。
オフショア開発の知見を活用した意思決定の価値
システムを熟知したメンバーが意思決定に参加することで、人月計算での見積りに入る前に、本当にその機能が必要なのか、あるいは大きな工数をかけてまで作るべきシステムなのか、という問題定義を行うことができます。
システムの開発において、正確な見積りや効果的な機能実装の判断は非常に重要です。特に、オフショア開発を熟知したメンバーが意思決定の過程に参加することで、その重要性はさらに増します。
熟練したシステムエンジニアはシステム全体の設計や動きを理解しているため、新しい機能がシステム全体にどのような影響を与えるか、またその機能の実装にどれだけの工数やコストがかかるかを的確に評価できます。その評価をもとに実際の利用者のニーズやビジネスの要件を鑑みて、本当にその機能が必要なのか、または大きな投資をしてまで導入する価値があるのか、効率的な開発体制などを判断することができます。
このような問題定義の段階でオフショア開発に知見のあるメンバーの意見や評価を取り入れることで、不必要な機能の実装を避け、コストや工数の浪費を防ぐことが可能となります。さらに、初期の段階での適切な判断は、開発の過程での追加修正や変更の頻度を減少させ、プロジェクト全体の品質や進行をスムーズにする助けとなります。
システムを熟知したメンバーとオフショア開発を知っているメンバーの参加とその専門的知識は、システム開発の成功にとって不可欠な要素といえるでしょう。
■まとめ
最初だけ安くて後から機動力が遅くなったり、謎に金額が高くなったりすることを避けるためにはどうすればいいか。
前述のとおり、御用聞スタイルのシステム開発会社は避けた方が賢明です。これは、日本の会社でもベトナムの会社でも同じですが、残念ながら多くの企業に多く見られます。
DXが大きく取り上げられる現代では、システム会社は最大のパートナーとなってバックアップしてもらうことが大切になります。機動力のあるオフショア会社から、いろいろな種類の提案を集めるにはやはり、幅広い知見をもったITコンサルを起用するのがよいでしょう。それは、知識のない単なる資料作りの人ではなく、ただ若手のデジタルネイティブでもないかもしれません。
システム開発のパッケージやツール選びから、業務分析までアタラキシアDXなら他職種、他業種におけるシステム開発経験、システム連携やリプレイス経験があります。助言だけでも聞いてくださいね。
