自分が成長でき、自分の価値が高まり、目標に近付ける重要度の高いタスクを優先するのが正解です。人生でもエンジニアライフでもより上を目指すならこれです。
緊急性の高いタスクも気になるところですが最低限に抑えて重要度の高いタスクにどれだけ時間を使えたかで結果が変わってきます。
緊急性が高いだけで自分の成長や実績にはつながりにくいのでやりすぎに気を付けましょう。
分析力や判断力を高め重要度の高いタスクに時間を使えるようになればデキるビジネスパーソンの仲間入りする日も近いです。
仕事はたいていの場合、早い方が偉いという世界なので完璧さは捨てて時短を目指した方が自分の評価が上がりやすいです。
逆に完璧さにこだわり時間をかけすぎてしまうと評価が上がりにくいので損です。
TTPモデルを探す
TTPは「徹底的にパクる」という意味の俗語です。
安易なマネごとや盗作はいけませんが、真面目に成功者のやり方をまねることは先人の知恵が活かせる賢いやり方です。
優先順位を考えるときには自分の価値感や夢、大目標などが基準になります。
ですが、それらが抽象的だと具体的な行動に結びつきにくいので、まずは目標を達成した成功モデルとしてTTPの対象となる人を探すといいです。
あなたの望む成功をすでに手にしているTTPモデルが見つかったら、どうすれば近づけるか考えて行動を続けていきましょう。
TTPモデルを見つけてその人の考え方を知れば、効率的な目標達成方法や問題点、実現できないことなどの現実的な問題を知ることができるでしょう。
そこで目標が間違っていたと分かれば軌道修正して、また別の目標に近いTTPモデルを探すこともできます。
どんなTTPモデルがいいか
自分のTTPモデルにする成功者は、自分の望む未来をすでに実現している人がいいです。
注意すべきは、自分がどうやっても実現できそうにない人は選ばないことです。
ソフトバンクのような大企業グループを一代で作り上げたいからといって孫正義をTTPモデルにしてマネしても、たいていの人にとっては実現性が低すぎて参考になりません。
TTPモデルは実際に実現できそうな範囲から選んで、それを実現したり状況や自分の気持ちが変わってきたら、また別の人を探したので問題ありません。
TTPモデルは遠い理想を追うより、現実的に追いつけそうな人を選びましょう。
あまりにも高い目標だけしか持たないと、実現できずに挫折しやすくなり、実現のための具体策も多すぎて特定しにくくなります。
有効な具体策がとれないと効率的にPDCAを回せなくなるので、自己成長できずTTPモデルに近付けなくなります。
また実際に自分の能力や実績を近づけられる範囲の人でないと、どれくらい近付いているのかといった成果を判断するのも難しくなります。
このようなことから目標とするTTPモデルは自分にも実現可能で、手が届きそうなルートを進んでいる成功者を選ぶことが大切です。
もちろん、その先の大目標として孫正義さんのような大企業家を目指すというのであれば問題ありません。
大目標を持つときの注意は、人は一度にひとつのことしかできないので、マルチタスク型にならないようにすることです。
まずは目の前の目標からひとつずつ達成していくことが成功への近道です。
人は楽をしたがる生き物
人の願望や欲求は矛盾しています。
超頑張って仕事や勉強ができるようになりたいと思う反面、一日中遊んでいられるなら遊んでいたいなどとついつい思ってしまうものです。
思いのままに生きているとどうしてお楽な方に流れて現状維持が続いてしまいます。
IOTやDX推進で社会構造がガラリと変わる可能性があり自己成長できない人は現状維持もままならない恐れもあります。
ですから、ぜひ成長型のマインドセットを身に着けて失敗も成功のための実験と思えるくらい前向きに考えてみてください。
そうすればあなたの目標に近付いていけるはずです。
他人の失敗をバカにする人とは付き合うな
極端な話、成功以外はすべて失敗だと判断することもできます。
「そんな失敗をしていてはダメだ」「自分はもっと早く出来たけどあなたは遅すぎる」などと言ってくるような人はマウントを取りたいだけなので関わらないほうがいいです。
他の部分でも他人の努力を笑うようなマインドな可能性が高いので百害あって一利なしです。
自分も世の中も変わっていくものなので成長に必要な努力や失敗をバカにしている人と付き合うことで大事な成長マインドを弱めてしまうのは損です。
重要度の重要性
優先度の高いことから取り組むこと自体はそれほど難しくありません。ちゃんと自分で何が重要なのかは分析して判断しておけばいいだけです。
なかなか難しいのが緊急性の高いタスクの対応です。
重要度の高いことをどれだけ出来たかで成長や成果が決まるので重要度こそが重要です。
重要度と計りにかける選択肢になるのが緊急度なのですがこれに時間をつかいすぎてしまうことがあります。
緊急なタスクの完成度にこだわりすぎて重要なタスクが進まなかったというのがよくあるパターンです。
緊急度が高いタスクは緊急なだけで重要度が低いことがあります。重要度が低いことをやっても成長や成果にはつながりません。
ですから、緊急度が高いだけのタスクは最低限の対応ですませたほうが効率的です。
とはいえ、やらないといけないことはやらないといけません。
対応が必須なことは後回しにするメリットはないので毎日まとめてやるかすぐできることはすぎにしたほうがいいです。
例えばメール返信などは社会人としては必須なので学生のみなさんも就職や仕事関連のメールがきていないか毎日チェックする習慣をつけておきましょう。
優先順位の決め方
自分の価値観にあった納得できるやり方で決めればいいです。
- 大目標と目指す理由やメリットを分析/自覚
- タスクのリストアップ
- タスクの重みづけをして重要度/不要度を決める
- リカバリープラン作成(作業の予備時間/休憩/趣味)
- タスクに優先度順に並べて管理
- 実現性と期待できる効果/成果をリストに反映
- 重要度/緊急度を分析しリストに反映
- 長期目標が複数あるときは並列処理する
これがタスクに時間を使う順番になります。
リストアップはなるべく細かい方がいいので思いついたものは全部リストアップするくらいでいいです。
優先順位を元に実作業へ
優先順位は大元の基準です。緊急タスクなどが発生したら作業順は変わってきます。
緊急タスクを最低限におさえ重要タスクにリソースをつぎ込むのが成長や成果を出すポイントです。
各タスクはスプレッドシートなどで管理し何がどこまで完成したかも書いておくと努力の実績を確認できるようになりモチベーションが維持しやすくなります。
- 緊急タスク対応(最低限におさえる)
- 優先タスク対応
- タスクがはかどらないときはタスクの詳細化や手順の見直し
- 心身ともに限界を超えたらリカバリー
- タスクがほぼ完了したら評価し優先順を更新
- 長期タスクの並行対応(読書を週3時間するなど)
リストが知的消耗をおさえる
自分の頭の中に入れておくだけど毎回いろいろなタスクのことを考え直さないといけないので頭が疲れます。
リストとしてアウトプットしておくと毎回優先順を考える手間がなくなる分だけ楽になります。
迷いは重いのほか知的エネルギーを使うので手順化やルーチン化しておくと消耗をおさえてメインのタスクにエネルギーを効率的に使うことが出来るようになります。
ビジネス書でウィルパワーというのが流行りましたが、人は判断するたびにウィルパワー(意志力/知的エネルギー)が減っていくという考え方です。
そのためオバマ大統領も毎日着る洋服を決めてウィルパワーを温存していたそうです。
ウィルパワーの分析がどこまで正しいのかは分かりませんが、知的に楽になるのは間違いないので判断を減らすというのは良策です。
人の能力は大枠では大差がないので難しいことをいかに楽にしていくかで差がつきます。
メモで知的リソースを節約
考えをメモに書くだけでもそのテーマが脳から出ていき脳のリソースが空きます。
そうすることで必要なことに脳のリソースが使えるようになりパフォーマンスが上がります。
ちなみにデジタルなメモよりアナログの紙のメモのほうが効果が高いことが分かっています。
IT社会なのに紙のほうが優れているとは驚きね。
マルチタスクとシングルタスク
昔はマルチタスクが効率的だとメディアがもてはやしていたのですが実際にはシングルタスクのほうが効率がいいことが分かっています。
中にはマルチタスク型の人もいなくはないのですがほとんどの人がシングルタスクのほうが仕事の効率がいいとうデータが出ています。
タスクの切り替えに知的なコストがかかるのと元々人間の脳がマルチタスクに向いていないとみられています。
優先順にタスクをこなしていくときもなるべくシングルになるようにしたほうが効率がいいです。
1時間ごとに別のタスクに切り替えるよりも10時間や30時間などと時間を決めてひとつずつ進めていったほうがいいです。
どこまでやるか決めておく
タスクにかける時間やスキルアップの合格ラインなどのゴールは先に決めておくべきです。
はっきりしたゴールがなくて無限にやり続けられることがけっこうあるからです。
「すべての創作物は作者の妥協で世にだされたものだ」と言うくらい止めるポイントは大切です。
タスクごとの作業時間の見積もりは管理職やCTO/PM/SEなどになったときに役立ちますし、見積もりが出来ないとフリーで仕事を引き受けるときにも困ります。
ただのいちプログラマーからステップアップするには必須スキルになってくるので時間感覚もみがいておきましょう。
時間管理は1週間や1ヶ月などの期間よりも1日や実時間で管理したほうがより正確な感覚が身に着くのでおすすめです。
スキルアップの基準を決めるのは少し難しいです。初心者が入門書を読むなら最初は理解度50%でいいでしょうし、就職に使うポートフォリオならプロに見せても評価されるレベルを目指すべきでしょう。
目的に応じて最適な基準が設定できるようにこのスキルもきたえていきましょう。
プログラミング言語の学習時間は関連技術の合わせて1000時間は必要だと言われています。
1000時間は意味や使い道などが分からなくても黙々と学習を続けていきましょう。
そこまでいかないと向き不向きも判断できないのでそこまでは多少分からないことがあっても問題ありません。
優先度リストも完璧でなくていい
完璧なリストを目指したり、時間を使いすぎてしまってはいけません。迷いとともに無駄な時間を減らすためのリストだからです。
リストで重要なのは大目標や上位タスクです。下位の優先度の低いタスクはどうせやらないので放置してもいいくらいです。
優先度が低いタスクを後から見返せばやらなくてよかったことが分かるはずです。
低優先度タスクは残しておいてもいいのですが、見直す時間も労力も無駄なのでキッパリと削除してしまったほうが効率がいいです。
別ファイルに移してもいいですが、また必要になったらリストアップすればいいだけなのでメインのリストからは消していいでしょう。
全部はできないのであきらめる
全部の言語/フレームワーク/サーバーなどを覚えるには時間がいくらあっても足りません。
全部できるようになってもそんな人にビジネス的な需要はあまりありません。全部を同時に使うアプリやシステムがないからです。
CTO やフルスクラッチエンジニアなら全部知っていてもいいですがどちらも管理タスクが増えてきてコーディングはあまりやらなくなるのでやっぱりあまり必要ありません。
初心者はたくさんの言語を使えるエンジニアのほうが凄腕のように感じるものです。
ですが、実際には主要10言語を使いこなせるのが自慢のエンジニアがいても全部中途半端にしか使えないだろうと思われてしまうでしょう。
広く浅くではあまり意味がないのです。それよりはひとつの言語のプロフェッショナルのほうが喜ばれます。
数で勝負ならJavaScriptの主要フレームワーク3つを使いこなせる人のほうが印象がよくなるでしょう。
例外というほどでもないですが人数が少ないチームでは何でもできるフルスクラッチスキルが喜ばれます。
フルスクラッチエンジニアを目指すなら小さな会社で幅広いスキルを身に着けていったほうが効率的です。
大企業だと一部分しか担当させてもらえないので意外とスキルアップしにくいことがあります。
とはいえ、Webでも業務システムでもネット/DB/アプリくらいは最低限使っているので関連する複数の言語は身に着けないといけません。
最初の就職のときは一点突破でもいいのですがその後のエンジニア価値は関連技術の種類や経験年数、コミュニケーションスキル、人間性(信頼できる良い人がいい)などが評価ポイントになるので高めていきましょう。
学習難易度は逆
最初の言語やサーバーを習得するのが一番難しくストレスが多いです。二つ目なら先に似た知識があるのでそれほど難しくありません。
エンジニアのスキルアップは最初が一番つらくどんどん楽になっていくので最初だけ我慢しましょう。
ちなみにトップレベルの研究などは難易度が高いでしょうがいわゆるエンジニアは技術を作る研究職ではなく、技術を使う側なのであまり関係ありません。
トライ・アンド・エラー
優先度、緊急度、重要度などの判断は難しいことがけっこうあります。トライ(アル)アンドエラーで失敗しながら進めていくのが正解です。
うまくいっていないから努力しているのであってやってみないことには分からないことはけっこうあります。
最初から完全に満足できるレベルまで分析/判断することはまず出来ないので50%以上分析できたらいつまでも調べたり考えたりしていないで作業を実行してしまったほうがうまくいきやすいです。
分析は50~70%くらいまではサクサク進むのですが100%を目指すととたんに難しくなり時間がかかってしまいます。
目標を達成するまでは何がよかったのか判断しにくいのでそもそも100%効率的なタスク分析などは不可能と考えておいたほうがいいです。
無駄な努力になるリスクはあるのですが平均化すると50%くらいの分析で作業を進めてしまったほうがうまくいきやすいです。
どうしてもやってみないと分からないことが出てくるので理論と実践を半々で進めていきましょう。
リカバリープラン
タスクが難しくて自分の手に負えないときや心身ともに疲労してしてしまったときの対応です。
タスクを冷静に分析して調べても解決できないときはいつまでも悩んでいないで相談したり、保留できるものは保留して次に進んだほうが建設的です。
後でスキルアップした自分なら解決できるかもしれないし、そもそも実現できない目標を立ててしまっている恐れもあります。
それらが判断できるようになるまで保留にしておいても大丈夫です。
仕事で引き受けてしまったときはもっと必死に解決法を調べないといけませんが、学習中なら保留で問題ないです。
仕事で問題解決するにはゼロから全ての処理や設定を見直せばヒントが見つかるはずです。
問題解決法やMECEというフレームワークもおすすめです。
これは問題を詳細にもれかぶりなく分析し、実現性や成果/効果の高さ、作業時間などを比較してタスクに取り組むという考え方です。
エンジニアの仕事以外でも人生全体で役立つので覚えておくと便利です。
エンジニア的にはその課題が自分や言語/システムなどで実現可能なのか判断することがまずは大切です。最初はこれが出来るようになることを目指しましょう。
出来ないことを出来ると言って引き受けて破綻してしまうのが一番よくありません。
出来ないことは素直に出来ないといっていい世界、というか、どうせバレるので最初から正直ベースで話した方が本人にとっても会社にとってもいいです。
できるかもしれないけど自信がない仕事を頼まれると迷うわね。
「とりあえず、調べておきます」ってことになるけど時間がないときは困りますね。
作戦の見直し
何をするにも細かく分析してみれば、抽象的な大目的から具体策まで深掘りして対処しているものです。
行動を続けて行き詰まった、あるいはこの道を進んでもダメだと分かってしまったときは上位の抽象的な目的に戻って作戦を見直せばいいだけです。
すぐにあきらめる必要はないんですよ。
具体策から大目的に戻る間には何段階かあるはずなので一段ずつ上に戻って見直すイメージです。
やるか・やめるか以外にも保留して後で挑戦するという第三の選択肢があることも忘れないでください。人生の可能性は無限です。
- よりよい人生を送りたい
- 安定収入、できれば高収入
- IT業界のITエンジニアがいい
- インフラエンジニアが寿命が長くてよさそう
- 学習範囲が広すぎて厳しかった
上の例なら学習範囲の広さが問題なので、いったん4に戻ってインフラエンジニアを目指すべきか見直します。
強いこだわりがないなら未経験からでもなりやすいフロントエンドエンジニアを目指すことに変えれば学習範囲がせまくなって学習しやすくなります。
フロントエンドからエンジニアになっても後からインフラ転向を狙えるので悪い選択ではありません。
実際にはもっと細かい目的や条件が出てくるのでマインドマップなどに書くことで客観的に把握しておくとより的確な問題分析と自己分析ができます。
自分が納得できるベストな選択を探すのが人生ってものさ。
予備時間の確保
スケジュールをキチキチに入れてしまうと予定がひとつ狂っただけで全体を直す必要が出てきて困ります。
予想外のことや超緊急課題など出てきたときに対応できるように予備時間を作っておくといいです。
読書や休憩時間を予備時間に変えられるようにスケジューリングしておくのもいいです。
何か作業が発生したらそれをやって何もなければ読書や休憩するなどの時間です。
スケジュールの見直し(リスケ)
学習や作業に必要な時間と残り期間を考えて、間に合いそうにないと分かったらなるべく早くスケジュールを変更したほうがいいです。
- 期間を延ばす
- やることを減らす
- 時間をかけて頑張る
自由時間を作業に回して解決するくらいならいいですが、時間には限りがるので時間をかけるのは基本的には悪手です。
仕事で優先度を考えるときは
基本は同じですが仕事は早い方が偉いという世界なので早くできることから仕上げていったほうが評価が上がりやすくなります。
仕事が早いと評価してもらえれば多少難しいタスクに時間をかけても「あの人が時間がかかるようなら難しい仕事なんだろう」といったように他のタスクでも評価されやすくなってお得です。
実は完成度は求められない
完璧主義の人には残念ですが完璧さは仕事ではあまり評価されにくいです。むしろ仕事が遅いというマイナス評価をされがちです。
仕事では100点満点の完璧なものよりも60点の合格ラインギリギリでも早くやったほうが評価が高くなりやすいです。
デザインや小説などの質が重要な創作物なら完成度が評価されるでしょうが、作業的な仕事では頼む側の要望は最低限のものをより早くやってほしいと思っていることがほとんどです。
エンジニアにとってのデキが90点でも60点でも、ビジネス的な評価や利益はあまり変わらないことが多いです。
偉い人には開発現場の美学なんて分からんのですよ。
どうせ売る値段は同じなのだから最低限で早くやってしまったほうがいいというのがビジネスの現実です。
中には最高品質を目指している会社もあるのですが少数派です。
そういう会社をクライアントにするといちいち細かい指摘をしてくるのでビジネスパートナーとしては少々手強いです。初心者はさけたほうが無難です。
各分野でトップを目指すなら品質重視でいいのですが、エンジニアだとマシンスペックも年々上がっていきます。
新しい技術も出てくるのでひとつの品質を高めるより関連技術をトータルでパフォーマンスアップ出来る方向性のほうが向いています。
品質はあんまり関係ないのか……
そのときベストなものを作ってもバージョンアップとかで状況が変わってきちゃうし、エンジニアの時給は高いから長時間働かせたくないとかいう理由もあるんでしょうね。
ちなみにエンジニア以外の職種でもよほどクリエイティブな仕事でない限りは質は最低限で速度を重視したほうが評価が上がりやすくなります。
経営者やクライアントの考え方も理解しておくといいです。
リスト化やマニュアル化の有効性
優先順位だけでなく他のこともリスト化やマニュアル化したほうが効率がいいです。より客観的に評価でき忘れることも防げ、さらに手法を継続的に磨き上げていくことも出来ます。
いいリストやマニュアルは量が少なく最低限の情報で最大限の効果が期待できるものです。効率化とともにシンプルで読むストレスが小さいものが理想です。
まとめ
優先タスク管理は要は時間の管理です。緊急性や完璧さ迷わされずにいかに重要なタスクに時間をつぎ込んで成長し結果を出していけるかがポイントです。
やりたくないことから逃げて楽だけどあまり効果のないことに時間を使うのも抑えていきましょう。
タスク管理の考え方は役に立つので毎日の作業も最初にタスク化しておくと達成感が味わえモチベーションを維持しやすくなるのでおすすめです。
モチベーションは結局のところ感情に迷わされずに大目標の達成に価値を感じ続けることが大切です。
一番結果の期待できるタスクにどんどん時間をつぎ込んでいけばどんどん目的達成に近付いていくことができます。
根本的には成長と時短マインドが一番大切です。タスクや仕事としては、いかに難しいことを楽に早くできるかがテーマです。
コメント