バトンタッチ
1on1 風の対談形式で、執行役員VPoEである柴田(hsbt)から、2022年9月1日付けで技術責任者に就任した高橋(kenchan)へバトンタッチというインタビューをお伝えします。
これまでと現状
hsbt: 自分はあんちぽさんの分身というのを意識して組織運営をしていました。従来のあんちぽさんの方針をなぞる形の運営ですね。具体的な例としては、あんちぽさんは技術選定などを行うときにトップダウンで決定ということはやらずに、選択肢を例示した上でエンジニアに決定してもらう、ということをやっていたので自分もできるだけそういう状況を作ろうと心がけていました。
この戦略を進めていく上で重要になるのはエンジニア個人が技術選定をできるようになる、というのがポイントになります。そのためには「決める」ための判断軸や基準を持っている必要があるのでことあるごとにスローガンとして周知していました。
kenchan: なるほど。確かにこれを使えと言われたことはなかったですね。いくつかオススメの選択肢を提示してもらうことはありましたが、それくらいだったと思います。
それぞれの人が基準を持って技術選定ができるようになったというのは良い点である一方で、技術スタックが統一されていないことによるデメリットもありますよね。たとえば、社内での人の流動性を確保しにくいなど。特にEC事業部では課題に感じることが多く、ここ数年解決にむけてみんなと取り組んでいるところです。
hsbt: そうですね。多様性があることはいいことなんだけど、多様性を持った上でプロダクト開発を持続させるためには、さらに仕掛けが必要と感じています。昨今、組織のレジリエンスというものが注目されていますが、技術選定についてもレジリエンスが必要と思います。
多様性を求めた結果、ただ技術スタックだけが増えて複雑になったり、逆に何か一つの技術スタックにだけ投資した結果、その一つだけが失敗すると復旧不可能になる。そうならないように、複数の選択肢を確保しつつプロダクト開発を、組織として継続させていくことが一定規模以上の組織にとってポイントになると思います。
という課題感を共有した上でバトンタッチするわけですがどうやっていきますか?
新・技術責任者の目指す像
kenchan: まだはっきりとした方向性は見つけられていないので具体的な話ができないのですが、今考えていることを話します。
数ヶ月前、実際にバトンをもらってから社内を見回してみると、今まで見えてなかったところがまだまだ沢山あることがわかりました。まずは、そういった見えてなかったところや、柴田さんに任せていたところを見つけて学んでいくことが第一でしょうか。今回、久しぶりに福岡オフィスに来て、ホスティング事業部の部長やマネージャの皆さんともお話させていただいたのですが、あたらしい視点をたくさんいただけてとても勉強になりました。
今もまだその過程ではありますが、いろいろな人と話をする中で、自分が大切にしていることも再確認できてきたように思います。いちソフトウェアエンジニアとしても、いちエンジニアリングマネージャとしても、 「たのしさと成長を両立させる」これが自分が大切にしていることなのかなと考えています。
私自身は、Rubyに出会ってエンジニアリングの「たのしさ」を再発見したように思うので、これからも新しい技術を楽しみながら、それを組織やサービスの成長に繋げていきたいし、そういう組織でありたいと思っています。「たのしさ」をこういう文脈で使うのはRubyコミュニティや二人の前職である永和システムマネジメントの影響かもしれませんね。
hsbt: そうですね、永和システムマネジメントの DNA でしょうか。
kenchan: 当時の先輩方って、Rubyが仕事になるかどうかわからないような状況から、それを仕事にするためにいろいろなことに取り組んでいて、たのしさと仕事を両立させようとしていたんだな、と。
そこから考えると、いまみんなが「たのしい」と思っていることを知るのが最初なのかもしれないなと思います。
hsbt: そこは同じことを考えたりします。最近の人って言うと範囲が広いですが、私よりも若い世代の人たちは技術の何処を楽しみとして取り組んでいるのかは興味があります。
kenchan: その辺はちょっと気になりますね。私たちが持っている価値観が絶対ということはないですし。ソフトウェアの開発手法的な文脈だと、型の恩恵を受けたいとか、大きな組織で開発をしたいのか、なども気になります。
ペパボのフェーズが変わってきたというのもあると思います。エンジニアの数もそうですけど、全体の人数も我々が入社した時からも倍近く増えていて、１つのサービスあたりに関わる人数も倍になってると思います。
hsbt: そうなると同じやり方では難しいでしょうね。うまくいってないところを発見して、観察して調整していく、ということをよりやっていく必要があると思います。あんちぽさんはその辺を先回りしてメッセージを出している気がします。
技術力の三要素
hsbt: 話を変えると、ペパボには技術力に作り上げる力、先を見通す力、影響を広げる力の三要素があって、最近だと「Googleのソフトウェアエンジニアリング」と似たような話ですけど、僕はただ作るだけじゃなくて、時間軸を考慮したソフトウェア開発とか、エンジニアリングの能力をより重視してきました。
近年、ペパボでは新規のサービス立ち上げはなかなか難しくなってきていると思います。これはペパボに限った話ではなく、業界の成熟化に伴ってサービスはとにかく作って出すというフェーズから作ったものを成長させるということに主眼が置かれている感じでしょうか。
そうなると機能を拡張するとか減らす、または不具合を直すみたいなものは、エンジニアリングの中の大多数を占めるようになってきていて、ペパボの「作り上げる力」という部分をどういう時間軸で考えるのか、というのが悩ましかったですね。
実際には、新しいものを作るだけではなくて、ちょっとした修正であるとか、常にあるコードベースに手を入れることを評価軸の「作り上げる力」に加味してきたのですが、そこから始まるエンジニアリングの強化については世の中には知見が広まってない気がします。
kenchan: この前 Kaigi on Rails というカンファレンスがあって、同僚と一緒に見ていたところ「自分達がやっていることと似たようなことをやってるね」という話になりました。そういう気づきが得られるのはすごくいいなと思って、社内でも「歴史のあるサービスを愚直に改善しているだけなので発表することはない」ということを聞いたりしますけど、カンファレンスで発表を聞くとうまく言語化できてないだけだったという気持ちになります。
hsbt: できていることをできているじゃないか、というのは外にどんどん発信していくとして、できてないな、ということをちゃんと認知して改善していくことを研修などで力を養っていく必要はありそうですね。
アーキテクチャの話は本や動画だけだとおそらくわからないと思うんですよね。ソフトウェアは目に見えないので、自分でコードを書いて、触って、動かすことで輪郭を自分の中で作っていくことで改めて見えるようになると思います。このような活動を促しながら、時間の経過に耐えるソフトウェアを作って、可用性を高めつつ、ユーザーに使ってもらう、そういう目的を同時に達成するというのがエンジニアリングの醍醐味なのだと思います。
kenchan: 多様性を高める、可用性を高めるという話だと、なんらかの指標を計測した上で進めるのがいいと思いますが、アーキテクチャの設計や技術的な意思決定はそれが難しいと感じています。@snoozer05さんが翻訳した書籍「進化的アーキテクチャ」等には「適応度関数」という話が出てきますが、実際に何を、どうやって計測するのかという点は自明ではありません。
なんとかして良いアーキテクチャになっている状態を定義してそこに向かっていくしかないとは思いますが、良くなっているという実感を感じるのには長いタイムスパンで見ないとわからないなど悩ましいです。
それこそマイクロサービスアーキテクチャのような形で分割していくというのは方針としてはいいけど、不可逆なことが多く、何が良くなったのだっけ？とか、組織の形との整合性は？などを判断するのはすごく難しいなと思います。
なので今のところは、サービスを細かくしていくという方針自体は進める一方で、組織の形も合わせたりしていくというのは、EC事業部のスコープだとあまり踏み切れてない部分だと思います。
プロダクトの領域の広げ方
hsbt: マイクロサービスの話にも近いと思いますけど、EC 事業部のカラーミーショップの話を例にすると、SaaS の Virtical/Horizontal で分割した時に、カラーミーショップはどのタイル(マス目)をカバーしているのかというのを理解することがスタートだと思います。その上でサービスを切り出した上で、縦なのか、横なのかどちらに広げていくのか、広げる方針もプロダクトを作るのか分割するのか、そして何をKGI にするのかというのがポイントと思います。
昨今では、単独プロダクトではマーケット規模の限界にすぐにぶつかるので縦も横もやるために、マイクロサービスなりプラットフォームなりを目指すしかなくて、そのためにはプロダクトとそのアーキテクチャが重要になっていくと思います。ただこの辺はドメインの境界を綺麗に切れればいいんですが、現実世界はそんなに単純じゃないので難しさがあるんだと思います。
kenchan: まさにEC事業部だとそこが難しいなと感じます。会員の基盤などは割と分かりやすく、切り離せるポイントではあるものの、どこをどう切っても注文という概念が出てきてしまうと感じていて、個々の細かいサービスを作ったところで楽になっているのか、がまだ不確実な状態です。
hsbt: ここまでは縦の話について考えましたが水平に広げていく方も考えていかないといけないとも思います。例えば minne や SUZURI でも在庫管理とかショップページに相当する LP などがあって、どのサービスも似たようなものを作ってるんですよね。それらをマイクロサービス、または API 結合でやるのか、一切やらずに独立したプロダクトでやるのか、などの課題が出てきますね。
kenchan: そうなんですよね。ペパポとしては EC をしっかりやっていこうという流れがある中で、カラーミーショップ、minne、SUZURI という3事業があって、水平的なところの繋がりがあまりないというのが課題だと感じています。
VPoEのふりかえり
kenchan: 少し話題を変えて、VPoEとして一番うまくいったなって思うことは何がありますか？
hsbt: マルチクラウド環境への移行はなどはうまくいったと思いますね。AWS, GCP に限らず OpenStack を使ったプライベートクラウドなどを跨いだプロダクトの構築はコストメリットを出しつつ、クラウドの恩恵を受けることに成功したと思います。
kenchan: 確かに EC 事業部もそれら無しでは運営できない状態ではあると思います。
hsbt: あとは技術イベントに出ていくようなことも当たり前になったと思います。特にテックブログが活用されている気がします。よくテックブログの運営が難しいという話題は聞きますが、執筆する人とレビューする人とで勝手にやっているのにうまくいってると思います。
改めて言語化するのは難しいですが、アウトプットすることが「わたしたちが大切にしている3つのこと」に入っていることから誰もが積極的なのかもしれません。テックブログもですが、各自がアウトプットしているものが会社の成果であり、個人の評価につながっているということはいいことだと思います。
僕は割と質より量のタイプで、「こんなことを企業のテックブログで書いてるのか」という声も聞きますが、嘘じゃないならいいと思ってます。誰もがベテランでもないし、新人でもないのであらゆる層に向けてどんどん技術情報を増やした方がいいと思いますね。
例えばアーキテクチャの話についても、現状の自分の理解というのを前置きにした上で、既存のサービスについても発信していくと課題解決のきっかけになるのかもしれません。この辺はオライリーの本の翻訳待ちだと、数年遅れになってしまうので、現状の課題、課題の理解、課題に対するアプローチ、その結果、というようなテックブログはどんどん発信すると良いと思います。
先ほどはテックブログの話をしましたけど、ペパボのエンジニアには元々発信する文化があるので、中だけではなく外に向けて発信していくとか、より高いアウトプットを促していくとか、そういう活動をしていくのが、結果として良い方向に行くのかなと思います。
技術責任者のやっていき
kenchan: その辺はもったいないなって思いましたね。福岡に来ていろんな人と話してると、各自がとても面白いことをやっているとわかったんですよね。苦労して上手くやれたことや、結果としてうまくいかなかったことなど、それらをチームや事業部を超えてうまく回せるような仕組みを考えて運用するところが自分の仕事になってくるのかなと思いました。
今は、月一でエンジニア全員で集まるミーティングで技術トピックとして紹介してもらっていますが、その辺をアップデートすることでうまく解決できるのかなと思います。
柴田さんとあんちぽさんが作ってきたペパボの文化や取り組みを、より良い形にしていくことにチャレンジしていきたいです。
