Runner in the High

技術のことをかくこころみ

千葉からの通勤

年明けに書いたこの記事で触れていたように、もともと住んでいた江東区から千葉県にある母親の実家へと引っ越した。

izumisy-tech.hatenablog.com

引っ越すにあたって、朝のラッシュがどんな感じなのかネットで調べてもいまいち要領を得ない感じなので、実際に自分が初日に職場のある六本木一丁目駅へ通勤してみてどんな感じだったかを、実録ドキュメントとして残すこととする。

ちなみに、住まいは新京成電鉄沿線である。

7:50~ 新京成電鉄津田沼

  • そんなに人は多くない。座れはしないが、車内が一杯というわけでもない。
  • 前原・薬園台からの乗り込みが意外と多い。
  • 新津田沼駅から降りた人たちはみんな脇目もふらずに津田沼駅へ向かっていく
  • 新津田沼駅に近づいてくるとホームの人の多さにギョッとする。とくに都心(新橋・錦糸町)へ向かう方向がすごい。
  • 津田沼駅の改札は、東京へ向かう電車がでているだけあって、さながらその光景は東京に勝るとも劣らない様相を呈している。学生の頃は井の頭線を使っていたが、ラッシュ終わり頃の井の頭線渋谷改札と同じくらいの混みよう。 ​

8:12~ 総武横須賀線で新橋へ

  • ホームで相当に混んでいたにも関わらず、実際にのりこんで見るとそんなに混んでない… が、行き先を見ると真逆に進んでいることに気づく。稲毛まで飛ばされてしまった。
  • この時間になると稲毛駅はガラガラ。もし稲毛駅に住むのであれば、この時間にもう余裕をもって座れるんではないかと思う。
  • 8:28ごろにようやく大船行きの総武横須賀線稲毛駅から乗り込む。この時間になるとラッシュを脱したらしく、普通に立てる程度の混雑。
  • 8:37の津田沼は乗り込んでくる人がそんなに多くない。逆に稲毛から乗ってみると降りる人が意外に多いのに驚く。
  • 8:53に新小岩到着。市川・新小岩あたりで乗車率がかなりキツくなってくる。
  • 錦糸町でドカッと降りていくも、そこそこ混雑している。が、そんなに乗り込みは多くない。 ​

その後

  • 新橋に着くと思ったら東京駅で止まってしまった。仕方ないので丸の内で四谷へ行き、そこから六本木一丁目へ向かった。
  • 9:37に乗り込む南北線がめちゃくちゃに混む。大勢が溜池山王で降りる。

後日談

  • この日の総武横須賀線はまだよかったほうで、また別日にはがっちりと車内でスクラムが組まれて、中に乗り込むのすら困難な日もあった。引っ越し初週ということもあり、会社には9:00~9:30のペースで出勤をしていたが、ラップトップなどの大事なモノ持って通勤する際にはもう少し遅めの時間に乗り込もうと思う。

  • 弊社にはあまり千葉方面在住の人間が多くなくナレッジ・シェアリングがしづらかったが、葛西に住んでいる先輩によると、9時台に乗る東西線は比較的余裕を持って立てる程度の混みようとのこと。

  • この引っ越しによって通勤時間は1時間半となったが、慣れとは恐ろしいもので、最初は「長すぎかもなぁ。耐えられるかな。」と心配していたものの、今となってはスマホをいじってポッドキャストを聴いたりしているといつの間にか着いている、というような感覚になってしまった。良くも悪くも現状に満足してしまうタイプの人間であることが功を奏したと言える。

  • せっかく遠くに済んだのだからリモートワークはどうなんだ、という話もあるが、おいおい余裕が出たらしてみたいと思っている

2019年の抱負、そして2018年を振り返る

今週のお題「2019年の抱負」

■ 2018年の出来事

 去年は各月の出来事を垂れ流して書いていたがめんどくさいのでやめた。今回は出来事を箇条書きスタイルで。

大学を卒業した

 大学を卒業した。ギリギリまで単位が足りているのかわからない状況で、教務課に問い合わせても「最終的な判断はご自分でしていただいて...」みたいな雑な回答しか得られず非常にフラストレーションが溜まった。

 こういう作業こそコンピューターで自動化して「あと〇〇の単位がいくつ足りません」みたいなのがリアルタイムで分かるようにすべきだろうが、と思った。とはいえ、練馬区の極小中堅大学にそんな文句を言っても仕方がない。もう卒業したしどうでもいいや、という感じではある。

 英文科的な所属であったのに、英語で本格的に教授とディスカッションしたのがこの大学4年生の頃だけだったのがなんとなく情けない。まあ、これも自分の大学選びが悪かったとしか言えない。

ひとり暮らしを始めた

 江東区に住み始めた。実家は世田谷区なので、なぜいまさら江東区なぞに...という感じではあるが、自分はミーハーなので清澄白河駅周辺に住みたいという欲求がとても強かった。

 また、実家は単なる集合住宅であり、成人4人が住むにはもはや狭すぎた。また、やはり人生経験としてひとり暮らしをしたいというのも個人的な願望としてはあったのだ。本当は高層階タワーマンションに住みたかったが、自分の収入と照らしあわせて最終的に見つけることのできた物件はあまり良いものではなかった(後述)

社会人になった

 Fringe81株式会社に入社した。 www.fringe81.com  10社くらいインターンに参加して、最終的に最高な会社だったなということでここに決めた。正直、なぜ自分がFringe81に決めたかという話は、軽く話してしまうともったいない気がしているので時間を取って書こうと思っている。が、あっという間に一年目が終わってしまいそうなので焦っている。

 入社してからは主にScala, Golang, Elmを書いている。もともとJavaScriptRubyばっかり使っていた身からすると、相当レベルの高い言語を書いているなという感じがする。決してプログラミング言語に優劣をつける気はないけれど、正直動的型付けよりも静的型付けの言語のほうが思想が深いと感じている。特にScalaなんか正にそうで、型システム自体がめちゃめちゃ深い。そして行き着く先はモナドだと思う。ここはまだまだ全然自分の中で咀嚼できていないことだらけなので、根気よくやっていきたい。

 Elmに関しては非常に自分の中で好き度が増している。とくにReactやVue界隈のどこまでいっても道具選びで消耗している感から解放されている感じがよい。Elmアーキテクチャというデ・ファクト・スタンダードが決まっているのもよい。社としてのプロダクトづくりの前提としてElmを選ぶという決定ができるというのはすごく喜ばしいことだと思うし、自分がElmを学ぶ必要に迫られるきっかけがあるというのはとてもありがたいと思っている。

海外出張に行った

 弊社がWebSummitへ参加するということで、人生で始めての海外出張へ行った。というかそもそも社会人が初めてなので、そりゃ初めてで当然という感じではある。 fringeneer.hatenablog.com  人生発ヨーロッパでもあったけど、現地のカンファレンスで話した言語は英語だったのでとくに問題はなかった。これまで英検準一級まで取った甲斐があったな、というくらいたくさん英語が話せたのでとても満足した。大学ではスペイン語を勉強していたものの、ポルトガル語は微妙に違うところがたくさんあり、そしてそもそも単位をほぼCで取得していたのでまったく役に立たなかった。単語は節々にそれっぽく分かるものがあった程度。

 帰りのトランジットで降りたパリが正直汚くて萎えた。リスボンは町並みやら気候やら、食事がとても自分にあっていた気がして、ちょっと暮らしてもいいかもなと思ったりした。

■ 学んだっぽいこと

2018年で学んだっぽいこと。こう書くといろいろある。

アプリケーション設計

 例えば大量のトラフィックを捌けるようなアプリケーションを設計する、という状況になるとして、アプリケーションの特性に応じてI/Oがボトルネックになるのか、CPUがボトルネックになるのかなどの勘所が学生の頃よりは持てているような気がする。弊社はGCPを使ってマイクロサービスっぽい構成でアプリケーション開発をしているが、Cloud Pub/SubやTaskQueueがどういった理由で必要になるのかというのは今思えば去年は全くもって想像できなかったんではないかと思う。

 また、適切なモジュールの責務分割と、それにまつわるユニットテストを書くことにすごく重要性を感じるようになった。これまでは、モジュール間の粗結合性をコードレベルでどう生み出せばいいのか、という知識が足りてなかったため、実質的にユニットテストをあまり意味のないものだと思っていた。だが、例えば「クリーン・アーキテクチャ」や「オブジェクト指向設計実践ガイド」などを読み込んでいくことで、複数モジュール間の依存関係をどのようにして粗結合な実装として表現すればいいのか、という概念的な知識がついてきた。特にこの2冊は「いかにして変化に強い設計にするか」という目的に向かってたくさんのヒントを提示してくれた。

 自分ひとりで作っているようなアプリケーションは結局作ったら作りっぱなし、という場合がほとんどであったけれども、業務でお金を生む機械として作るアプリケーションには、非常に多くの変更が加えられる。うれしいことに、ユーザーが比較的増えつつあるサービスを作っているだけあって、先輩たちから指導を受けながらアプリケーション設計を実践する機会がたくさんあったと言える。

新しい言語のパラダイム

 ScalaやElmは自分にとって本当にパラダイムシフトになった。

 自分が初めて使ったプログラミング言語はCだったが、そのときは「型付言語ってめんどくさいな」という気持ちが強かった。それもあってActiveBasicやらHSPに逃げたりしていたところもある。けれども、RubyJavaScriptを使ってある程度の規模のSPAやらサーバーサイド・アプリケーションを作ってきた過去を少しでももっていると、型があるということでどれだけの凡ミスやそれにまつわるランタイムエラーを防げるかがとてもよく分かった。

 が、逆に動的言語には動的言語なりのよさ(たとえばダック・タイピングとか)があり、自分の中でそういう考え方を失ってしまうのもそれはそれでもったいないと思うところがある。その点Golangはすごくちょうどよい。Interfaceでダックの実装をある程度約束できたり、動的/静的型付の良さをうまく折衷できている感がある。ポインタやリフレクションがでてくるとすぐランタイムエラーまみれのコードを書いてしまえるのが少し気になるが。

人間の死臭

 隣人が孤独死したので、その死臭を嗅いだ。なかなか人間の死臭を嗅ぐ機会もないだろうということで、これもある意味学びなんではないかと思う。

 死んでいるのがみつかったのも真夏の結構暑い時期で、どうやら1ヶ月程度は放置されていたらしい。古い物件だということもあり、隣の部屋にインターホンがなかったため面倒くさがって自分は入居の挨拶をしなかった。が、どうやら何らかの病気を患った人だったらしい。弊部屋の壁は本当にペラペラなので、隣の部屋からゴホゴホと咳をしている音が頻繁に聞こえてきた。さすがにちょっと心配になっていたが、今思えばもうちょっとお節介だったら助かっていたのかもしれないなと思うことはある。

金が金を生むということ

 株やクラウドレンディングに手をいくつか手を出した。

izumisy-tech.hatenablog.com

 現時点で、少額だが100万を超える金をクラウドバンクで運用している。見方によっては、どちらかといえば新興の金融商品であるクラウドレンディングだけれども、個人的にはわりとおもしろい資産運用だと思っている。毎月5000円程度の不労所得でポケットに入ってくるのも嬉しい。とりわけクラウドレンディングでお金を運用してみて良かったなと思うのは、よく言われる「金が金を生む」とはどういうことかが分かってきたところにある。

 ロバート・キヨサキの「貧乏父さん金持ち父さん」の最初の章に頻繁に出てくるフレーズとして「金持ちは負債ではなく資産を買う」というものがあるが、結局そのとおりなんだろうなと思っている。自分の収入の大半で資産を買い、残ったお金で慎ましく生活するというのが、4月から社会人になった自分の生活だった。ともすれば、ゲームやら服やらをたくさん買ったり、毎月旅行に行ったりしてお金をいくらでも散財できるが、そういうものにあまり興味が湧かないというのは、わりかし自分でも得な性格だなと思うところがある。せいぜい買ってもプロテインか本くらいなもので、それ以外は散歩でもしてれば大体満足する。

■ その他

基本情報技術者試験に合格した

f:id:IzumiSy:20190104202041p:plain

 自分は文系のバックグラウンドであるため、ある程度情報工学の素養をつけるために受けてみた。毎日チビチビ勉強をするのは、なんとも懐かしい気持ちになった。

そこそこQiitaの記事を書いた

 27記事書いていたらしい。 qiita.com  「今年は100記事書きたい」みたいなことを言っていた記憶があるものの、それには遠く及ばなかった。一部のエンジニア界隈ではQiitaはオワコン、みたいな風潮が散見されるが、いまだに日本語のプログラミングに関する情報についてはQiitaが量的には一番ではないかと思う。自分の場合には毎回英語を使って調べることが多いので、あまり検索結果上でQiitaに遭遇することはないが。

■ 2019年の抱負

目下次の2点かなという感じ

もっと徹底的に節約する

 まずひとり暮らしをして思ったのは、やはり「ひとり暮らしというのはコスパが悪い」ということ。

 どこで聞いたのかは忘れたが「都内のひとり暮らしは最高の贅沢である」という言葉はあながち間違いじゃないなと思わされた。今住んでいる物件の家賃は8万であるが、もはやこの8万を払っていることすらもったいない。ということで今年は早々に物件を引き払い、千葉にある母親の実家に居候をする形にしようと考えている。通勤時間が伸びたところで、その分自由になるお金が増えるのであれば大した話ではない。単純計算で毎月8万の家賃を12ヶ月支払っているということを計算すれば、毎年約100万円をドブに捨てているということが分かる。ケツを拭く紙にすらなっていない。これは確かに最高の贅沢だ。

本をもっと読む

 2019年にはビジネスモデルや不動産、税に関する知識をもっと深めたいと思っている。

 不動産投資関連の本を読んでいて思ったのは、不動産にまつわる節税スキームは日本の税制の歪みを利用しているものが多いということ。結局それらをうまく利用できるかできないかは、自分自身がどれだけ知識をもっているかにかかっている。不動産に限らず、社会人として生きていく上で比較的重要とされる世の中の仕組みは、そのほとんどが学校で学べるものではないし、知っているかどうかで大きく生き方に差がでるのではないかと思うことが多くなった。ビジネスモデルもまた、社会の仕組みの隙間の落穂を拾うような形で生まれているものがあったりと、相互関係にあると思っている。

Maybeに代えてカスタム型を使う

 ElmのMaybeはデータの有無を型で表現できるゆえ非常に便利なものであるが、文脈が失われるため無闇に使い過ぎるとワケがわからなくなる。ケースによっては、カスタム型を使うことによって型でデータの有無を Maybe に代えて表現するほうがよりメンテナブルにある可能性がある。

前提

 ユーザーログインの機能を持つTODOアプリを開発している。

 上記の仕様から、おそらくモデルに currentUser: User みたいなフィールドと TODO を表す todos: List Todo があるだろうと言うことは容易に想像できる。 だが、実際には「ログインしていない」と「ログインしている」のふたつのコンテキストを表現しなければいけないため、両方とも Maybe になる。ログインしていなければ両方共 Nothing になる。

type alias Model =
    { currentUser: Maybe User
    , todos: Maybe List Todo
    }

 正直ここの Maybe は苦しい。なぜならこの Maybe は文脈を持っていないからだ。

 例えば、ログインに失敗して Nothing なのか、純粋にまだ TODO を一個も持っていないから Nothing なのかは、ここでは分からない。 ユーザーがログインに失敗したから Nothing なのか、まだログインしていないから Nothing なのかも、判断が難しい。場当たり的な処置として Result 型を使う手もある。だが、結局文脈をもたない Maybe はコードを書く側が頑張ってその文脈をコード・リーディングしながら紐解いていくことになる。これはまず大変だし、バグを生む可能性がある。

 ではログインにまつわる文脈を持たせましょう、ということで LogInStatus 型のデータを与えると以下のようになる。

type alias Model =
    { currentUser: Maybe User
    , todos: Maybe List Todo
    , logInStatus: LogInStatus
    }


type LogInStatus
    = NotLoggedIn | LoggingIn | LogInSucceeded | LogInFailed

 これでモデルにログイン文脈のデータが与えられたが、それでもまだ苦しい。

 それぞれの Maybe の結果は LogInStatus と独立しているため、開発者のうちひとりが LogInSucceeded の状態であるにも関わらず currentUser を Nothing のままにしているなどのコードを書いてしまう可能性がある。ログインが成功しているのにユーザーがいない、というのはまず仕様としてもおかしい。

カスタム型で仕様を表現する

 Elmは型付言語なので、仕様を表現するような型制約を設けるのがよい

 たとえば、以下のようにデータが前提としてログインの状態に紐づくようにすることによって Maybe を使わずに currentUsertodos の存在有無を表現できる

type alias UserData =
    { currentUser: User
    , todos: List Todo
    }

type Model
    = NotLoggedIn
    | LoggingIn
    | LogInSucceeded UserData
    | LogInFailed

 このコードであれば、まずログインが成功していない限りユーザーも、TODOも存在していないということが型レベルで表現されるため、もとのコードにあったような Maybe の結果とログイン状態が食い違ってしまうようなコードを書いてしまうのを防ぐことができる。

基礎からわかる Elm

基礎からわかる Elm

  • 作者:鳥居 陽介
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2019/02/27
  • メディア: 単行本(ソフトカバー)

2018年で最も早くTypeScript+Reactのアプリを作る方法

結論から言うとこれです。

$ npx create-react-app myapp --typescript

create-react-app で --typescript オプションが公式にサポートされたということで、例えば以下の僕が昔 Qiita で書いた時に使った react-scripts-ts みたいなジェネレータ・スクリプトよりもこのオプションを使うほうがいいかと思います(絶対ダメ! というわけではないけど、公式のほうが安心感がある気がするので)

qiita.com

ちなみにこの --typescript オプション追加の PR は以下です

github.com

ちなみに、この PR で TypeScript のテンプレートが create-react-app の中にコミットされけど、これが react-scripts-ts のコピーなのかどうかは分からない。似てる気はするけど、コメントなどで言及もないしたぶん違うかな。

gpd-pocket-ubuntu-respinの更新を適用したらファンが止まらなくなった

本日久しぶりにGPD Pocketのコミュニティパッチを更新して適用したところ、まだ44℃だというのにCPUファンが思いっきり回転しはじめた

おそらくこれはファン周りのデーモンかなにかがうまく動いてないな...ということでおもむろにログを確認

 $ journalctl -u gpdfand.service 
-- Logs begin at 金 2018-08-24 17:54:08 JST, end at 金 2018-08-24 18:06:16 JST. --
 824 17:54:10 izumisy-gpd-pocket systemd[1]: Started GPD Fan Daemon.
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: Traceback (most recent call last):
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 78, in <module>
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     set_fans(1,0)
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 46, in set_fans
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     gpio.write(unicode(a))
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: IOError: [Errno 1] Operation not permitted
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Main process exited, code=exited, status=1/FAILURE
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Unit entered failed state.
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Failed with result 'exit-code'.

変更を遡って見てみると、どうやら以下の変更でIOErrorが起きるようになったっぽい?

github.com

いったんコミットを 7813b8a まで戻して再び更新を適用

$ git checkout 7813b8a
$ ./update.sh

これでとりあえずはファンが静かになった

Golangではinterfaceはどのパッケージに属するのか

Golangを使い始めてinterfaceでDIPっぽいことをしようとするとたしかに湧きがちな疑問のひとつ。結論から言うと、interfaceはそれを使う側のパッケージに所属させるのがセオリーらしい。なるほど。

Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values.

CodeReviewComments · golang/go Wiki · GitHub

なぜか

せっかくなので理由を考えてみた。

以下はJSONXMLなど複数のフォーマットでログを出力できるロガー・アプリケーションのクラス関係図の例。 このアプリケーションの設計は、中核となるLoggerクラスと具体的なXMLJSONなどへのシリアライザ実装がそれぞれISerializerインターフェースという抽象に依存している典型的なDIP(依存性逆転)だ。LogParamsクラスは、ログとして出力するデータの内容を保持しているものとする。

f:id:IzumiSy:20180819114326p:plain

それぞれ、黒矢印は「利用」、白矢印は抽象に対する「実装」、点線の矢印は「依存」を表している。

まず、このアプリケーションにおいてserializerパッケージというのは「どのように出力するか?」のHowが所属するレイヤであり、一方でmainパッケージはアプリケーションのビジネスロジックとして「なにをするのか?」のWhatが所属するレイヤにあたる。

そう考えると、具体的な実装を持たないinterfaceであるISerializerが、「出力の方法」を責務として所属させるべきserializerパッケージにいるというのは違和感がある。なぜならinterfaceは単なる「使い方」を示すだけのものであって具体的な実装を持つものではないのに、Howが所属するパッケージにいるからだ。このような理由で、interfaceはそれを使う側に配置するのがよい、というプラクティスに合点がいく。

(ちなみにではあるが、そもそもこの関係図だとmainパッケージとserializerパッケージが双方向依存になっているため、Golangではコンパイルの時点でエラーになってしまう)

f:id:IzumiSy:20180819115021p:plain

ということでISerializermainパッケージに所属させる。

パッケージ内での依存関係はいくら循環していようと構わないので、これは問題なく動作する。また、ISerializerインターフェースが実装先のパッケージから切り離された。これで正しく「使う側」に所属させることができた。

DDD的な観点: 例えば今回のISerializerに当たる部分が、DDDでいうところのリポジトリであると考えてみる。そう考えると、リポジトリドメイン層のインターフェースに当たる部分なので、リポジトリの具体的な実装のパッケージにそれが所属するのは解せない、というのがしっくりくる。意図せずここで不思議なつながりが見えた気がする(?)

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

依存関係について再び考える

izumisy-tech.hatenablog.com

  • あとからこの過去記事を読み返して「ムム」と思うところがあったので改めて。

  • CategoryId ではなく Category を引数として渡すことでデータ構造が隠蔽されているという旨の説明をしているが、これは fetchArtclesByCategory を呼び出す側の責務が「Categoryの データとしてIDが取れる」という知識を持ってしまうのを防げるという意味で書いたのではないかと思う。

  • けれどもその実装だと、結局 fetchArticlesByCategory 関数側が、引数として受け取る Category からIDを取り出すという処理をせなばならず、ID呼び出しでないという設計指針が fetchArticlesByCategory に対して Category への依存を与えてしまっている。

  • この依存が別に構わないという可能性もあり、たとえば Categoryドメインモデルなのであれば、そのドメインモデルに対して単方向の依存を持つクリーンアーキテクチャ的観点でいうところの外部のレイヤとして fetchArticlesByCategory が存在していると考えることもできるので、さほど問題を感じなくなる。

  • ところで fetchArticlesByCategory 関数を呼び出すのは、アプリケーションの責務のうち誰になるのだろうか... またまたクリーンアーキテクチャを考えてしまうが、おそらくユースケース層ではないかと思う。

  • DDD的観点: CategoryId を渡す場合においての別の懸念点としては、もしも CategoryIdCategory という集約ルートにおける値オブジェクトだとしたら、それを CategoryId 単体で受け取ってしまえるインターフェースもった関数 fetchArticlesByCategoryId があることで、利用者によって不変条件を保たずにつくられたおかしな CategoryId が渡ってくる可能性があるのではないかということ。正直ここは実装の問題のような気もするけど...

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

クラウドバンクをやっている

OneTapBUYをやっていたときもこういう記事を書いていたので今回はクラウドバンクについて書く

izumisy-tech.hatenablog.com

つい最近クラウドバンクも始めた。いまのところ投資額はOneTapBUYと同じくらいだが、パフォーマンスで言うと年6〜7%といったところらしく、さほどリスキーではなさそうな利幅でよろしいと思う。こちらもどういう風にお金が増えるのか楽しみだ。

ちょうどこの記事を書いた2017年の10月から始めていた。結論からいうと、自分のクラウドバンクのパフォーマンスは年利で3.8%という感じになっている。

f:id:IzumiSy:20180805121827p:plain

今現在で80万程度つっこんでいるわけだが、それで増えたのが1.8万くらい。こう見るとOneTapBUYにもっとお金を突っ込んでいたほうが今頃には利益がもっと出ていたかもしれない。

2017年の10月の記事ではOneTapBUYでは12万で1万の利益がでている! みたいに書いたが、その翌月には5000近くまで下がってしまっていた。もちろん株なんてものはそうやって上がったり下がったりするものではあるが「こういうの、いつも気になってしまってソワソワしてしまうな〜」という感覚を持った。その当時はまだ学生で毎月定期的な収入があるわけでもなかったため、いわゆるドルコスト平均法のような積立戦略を実践するにも難しさがあり、短期的な売買に終始していたからという理由もある。

その点クラウドバンクはある意味ただの投資に近いので、自分の利益が上がったり下がったりするのを見る必要はないし、そもそも見えない。預けたものに毎月分配金がつくだけでシンプル。見方を変えれば、株と違って自分で取捨選択をしている感覚がないので、地味といえば地味ではある。とはいえ、社会人にもなるとそんなに毎日自分のポートフォリオの上がり下がりを見ている余裕はそんなにないので、どちらかといえば勝手に誰かがやっていてくれるほうがうれしいというものだ。そういう理由もあって2017年の11月にはOneTapBUYで投資していた分を5000円プラスで売却し、クラウドバンクに突っ込むことにしたのだ。

f:id:IzumiSy:20180805122942p:plain

ココ最近のペースでは毎月3000円くらいの分配金が入ってきている。毎月一回くらい飲み会にタダでいける程度ではあるが、それでもこうやってお金が増えていく様子をみるのはうれしいものがある。