学習・オンボーディング
業務リファレンス
ナレコム 3つのコアバリュー
お客様の期待を超える最高のサービスを提供
速さ・品質・提案力で、常に期待の一歩先を行く。24時間以内の初回レスポンスが基本。
一人一人が会社を担う主力選手であること
一人ひとりが当事者意識を持ち、オーナーシップを発揮する。「誰かがやる」ではなく「自分がやる」。
チームワークを超えた強い絆で最大の力を発揮
ポジティブに、オープンに。心理的安全性のある環境で、互いの成長を支え合う。
オンボーディングロードマップ（5週間）
30日マイルストーン
学習リソースカタログ
21本の教材（4カテゴリ） 閲覧済み: 0/21ナレコム豆知識
SNS発信数
チームワークの証。全員で発信する文化。
キャパシティルール
勤務時間の40%を技術研鑽に充てる文化。
3大パートナー認定
AWS + Microsoft + Databricks の国内唯一のトリプル認定企業。
Databricks / PySpark トレーニング
12カテゴリ / 3難易度 / 間隔反復学習今週の学習ガイド
復習 40% / 弱点補強 40% / ストレッチ 20%スキルチェック実施後に学習ガイドが生成されます
上の「診断を開始」ボタンでスキルチェックを実施すると、あなたに最適な学習プランが表示されます
スキルチェック
12カテゴリの現在のスキルレベルを診断します。結果に基づいて最適な学習プランを提示します。
スキルマップ未作成
上の「診断を開始」ボタンでスキルチェックを実施すると、12カテゴリのレーダーチャートが表示されます
AI クイズ生成Azure OpenAI
AIがあなたの弱点に合わせたクイズを動的に生成します
チャレンジライブラリ（12カテゴリ）
復習キュー
間隔反復: 1, 3, 7, 14, 28日- 復習予定はまだありません チャレンジを完了すると自動で復習スケジュールが設定されます
学習ログ
基礎情報
業務フロー・オフィス運用・案件ルールナレコムの業務プロセスに関する基本情報です。いつでも参照できます。分からないことはナレコムくんに質問してください。
1. 「リード」に関するアプローチ
定期メルマガによる活動
マーケティングチームより月1回の定期メルマガの発信:
- プレスリリース
- ソリューション、事例
- 技術ブログ
- 展示会、イベント、ウェビナーのお知らせ
- その他トピック
BDによる個別ナーチャリング活動
リード情報に対して案件化を目的とした個別ナーチャリングの実施:
- 興味喚起のためのメール、電話での連絡
- オンラインMTGの打診
- オンラインMTGでのニーズ深堀り、BANTヒアリング
- 案件化
2. 「リード」に関するオペレーション
オペレーション 1: ナーチャリング活動の記録
リードに関してナーチャリング活動を実施。活動内容は「Timeline」に記載していく。案件化した場合は、「見込みありと評価」をクリック。
オペレーション 1 補足: リード情報の入力
| 項目 | 説明 |
|---|---|
| リードソース | リードを獲得した経路を記載 |
| 評価 | リードの温度感に応じて選択（例: Warm（追跡中）） |
| 状態 | 現在のステータスを記載（例: 接触済み・関心あり） |
| 所有者 | 担当者を設定 |
※優先的にアプローチすべきリードを選別するための情報。漏れなく記入すること。
オペレーション 2: 見込みありと評価
「見込みありと評価」をクリックしたら右側がポップアップするので、評価をするをクリックし、画面が遷移したら完了をクリックする。
オペレーション 3: 営業案件の作成
営業案件が自動的に作成されるので、案件名の修正及び必須事項を記載の上、上書き保存する。
必須入力項目:
- 案件名
- 取引先担当者
- 取引先企業
- 通貨
- 売上予定金額
- 決定権の有無
- 変きの種別
- 案件フォーキャスト
- 予測スコアリング
- 粗利(予定額)(円)
- 確率
オペレーション 4: リードの再アクティブ
営業案件化した場合はリード情報は削除はされないが、「読み取り専用」となっている。案件化したものが失注になった場合は、「リードの再アクティブ」をクリックして、再度ナーチャリング活動を継続していく。
3. 企業形態の運用ルール
| 顧客カテゴリ名 | 位置づけ | 2Q開始時点の顧客数 | 運用ルール |
|---|---|---|---|
| 重要ターゲット | 会社としてレビューする最重要顧客 | 9社 | アカウントプラン作成及びレビューを実施 |
| 既存ターゲットユーザー | 売上貢献が高く、戦略上重要な既存顧客 | 63社 | カスタマーサクセスの対象顧客 |
| 既存ポテンシャルユーザー | 追加提案や深耕によってポテンシャルが見込める既存顧客 | 126社 | 月1回以上コンタクト必須、Q毎のアクション作成、Q毎にレビュー対象 |
| 既存その他ユーザー | 取引規模や戦略的重要性が低い既存顧客 | 35社 | 不要なものは削除、ポテンシャルへのアップロードは半期毎に検討 |
| 新規ターゲットユーザー | 売上貢献が見込める、戦略上重要な新規顧客 | 176社 | 2月に1回以上コンタクト必須、Q毎のアクション作成、半期毎にレビュー |
| 新規ポテンシャルユーザー | 新規ビジネス開拓のポテンシャルが見込める新規顧客 | 792社 | 不要なものは削除、Qに1回以上コンタクト |
1. 働き方/リモートワーク運用の一部見直し（Return To Office）
千葉オフィス/熊本オフィス共通
- 原則、週3日以上は出社
- リモートワークをする場合は、前日までに上長に申請
- RDPは基本的に利用しない（利用が必要な場合はリモートワーク申請と併せて利用承認が必要）
- 2時間以上席を離れる場合は荷物をもって移動してもらう
- 基本は9時から出社、ただし満員電車をさけるための時差出社あり
- 夜勤は安全上リモートワークとなっているので、現状どおりの運用
2. オフィス運用
千葉オフィス
- 研修に紐づいた活動は基本的に丸伝で行う
- 1on1/2on1は基本的に丸伝で行う（極力会議室の利用は避ける）
- 会議室はお客様/パートナーとのMTG/社内の重要MTGを優先
- 複数人の社内会議は、オンラインで接続するのではなく、会議室を利用するようにする
熊本オフィス
- 機密情報がない作業は共用スペースで実施する
- 機密情報を扱う場合は、DevOps運用ルームを利用する（現在は食事や会議で利用しているが、食事は自席で実施）
- エアコンへの対策については別途検討
3. PCの管理、利用
※VDIの整備が完了するまでの暫定ルール
- PCは退勤時に電源を落とした状態でチームごとのPC保管ロッカーに施錠して保管（もしくは持ち帰る）
- くまラボはDevOps運用ルームに保管して部屋の施錠
千葉オフィス
PCの保管方法:
- チームごとのPC管理ロッカーに保管、もしくは持ち帰り
リモート勤務時:
- RDPは基本的に利用しない（どうしても利用が必要な場合はリモートワーク申請と併せて利用承認が必要）
- RDPを利用する場合は、出勤出社している社員に電源ON依頼、業務終了時に電源OFFを必ず実施
- RDPのPCは20時には全PCをシャットダウン
その他 千葉、熊本共通:
- PC 各拠点で利用しているPCのラベリングを行い管理を行う
- パスワードを16文字に変更する
4. ロッカー、書類ボックス運用
千葉オフィス
- ロッカーは共有とし、テンポラリーで利用（暗証番号は0000がデフォルトで自分でパスワードを変更して利用する）
- 退勤時はPCは持ち帰りorチームごとのPC管理ロッカーに保管して施錠する
- 飲み会等があるときはPCは持ち帰りせずロッカーに保管する
- 書類はおかない。不要なものはシュレッターにする（シュレッターを別途用意する）
- DICにはPCは置かない、持ち帰りor丸伝ロッカーに保管する運用にする
熊本オフィス
- 社員ロッカーは固定、アルバイトは共有とし、どちらでも原則私物を置かない
- ロッカーには通勤用バッグ、コードなど仕事中に保管する（机の周りには置かない）
- 退勤時はPC持ち帰りorロッカーに電源を切って保管して施錠する
- 飲み会等があるときはPCは持ち帰りせずロッカーに保管する
- ロッカーに入り切らない共用のものはいつも使うもの以外、レンタル倉庫に保管する。年2回、レンタル倉庫の在庫チェックを行う
- 書類はTeamsアプリのカメラでスキャンを行い、必要なメンバーに共有し原本が必須でないファイルは削除する
ロッカーの割り振り
ロッカーの割り振りはチーム毎とする。
| チーム | ロッカー構成 |
|---|---|
| 1チーム | テンポラリーロッカー x 3 |
| 2チーム | テンポラリーロッカー x 3 + 4/1入社研修メンバー用 x 2 |
| 3チーム | テンポラリーロッカー x 3 + 4/1入社研修メンバー用 x 2 |
| PEチーム | テンポラリーロッカー x 3 + 管理ロッカー x 2 |
| その他 | テンポラリーロッカー x 3 + マーケチーム + バックオフィスチーム |
※チームロッカーはPC及びヘッドセット等業務利用する物品の保管用として私物の保管には利用しない。
※テンポラリーロッカーはデイリーで活用して帰社時には中は空にするようにお願い致します。（週末にロッカー内にあるものは処分する運用にします）
1. BDチーム編成（4チーム制）
| チーム | メンバー | 代表顧客 |
|---|---|---|
| 1チーム | リーダー + メンバー | クボタ、カルビー、トヨタ自動車、黒田電気 等 |
| 2チーム | リーダー + メンバー | ビデオリサーチ、シュッピン、SBI、三菱商事 等 |
| 3チーム | リーダー + メンバー | 山口県教育委員、中部電力、名古屋大学、行政システム 等 |
| PEチーム | リーダー + メンバー | - |
※既存顧客の担当者変更時期は要検討
※新規顧客/ナーチャリングは業種に合わせたチームにて原則担当する
2. チーム毎の担当業種（4チーム制）
| 担当チーム | 大カテゴリ | 中カテゴリ（東証17カテゴリ+公共・教育・病院） |
|---|---|---|
| 1チーム | 製造 | 電機・精密(YRL)、素材・化学、鉄鋼・非鉄、食品 |
| 自動車 | 自動車・輸送機(トヨタ) | |
| 2チーム | メディア&コミュニケーション | 情報通信・サービスその他(カタリスト、廣済堂) |
| 金融 | 金融（除く銀行）、銀行 | |
| 3チーム | 小売 | 小売(イオン)、商社・卸売(三菱商事)、運輸・物流(内外日東、阪神阪急、京王電鉄、エイジス) |
| 4チーム | 公共・社会インフラ | 不動産、建設・資材、エネルギー資源、電力・ガス(中電)、公共(行政シス、赤十字、JPメディア) |
| ヘルスケア | 医薬品/病院(武田薬品、マッキャン) | |
| 教育 | 文教(教育委員会・大学)(山口県教育、立命館、山梨大学、名古屋大学生協) |
※グループ会社で業種が異なる場合は親会社の業種に依存します
3. 週次MTG案
月曜: 案件創出計画（各チーム 1時間）
目的: チームの進捗状況と活動のすり合わせ
- （リーダー）チームの目標と進捗の共有（受注と創出金額）
- （リーダー）目標達成までに必要な活動の共有
- （チームメンバー）今週の活動予定リスト
- （チームメンバー）活動からの創出予定金額、受注予定金額
- （リーダー、チームメンバー）アクション内容の過不足の調整
- （リーダー、チームメンバー）DRMへの登録確認
- Qの受注目標に対する進捗とネクストアクション
木曜: 案件創出レビュー&振り返り（各チーム 30分）
目的: 週初の目標と現状のすり合わせ
- （チームメンバー）活動予定の結果報告
- （リーダー）チームの目標と進捗の確認
- （リーダー、チームメンバー）目標達成に向けた今週の残アクションの確認
- （リーダー、チームメンバー）チームのミッションに対してのチームとしての活動まとめ（WinMTG向け）
- （リーダー、チームメンバー）DRMへの登録確認
- Qの受注目標に対する進捗とネクストアクションの結果共有
- 来週の案件創出活動のテーマ
※案件創出活動レビューは基本翌日にはキャッチアップを行う。デイリーの報告内容: こんな話が聞けたや気づき、他のチームにも共有したほうがいい内容など
Deal Review Meeting（毎週火木 14:30-16:30）
参加者は担当・リーダー・決裁者の内1名以上。案件単位でブロックし、当面は30分を1案件用として割り当てる。
- 火金のDeal Review Meeting枠に予約を入れる
- 資料は事前共有を行い、全員目を通した状態で行う
- 30分枠をブロックし、実施する
- 更新案件も含めてすべてレビュー対象（新規: 全案件、既存・更新: 100万円以上）
4. Deal Review の6フェーズ
フェーズ1. 提案着手の承認会議
目的: やる・やらないの審議（基本は、どうやるか）
共有事項: 背景、要望、BANT、リスク、提案実行体制案
審議項目: ライセンスについて、提案実行体制の検討、アクションプラン、提案スケジュール
必要なもの:
- 案件概要: 案件名、顧客名、取引実績、案件背景、ライセンスの購入状況、BANT（最低限 Budget・Timeframe）、案件ゴール、必ずライセンス提案を含める
- リスク評価: 主要リスク（取るリスク、取れないリスク）、対応策、ポテンシャル、競合有無
- リソース評価: 提案体制、想定リソース、想定コスト/利益（100万単位でOK）
- スケジュール: 提案時期、受注予定時期、構築期間、リリース予定日
フェーズ2. 提案書提出前レビュー
目的: 提案リスク判断
共有事項: 提案書、想定原価、事前検証有無
審議項目: 提案書バリューチェック（ライセンス提供・運用/保守）、原価レビュー（含む検証）
※パートナーへ発注を想定する場合は必ず3社以上のコンペを取り見積もりが比較できるようにすること
必要なもの:
- 基本情報と背景（案件名、顧客名、取引実績、ライセンスの購入状況）
- 提案内容と価値（提案書、ライセンスに対する提案、運用・保守に対する提案、ゴール）
- 予算・コスト・利益（顧客予算、提供価格、想定原価、利益）
- リスク評価と競合分析
- 実行計画と顧客評価（事前検証有無、ポテンシャル、承認プロセス、導入体制、スケジュール）
フェーズ3. キックオフ
目的: プロジェクトリスク判断
共有事項: ゴール（クローズ）、構築体制、想定工数、想定原価
※パートナーへ発注する場合は必ず承認を取る。未承認のものは支払いが行えません。
必要なもの:
- プロジェクトゴールと成功基準（計画書、成功基準の明確化）
- リソースと体制（チーム編成・役割分担案、パートナー発注有無）
- スケジュールと工数（タスクスケジュール、マイルストーン）
- コストと利益（想定原価、提供価格、利益見込み）
- リスク評価と管理（品質管理計画、エスカレーションパス）
フェーズ4. 中間レビュー
目的: 当初受注内容からゴール・リソース・スケジュールが変わりプロジェクトリスクが高まった際の対応判断
- プロジェクトゴールと成功基準（計画書、ゴール基準、相談事項）
- リソースと体制の変更
- スケジュールと工数（進捗状況、予実の確認）
- コストと利益（当初想定 vs 現在の想定原価）
- リスク評価と管理（相談事項のリスクと対策）
フェーズ5. 振り返り
- プロジェクト全体の振り返り（目標達成状況、主要成果、顧客価値）
- 工数とコストの分析（想定工数 vs 実工数、利益率の差異分析）
- リスクとトラブルの確認（原因、対応手順と結果、改善点と教訓）
- 次のプロジェクト（継続案件の有無、他案件への展開）
フェーズ6. 失注分析（500万以上の案件）
失注した案件の原因を明確化し、将来の提案や営業活動の改善につなげる。
- 案件概要（案件名、顧客名、失注時期、取引実績、ゴール）
- 提案内容（概要、提案金額と競合比較、スケジュールと体制）
- 競合状況（他社動向、強み・弱み）
- 顧客の評価（ポジティブ/ネガティブ要素、他社選定要因）
5. 見積もり承認〜稟議の考え方
| プロジェクト予算/粗利の考え方 | リーダー/マネージャー | 役員 | 役員ALL |
|---|---|---|---|
| 案件金額50万以下/粗利30%以上 | ● | ||
| 案件金額50万以下/粗利30%以下 | ● | ||
| 案件金額50万〜100万/粗利30%以上 | ● | ||
| 案件金額50万〜100万/粗利30%以下 | ● | ● | |
| 案件金額100万以上/粗利30%以上 | ● | ● | |
| 案件金額100万以上/粗利30%以下 | ● | ● | ● |
備考:
- 粗利が低い場合、ビジネスとして魅力があるものか、ナレコムとしてやるべきなのかを判断するため
- パートナーに発注をする場合は金額の大小に関わらず社長承認まで必要とする
1. 売上/粗利管理のためのオペレーション
全体フロー（新規案件）
ナーチャリング → 提案・見積 → 受注・契約 → 請求・回収
| フェーズ | 顧客 | BD(セールス) | BD/dev(構築・保守) | 営業事務/経理 |
|---|---|---|---|---|
| ナーチャリング | 情報提供・ヒアリング | 見込顧客登録 → 顧客登録・案件登録 → 商談状況更新 | - | - |
| 提案・見積 | 案件化 → 提案・見積 | 見積作成/原価計算 → 見積承認 | - | - |
| 受注・契約 | 発注 → 契約書締結 | 商談ステイタス更新 | 受注依頼 → 作業依頼 → 作業実施 → 作業完了 | 受注登録 → 請求登録 |
| 請求・回収 | 検収合意 → 検収書記載 → 請求 | 売上確認 → 売上確定 | 送付依頼 | 検収書と請求書発行 → 入金確認 → 完了 |
※売上金額・売上予定日・粗利金額に変更が生じた場合はBOチームに連絡すること
※更新案件の請求はBO担当者が対応。受注依頼の際に過去請求書の共有をお願いします。
2. Dynamics登録〜入金確認完了までのまとめ
BD: 案件の発生から受注までを主導
- Dynamics案件登録・商談状況の更新
- 見積作成・原価計算
- 受注依頼（営業事務への引き渡し）
BO: 受注以降のシステム登録・書類発行を担当
- 受注依頼を受けて受注処理
- 検収書作成（※依頼あれば送付）
- 請求書作成（※BO担当者が対応）
- 入金ステイタス更新（回収業務の完結）
3. 製品品目登録
タイミング: Dynamics見積書作成前
- Dynamics価格表から該当項目(D列)を探し登録を行う
- 製品品目未登録のものがあれば管理者に依頼する
- マネージドは項目ごとに製品品目を入力する
- 単価(税抜)、税額を別で入力する
- 表示価格が異なる場合は、価格指定で「出荷単価ごとの価格」を手入力
4. 見積登録
タイミング: Dynamics製品品目登録後
※製品品目に登録した内容でその後の見積〜請求書まで金額が固定となるため、内容に変更があった場合は製品品目から再度作成する
5. 粗利の出し方
タイミング: Dynamics見積登録前
格納先: com_sales > Dynamics関連 > 売上管理 > 粗利額確認シート
粗利額確認シートのフォーマット
- ファイル名:
顧客_案件名.xlsx - ファイル保存先: 17期：2024年10月-2025年09月 ※売上日基準
- ファイル保存規則: 案件ごとにファイルを分ける
原価テーブル
| 項目 | 原価の考え方 |
|---|---|
| AWS利用料 | 販売価格の100% |
| AWS代行費用 | 0 |
| Azure利用料 | 販売価格の85%(*0.85) |
| Azure代行費用 | 0 |
| Azureバウチャー費用 | 固定（Dynamics粗利用） |
| Partnerの保守・作業費用 | Partner作業金額 |
| SSL証明書 | 種類毎に異なる |
| Deep Security as a Service | 19,800/台(税抜) |
| マネージド | 価格表_v76 N列の実原価 |
| その他（独自ドメイン取得管理） | 200/台(税抜) |
| Trend Micro Cloud One ライセンス費用 | CEC請求書のDeep Security IT Protection Serviceが該当（単価 19,800円、CEC請求書上に 2,000円乗っているので合計額に2000足す） |
| Trend Micro Cloud One 運用サポート費用 | 原価 0 |
| バックアップ世代数追加（2世代以降） | スループット表 266行目 |
| cloudfront転送量 | 価格表 CDN欄 |
※概算工数のナレコム人件費は含みません。ナレコム側の作業のみで実費0の場合は原価0となります。
6. 受注
押印済注文書や内示を頂いたらBOに受注登録依頼をお願いします。
以下共有をお願いします:
- 該当Dynamics
- 粗利額確認シート
- 受注日
- 売上日（作業完了日）
売上日の考え方
| 案件種別 | 売上日 |
|---|---|
| 初期のみのもの | |
| SSL証明書系 | 作業開始日 |
| 構築・開発作業 | 作業完了日 |
| バウチャー | |
| バウチャー | 納品日 |
| 継続的なものの開始月 | |
| マネージ・保守 | 開始月月初 |
| 請求代行 | 開始月月初 |
| 継続的なものの2か月目以降 | |
| マネージ・保守 | 月初 |
| 請求代行 | 月初 |
7. 検収基準について
発注者が納品された物品やサービスが、契約や発注内容に従って適切に納品・提供されたかを確認し、その品質や数量が問題ないかを検査するプロセスです。
作業完了・検収をもって、支払いの手続きが進行します。
検収フロー
要件を満たした場合 → 客先へ送付 → 客先担当者押印をもって完了
請求フロー
検収終了 → 請求書発行 → 入金確認 が標準フロー
請求が翌々月等、例外対応は管理者・役員の事前承認を得て請求書発行依頼時にご連絡ください。キャッシュフロー厳守のため、作業完了後は検収および請求を迅速にご対応ください。
検収要件（6項目）
- 契約書・発注書に定められた納品条件（成果物、範囲、納期）を満たしていること
- 合意済みの成果物を顧客に提出し、受入テスト・確認を経て承認を得ていること
- 納品方法・日付が記録され、納品証跡が残っていること
- 社内品質管理チェックが完了していること
- 残課題がある場合は、顧客と書面またはメールで合意し、対応内容・期日を明確化していること
- 検収書を顧客から受領していること
社内品質管理チェックの内容
- 形式的品質（見た目・表記の統一）
- 技術的品質（コード・動作テスト）
- 納品物の完全性（揃っているか）
- リスク・コンプライアンスチェック（顧客提供物に含めてはいけない社内専用情報が入っていないか等）
8. 新規で月次請求を始める場合のフロー
月次請求に必要な情報:
- 初回請求の対象期間
- いつまでに発行するか（通常、翌4営業日発行当月末日支払い期限）
- 以下リンクのシートへa〜dの対応:
- a. ファイルは読み取り専用で開き別名保存でご利用ください
- b. 基本情報シートのB列を埋めてください（宛先/支払いサイクル/発行方法/アドレス/明細有無 等）
- c. AWS利用料の他に保守等があればフォーマットシートに品目/金額いれてください
- d. 基本的に1アカウントにつき1枚の請求書で代行費用はAWS利用料の10%（最低費用5,000円）。複数アカウント合算請求や代行費用パーセンテージの特別設定があればお知らせください
- 対象AWS アカウント ID
上記1〜4を揃え、BO担当者・管理者へ連絡してください。
PDF原本ダウンロード
業務に関する質問
ナレコムくんが業務フローに関する質問に回答します上記の業務フローについて分からないことがあれば、ナレコムくんタブで質問してください。PDF の内容に基づいて回答します。