【連載】ソニックガーデンストーリー 10年分のふりかえり
「納品のない受託開発」を掲げ、フルリモート勤務や管理しない組織など柔軟な働き方を実践するソニックガーデン。
メンバーへの取材をもとにその10年の歩みを追いました。
「納品のない受託開発」を行う顧問CTOには、どうすればなれるのか。一般的なプログラマとはまた違ったスキルも要求される顧問CTOとしての仕事を前に、遠藤や栩平は頭を抱えていました。それまで当たり前だと思っていた、プログラマ像と顧問CTOでは大きな違いがあったのです。
はたして、納品のない受託開発と、他の受託開発は何が違うのか…。
7-1 やればやるほど、うまくいかない
「最初の納品のない受託開発の仕事は、孫請けみたいな体制がよくなかったのか、うまくいきませんでした。いわゆる炎上案件、です。その次に西見さんとやった案件も、最後の最後にちゃぶ台返しになっちゃって、だめだった。思い描いていたプログラマの道を歩いているはずなのに、うまくいかないなぁって結構悩んでましたね」（遠藤）
ソニックガーデンに入社して以降、遠藤は、納品のない受託開発の顧問CTOとして苦悩する日々を送っていました。ことごとくうまくいかない案件に、「心が折れかけたこともあった」といいます。
「何がよくないんだろうといろいろ考えましたが、よくわかりませんでした。当時は、今ほど納品のない受託開発としてのスタンスが固まっていなかった。教科書があるわけでも当然ないので、みんなの背中を見ながら自分は何がいけないのか、どうすればいいかをひたすら考えていましたね」（遠藤）
納品のない受託開発は、ソニックガーデンが独自で作り上げたビジネスモデルです。先人がいるわけでもなく、自分たちで手探りで、そのモデルを育てていく必要があります。藤原は、「納品のない受託開発は、失敗を反映して成長してきた」とふりかえります。
「納品のない受託開発も、過去は何度も案件で失敗をしています。最初の頃は、お客様を選ばずにある程度なんでも受けていましたし、今ほどプロセスを重視する発想もなかったかもしれません。何か失敗した案件がある度に、僕と倉貫さんで話し合って、サービスとしての見直しを繰り返していったんです」（藤原）
7-2 オープンにふりかえりをする
納品のない受託開発がビジネスモデルとして成長していった背景には「失敗をオープンにして、ふりかえりをする」習慣がありました。
「ソニックガーデンでは、失敗を責めません。僕も、倉貫さんも『なんで失敗したんだ』なんて思いもしない。それよりも、大事なのは失敗を包み隠さずオープンにして、どうすればよくなるかをしっかりふりかえって考えていくこと。メンバーが、情報をつまびらかに共有してくれるので、我々もどう手を打てばいいか考えやすい。それを、ひたすら繰り返しながら成長していったんです」（藤原）
例えば、どんな失敗があったのでしょうか。西見は、過去のしくじり案件を詳細に覚えていました。
「今でもよく覚えている、しくじり案件があります。担当者と議論しながら、開発を進めていきぼちぼち公開かな、というところまできた。すると、突然担当者の上司から『全然開発が進んでないじゃないか』と連絡がきたんです。驚きましたよ。担当者と上司の間でコミュニケーションが全然できてなかった。結果、正月返上で開発です。この経験から、納品のない受託開発では必ずミーティングに意思決定者に同席してもらうようにしています。
それから、お客様が行っている事業とは全然違う領域で新しいサービスの開発を行ったときもうまくいきませんでした。流行りのサービスを開発してみたい、というやつです。その経験から、お客様の事業や強みをしっかり理解しながら、『なぜ開発するか？』をお互いすり合わせる大切さも学びました。開発をスタートするまでに、何度も話し合うのはこうした経験を繰り返した結果ですね」（西見）
7-3 無駄なモノを作ってしまう
納品のない受託開発を行う顧問CTOには、技術力に加え、コンサルティング能力も必要になってきます。要件定義は存在しないため、お客様と話し合いをしながら、その都度で最適な開発プロセスを構築していかなければいけません。こうしたプロセスに、経験があるが故に適応まで時間がかかるケースもあります。SIerとして腕に覚えがあった栩平もその1人でした。
「かつては、100枚もある要件定義書を必死に作って、開発するということをしていました。そういう開発に慣れていると、お客様が言ったものを全部作ろうとしてしまうんです。でも、一度、松村さんがお客様に『それは、ブラウザの機能を使えばいいので、作らなくてもいいですよね』と言っているのを聞いて、衝撃を受けると同時に『あ、顧問CTOの役割はこれか』と腑に落ちたんです」（栩平）
顧問CTOになりたての頃、「無駄だと分かっていても、つい作ってしまっていた」という栩平。SIerとしての習性が身についていたことで、作ることが目的となってしまっていました。しかし、周囲の顧問CTOの姿勢から徐々に、大切なポイントを学んでいきます。
「つまるところ、お客様、そしてエンドユーザーにとってその開発は本当に必要か？をしっかり考えることが大事なんだなと、2〜3年ぐらいかけて少しずつ身にしみこませていきました。一度、エンドユーザーへヒアリングをして、必要な機能、必要でない機能を整理してお客様と開発を進めて、成果を出せたことがありました。SIer時代だったら絶対にやらないプロセスですが、これこそが納品のない受託開発なのだな、と自信が付きましたね」（栩平）
7-4 「開発のこと考えずに話すよ」
さて、苦悩の道を歩む遠藤はどうでしょうか。納品のない受託開発がそのスタイルを確立させていくなかで、遠藤自身も失敗から多くの気付きを得ていました。
「うまくいかない日々の中で、少しずつプログラマの本来の役割が何かが見えてきたんです。それまで、プログラマは仕様をもとに“正解通りにプログラミングする人”だと思っていた。でも、納品のない受託開発においては違います。正解がない世界で、開発を進めていかなければなりません」（遠藤）
正解のない世界で、どう開発を進めていけばいいのか。遠藤はさらに思考を深めていき、“仮説”の重要性にたどり着きます。
「例えば、企画職の人は“仮説”をベースに考えていきますよね。いくつか仮説を考えて、どれがいいか悪いかを検証していく。そうした仮説検証を、リードしながら開発していくのが顧問CTOなんじゃないか。3年目ぐらいですかね、そういう考えが自分の中で固まってきました。その、試行錯誤のプロセスを楽しんで、スピーディーにやっていく。これが、納品のない受託開発の醍醐味なんじゃないかと思えるようになってきたんです」（遠藤）
そうした考えを持つようになって以降、案件がスムーズに進むようになり「馬が合うお客様が増え始めた」と遠藤は言います。プログラマの範囲を見誤り、いいコードを書くことばかりを考えすぎていた、かつての遠藤。そうではなく、お客様のビジネスがどうなればうまくいくかを、時にはお客様以上に考えて、仮説検証していく。想像以上に「広い範囲」を手がける顧問CTOとしてのあり方を受け入れることで、遠藤は暗いトンネルを脱します。
「顧問CTOとして自信がついてきたとき、ふと自分たちは寿司屋の大将と同じじゃないかと思ったんです。カウンターに立って、会話しながらそのときどきで相手が好む料理＝ソフトウェアを提供していくサービス業をしているのだと。
開発者モードでお客様と話していると、『どう開発すればいいか』ばかり考えてしまいます。でも、サービス業だから『どうすればお客様が満足するか』をまずは、考えなきゃいけないんです。だから、最近僕は『今から開発のこと考えずに話すよ』とよく言います。これは、自分自身を開発者モードから開放する言葉でもある。そうやって、いろいろな仮説を出すことからスタートすることで、お客様と同じ目線で話せる、つまり本当のパートナーになれるんです」（遠藤）
