はじめに
クライアントのシステムを開発する際、いくつか共通した問題によく直面します
コスト・納期・クライアントとのコミュニケーション etc...
これらに対して、どうすればうまく解決できるだろうかと考えている中で、ふと試してみたい契約方法を思いついたので、ここにまとめていきます。
よく感じる課題
-
クライアントに予算がない
システム開発に対してクライアントの予算感がずれており、クライアントに予算がそもそも足りていないなと思うことが多々あります。そのため、開発のコストを抑えたいという要望が強く、品質を維持しつつコストをどう削減するかが重要な課題となります -
クライアントの協力不足
システム開発はクライアントとの密接な協力が不可欠ですが、プロジェクトによってはクライアント側からの協力を十分に得られないことがあります。これにより、仕様の確認やフィードバックが滞り、開発プロセスがスムーズに進まないことがあります。 -
仕様変更の多さ
事前の打ち合わせで合意した仕様に対して、後になってから「やっぱりこうしてほしい」と変更を求められることが少なくありません。これにより、実装の手戻りが発生し、開発の効率が大きく低下してしまうケースもよく見られます。もちろん事前に決めたことなので大きな変更に対してはお断りをするということもできるのですが、今後の関係性のためにも多少は受け入れざるを得ません。
これらの課題を解決するために、ふとQAをクライアントにしてもらう契約を巻けば上記3つの課題が開発において小さくなるのではないかと思いました。実際にやったことないので憶測ですが、メリットデメリットをまとめて今後の開発の際にいつか試してみたいと思っています...。笑
メリット
1.予算を軽減することができる
クライアントにQA（品質保証）の一部または全てを担当してもらうことで、開発側のコストを軽減することができます。ここでいうQAというのは当たり前ですがそもそも大前提のシステムが動作するかなどのチェックではなく、事前に決めた仕様に対しての動作チェックを相手側に任せるということです。システム開発の中でも、QA作業には意外と多くの時間とリソースが必要です。特に、テストの実施、バグの報告、修正確認など、これらのプロセスにはエンジニアの工数が大きく割かれてしまうことが多いです。
そのため、クライアント自身がQA作業に参加することで、開発チーム側のリソースを他の工程に集中させることができ、工数削減に直結します。特に、クライアント側で実際の業務に近い環境でテストを実施してもらうことで、より実運用に即したフィードバックを得ることができ、手戻りも減少する可能性があります。
また、予算の厳しいプロジェクトでは、開発側がすべてのQA作業を担当するよりも、クライアントが関与することで開発費用を抑えられるという利点もあります。クライアントに対して「自分たちが品質チェックを行うことで、全体のコストが下がる」という明確なメリットを提示することで、クライアント側の協力を得やすくなり、コスト管理に貢献できるのではと考えています。
もちろん、全てをクライアントに任せるのではなく、最終的なQAチェックや重要なテストケースについては開発側でも確認を行う必要があります。例えば、システム全体のパフォーマンスやセキュリティに関するテストは、専門的な知識が必要となるため、引き続き開発チームが責任を持って行うことが求められます。しかし、事前に決めた仕様に対する基本的な動作確認をクライアントに担当してもらうことで、双方の負担を分散させ、効率的な開発を進めることができるのではないのかと考えています
2. クライアントから協力を仰ぐことができる
システム開発では、クライアントからの協力を得ることが重要です。特にプロジェクトの進行中に仕様確認やフィードバックを迅速に受け取るためには、クライアントの積極的な参加が大事ですが、実際にはクライアントがシステム開発のプロセスに深く関与しないことがあり、開発チームが独自に進めざるを得ない状況に陥ることも多々あり、そして後々変更を求められる...
そこで、クライアントにQA作業の一部を担当してもらうことで、クライアントの協力を自然に引き出すことができると考えています。QAをクライアント側に任せることは、単にコスト削減の手段であるだけでなく、クライアントがシステムの挙動や機能に対して直接確認し、責任を分散させることもできるのではないかと思っています
また、クライアント自身が動作確認をすることで、システムに対する理解が深まり、後の仕様変更や追加要望を減らすことにも繋がるのではと思います。実際の業務フローに合わせたテストを行いなどすれば、クライアントが期待している成果物に近い形で動作するかどうかを自身で確認できる点も大きなメリットです。
さらに、開発チームとしても、クライアントから迅速かつ具体的なフィードバックを受けることで、手戻りの少ない開発プロセスを実現しやすくなります。これにより、クライアントとのコミュニケーションがスムーズになり、開発スピードも向上することが見込まれます。
3. 仕様変更にうまく対処することができる
クライアントがシステムの挙動や仕様をテストする過程で、システムに対する理解が深まります。これにより、最初に決めた仕様が現実的かどうかをクライアントが早期に判断できるため、後から大幅な変更を依頼されることを防ぐことができます。
また、クライアントがQAを行うことで、変更がシステム全体に与える影響を事前に把握しやすくなり、慎重に仕様変更を要求することが可能になります。結果として、仕様変更の必要性がしっかりと検討され、頻度や影響が軽減されるのではないかと思います。
デメリット
次にデメリットの方も考えていきたいと思います。
1. クライアントのリソースに依存する
クライアントに仕様に基づいた動作チェックを任せる場合、十分なリソースが確保されていないと正確な確認が難しくなることがあります。仕様に対する理解や認識があっても、テストに必要な時間や人材をクライアント側が確保できない場合、テストの進行が遅れ、結果としてプロジェクト全体のスケジュールにも影響を及ぼす可能性があります。
さらに、クライアントがテストを行う際に、事前に決めた仕様に対するチェックが十分でなかったり、曖昧な部分が残ると、その後の開発プロセスに手戻りが発生するリスクもあります。特に、限られたリソースでテストを実施する場合、開発の進行が滞る原因となり得ます。
2. 責任の曖昧化
QAの一部をクライアントに任せることで、問題が発生した際の責任が曖昧になる可能性があります。クライアント側のQA作業が不十分であった場合、バグや仕様ミスが後になって発覚し、それが誰の責任なのかが不明瞭になることが考えられます。このような場合、開発チームとクライアントの間でトラブルが生じる可能性があるのでそこら辺も契約の際に注意が必要そうです。
3. コミュニケーションコストが増加する可能性
クライアントにQA作業を任せることで、逆にコミュニケーションコストが増える可能性もあります。クライアントからのフィードバックや確認作業に対して開発チームが対応する必要があるため、その都度やり取りが発生し、プロジェクトの進行が遅れる場合があると思います。また、仕様の解釈が異なる場合、双方の認識合わせに時間を割く必要が生じるため、結果的に開発スピードが低下することも考えられます。
4. 品質保証のばらつき
クライアントごとにQAの実施方法や品質基準が異なる可能性があります。クライアントが十分なリソースを持っていなかったり、QAの進め方に慣れていない場合、テストの品質が安定せず、プロジェクトごとに異なる結果が出るリスクがあります。これにより、プロジェクト全体の品質保証がばらつくことになり、最終的な成果物のクオリティに影響を及ぼす可能性があります。
まとめ
今回考えているクライアントにQAを担当してもらう契約方法は、開発コストの削減やプロジェクトのスピードアップ、クライアントとの協力体制の強化といったメリットと同時に、仕様変更や手戻りを減らすことにも繋がる可能性があります。
ただし、私自身この契約方法を実際に導入した経験がないため、どういった結果になるかはまだ未知数です。クライアントのリソースや協力の度合いに依存する部分が大きく、プロジェクトの進行にどのような影響が出るかについては慎重な検討が必要です。また、クライアント側の負担が大きくなりすぎたり、期待通りのフィードバックが得られないリスクも考えられます。
そのため、この契約方法を実際に導入する際には、クライアントとの事前のコミュニケーションを密にし、双方の役割と責任を明確にすることが特に大事になるのではと思っています。最初は小さなプロジェクト・案件で試してみることで、この方法がどのように機能するかを確認し、調整していくのが良いかもしれません。また開発規模によっても合う合わないなどもあると思います。
結論としてはまだ未知の要素も多いですが、クライアントとの協力を深め、開発プロセスを効率化するための一つの新しいアプローチとして試してみる価値は十分にあると考えています。もしこの契約で開発をしたら追加でどうだったのかなど記事にしたいと思います。
クライアントによって開発手法や契約など、クライアント・開発チーム両方ハッピーになるように柔軟にしていきたいですね
なんで開発ってこんなにコストや手間がかかるんでしょうね、実際に開発してても不思議です...🧐
契約の際などに気を付けていることなど教えてもらえれば幸いです