処理速度
・アプリケーションの起動
WinとMacで大差なし。
ただし、SSD化していないPro17は遅いです。サイヤ人とスーパーサイヤ人くらい差があります。比較になりません。
CPUの性能差よりも、Diskの差が処理速度への影響は大きいようです。
メモリにロードする際に、やはりディスクから大量のデータを持ってくるからでしょう。

・スリープからの復帰
Macが圧倒的に早い。
Win7は、SSDなのに数秒待ちます。Macは１秒くらい。これはいい

・起動
Macが若干はやいかな。どちらも15秒くらい。速い。
MacProは遅い（HDなので）

・シャットダウン
ともに２秒くらい。いい

・その他
MacBookにはVMwareFusion3.1でWin7を動かしてます。
Office2010用なんですが、起動は2秒くらいで快適です。
まったく問題なし。逆にMac用のOfficeはもってませんが、
VBAが使えないとか、落ちるとか、評価が低いみたいですね。
それに来年出るらしいし。。VMでOfficeしたほうがいいですよ。

・全般
Core2とi5の違いは全く感じません。普通に使う人には違いは分かりにくいと思います。
そこにお金をかけるよりは、ストレージをSSDにしたほうが断然良いです。
速度が違いすぎます。もうハードディスクには戻れません。

操作性
レッツノートのマウスパッドもいいです。
しかし、Macのマルチタップには勝てません。圧倒的にMacの勝利。
非常に快適ですし、Exposeの使い勝手は最高。
ただ、マジックマウスは微妙かも。表面がつるつるしてて滑らしにくい。
マウスパッドみたいな感触だと最高なのに。
ちなみに、Late2009には慣性スクロールがないので、SmartScrollで対応。快適です。

開発環境
VMWareでUbuntu使ってますが、これはどちらも一緒かな。
ただ、XCodeとなると、話は別で、Mac一択ですね。
そもそも、そのために購入したし。

モバイル
レッツノート圧勝。
まずは軽さ。Mac(2.3Kg) Let's(1.3Kg)です。全然違いますよ。持つと。
バッテリーの持ちもレッツ圧勝。
レッツは１３時間、マックは７時間。
実際には、Let'sはらくらく８時間は持ちますが、マックは３時間で終わるときもあります。ACアダプタなしだとちょっと不安ですね。レッツは心配ないのに。

ユーザーエクスペリエンス
なんとも言葉で表現しにくい項目ですが、
Macはなんとなく使っていてワクワク感があります。
なぜかはわかりません。遊び心なのか、楽しさがありますね。
Winは全くありません。事務的な感じ。作業するために、仕方なく使うんだ的な。
ま、超個人的見解ですが。

番外：熱
レッツはそれほど熱くなりません。
が、Macは結構熱くなります。ずっと触ってると辛いくらいに熱い。

その分Letのファンはうるさいですけどね。

そして現在
高かったレッツではなく、MacBookをメインにしています。
OfficeはVMWareで使っていますが、サスペンドも速いし、使いやすいです。
マウスも使いやすいし、こんなことなら、最初からMacにしておけば、、
と思う今日この頃。

ちなみに、Pro17は画面が大きいですが、文字は小さいのでちょっと疲れるかもしれません。でも、作業はしやすいですね。圧倒的な表示力です。

長い年月をかけて、またUnixベースのOSにもどってきました。Ubuntuのユーザインターフェースは相当使いやすいですね。ずいぶんと進化しました。

Macの操作性、性能、デザインについては、もう言うこと無しです。
なぜみんなWinばっかり買うのか最近では不思議に思います。
とはいえ、MacでVMWareを使うとなると、Fusion、Win7、Officeを購入する必要があるので、コスト的には大分負けるのは事実ですね。

2010-06-12

ドキュメントの共有

会社の規則や、部署のルールなど、組織で共有したいドキュメントは少なからずある。
しかし、フォーマット、もしくは、デザインや機能面で読みにくかったりする場合が多い。

たとえば、リンク先がいちいちワードファイルだったり、検索できなかったり。

そもそも、ルールというものは、守ってもらいたいために作っているのだから、参照しやくすく、とっつき易いものであるべきだ。

組織にルールを展開するとき、大事なことはなんだろうか。

1) Formatが統一されてること
2) デザイン的にとっつきやすいこと
3) 機能的であること（当然だが、検索できる、リンクされているetc）
4) 作るorメンテナンスコストが人的にもモノ的にも安いこと
5) 分かりやすいロケーションにあること

たとえば、Wikiである。
見た目的には見慣れているので、2,3を満たすと思う。

４についても、ドキュメントをアップしやすい。
環境構築も楽。

しかし、、、
２を満たしているといっても、必要最低限なんじゃないだろうか。。。
とっつきやすいかというと・・・。

そう考えると、特化したウェブサイトを作るのか。。。
うーむ。

某有名グループウェアはあるのだが、２と３が致命的に×。
使いにくくてしようがない。

「ドキュメントの共有」なんて、ありふれた話だが、いざやろうとすると、いまいち方法論が確立されていないような気がする。なんでだろ。。たぶん、私が無知なだけか。

Wikiでいいじゃん、ということか？
はたまた、それぞれの事情があるんだから、スクラッチしろよ、ということか・・・。

効率を気にしないヒトはそれでもいいだろう。

2010-05-22

SIerは、まず自分たちをITでイノベーションしろ

SIerは、顧客にはITに関する提案をしきりにすすめる

でも、

SIerは、自分たちをITでイノベーションすることがない

いやいやいや、、、

CMMIしかりだが、イノベーションはITでしか起きないよ。

下請けに丸投げで、元請けSIerにはもう技術はなく、
かといって、下請けが元請けのためにITイノベーションを起こしてはくれない。当然。

本当に日本のSIerは怪しい集団だ。

ということで、こんな業界を去る決意をした今日この頃。

ちょっと世界の風に吹かれてくる。

2010-05-16

CMMIって意味あんの？　まじで？　たぶん、大多数が勘違いしてると思

社内でCMMIの推進なんかやってたりもしてました。
その時の話をしようと思います。
※なので、CMMIの内容の議論ではありません。

言いたいことは、タイトルの通りで、

「CMMIって意味あるの？」

です。

私が思うに、

「正しく解釈できれば、意味がある」

あくまで、CMMI歴数カ月の私の意見ですが、以下が正しく解釈されているポイントです。
もし、あなたの組織でCMMIを実施されていれば、チェックしてみてください。

１）組織のみんなが「CMMIって何？」に１分間スピーチで語れる
２）CMMI活動の中心人物が、組織のキーパーソン/責任者で構成されている

３）CMMIの教本に書いていることは、気にしない。やろうとも思わない。

４）普段の業務でCMMIなんて意識しない。けど、ルールには従ってるし、従わないと気持ち悪い

５）ルールでガチガチに標準化なんてしない

上記の５つのポイントが成功の秘訣だと思います。
細かいこと言うと、High Maturityがどうのとかありますが、そんなこと本質的じゃないので割愛。
つーか、CMMI自体、どうでもいいけど。
そんなことよりも、市場で生き抜くために努力する方が大事。能力度レベルの達成なんかより。
レベル５とっても、業績が落ちれば、CMMIにコストなんてかけられないし。
思うに多くのアプレイザーは、CMMIという、所詮「型」もしくは「形」にこだわりすぎている。
ま、彼らの食い扶持だから仕方ないが、彼らの言うとおりにヘエコラしても、ビジネスで負けたら意味なし。
しかも、CMMIはビジネスで勝つために直結したものじゃない。

話がそれたが、５つポイントについて、簡単に触れたい

「１）組織のみんなが「CMMIって何？」に１分間スピーチで語れる」について。

一番大事。
CMMIが何を提供してくるもので、自分たちの組織がどう活用しているかを、語れるか。
つまり、「CMMIの真髄を理解」する必要があります。
また、自分たちのシステム開発という業務と、CMMIとを結びつけてわかっているか？です。

「２）CMMI活動の中心人物が、組織のキーパーソン/責任者で構成されている」について

よく、興味ある人、または、ひどいと、手が空いている人、が担当になったりします。実際、うちもそうでしたが。
問題は、CMMIは組織のルールを決めるために活用されるものなのに、
組織的に意味がない、または、相手にされない、どうでもいいような社員たちが頑張ったって誰も従わない。

もっとひどいのが、そういうどうでもいいショボイ社員は、しょせん
「組織のことなんて考えてない」んですよ。まじで。
自分の仕事量とか、そんなショボイことにしか頭が働かない。組織をどういう方向に持って行きたいか、
また、それに従うみんながどうやったら幸せになれるか？なんて考えない。

だから、組織のキーパーソン、責任者こそが、CMMIの活動の中心人物になるべきであり、
それを許容しない組織であれば、それはマネージャの力量がショボイということだと思います。
ま、国内企業のマネージャなんて、ろくにゼネラルマネージャの素養をもってませんけどね。まじで。
私自身、大企業に働いてるのですが、いままで２人くらいでしょう？まともな人は。
あとはみんなちまいです。反面教師にはなりますが。

「３）CMMIの教本に書いていることは、気にしない。やろうとも思わない」について

CMMIの教本（PDFが配布されてますね）には、いろいろと”典型的な作業成果物”や”サブプラクティス”なんていろいろ書いてます。
が、そんなことはどうでもいい。参考にもなりません。
そんなことよりも、
そのプロセスエリアが「本質的に」何をすべきと主張しているかをじっくりと「考える」ことが大事。
そして、自分たちの組織文化的にどういうことがそれに当てはまるか「解釈」することがもっと大事。

バカなCMMI推進者たちは、すぐに文字通りにやろうとします。考えもせず。
これこそ、「形骸化のはじまり！」
「制度化」というCMMIでよく出てくる言葉の意味を理解してません。

逆説的ですが、「CMMIをやろうとすればするほど、CMMIを実装できない」
というジレンマに陥ります。

なぜか？

かんたん。「CMMIの本質を理解してないから？」

そもそも、組織のみんなは日々の業務を一生懸命こなしてます。日々、大小さまざまな改善を積み重ねてませんか？
なのに、CMMIでプロセス改善しよう、って言ったって、「いや、今だって改善してるけど？」的な議論になります。

つまり、CMMIなんて所詮枝葉、形つまり、方法論にすぎないのに、方法論の実装を目的にしちゃうCMMI推進者が「ガン」なわけですね。

しかし、キーパーソンたちをCMMIの推進の中心グループにすえれば、こういうバカな話にはなりません。
それは、本質的に意味があることだけを取り入れるということが、彼らにはできるからです。
実際、私は、そうしました。

で、話は戻りますが、
CMMIのSGを読み（あとは読まない）、その意味をじっくり理解する。
ほかのプロセスエリアとも絡めながら、メンバーと議論する。意見交換する。そして、自分たちが馴染めそうなやり方を考える。
実際には、すでに実施している（暗黙部分を含め）ルールと照らし合わせる。
無駄に、新しいルールは作らない。いやできていることと、CMMIをリンクさせるだけでいい
これが非常に大事。

「４）普段の業務でCMMIなんて意識しない。けど、ルールには従ってるし、従わないと気持ち悪い」について

組織には、その組織なりのカルチャーがあるはずです。
そのカルチャーを無視して、CMMIの実装はできません。

つまり、そのカルチャーを理解し、その方向性に反しないルールをしくべきということです。
そうすれば、実施者は、いやでも従うものです。

「５）ルールでガチガチに標準化なんてしない」について

とかく、CMMIを実装しようとすると、どうしても標準的なルールや基準を作りたくなります。

例えば、技術解の選定基準とかなんとか。。。

てか、それ意味ある？
それぞれのケースで、都度考えるもんじゃない？
なのに標準化する意味あるの？
です。

はい。ありません。まったく。

都度比較基準を設定して、評価分析する、程度でいいのです。

それを馬鹿正直に、費用対効果、運用面、・・・・といった基準を頑張って作ったりしだして何か意味ある？
てか、誰が嬉しいの？？アプレイザー？？

そんなことをやっても、組織は嬉しくないわけですよ。

で、実際私が何をしたか？

以下列挙。

・志願制（実際は暇な人が押し付けられて集まる）のCMMI推進体制を解体　→　組織の各管理層・リーダーで体制を作り直し

・ルールブックを全面刷新　→　標準化したルールをほぼ廃止。基本概念だけ残し、基準や会議体は解体。それぞれが任意に実施し、実施者が責任をもって行動する（特定の会議体にしゃんしゃんで出す意味はゼロだから）

・CMMIの文字通り実装はすべて廃止し、すでに実施できていることを、逆にCMMIにリンクさせる。実際無理あるルールは形骸化してたから。

これだけです。

で思うに、CMMIって目指すものじゃないです。
自分たちでSGとかからその本質を考え、実装したするものです。

その結果、SPやGPをチェックシートとして使い、自分たちができているか、確認する程度に使うものです。

最初から、SPやGPを目指して実施すると、実は実装、特に制度化が非常に難しいと思います。

そうではなく、もっと頭を使って、解釈することが大事です。

が、多くの人達は、そうできず、くだらないルールばっかり作りたがります。
つまり無駄な仕事ばかり作り、誰もハッピーにならず、形骸化するのです。

そうなった場合、いくらCMMIといえど、まったく意味がないものになってしまうでしょう。
そして、残念ながら、そういう人たちが、少なくとも、私の周りには、大勢います。
ま、業務が忙しく、CMMIなんて真面目になってられん、というのが実態かもしれませんが。
CMMIなんかで飯が食えるのはアプレイザーだけでしょうしね。
ま、個人的にはくだらんと思います。

GooleやApple、FacebookってCMMIやってるの？

ま、それがすべてを物語ってる気もしますね。。。

2010-05-09

組織文化は変えられるのか？

組織文化は変えられない、
というのが私の経験を踏まえた上での見解です。

もう少し正しくいうと、
「組織が持つ文化は、トップが変わらないと変わらない」
です。

ここで、
組織＝社長や部長、プロジェクトマネージャ
文化＝ボトムアップでいろんな活動が活発化する、トップダウンで動くなどのカルチャー
を意味してます。

そして、
組織文化は変えるものではなく、利用するものというのが私の見解です。

なぜなら、組織文化を変えるということが、目的であるはずではなく、手段であるからです。
手段を目指すのはおかしく、利用することで、真の目的を達成すべきです。
例えば、売上を伸ばすとか、利益率を上げるといったことが本来の目的であるべきで、文化は基本的になんでもいいと思います。
これらの目的を達成するために、文化を最大限活用することのほうが大切だと思います。

■　変わらないのは努力不足のせいじゃない。組織構造の問題だ

実際、システム開発プロジェクトでの次のような経験がありました。

部のカルチャーが完全なトップダウンで、自分たちのプロジェクトマネジメントの手法、日々の業務に関する改善提案が全然挙がってこない状況にありました。
部長自身が、超ワンマンタイプで、恐怖政治により自分の思惑通りに勧めるタイプだったからです。

しかし、ある課長がなんとか組織文化をボトムアップに変えようと頑張りました。
みんなから、自分たちのやり方や意見をどんどん出して、組織を活性化したかったようです。
実際に、その方は、組織のプロマネの規則を策定する立場にある人で、私も彼の直下で働いていました。

彼は、私が加入する前から、すでに数年間、奮闘していました。
しかし、組織の文化は一向に変わりませんでした。

なぜか？

それは、部長がワンマンで、トップダウン型だからです。そして悪いことに減点主義で、失敗をずっと覚えているようなタイプだったからです。

これでは、いくら組織のプロセスを変えたって、ボトムアップになりようがありません。当たり前です。
何か言って、失敗すれば、損をするだけですもんね。

しかし、一番の問題は、
「そもそも、なぜボトムアップにしなければならないか？」
です。

それ自体に意味はないのです。

優秀なトップが、迅速に意思決定し、部下たちがそれにしたがって一直線に進む方が、組織全体の力は上なのでないでしょうか。
組織の目標である、事業拡大とか、利益率アップに直接貢献できるのではないでしょうか。

実際、私はそれについてなんどもその課長と議論しました。
そして、ついには、私自身が、トップダウンで動きやすい組織にむしろ大改革しました。

実際、社員もそのほうが、働きやすいのです。
結局、ボトムアップというカルチャーや、その課長の願望であり、それは、ビジネスという観点からは離れていると私は思います。

ま、私自身、トップダウン・タイプのリーダーシップを振舞うほうですし、その方が好きです。
ただ恐怖政治は嫌いですが、トップと部下の力量があまりに離れている場合は、仕方ないかもしれませんね。

ついついビジネスという観点を離れてしまうあたり、大企業病かなーなんて思ったりする今日この頃です。
ちなみに、ボトムアップを期待する上司もイマイチだと思いますが。。

■　組織とビジネスを本気で考え、エネルギーを持って実行する人の意見だけは聞く

１つだけ補足すると、みんなからの様々な意見は個人的には大事だと思います。
ただ、それが、ビジネスを本気で考え、組織全体のことを本当に考えて、エネルギーのある人からの意見は非常に大切だと思いますし、尊重します。
しかし、そうでない場合（ほとんどですが）、容赦なく意見を無視します。時間の無駄ですから。結局自分のことだけ考えてますからね。例えば、自分の作業量が増えるとか、そういった観点で。

2010-05-04

大手システム開発会社のSEの未来は明るいか？

大手SIerで働くシステムエンジニア（SE)の将来について、ふと考えてみた。
（あくまで経験に基づく私見ですので一般論ではないと思います。たぶん）

私自身、現在、大手システム開発企業で働いていますので、大手からの視点で記述します。

日本におけるSI産業の構造上、よく言われている多重請負構造（元請け→孫請け→曾孫請→・・・）を抜きに語れません。
元請けは、大手が占めており、例えば、NTTデータや野村総研、アクセンチュア、NEC、IBMといったところでしょうか。ここでのSEは、ほとんどプログラミングはしません。よって、技術音痴になる傾向は、構造上、仕組み上、致し方ありません。
彼ら、つまり、大手SI企業のSEの役割は、大きく以下の二つです。

業務要件の抽出（つまり、ニーズ（クライアントが気付いてない部分も含め）を引き出す）
下請け管理（一般に、協力会社とかパートナーと呼ばれています）

１については、よく「問題解決」とか言ってるところですね。
２については、主にプロジェクトマネジメントとか言ってたりしますが、実態はほとんど丸投げです。つまり、「やっといて」とか「できた？」の世界。決して楽しいものではありません。

彼らのクライアントは、主に大企業です。フロントはいざ知らず、バックエンドでは、未だCOBOLでのシステムがメインでしょう。
しかも規模も増え続け、数百万ステップは確実にあります。

こうしたなか、これを保守（エンハンスともいう）しているSEたちが将来直面する仕事は、ハードウェアの入替（ずっとは使い続けられないので）に伴なうシステムのマイグレーション（移行）ではないでしょうか。

問題は、このマイグレーションにあたり、問題はふたつ。

大手のSEが技術不足により、良い提案ができない（基盤のスキルもコーディングのスキルもない）
システムのノウハウを持っている協力会社をそのまま使わざるを得ない

１について
２：８の法則的に、８割は、明らかに技術不足ですし、現状にあぐらを書いているのか、本当に疎いです。
新しく、適した技術を提案できるはずはありません。

２について
協力会社が例えばCOBOLしか使えない人たちだとすると、その人達のノウハウを活用せざるを得ないため、使い続ける必要があります。
したがって、またCOBOLでの開発になります。また、新しい技術へのキャッチアップはハードル高いです。

このような状況から、大手ITコンサル企業のSEは、ずっとCOBOLを使い続け、ハードウェアとミドルウェアだけ入れ替えながら、代わり映えの無いことをずっとやっていくのだろうなーと想像できます。

別にいいんですけど、もし知らずに大手で働きたいと思っている人は、よく検討したほうがいいですし、実際に務めている友人などに状況を効いたほうがいいと思います。少なくとも、自分の腕で食べていくという意味＝市場価値のある自立した人材は育ちにくいと思います。
所詮、時間貸しみたいな産業では、人が育ちにくいのかもしれません。。。

2010-04-30

Paper book cover, unique style in Japan. But when in Japan, do as the Japanese do!

I'm in a Starbucks, Tokyo right now.

When watching a certain American having a paperback covered in paper of a Japanese bookstore, I couldn't help grinning.

cause, I know this is the very Japanese traditional service at bookstores, called "excessive packaging!"

It was for the first time that I watched foreigner having it.

Waste of resources is not so bad, after all.
You can hide what's going on in your hands.