解決すべき課題を特定する
enoはじめに
Belong Inc.で DataPlatform チームや社内の在庫管理システムのマネジメントを担当している eno です。
Belong には日々数多くの中古携帯端末が様々なチャネルから入荷され、検品したのちに様々なチャネルで販売・レンタルの形で提供しています。こういった様々な調達・販売方法に対応するよう在庫管理システムを内製し、円滑なオペレーションを実現するために日々開発を行っています。
Belong は当初は仕入れた端末を検品し、にこスマで販売する形でしたが、ここ数年で大幅に調達・販売方法が多様化したこともあり、ビジネスを実現するためのオペレーションも大きく変化してきました。 ビジネスの変化に伴い、既存のオペレーションは変化を求められます。その過程で現状ではどうしても対応が難しい工程が新たに発生したり、既存のオペレーションと整合性をとるために追加業務が発生するケースも出てきました。作業工程が多様化・複雑化したオペレーションにおいては、そもそも課題が何なのかを把握することが容易ではなくなってきます。
どれだけ高度なエンジニアリング能力を持っていたとしても、その能力を発揮し解決する課題の設定を誤ると、価値を生み出さない作業になります。そればかりか、単にオペレーションを複雑化させただけ、という結果にさえなりえます。 Belong の Engineering では "正しいものを正しく作る" というスローガンを掲げており、エンジニアをマネジメントする立場として、解決すべき課題を正しく捉えることに最も多くの時間を割くようにしています。
今回は、ビジネスとそれに伴うオペレーションについて、どのように解像度を上げ、課題を特定していくのか、その大まかな考え方について私見を述べてみます。
「顧客が本当に必要だったもの」
ミームとしてしばしば引用される「顧客が本当に必要だったもの1」は、システム開発に携わったものなら誰でも、程度の差はあれ身につまされるものかと思います。
私は自身で創業した事業を譲渡する形で Belong に参画したのですが、自分でプロダクトを開発し、お客様にセールスしていた時期に「顧客自身も自分の抱えている課題を正確に認識していないことがある」ということを何度も痛感しました。 顧客やユーザーが話してくれる要望・課題は、その発言の背景を理解した結果、全く違うものが根本的な課題だったということは少なくありません。とはいえ「御社の根本的な課題は何ですか？」などと不躾に質問しても、具体的なフィードバックはなかなか得られません。
そのため顧客の根本的な課題を理解するため、どのように話を聞けばよいか、何度も試行錯誤するようになりました。書籍などで顧客ヒアリングの方法論は様々紹介されていますが、私個人としては比較的シンプルなフレームワークである SPIN 話法2を好んで使っています。
適切な質問をすることで課題を明らかにする
SPIN 話法は顧客の抱える課題を引き出すためのフレームワークで、主に B2B 営業における商談成功のための話し方の枠組みとして整理されたものですが、顧客・ユーザーの潜在的なニーズを明らかにするという点で、営業のシーンに限らず汎用性のあるものだと考えています。以下の通り、顧客・ユーザーにヒアリングする際の質問のタイプを分類し、その質問をする順序を示したものです。
| S - Situation | 状況質問 | 顧客の現状について確認するための質問 |
| P - Problem | 問題質問 | 顧客が抱えている課題を引き出すための質問 |
| I - Implication | 示唆質問 | 課題を解決する必要性に、気づいてもらうための質問 |
| N - Need-payoff | 解決質問 | 顧客を解決策に導き、その解決策に積極的な関心を持ってもらうための質問 |
例えば製造工場のオペレーションの課題を特定するケースを考えてみましょう。その場合は
- 現在のビジネスの状況がどうなっているのかを説明したうえで、それに伴う現状のオペレーションがどうなっているのかを確認し、
- 確認したうえでそこに潜んでいる問題について投げかけ、
- その問題が解決されるとどういう outcome があるかについて認識してもらい、
- 問題解決への関心を高めてもらう。
という流れで、製造現場のスタッフとミーティングを進めていくことになるかと思います。実際には質問をしていく過程で前提となる現状のオペレーションについての認識齟齬があったり、問題だと認識している部分が異なったりすることが多々ありますので、SPIN を使ったヒアリングを繰り返すことで、課題の解像度を上げていくことになります。
仮説を必ず準備する
SPIN は適切な質問をするための枠組みですが、顧客・ユーザーにオープンクエスチョンを投げるようでは、なかなか具体的な話に至らないことが多いと思います。そのためできるだけ具体的な質問ができるよう、予習をしておくことが望ましいです。 例えば社内のオペレーション改善であれば、社外の顧客へのヒアリングとは異なり、事前に Situation(状況質問)については社内資料などで調査のうえ準備できるはずです。予め調査しておいて、現状認識に齟齬がないか確認する程度の質問に留めるべきでしょう。Problem(問題質問)以降の部分に時間を多く割くべきだと思います。
特に日々現場でオペレーションに関わっているわけではないエンジニアが事前の予習なしにヒアリングを行っても、Situation(状況質問)にほとんどの時間を費やしてしまい、オペレーションの現状について現場スタッフからレクチャーを受けるだけで終わってしまうことが想定されます。論点である「何が課題か」について話をする時間がほとんどとれなかったという結果になりがちです。
課題に対する納得感の醸成
また SPIN のミソは、単に課題を特定するという点だけでなく、その課題を顧客・ユーザーに自分事として認識してもらい、それを解決する価値があると納得してもらうことです。 ビジネスのオペレーションは、ソフトウェアだけで完結することはありません。それを利用するスタッフや、また EC であればデータベース上の在庫情報と、実際の商品在庫の実体をどう連動させるかなど、複数の構成要素を組み合わせて実現されています。 そのため課題を解決するためにソフトウェアがやるべき部分、スタッフの業務手順を変えるべき部分などを峻別する必要があります。SPIN を通じてどれだけ自分たちにとってこの課題を解決することに価値があるのかを感じてもらえないと、望ましいオペレーションのためにスタッフの行動を変えてもらうのに苦労することになります。
関係者に解決の機運を高めてもらうことも、ヒアリングの重要な目的となります。
言語化していつでも見られるように
多様な工程が絡み合う複雑なオペレーションの場合は、このようにヒアリングを経て特定した課題も、解決策に取り組む過程で頭から全体像が抜け落ちることがしばしばです。なので得られた情報はできるだけ言語化し、文書としていつでも参照できるようにしておくべきでしょう。エンジニアなら、タスク管理ツールのチケット毎に、取り組むタスクの背景として書いておくべきものになると思います。課題の解決策の方向性に議論の余地がでてきたら、すぐそもそもの目的として何の課題を解決しようとしているのかをその文書で参照できるようになっていれば、ゴールを見失わずにすみます。
おわりに
以上から、オペレーションの現場から何かしらの要望が挙がったら、ざっくり以下の順番で課題の特定を進めるようにしています。
- どの事業のどのようなオペレーションか、まずオペレーションの全体の流れを把握する
- 把握した内容をドキュメントにする
- オペレーションの全体の流れと現場から挙がってきた要望を照らし合わせ、現場の課題について仮説を構築し、ドキュメントに追記する
- 関係者を集めて SPIN を参考にしたヒアリングを行う
- 4 の結果オペレーションの認識齟齬や課題仮説の修正が必要になった場合は、ドキュメントを更新したうえで、改めて 4 を行う。課題の解像度が上がり、関係者に納得してもらうまでこれを繰り返す
- 解決すべき課題が明確になったら、どのように解決するかを考える
システム開発の本質的な困難さは、関係者の意思疎通にあると考えています。今回は価値のあるコードを書くためのコミュニケーションの方法として、私がふだん意識していることについて書いてみました。
人の役に立つコードを書く、課題解決に直結するコードを書くことに関心のある方は、是非一度カジュアル面談でお会いしましょう！
Footnotes
-
参考：日経 XTECH「50 年間使われ続ける、あの有名な「木にブランコ」の絵を最初に描いた親子」 ↩