STAGE 4・従業員 〜300人（目安）
ひとりからチームへ
情シスチームが複数部署の脱Excel要望を同時に抱えたときの優先順位付け
100〜300人規模では複数部署から脱Excel要望が同時多発します。1人で抱えていた頃とは異なる、チーム体制での優先順位の決め方と、断る・待ってもらう際の伝え方を解説します。
事業拡大期の基幹システム発注、要件を複数部署から集める進め方
基幹システムの刷新は複数部署が利用者になります。部署横断ヒアリングをどう設計し、対立する要望をRFPに落とし込むかを100-300人規模の実務目線で解説します。
兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方
ひとり情シスに2人目・3人目が加わる移行期は、責任範囲を曖昧にしたまま進めると重複と抜け漏れを同時に生みます。システム別・業務別の分担表の作り方と切り分けの基準を解説します。
従業員100人超えで必要になるセキュリティ体制、ひとり対応の限界ライン
セキュリティインシデントの初動をひとりで担ってきた体制は、従業員100人を超える規模で構造的な限界を迎えます。何が限界のサインで、どう体制を見直すべきかを整理します。
シャドーAI利用者が数十人規模になったときの是正の進め方
無許可のAI利用が数人にとどまらず数十人規模に広がっていた場合、個別注意では対応しきれません。100〜300人規模で組織的に是正を進める手順を解説します。
全社台帳をシステム化した後、部署ごとのローカルExcelが復活する問題
システム化して満足した数ヶ月後、部署ごとのシャドー台帳が静かに復活する現象は珍しくありません。100〜300人規模で再発を防ぐ運用ルールと兆候の早期発見方法を解説します。
脱Excelを1人で決めない。チーム体制での移行先選定・承認フロー
複数人が関わる100〜300人規模では、移行先の選定を1人の判断で進めると後で覆されます。チームでの合意形成と承認フローの設計方法を、具体的なステップとともに解説します。
ひとり体制から複数人体制へ。情シスチームの役割分担をどう設計するか
増員が決まってから慌てて分担を決めるのではなく、増員の前段階からどう業務を切り分け、どう引き継ぎを進めるかを時系列で整理します。100〜300人規模の体制移行プロセス全体の設計図です。
開発会社が1社依存になっている状態からの脱却、チーム体制での進め方
1社依存からの脱却は、複数人の情シスチームだからこそ計画的に進められます。誰が何を検証し、どう合意形成するかという意思決定プロセスを解説します。
部署ごとにバラバラだった開発会社の評価基準をチームで統一する
属人的な発注判断から脱却するため、100〜300人規模で開発会社を評価する基準をチームで標準化する方法を、評価項目の設計からスコアリングの運用まで解説します。
