ビジネスの構想からお客様と関わり、その実現をソフトウェア開発で支援していく「納品のない受託開発」には、要件定義や仕様書などの「正解」がありません。

「正解のない世界」で、お客様と一緒にどうやって戦っていこうか?と、試行錯誤を続けてきた遠藤さん。納品のない受託開発に関わり約10年が経った今、「開発者の帽子を脱ぐことに気づいた」と話します。

開発者の帽子を脱ぐとうまくいく

倉貫
ソニックガーデンのプログラマには、お客さんが暗中模索している「正解のない世界」で一緒に戦うことが求められるけど、遠藤さんはどんな姿勢で取り組んできたの?
遠藤
最近は、あえて「開発者の帽子を脱ぐ」ことを意識してます。
倉貫
「開発者の帽子を脱ぐ」。つまり開発者ではない立場になって、お客さんと話すってこと?
遠藤
そうですね。自分の本来の役割である開発者の帽子を脱いで、まずは「お客さんとチームになること」を大事にしたほうが、うまくいくんじゃないかって思ってます。

「どう作るかは後で考えるので、まずは何がやりたいかを一緒に考えましょう」みたいな気持ちですね。
倉貫
役割より先にチームになるってことだよね。開発者のままでは「開発する上でどうか?」の考えに留まるし、開発が難しそうな話に対して苦い顔しちゃうってこともある。
遠藤
「正解のない世界」でお客さんと一緒に戦うには、そのビジネスにとって本当に必要なものは何かを、冷静にジャッジすることが必要だと思ってるんです。そのときに、できるだけ開発者としてのバイアスがかからないようにしたいんですよね。

「開発者」としてお客さんと話をすると、「その機能作るの大変そうだな」「面倒だな」と感情が先行して、無意識のうちに避けちゃう感じがして。
倉貫
うんうん。どんな職業でも経験を積むほどリスクが想像できるし、痛い目に遭ったこともあるぶん知恵がつくんだよね。優秀なプログラマであるほど、実現のハードルの高さも知ってるから、つい「それ難しいですよ」って言っちゃう。
遠藤
でも、もし作るのが大変な機能だったとしても、それが本当にお客さんのビジネスにとって必要なら、頑張って作ったほうがいいじゃないですか。

だから、お客さんと話をするときには開発者の役割から離れて、「一緒に同じビジネスをするチームの一員」になることを意識した方が、より深い話が効率的にできる感じがするんですよね。

まずは、お客さんと「こうしたほうがより面白くなる」とか「より役に立ちそうだよね」とビジネスでやりたいことを話した上で、それを実現するためにそれぞれのメンバーが得意なことを進めていく形が理想というか。
倉貫
そうだね。ビジネスをやってる側の気持ちとしては、できないことじゃなくて、そのビジネスでやりたいことの抽象度を上げて、うまく実現する方法を考えて話してほしいんだよね。「こういうやり方だったらうまくいくんじゃないか」みたいな。
遠藤
そのためにもお客さんのビジネスの本質を理解する必要があるし、どっちに行ったらいいかわからない状況で進むためには、お客さんと向き合うんじゃなくて、お客さんと同じ方向を見て取り組むほうが大事なんじゃないかって思ってるんです。
倉貫
単純にお客さんを喜ばせるんじゃなくて、「問題に対して私たちで戦っていきましょう」のスタンスになれると、向き合い方が変わって目線が同じ方向になる。つまり、「問題vs私たち」の構図だよね。遠藤さんは、今それを実体験しているんだな。

「お客さんと同じ方向を見て取り組むほうが大事」って考えるきっかけが何かあったの?
遠藤
なにか明確な出来事があったわけじゃないんですけど・・・、最初は「納品のない受託開発って、小料理屋の店主みたいな仕事だな」と思ったんですよ。

カウンター越しにお客さんと僕が向かい合って、希望を聞きながら「じゃあこれ食べますか」って料理を出すのに似てる気がして。要するに「お客さんが欲しい物を考える仕事」なんじゃないかと。

でも、その考えではお客さんとの間に隔たりを感じたし、向き合ったところで、そもそもお客さんも僕も正解は持ってないと気づいたんです。
倉貫
なるほど。お客さんと向き合うって良いことだけど、「あなたvs私」の構図にならないように気をつける必要があるよね。どっちが正解なのか、どっちの意見が通るのかみたいな話になりがちだから。
遠藤
そう。だから、開発者の帽子を脱いで、お客さんと同じ方向を見て取り組むほうが大事なんです。言葉にするとシンプルですけど、実感を伴うまで時間かかったなぁと思いますね。

「作らない提案」の難しさ

倉貫
とはいえ、再びプログラマの帽子をかぶったときに、どう考えてもやらないほうがいいことってあると思うんだよね。そのときは、どうしてるの?
遠藤
お客さんが本来やりたいことを実現するためには、「今はそれを作らないほうがいい」って意見も素直に言います。そういう「作らない提案」をするときこそ、お客さんと同じ目線に立っていることが響くと思っていて。
倉貫
そうだね。納品のない受託開発では、なるべく「作らないほうがいいものは作らない」を大切にしているから。
遠藤
僕らはプログラマだから、良くも悪くもITの力でお客さんのやりたいことを形にできるんです。だからって、お客さんの作りたいものを何でも「それいいっすね」と言うのは、違う。
倉貫
うんうん。一方で、お客さんと一緒に考えてビジネスの実現に必要なら、たとえ難しいことでも他のやり方も含めて提案するようにしてる。このパラダイムシフトが必要なんだよね。
遠藤
作る/作らないの判断は、本当に難しいですね。僕たちは最終的に自分でソフトウェアを作るところまで責任持ってやんなきゃいけないので、そこのバランスをうまくコントロールするのは、なかなかハードだなと。
倉貫
でも、そうしたほうがお客さんから信頼を得られる。
遠藤
お客さんにとって無駄な機能を開発しなくていいし、本当に必要な機能だけに集中できるってことですからね。それに、途中で開発するものが変わっても、追加で費用が増えることもないですし。
倉貫
そうそう。「作らない提案」ができるのは、納品のない受託開発が月額定額だから。 一般的な、仕様書と見積もりがある開発では、お客さんが途中で仕様を変えるのも難しいし、開発側も納品をしないとお金をいただけない。「この機能必要?」と感じても、納品を優先しちゃうと思うんだよね。

でも、月額定額の納品のない受託開発は、「お客さんのビジネス成長に大事なこと」にお互いが集中できる。だから、一般的な納品のある受託開発とは違って、本当に必要がないものは作らない提案をしたり、他の実現方法の提案もしやすい。結果的に契約が長く続いて、ありがたいところがあるんだよね。

ソフトウェアは「生き物」

遠藤
僕も、7〜8年くらい同じお客さんと一緒に仕事してますね。
倉貫
それだけの時間をかけてきた遠藤さんだからこそ、お客さんから「新しいビジネスを一緒に考えてほしい」と相談されるくらいの信頼関係があるんだよね。一方で、いちプログラマからすると、同じプロジェクトを続けると飽きるんじゃないかって疑問もあると思うんだけど。そこはどうなの?
遠藤
それが、飽きないですね。お客さんやサービスの対象領域は同じだとしても、作るシステムは、同じじゃないんですよ。これが納品のない受託開発の面白いところだなと。

新規事業のような新しいことをやるときは、何が当たるかわからない。いろいろなアイディアを出しては作り、うまくいけば伸ばして、駄目だったら捨てるの繰り返しになるんですね。

そして、ビジネスが成長し始めると、作るものがどんどん変化していく。結果として、常に新しいものを開発している状態になるから、いつも新鮮な気持ちですよ。
倉貫
ソフトウェアの良さの1つは、物理的な建物と違って改築に限界がないところだよね。仮想だから。
遠藤
そうそう。同じコードベースを、ずっと進化させ続けることができるんですよね。そのときのビジネス状況に合わせていらないものはバッサリ捨てて、必要なものだけを残す。ビジネスの実態が変わってきたら、ちょっとずつ現状に合うように直していく。

お客さんと毎週ミーティングしながらズレを確認していくから、機能の塩漬けも起きにくいです。
倉貫
普通のソフトウェア開発は、定期的にリプレースしないとレガシーな状態になっちゃう。対して納品のない受託開発は、ずっと改善し続けられる。

僕はソフトウェア開発は、生き物と一緒で「育てていくもの」だと思っています。植物を育てるために毎日水やりをしたり、土を替えて手入れをしていくのと同じで、ユーザの反応を見ながら常にバージョンアップして触り続けるのが、ソフトウェア開発にとって自然な形。それを実現するためにはやっぱり納品をなくすこと、「作って終わりにしない」ことが必要だと考えているんだよね。
遠藤
そうですね。そうやってコードを進化させ続けるためには、お客さんから見えないインフラとか、プログラムのフレームワーク、ライブラリの部分を最新に追従し続けることが重要になってくるんですよね。

「正解のない世界」で戦うために、開発者の帽子を脱いでお客さんと同じ目線に立ち、ビジネスを進めるひとつのチームになることを大事にしているという遠藤さん。
お客さんとの関係性が長く続く中でも、その時々の実態に合わせてコードを進化させ続けていくので、常に新しいものを作っている感覚だといいます。

そんな遠藤さんが開発する際に意識しているのが「プログラムのコードは負債」という考えでした。

(第3回につづきます。)

次回の公開は7月28日です。


文=小野寺ちひろ(ソニックガーデン)/編集=マチコマキ