この記事はLITALICO Engineers Advent Calendar 2025 カレンダー3 の 9日目の記事です
はじめに
「現場の人が言うことは絶対」 そう思っていた過去の私は、間違いなく成長しないエンジニアでした。
私は株式会社LITALICOで、5年間教育・福祉領域のエンジニアをしています。
キャリアの変遷：
- 入社時：業界知識ゼロ、学校向けプロダクトからスタート
- 現在：児童発達支援・放課後等デイサービス・保育所等訪問支援の児童福祉施設向けプロダクト開発
入社直後は、事業部メンバーの知識量に圧倒され、「言われた通りに作る人」になっていました。
しかし、それはユーザーへの向き合い方として本当に正しかったのでしょうか？
「社内受託開発エンジニア」から脱却し、真にユーザーに貢献するエンジニアになるまでの軌跡と、5年間で学んだ「技術者だからこそできるユーザーへの向き合い方」をお話しします。
この記事で得られるもの：
- ドメイン知識がない状態からの具体的な成長ステップ
- 「現場の要望」と「技術的最適解」のバランスの取り方
- 実際の成果と数値に裏付けされた問題解決事例
- エンジニアが事業に与える真のインパクトの存在意義
🔄 1年目の私が犯していた4つの勘違い
入社1年目の自分に今伝えたいことを、4つのポイントにまとめました。
1. 🤔 「リスペクト」と「思考停止」を履き違えない
入社当時、私は現場の方々の熱量や知識に圧倒され、彼らの言葉を「正解」として扱っていました。しかし、これはリスペクトではなく、単なる思考停止でした。
| アプローチ | 対話例 | 結果 |
|---|---|---|
| 思考停止型 | 「このデータを一覧で見たい」→「はい！」 | 要求通りの画面を作成。将来の問題は未解決 |
| 真のリスペクト型 | 「なぜそのデータが必要ですか？」→深堀り対話 | 本質的課題を発見し、最適解を提案 |
真のリスペクトとは、相手の言葉を鵜呑みにすることではなく、相手の本当の課題解決のために最善を尽くすことです。
ドメインエキスパートの「現場の文脈での正解」と、エンジニアの「システム全体での最適解」は必ずしも一致しません。
言われたままに作ることは、一見ユーザーに寄り添っているようでいて、実は 「プロとしての責任放棄」 だったと痛感しています。
2. 💪 ドメイン知識で勝てなくても、勝てる場所はある
正直に言うと、ドメイン知識やユーザー理解において、現場の方々に勝てる気はしません。彼らが日々対峙しているN=1（一人ひとりのユーザー）への解像度は凄まじいものがあります。
また、現場の方々も私と同じく、あるいはそれ以上に日々勉強されているため、ドメイン知識で追いつくのは現実的ではありません。
しかし、私たちエンジニアには現場とは異なる武器があります：
| エンジニアの強み | 現場への価値提供 |
|---|---|
| 抽象化する力 | 個別の事象をパターンとして捉え、汎用的な解決策を提案 |
| システム思考 | 全体最適やデータ整合性の観点から業務フローを再設計 |
| 技術トレンドへの感度 | 他業界の事例や最新技術を教育・福祉領域に応用 |
| 数値・データへの慣れ | 感覚的な課題を定量化し、改善効果を可視化 |
現場が見ている「深さ（N=1の解像度）」と、エンジニアが見ている「構造（システム全体の最適化）」。
この2つを掛け合わせることで初めて、本当に価値あるプロダクトが生まれます。
3. 🔍 ユーザー自身も気づいていない「解」を模索する
LITALICOでは、お子様やご家族、施設利用者様など、たくさんのユーザーがいます。N=1の要望は非常に具体的で切実ですが、そのまま機能化するとシステムが複雑化し、他の多くのユーザーにとって使いにくいものになりかねません。
ここで重要だったのが、「言われたこと（How）」ではなく「やりたいこと（Why）」に立ち返る対話です。
実際の対話例：
現場：「子どもたちの情報を一覧で見たい」（How）
↓
私：「なぜ一覧で見たいんですか？」
↓
現場：「支援会議で誰がどんな状況か把握したい」（Why）
↓
私：「では、会議前に自動でサマリーレポートを生成するのはどうでしょう？」
このように深堀りすると、ユーザー自身も気づいていない本質的な課題が見えてきます。
これこそが、ドメイン知識を持った方々と、技術を持った私たちが**「共創」**する瞬間です。
4. 🌍 過去の経験は「外の視点」として価値になる
私は業界未経験で入社しましたが、過去に培ってきたシステム開発の経験や、他社での失敗・成功事例は無駄ではありませんでした。
業界の中にどっぷり浸かっていると、どうしても発想が「業界の常識」に囚われてしまいます。
そこに 「前の現場ではこう解決していた」「一般的なWebサービスではこういうUIが標準だ」 という外からの視点を持ち込むこと。
これこそが、ドメイン知識ゼロから入った私がチームに貢献できる、独自の価値でした。
👥 実体験：初めて現場に足を運んだ日の衝撃
入社2年目、学校の先生方に個別指導計画の作成をサポートするプロダクトを開発していた時期。実際に学校を訪問させてもらい...
- 学校の先生が私の作った画面を使っている姿を目の当たりに
- 「この機能のおかげで生徒一人一人に向き合うための計画がよりよく作成できました」という言葉
- 一方で「保護者の方から紙でいただいたアセスメントをシステムに転記する作業のコストがかかり、また、転記ミスがないかも不安になる」という率直なフィードバック
そしてここからが重要でした。
このフィードバックを受けて、私は「保護者の方が直接アセスメントを入力し、それを計画作成プロダクトに自動で取り込めるサービス」を企画提案しました。チームで検討を重ね、実際に開発・提供することになったのです。
定量的成果：
- 転記作業時間：1分（取り込みボタンを押し取り込みを待つ時間。結果、大幅に削減）
- 転記ミス：0件（転記作業自体が不要に）
定性的成果：
- 保護者：「スマホで簡単に入力できて便利」
- 先生：「事務作業が減って、子どもたちとの時間に集中できる」
→ コードの向こう側にいる人たちの存在を実感
→ 「技術は手段、価値は人が感じるもの」を体感
→ 現場の課題を技術で解決する醍醐味を初めて味わった瞬間
🚀 経験を積んだ今だからこそ見えてきた「エンジニアの本当の価値」
🎯 ドメインを知った「今」だからこそ、あえて疑う
入社から5年が経ち、私もそれなりに業界知識がつきました。現場の言葉が理解でき、背景にある法律や制度もわかってきました。
しかし、ここには新たな落とし穴があります：
「既存の仕組みに詳しくなりすぎて、課題を課題と思わなくなること」
知識がついたからこそ、「これは法律で決まってるから仕方ない」「業界の慣例だから変えられない」と思考停止してしまう危険性があるのです。
エンジニアが真に価値を発揮するために必要なのは、以下の2つの視点だと考えています：
「ドメインの常識」を技術でハックする
知識がつくと「法律で決まってるから仕方ない」と現場と同じ思考になりがちです。しかし、未来を作るエンジニアの役割は、そこで止まることではありません。
以下はまだ実現できていませんが、目の前の課題を解決した後に取り組みたい内容です：
今後取り組みたいこと1：児童発達支援での法的義務効率化
「個別支援計画の作成は法的義務で必須。でも、子どもの発達状況や過去の支援実績から計画のたたき台をAIで生成し、支援者は個別調整と最終確認に集中できるのでは？」
今後取り組みたいこと２：保育所等訪問支援向けポータブルアプリ
「保訪支援は、移動時間やコストが課題。移動時間にこれまでの指導内容や支援計画を確認したり、支援の記録をつけるられるようにすることでより児童と向き合う時間を確保できるようになるのでは？」
ドメイン知識を「守るためのルール」としてではなく、「ハックするための前提条件」として捉え直すこと。 現場の人が思いつかないような非連続な成長（イノベーション） を、技術起点で提案することがこれからの私の役割と考えています。
「作る人」から「事業を設計する人」へ
今までは「降りてきた要望をどう技術で打ち返すか」という視点でした。 しかし、ドメインと技術の両方がわかってきた今は、「そもそも何を解決すべきか」 という最上流の問いから一緒に考えることができます。
「システムを作る」のではなく、「技術を使って、LITALICOが届ける価値そのものを再定義する」。 これからは、エンジニアという枠を超えて、事業やサービスの未来図を一緒に描く人材でありたいと思います。
💥 実体験：UXデザイナーとの「建設的な対立」から生まれた価値
プロダクト開発において、UXデザイナーの方と意見が激しくぶつかったことがありました。
対立の構図：
- UXデザイナー：「ユーザビリティを最優先に、シンプルで直感的なUIを」
- 私（エンジニア）：「システムの拡張性や保守性を考えると、もう少し構造的なアプローチが必要」
当初は「どちらが正しいか」を議論していましたが、何度も話し合いを重ねる中で、お互いが同じゴール（ユーザーの価値向上）を目指していることに気づきました。
解決プロセス：
- Whyに立ち返る：「なぜそのUIが良いと思うのか」を互いに説明
- ユーザーテストで検証：実際の現場での使いやすさを数値化
- 段階的実装：まずはシンプル版で検証し、必要に応じて機能拡張
結果：
最終的にそのUXデザイナーの方から「意見はぶつかりまくったが、その結果プロダクトがより良い形になったのを実感できた」という言葉をいただきました。
→ 対立は悪いことではない。同じ目標に向かう情熱的な議論こそが、より良いプロダクトを生む
→ 異なる専門性を持つメンバー同士だからこそ、1人では到達できない解に辿り着ける
💫 まとめ：エンジニアだからこそできる「愛あるユーザー向き合い方」
ユーザーのことを完全に理解することは不可能かもしれません。LITALICOが向き合う課題は深く複雑です。それでも、向き合うことを諦めたくはありません。
大切なのは、この2つのバランスです：
- 謙虚さ：「自分はユーザーやドメインエキスパートではない」と自覚し、学び続ける
- 自信：エンジニアとしての視点（技術、構造、汎用性）には自信を持つ
ドメイン知識を持つ仲間と、技術という武器を持つ私たち。
お互いの視点が違うからこそ、ぶつかり合い、混ざり合って、1人では到達できない「最適な形」を作れるのだと思います。
真のユーザー向き合い方とは、単に優しく寄り添うことではありません。
時には 「技術の可能性」を信じて、ユーザーの想像を超える未来を提示することも、また一つの愛ある向き合い方です。
不完全な人間同士、これからも衝突を恐れず、最適な形を模索し続けていきます。