【2019年11月6日・未来のBUTAI#2】OCTOPASS × bajji 『ブロックチェーン技術がもたらすイノベーションの可能性と、それを加速させるためのCTOの役割を考える』
浅草橋のインキュベーション&コワーキングスペース『BUTAI（ぶたい）』では、イノベーター同士が出会える場を提供すべく毎週水曜日の夜にイベントを行っています。
第2回目は、CTO養成講座を提供するOCTOPASS様と共催！『ブロックチェーン技術がもたらすイノベーションの可能性と、それを加速させるためのCTOの役割を考える』というテーマで2019年11月6日に開催いたしました。
ゲストに、アペルザ元CTOで現在CTO養成講座OCTOPASSエバンジェリストを務める塩谷 将史氏をお招きし、当社bajjiからは、ブロックチェーン技術を活用したSNS『bajji（バッジ）』の開発に携わっているCBO（Blockchain）藤尾、CTO 小野寺が参加し、会場の参加者を巻き込みつつのディスカッションを行いました。
非エンジニアの方にもわかりやすいように、所々用語の解説も加えておりますので、是非レポートをお読みください。
OCTOPASSとは
2018年11月にローンチした日本唯一のCTO &テックリード育成・転職支援サービス。
エンジニアの転職支援を10年以上行ってきたインターノウス株式会社と、経験豊富なCTOを講師に迎え、実践的に技術とマネジメント力を学べます。
塩谷 将史氏
アペルザ元CTO・現アドバイザ
大学卒業後、Full Stack Engineerとして６年間様々なシステム、ネットサービスの開発に従事。
2008年に楽天に入社し、主に楽天の広告プラットフォームやAd Tech・Big Data系システムをプロデュースし、その開発組織のマネジメントも担当。
2012年シンガポール支社立ち上げに参画し、3年間でシンガポール・日本・インドの3拠点で約100名の多国籍・多拠点エンジニア組織を０から立ち上げ。グローバル広告プラットフォームの企画、開発、導入も指揮。
楽天退職後、2016年にアペルザを共同創業、CTOに就任し、製造業に特化したサーチエンジン、マーケットプレイス、クラウドサービスなどを立ち上げる。
2019年アペルザを退任し新たなスタートアップの準備と、CTO養成講座OCTOPASSのエバンジェリストを務める。
CTOは常にエンジニアであり経営者である
塩谷「CTOとは何なのか？
僕はこれは、コーディングしようがしまいが、基本的にはエンジニア・テクノロジストだと思うんですね。人によって解釈は違いますし、会社の規模やステージやサービス内容によっても全然違うと思いますが。そして、CTOは、エンジニアでありながら、経営者であることも常に求められます。
経営者の視点を持ってエンジニアをやること、つまりエンジニア×経営者であるということ、そこが一番楽しいところで、それがCTOじゃないかなと。
では、イノベーションとは何なのか？
私なりの定義では、目指したい世界やゴールに対し、技術やサイエンスやケミストリーなど画期的な手法を使ってそれを達成することを、イノベーションと呼ぶのではないかと思います。
現実の直線的な延長ではなく、ガーンと一段高いところにジャンプするような達成の仕方をする。
エンジニアは、そういうものを作っていく役割なんじゃないかなと。
ビジョンを達成するためのショートカットや、画期的な手法の1つがテクノロジーですが、その中でもここ数年ブロックチェーンが注目されていて、大きな可能性を秘めていると思っています。
私はブロックチェーンを使った開発をしたことがないのですが、CTOという立場として知りたいですし、実際どうなんですかという話を、この後の対談でしていきたいと思います。」
ディスカッション：「ブロックチェーンとCTO」
ここからは登壇者4人でディスカッションを行いました。
＜登壇者＞
元アペルザ CTO 塩谷氏
bajji CEO 小林
bajji CBO（Blockchain）藤尾
bajji CTO 小野寺
個人開発とチーム開発の違い
藤尾「bajjiでブロックチェーンサイドの責任者をしている藤尾と申します。2017年の5月に仮想通貨が盛り上がったところからブロックチェーンに興味を持ち、関わるようになりました。bajjiには2019年5月からジョインしました。その前は複合機メーカーでR&Dを担当するエンジニアで、そこまでコーディングをしていたわけではありませんでした。」
小林 「R&Dエンジニアからブロックチェーンのエンジニアに、どのように変われたんですか？」
藤尾「当時は、自分の仕事の内容が社会に貢献しているという実感を得にくかったんです。多分イノベーティブな仕事に憧れていたのだと思います。それで、19時～20時ごろに仕事が終わってからブロックチェーンについて調べたり、githubやBitcoinForumを見ながら情報をひたすら集めたりコードを書いてみたりしていました。その状態を3ヶ月くらい続けて、ブロックチェーン関連の仕事に転職しました。」
塩谷「会社でプロダクトとしてブロックチェーンを開発するのと、個人として開発するのでは結構違うのではないかと思うのですが、その辺どうですか？」
藤尾「個人で開発すると自分でレベルを設定してしまうので、レベルが低くなりがちです。会社のプロダクトの方が要求レベルが高いですよね。ですからそうした開発を経験した方が力がつくと思います。」
塩谷「具体的にはどの辺が違いますか？例えば、ブロックチェーンに興味があり、開発をしたい人がいる。そういった方に対して『そんなにブロックチェーンの開発は甘くないよ』といった点がどこかに潜んでいるんじゃないか、と思いまして。」
藤尾「そうですね。例えば、bajjiはパブリックなブロックチェーンを使ってますけど、想定外のエラーが出てくるんですよね」
小林「（会場に向けて）ところで皆さん、パブリックチェーンとかプライベートチェーンっていう用語わかりますか？」
（会場、数人手を挙げる）
塩谷「（手をあげて）ちょっとわかりません」
小林「では、ビットコインを自分で持っている方、手を挙げてもらえますか？」
（会場、数人手を挙げる）
小林「では簡単に説明しますね。ビットコインは、特定の管理者が存在しないパブリックなブロックチェーンですね。一方プライベートブロックチェーンは、どこかの会社なり個人なり一社（者）が管理しています。この中間が、Facebookが主宰するLibraです。
パブリックチェーンは、ビットコインという価値を保存したりマイニング（鋳造）したりする不特定多数のサーバーが世界中に散らばっていますが、誰がいくら持っているのかわからない状態になっています。
一方Libraの場合は、Facebookを含めた特定の複数の会社が管理していて、これをコンソーシアム型ブロックチェーンといいます。
パブリックとプライベートの中間の、セミパブリックな状態ですね。」
塩谷「なるほど。解説ありがとうございます。」
藤尾「まあ、開発が難しいのはパブリックチェーンに限ったことではないんですよね」
ブロックチェーンサービスは3つ子を育てるようなもの
塩谷「話をブロックチェーン開発の話に戻しましょうか。サービスの立ち上げ時と、プロダクトマーケットフィットの時期と、ユーザーがついてどんどん成長する時期が対比としてあった場合に、プロダクトマーケットフィットの時期の開発は、コードが汚くてもとにかく早く作って出して直してっていうのを繰り返すと思います。結果、それなりに成長していくと、リファクタリング（内部構造の改善）をするプロセスがあると思うんですよね。ブロックチェーンを使うサービスの場合、そういうリファクタリングってどうするんですか？それとも、最初のものをずっと使い続けるのでしょうか。」
藤尾「僕が設定したサービスは、できあがったパブリックなブロックチェーンを呼び出してサービスを作るものでした。ブロックチェーン上のデータはもちろん書き換えることはできませんが、それ以外の部分はどんどん書き直していました。そして、そのサービスはスマートコントラクトを使ったものだったのですが、スマートコントラクトを使った場合はリファクタリングが難しい部分があると思います。自分たちはブロックチェーンとサーバーを合わせてサービス構成していたので、色々とトライアンドエラーができる環境でした。」
小林「プロダクトマーケットフィットっていうのは、”顧客の課題を満足させる製品を提供して市場に受け入れられた状態”を見つけることを言います。通常のITサービスで問題になるのはざっくり言うと2つくらいしかなくて、UI/UXの問題か、サーバー構成の問題なんですね。ユーザー数・トラフィック数の増加にサービスを対応させないといけない。これに加え、ブロックチェーンを使ったサービスの場合、ブロックチェーンの仕様を考慮する必要があります。普通のサービスに子供が2人いるところ、ブロックチェーンサービスは3つ子をケアしないといけない」
頻繁に要件定義が変わるスタートアップの開発現場。CTOはどう振る舞う？
小野寺「僕はブロックチェーンの開発は担当していないのですが、プロダクトマーケットフィットを目指すフェーズでは、どれだけ早く市場に投入できるかというのがまず先にあって、その小さいプロダクトの状態でマーケットフィットするか意識しています。」
小林「アペルザ時代に立ち上げ期から成長期まですべて経験された塩谷さんに質問があります。スタートアップがプロダクトマーケットフィットを模索している時期には、開発順序・優先順位であったり、開発するもの自体すら変わることがあります。このような状態の時に、CTOはどのようにチームとコミュニケーションを取るのでしょうか？」
塩谷「いい質問ですね。朝言ったことを昼変えるっていうのが当たり前の世界で開発をしている時に、効果的だったのは、とにかく上意下達です（笑）。その時に、必ず理由とか根拠を伝えるんですね。Aって言ってたものをこれこれこういう理由でZになったっていうのを、言い続ける。そこに対してパッと手が動くメンバーを集める。そういう感じでやってました。」
小林「リソースの多い会社はAもZも別チームでやることができますが、そうでない会社で少人数でAもZもYも試すとなると開発効率が悪くなりませんか？そういう時はどうしますか？」
塩谷「これは私のスタイルなんですが、CEOが言ったからといって必ずしも正しいとは思わないんです。CEOが言ったことに対して、本当にそうなのか、自分なりに判断をして指示を出します。CEOはBと言ったけど私なりに解釈してAという形に落とすこともある。その時にちゃんとCEOに、こう思ったからこうしましたよと伝える。...おっと、何の話でしたっけ。」
小林「Aを半分やりかけてたけどZに変える、更にCTOはXがいいと言う、となると、ある時期まで並行して複数のプロジェクトが進んだりしますよね。Aだけやってれば100のスピードで開発できるのに、ZもXもやるので開発スピードが1/3になる。こういう時にどうしますか？」
塩谷「なるほど。とはいえ、無制限になんでも作るという状態にはならないですよね。ある程度目星もつけていると思うので、重要度の低いものを外注して難易度の高いものをシニアエンジニアに任せるなどして、動きを最大化できるようになっていればいいのではと思います。」
小林「アペルザって、開発チーム何人くらいいたんですか。」
塩谷「一番多い時で20人くらいです。デザイナーなどプロダクト作る人全部含めて。」
小林「そのチームの中でごちゃごちゃした事はなかったんですか？」
塩谷「ぶっちゃけて言うと、完全に上意下達でやってたんで、20人くらいならそれで行けるんですよね。私が中心にいて、エンジニア・デザイナー、ビジネスサイドが周りにいる。ビジネスサイドはほぼ社長でしたが。大体チームが5人以上になるとお互い何やってるかわからなくなってくると思うのですが、チームでの情報共有のほかに、会社全体での情報共有も密にやっていました。」
小林「その共有は週に一回とかですか？」
塩谷「週一回ですね。まだチームの規模が小さかったので、ボトムアップよりも上意下達の方が適していたんですよ。ただ、100人を超えるような規模になってくると、ハブになっている人がだんだんボトルネックになって、情報が行き渡らなくなってくるというのはあると思います。」
小林「例えば、5人でスムーズに回していた案件を10人で回す事になった時、一時的に非効率になる。そんな時はどうしてますか？」
塩谷「アペルザの時はそんな事はなかったですね。複数の人間で開発するというよりは、一人一人のエンジニアが自分の担当する領域で開発していて、いわゆる疎結合…こっちを変えてもこっちに影響しないという状態にしていました。
一方、楽天でシンガポールでチームを0から立ち上げた時は、開発しなければいけないものがすごく大きい規模のもので、1つの機能を作るのに3〜4人がアサインされるような感じでした。1人で作ってるものを複数人で作ろうとすると非効率になってくるので、誰かがリーダーかハブになって、その人がメンバーの面倒も見るような小さなチームが複数形成されました。その状態は非効率かもしれませんが、そうでないとスケールしないので。50人いたら5〜6人のチームに分けて、ハブの人を決めて、ハブの人だけを集めたミーティングで情報共有したり。どんどん分割していきましたね。」
小林「ハブを作る単位というか、適切な大きさってありますか？」
塩谷「一般的には3人から8人って言われていると思いますが、5人くらいがちょうどいいと思います。スタンドアップ・ミーティング（15分間立ったまま進行するミーティング）をやっても飽きないサイズ。8人くらいいると飽きてきちゃいますね。」
チームコミュニケーションをどう円滑に進めるか
小林「（会場にいるエンジニアの方に向けて）エンジニアの視点から、チームコミュニケーションやカルチャーギャップなどについて何か意見や質問ありますか？」
参加者「自分は大企業から10人くらいのチームに出向していて、新しい人が入れ替わり立ち代わりするような環境なんですが、みんな近くにいるのに直接話さずにTeams（Microsoftのグループチャットツール）でやり取りしていることが気になっていました。履歴が残るからいいという側面もありますが、コミュニケーションという意味ではちょっと違うと感じていました。」
小野寺「僕たちはリモートで作業することも多いので、チャットツールのSlackをメインで使ってますね。スタンプだけで会話ができるのが便利だし、みんなSlack大好きですね。」
小林「Slackの他にAsanaっていう管理ツールがあるんですけど、私はまだ使いこなせてないです（笑）」
塩谷「それは、エンジニアのツールをビジネスサイドの人間が使いこなせないっていうあるあるの話ですか？（笑）」
藤尾「いや、まだエンジニアサイドもそれは使いこなせてないです。なんとかタスクの見える化はしていきたいと思ってます。」
小野寺「先ほど上意下達という話がありましたが、塩谷さんは、小規模なチームでは、エンジニアには自発的な開発はさせてこなかったのでしょうか？」
塩谷「モノによってはありました。具体的な例で言うと、アペルザで検索ツールを作っていたことがあって、検索の精度を上げる担当のエンジニアがいたんですが、明確な指示をこちらからは出せないんですね。精度を上げてほしいとしか言えない。そうするとエンジニア主導で、こういうことをやりました、こういうことをやってみたいです、という進め方をするんですね。こちらはおだてて乗せるような感じ。クローラーを作るときも完全にエンジニア任せでした。最終的にこういう事がやりたいというのを伝えて、プロセスは任せる。
絶対に外してもらいたくないポイントだけを決めて、それ以外は自由にボトムアップでやってもらっていました。」
飲みニュケーションよりも真剣かつカジュアルな技術トークランチを
藤尾「エンジニアとどのようにコミュニケーションをとっていますか？信頼関係を築くために飲みに行ったりする人もいますよね」
塩谷「自分は、飲みに行ったりとかには頼らないですね。技術の話で真剣に向き合います。自分はアペルザでも楽天でも、ビジネスをどうエンジニアリングで実現するかっていうハブの仕事をずっとやっていたんですが、ビジネス側の情報もインプットするし、そこに対する疑問も全部受け止めて、技術も理解して、場合によっては技術面での指示も出す、というコミュニケーションをしてました。
仲良くなるというのは置いておいて、仕事の話を真剣にするっていうスタンスです。それが厳しいと受け止められてもいたようなんですが、フランクにフレンドリーにやってたつもりです。壁は絶対作らないですし、ランチの時に新しい技術の話や興味を持った技術の話をよくしてましたね。
エンジニア的にもそういうコミュニケーションの方が好きだと思うんですが、どうなんですかね。」
小野寺「今bajjiはエンジニアが10人いて、彼らは組織が大きくなった時のトップ層（管理層）になる方々だと思っていて、意見を言っていただいたりどんどん自発的な開発をしていただきたいんですが、僕の中にある譲れない部分を伝えるのが下手で（伝え方や伝えるタイミングなど）、開発が逆戻りしたりして迷惑をかける事があります。」
藤尾「うちはエンジニアが皆優秀なので、そこらへんは読みながらやってます（笑）」
塩谷「そういう関係性いいですね。1つ聞きたいのは、CTOから見て、CEOはエンジニアとコミュニケーションする時にどうあってほしいですか？」
小野寺「そうですねー、小林CEOからは、（手を上から振り下ろしながら）上からドン、ドン、って感じのフィードバックが来るのですが、僕はそれをそのまま受け入れられない時があったりします。そういう時に気をつけているのは、小林さんがおっしゃったことを言葉通りではなく、何を実現したくてその言葉が出てきたのか、本質の部分をしっかり読み解くようにしています。自分なりに解釈して実装に落とし込むことを意識しています。」
塩谷「CTOの方がCEOを忖度しなきゃいけないというか、気を使ってる感じですかね」
小野寺「（真顔で）そうですね」
（一同笑、小林苦笑）
小林「一応言い訳しますと、私は大学時代はコンピューターやっててある程度は分かってるんです。その上での”ドン”です。」
ブロックチェーンに関する質問：OSSのリスクとVC対策
小林「（会場に向かって）時間も迫ってきていますが、ブロックチェーン関連で何かご質問ありますか？ベーシックな質問でも構いません」
塩谷「（挙手）ベーシックなこと聞いていいですか」
小林「どうぞ」
塩谷「さっきのご説明の時にちょっとよくわからなかったんですが、APIでパブリックチェーンを呼び出す方って何なんですか？」
藤尾「ブロックチェーン上に構築されたフレームワークです」
小林「ブロックチェーンを操作するAPIセットがブロックチェーン上にあって、それを外側からbajjiのAPIが呼び出すという仕組みです。ブロックチェーン本体やフレームワークの仕様変更・バージョンアップがあると、こちらもそれに対応しないといけないです。（逆に、こちらがシステムをメンテナンスしたりバージョンアップしなくても別のコントリビュータがやってくれるとも言える）」
塩谷「パブリックチェーンの安定性とかはどうなんですか？」
藤尾「現段階ではかなり安定していると思います。新興のブロックチェーンだとバグが多かったりもしますが、bajjiが使っているカウンターパーティーはビットコインの上にのっかっているので、安定している方です」
塩谷「そのパブリックなブロックチェーンを作っている人たちっていうのは、いわゆるOSS（オープンソースソフトウェア）のコミッターなんですか」
藤尾「そうです」
塩谷「（会場に向かって）OSSを使って開発されている方っていますか？」
（反応なし）
小林「OSSは導入はしやすいですが、意図しないバージョンアップに対応する学習コストがかかりますね。他に質問ありますか？」
参加者「ブロックチェーンは、非中央集権的なシステムが作れるのが革新的だと思うのですが、それをうまく利用できてるサービスって現状あんまりないように見えます。今後そういうサービスは出てくると思いますか？」
藤尾「難しい質問ですね。中央集権的でない取引所のDEX（分散取引所：Decentralized Echange）や、分散的に金融・証券分野を扱うDeFi（分散型金融：Decentralized Finance）などが出てきていると思います。ただそれ以外では、まだまだ活用先が見いだせていないのかなあと。」
塩谷「パブリックブロックチェーンでないものは、非中央集権的ではないということ？」
小林「そうですね。セミパブリックなものとしてLibraなどがあります。これをLibraに参加する20社が牛耳っていると見るか、20社に権利が分散されていると見るか。」
塩谷「金融以外の領域でブロックチェーンを面白く使っているサービスって、bajjiの他にどのようなものがありますか？」
藤尾「自分たちは信頼を形成するためにブロックチェーンの”改ざんされない性質”を活用しています。そういう性質を使ったサービスは他にもあるんじゃないかな。海外にはあると思いますが、パッと出てこない。」
塩谷「パブリックブロックチェーンでサービスを作った時に、VC（ベンチャーキャピタル）からリスクを指摘されることってないんですか？パブリックブロックチェーンがダメになったらどうするの、とか。」
小林「それはすごくあります。うちのbajjiはその経験を踏まえて、今のシステム構成にしました。2017年に日本でも話題になったICO（InitialCoinOffering）というのがありますが、ICOっていうのは、こんなブロックチェーンとコインを作りますって宣言してお金を集めてたんですね。同時に二兎を追うようなものなので、ことごとく失敗したんです。0→1を2つ同時に追わないといけない。しかもサービスをグロースさせる事と、コインをグロースさせることの利害は、相違することもあるので難しいんですよね。
bajjiは、もし今のブロックチェーンが合わないと思ったら違うブロックチェーンに移れるように設計しています。なのでうちはVC受けすると思います。（笑）」
即席・ブロックチェーンアイディアソン
塩谷「（会場に向けて）ブロックチェーンを使えそうな領域って他に何かアイデアあります？軽くご意見を伺いたいです」
参加者「私は製造業にいるんですが、なにかアイデアはありますでしょうか」
塩谷「製造業は親和性高そうですよね。カタログのバージョン管理をブロックチェーンでできそうかなって思ったりしました。商品画像の真正性を担保したりっていうのも考えられますね。」
小林「今後中古物品を扱う事業をする場合に、メンテナンス履歴とかがブロックチェーンに刻んであると良さそう」
塩谷「品質保証とか、販路の保証をサービスまたいで簡単に共有できるといいですよね。」
最後に：開発においての失敗経験を共有
塩谷「プロダクトの将来における可用性や拡張性などを考慮するという事について、エンジニアの観点から将来的に楽になるようにと欲張ると、汎用性の高い物が出来上がってしまう。その結果、1-2年経っても使われないような仕組みや、機能が生まれてしまうわけですよね。
僕自身の過去を振り返って失敗だったのは、0-1の段階で拡張性を考えすぎてしまって、作り直すことが多かったです。それが正しいと思って進めてしまい、今考えると、もっとシンプルで後で潰しても良い物を作っていった方が良かったのかなと。」
・・・・・・・・・・
この後も、会場の参加者を交えてのブレストが続きました。
イベントに参加してくださった皆様ありがとうございました！
BUTAIでのイベントは12月分まで開催が確定しており、是非多くの方に足を運んでいただきたいと思っています。
▼11月13日開催
▼11月20日開催
▼11月27日開催
▼12月のイベント一覧はこちらからチェック！