よくある課題
1.過去に外注開発したシステムが事業に合わなくなってきた
事業立ち上げ時に、懸命に要件定義をして一括開発したシステム。しかし、事業の方向性を試行錯誤する中で、結果的に現状のビジネスモデルにふさわしくないシステムになることもあります。ほとんどの開発会社は納品して終わりなので、改修する際はまた要件定義をして、安くはない改修費用を支払わなくてはなりません。このように、変化に対応できないシステムは、事業の重荷となってしまうのです。
2.社内の開発責任者が退社。システムがブラックボックスに…
事業立ち上げのときには社内に優秀なプログラマがいたので、内製でシステムを開発。しかし事業が軌道に乗り始めた矢先、そのプログラマが退社することに…。結果的に、システムを把握できる人が社内にいなくなり、ブラックボックス化。そうなってしまうと、改修しようにもできず、バグや不具合の放置、ビジネスの成長にあわせた機能追加などができない状態に陥ってしまいます。
3.開発会社に改修を依頼するも、技術力不足から事態が悪化
開発会社に改修を依頼したとしても、技術力不足により、バグが改善されるどころか増加してしまうパターンも実は少なくありません。改修に次ぐ改修で、コストが増える割には一向に改修の兆しが見えないうえに、複雑なプログラムができあがっていく。最悪の場合開発会社側から「改修できない」と白旗を振られる…ということもあります。
4.汎用パッケージを導入するも、改修コストがかさむ
事業立ち上げ時に、簡単に、安価で導入できるという理由で汎用パッケージのシステムを導入することもあるでしょう。しかし、汎用パッケージは導入が簡単な分、柔軟性に難があり、事業変化にあわせたカスタマイズが難しいケースが多いのです。そのため、度重なる改修でコストが嵩んだり、販売代理店の技術力では対応できなかったりなど、事業継続の点において、大きな課題を抱えることになります。
本質的な問題 「納品」を前提とした開発を行っているから
既存システムで抱える課題感は上述の通り、企業によってさまざまな背景があります。しかし、改善がうまくいかない本質的な理由として納品を前提とした開発を行っているため、と私たちは考えています。納品を前提とした開発を行うことでのデメリットは大きく２つあります。
1.事業への理解が不足してしまう
既存システムを改修するうえで最も大切なのは、事業への深い理解です。その事業が何を目指しているのか、どのようなコアバリューを提供しているのかなどを理解してはじめて、最適なシステムへの改修が可能になるのです。しかし「とりあえず目の前の問題を解決しよう」と目先の要望だけの改修を繰り返していると、だんだんと本来の設計意図がわからなくなり、どんなに時間を費やしても改善の実感を得られない、重荷のままのシステムになってしまいます。
こうした問題が起きる背景として、要件定義をベースに一括請負で開発を行う、開発会社のビジネスモデルがあります。開発会社からすれば、事業の成否より、できるだけ多くの要件を盛り込んだシステムの改修を行ったほうが利益を得られます。ですので、事業への理解が不足したまま、決められた要件通りに「改修して納品する」ことをゴールとした開発を行ってしまうのです。
2.要件定義が必要になってしまう
既存システムの改修には、どこに問題があるか正確に把握する必要がありますが、他人が作ったプログラムを分析するには高度な技術力、幅広いプログラミングの知識が必要になります。生半可な技術力で改修を手掛けると、逆にバグを増やしてしまったり、以前よりも余計に複雑なプログラムができあがったりしてしまいます。
しかし、発注前に技術力の程度を把握するのは難しいものです。相談をしようにも、納品を前提とした開発を行うためには、要件定義が必要になってくるためそもそも相談すること自体が難しくなってきます。特にシステムを開発した人がいなくなってしまった場合や依頼していた開発会社がなくなってしまい、システムがブラックボックスとなってしまった場合、要件定義を作成することは不可能に近いでしょう。
継続的な開発を前提にした「納品のない受託開発」
既存システムの改修に関わる問題を解消するために、ソニックガーデンでは「納品のない受託開発」をお客さまに提供しています。この開発スタイルの大きなポイントは、プログラマが顧問としての役割を担うことで“継続的なシステム改修”がセットになっている点です。1回でドカンと既存システムを改修する仕組みと違い、相談しながら少しずつ再構築していくため、要件定義も必要なく、ユーザーの反応や事業状態にあわせて柔軟に開発していくことができます。
特に既存システムの改修の場合、すでに動いている事業をできるだけ妨げないように、少しずつ再構築していく必要があります。そのために、顧問プログラマとの綿密なコミュニケーションは欠かせません。事業が抱える技術的課題を解消し、かつその先も継続的に変化に対応しながらシステム開発ができる仕組みを納品のない受託開発が実現します。
「納品のない受託開発」の特徴
「納品のない受託開発」で既存システムを再構築するメリット
1.事業への理解から始め、本質的な課題を見極める
「納品のない受託開発」では、既存システムの技術的な問題点を分析する前に、顧問プログラマがまずは事業を理解することからスタートします。なぜなら、本当に事業にとって必要なシステムはどういうものか、その結果ユーザーに対してどのような価値を提供したいのか、が明確でないと正しい改修案を提案できないからです。ですので相談の際は、要件定義や既存システムの細かな仕様書の事前の提出は不要です。既存システムの改修を目指すのではなく、その先の事業成長とユーザーへの価値の提供を目指した開発を行うために、事業への深い理解を大切にしています。
2.つぎはぎの改修ではなく、根本から改善する
既存システムの課題の分析をしたうえで、納品のない受託開発では、ほとんどの場合でシステムを再構築する判断をしています。なぜなら、継続性を視野にいれずに開発されたシステムを、つぎはぎで直すだけでは根本的な改善には至らないからです。社内プログラマがいなくなり、ブラックボックス化してしまったシステムも同様です。事業を妨げないように、優先度を付けながら再構築を行い、継続的に変化に対応できるシステムへと生まれ変わらせる。一括開発ではなく、納品のない受託開発だからこそこうした柔軟な開発が可能なのです。
3.継続的に変化に対応できる仕組みを手に入れる
納品のない受託開発は、既存システムを再構築しておしまいではありません。その後も事業の変化にあわせて、システムを細かくアップデートし続けながら、より最適なシステムへと育てていきます。既に取り組まれている事業だからといって、そうした仕組みが手に入らないわけではありません。ソニックガーデンの高い技術力を持った顧問プログラマが、細かくコミュニケーションを取りながら、ユーザーにとっても、社員にとっても最適なシステムであり続けるようにサポートします。
主な事例紹介 「既存システムの再構築×納品のない受託開発」の事例
事例1: 株式会社ユーフォリア様 「納品がないから、ずっと仲間」。納品のない受託開発が生む信頼関係
抱えていた開発課題 スピーディーな開発体制の構築が必要だった
我々が開発・運営するONE TAP SPORTSは、アスリートのコンディションやトレーニングデータなどを登録し、管理するSaaS型のシステムです。アスリート一人ひとりの活動や状態を入力し可視化することで、ケガの防止に役立てるだけでなく、チームのコミュニケーション活性化やデータに基づいたマネジメントを実現。チームのパフォーマンスの向上を目的としています。
ONE TAP SPORTSは、実はラグビー日本代表からのオファーをきっかけに、2012年にリリースされました。スポーツサイエンスの浸透もあり、今はラグビーだけでなくプロ野球球団やJリーグのクラブなど、多くのスポーツチームが導入しています。
その一方で、求められる機能や継続的な改修などの要求度が高まり、スピード感のある開発体制とシステムの構築が必要になっていました。そこで、知人の紹介を通じて、ソニックガーデンに相談することになったのです。
納品のない受託開発との出会い 仕様書に時間をかけない。本質と向き合うから、スピード感も出る
ソニックガーデンの第一印象として、企業文化がとてもいい企業だと感じました。場所や時間にとらわれずに仕事をするスタイルもそうですし、何より一人ひとりの主体性や責任感、当事者意識を持って開発に関わっているところが素晴らしいと感じたのです。
それから、我々が求めていたスピード感のある開発体制についても、期待通りのものを提供してくれました。仕様書を固めることに時間を割くのではなく、とにかくスピーディーに、優先順位の判断や開発のために時間を使う。物事の本質と向き合いながらシステム開発を行う考え方が我々にもフィットして、素晴らしいパートナーと出会えたと実感しました。
納品のない受託開発にしてよかったこと スポーツチームからのハイスピードな要求にも対応できる開発チームに
日本代表レベルのプロアスリートたちは、日々ものすごい質と量のトレーニングを重ねています。そうした環境の中で寄せられる開発依頼は、ハンパじゃないハイスピードとハイプレッシャーです。選手サイドの依頼意図を深く理解し、どのようなシステムで実現するか、ソニックガーデンと何度もディスカッションを重ねていきました。その過程の中で、我々とソニックガーデンが、単なるパートナーではなく、1つの開発チームとして形になっていくのを実感したんです。ソニックガーデンの顧問プログラマも、実際に試合に足を運び、選手やスタッフの生の声を聞くなど、より深い理解に努めてくれました。
ディスカッションの場で、我々が機能提案を行うと、顧問プログラマからはよく「何のためにその機能が必要なんですか？」と質問が返ってきます。納得のいくまで議論ができないと、開発には進まない。めんどくさいと思うこともあるんですよ（笑）。でも、そのめんどくささが、価値なんですよね。そうやって、問いかけを受けながら「なぜ？」を繰り返すことで、新たな視点を手に入れることもできますから。
納品がない、ということはずっと仲間でいられるということ。ONE TAP SPORTSを、今後アスリートだけでなくビジネスパーソンやシニア層も使えるスポーツテックにできないか、という構想もあるんです。そんな大きな夢を、これからもソニックガーデンと追いかけていきたいと考えています。
事例2: 株式会社ワーク・ライフバランス様 顧問プログラマが気づかせてくれた、自分たちのコアバリュー
抱えていた開発課題 完成したシステムを使って「こうすればよかった」と悔しくなることがあった
弊社が行っているワーク・ライフバランスコンサルティング（以下、WLBC）のノウハウを学ぶ場として提供しているWLBC養成講座。この養成講座の運営を管理するシステムとして「WLBC養成講座会員サイト」があるのですが、かつてこのサイトに大きな課題を抱えていました。というのも、以前は既存のパッケージをカスタマイズして使っていたため、不必要な機能も残り、受講生から使い方の問い合せばかりが殺到する…という状態に困っていたのです。
運営を担当する社員も「システムを使うと余計に手間がかかる」と言うほどで、システムの再構築は今後の事業成長において必須でした。しかし、刻々と変わるビジネスの状況に応じて、その度に要件定義をするのは難しいものです。過去にも、要件定義をして完成したシステムを使って「もっとこうすればよかった」と悔しくなった経験もしていました。事業を理解し、細かく軌道修正しながら継続的に開発を行ってくれる会社があればいいのに…と探していたところ、「納品のない受託開発」を知ったのです。
納品のない受託開発との出会い 開発要件ではなく「事業のコアは？」という質問からスタート
最初にソニックガーデンとの打ち合わせをしたとき、「事業のコアな部分を教えてください」と質問を受けたことは覚えています。そして、実際に事業についてお伝えすると、そのコアの部分を抑えた必要最低限のシステムができあがってくるのです。
そのシステムを実際に触ってみて、違和感があれば話し合いながら軌道修正をしていく。納得がいく機能になれば、また次に必要な機能を開発していく。そうした開発の進め方はとても心地のいいものでした。「完成したシステムでまた後悔したらどうしよう…」という不安を抱く必要がなくなり、安心してシステム開発を前に進めることができました。
納品のない受託開発にしてよかったこと システムへの不安がなくなり、新たなチャレンジを後押ししてくれる
顧問プログラマは、私たちの事業状況を深く理解し、先々まで見据えて開発を進めてくれます。リプレース（再構築）にあたっての会員の移行手順も、リスクのない方法を考えて進めてくれました。
システムをリプレースする前は、「サービスにシステムが追いつかないんじゃないか…」という不安があって、新しいチャレンジをためらうこともありました。でも、ソニックガーデンとのシステム開発を通して「足踏みせずにやるべきことを突き詰めていくことが大事」だと教わったんです。
それに、リプレースによって受講生からの問い合わせ対応も減ったことで、講座のあるべき姿に向けた仕事もできるようになりました。単なるシステム開発で終わらず、事業成長や新たなチャレンジを後押ししてくれる。これからも、ワーク・ライフバランスの実現のために、ぜひソニックガーデンに協力いただきたいと考えています。
ご契約までの流れ
無料の「相談期間」を通じてお互いを理解する
「納品のない受託開発」は、お問い合わせ頂くことから始まります。初回の打ち合わせでは、私たちから「納品のない受託開発」について説明させて頂くと共に、お客さまが検討されている事業の概要や現在の課題、将来のビジョンについて説明して頂きます。
次のステップでは、すぐに開発したい機能や画面の要件について話すのではなく、お客さまの事業プランをもとに、事業が市場から必要とされているのか、事業の検証にソフトウェアが必要かどうか、今開発すべきかどうか、そういったそもそもから検討します。
私たちはITやソフトウェアに関する専門家です。お客さまの考えている課題やビジョンに対して、より効率的な方法やツールを紹介することが出来るケースが多くあります。そのためにも、お客さまの事業の本質的な部分について私たちも理解する必要があります。
お客さまの事業について深く議論しながら、お互いに理解を深めて本当に必要なソフトウェアは何かを見極めていくプロセスになります。このプロセスは無料の「ご相談期間」として、一切の費用は頂いていません。（長期に渡る場合は有償になる場合もあります）
ご相談期間では、定期的に打ち合わせを行います。新規事業であれば、ターゲットやニーズの明確化などを行い、業務改善であれば、業務や役割の見える化などを行います。この期間では私たち開発サイドよりも、お客さまの方に宿題が多く発生することになります。
この期間は最低でも１ヶ月、長くて半年もかかるケースもありますが、本当に必要なソフトウェアの肝を見つける大事な期間です。検証が進み、後はソフトウェアさえあればという状況になったら、次のステップとしてようやくソフトウェアの開発に進みます。
契約開始一ヶ月目で合う、合わないを判断
相談期間を経た上で、お互いに納得がいったら本契約を結ばせて頂きます。
最初に作るのは、最大で３ヶ月以内で作れる範囲の、ユーザが使い始めることのできる必要最小限の製品です。その際の設計では、必要最小限の機能から期間を出すのではなく、３ヶ月という期間に合わせて必要最小限の機能の優先順位が決まります。
３ヶ月で思うまま全ての機能は実現できないかもしれませんが、事業を次に進めるための機能に絞り込んで確実にユーザに届けることを重視しています。ユーザが使い始めることが出来れば、そこからまた新しい発見があるので、その先の計画もまた変わるからです。
３ヶ月分の機能の絞り込みが済んでソフトウェア開発が始まると、私たちは毎週の定例ミーティングを行うようになります。事前にすべての詳細までは決めずに、その定例ミーティングで１週間分だけの設計を行います。そこで翌週までに開発されるものが決まります。
私たちは次の定例ミーティングの時間までに、前回のミーティングで決めた仕様をもとにソフトウェア開発を行います。ミーティングからミーティングの１週間の間は、弊社謹製のオンラインのツールを通じてコミュニケーションをして質問のやりとりなどを行います。
月額定額で「顧問料」のような形で「納品のない受託開発」の費用を頂きますが、それがどの程度のパフォーマンスなのか、担当してくれる「顧問プログラマ」との相性はどうか、などが気になると思います。
そこで、契約後初月の１ヶ月目のみ、契約を途中解除した場合費用は頂戴いたしません。この１ヶ月目だけでも、定例のミーティングは３〜４回は行いますし、実際に動くソフトウェアまで２週目くらいから出来上がります。そこでの開発の雰囲気や進み具合がこの先も続くことで満足できそうかどうか判断して頂きます。
（問題なく２ヶ月目以降も契約が続く場合は、１ヶ月目から月額費用が発生いたします）
月額費用の内訳と休止期間について
ソフトウェアはクラウド環境に用意して、お客さまには実際に動くソフトウェアを使って進み具合や動きを確認してもらいます。これは正式にユーザが使い始めた以降も同じように続きます。開発と保守・運用に切れ間がないのが「納品のない受託開発」です。
月額費用は、顧問サービスの月額固定費と、ユーザが利用する「本番環境」の運用費の合算です。本番環境の運用費は、求められるサービスレベルに応じた金額を算出します。
顧問サービスの月額固定費は契約が続く限り発生しますが、たとえば営業に力を入れるため一時的に開発を止めたいといった状況に対応するために休止期間の制度もあります。
たとえ休止期間だとしても契約は続くため、本番環境の運用や問題発生時の対応は即座に行います。また、休止期間から通常の開発に戻すこともできるのでご安心ください。
お支払いは、月末締めの翌月払いです。そして気になる料金ですが、まずは「納品のない受託開発」に共感して頂くことが大事だと考えているので、掲載はしておりません。