システムを一度作り切って終わりにするのではなく、月額で開発の手を確保して、必要なものから順に作っていく形で頼む会社が増えています。 作りたいものが固まりきっていない、業務の変化に合わせて直し続けたい、 社内に開発できる人がいない——といった事情があるとき、区切りごとに見積もりを取り直すより進めやすい形です。
ただ、この形は契約を結んだ時点では「何を作るか」が決まっていないのが前提です。 そのため、走り出したあとの運び方を決めていないと、 依頼がなんとなく広がって本来やりたかったことに手が回らない、 何に時間が使われたのか分からない、といった状態になりがちです。 この記事では、受託開発を手がけるCoconutWorksが、月額で開発を続けてもらう形を選んだあとに発注側が決めておきたい取り決めを整理します。 仕組みそのものと向き不向きは納品のない受託開発（ラボ型開発）とはで扱っているので、ここでは契約後の運び方に絞ります。
結論: 走り出す前に決めておく4つの取り決め
| 決めごと | 何を決めるか | 決めないまま進むと起きること |
|---|---|---|
| 作業範囲 | 対象のシステムと領域、受け付ける相談の入り口、範囲外として扱うもの | 依頼が少しずつ広がり、本来やりたかったことに手が回らなくなる |
| 優先順位 | 依頼を出す窓口、順序を確定させる人、割り込みが入ったときの扱い | 依頼が同時に走り、どれも中途半端なまま月が終わる |
| 進み方の見え方 | 何に時間を使ったかの共有の仕方、区切りの置き方、定期で話す場 | 払っている実感が持てず、成果を社内に説明できない |
| 終わり方 | 解約を申し入れる期限、引き継ぐもの、権限やアカウントの戻し方 | やめたいときにやめられない。続けたくても引き継げる状態になっていない |
この4つのうち、契約書に書かれていることが多いのは作業範囲と終わり方です。 一方で優先順位と進み方の見え方は、契約書の外にある運用の話なので、 決めないまま始まりやすい部分です。実際に困りごとになりやすいのも、この2つのほうです。以下、順に掘り下げます。
最初に食い違うのは「範囲」ではなく「量」
月額の契約でつまずく場面として想像しやすいのは、 「頼んだ内容が契約の範囲外だと言われた」というものでしょう。 しかし実際に先に来るのは、範囲の話より量の感覚のずれです。 発注側は「月額を払っているのだから、思いついたものは順次入れてもらえる」と受け取り、 受託側は「確保した時間の中でできる分」として動く。ここに開きがあります。
たとえば、社内の申請業務をシステム化して使い始めた会社で、 現場から改善の要望が次々に挙がってくる段階があります。 入力項目を増やしたい、承認の経路を変えたい、集計の形を変えたい。 一つずつは小さく見えるため、発注側の感覚では「まとめてお願いできそう」となります。 ところが受託側から見ると、承認経路の変更は影響範囲が広く、 入力項目の追加とは必要な時間が桁違い、ということが起こります。
ここを埋めるのに有効なのは、金額の話ではなく今月の枠でどこまでやるかを月初に合わせておくことです。 契約時に「月にどのくらいの作業量を想定しているか」を、 人数と関わり方（常に見ている状態か、依頼があるときに動く形か）のレベルで確認しておくと、 期待の置き方がそろいます。依頼の量が月ごとに大きく動く見込みなら、その前提も先に伝えておきたいところです。
作業範囲は列挙より「入り口」で決める
作業範囲を決めるとき、やってもらえることを一つずつ書き出そうとすると、たいてい行き詰まります。 何を作るかが決まっていないからこの形を選んだのに、 作業を列挙するのは順序が逆になるためです。現実的なのは、受け付ける相談の入り口を決めるやり方です。
具体的には、対象のシステム（この業務システムとその周辺まで）、 扱う領域（開発と改修は含むが、パソコンの設定や社内ネットワークの相談は含まない）、 関わってよい業務の範囲（データの中身を見るのはどこまでか）といった単位で線を引きます。 この形にしておけば、個別の依頼が来たときに範囲内かどうかを判断でき、 判断がつかない相談が出てきたときには、それ自体が契約の見直しを考える材料になります。
あわせて決めておきたいのが、今動いているものが壊れたときの扱いです。 新しく作る作業と、既に動いているものの不具合対応は、同じ枠から出ていくのか別扱いなのか。 ここが曖昧だと、不具合が続いた月に新しい開発がまったく進まず、 発注側からは何も進んでいないように見える状態になります。 既存システムの維持が主目的なら、継続開発ではなく保守契約のほうが合う場合もあります。 その判断材料はシステムの保守契約で確認すべきことで整理しています。
優先順位は「決める人」を決めると回り出す
この形でいちばん効くのに、いちばん決められていないのが優先順位の決め方です。 月額で手が確保されている状態は社内から見ると使いやすいため、 部署ごとに直接依頼が飛ぶようになりがちです。すると、どれを先にやるかの判断が受託側に残ります。 受託側は業務の急ぎ具合を判断できないので、届いた順や作業しやすい順に手を付けることになり、 結果として「急ぎのものが後回しになっていた」という食い違いが起きます。
対処はそれほど難しくありません。依頼を出す窓口を一か所に寄せ、 順序を確定させる人を一人決めるだけです。役職は問いませんが、 業務の急ぎ具合を判断できる立場の方であることが条件になります。 受託側から「技術的にはこちらを先にしたほうが手戻りが少ない」といった提案は出せるので、案は受託側、確定は発注側という分担にすると回りやすくなります。
もう一つ決めておきたいのは、割り込みが入ったときの扱いです。 期の締めや繁忙期には、予定していた開発より先に手を付けたいものが出てくることがあります。 そのときに「予定していたものを後ろにずらす」と明示するか、 「今月は割り込みを優先して、予定分は来月に回す」と決めるか。 どちらでも構いませんが、押し出される側を明示することが大切です。 これをしないと、両方が進んでいる前提で月末を迎え、どちらも仕上がっていない状態になります。
進み方が見えないと、社内で説明できなくなる
一括の契約と違って、月額の継続開発には「納品」という分かりやすい区切りがありません。 このため、開発の当事者は進んでいる実感を持てていても、社内の他の方や決裁者から見ると何が進んだのか分からないという状態になりやすいです。 契約の更新判断の時期にこの状態だと、成果の有無ではなく説明のしづらさが理由で止まることがあります。
避けるには、区切りを自分たちで作ることになります。 おすすめは月単位で「今月やること」を数件に絞って先に決め、 月末にその結果を並べる形です。件数は多くなくてよく、 むしろ絞ったほうが説明しやすくなります。 あわせて、何に時間を使ったかも共有してもらえると、 調査や検証といった目に見えにくい作業が見える形になります。 実装に入る前の調査は成果物が出ないため、共有がないと「進んでいない月」に見えてしまいます。
報告の頻度は上げすぎないほうが結果的に良いことも多いです。 報告の準備そのものが作業時間を削るためで、 日々の状況はチャットなどで随時見える状態にしておき、 区切りの確認は月次など定期の場で行う二段構えが、負担と安心のバランスを取りやすい形です。
終わり方を、始める前に決めておく
継続を前提にした契約ほど、終わり方の取り決めが要ります。 続く前提で始めるからこそ、事情が変わったときの手順が用意されていないと動けなくなるためです。 決めておきたいのは解約を申し入れる期限、引き継ぐもの、権限やアカウントの戻し方の3つです。
引き継ぐものについては、ソースコードだけでは足りないことが多い点に注意が必要です。 動かすのに必要な設定、外部サービスの契約情報、 構成や設計の分かる資料、そして「なぜこの作りになっているか」という経緯。 このうち経緯は資料に残りにくいため、 引き継ぎの段で改めて用意してもらうよりも、進めながら都度残してもらう取り決めにしておくほうが確実です。 判断の記録を都度残す形にしておけば、担当者が変わる場面でも同じものが使えます。
権限まわりも忘れがちな項目です。開発のためにサーバーや外部サービスのアカウントを預けている場合、 誰の名義で契約しているかを把握しておく必要があります。 受託側の名義で取得したサービスがあると、終了時に移管の手続きが必要になり、 場合によっては移管できないこともあります。 始める段階で名義は発注側で持つことを基本にしておくと、この問題は起きにくくなります。
よくある誤解と、決めていく順序
- 「月額なので、頼む量が増えても費用は変わらない」 — 変わらないのは費用で、こなせる量ではありません。増えた分は他の作業が後ろにずれる形で吸収されます。量が増える見込みが立った時点で、体制を増やすか優先順位を絞るかを相談するほうが穏やかに進みます。
- 「やることが決まっていないから、決めごとも後でよい」 — 作るものが決まっていないことと、運び方が決まっていないことは別です。むしろ中身が決まっていないほど、判断の手順を先に決めておく意味が大きくなります。
- 「関係ができてきたら、細かい取り決めは要らなくなる」 — うまく回っているときには確かに不要に見えます。困るのは担当者が変わったときです。取り決めは、関係が良い時期のために作るのではなく、前提が変わったときのために作るものと考えると位置づけがはっきりします。
- 「引き継ぎは終わるときに考えればよい」 — 終了が決まってから経緯をまとめ直すのは、当事者にとっても負担が大きく、抜けも出ます。進めながら残す形にしておけば、引き継ぎのときに特別な作業が要りません。
決める順序としては、次のように進めると迷いにくくなります。
- ①依頼の窓口と、順序を確定させる人を決める — 契約書とは関係なく決められ、効果が出るのが早い項目です。ここが決まっていないと他の取り決めも運用に乗りません。
- ②受け付ける相談の入り口を言葉にする — 対象のシステム・扱う領域・関わってよい業務の範囲。作業の列挙ではなく範囲の線引きとして書きます。
- ③不具合対応をどの枠で扱うか決める — 新規の開発と同じ枠か別扱いか。既に動いているものがある場合は特に先に決めたい項目です。
- ④月次の区切りと共有の仕方を決める — 今月やることを数件に絞る形と、何に時間を使ったかの共有。社内への説明のしやすさがここで決まります。
- ⑤終わり方を契約書で確認する — 解約の申し入れ期限、引き継ぐもの、アカウントの名義。①〜④と違い、契約書の条項として残しておく部分です。
よくある質問
まとめ
月額で開発を続けてもらう形は、作るものが固まっていない段階でも動き出せる代わりに、運び方を決めておかないと進み方が見えなくなるという性質を持っています。 作業範囲は列挙ではなく相談の入り口として決め、優先順位は確定させる人を一人決める。 月次で区切りを作って何に時間を使ったかを共有し、終わり方は始める前に確認しておく。 この4つがそろっていると、依頼の量や担当者が変わっても同じやり方で続けられます。 契約の形をどう組むかの段階からのご相談も歓迎です。システム開発・業務改善サービスのページもあわせてご覧ください。ご相談・お見積もりは無料です。
