最近、ちょっとAndroidかRailsでも勉強でもするかなーと思って、ジュンク堂に行ったんですよ。昔から、新しいものを勉強する時は10冊ぐらい初心者用の本を買って勉強するのが効率的だっていう経験から。
ジュンク堂って座って読めるんですね。立ち読みならぬ座り読みです。そこで、ふんふんって読んでいると、「ああ、なんか新しいもの覚えるのってめんどくせえな。。」っていう怠け心が出てきまして。
ダメですね、これは。CakePHPからiPhoneアプリに移動する時もこの怠け心が相当強くて踏ん切りがつかなかったのを覚えてます。新しい事に挑戦しないプチイノベーションのジレンマです。
先日、爆速タイマーアプリのListTimerというシンプルなアプリをリリースした。
※標準アプリが不便なので、爆速セットできるタイマーアプリ作った
これはiOSの標準タイマーがセットしにくいから個人的に作ったんだけど、リリースしてみたら予想以上に人気が支持されて嬉しい驚きでした。
さらに、とりあえずリリースしてみるという重要さをこれほど感じた事はなかった出来事が起こった。
以前から欲しかったので、爆速でセットできる死ぬほどシンプルなタイマーアプリを作った！無料です。爆速タイマーで検索すると見つかる。
このアプリは今まで作ったものの中でダントツにシンプルだけど、自分が頻繁に使うために作りました。
僕はiOSの標準アプリのヘビーユーザでありまして、もう毎日のように使っている。
どんな時に使うかというと、まずは毎日の作業時間のタイマーをセットするため。
これは数時間単位でセットするから特に問題ないのだけど、ラーメン作る時とか、数分レベルの時間をささっとセットする時にはとても使いにくい。。
まずiOSのドラムUIのタップできる範囲が狭く、なおかつ5分とかにぴっちりと合わせるのに気を使い、その後にセットボタンを押さないといけない。
また、電車で降りる時間をセットする時にもタイマーを使う。
例えば、池袋から渋谷に地下鉄で行くとする。乗り換え案内で乗っている時間をチェックして、電車に乗車する時にタイマーを12分とかでセットして、到着する頃にちょうどタイマーが鳴るようにしておくのだ。
これで、「つぎ降りる駅かな？いや、まだ新宿すぎたところか。。チラチラ」といちいち乗り過ごしを気にする事なく、読書とかスマホいじりに集中できるわけです。
ちなみに、降りる駅になったら知らせるアプリがよいかと思ったけど、結局は乗り換え案内見た後に、タイマーセットするのが一番単純で楽でした。
こんな感じで、数分単位のタイマーを使うことはよくあるのに、標準のタイマーアプリをセットするのがサクッとできないのが毎日のアキレス腱になってて胃が痛い思いをしてた。
じゃあ、アップストアには使いやすいタイマーアプリがあるはずだと思って片っ端から試してみた。
しかし、いろいろなカスタマイズ機能とか、見た目がクールだとか、そういう方向性のものは多いのだけど、ずっと使い続けるのに重要な起動 => タイマーセットという動作を突き詰めたものが見つからない。
なので、こうすれば一番すばやくタイマーセットできるだろうというUIを考えた結果、最初から1分〜90分まで最初からセットされているリストをスクロールして、タップしたら自動的にスタートするというUIにたどり着いた。
もちろん押しやすいようにボタンの大きさも広めに調整。これで自分の用途にはぴったりだ。最高だ。シンプルイズベスト！他に余計な機能はいらない！
友達に見せたら「これ、1分30秒とかにセットしたい時はどうすんの？(笑)」という心ないツッコミが入ったが、「そんなものは必要ない。なぜなら朕が欲しないから」と、日露戦争前のニコライ二世ばりに断言して黙らせときました。
まあ、さすがにカスタマイズあったほうがいいかなと思ったけど、そういうのは万が一人気が出て要望があった時に検討すればよいかと。
バックグラウンド時でサイレントモードの時に音を出すのはiOSの標準アプリにしか出来ない動作なんですよね。
自分は常にバイブモードで使ってるので、ここが一番のキモだった。サイレントモードじゃなければ大きな音なるから大丈夫だけど。
いろいろな他のタイマーアプリを試したところ、ここは仕様的にどうしようもないようだ。
なので、爆速タイマーでは、通知を何回か連続で出して気づかせるという仕様です。複数回通知きたらサイレントモードでも振動でなんとか気づくかなと。
ちなみに、バックグラウンド時にはアプリ動かず、通知をスケジュールするだけなので電池の消耗も心配いりません。
毎回いろいろな新しいことをちょくちょく実験してるのだけど、爆速タイマーではアップストアの文面を変えてみた。
アプリの説明文で、「なぜ作ったのか？」という文章を書いてみた。
機能を羅列しても誰も読まないだろうし、そもそも機能らしい機能もないので。
実はあまりにシンプルすぎてストア並ぶ前に審査落とされるのではと心配だったけど、あの説明文を読んでくれた担当者は、「なるほど、そういうことね」と承認してくれたのかも知れない。
料理とか、作業時間とか、さくっとセットしたい時に便利なのでよければ使ってみてください。
先日暇だったので、日本ではまだまだ知名度低いけど、ペイパルとか電気自動車のテスラ、ロケットのスペースXを作ったイーロン・マスクのインタビューを見てみた。
実はなんで見たかというと、Amazonのページを開いてたら、「おい、お前こんなん興味あるんちゃうか」と言わんばかりにAmazonさんが”イーロンマスクの野望”みたいな本を紹介してきたのがきっかけだった。
確かに、イーロンマスクの評判は聞いていて、とにかくスケールのでかい事業ばっかりやってるすげえ人だとか、別れた妻から私をロボットのように扱ったと文句言われたりとかいくつか記事を読んでた。
アイアンマンの主人公のモデルだとか。ちなみに、アイアンマンは凄いくだらなくて面白い映画なので１、２、３と見ました。あれの主人公はひたすら軍事技術で儲けてたから微妙に違うけど。
でも、例の日本語の本のレビューを読んだら凄く評価が低い。もう知っているような情報を集めただけの本とか、著者の勝手な想像が入ってるとか、メタメタに酷評されてかわいそうだった。
まあ、そんなレビューを読んでいたら、ちょっとこの本微妙なのかな。。って思っちゃって、ポチるのを辞めてしまった。自分もアップストアでアプリ出してるけど、レビューって結構影響されますね。特に無料じゃないってのもあるけど。
じゃあ、Youtubeでインタビュー動画探してみたらいいんじゃないかと思い、名前で検索したら英語の動画がいろいろ出てきたので、どれどれと視聴してみた。
まず見たのがこれ。ドキュメンタリー番組で一番包括的で面白い。
まず、小さい頃から天才すぎて周りとなじめず、一人で籠ったり、本ばっか読んだりしてたらしい。
10代の頃にはプログラミングがめちゃくちゃできる少年になっちゃって、プログラミングの教室とか行ったら先生より自分のほうが遥かにできるから意味なかったとか、そういう天才エピソードが。
スタンフォード入ったけどすぐ辞めて、ペイパル作った話とかも出てきた。そこで大金持ちになる。羨ましい。
この後、テスラとかスペースXを同時にやっていくんだけど、数年前のリーマンショックあたりは本当にどん底だったようだ。
すごい大金持ちなのに、テスラも当時上手くいってない時期で従業員を大量解雇したり、スペースXも失敗続きでどんどん会社のお金がなくなっていく。
そこで、自分の財産を会社に注ぎ込む事を決心して、周りの人の話によるとあの時上手く行かなかったら破産するところであったらしい。
ここで、「あんなに大金持ちになったのに、それを全部失う覚悟で事業に注ぎ込もうとするのは並大抵のことじゃないヨ。。」とか周りの人が話してた。
日本とかは社長が自分の金突っ込んで、借金して会社が倒産して首つるとかよく聞く話だけど、アメリカは投資社会だからそういうのは珍しいのだなとも思ってしまったが、確かにあそこまで大金持ちになってからあの規模で財産突っ込むのは凄い。
リーマンショック時代の頃は、テスラもスペースXもどっちも倒産しそうで、本当に絶望的で打ちのめされてたらしい。あまりにも辛すぎて、朝起きたら枕が涙で濡れてたとかいう話も。
全体的にインタビュー受けてる時はかなりもの静かな感じで、あまりオラオラな感じではないエンジニアっぽい印象。特にテスラが大量のレイオフしたつらい時期のインタビュー動画とかは結構泣きそうな感じが伝わってくる。
次にカーンアカデミーでのインタビュー動画を発見したので見てみた。
このインタビュー自体は淡々としてるんだけど、いくつか見ていた中ですごく印象に残ったのが、いろんなインタビューで、なんでこの事業をやろうとしたんですか？と言われた時の返答。
たいてい、「たぶん失敗するだろうと思ったけど、重要な事だからやることにした。」と言ってる。
ペイパルの時もそうだし、テスラの質問でもそう答えてた気がする。
このたぶん失敗するだろうけどやる意味があるからやるっていう姿勢が一番印象に残った。
というのも、僕はブラックスワンとか書いたタレブの本に影響されすぎいて、ここが凄く新鮮でカッコいい部分でした。
ああいう本を読むと、一回しかない人生の戦略として博打的なものに突っ込まずに確実なものから初めて、成功したらデカいっていう事柄には全力で突っ込まない姿勢になるんですよね。
タレブさんは、自分の人生を賭けて成功したら人類のためになる事に打ち込むリスクテイカーな起業家がたくさん入れば人類全体にとって凄く価値があると言っている。しかし、その成功の確率は運の要素もでかいから、ごく稀にしか成功せず、一個人の戦略としてはおすすめできない。
しかし、それでもやるソルジャーがたくさんいるから、誰かが上手くいき、その一つでも成功したらそれが人類全体に大きな恩恵を及ぼすと。だからリスクを取る起業家は素晴らしいのだとスタンフォードの授業でタレブが話してた。
これは、よくある成功例だけを強調して起業を煽るケースと違い、ある意味やる気をそぐような事を起業クラスで話すという凄いシュールな光景で、それでもやろうとしている君たちを本当に尊敬すると本心から語るタレブやっぱおもしれえと思ったんだけど、確かにイーロンさんみたいな人がいると人類の進化に恩恵がでかい。
ちなみに、タレブが人生のリスクを賭けるソルジャーとして社会システムに貢献する起業家を倫理的に賞賛する動画がこちら。43分頃。
「アントレプレナーシップとは、失敗したとしても、いや失敗した時こそ賞賛せねばならない。なぜならどっかの銀行と違って救済処置がない尊い行為だから。」と語ってる。
こういう事を肌感覚で分かっていたのかどうかはよくわからなけど、たぶん失敗すると思うがこれはやる価値があるからやったというイーロンさんの話に痺れた。
ちなみに、新しい奥さんはナイスバディで若くて、イギリス人の女優で美人です。タレブの話を聞くと微妙にやる気なくなるので、彼の話は無視してイーロンさんの奥さんを見てモチベーションを上げよう。
僕も一日３時間で効率的にやるとか眠たい事を書いてましたが、ちょっとやる気がでました。
※日本語の本
イーロン・マスクの野望 未来を変える天才経営者
※関連ブログ
進化、自由、知識、一粒の麦 – Zerobase Journal
“「仮説検証は、人が生きる上で非常に重要です。それがなければ、人は失敗から学べない」と。無駄死にか、一粒の麦か。自分が失敗しても、人類にとってはだとすれば、失敗を恐れることはない。”
Kindleで安かったからイーロンマスクの野望っていう本を読んでみたら、これ面白いじゃないか！
Paypalに合併した時の内紛とか、テスラを作る過程でのバッテリー問題とか、BBCのトップギア訴えた話とか、スペースXでロケット産業のコスト構造を計算してた話とか。
僕はたいしてイーロンマスクについて詳しくないので、上で紹介した動画より本のほうが遥かに細かい情報が載ってて楽しめました。特に車とか好きなんで、テスラが加速ではポルシェとタメはるけど、コーナリング性能は重くて微妙だとか、そういう話が面白かった。
スポーツカーってたいていハイオクでガソリン代などの維持費がかかるけど、バッテリーの問題が大きく向上してガソリン代みたいにコストかからないようになったら素晴らしいな。
アプリを作っているとプロダクトデザイン上の選択が次から次へと押し寄せてくる。
例えば、どのタイミングで課金メッセージを表示するのが適切か、アプリ名はA案とB案どちらがいいか、ある機能のデフォルト値をどちらにするかなどなど。
どちらにしたらいいかを悩んで、ああでもない、こうでもないと２つ３つの選択肢からどれがいいか考える。
そんな時、よく出てくるのが、「これはABテストしてみないと分からない」とか、「データがないと分からない」という反論しにくい最強のメッセージです。
しかし、これは数限りなく降り掛かってくる開発中の選択において、まったく現実的でない場合が多かったりする。
LeanAnalyticsの記事に書いたように、定量データは重要な意思決定に役立つ反面、ほとんどのケースはデータなしで決めないといけない。
まず、参考になるアプリのUIや定量データをかき集めても、アプリ開発でぶち当たるデザイン上の選択には不十分なことがほとんど。
基本的に不確実情報の中で決定しなければならず、本当に役立つ情報は実装してリリースした後に分かるか、リリースした後もよくわからない事が多い。
なので、「データがないと決定できない」だと開発が止まってしまうので、不確実情報の中で、こういう理由でこれがベターだろうという判断をして前に進むしかないのが日常茶飯事。
「この機能はつけようか、つけまいか、判断が難しい。。。」こんな時はよくあると思う。
でも、「よし、わからないからABテストしよう！」というのは現実的じゃない場合がほとんど。
というのも、ABテストするにはそれに伴う実装コストが必要で、決断を先送りすることによって失う機会費用もある。迷った時に毎回ABテストしていたら開発はまったく進まないので、ほとんどの場合はできない。
なにかをすることを決定したら、それをしなかった時にできる作業や開発の機会費用が失われるので、本当にその価値があるかどうかを考えないといけない。
そんじゃ、どうすりゃいいかとなると、地味に参考になるデータや実装事例を集めたり、行動心理の実証データを参考にしたり、自分で何度も考えるしかないと思う。
周りの意見を聞くのは悩んだ時に判断する重要な材料になったり、決めきれない時の後押しでさくっと決断するきっかけにもなったり。
UIやUXの専門家にコンサルしてもらうのも、実際にユーザーテストやデータ分析するより時間対効果が高かったという話もよく聞く。
いろいろ考えた先にいくつか選択肢が残り、メールマーケティングみたいにABテストがしやすい状況が生まれて、手間をかける価値がありそうだったらやればいいのではないかと。
それ用のサービスではOptimizelyとかいうのが最近iOSにも手を広げ始めたらしい。
先日Facebookのf8とかいうイベントがあった。僕は去年のf8はそこまで注目してなかったのだけど、Parseがf8に買収されたので今回は楽しみにしてました。
そしたら期待のParseからこりゃいいねという発表が２つあった。
ひとつはParseの料金体系が変わり、安くなったこと。もうひとつはオフライン時のデータベースを扱うParse Local Datastore。
特にLocal Datastoreはオフラインで使えるデータベースを実装しつつ、他のデバイスとの同期も実現したいモバイル開発者にとって死ぬほど期待の機能。ワクテカが止まらない。
なぜかAndroidのみ使えて、iOSは近日公開らしい。待ちきれん！
今までは月に一定の回数のアクセス以上は有料になりますよっていうシステムだったけど、今度は一秒間に30requestsまでだったらいくら使っても無料になった。
一秒間に40requestは月100$といった感じで、スケールしていったら高くなる。これはいいかも。ただ、気になるのはオートスケールしてくれるかってところだ。
ドキュメントを読むと、無料プランで制限を超えるリクエストが一秒間にあったらエラーが出ると。
じゃあ、普段は無料で余裕で使えてて、突然なんかの拍子でバズって、いきなりアクセス殺到してエラー連発だったら困る。こういう時に自動的にスケールして頂きたい。
でも、リミットはつけておきたいので、100$のプランにしておけば制限をその月に一回でも超えなければ自動的に無料になって、超える時があればその月は100$払うっていうシステムなんだろうか？
ここが気になる！Parseの新しいシステムでPriceの設定を見たりドキュメントを読んだかぎり、ハッキリとわからない。
100$のプランにするボタンがあるのだけど、このボタン押したら一気にその月に100$の請求来るのか怖くて試せない。
ということで、質問しておいた。
The 30 requests/second price plan can be scaled automatically?
※アップデート
残念ながらオートスケールしないみたい。100$のプランにすると、30req/sを超えてなくても請求くる。つねにエラーをチェックしてくれという悲しい返信がきた。
iPhoneアプリにデータベース機能をつける時はCoredata使うのが一般的なんだけど、アプリを他のデバイスでも同期できるようにする時に、Coredataをサーバ側のデータベースとシンクロさせるのが凄い手間。
データベースはサーバ側のみとすると楽だけど、それだと毎回読み込みが発生するので遅いし、オフライン時に使いかってが悪い。
アップル製品だけで同期すればいいという方針だとiCloudがあって、長らくぶっ壊れてて使えないと評判だったiCloud + CoredataもiOS7でいくらかましになったらしい。
でも、それでも構造上の問題でまだまだ鬼門だと海外の有名な開発者のブログとかで書いてました。僕は面倒なので、有名な人がまだまだ面倒だと言ってたら自分でチャレンジする気も起きずに悶々と過ごしてた。
理想はiOS側ではオフラインでもさくさくデータベースに保存できて、バックグラウンドでネットに繋がってたら自動で同期して、iPhoneとiPadがシンクロするといった形。
この問題で期待をしてるのが、ParseのLocal Datastore。
ParseのSDKって凄くよくできてて、データベースの実装とか本当に分かりやすく直感的なコードで書けるんですよ。
iOSのCoredataとかで書いたらすごく面倒なコードを長々と書かないといけないけど、ParseのSDKだと分かりやすくて短いコードでちゃちゃっと。
でも、Parseはもともとクロスプラットフォームで同期するためにサーバにデータをその都度送信する前提で作られてる。
一応、ParseのSDKにはキャッシュで保存する、saveEventuallyみたいなメソッドもあるんだけど、このキャッシュ機能は貧弱なもんなので、Coredata使った時みたいにはオフラインで保存して検索とか使うのは無理だった。
だから、iOSでオフラインでもサクサク保存したり、検索したり、フェッチしたりするには結局CoreData使わないといけないねっていう結論になって、iPhone/iPadで自動同期機能つけたい僕もCoredata使ってた。
で、Parseの掲示板見ても、サクサクオフラインで動くようにCoredataを使いつつ、同期機能のためにParseとCoredataを繋げる実装をみんな四苦八苦しながら頑張るという苦しみを訴えている人がたくさんいた。
Parseチームは、「今、この問題に取り組んでます。」とか一年前に書いてた。そして、一年ほどたって、Local Datastoreがやっと発表されたので期待せずにはいられない。
まだiOSには対応してないから試せないのが悲しい。出たら速攻で試したい。
Local DatastoreのAndroidのサンプルコード見た限りだと、普通にParseの保存、検索などの機能がオフラインでも動きますよといったように見える。
それだと、将来同期機能を予定しているアプリに、最初からParseSDKでデータベース作ってCoredataを代替できるようになるかもしれない。
CoredataとiCloudとか、CoredataとDropboxAPIとか、CoredataとParseを上手くつなげてシンクロ機能を上手く動かすというめんどいことが一気に解決しそうなので、これは期待するなというのが無理というものです。
LocalDataStoreのコメント欄には興奮した開発者たちが、「おお、これが出たらもうCoredataとParse繋げるために今苦労してる実装いらなくなるから、いつ出るか教えてくれ！」とかみんなも期待度マックスのようです。
その気持ちは本当にわかる。僕もTaxnoteやZenyでiPhoneとiPadの自動同期機能をつけたいんだけど、実装に入るのはこれが出るまでちょっと待とうかと悩み中。
この動画の14分55秒あたりからParse創業者の発表がある。Parseの料金体系、Local Datastoreの実際のコード、AppLinkとかのデモなどがざっと全部見れるので、オススメ。特にAppLinkのデモは一見の価値あり。
※Facebook Updates Parse With Lower Prices, Improved Analytics, Offline Capabilities
今年に入ってから毎日の開発時間を去年の半分にしてみた。
すると、毎日凄く集中できて、空いた時間に頭にスペースが出来てアイデアもわきやすく、効率もよくなったのでこれはいいかも。
最初のきっかけは、Rails作ったDHHが「開発なんて長時間やっても逆効果だから毎日の仕事時間を減らせ。8時間じゃなくて5時間、4時間だけにしろ。それだけ短かったらSNSなんて見てる暇はない。」とスタートアップスクールで話してたこと。
あと、去年タレブのAntifragileという本を読んで、短い仕事時間を毎日やるのが長期に渡っていいパフォーマンスを出す秘訣だというような事を言ってた。
アップストアでアプリを出すのは、結果が出なければ開発時間をいくらかけても価値が０となる世知辛い世界。でもこれは完全成果主義でなかなか面白い。
毎日の開発時間の成果をいかに上げるかっていうのを考えていると、時間を絞るってのが一番よいかなと。デザインも余白が重要で、その余白こそが大きな価値を持つので。
個人でアプリ作っているから時間配分は自由にできるけど、ずっと一週間単位、一ヶ月、一年単位で一番パフォーマンス出せる時間の割り振り方はなんだろうと試してきた。
特に強制する人がいないからいつでも休めるので、ノルマというものを作ってた。例えば、週に40時間とか。そこで、毎日開発する時間をストップウォッチで計って、今日は6時間進めたとか、昨日は遊びに行ったから出来なかったから今日多めにやろうとか。
でも、同じ時間をやっても、今日は全然集中できてなくてあんまり成果でなかったなあとかよくあった。
同じ時間でも、疲れているコンディションとか、眠いとか、集中してない環境とか、その時々の状況によって成果がバラバラ。
最初の数時間は集中してても、時間がたつとだんだんと密度が薄まっているのがなんとなくわかる。
で、思い切って、集中してやるのは一日3時間までの制限にして、それを休日はなしで毎日やるというルールにしてみた。
実験的に極端なことやってみたけど、ここまで短いと、いかにその時間に最大限のパフォーマンスを持っていかねばならんと必死になる。
まず、一日の一番集中できる時間は朝起きてすぐなので、ぐっすり寝て、起きてすぐ開発することになる。メールやニュースも見たら気になるので、終わるまで一切見ない。朝ご飯は水かバナナ。
ダラっとすると貴重な時間がなくなるので、SNSも絶対見ない。毎日朝に重要な公式戦があって、その時間に最大限集中できるよう準備するスポーツ選手みたいな真剣度になる。
一日にまとめてやった９時間と、極限まで集中してフレッシュな状態でやった３時間×３日の９時間だと、合計時間が同じでも時間当たりの開発の密度や成果が段違いに違った。
これは新しい発見だったけど、時間が短く指定されると、なにに時間を使うかを今まで以上に真剣に考えるようになる。
開発のTODOリストを作る時も、ここは今やるべき価値があるかとか、今日時間使う意味あるかとか。
数ある重要なタスクの中で、今日やる部分は本当に現時点で最優先するべきなのかを凄く真剣に考えるようになった。以前も考えてたけど、時間が限られてるからその緊迫さが月とスッポン。
プログラミングしてる時はなにかでハマることが多いのだけど、時間がすぎて次の日になったら新しい角度で検証する方法がころっと出てきたりして、何もできずに時間が過ぎる事がなぜかなくなった。
でも、ハマるとムキになってしまって、悔しくて寝れなくなるので、ついついルールを破って延長してしまう時もたまにある。このムキハマり現象が一番の敵だ。おのれとの戦い。
で、そんな時に時間たってもあまり成果がでなくて、一晩寝ると別の方法が思いついて解決したりする。
後はあっさり諦めて次に進んで後から思い返すと、そこまで時間をかける価値がなかったなと冷静になったり。
また、一日を過ごす上で頭の中に余裕ができる時間ができたので、今やっている作業を違う角度で見たり、新しいアイデアを考えやすくなった気がする。
作業中は夢中でやってても、時間を置いてみたら、「あれは優先度そこまで高くないから、あそこまで時間かける意味はなかったな・・」と冷静に振り返る時間が増えたり。
このやり方の問題点は、いい感じにフロー状態に入った時にタイマーがなって、「もうちょっとやりたい。。」ってしょちゅうなること。
一日の開発時間が短すぎると平日はなんか暇なので、ついついもっとやってしまう時がある。
ただ、延長してしまうと、それに慣れてしまって、フロー状態に入るスピードも下がって、延長すればするほど時間単位の集中度クオリティが下がるのもわかる。
悩ましい。
ただ、一週間ぐらいだと、倍働いた方が量の違いで成果は出るかもしれないけど、二週間以上や一ヶ月以上で見ると、全体の成果は短い時間のほうがよい気がする。感覚的に。
以前は、ずっと仕事するのは嫌だから、早く引退して遊んでくらしたいなあと思ってた。
でも、短い時間で毎日やるなら一年ずっとやっても特にストレスたまらないし、一生続けてもよいかもと思った。これも予想してなかった新しい感覚。
今はハードに仕事して将来楽するぞっていうのより、マラソンみたいにずっと一定のペースでやりたい性格なので向いているのかもしれない。
Copyright © 2025 うめのんブログ
Theme by Anders Noren — Up ↑
