2026年9月28日、開発19日目。今日は「業務可視化くん」の進め方を大きく見直しました。
きっかけは、回答する項目が長すぎて、記入できない人が多いこと。まず基本の3項目に絞りました。でも、それだけでは、仕事を相談した人が何を持ち帰れるのかが変わらない。途中でその案を撤回し、仕事内容を聞いて改善案を提案し、合意したら自分で試作へ進める流れに作り直しました。
並行して、前日の勉強会レポートと開発日記を公開し、AIやナレッジの配り方を比べる記事も仕上げました。
今日やったこと
| 作業 | この日に進めたこと |
|---|---|
| 業務可視化の入力を簡略化 | 基本3項目と要件定義AIへの引き継ぎを一度実装。その後、目的に合わないと判断して撤回しました。 |
| 相談から提案へ、進め方を変更 | 仕事内容・流れ・課題を聞き、改善の方向性と実行案を返す形に変更。シートへの記録は任意にしました。 |
| 質問の数と回答の整理を改善 | 最大5問と進み具合を示し、一つの回答から複数の項目を整理する形にしました。 |
| 提案資料を画像でも返す | 文章の提案に加え、1枚の提案画像を生成。方向性の合意後に、業務アプリやAIへ仕事を任せる仕組みの設計へ進む流れを実装しました。 |
| 提案の先に、コピーして使える指示文を用意 | 読むための仕様書から、Claude CodeやCodexへ渡せる構築用プロンプトへ変更。使う目的と次の行動を伝える案内も直しました。 |
| 開始画面の説明文を調整 | 「仕事内容をヒアリング」「ワークフローと課題を整理」と、相談後に受け取れる提案資料を案内しました。 |
| 会員向けの使い分け説明を更新 | 業務可視化と要件定義を順番に使う前提を外し、目的に合わせて選ぶレッスンを追加。既存の2レッスンも合わせて直しました。 |
| マイAI作成の操作表示を本番へ反映 | 前日から進めていた、下書き作成ボタンが押されたかを運営画面で確認できる変更を反映しました。 |
| 勉強会レポートと閲覧用スライドを公開 | 前日の勉強会を記事にし、PDFをダウンロードするだけでなく、ページ内で読めるようにしました。会社・AI Crew側の関連記事にも閲覧用スライドを反映しました。 |
| 18日目の開発日記を公開 | 前日の勉強会と、案内・運営画面を整えた作業を公開しました。 |
| AI・ナレッジの配り方を比較する記事を公開 | 推論費用を誰が持つか、知識をどこまで渡すかを軸に、GPTs配布型・ナレッジ配布型・MCP型を整理しました。表紙の説明表示も記事に合わせて調整しました。 |
基本3項目にしても、相談の価値は増えなかった
最初に直そうとしたのは、回答する負担です。基本の3項目だけを先に聞き、必要なら詳しい情報を追加する。整理した内容は要件定義のAIへ渡す。いったんはこの形を実装しました。
ただ、ここで立ち止まりました。3項目を答えて次のAIへ移るだけなら、業務可視化くんを使ったことで何が分かったのかが薄いままです。
このとき、開発のやり取りで伝えたのが、次のことでした。
業務可視化はコンサルティングがやる最初のヒアリング
そのコンサルタントが提案資料を作ってくれます
仕事を広く聞いて、どこに負担があり、どう変えるとよさそうかを提案する。そういう相談をしたかったのであって、シートの空欄を埋めることを目的にしたかったわけではありません。
そこで、基本3項目と自動引き継ぎの流れを撤回しました。業務可視化くんと要件定義のAIは、それぞれ単独で使える形に戻しています。シートは相談の必須条件ではなく、必要な人が記録に使える位置付けです。
会員向けの説明も、アプリに合わせて更新しました。仕事のどこを改善するか相談したい人と、作りたいものが決まっていて要件を整理したい人では、入り口が違います。その使い分けを示すレッスンを加え、既存の説明からも「必ず業務可視化を先に使う」という前提を外しました。
質問を少なくして、回答の整理はAIに任せる
次に、相談が長く続きすぎないよう、最大5問と進み具合を示す形にしました。
シートに項目があるからといって、その数だけ質問する必要はありません。一つの回答に、仕事の流れ、困っていること、使っている道具が含まれていれば、それぞれの欄へ整理すればいい。聞いていないことを想像で埋めるのではなく、答えてもらった内容を複数の観点から読み取る形です。
| 見直した点 | 変更後の進め方 |
|---|---|
| 何問続くか分からない | 最大5問と、今どこまで進んだかを示す |
| 項目ごとに同じような話を聞く | 一つの回答から複数の項目を整理する |
| シートの記入が先に立つ | 相談と提案を先に進め、記録は任意にする |
| 仕事内容を抽象的に聞く | 具体的な作業の流れを仮置きし、合っているか確かめながら進める |
開始画面の説明も、この役割に合わせました。
提案資料を渡した後に、何をするのかまでつなぐ
提案資料を作ると言っても、文章で提案しただけでは、イメージしていた成果物にはなりません。今回は、文章とともに1枚の提案画像を返す処理を加えました。
その先も、最初は仕様書のたたき台や設計案を出す形でした。しかし、それを読んだ人が自分で作り始めるには、もう一段必要です。そこで、合意した方向性に沿って、Claude CodeやCodexへそのまま渡せる構築用プロンプトを出す形へ進めました。
仕事内容を相談する
↓
改善の方向性を、文章と提案画像で確認する
↓
進めたい方向に合意する
↓
要件を含んだ構築用プロンプトをコピーする
↓
Claude CodeやCodexへ渡し、自分の仕事で試すための試作を始めるここでも、コピーできるだけで完成ではありませんでした。提案資料を求めた人へ突然「プロンプトです」と渡しても、話のつながりが分からないからです。
資料を読んで終わらせず、自分で作って現場で試すための指示文を渡す。その目的を先に説明してから、使い方を案内するようにしました。
業務アプリを作る場合と、AIに仕事や役割を任せる仕組みを作る場合の両方で、実際に出力を確認しています。PCとスマホで全文をコピーできることも確認しました。これは試作を始める取っ掛かりを用意した、という段階です。指示文を渡せば必ず完成する、仕事の改善まで終わる、という意味ではありません。
前日からの公開作業と、配り方を選ぶための記事
業務可視化くんの改修とは別に、前日の作業を公開するところまで進めました。
勉強会のレポートでは、スライドのPDFをリンクで渡すだけでなく、ページ内で閲覧できる形にしました。記事を読みながら、その場で実演に使った資料を見返せます。18日目の日記も公開し、マイAIの下書き作成ボタンに関する運営画面の変更も本番へ反映しました。いずれも前日からの続きで、この日に新しく思いついた仕事とは分けて残しておきます。
また、GPTs配布型・ナレッジ配布型・MCP型を比較する記事を公開しました。比べたのは、どれが上かではなく、AIが考える費用を誰が持つか、知識をどのくらい利用者側へ渡すかです。
自分でAIを用意して配る場合も、利用者が普段使うAIから知識を呼び出す場合もあります。使う人がどこで仕事をし、提供する側が何を用意するのか。その違いを選べるように整理しました。
この記事では、細かな説明を毎回添える必要のない表紙に、定型の注記や拡大案内を付けないよう、表示も調整しています。
相談が終わった先に、自分で試せるものを残す
今日の変更をつなげて見ると、業務可視化くんは、情報を整理して次へ渡すところから、改善案を受け取り、その方向で作り始められるところへ進みました。
質問を減らすことは、相談を始めやすくするため。提案画像は、何を変えるのかを確かめるため。合意後の指示文と案内は、提案を自分の仕事で試すため。それぞれを別々に足すだけでなく、前の段階で得たものを次に使えるようにしたのが、今日の改修です。
前日は勉強会で、AIを作って使う流れを実演しました。今日は、アプリの中の相談そのものから、作り始めるところへ進めるようにしています。説明を聞いた人だけでなく、仕事の困りごとを持って入ってきた人にも、自分で試せるものを残す。そのために、入口の質問から最後の一言までをつなぎ直した一日でした。