状況に合わせたトレードオフで“ベター”を目指す　組織設計における、書籍『ソフトウェアアーキテクチャ・ハードパーツ』の活用

逆瀬川氏の自己紹介

逆瀬川光人氏：私からは「組織設計におけるハードパーツとトレードオフの活用方法を考えてみた」というところで、『ソフトウェアアーキテクチャ・ハードパーツ』を読んで、組織の問題を少しポストモーテムしてみた話をしたいなと思います。

簡単に自己紹介します。私はヘンリーのCEOをやっています。もともとはプロダクト畑にいて、楽天でモバイル、スマートフォンのWebやアプリを立ち上げるPdMやUXデザイナーを経験し、その後ウォンテッドリーに転職して、BizDevにキャリアを拡張し、新規事業の責任者としてビジネス側を統括していました。今はヘンリーで開発や採用、資金調達周りを見ています。

今まで、「楽天PointClub」のアプリや「楽天gateway」というポータルサービス、「Wantedly People」の立ち上げなどに携わっています。

医療系のDXに取り組むヘンリー

ヘンリーですが、電子カルテとレセプトコンピューターを作っていて、医療系のDXのど真ん中をやっている自負があります。カルテを書くところや、会計をするところの部分を担っていて、業務範囲がかなり広くて複雑なプロダクトです。

我々はクリニックに加えて病院の電子カルテとレセコンもやっているので、複数の診療科に対応し、診療報酬など複雑な領域も扱っています。なので、プロダクトにあわせて組織もアーキテクチャも少し規模が大きく、複雑になっているかたちです。

我々は、こういったディープな課題に本腰を入れて挑むアプローチをしています。業界にDeep-Diveして、より難しい、より時間のかかる問題にチャレンジしていこうと考えていて、その前提で組織をしっかり設計しています。

本セッションで話す内容

今日は、組織設計において『ソフトウェアアーキテクチャ・ハードパーツ』のエッセンスを活かしてみるところをお話ししたいと思っています。

組織もアーキテクチャだと思うので、けっこう応用できるポイントがあるかなと思っています。

今までの失敗談とかもあるので、そういった話の具体事例を少しお話しできればと思っています。

今日お話ししたいことは「組織設計におけるハードパーツって何なんだっけ？」みたいなところと、「それをどうやってトレードオフしてやってきたの？」という話。そして、「具体的にポストモーテムした時に、どういったところが活かせたんだっけ？」みたいな話を未来の話も含めてまとめてお話できればと思っています。

組織設計におけるハードパーツ

さっそく、組織設計におけるハードパーツについてお話ししたいと思います。

「ハードパーツの部分って何なんだろう？」みたいな話でいうと、「組織において変化しづらいもの、硬い部分」と、「組織において取り扱うのが難しいテーマ」の2つがあるかなと思っています。

具体的に硬い部分というと、ミッション・カルチャー・バリューなど、創業者および組織の思想的や、組織構造・役職など、変更するとハレーションが大きくて時間がかかる土台的なもの。あと事業ドメインで自ずと決まってくるもの。医療ドメインは（法令規制も多く複雑）なので、みなさん同じような課題を抱えていると思いますが、そういったものをイメージしています。

一方で「難しさって何？」みたいなところでいうと、けっこう具体的なものが多いかなと思っています。複雑で情報量が多い事業ドメイン、医療ドメインにおけるアーキテクチャに付随するチーム分割の話、まったく性質が異なるビジネスが混在し始めた時の評価制度の設計とか。

あとは、我々はプロダクトリリースまでに3年かかっていますが、時間がかかるプロダクトへのモチベーション設計をどう扱うのか。

ですので、この本のこの言葉がけっこう好きなんですけど、「アーキテクトは、自分の問題に対する「銀の弾丸」を探し求めてはならない」。

さまざまな難しい問題に常にぶち当たるのが、アーキテクトの方だと思っているんですが、組織設計をやられている方も同じく銀の弾丸はなくて、一つひとつ難しい問題をトレードオフでやっていくかたちなのかなと思います。

トレードオフする時に考慮するべきこと

トレードオフをする際に、どういったことを考慮するべきかですが、組織に与える要素は本当にさまざまなものがあって、事業ドメインからビジネスモデル、資金力や求められるビジネススピードなど。

先ほど（別のセッションで）「スプレッドシートで（オペレーションを設計し組織横断でお客様対応を乗り切る）」みたいなお話がありましたが、こういったものに対しても組織は柔軟に対応しなくちゃいけないし、それこそ事業フェーズやメンバーのスキルセットに合わせて取るべき組織形態が変わってくると思っています。

こういったさまざまな難題に対して、僕らがどういった制度やルール設計をしていくのかを、それぞれの設計に合わせた特性をバランス良く選択して、カスタマイズしていって、トレードオフの組み合わせでベターな方向性を目指していくのがけっこう重要なポイントで、ここがかなり僕の共感ポイントでした。

なので、常に動的に組織は進化していき、そこにベターを求め続けるというアプローチを考えています。

ヘンリーの失敗談

けっこう応用できそうだなと読んでいて思ったんですが、ポストモーテムですので、問題が起こっていた時にはこの本がなかったため漏れなく失敗した話をしたいと思います。

Henry's Sagaですが、後から変えていくのが難しい課題の部分をどうやって見極めていくのかとか、難しい部分をどうやって決定していくのかみたいなところの気づきになればいいかなと思っています。

前提ですが、電子カルテの特性みたいなところをお話しします。電子カルテ、レセコンの会計システムの特性は、ワークフローシステムや会計システムを兼ね備えているので、サービス規模がかなり大きくなります。

レセコンというのはつまり、1,700ページの本を実装し、しかもその1,700ページの本が2年間に1回改修がある。そういった膨大で曖昧なものとか不安定性みたいなものを吸収する会計のシステムになっています。

かつ、入院のフローも、病院の場合はアクターがかなり多くて。それこそお医者さん、看護師さん、管理栄養士さんとか放射線技師さんといったアクターも多いので、複雑なコラボレーションが発生します。

どのぐらい難しいのかをわかりやすく言うと、簡単に病院向けのカルテ、あとお会計の部分のレセコンは20年以上参入している新規プレーヤーがいないので、そのぐらいハードルが高いものをやっています。

チームが大きくなったタイミングでチーム分割もし始めましたが、そのタイミングで発生したコミュニケーション問題に関して、Henry's Sagaとしてお話ししたいと思います。

前提として、我々は難易度の高いものを現場にDeep-Diveして解いていくので、個人が自律的にチャレンジしていって、自分たちで解決していくことがキーだと思っています。

初期は本当に、みんながいい感じに解決してきて話し合ってやっていたんですが、ある時、僕と共同創業者の林君に（みんなが）メチャクチャ質問を聞きにくるようなことが起こって、「これはヤバい」と思い始めました。

そうなった時に、いろいろ分解してみるとコミュニケーションパスが僕らに集中しているし、現場の人たちも相互矢印がついていて、メチャクチャコミュニケーションが発生しているみたいなことが起こってしまって。これをどうにかしなくちゃいけないと思って解決しました。

このタイミングで、「じゃあこの本を読んでいたら、どういうトレードオフ分析をしたのか」ということを考えました。

我々の企業文化というところでいうと、オープンで自律を重んじるカルチャーがあります。事業ドメインでいうと、Deep-Diveしないと問題が解けない。扱う情報が多い。あとはメンバーのスキルセットでいうと、業界未経験者が多い。

事業フェーズでいうと、初期のフェーズなのでスピードが求められるところがあって、トレードオフをするべきところでいうと、自律的に意思決定をする環境整備や、業界を学んで自律的に動けるようにする支援など。

情報量が多くて、かつ業界未経験の人が多いので、認知負荷をちゃんと考慮してあげるとか、意思決定のスピードを意識した組織作りが必要です。

一番上の（自律的に意思決定するための環境整備のためにしたこと）は「漏れなく情報を公開する」みたいなことで、（これは）わりとベストプラクティスだなと思ったので（ヘンリーでも）できたのですが、ほかはほとんど失敗しました。

ここを見ると、企業文化はたぶん変更がしづらくて難しい。事業ドメインも変わらないので変更しづらくて難しい。メンバーのスキルセットとか難しさとかが他にも考慮すべき要素としてあって、こういったものをちゃんと考慮しなかった結果、オンボーディングが大変だし、認知負荷を無視して情報を与え続けたので、シャワーのように浴びてみんながパンクしたりとか。

あと、意思決定のスピードをあまり意識できずに、フラットの目的化とか合議制みたいなものが進んでしまったということがあって。それをちゃんとトレードオフしていたらけっこう防げたかなという気持ちになっています。

ソリューションとすると、認知負荷を合わせて情報とかミーティングを整理したり。一方で自主的に動きたい人のために、会議の動画をYoutubeに公開したり、Notionの議事録を全公開しています。

あとは、ロールの定義とデリゲーションみたいなものをちゃんとやったり、体系的な勉強会とか一問一答みたいなものを用意して解決していったんですが、こういったことに本当は冒頭でも気づけたのではないか、というところが大きな学びでした。

Sagaでの学びでいうと、ドメインをキャッチアップしなくちゃいけない分野であるのにもかかわらず、「（情報が公開されているのであとは）自律的にやってね」みたいに野に放ってしまったとか。

ドメインの複雑性を考慮しなかったので情報が多すぎてパンクしてしまったとか、意思決定プロセスをはっきりしなかった結果、なんでも私が決めることになって、意思決定の質が下がってしまいました。

あとは、組織はけっこう動的に進化していくものであることを忘れていて、最初から理想形を目指そうとしてしまったといったところが、気づきでした。

組織もモノリスからマイクロサービスに進化していくものだなと思っているので、ビジネス戦略に応じて組織もこれから細分化し始めています。今はもうチームが何個か分かれはじめていて、今後は事業部制に移行していく予定です。

チーム内でチームトポロジーなども勉強します。組織も、アーキテクチャにも合わせながらしっかりと変換していく可能性が高い部分かなとと思っていますので、形から入るのではなくて状況に応じてトレードオフしていって、徐々に理想形を目指していきたいなと今は考えています。

組織設計はベターな状態を目指していくことが重要

まとめです。組織設計もハードパーツがしっかりあって、状況に応じてトレードオフしていって、ベターな状態を目指していくことが重要だと思っています。

ヘンリーの場合は、ドメインの複雑性や扱う情報量を考慮することができず、漏れなく失敗しています。でも、どうにか盛り返しているので、組織も動的に進化していくと捉えています。

事業フェーズや人数、あとはメンバーのスキルセットに合わせて組織デザインを変更していって理想形を目指していき、ベターな状態を積み上げていきたいです。

具体的には、認知負荷をちゃんと考慮して、コミュニケーションの構造化を進めるとともに、そういった状況の中でチャレンジができる、自主的にドメインの課題を解決できる組織を目指していきます。

エンジニアの採用については、三社三様でやっていると思います。「この話をもっと詳しく聞きたい」など、みなさん興味があればぜひご連絡ください。以上になります。