見出し画像

何でも屋のネクストキャリアに推したい「ビジネスアーキテクト」とは?

こんにちは。Ubieの花谷(@kotarohanaya)です。約2年前にUbieに入社し、現在は製薬事業の組織 ”Ubie Pharma Innovation(以下、UPI)” にて”Bussiness Architect”(ビジネスアーキテクト)として、ビジネスプロセスの型化や改善を行っています。

UPIは設立から1年半ほどですが、取引実績は既にグローバルメガファーマ(売上高が1兆円以上の製薬企業)の半数以上に広がり、40名近くの組織規模となっています。

一方、「製薬企業と共に業界を変革し治療機会を最大化する」という大きなミッションの実現に対しては、一歩目を踏み始めたばかりで、これからが本番です。

成長のギアを一段上げて、飛躍を目指していくフェーズのUPIにおいて、今まさに向き合っている重要な組織イシューがあります。

  • 今後100名超の組織規模になっても通用するビジネスプロセスをいかに整備するか

  • 組織としてのスケーラビリティをどう担保するか(メンバーが増えれば増えるほど、組織全体の出力も上がる状態にする)

このようなイシューに正面から向き合い、課題の深掘りから解決に向けた打ち手までをリードしていく役割が、UPIの”ビジネスアーキテクト”です。

今回は、このビジネスアーキテクトについて、UPIでの役割、具体的な取り組みや面白さをご紹介できればと思います。

そもそもビジネスアーキテクトってどんな役割?

あまり聞き馴染みが無いポジション名かもしれませんが、UPIでのビジネスアーキテクトのミッションを一言で表現すると以下のようになります。

組織全体の生産性向上を通して、Ubie製薬事業の急成長を支え、治療機会の最大化に貢献する

立ち位置としては、製薬企業とのフロントで提案やデリバリーを行う営業や事業開発(いわゆるBiz)と、会社の屋台骨となるコーポレートやバックオフィスのメンバーとの「中間」になります。「組織の潤滑油」という表現も近いかもしれません(自らハードルを上げるスタイル)。

実際の動きとしては、ビジネスアーキテクト自身が特定のプロセスのオペレーションを担うこともあれば、業務を型化した上で、他のオペレーションが得意なメンバーに移管することもあります。

あくまでも、全体最適の視点で、組織の状況に応じて、自らの役割自体も柔軟に変えつつ、その時々のベストなオペレーションの形や体制を「設計」することが重要な役割です。

ちなみに「ビジネスアーキテクト」というネーミングを取り入れたのは、書籍『ビジネスプロセスの教科書』で、ビジネスプロセスの専門家として紹介されていたことがきっかけです。著者の以下の記事にも解説されています。

ビジネスアーキテクチャではまず業務や各業務のKPI、情報システム、情報、組織といった事業体が内包する構成要素を可視化します。そして長期的なビジョン(=これが“戦略“です)を達成するために、その各要素のどこをどのように変えなくてはいけないのかを識別します。変化させなくてはいけない要素が見えたら、それらを作り変えるための活動(=プロジェクト)を識別します。

引用:企業の変革を全体最適で進める役割 「ビジネスアーキテクト」とは(前編)

調べてみると、ビジネスアーキテクトは、SaaS企業を中心に、ビジネス変革を支援する役割として徐々に増えてきているようです。他にも”Biz Ops”と呼ばれるポジションも、Bizと現場のオペレーションをつなぐ役割として近しい概念です。

ビジネスアーキテクトってどんなことをやっているの?

ここからは、具体的に、UPIでのビジネスアーキテクトの取り組みをご紹介していきます。

1) 体制・仕事の進め方
まず前提として、UPIのメンバー全体約40名の内、30名は、製薬企業とのフロントに立ち、Bizとしてソリューション提案やデリバリーを担当しています。

一方、ビジネスアーキテクトは、現在、自分を含めて専任が2名です。加えてBizとの兼任1名と、MO(ミドルオフィス/販売管理)兼務1名の計4名で1つのチームとなり、ビジネスプロセスの型化や改善を行っています。

デイリースクラムの様子

限られた人数の中で、チームメンバー自身も生産性高くアウトプットを生み出せるよう、チーム運営には、コミュニケーション重視型のソフトウェア開発手法として用いられる「スクラム」を取り入れており、「解決したいテーマ」をベースに役割分担を行っています

参考:スクラムとは

業務プロセスの設計やオペレーション改善は、企業や事業のフェーズによって、時間をかけて作り込む進め方もあると思います。

一方、UPIでは、事業、組織の環境変化が大きく、取り組むべきテーマもその時々で変わってくるため、「早くアウトプットを出して、早く検証する」という動きを重視しています。

そのため、設計段階からすべてを見通すのではなく、少しづつ作って、「検査(作ったもの・作り方を評価)」と「適応(検査に従ってより良いやり方を探索)」を繰り返すという、スクラムの思想を参考にしています。

スクラムでは、PBI(Product Backlog Item)と呼ばれる、解決したいテーマを、1週間以内に解決できるサイズで明文化し、作成します。

PBIのフォーマットは、以下のように設定しています。

・背景(なぜそのテーマに取り組むのか)
・User & Return(そのテーマを解決すると、誰が何を得られるのか)
・AC(どのような条件を満たせば完了か、達成したい状態は何か)
・Dont's(このPBIではやらないこと)
・Do's(このPBIでやりそうなこと)

PBIはチームのメンバーがそれぞれ持ち寄り、週1回のリファインメントと呼ばれるミーティングで、持ち寄ったPBIの詳細化、工数の見積りと優先順位の調整を行ってから着手します。

例として、「Aという業務プロセスを効率化するために、Bというツールを導入したい」という声が挙がった場合に、初手のPBIは「Aという業務プロセスに関係するメンバーとそれぞれの課題の洗い出しが完了している」といった粒度で作成します。

ポイントは、ツール導入という「手段」ありきではなく、解くべき課題は何かから入るという点です。課題を深掘りすると、ツール導入は一つの選択肢ということに気づき、他のより良い選択肢(Aという業務プロセス自体を無くし、Bと統合する)を発見できることもあります。

このようにPBIをチームで作成・詳細化し、優先順位付けを行うことで手戻りが無くなり、生産性を高めることができるようになってきました。

スクラムについては、UPIのマーケティングチームも同じ運営形式を取っており、マーケターの林がnoteで解説しているので、興味がある方はご覧になってみてください。

2)これまでの取り組み
直近は、「人員増に耐えうるビジネスプロセスの整備」「組織のスケーラビリティ担保」といった、冒頭に挙げた組織イシューに対応する取り組みを行っています。

ビジネスプロセスの全体像を可視化してみた

具体的には、このようにUPIのビジネスプロセスの全体像を可視化し、「既に課題が顕在化しているプロセス」と、「潜在的に課題を抱え中長期的に解決が必要なプロセス」をそれぞれ分けて洗い出すところから始めました。

ビジネスプロセス毎に改善の優先順位と時期感を検討

その上で、各プロセスオーナーと連携しながら、優先順位を付け、課題を深掘りした上で、既存のプロセス・仕組みの改善や新規のツール導入など、課題解決に向けた打ち手を実行していきます。

以下は、直近、ビジネスアーキテクトが関わっているプロセスの一部で、領域はその時々の優先度によって様々です。

  • 業績管理会計(パイプライン管理など)の仕組み改善(事業管理プロセス)

  • 情報・ナレッジ共有の仕組み改善(事業管理プロセス)

  • 案件デリバリープロセスの仕組み改善(商談・デリバリープロセス)

  • 契約・請求のオペレーションの型化(商談・デリバリープロセス)

例として、契約・請求のオペレーションにおいては、上流から下流まで、各工程の事務メンバーの作業工数を洗い出す取り組みを行いました。

その結果、業務上のボトルネックの発見と効率化に加え、今後の件数増加を見据えた必要人員数の予測が立ち、リソース確保のアクションを先回りで行えるようになるといった成果が得られています。

ビジネスアーキテクトって面白いの?

ここまで具体例も交えて、ビジネスアーキテクトの取り組みをご紹介してみました。自分自身が感じているこの仕事の面白みを言語化すると、以下のような点があります。

  • 組織の動きを俯瞰し、全体最適の視点で、今解くべき課題を定義した上で、関係者を巻き込み改善活動を推進できる

  • プロセスの型化の過程で、自らオペレーションに入り込む機会もあるため、ビジネスプロセスの上流から下流まで幅広く携わることができる

  • 専門性の高い各領域の優秀なメンバーとフラットに議論し、Trust&Ownershipの精神で、コトを前に進めていくことができる

2022年10月にUPIにジョインした時は、契約や請求業務のオペレーションからスタートし、自分と派遣スタッフの2名体制で、とにかく1件1件、目の前のオペレーションを間違いのないようにこなすのに精一杯でした。

1~2カ月経過して徐々に担当領域のオペレーションの解像度が上がってくる中で、1年後に更に件数のボリュームが増加していく未来を見据え、オペレーションの属人化を減らし、チームとしての運営体制を構築しました。

これがきっかけとなり、UPIのさまざまなメンバーと、各領域のビジネスプロセス上の課題とあるべき姿を議論するようになり、組織全体の動きを俯瞰して課題を見つけに行く役割に徐々にスイッチしてきました。

まだまだ課題は山積ですが、さまざまなメンバーと課題をフラットに議論しながら、よっしゃ!と腕まくりしながら改善を進め、結果の手ごたえをメンバーと分かち合えた瞬間が最高に楽しいです。

何でも屋にぴったりのビジネスアーキテクト

最後に、これまで何でも屋的に組織を支えてきた人にとって、ビジネスアーキテクトという仕事はぴったりという話をさせてください。

個人的な話となりますが、前職は新卒で入社した会社で、1~2年毎にジョブローテがありました。いわば何でも屋的なキャリアで、専門性や軸と呼べるものが無いことに、漠然としたよくある悩みを持っていました。

そんな中、UPIにジョインし、自分の役割をビジネスアーキテクトとして定義したことで、ようやく自分の強みが見えてきました。

UPIメンバーからのフィードバック Trust&Ownership や Full throttle, but Safe についてはこちら

先日UPIで一緒に働くメンバーから、このような全く想定していなかったフィードバックを貰う機会があり、自身の強みの元となった体験を振り返ってみました。

そこで思い浮かんだのは、以下のような場面です。

  • 前職で金融商材を提案する折、お客様のニーズを頭が千切れるほど考え抜いた経験

  • プロマネや広報時代に、様々な立場の関係者とのコミュニケーションをリードし、物事を前に進めた経験

それぞれの異なる場面での「点としての経験」が、「線としての強み」になっていることに気づきました。

ビジネスアーキテクトは前述のとおり、組織全体の生産性を上げることが目的で、その手段として自らはアメーバのように柔軟に動く役割が求められます。

そのため、ビジネスアーキテクトは、これまで何でも屋的に働いてきた人にとって、これまでの点として様々な経験自体が強みとなり、バリューを発揮できるポジションなんじゃないかと思っています。

We are hiring!

ここまでお読みいただきありがとうございました!

ネクストキャリアを考えている、何でも屋さんな方。

この記事では伝えきれない、ビジネスアーキテクトの具体的な仕事、面白さや大変さなど、ぜひお話させてもらえませんか?

詳しくはこちらのサイトからご覧ください。

▼Business Architect(ビジネスアーキテクト)

▼IT Architect
ビジネスアーキテクトとも近いポジションで、主にITツールやシステムの導入・運用を担い、ITの面から組織の生産性向上を担ってくださる方も募集しています。

▼BackOffice / Secretary
急拡大する組織を円滑に運営するために、縁の下の力持ちとして活躍してくださるバックオフィスメンバーも募集しています。


この記事が気に入ったらサポートをしてみませんか?