FDEを使う内製化は、何を社内へ残すことか
内製化は、すべての設計や開発を社内だけで行うことを意味しません。自社の目的と優先順位を決め、必要な情報を管理し、運用で起きた変化を見て次の改善を選べる状態を持つことが中心です。外部の専門性を使い続ける場合でも、この判断が社内にあれば改善を継続しやすくなります。
アンドドットは、検証済みの実装例、設計パターン、専門家の知見を「AndDot Knowledge」として蓄積する考え方を持っています。内製化でも、完成したコードだけでなく、どの課題にどの設計を採用し、何を見送ったかという判断の型を社内に残すことが重要です。着手時から社内担当者が課題の言語化と案の比較に参加すれば、次の改善でその知見を使えます。
知見を自社へ残す五つの設計
1. 社内オーナーと判断の範囲を決める
対象業務ごとに、改善の目的、優先順位、予算、データ利用、受け入れを判断する社内オーナーを置きます。外部FDEは選択肢と根拠を示せますが、業務を変える最終判断は企業側に必要です。現場と推進側で意見が違うとき、誰が決めるかも明確にします。
判断の結果だけでなく、なぜ別案を採らなかったかを短く記録します。担当者が変わったときも、同じ検討を繰り返さずに済みます。
2. 作る過程を共同作業にする
社内担当者は、要件整理、利用者への聞き取り、設計レビュー、試行、受け入れへ参加します。会議に出席するだけでなく、自分の言葉で問題と選んだ解決策を説明できるかを確認します。外部だけが現場を理解している状態では、次の課題を社内で選べません。
共同作業の時間は、事業責任者と現場担当者の両方に必要です。忙しさを理由に試行へ参加できなければ、完成後に利用上の問題が見つかりやすくなります。開始前に参加できる時間を確保します。
3. 運用に必要な成果物をそろえる
コードや画面に加え、業務フロー、権限、問い合わせ先、例外時の対応、変更手順、判断の記録を残します。資料を大量に作ることが目的ではありません。実際に担当者が作業し、困ったときに何を見ればよいか分かる形を目指します。
未解決の課題も隠さず残します。対応済み、保留、次に判断する事項を分ければ、社内チームは改善の続きを計画できます。既存システムの管理者やベンダーへ渡す情報も確認します。
4. 社内担当者が運用する期間を置く
説明を受けただけでは、自分で回せるとは言えません。社内担当者が定例を進行し、利用者からの問い合わせを受け、小さな変更を判断する期間を設けます。FDEは必要に応じて後方からレビューし、詰まった点を一緒に解きます。
たとえば、想定外の入力があったとき、社内担当者が原因を切り分け、業務上の判断と技術的な対応を分けられるかを試します。外部がすぐに答えを出すより、判断の筋道を共有する方が次に活きます。
5. 自走条件を行動と成果で確かめる
外部支援の人数を減らすだけを達成とすると、品質低下や属人化を見落とします。業務面では、利用状況、処理時間、手戻りを測ります。組織面では、社内で判断できた変更、手順に沿って対応できた例、改善項目の更新を見ます。
測る条件は事前にそろえます。試行での見込み値と、継続利用で確認した値を分け、対象者や期間も併記します。時間を金額へ換算する場合は、支出削減と別の仕事へ使える時間を混同しません。
引き継ぎを四段階で進める
開始時に残したい能力を決める
最初に、社内で担う判断と、外部に依頼する専門作業を分けます。すべてを一度に移す必要はありません。最初の案件で、社内が何を説明し、どの変更を決められるようになるかを目標にします。
試行中に判断の理由を共有する
課題の見極め、解決策の比較、実装の変更点を短い周期で確認します。FDEが作業の結果だけを報告する形にせず、判断に使った情報と未確定の前提を社内担当者へ示します。責任者は必要な合意をその場で進めます。
運用開始後に社内主導へ移す
利用者の問い合わせ、例外の処理、変更の優先順位を、社内担当者が先に検討します。FDEはレビュー役として関与し、社内の判断で足りない情報を補います。この期間を設けず、引き継ぎ資料を渡してすぐ離れると、自走できるか確かめられません。
次の改善を社内で選ぶ
最初の仕組みが動いた後、社内担当者が次の課題を選び、現状を測り、利用者との合意を作れるか確認します。新たな技術判断に外部の助けを借りても、目的と優先順位を自社で決められるなら、内製化は進んでいます。
内製化を妨げる三つの状態
判断者が外部に寄り過ぎる
FDEが業務上の優先順位まで実質的に決めていると、支援終了後に社内で改善が止まります。責任者が比較案を理解し、選択理由を残す場を設けます。
資料だけで引き継ぎを終える
設計書や操作手順がそろっても、担当者が使えなければ成果にはなりません。代表的な問い合わせや例外を実際に扱い、手順と判断の両方を試します。
一人にだけ知見が集まる
社内の一人が理解しても、その人が不在なら改善を続けられません。業務の責任者、現場の利用者、情報システム担当に必要な知見を分けて共有し、記録の置き場所を決めます。
外部に任せる範囲は変化の速さで見直す
変わり続ける業務の判断は社内に置く
一度作って終わる業務と、毎月ルールが変わる業務では、社内に必要な力が異なります。変更の頻度が高い業務ほど、現場の要望を集めて優先順位を付ける人を社内に置きます。FDEに実装を頼む場合も、変更の目的、影響を受ける部署、受け入れ条件は社内で説明できるようにします。
専門作業の外部活用は続けてよい
高度な技術検証や一時的な開発量の増加を、すべて社内で抱える必要はありません。外部へ任せる作業ごとに、成果物の受け取り方、変更の承認者、運用後の相談先を決めます。内製化の目標は外注比率の数字ではなく、業務の方向を自社で選び、外部の提案を評価できることです。
運用と統制を引き継ぐときの確認項目
権限と記録を業務の流れに結び付ける
運用担当が使うアカウント、データへのアクセス範囲、変更履歴の確認方法を一覧にします。誰が閲覧し、誰が変更し、問題が起きたら誰に連絡するかまで業務フロー上で確かめます。アクセス権の設定だけを渡しても、担当者がその意味を理解していなければ判断できません。社内の情報管理方針との整合も、実運用に入る前に確認します。
保守と改善を別々に担当決めする
日々の問い合わせや障害対応と、新しい機能の優先順位付けは別の仕事です。前者は初動、切り分け、連絡経路を、後者は要望の評価と決定者を決めます。FDEの支援が終わる時点で、どの作業を社内で行い、どこを外部へ依頼するかを書面で確認します。担当が空白のまま残ると、小さな不具合が現場の利用停止につながり得ます。
引き継ぎの完了は実地で判定する
社内担当者が手順を読みながら、権限の変更、よくある問い合わせ、想定外の入力への対応を実際に試します。必要な資料が見つかるか、判断が必要な場面で決裁者へ届くかを見て、詰まった点を修正します。こうした試行を経て、資料の納品と業務の自走を区別できます。
まとめ
FDEを活用した内製化では、社内オーナー、共同作業、運用成果物、社内主導の実践、自走条件を最初から設計します。完成したものを受け取るだけでなく、問題の見極めと次の改善を自社で選べるかまで確かめてください。
内製化の計画を実行に移す際は、外部FDEと自社の役割、必要な費用、発注前に合意する条件を具体化します。次の3点セットを、導入から社内説明までの検討材料にしてください。
