私たちが取り組む「納品のない受託開発」では、お客さまの真のパートナーとなって事業を支え続けるために、変化に強くて保守しやすいソフトウェアの実現を目指しています。

そこでは企画の提案から、保守運用まで分業せず、すべての工程を担います。とりわけ自らコードまで書くことを大事にしており、その仕事を「顧問プログラマ」と呼んでいます。

お客さまへのミッションとして「一緒に悩んで、いいものつくる」としている通り、私たちはソフトウェアをつくることだけでなく、お客さまと同じ目線で問題解決に向き合うことを価値としています。

直接お客さまと対話できる、分業しないでコードを書く、ソフトウェア全体の設計ができる、理不尽な作業や無駄なドキュメントがない、それがソニックガーデンのソフトウェア開発の仕事です。

ビジネスモデル「納品のない受託開発」

ソニックガーデンが取り組む「納品のない受託開発」は、お客さまと開発者の双方を幸せにするために考え出したビジネスモデルです。(お客さまから見た「納品のない受託開発」の特徴は こちら )

開発と運用を繰り返し、続けていく

「納品のない受託開発」では、継続的に相談にのりながら仕様を一緒に考えます。言われたものをただ作るのではなく、より良いものになるよう私たちからも提案します。また、開発だけではなく、安定的な運用まで責任を持ちます。開発と運用をわけないことで、柔軟に対応していくことができます。

分業せず、すべての工程を担当する

「納品のない受託開発」では、どんなシステムを作ると事業成長に繋がるのか、その段階から相談にのります。プログラマたちが新規事業や業務改善の知見を持ち合わせているため、伝言ゲームによるコミュニケーションロスは発生しません。自ら開発して保守し続けるからこそ、良いソフトウェアを作ります。

働く時間ではなく、成果を提供する

「納品のない受託開発」で提供するのは、開発時間や機能数ではなく、システムによって得られる価値です。そのため事業の成長に合わせて開発以外に役割を変えることもあります。その価値を時間で換算しないので人月ビジネスとは逆で、時間あたりのパフォーマンスを上げることで自身の価値が高まります。

なぜ「納品のない受託開発」に取り組むのか

納品を前提とした一括請負のシステム開発では、動くシステムに価値を求める発注側と、納品するシステムに価値を置く受注側で目指すゴールが違っていることで様々な問題が生まれています。私たちは「納品のない受託開発」で、お客さまとプログラマの双方が幸せになれるシステム開発を実現したいのです。

ビジネスモデルの抱える構造的な欠陥

一括請負のシステム開発では、要件定義と計画通りのシステムを納品して開発会社は利益を得ます。しかし、お客さまにとっての利益は、納品されたシステムが事業や業務に価値をもたらすことです。この不幸なミスマッチを産むビジネスモデルが、使えないシステム、多重請負、費用対効果の悪さの原因です。

開発者のモチベーションを損なう構造

一括請負のビジネスモデルでは一般的に人月で見積りますが、これは生産性向上の意欲を損ねます。ゴールが納品なので、保守性の高いソースコードへの品質向上の意欲を損ねます。納品までが仕事となれば、自分の作ったシステムが使われる様子も見えず反応も貰えないことが何より仕事への意欲を損ねます。

お客さまが本当に必要だったものとは

お客さまが欲しいのはシステムそのものではなく、システム導入による事業成長に対する効果です。その効果を実現するのは事業に合わせて一緒に開発し続けてくれる仲間としての開発者です。私たちは、お客さまが作りたいものが決まっていない状態からパートナーとして一緒に考えて、取り組んでいきます。

プログラマが担う役割と仕事内容

「納品のない受託開発」では、業種や業界、対象業務に規模などを問わず様々な状況のソフトウェアに対応します。私たちは、お客さまの置かれた状況やニーズに合わせて最適な提案ができるように、役割と仕事を定義しています。共通しているのは、プログラミングまで行うということです

事業を立ち上げる一人目のエンジニア

新規事業を立ち上げるための、アイデアをスピーディーに形にする高い技術力と、仮説検証を続けていく事業への深い理解を持った一人目のエンジニアを担います。多くの新規事業に関わった経験を活かして、企画から一緒に検討していきます。フルスクラッチで開発し、完全オリジナルなサービスを作ります。

スケールする事業を支える開発責任者

事業がうまくいくほど、古いシステムが成長の足枷になります。そうしたシステムをリプレースして、スケールする事業に合わせて変化に対応していきます。開発するだけでなく、複数のエンジニアでチームを組んで組織化していく役割も担います。経営目線を持ち技術戦略を考える最高技術責任者と言えます。

業務改善を伴走し続ける業務ハッカー

社内業務の効率化を実現するのが業務ハッカーの仕事です。業務の見える化と分析をして、非効率な箇所を改善するようシステム化します。経営者の相談にのったり、実際の現場を訪問してヒアリングも行います。開発もしますが、お客さま自身で直していけるように、ローコードツールを使うこともあります。

プログラマが身につけて実践する習慣

良いソフトウェアを開発するために欠かせないのは、良い習慣を身につけていることです。チームの成果を最大化するために、ルールやプロセスを規定するのではなく、実践する習慣を揃えます。私たちが成果と同じくらい仕事の進め方を重視しているのは、良い習慣が良い成果に繋がると考えているからです。

ふりかえり:内省してメタ認知を身につける

あらゆる改善はふりかえりから生まれます。行動や取り組みを少しずつでも良くするきっかけであり、内省の機会でもあります。自分を含めた周りまで客観視できるようになれば、柔軟で冷静な思考が身につきます。ふりかえりが習慣化できれば、立ち止まることなく常に前向きに変化していくことができます。

小口化:小さくシンプルにして本質を捉える

「一度に大きくやる」よりも「何度も小さくやる」方がうまくいきます。どんな問題も小さくすれば、解決しやすくなります。仕事も小さく分解すれば、早く成果が見えます。小さくすれば無駄も見つけやすい。たとえ小さな挑戦であっても学びは大きい。一発勝負よりも試行錯誤を繰り返すための小口化です。

ザッソウ:問題vs私たちの構図で立ち向かう

チームで相談すれば、より良い成果を出すことができます。一人で抱え込んで時間を消費するよりも、曖昧な状態でも雑に相談することで、知識を補完し、アイデアを出し合い、問題に対して一緒に取り組むことができるのです。個人の技術力も大事ですが、私たちの仕事にコミュニケーションは欠かせません。

インタビュー