Category: Random

財務諸表を読む必要があるのはわかっている 近々会社を経営する予定がある。なぜそういうことになったのか？は別の機会に触れるとして、会社を経営するにあたって大切なことは会社を倒産させないことだと思う。 医者であれば患者を検査し、その結果の数値から治療法を提案し必要な処方箋を書くのと同じで、会社を倒産させないためには、会社についての数字を理解できる必要があり、会社の数字が記された財務諸表を読んで次の一手を考えられることが重要だと思う。 ここでいう財務諸表とは次のようなものを考えている、というこれ以外に知らない 会社ではMoneyForwardというサービスを使っているので、これらを月次で見ることはできる。しかし、それを見ても、それが何を意味しているのかがわからないのが現状である。 わからないのであればわかるようになるまで勉強すればいいと思う。これまでエンジニアとしてわからないことがあれば、検索したり書籍を当たったり勉強会に参加するなどして、それを理解するようにしてきた。しかし、財務諸表を読むことについては、そういったことができず後回しにしてきた。理由を考えることもせず遠ざけてきた、と言う言い方が正しいと思う。 そこで、この記事では、財務諸表を読むことについて、自分がどうして嫌なのかを自己分析していく。そうすれば、１つ１つの理由に対する処方箋を考えることができて、これまでの状態よりも一歩前進できるのではないかと思っている。 理由 1: 時間の見積もりが難しい どのくらい時間をかけて学べば良いのか分からず、一歩目を踏み出せない。 これまで新しいことを学ぶにしても、プログラミングについては、ある程度の時間をかければ、それなりに理解できることがわかっている。しかし、財務諸表については、そういったことができない。足場が全くないのに、突如高い壁が立ちはだかっているようなで、その壁の前に立ちすくんでいる感覚。 理由 2: 自社の数字が面白くないと感じる たとえば自分が経営する会社が利益がガバチョガバチョだったら、それをどのように使おうかと考えることができて、楽しい気持ちになると思う。しかし、社員30人程度の中小企業は常に資金繰りとの戦いであり、弊社として例外ではない。トントンの状態から、次の一手を打つための採用経費や新規事業開発のための投資などをどうするかを考えることが多い。そうなってくると、楽しいというよりは、なんとかして売り上げを増やさないと、という意識が先立って、分析することが苦痛になってしまう（気がしている） 理由 3: 無知と向き合うことの難しさ これは自分の幼さが原因かもしれないが、全く知らない分野の勉強をすると、自分の無知を痛感し、モチベーションが下がってしまう。 実はすでに、複式簿記やらバランスシートについての読み方について、何冊か本を読んでいる。読んだその時は「…なるほど…！？」と思うが、あまり腑に落ちることなく書かれていることが身に付かず、時間が経つと綺麗さっぱり忘れてしまう。そんなことがあり、自分は財務諸表を読む能力がないんじゃないか、という気持ちすら抱いている。 思いつく限り書いたが、こんなところだと思う。 原因がわかったところで、次に何をすればそれぞれの問題が改善されるか、検討をしてみる。 処方箋 1: 小さな目標を設定して、学習を習慣化する 財務諸表のすべてを一度に理解する必要はなく、小さなステップを積み重ねていくことが良い。例えば1 日 30 分の学習時間を設定し、短期間で成果が出るような区切りをつける。 処方箋 2: 他社を題材にする 実際の自社の財務諸表を読むのが苦痛であれば、他社の数字を勉強の素材にする。利益が潤沢な大企業や、自分が憧れる企業の財務諸表を調べてみると面白さを感じやすいし競合分析にもつながる。インターネット上には公開されている上場企業の財務諸表が多数あるため、そこから興味のある企業を選ぶと良いので素材は潤沢にある。理解が進んでから自社の財務諸表を見直せば、「こういう形で改善できるのでは？」という発想が生まれやすくなる。クイズを作ってみると楽しいかもしれない。 処方箋 3: 「わかる」実感を積み重ねる工夫 読んだことが腑に落ちないのは、具体例や実践が不足しているからかもしれない。そのためには小さなシミュレーションを通じて学ぶと良いかもしれない。 たとえば、自分の家計を複式簿記で記録し、簡単なバランスシートを作る練習をしてみる。「少しでもわかること」を日々の成果として実感するため、定期的に進捗を記録し、自分ができることを確認する。 処方箋 4:財務諸表を読むことへの前向きな考えを持つ 財務分析にプログラミングのようなクリエイティブさがないと思っていたことが、学ぶのが億劫な原因でもあったが、売上をどんな新事業に挑戦するために使うかを考えることは、クリエイティブな活動だと思う。 また、「財務諸表を読むことができるようになった自分は何を得ているか」と言う良いイメージを想像してみる。 財務諸表が読めるということは会社経営の「羅針盤」を手に入れた感覚を持つことだと思う。つまり数字を読み解けることで、何をすべきかがきっとクリアになる。反対に数字の根拠なく勘で経営方針を考えても、再現性や効率の観点から考えて、無意味。 まとめ 財務諸表を読むことは、単なるスキルの習得に留まらず、会社経営を支える基盤となる重要な知識だ。会社方針を考え、伝えることが経営者の役目の１つだが、数字が背景にあれば、言葉に説得力が増す。興味を持てない理由を理解し、それを克服するための対策を 1 つずつ実践することで、必ず道が開けると信じて進んでいきたい。 この投稿をきっかけに、一歩一歩前進していこうと思う。

技術書典を知ったきっかけ 1年半前（技術書典14）にサンシャインに立ち寄ったらやってたのがきっかけ。アプリの仕組みやサークルの配置、人の動線に至るまでよく考えられたイベントだな、技術書版コミケのようなイベントがあるんだ、と思いました。 自分で一冊書くのは無理でも、会社の人と一緒にいつか合本を作れたら楽しいだろうなー、でも執筆に興味ある人いないだろうなー、会社のブログ書いてるのも自分だけだしなー、とぼんやり思っていました。 私はエンジニアになる前は出版社で営業をやっていたので紙の書籍については少し思い入れがあります。（「あそこだけはやめろ」と言われるような業界でも有名なブラックな語学系出版社で心身ともに疲弊して辞めて今のIT系の仕事に流れ着いた過去があるのでいまだに乗っている電車が飯田橋駅を通過するたびに体がこわばります。当時フリーター職歴なしだった自分を採用してくれた間口の広さには一応感謝しています) 申し込み 9/2にツイッターを眺めていたら、もうすぐ技術書典の申し込み締め切りというアナウンスと「申し込みました！」というツイートが連続して流れてきて、そうか誰でも申し込んでいいのか、それならと記念受験のつもりで申し込みボタンをポチりました。ただ申し込み時に何についての本を書くかをあらかじめ書かなくてはいけません。そこで飽きっぽい自分が毎日取り組んでいた水耕栽培について書くことにしました。園芸ネタだけでは弱いと考えて、ちょうどラズパイを使った温湿度などのモニタリングをしていたので、そこを押し出せば、悪くないかもと考えながら申し込みフォームを埋めました。 締切20分前の23:40分に申し込み完了。 当選通知 1週間後の9/8に当選通知がきました。嬉しい気持ち半分と果たして自分に本が書けるのかという不安半分がありました。 私は仕事を掛け持ちしていて忙しいので1週間のうちこの時間なら確実に空いている、というのはなく偶然生まれた時間に書き上げるしかありません。 フワちゃんのスタイリストとジャンポケ専属のロケバスの運転手をしている関係でなかなか執筆の時間がとれませんでしたが、奇跡的に仕事に空きができたので、一気に書き上げていきました。 しょうもない冗談はさておき、この期間で一番きつかったのは、誰か知らない人の入稿しましたツイートを目にすることでした。例えばこんな感じのです。 11/3がオフラインイベントなのに、10/11時点で表紙こみで書き上げてる。今時の若者優秀すぎる。恐怖… それでもなんとか書き上げることができたのは、以下のことを最初にやっておいたことが功を奏したからだと思います。 中でも早いうちにRe:VIEWという素晴らしい組版ツールに出会えたことは振り返っても良かったと思います。書籍の本文のデザインはAdobeのInDesignを使用するのが当然で、Wordやフリーソフトだとどうしてもチープな感じが出たり痒いところに手が届かないものという認識でしたが、商業出版にも耐えられるレベルで入稿データを作成できるのは驚きでした。 また、VSCodeではなく、AIコードエディタのCursorで書いたことによって多くのメリットも享受できました。これについては改めて別の機会に紹介したいのですが、次のようなメリットがありました。 本文執筆完了 大体書き上げた後は、校正作業です。いくら気をつけて書いたとしても、おかしな表現や誤字脱字は発生します。別の形式で出力して読むことで、おかしなところ気づきやすくなります。 これは便利だと思った校正の方法があるので、ついでに紹介したいと思います。 2. 出力したPDFをAirDropを使ってiPadに転送 3. iPad側でGoodnotesというノートアプリに読み込ませる ページごとに出力されるので、気になった箇所をどんどんチェックする 以上です。iPad miniくらいのサイズがねころびながら出来て最高でした。 文章以外で苦労した点といえば、水耕栽培装置の図解をする都合上、大量のイラストを作成しないといけなかったのですが、祝日を丸一日使ってパワーポイントで作成しました。私はパワポをAdobeのイラレ、Canva、Figmaに並ぶデザインツールと捉えています。 写真などは、新規で撮影したものもありましたが、過去にTwitter（現X）にあげているものをかなり流用しました。こまめに状況をつぶやくことが、後々思いがけない形で自分自身を救うことになるので、今後もちまちま発信続けていこうと思いました。 最後にRe:VIEWに組み込まれている校正支援ツールprhで文章表現を整えて本文データは完成 表紙作成 日光企画は表紙データをPhotoshopで受け付けているのですが、操作がわからなさすぎて、パワポで表紙作成→PDF出力→フォトショに貼り付けという荒技で乗り切りました。Photoshopはサブスクで1ヶ月だけ契約しました。必要経費とはいえ高い。 宣伝 届ける工夫をなぜか1年前の技術書典で購入していてその時は実はしっかり目を通していなかったのですが、再度読み返しました。 自著を何度も宣伝する行為ってあざといな〜という印象を持っていたのですが、「販売部数という数字を積極的に追い求めると拝金主義に感じてしまう、謙虚さゆえに控えめに宣伝する人がいる、しかしその情報を必要としている人に届けたいという気持ちにネガティブな要素はあるのか？」的な文章を目にして考え方が変わりました。 そして毎日こまめに「届ける工夫」に書いている通りのやり方を実践しました。 すると 本当にフォローが増えたりいいねのリアクションが増えていくのを実感し伝えたい人にじわじわと伝わっていくのを体感しました。実際にTwitter見て買いに来ましたって人もいて良いことづくめでした。「届ける工夫」、まじ名著。 何より技術書典ジャストミートの内容なので、本を執筆中の時点での告知の仕方まで書いてくれていて、今後も技術書典の度に読み返すことになりそうです。 入稿 何が普通かわからなかったので、各方面でおすすめされていたバックアップ印刷所なる日光企画でデータ入稿しました。ページ数ごとに値段が違うので、見積もり作成がギリギリまでできず、なかなか入稿作業に手をつけられなかったので不安が大きかったです。本文データはRe:VIEWの技術書典レポジトリを使用したので不安は少なかったのですが、表紙データは指定のフォーマットでフォトショを使って入稿しないといけないので、不安大でした（背表紙の計算にひとスキル要求されます）。 入稿後、日光企画の人から電話があり、「ダメダメだったので直していいですか？」（要約）と伝えられ、秒でオネシャスと言いました。これまでプリントパックやラクスルを使用した入稿は経験があったのですが、同人誌印刷は今後も日光企画を使っていこうと心に決めています。 前日 ちょうど雨で外に出かけられなかったのもあって設営のリハーサル。初めて遠足に行く小学生みたいな気分でした。 設営についても「届ける工夫」に載っていたテクニックを全面的に参考にしました。 当日 自分でも馬鹿かと思いますが、興奮しすぎて2時半に起きました。 それまで自分のことで精一杯で、近くにどんなサークルがいるのか知らなかったので、技術書典季報を購入しました。他のサークルの書籍を物色し、時間があったら買いに行きたい本をリストアップしていました。すっごい楽しかったです。 自宅が会場であるサンシャインまで15分ほどという地の利を活かし、出展者の入場時刻である9時半ギリギリまで自宅のソファで期待に胸を膨らませ続ける幸せな時間を過ごしていました。 当日の出来事はちゃんと書くと長くなりそうなので箇条書きにします。 まとめ 出品サークルを支えるをいろんなありがたい仕組みがあるおかげで、初参加にもかかわらず本来頭を使うべきこと（執筆、宣伝、コミュニケーション）にしっかり向き合えた素晴らしいイベントでした。自分の経験を書籍にしたことで、知識が補強され、知りたいことも広がり、交友関係も広がりました。当然また参加したいです。 歳をとると初めての経験っていうのがどんどん少なくなるんですが、苦労した結果得られたものはとても多かったので、新しいことに挑戦する気持ちが芽生えてきます。 興味はあるけど自分とは違う世界の話だと思っていたこと、例えば社外のLTでの登壇（は来月する予定）、メンターサービスの活用、ISUCONへの参加、ポッドキャスト、海外での仕事など色々と始めていきたいです、終わり。 以下、思い出の写真を貼ります。

スター精密社製 SM-S210iを使い倒す！ 本記事はReact Native アドベントカレンダー 2023の 17 日目の記事です。

中島聡さんの仕事論的な本に書いてあった、「勉強はしない、必要になったら調査する」っていう文章を読んですごい楽になった。 日々新しい言語やフレームワーク、技術トレンドの情報が押し寄せる中で、自分の無力感と焦燥感が募ってしまうタイプだが、自分のやりたいことに集中しろ、やりたいことができるように努力しろ、みたいなことも書いてあって、それを信条にしていこうと思った。

コード書く時の参考にしようとした記事に「一部省略しています」って書かれてるのを見た時、激萎えする。

コーディングでつまった時、Qiitaとか読まず公式ドキュメント読む

この書き方が合ってるかわからんがReactNativeをExpo使って開発してる。 単純な画面遷移、値の受け渡し程度ならなんとか書き進められた。しかし、カメラの起動だったり、データをクラウドに保存とかしようとすると急激に難易度が上がった。 ReactNative + Expo で参考になるサンプルがあまり少ない。その上、ライブラリのバージョンが違ったりして、サンプルがうまく動かないことが多い。 そもそもC#やJavaの開発に慣れた身としてはJavaScriptの書き方がなんか気持ち悪い。 ->　とか見るとふざけてんのかといまだに思う。 そんな感じなもんだからラムダ式見るとキモ、と思ってしまう。 TypeScriptなんてもうお手上げである。 IT技術者として５年間培ってきたノウハウが全く通じず、自分は無能かと焦る。

池袋で働くIT技術者のブログです。