クラウドサイン TechLead 和田浩一「ものづくりは、自由なクリエイターから生まれる」#CloudSign_Astronauts

クラウドサインを創っている社員を、クラウドサイン責任者・橘がインタビューする企画「Astronauts（アストロノーツ）」。第６回目はクラウドサインのテックリード（TechLead） 和田 浩一さんをインタビュー。

テックリードから見たクラウドサインの６年間

橘：こうやって1時間マンツーマンで話すのも久しぶりですね。和田さんはクラウドサインリリース前の約1年前に入社され、和田さんが書いたコードからクラウドサインという製品が生まれました。

このクラウドサインの6年間を振り返ってみていかがですか？

和田：いやあ、今のクラウドサインの状況は全く想像がつきませんでした。当時は電子署名法のような電子契約を取り巻く法律が変更されるとは想像することができませんでしたし、とにかく驚いています。

今までの自分だったら開発しないようなタイプのアプリケーションで、「契約」という重要な領域を取り扱いますのでメカニズムやシステムだけでなく、お客様に安心してご利用いただくためには重要な責任を伴うアプリケーションだと開発当初は考えていました。

橘：今はまだまだ普及期の段階で振り返るには早いかもしれませんが、和田さんから生まれたコードがこうして社会に徐々に親しまれ、開発者としての自信や自負のようなものは生まれたりしましたか？

和田：自負というものは特にありませんね。クラウドサインという製品はシステム面だけでなく、サポートを含めた全体のパッケージングが大事な製品だという考えでいます。ヘルプページの充実度やカスタマーサポートの正確性や迅速さなども含めた総合的なパッケージングが問われる製品です。そういう意味で、自らの自負だけでなく、製品自体がひとりでに成長していくような感覚でいます。

ユーザーインターフェースに関しても総合力の1つで、THE GUILDの深津さんにリリース前に入っていただいたこともあり非常に優れていると思いますし、販促方法や広報活動でも、クラウドサインはファンを増やすような企画があって、ものづくりだけでない総合的な力に感心しています。

橘：なるほど、和田さんから見たクラウドサインとして非常に興味深いです。とはいえ製品自体も総合力の非常に重要な要素だと考えますが、設計での工夫などはありましたか？

和田：SaaS/クラウド製品は開発をし続けるものですので、当然ながらリリース当初の初期版は未完成なものでもあります。安定性を保つために、プログラムが異常終了しても再起動したら処理を継続できるようにするなど、非常に安定性の確保に気を配りました。

　特に安定性を重視して当初から設計したので、クラウドサイン内の書類にもシステム的には「状態」を持っていて、お客様が何らかのアクションをすればその「状態」を変化させる設計をするといった最初の設計がその安定性に寄与していると考えています。

　また、初期版を開発する際のプロセスは上手くいったと振り返っています。開発段階でデザイン構成が完成する前からデザインを仮組みし、恐らくこのような機能が必要であろうと予測しながら開発も並行していたため、いわゆる開発待ちのようなことが起きなかったプロセスも誇れる点でした。

橘：クラウドサインでは開発言語にGO言語（Golang）を当初から採用していますが、その判断は今振り返ってみて良かったですか？

和田：それは採用して良かったですね。もしGO言語でなければPHPを選択していたと思いますが、GO言語はコンパイル時に文法チェックがされるコンパイル型なので「堅く開発ができる」という特徴があります。GO言語はGoogleが開発したものですが、言語的には「Better C」を作ろうと始めた経緯もあり、それまでの当たり前を考え直して作られたようなところがあります。

　コンパイル時の文法チェックのおかげで、改修した時にバグが入ることがほとんどありませんでしたし、標準でフォーマットを整える機能や、テストを行う機能が付いていて簡単に扱えるため、開発環境をきれいに保つことが楽にできています。また、GOには予約語の数が少ないという特徴もあり、覚えることが少ないですし、自由度が高く面白い言語ですよ。

橘：クラウドサインではフロントエンドでもVue.jsを積極的に取り入れようとするなど、新しいものを取り入れようとする文化なども感じますが、いかがですか？

和田：やはり新しいものに触れないと使いにくくなってしまうので今後も取り入れていきたいですね。Vue.jsはJavaScriptフレームワークですが、画面のパーツに対応するデータを持って、フレームワーク側でデータの変更を反映して画面を書き換えてくれるので、整理に優れたフレームワークとなっています。

　Vue.jsもクラウドサインのスマートフォン版を開発する際に取り入れ、取り入れる際も全てを置き換えるのではなく一部から取り入れ、まずは既存の方法と共存する仕組みとして取り入れる工夫をしています。共存しながら動きを見て検証し、検証し終わった段階でその仕組みを全体に寄せていくような方法で積極的に検証していっています。

エンジニア部門として大切にしていること

橘：和田さんは1人目のエンジニアとしてリリース前から開発に携わっていますが、よいものづくりをするエンジニア部門として大切にしていることはありますか？

和田：そうですね、2つ大切にしていることがありますかね。まずは上下関係のようなものができないように発想を自由にすることです。もう1つは製品においては信頼性を大事にすることで、コードの書き方で言えば筋の通った書き方をするということです。

橘：筋の通った書き方とは、どういうことなのですか？

和田：筋の通ったプログラムとは、プログラムは一貫した考え方をし、その1つの整理に基づいて開発する必要を意味します。例えば一定の箇所に不具合が生じたときに根本的なプログラムの在り方を考えずに個別の修正を加えると全体に不具合を生じさせるようなことが起きます。なので常に根本的にどうなのかを考えることが重要となります。

橘：もう1つの発想を自由にすることとしては、クラウドサインの「Day0」という制度がありますよね。（編集注記：Day0とは、エンジニアの業務時間の20%を策定・決定されたプロダクトロードマップ以外の開発を自発的に行う制度で、実際にこの制度を活用して本開発になったこともある。）

和田：Day0は重要な文化ですし、制度だと思います。2017年くらいから始めた制度ですが、エンジニアにとってとても大事だと考えて始めました。当たり前ですが、エンジニアはコードを書かないと力がつきません。写経でもいいのでとにかくコードを書くことで力がつくのです。だからその基礎力を強化するために、自発的にコードを書くことができる制度として始めました。

橘：実際に先日クラウドサインの新機能としてリリースした「書類受信時の認証強化機能」もこのDay0がきっかけで生まれた新機能でした。工夫しているポイントはありますか？

和田：あまりルールの制約を設けないことが大事だと考えています。事業に直接的に関係のないように見えたり、他人から見たら遊びのように感じるようなものが自分自身の探究に繋がり、技術者としての基礎力が高まっていきます。

橘：関連しての質問ですが、技術力というものはどのような能力が差を分かつのでしょうか？

和田：プログラムの書き方で言えば、小さい単位に分けて開発できるかどうかで設計の差が出ると考えています。この単位のパーツはこの役割を担当し、線引きするというような責務が分離できるかどうかで技量が出ます。

　そして日本語を整理できて説明できるかどうかの言語感覚も非常に重要だと思います。設計においては、動作の仕様やシステムの構造を明確に説明できることが必要になります。そしてプログラム開発においては、動作のまとまりや変数ごとに名前をつけることになりますが、よい名前として表現できないと保守がしにくくなります。

　プログラム中では日本語のキーワードが出てくることはあまりありませんが、この場面でも先ほどの日本語で説明する上での言語感覚も生きてきます。そのプログラムが持つ動作の概念をどういう単語の組み合わせとして表すかも運用する上では重要な技術と考えています。

橘：なるほど、自分自身初めて知って勉強になります。そのような技術力を身に付ける上で和田さんはどのようなことから獲得していったのですか？

和田：私は好奇心から獲得していきました。今の仕組みを便利にしてみたいとか、使いやすいツールを作ってみようとか何かを自発的にしたいという好奇心から、ではどうやって使いやすくできるかという試行錯誤が始まります。

あとは他の人の書いたよいコードを見ることも勉強になりました。私がLotusにいた時代も、米国製品を日本向けにカスタマイズするような仕事をしていましたが、米国にいるエンジニアのコードを見て勉強になった記憶もあります。

SaaS製品のものづくり

橘：自分は常々、よいものづくりができる文化作りをしていきたいと思っていますが、クラウドサインのプロダクト開発で良い点と改善したい点などを教えてもらいたいです。

和田：よいものづくりをする上でエンジニアは皆が裁量を持てるクリエイターであって欲しいです。その意味で、日々のタスクの割り振りを開発レーン内でエンジニア同士で行っていることは良い点だと考えています。開発レーン内で日々ミーティングを行っており、それぞれが独立して動けるようになっています。

また、エンジニアの仕事は新規開発だけでなく、日々のアラート対応やヘルプデスク対応も大事な仕事で、各エンジニアが率先してやっている主体性のあるエンジニア達が多いのがよい点だと考えています。

橘：改善した方が良い点はありますか？

和田：開発ロードマップ策定段階で運用面を考慮に入れられるかが大事で、その面では改善した方が良いとも考えています。製品はどうしても新機能ばかり求められがちですが、去年リリースした機能をより使い勝手の良い機能に改修していくような事は運用チームこそ理解をしています。サービスをスケールするためにも、従来の機能の運用をしていくアジャイル開発を更に運用していくのが良いのではないかとも考えています。

橘：ありがとうございます。まさにその通りだと受け取りました。和田さんの方で今関心のある技術分野はありますか？

和田：マイクロサービスのような仕組みに関心を持っています。小さいサービスの塊としてそれぞれの責務は小さくし、独立して動くような設計です。イベントソーシングパターンを使用できないか、AWS（Amazon Web Service）の機能の中で利用できるものがないか調べたいと考えています。

　また、テストを楽にするようなこともテーマの1つです。QA（Quality Assurance）をプログラムでテストするようなものができないかなどは、クラウドサインでも重要なテーマです。

橘：最後にどんな人に入社してきて欲しいか、またこれからのクラウドサインのエンジニア組織をどうしていきたいかなどございますか？

和田：その人がいれば、周りが明るく仕事ができるような人に入社して欲しいと考えています。最近入社いただいたエンジニアの皆様はそのような方が多くて嬉しいです。

　もちろん技術力、良い品質のコードを書いていただける方という前提ですが、挑戦してみようや試してみようというマインドの方に是非入社いただきたいです。理想は、実装の仕様をエンジニアが自主的に開発できるような風土を確保できることです。自由な雰囲気が漂い、何かを開発したいという意欲が湧くような組織が理想で、言われたからやるようなものではなく、良い製品にしたいと自ら動き出せるような組織にしていきたいと考えています。

和田浩一

編集後記

　和田さんに取材後、事業責任者に期待することはありますか？と尋ねてみた。

　SaaS製品は「作って売る。売って作る。だと思うので、プロダクト側、ビジネス側という言葉で分けることができない製品だと思う。」と本質を突かれた。だから「こっちはこっち、あっちはあっちでなく、各プロフェッショナルな持ち場から自主的に貢献できるような風土が大事で、お願いしたい。」と。

　日本でも長らく様々な業種で「製販一体」と「製販分離」のリストラクチャリングが繰り返された。例えば、三井不動産レジデンシャル株式会社では、平成１８年１０月に三井不動産の住宅分譲事業部門と、三井不動産販売の住宅販売受託事業部門を統合し、「製販一体」となる企業へと変貌を遂げた。不動産開発には用地取得、魅力ある建物造り、分譲販売、土地建物の管理といった、それぞれの業務に高度な専門的知識・経験が必要で、各業務毎に熾烈な産業競争がなされている。お客様のニーズをダイレクトに捉える大胆な組織改革だ。

　家電メーカーや自動車製造などのハードウェア製造においてもリストラクチャリングは繰り返される。バリューチェーン全てを1つの企業が行う垂直統合的な企業体制は非合理なのではとも、時に指摘を受ける。シリコンバレーを中心に産業構造が転換され、ブランドの強い企業は企画開発、部品調達、マーケティングのみを担い、製造、販売は競争力あるパートナーシップに依存する水平分業がもてはやされ、今尚継続されている。SaaS企業もまた、「製販一体」と「製販分離」の議論が続く。

　組織体制のリストラクチャリングは今後も歴史の波の如く変化を遂げていく。ただ、重要なことはいつも変わらない。お客様のニーズを捉えて作る。そして売るということ。本質はいつも単純で、だからこそとても難しい。やり甲斐ある製品開発の現場を支える1人のエンジニアの物語を、いつまでも輝かしいものにしていきたい。

総合企画・ライター・編集：橘 大地
デザイナー：笛田 満里奈、佐伯 幸徳
写真撮影：長浜 裕子
テーマソング：YELLOW MAGIC ORCHESTRA 「RYDEEN」