底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

環境は仕事の出来不出来に影響するか?

プロ野球の世界では、頻繁ではないが年に何度かトレードが実施される。トレードとはチームに所属する選手を他球団の選手と交換すること(場合によっては金銭との交換もある)。それまであまり活躍していなかった選手が他球団に移籍したところ、今まで活躍してなかったのが嘘のように活躍するなんていうこともある。最近のトレードで印象的なのが、元巨人の大田泰示選手。巨人ではレギュラーでもなくあまり活躍してなかった印象だが、移籍先の日本ハムファイターズではレギュラーとして活躍している。巨人は「常勝」が宿命づけられた球界でも特に異質な雰囲気を持つチームというのもあり、かかるプレッシャーも甚大ではなかっただろうというのは想像に難くない。もしかしたらプレッシャー以外に、ファイターズでは指導者に恵まれたのかもしれない(特に監督が「三振を恐るな!」とアドバイスを与えたことが大田本人にとってよかったというインタビューをどこかで見た)。

 

プロ野球の世界でなくても一般的なサラリーマン、例えばエンジニアでも似たようなことはあると思っている。極端なことを言えば、常に無茶な要求ばかりしてくるクライアントやパワハラ上等の上司や先輩社員に囲まれ、システム開発において不明点があっても気軽に質問や雑談をする雰囲気にならない同僚ばかりだとしてまともに仕事が出来るだろうか。そんな環境で仕事が上手くいかなくて、「仕事ができないやつ」という烙印を押されたとしてそれは本当だろうか。

 

元々のポテンシャルがどれだけあろうが、そんな環境ではまともに仕事ができない人がほとんどだろうと思う。たまたまストレス耐性が人より高くて環境に関係なく仕事をスムーズに出来る人もいるかもしれないが、そんな人が「当たり前」なはずはなく仕事ができない方が当たり前だろう。

 

でもそんな環境にいると仕事ができない自分というのが当たり前に感じられなくて、自己嫌悪に陥ることもある。その場にいるとその場だけが世界の全てで比較対象がその中にしかないから、自分が仕事が出来ないのは自分が悪いせいとしか考えられなくなる。

 

もしかしたら勉強が足りないことが影響してる部分もあるかもしれないし、経験が足りてないことで判断できないことがあるのかもしれない。でもそれが理由で仕事が出来ないとしたら上司や先輩はなんのためにいるの?会社はなんのためにあるの?となる。出来ない部下や後輩がいるならそれを上手く指導したりするのが上司や先輩の役目なはず。会社も全員とは言わないまでも大体の人が上手く仕事が出来るようにするような仕組みを作るべきでしょう。

 

パワハラ上司や無理解な先輩社員、不愉快な同僚という組み合わせの場合だけでなく、このいずれか、または自分にとって負担でしかないような環境の職場であれば、転職することも視野に入れるべきだと思う。野球選手の場合、トレードを志願することで移籍することが出来る場合もごく稀にあるが、基本はトレードやフリーエージェントという仕組みを利用しないと環境を変えることはできないが、サラリーマンであればそのあたりの制約はない。

 

長々書いてきたが、実は今のプロジェクト先で「仕事が出来ておらずとても自己嫌悪に陥っている」のです。もともと開発のセンスがなく、実装から逃げてばかりいたので、上記で書いたような状況とはまた違うのですが、仕事を指示してくれるプロパーの社員さんの当たりが厳しく心身がしなびてきてしまったのです。

 

もうベテランとよばれてもおかしくない年齢とキャリアを重ねてきているので、「プログラムの組み方」を改めて手取り足取り教えてもらうという状況も異常だと思うし...学校じゃないんだから。役立たずで申し訳なくて恥ずかしくて死んでしまいそうでした。なので、現場を変えてもらう要望を出したのですが、案外プロジェクト先の評価はそこまで悪いものではなく、「役に立ってないということはなく、今後も頑張ってほしい」という意外なもの。

 

ただプログラミングの考え方はみっちり身についたので、別の現場で改めてリスタートした方が精神的にはいいかなぁと思っている次第です。

 

 

もしブラック・ジャックが仕事の悩みに答えたら

もしブラック・ジャックが仕事の悩みに答えたら

 
まんがで変わる 仕事は楽しいかね?

まんがで変わる 仕事は楽しいかね?

 
神メンタル 「心が強い人」の人生は思い通り

神メンタル 「心が強い人」の人生は思い通り

 

 

 

 

【ゲーム感想】FinalFantasyⅫ The Zodiac Ageをプレイしました

久々にゲームしました。前にPS2で途中までプレイしてたファイナルファンタジー12(FF12)のHD化されたリメイクを買ったのでプレイ感想を書きたいと思います。

まだクリアしてないので、途中までのプレイ感想になりますが、よかったらお付き合いください。 基本的にストーリーの根幹に関わるようなネタバレはない方向で f:id:starscream1999:20190429021526p:plain

どんなストーリーか


すごくざっくり言うと、

強大な軍事国家であるアルケイディア帝国とその帝国に侵略されたダルマスカ王国の王家の生き残りであるアーシェが 帝国への復讐を狙う


というのが今のところの本筋になっているけど、そこまで単純な話ではないかもしれない。 関わるキャラクターがたくさん出てくるので、誰が誰だっけ?となるので混乱するが、完全な群像劇ではないので話自体は上記の通り すごくシンプル。



キャラクターは割とリアルな作りだと思う


造形が、という話じゃなく。 主要な登場人物は7人。

  • ダルマスカ王国の王家の生き残りである、アーシェ
  • ダルマスカ王国の将軍だった男、バッシュ
  • 空賊という自由な生き方をしてる、バルフレア
  • バルフレアの相棒であり、魅力的なヒップのフラン
  • ダルマスカ王国の国民(つまり一般人)のヴァン
  • 同じくダルマスカ王国の国民でヴァンの幼馴染のパンネロ
  • アルケイディア帝国皇帝グラミスの三男(長男・次男は死んだ)で、軍事的に天才的な才能を持つヴェイン

どの辺がリアルか、というと
最初はヴァンが主人公というか物語を引っ張っていくのかな?と想像していたのに プレイしているとヴァンは無邪気な少年で、世間知らずな面もあるけれどパーティのムードを盛り上げる 楽しいキャラクターではあるものの、物語の中心人物ではない感じ。

ただ、王家復興を行動の主体としているアーシェやバッシュに比べて動機が薄いし、 空賊としてすでにキャリアを積んでるバルフレアやフランとは物事の見通しのレベルが違う。

そもそもアーシェがヴァンに頼るようなポイントがないので、パーティのリーダー的立場として振る舞うようになる というのは自然じゃない。安易にヴァンを主人公としてパーティに据えないのはよかったと思う。
(まだクリアしてないので、どういう展開になるのかは実はちょっとまだわかってないんだけども)

f:id:starscream1999:20190501022451j:plain
FF12のメインキャラクターと、登場種族たち



広大なフィールド、ダンジョン


FF12のフィールドはオープンワールドではないけれど、とても広い。 ケチってチョコボを利用しないで徒歩で移動すると特に広い。 広いけど、ダルマスカの東西に広がる砂漠に、南のギーザ草原、森林地帯や山岳地帯、海岸線などロケーションは豊富で飽きない。 冒険中にふと立ち止まってキャプチャを撮ってしまう。

f:id:starscream1999:20190426153854j:plain

f:id:starscream1999:20190426031115j:plain
頑張って撮ったパンチラ
f:id:starscream1999:20190426032332j:plain
f:id:starscream1999:20190429025040j:plain
FF12イヴァリース世界で最も文明の進んだ都市である帝国領内
f:id:starscream1999:20190429024949j:plain
ガラスの不透明感とかすごくいい感じ

ダンジョンも、古代の遺跡や坑道にありふれた洞窟などパターンもたくさんあり、そのどれもが細部に至るまできちんとデザインがされていて 製作スタッフの徹底したこだわりに頭がさがる思いだ。 FF15でも一つの街、一つのロケーションで「誰も見てないんじゃないの?」という部分までデザインがされていてため息が出たけど。 何よりこれだけの内容をPS2時代に実現していた、ということを考えると本当にFFの製作スタッフはすごい。 いまだにPS4をプラットフォームとしながらそのスペックのほとんど使わず紙芝居みたいな会話シーンでお茶を濁している 他メーカーとの力量の差を強く感じる。

f:id:starscream1999:20190429050735j:plain
ただのショーケースだけど、とてもリアルに作られてる
f:id:starscream1999:20190429050139j:plain
空賊のお姉さん。ファッションがとてもセクシーですね。



ガンビットシステムは癖があるが、慣れれば楽しい

PS2版でプレイした時は、いわゆるモンスターと接触からの戦闘エリアに移動してコマンド戦闘するという従来のRPGに慣れていた自分は フィールドでモンスターと接触してそのまま戦闘に移るFF12のシステムに違和感があり、なおかつパーティメンバーに対してつどつど指示を出す のではなく「指示書」としてガンビットを使うというのに全く慣れなかった。

エンジニアとして働く今なら「IF文の羅列」という仕組みに非常に馴染みができているのだけど、 それでももうちょっとパターンというか「IF〜ELSE」くらい欲しかったような気もする。 でもELSEまで含めてしまうと、ネストが深くなってもっと分かり難かったかもしれない。

しかし、慣れてはいるものの、いまだにガンビットを上手に使えていない。

「これで固定してOK」という運用じゃなくて、 ガンビットは固定ではなくて、戦う場所やモンスターによってその場で書き換えて運用するのが正しいのかもしれない。

f:id:starscream1999:20190426191522j:plain
美人姉妹



不満点は?

実はこれといった不満点はあまりない。 今回のリメイクで実装された高速モード(通常のプレイを2倍または4倍でプレイすることが出来る)があることで 広いイヴァリースの世界もそんなに苦ではないし。

一つ挙げるとしたら、MAPと自分の進行方向がよくわからなくなることが多くて、 行きたい方向と真逆に行ってしまうことが多々ある。L3ボタンで現在地のMAP表示が出来るようになっているのですごく 便利なのだけど、MAPと自分自身との連動がうまくいかないのでイライラすることが結構ある。

世界観の細部を突けば、飛空艇が非常に発達した世界であればその前に一般市民がもっと利用できるような自動車、バイクと行った交通手段が 発達してないとおかしいような気もする。帝国領内では空中を移動するタクシーが運行しているのに、それを外の世界で 使わないのはなんか変な感じ。人の行き来が飛空艇、またはクリスタルを介したものがメインになっているのと モンスターが跋扈している世界なので、自動車なんて危なくて乗ってられなかったりするのかもしれないけど。

とは言ってもやっぱり自動車(そもそも整備された道路がない)のは変だな。都市から都市へ荷物を運ぶのは飛空艇を利用するとして 飛空艇のステーションから離れた場所に荷物を運ぶ時どうしてるんだろ。人力?


クリア前の感想

とてもよくできたRPGで、他にPS4で一般的なRPGで遊べるものがない人は遊んでみたほうがいいと思う。 最初のジョブ選択ではよく考えたほうがいいとは思うけども。

ソースコード読めないプログラマがソースコードを読むために教えてもらったこと

懺悔めいた前置き(長くなってしまった)

今のプロジェクトに入るまでしばらくコーディングから離れていた。
プログラミングが苦手だったので、意図的に実装フェーズに関わらないようにプロジェクトを選んでいたので当たり前なんだけども。

なんで苦手かといえば、

  • ソースが読めない
  • 意図した通りにプログラムを組むことが出来ない

そんなのプログラマとして致命的だし向いてないからエンジニア辞めろ!という感じだが、 辞めず(追い出されずに、と言ってもいいかも)にこの業界に残れているのはひとえに周りに助けられてきたから。

ゴミエンジニアである自分が存在している時点で関わったプロジェクトの迷惑になっていて、それ自体は本当に申し訳ないんだけども、周りのおかげでなんとかエンジニアとして生きながらえさせてもらっていた。

前述の通り実装に不安を抱えていたので、ここ数年はテスト設計フェーズからのプロジェクトに参画していた。

いくつかWEB系プロジェクトのテストフェーズに関わり、そのままテストエンジニア(名前だけで中身は伴ってない)としてエンジニアを続けていければよかったのだけども、WEB系プロジェクトでテスト設計から関わってみて気づいたのが、自分が持つ「標準的なWEBアプリケーションに関する知識」が足りてないという実感。
今まで業務系システム(C言語でオンプレミス)ばかり関わってきていたので、当たり前といえば当たり前なのだけど。

  

WEBアプリケーションの基本部分を知らないと、業務的にWEBアプリケーションとしてテストすべき観点等が 曖昧になり、テスト設計がきちんと出来てこない。

  

知識がないので、確認すべきこと・確認しなくてもよいことの判断も出来ない。
テストとして不足していることにも気づけない。内部の動きがわからないので、きちんと動いているかどうかをWEB画面上で表面的にしか確認できない。
もちろんWEBの知識が不完全でも、テスト設計するのは自分だけではないのでテストケースが出来上がらないということもないし、
レビューで指摘を受ければ足りないことを加筆修正することは出来るので、テスト設計自体が「まったく出来ない」訳ではない。

やはりずっと心理的に「プログラムから離れていると不安である」ということを抱えているのかもしれない。 なので、テスト設計と併せてWEBアプリケーションの実装もさせてもらえるようなプロジェクトを探してもらって今のプロジェクトに入りこんだわけです。

今のプロジェクトはプロジェクト自体はいくつも並行で走っていて、
そのうちの一つに関わっている。周りにいるプログラマはそれぞれ別のプロジェクトに関わっているので、関わりは全くない(全く無関係ではないが、今のところ直接関係してない感じ)。

自分の担当プロジェクトでは、「リーダー」の下に自分だけがいるという構成になっている。久々に実装をしていて、

毎日めちゃくちゃ怒られている。

怒られているし、呆れられている。

(自分の仕事の出来なさに改めて泣きそうになっているが泣いたら終わりだと思うので踏ん張っている。)

  

目的と処理(手段)を分けて考える

前置きが長くなってしまったが、毎日何に怒られているかというと、

  • 変数の目的・役割をきちんと理解・把握出来ておらず、曖昧な状態でわかったふりをしているから。

今更「変数」か、という感じだが、本当にそのレベルなんです。すみません。 ただこれは基本だけどすごく大事なことで、変数だろうがメソッドだろうが、クラスだろうが同じことになる。

例えば、「成績優秀な生徒の名前を表示する処理」というような以下のソースがあった場合に、 (showという名前のメソッドのくせに表示する処理がなかったり、配列一つしかないのにforループしていたり、goodというフラグを作ってフラグを立てたり無駄なコードが入ってますがお気になさらず)

var students = {"name": hime,"testResult":100};

function showStudents(students){
  var good = false;
  var goodStudents = [ ];
  for(var key in students){
    if(students[key].testResult > 80){
      good = true;
      goodStudents[key].name.push({
        "name":students[key].name
      })
    }
  }
}

goodStudentsは成績が80点以上の生徒名が入る変数ではあるけれども、成績が80点以上の生徒名を入れるためではなく

  • 成績優秀な生徒として表示したいから作られた変数であること

という理解が大事だと教えられている。

今まで、

  • studentsは生徒情報を入れる変数
  • goodStudentsは成績が80点以上の生徒名を入れる変数

というように、「なんのため(目的)の変数なのか」ではなく「何をしている(処理)変数なのか」という読み方でコードを読んでいたし、プログラムしていた。 目的が曖昧だと「何をしているか」はわかっても「どうしたいか」の理解があやふやになる(自分の場合)。 このあたりの理解があやふやだった自分は、showStudents()生徒名を表示する処理と中途半端に理解した気になって、 studentsgoodStudentの役割の違いをきちんと言語化出来なかった。

  

ソースを修正したり、修正案を提示するたびに

  • 「これはなんのためにあるの」
  • 「どんな条件で変数に値を入れるの」
  • 「〜したいときはどうするの」
  • 「なぜここで初期化されているの」

と一つ一つ詰められている。答えられないということは理解がまだ出来てないということ。

これは変数に限った話ではなくて、関数だってクラスだってそれぞれ目的がまずあって、そのための手段をどうするかを考えるわけで、 ソースコードを読むときに目的をきちんと理解した上で読めば最終的に何をしたいのかわかる(と思う)。

小さな処理の単位で「何を目的に作られたのか」「なぜここで作られたのか」を理解出来れば どう処理を作ればいいのかも同時にわかる(実現の難易度とは別)。

  

ずっと詰められて頭が真っ白になってストレスでおかしくなる寸前で、 まだ消化できてなくて自分の言葉でわかりやすいようにアウトプット出来てない部分もあるけれど (わかりにくい文章だったらごめんなさい) まずは「目的」をきちんと把握するようにソースコードを読めば、理解できないこともないかなと思い始めている。

  

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

ソースコードリーディングから学ぶ Javaの設計と実装

ソースコードリーディングから学ぶ Javaの設計と実装

プログラマーのためのソースコードを読む技術

プログラマーのためのソースコードを読む技術

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

【基礎】テストエビデンスの取得について

長くて苦しい結合テストがやっと終わった。
テスト設計ではなく、久々に「テスター」として結合テストの最初から終わりまで一人でやり切った。
※わからないことは聞きまくりだったけども

  

しかし、長くて苦しかった訳はほとんど自分にあった。

とにかくテスト実施時の基本的なことをおろそかにしていたのだ...
何が大事だったか、戒めのために残しておこうと思う

  

  

テストを実施することよりも重要なことは、エビデンスをどう残すかということ

テストケースの消化、ということに集中しがちだが、結局納品物として「テストをしましたよ」という証明になるのはエビデンスになる。 「やりました」と口で言ってもエビデンスが残ってなければ話にならないからだ。 単体テストレベルであれば、打鍵のみでエビデンスを残さないケースもあるだろうが、結合テストではカッチリエビデンスに残すことに なるので、そのためにどうやってエビデンスを残すのか?というのは大事。

そして、エビデンスをどう残すかは決まったルールがあればそれに従うだけだが、 もし決まったルールがないのであれば、基本的には以下の4点を基本エビデンスとして残すこと。

  1. WEB系であれば、実行後の画面キャプチャ
  2. 実行前のデータ状態
  3. 実行後のデータ状態
  4. 実行後のログ   

  

エビデンスとテストケースの紐付け

エビデンスを格納した後でテストケースとエビデンスと一致させるために、紐付けが必要になる。
基本的にはエビデンス自体にテストケースナンバーをつけた上で保存しておけば基本は大丈夫。 わかりやすいのは、テストケースの大項目単位でフォルダを作成して、階層的にフォルダ管理をすることで エビデンスの紐付けはしやすくなる。
     

  

テストケースが「絶対」に正しいということはない

これはテストを実施中には実は判別が難しい。
テストケースが正しいか、誤っているかは仕様を理解していないと判別がつかないからだ。 単純にテストを消化するだけだと、テストケースの「期待値欄」とテスト結果が一致しないので、 「テスト結果=NG」としてしまいがち。
なので、テスト結果がNGとなった項目については、テスト実施直後くらいに先に報告をすべき。

※現場によってはRedmine等のテスト結果を管理するためのツールを利用しているかもしれない。  

  

テスト実施前にどんなテスト結果が必要か準備と確認をしておくこと

テスト実施前に手順の確認、という意味合いもあるが、

  • DBダンプを取る必要がある
  • 画像のキャプチャを取る必要がある
  • 実行ログを取得する必要がある
  • クライアントツール等のキャプチャを取る必要がある 等々

これらのエビデンスを取るために「何が必要なのか」を実施前に把握しておくこと。

  

テスト実施のための環境

テストを実施する環境は様々あると思うが、

  • WEBブラウザIEChromeのブラウザ種別の他に、versionも考慮されるはず)
  • ローカル環境(どこで実行するか、ログの出力はどこか)
  • サーバ環境
  • Dockerなどの仮想環境
  • AndroidiPhone等の各種スマホ

それぞれ「テストをするためにどんな環境構築が必要か?」と確認しておくこと。 最初から用意されている場合もあるが、大概何かしらの準備が必要になる。  

  

  

遅れていても余裕を持って(余裕がなくなることがミスを生む)

テストってどうしてもスムーズに進まず、どこかで遅れが発生することがある。 そもそもどんなテストをするのか、漠然と理解していてもきちんと理解できていない状態で、 テストを実施していると順調に進んでいるのか遅れているのかもよくわからなくなる気がする。 順調に進んでいるように見えて、実は確認すべきテスト項目の半分くらいしか確認できていない、 なんてこともあったりする。終わったと思ってエビデンスを格納する段階で「エビデンスが足りてない...」なんてことも。

場合によってはバグが多くてテスト実施はしたものの不完全だったりするなんてこともある。 現状の理解をきちんとをすることで進捗状態を把握できる。 パニックにならないためにも、状況を理解できる余裕を持つようにしよう。

  

  

もし大事はエビデンスを誤って消去してしまったら...

  1. MVコマンドでファイル名を置換しようとしたつもりが、RMコマンドを打っていた...
  2. 誤ってファイルの上書きをしてしまい、元のファイルが消えてしまった

など何かしらの操作により大事なエビデンスが消えてしまった場合の対処方法

RMコマンドで消してしまった場合は、ファイルシステムext3またはext4であること限定ですが、 以下の手段により復旧が可能なようですので試してみる価値はあります。

Linuxの恐怖体験「rmで間違ってファイル消してしまった!」そんな時はextundeleteでリカバリ | Unskilled?

大事なファイルを消してしまったけどextundeleteを使って危ないところで助かった話 - Qiita

Windowsの場合は、ゴミ箱に入っている可能性があるので、探してみよう。 そして、もし復旧ができなかった場合は素直に「すみません消してしまいました」と報告しよう。 何かしら対処を考えてくれるかもしれないし、単純にテストの取り直しを指示されるかもしれない。 おっかないのでRMコマンド打つ前はバックアップを取るのを忘れないようにしよう。

  

  

実施コマンド、投入したデータ、JSON、は念の為残しておこう

テスト実施時に叩いた、コマンドやデータ類、JSONなどの投入データは念の為手元に置いておこう。 だいたいテスト実施前に実行コマンド、データ、JSONなんかは実施前手順書的なドキュメントにあるだろうけど、 手順書に書いてある通りのコマンドなどで実施できない場合に書き換えもありうる。

日付やIDなどがユニークなキー値になっていて、すでに同じようなテストデータが投入されている場合に、 入力が弾かれてしまう場合があるからだ。

そもそも手順書の記載が誤っているかもしれない。

  

  

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

現場の仕事がバリバリ進む ソフトウェアテスト手法

現場の仕事がバリバリ進む ソフトウェアテスト手法

テスターちゃん 1巻

テスターちゃん 1巻

【提案】休日を有効に使うために考えたこと

エンジニアは常に自分の中の技術をアップデートし続けなくてはいけない宿命があります。

  1. 知らないプログラミング言語に対応する必要が出てきた
  2. 知らない開発環境を構築する必要が出てきた
  3. 仕事で関わりはないが、個人的に勉強しておきたい
  4. 資格取得のために学習したい

ドッグイヤーと呼ばれるIT業界では自分の状況がどうであろうと、日々何かしら技術が新しく生まれていて、それがいつの間に開発のデファクトスタンダードになってたりするのです。

もちろん技術的にアップデートしなくても仕事ができるケースはあるでしょう。 Javaのエンジニアは仕事にあふれていて、あぶれることはこの先ないような気もします。

しかし、大半のエンジニアは何かしらのアップデートが必要で、それを平日のプライベートの時間に使うのは難しく(そうでもない?)、勉強するなら休日にという人も多いはず。

まぁエンジニアという風に職種を限定せずとも、何かしら仕事をしていれば誰でもそうかもしれません。

自分は今までサボってきたツケが回ってきて、今さらWEBシステムの開発現場に入り四苦八苦しています。WEBシステムを開発するなら当たり前のような環境も何も知らず、現場の人から呆れられたりすることばかりで心がボロボロになってきてました。

これ以上ボロボロになるのは避けたいので、「休日に勉強して少しでもできるようになろう!」と考えて昨年から週末はファミレスで勉強してきました。 そこで、休日に勉強することを始めて気づいたのですが


休日に勉強していると、他に何もできない...

ということです。ファミレスで4時間5時間くらい勉強(SNSに気をとられることも多いですが)してると他に何もできなくなります。個人的には「勉強した!」という満足感もあるのでそこまで悲観的にならないのですが、一人暮らしで家事(掃除・洗濯)など平日できないことを休日にまとめてやるとしていた場合、結構ネックです。

だいたい午後2時か3時、日によって4時や5時にファミレスに行って4〜5時間勉強しているとその日はもう終わりです。

半年近くこのパターンを繰り返して気づいたのですが


午後から勉強を始めるとその日は他に何も出来ない

ということです。アホですね。 「勉強をしている」から「他に何も出来なくても仕方ない」を当たり前だと思ってました。 図書館に行こうと思っても閉館してますし、買い物行こうと思ってもお店は閉まってます。 そこで考えついたのが


午前中から勉強したら、午後から時間作れるじゃん!

ということです。 休日は12時くらいから始まるのがデフォルト、という生活パターンを変えて、 朝(7時〜9時)に起きて、ファミレスで朝食を食べてそのまま勉強すればいいことに気づいたのです!!

たとえ9時から4〜5時間勉強しても午後3時以降は他のことに使えるし、なんならショッピングとかにも出かけることも可能です!! これまでファミレスで勉強していた時にコーヒーをガバガバ飲んでいたのですが、カフェインが効きすぎて当日の夜は寝つきが悪かったように思います。しかし、午前中にガバガバ飲んでも多分その日の睡眠には影響が薄そうです。

これを実施するには、「休日前の金曜日とかに夜更かしし過ぎない」というヘビーな制約が必要ですが...

ザ・ファミレス

ザ・ファミレス

休日のアコースティック・カフェ のんびり聴きたい洋楽カバーベスト

休日のアコースティック・カフェ のんびり聴きたい洋楽カバーベスト

  • アーティスト: アントニオ・モリナ・ガレリオ
  • 出版社/メーカー: OVERLAP RECORD
  • 発売日: 2016/12/28
  • メディア: MP3 ダウンロード
  • この商品を含むブログを見る