マックとMacどっちを指しているか混乱するのは『まっく』って何?しかないんじゃないか説

関西ではマクドナルドのことを『マクド』というらしいです。なぜならパソコンの『Mac』とどっちのことを指しているのかわからないから…。果たしてそうでしょうか?

自分は関西人ではないのでマクドナルドのことは『マック』と略しますが私生活で『Mac』とどちらのことを指しているのかわからなくなったことはありません。一方はファーストフードの店名で一方はパソコンの名称。う~む。普段よく聞く使用方法から考えてみましょう。

『マック』の常用法


マック食べたい。

マック行きたい。

マックのポテトが美味しい。

マックは身体に悪い。

期間限定のマック○○食べなきゃ!

 

『Mac』の常用法


Mac使いやすい!

Mac調子悪い。

「パソコン何使ってるの?」「Macだよ」

Macとスマホを繋ぐ。

Macってどう?(一瞬どっち?かも?)

 

『まっく』って何?しかないんじゃないか説


考えた結果、『まっく』って何?という質問くらいしか思いつきませんでした。というか小さい子供でも言わなそうな質問ですね。

いずれにせよ、結局マックについて説明するのね…。

スポンサーリンク

中途の未経験入社は3年くらいで転職するといいかもという話

新人とか未経験で入社した場合、大抵は給料が低いと思います。

中途の場合年齢も考慮されるかもしれないが、同い年の人と比べても低い場合がほとんどではないでしょうか?

これはある意味仕方がないことで、やはり経験者の方が仕事が出来る分会社に貢献しその分給料を貰えるのは当たり前でしょう。私も販売員から未経験でプログラマーに転職したときは給料はそれほど高くなかったです。

スポンサーリンク


 

技術職なら転職すると給料が上がる?


そんなこんなで3年程経ってから転職をしたわけですが、結論から言うと100万円くらい上がりました。そんなに上がるとは思っていなかったですが資格を取得していたのと、開発経験がきちんとあったことが評価されたようです。

プログラマー職は売り手市場と言われているので前の会社以下の給料になることはほとんどないようです(少なくても自分の周りでは)。技術者が増えれば働く社員も増えるので客先常駐の会社は儲かります。ということで結構いい条件で雇用してくれたりするのですね。もちろんきちんと技術をつけていればの話ですが…。

自分の場合は職場にも恵まれた


転職先で常駐している会社はとても勉強になります。複数プロジェクトを持っているリーダーがいてその下で自分がひとりでひとつのプロジェクトの開発をしています。それが2カ月くらいの単位で色々な案件が繰り返され、いずれもいちからの開発です。ひとりで開発するとフレームワークの選定からどういうライブラリを使うとか考えるので勉強になるのでこの半年ほどで開発スキルがとても上がったように思います。居心地のいい現場にいけたのは偶然だと思いますが、転職してよかったと思います。

 

終わりに


今回は自分を例にいいことばかりを書いてしまいましたが、今の会社にマンネリを感じたら転職を考えてみるのはいかがでしょうか?普通転職というとマイナスイメージが強いかもしれませんが、プログラマーに限っていえば手に職を持っているので待遇面が改善される大きなチャンスのように思います。

スポンサーリンク

期日とパフォーマンスのバランスは大切

先日こんなことがありました。

東京側から指示を受けて地方で開発をするという状況。開発で使用するライブラリなどは自分が先行して調べていたので一番詳しい。わかりやすくするためにこのライブラリをグラフを作成するものとします。

ある日の午後、東京側のリーダーからグラフのサンプルイメージがきて、こういうグラフが今のライブラリでどこまで再現できるか実際にサンプルを送って欲しいと言われました。早速サンプルを作って簡単なサンプルを提出し、その後にできることとできないことを資料にまとめていました。

翌日、お昼前にメンバーから13時からグラフについて会議があるから口頭でいいので可能不可能を教えて欲しいと言われました。会議があることも知らず、東京側のリーダーが休みだったのでてっきりまだ作業を続けていいと思っていましたがどうやらお昼くらいには欲しかったようです。

前日にサンプルを送っているので他は口頭で伝えて事なきを得ましたが、今思うと期日をお互いにしっかりと連携していればよかったです。結局資料をまとめても意味がなくなってしまったので違う作業をすることにしました。

 

期日内で最大のパフォーマンスを


何がいいたいかというと、期日を確認してその期間内で求められているものを見極める必要があるということです。

資料まとめなんかはしっかりやろうと思えば結構こだわれてしまうので、お願いされた時にこうしようというのが大体見えてくると思います。次にその見えてきたものが期日内で終わるのか計算し、求められているものとのバランスを考えて作業をするというのがベストです。当たり前のようなことですが、今回は出来ていなかったです…。

今回でいうとサンプルと出来ること出来ないことの羅列でよかったのが、わざわざサンプルをいつくも作って注釈をつけたりパラメータを列挙して作っていたので、期日内には終わりません。結局無駄な作業が発生してしまいました。

特に連絡をとる人が遠くにいる場合はしっかりとした連携が必要ですね。

スポンサーリンク