下っ端の仕事の付加価値の付け方 〜「藤原先生、これからの働き方について教えてください。」を読んで〜

これからの人生を考えていこうということで、

　「藤原先生、これからの働き方について教えてください。(藤原和博 著、ディスカバー・トゥエンティワン出版)」

という本を読みました。

 

著者の経験をもとに、

今までの日本社会(成長社会)におけるキャリアの考え方と　

これからの日本社会(成熟社会)におけるキャリアの考え方を比較し、

いかに自分がレアな(希少価値の高い)存在になれるか、

が書かれていました。

 

今回はその書評を、、、ではなく、

タイトルにあるように「下っ端の仕事の付加価値の付け方」 についての内容です。

 

 

この本の中には、仕事の取り組み方について、以下のように書かれていました。

 

誰にでも共通していることが、1つあります。

今の仕事を漫然と続けていても、付加価値は上がらないということ。

  ーP.25 ORIENTATION 1 「自分の仕事の付加価値」を計算する　より

 

誰かに与えられて行うことは、仕事ではなく”作業”にすぎません。自分から見つけ出して、取り組むものを”仕事”といいます。

　ーP.191 LECTURE 4−2　21世紀の働き方を体現する「自分ベクトル」の作り方　より

 

上司から与えられた仕事を、ただただ”こなす”だけでは、目の前の仕事は片付いても、自分の血肉にはならないということです。

 

たしかに、誰でも入社したての頃は、上司や先輩に与えられた仕事をひたすら片付けることばかりだったと思います。

しかしその状態のまま「漫然と」働くと、ふとそれまでの仕事を振り返った時に、「私って何をしたんだっけ？」という感覚に苛まれます。（私自身そうなりました…）

そしてただただ与えられたことだけに反応するロボット野郎になってしまいます。

 

では、そんな感覚に苛まれず、ロボット野郎にならないように、

 

　取り組む仕事を自分から見つけ出すにはどうするか。

　ただの下っ端の立場で、どう”仕事”を探してくるか。

 

 

この点がわからないことには、対処のしようがないのですが、本書には書かれていませんでした。。

 

「そこは自分の頭で考えろ！」と言われる気もするので、自分なりに考えてみました。

 

３つ浮かんだのでそれぞれ書きます。

 

 

---

 

１つめ　仕事はどこからやってくる？

 

与えられる仕事があるということは、その仕事を誰かが見つけ出している人がいるということです。

 

「その人がどうやって仕事を見つけてきているのか」を考えてみたり、あるいは直接聞いてみたりすることで分かることがあるんじゃないか、と。

 

そして、上司に仕事を与えられた時には、「なぜこの仕事が必要なのか」を考え、上司の意図の探ることで、付加価値をつけて結果を残すことができます。

 

 

例えば、「先月のサーバの稼働状況をお客さんに説明するから、この資料のようにまとめておいて」と言われたとします。

 

ここでただ言われたとおりにまとめるだけでは、著者の言葉でいう”作業”になってしまいます。

 

そうではなく、「どの立場のお客さんに説明するのか」「何の目的で説明するのか」を明確にし、その回答に沿ったまとめ方にするのです。

 

システムのことをあまりよく分かっていない人に説明するならば、言葉をわかりやすく丁寧に記載する。サーバに詳しい人に説明するならば、ある程度言葉を端折って、少し込み入った話も混ぜ込む、といった具合に。

 

そうすることで、上司はお客さんに格段に説明しやすくなり、それが自分なりの「仕事の付加価値」になると思います。

 

 

ただまとめるだけでは、とてもつまらないタスクですが、仕事を与えられた意図を汲み取り、付加価値をつけて返す。

つまり、付加価値をつける、という仕事を見つけ出して、取り組んだことになります。

 

こうすることで自分のしていることが、”作業”から”仕事”へと変わります。

 

(BtoBのシステムの仕事をしている身なので、近い職じゃない方には、イメージしづらい例ですみません…）

 

 

２つめ　いつも同じことの繰り返し、を無くす

 

誰でも働く上で、いつも同じことの繰り返しになる仕事が少なからずあると思います。

 

ここに実は付加価値をつけるチャンスがあります。

同じことの繰り返し、ということは、機械化しやすいということです。

 

ツールを自分で作ったり、既製品を導入したりして、同じことの繰り返しを自動化する。

これこそまさに自分で見つけ出した仕事になり、組織に貢献したといえるでしょう。

 

そして何より自分が楽になり、他の仕事に時間をかけられるようになります。

 

 

３つめ　こうしたらもっと良くなる！を提案する

 

３つ目は、いわゆる顧客に提案する、というやつです。

 

何も新たな自社サービスを提案する、ってわけではありません。

 

いつも自分がやっている仕事やお客さんがやっている仕事を振り返ってみるんです。

細かい部分まで振り返り、より具体的にイメージすることで、お客さんが気にしている点、大変そうにしている点が見えてきます。

 

たとえば「共有している管理資料の更新をよく間違えてるな」とか「いつもこの点についての質問や確認が来るな」とか「毎週の打ち合わせにいつも時間がかかっているな」といった具合に。

 

 

そしてその点を改善するにはどうするか、お客さんが楽になるにはどうするか、を考えて、提案します。

たとえば先ほどの例に合わせると、

 

共有している管理資料の更新をよく間違えてるな

　→　共有している管理資料を、より見やすく更新しやすくしよう

 

いつもこの点についての質問や確認が来るな

　→　いつもお客さんが気にしている点を先回りして回答する、もしくはテンプレート化して定期報告する

 

毎週の打ち合わせにいつも時間がかかっているな

　→　打ち合わせの前に、あらかじめ話す内容を共有しておく

 

といった提案をするのです。

 

そうすることで、お客さんを楽にする、という付加価値をつけたことになります。

 

ただし、他２つに比べて難易度が高いと思います。

いつもやっていることを変えるということでお客さんを説得（魅了？）させる必要がありますし、楽になると思ってやってみたことがミスの温床となるなど裏目にでることもあるからです。

 

そのため、よく上司や先輩と検討して、お客さんに提案する必要があります。

とはいっても漫然とこなす仕事よりも数倍やりがいを感じ、楽しめるはずです。

 

 

---

 

 

さてさて以上３つが

　取り組む仕事を自分から見つけ出すにはどうするか。

　ただの下っ端の立場で、どう”仕事”を探してくるか。

に対して自分なりに考えた結果です。

(考えた、とはいっても、上司に言われたことや自分の経験、いままで読んだ本や記事がソースにはなっています。)

 

 

 

１、仕事はどこからやってくるか

２、いつも同じことを繰り返していないか

３、何か困りごとはないか

 

以上を意識して、仕事に取り組むことで、「漫然と」働くことは防げます。

 

 

早速、明日から実践してみてはいかがでしょうか。

(私も引き続き、"仕事"をしていきたいと思います。)

 

 

ではでは。

本を読む時に、内容を吸収するために実践していること

ビジネス書や自分の興味のある分野の本（小説以外）を読む時に、ただ読むだけだと記憶に残らずに「もったいない」と感じてしまいます。

せっかく「なるほど！これは良いことを読んだ！」と思っても、覚えてなければ意味がないです。

そこで、

私が本を読む時に長らく実践していることがあります。

それは以下の３つ。

　１、印をつけながら読む

　２、印をつけた部分をメモに起こし、自分の考え・感じたことを書く

　３、メモを貯め、実行に移し、結果をさらにメモに残す

 それぞれ解説していきます。

１、印をつけながら読む

本を読む時には、括弧「」を使って印をつけています。

ボールペンだとなんとなく嫌なので、鉛筆でそっと印をつけています。

 

印をつける場所は、自分が気になった部分、覚えておきたいと思った部分、疑問を呈した部分などなど。

 

 

下の絵のように、「」をつけます。

 

また、括弧をつけたページの右上に◯印もつけておくことで、後でどこに印をつけたか分かり易くなります。

見開きの左ページにしか印をつけていなくても、左上ではなく右上に◯印をつけることがポイントです。

左上にもつけるとパラパラパラーっと印を探すときに右と左どちらも見なければいけなくなって時間がかかってしまいます。

 

（便宜上、赤字で示しましたが、実際は鉛筆なのでグレーです。） 

 

 

２、印をつけた部分をメモに起こし、自分の考え・感じたことを書く

その後、印をつけた部分だけ、メモに起こします。

私は、Evernoteを使っています。

 

 

まずは本の印をつけた部分をメモに起こします。

 

この部分、Kindleで読んだ本だと、自分が印をつけた部分(KindleでいうYour Highlight)を自分のAmazon Kindleのページからコピペできるので、一瞬でできます。

 

しかし、紙の本の場合はそうはいきません。

ひとつひとつパソコンやタブレットなどで打ち込んでいくことになります。

 

 

ここで役に立つのが音声入力です。

 

印をつけた部分をただ声に出して読むだけ。

そうすることで自動的に文字に起こしてくれます。

 

読むことで印をつけた記憶に残りやすくなるので一石二鳥だと思っています。

 

 

 

さて話が逸れましたが、印をつけた部分をメモに起こしたら、今度はそれぞれに対して、自分の感じたことや考えを書き記していきます。

 

自分はこう思う、とか、これは実践してみよう、とか、これはもっと調べてみよう、とかとかです。

 

この時、意識しているのは、なるべく自分の考えをたくさん書き残すということ。

 

そうしないと自分の頭でしっかりと考えを深めていけず、腹落ちせずに終わってしまいます。

そして結局は本に書いていることを鵜呑みにしてしまうことになります。

 

腹落ちしないと、記憶に留まらず、読んだことが水の泡に帰してしまうのです。

 

 

 

３、メモを貯め、実行に移し、結果をさらにメモに残す

一つの本に対して、２番までの作業が完了したら、次は自分の考えをカテゴリ分けして他のメモに残しておきます。

そうすることで、他の本のメモと合わせてまとめて読み返すことができます。

 

 

 

また、ある程度一つのカテゴリが溜まったらブログの記事にして残すこともできると思います。

 

 

メモの中には、実践してみようという項目も出てきます。

そういう項目はToDoリストにしてガンガン実践していきます。

 

そしてその結果をまたメモに残す。

 

 

 

 

こうすることで、本の内容を自分の腹に落とし込み、自分の血肉へと変えていけます。

 

 

PostgreSQL データ型メモ

 

大きく分けて３種類のデータ型が存在する。

　①文字列データ型

　②数値データ型

　③日付・時刻データ型

 

 

①文字列データ型

　Character varying型：

　　文字数に上限のある可変長の文字列型。varchar(桁数)　でも宣言可能。

　Character型：

　　文字列に上限のある固定長の文字列型。

　　固定長なので、足りない部分には空白が入る。char(桁数)　でも宣言可能。

　text型：

　　文字数に上限のない可変長の文字列型。

 

実際に試してみる。まずはテーブルを作成。

postgres=# create table moji_data(

postgres(# varstring varchar(5),

postgres(# string char(5),

postgres(# moji text);

CREATE TABLE

postgres=#

postgres=#

postgres=# \d moji_data

           Table "public.moji_data"

  Column  |         Type                 | Modifiers

-----------+-----------------------+-----------

 varstring | character varying(5) |

 string      | character(5)      　    |

 moji        | text                    　   |

 

postgres=# 

 

データを挿入してみる。

postgres=# insert into moji_data values('ABCDE','AB','ABCDEFGHI');

INSERT 0 1

postgres=# select * from moji_data ;

 varstring | string   |   moji   

-----------+--------+-----------

 ABCDE   | AB       | ABCDEFGHI

(1 row)

 

 

宣言した桁数以上の文字数を格納しようとすると、エラーになる。

postgres=# insert into moji_data values('ABCDEあいう','AB','ABCDEFGHI');

ERROR:  value too long for type character varying(5)

postgres=# 

postgres=# insert into moji_data values('ABCDE','ABCDEFGH','ABCDEFGHI');

ERROR:  value too long for type character(5)

postgres=# 

 

 

文字列型はこの３つのみ。

気になるのは「どう使い分けるか」というところ。

 

charは自動的に空白が追加されてしまうので、注意が必要になる。

なぜなら、下記のようなことが起こり得るから。

 

postgres=# select * from moji_data ;

 varstring | string |   moji   

-----------+--------+-----------

 ABCDE     | test   | ABCDEFGHI

(1 row)

 

postgres=#

postgres=# select * from moji_data where string = '%est';

 varstring | string | moji

-----------+--------+------

(0 rows)

 

postgres=# select * from moji_data where string = 'test ';

 varstring | string |   moji   

-----------+--------+-----------

 ABCDE     | test   | ABCDEFGHI

(1 row)

 

postgres=# 

 

つまり空白を考慮せずに検索しようとすると、引っかからなくなる場合がある、ということ。

 

そのため、charは文字数を固定したい場合(一〜十の漢数字のみを格納するとか？)のみの利用に留めた方がよいのかも。

 

(文字列を固定したい場合がどんな時か、思いつかない。。。)

 

 

 

varcharは宣言した文字数しか格納できないため、文字数を統制することができる。

 

たとえば人名や都道府県などある程度の文字数が決まっているものは、varcharで宣言した方が、間違えて住所全てを記入してしまう、なとどいうことを防げる。

 

 

textは無制限に文字数を格納できるため、住所やアンケートの自由記入欄など、人によって何文字にもなり得る項目に設定することで長所を活かせる。

 

 

まとめると、こんな感じ↓

 

文字列型の使い分け方

　char型：固定文字数の文字列を格納したい時

　varchar型：文字数制限したい時

　text型：文字数が事前に把握できない時、どんな文字数であっても構わない時

 

 

(まとめてみると、当たり前のことを書いてるだけのような気がしてきた。。。)

 

②数値データ型

　integer：整数値。少数を入れたとしても四捨五入されて整数として格納される。

　numeric型：整数と少数を合わせて1000桁までの値を取れる数値型。全体の桁数と小数点以下の桁数を取ることができる。

　　たとえば「numeric(6,2)」と宣言すると、9999.99までの値を格納することができる。

 

まずはテーブルを作成。 

postgres=# create table data(

postgres(# int integer,

postgres(# num numeric(6,2)

postgres(# );

CREATE TABLE

postgres=#

postgres=# \d data

        Table "public.data"

 Column |     Type          | Modifiers

----------+---------------+-----------

 int         | integer           |

 num      | numeric(6,2)  |

 

postgres=# 

 

データを挿入してみる。

postgres=# insert into data values(10.3, 1234.56);

INSERT 0 1

postgres=#

postgres=# select * from data;

 int   |  num 

-----+-------

  10  | 1234.56

(1 row)

 

postgres=# 

postgres=# insert into data values(10.8, 9.9);

INSERT 0 1

postgres=#

postgres=# select * from data;

 int   |  num 

-----+-------

  10  | 1234.56

  11  | 9.90

(2 rows)

 

上記の9.90のように桁数は自動で補われる。

 

他にも数値データ型は多数存在する。

下記ページに詳しくまとまっている。

 

PostgreSQLのデータ型とその挙動のまとめ（数値型）

http://qiita.com/windows222/items/5c5a7ef3beb6f1d8f8aa

 

 

③日付、時刻データ型

　　data型：日付を格納するデータ型。

　　time型：時刻を格納するデータ型。

　　timestamp型：日付と時刻を格納するデータ型。

 

 

 

 

 

 

 

 

Python3 まとめ（１） 〜数値・変数〜

Python3を習得中なので、まとめておく。

 

まずは、数値と変数について。

 

情報源：

 UDEMYの講座(A Gentle Introduction to Python Programming)

 書籍(入門 Python3)

 

 

数値

+, -, *, / ：四則演算(足し算、引き算、掛け算、割り算)

//：割り算(切り捨て)

>>> 1+1-1

1

>>> 2*3

6

>>> 15/2

7.5

>>> 15//2

7

 

%：剰余(割り算の余り)

**：指数 

>>> 15%2

1

>>> 2**4

16

 

ちなみに…

divmod関数を使うことで、商と余りを同時に求められる。

>>> divmod(9,5)

(1, 4)

>>> divmod     ( 9 , 5 )

(1, 4)

そしてけっこう空白に寛容。

 

数字の前に0を置くとエラーになる。

>>> 05 + 2

  File "<stdin>", line 1

    05 + 2

     ^

SyntaxError: invalid token

>>> 5 + 2

7

 

スペースは必須ではない。空白がなくても、いくらあっても問題ない。

>>> 1+2  +    3

6

 

もっと省エネな書き方として、計算したい演算子と　=　を並べるだけという方法がある。

>>> x = 0

>>> x = x + 2

>>> x

2

>>> x = 0

>>> x += 2

>>> x

2

 

この表現方法は、どんな演算子にも利用可能。

>>> y = 10

>>> y -= 5

>>> y

5

>>> a = 10

>>> a //= 2

>>> a

5

>>> a %= 2

>>> a

1

 

ただし、演算子と　=　に空白を設けるとエラーになるので注意。

>>> x + = 3

  File "<stdin>", line 1

    x + = 3

        ^

SyntaxError: invalid syntax

 

 

 

 

変数

変数の宣言は = を使う。

型は自動的に判断される。

>>> num = 10

>>> num

10

>>> type(num)

<class 'int'>

>>>

>>> var = "hello"

>>> type(var)

<class 'str'>

>>> var

'hello'

 

 

また、変数は上書きされる。

>>> num

10

>>> num = 20

>>> num

20

 

 

宣言していない変数を呼ぶと当然ながらエラーになる。

>>> bum

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

NameError: name 'bum' is not defined

 

数値から始まる変数や、Pythonで予約されている言語を利用した変数は宣言できない。

>>> x1 = 1

>>> x_1 = 2

>>> 1x = 2

  File "<stdin>", line 1

    1x = 2

     ^

SyntaxError: invalid syntax

>>>

>>> break = 3

  File "<stdin>", line 1

    break = 3

          ^

SyntaxError: invalid syntax

>>> 

>>> bread = 3

>>> bread

3

breakは予約語だからエラーになるが、breadは予約されていないので問題なく宣言できる。

 

 

まとめ

　数値　

・演算子は下記

　+, -, *, / ：四則演算

　//：割り算(切り捨て)

　%：剰余(割り算の余り)

　**：指数

 

・数字の前に0を置くとエラーになる。

・数式中のスペースは必須ではない。空白がなくても、いくらあっても問題ない。

・算術演算子の効率的な書き方

　>>> x += 2

　>>> y -= 5

　>>> a //= 2

　>>> a %= 2

・divmod(x,y)で、x÷y の商と余りを同時に求められる。

 

　変数　

・変数の宣言は　=　を使う。

・型は自動的に判断される。

・変数は２回同じものを宣言すると上書きされる。

・宣言していない変数を呼ぶとエラーになる。

・数値から始まる変数や、Pythonで予約されている言語を利用した変数は宣言できない。

Evernoteを活用する！Evernoteに書いたことをほったらかしにせずにうまく使えないか考えてみた

日々、人から聞いた話や、本で読んだ内容、自分で経験したこと考えたことなどをメモとしてEvernoteに書いていた

 

ただ書いたあと、そのまま放置していたり、少し編集しても結局書き切らなかったりしているものが大半。。。

 

最初はただ単なる分類分けしたノートブックを作成し、そこにノートをガンガン突っ込んでいただけだったが、だんだん煩雑になってきてしまった

 

ということで、Evernoteのノートの使い方・まとめ方を考えた

 

 

 

書いてある内容によって２種類にノートブックを分類

 

メモをどんどん書いて貯めていくノートブック群(ここに書くノートを貯めメモと呼ぶことにする)

と

貯めメモをきれいに編集して残しておくノートブック群(ここに書くノートをまとめノートと呼ぶことにする)

を用意した

(もっとしっくりくる呼び方はないものか…)

 

こうすることで何のノートがメモレベルで、何のノートがきちんとまとめたノートなのかがはっきりする

 

 

貯めメモ　ー　メモをどんどん書いて貯めていくノートブック群

 

貯めメモを保存するノートブックは、過去と未来で分けた２つにする

 

まずとりあえず、当日やったこと中で「これは残しておきたい」と思うことを やったことノートブック にどんどんノートを作成して書いていく（過去）

 

またこれからやる予定ノートブック を作成して、

　これからやりたいと思うことを Wantノートに

　やらなければならないことを ToDoノートに

書き残しておく（未来）

そして書いたことを実際にやってみたら、 やったことノートブック にノートを作成する

その内容はWantノートやToDoノートからは削除する

（どんどん削除していかないと見た目が煩雑になってモチベーションが下がるかもなので！）

 

 

まとめノート　ー　貯めメモをきれいに編集して残しておくノートブック群

 

まとめノートを保存するノートブックは、カテゴリごとに作成する

 

宇宙のことなら 宇宙 のノートブックに、IT関連のことなら IT のノートブックに、日々の生活に関するものなら 日々の生活 のノートブックに、といった具合に

(ノートブックのタイトルはそのまんまが一番わかりやすいかな…)

 

使い方としては、貯めメモを毎週末など定期的に確認し、言葉や内容を整えて、それぞれカテゴリに合ったノートブックにノートを保存する

 

まとめノートに書き残した貯めメモは、どんどん削除していく

 

 

また、著作権等が問題なさそうなまとめノートは、読みやすく改良してブログにアップしてみる

 

文章力を鍛えられるし、アクセスがあればモチベーションも上がるかもしれない

 

 

 

このやり方でやりづらい部分があったら、改良を加えていく

 

あとは、いくら書いても後々に読み返さなかったら意味がないので、定期的に読み返す仕組みを作らないといけない…

 

そういうアイデアをググって実践してみようかな

早速、貯めメモにこれからやることとして書き残しておいた！

仕事の取り組み方には２種類ある： 「まずやってみる」か「じっくり計画してから」か

私事ながら４月１日で社会人５年目に突入しました。

４年間仕事をしてきて、改めてどういうやり方で仕事をしてきたかを振り返ると、

仕事の取り組み方には２種類あることを実感しました。

そしてこの選択を間違えると痛い目をみることも、実際に経験して身に沁みました。。

今日は、その２種類の仕事の取り組み方とその選び方について、ご紹介したいと思います。

どういう取り組み方があるか

２種類、とはずばり

　「まずやってみる」方法

と

　「じっくり計画して実行する」方法

です。

「まずやってみる」方法は、その名の通り、何か仕事を任された時にすぐに手を動かします。

仕事をすぐに実行するので、場合によってはすぐに結果がでます。

しかし、場合によっては何度も動いて、振り返り、やり直すことになる可能性もあります。

一方で「じっくり計画して実行する」方法は、事前に情報を集めて正確な予測をし、きちんと計画を立ててから仕事を開始します。

準備を整えてから実タスクに入るので、やり直す可能性は低くなります。

しかし、事前の予測には経験からくる直感やある程度の時間が必要になる上に、予測が外れてやり直すことになった場合は、その分余計に時間がかかります。

この２種類は仕事だけではなく、勉強や習い事にも言えることなので、多くの人が分かりきっていることかもしれません。

しかし、この使い分けが意外とできないのです。

仕事の性質を考えず、なんとなく感覚で、「とりあえずやってみるか」といきなり手を動かしたり、「まずは事前調査して、計画して、、、」と念入りに準備したりしてしまいます。

しかし、よく考えもせずに突き進むと、方法を間違えた時に、「じっくり計画を立てて進めなかったから抜け漏れが生じた。。」とか「もっと早く始めておけばよかった。。」といった事態が生じてしまいます。

こういった事態に陥らないためにも、事前に仕事の性質を見極めて、取り組み方を選択する必要があります。

どっちを選ぶか

さて、ではどちらの取り組み方が、どんな仕事に合っているか、について解説していきます。

まずは、「まずやってみる」方法を取るとうまくいく仕事の性質です。

　・やり方はなんとなく分かるが、結果がどうなるかがわからない。

　・長期的な予測ができない、ゴールのイメージがわかない。

　・いつまでに終わるか分からない。

こういった場合は、「どうなるかよく分からんから、とりあえずやってみるか」という気持ちで、PDCAを回していきましょう。（この場合はP:Planがないですが、、、DCAですかね？）

　やってみる(Do)→結果を確認する(Check)→やり方を変えてみる(Action)→やってみる(Do)→…

２つ目の「じっくり計画して実行する」方法に合う仕事の性質は次のようになります。

　・今までの経験から直感が働く

　・予測は正確であるが、何度もやるのは骨が折れる

　・ゴールが明確である

こういった場合は、まさにPDCAのPlanをじっくり練ってからDCAに移りましょう。

ゴールは明確なんだけど、予測が立てづらいし直感も働かない、という場合は、有識者に相談するなど準備に時間をかけるといった対応ができます。

若く経験が少ないうちは「まずやってみる」手法で、それなりに仕事を経験し体力が減ってきたら「じっくり計画して実行する」方法もありだと思います。

また、よく知らない分野ならば「まずやってみる」手法で、よく知っている分野ならば「じっくり計画して実行する」方法というやり方もできますね。

どちらもメリット・デメリットが存在するので、そこを理解していたら自ずと正しい方法を取ることができるかもしれません。

まとめ

まとめると、

・何度もやり直す体力がある、もしくは何度もやり直せる性質の仕事である
・長期的な予測ができない、ゴールのイメージが曖昧
・経験が少ない分野
・よく知らない分野

上記に当てはまる仕事をする時は、「まずやってみる」。

・体力がない、もしくは何度もやり直せることができない性質の仕事のである
・長期的な予測がつく、ゴールのイメージが湧く
・何度も経験した分野
・精通している分野

上記に当てはまる仕事をする時は、「じっくり計画して実行する」。

自分のやりたいことをやる

ただやりたいことをやる。

それが他の人と比べて劣るとか優れるとか関係ない。

自分がやったってどうせレベルが低いから

やったところで何にもならないから

とか言い訳して、いつまでも「やりたいな〜」と言って、やらない状態を続けても、それこそ何にもならない。

何にもやってない。

周りのことや、先のことは考えずに

ただやりたいことをやる。

気の赴くままに

と思って最近、絵を描くようになった。

ただひたすら描いてるだけだから楽しい。

小学校のころ、ノートに落書きをしていた時と同じ感覚。