KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

良いプロダクトづくりに必要なこと

はじめまして。AI在庫管理の開発チームでバックエンドエンジニアをしている沖です。社内ではファーストネームで「たくおさん」と呼んでもらうことが多いです。まだ(もう?)入社して4か月ちょっとなのですが、もりもり開発ができていて楽しいです。

この記事は カケハシ Part 1 Advent Calendar 2023 19日目の記事です。 カケハシ Part 2 Advent Calendar 2023 と合わせて楽しんでいただけたら嬉しいです。

アドベントカレンダーの話が挙がった際にとりあえずノープランでエントリーして、本番環境のDBマイグレーションでやらかした懺悔文でも書こうかなと直前まで思っていたのですが、他のメンバーのふり返り的なエントリーが年末のこの時期にとてもマッチしているなと思い、私も真似してみることにしました。

ということで、この記事では、今年の8月にカケハシに入社した私が、なぜカケハシを選んだのかやカケハシに対する入社前後の印象の違いなどをつらつらと書いていこうと思います。

カケハシに入社する前に考えていたこと

今回のカケハシへの転職は私にとっては3回目の転職でした。SIerでの旧き良き(?)ウォーターフォール開発や、自社サービスや受託案件におけるアジャイル開発(ウォーターフォールではないという意味のアジャイルとスクラムの両方)を経験し、ロールとしてもエンジニアとマネジメントとをどっちつかずな感じで経験してきました。

前職では、マネージャーというロールで医療システムの受託開発を行っていました。社会貢献性が非常に高く、技術的にもおもしろい取り組みができていたのでとても楽しかったのですが、一方で良いプロダクトづくりに集中できないと感じる場面も多くありました。たとえば、次のようなことです。

  • マネージャーというロールであったため、プロジェクトマネジメントやアカウントマネジメントの他、通常はPdMが担うであろうプロダクト仕様の決定、チームメンバーのピープルマネジメント等、マネジメントに関することはすべてこなさなければいけなかった。
  • 人月ビジネス的な側面があったため、経営層が優秀な人財の採用にあまり積極的ではなく、経験豊富なメンバーが限られていた。
  • 顧客の都合で契約と契約の間があき、チーム体制をうまく維持できなかった。

マネジメントの経験を積めたことは良かったのですが、上記のように良いプロダクトづくりに中々集中できないモヤモヤを感じ、転職を決意するに至りました。会社選びの軸としては、社会貢献性やエンジニアとしてスキルアップを目指せるかどうか(前職でも元々エンジニア志望だった)といった点も考慮しつつ、「良いプロダクトづくり」ができそうかという点を重視していました。

良いプロダクトづくりに必要なこと

今回の転職ではカケハシ以外にも興味を持った会社がいくつかあり、その中のいくつかからオファーもいただいたのですが、最終的にカケハシを選んだ一番の理由は、本気で「良いプロダクトづくり」に集中できると思ったからです。

そこで以降では、ひとりのエンジニアである私が、良いプロダクトづくりに必要だと感じたことについて、3つほど紹介できればと思います。

なお、そもそも「良いプロダクトとは何か」について掘り下げると発散してしまうかなと思ったので、ここでは「ユーザーに対して価値を届けることができるプロダクト」といったふんわりした定義としたいと思います。

その1: 組織の価値観

最初に必要だと感じたことは組織の価値観です。一般的な企業は営利企業なので、当然売上を意識しなければいけませんが、極度に売上を意識した結果、ユーザーに目を向けられていないプロダクトも一定数存在しているように思います。

実際、日本国内の主要サイトの6割でダークパターンが確認されたとする記事もあり、本当の意味でユーザーを大切にできている会社は少ないように思います。良いプロダクトづくりには、「自社の売上のため」といったベクトルが発生しないよう、組織としての、とくに経営層の価値観というのはとても重要だと思います。

この点でカケハシはどうかというと、カケハシの経営メンバーからは「悪いことをしてお金を稼ぐくらいなら、正しいことをして潰れてしまった方がいい」といった発言があるなど、医療業界を良くするために信念を貫こうという意気込みを感じられています。私は、Googleの "Don't be evil"(邪悪になるな)というモットーをはじめて聞いた時にとても素敵だなと感じたのですが、同じ価値観を持っていることをとても嬉しく感じています。

カケハシではこの価値観を「高潔」として、6つあるバリューの最初に掲げています。バリューを掲げていても浸透に苦戦している会社が多くある中、カケハシでは入社時のオンボーディングでバリューについてじっくり考える場があったり、業務の中でも「その行動はバリューに沿った行動なのだっけ」と自然発生的に問いかける場もあったりと、組織の価値観として大切にしていこうとする姿勢を感じています。

少し話しは逸れますが、入社前に「高潔」というバリューを聞いたときは少し異質な印象を持っていて、良くも悪くも真面目すぎるのではないかと感じていました。最終面接でYさんに「バリューにひとつ追加するとしたら何を追加しますか?」と質問し、少し考えた後に「自分を大切にする」という回答が返ってきた時も、素敵だなぁと感じるとともに、自己犠牲精神の強い人が多い文化なのかなとも思っていました。

ただ、実際に入社してみると、医療業界ということでお固い部分は一定ありつつもスタートアップらしい緩さも持っていて、個人的にはとても良い具合にマッチしました(人によって感じ方に差が出やすいところかなとは思いますが)。

その2: 適切な役割分担

2つ目は、入社前に感じていたことにも記載したことですが、適切な役割分担が必要だと感じています。マネージャーというひとつのロールの場合、見る範囲が広いために結局はすべてが中途半端になっていました。昨今、PdM、PjM、EM…とマネジメントに関するロールも細分化されていますが、これは適切に役割分担をして、ひとつひとりがやるべきことに集中できるようにするためだろうと思います。

それに対してカケハシでは、PdMやEM、スクラムマスター、デザイナーといったロールが、専任として各プロダクトにアサインされていると入社前に聞いていました。その中でもスクラムマスターを専任でアサインするというのは個人的には驚きで(スクラムマスターをエンジニアが兼任しているケースが多いと感じていたため)、しっかり役割分担をして良いプロダクトづくりに集中できる環境を用意しているのだなと感じていました。

また、面接でお話したPdMのKさんは「別にカケハシじゃなくてもいいのだが、日本の医療業界を良くしたいと心底思っている」と言っていて、なんちゃってPdM的な動きをしていた自分が恥ずかしくなるとともに、こういう人がPdMをやるべきなのだとも思いました。

実際に入社して感じたこととしては、適切にロールを分担しているところは入社前に聞いていた話と大方相違なく、自分自身はエンジニアリングに集中ができています。仕様に関しては、信念を持ったPdMがしっかりとユーザーヒアリングをしてビシッと決めてくれますし、デザイナーも仕様の背景を丁寧に理解してデザインしてくれています。

一方でややネガティブなギャップとしては、専任のスクラムマスターを置いてスクラムをしっかり回している印象があったものの、AI在庫管理の開発チームではちょうど体制変更の過渡期だったこともあり、レトロスペクティブができていないなどスクラムを効果的に回せてはいませんでした。この辺りは、変更後の体制がある程度馴染んできて、現在進行形で本来のスクラムの形に少しずつ寄せている途中なので、引き続きカイゼンを進められればと思っています。

その3: プロフェッショナルなメンバー

最後に挙げるのはプロフェッショナルなメンバーです。これは言わずもがなですが、どれだけ良い価値観と体制を用意しても、ひとりひとりの力が足りなければ良いプロダクトづくりはできません。これまでも、経験豊富なメンバーがチームに一定数いないとメンバーの育成も難しいなと感じていましたし、良いプロダクト以前に最低限の品質を担保することで精一杯でした。

カケハシの面接では、複数のエンジニアと話せる場を設けていますが、自分と同様に前職でマネージャーを経験していたエンジニアもいて、比較的シニアなメンバーが多いのかなと思っていました。

また、エンジニア組織としてHRTを重視している(「Team Geek」が必読書だったりする)という話しもあり、テクニカルなスキルだけでなく、マインドやコミュニケーションなどのソフトスキルも成熟したプロ意識の高いメンバーが多いのかなと感じていました。

こういった感覚はかなり曖昧なので、実際に入社するまでに正しく判断することは難しいなと思っていましたが、嬉しいことにここについては入社後のギャップはありませんでした。ひとつの課題を解消するために考えうる案を複数挙げて、それぞれのpros/consを吟味して実装方針を決定する。とても当たり前のことですが、関わるメンバー全員で、自然と、スピーディに実践できていますし、これまでよりも深くディスカッションできています。むしろ、私自身が未熟な部分が多く(本番環境でやらかしたり)、毎日必死でキャッチアップしているところです。

おわりに

さて、「良いプロダクトづくりに必要なこと」としてとりとめもなく書いてきましたが、本当のところをいうと、これらは必要条件でも十分条件でもないと思っています。体制が不十分であってもひとりのスーパーマンが素晴らしいプロダクトを産み出すことだってあるはずです。

ただ、良いプロダクトというのは一度つくって終わりではなく、つくり続ける必要があります。継続して再現性高く良いプロダクトをつくり続けるために、こういったことを意識できればいいのかなと感じているのが、上で書いたことだったりします。

これらは、ある程度エンジニア組織についてしっかり考えている会社であれば、当たり前のことなのかもしれません。ただ、少なくとも私がこれまで経験してきた中では決して当たり前ではなく、むしろ世の中には上で書いたことを実現できていない会社の方が多いのではないかと思っています。

今、そういった環境に身を置けていることに感謝しつつ、まだまだ不完全な部分に対して少しでも理想の状態に近づけるよう私自身も貢献できればと思っています。