たもろぐ

組み込みエンジニアが、エンジニアのキャリアやサイドプロジェクトについて考えるブログです。

好きを仕事にできれば幸せになれるのか問題

キャリア

こんにちは、たもです。

 

現役のソフトウェア開発者に限らず、最適な仕事選びは、多くの人の悩みのタネになったりするわけでございまして。

今回は、「好きを仕事に」の是非について語っていきます。

 

 

１．好きを仕事にできたら幸せなの？

結論から言うと、好きを仕事にしたら特別幸せというわけでもないようです。

2015年にミシガン州立大学が行った研究で、被験者を２グループに分け、どちらが職業上の幸福と成功を手に入れられるかを調べました。*1 

２つのグループとは、以下の通りです。

◉ 適合派：「 好き な こと を 仕事 に する のが 幸せ だ」 と 考える タイプ。「 給料 が 安く ても 満足 できる 仕事 を し たい」 と 答える 傾向 が 強い

◉ 成長派：「 仕事 は 続ける うち に 好き に なる もの だ」 と 考える タイプ。「 そんなに 仕事 は 楽しく なく ても いい けど 給料 は 欲しい」 と 答える 傾向 が 強い

 

出典：鈴木祐. 科学的な適職 (Kindle の位置No.348-350). 株式会社クロスメディア・パブリッシング. Kindle 版.

 

適合派の方が幸せなような気はしますが、実際は違うようです。

ところが、 結果 は 意外 な もの でし た。 適合 派 の 幸福 度 が 高い のは 最初 だけで、 １ ～ ５ 年 の 長い スパン で 見 た 場合、 両者 の 幸福 度・年収・キャリア などの レベル は 成長 派 の ほう が 高かっ た から です。

 

鈴木祐. 科学的な適職 (Kindle の位置No.352-353). 株式会社クロスメディア・パブリッシング. Kindle 版.

 

適合派の人は仕事に期待をしてしまう分、理想と現実のギャップに苦しむ傾向があるのでしょう。

例えば、データサイエンスをやりたくて企業に入ったが、データをいじる以外に、顧客との納期交渉や関係部署との調整、他社の特許調査、各種資料作成など、好きなこと以外に時間を取られ、「予想と違った・・・」と居酒屋でぼやく、といった話はよく聞きます。

したがって、変に「好きを仕事にしなければ・・・」と思うより、現職で目の前の課題をクリアする努力を重ねることも、キャリアの幸福の観点からは悪くない選択と言えます。

 

２．どうしても好きを仕事にしたい場合にまずやるべきこと

「それでも自分は夢をかなえるんだ！好きを仕事にするんだ！」という大志を抱く人はどうすべきか。

リスクを恐れないのであれば、そのまま就職なり転職、独立などして突き進むのもまた人生。実際にチャレンジしてみないと分からない部分はあると思います。

一方、思い切ってリスクを取れないという人は、以下のいずれかの手段を取るのをおすすめします。

  • 副業する
  • 今の仕事に「好き」成分をねじこむ

 

大事なのは理想と現実のギャップをいかに小さくできるかです。

例えば、週末だけバイトさせてもらうとか、自分でアプリやサービスを開発・運営してみるとか。やってみる中で、「こういった法的知識が必要なんだな」とか、「この設計思想、資料にまとめておかないと忘れるな」など気づきが得られ、望みの仕事に対する現実的な予測ができるようになり、理想と現実のギャップに苦しむリスクを軽減できます。

予測力が高まり、それでもその仕事をやりたいと思った段階で、転職や独立をするのも良いかなと思います。何もしないときに比べ、きっと自信をもてるはず。

 

まとめ

キャリア上の幸福は、人間関係や裁量権など、色んな要素が絡み合ってますが、少なくとも「好きを仕事に」という要素はあまり意識しなくてよさそうです。 

今後のキャリア選びの参考になれば。 

 

個人的な話ですが、私は新卒以来、産業機器の組み込みエンジニアとして１つの会社に５年ほど勤めていますが、別の分野に興味が出て、転職すべきかどうか悩んだ時期もあります。

が、上記の知識により「好きを仕事に」だけを理由とした転職は微妙かなと思い、踏みとどまりました。気になった分野は趣味としては続けてますが、今は転職しようとは思ってません。転職に悩まなくなったことで、時間も大幅に節約できたなあと感じます。

転職を迷ってる人にとって、本記事が意思決定の役に立てばいいなあと思います。

 

それでは。

 

参考文献

科学的な適職 4021の研究データが導き出す [ 鈴木祐 ]

科学的な適職 4021の研究データが導き出す [ 鈴木祐 ]

*1:https://journals.sagepub.com/doi/abs/10.1177/0146167215596988

デバッグ（など問題解決）で時間を浪費するクセを直す方法３選

効率化

こんにちは。たもです。

一般に、ソフトウェアエンジニアはデバッグをする機会が多く、 他人や自分の書いたコードが生み出すバグに日夜苦しんでいるかと思います。納期ギリギリのデバッグだと、もう発狂もの。
デバッグに限らず、あらゆる問題解決についても、同じような悩みはつきものです。

逆に言えば、デバッグにかける時間を節約できると、生産性が向上して自由な時間が増えるわけです。
（定時でさっさと帰って、ゲーム勉強とかしたいじゃん）

というわけで、今回はソフトのデバッグ効率化に使えるテクニックを紹介します。


1. なぜデバッグしてると時間だけが過ぎ去ってしまうのか

まずデバッグしてると時間ばかり過ぎてしまう原因ですが、以下のようなものがあります。

  • 疲れによる集中力の低下
  • 目的喪失

集中力が落ちれば、生産性が下がるのは当たり前ですね。
人間の集中力がどれだけ持つのかは諸説ありますが、30～50分くらいではないでしょうか。
その根拠として、トロント大学が17621人の学生を対象に行った実験で、被験者に記憶力テストをやってもらったところ、テスト開始～30分ではパフォーマンスが上昇し、30分経過後には落ち始めるそうです。さらに、テスト開始から50分経過すると、テスト開始直後のパフォーマンスを下回るといった結果が出ています。1

「目的喪失」は、自分が何やろうとしているかを見失ってる状態です。
たとえば登山において、山頂がどの方角にあるかわかってない状況で、森の中をむやみに歩き回るのが非効率なのは、言うまでもないことです。
「とりあえずデバッガを起動して内部の挙動を見て、対策を決めっかなー」とか思ってると陥りやすいワナですね。


2. 時間浪費グセを直す方法3選


2.1 ポモドーロ・テクニック

集中力低下対策として、ポモドーロ・テクニックをオススメします。 ポモドーロ・テクニックは、イタリア出身のソフトウェア・エンジニア、フランチェスコ・シリロ氏によって編み出された手法で、 「25分作業してから5分休憩する」のサイクルを最大4回実施してタスクをこなす時間術です。2

関連書や活用事例はググるとたくさん出てくるので、一定の効果はあるようです。3,4,5

ちなみに私は、スマホの標準タイマ―機能を使い、PCの横に置いて実践してます。 25+5分だと物足りなく感じるので、50+10分にタイマーセットしてやっています。 １サイクル毎（50分）にやることの目標を立てることで、集中力が保ちやすくなります。


2.2 バルーン・ブリージング

集中力回復にオススメなのが、バルーン・ブリージングです。 これはスタンフォード大学医学部のブログで紹介された深呼吸の方法です。6 集中力を回復するには、ストレスによる疲れを軽減する必要がありますが、 そこで定番のストレス対策である深呼吸を使おうというわけです。
ストレスによる疲れは、自律神経の乱れによるものが多いですが、7 呼吸は人間の自律神経に直接介入でき、その乱れを整えることができる数少ない手段です。8 普段、人間が意識せずとも呼吸ができているのは、自律神経のおかげです。 逆に呼吸を意識的にしてやれば、自律神経を操れるというわけですな。

バルーン・ブリージングのやり方は以下の通りです。

  1. 床やいすに座り、背筋を伸ばします。
  2. お腹に風船が入っているところをイメージします。
  3. 胸を少し開きながら、鼻から息を大きく吸い、風船が膨らむところをイメージします。
  4. 背中を少し丸めつつ、鼻から息を吐き切り、風船がしぼむところをイメージします。

以上のサイクルを繰り返します。5分もやると、リラックス効果が実感できます。 ちなみに前述のポモドーロ・テクニックの休憩時間に組み込むと、捗ります。


2.3 ソクラテス式問答法（ソロver.）

「目的喪失」を防ぐ手段として、ソクラテス式問答法を使ってみることをオススメします。

wikipediaでは、ソクラテス式問答法を以下のように定義しています。簡単に言えば、質問と回答を繰り返して、新しいアイデアや解釈を出す手法です。

問答法（もんどうほう、希: διαλεκτική, dialektike, ディアレクティケー; 英: dialectic）とは、古代ギリシアの哲学者ソクラテスが用いた、対話によって相手の矛盾・無知を自覚させつつ、より高次の認識、真理へと導いていく手法を指す。 出展：wikipedia

ソクラテス式問答法自体は、現代でも多くの記事やブログで紹介されるほど人気の手法です。 （クリティカルシンキングと言われることもあります。）

さて、本来は自分と他人とで問答するソクラテス式問答法ですが、これを以下の手順で行います。

  1. 自分の中に、質問する自分（A）と、それに答える自分（B）を想像する。
  2. Aが質問を投げる。
  3. Bが質問に回答する。
  4. 2~3を繰り返す。

上記手順を、紙に書いたり、独り言をしながら実践すると、 目的を見失いにくくなり、また詰まったときの打開策を打ち出しやすくなります。

個人的な経験として、1回のデバッグで１～２時間くらい手詰まりで悶々としていた時間が、 この手法を使うことでめっきりなくなったなーと感じています。


まとめ

今回、デバッグの効率化として３つの方法を紹介しました。 できそうなものから試してみてくださいませ。 しんどいデバッグが少しでもラクになれば幸いです。

よいデバッグライフを。

  1. https://www.ncbi.nlm.nih.gov/pubmed/28931013↩

  2. https://www.newsweekjapan.jp/stories/carrier/2019/03/post-11867.php↩

  3. https://gigazine.net/news/20171220-pomodoro-2-year-ractice/↩

  4. http://lalanoito.com/handstando-workshop-vl-2-i-tryied-pomodoro-and-then#i-3↩

  5. https://note.com/supisupi/n/n3ce3e5500c03↩

  6. https://mindful.stanford.edu/2015/03/balloon/↩

  7. https://www.nhk.or.jp/lifestyle/article/detail/00624.html↩

  8. https://www.daiwa-pharm.com/info/onko/426/↩

腕に自信が持てないソフトウェアエンジニアがやったらいいこと

キャリア サイドプロジェクト エンジニア

ambitiこんにちは、たもです。

会社員として働くソフトウェアエンジニアは多いと思いますが、プロジェクトの一部分の仕事しかできず、いまいち自分に自信が持てないこともあるのではないでしょうか。

結論として、エンジニアとして自信をつけるには「サイドプロジェクト」をやってみることをオススメします。


１．サイドプロジェクトとは

みなさんは「サイドプロジェクト」という言葉をご存知でしょうか。「サイド」でやる「プロジェクト」ということで、簡単に言えば個人の課外活動ですね。

ちゃんとした定義は人によってまちまちでしょうが、ここでは以下の条件をもったものをサイドプロジェクトと呼びましょう。

  1. 自分で設定した明確な目標がある（≒ 成功 or 失敗がある）
  2. 自分が好きな方法、好きなペースでやれる

趣味ほど無目的、無目標ではなく、また仕事や副業のように納期やルール、縛りがないのがサイドプロジェクトです。

 

２．サイドプロジェクトをやるメリット

サイドプロジェクトをやることで得られるメリットは以下の３つです。

  • （成功すれば）成功体験を積むことができ、自信がつく
  • プロジェクトを進める過程でスキルが向上する
  • やりようによっては収益化できる

例えば、iPhoneアプリを作ってApp Storeに出す場合、リリースまでの過程でアプリ開発やテスト、宣伝の仕方などを知る必要があり、この辺のスキルは自然と向上します。また一度リリースまでいけば、出来に応じて収入も得られ、それは自信へとつながります。

名著「SOFT SKILLS ソフトウェア開発者の人生マニュアル」の著者ジョン・メンソズ氏は、サイドプロジェクトのメリットを以下のように語っています。

それで 大きな 収入 が 得 られ た わけ では ない が、 広い 範囲 の スキル を 身 に つける こと が でき、 それ が 私 の キャリア を 大きく 伸ばす ため に 役立っ た。 　 何 よりも 大切 なのは、 プログラマー として の 自分 の 能力 に 自信 が 持てる よう に なっ た こと だ。 私 は アプリケーション を 自作 し、 それ を オンライン で 売る 方法 を 突き止め た。 それら 全部 を 独力 でし た の だ。 　 これ が サイド プロジェクト の 力 で ある。 新しい スキル を 学び、 既存 の スキル を 磨き、 新しい 方法 を 使いこなす という ハードル を 飛び越え、 自分 の 能力 に対する 自信 を 育む。

出典：ジョン・ソンメズ. CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド. 日経BP社. Kindle 版.

 

３．サイドプロジェクトを始めるときの注意点

サイドプロジェクトをやる上で、最初のうちは以下の点に注意してください。

  • 大きな目標を掲げない
  • 何を作るかを考えることに時間を使わない

まず、大きな目標を掲げると挫折します。当たり前ですけど。

そのプロジェクトで失敗するだけでなく、最悪、燃え尽き症候群を起こし、その後もチャレンジしようという意欲が削がれるリスクがあります。

自分がちょっと頑張れば達成できるレベルにしましょう。最初のうちは2週間とか1ヵ月くらいで、今の自分でもできるようなレベルが望ましいです。

 

次に、何を作るかを考えることに多くの時間を使わないことです。サイドプロジェクトの主たる目的はスキル向上と成功体験の蓄積です。ゆえに、これといったアイデアがない場合は、アイデア出しには時間をかけず、すでにあるサービスの類似品を作ることから始めましょう。サービスの流れやデザインがある程度わかっているので、開発に専念しやすいです。（類似品を公開したり収益化することの是非については、ここでは触れません。大事なのは開発すること。）

 

まとめ

個人がマイペースにできるサイドプロジェクトは、手軽にスキルと自信をつけるのにオススメです。もちろん、やる/やらないは個人の自由ですが、自信がなくてもやもやしてる人は試してみるといいかもしれません。

 

ちなみに、私は本業で組み込みエンジニアをやっていますが、webアプリ開発をサイドプロジェクトとしてやりました。2か月ほどかかりましたが、プロジェクトは完遂でき、Python Flaskやhtml/css、Github、Herokuといったスキルの向上に役立ちました。本業に役立つかは微妙ですが、やりきったことに自信を感じたのは間違いありません。

作ったもの：https://hachionemap.herokuapp.com/

 Github：https://github.com/tamoshu/HachioneMap

 

それでは。

 

参考文献

    • ジョン・ソンメズ. CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド. 日経BP社