AIで作った業務ツールを、社内で使い始める前に確認すること

AIを使って、入力画面も一覧もできた。試しに注文を登録すると、伝票も出せる。ここまで作れたら、次は実際の仕事で使ってみたくなると思います。

ただ、機能が一通り動くことと、普段の担当者が仕事を回せることの間には、まだ確認することがあります。画面の外で行っている連絡、担当者ごとの操作、金額の計算、普段は起きない注文の処理などです。

私がAIを使って開発した販売管理システムへの移行でも、機能を揃えてから実際に切り替えるまでに、多くの改善が必要でした。この記事では、その経験をもとに、自分で作った業務ツールを使い始める前に、何をどう確かめるかを紹介します。

自分が作った旧アプリでも、使い方を把握しきれていなかった

今回紹介するのは、複数の販路を持つ事業者の販売管理システムを移行した経験です。事例の業種や固有の情報は伏せ、確認方法に関わる部分を紹介します。

以前使っていた専用のWebアプリも、私が開発したものでした。

旧アプリの仕様を整理し、業務のヒアリングを行い、同様の機能を新アプリに実装しました。一通り動くようになり、残りは細かな調整だと考えていましたが、実際には想定よりも切り替えまでの調整に時間がかかりました。

原因の一つは、私が把握していなかった使い方です。開発者として業務を理解する努力はしていても、毎日その仕事をしている人と同じところまで理解できているとは限りません。自分が作ったアプリの置き換えでも、それは変わりませんでした。

画面の前後にある仕事まで、実際に通してみる

一番想定していなかったのは、管理画面のスクリーンショットがお客様や取引先への確認に使われていたことです。

例えば、電話で聞いた顧客情報を登録した後、その画面をメッセージアプリで送り、間違いがないか確認していました。取引先から電話で発注を受けたときも、受注データの画面を送って確認していたのです。

私にとっては社内で操作する画面でしたが、現場では相手に内容を伝える役割も担っていました。新しい画面では、送りたい情報が一画面に収まらなかったり、相手に見せたくない情報が同時に表示されたりして、その仕事を続けにくくなっていました。

対応では、操作のしやすさを保ちながらスクリーンショットを撮れるように調整したほか、相手が必要な情報を確認できる仕組みも追加しました。スクリーンショットだけに合わせるのではなく、内容を確認してもらう目的から方法を考え直しました。

アプリを試すときも、「登録できるか」だけで終わらせず、次の流れまで通してみてください。

• 情報はどこから来て、誰が入力するのか。
• 登録した後、誰が何を確認するのか。
• 別の人や取引先に、何をどの方法で伝えるのか。
• その人が確認した後、次の作業を始められるか。

画面の機能一覧には出てこない仕事が、この流れの中に見つかることがあります。

業務を知る一人の確認だけで終わらせない

今回のテストには、主に一人の担当者に参加してもらいました。画面の使いやすさでも、私の想定と現場の使い方には違いがありました。

旧アプリでは、伝票へ商品を追加するとき、検索画面で複数の商品にチェックを入れて選べました。新アプリでは、入力するにつれて候補が絞られる方式へ変更しました。その場所では一括操作の機会が少ないと考えたためです。

ところが、実際には「まとめて選びにくい」という意見があり、旧アプリの方式へ戻しました。新しい操作に慣れていないことと、実務に必要な操作がしにくいことは、分けて確かめる必要があります。

慣れるための時間を取れるかは、導入時期を考える際の確認点です。繁忙期にはその時間を確保しにくい場合もあるため、普段の業務と並行して新しい操作を試せるか、利用者と相談しておきたいところです。

また、今回のテストには参加していなかった別の作業者から、切り替え後に動線や表示について多くの意見が出ました。二人とも業務全体を経験していましたが、普段分担している仕事が違い、よく使う動線や見る場所も違っていたのです。

自分の業務ツールを自分で作るなら、開発者と利用者の認識の差は小さくなると思います。それでも、ほかの人と使うなら、その人の現在の仕事の進め方まで同じとは限りません。

次に同じ規模の導入をするなら、私は協力してもらえる主要なメンバーに、できるだけテストへ参加してもらいます。「自由に触ってください」だけでなく、業務フローごとに確認する項目を出し、それに沿って操作してもらう方法を取りたいと考えています。項目を出すのが難しければ、普段の仕事を見せてもらうところから始めます。

「使いにくい」という意見には、「どの作業で、何が起きるから不便なのか」「この変更でその不便さは解消するか」と聞き返します。希望されたボタンやリンクを増やす前に、困っていることを具体的にします。

要望を追加する前に、原因を確かめる

このシステムには、商品の分類に応じて、伝票で選べる商品を制限する仕組みがあります。ここで、選べる商品の範囲を広げてほしいという要望がありました。

背景を聞くと、使いたい商品の分類が実際の用途と合っていないことが分かりました。選択の制限を緩めるより、商品データを整えやすくする方が目的に合っています。そこで、商品マスタの検索や一括修正をできるようにしました。

テストで出た意見も、そのまま追加機能の一覧にする必要はありません。操作の問題なのか、データの問題なのか、業務の決め方の問題なのかを聞き分けると、必要な改善を絞れます。

画面の動作と、データの正しさを別々に確かめる

並行稼働中には、注文金額などの重要なデータが新旧のシステムで一致するかを確認するスクリプトも作りました。このスクリプトで、消費税の端数処理や、小計・ポイント・割引・送料の計算順序などによる差異を見つけて修正しています。

旧アプリには運用実績がありますが、結果が違うから必ず新アプリが間違っている、と決めたわけではありません。両方の処理を確認し、仕様の判断が必要な部分はお客様の担当者に確認しました。

非エンジニアの方が自分で確認する場合も、まずは普段扱う具体的なデータについて、期待する結果とアプリの結果を比べる方法が考えられます。AIにテストを作ってもらう場合にも、何を正しい結果として比べるのかを、業務に詳しい人と確認しておきたいところです。

日常の注文以外の業務もテスト期間に盛り込み、よくあるケースは一通り確認しました。それでも、切り替え後には、二つの発注をまとめて発送するために伝票を一つにしたい、というケースが出ました。そこで、複数の発注データを後から一つの伝票に取り込めるように修正しました。

一つの注文を複数個口で送る機能も、発送情報の登録には対応していましたが、一括処理や表示の考慮が漏れていて修正しました。

普段の仕事を通す確認に加えて、まとめる、分けるといった、実際に起きる例外も担当者同士で挙げてみる。すべてを最初から洗い出せなくても、思いつく漏れを減らす確認はできます。

切り替える範囲と、問題が起きたときの進め方を決める

今回の移行では、業務の範囲を分け、仕上がった部分から段階的に切り替えました。この順番を選んだ最大の理由は、開発のコストを抑えることでした。

確認は、業務の詳細を聞いて修正し、操作感を見てもらい、旧アプリで実務を続けながら一部の注文を新アプリでも処理してもらう順で進めました。その上で、お客様と切り替え日を相談しています。

切り替え後もしばらくは注文が両方に入る状態を保ち、新アプリで処理できないことがあれば旧アプリを使えるようにしました。旧アプリの停止は、新アプリで一通りの業務が回ることを確認し、運用コストも考えて判断しました。

停止時にはバックアップを残しましたが、これは停止前のデータです。停止後も最新の注文を持って旧アプリへ戻れる状態とは異なります。戻せるかを考えるときは、アプリが起動するかだけでなく、どの時点のデータまで戻せるかも確認が必要です。

私は、使い始める範囲で機能が成立していることと、データの不整合など後戻りできない、またはしにくい問題が起きないことを、最低限の判断点にしています。社内だけで使い、運用で補える問題なら、使い始めてから修正できる場合もあります。実際に使ってから方向性を決めたい機能は、後に回す方がよい場合もあります。

不具合が一つもないと証明することを、導入の条件にするのは現実的ではありません。複数人で思いつく漏れを確かめ、重大な問題を優先し、残った課題への対応を決める。その上で、使い始める範囲を判断します。

AIに渡す前提と、決まった方針を文書に残す

こうした確認をAIと進めるには、何のために、誰が、どう使うアプリなのかを共有する必要があります。プロダクトを今後どうしていきたいか、何を大事にするかは、AIが独自に決めるものではありません。

私はAIと相談して大きな方針が決まったときに、AIへ文書の更新を頼んでいます。複数の会話に作業を分けても、同じ前提から設計や実装を続けるためです。定期的に実装と文書のずれも確認し、どちらが正しいかを判断して更新しています。文書を残すだけで、自動的に整合するわけではありません。

私の経験では、AIが提案した設計が、小さく方針転換したいプロダクトには複雑すぎることがありました。請求や入金に関係する機能で、その複雑さを見落とし、後の改修で大きな作り直しのコストがかかったこともあります。何を重視するかを文書にするのは、こうした判断の前提を共有するためでもあります。

最初から大量の仕様書を作る必要はありません。何を書けばよいか分からなければ、AIに「新規プロダクトを開発するので、方針や想定する利用者など、開発に必要なことをヒアリングして文書にしてください」と頼むところから始められます。

例えば、次の情報が確認の土台になります。

• 誰の、どの仕事を、どう楽にしたいか。
• 今の業務の流れと、今回作る範囲。
• 重視することと、その方針を選んだ理由。
• 決まっていることと、まだ確認が必要なこと。
• どの文書を現在の方針として参照するか。

仕様を変えたら関連する文書も更新するよう頼み、AIの提案を採用したのか、まだ検討中なのかも分かるようにします。非エンジニアの方にとって実装と文書のずれを見極めるのが難しい場合は、その点も専門家への相談時に確認してもらう対象になります。

確認項目が分からなければ、整理するところからAIに相談する

「使い始める前に何を確認すればよいか分からない」という場合も、そのままAIに相談できます。「この業務ツールを使い始める前のチェック項目をリスト化して」と頼み、業務の状況、関係者の意向、重視することや懸念点を渡すことで、具体化を進められます。

例えば、次のように頼めます。

「このプロダクトの目的・利用者・業務の流れ・重視していることを踏まえて、使い始める前のチェックリストを作ってください。情報が足りない場合は先に質問してください。各項目には、何が起きると誰が困るか、確認方法、期待する結果を書いてください。業務担当者が確認できることと、技術的な確認が必要なことを分け、未確認の前提も明記してください。」

ここで作られるのは、確認を進めるためのたたき台です。AIが問題ないと答えたことと、具体的な方法で確認できたことは分けて記録します。

• 業務を最後まで進められるかは、普段その仕事をする人に試してもらう。
• 金額や帳票は、期待する結果と照合し、違いを業務に詳しい人と確認する。
• 権限、データ保護、復旧方法など、自分では判断できない点は、未確認として残して専門家へ相談する。

AIが出した確認項目にも漏れはあり得ます。確認済みのことと判断できていないことを整理すれば、専門家にも何を見てほしいか伝えやすくなります。

専門家への相談は、作り始める前と使い始める前に

私は、専門家に確認してもらうなら、ある程度やりたいことが固まった開発開始前と、使い始める前の二回が効果的だと考えています。

特に早い段階なら、技術の選び方、アプリを動かす環境、ログインや権限など、土台になる部分を相談できます。使い始める直前に基盤から見直すことになると、手戻りが大きくなります。

すでに作り始めていても、今の状態から確認できます。目的や方針の文書、試した業務、困っていること、まだ判断できないことを整理すると、次に確かめる範囲を決めやすくなります。

cyfrでは、自分で開発を続けたい方に向けて、作っているものと困りごとを確認し、実務で使うための進め方を支援しています。支援内容や料金は、AIで作った業務ツールを実務で使うための支援で紹介しています。