先日、友人のPC(fuego 218)が逝ったらしく、修理を頼まれた。
1CD Linux でデータのリカバリを試みたが×。

とりあえず、HDDが不良ということがわかったので発注。




で、HDDが届いたところでクリーンインストール。
２時間もあれば終わるだろうと思っていたら...。



ビデオコントロールのドライバがない...
どうやら、友人のPCは台湾のMOVITA社製らしく、
肝心のオフィシャルサイトは、閉鎖されておりサポートされていない(;ﾟдﾟ)ｧ....


オーディオドライバは、ここで見つけたが、
ビデオコントロールは、サイトの容量の関係でUPしていないとのこと。


困った　(´(･)｀；)　...。




そして、現れたよ。救世主！　You は　Shock!!


Driver Guide
無料会員登録が必要だけど、背に腹は変えられない！


で、探してきた(# ﾟДﾟ)ﾉﾌｫﾙｧﾖ!!　 [218_VGA_W2K_XP.zip]



無事インストール完了！リリース！！
報酬は【喜久福】ヽ(´ー｀)ノ



ここに書いておけば、あといつ頼まれても
クールに、スマートに、エレガントに決めてみせる( ﾟДﾟ)ﾉ　ﾉﾙｱ!

今日は、ただただ議事録を書きまくった！


さて、前回は「損益計算書とは」的なことを書いた。
聞きなれない単語が目白押しだったので、へこたれたわけですよ。ﾊｲ ( ﾟдﾟ)ノ

というわけで、今日は聞きなれない単語を勉強しようと思う。ｷｮｳﾊﾍｺﾀﾚﾅｲ!!

売上高(A)：製品やサービスなどの販売高
売上原価(B)：売れた分の原価
売上総利益(C)=(A-B)：これが高いということは、企業が提供する商品・サービスの競争優位性が高いことを示す。

これを、勤めてる会社に当てはめると...。
ちなみに、会社は独立系SIerとは名ばかりの、技術者派遣企業ですが（;´Д｀）

売上高は、派遣先から会社に支払われる人月単価。
売上原価は、SEの給与ぐらいかな？特に仕入れとかないし。
よって、売上総利益は、SEの人月単価　－　SEに支払った給与　ということになる。　ﾌﾑﾌﾑ...

販売費および一般管理費(D)：販売活動から生じる経費の「販売費」と、事務所の家賃や事務員の給与等の管理活動から生じる経費の「一般管理費」
営業利益(E)=(C-D)：営業活動の結果得られた利益。事業全体の競合優位性を表す。

これも同じように当てはめると。
販売費は、営業も兼ねる社長の給与とかが当てはまり、一般管理費は、事務所の賃料と総務の給与が当てはまるのかな(☆∀☆)
ということは、競合優位性を向上させるためには、「販売費および一般管理費」については、これ以上減ることはないだろうから、
たくさんのSEを集めて、「売上総利益」を増やすことが必要ってことか。　ﾝｰ...

営業外収益（F)：本来の事業活動以外からの収益。受取利息や受取配当金。
営業外費用（G)：本来の事業活動以外から生じた費用。借入金に対する支払利息。
経常利益（H)=(E+F-G)：企業経営活動全般としての儲けを表す。

さてこれも。

営業外収益については、利息や配当を受けるようなものは持っていないと考えられるので、該当無し。
営業外費用については、借入金の利息だな。どのくらい借入してるかは、実際の損益計算書を見ないとわからないから、
今度、帝国データバンクから情報を買ってみようかな(　￣ー￣)

特別利益(I)：臨時的な利益や、過年度に誤って処理したものを修正して出た利益。
特別損失(J)：臨時的な損失や、過年度に誤って処理したものを修正してでた損失。
税引前当期利益(K)=(H+I-J)：企業の最終的な利益を表している。

もうここまでくると、自分の見える範囲で当てはめるのは難しいかな。
経常利益は、その名の通り経常的な利益だから、企業の実力であり、
税引前当期利益は、臨時的な収益や費用を含めてるから、運も実力の内みたいなとこか。

法人税等(L)：法人税などなど。
当期利益(M)=(K-L)：利益処分に充てることのできる利益

それぞれの利益が、それぞれ意味を持っていて企業の成績を表している。


同業他社と比べる場合に、それぞれの利益を使って分析・比較ができるってことだよね　(ﾟдﾟ)




ハー。長かったけど、損益計算書についてはこのぐらいかな(ﾟДﾟ)ﾉ

今日は昼飯食い損ねました(つд⊂)ｴｰﾝ



さて、今日は財務諸表の１つ、「損益計算書」です。

損益計算書は、一定期間（通常は一年）における企業の経営成績を表した表です。

成績表であるから、その企業が一定期間の間にどれだけ利益をだしたのかを表すんだよね。
そこで利益とは、何かってことなんだけど、

利益（損失）＝　収益　－　費用　という算式で行われる。

これについてはOK。売った金額から、売るまでにかかった費用を引いた額が「利益」だし、
売った金額より、費用がかかれば「損益」ってことだ。

その利益とは、「売上総利益」「営業利益」「経常利益」「税引前当期利益」「当期利益」です。

急に聞きなれない単語がたくさん出てきたなぁ（;´Д｀）
「経常利益」は、ライブドア事件をニュースでやってる頃に聞いたような気がするぐらい。。。



とりあえず、今日は「損益計算書」とは何？ってとこまでにします。

アカウンティングには、大きく２種類あるんだって。

外部向けに作成される「財務会計」と、
内部向けに作成される「管理会計」。


「財務会計」は、外部の利害関係者への説明に用いるもので、
上場会社においては、財務諸表として公開される。

これを基に「投資家」は、株の売買を行う判断材料とする。


「管理会計」は、企業内部の経営管理者に対し、経営意思決定の材料とすることを目的としている。
財務分析、損益分岐点分析、予算管理などの手法で提供する。


対象者によって利用する用途が違うため、違う形で提供する。



追記：
そうそう。財務諸表は「貸借対照表」「損益計算書」「キャッシュフロー計算書」の３つを指すんだってさ。

というわけで、自分の理解度を測るために、
ちょこちょこと書いていこうと思う。


何のためのアカウンティングなのか

株式会社という制度に対して、「アカウンティング」が必要なんだって。

株式会社は、株式を発行し資金を調達し、その資金を元手に事業を展開し利益を獲得する法人である。
株を購入した人は「株主」、会社を経営する人は「経営者」と呼ばれる。

「株主」は、株の購入を通して株式会社に資金を提供し、「経営者」は、事業活動を行い利益を獲得する。
そして、獲得した利益を「株主」に対して分配する。これを「配当金」という。

株については、売買が自由であるため、「株主」は、売買の判断材料が必要である。
そのため、株式会社の経営陣は、会社の経営状況を「株主」に対して説明する必要がある。
この説明が「アカウンティング」である。


アカウンティングは、会社の経営状況を判断する材料

現在、自分が身に着けている知識は、
新しい技術、言語、環境が開発されていくにしたがって、
陳腐化されていく。

SEとして、知識が陳腐化するということは、
自分の価値が下がることだと思う。

これを解決するためには、
恒常的に自分の知識に対して、時間の投資をする必要がある。

「達人プログラマー」で提案されている指針の中から、
今の自分の網に引っ掛かるものをピックアップし、
備忘録として、ここに示す。

１．毎年少なくとも一つの言語を学習する
　新しい言語を学習することで、思考を幅広くするのが目的。

２．四半期毎に技術書を読む
　現在取り組んでいるプロジェクトに関連する書籍を、月に１冊読む。
　現在使っている技術をマスターする。

３．技術書以外の書籍を読む
　コンピュータは、人間本位であることを常に意識する。

４．異なった環境に慣れ親しんでみる
　Windowsしか知らないのであれば、Linux。
　IDEしか知らないのであれば、エディタ。

５．最先端にとどまり続ける
　業界紙やその他の雑誌を講読する。
　技術動向や市場動向にも目を向ける。
　
　
今の自分ができているのは、３と５。

今後、上記の指針を踏まえての目標としては、
・Linux(Fedora)をインストールして、vimまたはemacsで、LLの学習。
・DIコンテナに関する技術のマスター
　（Seesea2は、自分にとって黒魔術的なのでSpring)

詳細設計、製造、UTあたりの工程からプロジェクトに参加すると、
既に適用する共通ライブラリって決定されていて、
便利なオープンソースのライブラリの適用が出来ない状況が多々あるよね。

しかも、利用するフレームワーク（特に企業独自に開発したヤツ）によっては、
包括したユーティリティクラスなんて、ほぼ存在しない場合だってあるのに。

こんな場合に、なんの対策も講じないと、
同じようなコードを何度も書いたり、コピペしたりで、
仕様変更なんかされたら、即炎上。

そんな時に、社内で作成したライブラリの共有を円滑に進める必要があると思うんだ。
参考にしたのは「WEB+DB PRESS vol.38 無駄なコードを書かない技術」


ボトムアップルール
開発者自身が、開発中に「こんなライブラリがあったら便利」と気が付いたとき、
共通ライブラリを作成する場合のルール。

『書く前に開発メンバー全員に尋ねる。』

ポイント
　気軽に聞いてすぐにレスポンスをもらえる環境を準備しておく。
　メーリングリストより、インスタントメッセンジャーを利用した方がベター。
メリット
　開発メンバー間のコミュニケーションが促進される。
デメリット
　開発メンバーが分散している場合に適用しにくい。

トップダウンルール
既に適用している共有ライブラリについて、適用箇所を開発者に任せている場合、
共有ライブラリと共に、「ドキュメント」「サンプルコード」を提供するルール。

『書く前に共有ライブラリが存在しないか確認する。』

ポイント
　提供されている共有ライブラリを、俯瞰できる環境を準備しておく。
　Wikiベースのライブラリ共有サイトを使う方法が挙げられる。
メリット
　開発メンバーが頻繁に参照することにより、類似のライブラリ作成が抑制される。
デメリット
　運用方法を決定しておかなければ、ドキュメントが陳腐化してしまう。


情報共有ツールの活用（例えばWiki）
・運用ルールを決めておく
１．モジュールを作成する場合は、Wikiを参照し同機能のモジュールが無いことを確認する。

２．再利用性の高いと思われるモジュールを作成したら、
　　共有Wikiの所定のページにその仕様を明記する。
　作者名(問合せ先)
　ライブラリの概要
　サンプルコード
　説明
　機能一覧

３．毎朝のミーティングで追加ライブラリの周知を行う。


社内向けライブラリ作成のコツ
『基本』
・ライブラリは相互依存しないようにする。
・ライブラリを更新できるメンバを限定する。
・一度公開したライブラリのインターフェイスを変更しない。
・ユーティリティクラスのメソッドは、基本的にstaticメソッドとする。
『オープンソース活用』
・オープンソースのユーティリティ系クラスのソースコードを読む
・オープンソースのモジュールの一部を真似て自作する。
・パッケージ、クラス、メソッド、変数などネーミングを真似する。


重要なのは『ルール』を決め、遵守することで、
開発者自身に『価値』が与えられること。

ブログを始めて、一週間ぐらいになるんだけど、
どうも、文章を書くのが苦手というか、
ただのメモ書きにするわけでもないし、誰に向けて書いているのか分からない。

元々、ブログを書こうと思ったのは、
自分の文章に対する苦手意識の克服だったんだけど、

そこで、何のためにブログを書くのか明確にするのに、
「デジタル・ワークスタイル」の情報発信力編を参考にすることにしたんだ。


「デジタル・ワークスタイル」によれば、ブログを書く利点は、
「書くことによって自分の思考を整理できる」こと。

それは、ブログという誰でも読むことができるところへ書くことで、
人の目を意識するようになり、思考を整理して書こうとするかららしい。

確かに、文章にまとめようとするときに、
自然と不明点、疑問点をなくそうとしたり、
理解があいまいなところが見えてきて、理解を深めようとしている。

よく、ある事柄について理解しているかどうかは、
図解できるかどうかで分かっていうけど、
文章についても同じことが言えるんだろうなと思う。


「理解」していなければ「文章」にできない。

整理プロセス
　整理プロセスでは、処理プロセスで作成したリストを使い慣れたツールに組み入れる。

　このツールには何を使っても良いところがGTDの魅力のひとつではないだろうか。

　私は、Web上のTODOツール[check*pad.jp]を利用している。
　また、Webを利用するのであれば[Remember The Milk]も有益なサイトである。

レビュープロセス
　「書き出した項目を再度見直し、今日はこれをやろう、とイメージしていく作業」とあります。

　初回のレビュープロセスであれば、やることは特になく、
　一週間終わった時点での「週次レビュー」が重要である。

　日々、増えていくタスクを定期的にGTDのプロセスで処理し、リストを更新していく。

　「いつかやること」リストで興味がなくなったものは削除。
　「プロジェクト」リストで次にとるべき行動がはっきりしてきたものは、
　「次にとるべき行動」リストに移動。など。

実行プロセス
　「次にとるべきアクション」にあるタスクを、自分が置かれている状況、
　持っているエネルギーを把握しつつ、　タスクの優先度を考慮して、
　タスクを実行していく。


GTDのプロセス自体は非常にシンプルで、導入することも非常にスムーズにできる。

重要なのは、GTDを実践することによって、
自分の中のルールも適宜変えていく必要があるということ。

作成したリストの参照
・いつかやる／多分やるリスト [週に一度]
・資料リスト [必要に応じて随時]
・カレンダー、連絡待ちリスト [毎朝一回]
・プロジェクトリスト [随時]
・次にとるべき行動リスト [随時]

折角作成したリストを参照しなければ、意味が無い。

前回書いた各種プロセスの内容を列挙。

収集プロセス
　収集プロセスでは、「数時間使って頭の中の『気になること』を全部書き出す」こととある。
　
　「記憶」を外部ツールに任せてしまうため、思いつくことは全て書き出して、
　安心して忘れてしまうため、思考を巡らし頭の中にあることを書き出す。

　といっても、ある程度すると思い浮かばなくなってっくるので、
　『気になること』を思い出すヒントになる「トリガーリスト」を利用して、さらに思考を巡らす。

　「これも書き出したほうが良いかな？」と迷わず、思いついたら書き出しておいて、
　取捨選択は、後のプロセスで行う。

　あとで思いついたりしたら、収集しておいて定期的に後のプロセスを行う。

処理プロセス
　処理プロセスでは、収集した『気になること』リストをシステマチックな処理を行い、
　いくつかのリストに分類する。

　いくつかのリストは、以下の通り。
　受信箱：「未着手のタスク」を入れておく。思いついた考えなど。
　次にとるべきアクション：あと数日のうちに実現すると決めた数少ない物事。
　いつかやる／多分やる：いつかやりたいと思っていること。
　プロジェクト：いくつものタスクの集合となっている大きな仕事。
　資料：次にとるべきアクションを実行するためにあるトピックについて調査したことなど。
　連絡待ち：誰かに任せた仕事の連絡待ちのもの
　

ここまでできれば、GTDの導入については50％ほど完了。

今、取り組んでいる仕事中に、「あれもしなきゃ」、「あれも忘れちゃいけない」と、
考えるだけで、目の前の仕事量にウンザリすることがある。

そこで GTD (Getting Things Done) を利用することにした。
だいぶ前から話題になっていたようで、情報も充実してる。


人間の苦手な「記憶」は、リスト化してツールに任せる。
人間は得意な「処理」(仕事)に集中してクリエイティブなアイディアを捻出するというのが、
GTD (Getting Things Done) の目的なんだと思う。


GTD (Getting Things Done) の５つのプロセスは以下の通り。

・収集　頭の中の「気になっていること」をすべて紙に書き出します
・処理　書き出した事柄について、あるシステマチックなやり方にそって、しかるべきリストに仕分けしていきます
・整理　作ったリストを、自分が使い慣れているツールに組み入れていきます
・レビュー　自分が置かれている状況、持っているエネルギーを把握しつつ、今何ができるかをレビューします
・実行　今できることの中からやるべきことを実行していきます

[参考:ITmedia Biz.ID：はじめてのGTD]


仕事に集中する自分と、GTDで整理したリストで仕事を管理する自分を分けて、
自分で自分をコントロールすることに魅力を感じる。

ただ注意すべき点は、
「整理」プロセスで、ツールに組み入れていく時に、
ツールを使うことが目的にならないようにすること。
ツールは、あくまでも「整理」する「手段」であって、「目的」ではない。

「レバレッジ・リーディング」の「多読」は、
多くの本を読み、その本からエッセンスを取り出し、繰り返し読んで習慣化する。
条件反射的に出来るようになればその本の役目は終わり。
より多くの本から抽出したエッセンスを習慣化するのが目的。

「速読」は、
視野を広くして本を見たり、目を素早くスムーズに動かせるようにしたり、
多くの文字を目から取り入れられるよう訓練し、
文字をイメージ化して、脳内で再生すること。
早く読むことが目的。

両者とも、文字媒体から情報を効率よく得るためには有効だと思う。

ビジネス書や実用書を読む目的を考えれば、「レバレッジ・リーディング」。
物語を読むなら「速読」といった使い分けが必要なのかもしれない。

ただ、レバレッジ・リーディングにある、「カラーバス効果」と
「速読」の組み合わせで、シナジー効果が得られるような気もする。

あとは、自分にあった方法にアレンジすることが重要。

エントリが前後しているが気にしない。

今までただ読んできた本を、もう一度、レバレッジ・リーディングで読み直したくなる。

読むことで満足していたことに気が付かされた。
ビジネス書も、小説なんかを読むのど同様に、
隅から隅までテキストを消化することが目的になっていたのではないだろうか。

・何の目的で、この本を手に取ったのか。
・この本から何を得たいのか。
・この本のエッセンスはなんなのか。

まず、この意識が足りていなかったように思う。

テキストを消化することが、ただただ自信へとつながり。
本棚に並ぶ、本を眺めて「自分の知識量」だと勘違いしていた。
ってのは、ちょっとネガティブすぎるか。

これからは、「読む目的」「本のエッセンス」「習慣化」あたりが課題。

知識のみは「知っている」にすぎない 。

本で読んだだけでは身についたとはいえない。
あとで「知っている」単語に出合って、「あー。それ知ってる。」でおわり。

レバレッジ・リーディングでは、１度読んだら２度と読まない。とある。
重要なポイントは、メモに書き出し、たまったメモをいつでも読める環境を作り、
すきま時間に、目的を持ってみる（カラーバス効果）。繰り返す。習慣化する。

重要なポイントをメモすることで、本の役目は終わり。
あとは、抽出したメモが役目を果たす。

何事も実践あるのみ。

自分の課題・目的を絞り込む
↓
読むべき本を絞り込み、入手して、読む
↓
重要なところに線を引く、印を付ける
↓
レバレッジメモに要点を抽出し、繰り返し読む
↓
実践で試す
↓
レバレッジメモをブラッシュアップし、繰り返し読んで身に付ける
↓
実践で条件反射的に対応できるようになる


レバレッジ・リーディングにある、読書のシステム化のルーチン。

読んだときには、わかったつもりになってるけど、
いざ、実践しようと思ったときには、「なんだっけ？」ってことがよくある。

ここを見返しながら、習慣化していく。

わかってるつもりで、身につかないのは最悪。
実践あるのみです。