
タスクを予定どおりに終わらせるための9つの基本ステップは以下のとおりでした。
- STEP1やるべきことの背景・目的・方向性を見極める
- STEP2やることを見えるようにする
- STEP3見えるようにしても見えない部分が2割はある想定で計画する
- STEP4タスクの割り振りをする
- STEP5決定というスイッチを入れる
- STEP6行動する
- STEP7途中で予定に対して計測する
- STEP8計測時に進んでいなければテコ入れする
- STEP9次に誰でもできるよう記録する
一人でITの面倒をみているとして、突発的なトラブルがあったときに当てはめ、9つのステップを見てみたいと思います。
個人的な突発タスクで最初にやるべきこと
受注システムを担当していて突然トラブルが発生し、受注ができないという事態が発生したとします。
もちろん早く対処しないといけません。その時に進めるべきタスクは何でしょうか。
原因が何で、対処方法は?ということに走ってしまいます。
しかし、本当の目的は早く対処することなのでしょうか。
トラブっているので当たり前でしょう、と思われるかもしれませんが、場合によってはそうでもありません。
例えば、本日の受注受付がほぼ完了しているタイミングだとしたらどうでしょうか。慌てて対処する必要もありません。
IT界隈にいると、業務状況を把握できなくなっていることがあるかもしれません。レイヤを一つ上げるとしたら、業務のオペレーションがどうゆう状況でトラブルに対して、何の要求があるかを考えるほうが、原因究明と対処に走るより近道の場合もあります。
個人的な突発タスクでやるべきことを洗い出す
受注システムでのトラブルの続きを考えます。
受注はすでに締め切っているため業務上の問題はなかったとしても、その後何をやるかを考えていかないといけません。
トラブっているわけですから、将来の姿は復旧された状態となります。現在トラブっていることはわかりますが、実は影響がどこまで及んでいるかがわかっていません。ということは、影響を見極めないといけません。
その一方で、なぜトラブったのかという原因も探る必要があります。
さきほど締め切りのことを受注部門に確認しましたが、このままトラブって使えないとどうなるか、あるいは途中の状況を相談しながら進めないといけません。
これらあらゆる方面にて認識すべきことを整理します。
漏れがないかという点では、直接の事象から原因を辿っていったり、影響を追っていったりして、探っていきます。
トラブルなのでいち早く解決しなければならないですが、やることが沢山出てきてしまいました。
では、どうする?というところは次のステップにて説明します。
個人的な突発タスクで期間を確保する
トラブルが発生しいち早く復旧しないといけない状態で、今後の予定期間をどのように考えればいいでしょうか。
これも同じです。
トラブルの原因がわからないのに、その原因追求を行ってから復旧を行い、完全なる対応までが完了となるのはいつになるかわかりません。と言いたくなる方も多いかと思います。
しかし、この場合ですと翌日9:00までに対応しなければならないことがわかっているので、少なくともそれまでの間の半分の時間で対処ができるように計画することになります。
そこまでに原因究明すらできなかったら、対応できない前提のプランを考えておく必要があります。
ギリギリまで時間があると思っていて対応していると、時間があると思って緊張感が抜けます。また、ギリギリでやっぱり駄目だったとわかっても、何も対処のしようがないということになってしまいます。
個人的な突発タスクを割り振りをする
トラブルが発生していて、原因がまだ判明しておらず、対処が進められていない状況ではありますが、何をどう進めるかを決めないといけません。トラブルの場合、時間がありませんので何をやるべきかを予め決めておくべきです。と言いながら、何がトラブるかわからないので、用意のしようがないという人のほうが多いでしょう。
確かに何がトラブるかわかりませんが、トラブった時の影響箇所に関する調整や回避手段についてはある程度は用意できるのではないかと思います。
大きく分けると、影響先への連絡・調整のタスクと原因究明・復旧のタスクに分かれるでしょう。これらについてはできれば手分けしたいところですが、今は一人だったとします。
どちらも並行して行いたいところですが、調整しつつ原因究明するしかありません。
原因究明に走ってしまうと、自分しか何をしているのかわからない状況となります。連絡をしてから、自分のやるべきことに取り組んだほうがよいでしょう。
一人のタスクと思いきや、連絡することで連絡側のエンドユーザはトラブル事態に対する準備をすることができます。よって彼らにタスクが生まれ、並行していることになります。自分ひとりに責任があったとしても、そのほうが安心感が得られるというものではないでしょうか。
この行為は実は逆になる、つまり連絡せずに自らの行動に走りがちです。
個人的な突発タスクでスタートのスイッチを入れる
仮に一人でいろいろしなければならないことを抱えていたとしたら、何がスイッチとなるでしょう。
一つはゴールイメージを明確に持ち、そこまでの道筋が描かれていることです。計画の精度が高いことは達成感をそこで得ることができます。トラブル対応の場合、ゴールが見えていませんが、諦め思考になっているとできるものもできなくなります。
様々な可能性を考えて、原因を探らいないといけません。道筋は一本線ではなく、多くの分岐を持っているということなり、探索しながら進めるという道筋となります。ではありますが、そのいくつかを探れば必ず答えがあるという可能性思考であれば、進めるきっかけとなります。
ただしこれができるのは、いわゆるスーパーパーソンであり、このような人がいたら手放すことはできません。
もう一つは、他の人のフィードバックをもらうというものです。やはり一人で何でも進めるのは相当強い意志が必要です。他の人と何らかの話をすることで、きっかけとなることは多いです。その意味でも、いち早く連絡すべきです。
個人的な突発タスクでの行動フェーズ
この段階になると実行すると決めたことを実行し結果を出します。この場合は、試行が必要となってきますので、最も答えに近いであろうことを順番に実行していくことになります。
調査なりテストなり順番に実行していくことなりますが、決めた時間もありますから、周囲の状況も確認しつつ対応していくことになります。
個人的な突発タスクでの途中計測
中間地点における判断とは
トラブルへの対応としては、数日にかけて仕上げればよいというわけではなく、時間単位で解決し復旧していかないといけません。そのような中においても、先の予定を立てながら、途中の状況を計測することは必要です。
予定というのは、影響に着目して初めて立てられます。
現在原因調査を行っており復旧のめどが立っていません。しかし、0時までに復旧の目途を立てる目標としています。
中間地点までの見込み計測
翌日9時までには完全に復旧しないとITが使えませんので、何らか別な策が必要となります。
よって0時に復旧ができなければできないで、別な策の準備を開始しなければなりませんので、判断の分岐のある予定となっています。
時刻の予定がありますので、途中でどこまで進んで見込みが立っているかは、都度気にしたほうがよいです。
また、事象にもよりますが、数値的な計測が可能であれば実施しますし、できなくてもできる限り見込みの立つものを実施する必要があります。
中間地点で得られる安心感とは
中間時点での判断は、何らか対処しなければならないリミットの時刻には何らかの対処は完了できているという計画となります。よって現在不明瞭な状況であっても、どこかしらに落ち着くという一旦の安心感はあり、落ち着いて進めることはできるのではないでしょうか。
個人的な突発タスクでのテコ入れ方法
トラブルの原因究明をしていますが、なかなか原因にたどり着きません。取るべき策は、判断タイミングにより異なってきます。
0時には何らか回避策を検討しないといけないのですが、20時だったらどうでしょう。まだ原因がわかる可能性があると考えたとします。
今やっていることのらちが明かないのだったら、もう一度策を考え直すという意味でテコ入れします。
手順は以下のとおりでした。
- やるべきことの背景・目的・方向性を見極める
- やることを見えるようにする
- 見えるようにしても見えない部分が2割はある想定で計画する
- タスクの割り振りをする
- 決定というスイッチを入れる
- 行動する
背景ということで、もう一度考えてみると、アプリのPCでの動作環境のことばかりを考えていましたが、サーバOSの面でも問題があるかもしれない、ということもわかってきました。
そうなってくるとサポートを依頼したほうがよさそうです。サポート依頼について実施するとともに、解決判断を行う時間設定を22時としました。
サポートの受信はITスタッフ以外でもできるので、人に依頼します。
その方向をエンドユーザ部門に連絡します。
一人で行動していても、結果的に他の人も登場してきますが、手順に則りタスクを進めることで、他の方向性も見い出し進んだことになります。
個人的な突発タスクでの記録
原因不明のトラブルに見舞われ、てんてこ舞いしていたITスタッフ担当ではありますが、自分ひとりでやっているとはいえ、この事態を後から確認する時が必ずやってきます。
一人でやっているからこそ、記録することは重要と言えるでしょう。
0時の判断ポイントが来た時に、サーバOSでのエラーがなんなのかがわかりました。その影響で、アプリが動かなくなったのもわかりました。
これまでアプリの影響を都度記録していましたの、別な切り口での原因分析において関係性を見出すことが早くできました。
時間もないので記録はできず記憶だけになってしまいがちですが、ここはメモだけでも記録しておきたいところです。
記録は全プロセスにおいて重要ですので、本当は誰かにお願いしたいところですが、一人オペレーションが慣れている当のITスタッフは慣れていたのかもしれません。
まとめ
個人のタスクかつ突発的なトラブル対応という事例を挙げてみましたが、ある期限に向けて仕事を行う上では共通のタスクの進め方になるはずです。
個人ではありましたが、結果的には他の関係者も登場しました。
そのほうが健全にタスクを進めることができます。
基本は9つのステップです。
- STEP1やるべきことの背景・目的・方向性を見極める
- STEP2やることを見えるようにする
- STEP3見えるようにしても見えない部分が2割はある想定で計画する
- STEP4タスクの割り振りをする
- STEP5決定というスイッチを入れる
- STEP6行動する
- STEP7途中で予定に対して計測する
- STEP8計測時に進んでいなければテコ入れする
- STEP9次に誰でもできるよう記録する



コメント