「組織をつくる」という、エンジニアリング｜カウシェ Architect ✖︎ Backend Engineer 対談
「会社が大きくなっていく上で、どんなことをやっていくと組織がうまく回るかを考えることも含めて、エンジニアリングと言うんだと思います。」「カウシェというこれから大きくなるサービスを支え、組織を作っていくことは、私にとってチャンスだと感じました。」——今回は、10/1から入社したBackend Engineerの柴田に、なぜカウシェに入社したかや、これからのカウシェについてなど、Architectの伊藤が聞いていきます。
柴田 芳樹 / @Yoshiki Shibata
九州工業大学情報工学科で情報工学を学び、1984年同大学大学院で情報工学修士課程を修了。パロアルト研究所を含む米国ゼロックス社での5年間のソフトウェア開発も含め、Unix（Solaris/Linux）、C、Mesa、C++、 Java、Goなどを用いたさまざまなソフトウェア開発に従事してきた。現在もソフトウェア開発に従事し、個人的な活動として技術教育やコンサルテーションなどを行っている。2000年以降、私的な時間に技術書の翻訳や講演なども多く行っている。
伊藤 雄貴 / @yuki.ito
DeNA を経て 2018 年にメルペイにジョインし、Tech Lead や Architect としてマイクロサービスの開発や組織横断的な技術課題の解決に携わる。カウシェには立ち上げのタイミングから複業として参画しBackend全般の実装を行う。2022年7月よりArchitectとしてカウシェに正式にジョインし、全社的な技術戦略の意思決定や技術基盤の構築に携わる。
「どんなことをやっていくと組織がうまく回るか」を考えることも含めて、エンジニアリングである
@yuki.ito：
Shibataさんとは前職のメルペイで1年ほど同じチームだったのですが、改めて、なぜカウシェにジョインしたのかをお伺いしても良いですか？
@Yoshiki Shibata：
はい。理由は複数あり、ひとつずつお話しします。今回で7回目の転職なのですが、YOUTRUSTで転職意欲を切り替えた時にカジュアル面談の連絡が10〜11社ほどあり、その中の一つがカウシェでした。全ての話を聞いたのですが、カウシェが一番積極的で。
@yuki.ito：
一番積極的でしたか！Shibataさんとは、もう一度一緒に働きたいと素直に思っていました。
@Yoshiki Shibata：
それは嬉しいです。元々Webサービスの開発に従事したのがメルペイが最初だったんですよ。
@yuki.ito：
前職でKubernetesやGoogle Cloud Spannerの話をしていたのが懐かしいですね。
@Yoshiki Shibata：
使っている技術も単語も初めて聞くものだったので、「Spannerってなんだろう？なんとなくデータベースっぽいな」など思いながら自己学習をしつつ、yuki.itoさんも含めチームのメンバーに助けてもらいながら、なんとかマイクロサービスの開発をやっていました。
2018年の1月にメンロー・イノベーションズというアメリカの会社の社長と私ともう一人でセミナーをやったのですが、メンロー・イノベーションズはペアプログラミングしかしないんです。
どういう形でやるかというと、必ずペアの二人が隣の席になり、1週間で終わるくらいのタスクをこなしていくんです。その1週間が終わると次は違うタスク、違うペアになりまた1週間行うという形なのですが、そうすることで人が増えた時のスケールアップを行いやすいですし、人が減った時のスケールダウンも行いやすい。
そういった形で知識を共有しながら開発をしていかないと、うまくいかないんだと、そのセミナーでの話で思いました。個人的にはそういうことをやってみたいと思っていて、カウシェでそれができるのではないかと感じたのです。
ソフトウェアエンジニアとしては開発だけではなく、これから大きくなる「開発組織」のチームをどう作り、会社の生産性をどう上げるか、といった部分に興味があり、カウシェで私自身の経験を活かし、貢献していきたいと思ってジョインを決めました。
@yuki.ito：
すごく楽しみです。まさに自分も最近は個人として技術力を高めるだけでは会社の生産性が上がらないと考えていて、理想となるアーキテクチャを実現するために、チームトポロジーの考え方などを踏まえてチームや組織の構造を進化させていきたいと思っているところなんです。
コンウェイの法則のように、組織の構造が、組織の設計するシステムにも反映される。逆もしかりで、望ましいシステムアーキテクチャを作るために、チームや組織を良くしていくと言った考え方もあると思います。
@Yoshiki Shibata：
そうですね。そう言った意味で、ソフトウェアエンジニアは、「ソフトウェアを開発する組織に対するエンジニアリング」の要素がありますね。
エンジニアリングは、与えられたタスクでものを作っていれば良いという雰囲気があるのですが、組織開発が大きくなっていく上で、どんなことをやっていくと組織がうまく回るかを考えることも含めてエンジニアリングと言うんだと思います。
@yuki.ito：
そうですね。カウシェは嬉しいことにプロダクトの成長に伴って開発に携わるメンバーも増えているので、今まさに組織のあり方も設計していかないといけないな、と思っています。
@Yoshiki Shibata：
それを思ったのは、今年読んだ「Googleのソフトウェアエンジニアリング」という本がきっかけで、「ここに書いてあることこそがエンジニアリングだ」と思ったんです。
Googleと全く同じとはいかないですが、カウシェというこれから大きくなるサービスを支え、組織を作っていくことは、私にとってチャンスだと感じました。
@yuki.ito：
カウシェのバリューで「For Team」という言葉があるのですが、チームとしてどれだけ生産性を高められるか、会社としていかに早く価値をお客様に届けられるかというところを目的に、どう組織を作るかをShibataさんと、みんなと、楽しみながら一緒に考えたいです。
「育成」の重要性
@Yoshiki Shibata：
過去に6回転職しましたが、転職する一つの動機として、自分自身がソフトウェア開発をしたいというものがあります。その一方で、「若い人を育成する」ということも非常に重要だと思っています。
カウシェも大きくなってきたら新卒採用をするかもしれません。そうなった時に、会社の5年後10年後を支えるのはその人たちなんです。
若い人をきちんと育成していかないと組織は大きくなっていかない。そういう風に思ったのは1996年に日本オラクルへ転職した際に、その月に入社した中途採用のメンバーを集めて当時の社長から話がありました。「みなさんは即戦力だが、5年後10年後の会社を支えるのは今の新人だから、会社としては新人を大切に育てていきます」と言われました。
実は以前の私は、できない人にはソフトウェア開発をさせない方が良いのでは、というスタンスが強かったのですが、その話が転機で、若い人の育成を考えるようになりました。
@yuki.ito：
そうだったんですね。カウシェのプロダクトチームには新卒で入社したメンバーはいないですが、新卒に限らず、中途採用の人だったとしてもカウシェが今使っているスタックを全部知っている人は少なく、そういったものをレクチャーしていくところは大事だなと思いました。例えばインシデントが起きた時も、分かっている人がサッとやってしまうのも良くないと思っていて、自律・自燃に動けるために、チームで知識の共有をして、会社として強くなりたいと考えています。
@Yoshiki Shibata：
多くのスタートアップは外部向けの発信はたくさん行っているが、内部向けの知識共有はまだ手をつけられていないところも多く、難しいところですよね。
@yuki.ito：
まさに難しさを感じています。カウシェのバックエンドのコードも最初は自分が書いていたのですが、設計的な部分をチームに完全には伝播しきれていないと感じています。なので、設計思想なども含めたドキュメントを作り、入ってきた方への共有体制をしっかり作っていかないとなと、強く感じています。どうやって進めていくのが良いか、Shibataさんとぜひお話しさせていただきたいです。
@Yoshiki Shibata：
もちろんです。2000年頃から、1年間のかなりしっかりとしたJava言語教育を行ってきていたのですが、最初はみんな予習の練習問題300問で土日が潰れるなどと言っていました。その教育には毎回受講生が10数人いるのですが、終わった頃には「1,000ページ近くの本を一人では読めなかった。やってよかった」とその多くが言っていましたね。
@yuki.ito：
それはかなり基礎力が付きますね。
@Yoshiki Shibata：
そうですね、受ける方はキツかったと思いますが、その後活躍している人も多く、やっていてよかったと思っています。
今のカウシェの課題について
@yuki.ito：
リリース当初のカウシェでは、デプロイするAPI サーバーがひとつしか存在していませんでしたが、Modular Monolithのようにいくつかに分割できるように作ってきていました。
今年の9月でサービスをリリースしてから2年が経ち、メンバーも増え、サービスも伸びている中で、全員で同じAPIサーバーを実装することが難しくなっており、今まさにそれを技術的にも、組織的にも、どう分割していくかが課題になっています。
Shibataさんは、みんなで作ってきたひとつのものを分割するときに、どういう風に分けていくかなど、ご経験はあったりしますか？
@Yoshiki Shibata：
実は既存のものを分けたことはあまり経験がないんです。これまではイチからものを作ることがほとんどで、アーキテクチャを先に考えて、それに沿ってチームを作るパターンが多かったです。
前職のメルペイではチームごとにやり方が違いました。例えば、デプロイするときに複数の修正が含まれることがあると思うのですが、チームによっては複数のメンバーによる修正を毎週何曜日にまとめてデプロイすることもあります。私が最後にいたチームはそうではなく、各人がPull Request を作成し、QAを終え、その単位でデプロイしていく形でした。多い時は1日3回くらいリリースがありました。それを経験してみると、「ああ、こういうやり方でも上手く回っていくんだな」と思ったのです。
@yuki.ito：
アジリティが高くて良いですね。
先ほど話に出た「Googleのソフトウェアエンジニアリング」という本にも載っていましたが、カウシェはチームごとに違う進め方をする必要はないと思っており、生産性を高めるために、会社としての標準的なものづくりの方針に全チームが沿っている体制を作っていきたいと思っています。
みんなが自律して同じやり方を行い、チーム間の人の流動性を高めていける状態を作りたいです。
@Yoshiki Shibata：
そうですね、それは必要だと思います。
標準を作るということは、会社全体の生産性を上げるという意味で重要です。その標準を更に改善していくために、「やっぱりこっちの方がいい」となった時には新しい標準に変えていくということができると、強い組織になりますよね。
@yuki.ito：
そういうことができるようなチームの構成にしていきたいです。
@Yoshiki Shibata：
今日itoさんと話していても、個人的にはカウシェでかなりのチャレンジができると感じています。
@yuki.ito：
冒頭で、10数社のカジュアル面談をされたとお伺いしましたが、最終的に技術的な部分でカウシェに決めた理由はありますか？
@Yoshiki Shibata：
私自身がまだあまり触れていない技術にチャレンジできることに、面白さを感じました。
具体的にどの技術スタックに興味があるというよりは、常に新しい技術に触れ、学びながら仕事ができることが、自分にとって良い環境だと思っています。
@yuki.ito：
なるほど。カウシェには「Try First」という文化があり、新しい技術をすぐに取り入れてみることも行っています。もちろん何でもかんでも新しいものを試せば良いわけではないですが、いいものであれば、組織のアーキテクチャも考えて、それを会社で標準展開できるようにしていこうと思っています。
@yuki.ito：
Shibataさんはどんな人と一緒に働きたいですか？
@Yoshiki Shibata：
そうですね、自分自身が成長しながら、チームとして開発することを求めている人たちと働いていきたいです。
@yuki.ito：
まさに、自分も同じことを思っています。
知らないことに触れることを楽しみながら、チームとしてのものづくりに還元する意識がある人と働きたいですね。
@Yoshiki Shibata：
これまでスタートアップのフェーズの会社では働いたことがなく、今回このタイミングでのカウシェへのジョインは、私にとっていい経験になるのではないかと思います。
カウシェでは、共に「世界一楽しいショッピング体験をつくる」メンバーを募集中
少しでも気になった方は、ぜひ下記よりエントリーいただければと思います。
イベント情報
10/26(水)19:00
対談イベント｜「プログラミング言語Go」の訳者と語る、Goとソフトウェアアーキテクチャ
Backend Engineerの柴田、Architectの伊藤が登壇し、「Goとソフトウェアアーキテクチャ」のテーマで、なぜ ”Go” なのか、またGoの歴史や、魅力についてお話しいたします。ぜひご参加ください。