« 2005年8月 | トップページ | 2005年10月 »

2005年9月

2005/09/30

BW Expert Onlineを一緒に購読しませんか

SAP BWの仕事をしていてもっとスキルアップをしたいという方へ

BW Expert Online ( http://www.bwexpertonline.com/ )というサイトご存知でしょうか?Full text versionを読むためには購読料を払う必要があるのですが、おおよそ一人あたり1万円ちょっとの投資で1年間読むことができます。詳細は [Subscribe]のElectronic Team License を参照。

できれば、10人の有志を募って共同購読をしたいのです。ご興味ある方いらっしゃれば、info@knowledge-yield.com までメールをいただけますでしょうか。不明点などございましたらメールか当BLOG記事にコメントを着ける形で問い合わせいただければと思います。

(最初から10人きっちりそろう必要はないのですが、10に近い人数の賛同者はほしいなぁ)

| | コメント (1) | トラックバック (0)

2005/09/29

金融機関口座の統合(アグリゲーションサービス)

遅ればせながら(案外そうでもない?)アグリゲーションサービスを利用し始めました。たまたま東京三菱が「アンケートに答えれば謝礼を出す」ということを書いていてせっかくだから試してみようかと思い申請。アグリゲーションサービスとは、複数の口座(主に銀行・証券・クレジット会社)をひとつの画面で統合することで、その人の資金管理を便利にする仕組み。

MTFG NET PLAZA 口座一覧管理サービス
https://www.btm.co.jp/mnp/

口座一覧管理サービス 体験ツアー
https://www.btm.co.jp/mnp/taiken/index.html

さて今回試したところ、東京三菱の口座だけでなく、UFJ銀行、みずほ銀行、マネックス証券、E-Trade証券などを一つに統合することができました。最初のログイン画面は東京三菱のパスワードなのですがその認証ひとつで他の金融機関の口座残高や明細が見れることはかなり便利です。あくまで残高や明細の参照だけでして隣りに見えている他行口座への振込みなどはできません。(これが出来るとかなり便利なのですがね)ま、それは仕方ないことでしょう、それぞれは本当は独立したシステムですから。

東京三菱からすると、複数口座を1画面で統合することは顧客満足につながるとはいえ、ただ単にそれだけが目的でないはずです。狙いは「トータル資産が全体でどうなっていて比率的にもう少し投資信託などにしたほうがいいですよ」とか考えてもらうよう仕向けたいということでしょう。(本音をいうと他行の口座残高がどうなっているとか把握したいでしょうけれども、さすがにそれは許されないかと。)

| | コメント (0) | トラックバック (0)

2005/09/28

ロール設定と移送

いま入っているプロジェクトで自分が担当するBWパートが来月中旬サービスイン(本番稼働)します。いま移送作業やセットアップ作業で忙しいのですが、この時期一番の心配ごとはロール設定と移送がうまくいくかどうか。

■ロール
BW屋さんでもロール・権限を苦手にする人多いですよね。(ロールと権限はコンセプトと実際の設定の乖離が大きい領域だと思います。そして実際に触ったことある人しか、実践で使えないのも事実。)私ですか?複数のプロジェクトを経験して、そして苦労してずいぶん理解度UPしました。今回自分が担当したBWパートでのひとつの特徴(目玉の一つ)は次のようなものです。

ODSにログインIDと伝票項番の組み合わせを複数入れておく。クエリ実行時にログインIDから閲覧可能な伝票項番をExitで取得する。このカスタマ変数をロールにはめ込むことでレポート権限値を動的に変化させる。
⇒メリットはごく少ないロールで複雑な値制御をODSとExitを用いて実現ということ。
⇒世間一般のBWプロジェクトでどれだけこのテクを使っているのか知りませんが、結構スマートで好きです。


■移送
(やったことあるかたは分かるかと思いますが)SAP製品の仕組みが分かっていないと結構ドツボにはまります。「外科の移植手術」にたとえると分かりやすいでしょう。開発機から検証機、それでうまくいったら更に本番機へと複数環境をまたがってSAPオブジェクトを移す作業はさながら、臓器移植のようなものです。どれを持っていくのか、移植したあと正しくActivateできるか(神経・血管の接合みたいなものです)、また移植先環境で正しく動作するのかなど、チェック・チェックの連続です。

さてこの作業、どうもPMO(Project Management Office)とかSAPをよく知らない方はどうも軽視するきらいがあります。無知というのは怖いものです。もしかしたらWindowsのEXEファイルを右から左にコピーするぐらいに思っているのではとかんぐるときもあるぐらいです。(*1) 実際この作業の成否いかんでプロジェクトで作り上げてきたモノが生きるか死ぬか別れるわけです。臓器移植でいうと、提供元と提供先の両名の運命が執刀医の腕にかかっているのです。
十分でかつ安全な時間をとって順序ただしく行うことが重要です。ここで時間を短縮しようと過密スケジュールにしてしまうと事故のものになりがちです。どうもそういうのが分かっていないPMOとかが多いような。(医療の世界でも同じような構図なんだろうな。病院の理事長と執刀医のようなものか?)

さてボヤキが入りつつの本稿ですが、私の今週のタスクは検証機環境へのクエリ・ロール・変数・Webテンプレートの移送と本番機への全リソースの移送です。かなりタフな「オペ」になりそうです。これが落ち着いたら移送作業後のBW環境の使い方のイントロ(BExオブジェクト修正の決め事など)しないといけないかなと。

(*1)
自分がSAPの仕事をやる前に「移送」という言葉にイメージしたのは、「C言語ソースをmakeファイルでコンパイルする」というものでした。SAPプロジェクトでやる作業とはずいぶん違いますね。



■いろいろ

さてそんなこんなで移送作業をやっているわけですが、ひとつ疑問が。。
「レポート権限の移送」がうまくいかないのです。もう少しがんばって調べてみます。



■メモ NOTE

184586 システム変更オプションと BW
337950 クエリ (およびその他のオブジェクト) を編集できない
315181 空白のロールが表示されない

316470 ロールを変更するための権限がない
⇒'S_USER_AGR' または'S_USER_TCD'
373979 ロール保存用の権限
⇒'S_USER_TCD' または'S_BDS_D' 'S_BDS_DS'

315094 BW レポーティングで推奨される権限設定

580366 BW でのロールの移送
607708 オープン保存ダイアログボックスでのオブジェクト削除

579412 Sorting roles in the Web item role menu

790323 BW のレポート権限に対するログ
⇒RSSMログの見方を解説。(見つけてよかったこのNOTE)

611502 変更できないシステムでの RSSM の変更可能性



785308 NW での Microsoft セキュリティのパッチの副次的影響
⇒ Microsoft セキュリティ Hotfix 834707 の場合「フレーム依存のスクリプトベースのクライ
アント通信が一部のケースで拒否」という事象が起こりえるとのこと。自分のPCはこれ当たっているけど・・今回はフレーム使っていないから何も出ていないだけかも。


446015 Web アイテムロールメニュー
⇒「特に、以下の現象について記載します」とある。
32 を超えるフォルダの開閉。
iFrame を使用しないとロールメニューが表示されない (JavaScriptエラー "'SAPBWmenu_iframe'")。
エンタープライズポータルでロールメニューが表示されない(JavaScript エラー "Access denied'")。
エントリの順序が、ロール更新での順序と一致しない。
ロールの複数選択 (必要に応じて、ロールを表示する必要はありません)。
ターゲットフレーム "Whole page" ("_top") での Web ブラウザの"前画面" (JavaScript エラー "'parent.gMenu' is null or not at object")。
Web アイテムロールメニューでのロールのソート。
IE 4.0、5.0 および Netscape 4.7 で、ロールメニューが表示されない。
修正内容を適用したあとに CL_RSR_WWW_ITEM_MENU で構文エラーが発生する。
Netscape 4.7 でのユーザおよびロゴの表示。
Netscape 7.0 でアイコンおよびスタイルシートが表示されない。
Web テンプレートでの 2 つ以上の Web アイテムロールメニュー。

以下のヒントについても記載します。

背景色の変更。
トランザクション RSRT2 でのロールメニューを含む Web テンプレートの照会。



helpより

マニュアル登録されたプロファイルの移送
選択したプロファイルを移送するには、以下の処理を行います。
1. ツール → システム管理 → ユーザ管理 → 権限とプロファイル ( マニュアル更新) → プロファイルのマニュアル編集 と選択します。プロファイル一覧を登録してから、プロファイル → 移送 を選択します。
2. 表示された一覧から移送したいプロファイルを選択します。すべてのプロファイルを選択することもできます。
3. ダイアログボックスで、各プロファイルまたはプロファイルグループの移送依頼番号を入力します。
4. プロファイルのみを移送するか、またはプロファイルに含まれる権限も移送するかを選択します。プロファイルのみを移送することも、またはその全コンポーネントを移送依頼に含むこともできます。また、プロファイルおよび権限に関する文書も移送されます。
5. 選択が終了すると、ワークベンチオーガナイザを使用して移送依頼を実行することができます。

マニュアル登録された権限の移送
権限を移送する手順は同じです。最初に権限管理機能を開始します。ユーザ管理 → 権限 と選択してこの機能を開始します。オブジェクトクラスを選択してから、権限 → 移送 と選択します。


| | コメント (1) | トラックバック (0)

寄生獣ネタ

SAP BWなど堅いネタから逸脱して。。。(脱線しすぎか?)

昔読んだ漫画「寄生獣」がハリウッドで映画化されるとのこと。原作を読んだことない人にはわからないかもしれないけど、映像&脚本がどうなるのか非常に気になる。というか怖いものみたさか。

「寄生獣」ハリウッドで映画化:)
http://blog.nobon.boo.jp/?eid=144190

岩明均『寄生獣』ハリウッド映画化
http://ish.chu.jp/blog/archives/2005/07/post_67.html
寄生獣がハリウッドで映画化
http://coolsummer.typepad.com/kotori/2005/07/post_18.html

「寄生獣」って何という人は、このサイトであらすじを!
また第1巻のお試し版も見れる様子。
http://www.ebookjapan.jp/shop/title.asp?titleid=3959


あとこんなのもあった。うーん、自分はこの説を信じるほうだな。
(元ネタにかなりきつい冗談が入っているので適当に読み流していただければと)

岡■克也は寄生獣説
http://oretekinews.blog21.fc2.com/blog-entry-20.html



海外のアニメファン(オタク)にも結構評価されているような雰囲気。(あーいうネタ好きそうだもんな)
http://www.discountanimedvd.com/book_list2.asp?categoryno=687&OVRAW=parasyte&OVKEY=parasyte&OVMTC=standard

| | コメント (1) | トラックバック (0)

2005/09/25

地雷プロジェクト

自分が巡回するBLOGに最近なんともいえぬ空気が漂っている。ま、BLOGなんていうのはガス抜きの場のような要素もあるのでそんなものかもしれないが。。。

でも、面白いので引用させていただく。

地雷プロジェクト
http://www2.gol.com/users/gowild/essay/86%20mine%20projects.htm

とほほはすすむよどこまでも
http://d.hatena.ne.jp/ftmoon/20050924
[雑感][SAP]契約 なんというか・・・
http://d.hatena.ne.jp/ftmoon/20050822/1124715278

自分の変化
http://modify.dip.jp/mt/archives/2005/09/post_284.html#comments
ちょびっとですが私めのコメントも付けてます。



傭兵であるための心がまえとして「PJに感情移入しすぎないよう」にしてます。与えられたミッションによると思いますが、基本的には正規軍隊である人たち(いわゆるサラリーマン)とは違うんだと言い聞かせること。「あくまで正規軍隊にはなれないんだ」ということ。普通のサラリーマンだといろいろルール(有給の数、出退勤管理など)で縛られたり利益が搾取されたりという構図から開放されることの代償でしょうね。。

イメージ的には漫画エリア88の傭兵の気分です。戦場で死なないよう仕事を選ぶところも好きな描写です。ま、漫画の中でたくさんの人がお亡くなりになるわけですけど、飛行機ならぬいままで武器にしてきたITとともに死ぬならやむなし、かなと。

自分もときどきは正規軍隊に戻って大きなオペレーションをやりたいと思うところもありますが、独立開業したときの初心に立ち返って考えるようにしてます。(少なくとも3年以上は初志貫徹したいとは思ってますが..)shino-sanにとってはそういう逡巡の後いまそういう境地にいたっているのかもしれませんよね。

結局立ち位置の話なので、個人個人の考えが色濃く出るでしょうけれども、とある一人の思うところというところでコメントさせていただきました。



| | コメント (0) | トラックバック (0)

2005/09/23

SAP NetWeaver 2004 Slim Edition Sneak Preview をインストール

SAP社から取り寄せていた「SAP NetWeaver 2004 Slim Edition Sneak Preview」を自分のPCに入れている最中。まず最初にSun J2SEのインストールをしたあとPATHを通す。その後ようやくSAP NetWeaverインストールとなる。(NetWeaverのインストール画面においてPhase24のうちいま22まできた)

★注意点を記載

(1)NetWeaverインストールのexe を起動するときはDOS窓からやること。
(HTMLベースのインストラクションを見ながらやっていて、リンクをクリックすれば実行されるかと思いきや途中でNODEがないとかのエラーが出ました。
(もしかしたら自分のPCだけの事象かもしれませんが)

NewweaverSneakPreview1



Phase22 の SAP Netweaver Developer Studio 2.0.11 は、ファイルコピーがかなりあるので、それなりに時間かかりそうです。

NewweaverSneakPreview2



やっと完了(もう朝だ。。)
NewweaverSneakPreview3


| | コメント (0) | トラックバック (1)

2005/09/15

Google PageRank = 10 のサイト

いきなり面白い表を。2005年8月時点のGoogle PageRankが10のサイトである。
GooglePageRank10

元ネタはこちら。他にも似たような統計を出しているサイトはある。
http://www.suchmaschinen-optimierung-seo.info/pagerank.html

Googleで検索結果上位に表示されるためにはPageRankを高めないといけない。2005年9月15日現在このBLOGサイトはPageRank=3である。欲をいうとPageRank=5はほしい。

SAP BWなど経営分析システム導入のナレッジイールド
http://depeche.cocolog-nifty.com/

ではどうやれば高めることができるのかというとPageRankの高いサイトから参照されるなどいわゆるSEO(SearchEngineOptiomization)を意識する必要がある。SEOを手がける業者はたくさんいて玄人にお願いしたい誘惑に駆られるが、とりあえず今のところ自分でいろいろ試行錯誤をしてみようと思っている。

PageRankのアルゴリズムを具体的に書いてくれているサイトもあるが、素人の自分にはどうにも難解だし、読んで理解できたからといってSEOを飛躍的に高める何かを持ち合わせているわけではない(おそらくその境地に達してきたらSEO業者と同等なんだろう)。個人レベルではせいぜいHTMLレベルで最適化(ものによってはスパムと呼ばれるものもある)するぐらいしかできないだろう、というのが私見。

Google の秘密 - PageRank 徹底解説
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/pagerank.html

さて最初の表に戻ると、日本のサイトでは慶応大学がPageRank10で堂々の21位であるYahooJapanのトップページでさえPageRank=8であることを考えると立派なものである。もっとも慶応大学といえば村井教授がすぐ出てくるぐらいインターネット分野での草分けなのでPageRank=10において不思議ではないのだが、その他の有名大学と比較してみるとかなり面白い。一種インターネット世界での地価のようなものである。

東京大学 PageRank=9
http://www.u-tokyo.ac.jp/ 

京都大学 PageRank=7
http://www.kyoto-u.ac.jp/

慶応大学 PageRank=10
http://www.keio.ac.jp/

早稲田大学 PageRank=8
http://www.waseda.jp/

一橋大学 PageRank=7
http://www.hit-u.ac.jp/

ふと思うこと。慶応大学の卒業生でなんらかの方法で自分のサイトに誘導できれば、PageRankがUPするかも。真実はいかに?

| | コメント (1) | トラックバック (0)

SAP BW TIPS (ロール・クエリ編)

SAP OSS

672772 オープンダイアログボックスのロールのクエリの削除
---------------------------------------------------
オープン/保存ダイアログボックスで BW クエリを削除する場合、"Delete
object (オブジェクトの削除)" および "Delete reference (参照の削除)"
の 2 つのオプションが提供される。
"Delete reference" はお気に入りまたはロール内のエントリのみを削除す
る。BW クエリオブジェクトが保持される。06 活動 (削除) の権限オブジェ
クト S_USER_AGR が正しく考慮されない。詳細については、ノート 651240
を参照してください。
"Delete object" は BW クエリオブジェクトおよびこの BW クエリへのすべ
ての参照 (お気に入りおよびロールのエントリ) を削除する。必要な権限の
ないお気に入りおよびロールの参照の削除は、不整合を回避するための意図
的な機能である。

BW クエリはオブジェクトとして削除されるが、ロール内のこの BW クエリ
への参照は引き続き保持される。

-----------------------------------------------

607708 オープン保存ダイアログボックスでのオブジェクト削除

----------------------------------------------
651240 オープンダイアログボックスのロールでのワークブックの削除
------------------------------------------------
315181 空白のロールが表示されない
--------------------------------------------
588144 Entering BW queries in roles

----------------------------
580366 BW でのロールの移送
-----------------------------------
853058 結果/個別値の計算: 優先度のルール

315094 BW レポーティングで推奨される権限設定


■Load Runner
http://www.unisys.co.jp/solutions/sap/pdf/white1.pdf

| | コメント (0) | トラックバック (0)

SAP BW TIPS (Web編)

SAP NOTE:

815611 Web レポートの "戻る" 機能および変数入力画面
764394 Web アプリケーションのパフォーマンス改善ガイド
643464 標準 Web テンプレートの変数画面の有効化
639595 CSV へのエクスポートで行データが 1 セルに書込まれる
648988 不適切な標準 Web テンプレート

621630 Incorporating a company logo in the standard Web template

| | コメント (0) | トラックバック (0)

2005/09/11

難解な言葉の連発・

波田陽区じゃないけど、たまには斬り捨てたいときがある。

■難解な言葉の連発

Web Conference 2005 for IT テクノロジー
http://nikkei.hi-ho.ne.jp/webconference2005/index.html

難解な単語を使いすぎ。文章のかなりの割合が漢字とカタカナだ。漢字がたくさんあると論理的であるかのように見える。カタカナは英単語の代替という感じ。IT業界において悪しき風習の3文字英字も頻発する。さて文章の中身はというと問題提起から結論にいたるロジックや根拠となる数値が希薄である。(注:すべての記事がそうであるというわけではない。)

たとえば「新しい技術でこんなことができるようになります」という論調があるが、「これまでなぜそれが出来なくて今回それができるようになった理由はなぜか」が一番気がかりでありロジック上重要なところである。簡単にいうと長所と短所がどうシフトしたのか?なぜシフトしたのか?いつシフトするのか?ということである。そういう議論が示されない状態でキーワードが先行すると、漠然としたことしか伝わらないことになる。(誰を読み手に想定していたのだろうか?)

限られた紙面の中だとはいえ、論理の飛躍になるような大きな風呂敷を広げるくらいなら、もう少しフォーカスしたネタにするべきかと。自分のBLOG記事も暴走することがあるので、自戒の念をこめてコメントしてみた。

ちなみに私が書いている記事のほとんどは、SAPやBWをキーワードに訪問する方々をターゲットにしている。それゆえ、非ターゲットのかたがたにとっては単語は難解かもしれない。しかし論理を展開するロジックについては破綻しないように文脈の前後に注意して書いているつもり。いちおう、この場で釈明しときましょ。


■単純明快だけど、実務的には困る「とりあえず」

最近、嫌いだなと強く思った言葉がある。それは「とりあえず」。実務をやる上では、即決できないことは多い。そのため意思決定を先送りすることが望ましいこともある。また担当者同士のコンフリクトを避けるうえでも便利な言葉である。でも。。。

「とりあえず、こうしときましょう」
「とりあえず、それは置いておきましょう」

「とりあえず」の根拠はなんなのだろうか?
また「とりあえず」先延ばしにされた懸案とかは、いつ解決されるのだろうか?

ロジカルじゃない話には頻発するキーワードの一つだ。



上であげた2つを結びつけてどうこういうつもりはないが、2つから感じる違和感。これはなんだろう。問題提起にとどめてこの記事をクローズする。

| | コメント (1) | トラックバック (0)

2005/09/08

BW データロード チューニング

いま入っているPJはスコープがあまりに巨大でありシステム的には段階的立ち上げになってます。自分が担当しているBWパートは10月中旬にサービスインする予定です。残り1ヶ月というところですが、まさにチューニングの真っ最中です。
要件定義を経て設計を行った結果、レポート要件の特殊性もありかなり凝ったキューブモデリングをいたしました。そのせいか大量データをまず最初に流し込んだときはロードパフォーマンスが稼げませんでした。(ロードするデータ量は爆発的に多いというわけではないのですがね。。。)そこで、いろいろ試行錯誤を開始。



全部披露するわけにはいかないのですが、今回注力してみようと思うのがこれ

番号範囲バッファリング

いろいろ触ってます。面白い結果が出ればおいおい報告してみようかと。
とりあえずいまは下準備として調査したSAP NOTEを整理して掲載いたします。



192658:BWシステムの基本パラメータ設定
567747 総括ノート BW 3.x パフォーマンス: 抽出 & ロード
567745 総括ノート: BW 3.x パフォーマンス: DB 固有の設定

130253 BW へのトランザクションデータアップロード時の注意
→まずは定番のこれ!


Oracleならばこれら
180605 BW システムの Oracle データベースパラメータ設定



857998 Number range buffering for DIM IDs and SIDs
How do you find number range objects of the dimensions and SIDs for which the number range should be buffered?

a) You know in advance that the dimension or SID table will increase significantly per request.
b) There are accesses to the NRIV table and you can determine the number range object directly in the current SQL statement.
c) A high number range level may indicate for these two BW objects that there is a significant increase (only valid for BID* and BIM* objects)
SE16 'NRIV'
-> OBJECT = 'BID*' or OBJECT = 'BIM*'

displays all number range objects with number level (NRLEVEL).

Export this output to an Excel document and sort NRLEVEL in descending order. From experience, most candidates have a high number range level.

You can determine the corresponding dimension tables using the RSDDIMELOC table. You can find the InfoObject for SIDs using the RSDCHABASLOC table (the NUMBRANR field contains the last seven digits of the number range object). The procedure is even more effective if you read the NRIV table periodically and you determine the changes using NRLEVEL.



602202 InfoCube の次元に番号範囲オブジェクトを登録する方法
→ RSRV関係


708297 BRAIN071 with buffered number range object
Solution
The cause of the problem in the number range buffer must be eliminated. The problem frequently occurs because all of the DIALOG work processes are in use. In this case, the parallelism of the update must be restricted.



828725 Parallel processing for flat file upload


493980 マスタデータ属性およびマスタデータテキストの再編成

| | コメント (1) | トラックバック (0)

2005/09/02

ITサービスに「鬼十則」を

ちょっと愚痴をいいたい気分だが、のんべんだらりと書いても読み手に何の役にも立たないので含蓄の深い言葉をまじえながら愚痴をいきましょう。(いいたいことは、IT関係の人たち、もっとサービス精神を身につけましょうよ ということ)

割と有名な言葉だが、電通「鬼十則」というのがある。



1. 仕事は自ら創るべきで、与えられるべきでない。
2. 仕事とは、先手先手と働き掛けて行くことで、受け身でやるものではない。
3. 大きな仕事と取り組め、小さな仕事はおのれを小さくする。
4. 難しい仕事を狙え、そしてこれを成し遂げるところに進歩がある。
5. 取り組んだら放すな、殺されても放すな、目的完遂までは……。
6. 周囲を引きずり回せ、引きずるのと引きずられるのとでは、長い間に天地のひらきができる。
7. 計画を持て、長期の計画を持っていれば、忍耐と工夫と、そして正しい努力と希望が生まれる。
8. 自信を持て、自信がないから君の仕事には、迫力も粘りも、そして厚味すらがない。
9. 頭は常に全回転、八方に気を配って、一分の隙もあってはならぬ、サービスとはそのようなものだ。
10. 摩擦を怖れるな、摩擦は進歩の母、積極の肥料だ、でないと君は卑屈になる。


本質を突いているのでビジネスにたずさわる人は「まさにそうだそうだ」と言うと思うが、「これぐらいの真剣さで仕事に取り組んでいるのか?」といいたくなる人が多いのがIT業界。あえて最初に弁護しておくと、「鬼十則」は電通という広告ビジネスのドンのような会社から生まれた言葉であり、おそらく営業マンに向けての叱咤激励の言葉であり、これをそのままテクノロジーをサービスに変換させるビジネスの情報サービス業に適用させるのは無理があるかもしれない。ただテクノロジーと広告の違いを情状酌量として考えても、「IT業界の人、現在の状況をもっともっと真摯に受け止めて対応を考えない」と産業として発展しないぞと言いたい。(もちろん、自分にも言い聞かせながらだが、業界全体がそうならないといけないだろうからあえて苦言をいっている)

1. 仕事は自ら創るべきで、与えられるべきでない。
2. 仕事とは、先手先手と働き掛けて行くことで、受け身でやるものではない。

IT業界というよりもむしろ情報サービス業界というほうが正しいが、会社の中の職制としては「営業」「営業支援」「技術支援」「設計・開発」というような感じになっているのではなかろうか。そして言葉どおり「営業」だけやっている人の比率というのは案外少ない。ではそれ以外の人はというと確かにクライアントとの打合せに出たり営業支援をしたりと『仕事を自ら創る』という側面に触れてはいるが、全身全霊かたむけて注力しているかというと案外そうでもない。技術革新と背中あわせで技術キャッチアップだけでも精一杯という事情もあるが、仕事は増えてもそれほど喜ばないという風潮がある。(給料が増えない場合はなおさら)
簡単にいうと、真のサービス指向型になっていない。コンサルティングを標榜する会社が増えてはいるが、名前負けしている会社が多いのも事実。でも、これからの情報サービス業界、競争が激化し本当の意味での質の勝負になるので実体の伴ったサービス指向の会社しか生き残れないはず。淘汰されるはず。
組織全体の話をしてきたが、それを構成する個人個人がそういうマインドであることがなにより重要

3. 大きな仕事と取り組め、小さな仕事はおのれを小さくする。
4. 難しい仕事を狙え、そしてこれを成し遂げるところに進歩がある。
7. 計画を持て、長期の計画を持っていれば、忍耐と工夫と、そして正しい努力と希望が生まれる。

3.と4. はイケイケドンドンの電通カルチャーらしい言葉であるが、その裏で「緻密さ」と「全体を俯瞰する眼力」も要求される。なにより警鐘をあげるべきは、緻密さをあわせもたない挑戦。それはただただ無謀である。ITプロジェクトでいうと、緻密なスケジュールプラン・リソースプランがない状態での提案・受注は無謀だ。(もちろん不確定因子はあろうから幾分かのバクチ的要素を伴うことは重々承知)言葉でいうと平易だが「緻密さ」を身につけるのは大変である。
ここでいいたいのは、日々「緻密さ」を磨きつつ、いざ営業という局面にたったとき大胆な一手を打てることが重要ということ。情報サービス業はトークをする「営業」と最終的に緻密なプランを立てる「プロジェクトマネージャ」が別物であることに本質的な問題がある。分業という観点ではやむなしだが、ベクトルが違いすぎているケースが多い。

5. 取り組んだら放すな、殺されても放すな、目的完遂までは……。

プロジェクト途中で「このスケジュールでは無理です」「それはできません」とか『泣き』を入れる人が多いが、そういう人にこの言葉はぴったり。(ま、これはおそらく電通営業マンむけの「なんとしてもお客を落とせ」というときに使う言葉なんでしょうけどね)

6. 周囲を引きずり回せ、引きずるのと引きずられるのとでは、長い間に天地のひらきができる。

これを割と実践しているのがACに代表されるITコンサルティング会社。ERP導入など複数の利害関係者が関わるプロジェクトではまさにこの言葉どおり。引きずられる情報サービス会社の人たち、それでいいんですか?といいたくなるが、「人間、支配する人、される人」2種あるから仕方ないかも。でも引きずられる側にまわるのならば、あんまり文句はいうべきでない。物理のエネルギーでもそうだが引っ張る側はそれだけのエネルギーが必要である。また引っ張る側はビジネス上の責任を伴って仕事をしているわけである。言われたとおりやるだけの立場にさんざんいた挙句雲行きが怪しくなると急に「それはできない」とか言い出す。お金を出しているクライアントに大見得きってそれいえますかと。「できない」という言葉の重みをかみ締めていってほしい。(もっとも、技術を知らないやつらが勝手に「できるできる」といったことについてはその限りでないが)

8. 自信を持て、自信がないから君の仕事には、迫力も粘りも、そして厚味すらがない。
9. 頭は常に全回転、八方に気を配って、一分の隙もあってはならぬ、サービスとはそのようなものだ。
10. 摩擦を怖れるな、摩擦は進歩の母、積極の肥料だ、でないと君は卑屈になる。

これはコミュニケーションにまつわるところ。8.の「自信」についてだが、情報サービス業どうも自信がない人が多い。テクノロジーを扱う以上、自分の知らないことが多少なりともあるのは当たり前だが、なにかひとつ「これなら負けない」という分野を築くことが必要だ。履歴書で申し訳程度に書く資格の話ではない。たとえばDB設計ができるというなら「大手企業のエンタープライズデータベースを再構築できる」というぐらいの自信がほしい。自信と実力は微妙に違う。東大を受験するために必要な「自信」とその「実力」のようなものだ。極端な言い方をすると合格率(「実力」)80%ぐらいで「自信」はついてくるわけであり100%と隔たりがあるとはいえ、「自信」があれば「東大を受験するんですよ」というぐらいはできるはず。実際にできるかどうかはやってみないと分からないかもしれないことは多いが、それを言葉にして恥ずかしくないぐらいの域にせめて30歳前半ぐらいには達しているべきだ。

10. だが、プロジェクトにおいて利害関係の異なるチーム同士の会合というのは摩擦だらけだ。どうもIT関係者は技術指向の人が多いせいか人と人との摩擦は何の役にもたたないとばかりに、回避回避へと流れる傾向にある。技術分野であっても本来譲歩してはいけない領域とかはあるものだ。たとえばDB設計において妥協すればどんどん汚いTBLができあがる。結果プログラムで(本来不要であった)ロジックを書くはめになる。確かにそれはそれでひとつの解決策だが、顧客視点にたったとき正しい姿から乖離してしまうのは本当はよくない。またプロジェクトを進めていくことは意思決定の積み重ねだが、要所要所で本来クライアントのお伺いを立てないといけない選択というのがあるものだが、それを諮ることなく勝手な解釈で判断しているケースも見受けられる。スケジュールをクライアントの了承なく書きかえたあげく、「たしかこんな感じで承っていたかと思いますが」と、すっとぼけるなどはほとんど犯罪だ。クライアントから見えない世界/見てない世界では妥協が横行しているわけである。その妥協で必要となった工数というのは意味不明である。もうほとんど欠陥住宅と同じである。住居が生活に不可欠なのと同様、情報システムが企業活動に必要ということで、需要がゼロになることはありえないが、縮小していくマーケットのなかそういうやりかたをしていると淘汰されるに違いない。


| | コメント (0) | トラックバック (0)

« 2005年8月 | トップページ | 2005年10月 »