VPoEの私が導入過程に飛び込んでみて感じた組織開発の醍醐味
こんにちは。株式会社ヘンリーVPoEの張です。弊社は8月からダブルVPoE体制を施行しており、私はエンジニアリング思想をベースとした組織づくりのプラクティスを全社に展開する役割を担っているため、組織開発室をリードしている立場でもあります。
全社の組織開発の一環として、弊社サービスHenryを選んでくださった医療機関様への導入プロジェクト、特にインストールプロセスに最近から携わり始めました。まずは私個人の反省からのスタートになりますが、この1、2年は主にVP of Engineeringロールとして開発組織のチームづくりを行なってきたこともあり、開発組織以外の解像度はそれほど高くありませんでした。そのため、我々が提供する付加価値の大部分はHenryというWebサービスより生み出していると考えていました。なぜなら、私たちは医療従事者の業務効率化を推進することで付加価値を提供しております。そのアプローチとして、業務の一部をHenryのソフトウェアシステムに委譲すること負担軽減を図り、逆にインストールプロセスはHenryの価値を正しくお客様のところで反映させる一連の業務だと理解していました。
例えば、観たい映画のDVDを買って自宅のプレイヤーで再生して鑑賞する時、映画コンテンツが楽しみをもたらしてくれるのでそこに大きな価値を感じますが、プレイヤーを利用して再生すること自体は不可欠ではあるものの価値を感じることが少ないと思います。同様に、我々のサービスを活かしていただくためにインストールプロセスは不可欠だが、そこの付加価値が意識できていませんでした。
実は導入業務はイノベーションである
しかし、インストールプロセスを担当しているPartner Growthチームの組織開発を行なっていくために、実際に導入プロジェクトへ飛び込むことで解像度向上に繋げるようにしました。このディープダイブの経験から、ヘンリーのインストールプロセス自体は大きな付加価値の伴うイノベーションではないかと考え始めました。（イノベーションという単語は広く使われているため文脈によって指す内容が異なります。私はWikipedia上記載されている『物事の「新機軸」「新結合」「新しい切り口」「新しい捉え方」「新しい活用法」（を創造する行為）のこと』だと解釈しています。）
書籍の名前はもう思い出せないですが、以前読んだ技術書の中に印象に残る記述がありました。プログラミングのプロセスにクリエイティビティが欠かせないので製造業の部品製造と違い、どんな小さなソフトウェアモジュールの開発でも新規性が含まれています。そのため、ソフトウェアエンジニアリングはイノベーションの積み上げであると表現されていました。
その考え方から出発した私はヘンリーのインストールプロセスはソフトウェアエンジニアリングの本質とかなり近いと感じました。
ソフトウェア開発を行う時、エンジニアはまずモジュールが実現したいことを把握することになるでしょう。必要に応じてプロダクトマネージャーやアーキテクトと擦り合わせることが多々あります。実現したいことを一言でまとめられる場合でも、色々なユースケースと条件分岐が存在することがほとんどで、どこまで実現させるべきか、どうすれば賢く実現させることが可能かは頭を悩ませるポイントであり、イノベーションが生まれるポイントでもあります。
例え一見簡単なファイル読み込みモジュールでも、対象ファイルと想定用途によってプログラムのロジックが異なりますので、多くのアプローチが選択肢として潜んでいます。賢いアプローチを考え出して実装することによってプロダクトにイノベーションを加えることになります。
一方、ヘンリーのインストールプロセスでは、Partner Growth該当担当のチームメンバーが医療機関様の各部門の方々にヒアリングを行い、まず達成したいことを把握することになります。日本の医療現場では、同じ医事部門であっても医療機関のジャンルや成り立ちによって業務内容が大きく変わります。もちろん看護部門や検査部門など他の部門も同様です。そのため、ユースケースと条件分岐の把握が必須です。さらに、慣習として残っているが破棄もしくは変更したほうが良いワークフローが多く存在します。医療機関様と連携しながら適切に判断を行う上、あらゆるアプローチから賢い選択肢を考え出してお客様に実践していただくことになります。その際、”プレイヤーにDVDを再生させる方法を伝える”ような業務はほんのひと握りに過ぎず、多くの場合はもっと踏み込んだコンテキストでのワークフロー設計と実装です。
上記のように整理してみたら、ソフトウェアエンジニアリングとインストールプロセスはただ単純に対象が異なるだけだと感じました。前者の対象はソフトウェアプロダクトで、ヘンリーのインストールプロセスの対象はワークフローになります。つまり、ワークフローエンジニアリングです。インストールプロセスの角度から考えたら、我々のプロダクトはあくまで食材で、如何に賢く美味しい料理を仕上げるかはPartner Growthのもたらす付加価値に直結し、そこで生み出したプラクティスはプロダクト開発と同様に大事なイノベーションです。
バーティカルSaaSはバリューチェーンとの粘着性が非常に大事だと言われています。ヘンリーの場合、”食材栽培”と”調理過程”の相乗効果によって粘着性が生まれ、インストールプロセス抜きでプロダクトの価値を語ることが不可能だと体感しました。
すなわち、Partner Growthのイノベーション力は我々の価値（＝私たちが医療機関様へ提供できる価値）を左右する部分だと言えるでしょう。
ディープダイブの価値
最近、社会学者の細田満和子様の著書『「チーム医療」とは何か』を読んでおり、まえがきに書かれていた著者の心境変化が非常に印象に残っていました。ご本人が『「チーム医療」の理念と現実』を執筆する際に、研究者として一歩引いた傍観者の立場を取っていたため、下記のようなコンセプトを反映していたそうです。
現場の当事者の考えるチーム医療について概念整理をしますから，あとは現場の方々で考えてください
しかしその後、アメリカの大学で研究員に従事し、各国の学者たちと交流を深めることによって、実際の医療現場にディープダイブし、アクターとして関わる価値を実感し、研究者でも現場に関わらなくては行けないことに気づいたそうです。
このエピソードにとても共感を覚えました。もし私がヘンリーのインストールプロセスに深く関わっていなかったら、今回のような鮮明な所感を得ることができなかったでしょう。飛び込んだことによって、解像度が高まり、今後の施策判断の精度に大きく寄与できると信じております。
私が今いる組織開発室のミッションは「ヘンリーのミッションとバリューが浸透され、事業とともに急成長できる組織の実現を支える」を掲げており、書籍チームトポロジーでいうイネーブリングチーム（Enabling team）に該当します。簡単に言えば各チームの成長に助力する役割にあたります。いわば上記の細田様の立場と近い気がします。だからこそ卓上で組織の課題をまとめ、ルール作りのスタンスにハマっては行けないと考えております。
私はたまにハイキングをしますが、自然の風景は山頂からも山麓からも見るべきだと考えています。なぜなら、山頂では広く遠く見える一方、山麓でなければ細かく見えない風景がたくさんあります。組織開発に取り組む者として、視点を柔軟かつ頻繁に寄ったり引いたりしながら、各チームの業務にしっかりとディープダイブした上で、組織施策を打っていく必要があると考えました。チームメンバーが業務に旺盛な好奇心を持つことはもちろん、論理的思考力と柔軟な発想力も磨かなければいけない為、とてもチャレンジングであると同時に、やり甲斐を多く感じる仕事だと思っています。
もしこのようなミッションにワクワクを感じていただけるのであれば、これから1年のヘンリーは絶好の舞台だと考えており、ぜひ一度お話しができたら幸いです。
(Mostafa Ashraf Mostafa様の素敵な写真をカバー画像として使っております)