組織成長=事業成長、メンバー主体の意思決定を目指す組織の現実と理想
株式会社ヘンリーは、「社会課題を解決し続け、より良いセカイを創る」というMissionのもと、クリニック・中小病院向けの基幹システムであるクラウド型電子カルテ・レセプトシステム「Henry」を開発・展開しています。
今回お話を伺ったのは、開発側のチームビルディングを進めているVPoEの張さん(@shenyu_cyan)です。前職のビズリーチでは複数のサービス開発のリードやプロジェクト管理、エンジニア採用などを経験。2021年11月からヘンリーに入社しています。
「対外的にはVPoEと名乗っていますが、私にしか権限がないような業務はほぼありません」と語る張さん。チーム運営における決定権の委譲の話からはじまったインタビューは、チームの分割や、コミュニケーションの最適化などへと展開。理論と経験に裏打ちされたヘンリーのチームづくりの哲学についてたっぷりお話を伺いました。
実力者が揃っているからこそ、チームビルディングの可能性を感じた
— 最初に、張さんのお仕事内容について教えてください。
一言で言うとチームビルディングがメインの仕事です。プロダクトチーム全体の「持続可能な自律的成長を促進する」ことをミッションに置いています。もちろん、私一人ではなくメンバーと連携しながらですが、チームづくりの玄関口である採用活動やオンボーディングから、その先にあるメンバーが活き活きと働ける体制づくりや企画まで、組織の内外に目を向けて様々な活動をしています。
— 現在、プロダクトチームはどういった体制で運営されているのでしょうか?
現時点では、プロダクト側はさらに5つのチームに分かれています。例えば、開発者体験の向上と技術基盤の開発を担うプラットフォームグループや、「Henry」を通じてお客様が医療行為に集中できる状態を創るカスタマーエクスペリエンスなどいくつかの担当領域に分かれます。いまは業務委託も含めて約25名ほどのメンバーが、役職ではなくロールを起点に領域を横断しながら関わっています。
私は便宜上、対外的にはVPoE(Vice President of Engineering)と名乗っておりますが、ヘンリーはロールベースの組織のため、私にだけ権限があるような業務はほぼありません。メンバーをプロフェッショナルとして信頼しているため、権限の委譲は意識的に行っています。
— 張さんはチームビルディングにもともと興味をお持ちだったのでしょうか?
前職の時はチームビルディングに長らく携わっていましたが、業務委託のときを含めヘンリーに参画した当初は、エンジニアとして開発を担当していました。ヘンリーは開発力の高いメンバーが揃っているため、組織面が改善されたときの事業成長へのインパクトが大きいと仕事をするなかで思いはじめました。
事業成長には、組織の成長が不可欠。そこに成長ポテンシャルを感じたので、チームビルディングに注力するようになりました。
コミュニケーションの最適化により開発に集中できる環境をつくる
— チームビルディングと一口に言っても、考えるべきことは多岐に渡りそうですが、これまでどんなことを進めてきたのでしょうか?
まずは「そもそも、なぜチームが必要なのか?」という問いから始めました。
例えば「課題解決力とイノベーションを起こす確率の向上」は理由として分かりやすいと思います。シンプルなタスクならチームの重要性はそれほど感じ取れませんが、頭脳労働の場合、チームメンバー間で刺激を受け合いながら多角度から物事を分析することで仕事の効率が上がるはずです。
もう1つは「モチベーションの保持」でしょうか。人間は集団で生活する生き物ですから、本能的にコミュニケーションを必要としています。そのため、チームづくりはメンバーのモチベーションの保持にもつながります。よく言われるピアプレッシャーは、語感からネガティブな意味に聞こえてしまいがちですが、周りの存在によって個々人が成長するというポジティブな側面もあると思います。
ここまで考えると「では、全員が1つの大きなチームに所属すればいいのでは?」という別の問いが生まれます。しかし、その場合はチーム内のコミュニケーションの負荷が爆増するという課題が生じるので、それを回避するためにチームを適正サイズに分割する必要性が出てくるというロジックです。ちなみに、チームサイズは7人前後が最適という研究もあるので、プロダクトチームではそういった文献も参考にしながら組織体制を設計しました。
— どのように分割するのかを考えるのもまた難しそうですね。
そうですね。我々は、いくつかのメソドロジーを用いてフレームワークをつくり、それをベースに組織設計をしました。その際に大切にした思想は「価値のデリバリー」「システム思想の反映」「決定権の委譲」です。
ビジネスの世界ではバリューチェーンという考え方があるので、どんな組織設計だとユーザーへのバリューデリバリーが素早く正確にできるのかという問いからチームづくりを考えていきました。それが1つ目の「価値のデリバリー」です。
2つ目の「システム思想の反映」は、例えばAPIのような考え方をチームづくりにも適用させましょうというものです。チームAとチームBはいかにコミュニケーションを取るべきか、その担当分野はどのように設計すると効率がよいか、そういった観点から逆算してあるべき体制を考えていきました。
3つ目の「決定権の委譲」については先ほどお伝えした通りですね。
— なるほど。特に組織内のコミュニケーションは永遠の課題ですが、現在ヘンリーではどういった試行錯誤が行われているのでしょうか。
たしかにチームが成長して関わる人数が増えることによって、コミュニケーションの問題はどうしても出てきますよね。
それらは「ツール」「同期コミュニケーション」「非同期コミュニケーション」という側面から捉えることができると思います。例えば、社内wikiが立ち上がり情報が各所に散らばる、定例ミーティングが爆増する、メールやメッセージなどの情報がオーバーロードするなど、経験がある方も多いのではないでしょうか。そこで私たちは、必要なときに必要な情報を得られる、不必要なときに不必要な情報に邪魔されないよう工夫しています。
特にミーティングのような同期コミュニケーションは、バリューストリームが太くなるにつれてやりとりのボリュームが増えていきがち。エンジニアの作業時間が減ってしまうことに加えて、ミーティング自体の質低下を招くこともあります。そこでヘンリーでは、非同期でよいものは後ほどキャッチアップできるように、ミーティングの議事録の公開や録画推奨の文化があります。他にも、開発側は極力水曜日にミーティングを寄せて、他の日は作業時間メインにできるように工夫しています。
チームメンバーに決定権を委譲する理由
— 「決定権の委譲」についてもう少しお聞きしたいのですが、それはどういった背景から大切にしているのでしょうか?
現場に決定権を委譲したほうが、ROI(Return On Investment)におけるリターンの部分が大きくなるだろう、というのが基本的な考え方です。仕事の効率化はROIの向上で測れると思っています。リターンをできるだけ増やして、インベストメントをできるだけ減らすというものです。
なぜチームメンバーに決定権を委譲するとリターンが大きくなるのかというと、時代の流れと関係があります。大量生産時代は、基本的に現場はあまり頭を働かせる必要がなかったと思います。設計図が用意されていて、それを製造するという世界です。ただそういった考え方は、ソフトウェアエンジニアリングの世界では通用しなくなっています。現場の方が様々な事情を知っているので、ずいぶん以前から「現場主義」という言葉も出てきています。
ソフトウェアエンジニアリングの界隈で参考にしているのは実はトヨタ生産方式なんです。トヨタ生産方式の一例として、トヨタの現場の人には大きな権限が与えられており、製造ラインで不良品が出たときに、それを見つけた人がべルを鳴らせばラインを止めることができるそうです。学術的な研究でも現場判断が正しいケースが多いという結果もたくさんありますね。
— 反対に、張さんがチームビルディングにおいて難しさを感じている部分はありますか?
いっぱいあります。まだまだ経験が足りずに迷うことばかりです。直近では「Henry」の病院機能を開発していますが、プロダクトの仕様を決めることにどのくらいの時間を割くのか、ものづくりの時間を圧迫せずにどう進めていくとよいのか、といったことも試行錯誤の毎日です。
基幹システムであるERP(Enterprise Resources Planning)の界隈では仕様をきっちり決めた方が最終的に工数は少なくなるという考え方があるとお聞きしました。メンバーはWEB系出身が比較的多いため、このあたりのバランス感覚も私たちがこれから学んでいきたいところですね。
まずは、意思決定に至るコンテキストまで含めてドキュメントに記録として残すことからはじめています。例えば、3年後にそのドキュメントを振り返ったときに、このときはこういう判断をしてこの結果になったということが分かると、意思決定の参考になると思います。そうやって学び続けながら、自分たちの知見を深めていきたいです。
学びながら変化を続ける組織で一緒に成長したい
— 張さんから見たヘンリーのチームの魅力を教えてください。
実はヘンリーへ入社する際に「ストレングスファインダー」という資質診断を受けてもらっています。そして今の社内平均1位は「学習欲」なのです。まさにヘンリーは「学習する組織」としての伸びしろがあると以前から感じています。
例えば先日、ソフトウェアエンジニアのチーム内でテストライブラリの勉強会があったのですが、そこで紹介された機能を活かしたリファクタリングのPull Requestをメンバーがその日に作成し、コードベースにマージされていました。もちろん誰かが命じたわけではなく、主体的に動いてチーム全体にもポジティブな影響を与えていました。「実践までが勉強会」と話すメンバーもいました。まさにPDCAを高速で回して、学習し続ける組織を象徴しているような1つのエピソードだと思います。
学習する組織だからこそ、組織の成長に繋がり、組織の成長がプロダクトや事業の成長に繋がります。環境の成長が個人の成長に繋がり、個人の成長がまた環境の成長に繋がる、そういうイメージを持っています。
— ありがとうございます!それでは最後にどういった人と一緒に働きたいか、メッセージをお願いします!
ヘンリーのミッションやカルチャーに共感して、本気で社会課題を解決し続けたい方と一緒に働きたいです。
お伝えした通り、学びながら進化を続けている組織なので、ここまでお話した具体的な戦術も、コンテキストが変わればどこかで変わる可能性は十分あります。いまジョインしていただくと、組織がどんなコンテキストに直面したときにどういう判断をして、それがいかなる結果に繋がるのかという知見が日々たくさん得られるので、今後のご自身のキャリアや人生にも活かしていけるのではないかと思っています。ぜひ一緒に成長していけるとうれしいです。
インタビュー:中田 達大
ヘンリーでは、さらなる成長に向けて採用も積極的に行っています。ご興味をお持ちいただけた方は、ぜひお気軽にご連絡ください。