こんにちは。
システムチーム/プログラマーのNです。
制作チームは週単位で担当するタスクを決め、仕様を作成し承認を得て実装に入ります。
承認を得る内容は仕様だけではなく、「不安度」「着手順」「なぜそのタスクをするのか」という項目があります。
今回のブログはその「不安度」について考えてみようと思います。
不安度を下げるということ
担当するタスクが決まった時点では不安度は高い状態です。
一部の文言の変更など難易度の低いタスクは、この時点でやることを明確にしやすいので短時間で不安度を下げることができます。
大きな機能を追加することや、システム全体に影響が発生するタスクの場合は、頭の中だけでは処理できない部分が多く、その分「不安度」も高いです。
不安度が40%以上あるタスクは相談が必要で着手承認を得ることができません。
これは、上司が部下の業務を完遂できるように知恵を絞って作ったものになります。
不安度を出す仕組みにより、業務を完遂できることが増えてきました。
どの部分が不安なのか、漠然としたものを明確にし、上司にヒアリングをする必要があります。
不安な状態でスタートすると、必ず途中で手戻り・差し戻しが発生します。
なので着手前にその部分を潰します。
不安度は０にはならない
不安度０の考えではいけないと言ったほうがいいかもしれません。
不安度０ = 安心という考え方は危険だからです。
不安度が低ければ低いほうがストレスを感じる部分も低くなります。
人間なので、無意識の部分で自分でも気づかないうちにストレスの低いほうに考えが流されていってしまいます。
安心だと断定してしまうと、その部分を深く考えなくなり、そこに実はバグが潜んでいることに気づいていないという状態になってしまうからです。
常に不安と向き合うこと
不安と向き合うということは、常に
「本当に大丈夫だろうか」
「このまま進めても大丈夫だろうか」
と考えることだと思います。
常に不安なところがないか考えることによって相談が発生し、事前にバグを無くすことができます。
自分のタスクではなく会社から預かっているタスク
自分に向けてのブログでもあります。
しっかりとしたクオリティで返せるように、常に不安度を考えて作業をします。
最後までお読みいただき、ありがとうございました。
