1. 事前準備
2. 対面ヒアリング（１回目）
   1. ①座席位置とセッティング (対面の場合、20分前に現地入り)
      1. インタビュアーが多く、インタビュイー(お客様)が少ない場合は、取り囲まないように座席の配置に気を配る
         1. 取り調べ調にならない工夫
         2. ただし、レイアウトが決まっているので限界がある
      2. プロジェクタ画面を見る場合、インタビュアーはプロジェクタ画面側の席に座る
         1. お客様の目線を画面に向かせる
         2. 画面が目に入ることで、フローを作り上げるというゴールを意識してもらう
         3. 話が脱線した時に、戻しやすい
      3. モデラーは、2画面あると良い （ポータブルディスプレイ）
         1. 1画面はモニタ共有し、見せられないメモ等はもう1つの画面で入力する
         2. 画面拡張し、サブモニタを共有する
            1. チャットやメールの通知がされない
         3. デスクトップは、アイコンを整理しておく
         4. メインモニタを共有する場合は、通知オフ
   2. ②最初の挨拶と紹介
      1. 挨拶と名刺交換
      2. ヒアリング担当者紹介
      3. モデリング担当者紹介
   3. ③業務プロセス診断の説明
      1. 資料をもとに、 業務プロセス診断の説明
         1. 業務プロセス診断の概要と目的
         2. 成果物
         3. 進め方
            1. 今日の目的とゴールの説明
         4. ヒアリングスケジュール
         5. ヒアリングイメージ
      2. 録音了承の確認
         1. 録音開始
            1. スピーカー&マイクが必要
            2. 音声録音は、Teamsよりスマホ録音の方が聞き取れる
            3. リモート参加者なしだと、Teams録画を忘れることがある
   4. ④対象となる業務の全体像を確認し把握する
      1. 組織の業務内容や役割
         1. 事前に確認できていれば再確認し、確認できていなければここで確認する
            1. 複数部署が対象となる場合は、可能なら一番最初のお客様(マネージャー)に各組織の関係性などが聞けると全体が把握できる
            2. JEA様組織図
      2. 対象組織のミッション
         1. 業務のあるべき姿の仮説設定の材料
            1. あるべき姿をお客様に聞きたいが、お客様に質問しても分からないことが多いと思うので、実際は質問できない
            2. 持ち帰って、リコーサイトで「あるべき姿」の仮説を作る
            3. 仮説となる「あるべき姿」は、後日、お客様に確認する
   5. ⑤業務フローヒアリング
      1. 作業可視化の対象となるスコープを確認
         1. 業務の時系列を分類するためのフェーズを確認
            1. フローのヨコ軸
            2. 最初に決定すると、大きな変更は発生しない
         2. 対象組織(役割)と関連組織を表すための プールとスイムレーンを確認
            1. フローのタテ軸
            2. 実際は、「最初のトリガーはなんですか？」を聞いてから設定するケースが多い
            3. 最初の段階では、大枠でよく、 途中で関連組織を追加したり、プールを分割したりする
         3. 「プール」とは、プロセス定義における関係者の境界線を表現したフローエレメントです。 「スイムレーン」は、プールの中でさらに役割を区分したい場合に使用します。
      2. インタビュアーは、 最初のトリガーから作業をヒアリング
         1. 最初は少し戸惑う
            1. 粒度
            2. 「受領」や「受付け」の表現方法
         2. すぐに慣れて、どんどん話す
         3. 流れを止めない
         4. 細かく聞かず、全体を聞き終えるようにする
            1. 経験上、2時間以内には完了する
         5. イレギュラーは後まわし
      3. モデラーは、とにかく書く
         1. ハッピーパスで書く
         2. 汚くても良いから何でも書く
            1. よく分からない時は、コメントに記載しておく
            2. iGrafxは、アクティビティの中に記載
            3. bpmn.ioの場合は、コメントで記載
            4. 記録されたくないことかもしれないと思った時は、別モニターのメモ帳に記録
         3. 問題点は、爆弾マークで記録（iGrafxの場合）
         4. 会社に戻ってから整理する
      4. 【参考】業務モデリングの進め方（シルバー学習コンテンツ）
   6. ⑥気づいた点
      1. ヒアリング開始時は、どっちがいい？
         1. JEAさんの事例
            1. RJコンサル担当者が作成したフロー概要
            2. ヒアリングは、このフローを元にすすめるか？
            3. 情報がとぶ
            4. 元のフローにひっぱられる
            5. 何もないプレーンな状態ではじめるか？
            6. 何もないプレーンな状態ではじめるのがよさそう！
      2. ヒアリングは、上司と部下それぞれに実施するのがよい
         1. マネージャーは業務全体、経営部分を知っている
         2. 部下は、作業自体を詳しく知っている
            1. 問題点や困りごとも
         3. ヒアリングのやりかたは、 上司と部下、一緒と別々どちらがよいか？
            1. 2人一緒のメリット
            2. 2人一緒だとヒアリング内容が網羅できる
            3. 2人一緒だと意見が引き出され、相乗効果が期待できる
            4. 時間が短縮できる
            5. 2人一緒のデメリット
            6. 2人一緒だと言いたいことが言えないケースがある
            7. 部下の育成やスキル
            8. 上司への不満
            9. 2人一緒と別々のタイミングのヒアリングがあると良いかも
            10. 1回目は、二人同時 2回目は、個別に
            11. 1回目のヒアリングで緊張を解いてもらい、関係性を築く
            12. 2回目のヒアリングを個別に分けることで、本音を引き出す
            13. 1回目は、個別に 2回目は、二人同時に
            14. 1回目のヒアリングで異なる内容があった場合に、2回目で確認できる
      3. システムが深く関与しそうな場合は、システム部門のヒアリングを追加してもらえないか相談してみてもよいかも
3. ヒアリング整理
   1. 複数部署や部門で聞いた場合、 フローの全体構成を決める
      1. 共通業務を１つにまとめるか
         1. １つにまとめるメリットは、メンテナンスが容易
         2. １つにまとめるデメリットは、フローが分断される
         3. 今回は、１つにまとめる記載方法を選択
      2. 別々に作成するか
   2. BPMN、業務記述書の整理
      1. 個人名は削除
      2. メモを残す場合は、発言者が特定できないようにする
      3. 共通フローにする場合は、部署や役割で作業が異なる時の記載ルールを決める
         1. 複数のアクティビティが異なる場合：フローで分岐
            1. フロー分岐のサンプル
         2. １つのアクティビティで異なる場合：業務記述書でわかるように記載
            1. 業務記述書内の記述サンプル
      4. モデラーが複数人いる場合は、予め、記述ルールを決めておく
         1. (例)　・箇条書きにする 　 　・文末に句点(。)をつける　など
      5. 同じ問題が複数のアクティビティに発生する場合、全アクティビティに設定するべきか？
         1. 設定すると、問題解決した数が具体的にわかる
         2. 同じ内容が何度も出てきて見づらい（押しつけがましい）
         3. 今回は、問題を１つにまとめて作成しました
   3. 2回目のヒアリングで見せてOKなフローにまとめる
      1. ヒアリング時に書いたフローは履歴として残しておく
         1. iGrafxはバージョン管理が可能なため、記録を残す場合は、コピーして新しくできたファイルをバックアップとして名称変更し残しておくことをお勧め
            1. 常に最も古いファイルを編集し続けることで、バージョン管理による編集履歴を確認することができる（iGrafxのバージョン比較機能）
            2. イメージ
      2. NGのコメント等を削除したフローを用意し、2回目のヒアリングに臨む
4. 対面ヒアリング（2回目）
   1. 1回目のヒアリングフローを見せながら間違いがないかをお客様に確認してもらう
   2. 作業内容を深掘りし、細かく聞き出す
      1. 各アクティビティの詳細に関する記述
         1. iGrafxは、アクティビティの中に記載
         2. bpmn.ioの場合は、コメントで記載
            1. フェーズは、プールに対しコメント入力
      2. 関連する帳票やテンプレートの確認
      3. 関連するシステムの確認
   3. 作業で困っていることや問題点がないかを聞き出す
      1. iGrafxは、爆弾マークをおきヒアリング内容を入力する
      2. bpmn.ioは、コメントやアクティビティのカラーを設定する？
   4. 1回目のヒアリングで聞き終えられるなら2回目のヒアリングは省略可
   5. 複数部署にまたがってヒアリングする場合は、他の組織から見て、どう見えるかも聞く
   6. 1回目のヒアリングで別々にインタビューした　場合、NGコメントではない場合も配慮が必要
      1. コメントアクティビティを小さくしておく
      2. コメントのフォントサイズを小さくしておくなど
      3. 一緒にヒアリングした場合は、見せてもOK
5. iGrafxの紹介
   1. BPMNを作成するには、 「iGrafx FrowCharter」というデスクトップアプリを使用
   2. 作成したファイルは「igx」という拡張子のファイルで、ローカルPCに保存される
      1. １つのigxファイルには、図表を複数保存でき、この図表にBPMNを書く
      2. igxファイルの構成
   3. 作成したigxファイルをPlatformに追加するとCollaboratorライセンス保有者と共有できる
   4. Platform上で承認されるとViewerライセンス保有者もWeb上で閲覧できるようになる
   5. iGrafxのリポジトリ
   6. iGrafxのフローからExcel文書を書出し、編集後にiGrafxへ戻すことが可能
      1. 【サンプル】業務記述書
      2. 【サンプル】問題管理表
      3. 【サンプル】問題課題関連表
6. 分析の考え方整理 （シルバー学習コンテンツ）
   1. 問題とは？
   2. 問題事象とは？　
   3. 問題点とは？
   4. 「要因」と「原因」
      1. 「要因」は、物事を発生させることになった主要な原因のこと 「原因」は、ある変化や状態、物事を引き起こす事柄のこと 要因には複数の要素（原因）が含まれるが、原因には1つの要素（原因）しか含まれていないのがニュアンス的な違い 原因がいくつもある場合は、要因を使う。 一方で、原因が1つの場合、また物事がそうなった直接的な原因をさす場合には、原因を使う。
   5. 仮説の問題事象 （潜在的な問題事象）
      1. 想定要因を列挙していると、新たな問題事象が現れることがある これを「仮説の問題事象」として設定する 本来は、「仮説の問題事象」は、iGrafxに戻って爆弾マークを追加して管理(分析)すべきだと思うが、納期的な関係で報告用Excel上で管理（最初の問題事象の中で分析）してしまった。
      2. 「仮説の問題事象」は、潜在的な問題事象になる可能性がある
   6. 業務分析の進め方
      1. ①業務としてのあるべき姿
         1. 組織のミッションやリスクや影響の範囲などから、「業務としてのあるべき姿」を設定する
      2. ②問題事象
         1. ヒアリング内容や「業務のあるべき姿」から「問題事象」を設定する
      3. ③原因（要因）
         1. 要因となる「原因」を書き出していく
         2. なぜなぜ？を繰り返し「真の原因」を追究していく
      4. ④仮説の要因
         1. 「要因」となる「原因」を考えていると「仮説の要因」がでてくることがある
      5. ⑤仮説の問題事象
         1. 「仮説の要因」から「仮説の問題事象」が設定されることがある
         2. この段階で、本来ならiGrafxへ戻って爆弾マークを設定すべき
            1. 問題事象を分割して管理・分析する方がやりやすいため
      6. ⑥問題点（真の原因）
         1. 「原因」を追究すると「問題点（真の原因）」が見つかる
            1. 報告用Excel上では、「要因」のカテゴリー（分類）がそれにあたる
      7. 「問題事象」と「問題点」のカテゴリー（分類）を設定する
         1. カテゴリーを設定した方が分析しやすい
         2. ある程度、分析が確定してから分類化する方が効率的
      8. ⑦課題
         1. でてきた問題点を分類し、同じカテゴリーの問題点を抽象化して「課題」を設定する
         2. この段階の「課題」は、業務プロセス診断の成果物としての「課題」 報告書では、これらの中から組織として重点化すべき「課題」を導きだしていく
         3. iGrafxで「課題設定」すると管理しやすい
            1. １つの「課題」に対して対象の「問題事象」をセットすることができる
            2. 問題課題関連表」で書き出される「
      9. ⑧作業のあるべき姿
         1. 「業務のあるべき姿」を参考に、「問題事象」に対する「作業のあるべき姿」を設定する
         2. 分析後の方が、要因や課題を参考にすることで設定しやすい
      10. 業務プロセス診断の進め方イメージ
7. プロセス診断
   1. iGrafxから書き出した「問題管理表」を元に、報告書の形式にあわせたフォーマットに変更
      1. 「報告書用問題管理表」作成テンプレートファイルのリンク
      2. 作成手順 　①iGrafxから「問題管理表」を書き出す 　②Excelテンプレートファイルのシートに貼付け 　③②のテンプレートファイル上で分析 　④②のテンプレートファイルのiGrafx取込み用シートをiGrafxへインポート
   2. あるべき姿の設定
      1. 「あるべき姿」の必要性
         1. 「あるべき姿」がなければ、何を基準に「問題」を設定したのか説明できない
      2. お客様がわかっていて明言してくれるならそれが正解
      3. ほとんどはお客様から聞き出せない その場合は「業務としてのあるべき姿」の仮説を立てる
         1. 誰もがぼんやりと「あるべき姿」をイメージしている
            1. 「ここが問題」と感じる時点で、何かしらの「あるべき姿」はすでにある （明文化していないだけ）
         2. 「あるべき姿」の仮説設定は、様々な情報を元に設定すると抜け漏れがない
            1. 対象組織のミッション
            2. 自分が持っている「あるべき姿」のぼんやりイメージ
            3. リスク・影響観点
            4. ■iGrafxテンプレート「影響・リスクの分類」 　品質・制度低下 　生産性・効率性低下・ムダの発生 　ロス発生・コスト増加・収益の悪化 　期間の遅れ・納期の遅れ 　事故・トラブルの誘発 　機会・利益の逸失 　セキュリティ・コンプライアンス上リスク 　モラル・コミュニケーション悪化 　顧客満足度(CS)・社外からの信頼の低下 　事業戦略/事業計画の基礎情報の品質低下
            5. 問題分析を進めていくと、後からわかることもある
            6. 問題や要因を分析することで情報が整理され、「あるべき姿」見えてくる
            7. あるべき姿とは、問題や要因の反対になることが多いため
         3. 設定した「業務としてのあるべき姿」の仮説は、 お客様に対し、「私たちが考えるあるべき姿はこのように定義しており、それに基づいて問題分析を行う」と説明するのが良さそう
            1. 定義した「業務としてのあるべき姿」は、2回目のヒアリングの際、お客様に確認してもらうのが良いかもしれない
      4. 「業務としてのあるべき姿」は最初に設定するが、 「問題ごとのあるべき姿」はいつ設定すべきか？
         1. 「問題ごとのあるべき姿」を最初に設定してしまうと苦しむことになる
            1. 漠然とした状態で「あるべき姿」を設定するのは、とても難しい
            2. 問題事象と要因を行ったり来たりしていると、「問題ごとのあるべき姿」も変更になることが多い
            3. 大変さは、問題数や問題の複雑さにも関係するかもしれない
            4. JEA
            5. 問題数：５０個
            6. アクティビティ数：１５０個
            7. ビル：２０個 営業：２０個 駅ク：２０個 共通：５０個 資源：４０個
            8. 美里町
            9. 問題数：２０個
            10. アクティビティ数：６５
         2. 「問題ごとのあるべき姿」は、分析の最後に設定するのがよいかもしれない
         3. 「業務としてのあるべき姿」の構成要素を分解し、マトリックスにする方法もありかもしれない （シルバー学習コンテンツ抜粋）
   3. 問題分析
      1. ヒアリング内容は、「事実・事象(ヒアリング時のコメント)」としてそのまま残す
         1. ヒアリング時のコメントは、問題も要因も含まれるが、それでOK
            1. 後の工程で、「事実・事象の問題」と「問題発生の想定要因」を切り分けるため
         2. 「事実・事象(ヒアリング時のコメント)」は、１つの問題に複数の問題を混在させない
            1. 混在している場合は、最初に分割する （爆弾マークを分ける）
      2. 「事実・事象(ヒアリング時のコメント)」を元に、「事実・事象の問題」を分析する
         1. コメントから想定される問題（それによって起こる問題）をすべて書き出す
            1. 聞いた事実からの問題
            2. 仮説の問題
            3. 潜在的な問題である可能性がある
            4. 「仮説の問題」もiGrafxの爆弾マークで登録しなおした方がよいと思う
            5. 納期的に厳しいのが現実だけど・・・
         2. 「事実・事象の問題」も問題を混在させない方がカテゴライズしやすい気がする
      3. 「事実・事象の問題」をカテゴライズ
         1. 問題をカテゴリー分けする意味は？
            1. カテゴライズすることで、何に関する問題なのかを大別できる
            2. 文章を読まなくてすむため、問題を管理しやすくなる
         2. 問題カテゴリーをセット
            1. カテゴリとなりそうなキーワードを各問題に対してどんどんセットしていく
            2. 複数のカテゴリをセットしてOK
            3. 統合できるものは統合していく
            4. 書き出されたカテゴリから 「問題カテゴリ一覧」を作成する
            5. (例)JEAの場合 ①契約不一致 ②コンプライアンス ③職務権限 ④ビジネス理解 ⑤誤請求 ⑥従業員満足､待遇 ⑦ルール ⑧戦略的対応 ⑨システム ⑩仕組み・体制
            6. (例)美里町の場合 ①作業負荷 ②ミスの誘発 ③納期遅延 ④ペーパーレス ⑤検索性 ⑥ストレス ⑦権限移譲 ⑧品質のバラつき
            7. 客先に限らず「問題カテゴリー一覧」を統一することができれば管理しやすい
         3. チェック
            1. 問題カテゴリの内容が「事実・事象の問題」を網羅しているかチェック
            2. 逆に、他の問題カテゴリで設定できるものがないかもチェック
   4. 要因分析
      1. 「事実・事象の問題」を元に要因を分析する
         1. 要因は整理して書く
            1. 以下2種類に切り分ける ①ヒアリング情報からわかる要因 ②推測した想定要因
            2. ヒアリングコメントの要因と推測した要因を分けることでクレームを回避する
            3. 要因を告げることで、お客様が気分を害する可能性があるため、あくまでこちらが想定した要因の可能性だと識別できるようにする
         2. 本来は、なぜなぜ？を繰り返し「真の原因」を追究していく
         3. 今回は、フラットに要因となる「原因」を列挙していった
            1. その中には、なぜなぜ？の内容も含まれている
         4. 「問題点（真の原因）」
            1. 今回のフォーマットには「問題点（真の原因）」は記載していない
            2. 「問題点（真の原因）」＝「要因カテゴリー」となっている気がする
         5. その他
            1. 要因は最適化(問題解決)を行う際のチェック項目になる
            2. 最適化する際には、全要因がクリアされているべき
            3. 最適化後の効果は、問題がどれだけクリアされているかで確認
            4. 要因を潰し込んでも想定外の原因で問題がクリアされない可能性もあるため
            5. 要因の洗い出しが漏れている可能性がある
      2. 「問題発生の想定要因」をカテゴライズ
         1. 要因をカテゴリー分けする意味は？
            1. 要因カテゴリがあると抽象化しやすい
            2. 課題設定は、要因カテゴリを網羅した内容になっているべき
         2. 要因カテゴリーをセット （統一できるならその方がやりやすい）
            1. カテゴリとなりそうなキーワードを各要因に対してセットしていく
            2. 複数のカテゴリをセットしてOK
            3. 統合できるものは統合していく
            4. 列挙したカテゴリから「要因カテゴリー一覧」を作成する
            5. (例)JEAの場合 業務知識・スキル 育成計画 エクセル システム 入力（手入力） 業務の標準化・ルール化 過去の経緯・継承 案件の数（多い） 法令順守 ルール 情報共有・伝達・確認 臨時作業の請求 情報の管理・更新 データの一貫性・一元化 納期優先 収益性 ビジネス理解 役割・仕事の分担 書類の品質 紙処理と電子処理 時期や量の偏り・バラツキ スケジュール調整 検討不足 情報不足 書類の管理 レビューの品質 価格・仕様の変更 業務の複雑さ 変動費の精算 請求書のまとめ送付 人の変更 職務権限 現場対応（口約束） 複雑な業務
            6. (例)美里町の場合 業務の標準化・ルール化 情報不足・情報共有 情報の欠落 過去の経緯・継承 手入力 編集作業 作業の難易度 仕組み 納期遅延 職務権限 紙 規定・法律 操作性の問題 外部要因
            7. 客先に限らず「要因カテゴリー一覧」を統一することができれば管理しやすい
         3. チェック
            1. 要因カテゴリの内容が「問題発生の想定要因」を網羅しているかチェック
            2. 逆に、他の問題カテゴリで設定できるものがないかもチェック
   5. 課題設定
      1. 「要因カテゴリー」を元に課題を設定する
         1. 「要因カテゴリー」を元に、同じカテゴリーの問題点を抽象化して「課題」を設定する
         2. 「課題設定」は、iGrafxで行うと「問題課題関連表」に落とし込める
            1. 「要因カテゴリー」を参考にしながら実施すると漏れがない
            2. そのためにも「仮説の問題事象」は、爆弾マークで管理した方がよい
            3. JEA様は、iGrafxで課題設定していない 美里町様は、iGrafxで課題設定している
         3. チェック
            1. 設定した課題は、要因カテゴリを網羅しているかをチェック
            2. 逆に、課題から要因カテゴリに設定できるものがないかもチェック
8. 成果物の作成
   1. プロセスマップ
      1. プロセスマップのスコープを明確にして作成
      2. 業務可視化を実施した場合
         1. 業務構造図(Lv3レベル)を流用して作成することも可能
   2. BPMN
      1. BPMN　サンプル
      2. 全体がわかるようにLv1のフローも作成
   3. 業務記述書
      1. 業務記述書　サンプル
   4. 問題管理表
      1. 問題分析で作成したシートをiGrafxにインポートする
      2. iGrafxの問題管理表は使用しないが、問題アクティビティには取り込む
      3. プロセス診断で用いたExcelシートをファイルに書き出したものを「問題管理表」の成果物とする
      4. 問題管理表　サンプル
   5. 問題・課題関連表
      1. iGrafx上で、課題設定する
      2. iGrafxから「問題・課題関連表」を書出し、成果物とする
      3. 問題・課題関連表　サンプル
   6. iGrafxのフローから文書の書出し
      1. 【サンプル】_01_業務記述書
      2. 【サンプル】_02_問題管理表
      3. 【サンプル】_03_問題管理表_分析_テンプレート
      4. 【サンプル】_04_問題課題関連表
      5. 【サンプル】_05_問題管理表_最終
9. 報告書作成
10. 最終報告事前確認
11. 最終報告確認会議 （可能なら実施）
12. 最終報告会