ソニックガーデンの事業の柱であり、プログラマが活躍するメインステージである「納品のない受託開発」。月額定額でソフトウェアの企画・開発・保守などを一貫して行うというベースがありますが、一つの決まった形があるわけではありません。お客さまの事業フェーズ、チーム体制、業界特有の課題によって、その姿は柔軟に変化します。

本コラムでは、プログラマの視点から、4つの異なる納品のない受託開発の「リアルな舞台裏」を紹介します。これらは、日々の開発プロセス、お客さまとのコミュニケーション、そして技術的な意思決定がどのように行われているかを示す具体例です。

読者であるプログラマの皆さんにとって、パートナーとして、お客さまの事業に深く伴走する納品のない受託開発のリアルを感じ取っていただければ幸いです。

そもそも納品のない受託開発とは？

納品で終わりとせず、お客さまと共通のゴールを追い続ける

ソニックガーデンが提供する納品のない受託開発は、従来のシステム開発が抱える課題を解決する、月額定額制のビジネスモデルです。従来の一括請負型開発は「納品」がゴールであるため、発注側（スタート）と開発側（ゴール）で目的が異なり、多くの問題を生んでいました。例えば、変化に対応できない厳格な要件定義、納品後の高額な改修コスト……などです。

納品のない受託開発は、この「納品」という概念をなくしています。開発側はパートナーとしてお客さまに寄り添い、事業側と開発側が「共通のゴール」を持つ一つのチームとなります。これにより、要件定義や労働集約的な見積もり（人数と日数で費用を算出する）は不要になります。業務とソフトウェアを熟知したチームが継続的に関与するため、事業の変化に柔軟に適応し、迅速な改修や最適な提案を行えるのです。

ベースとなる体制

納品のない受託開発は様々な形で提供されていますが、ベースとなる形と特徴を紹介します。

まず、体制面では3つの特徴があります。

• ・ 開発責任者
  第一に「開発責任者」がCTO（最高技術責任者）として経営者の右腕となり、事業フェーズに応じてプロトタイプ開発からチームマネジメントまで担います。

• ・ 開発チーム
  第二に「開発チーム」は、全員がお客さまと直接対話し、設計から実装まで担当。これにより、スピーディーで業務理解の深い、内製チームのように機能します。

• ・ クラウド基盤
  第三に、これまでの開発実績、経験値をもとにした、安定したクラウド基盤をすぐに提供します。

ベースとなる開発プロセス

続いて、開発プロセスです。開発プロセスにおいては、お客さまによる時間管理を不要とします。

• ・ 相談期間
  開発に入る前にお客さまの課題や事業の方向性を伺いながら、必要なソフトウェアの企画や設計を行います。

• ・ ロードマップミーティング
  四半期から半期に一度、経営層も交えて中長期の方向性を決定します。

• ・ 定例ミーティング
  週次から四半期ごとの「定例ミーティング」では、デモで成果を共有し、その場で次回の仕様と優先順位を決めます。

• ・ 開発期間
  ミーティング間の「開発期間」はチームに一任され、非同期連絡を基本に高品質な開発に集中します。

以上が納品のない受託開発の概要になりますが、あくまでも様々な案件の共通点をまとめた説明になります。納品のない受託開発は10案件あれば、10の形が存在します。

そこで、ここからは4つのケースをもとに、納品のない受託開発の実態を見ていきましょう。

ケース1： 「作るべきもの」を共に探す、リプレイスの要望から始まったアプリ開発

[プロジェクト概要]

・ 体制: お客さま/3〜4名＆ソニックガーデン/開発責任者1名＋プログラマ3名
・ 特徴: 開発開始前に数ヶ月の「すり合わせ期間」を設けた

このプロジェクトは、既存アプリがメンテナンス不能になったため、リプレイスしてほしいという依頼から始まりました。当初は、現行の機能をそのまま新しい技術で作り直す、単純移植の予定でした。

数ヶ月にわたる「作らない」すり合わせ期間

しかし、ヒアリングを重ねるうち、深刻な問題が発覚しました。それは、「現行アプリが、お客さまの本来やりたいことを実現できていない」という事実です。さらに、お客さま自身も「どうすれば実現できるか（正解）」が分かっていない状態でした。

もし我々が「納品」を目的とする開発会社であれば、言われた通りにリプレイス作業を行い、完了していたでしょう。しかし、我々の目的は「お客さまの事業価値に貢献する」ことです。

そこで私たちは、開発（コーディング）をいったんストップするという大胆な提案をしました。そして、数ヶ月間、週1回のミーティングを「我々は何を作るべきか」という根本的なすり合わせのみに充てたのです。

この「すり合わせ期間」には、開発担当のプログラマ2名に加え、初回相談を担当した者、さらにデータ移行の専門家もアサインしました。お客さま側も意思決定者、システム担当、事務方など関係者が集結し、「本来の目的」を徹底的に議論しました。

このすり合わせ期間中、プログラマの役割はコードを書くことではありません。議論が抽象的にならないよう、パワポや簡単なモックアップなど「目に見えるもの」を素早く作成し、それを叩き台に認識合わせを進めることでした。これは、プログラマが「コミュニケーションツール」を設計・実装する行為とも言えます。

事業フェーズに合わせた体制の変化

方向性が見えた後、ようやく開発フェーズに移行しました。この際、私たちは「X月X日にリリースする」という厳格な納期を定めませんでした。開発途中で新たな課題や「やはりこうしたい」という要望が出てくるのは必然です。もし納期を固定すれば、「間に合わせること」が目的化し、本質的でない機能や、品質の低いコードが生まれてしまいます。

「納期を約束しない」という進め方は、一見するとお客さまにとって不安に思えるかもしれません。しかし、これこそが、不確実性の高いソフトウェア開発において、最終的により良いものを作るための合理的な選択です。これが受け入れられたのは、数ヶ月にわたる「すり合わせ」を通じて、お客さまとの間に強固な信頼関係が築かれていたからと言えます。

リプレイス後、必要な機能が揃いサービスが安定稼働したフェーズで、私たちは開発体制を縮小しました。これはお客さまの事業特性（急拡大を目指すモデルではない）に合わせた判断であり、開発コストを抑え「持続可能性」を担保するパートナーとしての動きです。

現在は、お客さま側のデザイナーと密に連携し、UI/UXを改善するフェーズに移行しており、プロジェクトの成長に合わせて我々の役割も柔軟に変化し続けています。

ケース2： 「即決」と「最善の塩梅」を追求する、1対1の少数精鋭プロジェクト

[プロジェクト概要]

・ 体制: お客さま/事業責任者 1名 ＆ソニックガーデン/開発責任者 1名
・ 特徴: 意思決定者が一人のため、コンパクトでスピード感を持つ開発体制

我々の開発スタイルの中でも、特にコンパクトな体制の事例です。お客さま側の窓口は事業責任者ただ一人。ソニックガーデン側もミーティングや開発などを行うのは基本的に開発責任者が一人という、ほぼ1対1の体制で10年以上続いているプロジェクトです。

“週刊連載”を支える週1定例

このプロジェクトの基盤となっているのが、週に1回、1時間の定例ミーティングです。我々の開発は、このミーティングをアウトプットの「締め切り」とした週刊連載のようなリズムで進みます。

ミーティングの基本的な流れは以下の通りです。

1. 1.近況確認: いわば雑談のようなものですが、プログラマにとっては重要な情報収集の時間です。お客さまが「決算でバタバタしている」と言えば、「今週は検討に時間を要するタスクをお願いするのはやめよう」と判断します。相手のリソース状況やコンディションを把握し、コミュニケーションの密度やタスクの量を調整するのです。

2. 2.デモンストレーション: 前回の定例ミーティングから今日までに進めたこととして、開発した機能を実際に動かしてデモを行います。ここで「イメージと合っていますか？」とリアルタイムに確認を取ります。

3. 3.ディスカッション: お客さまには事前に「今週相談したいこと」をドキュメントにまとめてもらっています。それをベースに、「次は何をすべきか」「この機能はどうあるべきか」をディスカッションし、方向性をすり合わせます。

4. 4.ネクストアクションの決定: すり合わせで合意した内容をタスクに設定し、優先度を確認します。次の定例ミーティングまでにやるべきこと（開発する機能、必要な設計など）が決まったら、ミーティングは終了です。

お客さまが多忙で大きな相談事がない週は、デモと簡単な確認だけで「じゃあ来週までにブラッシュアップしてきます」と、わずか10分でミーティングが終わることもあります。短い時間のミーティングでも、ソフトウェア開発が前に進み、事業の成長に貢献できることが大切です。ただ時間を埋めるためのミーティングはしません。

「最善の塩梅」を見極めるプログラマの腕

このプロジェクトでプログラマに求められる最も重要なスキルは、「仕様を固める能力」ではなく、「最善の塩梅（あんばい）を見極める能力」です。

お客さまからの要望は、「こんな感じのものが欲しいんですよね」といった、非常に抽象的なレベルで来ることがほとんどです。明確な仕様書は存在しません。

私たちは、その要望の背景にある真の課題を想像し、「おそらく、こうした機能が/こうした改修が一番いい感じだろう」という「最善の塩梅」を自ら考え、その場で提案しながら、その週に開発するタスクを決めます。

これは、「仕様を細かく詰めてから作る」という進め方とは真逆です。納品のない受託開発では、「まず作って見せた方が、議論が早くて正確だ」という考え方が根底にあります。

スピーディーなリリースサイクルと品質担保を同時に実現

開発のサイクルも非常にシンプルです。

• 1. 1.ミーティングで仕様がすり合わされる。
• 1. 2.プログラマが開発し、デモですり合わせる。
• 1. 3.デモでイメージに相違がなければ、社内の別のプログラマによるコードレビューを受ける。
• 1. 4.レビューの指摘を修正し、本番環境へリリースする。 （1へ戻る）

特徴は、お客さまによるデモの確認の後に、別のプログラマによるコードレビューを行っている点です。お客さまにレビュー前のデモを見せることで、万が一の仕様変更による手戻りコストを最小限に抑えられます。そして、社内のコードレビューによって技術的な品質（保守性、堅牢性など）もしっかり担保しているのです。

ケース3： 業界特有の事情に寄り添いながら進める、中規模BtoCサービス開発

[プロジェクト概要]

・ 体制: お客さま/プロダクト担当、CS担当など複数名 ＆ ソニックガーデン/開発責任者1名＋プログラマ2名
・ 特徴: 業界特有の事情が複雑に絡み合い、即決が難しい。24時間稼働。

介護業界向けのBtoCサービスの開発プロジェクトです。プロジェクトとしては中規模程度で、ソニックガーデン側も3名（開発責任者1名＋ベテラン1名、若手1名）のチームで臨んでいます。

目的別に分化した3つのミーティング

関係者が多いため、ミーティングは目的別に3種類に分化しています。

1. 1.開発ミーティング (週1): 開発チーム全員が参加。ケース1と同様、進捗デモと直近のタスクを決定する「実務」の場です。
2. 2.プロダクトミーティング (週1): 開発責任者のみが参加。ロードマップの議論や、「こんな課題があるのだが」といった「ふわっとした相談」を受ける場です。時にはお客さまのカスタマーサクセス(CS)担当者も参加します。
3. 3.デザインミーティング (隔週): 外部デザイナーも交え、UI/UXの改善を議論する専門的な場です。

「即決できない」前提で動く

このプロジェクトの最大の特徴は、「その場で即決できない」ことが多い点です。介護現場の業務フローや、ユーザーである高齢者の感覚など、業界特有の観点が強く求められるため、お客さま側も「他のメンバーと相談しないと判断できない」ことがほとんどなためです。そのため、必要な確認事項や、確認にかかる時間なども含めて、開発のロードマップを敷くようにしています。

また、お客さまは「解決策（機能案）」を自分たちで考えすぎてしまう傾向がありました。しかし、練り上げられた機能案が、既存の設計と合わなかったり、技術的な制約で非効率だったりすることも少なくありません。

そこで私たちは、「解決策ではなく、課題ベースで早めに相談してください」と積極的に働きかけました。プロダクトミーティングを「壁打ち」の場として機能させ、お客さまが考えすぎる前に、最適な解決策を共に模索するプロセスを確立したのです。

24時間稼働を支える技術的な判断

プログラマにとって技術的に緊張感があるのは、このサービスが24時間稼働し、データ量が膨大である点です。夜勤の介護士も利用するため、深夜でもアクセスが止まりません。

ここで求められるのは、奇抜な技術ではなく、「王道で堅実なコード」です。うっかりパフォーマンスを劣化させるコードをリリースすれば、即座に現場の業務に支障が出ます。

そのため開発責任者は、メンバーのコードレビューや設計相談、そして技術的負債の返済やインフラメンテナンスに関するお客さまへの説明などに多くのリソースを割いています。

また、リリースタイミングも慎重に決めるようにしています。現場のユーザーが混乱しないよう、大きなUI変更が伴うリリースを連続させないように調整するのです。技術的には「できるけど、今はやらない」という、事業的な判断もプログラマの重要な役割となっています。

ケース4： 大規模・混成チームを牽引する、テックリードとしての開発スタイル

[プロジェクト概要]

・ 体制: 5つを超える開発チーム、ソニックガーデンからは複数人のプログラマが参加、全体で数十人の大規模な開発体制。ソニックガーデンのプログラマは「テックリード」としての役割も担う
・ 特徴: お客さま側のプログラマ、外部委託プログラマとの「混成チーム」

今回紹介するケースのなかでは、最も大規模なエンタープライズ案件です。ここでは、我々は単なる開発チームとしてではなく、プロジェクト全体の技術を牽引する「テックリード」としての役割も担っています。

チームは、我々のプログラマ、お客さま側のプログラマ、そして外部の業務委託プログラマによる「混成チーム」です。

テックリードの役割：「足りないところを補う」

この体制におけるソニックガーデンのプログラマの役割は多岐にわたります。キーワードは「足りないところを補う」です。

• ・ 自らもコードを書く: テックリードとしての役割も担いますが、それぞれのプログラマはプレイヤーとして開発実務もこなします。
  
• ・ 開発文化の浸透: 最も重要な役割の一つが、ソニックガーデンが大切にしている開発文化「コードレビュー」の浸透と実践です。コードレビューは単なるバグチェックではありません。なぜこのような設計にするのか、なぜテストコードが重要なのかといった、我々の開発文化や設計思想を、背景の異なる混成チームのメンバーに粘り強く伝える時間でもあります。
  
• ・ マネジメントと育成: チームメンバーの状況を常に観察し、設計の壁打ち相手になります。時には、お客さま側の若手プログラマをあえてリーダーとして立てることもあります。我々は一歩引いてファシリテーションを任せるなど、チーム全体の技術力を底上げする「育成」の役割も担います。
  
• ・ 設計という価値提供: 目先のタスクをこなすだけでなく、次の大規模機能改修に備え、アーキテクチャや設計を考えることに頭を使います。コードを書いていない時間も、将来の技術的負債を防ぎ、プロジェクトの健全性を保つための重要な「価値提供」になります。
  
• ・ 技術的負債の可視化: お客さまからは見えにくいライブラリのアップデートやリファクタリングは重要です。その重要性を説明し、機能開発のタスクとバランスを取りながら時間を捻出するのも、テックリードの仕事です。

柔軟にコミュニケーション設計をする

大規模チームの透明性と一体感を維持するため、コミュニケーションも柔軟に設計しています。

• ・ 朝会 (週3回): 全員参加。各チームの状況を共有し、透明性を確保します。
• ・ 振り返り (月1回): チーム持ち回りで実施し、得られた学びを全体に共有します。
• ・ チーム定例 (週1回): 各チームが、担当する機能についてお客さまとすり合わせます。
• ・ 合宿: 複雑な仕様や設計を集中して議論するため、オフラインでの合宿を企画・実行することもあります。

このケースでは、単なる開発者に留まらず、プロジェクト全体の技術的な継続性、健全性とチームの成長へもコミットしています。納品のない受託開発だからこそできる、価値提供の一例と言えるでしょう。

---

以上、4つのケースを通じて、納品のない受託開発の実態を紹介しました。この4つのケースだけを見ても、体制や必要なミーティングの数、開発サイクルなどが全てバラバラだということがわかるかと思います。

それは、それぞれのお客さまにとって本当に価値のあるソフトウェア開発を提供しているからこそ、とも言えます。お客さまの事業成長にとって、真に価値のあるソフトウェア開発を行っていく。時には、開発せず、すり合わせに時間をかけることもあります。

納品のない受託開発を担うプログラマは、コードを書くだけでなく、お客さまの真の価値になることを常に考えながら、密にコミュニケーションも取っていきます。同時に、柔軟に対応するための設計力や高い技術力も求められます。

だからこその難しさもありますし、だからこそのやりがいもあります。何より、成長し活躍する場として、納品のない受託開発は、プログラマにとってとてもいい環境を構築できるビジネスモデルでもあります。

納品のない受託開発を担うソフトウェア開発者の仕事に興味を持った方は、採用への応募をご検討ください。

採用サイトトップはこちら↓
https://www.sonicgarden.jp/join_us/programmer