電通総研 テックブログ

電通総研が運営する技術ブログ

初めての案件でPoCをやって学んだこと3選

皆さんこんにちは。製造ソリューション事業部の長坂です。 この記事は、電通国際情報サービス Advent Calendar 2021の8日目の記事になります。昨日の記事は、福竹さんの「ふりかえり入門した、ふりかえり」でした。こちらもぜひご覧ください。 本日は、私がISIDに入社して初めて担当した案件から学んだことについて、自身の振り返りの意味も込めてご紹介したいと思います。

はじめに

長坂自身の紹介

  • 社会人歴:2年目
  • 担当ソリューション:自社製品の導入・維持保守・プラグイン開発など。 基本的には、ソフトウェア開発ではなく、どちらかというと導入側メインで携わっている人間です。なので、業務上コードを書いたりすることはほとんどないのが現状です。

担当した案件の紹介

今回、とあるプラグイン製品のPoCを実施しました。 PoC(Proof of Concept:概念実証)とは、新しいアイデアやコンセプトを実際に小規模で運用することで、実現可能性や得られる効果などについて検証する手法です。

通常のPoCでは、以下のプロセスで実施していくと考えています。

  1. 顧客の課題をヒアリング
  2. 課題に対応する提案を実施
  3. プロトタイプ開発
  4. ユーザーによる効果検証
  5. 3,4を繰り返す

しかし、今回以下のようなプロセスをとりました。

  1. とある研究結果からコンセプト立案し、製品を開発
  2. 上記のコンセプトを情シス部門に提案
  3. 協力していただく現場ユーザーを探す
  4. 現場ユーザーによる効果検証
  5. 検証結果を製品開発にフィードバック

プロセスは違えど、PoC、または製品を導入するにあたって共通することを自分の学びとして記載しています。

結果、お客様での導入には至りませんでしたが、製品に対するフィードバックを得られました。そのため、PoCを実施した意義はあったと考えています。

というわけで、早速学んだことについてご紹介します。

その1 ユーザーのユースケースをしっかり把握し、使い方を提案しよう!

PoCに手を挙げてくださったユーザー全員が、積極的に参加するとは限りません。 今回のPoCでは、一時期は1人しか使っていただけない時期もあり、どうしたら使ってもらえるのか相当悩みました。 なぜ使っていないのかユーザーへヒアリングした結果、「使う場面がユーザー側も良く分かっていない」ことが、原因ということが分かりました。 ユースケースを考え、実行するのはユーザーの役割かもしれませんが、使い方のヒントをユーザーに渡すのは導入エンジニア側の役割です。 ただ機能の説明をするのではなく、ユーザーが現在置かれた状況(仕事のやり方)を把握し、

  • 今ある課題を解決する方法
  • 課題ベースにとどまらず、新たなユースケースを提案

していくことが必要です。 ユーザーの仕事のやり方を把握するためには、 - どれくらいの頻度で関係する情報を得る・更新するのか - 誰と情報を共有して仕事を進めるのか - 情報を得る・更新するのに二重で実施していることはないか このあたりを意識すると、良いユースケースを考案するカギとなると思っています。

また、ちゃんと筋の通った提案をしても、ユーザーに刺さらないことがよくあります。 100発打って1発当たればいいや、という気持ちで、思いつく限り使い方を提案しましょう。

その2 「導入すること」が成功と思わない!

ビジネスにおける最初のゴールは、お客様に製品を導入してもらうことです。 ※その先にシステムの維持管理や継続して使ってもらうための努力は必要ですが、いったん置いておきます。 しかし、今回のPoCでは「自分の中のゴール=ビジネスのゴール」としてしまい、大変な思いをしました。

PoCのゴールは、「機能やユースケースが顧客の使い方にマッチしているか確かめること」です。 導入には至らなくても、製品改善のフィードバックを得るだけでそれは導入してもらうためのステップを着実に踏んでいることになります。

自分の中のゴール=何か身になる学びを得る」としたほうが良いでしょう。

その3 ユーザーへの会話は積極的に仕掛けよう!

その1にもつながる話ですが、ユースケースを知っているのも改善のフィードバックを得るのも、情報を持っているのはすべて使ってもらうユーザーです。 ユーザーに話を聞くことで、自分が今まで分からなかったことが分かります。またはそのヒントを得られます。 「何か一つでも情報が得られれば」と思いながら質問や情報共有、提案などをしていくことが大切です。 理由や聞きたいこともなく会話を仕掛けるのは、相手の時間を無駄にするのでよくありません。事前にポイントを整理しておきましょう。

上記はビジネスの基本ですが、PoCにおいてももちろん当てはまります。 特にPoCでは、「学びが多ければ多いほど良い」と考えているので、「積極的にユーザーに話を聞きに行く」ことが大切だと学びました。

まとめ

今回は、初めて担当した案件でPoCを通じて学んだことを3つお伝えしました。ベテランエンジニアの方にはすべて当たり前と感じられるかもしれませんが、私にとってはすべてが新鮮な学びでした。 初めてながら主担当で実施した案件だったため、色々と大変な思いをしましたが、振り返ると自分が成長する良い機会になったと思います。

テクニカルな話題が多い中で、少し異色のテックブログとなりましたが、いかがでしたか? 明日の記事は、米谷さんの「データ分析基盤/DataOpsに関する何か」です。お楽しみに!

執筆:@nagasaka.takuro、レビュー:@sato.taichiShodoで執筆されました