【カミナシCTO原トリ】優れたプロダクトは“Howのプロ集団”から生まれる

【PR】 2022.09.09 働き方

カミナシは社名の通り、ペーパーレスを始めとする現場DXを実現するためのプラットフォームサービス『カミナシ』を提供するスタートアップだ。

最近では「カミナシ2030」として「ノンデスクワーカーが『挑戦し、報われる世界』の創造」をビジョンとして掲げている。

そのカミナシに、2022年の4月からジョインし、7月1日付でCTOに就任したのが、Amazon Web Services（AWS）をはじめ複数の企業で開発運用から顧客支援を行ってきた原トリ(@toricls)さんだ。

「企業の成長を長期的に支える優れたプロダクトづくりに挑戦したい」と話す原トリさん。

彼が考える「SaaS領域における優れたプロダクト」とは何か。また、どのようなエンジニアなら優れたプロダクトを生み出せるのか。

CTOの立場から今後カミナシで起こしていきたい変革とあわせて聞いた。

会社の成長はビジネスと技術の両輪。エンジニア全員がオーナーシップを持つ組織へ

――カミナシにジョインしてから約5カ月がたちますが、会社の印象は？

良い意味でも悪い意味でもビジネスサイドが強い会社だということです。ただ、これはカミナシの技術力が低いということではありません。

ソフトウエアで起業するスタートアップの場合、ビジネスサイドとエンジニアリングサイドのバランスが取れていることが理想的です。

今は技術力を重視する企業も多いけれど、技術に寄りすぎると、ビジネスとしてのグロースが達成できませんから。

そういう意味でカミナシは創業者の諸岡の力強いリーダーシップや彼が築いたセールスチームに支えられてここまで成長できた会社だと思います。

――ただ、今後は技術面もさらに強化していく必要があると？

そうですね。これまでは、エンジニアリングの視点で経営の方向性を定める人が不足していたので、技術的な課題が現場に丸投げの状態になってしまうこともあったのは事実です。

でも、現場のエンジニアたちはどうしても目の前の開発に追われますから、中長期的な課題に取り組むのは後回しになってしまう。

そこで僕が今進めようとしているのが、経営の立場から組織に中長期的な技術戦略を持ち込むことです。現状はまだ、より良いエンジニアリング環境を実現するために、技術的負債の返済を進めているところ。

今後さらにSaaS領域で優れたプロダクトづくりをしていくため、組織の成長基盤を着実に整えたいと考えています。

――その先に、どのような開発チームをつくりたいと考えていますか？

エンジニア全員がプロダクトに対して「オーナーシップ」を持つようなチームです。

僕らが行っているのはソフトウエアエンジニアリングであって、単にコードを書いているわけではありません。

作ったソフトは、長期にわたってお客さまにサービスとして提供し続けていくわけで、そのライフサイクル全てに責任が発生します。

それなのに、よく考えずいきなりコードを書き出すと、何か一つでも「想定外」が起きたときに例えばパフォーマンスがガクッと落ちるようなシステムになってしまう。

そのような事態を防ぐためには、エンジニア一人一人が手を動かす前に、「自分たちが作っているシステムが、将来どのような使われ方をするのか」をイメージできていることが重要です。

プロダクトで新たな価値を提供したいなら、フロント、バック、インフラなど区分に意味はない

――SaaS領域で優れたプロダクトづくりに挑戦したいとのこと。そもそも原さんは、優れたプロダクトとはどういうものだとお考えでしょうか？

優れたプロダクトの定義は、ビジネスモデルによっても異なります。例えば受託開発であれば、仕様や要件を過不足なく満たしたものが良いプロダクトです。

一方、私たちが提供するSaaSにおける優れたプロダクトとは、「そのサービスが提供する継続的な価値＝ビジネスモデルの実現にアラインしたソフトウエアであること」だと考えています。

繰り返しになりますが、SaaSというビジネスモデルにおいてはプロダクトを作って終わり、ではないんですね。特にBtoBがメインである場合には、ユーザーの企業がビジネスを続ける限り、5年後も10年後も支えていかなければなりません。

そして、その間に自分たちも成長していくというのがスタートアップの使命ですから、既存のシステムは機能を追加したり、新しいプロダクトを足したりできるようにしておく必要があります。その際にも、安定性や信頼性を損ねるようなことがあってはならない。

つまり、拡張性と安定性を兼ね備えたソフトウエアの構造になっていることが、SaaSにおける優れたプロダクトの条件だと考えています。

――優れたプロダクト作りを実現するためには、どのような組織づくりをしていく必要があると思いますか？

現在、カミナシではサービス提供に責務を持つ組織をプロダクト、エンジニアリング、デザインといったように、その機能で分けています。

ただ、こうした組織図的な分割とは関係なく、実際の開発においてはサービスチームを組んで協力しながら進める体制をとっています。

例えば、前職のAWSは大きな組織で部署としてはたくさんの人数を抱えていますが、やはりステークホルダーとなるチームのサイズは5人から7人程度と小さく保って、素早く自律的に意思決定できる仕組みを採用していました。

カミナシも直近はエンジニアの数が増えてきているので、僕個人としては近い将来チームを分割したいと考えています。

ただし、課題が二つあって、一つはピープルマネジメントができるエンジニアリングマネジャーが足りていないこと。これは採用などで解決したいと思っています。

もう一つは、チームの分割に合わせて各チームが管轄するシステムも一緒に分割されなければならないこと。ただ、こちらはまだ社内のコンセンサスが取れていない僕個人の思い、という段階ではありますが。

――「チームとシステムの分割を一緒にする」とは？

大きくなったエンジニア組織を分割しようとする時にさまざまな会社でよく採られるのが、フロントエンド、バックエンド、インフラストラクチャーなどのように職能別にチームを区切る体制です。

しかし、僕はこの方法を積極的にとりたくはありません。なぜかというと、一般にWebサービスを作ろうとすると一つのシステムに複数の職能のメンバーが関わることになります。

ここに職能別のチーム体制を持ち込むと、一つのシステムについての責任を複数のチームで共有することにつながり、結果として生産性やデリバリ速度に悪影響を与える依存関係や、そこから生まれる責任の押し付け合いがチーム間に発生しやすいと考えているからです。

例えば、Aチームがデータベースに手を入れたら、Bチームの機能にエラーが増えた。すると何が起こるでしょうか？

予想されるのは、再発防止のためにデータベースを変更する際は両チームのレビューを必須にしましょう、相互にプルリクエストをするようにしましょう……といった事態です。

「あれ？開発のスピードを上げるためにチームを分けたはずが、余計な手間が増えてるよね？」なんてことになりかねません。

そもそも、プロダクトの価値提供を考えたときにフロント、バック、インフラという区分は意味がないんです。プロダクトで新たな価値を提供しようとするなら、その全てに手を入れる必要がある。

その意味でも、単一のチームで顧客への価値提供が可能な体制をとるということが理想的な組織形態だと考えています。

システムの構造はそれを作る組織のコミュニケーション構造を反映したものになる、というのが「コンウェイの法則」ですよね。

それが転じて、目指すべきシステム構成に従って組織構造を作るべきだという「逆コンウェイの法則」がありますが、そのためにはまず現状のシステムが目指すべき形を発見しなければならないというのが、今感じているジレンマです。

好奇心のままに技術を楽しみ、Howのプロへ

――優れたプロダクトを生み出せるエンジニアになるために必要なことは何だと思われますか？

プロダクトを作る際には、Why（なぜ作るのか）、What（何を作るのか）、How（どうやって実現するのか）という三つの視点から考えなければなりません。

もちろんどれも重要なのですが、僕がCTOとしてカミナシのエンジニアリングメンバーに話しているのは、まずHowの部分についてプロフェッショナルになろうということです。もちろんHowだけを突き詰めればいいというわけではなく、WhyやWhatの領域に染み出す活躍が当然に必要ですが、まずは技術のプロフェッショナルとして高いレベルでHowを実行できることこそが、エンジニアリングという役割に最も期待されることだからです。

また、これまでお伝えしてきたように、システムのライフサイクル全体を見るという意識が大切です。

実際、フロントエンド、バックエンドのようにエンジニアの役割が分かれた組織で働いている人の中には、システム全体に触れないことにフラストレーションを持っている人が一定数いると感じます。

プロダクトの価値を向上させようと思ったら、部分的に変えるだけでは実現できないことがほとんどですから。

特定の技術を突き詰めたい人から見たら、全部の分野を見なきゃいけないのはイヤだ、と思われるかもしれません。ただ、進化の速いソフトウエアの世界で一つの技術領域だけでやろうとしていると、いずれ賞味期限切れになりかねません。

もちろん、それを超えて突き抜けたスペシャリストというのは存在します。でも、そうした人ほどジェネラリストとしても優れているというのが、私の実感です。

例えば、AWSにはJava言語の生みの親であるジェームズ・ゴズリンが在籍していましたが、私がいた当時、彼はIoTの領域で活躍していました。

――複数の得意分野を持つことが、ますます求められる時代になるわけですね。

それと、エンジニアとしては自分なりの楽しさを見つけて、どんどん伸ばしていくとよいと思います。