最大は八人称だそうで

この前のエントリで休筆するとか言っておきながら、
今週も更新しちゃう自分が若干大好きですｗ
いや、鉄は熱いうちに打てというし、
最大のインプットはアウトプットとも言いますから。
ということで、今日は書評を書いてみます。

＜ビジネスは三人称で考える＞


在野のコンサルタントとして名を轟かせている
石原明氏の新著ですが、思うところがあって
虎の子のノウハウを公開したという背景もあり、
非常に実践的かつ汎用的な内容となっています。
業種や職種、年代を問わず、ビジネスマンであれば
是非とも一読すべきではないかと思います。

コンサル業界では、問題を解決するために
「視点を高くする」という言葉が頻繁に使われますが、
それがどういうことか、「人称」という
キーワードで分かり易くまとめられています。

自分だけの利害にフォーカスするのであれば「一人称」、
相手の利害にフォーカスするのであれば「二人称」、
自分と相手を見る第三者も考慮するのであれば「三人称」
といった具合で、思考の範囲と影響の広さが人称の
大きさを規定するという考え方なのですが、
人称が大きいほど長期的で抜本的な問題解決を
志向することに繋がるので、成果も上がるわけです。

ビジネスに対する労働の価値が陳腐化していく時代において、
三人称以上に至れない人は、淘汰の対象となっても
文句は言えないかもしれません。ではどうすべきか？
そのための具体的な方法や考え方もしっかりと
述べられていることが、この本の素晴らしい点です。

感情や主観に流されて一人称に戻されることなく、
大きな人称を自分のものにして種々の前提条件を疑い、
高い位置にある本当の成果を掴み取る。
そんなトレーニングをしてみてはいかがでしょうか。

ちなみに、私が一番ココロをくすぐられたのは、
交渉では相手よりも人称が大きい方が勝つという一文で、
ハーバード流交渉術にも繋がるものがあると思いました。
相手よりも人称が大きいというのがミソで、
相手の人称を下げるテクニックも効果的なんですね。

（参考）
http://d.hatena.ne.jp/kensakumaigo/20110129/p1
http://www.mmatsuura.com/negotiation/lect/lecture5.html

ブログ暫く休業します

週に一度の人生の振り返りが自分にとっても
有意義だなと感じてはいるのですが、
振り返りよりも前に進むことを優先すべき
タイミングもあるよなと考えています。

ITじゃないコンサルへの転職、
某技術書の英訳のお手伝い、
手を抜けないMBAの単位の履修、
山のように積まれた占術理論の読破、
嫁との冷戦の終結と、かなりクリティカルな
イベントが今年の後半戦には控えていまして、
その実行のために時間を作る必要が出てきました。

で、何を省くかと考えたときに、
苦渋の決断ですがブログの執筆を
省こうと考えるに至ったわけです。

とはいえ、備忘的なつぶやきなどは
Facebookに放り投げたりしていますし、
何か声を大にして伝えたいことがあったときは
気まぐれにブログを書いちゃうことも
あるかもしれません。縛りを無くすだけです。
…さあ、次の舞台に向かって飛躍するぞ！

こんなESB設計は嫌だ

「達人が語る こんなデータベース設計は嫌だ！」に
参加したので、感想をまとめようと思ったのですが、
出遅れて書くことが無くなってしまったので、
「変人が語る こんなEssbase設計は嫌だ！」という
誰得なエントリでお茶を濁してみることにします。

＜Essbaseサーバとサイジング＞
「そもそもサイジングできない奴、一歩前に出ろ」
-----------------------------------------------------------
せめて次元数とメンバ数でサイジングをしてから
プロジェクトの規模やハードウエアの見積って欲しいですね。
開発着手の前に既にPJTが崩壊してるとか泣きたくなる（死
　→参考01

＜Essbaseの性能はスケールするか＞
「EssbaseはRDBに比べスケールアウトが困難」
-----------------------------------------------------------
Essbaseはシェアード・エブリシング型のアーキテクチャで、
最近になってHA構成が辛うじて可能になった程度です。
しかも制限が多い。シングルインスタンス構成で
ディスクをパーティショニングくらいが限界かも（汗
ここらへんが改善されると、個人的には夢が広がります。
　→参考02
　→参考03
　→参考04

＜ストレージネックを解消しましょう＞
「とは言ってもEssbase側で可能なことは少ない」
-----------------------------------------------------------
先述のパーティショニングや、ディスクボリュームの
割り当てを分散させるくらいしかできないので、
頼むからRAIDで早いストレージを入れてください（泣
　→参考05

＜オンメモリの時代＞
「やっぱりディスクに触ったら負けかなと思ってる」
-----------------------------------------------------------
計算キャッシュ、インデックスキャッシュ、
データファイルキャッシュ、データキャッシュ
（直接入出力がONのときのみ有効）と
ディスクに触らせない諸々の設定があるのに、
メモリをケチって失敗するとか問題外。
　→参考06

＜32bit OSはオワコン＞
「64bit OSでもオワコンなケースに注意」
-----------------------------------------------------------
MEMSCALINGFACTORという、4GB以上のメモリを
キャッシュに設定できるオプションがあったのですが、
とあるバージョンでは設定が効かないというバグがあり、
64bit OSでもメモリを4GBまでしか使えないという
悲しい事態が発生したことがあります（吐血
最新のEssbase 11.1.2.2ではオプション自体が廃止されて、
最初からメモリを潤沢に使えるようになった模様。
　→参考07
　→参考08

＜手続き型の呪い＞
「手続き型でロジックが書けたら苦労しない」
-----------------------------------------------------------
EssbaseのDSLは手続き型のロジックを（基本的に）
記述できません。なので、ピヨピヨじゃないエンジニアも
開発現場で頻繁に爆死します。しかも、次元の疎密
（≒インデックスとエクステント）の違いと計算方法の
相性を理解したうえでロジックを記述できないと
パフォーマンスが劇的に劣化するので、
開発をクリアできてもシステムテストで爆死します。
というか、基本的に皆揃って爆死します。
ここでのアドバイスとしては、メンバ式的にロジックを
実装すると逃げ道があるとだけ言っておきます。
　→参考09

＜Essbaseはガツンと一発で操作＞
「常に必要なブロックを一度に操作する意識を持つ」
-----------------------------------------------------------
計算スクリプトはロジックを逐次で記述する形式に
なっていますが、逐次実行の数が増えるとパフォーマンスは
当然悪化します。データの並列処理に強いという特性を
活かせなければ、Essbaseを導入する意味など無いに等しい
ということを、某社の営業も知って欲しいと思います。

＜Essbaseはテーブルじゃねえんだよ＞
「人は何故データベースといえばRDBと考えるのか」
-----------------------------------------------------------
EssbaseはRDBと違い、データが丸ごと一つのファイルに
格納されていて、@XWRITE関数と@XREF関数が使える
場合を除いて、データ連携はエクスポートとインポートで
行わなくちゃいけない作りになっています。
なので、無駄な部分にアクセスさせずにロジックを
記述しないと、膨大なアクセス待ちが発生して死にます。
言い方を変えると、FIXステートメント超重要。
更新フラグの付いた部分だけを計算対象にする
高機能計算は、計算バグの元凶となるのでOFFを推奨。
　→参考10
　→参考11
　→参考12
　→参考13
　→参考14

＜Essbase技術者からの反論＞
「でもさ、Essbaseには利点もあるんじゃないの？」
-----------------------------------------------------------
この意見には一理ある。オプティマイザが存在しない
Essbaseでは計算処理のパフォーマンスに揺れが無い。
ただ、パフォーマンスを考えられる技術者は極めて少ない。
（僕を月300万以上で雇って貰えるならOKだけど。）
というか、Essbaseは更新系の処理をさせるのに
向いたアーキテクチャじゃないような…。
（OLAP用のDBなんで、OLAP用に使っていただきたく。）

＜垂直分割と水平分割＞
「理論と実践のトレードオフ」
-----------------------------------------------------------
現場レベルにおいて、垂直分割と水平分割を
提案できるエンジニアは一人もいない。
（ソース：@Bizuayeuの経験）

＜物理の犠牲になる論理＞
「物理と論理が喧嘩すると、物理が勝つ」
-----------------------------------------------------------
しかし、物理側が問題を解決できるわけでもないので、
最終的にプロジェクトそのものが犠牲になる。

＜アウトラインはいつ崩すべきか＞
「アウトラインの変更は手戻りのコストが大きい」
-----------------------------------------------------------
性能が出る出ない以前にアウトライン（≒マスタ）を
変更しないとデータそのものが入らないというのが
Essbaseのデータモデルなので、仕方ないね。
だからプロトタイプのフェーズが必須と小一時間（略

＜Essbaseの理想と現実＞
「Essbaseエンジニアはどこまで物理を意識するべきか？」
-----------------------------------------------------------
ぶっちゃけ物理を意識できないエンジニアは
Essbaseでは役に立たんのですよ。
それがEssbaseの最大の弱点だと真面目に思う。
残念ながら物理に至れるエンジニアが少ない現状、
ベンダーの甘言に乗ってEssbaseを導入するのは
相当なリスクじゃないかな。20年以上前から
OLAP用途には愛されている＝アーキテクチャ自身は
優れているという証拠で、キチンと使えたときの
パフォーマンスは素晴らしいし、知れば知るほど
洗練された作りになっていると僕も感じるので、
非常に寂しいのだけどね。

通し番号付でリネーム

外食写真に対して以下のページで紹介されている
リネーム方法を試してみたけど、確かに便利ね。
http://f.daccot.com/2010/07/28/3683/