AIで家系図アプリを作ろうとしたら、必要だったのはBPO型進捗共有ポータルだった

Posted at 2026-05-31

はじめに

私はSEではありません。
ただ、家系図の作成依頼を受託したあとに、

依頼者とどう連絡を取るか
今どこまで進んでいるのかをどう見せるか
追加資料をどう受け取るか
「依頼者待ち」なのか「こちらの作業中」なのかをどう整理するか

といった課題があり、それを支えるWebアプリが必要ではないかと考えました。

最初は「家系図アプリを作る」という発想でした。
ところがAIに叩き台コードを書かせてみると、先に立ち上がってきたのは家系図の描画機能ではなく、連絡・進捗共有・資料回収・状態管理でした。

つまり、作ろうとしていたのは家系図アプリのつもりだったのに、実際に必要だったのは、むしろ家系図作成という受託業務をクライアントとつなぐポータルだったのです。

この記事は、Reactの実装テクニックを語る記事というより、
非エンジニアがAIで業務アプリを試作したら、要件そのものが変わったという話です。

この記事に出てくる氏名・メールアドレス・電話番号・案件番号などは、すべてダミー化した例です。

最初に作ろうとしていたもの

当初のイメージは、ざっくり言えば「家系図アプリ」でした。

家系図を表示する
家系情報を入力する
完成版を確認する

でも、実際の受託業務を分解してみると、依頼者が本当に必要としているのは別の体験でした。

依頼者が知りたいこと	必要な機能
今どこまで進んでいるのか	進捗表示
次に自分がやることは何か	タスク表示
何を提出すればいいか	資料アップロード
不明点をどこで聞けばいいか	チャット / メッセージ
いつ頃終わりそうか	予定表示
追加確認があるか	お知らせ

この時点で、必要だったものの名前はもう「家系図アプリ」ではありませんでした。
必要だったのは、家系図作成の受託業務をクライアントと接続する進捗共有ポータルでした。

これは「家系図アプリ」より、BPO型業務のクライアントポータルに近かった

ここで少し視点を変えます。

家系図作成の受託業務は、見方によってはかなりBPO型です。
依頼者が持っている情報・資料・文脈を受け取り、それをこちら側で整理し、追加確認しながら成果物にして返す構造だからです。

この構造では、価値の中心は単純な画面操作ではありません。
価値の中心はむしろ、次の業務の流れそのものにあります。

[依頼受付]
   ↓
[本人確認・初期ヒアリング]
   ↓
[必要資料の案内]
   ↓
[依頼者が資料提出]
   ↓
[戸籍請求・収集]
   ↓
[内容確認・不足資料確認]
   ↓
[家系図作成]
   ↓
[確認・修正]
   ↓
[納品]

このフローを見ると、家系図作成そのものは後半工程です。
その前に、

何が揃っていて
何が不足していて
いま誰待ちで
どこまで進んでいるのか

を明確にしないと、案件全体は回りません。

つまり、最初に必要だったのは家系図描画エンジンではなく、案件の流れを可視化する仕組みでした。

依頼者向け画面と管理者向け画面は、同じ案件を見ていても別の世界を見ている

試作して特に強く感じたのは、依頼者向け画面と管理者向け画面は別物だということでした。

依頼者向けに必要だったもの

画面	役割
ホーム	全体進捗、予定日、今やることを見せる
タスク一覧	提出物や確認事項を明示する
お知らせ	進捗共有・追加依頼を伝える
チャット	個別確認を行う
FAQ	よくある質問を自己解決できるようにする

管理者向けに必要だったもの

画面 / 機能	役割
案件一覧	誰の案件がどこで止まっているかを見る
案件詳細	進捗、連絡履歴、WBSを管理する
タスク登録	依頼者への依頼事項を追加する
お知らせ配信	状況変化を伝える
WBS管理	戸籍請求、確認、作成、納品までの工程を管理する

これを雑に図にすると、こんな構造です。

依頼者
  ├─ ホーム
  ├─ タスク
  ├─ お知らせ
  └─ チャット
        ↓
   進捗共有ポータル
        ↓
  ┌───────────────┐
  │ 案件情報 / タスク / 通知 │
  │ WBS / 状態管理 / 連絡履歴 │
  └───────────────┘
        ↓
管理者
  ├─ 案件一覧
  ├─ 案件詳細
  ├─ WBS管理
  └─ 依頼者対応

依頼者が知りたいのは「今、自分が何をすればいいか」です。
一方、管理者が知りたいのは「この案件は全工程のどこで止まっているか」です。

同じ案件でも、必要な情報の粒度が違います。
ここを同じ画面・同じ言葉で済ませようとすると、たぶん失敗します。

PMBOKっぽく整理すると、最初に立ったのはステークホルダーとコミュニケーションだった

この試作で面白かったのは、結果的にかなりPMBOK的な論点が先に立ったことです。
ただし、「最初からPMBOKで考えた」というより、作ってみたら自然とそこに着地したという順番でした。

1. ステークホルダー

このサービスには、少なくとも次の関係者がいます。

ステークホルダー	関心事
依頼者	今どこまで進んでいるか、何をすべきか
担当者	資料が揃っているか、どこで止まっているか
管理者	複数案件の進行状況、負荷、納期
外部機関	戸籍請求や確認に関わる外部手続き

重要なのは、全員に同じ情報を見せればよいわけではないことです。

2. コミュニケーション

この業務では、コミュニケーションは補助機能ではありません。
むしろ成果物の品質と安心感を支える本体に近いです。

依頼者にとっては、

何を出せばいいか分からない
追加確認が必要か知りたい
放置されていないか不安
いつ終わるのか知りたい

という不安を処理すること自体が価値になります。

3. WBS

さらに、進捗を見せるには工程分解が必要でした。

親工程	子工程の例
受付・初期確認	受付登録 / 本人確認 / 初期ヒアリング
戸籍請求	市区町村A / 市区町村B / 市区町村C
内容確認・整理	続柄確認 / 不足資料確認
家系図作成	下書き作成 / 清書
納品	最終確認 / 納品完了

これがないと、依頼者向けに「いま戸籍収集中です」と言うことも、管理者向けに「どこで止まっているか」を把握することもできません。

つまりこの試作で先に必要だったのは、派手なUIではなく、

ステークホルダー整理
コミュニケーション設計
WBSによる工程分解

でした。

AIに叩き台を書かせたら、先に“状態”が増えた

実際に試作コードを見ていて一番印象的だったのは、UI部品より先に状態が増えていったことでした。

たとえば案件情報。

const initialClients = [
  {
    id: 1,
    name: "依頼者A",
    caseNo: "CASE-001",
    status: "進行中",
    assignee: "担当者X",
    dueDate: "2026-04-05",
    email: "client-a@example.jp",
    phone: "090-0000-0000",
  },
];

依頼者向けタスク。

const initialTasks = [
  {
    id: 1,
    title: "最新の戸籍謄本をご提出ください",
    deadline: "2026-03-25",
    status: "未対応",
    done: false,
    priority: "high",
    detail: "スマホで撮影した画像でも可",
    attachments: [],
  },
];

やりとりの履歴。

const initialMessages = [
  { id: 1, from: "support", text: "不明点はこのチャットでご連絡ください。", time: "10:12" },
  { id: 2, from: "client", text: "資料の送り先を確認したいです。", time: "10:18" },
];

この時点でかなり明確だったのは、
これは見た目の画面づくりではなく、案件の状態遷移をどう表現するかの問題だということでした。

コードで一番おもしろかったのは、進捗バーより“進捗の定義”が先に必要だったこと

せっかくなので、試作コードの中で一番「業務設計っぽさ」が出ていた部分を少しだけ載せます。

const statusProgressMap = {
  "未着手": 0,
  "請求準備中": 0.25,
  "請求中": 0.5,
  "取得済み": 0.8,
  "確認済み": 1,
  "差戻し": 0.3,
  "保留": 0,
  "進行中": 0.5,
  "完了": 1,
};

function getStatusProgress(status) {
  return statusProgressMap[status] ?? 0;
}

function calcParentProgress(parent) {
  if (!parent.children?.length) return 0;
  const sum = parent.children.reduce(
    (acc, child) => acc + getStatusProgress(child.status),
    0
  );
  return sum / parent.children.length;
}

function calcOverallProgress(wbs) {
  const totalWeight = wbs.reduce((acc, parent) => acc + (Number(parent.weight) || 0), 0);
  if (!totalWeight) return 0;

  const weighted = wbs.reduce(
    (acc, parent) => acc + calcParentProgress(parent) * (Number(parent.weight) || 0),
    0
  );

  return Math.round((weighted / totalWeight) * 100);
}

最初は「進捗バーを出したい」くらいの感覚でした。
でも実際にこれを書くと、すぐに論点が出てきます。

戸籍を請求した時点で50%なのか
取得済みは80%でよいのか
「確認済み」と「完了」は同じ1でよいのか
差戻しを0ではなく0.3にする理由は何か

これは単なるUIの問題ではありません。
何をもって進捗と見なすのかという、業務の定義そのものです。

つまり、進捗バーは表示部品ではなく、業務理解の圧縮表示でした。

類似案件の進捗を一言で見せるロジックも、実はかなりBPO的だった

もう一つ面白かったのは、「内部の細かいWBS」を「依頼者向けの分かりやすい一言」に変換しようとしていたことです。

function getClientSummaryLabel(wbs) {
  if (!wbs?.length) return "準備中";

  const sorted = [...wbs].sort(
    (a, b) => calcParentProgress(b) - calcParentProgress(a)
  );

  const current =
    sorted.find((parent) => calcParentProgress(parent) < 1) ||
    sorted[sorted.length - 1];

  return current?.clientLabel || current?.title || "進行中";
}

管理側では、

どの市区町村の戸籍を請求したか
どの子工程が止まっているか
どこに差戻しがあるか

を見たい。
でも依頼者側には、そこまで細かい情報は不要です。

依頼者に必要なのは、

戸籍収集中
内容確認中
家系図作成中
納品準備中

といった、安心して読める要約です。

この変換処理は、かなりBPO的でした。
内部の複雑さを、そのまま外に見せるのではなく、クライアントに意味のある粒度に翻訳する必要があるからです。

一番おもしろかったのは、家系図の描画より“連絡設計”が先に来たこと

自分でも意外だったのですが、家系図作成サービスで先に必要だったのは、

家系図をどうレイアウトするか
系図ノードをどう編集するか
どの描画ライブラリを使うか

ではありませんでした。

先に必要だったのは、

依頼者に何を見せるか
どの段階で何を提出してもらうか
どこまでを依頼者向けに開示するか
どの状態を管理者だけが持つか
案件進行をどう説明責任のある形で見せるか

という連絡と進捗の設計でした。

ここはSaaSっぽいアプリの発想とは少し違っていて、むしろ受託型の案件管理をどう可視化するかの話に近いと思います。

今回の試作で一番大きかった学び

今回いちばん大きかった学びは、これです。

家系図作成サービスで最初に必要だったのは、家系図を描く機能ではなく、依頼者とのやりとりと進捗共有を支える仕組みだった

言い換えると、

「何を作るか」を決める前に、「どんな業務を支えたいのか」を分解する必要があった

ということです。

その分解にあたっては、

BPO的に見るなら、どこに情報の滞留が起きるか
PMBOK的に見るなら、誰がステークホルダーで、どんなコミュニケーションが必要か
WBS的に見るなら、何を工程として可視化すべきか

を考える方が、技術スタックを決めるより先でした。

おわりに

最初は「家系図アプリを作りたい」と思っていました。
でも試作を通じて見えてきたのは、必要だったのは家系図作成の受託業務を支える顧客ポータルだった、ということでした。

もし同じように、非エンジニアがAIで業務用のWebアプリを叩いてみようとしているなら、最初に考えるべきは技術スタックよりも、

その業務の流れは何か
誰がどの情報を見るべきか
進捗とは何をもって進捗とするか
どこまでを非同期化し、どこからを人の判断に残すか

なのかもしれません。

私自身まだここから先に進む段階ですが、
「作りたいものの名前」と「本当に必要なもの」がズレていたことに気づけただけでも、試作した意味はかなり大きかったです。

最終振り返ると、AIにコードを書かせてみて、
一番大きかった成果はコードではなく、
自分が本当に解決したい問題を言語化できたことだったのかもしれません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up