「何を作るか」ではなく、「何を改善するか」から始める
システム開発の現場では、要件が決まったあとにエンジニアが呼ばれることが少なくありません。
決められた仕様を受け取り、設計し、実装し、リリースする。
もちろん、それも重要な仕事です。
しかし、実際の経営課題や業務課題は、最初から明確な「開発要件」になっているとは限りません。
たとえば、
* 問い合わせは来るが、商談につながらない
* Webサイトへのアクセスはあるが、次の行動が起きない
* 顧客情報は蓄積しているが、営業改善に活用できていない
* AIを導入したが、業務成果につながっているか分からない
* 新しい機能を追加し続けているが、何が効果を出しているのか判断できない
こうした課題に対して、いきなり機能開発を始めても、成果につながるとは限りません。
必要なのは、
顧客や現場の一次情報を整理し、課題を構造化し、優先順位を決め、必要な仕組みを実装し、その後の効果まで確認することです。
Sekimosoft合同会社では、自社サービス「BizDXAI」の開発・運営を通じて、この一連のプロセスを実践しています。
本記事では、顧客課題の整理からKPI設計、システム設計、AIを活用した開発、リリース後の改善までを、どのように一気通貫で進めているかをご紹介します。
> 本事例について
>
> 本記事は、Sekimosoft合同会社が自社サービス「BizDXAI」の開発・運営において実践した自社導入・開発実証事例です。
>
> 特定の顧客企業から受託したプロジェクトの事例ではありません。
>
> 実際の自社開発で行っている課題整理、設計、実装、検証、改善の進め方をご紹介しています。
背景：機能を増やすだけでは、事業成果は生まれない
BizDXAIの開発では、当初から一つの課題がありました。
それは、
「できることを増やすこと」と「事業成果を増やすこと」は同じではない
ということです。
AIを使えば、以前より速くシステムを開発できます。
Webサイトを作ることも、業務ツールを作ることも、データを可視化することも、以前より短期間で実現しやすくなりました。
しかし、開発速度が上がるほど、別の問題が生まれます。
作るべきではないものまで、速く作れてしまう。
そのためBizDXAIでは、機能数を開発成果の中心には置いていません。
重視しているのは、
* Webサイトを訪れた人が、次の行動を起こしたか
* 課題を持つ企業が、自社の状況を整理できたか
* 相談や診断が、具体的な商談につながったか
* 商談が、提案や契約につながったか
* 導入後に、本当に業務や経営が改善したか
という変化です。
私たちは、AIそのものを販売したいわけではありません。
DXそのものを販売したいわけでもありません。
AIやシステムは手段であり、提供したいのは経営や業務の改善成果です。
この考え方から、BizDXAIの開発では「機能を作る前」の工程を重視するようになりました。
最初に行うのは、課題の構造化
顧客や現場から聞こえてくる声は、必ずしもそのまま開発要件になるとは限りません。
たとえば、
「AIチャットを導入したい」
という要望があったとします。
そのまま受け取れば、AIチャットの開発が始まります。
しかし、本当に解決したい問題は別かもしれません。
* 問い合わせ対応の負担を減らしたい
* 営業担当者が対応する前に、顧客課題を整理したい
* 見込み顧客に、自社サービスを理解してもらいたい
* Webサイトから相談につながる割合を増やしたい
目的が違えば、必要な仕組みも変わります。
そのため、BizDXAIでは要望をそのまま機能に変換せず、
「なぜ、それが必要なのか」
を掘り下げます。
整理するのは、主に次のような項目です。
現在、何が起きているのか
まず事実を確認します。
思い込みや印象ではなく、現在の業務や顧客行動を見ます。
本来、どうなってほしいのか
理想の状態を明確にします。
どこに差があるのか
現在と理想の間にあるギャップを整理します。
何が最も大きなボトルネックなのか
すべてを同時に解決しようとせず、最も影響の大きい問題を特定します。
システムで解決すべきか
ここも重要です。
業務ルールの変更で解決できるのか。
情報整理で解決できるのか。
運用改善が必要なのか。
本当にシステム開発が必要なのか。
この順番で考えます。
「改善したかどうか」を判断できる状態を作る
課題を整理したあと、すぐに開発には入りません。
次に行うのは、
改善を判断するための指標を決めることです。
BizDXAIでは、顧客がサービスを知ってから契約に至るまでの流れを、一連のファネルとして捉えています。
たとえば、
Webサイトへの訪問
↓
課題の整理・診断
↓
相談情報の登録
↓
商談
↓
提案
↓
契約
という流れです。
この中で、
「どこで止まっているのか」
を見ます。
Webサイトへの訪問はあるが、相談につながっていない。
相談はあるが、商談につながっていない。
商談はあるが、提案や契約につながっていない。
問題の場所によって、作るべきものは変わります。
たとえば、契約率が課題なのにWebサイトのデザインだけを変更しても、根本的な改善にはならないかもしれません。
反対に、Webサイトを訪れた人が自分の課題を整理できず離脱しているのであれば、営業管理機能を増やすより、最初の導線を改善した方が効果的です。
このように、
事業課題を、観測可能な変化に変換する。
それがKPI設計の役割です。
開発で重要なのは、「何を作るか」だけではない
開発では、やりたいことが増え続けます。
新しい機能。
新しいAI。
新しい分析画面。
新しい自動化。
しかし、すべてを作ろうとすると、本当に重要な改善が遅れます。
そのためBizDXAIでは、
今の事業課題に最も近いものから作る
ことを重視しています。
判断するときは、主に次の観点を見ます。
顧客成果に近いか
その変更は、顧客の課題解決につながるか。
事業成果に近いか
商談、契約、継続利用などの改善につながるか。
今、本当に必要か
将来必要になるかもしれない機能ではなく、現在のボトルネックを解消するか。
検証できるか
リリース後に、良くなったかどうか判断できるか。
運用できるか
開発後に、現実の業務として使い続けられるか。
この基準でスコープを絞ります。
結果として、
作らない判断
も重要な設計の一部になります。
画面を作る前に、「情報の正しい場所」を決める
システムが成長すると、同じ情報が複数の場所に書かれる問題が起きます。
ある画面にはAと書いてある。
別の画面にはBと書いてある。
データベースにはCが入っている。
どれが正しいのか分からない。
こうした状態になると、変更のたびに確認作業が増えます。
AIを使って開発速度を上げても、情報構造が崩れていれば、間違いを速く増やすだけです。
そのためBizDXAIでは、
情報の正しい管理場所を決め、その情報から必要な表示や機能を作る
という考え方を採用しています。
重要な情報を一か所で管理し、
そこから必要なデータや画面を生成し、
利用者に届ける。
この構造によって、
* 情報の重複
* 表示の不一致
* 修正漏れ
* 担当者ごとの解釈差
を減らします。
これは単なるコード設計ではありません。
事業ルールを、長く運用できるシステム構造に変換する作業です。
AI駆動開発で重要なのは、役割分担
BizDXAIでは、AIを開発に活用しています。
しかし、
「AIに全部作らせる」
という考え方ではありません。
重要なのは、
人間とAIの責任範囲を分けることです。
人間が行うのは、
* 何を改善するか決める
* 優先順位を決める
* スコープを決める
* 顧客や事業への影響を判断する
* 公開してよいか最終判断する
といった意思決定です。
AIには、
* 既存仕様の調査
* 実装案の作成
* コードの修正
* テストの追加
* 変更内容の整理
* ドキュメント更新の支援
などを任せます。
この役割分担によって、
人間は判断に集中し、AIには調査・実装・整理を任せる
ことができます。
AIを使うこと自体が目的ではありません。
目的は、
開発速度を上げながら、判断の質とシステムの保守性を落とさないこと
です。
「作った本人しか分からない」を減らす
開発が速く進んでも、
* なぜこの仕様になったのか分からない
* どこを変更すればいいのか分からない
* 前回の判断を毎回やり直す
* AIに聞くたびに違う実装になる
という状態では、長期的な開発速度は上がりません。
そのためBizDXAIでは、実装だけでなく、
次の担当者や次の開発工程が迷わない状態を残すこと
を重視しています。
残すべきなのは、単なる作業履歴ではありません。
たとえば、
なぜ、その判断をしたのか
設計や優先順位の理由。
現在、何が動いているのか
実際のシステム状態。
どの仕様が正しいのか
最新の実装仕様。
何を実施したのか
変更や公開の記録。
これらを分けて管理することで、
「過去のチャットを読まないと分からない」
状態を避けます。
結果として、
* 人から人への引き継ぎ
* 人からAIへの指示
* AIから人への確認
* 次回開発への再開
がしやすくなります。
リリース後に、実際の変化を見る
機能を公開すると、開発は一度終わったように見えます。
しかし、事業改善という観点では、そこがスタートです。
リリース後に確認するのは、
* 実際に使われているか
* 想定した行動が起きているか
* 利用者が途中で止まっていないか
* 業務負担が減ったか
* 商談や契約につながったか
といった変化です。
想定どおりでなければ、原因を考えます。
機能が足りないのか。
説明が分かりにくいのか。
導線が悪いのか。
そもそも、解決しようとした課題が違ったのか。
そして、
仮説
↓
実装
↓
リリース
↓
確認
↓
改善
を繰り返します。
BizDXAIでは、
「完成したか」ではなく「改善したか」
を重視しています。
属人的な開発から、再現できる開発へ
一度うまくいっただけでは、組織の強さにはなりません。
重要なのは、
次も同じ品質で進められることです。
そのためBizDXAIでは、開発そのものだけでなく、
* 開発を始める前に何を確認するか
* どの情報を正しい情報源とするか
* どの順番で判断するか
* どこまでAIに任せるか
* リリース前に何を確認するか
* 開発終了時に何を残すか
といった進め方も整備しています。
目指しているのは、
「優秀な一人が全部覚えている状態」
ではありません。
人、AI、開発チームが変わっても、判断と品質を引き継げる状態です。
これは、開発速度の改善だけではありません。
事業として継続的に改善を続けるための基盤になります。
BizDXAIの自社開発では、単なるWebサービス開発ではなく、次の一連の流れを実践しています。
課題を整理する
↓
改善すべき指標を決める
↓
優先順位とスコープを決める
↓
システム全体を設計する
↓
AIを活用して実装・テストする
↓
リリースする
↓
利用状況や事業変化を確認する
↓
改善する
↓
進め方を再現可能な形にする
重要なのは、各工程を別々の担当領域として分断しないことです。
顧客課題を理解する人。
KPIを考える人。
設計する人。
実装する人。
分析する人。
それぞれが完全に分かれていると、工程の間に解釈のズレが生まれます。
BizDXAIでは、
課題とシステムの間をつなぎ、実装後の結果まで確認すること
を重視しています。
次のような状況では、特に相性があります。
要件が完全には決まっていない
「何を作るか」より先に、「何が問題なのか」を整理する必要がある場合。
現場と開発の間に距離がある
顧客や業務担当者の課題が、開発要件にうまく変換されていない場合。
AIを導入したいが、進め方が定まっていない
AIツールの導入そのものではなく、業務成果につながる使い方を設計したい場合。
開発後の効果が分からない
機能は増えているが、利用状況や事業成果との関係が見えていない場合。
開発が属人化している
特定の担当者しか仕様や判断理由を理解していない場合。
PoCから先に進めない
試作はできたが、実運用、改善、定着まで進められていない場合。
Sekimosoft合同会社は、システムを作ること自体を最終目的にはしていません。
Webサイト。
AI。
業務システム。
データ分析。
自動化。
これらはすべて手段です。
重要なのは、
その仕組みによって、経営や業務がどう改善したか
です。
そのため、私たちは、
「この機能を作ってください」
という依頼だけでなく、
「何を改善すればいいか、まだ整理できていない」
という段階から、一緒に考えることを重視しています。
顧客や現場の情報を整理する。
課題を構造化する。
優先順位を決める。
必要な仕組みを設計する。
実装する。
リリース後の変化を見る。
改善する。
そして、その進め方を再現できる形にする。
課題発見から改善まで、一気通貫で前に進める。
それが、BizDXAIで実践している開発アプローチです。
Sekimosoft合同会社では、次のようなテーマについてご相談いただけます。
* 新規Webサービス・業務システムの立ち上げ
* 顧客課題や業務課題の整理
* 開発計画・優先順位・スコープの設計
* KPIや業務指標を起点とした改善
* React・Next.js・TypeScriptを活用した開発
* AIを活用した開発体制の構築
* AI機能・業務自動化の設計と実装
* 既存システムや業務フローの改善
* リリース後の利用状況を踏まえた改善
* 属人化した開発・運用プロセスの整理
「作りたいものはあるが、要件が固まっていない」
「AIを活用したいが、どこから始めるべきか分からない」
「開発は進んでいるが、事業成果につながっているか分からない」
そのような段階でも問題ありません。
システムの話を始める前に、まず課題を整理するところからご一緒します。
課題整理から、設計・開発・改善まで
BizDXAIでは、AIやDXそのものを目的にしません。
必要なのは、新しい技術を導入することではなく、
経営や業務を、実際に前へ進めることです。
課題の整理から始めたい。
既存の開発計画を見直したい。
AIを活用して開発速度を上げたい。
リリース後の効果まで確認したい。
そのような課題があれば、ぜひご相談ください。
課題を整理し、優先順位を決め、必要な仕組みを作り、改善まで進める。
Sekimosoft合同会社は、その一連のプロセスを支援します。
