i_amaiの雑記

お金稼ぎが目的のブログです

若い世代に知ってほしいお金の常識5選

どうも、こんにちは。日商簿記2級持ちのi_amaiです。

ブログを書き始めて、まあネタ探しと言いますか、ライティングスキルをつけるにはどうしたら良いのかなーとか考えながらいろいろと他所さまのブログを巡回していると、ふと気づくことがあります。

「あれ?これって常識だと思ってたけど、もしかして知らない人多いんじゃね?」

…と。

f:id:i_amai:20180819131726p:plain

若くしてお金稼ぎたいブロガーの方ってたくさんいると思うんですけど、なんかお金の知識に関して混同している人が結構多かったので、そういう話を今回はしていこうかなーと思います。

なお、専門的な知識を得たい方はごめんなさい、別をあたってください。また、当方は専門家ではありません。間違っていたらコメント等でご指摘いただけると幸いです。

1. 売上と利益は違う

ざっくり言うと、

売上
サービスに対しお客が払ってくれたお金
費用
サービスを運用するのにかかったお金
利益(損失)
売上 - 費用

こんな感じです。売上は原則プラスですが、売上より費用が多ければ、利益はマイナス、つまり損失になることもあります。

知ってか知らずか、売上を殊更にクローズアップして損益(損失または利益の額)は教えてくれない人がいます。こういう人の言うことは信用してはいけません

まあ、売上は損益に比べると計算するのが簡単なので、使いたくなる気持ちは分かるんですけどね。

ついでに、丸儲けって言葉がありますよね。儲けとは利益のことです。よって丸儲けは、売上の全てが利益になる(費用がかからない)という意味ですね。豆知識。

2. 決算とは

桃鉄で、毎年3月のサイコロを振り終わると、電車がピューっと横切ってでかでかと出てくる「決算」の文字。

あれはなんなのでしょう?世間の会社は決算において何をしているのでしょう?

ざっくり言うと、決算とは、

一定の期間内のお金の出入(支出と収入)を計算して、損益の額を確定する手続き

です。

期間の違いによって、月次決算、四半期決算、年次決算と呼び方が変わります。桃鉄のは年次決算ですね。

決算によって作られるのが財務諸表で、財務諸表の代表が貸借対照表損益計算書です。

3. 貸借対照表とは

ざっくり言うと、

ある時点での会社の持っている全財産のうち、どれくらいが借金か

をあらわした表です。

全財産は現金、原材料、土地や建物、株、その他お金に代わるもの全てです。これを資産と言います。

借金は負債と言います。

そして、資産 - 負債、つまり借金以外の資産を純資産と言います。

よって、以下の式が成り立ちます。

純資産 + 負債 = 資産

ただの式の変換ですが、大事な考え方です。

ここまで分かったら、googleで画像検索してみましょう。

表の左側に「資産の部」、右側上に「負債の部」、その下に「純資産の部」と書いてあります。

そして、表の一番下の額が左右で揃っていることを確認してください。

これは、資産(全財産)は左の額。資産のうち負債(借金)と純資産(会社のお金)の割合がそれぞれいくらで、その合計が右の額。そして左右の額は釣り合っているよ、同額だよ、ということを表しています。

これが「対照」表と呼ばれる理由です。英語でbalance sheetと呼ばれるのも同じ理由からです。

(なお、「貸借」については、あまり気にしない方が幸せだと思います)

4. 損益計算書とは

ざっくり言うと、

ある期間の売上がいくらで、費用がいくらで、じゃあ損益はこれくらいだよね

をあらわした表です。

売上 - 費用 = 損益(プラスなら利益、マイナスなら損失)

俗に言う赤字は、損益計算書で算出された損失のことです。

また、貸借対照表が「ある時点のモノ・カネの状態」を表現しているのに対し、損益計算書は「ある期間の経営成績」を表現しています。なので、損益計算書で一定の損益が出ているからといって、直ちに倒産したり、資金繰りが改善したりということはありません。

例えば、貸借対照表上で負債の割合が高ければ、その期の損益計算書が大きく黒字でも負債の返済に大きく充てることになるでしょうし、逆に負債の割合が低くても、持っている資産の状況(土地建物が資産の多くを占めていると直ちに現金化できない)によってはやっぱり資金繰りが悪化することも考えられます。

5. 株式会社は貸借対照表(および損益計算書)の公告義務がある

会社法第440条の規定により、すべての株式会社は貸借対照表の少なくとも要旨を公告する義務があります。

「公告」とは広く一般に知らせることですね。小さい会社であれば、官報に記載する場合が多いです。

ところが、この事実はあまり認知されていないらしく、罰則も無いのかな?よって、小さな株式会社では公告していないところも多いみたいですね。

幸い私の所属している会社は公告していて、当期純利益なども確認できました。「会社名 決算」で検索するとだいたい引っ掛かりますので、自分の会社の将来が気になる方は、一度貸借対照表を見てみてはいかがでしょうか?

f:id:i_amai:20180819131134p:plain

まとめ

こんなの知ってるよ!という声が飛んできそうです。余計なお世話だったかもしれません。

知らなかったよ!という方がもしいらっしゃったら、見かけの数字に騙されないように、会計の知識は付けておくことを強くおすすめします。インターネットは情報であふれていますが、そこには必ず意図があり、あえて公開される情報と隠される情報とがあります。

気を付けて、ご安全に、賢くお金を稼いでいきましょう。

叱咤激励のコメントをお待ちしております。

それではこの辺で。

Ubuntu Server 16.04で無線LANに接続する

十数年前の機種で、長らくホコリをかぶっていた、東芝Windows XP 32bitラップトップ。

この度Ubuntu Server 16.04をインストールするために引っ張り出して、まあインストールはなんとかうまくいったのだけど、自宅の無線LANに繋ごうとしたらハマったのでメモ。



基本的には、下記ページのstep 2:以降を参照すればよさげ。

www.linuxbabe.com

無線LANインターフェースの名前を調べる

iwconfig無線LANインターフェース(NICなど)の名前を調べる。Access Point: Not-Associatedとなっているものを使う。

iwconfig

ここではwlan0が見つかったものとして進める。

インターフェースで利用可能なESSIDを調べる

sudo iwlist wlan0 scan | grep ESSID

と打つと、利用可能なネットワークのESSIDが一覧で表示される。

ステルス済みのESSIDはもちろん表示されない。

ここではhoge_ESSIDを利用するとして進める。

なお、ESSIDはネットワークを識別するためのIDであり、APを識別するIDではないことに注意。下記ページ参照。

www.infraexpert.com

wpa_supplicantのインストールと設定の書き込み

認証にwpa2を使用している場合は、wpa2サプリカント(認証クライアント・ソフトウェア)であるwpa_supplicantが必要。

sudo apt-get install wpasupplicant

自分の環境ではプリインストールされていた。

wpa_supplicantwpa_supplicant.confという設定ファイルから接続するネットワークに関する設定を得る。

wpa_passphraseでpskを暗号化して、wpa_supplicant.confファイルを生成し、パイプで渡して書き込む。

wpa_passphrase hoge_ESSID huga_passphrase | sudo tee /etc/wpa_supplicant.conf

ESSIDをステルスしている場合は、生成されたwpa_supplicant.confscan_ssid=1を入力する。

sudo vi /etc/wpa_supplicant.conf

network={
  ssid="hoge_ESSID"
  #psk="fuga_passphrase"
  psk=0123...       # wpa_passphraseによる生成
  scan_ssid=1       # 入力する
  ...
}

なおこの設定では、指定されたESSIDをもとにエリア内にprobe request frameをブロードキャストし、応答のあったAPとその後通信するみたい。

mrncciew.com

よく「ステルスSSIDはセキュリティ上効果はない」と聞くことがあるけど、こういう仕組みがあるからなんだなぁ。

wpa_supplicantで接続を試みる

sudo wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0 -B

-cは設定ファイルの指定、-iはインターフェースの指定、-Bはバックグラウンドで動かすためのオプション。

ここまでで接続が成功していれば、

iwconfig

wlan0Access Point:に今繋がっているAPのMACアドレスが表示されるはず。

DHCPサーバーからIPアドレスをもらう

上記の状態で、

sudo dhclient wlan0

とすると、IPアドレスを割り当ててもらえる。

ifconfig wlan0

で、inet addr:IPアドレスが入っていれば成功。

あとはping飛ばすなりなんなり。

ブート時に自動接続する方法もあるんだけど、CLIは接続状態がパッと見た目で分からず怖いので、最初は必要な時だけ手動で接続するようにしようかな。

ではこのへんで。

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

どうも、こんにちは。

以下の本を読みました。

「リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック」

諸事情によりリンク無しです。そのうち差し替えますので、ご容赦ください。

今回は書評を書いてみたいと思います。ちなみに、人生初書評です。お手柔らかに(?)。

読もうと思った背景

プログラミングを勉強し始めて1年経ったタイミングで、会社の同僚にプログラミングに関する講義をすることになり、理論武装余儀なくされたため。

個人的にはとくにユニットテストを(自分を含めた)社内に流行らせたくて、ユニットテストの書き方が具体的に載っている本を探していました。

感想

私はどちらかと言えば普段から「分かりやすいコードってどんなだろう?」と考えながら書いている方だと思っているんですが、「分かりやすいコードとはこんなコードだ!」と誰かに教わったわけではないので、曖昧なマイルールみたいなものが、まあ多くてですね。

たとえば、Excel VBAで、変数の名前に該当セルの番地を使ったり、使うフラグの数に応じて順番に、f3とかf7みたいなのを割り当てちゃう人がいたとして、「そ、それはあかん!」って話はするんですけど、「じゃあどうすりゃいいの?」って聞かれたら、ちょっと困っちゃうんですね。気持ち悪さをきちんと言語化できないというか(まあこの例だと分かりやすいですけど)。

「このコードはなぜ分かりづらいのか?」

であるとか、

「このコードはどうしたら『分かりやすいコード』になるのか?」

といった問に対する答えが、なんか主観的で、曖昧になりがちなんですよね。

諭し方が主観的だと、人って言うこと聞いてくれないじゃないですか。

そこらへんをきちんと、曖昧にせずに、(ちょっとお節介な先輩が)理屈っぽく教えてくれるのがこの本、という感じでした。


この本で一貫してキーとなる考えがありまして。

コードは他の人が最短時間で理解できるように書かなければいけない。

「他の人」には、「将来の自分」も含まれていて、これを本の中では、「読みやすさの基本定理」と呼んでいます。

これさえ覚えておけば、後はときどき立ち止まってコードを眺めてみて、「他の人にとって読みやすくなってるかな?」と考えてみる。必要に応じて、この本を開いて助言を得る。

そんなスタンスで、いけそうな気がしてきました。

あと、ユニットテストの書き方ですが、C++のサンプルコードが「悪い例」→「良い例」→「さらに良い例」とリファクタリングされていくのが参考になったほか、

テストが何をしているかは1つの文で記述できる。

という一文が印象的でした。

どうも、テストを書かないできた私のような人間からすると、テストの実装を難しく考えがちなところがあって。ポンと背中を押されたような気持ちです。テスト書こー。

調べた言葉

ベクタとスワップ p.64

vector = ベクタ = ベクトル

ベクタはC++で使われる動的配列。動的配列とはサイズを自由に変更できる配列のこと。

スワップは2つの値を入れ替える。

vector
a quantity having direction うんたらかんたら
swap
an act of exchanging one thing for another.

do/while ループ p.90

do { 文; } while (継続条件式);

まず文を実行してから、継続条件の判定を行う。継続条件式が真である間、文を繰り返し実行する。

ガード節とクリーンアップコード p.91

ガード節はreturn, continue, breakで早めに条件やループを抜ける。ネストを減らすメリットがある。

クリーンアップコードは、メモリーファイルシステムに残ったデータ構造を掃除するために書かれるコード。

デストラクタ p.92

C++で、コンストラクタなどでメモリ内に確保したリソースを開放するための処理。

destructor
a furnace(焼却炉) or oven for the burning of refuse

continue文 p.96

for, while, do/while ループの中で、処理を(for文等のブロック終了直前まで)スキップさせるために用いる。通常if文と併用される。

スレッド p.97

thread of executionの略。実行の脈略。CPU利用の単位。

コンピュータは擬似的に同時処理を行うために、ごく短い時間ごとに動かすスレッドを切り替えて、あたかも同時に複数のスレッドが動いているように見せかける。

シグナル/割り込みハンドラ p.97

シグナルとは、プロセス間通信の一種。たとえばCtrl + Cを押下すると対象プロセスにシグナルが送られる。

ハンドラとは、シグナルをプロセスが受信したときにプロセスが行う動作のこと。

例外 p.97

例外処理とは、下位の処理で異常(例外)があり継続不能等に陥ったとき、呼出し元の上位の処理に制御を返し安全な状態になるよう回復処理をすること。

関数ポインタ p.97

ポインタはメモリの番地を参照先にするものだが、関数ポインタでは参照先を関数にする。

仮想メソッド p.97

メソッドの動的呼出し。

C#では、virtualで定義したメソッドをoverrideで再定義することができる。

ここら辺、ちょっと調べたけどよく分からん。

DRY原則 p.106

Don't Repeat Yourselfの略。

同じ知識を2箇所以上に記述すると、当該1箇所の変更の際に他の部分も変えなければならない。結果、矛盾が発生しやすくなるし、データの信頼性が損なわれる。

要はRDBの正規化みたいなものだ。たぶん。

break文 p.115

最も内側のfor文、while文、do/while文から脱出する。

記憶が曖昧だったので調べた。

イミュータブル p.124

unchanging over time or unable to be changed.

不変。対義語はmutable。

forループの条件にtrueを使う p.126

for文は、下記条件式の値がtrueな限りループし続ける、というもの。

for (初期化式; <b>条件式</b>; 変化式){
  実行する文;
}

で、条件式にtrueがそのまま入っていると、{}内で処理が返る等しない限りループし続けることになる。

本書のp.126で使われていたけど、不要なバグを生みそうな気がする。

ビジネスロジック p.144

そのシステム固有の処理…を、ふんわり表現したもの、らしい。

英語版Wikipediaにはこうある。

business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.

Web小説をより良いものにするために

どうも、こんにちは。

4回目の投稿です。

下の記事を読みました。

p-shirokuma.hatenadiary.com

私は、何度かWeb小説を書こうと思っては挫折してきた、いわゆるワナビです。

思い出すのも辛いんですが、ノートにキャラクターの設定やあらすじなど書き込んでは、途中で投げ出した黒歴史がいくつもあります。

どうか、どうか石を投げないでください。私だって辛いんです。

その経験からすると、「小説家になろう」に小説を上げて、連載し、さらには完結まで持っていった著者の方々を、私は漏れなく尊敬します。尊敬するしかありません。

なかには、突っ込みどころ満載な、けどなんかネタっぽくないし、えっこれ大丈夫?と思うような作品もあることでしょう。

でもそれは、無料なのだし、読むのを止めてしまえばいいか、もしくは、せっかく作品ごとに感想やレビューを書く機能があるのだから、直接やんわりと突っ込んであげればいいのではないでしょうか。

その方が、作者の見えないところで突っ込むよりよっぽど建設的ですし、World Wide Webらしい。

当該記事のブコメにも似たような意見がありましたが、プログラムがそういう仕組みになっているように、Web小説だってみんなでリファクタリングしていけばいいんです。

…と思って、「なろう」のある作品の感想ページをのぞいてみたんですが、結構みんな辛辣に感想言い合ってますね…

Web怖。

箇条書きとロジック

どうも、こんにちは。

3回目の投稿です。

楽しくて1日に何度も文章を書いてしまいます。良い趣味ですね。

今回は、以下の記事に触発されまして、

www.nakahara-lab.net

これに対する所感をさらっと書きます。

箇条書きとは

そもそも箇条書きってなんでしょう?

キングオブザ集合知Wikipediaさんに聞いてみよう!

箇条書き(かじょうがき)は、文字による表現方法のひとつ。いくつかの項目をひとつひとつ分けて書き並べる。

(中略)

いくつかの項目を読みやすく(見やすく)するために箇条書きを用いる。文中にいくつもの項目を並べていくと、他の文字や記号に埋もれてしまい、項目の確認がしづらくなるからである。

https://ja.wikipedia.org/wiki/%E7%AE%87%E6%9D%A1%E6%9B%B8%E3%81%8Dja.wikipedia.org

まあそんな感じですよね。

箇条書きは、あくまで項目を読みやすく(見やすく)するために用いるものであって、中原敦教授が言うような、

「箇条書き」は、箇条に書き出した要素、概念感のあいだに「論理(ロジック)」をつくったり、「ストーリー」をつくったりすることができないのです。というか、それが一般には、求められない

といった使い方は、特段指定していないような気がするのです。

言うなれば副産物ですね。

箇条書きを使っても、思考のトレーニングはできるのではないか?

プライオリティ(優先順位)だったり、ロジック(論理)の流れの単位が、3つや4つだったらまだしも、10個あったとしましょう。

10個の手順を、簡潔に、的確に、しかも前後の脈絡をスムーズに読者へ伝える術を、私は箇条書き以外に知りません。知っていたら教えてほしいくらいです。

たとえるならそう、カラマーゾフの兄弟ですよ。あの、登場人物多すぎるしみんな長めの横文字で誰が誰だったか分からなくなるやつ

誰もが、冒頭の登場人物一覧を何度も見返しながらヒイヒイ読み進めた経験をお持ちでしょう。あれこそ箇条書きじゃないですか。

傑作とされることが多い作品ですが、必ずしも万人に読ませるものにはなっていない気がします。

読んでもらうことが大前提の論文なのに、前後関係が分からなくなって結局読んでもらえないのでは、本末転倒のような気がします。

人間の頭はそれほど合理的に文章を処理できるわけではありません。

要は、箇条書きを使っても、ロジカルな、あるいはストーリーテリングな書き方はできると思うのです。

もちろん、濫用は避けるべきだとは私も思います。

ただ、禁忌とまでしてしまうのは、かえって悪影響が生じてしまいそうな気がして怖かったので、こうして筆をとりました。

結論

何が何でも禁止とするのではなく、状況に応じてunorderedとorderedを使い分けるとか、書き手側のリテラシー次第という気がしますね。

私も勉強中の身ですが、自由に文体を取捨選択して、文章構成能力を磨いていきたいものです。

それではこの辺で。

書いてみて初めて分かることがある

どうも、こんにちは。

2回目の投稿です。

前回の投稿で物書きの産みの苦しみをほんの少し味わったので、今回はその苦しんだ感情を吐き出しておきたいと思います。

苦しむの or 吐き出すの早すぎじゃね?と思う方がいるか分かりませんが、今の自分は泳げないカナヅチのようなもので、いつか物書きの世界をすいすい泳げるようになっても(そんな時来るのか?)、カナヅチだった頃の自分を覚えておいてあげたいな、という考えがあります。

というわけで、どうぞ。

それにしても、みんなよくやってるよなあ、ほんと。

辛い

自分の文才の無さが辛い

これ。一番辛い。

世間並みくらいに読書はしていると自負しているんですが、もうね、こんなに自分に書く才能がないとは思わなかった。

ですます調とである調が混じったりする。てにをはが気になって何度も見返す。逆接とか副詞にバリエーションが無い。

言葉が湯水のようになんて出てこないもんね。一文一文立ち止まって、言葉の水脈を掘り当てるつもりで自分の脳内を引っ掻き回さなきゃいけない。それでもなかなか見つからない。

ブログなんて文才要らないだろ、って意見もありますね。それは違う、と声を大にして言いたい。

定量の文章を、定期的に、誰でもすらすら読めるように書き上げるというのは才能だと思う。

そもそも長文書けなくて辛い

これも辛い。

まず日常で1000字超の文章を書く機会なんてそうそうないわけで。

ランニングに慣れてない人が10kmを急に走ったときみたいな感覚がある。終わりが見えない。ペースもつかめない。なんども立ち止まっている。

そのうち慣れてくるんだろうか。

ネタが無くて辛い

辛いねー。辛い。

まず出不精だし、ネタ探しのアンテナ張るには鈍感だ。そのうえネタを見つけるだけじゃダメで、自分の意見をネタに落とし込まなきゃいけない。起承転結を交えて、かつ一定の共感を得られるように。これが辛い。

これも慣れの問題なのかも。

怖い

長文書くと論理破綻しそうで怖い

普段あまり論理的に考え事をしていない。

たとえば1000字にわたって起承転結で自分の意見を書いていったときに、起と結で意見が変わってしまうのでは(あるいはそのように読者に捉えられてしまうのでは)、という怖さがある。

この怖さがあって今回の投稿では、予めあらすじを見出しで書いてから本文を肉付けしていく方法に変えた。

しばらくはこの方法で行くと思う。

いつか総スカン食らいそうで怖い

自分はあまり極端な考え方は持っていない、方だと思う。極端な考え方を持っていても表明するだけの勇気も今はない。それ故に毒にも薬にもならない意見になりがち。

長くブログを書いていれば総スカンは多分どこかのタイミングで食らうことになるだろうけど、それに自分が耐えられるかはすごく心配。

そもそも誰にも読まれなさそうで怖い

怖い!

誰か読んで!

めんどい

半角/全角変換めんどい

この日記は基本的にVS CodeMarkdownで書いた後、gitにコミットしてから投稿してます。

はてなブログがリアルタイムなプレビューに対応してないみたいなのでこうしているんですが、Markdown記法を使うのに毎回半角にしなきゃいけない。これがちょっとめんどい。

英語圏は入力速そうで、ちょっと羨ましい。

言葉の意味を調べるのがめんどい

今回の日記では、

  • 逆説と逆接の違い
  • 総スカン

について調べました。

総スカンのスカンは「好かん」なんだって!賢くなったよ!やったね!

いろんな反論を想定するのがめんどい

反論が怖いので、いろいろと但し書きを付けたくなります。まだ読者もいないのに… あまり考えずに書ききってしまった方が良いのかもしれない。

でも、なんか楽しい!

文章を書くって楽しいですね。ちょっとしたストレス解消になるし、クリエイター気分が味わえます。ほとんどタダみたいな料金で自己顕示欲を満たせるなら、良い趣味だなあ。

なるべく続けられるように、だらだらと書いていきます。

今回はこの辺で。

個人的目標について

初投稿です。

はてなブログProに登録する勢いでドメインまで取得してしまった…連休深夜のテンションはほんと怖い。

まあ.comドメインでも年額1500円もかからないから、いいかな。

さて今回は、「今後自分がどうやってお金を稼ぐか」について、雑多に書いていきたいと思います。自分の中で結論が出ていないので、かなりぼんやりとした話になるはず…

また、随時追記していく予定です。お暇でしたらお付き合いください。

現状

年収400万。メーカー子会社勤務。ヒラ。

今の昇給ペースであれば、7~8年ほどで600万くらいにはなると思われる。

目標

3年で年収600万、7~8年ほどで年収1000万超

目標にあたっての障害

今の会社で年収1000万超を得るには、取締役になるしか道はない。そして、おそらく7~8年後までに空く取締役の席は多くて3つ。

ヒラの自分が、7~8年で並み居る役職付きを押しのけて、取締役まで上り詰めるのはなかなかハード。現実的じゃない。

では、どうするか?

今の会社で頑張っていくことは大前提。こまめに小さな目標を設定し、それを達成し続けることで、なるべく早めに600~700万のレンジを勝ち取る

小さな目標 達成期限  実際の達成時期
TOEICスコア900 2019年前半
役職を得る 2019年前半
電気工事士2種 2019年後半
ITツールの社内への浸透 2020年~2023年
東京の本社に出向し商品知識の習得 2020年
課長に就任 2026年

上の表はときどき眺めて、追記する。

で、1000万の大台に乗せようとするなら、結局300~400万を副業で稼ぐしかない。

副業の選択肢としては、以下を想定。

  • ブロガーになる

幸い、文章を書くのは嫌いではない(得意というわけではない)ので、意外とどうにかなるかもしれない。

  • スマホアプリやウェブアプリを作る

一応、ネタはある。プログラミングスキルにまだ乏しいのが問題。

  • 起業する

たぶん自分には無理。今の会社で頑張った方がまだマシ。


まとめ

というわけで、何かの取っ掛かりになれば良いかなーとブログを開設してみた次第。

7~8年後には、年収400万くらいをこのブログで稼げたら万々歳だけど、まあそう上手くは運ばないだろう。

ちょっと調べたら、それくらいの収入を得るにはだいたい月間100万PV必要みたいだ。うへー。そんな魅力が自分にあるとは到底思えない。

ほどほどに。