ビジネスの価値創造にむけて自走する組織が持つ三要素
SIerとして、多くの企業のシステムインテグレーションやアウトソーシングなどを手掛けるTIS。髙谷氏が所属する新規事業開発チームでは、名前の通り「TISで新規事業を成功させる」ことをミッションとし、社内で生まれてきた新しいビジネス・事業に対し、エンジニアリングを提供している。
しかし、TISは基本的に受託型の事業を展開してきたこともあり、「新しい価値を生み出す」よりも、「確定したものを早く安く正確につくる」ことに主眼が置かれてきた。そこで、新規事業開発に取り組むにあたり、まずは「マインド」を変える必要があった。そして、新規事業についてスピーディーに手続きを行うためSI前提だった「手続き」を変えること、さらにジュニアエンジニアも含めた「チーム編成」によって、学習・成長を支えながら開発のミッションに挑む必要があった。
そうした課題の一方、各ジャンルの専門家から技術面やビジネス・法務面で大きなサポートと知見を得られ、既存顧客との関係を活かした事業開発の可能性が考えられることなど、TISは大規模な会社ゆえの「強み」も有している。社内手続きも必ずしも硬直しているわけではなく、新規事業開発の実態や課題感を社内に共有することで変えられる余地はあり、髙谷氏のチームでも働きかけを積極的に行っているという。
そうした新規事業チーム内では、「ビジネスの価値づくりに向かって自走する状態」を実現するために必要なものについて話し合い、次の三要素が重要という結論に至った。
①ビジネスの理解と責任
自分たちが作ろうとしているもののビジネスへの「貢献性・価値」を理解した上で、何をどうプロダクトに落とし込めば実現できるか理解ができており、実際に開発に落とし込む責任を認識し、実行できること。
②状態・課題の透明性
チーム内はもちろん、プロダクトオーナーやビジネスオーナーなどステークホルダーとコミュニケーションを行い、ビジネス／・プロダクトの知識・状態・課題を明確に共有する。それによって、課題解決ができる人が問題を検知し、解決に向けたアクションや決定を下したり、状態に応じて協力体制を整えたりすることができる。
③主体的な問題解決ができること
各メンバーが役割や能力に応じてリーダーシップを発揮し、チーム全体で開発の課題に対処する状態。“自走する”上での重要ポイントとなる。
この3つの要素を踏まえ、さまざまな取り組みを実施し、現在は徐々に自走できる形になりつつあるという。その取り組みの1つとして「エンジニアがプロダクトオーナーを務める」までの経緯について紹介された。
エンジニアがプロダクトオーナーに！？ 新開発体制でコミュニケーションがスムーズに
もともとの開発体制は、市場を調査・理解して事業の戦略を立案する「事業オーナー」がプロダクトオーナーを務めていた。どちらかといえば、営業・ビジネスサイド寄りであり、背景には「プロダクト価値の最大化は事業オーナーにしか担えない」という“無意識”に抱いていた前提があったという。しかしながら、オーナーとエンジニアの間に齟齬が生じ、分断が深まることとなる。その理由について、髙谷氏は3つの課題があったと語る。
1）スクラムに関する理解の壁
ビジネス側ではスクラム開発に馴染みがなく、学ぶことから始まった。しかし、プロダクトバックログから開発チームに伝えるべきことについての理解がなかなか進まず、たとえばアイテムの目的や背景についてシステムに落とし込める“粒度感”や、PBIの受け入れ条件についての内容や確度など、習熟には時間がかかるものも多かった。
2）システム開発に関する基本知識の壁
稼働率や不正データの際のシステムの挙動など、システムの細かい判断について、開発チームがプロダクトオーナーに求めても十分な対応が難しかった。
3）事業オーナー／POに求めるものが多すぎる
事業オーナーへの要望が多く、細かな事項に忙殺されるようになった。事業戦略など、本来担うべき重要なミッションに関わる時間が圧迫され始めた。
その結果、プロダクトオーナーである事業オーナーとエンジニアのコミュニケーションがうまく取れず、理想とする「ビジネスの理解と責任」および「状態・課題の透明性」が担保できない状態になってきたことから、「エンジニア側がプロダクトオーナーを担う」判断がなされた。
しかしながら、エンジニアがプロダクトオーナーを担うとなれば、事業オーナーはエンジニア側のプロダクトオーナーを信頼し、仕様の最終決定権を委ねる覚悟を決める必要がある。プロダクトオーナーを担ったエンジニア側も、ビジネス知識やニーズを把握して、ビジネスにかなう仕様を生み出すことに集中する必要がある。そこで、エンジニアと兼業とせず、専業とすることとなった。
エンジニアがプロダクトオーナーになることで、開発チーム側にとってのメリットとしては、まず「データモデル設計について開発者とコミュニケーションできるようになったこと」があるという。
髙谷氏は「ビジネスを言語化・モデル化したデータモデル上で、システムについてコミュニケーションが取れるようになると、ビジネスプロセスやビジネス内で登場するイベントの構造や関係でも認識齟齬を大きく減らせる感触があった。また、ビジネス活動のうち、どのような履歴を残せば今後も活用できるのか、プロダクトオーナーと目線が合わせられるのはよかった」と語る。
そして、髙谷氏は2つめに良かったこととして、「要求→要件の過程で認識の齟齬が生まれなくなってきたこと」をあげる。プロダクトオーナーが、ビジネスの要求を伝えることと、その要求を叶えるためのシステム要件を定義・決定する人物が同一人物になったことで、システムの要件をしっかりと把握し定義できるようになった。
そして3つめには、「仕様に関するコミュニケーションで非エンジニアのための翻訳が不要になる」ことが大きかったという。技術的な問題点やサービスの選定などで、細かな説明やコンテキストのすり合わせをせずともダイレクトに通じるようになった。
