仕事をしていると色々な依頼だったり作業が割り込みで入ってきたりします。
基本的には仕事は計画を立ててそれに沿って作業をするので「今日やるべき仕事」ってのは決まっているのですけれど、僕がやっているコンピュータエンジニア業界ではほぼほぼ予定通りには行きません。色々としたインシデント（事案）が発生するんですよね。
それが課題になったりプログラムの不具合（バグ）だったりするのですが、メインの作業にプラスしてそれらが割り込んでくる訳です。
課題なら「どうすべきか？」を考えてプロジェクト全体で共通認識として方針を決定する必要がありますし、プログラムの不具合なら修正しないと行けません。
これらは想定外に割り当てられる作業なので元々のスケジュールにはありません。
なので基本的には「いつまでに対応すれば良いですか？」と確認する作業が必要になります。納期（とか期限・期日）ってヤツですね。
できれば、そう言う問題・課題管理には現実的な期限が決められているのが理想です（そう言うプロジェクトは大抵成功します）
しかしながら、トラブっていたりすると「なるべく早く！」という超曖昧な期限になってしまうのです。
それが1件で「他の作業を止めてでもこれだけに集中してくれ！」という依頼であれば
『なるべく早く』片付けるべく全力を尽くしますが、往々にして『なるべく早く』という課題が2桁になると大抵失敗します。
『なるべく早く（通称：なるはや）』は英語ではA.S.A.Pと称され”As Soon As Possible”の略です。日本特有というか、海外でも言葉としては存在していますね。
これ、本当にやっかいなんですよ。そもそも「なるはや」な課題が10個あったとしたら優先順位がつけられません。重要度・緊急度がきちんと決まっていればある程度ロジックに合わせて優先順位をつけることが可能かもしれません。
しかしそう言うのすら無ければ、僕ならさらーっと全件目を通して一番簡単そう（楽そう）なヤツから順次処理すると思います。楽したいので。
こういう管理の仕方をしているプロジェクトは本当に厄介で困ってしまいます（管理してない！とも思ってしまいます）。
さて、この重要度・緊急度・期日というのは色々と複雑に絡み合った関係なのですけれど、アジャイル開発でスクラムという手法を使うとちょっと面白い事が出来るんですよね。
スクラムでのインシデントの管理には重みとしてフィボナッチ数を使います。
フィボナッチ数というのは、1,1,2,3,5,8,13,21,34,55……と続く数列で、2つ前の数字と1つ前の数字を足していけば求められます。
（ちなみにこのフィボナッチ数は黄金比となっております。結構自然界と繋がっていて「数学すげー！」ってなる話は沢山あります）
例えば、プロジェクトとしてあるあるで言うと優先度をA,B,Cの3段階にしたり、1,2,3,4,5の5段階で管理したりします。そうすると例えば優先度’5’の課題が沢山並んでしまうと、結局「全部重要！優先！」になってしまうんです。50段階とかにしても、おそらく40台の数字が並ぶでしょう。あんまり意味ないんです。
それに対してフィボナッチ数を割り当てると結構上手くいくんですよ。
55だと「これは凄く重要なんだな！」って思いますし、3とかなら「まぁ、後回しでいいでしょ」とか感覚で分かりますよね。もちろん、「全部55！」というのはルール違反として、どれか1つしか割り当てられないと言うルールにします。
そうすると共通認識でどれが一番今注力しないといけないか？が視覚的に分かります。例えば、50段階としたとして、優先度47と49（数値が大きいほど優先）だと「両方大事だな」ってイメージになるんですけれど、優先度34と55になると「55の方が大事！」ってのがイメージしやすいですよね。
（厳密にスクラム使うともっとしっかりしています。ここでは概要みたいな感じで……）
今火消しをしていてまさに「なるはや」が多くて困っております（チケットに期日を入れてくださいと言っているのに入ってないので……）
木曜の夜に珍しく遅くまで残業して棚卸ししていたのですが、まだ「なるはや」の仕掛かりが17件あります（ちなみに月曜日にいきなり「なるはや」チケットが新規で31件来ました）
とは言え今からPMOに「フィボナッチ数列使って重み付けして順位決めてくれ！」と言っても「そもそもフィボナッチとは……」から説明しないといけない（この開発はアジャイルではなく経験者がいないので）し、それをさらに幹部に説明するのも面倒なのでやめておきますが、もしこれを読んでいる人がエンジニア職などでインシデント管理に関連している人は「”なるはや”は使わない」癖をつけて貰えると幸いです。
