STEP 6 · 進めて作る
生成AIを使って小さく作り、計画どおりに進める
決めたものを、生成AIを前提に小さく早く作り、現場で試します。同時に、少人数のプロジェクトを計画どおりに進める段取りも身につけます。実装経験がある人の強みが活きるステップです。
このステップのゴール
- 業務の「状態」（受付・確認中・完了など）を整理し、テーブルに落とせる
- 業務をAI化するとき、ルールで解くか、最適化か、生成AI・RAGかを選べる
- 作ったものを、顧客に渡す前に自分で確かめる手順を持っている
- WBS・課題ログ・定例で、少人数のプロジェクトを回せる
なぜこのステップが必要か
生成AIで実装は速くなりましたが、何を作るか・正しく動いているかを判断するのは人です。業務のステータス設計と動作確認ができると、作ったものが現場で使われるところまで持っていけます。
学ぶ講座
どの講座も、FDEガイドで無料で読めます。スライド・演習・テストは受講サイトにあります。
手を動かす練習
- ステップ4のTOBEに出てくる「もの」（注文・見積もりなど）ごとに、取りうる状態と遷移を書き出す
- 状態の一覧から、テーブルの分け方を考え、生成AIを使って小さな画面を1つ作る
- 作った画面について、正常・例外・境界値の確認項目を書き、自分で全部試す
- 2週間分のWBSと課題ログを作り、週1回の定例で何を報告するか決める
このステップで作るもの
TOBEの一部を実装した試作と、その動作確認の記録、そしてWBS・課題ログ。顧客に見せて、現場で試せる状態のもの。
できたかの確認リスト
- 状態の遷移に、取消や差し戻しなどの例外が入っている
- 生成AIを使う場面と使わない場面を、理由つきで説明できる
- 顧客に渡す前に、確認項目を自分で全部試している
- 課題ログに、担当と期限が入っている
つまずきやすいところ
全部をAIで解こうとする
ルールで決まる処理まで生成AIに任せると、結果がぶれて現場が困ります。向いている場面を選びます。
確認を顧客に任せる
動作確認を受け入れテストまで持ち越すと、信頼を失います。渡す前に自分で確かめます。
READ MORE
このステップの解説記事
業務システムのステータス設計とテーブル分割：3つの型と選び方の判断基準
業務システムの不具合や追加開発の多くは、ステータスとテーブルの切り方から生まれます。1テーブル＋ステータス列、イベントごとの分割、ヘッダ・明細・イベントログの3つの型と、選び方の判断基準を例で解説します。
スキル業務AI化のアルゴリズムの選び方：LLM・機械学習・最適化・ルールの使い分け
業務をAI化するとき、何でもLLMで解こうとすると精度も運用も崩れます。ルールベース、機械学習、数理最適化、LLM、RAGの向き不向きと、業務フローのどこに人の確認を入れるかを、判断フローと具体例で整理します。
スキル動作確認の基本：作ったシステムを自分で確かめる4つの観点と影響範囲の手順
画面が動いたことと業務で使えることは別です。正常系・異常系・境界・業務シナリオの4観点、データの流れから影響範囲を洗い出す手順、AIが出した集計の検算まで、自分で動作確認を終えるための型を解説します。
スキル少人数プロジェクトの進め方：WBS・課題ログ・定例で遅れを早く見つける
数人規模のシステム開発や業務改善プロジェクトを進めるための実務手順です。ゴールから逆算したマイルストーン、達成条件を書くWBS、課題ログの書き方、ステークホルダー整理、論点を扱う定例の型を例付きで解説します。
キャリア生成AIで実装が速くなった時代、エンジニアの価値はどこに移るか
生成AIでコードを書く時間が短くなると、エンジニアの価値は「何を作るかを決める」と「正しく動くかを確かめる」に移っていきます。実装の前後で何が問われるようになるのかを、業務システムの具体例で解説します。