Issueリスト　収集した意見をアクション化する

Issueリストというのは、チームの問題点、改善を進めていくための事実を収集した宝の山です。 収集しただけでは、解決へは進みません。 次のステップでは、この収集したことを、解決に進めていくために、アクションを定めていきます。 押さえるポイントは以下です ・記載内容をカテゴリに分ける。 　一例としてはcoropsのフレームワークを使い、4Mで分類するのが良いでしょう。 　詳細は、sprintで抑えるべき変化を参照ください。 　Mission：顧客との関係性の変化、ニーズの変化、チームに対する期待値の変化、事故やヒヤリハットetc 　Mesurement：目標、指標、進捗状況や具体的なアクションへに対する感じること 　Method：フローやナレッジなど、共通化できる点、etc 　Member：稼働状況、高いパフォーマンスなどのコツ、育成の状況、就業上のローカルルールetc 　カテゴリに分けると、意見が集中しているところがどこか？ということがわかります。 　あまり意見が出ていないカテゴリは、一見問題が発生しておらず意見が出ていないと思いがちですが、 　そもそも普段からその視点に向いておらず意見が出ていない可能性もあります。 　このような場合は、インタビューなどを行い、収集に努めて下さい。 ・チーム内で意見交換をする。 　カテゴリ分類した後は、意見が多いカテゴリから始めます。ここで会話することは、事象/原因についてです。 　何が起きているのか。意見交換を通じて、認識をすり合わせましょう。 次に、解決している状態についてすり合わせて下さい。 　この解決している状態とはどういう状態か。 　例えば、安定したものが崩れてしまい、「元に戻す」のであれば、 　皆が満足する状態というのは、共有認識で持てているため、どんな状態なのかの言語化は容易です。 　未知の問題に対しては、解決している状態をすり合わせるには、 　改めて、チームのミッション、今期のゴールはなんだったか、ヒントになる情報を抑えなければいけません。 　この意見のすり合わせは必ずするようにしてください。 最後にアクションについて意見交換をします。 解決している状態がすり合ったら、何をすればよいかを考えます。この段階で、どれだけ詳細化出来るかで、 解決までのイメージをすり合わせることに繋がります。 誰が何をいつまでにやるのか、 具体的なアクションをすり合わせることで、更に解決までのスピードも上がっていきます。 WBS化することが望ましいですが、時間のない中では、アクションは箇条書き程度になることも多々あります。 完全に詳細化しないと前に進めてはいけないわけではありません、進めながら詳細化させるケースもありますので、臨機応変に対応を進めてください。

リスクを評価する方法

業務に関するリスクを未然に防げるようにするため、 また、万が一発生してしまった場合も円滑に対処し、影響を最小限で抑えるためには、 事前に発生する可能性のあるリスクを洗い出すとよいです。 ※対外的なリスクの大きなプロジェクト（世間の注目を集めている、大規模で複数企業が参画しているなど）の場合は、 「リスクマネジメント」をチーム活動の重要な柱として位置づけ、定例的にあらゆる角度からのリスク評価を行うようにしましょう。 洗い出した業務制約に関わるリスクについては、対応する優先順位を検討するため評価を行い、 抜け漏れなく対策できるようにしていきましょう。 リスクの評価手順 ① 発生した際の影響度合いを見極める ② 発生した原因を想定して、発生可能性について見極める ③ リスク評価のマトリクスで優先順位をつける ④ 優先順位が高いリスクから、対策コストを検討する ⑤ チーム内で取り組むべきことについて検討し、適切な対処を行う

緊急連絡体制の強化

緊急連絡体制、エスカレーションフローの確立は、障害・インシデント・情報セキュリティ事案・社員保護の観点から重要です。作成時は、実際に機能するか、テストも忘れずに行いましょう。 そのあとは、定期的に以下4点を見直していくことで緊急連絡体制の強化ができます。 　1、報告対象の更新 　2、連絡フローの更新 　3、関係者とすり合わせ 　4、チーム内の展開 トラブルや事故は、頻繁には発生しませんが、いざというときにすぐに動けるようにしておくことが望ましいです。 そのためには、定期的にシミュレーションを行っておくことを推奨します。 トラブルや事故が万が一発生した場合、対象者は動揺してしまい、正常な判断が出来なくなる可能性があります。連絡を受ける上司も、突然の動揺した相手から、何が起きているのかをすぐに把握することは難しいです。 どんな事象が報告する対象であるか、初動のアクションは何をすればよいか、誰にどんなことを連絡をすればよいか、何分以内に行うのか。連絡を受ける側は、相手から何を確認すればよいか、を押さえておきましょう。 シミュレーションを行うことで、手順の確認だけではなく、実際に対処方法で事象が復旧するかどうかも確認することが出来ます。 一つの事例として、ある拠点でNW障害が発生しました。緊急対応フローに沿って、迂回先へ切替を行ったところ、迂回先のNW機器の電源が入っておらず、NWが全断になるというトラブルが発生しました。このようなことも、事前にシミュレーションをしていれば迂回先のNW機器に電源が入っていないことに気づけています。

トラブル発生時の対応

万が一事故が発生した場合に、連携をスムーズに行い影響範囲を最小限に抑えるために緊急フローを作成します。 作成中に新たなリスクに気づいた場合はチーム内に共有し、対処方法を検討し関係者とすり合わせておきましょう。 関係者とすり合わせすること ・報告しなければいけない事象は何か ・報告ルート ・報告する情報の内容 ・規程外のリスクで気づいた内容　など 作成の手順 １．報告対象の整理 　 関係者と一緒に、どのような内容について報告が必要かをすり合わせを行う 　・ 業務上のトラブル例 　　 ・オペレーションミス(影響度合によって分類が必要) 　 　・システム停止 　・チームの活動に関するトラブル例 　　 ・セキュリティインシデント(IDカード紛失、メール/FAX誤送信) 　　 ・マニュアル、ツール類(データ)の破損 ・貸与品(PC、機器)の紛失、破損 ２．連絡フローの作成 　　連絡フロー（誰から誰へ何を、何分以内に報告するか）、連絡手段、連絡先の確認を行う。 ３．関係者とすり合わせ ４．チーム内の展開 　確定したフローをチーム内へ展開し、万が一発生した場合に何をすればよいかを理解している状態にする ※関係者に変更が発生した場合は、緊急フローの更新を行い、関係者へ変更箇所のすり合わせを行いましょう。