社内ルール
定例会議・承認フロー・受注の流れ・バージョン管理・資産保管
文言の定義
社内で使用する用語の定義です。責任者と作業担当者は必ずしも同一人物ではなく、ほとんどの場合は別人格です。
| 用語 | 定義 |
|---|---|
| 責任者（管理者） | 案件に限らず担当の仕事全体を把握して納期・品質に責任を持つ者 例）社内を綺麗に保つことは資料整理なども仕事の一つ |
| 営業担当者 | 売上の数字・目標達成に責任を持ち評価に直結する者 |
| 作業担当者 | 案件に限らず作業する仕事に対して納期・品質に責任を持ち評価に直結する者 |
部署別タスク管理責任者
営業関連タスク
事業企画部部長
開発タスク
開発チームリーダー
総務関連（その他）
総務・事務リーダー
保守サービス
保守サービスチームリーダー
総務・福利厚生AI
📌 使いどころ
有給、お見舞金、育児休暇など、総務・福利厚生に関する確認はまず総務AIを利用する。
- 質問例: 有給は？ / お見舞金は？ / 育児休暇は？
- 回答内容を申請・運用へ反映する前に、必要に応じて総務・事務へ最終確認する
総務AIを開く
NotebookLM 上で総務・福利厚生の質問に回答します。
定例会議
全体定例会議
隔週火曜日
毎週火曜日から隔週火曜日へ変更
運用責任者: 保守サービスチームリーダー
開発会議
毎週開催
毎週、会議内で次回日程を決める。
運用責任者: 開発チームリーダー
営業会議
毎週開催
毎週、会議内で次回日程を決める。
運用責任者: 保守サービスチームリーダー
全体定例会議の運用
隔
隔週火曜日に開催
全体定例会議は毎週火曜日開催から隔週火曜日開催へ変更する。運用責任者は保守サービスチームリーダーが担う。
共
開催時の共通ルール
議事録作成人を設置し、参加者でリアルタイムに議事録を記録する。必要な資料は事前共有し、会議内で決定事項と次回検討事項を明確にする。
次
開発会議・営業会議の次回日程
開発会議と営業会議は毎週開催し、どちらも会議内で次回日程を決める。開発会議の運用責任者は開発チームリーダー、営業会議の運用責任者は保守サービスチームリーダーとする。
アジェンダ必要項目
- 課題：具体的な課題の概要（個別ではなく全体で結論を出すべき課題に限る）
- 決定事項・次回検討事項を明確に記録する
- 全ての事案に関して期日を設定する
📝 議事録の追加・訂正
追加や訂正は赤文字で記入すること。
評価ポイント
営業・新規-リプレース
事業企画部部長
開発タスク
開発チームリーダー
- 保守評価ポイント及び新規-リプレース評価ポイントシートは毎月5日までに締める
- 毎月6日前後に担当役員・マネジメントチーム層でレビューを行う
新規問い合わせ対応
📌 対応責任者：事業企画部部長
- WEB・電話からの問い合わせに対して1営業日以内に電話でリアクションする
- 既存クライアントからのシステムに関する新しい「要望」または「相談」は、その場で携帯で事業企画部部長または開発チームリーダーに連絡する
業務進捗管理（xeroPM）
xeroPMを開く
日報・カンバン・顧客管理を同じツールで運用します。
| 機能 | 使い方 |
|---|---|
| 日報 | xeroPM の日報機能へ、当日の作業内容・結果・補足を記録する |
| タスク管理（カンバン） | xeroPM のカンバンで案件ごとのタスクを管理し、進捗に応じてステータスを更新する |
| 顧客管理 | xeroPM の顧客管理機能で顧客・案件情報を確認し、必要な情報を参照する |
- 日々の作業結果はxeroPM の日報機能へ記録する
- 継続タスク・開発タスク・対応タスクはxeroPM のカンバンで管理する
- 顧客情報・案件情報の確認が必要な場合はxeroPM の顧客管理機能を参照する
- 突発的なタスクの優先順位は例外なく都度上長に確認し上長判断を行う
- xeroPM 運用の不明点・不都合は都度上長に報告連絡相談する
電子化ルール
📌 総務関連責任者：総務・事務リーダー
税務関連において法的保管義務がある紙書類以外は、基本的に作業担当者が全て電子化を行い紙書類は破棄する。
- 設計書・仕様書等を含むすべての書類を電子化する
- 法的保管義務がある紙書類は除外する
- 電子化完了後は紙書類を破棄する
承認フロー
社長
社長
上長
上長
①
担当者が資料を作成・自己確認
明確で分かりやすい表現を心がける。専門用語・難しい言葉は避け平易な表現で意思疎通を図る。説明できない部分は別紙を作成しリンクを貼る。
②
上長がレビュー・承認
上長は不明点があるまま承認しない。十分な確認をし、しっかりと内容を把握した上で承認をする。
③
担当者 ＆ 社長が最終確認・承認
社長からのコメントに関しては上長が対応をする。
⚠️ 上長への注意事項
後に誤解やトラブルが生じる可能性があるため、不明点があるまま承認を行わないこと。
受注の流れ
見積書・注文書運用（KCS販売管理）
📌 使用ツール
見積書・注文書の作成は KCS販売管理 を使用する。見積書で合意する作業範囲と要件定義書は一対一で対応させ、受注後は同じ案件の正式要件として管理する。
⚠️ 開発着手の前提
要件が曖昧な状態では絶対に開発を進めない。見積内容と対応する要件定義書をクライアント確認済みの状態にしてから、概要設計・画面設計・開発へ進むこと。
1
KCS販売管理で見積書を作成し、作業範囲と条件を明記
金額・工数・納期・支払い条件に加え、何を作るかの範囲を見積書と紐づけて整理し、必要に応じて事業企画部部長へ確認を依頼する。
2
要件定義書を作成し、KCS販売管理へ添付
KCS販売管理の案件に、見積書と一対一で対応する要件定義書を必ず添付する。要件定義書添付なしで案件を進めない。
3
クライアントに見積内容と要件定義書を確認してもらう
注文書だけでなく、要件定義書にもクライアント確認印または承認記録を残す。開発範囲の合意が取れていないまま着手しない。
4
要件が決め切れない場合は準委任契約へ切り替える
仕様確定前に工数だけが進む状態を避けるため、要件を確定できない案件は請負のまま進めず、クライアントと準委任契約を締結した上で整理・検討を進める。
5
注文書控え（または発注書）を受領し、売上計上へ進む
受領後、KCS販売管理の内容と差異がないか確認し、各担当または総務・事務が予実管理に注文売上を計上する。
6
注文書控えを所定の場所に仮保管し、正式保管する
所定の場所（吉井さんの机の上の保管箱）へ保管し、その後事務・総務が注文ファイルへ綴じてキャビネットへ正式保管する。
📌 必須ルール
要件が曖昧な状態で絶対に開発を進めない。見積書に対して要件定義書が未添付、またはクライアント確認が取れていない案件は着手不可とする。要件を決め切れない場合は、請負ではなく準委任契約で進める。
注文書の確認事項
- 見積書に対応する要件定義書が KCS販売管理 に添付されているか？
- 要件定義書にクライアント確認印または承認記録があるか？
- 納期は明記してあるか？
- 支払い条件は明記してあるか？
- 金額は正しいか？
バージョン管理
📌 表記ルール
バージョン情報はメニュー画面の適切な位置に表示する
バージョン番号の体系：ver 1.00.00
| 桁 | 変更のタイミング | 例 |
|---|---|---|
| 第一桁 | リニューアルなど全体的なバージョンアップ | ver 2.00.00 |
| 第二桁 | ファイル（データ・WORKファイル）の構成を変更した場合 | ver 1.01.00 |
| 第三桁 | 軽度な修正（ファイル構成に依存しない） | ver 1.00.01 |
資産管理のルール
- Googleドライブに最新バージョンを置く
- バージョン管理フォルダではコピーを作成しない（データ肥大防止）
- テストで使用するファイルは必ず最新バージョンへ更新する
- 変更履歴は画面設計書の改訂履歴で必ず管理する
資産の保管場所・ディレクトリ構成
📌 保管パス
共有ドライブ > 00.CLIENT > クライアント名 > 開発資料 >
📁 開発資料
📁 要件定義・設計 （要件定義書・画面設計書等）
📁 議事録 （開発MTG議事録等）
📁 最新プロジェクト(社内) （開発版社内最新プログラム資産）
📁 最新リリース・納品 （リリース版プログラム資産・クライアント機器のバージョン記載）
📁 ファイル受け渡し （社内でのファイル受け渡しフォルダ）