影響範囲が少ないかどうかはお前が決めるな
「影響少ないですよね？」にイラっとした話
「クライアントアプリの項目を1つ増やすだけだから、影響は少ないですよね」
最近、こんなことを言われました。質問じゃなくて、断言されました。
「お前、本当に影響度を完璧に理解して言ってんのか？」って、思いましたね。
正直、イラっとしました。
「項目を1つ増やすだけ」と聞くと、たしかに影響度は低く感じます。
画面に入力欄を1つ足すだけ。表示項目を1つ増やすだけ。管理画面に項目を1つ追加するだけ。
言葉だけ聞けば、めちゃくちゃ軽そうに聞こえます。
でも、システム開発ってそんなに単純じゃないだろ？
画面上は「項目を1つ増やすだけ」に見えても、その裏側ではいろいろな箇所に影響する可能性があります。
見た目の変更が小さいことと、影響範囲が小さいはイコールにならない。
もちろん、本当に影響が少ないケースもあります。
数分、数十分で対応できるような軽微な修正もあります。
でも、それを判断するのは発注側じゃないよね？
今回まず言いたいのは、影響範囲が少ないかどうかはお前が決めるな。
「項目1つ追加」の裏側で起きること
「項目を1つ増やすだけ」
たしかに、言葉だけ聞くと簡単そうに聞こえます。
でも、クライアントアプリに項目を1つ増やす場合、影響はクライアントアプリだけで終わるとは限りません。
例えば、こんな影響が出る可能性があります。
・デザイン：レイアウト変更が必要になる
・クライアントアプリ：入力項目、表示項目、バリデーションが増える
・API：リクエスト・レスポンス項目の追加が必要になる
・DB：カラム追加やデータ保存方針の検討が必要になる
・CMS：管理画面側にも項目追加が必要になる
・テスト：追加項目に関連する検証観点が増える
もちろん、毎回すべてに影響するわけではありません。
本当にクライアントアプリ内だけで完結するケースもあります。既存の項目を少し表示するだけで済むケースもあります。影響範囲がかなり限定的なケースもあります。
でも、それは中身を確認してから分かることです。画面上は「項目を1つ増やすだけ」に見えても、裏側ではデザイン、API、DB、CMS、テストまで関係することがあります。
だから、見た目だけで「影響は少ない」と決めつけられる話ではありません。
……と、これだけだと愚痴で終わっちゃうので、発注側と開発ベンダー側、それぞれどう動くのが良いかを整理してみます。
発注側は、まず影響範囲を確認しよう
発注側におすすめしたいのは、基本的に「確認するスタンス」で進めることです。
開発のプロではないのだから、影響範囲を完璧に把握するのは難しいです。
クライアントアプリの画面だけを見て、「これは簡単そう」「影響は少なそう」と感じること自体は自然だと思います。でも、それを「影響は少ないですよね」と決めつけるのは違います。
考え方は、こんな感じ。
・NG：項目を1つ増やすだけだから、影響は少ないですよね？
・OK：項目を1つ追加したいです。影響範囲を確認してもらえますか？
これだけで、受け取る側の印象はかなり変わります。別に、遠慮する必要はありません。追加や変更したいことがあるなら、伝えましょう。本当に影響が少ない追加であることもありますし、多少影響があっても、スケジュールや予算の範囲に収まるなら対応できることもあります。
もし影響があるけど、それでもやりたいなら、スケジュールを調整する、追加予算を確保する、対応範囲を見直す、優先順位を入れ替える。やり方はいろいろあります。
だから、要望を出すこと自体は悪くありません。
悪いのは、影響範囲を確認せずに「これくらい簡単ですよね」と決めつけることです。
ベンダー側は、安易に約束しない
開発ベンダー側におすすめしたいのは、安易に即受けしないことです。
もちろん、その場で影響度を判断できるレベルの内容なら良いです。クライアントアプリ内だけで完結する、既存項目の表示位置を少し変えるだけ、既存の仕組みをそのまま使える。そう言い切れるなら、その場で回答しても問題ないと思います。
でも、自信が無いなら、即答しない方が良いです。
「大丈夫です」
「影響は少ないと思います」
と、軽い気持ちで受けた結果、想定より影響範囲が広くて苦しくなることがあります。最初は小さな修正のつもりだったのに、API、DB、CMS、テストまで影響して、気づいたら普通に追加開発になっている。
なので、影響範囲を確認する前に、安易に約束しない方が良いです。
見た目上は小さな変更でも、影響があるなら堂々と説明しましょう。項目追加に伴ってAPIやDBの変更が必要になる。CMS側にも項目追加が必要になる。既存データへの影響確認やテスト観点の追加が必要になる。そういう影響があるなら、ちゃんと伝えるべきです。
それでゴネられても、影響があるものはあります。そこを曖昧にして飲み込むと、結局あとでプロジェクト全体が苦しくなります。
ただし、本当に影響が少ないなら、無理に跳ね除ける必要はありません。対応できるものは対応した方が良いです。発注側からすると、小さな要望に柔軟に対応してもらえると安心しますし、信頼関係の向上にもつながります。
その場合も、ただ「やりますね」で終わらせるより、「今回は影響範囲が限定的なので対応します」と伝えておくと良いと思います。恩着せがましくする必要はありませんが、ちゃんと確認したうえで対応していることは伝えた方が良いです。
影響が大きい場合も、「やりません」「無理です」で終わらせるのは違います。スケジュール調整や追加発注が必要になるなら、その前提で進めるか確認すれば良いです。
開発ベンダー側がやるべきなのは、要望を雑に受けることでも、雑に拒否することでもありません。影響範囲を確認し、必要な条件を説明し、そのうえでどう進めるかを提案することです。
小さな変更こそ、確認してから判断しよう
変更要望を出すこと自体は悪いことではありません。むしろ、プロジェクトを進めていく中で「ここを追加したい」「ここを変えたい」と思うことはあります。
発注側が「これは影響が少なそう」と思うことも、別に悪いことではありません。開発のプロではないのだから、画面上の見た目からそう感じるのは自然です。ただ、それで「影響は少ないですよね」と決めつけるのがダメ。
影響範囲が少ないかどうかは、見た目だけでは判断できません。クライアントアプリ、デザイン、API、DB、CMS、テストなど、どこまで影響するかを確認してから判断するものです。
発注側は、決めつけるのではなく確認する。開発ベンダー側は、安易に受けるのではなく、影響範囲を確認して説明する。
このやり取りができるだけで、プロジェクトはかなり平和になります。
小さく見える変更でも、確認するまでは小さいとは限りません。発注側と開発ベンダー側が、お互いに確認と説明をしながら進められるプロジェクトが少しでも増えることを願います。
