組織設計におけるハードパーツとトレードオフの活用方法を考えてみた / 株式会社ヘンリー
組織設計におけるハードパーツとトレードオフの活用方法を考えてみた / 株式会社ヘンリー
スタートアップ×TECHに関する様々なイベントをお届けするStart Tech Live。「医療DXをリードする3社が考えるプロダクト・アーキテクチャ ソフトウェアアーキテクチャ・ハードバーツから学んだこと」で登壇したのは、株式会社ヘンリーの逆瀬川氏。組織設計におけるハードパーツとトレードオフの活用方法の考えを紹介しました。
スピーカー
逆瀬川光人 | 株式会社ヘンリー ｜ 共同CEO
楽天でUI/UXやPMの仕事を5年、ウォンテッドリーで新規事業のBizDevの責任者を3年務め、2019年、創業。楽天時代は楽天PointClubの立ち上げPdMなどを中心に、10個以上のサービス、アプリの立ち上げとBizDevを経験。Henryでは、複雑な課題を解くのが好きな開発者を募集しています！
ヘンリー 逆瀬川 光人 氏（以下、逆瀬川）：私からは「組織設計におけるハードパーツとトレードオフの活用方法を考えてみた」というタイトルで、ソフトウェア・アーキテクチャ ハードパーツを読んで組織の問題をポストモーテムしてみた話をさせていただきます。
簡単に自己紹介をします。私はヘンリーのCEOで、元々プロダクト畑にいました。楽天でモバイル、スマートフォンのウェブやアプリの立ち上げのPdMやUXデザイナーを経験し、その後Wantedlyに転職しました。その後、BizDevで新規事業の責任者をした後ビジネス側を統括しました。今はヘンリーで開発・採用や資金調達周りをみています。
ヘンリーは、電子カルテとレセプト会計システムを作っていて、医療系のDXのど真ん中をやっている自負があります。カルテを書くところや、会計をするところの部分を担っていて、業務範囲が広くて複雑なプロダクトです。
我々はこういったディープな課題に本腰を入れて挑むアプローチをしているので、業界にDeep-Diveして、より難しい、より時間のかかる問題にチャレンジしていこうと考えています。その前提で組織をしっかり設計しています。
今日は組織設計において、ソフトウェアアーキテクチャ・ハードパーツのエッセンスを活かしてみるというところをお話しします。
組織設計はアーキテクチャだと思いますので、結構応用できるポイントがあるかなと思っています。
今までの失敗談とかもありますので、少し具体事例をお話ししたいと思います。
今日お話ししたいことは「組織設計におけるハードパーツって何なんだっけ？」「それをどうやってトレードオフしてやってきたの？」という内容です。そして具体的に「ポストモーテムした時にどういったところが活かせたんだっけ？」のような未来の話のまとめも含めてお話しできればと思います。
1. 組織設計におけるハードパーツ
組織設計におけるハードパーツについて、早速お話しします。
「組織設計におけるハードパーツな部分って何だろう?」
こちらの問いに対して「組織においては、変化しづらいもの」と「組織において取り扱うのは難しいテーマ」の2つがあると思っています。
具体的に硬い部分でいうとミッションやカルチャー・バリューなど創業者が組織の思想的な性質なものと、組織構造・役職などの変更に時間がかかる土台の設計のもの、事業ドメインなどで自ずと決まってくるものをイメージしています。
一方で難しさについては、結構具体的なものが多いと思っています。
複雑で情報量が多い事業ドメイン、医療ドメインにおけるチーム分割やアーキテクチャの分割の話や全く性質の異なるビジネスが混在した際の評価制度設計、プロダクトのモチベーション設計などです。
2. 組織設計におけるトレードオフ
この本にはいい言葉が掲載されています。
「アーキテクトは、自分の問題に対する『銀の弾丸』を探し求めてはいけない。」
様々な難しいものの内に常にぶち当たるのが、アーキテクチャをやるアーキテクトの方だと思っています。
そして組織設計をやられる方も同じく、銀の弾丸はなくて一つひとつ難しい問題をトレードオフでやっていく形だと思っています。
トレードオフをする際にどういったことを考慮するべきかについて。組織に与える要素というのは本当にさまざまなものがあります。
事業ドメインからビジネスモデル、資金力や求められるビジネススピードです。先ほど（別のセッションで）「スプレッドシートで（オペレーションを設計し組織横断でお客様対応を乗り切る）」みたいな話がありましたが、こういったものに対しても組織は柔軟に対応する必要があります。
それこそ事業フェーズやメンバーのスキルセットなどに合わせて取るべき組織形態が変わってくると思っています。
こういったさまざまな難題に対して、僕らがどういった制度とかルール設計をしていくのかを、それぞれの設計に合わせた特性をバランス良く選択してカスタマイズし、トレードオフの組み合わせでベターを目指してくみたいなところが重要なポイントと思っています。ここがかなり僕の共感ポイントです。
常に動的に組織は進化していき、そこにベターを求め続けるっていうアプローチを考えています。
3. Henry’s Saga
結構応用できそうだなと読んで思ったんですが、当然ポストモーテムなので問題が起こってる時はこの本はありませんでした。
そこで、失敗した話をしたいと思います。Henry’s Sagaについてです。
後から変えていくのが難しい課題の部分をどうやって見極めていくのかと、決定していく部分が難しい部分をどうやって決定していくのか、の気づきになればいいかなと思っています。
まずは前提として電子カルテの特性についてお話しします。
電子カルテ・レセコンの会計システムの特性についてですが、ワークフローシステムや会計システムを兼ね備えてますので、サービス規模がかなり大きいです。
レセコンっていうのはこの1700ページの本を実装する必要があります。しかもその1700ページの本が2年間に一回改定される診療報酬制度と複雑な業務フローだったり、曖昧性や不安定性みたいなものを吸収する会計のシステムになっています。
且つ、入院フローについてもアクターが病院の場合だとかなり多くなります。例えば、お医者さん、看護師さん、管理栄養士さんや放射線科の方です。結構複雑なコラボレーションが発生します。
どのぐらい難しいのかを分かりやすく言うと、病院向けのカルテ、会計部分のレセコンに20年以上参入している新プレイヤーはいませんので、そのくらいハードルが高いものをやっています。
チームが大きくなったタイミングでチーム分割を始めたのですが、このタイミングで発生したコミュニケーション問題に関して、Henry’s Sagaとしてお話ししたいなと思います。
我々は前提として、表面的に見える課題を現場にDeep-Diveして解くべき課題を発見していくので、個人が自律的にチャレンジし自分達で解決していくことがキーだと思っています。
初期だと本当にみんながいい感じに解決してきて話し合ってやっていました。しかしある時、僕と共同創業者の林くんに質問とお伺いが来る状況が頻発してしまいました。
そうなった時、色々分解してみるとコミュニケーションパスが殆ど僕らに集中してるし、現場の人たちも相互矢印が付いててコミュニケーションが多発してる状況になっていました。どうにかしなくてはらないと思い、解決をしました。
このタイミングでもしもこの本を読んでいたら、どういうトレードオフ分析をしたのかを考えてみました。
我々の企業文化はオープンで、自律を重んじるカルチャーがあります。事業ドメインはDeep-Diveしないと問題が解けない、情報が多いと言う特徴があります。
またメンバーのスキルセットは結構未経験者が多く、事業フェーズでいうと初期のフェーズなのでスピードが求められるみたいなことがあります。
トレードオフをするべきところでいうと、自律的に意思決定をする環境整備、業界を学んで自律的に動けるようにする支援、そして、そもそも情報量が多くて且つ未経験の人が多いので認知負荷をちゃんと考慮すること。それから、意思決定のスピードを意識した組織作りが必要になります。
一番上の項目については、情報公開する対応でベストプラクティスだなと思ったので出来ましたが、他はほとんど失敗してました。
ここを見ると、企業文化は変わらないので「変更がしづらくて難しい」、事業ドメインも変わらないので「変更はしづらくて難しい」メンバーのスキルセットとか難しさと硬さがありました。これらをちゃんと考慮しなかった結果、オンボーディングが大変だったり、認知負荷を無視して情報を与え続けたので、メンバーに負荷がかかってしまいました。
意思決定のスピードは、あんまり意識できずにフラットの目的化とか合議制みたいなのが進んでしまったっていうのがあって、それをちゃんとトレードオフしてたら防げたかもしれません。
ソリューションとすると、認知負荷を合わせて情報とかミーティングを整理したり、自主的に動きたい人の動画を出したり、Notionの議事録とかを公開したりなど。またそのロールの定義とデリゲーションをちゃんとやったり、体系的な勉強会とか一問一答を用意して解決しました。しかし、冒頭でもこういったことに本当は気づけたのではないか、というところが学びでした。
このSagaでの学びでいうと、ドメインをキャッチアップしないといけない分野であることを考慮せずに、ただ自律的な行動を求めてしまったこと。ドメインの複雑性を考慮しなかった結果、扱う情報が多すぎて負荷がかかってしまったこと。意思決定プロセスをはっきりしなかった結果、なんでも合議制とか私が決めることによって意思決定の質が下がってしまったこと。あとは組織が動的に進化していくものであることを忘れていて、最初から理想型を目指そうとしてしまったことが、学びでした。
組織もモノリスからマイクロサービスに進化していくものだと思っているので、技術戦略に応じて組織もこれから細分化し始める予定です。
今のチームは何個か分かれていますが、事業部制に移行していく予定なので、チームトポロジーをチーム内で勉強しつつ、組織もそういったアーキテクチャに合わせながらしっかりと変換していく可能性が高いと思ってます。
しっかりとカタチから入るのではなくて、状況に応じてトレードオフして、徐々に理想形を目指していきたいなと思ってます。
4. まとめ
組織設計もハードパーツがあり、状況に応じてトレードオフしていきベターな状態を目指していくことが重要かなと思っています。
ヘンリーの場合はドメインの独自性や扱う情報量を考慮することができず、失敗してます。どうにか盛り返しているので組織も動的に進化していくところと捉えています。
事業フェーズや人数、メンバーのスキルセットに合わせて組織デザインを変更していき理想形を目指してベターな状態を積み上げていきたいです。
具体的には、認知負荷をちゃんと考慮してコミュニケーションの構造化を進めるとともに、そういった状況の中でチャレンジができる・自主的にドメインの課題を解決できる組織を目指したいと思ってます。
皆さん興味があればご連絡いただければと思います。
採用情報
https://jobs.henry-app.jp/
Startup Tech Live
こちらのグループはVC「Globis Capital Partners」が主催するTechnologyにフォーカスしたcommunityになります。 スタートアップ×Engineeringに関する情報はもちろん、著名な方の登壇イベント等を発信していきます。
Globis Capital Partnersは日本初の本格的ハンズオン型ベンチャーキャピタルとして1996年に設立しました。 日々次世代のリーディングカンパニーを生み出すためにチーム一丸となり精進しております。
Twittter: https://twitter.com/gcp_byvc
connpass: https://gcp-tech.connpass.com/
この記事が気に入ったらサポートをしてみませんか？