小さな改善の見積もりが重い理由は？（1-7／第7回）

表示を1つ変えるだけの要望なのに、開発チームから思ったより大きい見積もりが返ってきたことはありませんか。
昔よりは減りましたが、私も未だにあります。一方で、AIを使った開発が広まったことで見積もりの精度に差が出るようになり、また難しくなってきたとも感じています。

すべてではありませんが、要望の重さは、それがシステムのどこに手を入れるかで大きく変わります。
これらを実装レイヤーではなく、PdMが判断する範囲で整理してみます。

システムのモデル

システムの組み方には、大きく3つのモデルがあります。

これらはビジネスやサービスの特性によって主流が変わっていきます。
「所有の時代」から「利用の時代」になるにつれて、買い切りがサブスクになっていったように、システムも個々で完結する「スタンドアロン」（図の左）モデルから最低限のみ持って利用しにいく「クライアント・サーバ」（図の真ん中）モデルが主流になってきました。
WEB3やAIによって変わっていくかも知れませんが、現在イメージする多くのプロダクトはこのモデルと思います。

ざっくりいうと、電波のない場所でも使えるべきか、データを利用者の端末と自社のサーバのどちらに持つか、がモデルを選ぶときの判断材料になります。どちらも、機能を作り始めてからでは変えにくい部分です。

クライアント・サーバと3層アーキテクチャ

多くのプロダクトが先ほどの「クライアント・サーバ」モデルという前提で、ここをもう少し見ていきます。

ユーザーが持っている端末側をクライアント、サービス提供者側がもっているコンピューター群をサーバといいます。クライアント・サーバモデルとはこの関係で成り立っています。
また、サーバとは、特定の用途に特化したコンピューターのことです。その中でも役割ごとに3層のサーバに分けることができます。

テックメインのプロダクトでなければPdMがここより降りる場面は多くないので、この3層の分かれ方が分かれば十分だと思います。
いずれも中身はCPU・メモリ・ディスク・ネットワークの組み合わせで、何がどう通信しているかはより細かい話（OSI参照モデル）になります。

なお最近は、サーバを自社で用意せず、クラウドが提供する部品を組み合わせて作ることも多いです。
また、Webサービスやアプリでは、画面の多くを端末側（ブラウザやアプリ）で組み立て、サーバは処理したデータを返すだけの形とし、決済や認証、生成AIのように、外部のサービスを組み込むことも増えました。
これらによって、3層の境目は見えにくくなっていますが、画面・処理・データという役割の分かれ方はあまり変わりません。
（例：クライアント（WEB・APP） - サーバ（APP・DB）など）

システム構成のモデルを知ると何が変わる

モデルが分かると、その機能がどの層に手を入れるかで、開発の重さの当たりがつけられるようになります。（あくまで大枠の話です）

例: 一覧画面への3つの要望

例えば、業務向けのSaaSで、顧客から一覧画面について3つの要望が来たとします。

どれも一覧の見た目を少し変えるだけに見えますが、重さは違います。
Aは受け取ったデータをその場で並べ替えるなら画面の変更だけで済みますし、Bは計算の処理に手が入るので、請求書など同じ計算を使う他の画面まで確認が要ります。

その中でも、基本はCが一番重くなると思います。今のデータに誰が更新したかを記録していなければ、項目を足すところから始まり、過去の分は表示できません。見た目の変更に見えて、実際はデータを増やす話になります。

また、スマートフォンのアプリでは、画面だけの変更でもストアの審査と利用者のアップデートを待つことになります。Webなら当日に直せる変更でも、アプリでは行き渡るまで数日かかることがあるので、提供形態によっても重さは変わります。

つまり、小さな改善に見えても、小さいとは限りません。
実際の見積もりは開発チームが出すものですが、要望を受けた時点で、その情報を今どこかに持っているかを確かめるだけでも、重さの見当は外れにくくなります。
ぜひ最近受けた要望を、画面・処理・データのどこに手が入るかで分けてみてください。重い見積もりが返ってきたものは、データに手が入っていることが多いと思います。

開発関係者の方からしたら当たり前の話かもしれませんが、開発経験のない人やPdMになってすぐの人からすると、この前提さえ把握できていないことも多いと思います。

実務で見積もりが大きくなる理由

大枠のモデルや処理の流れを解説しましたが、これを踏まえても、実際の見積もりが想定より大きいことは多々あります。私は大きく2つの理由があると思っています。

1. 見えない複雑性や難易度

開発している人にしか見えない、システムの複雑性や難易度があります。
特に古いシステムは開発の積み重ねなので、考慮しなくてはいけない点や社内のルールがあり、これらシステムを見ているからこそ分かる細かな課題は、PdMからは見えません。（例：オフラインのときはどうするのか、データはいつまで保存するのか、処理結果の品質をどう担保するのか、内部システムとの整合性..などなど）
また、開発はトライ&エラーの繰り返しなので、新しい技術ほど、その知見やベストプラクティスが少なく、難易度は上がるでしょう。

2. PdMと開発メンバーのゴールは少し違う

PdMにとっては、早くユーザーに出して効果を得ることがメリットですが、開発メンバーにとって早く出すことは、必ずしもメリットになっていないこともあります。
その一因は、数字が伸びない責任はPdM寄りですが、開発の問題の責任は開発側になりがちで、数字が伸びること以上に、開発の遅れや不具合を出すことの方が懸念になるためかなと考えています。
これを防ぐために開発期間を多めにとり、実際の工数以上に見積もりが大きくなることは、実務上ありえますが、システム開発を安定させるには、ある程度は必要なことだと考えています。
ただし、これらのギャップは開発内容というより、チームの状態によるものも大きいです。本来はゴールの認識をそろえていくべきですが、立場が違う以上、違いは残って当然と思います。なるべくお互いの認識の違いを補完し合っていきましょう。（いきたいです）

システム開発に関する詳細や、クラウド化、コンポーネント化などの前提については以降の回で書きます。

まとめ

• システムのモデルは大きく3つ。多くはクライアント・サーバ構成で、サーバは3層に分かれる

• どの層に手が入るかで開発の重さが変わる。見た目の要望でも、持っていないデータが要るなら重い

• 実際の見積もりには、見えない複雑性やチームの状態も影響する

次回は、システムなどの開発領域を含んだプロダクトマネジメントで必要なスキルについて解説します。

「プロダクトマネジメントわかりたい」

プロダクトマネジメントに関するnoteを週2ペースで連載してます。
よければ記事に対するリアクションや疑問、感想いただけると嬉しいです！