モノグサでエンジニアリングマネージャー（EM）を務めている深谷です。
今回は、エンジニアリングを通じていかにインパクトを最大化させていくかについて、私が日頃大切にしている考え方やチームでの実践を共有します。
モノグサのエンジニアの皆さんは非常に高い技術力を持っており、求められたものを形にする能力は高いと感じています。
しかし、技術的成果物をデリバリーしたからといって、それが必ずしも「ユーザーの行動変容」という形のインパクトに繋がるとは限らず、不確実性が伴います。
開発に時間を投じたものの、狙い自体が外れることもあります。(一定やむを得ないことではありますけれども。)
なぜ、作ったものがインパクトに繋がらないことがあるのでしょうか。
その本質的な原因は、結局のところ「デリバリしたものがユーザーの問題を真に解決しきれていない」点にあると考えています。
例えば、以下のような状況が考えられます。
- ユーザーが抱える課題を十分に理解しないまま、チームの思い込みで開発を進めてしまう
- ユーザーから寄せられた要望の背景や目的を十分に掘り下げないまま実装し、根本的な課題解決に至らない
- 解決策の質が不十分、あるいは副作用で別の問題を引き起こしてしまう
「問題が分かれば、答えは半分わかったと同じだ」という言葉の通り、多くの場合は真の問題を特定できていないことこそが最大の問題です。
本記事では、ユーザーの真の課題を解決し、インパクトを出すための3つのプラクティスを紹介します。
1. 「現地現物」に拘り、自分事化する
モノグサの開発チームは実際に学校現場などのユーザーのもとへ足を運び、導入の案内をしたり、ユーザーの生の声を聴いたりしています。
Slackなどのテキスト情報や又聞きでは伝わりづらい「空気感」や「切実さ」があるからです。
ここで重要なのは、「現地現物」とは単なる視察ではないということです。
トヨタ自動車の豊田章男氏は、「現地現物」について、単に現地を視察することではなく、目の前で起きていることを自分事として捉え、より良くするために行動することだと述べています。
Monoxerのアプリでは、以前「ログイン時に意図せず個人用スペースに入ってしまう」という課題がありました。
オフィスで事象だけを聞いていたときは、「少し不便な状態」程度に捉えていました。しかし、実際のオンボーディング現場で、その影響の大きさを知りました。
オンボーディングでは、カスタマーサクセス（CS）の担当者が、約50分という限られた時間の中で、操作方法だけでなく、Monoxerを活用する価値まで伝えようとしています。 しかし、ログインステップのつまずきのせいで、肝心の説明の時間が削られてしまいます。
この光景を目の当たりして「自分事」として捉えたことで、ログイン時の無駄やつまずきをなくす改善の優先度を上げました。その結果、オンボーディングが本格化する時期にリリースでき、現場でのスムーズな導入につなげることができました。
後日談として、別の学校に行ったときに、
先生「登校が難しい児童生徒にも使ってほしいが、ログイン手順の案内が大変なんですよね」
先生「（Chromebookで）アプリの画面サイズを最大化したりとか」
私「お手数をおかけしましたが、最新バージョンではデフォルトで最大になるように修正が入りました！」
とタイムリーに修正を入れることができたとお伝えできました。
2. 「なぜなぜ分析」で、課題の真因を捉える
現場で起きた事象が見えたら、次はその構造を紐解く「なぜなぜ分析」を行います。表面的な不満に対して安易な解決策を当てはめないためです。
例えば、ユーザーから「学習計画の進捗がなかなか進まない」という不満があったとします。「進捗計算を甘くして早く進むようにする」という解決策が思いつきそうですが、これだけでは本質的な解決になるかわかりません。
ここでは、多角的にクリティカルシンキングすることが必要です。
- 進捗そのものが遅いのか。それとも、ユーザーが「なかなか進まない」と感じる体験になっているのか
- 記憶がなかなかできていない結果、進捗が遅くなっていないか？（コンテンツの難易度や、学習サイクルの設計に問題はないか）
- 記憶はできているのに、アプリの判定ロジックがそれを拾えていないのか？
ユーザーがなかなか記憶できていない場合はなぜ覚えてもらっていないのかを解決する必要がありますし、 実際にはユーザーは記憶しているのにアプリ側で正しく記憶済みと判定できないなら判定論理を変更する必要があります。
こうした分析を階層化し、ビジュアライズすることで、チーム内の意識を統一し、「本当に解くべき問題」にフォーカスできるようになります。
3. 仮説検証サイクルを高速化する
問題が特定できれば、次は解決策の検証です。
モノグサでは厳密な仮説検証の手法としてABテストを重視していますが、以前は実施頻度が低いという課題がありました。
そこで、「ABテストの頻度を1Qに1回から、10回へ増やそう」という目標を掲げ、開発プロセスを抜本的に見直しました。具体的に実践した改善は以下の通りです。
- 仮説/施策候補の管理台帳（Notion）の運用：全メンバーがアイデアを出し、定期的に議論する仕組み作り
- MVP（最小機能開発）の徹底：作り込みすぎず、検証に必要なプロトタイプを作り、期待された効果が確認できなければ本実装を見送る
- BtoBtoC特有の顧客調整フローの確立：CSと連携し、学校や塾の運用状況、学習者の利用環境への影響を考慮しながら、検証の対象範囲や期間を設計
- 分析の自動化（Colab作成）：クエリ作成や集計ミスを排除し、誰でも即座に結果を可視化できる環境整備
- レポート雛形の改善：単なる数字の羅列ではなく、結果に対する「解釈」を残し、チームの資産にする
結びに：アウトプットをアウトカムに変えるために
これらの取り組みの結果、1Qで9回のABテストを実施でき、プロダクトKPIの伸び（ABテスト結果の積み上げベース）は昨年の約8倍にまで跳ね上がりました。
エンジニアリングの本質的な価値は、コードを書くことそのものではなく、その先の「ユーザーに価値を届けること」にあります。
これからも現地現物で課題に向き合い、真因を射抜き、高速に検証を回し続けることで、教育における革新的なインパクトを創出していきたいと思います。
