・「AIで作成したその業務アプリを来週から社内10人で使うとしたらどうでしょう」

　社内でアプリを共用する場合、社外の人員や退職者がデータにアクセスできてしまう漏えいリスクを避けるために、アクセス権限の設定が必要だ。また、データの保存失敗などに備えたバックアップや、データのバリデーション（入力の妥当性）チェックも欠かせない。さらに、2人以上の同時編集時の競合ハンドリングも考慮しなければならない。

・「3カ月後、なぜこの仕様か説明できますか？」

　業務の一部が変更されるとそれに応じてアプリ機能も改修することになり、対応するためにはアプリの仕様を把握していなければならない。記憶は常に欠落していくので、ドキュメントが残されていなければ、仕様の細部が残されたチャットの履歴を毎回さかのぼる手間が発生する。しかしチャットから正しい仕様を読み解くのは難しく、履歴が残っていない場合もありうる。

・「担当者が変わったら、何を見ればいいでしょうか？」

　その業務アプリは作成者が異動したり退職したりした後も、同僚が運用を続けることができるだろうか。新しい担当者が迷わずにメンテナンスできるようになっているだろうか。チャット履歴が異動や退職と同時に消えてしまうと、アプリはブラックボックスとなり、「野良アプリ」として迷惑なだけの存在になるかもしれない。

　こうした組織内での利用と運用を前提にアプリを作り込み、ドキュメントなどを用意しなければアプリの本当の「完成」には至らないと堀氏は述べた。

図3 「動くアプリ」と「会社で使えるアプリ」の分かれ目（出典：セミナー投影資料）

組織で使えるアプリが備えるべき条件とは？

　「作るだけと、会社で使い続けることとは別です。本当のアプリ完成は、仕様と現在地、次の作業、判断理由を理解し、誰でも続けられるようになった状態です」と堀氏は語る。さらに同氏はアプリを会社で使うために必要な5つの条件を挙げた。

1．業務適合

　入力タイミングなどが業務フローに沿い、管理者と一般従業員で画面や操作権限が適切に分離されているかどうか。

2．データ管理

　個人のマイドライブなどではなく共有ストレージに保存され、識別・検索のためのIDが正しく管理されているかどうか。入力ミスへの対応も必要だ。

3．アクセス制御

　適切な認証が実装され、許可されたユーザーのみがアクセス可能かどうか。

4．安定運用

　不具合やエラー発生時に修正・復旧できる体制があり、エラーハンドリングや更新手順が確立されているかどうか。

5．改善可能（メンテナンス性）

　業務変更に伴い、3カ月後・半年後・1年後でも別の担当者が安全に仕様を変更し、拡張できるかどうか。

図4 アプリの「完成」の要件（左）と組織利用に必要な5つの条件（右）（出典：セミナー投影資料）

　堀氏が特に強調したのは、「仕様や現在の進行状況（現在地）や次の作業、判断理由といった要点を整理し、作成者以外の誰でも運用・改善を継続できるビジネス上の仕組みが整った状態にすること」だ。

　そのためには、アプリがブラックボックスであってはならない。運用を考慮して適切な設計をしておくことはもちろん、メンテナンス性を保持できる「管理用ドキュメント」を残しておくことが重要だ。チャット履歴に頼らず、設計からデプロイに至るまでのドキュメントを意識的に完全な形で作成しておくこと、つまり、ドキュメントを永続化・共有化する必要がある。

　同氏が推奨するのは次の「4つの重要要素」をカバーし、共有ドキュメントに残すことだ。

1．仕様（SPEC）：何を作るのか、アプリの目的や機能要件。

2．現在地（STATUS）：現在どこまで実装・完了しており、何が未完了なのか。

3．タスク（TASKS）：今後実行すべき具体的なToDoリスト。

4．判断理由（DECISION LOG）：なぜその仕様・設計を採用したのかという経緯（例：日付計算の端数処理を含めるか否かなど）。

　これらを残すことで、後から仕様が混乱するのを防ぎ、また無駄に元に戻る「先祖返り」を防ぐことができる。

　各ドキュメントはチャット内ではなく、プロジェクト内に別に保管し、関係者が共有して互いに編集・更新できるようにしておく必要がある。

　堀氏は、実践的なアプリ作成の流れとして、次のようなフローを実行している。

　1．業務整理→2．仕様化→3．UI確認→4．プロジェクト管理→5．タスク分解→6．AIによる実装→7．QA（確認）→8．デプロイ→9．運用改善

　1～3を事前に実行し、4～9を運用改善サイクルとして長期にわたって回し、変化する業務に適合させながらより効果的に利用できるようにしていく。

　その際に適切なドキュメントがあれば、AIとのチャット履歴がなくなっても、作成担当者が変わっても開発を引き継げる。例えば、「今の仕様と現在地を確認して、次にやる作業を教えてください」と新しいAIチャットに指示することで、目的を達成するための残タスクや、未達の要件、セキュリティ強化策、さらにより望ましい改善点までを答えてくれる。それに沿ってプロジェクトを改善していくことができる。

　堀氏のデモでは先ほどの問い合わせ管理アプリを基に、新しいチャットで改善を施す（画面の色調を変える）修正が披露され、4分ほどで修正が完了した。堀氏によると、短時間で修正できたのは適切にドキュメントを残していたからだという。もちろん、この修正もドキュメントに反映しており、図5の6個のドキュメントが更新された。

図5 修正によって更新されたドキュメントの例（出典：セミナー投影資料）

　この後、例えば「残タスクの表示」を指示し、表示されたタスクを実行していけばよい。開発担当者が変わっても共有されたドキュメント群さえあれば、正確に仕様や文脈を引き継いで開発・保守作業を開始できることになる。

　堀氏は、AIによる開発ステップの重要ポイントを次のように整理している。

・ステップ1：どんな業務か、誰が使うか、何ができれば成功かを、最初に決める

・ステップ2：実装を細かく分けて、小さく作る

・ステップ3：動いたら終わりでなく想定通り使えるか確かめる

　「AIはコード作成の能力をますます高める。人間がコード作成を学ぶ必要性は低くなる。しかし、“何をもってアプリの完成とするか”は人間が決めなければならない」（堀氏）。一度リリースしたアプリでも、業務が変化すればそれに即した完成型が求められる。常に最善の業務効率化やガバナンス徹底を目指すなら、自動生成アプリを管理する仕組みを作り、メンテナンスによりその時点で最善の完成型を目指す取り組みが必要だ。