タスクとは

タスクとは

タスクとは様々な場面にて様々なものが当然ありますが、一つのコトを完成させるには、一連の行為を行う必要があります。そしてこのタスクが積み上がったものが、最終的に全体の完成を意味することとなります。

システム開発を大まかなタスクで見るのであれば、プログラムを作成するというのがコアのタスクにはなりますが、要件定義、設計という前のタスクがあり、テスト、リリースという後のタスクもあります。

システム開発を行ってください、と依頼された時に、プログラム作業の見積だけをして取り組むということはないと思われますが、似たようなことは実はよく起きています。

実際は何をすべきかを見極めて、実行し、実行した結果を確認し、新しい環境へと対応させる、といった一連の行為が必要であるにもかかわらず、実行だけを見てしまっているということです。

実行や作成という行為は比較的分かり易い作業なので、自分でもやり易いですし、人に頼みやすいものでもあります。ところが、何らかやらないといけないのに、実行することが具体的にわからないことがあるので、停滞が発生します。

あるいは、実行したものの品質を担保するという行為はセットになってしかるべきですが、実行のみを見ていると、実はきちんと仕上がっていなかったということになります。プログラム作成で言えばテストはセットになっていると思いがちですが、現場ではそれさえもできていないことが起こり得ます。

したがって、ITマネジメントを有効にするためには、正しいタスク手順を踏んでコトを進めるということが必要となってきます。

タスクの種類

やるべきタスクがなんとなくわかっているのに、実際は何をしていいのかわからない場合、大まかには実行や作成のタスクの前に2段階、後に1段階以上はあると思っていたほうがよいでしょう。

当然必要な工数も期間もその段階に応じて増えていきます。

タスクについては非常に様々なものがあるのは確かですが、IT現場において発生する多くは、4段階くらいのものでまず考えましょう。

その4段階は以下です。 

認知・展望のプロセス

認知はまず何をそもそもやるべきなのかと知るということになります。

その手段もわからない場合は、誰がそれを知っているか、何をすればわかるか、どこかで買ってくる必要があるか等のあらゆる手段を考えるところからタスクが始まるということになります。

スタートラインとしての現状がわかっていないこともあります。現状を分かる必要がある場合は、現状分析を前タスクとした上で、実際にやるべきタスクに移ります。

未来になるべき姿が明確になっていない場合も、当然その姿を描くことが先にやるべきことです。これからどのようにやっていくのかも展望を描きます。

定義・計画のプロセス

認知し展望することだけでは、まだ何をやるべきかが具体的でないことが多いです。

具体化することが定義です。

特に何をしたいという話は具体性に欠けていることが多いです。

したいことを実現するには、何と何と何をする、ということを明確にすることが定義ということになります。何をするかわからないのに、したいことを受けて実行に移るというのは、できそうにないと思えるかもしれませんが、実際はよく起きています。

なので漏れなどが後から発覚します。

定義するというは決断でもありますで、意外と決定に時間を要することもあります。

それを踏まえてタスクを見込む必要があります。

具体化するのが定義となりますが、これからどのように進めていくかということは計画となります。

やることが決まっていれば計画こそなくても実行していくことは可能と言えば可能ですが、何をいつまでに実行し、それを受けて別なことを実行するといった時系列のことや、誰が実行するという体制面の話も計画していく必要があります。

無計画仕事の多くは後で問題が発生し、費用的にも被害を被ることになりますので、実行を急ぎたい場合においても、計画するタスクを見込んでおくことが重要となります。

実行・作成のプロセス

実際に行動し仕事しているのがこのタスクです。

実行であったりものづくりであれば作成という行為になります。

非常に短く単純なことであれば、単に何をするという行為と捉えて構いません。しかし、ITの場面においては、多くはもっと複雑になります。

よって前もって計画が必要となってくるのですが、実行段階で重要なことは、予定どおり進んでいるかを確認し、もし進んでいなければ是正しなければいけないということです。

予定どおりかどうかの確認方法についても前タスクとして計画すべきですが、実際に実行するのは実行段階であるため、実行時に確認すべき項目、多くは計測可能な項目ということになりますが、それをわかるようにするのも実行タスクに含まれるということになります。

ITは特に見えないものが多いため、製作物のように見ればわかるでしょ、ということにはならず、分かり易い計測方法を考えておく必要があります。

仕上・受入のプロセス

実行や作成のタスクは終われば完成と言えるのですが、その結果がそもそも目的と合っているのか、新しい環境に融合できるのか、先に決めた定義どおりか、などの検証が必要です。

単純な仕事であっても、他人によるチェックなどで完全性を保証するという行為もよく行われます。

ここでは仕上げのタスクと言っておきます。

先に計画する段階においても、ただ作成するだけではなく、きちんと仕上げを行うタスクを後で見込んだ上で、最終作成物になる、という計画としておきたいです。

システム開発で言えば、段階的にテストを行うということになります。実行や作成を人に任せることもあるかと思います。その場合も仕上げは当然必要です。

ITの場面ではレビューを経て受け入れるということなります。

レビューでは多様な立場からの目線にて問題ないかを確認することになります。

受入については、単に受け取るだけであればタスクというほどではないですが、実際は受入という行為をそれなりの工数・期間にて実施しないと完全にはならないことが多いため、予めタスクとして考えておいたほうが無難です。

さらに言えば、1回の受入で終わらないことも想定し、2回対応として予定しておいたほうがよいケースも多々あります。

 まとめ

ITの現場で出くわす多くのタスクの種類については以下の種類となっています。

実行プロセスを急いで行うがゆえに、実はしっかり計画がなされていなかったとか、行く先が見えていなかったということがあり得ます。もし実行しているタスクに課題を抱えている場合は、プロセスが不足していないか確認しましょう。