WR blog

about Enterprise IT, Oracle Database, Jazz/Fusion Music, etc…

WR blog RSS Feed
 
 
 
 

Archive for July, 2005

先輩の2次会終了・・・ ほっとした。

大学時代の大先輩の2次会の幹事をおおせつかったので、ここ3週間はいろいろとバタバタしていた。 先週末の日曜日に、その2次会が無事終了。綱渡りのような、トラブル続きの2次会だったので、無事に終えることができてカナリほっとしている。

トラブル(の一部)

ネタがかぶった・・・

バンド連中のネタは事前に把握していたのだけど、新郎職場の素人さんのネタがなかなか決まらず把握し切れなかった。そうしたら・・・・ネタがかぶった。orz. これだから素人はイヤなのよ。 →後輩の機転で、演出を変更し、ことなきを得た。

時間押しまくり・・・

出演時間を守らないバンド大杉!お前ら、15分って言ってあったらだろ?! 幹事を泣かせるなと。 →時間的にスケーラブルにしてあったので、軽めの出し物を1つ削って対処

引き出物が違う!

会場の担当者から受け取ったダンボールの中身が、会場のロゴが入ったグラス。これが引き出物のはずはないし、そもそも、グラスをそのまま渡すなんてありえない! → 会場の不手際でダンボール間違い。置き場から正しいダンボールを発掘した・・・が、その引き出物は仕込が必要なモノだったので人海戦術で対処、対処。つめつめ。仕込が必要ならその旨言ってくれないと・・・。

ギタートラブル!

ただでさえ押しているのに、ギタートラブルでさらに押し・・・・orz. → 片づけを超マッハでやることで対応

ビデオケーブルがない!

ビデオ出力が受けられると聞いたのでアップスキャンコンバータを後輩に手配してもらい、準備万端・・・のはずが、会場には1mのビデオケーブルしかなく、PA卓から客席まで届かない!我々がビデオ出力を使用するということは、前に伝えてあった筈。狭いPA卓に我々が入れない以上、それなりの長さのビデオケーブルがあってしかるべき。 → ビデオケーブル購入で対応

PAが遅刻

論外!約束の時間からかなり遅刻しやがってきた。ムカムカ。おかげでせっかく前倒しして入場したことによるゲインが相殺されてしまった。

ワイヤレスマイク受信機の出力が受けられず

出演者にキャノンでしか受けられないと念押ししていたのにかかわらず、出演者が持ってきたワイヤレス受信機はフォーン出し・・・orz. → 変換ケーブルを買ってくるように依頼・・・したけど最終的な対処方法は不明。なんとかなったらしい。 (つーか、会場にキャノン←→フォーンの変換ケーブルが無いのが大問題なわけだが)

ありがと。

コレだけのトラブルに対処できた理由は、あらかじめ計画を立てて、役割を委譲していたため。 ビデオ担当、オープニング・エンディング担当、司会などもろもろ。

ただ、もちろん、役割を担当してくれた先輩・後輩連中の助けが無くては、うまく行かなかったことは明らか。心から感謝します。ありがと。

会計システムのアーキテクチャ論 - 設計者の発言

会計システムのアーキテクチャ論 - 設計者の発言

制度会計ベースのアーキテクチャについて

まず、現在の主流である「制度会計に管理会計が寄生しているスタイル」というのは、「管理会計上の諸問題を仕訳に組み込んでしまう」というものだ。とりあえずすべての取引を1個ずつ仕訳して決算書を作ると同時に、仕訳データを集計して管理会計上の諸問題を管理しようとする。

管理会計ベースのアーキテクチャについて

いっぽうの「管理会計に制度会計が寄生しているスタイル」では、仕訳テーブルは単純な形をとる。このスタイルにおいて仕訳は、公告用の決算書を出力するためだけのネタなので、必要最小限度の項目さえ載っていればいいからだ。日々の活動はそれぞれの業務データ管理サブシステムによって管理されている。個々の取引毎に仕訳する必要はなく、月次でも、場合によっては四半期毎のサマリーデータからでも仕訳すればいいので、仕訳データ量もずっと少ない。期中の進捗については、仕訳データ経由ではなくそれぞれのサブシステムが保持する数字を直接集計して監視すればよい。システムは基本的に「管理会計システム」で、決算書出力機能が「オマケ」としてついているようなイメージだ。

簿記の枠組み、すなわち、汎用の枠組みに大して、業界・業種・企業に特化したデータ を盛り込むようなアプローチには限界がある。 そして、業界・業種・企業に特化したデータをベースに汎用のデータを生成するアプローチのほうが良いと理解した。

六の日記はここにはないぞ - 仕訳をいつ作るかなあと云う話

確かに仕訳中心で全てを従属させると大統一理論てな塩梅でとても愉快なんだけど、やっぱり計上→訂正→消込とかのフローに沿った部分は債務は債務、債権は債権で別管理にしておいて、仕訳は仕訳でその時々のスナップショットみたいな考えでパカパカ生成するのみにして、「どれに対する消込かって?債権側に聞けや」みたく人任せにする形が、良かったなァ、って設計した人と後から反省した。

の話にも通じるのかなっと。

Linuxは安くない。

Linux/これでいいのかLinux(仮) - 404 Not Found (FreeStyleWiki)

ふーん。納得できるかも。

Profile

渡部亮太 / Watabe Ryota
代官山在住のOracle Database Engineer。 株式会社コーソル所属。講演/講師業もぼちぼち。書籍「プロとしてのOracle運用管理入門」「プロとしてのOracleアーキテクチャ入門」買ってくれるとうれしいなっと。 twitter:wrcsus4

Book



Other Works

Certifications

  • Oracle Master 10g Platinum
  • Oracle Master 11g Gold
  • Oracle Master Silver Oracle PL/SQL Developer
  • Oracle Master Expert 10g RAC
  • Oracle Master Expert Oracle on Linux
  • LPIC level2
  • CCNA
  • 日商簿記3級

Contact

wrcsus4 _at_ gmail _dot_ com

Archives

Recent Posts

Recent Comments

Categories

Tags

Meta