読者です 読者をやめる 読者になる 読者になる

コツコツ

デザインやプログラミングについて学べる8bitspell.comの運営者のブログです。IT以外のことでも、思ったことをつらつらと書いていきます。

Amazon Web Service (AWS)のSNSを使ってiOSにプッシュを送ってみた 【Xcode編 その3】

f:id:takafoo:20161109235608p:plain

前回はProvisioning Profilesの作成をしました。 今回はXcodeでサンプルアプリを作成して、DeviceTokenを取得してみましょう。

サンプルアプリの作成

Xcodeを起動して、File>New>Projectを選択します。

f:id:takafoo:20161109235906p:plain


Single View Applicationを選択して、Nextをクリックします。

f:id:takafoo:20161109235958p:plain


Organizations Nameは識別しやすいもので大丈夫です。 Product NameとOrganizations Identifier を入力するのですが、その組み合わせがその1で作成したBundle Identifierと一致するようにしてください。 ここは凄く重要です。

f:id:takafoo:20161110000031p:plain


PROVISIONING PROFILEの割当て

以前作成したProvisioning Profileをサンプルアプリに割り当てていきます。 TARGETS>pushtest>Generalに移動したら、Teamのところから自分の開発用アカウントを選択します。

f:id:takafoo:20161110000112p:plain


pushtest>PROJECTのpushtestへ移動します。

f:id:takafoo:20161110000147p:plain


Build Settingsを選択して、Allが選択されていることを確認したら、検索バーにcode signと入力します。

f:id:takafoo:20161110000235p:plain


Provisioning ProfileのDebugには作成したプッシュ通知用のProvisioning Profileを指定します。Code Signing IdentifyにはProvisioning Profileに登録されたアカウントを指定します。この選択時にIdentifiers from Profile “hogehoge”というアナウンスが表示される場合は、それでサジェストされたアカウントを指定してください。上手く表示されない場合は、一度Xcode全体を終了して、再起動してみてください。これによって、Profileなどの認証がうまくいきます。新しいProvisioning Profileを追加した場合は再起動することをおすすめします。

f:id:takafoo:20161110000316p:plain


設定が完了すると次のようになります。

f:id:takafoo:20161110000341p:plain


TARGETS>pushtestのCode Signingについても同様の設定を行います。

f:id:takafoo:20161110000445p:plain


DEVICE TOKEN取得用コードの追加

TARGETS>pushtest>CapabilitiesからPush Notificationを有効化します。

f:id:takafoo:20161110000527p:plain


AppDelegate内に以下のコードを追加します。

// REGISTER DEVICE TOKEN
func application(application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData) {
        // GET TOKEN
        print("Device token = \(deviceToken)")
}

実機でアプリを起動すると、アプリがAppleのプッシュ管理用のサーバーにアクセスします。 端末固有のID情報の登録が完了すると、このファンクションを通じてdeviceTokenが表示されます。

// FAILED TO REGISTER DEVICE TOKEN
func application(application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: NSError) {
    print("couldn't register: \(error)")
}

また上のコードを追加することで、deviceTokenの取得に失敗した場合のエラー内容をみることができます。

//
// REGISTER DEVICE TOKEN
//
 
let userNotificationTypes:UIUserNotificationType = [UIUserNotificationType.Alert,UIUserNotificationType.Sound]
let settings = UIUserNotificationSettings(forTypes: userNotificationTypes, categories: nil)
application.registerUserNotificationSettings(settings)
application.registerForRemoteNotifications()

最後にAppDelegateのdidFinishLaunchingWithOptions内に上のコードを追加してくだい。 このコードでは通知設定を促すウィンドウとDeviceTokenの取得を試みます。


f:id:takafoo:20161110000559p:plain

DeviceTokenが取得できるとXcodeのConsole画面に次のように表示されます。 次回はAWSSNSを使って実際にプッシュ通知をしてみましょう!

【書籍】「強いチームはオフィスを捨てる」リモートワークのメリット・デメリットについて書かれた一冊

f:id:takafoo:20161106133419p:plain

初めて投稿する【書籍】記事です。 この書籍シリーズでは最近僕が読んで良かったと思う本を紹介していきたいと思います。

記念すべき第一回目は『強いチームはオフィスを捨てる』です。

僕が感銘を受けた『小さなチーム、大きな仕事』を執筆した37SIGNALSの新作

みなさんは37signalsという会社をご存知ですか?社名を聞いてもピンと来ない人の方が多いかと思います。 では、Ruby on Rails というフレームワークはご存知ですか?もしかすると、このブログの読者の方にとってはこちらの方がピンとくるかもしれません。 実はRailsというフレームワークは37signlasによって作られました。 現在は社名をbasecampに変えられており、このbasecampという名前もbasecampが提供しているプロジェクト管理用のウェブサービスから来ています。 多くの気付きと深い感銘を受けたジェイソンさんによって執筆された前作『小さなチーム、大きな仕事』にはbasecamp社のモノづくりに対する考え方やアプローチについて素晴らしい挿絵と分かりやすい言葉で書かれています。一般的な考え方とは違って、ときに過激に感じる内容もあると思います。 それでも、どの内容も実直にモノづくりをしてきた人だからこそ書ける内容であり真理をついている部分が多いです。 僕はこの本から多くの刺激を受けて、その後のモノづくりの考えたががらっと変わりました。個人、小さなチームで開発されている方にはオススメの一冊です。

そんなジェイソンさんの新作が今回紹介する『強いチームはオフィスを捨てる』です。 モノづくりの考えたやアプローチについて解説している前作とは異なり、今作ではチームでの働き方について焦点をおいています。

新しい働き方がもうそこにやってきている

僕もこの本を読むまでは「リモートワークって知っているけど、周りにやっている人は殆どいないし自分には縁のない話」だと決めつけていました。はなから自分には出来っこないと思っている人達に向けて、ジェイソンさんは自らの体験をもとにリモートワークのメリット・デメリットを教えてくれています。この本を読んで感銘を受けた部分を抜粋していきたいと思います。

働けるうちは仕事に専念し、リタイアしてから好きなことをやるという考え方は、もう捨てよう。 これからは仕事も趣味も、同時に楽しめる時代だ。「仕事さえなければ」という思い込みから自由になれば、人生はもっと生きやすくなる。宝くじにあたるのを待つより、そのほうがずっと現実的だ。

(略)

といっても別に、スキーがやりたければ家を引き払って雪国に引っ越せといっているわけではない。もっと簡単なところからはじめればいい。 たとえば、3週間だけ雪国にステイしてみるのはどうだろう? すべてを捨てる必要はない。柔軟にやっていけばいいのだ。

これからは、場所と時間を自由に選べることが本当のぜいたくになる。 いちどそんな自由を経験したら、最上階のオフィスや豪華な社食なんかこれっぽっちの魅力も感じないはずだ。

ライフスタイルを変えるときには退路を断つような気持ちで臨む必要はありません。 たとえば、リモートワークをしたいのなら週1で1日2、3時間から始めてみればいいと思います。 朝10時に出勤する必要があるのなら、自宅で12時まで作業してそれからオフィスに向かう形でもいいのです。 小さく柔軟に始めることで、周りにも自分にも負担をかけずライフスタイルをシフトすることができます。

本を読んだ中で一番印象に残った言葉が『これからは、場所と時間を自由に選べることが本当のぜいたくになる。』という言葉です。 まさにこの言葉通りで、一度でもリモートワークを経験すると豪華なオフィスや社食といった物資的なもので得られるものになんの魅力も感じなくなってしまいます。


「会社と社員の両方にメリットがある」なんていうと、虫がよすぎるように聞こえるかもしれない。ただの夢物語だと思うかもしれない。 でもリモートワークなら、本当に、会社も社員もハッピーになれるのだ。

(略)

リモートワークに向いた仕事のほとんどは、管理者と労働者の対立からは自由なところにある。昔ながらの工場の単純作業なら、1分1秒見張って生産性を上げさせるというやりかたもありだったかもしれない。 でも文章を書いたり、プログラミングやデザインをしたり、広告を考えたり、顧客をサポートしたりーそういう仕事の生産性は、もっとずっと複雑なものだ。 コピーライターの1時間あたりの生産ワード数を増やすことにこだわったところで、誰の得にもならない。 それよりも、最高にグッとくるコピーをひとつ生みだしてくれたほうがいい。そのほうが、みんな豊かになれる。

僕は仕事でプログラミングやデザインをすることが多いのですが、これらの仕事の生産性は時間に比例しないことがよくあります。 例えば、プログラミング中にバグを発見して何時間もかけて悩んでいたものが、数分の休憩をとったあとに「あっ、これってこうじゃない」といった感じであっという間に解決できてしまうことがよくあります。開発中にゾーンに入ると、普段の作業時間の半分くらいのスピードで実装が完了することもあります。デザインの場合はもっと顕著に現れます。いいデザインをあっという間に思いつくこともあれば、時間をかけても中々思いつかないことだってあります。

時間がかかっても最終的にいいプロダクトが出来てみんながハッピーになれればそれで良いと思います。


そして、いったんリモートワークに慣れてしまえば、距離のことなんてまったく関係なくなる。みんなが実際にどこにいるかなんて、すぐに忘れてしまう。いつもはロシアにいる人が、タイで働いていても気にならない。仕事をするうえでは、何のちがいもないからだ。

世界に目を向ければ、すばらし人材を獲得できるチャンスは格段に広がる。それに、外国で商品を売るときの強みにもなる。外国の細かな習慣を知っておいたほうが有利だからだ。たとえばソフトウェア開発でいえば、カレンダーは何曜日からはじまるのか。日曜日に固定してしまうと、月曜日からはじまる国で売れなくなる。カレンダーのアプリをつくるとき、そういうことに気づく人がいてくれると心強い。

僕もリモートワークを始めてから気がついたことがあります。 それは、パソコンとネット環境さえあればどこでも仕事ができるということです。メンバーとのやり取りはSlackで簡単にできるため、他のメンバーが遠く離れたところにいてもまるで隣で一緒に作業している感覚です。また、リモートで作業できるためオフィスから遠く離れた場所で開催されるワークショップがある場合は、予めその近くで作業することで移動時間も短縮することができます。

世界中で働くことができるということは、世界中の人材と一緒に働くことができるということでもあります。 この本でも紹介されているように、それぞれの国によって好まれる色やデザインというものがあります。世界中の人に使って欲しいサービスがあるのなら、特定の人種だけで開発を行うとUIやデザインが偏ってしまうことがよくあります。世界中の人と働くことで、様々な視点を持てるためよりよりプロダクトの開発が出来るのではないかと思います。


リモートワークについての報道を見ると、怠けて働かなくなるというイメージが一般的なようだ。でも、リモートワークの本当の危険は、働かないことではない。 働きすぎてしまうことだ。

従来のオフィス勤務の場合、多少の残業はあっても、最終的には家に帰らなくてはならないという区切りがあった。ところがリモートワークには、そういう明確な区切りがない。

(略)

人は油断すると、仕事にハマってしまう。

リモートワークでもっとも勘違いされてしまうのが、この「サボって仕事しなくなるんじゃないか」という点です。 リモートワークを経験して、これが間違いであるということを実感しました。僕もリモートワークを始めた当初はバグとりや実装に夢中になってしまい働きすぎてしまうことがありました。自宅で作業している場合には帰宅する必要もないので、なにか良いアイディアを思いつたりでバグを見つけてしまったりすると、際限なく作業してしまうのです。


この働き過ぎを防ぐ一つの方法として次のようなものが紹介されています。

働きすぎをふせぐためには、チーム全員でお互いに目を光らせておくことだ。そして何より、チームをまとめるリーダーや経営者が「働きすぎはよくない」というムードをつくっていく必要がある。リーダーが残業好きだと、部下もそれに引きずられてしまう。

(略)

働かないチームはいらないが、仕事ひとすじのチームも困りものだ。うまく息抜きできる人のほうが、長く安定して成果をだしやすい。

リーダーや経営者がこのようなムードを作ることで、「上司が残っているから帰りにくい」といった雰囲気を打ち消すことができます。 定時に帰ることで、仕事とプライベートの切り分けがしっかりできます。自由に使える時間を自分の趣味や勉強にあてることで、仕事に役立つようなアイディアが浮かんでくることもあるでしょう。


リモートで働くメリットのひとつは、自由に環境を変えられることだ。 といっても別に、遠い外国に行くということではない。もっと気軽に、場所を変えるということだ。 家で仕事をしたり、近所のカフェで仕事をしたり、たまには別のカフェで仕事をしたり、図書館に行ってみたり。ひとつの場所にとどまる必要はどこにもない。

決まりきったことの繰り返しは、クリエイティビティを弱らせる。 同じ時間におきて、同じ電車に乗り、同じ道を歩いて、同じオフィスの同じ机に座る。毎日毎日その繰り返しでは、発想まで凝り固まってしまう。

でも、環境を変えれば新しいアイディアがどんどん浮かんでくる。

(略)

リモートで働くということは、家をオフィスにすることではない。キッチンが会社のデスク代わりになるのでは、意味がない。 それよりも、場所の自由を生かして、もっといろんな環境にふれてみよう。多様なものをみて、多様な空気を感じよう。

毎日同じ場所に通う生活よりも、ずっと発想の幅が広がるはずだ。

僕もリモートワークで働くようになってから、自宅やコワーキングスペース、カフェなどで作業するようになりました。 固定の場所で働くことはあまりなく、日替わりで毎日違う場所で作業しています。移動手段も電車を使ったり、天気が良い日には歩いてみたりと様々

場所やルートを変えることで、目に入ってくる景色や、周囲の会話などの色々な情報を吸収することができます。 これらが新しいアイディアを浮かぶことに繋がっていると実感しています。

リモートワークを経験してわかったこと

今から約3ヵ月前にこの本に出会い、実際にリモートワークを始めてみると本の内容に深く共感する点が多くありました。

実際に仕事とプライベートの切替ができるようになり、プライベートが充実してきました。自由に使える時間で個人的に始めたいことに挑戦したことで、それで身につけたスキルや経験が仕事の方に役立つことが実際にありました。さらには、色々な環境に触れることで発想の幅が広がりました。

また、この本でも述べられていることなのですが、リモート作業により会社の人と実際に面と向かって話す機会が減ってしまいました。一見すると悪いように思えますが、逆に会える機会が少ないからこそメンバーと実際に会える時間がとても貴重な時間となりました。オフィスで作業している時には、他のメンバーにも積極的に声をかけて以前よりも話す機会が多くなりました。

ネットとウェブテクノロジーの発展により、働くのに場所や時間を選ばない環境が僕らの周りにもう揃っています。 あなたの会社でリモートワークをしている人が1人もいないのなら、あなたの方から上司に提案してみてはいかがでしょうか? いきなり、業務の全てをリモートワークに置き換えるのは難しいとは思うので、10%でも5%でもいいと思います。小さなところから始めることで、周りの理解も得られるのではないかと思います。

もし、あなたがリモートワークを経験したらオフィスで毎日働くことに不満を感じてしまうと思います。それほど、リモートワークは強烈なインパクトを持っています。 少しでもリモートワークに興味をお持ちなら、『強いチームはオフィスを捨てる』を強くオススメします。新しい働き方に興味があるあなたの背中をそっと教えてくれる一冊です。

Amazon Web Service (AWS)のSNSを使ってiOSにプッシュを送ってみた 【Apple Developer Center編 その2】

前回はApp IDの作成とSSL証明書をアップロードして、プッシュを通知を有効化にするまでの準備をしました。 今回はProvisioning Profilesの作成をして、Apple Developer Centerでの作業を完了させましょう!

バイスIDの取得

プッシュ通知を送る際に必要なDevice Tokenはシミュレータ上では取得できないため、実機のiPhoneiPadなどが必要になります。デバイスをケーブルでMac本体に接続して、Xcodeを起動してくだい。 上部メニューからWindow > Devicesを選択します。

f:id:takafoo:20161106041046p:plain


プッシュ通知を送りたいデバイスを選択して、Identifierの文字列をコピーします。

f:id:takafoo:20161106041307p:plain


バイスの登録

Developer Centerに移動して、Devices > All をクリックします。 右上の「+」をクリックしてください。

f:id:takafoo:20161106041112p:plain


Register DeviceNameに識別しやすい名前をつけます。 UDIDの部分のところに、先ほどコピーしたIdentifierをペーストして、Continueをクリックしてデバイスを登録します。

f:id:takafoo:20161106041129p:plain


PROVISIONING PROFILESの作成

Developer Centerでの最後の手順となるProvisioning Profilesの作成をします。 Allを選択して、「+」をクリックします。

f:id:takafoo:20161106041512p:plain


iOS App Development**を選択してContinueをクリックします。

f:id:takafoo:20161106041601p:plain


プルダウンメニューから以前作成したApp IDを選択して、Continueをクリックします。

f:id:takafoo:20161106041916p:plain


開発者用の証明書を適宜選択して、Continueをクリックします。

f:id:takafoo:20161106041617p:plain


このProvisioning Profilesで扱う開発用のデバイスを選択します。 先ほど登録したデバイスを選択して、Continueをクリックしてください。 ちなみに、Xcodeでの開発中はここで選択した実機デバイス上でのみアプリケーションが起動します。

f:id:takafoo:20161106041942p:plain


Provisioning Profile が識別しやすい名前を入力してContinueをクリックします。

f:id:takafoo:20161106041958p:plain


Profileが生成されるので、分かりやすい場所にDownloadしてください。

f:id:takafoo:20161106042020p:plain


これでDeveloper Center編は終了です!

次回はXcodeで簡単なアプリを作ってDevice Tokenの取得などをしてみましょう!

Amazon Web Service (AWS)のSNSを使ってiOSにプッシュを送ってみた 【Apple Developer Center編 その1】

f:id:takafoo:20161105040535p:plain

開発中のアプリでプッシュ通知を送る必要があり色々調べていたところ、 Amazon Wev Service (AWS)SNSというサービスを利用するのが簡単だということがわかりました。しかし、証明書の発行やトークンの取得だったりとやることが多すぎて忘れてしまう可能性があるため、覚書のような感じで記事を書きました。

全3回 に渡ってApple Developer Centerでの証明書の発行からSNSの設定、プッシュの送信までを書いていきたいと思います。

やらなくてはいけないことリスト

以下がプッシュ通知ができるようになるまでの手順です。

[ Apple Developer Centerやること ]

  1. App IDの作成
  2. SSL証明書の作成
  3. Provisioning Profilesの作成

[ Xcode ]

  1. サンプルアプリの作成
  2. Provisioning Profilesの割当て
  3. DeviceTokenを取得するコードを追加

[ AWS SNSでやること]

  1. Platform applicationの作成
  2. Endpointの作成
  3. プッシュ送信の確認

APP IDの作成

まずは、developer.apple.comに移動してログインをします。 左側のメニューからCertificates,IDs & Profilesをクリックします。

f:id:takafoo:20161105033253j:plain


IdentifiersからApp IDsをクリックします。

f:id:takafoo:20161105034212j:plain


右上にある「+」をクリックします。

f:id:takafoo:20161105034226j:plain


App IDの登録画面になるので、必要な情報を入力していきます。 App ID DescriptionはこのAPP IDの簡単な説明でわかりやすい名前をつけてください。

f:id:takafoo:20161105034239j:plain


Explicit App IDを選択して、Bundle IDを入力します。一般的には自分の所有するドメイン名を逆にしてアプリ名を追加した形になります。たとえば、taka.usの場合はus.taka.アプリ名になります。また、ここに入力したIDと後ほどXcode上で作成したプロジェクトのIDを一致させる必要があります。

f:id:takafoo:20161105034251j:plain


App Services の項目に移動します。ここでは、使用したいサービスにチェックを入れることでアプリでその機能を有効化することができます。今回は通知サービスを使いたいので、Push Notificationsにチェックをいれます。次にContineボタンをクリックします。

f:id:takafoo:20161105034513j:plain


App IDの確認画面からアプリの設定一覧が表示されます。Push Notificatonsの項目がConfigurableになっていると思います。まだ、この状態では有効になっていませんが、気にせず RegisterをクリックしてApp IDを登録しましょう。

f:id:takafoo:20161105034825j:plain

SSL証明書の作成

プッシュ通知を有効化するためにSSL証明書を作成します。作り方は非常に簡単です。 標準でインストールされているキーチェーンアクセスというアプリを起動します。

f:id:takafoo:20161105035314p:plain


上部メニューからキーチェーンアクセス証明書アシスタント認証局に証明書を要求をクリックします。 f:id:takafoo:20161105035430p:plain


作成用のウィザードが表示されるの各情報を入力します。ユーザーのメールアドレスはDeveloperプログラムに登録しているものを入力しておきましょう。 通称は何でも構いません。また、CAのメールアドレスは入力しなくて大丈夫です。 ディスクに保存にチェックを付けて続けるをクリックします。 f:id:takafoo:20161105035547p:plain


任意の場所を選択して証明書を保存します。これから複数の証明書を扱うことになるので、アプリごとに証明書を保管するディレクトリを作成することをおすすめします。 f:id:takafoo:20161105035648p:plain


作成した証明書をDeveloper Center にアップロードしていきます。

App IDsをクリックして、先ほど作成したApp IDを選択します。 f:id:takafoo:20161105035738j:plain


Editをクリックします。 f:id:takafoo:20161105035823j:plain


Push NotificationsからCreate Certificateをクリック f:id:takafoo:20161105035918j:plain


Continueをクリック f:id:takafoo:20161105040015p:plain


Choose Fileをクリックして、先ほど生成した証明書を選択します。 証明書を選択したら、Continueをクリックして次に進みます

f:id:takafoo:20161105040118p:plain


プッシュ通知用の証明書が生成されるので、わかりやすい場所に証明書をダウンロードします。 Doneをクリックして次にすすみましょう。 f:id:takafoo:20161105040235p:plain


App IDsからこのApp IDを確認してみましょう。 Push NotificationsDevelopmentEnabledになっているのが確認できると思います。 f:id:takafoo:20161105040340p:plain

早起き生活を2ヵ月続けてわかったこと【メリット編】

f:id:takafoo:20161102000600p:plain

 

前回の記事では早起き生活を続けるコツを僕なりに説明しました。

実際に早起き生活を2ヵ月続けて次のような良かった点がありました。

  • 自由に使える時間が増える
  • クリエイティブな作業に集中できる
  • 目覚めがよくなる

【自由に使える時間が増える】

朝方生活をして得られた一番大きなメリットは自由に使える時間が増えたことでした。
以前の僕なら仕事が終わって、食事や雑務などを済ましてから作業をしていました。
この方法だと、仕事でちょっと立て込んで帰りが遅くなってしまったり、急に飲み会が入ってしまい自由に使える時間が減ってしまうことがありました。また、夢中になって作業していると寝る時間が遅くなってしまうという結果になってしまうことがよくありました。

しかし、朝起きる時間を早くすれば出社するまでの時間は確実に確保することができます。
業務時間ではないので、仕事で立てこんだり、朝7時くらいから飲み会が入ることなんてないですよね?だからこそ、朝早く起きた時間は大切なのです。

たとえば、朝早く起きて1日1時間確保すれば1ヶ月で30時間近くの時間を自由に使えるようになります。
30時間あれば、本を読んだりブログや本を書いたりプログラミングを勉強したり色々なことができるようになるのです。だからこそ、僕は何か新しいことを始めたいなら朝にやるべきだと思っています。

 

【クリエイティブな作業に集中できる】

人間は寝ている間に記憶情報を処理していると言われています。
もし、その日町ですれ違った人全員の服装や髪型、顔を脳が記憶しようとしていたらあっという間にキャパシティオーバーで脳がいっぱいいっぱいになってしまいます。
それを防ぐために脳は寝ている間に必要な情報と不要な情報を整理しているそうです。

そのおかげかどうか、目覚め後すぐは頭がスッキリとして「きれいサッパリな状態」になっている気がします。
昨夜まで悩んでいたアイコン、ロゴ、レイアウトなどのデザインを見直した時に違った切り口や異なるコンセプトが浮かび上がることがよくあります。朝早くに作業すると周りが静かなため、集中力が必要とされるクリエイティブな作業にも没頭できるのだと思います。
ちなみに、このブログも朝の時間を使って書いています。

 

【目覚めがよくなる】

最後になりますが、これについては説明するまでもないですね。
早寝早起きというと毎朝嫌々起きて辛いのではないかと思われそうですが、そんなことはありません。
僕の場合はむしろ以前より寝る時間が増えました。
早く寝ることで、朝日がのぼる時間に合わせて目が覚めるようになり目覚めがよくなりました。
夜型生活の時は何度も寝たり起きたりしていたのですが、今では一度目が覚めたらすぐに顔洗って作業に移れるようになりました。

 

何か新しいことを初めてみたいと思っているあなた。
朝方生活に切り替えて、朝の貴重な数時間を有意義に使ってみてはいかがでしょうか?
まずは5分早く起きることから始めてみましょう!

早起き生活を2ヵ月続けてわかったこと【メソッド編】

f:id:takafoo:20161031020734p:plain

最近僕は周囲の人に口々に「早起きの生活いいですよ!」と言っています。

困ったことに一度言っている人にもまた同じ事を言っている有様です。
どうして、ここまで自分が回りに言っているのかと言うと、朝方の生活を初めて本当に良いことだらけだったからです。
今回は僕が早起き生活にシフトした方法と得られたメリットについて書いていきます。

まずは少しずつ

朝方生活を始める前、僕は典型的な夜型人間でした。
仕事から帰ってくるとお風呂に入ってご飯を食べて、それからパソコンをいじっていると気がつくと深夜1時になっていることがありました。
ベットに移動して寝るかとおもいきや、スマホをいじってしまい、なんだかんだで寝るのが2時近くになることが殆どでした。
寝る時間は遅いのに、朝起きる時間は同じため朝起きても頭がボーッとしてしまいすぐに出かけける準備ができないことが多くなりました。

「こんな生活じゃだめだ」

一念発起して朝方生活に挑戦することにしました。
そしていきなり、「よし、明日はは6時に起きよう!」と決心して寝たのですが、翌朝起きた時間はいつもと変わらない8時頃でした。
朝方生活初日にしていきなりの失敗です。実は何度も目が覚めていたのですが、グズグズとベットの上で過ごして2度寝してしまったのです。
それもそのはずで、僕の体は毎朝8時に起きるのに慣れているのに、いきなり2時間も早く起きても上手くいくはずがないのです。
そして、次の日からは「よし、明日は7時50分に起きよう!」といつもの時間より10分早い時間に起きることに変更しました。
早起き生活を始めるときは、いつもよりほんの僅かな時間早く起きることからスタートする方がいいのだと思いました。
10分でも5分でも3分でもいいと思います。少しずつ時間を早くして体を慣れさせていくのです。

寝る時間を早くする

少しずつ起きる時間を早くするといっても、就寝時間が変わらず深夜1時だったら何の意味もありません。
時間は圧縮することができないので、就寝時間を早くする他ありません。
そのため自分の中で以下のルールを決めました。

  • どんなに遅くとも夜12時には寝る
  • パソコンは机の上において使う
  • スマホはベットに置かない
【どんなに遅くとも夜12時には寝る】

時には仕事で忙しかったり、個人的にやらなくてはいけないことがあり夜遅くまで作業しなくてはいけないことがあるかもしれません。
そんな時、以前の僕なら2時3時頃まで作業していたのですがそれもキッパリやめることにしました。
そもそも、夜中に作業して個人的にパフォーマンスが落ちるというのを実感していますし、翌日起きるのが辛いのでいいことありません。
だから、自分のことを思ってまずは何が何でも12時までには寝ることにしました。

【パソコンは机の上において使う】

僕は仕事でもプライベートでもラップトップを使っています。
持ち運びは楽ですし、画面を開けばすぐに作業できるのがとても便利です。
しかし、その反面ベットやソファーの上でも開いてしまうため、ベットに移動しても夜遅くまで作業してしまうことが多くなりました。
それを防ぐために、現在は机と椅子とディスプレイを用意してそこだけでしかパソコンをいじらないようにしています。
このおかげで、椅子に座ってディスプレイに向かうと作業モードになりますし、ベットに移動したら何も出来ないのですぐに寝られるようになりました。

スマホはベットに置かない】

今まで色々と紹介してきたルールの中で一番効果的だった方法がこのスマホをベットに置かないというものでした。
一つ前のパソコンは机の上において使うというものと似ているのですが、寝るときはパソコン同様にスマホも机の上に置くようにしています。
みなさんも、経験があると思いますがスマホであれこれ出来てしまうが故に、いつまで経っても寝ないでブラウジングしてしまうことがあると思います。
それを防ぐためにも、スマホを机に置いてしまえばベットでは寝ることしかできません。

パソコンやスマホなどの電子機器をベットから離れた場所に置くだけでも、簡単に寝られる環境を作ることができます。
最初は不便に感じたり、誘惑にかられそうになるとは思いますが一週間もすればすぐに慣れてしまうと思います。