こんにちは。システムチームのKです。
今回はタスクの不安度について書きたいと思います。
不安度とは
不安度とは、渡されたタスクに対して直感的に感じる不安を数値で表したものです。
不安度が高ければ当然、そのタスクの達成率は低くなります。
逆に低ければ実装までのイメージが湧いている、ということになり、達成率は高くなります。
そのため、タスクに取り掛かる前に不安度を解消するための時間をとっていただいています。
今までは不安度解消を上司に頼り切りにしており、自分は不安に思っていることを書き出すだけ。
書き出した不安を上司に説明していただいて不安度を下げるという動きでした。
しかし、この方法では自分で不安度を下げる力がなかなか身につきません。
上司がどのように自分が出した質問に答えていて、どのような回答をもらえたら不安度が下がるのか。
そう言ったことを考えながら聞く必要があるのだと思います。
不安度解消のタイミング
タスクに取り掛かる前、実際に改修対象となるファイルなどを確認し、出した不安の中身を明確にします。
それらを元に、取り掛かる前に不安度を解消します。
しかし、不安度は下がればずっと低いまま、というわけにはいきません。
実際に改修を始め、思った通りに進むことの方が少ないです。
デキテルはサービス開始から10年以上経っています。積み重ねたコードやファイルが複雑に関係し合っているので、少しの改修でもいろんな箇所に影響を及ぼす可能性があります。
そのため、当初の想定以上に難解なコードに出会うことがあります。
また、想定外の挙動をすることもあります。
そう言った時、原因がすぐに分かり、解決策も見えているのであれば不安度は変わりません。
しかし、多くの場合は想定外のため、原因や解決策を見つけるためにコードを書いてどうにかしようとしてしまいます。
これが最も時間を取られる動きです。
想定外が起きたのであれば、自分の想定した実装方法が正しいのか、立ち止まって考える必要があります。
すぐに原因や解決策が出ない時は、下がった不安度は高くなります。
高まった不安度をもう一度下げる必要があります。
実装を進めていて浮かんだ不安の内容を書き出していき、その原因を調べます。
自分の手に負えない場合は上司に相談する必要もでてきます。
上がった不安度を下げ、低い状態を維持することが、タスク達成には不可欠な行動です。
まとめ
今回は不安度について書き出してみました。
タスクに対するふわっとした不安や悪い予感、みたいなものは当たりやすいと感じます。
それを回避するためにも、不安度が高くなった時はそのまま進まず、
立ち止まって不安の内容を明確にすることが大事だと思います。
ここまでお読みくださり、ありがとうございました。
