愛と勇気と缶ビール

ふしぎとぼくらはなにをしたらよいか

会計の勉強をする

要約

  • 簿記の勉強の仕方についての記事ではない
  • でも簿記の勉強にも多少役立つかもしれない
  • 初心者(主にエンジニア)が会計を理解するのにも多少役立つかもしれない


次の会社で会計システムを扱うことになったので、会計の勉強をしている。

普通の会社員が会計の勉強、というと簿記の3級や2級を取るという方向に行きがちである。資格を取ること自体が働き先で義務付けられているような場合は別だが、今回はそうではない。僕にとってはあくまで「会計とはどんなものか」を学ぶのが主眼なので、簿記そのものにはあまりこだわらないことにした。

それでも一応テクニカル・タームというか、一般的な語彙が分からないとどうしようもないな、と思ったので簿記のテキスト自体は通読しておくことにした。

超スピード合格! 日商簿記3級テキスト&問題集 第2版

超スピード合格! 日商簿記3級テキスト&問題集 第2版

テキストは上記のものを買った。

このテキストを眺めていて分かったことだが、簿記というのは基本的に「◯◯はこういう仕訳をする」「仕訳をした結果をこういう風に勘定する」「そこからこういう表を作ります」という内容がメインだ。 特に「◯◯はこういう仕訳をする」という項目が沢山ある。

「仕訳」というのはお金やモノの動きがあった際につける記録のことである。どうやら、一般的に簿記の勉強というものは、この「仕訳」の仕方を淡々と覚えていくものである、ということになっているらしい。(勉強内容自体は他にもあるけど)

この時点で、僕は簿記の試験を受ける気がなくなった。裏にあるロジックを理解せずひたすら記憶する、みたいな勉強に時間を割いてしまってはその時点で社会人として負け組である。

簿記のテキスト自体は、頭の外にあるインデックスとして使うことにした。「あれって何だっけ?」と思った時に該当の項目を引いて理解できればいいので、頭の中に持っておく必要のない情報だと判断した。

簿記は一旦おいて会計を

というわけで、簿記は一旦忘れて会計全体を貫くロジックやパターンを理解することに時間を使うことにした。

ここで話がややこしくなるのだが、僕は別の機会に貸借対照表と損益計算書を読む勉強をしたことがあって、それらの読み方は予め分かっていた。なのでここからの話はその前提で進む。

会計の流れから言えば、これらの表は最終的に生み出される「結果」「アウトプット」に属するものである。なので、アウトプットの見方は分かっていて、それに至るまでの道筋を補完する、という方向での勉強になった。

決算書がスラスラわかる 財務3表一体理解法 (朝日新書 44)

決算書がスラスラわかる 財務3表一体理解法 (朝日新書 44)

なお、財務3表の読み方について勉強した時に使った本は上記のもの。良い本だと思う。

会計はロジカルか?

会計全体を貫くロジックという言い方をしたけど、そもそもそういうものが存在しないという場合もあり得る。実際、会計には体系的な理論があるわけではなく、長く続けられてきた商習慣から「こういう風にした方が現実には便利だろう」というすり合わせをしつつ建て増しされてきたもののようだ。少なくとも僕にはそう見える。

例えば貸借対照表の左側と右側を「借方」「貸方」と呼ぶのだが、この呼び方自体には全然意味がない。意味がないところに「なんでこれが『貸し』でこれが『借り』になるんですか?」という風に理屈を求めて苦しんでいる人をネット上などでよく見かける。(例: http://oshiete.goo.ne.jp/qa/3061295.html)

ロジックが存在しないところにロジックを見出そうとするので話が色々おかしくなる。ちなみに僕が読んだマトモな本の著者はみんな「借方」「貸方」に「左側と右側」以上の意味はない、と書いている。ここに変な理屈をつけて「借方」「貸方」という言葉ベースで説明しようとする人間の言うことは信用しない方がいい。

ともかくこうしたものであるからして、「習うより慣れろ」式の簿記的な勉強法がメインストリームになっているのだろう。でもそういう勉強は効率がよくないからやりたくないんだよなあ、と思っていた所に丁度いい本を見つけた。

世界のエリートがやっている 会計の新しい教科書

世界のエリートがやっている 会計の新しい教科書

タイトルがバタくさいが、この本は「とにかくこういうもんだ」的な部分が少なく、ちゃんと順を追った説明がされているので理解しやすいと思う。後付けではあるが、ロジックもすっきりしていて頭に入ってきやすい。

簿記そのものを勉強する人もこの本の第一章は読んでおいたほうがいい。第二章、第三章はオマケ程度に。

余談だが、上記の本もよかった。まず言葉の定義をはっきりさせる、段階的に論理を積み上げる、という構成になっているのがよい。

唐突に今後の予定

上記の本などを読んでいて、「この辺には後付けのロジックが適用できて、この辺はそもそもロジックとか要らない部分」というノリが何となく分かって来たので、後はなんとかなるか、ということで勉強はこの辺にするかもしれない。

簿記2級のテキストもさらっと読んでみてもいいかもしれない。3級同様、試験を受ける気は今のところないが...

時間割を決めて行動してみる

2月の頭から有給消化モードに入り「このままだと無限にダラダラしてしまう可能性があるな」と思ったので、時間割を決めて行動している。

時間割を決めるなんてしっかりしてるな、と思う人がいるかもしれないが、以下の本によるとそれは逆で、自分でタイムマネジメントが出来ない人こそ時間割を決めた方がよいとのこと。

強く生きるノート 考え方しだいで世界は変わる (KEIO MCC Intelligence Series)

強く生きるノート 考え方しだいで世界は変わる (KEIO MCC Intelligence Series)

  • 作者: 本田直之,ちきりん,小池龍之介,平田オリザ,竹中平蔵,原田泳幸,村上憲郎
  • 出版社/メーカー: 講談社
  • 発売日: 2013/11/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る

で、2/1からなんとなく時間割に沿って行動してみた感想をば。ここで「なんとなく」と書いているのはそこまで厳密に従ってないからである。妻に言わせれば「全然従ってない」ということになるかもしれない。

  • 「◯◯している時間」に◯◯してないと、なんとなくサボっている気分になる
  • サボっている気分から離脱するためにちゃんとやろうとする
  • 時間割を決めていない場合よりも、ダラダラする時間が甘美になる
  • 逆にちゃんと◯◯しておけば休憩時間や自由時間がとても気楽になる
  • 例えば勉強時間でない時間に、意味のない焦燥感に囚われたりすることが少なくなる

というような効果があるようだ。意外に面白い。

2週めでだんだんダレてきたので、時間割を再構築してもいいかもしれない。また、普通の休日などもある程度時間割を切った方がいいかもしれない。と思った。

聞く所によると、さる高名なエンジニアの方は毎日決まった時間に勉強されているそうだ。

自分のためだけの勉強をやめる

「自分のためだけの勉強はそろそろやめたらいいんじゃないか」という言葉が頭に残っている。僕の尊敬している人の言っていたことである。

その人が正確にどういう意味で言ったのかは忘れたけども、その後いろいろ考えた。

誰かに教える、共有するために勉強する、というのも自分のための勉強から離れるかもしれない。

初めから何かを作り出すためだけに勉強する、というのもそうだ。

あるいは、何らかの外部のプロジェクトに貢献するための勉強もそうかもしれない。

インプットするだけでなく、アウトプットしないと本当の知識にはならない、身に付かない、というのはよく聞く話である。また真実であるとも思う。

最近は本を読んで勉強するときには、メモを取るようになった。

メモは自分しか読まないので、これはまだ自分のための勉強を脱しているとはいえないが、少なくとも後でどこかに書く、例えばここなどに書くためのとっかかりにもなるであろう、と思ってメモを書いている。

…というようなことを考えつつ書いていたら、飴色玉ねぎが少しこげてしまった。

飴色玉ねぎは難しい。

凡庸な話について

凡庸たらざるを得ない文章というものがある。

例えば、結婚式でのお父さんのスピーチや、校長先生のお話。

僕の父はいささか変わり者で、だから僕は父が結婚式で変わったスピーチをするのを期待していた。でも、それは違うのではないかと思うようになった。

この場面ではみんなありきたりなことを言うから、いっちょ変わったことをしてやろう。奇抜な内容を話に盛り込んでやろう。

個性的であろうとすること、あるいは個性的であらねばならないと思うこと。それこそ、僕にはむしろひどく凡庸なものに感じられる。

誰もが凡庸な話をする場面では、凡庸な話をすればよいのである。

奇抜なことをやるのは凡庸だ。

凡庸な内容を突き詰めて、その上で何か手の上に余るもの、それが本当の意味で凡庸さを超えるものだろう。

JsDocにやさしいJSの書き方

最近、比較的真面目にJsDocを書くという機会があったので。

(※この記事の前提はJsDoc 3.2.2です)

JSで適当に名前空間的なものを切ってコードを書いていくと、

/**
 * @class
/*
function Klass() {
}

Klass.prototype.foo = function () {
};

my.name.space.Klass = Klass;

みたいな書き方がいいか、

/**
 * @class
/*
my.name.space.Klass = function() {
};

my.name.space.Klass.prototype.foo = function() {
};

みたいな書き方がいいか、という割とどうでも良い選択(意味的には同じなので)を迫られることがありますが、これは結論的には後者の方がよくて、

  • 後者だとJsDocが勝手にKlassがmy.name.spaceに属することを判断してdocumentを作ってくれるが、前者の場合は@memberofとか使わないとその辺を理解してくれない
  • 前者だと余計なシンボルがスコープに定義される (Klass)

という二点において、後者を選んだ方がよいです。

ちなみに僕は「メソッド宣言とかを短く書けるから」という理由で前者を選んでいましたが、JsDocを書く段になって後悔しました。

この辺の話は今後JsDocそのものが賢くなると改善されるかもしれませんし、browserifyなどのモダンなモジュールシステム(?)を使っている場合はあまりこういう話題は登場しないかもしれませんね。

JsDocのannotationを真面目に書くのって割と面倒なので、出来るだけannotationなしでJsDocに構造を理解してもらえるようにコード書いたほうが後々ラクですよ、というお話でした。

Googleは内部的には違うものを使っていると思いますが、JsDocの書き方自体はclosure libraryが参考になる気がしています。

google/closure-library · GitHub

色々なライブラリが群雄割拠している昨今のJS業界ですが、closure libraryにはGoogleの伝統と知恵が詰まってると思うんだ。多分。