連載「Technology Company Internals」では、テックカンパニーの内側で働くエンジニアに、技術に精通したエキスパートが対面で話を聞き、テックカンパニーとは何か？を探るだけでなく、テックカンパニーを目指す企業の指針となることを目指します。
クラウドサインとは？をCTOに聞く
-- 自己紹介をお願いします。
市橋: 市橋 立です。弁護士ドットコムのCTOを務めています。
クラウドサインというサービスの開発を中心としながら、エンジニアとデザイナーを横断的にマネジメントしています。
-- クラウドサインについて教えて下さい。
市橋: 「紙と印鑑」を「クラウド」に置き換え、契約作業をオンラインだけで完結できるWeb完結型のクラウド電子契約サービスです。インターネット上で安全に、法的に有効な契約を素早く行えます。
従来の、紙と印鑑で行われている契約は、実はかなりコストのかかる作業です。
企業同士だと、契約書のやり取りだけで1-2週間を要することもざらにありました。その手間や時間を大幅に軽減できるのがクラウドサインです。PDFのアップロードから始まって、早ければ10分もかからず契約完了です。
-- コロナ禍で利用も大幅に増えたのではないでしょうか？
市橋: はい、利用ペースは順調に拡大しています。コロナ禍の初期、政府から在宅勤務が推奨されるようになり、押印のためだけの出社に対する課題意識が高まっていました。その上で、電子契約であれば家からでも契約できる。この利便性をお客様に評価していただけています。
何より大きいのが、エンタープライズ企業の意識が変わったことですね。以前は、エンタープライズ企業が電子契約を行うには心理的・組織的なハードルも大きかったのですが、いまや電子契約を導入する「前提」として話が進みます。
「前例のないサービス」を生み出せた理由
-- 市橋さんは、クラウドサインの誕生から立ち会っていらっしゃるんですよね。「クラウドサインを作る」という決断に踏み出せたポイントはどのようなものでしょう？
市橋: クラウドサインは2015年に生まれたサービスです。当時も電子署名を行うサービスはいくつかありましたが、あまり普及していませんでした。
電子署名が社会に普及するプロダクトを作りたい。そう考え、クラウドサインは利便性を重視し、前例のないサービスを作る決断をしました。法律に精通している弁護士ドットコムだからこそ、この決断に踏み出せたと思います。
また、直感的に使いやすいサービスでないと普及しませんので、当初はUXデザイナーの深津 貴之さんにもご協力いただき、UXを重視しました。
（参考記事: 当事者署名型と事業者署名型の違い より許可を得て転載）」
なぜGo言語で作ったか。なぜScalaでなかったか。
-- クラウドサインではGo言語をかなり早く採用されたとか。
市橋: はい、2015年から利用しています。当時はまだGo言語は今ほど人気もなく、「黎明期」と言ってもいい状況だったかと思います。
弊社の祖業である弁護士ドットコムはメディアという性質上の観点から、いかにアジリティを持って改善できるかが重要なためPHPで書かれています。なので、社内エンジニアとの技術親和性を考えればPHPを採用するところだったのですが、クラウドサインは「契約」という非常にセンシティブな領域を取り扱うサービス。そこに求められるのは、やはり「堅牢性」です。
そうなってくると、PHPより「固い」言語がいいよね、ということになり、強い型付けを持った静的型付け言語を採用しようということになったわけです。
-- 強い型付けを持つ言語は、Go言語以外にも検討されたのですか？
市橋: はい、Scalaも候補に挙がりました。ただ、2つの理由から採用しませんでした。
1つは、ScalaはJVM言語ですが、JVMの運用経験がなかったこと。
もう1つは、Scalaは書き方がBetter Javaな書き方と関数型の書き方の二通りがあって、開発者によって書き方が異なってしまうこと。その点、Goだと書き方が統一できるのが利点でした。
試行錯誤のGo言語開発。技術的負債は？
-- Go言語を黎明期に導入したことで、苦労したところはありましたか？
市橋: やはり、Go言語開発の先駆けであるが故、ノウハウがあまりなかった点ですね。トライアンドエラーにかなりの時間を費やしました。プロダクション環境で当時Goを使っていたのは、エウレカさんと弊社くらいしかなかったんじゃないかと思います。
エコシステムが未成熟だったのも大変でした。GoのフレームワークとしてRevelを採用していたのですが、その後EchoやGinなどのフレームワークが次々に誕生し（参考: go-webframework-stars）、Revelは最近開発が停滞気味です。
パッケージマネージャーも当時はなかったので、ライブラリの管理も大変でした。GOPATHで色々と制約がある中、頑張ってましたね（笑）
※GOPATH…Goライブラリの読み込みパスを指定するための環境変数
-- 6年間の間に、技術的負債もだいぶ溜まっているのではないでしょうか？
市橋: なので、技術的負債を返済するチームを作りました。
-- 負債返済チームですか？
市橋: 技術的負債の返済のみに特化したチームというわけではなく、技術を刷新していくことが本質的な役割ですね。例えば、コンテナ技術を採用してマイクロサービス化の基盤を構築したのもこのチームです。
リリースから6年経過すると、当時とは全然環境も違いますし、放っておけば生産性が落ちてしまいますので、そこはコストをかけてでも負債を返済するようにしています。
Go言語とジェネリクス、そしてマイクロサービス
-- 市橋さんは長くGoと付き合っているわけですが、Goはこれからどうなっていくと思いますか？
市橋: Go言語の哲学として、「イージーではなくシンプル」というのがありますが、これはこれからも一貫していくと思いますね。
例えばジェネリクスが1.18から導入されますが、Goの良さを崩さないよう、慎重に検討されています。
-- ジェネリクスについてはどう思われますか？
市橋: 個人的には、アプリケーション開発者側ではそこまでハードに使わないのではないかと思います。リフレクションなどもそうですが、初級者がガンガン使うものではありませんし、控えめに使うくらいがちょうどいいのかな、と。
-- 先程、マイクロサービスについてお話がありましたが、クラウドサインのマイクロサービス化について教えてください。
市橋: クラウドサインは今、エンタープライズ分野での採用も進み、製品のカバー範囲がどんどん広がっています。そうなるとやはり、モノリシックなサービスだと限界があります。
例えば、電子署名を行う部分については外部サービスを利用しているのですが、そのサービスが止まってしまうと、（モノリシックな場合）クラウドサイン全体が止まってしまう危険性があります。また、外部サービスに負荷をかけすぎてもいけないので、API呼び出しのペースを調整する必要もあります。こうした要件を実現するのに、マイクロサービス化は利点があります。
-- マイクロサービスといえば、データベースを分割するのかどうかが常に議論の的となりますが、ここはいかがでしょうか？
市橋: 将来的には（やるかも）、という感じですね。マイクロサービス化についても様々な段階があって良いと思っていて、今は依存するライブラリを分ける、などの段階です。
マイクロサービスにすることや、原理原則に則ることが目的ではなく、事業成長に資することが一番の目的ですので。
「これからの100年、新しい契約のかたち」をつくる
-- 技術選定においても、「事業成長に資する」という軸がブレていないのがすごいです。
市橋: そうですね、クラウドサインはミッションやビジョン、バリュー（MVV）を言語化していることで、前例があるかないかとか、技術的に面白いかどうかとか、そういうことに惑わされずに一貫した軸で意思決定できているのかなと思います。
-- ミッションにある「Rule Re:Maker」とは？
市橋: 「社会の『ふつう』を再定義していく」ということです。クラウドサインも、「契約業務は紙と印鑑で行うのが当たり前」という考えを変えたいというところから生み出されました。
最後は社会の「合意のあり方」そのものを変えたいと考えていて、そのゴールからすると、まだ私達は始まったばかりという段階です。クラウドサインのタグライン（編注: ロゴに添えられたテキスト）にも「これからの100年、新しい契約のかたち。」とあるとおり、今後100年を支える電子契約インフラとなり、あたらしい商慣習をつくりたいと考えています。
-- 「新しい商慣習をつくる」とは、壮大な目標です。ブロックチェーンの活用なども考えられそうですね。
市橋: はい、そこはもちろん注目しています。ブロックチェーン、特にスマートコントラクトという仕組みは、契約の履行も含めたソリューションになるので、大きな可能性を持っています。
現在は、契約に合意したとしても履行されるとは限りません。いわば「逃げ得」みたいなことも起こり得ますので、そこを変えられることができるかもしれません。
エンジニア求む。社会を変えよう。
-- 最後に、読者に向けてメッセージを頂けますか？
市橋: 「新しい商慣習をつくる」という目標を達成するために、クラウドサインはまだまだイノベーションが生まれるでしょうし、技術を使って解決できることはたくさんあります。
技術面だけでなく事業的にも面白いフェーズと立ち位置にいると思いますので、ぜひ多くのエンジニアに弊社で働くことに対して興味を持っていただけたらと思います。Go言語に興味がある、というだけでも歓迎ですが、社会に広く使われるサービス、そして社会を変えていくサービスを作りたい方々にぜひ来ていただきたいですね。
弊社には、「Professional with Respect」というバリューステートメントがあるんです。「Rule Re:Maker」であるためには、あらゆる分野の知識が必要。なので、プロフェッショナルたちがお互いをリスペクトしながら、一つのゴールに向かって協力していくというカルチャーを大事にしています。そういう意味でも、エンジニアというプロフェッショナルがパフォーマンスを発揮しやすい会社だと思います。
-- 本日はどうもありがとうございました。
