ITの普及にともないプログラミング言語に関する書籍が書店の
本棚を占拠するようになって久しい。「やさしい」「できる」
「わかる」「超図解」などの形容句を題名につけた、絵や図、
パソコン画面の写真、はては漫画まで氾濫する内容に思わず
辟易とした経験がある。
プログラムやシステムには興味はあるが、本を手にとってみれば
上記のようなマニュアルや、または難解なプログラムのコードが
延々と続くプログラミング技術専門の無味乾燥な中味が
大部分を占め今ひとつ食指が動かない。
「プログラムとはコンピューターに計算を指令する命令文である。」
程度の認識から、実際にプログラムコードはどのようなもので
それがどのような動きをするのかもう少し理解を深めたい。
JavaやC#などオブジェクト指向言語の基礎知識はありながら、
断片的なテクニックが次から次へと流入するため全体構造が
捉えられない。
具体的にそれが何故？どのように役に立つのか未だ
疑問を抱いている。
プログラムをその機能や効用中心ではなく、哲学的・社会学的に
人間の思考と絡めてどのように解釈すれば良いのか？
またプログラミング言語の構造や文法が人間の思考に
どのような作用と影響を及ぼすのか知りたい。
ネット社会（匿名、ヴァーチャル）で培った知識や経験がリアルな
一般社会でどの程度通用するのか、また一般社会から見たネット社会の
平均的な知的水準はどの程度のなんだろうと考えている。
このHPはそのような方々と想いを共有する読者全てに向けて書かれて
おります。プログラマーやSEなど職業としてプログラミングをする
人々向けではなく、一般の学生やOL、サラリーマンが「プログラミング
をする意義や効果」について考えてみたいと思います。
プログラミング言語を「人文系女性」の視点から分析し、皆さんと
一緒に考えて行きます。
「人文系女性」視点とは、このボタンをクリックしてこのタグを
開いて…、のようなロボット的マニュアルを欲しません。また
TCP/IPの通信プロトコル第４階層の…、ごとき専門技術水準で
ものを語るものでもありません。
プログラミング言語の核心部分を具体的コードで切り出して
それをどう解釈し、私達の思考―文化―制度社会にどのような
インパクトを与えるのかとの視点に立脚するものです。
なお予めご承知おき頂きたいことが二点あります。
筆者は自由奔放な思考の跳梁こそHPの楽しみと理解して
おります。したがって目次を一応の道標としますが理路整然と
編集された内容にするつもりはありません。
逸脱や迂回を含んだ思考過程をありのままの姿で提示するつもりです。
いわばプログラミング言語と思考が一体となって躍動する
「活造りの盛合わせ」をお出ししたい。
また本HPはJava言語の教則本ではないので「これで入門コースはお終い。」
なんてものはありません。
本書の末尾が新たな思考の起点となるべく、常に未完成への意思を
もって考察を深めてゆくつもりです。
目次へ
プログラム言語を学ぶ人が最初につまずく
可能性のある小さな小石をまず取り除きま
しょう。
1 + 1 = 2 ですね。そして、1 + 1 =□ の中味は当然2です。
そこで□を答と名づけましょう。そして1 + 1 = 答の中味はこれも2です。
その右辺と左辺（=の両側）を逆転します。
すると答=1 + 1 となります。
これで、皆さんはプログラムの世界に一歩
足を踏み入れたのです。
書式は簡単です。
答=1 + 1 ；
後ろにセミコロンをつけるだけ。
まあ文章の最後の句読点のようなものと考えて下さい。
でも忘れるとプログラムが注意（エラーと）するので必ずつける
ようにして下さい。
但し、これは
答 = 1 +
1 ； と
書いてもOKです。（あまり見たことはありませんが…）
こだわるところは徹底してこだわるが、エーカゲンなところは
徹底してエーカゲン。某国の総理大臣とそっくりです。
とにかく答=1 + 1 ； で2を答に代入（Assignment）している
プログラムです。
答=2 + 1 ； の中味は３ですね。
以前の中味である２は消えてなくなります。さて、ここからです。
今20才の花子さんが居ます。幼稚園に行っていた4才の花子さんはもういません。
それをプログラムでは
int 花子 ；// 花子という名前は整数ですよコンピュータに宣言？して教える。
花子 ＝ ４；// まとめて
int 花子＝ ４；//としてもＯＫです。
花子 = 花子 + 16；
と表します。
（int＝イントというのは整数であるIntegerを略したものです。つまり
コンピュータに花子の名前の中味は整数ですよと教えて上げる
訳です。これをタイプ＝型といいます。）
右の花子は４才です。左の花子は16年後現在二十歳の花子さんを
表しています。
（花子 + 16 = 花子；はエラーですから）
数学の等式と逆に必ず左は右の結果です。
歳月は人を待ってはくれません。
花の色は移りにけりないたずらに…です。
二十歳の花子をもう一人これに加えて
花子 ＝花子 ＋ 花子；
とするとどうなるのでしょうか？
どっしりと安定感を加え、押しも押されぬ四十路の花子さんが左辺の結果に
出現するのです。
同窓会に行けば「あらぁ~、見違えちゃったわよぉ。」と友人に
言われるでしょう？
この表現は通常、安定感が増したことを素直に言えないほど
「見違えた」ときに使用されます…。
将来の花子さんを予想することは止めましょうね。では、
花子 ＝ 花子 − ２０；
System.out.println(花子)；
画面に20と表示されます。
あぁ良かった無事二十歳の花子に戻ることができました。
「さっきは悪夢だったのかしら…。」
なお System.out.printlnというのはプログラムで
システムさん（System）出力（out）して下さい。
( )の中味を改行付で画面に表示してね。（println）という意味です。
末尾のlnはLine(行)の略です。
以上よくプログラムの中で見かけ初心者が疑問に感じるコード
i = i + 1；？？？の解説でした。
お分かり頂けたでしょうか？
「じゃぁさぁ、今の花子が、過去の花子の想像ではなく、かつ、
将来の花子の想い出ではない、
とプログラム的にどうしたら証明出来るのでしょうかぁ？」って…
鋭いご質問には若干今のレベルではお応えできないので下記の
脚注を参考にして下さい。
目次へ
脚注その１
「今の花子が、過去の花子の想像ではなく、かつ、将来の花子の
想い出ではない、とプログラム的にどうしたら証明出来るので
しょうか？」に対する回答は下記のプログラムとなります。
import java.util.*;
public class Genzai {
public static void main(String[] args) {
int 花子の生年= 1984;
//花子の生年を定義します。自分の生れた年は
//いくらなんでも記憶しているでしょうから。
int 今年;
//今年を表す変数を一個定義する。
Calendar cal= Calendar.getInstance();
//Calender型のInstanceを取得します。システムクロック
//ベースの現在オブジェクトがcalで生成されます。
今年= cal.get(Calendar.YEAR);
//そしてYEARをcalからgetして今年に代入する。
System.out.println("今年は" + 今年 + "年です。");
System.out.println("花子の生年は" + 花子の生年 + "年です
から");
System.out.println("花子の年齢は" + (今年 - 花子の生年) + "
才です。");
System.out.println("中年オバサンでも幼稚園児
でもありません。");
System.out.println("システム的にはこれが証明です。");
}
}
/*結果です：
今年は2004年です。
花子の生年は1984年ですから
花子の年齢は20才です。
中年オバサンでも幼稚園児でもありません。
システム的にはこれが証明です。*/
プログラムにとっては日本時間もグリニッチ標準時間もあり
ません。ただシステムクロック（画面右下に表示）だけが現在
であると信じております。つまりそれより前が想い出でそれより
後が想像の世界です。
この質問は哲学的にもかなり厳しいものがあります。
現実性とは何か？現在性とは何か？の問いには古来中国の荘子
に出てくる「胡蝶の夢」（司馬遼太郎の小説はこれからとった
ものです。）の通り繰り返し歴史的な哲学者が挑戦しております。
本書の続編でユング心理学のシンクロニティー（同時性）と
いう概念をプログラムの再帰関数を絡めて「現在性」については
解説する予定でおります。どこまで核心に迫れるか、人文系
サンデープログラマー集団が挑みます。
続きます。
脚注 ２
i = i + 1；はこれまでの左から右に流れる数学の等式を単に
逆転したもの以上の意味を孕んでいます。
右にプロセスをおき左に結果である状態をおくことにより、
以前の結果自体が変貌する様子を表したものです。
さらに現在の結果は新たなるプロセスに限りなく投企される存在
可能性を秘めております。
「投企」とは「投棄」や「投機」の謂いではありません。
分解すれば「投」と「企」です。
「投」はリスクを負って自らを次のプロセスに放り込むこと、
「企」とはその結果である状態を目指すことです。
つまりiとは現在までのプロセスの中にあります。また
それを包摂しながら存在する現在の姿でもあるのです。
さらにその全てが共存している総体を指していることを
ここではご理解頂きたいのです。
花子さんの例でお分かりのとおり中味は常に変化の可能性に
さらされつつ、また変化し続けます。
自己同一性（アイデンティティー）をかろうじて保っているのは自らの
名前とそしてその記憶ではないでしょうか？
DNA鑑定もご本人にとってみれば検査を受けたというプロセスの
記憶に過ぎません。
中年時代を想像したのも記憶より想起され記憶に刻まれます。
左辺のiが背負うさらにその左にご注目下さい。
それが真の未来です。
過去のプロセスを包摂しながら新たなプロセスに投企する
それがi の使命ではないでしょうか。
目次へ
つぎは花子さんの気分をプログラムにしてみましょう。
ここは高原のホテルのカフェテラスです。
爽やかな朝の空気を頬に感じながら恋人と…
ミルクのたっぷり入ったカフェオレを
飲んでいる花子さんです。
String 花子；
花子 ＝ "ルンルン、ルンルン"；
の気分です。
（別れ話でなければですが…）
String＝ストリングは花子の中味を文章ですよとコンピュータに教える
サインです。また文章は" "の間に書きます。
さて、場面は変わってここは朝のオフィス。
細かいミスで課長に呼びつけられてネチネチと叱られる花子。
花子 ＝ "サイッテーェ！"
の気分ですよね。
プログラムとしては
花子 ＝ "ルンルン"＋"サイッテーェ！"；
文章でも＋記号が成立します。（−記号はありません…）
しかし花子さんの気分としてはあり得ないこ
となんです。
どうして花子さんはいつも高原のホテルの気分でいられないので
しょうか？
それは"サイッテーェ"がなければ"ルンルン"は生れません。
"ルンルン"がなければ"サイッテーェ！"もないからです。…と思いましょうね。
ところでint の花子とStringの花子を同時には使用できません。
例えば、花子の中味が年齢の20だと思って
System.out.println(花子)；
表示するつもりがいきなり：
"ウチの課長ってサイッテーェ！よぉ。自分が部長に注意されたからって、
わざわざ部長の前に呼びつけておいてネチネチと絡むなんてさぁ。
自分も書類チェックしたんだから、課長も責任あんのよぉ。これから課長
なんてすっ飛ばして部長に直接書類出しちゃおうかしらぁ！…")
こんな給湯室での雄叫びが画面に表示されたりたらびっくりします。
プログラムも同じです。
課長はもっと…。
int 花子； //花子の中味は数字？。
花子 ＝ "あの課長のおかげで朝から気分だいなしよぉ…"；
/*コンピュータに嘘ついちゃいけません。
エラーになります。（花子さんも根は結構、しつこいようです。高原の恋人の
先が思いやられるか…）*/
花子 ＝ ２０；//これが正しい。
このように中味が変容するものを英語でVariableと言います。
ぴったりの表現です。ところが最初にこれを翻訳した日本人が算数の得意な人
だったようで変数と訳してしまった。
例えば：
「貴女の場面に応じたVariableなところが、
いつも新鮮な感じを僕に与える…」それを、「変数なところが…」では…
ちょっと意味が通じません。
Variableって結構使えますよね。
コロッコロッと相手によって態度を変える
ブリッ子には特に…。
お気づきでしょうか。これまでのプログラム中に「//」や「/* 〜 */」が
出てきました。これはコメントのサインです。
Javaのプログラムにとって「//」の前後と「/* 〜 */」の内外では雲泥の
差が生じます。コメントはプログラムの製作者の意思を自らや他の製作者に
伝えたりするためにあります。また上記の誤ったコードに：
// 花子 ＝ "あの課長のおかげで朝から気分だいなしよぉ…"；
斜線を二本入れることでプログラムから認識できないようにすることが
可能です。
課長からも…。
確かに存在するがプログラムからは見えないのです。
私達のまわりには認識できないメッセージやかってのプログラムがあふれて
いるのかも知れません。
脚注です。
女性の気分はころころ変化します。
でも、見られている自分が心に刷り込まれているので
あくまで表面的なんです。
つまり、恋人と居ると楽しい、課長に朝から叱られるのは
面白くない。っと、見られている自分が判断しているのです。
言ってしまえば中味が空っぽなんです。
周りがそう思うだろうから、自分もそうなっているだけなんです。
泣いたり怒ったりします。ころころ変わります。
深い意味はありません。深い意味がないからころころ変われるのです。
負け犬でも勝ち犬でも周りがそう思うだろうから、そう思うだけ。
シャネルでもヴィトンでも本当はどうでもいいのです。
「どうでもいいから」拘る訳です。
長い人類の歴史のなかで商品価値的人生を生きざる得なかった。
結婚という商品マーケットから母性という子供の養育器的な、
愛情という名の空虚性に縛られまた他人も縛ってきたせいでしょう。
本質的には慎みや恥の感覚とは無縁の存在ではないでしょうか。
他者視線を意識するかどうかの問題であり、その他者視線こそが
商品価値を決定するものだからです。
目次へ
どうも「花子」だけではこんがらかるので
それぞれに名前をつけましょう。
例えば：
int 小学校の花子 = ６；
int 現在の花子 = ２０；
int 中年の花子 = ６０；
（最近、６０過ぎはまだ中年で十分通用するようです。
吉永小百合さんとか十朱久代さんとか…）
さて、現在の花子は二十歳ですが小学校の花子は６歳だけで
はありません。それをどうプログラムで表現するのでしょう。
いわば変数がたくさんあるイメージです。
（賢明なる筆者は「中年」をサンプルに選びません。
何故か？ 中年の入り口を若くすると怒られ、
じゃぁって出口を若くするとまた怒られるからです。
いくら平均寿命が延びたからって70過ぎて中年ってのは、どうも…）
それではプログラムです。
int 小学校の花子[ ]；
と名前の後ろに[ ]箱マークをつければ良いのです。
（int[ ] 小学校の花子；と書いてもかまいません。.）
これを配列（Array）アレー？と言います。そして、
小学校の花子 ＝ new int[6] ；
newなint整数の箱を6個用意して「小学校の花子」の配列に代入します。
これをまとめて、
int 小学校の花子[ ]＝ new int[6] ；// としてもＯＫです。
そして、
小学校の花子[0] = 6; 小学校の花子[1] = 7;
小学校の花子[2] = 8;小学校の花子[3] =9;
小学校の花子[4] = 10; 小学校の花子[5] = 11;
と箱の中に年齢（数値）を各々入れます。
[ ]の中はインデックス(添字)で、配列は
必ず0からスタートします。
でもこれでは学年と一致しません。
そこで、
小学校の花子[1] = 6; 〜 小学校の花子[6] = 11;
と入れてみます。これでうまく行くと普通は
思う、が、ArrayIndexOutOfBoundsExceptionと
エラーが表示されます。これは配列の範囲をオーバーして
いるという意味です。
ここが配列のアレー？なところ…。
小学校の花子 ＝ new int[6] ；
このすぐあと、まだ何も配列に代入する前、
System.out.println(小学校の花子[0]);
とプログラムして見ましょう。０が画面表示されますね。
つまりnewした時点で全ての箱には０が入った状態になって
いるのです。これを初期化（initialize）といいます。
暗黙のうちに小学校の花子[0] = 0 ; が生成され配列の数が
オーバーした訳です。
従ってインデックスと学年を一致させるためには、
小学校の花子 ＝ new int[7] ；
とする必要があります。
「ちょっとぉ、配列って結構メンドイわねぇ」と仰る貴女に
特別サービスです。
int 小学校の花子[ ] = [ 0,6,7,8,9,10,11 ] ;
とすればアレー不思議…例えば三年生の花子
の年齢を表示してみると、
System.out.println(小学校の花子[3]);
ちゃんと８が画面表示されます。
「はなっからそう説明すりゃぁいいじゃん。」って、
まあ説明には順序がありまして…。
但し、intの配列は中味に関して数値であれば、なんの制約も
ありません。（小数点付きの数値は駄目ですが…）
小学校の花子[3] = 60 ;
とすると、先生のママがご心配になってわざわざ授業参観に
ご臨席あそばされたのか！
と思うような「中年の」花子さんが小学校三年生の教室に現れ、
デ〜ンとふんぞり返っておられることになります。
（椅子がその重量に耐えられれば…）
配列とは関係ありませんが、あと少し。
世の中には変わって欲しくないものってありますよね？
例えば：
int お肌の年齢 ＝ 18 ；// とか…。
そのときは頭にfinalをつけましょう。よく効きますから…。
final int お肌の年齢 = 18 ;
これが変わらぬことへの想いを込めた定数です。
さらにこれにstatic(継続的に)をつけると
万全自若です。
static final int お肌の年齢 = 18 ;
これで貴女は永遠に（プログラムが終了する
までですが）18歳のお肌が保てます。
つまりその後不埒なプログラマーが
お肌の年齢 = 50 ;
とか書くとプログラムが貴女に代わって、文句を
（エラーよぉ！）言ってくれます。
（貴女の文句を言いたい気持ちを汲んでくれるのです。
但しエラーかどうかは…）
目次へ
基本的にプログラムは変数と代入プロセス
で構成され、そしてそれの繰り返しです。
しかしそれら頻繁に使用するものを一括り
にして名前を付けておけば便利と
プログラム言語の製作者は考えたのです
例えば：
int 花子；
花子＝50；
花子＝花子−30；//これを「若返り」と…
int 若返り（int 今の歳, int 若返り年）｛
return 今の歳−若返り年;
｝
これをメソッド（関数）とプログラムでは
言います。つまりメソッド名(若返り)の
左がreturnされるアウトプットのタイプで
ある（型）です。そしてメソッド名の右側の（）の中味が
メソッドからインプットされる
引数のタイプとメソッド中で使用される
名前です。その実際の加工プロセス（実装）
が｛ ｝の中の
return 今の歳−若返り年;
です。実にシンプルなメソッドではありますが、まさに、
これは、若さへの鬼気迫る執念を感じさせますよね。
これは別のプログラムから
int 外見＝若返り（70 , 50）;
と若返りメソッドを呼んで「外見」に代入し
System.out.pritln("外見");
とか表示したりして…
無駄な抵抗をされるのです。
んでもって、ほんのついでに「老ける」も：
int 老ける（int 今の歳, int 老ける年）｛
return 今の歳＋老ける年;
｝
これは説明しなくてもこれまでの若返りの
例でお分かりですよね。
「あぁ！あの＋記号が憎らしいっ。
いたずらに過ぎた私の青春時代はどこへ…」
メソッドにはアウトプットのないものもあり
ます。それをvoidメソッドと言います。
貯めるだけ貯めて自分は決して出さない
タイプと申しますか…。
例えば：
void バレバレ（String 相手 , int サバ）｛
System.out.pritln("いやぁねぇ、" +相手 +"若く見えても、
もうおばさんなんだからぁ。");
System.out.pritln("今年でもう"+ サバ +"になりますのよぉ。ホホホホ" );
｝
これを
バレバレ（"センセ", 55）；
でためしにバレバレメソッドを呼んでみましょう。
画面表示は下記の通りです。
「いやぁねぇ、センセ若く見えても、もうおばさん
なんだからぁ。今年でもう55になりますのよぉ。ホホホホ」
勘の鋭い女性は最後のホホホホの最後の一つ
が余分であることを決して見逃しません。
余分の「ホ」一つ10歳が相場とか…。
メソッドにはアウトプットもインプットも
ないものも実は存在するのです。
void ウットリ（）｛
System.out.pritln("露天風呂キッモチイー！")
｝
たとえvoid で（）なメソッドでも、これで
日本全国疲れたＯＬの心からの叫びが今、見事画面に
表示されるのです。（オフィスでは止めたほうが…）
特に紅葉でも初雪でも眺めながらキリッとした冷気を
お湯でほてった頬に感じながら身体はお湯のなかで
とろけている状態は確かに最高じゃありませんか。
プログラム的には虚しい(void)、まるで意味のない
（）メソッドにしか過ぎません。
が、しかし、画面にちゃんと文章を表示して
るじゃないの、露天風呂で日頃の疲れを癒された
至福の気持ちが分かるじゃないの、と
まあ熟年に限りなく近づきつつあるＯＬならばそう思います。
この辺りがまだプログラムの至らないところ
でありまして、プログラム同士で互いに
アウトプット、インプットするときはタイプや
名前までつけたりするのにユーザーに対する
表示は単にvoid（）なんです。
どうです？同期の間では勤務中にも関わらず
ペチャクチャお喋りをする。
しかしこちらには報告しない、連絡しない、相談しない、
意思表示もしない、最近の新入社員とそっくりじゃありませんか。
無理解な課長と若いだけでチヤホヤされる
こんな新入社員に囲まれ徐々に居づらくなる
貴女の気持ちは痛いほど分かるつもりですから…。
脚注です。
「長い人類の歴史のなかで商品価値的人生を生きざる得なかった。
結婚という商品マーケットから母性という子供の養育器的な、
愛情という名の空虚性に縛られまた他人も縛ってきたせいでしょう。
本質的には慎みや恥の感覚とは無縁の存在ではないでしょうか。
他者視線を意識するかどうかの問題であり、その他者視線こそが
商品価値を決定するものだからです。」
前回の脚注でこのような発言を致しましたが、これは別に
Aranskの独自見解でもなんでもありません。
古くはヴォーボワール、最近ではジュディス・バトラーなどの
フェミ系論者やラカン、ジジェクなどの思想家が展開している
この業界ではほぼ常識的な話題です。
基本的には女性の環境依存性の高さから帰結されている解釈です。
つまり産む作業、育てる作業は多かれ少なかれ巣を作らないと
出来ません。一定期間環境から保護される必要があるのです。
そこに女性としての土着性、親原始性が発生する所以なんです。
母性とは言い換えれば自然性です。女性の脳容量が男性のそれと
比較して平均10%程度小さいのもこの自然性によるものです。
動物生理学的に脳容量の肥大化は反自然性を生むとも解釈されます。
自然環境や地域社会の絆から切り離されて女性の依存性が
満足されない。他者視線に迎合的な女性固有の文化制度的商品特性
だけが極大化傾向にあるため、出産や子育てに消極的なんじゃ
ないでしょうかねぇ。
もっとはっきり言ってしまえば自らの本能的な空虚さを犠牲にして
負け犬が勝ち犬化しつつあるように思えます。
さらに出産、子育てもその本能的な満足よりも他者視線的
満足ー＞有名幼稚園、有名小学校に母親（勝ち犬）として
出席すること自体に憧れている部分はないのでしょうか。
目次へ
いくら初心者でもあまりに簡単過ぎないか？との指摘があり
このマイナーなＨＰを見る程度にプログラムに関心がある
皆さんのために少し内容をグレードアップしてみました。
さて、Javaの大幅なヴァージョンアップであるJDK 5.0がサンマイクロ
システム社より今秋リリースされました。単なるライブラリーや
標準クラスの追加に止まらす言語自体にも新たなパラダイムが付加され
読者の皆さんも今使い勝手を試しておられる段階ではないでしょうか。
そこで具体的にどのような新機能の活用方法があるのか、そのサンプルを
ご参考に提供したいと考えたのが今回企画の一つの狙いです。
またご承知の通り、減損会計の導入は日本の会計ビッグバンの総仕上げ
と称されるほど大きなインパクトを企業経営に与える制度変更となります。
既に早期適用している企業もありますが、いよいよ来年4月1日以降開始
する事業年度より全企業連結ベースで強制適用となります。
未だ実施してない企業は今期の中間決算発表後、来年の期末決算までに
その準備を完了させなければなりません。いや、来期の年度事業利益計画
及び中長期計画の策定作業そのものが減損会計算定のベースとなります
から事実上もう適用段階に入っていると申し上げてもよいのではないでしょうか。
JavaにおけるビッグバンJDK 5.0の新機能をもって会計ビッグバンの掉尾を
飾る減損会計理論を本記事の題名通りJavaと会計のための繰り返し（for）
ビッグバンを起こしたい。
Javaのプログラミングパラダイムで減損会計をどう解釈しどうモデル化が可能なのか。
ビジネスの最前線にとってJavaはどのような分析力を示すのか。
といったテーマについて、さりげなくビジネス・プロセス上のヒントと、笑えない
ギャグを織り交ぜながら今回と次回の二回に渡って読者の皆さんと一緒に挑戦して
みることにします。
では、早速、架空の典型的な大手メーカー企業における減損会計制度導入の
対応状況をJavaでプログラム化してみます。
プログラム内の会話は当然、全てバーチャルリアリティーの世界での話です。
/*
* Created on 2004/11/24
* @author Aransk
*/
//Joukyou.Javaです。
/*
* 通常頻繁に使用される「System.out.println」を可読性の
* 高い 「表示」としてメソッドを作成しstatic修飾子を
* 付加することにより全てのクラスで共用出来るようにします。
* またString引数名も「内容」とします。
* 本来なら文字列以外でjavaのプログラム中に全角漢字を
* 使用することはあまりお奨め出来ません。が、プログラムは
* 最低限正常に動作します。従ってプログラミングの作業効率や
* マシーン負荷よりも、読者の皆さんの可読性を
* をより優先するため最大限日本語を使用することにします。
* これは「ひまわり」という日本語プログラミング言語からヒントを
* 頂戴いたしました。「ひまわり」は分かり易い、お奨めの言語です。
* さすがに、クラス名だけは漢字を使用できないのでTool(道具)
* を略して「class T」とします。
*/
class T {
static void 表示(String 内容) {
System.out.println(内容);
}
}
//super classとして登場人物ToujouJinbutsuを定義します。
class ToujouJinbutsu {
//某社における職位です。
String 職位;
//発言メソッド定義です。
void 発言(String メッセージ) {
T.表示(職位 + "：" + メッセージ);
}
}
//某社の財務担当常務class Joumuです。ToujouJinbutsuを継承して
//おります。
class Joumu extends ToujouJinbutsu {
// クラスのコンストラクターです。
public Joumu() {
職位 = "常務";
}
}
//某社の秘書class Hishoです。
class Hisho extends ToujouJinbutsu {
// クラスのコンストラクターです。
public Hisho() {
職位 = "秘書";
}
}
//本編の主人公Yonです。本来呼び方は余雲（ヨウン）が正しいのですが、
//某国著名俳優に白くて細い「指先だけ」が似ていると言われ、
//それ以来Yonが愛称となっております。
class Yon extends ToujouJinbutsu {
//主人公だけは名前を定義します。
String 名前 = "Yon";
//super classの定義をOverrideします。
@Override void 発言(String メッセージ) {
T.表示(名前 + "：" + メッセージ);
/*
* この「@Override」がJDK5.0から新規に採用されたアノテーション機能
* の一つです。例えばスーパークラスのメソッドをOverrideするつもりで
*「発言」を「発音」と間違って書くと下記のようなコンパイル時エラーで
* 知らせてくれる機能です。
* 「Joukyou.java:46:メソッドはそのスーパークラスのメソッドを
* オーバーライドしません。@Override void発音(String メッセージ)」
* C#のoverride,new Keyword とほぼ同様の機能です。
* 但しC++ではこのような機能はありませんから、C++と比較すれば安全性は
* 高まったと評価しても良いのではないでしょうか。
*/
}
}
public class Joukyou {
public static void main(String args[]) {
Hisho 秘書 = new Hisho();
秘書.発言("Yonさん、常務がお呼びです。");
//あくまで「さん」であって「様」でないところが「指先だけ」の寂しさです。
Yon Yon = new Yon();
Yon.発言("はい、すぐ参りますとお伝え下さい。");
Joumu 常務 = new Joumu();
常務.発言("どうかねYon君、減損会計の\n" + "進み具合は？");
Yon.発言("そうですねぇ、一応この正月休み辺りが\n"
+ "正念場になる見込みです。");
常務.発言("各事業本部長を始めとして事業部長や関連会社の社長にも、\n"
+ "減損会計は待った無しだ。\n"
+ "例年より１ヶ月早いが来年度からの利益計画を\n"
+ "12月半ばにはまとめろ！とハッパをかけているのだからね。");
Yon.発言("承知しております。これまでの３年間で段階的に本部レベルと\n"
+ "事業部レベルでそれぞれ資産グルーピングを行い、その\n"
+ "試算結果を逐次取締役会にてご報告しております。\n"
+ "今回はSBU単位(Strategic Business Unit=製品機種別)、\n"
+ "まさに最小キャッシュ・ユニット・ベースの資産グルーピング\n"
+ "における資産効率、使用価値のシミュレーションと\n"
+ "なる次第です。8本部、46事業部、528 SBUの総決算と\n"
+ "なる訳です。");
常務.発言("それに自社工場27（内、海外5）、連結子会社83（内、海外18）、\n"
+ "持分法適用会社56が重層的に\n"
+ "かつマトリックス的に相互構成されているの\n"
+ "だから確かに我社創立以来の大経営プロジェクトが\n"
+ "陽の目を見る訳だ。");
Yon.発言("");
常務.発言("");
Yon.発言("");
常務.発言("");
Yon.発言("");
常務.発言("");
Yon.発言("");
常務.発言("");
Yon.発言("");
}
}
実行結果は下記の通りです。
秘書：Yonさん、常務がお呼びです。
Yon：はい、すぐ参りますとお伝え下さい。
常務：どうかねYon君、減損会計の
進み具合は？
―以下プログラム通りですので省略します。―
但し、前記コード以後の会話内容については下記の通り
プログラムする予定でした。
（Ｊ：常務、Y：Yon）
Y：常務のご指示である「現場最優先！、決して各現場の個性と多様性を失って\n
はならん。それぞれの現場における品質、スピード、\n
コストが最適になるよう本社側=統合側が知恵を絞れ！」\n
これには本社の財務本部、生産開発本部、情報システム本部\n
の連中が泣いていましたよ。\n
Ｊ：良いかね、前々から言っているように減損会計制度導入は\n
リバレージ（梃子）にしか過ぎないんだよ。\n
真の国際競争力を日本企業が回復軌道に乗せられるか\n
どうかは、今が、正念場だ。日本における製造業の空洞化を\n
食い止めるには設備資産効率と人材効率を最大限に\n
高める以外に方法はないんだ。その為の経営基盤を\n
構築しているんだからね。単なる会計基準の適用\n
不適用レベルで物事を考えてもらっちゃ困るんだよ。\n
だから生産本部の精鋭を選抜してそれぞれの現場に貼り付け\n
物の動き、人の動き、設備の稼動状況、そして現場で働く
全ての人々の心、身、の健康をも含めた「総合安全性」をチェック\n
しながら再構築しているんだからね。完全に現場に密着した\n
現場のためのプロジェクトであることを\n
忘れてもらっちゃ困るよ。\n
Y：特に情報システム本部は苦労しているようです。\n
これまでは本社側で必要な情報のインタフェースを\n
示して、それに流し込むまでは事業本部や関連会社側で\n
やっていましたから。今回は多様な生情報をそのまま\n
受け入れて連結グループ全体のシミュレーションが出来るまで\n
本社側で組み上げる訳ですからね。\n
常務が指示された「財務や固定資産情報だけでなく\n
その稼働率や各現場のバランスド・スコアカード的な\n
予実対比まで取り込み」ましたからね。それも\n
過去５年間分と今後５年間の中期計画分及び今後１０年間の長期計画分\n
ですから、膨大なデータ量になります。\n
データ件数で５０〜１００億、容量で２テラバイトは超えると\n
思われます。\n
/**「バランスド・スコアカード」とは歩留まりや仕損比率、
クレーム件数やそれに対する処理時間短縮率など財務会計数値
以外の目標指数です。顧客満足度を高めるために企業
として目標を具体的な数値で示し、経営状況をモニターする
仕組みです。*/
J：今年の正月休みはシステムトライアルで\n
完全に返上だね。まぁシミュレーションが主体だから\n
さしあたり会社の直接業務に支障が出ることはないが\n
結果によっては今期中に処理しなけりゃならん資産もあるはずだ。\n
また４月からは膨大な生データを直接リアルタイムで\n
受け入れるようになるからね。\n
当面は月次で稼動させる予定だが、再来年は経営会議での\n
議論を直接リアルにシミュレーション出来るように\n
することも考えているから…。
Y：月次稼動だけでもアップアップですから、常務、今からそんなこと\n
を言って脅かさないで下さいよ。私自身の心の安全はどうなるんですか？\n
Ｊ：システム業界でも「Least Astonishment」（驚き最小限の法則）って言うらしいね。\n
だから、予め「覚悟だけ」はしておいてもらおうと思ってね。\n
ワッハ、ハ、ハ…。\n
多分、全国の大手メーカー各社の重役室では「ワッハ、ハ、ハ…。」を除き、ほぼこの
ような会話が進行中と推定されます。
本誌の読者の中には減損会計は大手ゼネコン、不動産業者、又は上記のようにメーカーで
土地や設備に関する問題に限定されるとお考えの方もおられるのではないでしょうか。
しかしながら資産の中にはソフトウェア資産も当然含まれております。開発が完了した
時点で総費用は貸借対照表上の長期前払費用に計上され５年間均等償却されます。
これまで費用対効果が議論されるのは主に開発計画書段階でした。一旦開発が開始されて
しまえば少々納期が遅れようが費用が増大しようが、最終的に稼動すれば「高いものに
ついたな。」程度で済んでいた部分もあったと聞いております。
ところが減損会計が適用されれば、全ての資産が将来キャッシュフローにどのように貢献
しているのか？という視点から毎期見直されることになります。今後はメンテナンス
やアドオン費用などが詳細にカウントされソフトウェアのトータルライフで収支はどう
なるのか？システム導入による費用削減効果とシステムにつぎこんだコストは現実に
前者が後者を上回っているのか？…といった観点がより一層クローズアップされます。
ご承知の通りＩＴ化にともないソフトウェア資産はバランスシートの中でビッグバン
現象を起こして膨張しております。アメリカで企業がソフト開発、メンテナンスを
オフショア化―インド・中国への海外外注―を進めているのは、このような会計基準や
資本マーケットからの圧力を経営者が厳しく受け止めていることも原因の一つといえ
ましょう。上記の重役室の会話における「スピード、品質、コスト」最優先はソフト
ウェア産業にも当て嵌まります。これまでのような元請け、中請け、孫請け的なジェネ
コンスタイルのシステム業界体質を見直す必要が出て来ます。
階層型構造が無くなるとは思いません。しかし、それぞれのベンダーがスペッシャリ
ティーを活かしながらクラスやモジュールを組み上あげてゆくといったオープンで
フラットな協業が模索されるようになるでしょう。
確かに減損会計の適用はシステム開発需要を起こす誘因ではありましたが、これは
システム業界にとっても諸刃の剣であることをくれぐれもお忘れなきよう。
さて、あまり余談でページを埋めているとプログラムスキル貢献度の観点から
減損評価？されるといけません。
上記プログラムの結果をディスプレーで見るだけではなくテキストファイルに
会話内容を落として自社の参考にしたいとします。
さて皆さんはどうされるでしょうか？
色んな方法が考えられますがclass Tに注目された方はなかなか鋭い着眼です。
ArrayListを作成して表示メソッドが呼ばれるたびに内容をそれに格納すればどうで
しょう。
class T {
static String 文章 = "";
static ArrayList 会話 = new ArrayList();
//ArrayList会話の作成です。
static void 表示(String 内容) {
System.out.println(内容);
会話.add(内容);
//ArrayList会話に内容を追加します。
}
}
そしてテキストファイルに落とす前にうまく作動するかどうか試してみます。
public class Kiroku {
public static void main(String args[]) {
Hisho 秘書 = new Hisho();
秘書.発言("Yonさん、常務がお呼びです。");
Yon Yon = new Yon();
Yon.発言("はい、すぐ参りますとお伝え下さい。");
Joumu 常務 = new Joumu();
常務.発言("どうかねYon君、減損会計の\n" + "進み具合は？");
//ArrayList会話から要素を取り出してそれを表示させます。
for (int 回数=0;回数＜T.会話.size();回数++){
String 記録 = (String)T.会話.get(回数);
T.表示(記録);
}
}
}
どうでしょう？
こりゃぁ、まずいじゃないか！
と、一目で気付かれた貴方のプログラミング能力は正直、筆者を凌駕されておられます。
T.表示(記録); ！！
クライアントのmainからclass Tのメソッドも呼び出せるのでうっかりし勝ちですが、
これでは無限ループしてしまいます。Eclipseで確認しました。（確認させられたが正しい？）
Eclipseの無限ループをご覧になった方はおられるでしょうか？
さすがにEclipseです。止まりません。
あれほど細かくチェックしてアラームを出すEclipseでも無限ループは避けられません。
何故、無限ループのごとき危険なマシーン動作に対してアラームを出さないのか？
Windows Programmingの場合にアラームが出っぱなしになるからです…
そもそも11月末本稿執筆時点ではEclipse3.01がJDK5.0対応になっておりません。
使っている方々はお分かりの通り一度Eclipseに嵌ったらコーディングに対する
注意力が半減します。Eclipseの行き届いたコードチェックとアラームに浸りきってしまう
からです。
では、今、現在どうしているのかと申しますと、いったんはJDK1.4ベースでEclipse上
にてコーディングした後、それをフォーマットし、コード全体をNotePadに貼り付け、
さらにそれをJDK1.5ベースに書き換えたあげく、DOS窓からjavacしている次第です。
何行目エラーとDOS窓に表示されてもNotePadに行番号はありません。
来年早々にはこれが懐かしい昔話になっていることを切に願っております。
そこで、ここは
//T.表示(記録);
System.out.println(記録);
としなければなりません。
すると、結果は：
秘書：Yonさん、常務がお呼びです。
Yon：はい、すぐ参りますとお伝え下さい。
常務：どうかねYon君、減損会計の
進み具合は？
秘書：Yonさん、常務がお呼びです。
Yon：はい、すぐ参りますとお伝え下さい。
常務：どうかねYon君、減損会計の
進み具合は？
こうなります。
（二回も常務から進捗状況を確認されるのはYonもあまり気持ち良くないでしょうが…）
さて、ここからが本題です。
String 記録 = (String)T.会話.get(回数);
先程のプログラムのすぐ上です。従来のJDKではこのようにキャストが必要でした。
それが今回JDK5.0ではジェネリクス機能が追加されたのでそれが不要になったのです。
これはＣ＃も未だ実現しておりません。
String 記録 = T.会話.get(回数);
これで済みます。とにかく、コードがキャスト無しで利用出来るのは大きな進歩です。
さらに
for (int 回数=0;回数＜T.会話.size();回数++){
これも
for (String 要素 : T.会話){
と今回foreach的機能が追加されたのです。
普通はforeach 要素 in コレクション的なコーディングスタイルが多いのですが、Java
ではこれまでのfor文との整合性をとったとのことです。
慣れればfor (要素 : コレクション)の方が書きやすいと思われます。
従ってこのforeach機能を使用すれば
for (String 要素 : T.会話){
String 記録 = 要素;
System.out.println(記録);
}
格段にすっきりしたコードになりました。
但しclass T { の中で定義している
static ArrayList 会話 = new ArrayList();
これは
static ArrayList＜String＞ 会話 = new ArrayList＜String＞ ();
とジェネリクス的< >を使用して書き直す必要があります。
では最後に、これはJDK5.0の新機能ではありません。
しかし、いちいちテキストに落とすためのtry catch構文のエラー処理や、
先程の簡単になったとはいえfor (String 要素 : T.会話)のようなfor文を
クライアントのmainメソッドに書きたくない方のために。
特に悪夢の無限ループを再現させる可能性の高い人のために
（つまり筆者のために）class Tの道具にもう一つメソッドを追加しましょう。
static void テキスト変換(String 保存ファイル,String 追加_上書きモード){
//追加上書きモードを文字列で指定できるようにします。
Boolean 真偽;
if (追加_上書きモード == "上書き"){
真偽 = false;
}else{
真偽 = true;
}
try{
PrintWriter 出力 = new PrintWriter(new BufferedWriter
(new FileWriter(保存ファイル,真偽)));
for (String 要素 : T.会話){
String 記録 = 要素;
出力.println(記録);
}
出力.close();
}catch(IOException e){
System.out.println("err: " + e);
System.exit(1);
}
}
これで後はクライアントのmainメソッドには保存ファイルを追加モードにして
T.テキスト変換("報告.txt","追加");
と一行付け加えればＯＫです。
さらに、「安全は全てに優先」します。従ってT クラス内の紛らわしいメソッド名
"表示"は"クラス内専用_会話内容"とクラス内専用prefixを追加しましょう。
また、「常に事件は現場で発生します。」
下記コメントを現場であるmainメソッドの直前に掲げることで、何らかのプログラム
修正の際にうっかりこのメソッドを使用しないよう注意を喚起することにいたしましょう。
/*
* 注意：クラスＴのstaticメソッドである
* 「クラス内専用_会話内容」を mainメソッド内で
* 直接使用すると無限ループが発生する。
*/
このようにクラスのStaticメソッドは慎重に利用しさえすればRuby・Groovyの
モジュールMixinやAspect志向的なことも可能になります。
是非色々と工夫してみて下さい。
では最後に確認の意味でプログラム全文を掲載いたします。
import java.util.*;
import java.io.*;
/*
* Created on 2004/11/26
* @author Aransk
*/
//KirokuJDK5.Javaです。
class T {
static String 文章 = "";
static ArrayList＜String＞ 会話 = new ArrayList＜String＞();
//ArrayList会話を作成します。
static void クラス内専用_会話内容(String 内容) {
System.out.println(内容);
会話.add(内容);
}
static void テキスト変換(String 保存ファイル,String 追加_上書きモード){
boolean 真偽;
if ( 追加_上書きモード == "上書き"){
真偽 = false;
}else{
真偽 = true;
}
try{
PrintWriter 出力 = new PrintWriter(new BufferedWriter
(new FileWriter(保存ファイル,真偽)));
for (String 要素 : T.会話){
String 記録 = 要素;
出力.println(記録);
}
出力.close();
}catch(IOException e){
System.out.println("err: " + e);
System.exit(1);
}
}
}
//super classとして登場人物ToujouJinbutsuを定義します。
class ToujouJinbutsu {
//某社における職位です。
String 職位;
//発言メソッド定義です。
void 発言(String メッセージ) {
T. クラス内専用_会話内容(職位 + "：" + メッセージ);
}
}
//某社の財務担当常務class Joumuです。
class Joumu extends ToujouJinbutsu {
// クラスのコンストラクターです。
public Joumu() {
職位 = "常務";
}
}
//某社の秘書class Hishoです。
class Hisho extends ToujouJinbutsu {
// クラスのコンストラクターです。
public Hisho() {
職位 = "秘書";
}
}
//本編の主人公Yonです。
class Yon extends ToujouJinbutsu {
//主人公だけは名前を定義します。
String 名前 = "Yon";
//super classの定義をOverrideします。
@Override void 発言(String メッセージ) {
T. クラス内専用_会話内容(名前 + "：" + メッセージ);
}
}
public class KirokuJDK5{
/*
* 注意：クラスＴのstaticメソッドである
* 「クラス内専用_会話内容」を mainメソッド内で
* 直接使用すると無限ループが発生する。
*/
public static void main(String args[]) {
Hisho 秘書 = new Hisho();
秘書.発言("Yonさん、常務がお呼びです。");
Yon Yon = new Yon();
Yon.発言("はい、すぐ参りますとお伝え下さい。");
Joumu 常務 = new Joumu();
常務.発言("どうかねYon君、減損会計の\n" + "進み具合は？");
//以降の会話は省略します。
T.テキスト変換("報告.txt", "追加");
}
}
如何だったでしょうか？
JDK5.0の主要な機能のみ減損会計の企業における取り組み状況と併せて紹介いた
しましたが、ご理解頂けたでしょうか？
今回のJDKのバージョンアップは他の言語が先行している機能を取捨・選択しながら
Java言語側がjava スタイルで取り込んだ形となっております。これはマイクロソフトの
常套手段なのですが、今回はサンの方がお株を奪った形です。マラソンと同じですね。
どこでスパートして競争者に追い着き、それを追い越すか、ビジネスでも重要なKey_
Pointになるようです。
本稿では特に紹介はしませんでしたが、
int 整数 = 10000;
double 小数点付き数値 = 1052.34;
String 文字列 = "いろはにほへと";
System.out.printf("%d %,5.2f %s\n",整数, 小数点付き数値, 文字列);
printf…まるで時代が逆行したかのような懐かしい？機能も復活しております。
今はまだSDK5.0に対応したツールは少ないようですが是非ご自分でお試し頂けたら
と思います。
またクラスのstaticメソッドはいったん定義すれば
PrintWriter 出力 = new PrintWriter(new BufferedWriter(new FileWriter
(保存ファイル,真偽)));
このような面倒なコードをいちいちクライアント側でタイプする必要は無くなります。
但しstaticメソッドの怖さも実例でご紹介しました。
No Risk No Return はビジネスだけではありません。
ご存知でしょうか？
GroovyというJava用のスクリプト言語の場合は変数もメソッドも宣言しなければ
全てpublicだそうです。国際会計基準の潮流と同じく情報開示がプログラミングの
世界でも主流になってゆくのかも知れません。
次回はいよいよ減損会計制度をJavaでモデル化しその本質に迫ります。
ご期待下さい。
以上
脚注です。
減損会計は巷間、問題視されているように、企業側の恣意性が
入り込む余地は確かにあります。
仕組み自体が定着するまで、制度監査の現場において公認会計士と
企業側との間で具体的に詰めなければならない問題が頻発すると
思われます。またその問題の処理基準は法令に規定されておりません。
公認会計士協会の減損会計適用指針そのものが現場に丸投げ状況です。
つまり将来計画の確実性を担保する手段がないのですから、個々の場面に
おける公認会計士の判断に委ねざる得ないのです。
しかしながら、会計基準の国際化の流れだけはprintfなんかと違って
逆行することは出来ません。
具体的に申し上げれば従来の管理会計と制度会計を融合した形での
新たなアカウンタビリティーを企業が資本市場から要求されているのです。
減損評価の判断基準である将来割引前キャッシュフローを生み出す行為
自体にこのアカウンタビリティー能力が組み込まれております。
本来、企業の業績を報告するためのアカウンタビリティー能力は
利益を説明することが目的であり利益を生み出す行為では
なかったのです。
ところが今後は企業の将来計画を説明することが、それに対する
マーケットの信頼を得ることが、即、将来キャッシュフローの成否に
影響するのです。市場が納得しないキャッシュフロー計画は
成立しなくなるのです。
プログラムのアルゴリズムで申せば再帰的な企業の営為と申せましょう。
自らの企業行動を説明することが企業自体の存立に影響を及ぼすのです。
この再帰性ゆえに、法令適用精度が向上すればするほど企業間格差と
能力差異は拡大されます。
このような経営環境においては、正確で、迅速な、情報自体が力です。
システムに多かれ少なかれ関与されておられる読者の皆さんの働き自体が
企業の盛衰を左右するKey For Success(KFS)である、時代に、既に、常に、
入っているのではないでしょうか。
目次へ
前回はJDK5.0の新機能の紹介と減損会計の導入状況に主眼を
おいてみてゆきましたが、今回は会計理論（減損会計）の
ビジネスロジックをJavaでモデル化することを中心に
話を進めたいと思います。現実のシステムはエラートラップや
トランズアクション処理及びデータベースとのやり取りなどが
重層的にプログラムされており、ビジネスロジック自体は
その中に埋もれてしまいがちになります。
１）そこで減損会計ロジックそのものの説明をも含めた形で
モデル化したいと考えております。そこでデータはCSVファイル
より読み込み、データ処理結果もCSVファイルに書き込む
シンプルな形で説明します。
実際の企業におけるシステムは固定資産システムや会計システムなど
と分散化されて運用していると思われるます。いわばデータ授受を
CSVファイルで行うイメージです。アウトプットもCSVファイルで
あればエクセルでもアクセスでも自由に読み込め二次加工も簡単に
行えますから一般ユーザーも扱い易いのではと考えた次第です。
２）さらに普通は要件定義書からUMLに展開しそれからコーディングと
いう順序になりますが、今回はいきなりJavaでコーディングしながら
会計理論の説明を行います。
アラン・ケイがオブジェクト指向言語に期待した、人間の思考概念形成の
ためのツールとしてJavaを利用します。
完成された構造からコーディングを行うのではなく、試行錯誤的
にクラスを作って行きます。作ったプログラムの作動をその場で
皆さんと一緒に体験しながら、まるで筆者と皆さんがエクストリーム手法に
おけるペアープログラミングをしているかのごとく作業を進めたいと考えて
おります。さりげなく、ビジネス・プロセス改善のためのヒントとホワイト
オープニング・ギャグを織り交ぜつつ。
では早速ざっくりと減損会計の核心部分をプログラム化してみましょう。
/*
* Created on 2004/12/04
* @author A.Uchiyama
*/
//GensonHantei.javaです。
//最初は前回も使用した道具class Tです。System.out.printlnを「表示」
に変換します。
class T {
static void 表示(String 内容) {
System.out.println(内容);
}
}
class Hantei {
String 資産名;
int 資産帳簿価格;
int 正味売却価格;
int 使用価値;
Hantei(String str, int x, int y, int z) {
資産名 = str;
資産帳簿価格 = x;
正味売却価格 = y;
使用価値 = z;
}
void 判定() {
if (正味売却価格 ＜ 資産帳簿価格 && 使用価値 ＜ 資産帳簿価格) {
T.表示(資産名 + "は減損状態にあります。");
} else {
T.表示(資産名 + "は減損状態ではありません。");
}
}
}
public class GensonHantei {
public static void main(String[] args) {
Hantei ケース1 = new Hantei("機械設備", 40, 50, 70);
ケース1.判定();
Hantei ケース2 = new Hantei("建物", 100, 50, 70);
ケース2.判定();
}
}
結果は：
"機械設備は減損状態ではありません。"
"建物は減損状態にあります。"
となりますね？
つまり、
if (正味売却価格 ＜ 資産帳簿価格 && 使用価値 ＜ 資産帳簿価格) {
T.表示(資産名 + "は減損状態にあります。");
これからお分かりのように、これだけなんです。
本来企業が貸借対照表に資産を計上できるのは、将来それが価値を
生むからです。実際の正味売却価格や使用価値より高く資産が計上
されているのは、明らかに過大評価されているからです。
それを現実に合わせましょうというのが減損会計の趣旨です。
但し、逆はありません。事業用の固定資産が値上がりしても
それは評価しません。
起こるべき損は早めに開示しますが、未実現（売却前）の利益は評価しないのです。
投資家や債権者を保護するために企業の財務内容の健全性を保つことが
何より優先されるからです。
この点については法人税法と食い違います。減損を損金として国税庁は認めません。
税金を課すべき所得額が少なくなるからです。従って減損を計上する企業に関しては
損益は悪化するわ、税金は取られるわ、という事態になる訳です。
前回の会話編にもありましたように経営者としては資産効率を高める以外に道は
ないのです。それとも、資産バブルの復活を神頼みするか…。
（国際的な資金の流れ次第で、投機対象が変化しますから資産バブルの再燃も
有り得ないとは断言できません。神頼みも一つの経営決断と言えなくもない？）
では前期GensonHantei中にある帳簿価格をどうして算定するのか、コーディングして
みましょう。
/*
* Created on 2004/12/04
* @author Aransk
*/
//ChouboKakaku.javaです。
//Eclipseでコーディングしておられる方はGensonHanteiと同じプロジェクトに
//ChouboKakakuも入れておけば、いちいちclass Tを定義する必要はありません。
class T {
static void 表示(String 内容) {
System.out.println(内容);
}
}
class ShisanChoubo {
String 資産名;
int 資産帳簿価格;
int 取得価格;//資産を取得した時点の価格。
int 減価償却累計額;//今期末まで毎期減価償却してきた累計額。
ShisanChoubo(String str, int x, int y) {
資産名 = str;
取得価格 = x;
減価償却累計額 = y;
}
int 帳簿価格算定() {
資産帳簿価格 = 取得価格 - 減価償却累計額;
T.表示(資産名+"の帳簿価格は"+資産帳簿価格+"です。");
return 資産帳簿価格;
}
}
public class ChouboKakaku {
public static void main(String[] args) {
ShisanChoubo ケース1 = new ShisanChoubo ("機械設備",70, 30);
ケース1.帳簿価格算定();
ShisanChoubo ケース2 = new ShisanChoubo("建物", 100, 50);
ケース2.帳簿価格算定();
}
}
結果は：
"機械設備の帳簿価格は40です。"
"建物の帳簿価格は50です。"
となります。
定率法や定額法によるそれぞれの資産の減価償却計算過程自体は減損会計システムには
織り込みません。通常は既に計算された結果を固定資産システムのデータベースに
保有されていると思われるからです。
これまでのプログラムの流れでお気づきの通り、トップダウン方式でクラス構造を
作成しております。また作る度に作動結果をmainのメソッドの中で確認しながら
着実に作業を進めます。オブジェクト指向言語の良い点はトップ・ダウンでも
ボトム・アップでもミドル・エクスパンションでも自分がやりやすいように
コーディング出来るところにあります。
自らの思考の過程を素直に表現することが何よりも大切です。
筆者の場合はスタートはトップ・ダウンでロジックの中心部分はミドルエクスパンション
最後ボトムアップで細かい点をフォローして完成させるスタイルが気に入っております。
また、これは個人的な趣味の問題かもしれませんが、最初はクラスの粒度を小さくして
たくさん作っておき、あとで纏めるなり、インターフェースやミディエーターパターンで
関連させる方が、大きなクラスを後で分割するよりうまく行くような気がしております。
皆さんも色んなパターンを試しながら得意な方法を見つけて下さい。
要は最後に動けば良いのですから…。
では、同じ要領で正味売却額の算定もコーディングしてみます。
/*
* Created on 2004/12/04
* @author Aransk
*/
//ShisanBaikyaku.javaです。
class T {
static void 表示(String 内容) {
System.out.println(内容);
}
}
class Baikyaku {
String 資産名;
int 正味売却額;
int 売却価格;//公正な市場価格又は売却見積書額
int 売却に要する費用;//資産売却に要する費用、撤去、運搬、整地費用など
Baikyaku(String str, int x, int y) {
資産名 = str;
売却価格 = x;
売却に要する費用 = y;
}
int 正味売却価格算定() {
正味売却額 = 売却価格 - 売却に要する費用;
T.表示(資産名 + "の正味売却額は" + 正味売却額 + "です。");
return 正味売却額;
}
}
public class ShisanBaikyaku {
public static void main(String[] args) {
Baikyaku ケース1 = new Baikyaku("機械設備", 70, 10);
ケース1.正味売却価格算定();
Baikyaku ケース2 = new Baikyaku("土地", 100, 20);
ケース2.正味売却価格算定();
}
}
実行結果は：
"機械設備の正味売却額は60です。"
"土地の正味売却額は80です。"
となります。
帳簿価格も売却価格の算定も、特に説明を要するほどの問題もなく、
スムーズに作業は進捗いたしました。さて、これからが減損会計の核を
構成する部分です。
最後に残った資産の「使用価値」は何で計測すれば良いのでしょうか。
土地やビルは売れます。しかし機械設備などは同業者にしか売却できませんし、
事実上稼動設備を買い取る場合に高値は殆ど望めません。
現在の使用者にとっての価値が最も高いのが普通です。設備自体を売却するより
事業そのものを企業分割して売却する方が選択肢としては可能性が高いと
思われます。
そこで「使用価値」を測る尺度として将来キャッシュフローが選択されたのです。
途中ですが、脚注です。
この後「延々と」プログラムと説明が続きます。
減損認識においては割引前将来キャッシュフローが使用されるが
減損処理そのものには割引後の将来キャッシュフローが使用されるとか、その
割引率を決定する際の資本コストの概念とか、、資産グルーピングにおける
共用資産の取り扱い方法とか、減損処理後の繰り延べ税金資産の計上基準等々
またプログラム的にもJDK5.0のジェネリクス機能をネスト化したデータ構造が
減損シミュレーションに適しているのではないか…。
これって「プログラム初歩、初歩の初歩」のタイトルから著しく
遊離してない？これじゃぁギャグの入れようもないわよぉ！
との批判をもろに受けてしまいました。
確かにアンチプラグマティズムを標榜し「非」実用性こそ命の
本HPの趣旨からもかなり逸脱した内容となっております。
そこでこの度はここでこのシリーズを打ち切らせて
頂きますのでご了承願います。
会計理論のややこしい話はどうでも良いけど「JDK5.0のジェネリクス機能を
ネスト化したデータ構造」ってどんなイメージなのかなぁ？
との質問が寄せられたので簡単にご説明します。
早速プログラムです。
//FlexData.javaです。
import java.util.*;
public class FlexData {
public static void main(String[] args) {
// 資産リスト(LinkedList)の初期化と建物設定
List 資産 =new LinkedList();
資産.add("建物");
// 事業部リスト(ArrayList)の初期化と資産リストの追加
List> 事業部 =new ArrayList>();
事業部.add(資産);
// 事業部リストから資産を読み出す：
// ListやStringへのキャストは不要
System.out.println(事業部.get(0).get(0));
}
}
実行結果は：
建物
これだけ、ですがこの構造の裏に隠されている可能性は大きいのです。
一見すると多次元配列のように思われるかもしれませんが
LinkedlistとArraylistのタイプセーフな多次元構造を実現して
おります。何層にもネスト可能で柔軟に構造自体を変形改造できます。
またListIteratorもジェネリクスを利用できますから
データ構造内を自由に走査可能です。
確かにLinkedlistとListIteratorの組み合わせのスピードは
Javaプログラムの動作中最遅？です。
しかし遅いってことは、今や褒め言葉なんです。
スローライフこそ２１世紀のキーワードです。
アンチプラグマティズムと「非」実用性こそＹ世代のスローガンです。
多様性と柔軟性と寛容性こそプログラミングが本来求める
ものではないでしょうか。
本講座を読んでプログラミングが少しでも面白そうだなと
感じた人には無料の開発ソフトが待っています。
まずは、Enjoy Programming!
コメント
>確かにLinkedlistとListIteratorの組み合わせのスピードは
>Javaプログラムの動作中最遅？です。
シーケンシャルアクセスはC++とほとんど変わらないみたいです。
使い手の問題みたいです。
投稿者: t (January 15, 2005 07:21 PM)
>>確かにLinkedlistとListIteratorの組み合わせのスピードは
>>Javaプログラムの動作中最遅？です。
>シーケンシャルアクセスはC++とほとんど変わらないみたいです。
>使い手の問題みたいです。
tさん、貴方実はプログラマーみたい
じゃありませんね？
Javaの動作中と申し上げております。
配列やArrayListよりも早いとでも
仰りたいのでしょうか？
投稿者: Aransk (January 28, 2005 03:43 PM)
目次へ
 |