薬剤師と患者双方の薬局体験向上を目的に、薬局体験アシスタント「Musubi」を展開している株式会社カケハシ（以下、カケハシ）。本日は、大手印刷会社からインターネットサービスの世界に飛び込んだ同社CTOの海老原氏に自身のキャリア形成やカケハシの組織構築にまつわるエピソードを伺いました。
慶應義塾大学大学院政策メディア・研究科修了後、凸版印刷株式会社でバーチャルリアリティ用3DCGビューア/SDKの開発、3DCGコンテンツ制作会社でテクニカルディレクションに従事。インターネットサービスに転進し、グリー株式会社にてSNS/プラットフォーム系開発に携わった後、株式会社サイカの取締役CTOを経て、創業直後の株式会社カケハシにCTOとして参画。
カケハシについて
弊社は「日本の医療体験を、しなやかに」をミッションに、薬剤師と患者双方の薬局体験向上を目指しています。2017年8月にクラウド型電子薬歴システム「Musubi」をリリースして以来、順次導入店舗を拡大しています。2020年7月には、調剤薬局に特化したBI（Business Intelligence）ツール「Musubi Insight」と患者向けにおくすり連絡帳アプリ「Pocket Musubi」という「Musubi」と連携する2つの新サービスをリリースしました。このように、カケハシは、さらなる薬局の働き方改革と患者満足を目指し、様々な取り組みを行っています。
大学の授業でプログラミングに触れた時、適性を感じた
大学進学時、新設の実学系の学部か文学部のどちらに進むか迷っていました。当時、インターネットという言葉自体が出始めて間もなかったのですが、そういうものを含めた情報技術やメディア研究の将来性を感じ、実学系の学部を選びました。
進学した慶應義塾大学の湘南藤沢キャンパスでは、情報処理が必修のため1年次からプログラミングに取り組んでいました。私は進路選択で文学部も視野に入れており、もともと人文系の学問や文章で何かを表現することに興味を持っていたので、最初は授業選択もそういうものが多かったです。けれど、授業を通してプログラミングを学ぶ中で、抽象的な構造の整理や論理構築で処理をコントロールすることに面白さを感じ、キャッチアップも早かったので、それまでは全く関心の無かったプログラミングに適性があるのかもしれない、と思うようになりました。
当時、ちょうどオブジェクト指向が普及し始めた時期で、所属していた研究室ではオブジェクト指向による設計をベースにしたプログラミングによる３DCG（現在のバーチャルリアリティ）のコンテンツ制作に取り組んでいました。
ロシアの研究者ウラジーミル・プロップ氏は著書『昔話の形態学』で、ロシアの民話を抽象的な概念設計で捉え直し、汎用的な構成要素の組み合わせで表現することができるという研究について著しています。私はこの考え方をシナリオの自動生成に活用できるのではないかと思い、3DCGキャラクターの単純な属性や行動をプログラミングで制御し、インタラクティブコンテンツとして表示するためのコンセプト実装に取り組んでいました。
私の所属していたゼミでは凸版印刷と産学共同研究を行っていました。凸版印刷はバーチャルリアリティコンテンツの文化的活用を行っていて、当時としては珍しい大規模な超高精細没入型シアターを保有していました。
そのシアターで上映するコンテンツのプロジェクトがゼミの先輩達のものだったという縁もあり、VR関連の開発チーム志望で凸版印刷の採用選考に臨み、無事内定をいただきR＆D部門に配属されました。
その部門はどちらかというと研究開発的な立ち位置が強く、大企業ですがとても自由にやらせていただいていましたし、今思うとすごく恵まれていた環境だったな、と思います。一方で、4年弱携わった頃、シアターで上映するためのVRコンテンツのために自分ができることはある程度やり切ったと考え、新しい環境に身を置くため2006年の秋に退社しました。
それから、凸版のVRチームに基盤を提供しているVR制作会社の方が一人でやっていた会社に入り、よりインディペンデントなかたちで3年程業務に携わっていました。けれども当時のVRは、まだシアターで上映するような用途以外であまり使われておらず、このままずっと単発な受注を繰り返してその案件状況に経営が大きく左右される仕事の仕方をしていて良いのだろうか、という焦りがありました。ちょうどWeb2.0のような概念がだいぶ浸透してきていた時期だったこともあり、Web系の開発への転向をキャリア的に意識するようになりました。
32歳で3DCG開発→Web開発へキャリアチェンジを決意
改めて今後のキャリアについて考え始めた時、ちょうどゼミの後輩から誘われたので、少し話を聞いてみようかな、という位のフランクな気持ちでグリーの選考に行きました。それから、とんとん拍子に選考が進み入社することになりました（笑）決め手としては、グリーのCTO藤本さんの人柄に惹かれた、という点が大きかったです。
当時のグリーは、既にマザーズに上場していて東証一部に市場変更する直前のタイミングでした。私は、グリーに入社する32歳までWeb開発の経験がなかったので、OJTのような形で実際に触ってみつつ、先輩に教えていただきながら学んでいきましたね。
まず、開発言語の違いや基本的な設計論のようなことについては全く不安はありませんでした。もちろん、３DCGとWeb開発は大きく違いますが、情報処理技術やエンジニアリングの本質的な部分については領域が違ってもあまり変わらないと思っていたからです。そのため、シンプルな開発や改修のキャッチアップにはそこまで時間はかかりませんでしたね。
一方で、もちろんデータベースのチューニングや基本的に全ての処理がネットワーク越しであることなどはそれまでに全く無かった考え方だったので、そういう部分のキャッチアップは結構苦労しました（笑）
入社後しばらくは、SNS系サービスの業務に携わっていて、投稿機能や青少年保護のための投稿監査の開発を行っていました。ちょうどスマートフォンの存在感が増してきたタイミングでアプリ開発の対応をする必要があり、以前Javaを使ったことがあるという経緯からAndroidアプリ開発の立ち上げを最初一人で任されました。のちに、チームの拡充に伴いリーダーを務めるようになり、退職する1年ほど前からは全社的なサービスグローバル化のプロジェクトにAndroidチームとして参加しました。また個人としても、SNS関連APIの基盤部分の開発担当として参加しましたね。
20代の頃も業務上リーダーシップを取る場面はありましたが、グリーでの業務から明確にリーダーシップやマネジメントを意識するようになり、強みのあるスキル経験として設定しているところはあります。けれど、現時点でも本来の自分が性格的にリーダーという役割にあまり適しているとは思っていないですね（笑）根本の話をすると、黙々とプログラミングや新しい技術の調査などをしていたいタイプの人間だと思います。
一方で、マネジメントやリーダーの事業、組織における機能とその重要性にとても興味があり、今後もそういう側面で業務するのがメインになるだろうと思っていますね。私のキャリアを通じて一貫したスタンスとして「成長のためにコンフォートゾーンから離れ続ける」ということがあって、自分が好きで楽しいことをただやるよりも今の動き方の方がよいと思っています。
スタートアップ企業へCTOとしてジョイン
もともと私は、グリーでWeb系の知識を吸収したら最終的には自分で組織を作りたいと考えていました。
2012年の夏頃に当時携わっていた大きなプロジェクトがひと段落したタイミングで、起業したばかりのサイカのCEOと知り合いました。その時、彼から「こんなビジョンを持っています」、「こんな世界になったら本当に良いと思う」というような起業に至った想いを聞きました。社会を変えるために具体的なビジョンを持って事業を起こしたいと本気で夢を語る人と一対一で議論したのは初めてだったので、とても感銘を受けました。それまでどちらかというとエンターテイメントの領域で働いていたのですが、この時、より直接的な社会貢献につながる事業に携わりたいという気持ちが明確になりました。
サイカが創業されたのはデータサイエンスブームが来る前でしたが、全ての人が定量的なデータを元に統計的なアプローチで意思決定する世界の実現をビジョンに掲げている会社でした。当時、私自身基本的な統計の知見しかなかったですが、課題意識にリアリティがありどうやって社会を変えたいかというビジョンを感じられたので、そこに自分が持っている技術のエッセンスを加えることで、できることは沢山あるな、と思いジョインすることに決めました。
創業初期なので、所謂CXOというような業務というよりも、一テックリードとしての振る舞いが多かったです。社内ITの整備からサービスに関するリードエンジニア、インフラ整備、サービスの基盤になっているミドルウェアの実装、開発ロードマップ作成、開発手法の選定、採用など幅広く携わりました。
30代後半だったので、最後にもう1度だけ0から組織を作ることへチャレンジしたいと思い、知り合いのキャピタリストにCTOを探しているスタートアップをご紹介いただきました。その中の１つにカケハシがありました。
ファウンダーの中尾と中川は私より一回り位下の世代ですが、日本という国の医療の未来に対する明確なビジョン、サスティナブルな医療を実現するためのイメージを持っていました。また、それだけではただの夢に終わってしまいますが、その時点で描けるレベルの具体的な事業ロードマップも作っていたという点は大きな決め手になりましたね。
話を聞たうえで、この事業は私達生活者にとって今後とても重要になるものだと共感できましたので、ジョインすること決めました。
最初は、ボードメンバーのWebサービスへの理解とエンジニア採用から始めた
まずは、とにかく採用でした。リファラル採用で一緒に働きたいと思う知り合いに声かけていきましたが、グリーの時の知り合いは大体どこかのCTOとして働いており、なかなか苦労しました（笑）5～6人くらい集まれば、一旦サービスを開発できると思っていたので、そこまでは採用に全力を注ぎましたね。
それから、中尾や中川も本格的にWebサービスで起業するのは初めての経験だったので、いわゆるWebサービスというものをどういう風に開発して顧客に価値訴求いくものなのか話をしていきました。例えばMVPというような概念について「プロダクトを作るうえで最初から大きい物を作るのではなくて、市場に求められる最小限のものから作っていった方がいいですよ。そうだとしたら、まず何しましょうか」という風にファシリテーションしていきました。入社１年目は、このように一緒に進めながら開発チームを作っていきました。
一緒に進めつつも、最初から「（経営陣の意見は）尊重すべきアイディアとして受け取りますが、それをどう咀嚼して実現するかは実際に開発する人間に任せて欲しい」と話していました。
経営陣がサービスに一番強い思い入れがあるのは当然です。その上で、例えば「（サービスのデザインを見て）ここの余白をもっと空けたい」など細かいところの指摘に対して、「デザインの分野は、最終的にはデザイナーに任せて欲しい」と伝えました。
私も含めて、経営陣が言ってしまうと、どうしても現場は指示、命令として受け取ってその通りに作らなければいけない、という雰囲気になってしまいがちです。もちろん、開発初期においては顧客である調剤薬局の意見や文化に一番詳しいのはファウンダーの二人なので、そのような意見はきちんと受け取り反映するようにしました。けれど絶対的な命令として受け取られないような状況作りはしていくべきだと考えていました。
最近、改めて明確にしたところでもありますが、やはり明確な意図を持った役割分担とフォーメーション設計をしてお互いの専門分野を尊重し任せ合うことが大切だと思います。例えば「調剤薬局の昨今の流れからこういうことをすべきだ」と社長が言ったらその顧客視点を尊重し、私が「サービスの堅牢性からこういう取り組みをした方がよい」と言ったらそれを尊重してもらったり、専門外でも気づいたことは指摘しつつお互いの意見を尊重し合うことが大切だと思います。
最初は、バリューの必要性について社内から声が上がったので作ることになり、全社でワークショップを行い意見を出し合いました。この取り組み自体はとても良いものだったのですが、そこで生まれたものは多くの意見をくんでまとめていった結果とても抽象的な内容で色が無く、会社のバリューとして打ち出すには厳しいレベル感のものでした。どうしようかと悩んでいたタイミングに、コーポレートブランディングやコピーライティングに大きな強みを持つ人が入社してくれたので、その人にバリュー定義を一から全面的にお任せしました。
そうしたら、やり方が真逆になり、経営陣が1日缶詰めになって「どんな人と働きたいか」を濃密にディスカッションし、その場で最終的に６つの内容に絞りこむところまで一気にやる進め方になりました。その後、最終的なワーディングはその担当者に任せつつ私が監修してまとめていきましたね。
浸透はまさに今の課題です。コロナショックもあり全社でコミュニケーションを取る機会が減る一方で、組織として必要な拡大を進めるため、バリューの深い意図までを浸透させることの重要性と難しさは以前よりも格段に上がっています。
すぐにできることとしては、日常の中でバリューを意識しやすいように工夫しています。例えば、Slack上でバリューの言葉をスタンプ化したものを作り皆で日常的に使えるようにしたり、バリューに寄り添った良い行動があればそのバリューの言葉とともに称賛するような動きをスクラムマスター達で強く意識するなどが挙げられます。
バリューの浸透は、経営陣からトップダウンのメッセージとして発信するだけではあまり効果がでないと思うんです。それは前提として、日々の行動や思考などでメンバー自身が意識しながら徐々に組織文化として醸成されていくというのが理想のかたちですね。
フルフラットな組織を実現するために、考えるべきこと
確かに、フルフラットの組織が常に必ず良いとは言えません。フルフラットにすることでどういう組織デザインを意図していて、どんな事業的メリットがあるのかが重要だと思います。
フルフラットのメリットとしては、情報伝達の直接性や個々のメンバーの動き方の柔軟性、集合知による創造的な発想と組織的なレバレッジなどが挙げられます。スタートアップの強みは密度の高い集団で圧縮した意思決定であるからこそ、硬直化した階層を設けることで情報伝達に途中の誰かの思惑が混ざったり承認リレーで意思決定に時間をかけてしまうのは致命的です。また、偉い人でないと何かを決められないということ自体が、柔軟な考えや判断力の低下、より専門性の強いメンバーへの権限移譲の阻害に繋がると思います。そういった意味で、特に初期のスタートアップにはフルフラットが向いていると言えるかもしれません。
もちろんフルフラットにも、デメリットはあります。例えば、何か意思決定を進めたい時、静的に職能分化された組織と階層がある場合は誰に話をもっていけば良いか明確ですが、いわゆるフルフラット・アメーバの類の組織だと、きちんと整理しないと分かりにくいです。誰が責任と権限を持っているのかを常に明確にしておかなければ、途中でボールが落ちてしまいます。ピラミッド型の階層構造として定義されていれば自動的に進められることを、状況が刻一刻と変わっていくことを前提として組織と個々人がチューニングしながら意思決定していくことが求められるため、各自の認知負荷が高くなります。そのため、組織全体に対して高い自律性と柔軟な思考を業務の前提として求める組織の作り方になります。
形だけフラットにすると誰も物事を決めないことになってしまうので、そうならないように組織を作るのは大変だとつくづく実感しています。それらのデメリットを補うために、コストやリソースを割けると経営陣が覚悟できるのであれば、フルフラットを導入しても良いと思います。
約40人のエンジニアがまず提供しているサービスごとのスクラムチームとしておおまかに4チームに分かれ、その他専門分野的なチームとしてSRE、メディア、コーポレートエンジニアリングなどのチームがあります。スクラムで回していますが、役職ではなく役割という考え方で整理しています。
プロダクトマネージャーは、自身が責任を持つサービスについて最終的な意思決定を行う権限を持っていて、そのために関連する複数チームの動きを調整する役割になりますが、他のメンバーに対して強制力を持った細かい指示や命令を手段として仕事を進める役職ではないと捉えています。とはいえ、それは複数のチームを統括する部長のような役職と何が違うのかというとなかなか説明の仕方が難しいですが、メンタルモデルとしてのあり方の違いとして考えられるのではないかと思います。
創業後しばらくは、スクラムで言うとプロダクトオーナーはいても明確なプロダクトマネージャーというポジションを置いていませんでした。他の職種も同様に、複数チームを取りまとめるような役割をあまり明確に置いていませんでした。その理由は、丁寧に設計していかないと人によっては過去の経験からそのような役割を担う人が偉い人である、と受け取られてしまう恐れがあったからです。
けれども、40人の規模にまで拡大するとプロダクトの全体を包括的に見る人なしでは、今度は組織が機能しなくなるので、プロダクトマネージャーを置いたり複数チームをまとめるチーム内チームのような概念を設定しました。その際は、階層的、権力構造的な考え方に寄ってしまわないよう意識した作り方や表現をするように気を付けています。
このように組織の成長に繋がることを重きにおいて、事業規模に合わせながら考え方を微調整して進めているため、私が2016年に言っていったことと、今言っていることは表向きは全然違うと思いますね（笑）
以前は一部の人がフルリモートで勤務していましたが、今は全員がフルリモートで、問題なく回っていますね。
もともとー部の人がフルリモートで仕事をするのが前提だった為、会社に来ているメンバーだけが持っている情報で意思決定するのはよくないことだという、業務マナーは既に共有されていました。議論の過程は必ず何らかのログとして残すとか、必要あれば別途共有するなど、そのような文化の土台を4年間かけて作っていったので、今上手く回っているようにも思います。
とは言っても、場合によっては全員集まった方が上手く回る業務もあるので、生産性の低下というデメリットは多少なりともあります。一方で通勤時間が省略されるとかより個々の生活に合わせた柔軟な働き方というメリットもありますので、コロナで社会の前提が変わったことをきっかけにこれからの働き方を考えていきたいですね。
患者さんがライフスタイルに合わせた医療を選択できる世界にしたい
ここ2年ほどは採用が非常に大きい割合を占めていましたが、現在は、組織が急激に拡大したため社内の体制を整えるフェーズにきています。そのため、開発には意思決定レベルでは関わるようにしていますが、一旦コーポレートエンジニアリングやバリューの浸透のような組織的な課題を解決するための業務が多くなっています。
「今までできなかったことが、世界そのものが変わってしまうようなあり方でできるようになる」というのが、技術やエンジニアリングの本質だと考えています。以前は大きな資本・資材・人材がないと実現できなかったことも、技術の革新によって少ないリソースでできるようになったので、あらゆる物事が民主化され個人の力が開放されます。
カケハシのCTOとしての観点からいうと、患者さんがそれぞれのライフスタイルに合わせて多様な選択肢の中からどういう医療を受けるか最適なものを選べるようになることが重要だと考えています。
薬剤師や患者さんの薬学治療に関するあらゆる動きをデジタル技術で情報化した上で、それに対してどうアクセスするかは各自に委ねられている、そうした状況を実現していくために技術を活用していきたいと考えています。これらを実現するために、解決しなければならない問題は、技術的ハードルが高いものだけでなく、セキュリティ上の課題や制度に適応するための調整など山積みです。
けれども、これらのデジタルプラットフォームを作ることは、社会的に意義の大きいですし、ゆえに全力で取り組む価値も感じますので、今は実現に向けて１つ１つの課題に取り組んでいきたいです。
