１年前に作った人生設計の振り返り
去年（2020年）に書いた将来設計のブログを見て振り返ります。
読んでみたまず思ったのが、ほとんどの目標が今とは変わっていることです。
びっくりするぐらい今の人生設計と違います。
１年でこんなに考えが変わるのかと考えさせられました。
達成度的には本を読む目標に関しては9割以上達成していますが、それ以外は9割以上未達成です。
転職したいとか言っていますが、今は全く転職する気は無いです。
これには理由がありますが、
知り合いの会社を今の会社に紹介して私自身で担当することになったため、
その会社を良くするのが今のミッションであり数年は掛かりそうな案件なので
転職の考えは無くなっていました。
なので、転職のためにRubyを学んでポートフォリオ作るとか言っていますが、ポートフォリオも今は作る気なし。
Rubyも学ぶ気なし。
Web系企業に行きたいとか言っていますが、全く行きたいと思っていません。
Web系企業に居なくてもスキルは身につくし、むしろ偏ったスキルが身につきそうなので、今はWeb系企業に行きたい気持ちはないです。
10年後とかの将来ではありかもしれないですが、とりま今は転職の気持ちはないです。
副業したいとか言っていますが、副業はしたくない。でもお金は欲しい。
今の考えでは簡単に副業で稼げるとは思っていなくて、本業で収入を増やしたいと考えています。
ワードプレス開設して副収入を得るとか言っていますが、まだワードプレス開設していません。
ワードプレスは開設したいと思っていますが、記事制作に時間が取れそうに無いうちにレンタルサーバー代を払うのが嫌だなぁと思っているため、足踏みしている状況です。
本腰入れて作るとすると時間がかかるため、もうちょっと先になりそうです。
FXで荒稼ぎするとか言っていますが、全く成果が出ていません。
一応、粛々と続けてはいましたが、FXはすごい難しいです。
FX舐めてました。
どうすれば勝てるようになるのか、、、全然上手になりません。
英語をしゃべれるようになりたいと言っていますが、それは今でも思っています。
エンジニアをしている限り英語はついて回ってくるので、英語はいつかは文献を読めるようになってしゃべれるようになりたいと思っています。
ただ、留年したいとか言っていますが、今はそこまでは思っていないです。
日本でもある程度の学習は可能だと思うからです。
フリーランスになりたいとか言っていますが、それも特に考えていません
去年はだいぶ先のことまで考えていたようですが、今は会社を辞める気は無くそこまで先のことは見据えていません。
この先どう転がるか分からないので目の前のことを一生懸命やって行くだけです。
大学に行きたいとか言っていますが、まあ学びたいことがあったら行ってもいいかなくらいです
コンピュータサイエンスは確かに学びたいし、今後AI関連の仕事をすることになったとしたら数学の知識とかついていける気がしないので、大学に入って体型的に学び直すのはありだと思います。
でも、そこまで行きたい欲求は無いです。
MBAに行きたいとか言っていますが、特にその欲望は無い
去年は大分、やりたいことがいっぱいあったようですが、今は欲望が薄れてきているようです。
MBAの資格を持っていれば面白いとは思いますが、他にやることがあるような気もします。
とりあえず、今は特にその予定はなし。
おわりに
去年と比べると今は野心が薄れているのが、わかりました。
野心が薄れた原因はなんのか？
年を取ったからなのか、状況が変わったからなのか、思いつく原因としてはおそらく、
去年は転職したりFX始めたりブログ始めたりと精神的に興奮していたので野心が大きかったのではないかと思います。
いわゆる、コンフォートゾーンを抜け出した状況だったのでしょう。
今は転職して１年経ちコンフォートゾーンに入っているので野心が薄れたのだと思います。
また、何か新しいことを始めてコンフォートゾーンを抜け出そうと思います。
＜復習＞Java言語で学ぶデザインパターン入門
Java言語の文法を一通り勉強し、次に読む本としてデザインパターンのおすすめ書籍を調べたら真っ先に本書が上がってきました。
正直に言って、Javaの文法を一通り勉強した程度の実力では、半分くらいしか理解できませんでした。
読むのもとても大変で章末問題を飛ばしても読み終わるのに30時間ほど掛かりました。
なんとか最後まで読み切りましたが、もう少し経験を増やしてから再度読み直して理解できなかった部分を理解したいと思っています。（多分読まないけど）
読者のレベルもある程度は必要で、コードの解説がメインの話なのでコードを理解する能力は必要です。
コード自体はそこまで難しくないので時間を掛ければ理解できます。
ただ、コードを読んだだけで終わりになってしまった感はあります。
私もまだピンと来ていないので、実際に業務で使って理解を深めていくしかないと思っています。
とりあえず、本書を読んでざっくりの理解です。
具体的にどこが理解できていなかったと言うと、そのパターンがなんのために利用されるのか、そのパターンにはなんの意味があるのか、の部分が理解できませんでした。
なんとなくは分かるのですが、実務に落とし込んで考えることができなかったです。
なので、実際に業務でぶち当たることしかないなぁと言った感じです。
雰囲気はつかめたし、業務上のコードや他の本を読んでいてもちょいちょい出てくるワードがあったので読んでおいて良かったとは思っています。
ただ、内容が難しく手をつけるのは少し早かっただけです。
Java言語で学ぶデザインパターン入門
そもそもデザインパターンとはなんでしょうか。
本書では「部品がどのように組み立てられているか、個々の部品がどのように関連して大きな機能を果たすのかを表現したもの」と言われています。
the Gyang of Four
本書はthe Gyang of Four、または GoF と呼ばれている２３種類のデザインパターンを一つ一つ取り上げてわかりやすく説明してくれます。
第１章 Iterator パターン
複数の要素が集まっている中から要素を一つ一つ取り出していくパターンです。
第２章 Adapter パターン
異なるインタフェース(API)を持つクラスの間をつなげるパターンです。
第３章 Template Method パターン
スーパークラスで処理の骨組みを定め、具体的な処理をサブクラスで行うパターンです。
第４章 Factory Method パターン
スーパークラスでインスタンスの作り方の骨組みを定め、具体的な作成そのものはサブクラスで行うパターンです。
第５章 Singleton パターン
インスタンスが一つしか存在しないパターンです。
第６章 Prototype パターン
ひな型となるインスタンスをコピーしてインスタンスを作るパターンです。
第７章 Builder パターン
複雑な物を段階を踏んで組み立てていくパターンです。
第８章 Abstract Factory パターン
工場のように部品を組み合わせてインスタンス生成を行うパターンです。
第９章 Bridge パターン
２種類の拡張が混在するプログラムを機能の階層と実装の階層にわけ、その間に橋渡しを行うパターンです。
第１０章 Strategy パターン
アルゴリズムをごっそり切り替えて改良しやすいようにするパターンです。
第１１章 Composite パターン
容器と中身を同一視して、再帰的な構造を構築するパターンです。
第１２章 Decorator パターン
飾り枠と中身を同一視して、飾り枠を何重にも重ねるパターンです。
第１３章 Visitor パターン
構造を渡り歩きながら同じ操作を繰り返し適用するパターンです。
第１４章 Chain of Responsibility パターン
複数の物が連なっている中の、どこかで仕事を行うと言うパターンです。
第１５章 Facade パターン
複雑に絡んだクラスを個別に制御するのではなく、窓口役のクラスを一つ配置することでシステム全体の操作性をよくするパターンです。
第１６章 Mediator パターン
複数のクラスが互いに相談し合うのではなく、相談役のクラスを一つ用意し、その相談役とだけやり取りすることでプログラムをシンプルにするパターンです。
第１７章 Observer パターン
状態が変化するクラスとその変化を通知してもらうクラスを分けて考えるパターンです、
第１８章 Memento パターン
現在の状態を保存し、必要に応じて復帰させ、アンドゥを行えるようにするパターンです。
第１９章 State パターン
状態をクラスで表現し、状態に応じたswicth文を減らすパターンです。
第２０章 Flyweght パターン
複数箇所で同じ物が登場するときに、それらを共有して無駄をなくすパターンです。
第２１章 Proxy パターン
本当に目的の物が必要になるまでは代理人を使って処理を進めるパターンです。
第２２章 Command パターン
要求や命令を形にしてクラスで表現するパターンです。
第２３章 Interpreter パターン
文法規則をクラスで表現するパターンです。
GoFのデザインパターンの分類
生成に関するパターン
- Abstract Factory パターン
- Builder パターン
- Factory Method パターン
- Prototype パターン
- Singlten パターン
構造に関するパターン
- Adapter パターン
- Bridge パターン
- Composite パターン
- Decorator パターン
- Facade パターン
- Flyweght パターン
- Proxy パターン
振る舞いに関するパターン
- Chain of Responsibility パターン
- Command パターン
- Interpreter パターン
- Iterator パターン
- Mediator パターン
- Memento パターン
- Observer パターン
- State パターン
- Starategy パターン
- Template Method パターン
- Visitor パターン
おわり。
現場で使えるデバッグ&トラブルシュート Java編
現場で使えるデバッグ&トラブルシュート システム障害を乗り越えるための解析テクニック Java編
読んだ感想としては、
プログラマより運用管理者とかインフラエンジニア向けな内容でした。
しかし、汎用的で広範囲に渡る内容なので関係者であれば何かしら糧にはなりそうではあります。
発行は少し古くて2010年です。
Java編と謳っていますが、そこまでJavaの話は出てこないないです。
前提知識としてJavaを少しは使ったことがある読者を想定していますが、Javaの文法をそこまで覚えていなくても問題はなさそうです。
Javaのソースコードは第６章の一部（JUnitの部分）でしか出てきません。
Javaのエラー画面やソースコード以外の画面はよく出てくるので、ある程度システム開発の慣れは持っていないとついて行けないかもしれませんが。
第１章 概要
導入の章
- 故障が起こる原因
- デバッグとトラブルシュートの概念
- 基本的な流れ
- 情報収集 問題把握 原因分析 対処
などです。
第２章 基礎知識 ／ 第３章 環境の構築
各種ツール、基本的な知識、インストールです。
第４章 要件定義／設計
要件定義や設計の段階で障害を想定するのがどれだけ大事かと言ったお話と実際にどのように設計するのか説明があります。
第５章 バージョン管理
SVNの使い方です。
バージョン管理もデバッグの一部だと言うことと思いますが、単純にバージョン管理の使い方が続くので知っている方は飛ばしても問題なさそうです。
第６章 デバッグ
この本ではデバッグをソフトウェアのエラーを修正することを意味しています。
情報収集、原因分析、修正の実施の３段階で話が進みます。
デバッグツールの使い方を学べます。
第７章 トラブルシュートの全体像
この本ではトラブルシュートを、システム提供後に起きたエラー／トラブルを解決することを意味しています。
トラブルシュートの説明はこの章から９章までの３章しかありませんが、多くのページ数が割かれているので、ここからがこの本のメインとなるでしょう。
第８章 トラブルシュート〜問題把握〜
ハードウェアやミドルウェアを解析する上で必要な情報の説明が多いです。
第９章 トラブルシュート〜原因分析〜
ハードウェアやミドルウェアを解析するためのCPUやメモリなどの動作状況のログの見方です。
巻末 情報収集／集計で使えるツール
各種ツールの説明があります。
感想
正直、デバッグまでの道のりが長いので、第６章まで読み飛ばしても問題ないかと思います。
ピンポイントにデバッグとトラブルシュートを教えてくれる本ではなく、広範囲に渡って教えてくれる本なので、自分にとってはすでに知っていたために不必要な項目が多かったです。
JavaエンジニアのためのEclipseパーフェクトガイド
Eclipseの歴史から各種ツールの使い方を学べるEclipseのガイドブックになります。
各種ツールのインストールを行うところから、各種ツールの使い方を体系的に学ぶことができます。
Eclipseのテクニック集のような本ではないです。
第１章 Eclipseとは
統合開発環境について、Eclipseの歴史、Eclipseの開発工程、Eclipseの特徴などが学べます。
- 統合開発環境 エディター、デバッガー、コンパイラーなど様々なツールがまとまっている一つのアプリケーション
- Eclipse Foundation 現在のEclipseの運営団体
- Eclipseマーケットプレイス 有償、無償含む様々なプラグインをインストールできる
第２章 Eclipseをはじめよう
Eclipseのインストール、起動と終了、ディレクトリーなど基礎知識を学べます。
- Pleiades All in One Eclipseと日本語化プラグイン一つになったパッケージ
- configuration プラグインやワークスペースの設定が保存されている
- dropins プラグインやフィーチャーを手動で組み込む際に使用
- plugins プラグインの格納先
- readme 使用方法や注意事項が保存されている
- eclipse.exe-clean.cmd 古い情報ファイルを削除するコマンドファイル
- eclipse.ini Eclipseのパフォーマンスを改善する際に編集する
- ワークベンチ Eclipse全体のウィンドウのこと
- パースペクティブ 使いやすいようにウィンドウ環境が構築されているレイアウト
第３章 Eclipseの基本機能を理解する
パースペクティブの使い方、プロジェクトの設定などを学べます。だいたい見れば分かりそうな部分の説明ばかりです。
第４章 Eclipseを使った開発の流れ
プログラミング、デバッグ、コンパイルをする際のEclipseの利用方法を学びます。ここ の章も、ただの使い方の説明で面白くはないです。
第５章 Javaエディターの基本操作
コードアシスト機能、テンプレート機能、ソースコード編集方法などを学びます。はじめてeclipseを触る方は、こんな機能があるのかと思うかもしれません。
第６章 Eclipseのリファクタリング手法
Eclipseで便利に使えるリファクタリングの方法を学びます。
第７章 JUnitによるテスティング
JUnitを実際に利用してEclipseを通してJUnitの使い方を学びます。
第８章 Gradleによるビルド方法
ビルドツールであるGradleの実行方法を学びます。
第９章 Eclipseによるチーム開発方法
SVNやGitでのチームによる開発方法を学びます。
終わり。
Amazonのクチコミばかり見ていたら読んだ本は入門書だらけ
エンジニアとして成長するべく本を読んでいます。
たくさん読んでいます。
ですが、ふと思い返したら入門書ばかり読んでいて中途半端なエンジニアになっていました。
なぜだろうと考えていたらあることに気付きました。
Amazonのクチコミは入門向けの本の方が玄人向けの本より評価が高く数も多いことです。
私はAmazonの口コミが大好きで、本を買う際は必ずAmazonの口コミを見て判断します。
実際、Amazonの口コミは私の経験上とても信頼できています。
Amazonの口コミを見て高評価の商品を買ったらほとんど外れませんし、本を買ったらだいたい面白いです。
たまに聞いたことの無いブランドの超高評価の商品などで怪しい口コミもありますが、その辺は長年の感で回避できていると思います。
しかし、玄人向けやマニアックな商品は評価がされにくく高評価にもなりにくいところは盲点でした。
今にして思えばですが、口コミの評価が高いのはわかりやすい入門書や初心者向けの本ばかりでした。
難しい本になってくると読む人口が少ないので口コミ自体があまりされません。
そして、難しいので挫折した方は低評価を付けます。
そうすると難しい本は口コミ自体も少ない上に評価も高くなりづらいです。
初心者向けの本の場合は読者数も多いのでその分口コミが多くなります。
初心者向けの本は難しい本と比べて販売数も多いので予算を多く出せます。
そうすると、デザインや編集に多くの労力をかけられるのでとても読みやすくなります。
出版される本の種類も多いので競合も多いので切磋琢磨して平均的なクオリティも上がっていきます。
たまに、思ったよりも簡単だったと言う口コミで評価が低くなることもありますが、それでも高評価の数が多いです。
Amazonの口コミは信頼していますが、初心者本ばかりに目がいってしまい、難しい本に手が伸び辛くなっていました。
正直、Amazonの口コミによる成功体験が多いだけに、高評価なだけで面白そうだし、読んでみたくなるんですよね。
ここまで来たら趣味の領域でもあり、楽しむだけ楽しめば良いとも思いますが、エンジニアとして効率よく技術力を高めていきたいなら、初心者本ばかりではなく難しい本も読んでいく必要がありそうです。
まあ本ばかり読んでいないで手を動かせって話でもありますが。。。
これからはAmazonのクチコミばかり見ずに視点を変えて本を読んで行きたいです。
そもそもそんなに本を読む必要があるのか。
その本を読んで技術力が上がるのか。
その辺りを考えながら、技術書と向き合って行きたいと思います。
７つの習慣〜人格主義の回復〜＜まとめ＞
７つの習慣〜人格主義の回復〜
完訳 7つの習慣 人格主義の回復: Powerful Lessons in Personal Change
- 作者:スティーブン・R・コヴィー
- 発売日: 2014/05/23
- メディア: Kindle版
本のタイトル通り、７つの習慣を作っていく話がメインになっています。
７つの習慣を実践してより良い人格を形成すれば人生が豊かになっていくと言った自己啓発本です。
７つの習慣の一覧
- 主体的に行動をすること
- 終わりを思い描くことから始めること
- 最優先事項を優先すること
- Win-Winを考えること
- 相手の理解に努めたあとに自分を理解してもらうこと
- シナジーを作り出すこと
- 刃を研ぐこと
この７つの言葉でなんとなくイメージできたでしょうか。
ビジネス本の範疇を超えて、全人類に向けて人格形成の大切さを説いている本です。
サブタイトルにも「人格主義の回復」と書いてあります。
一言で言うと、”誠実に生きて、立派な人格になってお仕事を一生懸命頑張れば、人生が豊かになりますよ。”
と、この本は言いたいようです。
成長の連続体
７つの習慣はすべて繋がっています。
最初の習慣で出てくる”主体的に行動する”がすべての土台となっており、最後の章の”刃を研ぐ”は他のすべてができた上で行う習慣です。
無論、すべて完璧にこなせないと意味がないと言うわけではなく、７つの習慣は相互に関係し合っているので成長の度合いに影響してきます。
７つの習慣のすべてが繋がっていることを説明するのが成長の連続体です。
私的成功
他者に依存している間に起こる結果は、他者に委ねられていると言えます。望む結果を自分で成し遂げたいのであれば依存からの脱却、いわば自立をする必要があります。私的成功とは、他者に依存せずに自分の力で結果を出していくことです。
私的成功には３つの習慣があります。
- 主体的である
- 終わりを思い描くことから始める
- 最優先事項を優先する
順に説明していきます。
主体的である
自分の力で物事を成し遂げていくためには、主体的に行動して行かなくてなりません。他人からの影響で結果が出るのでは自分のためになりません。自らその状況を創造できるように主体的に行動します。行動するときは率先して動き、自分の行動に責任を持てば主体性が成長し、自ら良い結果を創造することができるようになります。
終わりを思い描くことから始める
終わりを思い描くことにより、優先順位を図ることができるようになります。短期的な狭い視野から長期的な視野を持てるようになれば、途中途中の選択も変わってきます。そして、物事を選択する際には原則中心の考え方を身につければもっと良い選択できるようになります。原則中心とは、どんな物にも影響されない不変的な真理です。原則中心に行動すれば、正しい良心を持ち、賢明な選択ができるようになります。
最優先事項を優先する
時間管理の本質を一言で言うなら「優先順位をつけ、それを実行する」と言うことです。大事なのは「緊急ではないが重要なこと」で後回しにされている領域を優先していくことです。ここで第１の習慣と第２の習慣ができていないと、正しい行動ができません。主体的に動けないと、優先事項があっても周りに影響を受けてしまい、原則中心の選択ができないと正しい優先事項がわかりません。最優先事項を優先させるために、主体性と原則中心の考え方を持った上で、自己マネジメントを成長させていく必要があります。
公的成功
公的成功とは他人との信頼関係を正しく築き上げて相互作用の力を引き出すことです。正しい信頼関係を築くためには、誠実な行動が必要です。相互作用を引き出すためには、主体的な行動ができるようになっていないとできません。この章も今までの習慣が土台となって効力を発揮します。
公的成功には３つの習慣があります。
Win-Winを考える
Win-Winとはテクニックではなく、人間関係の総合的な哲学です。すべての人間関係においてお互いの利益になる結果を見つけようとする考え方と姿勢です。Win-Winの関係でないと信頼関係を築きあげることはできません。そして、Win-Winの関係を築くためにも、私的成功にあった習慣が必要になってきます。
まず理解に徹し、そして理解される
相手の理解に徹して、相手に耳を傾けて共感する。相手の信頼を築いた後に、自分を理解してもらいます。信頼関係を築かないと相互作用を生む創造的な解決策が生まれません。
シナジーを作り出す
シナジーは心が沸き立つものです。創造して心を沸き立たせるものです。お互いに主体性を持って信頼関係を築いていれば、シナジーを作る創造的なアイデアが生まれます。
刃を研ぐ
第７の習慣は、自分自身の価値を高めていく習慣です。肉体、精神、知性、社会の４つの側面の刃を研ぎ、再新再生させていきます。成長の連続体では第７の習慣を身に付け、他のすべての習慣に影響を与えます。
終わり。
感想
とても良い本だとは思うのですが、、、
宗教チックなゴリ押し感と胡散臭いにおいがあって、金儲けの餌に使われている感じがちょっと、、、
リモートワークに憧れていたのに実際にやってみたらリモートワークは最悪だった件（個人的感想）
半年ほどリモートワークをしていました。
今は毎日電車に揺られながら出勤していますが、リモートワークと比べて出勤は最高です。
リモートワーク期間はダメダメでした。
今回はリモートワークのなにがダメダメなのかと言う話をしたいと思います。
ダメダメポイント１ 仕事が捗らない
全然仕事が捗りません。
まあ当たり前ですよね。
自分の場合ですが生産性で言うと、8分の１くらいです。
なぜ８分の１なのかと言うと通常であれば毎日８時間仕事をするところ、在宅勤務では集中して仕事をしている時間は１時間程度だからです。
気持ち的にはサボる気もなく、真面目に働きたいと思っているのにいつの間にかネットサーフィンをしていたり、携帯をいじっていたり、漫画を読んでいたり、、、
最悪だったのは漫画を読み始めたら止まらなくなって全く仕事をしていなかった日です。
自分的には最高かもしれませんが、会社的には最悪です。
買ったばかりのゲームを一日中やっていた日もあります。
そんな日は嘘の報告を上司に伝えるしかありません。
とても心苦しいです。
昔はリモートワークに憧れていました。
リモートワークになったら仕事をバリバリにこなしていつもより少ない時間で業務を遂行してその分プライベートを充実させると言ったようなイメージをしていましたが、実際にはそんなに甘くありませんでした。
全然仕事捗りません。
本当はバリバリ仕事がしたいんです。
でも、できないんです。
集中が続かないんです。
誘惑が多すぎるんです。
だって、いつでもサボれますから。
監視している人もいませんから。
いつでもサボれる状況下で真面目に仕事を続けることは私にとっては無理でした。
途中、本気で思いました。
「zoomで部屋を映しあいながら仕事したいな」
女性に言ったらただのセクハラですが、共感できる人となら意外と有りだと思っています。
そのぐらい集中できないです。
ダメダメポイント２ 仕事がしたいのに仕事が進まないストレスとの闘い
サボってはいますが、本当は仕事がしたいんです。
最初に考えていたバリバリ仕事をこなした上でプライベートも充実させる、なんてことができたら最高ですが、それはもう諦めています。
普段よりちょっと少ない程度に仕事ができればいいかなくらいになっていますが、それも無理でした。
会社に出勤していた時よりもちょっと少ない程度の仕事量もこなせないです。
けど、最低そのくらいはしないとお給料をもらっている身として面目が立ちません。
会社に迷惑を掛けたいと考えている会社員はいないと思います。
私もそうです。
でも、リモートワークでは仕事が捗らないんですね。
最低ラインの仕事量はこなしたいのに、最低ラインの仕事量もこなせないので、毎日申し訳ない気持ちでやりました感を出しながら上司に報告します。
その心苦しさが毎日ストレスとして蓄積されます。
上司には言い訳として、リモートワークでは集中できないと言った相談はしましたが、それでも結局のところ改善できていないので上司からの信頼もなくなっていくことでしょう。
仕事がしたいのに仕事ができないストレスがすごいです。
仕事をした上で進まなかったらまだ良いですが、そもそも仕事をしていないんですから問題ですよね。
でも自宅ではどうしようもなかったんです。
ダメダメポイント３ 喫茶店で長時間居座るのは寒いしお金がかかる
もう家では無理です。
諦めました。
喫茶店で仕事をすることにしました。
しかし、喫茶店で仕事をしてみても結構居心地悪かったです。
１、２時間勉強する程度なら良いですが、仕事は８時間あります。
さすがに喫茶店に８時間も入れないです。
４時間ほどいたこともありますが、喫茶店は長くいるとめっちゃ寒いです。
手がかじかんできます。
実際にやってみると色々と面倒でした。
喫茶店での流れはこう↓です。
実際に４件も移動すると疲れちゃいます。
お金も３件分の茶店代とランチ代で2,000円以上掛かります。
移動時間もばかになりません。
私は千葉の田舎なので最寄駅には喫茶店はありませんので、電車で喫茶店まで向かうことになります。
仕事を喫茶店でするのはセキュリティの問題もあります。
Wi-Fi環境のことも考えなくてはなりません。
あと、気持ちの問題ではありますが、喫茶店に長いするのは居心地悪いです。
それが結構なストレスになります。
現実には、気分がのらずに疲れるしで途中で家に帰ることが多かったです。
ちなみに、喫茶店以外も色々試しましたが、どれも仕事する環境では微妙でした。
- ファミレス → 喫茶店よりも騒がしい
- 漫画喫茶 → 長いはできるがお金はもっとかかる上にサボってしまう
- コワーキングスペース → 地元には無い。料金は漫画喫茶程度
- 図書館 → コロナ期間により閲覧スペースの利用が不可。実際には仕事をして良い場所では無いし、電話もできない。
結局、せっかくのリモートワークなのに家から出ていくと言う本末転倒なことをしたのにあまり良い結果を得られませんでした。
家でできればすべてが上手く行くんですけどね。
ダメダメポイント４ 仕事の学習スピードが落ちる
仕事がサボりがちになってしまうせいで、仕事の経験値が得られなくなってしまいました。
１００の仕事量をこなしてレベルが１０になれるところ、２０の仕事量しかこなせ無いのであればレベルが２にしかなりません。
エンジニアは開発するのが仕事なのに、開発しないのであれば仕事ができるようになるわけがない。
結果、リモートワークをして仕事の生産性が落ちるせいで、エンジニアとしての学習スピードが落ちてしまいます。
ダメダメポイント５ コミュニケーション不足
やっぱりチームで仕事をしているので、情報の共有が十分で無いとチームとしての生産性も落ちてしまいます。
コミュニケーションが少ないと情報の共有が普段より少なくなっていきます。
雑談から仕事の話に飛んで行くことも多々あります。
雑談の中だったらできる質問も多々あります。
そう言ったところで仕事への理解が深まるし、そのプロジェクトへの愛着も大きくなると思うので、やっぱり実際に会ってコミュニケーション取りたいです。
て言うか普段から足りていない情報ががほとんどなくなったので、情報共有不足すぎました。
コミュニケーションツールを使って交流が取れているならまだしも、自分の場合はほとんど利用されていなかったのでマジで辛かったです。
そして、コミュニケーションが取りづらいと通常の仕事での質問もしづらいです。
普段から質問しづらいのにコミュニケーションがなくなるとさらに質問しづらくなりました。
エンジニアになりたての自分はもっと質問しやすい環境が欲しかった。
リモートワークで無ければもっと質問できたはずです。
ダメダメポイント６ 勉強が捗らない
これが一番キツかったかもしれません。
エンジニアになりたてなので学習意欲が半端ないんです。
半端ない学習意欲で学習スケジュールを作っていたのですが、リモートワークになった途端に崩れていきました。
通常であれば、
- 通勤時の電車内での勉強
- 出勤前の喫茶店での勉強
- 昼休憩での勉強
これらの時間を確保して平日は４時間近く勉強ができていたのですが、リモートワーク時は出勤前の茶店での勉強のみになりました。
通勤時間が減った分勉強できると思われるますが、仕事も集中できないのに勉強なんてもっと集中できるわけが無いです。
そうすると勉強しに茶店に行かなくてはならなくなりますが、出勤前に勉強のために茶店を使うと仕事をするときにはその茶店にいづらくなってしまうんですよね。
定期代も出ないのに電車で移動して、茶店代もかさんで最悪です。
最後に
リモートワークが最悪だったお話をしましたが、この記事を書きながら大抵の人はリモートワークを有効活用できそうだなとも思いました。
実際にリモートワーク最高と言っている人もいます。
家族の時間も増やせるし、趣味の時間も増やせるし、サボりたい時にサボれるしリモートワークはいいことづくしなんですけど、自分には合わなかっただけなんだと思います。
リモートワーク賛歌に一石を投じてみました。
