私たちの想い 09

「サーバーの言語にScala(スカラ)を選んだ理由。非常に堅牢です。」
CTO 玉置 龍範 インタビュー(前編)

CHANGE(チェンジ)立ち上げの変遷を教えてください。

もともと弊社代表の池田から「一緒に世界を変えよう」と誘われ、2016年10月に株式会社チェンジ・ザ・ワールドに着任しました。「太陽光発電所を分割して販売すれば、より多くの方に購入してもらえるのでは」というぼんやりした仮説はありましたが、CHANGE(チェンジ)など影も形もなくパソコン1台でビジネスプランを考え始めるところからスタートしました。

太陽光発電所をたくさんの方に買ってもらうためにどういうビジネスである必要があるのか考えた結果、今のCHANGEの形、「太陽光発電所を1W(ワット)ずつ販売する」「月に1度チェンジコインという形で売り上げを分配する」「分配すると同時にワット価格がなだらかに下がっていく」という仕組みを構築しました。

2017年7月に「千葉市緑区高田町1号発電所」を初めてCHANGEで販売開始。ここまでで私が着任してから10ヶ月かかりました。

CHANGE(チェンジ)というサービスをゼロから立ち上げる上で難しかったことは何ですか？

まず一つ目に、ワットの価格設計が大変でした。

ワット価格が20年にわたってなだらかに下がっていく計算式を作ったのですが、これだけで2～3ヶ月かかりました。どうしても計算の帳尻が合わなくて、何度も計算しなおしました。

ちょっと具体的に説明させていただきますと、CHANGEでは売電収入を分配すると同時に発電所(ワット)の価格が下がっていくわけですが、発電所の価格が直線的に下がっていくとビジネスとして成り立たないのです。発電期間20年の発電所を20万円で発売し、価格を1年後に19万円、2年後に18万円・・・と直線的に下げていくと、残り2年で購入した場合2万円で買った発電所が2年で4万円発電してしまう。最後の方に購入するほど利益率が良くなるという不公平が起きてしまうのです。

そこで、発電所(ワット)の価格がなだらかに下がっていく計算式を構築しました。この計算方法は実は特許もとっているんです。

「ワットの販売価格・買取価格」について詳しくはこちら

二つ目として、販売も難しかったですね。

最初はイベントでクーポンを配り、ユーザー登録してもらうところからスタートしました。やっと販売を開始してもなかなか思うように売れないので、お願いして知り合いに買ってもらったり自分たちで買ったりしていました。

販売面でも様々試行錯誤をしながら、口コミなどもあり徐々に広がっていきました。「あ、全く知らない方が購入してくれた、すごい！」というように注文の度に喜んでいました。

プログラマー(エンジニア)視点で難しかったことはありますか？

CHANGE(チェンジ)のサーバーにはScala(スカラ)というプログラミング言語を選んだのですが、私自身Scala(スカラ)は新しいチャレンジという意味で大変ではありました。

これまでもずっと勉強してはいましたが、本格的にサービスで使ったのは初めてだったので、ログイン機能やその他細かいパーツを一から作る必要がありました。後は、フレームワーク上に構築されているプログラムの書き方やモジュールの分け方などの設計も、全て最初は決めていかなければいけないので時間がかかりましたね。

なぜ、Scala(スカラ)を選んだのですか？

一言で理由を説明するのは難しいですね。「好きだから」でしょうか(笑)。

まず、Scala(スカラ)は様々なプログラムを自由に素早くかける汎用的な言語でありながら、何か変更したときの影響範囲が特定しやすいという点において、大規模システムを構築しやすい言語であることが挙げられます。

汎用的で素早く書けるプログラミング言語ということで長年Ruby(ルビー)を使っていましたが、Ruby(ルビー)には弱点がありました。Ruby(ルビー)は「動的型付け言語」で、コンパイルという作業をしない言語なのです。それはコンパイルしなくてもすぐに動いて簡単にかけるというメリットがあるのですが、大規模なシステムを組む上では、何か変更したときにその変更がどこに影響を及ぼすのか分かりにくいという意味において、足を引っ張ってきます。だから大規模システムを構築しにくいのです。

Scala(スカラ)はその点Ruby(ルビー)と同等程度に柔軟性を持ちつつ、「静的型付け言語」なので、何か変更したときの影響反映が特定しやすいという点において気に入っています。

また、Scala(スカラ)は実行スピードがとても速いです。

実際2017年1月会員登録サイトをオープンした時をCHANGE(チェンジ)の最初のリリースとすると、もう3年以上使っているシステムですが、今のところパフォーマンスの問題も出ていませんし、「システムがとっちらかってメンテナンスできない」みたいな状態にもなっていません。予定通りではあるけれど、あちこち様々な変更を持続的に行うCHANGE(チェンジ)のようなサービスにおいて、大きなメリットです。