02納品の目標
この仕事ができるようになると、業務はどう変わるのでしょうか？
制度についての質問は、一人の小さな疑問に見えるかもしれません。その裏では、同僚が質問を取り次ぎ、制度に詳しい人が作業を止めて資料を探し、見つかった回答を同じ経路で返していることがあります。毎回こうなると、業務をよく知る人ほど、判断が必要な仕事にまとまった時間を使いにくくなります。プロジェクトが役に立ったかを見るには、この種の問い合わせを追います。質問した人が自分で調べられたものは何か、詳しい人への取り次ぎが残ったものは何か。その理由が資料を見つけられなかったためなのか、本当に業務上の判断が必要だったためなのかも確認します。この違いから、日々の仕事がどう変わったかが見えてきます。画面の入口がいくつ増えたかより、こうした違いのほうが日常業務の変化を具体的に示します。
同じ小さな仕事 · 以前の進め方- 社員が質問する
- 同僚が質問を取り次ぐ
- 詳しい人が作業を止めて資料を探す
- 回答を元の人へ返す
今回の成果によって、プロジェクト責任者が確認したい変化確認済みの資料を探す仕事を、質問した人自身が行えるようにします。制度に詳しい人は、本当に判断が必要な例外に時間を使えるようになります。
03対象範囲と境界
今回は、どこまで対応するのでしょうか？
「企業のナレッジベースを作る」という言葉だけでは、今回どこまで対応するかはまだ分かりません。総務は承認規程の確認を、営業は商品資料の検索を考えるかもしれません。技術担当者には、資料がどのシステムから来るのか、どの役割の人が閲覧できるのかも必要です。どの理解も自然ですが、接続する資料も開発する仕事も異なります。着手前に、今回の業務担当者が実際に行う仕事を選びます。発注側と、どこから始め、どの資料を使い、最後にどの役割の人が何を完了するかを順に確認します。その経路に沿って、要件・見積もり・日程の内容を照らし合わせられるようにします。
- 今回、誰が使うか同僚への回答を担当する総務担当者が、自分のアカウントで入ります
- 今回、どの資料を使うか発注側が提供し、今回の対象に含めると確認した現行の承認規程
- 今回、どこまで進めるか担当者が該当条項と原文を見つけ、この問い合わせに回答します
04対象範囲と境界
今は対応しないことも、先に伝えます
今回は承認規程の検索だけを行うと合意したなら、営業資料はまだ接続しないことも、目につく場所に示す必要があります。「企業のナレッジベース」という名前から、他部署が自分たちの資料も同じ入口で調べられると思うのは自然です。展開する段階になって営業はまだ使えないと伝えると、予定していた試用や準備済みの紹介資料を見直すことになりかねません。今は対応しない内容も今回の範囲と一緒に示し、特に当然含まれると思われやすい項目を明確にします。社内で紹介するときから、今回は誰が先に使い、他の役割では何の条件を待つのかを説明できるようにします。
自社作成の説明 · 「企業のナレッジベース」の二つの捉え方
今回、確認した範囲総務担当者が確認済みの承認規程を調べる
今回は含めない範囲営業規程の整理・接続・検索の公開
営業部門も使う必要があるなら、日程を組む前に、今回の範囲へ加えるかをプロジェクト責任者が判断できます。決定するまでは、その要望を「ナレッジベース」という言葉の中に埋もれさせないようにします。
05納品物
最終的に、どのようなシステムを納品するのでしょうか？
納品するシステムでは、実際の担当者が、一件の仕事をどこから始め、次に何を見て、どう先へ進めるかが分かる必要があります。問い合わせ対応なら、顧客の連絡が入った後に、関連する注文と過去の対応記録を確認し、情報が足りるか、次に何を聞くかを判断します。システムが対応案を出す場合も、その根拠と、担当者が確認すべき部分を区別できるようにします。こうした手順をつなげることで、納品する機能が日常業務をどう支えるかが分かります。担当者が自席に戻ったとき、並んだメニューを目の前の仕事にどう使うかが見えることが大切です。
自社作成の画面説明 · 問い合わせ対応問い合わせが届いたら、担当者はここで対応を始めます。
自社作成の構成説明問い合わせ・資料・対応案・実際の処理は、どの層に置かれるのでしょうか？
一件の問い合わせに沿って構成を見ます。情報を集め、根拠のある対応案を作り、担当者が確認したうえで実際の処理を行います。
図を拡大表示 ↗
- 情報が不足しているときは、必要な追加情報を表示し、整った対応案の中に不足を埋もれさせません。
- 対応案と実行済みの処理を分けます。担当者が確認してから結果を記録し、下書きを完了の根拠にしません。
- 次の担当者は同じ注文から経緯をたどれます。その仕事に沿って、役割ごとの権限と対応する版も確認します。
この欄の構成と関係を説明する図です。実際の範囲、接続方法、実行できる操作は、個別のプロジェクトで確認します。
実際に操作する担当者情報を一か所に集め、判断は担当者が行います。01 · 顧客からの連絡を受ける注文 01 · 商品不足の連絡
「届いたカップが一つ足りません。」
03 · 対応案の根拠と不足情報を示すまず注文と同梱明細を確認する
現在の情報だけでは、商品の不足状況を判断できません。追加で必要な資料と確認する根拠を一緒に表示し、担当者が確認を続けられるようにします。
担当者が対応案を確認・修正・差し戻しします。実際の回答と処理記録は同じ問い合わせに残し、次の担当者も経緯を確認できます。
06納品物一覧
システム以外に、何が発注側へ引き渡されるのでしょうか？
圧縮ファイルをいくつか受け取っても、引き継ぐ担当者には、中身が何なのか、どれが稼働中のシステムに対応するのかを知る必要があります。設定を一つ変えようとしたとき、三つのファイルがどれも最新版に見えるなら、結局は元の開発担当者に聞き直すことになります。システム以外に引き渡すと合意した成果物についても、用途、保存場所、対応するバージョンを一つずつ説明し、その場で受領担当者に該当するものを見つけてもらいます。一覧にあるものの、まだ引き渡していない項目は、その状態を明記します。ファイルだけが増えて、何が足りないのか分かりにくくなるのを防ぐためです。
自社作成の段階納品パッケージ・注文照会の説明用場面一回の段階提出では、対応関係のある一組の資料を引き渡します。
新しいバージョンを受け取るときは、今回何を試すのか、前回の問題をどこで修正したのか、何がまだ確認できていないのかも、合わせて見つけられる必要があります。以下では、同じ注文照会の提出に沿って、これらの資料をまとめて見ます。
この一組の資料が対応する対象注文照会・試用版 B確認予定：カスタマーサポート担当者が職務用アカウントで注文 01 を開き、以前の空白表示が修正されたかを確認します。
修正版提出済み・業務担当者の再確認待ち - 01
今回のシステムと試用入口
入口、環境、稼働バージョンを B にそろえ、受領担当者がどの職務用アカウントで入るか分かるようにします。まず注文照会を試します。まだ接続されていない対応案は、今回の一連の対応確認には含めません。
用途：今回確認できる範囲を特定します。 - 02
バージョンに添える提出説明
注文表示に関わる処理を調整したことと、サポート担当者に元の操作へ戻って再確認してもらう予定を記載します。今回まだ確認できない結果も、説明に残します。
用途：この版を提出する理由と、今回確認する手順を伝えます。 - 03
元の問題記録
問題 01：サポート用アカウントで注文 01 を開くと、空白が表示されます。元の現象と B の修正を同じ記録に残し、状態は再確認待ちのままにします。
この問題の記録方法を詳しく見る ↗ - 04
今回の実際の確認で残す所見
サポート担当者が元の操作をやり直した後、確認したバージョン、担当者、日時、実際の現象を記録します。現時点では今回の業務側の再確認結果はまだないため、「提出済み」を「確認合格」とは記載できません。
用途：実際に確認した結果を今回の提出にひもづけます。 - 05
この段階で必要な操作・引き継ぎ資料
試用担当者が注文照会の操作説明、アカウントの権限条件、問題の連絡先となる担当を見つけられるようにします。ソースコード、配置、保守の資料は、それぞれ合意した引き渡し時点に沿って記載します。試用版を提出しただけで、すべての引き渡しが完了したとは扱いません。
用途：バージョンを受け取った後、試用の始め方と、途中で止まった場合の報告方法を伝えます。
これらの資料は、次の手順にどうつながるのでしょうか？同じ職務用アカウントと同じ注文を使って B で再確認し、実際の所見を問題 01 に戻します。まだ空白なら、不合格の結果を残します。開けた場合も、確認できたのはその手順だけです。対応案やその他の未試用の内容は、それぞれの未確認事項に残します。
同じ成果が段階払いの根拠にどう対応するかを見る ↗ 以上は、資料の対応関係を示す自社作成の説明であり、実際のプロジェクトの入口や確認結果を提供するものではありません。毎回どの資料を提出し、誰が各項目を受け取り、いつ引き渡すかは、今回の範囲と節目に沿って確認します。
プロジェクトの納品物一覧の作り方使えるシステムと、それを引き継ぐために必要なものを、合わせて確認します。
以下は、一つずつ確認する成果物の種類です。今回どれを含め、どの状態まで引き渡すかは、範囲と見積もりを確認する際に明記します。すべてが含まれるとは限りません。
ソースコードまたは実行可能な成果物
利用入口の提供、実行可能な成果物の納品、ソースコードの引き渡しは、それぞれ異なる取り決めです。見積もり時に分けて明記します。
利用と引き渡しの権利を確認する ↗利用・保守・研修資料
業務担当者が操作を続けられ、保守担当者が配置や問題調査に必要な説明を見つけられるようにします。
資料と業務の対応を見る ↗引き継ぎ場面の説明送ったファイルを、引き継ぐ担当者が見つけられる状態にします。
引き継ぐ担当者に一つ開いてもらいます。稼働中のバージョンと、自分が次に進むために必要な説明を見つけられるかを確認します。
コードまたは実行可能な成果物
合意したリポジトリや成果物の保存場所を開き、稼働中のシステムとのバージョンの対応を確認します。
設定と依存関係の資料
設定説明と依存関係の一覧を見つけ、あるパラメーターをどこで設定し、誰が管理するのかを確認します。
テストと問題の記録
まだ合格していない項目を記録から見つけ、その影響と現在の対応状況を確認します。
利用と保守の説明
担当する役割に沿って、よく使う操作の手順や、問題調査の入口を見つけます。
受領担当者が各項目の場所とアクセス条件を確認します。開けないものや説明が足りないものは、その場で記録して補います。コード、モデル、第三者の資産の利用・引き渡しの権利は、プロジェクトの合意に従います。
07納品形式と仕様
引き渡されるのは、どのバージョンでしょうか？
システムの使い勝手を話し合う前に、全員が同じ版を開いているかを確認します。たとえば、先週の試用入口がブックマークに残ったまま、今週は開発側が新しい版を提出していることがあります。説明がなければ、業務担当者は古いアドレスを再び開き、開発側が修正した内容とは対応しない問題を見るかもしれません。双方とも実際に見たことを話しているのに、話がかみ合わなくなります。システムを引き渡すたびに、どの提出版なのか、今回はどの担当にどの手順を確認してもらうのか、前回の問題をどこで修正したのかも説明します。その後の所見を同じ版にひもづけ、まず何を見ているかをそろえてから、出来具合を話し合います。
前回のデモAその時点の確認記録を残します。
今日提出する成果の代わりにはなりません。
今回の確認B今日提出する入口と成果物をともに B と表示し、全員が同じ版を見て確認を続けます。
現在確認する対象 前回の閲覧制限付き資料の検索に戻る
権限の処理は調整済みですが、元のアカウントと質問で B を再確認する必要があります。「修正版提出済み」と「確認合格」は分けて説明します。
社内規程の検索／今回の提出 B
元の場面での再確認待ち- 対応する成果物
- 今回の試用入口と実行可能な成果物をともに B と表示し、受け取り先を提出説明に記載します。
- 今回の確認担当
- 業務側の試用担当者が、元の一般従業員アカウントで、閲覧制限付き資料について同じ質問をし直します。
- 前回の問題を修正した箇所
- 検索結果の権限処理を調整しました。ここに記録するのは修正版の提出であり、確認合格はまだ記録していません。
- 今回まだ確認できていないこと
- 閲覧制限のある出典がまだ表示されるかは、元のアカウントと資料の条件での再確認結果を待ちます。
正式な提出説明には、実際の版の識別情報、アクセス先、確認担当者を記載します。この自社作成の抜粋は、アクセスできるプロジェクトの入口を提供するものではありません。
A、B は自社作成の説明用の番号です。まだ接続していないデータと未確認の場面も合わせて説明します。正式な検収は、双方が指定した版とその記録に基づきます。
08納品形式と仕様
成果物はどこに置き、どう発注側へ引き渡すのでしょうか？
ファイルの保存場所と、引き継ぐ担当者が開けるかどうかは、引き渡し時に合わせて確認する必要があります。開発担当者のパソコンでは開けるリンクでも、保守担当者が自分のアカウントで開くと権限エラーになるなら、その資料はまだ後の作業を支えられません。元の連絡担当者がグループにいなくなってから権限を付けられる人を探すことになると、小さな修正でも止まりかねません。成果物の引き渡しでは、受領担当者とシステム環境、ファイルの場所、必要な権限を照合し、自分のアカウントで実際に開いてもらいます。必要な内容がそこにあり、合意した範囲で操作を続けられるかを確認します。
受け取り先の説明
引き継ぐ担当者自身のアカウントで、成果物を受け取ります。
システムの引き継ぎ担当者合意した実行環境に入る
発注側が指定したアカウントで入り、合意した管理権限を確認します。
技術面の引き継ぎ担当者リポジトリまたは成果物の保存場所を開く
合意した内容を取得し、その後のアクセス権限を誰が管理するかを把握します。
資料の保管担当者説明資料と引き継ぎ記録を開く
自分のアカウントと合意したソフトウェアで開き、保管する担当を明確にします。
後で引き継ぐ人が変わったとき、元の開発担当者にまたアクセスを開いてもらう必要があるでしょうか。引き渡し時に、発注側の権限管理担当者が合意に沿って別の引き継ぎ担当者に一度権限を付与し、その手順を実際に確認できます。
保存場所、形式、言語、アカウント、権限の範囲は、個別のプロジェクトで確認します。ここでは受け取りの関係を示しており、すべてのプロジェクトで全面的な管理権限を提供するという意味ではありません。
09納品時期とマイルストーン
業務担当者が初めて操作できるのはいつでしょうか？
稼働開始の直前まで業務担当者にシステムを操作してもらわないと、仕事が止まる手順に気づくのが遅くなる可能性があります。画面はそろっていても、実際の処理では必要な情報が欠けていたり、システムの結果だけでは判断できなかったりします。その時点では開発はすでに先へ進み、予定していた利用開始日も近づいています。初めて操作できる版は、こうした点を調整する時間が残っているうちに渡す必要があります。まず今回の最も重要な仕事に沿って、実際に操作できる部分を提出します。利用する本人に作業してもらい、まだ判断できない手順を指摘してもらいます。その内容から、次の開発で資料の接続を先に進めるのか、ルールを補うのか、元の進め方を変えるのかを把握します。
広い範囲の接続と正式な稼働開始の前にまず重要な手順を実際に操作できる版を用意します。誰が、どの仕事を試し、何日に渡すかは、範囲と依存条件を踏まえて開始計画で決めます。
10納品時期とマイルストーン
これからの各節目で、何を確認できるのでしょうか？
「来週から試験運用に入る」だけでは、説明が足りません。サポートの仕事なら、その日にできるのは問い合わせを開くことだけなのか、それとも注文を見て、資料を基に処理を進められるのか。「開発は80％完了」では、この問いに答えにくくなります。同じ割合でも、画面がそろった状態なのか、最も重要な資料がまだ接続されていない状態なのかは分かりません。その後の各日程では、どの版を提出し、どの担当がどの手順を実際に行えるのかを説明し、未接続の部分も並べて示します。同じ仕事に沿って節目を追うことで、プロジェクト責任者は試用を手配する根拠を持てます。業務担当者も、今回はどこまで確認できるかを把握できます。
自社作成の日程説明・同じ問い合わせに沿って成果を確認。具体的な日付はプロジェクト計画で決定
- 接続
合意した環境とアカウントが接続された時点合意した注文情報と顧客情報を担当者が見る
利用者が自分のアカウントで問い合わせを開き、処理に必要な情報が合意どおりに届いているかを確認します。
- 試用
試験運用を開始する時点担当者が実際に処理し、結果を残す
確認済みの試用範囲で、一件の問い合わせを最後まで処理できるか、どこにまだ人の補助が必要かを確認します。
- 利用開放
正式に利用を開放する判断の前今回の版を誰に開放できるかを確認する
未解決の問題と影響する担当を確認し、今回開放できる業務範囲を決めます。
- 引き渡し
検収と成果物の受領時引き継ぎ担当者が今回の版と資料を受け取る
現在の版、対応する確認記録、合意した引き渡し項目を照合し、まだ受け取っていない部分を特定します。
自社作成の計画項目・日程の記載例最初の業務試用は、計画にここまで記載します。
開始計画では、今回の範囲、既存システム、各者が条件を用意できる時期を踏まえて、各提出日を確認します。まだ決められない節目は、何を待っているかを説明し、次に照合する時期を決めます。
今回提出するものサポート担当者が関連注文を自分で照会できる版注文を開けるか、情報が判断に十分かを試します。対応案がまだ接続されていなければ、処理全体の検収は設定しません。
今回の日程が依存する条件テスト環境、職務上の権限、注文照会の条件資料と権限の準備は、画面開発と並行して進められます。実際の注文照会の結合確認は、これらの条件がそろってから行います。
日付を確認する時期開始計画で確認し、条件が変わった際に見直す提供側がいつ準備できる見込みか、何日に確認するか、誰が追跡するかも計画に記載します。未確認の日付は未定のままにします。
この項目は計画に必要な情報を示すもので、実際のプロジェクトの日程が決まっているという意味ではありません。具体的な計画には、各提出日、担当者、前提条件を記載し、双方の確認後に試用を手配します。
実際の日程表では、各日付と成果、前提条件を合わせて記載します。環境、アカウント、資料がまだ整っていなければ、どの確認点に影響するかを明記し、プロジェクト責任者が調整できるようにします。
