【CTO対談：hey × Kanmu】素直に、素朴に、ソフトウェアと人に向き合う
最前線スタートアップのCTOは、普段どんなことを考え、どんな悩みを感じているのか？経営目線だけではなく、一エンジニアとしてのこだわりや思想を深掘ることで、よりその会社の技術に懸ける想いが伝わるのではないかと考え、初めての「CTO対談」を行いました。お話いただいたのは、ヘイ株式会社(以下、ヘイ)CTO藤村さんと株式会社カンム(以下、カンム)CTOの伊藤さんです。カンムCOOの知久さんにモデレーターとなっていただいて、CTOのおふたりが感じる「ソフトウェアエンジニアリング」について対談形式でお話を伺いました。
左から、
・カンムCTO伊藤さん https://github.com/mururu
・ヘイCTO藤村さん https://github.com/fujimura
・カンムCOO知久さん https://github.com/achiku
(期せずして、取材日は３人そろって白シャツ×短パンでした！)
ーー簡単に会社紹介をお願いします。
藤村：誰でも本格的なネットショップがつくれるサービス『STORES』とお店のキャッシュレスサービス『STORESターミナル』を展開するヘイ株式会社(以下、ヘイ)のCTO藤村です。先日、予約システムの開発・運用を手掛けるクービック社も仲間に加わりました。こだわりを持って夢中に何かに取り組む人たちが、「お商売」を通じてできることをもっと増やすために、サービス作りに勤しんでいます。
伊藤：カンムCTOの伊藤です。「心理的unbankedをソフトウェアで解決する」というビジョンの下、「使いすぎが不安」「なんとなく怖い」等の心理的な理由で金融サービスに距離を感じている人や、オンライン決済手段を持っていない方に対してVisaプリペイドカードアプリ『バンドルカード』を提供しています。2018年より、後払い式のチャージにも対応し、自宅でカード発行・チャージ・決済が完結する体験を実現しています。また、現在決済x投資領域の新規プロダクトも開発中で、2020年にリリースできるよう開発を進めております。
〜２社の募集中求人情報〜
▼ヘイ株式会社 募集中職種
▼株式会社カンム 募集中職種
ーーエンジニアのチーム構成は、どのような体制ですか？
伊藤：今現在提供しているのが「バンドルカード」のみなので、１つのチームで企画〜開発まで一気通貫して行っています。人数としては、フルタイムの業務委託の方含めてまだ１桁という小回りのきくサイズ感です。技術面では、アプリはReact Native、バックエンドではGoをサーバー言語として使用しつつAWSと一部オンプレで運用しています。
面白いのは、決済部分の仕組みです。決済は、ウェブで完結する一般的なECサイトのシステムとは異なり、Visaやパートナー企業のデータセンターと直接つなぎ込み、ウェブの世界から少しはみ出しているので、珍しい体験ができると思います。
カンムCTO 伊藤さん
藤村：チームはSTORESとSTORESターミナルと、プロダクト別に大きく２つに分かれています。STORESは約40人、STORESターミナルは10〜20人程度で担当しています。STORESはバックエンド・フロントエンド・SRE、STORESターミナルはバックエンド・フロントエンドと、職能別に分化しています。また経営統合に伴い、2つのサービスの共通基盤（プラットフォーム）を創るチームも立ち上がっています。
ーーソフトウェアの設計をする上で、大切にしていることはありますか？
伊藤：2つあります。1つはソフトウェアの設計に入る前に「ソフトウェアを通じて達成したい目的の解像度を上げる」こと。仕事でやるのであればビジネスモデルを理解することはもちろんのこと、ユーザーが本当に必要としてるものは何か、どういうチーム構成で運用していくのか、利用する外部サービス、関連ソフトウェアなどエンジニアリングやソフトウェアに直接関係しないものでも、設計前にどれだけ現実に即した形で理解できるかが、より良い設計に繋がる土台となると考えています。
その土台の上で「できるだけ素直に実装する」ということが2つ目に大事にしていることです。現状理解の土台がしっかりあるからこそ、「これは本当に必要な抽象化なのか」、「こういう機能が入るかもしれない」等の議論をより地に足のついた形で行えると感じています。そういった議論を経て、その上でいかに素直な設計にするかということは、非常に大切にしています。
藤村：自分も伊藤さんと似ているんですが、周辺のコンテクストを十分に把握した上で「できるだけ素朴に設計する」ことですかね。素朴というのをもう少し具体的に話すと、最小の概念やレイヤーで対象を正しく説明できるかどうか、という観点で、これはソフトウェア設計以外の仕事でも意識している部分ではあります。昔、その辺りの話を簡単にまとめたのがあって、コレです。
藤村さんのFacebook投稿より引用
なので、設計している際に「工夫してなんとかできる」と「素朴にやればできる」のどちらかを取る際には意図的に素朴側を選択していると思います。線形時間で手を動かして問題を倒せるのであればそれで良いというか。
知久：自分もお二人と似たような設計の傾向あるなぁと思いつつもう少し理由を伺いたいのですが、なぜ「素朴/素直に実装する」というのを大切にしているのですか？
藤村：やはり素朴な作りは変化に強いからですかね。工夫して凝り始めてしまうと、変えるコストが高くなってしまうと感じています。複雑で現状把握にコストが掛かる為変更しづらいというのもありますし、そもそも複雑で絶妙なバランスの上に成り立っている設計は、変更の波及先まで含めた考慮点が多く変更しづらい、という感じですかね。
伊藤：自分も藤村さんに同意なのですが、1点追加するとすれば、わかりやすい方が自分が理解しやすいのはもちろん、チームで取り組む時にもメリットが大きいと考えているというのはありますね。新しくチームに入った人がコードを見たり、レビューをする中で、少ない概念で/少ない範囲のコードを見て現状の処理を理解できるのであればそれに越したことはありません。もちろん、個別具体的な議論の中で盲目的にシンプルさやわかりやすさを追求するという事はしないのですが、複雑さを導入するコストに対して意識的であるというのはある気がします。
藤村：そうですね、基本方針は素朴側に倒すというのは同意なのですが、時にはラフプレーが必要な時もありますよね。
伊藤：確かに。議論して練り上げた目的に照らすと、シンプルだと自分が感じる方法ではそれを達成できないこともあります。
知久：今まででラフプレーというか、素朴に作らずにある程度の複雑性を持つ事が必要なシーンに向き合ったことはありましたか？少し前の話ですが、伊藤がErlang/OTPにパッチを投げて特定処理のパフォーマンスを5倍ほど改善したと記憶してます。そういった非線形な効果が出るものに対しては複雑性を導入する方が、コストが見合うといった経験はありますか？
伊藤：あの経験は複雑ではなく、すごく真っ当でシンプルな修正でした。カンム入社前に働いていた会社で、WebRTC SFUサーバーのパフォーマンス改善をやっていたのですが、ボトルネックはメディアを暗号化する部分だというのはプロファイルからも明らかでした。それ以外の部分を複雑に工夫して、パフォーマンスを担保するという選択肢もあったのですが、最も大きなボトルネックは特定できており、解決する手段も世の中には存在している、且つ自分はそれを実装できるだろうということで、単純にやった、という流れですね。
藤村：王道ですね。
知久：なるほど。複雑だと思っていましたが、実はシンプルで素朴だったという良い話ですね！藤村さんはどうですか？
対談モデレーターを務めたカンムCOOの知久さん
藤村：長い期間ではありませんが、20代の頃は結構トリッキーなものに凝っていた時期はありました。新卒の頃から単純な道具立てで物事を解決していくのが良い、という姿勢はあったのですが、その時代においては「俺のこの抽象化されて凝ったソリューションはどうだ！」みたいな驕りがあったかなと、振り返ってみると思いますね。
知久：藤村さんみたいな方でも、それをやっていたという話、良い話すぎます！
伊藤：あと、複雑性が持ち込まれるのって、自分たちが完全に管理できるコード以外の部分じゃないかなぁというのもあります。外部のシステムをつなぐ、ネットワークのトポロジーを決めるといったことは、外部環境が既に持っている複雑性をどうしても取り込まないといけない側面がある。特に自分たちが手を入れられない外部システムをつなぐ際は、それらが持っている概念を抽象化して自分たちのシステムの中の概念と全く同じに扱えるように設計するのか、もはやそれは別の概念として切り出すのかという選択肢があると思います。そういったタイミングと向き合った時には、「素朴に別概念として扱う」ことが多い気がしますね。
1,000人の組織において、ある1人が、組織が本来向き合わなければいけない複雑性を吸収可能なライブラリを作り、残りの999人がそれを利用することで、一人あたり開発効率が上がり、複雑性に支払うコストが見合うという現象はあるだろうとは思います。ただ、10人程度の組織であれば素朴に全員理解できる形になっている事の方がメリット大きいかな、と考えるケースが多いです。
ーーおふたりはCTOというチームを率いる立場にいらっしゃいます。チーム作りにあたって、意識していることはありますか？
伊藤：どういう人がチームに入って欲しいか、という質問だと捉えると、「自立して動ける人」というのが今の会社の状況にマッチしていると考えています。まだまだ人数も少なく、改善点はたくさんある為、自分の得意領域の視点からプロダクトを見て、改善余地や優先順位を決めて、オーナーシップを持って進めて行ける人にお任せできると大変ありがたいという感じです。
藤村：現状組織化はうまく進みつつあるので、次の課題として「スケールする組織をどうやって作るか」ということをマネジメント目線で意識しています。また職能面で、それぞれのスペシャリティが存在する中で、「どういった人材配置が最適か」ということも考えていますね。
ーー「良いチーム」って、どんなチームだと考えていますか？
伊藤：成そうとしている事があり、それを成せるチームが良いチームだと考えています。そのためには、何を成そうとしているのか、そのために必要なことが何かを適切に問い続けられ、かつ達成するための技術を持っている状態が大切なのかなと思います。
知久：とはいえ目的が曖昧になってしまうタイミングも結構ありませんか？
伊藤：それはそうで、目的ややるべき事が常に明確なわけではなく、曖昧な場面も多々あります。株式会社という枠組みの中でやっていれば株主利益の最大化もあるし、自分たちが向き合ってるユーザーの方々が本当に必要としているのは何かという観点もあるし、中期で見て会社としてプロダクトをどの方向に進めるべきなのか、という点も含めて、何を選択していくのかを決めるのは大切。そういう時でも「何でこれやるんだっけ？」ときちんと問い続けて、必要に応じては「それ違うんじゃない？」と建設的な議論ができる、今やっていることに納得して目的達成のために進んでいる状態が、健全で良いチームだと思います。その上で、成すべきと決めた事に対して自分たちの技術を適切に運用していけるのが良いんじゃないかなと。
藤村：全然別の軸なんですけど、自分が今まで関わったチームで一番うまくいってると感じたのって、自分でやっているバンドだと思うんですよね。もう15年も続いているんですが、喧嘩も5年に1回くらいで滅多にしません。なんでだろうと考えると「お互いの苦手なことを、なんとなく補完しあえること」が理由として浮かびました。頑張ってもある程度時間をかけないと身につかないものってあったりするじゃないですか。なので今できないことに時間を割いてもらうより、「これやっとくわ」と気前よく引き受けるし、頼める。そういう関係って、かけがえの無い資産だと思っていて、それは個人的には良いチームの定義としてあるよなぁと思います。その関係を仕事でも築くためには、非常に難しいんですけど「正直でいること」はとても重要だと思います。「これ辛かったわ」とか「これは嬉しかった」という自分の意見や考えは、想像以上に正直に、そして意図的に伝え続けないと、本当に伝わらない。相手に理解する部分を任せてしまっていると、少しずつ歪みが出てきてしまうなと感じています。
ヘイCTOの藤村さん
伊藤：すごく良い話だなと思う反面、そういうのって人数多くなっていけば多くなる程難しくなりそうな気がするんですが、どうですかね。誰が何が得意とか苦手とか、把握し続けるの大変そうという素朴な感想ではあるんですが。
藤村：今の話題でいうとソフトウェアエンジニアチーム単位の話なので、マネージャー1名で下に100名いるみたいなチームでは流石に難しいと考えています。なので、数人単位で割ったチームの内部で気をつけたい事という感じですね。
ーー設計段階でも「素直・素朴」というワードが出てきましたが、人柄やチームでも共通する部分がありそうですね。
藤村：根は素直なんですが、性格が少しひねくれているので、「素直でありたい！」という意思は他の人より強いかもしれません(笑)ネーミングはさておき、いつでも素直な「まっすぐエンジニア」でありたいですし、そんなチームでいたいですね。
伊藤：でも、エンジニアの素養として「素直さ」が大事だなというのは、僕も深く共感できます。おそらく色んなソフトウェアをがむしゃらに作っていく経験をしたからこそ、一周回って「素直が一番良い」と気づけたのかもしれません。
ーーエンジニアの評価にあたり「技術力が高い/低い」という言葉を聞きます。「技術力が高い/低い」とは、どういう意味だと考えていらっしゃいますか？
伊藤：一般的に使われている文脈での技術力の高低みたいな話題はそこまで深く考えたことはないのが正直なところです。「技術力が高い/低い」が指し示すものはコンテクストに依存してしまい、どういう場面で技術を行使するかによって全く異なってしまうため、「技術力が高い/低い」というフレーズだけで表現するのは難しいと思います。
もう少し具体的に、ソフトウェアエンジニアが持っているべき技能、という観点で言語化すると「未知の環境/事業/技術スタックに出会っても、高速で学習を繰り返し成果を出せる」という軸が自分の中にはあり、そういう人と一緒に働けるのは経験上すごく楽しく且つ勉強になるなと思います。もちろん本人の意向としてインフラ/バックエンド/フロントエンドまで幅広に見たい、一つの領域、例えば機械学習やネットワークサーバーを書く、みたいなものを突き詰めていきたい等、どのような形で技術を伸ばしていきたいかという方向性はあるのですが、どのような方向性を持っている方でも「高速に学習し、最終的に成果を出せる」という汎化された技能を持っている方は強いなと思います。
藤村：伊藤さんと同じく、コンテクスト依存が強く比較しようがないと思うんですよ、技術力って。「とうもろこしと餃子どっちが美味しい？」って聞かれるのと同じ感覚があって。どっちもそれぞれ美味しいよね？みたいな。
自分も少し「技術力の高い低い」の話とは逸れてしまうのですが、ソフトウェアエンジニアを見る観点としてはStack OverflowやTrelloを開発したジョエル・スポルスキ著の『ソフトウェア開発者採用ガイド』の一節が良く出来ているなと感じています。その一節は「採用基準は 1. 頭が良く、2. 物事を成し遂げる の2点が重要」という部分。エンジニアリングの仕事は他の職種と比較して、もちろんそれだけではないのですが、「何かの課題を解決すること」にフォーカスが当たる事が多いです。これは複雑な課題を理解し、持てる知識を総動員し最も効率的な方針を検討する「頭の良さ」と、実際にその方針を運用して最後まで「物事を成し遂げる」事ができる必要があるという点で良く課題解決能力の定義と符号しているという点もさることながら、どちらか一方だけに当てはまる人はそれなりにいて、どちらか一方だけだと危ういよ、という事を示唆している部分も良く練られている一節だなと感じますね。大量の整頓された知識があっても成し遂げられなければ駄目だし、成し遂げる為に愚直に100段CASE文を書きメンテし続けるのも...もう少しなんとかなるのでは...みたいな。
ただ、「課題解決能力」とざっくりくくられる一般的な部分ではなく、特定の領域を強化するエンジニアが現れても良いんじゃないかなという思いもあります。ボクシングを例で挙げるならば、「ストレートもフックも、アッパーも得意です」といった掛け算でスキルをアピールするケースを、最近はよく目にするのですが、もっと「俺、ストレートなら誰でも倒せます！」という人とも出会いたいですね。
ーーチームの加わり方として、「副業」という関わり方もあると思います。副業に関しては、どのような意見をもっていますか？
藤村：個人的な意見として「副業は資産がたまる」ので、機会があるならどのエンジニアもやった方が良いと思っています。他のサービスのテクノロジースタックを見ることで、持って帰れる知見も、逆に副業先に教えられることもあり、知識の交換としてハイレバレッジな機会だと思います。
知久：エンジニアの副業は、「ビジュアルリグレッションテストをしたい」とか「フロントのCIを整備したい」といったトピック単位で切り出せるので、スーパースペシャリストにも依頼しやすいのが良い点だと思うんですが、ヘイと比較してまだ組織が小さいカンムだと、どういった人なら副業でも活躍できますかね？
伊藤：そうですね。カンムのサイズ感だと、まだ業務を切り出すこと自体が難しいフェーズかもしれません。走りながらやることが変わる感じなので、その状況に適応してくれる方であれば、是非副業として新しい経験を組織に持ち込んでほしいなと思います。
ーー最後に、こんな人と一緒に働きたいということがあれば、ぜひ教えてください。
伊藤：先程話した課題解決の話から少しズレてしまうのですが、個人的には「ソフトウェア好きな人が好き」なんですよね。なので、基礎的な部分は踏まえた上で、そういったところで共感できる人と働けると嬉しいです。僕自身、大学の暇だった頃に何気なく勧められた『独習C++』をやってみて、楽しくてのめり込んで、がむしゃらに続けて今があるという人なので、ぜひソフトウェアが大好きで、ソフトウェアを通じて社会の課題を一緒に解決していきたいという人と働きたいです。
藤村：「難しい問題を解くのが好きな人」と働きたいですね。僕の場合、大学時代に専攻した哲学がその原体験ですが、哲学分野のとにかく難しい事象を議論して理解していくその過程がとても楽しかったんです。お伝えした通り、エンジニアは「何かの課題を解決すること」が基本の仕事ですが、その設定する課題自体が難しいものであればあるほど、大きな価値を社会に返せると思います。なので、ぜひ世の中の難しい問題を解くことにワクワクする人と、色んな形で関わりたいですね。
ーーありがとうございました！(取材：2020年8月)
-------------------------
今回対談を伺ったヘイ社・カンム社ともに、エンジニアの採用を絶賛強化中です！副業からの関わり方も可能です。(要相談)
興味のある方は、以下採用ポストをご覧ください！
▼ヘイ株式会社 募集中職種
▼株式会社カンム 募集中職種
-------------------------
副業・転職のキャリアSNSのYOUTRUSTでは、エンジニア職をはじめITインターネット業界で自分のつながりに近い求人情報を、確認・応募することができます。ユーザー登録はこちらから。