メンバー増加でオーバーヘッドが大きくなったためチームを分割
西村賢氏（以下、西村）：（スライドを示して）それで、右側にいくと、次はどういうかたちの……。
原トリ氏（以下、原）：この頃、たぶん、正社員がちょうど僕が入った時の倍ぐらいですかね。
西村：けっこうな成長ですよね。
原：そうですね。だから僕はこの期間ずっと採用ばかりしていたんですよ。
それまでは1チームでやっていたんですけど、10人超えたぐらいでオーバーヘッドが大きいと。コミュニケーションパスもあるし。
あとは、別の課題として人数がいるので、プロダクトマネージャーが複線化していろいろなことをやりたがるんですよね。大きい機能A、Bみたいなものを持ってきて、それを全部同時に流そうとするんですけど。
スクラムって、お互いが何をやっているか見えることがすごく大事なので、複線化させると、チーム内で別チームみたいになっちゃうから、一方で不確実性にやられた結果、予想外のことが起きた時に誰も助けられないみたいな。
なので、「大きなものを同時に複数並べるのはやめないとね」という会話もこのへんから始めたんですけど、オーバーヘッドが大きいとなったので、3週間ぐらい僕がたくさんDocを書いて。
西村：次に進めたのはPartially Worked、チーム分割ですね。
原：そうですね。チーム分割をメンバーが考え始めたので、なぜチームを割るか、チームを割ることにどんな効果が期待されるのか、チームを割ることで生まれるデメリットの部分などについてDocを何枚も書いて情報を共有して、彼らがいい意思決定をできるように支援はしました。
西村：これはフラットな分け方なんですか？ 役割ではなくて。
原：そうですね。基本は役割をやらないほうがいいという話は、Docの中でも言及しているんですが、その時のチームの状態を考えると、こう割らざるを得なかったみたいな。本当は、この割り方はあまり良くないなと思って後から片方を負債返済だけするチームに直したんです。
西村：そうはしたくなかったけど、このタイミングではそれがいいという判断をしたんですね。
原：そうですね。組織のレベル的に。機能開発も不具合修正も負債返済も、きちんと1つのバックログの中で管理できている状態が、僕はあるべきかたちだと思っているし、それによって一番いいものをお客さんに届けられると思っています。
なんですが、当時のカミナシでは無理かなという判断になった。負債返済とかまで、プロダクトマネージャーやステークホルダーがしっかり踏み込んでロードマップを作るみたいなことは、今はまだできないだろうということで、こういう分け方にしました。
何回も言いましたね。「この割り方は本当に嫌なんですけど、これで割りますね」と。
西村：（笑）。時限措置だと。
原：そうです。半年もせずに戻しますという話をしました。重要な機能の開発がすごくリスキーな状態になっていたのと、50パーと言ったけど結局負債返済がなんにも進んでいない状態だったので、バツっと切って。
西村：そういう意味では、インターナルの業務アプリというか、ダッシュボードというか、2人がうまくいったので、それのちょっと拡大みたいなニュアンスもあるんですかね。
原：そうですね。組織レベルが高ければ複数の重要なことを1チームの中で優先順位をつけながらやれるのかもしれないんですけど、成熟していくまでは、やはり役割でガチッと、僕は本来切りたくないと思っている場所でも切らないと機能しないみたいなのがあるんだなというのは……うん。
西村：チームが急速に大きくなったのもあるんですかね、やはりね。
原：それもあります。
西村：そこもスタートアップ的ですよね。
原：出てくる負債返済をどう進めるかというところでの学びなんですけど、やはりゴールを明示してしっかりDoc書いて、オーナーシップ持って進めていく人がいないと、大きな負債返済は片づかんなと学びました。
ゴールを明示して、どう解くか、なぜそう解かなきゃいけないかというところまで、僕がDocを書いてチームに渡して、その負債返済チームにやってもらったんですけど。
西村：そのタスクの大きさみたいな話。ボールの大きさみたいな。小さなリファクタリングとか、「ちょっとこのへんこうしたほうがいいね」ぐらいの話じゃなくて、アーキテクチャレベルで手を入れるみたいな。
原：そうですね。バッチ処理のアーキテクチャをガリッと変えた話をメンバーがブログに書いてくれているんですけど。
西村：そうなんですね。そこのイニシアチブを持って、「ここがこう問題で」というのを、きちんと形として見せて、「リソースこれぐらい、時間これぐらい」みたいなのを見積もる人がいなかったということなんですかね？
原：かな。あとは、その時間をみんなが取れていなかった。それから、ここで僕がやったのは、事業計画どおりに売上が伸びていった時の、3年後のお客さんの数とか、そうなった時のバッチ処理の処理量から、どういうシステムアーキテクチャに変えないと処理が終わらないですよねみたいな話をすること（笑）。
あとは、もともとそんなにイケてなかった作りではあった部分もあったので、そこを妥当な作り、メンテナンスしやすいシステムデザインに変えるとか。
バッチ処理をカミナシは、ずっとスケールアップでこなしてきていたんですね。「あっ、処理が終わっていない」となったら、マシンに割り当てるCPUとメモリをデカくするという、札束で殴る方式でずっとやってきた。
西村：スケールアウトではなかった。本当はね、横にやったほうが。
原：そうです。2000年代のERPシステムの仕方なんですけど、札束で叩いてマシンスペックを上げることでスループットを増やして、バッチ処理が朝までに終わるようにするというやり方だったので。
我々はSaaSなのでもちろんスケールアップも重要なんですが、スケールアウトで処理量の増減に対応できるようにしなきゃいけないんですよという学び要素も入れたくて、この負債を片づけましょうということで、ゴールを明示して預けたら進みました。
チームを分けたというのと、Docを書いたという2つですね。
西村：なるほど、わかりました。
PMとエンジニアリングとPDで走るチームに負債返済チームを変えた
西村：次の段階でいうと、（スライドを示して）今度は左下ですかね。
原：先ほど、負債返済チームを作ったという話があったじゃないですか。
西村：えぇ。
原：あれをやっている期間は、素材が合っていない服を着ていて、すげぇ肌痒いみたいな感じで。
西村：あぁ、なるほど。itchy（笑）。
原：itchyな感じ。早く変えたいと思っていたので、4月にはPMとエンジニアリングとPDで走るチームに負債返済チームを変えますよというのは、言っていたんですよね。
それを4月に変えたんですけど、前回50パーセントルールが機能しなかったじゃないですか。
西村：そうですね。
原：ここでなにも打ち手を打たないと、たぶんまた2022年の7、8、9月みたいになるなと思ったので、今回は、ちょっとやり方を変えました。今、1週間スプリントで12月に変えた時からやっているんですけど。
通常のPM、PDと一緒に動くスプリントを1週間×3回やった後に、エンジニアリングだけ、もっと言うと僕も入って内部品質改善スプリントなる名前を1週間やる。
そこの1週間の中は、コンテキストスイッチを起きないようにすることで、それなりの大きさのボールをエンジニアリングが動かせるようになるのでは、という期待値込みで。
時間ではなく、もうスプリントという枠組みの1個を必ず内部品質改善に充てますよというルール。
西村：先ほどおっしゃっていたみたいに、比率で50パーセントと言っても、実際そもそも自分たちの時間がどこにどれだけというのが把握できていない状態。だったら、もうここは決めちゃうみたいな。
原：そうですね。
西村：この週は、改善だけしなさいと。
原：この週はもう、ガツッと内部品質改善。
西村：そういう意味では、今度はチームじゃなくてスロットを1個丸々アロケートしたみたいな話ですかね。
原：はい、そうです。
西村：これはうまくいったんですか？
原：これは一定うまくいきました。うまくいった理由として、やはり1週間あるので、しっかり考える時間をある程度取れるというのはもちろんあります。
あとは、サポートから流れてくるチケットをとにかく減らす。サポートとCS側が解決できる範囲をどんどん広げていくのはずっとやってきていたので、この頃には内部管理画面がけっこうフィーチャーリッチになっていて。
西村：できることが増えていった。
原：例えば、「誰がこれを編集したか知りたいんです」みたいな問い合わせが来るんですよ。それも監査機能として出すと、「監査」という言葉を使った瞬間に、エンタープライズがビビッと反応するんですよね。
西村：仕様がめっちゃ厳しくなるんですね。
原：まだ公開はしていないんですけど、「これは、ISOなんとかのなんとかで使える監査機能ですか？」みたいなのをめっちゃ聞かれるので少なくとも内部の人は、誰がいつどういう変更をしたかを見られるようにしたりなど、だいぶフィーチャーリッチになったことで、サポートチケット自体が。
西村：早くなった、処理が。
原：そう。サポート、CSで解決できるようになったというのも、1つ機能した理由です。あとはあれですね、PMも技術的な会話をしなくていい。
これも別にそんなに好きなやり方ではないんですけど、やはりコンテキストスイッチを1個のスプリントの範囲内でなくすことができたので、小さなボールではあるけど、ちょっと動いた感じですね。
西村：でも、ちょっと打ち合わせでおっしゃっていたみたいに、ボールって大きいほどモヤモヤっとして見えないから、それを誰かが一生懸命考えて、たぶんボールはこういう形だろうと、みんなの前にゴロンと出すみたいなこともけっこうできるようになったという。
原：それは、ここではできなかったんですよ。
西村：ここでもまだできないんですね。
原：（スライドの）一番下に書いているんですが、小さなリファクタリングや修正ばかりやっているんですよ。
プランニングをしていないんですね。通常スプリントは、しっかりスクラムをやっているのでプランニングもしているし、バックログリファインメントもやっている。
西村：ふりかえりですよね。
原：そうです、ふりかえりもやっているんですけど、内部品質改善はなんとなく始めたので、枠組みだけ作って。
西村：なるほど。
原：内部品質改善スプリントの週になったら、急にチケットの一覧を見て、「これ、なんかいけそうだな」みたいな感じで。
西村：この小さいやつ（笑）。
原：ちまちま直しているんですよ。
西村：まぁ、気持ちいいですよね。スッキリしたみたいな。大物に向かない。
大きなボールを動かすために必要なこと
原：いったんは僕は黙っていたんですよ。いきなり入っていくと、学びがないと思うので黙っていたら、なんか会話を始めたんですよ。「こんなアドホックに小さいボールばっかり片づけるのでいいんだろうか？」みたいな。
「どうやってデカいボールを動かそうか？」という話を始めて、ミーティングしていました。その大きいボールって、抽象度が高いので、なんかまずいよなと思っていても、もっと具体的な内容をDocに落とさないとほかの人が理解できない。1週間でやろうとすると複数人で分担してガガッと進めないともちろん終わらない。
なので、特に等級の高いエンジニアは、ほかの人が、その課題を解いたらどんな価値が得られるのかを認識できるように血を吐きながらDocに落とさなきゃ駄目なんですという話をしたら、何人かがDocを書き始めて、この間1個デカいやつが……デカいと言っても、そんなデカくないかな。
カミナシは、AWSを使っていて、「Amazon ECS」というコンテナのオーケストレーションサービスを使っているんですけど、そこにECSクラスターというコンテナを走らせる集まりみたいなものとかいろいろあって、それを式年遷宮っていうんですかね、伊勢神宮の。
西村：式年遷宮（笑）。エンジニアの方はご存じですが、せっかくなので、式年遷宮。
原：伊勢神宮の式年遷宮がなぜ行われているかという背景までは僕は語れないんですけど。
西村：まぁ、ざっくりで（笑）。
原：建物って、もちろん建って、時間が経っていくとどんどんきしんで傷んでいくじゃないですか。
西村：日本の宮大工の伝統ですよね。
原：そうです。それを部分部分で直していくと、たぶん細部を見落とすんですよ。なので、パーツを入れ替えて別の場所にドンと新しく1個作り直す。そうすると、まるで今作ったかのようにきれいな構成で作り直せるみたいなやつだと思うんですけど。
西村：あと、スキルを上の世代から下の世代にやる時に。ゼロから作るというのが若い人にとっては伝承の大事な経験みたいなね。
原：そうですね、伝承とか。
アーキテクチャ、建造物もそうなんですけど全体の概要が見えなくなっていくんですよね。それを式年遷宮することで、中身を一回ひもといて作り直していくので、伝承もできるし。
西村：きれいにもなる。
原：そう、良くなかった場所。伊勢神宮だとたぶんあまりやらないと思うんですけど。でもたぶん、新たな技術を導入するとかはやっていると思うんですよ、式年遷宮する時に。
西村：確かに、確かに。
原：ここの組み方をちょっと変えるともっと耐久性高くなるとか、いわゆる業界で得た学びが式年遷宮の時にきっと反映されていると勝手に思っていて。
その、ECSクラスターというけっこうデカい塊を式年遷宮するみたいなのが、このDocを書き始めた次の内部品質改善スプリントできちんと動いたので、僕が入っていくんじゃなくて、しばらく様子を見ていようかなという、今、フェーズで。
2月ぐらいに、けっこう活きのいいPMがカミナシに入ってきて、その人が、「内部品質改善スプリントみたいなちまちましたことはやらずに、バッグログに全部載せたい」と。負債返済も機能開発も、全部1個のロードマップの中できちんと管理したいと。
西村：もともと理想としていたかたち。
原：そうです。僕はもともとやりたいと（思っていたかたち）。でも、技術のバックグラウンドがないので、やはりコミュニケーションのオーバーヘッドが大きいんですよね。なぜそれが優先順位高いのかという会話をする時に、エンジニアリングについては、エンジニアの中だけだったら10で説明すればいいことが、PMに説明しようとすると15になるみたいな。
そういうオーバーヘッドがまだあるなと思っていたので、「いや、うまくいきますかね？」と僕は言っていたんですが、その活きのいいPMは、「いや、いけるんでチャレンジさせてください」と言うので、「じゃあ、やってみなはれ」という話を今、ちょうど始めたぐらい。
うまくいけば、たぶん内部品質改善スプリントは廃止できて、妥当な優先順位で機能開発や負債返済の話ができるチームになっていくんですが、僕はまだ、そんなに期待していなくて、たぶんまだねじれるよなとは思っていて。
「ノンデスクワーカーの世界にがっつり入っていけること」がカミナシのPMに求められること
西村：カミナシさんは、PMとかプロダクトマネージャーも、現場のリクワイアメントみたいな、より現場に行かないとわからないようなものを吸い上げてくるみたいな。
原：そうですね。
西村：というところで、現場の人たちにとっては当たり前の環境すぎて言ってくれないみたいな距離がデカくて、それはやはり本質的に難しいところではありますよね。
原：ありますね。僕、前職でクラウドベンダーの中にいたんですけど、クラウドベンダーは商材が技術で、お客さんもわりと技術屋さんなので、プロダクトマネージャーは、ほぼすべてソフトウェアエンジニアリングの出身なんですよね。ソフトウェアエンジニアリングをやっていた人がMBAを取ってPMになりましたみたいな。
西村：お客さんの気持ちもめっちゃわかる（笑）。
原：そうです。そういう人がやはり多くて。ソフトウェアを作るのであれば、プロダクトマネージャーが技術をわかっている、そこに経験があるのがめちゃめちゃいいんですよね。エンジニアとの会話のオーバーヘッドが減るので。
じゃあ、カミナシでそういう人を採ればいいかというと、今まさにおっしゃってくださったとおりで、僕らのお客さんってデスクワーカーじゃなくて、例えば、工場でかまぼこを切っていますという人とか、ふだん机じゃない場所で仕事をしている人たちが僕らのお客さんなので、そういうところに一次情報を取りにいくモチベーション、マインドセットがめちゃめちゃしっかりしているPMを採るのが、やはりすごく会社として重要です。
そうすると、優先順位の話で、技術力があるかどうかとか、技術を理解しているかどうかよりも、そういうノンデスクワーカーの世界にがっつり入っていけるかどうかをどうしても優先する必要が出てくる。
そうすると、エンジニアリングとの技術的な会話、オーバーヘッドが大きいみたいな。なので、本当はトレードオフにしたくないんですけど、今のカミナシだとなっている感じですかね。
でも活きのいいPMが、「いや、やれるし」と言っているから、「じゃあ、やったらいいんじゃないですか」と言って。
西村：（笑）。以前（お話しされていた）それこそPMのジョブディスクリプションをちょっと変えようかみたいな。
原：変えたいと思っています。
西村：まさにそういうところの問題意識で、例えば、先ほどのクラウドベンダーもそうですけど、テックテックしたところで、SaaS向けにツールを出しているところでA/Bテストをして、PLG（プロダクトレッドグロース）で、みたいなPMとはやはりちょっとやはり違う感じなんですよね。
原：違うと思いますね。プロダクト組織としてPLGができるプロダクトを作るマインドセットは超重要だと思うんですよ。「うちはBtoBだから、わかりやすさとかは別にいいんだよね」みたいな。
西村：それじゃ駄目ですね。
原：そう。「そのへんは全部CSがやってくれればいいんだよね」みたいな。「だから、ユーザー体験やわかりやすさは優先順位を落とそう」みたいな、さもいいトレードオフを選択したみたいな表情でそういうのを語るんですけど。
西村：（笑）。
原：PLGみたいなものを諦めるのは駄目で、やはりわかりやすいプロダクトとか、CSコストを下げるプロダクトは、超重要なんですが、そこを強く意識しているプロダクトマネージャーがフィットするかというと、たぶんそれ以外にもけっこう重要なことがカミナシでプロダクトを作る場合はあるかなという感じですかね。
西村：なるほど。
N=1を見にいくマインドセットが重要
西村：カミナシさんの事例で言っていいのか……ツール入れてみたけれど結局紙に戻ったみたいなチャーンの事例でいうと。
原：あります、あります。
西村：僕らは想像つかないけれど、もう紙と鉛筆がそこにあるほうがタブレットよりもぜんぜん早いみたいなね。
原：そうなんですよね。
西村：それは想像つかないですよね、やはり現場にいないと。
原：だからカミナシのプロダクトって、いわゆるカスタム帳票を自由に作れるんですね。
西村：紙のやつを。
原：そう。分岐やループが帳票で組めるんですよ。
西村：めっちゃいいじゃないですか。
原：例えば、冷蔵庫の温度を記録してくださいという入力項目に現場の人が温度を入力した時に、決まっている温度の範囲外だったら、即管理者に通知が行って機械のチェックをする、みたいなのとか。
あとは、なんかの機械の圧力チェックで、圧力が何ニュートン以内になっているというところが違ったら、その場で修正方法のマニュアルの画面が出て、「機械を調整してくれ」みたいなのが出るとか。
なので、インタラクティブ性があって、かつ、帳票の周りに承認フローとかスケジューリングとかビジネスプロセスを組める。そういう、帳票なんでもシステムみたいな感じです。
なので、現場で、ある機械のそばで仕事をしている人がそこを使って記録していくんですけど、先ほどの「紙のほうがいい」の話で言うと、戻ったお客さんもいるんですね。カミナシよりも紙のほうがいいと。もう現場は「紙がいい」と言っている。
「なんでですか」って現場を見にいったんですよ。そうしたら、機械にコルクボードで紙と鉛筆が一緒にぶら下げてあるんですね。現場の人は記録する時、右手伸ばして、作業をこっちでやりながらパッて書いて終わりなんですよ。
「カミナシ」という僕らのタブレットを現場の人は使うんですけど。タブレットを使う場合、まずはホームボタンを押して画面を起動して、カミナシのアプリを開いたと思ったら、「うわっ、認証のセッションが切れとる、再ログインや」みたいな。「パスワードわからん」と言って、管理室に行って再ログインして帰ってきたら、ライン業務とかをやっているので、ラインがすげぇ流れているみたいな。「業務、回らないんですけど」みたいなのがやはり業務の種類によっては起きる。
でも、その現場の人に「なんで使いにくいんですか？」とだけ聞いても、「いや、紙のほうが楽なんです」みたいなのしか基本は言ってくれないので、そういう時に「オラッ！」と見にいくPMが必要みたいな（笑）。何があかんかったのかを実際に見にいって、現場の人が語ってくれない情報をきちんとキャッチしてくる。だからこれが駄目なんだみたいな。
なので、N=1みたいなものをどこまで重視するかという話は、もちろん大事なんですが、「なんかこれはありそうだ」と思った時に、沖縄の端っこまで行って、N=1を見にいくみたいなマインドセットのPMがうちにはすごく重要だし、そういう人が活躍している会社ですね。
西村：やはりむちゃくちゃ価値あると思いますね。
原：そうですね。みんな楽しそうですけどね。
西村：楽しそうですよね。ただ、やはり先ほどおっしゃったように、1人の人間で見た時に、バリバリエンジニアリングに興味がある人と、沖縄に行く人はやはりちょっと別の感じがちょっとしますよね。なのでね、そこをつなぐ……。
原：そうですね。
西村：だからそこは、それこそスクラムの価値ですよね。みんなでやる。
原：はい。一次情報を取りにいくのが好きなエンジニアもいれば、ちょっとそこが弱いエンジニアもいる。技術に心が向いている人もいるんですけど、スクラムで、全員でそこのバランスをきちんと取れるメンバーをそろえたい感じですかね。
西村：なるほど。わかりました、ありがとうございます。原トリさんでした。今日はどうもありがとうございました。
原：ありがとうございました。
西村：みなさん、拍手をお願いいたします。
（会場拍手）
