タスク設計における、3ステップの「理由付け」

Created:

2021-04-26

Updated:

2021-04-26

例えば、このようなタスクを他人に指示・依頼することを考える。

仮想ストレージのサイズを倍にしておいてください。

このときに、依頼者・被依頼者の関係性がタスク内容を吟味することを要求可能であれば、 依頼側は次の点に対して何かしらの形式で「理由付け」を答えられる必要がある。 [1]

  • 目的とする状況（なぜやるのか）

  • 手段の選定理由（どうやるのか）

  • 数量の算出理由（どれだけなのか）

という話をこのノートでは書く。

前提

ここから先の内容は、依頼者・被依頼者の間で上記のことを質問・回答できる関係性にあることを前提としている。 そもそも、これができない関係性でタスク依頼などは極力するべきではない。

一応、例外適用条件は存在するとは考えており、そちらに関しては 文末 参照。

「タスク」の範囲

「現在/過去/予測の状況」と「本来の状況」のズレを「問題」として捉えて、 この「問題」を解決するための手段として取るべきと考える「アクション」をタスクと定義する。

ここでの「問題」は前述の通り「過去・現在と未来のズレ」であるため、 障害・不具合と言ったいわゆるトラブルの類にとどまらず、もっと多くの範囲に適用できる概念になる。

  • 請求書の発行 = 「請求書が必要になった瞬間は存在しない」ので「請求書が存在する状況に」するためのアクション

  • ストレージ拡張 = 「予測としてディスク使用状況が100％に到達しつつある」ので「使用状況に余裕をもたせる」ためのアクション

3ステップ

ここからは、上記の3ステップが意味するものと、回答有無による効果を整理する。

目的とする状況

タスクの定義として「問題の解決」を置く以上、「解消されたあとの『本来の状況』」を正しく認識・言語化する必要がある。 さらに目的にはグラデーションが存在することが多く、 タスクそのものがもたらす「直接的に解決したい状況」だけではなく、 タスクの遂行の先にある「本質的に解決されていないといけない状況」を考える必要がある。 [2]

例の「ストレージ拡張」であれば、直接的な効果として「ストレージ容量の増加」を得られるが、 ただ容量増加だけが目的になることはまずなくて、「容量が増加された状態」になった結果として どんな状況になっていてほしいかを意識しないといけない。

ここが見えないとどうなるかというと、

  • 目的が見えないため、複数のタスクで優先度を付けないといけないシーンで優先順位の基準点を設定できない

  • 「本質的に解決していたい状況」への手段として正当なのか吟味が出来ない

という状況が発生する。

手段の選定理由

さて、最初のステップで「目的」に対して「手段」が正しいとしよう。 次の段階ではこのような疑問点が出てくることだろう。 「他により良い手段はなかったのだろうか」

引き続きストレージ拡張を題材にすると、「容量の増加」がもたらすものは「全体としての使用率の減少」である。 このときに、ストレージ拡張という手段はいわゆる「分母を増やす」アプローチとなっている。 ここで考慮しないといけないのは「『分子を減らす』アプローチは存在しないのか」ということである。

例えば、全く不必要なファイル出力をずっとしているとしたら、ストレージ拡張は一時的な効果はあるにしろ、 いずれ使用率は再び危険な状況になっていくことだろう。

この場合、「ファイル出力を止める対応」にかかるコストを踏まえた上で「ストレージ拡張を選択した理由」を 持っていないといけないだろう。

これは何も、「誰もが納得できる精密で正当性の高い理由」である必要はまったくない。 状況に応じて変動しうる要素が多いので、大枠だけでも良い。

例えば、ストレージ拡張の例では「マシンの生存期間的に、修正コストよりストレージコストが低そう」ぐらいでも十分である。 極端な話では、「ファイル出力減らせないの？」という問いに対して「思い浮かばなかった」でも良い。 [3] 重要なのは、この時点では「どんな判断でこの手段を選択したのか」の意思を言語化出来ていることである。

数量の算出理由

※この項目はフラグ的なオペレーション（設定のON/OFF）のときには当てはまらない

最後に来るのは「数量設定に関する妥当性」となる。 ここの数値を何も考えずに指定することも避けたい。

ストレージ拡張を例にすれば「どれぐらい容量を増やすのか」の理由付けとなる。

IaaSを利用したクラウドインフラを構築する場合、 ストレージとは「お金が許す範囲において、無限大の容量確保が可能」 と捉えて差し支えないだろう。 [4]

もちろん容量x時間で費用が発生するために、何も考えずに「いっぱい増やす」というわけにはいかない。 そのため、次のような観点で決めたりする。

  • 1回の作業として、どれぐらいのコストがかかるか

  • どれぐらいの増加ペースを賄う必要があるか

    ex: 「1GB/dayの増加ペースで、ローテートの関係で30日分あればいいので、余裕を持って50GB」

別ケース：ログの刈り込み

ログのローテートがそれなりに長めに取られてて、 なおかつ何かしらの理由でローテート期間を減らす対応をするときの話。 （前2段の結果としてローテート日数を減らす結論が出ているものとする）

この場合は、「出力しない」が理論上の限界値となり 「無限大に減らす」ことが出来ない。 また、ストレージと違って、減らすことによる金銭的インセンティブが無い。

これらを踏まえると、以下のような観点が必要になってくる。

  • ローテートをどこまで減らしても運用観点で困らないか

例えば、デフォルトで30世代分のローテート保持をしているが、 実はサイクルとしては1週間分までで十分かもしれない。 このあたりは、要件としてどうなっているべきかをなるべき知っている必要がある。

なお、これらの根拠についても決して精緻である必要はない。 少なくとも「自分はこう思ってて、こう設定した」という意思が言語化できていれば良い。

逆説的な書き方になるが、「特に根拠はないけど、こう設定する」は論外で、 こんな理由でオーダーを出すぐらいなら 「適切そうな解が思い浮かばないので、一緒に考えて」 のほうが遥かに有用である。 [5]

※例外適用が可能になる条件

この話にも一応例外みたいなものはあって、次の2条件のいずれか満たすのであれば、 やり取り自体は無理に行わなくても良いとは考えられる。 [6]

  1. そのタスク内容の土台となる知識・技能について、能力差が 依頼者>>>被依頼者 と表現できるレベルで格差がある

  2. 契約として、被依頼者がが依頼をもとに行うアクション全てにおいて、依頼者側が全面的な責任を持つことになっている

前者に関しては、被依頼者が出してくる疑問点などに関しては、ほとんどのケースで依頼時点でカバーできているか、 考慮する必要が無いと判定できうるため。 もちろん、どんなに差があっても支店の違いから生まれる見解は良いものを産むケースがあるため、 被依頼者は不明に思った点を聞くほうが良い。

後者に関しては、極論この条件が完全に成立するなら被依頼者としては、さっさと作業したほうが効率が遥かに良いため。 ただし、アクションの結果を含めてこのような条件が成立するのはまず無い。

脚注

※脚注