スムーズな開発のための開発手法、契約、手続き
こんにちわ。
今回は開発回りの手法や契約、手続きなどについて考えていきたいと思います。
様々な案件に関わっていると、作りたいプロダクトに対して開発手法が不適切な場合、選択した開発手法に対して求める社内手続きがあっていない場合など、「開発手法」「契約形態」「社内手続き」の3つの矛盾によって、不要な作業とリードタイムがかかってしまい、価値の提供が遅れてしまうプロジェクトを多数見ています。
今回は、ソフトウェアを作るうえでの選択が極めて大切な、「開発手法」「契約」「社内手続き」について考えていきたいと思います。
この3つの選択をミスする、もしくは、過去踏襲でいずれかの手法が固定されてしまっていると、開発の時間とコストがかかり、メンバーへの負担も大きなプロジェクトになってしまう可能性が高いです。
はじめに
改めてですが、皆さんのプロジェクトは、すべて内製でしょうか、外部パートナーを含めた開発でしょうか。
完全に内製で開発している方は、契約部分については、読み飛ばしていただいてもよいかと思います。
外部パートナーを利用して開発している方は、契約部分も読んだ頂けると良いかと思います。
開発の手法について
初めに、代表的な開発手法についてみていきたいと思います。
開発手法を見ていく前に、よく見る開発手法と契約手続き、社内手続きで矛盾が生じるパターンは、
「アジャイル開発」「請負」「スケジュールコミット」
この組み合わせです。
この3つのセットは後で言及しますが、非常に相性が悪いので、各ステークスフォルダーへの調整（説明のための資料作成や会議体）コストが莫大にかかります。
もう少し書くとこの3つの組み合わせでプロジェクトを進めようとするのは、あえて開発しづらく、プロジェクト管理の混乱を招く行為なので避けたほうが良いでしょう。
アジャイル開発
アジャイル開発について、詳しく知りたい人は、アジャイルソフトウェア開発宣言を読んでいただきたいですが、基本的に顧客との対話から動くソフトウェアを重視して、各メンバーとの対話プロセスを重視して、変化に対応しやすい開発手法だと認識されています。
以下のように、比較的短い期間で顧客に価値が提供できる単位でリリースしていくのが一般的です。
きちんとした顧客との対話に基づき、仕様変更をしながらリリースしていく形が有効なプロダクトはアジャイル開発が向いていると思います。
全ての機能をリリースしないと利用できないようなプロダクトやガチガチにリリース日が決まっているようなプロダクトには不向きです。
また、アジャイルソフトウェア開発宣言に記載してある通り、包括的なドキュメントより動くソフトウェアを重視しますので、ドキュメントを重視する組織やドキュメントを各フェーズで細かくチェックするような開発体制、組織には、向かないと思います。
アジャイル開発に向いているケース
内製開発で、ユーザー部門や利用者の声を聞きながら作れる
営業、開発、デザイン、マーケなどの部署が縦割りになってなく同じチームとして動ける
価値が決まっていなく何度もリリースとピボットが必要
アジャイル開発に向いていないケース
ずらせないリリース期日がある
社内が縦割りで、必要なメンバーが1チームで動けない
要件定義、設計などのドキュメントのレビューと承認フローが社内にある
ウォータフォール開発
ウォーターフォール開発は基本的には、以下の工程があります。
企画（要件定義）、設計（基本設計、詳細設計）、プログラミング、テスト、リリース（リリースと保守運用）の工程があります。
スケジュール通りに決まった物を決まった日にリリースする場合は、非常に効果的です。
また、ドキュメント作成・管理をきちんと行いたい場合は有効です。
前の工程には基本的に戻らないので出来た物を見て修正したいなど、仕様の変更には弱く、途中での仕様変更は多くの場合、前工程への手戻りが発生してスケジュールが伸びます。
また、その場合には期間が伸びる可能性が高いため、各工程でより正確に要件や要求を決めていく必要があります。
従って、企画と設計の期間とコストが非常に大きくなりがちです。
ウォーターフォールが向いているケース
リリース日が決まっている場合にに有効
ドキュメントをきちんと作成したい場合
作るものの価値が決まっている
フォーターフォールに向いていないケース
スプリント単位で進めたい
作る物の価値が決まっていない
利用者に使ってもらわないと要件の洗い出しが難しい
プロトタイプ開発
プロトタイプ開発は、プロトタイプを開発するという意味合いのプロトタイプ開発と、開発手法としてのプロトタイプ開発という意味があります。今回は、開発手法としてのプロトタイプ開発（試作品を構築し、それを評価してブラッシュアップしていく手法）について記載します。
プロトタイプ開発は、動くプロダクトを見ながら修正して作っていけるため、クオリティや操作性などに不安を感じずに作れる点がメリットです。また、大きく作る前に変更が可能なので変更がしやすい点もメリットだとは思います。
一方で、頻繁に変更が行われることで、スケジュールが伸びがち。追加要望などが増えて、コストが膨らむ。結果的にトータルコストが膨らんだり、期間が長くなるリスクがあります。
また、レビューワーが多く意思決定者が複数（階層構造）になっていたりするとたくさんのインプットがきて、インプットの整理に時間がかかったり、方向性が右往左往して、検討コストや調整だけに時間がかかってしまうことも多々あります。
プロトタイプ開発に向いているケース
新しい技術を試す必要がある場合
利用者の要求が不明瞭で具現化して確認が必要な場合
うまくいかないことを早く確認したい場合
プロトタイプ開発に向いていないケース
予算に限りがある場合（かなりタイトな場合）
スケジュールが決まっている場合
評価の基準が決まっていない、評価者が階層構造でたくさんいる（リーダー、課長、部長、役員のような）場合
スパイラル開発
スパイラル開発は、並行作業可能な機能群やシステム群に分割して、機能や機能に付随する機能単位で開発していく手法です。
各機能毎に、企画、設計、コーディング、テストを行いながらウォーターフォールのプロセスを分割して進めていく形です。
以下の図では、リリースは一括になっていますが、リリース分割するケースもあります。
また、企画部分を一括して行った後に設計から機能毎に分割するようなイテレーティブ・モデルのような開発手法も存在します。
スパイラル開発に向いているケース
仕様変更が特定の箇所で発生する可能性が高い場合
システムの依存関係が密接でない場合（分割可能な場合）
期日にバッファがある（リリース日のリスケが可能な場合）
スパイラル開発に向いていないケース
単一の大規模システム（機能単位に分割して開発するのが難しい場合）
各機能の依存関係が複雑かつ密接な場合
期日がタイト（短期間で開発が必要な場合）
開発手法のメリット・デメリット
上記で、各開発手法についての向いているケースや向いていないケースを見てきましたが、それにくあわえて一般的に以下のようなメリット・デメリットがあります。
上記のような点も含めて、開発手法を選択すると良いと思います。
契約について
請負契約について
請負契約は、仕事の完遂を対価とする契約です。基本的には成果物に対して報酬を払う形となります。
基本的に成果物を決められた期日納品することで対価が発生する形です。また、成果物をどのようにつくるかは、受託した側が決める形となります。
開発プロジェクトにおいては、主に設計、コーディングなどの工程で多く見られる契約形態です。
準委任契約について
準委任契約については、特定の業務を行うことを定めた契約です。請負と異なるのは、業務の遂行自体が目的となり結果や成果物の完成については、責任を求められません。
開発プロジェクトにおいては、主に要件定義部分の支援の時などが準委任契約となるケースが多いです。
契約と開発手法について
開発手法と契約についてですが、こちらについては、相性の良し悪しがあると思います。
以下の表にまとめましたが、請負契約は、成果物を決めて発注するため、仕様の修正が発生したりする開発手法とはあまり相性が良くないです。
特にアジャイル開発は、契約開始時に全ての納品物を決めて見積もることが難しいです。従って、アジャイル開発したいが請負にしてほしいというのは矛盾を孕んでおり、現実的に両方の用件を満たしてやることはほとんどできないでしょう。
請負の特徴として成果物を定義するため、プロトタイプ開発やスパイラル開発とも少し相性が良くないと考えられます。
基本的には準委任契約で良いと思います。信頼できない相手や定義した成果物通りに作ってもらうことが何よりも優先な場合は、請負契約とするのが良いでしょう。
また、きちんと定義すれば、請負契約の方がスムーズなケースもあると思います。例えばプロトタイプ開発のプロトタイプを300万の請負でつくってほしい。仕様もデザインも決まっているという様なケースは請負の方が良いでしょう。
契約は単純に社内で決められている形を踏襲するだけでなく、やりたいことと作りたいものから適切な作り方になる様に開発手法とセットで検討するのが良いでしょう。
社内の手続き（適切なレビューと評価について）
各手続の目的
開発において、社内レビューや申請、承認など様々な手続きがあると思います。そもそも、それらはなぜあるのでしょうか？
プロジェクトにおける申請や手続きの目的
目的は主には以下のようなものに分類されるかと思います。
「法律上必要」「品質管理」「リスク管理」「透明性の担保」「コンプライアンス」「ステークスホルダーの合意」
開発において特に難しいのが、透明性の担保（スケジュール、進捗）、品質管理（要件定義、設計、開発、テストのレビュー）と開発手法です。
多くの企業ではこれまでウォータフォールで開発してきたこともあり、基本的には開始から終了までのスケジュールを細かく作成して、手順に沿って実施していく形だと思われます。
基本的には過去のプロジェクト開発の手法に沿って社内手続きが作られていることが多数です。
上記に示したようなアジャイル開発、プロトタイプ開発などにおいてもウォーターフォールと同様に品質管理をしようとしたり、透明性を担保しようとする破綻するケースもしくは、現場の説明コスト（本来見積もれないものやもう一度直す可能性がある資料を何度も作成する）が、増加する可能性が高いです。
アジャイル開発においては、当然ですが都度、企画、設計、開発をするため見積もりも都度になります。
企画した機能のボリュームによっては、スケジュールがずれる可能性があります。従って、アジャイル開発でもマイルストーンは存在すると思いますが、製品の長期的な開発スケジュールをウォーターフォールのように正確に出すことは開発手法の特性として難しいです。
アジャイル開発の場合は、長期のスケジュールはマイルストーンとして整理して、詳細スケジュールは、直近とその次のリリース程度にとどめるのが適切かと思います。
どうしても詳細なスケジュールや必達のスケジュールがある場合は、ウォーターフォール開発もしくは、スパイラル開発で実施した方が良いと思います。
適切なコストに見合った手続きか
さて、それでは各手続きは、本当にコストに見合っているのでしょうか。
ソフトウェアにおいてこの点を突き詰めていくと、本質的に何が必要か見えてくるかもしれません。
■プロダクトA
・これまでの社内手続きにそって、要件定義、設計、テストケース、全てのレビューをきちんと実施して出したプロダクト
・プロダクトの利用者のレビュー（NPS）は5/10
■プロダクトB
・利用者の手触りと利便性重視で、細かくリリースをして社内手続きよりも機能単位のユニットテスト、開発環境でのテスト、リリース単位での利用者レビューを重視したプロダクト
・プロダクトの利用者のレビュー（NPS）は8/10
本当に必要なのは利用者が評価する品質であり、社内手続きが多くても手触りが悪く、分かりずらいUIであれば、使われません。
もし、皆さんが関わっているものがプロダクトAのような状況であれば、何かを見直す必要があるのかもしれません。
上記は1つの例で、品質においては、障害がない、速度が早い、セキュリティが高いなど利用者から直接見えない点も非常に重要ですが、やはり、利用者が最高と思う価値を提供できることが優れた製品やサービスであり、それこそが、どのプロジェクトにおいても共通に達成すべきゴールです。
終わりに
私は、大企業の発注側、行政の発注側、社内開発、ベンチャーの受注側、受注側（2次受け、3次受け）、発注側のアドバイザリーなど様々な立場、またPM、PdM、開発、営業、ディレクター、分析、マーケティングなどの様々な役割、メンバー、リーダー、部長、役員など様々な役職でも仕事をしてきました。
様々な立場、役割、役職で仕事をして感じることは、プロダクトの開発手法や契約、手続きに正解はありませんが、悪手を避けることはできると思います。上記に書いたような相性の悪い矛盾したプロセスや手順にならないようにプロジェクトのセッティングを工夫することが大切だと思います。
どの役割でプロジェクトに参加しても、最初のセッティングが悪いプロジェクトは、無駄なドキュメント作成が増え、確認コストが増え、プロジェクトの進捗が悪く、メンバーのモチベーションが落ち、そして最終的なアウトプットの品質が良くない傾向にあります。
最初の選択を間違えるプロジェクトは、工数の消費と進捗の遅れ、遅れを確認するためのタスクの洗い出し、再見積り、スケジュール遅延の報告、リカバリーのための会議の多発など芋づる式によくないことが多発しがちです。
結果的に本質的でない作業が増大し、多くの時間を取られます。
そういうことにならないように、皆さんも是非、最初のプロジェクトのセッティングについて、プロジェクトを始める前に、一度立ち止まり考えて、良い選択をしていただきたいと思います。
ご自身だけでなくプロジェクトに関わる多くの人にとって良いものとなると思います。
この記事が気に入ったらサポートをしてみませんか？