PoC実践～新サービス企画における部門間のギャップを解消～｜2022年 | DXブログ

国内大手企業のお客様の新サービス企画・開発をご支援しているシステムコンサルタントから、大手企業のような分業組織で新規サービス企画の初期段階に生じる「部門間のギャップ解消」に焦点を当てたPoCの実践についてお届けします。
特に新サービス企画の初期フェーズで、どのようにサービスを具体化していくべきか、でお悩みの方に実践頂きたいアプローチです。

執筆者プロフィール

矢倉健一郎：
2009年NRIに入社。
インフラエンジニア・プロジェクトマネージャとして証券会社向けのシステム基盤のアーキテクチャ設計・開発・運用を中心とした様々なプロジェクトを経験。
2015年より、コンサルタントとしてビッグデータ、AI、IoTなどを活用したシステム化構想、デジタルトランスフォーメーション組織立ち上げ等に従事。

はじめに
分業組織で起こる新サービス開発の
代表的な問題

解決に向けた最初の一歩
としてのPoC
逃げてはならないこと
おわりに

はじめに

新サービス企画において多くの企業が取り入れている方法論としてアジャイル・スクラムがあります。これは、多彩な資質や能力を持つ人材がチームを結成して、互いを補い合いながらサービスを作り上げるやり方です。ただし、専任チームを構成できるのは一握りの企業です。特に、大企業では新サービス専任チームを組成するのは難しく、現業を持つ複数の部署から人を集めることが多いのが現実です。そのため大企業では、メンバーは別々の組織に所属しながら新サービス開発を行うことになり、どうしても部門間の確執が生じやすくなります。今回は、そうした部門間の課題を解消するための解決策の１つとして、企画初期段階でのPoC実施を提案します。

分業組織で起こる新サービス開発の代表的な問題

あなたの会社では、新しい事業やサービスを開発する際に、どのような流れで進めているでしょうか。大企業であれば、ビジネス部門が企画したものをIT部門に持ち込み、サービスに必要なシステムを設計・開発してもらうという流れではないでしょうか。
その場合、ビジネス部門は顧客層、提供価値、競争優位性、ビジネスモデルなどを決め、IT部門はそれらをもとに、要件定義、設計、開発を行うといった役割分担となるでしょう。
このようなビジネス部門とIT部門との分業体制でサービス開発を進めている企業では、次のような問題が頻繁に起こっています。

ビジネス部門

「企画が完成して承認も得ているのに、IT部門がなかなか動いてくれない」

IT部門

「企画書の内容がふわっとしていて、何を作りたいのか分からない」

「技術的に実現不可能な企画になっている」

結果として、企画フェーズから開発フェーズに移行できず、新サービスのプロジェクトがとん挫してしまうといったことは起こっていないでしょうか。このようなことが続くと、ビジネス部門とIT部門の関係が悪化し、コミュニケーションを取らなくなってしまい、複数のサービスで企画・開発のスピードが落ちる、案件が進まない、ということが頻発することになります。

このようなケースは、なぜ発生するのでしょうか。ビジネス部門、IT部門、どちらかに非があるのでしょうか。

実は、どちらかが悪いということではなく、「サービス開発に必要な情報の欠落」や「技術的な実現性・難易度に関するすれ違い」が、原因になっていることが多いといえます。そして、相手が普段取り組んでいる業務内容・範囲や考え方を知らないために、その問題は認識されづらく、認識できたとしても簡単には解決できないのです。

解決に向けた最初の一歩としてのPoC

あなたの会社がこのような状況にあるならぜひ試して頂きたい有効な進め方があります。それは、「企画段階でのライトなPoCの実践」です。これを通して「サービス開発に必要な情報の欠落」や「技術的な実現性・難易度に関するすれ違い」を両者が認識し、不足していた情報を両者が納得できる方法で入手・共有することができます。具体的には次のような進め方となります。

初期のサービス構想で一番重要な部分だけを具体化する

企画を検討する際、一番コアとなる部分は何かを考えてみましょう。まずは全部を具体化できなくても、重要な部分だけを考えれば大丈夫です。一番重要な部分は「この企画ならでは」が詰まった場所です。サービス構想は、基本的にはビジネス部門の役割ですが、可能ならビジネス部門とIT部門が話し合いながら作るのもよいでしょう。
手書きの絵でもワードの文書でもパワーポイントで作った画面イメージでもなんでもよいので、一番重要な部分が何かが分かるように書き出します（書き出したものを企画書Aとします）。

IT部門で実際にモノづくりをする

IT部門は、企画書Aを受け取ったら、出来る範囲でモノづくりをしてみましょう。一番重要な部分に限り、開発してみてください。
開発を始めると、その企画書には書かれていない困りごとが出てきます。それは、ビジネス部門に問い合わせみても、「考えていなかった」、「決められない」といった困った状態になるものです。これがいわゆる「簡単には埋められない情報の欠落」です。この時点では検討事項として記録しつつ、仮で決めた上で開発を進めましょう。
また、開発過程で企画書通りに実装できない機能、もしくは実装できそうではあるがとても時間がかかる機能が出てくる場合もあるでしょう。これが「技術的な実現性・難易度に関するすれ違い」です。適したライブラリが存在しない、AIの精度が出ない、など、時間をかければ解決できるものかもしれません。ですが、この時点では時間をかけず、最も似た機能、と思える範囲で開発するにとどめましょう。

ビジネス部門とIT部門で期待とのギャップを確認する

開発した結果を両部門で確認し、期待したものとのギャップや、実現できなかったことの共有を行います。
例えば、次のようなものがでてくるでしょう。

ギャップ　例）

期待したほど魅力的な機能になっておらず、どこかで見たようなサービスになっている
最新のAIに期待したが、思ったような結果が出てこない
想像以上にコストがかかる試算になり、収支が見合いそうにない

これらのギャップについて、次のような観点で確認し両部門で対応を相談するとよいでしょう。

確認観点

1.

ギャップは、企画書Aに記載されていない「簡単には埋められない情報の欠落」に起因するか
2.

ギャップは、企画書Aの記載通り実現できなかった「技術的な実現性・難易度に関するすれ違い」に起因するか
3.

ギャップは、企画書Aへの記載不足でIT部門が独自に開発したことに起因するか

ギャップが1の場合は、企画の重要な部分に関して具体化がなされていない、または決断できていないということが分かります。このような事項を具体化するのはビジネス部門の役割でしょう。
2の場合は、夢のような企画ですが残念ながら技術的には実現できない可能性があるのかもしれません。これに関しては技術的な調査をすることも必要ですが、今できるレベル感でサービスが成立する方法を考え直す方が重要かもしれません。
3の場合は、コミュニケーションギャップが発生しています。なぜこの実装にしたか、どこが想定した企画と異なるのかを共有することで、今までの企画以上のものに変えられる可能性があるかもしれません。

「企画段階でのライトなPoCの実践」を通して得られる気づき

この早期に部分的に実装して確認するPoCを実践することで次のような点に気づくことができます。

決めなくては進めない事項・具体化すべき検討事項
実現可能なライン（技術的に実現できるレベル感）
双方の持つゴールイメージのギャップ

また副次的な効果として、チーム感が生まれ、協力が進み、結果的に検討が進捗することも期待されます。

逃げてはならないこと

上記のように作りながらギャップを埋めていくことで、企画は徐々に具体化していくでしょう。具体化できた段階で通常の分担に戻してもよいと思います。ここでは、こうした活動を行う上で逃げずに取り組むべきことをお伝えします。

決めるべきことは決める、仮でも決める

「今はまだ決められない」「難しい問題だ」と言って判断を先延ばしにしては検討が具体化できません。特にそれが企画において一番重要な部分と考えるのであれば、今時点で仮でもよいので決めることを検討してください。決められないものは重要ではないことと割り切れるかを検討してください。今決めなくては進めないことであれば、まず決めて作り、その結果を見て仮決めした部分を見直しましょう。状況が変わるなら、後で作り直せばよい。決めるのはビジネス部門の役割です。

絶対必要、絶対無理の戦い

新サービスでは、絶対譲れない差別化ポイントや機能があります。一方、技術者から見ると、「絶対実現できない」という部分が存在します。それらを、「ここまでならできる」、「そこまでできれば十分」、と納得できるまで試しながら確認することが重要です。「絶対必要」「絶対無理」で論争するのではなく、現実的な実現レベルを考えた上でサービスに足るか議論しましょう。IT部門の技術力がないことを理由とせず、今ある範囲・できる範囲で実現したいサービスに対してどの程度効果を発揮できるかを、十分に議論することが必要です。どこまでなら実現できるかを示すのはIT部門の役割になります。

おわりに

いかがでしょうか。今回は、新規サービス開発において起こりがちな問題である「ビジネス部門とIT部門の確執」に焦点をあて、企画初期の段階でPoCを実践するための企画の具体化と検証アプローチをご紹介しました。
ビックデータを活用するサービスやDXと言われる領域で、今回のアプローチが特に効果的だと感じております。こうした領域では、ユーザーが求めるものは変化しつづけています。ユーザーの利用方法やユーザー属性によって提供情報が異なるサービスでは、実際に開発してみると企画時には想像しきれない結果が出ることが多いため、今回のアプローチは有効です。是非お試しいただければと思います。

DXブログ一覧ページへ

システムコンサルティングトップページへ

執筆者情報

矢倉健一郎

TMプロジェクト部

上級システムコンサルタント

フリーワード検索

PoC実践