ワークフローサンプル

「障害の発生」の公表は、正確性と迅速さが欠かせない。特に「一次発表」までの時間を、如何に短縮できるかが大きなポイントと言える。事業内容（業種）に応じて『障害情報』の発表フォーマットはそれぞれ異なるが、その作成手順（業務プロセス／ワークフロー）には大きな違いはない。

Web事業者（広義の「Webサービス」）
データセンター事業者
SaaS事業者
通信事業者
交通機関
など

なお、忘れられがちな話だが、それらの障害情報を集積しキッチリと分析する事が最も大切だ。障害発生時の業務プロセスを整備するだけでなく、報告時刻などの対応履歴を定期的に分析するようにしたい。

＜各タスク名＞
1.障害検知報告、2.アサイン、3a.一次発表文作成、3b.アプリ一次報告、3c.インフラ一次報告、4a.発表文定時更新、4b.アプリ復旧定時報告、4c.インフラ復旧定時報告、5.一次発表文確認、6.復旧完了確認

日本では台風シーズン到来だ。そして気象警報が発令されると「電話連絡網」が回ってくる。（休校を知らせるための電話伝言ゲーム）

ただ最近では、「メールの普及」「個人情報への配慮」「リアルタイム性の担保」等の理由から、電話連絡網（緊急連絡網）を廃止して、メーリングリストでの情報配信に切り替える学校も多い。

『緊急メール』の配信で注意したいのは「誤解の無い文章の作成」だ。メールでの情報配信は便利なのだが、要らぬ誤解は混乱を助長する。「情報が正確に伝わっているか？」、かならず起案者以外の職員にレビューしてもらってから送信するルールにしたい。

以下のワークフローでは、(1)配信文章の起案、(2)素早いレビュー校正、(3)素早い承認、を考える。（レビューや承認は、スマートフォンが吉！）

＜各タスク名＞
1.配信文起案、2.配信文校正、3.承認、3b.事後承認

「コンプライアンス体制の基本は『規程書類』だ」
と言う意見を否定するつもりはない。しかし一方で、社員全員に『憲章』や『規程』に興味を持ち続けてもらう事は現実的ではない。

1. コンプライアンス体制を維持する
2. その本質：全社員が「法令や定款」を守る必要がある
3. その方針：社内での「相互監視体制」をとるべきだ
4. その方法：社内の多くに認知された≪目安箱≫を設置しよう。

この思考は正しい。社内に目安箱と言うポストを配置すれば良い。しかし「投稿者の投函時ストレス」「回収者の手間」を考えるに、今どきオンラインで受け付けたい所だ。「紛失すること」も、「もみ消されること」も無いだろう。

※ ≪内部通報システム≫、≪内部告発システム≫と呼ぶ事もできるが、≪目安箱≫と呼ぶのがイイような気がする。

＜各タスク名＞
1.投稿、2.投稿確認、3.調査＆回答文作成、3a. 疑問対応、4.回答掲示

パッケージソフトウェアの制作やウェブサイトの制作は「完成したら終わり」と言うものではない。むしろ『変更要望』と言う更新業務に追われる日々が「始まる」と言った方が良い。時には「不具合」も報告されるだろう。

以下の業務フロー図は、「不具合報告」や「要望」のステータス管理を効率よく行う事を主眼に置いた設計だ。（※ 社員が全員、ワークフローのアカウントを持つケース）

＜各タスク名＞
1.不具合要望登録、2.回答者指名／優先度設定、3.一次回答、3a. 疑問対応、4.最終回答、5.一次回答確認、6.最終回答確認

[不具合＆要望の受付から回答「2.回答者指名／優先度設定」]

「ID・パスワード」の発行業務は『地味』ではあるが『極めて重要』だ。その運用を誤ると「情報漏洩」や「情報システムの乗っ取り」など、事業継続に大きな支障をきたす可能性すらある。少なくとも、発行ログはきっちりと記録しておきたいものだ。

以下のワークフローでは、

A. 人事部門による「入社研修プロセス」から『自動起動』されるケース（新規ID発行）と、
B1. 一時雇用者等のためのIDが『申請』されるケース（新規ID発行）、
B2. そして社員の『パスワード忘れ』『改名時のID変更』のケース（既存ID更新）、

に対応している。Aはプロセス間連携、BはWebフォーム連携を想定している（プロセスモデル接続API）

当然の話ながら、「アカウント発行」や「アカウント再発行」を行う以上、「アカウント削除」についてもその業務フローを整備したい。「紙面の都合」と言う名の「大人の都合」でまたの機会としたい。

＜各タスク名＞
0.承認者指名、1.承認、2.認証コード発行、3.認証コードを聞いて入力、4.仮パスワード変更確認、5.確認

[セキュアなパスワード発行: 「2.認証コード発行」画面]

「プレス原稿の作成フロー？？」
「オレの代わりは居ないし、ナカナカ人には伝えられない仕事なんだよ・・・！」

どれだけ会社規模が大きくなっても、「たった一人が担当している仕事」の１つや２つは存在する。しかし、その様な「一子相伝の秘められたプロセス」であっても、業務フロー定義を諦めるべきではない。少なくとも、『各案件がどの進捗にあるのか』を明らかにするだけでも、大きなメリットがある。

以下のワークフローは『プレスニュース原稿の作成フロー』の概略工程を定義したものだ。情報収集や裏づけなどの細かいタスクは気にせず、大きな流れだけを定義している。

＜各タスク名＞
0.NEWSアイデア提案、1.NEWSネタ熟成、1a. 助言対応、2.NEWS草稿執筆、2a. 助言対応、3.配信代行サービス登録、4.Webサイトアップ、5.効果測定、6.意見感想投稿

[プレスニュース原稿の作成 : 「2.NEWS草稿執筆」画面]

問い合わせ対応はタイヘンな仕事だ。「理解する力」や「専門知識」も重要だが、「説明する力」がもっと重要だ。一朝一夕には身につくものではない。

どんな組織においても『問い合わせ回答のベストプラクティス』を組織内で共有したいものだ。最初は手間がかかるが、徐々に回答効率・回答品質・回答時間のすべてが改善する。
以下は、様々な問い合わせに対して地域言語（例えば日本語）で回答文を作成するだけでなく、FAQとして管理すべきものについては、地域言語と英語の両方でデータベース化するワークフローだ。「データベース化」する先のシステムとしては様々に想定できるが、いずれのシステムにせよワークフロー完了時に自動的に投稿される様に設定したい。
・社内専用FAQ：グループウェア、社内ブログ、Facebook非公開グループ、など
・Web公開FAQ：公式ブログ、ディスカッションサイト(Google Group)、Facebook公開グループ、など
＜各タスク名＞
0.手動、0a.例外エントリ対応、1.回答担当指名、2.回答文作成、2a.重要顧客対応、2b.助言、3.回答後経過の記録、4.FAQ掲載文作成、5.翻訳